Кластеризація Proxmox та HA: як це працює, що ламається і як проєктувати правильно

January 4, 2026 • February 3, 2026 • Читання: 5 хв • Views: 6

Було корисно?

Вперше, коли Proxmox HA «рятує» вас перезавантаженням ВМ на вузол, який не бачить її диск,
ви отримуєте корисний урок: доступність — це властивість системи, а не чекбокс.
Кластеризація проста. Вижити під відмовою — складніше.

Це практичний, орієнтований на виробництво гайдик: як кластеризація та HA у Proxmox працюють насправді,
що ламається в реальних середовищах і як спроєктувати кластер, який не перетворює дрібні відмови на імпровізований танець.

Ментальна модель, що відповідає реальності

Кластеризація Proxmox — це не магія. Це три окремі проблеми, які люди люблять зливати в одне:

Плоскість керування (control plane): вузли погоджуються щодо членства та конфігурації (corosync + pmxcfs).
Плоскість даних (data plane): диски ВМ доступні там, де запущена ВМ (спільне сховище або реплікація).
Оркестрація навантаження: коли вузол падає, щось вирішує перезапустити ВМ десь інде (pve-ha-manager + pve-ha-lrm).

HA працює тільки якщо всі три проєктуються так, щоб відмови були безпечними. Можна мати абсолютно здоровий кластер
з цілком не-HA сховищем. Можна мати ідеальне спільне сховище з плоскістю керування, яка панікує при втраті пакетів.
А можна мати обидва і самосаботуватися «оптимізаціями» — агресивними таймаутами або одним комутатором.

Правило експлуатації просте: якщо ви не можете пояснити, де знаходиться диск ВМ під час відновлення, у вас немає HA.
У вас є «можливість перезавантажити ВМ десь інде». Це не те саме.

Що всередині: corosync, pmxcfs, pve-ha-manager

Corosync: членство і обмін повідомленнями

Corosync — це шар комунікації кластера. Він обробляє членство вузлів і надійно розповсюджує стан кластера.
Proxmox використовує його для питання «хто в кладі?». Він чутливий до затримок, джиттера й втрати пакетів так само, як ваш найжвавіший uplink чутливий до «все буде гаразд».

pmxcfs: файлова система конфігу

Proxmox зберігає конфігурацію кластера в /etc/pve, яку підтримує pmxcfs — розподілена файлова система.
Вона не призначена для ваших образів ВМ. Вона для конфігів: визначення сховищ, конфігурації ВМ, ACL, налаштувань кластера.

Коли втрачається кворум, /etc/pve переходить у захисний режим. Записи блокуються, бо дозволяти двом розділеним частинам писати конфіг незалежно — шлях до розділення конфігів.
Це функція. Це також причина, чому люди думають «Proxmox впав», коли лише блокуються записи.

pve-ha-manager і pve-ha-lrm: мозок HA і місцеві руки

HA-стек має менеджер і місцеві менеджери ресурсів. Менеджер вирішує, що повинно працювати де. Місцевий агент виконує старт/стоп.
Він використовує мікс логіки watchdog і стану кластера, щоб уникнути одночасного запуску однієї ВМ двічі. Уникнути. Не гарантувати. Гарантія вимагає fencing.

Одна цитата для стіни в дусі експлуатаційної реальності: (парафраз) «Сподівання — не стратегія.» — часто приписують інженерам і операторам, і вона вірна незалежно від авторства.

Кворум: найважливіше слово у вашому кластері

Кворум відповідає на питання: чи має ця частина вузлів повноваження приймати рішення щодо кластера?
Якщо ви експлуатуєте кластер, не розуміючи кворуму, ви керуєте навантажувачем у скляному магазині.

Навіщо існує кворум

У мережевому розділенні ви можете опинитися з двома групами вузлів, які не бачать одна одну.
Без кворуму обидві сторони можуть «робити правильну річ» локально і запустити ту саму HA-ВМ.
Так ви корумпуєте файлові системи, бази даних і стосунки з фінансовим відділом.

Правило великого пальця: непарні числа перемагають

Кластер з 3 вузлів може втратити 1 вузол і зберегти кворум. Кластер з 2 вузлів — ні.
Ви можете змусити 2-вузловий кластер працювати за допомогою пристрою кворуму (QDevice), але якщо ви намагаєтеся зробити HA дешево,
дуже швидко зрозумієте, чому люди радять 3.

QDevice: «третій голос» без третього гіпервізора

QDevice додає зовнішній голос кворуму, щоб 2-вузловий кластер міг продовжувати працювати, коли один вузол впав (або відділений).
Його потрібно розміщувати обережно: якщо QDevice стоїть на тому самому мережевому шляху, що й збої, це декоративний голос.
Розміщуйте його там, де він ламається інакше, ніж ваш кластерний інтерконект.

Жарт №1 (короткий і доречний)

Кворум як дорослість: якщо треба запитати, чи він у вас є — скоріш за все, немає.

