Пожары в дата-центрах. Как выстроить надёжное резервирование?

Kate

Administrator
Команда форума
Когда 16 сентября 2022 года загорелся небоскрёб China Telecom со столбом пламени в десятки метров и взрывами, то первым делом возник вопрос — что так сильно горит в 42-этажном офисном здании? Вскоре выяснилось, что здание не совсем офисное. Оказалось, на нескольких этажах размещался ЦОД. А все мы знаем, что по правилам резервирования Tier 2 дата-центр обязан хранить запасные энергоносители на случай отключения основного питания.

Что такое «запасные энергоносители»? Это могут быть заряженные аккумуляторы, ну, или дизельное топливо…
По предварительным оценкам, в здании China Telecom на момент возгорания могло быть около 35 тонн дизельного топлива. В результате, фасад 220-метрового небоскрёба в городе Чанша провинции Хунань выгорел буквально за 20 минут.



Цистерны с дизтопливом в офисном здании — совершенно невероятная картина, но в Китае и не такое можно представить.

Китай в этом плане вообще уникальная страна со своими культурными особенностями. Там иногда встречаются вещи, которые нам кажутся дикими. Например, недавно был случай, что сотрудники дата-центра Guizhou Cloud Big Data в Гуйчжоу (крупнейший дата-центр Apple, который китайские власти забрали под свой контроль в 2017 году) больше недели не покидали рабочие места из-за ковидных ограничений. То есть сотрудники некоторое время буквально жили в ЦОДе, как колония рабочих муравьёв в муравейнике.

uwab6u4eaq4otsqtihgshouwnrs.jpeg

Guizhou Cloud Big Data

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

Ещё не стёрся в памяти cгоревший дата-центр OVHCloud в Страсбурге в 2021 году.

cprmlhlbsal5zn8aoed7g7wpreo.jpeg


Здание SBG-2 было частью кампуса SBG из четырёх ЦОД. В нём предоставлялись услуги аренды выделенных серверов (dedicated) и облачные сервисы. В пожаре были уничтожены 15 000 серверов.

Из российских происшествий многие помнят возгорание кровли в дата-центре Dataline на Боровой («Одноклассники», Mail.ru), пожары в дата-центре Selectel в Санкт-Петербурге («Вконтакте»), дата-центре «Технологии Будущего» (где размещались восемь хостингов, так что из-за пожара ушло в офлайн около 2500 веб-сайтов разных компаний) и много других аварий как у нас, так и за рубежом.

zwjm0yfntoaywbzlrdb3zbl6gek.jpeg

Место, где начался пожар в дата-центре Dataline (5 июня 2019 года)

Некоторые из самых необычных происшествий последних лет:

▍ Электрические взрывы​


8 августа 2022 года в дата-центре Google г. Каунсил-Блафс (штат Айова) произошёл взрыв с человеческими жертвами (трое раненых с серьёзными ожогами). В результате поиск и картографический сервис Google на непродолжительное время стали недоступны в разных частях света. По информации пользователя Council Bluffs Scanner, который прослушивает радиопереговоры спасателей и полиции в своём городке, причиной стал «крупный электрический взрыв без возникновения пожара» на территории ЦОДа.


Электрический взрыв — возникновение электрической дуги огромной мощности. Причины инцидента неизвестны. Возможно, это связано с аномальной жарой, которая стояла в Айове.

▍ Аномальная жара​


Иногда серверы приходится обесточивать просто в силу неблагоприятных погодных условий. В июле 2022 года Google была вынуждена отключить серверы Google Cloud в лондонском дата-центре из-за проблем с их охлаждением в связи с жарой (40° С в тени). Отключение ЦОДов привело к перенаправлению нагрузки, что вызвало затруднения в работе сервисов.

plg0hzht1a1f9yvuef7e16yswsi.jpeg

Лондон, 18 июля 2022 года. Фото: Jose Sarmento Matos/Bloomberg

Компания Oracle тоже сняла нагрузку со своего дата-центра в Лондоне в тот же период времени.

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

▍ Удары молнии​


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

xwj1atp_kujrwxkq13yliuo2ico.jpeg


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

▍ Выпуск газа​


Ещё одна необычная авария случилась в апреле 2018 года в новеньком дата-центре DigiPlex (на севере Стокгольма), который обслуживает систему хранения данных фондовой биржи Nasdaq Nordic. Из-за ошибочного включения системы газового пожаротушения произошёл выпуск газа, а ударная волна вывела из строя дисковые накопители серверов.

Авария привела к остановке торгов Nasdaq Nordic на пять часов.

▍ Глобальные сбои облачных провайдеров​


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

