Определение домена управления

Введение

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

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

География часто совмещается с расположением деловых структурных единиц, так что простое перечисление всех подсетей по географическому принципу определяет домен управления. Этот подход встречается чаще всего. Перечисление всех маршрутизаторов по географическому принципу в seedfile – это, как правило, первый шаг в процессе определения домена управления.

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

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

Вооружившись этой стратегией, можно подготовить свои конфигурационные файлы для первого раскрытия. К таким файлам относятся netmon seedfile, фильтр раскрытия, фильтр DHCP, командная строка xnmsnmpconf файла строк сообществ, параметры опроса для xnmpollin и файл netmon.noDiscover.

Определение общности интересов в сети

Общность интересов можно определять на основе сквозных систем, которые используются в данной деловой структурной единице. Например, сетевые менеджеры узла интересуются своим сообществом концентраторов, мостов, коммутаторов, мостов-маршрутизаторов и маршрутизаторов. Менеджер WAN в данной стране интересуется сообществом отечественных компаний, владеющих линиями связи, сервис-провайдеров и действующих распределительных маршрутизаторов. Менеджеры web-сайтов интересуются своим сообществом серверов, дисковых устройств SAN и принтеров. Администраторы e-mail существуют в своем сообществе серверов электронной почты и шлюзов, а также наблюдают за DNS, поскольку эта система обслуживает записи Mail Exchange (MX). Менеджеры файловых и принтерных серверов работают внутри своего сообщества по интересам. Общностью интересов инженерных групп являются их рабочие станции, серверы и сетевые принтеры.

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

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

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

В качестве другого примера рассмотрим персонал сети, который управляет маршрутизаторами доступа в Internet. Они осуществляют мониторинг использования центрального процессора этими маршрутизаторами, у которых нередко имеются огромные таблицы маршрутизации. При обработке каждого SNMP-запроса элемента таблицы маршрутизации происходит интенсивное использование ресурса ЦП. Излишние запросы таблиц маршрутизации, поступающие от NNM (стандартный аспект автоматического раскрытия), могут поднять уровень загрузки ЦП маршрутизатора почти до 100%. Эту загрузку трудно снизить, указав, что процесс SNMP на маршрутизаторе имеет низкий приоритет. Короткие всплески нагрузки центрального процессора из-за операций SNMP допустимы, но длительная интенсивная нагрузка – это плохо, так как она может скрывать реальные проблемы интенсивного использования ЦП, подобные тем, которые вызываются колебаниями маршрутов.

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

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

При выявлении сообществ по интересам может помочь технология Remote Monitoring (RMON2). Сетевые устройства с встроенными SNMP-агентами RMON2 обладают способностью к выборке сетевых пакетов и идентификации приложений (по номеру порта TCP или UDP). При отсутствии встроенных агентов можно установить внешние датчики. Инструментальные средства, подобные Agilent/HP NetMetrix, могут консолидировать вывод многих датчиков RMON2 и отображать результат в виде диаграммы, изображающей сетевой трафик пар "источник-цель" в соответствии с типом приложения. Это позволяет автоматизировать выявление сообществ по интересам и помогает избежать сбора неточных данных, получаемых посредством интервью.

Географические регионы и бизнес-связи

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

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

В другой распространенной модели домена управления узлы определяются в соответствии с географическим положением, и все сетевые вопросы внутри этой области остаются под местным управлением. Локальное оборудование узла может использоваться многими независимыми бизнес-подразделениями корпорации, но сама сеть управляется местной организацией. В этом случае центральная корпоративная организация поддержки имеет дело с каналами WAN между всеми этими географическими единицами. Сюда следует отнести маршрутизаторы, устройства обслуживания каналов (DSU/CSU) и другие элементы, которые соответствуют магистрали корпоративной IP-сети.

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

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

Оценка размера домена управления

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

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

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

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

Третий способ оценки числа устройств состоит в посещении каждого маршрутизатора и сервера в домене управления, заимствовании их APR-кэшей и удалении из списка дублирующих записей. Наилучшим временем для сбора кэшей являются часы наибольшей занятости, поскольку записи ARP-кэша устаревают. Типичное время старения для серверов составляет 20 минут; для маршрутизаторов – четыре часа. Параметр старения ARP-кэша часто настраивается сетевыми менеджерами под местные нужды, поскольку ARP-кэши являются ценным источником информации о сети. Допущение старения записей и их утечки из таблиц означает потерю полезной информации.

