Як перенести віртуальні машини крок за кроком

La міграція віртуальних машин Це стало щоденним завданням у будь-якому мінімально сучасному ІТ-відділі. Йдеться вже не лише про переміщення машини з одного сервера на інший: сьогодні ми говоримо про міграцію з локальних кластерів VMware до Azure або Google Cloud, зміну платформ віртуалізації (наприклад, з VMware на KVM/VMmanager), або навіть реорганізувати ресурси в межах одного центру обробки даних для підвищення продуктивності чи стійкості, одночасно намагаючись мінімізувати час простою.

У цій статті ми досить детально розглянемо, Як упорядковано перенести віртуальні машиниУ цьому посібнику розглядаються варіанти використання, типи міграції (холодна та гаряча), специфічні процеси таких платформ, як Azure Migrate та Google Cloud Migrate на віртуальні машини, а також способи обробки змін гіпервізора в рішеннях, таких як VMmanager. Мета полягає в тому, щоб надати вам чіткий, практичний посібник для мінімізації ризиків та розуміння того, що відбувається «під капотом».

Навіщо мігрувати віртуальні машини в бізнес-середовищі

У корпоративному середовищі, Робоче навантаження постійно змінюєтьсяНесподівані сплески трафіку, нові програми, маркетингові кампанії, що викликають сплеск запитів, обслуговування обладнання тощо. Розгортання додаткових фізичних серверів щоразу, коли щось йде не так, не завжди можливо, тому міграція віртуальних машин стає ключовим інструментом для динамічного перерозподілу ресурсів.

Одна з найпоширеніших причин переміщення віртуальних машин – виконувати планові завдання з технічного обслуговування на фізичних хостах (оновлення прошивки, зміни обладнання, переміщення стійки тощо). Замість того, щоб брати на себе відповідальність за простої користувачів, віртуальні машини переміщуються на інші сервери під час періоду технічного обслуговування, а потім, за необхідності, повертаються на початковий хост.

Міграція віртуальних машин також важлива для забезпечення висока доступність у разі непередбачених збоївЯкщо фізичний сервер виходить з ладу або демонструє ознаки неминучого збою, можливість швидкого переміщення віртуальних машин на інший хост або хмару дозволяє користувачам ледь помітити інцидент, забезпечуючи безперебійну роботу програм.

