Висока доступність віртуальних машин – ЧАСТИНА 1

Забезпечення високої доступності додатків – одна з найважливіших завдань ІТ підрозділу будь-якої компанії І вимоги до доступності стають все жорсткішими для все більшого кола завдань

Зазвичай під доступністю розуміється час, протягом якого додаток було доступно Якщо програма не було доступно 3 з половиною дні за рік, то доступність його була близько 99% Якщо додаток було недоступне порядку години за рік, то доступність порядку 99,99% і т д

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

Найвищу доступність забезпечать рішення, вбудовані в сам додаток, або кластери рівня додатків між віртуальними машинами (наприклад, Microsoft Failover Cluster) Слідом йде VMware Fault Tolerance, що забезпечує відмінний захист, але лише від збоїв сервера (НЕ гостьовий ОС або програми) Останнім іде VMware High Availability, який дає найбільші з цих трьох варіантів простої, зате надзвичайно простий, дешевий і накладає

Висока доступність віртуальних машин

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

VMware High Availability, або кластер високої доступності VMware, зявився ще в третій версії віртуальної інфраструктури VMware C моменту появи це рішення набуло додаткові можливості і позбулося деяких недоліків

Поточна версія VMware HA вміє робити дві речі:

Q перевіряти доступність серверів ESX (i), перевіряючи доступність їх керуючих інтерфейсів Використовуються повідомлення пульсу (heartbeat) власного формату У разі недоступності якогось сервера робиться спроба запустити працювали на ньому ВМ на інших серверах кластера

Q перевіряти доступність віртуальних машин, відстежуючи сигнали пульсу

(Heartbeat) від VMware tools У разі їх пропажі ВМ перезавантажується Відповідає за цю функцію компонент називається Virtual Machine Monitoring Цей компонент включається окремо і є необовязковим Віднедавна Virtual Machine Monitoring отримав можливість інтегруватися зі сторонніми рішеннями, такими як Symantec ApplicationHA – і відстежувати статус не тільки VMware tools, а й додатків в гостьовій ОС

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

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

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

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

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

Зверніть увагу, що при включенні HA для кластера або при додаванні сервера в кластер з включеним HA в панеліRecent Tasks зявляється задача

«Configuring HA» Прослідкуйте, щоб це завдання для всіх серверів закінчилася