Сховище для HA: що означає «спільне» насправді

Рішення по сховищу — це рішення по HA. Усе інше — хореографія.

Варіант A: справжнє спільне сховище (SAN/NFS/iSCSI/FC)

Спільне сховище означає, що диск ВМ доступний з кількох вузлів одночасно з коректним блокуванням.
У термінах Proxmox це типи сховищ, які підтримують спільний доступ і правильні семантики (наприклад, NFS з належною конфігурацією, iSCSI з LVM, FC з multipath).

Спільне сховище робить відновлення швидким: перезапустив ВМ на іншому вузлі — той самий диск. Воно також концентрує ризик: масив стає вашою «однією річчю», яка може вивести все з ладу.
Деякі організації це приймають, бо масив побудований як танк. Інші виявляють, що «масив» — це один контролер і один адмінський пароль, змінений в 2018 році.

Варіант B: гіперконвергентне спільне сховище (Ceph)

Ceph дає розподілене сховище по вузлах Proxmox (або на виділених вузлах сховища). Чудово, коли спроєктовано правильно:
достатньо вузлів, достатньо NIC, достатньо дисків, достатньо CPU і достатньо скромності.

Ceph — це не «безкоштовне HA». Це система з власними режимами відмов, поведінкою відновлення і профілем продуктивності.
Під час відновлення Ceph може з’їдати ваш IO-бюджет, що виглядає як «Proxmox HA зламався», коли насправді кластер робить саме те, що ви попросили: відновлює дані.

Варіант C: реплікація (реплікація ZFS) + перезапуск

Реплікація ZFS може забезпечити поведінку близьку до HA: реплікуйте диски ВМ з первинного на вторинні вузли за розкладом.
Якщо вузол помирає, ви запускаєте ВМ на вузлі з недавньою реплікою. Компроміс очевидний: RPO не нульовий, якщо тільки ви не використовуєте синхронну реплікацію (а вона — інша історія).

Реплікація — сильний вибір для малих кластерів, які можуть терпіти втрату кількох хвилин даних, або для навантажень, де є прикладне рівне реплікації.
Вона також значно простіша в експлуатації, ніж Ceph для багатьох команд. Простота — добре. Передбачуваність — краще.

Що ламає HA-сховище на практиці

Невідповідність блокувань: сховище підтримує спільні читання, але не безпечні спільні записи.
Мережеве зв’язування: трафік сховища та corosync ділять один перевантажений лінк.
Припущена міцність: «це RAID» стає «це безпечно» і перетворюється на «куди подівся datastore?»
Відновлення без fencing: два вузли вважають, що володіють тим самим диском.

Fencing: те, що ви пропускаєте, поки не вдарить

Fencing (STONITH: Shoot The Other Node In The Head) гарантує, що збійний або відділений вузол реально зупинений перед тим, як ресурси запустять інакше.
У VM-HA fencing — це те, як ви запобігаєте катастрофі «два активних записувача».

Без fencing ви покладаєтеся на таймаути і вдачу. Таймаути — не повноваження. Це вгадки.

Як виглядає fencing у світі Proxmox

Proxmox підтримує self-fencing на основі watchdog і зовнішнє fencing через IPMI/iDRAC/iLO-типу управління.
На практиці, для серйозного HA:

Увімкніть і перевірте watchdog на кожному вузлі.
Використовуйте поза-мережне управління живленням, щоб жорстко вимкнути вузол, який «живий, але неправильний».
Проєктуйте живлення і мережу так, щоб вузол можна було зфенсити навіть якщо його основна мережа мертва.

Якщо ви використовуєте блочне спільне сховище (iSCSI/FC) і запускаєте кластерні файлові системи або LVM, fencing має ще більший сенс.
Пошкодження даних рідко миттєве. Зазвичай воно затяжне, тонке й кар’єрно-шкідливе.

Мережа кластера: кільця, затримки та втрата пакетів

Corosync хоче низької затримки і малої втрати пакетів. Він витримає менше «дивностей», ніж ваш стек зберігання.
Класичний режим відмов — «мережа в основному нормальна», що люди говорять, коли втрата пакетів 0.5% і ваш кластер періодично втрачає кворум.

Розділяйте мережі за функціями

Corosync: виділений VLAN або фізична мережа, якщо можете. Важлива передбачувана затримка.
Сховище: теж виділене, особливо для Ceph або iSCSI.
Клієнтський/ВМ трафік: не давайте йому давити на plane керування кластера.

Подвійні кільця — не декорація

Corosync може використовувати кілька кілець (окремі мережі) для відмовостійкості. Це варто зробити.
Якщо ви не можете дозволити собі резервування комутації, прийміть, що ваше «HA» — це «великий трепет».

Жарт №2 (короткий і доречний)

Втрата пакетів як терміти: будинок здається нормальним, поки раптом не перестає бути.

Як це ламається: реальні відмови й чому

