Компания 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 >

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

Категория конфигурационных сигналов изобилует самородками ценной информации о конфигурационных проблемах в сети. Если требуется уделять внимание только одной категории сигналов, то стоит выбрать именно категорию конфигурационных сигналов. На мой взгляд, это одно из наиболее полезных средств 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 не генерирует конфигурационные сигналы для других, менее очевидных конфигурационных ошибок, таких как:

  • не определен никакой маршрут по умолчанию (выявляется с помощью SNMP);
  • асимметричная маршрутизация;
  • некорректные установки Fast Ethernet FDX/HDX;
  • некорректный DNS-сервер в конфигурации распознавателя;
  • RIP не активен.

Эти типы конфигурационных ошибок неочевидны, и для них нет никаких индикаторов в 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, то от этих систем впоследствии будут поступать предупредительные сигналы по поводу производительности. В число типичных сигналов ресурсов входят следующие:

  • интенсивность использования пространства свопинга;
  • интенсивность дискового ввода/вывода;
  • интенсивность загрузки ЦП;
  • ошибки LAN;
  • пропускная способность LAN;
  • интенсивность использование RAM.

Чтобы сопоставить эти сигналы с объемом пользовательской активности, может быть полезно запрограммировать 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-мониторинга:

  • передача данных от накопительной станции к управляющей станции;
  • зацикливание сессий ovw или других клиентов X-Windows;
  • syslogd должен быть активным;
  • все демоны NNM должны быть активны ( ovstatus ).

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

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