• Звонок по России бесплатный 8 800 200-59-60
  • Москва +7 (495) 232-92-30
  • Санкт-Петербург +7 (812) 327-59-60
  • Екатеринбург +7 (343) 378-41-50

IBM Tivoli Netcool/OMNIbus

IBM Tivoli Netcool/OMNIbus предназначен для построения систем централизованной обработки и корреляции аварийных сообщений, поступающих от разнородных источников, включая оборудование и управляющие программы различных производителей. Большая часть сказанного о назначении IBM Tivoli Netcool/OMNIbus во вступлении к этому разделу, относится в первую очередь к IBM Tivoli Netcool/OMNIbus, так как именно он выполняет функции центрального программного модуля, консолидирующего, обрабатывающего и хранящего данные, поступающие в виде потока сообщений от интерфейсных модулей (проб) и мониторов.

Построение систем операционной поддержки (OSS) неразрывно связано с централизацией управления неисправностями (англ. Fault Management), более того, на практике, объединение сбора и обработки потоков аварийных сообщений реализуют в первую очередь, так как без него невозможно анализировать поведение инфраструктуры в целом, выявлять настоящую причину аварии и отсеивать симптомы (англ. Root Cause Analysis).

IBM Tivoli Netcool/OMNIbus это объединяющее название пяти типов компонентов:

  • База данных IBM Tivoli ObjectServer - это высокопроизводительная реализация резидентной базы данных, предназначенная для хранения и обработки поступающих сообщений.
  • Пробами называются интерфейсные модули, выполняющие функции получения, нормализации, предварительной обработки и доставки аварийных сообщений от объектов мониторинга в ObjectServer.
  • Шлюзы занимаются "массовой" передачей сообщений из одного IBM Tivoli ObjectServer в другой, или из IBM Tivoli ObjectServer во внешнюю базу данных.
  • Контроль процессов (Process Control Agent) - это служебный компонент, отвечающий за управления процес сами (модулями) самого IBM Tivoli ObjectServer и за выполнение заданных в настройках ObjectServer внешних процедур и программ. В частности, контроль процессов отвечает за упорядоченный запуск компонентов IBM Tivoli ObjectServer в случае перезагрузки сервера.
  • Клиентские приложения. IBM Tivoli Netcool Administrator предназначен для администрирования баз ObjectServer и настройки контроля процессов, a Event List (список событий) - для текущей оперативной работы с аварийными сообщениями. Есть ещё одно приложение, которое представляет собой текстовый SQL инструмент работы с ObjectServer (англ. Command line SQL Tool или Interactive SQL Interface)

 

Остановимся подробнее на наиболее важных из них.

IBM Tivoli ObjectServer

База данных IBM Tivoli ObjectServer оптимизирована для потоковой обработки и распределения событий, что позволяет достигать высоких показателей производительности достигающей сотен обрабатываемых сообщений в секунду. Тот факт, что база резидентная (хранящаяся в оперативной памяти) не значит, что при внезапном отключении сервера её данные исчезнут. Для сохранения целостности информации, содержащейся в репозитарии, IBM Tivoli ObjectServer использует механизм контрольных точек (checkpoints), осуществляя сохранение всех таблиц репозитария на диск и промежуточные изменения в журнальные файлы. Каждый IBM Tivoli ObjectServer состоит из большого числа таблиц, в них хранятся не только сами аварийные сообщения, но и практически все его собственные настройки (учётные записи пользователей, меню и инструменты клиентских списков сообщений, настройки автоматических действий и мн.др.). Поддерживается возможность добавления новых полей и таблиц без остановки базы IBM Tivoli ObjectServer.

