Proxmox «кластер не готовий — немає кворуму?»: як відновити кворум, не погіршуючи ситуацію

Що насправді означає кворум у Proxmox (і чому він блокує дії)

Кластеризація Proxmox будується на основі Corosync для членства та обміну повідомленнями, а також pmxcfs (Proxmox Cluster File System),
який реплікує конфігурацію (конфігурації VM, визначення сховищ, правила брандмауера, користувачів тощо) між вузлами. Коли кворум втрачається, Proxmox навмисно
припиняє робити «зміни на рівні кластера», бо не може безпечно визначити, чи він представляє єдину істинну картину.

Уявіть кворум як здатність кластера впевнено відповісти на одне питання: «Чи ми легітимна більшість?»
Без цього дві половини розділення можуть обидві думати, що вони керують. Це і є split‑brain. Split‑brain — не модний архітектурний патерн;
це просто корупція з кращим маркетингом.

У Proxmox втрата кворуму зазвичай проявляється як:

• Банер у UI: «кластер не готовий — немає кворуму?»
• Помилки в CLI: помилки pvesh / pveproxy, неможливість запису в /etc/pve
• Операції з VM блокуються: особливо навантаження, що керуються HA
• Нестабільний стан сховища: бо частина конфігурації зберігається в /etc/pve

Зверніть увагу на нюанс: ваші VM можуть продовжувати працювати. Ваше сховище може бути в порядку. Мережа може бути в нормі.
Втрата кворуму — передусім проблема координації кластера. Небезпека в тому, що вона спокушає вас на дії, які створять проблему з даними.

Цитата, яку варто пам’ятати під час інциденту:
«Сподівання — не стратегія.» — Джин Кранц

Жарт №1: Кворум — як нарада, яка має значення лише якщо прийшло достатньо людей. На диво, цього разу кластер — дорослий у кімнаті.

Швидкий план діагностики (перші/другі/треті перевірки)

Коли ви посередині збою, вам не потрібна теорія. Потрібно швидко знайти вузьке місце, обрати найменш ризиковий шлях відновлення
і уникнути «фіксів», які працюють лише тому, що ви не помітили другої відмови.

Спочатку: підтвердіть, що це справді кворум, а не проблема UI чи проксі

• Запустіть pvecm status на вузлі, на якому ви працюєте.
• Перевірте systemctl status pve-cluster corosync.
• Переконайтеся, що /etc/pve змонтовано і відповідає.

По‑друге: визначте реальність членства (хто живий, хто може спілкуватися)

• Запустіть pvecm nodes.
• Перевірте стан кільця Corosync (corosync-cfgtool -s або corosync-quorumtool -s).
• З кожного вузла протестуйте інтерфейси кільця за допомогою ping/arping і перевірте маршрути/VLANи.

По‑третє: визначте клас відновлення

Оберіть один із цих варіантів, у такому порядку пріоритету:

1. Відновити відсутні вузли або мережу, щоб початковий кластер поступово отримав кворум.
2. Тимчасово відкоригувати очікувані голоси тільки під реальність, яку ви можете довести безпечно.
3. Останній варіант: примус одного вузла стати операційним достатньо довго, щоб стабілізуватися (із явним прийняттям ризику).
4. Відновлення після катастрофи: відновити кластер і приєднати вузли з нуля після замороження старого стану.

Якщо ви не можете чітко пояснити, до якого класу відновлення належите, вам не варто вводити команди, що змінюють кворум.

Цікаві факти та контекст (чому все так влаштовано)

