Рентгеновский снимок сети

Несколько на первый взгляд не связанных друг с другом продуктов сгруппировались вокруг функций мониторинга сети и декодирования протоколов. Какое будущее их ждет?

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

Инструменты для решения проблем, с которыми администратору сети приходится сталкиваться чаще всего, можно условно разделить на шесть классов:

· системы управления глобальными сетями и системами на базе SNMP;

· зонды и приложения для удаленного мониторинга на базе RMON;

· программные сетевые мониторы;

· анализаторы протоколов;

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

· портативные диагностические инструменты с функциями сетевых мониторов, кабельных тестеров и анализаторов протоколов одновременно.

ПЛАТФОРМЫ УПРАВЛЕНИЯ

Глобальные системы управления на базе SNMP типа OpenView компании Hewlett-Packard, Spectrum компании Cabletron, SunNet Manager/Solstice компании Sun Microsystems и линии SystemView компании IBM предоставляют рабочий материал - API разработчика, стандартный пользовательский интерфейс и некоторые базовые данные о сети (например, карту сети и базу данных атрибутов узлов) - необходимый минимум, позволяющий производителям оборудования разрабатывать приложения для настройки и мониторинга своих продуктов. Предоставляемые данными платформами консоли управления могут быть настроены на отслеживание возникновения особых ситуаций различной степени сложности, прием, регистрацию и обработку аварийных сигналов от устройств и сбор разнообразной статистики ото всех агентов SNMP - обычно они располагаются на маршрутизаторах и концентраторах. Наиболее широко используемые платформы непригодны для управления очень крупными сетями из-за того, что им не хватает гибкости при разделении управляющей информации между несколькими администраторами в соответствии со взаимным распределением обязанностей; они нередко не в состоянии предоставить информацию в достаточной мере подробную, чтобы принимать надлежащие решения.

RMON ПРИХОДИТ НА ПОМОЩЬ

Зонды RMON и соответствующее программное обеспечение используют инфраструктуру SNMP и расширяют ее в соответствии со стандартами группы инженерной поддержки Internet. Зонд RMON собирает статистические и исторические данные с того сегмента сети, в котором он расположен. Зонд не передает все до единого байты данных центральной консоли. Если бы каждая группа RMON была реализована, то зонд RMON просто-напросто не смог бы обойтись без собственного процессора, поскольку некоторые из наиболее сложных функций RMON требуют значительных затрат вычислительных ресурсов. К ним можно отнести такие задачи, как вычисление "наиболее говорливых" (порождающих наибольший трафик) устройств и "наиболее общительных" (с наибольшим трафиком между ними) пар конечных станций, а также сбор и декодировка пакетов.

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

Ведущими поставщиками программного обеспечения и зондов RMON стали Frontier Software, Armon Networking (недавно приобретена Bay Networks) и Axon Networks (недавно приобретена 3Com). LANalyzer Agent for Netware компании Novell является агентом RMON для серверов Netware.

Цена на зонды RMON высока, но и работу им приходится выполнять не малую. Большинство администраторов сетей могут позволить себе установку этих дорогих (3000-4000 долларов) устройств только в ключевых сегментах. К этому добавляется еще и то, что RMON стандартизован только для двух нижних уровней модели OSI. RMON-2 (ко времени выхода нашей статьи ему уже должны были присвоить номер RFC) распространяет стандарт RMON на третий и вышележащие уровни. Однако сегодня имеющиеся рыночные продукты используют собственные нестандартные методы декодирования протоколов третьего и более высоких уровней; таким образом, неразумно было бы ожидать взаимодействия между зондами одного поставщика и программным обеспечением другого на этих уровнях. Но если вы можете себе позволить потратиться на аппаратное и программное обеспечение, а также на обучение и администрирование, то доступ к информации, достаточной для решения подавляющего большинства случаев низкой производительности и сбоев (особенно в сетях на базе IP), вам обеспечен.

СЕТЕВЫЕ МОНИТОРЫ

Информация SNMP, тесно связанная с IP своим происхождением, может передаваться по другим протоколам, например IPX и AppleTalk. В действительности, SNMP не сразу проник в мир ПК, поскольку лишь небольшая часть настольных систем на базе ПК работала с IP; эта ситуация сохранялась вплоть до начала бума Internet в 1994 году. Другая причина состояла в том, что процессоры ПК были относительно маломощны в сравнении с компьютерами Unix, из которых тогда преимущественно состояла Internet. Наконец, настольные ПК обычно работали под управлением недоделанных однозадачных операционных систем и, само собою, не могли поддерживать агента. Даже сегодня мир ПК слабовато охвачен управлением сетями и системами на базе стандартов IETF.

Однако в этом мире, особенно в сетях NetWare, появилось немало нестандартных утилит для мониторинга сети. Frye и Network Computing (обе теперь Seagate EMS), Intel, Cheyenne Software и сама Novell - вот только несколько компаний, вышедших на рынок с предложениями такого рода. Systems Management Server компании Microsoft имеет функцию мониторинга сети, а продукты управления SystemView компании IBM также способны справляться с такой задачей.

Этот класс сетевых мониторов выполняет во многом сходные с мониторами RMON функции. Они собирают статистику о кадрах и пакетах, о широковещательной, групповой и одноадресной передаче, об особых ситуациях, например о несовпадении контрольных сумм и нестандартных кадрах. Мониторы предоставляют информацию о трафике в каждой из этих категорий для каждого из протоколов в отдельности, однако "умалчивают" о третьем уровне - они составляют диаграммы о распределении пакетов IP, IPX и AppleTalk, но не производятся дальнейшее декодирование этих пакетов. Сетевые мониторы способны определять наиболее "говорливых" и наиболее "общительных", анализировать распределение широковещательных сообщений по источникам и т.п. Некоторые собирающие данные модули мониторов выполняются на серверах NetWare как загружаемые модули, другие же - на обычном ПК, возможно даже на том же самом, что отображает статистику и распечатывает отчеты. Как и системы на базе RMON, сетевые мониторы способны генерировать отчеты о производительности и подавать предупредительные сигналы при превышении заданных порогов, например, для числа ошибок или количества широковещательных пакетов.

Сам по себе сетевой программный монитор стоит недорого, но если учесть, что обычно под цели мониторинга выделяется отдельный ПК, то общая цена оказывается сравнимой с ценой зонда RMON. Однако зонды RMON для сетей IPX или AppleTalk не так то и просто найти. Оснащение сетей на базе ПК достаточным иструментарием для диагностики сбоев может оказаться весьма дорогостоящим, не говоря уже о проблемах создания параллельной инфраструктуры RMON и SNMP.

АНАЛИЗАТОРЫ ПРОТОКОЛОВ

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

Анализатор можно усовершенствовать, добавив фильтры до начала процесса сбора; в результате объем данных для хранения, обработки и анализа (человеком) оказывается не столь подавляющим. Так Ethernet при полной загрузке передает до 14880 кадров в секунду, а 100BaseT Ethernet в десять раз больше. Если буфер заполняется за несколько секунд, то ПО может просто не заметить возникшую проблему из-за того, что буфер не смог вместить остальные данные.

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

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

Наиболее трудная часть анализа протоколов - это интерпретация собранных данных (часто называемых следом) и определение источника проблемы. Следы анализаторов протоколов, даже если они были тщательно отфильтрованы, все равно приходится разбивать на меньшие блоки. Если у вас недостаточно опыта работы с серверами, клиенты, маршрутизаторы, агенты управления и программное обеспечение на всех уровнях модели OSI, то вряд ли вы сможете разобраться в следе.

Поставщики анализаторов протоколов затратили немало усилий на решение проблемы интерпретации. Одни предоставляют интерактивные справочные материалы с подробным объяснением заданий, выполняемых конкретными пакетами. Например, Internet Advisor компании Hewlett-Packard имеет Expert Commentators.

Наиболее амбициозные из них предоставляют автоматизированные экспертные системы для интерпретации собранных данных с рекомендациями о том, что необходимо предпринять. Например, такие события, как повторные передачи и тайм-ауты, свидетельствуют о возникновении проблем. Expert Sniffer компании Network General называет эти события симптомами, в то время как Azure Technologies, изготовитель линии анализаторов ExpertPharaoh, называет их экспертными событиями. Учитывая тяжесть и частоту таких событий, экспертная система анализатора протокола применяет набор правил и выдает возможную причину.

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

Анализатор протоколов, по определению, независим от протокола. Продукты на базе Macintosh и Unix весьма успешно декодируют пакеты в гетерогенных сетях. Наиболее мощные анализаторы декодируют свыше 200 различных протоколов. Как правило, программные анализаторы протоколов предназначены для использования с портативными компьютерами, поскольку эти инструменты переносятся обычно от одного места, где возникникла проблема, к другому. Подобно сетевым мониторам и зондам RMON анализаторы протоколов способны просматривать только один сегмент.

Анализаторы протоколов чаще всего используются в качестве диагностических инструментов. Если возникает проблема и нет иных способов определить ее причину, то анализатор протокола переносится в вызывающий беспокойство сегмент сети, где он собирает данные для экспертизы. Затем данные интерпретируются либо человеком, либо экспертной системой. (Исключение составляет распределенная система Distributed Sniffer System компании Network General, состоящая из нескольких более или менее постоянно подключенных мониторов, передающих информацию на управляющую консоль.)

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

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

КАБЕЛЬНЫЕ ТЕСТЕРЫ

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

Такие проблемы реально обнаружить и устранить только на месте и с помощью тех или иных приборов для замеров проводки. К счастью, все большее распространение структурированной проводки и преобладание топологий типа "звезда" для 10BaseT Ethernet и Token Ring позволили свести к минимуму количество связанных с проводкой проблем.

РЕШЕНИЕ ПОД РУКОЙ

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

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

Ведущие поставщики таких инструментов - компании Fluke, Microtest, Scope и Datacom Technologies. Enterprise LANMeter компании Fluke осуществляет IP-диагностику, например, ping и traceroute через маршрутизаторы и читает информацию с удаленных агентов SNMP и RMON. По мере роста возможностей этих устройств анализатор протоколов как переносной иструмент для диагностики сети (но вовсе не в качестве исследовательской лаборатории и инструмента разработчика) отойдет по своей значимости на второй план.

УЛИЦА С БЫСТРЫМ ДВИЖЕНИЕМ

Конструкторам анализаторов протоколов никуда не уйти от создания продуктов для поддержки новых высокоскоростных сетевых устройств. Задача эта нетривиальна даже для 100BaseT с тем же форматом кадров, что и у Ethernet на 10 Мбит/с. Некоторые поставщики анализаторов протоколов поставляют специальный сетевой интерфейс с выделенным процессором и большим объемом оперативной памяти для сбора пакетов с целью уменьшения нагрузки на шину и системные ЦПУ.

Ведущие поставщики анализаторов протоколов для локальных сетей предлагают также экспертный анализ и декодеры для протоколов глобальных сетей. Internetwork Analyzers компании Network General осуществляет декодирование для SNA, Х.25, frame relay и других протоколов. Недавно компания начала также поставки пакета для ISDN. Декодировние протоколов глобальных сетей предлагают также Azure, Digitech, Wandel и Golterman и Comtest.

Возможно, самую сложную задачу анализаторам протоколов, как, впрочем, и сетевым мониторам и зондам RMON, ставит коммутация. (Если бы маршрутизаторы могли сегментировать сеть так же дешево, как коммутаторы, они создавали бы те же препятствия для диагностики сбоев в сети.) Все перечисленные инструменты для диагностики сбоев могут обслуживать только один сегмент сети единовременно. Коммутатор же способен соединять 24 и более сегментов сети. Подключенные к двум портам коммутатора, диагностические устройства могут видеть весь трафик между ними. Но весь остальной трафик через коммутатор остается невидимым для монитора, в то время как трафик через все разделяемые порты повторяющего концентратора, наоборот, виден (см. Рис.1).

Компания Lantronix предложила новый подход к проблеме мониторинга сегментов. Продукты Network Analyzer предлагаются в двух- и шестипортовых версиях. Каждый порт предназначен для мониторинга и сбора трафика, а программное обеспечение EZMan анализирует и декодирует трафик и генерирует аварийные сигналы. LNA2 стоит 2995 долларов, а LNA6 - 3995 долларов.

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

ПЕРСПЕКТИВЫ АНАЛИЗА ПРОТОКОЛОВ

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

Некоторые поставщики управляющих программ и поставщики оборудования начали говорить о самоизлечивающихся сетях. Сетевые мониторы, вне зависимости от их разновидности: системы на базе RMON, утилиты на рабочей станции или сервере, анализаторы протоколов - имеют средства для генерации аварийных сигналов. Консоли управления сетью в ответ на полученный сигнал могут запустить ту или иную программу.

Несколько более сложная реакция на сигнал состоит в дальнейшем зондировании сети для уточнения диагноза. С распространением многозадачных операционных систем типа OS/2, Windows NT, NetWare, Windows 95, Unix и будущих версий ОС Macintosh появляется возможность передачи диагностического программного обеспечения для запуска на одном или нескольких узлах сети во время возникновения проблемы. Иными словами, при первых признаках сбоя управляющая консоль просит узел в вызывающем беспокойство сегменте выполнить то или иное задание по мониторингу и анализу протоколов. Пользователи могут даже не знать о том, что их компьютер выполняет такую задачу. При подобном сценарии нет необходимости устанавливать и обслуживать дорогостоящее диагностическое оборудование.

Развитие анализа протоколов должно пойти по пути повышения эффективности приложений и управления сбоями. Стеки протоколов стабилизировались, а их производительность возросла. Сетевые операционные системы вполне зрелы и надежны. С появлением настоящих клиент-серверных почтовых систем даже пресловутые проблемы надежности и администрирования электронной почты начинают сходить на нет. Но с ростом важности приложений для Internet и развитием новых парадигм в связи с появлением таких продуктов, как Java и объектно-ориентированные инструменты, потребность в анализе высокоуровневых протоколов неизбежно возрастает.