Кластер DRS. DPM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По порядку

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

Рис 660 Налаштування кластера DRS

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

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

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

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

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

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

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

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

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

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

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

standby

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

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

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

Рис 661 Поточна інформація про статус DRS-кластеру

Найголовніше тут – це:

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

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

Q  Current host load standard deviation – Стандартне відхилення поточного навантаження на сервери

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

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

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

6 ceil (Current host load standard deviation / 01 × sqrt (Кількість серверів в кластері))

де ceil (x) – найменше ціле, що не меншу x

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

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

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

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

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

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

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

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

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

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

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

Q якщо додаток у віртуальних машинах ліцензується таким чином,

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

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

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

тестових, віртуальних машин тільки деякі сервери ESX (i)

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

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

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

Рис 663 Подробиці правила для DRS

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

У версії 41 зявилася можливість розділити віртуальні машини і сер-

віри по групах і вказати правила їх звязки один з одним Доступні наступні варіанти (рис 664):

Q  Must run on hosts in group – Зазначена група віртуальних машин зобовязана

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

Q  Should run on hosts in group – Зазначена група віртуальних машин

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

Q  Must Not run on hosts in group – Зазначена група віртуальних машин

зобовязана працювати НЕ на зазначеній групі серверів

Q  Should Not run on hosts in group – Зазначена група віртуальних машин

повинна намагатися працювати НЕ на зазначеній групі серверів

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

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

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

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

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

ритет має правило, створене пізніше

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

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

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

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

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

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

Q правила типу «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 (рис 665) можна знайти в базі знань VMware (Статті 1003212 і 1005764)

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

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

2 Включити EVC

Рис 665 Налаштування EVC для кластера DRS

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

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

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

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

2 Включити ЕVC

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

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

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

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

Рис 666 DRS пропонує сервер, на якому краще включити ВМ

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

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

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

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

По кнопці History на закладці DRS для кластера доступна історія успішних

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

Рис 667 Summary для кластера DRS

Рис 668 Рекомендація vMotion від DRS

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

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

Рис 669 Навантаження на сервери в DRS-кластері

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

DPM – це додаткова функція кластера DRS Полягає вона в тому, що DRS аналізує навантаження на сервери і, якщо для роботи всіх віртуальних машин достатньо лише частини серверів, може перенести всі ВМ на цю частину А що залишилися сервери перевести в standby-режим Зрозуміло, в той момент, коли в їх продуктивності виникне потреба, DPM включить їх назад Аналіз DPM заснований на тих даних, що збирає та аналізує DRS DRS виконує свою роботу з пятихвилинним інтервалом, таким чином, DRS перераховує свою аналітику раз на пять хвилин При аналізі DPM керується даними за 40-хвилинний інтервал

За замовчуванням DPM вважає нормальною навантаження на сервер 63 ± 18% Коли навантаження на сервери перевищує 81%, починається включення серверів Коли навантаження падає нижче 45%, DPM починає консолідувати ВМ і вимикати сервери Ці настройки можна змінювати в Advanced Settings для DRS-кластеру, про що нижче

Таким чином, якщо наша інфраструктура має запас по серверам, то зайві в даний момент сервери можуть бути вимкнені Або коли навантаження ночами значно падає, знову ж частина серверів може не гріти повітря даремно

Для включення серверів DPM може використовувати два механізми: BMC / IPMI або Wake-On-LAN (WOL) Для задіяння BMC / IPMI необхідно для кожного сервера вказати необхідні параметри доступу до BMC (Baseboard Management Controller) Під BMC розуміються контролери, що працюють по протоколу IPMI, наприклад HP iLO, Fujitsu iRMC, IBM RSA, Dell DRAC (рис 670)

Рис 670 Налаштування параметрів доступу до IPMI / iLo для ESX (i) 4

Само собою, повинні бути зроблені необхідні настройки – на BMC має бути створений користувач, що має право включати сервер, IP-адреса BMC / IPMI повинен бути доступний з сервера vCenter Подробиці з налаштування цих компонентів слід шукати в документації до сервера

Суть BMC / IPMI контролера – у тому, що ці контролери є, по суті, компютерами в мініатюрі, зі своїм мережевим портом Ці контролери мають доступ до управління обладнанням «великого» сервера Працюють вони незалежно від працездатності сервера Таким чином, якщо сервер вимкнений, то BMC / IPMI залишається доступний по мережі, і по мережі можна ініціювати, зокрема, функцію включення сервера Цим і користується DPM

Якщо для сервера не вказані налаштування BMC / IPMI, то vCenter намагатиметься включати їх за допомогою механізму Wake-On-Lan Зверніть увагу, що пакети WOL будуть надсилатися на ті фізичні мережеві контролери сервера, до яких підключений vMotion інтерфейс VMkernel Надсилатися вони будуть не

сервером vCenter, а одним з включених серверів ESX (i) за командою vCenter

Таким чином, необхідно виконання наступних умов:

