Live Migration. Що потрібно для її використання? :: Журнал СА 102009

ОЛЕКСАНДР КОСІВЧЕНКО, технічний фахівець ЗАТ «Компьювей». Займається впровадженням серверних рішень на базі ПО Microsoft

Live Migration
Що потрібно для її використання?

Поговоримо про можливості і застосуванні нової технології, що увійшла до складу Microsoft Windows Server 2008 R2.

У Microsoft Windows Server 2008 R2 з'явилося багато нових можливостей. Серед них однією з найцікавіших є технологія, що дозволяє переміщати віртуальні машини між вузлами кластера з нульовим часом простою. У попередній моїй статті [1] було розглянуто використання стійких до відмов кластерів при віртуалізації серверів, а тут ми докладно розглянемо одну з корисних можливостей такого рішення - Live Migration, яка як раз і дозволяє таке переміщення здійснювати.

Live Migration: що за звір і з чим його їдять?

Напевно багатьом з читачів доводилося стикатися з проблемою, коли сервер необхідно на якийсь час вимкнути або перезавантажити: установка оновлень ОС, заміна апаратних компонентів. Доводилося сповіщати всіх користувачів, робити свою «чорну справу», а потім знову сповіщати всіх, що, мовляв, все в порядку і можна продовжувати роботу. Іноді ж доводилося залишатися на місці після закінчення робочого дня або ж приходити в вихідні дні. У деяких випадках, коли потрібна робота 24/7, це буде ще проблематичніше. Саме для таких випадків була придумана технологія Live Migration, що дозволяє переносити віртуальні машини з одного вузла кластера на інший непомітно для користувача.

Як це працює?

Сам процес міграції може бути ініційований трьома способами:

• вручну через оснащення Failover Clustering;
• c допомогою командлета PowerShell;
• c допомогою додаткового ПЗ, наприклад System Center Virtual Machine Manager.

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

Потім запускається процес синхронізації вмісту пам'яті. У процесі синхронізації віртуальна машина продовжує працювати.

На рис. 1 показана область пам'яті, відведена якоїсь віртуальної машини, розташованої на вузлі Node1. Після запуску процесу синхронізації весь вміст пам'яті передається сторінками по 4 КБ на цільовий хост, де попередньо було виділено область пам'яті такого ж обсягу, і вміст записується безпосередньо в пам'ять. Це перша ітерація. В процесі передачі вміст деяких сторінок було змінено (жовті осередки). Тому запускається друга ітерація, в процесі якої копіюються тільки змінені сторінки. Так як їх буде значно менше, ніж сумарний обсяг пам'яті, процес займе набагато менше часу, і після другої ітерації вміст пам'яті на обох хостах буде ідентично. Насправді ітерацій може бути більше - до 10. Якщо досягти повної ідентичності за 10 ітерацій не вдається, процес міграції переривається. Це одне зі слабких місць Live Migration: якщо віртуальна машина занадто активно працює з пам'яттю, існує теоретична можливість, що перенести її за допомогою Live Migration буде неможливо. В цьому випадку треба почекати спаду активності або використовувати інші методи переміщення, наприклад Quick Migration. Відразу ж після закінчення процесу синхронізації - нової віртуальної машині передається керування всіма необхідними дисками (як VHD, так і pass-through-дисками). Процес такого «перемикання» відбувається практично миттєво, TCP-з'єднання не встигають «відвалитися» по тайм-ауту, і користувачі не помічають, що щось змінилося.

Малюнок 1. Процес синхронізації вмісту пам'яті здійснюється ітераційно

Cluster Shared Volumes

