Эксплуатация ЦОД «по старинке» — с раздельным управлением различными инженерными подсистемами — становится по меньшей мере неэффективной. На то есть ряд весомых причин, и прежде всего — повышение плотности ИТ-оборудования. Полностью заполненная серверами стойка сегодня потребляет от 6 до 35 кВт электричества, тогда как многие построенные ранее ЦОД рассчитаны на 2–5 кВт на стойку. Установка нового ИТ-оборудования может привести к перегрузке системы электропитания, перегреву оборудования, снижению требуемого уровня резервирования. Чтобы предупредить любые инциденты, необходимо четко планировать разного рода добавления и изменения, а для этого обслуживающему персоналу нужна достоверная информация о ресурсах и возможностях инженерной инфраструктуры.

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

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

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

«Лоскутное» построение инженерной инфраструктуры негативно сказывается на эффективности ЦОД. Однако дело не только в этом: отсутствие взаимодействия между ее элементами становится просто опасным. Как отмечает Максим Прудников, руководитель отдела разработки компании «Логический Элемент», если такой интеграции нет, диспетчеру приходится собирать информацию с каждой отдельной системы контроля, что усложняет и замедляет процесс обработки данных и последующего принятия решения. А это недопустимо в ситуациях, когда необходимо оперативно реагировать на аварийные сбои.

Поучительный пример приводит Алексей Карпинский, директор департамента по поддержке продаж компании «Астерос»: «Когда в региональном ЦОД, принадлежащем одному из наших крупных заказчиков, сработала система пожаротушения, из-за отсутствия интеграции между системами безопасности и управления инженерной инфраструктурой сотрудник, который отвечал за функционирование ЦОД, узнал об аварии только через несколько часов. Работа не была прекращена вовремя, что привело к аварии системы охлаждения, а затем к полной остановке объекта с серьезным финансовым ущербом для бизнеса. Только после такой крупной аварии заказчик понял, что наличие выделенной системы мониторинга датчиков вовсе не означает, что все будет работать в автономном режиме».

При подобных авариях заказчик нередко предъявляет претензии к интегратору, предполагая наличие ошибок при проектировании или реализации. Система комплексного мониторинга позволяет выявить «истинного виновника» проблемы: в любой момент можно ознакомиться с записями из системных журналов, которые ведутся автоматически, установить последовательность событий, проверить действия системы и дежурного персонала. Только в этом случае удастся установить причину аварийной ситуации и предпринять корректирующие действия на будущее.

ВСТРОЕННЫЕ СРЕДСТВА

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

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

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

Рисунок 1. Управляемый блок розеток (PDU) компании APC by Schneider Electric.Следует различать те ресурсы, которые потенциально могут быть предоставлены конкретной стойке или устройству, и те, которые она может реально использовать. Первые определяются характеристиками системы электропитания и охлаждения, а вторые измеряются непосредственно в стойке при помощи разного рода датчиков, «интеллектуальных» блоков розеток (см. Рисунок 1) и пр. Существенная разница в этих двух характеристиках говорит о наличии серьезных проблем — например, поток холодного воздуха блокируется пучком кабелей или просачивается в горячий коридор, минуя внутристоечное пространство с работающим в нем ИТ-оборудованием. Грамотно спроектированная система управления должна фиксировать подобные моменты, сигнализируя о них обслуживающему персоналу.

ДОПОЛНИТЕЛЬНЫЕ ДАТЧИКИ

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

Большая группа датчиков и других технических средств служит для обеспечения контроля доступа. Датчики открытия/закрытия дверей и дистанционно управляемые замки могут устанавливаться как на общую дверь в вычислительный зал, так и на дверь каждого шкафа — все зависит от специфики объекта. Камеры видеонаблюдения должны располагаться так, чтобы было четко видно все входы и выходы, а также все коридоры между стойками с оборудованием. Если бюджет проекта не позволяет оснастить вычислительный зал такими камерами, вместо них можно использовать более дешевые датчики движения. Для фиксации фактов несанкционированной установки или неразрешенного извлечения оборудования целесообразно каждую стойку оснастить датчиками вибрации. Наконец, при наличии окон (выходящих как наружу, так и в другие помещения) понадобятся датчики, фиксирующие разбитие стекла.