Важным свойством ObjectServer является возможность задать алгоритм обработки или, другими словами, описать жизненный цикл для каждого типа сообщений. В идеальном случае, в ObjectServer должны присутствовать только сообщения, отражающие существующие аварии или состояния в контролируемой среде. Все неактуальные сообщения должны удаляться из высокоскоростной оперативной базы ObjectServer, но предварительно архивироваться при помощи шлюза во внешнюю дисковую базу данных (напр. Oracle, MS SQL). Такой подход позволяет поддерживать высокую производительность и низкое время отклика клиентским приложениям. Исполнителями алгоритмов являются так называемые триггеры. Алгоритм работы триггера настраивается в графическом интерфейсе с использованием несложных SQL выражений. Триггеры позволяют обрабатывать сообщения без участия оператора и являются основополагающей частью IBM Tivoli Netcool/OMNIbus. В триггере могут выполняться как SQL команды, так и внешние по отношению к ObjectServer процедуры. В поставке идёт более 50 готовых триггеров, отвечающих за различные, типичные для большинства применений функции. В процессе внедрения специалисты дополняют этот список своими собственными триггерами, реализуя тем самым все требуемые алгоритмы поведения базы ObjectServer по отношению к сообщениям, записываемым, хранящимся и удаляемым.

В IBM Tivoli Netcool/OMNIbus используется три типа триггеров:

  • Триггеры Базы данных реагируют на изменение или попытку изменения содержимого таблицы ObjectServer. Характерным примером использования такого типа триггеров является обслуживание функции дедупликации. При попытке записи сообщения триггер определяет, что это повтор уже имеющегося в ObjectServer, и вместо ещё одной записи изменяет метку времени последнего поступления и увеличивает на единицу поле счётчика таких событий в уже существующей записи. Примерами внешних процедур может быть также отправка письма уведомления по электронной почте, мгновенный запуск скрипта/программы с параметрами, подставляемыми из содержимого только что поступившего сообщения.
  • Временные триггеры срабатывают периодически с заданным интервалом времени. Например нужно один раз в 5 минут проверять все сообщения ObjectServer и удалять те у которых истек "срок годности" (поле Expiry time). Другой важный пример использования временных триггеров это отработка механизма корреляции "проблема - решение". Триггер просматривает все сообщения класса решение проблемы (англ. Resolution - сообщение что конкретная проблема больше не актуальна), находит соответствующие им сообщения о проблемах и полученным парам присваивает нулевой уровень критичности (Clear).
  • Сигнальные триггеры конфигурируются для обработки системных или пользовательских прерываний, например формирование уведомления оператору при остановке ObjectServer. Можно настроить триггер на срабатывание по сигналу прерывания, выставляемого внешней программой или другим триггером (пользовательское прерывание - англ. User defined signal). Список системных прерываний фиксированный. Примеры системных прерываний: старт/стоп базы ObjectServer, отказ в авторизации клиента, подключение/отключение клиента, удаление/до бавление таблиц и т.д.

 

Масштабируемость и отказоустойчивость

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

Интеграция инструментов в списки сообщений

Клиентское приложение Event List позволяет интегрировать в свой интерфейс внешние команды, запускаемые в контексте узла, о котором идёт речь. Отталкиваясь от сообщения, оператор может вызвать внешнюю программу производителя оборудования, открыть терминальную сессию, дать команду на открытие сервисной заявки и выполнить любые действия с сообщениями.

Протокол сетевого взаимодействия и вопросы безопасности

Компоненты IBM Tivoli Netcool/OMNIbus используют клиент/серверную технологию связи поверх сети TCP/IP. Они могут быть установлены все на одном сервере или распределены по нескольким. Например, можно установить пробу на той же системе где находится источник сообщений, а сам IBM Tivoli ObjectServer с графическими клиентами на другой. С точки зрения подключения к базе IBM Tivoli ObjectServer и взаимодействия с ней все другие приложения Netcool выступают в роли пользователей. IBM Tivoli ObjectServer может работать либо в защищенном (Secure mode) либо в открытом режиме. В защищенном режиме, когда проба или шлюз подключаются к IBM Tivoli ObjectServer он требует от них логин и пароль. Эти данные передаются по сети в зашифрованном виде. Графические и интерактивные клиентские приложения (Event list, Administrator, Command line SQL tool) аутентифицируются вне зависимости от режима ObjectServer. Поддерживается режим внешней аутентификации с использованием служб LDAP и NIS. Авторизация связана с проверкой прав аутентифицированного пользователя на просмотр и изменение информации в ObjectServer. Аутентификация реализована внутри ObjectServer и использует подход объединения пользователей в группы и назначения этим группам различных ролей. Для тонкой настройки ограничения на просмотр данных таблиц для отдельного пользователя или группы используют "заградительные фильтры" (restriction filters).