Например, 13 марта 2019 года случился глобальный сбой в обслуживании почты Gmail и файлового хранилища Google Drive, которые полностью ушли в офлайн на несколько часов. Причины не назывались.

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

В ноябре 2020 года сбой AWS в регионе US-EAST-1 положил значительную часть интернета. Сервисы AWS начали выходить из строя 25 ноября около 11:00 ET. По информации AWS, первым упал Kinesis Data Streams, потянув за собой всё остальное: ACM, Amplify Console, API Gateway, AppStream2, AppSync, Athena, CloudFormation, CloudTrail, CloudWatch, Cognito, Connect, DynamoDB, EventBridge, IoT Services, Lambda, LEX, Managed Blockchain, Resource Groups, SageMaker, Support Console и Workspaces. Полная работоспособность восстановили только в 4:16 на следующий день, то есть даунтайм продолжался почти сутки. Пострадали тысячи сайтов, сервисов и мобильных приложений, которые размещают бэкенд на AWS, включая 1Password, Adobe Spark, Autodesk, Coinbase, Glassdoor, Flickr, iRobot, Roku и др.

Другой крупный сбой AWS произошёл в июне 2021 года. Тогда ненадолго ушли в офлайн многие популярные сайты, как Twitch, Reddit, Twitter, Hulu, HBO Max, Shopify и Amazon.


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

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

▍ МультиЦОДовость​


В последнее время всё более популярным становится тема гибридных облаков, мультиоблачных решений и «мультицодовости».

Гибридное облако — сочетание моделей развёртывания публичного и частного облака (on-prem).

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

Если внедрять мультицодовость в локальном масштабе, то лучшая стратегия сохранения данных — взять несколько виртуальных машин в разных ЦОДах.



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

  1. ДАТА-ЦЕНТР RUCLOUD (РОССИЯ, МОСКВА)
    Объект представляет собой комплекс из нескольких независимых залов (гермозон), помещения которых герметичны. Помещения дата-центра аттестованы в соответствии с требованиями ФСТЭК, проектировались в соответствии с категорией надёжности TIER III, согласно стандарту TIA-942 (резервирование N+1 с уровнем отказоустойчивости 99,98%). Мы также отдельно писали историю размещения в нём.
  2. ДАТА-ЦЕНТР М9 (РОССИЯ, МОСКВА)
    Крупнейшая в России точка обмена интернет-трафиком (IX), расположенная в Москве. Шестая крупнейшая IX в мире. Дата-центр RUCLOUD соединён прямым каналом связи с пропускной способностью в 10 Гбит/с с магистральным узлом связи в дата-центре М-9. Это позволяет гарантировать клиентам высокую скорость обмена трафиком между виртуальными серверами, расположенных в разных дата-центрах.
  3. ДАТА-ЦЕНТР ZUR1 (ЦЮРИХ, ШВЕЙЦАРИЯ)
    Центр обработки данных Interxion ZUR1 расположен в финансовой столице Швейцарии — в 5 минутах от аэропорта и в 10 минутах от центра Цюриха. ZUR1 сертифицирован по стандартам ISO 27001 и ISO 22301, имеет уровень SLA 99,999% по надёжности, что выше чем TIER4. Дата-центр ZUR1 имеет прямой выход на магистральные узлы обмена трафиком в Швейцарии SwissIX и в Европе NL-IX.
  4. ДАТА-ЦЕНТР TELEHOUSE (ФРАНКФУРТ, ГЕРМАНИЯ)
    Один из крупнейших дата-центров Германии в ЦОДе Telehouse Frankfurt находящегося в кампусе “Kleyerstrasse”. Включает в себя 3 дата-центра общей площадью 25000 квадратных метров. Дата-центр Telehouse Frankfurt имеет уровень энергообеспеченности Tier III и подключён ко второй по величине в Европе точке обмена трафиком DE-CIX с более чем 500 интернет-провайдерами и операторами связи.
  5. ДАТА-ЦЕНТР EQUINIX LD8 (ЛОНДОН, АНГЛИЯ)
    Дата-центр Equinix LD8 является одной из основных точек обмена трафиком в Европе (LINX, Лондонский Internet Exchange), насчитывающей более 690 членов в 68 странах мира. ЦОД объединен в единую сеть с крупнейшими узлами связи в Амстердаме(AMS-IX), Нидерландах (NL-IX) и во Франкфурте (DE-CIX). Расположенный в непосредственной близи одного из самых важных финансовых центров в мире, дата-центр LD8 обеспечивает беспрецедентный доступ к более чем 30 европейским рынкам и 80 биржам.
  6. ДАТА-ЦЕНТР LINXDATACENTER (САНКТ-ПЕТЕРБУРГ, РОССИЯ)
    Linxdatacenter находится на территории бизнес-центра «Скай-Трейд» и занимает площадь 9 000 кв.м. ЦОД в Санкт-Петербурге — это высоконадёжный дата-центр уровня TIER III, входит в ТОП-5 крупнейших ЦОДов на территории России. Мощность Linxdatacenter в 12 МВт достаточна для обеспечения ежедневного энергоснабжения города с численностью населения более 30 000 человек.
  7. ДАТА-ЦЕНТР IT PARK (КАЗАНЬ, РОССИЯ)
    Дата-центр находится на территории Казанского ИТ-парка и занимает площадь 1 000 кв.м. ЦОД в Казани — это высоконадёжный дата-центр уровня TIER III, самый крупный на территории Республики Татарстан. Дата-центр позволяет разместить свыше 300 стоек. Мощность ЦОД составляет 2,5 МВт.
  8. ДАТА-ЦЕНТР ЕКАТЕРИНБУРГ (ЕКАТЕРИНБУРГ, РОССИЯ)
    Дата-центр находится на территории бывшего завода “Радиоаппаратуры” в Екатеринбурге. Все серверные помещения находятся в собственности ЦОДа и занимают площадь 160 кв.м. В собственности дата-центра находятся 7 подстанций, подключение к которым происходит напрямую, с возможностью оперативного наращивания выделяемой мощности.
  9. ДАТА-ЦЕНТР НОВОСИБИРСК (НОВОСИБИРСК, РОССИЯ)
    ЦОД имеет прямое подключение к 2 центральным узлам связи Новосибирска MSK-IX — ТЦМС-8 по адресу 2-я ул. Союза молодежи, д. 33/1, и ДЦ НвсФ ФГУП «ЦентрИнформ» на ул. Серебренниковская, д. 14.
  10. ДАТА-ЦЕНТР AMS9 (АМСТЕРДАМ, НИДЕРЛАНДЫ)
    Центр обработки данных Interxion AMS9 расположен в столице Нидерландов — Амстердаме, в Science Park Data Center – ведущем центре межсетевых соединений города. Расположение ЦОД и его соединение с крупными точками обмена интернет-трафиком, обеспечивает хорошую связь со странами как Нового, так и Старого Света и доступ к данным из любой точки мира с самой низкой задержкой – 99,99999%.
  11. ДАТАЦЕНТР ОСТАНКИНО (РОССИЯ, МОСКВА)
    Дата-центр “ТТЦ Останкино” находится в центре Москвы в собственном капитальном здании, расположенном на территории площадью 10 000 квадратных метров. RUVDS выбрали этот ЦОД как свою локацию из-за высокого гарантированного SLA в 99,982 и повышенной отказоустойчивости: он построен так, чтобы выдерживать даже серьёзные инциденты изменяющейся окружающей среды в серверных залах ЦОД.
