vMotion - це назва процесу динамічної міграції. Тобто переїзду віртуаль ної машини з одного сервера на інший без перерви в роботі. Жива міграція стане в нагоді вам:
Q коли необхідний плановий простий сервера. ВМ з вимагає виключе-
ня сервера можна прибрати на інші сервери і спокійно вимкнути його;
Q для балансування навантаження. З завантаженого сервера можна мігрувати віртуальні машини на більш вільні сервери.
Як тільки ми запускаємо міграцію, vCenter перевіряє виконання умов для віртуальної машини і серверів, між якими вона мігрує. Про умови далі.
Отже, основний обсяг пам'яті передається на інший ESX (i) через інтерфейс VMkernel, який ми задіємо під vMotion.
Як тільки вся пам'ять передалася - ВМ блокується повністю, і на другий ESX (i) передаються змінені сторінки пам'яті. Так як їх обсяг буде невеликий - час, протягом якого ВМ повністю блокується, також невелика. Досить невелика. А якщо обсяг зміненої пам'яті буде більше якогось порогового значення, значить, ESX (i) просто повторить ітерацію. Завдяки цьому область пам'яті, для передачі якій ВМ повністю заморозити, обов'язково буде дуже невеликою, нехай і через кілька ітерацій.
Якщо на якомусь етапі йде збій - то ВМ просто не вбивається на вихідному сервері і нікуди не їде, але падіння ВМ через невдалий vMotion не відбувається.
Для того щоб якусь ВМ можна було мігрувати без простою між двома серверами, повинні бути виконані деякі умови для цієї віртуальної машини і цих серверів.
Основна умова vMotion, що накладається на сервери, - процесори серверів повинні бути сумісні з точки зору vMotion. Справа в тому, що процесор - єдина підсистема сервера, яку віртуальні машини (гостьові ОС) бачать такою, яка вона є фізично. Не має значення, якщо у процесорів цих серверів виявляться різні тактові частоти, розмір кеш-пам'яті, кіль під ядер. А має значення набір підтримуваних інструкцій, таких як SSE 3, SSE 4.1, NX / XD і ін. Якщо на двох різних серверах різні процесори, а додаток використовує якусь із інструкцій, що була доступна до, але не доступна після переїзду, - то додаток впаде.
Щоб не допустити цього, vCenter не дозволить почати vMotion між серверами з несумісними процесорами. До речі, не забудьте, що частина функцій процесора управляється BIOS, так що і сервери з ідентичними процесорами можуть бути непридатні для гарячої міграції між ними ВМ, якщо настройки BIOS відрізняються. Іноді найпростіше скинути їх до стандартних значень.
В ідеалі процесори у вас сумісні для vMotion (подробиці доступні в базі знань VMware). Якщо немає, але жива міграція дуже потрібна, вам можуть допомогти наступні варіанти:
Q редагування так званої CPUID Mask (властивості ВМ. Options
CPUID Mask). Суть в тому, що для конкретної ВМ ми можемо «заховати»
ті процесорні інструкції, що заважають міграції. докладні інструк-
Q в принципі, відключення самої перевірки на однаковість процесорів, яку робить vCenter. Дія може не підтримуватися, але працює. Звичайно, дане рішення має сенс використовувати, лише якщо ви впевнені, що додатки в ваших ВМ НЕ задіють ті інструкції, якими відрізняються процесори серверів. Для відключення перевірки необхідно вставити рядки
в файл% AllUsersProfile% \ Application Data \ VMware \ VMware VirtualCenter \ vpxd.cfg і перезапустити службу vCenter;
Q Enhanced vMotion Compatibility, EVC. Що це таке, можна прочитати в на-
чільного розділах книги, як це включається - в розділі про DRS. Однак EVC включається і для кластера, в якому DRS не включений.
Повернемося до умов, які накладаються на ВМ і сервери через vMotion.
Всі ресурси, які задіє ВМ, повинні бути доступні на обох серверах. це:
Q зрозуміло, файли самої ВМ. vmx, vmdk та інші (за винятком файлу
підкачки vswp). Якщо резюмувати - ВМ повинна бути розташована на загальному сховищі. Якого саме типу - FC, iSCSI або NFS, не важливо. RDM також підтримується, але LUN, підключений як RDM, має бути видно обом серверів;
Q для віртуальних SCSI-контролерів настройка SCSI Bus Sharing НЕ
Q до ВМ можуть бути підключені образи CD-ROM і Floppy. Ці файли також повинні бути доступні з обох серверів;
Q до ВМ не повинен бути підключений CD-ROM сервера, тобто настройка
«Host Device» у властивостях віртуального CD-ROM. Ті ж умови вірні для FDD;
Q до ВМ не повинні бути підключені фізичні COM і LPT порти сервера;
Q у ВМ не повинно бути налаштоване CPU Affinity - вказівка конкретних ядер, на яких повинна працювати ця ВМ;
Q групи портів, до яких підключена ВМ, повинні існувати на обох серверах. Перевіряється тільки збіг імен, з точністю до регістру;
Q ВМ не повинна бути підключена до віртуального комутатора без прищепити занних фізичних мережевих контролерів. Однак перевірку на це можна відключити. Для цього вставте рядки
в файл% AllUsersProfile% \ Application Data \ VMware \ VMware VirtualCenter \ vpxd.cfg і перезапустіть службу vCenter;
Q в процесі vMotion між серверами передається вміст оперативної
пам'яті ВМ. Це вміст передається між інтерфейсами VMkernel, так що ми повинні створити ці інтерфейси. Зверніть увагу, що будь-який інтерфейс VMkernel може одночасно використовуватися ще і для NFS, iSCSI, Fault Tolerance, і для керуючого трафіку (останнє в разі ESXi). Однак для vMotion рекомендується виділити окремий гігабітний інтерфейс і, як наслідок, окремий інтерфейс VMkernel. У властивостях віртуального мережевого контролера VMkernel, який ви плануєте задіяти під vMotion, необхідно поставити прапорець «Use this port group for vMotion».
Зверніть вніманіе.vCenter перевіряє тільки факт наявності інтерфейсів VMkernel з прапорцем «Use this port group for vMotion» у властивостях, але не наявність зв'язку між цими інтерфейсами різних серверів. Щоб переконатися, що в конфігурації мережі немає помилок, на одному з серверів виконайте команду vmkping
Для перевірки виконання більшої частини умов зі списку вище добре підійде закладка Maps для віртуальної машини (рис. 6.57).
Зверніть увагу на малюнок - на ньому показана схема віртуальної інфра
Q це група портів «External_VM_Network» - вона є на одному сервері, але на сервері esxi2.vm4.ru її немає. Рішення - створити групу портів з тим же ім'ям на сервері esxi2. Або перестати її задіяти для даної ВМ;
Q дана ВМ задіє два сховища - «iSCSI_LUN_1_main» і «Local_esx1». Притому другий недоступно з сервера esxi2. Рішення - або зробити «Local_esx1» доступним з другого сервера (не завжди можливо), або перенести ВМ або її диск, розташовані на «Local_esx1», в інше сховище, доступне обом серверів;
Q «vMotion is disabled» на esxi2 означає, що на цьому сервері немає жодного інтерфейсу VMkernel, у властивостях якого дозволений трафік vMotion. Рішення - створити такий інтерфейс або поставити відповідний прапорець у властивостях існуючого інтерфейсу.
Для того щоб зрозуміти, які групи портів і які сховища доступні з обох серверів, допоможе Home. Maps. На рис. 6.58 ви бачите приклад такої карти.
Якщо всі проблеми вирішені, то карта vMotion повинна виглядати приблизно так, як показано на рис. 6.59.
Мал. 6.57. Maps для ВМ, яка не може мігрувати на гарячу
Мал. 6.58. Карта зв'язків сховищ з серверами
Мал. 6.59. Maps для ВМ, яка може мігрувати на гарячу
Зверніть увагу, що через Maps може не повідомляти про RDMдісках ВМ. Віртуальну машину з RDM мігрувати за допомогою vMotion можливо, однак підключений як RDM LUN повинен бути презентований обом серверів. Перевірити це через Maps можна. Втім, якщо до ВМ буде підключений RDM LUN, видимий лише поточного сервера, про це вам скажуть на першому кроці майстра vMotion.
Єдиним файлом ВМ, який не зобов'язаний лежати на загальному сховищі, є файл підкачки (VMkernel swap). Навіть якщо він розташований на приватному для першого сервера ресурсі, при міграції ВМ буде створений файл підкачки на диску, видимому для другого сервера, і вміст буде перенесено. Але на тому диску, де другий сервер має файли підкачки працюють на ньому ВМ, має бути достатньо вільного місця, інакше vMotion не відбудеться.
Запустити сам процес міграції можна, вибравши Migrate в контекстному меню ВМ, потім вибравши Change host на першому кроці майстра. Найчастіше простіше перетягнути ВМ на потрібний ESX (i) - тоді в майстра vMotion буде менше питань. Залишаться лише:
Q Select Resource Pool - поміщати чи ВМ в якийсь пул ресурсів, і якщо так, то в який;
Q vMotion Priority - резервувати чи ресурси під переміщувану ВМ на сервері призначення (вибрано за замовчуванням). Хіба ви не резервувати. Другий варіант дозволить мігрувати ВМ в умовах нестачі ресурсів, нехай навіть сама міграція займе більше часу.
За замовчуванням з кожного сервера можна одночасно мігрувати 4 (8 для 10 Гбіт мережі) ВМ. З урахуванням значно переробленого і поліпшеного компо-
нента, що відповідає за vMotion, навіть чотирьох одночасних міграцій, швидше за все, для вас буде достатньо.
Зверніть вніманіе.Імеется на увазі саме vMotion, для Storage vMotion і міграції виключених ВМ параметри за замовчуванням інші.