Высокая доступность в Proxmox: что произойдёт при падении узла

MAATRIX

Ночью падает физический узел кластера — сгорел блок питания, отвалилась сеть, завис гипервизор. Все ждут, что HA (High Availability) в Proxmox мгновенно поднимет виртуалки на соседнем узле, и через секунду всё снова работает. На практике происходит не это: переключение занимает минуты, а не секунды, VM перезапускается «с нуля» с потерей оперативной памяти, а если диск виртуалки лежал только на упавшем сервере — HA не поможет вообще. Разберём механизм HA в Proxmox честно: что он реально делает, какие два требования обязательны, и что произойдёт по шагам, если узел кластера действительно упадёт.

Что вообще такое HA в Proxmox и как это работает под капотом

HA в Proxmox — это не отдельная технология, а надстройка над уже существующим кластером: демон pve-ha-lrm (Local Resource Manager) работает на каждом узле и следит за локальными ресурсами, а pve-ha-crm (Cluster Resource Manager) выбирается кластером как «менеджер» и принимает решения о том, где какая VM должна работать. Все решения HA опираются на состояние кластера, которое хранится в /etc/pve/ha/ — общей для всех узлов файловой системе pmxcfs.

Список VM, которых касается HA, задаётся явно — по умолчанию HA не следит вообще ни за одной виртуалкой:

ha-manager add vm:101 --state started --group priority-group --max_restart 3 --max_relocate 3

Это создаёт ресурс в /etc/pve/ha/resources.cfg:

vm: 101
    group priority-group
    max_relocate 3
    max_restart 3
    state started

state started говорит HA поддерживать VM включённой; max_restart/max_relocate ограничивают число попыток перезапуска на месте и переноса на другой узел, чтобы избежать бесконечного цикла падений, если проблема не в узле, а в самой VM. Группы (ha-manager groupadd) задают, на каких узлах вообще разрешено запускать ресурс и в каком порядке приоритета — это управляемо, а не «куда получится».

Важно понимать: HA в Proxmox работает только с тем, что описано выше явно. Если VM не добавлена в HA-ресурсы, при падении узла она просто не запустится нигде — и это нормальное, ожидаемое поведение, а не баг.

Требование №1: кворум — без него HA технически не может работать

Первое обязательное условие — рабочий кворум кластера. Проверить его состояние:

pvecm status

Если в выводе Quorate: No — HA не работает вообще, и это не ограничение конфигурации, а логическая необходимость. Причина в том, что кластеру нужно как-то отличить два принципиально разных сценария: узел действительно упал (сгорел блок питания, вышел из строя диск) или узел просто временно не отвечает по сети (порвался линк, перегружен коммутатор, потерялись несколько пакетов corosync). Со стороны оставшихся узлов оба сценария выглядят одинаково — «узел молчит». Разница в том, что делать дальше: если узел жив, но просто отрезан от сети, а другой узел параллельно запустит ту же VM на её диске — получится classic split-brain, два экземпляра одной виртуалки одновременно пишут на один и тот же диск, и это гарантированно ломает данные.

Кворум решает именно эту задачу: решение «узел точно недоступен, можно безопасно перезапускать его VM в другом месте» принимается только той частью кластера, у которой больше половины голосов от общего списочного состава. Меньшинство узлов права принимать такие решения не имеет — даже если оно уверено, что право у него. Отсюда прямое следствие для инфраструктуры: двухузловой кластер для HA практически бесполезен — при разрыве связи между двумя узлами кворум не наберёт ни одна из сторон. Подробный разбор механизма и то, почему именно 3, а не 2 узла — в статье про кворум в кластере; отдельно про типичные грабли конкретно двухузлового Proxmox-кластера — в статье «Кластер Proxmox из двух узлов».

Практический вывод для планирования инфраструктуры: если вы рассчитываете на HA, закладывайте минимум 3 полноценных узла кластера (или третий узел-«свидетель» без нагрузки, только для голосования — pvecm qdevice). Меньше — и сам механизм HA не сможет корректно отработать отказ.

Требование №2: общее хранилище — самое частое заблуждение