• Факт 1: «Кворум» у Corosync забезпечує сервіс votequorum, який вирішує, чи має партія достатньо голосів для роботи.
• Факт 2: /etc/pve у Proxmox — розподілена файлова система (pmxcfs), що зберігається в RAM і синхронізується через Corosync; це не звичайний каталог.
• Факт 3: Механізм «очікувані голоси» існує, бо кластери змінюють розмір; його також можна зловживати, «переконуючи» партію, що вона має кворум.
• Факт 4: Двовузлові кластери априорі незручні для кворуму: без третього голосу партія не може відрізнити «пір недоступний» від «лінк недоступний».
• Факт 5: Ідея більшості голосів у розподілених системах має десятиліття історії; це практичний компроміс: безпека важливіша за доступність під час розділення мережі.
• Факт 6: Corosync використовує ідентифікатори кілець і переходи членства; часті зміни кілець зазвичай означають втрату пакетів, невідповідність MTU або нестабільні лінки.
• Факт 7: HA у Proxmox покладається на стан кластера; якщо кворум втрачено, HA зазвичай відмовляється діяти «розумно», бо «розумно» часто призводить до одночасного запуску VM в двох місцях.
• Факт 8: Концепція qdevice (зовнішній вирішувач) існує переважно тому, що організації наполягають на парній кількості вузлів, а потім дивуються, коли трапляється фізика.

Жарт №2: Двовузловий кластер без вирішувача — як двоє менеджерів, що сперечаються в Slack. Єдиний переможець — канал інцидентів.

Правила безпеки: зробіть це перед тим, як щось чіпати

1) Визначте, що ви захищаєте: цілісність VM, цілісність сховища або лише UI

Якщо сховище спільне (Ceph, SAN, NFS, iSCSI), найбільший ризик — два вузли, які вважають, що володіють одним і тим же записуваним ресурсом.
Якщо сховище локальне (ZFS на кожному вузлі), ризик зсувається в бік розбіжності конфігурації й невдалих дій HA, а не в пряме пошкодження блоків.

2) Заморозьте автоматизацію

Якщо у вас є зовнішня автоматизація, що змінює конфіг Proxmox (Terraform, Ansible, скрипти, що викликають API), призупиніть її.
Інциденти з кворумом — місце, де ідемпотентність часто вмирає, бо кластер не приймає записи стабільно.

3) Не «виправляйте» перезавантаженням усього

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

4) Якщо використовується спільне сховище, визначте факти фензингу

Якщо у вас є спільні LUNи або NFS‑експорти, змонтовані в режимі запису кількома вузлами, потрібно знати, чи є будь‑який механізм фензингу:
IPMI для керування живленням, SCSI‑резервації на SAN, правила Ceph OSD тощо. Якщо відповідь «не впевнений», не форсуйте кворум легковажно.

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

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

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

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

Quorum information
------------------
Date:             2025-12-25 10:14:18
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          No

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

Значення: Ця партія має 1 голос, але очікує 3; кворум вимагає 2. Ви не в кворумі.

Рішення: Не чіпайте HA або конфігурацію кластера. Далі з’ясуйте, куди поділися інші два голоси: вузли вимкнені чи мережевий розділ.

Завдання 2: Подивитися, які вузли кластер вважає наявними

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

Значення: Конфігурація кластера очікує три вузли з по одним голосом кожен.

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

Завдання 3: Перевірити здоров’я служби corosync на локальному вузлі

cr0x@pve1:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Thu 2025-12-25 10:01:03 UTC; 13min ago
       Docs: man:corosync
   Main PID: 1189 (corosync)
      Tasks: 10
     Memory: 45.2M
        CPU: 7.412s

Значення: Corosync працює. Це не «служба померла», це «служба не бачить достатньо пір».

Рішення: Зосередьтеся на здоров’ї мережі/кільця/пірів, а не на бездумному перезапуску.

Завдання 4: Перевірити готовність pve-cluster і pmxcfs

cr0x@pve1:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Thu 2025-12-25 10:01:10 UTC; 13min ago
   Main PID: 1260 (pmxcfs)
      Tasks: 12
     Memory: 78.0M
        CPU: 3.201s

Значення: pmxcfs працює, але може бути в режимі, схожому на читання‑тільки для записів кластера через відсутність кворуму.

Рішення: Перевірте, чи доступний /etc/pve та чи блокуються записи.

Завдання 5: Підтвердити, що /etc/pve змонтовано (і не зависло)

