АЛМАЗ НЕОГРАНЕННЫЙ

Сегодня для управления растущими локальными сетями зачастую уже недостаточно просто внимательности, недостаточно и использования SNMP.

Никто не станет отрицать, что потребность в быстром и эффективном управлении для современных сложных и взаимосвязанных сетей растет буквально с каждым днем. Как всем хорошо известно, трудности тоже возрастают; маршрутизаторы поставляет одна компания, концентраторы - другая, сетевые платы - третья, серверы - четвертая или пятая, а рабочие станции на базе Intel выпускают, по крайней мере, несколько десятков фирм. Необходимость в критически важном для бизнеса обмене электронными документами (Electronic Document Interchange, EDI) с поставщиками, в электронной почтовой связи с клиентами, а также в наличии критически важных проектов на основе Internet увеличивают сложность сетей. Пришло время заглянуть дальше SNMP и попытаться понять, какие преимущества может предоставить режим удаленного мониторинга (remote monitorinf, RMON).

Протокол SNMP определяет метод информационного обмена между приложениями управления и агентами на устройствах (т.е. программным обеспечением, которое собирает данные о конфигурации устройства, о текущем его состоянии и о событиях, на которые надо отреагировать).

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

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

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

Шаблон, где перечислены и объединены в группы все управляемые объекты, называется базой управляющей информации (Managemant Information Base, MIB). База MIB обеспечивает точную идентификацию и передачу данных. Протокол SNMP определяет 11 групп объектов для MIB-2 в RFC 1213, опубликованных в марте 1991 года.

Производители устройств разработали стандарты расширений MIB для ряда устройств, среди которых мосты, маршрутизаторы и серверы. Кроме того, к стандартным MIB часто добавляются разработанные самими производителями расширения; иногда описания этих расширений публикуются, так что ими могут воспользоваться и другие компании. Маршрутизаторы, хабы, а также различные другие сетевые устройства успешно используют SNMP для конфигурирования, управления и диагностики.

НЕДОСТАТКИ SNMP

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

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

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

RMON ПРИХОДИТ НА ВЫРУЧКУ

Этим проблемам посвящен документ RFC 1271, опубликованный Internet Engeneering Task Force (IFTF). Документ называется "База управляющей информации для удаленного мониторинга сети" (Remote Monitoring Managemant Information Base, RMON MIB).

RMON MIB - это дополнительная база MIB, в которой определяется еще один набор управляемых объектов с использованием стандартных SNMP. Объекты, определенные в RFC 1271 для Ethernet, были доопределены для Token Ring в RFC 1513, выпущенном в сентябре 1993. В феврале 1995 RFC 1271 заменили на RFC 1757.

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

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

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

Наконец, благодаря RMON, архитектура управления сетью становится более гибкой, нежели двухуровневая иерархия SNMP (см. Рис. 1). Мониторы RMON могут передавать данные нескольким управляющим приложениям, в том числе и одновременно (если только хватит вычислительной мощности и пропускной способности сети), а сигналы тревоги могут посылаться разным управляющим станциям в соответствии с их назначением. Поскольку RMON MIB может следить за деятельностью хостов на сегменте, зонды могут работать как уполномоченные агенты хостов, тем самым избавляя их от необходимости иметь собственных агентов.

ДЕСЯТЬ ГРУПП MIB

Данные, относящиеся к группе статистики, первой из десяти основных групп MIB, отражают использование сети, уровни трафика, а также важные для диагностики сбоев детали. Переменные включают счетчики кадров, октетов (на языке IETF - восьмибитных байтов), широковещательных и многоадресных сообщений, а также конфликтов; все это действует как для Ethernet, так и для Token Ring. Группа содержит также счетчики ошибочных кадров пяти разных типов, имеется и возможности слежения за размерами кадров.

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

В противоположность этому, в системах на базе SNMP каждое полученное в данный момент значение должно быть немедленно, в реальном времени, передано менеджеру, и именно менеджер отвечает за сбор и хранение всех данных.

В группе аварийных сигналов пользователь может различными способами определять пороги событий - устанавливать верхние и нижние пределы статистических параметров для определенных интервалов, ограничивать предельные значения изменения на интервале или отождествлять пакеты, как описано в группе фильтров. Зонд генерирует событие в тот момент, когда выполняется условие выхода за пределы порогового значения. (Чтобы аварийные сигналы начали работать, должна быть реализована также группа событий). В группе аварийных сигналов имеется механизм задержки, позволяющий, в соответствии с желанием пользователя, игнорировать пренебрежимо малые или повторяющиеся превышения порогов событий. Этот механизм дает возможность избежать передачи ненужных аварийных сигналов по сети.

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

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

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

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

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

