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

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

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

Стремление устранить эти недостатки SNMP привело к появлению стандарта RMON. Положения нового стандарта были сформулированы в документе RFC 1271, опубликованном организацией Internet Engineering Task Force (IETF) и прошедшем апробацию в 1992 году.

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

Технологической основой новой схемы управления сетью стали аппаратно-программные зонды, подключаемые к сегментам сети. Изначально зонды мыслились как автономные устройства, представляющие собой процессор (класса i486 или RISC-процессор), оснащенный сетевым адаптером и определенным объемом оперативной памяти, достаточным для работы программного обеспечения зонда. Сейчас можно сказать, что существуют три вида зондов: встроенные, зонды на базе компьютера и автономные зонды.

Встроенные зонды представляют собой модули расширения для сетевых устройств: концентраторов, маршрутизаторов, коммутаторов. Многие производители интеллектуальных сетевых устройств уже производят такие модули или объявили о намерении их производить. Это такие компании, как Cisco, Cabletron, 3Com и другие. Основное достоинство таких зондов состоит в том, что они обеспечивают поддержку всех основных групп данных RMON MIB при относительно невысокой цене. Кроме того, их легко переставлять из устройства в устройства, что бывает очень полезно при нехватке средств: можно поочередно собирать информацию о работе разных сегментов, физически перенося модуль, например, из одного коммутатора в другой. Первоочередной недостаток - низкая производительность и, как следствие, поддержка не всех групп данных RMON MIB.

Зонды на базе компьютера - это просто подключенные к сети компьютеры с установленным на них программным агентом RMON. К числу таких агентов относится, например, продукт Cornerstone Agent 2.5 компании Network General. Зонды на базе компьютера, как правило, поддерживают все десять групп данных RMON MIB и обладают гораздо более высокой производительностью, чем встроенные зонды. К преимуществам зондов данного типа следует также отнести возможность их расширения и более низкую стоимость, чем у автономных зондов. Недостатком данного решения является необходимость использования операционной системы, что приводит к повышению накладных расходов и может ограничивать пропускную способность зонда, а также относительно большой размер ("полноценный" настольный компьютер, с монитором и клавиатурой), что не всегда удобно.

Наивысшей производительностью обладают специализированные автономные зонды, примером которых может служить Netscout Agent компании Frontier Software. Здесь все вычислительные ресурсы зонда направлены на выполнение его основной задачи. Другим бесспорным, хотя и менее важным достоинством этого решения является малый размер корпуса устройства (обычно это "черный ящик" величиной с модем). Недостатками этого решения является, во-первых, высокая стоимость (по причине использования большого количества специализированных схемных решений), а во-вторых, недостаточные возможности для расширения.

Задача зондов - сбор информации в соответствии с группами данных RMON MIB (см. врезку). Рассмотрим подробнее, какие задачи позволяет решать собранная информация.

Во-первых, отметим очевидное - анализ объемов трафика позволяет определять источники максимальной нагрузки сети и принимать соответствующие решения, как тактические, так и стратегические. Это, однако, не единственный результат анализа объема трафика. При установке системы RMON обычно выполняется сбор базовой сетевой статистики (network baseline), характеризующей работу сети в нормальном режиме. Среди важных статистических показателей здесь отметим объем трафика и количество коллизий в минуту (для Ethernet). Базовая статистика обычно собирается в течение четырех-шести недель, отдельно в часы пиковой нагрузки и в часы нормальной работы. После выполнения этой работы можно устанавливать пороги событий по превышению, например, среднего числа коллизий на определенную величину. Для сетевого администратора такое событие может послужить сигналом о сбоях в сетевом устройстве - тогда его можно будет отправить в ремонт, не дожидаясь полного отказа. Установить неисправное устройство будет достаточно несложно, поскольку статистика собирается с разбивкой по MAC-адресам.

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

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

Несколько слов о продуктах, позволяющих реализовать RMON в сети. Прежде всего, отметим, что имеющийся на настоящий момент стандарт отнюдь не покрывает всех нужд сетевых администраторов. В частности, объекты управления, зафиксированные в RMON MIB, относятся к первым двум уровням стека протоколов ISO/OSI, в то время как для полноценного управления работой сети желательно иметь информацию о всех семи уровнях. Это приводит к тому, что производители самостоятельно "достраивают" свои продукты, руководствуясь своим собственным представлением о нуждах потребителей. В результате оказывается, что уровень совместимости продуктов оставляет желать лучшего: зачастую зонды, выпущенные одной компанией, отказываются работать с консолями другой компании. По счастью, основные компании, работающие в этом секторе рынка, сами выпускают и зонды, и консоли. Однако для встраиваемых зондов, для которых производители сетевого оборудования не выпускают соответствующие консоли, проблема совместимости может оказаться довольно острой; во всяком случае, это соображение обязательно следует учитывать при планировании закупок.

