Налаштування кластера Proxmox для високої доступності

Помилка при налаштуванні кластера Proxmox може коштувати вам даних. Типовий сценарій: два вузли, спільне сховище не налаштоване, кластер постійно втрачає кворум, ВМ падають щотижня. Ми знаємо, як це виправити. За 5 років ми реалізували 30+ проєктів з налаштування HA кластерів Proxmox для компаній різного масштабу — від стартапів до enterprise. Наша мета — щоб ваші ВМ автоматично мігрували при збої вузла, а downtime вимірювався хвилинами, а не годинами.

Як налаштувати Proxmox кластер для високої доступності?

Ми ділимося практичними конфігами, перевіреними в бою. У цій статті розберемо ключові архітектурні рішення: від вибору сховища до налаштування fencing. Вартість рішення розраховується індивідуально, але зазвичай нижча на 20–30% порівняно з аналогами на VMware.

Проблеми, які вирішуємо

Мінімальна кількість вузлів: 3

Кворум (більшість голосів) потрібен для прийняття рішень кластером. З 2 вузлами при втраті зв'язку кожен вважає себе єдиним вцілілим — виникає split-brain, і обидва намагаються запустити однакові ВМ, що призводить до пошкодження даних. 3 вузли гарантують, що при будь-якому одиничному відмові залишається більшість. Згідно з документацією Proxmox, кворум критичний для цілісності кластера.

Як уникнути типових помилок мережі?

Найчастіша проблема — спільне сховище не налаштоване або налаштоване неправильно. HA в Proxmox потребує shared storage: ВМ має бути доступна з будь-якого вузла. Якщо диск ВМ лежить на локальному ZFS хоста, при його падінні ВМ нікуди не мігрує — дані недоступні.

Друга проблема — 1 мережевий інтерфейс для всього трафіку. Cluster network (corosync), migration network та VM трафік на одному NIC: при високому навантаженні коросинк втрачає пакети, кластер вважає хост мертвим і починає fence — примусово вимикає живлення через IPMI. Насправді хост живий, просто зайнятий. Підсумок — непотрібний failover та downtime.

Мережева архітектура: що і чому

Рекомендована схема для 3 вузлів:

Corosync на виділеному інтерфейсі — обов'язково. Якщо окремий фізичний NIC недоступний, використовуємо VLAN з пріоритетом QoS.

Як вибрати спільне сховище для Proxmox HA?

Вибір shared storage визначає відмовостійкість та бюджет. Порівняємо основні варіанти.

Порівняння варіантів shared storage

Ceph — вбудований у Proxmox, розподілене сховище прямо на дисках вузлів. Кожен вузол вносить диски в Ceph пул, дані реплікуються між 3 вузлами автоматично. Мінус: Ceph споживає ~2–4 GB RAM на OSD.

NFS/iSCSI — зовнішній СЗД. Простіший в управлінні, але єдина точка відмови, якщо СЗД не має власного HA.

Shared ZFS через iSCSI — ZFS на dedicated storage сервері, експортується як iSCSI LUN та монтується на всі вузли.

Створення кластера

# На першому вузлі — створюємо кластер
pvecm create pve-cluster --link0 address=10.10.1.1 --link1 address=10.10.2.1

# На другому та третьому вузлах — приєднуємося
pvecm add 10.10.1.1 --link0 address=10.10.1.2 --link1 address=10.10.2.2
pvecm add 10.10.1.1 --link0 address=10.10.1.3 --link1 address=10.10.2.3

# Перевіряємо статус кластера
pvecm status

--link0 та --link1 — 2 незалежних шляхи corosync. При втраті одного — кластер продовжує роботу через другий. Це redundant ring protocol, критично для стабільності.

Налаштування HA Manager

Після налаштування shared storage вмикаємо HA для конкретних ВМ:

# Додавання ВМ до HA групи
ha-manager add vm:101 --state started --max_restart 3 --max_relocate 2

# Створення HA групи з пріоритетами вузлів
ha-manager groupadd production-group --nodes pve1:3,pve2:2,pve3:1 --restricted 1
ha-manager add vm:101 --group production-group

max_restart — скільки разів HA намагається перезапустити ВМ на поточному вузлі до евакуації. max_relocate — скільки разів переносить на інший вузол. restricted — ВМ запускається тільки на вузлах з групи.

Чому fencing критичний?

Fencing — обов'язковий компонент HA. Proxmox має вміти примусово вимкнути живлення проблемного вузла, перш ніж запустити його ВМ на іншому хості. Без fencing дані можуть пошкодитися: два хости пишуть в один диск одночасно. Налаштовуємо через IPMI/iDRAC/iLO:

# Налаштування IPMI fencing для вузла pve1
pvesh set /nodes/pve1/config --wakeonlan 0

# У /etc/pve/corosync.conf додаємо конфігурацію fence agent

totem {
  ring0_addr: 10.10.1.1
  ring1_addr: 10.10.2.1
}
quorum {
  provider: corosync_votequorum
}
nodelist {
  node {
    name: pve1
    nodeid: 1
  }
}
logging {
  to_syslog: yes
}

Live Migration та навантаження

Proxmox підтримує live migration (аналог vMotion) для ВМ без вимкнення. Для коректної роботи: однакові або сумісні CPU на всіх вузлах (прапорець --cpu host обмежує міграцію — використовуйте --cpu kvm64 для сумісності), спільне storage, migration network на окремому інтерфейсі.

# Ручна live migration ВМ 101 на вузол pve2 qm migrate 101 pve2 --live 1 --migration_network 10.10.3.0/24 

Що входить у роботу

1. Повна документація з налаштування кластера, мережі та storage
2. Доступи до Proxmox, IPMI, моніторингу для вашого адміна
3. Навчання команди базовим операціям (3–4 години)
4. Гарантія працездатності HA-конфігурації протягом 30 днів
5. Пост-релізна підтримка: 3 місяці консультацій телефоном/поштою
6. Міграція даних з існуючої інфраструктури (при необхідності)
7. Скрипти автоматичного відновлення для типових збоїв

Отримайте консультацію інженера перед початком робіт — ми підберемо оптимальну архітектуру під ваш бюджет та навантаження. Замовте налаштування під ключ та отримайте кластер, готовий до продакшну. Економія на відмовостійкості може сягати 40% порівняно з традиційними рішеннями. Зв'яжіться з нами для оцінки вашого проєкту.

Строки

Налаштування 3-вузлового кластера з Ceph: 3–5 днів. Із зовнішнім СЗД (NFS/iSCSI): 2–3 дні. З нуля, включаючи встановлення ОС на хости: додати 1–2 дні.