Функции высокой доступности (HA)

Функция высокой доступности (HA) автоматически “перезапускает” (так называемый failover) виртуальную машину на другом нормально функционирующем хосте, если физический хост выходит из строя. Поэтому необходимо заранее подготовить гостевую ОС виртуальной машины, чтобы система могла автоматически восстановиться.

Каковы условия для использования HA?

Для использования HA с версией HRPC KVM должны быть выполнены следующие условия:

1. Виртуальный центр данных, состоящий из трех или более одинаково настроенных узлов.
2. Должен быть тип HCI или 3-уровневый, так как требуется общее хранилище (Ceph, ESF с ES).
3. На оборудовании должно быть достаточно свободной емкости (особенно памяти). Важно, чтобы в общей сложности была свободна память как минимум одного узла.
   *Например, в случае виртуального центра данных, состоящего из трех узлов, в общей сложности должна использоваться память только двух узлов.
4. Убедитесь, что выполняются резервные копии виртуальных машин.
   Мы настоятельно рекомендуем заключить контракт с Backup Storage или аналогичным сервисом и настроить регулярное резервное копирование ваших виртуальных машин.

Как включить функцию HA?

Если вы хотите включить функцию HA, сначала выберите центр данных в левой панели, откройте HA в средней панели и нажмите на “Группа”.

Нажмите кнопку “Создать” в правой панели, создайте идентификатор группы HA и отметьте хосты, связанные с HA. При создании виртуальных машин на хостах, связанных с HA, вы должны подготовить запас памяти, эквивалентный как минимум одному физическому хосту. Если вы участвуете в HA с четырьмя HRPC, оснащенными 768 ГБ памяти, оставшиеся три машины должны иметь 768 ГБ свободной памяти, чтобы другие устройства могли продолжать работать, даже если один HRPC выходит из строя. Если вы не отметите группу HA, она будет игнорироваться как цель HA, даже если находится в том же центре данных.

Если хост намеренно удален из группы HA, и настройка группы HA “ограничена” отмечена, виртуальные машины, принадлежащие этой группе HA, не могут быть запущены на удаленном хосте.

Если отмечено nofailback, при перезапуске и возвращении сбойного физического узла виртуальные машины не будут восстановлены, а продолжат работать на новом месте. Если nofailback не отмечено, они будут возвращены на исходный узел с помощью живой миграции, что позволяет строго управлять размещением узлов хостов и виртуальных машин. Однако, если физический узел становится нестабильным и многократно перезагружается, HA будет активирована снова, и виртуальные машины будут многократно перезапускаться. По этой причине мы рекомендуем отмечать nofailback.

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

Как включить HA для виртуальной машины?

HA в Proxmox не будет применяться, если виртуальная машина не находится под управлением HA.

Чтобы поместить виртуальную машину под управление HA, выберите виртуальную машину и выберите “Управление HA” из выпадающего меню “Больше▼” в правом верхнем углу. Выберите идентификатор настроенной выше группы HA из списка, установите желаемое состояние как “запущено” и нажмите кнопку “Добавить”.

Теперь эта виртуальная машина находится под контролем HA.

Область действия HA зависит от гипервизора. В VMware, когда HA включена в виртуальном центре данных, это влияет на все виртуальные машины в центре данных, тогда как в XenOrchestra это затрагивает только виртуальные машины в пуле, для которых включена HA и установлен “перезапуск”.

Взаимосвязь между плановой перезагрузкой узлов (хостов) в группе HA и виртуальными машинами

Когда узел, входящий в группу HA, перезагружается для обслуживания (не из-за неожиданного сбоя), поведение виртуальных машин будет различаться в зависимости от того, находятся ли они под управлением HA.

Виртуальные машины под управлением HA	Живая миграция на другую машину
Виртуальные машины, не управляемые HA	Автоматически выключаются и остаются выключенными после перезагрузки

Колонка

Ограничения функции HA

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

1. Непредвиденный перезапуск виртуальной машины
2. Повреждение данных виртуальной машины

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

Во-первых, невозможно строго определить, что считается “сбоем” конкретного узла среди всех трех узлов (например, узел A, узел B и узел C). HA достигается за счет скоординированной работы каждого узла с другими.

Когда узел A теряет связь с узлом B, неясно, произошел ли сбой в узле B или просто потеряна связь между узлом A и узлом B. Если узел A может связаться с узлом C, можно предположить, что сбой произошел в узле B.

Однако, если данные виртуальных машин, размещенных на узле B, постоянно обновляются в общем хранилище, узел B может быть полностью изолирован.

В приведенном выше примере, если узлы A и C находятся в связи, высока вероятность, что узел B вышел из строя. Поэтому узлы A и C попытаются самостоятельно запустить виртуальные машины, размещенные на узле B.

Однако узел B, возможно, не вышел из строя, а просто изолирован. Если узел определяет, что он изолирован, он немедленно выключает размещенные на нем виртуальные машины, чтобы узлы A и C могли начать их запуск, что и вызывает упомянутый выше неожиданный перезапуск.

Что произойдет, если узел B не выключится?

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

Таким образом, ваш выбор — либо перезагрузка, либо уничтожение данных.

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

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

Это решение принимается с интервалами, и Proxmox делает это каждые 2 минуты. Если ответа нет в течение 2 минут, определяется, что “хост вышел из строя”. Таким образом, как минимум, время простоя составит 2 минуты + время, необходимое для запуска виртуальной машины (на практике это займет больше времени).

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