Основные производители продуктов и программ для RMON таковы (здесь мы не рассматриваем производителей встроенных зондов): Armon Networking, Frontier Software, Hewlett-Packard, Network General и Novell. Некоторые из этих компаний выпускают автономные зонды, другие - зонды на базе компьютеров (то есть фактически просто программные агенты RMON), третьи - и те и другие вместе. Все перечисленные компании выпускают управляющие консоли для работы со своими зондами.

Компания Armon Networking выпускает семейство RMON-продуктов под названием OnSite. Автономные зонды Armon работают на базе RISC-процессора i960 и снабжены четырьмя сетевыми интерфейсами каждый. Кроме того, эта компания выпускает программные агенты, рассчитанные на применение на SPARC-станциях Sun. (Выше уже говорилось, что использование RMON требует весьма серьезного компьютерного ресурса.) Система Armon Networking не ограничивается стандартным набором управляемых объектов RMON, в результате чего оказывается возможным изучение, например, сетевых протоколов межсегментного обмена данными. Управляющие программные средства производства Armon Networking обеспечивают автоматическую установку порогов событий, анализ и отображение аварийных сигналов (в соответствии с установленными фильтрами), отображение сводной информации о работе сети в целом. Имеется также специальная утилита (работающая в среде операционной системы Unix), которая графически отображает работу сети. На экране высвечиваются условные обозначения сегментов, которые соединяются между собой линиями, толщина которых тем больше, чем интенсивнее межсегментный трафик. Цвет линии соответствует типу используемого протокола. При работе в системе Unix возможно также сохранение информации от зондов в виде базы данных Informix и генерация отчетов. Для этого служит отдельное приложение.

Компания Frontier Software производит несколько моделей зондов для сетей различных топологий (Ethernet, Token Ring и различных комбинаций с глобальными сетями) на базе процессора 80486. Кроме того, имеются зонды на базе Pentium (для различных видов FDDI) и программные зонды, рассчитанные на работу на SPARC-станциях Sun. Программное обеспечение зондов носит название Netscout Agent. Агенты Netscout совместно с управляющим программным обеспечением Netscout Manager обеспечивают сбор информации по всем семи уровням стека протоколов ISO/OSI для всех групп данных RMON MIB. Имеется также возможность создания пользовательских фильтров, выявление дублирования адресов пакетов и нахождения дефектных приложений; имеется большое число заготовок фильтров, которые удобно использовать для создания собственных каналов. В основе работы Netscout лежит идея домена, понимаемого как сочетание агента (или группы агентов) с сетевым доменом. Таким образом, можно проводить анализ работы сети на уровне индивидуальных протоколов или приложений. Для создания доменов служит специальная утилита, позволяющая привязывать список критериев домена к определенному агенту. Тем самым оказывается возможным выделять из полного сетевого трафика ту его часть, которая более всего интересует администратора. К недостаткам данного продукта следует отнести, во-первых, его низкую совместимость с зондами других производителей (что во многом связано именно с концепцией доменов, которая другими фирмами не применяется), а во-вторых, большое число недоработок в системе представления данных.

Hewlett-Packard выпускает четыре модели автономного зонда LANrobe и программный монитор RMON под названием HP Power Agent. Зонд работает на базе RISC-процессора и имеет от 4 до 16 Мбайт оперативной памяти. Консольное программное обеспечение называется ProbeView и работает в среде HP OpenView for Windows. ProbeView может функционировать не только с LANProbe, но и с зондами других производителей (как уже говорилось, это встречается не так часто). Данный продукт позволяет выполнять все основные функции RMON, взаимодействуя со всеми семью уровнями стека протоколов OSI. ProbeView имеет очень удобную систему для сбора статистической информации о работе сети и получает точную информацию о базовом состоянии сети (baseline). ProbeView удобен для работы в многопротокольном режиме. В частности, поддерживается сбор информации о распределении трафика по протоколам. В данном продукте возможно использование IP-адресов (с обнаружением дублирования адресов), MAC-адресов и мнемонических имен. Данный продукт, как и все другие, имеет возможности фильтрации и захвата пакетов; возможна и перенастройка фильтров, однако эту операцию приходится выполнять вручную. Система снабжена удобной подсистемой представления данных.

