Живая миграция виртуальных машин: как перенести RAM и процессы без простоя

Живая миграция (live migration) переносит работающую виртуальную машину с одного физического сервера на другой без остановки гостевой ОС и без перезапуска приложений внутри неё.

В классических ЦОД её используют для обслуживания оборудования. В мире прерываемых ресурсов тот же механизм становится способом пережить отключение хоста: вместо SIGTERM и холодного перезапуска платформа успевает перенести RAM и процессы на соседний сервер.

Коротко: живая миграция переносит RAM и процессы работающей ВМ на другой сервер без перезапуска приложения. Но работает только вместе со стабильной сетью и реплицируемыми томами.

Сначала о механике переноса — предварительном копировании (pre-copy) и приостановке с финальной передачей (stop-and-copy). Затем — точки отказа при миграции одной памяти и реакция оркестратора microsrv на уведомление об отзыве хоста.

1. Зачем нужна живая миграция

Без живой миграции смена хоста почти всегда означает холодный перезапуск:

процессы принудительно завершены, кэш в оперативной памяти сброшен;
локальные эфемерные диски потеряны;
IP-адреса потеряны, TCP-соединения разорваны;
клиенты видят простой до повторной загрузки и реконфигурации.

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

2. Предварительное копирование: итеративная передача памяти

Большинство гипервизоров (KVM/QEMU, Xen, VMware) используют схему pre-copy:

Первый проход. ВМ продолжает работать на исходном хосте, а гипервизор копирует страницы RAM на целевой сервер.
Грязные страницы (dirty pages). Гостевая ОС продолжает писать в память. Изменённые страницы помечаются и пересылаются повторно.
Сходимость. Пока скорость передачи выше скорости появления новых изменений, объём оставшихся изменённых страниц уменьшается.
Stop-and-copy. vCPU гостевой ВМ на короткое время останавливаются, досылается оставшаяся память и состояние устройств, затем ВМ возобновляет работу уже на целевом хосте.

Пауза обычно длится миллисекунды или десятки миллисекунд. Тайм-ауты TCP и health-check’и клиентов её чаще всего не замечают. Условие одно: сеть и тома на новом хосте тоже готовы принять ВМ.

Post-copy: передача страниц памяти по требованию

В схеме post-copy ВМ сразу запускается на целевом хосте, а недостающие страницы подгружаются по требованию при page fault. Переключение происходит быстрее, но растут всплески задержки и зависимость от канала миграции. На практике оркестраторы часто комбинируют подходы или берут pre-copy как более предсказуемый вариант при коротком окне эвакуации перед отзывом хоста.

3. Что ломается, если мигрировать только RAM

Успешный перенос памяти — необходимое, но недостаточное условие. Без двух других слоёв клиент всё равно получает сбой:

Сеть. Внутренний IP, маршруты и сокеты привязаны к старому хосту, и после переключения пакеты теряются. Подробно это разобрано в статье про eBPF-сеть microsrv.
Диски. Корневой том и данные лежали только на локальном SSD исходного сервера. На целевом хосте файловой системы просто нет. Нужна репликация томов, независимая от конкретного Spot-узла.

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

4. Холодный перезапуск: резервный сценарий при аварии

Живая миграция работает, когда есть предупреждение и канал связи с целевым хостом. Если сервер мгновенно обесточен или произошла паника ядра, предварительное копирование завершить невозможно.

Остаётся холодный перезапуск из реплики:

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

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

5. Как оркестратор microsrv реагирует на отключение хоста

Платформа microsrv использует прерываемые ресурсы крупных облачных провайдеров и управляет ими через собственный оркестратор. Типичная последовательность при получении сигнала прерывания:

Получено уведомление об отзыве — обычно за десятки секунд до принудительной остановки сервера.
Резерв на соседнем хосте. Оркестратор заранее отслеживает свободные вычислительные ресурсы и память, чтобы было куда переносить нагрузку.
Живая миграция RAM и процессов. Гостевая ВМ переносится без перезапуска приложения.
Обновление eBPF-маршрутов. Трафик и открытые TCP-соединения следуют за ВМ.
Освобождение исходного хоста. Провайдер отзывает прерываемые ресурсы, клиент продолжает работу на новом узле.

Если времени на миграцию нет, срабатывает холодный перезапуск из реплицированного тома. Для приложения это выглядит как редкая аварийная перезагрузка, а не как повседневная цена Spot-модели.

6. Практический вывод для инженеров

Живая миграция устраняет главный эксплуатационный недостаток Spot: принудительный перезапуск при каждом отзыве хоста.
Сама по себе миграция памяти бесполезна без стабильной сети и томов, не зависящих от исходного сервера.
Разделяйте два сценария: штатный отзыв после уведомления провайдера → живая миграция; аварийный отказ оборудования → холодный перезапуск из реплики.
В microsrv эта связка уже собрана: оркестратор + реплицируемое хранилище + eBPF-сеть дают около 25% экономии относительно тарифов крупных облаков, без переписывания приложений под graceful shutdown и ручные контрольные точки.

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

QEMU — Migration (pre-copy, post-copy, dirty pages)
KVM — Live migration internals (kernel.org)
Clark et al. — “Live Migration of Virtual Machines” (NSDI ’05) — базовый pre-copy-подход
Сопутствующие статьи microsrv: eBPF-сеть (почему одной памяти недостаточно) и репликация томов (непрерывность диска)

Как проверяли: лабораторная миграция гостевой ВМ на KVM с 8 ГБ RAM командой migrate --live показала паузу stop-and-copy в десятки миллисекунд; TCP-сессии удерживались при перепривязке eBPF-карт на целевой хост. При внезапном отказе срабатывает холодный перезапуск из реплики, а не пропущенная миграция.