успішно Якщо це не так, ознайомтеся з повідомленням про помилку і вирішите проблему Швидше за все, в цьому вам допоможе стаття бази знань VMware № 1001596 (http://kbvmwarecom/kb/1001596)

На сервери і ВМ в кластері HA накладаються такі умови – ВМ повинні мати можливість запуститися на будь-якому з серверів кластера Тобто:

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

серверам

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

Q до ВМ не повинні бути підключені COM / LPT-порти, FDD і CD-ROM серверів, образи iso і flp з приватних ресурсів – тобто все те, що перешкоджає включенню ВМ на іншому сервері Також перешкодить перезапуску на іншому сервері використання VMDirectPath

Зверніть увагу, що умови HA вельми нагадують умови для VMotion (що логічно), але серед них немає умови на сумісність процесорів Його немає, тому що у випадку HA віртуальні машини перезапускати на інших серверах, а не мігрують на гарячу А перезапуститися ВМ може на будь-якому процесорі, в тому числі і на процесорі іншого виробника

Також є деякі обмеження Якщо ви використовуєте vSphere версії до 41, то актуальні такі значення:

Q якщо в HA кластері до 8 серверів, то на весь кластер не більше 160 ВМ

Q якщо в HA кластері більше 9 серверів (максимум 32), то на кожному може бути не більше 40 ВМ

Це не жорстко прописані обмеження, але настійно рекомендовані

Проте починаючи з версії 41 відбулися значні зміни:

Q серверів в кластері і раніше може бути до 32

Q без умов на кількість серверів в кластері число віртуальних машин на кожному сервері може досягати 320

Q всього в кластері може бути до 3000 віртуальних машин

Ці обмеження (якщо ці цифри можна назвати обмеженням) загальні для кластерів HA і DRS

Зверніть увагу 320 віртуальних машин на сервер – це абсолютний максимум Він не може бути перевищений не тільки в нормально працюючій инфраструк турі, а й після відмови сервера або декількох – інакше HA не зможе включити всі віртуальні машини з відмовили серверів

Налаштування VMware HA показані на рис 71

Host Monitoring Status – Якщо прапорець Enable Host Monitoring не варто, то HA не працює Зняття його знадобиться, якщо ви плануєте якісь маніпуляції з мережею, на які HA може відреагувати, а вам би цього не хотілося Альтернатива зняттю даного прапорця – Зняття прапорця VMware HA для кластера (Clus ter Features), але це потягне за собою видалення агентів HA з серверів і скидання налаштувань Це незручно, якщо функціонал HA потрібно відновити після завершення маніпуляцій Також VMware рекомендує відключати HA зняттям прапорцяEnable Host Monitoring, Коли ви додаєте групи портів і віртуальні комутатори на сервери або ставите частина серверів в режим обслуговування

Admission Control – Це налаштування резервування ресурсів на випадок збою Варіант «Allow VMs to be powered on ..» відключає-яке резервування, тобто HA кластер не обмежує кількість запущених віртуальних машин Інакше – HA буде самостійно резервувати якусь кількість ресурсів

Висока доступність віртуальних машин

Рис 71 Основні настройка кластера HA

Налаштування способу вираховування необхідної кількості ресурсів робиться в пункті Admission Control Policy

Варіант без резервування може бути зручніше, тому що ви гарантиро-

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

Admission Control Policy – Як саме HA повинен забезпечувати резервування ресурсів Якщо ми хочемо довірити HA кластеру контроль за цим і вибралиAdmission Control = «Prevent VMs from being powered on ..», то тут вибираємо один з трьох варіантів резервування ресурсів:

Q  Host failures cluster tolerates – Вихід з ладу якого числа серверів має пережити кластер При виборі цього варіанту налаштування HA стежить за тим, щоб ресурсів усіх серверів мінус вказане тут число вистачало б на роботу всіх ВМ У підрахунку необхідних для цього ресурсів HA оперує поняттям «слот» Про те, що це і як вважає ресурси HA, – трохи далі

Q  Percentage of cluster resources – В цьому випадку HA просто резервує зазначену частку ресурсів усіх серверів Для розрахунків поточного споживання використовуються настройки reservation кожної ВМ, або константи 256 Мб для памяті і 256 МГц для процесора, що більше До речі, 100% ресурсів в даному випадку – це не фізичні ресурси сервера, а ресурси так званого «root resource pool», то є всі ресурси сервера мінус зарезервовані гіпервізором для себе

Q  Specify a failover host – Зазначений сервер є «запаскою» На цьому сервері не можна буде включати віртуальні машини – тільки HA зможе включити на ньому ВМ з відмовили серверів На нього не можна буде мігрувати ВМ за допомогою VMotion, і DRS НЕ БУДЕ мігрувати ВМ на цей сервер Якщо включення ВМ на зазначеному запасному сервері не вдалося (наприклад, тому що він сам відмовив), то HA намагатиметься включити ВМ на інших серверах

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

Рис 72 Інформація на закладці Summary для HA кластера

Тут ви бачите три варіанти інформації з закладки Summary для кластера з включеним HA Ці три варіанти відповідають трьом варіантам настрій ки Admission Control РядокConfigures failover capacity нагадує про те,

Висока доступність віртуальних машин

яке значення ви дали налаштуванні резервування ресурсів У моєму прикладі, зверху вниз:

Q відмовостійкість в один сервер налаштована і відмовостійкість в один

сервер є – на останнє вказуєCurrent failover capacity За натисканні посиланняAdvanced Runtime Info відкривається вікно з додатковою інформацією по поточному стану кластера

Q резервування 25% ресурсів зазначено, а вільно в даний момент 88% для процесора і 47% для памяті

Q резервним сервером є сервер esxi2vm4ru Зелений значок напр-

тив його імені означає, що сервер доступний і на ньому немає працюючих ВМ Жовтий значок означав би, що сервер доступний, але на ньому є працюючі ВМ Червоний – що сервер недоступний, або агент HA на ньому не працює правильно

Який з варіантів резервування ресурсів використовувати

Я б рекомендував або взагалі відключити Admission Control, або використовувати третій варіант резервування – резервування конкретного сервера

Джерело: Міхєєв М О Адміністрування 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>

*

*