Q на кожному сервері повинні бути інтерфейси VMkernel з дозволеним vMotion через них

Q ці інтерфейси повинні бути в одній підмережі, без маршрутизаторів між ними

Q той фізичний мережевий контролер, через який працюватиме цей vMotion інтерфейс, повинен підтримувати WOL Перевірити це можна,

пройшовшиConfiguration Network Adapters для сервера У стовпці Wake

On LAN Supported повинно стояти Yes

Зверніть увагу, що багато мережеві контролери здобувають WOL не у всіх режимах роботи Часто тільки 100 або 10 Мбіт / с Таким чином, може знадобитися настройка портів фізичного комутатора, до якого підключені ці мережеві контролери серверів Ці порти повинні бути налаштовані на автоузгодження (auto negotiate) швидкості, щоб, коли сервер вимкнений, мережеві карти могли працювати на необхідної для WOL швидкості

Ще до включення функціоналу DPM слід протестувати працездатність цих механізмів У контекстному меню працюючого сервера є пункт Enter Standby Mode, А в меню вимкненого сервера – Power on Якщо включення сервера через IPMI / iLO не запрацювало, то видаліть налаштування з пунктуPower Management для цього сервера Коли IPMI / iLO для сервера не налаштоване, DPM буде використовувати WOL

Для налаштування DPM зайдіть у властивості кластера DRS, вас цікавить пункт

Power Management Там три варіанти налаштування:

Q  Off – DPM виключений

Q  Manual – DPM включений, але буде лише показувати рекомендації по виключенню серверів Ці рекомендації будуть доступні на закладці DRS для кластера

Q  Automatic – Включення і виключення серверів, а також повязані з цим міграції ВМ будуть відбуватися автоматично Бігунок вказує на те, рекомендації з яким пріоритетом будуть виконуватися автоматично Пріоритет позначається цифрами від 1 (максимальний) до 5 (мінімальний)

Зверніть увагу, що рівень автоматизації можна вказувати індивідуально для кожного сервера Робиться це на пункті Host Options Якщо якісь сервери неможливо включити через IPMI / iLO / WOL, буде гарною ідеєю для них функцію DPM відключити

Рекомендації DRS і DPM не залежать одне від одного Рівні автоматизації DRS і DPM не повязані один з одним

Для автоматизації моніторингу дій як DRS, так і DPM можна використовувати механізм vCenter alarms Для кластера або вище нього в ієрархії vCenter треба створити alarm, який моніторить події (Events) Наприклад, для DPM можна моніторити такі події:

Q  DrsEnteringStandbyModeEvent – Ініціація виключення сервера

Q  DrsEnteredStandbyModeEvent – Успішне вимикання сервера QDrsExitingStandbyModeEvent – Ініціація включення сервера QDrsExitedStandbyModeEvent – Успішне включення сервера

Q  DrsExitStandbyModeFailedEvent – Неуспішне включення сервера

З моніторингом може бути повязаний ще один нюанс – у вас може вико тися-яке з засобів моніторингу, таке як BMC Performance Manager, HP System Insight Manager, CA Virtual Performance Management, Microsoft System Center Operations Manager, IBM Tivoli Ця система може зреагувати на вимикання сервера, ініційоване DPM Можуть знадобитися корективи правил моніторингу, щоб на такі штатні вимикання серверів ці системи не реагували

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

рез планувальник vCenter (Home Scheduled Tasks New) Створіть завдання

Зверніть увагу vCenter привязує шаблони ВМ до якогось серверу, навіть коли вони розташовані на загальному сховищі Якщо DPM вимкне той сервер, за яким числиться шаблон, то шаблоном неможливо буде скористатися Тому в ідеалі той сервер, за яким числяться шаблони, не повинен вимикатися DPM Якщо ж шаблон виявився недоступний, то його треба видалити з ієрархії vCenter (пункт Remove from Inventory контекстного меню шаблону) і потім додати назад через вбудований файловий менеджер (пункт Browse Datastore контекстного меню сховища, де розташований шаблон)

З видаленням DRS-кластеру повязаний наступний нюанс – видалення DRS видалить всі пули ресурсів, існуючі в ньому Крім того, пропадуть всі правила affinity, anti-affinity і правила привязки груп віртуальних машин до груп хостів Тому, якщо вам необхідно лише на час відключити функціонал DRS, часто краще перевести його в режим Manual і перевірити, що для кожної ВМ також використовується Manual-Режим

Зверніть увагу на рис 671

Тут ви бачите область розширених налаштувань кластера DRS і DPM

У даному прикладі значення 75 настройки DemandCapacityRatioTarget говорить про те, що DPM повинен звертати увагу на сервери не за формулою 63 ± 18%, а за формулою 75 ± 18%

За списком розширених налаштувань зверніться за посиланням http://wwwvmware

com/resources/techresources/1080

Рис 671 DRS Advanced Settings

Джерело: Міхєєв М О Адміністрування VMware vSphere 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*