С помощью группы фильтров определяются условия отождествления пакетов, например: при желании объявляются ошибочными все слишком короткие пакеты; отождествление такого пакета может инициировать перехват пакета или какое-нибудь другое событие. Можно также назначать буфер, куда будут направляться все перехваченные пакеты. Фильтры необходимы для отбора данных по определенному признаку.

В состав группы перехвата пакетов, тесно связанной с группой фильтров, входят буферы перехвата, которые при заполнении могут начинать записывать с начала буфера либо останавливать перехват. Размер перехватываемого куска тоже можно менять; скажем, можно потребовать, чтобы перехватывались только первые 80 байтов пакета. Перехваченные пакеты могут в дальнейшем составлять базу для анализа протокола методами, реализованными, например, в продуктах Sniffer фирмы Network General (Менло-Парк, шт. Калифорния) или LANalyzer производства Novell. Особенно полезен в данном случае режим автоматического перехвата пакетов.

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

Дополнительные группы для использования специально в сетях Token Ring описаны в документе RFC 1513. Некоторые из них входят в состав групп статистики и истории, а остальные (в том числе такие специфические для Token Ring данные, как порядок станций в кольце и маршрутизация источников) включены в десятую группу.

РАСШИРЯЕМ ПРЕДЕЛЫ

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

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

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

КАК ВСЕ ЭТО ВЫГЛЯДИТ

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

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

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

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

ПОСТУПИЛИ В ПРОДАЖУ

Продукты, совместимые с RMON, выпускаются в разных формах и сильно различаются по расширениям и области применения. В число ведущих производителей входят Armon Networking (Санта-Барбара, шт. Калифорния), Frontier Software (Тьюксбери, шт. Миннесота), Hewlett-Packard (HP, Пало-Альто, шт. Калифорния) Network General.

Зонды, входящие в состав выпускаемого компанией Armon Networking семейства продуктов OnSite для RMON, представляют собой автономные устройства с четырьмя сетевыми интерфейсами каждый. Они работают на базе RISC-процессора i960 и могут иметь оперативную память от 2 до 20 Мбайт. Armon также выпускает чисто программные зоны, работающие на SPARC-станциях производства Sun Microsystems (Маунтейн-Вью, шт. Калифорния).

Менеджер OnSite может работать на платформах HP OpenView, SunNet Manager, IBM NetView for AIX и HP OpenView for Windows (существует также автономная версия для Unix). В менеджер OnSite входят следующие инструментальные средства: Learning для автоматического установления порогов (исключительно трудоемкая задача, если выполнять ее вручную, без использования интеллектуального программного обеспечения), Network Health для сбора, фильтрации и отображения аварийных сигналов, а также Enterprise View, занимающееся составлением сводки обо всем предприятии вместо простого посегментного отображения информации. Помимо этого в состав продукта входит семиуровневое средство Protocol Display плюс средства графического представления данных и статистической информации, имеющиеся на любой управляющей консоли.

Armon предлагает также OnSite EyeNet Internetwork Monitor, прикладную программу для Unix, которая отображает все сегменты объединенной сети и представляет трафик между сегментами в виде линий разной толщины (чем толще линия, тем напряженнее трафик). Цвет линии соответствует типу протокола. EyeNet - это самостоятельно разработанное расширение MIB, в котором используется информация сетевого и прикладного уровней.

Другой дополнительный программный пакет и приложение под Unix, OnSite Net Reporter, собирает данные от зондов и сохраняет их в виде базы данных языка структурированных запросов Informix (Менло-Парк, шт. Калифорния). Возможна также гибкая генерация отчетов, кроме того, заранее задан ряд форматов для отчетов. NetReporter и EyeNet - это приложения под Unix.

Компания Frontier Software производит шесть моделей зондов NETscout на базе процессора Intel 486. Зонды предназначены для работы в сетях Ethernet, Token Ring, глобальных сетях с интерфейсом либо с Ethernet, либо с Token Ring, а также с комбинациями Ether/WAN и Token Ring/WAN.

Шесть зондов на базе Pentium предназначаются для различных комбинаций CDDI, single-attached FDDI, dual-attached FDDI и Ethernet или Token Ring. Чисто программные зонды могут работать на SPARC-станциях Sun под Ethernet и Token Ring. Для непомерно экономных покупателей существуют чисто программные зонды и под DOS.

