Кластер Proxmox: чому Corosync виглядає нормально, а ваш кластер гине

February 28, 2026 • February 28, 2026 • Читання: 6 хв • Views: 1

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

Ви відкриваєте GUI Proxmox і він підвішується. Міграції зупиняються. HA фліптає. Віртуальні машини працюють — поки не перестануть.
Потім ви перевіряєте очевидне: кворум Corosync. Воно каже, що все в порядку.

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

Що таке Corosync (і чим воно не є)

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

Proxmox будує багато залежностей на «вузли бачать одне одного»:
pmxcfs (кластерна файлова система Proxmox, що зберігає стан конфігурації),
pveproxy та pvedaemon (сервіси API/UI),
pve-ha-lrm/crm (логіка HA),
pvestatd (статистика),
та те, що робить ваш бекенд сховища сьогодні (ZFS, iSCSI, NFS, Ceph, локальний LVM… оберіть улюблену головний біль).

Членство Corosync може залишатися стійким навіть якщо:

pmxcfs застрягає, чекаючи операцій FUSE і ви не можете застосувати зміни конфігурації
мережа втрачає пакети або має спайки латентності — просто не настільки, щоб втратити кворум
розбіжність часу викликає тонкі проблеми з аутентифікацією та fencing
затримки в роботі сховища заморожують потоки QEMU і міграції тайм-аутяться
демони управління блокуються через DNS, PAM/LDAP або виклики файлової системи

Дві сухі істини, що рятують кар’єру

Кворум бінарний; здоров’я — ні. Ви можете мати кворум і водночас бути непрацездатними.
Більшість «проблем кластера» Proxmox — це проблеми латентності. Не завжди мережа — часто сховище або конкуренція за CPU, що проявляється як пропущені heartbeat’и в інших місцях.

Цікаві факти та історичний контекст (системи мають багаж)

Corosync походить від проєкту OpenAIS, який прагнув реалізувати концепції інтерфейсу прикладних програм для кластерів у Linux.
Totem — шар групової комунікації Corosync; його механізм токена — причина, чому «налаштування token timeout» дає відчуття влади — а потім жалю.
Кворум у Corosync — це задача голосування (через votequorum), а не система оцінки здоров’я; він не вимірює рівень сервісу.
pmxcfs — це файлова система, основана на FUSE; вона чудова для маленьких конфігураційних файлів і жахлива для вашого терпіння, коли блокується.
«Кластерна файлова система» Proxmox — не загальна файлова система; це репліковане сховище конфігів. Спроба використовувати її як загальне сховище — прямий шлях до терапії.
Уникнення split-brain — дизайн-перевага для більшості стеків кластерів; Proxmox зазвичай віддає перевагу «зупинити запис» над «мовчазною корупцією».
Історично в Ceph болючим був ефект ампліфікації дрібних записів; сучасні версії значно покращилися, але ваша мережа та диски все одно вирішують, чи це Ferrari або газонокосарка.
Планування ядра Linux і тиск I/O можуть створити режими відмов «все виглядає вгору, але нічого не рухається» — особливо на перевантажених хостах.

Одна цитата, яку варто приклеїти до монітора:
Надія — це не стратегія. — ген. Гордон Р. Салліван

Жарт №1: Corosync, що каже «кворум», коли ваш GUI зависає — як сигналізатор диму, який говорить «батарея ОК» під час пожежі на кухні.

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

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

По-перше: це проблема членства мережі чи зависання панелі управління?

Перевірте стабільність членства Corosync (pvecm status, corosync-cfgtool -s).
Перевірте, чи pmxcfs відповідає (pvecm updatecerts зависне, якщо кластерна фс застрягає; також прості читання у /etc/pve можуть блокуватися).
Перевірте, чи API/UI заблоковано (systemd статус та journal для pveproxy/pvedaemon).

По-друге: який зараз домінуючий джерело латентності?

Латентність мережі/втрата пакетів (ping -f — не відповідь; використовуйте mtr, ethtool -S, лічильники на комутаторі).
Латентність сховища (ZFS zpool iostat -v, Ceph ceph -s та slow ops, статистика NFS-клієнта).
CPU steal / черга виконання / тиск пам’яті (середнє навантаження — замало; перевіряйте vmstat, top, pressure-stall-information, якщо доступно).

По-третє: щось «корисно» пробує нескінченно повторюватися?

DNS та LDAP-запити (входи в GUI зависають, API-виклики блокуються).
Флапінг multipath (шляхи iSCSI вмирають і повертаються як мильна опера).
Ceph backfill/recovery насичує кластер (він «здоровувато» виглядає, але повільний настільки, що все інше тайм-аутиться).

Швидкі рішення для триажу

Якщо членство стабільне, але pmxcfs заблокований: розглядайте це як відмову контрольної площини. Припиніть змінювати конфігурацію і знайдіть затримку.
Якщо спайки латентності сховища: зупиніть міграції, резервні копії, все, що множить I/O. Відновіть базовий стан спочатку.
Якщо мережеві втрати/латентність зростають: віддайте пріоритет стабілізації кільцевої мережі понад «налаштуванням token timeout». Налаштування — останній засіб, а не лікування.

Режими відмов, коли Corosync виглядає здоровим

1) pmxcfs застрягає: Corosync в порядку, але запис конфігів блокується

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

Коли pmxcfs повільний або зупинений, ви помітите такі симптоми:

Дії в GUI зависають (створення ВМ, редагування сховища, зміни HA)
Команди qm/pct фризяться при зверненні до конфігів
SSH працює; ВМ продовжують працювати; але управління «під водою»

Типові причини: екстремальний тиск на CPU, deadlock FUSE, затримки диска, що впливають на локальний журнал, або затримки повідомлень corosync, які ще не порушили кворум.

2) Токен-таймаути не зламались; ваш бюджет латентності — так

Механізм токена Corosync очікує своєчасної доставки повідомлень. Ви можете мати стабільний кворум навіть за періодичних спайків латентності, які
не перевищують ваш token timeout — але ці спайки все одно достатньо довгі, щоб заморозити міграції, резервні копії й рішення HA.

Класичний патерн: ви «виправили» corosync, збільшивши token timeout. Членство припинило фліпати.
Тим часом кластер став толерантним до латентності настільки поганої, що все інше страждає. Ви не виправили мережу.
Ви просто навчились Corosync не скаржитися.

3) Затримки сховища заморожують гіпервізор, а не Corosync

Найнеприємніші інциденти Proxmox викликані сховищем. Запис ВМ блокується в ядрі або QEMU,
хост відчуває I/O wait, і раптом всі демони управління відповідають ніби з тунелю.

Corosync все ще може обмінюватися heartbeat’ами, якщо CPU час від часу отримує планування. Цього достатньо для збереження кворуму.
Але цього недостатньо для чуйної системи.

4) Розбіжність часу: повільний яд

Проблеми з NTP/chrony не завжди ламають кворум. Але вони можуть зламати все, що залежить від монотонності часу:
TLS-ручне рукостискання, аутентифікація, кореляція логів, рішення fencing і «чому цей вузол думав, що він на 5 хвин у майбутньому?»

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

5) HA не «вимкнено», воно нерішуче при частковій відмові

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

6) GUI повільний, бо pveproxy чекає на щось дурне

Типові винуватці: зворотні DNS-запити, timeouts LDAP/PAM, заблоковані читання в /etc/pve,
або насичений однопоточний шлях десь у обробці запитів.

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

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

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

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

Quorum information
------------------
Date:             Tue Feb  4 10:12:31 2026
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

Значення: Corosync бачить 3 вузли, кворум досягнуто, голоси відповідають очікуванню.
Рішення: Якщо тут «Yes», але ви все одно маєте проблеми, припиніть звинувачувати кворум і почніть вимірювати латентність, pmxcfs та сховище.

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

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
        id      = 10.10.10.11
        status  = ring 0 active with no faults
RING ID 1
        id      = 10.10.20.11
        status  = ring 1 active with no faults

Значення: Кільця активні. «No faults» не означає «хороша латентність».
Рішення: Якщо кільця показують помилки періодично, спочатку виправте L2/L3 проблеми (bonding, MTU, помилки на комутаторі), перш ніж чіпати налаштування Corosync.

Завдання 3: Прочитати скарги Corosync (вони тонкі)

cr0x@server:~$ journalctl -u corosync -S -2h --no-pager | tail -n 30
Feb 04 09:41:02 pve01 corosync[1267]:   [KNET  ] link: host: 2 link: 0 is down
Feb 04 09:41:03 pve01 corosync[1267]:   [KNET  ] host: 2 link: 0 recovered
Feb 04 09:58:19 pve01 corosync[1267]:   [TOTEM ] Token has not been received in 1800 ms
Feb 04 09:58:19 pve01 corosync[1267]:   [TOTEM ] A processor failed, forming new configuration.

Значення: Короткі пропади лінків і затримки токена. Ви все ще можете залишатися кворумними під час переналаштувань.
Рішення: Якщо ви бачите попередження про токен, розглядайте це як реальний інцидент: розслідуйте мережеві помилки, голодування CPU або IRQ-шторм.

Завдання 4: Підтвердити, що pmxcfs змонтовано і відповідає

cr0x@server:~$ 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)

Значення: Точка монтування існує. Вона все ще може бути повільною.
Рішення: Далі — протестуйте швидкість читання/запису.

Завдання 5: Перевірити, чи операції в /etc/pve зависають

cr0x@server:~$ time ls -l /etc/pve/nodes/pve01/qemu-server | head
total 8
-rw-r----- 1 root www-data 1324 Feb  4 09:55 101.conf

real    0m0.012s
user    0m0.002s
sys     0m0.004s

Значення: Швидка відповідь — нормально. Якщо це займає секунди або зависає, pmxcfs давиться.
Рішення: Якщо повільно/зависає лише на одному вузлі — підозрюйте локальний ресурсний тиск. Якщо повільно на всіх вузлах — підозрюйте латентність corosync або конфлікт pmxcfs по всьому кластеру.

Завдання 6: Перевірити здоров’я pmxcfs та сервісів pve

cr0x@server:~$ systemctl status pve-cluster pvedaemon pveproxy --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Tue 2026-02-04 08:01:12 UTC; 2h 11min ago
   Main PID: 1123 (pmxcfs)
      Tasks: 13 (limit: 154263)
     Memory: 52.4M
        CPU: 2min 1.911s

● pvedaemon.service - Proxmox VE API Daemon
     Active: active (running)

● pveproxy.service - Proxmox VE API Proxy Server
     Active: active (running)

Значення: Сервіси «running». Це не означає, що вони відповідають.
Рішення: Якщо «active», але UI зависає — перевіряйте логи та блокуючі виклики (наступні завдання).

Завдання 7: Перевірити, чи pveproxy тайм-аутиться на auth/DNS

cr0x@server:~$ journalctl -u pveproxy -S -2h --no-pager | tail -n 25
Feb 04 10:01:18 pve02 pveproxy[2044]: proxy detected vanished client connection
Feb 04 10:02:41 pve02 pveproxy[2044]: authentication failure; rhost=10.10.30.50 user=admin@pam msg=timeout
Feb 04 10:02:41 pve02 pveproxy[2044]: failed login attempt; user=admin@pam

Значення: Таймаути авторизації можуть бути спричинені повільним LDAP/PAM/DNS, а не неправильними паролями.
Рішення: Якщо бачите таймаути — перевірте розв’язування імен і доступність директорій; не «перезапускайте випадкові сервіси» одразу.

Завдання 8: Перевірити синхронізацію часу і розбіжність між вузлами

cr0x@server:~$ chronyc tracking
Reference ID    : 192.0.2.10
Stratum         : 3
Ref time (UTC)  : Tue Feb 04 10:11:32 2026
System time     : 0.000347812 seconds slow of NTP time
Last offset     : -0.000112345 seconds
RMS offset      : 0.000251901 seconds
Frequency       : 12.345 ppm fast
Leap status     : Normal

Значення: Гарна синхронізація показує малі зсуви та «Normal» у leap status.
Рішення: Якщо зсув великий або leap status не нормальний — виправляйте час негайно. Не аналізуйте поведінку кластера, поки години не погоджені.

Завдання 9: Виявити тиск CPU та I/O wait, що виснажує все

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 812344  54212 9248120    0    0     4    21  920 1800  6  2 88  4  0
 3  1      0 790112  54180 9249008    0    0   120  8020 1100 2100  9  3 44 44  0
 4  2      0 780004  54140 9249912    0    0   200  9100 1200 2400  8  4 36 52  0

Значення: Високий wa (I/O wait) вказує, що система заблокована на очікуванні сховища. Високий b свідчить про заблоковані процеси.
Рішення: Якщо wa постійно високий під час інциденту — припиняйте шукати помилки Corosync і переходьте до діагностики сховища.

Завдання 10: Здоров’я ZFS і латентність на вузлі з локальним ZFS

cr0x@server:~$ zpool status -x
all pools are healthy

Значення: Відомих помилок пулу немає. Але це не каже про латентність.
Рішення: Якщо повільно — перевірте iostat та поведінку sync наступним кроком.

cr0x@server:~$ zpool iostat -v 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
rpool       320G   1.45T     80   1200  5.4M   98.2M
  mirror    320G   1.45T     80   1200  5.4M   98.2M
    nvme0n1    -      -      40    610  2.7M   49.1M
    nvme1n1    -      -      40    590  2.7M   49.1M

Значення: Інтенсивні записи. Якщо це корелює з зависанням панелі управління — можливо, ви насичуєте сховище.
Рішення: Розгляньте обмеження пропускної здатності резервних копій/реплікації і перевірте наявність sync-записів (бази даних, NFS sync або неправильно налаштований ZFS).

Завдання 11: Стан кластера Ceph (якщо ви його використовуєте)

cr0x@server:~$ ceph -s
  cluster:
    id:     1b2c3d4e-5555-6666-7777-88889999aaaa
    health: HEALTH_WARN
            12 slow ops, oldest one blocked for 38 sec
  services:
    mon: 3 daemons, quorum a,b,c (age 2h)
    mgr: x(active, since 2h)
    osd: 9 osds: 9 up (since 2h), 9 in (since 2h)
  data:
    pools:   6 pools, 512 pgs
    usage:   12 TiB used, 18 TiB / 30 TiB avail
    pgs:     512 active+clean

Значення: «slow ops» — це ввічливий спосіб Ceph повідомити, що ваше сховище страждає.
Рішення: Розглядайте slow ops як продакшн-проблему. Призупиніть інтенсивні I/O операції. Діагностуйте затримки OSD, мережу та налаштування recovery/backfill.

Завдання 12: Перевірити помилки мережі на інтерфейсах Corosync

cr0x@server:~$ ip -s link show dev bond0
3: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    1234567890  987654      12      0       0       0
    TX:  bytes packets errors dropped carrier collsns
    2233445566  876543       0      0       0       0

Значення: RX errors відмінні від нуля — підказка. Дванадцять помилок можуть бути «ні про що» або вершиною айсберга — корелюйте з часом інциденту.
Рішення: Якщо помилки зростають під час інцидентів — перевірте кабелі, оптику, прошивку NIC, порти комутатора і узгодженість MTU по всьому шляху.

Завдання 13: Виміряти латентність і втрати між вузлами (без самообману)

cr0x@server:~$ mtr -r -c 50 -n 10.10.10.12
Start: 2026-02-04T10:12:01+0000
HOST: pve01                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.10.12               0.0%    50    0.4   0.6   0.3   2.1   0.3

Значення: Добре: низьке середнє, низький максимум, без втрат.
Рішення: Якщо найгірші значення підскакують до десятків/сотень мс або з’являється втрата — Corosync може все ще виглядати «в порядку», тоді як решта тайм-аутиться. Виправляйте якість мережевого шляху.

Завдання 14: Перевірити застряглі завдання і чому міграції/резервні копії не завершуються

cr0x@server:~$ pvesh get /cluster/tasks --limit 5
[
  {
    "endtime": 0,
    "id": "UPID:pve02:0000A1B2:00C3D4E5:67A1B2C3:vzdump:105:root@pam:",
    "node": "pve02",
    "pid": 41394,
    "starttime": 1707040801,
    "status": "running",
    "type": "vzdump",
    "user": "root@pam"
  }
]

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

Завдання 15: Побачити нерішучість менеджера HA

cr0x@server:~$ ha-manager status
quorum OK
master pve01 (active, Tue Feb  4 10:12:12 2026)
lrm pve01 (active, Tue Feb  4 10:12:11 2026)
lrm pve02 (active, Tue Feb  4 10:12:10 2026)
lrm pve03 (active, Tue Feb  4 10:12:09 2026)

service vm:101 (started)
service vm:102 (freeze) (request_stop)
service ct:203 (started)

Значення: «freeze» вказує, що HA не може просунутись — часто через конкуренцію за блокування, недоступність сховища або застряглі агентські дії.
Рішення: Діагностуйте сховище і блокування конфігів у ресурсів. Не «форсуйте» дії HA, поки не знаєте, чого вони чекають.

Завдання 16: Знайти конфлікт блокувань конфігів (тихий вбивця)

cr0x@server:~$ ls -l /var/lock/pve-manager
total 0
-rw-r----- 1 root www-data 0 Feb  4 10:08 vzdump.lock
-rw-r----- 1 root www-data 0 Feb  4 10:09 pve-storage-lock

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

Три міні-історії з реальних кейсів

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

Середня компанія експлуатувала три-вузловий Proxmox кластер для внутрішніх сервісів. Усього було «резервовано»: подвійні NIC, два комутатори,
RAID на гіпервізорах. Вони пишалися цим. І заслужили.

Потім одного понеділка GUI почав час від часу замерзати. Міграції зависали. Резервні копії, що зазвичай робилися за хвилини, тягнулися години.
Рятівник виконав ритуал: перевірив pvecm status. Кворум. Жодного відвалу вузла. Corosync виглядав чистим.
Тож вони припустили, що мережа кластера в порядку і пішли шукати в логах UI Proxmox.

Неправильне припущення: «Якщо Corosync має кворум, мережа кластера здорова».
Кворум лише означав, що вузли могли обмінюватися достатньою кількістю повідомлень, щоб погодитись щодо членства. Це нічого не казало про tail latency.

Насправді винен був один порт комутатора, що ламався частково — не падав лінк повністю. Він вводив періодичні мікробурсти і CRC-помилки.
Knet-лінки Corosync швидко відновлювалися, тож членство залишалось стабільним. Але записи в pmxcfs затримувались, а API постійно чекало відповіді кластерної файлової системи.

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

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

Інша організація мала Proxmox+Ceph розгортання. Вони хотіли менше попереджень «Corosync token timeout» під час пікових навантажень.
Хтось запропонував збільшити token timeout і час консенсусу, щоб Corosync витримував тимчасові спади.
Зміна зменшила шум у логах. Усі святкували. Невдовзі.

Через тижні обслуговування сховища спричинило recovery Ceph, що наситив бекенд-мережу.
Кластер залишився кворумним. І це була проблема. Вузли залишались у членах, стаючи поступово нефункціональними через I/O wait.
Рішення HA затримувались. Міграції нарощувались у чергу. GUI напівпрацював — достатньо, щоб створити хибну впевненість.

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

Остаточне виправлення не було лише відкатом таймаутів. Вони розділили трафік: Corosync — на низьколатентні незавантажені лінки;
recovery Ceph налаштували так, щоб не насичувати мережу; додали оповіщення за tail latency та slow ops, а не лише за member flaps.
Token timeout повернули ближче до дефолту. Шум у логах виріс; реальні відмови зменшились.

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

У регульованому середовищі Proxmox використовували для набору критичних робочих навантажень. Команда була консервативною до дратування.
Вони дотримувались суворого правила: кожен вузол мав OOB-управління, документовану процедуру «безпечного вимкнення»,
і квартальний тренінг з відновлення після часткових відмов без імпровізації.

Під час події з електропостачання один вузол повернувся з деградованим пулом сховища і періодичними I/O помилками. Кворум Corosync тримався,
але операції управління стали ненадійними: іноді конфіги зависали, резервні копії ставали, а HA вагався перемістити робочі навантаження.

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

Нудна практика — документовані кроки, відомий порядок дій і відмова від «просто клацнути навмання» — не дала апаратній проблемі перетворитись на інцидент усього кластера. Бізнес майже не помітив.
Команда повернулась до рутинного дратування своєї власної процедури — і це якраз те, чого ви хочете від роботи з надійністю.

Жарт №2: Якщо ваш кластер працює на «племінному знанні», вітаю — ви винайшли єдину точку відмови з почуттями.

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

1) Симптом: Кворум «Yes», але дії в GUI зависають

Корінь: Латентність pmxcfs або конкуренція за блокування; API-виклики блокуються, чекаючи /etc/pve.
Виправлення: Протестуйте латентність ls /etc/pve на кількох вузлах; перевірте CPU/I/O wait; зменшіть навантаження; вирішіть застряглі завдання, що тримають блокування.

2) Симптом: HA показує «freeze» або повторні спроби рестарту

Корінь: HA не може підтвердити стан через таймаути сховища, блокування або затримані оновлення кластерної файлової системи.
Виправлення: Перевірте ha-manager status, завдання і здоров’я сховища; стабілізуйте сховище спочатку; уникайте форсованого старту, поки стан не буде узгоджений.

3) Симптом: Міграції стартують, а потім зависають на фіксованому відсотку

Корінь: Бекенд сховища не витримує (Ceph slow ops, латентність NFS, тиск sync в ZFS), або пропускна здатність мережі колапсує під навантаженням.
Виправлення: Виміряйте латентність сховища, перевірте Ceph slow ops, перевірте помилки NIC; призупиніть інші I/O-важкі операції; забезпечте, щоб мережа міграцій не була спільною з насиченим каналом сховища.

4) Симптом: Логи Corosync показують попередження про токен, але кворум тримається

Корінь: Спайки tail latency через конгестію, проблеми IRQ або голодування CPU; переналаштування проходять без повної втрати членства.
Виправлення: Розглядайте це як інцидент мережі/хоста; перевірте ip -s link, ethtool -S, mtr і CPU wait; виправляйте підлягаючий шлях.

5) Симптом: Випадкові «permission denied» або TLS/auth помилки після «нічого не змінювалося»

Корінь: Розбіжність часу між вузлами; вікна валідації сертифікатів порушені; Kerberos/LDAP, що чутливі до часу, падають.
Виправлення: Виправте chrony/NTP, перевірте розбіжність на всіх вузлах, потім повторно протестуйте потоки аутентифікації. Не крутить сертифікати як перший крок.

6) Симптом: Лише один вузол «повільний», але не виходить із кластера

Корінь: Локальний апаратний або ядровий збій: помилки диска, деградація ZFS, помилки NIC, тиск пам’яті.
Виправлення: Порівняйте метрики й логи з здоровим вузлом; евакуюйте робочі навантаження; діагностуйте апаратне забезпечення; не дозволяйте хворому вузлу отруїти контрольну площину.

7) Симптом: Усе погіршується під час резервних копій

Корінь: I/O резервних копій насичує сховище або мережу; commit снапшотів повільний; блокування тримаються довше; операції управління накопичуються.
Виправлення: Рознесіть резервні копії в часі, обмежте їхню пропускну здатність, розділіть трафік резервного копіювання і забезпечте резерв про запас у сховищі. Резервні копії мають бути нудними, а не тестом навантаження.

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

Контрольний список A: Коли кластер «відчувається повільним», але кворум в порядку

Заморозьте зміни. Жодних нових конфігів сховищ, жодних правок firewall, жодних перестановок HA, поки ви не зрозумієте затримку.
Виберіть один «поганий» вузол і один «хороший» вузол. Запустіть ті самі перевірки; відмінності — золото.
Підтвердіть стабільність членства: pvecm status, corosync-cfgtool -s, журнал Corosync.
Перевірте відгук pmxcfs: швидке ls під /etc/pve з вимірюванням часу.
Перевірте блокування і застряглі задачі: pvesh get /cluster/tasks, інспект файлів блокувань.
Виміряйте тиск хоста: vmstat, load, I/O wait, пам’ять.
Виміряйте якість мережі: лічильники помилок + mtr між вузлами на кільці Corosync.
Виміряйте здоров’я сховища: ZFS iostat/status або Ceph slow ops.
Лише після цього розглядайте налаштування. Налаштування без вимірювань — як побудувати «стабільну» повільну катастрофу.

Контрольний список B: Стабілізувати спочатку, потім відновлювати функціональність

Зупиніть множники навантаження: призупиніть міграції, відкладіть резервні копії, обмежте recovery/backfill у Ceph (обережно).
Ізолюйте хворий вузол: якщо один вузол має помилки/латентність, мігруйте звідти те, що можете, і виключіть його з рішень HA, поки не виправите.
Перевірте синхронізацію часу: погодьте годинники перед інтерпретацією логів і подій fencing.
Відновіть базову мережу: усуньте втрати пакетів, CRC-помилки, невідповідність MTU і перевантажені лінки.
Відновіть базове сховище: очистіть помилки диска, відновіть деградовані пули, усуньте slow ops, забезпечте вільне місце.
Поступово відновлюйте операції: міграції/резервні копії по одній, спостерігайте за латентністю та логами.

Контрольний список C: Загартування, щоб це не повторилось

Розділіть класи трафіку: Corosync на низьколатентних лінках; сховище на окремій мережі; міграції окремо, якщо можливо.
Оповіщення за tail latency, а не тільки «up/down». Кворум-алярми необхідні, але недостатні.
Планування ємності для резервних копій і recovery. Якщо ваш кластер не витримує recovery плюс нормальне навантаження — він не стійкий.
Тестуйте сценарії відмов. Практикуйте «один вузол повільний», «один лінк флапає», «slow ops сховища». Реальні інциденти не повинні бути вашим першим репетиційним запуском.

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

1) Чому `pvecm status` показує «Quorate: Yes», коли GUI непридатний?

Тому що кворум — це про членство й голосування, а не про вчасність відповіді. GUI залежить від pmxcfs та API-демонів, які можуть блокуватись через I/O, блокування, DNS або латентність сховища.

2) Якщо Corosync не показує помилок, чи мережа все одно може бути проблемою?

Так. Короткі спайки, мікробурсти, CRC-помилки і джиттер можуть зруйнувати tail latency без втрати членства. Перевіряйте лічильники і mtr, а не тільки стан кільця.

3) Чи варто збільшувати token timeout Corosync, щоб зупинити флапінг?

Тільки після того, як ви доведете, що мережа та планування хоста стабільні і вам все ще це потрібно. Збільшення таймаутів може приховати реальні проблеми латентності і затримати виявлення відмов.

4) Який найшвидший спосіб зрозуміти, чи pmxcfs — вузьке місце?

Поміряйте просте ls у /etc/pve на кількох вузлах. Якщо воно повільне або зависає — pmxcfs причетний. Далі перевіряйте CPU і I/O wait.

5) Чи можуть проблеми зі сховищем реально вплинути на Corosync і управління кластером?

Абсолютно. Затримки у сховищі створюють I/O wait, що затримує процеси і планування. Corosync може продовжувати обмінюватися достатніми повідомленнями, але pmxcfs та API-виклики постраждають.

6) Як розбіжність часу ламає Proxmox-кластер, якщо кворум при цьому в порядку?

Дрейф може зламати TLS/aутентифікацію, заплутати логи і спричинити несумісні рішення HA чи fencing. Виправте час перед глибшою діагностикою.

7) Чому міграції зависають частіше, ніж «звичайний час виконання ВМ» під час інцидентів?

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

8) Що робити, якщо один вузол повільний, але все ще в кластері?

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

9) Чи безпечно перезапускати corosync або pmxcfs під час інциденту?

Іноді так, але це не перший крок. Перезапуск може спричинити зміни членства і вирубку блокувань. Спочатку стабілізуйте мережу/сховище, потім перезапускайте з чіткою метою.

10) Який найкращий «один метрик» для оповіщення про ці проблеми?

Одного немає. Комбінуйте: відгук pmxcfs (синтетичні перевірки), втрата/джиттер мережі, латентність сховища/slow ops і I/O wait хоста. Кворум сам по собі — лише заспокійливий показник.

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

Якщо ви експлуатуєте Proxmox у продакшні, ось практичний шлях, що реально змінює результат:

Додайте синтетичну перевірку pmxcfs: вимірюйте і сповіщайте, якщо ls /etc/pve перевищує невеликий поріг на будь-якому вузлі.
Сповіщайте про мережеві помилки на інтерфейсах Corosync: CRC-помилки, дропи, флапінг лінків. Це виявляє деградації «кворум в порядку» раніше.
Сповіщайте про латентність сховища: аномалії ZFS iostat, Ceph slow ops, повтори NFS-клієнта. Сховище — тиха більшість таких інцидентів.
Тримайте таймаути Corosync розумними: не використовуйте налаштування як пластир для поганої мережі. Якщо налаштовуєте — документуйте чому і які вимірювання це виправдовують.
Проведіть відпрацювання відмов: симулюйте насичену мережу сховища або флапінг лінк і практикуйте «спочатку стабілізація». Майбутнє «ви» буде вдячне і трохи менш втомлене.

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