Rambler's Top100
Статьи ИКС № 03-04 2015
Игорь ДОРОФЕЕВ  21 апреля 2015

DCIM или не DCIM – вот в чем вопрос

Рынок систем DCIM оценивается аналитиками в миллионы долларов, однако скептики отмечают низкую коммерческую эффективность внедрения таких систем и даже сравнивают их с мыльным пузырем.

Игорь ДОРОФЕЕВ, генеральный директор, «АйКорд»

Системы управления инфраструктурой дата-центра (Data Center Infrastructure Mana­ge­ment, DCIM) выпускаются множеством компаний, от неизвестных стартапов до именитых грандов. Тем не менее, когда вопрос выбора и внедрения системы переходит в практическую плоскость, возникает масса проблем, требующих решения.

Что такое DCIM

Автоматизированные системы диспетчеризации и управления, в том числе для зданий и сооружений, вещь совсем не новая. Вспомним популярную 10–15 лет назад концепцию умного дома. Она была предшественницей систем управления зданием (СУЗ). Развитие технологий умного дома во всем мире держалось на трех китах: экономии ресурсов, наблюдении за состоянием и протоколировании, сервисе и удобстве управления. В России эти мотивирующие факторы работали не в полную меру: ресурсы были относительно дешевы, мониторинг и управление могли осуществляться в ручном режиме, силами нанятого персонала. При существенной стоимости внедрения окупаемость таких систем была под вопросом. Поэтому рынок систем умного дома и СУЗ рос достаточно медленно, а качество реализации зачастую было весьма невысоким.

Еще один пример такого же сорта – так называемые системы интеллектуального управления (СИУ) структурированных кабельных систем. Подобные системы тоже внедрялись как дорогие игрушки без достаточного понимания их необходимости. Часто можно было видеть, как через несколько месяцев эксплуатации СИУ СКС попросту выключали. То есть необходимость их внедрения была переоценена. Забегая вперед, следует сказать, что вторую жизнь СИУ дала как раз их реализация в центрах обработки данных, а большинство таких систем явились родоначальниками решений в области DCIM.

Итак, по мере развития отрасли ЦОДов зрело понимание соответствия функционала СУЗ задачам, которые ставились перед инженерной инфраструктурой дата-центров. Действительно, ресурсопотребляющие ЦОДы требовали оптимизации затрат; задачи обеспечения надежности, безопасности, быстрого оперативного или автоматизированного управления в нештатных ситуациях могли оправдать внедрение дорогостоящего инструментария. Системы DCIM унаследовали подходы, которые применяются для создания автоматизированных систем диспетчеризации и управления (АСДУ), автоматизированных систем управления технологическими процессами (АСУ ТП), систем управления зданием. Однако системы управления инфраструктурой ЦОДа управляют не только инженерной инфраструктурой, их функционал намного шире.

С учетом сегодняшних трендов развития рынка систему DCIM можно описать как программно-аппаратный комплекс, который собирает данные, анализирует их и по необходимости управляет оборудованием во всех аспектах функционирования ЦОДа. Основная цель внедрения системы – оптимизация затрат, управление и обеспечение рабочих характеристик ЦОДа. Предполагается, что система отличается гибкостью и может адаптироваться под нужды службы эксплуатации и владельца бизнеса.

В общем случае систему целесообразно разбить на три связанных логических блока (см. рисунок): управление инженерной инфраструктурой, управление ИТ-инфраструктурой и управление бизнес-процессами. При этом DCIM находится в окружении и должна учитывать факторы, которые оказывают на нее непосредственное влияние, а именно: операционную или эксплуатационную модель дата-центра, персонал, существующие активы, ресурсы, внешнее окружение, предлагаемые ЦОДом сервисы.

Управление инженерной инфраструктурой. Это наиболее проработанная задача. Речь идет о мониторинге и управлении оборудованием инженерных систем, и в этом плане нужно отметить значительное заимствование подходов АСДУ и СУЗ. Именно поэтому под DCIM нередко ошибочно понимают АСДУ инженерного оборудования.

Предпосылки для внедрения подсистемы мониторинга заключаются в необходимости постоянного отслеживания текущей ситуации и ее протоколирования. Как правило, контролируются ключевые параметра микроклимата ЦОДа, параметры сети и оборудования электроснабжения, состояние элементов прочих систем. Стратегия получения параметров может быть закрытой или открытой. В случае закрытой стратегии возможности системы ограничены функционалом производителя, и расширение или портирование данных со стороны прочего оборудования возможны на достаточно простом уровне. При этом точки сбора данных существуют и в смежных системах, более того, они дублируют требуемые для DCIM. Открытая стратегия предполагает получение любых нужных данных от разнородных смежных систем.