Интеграция средств безопасности (контроль доступа, охранная и пожарная сигнализации и т. д.) в единую систему управления представляет ряд сложностей. Как рассказывает Алексей Карпинский, проблемы здесь могут возникнуть по двум причинам — организационной и технологической. Если за объект отвечает внешняя или внутренняя служба безопасности (иногда МВД), то обычно на нем уже установлено специализированное оборудование — возможно, решения Bosch, Siemens или системы российских производителей («Болид», «Рубеж» и др.). Все регламенты обмена данными в обязательном порядке придется в этом случае согласовывать со службой безопасности. Как правило, техническая система безопасности остается самостоятельной и автономной, своего рода «государством в государстве», но определенная часть информации может передаваться в общую систему управления в целях мониторинга. По словам специалиста «Астерос», если организация коммерческая и старается не отставать от прогресса, ее руководство обычно дает разрешение на интеграцию систем безопасности в общую систему управления ЦОД. Тогда можно подключить необходимый блок контроллеров и организовать сбор информации при помощи традиционных решений. Однако российские системы зачастую основываются на устаревших протоколах, и поэтому для них приходится разрабатывать дополнительные драйверы.

В последнее время широко обсуждается возможность дистанционного обнаружения свободных монтажных мест (U) в стойке/шкафу с помощью технологий радиочастотной идентификации (RFID). Концептуально решение очень простое: на каждую единицу оборудования в стойку устанавливаются бесконтактные метки, контролируемые специальным сканером. Когда оборудование инсталлируется, система автоматически распознает, какой сервер находится в конкретной стойке на конкретном месте, и записывает эту информацию в базу данных. «Такое решение оптимально, когда у клиента внедрена система управления активами, в которой ведется учет всего ИТ-оборудования, а RFID-метки сопряжены с этой базой данных, — уточняет Алексей Карпинский. — Но пока мы не видели ни одной российской инсталляции подобного рода».

В системе контроля электропитания конечными «датчиками» служат «интеллектуальные» блоки розеток. Однако, по словам Владислава Яковенко, руководителя отдела инфраструктурных проектов компании «Комплит», заказчики часто отказываются от такого решения из-за его высокой стоимости — в этом случае электрическая нагрузка вычислительного зала или группы шкафов контролируется электросистемой ЦОД.

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

АГРЕГИРУЯ ДАННЫЕ

Индивидуальное подключение к IP-сети множества датчиков не слишком разумно. Специалисты APC by Schneider Electric рекомендуют использовать специальные агрегаторы (см. Рисунок 3), которые собирают информацию с нескольких датчиков, фильтруют и анализируют ее, а «наверх» (в систему управления) отправляют только заслуживающие внимания данные. Такой подход позволяет существенно уменьшить число индивидуальных подключений, сократить объем служебного трафика, упростить техническую поддержку сети. Кроме того, заметно снижается объем ненужной информации, а ИТ-персонал привлекается только тогда, когда это действительно необходимо.

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

Важнейшей функцией системы управления является выдача предупреждающих сообщений в режиме реального времени. Причем система не должна «ждать», когда ситуация окажется близка к аварийной или сбой уже произойдет. Предупреждения должны выдаваться, когда, например, уровень энергопотребления или температура в стойке достигли установленного порога или включение резервных систем привело к снижению уровня отказоустойчивости, заданного для конкретного объекта.

«СЕРДЦЕ» ИНТЕГРАЦИИ

Такие интеграторы, как «Астерос» и «АйТи», реализуют свои решения на базе систем SCADA, которые собирают информацию от контроллеров и представляют ее в графическом формате (например, накладывая на план ЦОД). По мнению Алексея Карпинского, обычные приложения Windows для этих целей не подходят, тогда как система SCADA может собирать и обрабатывать до 300 тыс. параметров одновременно. Кроме того, ее можно дополнить модулем аналитики, который способен выявлять различные тренды (энергопотребление, температура и пр.), находить зависимости, отображать разные срезы информации и строить прогнозы. «Астерос» применяет для мониторинга оборудование и базовое ПО компании Delta Controls и дополнительно ПО Iconics для графического отображения информации и блока аналитики.

Другой интегратор, компания «Утилекс», в качестве центральной системы управления использует в своих проектах систему Microsoft System Center Operations Manager 2007 R2. Для интеграции с продуктами сторонних производителей чаще всего выбирается поддерживаемый этой системой протокол SNMP. Если производители используют собственные протоколы, например VMware API, то специалисты «Утилекс» применяют специальные коннекторы, как отдельные, так и реализованные в составе «сторонних» продуктов, например Opalis.

При построении комплексных систем управления инженерной инфраструктурой Валерий Волобуев считает наиболее удобным протокол Modbus TCP, который широко поддерживают производители различного климатического и электротехнического оборудования. В системе «Астерос» сбор данных с контроллеров осуществляется по открытому протоколу BACnet IP. «Благодаря тому, что этот протокол поддерживается оборудованием практически любого производителя, мы можем построить комплексную систему управления на объекте, где ранее были установлены системы третьих компаний. Еще два года назад в такой ситуации пришлось бы “сносить” действующее ПО и “железо” и создавать систему с нуля», — подчеркивает Алексей Карпинский.

