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

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

< Лекция 15 || Лекция 16: 123456

Механизм раскрытия и опроса

Новшеством в NNM 7.0 является отделение задачи раскрытия сети (т.е. методического отслеживания сетевых ресурсов) от задачи мониторинга ее состояния (т.е. циклически выполняемых опросов состояния). Если в предшествующих версиях обе задачи решались единственным процессом netmon, то в седьмой версии задача опроса состояния возложена на службу APA, включая оптимизацию ресурсов и производительности. Например, APA отвечает за опрос компонентов HSRP, "распознанных" за счет средства Extended Topology, и в то же время управляет работой перекрывающихся IP-доменов (с дублирующими диапазонами IP-адресов).

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

Безопасность управляющих станций и информации, используемой при управлении

Говоря о безопасности в терминах систем управления сетями, необходимо отличать безопасность и защиту хранимых данных (схемы сетей; индикаторы событий; конфигурации SNMP, включая строки сообществ и т.д.) от несанкционированного доступа и защиты потоков данных при передаче данных с применением алгоритмов шифрования (например, SSL). При использовании сервера приложений TomCat обеспечиваются оба требования. С одной стороны, сервер приложений разрешает доступ к управляющим станциям через браузер, поддерживающий SSL, чтобы обеспечить безопасную передачу потоков данных; с другой стороны, в архитектуре TomCat допускается использование областей безопасности (realm) для защиты хранимых данных.

Область безопасности в данном контексте означает имена, пароли и профили пользователей базы данных, которые применяются в качестве средств аутентификации и авторизации при попытке доступа. В конфигурации по умолчанию соответствующая информация хранится в XML-файлах. В этом режиме управление данными производится в формате простого текста. Тем не менее, предоставляется руководство по использованию кодов доступа MD5. Кроме того, в данной архитектуре допускается применение внешней аутентификации за счет использования JNDI (Java Naming and Directory Interface). В этом случае, например, служба каталогов, уже используемая в компании и основанная на протоколе LDAP, может применяться в целях аутентификации.

С внедрением технологии Java в NNM обеспечивается возможность назначать пользователям специальные профили (например, администратор, оператор) в соответствии с родом их деятельности в компании и определять права доступа, свойственные ролям. Например, на практике администраторы наделяются правом изменения конфигураций или наблюдения за устройствами в целом. Однако операторам предоставляются права "только на чтение". В то же время, имеется возможность централизованного хранения информации о пользователях в уже существующей службе каталогов, что существенно упрощает трудоемкую работу по "инициализации пользователей" – по крайней мере, в контексте сетевого управления. Таким образом, NNM 7.0 соответствует не только всем необходимым условиям, которые должны соблюдаться при использовании в крупных и сложных корпоративных сетях, но и тем, которые необходимы поставщикам сетевых услуг, поскольку эти сервис-провайдеры выдвигают серьезные требования к правам и профилям пользователей для сетевых операторов. Соответственно, поставщики услуг должны полностью разделить подсети индивидуальных пользователей в том, что касается прав доступа и функций операторов.

Динамические представления

Как уже говорилось, основанный на web доступ к данным управления производится через браузер. В этом случае NNM предоставляет портал начального уровня ( исходную базу, home base ), обеспечивающий графическую сводку отчетов по входящим событиям (сводку событий), а также предоставляющий доступ к различным динамическим представлениям.

Термин динамическое представление (Dynamic View) относится к дальнейшему развитию идеи схем, предоставляемых "по требованию" (On-Demand), которые появились в предыдущих версиях NNM. Такие представления сетевых топологий не хранятся в памяти управляющей станции, а вычисляются и отображаются каждый раз по мере необходимости. В случае Dynamic View этот процесс опирается на использование языка Java. Таким образом, релевантное представление сетевой среды в полном или частичном виде становится возможным в любое время. Продолжительность загрузки одного представления строго зависит от числа представляемых объектов. Однако в целом динамические представления весьма эффективны, и поэтому случаи длительной загрузки встречаются редко.

В предыдущих версиях все графические отображения управляющих станций поддерживались процессом OpenViewWindows ( ovw ), который отвечал за интерпретацию информации. В случаях параллельного доступа этот процесс часто являлся узким местом, что сильно снижало производительность системы. При использовании сервера приложений TomCat для построения динамических представлений эта проблема не возникает, поскольку данный компонент рассчитан на параллельную обработку одновременно поступающих запросов.

Затруднительный момент связан с тем, что почти все без исключения приложения сторонних поставщиков и коммутационные модули, разработанные для предыдущих версий, интегрированы в интерфейс ovw через файлы регистрации приложений ( Application Registration Files, ARF ). Это означает, что придется продолжать использовать эти приложения только через интерфейс ovw до тех пор, пока они не будут интегрированы в интерфейс NNM, основанный на web.

Представление соседних узлов (Neighbour View)

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

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

Представление узлов (Node view)

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

  • узлы ATM;
  • узлы BGP4;
  • узлы Frame Relay;
  • узлы HSRP;
  • IP-маршрутизаторы;
  • узлы MPLS (с установленным модулем расширения SPI для MPLS);
  • магистральная часть сети;
  • инфраструктура сети и т.д.

Для создания "собственного специального фильтра" его необходимо описать на специальном "языке HP для описания фильтров" и зарегистрировать в конфигурационном файле в $OV-CONF/C/filters. Сразу после создания нового фильтра он становится доступным во вновь открываемом представлении. Поэтому перезапуск службы OV не требуется.

Вот пример создания собственного специального фильтра, объединяющего все имеющиеся в сети компоненты Cisco:

// Фильтр для устройств Cisco "Cisco Devices Only" {
("SNMP sysObjectID" ~ .1.3.6.1.4.1.9.* ) }

Пояснения:

  1. Строки, начинающиеся с двойной косой черты, являются комментариями и игнорируются интерпретатором. Далее следует название фильтра и его описание. Затем определяется критерий фильтрации. В примере описываются все системные идентификаторы объектов ( systcode object ID ) SNMP, соответствующие указанному OID 1.3.6.1.4.1.9.* (в действительности, Cisco). В результате при применении фильтра будут показаны только компоненты, изготовленные компанией Cisco.
  2. Для создания собственного фильтра требуется некоторая практика использования специального языка. Однако это оправдано тем, что получаемые результаты могут впоследствии неоднократно использоваться для эффективного выполнения задач управления.
  3. Число представляемых устройств может быть ограничено путем указания NNM области IP-адресов. Эта область дает возможность выбора сетевых областей, охватываемых NNM, а также может служить групповым символом для всех сетей при использовании разворачиваемого меню. В результате представление ограничивается выбранной сетевой областью.
  4. Дальнейшее ограничение представляемой информации можно обеспечить выбором соответствующего уровня критичности состояния объектов. При этом в представление включаются только объекты с уровнем критичности не выше заданного.
  5. Благодаря преднамеренному ограничению представляемых элементов, можно создавать так называемые "представления исключений", т.е. представления существующих на данный момент проблемных участков сети.
< Лекция 15 || Лекция 16: 123456