cr0x@pve1:~$ mount | grep /etc/pve
pve on /etc/pve type fuse.pve (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Значення: pmxcfs змонтовано. Це добре.

Рішення: Якщо його немає, у вас більша локальна проблема вузла (pmxcfs не змонтовано), а не лише втрата кворуму.

Завдання 6: Перевірити, чи файлова система кластера записувана (практично)

cr0x@pve1:~$ touch /etc/pve/.rw-test
touch: cannot touch '/etc/pve/.rw-test': Read-only file system

Значення: При відсутності кворуму pmxcfs відмовляється від записів (звичайна поведінка).

Рішення: Припиніть намагатися «редагувати, щоб вибратися». Спочатку відновіть кворум або скористайтеся контрольованою процедурою відновлення одного вузла, якщо це обраний шлях.

Завдання 7: Подивитися стан кільця Corosync (рівень лінку)

cr0x@pve1:~$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
        addr    = 10.10.10.11
        status:
                nodeid:          1:     connected
                nodeid:          2:     disconnected
                nodeid:          3:     disconnected

Значення: pve1 підключений до себе, але не може досягти pve2/pve3 на мережі кільця.

Рішення: Підтвердьте досяжність мережі кільця (IP, VLAN, MTU, брандмауер) перед тим, як чіпати голоси.

Завдання 8: Перевірити на втрачені пакети та невідповідність MTU на кільці

cr0x@pve1:~$ ping -c 5 -M do -s 8972 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500

--- 10.10.10.12 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4087ms

Значення: Ви виконали jumbo‑ping і виявили MTU 1500 на шляху відправника. Якщо ви очікували jumbo‑кадри, ви знайшли реальну причину.

Рішення: Узгодьте MTU по всьому шляху для мережі Corosync (порти комутаторів, бонди, VLAN‑інтерфейси). Corosync не любить таємничої фрагментації.

Завдання 9: Підтвердити базову досяжність пір (не пропускайте нудну частину)

cr0x@pve1:~$ ping -c 3 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.602 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.581 ms
64 bytes from 10.10.10.12: icmp_seq=3 ttl=64 time=0.594 ms

--- 10.10.10.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2041ms
rtt min/avg/max/mdev = 0.581/0.592/0.602/0.009 ms

Значення: IP‑зв’язок є, принаймні для ICMP. Це необхідна, але не достатня умова.

Рішення: Якщо ICMP працює, але Corosync все ще показує відключення, підозрюйте фільтрацію UDP, асиметричну маршрутизацію або неправильний bindnetaddr.

Завдання 10: Перевірити логи Corosync на предмет змін членства й тайм‑аутів токена

cr0x@pve1:~$ journalctl -u corosync -n 50 --no-pager
Dec 25 10:12:02 pve1 corosync[1189]:   [KNET  ] host: 2 (passive) link: 0 is down
Dec 25 10:12:03 pve1 corosync[1189]:   [TOTEM ] A processor failed, forming new configuration.
Dec 25 10:12:04 pve1 corosync[1189]:   [QUORUM] Members[1]: 1
Dec 25 10:12:04 pve1 corosync[1189]:   [QUORUM] This node is within the non-primary component and will NOT provide service.

Значення: KNET‑лінк до хоста 2 впав, і підсистема кворуму відмовляє в наданні сервісу. Це курильний пістолет для «мережа або віддалений вузол недоступні».

Рішення: Виправте фізичний/віртуальний мережевий шлях або підніміть віддалений вузол, потім дочекайтеся стабілізації членства.

Завдання 11: Переглянути конфігурацію Corosync (bindnetaddr і список вузлів)

cr0x@pve1:~$ cat /etc/pve/corosync.conf
totem {
  version: 2
  cluster_name: prod-cluster
  transport: knet
  interface {
    linknumber: 0
    bindnetaddr: 10.10.10.0
    mcastport: 5405
  }
}

nodelist {
  node {
    name: pve1
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.10.10.11
  }
  node {
    name: pve2
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.10.10.12
  }
  node {
    name: pve3
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 10.10.10.13
  }
}

quorum {
  provider: corosync_votequorum
}

Значення: Corosync очікує мережу кільця на 10.10.10.0/24. Якщо вузли перемістилися в інші підмережі, змінили IP або теги VLAN, членство зламається.

Рішення: Якщо IP змінилися, відновіть їх або оновіть corosync.conf з кворумного вузла (або скористайтеся контрольованим методом відновлення). Не редагуйте вручну, поки pmxcfs нестабільний.

Завдання 12: Визначити, чи відсутні вузли насправді вимкнені

cr0x@pve1:~$ ssh root@10.10.10.12 "uptime && systemctl is-active corosync && pvecm status | sed -n '1,20p'"
 10:15:41 up 12 days,  3:22,  2 users,  load average: 0.22, 0.18, 0.15
active
Cluster information
-------------------
Name:             prod-cluster
Config Version:   12
Transport:        knet
Secure auth:      on

Значення: pve2 увімкнений і corosync активний. Тож чому pve1 відключений? Ймовірно, мережевий розділ, брандмауер або асиметрична маршрутизація.

Рішення: Проведіть ті самі перевірки кільця з pve2. Потрібні симетричні докази (щоб pve2 також не бачив pve1 або бачив іншу картину).

Завдання 13: Підтвердити досяжність UDP‑портів (трафік Corosync) через tcpdump

cr0x@pve1:~$ tcpdump -ni vmbr1 udp port 5405 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:16:02.112233 IP 10.10.10.11.5405 > 10.10.10.12.5405: UDP, length 256
10:16:03.113244 IP 10.10.10.11.5405 > 10.10.10.12.5405: UDP, length 256
10:16:04.114255 IP 10.10.10.11.5405 > 10.10.10.12.5405: UDP, length 256

Значення: Вихідні пакети відправляються. Якщо ви не бачите вхідних відповідей, проблема між вузлами (ACL, комутатор, маршрутизація або брандмауер пір).

Рішення: Захоплення проводьте одночасно на pve2. Якщо pve2 бачить вхідні, але відповіді зникають, підозрюйте асиметричну маршрутизацію або фільтрацію вгору по ланцюжку.

Завдання 14: Перевірити статус брандмауера хоста (PVE firewall може підкосити)

cr0x@pve1:~$ pve-firewall status
Status: enabled/running

Значення: Брандмауер увімкнений. Сам по собі це не погано; це змінна, яку треба врахувати.

Рішення: Переконайтеся, що правила дозволяють Corosync на інтерфейсі кільця. Якщо ви нещодавно посилили правила, це перший підозрюваний.

Завдання 15: Переконатися, що комунікація кластера не блокується через зсув часу

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

Значення: Синхронізація часу на цьому вузлі здорова. Corosync не перевіряє TLS‑дійсність ваших пакетів за часом, але розбаланс часу корелює з «усім дивно», включно з аутентифікацією та логами.

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

Завдання 16: Як контрольована дія — встановити expected votes (тимчасово) для відновлення кворуму

cr0x@pve1:~$ pvecm expected 1
Setting expected votes to 1

Значення: Ви повідомили votequorum очікувати лише 1 голос. Це може миттєво зробити цю партію кворумною.

Рішення: Робіть це лише якщо ви впевнені, що інші вузли вимкнені або ви їх зафензили. Інакше ви ризикуєте мати дві кворумні партії одночасно (це фільм жахів).

Завдання 17: Перевірити кворум після зміни

cr0x@pve1:~$ pvecm status | grep -E "Quorate|Expected votes|Total votes|Quorum"
Quorate:          Yes
Expected votes:   1
Total votes:      1
Quorum:           1

Значення: Вузол тепер кворумний (відповідно до нового очікування).

Рішення: Використайте це вікно, щоб стабілізувати конфігурацію кластера, але плануйте повернути очікувані голоси, коли кластер знову буде повний.

Завдання 18: Чисто видалити мертвий вузол (коли кластер кворумний)

cr0x@pve1:~$ pvecm delnode pve3
Removing node pve3 from cluster

Значення: Членство кластера оновлено; очікувані голоси і математика кворуму змінюються відповідно.

Рішення: Робіть це тільки якщо ви прийняли рішення, що pve3 назавжди відсутній (або буде перевстановлений і заново приєднаний). Не використовуйте delnode як «тест ping».

Завдання 19: Перевірити здоров’я pmxcfs після відновлення кворуму

cr0x@pve1:~$ ls -la /etc/pve/nodes
total 0
drwxr-xr-x 2 root www-data 0 Dec 25 10:18 .
drwxr-xr-x 1 root www-data 0 Dec 25 10:18 ..
drwxr-xr-x 2 root www-data 0 Dec 25 10:18 pve1
drwxr-xr-x 2 root www-data 0 Dec 25 10:18 pve2

Значення: Директорія nodes відображає поточних членів кластера; це перевірка цілісності файлової системи кластера.

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

Завдання 20: Якщо налаштовано HA, перевірте статус менеджера перед розблокуванням операцій

cr0x@pve1:~$ systemctl status pve-ha-lrm pve-ha-crm --no-pager
● pve-ha-lrm.service - PVE Local Resource Manager Daemon
     Active: active (running)
● pve-ha-crm.service - PVE Cluster Resource Manager Daemon
     Active: active (running)

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

Рішення: Перегляньте ресурси HA і переконайтеся, що ви не спричините несподівані міграції/запуски в момент повернення кворуму.

Шляхи відновлення: оберіть найменш ризиковий варіант

«Відновити кворум» — це не одна дія. Це сімейство кроків з різним радіусом ураження.
Ось як я обираю під тиском.

Шлях A (найкращий): відновити мережу і/або повернути відсутні вузли

Якщо вузли здорові, але від’єднані, виправте мережу кільця Corosync. Це найчистіше рішення, бо зберігає історію членства і уникає спецхаків з кворумом.
Типові винуватці: неправильний VLAN, невідповідність режиму бонду, невідповідність MTU, помилки LACP, правила брандмауера або перезавантаження комутатора з іншим профілем порту.

Коли зв’язність повернеться, членство Corosync має зійтися, votequorum стане кворумним, pmxcfs стане записуваним і життя повернеться.
Якщо членство продовжує флапати — не переходьте до змін конфігурації. Спочатку виправте стабільність.

Шлях B (прийнятний): тимчасово відкоригувати очікувані голоси

pvecm expected — інструмент, а не стиль життя. Він доречний коли:

• У вас багатовузловий кластер, але достатня кількість вузлів тимчасово офлайн, щоб швидко не відновити більшість.
• Ви можете довести, що інша сторона не зможе теж оголосити кворум (бо вона вимкнена, зафензена або відокремлена від спільного записуваного сховища).
• Вам потрібно терміново повернути можливість запису в кластер для господарських робіт (delnode, виправлення corosync.conf через pmxcfs, налаштування HA, планове обслуговування).

Це недоцільно, якщо ви лише підозрюєте, що інші вузли недоступні. Підозра — для детективних романів, а не для кворумної арифметики.

Шлях C (високий ризик): примус одного вузла до роботи

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

• Підтвердіть, що інші вузли вимкнені або зафензені.
• Відключіть дії HA, якщо вони можуть запустити дублікати.
• Якщо є спільне сховище — забезпечте, щоб лише ця сторона могла записувати (фензинг, закриття експорту, маскування LUN на SAN).

На практиці багато хто «виправляє» кворум примусом, а потім виявляє, що HA запустив VM на іншому боці, поки вони також запустили її локально.
Це не виправлення кворуму; це вибір власної катастрофи.

Шлях D (відновлення): коли кластер втратив цілісність

Якщо pmxcfs неконсистентний, кілька вузлів були примусово кворумовані ізольовано, або конфіг Corosync розійшовся, можливо, настав час відновлення:
оберіть вузол‑джерело правди, зробіть дамп конфігів, перевстановіть/відтворіть кластер, повторно приєднайте вузли і обережно відновлюйте HA.
Це повільніше, але часто єдиний спосіб відновити довіру до системи.

Три корпоративні міні‑історії (реалістичний біль включено)

Міні‑історія 1: Інцидент через неправильне припущення

Середня компанія експлуатувала три‑вузловий кластер Proxmox. Два вузли були в одному стояку; третій — «поруч» в іншому ряду.
Corosync використовував виділений VLAN. Хтось під час робіт на комутаторах тимчасово перевів кілька портів у дефолтний VLAN.
NIC кільця третього вузла опинився в неправильному VLAN. Вузол лишився працювати, VM продовжували працювати, моніторинг показував хост здоровим.

Наступного ранку хтось побачив «кластер не готовий — немає кворуму?» на одному з вузлів у стояку. Їхнє припущення: «pve3 напевно впав».
Вони не перевірили цього з pve3. На pve1 запустили pvecm expected 1 і миттєво повернули UI та доступ для запису в /etc/pve.
Перемога, правда?

Не зовсім. pve3 був живий і періодично підключався до pve2 через інший випадковий шлях через другу зміну в мережі.
Тепер були моменти, коли дві партії коротко вважали себе «владою». Зміни конфігурації (правила брандмауера і сховища) застосовувалися тільки з одного боку.

Коли VLAN виправили, кластер зібрався, і команда отримала новий набір дивних симптомів: VM зникали з UI на одному вузлі, визначення сховища не відповідали,
і періодично виникали помилки дозволів. Вони провели години, «виправляючи дозволи», які насправді були симптомами розбіжності конфігурацій під час примусового кворуму.

Виправлення було нудним: повернути очікувані голоси до реального значення, стабілізувати зв’язність кільця, а потім узгодити конфіг із бекапів і з одного обраного джерела правди.
Урок: не змінюйте математику кворуму, ґрунтуючись на припущеннях про стан вузлів. Доведіть факти.

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

Інша організація хотіла «прискорити трафік кластера» і вирішила ввімкнути jumbo‑фрейми для мережі віртуалізації.
Змінили MTU на мости та бонди Proxmox. Змінили на топ‑оф‑рек комутаторах.
Але не змінили на кількох проміжних VLAN‑транках, бо ті належали іншій команді і «звісно ж, стандартні».

Деякий час усе здавалося в порядку. Трафік VM був нормальним. Трафік сховища майже нормальний.
Проте Corosync почав флапати під навантаженням. Зміни членства відбувалися під час пікових вікон бекапів.
Кворум падав, повертався, знову падав. HA нервувала і припинила дії; оператори нервували і почали перезавантажувати вузли.

Флап був не випадковим. Трафік Corosync фрагментувався або відкидався на шляху з різним MTU.
Оскільки Corosync проєктувався для захисту коректності, він трактував втрату пакетів як загрозу членству. І це було правильно.

«Оптимізація» дала технічно швидший, але операційно менш надійний кластер. Вони повернули MTU 1500 на кільці Corosync і лишили jumbo лише для сховища,
де могли довести наскрізну консистентність.

Сенс: оптимізуйте там, де можете верифікувати. Corosync не вражають ваші графіки пропускної здатності, якщо пакети не доходять стабільно.

Міні‑історія 3: Сухо, але правильно, що врятувало день

Компанія, що працює з фінансами (тобто: аудити, контроль змін і довгі наради), експлуатувала п’яти‑вузловий Proxmox.
Вони мали звичку, яку інженери глузували: надрукований односторінковий рукбук з IP‑адресами кільця Corosync, портами комутаторів і IPMI‑адресами для кожного вузла.
Він оновлювався щокварталу, погоджувався і ламінувався. Так, ламінували.

Одного дня відмовив блок розподілу живлення і вивів з ладу два вузли. Інший вузол залишився живим, але втратив uplink свого кільця через подію перезбору spanning‑tree.
Кластер впав до двох доступних вузлів із п’яти. Немає кворуму. UI посварився. Телефони загорілися.

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

Uplink повернули, третій вузол приєднався, кворум повернувся природно (3/5), і вони уникнули будь‑яких примусових змін голосів.
Пізніше вони повернули два вимкнені вузли і дали кластеру зійтися. Мінімально драматично.

Урок: банальна інвентаризація і гігієна топології переважають імпровізацію. Ламіновані рукбуки — не круто, але пост‑мортем split‑brain ще менш приємний.

Поширені помилки: симптом → корінна причина → виправлення

1) Симптом: «кластер не готовий — немає кворуму?» після зміни мережі

