Категории: Серверы и сети

Сгорел один из дата-центров крупнейшего в Европе хостера

В 2018 году я уже писал о проблемах в российском ДЦ Xelent, которые привели к недоступности VK и многих других сайтов. И вот история отчасти повторяется. Казалось бы, современные ЦОД строят по схемам с резервированием по питанию, охлаждению, ставят мощные ДГУ (дизель-генераторные установки), ИБП. Применяются системы автоматического пожаротушения. Казалось бы, что еще нужно?

Как мы в очередной раз убедились сегодня, не все работает так хорошо, как хотелось бы. В 2014 году в ЦОД Samsung в Корее был пожар. 4 ноября 2019 года пожар в одном из ДЦ Вконтакте, которые привели к проблемам с электроснабжением. Жизнь ничему не учит.

Пожар в OVH

Сегодня ночью в дата-центре облачного провайдера OVH в Страсбурге (Франция) произошел пожар, никто из сотрудников компании не пострадал. OVH — крупнейший хостинг-провайдер в Европе и третий по величине в мире. OVH предоставляет услуги выделенных серверов, общего и облачного хостинга, регистрации доменов и VoIP телефонии. Четырнадцать из 27 дата-центров OVH расположены в Европе, всего у компании хостится около 300000 серверов. Последняя крупная авария у OVH также произошла в кампусе SBG в 2017 году. В результате отключения электроэнергии весь кампус SBG был отключен (как? там же есть и резервные вводы питания и ДГУ, который должен обеспечивать питанием минимум сутки). Сорок минут спустя другой кампус RBX (Рубе, Франция) потерял связь из-за ошибки на сетевом оборудовании. В декабре 2020 года опять наблюдались проблемы на сетевом оборудовании в RBX, восстановление которых заняло около 3 часов.

Кампус в Страсбурге состоит из 4 ЦОД: SBG1, SBG2, SBG3 и SBG4. В результате пожара полностью сгорел SBG2, частично затронут SBG1, который находится в опасной близости. Пожарные немедленно прибыли на место происшествия, но не смогли справиться с возгоранием в SBG2. В SBG2 предоставлялись услуги аренды выделенных серверов (dedicated) и облачные сервисы. И если облачным сервисам OVH должен был обеспечивать резервное копированием своими силами, то для арендаторов выделенных серверов эта ситуация в отсутствии резервных копий может быть фатальной. Все серверы и данные на них (если они не копировались на другие ДЦ), утеряны безвозвратно.

На данный момент все 4 ЦОД обесточены. Пожарные проливали соседние здания ЦОД рядом с горящим SBG2, чтобы избежать перекидывания огня. SBG1 поврежден частично: 4 серверные комнаты разрешены, 8 остались в целостности, комната с сетевым оборудованием не повреждена. Все серверы в SBG3 остались в целостности и сохранности, но выключены. Они продержались некоторое время на UPS, после чего утром были отключены. SBG4 остался не затронутым, но лишился сетевой связности и питания. Частично повреждено сетевое оборудование в сетевой комнате в SBG5.

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

Помимо утерянных серверов в течение ближайших 2 недель потребуется заново прокинуть линию питания 20 кВ на SBG3, полностью переделать внутренние линия питания 240 В в SBG1/SBG4, а также проверить целостность опто-волоконных линий в другие ДЦ компании в Париже и Франкфурте.

OVH планирует перезагрузить оборудование в SBG1+SBG4 и сеть 15 марта, а SBG3 — 19 марта. Иначе говоря, им потребуется минимум неделя, чтобы восстановить доступ к уцелевшим серверам. В других ДЦ имеет запас серверов и оборудования, которое будет перемещено. По словам президента Octave Klaba они установят 10000 новых серверов в течение ближайших 3-4 недель.

Само собой консоль OVH manager не работает на данный момент, и клиенты не могут посмотреть состояние своих серверов и данных, даже если они остались целыми. Однако, пользователи хотя бы могут узнать, в каком ЦОД был из сервер через OVH dashboard. Для этого надо пройти по адресу https://www.ovh.com/manager/dedicated/#/iaas/vps/vps123456.ovh.net/dashboard, где vps123456.ovh.net — имя VPS вашего VPS/VDS сервера. Там вам нужно проверить секции Zona (Cluster) и Location. Пользователи также констатируют, что не доступен и OVH backupspace, то есть все их бэкапы.

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

