Віртуалізація - що нового в vmware high availability (fdm) в vmware vsphere 5

Що нового в VMware High Availability (FDM) в VMware vSphere 5.

Ви вже Новомосковсклі, що в VMware vSphere 5 механізм відмовостійкості віртуальних машин VMware High Availability зазнав значних змін. Точніше, він не просто змінився - його повністю переписали з нуля. Тобто переробили зовсім, змінивши логіку роботи, принцип дії і прибравши багато з існуючих обмежень. Давайте поглянемо детальніше, як тепер працює новий VMware HA з агентами Fault Domain Manager.

Спочатку поглянемо на загальний список змін і нововведень VMware HA:

• Повністю переписаний механізм відмовостійкості
• Усунення найбільш частою проблеми - дозвіл імен в DNS
• Кілька каналів для комунікації агентів. І мережу управління (management network), і мережа зберігання можуть бути використані для взаємодії агентів. Це підвищує надійність і дозволяє обробити більшість типів відмов.
• підтримка IPv6
• Поліпшення механізму вирішення проблем - тепер логи на хості ESXi надають більш зручну і зрозумілу інформацію.
• Перероблений інтерфейс користувача.
• Поліпшений механізм розгортання агентів і налаштування кластера.

Давайте поглянемо на загальну картину компонентів нового VMware HA:

Ми бачимо, що тепер на кожному хості встановлюється агент Fault Domain Manager (FDM) механізму VMware HA (колишній AAM). В процесі настройки кластера HA один з агентів вибирається як Master, всі інші виконують роль Slaves. Тепер більше немає primary / secondary вузлів. Розмір агента FDM - близько 50 КБ (до речі, він тепер не залежить від служби vpxd).

Роль Master виконує наступне:

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

Роль Slave виконує наступне:

• Відстежує стан своїх віртуальних машин, веде їх список і відправляє цю інформацію на Master.
• Здійснює функції VM Health Monitoring (тобто те, що не залежить від кластера HA)
• Відстежує стан Master і, в разі його відмови, бере участь у виборах нового Master.

У разі виходу з ладу Master відбуваються вибори між Slaves, де вибирається новий Master. Як він вибирається? Дуже просто - це хост з максимальною кількістю сховищ (якщо у хостів рівну кількість сховищ, то вибирається просто за алфавітом, в залежності від імені).

Вибори нового Master відбуваються в 3 випадках:

• Ви включили VMware HA в кластері.
• Master вийшов з ладу або переведений в Maintenance Mode.
• Структура мережі управління розірвалася на сегменти, в одному з яких немає Master. У цьому випадку буде 2 або більше Master'ов в кластері.

Комунікація між агентами FDM відбувається наступним чином:

Агенти для взаємодії використовують Management Network. Все спілкування йде без бродкастов, тільки "точка-точка". Вибори Master йдуть по UDP. Після того, як Master обраний, хости спілкуються між собою по TCP з шифруванням по SSL.

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

Master посилає конфігурацію кластера на сервер VMware vCenter, інформує Slaves про зміни конфігурації і посилає сигнали доступності (Heartbeats) Slave-хостам кластера HA.

Сам же vCenter в першу чергу контактує з Master для підтримки списку сумісності для хостів (на яких з них ВМ може бути запущена) і поновлення станів про віртуальних машинах. Master поширює цю інформацію далі.

Як видно з картинки, vCenter може контактувати і з Slave-вузлами для наступних цілей:

• Сканування на предмет існування Master.
• Якщо Master каже, що він не може зв'язатися з одним з Slaves. Тоді vCenter намагається з'ясувати чому.
• При включенні Secondary VM для Fault Tolerance.
• Коли хост сповістив про те, що він ізольований або мережа розділена.

Для комунікації використовуються наступні порти і протоколи:

На рівні системи зберігання відбуваються наступні взаємодії:

З'явилися так звані "Heartbeat Datastores". Вони використовуються тільки коли не працює мережа управління (Management Network).

Ці Heartbeat Datastores дозволяють майстру моніторити доступність підлеглих і визначати, коли вони виявляються ізольовані від мережі. При цьому через ці сховища відбувається координація прав володіння на віртуальні машини, оскільки ними може володіти тільки один Master, а самих майстрів може бути кілька при поділі мережі. За замовчуванням, як цих сховищ вибираються 2, і вони можуть бути визначені користувачем.

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

Відбуваються всі комунікації через сховища так:

Залежно від використовуваного сховища, Master Новомосковскет або Heartbeat Region на томі VMFS, або Heartbeat File на томі NFS (який перодіческі оновлюється з боку Slave-хостів). Доступність віртуальних машин контролюється через файл, створювані кожним з Slave-хостів, який містить список запущених ВМ. Координація між Master-ами відбувається за рахунок механізму розподіленої блокування на сховище (майстрів може бути кілька при поділі мережі).

