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

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


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

VMware vSphere High Availability будет пытаться перезапустить защищенные виртуальные машины только тогда, когда произойдет одно из следующих событий:


  • Хост вышел из строя
  • Хост изолирован
  • Ошибка в гостевой ОС


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


Restart Priority and Order

В VMware vSphere 5, HA будет перезапускать виртуальные машины в следующем порядке:


  • Агентские (Agent) виртуальные машины
  • FT (Fault Tolerance) secondary виртуальные машины
  • Виртуальные машины с высоким приоритетом (high) перезапуска
  • Виртуальные машины со средним (medium) приоритетом перезапуска
  • Виртуальные машины с низким (low) приоритетом перезапуска


Как мы видим, VMware HA в первую очередь будет пытаться перезапустить агентские виртуальные машины (хорошим примером здесь будет "vShield Endpoint"). Затем - FT secondary ВМ, ну, а дальше, как доктор прописал - виртуальные машины c "high", "medium" и "low" приоритетами. В случае, если по каким-либо причинам агентскую ВМ не удается запустить, повторный её запуск будет произведен чуть позже. Ну, а в это время, VMware HA будет выполнять перезапуск других ВМ. То есть, в случае, если не получается запустить агентскую ВМ, HA не застопорится на этом, а будет и дальше продолжать перезапускать другие ожидающие перезапуска ВМ.


Restart Retries

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


  • T0 – Initial Restart
  • T2m – Restart retry 1
  • T6m – Restart retry 2
  • T14m – Restart retry 3
  • T30m – Restart retry 4


А теперь представьте себе ситуацию, когда мастер-хост, допустим, в третий раз выполняющий перезапуск ВМ, выходит из строя. Что тогда? Тут все предельно просто. Когда новый мастер будет выбран, он начнет перезапуск виртуальной машины с T0. Т.е., предыдущая последовательность перезапуска этой ВМ сбрасывается.


Когда дело доходит до перезапуска виртуальных машин, VMware HA не будет выдавать больше 32 одновременных "power-on" задач на хост. Например, если в HA кластере есть только два хоста, и если второй хост, на котором запущено 33 ВМ с одним и тем же приоритетом, выходит из строя, то HA на первый хост выдаст только 32 одновременных "power-on" задачи. А вот 33-я ВМ сможет запуститься только после того, как хотя бы одна из предыдущих 32 задач успешно выполнится или завершится с ошибкой.


Если нужно перезапустить 32 виртуальные машины с низким приоритетом и одну ВМ с высоким приоритетом, то HA, как и положено, сначала отдаст команду хосту на запуск ВМ с высоким приоритетом, но при этом, как это уже было написано чуть выше, HA не будет ждать, пока ВМ с высоким приоритетом запустится, и отдаст еще 31 команду на запуск других ВМ с более низким приоритетом. То есть, теоретически возможно, что в случае неудачного запуска ВМ с высоким приоритетом, виртуальные машины с более низким приоритетом могут запуститься раньше, чем ВМ с более высоким приоритетом.


Вот теперь, когда мы рассмотрели порядок, приоритет и количество попыток перезапуска ВМ, самое время рассмотреть различные сценарии, такие как выход из строя мастера, слейва или изоляция хоста.


The Failure of a Slave

Когда slave-хост выходит из строя, то сценарий будет следующим:


  • T0 – Slave-хост выходит из строя
  • T3s – Мастер начинает мониторинг "datastore heartbeats" в течение 15 секунд

  • T10s – Хост помечается как "недоступный (unreachable)", и мастер начинает через management network пинговать вышедший из строя хост

Этот непрерывный пинг будет генерироваться на протяжении 5 секунд.

  • T15s – Если "heartbeat" датасторы не были сконфигурированы, то хост ESXi объявляется "мертвым" (dead), и начинается процесс перезапуска виртуальных машин

  • T18s – Если "heartbeat" датасторы БЫЛИ сконфигурированы, то хост ESXi объявляется "мертвым" (dead), и начинается процесс перезапуска виртуальных машин


Для лучшего понимания, вот вам диаграмма:

slave-failure.jpg

Теперь давайте рассмотрим сценарий, при котором мастер-хост выходит из строя.


The Failure of a Master

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


  • T0 – Мастер вышел из строя
  • T10s – Инициируется процесс выбора мастера
  • T25s – Мастер выбран и считывает файл "protectedlist"
  • T35s – Новый мастер инициирует процесс перезапуска всех на данный момент не запущенных виртуальных машин, находящихся в файле "protectedlist" (то есть, защищенных VMware HA).


Диаграмма для лучшего понимания:

master-failure.jpg

Как вы можете видеть, отказ мастер-хоста влечет за собой более длительный простой в работе виртуальных машин, чем отказ слейв хоста. Но это и логично. Ведь мастер, это ж не слейв :0).


Isolation Response and Detection

Isolation Response