Novell выпускает управляющий пакет для RMON под названием ManageWise. Работа ManageWise основана на использовании различных загружаемых модулей NetWare, которые могут работать на серверах NetWare версий 3.11, 3.12, 4.02 и 4.1. Один из наиболее важных модулей - NetExplorer, который собирает информацию о топологии сети и работающих в сети устройствах. Эта информация сохраняет в базе данных Novell NetWare Management System. Информацию для ManageWise собирает Netware Management Agent (эта программа устанавливается на сервере и поставляет информацию о своем "хозяине") и NetWare LANalyzer Agent, которые собирает статистические данные о сетевых сегментах. В состав ManageWise входит также LANDesk Tools производства Intel. ManageWise может самостоятельно устанавливать конфигурацию сети, в которой он работает, и выполнять сбор базовой статистики. В нем хорошо реализован механизм разрешения адресов на сетевом уровне стека протоколов. Здесь также возможно использование MAC-адресов, IP-адресов, IPX-адресов и мнемонических имен с определением дублирования IP- и IPX-адресов. Поддерживаются все семь уровней стека протоколов, что позволяет выявлять не только станции, но и приложения, дающие максимальный трафик. Поддерживается работа с многопротокольным трафиком, используемые протоколы распознаются, и соответствующая информация предоставляется пользователю. Данный пакет снабжен также весьма удобной системой представления данных. К недостаткам ManageWise можно отнести трудность конфигурирования продукта и невозможность перенастройки фильтров.

Network General предлагает программный зонд Cornerstone Agent, работающий на базе Intel 486/33 МГц, а также консольное программное обеспечение Foundation Manager, в его основе лежит выпускаемое компанией средство анализа протоколов Sniffer, благодаря которым возможности управляющей программы далеко выходят за рамки стандарта RMON. Foundation Manager обладает хорошей совместимостью с зондами, выпускаемыми другими компаниями. В данном продукте поддерживаются все семь уровней стека протоколов OSI для всех групп данных RMON MIB, поддерживается работа с многопротокольным трафиком, расшифровка адресов сетевого уровня и выявление дублирования адресов. Предусмотрено закрепление мнемонических имен за MAC-адресами, что очень удобно для работы в аварийной ситуации, поскольку нет необходимости тратить время на выяснение, какой физической станции соответствует данный адрес. Программа представляет хорошие возможности для анализа протоколов; имеется возможность определения наиболее часто используемых протоколов и выяснения степени загрузки сети работой в разных протоколах. Последняя возможность особенно хороша для сетей, представляющих собой конгломерат различных протоколов, как это часто бывает с корпоративными сетями. При анализе протоколов оказывается возможным проследить источник трафика вплоть до порождающего его приложения. К недостаткам пакета следует в первую очередь отнести неудобство работы с RMON MIB. Любое изменение конфигурации (например установка признаков аварийной ситуации) связана с большим объемом ручной работы.

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


Александр Крейнес - научный сотрудник Института кристаллографии РАН. С ним можно связаться по телефону (095) 334-2913.

Группы данных RMON MIB

1. Статистика (Statistics)Общая информация о трафике в данном сегменте (количество байтов, пакетов, ошибок и т. д.).
2. История (History)Сбор общей статистики трафика в течение определенного промежутка времени.
3. Аварийные сигналы (Alarms)Установка порогов для объектов MIB и генерация аварийных сигналов при выходе показателей за пределы установленных порогов, как правило, с передачей аварийного сигнала в группу событий.
4. Хосты (Hosts)Сбор основной статистики по MAC-адресам устройств (в частности, хостов) на данном сегменте.
5. Высшие N хостов (HostTopN)Список из N первых хостов, показатели статистики группы Hosts, по которым превосходят заданный уровень.
6. Матрица трафика (Traffic Matrix)Сбор основной информации о пересылке транзакций между станциями (идентифицируемыми по MAC-адресам).
7. Фильтры (Filters)Создание каналов (на произвольных сегментах) при помощи определяемых пользователем фильтров. Каналы могут использоваться для передачи данных в группу Event или Packet Capture, где будет генерироваться аварийный сигнал.
8. Захват пакетов (Packet Capture)Захват (полностью или частично) пакетов на данном сегменте.
9. События (Events)Управление генерацией событий SNMP и передачей соответствующих сообщений агента. Событие может быть проигнорировано, занесено в список или послужить причиной для генерации аварийного сигнала, который будет послан на управляющую консоль для интерпретации.
10. Порядок следования станций (Ring Order)Информация о физическом порядке следования станций на кольце Token Ring (только для сетей Token Ring).


Мониторинг коммутируемых локальных сетей

Компания Frontier Software Development предложила архитектуру Remote Monitoring (Rmon) для диагностики коммутируемых локальных сетей под названием Unison. Основу ее составляют первый зонд для Fast Ethernet плюс программное обеспечение для диагностики трафика на коммутаторе или на его портах. Специалисты по архитектуре Rmon компании Frontier Software дополняют свою программу NetScout Manager анализатором тенденций на базе SQL и инструментарием Switch Monitor. Это позволит администраторам контролировать трафик через популярные коммутаторы от внешних пробников, таких как Netscout Fast Ethernet Probe.