Данная статья является очень кратким конспектом соответствующ(их/ей) глав(ы) книги:

" vSphere 5 Clustering Technical Deepdive (Authors: Duncan Epping, Frank Denneman) ".


Купить eBook (Kindle) версию книги (~12$) вы можете на сайте Амазона (amazon.com)

Это заключительная часть статьи: "vSphere 5: High Availability - Основные Понятия"

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

Heartbeating

На данный момент существуют только два способа обмена "heartbeat" сигналами в HA кластере. Первый способ - через сеть управления (management network), ну и второй - с использованием хранилищ. Немного ниже мы достаточно кратко рассмотрим эти два способа обмена "heartbeat" сигналами в VMware HA кластере.


Network Heartbeating

Этот механизм является самым простым для определения того, "жив" ли хост или нет. Мастер и slave-хосты каждую секунду обмениваются (master <-> slave) между собой "heartbeat" сигналами. И, в зависимости от того, получен ли "heartbeat" сигнал, предпринимается то или иное действие на хосте VMware ESXi.


Datastore Heartbeating

Это новый механизм, появившийся в VMware vSphere 5.0. Данный механизм позволяет исключить ситуацию, когда сеть управления на хосте недоступна, и из-за этого виртуальные машины, которые могут вполне себе нормально работать, будут перезапущены.

Механизм "Datastore Heartbeating" используется только тогда, когда хост не доступен через сеть управления (management network).

Итак. Допустим, произошла изоляция хоста. Как мастер узнает о том, что хост изолирован? Да все достаточно просто. Мастер будет проверять "poweron"-файл на хранилище, который slave-агент должен обновить, занеся в его первую строку значение "1".

Для получения дополнительной информации о "poweron"-файле вы можете обратиться к ранее опубликованной первой части этой статьи.

После того, как мастер поймет, что хост изолирован, его дальнейшие действия будут зависеть от значения параметра "isolation response", заданного при настройке кластера HA. Если в "isolation response" указано "Leave powered on", то slave-хост и мастер ничего предпринимать не будут. Виртуальные машины так и будут продолжать работать на изолированном хосте. Если в "isolation response" указано "Power off" или "Shut down", то изолированный хост потушит свои ВМ, а мастер, после того как убедится в том, что виртуальные машины выключены (проверив "poweron"-файл), инициирует процесс перезапуска ВМ на других хостах кластера HA.


А теперь давайте представим, что хост, будучи изолированным, выходит из строя. Как мастеру узнать, что хоста больше нет, и что нужно перезапускать виртуальные машины, работавшие на нем? Для этого существует специальный файл,

host-<number>-hb

d-hb.jpg

который хост должен держать постоянно открытым. На самом деле, хосту необязательно держать постоянно открытым именно этот файл. Если хостом будет открыт любой другой файл, то мастер поймет, что хост жив. Дело все в том, что для отслеживания того, что хост жив, используются стандартные механизмы ФС VMFS. В частности, используется так называемый "heartbeat region", который постоянно обновляется, пока у хоста есть хотя бы один открытый файл на томе VMFS.

Если файл "host-<number>-hb" находится на NFS хранилище, то хост должен его обновлять каждые пять секунд. Иначе мастер поймет, что хост вышел из строя.

По умолчанию HA в качестве "heartbeat datastores" выбирает только 2 хранилища. Если вы считаете, что этого мало, вы можете увеличить это значение при помощи этого параметра: "das.heartbeatDsPerHost".


Isolated versus Partitioned

Если хост изолирован, то он:


  • не получает "heartbeat" сигналы от мастера
  • не получает любой трафик по выбору мастера (election traffic)
  • не пингует проверочный IP адрес (isolation address)


Если хост разделен (partitioned), то он:


  • не получает "heartbeat" сигналы от мастера
  • получает трафик по выбору мастера

На какое-то время в разделенной сети будет выбран новый мастер, и vCenter'у будет об этом сообщено.

scheme.PNG

Если у вас сеть разбивается на несколько сегментов, то в каждом сегменте будет происходить выбор мастера. Но как только сеть управления снова заработает, в сети останется только один мастер, который, в дальнейшем, и будет всем заправлять.


Может случиться так, что мастер в разделенной сети может взять под свою ответственность виртуальные машины, расположенные на хостах ESXi в другой разделенной сети. В этом нет ничего страшного. Если с ВМ в другой разделенной сети что-нибудь случится, мастер об этом будет уведомлен через "datastore communication" механизм. В случае, если хост (на котором работает защищенная мастером ВМ) в разделенной сети выйдет из строя, то мастер сразу же узнает об этом через "datastore heartbeat" механизм.

Если в кластере HA, например, случилось что-то со slave-хостом, то оставшиеся узлы кластера не перезапустят у себя виртуальные машины до тех пор, пока мастер не убедится в том, что хост вышел из строя или стал изолированным, и сработало действие, заданное в "isolation response".


Существует еще один очень интересный момент. Будучи изолированным, хост, перед тем, как что-либо делать со своими виртуальными машинами, проверит наличие блокировки на файле "protectedlist". Если хост увидит, что блокировки на этом файле нет, то, вне зависимости от того, что за действие установлено в "isolation response", с виртуальными машинами не будет ничего сделано. То есть они будут продолжать работать. Зачем это сделано? Дело в том, что если нет блокировки на файле "protectedlist", то это означает, что на данный момент мастер-хоста не существует, а это, в свою очередь, означает что некому будет перезапустить виртуальные машины.


Virtual Machine Protection

  • Защита виртуальной машины:

vm-protect.jpg

  • Снятие защиты с виртуальной машины:

vm-unprotect.jpg