У Windows Server 2008 R2 з'явилися так звані Cluster Shared Volumes CSV - якийсь аналог кластерної файлової системи. Cluster Shared Volume (CSV), по суті, являє собою кластерну файлову систему з єдиною точкою монтування для загальних дискових ресурсів на всіх вузлах кластера. Крім того, як відомо, з будь-яким одним загальним дисковим ресурсом кластера до недавнього часу одночасно міг працювати тільки один з вузлів. Тому, щоб мати можливість одночасної роботи декількох віртуальних машин на різних серверах, необхідно було для кожної віртуальної машини створювати окремий LUN на системі зберігання даних. Це могло породити деякі проблеми при великій кількості віртуальних машин. Справа в тому, що існують технічні обмеження на кількість створюваних LUN'ов в різних СГД. Використання Cluster Shared Volume дозволяє вирішити цю проблему: доступ до одного і того ж CSV може здійснюватися одночасно з усіх вузлів кластера, і тому кількість віртуальних машин обмежується лише обсягом дискового простору. Як же виглядає Cluster Shared Volume в системі? На системному розділі (наприклад, диск С :) всіх вузлів кластера створюється папка ClusterStorage, і все дискові пристрої монтуються в ній, як папки з ім'ям Volume1, Volume2 і т.д. Таким чином, доступ до файлів на одному і тому ж блоковому пристрої на всіх вузлах кластера буде здійснюватися по одному і тому ж шляху: C: \ ClusterStorage \ Volume1 \. На жаль, на даний момент Microsoft дозволяє використовувати CSV тільки для задач Hyper-V. Використання CSV з іншою метою є непідтримуваних рішенням, про що виводиться відповідне попередження при включенні CSV.

Основна вимога для використання CSV - системний розділ на всіх вузлах кластера повинен мати однакову букву диска, наприклад С :.

Вимоги для використання Live Migration

Існують вимоги, які необхідно дотримати для використання Live Migration.

• Підтримувані версії ОС:
  • Windows Server 2008 R2 64bit Enterprise Edition;
  • Windows Server 2008 R2 64bit Datacenter Edition;
  • Hyper-V Server 2008 R2.
• Всі хости, на яких планується використовувати Live Migration, повинні бути вузлами Microsoft Failover Cluster.
• Microsoft Failover Clustering підтримує до 16 вузлів в одному кластері.
• Слід створити між вузлами окрему незалежну мережу для трафіку Live Migration з пропускною спроможністю 1Gbps і вище.
• Всі вузли кластера повинні мати процесори одного виробника (AMD / Intel).
• Для використання Cluster Shared Volume всі вузли кластера повинні мати однакову букву завантажувального розділу (наприклад, С :).
• Всі хости повинні належати до однієї IP-підмережі.
• Всі хости повинні мати доступ до спільного сховища даних.

Крім обов'язкових вимог, рекомендується:

• Для зберігання файлів віртуальних машин використовувати Cluster Shared Volume.
• Конфігурація кластера повинна задовольняти Microsoft Support Policy for Windows Server 2008 Failover Clusters: http://support.microsoft.com/default.aspx?scid= kb; EN-US; 943984 .

Також обов'язково треба враховувати, що при використанні Live Migration будь-які два вузла кластера можуть бути задіяні тільки в одному процесі міграції, і при цьому переміщається тільки одна віртуальна машина. Не можна одночасно переміщати кілька машин з одного хоста або на один хост. Це означає, що в кластері з N вузлів може одночасно відбуватися N / 2 процесів міграції.

Основні сценарії застосування

Для чого ж можна застосовувати кластери, і зокрема Live Migration? Існує кілька загальних сценаріїв.

Сценарій 1. Технічне обслуговування серверів, установка оновлень

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

Завдяки використанню Live Migration віртуальні машини можуть бути переміщені на інший фізичний хост з нульовим часом простою, що абсолютно непомітно для користувача. Це означає, що будь-які роботи, навіть пов'язані з зупинкою сервера, можна проводити в розпал робочого дня, просто перемістивши попередньо все віртуальні машини на інший сервер і не телефонуючи користувачів з проханням «вийти з програми».

Сценарій 2. Динамічна ІТ-інфраструктура

Завдяки використанню технології Live Migration можна зробити ІТ-інфраструктуру повністю динамічної. Дуже сильно допоможуть в цьому інші програмні продукти - Microsoft System Center Virtual Machine Manager (VMM) і System Center Operations Manager (SCOM). Вони дозволяють стежити за завантаженістю всіх фізичних хостів в реальному часі і в залежності від завантаженості переміщати віртуальні машини з більш завантажених серверів на менш завантажені, розподіляючи таким чином навантаження рівномірно.

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

