Пожары в дата-центрах. Как выстроить надёжное резервирование?
Когда 16 сентября 2022 года загорелся небоскрёб China Telecom со столбом пламени в десятки метров и взрывами, то первым делом возник вопрос — что так сильно горит в 42-этажном офисном здании? Вскоре выяснилось, что здание не совсем офисное. Оказалось, на нескольких этажах размещался ЦОД. А все мы знаем, что по правилам резервирования Tier 2 дата-центр обязан хранить запасные энергоносители на случай отключения основного питания.
Что такое «запасные энергоносители»? Это могут быть заряженные аккумуляторы, ну, или дизельное топливо…
По предварительным оценкам, в здании China Telecom на момент возгорания могло быть около 35 тонн дизельного топлива. В результате, фасад 220-метрового небоскрёба в городе Чанша провинции Хунань выгорел буквально за 20 минут.
Цистерны с дизтопливом в офисном здании — совершенно невероятная картина, но в Китае и не такое можно представить.
Китай в этом плане вообще уникальная страна со своими культурными особенностями. Там иногда встречаются вещи, которые нам кажутся дикими. Например, недавно был случай, что сотрудники дата-центра Guizhou Cloud Big Data в Гуйчжоу (крупнейший дата-центр Apple, который китайские власти забрали под свой контроль в 2017 году) больше недели не покидали рабочие места из-за ковидных ограничений. То есть сотрудники некоторое время буквально жили в ЦОДе, как колония рабочих муравьёв в муравейнике.
Guizhou Cloud Big Data
Кто-то может сказать, что это особенности китайской культуры, где ценность человеческой жизни и личности не настолько высоко ценится, как в нашей цивилизации. Но это весьма спорное утверждение. На самом деле такие происшествия происходят не только в китайских, но и в западных ЦОДах. От пожаров никто не застрахован.
Ещё не стёрся в памяти cгоревший дата-центр OVHCloud в Страсбурге в 2021 году.
Здание SBG-2 было частью кампуса SBG из четырёх ЦОД. В нём предоставлялись услуги аренды выделенных серверов (dedicated) и облачные сервисы. В пожаре были уничтожены 15 000 серверов.
Из российских происшествий многие помнят возгорание кровли в дата-центре Dataline на Боровой («Одноклассники», Mail.ru), пожары в дата-центре Selectel в Санкт-Петербурге («Вконтакте»), дата-центре «Технологии Будущего» (где размещались восемь хостингов, так что из-за пожара ушло в офлайн около 2500 веб-сайтов разных компаний) и много других аварий как у нас, так и за рубежом.
Место, где начался пожар в дата-центре Dataline (5 июня 2019 года)
Некоторые из самых необычных происшествий последних лет:
▍ Электрические взрывы
8 августа 2022 года в дата-центре Google г. Каунсил-Блафс (штат Айова) произошёл взрыв с человеческими жертвами (трое раненых с серьёзными ожогами). В результате поиск и картографический сервис Google на непродолжительное время стали недоступны в разных частях света. По информации пользователя Council Bluffs Scanner, который прослушивает радиопереговоры спасателей и полиции в своём городке, причиной стал «крупный электрический взрыв без возникновения пожара» на территории ЦОДа.Электрический взрыв — возникновение электрической дуги огромной мощности. Причины инцидента неизвестны. Возможно, это связано с аномальной жарой, которая стояла в Айове.
▍ Аномальная жара
Иногда серверы приходится обесточивать просто в силу неблагоприятных погодных условий. В июле 2022 года Google была вынуждена отключить серверы Google Cloud в лондонском дата-центре из-за проблем с их охлаждением в связи с жарой (40° С в тени). Отключение ЦОДов привело к перенаправлению нагрузки, что вызвало затруднения в работе сервисов.
Лондон, 18 июля 2022 года. Фото: Jose Sarmento Matos/Bloomberg
Компания Oracle тоже сняла нагрузку со своего дата-центра в Лондоне в тот же период времени.
В других дата-центрах пришлось прибегнуть к экстренным мерам, в том числе спрыскивать водой крыши зданий, понижая температуру воздуха около змеевиков кондиционеров для улучшения теплообмена.
▍ Удары молнии
В сентябре 2018 года несколько техасских дата-центров Microsoft оказались в эпицентре урагана. Как сообщается, удары молний привели к продолжительным перебоям в электропитании ЦОДов.
Один из ЦОДов перешёл на резервные генераторы, что привело к повышению температуры в машинном зале. Система охлаждения не справилась, а часть серверов вышла из строя. Инженеры приняли решение полностью отключить машинные залы от электропитания, то есть увели ЦОД полностью в офлайн.
▍ Выпуск газа
Ещё одна необычная авария случилась в апреле 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 дата-центров — для резервирования ваших данных почти по всему миру, давайте кратко по ним пробежимся:
- ДАТА-ЦЕНТР RUCLOUD (РОССИЯ, МОСКВА)
Объект представляет собой комплекс из нескольких независимых залов (гермозон), помещения которых герметичны. Помещения дата-центра аттестованы в соответствии с требованиями ФСТЭК, проектировались в соответствии с категорией надёжности TIER III, согласно стандарту TIA-942 (резервирование N+1 с уровнем отказоустойчивости 99,98%). Мы также отдельно писали историю размещения в нём. - ДАТА-ЦЕНТР М9 (РОССИЯ, МОСКВА)
Крупнейшая в России точка обмена интернет-трафиком (IX), расположенная в Москве. Шестая крупнейшая IX в мире. Дата-центр RUCLOUD соединён прямым каналом связи с пропускной способностью в 10 Гбит/с с магистральным узлом связи в дата-центре М-9. Это позволяет гарантировать клиентам высокую скорость обмена трафиком между виртуальными серверами, расположенных в разных дата-центрах. - ДАТА-ЦЕНТР ZUR1 (ЦЮРИХ, ШВЕЙЦАРИЯ)
Центр обработки данных Interxion ZUR1 расположен в финансовой столице Швейцарии — в 5 минутах от аэропорта и в 10 минутах от центра Цюриха. ZUR1 сертифицирован по стандартам ISO 27001 и ISO 22301, имеет уровень SLA 99,999% по надёжности, что выше чем TIER4. Дата-центр ZUR1 имеет прямой выход на магистральные узлы обмена трафиком в Швейцарии SwissIX и в Европе NL-IX. - ДАТА-ЦЕНТР TELEHOUSE (ФРАНКФУРТ, ГЕРМАНИЯ)
Один из крупнейших дата-центров Германии в ЦОДе Telehouse Frankfurt находящегося в кампусе «Kleyerstrasse». Включает в себя 3 дата-центра общей площадью 25000 квадратных метров. Дата-центр Telehouse Frankfurt имеет уровень энергообеспеченности Tier III и подключён ко второй по величине в Европе точке обмена трафиком DE-CIX с более чем 500 интернет-провайдерами и операторами связи. - ДАТА-ЦЕНТР EQUINIX LD8 (ЛОНДОН, АНГЛИЯ)
Дата-центр Equinix LD8 является одной из основных точек обмена трафиком в Европе (LINX, Лондонский Internet Exchange), насчитывающей более 690 членов в 68 странах мира. ЦОД объединен в единую сеть с крупнейшими узлами связи в Амстердаме (AMS-IX), Нидерландах (NL-IX) и во Франкфурте (DE-CIX). Расположенный в непосредственной близи одного из самых важных финансовых центров в мире, дата-центр LD8 обеспечивает беспрецедентный доступ к более чем 30 европейским рынкам и 80 биржам. - ДАТА-ЦЕНТР LINXDATACENTER (САНКТ-ПЕТЕРБУРГ, РОССИЯ)
Linxdatacenter находится на территории бизнес-центра «Скай-Трейд» и занимает площадь 9 000 кв.м. ЦОД в Санкт-Петербурге — это высоконадёжный дата-центр уровня TIER III, входит в ТОП-5 крупнейших ЦОДов на территории России. Мощность Linxdatacenter в 12 МВт достаточна для обеспечения ежедневного энергоснабжения города с численностью населения более 30 000 человек. - ДАТА-ЦЕНТР IT PARK (КАЗАНЬ, РОССИЯ)
Дата-центр находится на территории Казанского ИТ-парка и занимает площадь 1 000 кв.м. ЦОД в Казани — это высоконадёжный дата-центр уровня TIER III, самый крупный на территории Республики Татарстан. Дата-центр позволяет разместить свыше 300 стоек. Мощность ЦОД составляет 2,5 МВт. - ДАТА-ЦЕНТР ЕКАТЕРИНБУРГ (ЕКАТЕРИНБУРГ, РОССИЯ)
Дата-центр находится на территории бывшего завода «Радиоаппаратуры» в Екатеринбурге. Все серверные помещения находятся в собственности ЦОДа и занимают площадь 160 кв.м. В собственности дата-центра находятся 7 подстанций, подключение к которым происходит напрямую, с возможностью оперативного наращивания выделяемой мощности. - ДАТА-ЦЕНТР НОВОСИБИРСК (НОВОСИБИРСК, РОССИЯ)
ЦОД имеет прямое подключение к 2 центральным узлам связи Новосибирска MSK-IX — ТЦМС-8 по адресу 2-я ул. Союза молодежи, д. 33/1, и ДЦ НвсФ ФГУП «ЦентрИнформ» на ул. Серебренниковская, д. 14. - ДАТА-ЦЕНТР AMS9 (АМСТЕРДАМ, НИДЕРЛАНДЫ)
Центр обработки данных Interxion AMS9 расположен в столице Нидерландов — Амстердаме, в Science Park Data Center — ведущем центре межсетевых соединений города. Расположение ЦОД и его соединение с крупными точками обмена интернет-трафиком, обеспечивает хорошую связь со странами как Нового, так и Старого Света и доступ к данным из любой точки мира с самой низкой задержкой — 99,99999%. - ДАТАЦЕНТР ОСТАНКИНО (РОССИЯ, МОСКВА)
Дата-центр «ТТЦ Останкино» находится в центре Москвы в собственном капитальном здании, расположенном на территории площадью 10 000 квадратных метров. RUVDS выбрали этот ЦОД как свою локацию из-за высокого гарантированного SLA в 99,982 и повышенной отказоустойчивости: он построен так, чтобы выдерживать даже серьёзные инциденты изменяющейся окружающей среды в серверных залах ЦОД.
НЕ LOOKING GLASS
Не стоит забывать о правиле резервного копирования 3–2–1, которое можно адаптировать для своих нужд.
▍ Правило 3–2–1
Оригинальное правило 3–2–1 простое и понятное:
- 3 экземпляра данных
- 2 разных носителя. Чтобы избежать общих причин сбоя, лучше использовать накопители разных типов (HDD, SSD, флешки)
- 1 копия в офлайне (за пределами офиса или квартиры). Физическое разделение копий на максимальное расстояние друг от друга. Можно использовать облачные решения.
Это самые минимальные требования к сохранности информации, которые идеально описывают потребности отдельного пользователя по сохранности личного информационного архива. В продакшне требования более серьёзные. Конечно, правило можно (и нужно) изменять под свои потребности и возможности. Например, таким образом:
- 3 экземпляра данных
- 2 разных сервера
- 1 копия в резервном дата-центре (или другом облаке)
Провайдер хостинга Blackblaze называет более продвинутые варианты этой стратегии: 3–2–1–1–0 и 4–3–2.
▍ Стратегия 4–3–2
Стратегия 4–3–2 просто добавляет один избыточный уровень резервирования к правилу 3–2–1. Это логика минимизации рисков. Вкратце её можно сформулировать в виде правила десантников, которые в важных деталях привыкли считать, что «два — это один», а «один — это ноль». Поэтому добавляем по единице к каждому уровню.
▍ Стратегия 3–2–1–1–0
Эта стратегия более детально указывает разнообразие накопителей/локаций, добавляет офлайновое хранилище, отключённое от интернета, а также вводит инструментарий типа Object Lock. Он работает по модели Write Once, Read Many (WORM), предотвращая изменение или удаление каких-либо объектов в хранилище.
Многочисленные аварии и пожары в дата-центрах показывают, что в этом мире много чего может произойти. Поэтому для максимальной сохранности своих данных — всегда лучше перестраховаться и копировать свою VM в нескольких ЦОДах и — в нескольких странах.
Telegram-канал и уютный чат