Режим відмови: втрата кворуму зупиняє запис конфігів

Симптом: ви можете залогінитися, ВМ можуть продовжувати працювати, але не можна старт/стоп/мігрувати, і зміни в GUI не працюють.
Корінь: вузол (або розділення) не має кворуму, тому pmxcfs блокує записи.
Правильна реакція: відновіть кворум, не «примушуйте» систему, якщо не збираєтеся свідомо працювати в ізольованому одно-вузловому режимі і розумієте наслідки.

Режим відмови: HA перезапускає ВМ, але вони не завантажуються

Симптом: менеджер HA намагається перенести/перезапустити, але ВМ падає з помилками про відсутні диски, сховище офлайн або IO-помилками.
Корінь: сховище фактично не було спільним/доступним на цільовому вузлі; або мережева доріжка до сховища впала разом із вузлом.
Правильна реакція: розглядайте сховище як частину домену відмов; переробіть диверсифікацію шляхів до сховища; переконайтесь, що визначення сховища послідовні і доступні на всіх вузлах.

Режим відмови: split brain або ризик «подвійного старту»

Симптом: однакова служба з’являється двічі, або спільний диск показує корупцію, або HA флапає.
Корінь: мережеве розділення без ефективного fencing, неправильно виставлені очікувані голоси або погано розміщений QDevice.
Правильна реакція: виправте дизайн кворуму і додайте fencing. Не налаштовуйте таймаути, поки не спроєктуєте повноваження.

Режим відмови: відновлення Ceph робить усе начебто мертвим

Симптом: після відмови вузла ВМ заїкаються, затримки IO стрибають, кластер «відчувається» як мертвий.
Корінь: Ceph робить backfill/recovery, насичуючи диски і мережу.
Правильна реакція: планування потужностей, швидкі мережі і здорові налаштування відновлення. Також: прийміть, що «самовиліковне сховище» витрачає ресурси на лікування.

Практичні завдання: команди, виводи та рішення

Це перевірки, які я реально запускаю. Кожна включає, що означає вивід і яке рішення прийняти.
Виконуйте їх на вузлі, якщо не вказано інше.

Завдання 1: Перевірити членство кластера і кворум

cr0x@pve1:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 12:10:41 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Значення: Quorate: Yes означає, що ця частина має право безпечно змінювати стан кластера (запускати HA-ВМ, редагувати конфіг).

Рішення: Якщо Quorate: No, припиніть зміни і виправте підключення/пристрій кворуму перед втручанням у HA.

Завдання 2: Показати по-вузловий вигляд і голоси

cr0x@pve1:~$ pvecm nodes
Membership information
----------------------
Nodeid      Votes Name
0x00000001      1 pve1 (local)
0x00000002      1 pve2
0x00000003      1 pve3

Значення: Підтверджує, хто в списку членства і скільки голосів у кожного.

Рішення: Якщо вузол відсутній несподівано, дослідіть corosync-з’єднання і стан вузла перед тим, як звинувачувати HA.

Завдання 3: Перевірити стан кілець corosync (knet links)

cr0x@pve1:~$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
        addr    = 10.10.10.11
        status  = ok
LINK ID 1 udp
        addr    = 10.10.20.11
        status  = ok

Значення: Обидва кільця підняті. Якщо лінк down, ви втратили резервування.

Рішення: Якщо резервність кілець порушена, ставте це як sev-2: наступний хік-ап комутатора стане інцидентом кластера.

Завдання 4: Перевірити часування corosync і членство з runtime-статистики

cr0x@pve1:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Sun Dec 28 12:11:22 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          1
Ring ID:          1.2c
Quorate:          Yes

Значення: Підтверджує перспективу votequorum; корисно, коли UI бреше або журнали забруднені.

Рішення: Якщо це каже non-quorate, припиніть ганятися за примарами сховища/продуктивності і спочатку виправте комунікації кластера.

Завдання 5: Підтвердити, що pmxcfs здоровий і не застряг у режимі лише читання

cr0x@pve1:~$ pvesh get /cluster/status
[
  {
    "type": "cluster",
    "name": "prod-cluster",
    "version": 42,
    "quorate": 1
  },
  {
    "type": "node",
    "name": "pve1",
    "online": 1,
    "ip": "10.10.10.11"
  },
  {
    "type": "node",
    "name": "pve2",
    "online": 1,
    "ip": "10.10.10.12"
  },
  {
    "type": "node",
    "name": "pve3",
    "online": 1,
    "ip": "10.10.10.13"
  }
]

Значення: "quorate": 1 вказує, що файлова система кластера може приймати записи в нормальному режимі.

Рішення: Якщо quorate = 0, не намагайтеся редагувати /etc/pve; зміни не пройдуть (або, гірше, створять хаос під час відновлення).

Завдання 6: Перевірити стан менеджера HA

cr0x@pve1:~$ ha-manager status
quorum OK
master pve2 (active, Sat Dec 27 23:14:02 2025)

