20.04.2022

Причина выгорания: по итогам расследования пожара дата-центра OVH

Опубликованы результаты расследования обстоятельств пожара, уничтожившего дата-центра SBG2 компании OVHcloud в Страсбурге.

Константин Нагорный, главный инженер Linxdatacenter в Санкт-Петербурге 

Опубликованы результаты расследования обстоятельств пожара, уничтожившего дата-центра SBG2 компании OVHcloud в Страсбурге. Комплекс причин, установленный экспертами — грубые нарушения требований пожарной безопасности. Разбираемся в выводах и трактовке результатов расследования, озвученных в СМИ, и делаем выводы на будущее.  

Пожар в дата-центре OVH в марте 2021 года продемонстрировал, что неуязвимых ЦОДов не существует вне зависимости от региона или статуса провайдера.

Напомним, инцидент привел к отключению 3,6 млн веб-сайтов и интернет-сервисов по всему миру: тогда пострадали правительственные ресурсы, порталы банков, ритейлеров и СМИ. Особенностью катастрофы стала невозможность быстро справиться с огнем, хотя на место происшествия пожарные прибыли очень оперативно.

В результате ЦОД сгорел практически полностью и восстановлению не подлежит.

Первые версии и финальный отчет 

Первые выводы по итогам предварительного расследования инцидента в качестве причины указывали на источники бесперебойного питания (ИБП). По данным СМИ, они загорелись через несколько часов после завершения ТО с заменой некоторых компонентов и перезапуска.

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

В отчете пожарной службы департамента Нижнего Рейна, опубликованном в марте 2022 года, говорится, что при тушении пожара в помещении ИБП наблюдались электрические дуги длиной более 1 м.

Пожарным потребовалось около 3 часов, чтобы отключить электропитание, поскольку в ЦОДе не было единого выключателя. Все это время с начала возгорания в инверторы ИБП подавалось электричество, некоторые серверы продолжали работать.

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

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

Давайте подробно рассмотрим роль каждого перечисленного выше фактора.

Деревянные полы и потолки 

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

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

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

Отсутствие системы автоматического пожаротушения 

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

Обязательным является наличие автоматической системы пожарной сигнализации, которая обнаружит возгорание и запустит процессы для предотвращения распространения огня.

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

Распространение огня из-за фрикулинга  

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

Если такого сигнала не было, то данная причина действительно может являться серьезным фактором, приведшим к распространению огня.

Единая кнопка отключения электричества (EPO) 

Еще один спорный фактор. Многие считают, что единая кнопка EPO опасна с точки зрения операционной устойчивости всего ЦОД.

Кнопка EPO – это обычный выключатель, контакт которого может разомкнуться в том числе и случайно, в итоге весь ЦОД останется без электропитания. Более разумный подход – наличие выделенных кнопок EPO на различные системы дата-центра. Например, отдельный выключатель EPO на ИБП линейки А и еще один – на ИБП линейки Б и т. д., что исключает одновременное отключение двух лучей ИБП при ложном срабатывании одной общей кнопки.

Естественно, кнопки EPO должны быть расположены вне помещений с оборудованием. Кстати, роль EPO могут выполнять и обычные электрические выключатели в щитовых, вынесенные отдельно от оборудования. Самое важное иметь доступ к ним во время пожара, то есть не размещать в одном помещении с подключенным оборудованием.

Выводы и памятка 

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

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

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

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

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

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

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

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

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

Хранение любых поддерживающих горение материалов должно быть организовано вне серверных и других критически важных помещений. Нет так называемой «пожарной нагрузки» – нечему гореть.

Надеемся, данная статья помогла вам составить представление об особенностях организации пожарной безопасности в ЦОДе.

 

Другие новости и публикации

Статья
09.08.2022
ИБ в условиях дефицита: стратегия большого перехода
Новость
01.08.2022
Linxdatacenter – в топ-10 крупнейших поставщиков услуг ЦОД
Новость
25.07.2022
Linxdatacenter запускает собственные PaaS-инструменты
Новость
20.07.2022
Петербургское облако Linxdatacenter прошло аттестацию по ...
Статья
30.06.2022
Как мы оптимизировали управление ЦОДами клиента
Новость
27.06.2022
Linxdatacenter: рынок российских облаков вырастет в 2022 ...
Новость
26.05.2022
Анна Мальми назначена региональным директором Linxdatacen...
Статья
20.05.2022
Облачный край: что происходит на российском рынке
Новость
13.05.2022
Новым генеральным директором Linxdatacenter назначен Андр...
Статья
03.05.2022
Блок на моноблок: модульная ИБП-революция в ЦОДах

