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

Определение домена управления

< Лекция 2 || Лекция 3: 123 || Лекция 4 >

Конфигурационные файлы для регулирования домена управления

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

Файл seedfile – это просто список устройств, которые поддерживают SNMP. В качестве побочного эффекта этот список используется демоном netmon во время запуска для определения подсетей в исходном домене управления. Рекомендуются такие многосвязные устройства, как маршрутизаторы, но иногда можно использовать и другие устройства с насыщенными ARP-кэшами (такие как серверы). Чтобы информировать netmon o seedfile, следует вставить в файл $OV_LRF/netmon.lrf командную строку "-s/path/seedfile", выполнить команду $OV_BIN/ovaddobj $OV_LRF/netmon.lrf, чтобы зарегистрировать изменение, остановить netmon с помощью $OV_BIN/ovstop netmon и снова перезапустить его с помощью команды $OV_BIN/ovstart netmon. Примерное содержимое файла seedfile приводится на рисунке 3.2.

Примерное содержимое файла seedfile

увеличить изображение
Рис. 3.2. Примерное содержимое файла seedfile

Это список устройств, предназначенный для определения подсетей исходного домена управления. Полезные записи в seedfile соответствуют многосвязным устройствам с насыщенными ARP-кэшами, таким как маршрутизаторы. Можно ввести также серверные системы, поскольку их ARP-кэши будут наполнены IP-адресами клиентских систем.

Файл filters обеспечивает правила для демона ovtopmd по включению или исключению устройств на основе их атрибутов. Это базовое средство для управления тем, какие устройства раскрываются и впоследствии помещаются на схему. Фильтры, перечисленные в этом файле, имеют имена, и эти имена передаются ovtopmd по одному в регистрационном файле $OV_LRF/ovtopmd.lrf путем добавления параметра "-f filter_name", регистрации изменения при помощи $OV_BIN/ovaddobj $OV_LRF/ovtopmd.lrf и остановки и запуска демона ovtopmd, чтобы изменение возымело эффект. Файл filters можно использовать, чтобы гарантировать, что включены бесспорные устройства, такие как серверы, а также такие сетевые устройства, как маршрутизаторы, коммутаторы и тому подобное. Файл filters располагается в каталоге $OV_CONF/C/. Пример содержимого файла приводится на рис. 3.3. Заметим, что HP обеспечивает шаблон файла filters, так что им можно воспользоваться в случае ошибки персонала. Точный синтаксис определения фильтра и допустимые атрибуты объектов можно найти в Приложении A документа A Guide to Scalability and Distribution for HP OpenView Network Node Manager.

Важно отметить, что фильтры в NNM используются четырьмя различными способами. Все четыре фильтра определяются в файле $OV_CONF/C/filters, и все они обладают одним и тем же синтаксисом. Это фильтр раскрытия (Discovery Filter), фильтр схемы (Map Filter), фильтр сохраняемости (Persistence Filter) и фильтр топологии (Topology Filter).

Фильтр раскрытия контролирует процесс раскрытия, выполняемый NNM. Фильтр применяется путем использования выпадающего меню Options:Network Polling Configuration:Discovery Filter Option. Точное местонахождение меню зависит от версии NNM и от локальных настроек меню.

Фильтр схемы определяет, какие объекты отображаются на схеме ovw. Он применяется с помощью выпадающего меню Options:Map Configuration. И снова местонахождение меню зависит от версии NNM и от локальных настроек меню.

Фильтр сохраняемости помещает фильтруемые объекты в память и немедленно помещает раскрытые объекты на схему, если они проходят через фильтр. Так обеспечивается поддержка тесно интегрированных приложений сторонних поставщиков, зависящих от пребывания объектов в памяти. Фильтр применяется из выпадающего меню Options:Map Configuration:IP Map, а точное местоположение меню зависит от версии NNM.

Фильтр топологии на накопительной станции служит для контроля над тем, какие объекты будут передаваться на управляющую станцию. Имя фильтра определяется в файле $OV_LRF/ovtopmd.lrf.

Строки сообществ SNMP хранятся вместе с другой конфигурационной информацией SNMP. Эта информация управляется с помощью GUI $OV_BIN/xnmsnmpconf. Если обнаружится устройство со строкой сообщества для чтения, отличной от строки, используемой по умолчанию, и никакое выкручивание рук не убедит администратора устройства изменить эту строку (на "public"), то NNM сможет получить необходимую информацию от xnmsnmpconf. Иначе NNM не мог бы управлять этим устройством. Моментальный снимок экрана xnmsnmpconf приведен на рис. 3.4. За подробностями обращайтесь к оперативной странице руководства xnmsnmpconf.

Пример файла filters

увеличить изображение
Рис. 3.3. Пример файла filters

Этот отредактированный вручную файл filters содержит набор именованных фильтрующих выражений. Можно сконфигурировать демон ovtopmd для использования одного из этих выражений в фильтре топологии. Можно указать фильтр раскрытия, определенный в filters, с помощью GUI $OV_BIN/xnmpolling непосредственно из командной строки или из меню ovw.

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

Примерный моментальный снимок экрана конфигурации SNMP

увеличить изображение
Рис. 3.4. Примерный моментальный снимок экрана конфигурации SNMP

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

В реальных сетях обнаруживаются неисправные агенты SNMP. Время от времени неправильное поведение агента SNMP будет сбивать с толку netmon, заставляя его выдавать дамп памяти ядра, впадать в бесконечный цикл или просто тратить впустую поток команд для бесконечного опроса одного и того же устройства. Если в демоне netmon поддерживается удовлетворительная журнализация и трассировка (netmon–M 63 очень многословен), то файл $OV_LOG/netmon.trace продемонстрирует устройство, являющееся причиной неполадок в работе. Чтобы netmon не "спотыкался" то и дело об эти устройства, следует поместить их IP-адреса отдельными строками в файл $OV_CONF/netmon.noDiscover.

Параметры опроса NNM хранятся в файле $OV_CONF/polling. Их полагается конфигурировать с помощью GUI xnmpolling (или подходящих опций командной строки).

Во время первоначального раскрытия может оказаться разумным отключить функцию автоматического регулирования времени опроса и вместо этого выбрать фиксированный интервал (от 5 до 15 минут), чтобы гарантировать, что NNM сохранит активный режим раскрытия. Такой подход может сэкономить значительное время при первоначальном раскрытии для пилотного проекта, но это не требуется в операционном режиме производственных систем NNM после первоначального раскрытия. Следует иметь в виду, что с помощью этого GUI можно отключить раскрытие.

< Лекция 2 || Лекция 3: 123 || Лекция 4 >