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

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


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

Это первая часть статьи: "vSphere 5: High Availability - Основные Понятия"

В этой статье мы рассмотрим основные понятия, связанные с VMware HA:


  • Master / Slave Nodes
  • Heartbeating
  • Isolated vs Network partitioned
  • Virtual Machine Protection


Master Agent

Одной из главных задач мастер-агента является отслеживание состояния виртуальных машин и принятие решений по их перезапуску в зависимости от ситуации. Также мастер ответственен за обмен информацией с vCenter. В общем, это так или иначе озвучивалось в предыдущих статьях:



Когда мастер-агент берет под свою ответственность виртуальную машину, то он тут же берет во "владение" хранилище, на котором хранятся конфигурационные файлы ВМ. Фактически, мастер - это центральное звено в HA. Поэтому давайте рассмотрим, в каких случаях происходит выбор мастера.


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


  • возникла какая-либо ошибка в работе хоста или мастер-агента
  • сеть разделена или изолирована
  • хост отключён от VC (vCenter)
  • хост введен в режим обслуживания или находится в standby режиме
  • на хосте перенастраивается HA


Весь процесс выбора мастера занимает около 15 секунд, и, при этом, HA не будет реагировать на какие-либо сбои, произошедшие во время выборов. Но, как только мастер будет выбран, сбои, произошедшие до и во время выборов, будут обработаны.

В качестве мастера выбирается хост с наибольшим количеством подключенных к нему датасторов. Если два или более хостов имеют одинаковое количество подключенных к ним хранилищ, то в качестве мастер-хоста будет выбран хост с наибольшим "Managed Object Id".

После выбора мастера slave-агенты устанавливают с ним защищенное (SSL) TCP соединение, и, начиная с этого момента, slave-агенты больше не общаются между собой до следующих выборов.


Как уже писалось немного ранее, когда мастер выбран, он пытается получить во "владение" все хранилища, к которым он может получить прямой или через slave-агента доступ, используя для этого proxy-запрос. Владельцем того или иного хранилища мастер станет только после того, как он заблокирует файл "protectedlist".


Формат имени и расположение этого файла выглядят следующим образом:

3.jpg

Если кому интересно, то "<cluster-specific-directory>" построено по следующей схеме:

4.jpg

Мастер-агент использует данный "protectedlist" файл для хранения списка виртуальных машин, находящихся под защитой HA. Мастер распространяет данный файл на все хранилища, которые используются виртуальными машинами этого кластера (кластера HA). Ниже показан пример файла "protectedlist", расположенного на одном из хранилищ:

ha-protect.jpg

Теперь давайте рассмотрим, что происходит, когда мастер терпит неудачу или изолирован. Если мастер терпит неудачу, то здесь все просто. Блокировка файла "protectedlist" истекает, и новый мастер заблокирует данный файл. В случае изоляции этот сценарий немного отличается, хотя результат аналогичен. Мастер снимает блокировку с файла "protectedlist", тем самым гарантируя, что когда новый мастер будет выбран, он сможет без проблем взять под свою ответственность (путем блокировки файла) виртуальные машины, расположенные на этих хранилищах. Если мастер терпит неудачу в тот момент, когда он уже изолирован, то перезапуск виртуальных машин будет отложен до того момента, пока не появится новый master.


Давайте на секунду представим себе, что ваш мастер потерпел неудачу. Slave-хосты, используя механизм "network heartbeat", определяют, что мастера нет, и тогда начнется процесс выбора мастера. По окончании этого процесса новоиспеченный мастер считывает нужную ему информацию и, в течение 10 секунд, перезапустит "упавшие" виртуальные машины. Перезапуск ВМ - это лишь одна из задач мастера. Мастер также ответственен за мониторинг состояния slave-агентов. Если slave-хост терпит неудачу или становится изолированным, то мастер определяет, какие виртуальные машины должны быть перезапущены, и перезапускает их на работающих хостах.


Slaves

У Slave-агентов существенно меньше обязанностей, чем у мастера. Slave следит за состоянием своих виртуальных машин и оповещает мастера при любых изменениях в их состоянии. Также slave-агент участвует в обмене "heartbeat" сигналами с мастером.


Файлы, используемые Мастером и Слейвом

Мастер и слейв используют файлы не только для того, чтобы сохранять в них состояние ВМ. Еще файлы служат для связи (обмена информацией) между мастером и слейвом. Существует несколько типов файлов, которые используются как мастером, так и слейвом. "Remote Files" представляют собой файлы, хранящиеся на общих датасторах. В то время, как "Local Files" хранятся только локально на хосте и к ним нет общего доступа.


Remote Files

Как мастер, так и слейв создают на shared хранилищах файлы вида:

host-<number>-poweron

В данном файле содержится список, запущенный ВМ на конкретном хосте. Но в этом файле содержится не только эта информация. Slave-агент использует данный файл еще и для того, чтобы оповестить мастера о том, что он изолирован. В начале этого файла хранится информация о том, изолирован ли хост или нет.


  • 0 - означает, что хост не изолирован
  • 1 - хост изолирован


В случае, если слейв считает себя изолированным, то он записывает в начало файла - 1. И, когда мастер обнаруживает это, он сразу же оповещает об этом vCenter.


Local Files

Когда HA-агент конфигурируется на хосте, то он настраивается таким образом, чтобы хранить определенную информацию о своем кластере непосредственно на хосте.

ha-files.jpg

В данных файлах хранится важная информация о состоянии кластера, хостах, которые входят в кластер, матрице совместимости. Эта информация хранится локально на каждом хосте. Данная информация vCenter'ом отправляется мастеру, а мастер, в свою очередь, транслирует её на все slave хосты.


  • clusterconfig - содержит в нечитабельном виде сведения о конфигурации кластера

  • compatlist - содержит актуальную матрицу совместимости для каждой HA защищенной ВМ

  • fdm.cfg - содержит в себе настройки, касающиеся подсистемы логирования

  • hostlist - список хостов, участвующих в кластере (IP, MAC адреса и heartbeat датасторы)