День с NNM

Введение

Обычный день с NNM не обходится без того, чтобы какой-нибудь пользователь не обратился к администратору с просьбой о сборе нестандартных данных SNMP о производительности. Часто такие пользователи могут получить нужные данные с помощью стандартного MIB-браузера и средства xnmgraph. При наличии потребности в коллекции долговременных данных может понадобиться добавить коллекцию исторических данных SNMP, поскольку средство xnmpgraph историю не сохраняет.

Тестирование патчей NNM может не быть ежедневным событием, но посещать web-сайт HP OpenView следует каждый день. Независимо от того, практикуется ли на узле активное или осторожное управление вставками, всегда следует тестировать "заплатки" в лаборатории, прежде чем вводить их во все действующие системы NNM.

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

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

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

Имеет значение и подтверждение правильности изменений операционной системы. После внесения патчей в ОС или модернизации RAM, диска, или адаптеров LAN следует проконтролировать настраиваемые параметры ядра, DNS и показатели производительности.

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

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

Обычным делом является также улаживание проблем раскрытия маршрутизаторов и интерфейсов маршрутизаторов.

Специальное управление производительностью

Хотя NNM обычно конфигурируется в расчете на сбор исторических данных SNMP о производительности, часто бывает нужно непредусмотренным заранее образом собирать другие данные о производительности. Часто требуется отслеживать конкретную переменную MIB для одного устройства в течение нескольких часов. Стандартным инструментом является GUI MIB-браузера. Нужно выделить пиктограмму устройства в окне схемы ovw, вызвать MIB-браузер из меню Tools:SNMP MIB Browser, перейти к интересующей переменной MIB и нажать кнопку Graph. Появится стандартный GUI xnmgraph с десятисекундным интервалом опроса переменной в реальном масштабе времени. При необходимости опрос можно сделать более активным, уменьшив интервал опроса до одной секунды. Эта установка легко выполняется с помощью разворачиваемого меню File:Configure in Data Collector. Поскольку во время этого динамического опроса данные не сохраняются в базе данных snmpCollect, к ним не применяются какие-либо действия по сокращению данных, которые могут периодически выполняться для ограничения объема исторических данных SNMP.

Заметим, что нет строгой необходимости запускать MIB-браузер из GUI ovw. GUI xnmbrowser можно запустить из командной строки следующим образом:

$OV_BIN/xnmbrowser -node device_name

Здесь предполагается, что переменная окружения $DISPLAY уже установлена правильно.

Если конкретное устройство предстоит подвергать такому исследованию ежедневно, то имеет смысл создать простое приложение над MIB ovw, которое можно добавить в структуру меню. MIB-приложение, созданное таким способом, будет похоже на Graph, а интервал опроса и MIB-переменная могут быть предопределенными. Заметим, что при создании MIB-приложения генерируется файл регистрации приложения (ARF). В тех средах, в которых структура меню настраивается с несколькими деревьями регистрационных каталогов с использованием $OVwRegDir, ARF, применяемый по умолчанию, возможно, следует переместить на соответствующее ему место, чтобы обеспечить его доступность для пользователей. Более подробную информацию можно найти в главе 9 "Controlling Map Access" руководства Managing Your Network with HP OpenView Network Node Manager.

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

Все данные SNMP, собранные xnmgraph, отбрасываются при завершении работы этой утилиты, так что следует обязательно сохранять текстовые данные с помощью меню File, а диаграммы – с помощью мгновенного снимка экрана.

Несгибаемые энтузиасты командной строки указали бы на то, что данные SNMP можно собирать напрямую без графических утилит, используя команду snmpget:

$OV_BIN/snmpget device_name object-id >> /tmp/data_file

которая получает значение переменной SNMP object-id от устройства device_name и дописывает его в конец файла /tmp/data_file. Эта команда вставляется в shell-скрипт, который выполняется в цикле, пока не будет остановлен пользователем.

Для сбора исторических данных SNMP о производительности требуется доступ к GUI xnmcollect из меню Options:Data Collection Thresholds. С помощью этого GUI администратор NNM и другие доверенные пользователи могут добавлять коллекции. Подробная информация содержится в разделе "Data Collection Thresholds" главы 11 руководства Managing Your Network with HP OpenView Network Node Manager. Для добавления новых коллекций нужно выполнить следующие действия:

Заметим, что если у администратора NNM имеется запись crontab для сокращения объема исторической базы данных, то эта процедура будет применяться также и к специальным историческим данным. Этой ситуации можно избежать только в том случае, если скрипт-чистильщик очень избирателен по отношению к узлам, на которых выполняется процедура, и не затрагивает специальные долговременные коллекции.

Тестирование патча NNM

Наверное, стоит включить в свое расписание ежедневное посещение web-сайта HP OPenView по адресу http://www.openview.hp.com/, чтобы посмотреть, не появились ли какие-либо новые патчи, доступные для скачивания. Будем надеяться, что не придется каждый день тратить время на вставку нового патча для NNM.

Существуют, по крайней мере, два подхода к управлению патчами. При осторожном подходе их вставка откладывается на некоторое время, возможно, навсегда:

"То, что не сломано, чинить не нужно".

При активном подходе все "заплаты" тестируются и устанавливаются, как только становятся доступными:

"Чините, пока не сломалось".

Осторожный подход предполагает анализ пригодности патча для конкретной системы. Если "заплата" не адресуется к проблемам, которые испытывают администраторы и пользователи системы, то ее вставка откладывается на более позднее время. Прежде чем действовать, можно просто подождать поступления сводного патча. Такая философия помогает избежать случайных побочных эффектов, которые могут быть привнесены патчем; ведь патчи обычно не подвергаются регрессивному тестированию в той же степени, что и полная версия продукта, хотя, конечно, они основательно тестируются перед выпуском.

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

Проверка корректного функционирования меню

Распространенной практикой является настройка структуры меню NNM. Одна из целей настройки меню – предотвращение внесения изменений в конфигурацию NNM некоторыми классами пользователей. Имеются в виду пользователи, которые являются операторами инструментария NNM. У таких пользователей часто имеется переменная окружения $OVwRegDir, определенная в стартовом shell-скрипте и указывающая на растущее от домашнего каталога дерево каталогов с регистрационными файлами, так что когда запускается NNM, ovw просматривает эту структуру каталогов вместо стандартного дерева, на которое указывает $OV_REGISTRATION.

Нужно вытерпеть утомительное регрессивное тестирование, чтобы убедиться в том, что настроенные меню работают должным образом для каждого типа пользователей:

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

Подтверждение правильности новой процедуры

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

Работает ли новая процедура на всех устройствах, или только на некотором подклассе устройств? Всегда ли эти устройства будут присутствовать на схеме NNM? Как быстро можно найти эти устройства на схеме? Имеется ли встроенное программное обеспечение устройства или требуется новая версия операционной системы? Зависит ли процедура от конкретной версии NNM? Могут ли все пользователи задействовать преимущества процедур? Можно ли усовершенствовать эту процедуру с помощью новой настройки меню? Следует самостоятельно протестировать процедуру. Всегда ли работает новая процедура или возможны "сюрпризы"? Зависит ли процедура от местных соглашений, таких, например, как стратегия наименования устройств?

Тестирование приложений сторонних поставщиков

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

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

Несколько независимых приложений могут конфликтовать. Например, они могут помещать конфликтующие записи в oid_to_sym и oid_to_type для одного и того же типа компонентов.

Подтверждение правильности изменений операционной системы

Операционная система (OС), в среде которой работает система NNM, не является статичной. Поставщик OС вносит изменения в код системы по различным причинам, в том числе, чтобы:

Прежде чем погружаться в стратегию активной модернизации, следует не забыть удостовериться в том, что любая модернизация ОС поддерживается NNM и используемыми приложениями сторонних поставщиков. Здесь следует быть осторожным. Можно, например, обнаружить, что некоторое приложение независимого поставщика, которое загружается в среде NNM 5.x, отказывается загружаться в среде NNM 6.x, но продолжает работать, если производится модернизация NNM 5.x до уровня NNM 6.x. Здесь "свеча сжигается с двух концов", поскольку со временем, вероятно, возникнет желание загружать непосредственно NNM 6.x или более позднюю версию, чтобы сократить время компоновки системы. В данном примере сторонний поставщик приложения, вероятно, не будет поддерживать свой продукт в среде NNM 6.x, и вы окажетесь в "чистилище" поддержки. Чтобы избежать такого сошествия в чистилище, нужно отслеживать на web-сайте HP совместимость конкретных версий продуктов OpenView.

