Причины недостаточной производительности глобальной сети очень разнообразны и могут охватывать все уровни OSI —от неисправных компонентов или неправильно настроенного пограничного маршрутизатора на предприятии (Customer Edge, CE) или у провайдера (Provider Edge) до приложений, изначально создававшихся для локальных сетей и не оптимизированных для сетей глобальных. Возможно также, что после введения новой версии приложения на базе XML сервер уже не справляется с поддержкой определенного количества одновременно выполняемых транзакций или клиенты располагают слишком маленькой памятью RAM. Кроме того, после установки заплат или обновлений работа таких «болтливых» протоколов, как CIFS или NFS, нередко приводит к снижению производительности сети.
Список возможных причин возникновения ошибок можно продолжать до бесконечности. Но именно для соединений через глобальную сеть необходимо выяснить, в чем конкретно они заключаются и кто за это отвечает — провайдер, корпоративный отдел ИТ или и те, и другие, но на разных уровнях? В любом случае, первой инстанцией всегда оказывается сетевой департамент, ведь именно ему приходится заниматься поиском источника проблемы.
Прежде всего специалист по сетям должен проверить загруженность линий и время отклика в различных сегментах на уровне TCP/UDP, причем измерение на уровне UDP предполагает наличие двух точек замера. Для этого существуют решения самых разных ценовых категорий. Так, варианты на базе технологий NetFlow/sFlow или SNMP предоставляют хороший обзор состояния сети. Для выявления затронутых неполадками уровней OSI необходимо детально проанализировать пакеты данных в пострадавших соединениях при помощи анализатора протоколов.
В случае централизованной архитектуры сети измерение и контроль времени отклика, а также определение загруженности соединений может проводиться из одной точки, расположенной, как правило, за входным маршрутизатором на цент-ральной магистрали. Если в сети имеется два или более маршрутизаторов, находящихся недалеко друг от друга, то для выяснения скорости прохождения трафика по сети потоки данных можно агрегировать в режиме реального времени, а ее значение определить на основании времени отклика (Delta Time) пакетов при процедуре установления связи (Handshake) TCP. Последующие отклики до момента разрыва соединения соотносятся с приложением. Таким образом, этот механизм разделяет время отклика между приложениями и сетью. Соответствующие инструменты способны контролировать данный параметр для каждого потока приложений (Application Flow), что позволяет выявлять общие аномалии или происходящие события при соединении с филиалами (см. Рисунок 1). 
Чтобы установить типичное поведение сети (так называемый Baselining) в глобальных соединениях, в филиале требуется организовать вторую точку измерения, лучше всего между маршрутизатором и местным распределительным коммутатором. Для определения времени отклика обе точки не должны работать синхронно, что позволит довольно точно измерить величину задержки глобальной сети при разумных затратах. Мониторинг соединения желательно проводить в течение месяца, обращая внимание на базовые параметры пользователя и его поведение: где, когда, как быстро, с кем и с какой целью он взаимодействовал.
Точность определяется отметками о времени (Timestamp) операционной системы (с точностью до миллисекунды) или специальной измерительной картой в анализаторе (с точностью до нескольких наносекунд), а также способом передачи данных в Ethernet. В идеале, это не должно влиять на скорость прохождения и порядок следования пакетов. С помощью времени входящей и исходящей передачи в оба конца (Inbound/Outbound Roundtrip Time) можно точно определить время задержки на каждом направлении (One Way Delay), если в локальной сети отсутствуют ассиметричные маршруты. Последнее обстоятельство имеет большое значение, когда администратору при анализе состояния сети необходимо рассмотреть поток входящих данных только на логическом уровне
и замерить его без синхронизации по времени.
Таким образом, обладая аналитическими навыками, на логическом уровне можно эффективно выявлять проблемы, возникающие на физическом уровне.
Если установленное время передачи не выходит за рамки типичного поведения, то на следующем этапе понадобится качественное и количественное измерение того, как ведут себя пользователи и приложения в процессе работы. Речь идет о том, чтобы выяснить, какие приложения и узлы нуждаются в определенной пропускной способности в конкретное время и что при этом наблюдается. При возникновении какой-либо неполадки администратор, воспользовавшись этой информацией, может выявить несоответствия посредством анализа сети по всем уровням OSI.
При классическом анализе сети обычно начинают со второго уровня и проверяют, к примеру, поведение
в полнодуплексном режиме. Если все в порядке, то внимание переключается на отдельные коммуникационные потоки на третьем и четвертом уровнях (как правило, TCP, UDP или RTP). Независимо от приложений, соответствующие шаблоны трафика указанных протоколов всегда схожи. Однако в длинных диалогах между клиентом и сервером сказываются параметры реализации протоколов. Кроме того, критическую роль играют лишние петли или проблемы с разрешением имен (Name Resolution) в глобальной сети, ведь они значительно увеличивают продолжительность выполнения транзакций, что чревато «замиранием» графичес-ких пользовательских интерфейсов на компьютерах, расположенных
в филиалах.
На прикладном уровне определение ошибок несколько усложняется. Как правило, для этого требуются знания в области протоколов SMB, Exchange, Citrix, NFS и их отдельных версий, конфигураций Windows или Novel Directory, а также надо разбираться во взаимосвязи клиентов и серверов Windows и конкретных механизмах их функционирования. Важна и обратная совместимость. Кроме того, необходим немалый опыт обращения с измерительными приборами. Особенно при изменениях на седьмом уровне документация о трафике данных в сети при ее нормальном состоянии оказывается ценным источником информации и экономит немало времени при локализации ошибок.
ЗАКЛЮЧЕНИЕ
Решение для проведения измерений и анализа внутри сети и за ее пределами не обязательно должно быть дорогостоящим, но с его помощью администратор может, к примеру, точно установить источники ошибок при возникновении проблем с производительностью сети. Как правило, этого достаточно для принятия решений о дальнейших действиях. Ключевыми факторами являются проактивный подход и корректное определение нормального состояния сети. Кроме того, от администратора требуются навыки работы с измерительными инструментами, ведь если ситуация окажется критической, очень важно быстро, эффективно и уверенно применять необходимые инструменты. В случае отсутствия в штате предприятия квалифицированных сотрудников следует заранее заняться поисками компании, предоставляющей компетентные услуги
в этой сфере.
Матиас Лихтенеггер — менеджер по региону Германия-Австрия-Швейцария компании WildPackets. Штефан Туме отвечает за продвижение технологий NGN в компании BrainWorks.
© AWi Verlag