ENG
Мнение, Технологии

Эти ЦОДы в огне

Тарас Чирков

Тарас Чирков

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

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

Бессмертия не существует

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

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

Источник бесперебойного возгорания?

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

Впрочем, подозрение сразу пало на ИБП: системы бесперебойного питания из дата-центра SBG2 были переданы полиции и страховой компании для совместного расследования вместе с предохранителями почти сразу после ликвидации огня. Гипотезу поддерживал основатель и владелец OVH Октав Клаба — в одном из сообщений в Twitter он рассказал о тайминге событий, который говорит в пользу именно этой версии.

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

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

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

«В ЦОДе нечему гореть!» ©

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

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

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

Uptime ни при чем 

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

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

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

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

Когда хорошо иметь план Б

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

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

Кстати, именно этого в случае OVH, видимо, сделано не было. Когда в результате пожара пострадали около 3,6 млн веб-сайтов, хостившихся на площадках компании в Страсбурге, многие клиенты дата-центра искренне удивились, узнав, что план аварийного восстановления (DRP) для владельцев выделенных серверов в ЦОДе на случай пожара был, оказывается, их обязанностью. А если они им не озаботились, то никто не вернет им их ИТ-системы и данные. По умолчанию такие сервисы, как правило, не предоставляются.

«Некоторые клиенты не понимают точно, что они покупают в дата-центре», прокомментировал критику Клаба.

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

Последствия для отрасли

OVH извлекла уроки из случая и анонсировала проверку всех блоков ИБП на всех площадках, стратегию избыточной безопасности (oversecure), а также сообщила о планах запуска лаборатории по исследованию причин и путей предотвращения пожаров в ЦОДах.

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

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

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

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

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

Подписывайтесь на канал «Инвест-Форсайта» в «Яндекс.Дзене»

Вам понравился этот текст? Вы можете поддержать наше издание, купив пакет информационных услуг
Загрузка...
Предыдущая статьяСледующая статья