Кратко

  • Сбои Cloud Storage 8 и 9 октября длились в us-central1 и us-central1-b в общей сложности 18 часов 11 минут; опубликованные симптомы в основном относились к записи.
  • Google объясняет первый эпизод оптимизацией, обошедшей маршрутизацию с учётом мощности, а повторный — неполным откатом; пострадавшие клиенты и размер ущерба не названы.

Сбой облачного хранилища часто обсуждают через вопрос о расположении копий данных. Отчёт Google заставляет поставить другой вопрос: по какому пути проходит запрос записи, прежде чем становится сохранённым объектом? 8 октября пользователи Cloud Storage в us-central1 наблюдали повышенную задержку и больше ошибок записи в течение 12 часов 30 минут. На следующий день проблема повторилась в зоне us-central1-b и длилась 5 часов 41 минуту. Суммарная длительность по версии Google — 18 часов 11 минут, но это два эпизода с восстановлением между ними, а не единый 18-часовой перерыв.

Описанные симптомы конкретны. По словам Google, чаще всего клиенты получали HTTP 503 UNAVAILABLE при операциях WriteObject и сталкивались с тайм-аутами на стороне клиента; успешные записи также выполнялись заметно медленнее. В итоговом отчёте говорится, что другие регионы Cloud Storage и другие сервисы Google Cloud в рамках этого события не пострадали. В ранней предварительной части упоминалось небольшое влияние на чтение, но итоговая сводка не приводит его масштаб. Следовательно, запись подтверждает ограниченную проблему пути записи в одном регионе, а при повторении — в одной зоне.

Она не доказывает, что пострадали все клиенты региона, что не удалась каждая запись или что были потеряны сохранённые объекты.

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

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

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

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

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

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

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

Объявленные Google меры профилактики следуют этой цепочке. Компания планирует проверять изменения балансировки в небольших регионах до их развёртывания в крупных, сильно загруженных регионах; усилить ограничения мощности, чтобы логика распределения не обходила упреждающие меры защиты; и улучшить внутреннее перемещение данных в сильно используемых ячейках хранения. Это будущие меры в изложении Google, а не независимо подтверждённые завершённые изменения. В публичной записи нет результатов испытаний, количества затронутых запросов, списка клиентов, распределения типов бакетов или измеренных потерь.

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

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