Вторая функциональная задача – управление – предполагает работу с исполнительными механизмами того же самого инженерного оборудования. Управление может быть как автоматизированным, так и ручным – в целях оперативного реагирования или сервисного обслуживания.

Управление ИТ-инфраструктурой. В этой статье управление ИТ-оборудованием, данными и сервисами вряд ли стоит рассматривать подробно. Эти системы давно и успешно развиваются, подходы к управлению ИТ-услугами или процессами управления информационными сервисами и системами (ITSM) вполне зрелые и могут быть успешно использованы в операционной модели ЦОДа. В рамках DCIM непосредственный интерес представляет корреляция данного блока с остальными для более эффективного управления ЦОДом, в частности, управление виртуальными серверами, распределение нагрузки в разрезе потребления ресурсов и анализ сетевого трафика, в том числе в качестве меры обеспечения комплексной безопасности.

Управление бизнес-процессами. Здесь имеются в виду получение и обработка данных, на основе которых можно осуществлять и корректировать бизнес-процессы ЦОДа, а также выполнять локальные операции, которые хорошо автоматизируются. Традиционный функционал данного блока – автоматизированный расчет параметров и показателей ЦОДа, в том числе специальных. На основе собранных аналитических данных проводится оценка влияния событий, планирование, прогнозирование отказов, управление загрузкой ресурсов и пространством ЦОДа. Сюда же встраиваются справочно-информационные системы, системы документооборота и учета активов. Последние также позволяют управлять изменениями. В качестве возможного расширения можно отметить интеграцию с экономическими модулями или, скажем, системами биллинга.

При целевой ориентации DCIM на бизнес-процесс ожидается, что программно-аппаратный комплекс будет способствовать поддержанию основных характеристик ЦОДа: эффективности, надежности, доступности и безопасности. От управления физической инфраструктурой система переходит к управлению информацией. Причем архитектура системы должна быть открытой и допускать получение данных из любых возможных точек наблюдения в ЦОДе. А реализация продукта должна быть гибкой, чтобы позволить сконфигурировать систему, наиболее приспособленную для задач конкретного ЦОДа. Например, в сфере безопасности помимо физической или пожарной безо­пасности в DCIM может быть реализована полная модель угроз, включая информационную безопасность и человеческий фактор.

Таким образом, сегодня самое актуальное требование к системе DCIM – это полная интеграция различных сервисов, которые обеспечивают работу ЦОДа. Не случайно некоторые производители уже говорят о системе, которая может придти на смену DCIM, имея в виду операционную систему ЦОДа (DCOS). Последняя ориентирована главным образом на информационную составляющую, предоставление услуг, ИТ-оборудование и программное обеспечение. Физическая инфраструктура, безусловно, попадает в сферу действия DCOS, но реализация многих аспектов переносится из физической плоскости в логическую.

На практике воплощения описанной модели далеки от идеала. Сохраняются проблемы интеграции разных инфраструктур и бизнес- и аналитических модулей в полноценную комплексную систему, а экономическая целесообразность внедрения и окупаемость DCIM по-прежнему под вопросом.

Варианты реализации

Опишем наиболее распространенные типы систем контроля и управления ЦОДа, причем постараемся рассмотреть их в развитии – от простейших вариантов до передовых.

Безусловно, самый простой вариант – это использование NMS- и SNMP-совместимых устройств. Это даже трудно назвать системой. Это, скорее, подход, который применяли и применяют системные администраторы и прочие ИТ-специалисты, пытаясь получить информацию о своем ЦОДе и размещенном в нем оборудовании. Как правило, к нему прибегает служба эксплуатации, для которой в ЦОДе при строительстве не предусмотрели никакой системы мониторинга, не говоря уже об управлении. Точки мониторинга создаются не там, где нужно, а там, где получается. Данные собираются с устройств и оборудования, в которые можно установить какие-либо коммуникационные карты или платы. Развитие этого метода – сбор информации по локальным протоколам и конвертация в IP данных, передаваемых по полевым шинам. Некоторые данные, например о температуре в серверах, могут сниматься непосредственно с ИТ-оборудования.

