Распределенное управление сетью

Введение

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

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

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

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

Чтобы эффективно управлять множеством систем NNM, рекомендуется загрузить в них агентов HP OV Performance Agents и HP OV Operations и обязать управлять ими центральную систему, в которой выполняются HP OV Operations и PerfView.

Управляющая станция инициирует связь с накопительными станциями. Эту станцию следует конфигурировать с использованием значений set-community-name накопительной станции, иначе связь не будет установлена. Для больших сетей можно отключить автоматическое раскрытие на управляющей станции и использовать seedfile для определения накопительных станций.

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

Время от времени база данных накопительной станции перестраивается. Это приводит к удалению управляемых устройств и объектов и их повторному импортированию. С помощью короткой и несложной процедуры можно восстановить подсхему Internet на управляющей станции в предыдущем состоянии.

Связь управляющей и накопительной станций

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

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

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

Для накопительной станции не требуется запуск демона ovrepld, но по умолчанию он запускается. Определение фильтра в файле filters указывает, какие объекты накопительная станция будет пересылать по запросам на управляющую станцию через SNMP. Этот фильтр определяется с использованием опции командной строки -f filter в файле ovtopmd.lrf. Это объясняется тем, что для связи с ovtopmd на накопительной станции в ovrepld на управляющей станции используются snmpget и snmpset. Не следует путать этот фильтр с фильтром раскрытия, которому соответствует другое определение фильтра в файле filters. Напомним, что фильтр раскрытия определяется в файле $OV_CONF/polling и устанавливается в GUI конфигурации опроса.

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

Накопительная станция по своей инициативе не предлагает никакой информации, если только она явно не запрашивается со стороны управляющей станции. Накопительная станция отвечает взаимностью только на явное предложение со стороны управляющей станции. Накопительная станция может быть связана с несколькими управляющими станциями. Накопительная станция может быть системой Windows NT, HP-UX или Solaris.

Управляющая станция инициирует связь со своими накопительными станциями и загружает разнообразные топологические "лоскутки" в единое сквозное представление корпоративной сети. Если домены управления накопительной станции определяются корректно, то каждый "лоскуток" плотно подгоняется к общему "одеялу". Отметим, что эти лоскутки могут перекрываться, потому что могут перекрываться домены.

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

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

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

Конфигурирование накопительной станции

Строка сообщества демона SNMP для доступа по чтению/записи должна быть явно сконфигурирована в файле /etc/snmpd.conf следующим образом:

get-community-name:	public
set-community-name:	secret

Выберите свою строку сообщества для set-community-name, но, пожалуйста, оставьте get-community-name как public. Кроме того, важно убедиться, что вы не нарушаете права доступа к файлу (значением кода должно быть 400, а владельцем должен быть root ). Следует остановить и снова запустить демон /usr/sbin/snmpdm, чтобы он считал изменения, внесенные в файл /etc/snmpd.conf.

Должен быть сконфигурирован фильтр топологии, который применяется ко всем объектам базы данных, экспортируемым из накопительной станции. В файле $OV_CONF/C/filters должна появиться запись следующего содержания:

NetBackbone "Networks and gateways/routers"
{ Routers || Networks }

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

Чтобы задействовать фильтр топологии NetBackbone, файл $OV_LRF/ovtopmd.lrf необходимо отредактировать следующим образом:

ovtopmd:ovtopmd:
OVs_YES_START:pmd,ovwdb,OVLicenseMgr:-O -f
NetBackbone:OVs_WELL_BEHAVED:15:

Параметр -f NetBackbone предписывает ovtopmd экспортировать только те объекты, которые проходят через этот фильтр на все управляющие станции. Непосредственно после внесения этого изменения в LRF-файл нужно выдать следующие команды:

$OV_BIN/ovstop
$OV_BIN/ovaddobj $OV_LRF/ovtopmd.lrf
$OV_BIN/ovstart -v

Если существует большая база данных объектов (около 20000 объектов), то для обработки отфильтрованной базы данных ovtopmd понадобится приблизительно 20 минут.

Какие устройства следует экспортировать

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

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

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

Некоторые стратегии определения того, какие устройства следует экспортировать на управляющую станцию, представлены в таблице 6.1.

