Shared-nothing live migration в Windows Server 2012.
Live migration, або динамічна міграція в Hyper-V дає можливість переносити працюючу віртуальну машину з одного хоста на інший без її зупинки. Спочатку динамічна міграція була можлива тільки в кластерної конфігурації, і тільки з використанням загального кластерного ресурсу (Cluster Shared Volumes, CSV).Але з виходом Windows Server 2012 ситуація змінилася.
Тепер загальне сховище (shared storage) більше не є необхідною умовою для роботи Live Migration, а переносити віртуальні машини можна не тільки між вузлами кластера . Для перенесення віртуальної машини з одного хоста Hyper-V на інший досить того, щоб вони були пов'язані мережею Ethernet.Подібний тип міграції отримав назву Shared-nothing live migration, або Динамічна міграція в режимі "нічого спільного".
Для можливості включення Shared-Nothing Live Migration необхідно дотримати наступні вимоги:
• Два або більше сервера Windows Server 2012 c встановленої роллю Hyper-V. Також можна використовувати безкоштовну редакцію Hyper-V Server 2012;
• Кожен сервер повинен мати доступ до власного сховища віртуальних машин.Як сховище можна використовувати локальні диски, мережі зберігання (SAN) або мережеві кулі SMB 3.0;
• Віртуальні машини, які планується мігрувати, не повинні використовувати підключені безпосередньо (pass-through) жорсткі диски;
• Для забезпечення сумісності сервери повинні мати процесори з однаковою архітектурою.В ідеалі краще використовувати ідентичні сервери від одного виробника;
• Сервери повинні бути членами одного домену Active Directory;
• Сервери повинні бути пов'язані як мінімум одним гігабітним мережевим з'єднанням. Виділена мережа для трафіку міграції рекомендується, але не обов'язкова;
• На мережеві адаптери, що використовуються для міграції, повинні бути включені Client for Microsoft Networks і File and Print Sharing for Microsoft Networks;
• Кожен Hyper-V хост повинен мати віртуальні комутатори з одним і тим же ім'ям.Це потрібно для того, щоб уникнути помилок і ручних операцій при виконанні міграції.
Якщо всі ці вимоги дотримані, то наступним кроком є включення міграції в налаштуваннях Hyper-V на всіх серверах, що беруть участь в міграції. Для цього відкриваємо Hyper-V Manager і йдемо в розділ «Hyper-V Settings».
Тут нас цікавить пункт «Live Migration», в якому зосереджені настройки динамічної міграції. В першу чергу її необхідно включити, зазначивши відповідний чекбокс. Потім вибираємо тип аутентифікації - Kerberos або CredSSP. При використанні CredSSP віддалене або автоматичне виконання міграції неможливо, т.к. необхідно залягання на сервері. Аутентифікація Kerberos позбавлена цього недоліку і більш безпечна, тому краще використовувати її.
Далі задаємо кількість одночасно переміщуються віртуальних машин. Віртуальні машини можна мігрувати паралельно, причому кількість одночасних міграцій обмежена тільки можливостями обладнання і вашим здоровим глуздом :).Щоб уникнути перевантаження, за замовчуванням стоїть обмеження на дві одночасні міграції.
Для приймаючої сторони можна вказати, з яких IP приймати вхідну міграцію. В якості фільтра можна вказати як окремі IP-адреси, так і цілі підмережі. За замовчуванням входить міграція приймається з будь-яких адрес.
Окремо на вкладці «Storage Migrations» можна вказати кількість одночасних міграцій сховища віртуальних машин. По дефолту тут також є обмеження в 2 міграції.
Закінчивши, тиснемо клавішу Apply, зберігаючи зроблені настройки. Нагадаю, що динамічну міграцію можливо включити тільки на серверах, які є членами одного домену.В іншому випадку Hyper-V не дасть зберегти настройки та видасть ось таку помилку.
Зберігши настройки , повертаємося в основне вікно і вибираємо віртуальну машину, яку належить смігріровать. Кількома на ній правою клавішею і вибираємо пункт «Move».
Запускається майстер перенесення.У стартовому вікні немає нічого цікавого, тому тиснемо Next.
Далі нам пропонується вибрати, що саме потрібно перенести - віртуальну машину цілком або тільки сховище віртуальних дисків. Наше завдання - повністю перенести ВМ на інший сервер, тому вибираємо перший варіант і йдемо далі.
В наступному вікні вибираємо сервер призначення, на який переїде наша віртуальна машина.
Тепер треба вибрати, як саме переносити машину, цілком або частинами. Можна помістити всі компоненти в одне місце, а можна вибрати для кожного з них своє розміщення - окремо віртуальні жорсткі диски, окремо снапшоти, окремо файли конфігурації і файл смарт-пейджинга.Третій варіант - смігріровать тільки саму ВМ, залишивши диски на місці, можливий тільки при наявності загального сховища (shared storage).
Далі вказуємо папку (або папки) на сервері призначення, в яку буде перенесена віртуальна машина і тиснемо Next.
Дивимося результуючу інформацію.Якщо все влаштовує, то тиснемо кнопку Finish, запускаючи процес міграції.
Зверніть увагу, що якщо імена віртуальних комутаторів на вихідному сервері і сервері призначення не збігаються, то процес не зможе бути запущений. Дану проблему легко виправити, вказавши до якого комутатора підключити віртуальну машину, але для цього буде потрібно втручання користувача.Якщо ви плануєте запускати міграцію в автоматичному режимі, наприклад за допомогою скриптів, то конфігурації повинні бути повністю ідентичні.
Тепер залишається спостерігати за процесом переносу. Його тривалість залежить від декількох факторів:
• Пропускна здатність каналу між серверами;
• Поточна навантаження на сервера;
• Обсяг оперативної пам'яті, виділений для віртуальної машини.
У мене міграція віртуальної машини c встановленої Windows Server 2012 зайняла трохи більше 8 хвилин.
При цьому для користувача перенесення проходить практично непомітно. В якості експерименту на час міграції я запустив утиліту ping для перевірки доступності машини.Як бачите, при міграції втрачено всього 6 пакетів. Хоча перевіряв я на ненавантаженому машинах і при великому навантаженні простий може бути більше.
На закінчення скажу , що Shared-nothing live migration не забезпечує відмовостійкість віртуальних машин і не є заміною кластерам.Проте, ця технологія дає можливість вільно переміщувати віртуальні машини між серверами. При цьому немає необхідності в дорогих системах зберігання даних. Загалом, рекомендується до використання однозначно