service vm:101 (running, node=pve1)
service vm:120 (running, node=pve3)

lrm pve1 (active, Sat Dec 27 23:14:11 2025)
lrm pve2 (active, Sat Dec 27 23:14:02 2025)
lrm pve3 (active, Sat Dec 27 23:14:07 2025)

Значення: Показує, який вузол є HA-master і чи активні місцеві менеджери ресурсів.

Рішення: Якщо LRM неактивні або master флапає, зосередьтеся на стабільності кворуму і corosync перед тим, як торкатися окремих ВМ.

Завдання 7: Пояснити, чому конкретна HA-ВМ не переміщується

cr0x@pve1:~$ ha-manager status --verbose
quorum OK
master pve2 (active, Sat Dec 27 23:14:02 2025)

service vm:101 (running, node=pve1)
  state: started
  request: none
  last_error: none

service vm:130 (error, node=pve2)
  state: stopped
  request: start
  last_error: unable to activate storage 'ceph-vm' on node 'pve2'

Значення: HA не «зламаний», його блокує активація сховища на цільовому вузлі.

Рішення: Переходьте до дебагу сховища (Ceph/NFS/iSCSI), а не до налаштувань HA.

Завдання 8: Швидко перевірити втрату/затримку мережі кластера

cr0x@pve1:~$ ping -c 20 -i 0.2 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.355 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.420 ms
...
--- 10.10.10.12 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3815ms
rtt min/avg/max/mdev = 0.312/0.401/0.612/0.081 ms

Значення: Чистий ping не доводить, що corosync задоволений, але втрата/джиттер тут — це сигнальний кратер.

Рішення: Якщо існує втрата пакетів, зупиніться. Спершу виправте мережу. Corosync під втратою породжує фантомні відмови всюди.

Завдання 9: Переглянути журнали corosync на предмет перезасновувань членства

cr0x@pve1:~$ journalctl -u corosync -S -2h --no-pager | tail -n 20
Dec 28 10:41:03 pve1 corosync[1203]:   [KNET  ] link: host: 2 link: 0 is down
Dec 28 10:41:06 pve1 corosync[1203]:   [QUORUM] This node is within the primary component and will provide service.
Dec 28 10:41:11 pve1 corosync[1203]:   [KNET  ] link: host: 2 link: 0 is up
Dec 28 10:41:12 pve1 corosync[1203]:   [TOTEM ] A new membership (1.2b) was formed. Members joined: 2

Значення: Флапи лінків спричинили формування нового членства. Це турбулентність кластера.

Рішення: Ставте повторні зміни членства як передвісник відмови. Досліджуйте NIC, комутатори, bonding, VLAN, MTU та перевантаження.

Завдання 10: Перевірити наявність watchdog (передумова для self-fencing)

cr0x@pve1:~$ dmesg | grep -i watchdog | tail -n 10
[    1.842113] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[    1.842205] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

Значення: Драйвер апаратного watchdog присутній. Це база для self-fencing.

Рішення: Якщо watchdog відсутній, не прикидайтеся, що у вас безпечний HA. Додайте апаратну підтримку або зовнішнє fencing.

Завдання 11: Підтвердити видимість сховища на цільовому вузлі (приклад NFS)

cr0x@pve2:~$ pvesm status
Name         Type     Status           Total       Used        Avail     %
local        dir      active         19660800    2457600     17203200   12%
nfs-vmstore  nfs      active       1048576000  734003200    314572800   70%

Значення: Сховище active на цьому вузлі. Якщо inactive, HA не зможе стартувати диски тут.

Рішення: Якщо inactive — виправте монтування/мережу/аутентифікацію перед тим, як дозволяти HA розміщувати тут навантаження.

Завдання 12: Підтвердити бекенд диска ВМ і чи його можна мігрувати

cr0x@pve1:~$ qm config 101
boot: order=scsi0;net0
cores: 4
memory: 8192
name: app-prod-01
net0: virtio=12:34:56:78:9a:bc,bridge=vmbr0
scsi0: ceph-vm:vm-101-disk-0,iothread=1,size=80G
scsihw: virtio-scsi-pci
vmgenid: 0b0b0b0b-1111-2222-3333-444444444444

Значення: Диск на ceph-vm. Це спільне сховище (за умови здорового Ceph).

Рішення: Якщо бачите local-lvm або локальний ZFS dataset без реплікації, не очікуйте, що HA успішно перезапустить ВМ на іншому вузлі.

Завдання 13: Перевірити стан Ceph (якщо ви його використовуєте)

cr0x@pve1:~$ ceph -s
  cluster:
    id:     2f4a9d2e-aaaa-bbbb-cccc-111122223333
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 12/3456 objects degraded

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 7m)
    mgr: pve1(active, since 2h)
    osd: 9 osds: 8 up (since 1m), 9 in (since 30d)

  data:
    pools:   3 pools, 128 pgs
    objects: 1152 objects, 4.5 GiB
    usage:   220 GiB used, 1.8 TiB / 2.0 TiB avail
    pgs:     12 active+undersized+degraded, 116 active+clean

