Обеспечение производительности приложений

Обеспечение производительности приложений

Андреас Штайн Если и можно охарактеризовать сегодняшние сети и приложения одним словом, то это «сложность ». Приложения стали крайне непростые. Они взаимодействуют через целый ряд портов TCP/UDP, работают в многозвенных средах и все чаще перемещаются с распределенных на централизованные серверы. Управлять важными деловыми службами становится все труднее. В такой ситуации поможет лишь глубокое знание происходящих в сети процессов.

Конвергенция трафика данных и голосового трафика на порядок повышает сложность корпоративной сети. Раньше сети передачи голоса, видео и данных были разделены, сегодня же все эти виды трафика передаются по единой сети. С появлением IP-телефонии отделы ИТ пытаются оценить, как IP-телефония, передача графических файлов и управление качеством услуг (Quality of Service, QoS) влияют на работающие в сети деловые приложения. Сетевое оборудование также стало сложнее. ИТ-ме-неджеры уже ближайшие два года планируют внедрение 10 Gigabit Ethernet, MPLS, виртуальных частных сетей (Virtual Private Network, VPN) и механизмов QoS. Однако, как и прежде, используются Gigabit Ethernet, ретрансляция кадров и ATM. Неважно, вследствие каких причин возникает необходимость реструктуризации сети: из-за потребности в пропускной способности, неправомерного использования сети или появления новых приложений — без конкретных и детальных характеристик все это гораздо больше напоминает искусство, чем науку.

Специфическая проблема заключается в том, что при обращении в службу технической поддержки большинство пользователей описывают именно затруднения, связанные с выполнением повседневных деловых операций: «Электронная почта медленно работает» или «Приложение CRM слишком долго реагирует». Подобные примеры подтверждают необходимость системного подхода к анализу работы всех приложений для распознавания и устранения проблем, планирования изменений производительности и минимизации времени реакции.

Абсолютно необходима информация о функционировании TCP и UDP, а также о случаях, когда HTTP занимает большую часть пропускной способности по сравнению с DNS или FTP (см. врезку «Идентификация важных индикаторов производительности»). Она дает сетевым администраторам и разработчикам приложений представление о том, как сотрудники используют сеть и насколько сетевые услуги, к примеру запрос к DNS, соответствуют ожиданиям.

Решение для управления производительностью сети и приложений должно обладать определенными основными функциями. Очень важно, чтобы оно предназначалось для применения в конвергентных сетях. При обеспечении безопасности полетов ни одна авиакомпания не полагается исключительно на собственные системы слежения, поскольку все используют одно и то же воздушное пространство. Этот принцип должен применяться и в случае голосовых, видеои информационных приложений в одной и той же сети. Ответственный за ИТ должен иметь возможность анализа и обзора всех приложений, а также сбора соответствующих данных. Прочие требования звучат следующим образом:

идентификация и нахождение всех приложений, будь то широко распространенные, комплексные, разработанные внутри компании или на базе Web, как, например, SAP, Citrix, IP Multicast, HTTP и одноранговые приложения;

выявление всех адресов отправителей и получателей из числа пользователей приложений;

взгляд на приложения в соответствии с классами QoS (с различением по кодовой точке дифференцированных услуг — Differentiated Services Code Point, DSCP);

выявление приложений по сегменту, к примеру по соединению Gigabit Ethernet, по виртуальному каналу (виртуальной локальной сети) и одновременно в соответствии с QoS (см. Рисунок i);

взгляд в реальном времени и ретроспективные отчеты при простой навигации между временными срезами;

мониторинг голосовых приложений и протоколов: протокола передачи в реальном времени (Real Time Protocol, RTP) и протокола инициации сеансов (Session Initiation Protocol, SIP), а также собственных протоколов таких производителей, как Avaya и Cisco;

предоставление многообразных недорогих инструментальных опций для охвата различных частей сети;

анализ и сопоставление собранных данных для выявления наиболее часто или, наоборот, редко применяемых приложений, независимо от инструментария и топологии;

подача сигнала об активном использовании приложений: к примеру, при превышении 50-процентной загрузки пропускной способности сегмента трафиком HTTP или уровня в 3% в случае одноранговых приложений, подобных Kazaa;