Від теорії - до практики

Тепер спробуємо «помацати» Live Migration на практиці: розгорнемо кластер на справжніх серверах, створимо високодоступних (High Available) віртуальну машину і спробуємо її мігрувати.

Короткий опис тестового середовища

Отже, що ж ми маємо? Для роботи з Live Migration розгорнута тестова середовище, що включає в себе:

• Віртуальну машину, на якій піднято контролер домену TEST.LOCAL і iSCSI Target від компанії StarWind (безкоштовна версія, підтримує віртуальні диски до 2 Тб).
• Два комп'ютери, які грають роль вузлів кластера. Кожен з них оснащений процесором фірми Intel, що задовольняє вимогам для роботи Hyper-V. Обидва комп'ютери забезпечені двома мережевими адаптерами, один з яких підключається в комутатор, інший - з'єднується з іншим комп'ютером перехресним патч-кордом.
• Звичайний комутатор Gigabit Ethernet.

Всього створено два iSCSI-пристрої. Одне - об'ємом 0,5 Гб - буде використовуватися в якості кворуму. Інше, 50 Гб - для зберігання даних. Схема тестової середовища наведена на рис.2.

Малюнок 2. Тестова середовище для розгортання кластера

Початкові налаштування вузлів кластера

Як вузлів кластера використовуються два комп'ютери - Node1 і Node2. У кожного з них є по два інтерфейси Gigabit Ethernet - LAN1 і LAN2 (див. Таблицю). Обидва вузла (Node1 і Node2) введені в домен TEST.LOCAL.

Таблиця. Налаштування мережевих інтерфейсів

Вузол / Інтерфейс

IP-адреса

Маска підмережі

Default Gateway

DNS

DC

10.0.0.1

255.0.0.0

-

127.0.0.1

Node1 / LAN1

10.0.0.2

255.0.0.0

10.0.0.1

10.0.0.1

Node1 / LAN2

172.16.0.1

255.255.0.0

-

-

Node2 / LAN1

10.0.0.3

255.0.0.0

10.0.0.1

10.0.0.1

Node2 / LAN2

172.16.0.2

255.255.0.0

-

-

