Кластер 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, або повноцінна третя нода, інакше кластер ризикує повністю зупинити керування за єдиного збою.