Значення: Ceph піднятий, але деградований; продуктивність може бути поганою і перезапуски HA можуть працювати повільно.

Рішення: У деградованих станах уникайте масових міграцій і не спричиняйте зайвих рестартів. Спочатку стабілізуйте Ceph.

Завдання 14: Підтвердити стан реплікації для ZFS-реплікацій

cr0x@pve1:~$ pvesr status
JobID  Type  State    Last Sync              Duration  Error
1000   local ok       2025-12-28 11:55:02    00:01:42  -
1001   local failed   2025-12-28 11:40:02    00:00:11  ssh connection failed

Значення: Job 1001 впав; репліки можуть бути застарілими на цільовому вузлі.

Рішення: Не приписуйте HA-покриття ВМ для робіт реплікації, що падають. Виправте транспорт/аутентифікацію, потім перевірте RPO.

Завдання 15: Перевірити, чи кластер не страждає від нестачі ресурсів (CPU steal, IO wait)

cr0x@pve1:~$ pvesh get /nodes/pve1/status
{
  "cpu": 0.71,
  "loadavg": [2.15, 2.07, 1.94],
  "memory": {
    "total": 68719476736,
    "used": 51234567890,
    "free": 17484908846
  },
  "swap": {
    "total": 8589934592,
    "used": 2147483648
  },
  "uptime": 123456
}

Значення: У вас йде своп. У кластерах своп перетворює «дрібну мережеву пробоїну» в «чому все зупинилося».

Рішення: Якщо своп використовується суттєво в нормальних умовах — виправте тиск пам’яті перед діагностикою HA-флапів.

Завдання 16: Перевірити синхронізацію часу (так, це важливо)

cr0x@pve1:~$ timedatectl status
               Local time: Sun 2025-12-28 12:14:55 UTC
           Universal time: Sun 2025-12-28 12:14:55 UTC
                 RTC time: Sun 2025-12-28 12:14:55
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Годинник синхронізований. Добре. Дрейф часу робить журнали марними і може підривати розподілені системи тонко.

Рішення: Якщо не синхронізовано — виправте NTP/chrony на всіх вузлах перед тим, як інтерпретувати послідовність подій під час інциденту.

Швидкий план діагностики

Коли кластер Proxmox «веде себе дивно», ви хочете швидкість і правильні пріоритети. Ось порядок, який швидко знаходить вузьке місце.

По-перше: чи авторитетний контрольний шар?

Запустіть pvecm status: чи маєте ви кворум?
Запустіть corosync-cfgtool -s: лінки підняті? чи якесь кільце down?
Проскануйте journalctl -u corosync: чи є повторні зміни членства?

Якщо кворум нестабільний — зупиніться тут. Виправте мережу і членство кластера перед розслідуванням HA, сховища або симптомів ВМ.

По-друге: чи бачить цільовий вузол сховище ВМ?

pvesm status на цільовому вузлі: сховище active?
qm config <vmid>: де насправді диск?
Якщо Ceph: ceph -s і слідкуйте за degraded/backfill.

Якщо сховище недоступне всюди, де потрібно — HA буде флапати або перезапускатись із помилкою.

По-третє: HA застрягло чи відмовляється робити небезпечну дію?

ha-manager status --verbose: читайте помилку, не вгадуйте.
Перевірте readiness watchdog/fencing, якщо бачите ризик подвійного старту або повторне fencing-подібне поводження.

По-четверте: чи це насправді голодання по ресурсах?

pvesh get /nodes/<node>/status: своп, load, використання CPU.
Перевірте втрати та затримки мережі між вузлами; потім перевірте мережу сховища окремо.

Типові помилки: симптом → корінь → виправлення

1) «HA зламався, він не запускає ВМ»

Симптоми: дії HA падають; GUI показує помилки; деякі вузли показані як «unknown».

Корінь: втрата кворуму або churn членства corosync.

Виправлення: Відновіть стабільне corosync-з’єднання (виділена мережа, резервні кільця). Додайте QDevice для 2-вузлового кластера. Не міняйте таймаути перш за все.

2) «ВМ перезапустилася на іншому вузлі, але диск відсутній»

Симптоми: ВМ стартує, потім падає; помилки сховища; диск не знайдено.

Корінь: Диск був на локальному сховищі вузла (або спільне сховище не змонтоване/неактивне на цілі).

Виправлення: Поставте HA-ВМ на справжнє спільне сховище (Ceph/NFS/iSCSI/FC) або реалізуйте реплікацію з визначеним RPO і протестуйте відновлення/відкат.

3) «Кластер зависає під час бекапів/міграцій»

Симптоми: timeouts corosync, HA флапає, повільний GUI під важким IO.