Корінна причина: зламана мережа кільця Corosync (VLAN, MTU, бонд/LACP, брандмауер).

Виправлення: Використайте corosync-cfgtool -s, tcpdump і MTU‑ping для підтвердження втрати; відновіть консистентність L2/L3; не змінюйте голоси як першу реакцію.

2) Симптом: Один вузол бачить кворум, інший — ні

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

Виправлення: Порівняйте pvecm status на кожному вузлі; відмініть примусові налаштування голосів; переконайтеся, що всі вузли бачать однакове членство перед змінами.

3) Симптом: /etc/pve — тільки для читання або записи не вдаються

Корінна причина: відсутність кворуму або pmxcfs не в порядку через нестабільність corosync.

Виправлення: Відновіть кворум (бажано) або скористайтеся контрольованою зміною очікуваних голосів; потім підтвердіть стабільність членства перед редагуванням конфігурації кластера.

4) Симптом: Кворум періодично падає (флап)

Корінна причина: втрата пакетів, невідповідність MTU, нестабільне посилання, перевантажений інтерфейс кільця або проблеми віртуалізованої мережі.

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

5) Симптом: Двовузловий кластер втрачає кворум щоразу, коли один вузол перезавантажується

Корінна причина: Математика кворуму для двох вузлів: більшість з 2 — це 2; втрата одного голосу означає відсутність кворуму.

