Компания HP
Опубликован: 22.09.2006 | Доступ: свободный | Студентов: 675 / 67 | Оценка: 4.22 / 3.72 | Длительность: 22:59:00
ISBN: 978-5-9556-0042-6
Лекция 8:

Управление событиями с использованием NNM

< Лекция 7 || Лекция 8: 1234 || Лекция 9 >
Аннотация: Управляемые и неуправляемые устройства. Прерывания от ожидаемых и неожиданных источников. Потоки syslog от устройств и ovevent. Предопределенные и специальные категории сигналов. Настройка действий в ответ на события, ECS. Управление историями событий.

Введение

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

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

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

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

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

В NNM предопределяется шесть категорий событий, и разрешается определять новые категории. Например, можно определить специальную категорию событий Router Alarms, чтобы получать перенаправляемые сообщения syslog.

Каждое событие, определенное в NNM, можно модифицировать, чтобы приспособить к местным условиям. Для конкретных событий можно также определить специально настроенные действия. Это могут быть различные действия: от выполнения скрипта восстановления до отсылки e-mail-сообщения.

Для управления историями событий используется база данных событий, которая может быть старомодным плоским файлом trapd.log (в NNM 5.x и более ранних версиях) или средством eventdb, введенным в NNM 6.0. Поскольку полезно иметь возможность просматривать старые события, размер базы данных можно увеличивать, насколько это требуется.

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

В качестве исторической справки заметим, что для NNM 5.x и более ранних версий в HP определялись категории событий (event category) и обеспечивался браузер событий (event browser). В NNM 6.0 для тех же сущностей используются термины "категория сигналов тревоги" (alarm category) и "браузер сигналов тревоги" (alarm brouser). Основанием является следующее:

  • событием считается любое заметное действие;
  • сигнал тревоги является событием достаточно важным, чтобы обратить на него внимание.

Управляемые и неуправляемые устройства

NNM подвергает управляемый объект регулярному опросу на предмет его состояния и конфигурации, а демон snmpCollect собирает данные SNMP от управляемого устройства. Пиктограмма управляемого объекта отражает его состояние. Неуправляемое устройство не опрашивается, и для него не собираются данные SNMP. Его состояние неизвестно, поэтому пиктограмма не отражает состояние своего контейнера. Цвет пиктограммы неуправляемого объекта – пшеничный.

Менеджеры сети часто не управляют устройствами или интерфейсами по разным причинам:

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

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

Если на схеме видно, что устройство является неуправляемым, то означает ли это, что оно действительно не управляется? В тех случаях, когда это устройство находится в нескольких схемах, оно по-настоящему не управляется, только если является неуправляемым в каждой схеме. Если хотя бы одна схема содержит управляемый вариант устройства, то netmon будет его опрашивать. Реальное состояние управляемости устройства определяется с помощью команды ovtopodump –L device_name.

Заметим, что если устройство является неуправляемым в домене управления накопительной станции, и если это устройство экспортируется на управляющую станцию, то экспортируется и состояние неуправляемости. Предположим, что две или более накопительные станции управляют или не управляют данным устройством. Ситуация, когда это устройство относится к нескольким накопительным станциям, причиняет беспокойство, поскольку одна из них назначается для него основной, но какая? Существует девять правил, которыми руководствуется управляющая станция при выборе основной накопительной станции для объекта. Ответ на наш вопрос дают правила 3, 5 и 9:

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

Правило 5: Если только у одной накопительной станции данный объект имеется в управляемом состоянии (либо по умолчанию, либо в результате выбора), то эта станция назначается основной для данного объекта.

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

Полное рассмотрение этих правил представлено в главе 5 учебника HP OpenView Advanced Network Node Manager.

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

< Лекция 7 || Лекция 8: 1234 || Лекция 9 >