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

Поиск и устранение неисправностей NNM

< Лекция 12 || Лекция 13: 123 || Лекция 14 >
Аннотация: Использование журналов регистрации событий. Обращение к схеме по поводу родственных объектов. Непредвиденные изменения имен устройств. Ошибки автоматического размещения сетевой топологии. DHCP переназначает IP-адрес. Неудачи автоматического раскрытия.

Введение

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

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

Имена устройств в категории конфигурационных сигналов могут изменяться непредвиденным образом. Это часто указывает на изменения в DNS.

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

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

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

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

Проблемы GUI NNM могут возникать в тех случаях, когда эмулятор X-Windows не сконфигурирован должным образом для обеспечения ресурсов. Иногда пропадают установки переменных окружения, или имена в DNS не распознаются должным образом. В тех случаях, когда для использования NNM остается недостаточное число элементов цветной схемы, может наблюдаться мерцание цвета. В системах NNM, в которых не установлены патчи, сессия ovw иногда оказывается отсоединенной от своего дисплея X-Windows, но процесс не завершается, поскольку отсоединение не выявляется. Процесс циклится, пока не будет завершен автоматическим действием HP OV Operations или администратором NNM.

Использование журналов регистрации событий

Если сама система NNM ведет себя неправильно, то в процессе поиска и устранения неисправностей требуется сбор данных о проблеме, а все улики, касающиеся NNM, спрятаны в журналах регистрации событий. Это означает, что следует воспользоваться браузером журнала регистрации событий (для относительно недавних событий), архивированными файлами trapd.log (для версий, предшествующих NNM6.0) или базой данных событий, по обстановке. Если исторических данных оказывается недостаточно, следует увеличить размер базы данных событий или trapd.log. Нужно также исследовать netmon.trace и snmpCol.trace.

Если система NNM является управляющей станцией, то следует посетить некоторые накопительные станции, чтобы посмотреть, доступна ли родственная информация. Если система NNM является накопительной станцией, то нужно посетить ее управляющую станцию в поисках родственной информации и свериться с другими накопительными станциями, чтобы посмотреть, нет ли у них подобных проблем. Эта стратегия является составной частью методологии поиска и устранения неисправностей Kepner-Tregoe (K-T), которая учит собирать дополнительную информацию, наблюдая за тем, где существует проблема.

Обращение к схеме по поводу родственных объектов

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

Непредвиденные изменения имен устройств

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

  • имя DNS, соответствующее низшей части IP-адреса, иначе
  • системное имя MIB-2, если устройство поддерживает SNMP, иначе
  • IP-адрес, если он один, иначе
  • MAC-адрес устройства (в предположении, что действует раскрытие уровня 2).

Типичное изменение имени устройства часто соответствует изменению в базе данных DNS. Обратный поиск по IP-адресу в DNS ранее возвращал исходное имя устройства, а теперь возвращается какое-то другое имя. Это может быть абсолютно законно, а может быть административной ошибкой. Другое типичное изменение имени устройства происходит в том случае, когда именем вновь становится IP-адрес устройства. Это обычно случается, когда запись устройства удаляется из базы данных DNS, и устройство не поддерживает SNMP. Иначе именем устройства стало бы то, которое указано в группе system MIB-2.

Ошибки автоматического размещения сетевой топологии

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

Иногда NNM не размещает часть сети должным образом, потому что не может получить нужную информацию от дефектного агента SNMP. Например, коммутатор Ethernet может не обеспечить должным образом MIB моста, так что NNM будет не в состоянии правильно идентифицировать все его порты. Проблема раскрытия приводит к проблеме автоматического размещения.

Функция автоматического размещения NNM и вспомогательные подсети

Рис. 13.1. Функция автоматического размещения NNM и вспомогательные подсети

Рассмотрим интерфейс маршрутизатора с основным IP-адресом и тремя вспомогательными адресами. У этого интерфейса имеются четыре подсети. Предположим, что у нас есть четыре коммутатора Ethernet, подсоединенных к этому интерфейсу, и что каждый коммутатор конфигурируется на отдельной подсети. В логическом IP-представлении NNM каждый коммутатор будет вставлен в пиктограмму его подсети. Это означает, что ожидаемые физические соединения между коммутаторами не могут быть изображены должным образом. Чтобы исправить ситуацию, нужно назначить для всех четырех коммутаторов Ethernet IP-адрес на одной из подсетей.

Поскольку NNM тяготеет к тому, чтобы придерживаться старой конфигурационной информации, могут возникать трудности при радикальном изменении конфигурации устройства. Например, вставка новой платы в коммутатор Ethernet и его перезапуск часто приводит к перенумерации экземпляров MIB для портов. При следующей проверке конфигурации NNM может добавить все новые экземпляры, но не удалить старые. Иногда единственным способом избавить базу данных NNM от устаревших данных является удаление устройства и отправка ему запроса на отклик из системы NNM, чтобы вызвать его повторное раскрытие. Заметим, что поскольку это не затронет схемы, если только они не открыты, счетчики схем для этого удаленного объекта будут несогласованными.

IP-центрическая конструкция системы NNM приводит к тому, что для каждой подсети, раскрываемой NNM, создается свой контейнер. Если у интерфейса маршрутизатора имеются один основной адрес и три вспомогательных, то NNM покажет маршрутизатор, как имеющий четыре присоединенных подсети. С точки зрения IP это совершенно верно. Предположим, что дополнительные подсети нужны для поддержки растущего числа устройств. Каждое раскрываемое устройство помещается в свой контейнер подсети. Теперь предположим, что коммутаторам IP-адрес назначается случайным образом из четырех доступных подсетей. Как показано на рис. 13.1, NNM будет выводить физическую топологию в каждой подсети неправильно. Ситуацию можно исправить, переадресовав коммутаторы на одну и ту же подсеть. В этой подсети NNM будет в состоянии правильно вывести физическую топологию. Если некоторые коммутаторы адресуются внутри одной и той же подсети, то они будут соединены должным образом, но их представители будут размещены внутри пиктограмм других подсетей, что наносит ущерб возможности NNM демонстрировать правильную топологию.

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