Репликация томов виртуальных машин: как не потерять данные при отказе хоста

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

В статье про прерываемые ВМ потеря локальных дисков названа одним из главных рисков. Дальше — почему временное хранилище несовместимо с надёжной работой на прерываемых ресурсах, чем репликация отличается от бэкапа в объектное хранилище и как устроена репликация томов в microsrv.

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

1. Временное и постоянное хранилище: что происходит при отказе

Временный (локальный) диск привязан к жизненному циклу инстанса ВМ или физического хоста. Стоит удалить инстанс или столкнуться со сбоем оборудования — и данные исчезают вместе с сервером. Такой диск дёшев и быстр (высокие IOPS), но годится только для:

временных кэшей сборки;
промежуточных данных, которые можно пересчитать;
слоёв, которые и так вынесены во внешнее хранилище.

Постоянный реплицируемый том существует независимо от конкретного вычислительного узла. ВМ можно остановить, перенести или запустить на другом хосте, и том останется при ней. Для сервисов с состоянием это базовая необходимость.

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

2. Репликация — не то же самое, что бэкап

Путаница между бэкапами и репликацией обходится дорого:

	Резервная копия (например, снимки в объектном хранилище)	Непрерывная репликация
Когда пишется	По расписанию или вручную	Постоянно / с коротким лагом
RPO	Минуты–часы между точками	Секунды или меньше
Назначение	Откат после логической ошибки, атаки вируса-шифровальщика (ransomware) или ошибки пользователя	Пережить отказ текущего хоста
Время восстановления	Создать том из снапшота, примонтировать, поднять сервис	Перепривязать уже синхронизированный том

Бэкапы нужны всегда. Но когда уведомление об отзыве хоста даёт 30–120 секунд до отключения, спешно разворачивать последний снимок из S3 слишком рискованно. Переключаться лучше на том, который непрерывно реплицировался параллельно с записью.

3. Синхронная и асинхронная репликация: цена RPO

Репликация бывает разной по гарантиям:

Синхронная. Запись считается завершённой, когда подтверждена на реплике. Минимальный RPO (для подтверждённых записей часто ≈ 0), выше задержка ввода-вывода (I/O latency).
Асинхронная. Запись подтверждается локально, реплика догоняет с задержкой. На задержку записи влияет меньше, но при внезапном отказе первичного узла теряются последние ещё не синхронизированные записи.
Периодические снимки. Проще в эксплуатации, худший RPO: по сути классический бэкап.

Строя оркестрацию поверх прерываемых ресурсов, заранее ответьте на вопрос: какой RPO допустим при аварийном отказе хоста? Для кэша CI — минуты. Для PostgreSQL с пользовательскими транзакциями — секунды или меньше. И помните: несохранённое состояние в памяти может пропасть при холодном перезапуске независимо от репликации.

4. Связка с живой миграцией и холодным перезапуском

Живая миграция переносит RAM и процессы. Диск при этом не копируется с нуля в момент переключения: целевой хост должен уже видеть актуальный том (через сетевое или распределённое хранилище либо заранее прогретую реплику). Иначе после stop-and-copy гостевая ОС поднимется без корневой файловой системы.

Если аварийный отказ хоста оборвал предварительное копирование памяти:

вычислительные ресурсы на исходном хосте потеряны;
оркестратор поднимает ВМ на новом узле;
том подключается из реплики;
сеть (см. eBPF-слой) возвращает стабильный IP и маршруты.

Данные на томе сохранены, приложение проходит обычную загрузку. Это не работа без простоя, но контролируемое восстановление вместо сценария «экземпляр исчез вместе с диском».

5. Как microsrv сохраняет тома

В платформе microsrv репликация хранилища — стандарт для всех клиентов:

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

Вместе с оркестратором и eBPF-сетью это превращает прерываемые мощности в ВМ, на которых можно держать и пакетные задачи, и сервисы с локальной файловой системой. Экономия — около 25% относительно тарифов крупных облаков.

6. Главные выводы и чек-лист

Не храните единственную копию данных на локальном временном SSD прерываемого инстанса.
Разделяйте бэкап (логическое восстановление) и репликацию (переживание отказа хоста).
Зафиксируйте целевой RPO для аварийного отказа и осознанно выберите синхронную или асинхронную репликацию.
Проверяйте оба сценария: штатное отключение хоста с живой миграцией и отдельно холодный перезапуск из реплицированного тома.
В microsrv репликация томов уже встроена в платформу. Контрольные точки «на всякий случай» по-прежнему полезны для прикладной логики, но единственной защитой файловой системы служить не должны.

Источники и что почитать дальше

SNIA — Online Dictionary: replication, см. также Репликация данных (Википедия)
Блочный слой Linux — DRBD и Ceph RBD как референсные дизайны реплицируемых томов
Хранилище KVM — QEMU block jobs / live storage migration
Сопутствующее: живая миграция (почему на целевом хосте том должен быть уже виден)

Как оценивать RPO: при синхронной репликации PostgreSQL подтверждённые записи имеют RPO≈0; при асинхронной последние секунды могут потеряться при внезапном отказе. Тестируйте оба пути: штатное вытеснение и холодный перезапуск.

FAQ

Репликация — это бэкап? Нет. Репликация переживает потерю хоста (RPO — секунды); бэкап (снапшоты в S3) откатывает логические ошибки. Нужно и то и другое.

Нужно ли чекпоинтить в S3 на Spot? Да, для инвариантов приложения, но не как единственная защита от потери файловой системы.