Виправлення: Додайте третій голос (qdevice або третій вузол). Якщо ви змушені працювати з двома вузлами, прийміть обмежену семантику кластера і плануйте процедури обслуговування ретельно.

6) Симптом: Після «виправлення кворуму» HA несподівано запускає/зупиняє VM

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

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

7) Симптом: Кластер здається в порядку, але вузли не можуть приєднатися або постійно перепідключаються

Корінна причина: Неправильні адреси в corosync.conf, дублікати node ID, застарілі імена хостів або невідповідні ключі аутентифікації.

Виправлення: Перевірте /etc/pve/corosync.conf на авторитетному вузлі; переконайтеся в унікальності nodeid і правильності адрес кілець; приєднуйте вузли чисто, а не хакерськи.

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

Чекліст 1: «Я щойно побачив no quorum» (зробіть це за 5 хвилин)

1. На ураженому вузлі: запустіть pvecm status. Зробіть скріншот або скопіюйте вивід у журнал інциденту.
2. Запустіть pvecm nodes, щоб підтвердити очікуване членство.
3. Запустіть corosync-cfgtool -s, щоб побачити, хто відключений.
4. Перегляньте journalctl -u corosync -n 50 на наявність повідомлень про лінк‑down.
5. З вузла пропінгуйте IP кільця відсутніх пір. Якщо ping не проходить — зупиніться і виправте мережу або живлення.
6. Якщо ping працює — запустіть tcpdump -ni <ring-if> udp port 5405 і робіть захоплення одночасно з піром.

