Міграція 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, задіяні типи сховищ, схема мережі і те, які сервіси критичні до зупинки.
Цього вже достатньо, щоб розділити парк машин на переносні живцем і ті, що доведеться гасити в узгоджене вікно.
За готовності опису ми повертаємося з робочим комплектом, а не із загальними словами:
- план перенесення за хвилями — від низькоризикових машин до бойових, із вікнами та порядком дій;
- карту віртуальних машин із режимом для кожної: живе перенесення, перенесення із зупинкою або перескладання;
- склад команди на період робіт і зони відповідальності — хто веде сховища, хто мережу, хто приймає сервіси після переїзду;
- перелік перевірок до і після: доступність, цілісність даних, відгук застосунків, поведінка під навантаженням;
- схему відкату і точки повернення на випадок, якщо машина не піднімається на новому вузлі;
- регламент зв'язку і режим звітності на час міграції.
Якщо частину даних ще не зібрано — це не привід відкладати: обговоримо завдання в тому обсязі, який є, а недостатнє уточнимо по ходу. Опишіть контур і допустимий простій — далі ми повернемося з оцінкою і планом перенесення.
