vMotion - це назва процесу динамічної міграції. Тобто переїзду віртуальної машини з одного сервера на інший без перерви в роботі. Жива міграція стане в нагоді вам:

- коли необхідний плановий простий сервера. ВМ з вимагає виключення сервера можна прибрати на інші сервери і спокійно вимкнути його;

- для балансування навантаження. З завантаженого сервера можна мігрувати віртуальні машини на більш вільні сервери.

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

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

Отже, основний обсяг пам'яті передається на інший ESX (i) через інтерфейс VMkernel, який ми задіємо під vMotion.

Як тільки вся пам'ять передалася - ВМ блокується повністю, і на другий ESX (i) передаються змінені сторінки пам'яті. Так як їх обсяг буде невеликий - час, протягом якого ВМ повністю блокується, також невелика. Досить невелика. А якщо обсяг зміненої пам'яті буде більше якогось порогового значення, значить, ESX (i) просто повторить ітерацію. Завдяки цьому область пам'яті, для передачі якій ВМ повністю заморозити, обов'язково буде дуже невеликою, нехай і через кілька ітерацій.

На цьому етапі ми маємо два ідентичних процесу, дві ідентичні ВМ на обох ESX ^. Тепер ВМ на вихідному сервері побивається, по мережі йде оповіщення, що машина з цим MAC-адресою доступна вже на іншому порту фізичного комутатора. Усе.

Якщо на якомусь етапі йде збій - то ВМ просто не вбивається на вихідному сервері і нікуди не їде, але падіння ВМ через невдалий vMotion не відбувається.

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

Основна умова vMotion, що накладається на сервери, - процесори серверів повинні бути сумісні з точки зору vMotion. Справа в тому, що процесор-єдина підсистема сервера, яку віртуальні машини (гостьові ОС) бачать такою, яка вона є фізично. Не має значення, якщо у процесорів цих серверів виявляться різні тактові частоти, розмір кеш-пам'яті, кількість ядер. А має значення набір підтримуваних інструкцій, таких як SSE 3, SSE 4.1, NX / XD і ін. Якщо на двох різних серверах різні процесори, а додаток використовує якусь із інструкцій, що була доступна до, але не доступна після переїзду, - то додаток впаде.

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

В ідеалі процесори у вас сумісні для vMotion (подробиці доступні в базі знань VMware). Якщо немає, але жива міграція дуже потрібна, вам можуть допомогти наступні варіанти:

- редагування так званої CPUID Mask (властивості ВМ ^ Options ^ CPUID Mask). Суть в тому, що для конкретної ВМ ми можемо «заховати» ті процесорні інструкції, що заважають міграції. Докладні інструкції ви знайдете в базі знань VMware ( http://kb.vmware.com/kb/1993 );

- в принципі, відключення самої перевірки на однаковість процесорів, яку робить vCenter. Дія може не підтримуватися, але працює. Звичайно, дане рішення має сенс використовувати, лише якщо ви впевнені, що додатки в ваших ВМ НЕ задіють ті інструкції, якими відрізняються процесори серверів. Для відключення перевірки необхідно вставити рядки

<Migrate>

<Test>

<CpuCompatible> false </ CpuCompatible>

</ Test>

</ Migrate>

в файл% AllUsersProfile% \ Application Data \ VMware \ VMware VirtualCen-ter \ vpxd.cfg і перезапустити службу vCenter;

- Enhanced vMotion Compatibility, EVC. Що це таке, можна прочитати в початкових розділах книги, як це включається - в розділі про DRS. Однак EVC включається і для кластера, в якому DRS не включений.

Повернемося до умов, які накладаються на ВМ і сервери через vMotion.

Всі ресурси, які задіє ВМ, повинні бути доступні на обох серверах. це:

- зрозуміло, файли самої ВМ. vmx, vmdk та інші (за винятком файлу підкачки vswp). Якщо резюмувати - ВМ повинна бути розташована на загальному сховищі. Якого саме типу - FC, iSCSI або NFS, не важливо. RDM також підтримується, але LUN, підключений як RDM, має бути видно обом серверів;

- для віртуальних SCSI-контролерів настройка SCSI Bus Sharing не повинна бути виставлена ​​в значення, відмінне від None. Це означає, що віртуальні машини-вузли кластера Майкрософт не можуть бути мігрують-вани за допомогою vMotion;

- до ВМ можуть бути підключені образи CD-ROM і Floppy. Ці файли також повинні бути доступні з обох серверів;

- до ВМ не повинен бути підключений CD-ROM сервера, тобто настройка «Host Device» у властивостях віртуального CD-ROM. Ті ж умови вірні для FDD;

- до ВМ не повинні бути підключені фізичні COM і LPT порти сервера;

- у ВМ не повинно бути налаштоване CPU Affinity - вказівка ​​конкретних ядер, на яких повинна працювати ця ВМ;

- групи портів, до яких підключена ВМ, повинні існувати на обох серверах. Перевіряється тільки збіг імен, з точністю до регістру;

- ВМ не повинна бути підключена до віртуального комутатора без прив'язаних фізичних мережевих контролерів. Однак перевірку на це можна відключити. Для цього вставте рядки

<Migrate>

<Test>

<CompatibleNetworks>

<VMOnVirtualIntranet> false </ VMOnVirtualIntranet>

</ CompatibleNetworks>

</ Test>

</ Migrate>

в файл% AllUsersProfile% \ Application Data \ VMware \ VMware VirtualCen-ter \ vpxd.cfg і перезапустіть службу vCenter;

- в процесі vMotion між серверами передається вміст оперативної пам'яті ВМ. Це вміст передається між інтерфейсами VMkernel, так що ми повинні створити ці інтерфейси. Зверніть увагу, що будь-який інтерфейс VMkernel може одночасно використовуватися ще і для NFS, iSCSI, Fault Tolerance, і для керуючого трафіку (останнє в разі ESXi). Однак для vMotion рекомендується виділити окремий гігабітний інтерфейс і, як наслідок, окремий інтерфейс VMkernel. У властивостях віртуального мережевого контролера VMkernel, який ви плануєте задіяти під vMotion, необхідно поставити прапорець «Use this port group for vMotion».

Зверніть увагу. vCenter перевіряє тільки факт наявності інтерфейсів VMker-nel з прапорцем «Use this port group for vMotion» у властивостях, але не наявність зв'язку між цими інтерфейсами різних серверів. Щоб переконатися, що в конфігурації мережі немає помилок, на одному з серверів виконайте команду vmkping <IP vMotion-інтерфейсу VMkernel другого сервера>.

Для перевірки виконання більшої частини умов зі списку вище добре підійде закладка Maps для віртуальної машини (рис. 6.57).

Зверніть увагу на малюнок - на ньому показана схема віртуальної інфраструктури в контексті vMotion однієї ВМ. Зараз віртуальна машина «File_Server_ Win2008» працює на esx1.vm4.ru. Мною обведені ті об'єкти, на які варто звернути увагу, так як вони перешкоджають vMotion цієї ВМ на другий сервер:

- це група портів «External_VM_Network» - вона є на одному сервері, але на сервері esxi2.vm4.ru її немає. Рішення - створити групу портів з тим же ім'ям на сервері esxi2. Або перестати її задіяти для даної ВМ;

- дана ВМ задіє два сховища - «iSCSI_LUN_1_main» і «Lo-cal_esx1». Притому другий недоступно з сервера esxi2. Рішення - або зробити «Local_esx1» доступним з другого сервера (не завжди можливо), або перенести ВМ або її диск, розташовані на «Local_esx1», в інше сховище, доступне обом серверів;

- «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 буде менше питань. Залишаться лише:

- Select Resource Pool - поміщати чи ВМ в якийсь пул ресурсів, і якщо так, то в який;

- vMotion Priority - резервувати чи ресурси під переміщувану ВМ на сервері призначення (вибрано за замовчуванням). Хіба ви не резервувати. Другий варіант дозволить мігрувати ВМ в умовах нестачі ресурсів, нехай навіть сама міграція займе більше часу.

За замовчуванням з кожного сервера можна одночасно мігрувати 4 (8 для 10 Гбіт мережі) ВМ. З урахуванням значно переробленого і поліпшеного компо нента, що відповідає за vMotion, навіть чотирьох одночасних міграцій, швидше за все, для вас буде достатньо.

Зверніть увагу. Мається на увазі саме vMotion, для Storage vMotion і міграції виключених ВМ параметри за замовчуванням інші.

6.8. Кластер DRS. DPM

Жива міграція ВМ - це корисна штука. Вона дозволяє мігрувати ВМ між серверами для:

- балансування навантаження між ними;

- звільнення сервера, коли потрібно його перезавантажити. Це стане в нагоді при установці оновлень, апаратному обслуговуванні.

Однак при більш-менш великий інфраструктурі виконувати ці операції вручну для адміністратора стає важко. На допомогу в цьому йому може прийти VMware DRS.

Навіщо потрібен DRS:

- для балансування навантаження (по процесору і пам'яті) між серверами;

- для автоматичного vMotion віртуальних машин з сервера в режимі обслуговування (maintenance mode). Цим режимом адміністратор або VM-ware Update Manager позначає сервер, який треба звільнити від віртуальних машин перед операціями обслуговування.

Для вирішення цих завдань DRS вміє здійснювати лише дві речі:

- запускати vMotion для віртуальних машин і вибирати, звідки, куди і яку ВМ краще мігрувати;

- при включенні ВМ вибирати сервер, на якому вона включиться (це називається Initial Placement).

Для створення DRS-кластера необхідно створити об'єкт «Cluster» в ієрархії vCenter. У контекстному меню Datacenter виберіть Add new Cluster, вкажіть ім'я створюваного кластера і поставте прапорець DRS (не має значення, чи варто прапорець HA). Натисніть ОК.

Отже, кластер як об'єкт vCenter ви створили. Залишилося два кроки:

1. Налаштувати DRS-кластер.

2. Додати в нього сервери ESX (i).

Втім, включити DRS можна і для вже існуючого кластера.

Якщо для кластера активований DRS, то вам доступні групи налаштувань, показані на рис. 6.60.

По порядку.

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

Мал. 6.60. Налаштування кластера DRS

- Manual (ручний) - і вибір, де включити, і vMotion буде лише пропонуватися;

- Partially automated (напівавтомат) - вибір, де включити ВМ, DRS буде робити сам, а ось vMotion - лише пропонувати;

- Fully automated (повністю автоматичний) - і вибір, де включити, і vMotion DRS буде робити сам.

Зверніть увагу на бігунок Migration Threshold - його положення вказує агресивність роботи кластера DRS. Чим його положення ближче до Conservative, тим тільки більш важливі рекомендації видаватиме і виконувати DRS. Чим бігунок ближче до Aggressive, тим менш важливі рекомендації будуть видаватися.

Зверніть увагу. Якщо DRS працює в ручному (Manual) режимі, то непривілейованих користувачі (у яких є право включати ВМ, наприклад з роллю Virtual Machine User) не зможуть побачити вікно вибору сервера при включенні цієї ВМ (рис. 6.66), і ВМ подаватися не буде.

DRS створює рекомендацію для міграції з наступних причин:

- для балансування навантаження на процесори сервера, або reservation по процесору;

- для балансування навантаження на пам'ять сервера, або reservation по пам'яті;

- для задоволення налаштування reservation для пулів ресурсів;

- для задоволення правил affinity або anti-affinity (мова йде про однойменну налаштування кластера DRS, а не про налаштування CPU affinity у властивостях ВМ);

- для міграції ВМ з сервера, що переходить в режим maintenance або standby;

- для задоволення рекомендацій Distributed Power Management, якщо цей компонент використовується.

DRS відстежує лічильники Host CPU: Active (включаючи run і ready) і Host Memory: Active. DRS видає рекомендації за п'ятихвилинні інтервали, змінити це не можна. Посилання Run DRS на закладці DRS для кластера примусово змушує обрахувати рекомендації.

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

Мал. 6.61. Поточна інформація про статус DRS-кластера Найголовніше тут - це:

- Migration Threshold - настройка, яка вказує на рівень пріоритету, рекомендації з яким виконуються автоматично. Від цієї настройки залежить значення «Target host load standard deviation». Таким чином, дана настройка вказує на те, наскільки кластер може бути незбалансованим;

- Target host load standard deviation - стандартне відхилення навантаження, при досягненні якого потрібно балансування;

- Current host load standard deviation - стандартне відхилення поточної навантаження на сервери.

У розрахунку стандартного відхилення використовується розрахунок навантаження на кожен сервер за такою формулою:

ЕІТ (навантаження від ВМ на одному сервері) / (ресурси сервера)

Пріоритет міграції вираховується за формулою:

6 - ceil (Current host load standard deviation / 0.1 x sqгt (Кількість серверів в кластері))

де ceil (x) - найменше ціле, одна з х.

Втім, формула може змінюватися в наступних версіях vSphere.

Також високий пріоритет мають міграції, викликані правилами affinity і anti-affinity, про які пізніше. Нарешті, якщо сервер помістити в режим Maintenance, то DRS згенерує рекомендацію мігрувати з нього все ВМ, і у цих рекомендацій пріоритет буде максимальний.

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

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

Починаючи з версії 4.1, DRS враховує не тільки навантаження на процесори і пам'ять серверів, але і число віртуальних машин. Тепер не буде ситуацій, коли на одному з двох серверів кластера 20 маленьких віртуальних машин, а на другому -2 великі. Виходило дуже багато яєць в першому кошику.

Починаючи з версії 4.1, в кластері DRS може бути до 32 серверів і до 3000 віртуальних машин. На кожному сервері може бути до 320 віртуальних машин. Ці цифри не залежать від типу кластера (HA / DRS / обидва) і не залежать від числа серверів в кластері (як це було в попередніх версіях).

DRS Groups Manager - цей пункт налаштувань з'явився тільки у версії 4.1. Його суть в тому, що для DRS-кластера ми можемо позначити групи серверів і віртуальних машин, а потім створити правила співвідношення між ними. Правила виду «група віртуальних машин" test "не повинна працювати на серверах групи" new_servers "» або «група віртуальних машин" CPU Intensive "повинна працювати на серверах групи" Servers_with_new_CPU "» (рис. 6.62).

Ця можливість може бути цікава нам з таких міркувань:

- щоб однотипні віртуальні машини працювали на одних і тих же серверах. В такому випадку механізм transparent page sharing буде більш ефективно дедупліціровать оперативну пам'ять цих віртуальних машин;

Мал. 6.62. Групи серверів і віртуальних машин для кластера DRS

- щоб віртуальні машини з більш високими вимогами до продуктивності працювали на більш продуктивних серверах кластера (де більш нові процесори або більший обсяг пам'яті);

- если додаток в віртуальніх машинах ліцензується таким чином, что Ліцензування Залежить від числа серверів, на якіх может заробіті Віртуальна машина. Обмеживши число таких серверів, ми можемо здешевити ліцензування або гарантувати дотримання поточної ліцензії;

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

- щоб HA використовував для включення після збою деяких, наприклад тестових, віртуальних машин тільки деякі сервери ESX (i).

Rules - тут ми можемо створювати так звані правила affinity і antiaffinity, а також вказувати правила приналежності груп віртуальних машин групам серверів.

При створенні правила anti-affinity ми вказуємо кілька віртуальних машин, які DRS повинен розносити по різних серверах. Зверніть увагу: кожна ВМ однієї групи anti-affinity повинна розташовуватися на окремому сервері. Наприклад, таке правило має сенс для основного і резервного серверів DNS або контролерів домену. Таким чином, в одному правилі не зможе брати участь віртуальних машин більше, ніж в кластері серверів.

У правилі affinity ми вказуємо довільну кількість ВМ, які DRS повинен тримати на одному сервері. Наприклад, це буває виправдано для сервера додатків і сервера БД, з яким той працює. Якщо така пара буде працювати на одному сервері, трафік між ними не буде навантажувати фізичну мережу і не буде обмежений її пропускною спроможністю. Якщо якісь правила взаємовиключні, то у імені, створеного останнім, не можна поставити прапорець (тобто правило не можна активувати). З яким іншим правилом воно конфліктує, можна подивитися по кнопці Details (рис. 6.63).

Мал. 6.63. Подробиці правила для DRS

Якщо якесь правило в даний момент порушено, отримати інформацію про це можна по кнопці Faults на закладці DRS для кластера.

У версії 4.1 з'явилася можливість розділити віртуальні машини і сервери по групам і вказати правила їх зв'язки один з одним. Доступними параметрами (рис. 6.64):

- Must run on hosts in group - зазначена група віртуальних машин зобов'язана працювати на зазначеній групі серверів. Якщо відповідного серверу не буде доступно - віртуальна машина не буде включена або мігрувати;

- Should run on hosts in group - зазначена група віртуальних машин повинна намагатися працювати на зазначеній групі серверів. Якщо відповідних серверів не буде - віртуальна машина буде працювати на якомусь з інших;

- Must Not run on hosts in group - зазначена група віртуальних машин зобов'язана працювати не на зазначеній групі серверів;

- Should Not run on hosts in group - зазначена група віртуальних машин повинна намагатися працювати не на зазначеній групі серверів.

Мал. 6.64. Варіанти прив'язки груп віртуальних машин до груп серверів ESX (i)

Хоча цей поділ робиться в налаштуваннях DRS, «жорсткі» правила впливають також на HA і DPM.

Для цього механізму слід згадати про такі правила роботи:

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

- якщо відбувається конфлікт правил для однієї віртуальної машини, пріоритет має правило, створене пізніше;

- якщо в кластері присутні групи з жорсткими зв'язками виду «Must run ..» або «Must Not run ..», то навіть адміністратор не зможе запустити або мігрувати віртуальну машину на сервер, що не задовольняє правилу. Більш того, DRS, DPM і HA ні здійснювати операції, що суперечать цим правилам. Тобто при конфлікті з таким правилом:

• DRS НЕ буде мігрувати віртуальні машини з сервера, що перекладається в режим обслуговування;

• DRS не включатиме або мігрувати для балансування навантаження віртуальну машину на невідповідний сервер;

• HA не включить віртуальну машину, якщо відповідних за правилом сервер не буде доступно;

• DPM не вимикаючи сервери, які не зможе звільнити через вплив правила;

- з правилами типу «Should ..», м'якими, таких обмежень немає - саме тому вони є рекомендованими в загальному випадку;

- правила типу «Should ..», м'які, DRS може не брати до уваги при дисбалансі навантаження на процесори або пам'ять серверів кластера. Вони є рекомендованими, а не обов'язковими. DRS навіть не буде мігрувати віртуальну машину для задоволення м'якого правила, а лише видасть попередження про те, що правило не виконується.

Зверніть увагу. Доступна можливість створити alarm, який буде відслідковувати подія конфлікту з правилом. Для цього створіть alarm для віртуальної машини або їх групи типу Event based і на вкладці Trigger виберіть VM is violating VM-Host Affinity Rule.

Virtual Machine Options - це наступний пункт налаштувань DRS. Тут можна включити або виключити можливість індивідуальної настройки рівня автоматизації для кожної ВМ. Часто має сенс для важких ВМ виставити цю настройку в ручний або напівавтоматичний режим, щоб мінімізувати вплив на такі ВМ з боку DRS. Балансування навантаження буде здійснюватися за рахунок менш критичних віртуальних машин.

Зверніть увагу. У разі DRS-кластера рекомендується для ВМ з vCenter налаштувати DRS в ручний режим і завжди тримати цю ВМ на одному обраному сервері (наприклад, першому). Інакше якщо ВМ з vCenter не працює, то шукати її доведеться на всіх серверах по черзі перебором.

Power Management і Host Options - тут налаштовується DPM. Про нього і про його налаштуваннях пізніше.

VMware EVC або Enhanced vMotion Compatibility - так як DRS використовує vMotion для виконання своїх функцій, то для віртуальних машин і серверів в DRS-кластері повинні виконуватися умови для vMotion. Одне з них - однаковість процесорів по підтримуваним інструкцій. Найефективніший спосіб це зробити - включити функцію EVC.

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

EVC здатна забезпечити сумісність НЕ будь-яких процесорів, і навіть не будь-яких поколінь процесорів навіть одного вендора. Інформацію по групах сумісності EVC (рис. 6.65) можна знайти в базі знань VMware (статті 1003212 і 1005764).

Зверніть увагу - включення EVC може зажадати виключення віртуальних машин. В ідеалі включати EVC слід в момент впровадження віртуальної інфраструктури, дотримуючись наступної послідовності кроків:

1. Створити кластер DRS (на ньому також може бути включена і функція HA, це не має значення в даному контексті).

2. Включити EVC.

Мал. 6.65. Налаштування EVC для кластера DRS

3. Додати в кластер сервери.

4. Після цього почати створювати і включати віртуальні машини.

Якщо DRS-кластер вже існує, то порядок включення EVC буде наступним:

1. На тих серверах в кластері, що мають більше функцій, ніж у використовуваному шаблоні EVC, не повинно залишитися ВМ. Їх потрібно вимкнути.

2. Включити Е ^.

3. Включити ВМ, вимкнені на кроці 1.

Swapfile location - де ВМ за замовчуванням будуть зберігати свій vmkernel swap файл. Зверніть увагу, що файл підкачки може бути розташований не на загальному сховищі. Наприклад, якщо ми вказали зберігати файли підкачки на локальних дисках серверів, віртуальні машини все одно зможуть мігрувати за допомогою vMotion.

Звертаю вашу увагу, що вживається тут термін «кластер» означає тип об'єктів в ієрархії vCenter. По суті, цей «кластер» - не що інше, як контейнер для серверів, група серверів. На цій групі ми можемо включити функції DRS і / або HA. Однак настройки EVC і Swapfile location ми можемо задавати і для кластера, де ні DRS, ні HA не включені. Отже, ми можемо задавати ці настройки, навіть коли ліцензій на HA і DRS у нас немає.

Ілюстрація роботи DRS - зверніть увагу на рис. 6.66.

Мал. 6.66. DRS пропонує сервер, на якому краще включити ВМ Це вікно вибору сервера для включення ВМ. Таке вікно ви побачите в Manual-режимі DRS-кластера при включенні ВМ. Зверніть увагу, що при кліці на імена ВМ і серверів ви потрапите в їх властивості, а не виберете міграцію на той чи інший сервер. Дивитися тут треба на значення в стовпці Priority - чим більше число, тим краще (на думку DRS) запустити ВМ на сервері з цього рядка.

Виділивши кластер, на закладці Summary ви побачите базову інформацію по ньому. Зверніть увагу на DRS Recommendations (рис. 6.67).

Перейшовши за цим посиланням, ви потрапите на закладку DRS. За кнопці Recommendations на ній ви побачите приблизно таку картинку, як показано на рис. 6.68.

Ось так виглядають рекомендації до міграції від DRS. У цьому прикладі нам пропонують мігрувати ВМ File_Server_Win2008 на сервер esx1.vm4.ru. Якщо ви хочете виконати цю рекомендацію, натисніть кнопку Apply Recommendation. Якщо DRS пропонує міграцію відразу декількох ВМ, а ви не хочете мігрувати відразу все - поставте прапорець Override DRS recommendations і прапорцями в стовпці Apply вибирайте рекомендації, які будуть виконані після натиснення Apply Recommendation.

За кнопці History на закладці DRS для кластера доступна історія успішних міграцій. Дані на цій сторінці зберігаються протягом чотирьох годин і доступні і при відкритті нової сесії клієнта vSphere.

Мал. 6.67. Summary для кластера DRS

Мал. 6.68. Рекомендація vMotion від DRS

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

Зазвичай рекомендації DRS слідують з сильно розрізняється навантаження на сервери, яку можна побачити на закладці Hosts для кластера (рис. 6.69).

Мал. 6.69. Навантаження на сервери в DRS-кластері Повернемося до рис. 6.54. На закладці Summary для кластера DRS доступна інформація про його налаштуваннях і про ресурси кластера. У моєму прикладі повідомляється, що сукупні ресурси кластера дорівнюють 6 ГГц для процесора і 4,62 Гб для пам'яті. Зверніть увагу - це не означає, що я можу виділити однієї ВМ 4,62 Гб фізичної пам'яті, тому що ця пам'ять рознесена по декількох серверах. Тобто правильно читати цю інформацію в такий спосіб: все ВМ в даному кластері в сукупності можуть задіяти 6 ГГц і 4,62 Гб фізичної пам'яті. Тобто для розподілу ресурсів присутня деяка дискретність. Втім, зазвичай ресурси сервера значно перевершують ресурси для самої вимогливої ​​ВМ, і це попередження неактуально.

⇐ 6.6. storage vmotion -Живий міграція файлів вм між сховищами | Адміністрування VMware vSphere | Vmware distributed power management ⇒