Сергей Ермаков, технический директор «Инэлт», считает, что все многообразие решений по созданию единых СУ, охватывающих различные инженерные подсистемы, на практике сводится к системам двух типов: на базе локальной сети с использованием протокола SNMP и на базе промышленных контроллеров. Эта инжиниринговая компания разработала два готовых продукта: UPSLook и JSLook. Система UPSLook базируется на протоколе SNMP, и, по словам специалиста «Инэлт», является универсальным программным средством для сетей IP, в том числе для мониторинга любого числа ИБП всех популярных марок, представленных в России. В свою очередь, JSLook использует для мониторинга ИБП, ДГУ, кондиционеров или другого инженерного оборудования промышленные протоколы Jbus, ModBus и ProfiBus. Поддержка широкого набора протоколов упрощает интеграцию различных инженерных подсистем.

Основная функция решений «Инэлт» — контроль параметров электропитания (показатели качества электроэнергии по ГОСТ 13109-97, уровни потребления тока). Программы осуществляют непрерывное протоколирование событий, поэтому фиксируют не только факты пропадания-восстановления электропитания, но и время срабатывания автоматических выключателей, подключения/отключения новых нагрузок (серверов и прочего оборудования). Применяемые в этих решениях SNMP-адаптеры и преобразователи оснащены термопарами и датчиками влажности, поэтому обеспечивается и контроль микроклимата. А при установке сухоконтактных интерфейсов возможна передача в системы мониторинга СБГЭ также информации о доступе в помещения, например с регистрацией времени открытия/закрытия дверей.

Рисунок 4. Пример интерфейса системы «Элемент».Одним из основных достоинств своей программной системы управления «Элемент» (см. Рисунок 4) представители компании «Логический Элемент» считают отсутствие привязки к конкретному типу оборудования сбора и передачи данных. Компания имеет в своем арсенале набор аппаратных средств для мониторинга инженерных систем, а ее система управления поддерживает такие стандартные протоколы, как SNMP, Modbus и LonWorks, но при этом она позволяет и гибко интегрировать существующие инженерные и технологические системы предприятия, а также их отдельные компоненты (например, датчики, отдельные механизмы) по «родным» протоколам и интерфейсам.

По словам Максима Прудникова, немалая часть производителей использует собственные протоколы обмена данными, поддержка которых требует написания специальных драйверов, и эта задача остается одной из самых трудоемких в подобных проектах. Процесс интеграции с оборудованием сторонних производителей по нестандартному протоколу может занимать от 32 часов до 5 месяцев с выездом к заказчику или производителю. При этом больше всего времени — до 3 месяцев — уходит на заключение соглашения о неразглашении (Non-disclosure Agreement), а написание драйвера занимает от 4 часов до 5 дней.

К КОМПЛЕКСУ С РАЗНЫХ СТОРОН

Наиболее функциональные и комплексные системы управления инженерной инфраструктурой сегодня предлагают компании, выпускающие широкий спектр инженерного оборудования, включая ИБП, системы охлаждения, монтажные конструктивы. В их числе APC by Schneider Electric, Emerson Network Power, Rittal.

Так, предлагаемый APC by Schneider Electric комплекс, состоящий из сервера InfraStruXure (ISX) Central и набора программных модулей, полностью русифицирован, имеет открытый программный интерфейс Web API и снабжен набором средств разработчика для интеграции с другими приложениями. Мониторинг параметров окружающей среды и контроль доступа выполняют устройства APC NetBotz, а контроль электропитания — блоки APC Switched PDU. Для управления оборудованием сторонних производителей система ISX Central использует стандартные средства ModBus и SNMP, причем, по заверению представителей APC by Schneider Electric, эти протоколы позволяют собирать данные с устройств большинства ключевых производителей.

Более узкоспециализированные производители тоже активно работают над расширением функционала своих средств управления. В частности, система управления электропитанием PowerAlert NMS (Network Management System, NMS) компании Tripp Lite, помимо ИБП и блоков распределения питания, способна работать с датчиками температуры, влажности и т. п. Как отмечают представители компании, поскольку эти датчики подключаются к карте управления ИБП или БРП, нет необходимости прокладывать несколько информационных кабелей для разных датчиков — все они контролируются по одному информационному каналу. Находящиеся на датчиках температуры и влажности группы сухих контактов позволяют подсоединять дополнительные датчики, например для контроля протечек, задымления и доступа. Управление всеми компонентами осуществляется через единый интерфейс PowerAlert NMS, а максимальное число управляемых элементов ограничивается лишь количеством поддерживаемых IP-адресов — до 250 на одну систему администратора.