Чекліст 2: «Чи варто використовувати pvecm expected?» (ворота рішення)

1. Чи відсутні вузли підтверджено вимкнені (IPMI) або зафензені? Якщо ні: не робіть цього.
2. Чи є спільне записуване сховище, яке могло б бути змонтоване обома партіями? Якщо так: не робіть цього, поки сховище не зафензене/заблоковане.
3. Чи потрібно вам терміново виконувати записи на рівні кластера (delnode, виправлення corosync.conf через pmxcfs, налаштування HA)? Якщо ні: зачекайте і спочатку виправте мережу.
4. Чи є у вас чіткий план повернення очікуваних голосів після повернення вузлів? Якщо ні: складіть план спочатку.

Чекліст 3: Контрольоване відновлення кворуму (доволі безпечний робочий процес)

1. Стабілізуйте членство: виправте мережу кільця, поки corosync-cfgtool -s не покаже підключених пір і логи перестануть флапати.
2. Підтвердіть кворум: pvecm status показує Quorate: Yes з очікуваними голосами, що відповідають реальному розміру кластера.
3. Перевірте можливість запису в /etc/pve: створіть і видаліть тестовий файл у /etc/pve (або перевірте редагування конфігів через UI).
4. Перевірте HA: впевніться, що сервіси HA здорові і немає несподіваних дій у черзі.
5. Лише потім: вносьте зміни в кластер (видаляйте мертві вузли, змінюйте конфігурацію сховища, оновлюйте правила брандмауера).

