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

Відключення Admission Control виправдано в тому випадку, коли сервери вашої віртуальної інфраструктури завжди не завантажені більше, ніж відсотків на 80 Якщо ресурси процесора і памяті у вас в надлишку, або ви самі стежите за тим, щоб завантаження не перевищувала тих самих 80% (плюс-мінус), то додатково щось резервувати засобами HA просто немає чого

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

Резервування ресурсів за відсотками не подобається мені тим, що резервування робиться не для реальних апетитів віртуальних машин, а для їх reservation Тобто якщо HA резервує 25% ресурсів, то це означає, що сервер може бути завантажений і на 100%, а 75% відноситься до суми reservation віртуальних машин Це означає, що якщо для всіх або більшості ВМ ви настройку reservation не робили, то такий варіант резервування ресурсів взагалі непотрібний

Нарешті, варіант резервування за слотам Його докладний опис – трохи нижче, а коротка характеристика от яка: він поганий, якщо віртуальні машини нашої інфраструктури сильно відрізняються за своєю конфігурації Це повязано з тим, що HA розраховує розмір якогось слота (кількість мегагерц і мегабайт), яке необхідно для роботи ВМ І розмір слота – один на всіх Я ризикну припустити, що в більшості інфраструктур таке наближення буде занадто грубим

Virtual Machine Options Це наступна група налаштувань кластера HA (рис 73)

Тут нам доступно наступне:

Q  VM restart priority – Пріоритет рестарту для ВМ кластера, тут вказуємо значення за замовчуванням Очевидно, що першими повинні стартувати ВМ, від яких залежать інші Наприклад, сервер БД повинен стартувати до сервера додатків, що використовує дані з БД Зверніть увагу, що якщо одночасно відмовили хоча б два сервери, то перезапуск

Рис 73 Virtual Machine Options

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

Q  Host Isolation response – Чи повинен сервер вимкнути свої віртуальні

машини, якщо він опинився в ізоляції (isolation) Що таке ізоляція, см

трохи далі

Q  Virtual Machine Settings – Тут можемо обидві попередні налаштування вказати індивідуально для кожної ВМ

Якщо для кластера HA ми вказали настройки Admission Control = «Prevent VMs from being powered on», то HA починає резервувати ресурси кластера Кількість резервуються ресурсів залежить від продуктивності серверів, кількості і налаштувань віртуальних машин, від значенняHost failures cluster tolerates (Ми зараз говоримо про настройку Admission Control Policy у значенні «Host failures cluster tolerates»)

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

Дивіться рис 74

Рис 74 Інформація про слоти в HA кластері

Тут ми бачимо:

Q  Slot size – Розмір слота для цього кластеру

Q  Total slot in cluster – Сума слотів на хороших серверах (good hosts, см

останній пункт списку)

Q  Used slots – Скільки слотів зараз зайнято

Q  Available slots – Скільки слотів ще можна зайняти, щоб кластер продовжив бути ВІДМОВОСТІЙКО

Q  Total powered on VMs in cluster – Всього включених ВМ

Q  Total hosts in cluster – Всього серверів в кластері

Q  Total good hosts in cluster – Всього «хороших» серверів в кластері Добрими вважаються сервери: не в режимі обслуговування, невимкнені і без помилок HA

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

«Хороших» теж 2 Всього включених ВМ 2 Всього слотів 36, зайняті 2, доступні

16 Розмір одного слота – 1 vCPU, 256 МГц, і 385 Мб ОЗУ Звідки беруться ці цифри Чому з 34 (= 36 – 2) слотів доступні лише 16

«Слот» – це кількість ресурсів під віртуальну машину Дуже приблизна кількість ресурсів, яке вважається за наступною схемою:

1 Виглядає reservation всіх ВМ в кластері

2 Вибирається найбільше значення, окремо по памяті і окремо по процесору

3 Воно й стає розміром слота Але для памяті до значення reservation додаються накладні витрати (memory overhead, його можна побачити на закладці Summary для віртуальної машини)

4 Якщо reservation у всіх нуль, то береться значення слота за замовчуванням – 256 МГц для процесора і максимальне серед значень overhead для памяті

5 Ресурси процесора і памяті сервера діляться на пораховані в п 3 і 4 величини, з округленням вниз Вибирається найменше значення – стільки слотів є на цьому сервері Ці розрахунки виконуються для кожного сервера