Корінь: corosync мережа ділить перевантажений лінк з VM/сховищем; або голодування CPU через шифрування/компресію/бекапи.

Виправлення: Розділіть мережі; обмежте швидкість важких робіт; прив’яжіть corosync до шляхів з низькою затримкою; плануйте CPU для вікон бекапів.

4) «Дво-вузловий кластер: інколи він просто перестає управляти речами»

Симптоми: після відмови одного вузла залишковий вузол не стартує HA-ресурси або не редагує конфіг.

Корінь: Немає QDevice; очікувані голоси не синхронізовані; кворум неможливий самостійно.

Виправлення: Додайте QDevice, розміщений в незалежному домені відмов; перевірте expected votes; тестуйте сценарії «один вузол вниз».

5) «Ceph більш-менш здоровий, але все повільно»

Симптоми: висока затримка IO, ВМ паузять, повільні відновлення після відмови.

Корінь: деградований/backfill/recovery насичує IO; мережа (1GbE) або диски замалі; замало OSD.

Виправлення: Проєктуйте Ceph правильно: 10/25GbE, достатньо OSD, розділені public/cluster мережі при потребі, і плануйте вплив відновлення.

6) «Ми налаштували таймаути corosync і тепер HA гірше»

Симптоми: частіша втрата кворуму, хибні смерті вузлів, випадкові відмови.

Корінь: таймаути встановлені нижче реального джиттера під навантаженням; кластер стає надчутливим.

Виправлення: Поверніть стандартні налаштування; виправте мережу; виміряйте джиттер під піковим навантаженням; тільки потім обережно налаштовуйте.

7) «Після перезавантаження вузол не може приєднатися до кластера»

Симптоми: вузол здається офлайн; corosync не стартує; помилки невідповідності конфігів.

Корінь: Неправильна мапа /etc/hosts, застарілий corosync-конфіг, несумістний MTU або правила фаєрволу.

Виправлення: Перевірте резолюцію імен, узгоджений MTU, відкрийте потрібні порти для мереж кластеру і підтвердіть консистентність corosync.conf через /etc/pve.

Контрольні списки / покроковий план

Чеклист проєктування: будівництво кластера, на якому можна спати

Виберіть розмір кластера: віддавайте перевагу 3+ вузлам. Якщо 2 вузли — плануйте QDevice і fencing з першого дня.
Визначте домени відмов: комутатори, електроживлення, стійки, пари ToR, шляхи до сховища. Запишіть їх.
Розділіть мережі: corosync на власному VLAN/фізичній мережі; сховище окремо; клієнтський трафік — окремо.
Резервність: подвійні кільця corosync; резервні комутатори; bonded NIC лише якщо розумієте конфіг на комутаторі.
Стратегія сховища: спільне (Ceph/SAN/NFS/iSCSI) для справжнього HA; реплікація — для «перезапуску з RPO». Не плутайте очікування.
Fencing: watchdog + управління живленням поза мережею, протестовані. Задокументуйте, як зфенсити вручну.
Ємність: N+1 для обчислень. HA без резервної ємності — це автоматизоване розчарування.
Операційні тести: плановий ребут вузла, вимкнення живлення, відключення порту комутатора, відмова шляху до сховища, втрата QDevice (якщо використовується).

План впровадження: від нуля до стабільності

Будуйте вузли ідентичними (ядро, драйвери NIC, налаштування BIOS для віртуалізації, контролери сховищ).
Виставте статичні адреси для corosync-мереж; забезпечте стабільну резолюцію імен.
Створіть кластер; одразу налаштуйте двокільцевий corosync, якщо маєте мережі.
Перевірте поведінку кворуму тимчасовою ізоляцією одного вузла (контрольований тест).
Підніміть сховище і перевірте з кожного вузла (pvesm status має бути нудно послідовним).
Увімкніть watchdog і перевірте його наявність у логах на кожному вузлі.
Створіть HA-групи з розумними обмеженнями (не дозволяйте всьому впасти на найменший вузол).
Поставте одну некритичну ВМ в HA, протестуйте відмову вузла, підтвердіть її запуск на іншому вузлі з правильним диском і мережею.
Розгорніть HA по класах сервісів; тримайте пул «не HA» для домашніх тварин і експериментів.

Операційний чеклист: тижневий рутинний «тримати здоровим»

Перевірте pvecm status на випадковому вузлі: підтвердіть стабільний кворум.
Проскануйте журнали corosync на предмет флапів лінків і змін членства.
Якщо Ceph: перевірте ceph -s і вирішуйте попередження до того, як вони стануть інцидентами.
Перевіряйте роботи реплікації (pvesr status), якщо покладаєтеся на них.
Підтверджуйте синхронізацію часу на всіх вузлах.
Іноді виконуйте контрольовану міграцію в робочий час (так, навмисно), щоб виявити дрейф раніше.

Три міні-історії з корпоративного світу