анализ времени реакции приложения до и после внедрения голосовых услуг с целью обеспечения работы деловых приложений и соблюдения соглашений об уровне сервиса (Service Level Agreement, SLA) для отделов при миграции на конвергентные услуги.

Единое решение включает в себя пассивный инструментарий для распознавания приложения наряду с активными агентами и развитыми средствами анализа производительности. Только так обеспечиваются наилучший возможный обзор и анализ происходящего на уровнях со второго по седьмой, и в итоге можно составить и конфигурировать внутренние соглашения об уровне сервиса с отделами и филиалами, а также управлять ими. Критериями становятся предоставление данных по сети в соответствии с приоритетами QoS, гарантированная пропускная способность и целевое использование корпоративной сети. Кроме того, указанный подход требует меньшего количества инструментов для управления приложениями на всем предприятии. В результате повышается продуктивность работы сотрудников отдела ИТ, а стоимость текущего ремонта и полная стоимость владения снижаются.

Еще одним положительным результатом является широкий, но контролируемый доступ к отчетам. Таким образом, отдел ИТ может помочь своим коллегам из бизнес-отделов решать возникающие проблемы, будь то взаимодействие финансовых менеджеров при согласовании бюджетных документов или тщательный анализ работы филиальной сети руководителями подразделений компании.

Идентификация важных индикаторов производительности

Решения по управлению производительностью сети ведут поиск специфической информации на всех семи уровнях для определения и анализа поведения сети и приложений:

при измерении QoS используется технология второго уровня 802.1р или DSCP в заголовке пакета в соответствии со стандартами RFC 2474 и 2475;

мониторинг виртуальных локальных сетей происходит в соответствии с 802. lq или с межкоммутаторным канальным протоколом (Inter-Switch Link Protocol, ISL) от Cisco;

широко известные приложения — HTTP, FTP и т. д. — идентифицируются на основе стандартного номера порта;

сложные приложения, например SAP, часто задействуют несколько портов; решение мониторинга способно объединять эти данные, сопоставляя порты и IP-адреса сервера для определения общего использования;

одноранговые приложения (Kazaa, Morpheus и прочие решения совместного использования файлов) часто задействуют другие порты помимо порта HTTP 80; для распознавания одноранговых приложений и сравнения схем трафика данных решения мониторинга могут следить за любыми сеансами TCP, если те не относятся к определенному порту приложения или широко известному приложению.

От повседневной проблемы к познанию

Для принятия решения о предоставлении деловых услуг по сети необходима более или менее детальная информация. Еще раньше следует выяснить, какого рода должно быть это решение: введение новых деловых приложений поднимает вопрос, достаточно ли высока пропускная способность самой корпоративной сети и доступа по глобальной сети к штаб-квартире, в вычислительном центре и в удаленных филиалах. Пример: ответственная за приложения группа в банке регулярно добавляет новые услуги без предварительного сообщения об этом другим подразделениям ИТ. В ответ на это ответственный администратор устанавливает зонд перед серверной фермой. В ходе проверок проводится мониторинг всех приложений и немедленно распознаются новые.

Еще одной проблемой является определение того, где находится причина снижения времени реакции: в сети или на сервере приложений. Так, к примеру, в одной крупной организации здравоохранения, где для управления электронными медицинскими данными использовалось требовательное к ресурсам программное обеспечение, время реакции составляло более 10 с. Нужно было установить, вызвана такая задержка сервером или приложением. Зонд седьмого уровня со встроенным активным и пассивным анализом времени реакции определил причину задержки в приложении. После этого организация смогла заставить разработчика приложения выпустить заплату для устранения проблемы.

Внедрение IP-телефонии ведет к разработке внутренних SLA между отделом ИТ и производственными подразделениями для обеспечения высококачественного предоставления голосовых приложений и приложений обработки данных. Для соблюдения SLA часто применяется управление QoS, однако этого не всегда достаточно. К примеру, у финансового приложения несмотря на управление QoS были заметные проблемы. После установки зонда удалось выяснить, что почти всем приложениям был присвоен высокий класс QoS, так что появлялись проблемы с качеством. Это лишь некоторые примеры из практики, когда более глубокое изучение на всех семи уровнях модели OSI позволяло сложное сделать простым. LAN.

Список литературы

Журнал LAN № 8 2005.