Что касается визуализации и ведения аналитики, то здесь огромный простор для творчества. Для визуализации или редактирования планов и чертежей могут использоваться различные системы автоматизированного проектирования и черчения, графические редакторы, редакторы диаграмм и блок-схем. Самый популярный инструмент для планирования, управления и расчетов в этом случае – электронные таблицы, входящие в стандартные офисные пакеты программного обеспечения. С их помощью рисуются фасады стоек с описанием параметров и ведутся учет и планирование активов и ресурсов. Стандартными средствами таких пакетов также могут быть рассчитаны и отображены отдельные показатели. Нельзя сказать, чтобы этот вариант канул в Лету, в небольших серверных и ЦОДах он продолжает использоваться. Отметим также, что он в полной мере опирается на открытую стратегию получения данных о ЦОДе.

Второй, альтернативный, вариант строится на решении классической задачи АСУ ТП. Для создания системы управления ЦОДа используются наработанные решения и промышленное оборудование автоматизации, типовые контроллеры, полевые шины, SCADA-системы. Сюда же можно отнести и оборудование для управления системами зданий. Достоинства данного подхода – накопленный за годы опыт, надежность оборудования, гибкие и широкие возможности мониторинга и управления. Визуализация обеспечивается средствами стандартных графических интерфейсов. Самым главным недостатком, помимо высокой стоимости решения, является отсутствие аналитических модулей. Данные приходится либо анализировать «в лоб», либо разрабатывать те или иные специальные алгоритмы, причем делать это для каждого конкретного объекта заново, что удорожает проект в целом. Тем не менее именно этот вариант наиболее востребован для больших ЦОДов, которые были построены за последние пять-десять лет.

Рынок ЦОДов в целом и DCIM в частности искал решение промышленного уровня, но без ненужной избыточности и дороговизны систем промышленной автоматизации. Круг решаемых задач и контролируемых параметров в ЦОДе значительно уже, а реализация может быть упрощена за счет применения типовых блоков, датчиков, стандартов и протоколов. В итоге сформировался целый класс систем, как правило, на базе проприетарных протоколов, которые работают поверх IP или по выделенным линиям связи. То есть решение позиционируется как завершенная комплексная система от производителя. В ней используются простейшие контроллеры и датчики, для подключения которых может задействоваться функционал СКС, определяется ограниченный набор ключевых параметров и внешних данных, а управление реализуется через блоки сухих контактов и релейных модулей. Упор в системе делается на визуализацию. Помимо отображения параметров можно создать графическую модель дата-центра, рассматривать планы расположения оборудования, фасады стоек и и.д. Аналитические модули также достаточно простые, обеспечивающие расчет самых известных макропоказателей, например PUE. Следующий шаг – появление облачных сервисов с тем же функционалом, DCIM как услуга.

К этому типу относится большинство решений, имеющихся сегодня на рынке. Очевидная проблема – обособленность системы внутри ЦОДа, что часто приводит к дублированию систем управления, например в случае использования решения промышленной автоматизации. Управление инженерной инфраструктурой не затрагивает сектор информационных систем и бизнес-процессов. Функционал таких систем достаточен для небольших ЦОДов, но по мере увеличения масштаба недостатки становятся все более явными.

Наконец, нужно отметить важный момент, касающийся разработчиков – вендоров этих систем. Их разработка, как правило, начиналась с какой-либо одной сферы, скажем, управления электроснабжением, кондиционированием или СКС. Следует обращать пристальное внимание на то, как в дальнейшем наращивался функционал для смежных систем. Часто решения вне зоны основной компетенции вендора выполнены «для галочки» и далеки от идеала.

В последнее время передовые игроки рынка пытаются выйти за пределы управления инженерной инфраструктурой и предлагают комплексные программно-аппаратные решения, связанные с управлением информационными сервисами и системами и имеющие расширенные возможности управления бизнес-процессами. В настоящий момент интеграция с системой управления ИТ-инфраструктурой происходит на уровне объединения независимых платформ. Это предполагает открытую модель получения внешних и внутренних данных с разных устройств и управление распределенной инфраструктурой. Для бизнес-аналитики появляется возможность гибко задавать отслеживаемые параметры, интегральные характеристики, в том числе собственные. Благодаря этому есть надежда, что появятся новые метрики эффективности, которые были сформулированы достаточно давно, но не были реализованы, например, расчетная производительность ИТ-систем в привязке к энергопотреблению оборудования.

