Живая миграция контейнеров
Механизм бесшовного переноса работающих контейнеров между Spot-хостами без перезапуска процессов и с сохранением TCP-сессий.
Зачем нужна живая миграция контейнеров?
В стандартных контейнерных платформах (Kubernetes, Docker) концепция живой миграции (Live Migration) не поддерживается:
- При выводе узла на обслуживание или отзыве Spot-инстанса облачным провайдером Kubernetes отправляет процессам сигнал
SIGTERM, принудительно завершает контейнеры (SIGKILL) и перезапускает их с нуля на другом сервере. - Это приводит к сбросу оперативной памяти, разрыву всех активных клиентских TCP-соединений (WebSockets, gRPC-стримов, пулов соединений к базам данных) и потере неэкспортированного состояния.
В платформе microsrv контейнеры поддерживают полноценную живую миграцию наравне с виртуальными машинами (KVM).
[!NOTE] Контейнер перемещается на новый физический сервер без остановки исполняемого кода, сброса кэшей в RAM или разрыва сетевых подключений.
Архитектура живой миграции
Благодаря изоляции песочницы, все структуры операционной системы (таблицы виртуальной памяти, дескрипторы файлов, потоки выполнения, таймеры и сетевой стек) инкапсулированы внутри независимого пространства пользователя:
1. ТЕЛЕМЕТРИЯ: СИГНАЛ ОТЗЫВА ХОСТА
[TELEMETRY] Получен сигнал отзыва хоста (T-120s) • Резервирование мощности на Хосте B...
Этапы процесса миграции
- Отслеживание событий провайдера: Оркестратор microsrv непрерывно анализирует аппаратную телеметрию и заблаговременно определяет интервал до отзыва Spot-хоста.
- Предварительное копирование памяти (Фаза Pre-copy):
- Содержимое оперативной памяти песочницы и приложения асинхронно передаётся на целевой узел через высокоскоростную внутреннюю сеть дата-центра.
- Контейнер продолжает исполнять инструкции и отвечать на запросы пользователей. Изменяемые во время передачи страницы памяти помечаются и передаются повторными итерациями.
- Финальное переключение (Фаза Stop-and-copy, менее 50 мс):
- Исполнение инструкций процессора кратковременно приостанавливается.
- Финальный срез изменённых страниц памяти и регистры CPU передаются на целевой узел.
- Право записи в распределённый NVMe-диск (Stateful OverlayFS) переходит целевому хосту.
- Атомарная перемаршрутизация через eBPF:
- eBPF-программы на сетевых маршрутизаторах атомарно обновляют таблицы сокетов.
- Сетевой трафик мгновенно перенаправляется на новый хост.
- Клиенты не получают ошибок
Connection reset by peer— все активные TCP-сокеты остаются открытыми.
Сравнение поведения при отзыве Spot-хоста
| Характеристика | Kubernetes (Spot Eviction) | Контейнеры microsrv (Live Migration) |
|---|---|---|
| Время недоступности (Downtime) | 10–60 секунд (холодный старт) | 0 секунд (микропауза < 50 мс) |
| Состояние оперативной памяти | Полностью сбрасывается | Сохраняется на 100% |
| Активные TCP-соединения | Принудительно разрываются | Сохраняются без сброса |
| Данные на диске | Сбрасываются (если не настроен PVC) | Сохраняются (Stateful OverlayFS) |
| Влияние на пользователей | Ошибки 502/504, повторная авторизация | Незаметно для пользователей |
Обработка нештатных ситуаций
- Штатный отзыв Spot-инстанса: Запуск автоматической живой миграции с нулевым временем простоя.
- Внезапный аппаратный сбой (Kernel panic хоста / отключение питания):
Если физический сервер отключается мгновенно без предупреждения со стороны дата-центра, оперативная память не может быть скопирована. В этом случае оркестратор автоматически запускает холодный перезапуск (Cold Restart):
- Контейнер инициируется на новом сервере.
- К нему монтируется тот же реплицированный NVMe-том со всеми сохранёнными данными Stateful OverlayFS.
- Контейнер сохраняет свой постоянный приватный IP-адрес в VPC.
Статус контейнера при миграции
Во время переноса контейнера в веб-консоли и API в поле state отображается статус Migrating. После завершения переноса статус автоматически возвращается в Running.