Первое раскрытие сети – это лучшее время. Это похоже на первую главу романа или первый день отдыха в экзотической стране. Советую сетевым менеджерам уповать на свой опыт, ибо грядет тяжелая работа, как за днем неизбежно следует ночь.
Первое раскрытие часто производится в отсутствие seedfile. Домены управления по умолчанию представляются набором подсетей, соединенных с системой NNM, где возможно только полное раскрытие. Часто эта среда является испытательной лабораторией. Целью раскрытия является проверка корректности взаимодействия сетевой инфраструктуры с NNM. В такой игре легко обнаружатся все очевидные проблемы.
В отсутствие seedfile домен управления пополняется слой за слоем вновь раскрытыми подсетями, которые управляются вручную. В осторожном и контролируемом режиме NNM нацеливается на интересующие области. Проще устанавливать местоположение проблемных устройств и иметь с ними дело, когда они раскрываются медленно и осторожно. NNM создает реестр сетевого и системного оборудования и вскрывает все типы конфигурационных проблем.
В большой сети нельзя позволить себе роскошь управляемого вручную автоматического раскрытия на каждой накопительной станции, поскольку это занимает слишком много времени. Вместо этого можно "словчить" с файлом seedfile, который часто представляет собой список маршрутизаторов внутри домена управления. Пользуясь опытом предыдущего раскрытия, можно установить фильтр раскрытия, чтобы обеспечить раскрытие только желательного оборудования. В seedfile часто бывают пропущены некоторые маршрутизаторы, а иногда перечисляются такие маршрутизаторы, которых нет в домене управления; поэтому в процессе раскрытия обычно работы приостанавливаются вручную для коррекции seedfile и очистки базы данных от нежелательных устройств.
Иногда кажется, что процесс раскрытия заторможен, и новые устройства появляются не так быстро, как обычно. В этом случае следует дать системе NNM указание опрашивать ближайшие маршрутизаторы и коммутаторы. Это заставит netmon немедленно приступить к сбору их ARP-кэшей, что, возможно, позволит идентифицировать IP-адреса подозрительных устройств. Иногда помогает простое выполнение ping.
Неоднородные строки сообществ SNMP – это проклятие сети и напасть для администратора, который должен включать их в конфигурацию NNM. Процесс раскрытия под управлением NNM не будет работать с неправильными строками сообществ. Лучше иметь "public" в качестве стандартной строки сообщества, а для реализации защиты устройств применять списки контроля доступа. В основном это проблема крупной сети. В небольших сетях с неоднородными строками сообществ управляться гораздо проще.
Раскрытие напрямую связано с демоном netmon. В файле netmon.lrf можно установить опции -q и -Q для управления размером очередей ping и SNMP. За выполнением netmon можно проследить в графической форме, используя выпадающее меню Performance:Network Polling Statistics. Можно также наблюдать за очередью опросов ICMP с помощью команды
snmpget localhost nnmICMPSecsUntilNextPoll
а за очередью опросов SNMP – с помощью команды
snmpget localhost nnmSNMPSecsUntilNextPoll
Когда раскрытие стабилизируется, подсхема Internet (иначе называемая Internet Submap) NNM часто переполняется, в то время как на LANscape пиктограммы сжимаются почти до точек. С загромождением схемы можно бороться путем контейнеризации подсхемы Internet и настройки параметров раскрытия уровня 2.
Для контейнеризации подсхемы Internet требуется стратегия обеспечения согласованности схемы для всех резервных управляющих станций. В противном случае в сбойных ситуациях пользователи столкнутся с различными схемами.
Настройки схем отнимают значительную часть времени и усилий. Схемы следует сохранять и копировать при любых изменениях подсхемы Internet.
Конструкторы схем в большой компании должны обмениваться производственным опытом. В ситуации взаимозависимости управляющих и накопительных станций изменения, выполненные в одном месте, влияют, по крайней мере, на управляющие станции.
А если администратор вообще не собирается определять seedfile и хочет запустить NNM и позволить ему начать раскрытие без этого файла? Что в таком случае представляет собой домен управления? Это локальная подсеть, в которой располагается система NNM. При раскрытии будет использоваться таблица маршрутизации, таблица интерфейсов и ARP-кэш системы NNM. Таблица маршрутизации будет подразумевать локальные маршрутизаторы. Таблица интерфейсов будет подразумевать локальные подсети, так что в действительности в исходном домене управления может присутствовать несколько подсетей. ARP-кэш обеспечит список IP-адресов, являющихся кандидатами на автоматическое раскрытие.
Когда уляжется шум, в принятой по умолчанию подсхеме Internet будут показаны управляемые локальные подсети, подсоединенные к системе NNM, управляемые маршрутизаторы, присутствующие в каждой подсети, и все неуправляемые (пшеничного цвета) подсети (действующие и вспомогательные), присутствующие на других интерфейсах этих маршрутизаторов. В этой точке процесс автоматического раскрытия остановится и сконцентрируется только на управляемых подсетях. Если не определены какие-либо фильтры раскрытия, то в конце концов может быть раскрыто любое устройство, IP-адрес которого обнаруживается в APR-кэше уже раскрытого локального SNMP-устройства. Как правило, ARP-кэши маршрутизаторов и серверов являются богатыми источниками данных о локальных IP-адресуемых устройствах.
Процедура автоматического раскрытия также умеет пользоваться информационными базами управления (Management Information Base, MIB) устройств подключения к среде (Media
Зачем ограничивать раскрытие только локальными подсетями? Возможно, следует подтвердить корректность базовой установки NNM, проверить работоспособность автоматического раскрытия и сделать это на локальной подсети, не затрагивая остальную, критически важную в производственных целях часть корпоративной сети. Желательно убедиться в том, что коммутаторы Ethernet работают должным образом, и что в NNM точно представлена физическая топология.
Теперь, когда раскрыт исходный домен управления, следующим шагом могло бы быть осторожное управление (с использованием выпадающего меню Edit:Manage Objects ) несколькими подсетями, подсоединенными к локальным маршрутизаторам. Это соответствующим образом расширяет домен управления, что побуждает NNM к автоматическому раскрытию внутри этих новых подсетей. Если предположить, что в NNM уже определены строки сообществ SNMP, в новых управляемых подсетях, несомненно, будут раскрываться новые маршрутизаторы, а в подсхеме Internet новые маршрутизаторы будут наращиваться новыми подсоединенными к ним неуправляемыми подсетями. Осторожно продвигаясь и обеспечивая сходимость процесса автоматического раскрытия, можно вручную провести NNM через желательный домен управления. Этот процесс может добавить несколько часов к процессу раскрытия, но это контролируемый, дружественный процесс, который в любой момент может быть повернут вспять путем отказа в управлении (с использованием выпадающего меню Edit: ) нежелательными частями схемы сети.
Другое преимущество раскрытия, управляемого вручную, заключается в том, что в этом случае проще опознаются любые ненадежные агенты SNMP. Например, если вы только что управляли подсетью, а через минуту (после того, как раскрытие стабилизировалось) демон netmon выдает дамп памяти, сразу становится ясно, где находится проблемное устройство.
Если желательно изучить влияние процесса автоматического раскрытия на загрузку ЦП маршрутизатора Cisco, можно проследить за переменной MIB busyPer и обратить внимание на то, как возрастает и уменьшается ее значение, когда NNM обрабатывает ARP-кэш, таблицу маршрутизации и таблицу интерфейсов этого маршрутизатора. Можно использовать для этой цели браузер MIB ( Tools:SNMP MIB Browser ) и нажать на кнопку "graph", чтобы автоматически собрать данные и оформить их в виде диаграммы. Этот тип данных полезен для того, чтобы сетевые менеджеры поняли, как повлияет NNM на работу их маршрутизаторов, и убедились в том, что он никак не повредит их нормальному функционированию.
Еще одним преимуществом раскрытия, управляемого вручную, является то, что при этом встретятся все виды ошибок, одна за другой. Может быть упущена пиктограмма, может оказаться неправильной строка сообщества, в коммутаторе могут использоваться старые встроенные программы, ограничивающие возможности NNM для автоматического построения схемы, или устройство может некорректно проникать через фильтр раскрытия из-за опечатки.
Последнее преимущество раскрытия, управляемого вручную, состоит в том, что определяются трудно раскрываемые устройства. Например, для устройств, которые не взаимодействуют с другими устройствами или удаленными подсетями, не будет записей в ARP-кэшах локальных маршрутизаторов. В таких случаях только ручной тестовый опрос (pinging) этих устройств в системе NNM позволит NNM раскрыть их. Это связано с тем, что демон netmon слушает неформатированный (raw) сокет ICMP (Internet Control Message Protocol), отлавливает действия по тестовому опросу и собирает IP-адреса отвечающих устройств.
На начальной стадии, когда NNM раскрывает новые подсети и маршрутизаторы и начинает ими управлять, желательно дать NNM возможность перестроить подсхему Internet. Однако в определенный момент, когда эта схема становится перенасыщенной, следует отключить функцию автоматического построения схемы для подсхемы Internet и переместить пиктограммы в подходящие позиции. Это достаточно безопасно, поскольку процесс раскрытия полностью контролируется.
После выполнения нескольких раскрытий вручную вырабатывается необходимая уверенность и накапливаются данные для автоматизации процесса. Вооружившись списком маршрутизаторов домена управления, можно создавать seedfile, удалять базу данных объектов, топологии и схем и перезапускать демонов NNM. Поскольку подразумевается, что этот процесс будет повторяться, обычно базу данных удаляют несколько раз, пока все конфигурационные файлы, включая seedfile, не станут правильными, а раскрытие не будет происходить так, как намечалось.
Следует поместить seedfile в безопасное и неизменное место, независимое от дерева инсталляции NNM, такое как /opt/config/seedfile. Владелец и права доступа файла seedfile должны соответствовать особенностям
Для удаления базы данных объектов, топологии и схем NNM (предполагается база данных плоских файлов NNM 6.x и более поздних версий) существует две опции. Чтобы сохранить содержимое старой базы данных, выполняются следующие шаги:
$OV_BIN/ovstop ;mv openview openview .old. В версиях, предшествующих NNM 6.1, нужно удалить старые файлы регистрации событий с помощью команды $OV_LOF/xnmevents.*. Для NNM 6.1 требуется выполнить последовательность команд cd $OV_DB/eventdb; rm -rf $OV_DB/eventdb/*/* ;$OV_BIN/xnmsnmpconf -clearCache ;ovwdb с помощью команды $OV_BIN/ovstart ovwdb ;$OV_BIN/ovw -fields ;$OV_BIN/ovstart.Для удаления базы данных без сохранения ее содержимого нужно просто целиком удалить подкаталог ( rm ), не переименовывая его на предыдущих шагах. Следует обратить внимание, на возможность удаления данных о сигналах.
Процесс удаления базы данных и заведения ее заново может потребоваться, поскольку на первых порах seedfile обычно бывает небезупречным. Он может содержать данные о маршрутизаторах, которые не находятся в домене управления, или не содержать данные о маршрутизаторах из намеченного домена управления. По мере тестирования нового seedfile будут возникать новые проблемы, что заставит произвести еще один раунд раскрытия. Для окончательного утверждения seedfile требуется финальная очистка базы данных и еще одно раскрытие.
Заметим, что если нужно всего лишь добавить к seedfile маршрутизатор, не требуется создавать базу данных с нуля. Следует просто остановить и запустить netmon, чтобы заставить его снова прочитать seedfile. Если желательно удалить маршрутизатор из seedfile, и если нетрудно удалить непреднамеренно раскрытую топологию вручную, то нужно сделать это и снова остановить и запустить netmon.
Что делать, если seedfile случайно затерт, и нет резервной копии? Можно вернуться к своим записям и заново набрать этот файл. В конце концов, в файле, вероятно, содержится всего 50-100 строк. Однако нет ли способа автоматически восстановить список на основе базы данных NNM? Почему бы не воспользоваться командой ovtopodump -f filtername, чтобы распечатать данные обо всех маршрутизаторах, где filtername – это фильтр, определенный в файле $OV_CONF/C/filters и безошибочно отбирающий маршрутизаторы? Этот список будет включать маршрутизаторы, для которых имеются подсоединенные неуправляемые подсети. Использование таких маршрутизаторов в seedfile расширит домен управления на один уровень подсетей и маршрутизаторов, внешних по отношению к текущему домену. Следует руководствоваться подсхемой Internet и устранить в seedfile посторонние маршрутизаторы.
Заметим, что подсети, которые первоначально раскрываются через маршрутизаторы из seedfile, являются по умолчанию управляемыми. Подсети, добавленные к этим маршрутизаторам позже, по умолчанию будут неуправляемыми. Для маршрутизатора не из seedfile, который автоматически раскрывается впоследствии, NNM оставляет сначала все подсети неуправляемыми, кроме уже управляемых подсетей, для которых у маршрутизатора имеются интерфейсы.
Раскрытие, управляемое посредством seedfile, почти всегда происходит очень быстро. Исключение составляют периоды затишья в сети, когда ARP-кэши истощаются, и многие рабочие станции выключены. В таких условиях автоматическое раскрытие может быть крайне медленным. Иногда бывает полезно включить в файл netmon.lrf параметр резкого старта "-J". Наличие этого параметра позволяет демону netmon предписывать удаленной системе с SNMP-агентом HP рассылать запрос ICMP-отклика по своим широковещательным IP-адресам, заставляя все активные машины подсети отвечать ICMP-откликом. Это приведет к заполнению ARP-кэша удаленной системы, который потом подберет netmon.
Заметим, что если система NNM действует как станция управления, для которой не предусмотрено автоматическое раскрытие самой себя, то seedfile должен содержать только имена ассоциированных накопительных станций NNM.
Если NNM раскрывает устройства не так быстро, как требуется, нужно вмешаться. NNM может утратить активность раскрытия, или проверки конфигурации демона netmon могут быть запланированы на более позднее время. Обычно можно понять, у какого устройства имеется необходимая информация, и дать указание NNM немедленно опросить этот узел. Элемент меню Poll Node, который раньше назывался nmdemandpoll. Это заставляет netmon немедленно запросить у устройства его
Возможно, что netmon уже занят обработкой большого ARP-кэша на медленном маршрутизаторе, и в таком случае его опрашивать бессмысленно. Очереди SNMP демона netmon могут быть почти заполнены, что тоже делает вмешательство спорным. Если локальные строки сообществ SNMP являются неправильными, то единственное, что можно сделать — это скорректировать их. Сама система NNM может быть временно перегружена, тогда необходимые циклы ЦП будут отняты у netmon и демонов базы данных.
Опрос узла является более сильнодействующим средством, чем его тестовый опрос ( pinging ). Напомним, что netmon слушает неформатированный сокет ICMP на предмет новых IP-адресов в домене управления и все равно планирует опрос. Опрос вручную просто заменяет тот опрос, который был бы инициирован демоном netmon. Когда устройство подвергается опросу, интенсивность использования ЦП этого устройства значительно возрастает, сопровождаясь пиком сетевого трафика.
Техническое обслуживание сети часто планируется на конец недели. Могут устанавливаться новые коммутаторы и удаляться старые. Сетевой трафик в выходные дни низок – ARP-кэши могут быть истощены, и автоматическое раскрытие может ухудшиться. В среде UNIX может оказаться разумным написать задание cron, чтобы следить за сетевой электроникой с помощью скрипта nmdemandpoll.
Заметим, что система NNM очень устойчива по отношению к удалению информации из базы данных. NNM может оставить старые интерфейсы для переконфигурированного или замененного коммутатора, даже когда добавляются вновь раскрытые интерфейсы. Опрос коммутатора не поможет. Удаление коммутатора и его тестовый опрос часто является самым быстрым способом уладить дело, поскольку коммутатор будет заново раскрыт в своей текущей конфигурации.
NNM начинает свою работу, имея единственную глобальную, используемую по умолчанию строку сообщества, которая первоначально устанавливается в "public". Можно также информировать NNM об особых строках сообществ, основанных на диапазоне IP-адресов (wildcard), или строках сообществ для конкретных устройств. Озабоченные проблемами защиты сетевые менеджеры часто используют множество строк сообществ, чтобы не дать хакерам/взломщикам возможности получить информацию о сети от агентов SNMP. По моему опыту, результаты такого подхода к безопасности исключительно печальны, а потому, если только это возможно, следует применять списки доступа (подобные тем, которые используются в Cisco IOS для ограничения доступа к сервису на основе списка допущенных клиентов).
Не всегда удается найти понимание со стороны системных и сетевых администраторов, если подступиться к ним с просьбой изменить строки сообществ SNMP, чтобы облегчить свою задачу как администратора NNM. Следует объяснить им, что политика однородных строк сообществ SNMP сокращает административные издержки всех заинтересованных сторон. Обратите их внимание на то, что стандартизированная используемая по умолчанию строка сообщества улучшает автоматическое раскрытие и повышает эффективность NNM. Для случаев, когда важна строка сообщества, отличная от используемой по умолчанию, нужно дать понять коллегам, что вы можете информировать NNM о любых не используемых по умолчанию строках сообществ для систем и сетевых устройств, управляемых NNM.
Одной из зон бедствия является DNS, точнее, плохо реализованные серверы имен и средства защиты в DNS. Например, рассмотрим маршрутизатор с большим числом основных и вспомогательных IP-адресов. Предположим, что клиент, такой как NNM, запрашивает имя для адреса 1.1.1.1 (используя стандартный распознаватель). В качестве защитной меры предосторожности распознаватель требует, чтобы результирующее имя отображалось обратно на тот же самый IP-адрес. Но некоторые серверы имен DNS укорачивают длинный список IP-адресов (потому что не обращаются к TCP за ответами длиннее 512 байтов), и тогда исходный поисковый запрос не возвращает никакого имени. Это ставит в тупик систему NNM, так как она не может отобразить IP-адрес в имя и поэтому не в состоянии использовать надлежащую строку сообщества для общения с ним.
Другой пример бедственной ситуации в DNS – это просто изменение отображения имен и IP-адресов. Если меняется IP-адрес устройства, и это соответствующим образом отражается в DNS, то строка сообщества не будет правильной, если система NNM останется сконфигурированной со старым IP-адресом, и, следовательно, NNM потерпит неудачу при обращении к SNMP-агенту устройства.
Очевидно, что если DNS конфигурируется и реализуется должным образом, и если можно использовать имена, а не IP-адреса для сопоставления специальных строк сообществ SNMP, и если в NNM постоянно обновляются конфигурации SNMP, то этих проблем можно избежать. В больших, распределенных, динамичных корпоративных сетях имеется много подобных "если".
Первое раскрытие – это всегда неожиданность. Наблюдение за подсхемой Internet, когда NNM раскрывает новую сеть, всегда обеспечивает свежие впечатления. Когда это раскрытие завершается, наступает время оценить то, что находится в базе данных. На первых порах фильтр раскрытия часто оставляют открытым для идентификации каждого IP-адресуемого устройства. Это "раздувает" базу данных NNM. Поэтому теперь приходит время инвентаризации всех
Вооружившись новым пониманием компонентов сети, вероятно, следует модифицировать файл filters, чтобы включать одни дополнительные sysObjectIDs и отвергать другие. Использование sysObjectID в фильтре раскрытия целесообразно, поскольку таким образом обеспечивается простой и изящный метод определения устройств независимо от других трудно определяемых и тяжело управляемых атрибутов, таких как IP-адреса, которые подвержены изменениям в реальной сети. Нужно решить, какие устройства желательно раскрыть и поместить на схему. Возвращаясь к лекции 3, напомним, что фильтр схемы определяет, какие устройства показываются на заданной схеме, тогда как фильтр раскрытия определяет, какие устройства netmon допускает в базу данных.
Заметим, что не требуется очищать базу данных и заново раскрывать сеть только для того, чтобы удалить устройства, которые решено не включать в файл filters. Выполнение команды ovtopofix -f filtername применит к текущей базе данных пересмотренный фильтр раскрытия filtername и удалит устройства, которые через этот фильтр не проходят.
Одна из стратегий разработки фильтра раскрытия состоит в определении всего сетевого оборудования в соответствии с
Во время первого раскрытия можно заметить, что netmon использует ЦП куда менее интенсивно, чем ожидалось, скорость раскрытия, соответственно, удручающе низка, или NNM с запозданием отображает изменения в состоянии устройств. Да и общая загрузка системы является достаточно низкой. Хотелось бы знать, почему netmon не раскрывает устройства быстрее, и что можно сделать для изменения ситуации.
Следует ввести в файл netmon.lrf необязательные параметры демона netmon -q ICMP-queue-length и -Q SNMP-queue-length. Для обоих параметров значением по умолчанию является 20 в UNIX-системах и 3 в системах Windows NT. Эти значения могут быть увеличены в соответствии со следующими инструкциями.
Параметр ICMP-queue-length следует увеличивать, только если netmon не успевает (на что указывает очередь, всегда заполненная по максимуму), потому что может переполниться буфер операционной системы для хранения входящих ответов ICMP, что может выразиться в беспорядочных ошибочных изменениях состояния. Параметры SNMP-queue-length следует увеличивать, только если netmon не успевает, потому что операционная система ограничивает число дескрипторов открытых файлов для каждого процесса. Это настраиваемый snmpCollect. ) Не забудьте записать изменения в файл netmon.lrf с помощью команды ovaddobj, прежде чем останавливать и снова запускать netmon.
Теоретическим обоснованием увеличения этих максимальных длин очередей является то, что это позволяет демону netmon выдавать большее число невыполненных запросов. Это увеличивает пропускную способность и помогает демону netmon придерживаться своего расписания опроса. Например, при использовании установленной по умолчанию длины очереди 20 можно ожидать, что netmon будет поддерживаться должным образом, пока среднее время ответа на запросы SNMP не будет превышать 50 миллисекунд.
Увеличение максимальной длины очереди SNMP также повышает устойчивость netmon к медлительным и "неотзывчивым" агентам SNMP. Например, в один из неудачных дней netmon может заниматься опросом 15 медлительных устройств в сети (или, возможно, они будут находиться в удаленной LAN, подключенной через перегруженную линию WAN). Тогда в течение всего этого времени netmon сможет опрашивать только пять других устройств.
Насколько велики могут быть эти предельные значения для очередей? Эмпирическая оценка – 200. После увеличения максимальных значений длин очередей следует часто контролировать поведение очередей демона netmon. Необходимо отслеживать аномальное поведение при раскрытии и опросе и следить за журнальными файлами на предмет потенциальных проблем, вызываемых слишком длинными очередями.
Нужно проконтролировать процесс опроса демона netmon с использованием меню NNM Performance:Network Polling Statistics, затем подождать примерно минуту для получения графического представления течения опроса на основе 10-секундных выборок. Вариант командной строки для контроля функционирования демона netmon – netmon -a 5. Эта команда предписывает работающему экземпляру демона netmon вывести размеры списков тестового опроса (ICMP) и SNMP в файл $OV_LOG/netmon.trace. Эффективным способом использования этого средства является открытие двух shell в отдельных окнах. В первом окне нужно набрать tail -f $OV_LOG/netmon.trace, а во втором – netmon -a 5. При каждом наборе netmon -a 5 в другом окне появляется вывод.
Эффективность настройки netmon основывается на предположении, что отсутствуют какие-либо другие сдерживающие факторы его производительности. Если в NNM интенсивно используется система дискового ввода-вывода (проверьте это с помощью HP Glance/Plus top или команды iostat ), то настройка netmon с целью увеличения его пропускной способности не принесет никакой выгоды. Если серверы DNS крайне медленны, или если канал WAN с низкой пропускной способностью и высокой загрузкой разделяет систему NNM и ее домен управления, то настройка netmon не слишком сильно повысит производительность.
Рабочая лошадка netmon часто залатывается, обновляется и исправляется по мере того, как HP развивает продукт NNM. Появляются новые функции и аргументы командной строки, а некоторые старые исчезают. Держите под рукой оперативную страницу руководства. Пользователям Windows NT следует искать справочную страницу про netmon в оперативной справочной системе. Обычно эта документация является самой свежей, поскольку поступающие от HP патчи наряду с изменением кода обновляют и оперативные страницы руководства. Таким образом, внимание пользователей будет направлено на новые способы настройки netmon.
Когда завершается первое раскрытие, подсхема Internet может оказаться заполненной множеством вложенных пиктограмм. Этого следует ожидать в корпоративных сетях, содержащих сотни маршрутизаторов и тысячи подсетей. Это большое IP-центричное изображение точно представляет связность сети и очень полезно для поиска и устранения сетевых проблем, когда уляжется первое впечатление. Тем не менее, имеются неотразимые доводы в пользу разделения этой большой схемы на несколько дюжин контейнеров. Первая причина – это простота использования, а вторая – время ответа. Разделы обычно представляют домены управления или географические регионы.
Даже внутри пиктограммы подсети могут присутствовать сотни пиктограмм коммутаторов, мостов, маршрутизаторов и сегментов. Здесь на помощь приходит средство панорамирования, поскольку задача разбиения на разделы каждой подсети является слишком трудоемкой.
В подсети с большим количеством коммутаторов и сотнями портов коммутаторов число пиктограмм сегментов может приводить в уныние. Можно избежать отображения большей части беспорядка уровня 2, используя в netmon.lrf параметр NNM 6.1 -k segRedux=TRUE. Это приводит к исключению сегментов со всего лишь двумя устройствами и соединению их напрямую. Если схема уровня 2 не представляет интереса, можно использовать в netmon.lrf опцию -k bridgeMIB=FALSE, и тогда для портов коммутаторов и мостов никакие дополнительные сегменты создаваться не будут.
Заметим, что segRedux по умолчанию имеет значение "on" для чистой установки NNM 6.1. Для ситуаций модернизации значением по умолчанию является "off".
В подсхеме Internet имеется слишком много подсетей, маршрутизаторов и групповых хостов, поэтому конструктор схемы добавляет к схеме контейнеры (пиктограммы местоположения) и помечает их в соответствии с географией или назначением. Затем с помощью разумных операций выбора и "drag and drop" большинство пиктограмм будет помещено в соответствующие "домашние" контейнеры. Необходимые шаги просты:
export MAP_CUSTOMIZATION=true (только для NNM 5.x);ovw и создать новую схему;Для справочных целей см. главу 8 "Map Customization" руководства Managing Your Network with HP OpenView Network Node Manager.
Переменная окружения $MAP_CUSTOMIZATION (требуется только для NNM с номером версии, меньшим 6.x; в NNM 6.x это стандартный элемент меню) дает возможность ipmap информировать ovw о том, что в меню File нужно сделать доступными два новых элемента меню для импорта и экспорта ASCII-файла настроек. В этот файл записывается стандартная информация для всех пиктограмм подсхемы Internet. В нем не хранятся такие специальные объекты, как добавленные вручную соединения. Файл настроек очень приветствуется при реконструкции схемы. Это может понадобиться в тех случаях, когда конструктор схемы вместо исправления схемы разрушает ее, происходит аварийный отказ базы данных накопительной станции, и она должна заново раскрывать свой домен управления, или локальная база данных была настолько плохо согласована, что ее не удалось восстановить с помощью ovtopofix.
После импортирования настройки схем может проявиться несколько незначительных затруднений. Среди настроек могут содержаться еще не раскрытые пиктограммы, поэтому выдается предупреждение. Имя устройства может измениться, и оно не попадет в свой "домашний" контейнер, а останется на подсхеме Internet. Могут быть раскрыты устройства, неучтенные в настройке, и они тоже останутся на подсхеме Internet. В результате подсхема Internet все еще не будет "привлекательной" по причине наличия "сиротских" пиктограмм, не имеющих "дома".
Но вместо того чтобы падать духом, следует использовать простую уловку, чтобы восстановить схему в ее исходном виде. Требуются следующие шаги:
Большое преимущество вспомогательного контейнера состоит в том, что при этом быстро устраняется неправильное масштабирование на реконструированной схеме, вызванное размещением "сиротских" пиктограмм вдалеке от исходных символов.
Для обеспечения высокого уровня доступности платформы NNM в большой компании потребуется много управляющих станций. Чтобы достичь полного дублирования, все управляющие станции пользуются одним и тем же набором накопительных станций. Есть все основания размещать управляющие станции в физически независимых местах, так что ими могут управлять разные конструкторы схем. Тем не менее, схемы должны выглядеть одинаково, если накопительные станции должны служить дублерами одна для другой.
Чтобы сохранять согласованное состояние схем управляющих станций, конструкторы схем, очевидно, должны принять соглашение о том, кто в какой день будет модифицировать схему, так чтобы другие могли импортировать ее без потери локальных изменений схемы. Файл настройки схем представляет собой плоский текстовый файл формата ASCII, но его размер может превышать мегабайт, так что перед отправкой по электронной почте его следует сжимать. Другим вариантом общего использования файла является просто получение его посредством FTP (способ UNIX) или совместный доступ к папке (способ Window) систем NNM. Третьим способом совместного использования файлов настройки схем является инсталляция web-сервера в системе NNM и обеспечение простого web-интерфейса для каталога настройки схем.
Сотрудничающим конструкторам схем следует делиться своим производственным опытом, чтобы сэкономить время, которое они тратят на свои Internet-подсхемы. Например, если один конструктор схем обладает еще и навыками разработчика в области написания приложений
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.