Еще один способ подсчета числа активных устройств в домене управления состоит в том, чтобы разослать внутри каждой подсети запрос отклика ICMP по широковещательному IP-адресу и подсчитать число уникальных ответов. Можно вручную дать указание маршрутизатору произвести такую рассылку. Это срабатывает в местных LAN. И опять упускаются устройства, которые в данный момент не активны. Не все системы являются восприимчивыми к тестовому опросу по широковещательному IP-адресу. И не все системы отвечают на запрос. Этот метод приведет к заниженной оценке реального числа активных устройств.

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

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

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

В зависимости от целей менеджеров сети, из реального числа активных устройств можно сознательно исключить Macintosh, машины Wintel, X-терминалы и рабочие станции под управлением Linux. Некоторые менеджеры сети заинтересованы, главным образом, в самой сетевой инфраструктуре и рассматривают DHCP, WINS, DNS, файловые, принтерные и web-серверы как прикладные системы, которыми лучше всего управлять посредством платформы управления приложениями, такой как HP OV Operations. Согласно этой философии, устройства, не поддерживающие SNMP, не должны раскрываться и управляться.

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

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

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

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

Поскольку управление сетью основано на SNMP, необходима уверенность в том, что известны все строки сообщества для доступа (по чтению) к этим маршрутизаторам. Надо надеяться, что эта строка сообщества представляет собой "public", и можно оставить для NNM исключительно установки по умолчанию. Маршрутизаторы могут быть раскрыты, даже если их строка сообщества неизвестна, но они не будут распознаны как маршрутизаторы и будут демонстрироваться на схеме как обобщенные IP-устройства с обобщенной, безликой пиктограммой.

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

Если для некоторого устройства в сети нет подходящей пиктограммы, нужно воспользоваться редактором растровых изображений. Для NNM версий 6.x и более поздних поддерживаются изображения в стандартном формате GIF. Если для создания пиктограмм предпочтительнее использовать Macintosh, следует применить программы GraphicConverter или Adobe Photoshop. Программы HiJaak Pro или Paint Shop Pro являются хорошими редакторами растровых изображений для систем Windows, пригодными для создания GIF-файлов. По поводу требований к этим пиктограммам следует обязательно просмотреть Приложение D к руководству Managing Your Network with HP Open View Network Node Manager. В NNM 5.x для создания собственных пиктограмм используется стандартный UNIX-редактор bitmap. Заметим, что bitmap создает только монохромные растровые изображения. Пример сессии по созданию пиктограммы показан на рис. 3.1.

Для каждого сетевого устройства с SNMP также обеспечивается системный объектный идентификатор (sysObjectID, OID), который уникально идентифицирует устройство. За более подробной информацией можно обратиться к разделу "Unique Properties of the SNMP MIB Object" Главы 11 руководства HP Managing Your Network with HP Open View Network Node Manager . В NNM эти OID используются для размещения пиктограмм устройств и для определения того, как они должны отображаться. Например, маршрутизаторы должны отображаться на подсхеме Internet и ниже, тогда как коммутатор Ethernet следует показывать только на схеме подсети и ниже.

Частью стратегии является определение OID устройств, подлежащих раскрытию. Как и в случае с пиктограммами, поставщики оборудования поставляют свои OID-отображения вместе с менеджерами элементов, и они автоматически помещаются в нужные каталоги. Если OID какого-либо устройства неизвестен, и он не содержится в файлах HP oid_to_sym и oid_to_type, то нужно уделить этим файлам пристальное внимание и поддерживать их как часть действующей стратегии.

Это клиентское приложение X-Windows позволяет создавать и редактировать монохромные X-растровые изображения (XBM) и сохраняет их в ASCII-файлах с расширением xbm. NNM отображает эти растровые изображения на схеме внутри пиктограмм устройств. Это облегчает уникальную идентификацию типов устройств. В NNM 6.x и более поздних версиях поддерживаются растровые GIF-файлы.

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

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

Конфигурационные файлы для регулирования домена управления

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

Файл seedfile – это просто список устройств, которые поддерживают SNMP. В качестве побочного эффекта этот список используется демоном netmon во время запуска для определения подсетей в исходном домене управления. Рекомендуются такие многосвязные устройства, как маршрутизаторы, но иногда можно использовать и другие устройства с насыщенными ARP-кэшами (такие как серверы). Чтобы информировать netmon o seedfile, следует вставить в файл $OV_LRF/netmon.lrf командную строку "-s/path/seedfile", выполнить команду $OV_BIN/ovaddobj $OV_LRF/netmon.lrf, чтобы зарегистрировать изменение, остановить netmon с помощью $OV_BIN/ovstop netmon и снова перезапустить его с помощью команды $OV_BIN/ovstart netmon. Примерное содержимое файла seedfile приводится на рисунке 3.2.

Это список устройств, предназначенный для определения подсетей исходного домена управления. Полезные записи в seedfile соответствуют многосвязным устройствам с насыщенными ARP-кэшами, таким как маршрутизаторы. Можно ввести также серверные системы, поскольку их ARP-кэши будут наполнены IP-адресами клиентских систем.

Файл filters обеспечивает правила для демона ovtopmd по включению или исключению устройств на основе их атрибутов. Это базовое средство для управления тем, какие устройства раскрываются и впоследствии помещаются на схему. Фильтры, перечисленные в этом файле, имеют имена, и эти имена передаются ovtopmd по одному в регистрационном файле $OV_LRF/ovtopmd.lrf путем добавления параметра "-f filter_name", регистрации изменения при помощи $OV_BIN/ovaddobj $OV_LRF/ovtopmd.lrf и остановки и запуска демона ovtopmd, чтобы изменение возымело эффект. Файл filters можно использовать, чтобы гарантировать, что включены бесспорные устройства, такие как серверы, а также такие сетевые устройства, как маршрутизаторы, коммутаторы и тому подобное. Файл filters располагается в каталоге $OV_CONF/C/. Пример содержимого файла приводится на рис. 3.3. Заметим, что HP обеспечивает шаблон файла filters, так что им можно воспользоваться в случае ошибки персонала. Точный синтаксис определения фильтра и допустимые атрибуты объектов можно найти в Приложении A документа A Guide to Scalability and Distribution for HP OpenView Network Node Manager.

Важно отметить, что фильтры в NNM используются четырьмя различными способами. Все четыре фильтра определяются в файле $OV_CONF/C/filters, и все они обладают одним и тем же синтаксисом. Это фильтр раскрытия (Discovery Filter), фильтр схемы (Map Filter), фильтр сохраняемости (Persistence Filter) и фильтр топологии (Topology Filter).

Фильтр раскрытия контролирует процесс раскрытия, выполняемый NNM. Фильтр применяется путем использования выпадающего меню Options:Network Polling Configuration:Discovery Filter Option. Точное местонахождение меню зависит от версии NNM и от локальных настроек меню.

Фильтр схемы определяет, какие объекты отображаются на схеме ovw. Он применяется с помощью выпадающего меню Options:Map Configuration. И снова местонахождение меню зависит от версии NNM и от локальных настроек меню.

Фильтр сохраняемости помещает фильтруемые объекты в память и немедленно помещает раскрытые объекты на схему, если они проходят через фильтр. Так обеспечивается поддержка тесно интегрированных приложений сторонних поставщиков, зависящих от пребывания объектов в памяти. Фильтр применяется из выпадающего меню Options:Map Configuration:IP Map, а точное местоположение меню зависит от версии NNM.

Фильтр топологии на накопительной станции служит для контроля над тем, какие объекты будут передаваться на управляющую станцию. Имя фильтра определяется в файле $OV_LRF/ovtopmd.lrf.

Строки сообществ SNMP хранятся вместе с другой конфигурационной информацией SNMP. Эта информация управляется с помощью GUI $OV_BIN/xnmsnmpconf. Если обнаружится устройство со строкой сообщества для чтения, отличной от строки, используемой по умолчанию, и никакое выкручивание рук не убедит администратора устройства изменить эту строку (на "public"), то NNM сможет получить необходимую информацию от xnmsnmpconf. Иначе NNM не мог бы управлять этим устройством. Моментальный снимок экрана xnmsnmpconf приведен на рис. 3.4. За подробностями обращайтесь к оперативной странице руководства xnmsnmpconf.

Этот отредактированный вручную файл filters содержит набор именованных фильтрующих выражений. Можно сконфигурировать демон ovtopmd для использования одного из этих выражений в фильтре топологии. Можно указать фильтр раскрытия, определенный в filters, с помощью GUI $OV_BIN/xnmpolling непосредственно из командной строки или из меню ovw.

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

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

В реальных сетях обнаруживаются неисправные агенты SNMP. Время от времени неправильное поведение агента SNMP будет сбивать с толку netmon, заставляя его выдавать дамп памяти ядра, впадать в бесконечный цикл или просто тратить впустую поток команд для бесконечного опроса одного и того же устройства. Если в демоне netmon поддерживается удовлетворительная журнализация и трассировка (netmon–M 63 очень многословен), то файл $OV_LOG/netmon.trace продемонстрирует устройство, являющееся причиной неполадок в работе. Чтобы netmon не "спотыкался" то и дело об эти устройства, следует поместить их IP-адреса отдельными строками в файл $OV_CONF/netmon.noDiscover.

Параметры опроса NNM хранятся в файле $OV_CONF/polling. Их полагается конфигурировать с помощью GUI xnmpolling (или подходящих опций командной строки).

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