Таким чином, припустимо, що у вас в кластері 50 ВМ з маленьким або нульовим reservation і одна ВМ з великим reservation (наприклад, по рівним 1000 МГц для процесора) Тоді HA вважає розмір одного слота рівним 1000 МГц і що таких слотів потрібно 51, по числу включених віртуальних машин Притому ресурси для 51 слота повинні бути не на всіх серверах, а на всіх серверах мінус вказане в Host failures cluster tolerates кількість Саме для виконання цієї умови HA тримає частину ресурсів зарезервованими

Поверніться до малюнка вище HA порахував розмір слота і порахував, що ресурсів двох серверів кластера вистачить на 36 слотів Але HA гарантує, що запустять ся все ВМ при падінні зазначеного в налаштуваннях кількості серверів, лише якщо зайнято не більше 16 слотів

Однак якщо вас не влаштовують такі підрахунки, то за допомогою параметрів das slotCpuInMHz і dasslotMemInMB в Advanced Options для HA кластера можна вказати розмір слота вручну Детальніше про розширені налаштування (Advanced Settings) для кластера HA далі

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

У той момент, коли ви включаєте HA для кластера, vCenter встановлює на кожному сервері агент HA Серед серверів в кластері вибираються пять, агенти на яких отримують статус Primary Всі інші сервери стають Secondaryузламі Безпосередньо роботою HA кластера управляють саме Primary-вузли

Один з Primary-вузлів призначається «active primary», координатором Саме він управляє перезапуском ВМ з відмовили серверів Якщо він сам опинився в числі відмовили, то на роль координатора призначається один з решти Primary-вузлів

Агенти обмінюються між собою повідомленнями пульсу (heartbeat) виду «я ще живий» За замовчуванням обмін відбувається кожну секунду

Якщо за 15-секундний інтервал від сервера не прийшло жодного повідомлення пульсу (heartbeat) і сервер не відповідає на пинги, то він визнається, що відмовив Active Primary сервер починає перезапуск ВМ з цього сервера на інших Причому HA вибирає для включення ВМ сервер з найбільшою кількістю незарезервірованних ресурсів процесора і памяті, і вибір цей відбувається перед включенням кожної ВМ

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

HA робить 5 спроб перевключення (змінити цю настройку можна за допомогою параметра dasmaxvmrestartcount)

Перша спроба відбувається після визнання сервера відмовив (15 секунд за замовчуванням)

Друга – через 2 хвилини

Третя – через 4 хвилини

Всі наступні – через 8 хвилин

Зазвичай Primary-вузлами стають ті сервери, що були додані в кластер першими

Зверніть увагу, що при відмові Primary-вузла кластера перевиборів не відбувається Так як Primary вузлів 5, то HA кластер гарантовано переживає відмова будь-яких чотирьох серверів Якщо вийдуть з ладу пять і ці пять виявляться Primary – то HA кластер не відпрацьований

Імовірність такого розвитку подій невисока, проте свого часу був широко описаний випадок, коли в одному HA кластері були блейд-сервери з двох шасі У кластер ці сервери додавали без витівок, послідовно, і все Primaryузли опинилися в одному шасі Яке цілком вийшло з ладу через відмову центральної контактної плати

Щоб виключити ймовірність такого збігу обставин, має сенс перевірити, які сервери є Primary-вузлами Дізнатися, Primary або Secondary-вузлом є той чи інший сервер, з графічного інтерфейсу не можна, тільки з командного рядка:

Переглянувши файл журналу

cat  /var/log/vmware/aam/aam_config_util_listnodeslog

або запустивши оболонку

/opt/vmware/aam/bin/Cli

і виконавши в ній команду

ln

На виході ми побачимо щось подібне (для останнього випадку) такого:

~ #  /opt/vmware/aam/bin/Cli Welcome  to  VMware    AAM

Version  512

Copyright  VMware,  Inc 2006

AAM&gt  ln

Node Type State

——————————— ————-esx1  Primary  Agent Running

esxi2  Primary  Agent Running

Якщо нас не влаштовує поточний розбиття, то ми можемо на нього вплинути:

Q вибравши «Reconfigure for VMware HA» в контекстному меню сервера У цьому випадку вибори Primaryі Secondary-вузлів відбудуться випадковим чином

Q помістивши один з Primary-вузлів у Maintenance-режим, відключивши (discon-

nect) від vCenter або видаливши з кластера

Q виконавши в командному рядку

/ Opt / vmware / aam / bin / Cli Після цього команди promotenode <ім'я сервера> і

