Как показывают предыдущие лекции этой книги, автор базировался в основном на продукте Open View NNM 6.0, а иногда и на более ранних версиях. За годы, прошедшие после выхода в свет оригинального издания книги (2000 г.), компания HP выпустила несколько промежуточных версий NNM 6.x, а в 2003 г. был выпущен релиз NNM 7.0, в котором имеются существенные отличия от 6.x. В этой дополнительной лекции расматриваются основные новые черты и функциональные возможности NNM 7.0.
Прежде всего, в седьмой версии изменилась структура продукта. В предыдущих версиях по-разному лицензировались только модули, которые зависели от числа устройств, обслуживаемых программой Node Manager. Теперь функционально разделены две редакции продукта – Advanced Edition, AE (расширенная редакция) и Starter Edition, SE (начальная редакция), и эти редакции лицензируются различным образом. В данной лекции, в основном, обсуждается Advanced Edition, поскольку именно эта версия будет преимущественно использоваться на крупных предприятиях. В приложении представлена таблица, в которой сравниваются функциональные возможности SE и AE.
В лекции подробно анализируется новая, основанная на web архитектура продукта. На основе так называемых динамических представлений (view) в этой архитектуре обеспечиваются различные представления топологии сети, которые можно просмотреть с помощью браузера. Кроме того, здесь обсуждаются методы работы с дублирующими диапазонами IP-адресов, а также с Netmon в будущем станет применяться только для начального раскрытия сети.
Продукт HP OV Problem Diagnosis, доступный до настоящего времени только как отдельный компонент, теперь, наряду со средством поддержки Расширенной Топологии (Extended Topology), стал составной частью HP OV NNM Advanced Edition. Мы рассмотрим метод, лежащий в основе функционирования этого продукта, и способ его интеграции в NNM. Что касается области соотношения событий, то мы продемонстрируем возможности нового интерфейса
NNM 7.0, в отличие от предыдущей версии, в значительно меньшей степени испытывает недостаток ресурсов благодаря поддержке второго уровня топологии. Были введены существенные усовершенствования, особенно что касается требований к памяти управляющих станций, а также в вопросах представления сети и разрешения проблем. Благодаря этому с помощью одной управляющей станции теперь можно осуществлять мониторинг значительно более сложной среды. Конечно, использование распределенных систем управления будет по-прежнему поддерживаться, однако применение таких конфигураций будет отныне ограничено, главным образом, очень крупными сетевыми средами.
По сравнению с версиями NNM 6.x (за исключением версии 6.4, которая уже включала некоторую новую функциональность, например, поддержку IPv6), седьмая версия продукта HP OV
Интерфейс был дополнен Динамическими Представлениями (Dynamic View) (более подробное описание см. ниже), которые позволяют создавать основанные на web представления сетевой среды и в перспективе придут на смену GUI ovw. Область раскрытия и опроса была полностью переработана и больше не находится исключительно в ведении демона netmon. Практика показала неэффективность процесса netmon при выполнении задач раскрытия и опроса состояния. В версии 7 введен многопотоковый процесс netmon при выполнении функций опроса состояния. Средство
Введение Correlation Composer существенно упрощает соотношение событий и обеспечивает возможность защиты Хранилищ Соотношений (Correlation-Store) путем определения соответствующих требований безопасности. В результате, например, операторы могут ограничиться подборкой пороговых значений внутри защищенных Хранилищ Соотношений. Кроме того,
Еще одним нововведением является интеграция сервера syslog в NNM; в результате этой интеграции сообщения syslog от устройств могут преобразовываться в OV-прерывания и использоваться для обработки событий или в целях их соотношения (анализа исходной причины).
В будущем следует ожидать, что новые приложения, связанные с управлением, станут оснащаться новыми пользовательскими интерфейсами от HP, и интеграция отдельных продуктов будет все более расширяться. По этому поводу можно, в частности, сослаться на интеграцию с NNM HP OV Service Desk and Operations, и в будущем все компоненты интегрированного продукта получат возможность доступа к центральной базе данных.
С выходом HP OV NNM 7.0 облик продукта существенно изменился. В новой версии по-прежнему доступны применявшиеся ранее, зависящие от платформы GUI (W32 в среде Windows и X11 в среде UNIX), однако в той части, которая относится к функциональным аспектам, они были почти полностью заменены новыми Java-GUI, основанными на web.
Кроме того, структура продукта NNM разработана в расчете на то, что теперь раличаются начальная ( Starter Edition – SE) и расширенная ( Advanced Edition – AE) редакции. Различия между этими двумя версиями продукта заключаются в объеме пакета поставки (например, версия AE включает средство Extended Topology, ранее поставлявшееся только отдельно); технических возможностях приложения (раскрытие уровня 3 или даже уровня 2) и тексте лицензионных соглашений. Версия SE является в чистом виде системой управления уровня 3 (сетевой уровень модели OSI/ISO) и будет использоваться преимущественно малыми и средними компаниями, имеющими достаточно просто структурированные сети. Версия AE, напротив, предназначена для управления сложными коммутируемыми сетями, работающими на основе избыточности. В приложении к лекции приводится детальное сравнение индивидуальных особенностей SE и AE.
К основным компонентам технологии Java, используемым в данном случае, относится широко известный сервер приложений Apache TomСat (считающийся эталонной реализацией в отношении соответствия стандарту J2EE). Несомненным преимуществом этой технологии является широкое распространение сервера в корпоративных средах, а также использование открытых стандартов, происходящих из области Java-технологии. В текущей, седьмой версии NNM используется сервер приложений TomCat версии 4.0.4, так что контейнером Catalina. В предшествующей редакции NNM (например, в версии 6.4) использовался устаревший контейнер Jakarta, который был полностью переработан, особенно в отношении таких параметров, как эффективность операций и время запуска, и в результате значения этих параметров были существенно улучшены.
Если раньше при работе на уровне GUI X11/W32 сервер управления был вынужден использовать собственные вычислительные ресурсы для представления информации, то теперь, по причине расширения сферы применения Java-технологии, эти вычисления распределяются между несколькими клиентскими узлами. Несомненным преимуществом является то, что информация может быть представлена любым поддерживаемым браузером. Тем не менее, такому клиенту требуется адекватная рабочая память и соответствующая производительность процессора. Точные системные требования к управляющим станциям и клиентам перечислены в приложении. В продукте NNM 7.0 поддерживаются следующие версии браузеров: Mozilla 1.4, Netscape 7.1, а также Internet Explorer 6 с SP1.
При первом обращении к серверу управления происходит проверка текущей версии Java-Runtime (
В прошлом концепции распределенного раскрытия и мониторинга приходилось следовать при решении задач управления крупными корпоративными сетями, охватывающими несколько территориальных единиц. Для этого в крупных отделениях и филиалах, доступных только по "медленным линиям" WAN, устанавливались дополнительные накопительные станции, которые отвечали за раскрытие и мониторинг в своей части сети и обладали возможностью передачи данных о возникающих ошибках на одну или несколько вышестоящих управляющих станций. Это позволяло избежать опроса состояния через WAN-соединения, но достигалось ценой огромных дополнительных затрат на оборудование, планирование, конфигурирование и эксплуатацию (управление изменениями).
Усовершенствования, внесенные в NNM в плане использования ресурсов (ЦП, RAM), воздействуют на приведенный сценарий. Начиная с версии 7, NNM может управлять значительно большим числом объектов с одной-единственной управляющей станции. Это удобно, поскольку теперь компании гораздо активнее используют WAN при проведении своих операций, и поэтому удаленный опрос является более обоснованным.
Во время лабораторного тестирования NNM полностью распознал существующую сеть на уровне 2 ISO/OSI и правильно ее визуализировал. Дополнительная обработка вручную потребовалась только по причине присутствия двух несколько устаревших коммутаторов рабочих групп Cisco 1924, размещенных в Internet, которые пришлось обозначить в таблице
Помимо этого продолжает существовать известная по предыдущим версиям архитектура накопительных и управляющих станций с соответствующим коммуникационным механизмом RPC. Ранее это обстоятельство приводило к ситуации, при которой для мониторинга в пределах отдельного раздела секции сети требовалось наличие дополнительного порта в брандмауэрах для обеспечения коммуникаций накопительных станций, расположенных в DMZ, с управляющей станцией.
В будущих версиях NNM должен появиться новый "менеджер менеджеров" – так называемая Развитая Система Консолидации Проблем (Advanced Problem Consolidator). В этой будущей редакции, наконец, станет возможной связь между управляющими станциями по протоколу HTTP – не затрагивая proxy-сервер. В связи с огромным числом DMZ, обнаруживаемых в настоящее время в корпоративных средах, и применением соответствующих разделительных механизмов, пользователи мечтают о связи на основе HTTP.
Новшеством в NNM 7.0 является отделение задачи раскрытия сети (т.е. методического отслеживания сетевых ресурсов) от задачи мониторинга ее состояния (т.е. циклически выполняемых опросов состояния). Если в предшествующих версиях обе задачи решались единственным процессом netmon, то в седьмой версии задача опроса состояния возложена на службу
Введение netmon в предыдущих версиях. В то же время в
Говоря о безопасности в терминах систем управления сетями, необходимо отличать безопасность и защиту хранимых данных (схемы сетей; индикаторы событий; конфигурации SNMP, включая строки сообществ и т.д.) от несанкционированного доступа и защиты потоков данных при передаче данных с применением алгоритмов шифрования (например, SSL). При использовании сервера приложений TomCat обеспечиваются оба требования. С одной стороны, сервер приложений разрешает доступ к управляющим станциям через браузер, поддерживающий SSL, чтобы обеспечить безопасную передачу потоков данных; с другой стороны, в архитектуре TomCat допускается использование областей безопасности (
Область безопасности в данном контексте означает имена, пароли и профили пользователей базы данных, которые применяются в качестве средств аутентификации и авторизации при попытке доступа. В конфигурации по умолчанию соответствующая информация хранится в XML-файлах. В этом режиме управление данными производится в формате простого текста. Тем не менее, предоставляется руководство по использованию кодов доступа MD5. Кроме того, в данной архитектуре допускается применение внешней аутентификации за счет использования
С внедрением технологии 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.
Представление соседних узлов позволяет создавать изображение конкретного компонента, сосредотачиваясь на существенной для него сетевой среде. Чтобы загрузить это представление, нужно указать соответствующий компонент и число "прыжков" ("hop"), включаемых в представление в качестве окружения данного компонента. Термин "прыжок" используется для обозначения соединителей, включенных в NNM наряду с реальными маршрутизаторами и коммутаторами.
Представления этого вида целесообразно применять в области сетевого администрирования, прежде всего, с точки зрения "среднего времени восстановления" (т.е. периода времени, необходимого для восстановления после возникновения неполадок), поскольку соответствующий компонент и его существенное сетевое окружение могут быть отображены на экране для проведения анализа в контексте произошедшего события.
Представление узлов обеспечивает изображение сетевой среды на основе фильтра, известного по предыдущим версиям. В конфигурации по умолчанию существуют следующие фильтры, ограничивающие представления:
Для создания "собственного специального фильтра" его необходимо описать на специальном "языке HP для описания фильтров" и зарегистрировать в конфигурационном файле в $OV-CONF/C/filters. Сразу после создания нового фильтра он становится доступным во вновь открываемом представлении. Поэтому перезапуск службы OV не требуется.
Вот пример создания собственного специального фильтра, объединяющего все имеющиеся в сети компоненты Cisco:
// Фильтр для устройств Cisco "Cisco Devices Only" {
("SNMP sysObjectID" ~ .1.3.6.1.4.1.9.* ) }
Пояснения:
systcode object ID ) SNMP, соответствующие указанному В представлении станций, которое вызывается из исходной базы NNM, демонстрируются накопительные и управляющие станции, размещенные в сети, когда они сконфигурированы для работы в режиме распределенного управления сетью. В этом представлении в графической форме изображаются все управляющие станции, расположенные в сети. Двойной щелчок по пикторамме любой управляющей станции приводит к появлению представления Internet выбранной управляющей станции. Таким способом из любой управляющей станции можно в любое время получить информацию обо всех других управляющих станциях.
Эту разновидность представлений целесообразно использовать в корпоративных средах, функционирующих на основе концепции распределенного управления, т.е. в тех случаях, когда используется несколько экземпляров
Представления Internet напоминают схемы ovw, известные по предыдущим версиям NNM. Представление производится без использования информации Extended Topology и основывается на IP-подсетях. В данном случае это в чистом виде представление сетевой топологии на уровне 3. В отличие от предыдущих версий NNM, в представлениях такого рода не предусмотрена возможность открытия подсхем, представляющих компоненты, которые размещены в одном сегменте графического изображения топологии. Однако список существующих устройств в табличной форме предоставляется.
Стандартное представление подробно изображает область IP-сети, выбранную из разворачиваемого меню. Представление имеет вид таблицы, в которой содержится информация о типе сегмента сети (топология шина, звезда), а также о входящих в него компонентах и их операционном состоянии.
С помощью представления маршрутов операторы могут отслеживать и визуализировать соединительные маршруты между двумя управляемыми устройствами даже в крупных и сложных сетях. Источником данных для построения представления маршрута служат сетевые соединения, выявленные на этапе раскрытия, – в отличие от датчиков, которые обсуждаются в следующем разделе.
Если известны исходный и целевой адреса, то могут быть показаны даже физические соединительные маршруты между устройствами на уровне 2 ISO/OSI. Представления маршрутов, благодаря чрезвычайной простоте использования, завоюют, по всей видимости, широкую популярность среди специалистов по администрированию и эксплуатации сетей.
Через представление VLAN предоставляется для использования вся информация о VLAN, выявленная в сети на этапе раскрытия. По желанию эта информация может быть скомпонована в группы либо на основе VLAN-ID, либо по коммутаторам, на которых размещается VLAN. В разделе подробной информации представления VLAN можно увидеть коммутаторы, входящие в сеть VLAN, и их порты.
Следует обратить особое внимание на возможность сортировки по коммутаторам и меткам VLAN. Эта функция часто используется на практике, и до сих пор для ее выполнения нужно было задействовать какой-либо менеджер элементов (например, CiscoWorks).
Помимо простого представления VLAN, в NNM поддерживается, например, возможность – с использованием уже открытого представления узлов – "подсветить" с помощью функции Highlight VLAN все устройства, принадлежащие одной сети VLAN, и таким образом выделить их в общей топологии.
Протокол горячей замены маршрутизатора компании Cisco (Cisco H ot S tandby R outing P rotocol,
В прошлых версиях NNM отсутствовали знания о связях между
В седьмой версии NNM AE теперь имеется возможность распознавать группу таких маршрутизаторов и выявлять их отказы. При этом не только проверяется доступность виртуального адреса в сети, но и по протоколу SNMP опрашивается информационная база управления
Первоначально определенный в документе RFC 1583 Проблемной группой проектирования Internet (IETF), стандарт OSPF (Open Shortest Path First, первоочередное открытие кратчайших маршрутов) был пересмотрен в RFC 2328. OSPF – это так называемый протокол маршрутизации "внутреннего шлюза", в котором используются методы "состояния канала", чтобы сделать маршрутную информацию (прямые каналы к сетям) доступной другим маршрутизаторам сети. Обычно среды OSPF технически очень сложно организованы, для их обслуживания требуются значительные усилия, и до настоящего времени при возникновении ошибочных ситуаций их диагностика была затруднена из-за отсутствия визуального представления среды.
В седьмой версии NNM AE теперь имеется возможность определять местоположение области OSPF в сети, отслеживать работу устройств, входящих в эти области, и представлять среду в графическом виде. Предварительным условием этого процесса является доступ через SNMP к так называемым "граничным шлюзам", которые в действительности являются устройствами, поддерживающими прямые связи с другими областями. Для создания динамических представлений OSPF NNM использует данные, полученные в процессе раскрытия уровня 2.
При открытии динамического представления OSPF демонстрируется содержимое первой области OSPF (0.0.0.0). Отображаются все маршрутизаторы, содержащиеся в этой области, и их связи с другими областями OSPF, существующими в сети. Если дважды щелкнуть по символу OSPF в динамическом представлении, то отобразится соответствующая выбранная область, включая все ее устройства и каналы к другим областям.
По желанию области OSPF могут быть представлены в табличной форме. В обоих представлениях помечается устройство, распознанное как граничный шлюз. В табличном представлении также демонстрируются операционные состояния и назначения адресов маршрутизаторов.
Поддержка IPv6 появилась еще в NNM 6.4. Визуализация и опрос состояния таких устройств возможны при условии доступности в сети так называемых маршрутизаторов с "двойным стеком", о которых известно в обоих мирах IP. При выполнении этих условий NNM может выполнять следующие функции:
Еще одним важным новшеством седьмой версии NNM AE является возможность управлять с помощью одной-единственной системы управления так называемыми "дублирующими IP-диапазонами", т.е. областями с дважды выделенными IP-адресами. При этом NNM следует концепции "доменов с перекрывающимися адресами (
Теперь для упрощения идентификации NNM назначает этим индивидуальным сегментам идентификаторы и соответствующие символические обозначения. Эти метки отображаются в представлениях, а идентификаторы применяются при отображении событий. Область с несколькими назначениями адреса отображается на однозначный IP-адрес, что позволяет индивидуализировать адреса, назначенные несколько раз. Однако предварительным условием для этого является применение в маршрутизаторе шлюза статической трансляции сетевых адресов (
Для областей с перекрывающимися адресами доступны следующие возможности мониторинга:
Эта функциональность представляет особый интерес для сервис-провайдеров, потому что частные числовые домены IP-адресов используются повсюду, и до настоящего времени для выполнения операций внутри каждой их этих частных сетей требовалась отдельная управляющая станция.
Еще одним новшеством седьмой версии NNM является возможность установки в сети так называемых программных датчиков (software
При использовании датчика текущий маршрут пакетов данных анализируется и отображается в графической форме. Это представление отличается от ранее рассмотренного представления маршрутов ( Path View ), которое основывается на результатах процесса раскрытия.
При грамотной расстановке датчиков в различных сайтах или областях сети сетевые операторы могут в любое время получить текущий маршрут передачи пакетов данных и аналитически обработать полученную информацию. В частности, в широко распространенных динамических сетях с избыточностью (на основе OSPF, (быстрых) связующих деревьев и т.д.) трудно отследить непосредственный текущий маршрут пакетов данных. В этом случае датчики диагностики проблем ( Problem Diagnosis Probe ) обеспечивают администраторов мощным инструментом для решения этой задачи.
Информация диагностики проблем базируется, прежде всего, на данных "трассировки маршрутизации", представляемых на уровне 3 топологии сети. Кроме того, данные, по мере возможности, дополняются результатами раскрытия топологии уровня 2.
В состав инструментального средства Problem Diagnosis входят три компонента:
Основу инструмента составляет cервер диагностики проблем. Именно сюда поступает и здесь обрабатывается информация с каждого отдельного датчика. Для анализа маршрутов в этом сервере используется база данных топологии NNM, датчики, установленные в сети, и другие приложения HP Open View.
Сервер для управляющей станции размещается на отдельном сервере приложений. В версии NNM 7.0 в качестве такого сервера используется сервер приложений Mortbay-Jetty, который занимает в конфигурации по умолчанию TCP-порты 8086 и 8087. Однако описание конфигурации сервера полностью хранится в XML-файле и может быть настроено в соответствии с индивидуальными требованиями пользователя.
Датчики служат поставщиками наиболее важных данных для анализа проблем. Эти датчики являются независимыми программами, основанными на языке Java, и устанавливаются в сети таким образом, чтобы их распределение в сети было стратегически оправдано. Датчики отслеживают устройства на маршрутах, выявляют все задержки между устройствами, а также только что добавленные допустимые устройства на маршруте между двумя датчиками. Наконец, они передают эти результаты на один или несколько серверов диагностики проблем.
Графический пользовательский интерфейс сервера диагностики проблем интегрирован с исходной базой NNM (стартовой страницей), откуда и производится его запуск.
Помимо этого, выбранный маршрут можно представить в графическом виде как деталь схемы сети. В зависимости от конкретной конфигурации, представление может базироваться исключительно на уровне 3 ISO/OSI, или в него включается и информация уровня 2.
Соответствующие значения периодов обращения, т.е. времена отклика каждого устройства на основном маршруте, приводятся в области Path Detail. Если раньше при диагностике ошибочной ситуации на сетевом маршруте администратору приходилось вручную использовать различные инструменты и устройства, то теперь у него появилась возможность надзирать за критическими маршрутами в сети в целях профилактики. Система немедленно указывает на неисправное устройство, и проблему можно быстро устранить.
Насущной проблемой сетевых и системных администраторов современных распределенных систем является преобразование огромного числа отчетов о событиях, поступающих от разных устройств и в разных форматах, в понятные и осмысленные отчеты, пригодные для отображения или дальнейшей обработки. Кроме того, нужно управлять потоком входящих сообщений и выделять только те из них, которые действительно необходимы для дальнейшего использования или документирования. Для достижения этой цели должны приниматься действующие решения по поводу того, какие события можно игнорировать, а какие события являются важными для диагностики. Раньше для соотношения событий с использованием службы
Кроме того, в
Несмотря на доступность шаблонов, готовых к применению, для работы с
В частности, операторы могут настраивать пороговые уровни спецификаций соотношения событий, не имея квалификации программистов.
Пояснения:
В связи с тем, что продукт NNM AE интегрирован со средством Extended Topology, в NNM поддерживаются следующие сетевые технологии второго уровня:
С появлением седьмой версии NNM в продукте поддерживаются устройства всех ведущих производителей и все современные сетевые технологии. Более того, будут поддерживаться все новые устройства.
Наряду с поддержкой функциональности NNM, описанной ранее в этой лекции, в Open View дополнительно предоставляются так называемые модули расширения Smart Plugins (
| Возможность NNM | Starter Edition NNM | Advanced Edition |
|---|---|---|
| Раскрытие, опрос, события, сбор данных, отчетность | Да | Да |
| Раскрытие на уровне 3 | Да | Да |
| Раскрытие на уровне 2 | Нет | Да |
| OSPF, |
Нет | Да (через |
| IP-телефония, Frame Relay, Multicast | Нет | Да (с использованием дополнительных |
| Предопределенная фильтрация событий | Да | Да |
| Предопределенное соотношение событий | Базовые средства | Расширенные средства |
| Смежные сбои | Нет | Да |
| Интеллектуальная диагностика сетей | Нет | Да |
| Отчетность | Да | Да |
| Дублирующие IP-адреса | Нет | Да |
| Распределенное управление | Нет | Да |
| Новый GUI исходной базы | Да | Да |
| Динамические представления | Да | Да |
| Интеграция с решениями других поставщиков | Да | Да |
| Использование готовых пиктограмм,прерываний и т.д. сторонних поставщиков | Да | Да |
| Windows, Solaris, HP-UX | Да | Да |
| Linux | Да | Нет (ожидается в будущем) |
| Пользовательская настройка | Да | Да |
| Пользовательские представления | Нет | Да (дополнительный продукт Customer Views) |
Ниже пречисляются системные требования для седьмой версии
| Платформа | Минимальные требования |
|---|---|
| Рабочая станция HP 9000 серии 700, 800 | |
| HP-UX 11.0 | CD ROM |
| HP-UX 11.11 | RAM 512 Mб |
| 1 Гб свободного пространства на жестком диске | |
| Пространство для свопинга 768 Мб | |
| Sun SPARCstation | |
| Solaris 8 | CD ROM |
| Solaris 9 | RAM 512 Mб |
| 1 Гб свободного пространства на жестком диске | |
| Пространство для свопинга 768 Мб | |
| Intel Pentium II или выше, минимальная тактовая частота 333 МГц | |
| Windows XP | CD ROM |
| Windows 2000 | RAM 512 Mб |
| 1 Гб свободного пространства на жестком диске (NTFS) | |
| Пространство для свопинга 512 Мб |
| Клиентские операционные системы | Поддерживаемые браузеры |
|---|---|
| HP-UX 11.11 | Netscape Navigator 7.0 |
| HP-UX 11,0 | Mozilla 1.4 |
| Solaris 8 | Netscape Navigator 7.0 |
| Solaris 9 | Mozilla 1.2.1 (1.2b) |
| Windows XP | Internet Explorer 6.0 SP1 |
| Windows 2000 | Netscape Navigator 7.0 |
| Mozilla 1.4 | |
| RedHat Linux | Mozilla 1.4 |
| Серверная операционная система | Поддерживаемый модуль расширения |
|---|---|
| JavaHP-UX 11.11 | JPI 1.4.1.05 |
| HP-UX 11,0 | |
| Solaris 8 | JPI 1.4.2_01 |
| Solaris 9 | |
| Windows XP | JPI 1.4.2_01 |
| Windows 2000 | |
| RedHat Linux (SE) | JPI 1.4.2_01 |
Как показывают предыдущие лекции этой книги, автор базировался в основном на продукте Open View NNM 6.0, а иногда и на более ранних версиях. За годы, прошедшие после выхода в свет оригинального издания книги (2000 г.), компания HP выпустила несколько промежуточных версий NNM 6.x, а в 2003 г. был выпущен релиз NNM 7.0, в котором имеются существенные отличия от 6.x. В этой дополнительной лекции расматриваются основные новые черты и функциональные возможности NNM 7.0.
Прежде всего, в седьмой версии изменилась структура продукта. В предыдущих версиях по-разному лицензировались только модули, которые зависели от числа устройств, обслуживаемых программой Node Manager. Теперь функционально разделены две редакции продукта – Advanced Edition, AE (расширенная редакция) и Starter Edition, SE (начальная редакция), и эти редакции лицензируются различным образом. В данной лекции, в основном, обсуждается Advanced Edition, поскольку именно эта версия будет преимущественно использоваться на крупных предприятиях. В приложении представлена таблица, в которой сравниваются функциональные возможности SE и AE.
В лекции подробно анализируется новая, основанная на web архитектура продукта. На основе так называемых динамических представлений (view) в этой архитектуре обеспечиваются различные представления топологии сети, которые можно просмотреть с помощью браузера. Кроме того, здесь обсуждаются методы работы с дублирующими диапазонами IP-адресов, а также с Netmon в будущем станет применяться только для начального раскрытия сети.
Продукт HP OV Problem Diagnosis, доступный до настоящего времени только как отдельный компонент, теперь, наряду со средством поддержки Расширенной Топологии (Extended Topology), стал составной частью HP OV NNM Advanced Edition. Мы рассмотрим метод, лежащий в основе функционирования этого продукта, и способ его интеграции в NNM. Что касается области соотношения событий, то мы продемонстрируем возможности нового интерфейса
NNM 7.0, в отличие от предыдущей версии, в значительно меньшей степени испытывает недостаток ресурсов благодаря поддержке второго уровня топологии. Были введены существенные усовершенствования, особенно что касается требований к памяти управляющих станций, а также в вопросах представления сети и разрешения проблем. Благодаря этому с помощью одной управляющей станции теперь можно осуществлять мониторинг значительно более сложной среды. Конечно, использование распределенных систем управления будет по-прежнему поддерживаться, однако применение таких конфигураций будет отныне ограничено, главным образом, очень крупными сетевыми средами.
По сравнению с версиями NNM 6.x (за исключением версии 6.4, которая уже включала некоторую новую функциональность, например, поддержку IPv6), седьмая версия продукта HP OV
Интерфейс был дополнен Динамическими Представлениями (Dynamic View) (более подробное описание см. ниже), которые позволяют создавать основанные на web представления сетевой среды и в перспективе придут на смену GUI ovw. Область раскрытия и опроса была полностью переработана и больше не находится исключительно в ведении демона netmon. Практика показала неэффективность процесса netmon при выполнении задач раскрытия и опроса состояния. В версии 7 введен многопотоковый процесс netmon при выполнении функций опроса состояния. Средство
Введение Correlation Composer существенно упрощает соотношение событий и обеспечивает возможность защиты Хранилищ Соотношений (Correlation-Store) путем определения соответствующих требований безопасности. В результате, например, операторы могут ограничиться подборкой пороговых значений внутри защищенных Хранилищ Соотношений. Кроме того,
Еще одним нововведением является интеграция сервера syslog в NNM; в результате этой интеграции сообщения syslog от устройств могут преобразовываться в OV-прерывания и использоваться для обработки событий или в целях их соотношения (анализа исходной причины).
В будущем следует ожидать, что новые приложения, связанные с управлением, станут оснащаться новыми пользовательскими интерфейсами от HP, и интеграция отдельных продуктов будет все более расширяться. По этому поводу можно, в частности, сослаться на интеграцию с NNM HP OV Service Desk and Operations, и в будущем все компоненты интегрированного продукта получат возможность доступа к центральной базе данных.
С выходом HP OV NNM 7.0 облик продукта существенно изменился. В новой версии по-прежнему доступны применявшиеся ранее, зависящие от платформы GUI (W32 в среде Windows и X11 в среде UNIX), однако в той части, которая относится к функциональным аспектам, они были почти полностью заменены новыми Java-GUI, основанными на web.
Кроме того, структура продукта NNM разработана в расчете на то, что теперь раличаются начальная ( Starter Edition – SE) и расширенная ( Advanced Edition – AE) редакции. Различия между этими двумя версиями продукта заключаются в объеме пакета поставки (например, версия AE включает средство Extended Topology, ранее поставлявшееся только отдельно); технических возможностях приложения (раскрытие уровня 3 или даже уровня 2) и тексте лицензионных соглашений. Версия SE является в чистом виде системой управления уровня 3 (сетевой уровень модели OSI/ISO) и будет использоваться преимущественно малыми и средними компаниями, имеющими достаточно просто структурированные сети. Версия AE, напротив, предназначена для управления сложными коммутируемыми сетями, работающими на основе избыточности. В приложении к лекции приводится детальное сравнение индивидуальных особенностей SE и AE.
К основным компонентам технологии Java, используемым в данном случае, относится широко известный сервер приложений Apache TomСat (считающийся эталонной реализацией в отношении соответствия стандарту J2EE). Несомненным преимуществом этой технологии является широкое распространение сервера в корпоративных средах, а также использование открытых стандартов, происходящих из области Java-технологии. В текущей, седьмой версии NNM используется сервер приложений TomCat версии 4.0.4, так что контейнером Catalina. В предшествующей редакции NNM (например, в версии 6.4) использовался устаревший контейнер Jakarta, который был полностью переработан, особенно в отношении таких параметров, как эффективность операций и время запуска, и в результате значения этих параметров были существенно улучшены.
Если раньше при работе на уровне GUI X11/W32 сервер управления был вынужден использовать собственные вычислительные ресурсы для представления информации, то теперь, по причине расширения сферы применения Java-технологии, эти вычисления распределяются между несколькими клиентскими узлами. Несомненным преимуществом является то, что информация может быть представлена любым поддерживаемым браузером. Тем не менее, такому клиенту требуется адекватная рабочая память и соответствующая производительность процессора. Точные системные требования к управляющим станциям и клиентам перечислены в приложении. В продукте NNM 7.0 поддерживаются следующие версии браузеров: Mozilla 1.4, Netscape 7.1, а также Internet Explorer 6 с SP1.
При первом обращении к серверу управления происходит проверка текущей версии Java-Runtime (
В прошлом концепции распределенного раскрытия и мониторинга приходилось следовать при решении задач управления крупными корпоративными сетями, охватывающими несколько территориальных единиц. Для этого в крупных отделениях и филиалах, доступных только по "медленным линиям" WAN, устанавливались дополнительные накопительные станции, которые отвечали за раскрытие и мониторинг в своей части сети и обладали возможностью передачи данных о возникающих ошибках на одну или несколько вышестоящих управляющих станций. Это позволяло избежать опроса состояния через WAN-соединения, но достигалось ценой огромных дополнительных затрат на оборудование, планирование, конфигурирование и эксплуатацию (управление изменениями).
Усовершенствования, внесенные в NNM в плане использования ресурсов (ЦП, RAM), воздействуют на приведенный сценарий. Начиная с версии 7, NNM может управлять значительно большим числом объектов с одной-единственной управляющей станции. Это удобно, поскольку теперь компании гораздо активнее используют WAN при проведении своих операций, и поэтому удаленный опрос является более обоснованным.
Во время лабораторного тестирования NNM полностью распознал существующую сеть на уровне 2 ISO/OSI и правильно ее визуализировал. Дополнительная обработка вручную потребовалась только по причине присутствия двух несколько устаревших коммутаторов рабочих групп Cisco 1924, размещенных в Internet, которые пришлось обозначить в таблице
Помимо этого продолжает существовать известная по предыдущим версиям архитектура накопительных и управляющих станций с соответствующим коммуникационным механизмом RPC. Ранее это обстоятельство приводило к ситуации, при которой для мониторинга в пределах отдельного раздела секции сети требовалось наличие дополнительного порта в брандмауэрах для обеспечения коммуникаций накопительных станций, расположенных в DMZ, с управляющей станцией.
В будущих версиях NNM должен появиться новый "менеджер менеджеров" – так называемая Развитая Система Консолидации Проблем (Advanced Problem Consolidator). В этой будущей редакции, наконец, станет возможной связь между управляющими станциями по протоколу HTTP – не затрагивая proxy-сервер. В связи с огромным числом DMZ, обнаруживаемых в настоящее время в корпоративных средах, и применением соответствующих разделительных механизмов, пользователи мечтают о связи на основе HTTP.
Новшеством в NNM 7.0 является отделение задачи раскрытия сети (т.е. методического отслеживания сетевых ресурсов) от задачи мониторинга ее состояния (т.е. циклически выполняемых опросов состояния). Если в предшествующих версиях обе задачи решались единственным процессом netmon, то в седьмой версии задача опроса состояния возложена на службу
Введение netmon в предыдущих версиях. В то же время в
Говоря о безопасности в терминах систем управления сетями, необходимо отличать безопасность и защиту хранимых данных (схемы сетей; индикаторы событий; конфигурации SNMP, включая строки сообществ и т.д.) от несанкционированного доступа и защиты потоков данных при передаче данных с применением алгоритмов шифрования (например, SSL). При использовании сервера приложений TomCat обеспечиваются оба требования. С одной стороны, сервер приложений разрешает доступ к управляющим станциям через браузер, поддерживающий SSL, чтобы обеспечить безопасную передачу потоков данных; с другой стороны, в архитектуре TomCat допускается использование областей безопасности (
Область безопасности в данном контексте означает имена, пароли и профили пользователей базы данных, которые применяются в качестве средств аутентификации и авторизации при попытке доступа. В конфигурации по умолчанию соответствующая информация хранится в XML-файлах. В этом режиме управление данными производится в формате простого текста. Тем не менее, предоставляется руководство по использованию кодов доступа MD5. Кроме того, в данной архитектуре допускается применение внешней аутентификации за счет использования
С внедрением технологии 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.
Представление соседних узлов позволяет создавать изображение конкретного компонента, сосредотачиваясь на существенной для него сетевой среде. Чтобы загрузить это представление, нужно указать соответствующий компонент и число "прыжков" ("hop"), включаемых в представление в качестве окружения данного компонента. Термин "прыжок" используется для обозначения соединителей, включенных в NNM наряду с реальными маршрутизаторами и коммутаторами.
Представления этого вида целесообразно применять в области сетевого администрирования, прежде всего, с точки зрения "среднего времени восстановления" (т.е. периода времени, необходимого для восстановления после возникновения неполадок), поскольку соответствующий компонент и его существенное сетевое окружение могут быть отображены на экране для проведения анализа в контексте произошедшего события.
Представление узлов обеспечивает изображение сетевой среды на основе фильтра, известного по предыдущим версиям. В конфигурации по умолчанию существуют следующие фильтры, ограничивающие представления:
Для создания "собственного специального фильтра" его необходимо описать на специальном "языке HP для описания фильтров" и зарегистрировать в конфигурационном файле в $OV-CONF/C/filters. Сразу после создания нового фильтра он становится доступным во вновь открываемом представлении. Поэтому перезапуск службы OV не требуется.
Вот пример создания собственного специального фильтра, объединяющего все имеющиеся в сети компоненты Cisco:
// Фильтр для устройств Cisco "Cisco Devices Only" {
("SNMP sysObjectID" ~ .1.3.6.1.4.1.9.* ) }
Пояснения:
systcode object ID ) SNMP, соответствующие указанному В представлении станций, которое вызывается из исходной базы NNM, демонстрируются накопительные и управляющие станции, размещенные в сети, когда они сконфигурированы для работы в режиме распределенного управления сетью. В этом представлении в графической форме изображаются все управляющие станции, расположенные в сети. Двойной щелчок по пикторамме любой управляющей станции приводит к появлению представления Internet выбранной управляющей станции. Таким способом из любой управляющей станции можно в любое время получить информацию обо всех других управляющих станциях.
Эту разновидность представлений целесообразно использовать в корпоративных средах, функционирующих на основе концепции распределенного управления, т.е. в тех случаях, когда используется несколько экземпляров
Представления Internet напоминают схемы ovw, известные по предыдущим версиям NNM. Представление производится без использования информации Extended Topology и основывается на IP-подсетях. В данном случае это в чистом виде представление сетевой топологии на уровне 3. В отличие от предыдущих версий NNM, в представлениях такого рода не предусмотрена возможность открытия подсхем, представляющих компоненты, которые размещены в одном сегменте графического изображения топологии. Однако список существующих устройств в табличной форме предоставляется.
Стандартное представление подробно изображает область IP-сети, выбранную из разворачиваемого меню. Представление имеет вид таблицы, в которой содержится информация о типе сегмента сети (топология шина, звезда), а также о входящих в него компонентах и их операционном состоянии.
С помощью представления маршрутов операторы могут отслеживать и визуализировать соединительные маршруты между двумя управляемыми устройствами даже в крупных и сложных сетях. Источником данных для построения представления маршрута служат сетевые соединения, выявленные на этапе раскрытия, – в отличие от датчиков, которые обсуждаются в следующем разделе.
Если известны исходный и целевой адреса, то могут быть показаны даже физические соединительные маршруты между устройствами на уровне 2 ISO/OSI. Представления маршрутов, благодаря чрезвычайной простоте использования, завоюют, по всей видимости, широкую популярность среди специалистов по администрированию и эксплуатации сетей.
Через представление VLAN предоставляется для использования вся информация о VLAN, выявленная в сети на этапе раскрытия. По желанию эта информация может быть скомпонована в группы либо на основе VLAN-ID, либо по коммутаторам, на которых размещается VLAN. В разделе подробной информации представления VLAN можно увидеть коммутаторы, входящие в сеть VLAN, и их порты.
Следует обратить особое внимание на возможность сортировки по коммутаторам и меткам VLAN. Эта функция часто используется на практике, и до сих пор для ее выполнения нужно было задействовать какой-либо менеджер элементов (например, CiscoWorks).
Помимо простого представления VLAN, в NNM поддерживается, например, возможность – с использованием уже открытого представления узлов – "подсветить" с помощью функции Highlight VLAN все устройства, принадлежащие одной сети VLAN, и таким образом выделить их в общей топологии.
Протокол горячей замены маршрутизатора компании Cisco (Cisco H ot S tandby R outing P rotocol,
В прошлых версиях NNM отсутствовали знания о связях между
В седьмой версии NNM AE теперь имеется возможность распознавать группу таких маршрутизаторов и выявлять их отказы. При этом не только проверяется доступность виртуального адреса в сети, но и по протоколу SNMP опрашивается информационная база управления
Первоначально определенный в документе RFC 1583 Проблемной группой проектирования Internet (IETF), стандарт OSPF (Open Shortest Path First, первоочередное открытие кратчайших маршрутов) был пересмотрен в RFC 2328. OSPF – это так называемый протокол маршрутизации "внутреннего шлюза", в котором используются методы "состояния канала", чтобы сделать маршрутную информацию (прямые каналы к сетям) доступной другим маршрутизаторам сети. Обычно среды OSPF технически очень сложно организованы, для их обслуживания требуются значительные усилия, и до настоящего времени при возникновении ошибочных ситуаций их диагностика была затруднена из-за отсутствия визуального представления среды.
В седьмой версии NNM AE теперь имеется возможность определять местоположение области OSPF в сети, отслеживать работу устройств, входящих в эти области, и представлять среду в графическом виде. Предварительным условием этого процесса является доступ через SNMP к так называемым "граничным шлюзам", которые в действительности являются устройствами, поддерживающими прямые связи с другими областями. Для создания динамических представлений OSPF NNM использует данные, полученные в процессе раскрытия уровня 2.
При открытии динамического представления OSPF демонстрируется содержимое первой области OSPF (0.0.0.0). Отображаются все маршрутизаторы, содержащиеся в этой области, и их связи с другими областями OSPF, существующими в сети. Если дважды щелкнуть по символу OSPF в динамическом представлении, то отобразится соответствующая выбранная область, включая все ее устройства и каналы к другим областям.
По желанию области OSPF могут быть представлены в табличной форме. В обоих представлениях помечается устройство, распознанное как граничный шлюз. В табличном представлении также демонстрируются операционные состояния и назначения адресов маршрутизаторов.
Поддержка IPv6 появилась еще в NNM 6.4. Визуализация и опрос состояния таких устройств возможны при условии доступности в сети так называемых маршрутизаторов с "двойным стеком", о которых известно в обоих мирах IP. При выполнении этих условий NNM может выполнять следующие функции:
Еще одним важным новшеством седьмой версии NNM AE является возможность управлять с помощью одной-единственной системы управления так называемыми "дублирующими IP-диапазонами", т.е. областями с дважды выделенными IP-адресами. При этом NNM следует концепции "доменов с перекрывающимися адресами (
Теперь для упрощения идентификации NNM назначает этим индивидуальным сегментам идентификаторы и соответствующие символические обозначения. Эти метки отображаются в представлениях, а идентификаторы применяются при отображении событий. Область с несколькими назначениями адреса отображается на однозначный IP-адрес, что позволяет индивидуализировать адреса, назначенные несколько раз. Однако предварительным условием для этого является применение в маршрутизаторе шлюза статической трансляции сетевых адресов (
Для областей с перекрывающимися адресами доступны следующие возможности мониторинга:
Эта функциональность представляет особый интерес для сервис-провайдеров, потому что частные числовые домены IP-адресов используются повсюду, и до настоящего времени для выполнения операций внутри каждой их этих частных сетей требовалась отдельная управляющая станция.
Еще одним новшеством седьмой версии NNM является возможность установки в сети так называемых программных датчиков (software
При использовании датчика текущий маршрут пакетов данных анализируется и отображается в графической форме. Это представление отличается от ранее рассмотренного представления маршрутов ( Path View ), которое основывается на результатах процесса раскрытия.
При грамотной расстановке датчиков в различных сайтах или областях сети сетевые операторы могут в любое время получить текущий маршрут передачи пакетов данных и аналитически обработать полученную информацию. В частности, в широко распространенных динамических сетях с избыточностью (на основе OSPF, (быстрых) связующих деревьев и т.д.) трудно отследить непосредственный текущий маршрут пакетов данных. В этом случае датчики диагностики проблем ( Problem Diagnosis Probe ) обеспечивают администраторов мощным инструментом для решения этой задачи.
Информация диагностики проблем базируется, прежде всего, на данных "трассировки маршрутизации", представляемых на уровне 3 топологии сети. Кроме того, данные, по мере возможности, дополняются результатами раскрытия топологии уровня 2.
В состав инструментального средства Problem Diagnosis входят три компонента:
Основу инструмента составляет cервер диагностики проблем. Именно сюда поступает и здесь обрабатывается информация с каждого отдельного датчика. Для анализа маршрутов в этом сервере используется база данных топологии NNM, датчики, установленные в сети, и другие приложения HP Open View.
Сервер для управляющей станции размещается на отдельном сервере приложений. В версии NNM 7.0 в качестве такого сервера используется сервер приложений Mortbay-Jetty, который занимает в конфигурации по умолчанию TCP-порты 8086 и 8087. Однако описание конфигурации сервера полностью хранится в XML-файле и может быть настроено в соответствии с индивидуальными требованиями пользователя.
Датчики служат поставщиками наиболее важных данных для анализа проблем. Эти датчики являются независимыми программами, основанными на языке Java, и устанавливаются в сети таким образом, чтобы их распределение в сети было стратегически оправдано. Датчики отслеживают устройства на маршрутах, выявляют все задержки между устройствами, а также только что добавленные допустимые устройства на маршруте между двумя датчиками. Наконец, они передают эти результаты на один или несколько серверов диагностики проблем.
Графический пользовательский интерфейс сервера диагностики проблем интегрирован с исходной базой NNM (стартовой страницей), откуда и производится его запуск.
Помимо этого, выбранный маршрут можно представить в графическом виде как деталь схемы сети. В зависимости от конкретной конфигурации, представление может базироваться исключительно на уровне 3 ISO/OSI, или в него включается и информация уровня 2.
Соответствующие значения периодов обращения, т.е. времена отклика каждого устройства на основном маршруте, приводятся в области Path Detail. Если раньше при диагностике ошибочной ситуации на сетевом маршруте администратору приходилось вручную использовать различные инструменты и устройства, то теперь у него появилась возможность надзирать за критическими маршрутами в сети в целях профилактики. Система немедленно указывает на неисправное устройство, и проблему можно быстро устранить.
Насущной проблемой сетевых и системных администраторов современных распределенных систем является преобразование огромного числа отчетов о событиях, поступающих от разных устройств и в разных форматах, в понятные и осмысленные отчеты, пригодные для отображения или дальнейшей обработки. Кроме того, нужно управлять потоком входящих сообщений и выделять только те из них, которые действительно необходимы для дальнейшего использования или документирования. Для достижения этой цели должны приниматься действующие решения по поводу того, какие события можно игнорировать, а какие события являются важными для диагностики. Раньше для соотношения событий с использованием службы
Кроме того, в
Несмотря на доступность шаблонов, готовых к применению, для работы с
В частности, операторы могут настраивать пороговые уровни спецификаций соотношения событий, не имея квалификации программистов.
Пояснения:
В связи с тем, что продукт NNM AE интегрирован со средством Extended Topology, в NNM поддерживаются следующие сетевые технологии второго уровня:
С появлением седьмой версии NNM в продукте поддерживаются устройства всех ведущих производителей и все современные сетевые технологии. Более того, будут поддерживаться все новые устройства.
Наряду с поддержкой функциональности NNM, описанной ранее в этой лекции, в Open View дополнительно предоставляются так называемые модули расширения Smart Plugins (
| Возможность NNM | Starter Edition NNM | Advanced Edition |
|---|---|---|
| Раскрытие, опрос, события, сбор данных, отчетность | Да | Да |
| Раскрытие на уровне 3 | Да | Да |
| Раскрытие на уровне 2 | Нет | Да |
| OSPF, |
Нет | Да (через |
| IP-телефония, Frame Relay, Multicast | Нет | Да (с использованием дополнительных |
| Предопределенная фильтрация событий | Да | Да |
| Предопределенное соотношение событий | Базовые средства | Расширенные средства |
| Смежные сбои | Нет | Да |
| Интеллектуальная диагностика сетей | Нет | Да |
| Отчетность | Да | Да |
| Дублирующие IP-адреса | Нет | Да |
| Распределенное управление | Нет | Да |
| Новый GUI исходной базы | Да | Да |
| Динамические представления | Да | Да |
| Интеграция с решениями других поставщиков | Да | Да |
| Использование готовых пиктограмм,прерываний и т.д. сторонних поставщиков | Да | Да |
| Windows, Solaris, HP-UX | Да | Да |
| Linux | Да | Нет (ожидается в будущем) |
| Пользовательская настройка | Да | Да |
| Пользовательские представления | Нет | Да (дополнительный продукт Customer Views) |
Ниже пречисляются системные требования для седьмой версии
| Платформа | Минимальные требования |
|---|---|
| Рабочая станция HP 9000 серии 700, 800 | |
| HP-UX 11.0 | CD ROM |
| HP-UX 11.11 | RAM 512 Mб |
| 1 Гб свободного пространства на жестком диске | |
| Пространство для свопинга 768 Мб | |
| Sun SPARCstation | |
| Solaris 8 | CD ROM |
| Solaris 9 | RAM 512 Mб |
| 1 Гб свободного пространства на жестком диске | |
| Пространство для свопинга 768 Мб | |
| Intel Pentium II или выше, минимальная тактовая частота 333 МГц | |
| Windows XP | CD ROM |
| Windows 2000 | RAM 512 Mб |
| 1 Гб свободного пространства на жестком диске (NTFS) | |
| Пространство для свопинга 512 Мб |
| Клиентские операционные системы | Поддерживаемые браузеры |
|---|---|
| HP-UX 11.11 | Netscape Navigator 7.0 |
| HP-UX 11,0 | Mozilla 1.4 |
| Solaris 8 | Netscape Navigator 7.0 |
| Solaris 9 | Mozilla 1.2.1 (1.2b) |
| Windows XP | Internet Explorer 6.0 SP1 |
| Windows 2000 | Netscape Navigator 7.0 |
| Mozilla 1.4 | |
| RedHat Linux | Mozilla 1.4 |
| Серверная операционная система | Поддерживаемый модуль расширения |
|---|---|
| JavaHP-UX 11.11 | JPI 1.4.1.05 |
| HP-UX 11,0 | |
| Solaris 8 | JPI 1.4.2_01 |
| Solaris 9 | |
| Windows XP | JPI 1.4.2_01 |
| Windows 2000 | |
| RedHat Linux (SE) | JPI 1.4.2_01 |
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.