OpenView Network Node Manager

Передовой опыт применения NNM

Показывать лекцию целиком

Введение

Эта лекция представляет собой сводку практических советов, приводившихся на протяжении книги.

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

HP OV Operations представляет собой отличный инструмент для управления менеджерами. Это средство позволяет автоматизировать большое число задач системного мониторинга для увеличения эффективности управления. Оно также сокращает время простоя, позволяя распознать проблемы до того, как они смогут повлиять на сообщество пользователей.

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

Управление проектом помогает поддерживать основное направление проекта, выявляя ситуации, когда деятельность на критическом участке подвергает риску весь календарный план.

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

Оценка размеров платформы

Первую оценку можно сделать с использованием публикации HP Network Node Manager Performance and Configuration Guide. Этот документ обеспечивает методологию оценки размера системы, основанную на рассмотрении следующих показателей:

  • число объектов;
  • число узлов;
  • накладные расходы накопительной станции;
  • накладные расходы управляющей консоли;
  • число сессий ovw ;
  • число сессий, основанных на web;
  • объем собираемых данных SNMP;
  • частота возникновения сигналов;
  • резервные копии;
  • частота опроса;
  • накладные расходы баз данных;
  • схемы по требованию.
  • Несомненно, это руководство устаревает по мере выпуска новых версий NNM и новых патчей. Безопасный подход состоит в том, чтобы получить первую оценку с использованием руководства, удвоить результаты и предусмотреть их возрастание. Следует помнить, что производительность компьютерной системы определяется объемом ресурсов. Хорошо, когда загрузка ресурсов системы не является предельной, поскольку это означает, что система работает настолько быстро, насколько это возможно.

    Примеры оценки размеров системы NNM
    Система Сети Сегменты Узлы Интерфейсы Маршрутизаторы RAM Мб ЦП База данных Мб Дисковые устройства Пользователи
    1 393 1846 1450 61344 111 3328 4 263 4 9
    2 340 805 803 27399 92 2560 3 94 2 10
    3 619 1149 782 16033 125 1024 2 81 2 8
    4 390 1260 1324 45006 66 1792 3 212 3 11
    5 400 1666 1351 20643 127 1024 2 105 2 8
    6 146 774 663 19469 29 1024 2 73 2 8
    7 131 180 179 5111 35 1024 2 20 2 3
    Управляющая станция 2492 11 643 8570 634 1024 2 80 3 8

    Некоторые из входных параметров приведенной выше методологии требуют детального знания числа управляемых объектов. Как это можно оценить? Следует воспользоваться 60-дневным бесплатным оценочным периодом, предоставляемым HP, загрузить систему на доступный компьютер и создать базисный счетчик объектов для своей сети (см. в таблице 15.1 сводку эксплуатационных данных для оценки размеров системы NNM).

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

  • число процессоров;
  • объем RAM;
  • скорость адаптера LAN;
  • объем дискового пространства;
  • число дисков в дисковом массиве.
  • Было бы ошибкой развертывать систему NNM, которую нельзя быстро модернизировать в эксплуатационном режиме. Следует отслеживать системные ресурсы NNM с использованием агента HP OV Performance Agents и еженедельно оценивать данные с помощью PerfView Analyzer. Это позволяет планировать модернизацию заранее, до того как пользователи начнут жаловаться на длительное время ответа.

    HP OV Operations управляет системами NNM

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

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

  • убеждаться, что схема, доступная в режиме чтения и записи, открыта и работает должным образом;
  • проверять, используется ли файл syslog /var/adm/messages для журнализации симптомов известных проблем;
  • выявлять и останавливать зацикленные процессы, особенно для X-клиентов.
  • Поскольку HP OV Operations также отслеживает сигналы HP OV Performance Agents, возможно, потребуется исследовать предустановленные пороговые параметры и изменить их таким образом, чтобы они отражали ваш собственный опыт. Иначе вам предстоит получать много нежелательных сигналов по поводу условий, которые, исходя из вашего опыта, не ухудшают время реакции системы для пользователя.

    (рис 15.1) Окно HP OV Operations для систем NNM

    В этом примере показаны три системы NNM под управлением HP OV Operations. Цвет пиктограммы указывает на состояние отслеживаемых компонентов каждой системы.

    Управление меню

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

    Следующим трудным участком является процесс поиска для каждого элемента меню стандартных файлов регистрации приложений (ARF) NNM, расположенных в каталоге $OV_REGISTRATION, создания дополнительных структур каталога для каждого типа пользователей (в $OVwRegDir ) и соответствующего редактирования файлов ARF. Заметим, что необходимо рассматривать и самодельные элементы меню, а также все дополнительно обеспечиваемые приложения, такие как HP NetMetrix и CiscoView, поскольку они тоже привносят меню в NNM. На практике руководствоваться одной этой краткой сводкой опасно, так что рекомендую обратиться к главе 9 "Using ARF Files to Control Menu Choices" руководства Managing Your Network with HP OpenView Network Node Manager.

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

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

    Управление проектом

    Для крупных инсталляций NNM требуется воспользоваться услугами менеджера проекта, который будет следить за выполнением плана. Менеджер проекта (Project Manager, PM) не обязательно должен непосредственно управлять внедрением NNM. Как минимум, PM следит за графиком, сравнивает его с реальным ходом событий и поднимает красный флажок, когда событие на критическом участке пути не завершается вовремя. PM часто приходится собирать информацию от членов команды, разработчиков, инсталляторов, пользовательского сообщества и руководства. PM также отслеживает своевременную сдачу технических требований, руководств по инсталляции и учебных материалов.

    Управление проектом – это и должность, и роль. В крупных проектах по внедрению NNM работа может занимать большую часть времени сотрудника, так что требуется полноценная должность PM. В менее крупных проектах руководство проектом NNM может считаться ролью.

    Выделенный системный администратор

    Системный администратор выполняет большое количество разнообразных технических задач для поддержания проекта развертывания NNM. Вот эти задачи:

  • инсталлировать на платформе наиболее свежую версию операционной системы;
  • конфигурировать сетевые подсистемы;
  • добавлять пользователей и управлять учетными записями;
  • осуществлять тонкую настройку системы;
  • конфигурировать дисковые массивы;
  • модернизировать аппаратуру;
  • разрабатывать скрипты копирования и восстановления;
  • управлять системой, на которую производится резервное копирование;
  • писать скрипты инсталляции для самодельного кода;
  • взаимодействовать с разработчиками;
  • находить и устранять погрешности инсталляций;
  • скачивать, вносить и тестировать патчи NNM и ОС;
  • инсталлировать агентов HP OV Operations и разрабатывать специальные скрипты мониторинга;
  • решать проблемы с учетными записями пользователей и X-Windows;
  • настраивать графическую среду.
  • После развертывания NNM тот же системный администратор продолжает обеспечивать важную функцию поддержки.

    Примеры использования NNM

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

    Глобальная производственная компания

    Крупная производственная компания зависит от своей основной IP-магистрали, обеспечивающей связь с сотнями узлов, расположенных по всему миру. Развертывание системы NNM на каждом физическом узле было бы неэффективно с точки зрения стоимости, так что вместо этого выбирается 30 узлов с персоналом поддержки локальной сети. Каждый узел получает накопительную станцию, а два узла – управляющие станции. Большая часть сообщества пользователей NNM обращается к своим системам NNM с помощью эмулятора X-Windows, работающего на системах Windows. Некоторые пользователи предпочитают компьютеры Macintosh с Mac X или системы Linux, поддерживающие встроенное программное обеспечение X-Windows. Системные администраторы пользуются встроенным программным обеспечением X-Windows своих рабочих станций UNIX для доступа к удаленным системам NNM.

    Системы NNM подготавливаются в корпоративном отделе IT и поставляются на места назначения в соответствии с графиком. Каждая система собирается с использованием текущей версии ОС, соответствующих патчей ОС и NNM и дополнительных приложений от независимых поставщиков с их текущими патчами. Поскольку эти системы основываются на ОС UNIX, они конфигурируются как реплики NIS+, содержащие всю информацию учетных записей пользователей. Подразумевается, что имеется возможность обратиться с любого узла к системе NNM другого узла для поддержки и резервного копирования.

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

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

    Администратор центральной системы IT может управлять всеми удаленными системами NNM с использованием стандартного интерфейса X-Windows. Если проблемы производительности WAN ограничивают применение X-Windows, то можно задействовать простые и ненакладные сессии telnet. На случай возникновения в системе UNIX сложных аварийных ситуаций терминальный сервер соединяется кабелем с последовательным портом для обеспечения прямого доступа к диагностическому порту. Система поставляется с загрузочным CD-ROM в качестве альтернативного загрузочного устройства.

    Каждая система NNM выполняет сессию VNC (Virtual Network Computing) и поддерживает сессию ovw с чтением и записью схемы. Системные администраторы и администраторы NNM могут подсоединяться к этой сессии VNC с целью поддержки схем.

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

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

    Компания по добыче природных ресурсов

    У компании по добыче природных ресурсов имеются узлы по всей Северной Америке. Выбирается централизованное управление всей сетью с использованием одной большой системы NNM, размещенной в корпоративном центре данных. Эта UNIX-система предназначается для поддержки 30 одновременно работающих пользователей, поэтому устанавливается максимальное число ЦП и максимальный объем поддерживаемой RAM. В другом месте инсталлируется небольшая резервная система NNM.

    Чтобы не впадать в зависимость от SNMP-опроса в стиле snmpCollect для управления производительностью, во всех критических точках LAN и WAN устанавливаются датчики RMON. HP NetMetrix управляет датчиками и загружает данные о производительности. Датчики также генерируют пороговые сигналы. Это позволяет избежать накладных расходов системы NNM при сборе данных о производительности и обеспечивает более гибкое управление собранными данными.

    Персонал IT проходит весь формальный курс обучения HP OpenView и нанимает консультанта на две полных недели для инсталляции NNM, управления раскрытием сети, настройки сбора данных SNMP, обучения персонала и документирования всей стратегии управления и реализации сети.

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

    Биоинженерная компания

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

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

    Управление производительностью основного маршрутизатора состоит в простом сборе статистических показателей интерфейсов на всех портах. Это позволяет не нагружать каналы WAN трафиком опроса.

    Местная компания по производству автомобилей

    Местная компания по производству автомобилей располагается в границах одного штата и имеет шесть заводов-изготовителей, один центр данных и офис корпорации. NNM используется для управления сетевой инфраструктурой и критическими серверами в каждом узле. Конфигурируется DNS-сервер на одной системе NNM, установленной на небольшой рабочей станции с ОС UNIX.

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

    Обеспечивается обучение на месте для пользователей и персонала IT, включающее работу с сетью, основы DNS и NNM. Пользователи действительно выигрывают от обучения на собственной сети с использованием своей системы NNM. Учебные материалы включают толстый рабочий журнал обучаемого пользователя.

    То, что в ведении отдела IT находится DNS всей компании, оказывает влияние на разработчиков приложений. Их приложения могут не работать, поскольку в коде используются имена в стиле /etc/hosts, а не полностью уточненные доменные имена. Требуется некоторое обучение, чтобы разработчики поняли, что пользователь может располагаться в одном поддомене, тогда как целевой сервер располагается в другом домене.

    Общественный колледж

    У общественного колледжа имеется несколько кампусов. Для управления сетью колледжа была приобретена система NNM, запускаемая на существующей рабочей станции с ОС UNIX. Поскольку в колледже использовалось исключительно оборудование от HP, система NNM могла совершенно безошибочно автоматически размещать каждую подсеть, используя точную корпоративную MIB от HP. Это происходило до появления индустриальных стандартов для MIB повторителей и мостов.

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

    Национальная консалтинговая компания

    У консалтинговой компании имеется сеть, содержащая массу сайтов, для организации локальных сетей которых используются маршрутизаторы Cisco и концентраторы HP. NNM инсталлируется на существующей рабочей станции с ОС HP-UX, конфигурируются необходимые строки сообществ маршрутизаторов и производится подготовка к ручному управлению NNM для раскрытия сети. К сожалению, обнаруживается, что маска подсети рабочей станции установлена неправильно. В системе NNM предполагалось, что вся сеть класса B была неструктурированной, поэтому система готовилась к раскрытию всей сети. Эта единственная подсеть изображалась в виде колеса, плотно набитого пиктограммами. После исправления маски подсети системы NNM автоматическое раскрытие проходит нормально.

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

    Любопытно, что сеть работала нормально, несмотря на то, что для многих устройств не было записей в таблице маршрутизации. Оказалось, что в маршрутизаторах Cisco имелись proxy-ARP, задействованные по умолчанию. Это позволяло сети работать.

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

    Небольшая техническая фирма

    У этой небольшой фирмы имеется единственное двухэтажное здание. Единственная LAN обеспечивает доступ каждой инженерной рабочей станции к нескольким файловым и принтерным серверам. Принтерный сервер управляет принтерами LaserJet для печати стандартной документации и крупноформатными плоттерами для производства технических чертежей. Каждый сервер обслуживает примерно дюжину рабочих станций.

    NNM инсталлируется на существующей рабочей станции с ОС UNIX, и каждая система в этой одиночной подсети раскрывается безо всяких усилий. Преобразования имен в адреса обеспечивает файл /etc/hosts.

    NNM отслеживает только несколько дюжин систем, и можно установить односекундный интервал опроса без опасений за перегрузку чего бы то ни было. Существование этой небольшой фирмы зависит от работоспособности LAN, и желательно быстрое уведомление о любых отказах, чтобы сократить среднее время восстановления (MTTR). Администратор LAN использует X-Windows для доступа к NNM и имеет возможность начать работать над проблемой до того, как к нему обратятся с жалобами пользователи.

    Всемирная компьютерная компания

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

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

    NNM конфигурируется таким образом, чтобы опрашивать каналы WAN с целью управления нагрузкой. Поскольку каждая линия является дуплексной (FDX), отбираются только статистические показатели входных портов маршрутизаторов. Это вдвое уменьшает объем собираемых данных.

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

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

    Вернуться к учебному плану