Міні-історія 1: Інцидент, спричинений неправильною припущенням

Середньо-велике підприємство побудувало три-вузловий Proxmox-кластер для «HA». Команда зробила те, що роблять багато команд: зв’язали вузли,
увімкнули HA і були задоволені. Сховище «було спільним», казали вони, бо кожен вузол мав доступ до NAS по NFS.
Ніхто не поставив непривабливе питання: чи змонтований NFS і здоровий на кожному вузлі під час тієї точної відмови, яку ми плануємо?

Перша реальна відмова — ребут top-of-rack комутатора. Вузли лишилися підключеними, але VLAN NAS затремтів.
Corosync був на тому самому шляху комутації, тож почався churn членства. Кворум мерехтів.
HA позначив вузол як нездоровий і перезапустив дві ВМ на вузол, який у той момент не мав змонтованої NFS-шари.

ВМ не завантажилися. Застосунки впали. Команда, дивлячись на UI, інтерпретувала це як «Proxmox HA багнуте».
Вони перезавантажили вузли під гаслом «стабілізації», що тільки погіршило ситуацію, бо збільшило churn і кількість провалів стартів.

Після вирішення питання постмортем показав неправильне припущення: «доступний NFS» скоріше вважали «HA-сховищем».
Виправлення не було екзотичним. Вони відокремили corosync на виділену мережу, зробили монтування сховища стійким і під нагляд,
і додали жорстке правило: ніякого HA-тегу ВМ, якщо її диск не знаходиться на сховищі, доведеному як доступне з будь-якого цільового вузла під тестами відмов.

Урок неромантичний: HA — це контракт. Якщо сховище може зникнути під тією ж категорією відмови, що і та, яка тригерить failover,
ваша HA-система охоче перезапустить навантаження в порожнечу і назве це успіхом.

Міні-історія 2: Оптимізація, що повернулася бумерангом

Інша організація працювала з Proxmox і Ceph і мала періодичні «вузол втратився» алерти. Хтось вирішив «пожвавішити детекцію»
зменшивши таймаути кластера. Швидша детекція = швидший failover, аргументували вони. Вони хотіли, щоб система була «швидшою».

Це пройшло в лабораторії. В продакшні ж з’явилася реальність: вікна бекапів, шумний сусід IO і мережа, яка була нормальною,
поки трафік відновлення Ceph не став амбітним. Під піковим навантаженням corosync-пакети затримувалися трохи.
З ужатими таймаутами ці затримки перейшли від «терпимого» до «вузол оголошено мертвим».

HA почав переміщувати ВМ. Ceph вже був зайнятий. Тепер він мав обслуговувати IO ВМ плюс відновлення плюс поглинути шторм міграцій/рестартів.
Кластер закрутився у самозаподіяний біль: хибні відмови спричиняли реальне навантаження, що викликало ще більше хибних відмов.

Виправлення було трохи соромно-амбулаторне і повністю ефективне: відкотили таймаути, потім виправили латентність і перевантаження.
Вони розділили трафік, обмежили швидкість найгаласливіших робіт і виставили очікування: швидкість failover не варта нестабільності кластера.

Глибокий урок: таймаути — не ручки продуктивності. Це датчики відмов. Якщо ви налаштовуєте їх нижче вашого найгіршого джиттера,
ви не покращуєте доступність. Ви генеруєте хаос швидше.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Компанія зі суворими вимогами відповідності експлуатувала Proxmox-кластер зі спільним iSCSI-сховищем і QDevice.
Їхній дизайн не був ефектним. Він був просто безкомпромісно ретельним: виділена corosync-мережа, резервні комутатори,
задокументований fencing через поза-мережне управління і щоквартальні тести «вимкнути живлення».

Під час планового обслуговування оновлення прошивки на одному комутаторі пішло не так і комутатор перестав форвардити трафік належним чином.
Corosync-кольцо 0 почало дивно себе вести. Кільце 1 залишилося здоровим. Кворум не був втрачений.
ВМ не флапнули. Моніторинг загорівся, але бізнес майже не помітив.

On-call дотримувався рунабука: підтвердив кворум, перевірив статус кілець corosync, перевірив шляхи сховища, а потім ізолював поганий комутатор.
Вони свідомо перемістили деякі навантаження замість того, щоб дозволити HA трощити систему. Вони не панічно перезавантажували вузли.

Після інциденту команда не отримала очок героя, бо нічого драматичного не сталося. Оце мрія.
Нудна практика — резервні кільця плюс відпрацьована діагностика — перетворила потенційно брудну відмову на контрольоване обслуговування.

Якщо хочете, щоб HA виглядала як компетентність замість адреналіну, потрібні ці нудні звички. Драма — не KPI.

Цікаві факти та історичний контекст

