По следам пакетов

Для современных центров обработки данных 10 Gigabit Ethernet уже давно не сенсация, а вполне обыденное явление. Более того, стали появляться первые сети 40 и 100 Gigabit Ethernet. Для технологии детального анализа пакетов (Deep Packet Inspection, DPI)?— «королевской дисциплины» получения информации о сетях — это означает не только смену интерфейсов, но и увеличение объемов анализируемых данных в десятки раз по сравнению

с технологией Gigabit Ethernet. Если при использовании Fast Ethernet максимальный объем данных составлял 25 Мбит за секунду, то для стандарта 10 Gigabit это уже весьма значительные 2,5 Гбайт. При такой скорости жесткий диск емкостью 1?Тбайт заполнится примерно за 6,5 мин. С подобным информационным потоком не удастся справиться без специального высокопроизводительного аппаратного обеспечения, оснащенного соответствующими системами хранения и интеллектуальной системой администрирования данных.

Однако сначала следует получить ответ на принципиальный стратегический вопрос: надо ли записывать весь сетевой трафик, чтобы при необходимости проанализировать его для выявления проблемных случаев, или уже в самом начале стоит ограничить важный трафик данных, целенаправленно фильтруя его с помощью менее производительного аппаратного обеспечения? Это позволит решить, во что следует вкладывать средства — в порты доступа для тестирования (Test Access Ports, TAP) с функциями фильтрации на седьмом уровне или в анализаторы старшего класса (High End). Для важных проектов могут потребоваться обе технологии.

Вне зависимости от выбранного способа, для любых измерений, где важны данные о потере пакетов, необходимо записывать все пакеты данных и анализировать их. Подобная система предлагается, к примеру, в решении Timeline Appliance американского производителя WildРackets — в настоящий момент она способна справляться с потоком данных скоростью до 11,7 Гбит/с, а при некоторых уловках — даже до 20 Гбит/с. Подходы, когда анализ трафика переносится на периферию, то есть на сторону клиента, в отдельных случаях могут быть полезными и востребованными, однако они не способны удовлетворить все требования корпоративных сетей, а для провайдеров этот вариант совсем не подходит. Во многих средах, благодаря концентрации трафика в одном или нескольких немногочисленных соединениях 10 Gigabit Ethernet, впервые появляется возможность использования всего сетевого трафика (или, по крайней мере, большей его части) для централизованного мониторинга и исправления ошибок. Неважно, надо ли хранить данные за последние три-пять дней для специалистов технической поддержки третьего уровня, чтобы они могли адекватно реагировать на нерешенные проблемы справочной службы (Helpdesk), или нужно произвести лишь выборочный контроль — в любом случае централизованное управление облегчит работу техников.

РЕШЕНИЕ ПРОБЛЕМ В СРЕДЕ 10 GIGABIT ETHERNET НА ЛЕСТНИЦЕ OSI

Рисунок 1. Отображение отдельных протоколов (в данном случае протокол SIP) позволяет сделать много полезных выводов.

Оба подхода полезно рассмотреть на предмет типичных проблем на уровнях OSI. И начать следует с потери пакетов и времени их прохождения. Для действительно быстрого определения проблемы на втором уровне нужно сделать измерения в двух точках: одна находится в магистральной сети (Backbone), а другая — в удаленном местоположении или на стороне клиента. Проверенные решения позволяют просто и быстро выбирать пакеты проблемной коммуникации в обеих точках (нажатием правой кнопки мыши) и затем их сравнивать.

По количеству пакетов специалист сразу увидит, с какой стороны возникли неполадки, а по исходящему (TX) или входящему (RX) потоку пакетов он определит, в каком направлении пакеты теряются. Для определения времени прохождения он просто сопоставит трафик в обеих точках измерения. Если дельта-время двух пакетов (к примеру, Syn и SynAck) в точке 1 вычесть из дельта-времени этих же пакетов в точке 2, то можно узнать время их прохождения по сети.

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

Рисунок 2. С помощью временного ряда технический специалист может обнаружить периоды высокой нагрузки.

При дальнейшем подъеме по лестнице уровней OSI часто возникают проблемы с маршрутизацией. Нередко уже в гигабитной среде измерения показывают, что трафик идет совсем иными путями, нежели предполагалось. При концентрации трафика в одной-единственной магистрали 10 Gigabit Ethernet этой специфической проблемы не возникает, и тем не менее нежелательная локальная маршрутизация встречается гораздо чаще, чем можно предположить. Это вызывает значительную задержку процесса деловой коммуникации, причина которой остается непонятной.

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

Интересная ситуация складывается на четвертом уровне, ведь TCP благоприятствует нахождению правильных решений, если возникающие трудности не связаны с передачей голоса по IP (Voice over IP). Проблемы в сети, в приложениях, на сервере или на клиенте отражаются в сообщениях об ошибках протокола TCP и/или сказываются на его поведении. На основе этой информации можно выявить ключевые показатели: общее количество сообщений TCP об ошибках для каждого приложения, объем повторной передачи пакетов TCP (Retransmission) по сравнению с общим объемом переданных данных, количество повторных передач при взаимодействии с определенными коммуникационными партнерами, количество попыток повторного подключения (TCP Repeated Connection Attempt) и множество других аналогичных и крайне важных уведомлений.

Рисунок 3. При необходимости провести расследование можно анализировать предварительно заданные интервалы времени.

