План проекта по развертыванию NNM

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

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

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

Так что же лучше допустить – бреши между доменами или наличие перекрытий? Большинство согласится, что лучше иметь перекрывающиеся домены управления, чем оставить раздел сети неуправляемым. Что произойдет, если ряд сетевых устройств будет управляться более чем одной системой NNM? Управляемые устройства будут дважды получать запросы SNMP, и им в два раза чаще будет перебрасываться информация. Когда устройство выйдет из строя, над проблемой будут работать две группы вместо одной, если, конечно, управление сетью не является централизованным. Куда сетевое устройство посылает прерывание SNMP? Это прерывание посылается на управляющие станции NNM из списка Trap Forwarding программного обеспечения локального агента SNMP.

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

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

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

Планирование решения текущих задач

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

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

Для обмена общей информацией группа IT может установить списочный сервер, такой как listserv или majordomo, на услуги которого подписываются клиенты. Каждый, кто хочет задать вопрос или дать совет, может послать в список сообщение по электронной почте. Все подписчики списка получают копию этого сообщения, и каждый может прислать ответ или новости. Список архивируется, а доступ к нему предоставляется через web-интерфейс.

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

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

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