Авариям в центрах обработки данных посвящена немалая часть новостных материалов, что лишний раз подчеркивает: ЦОД — это сложный объект, с точки зрения поддержания работоспособности. В этой статье, подготовленной компанией Eaton, перечислены типичные причины аварий в ЦОДах, знание которых помогает как предвидеть развитие аварийных ситуаций, так и внедрять регламентные процедуры по быстрому устранению аварий и их последствий.
Четыре кита
Работа любого дата-центра держится на «трех китах» — энергоснабжении, охлаждении, системах мониторинга и безопасности. В последнее время, с массовым переходом на облачные приложения, к числу критически важных систем добавился и четвертый — системы телекоммуникации ЦОДа. Ведь если будет потеряна связь дата-центра с провайдерами телекоммуникационных услуг, то для клиентов он станет полностью недоступен, даже если все серверы и системы хранения данных (СХД) находятся в полном порядке.
Разумеется, типичные причины аварий — это именно та прошедшая война, к которой готовятся «генералы» в лице отделов эксплуатации. А жизнь всё время подкидывает новые нестандартные аварийные кейсы, из которых порой с честью, но чаще с убытками выходят даже ЦОДы именитых брендов.
Уровень надёжности
Напомним, что с 1990-х годов для оценки уровня надёжности центра обработки данных используется система классификации Uptime Institute, включающая четыре категории надёжности (Tier I–IV). С его помощью также рассчитывается ожидаемый коэффициент доступности сервисов для внешних клиентов, что позволяет компаниям принимать решение о том, пользоваться ли услугами данного ЦОДа или нет.
Надёжность data-центра, оцениваемая по Tier, относится к любым инженерным системам и процедурам, поддерживающих работоспособность объекта — сюда входят, к примеру, насосы, которые подают топливо для резервных дизель-генераторных установок (ДГУ), объём топлива в цистернах и наличие договоров с нефтетрейдерами, обязывающих компании к бесперебойному подвозу топливной смеси на площадку.
В последние годы коммерческие data-центры в основном строят с уровнем надёжности Tier III, который, как считается, обладает наилучшим соотношением по параметру «надёжность/стоимость систем». В Tier III используется схема резервирования 2N — это когда все компоненты продублированы. Уровень доступности для Tier III составляет 99,982 % или, по-простому, «три девятки», а ежегодное время простоя не должно превышать 1,6 часа.
Схема энергоснабжения 2N или «всего по два»
ЦОД подключают к внешним источникам электроснабжения (подстанциям оператора электрораспределительных сетей) двумя независимыми фидерами 6/10 кВ одинаковой мощности, на территории дата-центра размещаются две понижающие подстанции, на которых высокое «магистральное» напряжение 6/10 кВ понижается до 380 В (400 В) и далее подаётся на два главных распределительных щита (ГРЩ) с системой защитной автоматики. После ГРЩ напряжение подается на две группы промышленных ИБП с функцией двойного преобразования. Примером таких ИБП является модель нового поколения Eaton 93PM G2 мощностью 30-500 кВA.
На случай перехода на питание от ИБП к ним подключается две взаимно резервируемые матрицы 12-вольтовых батарей. Заряда этих батарей хватает на период работы дата-центра под полной нагрузкой до момента запуска ДГУ (обычно порядка 7-10 минут). В последнее время на замену традиционным свинцово-кислотным батареям приходят инновационные источники питания, такие как суперконденсаторные модули (например, Eaton XLM). Они охватывают диапазон мощности от 8 до 7700 кВт, обеспечивают энергоснабжение ИБП на время до нескольких минут, не требуют технического обслуживания и изготовлены из экологически чистых материалов.
С каждой группы источников бесперебойного питания по двум группам шинопроводов электроэнергия подаётся на щиты гарантированного электропитания (ЩГП) и с них уже непосредственно в машинные залы к распределительным шкафам питания стоек (ЩС). В этих шкафах напряжение 380 В (400 В) разделяется на взаимно резервируемые шины 230 В для питания компьютерного и сетевого оборудования.
Основная причина сбоя схемы 2N
Почему же происходят аварии системы энергоснабжения, если всё так хорошо продумано? Практика показывает, что наиболее частая причина возникновения аварийных ситуаций в ЦОДах — это человеческий фактор. Точнее, несоблюдение регламентных процедур по обслуживанию оборудования: не вовремя почистили от пыли распределительные шкафы, не проверили температуру контактов тепловизором, долгое время не запускали ДГУ и т. д. Тогда даже какая-то простая поломка может привести к эскалации аварийной ситуации.
Последствия
Как правило, аварии систем электроснабжения достаточно быстро устраняются и не критичны для дальнейшей работы центра. Да, они чреваты потерей части данных, но бэкапы и репликация виртуальных машин в другие data-центры и здесь позволит выйти «сухим из воды». При этом обесточенные серверы и системы хранения в ЦОДах остаются работоспособны — после подачи электропитания и перезагрузки они продолжат функционировать в штатном режиме.
Система охлаждения
Климатические системы дата-центра более сложны в обслуживании в сравнении с электрооборудованием. Течи в многочисленных трубопроводах с жидким хладагентом, влияние погодных аномалий внешней среды, даже активное распространение тополиного пуха или песчаной взвеси в воздухе и прочие тому подобные причины могут привести к выходу из строя кондиционеров, чиллеров и других компонентов климатических систем ЦОДа.
Причины аварии
При превышении температуры в серверных залах выше нормы, начинаются отказы ИТ-оборудования. Если процесс принимает неуправляемый характер, помимо потери данных возможны выход из строя электронных компонентов серверов и систем хранения. На этом этапе дежурная смена, как правило, принимает решение обесточить все ИТ-системы объекта во избежание окончательного выхода серверов и СХД из строя и предотвращения пожара.
Меры профилактики
Предупреждение аварий климатических систем осуществляется за счёт соблюдения регламентного обслуживания кондиционеров, систем фрикулинга и вентиляции. Опытные эксплуатанты также держат на складе запасы хладагента, расходников и некоторых критически важных агрегатов, поскольку в условиях аварии не будет времени на заказ таких компонентов и материалов у поставщиков.
Аварии коммуникационного оборудования
Выход из строя магистральных сетевых коммутаторов или физическое повреждение кабелей, связывающих ЦОД с узлами обмена трафиком приводит к тому, что для внешнего мира центр становится недоступен. Даже если всё остальное оборудование в data-центре исправно, это приведет к убыткам клиентов, арендующих вычислительные мощности.
Выход из положения
Задача решается наличием на складе резервного коммутатора, организацией разветвленной структуры связности к внешним операторам связи, физической защитой коммуникационных кабелей и колодцев.
Катастрофические события
Пожар, затопление помещений или умышленное повреждение оборудования посторонними лицами — это катастрофические события, которые хотя и редки, но чреваты значительными убытками для владельцев ЦОДов и их клиентов.
Защита от пожара решается установкой систем мониторинга с видеонаблюдением, температурными датчиками, сенсорами задымления, установкой системы автоматического пожаротушения, регулярными обходами серверных залов и технических помещений дежурным персоналом, своевременным регламентным обслуживанием оборудования.
Защита от проникновения воды реализуется проверкой герметичности систем водоснабжения и канализации, уходом за гидроизоляцией крыши, своевременной её очистки от снежных масс и наледи. Для защиты от проникновения посторонних лиц организуется система видеонаблюдения и контроля доступа, а также прописывается регламент передвижения по помещениям ЦОД для посетителей. В крупных IT-структурах в России на объектах дежурит вооруженная охрана.
Заключение
Как видно из всего выше сказанного, своевременное обслуживание и ремонт оборудования — это основной способ предотвращения аварий в ЦОДах. Клиентам, арендующим вычислительные мощности для критически важных приложений, можно порекомендовать использовать репликацию виртуальных машин и данных между географически разнесенными объектами, а также чётко соблюдать золотое правило бэкапов «3-2-1», согласно которому компаниям рекомендуется хранить по три копии резервных данных, из которых две копии размещаются на разных устройствах одной площадки, а третья — на другой (чаще всего облачной) площадке.