До сих пор мы не упоминали об одной важной функции, которую обычно относят к сфере управления «физической инфраструктурой». Это контроль кабельных соединений, который уже давно обеспечивают ведущие поставщики структурированных кабельных систем (СКС). Соответствующие технические решения наделяют кабельные системы «интеллектом», что позволяет фиксировать факты подключений/отключений на уровне коммутационного поля, автоматически вести кабельный журнал, строить карту сети с указанием физических мест установки оборудования и пр. Часть этих производителей ведет активную работу по наделению своих систем управления возможностями контроля микроклимата в местах размещения оборудования, уровня энергопотребления и пр. Таким образом, они со своей стороны начали движение в сторону комплексных систем управления инженерной инфраструктурой.

Компания Nexans первой из производителей СКС интегрировала систему контроля микроклимата, физического доступа и электропитания (EMAC) в свою систему контроля сетевой инфраструктуры LANsense. EMAC способна предоставлять сторонним программно-аппаратным комплексам информацию, собираемую с различных датчиков: например, данные о температуре и влажности в шкафу — системам кондиционирования, а сведения по задымлению — системам пожаротушения. Возможность активного управления кабельной инфраструктурой дает ряд дополнительных преимуществ. Например, по словам Евгения Власова, регионального менеджера по решениям для ЛВС компании Nexans, в случае несанкционированного доступа в шкаф или какого-либо события в сети, например при регистрации неавторизованного MAC-адреса на том или ином порту, система способна не только оповестить администраторов, но и отключить порт, коммутатор, сервер или остановить предоставление сервиса. Подобные возможности существенно повышают эффективность работы средств безопасности.

Программно-аппаратный комплекс AMPTRAC компании Tyco Electronics с новыми версиями ПО — iTRACS for Converged Building Systems (iCBS) и iTRACS for Converged Data Center (iCDC) — тоже превратился в многофункциональный инструмент для контроля за объединенной физической инфраструктурой офисного здания и ЦОД. Теперь система AMPTRAC совместима с управляемыми блоками розеток электропитания и мониторами состояния окружающей среды сторонних производителей, поддерживающих протокол SNMP. Она способна контролировать энергопотребление посредством опроса устройства (или присоединенного к нему источника питания) для получения актуальной информации о расходе электроэнергии. Кроме того, в целях контроля могут использоваться паспортные данные о максимальном энергопотреблении конкретного оборудования, заявленные его производителем, или нормативы, установленные самим заказчиком. Отметим, что система AMPTRAC поддерживает технологию виртуализации и распознает многочисленные виртуальные серверы, выполняющиеся на одном физическом сервере.

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

Интеграторы используют системы управления СКС в своих комплексных решениях. Так, «Астерос» уже имеет в своем «послужном списке» проекты, где в общую систему управления были интегрированы функции контроля 29 тыс. портов интеллектуальной СКС Systimax iPatch, а в течение ближайшего полугода компания планирует закончить интеграцию продуктов других производителей — АМР AMTRAC и Panduit PanView.

ГРАФИКА В ПОМОЩЬ

Развитые графические интерфейсы — это уже базовые возможности любой современной серьезной системы. По мнению Алексея Карпинского, следующим шагом станет переход на трехмерное изображение, однако проблема в том, что нынешние системы управления используют только статичные представления и не поддерживают (или плохо поддерживают) трехмерные модели, создаваемые в системах автоматизированного проектирования (САПР).

«Часто после полугода эксплуатации реальное состояние ЦОД может значительно отличаться от первоначальной модели, которая была зафиксирована в проектной документации. Если трехмерные изображения, созданные при проектировании объекта, можно будет загружать и использовать в системе мониторинга и диспетчеризации, то это позволит значительно сократить затраты на разработку и внесение изменений, а также на поддержку технической документации в актуальном состоянии. При решении этих задач “законодателем мод” будут не ЦОД, а коммерческие здания, потому что при сходных задачах, на автоматизацию зданий выделяется значительно больше средств», — полагает он.

