Особенности работы HA в vSphere 5.0

Duncan Epping выпустил серию статей про механизм High Availability в vSphere 5.0 (ссылка на первую часть), а я попробую перевести их ибо чтиво интересное!

По мере публикации новых статей Duncan’а я буду править эту статью. Поехали…

FDM

Как вы знаете, в VMware Infrastructure 3 / 3.5 и в vSphere 4 / 4.1 за механизм высокой доступности отвечал AAM. Этот продукт был в незапамятные времена приобретен VMware и практически без изменений служил последние лет 5-10.

В vSphere 5.0 его прилично переработали (в сторону большей надежности и простоты) и отребрендили. Теперь он называется Fault Domain Manager. С точки зрения пользовательского интерфейса ничего не поменялось, большинство изменений “под водой”. Например, VMware наконец-то ушли от концепции Primary/Secondary node, накладывающей значительные ограничения на дизайн кластера.

Итак, теперь HA обменивается данными напрямую с Hostd. Ранее, AAM делал это через агента VPXA.

Также FDM-агент “общается” напрямую с vCenter.

В результате мы имеем два достаточно полезных улучшения:

• независимость от DNS
• интеграцию с Syslog.

Остановлюсь чуть-чуть поподробнее на этом.

Предыдущий HA (AAM) отправлял пакеты-сердцебиения хостам, основываясь на их FQDN-именах. Соответственно, при каких-то проблемах с DNS вы автоматически получали проблемы с HA. FDM работает напрямую с IP-адресами.

Второе нововведение касается журналов: теперь нет необходимости лезть в специальную консоль и разыскивать там журналы.

Журнал складируется в /var/log и может быть консолидирован в Syslog.

Primary Nodes

Если вы задавались вопросом дизайна VMware HA-кластера, то слышали про Primary и Secondary узлы. При создании кластера первые 5 узлов становятся первичными, остальные – вторичными. При сбое хоста именно первичный узел определял что и где запускать. В результате, была возможна ситуация, когда все первичные узлы находились в одном шасси, и при сбое шасси помирал весь кластер. Соответственно, существовала и рекомендация – не собирать в одном месте более 4 узлов кластера.

В FDM концепция Primary/Secondary полностью переработана. Встречайте – Master/Slave 🙂

Один из узлов кластера автоматически становится главным, остальные – подчиненные. При сбое главного узла автоматически собираются выборы, в результате которых появляется новый главный узел. К примеру, если у вас есть распределенный кластер, и между площадками потеряна связь – на каждой площадке будет свой главный узел.

Главный узел отвечает за:

• перезапуск виртуальных машин;
• опрос подчиненных узлов;
• отчет о состоянии в vCenter.

Перевыборы главного узла занимают примерно 15 секунд. Сначала проверяется количество подключенных хранилищ. Если есть два хоста с одинаковым количеством хранилищ, сравнивается их “Managed Object ID”.

Вот так будет выглядеть статус кластера:

Изоляция и “частичная изоляция” (partitioning)

Изолированный хост:

• не получает пакеты от главного узла;
• не получает пакеты операции перевыбора;
• не может пинговать адрес изоляции.

Частично изолированный хост:

• не получает пакетов от главного узла;
• получает трафик перевыборов;
• может быть выбран в качестве нового главного узла.

“Пинг” хранилищ

В настройках HA-кластера вы можете заметить новый пункт – “Datastore Heartbeating”.

В предыдущей версии HA изоляцией считалась “неработоспособность” управляющей сети. Соответственно, мог считаться изолированным вполне “работающий” сервер. Благодаря “пингу” хранилища главный узел может более точно определить, изолирован узел или нет.

На скриншоте выше показан рекомендуемый вариант по выбору хранилищ – автоматически vCenter’ом. Также по умолчанию выбирается два хранилища, но вы можете изменить эту настройку через das.heartbeatDsPerHost.

Для “пинга” хранилища HA использует механизм блокировок VMFS или “heartbeat region”. “HR” обновляется пока держится блокировка на файле. Соответственно, чтобы его обновлять, хост должен открыть хотя бы один файл с хранилища.

На скриншоте ниже показаны файлы, создаваемые хостами на хранилище.

Посмотреть, какие хранилища используются для “пинга” можно в статусе кластера.

Перезапуск ВМ

Изменения в перезапуске ВМ коснулись следующего функционала:

• Приоритет перезапуска ВМ;
• Количество попыток перезапуска ВМ;
• Реакция на изоляцию и определение изменений.

Приоритет перезапуска ВМ

1. Агентские ВМ
2. Вторичные виртуальные машины из Fault Tolerance
3. ВМ с высоким приоритетом
4. ВМ со средним приоритетом
5. ВМ с низким приоритетом

Агентские ВМ – это ВМ, содержащие антивирусные движки либо службы сканирования для vShield Edge. Стоит также отметить, если произошел сбой перезапуска какой-то ВМ, остальные продолжат запускаться.

В 4.1 есть следующий недостаток: при перезапуске ВМ перезапускаются с конкретного хоста в соответствии с приоритетами. Если у вас “померли” два хоста, сначала запустятся все ВМ с одного (даже с низким приоритетом перезапуска), и только затем со второго. Duncan не комментирует, изменилось ли это поведение в 5.0.

Количество перезапусков

В vSphere 4.1 был один первичный перезапуск. Количество дальнейших перезапусков ВМ регламентировалось параметром “das.maxvmrestartcount”. По умолчанию это значение равно 5. В vSphere 5.0 количество перезапусков равно 5 без вариантов.

• T0 – первый перезапуск
• T2m – попытка №2
• T6m – попытка №3
• T14m – попытка №4
• T30m – попытка №5

Изоляция и тарам-пам-пам 🙂

В vSphere 4.1 многие использовали параметр “das.failuredetectiontime” в качестве времени, нужного для определения – изолирован хост или нет. Значение по умолчанию – 15 секунд, обычно его увеличивают если есть несколько узлов для проверки изоляции. Так как появился функционал “пинга” хранилища, полезность параметра под вопросом. Второй момент – хост проверяет, дейтствительно ли виртуальные машины могут быть перезапущены, и не происходит ли работ с сетью.

Как подчиненный узел рассматривает изоляцию:

• T0 – происходит изоляция подчиненного узла
• T10s – узел идет в режим выборов
• T25s – узел провозглашает себя главным (Master)
• T25s – узел пингует адрес изоляции
• T30s – узел объявляет себя изолированным

Как главный узел обрабатывает изоляцию:

• T0 – происходит изоляция главного узла
• T0 – узел пингует адрес изоляции
• T5s – узел объявляет себя изолированным

По окончании этого процесса главный узел видит, что другой узел изолирован и  перезапускает виртуальные машины в соответствии с настройками кластера.

Если произойдут “внезапные” работы с сетью, vSphere 5.0 не перезапустит ВМ.