demotenode <ім'я сервера>

змінюють статус Primary ⇒ Secondary (promote) і в зворотний бік (demote) Зверніть увагу, що за допомогою команди promotenode ви можете зробити Primary-вузлами 6 серверів Однак це не підтримується VMware При спробі призначити Primary 7-го сервера у вас почнуть відключатися агенти HA

Починаючи з версії 41 на вкладці Summary для кластера HA зявилося посилання Cluster Operational Status У відчиненому при кліці по ній вікні відображають ся проблеми (якщо вони є) з вузлами кластера (рис 75)

Рис 75 Інформація про проблемні вузлах кластера HA

Сервери в кластері HA перевіряють доступність один одного повідомленнями пульсу (heartbeat) по мережі управління Однак ці сигнали можуть перестати ходити не

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

тому, що впав сервер, а тому, що впала мережу Фізичний контролер може вийти з ладу, порт в комутаторі, комутатор цілком Ситуація, коли ESX (i) працює, але недоступний по мережі, називається ізоляція Недоступний по мережі сервер стає ізольованим

ESX (i) вміє виявляти ізоляцію Якщо сервер перестав отримувати повідомлення пульсу (heartbeat) від всіх інших серверів, то через 12 секунд він пробує пропінгувати перевірочний IP-адресу Якщо той на пінг не озвався, сервер визнає себе ізольованим За замовчуванням перевірочним є адреса шлюзу за замовчуванням (для ESX – шлюзу Service Console), але ви можете вказати довільну адресу і навіть кілька через розширені настройки (Advanced Settings)

Таким чином, якщо сервер в кластері перестав приймати повідомлення від інших серверів і плюс до того перестав пінгувати перевірочні IP-адреси, то він вважає себе ізольованим (Якщо ж інші сервери пропали, але перевірочний адресу пінгуєтся, то відмовився визнати інші сервери)

У налаштуваннях кластера ми можемо вказати, що повинен робити сервер, опинившись ізольованим, рис 76

Рис 76 Налаштування реакції на ізоляцію

Як ви бачите, варіантів три:

Q  Leave powered on – Не робити нічого, залишити ВМ працюючими

Q  Power off – Вимкнути живлення ВМ, некоректне завершення роботи

Q  Shutdown – Коректне завершення роботи Вимагає встановлених у ВМ VMware tools Якщо за 300 (за замовчуванням) секунд ВМ не вимкнув, її вимикають вже некоректно

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

Що вибирати

Ізоляція трапляється тоді, коли виникають проблеми в мережі управління (це мережа Service Console для ESX і мережа VMkernel з прапорцем «management» для ESXi) Це означає, що наш ESX (i) недоступний для управління, однак ВМ на ньому продовжують працювати Інші сервери кластера, побачивши пропажу пінгів з цього сервера, спробують включити його ВМ у себе – але не зможуть через блокування файлів на VMFS Щоб ВМ змогли перезапуститися на інших серверах HA кластера, їх треба вимкнути Це міркування номер раз До речі, спроб включити буде 5

Міркування номер два – а чи будуть ВМ з відмовив сервера мати доступ у мережу Зверніть увагу на рис 77

Як ви бачите, в даному прикладі мережа керуюча, і мережа віртуальних машин рознесена фізично І вихід з ладу мережного контролера vmnic0 призведе до ізоляції сервера, але не до припинення роботи ВМ по мережі Допитливий читач, правда, може привести приклад глобального збою – якщо vmnic0 і vmnic1, 3,4

Рис 77 Приклад організації мережі

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

підключені до одного комутатора, і з ладу вийшов комутатор Однак, вправах, комутатор не повинен бути незадублірован і по-друге – тоді мережа пропаде на всіх ESX (i), і HA тут не допоможе

Висновок з цих двох міркувань наступний:

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

Q якщо ізоляція не означає пропажу мережі для ВМ (як у моєму прикладі),

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

«Leave powered on», щоб зменшити ймовірність накладок при виключенні і перевключення віртуальних машин

Q якщо частина ВМ розташована на локальних або приватних сховищах і

HA не зможе їх перевключіть – однозначно їх має сенс залишити включеними

Q віртуальні машини можуть розташовуватися на NFSілі iSCSI-ресурсах, і

