Задачи периодического технического обслуживания NNM

Починка базы данных

Базы данных объектов NNM, схем и топологии должны обслуживаться периодически и часто. Это увеличивает надежность системы и повышает ее производительность. В процессе нормальной работы NNM находит, изменяет и удаляет объекты баз данных объектов и топологии, а пользователи создают, открывают, редактируют, закрывают и удаляют схемы, содержащие эти объекты. Время от времени могут возникать операционные проблемы, приводящие к аварийному завершению демонов NNM и сессий ovw, что вызывает несогласованность в базе данных. Чтобы предотвратить повреждение базы данных до такого уровня, что ее нельзя будет починить, важно, по крайней мере, еженедельно запускать для базы данных NNM эквивалент "Norton Disk Doctor".

Если имеется много схем различных авторов, то могут появляться объекты, удаленные из одних схем, но все еще содержащиеся в других схемах. Схемы, которые не открывались и не синхронизировались, будут содержать объекты, удаленные из более активно используемых схем. Счетчики объектных ссылок должны быть согласованы. Это делается путем периодического запуска (от имени root, возможно, используя запись в crontab ) следующей команды:

$OV_BIN/ovw –mapcount –ruvDR

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

Чтобы устранить проблемы в базе данных, нужно остановить netmon и запустить следующую команду:

$OV_BIN/ovtopofix –cshv

Эти две команды можно выполнять после завершения выполнения скрипта резервного копирования. Для больших баз данных для полного выполнения этих команд может потребоваться больше часа.

В среде 24*7 для возможности периодических перерывов на обслуживание требуется назначение резервного опроса с использованием второй накопительной станции или управляющей станции.

Помещение вновь раскрытых устройств в подходящие для них контейнеры

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

Сопровождение схем включает перемещение этих новых устройств в пиктограмму соответствующего контейнера. В предположении, что конструктор схем осведомлен об изменениях в сети, наличие новых пиктограмм вероятно, и соответствующая позиция очевидна. Если это не так, то следует собрать некоторую дополнительную информацию. Лучше начать с перетаскивания пиктограммы из области хранения новых объектов в Internet-подсхему. NNM будет рисовать подключения к подсетям, которые содержат интерфейсы данного устройства. Далее нужно взглянуть на имя этого устройства и перетащить его пиктограмму в подходящий контейнер. Если этих подсказок недостаточно, следует подключиться к устройству через telnet и поискать подсказки в заголовке начала сеанса. Если и это не поможет, нужно воспользоваться браузером MIB и запросить поля location и contact группы system соответствующего устройства. Эти поля определялись администраторами сети, и в данном случае их наличие поможет другим специалистам.

Ценное заключительное замечание: "Никогда не следует настраивать схему, используемую по умолчанию ".

Резервное копирование настроек схемы

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

Настройки схем сохраняются с использованием меню Map:Export. Чтобы это меню было доступно, должна быть определена переменная окружения $MAP_CUSTOMIZATION (это необходимо только для NNM 5.x). По умолчанию файл настроек располагается в /var/opt/OV/tmp/ipmap.out. Вместо того чтобы каждый день писать в один и тот же файл, имеет смысл создавать новые файлы, добавляя к имени файла текущую дату следующим образом:

ipmap.out.mmddyyyy

где mm – это месяц, dd – день месяца, а yyyy – четырехзначный год. Не следует применять двузначное обозначение года. (Не забудем урок двухтысячного года.)

Заметим, что поскольку импорт/экспорт настроек схем сохраняет не все, лучше использовать общее резервное копирование. Однако настройки схем могут применяться другой системой NNM (такой, как резервная система), импорт/экспорт производится очень быстро, и для него не требуется временной остановки системы.

Обновление MIB для новых устройств

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

При подготовке к загрузке обновленной или новой MIB следует скопировать соответствующий ASCII-файл в каталог $OV_SNMP_MIBS. В NNM поддерживается простой GUI для загрузки и выгрузки MIB из этого места. Сначала нужно выгрузить старую MIB, а затем загрузить новую. У этих операций имеется побочный эффект удаления старых определений прерываний и загрузки новых. По завершении этого шага следует воспользоваться браузером MIB, чтобы проверить, что MIB работает с данным устройством, и что в определения snmpCollect коллекции исторических данных SNMP внесены обновления, отражающие особенности новой MIB.

Заметим, что можно загружать/выгружать MIB в режиме командной строки с использованием xnmloadmib, но эта команда по умолчанию не занимается прерываниями. Требуется указывать это явно посредством опции -event.

Удаление нежелательных схем

Если не препятствовать произвольному созданию пользователями схем NNM, то, как правило, их схемы будут оставаться в системе в течение неопределенного времени. Чтобы получить список схем системы NNM, можно воспользоваться простой командой: ovwls.

Она выдает список схем и их владельцев. Наличие большого количества схем в системе NNM приводит к следующим последствиям:

• увеличенный размер базы данных;
• увеличенное время резервного копирования;
• неконтролируемые пользователи;
• увеличенное время выполнения ovw -mapcount ;
• увеличенное время выполнения ovtopofix –a ;
• сокращение общей производительности NNM;
• проблемы раскрытия.

Очевидно, что чем меньше схем, тем лучше. Нет никакой особой причины иметь схему с именем default, хотя некоторая символическая схема с таким именем создается. Можно предотвратить создание пользователями их собственных схем путем удаления соответствующих регистрационных файлов. Побочным эффектом такого шага является то, что при каждом обновлении NNM регистрационные файлы, вероятно, будут изменяться, и придется снова заходить в них для ввода изменений. Это очень сложный процесс. О нем говоритс я в "Controlling Map Access" в главе 9 руководства Managing Your Network with HP OPenView Network Node Manager.

Иногда пользователи создают схему неумышленно, неправильно набирая имя схемы, которую хотят открыть. Можно помочь пользователям избежать такой ошибки путем создания системного псевдонима для ovw, определенного в регистрационной среде пользователя. Например, если правильным именем схемы является "bellevue", то подходящей формой команды создания псевдонима может быть следующая:

alias ovw /opt/OV/bin/ovw –ro –map Bellevue

Теперь, если пользователь наберет команду ovw, то будет выполняться псевдоним, и поэтому будет открыта копия схемы "bellevue" в режиме только чтения.