Кластер Proxmox VE объединяет несколько серверов в единую управляемую инфраструктуру. Это обеспечивает централизованное управление, живую миграцию VM и опциональную высокую доступность (HA).
Требования к кластеру
- Минимум 3 ноды для HA (для кворума)
- Идентичная версия Proxmox VE на всех нодах
- Надёжная сеть между нодами (latency < 5 мс)
- Синхронизация времени (NTP/Chrony) на всех нодах
- Уникальные hostname и IP для каждой ноды
Создание кластера
# На первой (master) ноде
pvecm create my-cluster --link0 192.168.1.100
# Проверить статус
pvecm statusДобавление ноды в кластер
# На новой ноде (убедитесь в доступности master по SSH)
pvecm add 192.168.1.100 --link0 192.168.1.101
# Проверить список нод
pvecm nodesНастройка High Availability (HA)
HA автоматически перезапускает VM на другой ноде при отказе текущей:
# Включить VM в HA-группу через CLI
ha-manager add vm:100 --group ha-group --state started
# Создать HA-группу
ha-manager groupadd ha-group --nodes "node1,node2,node3" --restricted 0
# Статус HA
ha-manager statusНастройка Corosync-сети
# Добавить второй линк для кластерной сети (резервный)
pvecm add 192.168.1.100 --link0 192.168.1.101 --link1 10.0.0.101
# /etc/pve/corosync.conf — посмотреть конфигурацию
cat /etc/pve/corosync.confВосстановление кворума
# При потере кворума (нода недоступна)
# Временно снизить ожидаемый кворум (ОПАСНО — только для обслуживания)
pvecm expected 1
# Удалить недоступную ноду из кластера
pvecm delnode pve3
# Восстановить конфигурацию кластера на оставшихся нодах
systemctl restart corosync pve-clusterpvecm expected 1 в продакшн-среде без понимания последствий может привести к split-brain и потере данных. Всегда консультируйтесь с документацией.
Мониторинг кластера
# Статус всех нод
pvesh get /nodes
pvecm status
# Журналы кластера
journalctl -u corosync -f
# Ping-тест между нодами
corosync-cfgtool -sТипичные ошибки Corosync и кворума
Большинство проблем кластера видно уже в момент создания или добавления ноды — Corosync жёстко проверяет согласованность конфигурации и сразу сообщает о расхождении, а не работает «наполовину».
Corosync Cluster Engine Authentication error
cluster not ready - no quorum? (500)
TOTEM ] Retransmit List: 15 16 17- Authentication error: файл /etc/corosync/authkey отличается между нодами — обычно из-за ручного копирования конфигурации вместо штатной команды. Переустановите ноду через
pvecm addс нуля. - no quorum? (500): у кластера меньше половины голосов онлайн — любые изменения конфигурации через веб-интерфейс блокируются, пока кворум не восстановлен.
- Retransmit List растёт: сеть Corosync перегружена или теряет пакеты — переносите кластерный трафик на выделенный линк с низкой задержкой.
Полезная привычка — сверять время создания проблемы с журналом изменений сети и обновлений пакетов: две трети таких инцидентов совпадают с плановыми работами, а не возникают сами по себе.
Варианты кворума при двух нодах
Классическая схема требует нечётного числа голосов; для двух серверов есть три практических варианта.
| Вариант | Голоса | Стоимость | Когда использовать |
|---|---|---|---|
| QDevice (внешний арбитр) | +1 голос | Лёгкий сервис вне кластера | Есть третий независимый хост для арбитра |
| Третья полноценная нода | +2 голоса | Полный сервер | Бюджет позволяет третий физический узел |
| Без HA, ручное вмешательство | — | Ноль | Кластер нужен только ради живой миграции |
Когда кластер Proxmox не подходит
Кластеризация добавляет не только возможности, но и эксплуатационную нагрузку.
- Два сервера без QDevice и без готовности вручную поднимать кворум при сбое — риск полной остановки управления превышает пользу от живой миграции.
- Ноды в разных дата-центрах с задержкой сети выше 5–10 мс — Corosync и HA становятся нестабильными, возможны ложные фейловеры.
- Разовые задачи или тестовые стенды — накладные расходы на обслуживание кластера (сертификаты, кворум, синхронизация времени) не окупаются.
Проверка результата настройки
После создания кластера и настройки HA убедитесь, что кворум устойчив и фейловер действительно срабатывает.
# Кворум и список нод
pvecm status
# Реальная задержка между нодами кластерной сети
corosync-cfgtool -s
# Проверка: отключить сетевой линк на одной ноде и посмотреть, перезапустится ли VM из HA-группы на другой
ha-manager statusЕсли после отказа ноды VM из HA-группы поднимается на другом узле в течение минуты — настройка рабочая. При потере кворума порядок восстановления описан в статье восстановление кворума Proxmox.
Частые вопросы
Почему кластеру Proxmox нужно нечётное число нод для кворума?
Кворум определяется как больше половины голосов от общего числа нод, и при чётном количестве сеть легко разделяется на две равные половины, каждая из которых считает себя главной, — это называется split-brain. Нечётное число голосов гарантирует, что ровно одна часть кластера останется в большинстве при любом разрыве связи между нодами.
Включается ли High Availability автоматически после объединения нод в кластер?
Нет, сам по себе кластер только объединяет ноды для управления и живой миграции, а High Availability настраивается отдельно: нужную VM добавляют в HA-группу и указывают список нод, между которыми она может перезапускаться при отказе. Без этого шага VM продолжит работать как обычно, просто на кластеризованной инфраструктуре.
Что такое fencing и почему он обязателен для надёжного HA?
Fencing — это механизм принудительного отключения питания неисправной ноды через внешнее устройство вроде IPMI или управляемого PDU. Без fencing кластер не может быть уверен, что отказавшая нода действительно остановилась, а не просто временно потеряла связь, и может запустить ту же VM на другой ноде одновременно — это и приводит к split-brain.
Можно ли настроить HA на двух нодах без третьей ноды или QDevice?
Формально да, но без дополнительного голоса арбитра кворум между двумя нодами легко теряется при отказе любой из них, и восстановление требует ручного вмешательства администратора. Для стабильного автоматического HA нужен третий голос — либо лёгкий внешний QDevice, либо полноценная третья нода, иначе кластер рискует полностью остановить управление при единственном сбое.