Отже, перше, що нам необхідно зробити, - це підключити наші iSCSI LUN'и. Для цього на першому вузлі заходимо в Administrative Tools - iSCSI Initiator. Сервіс iSCSI за замовчуванням не запущений, тому система запитає, чи хочемо ми, щоб цей сервіс запустився і стартував автоматично. Погоджуємося. У вікні налаштувань ініціатора перше, що нам необхідно зробити, - це вказати, де знаходяться наші iSCSI-диски. Заходимо на закладку Discovery, вибираємо Discover Portal і вводимо адресу нашої системи зберігання. В даному випадку, як вже було написано, це сервер DC, тобто 10.0.0.1. Якщо все було вказано правильно, в списку порталів з'явиться наш сервер. Якщо були якісь проблеми (наприклад, порт закритий файерволом або адреса неправильний), видасть повідомлення про помилку. Тепер йдемо на закладку Targets і бачимо, що у нас з'явилися два таргета зі статусом Inactive. Потрібно по кожному з Таргет клікнути і натиснути Connect. У віконці, що з'явилося залишаємо все за замовчуванням (ім'я таргета має залишатися, і верхня галочка повинна бути включена - тоді наш диск автоматично підключиться при перезавантаженні ОС, див. Рис. 3).

Малюнок 3. Підключення iSCSI-дисків

Потім переходимо на закладку Volumes and Devices і вибираємо Auto Configure. Після цього можна закривати вікно властивостей ініціатора натисканням кнопки OK.

Наступним кроком нам потрібно зайти в консоль Server Manager в розділ Storage - Disk Management. Якщо все було зроблено правильно, то там з'являться два нових диски і обидва будуть в змозі Offline. Переводимо їх в Online. Потім обидва диска треба проинициализировать (Initialize) і створити розділи. Ми створимо на кожному диску по одному розділу об'ємом на весь диск і відформатуємо в системі NTFS (інші не підтримуються Microsoft Clustering Services). Надаємо маленькому диску букву Q: і мітку Quorum, а великим - S: і Storage відповідно. Природно, це робиться для зручності. Після успішного завершення все буде виглядати, як на рис. 4.

Малюнок 4. Вікно оснащення управління дисками після створення розділів

Потім треба встановити роль Hyper-V і Failover Clustering. В оснащенні Server Manager йдемо в розділ Roles, тиснемо Add Roles, в майстра вибираємо роль Hyper-V і встановлюємо її. Можна і навіть бажано поставити галочку навпроти мережевого адаптера, «наглядача» в комутатор, щоб не створювати потім віртуальну мережу руками. Буде потрібно перезавантаження сервера, смиренно погоджуємося і чекаємо. Після перезавантаження знову заходимо на сервер. Через якийсь час майстер установки ролей продовжить роботу. Треба почекати повідомлення про успішну установку Hyper-V. Закриваємо майстер, йдемо в Server Manager -> Features -> Add Features і вибираємо всього одну компоненту: Failover Clustering. Все, більше нам тут робити нічого. Заходимо на другий вузол і повторюємо все точно так же, за винятком роботи з дисками (ініціалізація-форматування і т.д.): на другому вузлі iSCSI-диски повинні залишитися в стані Offline. За сім настройка вузлів закінчується.

Створення відмов кластеру з двох вузлів

Після того як ми підключили загальні сховища до вузлів майбутнього кластера і встановили необхідні компоненти системи, можна переходити до власне налаштування кластера. З будь-якого з вузлів (це не принципово) або, як у нашому випадку, з DC запускаємо консоль Failover Cluster Manager (далі - FCM).

Перше, що нам необхідно зробити, - це перевірити, чи вийде у нас взагалі кластер з наших двох серверів. Для цього запускаємо перевірку: Validate a Configuration. Запуститься майстер перевірки конфігурації. Спочатку вибираємо наші обидва вузла. Далі нам буде запропоновано вибрати, чи запустити всі тести або тільки вибрані. Я і Microsoft настійно рекомендуємо зупинити вибір на Run All Tests, тому що тільки в цьому випадку рішення буде підтримуватися Microsoft. Потім можна йти пити чай: перевірка займе якийсь час, близько 10 хвилин. Якщо все ОК, ми побачимо щось на зразок рис. 5.

Малюнок 5. Перевірка конфігурації успішно завершена, можна збирати кластер

Якщо були якісь проблеми, можна подивитися звіт (View Report) у вигляді веб-сторінки, де буде детально пояснено, які тести провалилися і чому. Після виправлення всіх проблем треба запустити перевірку заново.

Отже, перевірка успішно завершена, і можна нарешті таки збирати кластер. У FCM вибираємо Create a Cluster. З'явиться майстер, схожий на попередній. Треба вибрати наші два вузла, а потім ввести DNS-ім'я і IP-адреса для нашого кластера. У нашому випадку - hvcluster з IP-адресою 10.0.0.10 (див. Рис. 6).

Малюнок 6. Задамо мережеве ім'я та IP-адреса для нашого кластера

Тепер кластер зібраний. Потрібно переконатися, що в якості кворуму використовується саме наш диск об'ємом 512 Мб. Заходимо FCM - імя_кластера - Storage. У Disk Witness in Quorum повинен стояти наш диск Q :, а другий диск (50 Гб) повинен знаходитися в Available Storage.

Використання Cluster Shared Volume

Тепер було б непогано зробити так званий Cluster Shared Volume. Включаємо CSV: йдемо FCM - імя_кластера і вибираємо Enable Cluster Shared Volumes. Виводиться попередження про те, про що я говорив вище - що CSV може використовуватися тільки для віртуальних машинах і ні для чого більше (див. Рис. 7).

Малюнок 7. При включенні Cluster Shared Volumes з'являється попередження

Ставимо галочку, що ми все прочитали і зрозуміли, тиснемо ОК. У дереві зліва з'являється розділ Cluster Shared Volumes. Заходимо туди, вибираємо Add Storage - і вибираємо наш диск, об'ємом 50 Гб. Після цього він пропадає з Available Storage, але з'являється в Cluster Shared Volumes і доступний на кожному вузлі як C: \ ClusterStorage \ Volume1.

Створення високодоступних віртуальної машини

Для початку потрібно створити саму віртуальну машину. Це можна зробити як безпосередньо з консолі FCM, так і з оснащення Hyper-V Manager. У Hyper-V Manager нам заходити все одно доведеться, так що зробимо звідти. Отже, на кожному з вузлів, припустимо, на першому, створюємо віртуальну машину. Обізвати її можна як завгодно - наприклад TestVM. Пам'ять і все інше - за смаком. Але є нюанси. Шлях для збереження файлів віртуальної машини не залишаємо за замовчуванням, а вказуємо наш кластерний диск (див. Рис. 8).

Малюнок 8. Файли віртуальної машини будемо зберігати на CSV

Розмір віртуального диска бажано, щоб уникнути конфузу вказати менше, ніж розмір нашого кластерного диска. Наприклад - 20 Гб. Далі все за смаком.

Відразу ж, якщо ми збираємося використовувати міграцію, а процесори у серверів одного виробника, але різною моделі (як в нашому випадку), необхідно включити Processor Compatibility Mode. Заходимо в властивості віртуальної машини (Settings) і в розділі Processor встановлюємо галочку Migrate to a physical computer with a different processor version (див. Рис. 9).

Малюнок 9. Включаємо Processor Compatibility Mode

Тепер нам треба зробити нашу віртуальну машину високодоступних. Термін «високодоступних (High Available)» віртуальна машина »означає, що віртуальна машина налаштована особливим чином для роботи в кластері, і тільки в цьому випадку підтримуються додаткові можливості, пов'язані з кластерами, такі, як міграція між вузлами.

Повертаємося в FCM - імя_кластера. У розділі Services and applications вібіраємо Configure Servise or Application. У майстра вказуємо, що це буде віртуальна машина (Virtual Machine внизу списку), і вибираємо нашу створену віртуальну машину (TestVM). Віртуальні машини можна створювати прямо з FCM, і тоді вони відразу ж автоматично робляться високодоступних, але тим не менше доведеться зайти в Hyper-V Manager для налаштувань процесора (див. Вище).

Використання Live Migration

Тепер на нашу готову і високодоступних віртуальну машину можна (і потрібно!) Встановити ОС. Яку ОС ставити - це ваш вибір. Після установки ОС можна перевірити Live Migration. Для цього можна, наприклад, запустити безперервний пінг нашої віртуальної машини в окремому вікні або качати на неї / с неї який-небудь великий файл (фільм в HD вагою в 25 Гб, наприклад).

Поки все це неподобство відбувається, спробуємо тихесенько перенести нашу багатостраждальну віртуальну машину на інший вузол. Кількома на ній правою кнопкою і вибираємо Live Migrate, а в випадаючому меню - той вузол, куди вона буде переїжджати. Процес міграції займає пару секунд - і ми бачимо, що Current Owner змінився. Якщо відкрити Hyper-V Manager, то можна переконатися, що наша віртуальна машина знаходиться вже на іншому вузлі. При цьому під час міграції ні пінг, ні закачування файлу, як ми бачимо, не перериваються. Ура!

***

Отже, в цій статті ми ознайомилися з новою «родзинкою» Microsoft Windows Server 2008 R2: Live Migration. Ми дізналися, що потрібно для її використання, як відбувається сам процес міграції, і здійснили все описане на практиці. Сподіваюся, що ви знайшли цю статтю корисною.

1. Косівченко А. Комплексне рішення: віртуалізація + відмовостійкий кластер. // Системний адміністратор, №9, 2009 г. - С. 16-19.