«Хорошая погода» в сети

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

Границы между мониторингом, анализом и управлением сетью нередко оказываются размыты. Эти понятия не очень четко дифференцируются и используются не всегда корректно, а ведь все три перечисленные дисциплины различаются между собой довольно сильно.

Мониторингом сети называют (пассивное) наблюдение за потоками данных на протяжении длительного времени. При этом в сетевой системе идет активный процесс, регистрирующий многочисленные параметры: величину нагрузки на сеть, объем протокольных данных, изменение времени реакции. Главная задача — сбор подробной статистики. Данные, как правило, оцениваются централизованно и преобразуются в «удобочитаемую форму» при помощи приложения генерации отчетов.

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

Управление сетью отличается «активным получением» значений параметров, прежде всего посредством протокола SNMP. При этом либо циклически опрашиваются стандартные статистические данные (MIB II, IETF/RFC1213) или специфическая информация (частные MIB), либо при помощи заранее определенных граничных значений отправляются и обрабатываются тревожные сообщения. В процессе опроса SNMP регулярно запрашивается статистический счетчик конечных устройств и сетевых систем, а поступающая информация записывается в специализированные базы данных. Помимо доставки данных команды Set протокола SNMP предоставляют возможность реконфигурации устройств.

МОНИТОРИНГ И АНАЛИЗ НА БАЗЕ ПОТОКОВ

Эта дисциплина «утвердилась» уже несколько лет назад, при этом так называемый мониторинг потоков развивается как отдельное направление. В отличие от массовой записи и хранения или обработки пакетов в классическом случае, анализ потоков отслеживает связи (потоки) между станциями или IP-адресами. Таблица потоков регистрирует пакеты данных либо в «выборочном режиме» (к примеру, каждый десятый пакет), либо пакет за пакетом. Вследствие заметно меньшего — по сравнению с анализом — объема данных мониторинг потоков может быть реализован в маршрутизаторах или коммутаторах при помощи главного процессора или специализированной интегральной схемы.

В целях ограничения объема данных, в особенности на магистральных коммутаторах и маршрутизаторах, вместо пакетов данных заранее сконфигурированному получателю (коллектору потоков) отправляется лишь обновление — статистическая информация со всеми деталями, при этом из памяти информация стирается. Доминирующими методами анализа на базе потоков являются Netflow (разработка Cisco) и S-Flow (разработка Foundry). Анализ и мониторинг потоков — это компромисс между очень точным анализом пакетов и статистической стратегией опроса SNMP. Новые потоковые технологии, к примеру Qflow, разработанная компанией Q1labs, базируются на схожей основной модели, однако концентрируются преимущественно на аспектах наблюдения, к примеру на распознавании аномалий и анализе безопасности.

Многие аналитические методы пытаются интерпретировать технические параметры и состояния для пользователя и определить причины отказов, падения производительности и проч. Часто это называют анализом основных причин (или первопричин). Очень сложно дать оценку отдельным ошибкам в общем контексте, потому что специфические для сети, сервера и приложений особенности не могут быть визуализированы немедленно. Часто анализ оказывается затруднен из-за сложности инфраструктуры ИТ, а иногда пользователь недооценивает влияния параметров, которыми на первый взгляд можно пренебречь. Порой для правильной оценки недостает решающей дополнительной информации, поскольку ее нельзя получить, к примеру, при помощи опроса SNMP.

В такой ситуации пригодятся активные методы тестирования, приобретающие все большее значение. Они используют реальную среду ИТ, чтобы из разных точек доступа к сети, а значит, с разных точек зрения проверять стандартизированным образом сетевые системы, службы и приложения и периодически контролировать их качество (готовность и производительность). При этом отдельные контрольные точки ведут себя как обычные пользователи (см. Рисунок 1). Благодаря совмещению «частичных срезов» формируется очень пластичная качественная картина активных деловых процессов. Гибкость этого метода позволяет в зависимости от типа решения даже моделировать пользовательские сообщения, а также тесты приложений в пределах среды терминальных серверов. Однако измерение качества не непрерывно: проверки периодически прерываются, и в измерениях возникают пробелы.

ПРОБЛЕМА МИКРОСЕГМЕНТИРОВАНИЯ

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

Классические топологии локальных сетей, в частности Thick/Thin Ethernet, Token Ring или FDDI, являются архитектурами разделяемой локальной сети, где определенное количество устройств делит между собой общую среду. Ошибка в сети одновременно видна всем участникам, включая анализатор. В этом традиционном сценарии достаточно одного анализатора на широковещательный домен.

Быстрое развитие коммутирующего оборудования привело в результате микросегментирования к тому, что проведение всеобъемлющего анализа становится по сути неосуществимым. Если 24-портовый концентратор располагает общей локальной сетью, то у каждого 24-портового дуплексного коммутатора имеется уже 48 сегментов (24 порта умножаются на два дуплексных сегмента), а потому данные между отдельными участниками в ло-кальной сети не поддаются учету анализатором или зондом. Необходим новый метод, который позволил бы сделать коммуникацию между станциями видимой и, тем самым, анализируемой.