Вас также могут заинтересовать

Linx Outsourcing
Аудит, модернизация и оптимизация ваших серверных мощностей
Подробнее
Аутсорсинг управления дата-центром
Linx Network
Обеспечьте отказоустойчивость и бесперебойную работу сети
Подробнее
Сетевые услуги
Linx DraaS
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-системы уже сегодня!
Подробнее
Аварийное восстановление DRaaS

Напишите нам

Как мы оптимизировали управление ЦОДами клиента

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

Тарас Чирков, руководитель ЦОД Linxdatacenter в Санкт-Петербурге 

Константин Нагорный, главный инженер ЦОД Linxdatacenter в Санкт-Петербурге 

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

В главной роли – управление 

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

Роль надежных и производительных дата-центров в современной экономике постоянно растет вместе с требованиями к их бесперебойной работе. Однако на этом направлении существует большая системная проблема.  

Высокий уровень «аптайма» – безаварийной работы дата-центра без простоев – очень сильно зависит от команды инженеров, которая занимается управлением площадки. А единой формализованной школы управления ЦОДами не существует.  

Нет какого-то сводного канона с правилами, применимыми для любого дата-центра. Есть стандарты международной отраслевой организации Uptime Institute, но они устанавливают рамки и вектор развития, к каждому конкретному дата-центру они будут применяться по-разному.  

В масштабах страны  

На практике в России ситуация с эксплуатацией ЦОДов выглядит так.  

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

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

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

Все это выливается в ситуацию «кто во что горазд». «Разношерстный» состав команд эксплуатации из специалистов с разным бэкграундом, различные подходы к организации корпоративной архитектуры, взгляды и требования в отношении ИТ-департаментов.  

Факторов, приводящих к такому положению дел, много, один из главных – отсутствие систематизированной документации по выстраиванию эксплуатационных процессов. Есть пара вводных статей Uptime Institute, которые дают представление о проблеме и путях ее преодоления. Но дальше необходимо выстраивать систему своими силами. А на это ресурсов и компетенций хватит далеко не у каждого бизнеса.  

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

Кейс: через тернии к относительному порядку 

Проиллюстрируем на примере реализованного проекта. К нам обратилась крупная международная компания с сетью собственных дата-центров. Запрос был на помощь в оптимизации процессов управления тремя площадками, где на серверах развернуты ИТ-системы и приложения, абсолютно критичные для бизнеса.  

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

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

И здесь началось самое интересное.  

Познай себя 

Чтобы оценить уровень работы ЦОДов с точки зрения соответствия стандартам, нужно знать точные требования бизнеса к ИТ-системам: каков уровень внутренних SLA, допустимый период простоя оборудования и т.д.  

Сразу же выяснилось – ИТ-департамент не знает, что именно хочет бизнес. Не было внутренних критериев качества сервиса, не было и понимания логики устройства собственной инфраструктуры.  

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

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

Когда было достигнуто понимание архитектуры ИТ-систем, команда смогла суммировать требования к службе эксплуатации, подрядчикам и к уровню надежности оборудования.  

Улучшения в процессе 

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

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

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

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

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

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

Далее последовал этап первичной поддержки работ по обновленным регламентам, который в удаленном формате продолжался один год. Затем мы перешли к тренингам и учениям – единственный путь закрепления нового материала на практике.  

Что сделано 

В процессе работ нам удалось решить несколько серьезных вопросов.  

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

Принцип «просто найти, просто понять, легко запомнить» дополнился тем, что новая информация привязывается к старому опыту и знаниям сотрудников. 

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

Но нас удивило легкомысленное отношение компании к своей ИТ-инфраструктуре: от отсутствия резервирования критичных систем до хаоса в структуре и управлении.  

За 1,5 года процессы управления инженерными системами были прокачаны до уровня, который позволил специалистам компании успешно отчитаться «за качество» перед аудиторами из головного офиса.  

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

Выводы 

В целом перспективы консалтинга в сфере операционного управления дата-центрами, по нашему мнению, самые яркие.  

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

Главная проблема здесь: многие руководители не понимают, по какому тонкому льду они идут, не уделяя этому моменту должного внимания. Человеческий фактор по-прежнему остается главным источником самых неприятных аварий и сбоев. И это нужно объяснять.  

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

Когда требования к государственным ЦОДам в РФ на уровне законодательного акта будут сведены в стандарт, его можно будет применять и для коммерческих дата-центров, в том числе и для размещения государственных ИТ-ресурсов.  

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

Причина выгорания: по итогам расследования пожара дата-центра OVH

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Клиент:

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Спасибо за ваш запрос, мы свяжемся с вами в ближайшее время!