пропажа мережі може означати і недоступність дисків ВМ У такому випадку VMware рекомендує реакцією на ізоляцію вибирати вимикання ВМ Це повязано з тим, що після втрати якимось хостом доступу до IP-сховища блокування файлів ВМ зніметься, і ВМ будуть включені на іншому сервері А якщо на першому сервері вони не були вимкнені, а доступ до сховища знову був отриманий – виникне конфлікт, ситуація split brain

Як видно, для HA особливо важлива конфігурація мережі На що тут слід звернути увагу:

Q на дублювання керуючої мережі

Q на дублювання фізичних комутаторів

Q перевірочний IP-адреса має відповідати на пинги 24/7 Варіант за замовчуванням – шлюз для керуючого інтерфейсу хороший далеко не завжди, і він один У розділі, присвяченому розширених налаштувань (Advanced Settings), для кластера HA сказано, як задавати довільний і доповни тільні перевірочні IP

До дублювання керуючих інтерфейсів у вас два підходу (рис 78)

Зліва ви бачите один керуючий інтерфейс (Service Console для ESX), підключений до двом фізичним контролерам А праворуч – два керуючих інтерфейсу на різних фізичних контролерах У будь-якому випадку ми досягаємо бажаного – відсутність єдиної точки відмови

Якщо керуючих інтерфейсів кілька, то повідомлення пульсу (heartbeat) будуть надсилатися через все

До речі, якщо у вас не буде дублювання по одній з цих схем, то статус сервера буде Warning, і на закладціSummary для сервера ви будете бачити його лайка з того приводу (рис 79)

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

Рис 78 Схеми дублювання керуючих інтерфейсів Джерело: VMware

Рис 79 Повідомлення про відсутність дублювання керуючого інтерфейсу сервера

Налаштування VM Monitoring, рис 710

Суть цього механізму HA – у тому, що він відстежує наявність сигналів пульсу (heartbeat) від VMware tools Передбачається, що відсутність цих сигналів означає зависання VMware tools внаслідок зависання гостьовий ОС

Якщо сигнали пульсу (heartbeat) відсутні протягом «Failure interval» секунд, а з моменту старту ВМ пройшло не менш «Minimum uptime» секунд, то ВМ перезавантажується Однак її перезавантажать не більш «Maximum per-VM resets» раз за час «Maximum resets time window»

Цей механізм, по суті, є аналогом так званого watchdog-таймера, реалізованого в BIOS багатьох серверів

Опис налаштувань:

Q  VM monitoring status – Якщо цей прапорець не варто, то даний механізм не працює

Q  Default Cluster settings – Налаштування роботи механізму На малюнку наведено варіант «Custom» Якщо однойменний прапорець не варто, то ми можемо вибрати один з трьох варіантів за умовчанням

Q  Virtual Machine Settings – Вказівка ​​попередніх налаштувань індивідуально на рівні кожної ВМ

Іноді можливі ситуації, що сигнали пульсу (heartbeat) від VMware tools пропали, але ВМ працює Щоб не перезавантажувати працюючу ВМ в такій ситуації, компонент VM Monitoring відстежує ще й активність введення-виведення ВМ Якщо сигнали пульсу (heartbeat) пропали і не поновилися знову протягом

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

Рис 710 VM Monitoring

«Failure interval» секунд, то виглядає на активність роботи цієї ВМ з диском і мережею за останні 120 секунд Якщо активності не було, ВМ перезавантажується

Мені цей механізм видається занадто грубим, щоб з ходу почати його використовувати Проте якщо у вас є регулярно зависающие віртуальні машини і перезапуск як вирішення проблеми вас влаштовує – Тільки для цих ВМ функція VM Monitoring підійде відмінно

Зверніть увагу, що у версії 41 VMware реалізувала API для сторонніх постачальників кластерних рішень під назвою Application Monitoring Суть цього механізму – в тому, що сторонні агенти, встановлені в гостьові ОС, можуть відслідковувати статус додатків і взаємодіяти з сервером vCenter і агентами HA для ініціації перезавантаження ВМ при проблемах у роботі програми На момент написання єдиним відомим мені додатком, які реалізують Application Monitoring для VMware HA, є Symantec ApplicationHA

Оскільки настройки такого роду доповнень повною мірою залежать від використовуваного стороннього кошти, тут вони не розглядаються

Для кластера HA можуть бути виконані деякі розширені налаштування

Список таких налаштувань см в табл 71

Таблиця 71 Список розширених налаштувань (Advanced Settings) для кластера HA

Назва настройки

Опис

dasisolationaddress[..]

Значення – IP-адресу Вказівка ​​довільного IP-адреси як перевірочного на ізоляцію IP