Из интересного обнаружилось, что страницы мониторинга http://status.ovh.com/vms/index_sbg2.html показывают, что все серверы доступны. Из чего можно сделать вывод, что статистика фейковая или не обновляется при отсутствии сетевого подключения. То есть серверы могут потерять связность, но будут зелеными в мониторинге :)

Причины пожара

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

Пообщавшись с экспертами в области архитектуры, стало ясно, что пожарные нормы в РФ гораздо строже, чем в Европе, причём в РФ они ужесточаются каждый год. Смотря на структуру зданий OVH можно заметить, что они простроены по принципу простейшего ангара. Кроме того, в них используются CO2 огнетушители, наравне с автоматической системой пожаротушения. Однако, она не эффективна на больших по объему пространствах. Кроме того, OVH активно использует физические контейнеры для построения контейнерных ДЦ. Само собой, с этими «кубиками» невозможно обеспечивать централизованное пожаротушение. Кроме того, схема охлаждение типа free cooling подразумевает приток наружного воздуха, при котором невозможна герметизация помещений.

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

Более подробно о пожарной безопасности дата-центров мнения экспертов вы можете почитать здесь.

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

Кто пострадал

В список пострадавших клиентов OVH входит компания Bad Packets , занимающаяся разведкой киберугроз, шахматный интернет-сервер Lichess.org, криптовалютная биржа Deribit, программное обеспечение для шифрования «на лету» VeraCrypt, новостной портал eeNews Europe, сайт аэропорта Стасбурга, официальные сайт парижского Центра Помпиду и 25 игровых серверов Rust. Создатели Rust из Facepunch Studios объявили, что они утратили огромную часть данных европейских игроков из-за пожара, все данные игроков с этих серверов утеряны. Всего пострадало около 3,6 миллионов сайтов, большая часть из которых — европейские. Согласно аналитике Gartner потери от даунтаймов обходятс в среднем около $300000 в час, то есть $5600 в час.

Среди российских хостеров ДЦ OVH популярен для услуг колокейшен и VPS/VDS. Поэтому некоторые российские хостеры не могли представлять услуги хостинга сегодня, в их числе: hostiman.ru, webhost1.ru, mangohost.net, bitweb.ru, waf.ovh, Fornex.com, ZTV.su и многие другие.

Список VPS/VDS хостингов, использующих сервера во Франции (не все из них использовали поврежденный ДЦ) можно посмотреть по ссылке: http://hosting101.ru/catalog/fr

Итоговые мысли

По итогу мысли только одни: современные ДЦ, несмотря на всю навороченность технологий резервирования, по-прежнему не гарантируют сохранность ваших данных на 100%. Вы всегда должны иметь бэкапы в другом ДЦ, чем находятся ваши серверы. Имеет смысл настроить DNS записи на небольшое значение TTL (например, 3600) и управлять ими через панель регистратора, а не через панель хостера. Так вы сможете развернуть сайт из бэкапа на другом хосте в течение часа.

[Посещений: 1 511, из них сегодня: 1]

Свежие посты

Процессы зомби, демоны и сироты в Linux

Процессы и программы Программа в Unix — это последовательность исполняемых инструкций на диске. Вы можете…

12 октября 2024

Изучаем сертификаты, приватные ключи и keystore

Существует большое разнообразие форматов, в которых создаются сертификаты и приватные ключи для них. Часто они…

20 июля 2024

Восстановление доступа к Docker Hub

Все известно, что Докерхаб закрыл доступ для пользователей из санкционных стран, включая РФ и РБ.…

30 мая 2024

Как посмотреть сертификат хоста через командную строку

Зачастую бывает необходимо проверить, а какой SSL сертификат отдает тот или иной хост на определенном…

21 февраля 2024

Использование choco через прокси

Choco - лучший пакетный менеджер для Windows. Чтобы использовать его в корпоративной среде за прокси,…

21 февраля 2024

Обзор SSD диска XrayDisk

В России становится все больше малоизвестных китайских товаров, поэтому сегодня у нас на обзоре китайский…

3 декабря 2023