Для обеспечения безопасности все компоненты IBM Tivoli Netcool/OMNIbus могут работать в защищенном режиме, используя для аутентификации и криптографической защиты соединений средства SSL (Secure Socket Layer). SSL - это протокол, который защищает данные, пересылаемые между сервером и клиентом. Основное назначение протокола защиты состоит в аутентификации источника, гарантирующей пользователям достоверность информации и создание защищенного канала для её передачи.

Поддержка русского языка

IBM Tivoli Netcool/OMNIbus поддерживает различные кодировки включая русские СР1251 и KOI8-R. При передаче данных между компонентами, работающими в разных локалях (кодировках) выполняется автоматическая трансляция кодировок. Названия столбцов в списках аварий, пункты меню, текст самих сообщений и комментариев операторов - все они могут отображаться по-русски.

Пробы

Программные агенты, предоставляющие интерфейс к уровню сетевых элементов или к уровню управления элементами сети. Проб реализует, в случае необходимости протокол обмена с оборудованием или системой управления, и обеспечивает сбор, унификацию и гарантированную доставку аварийных сообщений в ObjectServer, а также, в некоторых случаях, синхронизацию и поддержание актуальности набора полученных данных. На сегодняшний день насчитывается более 250 типов проб для более чем 1000 моделей оборудования и систем управления других производителей. Это не считая огромного количества моделей SNMP оборудования формат сообщений которых понимает SNMP проба. Каждый год этот список пополняется десятками новых проб.

Проба является реконфигурируемым модулем, выполняющим все необходимые операции по сбору и нормализации сообщений. Проб определяется типом и производителем устройства или системы управления оборудованием, версией встроенного ПО и типом используемого для интеграции интерфейса. Алгоритм разбора различных форматов сообщений заложен в текстовом файле, называемом файлом правил (Rules File). Синтаксис языка файлов правил Netcool достаточно прост и путём редактирования текста можно менять поведение проб.

Для обеспечения целостности данных проб использует механизм Store and Forward (Сохранить и Передать), что позволяет пробу при потере соединения с ObjectServer переключаться в режим Store, сохраняя данные на локальном диске. При восстановлении соединения проб переходит в режим Forward, передавая все сохраненные данные в репозитарий. Большинство проб поддерживают программное резервирование, что используется для отказоустойчивых конфигураций.

Шлюзы

Шлюз является интеграционным модулем, реализующим двунаправленный или однонаправленный интерфейс. Шлюз позволяет синхронизировать данные между базами ObjectServer для реализации систем повышенной надежности (failover), строить архитектуры с распределением нагрузки (load balancing), а также осуществлять интеграцию с другими прикладными системами.

Двунаправленные шлюзы позволяют синхронизировать изменения одновременно в двух направлениях, в отличие от однонаправленных шлюзов, транслирующих изменения только в одном направлении.

Вот список внешних шлюзов:

  • Remedy ARS
  • Clarify
  • IBMDB2
  • Siebel eCommunications
  • Siebel Field Service Desk
  • Informix
  • MS SQL Metasolv
  • TMS Oracle
  • Peregrine Service Center
  • Hewlett Packard Service Desk
  • MySQL
  • PostGres
  • Cramer
  • Granite
  • Smallworld
  • TIBCO
  • Vitria
  • Sybase
  • Peoplesoft Vantive
  • Espresso
  • Flat File
  • Socket
  • SNMP
  • ODBC
  • XML

 

Поддерживаемые OMNIbus операционные системы:

Sun Solarise, 9, 10
HP-UX 11.00 (серии 700/800)
HP-UX 11i (11.11)
IBM AIX 5L (5.2 и 5.3 RS/6000-32bit)
Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2003 Server
Red Hat Linux AS, ES и WS 3
Red Hat Linux AS, ES и WS 4
SUSE Linux Enterprise Server 9.2

На следующих платформах поддерживаются только компоненты графического интерфейса пользователя:

Microsoft Windows XP
Microsoft Windows 2000 Professional

Система Orphus