dasisolationaddress1, dasisolationaddress2 . das isolationaddress10 є додатковими перевірочними адресами Занадто багато краще не вказувати, інакше процес перевірки на ізоляцію затягнеться Зазвичай вказують

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

Зміна вимагає перевключення HA кластера

dasusedefaultisolationaddress

Значення – true \ false Використовувати чи ні шлюз за замовчуванням як перевірочний адресу Зміна вимагає перевключення HA кластера

dasfailuredetectiontime

Значення – число За замовчуванням HA чекає відновлення сигналів з інших хостів протягом 15 000 мілісекунд, до того як визнати їх відмовили Тут вказуємо довільну кількість мілісекунд Багато фахівців рекомендують збільшувати значення за замовчуванням до 20 000 або навіть до

60000 мілісекунд Зміна вимагає перевключення HA кластера

dasfailuredetectioninterval

Значення – число Як часто хости посилають один одному сигнали пульсу (heartbeat) За замовчуванням – 1000 мілісекунд Зміна вимагає перевключення HA кластера

dasdefaultfailoverhost

Значення – імя хоста Вказівка ​​предпочитаемого хоста для старту на ньому ВМ з відмовив Використовується, коли Admissions control = failover level або cluster resource percentage Якщо Admissions control = Failover host, то дана настройка має пріоритет над штатної налаштуванням Такий хост може бути тільки один для кластера

dasisolationShutdownTimeout

Значення – число Час, протягом якого очікується вимикання ВМ при ізоляції, коли вибрано коректне завершення роботи Після закінчення цього часу ВМ вимикається жорстко За замовчуванням 300 секунд Зміна вимагає перевключення HA кластера

dasslotMemInMB

Значення – число Кількість памяті для слота, в мегабайтах При виборі розміру слота це значення порівнюється з найбільшим значенням reservation + overhead між усіма включеними ВМ в даному кластері Менше з двох цих значень і буде прийнято за розмір слота

dasslotCpuInMHz

Значення – число Кількість ресурсів процесора для слота, в мегагерцах При виборі розміру слота це значення порівнюється з найбільшим значенням reservation між усіма включеними ВМ в даному кластері Менше з двох цих значень і буде прийнято за розмір слота

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

Таблиця 71 Список розширених налаштувань (Advanced Settings) для кластера HA (закінчення)

Назва настройки

Опис

dasvmMemoryMinMB

Значення – число Кількість памяті, що використовується для розрахунків слота під ВМ, коли її reservation для памяті дорівнює нулю За умовчанням 0

dasvmCpuMinMHz

Значення – число Кількість ресурсів процесора, що використовується для розрахунків слота під ВМ, коли reservation для процесора дорівнює нулю За замовчуванням 256 Мгц

dasiostatsInterval

Значення – число Кількість секунд, за яке аналізується активність введення-виведення ВМ, коли пропали сигнали пульсу (heartbeat) від VMware tools За замовчуванням 120 секунд

Список неповний, в базі знань і в радах підтримки VMware вам можуть зустрітися і інші настройки

Зверніть увагу«Das» у назві цих налаштувань присутній тому, що ця абревіатура – перший варіант назви того, що зараз називається «кластер HA»

Щоб вказати ці налаштування, зайдіть у властивості кластера і в налаштуваннях HA натисніть кнопку Advanced Settings (Рис 711)

Рис 711 Розширені налаштування для кластера HA

Зверніть увагу, при оцінці використовуваних у даний момент ресурсів HA дивіться не на поточну навантаження, а на значенняreservation Це означає, що він не найефективнішим чином вибирає сервери для рестарту ВМ Тому для вас набагато зручніше використовувати HA разом з DRS, який збалансує навантаження більш ефективно

Починаючи з версії 41, при включенні HA і DRS разом останній буде намагатися консолідувати вільні ресурси на якомусь одному сервері, щоб знизити ймовірність «фрагментирования» вільних ресурсів між серверами кластера

Якщо для HA включений admission control, то DRS може не змогти мігрувати ВМ з серверів в режимі обслуговування, якщо вони претендуватимуть на зарезервовані HA ресурси на інших серверах Вам доведеться тимчасово відключити Admission Control

Якщо admission control вимкнений, то HA НЕ резервує ресурси Тому DRS зможе мігрувати ВМ з сервера в режимі обслуговування і stand-by, навіть якщо це зробить конфігурацію вразливою до збою

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

*

*