Основные черты NNM 7.0

Домены с перекрывающимися адресами

Еще одним важным новшеством седьмой версии NNM AE является возможность управлять с помощью одной-единственной системы управления так называемыми "дублирующими IP-диапазонами", т.е. областями с дважды выделенными IP-адресами. При этом NNM следует концепции "доменов с перекрывающимися адресами (Overlapping Address Domains, OAD)". Отличительная особенность OAD состоит в том, что в отдельных сегментах используются такие IPv4-адреса, которые, с одной стороны, являются однозначными в пределах одного отдельного сегмента, а, с другой стороны, повторяются в других сегментах и, следовательно, теряют однозначность в перекрывающихся областях.

Теперь для упрощения идентификации NNM назначает этим индивидуальным сегментам идентификаторы и соответствующие символические обозначения. Эти метки отображаются в представлениях, а идентификаторы применяются при отображении событий. Область с несколькими назначениями адреса отображается на однозначный IP-адрес, что позволяет индивидуализировать адреса, назначенные несколько раз. Однако предварительным условием для этого является применение в маршрутизаторе шлюза статической трансляции сетевых адресов (Network Address Translation, NAT).

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

• обнаружение связности (включая связность уровня 2 ISO/OSI и VLAN);
• мониторинг состояния через ICMP и SNMP;
• анализ отказов в неисправных устройствах;
• графическое отображение доменов через динамические представления;
• в развитой модели событий обеспечивается присвоение всем входящим событиям индивидуальных идентификаторов.

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

Диагностика проблем (Problem Diagnosis)

Еще одним новшеством седьмой версии NNM является возможность установки в сети так называемых программных датчиков (software probe). Используя их, можно анализировать различные, зачастую динамические транспортные маршруты внутри одной сети, а также проводить мониторинг маршрутов, связанных с операционными сбоями. Программные датчики доступны для операционных систем Windows, Solaris и HP-UX. После установки датчика в целевую систему он может быть немедленно сконфигурирован управляющей станцией таким образом, чтобы анализировать сетевые маршруты от оконечного оборудования до управляющей станции или других датчиков, установленных в системе. Предусмотрен также автоматический режим для постоянного мониторинга потока данных.

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

При грамотной расстановке датчиков в различных сайтах или областях сети сетевые операторы могут в любое время получить текущий маршрут передачи пакетов данных и аналитически обработать полученную информацию. В частности, в широко распространенных динамических сетях с избыточностью (на основе OSPF, (быстрых) связующих деревьев и т.д.) трудно отследить непосредственный текущий маршрут пакетов данных. В этом случае датчики диагностики проблем ( Problem Diagnosis Probe ) обеспечивают администраторов мощным инструментом для решения этой задачи.

Информация диагностики проблем базируется, прежде всего, на данных "трассировки маршрутизации", представляемых на уровне 3 топологии сети. Кроме того, данные, по мере возможности, дополняются результатами раскрытия топологии уровня 2.

В состав инструментального средства Problem Diagnosis входят три компонента:

• основанный на web GUI;
• cервер диагностики проблем;
• датчики диагностики проблем.

Основу инструмента составляет cервер диагностики проблем. Именно сюда поступает и здесь обрабатывается информация с каждого отдельного датчика. Для анализа маршрутов в этом сервере используется база данных топологии NNM, датчики, установленные в сети, и другие приложения HP Open View.

Сервер для управляющей станции размещается на отдельном сервере приложений. В версии NNM 7.0 в качестве такого сервера используется сервер приложений Mortbay-Jetty, который занимает в конфигурации по умолчанию TCP-порты 8086 и 8087. Однако описание конфигурации сервера полностью хранится в XML-файле и может быть настроено в соответствии с индивидуальными требованиями пользователя.

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

Графический пользовательский интерфейс сервера диагностики проблем интегрирован с исходной базой NNM (стартовой страницей), откуда и производится его запуск.

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

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

Спецификация соотношения событий (Correlation Composer)

Насущной проблемой сетевых и системных администраторов современных распределенных систем является преобразование огромного числа отчетов о событиях, поступающих от разных устройств и в разных форматах, в понятные и осмысленные отчеты, пригодные для отображения или дальнейшей обработки. Кроме того, нужно управлять потоком входящих сообщений и выделять только те из них, которые действительно необходимы для дальнейшего использования или документирования. Для достижения этой цели должны приниматься действующие решения по поводу того, какие события можно игнорировать, а какие события являются важными для диагностики. Раньше для соотношения событий с использованием службы ECS (Event Correlation Service), которая была полностью синхронизирована с сетевой средой, требовалось применение инструментального средства ECS Designer, которым могли оперировать только эксперты, обладающие глубоким знанием технологии. В седьмой версии NNM для этой цели предлагается инструментальное средство HP OV Correlation Composer с новым графическим интерфейсом, предназначенное для создания и параметрической обработки специальных соотношений.

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

• Enhance (сбор данных о событии);
• Multi-Source (создание одного логического события на основе нескольких источников событий);
• Rate (определение числа событий, произошедших за определенный период времени);
• Repeated (удаление дублирующих событий и создание нового события);
• Suppress (подавление некоторых специальных событий);
• Transient (определение ситуации частого изменения состояния по причине ошибок).

Кроме того, в Correlation Composer допускается создание шаблонов соотношения событий, определяемых пользователем.

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

Несмотря на доступность шаблонов, готовых к применению, для работы с Correlation Composer требуется значительное время на обучение администраторов. Однако возможность выбора разных режимов (разработчика или оператора) следует рассматривать как значительный прогресс.

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

Пояснения:

1. Если входящее событие относится к категории Open View Enterprise Event, являясь так называемым "особым прерыванием", поступающим не от коммутатора или маршрутизатора, то это событие, по всей вероятности, будет впоследствии подавлено.
2. При этом Correlation Composer может обрабатывать события в формате OVO ( Open View Operation ) и SNMP.