Второе требование не менее критично, и именно на нём чаще всего спотыкаются, настраивая HA первый раз: диски виртуальных машин, которых касается HA, должны физически лежать на хранилище, доступном ВСЕМ узлам кластера — Ceph, ZFS-репликация между узлами, NFS/iSCSI на внешнем сторонже, и так далее.

Логика простая до банальности, но её часто упускают: если диск VM физически существует только на локальном хранилище упавшего узла (local-lvm, локальный ZFS-пул конкретного сервера), то ни один другой узел кластера физически не может запустить эту VM — потому что не имеет доступа к байтам, из которых она состоит. Не «медленно», не «с ограничениями» — вообще никак. HA в такой ситуации бессилен, независимо от того, насколько правильно настроен кворум и группы.

qm config 101 | grep -E 'scsi0|virtio0'

Если в выводе хранилище вида local-lvm:vm-101-disk-0 — это локальное хранилище конкретного узла, и HA для этой VM работать не будет, даже если она формально добавлена в resources.cfg. Нужно хранилище общего типа — например ceph-vm:vm-101-disk-0 или NFS-датастор, смонтированный одинаково на всех узлах.

Отдельный нюанс: ZFS-репликация (pve-zsync, встроенная репликация Proxmox между узлами) — не то же самое, что настоящее общее хранилище. Данные реплицируются по расписанию (обычно раз в несколько минут), а не в реальном времени, поэтому при отказе узла HA восстановит VM на состоянии последней успешной репликации — то есть возможна потеря нескольких минут записей. Это компромисс, который иногда оправдан (не у всех есть Ceph), но о нём нужно знать заранее, а не узнавать при реальном отказе. Что конкретно предлагает Proxmox из типов хранилищ и когда какой выбирать — разобрано в статье «Хранилища в Proxmox: что и когда».

Пошагово: что происходит с VM при отказе узла

Когда физический узел действительно выходит из строя, кластер проходит через несколько последовательных этапов — и ни один из них не мгновенный.

Шаг 1. Обнаружение недоступности узла. Остальные узлы перестают получать от него сигналы corosync. Но кластер не реагирует на первый же пропущенный «пинг» — иначе любое кратковременное сетевое дрожание вызывало бы ложные переключения. Таймауты corosync/CRM подобраны так, чтобы отличить реальный отказ от временной задержки: узел должен молчать некоторое устойчивое время, прежде чем его признают отказавшим.

Шаг 2. Подтверждение отказа через кворум. Как только период ожидания истёк, оставшаяся часть кластера (при условии, что у неё есть кворум — см. выше) помечает узел как dead в HA-статусе. Проверить текущее состояние:

ha-manager status

Шаг 3. Fencing (изоляция узла). Прежде чем где-либо перезапустить VM, кластеру нужна гарантия, что старый узел точно не работает с этим же диском параллельно — иначе split-brain на общем хранилище. Proxmox использует механизм watchdog-fencing: LRM упавшего узла (если он хоть немного жив) сам должен самостоятельно перезагрузиться по watchdog-таймеру, если не может подтвердить кластеру, что он жив. Это встроенная защита именно от того сценария, где сеть развалилась, а сам сервер работает.

Шаг 4. Запуск VM на другом узле. Только после этого CRM выбирает из доступных узлов (с учётом настроенной группы и приоритетов) новый хост и запускает на нём сконфигурированные с HA виртуалки — используя их последнее состояние конфигурации и диски с общего хранилища. Логи этого процесса можно смотреть через:

journalctl -u pve-ha-crm -f

Весь цикл — от последнего сигнала живого узла до фактического старта VM в новом месте — реалистично занимает от одной до нескольких минут, в зависимости от настроенных таймаутов и загрузки хранилища. Это и есть RTO (Recovery Time Objective) вашего HA-кластера: не ноль, а величина порядка минут.

Это перезапуск, а не живая миграция — и это меняет всё

