Proxmox

Настройка High Availability для виртуальной машины в Proxmox VE

Пошаговая настройка High Availability для виртуальной машины в кластере Proxmox VE: HA groups, resource state, watchdog, failover и проверка.

High Availability в Proxmox VE позволяет автоматически перезапустить виртуальную машину на другом узле кластера, если текущий узел становится недоступен.

В этой инструкции рассматривается только добавление одной VM в HA, создание HA group и базовая проверка failover.

Подходит для: Proxmox VE 8 и 9
Уровень сложности: высокий
Время выполнения: около 30–60 минут
Требуемый доступ: права управления HA, кластером и виртуальной машиной

Важное предупреждение

HA не заменяет резервное копирование.

High Availability защищает от отказа узла, но не защищает от:

повреждения данных внутри VM;
ошибочного удаления файлов;
шифровальщика;
сбоя приложения;
отказа всех узлов;
повреждения общего storage;
некорректной репликации.

Перед настройкой HA должны существовать отдельные резервные копии и проверенная процедура восстановления.

Что будет настроено

После выполнения инструкции:

будет проверен quorum;
будет проверено состояние HA-служб;
будет создана HA group;
VM будет добавлена как HA resource;
будет задано желаемое состояние started;
будет проверена возможность запуска на другом узле;
будет выполнен контролируемый failover;
будут разобраны типичные ошибки.

Требования к HA

Для работы HA необходимы:

Proxmox-кластер;
стабильный quorum;
минимум три голоса или QDevice;
одинаковые network bridge на узлах;
доступность storage на целевых узлах;
совместимые CPU;
работающий watchdog;
HA-совместимая конфигурация VM;
отсутствие привязки к локальным устройствам.

Минимальная рекомендуемая схема

Практичный вариант:

3 узла Proxmox VE
Общий storage или ZFS replication
Отдельная cluster network
Watchdog
Резервные копии

Двухузловой кластер без QDevice не является устойчивой основой для HA.

Проверка кластера

pvecm status

Проверьте:

Quorate: Yes

Покажите узлы:

pvecm nodes

Все узлы, участвующие в HA, должны быть online.

Проверка HA-служб

На каждом узле:

systemctl status pve-ha-lrm --no-pager
systemctl status pve-ha-crm --no-pager

Ожидаемый статус:

active (running)

Проверьте:

ha-manager status

Что делают HA CRM и LRM

pve-ha-crm

Cluster Resource Manager принимает решения:

где должен работать ресурс;
какой узел выбрать;
когда выполнить recovery;
как учитывать HA group.

pve-ha-lrm

Local Resource Manager выполняет действия на конкретном узле:

start;
stop;
migrate;
freeze;
recovery.

Проверка watchdog

HA использует watchdog для fencing.

Проверьте:

ls -l /dev/watchdog*

Проверьте журнал:

journalctl -u pve-ha-lrm   -n 100   --no-pager

Для программного watchdog может использоваться:

softdog

Проверьте модуль:

lsmod |
grep softdog

Почему нужен watchdog

При потере quorum узел должен прекратить работу HA-ресурсов, чтобы избежать split-brain.

Watchdog обеспечивает fencing: если HA-служба перестаёт подтверждать нормальное состояние, узел перезагружается.

Не отключайте watchdog в HA-кластере без понимания последствий.

Проверка VM

qm status VM_ID

Покажите конфигурацию:

qm config VM_ID

Проверьте:

storage;
network bridge;
CPU type;
PCI passthrough;
USB passthrough;
local ISO;
локальные диски;
replication job.

Проверка storage

pvesm status

Для HA VM должен быть выполнен один из вариантов:

Shared storage
ZFS replication
Ceph RBD
NFS
iSCSI

Если диск существует только на одном локальном storage без replication, другой узел не сможет запустить VM.

Проверка дисков VM

qm config VM_ID |
grep -E '^(scsi|virtio|sata|ide|efidisk|tpmstate)[0-9]*:'

Убедитесь, что каждый необходимый диск доступен на всех допустимых HA-узлах.

Проверка локальных устройств

qm config VM_ID |
grep -E '^(hostpci|usb|args|serial|parallel)'

PCI passthrough и USB passthrough обычно делают VM зависимой от конкретного узла.

Такую VM нельзя считать полноценно HA-ready.

Проверка CPU type

qm config VM_ID |
grep '^cpu'

Для миграции между разными узлами лучше использовать совместимую модель CPU, а не:

host

если процессоры узлов различаются.

Проверка bridge

qm config VM_ID |
grep '^net'

На каждом узле проверьте:

ip link show vmbr0

Имена bridge и VLAN должны совпадать.

Создание HA group