Консольное программное обеспечение NETscout Manager поставляется для нескольких платформ: SunNet Manager/Motif, SunNet Manager/Solaris, HP OpenView/Motif, NetView for AIX/Motif, AT&T One/Motif и Windows.

EnterpriseRMON позволяет пользователям видеть все семь уровней трафика по всему предприятию, от одного конца до другого. Модуль Watchdog облегчает определение аварийных сигналов и генерацию прерываний SNMP, а модуль Protocol Monitor обеспечивает просмотр определенных протоколов и прикладного трафика (в установленном пользователем режиме). Пользуясь мышью, пользователь может просмотреть обстоятельства возникновения какой-то определенной проблемы.

Domain Manager позволяет группировать сегменты, дабы облегчить управление зондом, а Resource Manager обеспечивает доступ NETscout Manager к SNMP, что дает зондам NETscout возможность читать переменные из обычной базы MIB SNMP.

В состав NETscout Manager входит также инструментальное средство мониторинга взаимоотношений клиент/сервер. (В настоящее время поддерживаются Notes, Mosaic и NFS; кроме того, предполагается дополнительная поддержка для продуктов Sybase (Эмервиль, шт. Калифорния) и Oracle (Рэдвуд Шорс, шт. Калифорния), а также cc: mail и других приложений).

NETscout поддерживает семиуровневую расшифровку протоколов для одиннадцати различных стеков с пре- и пост-фильтрацией, статистику, графы истории и другие средства детального анализа. Перехваченные пакеты записываются в файлы, следуя формату, совместимому с продуктом Sniffer компании Network General. В средах Windows и Unix возможно создание сценариев для автоматического запуска программ при обнаружении аварийного сигнала.

Модуль Expert Vizualzer продукта NETscout обеспечивает настраиваемое трехмерное представление сетевых сегментов, протокольных доменов, подсетей и хостов. Размер объекта на экране соответствует величине выбранного статистического показателя (например числа пакетов, конфликтов или широковещательных сообщений), а толщина линий, соединяющих объекты, показывает размер трафика между этими объектами. Щелчок мышью в пределах объекта позволяет узнать дополнительные подробности.

Подразделение испытаний и измерений HP (Test and Measurement division) производит четыре модели зонда LanProbe - три для Ethernet и одну для Token Ring - и программный монитор HP Power Agent. Консольное программное обеспечение носит легко запоминающееся имя - HP ProbeView SNMP для OpenView под Windows.

Продукт поддерживает расшифровку протоколов восьми популярных семейств; перехват пакетов может осуществляться с пре- или постфильтрацией. Статистические показатели и их тенденции легко получать, отображать и экспортировать. Зонды LanProbe могут инициировать эхотесты для протоколов AppleTalk, Novell, VINES, DECnet, IEEE и 802.2, а также для Internet Control Message Protocol (ICMP). Эти тесты позволяют свести к минимуму обратный ("ping") трафик между сегментами. Аварийные сигналы могут записываться в журнал на диск, использоваться для активации сценариев, посылки извещений на пейджер или для генерации прерываний для заранее заданной группы адресов назначения.

Компания Network General более всего известна благодаря выпускаемому ею семейству средств анализа протоколов Sniffer. Однако Network General выпускает и свою собственную линию продуктов RMON. Программный агент RMON под названием Cornestone Agent может устанавливаться на базе Intel 486/33 МГц, работающих под Windows или OS/2. Выпускается также зонд Cornerstone Probe - персональный компьютер 486/50 МГц с установленным на нем агентом Cornerstone Agent.

Консольное программное обеспечение под названием RMON Foundation Manager взаимодействует с агентами Cornerstone Agents. Кроме того, в семейство входит программа QuickStats, собрание полезных программ анализа статистических параметров и тенденций, а также Solution Sets, позволяющий решать такие, например, нередкие проблемы, как анализ работы узлов в удаленном режиме.

ЗВЕЗДНАЯ РОЛЬ

Возможности продуктов на базе RMON быстро растут. Спецификация RMON-2, которая по всей видимости будет утверждена уже в ноябре 1995 года, расширит стандарт RMON до сетевого уровня модели ISO.

Зонды RMON нередко входят в состав коммутаторов Ethernet; тем самым управляемость этих устройств повышается. Компания Lannet (Ирвин, шт. Калифорния) впервые разработала технологию мониторинга всего трафика в объединенной панели коммутатора без снижения производительности. Некоторые из упомянутых выше производителей интенсивно разрабатывают зонды RMON для 100BaseT, 100BaseVG и ATM. Конечно, RMON не панацея от всех бед, но именно ему будет принадлежать главная роль в управлении сетями предприятий до конца этого столетия.