Важнейшую задачу, стоящую сегодня перед администратором ИТ, назвать несложно: поддержка деятельности предприятия при помощи информационных технологий. С учетом постоянных перемен, с которыми приходится иметь дело ежедневно, компаниям необходима гибкая инфраструктура ИТ, которая без проблем адаптировалась бы к деловым процессам. Решения управления должны быть в состоянии оптимально использовать имеющиеся архитектуры — причем без компромиссов в отношении безопасности и готовности. В последнее время все это выливается в требование управления и администрирования ресурсов ИТ с точки зрения деловых процессов.
Между тем директорам по информационным технологиям приходится бороться со сложностью исторически сформировавшихся инфраструктур, где представлены разные производители, платформы, приложения и стандарты. С учетом фрагментирования традиционных систем управления администрирование сред ИТ стало требовать весьма значительных усилий со стороны персонала. Лишь немногие инструменты позволяют осуществлять управление с точки зрения деловых процессов, большинство же предлагает ограниченный, функционально-ориентированный взгляд на происходящее.
До тех пор пока управление информационными технологиями остается «ручной работой», его стоимость будет большей, чем нужно, а предприятия не смогут использовать собственные ресурсы ИТ полностью. Одновременно предприятию угрожает повышенный риск в отношении безопасности из-за раздробленности информационных технологий и их ориентации на решение строго определенных задач. До сих пор такая стратегия не позволяла или, по крайней мере, мешала единому управлению различными технологиями, потому что многие организации, к примеру, хранят данные об активах и данные об управлении хранением раздельно. В этом случае для зарегистрированного в рамках автоматического обнаружения сервера нельзя точно установить, когда проводились процедуры резервного копирования и проводились ли вообще. Еще один пример. Система сетевого управления предоставляет информацию о статусе только работающих компонентов, но не дает администратору данных о реальных ресурсах сети, поскольку выключенные системы не отображаются.
Каждый инструмент и каждая дисциплина управления пользуются собственными схемами и базами данных. А обмен сообщениями между отдельными административными задачами может проходить лишь с минимальным общим делителем, поскольку необходимое отображение, занимающее к тому же много времени, не обходится без потери данных. Различные инструменты приводят данные к сопоставимым значениям в отличающихся выражениях и в разные моменты времени. Таким образом, ответ на вопрос об актуальности и качестве информации повисает в воздухе. И эти данные из-за ограниченной информативности едва ли можно использовать для целей текущего управления производительностью, рисками и доступом. Даже ответы на вопросы о пользователях ноутбуков, приобретенных несколько месяцев назад, о недостаточном или, наоборот, чрезмерном количестве лицензий, о постоянном запуске обновлений системы безопасности требуют серьезных усилий со стороны администратора и больших временных затрат.
ЕДИНСТВЕННЫЙ ИСТОЧНИК ИСТИНЫ
В итоге все острее становится потребность в интегрированной возможности всеобъемлющего обзора систем ИТ и в единственном источнике информации о действительном положении дел в управлении (Single Source of Truth, SST) — кто не знает, как выглядит его ландшафт ИТ, тот не может им управлять в принципе. Он не в состоянии смоделировать свою систему, защитить ее и достичь оптимального соотношения готовности и производительности ресурсов ИТ.
Первое приближение к созданию такого единственного источника правдивых сведений представляет собой модель базы управляющей информации о конфигурации (Configuration Management Database, CMDB), которую библиотека инфраструктуры ИТ (IT Infrastructure Library, ITIL) рассматривает как центральную составную часть всех задач управления услугами ИТ. С данными о структуре, взаимосвязях и истории ресурсов ИТ, включая изменения, ошибки и отказы, она образует ядро многих процессов ITIL, к примеру для управления конфигурацией, ресурсами и рисками.
В этом контексте ITIL определяет CMDB как библиотеку элементов конфигурации (Configuration Item, CI). Наряду с собственно ресурсами они включают в себя и отношения внутри среды ИТ. Тем временем вопрос о реализации CMDB остается открытым: в принципе, можно даже всю информацию о CI занести в таблицу Excel. Часто встречаются такие подходы к решению, которые в зависимости от приложения организуют виртуальный уровень над собирающими данные источниками, чтобы путем использования коннекторов или промежуточного программного обеспечения свести их воедино в одной логической базе данных либо каком-то подобии хранилища данных о конфигурации (в так называемой «федеративной» CMDB).
Наряду с высокими требованиями к обслуживанию недостаток этого подхода, особенно в крупных инфраструктурах, заключается в том, что перечисленные выше проблемы не решаются по существу. Если приложение А назначает отслеживаемому сетевому компоненту номер, а приложение В идентифицирует его по МАС-адресу, то CMDB на стороне приложения должна распознать, что речь идет об одном и том же компоненте. Еще более сложными и опасными являются конфликтные ситуации, возникающие, когда различные приложения управления предоставляют противоречивую информацию и оставляют CMDB один на один с вопросом оценки их достоверности.
МОДЕЛЬ SOA
Проблема, причина которой кроется в заимствовании информации из различных вместилищ данных, позволяет провести параллель с текущими задачами в области корпоративного программного обеспечения. Эксперты единодушны в том, что потребность в гибкости и интеграции может быть удовлетворена при помощи ориентированной на услуги архитектуры (Service-Oriented Architecture, SOA). Поэтому довольно скоро модель SOA в системном управлении тоже будет играть роль доминирующей программной архитектуры.
Концепция управления корпоративными ИТ (Enterprise IT Management, EITM), к примеру, базируется на принципах ориентированной на услуги архитектуры и предлагает отдельным приложениям управления совместно используемые услуги на базе интеграционной платформы (см. Рисунок 1). Все компоненты следуют единой модели данных и в качестве хранилища управляющей информации используют центральную базу данных (Management Data Base, MDB). Такая управляющая база поддерживает распознавание и инвентаризацию всего аппаратного и программного обеспечения, управление правами пользователей и определение правил, а также реализацию концепции CMDB, однако ее функциональность гораздо шире, поскольку она связывает полное множество управляющих данных с ресурсами ИТ из самых различных дисциплин управления и поэтому служит в качест-ве единственного источника истины.
|
| Рисунок 1. Платформа интеграции для управления службами ИТ и безопасностью должна опираться на архитектуру, ориентированную на услуги. |
ЕДИНАЯ СХЕМА ДАННЫХ
Этот единый взгляд на «правду управления» становится возможен благодаря наличию единственной интегрированной схемы данных для хранения. Она охватывает полный набор данных управления и отношения между ними. По сравнению с взаимодействием на уровне API неоценимое преимущество такой схемы в том, что она практически решает задачу интеграции: новый инструмент получает информацию об управлении из управляющей базы данных и записывает в нее новую информацию. В идеальном случае при запуске инструмент ищет уже имеющуюся управляющую базу данных для использования ее в качестве собственной базы.
Одна из самых больших проблем в этой области, как и в случае с уже упомянутой реализацией CMDB, касается трактовки идентичности CI. Эта трактовка сказывается на точности и полноте информации управления, поскольку инструменты обнаружения ресурсов часто применяют собственные методы, а разные инструменты дают разные результаты.
Так называемый метод «реестра активов» предлагает сравнительно простую и четкую концепцию. Идея в том, что каждый бит информации об элементе конфигурации вводится по определенной схеме в единую базу данных. При нахождении новой конфигурации запускается процесс регистрации, а центральный регистр выдает однозначный идентификатор. Но если алгоритм регистрации определит, что данный объект уже зарегистрирован, то идентификатор связывается с уже введенной в управляющую базу данных конфигурацией. В результате приложение сразу же получает доступ к предоставленной другими приложениями информации управления. И наоборот, последние могут воспользоваться добавленными данными.
АЛЬТЕРНАТИВА ОТОБРАЖЕНИЮ
По сравнению с широко распространенным отображением данных при использовании нескольких относящихся к разному инструментарию источников информации сильные стороны такой интерпретации идентичности CI особенно наглядно проявляются в динамичных инфраструктурах ИТ. В случае решений виртуализации, к примеру VMware или Virtual PC, компьютер в принципе может обладать несколькими идентичностями
с разными именами DNS. По административным причинам имеет смысл обрабатывать их как одну конфигурацию. Если администратор задумает разделить идентичности, посчитав, что из соображений производительности и безопасности определенные приложения должны работать на отдельном физическом компьютере, то при помощи метода регистрации активов в реестр добавляется еще один идентификатор элемента конфигурации. Иными словами, не нужно просматривать все таблицы управляющей информации и вводить новые ссылки.
Осуществление интеграции на уровне данных посредством управляющей базы данных с единой расширяемой схемой данных предотвращает избыточность и снижает издержки на администрирование и обслуживание. Например, описанных в начале противоречивых ситуаций можно было бы избежать, поскольку все данные едины и ясны. Ввод информации происходит в ходе согласованного процесса и через стандартизированные интерфейсы (среди прочих XML). Это изначально предотвращает проблемы, возникающие из-за отсутствия синхронизации в данных.
В отличие от прочих подходов, которые из баз данных различных инструментов фильтруют необходимую информацию для получения единого обзора, управляющая база данных всегда содержит актуальную информацию об управлении. И поскольку ее внедрение требует применения мощных реляционных баз данных, одновременно становится доступным множество уже хорошо зарекомендовавших себя концепций интеграции и распределения, среди которых — двухфазная фиксация, функции тиражирования для распределенных реализаций и т. п. При помощи коннекторов и адаптеров можно построить звездообразную архитектуру в виде концентратора с расходящимися лучами, когда под контроль единой MDB ставятся имеющиеся базы данных управления, чтобы в итоге полностью заменить их, внедрив ведущую систему.
АКТУАЛЬНАЯ ИНФОРМАЦИЯ УПРАВЛЕНИЯ
Основная польза от применения MDB заключается в том, что информация централизованно связывается с ресурсами ИТ из разных дисциплин управления. Отделу ИТ больше не придется с огромными усилиями и затратами времени устанавливать связи между данными. Если, к примеру, система управления сетью запускает процесс обнаружения и регистрирует какой-либо объект, то управление активами немедленно активизирует агента, чтобы получить полный список аппаратного и программного обеспечения. В случае получения информации о каком-либо происшествии сотрудники сервисной службы могут немедленно проверить все активы, включая инвентарную информацию. Если служба аудита или мониторинга регистрирует необычные события или отказы, то администраторы немедленно выявят все затронутые ресурсы и пользователей, а также определят дополнительные риски вследствие недоступности исходных соединений. При необходимости согласованность на уровне инструментов управления расширяется до полных потоков заданий, сопровождающих деловой процесс. Если отдел ИТ захочет из соображений безопасности применить ко всем приложениям новую, единую версию заплат, то MDB предоставит полную картину реального использования и установленных версий. На следующем шаге эту информацию можно сравнить с торговым учетом и управлением системами, а также с данными управления пользователями и персоналом. Подобная комбинация позволяет четко отслеживать, что было куплено, что внедрено, что использовано, какой круг лиц имеет доступ к приложению и т. д. В результате формируется точное представление относительно необходимости дополнительных закупок следующей версии программы для перехода на единую версию. После определения потребности, заказа и последующего приобретения в ходе реализации можно автоматически запускать необходимые процессы для инвентаризации и управления идентичностью.
ЗАКЛЮЧЕНИЕ
Концепция SOA-совместимой интеграционной архитектуры, в том числе MDB, пока еще молода. Но уже очевидно, что она предоставляет надежный фундамент для администрирования ресурсов ИТ, мониторинга и оптимизации влияния ИТ на деловые процессы. Отход от изолированного наблюдения и поддержания различных хранилищ данных ведет в конечном итоге к тому, что администрирование ИТ на предприятиях превращается из заведомо непопулярной и непрозрачной строки в бюджете в экономически контролируемый, минимизирующий риски инструмент управления.
Георг Лауэр — региональный менеджер по обслуживанию компании СА.
? AWi Verlag
CMDB и MDB
MDB способна функционировать как ITIL-совместимая CMDB, но обратное утверждение несправедливо. CMDB «видит» лишь данные, относящиеся к конфигурации, тогда как MDB в наиболее расширенной версии служит в качестве стартовой площадки для всех управляющих данных об активах. MDB представляет собой оперативную базу данных с управляющей информацией, в то время как реализация CMDB в соответствии с ITIL предполагает лишь сведение воедино данных от различных инструментов, что, в принципе, можно сделать и при помощи таблицы Excel. Иначе говоря, рассмотрению подлежат не реальные производственные данные, а лишь извлеченные, трансформированные. Воспроизведение данных также не предусмотрено. Кроме того, сбор информации чаще всего происходит с точки зрения приложения (в большинстве случаев — службы помощи или поддержки). Поэтому она не обладает общим, подходящим для каждого инструмента форматом данных.