Ось які файли використовує VMware HA на Кадом хості в папці / etc / opt / vmware / fdm:

Ось які загальні для хостів файли використовує VMware HA:

• host-X-hb - heartbeat-файл для хоста, який їм оновлюється, і який перевіряється з боку Master в разі якщо хост виявився ізольованим від мережі управління. Для VMFS томів використовується механізм розподіленої блокування з використанням механізму старіння тимчасових міток, а для томів NFS використовується файл, в якому оновлюється timestamp. Цей файл є тільки на Heartbeat Datastores.
• host-X-poweron - файл, який містить список всіх включених хостів, використовується для того, щоб ізольовані від Management Network хости могли повідомити про свою ізоляції. Цей файл є тільки на Heartbeat Datastores.
• protectedlist - список захищених машин для кожного сховища (лежить не на хості, а на сховище). Саме з цього списку буде проходити їх відновлення в разі відмови Master (в разі відмови Slave - ця інформація є у майстра в пам'яті). Використовується для всіх Datastores.

Файли protectedlist і host-X-poweron використовуються при виконанні дії Isolation Responce і умови поділу мережі.

Перейдемо до станів захищеності віртуальних машин.

Статус віртуальної машини "Protected" в GUI vSphere Client означає, що HA гарантує спробу відновлення віртуальної машини в разі збою. Машина стає захищеною, коли vCenter оповіщається майстром про цей факт. При включенні машини vCenter оповіщає Master про те, що вона включилася, він оновлює список захищених ВМ і повідомляє про це сервера vCenter. При виключенні машини - відбувається зворотний процес.

Тепер включення віртуальної машини відбувається швидше за рахунок того, що їй при старті не потрібно чекати стану protected. Тобто, після старту віртуальна машина буде деякий час залишатися unprotected, поки Master НЕ запише інформацію на диск. Кожні 5 хвилин хост vCenter перевіряє відповідність свого списку захищених ВМ зі списком Master і оновлює список на Master, якщо є відмінності.

Тепер статус Master бачиться у властивостях хоста в vSphere Client:

HA State може бути наступним:

• N / A (HA не налаштований)
• Election (йдуть вибори Master)
• Master (може бути кілька)
• Connected (з'єднаний з Master, тобто він - Slave)
• Network Partitioned
• Network Isolated
• Dead
• Agent Unreachable
• Initialization Error
• Unconfig Error
  

Основні логи VMware HA зберігаються в фалі /var/log/fdm.log на хості ESXi.

Приємно, що тепер все агенти FDM на хостах ставляться паралельно:

При додаванні хоста ESXi в кластер є інтеграція з механізмом VMware Auto Deploy:

При видаленні хоста з кластера або відключенні VMware HA відбувається видалення агентів FDM і очищення службових даних HA на сховищах.

Давайте тепер подивимося на приклади збоїв і їх обробку в VMware HA.

Перший тип збою - поділ мережі

В цьому випадку Master бачить хости через Heartbeat Datastores, але не бачить хости через мережу управління. В цьому випадку в кожному сегменті у нас вийде два хоста Master:

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

Другий сценарій - ізоляція хоста

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

В цьому випадку виконується дія Isolation Response (якщо воно налаштоване і Master може перезапустити ВМ). Якщо встановлено значення за замовчуванням (Leave Powered On), то віртуальні машини продовжують працювати, при цьому вони знаходяться під наглядом з боку сховищ. Якщо і до сховища пропаде доступ хоста - машини перезапустити на інших хостах кластера.

Третій сценарій - збій FDM-агента

Трапляється, коли Master пінг хост, але FDM-агент на ньому не відповідає. При цьому vCenter також з ним з'єднатися не може.

Ця ситуація з'явиться у вигляді Алерта в vSphere Client і нічого не буде зроблено по відношенню до ВМ хоста. Треба буде перевстановити агент FDM.

Четвертий сценарій - повна поломка хоста

В цьому випадку Master не може отримати сигналів доступності від хоста ні по мережі управління, ні по мережі сховищ (не оновлюється timestamps).

В цьому випадку всі захищені віртуальні машини цього хоста будуть перезапущени на інших серверах кластера.

Тепер давайте поглянемо як це виглядає в GUI vSphere Client.

Так виглядають властивості кластера:

Хости Master і Slaves:

Статус захищеності віртуальної машини:

Налаштування Datastore Heartbeating:

Налаштування Admission Control:

Скоро - ще більш докладна інформація про роботу VMware HA. Слідкуйте за новинами.