Данный материал рассказывает о том, как в специализированном проектном решении CleverENGINE реализована возможность использовать связи между конфигурационными единицами (далее – CI) для документирования моделей ИТ-систем и услуг.
Материал является частью описания новых функциональных возможностей решения CleverENGINE по сравнению с продуктом HP OpenView Service Desk 4.5.
CMDB является инструментом, который помогает в решении следующих задач: диагностике инцидентов и проблем, определении последствий отказа отдельных элементов ИТ-инфраструктуры, анализе и моделировании доступности услуг и компонентов, планировании мощностей и так далее. Для того чтобы это было возможно, CMDB должна содержать не только отдельные CI (в виде списка оборудования, приложений и других сервисных активов), но и связи между ними, отражающие логику взаимосвязи и характер взаимодействия.
В HP OpenView Service Desk 4.5 существовала возможность создавать связи между CI двух видов – parent/child и peer-to-peer.
Связи parent/child (один ко многим), как правило, использовались для документирования структуры CI (например, дочерняя CI «компьютер» является частью родительской CI «Автоматизированное рабочее место» и так далее).
Связи peer-to-peer (многие ко многим) использовались для документирования логического и функционального взаимодействия, а также зависимости CI друг от друга. Для определения семантики связей peer-to-peer существовала отличная возможность определять тип связи, например «uses / used by», «standby for / reserved by», «connected to» и так далее. Однако, к огромному сожалению, связи в Service Desk 4.5 не могли обладать собственными атрибутами.
Отсутствие атрибутов связей между CI является серьёзным недостатком. Почему? Представим себе две CI, связанные peer-to-peer связью «uses / used by». Давайте попробуем на основании этой информации в CMDB ответить на следующие вопросы:
- Зависит ли одна CI от другой? Каковы характеристики этой зависимости? Например, отказ одной CI приводит к мгновенному отказу второй CI или скажется на второй CI лишь спустя какое-то время?
- Как фактически осуществляется взаимодействие этих CI? Например, если эти CI – два взаимодействующих приложения, взаимодействие осуществляется посредством сетевого API или через файловый обмен? По каким протоколам? По какому расписанию, через какие сетевые папки?
Для того чтобы CMDB помогала ответить на эти и аналогичные вопросы, у связей между CI должны быть собственные характеристики, определить которые в HP OpenView Service Desk 4.5 было невозможно.
В решении OMNITRACKER CleverENGINE также существует два вида связей – parent/child (родительские/дочерние) и peer-to-peer. Для отображения логики взаимосвязи и характера взаимодействия интерес представляет связь вида peer-to-peer. С точки зрения реализации в системе, данная связь представляет собой самостоятельный объект. За счёт этого функциональные возможности ее использования значительно расширены и позволяют не просто определять тип связи, но наделять связь CI всеми свойствами, доступными для любого объекта системы, например: определять набор специфичных атрибутов, вести журнал изменения объекта.
Штатно в системе заложено определение атрибутов и характеристик связи CI на уровне формирования справочника типов связей. Тип связи определяет:
- направление связи: прямая и обратная связи, так как связи являются двунаправленными (например, «Использует / Используется»), пример визуального отображения связи между двумя CI приведен на рисунке ниже:
Рисунок 1. Визуальное отображение связи
- характеристики связи:
- [Мощность связи] – определяет допустимое количество экземпляров связей с CI (один ко многим или многие ко многим)
- [Направление влияния] – определяет взаимное влияние CI друг на друга (например, остановка сервера влияет на работу установленного на нем приложения)
- доступность и обязательность заполнения атрибутов. Для связей предусмотрены следующие атрибуты:
- [ID подключений] – идентификаторы исходной/конечной точки подключения. Данные идентификаторы могут использоваться, например, для связей между двумя сетевыми устройствами или сайтами (для указания портов, IP-адресов и так далее)
- [Спецификация] – текстовое описание характеристик связи между CI
Пример элемента справочника типов связей CI приведён на рисунке ниже.
Рисунок 2. Внешний вид формы элемента справочника типов связей CI
(нажмите на изображении для увеличения)
На этапе определения связей между CI в CMDB, в зависимости от используемого типа связи, заполняются те или иные атрибуты. В качестве примеров рассмотрим несколько ситуаций:
- данные финансового приложения хранятся в базе данных. Для обеспечения отказоустойчивости и доступности данных два сервера (Server 1 и Server 2) объединяются в кластер (My cluster), резервируя друг друга. Тогда в CMDB для связей CI «My cluster – Server 1» и «My cluster – Server 2» указывается влияние связи «С резервированием», что на практике, например, при анализе инцидентов, позволит понять: выход из строя Server 1 не приведёт к отказу кластера, базы данных и финансового приложения в целом. Однако выход из строя кластера целиком приведет к отказу базы данных. Пример приведено на рисунке ниже
Рисунок 3. Связи CI с резервированием
(нажмите на изображении для увеличения)
- из продуктивной базы данных (DB1) финансового приложения данные выгружаются в специализированную базу отчетности (DB2) посредством внешнего скрипта по расписанию. Если по каким-либо причинам продуктивная база DB1 не функционирует, то в течение определенного времени ее простой никак не повлияет на базу отчетности DB2. Таким образом, при определении связи между DB1 и DB2 влияние определяется как «Отложенное», в спецификации отображается каким образом выполнена интеграция: расписание, наименование скрипта и т.д. Пример приведен на рисунке ниже
Рисунок 4. Связь CI между двумя базами данных
(нажмите на изображении для увеличения)
- два маршрутизатора обеспечивают объединение нескольких подсетей в единую локальную сеть организации. Тогда для отображения связи используется тип связи «Подключен к», не предполагающий указания влияния. В качестве ID исходного/конечного подключения указываются IP-адреса. Пример приведен на рисунке ниже
Рисунок 5. Связь CI между маршрутизаторами
(нажмите на изображении для увеличения)
Кроме фиксированного набора атрибутов, определенного штатной конфигурацией системы, за счет гибкости модели данных платформы OMNITRACKER, существует возможность расширять состав атрибутов для связей CI. За счет этого связи могут использоваться не только для отображения модели ИТ-инфраструктуры, но и для более сложных задач, например, разнесения стоимости CI на услуги и т.д.
Таким образом, в OMNITRACKER CleverENGINE появляется возможность не только отразить наличие и тип связи, но и зафиксировать характеристики связи, что позволяет:
- формировать наглядные модели ИТ-систем и услуг;
- получать необходимую информацию о влиянии CI и выполнять эффективную диагностику инцидентов и проблем с помощью встроенных средств визуализации (см. «CleverENGINE. Визуализация CMDB») и информации о доступности CI (см. «CleverENGINE. Расчёт доступности конфигурационных единиц»);
- использовать связи для оценки рисков, связанных с проведением инфраструктурных изменений и решать многие другие задачи.