В веб-интерфейсе откройте:

Datacenter → HA → Groups

Нажмите:

Add

Укажите имя:

production-ha

Добавьте узлы.

Пример:

pve01
pve02
pve03

Приоритет узлов

Для каждого узла можно задать priority.

Пример:

pve01: 100
pve02: 80
pve03: 60

Чем выше значение, тем предпочтительнее узел.

При одинаковом priority HA выбирает подходящий узел по внутренней логике.

Restrict group

Параметр:

restricted

ограничивает запуск ресурса только узлами группы.

Если restricted отключён, Proxmox VE при необходимости может использовать другие доступные узлы кластера.

Для production-сервисов группу часто делают restricted, если только выбранные узлы имеют нужные storage, VLAN и CPU.

Nofailback

Параметр:

nofailback

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

Если nofailback включён:

VM останется на текущем рабочем узле;
не будет лишней обратной миграции;
уменьшается число автоматических перемещений.

Для многих production-сценариев это удобно.

Создание группы через CLI

Покажите справку:

ha-manager groupadd --help

Пример:

ha-manager groupadd production-ha   --nodes pve01:100,pve02:80,pve03:60   --restricted 1   --nofailback 1

Проверьте:

ha-manager config

Добавление VM в HA

В веб-интерфейсе:

Datacenter → HA → Resources

Нажмите:

Add

Выберите:

VM: 100
Group: production-ha
State: started

Добавление через CLI

ha-manager add vm:VM_ID   --group production-ha   --state started

Пример:

ha-manager add vm:100   --group production-ha   --state started

Проверьте:

ha-manager config

Состояния HA resource

Основные состояния:

started
stopped
disabled
ignored

started

HA должен поддерживать VM в запущенном состоянии.

stopped

HA должен поддерживать VM остановленной.

disabled

Ресурс остаётся в конфигурации HA, но автоматическое управление отключено.

ignored

HA не предпринимает действий, даже если VM запущена или остановлена вручную.

Используйте ignored только для временного обслуживания и с пониманием последствий.

Проверка статуса

ha-manager status

Пример логики вывода:

service vm:100 started on pve01

Проверьте также:

qm status 100

Проверка HA-конфигурации

cat /etc/pve/ha/groups.cfg

cat /etc/pve/ha/resources.cfg

Не редактируйте эти файлы вручную без необходимости.

Перевод ресурса в started

ha-manager set vm:100   --state started

Проверьте:

ha-manager status

Ручная миграция HA resource

Для контролируемого переноса используйте HA-команду:

ha-manager migrate vm:100 pve02

Следите:

ha-manager status

Обычная qm migrate для HA-managed VM может привести к конфликту с HA-логикой.

Relocate

Для остановленного ресурса или специального сценария используется relocation.

Проверьте справку:

ha-manager relocate --help

Пример:

ha-manager relocate vm:100 pve02

Проверка приложения после миграции

Проверьте:

ping -c 3 VM_IP

ssh ADMIN_USER@VM_IP

Для веб-сервиса:

curl -I http://VM_IP

Проверьте приложение, storage и QEMU Guest Agent.

Контролируемый тест failover

Безопаснее сначала выполнить ручную HA migration.

После этого можно проверить поведение при обслуживании узла.

Не отключайте питание production-узла без согласованного окна.

Maintenance mode узла

Перед обслуживанием используйте режим maintenance, если он доступен в текущей версии и конфигурации.

Проверьте команды:

ha-manager crm-command node-maintenance enable NODE_NAME

Показать справку:

ha-manager crm-command --help

После включения maintenance HA должен переместить ресурсы с узла.

Проверка maintenance

ha-manager status

Проверьте, что ресурсы ушли на другие узлы.

Затем можно обслуживать или перезагружать исходный узел.

Выход из maintenance

ha-manager crm-command node-maintenance disable NODE_NAME

Проверьте:

ha-manager status

При nofailback=1 ресурсы могут не вернуться автоматически.

Аварийный failover

При реальном отказе узла HA:

обнаруживает потерю узла;
ждёт fencing;
подтверждает quorum;
выбирает целевой узел;
запускает ресурс;
обновляет состояние.

Процесс не является мгновенным.

Почему failover занимает время

На длительность влияют:

Corosync detection;
watchdog fencing;
storage readiness;
время загрузки VM;
время запуска приложения;
fsck;
database recovery;
healthcheck приложения.

HA запускает VM, но не гарантирует мгновенную готовность приложения.

Проверка журналов HA

CRM:

journalctl -u pve-ha-crm   -n 200   --no-pager

LRM:

journalctl -u pve-ha-lrm   -n 200   --no-pager

Corosync:

journalctl -u corosync   -n 200   --no-pager