Про "Isolation Response" у меня уже есть ранее написанная статья: "VMware vSphere 5 HA - Isolation Response". Здесь же я опишу только то, чего нет в моей статье. Итак. Когда действие "Isolation Response" срабатывает, хост удаляет из файла "poweron" выключенные виртуальные машины. Мастер узнает о том, что виртуальные машины исчезли (были выключены) и инициирует процесс перезапуска этих ВМ.


Кроме того, когда все же срабатывает действие, заданное в "Isolation Response", то для каждой виртуальной машины будет создан соответствующий файл в каталоге "poweredoff". По наличию этого файла мастер будет знать, что виртуальная машина была выключена именно в результате срабатывания действия "Isolation Response".


Isolation of a Slave

  • T0 – Происходит изоляция хоста (слейва)
  • T10s – Slave переходит в состояние выборов
  • T25s – Slave избирает себя, как мастер
  • T25s – Slave пингует "isolation addresses"
  • T30s – Slave объявляет себя изолированным и выполняет действие "Isolation Response"


После завершения этой последовательности мастер, через "poweron" файл, узнает, что slave был изолирован, и далее мастер будет действовать, основываясь на информации, предоставляемой слейвом.


Isolation of a Master

  • T0 – Происходит изоляция хоста (master)
  • T0 – Master пингует "isolation addresses"
  • T5s – Master объявляет себя изолированным и выполняет действие "Isolation Response"


Additional Checks

Для того, чтобы уменьшить количество ложных срабатываний, вы можете, с помощью параметра "das.isolationaddress", добавить несколько, а, конкретнее, до 10 проверочных адресов изоляции (isolation addresses), которые хост будет пинговать.

isol-address.jpg

С этим разобрались, теперь переходим к самому интересному - к перезапуску ВМ.


Restarting Virtual Machines

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


Прежде чем мастер приступит к перезапуску ВМ, он будет ждать около 10 секунд. Это сделано для того, чтобы в случае, если в это время выйдет из строя другой хост ESXi, обработать все виртуальные машины с этих двух, трех или более хостов одним разом. Однако, прежде чем мастер инициирует процесс перезапуска ВМ, он убедится в том, что владеет хранилищем, на котором располагаются файлы перезапускаемой ВМ. Если мастер по каким-либо причинам не владеет этим хранилищем, то он пропустит (отфильтрует) данные ВМ.


И вот, после всех этих действий, VMware HA имеет список виртуальных машин, нуждающихся в перезапуске. Осталось только определиться, где разместить виртуальные машины, в смысле, в каком порядке и на каком именно хосте, перезапустить ту или иную ВМ. Для этого VMware HA берет во внимание следующее:


  • Резервирование по CPU и memory, в том числе и memory overhead для этой ВМ
  • Количество незарезервированной мощности на хосте, входящем в кластер
  • Приоритет перезапуска относительно других нуждающихся в перезапуске ВМ
  • VM-to-Host список или еще по-другому, матрицу совместимости
  • Количество dvPorts, необходимых для ВМ и доступных на хосте-кандидате
  • Максимальное количество vCPU и ВМ, которые могут работать на этом хосте
  • Restart latency


Restart latency - относится к количеству времени, которое требуется для начала перезапуска ВМ. Перезапуск виртуальных машин мастером распространяется на несколько хостов, что позволяет избежать возникновения чрезмерной нагрузки на одном хосте и, следовательно, чрезмерной задержки.


Если место для размещения ВМ найдено, мастер пошлет на каждый целевой хост определенный набор виртуальных машин, которые необходимо перезапустить, но, заметьте, что не больше 32-х перезапускаемых ВМ на каждый хост. Если виртуальная машина успешно запускается на хосте, то хост сообщит мастеру об этом, и мастер удалит эту ВМ из списка: "restart list".


Если HA не может найти хост для размещения ВМ, то мастер помещает эту ВМ с список "pending placement list". И после этого HA вернется к этой виртуальной машине только тогда, когда произойдет одно из следующих событий:


  • vCenter предоставит новый VM-to-Host список совместимости (матрицу)
  • Хост сообщит о том, что незарезервированная мощность увеличилась
  • Хост присоединился или переподсоединился к кластеру

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

  • Обнаружен новый сбой, при котором пострадали виртуальные машины
  • Произошел какой-либо сбой во время сбоя виртуальной машины (англ. вариант см. ниже)

A failure occurred when failing over a virtual machine


Мастер постоянно отчитывается перед vCenter о виртуальных машинах, которые не удается нигде разместить. И, если для кластера включен DRS, то данная информация будет использована при балансировке нагрузки с целью обеспечить необходимое количество ресурсов для ожидающих перезапуска виртуальных машин.


Split-Brain Scenario

Начиная с версии 4.0 Update 2, если ESXi обнаруживает, что блокировка на VMDK файл была потеряна, то HA автоматически выключит эту виртуальную машину. Это, как раз, и помогает избежать сценария, когда существует две включенные ВМ, то есть того самого пресловутого "Split-Brain" сценария.