Кластер High Availability (высокой доступности) это то, ради чего многие и внедряют платную виртуализацию. Когда на сервере ESXi работает несколько виртуальных машин, файлы этих машин лежат на локальных дисках или даже на системе хранения данных, а кластер не создан, и вдруг этот сервер выходит из строя. Тогда все выключается и ждет пока человек вмешается в процесс. А Человек — системный администратор спит дома и на работу скорее всего опаздает задержется, и в дороге ему начнут звонить недовольные и спрашивать когда, когда… Вот для таких случаев и настраивается HA Cluster. С ним все происходит автоматически, один сервер ESXi выходит из строя — ВМ, которые были запущены на нем, перезапускаются на другом сервере кластера. И еще одно применение HA, если гостевая операционная система внутри виртуальной машины зависает и перестает отвечать на запросы, такая ВМ автоматически перезапускается. Вот этот функционал я и покажу в текущей статье.

Естественно, все не так просто, и перед HA , было произведено немало настроек, посмотреть можно тут.

1

У меня тут два сервера ESXi, которые управляются через vCenter server. Создано 2 виртуальные машины, файлы которых лежат на LUN-е системы хранения данных FreeNAS (все это было описано ранее). И я создаю новый кластер.

2

Название кластера, и галочка только напротив HA. Про DRS будет отдельная статья.

3

Host Monitoring status — это основной механизм в HA, отслеживает состояние серверов ESXi и по результату данного мониторинга происходят уже действия, такие как перезапуск виртуальных машин, например.
Admission Control — если в кластере HA может не хватить ресурсов для запуска виртуальных машин с вышедшего из строя сервера ESXi то лишние виртуальные машины не даст запустить Admission control (надеюсь понятно). А вот сколько сервером может выйти одновременно из строя серверов указывается через Admission control policy (по умолчанию 1).
Альтернативно можно также настроить политику, чтобы она  оставляла ресурсы CPU и памяти. Но многие администраторы сразу отключают этот искуственный контроль — раздражает сильно. 

4

тут все по-умолчанию

5

VM Monitoring — как только Windows (например) внутри виртуальной машины вылетает в BSOD, VM Monitoring отслеживает, что ОС не отвечает на запросы и перезагружает ВМ.

6

EVC — encahced vMotion compatibility — если у вас разные процессоры в серверах ESXi или разное количество ядер, то процесс миграции виртуальной машины vMotion может закончиться неудачей. Такие серверы добавить в кластер HA с ВЫключенной EVC не получится. EVC приводит серверы к общему знаменателю, чтобы они могли работать в кластере и обеспечивать отказоустойчивость. EVC в основном смотрит на процессор, понижая функциональность всех процессоров до самого слабого в кластере.  

7

Сохранять файл подкачки в папке виртуальной машины.

8

Все готово, кластер почти создан

9

Создан успешно. Слева вверху видим сам кластер и наши ESXi серверы отдельно. Теперь нужно перенести хосты в кластер. Действуем мышкой, Drug-and-Drop

10

На каждый сервер ESXi во время добавления в кластер устанавливается агент HA. Если интересно, как именно работает, HA, как установленные агенты обмениваются информацией и устравают выборы мастера, погуглите. Мне важно, что HA работает теперь лучше чем в VMware vSphere 4.1

11

Теперь чтобы посмотреть, на каком из серверов ESXi в данный момент работает виртуальная машина, нужно смотреть в ее свойства. WinXp закреплена за 106 хостом.

12

Пришло время проверить, как работает кластер высокой доступности HA, выключаем один из хостов.

13

Да мы уверены, что хотим выключить, хоть он и не в Maintenance mode. Этот режим нужен, чтобы корректно выводить сервер из эксплуатации, чтобы нечаянно не погасить ВМ, а мне именно это и нужно сейчас.

14

Выключаешь, укажи причину.

15

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

16

Отвалился ESXi хост

17

WinXP почти вернулся в сторой.

18

Вернулся, работает.

19

Видим что запустился WindowsXP на 115 хосте.

20

Включил обратно хост 106, но виртуальные машины остались на 115. Чтобы они вернулись обратно нужно делать миграцию vMotion руками . Чтобы они вернулись автоматически требуется DRS.

21

Давайте уберем надоедливую ошибку "This host currently has no management network redundancy", она говорит о том, что вся отказоустойчивость у нас кончается на одной единственной сетевой карточке. Можно двумя путями пойти, добавить второй сетевой интерфейс (на 106 хосте так сделаю) или просто отключить ошибку, чтобы не отображаласть (для всего кластера).

22

Заходим в настройки виртуального коммутатора vSwitch0

23

Во вкладке Network Adapters -> Add

24

Выбираю свободный сетевой интерфейс vmnic1

25

В этой вкладке можно указать, какие сетевые интерфейсы будут активны, а какие будут в запасе, ждать пока активные сломаются.

26

почти готово

27

Готово, две сетевые карты подключены к виртуальному коммутатору, а ошибка все так же горит.

28

Чтобы кластру стало понятно, что этот хост теперь заполучил нормальную отказоустойчивость, необходимо его переконфигурировать.

29

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

30

Заходим в настройки кластера

31

нужна кнопка Advanced Options

32

прописываем ручками параметр das.ignoreRedundantNetWarning  true

33

И конечно Reconfigure for vSphere HA

34

Теперь данной ошибки не будет вообще, никогда, в этом кластере.