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

День с NNM

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

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

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

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

На своем ли месте расположен каждый элемент меню?

Работают ли правила выбора для каждого элемента меню?

Загружены ли и работают ли реальные программы, которые выполняет меню?

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

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

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

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

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

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

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

  • загружаются надлежащие пиктограммы;
  • загружаются новые атрибуты и свойства устройств;
  • все MIB инсталлируются и загружаются должным образом;
  • новые элементы меню приложения ovw видны соответствующим пользователям;
  • новые демоны можно запускать и останавливать с помощью ovstart и ovstop ;
  • новые порты документируются в /etc/services ;
  • после инсталляции все еще имеется свободное дисковое пространство;
  • удовлетворяются требования к хранению данных приложения на диске.

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

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

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

  • поддерживать конкурентное преимущество;
  • соблюдать правила Y2K (все еще);
  • избегать морального старения;
  • исправлять ошибки кодирования;
  • добавлять новые возможности;
  • модернизировать такие подсистемы, как DNS или X-Windows.

Прежде чем погружаться в стратегию активной модернизации, следует не забыть удостовериться в том, что любая модернизация ОС поддерживается 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-адрес для всех карт и сбалансировать их нагрузку. Нужно проверить, что балансировка нагрузки работает должным образом.

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