Здесь кроется главное заблуждение вокруг HA: многие ожидают от него поведения живой миграции — когда VM переезжает между узлами без перерыва в работе, приложение продолжает отвечать, а пользователь ничего не замечает. HA работает принципиально иначе. Живая миграция возможна только когда исходный узел жив и может передать состояние памяти VM новому узлу; при отказе узла состояние передавать уже физически не от кого — узел не отвечает. Разница между этими двумя механизмами разобрана подробно в статье «Живая миграция виртуалок: что с памятью» — она наглядно показывает, что HA-переключение эту гарантию не даёт в принципе.

Что происходит на практике: VM на новом узле стартует так, будто сервер, на котором она работала, внезапно обесточили посреди работы. Всё содержимое оперативной памяти теряется целиком — открытые сетевые соединения обрываются, незакоммиченные в БД транзакции откатываются, состояние приложения в памяти (сессии, кэши, очереди в оперативке) исчезает. Файловая система внутри VM монтируется заново — как после нештатной перезагрузки, с проверкой журнала.

Практическое следствие для того, что вы кладёте в HA-группу: приложение внутри VM обязано быть готово к грубому холодному рестарту, а не только к аккуратному systemctl restart. Это тот же принцип, что при построении корректного порядка автозапуска сервисов после перезагрузки — сервис должен уметь стартовать самостоятельно, без ручного вмешательства, и переживать обрыв соединений с зависимостями (БД, очередями, соседними сервисами). Разбор того, как выстроить зависимости и порядок старта для устойчивости именно к такому сценарию — в статье «Автозапуск и порядок старта виртуалок».

Отдельно стоит подчеркнуть, от чего HA защищает, а от чего — нет:

• Защищает: от отказа физического узла — сервер сгорел, завис, потерял сеть навсегда.
• Не защищает: от отказа приложения внутри VM (зависшая служба, memory leak, упавший процесс) — VM на своём узле продолжит работать, HA её не тронет, потому что с точки зрения кластера узел и VM в порядке.
• Не защищает: от потери данных в оперативной памяти на момент отказа — это архитектурно неизбежное следствие холодного перезапуска.
• Не защищает мгновенно: RTO порядка минут — если вашему сервису нужна доступность в духе «пользователь вообще ничего не заметил», HA Proxmox для этого не рассчитан, нужна отдельная отказоустойчивость на уровне приложения (кластер БД, балансировщик между несколькими VM в разных узлах одновременно).

Как настроить HA-группу и приоритеты (практика)

Группа задаёт, на каких узлах разрешено работать VM и в каком порядке предпочтения. Пример: три узла, pve1 — основной, pve2 и pve3 — резервные:

ha-manager groupadd priority-group --nodes pve1:3,pve2:2,pve3:1 --restricted 0 --nofailback 0

Цифра после узла — приоритет (больше = предпочтительнее). restricted 0 разрешает HA переносить VM и на узлы вне явного списка приоритетов, если все перечисленные недоступны; restricted 1 — жёстко запрещает выход за пределы группы. nofailback 0 означает, что после восстановления упавшего узла VM автоматически вернётся на него по приоритету; nofailback 1 — останется там, где запустилась, пока её не перенесут вручную. На практике nofailback 1 часто безопаснее: автоматический возврат на только что «ожившей» ноде, чью стабильность вы ещё не проверили, — сомнительная идея.

Добавление ресурса в группу:

ha-manager add vm:101 --group priority-group --state started

Проверка состояния HA по всему кластеру:

ha-manager status
# quorum OK
# master pve1 (active, Wed Aug 26 10:00:00 2026)
# lrm pve1 (active, Wed Aug 26 10:00:00 2026)
# lrm pve2 (active, Wed Aug 26 10:00:00 2026)
# lrm pve3 (active, Wed Aug 26 10:00:00 2026)
# service vm:101 (pve1, started)

Стоит регулярно (не только один раз при настройке) проверять, что диски VM в HA-группе действительно на общем хранилище — переезд диска на локальное хранилище конкретного узла (например, при ручной миграции «с локальным диском» или неудачном клонировании) молча ломает HA для этой VM, и заметите вы это обычно только в момент реального отказа, когда откатывать уже поздно.

Частые вопросы