← назад к разделу

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

Облако даёт для этого готовые кирпичи — зоны, реплики, копии, — но не собирает их за вас и не проверяет, что собранное работает. В этой статье — две разные задачи, которые часто путают, два числа, которые определяют схему, и правило про непроверенную копию.

Главное

  • Отказоустойчивость и восстановление — разные задачи: первая переживает отказ железа, вторая возвращает данные после ошибки или катастрофы.
  • Раскладка копий по зонам за балансировщиком и реплика базы в другой зоне закрывают отказ дата-центра; от ошибки в данных они не спасают, реплика повторит удаление.
  • RPO — сколько данных вы готовы потерять, задаётся частотой копий; RTO — сколько времени готовы стоять, задаётся способом восстановления.
  • Копии снимает провайдер, но восстановление проверяете вы: копия, которую ни разу не восстанавливали, — не копия, а надежда.
  • Второй регион берут, когда потеря региона недопустима; для большинства продуктов достаточно зон одного региона и проверенных копий.
  • Схему восстановления записывают и прогоняют по расписанию, а не вспоминают во время аварии.

Две разные задачи

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

Восстановление — про другое: данные испорчены или потеряны, и их надо вернуть. Ошибочный запрос удалил строки, миграция сломала таблицу, регион лёг целиком. Дублирование здесь не помогает — реплика честно повторит удаление. Спасают только копии, отдельные от боевых данных, и заранее известный порядок их возврата.

Путают их постоянно: «у нас есть реплика, значит, копии не нужны». Реплика защищает от отказа узла, копия — от ошибки. Нужны обе.

Отказоустойчивость: зоны и реплики

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

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

Восстановление: RPO, RTO и копии

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

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

Ключевое правило, которое нарушают чаще всего: копия, которую ни разу не восстанавливали, — не копия, а надежда. Восстановление прогоняют по расписанию, на отдельной базе, с замером времени, и это же время и есть ваш реальный RTO.

Четыре стратегии восстановления

От дешёвой к дорогой. Копия и восстановление: только копии, при аварии поднимаем всё заново — часы простоя, минимум денег. Тлеющий огонёк: в резервном регионе есть база с репликацией и минимальная инфраструктура, приложение поднимают при аварии — десятки минут. Тёплый резерв: уменьшенная копия системы работает постоянно, при аварии её масштабируют — минуты. Активный-активный: оба региона обслуживают трафик всё время — секунды, вдвое дороже и сложнее в данных. Выбирают по RPO и RTO, а не по красоте: для большинства продуктов правильный ответ — первая или вторая.

Глубже: что ломается при переключении на реплику

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

Второй эффект — потеря последних транзакций при асинхронной репликации: реплика отстаёт на секунды, и то, что не успело доехать, теряется. Синхронная реплика этого не допускает, но платит задержкой на каждой записи. Выбор между ними — это тоже про RPO.

Глубже: учения по восстановлению

Схема восстановления, записанная в документе, стареет: меняются адреса, права, версии. Единственный способ узнать, что она работает, — прогнать её. Раз в квартал команда восстанавливает базу из копии на отдельный стенд, поднимает сервис на нём и замеряет время. Расхождения с документом чинят сразу, а замер становится честным RTO вместо предполагаемого. Это скучная работа, и именно её пропускают чаще всего.

Что почитать дальше