При всей прогрессивности наиболее полных реализаций хотелось бы отметить определенные логические неувязки. Первый вопрос связан с целевой группой, для которой разрабатывается интегральный продукт. В ЦОДе работают разные специалисты, есть разные департаменты, со своими задачами, бюджетами и т.д. Что будет стимулировать отказ специалистов от локальных и более цельных инструментов в пользу «сырого» интегрального решения? Далее, с точки зрения бизнес-процессов модели, закладываемые в систему, крайне простые. Формальная привязка операционных затрат к этим по сути творческим задачам вызывает много вопросов. Например, стоимость продуктов и услуг, созданных на базе ЦОДа, может многократно превышать операционные расходы, а модель развития бизнеса качественно отличаться от заложенных шаб­лонов.

Тем не менее любой из рассмотренных вариантов имеет право на существование и эффективную эксплуатацию в соответствии с поставленными задачами и окружающими условиями.

Типовые ошибки внедрения

Изучая ошибки, которые могут быть допущены при внедрении DCIM, целесообразно опираться на уровень предлагаемых решений, накопленный опыт и статистику, а желаемые в идеале опции, например интеграцию блоков системы воедино, оставить на будущее. На примерах покажем некоторые проблемы, которые возникают при развертывании функционального блока управления инженерной инфраструктурой.

Пример 1. Внедрение DCIM без привязки к условиям ЦОДа

Как правило, системы управления инсталлируются в рамках комплексного проекта создания ЦОДа. При этом выбираются стандартные решения, которые никоим образом не учитывают будущие реалии. Зачастую их даже сформулировать некому. Очевидно, что идеальным будет вариант, когда сначала разрабатываются операционная модель ЦОДа и организационно-штатные мероприятия и уже на их основе реализуется DCIM, а после этапа опытной эксплуатации проводится корректировка решений в соответствии с фактически сложившимися условиями.

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

Более сложные вопросы, такие как вид и время отображения критической информации, алгоритмы действий в нештатных и аварийных ситуациях, вообще не рассматриваются и не реализуются, переносятся в зону ответственности службы эксплуатации. Между тем несвоевременная реакция персонала на события или отсутствие времени на принятие решения чаще всего и приводят к нарушению работоспособности ЦОДа.

Пример 2. Несоответствие функционала DCIM возможностям персонала и административным процедурам

По сути, этот пример является продолжением предыдущего. При внедрении системы мало разработать правила, нужно еще их выполнять. При этом любые расхождения между фактической и запланированной ситуациями будут влиять на функционирование ЦОДа. Здесь, безус­ловно, самым слабым звеном являются люди, т.е. обслуживающий персонал, а многие вопросы лежат не в области техники, а в области психологии и реализации интерфейса взаимодействия системы с оператором. Технические решения, с одной стороны, могут помочь нивелировать ущерб от потенциальной халатности и глупости, а, с другой, могут быть настолько непрозрачными, что эксплуатационщикам ЦОДа придется полагаться на авось. В этом случае обычно остро стоит вопрос оценки квалификации персонала и соответствия его компетенции задачам обслуживания системы и ЦОДа в целом.

Пример 3. Обособленность DCIM

Помимо обособленности внутренней, интеграционной, о которой уже неоднократно говорилось в данной статье, нельзя упускать из виду интеграцию с внешним окружением. Фактически речь идет о границах ЦОДа, которые с течением времени все более размываются. Где находится та грань, до которой DCIM осуществляет мониторинг и управление системами, влияющими на функционирование ЦОДа? ЦОД, очевидно, не является самодостаточным объектом, а влияние внешнего окружения плохо формализуется, будь то экономическая обстановка, обеспечение ресурсами и линиями связи или разного рода внешние угрозы.

  

Многообразие имеющихся систем мониторинга и управления, подходов к их реализации, а также динамичная ситуация на рынке DCIM не позволяют сформулировать универсальные критерии выбора и реализации систем управления ЦОДом. При выборе системы следует отталкиваться от насущных потребностей, реальных условий и модели эксплуатации, сложности и масштаба инфраструктуры. Также необходимо оценивать окупаемость внедрения системы. На растущем и быстро меняющемся рынке, вероятно, не стоит гнаться за модным трендом, а лучше посмотреть, какие насущные вопросы могут быть решены. Может оказаться, что для большинства существующих ЦОДов набор простых локальных инструментов будет более эффективен, чем полновесная комплексная система на все случаи жизни. Финансисту не придется разбираться в инженерной инфраструктуре, а системному администратору – в финансах. Да и отработанный профессиональный инструментарий в каждой из этих сфер потенциально лучше, чем интегрированный.

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!
Поделиться: