Конфигурирование накопительной станции

Строка сообщества демона SNMP для доступа по чтению/записи должна быть явно сконфигурирована в файле /etc/snmpd.conf следующим образом:

get-community-name:	public
set-community-name:	secret

Выберите свою строку сообщества для set-community-name, но, пожалуйста, оставьте get-community-name как public. Кроме того, важно убедиться, что вы не нарушаете права доступа к файлу (значением кода должно быть 400, а владельцем должен быть root ). Следует остановить и снова запустить демон /usr/sbin/snmpdm, чтобы он считал изменения, внесенные в файл /etc/snmpd.conf.

Должен быть сконфигурирован фильтр топологии, который применяется ко всем объектам базы данных, экспортируемым из накопительной станции. В файле $OV_CONF/C/filters должна появиться запись следующего содержания:

NetBackbone "Networks and gateways/routers"
{ Routers || Networks }

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

Чтобы задействовать фильтр топологии NetBackbone, файл $OV_LRF/ovtopmd.lrf необходимо отредактировать следующим образом:

ovtopmd:ovtopmd:
OVs_YES_START:pmd,ovwdb,OVLicenseMgr:-O -f
NetBackbone:OVs_WELL_BEHAVED:15:

Параметр -f NetBackbone предписывает ovtopmd экспортировать только те объекты, которые проходят через этот фильтр на все управляющие станции. Непосредственно после внесения этого изменения в LRF-файл нужно выдать следующие команды:

$OV_BIN/ovstop
$OV_BIN/ovaddobj $OV_LRF/ovtopmd.lrf
$OV_BIN/ovstart -v

Если существует большая база данных объектов (около 20000 объектов), то для обработки отфильтрованной базы данных ovtopmd понадобится приблизительно 20 минут.

Какие устройства следует экспортировать

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

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

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

Некоторые стратегии определения того, какие устройства следует экспортировать на управляющую станцию, представлены в таблице 6.1.

Для конфигурирования фильтра экспорта необходимо знать правильно определенную согласованную характеристику, однозначно описывающую устройство. Безусловно уникальными являются OID, IP-адрес и имя выборки устройства. Наименование поставщика может быть слишком общим. Например, наименование поставщика Cisco пропустило бы любой продукт, производимый компанией. В число этих продуктов входили бы любые рабочая станция или сервер с адаптером, произведенным Cisco. Имеется также большое число стандартных характеристик, таких как isRouter, isInterface и isHub. Чтобы определить свойства объекта (такие как sysObjectID), нужно щелкнуть правой кнопкой мыши по его пиктограмме, получить всплывающее меню и выбрать элемент меню "Describe/Modify Object".

Сбор данных SNMP на управляющей станции

Управляющая станция не импортирует данные SNMP, собираемые и хранящиеся на накопительных станциях. С накопительной станции на управляющую распространяются пороговые события. Чтобы увидеть реальные данные, которые привели к пороговому событию, нужно запустить сессию ovw на соответствующей накопительной станции, определить на схеме местоположение интересующего устройства и запустить утилиту Grapher.

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

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

Мониторинг систем NNM с использованием HP OV Operations и HP OV Performance Agents

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

Если агенты HP OV Performance Agents загружаются и конфигурируются во всех системах NNM с центральной системы, то затем можно использовать HP PerfView для мониторинга всех критических ресурсов систем, среди которых:

• коэффициент использования RAM;
• коэффициент использования виртуальной памяти (VM);
• интенсивность замещения страниц VM;
• коэффициент использования ЦП для всех процессоров;
• интенсивность дискового ввода-вывода (I/O);
• размеры очередей дисковых контроллеров;
• интенсивность возникновения ошибок сетевых интерфейсов.

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

Агенты HP OV Operations также должны загружаться и конфигурироваться на всех системах NNM. Агент может быть адаптирован для отслеживания конкретных условий с использованием настроенных скриптов. Во время пилотного проекта NNM не соответствующие норме условия сначала могут выявляться вручную. С целью будущей автоматизации следует записывать команды, которые использовались для выявления или устранения проблемы. Вот некоторые примеры:

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

Приложение HP OV Operations можно загружать в ту же самую систему мониторинга, где располагается PerfView. Тогда HP OV Operations может выявлять предупреждения HP OV Performance Agents. После этого можно считать, что создан MOM (Manager Of Managers). Эту систему следует расположить в корпоративном центре управления сетью.