Чому vMotion зривається на живому навантаженні
Жива міграція віртуальних машин виглядає як одна команда, але під нею — кілька паралельних потоків: копіювання стану пам’яті, перенесення дисків, переналаштування мережі й перемикання на цільовий хост. Поки вони вкладаються у відведене вікно, переїзд проходить непомітно.
Збій перенесення віртуальної машини починається там, де хоча б один потік не встигає за навантаженням.
Перша причина — розсинхронізація даних. Пам’ять переноситься посторінково, і після старту синхронізації змінені сторінки копіюються повторно, а потім ще раз.
Якщо застосунок пише швидше, ніж канал встигає передавати, раунд не закривається: гіпервізор перезапускає синхронізацію до межі, після чого відкочує перенесення — машина залишається на вихідному хості, а вікно обслуговування вже зсунулося.
Друга — вузьке місце сховища. Різні томи, типи розділів, розмір блоку й кеш дають непередбачувану швидкість: під час Storage vMotion дані переливаються повільніше за план, а диски з прямим підключенням перенести не можна в принципі.
Перевантажений канал між майданчиками додає своє — трафік міграції ділить смугу з реплікацією та резервним копіюванням, і розрахунковий час множиться.
Третя — відсутність запасу за ресурсами, через що ризик перетворюється на простій сервісу під час переїзду: без резерву процесора й пам’яті на цільовому хості, перевіреної комутації та плану відкату будь-яка затримка розтягується на години. Розбираємо, як це закривається — від профілю навантаження до прогону міграції на копії.
Що дає перенесення без зупинки сервісу
Суть перенесення без зупинки сервісу в тому, що працююча машина переїжджає між хостами, не вимикаючись: пам’ять копіюється на цільовий хост, змінені сторінки наздоганяються повторними проходами, а перемикання займає частки секунди.
З’єднання, що потрапили в цю паузу, перепідключаються за таймаутом, а не рвуться помилкою. Клас задач «вимкнути, перенести, увімкнути» з плану обслуговування зникає.
Звідси головний ефект — скорочення вікна обслуговування.
Оновлення гіпервізора, заміна заліза, перебалансування навантаження й перенесення дисків між сховищами відбуваються на працюючих системах: вузол переводиться в режим обслуговування, машини роз’їжджаються по кластеру, роботи більше не потребують нічних простоїв.
Storage vMotion робить те саме з дисками — том змінюється під працюючою системою, без відключення й повторної реєстрації.
Знімається й клас відмов, пов’язаних із ручним перемиканням. Коли перенесення роблять руками — зупинка сервісу, відключення томів, повторне сканування, реєстрація на новому хості, увімкнення, правка записів балансувальника, — будь-яка помилка перетворює планове вікно на аварію.
Під час живої міграції помилитися ніде: якщо перенесення не сходиться, машина залишається на вихідному хості й продовжує обслуговувати запити. Фактична пауза — частки секунди замість десятків хвилин, а узгоджувати нічні роботи з бізнесом уже не потрібно.
Безперервність сервісу перевіряємо на пілотній групі: вимірюємо реальну недоступність, дивимося поведінку під навантаженням і лише потім переносимо решту.
Порівняння режимів: vMotion і Storage vMotion
Режим живої міграції вибирають за тим, що саме переїжджає: обчислювальний вузол, сховище чи обидва компоненти одразу.
У VMware vMotion працююча машина змінює хост, а її диски залишаються на спільному сховищі — простій вимірюється секундами, а тривалість залежить від зв’язності між вузлами, а не від обсягу диска.
Storage vMotion вирішує зворотну задачу: файли віртуальної машини переїжджають на інше сховище, а сама вона залишається на поточному хості. Час перенесення тут пропорційний обсягу даних і пропускній здатності між масивами.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| vMotion | Потрібно зняти навантаження з вузла, звільнити його під обслуговування або вирівняти баланс у кластері, сховище залишається попереднім | Потрібне спільне сховище, доступне обом хостам, і сумісні набори процесорних інструкцій у межах кластера |
| Storage vMotion | Перенесення сховища віртуальних машин: зміна масиву, виведення старого обладнання, перекладання дисків на інший рівень | Потрібні вільне місце на цільовому сховищі та запас пропускної здатності; великі знімки й диски в режимі прямої передачі даних подовжують операцію |
| Обидва режими послідовно | Переїзд на інший вузол та інше сховище одночасно, у тому числі на інший майданчик або в інший кластер | Найдовша операція: вимоги до мережі, сумісності та вільного місця додаються, потрібен запас за навантаженням |
Перед вибором режиму ми перевіряємо те, що найчастіше ламає перенесення: знімки дисків, режим їх підключення, типи сховищ на обох кінцях і сумісність процесорів. Це дозволяє заздалегідь відокремити машини, які переїдуть без зупинки, від тих, що доведеться переносити окремо.
Етапи перенесення: від аудиту до передачі
Порядок робіт фіксований: спочатку факти, потім перемикання. Етапи міграції інфраструктури будуються так, щоб кожен крок давав перевірюваний результат, а проміжний стан залишався відкатним — цим планове перенесення й відрізняється від аварійного.
- Аудит перед перенесенням. Інвентаризація машин, гостьових ОС, дисків, мереж і залежностей між сервісами. Окремо — сумісність із цільовим кластером і профіль навантаження на сховище в години пік: він задає допустиме вікно робіт.
- План перенесення віртуальних машин. Розмічаємо, що виїжджає живою міграцією vMotion без зупинки сервісу, а що потребує короткого простою — зміна формату диска, драйверів або контролера. Фіксуємо мережеві відповідності та порядок груп.
- Підготовка майданчика. Сховища, пули, політики розміщення, права, розклади реплікації, резервні копії. Перевіряємо, чи вистачає пропускної здатності каналів на перелив дисків, а не лише на саме перемикання.
- Пробний прогін. Переносимо дві-три копії з різних груп і знімаємо контрольні вимірювання: час перемикання, затримки введення-виведення, завантаження сховищ. За вимірами уточнюємо схему й довжину вікна.
- Основна хвиля. Групи йдуть у заданому порядку, після кожної — перевірка доступності сервісів, журналів і копій.
- Перевірка після міграції. Порівнюємо виміри з базовими, джерела тримаємо вимкненими, але готовими до запуску: це і є план відкату.
- Передача. Доступи, схеми, регламент обслуговування й інструкція щодо повернення для чергової зміни.
Документи та схеми, які залишаються у вас
Міграція закінчується не моментом перемикання на інший хост, а комплектом документації з інфраструктури, за якою її можна експлуатувати й розвивати без автора змін.
Нижче — те, що ми передаємо разом із доступами: список закриває і повсякденну роботу, і наступну міграцію, і розбір збою.
- Карта залежностей сервісів. Що з чим пов’язано: звернення до баз, брокерів повідомлень, файлових сховищ, зовнішніх систем. Збираємо з конфігурацій і мережевих журналів, а не з пам’яті адміністратора, — під час перенесення відразу видно, що не можна вимикати одночасно.
- Схема віртуальної інфраструктури. Кластери, хости, сховища, сегменти мережі, точки відмови, запас за процесорами, пам’яттю й дисками. За нею новий інженер розбирається в топології за годину, а не за тиждень розпитувань.
- Регламент перенесення. Порядок міграції за кроками: що перевіряємо до перемикання, які показники вважаємо ознакою успіху, за яких умов повертаємося на вихідний хост і скільки це займає.
- Регламент відновлення. Цільовий час і точка відновлення за кожним сервісом, черговість підйому, відповідальні, критерій закриття інциденту.
- Політики доступу. Ролі, службові облікові записи, права на рівні кластера, сховища й гостьових систем, правила ротації секретів і порядок видачі доступів новим співробітникам.
- Інвентаризація та резервне копіювання. Ресурси кожної машини, розклад копій, місця зберігання, дата останньої перевірки відновлення з копії.
Коли новий підрядник або ваш інженер відкриває ці файли, передача інфраструктури не перетворюється на листування із запитаннями.
Документи пишемо під ваш контур — із реальними іменами хостів, сховищ і груп доступу, а перед здаванням проходимо список разом із командою й правимо те, що залишилося неочевидним.
Кейс: переїзд кластера без зупинки сервісу
Кластер із кількох десятків віртуальних машин обслуговували вручну. Планові перенесення робили лише в нічні вікна: кожне — із зупинкою сервісу на сорок-шістдесят хвилин і черговим інженером біля монітора.
За місяць набиралося шість-вісім таких вікон, а помилка в порядку перенесення оберталася тим, що частина машин піднімалася з неправильними мережевими налаштуваннями і її доводилося лагодити вже вранці, на живих користувачах.
Що змінили
Обслуговування перевели на штатні засоби VMware: працюючі машини переносимо між хостами на ходу через vMotion, дискові томи мігруємо окремо від обчислень — переїзд перестав бути подією із зупинкою.
Порядок операцій закріпили регламентом: спочатку перевірка сумісності на рівні процесорних наборів і драйверів, потім перенесення обчислень, далі сховища, і лише після цього — виведення звільнених хостів на обслуговування.
Окремо налаштували правила розподілу ресурсів, щоб після перенесення навантаження не звалювалося на один хост.
Що стало
Нічні вікна як окремий процес зникли: рутинні роботи йдуть у робочі години, кількість планових простоїв скоротилася з шести-восьми на місяць до нуля, а час чергових, що звільнився, пішов на розвиток інфраструктури.
Час повернення до роботи після збою хоста скоротився з кількох годин ручного розбору до десятків хвилин — машини піднімаються на резервному вузлі за заздалегідь прописаним сценарієм.
Міграція кластера тепер займає один робочий день замість низки нічних змін, і сервіс при цьому жодного разу не вимикався.
Що робити, якщо vMotion не проходить на поточному сховищі
Найчастіше жива міграція відвалюється не через збій гіпервізора, а через відсутність спільної опорної точки між сторонами.
Перевіряють чотири речі: чи бачить одне сховище обидва кластери, чи збігаються типи томів, чи зведені можливості процесорів до спільного набору, чи немає відкритих снапшотів і проброшених пристроїв. Будь-яка з деталей блокує перенесення ще до старту, а помилка показує лише наслідок.
Якщо хости в одному кластері, а змінювати потрібно носій, а не обчислювальний вузол, це задача Storage vMotion: диски переїжджають між сховищами на ходу, без зупинки гостьової системи.
Обмеження одне — пропускна здатність каналу між масивами: за слабкої полиці перенесення йдуть у чергу й обриваються за таймаутом.
Коли спільної точки немає зовсім — різні кластери, майданчики, відсутність спільного тому — обходяться без перебудови інфраструктури.
Сховище-«міст», доступне обом сторонам, дозволяє переносити томи частинами: спочатку базу, знятим снапшотом, потім дельту, а ланцюжок збирають уже на приймачі. Кількість одночасних перенесень обмежують вручну, інакше канал реплікації забивається.
Якщо й це не проходить, працює гостьовий рівень: реплікація засобами самої системи або холодне перенесення — машину гасять, копіюють томи, піднімають на новому місці. Холодний шлях передбачуваний і в години пік виявляється швидшим, ніж боротьба з таймаутами.
На VMware і сумісних платформах ми спочатку знімаємо карту сумісності: кому які томи видно, які набори інструкцій збігаються, де вузьке місце каналу. Так перенесення вкладається у вікно обслуговування без перебудови сховища цілком.
Часті сумніви перед живою міграцією
Перед живою міграцією vMotion виринає один і той самий набір сумнівів: що буде із сервісом під час обриву перенесення, чи доведеться гасити машини, як поводитимуться бази під навантаженням.
Нижче — розбір заперечень, з якими до нас приходять найчастіше, включно з кластерами зі спільним сховищем і давно не оновлюваними системами.
Що буде, якщо перенесення обірветься на середині?
Машина залишається на вихідному хості: до завершення перенесення стан фіксується точкою повернення, і під час обриву зв’язку гостьові системи продовжують працювати там, де працювали. Повернення перевіряємо на тестовій групі до виведення решти.
Чи обов’язково гасити віртуальні машини?
Ні. Під час живої міграції пам’ять і стан процесора переносяться на ходу, а коротка недоступність можлива лише в момент перемикання. Її тривалість ми вимірюємо заздалегідь, а не обіцяємо на словах.
Як переносяться бази даних і кластери?
Вузли переносимо по одному, стежачи за кворумом і реплікацією: кластер має зберігати більшість голосів на кожному кроці. Бази з інтенсивним записом переводимо в щадний режим синхронізації й переносимо останніми.
Що робити із застарілими платформами?
Гостьові системи на старих гілках часто не підтримують живе перенесення — їх оновлюємо або перезбираємо заздалегідь. Це подовжує підготовку, але прибирає клас відмов, який інакше виринув би під час робіт.
Обговоримо ваш сценарій перенесення
Щоб замовити перенесення віртуальних машин, не потрібен формальний документ — достатньо того, що вже є в адміністраторів: вивантаження з інвентарю, схем мереж, листування щодо вікон обслуговування.
За цим набором ми збираємо план хвиль і говоримо, де перемикання пройде без зупинки сервісу, а де знадобиться вікно.
- Склад парку: кількість машин, операційні системи, обсяг і тип дисків, знімки, шаблони, машини зі спільними дисками кластера.
- Схема майданчиків: адресація, сегментація мереж, правила маршрутизації між контурами, доступність сховищ з обох сторін.
- Вимоги до доступності за кожним сервісом: допустима тривалість простою, години, коли перемикання заборонено, періоди пікового навантаження.
- Критичні сервіси та зв’язки між машинами: що піднімається першим, що тримає блокування й спільні томи, де порядок запуску жорсткий.
- Поточні налаштування кластера й зберігання: типи сховищ, політики розміщення, обмеження на кількість одночасних задач.
- Умови відкату: до якого моменту можна повернутися на вихідний майданчик і чи вистачить там ресурсів, поки триває міграція кластера.
Чогось зі списку може не бути — це нормально, частину даних знімаємо самі на обстеженні. Опишіть задачу й надішліть те, що є: повернемося з оцінкою, розбивкою на хвилі, точками перевірки після кожної та сценаріями відкату.
Так перенесення інфраструктури під ключ отримує вимірювані критерії приймання, а не обіцянку «зробимо акуратно». Обговоримо міграцію на конкретних цифрах вашого парку.