При проведении модернизации ОС следует также убедиться в том, что после модернизации системные ресурсы NNM останутся доступными. В среде Sun Solaris ресурсы ядра определяются в текстовом файле /etc/system. В среде HP-UX для изменения параметров ядра можно использовать GUI SAM. В документе по инсталляции NNM разъясняются изменения в конфигурациях ядра, необходимые для нормального функционирования системы.

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

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

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

Если к системе добавляется дополнительный ЦП, то нужно убедиться в том, что его загрузка балансируется с другими ЦП. Если ОС не распознает новый ЦП, администратор должен быть первым, кто узнает об этом.

Наконец, если стандартный Ethernet LAN-адаптер для системы NNM меняется на адаптер Fast Ethernet, следует убедиться, что он согласуется с присоединенным портом коммутатора на предмет дуплексного соединения на скорости 100 Mbps. Если принимается решение добавить одну или несколько карт Fast Ethernet к системе HP-UX для увеличения производительности LAN, то следует учесть возможность установки дополнительного программного обеспечения автоматического агрегирования порта (APA, Automatic Port Aggregation). Это позволит назначить один IP-адрес для всех карт и сбалансировать их нагрузку. Нужно проверить, что балансировка нагрузки работает должным образом.

Проведение направленного раскрытия

Время от времени кто-то из исследователей будет говорить вам: "Мне требуется NNM-представление сети от A до B, в котором демонстрируются все устройства между этими узлами". Стандартные схемы, имеющиеся на прилавке NNM, не обеспечивают такое представление сети, возможно, потому, что оно охватывает область, большую, чем один домен управления, или потому, что пользователь хочет видеть устройства, которые обычно не раскрываются. Поэтому исследователь не может использовать стандартную систему NNM, и придется посетить испытательную лабораторию системы NNM и построить схему с нуля.

Следует начать с пустого seedfile и отключенного фильтра раскрытия. Необходимо вручную добавить устройства A и B и позволить NNM раскрыть локальную топологию. Воспользуйтесь своим знанием сетевой топологии и тщательно управляйте подсетями в каждой ее части, что позволит раскрыть промежуточную топологию. Во время управления подсетью работает автоматическое раскрытие, и раскрывается еще один уровень маршрутизаторов и подсетей. Следует продолжать управлять одиночными подсетями до тех пор, пока не будет определен единственный путь между A и B.

Если определить путь между A и B оказывается затруднительным, для ускорения можно воспользоваться командой traceroute от A к B, чтобы распознать все маршрутизаторы между этими узлами. Также может помочь команда NNM findroute, устанавливающая местоположение маршрутизаторов с помощью SNMP. Ее можно вызвать из ovw, щелкнув по пиктограмме A, щелкнув и одновременно нажав клавишу "control" на пиктограмме B и перейдя к выпадающему меню Fault:Locate Route via SNMP. Тогда findroute нарисует белую линию на каналах, графически представляющую маршрут между A и B. После этого нужно добавить в seedfile список найденных маршрутизаторов, остановить и запустить netmon, и NNM отобразит топологию между A и B, как и требовалось исследователю.

Обычным назначением такой направленной схемы является содействие изучению операционной производительности сетевых компонентов между A и B как части исследования планирования нагрузки.

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

Создание схемы специального назначения

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

Другие классы пользователей могут удовлетвориться стандартными схемами, если в представлении скрыты только некоторые устройства. Для этих пользователей можно создать схему путем обнаружения всех объектов с соответствующими атрибутами, выбора выделенных пиктограмм и скрытия всех пиктограмм.

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

NNM и маршрутизаторы

Распространенной проблемой является объединение системой NNM двух маршрутизаторов в один узел. Это обычно вызывается неверными данными DNS.

Может оказаться ненадежным и протокол HSRP, если в oid_to_type не установлены правильные флаги. В настоящее время (июнь 2000) при инсталляции менеджеров элементов Cisco не устанавливает флаги должным образом. Для маршрутизатора, на котором выполняется HSRP, должны быть установлены флаги "GD". В противном случае netmon будет непрерывно добавлять и удалять адрес HSRP.