Факт 1: Proxmox VE будує комунікацію кластера на Corosync — довготривалий проект з відкритим кодом, також використовуваний у класичних Linux HA стеках.
Факт 2: Концепція «кворум» передує сучасній віртуалізації; вона корениться в безпеці розподілених систем: тільки більшість може безпечно вирішувати.
Факт 3: Split brain не винайшли для віртуалізації; кластерні файлові системи та реплікація баз даних боряться з цим десятиліттями.
Факт 4: pmxcfs — файлова система конфігурації, а не загальноцільова розподілена файлова система; трактувати її як «спільне сховище» — поширене непорозуміння.
Факт 5: Перехід Corosync на транспорт knet покращив обробку лінків і опції резервування порівняно зі старими налаштуваннями.
Факт 6: STONITH як термін звучить як жарт, але ідея смертельно серйозна: гарантувати, що існує лише один писач.
Факт 7: «HA» спочатку означало перемикання сервісів на рівні процесів; віртуалізація зробила одиницею відновлення всю машину, але правила безпеки лишилися.
Факт 8: Популярність Ceph у гіперконвергентних встановленнях зросла через вирішення реальної проблеми: масштабування сховища без монолітного масиву, але ціною операційної складності.
Факт 9: Дво-вузлові кластери історично незручні в системах на основі кворуму; третій голос (людський, свідок або qdevice) — добре відпрацьований патерн.

Поширені питання

1) Мені потрібно три вузли для Proxmox HA?

Якщо хочете розумної поведінки кворуму без спеціальних компонентів — так. Два вузли можуть працювати з QDevice, але це менш терпиме і легше неправильно спроєктувати.

2) Що робиться, коли кластер втрачає кворум?

Вузли без кворуму блокують запис конфігів у /etc/pve. Запущені ВМ можуть продовжувати працювати, але операції, керовані кластером (особливо HA), можуть бути обмежені.

3) Чи можу я мати HA, якщо диски ВМ на локальному сховищі?

Не справжнє HA failover. Proxmox може перезапустити ВМ десь інде тільки якщо диск доступний там (спільне сховище) або реплікований і промотований з відомим RPO.

4) Чи є ZFS-реплікація «HA»?

Це «автоматизований перезапуск з реплікацією». Чудово для багатьох навантажень, але це не нульовий RPO. Якщо це прийнятно і протестовано — це валідний дизайн.

5) Чи справді мені потрібен fencing?

Якщо ви використовуєте спільне сховище і дбаєте про цілісність даних — так. Без fencing мережеве розділення може призвести до двох активних писачів.
Іноді пощастить. Іноді ви отримаєте пошкоджену базу і довгі вихідні.

6) Чи повинні corosync і Ceph/NFS працювати в одній мережі?

Уникайте цього. Corosync хоче передбачуваної затримки; трафік сховища стрибкоподібний і рано чи пізно «притисне» його. Розділяйте, якщо не маєте дуже маленького середовища і приймаєте ризик.

7) Як зрозуміти, що HA не працює через сховище чи через комунікації кластера?

Спочатку перевірте кворум (pvecm status). Якщо quorate — перевірте, чи сховище active на цілі (pvesm status) і читайте ha-manager status --verbose на предмет явних помилок.

8) Чому Proxmox HA іноді відмовляється перемістити ВМ, навіть коли вузол виглядає нездоровим?

Тому що він намагається уникнути небезпечних дій: старт без сховища, подвійний старт або дія без кворуму. «Відмова» часто є правильною поведінкою.

9) Чи можу я розтягнути Proxmox-кластер на два сайти?

Можете, але підписуєтесь на латентність, ризик розділення і складну реплікацію сховища. Якщо мусите — проєктуйте кворум, fencing і сховище як розподілену систему, не як LAN.

10) Який найпростіший надійний дизайн HA для малих команд?

Три вузли, виділена corosync-мережа, справжнє спільне сховище (або реплікація з явним RPO), увімкнений watchdog і протестовані сценарії відмов. Тримайте це нудним.

Висновок: практичні наступні кроки

Кластеризація Proxmox і HA працюють добре, коли ви ставите до купи інженерію систем: повноваження (кворум), безпечне виконання (fencing)
і доступність даних (сховище). Якщо будь-який із цих аспектів опущено — кластер зрештою за це розплатиться.

Наступні кроки, які ви можете зробити цього тижня:

Запустіть швидкі перевірки діагностики зараз, поки все «гарне», і зафіксуйте базові виводи.
Класифікуйте кожну ВМ: справжній HA (спільне сховище + fencing), перезапуск з RPO (реплікація) або best-effort (локальне).
Розділіть трафік corosync від трафіку сховища і ВМ, або хоча б доведіть, що мережа витримає найгірший джиттер під навантаженням.
Протестуйте одну реальну відмову (вимкніть живлення вузла або відключіть порт комутатора) у контрольованому вікні і підтвердіть: поведінку кворуму, рішення HA, доступність сховища.
Задокументуйте, як зфенсити вузол, і потренуйтеся. Ви не хочете, щоб перша спроба fencing була під час корупції даних.