Технология Live Migration: перенос работающих виртуальных машин

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

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

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

Анатомия невозможного

Виртуальная машина - это изолированная среда, состояние которой можно полностью описать и воссоздать в другом месте. На этом всё и держится.

Как идёт перенос

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

Дальше начинается главное - синхронизация памяти. Гипервизор копирует содержимое оперативной памяти на целевой хост. Машина работает, часть страниц за время копирования успевает измениться, гипервизор помечает их как «грязные» и копирует заново. Потом ещё раз. И ещё, пока объём изменившегося за один проход не станет достаточно малым.

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

Такая схема называется pre-copy: сначала копируем память, потом переключаемся. Обычно пауза укладывается в доли секунды, но точная цифра зависит от того, насколько быстро машина пачкает память. Спокойный файловый сервер уедет за десятки миллисекунд. Нагруженная СУБД, которая пишет в память быстрее, чем гипервизор успевает копировать, может не сойтись вообще - итерации будут повторяться, пока гипервизор не сдастся или не остановит машину принудительно.

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

Как живая миграция называется у разных платформ

Единого термина нет. Отсюда половина проблем при поиске документации: человек читает про live migration, а в интерфейсе видит vMotion, и не понимает, одно это и то же или нет. Одно.

Отдельно про РЕД Виртуализацию, потому что формулировка там своя. Функция называется живой миграцией, а способ переноса памяти задаётся политикой миграции - той самой развилкой pre-copy и post-copy из предыдущего раздела, только названной по-человечески: память переносится до запуска машины на новом хосте или после.

Какая платформа что ещё умеет помимо миграции - в отдельном разборе: сравнение гипервизоров 2026.

Технические ограничения и требования

Живая миграция не работает по принципу «включил и забыл». Требования к инфраструктуре вполне конкретные.

Сеть

Пропускная способность между хостами прямо определяет скорость переноса. Минимум - 1 Гбит/с, нормально - 10 Гбит/с, особенно для машин с большим объёмом памяти или высокой активностью записи. Под миграцию выделяют отдельную сеть или хотя бы отдельный VLAN: иначе перенос будет конкурировать с продуктивным трафиком, а страдать будут оба.

Задержка тоже важна. Высокие задержки удлиняют финальную паузу, и для переноса между географически разнесёнными площадками это становится ограничивающим фактором.

Сколько ресурсов закладывать под сам кластер, разбирали отдельно - планирование ресурсов для виртуальных машин.

Совместимость процессоров

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

Обходится это маскировкой: гипервизор показывает машинам набор инструкций по самому старому поколению в кластере. У VMware механизм называется EVC (Enhanced vMotion Compatibility), у Hyper-V - режим совместимости процессоров (Processor Compatibility Mode). Цена - часть возможностей новых процессоров остаётся невостребованной.

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

Миграция без общего хранилища

Утверждение «для живой миграции нужно общее хранилище» кочует по статьям с середины двухтысячных и давно устарело.

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

Но обязательным условием оно перестало быть больше десяти лет назад. Hyper-V умеет переносить машины между отдельно стоящими хостами без кластера и общего хранилища с Windows Server 2012 - функция так и называется, Shared Nothing Live Migration. VMware добавила такую же возможность в vSphere 5.1. Proxmox переносит машины с локальными дисками ключом --with-local-disks. В zVirt 5.0 заявлена живая миграция между центрами обработки данных без общей СХД.

Разница в цене операции. Без общего хранилища по сети едет ещё и диск, поэтому перенос занимает не секунды, а минуты или десятки минут - в зависимости от объёма. Сама машина при этом всё время работает, пауза в конце такая же короткая.

Разновидности миграции

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

Плановая

Выполняется для обслуживания железа, балансировки или консолидации. У администратора есть время подготовиться и выбрать момент. Это основной режим, ради которого технологию и держат.

Аварийная

Здесь важно не путать понятия, потому что путают часто. Если хост уже отказал, живой миграции не будет - переносить нечего, память умерла вместе с хостом. В этом случае работает механизм высокой доступности: машины перезапускаются на других хостах с потерей их текущего состояния, как после внезапного отключения питания. Живая миграция помогает раньше - когда хост ещё жив, но подаёт признаки проблем: сыпется память, греются диски, деградировал блок питания.

Автоматическая балансировка

Кластер сам следит за загрузкой хостов и перераспределяет машины. У VMware этим занимается DRS (Distributed Resource Scheduler), у остальных платформ есть свои планировщики с похожей логикой. Настраивается порог агрессивности: от «только советовать администратору» до «переносить самостоятельно».

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

Практические применения

Обслуживание без простоев

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

Энергоэффективность

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

Аварийное восстановление

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

Российские платформы: как обстоят дела здесь

Вопрос не праздный: VMware в России официально не продаётся с 2022 года, а на продлении подписок Broadcom поднял цены в разы. Живая миграция при этом есть у всех основных российских платформ - это базовая функция KVM, на котором они построены, а не чья-то уникальная разработка.

zVirt - KVM с управлением, унаследованным от oVirt. В версии 5.0 заявлена живая миграция между центрами обработки данных без общей СХД, и это самое интересное, что случилось в теме за последнее время.

РЕД Виртуализация - живая миграция с настраиваемой политикой миграции, то есть с выбором между pre-copy и post-copy на уровне интерфейса.

ROSA Virtualization - в версии 4.0 появился встроенный механизм аварийного восстановления, что среди российских платформ пока редкость и напрямую относится к сценарию с двумя площадками.

Подробный разбор платформ с лицензированием и сертификацией - в материале про гиперконвергентную инфраструктуру на zVirt, ROSA и «Альт».

Подводные камни и ограничения

Влияние на производительность

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

Риск при обрыве связи зависит от схемы

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

Инфраструктурные зависимости

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

Лицензии, привязанные к железу

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

Безопасность

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

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

Что она не заменяет - так это высокую доступность и резервное копирование. Живая миграция помогает, пока хост жив. Дальше нужны другие механизмы, и закладывать их надо в том же проекте.