Миграция Proxmox: где ломается перенос машин между нодами
При переносе виртуальных машин между нодами Proxmox задача выглядит линейной: скопировать память, переключить владение, погасить источник. На практике живая миграция идёт в несколько проходов — сначала переносится основной объём, затем догоняются изменённые страницы памяти. Если гость активно пишет в память (база данных, кэш, очередь), догон не сходится: перенос тянется десятки минут и заканчивается всё той же остановкой, которую никто не планировал.
Типовые сбои начинаются раньше, чем заканчивается копирование. Обрыв связи между нодами на середине процесса оставляет на источнике запись-замок и незавершённую задачу: машина не поднимается ни на старой ноде, ни на новой, пока замок не снят вручную. Несовпадение хранилищ даёт сбой уже после переноса памяти — на целевой ноде нет того же пула или тома, и работа откатывается к исходной точке.
Сеть — отдельный источник отказов. На целевой ноде другой мост, другие метки VLAN, адрес гостя уезжает в чужой сегмент, и сервис становится недоступен, хотя перенос формально прошёл. Кластер виртуализации добавляет свой слой: нода на время выходит из голосования, и при малом числе участников перенос блокирует соседние операции.
Простой сервиса здесь и есть цена ошибки. При офлайн-переносе окно недоступности равно времени копирования диска, а при ручных переключениях администратор поднимает сервис раньше, чем гость действительно стартовал. Дальше разбираем, как это закрывается.
Что даёт плановый перенос: простой, целостность, откат
Плановый перенос — операция с измеримым бюджетом простоя, а не «перезагрузим и посмотрим». При живой миграции гипервизор итеративными проходами догоняет память гостя, пока расхождение не станет минимальным, затем останавливает машину на доли секунды, переносит последнее состояние и поднимает её на целевой ноде — соединение приложения при этом не рвётся. Офлайн-перенос делает наоборот: гость останавливается, диски копируются, машина поднимается заново. Простой здесь равен времени передачи, зато исключены любые расхождения по состоянию.
Целостность держится на трёх проверках: снимок диска на исходной ноде, контроль заполненности хранилища на целевой и сверка размера и контрольных сумм после переноса. Для баз данных и кластеров с кворумом узлы переезжают по одному, а Proxmox VE позволяет задать порядок и убедиться, что кворум не потерян ни на одном шаге.
Точка отката — это не резервная копия, а сохранённая конфигурация машины и её диски на исходной ноде: они не удаляются, пока целевая не подтвердит приём и запуск. Если проверки не прошли, машина возвращается обратным переносом по той же схеме, и это заранее отрепетированный сценарий, а не импровизация ночью.
Предсказуемость переезда складывается из трёх чисел, которые мы называем до начала работ: ожидаемое окно простоя, длительность передачи дисков и количество машин, переносимых за одно окно. Дальше это превращается в план по нодам с контрольными точками — на каждом шаге понятно, что уже переехало, что проверено и куда откатываться.
Live и offline миграция Proxmox: сравнение режимов переноса
Оба режима решают одну задачу — перенести работающую виртуальную машину на другую ноду, но по-разному обходятся с её состоянием. При live-переносе память копируется итеративно: сначала весь объём, затем только изменённые страницы, а в конце машина на короткое время останавливается для финальной синхронизации и стартует уже на новом месте. Offline-перенос работает проще: машина гасится, диск и конфигурация переносятся как файлы, после чего она включается на новой ноде.
Выбор режима определяется не удобством, а типом хранилища и допустимым временем недоступности сервиса. Если диски лежат на разделяемом сетевом хранилище, доступном обеим нодам, переносить нужно только состояние памяти. С локальными дисками к состоянию добавляются блоки самого диска, и тогда режим упирается в нагрузку записи: пока идёт догон, машина продолжает писать, и при интенсивном вводе-выводе перенос не сходится — приходится останавливать её и переходить к offline-сценарию.
| Вариант | Когда подходит | Ограничения режима |
|---|---|---|
| Live, общее хранилище | Диски на разделяемом сетевом хранилище, обе ноды его видят | Простой только на финальной синхронизации памяти; при высокой нагрузке запись опережает догон, и перенос не завершается |
| Live, локальные диски | Нужно сохранить сервис, диски физически на ноде | Копируется весь объём диска вместе со свободным местом; активная запись переводит перенос в режим с остановкой; проброс физических устройств переносится не всегда |
| Offline | Нагруженные записью и ресурсоёмкие машины, окно обслуживания согласовано | Машина недоступна весь перенос; переносятся диск и конфигурация целиком, время зависит от объёма данных |
| Экспорт и импорт | Перенос между несвязанными кластерами или разными ветками платформы | Ручные шаги на обеих сторонах, простой до полного переноса и проверки запуска |
На практике границы между режимами размываются: часть ограничений снимается подготовкой — переносом дисков на разделяемое хранилище заранее, настройкой маршрутов и проверкой доступности хранилища с целевой ноды. Это разбираем на этапе планирования, до самого переключения.
Этапы внедрения: от инвентаризации до передачи в эксплуатацию
Порядок работ одинаков и для переноса на ходу, и для переноса с короткой остановкой машины — различаются только состав окна работ и готовность сервиса к паузе. Ниже последовательность, по которой мы ведём проект в Proxmox: каждый этап закрывается проверяемым результатом, а не отчётом о выполнении.
-
Аудит кластера. Снимаем инвентарь: машины, привязка к хранилищам, состояние кворума, сетевые мосты, права, гостевые дополнения. Отдельно отмечаем зависимости, из-за которых перенос без остановки невозможен.
-
План переноса. Схема целевых узлов, тип переноса для каждой машины, партии и очерёдность, точки возврата. Согласуем окно работ — в него попадает только то, что действительно требует паузы.
-
Настройка. Общее хранилище или репликация между узлами, сеть и адресация, ограничения по нагрузке, резервные копии перед партией. Узлы проходят штатные проверки состояния.
-
Тестовый прогон. Второстепенная группа машин: замеряем время переключения, целостность данных, доступность сервисов, работу отката. По итогам правим состав партий и границы окна.
-
Работа в окне. Переносим партиями, следим за загрузкой узлов и хранилищ, критичные сервисы идут первыми. Инженер на связи отвечает за переключение и откат.
-
Приёмка и передача. Проверка сервисов по списку, сверка данных и журналов, фиксация результата с ответственными за системы. Отдаём регламент переноса, схему кластера и инструкции дежурной смене.
Что остаётся у вас: карта кластера, конфигурации, регламенты
После переноса у вас остаётся не отчёт о работах, а рабочий комплект, по которому кластер можно обслуживать и развивать без нашего участия. Все артефакты лежат в вашем репозитории и читаются штатными средствами Proxmox и обычным текстовым редактором.
- Карта размещения машин — таблица «машина → узел → хранилище» с текущим потреблением и свободным резервом на каждом узле. По ней сразу видно, куда можно добавить нагрузку, а где следующий перенос упрётся в лимит.
- Конфигурации узлов — сетевые мосты, правила фильтрации трафика, параметры хранилищ и задания резервного копирования, выгруженные в виде, пригодном для сравнения и восстановления.
- Регламент переключения — пошаговый порядок живого и холодного переноса: что проверяем до начала, какие команды выполняем, в какой момент переводим нагрузку и как фиксируем результат.
- План отката — заранее заданные точки возврата (снимок, копия конфигурации, старый узел в резерве), условия запуска отката и тот, кто принимает это решение.
- Документация и журнал изменений — схема сети и хранилищ, роли узлов, история правок конфигурации. Новый инженер входит в контур за часы, а не за недели.
- Проверочные сценарии — короткий набор проверок после каждого переноса: доступность сервиса, отклик, состояние репликации, целостность резервных копий.
Комплект живёт вместе с кластером: мы обновляем его по ходу работ, чтобы при следующем расширении или плановом переезде вы опирались на свои документы, а не восстанавливали картину по памяти.
Кейс: кластер из нескольких нод перевели без длительного простоя
Кластер на Proxmox из шести нод обслуживал продуктовый и тестовый контуры. Диски машин лежали локально на нодах, поэтому перенос без остановки был невозможен в принципе: каждую машину гасили, ждали освобождения блокировок, поднимали на целевой ноде и вручную проверяли доступность сервисов. Одно плановое обслуживание — 9 ручных операций на машину и окно в 30–40 минут, которые всегда ставили ночью.
Сначала разметили парк: что требует живой памяти и минимального простоя, что переносится пакетно, где локальный диск принципиален. Под машины первого типа подвели общее хранилище с репликацией на вторую ноду — у каждой был актуальный образ до начала переноса, поэтому состояние переносится без перезапуска. Для крупных машин с локальными дисками оставили управляемый offline-перенос с предварительной конвертацией и проверкой готовности через агента внутри гостевой системы.
После изменений простой машин на общем хранилище сократился до 1–2 секунд — сетевое соединение переезжает вместе с адресом, клиенты видят разве что короткий обрыв. Пакетный перенос крупной машины занимает 6–8 минут вместо 40 и запускается одной командой вместо девяти действий руками. Отдельно ушёл класс отказов: рассинхрон диска между нодами и зависшие блокировки при аварийном завершении переноса больше не всплывают.
Работы перестали привязываться к ночным окнам — обслуживание идёт в рабочие часы, а откат на исходную ноду остаётся доступным до подтверждения готовности сервиса на целевой.
Чем отличается live-перенос от offline и когда нужен каждый режим?
Разница не в скорости, а в том, что происходит с работающей машиной. В live-режиме память копируется циклами, пока гость продолжает обслуживать запросы, и останавливается виртуальная машина только на финальном переключении. В offline-режиме машину гасят, диск переносится целиком, и простой равен времени копирования.
Выбор режима задаёт тип диска. Если том лежит на общем хранилище, целевая нода видит его сразу, и переключение сводится к передаче состояния памяти. Локальные тома приходится копировать по сети: live-перенос крупного диска идёт часами и завершается лишь тогда, когда скорость записи гостя падает.
В Proxmox VE обе операции штатные, поэтому решают допустимое окно и состояние машины. Сервисам без собственного состояния хватает offline-переключения в техническое окно, а СУБД требуют согласованного порядка остановки — незаписанный кэш в памяти при жёстком гашении теряется.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Live (online) | Пауза недопустима, диск на общем хранилище | Нужны совместимые процессоры и запас ресурсов на целевой ноде; при активной записи перенос затягивается |
| Offline (stop) | Есть согласованное окно, тома локальные или крупные | Простой равен времени копирования; нужен порядок остановки сервисов |
Практический критерий: есть общее хранилище и пауза недопустима — live; тома локальные или окно согласовано — offline. Перед переключением проверяем кворум кластера, совместимость процессорных инструкций нод и запас ресурсов на целевой стороне — это и делает перенос плановой операцией с предсказуемым окном.
Частые технические сомнения: совместимость, окна работ, откат
Инженерные сомнения перед миграцией обычно сводятся к четырём вопросам: перенесётся ли конфигурация гостевой системы без ручной правки, сколько займёт окно работ, что делать при сбое и как перенос отразится на соседних виртуальных машинах. Ниже — короткие ответы на то, что чаще всего поднимают до старта.
Конфигурация гостевой системы отличается от целевой ноды — перенос возможен?
Да, если различия не касаются архитектуры процессора и поддерживаемого набора инструкций. Тип дискового контроллера, модель сетевого адаптера и привязку к мостам мы сверяем заранее и приводим к общему знаменателю на тестовом стенде, а не в момент переключения. Если целевая нода уступает по возможностям, часть параметров выносится в отдельный профиль конфигурации, чтобы гостевая система стартовала без правок внутри.
Сколько нужно окно работ и можно ли обойтись без простоя?
Живой перенос держит службу доступной: страницы памяти передаются на целевую ноду, а финальное переключение занимает доли секунды и укладывается в паузу, незаметную для пользователей. Холодный перенос требует остановки гостевой системы, зато снимает ограничения по нагрузке и объёму дисков. Окно планируем так, чтобы переносить группы машин последовательно и не выводить из строя связанные сервисы одновременно.
Что происходит при сбое и каков порядок отката?
До переключения исходная машина остаётся рабочей копией, поэтому откат — это возврат управления к ней, а не восстановление из резервной копии. Конфигурацию и снимки состояния мы сохраняем перед переносом, а после переключения проверяем доступность служб и целостность данных на целевой ноде. Если проверки не проходят, возврат занимает минуты: гостевая система поднимается на исходной ноде в прежнем виде.
Как перенос нагружает соседние ноды?
Во время живого переноса целевая нода получает дополнительный поток записи на диск и трафик по сети, исходная — нагрузку на канал передачи. Поэтому перенос планируется вне пиков и по одной-двум машинам за раз, а не пакетом. Перед стартом мы смотрим запас по дисковому вводу-выводу и памяти на обеих нодах и разносим волны миграции так, чтобы запас оставался.
Обсудим вашу задачу: подберём режим и вернёмся с планом
Чтобы оценка работ опиралась на факты, а не на предположения, нужен срез текущего контура: число узлов в кластере Proxmox, задействованные типы хранилищ, схема сети и то, какие сервисы критичны к остановке. Этого уже достаточно, чтобы разделить парк машин на переносимые живьём и те, что придётся гасить в согласованное окно.
По готовности описания мы возвращаемся с рабочим комплектом, а не с общими словами:
- план переноса по волнам — от низкорисковых машин к боевым, с окнами и порядком действий;
- карту виртуальных машин с режимом для каждой: живой перенос, перенос с остановкой или пересборка;
- состав команды на период работ и зоны ответственности — кто ведёт хранилища, кто сеть, кто принимает сервисы после переезда;
- перечень проверок до и после: доступность, целостность данных, отклик приложений, поведение под нагрузкой;
- схему отката и точки возврата на случай, если машина не поднимается на новом узле;
- регламент связи и режим отчётности на время миграции.
Если часть данных ещё не собрана — это не повод откладывать: обсудим задачу в том объёме, который есть, недостающее уточним по ходу. Опишите контур и допустимые простой — дальше мы вернёмся с оценкой и планом переноса.
