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

Введение

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

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

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

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

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

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

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

DHCP переназначает IP-адрес

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

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

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

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

Этот GUI позволяет снабдить NNM специальными знаниями об устройствах, IP-адреса которых находятся под управлением DHCP. После проверки блока DHCP Polling Options необходимо указать имя DHCP-фильтра в файле $OV_CONF/C/filters и при желании разрешить NNM удалять назначенный через DHCP IP-адрес устройства, которое не работает слишком долго.

Понятно, что для устранения таких проблем можно привлечь поддерживающие DHCP средства NNM 6.1. Прежде всего, следует определить в файле $OV_CONF/C/filters фильтр, который соответствует диапазону IP-адресов, выделенных для назначения через DHCP. После этого нужно войти в меню Options:Network Polling Configuration и включить этот фильтр DHCP. Сервер DHCP должен быть сконфигурирован так, чтобы пересылать в систему NNM прерывания SNMP OV_DHCP_Alloc и OV_DHCP_Release, где их будет получать netmon. В результате мы получим сокращение конфигурационных сигналов, касающихся DHCP-устройств. NNM будет удалять IP-адреса устройств, у которых IP-адреса соответствуют фильтру DHCP, если эти устройства находятся в нерабочем состоянии в течение указанного времени. Этим интервалом времени можно управлять, используя команду

xnmpolling -delDhcpAddrTime interval-spec

и он приводится в действие командой

xnmpolling -delDhcpAddrsOn

Это действует при наличии опции -dhcpFiltName filter-name. Все упомянутые средства можно включать и отключать с помощью команды:

xnmpolling -dhcpHandlingOn

GUI xnmpolling сохраняет свои конфигурационные данные в файле $OV_CONF/polling. См. примерный снимок экрана конфигурирования DHCP с использованием команды xnmpolling на рис. 13.2.

Неудачи автоматического раскрытия

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

Напомним, что ответственным за процесс автоматического раскрытия является демон netmon. Он руководствуется необязательным параметром seedfile в файле $OV_LRF/netmon.lrf, который читает каждый раз, когда стартует. Файл seedfile часто используется для определения исходного домена управления во время первого раскрытия. Позже в seedfile можно добавлять записи, чтобы расширить домен управления. Конструктор схем или администратор NNM могут также расширять домен управления в интерактивном режиме. Автоматическое раскрытие совершается только в пределах домена управления, то есть в управляемых подсетях. Файл netmon.noDiscover содержит IP-адреса, которые netmon будет игнорировать, если они ему встретятся.

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

Если устройство выключено или недостижимо в то время, когда раскрывается его IP-адрес (возможно, исходя из записи в некотором ARP-кэше), то netmon не может подтвердить существование устройства, и оно не раскрывается.

Иногда кажется, что устройство осталось нераскрытым, когда в действительности оно раскрыто. Его пиктограмма скрыта глубоко внутри контейнера сегмента, потому что netmon не может общаться с SNMP-агентом устройства. Это препятствует раскрытию демоном netmon устройства, которое в действительности является коммутатором или маршрутизатором, так что оно не может отображаться на представлениях подсети или подсхемы Internet. Решение состоит в том, чтобы убедиться, что SNMP-агент устройства функционирует, что NNM конфигурируется с соответствующей строкой сообщества, что список доступа устройства разрешает системе NNM взаимодействовать с сервисом SNMP, и что флаги в oid_to_type для этого компонента являются правильными и полными (например, для концентратора должен быть установлен флаг "H").

Ответственность может лежать на "болезни пальцев" (ошибке оператора). Возможно, что пиктограмма раскрытого устройства была скрыта оператором. Чтобы проверить, раскрыто ли устройство, следует воспользоваться командой ovtopodump -RISC device_name.

После того, как устройство вручную удаляется со схемы, оно обычно раскрывается повторно с помощью ping. Но если другие закрытые схемы содержат данный объект, то его счетчик ссылок может не стать нулевым, и повторное раскрытие не произойдет. Это хороший довод в пользу принятия стратегии единственной схемы. Решение состоит в том, чтобы оставить все схемы открытыми в режиме чтения/записи, или выполнить команду ovw -mapcount -ruvDR от имени root без всяких открытых схем.

Проблемы раскрытия вызываются также следующими обстоятельствами:

Выявление предстоящего истечения лицензии

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

$OV_BIN/xnmtopoconf -test station_name

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

Проблемы GUI NNM в UNIX-системах

Система X-Windows на пользовательских рабочих станциях под управлением ОС UNIX должна быть соответствующим образом сконфигурирована для нормального функционирования. Часто пользователи жалуются на то, что GUI – обычно GUI ovw – не может соединиться с дисплеем. Это может быть вызвано тем, что неправильно установлена или не установлена переменная $DISPLAY, что имеются недостаточные права доступа для связи с дисплеем (это может исправить xhost ), что имя дисплея не может быть разрешено с помощью локального распознавателя DNS, или тем, что отсутствует IP-маршрут между системой NNM и рабочей станцией, поддерживающей эмулятор X-Windows.

Активная сессия ovw может быть неожиданно прервана из-за того, что заблокирована рабочая станция пользователя, пользователь вышел из среды X-Windows, не придерживаясь должных процедур, или заблокирован эмулятор X-Windows. Иногда этот тип отказа не связан с сессией ovw, которая продолжает попытки ввода/вывода на свой дисплей. В системах NNM без установленных патчей это может привести к зацикливанию сессии ovw, которая может полностью занять ЦП. Зацикленный процесс должен быть завершен вручную его владельцем или от имени root. Можно запрограммировать HP OV Operations для отслеживания такого поведения и выполнения команды завершения (типа kill -9 ovw_pid ).

Если физический размер монитора слишком мал, то некоторые громоздкие GUI не могут отображаться полностью. В этом случае не будет видно кнопок в нижней части окна. Рекомендуется использовать монитор с разрешением 1280x1024, или, по крайней мере, должен быть доступен такой виртуальный экран, который может прокручиваться, когда физические размеры монитора меньше рекомендованных.

Иногда эмулятор X-Windows не поддерживает необходимые шрифты. Возможное решение состоит в выполнении полной инсталляции программного обеспечения или его модернизации до самой последней версии. Другая возможность состоит в конфигурировании сервера шрифтов X-Windows в сети и конфигурировании эмулятора X-Windows для его использования. Обходным путем является изучение файла установок по умолчанию приложения, поиск ресурсов шрифтов, определение доступных заменяющих шрифтов, создание в домашнем каталоге пользователя приложения X-Windows resource_file, конфигурирующего эти новые шрифты, и использование команды xrdb resource_file для активизации ресурсов. При каждом следующем вызове приложение будет использовать замененные шрифты и прекратит выдавать предупреждающие сообщения.

Могут встречаться проблемы цвета, когда ovw выполняется на дисплее, в общедоступной схеме цветов которого содержится недостаточно свободных цветов. Как кажется, это часто случается, когда ко времени запуска ovw уже работает web-браузер. Выход из положения состоит в том, чтобы до запуска ovw завершить работу браузера и всех других приложений, использующих много цветов.

Наконец, при работе GUI NNM могут возникать проблемы с производительностью. Они могут быть связаны с недостатком доступных ресурсов на рабочей станции, лишающим эмулятор X-Windows необходимой RAM, циклов ЦП или сокетов TCP. Следует попробовать завершить некоторые приложения, чтобы освободить оперативную память и центральный процессор, и сконфигурировать эмулятор X-Windows таким образом, чтобы использовалось большее число сокетов TCP (ограничением по умолчанию является всего 16 сокетов, что обычно недостаточно для использования NNM).