История аварии: как один ЦОД стоял 8 часов

в 13:31, , рубрики: Tier, Uptime Institute, авария, аудит, Блог компании КРОК, дата-центр, дизель, ит-инфраструктура, охлаждение, питание, тепловизор, хостинг, цод, метки: , , , , , , , , ,

Эта история произошла с ЦОДом одной компании уже довольно давно, все последствия аварии устранены, плюс выполняются доработки, исключающие повторение ситуаций. Тем не менее, отчёт о происшедшем, полагаю, будет интересен и тем, кто занимается дата-центрами, и тем, кто любит почти детективные IT-истории.

Итак, ожидалось плановое отключение электричества. В дата-центр приходило две линии, владельцы ЦОДа заранее знали о ситуации, подготовились и провели все необходимые тесты. Всё что было нужно – просто перейти на дизели по стандартной процедуре.

Час X

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

Час П

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

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

Результат — во время планового отключения компания получила аварийную остановку всего ЦОДа. Примерно на 8 часов, что для крупной компании может равняться чуть ли не квартальной прибыли. ЦОД простоял от момента зачерпывания воды дизелями до того момента пока не подали питание снова.

Встать — мало: нужно больше никогда не ложиться

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

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

С другой стороны, автономная часть по меркам Uptime Institute очень важна. Тщательно изучается качество дизелей, топливо, обслуживание и так далее. Объяснять, что в России принято делать наоборот, наверное, не надо. Все подробно рассказывают: у нас вот этот луч оттуда, а этот отсюда, вот эта подстанция очень хорошая… Если кто помнит случай с Чагинской когда сразу все лучи повыключались, станет понятно, почему Uptime Institute так относится к таким линиям. По стандарту нужно поддерживать в исправном состоянии ту инфраструктуру, которая есть у именно у вас как владельца ЦОДа, и грамотно её проектировать.

Обследование

ЦОД был спроектирован и построен на достаточно современном уровне, с применением современных решений, но, как известно, дьявол кроется в мелочах. Первое, о чем сказали наши профильные инженеры – что реализована очень запутанная и нелогичная схема распределения питания. Она построена на базе программируемых управляемых контроллеров, причем производителя с закрытой архитектурой и одной «головой»: если она ломается, никакого резервирования нет. И тут мы опять приходим к тому, о чем говорят наши коллеги из Uptime Institute: главный принцип выражается по сути одним предложением для Tier III (по нашим ощущениям, самого востребованного): один любой элемент может быть выведен из эксплуатации, и система при этом должна сохранить свою полную работоспособность.

В элементах проектной документации упоминаний о соответствии стандартам, кроме как строительным и ПУЭ, нет: это характерный симптом, что надо закопаться поглубже и провести аудит всех мелочей. Ещё похожий симптом – это когда указаны стандарты, не предполагающие сертификации внешним, по отношению к проектировщику органом. Здесь часто случается, что на бумаге заявляется одно, а на объекте – совсем другое. К счастью, в нашем случае проектная документация точно соответствовала реальному воплощению.

Питание

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

Следующий момент — работа системы питания топливом и синхронизации дизель-генераторов. Топливная система рассматривается как критичная для функционирования ЦОД и требует своего резервирования. Ну а отсутствие сепараторов, это уже вопрос недооценки западными проектировщиками наших реалий. Синхронизация дизель-генераторов еще один важный момент, который Uptime Institute с пристрастием проверяет. Если запустить все их, то дальше один назначает себя лидером, садится на общую шину, и все остальные машины по очереди пытаются синхронизироваться. Грубо говоря, должны совпасть синусоиды переменного напряжения, чтобы не было короткого замыкания. Как только какая-то из машин оказывается засинхронизирована, у нее включается контактор, и она включается в общую шину. Так все дизели по очереди набираются на общую линию. Чтобы это все нормально проходило, у современных дизель-генераторов предусмотрена связь между собой, то есть они объединены в общую информационную сеть. Ещё плюс этого метода — машины могут балансировать нагрузку.

Uptime Institute предлагает исходить из следующего постулата: представьте, что внешней сети нет, вы круглый год работаете на дизель-генераторах. Вот пришло время, например, заменить панель управления одного из дизелей. Вы её выключили, остальных хватает, чтобы обеспечивать ЦОД. А дальше вы должны эту шину, которая объединяет машины, из него вынуть и снять панель управления. Этот тест ни один стандартный дизель-генератор, который у нас продается, не пройдет. Потому что у них шина, по сути, линейная. Они друг с другом соединены: размыкаешь в середине, и правая сторона не знает, что делает левая. Для нашего ЦОДа повышенной ответственности «Компрессора» специально под это требование сделали другие системы управления, где закольцована шина. И мы можем в любом месте ее порвать, данные не теряются, и машины продолжат друг с другом общаться. При проектировании ЦОДов мало кто об этом знает, и, соответственно, есть ещё одно узкое место. Вроде мелкое, крайне маловероятное – но цепочка таких вероятностей создаёт самые страшные ситуации, которые крайне желательно избежать.

Дальнейшие тесты

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

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

Основные замечания были по наиболее важным системам. Мы, например, снимали термограммы, искали локальные зоны перегрева. Например, обнаружили зону инжекции:
История аварии: как один ЦОД стоял 8 часов
Была локальная зона перегрева: стоит стойка, не хватает из решетки дальнобойности струи. Внизу охлаждает, а наверху не хватает. Причем если стойка не полностью заполнена серверами, ставятся заглушки, чтобы горячие и холодные коридоры разобщить. В противном случае возникают перетоки, вот как пример:
История аварии: как один ЦОД стоял 8 часов
По большому счету, надо просто поднять скорость вращения вентиляторов фанкойлов: до этого нижний сервер охлаждался больше чем нужно, а верхний был в тепле. Второй пример – стоит стена из блоков, на термограмме видны швы: у них теплопроводность выше, чем у пенобетона. Естественно никаких проблем это не сулит, просто хорошая демонстрация возможностей современных тепловизоров.
История аварии: как один ЦОД стоял 8 часов
Заодно смотрели качество электроснабжения ЦОД: проверяли, какое качество питания на входе, использовали для этого специальные железки, там всё нормально.
История аварии: как один ЦОД стоял 8 часов
Дальше тестировали несколько параметров в СКС, расходы воздуха, соответствие установленной мощности фанкойлов и реальной – все соответствует, все работает нормально.

Резюме

Всё началось с аварии, и все это вылилось в анализ, в результате которого вскрылись еще недочеты и были сформированы рекомендации по оптимальному увеличению мощности.

В России вместо Tier III по методологии от Uptime Institute часто заявляют Tier III по TIA 942. TIA, по сути, описывает требования, которым необходимо соответствовать, чтобы ваш ЦОД был похож на Tier-третий, но на ваше усмотрение, делать так или нет. Это рекомендательный стандарт, и процедура оценки там заявительная: построили и сказали, что это Tier III. А учитывая, что уровень Tier III есть и в Uptime Institute и в TIA, заказчиков часто вводят в заблуждение. Чтобы проверить, действительно ли площадка получила сертификат, достаточно зайти на сайт Uptime Institute.

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

Автор: Yury_Ilin

Поделиться

* - обязательные к заполнению поля