Ще один критичний випадок – це відновлення після стихійних лихБагато архітектур реплікують віртуальні машини та їхній стан (диски та, в деяких випадках, пам'ять) між основним сайтом та сайтом аварійного відновлення. Коли оголошується аварійний стан, віртуальні машини переносяться до інфраструктури відновлення, що зменшує загальний час простою та втрату даних.

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

Типи міграції віртуальних машин: холодна та гаряча міграція

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

Холодна міграція

Холодна міграція передбачає переміщення віртуальна машина вимкнена або перебуває у стані призупинення на новий хост або нове сховище даних. Під час цього процесу пов'язані файли (конфігурація, диски, знімки) також можуть бути переміщені, переміщені з одного віртуального комутатора на інший або навіть з одного центру обробки даних до іншого.

Цей тип міграції можна виконати вручну або запланувати на певне вікно, але він має очевидний недолік: Є явне переривання обслуговування оскільки віртуальну машину потрібно зупинити. Крім того, часто потрібен певний рівень поглиблених знань про гіпервізор, мережу та сховище, щоб уникнути ускладнень із залежностями, шляхами або дозволами.

Гаряча міграція

Під час динамічної міграції віртуальна машина перекази, поки ще діютьТобто, він продовжує надавати послуги під час перемикання з одного хоста на інший. Такі інструменти, як vMotion у VMware або функції живої міграції інших гіпервізорів, забезпечують практично безперервну доступність під час цього процесу.

Система майже безперешкодно копіює пам'ять, стан процесора та іншу інформацію, необхідну для того, щоб віртуальна машина «прокинулася» на новому сервері. Наприклад, можна переміщувати запущену віртуальну машину між хостами, які використовують одне й те саме сховище, що є поширеною практикою в таких середовищах, як Кластери Citrix Hypervisor або KVM зі спільною кабіною.

Великою перевагою гарячої міграції є те, що Це звільняє адміністратора від багатьох ручних завдань. і забезпечує практично постійну доступність програми. Однак для забезпечення безпечної роботи та запобігання зниженню продуктивності потрібна добре продумана інфраструктура (низька затримка, спільне сховище, адекватна мережа).

Міграція локальної VMware або AVS до Azure за допомогою Azure Migrate

У гібридних хмарних сценаріях одним із найчастіших випадків є переміщення віртуальних машин з локального середовища VMware або з Рішення Azure VMware (AVS) до віртуальних машин Azure. Для цього Microsoft пропонує інструмент Azure Migrate: Міграція та модернізація, що дозволяє агентно-орієнтовані міграції та, все частіше, високоавтоматизовані безагентні міграції.

Процес міграції Azure включає все: від підготовки середовища до реплікації, тестування міграції та остаточного перенесення. Весь робочий процес детально пояснюється нижче, окреслюючи кроки та рішення, які необхідно приймати на кожному етапі.

Необхідні умови для міграції віртуальних машин VMware до Azure

Перш ніж повністю зануритися в процес, вам потрібно виконати низку основні передумови в Azure та у вашому середовищі VMware. Якщо ви їх не підготуєте, ви, ймовірно, зіткнетеся з помилками дозволів або проблемами з мережею посеред проекту.

Перше, що потрібно зробити, це мати активна підписка AzureЯкщо у вас його немає, ви можете створити безкоштовний обліковий запис, а потім увімкнути служби, необхідні для міграції. Без підписки ви, очевидно, не зможете нічого розгорнути.

На рівні проекту Microsoft рекомендує пройти принаймні початковий навчальний посібник для Підготовка Azure та VMware Для міграції (базова конфігурація мережі, дозволи тощо). Крім того, дуже корисно виконати посібник з оцінювання Azure Migrate, щоб проаналізувати віртуальні машини VMware перед їх міграцією, хоча цей крок не є обов’язковим.

У Azure Migrate вам потрібно буде використовувати існуючий проект або створити новий де оцінювання та міграції будуть централізовані. Також перевірте, чи обліковий запис Azure, який ви використовуватимете, має достатні дозволи для створення віртуальних машин і запису на керовані диски.

Щоб правильно отримати деталі щодо дозволів, доцільно переглянути конкретну документацію Вбудовані ролі Azure та необхідні дозволи через Azure Migrate (створення, виявлення, оцінювання та міграція проектів). Це запобіжить несподіванкам під час запуску автоматизованих завдань, які згодом не створюють ресурси.

Конфігурація пристрою Azure Migrate

Рішення для міграції Azure використовує легкий пристрій, розгорнутий на VMwareЦей пристрій відповідає за виявлення віртуальних машин, виконання оцінок та оркестрацію реплікації без агента. Якщо ви вже завершили етап оцінки, цей пристрій, як правило, вже налаштовано та зареєстровано в проєкті.

Якщо у вас його ще немає, ви можете розгорнути його двома основними способами, залежно від обмежень вашого середовища та того, чи працюєте ви зі стандартними публічними хмарами, чи середовищами, такими як Azure Government:

• Шаблон OVAВи завантажуєте шаблон і розгортаєте його як іншу віртуальну машину в vSphere. Це найпряміший метод, коли у вас немає жодних особливих обмежень.
• Скрипт PowerShellВи встановлюєте пристрій на віртуальну машину VMware або фізичний сервер за допомогою скрипта. Такий підхід зазвичай використовується, коли робота з OVA неможлива або незручна, або в певних регламентованих середовищах.

Після розгортання машини перевірте, чи вона Він може безперешкодно взаємодіяти з Azure Migrate: Оцінка сервера та Міграція сервераЗавершіть початкове налаштування та зареєструйте його у відповідному проекті Azure Migrate. Без цієї реєстрації портал не зможе пов’язати інформацію про виявлення та реплікацію з вашим середовищем.

Увімкнення та налаштування реплікації віртуальної машини

Після того, як пристрій запущено та виявлено, наступним кроком буде Увімкнути реплікацію віртуальних машин VMware до AzureAzure Migrate підтримує до 500 одночасних реплікацій, хоча на порталі можна вибрати лише 10 віртуальних машин на операцію, тому бажано групувати їх у пакети.

Щоб розпочати реплікацію, у вашому проекті Azure Migrate перейдіть до розділу виконання та виберіть опцію Розпочати міграціюУ майстрі виберіть «Сервери» або «Віртуальні машини» як тип корисного навантаження та «Віртуальна машина Azure» як місце призначення переміщення.

Тоді вам доведеться вирішувати. як вибрати робочі навантаження: вручну з усього виявленого інвентарю або починаючи з попередньої оцінки, що може спростити вибір, якщо у вас вже є визначені групи та залежності.

У методі виявлення виберіть пристрій, що відповідає вихідному середовищу (у цьому випадку пристрій для VMware vSphere) та в розділі «Режим міграції» виберіть опцію міграції без агента. Потім виберіть віртуальні машини, які потрібно реплікувати, та тип безпеки цільової віртуальної машини; Azure підтримує міграцію до віртуальних машин із Безпечний запуск і віртуальний TPM (Надійний запуск), що дуже рекомендується, коли завантаження сумісне.

У розділі налаштувань місця призначення потрібно вказати підписка, цільовий регіон та обліковий запис сховищаЦей крок також визначає віртуальну мережу та підмережу Azure, де будуть розташовані віртуальні машини після завершення міграції.

Ще один ключовий аспект полягає в тому, варіанти доступностіВи можете закріпити машини за певними зонами доступності, щоб розподілити вузли одного рівня програми по різних зонах, використовувати набори доступності (якщо вони існують у цільовій групі ресурсів) або не застосовувати жодних додаткових параметрів, якщо вони не потрібні. Вам також потрібно буде вибрати тип шифрування диска: ключі, керовані платформою, ключі, керовані клієнтом, або подвійне шифрування.

Щодо ліцензування, Azure дозволяє вам вказати, чи хочете ви використовувати Перевага гібридної Azure Для серверів Windows Server із програмою Software Assurance або активними ліцензіями. Якщо ви оберете «так», ви зможете зменшити витрати, використовуючи наявні ліцензії.

У вкладці «Обчислення» уважно перегляньте Ім'я віртуальної машини, розмір, тип диска операційної системи та параметри доступностіЯкщо ви використовуєте попередню оцінку, помічник запропонує рекомендовані розміри; в іншому випадку Azure вибере найближчий доступний розмір у вашій підписці. Ви завжди можете налаштувати його вручну відповідно до потреб вашого процесора та оперативної пам’яті.

Також потрібно буде вказати, який саме. диск з операційною системою (завантажувальний) у вихідній віртуальній машині, зоні доступності призначення або наборі доступності, і, якщо у вас вже є резервування потужності, пов’яжіть SKU віртуальної машини з резервуванням, щоб забезпечити доступність ресурсів під час перемикання.

На вкладці «Диски» ви можете вибрати, які диски з вашого комп’ютера потрібно реплікувати, а також який тип диска використовуватимете в Azure (Premium v2, Ultra Disk, Standard SSD, Standard HDD або Premium managed disks). Скористайтеся цією можливістю, щоб вирішити, де варто платити більше за продуктивність, а де буде достатньо простішого сховища.

Щоб завершити початкове налаштування, ви можете призначити мітки (теги) до віртуальних машин, дисків та мережевих карт, що дуже корисно пізніше для інвентаризації, витрат та автоматизації. Після перевірки всіх налаштувань підтвердьте конфігурацію та розпочніть початкову реплікацію.

Моніторинг та відстеження міграцій в Azure Migrate

Після початку, важливо моніторити хід реплікації та різні фази міграціїНа порталі, в розділі виконання проекту, ви можете переглянути міграції, згруповані за програмами або за робочими навантаженнями, залежно від того, що вам зручніше.

Операція концептуально поділена на три фази: Підготовка, тестування та завершенняКожен сервер також відображає статус: виконується, з помилкою, очікує дії або завершено. На етапі підготовки виконується початкова реплікація; на етапі тестування диференціальна реплікація вже налаштована, і можна запускати тестові міграції; на етапі завершення виконуються перезавантаження та очищення.

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

Якщо ви вирішите пропустити тестування, ви можете перейти безпосередньо до фази фіналізації, хоча це не рекомендується для критичних робочих навантажень. Після того, як диференціальна реплікація стабілізується, а тестування пройде успішно, ви можете запланувати остаточні міграції (перезавантаження) і, після перевірки всіх параметрів, виконати очищення ресурсів міграції.

Для кращого контролю Azure Migrate надає Командлет PowerShell під назвою Get-AzMigrateServerMigrationStatusЗ його допомогою ви можете побачити час реплікації, що залишився на кожному етапі, прогрес на кожен диск, швидкість завантаження та навіть рекомендації щодо пришвидшення міграції.

З Azure Cloud Shell просто відкрийте консоль, виберіть PowerShell і виконайте щось на кшталт:

Get-AzMigrateServerMigrationStatus -НазваПроєкту « » -НазваГрупиРесурсів « » -Назва_машини « »

Якщо додати параметр -ПрискоритиКоманда повертає робочі параметри пристрою та список пріоритетних запропонованих дій для скорочення часу, що залишився до міграції. Також можна виконати команду без MachineName, щоб побачити стан усіх віртуальних машин у проекті, або використовувати такі параметри, як -Здоров’я щоб отримати детальну інформацію про помилки, можливі причини та кроки їх вирішення.

Ви також можете фільтрувати за Назва пристрою переглядати глобальний стан усіх серверів, пов’язаних із певним пристроєм Azure Migrate, що особливо корисно у великих розгортаннях із кількома розподіленими пристроями.

Виконайте тестову міграцію в Azure

Коли активна диференціальна реплікація, наполегливо рекомендується запускати щонайменше одна тестова міграція на віртуальну машину перед внесенням остаточної зміни. Мета полягає в тому, щоб перевірити, чи машина правильно завантажується в Azure, чи працює програма, і чи немає несподіванок із залежностями, брандмауерами чи DNS.

Пробна міграція полягає у створенні Віртуальна машина Azure з реплікованих даних і зазвичай розміщують його у віртуальній тестовій мережі, ізольованій від виробничого трафіку. Вихідні машини, як локальні, так і в AVS, продовжують працювати та реплікувати дані протягом усього процесу, тому обслуговування не переривається.

Щоб запустити тест, у проекті Azure Migrate перейдіть до розділу міграцій, виберіть потрібний сервер і в розкривному меню тесту виберіть опцію Розпочати тестову міграціюДалі виберіть віртуальну мережу Azure, де буде створено тестову віртуальну машину, і призначте відповідні підмережі кожній реплікованій мережевій карті.

Ще одна перевага полягає в тому, що ви можете Скористайтеся цією можливістю, щоб оновити Windows Server Під час цього етапу тестування, якщо доступна опція оновлення, виберіть цільову версію операційної системи та застосуйте зміни, щоб під час тестування можна було перевірити, як програма поводиться з новою версією.

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

Остаточна міграція (перехід) віртуальних машин

Після перевірки задовільних результатів тестів, настав час остаточно перенести віртуальні машини з вихідного середовища до Azure. Це той момент, коли зазвичай планується період технічного обслуговування, оскільки він зазвичай передбачає вимкнення вихідних машин.

У розділі міграцій проекту виберіть цільовий сервер і в меню завершення виберіть опцію МігруватиМайстер запитає, чи бажаєте ви вимкнути вихідні віртуальні машини, щоб виконати заплановану міграцію без втрати даних; якщо ви оберете «Так», Azure Migrate вимкне машину, запустить реплікацію на вимогу з останніми змінами та гарантуватиме, що жодна інформація не буде втрачена.

Якщо з якоїсь причини ви не хочете вимикати вихідну віртуальну машину, ви можете вибрати "Ні", хоча це зазвичай пов'язано з більшим ризиком або вимагає більшої обережності під час синхронізації даних. Ви також можете повторно використати цей етап для Оновлення Windows Server під час міграції, вибравши відповідну цільову версію.

Якщо у вас є резервування потужності для VM SKU, який ви збираєтеся використовувати в регіоні призначення, рекомендується пов’язати їх тут, щоб переконатися, що місця буде достатньо. гарантовані ресурси Прямо в точці перемикання. Щойно ви все підтвердите, розпочнеться завдання міграції, і ви зможете відстежувати її перебіг у сповіщеннях Azure та в самому поданні міграцій.

Після завершення роботи машина стає доступною як Повністю керована віртуальна машина Azure На порталі ваш статус у Azure Migrate перейде на етап завершення, щоб ви могли виконати завершальні кроки.

Завершіть та завершіть міграцію в Azure

Оскільки віртуальна машина тепер працює в Azure, залишилося ще кілька кроків для успішно завершити міграцію і залиште середовище чистим і добре задокументованим. Перший крок – повідомити Azure Migrate про завершення міграції для цього комп’ютера, використовуючи параметр Завершити міграцію у меню завершення.

Після завершення міграції реплікація з джерела зупиняється, а стан відстеження машини в Azure Migrate очищується. Під час цього процесу Azure автоматично інсталює Агент віртуальної машини для Windows та Linux у нових машинах, що полегшує їх подальше управління (моніторинг, розширення тощо).

Тоді вам слід перевірити, чи Активація Windows на віртуальній машині Azure Його успішно завершено, і всі попередження мають бути виправлені. Це також гарний час для налаштування параметрів програми: імен хостів, рядків підключення до бази даних, внутрішніх шляхів, конфігурації веб-сервера, правил брандмауера та будь-яких інших параметрів, залежних від середовища.

На функціональному рівні важливо виконувати остаточне тестування застосунку та бізнес-валідаціяЩойно всі дадуть дозвіл, ви зможете назавжди перенаправляти трафік на новий екземпляр в Azure (зміни DNS, переналаштування балансувальника навантаження, оновлення кінцевих точок у клієнтських програмах тощо).

Тільки тоді слід видалити вихідні віртуальні машини Заздалегідь переконайтеся, що жодні служби чи залежності не залишаються невідповідними, використовуючи локальні рішення для інвентаризації та резервного копіювання. Не забудьте оновити всю внутрішню документацію, щоб відобразити нове розташування, IP-адреси та характеристики віртуальних машин, які зараз знаходяться в Azure.

Найкращі практики після міграції до Azure

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

Спочатку з'ясуйте, як ви збираєтеся впоратися з захист данихAzure Backup дозволяє централізовано створювати резервні копії віртуальних машин та гнучко керувати їх збереженням. Щоб захистити себе від регіональних катастроф, ви можете реплікувати свої віртуальні машини в інший регіон за допомогою Azure Site Recovery, додаючи додатковий рівень безперервності бізнесу.

Щодо продуктивності, перегляньте конфігурація кешу диска данихЗа замовчуванням багато дисків створюються з кешем, встановленим на "None" (Немає), але залежно від типу навантаження (бази даних, транзакційні програми, файлові сервери тощо) може бути доцільно змінити цей параметр для досягнення оптимальної продуктивності.

Безпека та постійний моніторинг є однаково важливими. Інтеграція віртуальних машин із інструменти моніторингу та управління витратами такі як Microsoft Cost Management для моніторингу споживання, а також використання централізованих рішень для ведення журналу, сповіщень та аналізу безпеки, що дозволяють швидко реагувати на аномалії.

Зрештою, корисно переглянути Структура впровадження хмарних технологій Azure, у якому описано повний процес впровадження хмарних технологій у Microsoft, від стратегії до управління та експлуатації, що може допомогти вам вписати ваш проект міграції віртуальних машин у ширшу ініціативу.

Міграція віртуальних машин до Google Cloud за допомогою функції «Міграція на віртуальні машини»

Якщо вашою метою є переміщення віртуальних машин з вашого поточного середовища (наприклад, центру обробки даних VMware) до Google CloudРідним рішенням є «Міграція на віртуальні машини», орієнтоване на міграції з підйомом та перенесенням з мінімальними автоматичними модифікаціями цільових віртуальних машин.

Цей інструмент інтегрується безпосередньо в консоль Google Cloud та використовує механізм безперервної реплікації даних Це реплікує диски вихідних віртуальних машин, залишаючись працездатними. Потім на цих реплікованих даних створюються тестові віртуальні машини, клони та, нарешті, виробничий екземпляр на Compute Engine.

Фази процесу міграції в Google Cloud

Міграція на віртуальні машини структурує процес міграції на кілька дуже чітких фаз: включення, реплікація, визначення мішені, тестовий клон, перерізання та термінаціяПослідовність дій досить логічна та дозволяє перевірити кожен крок, перш ніж рухатися далі.

На етапі адаптації ви обираєте вихідні віртуальні машини, які потрібно перенестиНаприклад, у середовищі vSphere консоль Google Cloud відображатиме весь інвентар центру обробки даних, і ви вибираєте лише ті віртуальні машини, які вас цікавлять для переміщення, додаючи їх до проекту міграції.

Потім починається фаза реплікації, під час якої дані з вихідних дисків віртуальної машини до Google Cloud без зупинки машини. Реплікація є безперервною та виконується у фоновому режимі, мінімізуючи вплив на продуктивність. Ця фаза складається з початкового кроку повної реплікації (початковий знімок диска) та наступних додаткових кроків, які виконуються через регулярні проміжки часу (за замовчуванням кожні дві години) за допомогою механізмів відстеження змінених блоків (CBT).

Після початку реплікації ви визначаєте Деталі цільової віртуальної машини в Compute EngineПроект, зона, тип екземпляра, пам'ять, мережі тощо. Ці параметри можна змінити будь-коли та використовуватимуться під час створення тестових клонів або кінцевої робочої віртуальної машини.

Наступний етап – тестовий клон. У будь-який час після завершення початкової реплікації ви можете Створення тестової віртуальної машини в Compute Engine На основі реплікованих даних та налаштувань цільового пристрою цей клон є статичним знімком вихідної машини на даний момент і служить для перевірки поведінки в Google Cloud без впливу на оригінальну віртуальну машину.

На етапі переходу, коли ви вже протестували все необхідне, перейдіть на віртуальні машини. Зупиніть вихідну віртуальну машину, виконайте останню реплікацію Для синхронізації остаточних змін система створює остаточний екземпляр Compute Engine, який замінить оригінальний сервер. Саме тоді настає період обслуговування, оскільки вихідна віртуальна машина вимикається, щоб запобігти розбіжності даних.

Нарешті, на завершальному етапі виконується наступне: очищення даних реплікації та тимчасових ресурсів пов’язані з міграцією. Важливо зазначити, що доки ви не видалите ці дані, ви продовжуватимете платити за сховище, яке вони займають, тому бажано завершити цей етап лише після перевірки того, що перенесена віртуальна машина функціонує належним чином у довгостроковій перспективі.

Адаптації операційної системи в Google Cloud

Щоб перенесені віртуальні машини коректно працювали в Google Cloud, простого копіювання дисків як є недостатньо; необхідно виконати низку кроків. адаптації операційної системи які автоматично застосовуються в кінці кожного кроку реплікації.

Ці адаптації включають зміни в конфігурація мережі, встановлення агента Compute Engine та активація послідовної консоліТочний тип налаштувань залежить від того, чи є машина Linux чи Windows, але мета завжди одна: запустити віртуальну машину та належним чином інтегрувати її в інфраструктуру Google Cloud без необхідності виконувати надмірні ручні налаштування.

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

Сценарії успіху та невдачі в Google Cloud

Під час фази змін може статися кілька сценаріїв, які необхідно чітко усвідомити з самого початку. Якщо Перемикання не вдається з якихось технічних причин (проблема з мережею, помилки конфігурації тощо), вихідна віртуальна машина буде зупинена, але остаточна реплікація все ще буде дійсною. У цьому випадку звичайна процедура полягає у з'ясуванні причини збою та повторній спробі внести зміни.

Якщо зміну завершено, але Нова віртуальна машина на Compute Engine працює неправильноАбо ж можна виконати відкат: зупинити та видалити проблемний екземпляр у хмарі, перезапустити вихідну віртуальну машину та перенаправити трафік назад до неї. Це не повністю автоматичний процес, тому він потребує ретельного планування, особливо щодо даних, записаних до несправного екземпляра, які не будуть репліковані назад до джерела.

Коли результат задовільний і віртуальна машина на Compute Engine працює належним чином, міграція вважається операційно завершеною. З цього моменту ви можете продовжувати. Оптимізуйте екземпляр, налаштуйте типи машин, дисків та мереж, та підготувати завершення міграції з фазою фіналізації та очищенням реплікованих даних.

Міграція віртуальних машин на російські платформи віртуалізації: приклад за допомогою VMmanager

У деяких країнах просувається політика, спрямована на заміна іноземного програмного забезпечення за допомогою національних рішень. Це призвело до ситуацій, коли деякі клієнти продовжують використовувати міжнародні продукти, але з очевидними ризиками: проблеми з поновленням ліцензій, заборона на оновлення, втрата офіційної підтримки та навіть можливі додаткові штрафи.

Щоб зменшити ці ризики, багато організацій розглядають перехід до локальні платформи віртуалізації, такі як VMmanagerЦе зріле рішення, розроблене як для невеликих інсталяцій, так і для великих інфраструктур, яке дозволяє консолідувати віртуальні машини з різних гіпервізорів без необхідності використання надзвичайно складних інструментів міграції.

В офіційній документації VMmanager цей процес пояснюється досить детально. Імпорт віртуальних машин з Hyper-V, VirtualBox, VMware, Xen та інших платформ на базі QEMU-KVMТиповий підхід поділяється на чотири кроки: підготовка віртуальної машини до міграції, підготовка середовища VMmanager, перенесення дисків машини та завантаження її в новий гіпервізор.

Під час підготовки віртуальної машини зазвичай необхідно Налаштуйте драйвери, видаліть певні інструменти з попереднього гіпервізора (наприклад, VMware Tools) та залишають конфігурацію мережі у стані, що дозволяє легке переналаштування в місці призначення. Потім VMmanager налаштовується для отримання цих віртуальних машин, диски (vmdk, vhdx, qcow2 тощо) копіюються до сховища платформи, і створюється карта віртуальної машини, що вказує на ці диски.

Якщо в будь-який момент процес ускладниться, адміністратори можуть покладайтеся на технічну підтримку VMmanager, чиї інженери зазвичай допомагають вирішувати несумісності та вдосконалювати деталі міграції, щоб зробити перенесення якомога плавнішим.

Тестові міграції за допомогою перетворення диска

У багатьох середовищах, особливо під час роботи зі сховищами даних QEMU-KVM або певні файлові системиВикористовуються тестові міграції, зосереджені на конвертації формату віртуального диска та створенні тимчасових віртуальних машин для перевірки процесу.

Загальний підхід передбачає конвертувати диски VMDK у рідний формат нового середовища та створювати віртуальні машини з цих перетворених дисків, розміщуючи їх у qtree або тому, призначеному для цієї мети. Ця методологія імітує фактичну міграцію, не впливаючи на оригінальну робочу віртуальну машину.

Ці тести дозволяють нам перевірити, чи Операційна система завантажується коректно після конвертації.Це включає перевірку наявності необхідних драйверів, налаштування мережі без проблем та необхідності додаткових змін (встановлення агентів, переналаштування служб тощо). Остаточна міграція розглядається лише тоді, коли пробна міграція вважається стабільною та без помилок.

Правильне планування та виконання цих тестів значно знижує ризик виникнення неприємних сюрпризів під час фактичного періоду обслуговування, незалежно від того, чи ви мігруєте до публічної хмари, чи змінюєте локальну платформу віртуалізації.

Міграція віртуальних машин, чи то між локальними хостами, чи то до публічних хмар, таких як Azure або Google Cloud, чи то на нові платформи, такі як VMmanager, – це процес, який вимагає планування, тестування та добре розуміння фаз реплікації, адаптації операційної системи та переходу на нові технологіїДотримуючись описаних практик, використовуючи нативні інструменти від кожного постачальника та завжди перевіряючи за допомогою тестових міграцій, ви можете змінити базову інфраструктуру, майже не помітивши змін з боку користувачів, і в процесі отримати стійкість, продуктивність та масштабованість.