Что показал сбой Google Cloud: почему даже гиперскейлеры не могут доказать отказоустойчивость дата-центров

15 часов простоя, три упавших сервиса и один физический дата-центр, о зависимости от которого клиенты даже не подозревали. Так выглядел сбой Google Cloud в зоне europe-west4-a (Нидерланды), который на прошлой неделе разобрал The Register. Авария любопытна не сама по себе, а выводом, к которому приводит: оценить реальную отказоустойчивость дата-центров облачного провайдера со стороны почти невозможно, и касается это не только Google. Ниже разберём, что сломалось, где спряталась точка отказа и какой чек-лист снижает ваши риски, когда полагаться на обещания провайдера вслепую не хочется.

15 часов темноты: что именно упало в europe-west4

Из строя вышли три управляемых сервиса: VMware Engine (GCVE), NetApp Volumes и Bare Metal Solutions (BMS). Простой длился около 15 часов. По отчёту Google, дата-центр, обслуживающий europe-west4-a для этих трёх сервисов, «испытал сбой питания, который затем вызвал отказ системы охлаждения».

Дальше начинается самое любопытное. Первопричина, по формулировке самой компании, лежала снаружи здания: «Электрический сбой произошёл в питающей энергосети выше дата-центра, нарушив работу распределительного электрооборудования и оборудования охлаждения». Как внешняя авария пробила внутреннюю защиту (резервное питание, ИБП, генераторы), Google не объяснил. Чтобы данные клиентов не пострадали от перегрева, компания «превентивно снизила нагрузки». Часть инфраструктуры выключили сознательно, ради сохранности данных.

The Register спросил Google, были ли на площадке дизель-генераторы и почему при их наличии всё же пришлось гасить нагрузку. К моменту публикации ответа не было. Анализ инцидента, по словам компании, продолжается, а финальный отчёт с «предупредительными мерами» обещан позже.

Один дата-центр на три сервиса: где спрятана точка отказа

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

Разберём матрёшку, которую облака прячут за красивыми словами. Регион это географическая площадка (например, europe-west4 в районе Эмсхавена в Нидерландах). Внутри региона несколько зон (europe-west4-a, -b, -c), которые считаются независимыми: своё питание, охлаждение, сеть. Предполагается, что падение одной зоны не тянет за собой другие. Но зона не обязательно одно здание, и одно здание не обязательно обслуживает всю зону целиком. Отдельные управляемые сервисы могут висеть на конкретном ЦОД внутри зоны. Вот там и живёт единая точка отказа, которую вы со стороны не видите.

Аналитик Forrester Бисваджит Махапатра формулирует прямо: «Реальная проблема это прозрачность: клиентам говорят использовать несколько зон и регионов, но редко дают понимание, есть ли у конкретного управляемого сервиса зависимость от одного дата-центра внутри зоны». Многие организации, по его словам, ошибочно полагают, что облачная абстракция даёт больше резервирования на уровне площадки, чем есть в реальности.

«Выше по сети»: почему отказ питания рушит охлаждение

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

Для защиты как раз и существуют схемы резервирования: N+1 (один запасной элемент на группу), 2N (полное дублирование), источники бесперебойного питания и дизель-генераторы, которые должны подхватить нагрузку за секунды. Но их наличие не гарантирует бесперебойность при нештатной внешней аварии. Если сбой в питающей сети повредил распределительное оборудование внутри объекта, генераторам может быть просто некуда отдавать ток. Или охлаждение всё равно не успевает восстановиться, и оператор идёт на аварийное снижение нагрузки, чтобы не потерять данные. Судя по отчёту, именно так поступил Google.

Париж-2023 и Нидерланды-2026: когда репликация не спасает

Это уже не первый раз. Адриан Вонг из Gartner напомнил про сбой 2023 года в зоне europe-west9-a (Париж) из-за утечки воды, которая, по словам Google, «возникла в не-Google части объекта». Тогда межзональная репликация базы данных Spanner не отработала как ожидалось, стоило одному зданию стать недоступным. Вонг говорит без обиняков: «Очень трудно разобраться, как устроен отдельный регион. Наши клиенты часто этому удивляются».

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

Отказоустойчивость дата-центров: проблема не только Google

Махапатра подчёркивает, что архитектура не уникальна для Google. У AWS, Azure и Google есть сервисы на выделенном «железе» или платформах хранения, которые не распределены по нескольким площадкам так же, как базовые вычисления и хранилище. В том же материале The Register упоминает недавний сбой AWS CloudFront и массовый отказ мобильной связи в Австралии из-за проблемы с NTP-сервером. Ломается у всех, вопрос лишь в том, знаете ли вы заранее, где именно тонко.

И вот вывод источника, который легко пропустить: даже когда Google опубликует финальный отчёт и расскажет, как будет предотвращать подобное впредь, у клиента всё равно не появится инструмента понять, устранят ли эти меры скрытые дефекты проектирования. Вы получаете обещание, но не схему.

Что спрашивать у облачного провайдера

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

Отталкиваясь от таблицы, задайте провайдеру предметные вопросы: привязан ли конкретный управляемый сервис к одному дата-центру внутри зоны; как ведёт себя репликация, когда недоступно одно здание, а не вся зона; что прописано в SLA именно для управляемых сервисов, а не только для базового compute. Ответы на это редко лежат на поверхности, их приходится вытаскивать.

Что это значит для пользователей из РФ и СНГ

Для аудитории в России и СНГ урок простой: не складывайте всё в одну корзину, будь то облако или один канал доступа. Держите бэкапы в независимой геолокации или у другого провайдера. Проверяйте, где физически лежат ваши данные, и имейте план на случай многочасового простоя, а не только на тот случай, когда «всё работает».

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

Частые вопросы

Значит ли это, что облаку нельзя доверять?

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

Помогла бы мультизона в этом сбое?

Не факт. Упавшие сервисы (GCVE, NetApp Volumes, BMS) были завязаны на выделенный дата-центр, поэтому «другая зона» не гарантировала бы им спасение. В этом и суть претензии аналитиков: к прозрачности, а не к самому факту сбоя.

Что делать обычному пользователю, а не бизнесу?

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

Источники

The Register, разбор сбоя Google Cloud и проблемы прозрачности отказоустойчивости гиперскейлеров