Не стоит забывать о правиле резервного копирования 3-2-1, которое можно адаптировать для своих нужд.

▍ Правило 3-2-1​


Оригинальное правило 3-2-1 простое и понятное:

  • 3 экземпляра данных
  • 2 разных носителя. Чтобы избежать общих причин сбоя, лучше использовать накопители разных типов (HDD, SSD, флешки)
  • 1 копия в офлайне (за пределами офиса или квартиры). Физическое разделение копий на максимальное расстояние друг от друга. Можно использовать облачные решения.

1_t2nlcmg5mfugk-__nsgahmdd4.gif


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

  • 3 экземпляра данных
  • 2 разных сервера
  • 1 копия в резервном дата-центре (или другом облаке)

Провайдер хостинга Blackblaze называет более продвинутые варианты этой стратегии: 3-2-1-1-0 и 4-3-2.

▍ Стратегия 4-3-2​


2j90ae69rv2hn7jhamoczut1k7q.png


Стратегия 4-3-2 просто добавляет один избыточный уровень резервирования к правилу 3-2-1. Это логика минимизации рисков. Вкратце её можно сформулировать в виде правила десантников, которые в важных деталях привыкли считать, что «два — это один», а «один — это ноль». Поэтому добавляем по единице к каждому уровню.

▍ Стратегия 3-2-1-1-0​


y62uf_dlyxqwkb7c5yqw_bdbrue.png

Эта стратегия более детально указывает разнообразие накопителей/локаций, добавляет офлайновое хранилище, отключённое от интернета, а также вводит инструментарий типа Object Lock. Он работает по модели Write Once, Read Many (WORM), предотвращая изменение или удаление каких-либо объектов в хранилище.



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

 
Сверху