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

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

< Лекция 10 || Лекция 11: 123 || Лекция 12 >
Аннотация: Автоматизация резервного копирования и его область действия. Контейнеры для вновь раскрытых устройств. Обновление MIB. Удаление нежелательных схем. Анализ конфигурационных сигналов, журнальных файлов, сигналов приложений, данных HP OV Performance Agents.

Введение

Использование crontab в UNIX является идеальным способом автоматизации задач периодического технического обслуживания NNM. Для минимизации операционных воздействий выполнение многих из этих задач назначается на нерабочие часы. Любой результат, производимый этими автоматизированными задачами, может быть зарегистрирован или отправлен по e-mail администратору NNM. Некоторое повседневное сопровождение, такое как настройка схем, остается задачей, выполняемой вручную.

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

Устранение дефектов баз данных необходимо автоматизировать и выполнять, по крайней мере, еженедельно. Эти действия нарушают функционирование NNM и должны выполняться в нерабочие часы. Запуск команд ovw –mapcount –ruvDR и ovtopofix –cshv можно автоматизировать путем использования записи crontab.

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

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

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

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

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

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

Анализ данных HP OV Performance Agents помогает определить потребность в модернизации аппаратного обеспечения системы NNM. Эту задачу лучше всего выполнять еженедельно, применяя PerfView для изучения диаграмм использования ресурсов.

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

Использование записей crontab для автоматизации резервного копирования

Средство cron ОС UNIX является "пуленепробиваемым", гибким, простым для использования и надежным механизмом планирования периодических задач, таких как резервное копирование. Поскольку владельцем многих файлов NNM является root, скрипт резервного копирования должен запускаться записями crontab, принадлежащими root. Средство cron настолько просто в применении, что требуется упомянуть только две его разновидности:

  • crontab –l выдает список записей crontab ;
  • crontab file создает записи crontab из файла file.
Таблица 11.1. Первые пять полей записи файла crontab
Поле Допустимые значения
минута 0-59
час 0-23
день месяца 0-31
месяц 0-12 (или названия, такие как jan, feb, mar, …, dec)
день недели 0-7 (0 или 7 представляет Sunday) (или названия, такие как sun, mon, …sat)

Например, file мог бы содержать следующие строки:

# run five minutes after midnight, every day
5 0 * * * $HOME/bin/nnm_backup_job >> $HOME/tmp/out 2>&1

Первые пять полей во второй строке представляют время (см. таблицу 11.1), а оставшаяся часть строки является командой, предназначенной для выполнения в соответствующее время. Эта команда должна вызывать ovbackup.ovpl (NNM 6.x).

Определение области действия резервного копирования

В таблице 11.2 определяются каталоги, подлежащие резервному копированию. Это хорошая точка отсчета для определения области действия резервного копирования. Заметим, что для NNM 6.x в действительности не приходится иметь со всем этим дело, поскольку данная информация уже содержится в ovbackup.ovpl. Этот скрипт согласует записи базы данных, производит ее резервную копию в определенном месте и журнализирует результаты резервного копирования в файле $OV_TMP/ovbackup.log. Более подробную информацию см. на странице оперативного руководства по ovbackup.ovpl.

Здесь уместно задать вопрос: "Зачем вообще производить резервное копирование данных NNM?" В конце концов, при наличии всего лишь файла seedfile и файла настройки схем всего за несколько часов сеть может быть заново раскрыта, а схема восстановлена. Если предположить, что систему NNM можно восстановить из резервной копии примерно за 10 минут, то ответить на этот вопрос можно так: "потому что это увеличивает уровень доступности системы NNM". Другой ответ может состоять в том, что желательно восстанавливать такую историческую информацию, как события и данные snmpCollect.

Таблица 11.2. Каталоги, подлежащие резервному копированию
Каталог Содержание
$OV_DB/openview Базы данных схем, объектов и топологии
$OV_DB/snmpCollect Исторические данные SNMP
$OV_DB/eventdb База данных событий
$OV_CONF Конфигурационные файлы
$OV_LRF Локальные регистрационные файлы
$OV_REGISTRATION Регистрационные файлы приложения
$OV_DB/ Аналитические файлы
$OV_FIELDS Регистрационные файлы полей
$OV_SYMBOLS Пиктограммы
/var/opt/OV/tmp Файлы настроек схем
$OV_SNMP_MIBS Необработанные и собранные файлы MIB

Некоторые системные администраторы твердо придерживаются принципа KISS ("не усложняй, болван") . Вместо того чтобы копировать файлы определенных каталогов (и идти на риск потери информации), они предпочитают копировать весь раздел диска ( /opt/OV ) целиком, сжимать файл резервной копии и передавать его по сети в резервную систему. Какой бы метод резервного копирования не был выбран, следует помнить, что в NNM применяются разреженные файлы данных, которые кажутся огромными (в масштабе гигабайта), но в действительности в них используется только несколько сотен мегабайт. Средство резервного копирования должно хорошо справляться с этим типом файла.

Более подробную информацию о резервном копировании можно найти в главе 6 руководства Managing Your Network with HP OpenView Network Node Manager.

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