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

Введение

Использование 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 настолько просто в применении, что требуется упомянуть только две его разновидности:

Например, 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.

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

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

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

Базы данных объектов 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 приводит к следующим последствиям:

Очевидно, что чем меньше схем, тем лучше. Нет никакой особой причины иметь схему с именем 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" в режиме только чтения.

Анализ конфигурационных сигналов

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

Возможно, наименее волнующим конфигурационным событием является раскрытие нового устройства или нового интерфейса устройства. Более интересно изменение MAC-адреса, а если это случается снова и снова, то может сигнализировать о наличии дубликата IP-адреса, что является еще более незаурядным событием.

Другим конфигурационным событием является изменение имени устройства. Это событие предполагает изменение записи DNS для данного устройства, но если новое имя представляет собой IP-адрес устройства или его SNMP-имя, то DNS теряет имя устройства. Конечно, если имя устройства меняется правильным образом, то событие сигнализирует о хороших новостях.

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

Неверная маска подсети обычно обнаруживается в сетях, в которых сетевой адрес класса B разбивается на несколько подсетей класса C. Маской подсети для сети класса B по умолчанию является 255.255.0.0, и обычно это неправильное значение маски. Если сеть разделяется на подсети, стандартной маской подсети является 255.255.255.0. Иногда в маску подсети может быть некорректно установлено значение 255.255.252.0, 25.252.252.0 или некоторая другая перестановка, и в этом случае, прежде всего, вызывает удивление тот факт, что устройству удавалось правильно работать. Иногда это объясняется тем, что локальный маршрутизатор конфигурируется для поддержки Proxy ARP.

Подробную информацию о масках подсетей можно найти в разделе "Subnet Masks Consistently Configured" главы 4, и в разделе "Subnet Mask Issues" главы 5 руководства Managing Your Network with HP OpenView Network Node Manager.

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

NNM не генерирует конфигурационные сигналы для других, менее очевидных конфигурационных ошибок, таких как:

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

Анализ журнальных файлов и сигналов приложений

Демоны NNM журнализируют информацию в своих журнальных файлах, причем одни больше, другие меньше. Следует контролировать некоторые основные журнальные файлы в каталоге $OV_LOG, включая snmpCol.trace, netmon.trace и trapd.log.

Демон snmpCollect журнализирует интересные события в файле snmpCol.trace. Если возникает какая-либо проблема сбора данных SNMP от устройства, то подсказки можно найти именно в snmpCol.trace. Поэтому данный файл нужно периодически исследовать. Возможно, изменилась строка сообщества, и сбор данных от устройства приостановился. Возможно, сбор данных ограничивается тайм-аутами.

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

Файл trapd.log (до NNM 6.x) также может содержать ценные крупицы информации, поскольку многие сигналы являются "только журнализируемыми". Особенно интересными являются события, имеющие отношение к демонам NNM и приложениям. Непредвиденные разрывы соединений между приложениями и демонами NNM могут указывать на то, что у пользователей имеются проблемы, о которых они не сообщают. Эти сигналы могут не обнаруживаться в категории Application Alarm, если они являются "только журнализируемыми".

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

Анализ данных HP OV Performance Agents

Если во всех системах NNM запускаются агенты HP OV Performance Agents, и для управления ими используется HP OV Operations, то от этих систем впоследствии будут поступать предупредительные сигналы по поводу производительности. В число типичных сигналов ресурсов входят следующие:

Чтобы сопоставить эти сигналы с объемом пользовательской активности, может быть полезно запрограммировать HP OV Operations для отслеживания числа сессий ovw в каждой системе NNM. Опыт подсказывает, что успешное развертывание NNM привлекает больше пользователей, чем первоначально ожидалось. Если сигналы ресурсов возникают в рабочие часы слишком часто, и число активных сессий превышает ожидания, то может быть оправдана некоторая настройка платформы в виде подключения дополнительных ЦП, RAM или дисков.

Наконец, на очереди замечание об LAN-адаптерах системы NNM. В новых инсталляциях Fast Ethernet часто проявляется фаза, в течение которой процедура автоматического согласования времени между адаптером Fast Ethernet и его портом коммутатора возвращается к полудуплексному режиму на скорости 10 мегабит в секунду. Чтобы предотвратить это, следует написать простой скрипт для проверки установок адаптера системы NNM и порта коммутатора и сделать его записью crontab.

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

Изучение и обновление сигналов HP OV Operations

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

По мере накопления практического опыта и разрешения проблем NNM может оказаться целесообразным автоматизировать с использованием HP OV Operations и дополнительные проверки.