Удаленный мониторинг

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

Такими датчиками могут быть выделенные узлы, резидентные на сервере; они могут быть также включены в стандартное сетевое устройство, такое как маршрути­затор или коммутатор. Датчики собирают требуемые данные в каждом сегменте и передают их на консоль управления. Избыточные консоли управления предостав­ляют два основных преимущества для процессов управления сетью. Первое из них состоит в том что осуществлять мониторинг одной и той же сети и управлять этой сетью могут несколько сетевых администраторов, расположенных в разных местах (например, один администратор в Нью-Йорке, а другой в Сан-Хосе). Вторым пре­имуществом является сам факт избыточности. Наличие двух или более консолей управления означает, что если одна из консолей выходит из строя, то другая может быть использована для мониторинга и управления сетью до тех пор, пока первая консоль не будет отремонтирована (см. рис. 18.15).

Расширение RMON протокола SNMP создает новые типы данных. Эти данные увеличивают количество ветвей в базе данных MIB. Ниже описаны главные типы таких данных.

• Группа статистики (The Statistics Group). Эта группа содержит статистические данные для каждой подсети, в отношении которой осуществляется монито­ринг. Они включают в себя показания счетчиков (показания которых начи­наются с нуля) для байтов, пакетов, количества ошибок и размеров фреймов. Другим типом справочных данных являются индексные таблицы. В этой таб­лице идентифицированы все Ethernet-устройства, в отношении которых осу­ществляется мониторинг, что позволяет использовать счетчики для всех Eth­ernet-устройств. Группа статистики дает общую картину нагрузки в сети и со­стояние подсетей, регистрируя различные типы ошибок, включая ошибки проверки циклической избыточности (cyclic redundancy check— CRC), кол­лизии, а также пакеты слишком большого или слишком малого размера.

• Группа истории (The History Group). В этой группе содержится таблица данных, которые представляют собой образцы показаний счетчиков в группе стати­стики Ethernet за определенный период времени. Стандартной установкой для выбора образцов является период 30 минут (1800 секунд), а стандартным раз­мером таблицы 50 записей, что в целом обеспечивает 25 часов непрерывного мониторинга. При создании истории для конкретного счетчика в таблице создается новая запись для каждого интервала, до тех пор пока не будет достигнут лимит равный 50. После этого при создании новой записи старейшая запись удаляется. Эти образцы дают общую картину состояния сети (базовую произ­водительность) (baseline), которая может быть использована для сравнения с первоначальной для разрешения возникающих проблем или обновления общей картины при изменениях в сети.

• Группа предупреждения (The Alarm Group). Эта группа использует заданные пользователем пороговые значения. Если показания счетчиков выходят за границы пороговых значений, то соответствующим лицам посылается сооб­щение-предупреждение.

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

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

• Группа верхних N узлов (The HostTopN Group) — эта группа подготавливает от­чет о группе узлов, находящихся в верхней части статистического списка, со­ставленного по измеряемому параметру. Наилучшим способом описать груп­пу является приведение примера. Отчет может быть сгенерирован для верхних 10 узлов, которые генерировали широковещательные сообщения в течение дня. Другой отчет может быть сгенерирован по максимальному количеству пакетов, переданных в течение дня. Эта категория предоставляет простой спо­соб определить, кем и каким типом данных в наибольшей степени была за­гружена выбранная подсеть.

• Матричная группа(ТЪе Matrix Group) — в этой группе записываются данные, ко­торыми обмениваются пары узлов в подсети. Эти данные хранятся в виде мат­рицы (многомерной таблицы). Одним из отчетов, которые могут быть сгенери­рованы из этой группы является отчет об использовании узлом сервера. Реоргани­зуя матрицу можно создавать и другие типы отчетов. Например, один отчет может показывать всех пользователей конкретного сервера, в то время как другой отчет может отображать все серверы, которые используются конкретным узлом.

Группа фильтров (The Filter Group). Предоставляет способ, которым консоль управления указывает датчику RMON какие пакеты следует выбирать на кон­кретном интерфейсе указанной подсети. Такой выбор основан на использова­нии двух фильтров: фильтра данных и фильтра состояния. Фильтр данных предназначен для проверки соответствия данных заданным образцам, что по­зволяет выбирать данные особых типов. Фильтр состояния основан на типе рассматриваемого пакетов, например, пакет CRC или действительный пакет. Эти фильтры могут соединяться с использованием логических операций "и" и "или", что позволяет создавать сложные условия. Группа фильтров позволяет сетевому администратору выборочно просматривать различные типы пакетов и более эффективно осуществлять анализ работы сети и устранять неполадки.

• Группа захвата пакетов (The Packet Capture Group). Эта группа позволяет сете­вому администратору указать метод, который следует использовать для захвата пакетов, выбранных группой фильтров. Захватывая указанные пакеты сетевой администратор может детально и точно просмотреть пакеты, которые удовле­творяют базовому фильтру. Группа пакетов также указывает количество захва­ченных индивидуальных пакетов и общее количество перехваченных пакетов.

• Группа событий (The Event Group). В этой группе регистрируются события, кото­рые генерируются другими группами в базе данных MIB. Примером события мо­жет служить превышения счетчиком порогового значения, указанного в группе предупреждений. Такое действие генерирует событие в группе событий. На основе этого события может быть сгенерировано некоторое действие, такое, например, отправка сообщения-предупреждения всем лицам, перечисленным в параметрах группы предупреждений или создание записи о входе в сеть (logged entry) в табли­це событий. Событие генерируется для всех операций сравнения в расширениях RMON базы MIB.

• Расширения Token Ring (The Token Ring Extensions). В этой группе находятся счетчики сетей Token Ring. Хотя большинство счетчиков в расширениях RMON не связаны с конкретным типом протокола, группы статистики и истории име­ют такую связь. Они конкретно настроены на протокол Ethernet. Группа Token Ring создает счетчики, которые необходимы для мониторинга и управления се­тями Token Ring с использованием удаленного мониторинга RMON.

Следует помнить о том, что RMON является расширением протокола SNMP. В частности, это означает, что хотя RMON расширяет возможности протокола SNMP и усовершенствует осуществляемый им мониторинг, сам протокол SNMP не­обходим для того чтобы RMON мог функционировать в сети. И, в заключение, важ­но помнить о том, что имеются последние версии протокола SNMP и удаленного мониторинга RMON, обозначаемые SNMPv2 и RMON2. В настоящем изложении описаны не все новые возможности этих версий.