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

День с NNM

< Лекция 11 || Лекция 12: 123 || Лекция 13 >
Аннотация: Специальное управление производительностью. Тестирование патча NNM. Проверка корректного функционирования меню. Подтверждение правильности новой процедуры, изменений операционной системы. Проведение направленного раскрытия. NNM и маршрутизаторы.

Введение

Обычный день с NNM не обходится без того, чтобы какой-нибудь пользователь не обратился к администратору с просьбой о сборе нестандартных данных SNMP о производительности. Часто такие пользователи могут получить нужные данные с помощью стандартного MIB-браузера и средства xnmgraph. При наличии потребности в коллекции долговременных данных может понадобиться добавить коллекцию исторических данных SNMP, поскольку средство xnmpgraph историю не сохраняет.

Тестирование патчей NNM может не быть ежедневным событием, но посещать web-сайт HP OpenView следует каждый день. Независимо от того, практикуется ли на узле активное или осторожное управление вставками, всегда следует тестировать "заплатки" в лаборатории, прежде чем вводить их во все действующие системы NNM.

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

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

Тестирование приложений независимых поставщиков с использованием NNM включает проверку конфигурационных файлов, пиктограмм, MIB, меню и дискового пространства.

Имеет значение и подтверждение правильности изменений операционной системы. После внесения патчей в ОС или модернизации RAM, диска, или адаптеров LAN следует проконтролировать настраиваемые параметры ядра, DNS и показатели производительности.

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

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

Обычным делом является также улаживание проблем раскрытия маршрутизаторов и интерфейсов маршрутизаторов.

Специальное управление производительностью

Хотя NNM обычно конфигурируется в расчете на сбор исторических данных SNMP о производительности, часто бывает нужно непредусмотренным заранее образом собирать другие данные о производительности. Часто требуется отслеживать конкретную переменную MIB для одного устройства в течение нескольких часов. Стандартным инструментом является GUI MIB-браузера. Нужно выделить пиктограмму устройства в окне схемы ovw, вызвать MIB-браузер из меню Tools:SNMP MIB Browser, перейти к интересующей переменной MIB и нажать кнопку Graph. Появится стандартный GUI xnmgraph с десятисекундным интервалом опроса переменной в реальном масштабе времени. При необходимости опрос можно сделать более активным, уменьшив интервал опроса до одной секунды. Эта установка легко выполняется с помощью разворачиваемого меню File:Configure in Data Collector. Поскольку во время этого динамического опроса данные не сохраняются в базе данных snmpCollect, к ним не применяются какие-либо действия по сокращению данных, которые могут периодически выполняться для ограничения объема исторических данных SNMP.

Заметим, что нет строгой необходимости запускать MIB-браузер из GUI ovw. GUI xnmbrowser можно запустить из командной строки следующим образом:

$OV_BIN/xnmbrowser -node device_name

Здесь предполагается, что переменная окружения $DISPLAY уже установлена правильно.

Если конкретное устройство предстоит подвергать такому исследованию ежедневно, то имеет смысл создать простое приложение над MIB ovw, которое можно добавить в структуру меню. MIB-приложение, созданное таким способом, будет похоже на Graph, а интервал опроса и MIB-переменная могут быть предопределенными. Заметим, что при создании MIB-приложения генерируется файл регистрации приложения (ARF). В тех средах, в которых структура меню настраивается с несколькими деревьями регистрационных каталогов с использованием $OVwRegDir, ARF, применяемый по умолчанию, возможно, следует переместить на соответствующее ему место, чтобы обеспечить его доступность для пользователей. Более подробную информацию можно найти в главе 9 "Controlling Map Access" руководства Managing Your Network with HP OpenView Network Node Manager.

Долговременное применение такого специального опроса ограничивается местной практикой администрирования, в соответствии с которой ежедневно или еженедельно могут выключаться из работы многие или все приложения NNM. Приложения, запущенные через ovw, будут завершены при завершении ovw. Такого поведения можно избежать, если запускать xnmbrowser и xnmgraph вручную.

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

Несгибаемые энтузиасты командной строки указали бы на то, что данные SNMP можно собирать напрямую без графических утилит, используя команду snmpget:

$OV_BIN/snmpget device_name object-id >> /tmp/data_file

которая получает значение переменной SNMP object-id от устройства device_name и дописывает его в конец файла /tmp/data_file. Эта команда вставляется в shell-скрипт, который выполняется в цикле, пока не будет остановлен пользователем.

Для сбора исторических данных SNMP о производительности требуется доступ к GUI xnmcollect из меню Options:Data Collection & Thresholds. С помощью этого GUI администратор NNM и другие доверенные пользователи могут добавлять коллекции. Подробная информация содержится в разделе "Data Collection & Thresholds" главы 11 руководства Managing Your Network with HP OpenView Network Node Manager. Для добавления новых коллекций нужно выполнить следующие действия:

  • выбрать устройство, экземпляр mib и частоту выборки;
  • активизировать коллекцию;
  • немного подождать, пока соберутся некоторые данные;
  • просмотреть данные SNMP; сохранить их, если это требуется;
  • законсервировать коллекцию, пока она не потребуется снова.

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

Тестирование патча NNM

Наверное, стоит включить в свое расписание ежедневное посещение web-сайта HP OPenView по адресу http://www.openview.hp.com/, чтобы посмотреть, не появились ли какие-либо новые патчи, доступные для скачивания. Будем надеяться, что не придется каждый день тратить время на вставку нового патча для NNM.

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

"То, что не сломано, чинить не нужно".

При активном подходе все "заплаты" тестируются и устанавливаются, как только становятся доступными:

"Чините, пока не сломалось".

Осторожный подход предполагает анализ пригодности патча для конкретной системы. Если "заплата" не адресуется к проблемам, которые испытывают администраторы и пользователи системы, то ее вставка откладывается на более позднее время. Прежде чем действовать, можно просто подождать поступления сводного патча. Такая философия помогает избежать случайных побочных эффектов, которые могут быть привнесены патчем; ведь патчи обычно не подвергаются регрессивному тестированию в той же степени, что и полная версия продукта, хотя, конечно, они основательно тестируются перед выпуском.

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

< Лекция 11 || Лекция 12: 123 || Лекция 13 >