ПРИЕМЫ И ХИТРОСТИ В АНАЛИЗЕ ДАННЫХ

Без вспомогательных средств, приобретенных самостоятельно или имеющихся в активных сетевых компонентах, успешное «тушение пожара» в современной инфраструктуре едва ли возможно. Основное правило гласит: анализировать и оценивать можно только те данные, которые были предоставлены процессом, агентом или тестовой системой. Далее приводится ряд технологий, полезных как для мониторинга, так и для анализа (см. Рисунок 2).

Измерительный концентратор. Проверяемое соединение отключается и направляется через традиционный концентратор, после этого все пакеты данных могут быть проверены и оценены в «разделяемой полудуплексной» локальной сети при помощи анализатора. Решение недорогое, но имеют место ошибочные результаты (к примеру, при принудительном переходе на полудуплекс).

Зеркальные порты. «Интеллек-туальные» коммутаторы часто обладают зеркальными портами, когда отдельные порты локальной сети или сегменты VLAN копируются на зеркальный порт для анализа. Хотя это решение удобно и конфигурируется без прерывания работы, у него есть слабые стороны. Так, некоторые ошибки в оригинале (в частности, ошибки CRC) не могут быть переданы через специализированную интегральную схему (Applications Specific Integrated Circuit, ASIC), поэтому измеренные данные оказываются неаутентичными. Кроме того, количество зеркальных портов в большинстве случаев ограничено, а пиковые нагрузки могут превысить их емкость. На функции зеркалирования способна повлиять и перегрузка центрального процессора коммутатора. В любом случае аутентичный анализ не гарантируется.

Аналитические отводы. При помощи адаптера делается отвод от линии передачи данных (медного или оптического) с минимальными потерями (вызванными затуханием). Копия полезных данных становится доступной на используемом для анализа и мониторинга порту (ТАР) в исходном виде — со всеми битовыми и блочными ошибками. Отводы предоставляются во множестве вариантов: отводы-конверторы, отводы для нескольких устройств, переключаемые и управляемые отводы или отводы с предотвращением вторжения. На рынке появились новые, так называемые агрегирующие отводы, позволяющие проводить анализ данных и при помощи стандартных сетевых карт: они «суммируют» оба дуплексных канала передачи данных в буфере и передают для анализа в один общий принимающий канал.

РАСПРЕДЕЛЕННЫЕ СИСТЕМЫ АНАЛИЗА И МОНИТОРИНГА

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

SNMP/RMON

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

К сожалению, протокол часто переоценивается в отношении возможностей распознавания и обработки ошибок. Одновременно недостаточное значение придается данным, получаемым в результате мониторинга всех сетевых портов.

Аналитическое расширение SNMP — RMON (I и II) — до сих пор используется редко, несмотря на его довольно большую известность, поскольку помимо прочих недостатков он порождает очень много управляющего трафика. Поэтому повсеместное распространение систем RMON сегодня вряд ли возможно. Попытка привлечения широкой массы пользователей посредством реализации центральных библиотек RMON внутри коммутирующих магистралей (SMON) также не удалась из-за применения нестандартных подходов и по причине высокой стоимости.

АППАРАТНЫЕ ИЛИ ПРОГРАММНЫЕ РЕШЕНИЯ

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

Рисунок 3. Высокоскоростной модуль анализа обеспечивает сбор с максимальной скоростью Gigabit Ethernet.

• В каких точках нужно проводить измерения и какие пиковые нагрузки можно ожидать в этих точках? Так, порт локальной сети при соединении Internet с пропускной способностью 2 Мбит/с хотя и генерирует приемлемую нагрузку на сеть, но рабочая нагрузка на зонд может повыситься вследствие множества сеансов (соединений ТСР). Порты сервера имеют тенденцию к "пиковым нагрузкам", и в случае Gigabit Ethernet "стопроцентные скорости сбора" с использованием программных зондов трудно достижимы (см. Рисунок 3).
• Интерес представляет, скорее, статический контроль проверяемых соединений или же требуется отслеживать массовые потоки данных? Пример - определение долгосрочных сетевых тенденций в отличие от расчетов стоимости в соответствии с использованием сетей.
• Какой бюджет предусмотрен для приобретения инструментария? Он может ничего не стоить, но коммерческие продукты в большинстве случаев выигрывают у своих свободно распространяемых аналогов в производительности и функциональности. Требования по гарантии, предложение соответствующего обучения, а также возможные "корпоративные правила", не позволяющие устанавливать бесплатное программное обеспечение, могут иметь решающее значение для выбора.
• Должно ли предусмотренное решение быть мобильным или стационарным?
• Какое количество точек измерений следует включить в процесс наблюдения одновременно?

ЗАКЛЮЧЕНИЕ

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

Список сокращений