Подтверждением этих слов служит реализация компанией iTracs в своей новейшей версии ПО iCBS продвинутого графического интерфейса для визуализации трехмерных изображений элементов объединенной инфраструктуры. По словам Владимира Стыцько, директора по продажам AMP Netconnect/Tyco Electronics в России, многообразие предустановленных шаблонов с изображениями монтажных шкафов, систем бесперебойного электроснабжения, систем охлаждения, телекоммуникационного оборудования и других элементов позволяет создать очень наглядное виртуальное отображение реальной инфраструктуры. При помощи ПО iCBS можно моделировать планируемые изменения в существующей инфраструктуре без вмешательства в ее работу: например, задав в качестве сценария добавление сервера, посмотреть, как его реализация повлияет на текущее состояние ЦОД.

АНАЛИЗИРУЯ PUE

Комплексное оснащение объекта средствами измерения энергопотребления уже на 99% решает задачу по расчету очень важного параметра — Power Usage Effectiveness (PUE), который определяется как отношение полной энергии, подаваемой на площадку, к энергии, потребляемой ИТ-оборудованием. Разработчики СУ пользуются этой возможностью. Так, ПО iCBS способно накапливать данные от различных элементов инфраструктуры и предоставлять отчет по PUE в обычном табличном формате или в виде «приборной доски» (см. Рисунок 5).

Рисунок 5. Система iTRACS for Converged Building Systems (iCBS) предоставляет на «приборной доске» значение PUE, а также коэффициент DCE (Datacenter Efficiency) — величину, обратную PUE (DCE = 1/PUE).

Предоставление базового отчета по показателю PUE является частью функционала модуля Energy Efficiency системы ISX Central. Но разработчики APC by Schneider Electric пошли дальше, реализовав в своей системе расширенный анализ PUE, возможность идентификации потерь эффективности подсистем, а также анализ использования ресурсов и моделирование соответствующих процессов.

Отчеты по PUE могут генерироваться и системой «Элемент». Как пояснил Максим Прудников, на основе собранных системой данных по энергопотреблению можно проводить анализ «слабых» сторон объектов, включая расчет эффективности перехода на многотарифный режим потребления электроэнергии. Пока подобный анализ проводится в ручном режиме, но уже в ближайшее время «Логический Элемент» планирует автоматизировать этот процесс.

Комментируя перспективы использования данных по энергоэффективности в биллинговой системе коммерческого ЦОД или для оценки сокращения затрат на эксплуатацию, Алексей Карпинский подчеркивает: «На Западе такие системы используются, но большинство российских заказчиков пока не видят смысла в подобных решениях — цена электроэнергии, ее доля в составе общих затрат у нас и на Западе отличаются. Кроме того, ИТ-подразделения редко задумываются о затратах на энергию, потому что они не включаются в ИТ-бюджет».

МОСТ К ИТ

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

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

Системы управления, обеспечивающие взаимодействие инженерной инфраструктуры и ИТ-систем, в частности для интеллектуального выделения ресурсов, получили название Data Center Infrastructure Management (DCIM). По данным Gartner, пока уровень проникновения системы класса DCIM составляет всего 1%, однако к 2014 году этот показатель увеличится до 60%.

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

Технической основой для организации взаимодействия между системами управления инженерным и ИТ-оборудованием (включая сетевую инфраструктуру) может служить протокол SNMP. Причем SNMP поддерживается современными промышленными пакетами SCADA, что позволяет им самостоятельно работать с ИТ-оборудованием.

Отдельные функции по взаимодействию с ИТ есть у целого ряда систем управления инженерной инфраструктурой. Например, Rittal предлагает специальный программный пакет для интеграции RiZone c управляющим ПО Microsoft, которая обеспечивает двунаправленное взаимодействие между серверами/приложениями и инженерной инфраструктурой. Скажем, в случае выхода из строя части систем охлаждения, RiZone может автоматически распределить вычислительную нагрузку между серверами, снижая тепловую нагрузку на проблемную стойку.

В октябре текущего года компания Emerson Network Power представила свою стратегию по разработке DCIM-системы Trellis (см. Рисунок 6), которая, как утверждают представители компании, станет первой интегрированной системой для управления инфраструктурой ЦОД, «закрывающей разрыв» между управлением ИТ-оборудованием и инженерными системами и использующей единую информационную базу данных. В результате приобретения компании Avocent в 2009 году Emerson Network Power получила финальный компонент, необходимый для выпуска такой единой системы. В процессе создания Trellis компания интегрирует технологии управления инфраструктурой, имеющиеся в продуктах Aperture, Avocent и Liebert. Согласно ее прогнозам, основные модули Trellis станут доступны в IV квартале 2011 года.

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

Александр Барсков — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: ab@lanmag.ru.

Рисунок 2. Примеры размещения различных датчиков в вычислительном зале ЦОД.

Рисунок 3. Агрегация датчиков в системе мониторинга.

Рисунок 6. Архитектура DCIM-системы Trellis.