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

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

< Лекция 2 || Лекция 3: 123 || Лекция 4 >

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

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

Редактор bitmap

увеличить изображение
Рис. 3.1. Редактор bitmap

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

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

  • будут раскрыты неожиданные устройства;
  • появятся безликие пиктограммы;
  • менеджеры локальных сетей объявят, что оборудование перегружено;
  • некоторые устройства останутся нераскрытыми;
  • подсети окажутся повисшими и ни к чему не присоединенными;
  • будут иметься перекрытия с другими доменами;
  • произойдет обвальное раскрытие нежелательных устройств;
  • окажутся неверными маски подсетей;
  • выявятся проблемы маршрутизации;
  • демон netmon зациклится или выдаст дамп ядра;
  • X-сессии и GUI будут заблокированы.

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

< Лекция 2 || Лекция 3: 123 || Лекция 4 >
Андрей Хохлов
Андрей Хохлов
Россия
Игорь Соловьев
Игорь Соловьев
Россия, Братск