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

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

Способность 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 без всяких открытых схем.

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

  • В ARP-кэше на узле, поддерживающем SNMP, отсутствует данный IP-адрес;
  • IP-адрес удален из ARP-кэша как устаревший;
  • проверке устройства демоном netmon препятствует потеря пакетов;
  • устройство не может обмениваться данными за пределами своей подсети;
  • устройство выключено;
  • устройство не работает семь дней и удаляется;
  • не удается найти удаленный конец последовательной линии, если указана опция -R ;
  • у устройства был временный стек IP, который теперь выгружен;
  • устройство не использует IP;
  • коммутатор или мост отфильтровывает MAC-адрес устройства;
  • неверный ACL SNMP на устройстве блокирует доступ;
  • на устройстве конфигурируется неизвестная строка сообщества;
  • достигнут предел в 250 узлов при наличии лицензии на 250 узлов.

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

Иногда проблема системы проявляется спустя шестьдесят дней после истечения срока действия лицензии 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).

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