Чекліст 4: Якщо доводиться тимчасово працювати лише на одному вузлі

1. Підтвердіть, що інші вузли вимкнені через IPMI або фізично відключені від мережі кільця.
2. Якщо є спільне сховище: забезпечте, щоб лише цей вузол мав можливість запису (відключіть експорти, приберіть LUN‑мапінги або забезпечте фензинг).
3. Змінюйте очікувані голоси лише на необхідний час. Задокументуйте зміну в таймлайні інциденту.
4. Уникайте масових змін конфігурації кластера в примусовому стані; робіть мінімум для відновлення критичних навантажень.
5. Коли інші вузли повернуться — поверніть очікувані голоси і спостерігайте, як членство сходиться перед тим, як вмикати HA та автоматизацію.

FAQ

1) Чи означає «немає кворуму», що мої VM ушкоджені?

Зазвичай ні. Це означає, що координація кластера небезпечна. VM можуть продовжувати працювати, особливо на локальному сховищі.
Ризик корупції зростає, якщо ви запускаєте/зупиняєте ту саму VM з різних партій або якщо спільне сховище записуване з обох сторін.

2) Чи можу я просто перезапустити corosync, щоб виправити це?

Перезапуск corosync може допомогти, якщо процес застряг, але рідко вирішує корінну причину (мережевий розділ, MTU, брандмауер, мертвий пір).
Також перезапуск під час флапу може спричинити ще більше змін членства. Спочатку діагностуйте; перезапускайте свідомо.