Для конфигурирования фильтра экспорта необходимо знать правильно определенную согласованную характеристику, однозначно описывающую устройство. Безусловно уникальными являются OID, IP-адрес и имя выборки устройства. Наименование поставщика может быть слишком общим. Например, наименование поставщика Cisco пропустило бы любой продукт, производимый компанией. В число этих продуктов входили бы любые рабочая станция или сервер с адаптером, произведенным Cisco. Имеется также большое число стандартных характеристик, таких как isRouter, isInterface и isHub. Чтобы определить свойства объекта (такие как sysObjectID), нужно щелкнуть правой кнопкой мыши по его пиктограмме, получить всплывающее меню и выбрать элемент меню "Describe/Modify Object".

Сбор данных SNMP на управляющей станции

Управляющая станция не импортирует данные SNMP, собираемые и хранящиеся на накопительных станциях. С накопительной станции на управляющую распространяются пороговые события. Чтобы увидеть реальные данные, которые привели к пороговому событию, нужно запустить сессию ovw на соответствующей накопительной станции, определить на схеме местоположение интересующего устройства и запустить утилиту Grapher.

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

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

Мониторинг систем NNM с использованием HP OV Operations и HP OV Performance Agents

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

Если агенты HP OV Performance Agents загружаются и конфигурируются во всех системах NNM с центральной системы, то затем можно использовать HP PerfView для мониторинга всех критических ресурсов систем, среди которых:

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

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

Приложение HP OV Operations можно загружать в ту же самую систему мониторинга, где располагается PerfView. Тогда HP OV Operations может выявлять предупреждения HP OV Performance Agents. После этого можно считать, что создан MOM (Manager Of Managers). Эту систему следует расположить в корпоративном центре управления сетью.

Конфигурирование управляющей станции

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

Процесс конфигурации управляющей станции следует начинать с отключения функции автоматического раскрытия в меню опроса.

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

Накопительная станция должна быть представлена в базе данных объектов управляющей станции, прежде чем может быть установлена связь накопительной станции с управляющей станцией. При желании можно вручную добавить накопительные станции к схеме ovw управляющей станции, но предпочтительным может оказаться перечисление накопительных станций в seedfile. Не следует забывать, что при первом определении seedfile в $OV_LRF/netmon.lrf необходимо зарегистрировать изменения с использованием $OV_BIN/ovaddobj $OV_LRF/netmon.lrf, а затем остановить и снова запустить netmon. Если seedfile только редактируется, то требуется всего лишь остановить и перезапустить netmon.

Заметим, что по умолчанию netmon будет пытаться добавить имя системы NNM к списку адресатов доставки прерываний для каждого SNMP-агента, с которым он общается. Это значит, что для каждой накопительной станции в файле snmpd.conf будет существовать запись об адресате доставки прерывания. Если это вызывает проблемы при инсталляции, можно предотвратить такое поведение, включив флаг -N в файл netmon.lrf. Заметим, что, начиная с версии NNM 6.0, в netmon используется строка сообщества set-community-name SNMP, конфигурируемая посредством xnmsnmpconf при добавлении и удалении записи об адресате прерывания (вместо механизма, использовавшегося в предыдущих версиях, в котором игнорировались стандартные критерии аутентификации SNMP).

Как показано на рис. 6.2, управляющая станция должна быть сконфигурирована со строками сообществ set-communty-name накопительных станций.

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

$OV_BIN/ovtopodump -Lr / more

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

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

Затем установите связь с накопительной станцией на управляющей станции путем открытия окна shell и ввода команды

$OV_BIN/xnmtopoconf -manage collection_station_name

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

Для проверки состояния связи с накопительной станцией нужно ввести команду

$OV_BIN/xnmtopoconf -print collection_station_name

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

Добавление накопительной станции к действующей управляющей станции

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

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

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

Управляющую станцию нужно сконфигурировать таким же образом, как указывалось выше. Если теперь выполнить команду xnmtopoconf -manage new_collection_station, то в области хранения новых объектов подсхемы Internet должны наблюдаться новые устройства. Следует дождаться, пока управляющая станция произведет импортирование дополнительных устройств.

Менее чем за десять минут новые устройства могут быть помещены в их новые "дома".

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

Влияние перестройки накопительной станции

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

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

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