Проверка ошибок

ha-manager status

Ищите состояния:

error
fence
freeze
stopped
unknown

Не перезапускайте службы HA вслепую без анализа причины.

Очистка error state

После устранения причины может потребоваться отключить и снова включить ресурс.

Пример:

ha-manager set vm:100   --state disabled

Затем:

ha-manager set vm:100   --state started

Сначала проверьте storage, quorum и состояние VM.

HA и backup

HA не отменяет backup.

Для HA VM настройте отдельное расписание резервного копирования на storage, не зависящее от одного узла.

Периодически выполняйте тестовое восстановление.

HA и ZFS replication

При local ZFS HA обычно сочетается с replication job.

Проверьте:

pvesr status

При failover VM запускается с последней доступной реплики.

Возможна потеря данных после последней успешной синхронизации.

HA и shared storage

На shared storage VM может запускаться на любом узле, имеющем доступ к storage.

Проверьте:

pvesm status

Storage должен быть active на всех узлах HA group.

HA и базы данных

Перезапуск VM на другом узле не гарантирует целостность базы данных.

Для критичных СУБД нужны:

WAL или binlog replication;
application-level failover;
fencing базы данных;
регулярные дампы;
тест восстановления.

HA и application health

Proxmox HA отслеживает состояние VM, а не бизнес-функцию приложения.

VM может быть running, но приложение внутри неё — недоступно.

Используйте внешнее наблюдение:

Zabbix;
Prometheus;
HTTP checks;
database checks;
synthetic monitoring.

Проверка автозапуска

HA-managed resource не должен управляться только параметром onboot.

Проверьте:

qm config VM_ID |
grep '^onboot'

Главным механизмом запуска становится HA state.

Не создавайте противоречивые схемы управления.

Остановка HA VM

Для плановой остановки:

ha-manager set vm:100   --state stopped

Не используйте только:

qm stop 100

HA может воспринять это как отклонение от желаемого состояния и запустить VM снова.

Временное отключение HA

ha-manager set vm:100   --state disabled

После обслуживания:

ha-manager set vm:100   --state started

Удаление VM из HA

ha-manager remove vm:100

Проверьте:

ha-manager config

Удаление из HA не удаляет саму VM.

Удаление HA group

Сначала убедитесь, что группа не используется ресурсами.

Проверьте:

ha-manager config

Удалите:

ha-manager groupremove production-ha

Типичные проблемы

Resource state error

Проверьте:

ha-manager status

Затем:

pvesm status
pvecm status
qm status VM_ID

VM не запускается на другом узле

Проверьте:

storage;
replication;
bridge;
VLAN;
CPU;
PCI passthrough;
USB passthrough;
local ISO;
EFI и TPM volumes.

HA не может мигрировать VM

Проверьте конфигурацию:

qm config VM_ID

Особенно:

hostpci
usb
local storage
cpu: host

После отказа узла VM не стартует

Проверьте quorum:

pvecm status

Проверьте fencing и watchdog:

journalctl -u pve-ha-lrm   -n 200   --no-pager

Проверьте целевой storage.

VM постоянно возвращается на первый узел

Отключите failback:

nofailback=1

или измените приоритеты HA group.

VM запустилась, но приложение недоступно

Проверьте внутри гостя:

systemctl --failed
journalctl -b -p err --no-pager

Проверьте application dependencies и database recovery.

Безопасный порядок настройки

Проверить backup.
Проверить quorum.
Проверить HA-службы.
Проверить watchdog.
Проверить storage или replication.
Проверить bridge и VLAN.
Проверить отсутствие passthrough.
Создать HA group.
Добавить VM в HA.
Проверить ha-manager status.
Выполнить ручную HA migration.
Проверить приложение.
Выполнить maintenance test.
Только затем считать HA настроенным.

Быстрый набор команд

Проверить HA:

ha-manager status

Создать группу:

ha-manager groupadd production-ha   --nodes pve01:100,pve02:80,pve03:60   --restricted 1   --nofailback 1

Добавить VM:

ha-manager add vm:100   --group production-ha   --state started

Мигрировать:

ha-manager migrate vm:100 pve02

Остановить через HA:

ha-manager set vm:100   --state stopped

Удалить из HA:

ha-manager remove vm:100

Итог

После выполнения инструкции:

проверены quorum, watchdog и HA-службы;
создана HA group;
VM добавлена как HA resource;
настроены priority, restricted и nofailback;
выполнена ручная HA migration;
проверен maintenance mode;
разобран аварийный failover;
рассмотрены ограничения storage и passthrough.

High Availability считается настроенной только после контролируемого теста переноса и проверки реальной готовности приложения на другом узле.