3) Що саме робить «pvecm expected»?

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

4) Чому двовузлові кластери Proxmox такі проблемні?

Бо більшість з 2 — це 2. Якщо один вузол недоступний, ні один не може довести, що має більшість.
Без вирішувача найбезпечніша поведінка — припинити записи в кластер. Саме це ви бачите.

5) Мені потрібен qdevice?

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

6) Чому /etc/pve особливий?

Це pmxcfs: файлова система кластера, змонтована через FUSE і підкріплена розподіленим станом. Вона призначена для запобігання небезпечним записам при невизначеному членстві.
Трактуйте її як базу даних, а не як локальну папку.

7) Чому після повернення кворуму все трохи «повільно»?

Відбувається відновлення членства, узгодження стану, перерахунок HA і відновлення підключень сервісів.
Якщо був флап, може накопичитися черга повторів. Дайте системі хвилину, але слідкуйте за логами на предмет подальшого флапу.

8) Як зрозуміти, що я ризикую split‑brain?

Якщо ви не можете довести, що лише одна партія може отримати доступ до спільних записуваних ресурсів, ризик є.
Інший тривожний знак: різні вузли показують різне членство або різні очікувані голоси. Саме так split‑brain починається — тихо.

9) Чи безпечно редагувати corosync.conf безпосередньо?

Це безпечно лише коли кластер кворумний (щоб зміна поширилась консистентно) або під час контрольованого відновлення одного вузла, коли ви розумієте,
що створюєте нове джерело правди. Випадкові правки під час відсутності кворуму — відмінний спосіб отримати неконсистентний стан кластера.

10) Що робити, якщо лишився лише один вузол і мені потрібен UI для керування VM?

Ви можете використати expected votes, щоб повернути кворум на цьому вузлі, але лише після того, як підтвердите, що інші вузли вимкнені або зафензені.
Після цього робіть мінімальні зміни і сплануйте, як коректно повернути інші вузли.

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

Втрата кворуму — це Proxmox, який робить вам послугу: він відмовляється дозволяти створення неконсистентного стану кластера.
Ваше завдання — відновити зв’язність і членство спочатку, а вже потім повертати зручність.

Наступні кроки, які дійсно допомагають:

1. Пройдіть швидкий план діагностики і визначте, чи помилка викликана живленням, мережею чи розходженням конфігурації.
2. Виправте стабільність мережі Corosync перед зміною голосів. Розглядайте флап як інцидент мережі, а не як виключно Proxmox‑інцидент.
3. Якщо вам доводиться використовувати pvecm expected, робіть це як контрольовану, документовану, обмежену в часі дію з фактами фензингу.
4. Після стабілізації зменшіть майбутні ризики: уникайте двовузлових кластерів без вирішувача, тримайте Corosync на чистій мережі і документуйте топологію так, ніби це важливо.

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