С помощью размера окна один из партнеров по коммуникации сигнализирует другому, какой объем данных он способен принять за один прием. Как правило, это около 65 536 байт, то есть до заполнения окна можно отправить очень много пакетов размером 1518 байт. Поскольку система непрерывно передает пакеты из стека TCP на вышележащие уровни, «узких мест» обычно не возникает. Но если коммуникация осуществляется, к примеру, через прокси-сервер с несколькими тысячами клиентов с одной стороны и несколькими сотнями серверов Web с другой, то заторы все-таки возможны. Уменьшение размера окна предупреждает о необходимости «притормозить» передачу: если скорость не снизится, то коммуникационные партнеры вынуждены будут считаться с угрозой паузы (TCP Zero Window). Аналогично обстоят дела с клиентами: если серверы приложений передают им слишком большой поток информации (к примеру, из-за плохо запрограммированных приложений Java), то они также сигнализируют об опасности с помощью размера окна. Компьютер пользователя в этот момент «зависает», о чем и сообщается службе технической поддержки.

Анализ протоколов на пакетном уровне существенно облегчает задачу. Проблемы на уровне TCP очень легко идентифицировать в результате анализа всего трафика данных. Полезно, если специалист сначала проверит, является ли рассматриваемая проблема основной или представляет собой лишь побочный эффект. Затем можно сравнить параметры различных приложений, IP-адресов или групп адресов, чтобы, к примеру, выяснить, как пространственно локализуется повторная передача TCP.

Теперь обратимся к TCP/UDP — для более подробного рассмотрения передачи голоса и видео. Всевозможные проблемы с прикладными протоколами, основывающимися на таких надежных транспортных протоколах, как TCP, проявляются и на этом уровне. Они могут выражаться, например, в том, что при моментальном отклике объем переданных данных — сравнительно небольшой. В этом случае клиент и сервер очень активно обмениваются пакетами, а на экране пользователя ничего не происходит — типичная проблема трафика CIFS/SMB.

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

VOIP: СОЛЬНЫЙ НОМЕР ДЛЯ СЕТЕВЫХ АДМИНИСТРАТОРОВ

Передача голоса по IP (Voice over IP, VoIP) — это первое приложение, которое полностью было передано в распоряжение сетевых администраторов, так как они обладают должным представлением о требованиях, предъявляемых оцифрованной речью ко всем уровням OSI. Процесс поиска ошибок существенно упрощается и ускоряется, если руководство компании не препятствует этому в стремлении сохранить конфиденциальность данных и без скепсиса воспринимает тот факт, что для устранения ошибок и тщательного мониторинга качества соединений требуются полные пакеты с разговорами или видеоконференциями. В противном случае, как и при обеспечении безопасности, приходится находить сбалансированное решение: ведь чем лучше защищена среда ИТ, тем она неудобнее для пользователя.

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

В мире традиционной телефонии дела обстоят точно так же, но в цифровой среде получить доступ к сетевому кабелю и подходящим средствам все-таки значительно легче. Вопрос с защитой данных в нешифруемых средах VoIP можно решить, «обрезав» в процессе записи отдельные протоколы в нужном месте (кстати, этот метод подходит и для любых других приложений, ведь не всегда просмотр полезной нагрузки пакетов действительно требуется). Таким образом, воспроизведение становится невозможным, а разговоры тем не менее характеризуются всеми необходимыми метриками (оценка разборчивости речи — Mean Opinion Score, MOS; вариации задержки; потеря пакетов, сетевая задержка и т. д.). Плохие показатели выделяются и предоставляются специалистам для анализа.

Разговоры VoIP инициируются и завершаются посредством сигнальных протоколов (от телефона к менеджеру вызовов и далее к другому телефону), а сами аудиоданные идут напрямую по протоколу реального времени (от телефона к телефону) и обычно управляются так называемым протоколом контроля в реальном времени (Realtime Control Protocol, RTCP). Мониторинг качества VoIP осуществляется обычно с помощью двух видов решений. Первые, с помощью протокола RTCP, считывают только информацию о статусе из конечных устройств или шлюзов и выдают ее в виде так называемых детальных записей о вызове (Call Detail Records, CDR), в которых данные из телефонов и УАТС обобщаются на том уровне детализации, какой предусмотрен при разработке устройств. Вторые самостоятельно рассчитывают потерю пакетов, сетевую задержку и ее вариации на основе реальных пакетов RTP — это вполне возможно, поскольку телефон VoIP каждые 20 мс отправляет голосовые пакеты.

У обеих этих технологий есть свои преимущества и недостатки. Метод с использованием RTCP окажется бесполезным, если пользователи отключат передачу или изначальная конфигурация неверна и содержит ошибки. Зато в случае надежного функционирования всего оборудования технический специалист получает информацию, близкую к результатам сквозных измерений (End to End), так как данные поступают непосредственно от конечных точек.

Метод с привлечением RTP отражает состояние разговора прямо в точке измерения. Если один из двух потоков данных пострадает после прохождения точки измерения, это не будет учтено в отчетах о качестве RTP. Безусловно, сочетание обеих методик облегчает поиск ошибок и повышает надежность расчетов, поэтому ведущие решения поддерживают и ту и другую.

10 GIGABIT — ETHERNET, ТОЛЬКО БЫСТРЕЕ

Имеют ли наши последние рассуждения какое-либо отношение к анализу 10-гигабитных магистральных сетей? Нет! По правде говоря, по сравнению с технологией Gigabit Ethernet изменились лишь скорость и объемы передаваемых данных. Это по-прежнему Ethernet. Разве что возросли требования к измерительным технологиям в плане производительности и надежности, а сетевому администратору понадобятся новые знания, чтобы понимать, как осуществляется взаимодействие между всеми уровнями OSI.

Маттиас Лихтенэггер — менеджер по региону DACH (Германия, Австрия, Швейцария) в компании WildPackets.