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

Андреас Штайн

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

Конвергенция трафика данных и голосового трафика на порядок повышает сложность корпоративной сети. Раньше сети передачи голоса, видео и данных были разделены, сегодня же все эти виды трафика передаются по единой сети. С появлением IP-телефонии отделы ИТ пытаются оценить, как IP-телефония, передача графических файлов и управление качеством услуг (Quality of Service, QoS) влияют на работающие в сети деловые приложения. Сетевое оборудование также стало сложнее. ИТ-ме-неджеры уже ближайшие два года планируют внедрение 10 Gigabit Ethernet, MPLS, виртуальных частных сетей (VirtualPrivateNetwork, 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, гарантированная пропускная способность и целевое использование корпоративной сети. Кроме того, указанный подход требует меньшего количества инструментов для управления приложениями на всем предприятии.