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

Волнения первого раскрытия

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >

Раскрытие, управляемое seedfile

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

Следует поместить seedfile в безопасное и неизменное место, независимое от дерева инсталляции NNM, такое как /opt/config/seedfile. Владелец и права доступа файла seedfile должны соответствовать особенностям локальных процессов управления.

Для удаления базы данных объектов, топологии и схем NNM (предполагается база данных плоских файлов NNM 6.x и более поздних версий) существует две опции. Чтобы сохранить содержимое старой базы данных, выполняются следующие шаги:

  • остановить демоны с помощью $OV_BIN/ovstop ;
  • переименовать каталог openview, выполнив команду mv openview openview.old. В версиях, предшествующих NNM 6.1, нужно удалить старые файлы регистрации событий с помощью команды $OV_LOF/xnmevents.*. Для NNM 6.1 требуется выполнить последовательность команд cd $OV_DB/eventdb; rm -rf $OV_DB/eventdb/*/* ;
  • очистить кэш SNMP с помощью команды $OV_BIN/xnmsnmpconf -clearCache ;
  • запустить ovwdb с помощью команды $OV_BIN/ovstart ovwdb ;
  • выполнить команду $OV_BIN/ovw -fields ;
  • запустить программы-демоны с помощью команды $OV_BIN/ovstart.

Для удаления базы данных без сохранения ее содержимого нужно просто целиком удалить подкаталог ( rm openview/*/* ), не переименовывая его на предыдущих шагах. Следует обратить внимание, на возможность удаления данных о сигналах.

Процесс удаления базы данных и заведения ее заново может потребоваться, поскольку на первых порах seedfile обычно бывает небезупречным. Он может содержать данные о маршрутизаторах, которые не находятся в домене управления, или не содержать данные о маршрутизаторах из намеченного домена управления. По мере тестирования нового seedfile будут возникать новые проблемы, что заставит произвести еще один раунд раскрытия. Для окончательного утверждения seedfile требуется финальная очистка базы данных и еще одно раскрытие.

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

Что делать, если seedfile случайно затерт, и нет резервной копии? Можно вернуться к своим записям и заново набрать этот файл. В конце концов, в файле, вероятно, содержится всего 50-100 строк. Однако нет ли способа автоматически восстановить список на основе базы данных NNM? Почему бы не воспользоваться командой ovtopodump -f filtername, чтобы распечатать данные обо всех маршрутизаторах, где filtername – это фильтр, определенный в файле $OV_CONF/C/filters и безошибочно отбирающий маршрутизаторы? Этот список будет включать маршрутизаторы, для которых имеются подсоединенные неуправляемые подсети. Использование таких маршрутизаторов в seedfile расширит домен управления на один уровень подсетей и маршрутизаторов, внешних по отношению к текущему домену. Следует руководствоваться подсхемой Internet и устранить в seedfile посторонние маршрутизаторы.

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

Раскрытие, управляемое посредством seedfile, почти всегда происходит очень быстро. Исключение составляют периоды затишья в сети, когда ARP-кэши истощаются, и многие рабочие станции выключены. В таких условиях автоматическое раскрытие может быть крайне медленным. Иногда бывает полезно включить в файл netmon.lrf параметр резкого старта "-J". Наличие этого параметра позволяет демону netmon предписывать удаленной системе с SNMP-агентом HP рассылать запрос ICMP-отклика по своим широковещательным IP-адресам, заставляя все активные машины подсети отвечать ICMP-откликом. Это приведет к заполнению ARP-кэша удаленной системы, который потом подберет netmon.

Заметим, что если система NNM действует как станция управления, для которой не предусмотрено автоматическое раскрытие самой себя, то seedfile должен содержать только имена ассоциированных накопительных станций NNM.

Опрос по требованию для улучшения характеристик раскрытия

Если NNM раскрывает устройства не так быстро, как требуется, нужно вмешаться. NNM может утратить активность раскрытия, или проверки конфигурации демона netmon могут быть запланированы на более позднее время. Обычно можно понять, у какого устройства имеется необходимая информация, и дать указание NNM немедленно опросить этот узел. Элемент меню Poll Node, который раньше назывался Demand Poll, приводит в действие GUI, эквивалентный командной строке nmdemandpoll. Это заставляет netmon немедленно запросить у устройства его базовую конфигурацию, таблицу интерфейсов, таблицу маршрутизации и ARP-кэш. Эта информация обычно дает возможность NNM раскрывать дополнительные устройства и топологию. Однако в этом подходе имеются недостатки.

Возможно, что netmon уже занят обработкой большого ARP-кэша на медленном маршрутизаторе, и в таком случае его опрашивать бессмысленно. Очереди SNMP демона netmon могут быть почти заполнены, что тоже делает вмешательство спорным. Если локальные строки сообществ SNMP являются неправильными, то единственное, что можно сделать — это скорректировать их. Сама система NNM может быть временно перегружена, тогда необходимые циклы ЦП будут отняты у netmon и демонов базы данных.

Опрос узла является более сильнодействующим средством, чем его тестовый опрос ( pinging ). Напомним, что netmon слушает неформатированный сокет ICMP на предмет новых IP-адресов в домене управления и все равно планирует опрос. Опрос вручную просто заменяет тот опрос, который был бы инициирован демоном netmon. Когда устройство подвергается опросу, интенсивность использования ЦП этого устройства значительно возрастает, сопровождаясь пиком сетевого трафика.

Техническое обслуживание сети часто планируется на конец недели. Могут устанавливаться новые коммутаторы и удаляться старые. Сетевой трафик в выходные дни низок – ARP-кэши могут быть истощены, и автоматическое раскрытие может ухудшиться. В среде UNIX может оказаться разумным написать задание cron, чтобы следить за сетевой электроникой с помощью скрипта nmdemandpoll.

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

Проклятие множественности строк сообществ SNMP

NNM начинает свою работу, имея единственную глобальную, используемую по умолчанию строку сообщества, которая первоначально устанавливается в "public". Можно также информировать NNM об особых строках сообществ, основанных на диапазоне IP-адресов (wildcard), или строках сообществ для конкретных устройств. Озабоченные проблемами защиты сетевые менеджеры часто используют множество строк сообществ, чтобы не дать хакерам/взломщикам возможности получить информацию о сети от агентов SNMP. По моему опыту, результаты такого подхода к безопасности исключительно печальны, а потому, если только это возможно, следует применять списки доступа (подобные тем, которые используются в Cisco IOS для ограничения доступа к сервису на основе списка допущенных клиентов).

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

Проблемы DNS

Одной из зон бедствия является DNS, точнее, плохо реализованные серверы имен и средства защиты в DNS. Например, рассмотрим маршрутизатор с большим числом основных и вспомогательных IP-адресов. Предположим, что клиент, такой как NNM, запрашивает имя для адреса 1.1.1.1 (используя стандартный распознаватель). В качестве защитной меры предосторожности распознаватель требует, чтобы результирующее имя отображалось обратно на тот же самый IP-адрес. Но некоторые серверы имен DNS укорачивают длинный список IP-адресов (потому что не обращаются к TCP за ответами длиннее 512 байтов), и тогда исходный поисковый запрос не возвращает никакого имени. Это ставит в тупик систему NNM, так как она не может отобразить IP-адрес в имя и поэтому не в состоянии использовать надлежащую строку сообщества для общения с ним.

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

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

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >