Proxmox «pve-cluster.service failed»: як повернути стек кластера в робочий стан

Що насправді означає «pve-cluster failed»

pve-cluster — це сервіс, який запускає Proxmox Cluster File System (pmxcfs). pmxcfs — це файловий простір на базі FUSE, змонтований у /etc/pve. Якщо він не змонтований або не працює коректно, Proxmox втрачає доступ до конфігурації кластера в тому вигляді, в якому її очікують. Це включає:

• Глобальні налаштування кластера, визначення сховищ, стан HA
• Конфігурацію файрволу (в межах кластера)
• Членство вузлів і розповсюдження конфігурації Corosync
• Файли конфігурацій ВМ і CT (у кластерному режимі)

Під капотом pmxcfs сильно залежить від Corosync (членство в кластері, кворум, обмін повідомленнями). Corosync — це не «приємна опція». Це рефері. Якщо немає кворуму, pmxcfs стає обережним, щоб уникнути split-brain записів.

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

Операційна позиція, яку я рекомендую: сприймайте pve-cluster.service failed як симптом, а не діагноз. Реальний діагноз зазвичай належить до одного з цих кластерів причин:

• Проблеми з кворумом/членством (мережа, кількість вузлів, невідповідність конфігурації Corosync)
• Локальні обмеження системи (диск заповнений, вичерпано inode, тиск пам’яті, ліміти дескрипторів файлів)
• Проблеми часу (дрейф NTP робить Corosync невдоволеним; TLS ламається; журнали вводять в оману)
• Пошкоджена або непослідовна конфігурація кластера (поганий corosync.conf, часткові оновлення, застарілі сертифікати вузлів)
• Помилки оператора (використання примусових прапорів у невірний момент, «швидкі виправлення», що тихо створюють split-brain)

Цитата, яку варто тримати на слуху: Надія — це не стратегія. — генерал Гордон Р. Салліван. Це не цитата з Proxmox, але вона пасує кожному чергуванню.

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

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

Перше (60 секунд): визначте, чи змонтовано /etc/pve і чи є кворум у Corosync

• Перевірте, чи змонтовано pmxcfs: findmnt /etc/pve
• Перевірте Corosync/кворум: pvecm status і corosync-quorumtool -s
• Перевірте точну причину відмови: systemctl status pve-cluster + journalctl -u pve-cluster -b

Друге (2–5 хвилин): перевірте «нудні базові речі», що вбивають сервіси кластера

• Дисковий простір/inode: df -h, df -i
• Тиск пам’яті: free -h, dmesg -T | tail
• Синхронізація часу: timedatectl, chronyc tracking (або systemctl status systemd-timesyncd)
• Доступність мережі на лінках Corosync: ping/MTU перевірки між вузлами

Третє (5–15 хвилин): оберіть режим відновлення

• Якщо кворум можна відновити: виправте мережу/конфіг/час і підніміть Corosync у нормальному режимі. Потім перезапустіть pve-cluster.
• Якщо кворум швидко відновити не вдається: оберіть між безпечними операціями лише для читання та контрольованим тимчасовим одновузловим режимом (лише якщо ви розумієте наслідки).
• Якщо це двовузловий кластер: вирішіть, чи використовувати qdevice (краще), або короткостроковий хак з expected-votes (ризиковано, але інколи необхідно).

Жарт №1: Якщо перший крок відновлення — «перезавантажити все», ви не діагностуєте — ви виконуєте інтерпретативний танець для богів аварій.

Цікаві факти й історичний контекст (які справді допомагають у налагодженні)

1. pmxcfs — це FUSE-файлова система. Це означає, що директорія /etc/pve, яку ви бачите, — користувацький монтування; якщо вона впала, реальні файли на диску лежать в іншому місці, і поведінка змінюється.
2. Proxmox рано перейшов до центрування конфігурації на кластері. Це робить управління багатовузловими середовищами розумним, але також означає, що здоров’я кластера впливає на базові операції навіть одного вузла.
3. Дизайн Corosync орієнтований на кворум. Він віддає перевагу відмові від записів, ніж ризику роздвоєння мозку (split-brain). Через це відмови часто виглядають «чересчур суворими».
4. Двовузлові кластери внутрішньо незручні. Без третього голосу (qdevice або свідок) ви завжди на один відмовлений вузол від філософської дискусії про те, хто «клaster».
5. Кворум — це не про більшість аптайму, а про безпечне членство. Ви можете мати 99% сервісів запущеними і все одно бути «небезпечним для запису стану кластера».
6. Дрейф годинника може маскуватися під мережеву відмову. Corosync і TLS поводяться погано, коли час невірний; журнали стають недостовірними, і кількість повторів зростає.
7. Проблеми з повним диском сильніше вражають кластери. Повний кореневий файловий простір може завадити записам стану, логуванню або внутрішнім механізмам pmxcfs, спричиняючи каскадні відмови сервісів, які виглядають як «Corosync помер».
8. Помилки в UI Proxmox часто відображають стан pmxcfs. Веб-інтерфейс може й далі завантажуватися, але операції завершуються помилкою, бо він не може записати конфіг у /etc/pve.

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

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

Завдання 1: Підтвердіть відмову сервісу і збережіть реальну причину

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: failed (Result: exit-code) since Tue 2025-12-25 09:41:02 UTC; 2min 3s ago
    Process: 1832 ExecStart=/usr/bin/pmxcfs (code=exited, status=255/EXCEPTION)
     Memory: 1.6M
     CPU: 43ms

Dec 25 09:41:02 server pmxcfs[1832]: [main] notice: starting pmxcfs
Dec 25 09:41:02 server pmxcfs[1832]: [main] crit: unable to initialize cluster communication
Dec 25 09:41:02 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 25 09:41:02 server systemd[1]: pve-cluster.service: Failed with result 'exit-code'.

Значення: pmxcfs запустився, але не зміг ініціалізувати зв’язок кластера — дуже часто це Corosync/кворум. Це не типовий краш.

Рішення: Негайно перевірте статус Corosync і кворум перед тим, як торкатися прапорців pmxcfs або перезапускати все підряд.

Завдання 2: Прочитайте журнал pve-cluster для точного ланцюжка відмов

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager -n 80
Dec 25 09:40:59 server systemd[1]: Starting The Proxmox VE cluster filesystem...
Dec 25 09:41:02 server pmxcfs[1832]: [main] notice: starting pmxcfs
Dec 25 09:41:02 server pmxcfs[1832]: [dcdb] notice: data verification successful
Dec 25 09:41:02 server pmxcfs[1832]: [main] crit: unable to initialize cluster communication
Dec 25 09:41:02 server pmxcfs[1832]: [main] notice: exit now
Dec 25 09:41:02 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=255/EXCEPTION

Значення: Локальна база даних (dcdb) виглядає нормально. Відмова стосується мережі/членства, а не локальної корупції.

Рішення: Зосередьтеся на Corosync і кворумі, а не на перевстановленні пакетів чи «ремонті» файлів поки що.

Завдання 3: Перевірте, чи змонтовано /etc/pve (pmxcfs)

cr0x@server:~$ findmnt /etc/pve

Значення: Відсутність виводу зазвичай означає, що він не змонтований. Якщо змонтований — ви побачите FUSE-монтування (pmxcfs).

Рішення: Якщо не змонтовано і pve-cluster не працює, ви в зоні «файлова система кластера впала». Не редагуйте /etc/pve, очікуючи, що зміни збережуться в кластері.

Завдання 4: Перевірте стан Corosync і кворум за допомогою інструментів Proxmox

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

Quorum information
------------------
Date:             Tue Dec 25 09:43:18 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.152
Quorate:          No

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

Значення: Не кворум. При видимості лише 1 з 3 голосів сервіси кластера поводитимуться обережно.

Рішення: Потрібно відновити зв’язок щонайменше з одним додатковим вузлом (або qdevice), перш ніж чекати нормальної роботи pmxcfs.

Завдання 5: Перевірте погляд Corosync власними інструментами

cr0x@server:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Tue Dec 25 09:43:46 2025
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          1
Ring ID:          152.209
Quorate:          No

Votequorum information
----------------------
Expected votes:   3
Total votes:      1
Quorum:           2
Flags:            None

Значення: Підтверджує, що це не просто інструмент Proxmox — Corosync дійсно не бачить членів.

Рішення: Припиніть думати «pve-cluster зламався». Почніть думати «кластер зламався».

Завдання 6: Перевірте сервіс Corosync і останні журнали

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:41:10 UTC; 2min 50s ago
       Docs: man:corosync
   Main PID: 1904 (corosync)
      Tasks: 9
     Memory: 29.8M
     CPU: 2.214s

cr0x@server:~$ journalctl -u corosync -b --no-pager -n 80
Dec 25 09:41:10 server corosync[1904]:   [KNET  ] link: host: 2 link: 0 is down
Dec 25 09:41:10 server corosync[1904]:   [KNET  ] link: host: 3 link: 0 is down
Dec 25 09:41:10 server corosync[1904]:   [QUORUM] This node is within the non-primary component and will NOT provide service.

Значення: Corosync працює, але knet-лінк не може досягти пірів. Зазвичай це мережа, MTU, VLAN, файрвол або неправильна IP у corosync.conf.

Рішення: Перевірте шлях мережі кільцем від початку до кінця перед редагуванням конфігів.

Завдання 7: Переконайтеся, що corosync.conf присутній і послідовний на цьому вузлі

cr0x@server:~$ sed -n '1,200p' /etc/pve/corosync.conf
sed: can't read /etc/pve/corosync.conf: No such file or directory

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

Рішення: Прочитайте локальну резервну копію у /etc/corosync/corosync.conf (не ідеально, але показує, у що вірить цей вузол).

cr0x@server:~$ sed -n '1,220p' /etc/corosync/corosync.conf
totem {
  version: 2
  cluster_name: prod-clu
  transport: knet
  interface {
    linknumber: 0
    bindnetaddr: 10.10.50.0
    mcastport: 5405
  }
}
nodelist {
  node {
    name: pve1
    nodeid: 1
    ring0_addr: 10.10.50.11
  }
  node {
    name: pve2
    nodeid: 2
    ring0_addr: 10.10.50.12
  }
  node {
    name: pve3
    nodeid: 3
    ring0_addr: 10.10.50.13
  }
}
quorum {
  provider: corosync_votequorum
}

Значення: Цей вузол очікує пірів у підмережі 10.10.50.0/24. Якщо ваша мережа «оптимізована» командою мережі, тут ви це помітите.

Рішення: Підтвердіть, що 10.10.50.x досяжний на L2/L3 як задумано і що інтерфейс вузла дійсно в цій підмережі.

Завдання 8: Підтвердіть IP вузла і маршрутизацію відповідно до мережі Corosync

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.50.11/24
eno2             DOWN
vmbr0            UP             192.168.10.11/24

cr0x@server:~$ ip route
default via 192.168.10.1 dev vmbr0
10.10.50.0/24 dev eno1 proto kernel scope link src 10.10.50.11
192.168.10.0/24 dev vmbr0 proto kernel scope link src 192.168.10.11

Значення: Мережа кільця Corosync підключена напряму на eno1. Це добре. Якби ні — ви б побачили дивну маршрутизацію.

Рішення: Тестуйте доступність і MTU до пірів на мережі кільця наступним кроком.

Завдання 9: Перевірте досяжність пірів і MTU (Corosync ненавидить мовчазні втрати)

cr0x@server:~$ ping -c 2 10.10.50.12
PING 10.10.50.12 (10.10.50.12) 56(84) bytes of data.

--- 10.10.50.12 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1016ms

cr0x@server:~$ ping -M do -s 1472 -c 2 10.10.50.12
PING 10.10.50.12 (10.10.50.12) 1472(1500) bytes of data.

--- 10.10.50.12 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1013ms

Значення: Повна втрата пакетів вказує на проблему лінку/VLAN/файрволу/порту, а не лише MTU. Якщо працював малий ping, але не пройшов MTU-пінг — підозрюйте невідповідність MTU або шляхи з блокованою фрагментацією.

Рішення: Якщо ping не проходить — зупиніться. Виправте шлях мережі (порт комутатора, відмітки VLAN, правила файрволу, маршрути). Перезапуск сервісів не змінить фізику.

Завдання 10: Перевірте, чи файрвол блокує Corosync на хості

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

cr0x@server:~$ iptables -S | head
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Значення: Файрвол Proxmox може бути увімкнений і все одно не блокувати Corosync залежно від набору правил. Наведений фрагмент iptables показує ACCEPT за замовчуванням, що вказує на те, що файрвол хоста, ймовірно, не проблема.

Рішення: Якщо ви бачите DROP за замовчуванням або явні відмови для UDP 5405/5404 тощо — виправте правила. Якщо ні — зосередьтеся на мережі нагору по ланцюгу.

Завдання 11: Перевірте дисковий простір і вичерпання inode (так, серйозно)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        48G   47G  180M 100% /

cr0x@server:~$ df -i /
Filesystem     Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2     3145728 3120000   25728   100% /

Значення: Повний диск і вичерпані іноді — класичні вбивці кластерів. Сервіси не можуть записувати стан, логи або тимчасові файли. pmxcfs може падати творчими способами.

Рішення: Звільніть місце безпечно (логи, старі ядра, накопичені ISO). Не видаляйте випадкові файли кластера зі злобою.

Завдання 12: Перевірка часу (бо розподілені системи дріб’язкові)

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-25 09:46:10 UTC
           Universal time: Tue 2025-12-25 09:46:10 UTC
                 RTC time: Tue 2025-12-25 09:46:09
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

cr0x@server:~$ chronyc tracking
Reference ID    : 192.0.2.10
Stratum         : 3
Last offset     : +3.421 seconds
RMS offset      : 1.922 seconds
Frequency       : 34.112 ppm fast
Leap status     : Not synchronised

Значення: У вас дрейф у секундах. Цього достатньо, щоб розподілені компоненти поводилися як привид — особливо під час змін членства та валідації TLS.

Рішення: Спочатку виправте синхронізацію часу (доступність NTP, конфіг chrony). Потім повторіть спробу підняти Corosync/pve-cluster.

Завдання 13: Акуратно підніміть Corosync (після виправлення основної проблеми)

cr0x@server:~$ systemctl restart corosync

cr0x@server:~$ pvecm status | sed -n '1,40p'
Cluster information
-------------------
Name:             prod-clu
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Tue Dec 25 09:49:02 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.154
Quorate:          Yes

Значення: Кворум повернувся. Тепер pmxcfs має шанс запуститися коректно.

Рішення: Перезапустіть pve-cluster і перевірте монтування.

Завдання 14: Перезапустіть pve-cluster і перевірте монтування pmxcfs + базові читання

cr0x@server:~$ systemctl restart pve-cluster

cr0x@server:~$ 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 Tue 2025-12-25 09:49:20 UTC; 4s ago
   Main PID: 2488 (pmxcfs)

cr0x@server:~$ findmnt /etc/pve
TARGET   SOURCE  FSTYPE OPTIONS
/etc/pve pmxcfs  fuse   rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other

cr0x@server:~$ ls -la /etc/pve | head
total 0
drwxr-xr-x 2 root www-data 0 Dec 25 09:49 .
drwxr-xr-x 1 root root     0 Dec 25 09:49 ..
-rw-r----- 1 root www-data 0 Dec 25 09:49 .members
-rw-r----- 1 root www-data 0 Dec 25 09:49 corosync.conf
drwxr-xr-x 2 root www-data 0 Dec 25 09:49 nodes

Значення: Змонтовано і конфіг кластера знову видимий. Це індикатор «стек повернувся».

Рішення: Перевірте pvedaemon і pveproxy, якщо UI все ще показує помилки.

Завдання 15: Перевірте бекенд-сервіси UI після відновлення файлової системи кластера

cr0x@server:~$ systemctl status pvedaemon pveproxy --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:49:40 UTC; 9s ago
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:49:42 UTC; 7s ago

Значення: API-стек працює. Якщо GUI все ще падає, ймовірно, це проблема аутентифікації/сертифікатів або кешу браузера чи конкретного вузла, що досі не в кворумі.

Рішення: Перевірте членство кластера та список вузлів на всіх вузлах.

Завдання 16: Підтвердіть членство і пошукайте «привидів» вузлів

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve1
         2          1 pve2
         3          1 pve3

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

Рішення: Якщо є «привиди», заплануйте їхнє коректне видалення з кластера, а не робіть ad-hoc правки під час аварії.

Завдання 17: Якщо pmxcfs змонтовано, але записи не вдаються — протестуйте безпечну операцію запису

cr0x@server:~$ touch /etc/pve/.pmxcfs-write-test
touch: cannot touch '/etc/pve/.pmxcfs-write-test': Read-only file system

Значення: pmxcfs змонтовано в режимі лише для читання. Це часто корелює з втратою кворуму або внутрішнім захисним режимом.

Рішення: Перевірте кворум ще раз (pvecm status). Якщо кворум = «No», припиніть намагатися форсувати записи. Відновіть кворум або свідомо оберіть одновузловий режим з розумінням ризиків (див. чеклісти).

Завдання 18: Підтвердіть сигнали здоров’я локальної бази конфігурації кластера

cr0x@server:~$ systemctl status pve-cluster --no-pager -l
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:49:20 UTC; 1min 22s ago
   Main PID: 2488 (pmxcfs)
     CGroup: /system.slice/pve-cluster.service
             └─2488 /usr/bin/pmxcfs

Значення: Ви в основному перевіряєте, що він тримається і не перезапускається. Якщо він «хитається», він і досі бореться з Corosync, диском або часом.

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

Кореневі причини за симптомами (як думати, а не лише що вводити)

Симптом: pve-cluster падає негайно з «unable to initialize cluster communication»

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

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

Симптом: /etc/pve існує, але порожній або відсутні очікувані файли

Ймовірні причини: pmxcfs не змонтовано; ви дивитеся на підлягаючу директорію (або зламане монтування).

Підхід: Використайте findmnt. Якщо не змонтовано, не «відтворюйте» файли у /etc/pve вручну. Так ви створите майбутню проблему.

Симптом: pmxcfs змонтовано в режимі лише для читання

Ймовірні причини: Відсутність кворуму. Іноді локальний «захисний режим» після нестабільності.

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

Симптом: Corosync «active (running)», але кластер не в кворумі

Ймовірні причини: Мережевий розділ, вузли не відповідають, невідповідність конфігурацій між вузлами або невірні expected votes (поширено після видалення вузла або двовузлового дизайну).

Підхід: Читайте журнали Corosync, перевіряйте досяжність, підтверджуйте версію конфігурації і перевіряйте список вузлів.

Симптом: Все було нормально, поки хтось не змінив VLAN/MTU/teaming

Ймовірні причини: Трафік Corosync відкидається, фрагментується або маршрутизується неправильно. knet стійкий, але не чарівний.

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

Симптом: Стек кластера впав після відключення живлення

Ймовірні причини: Дрейф часу (RTC не вірний), непослідовний порядок старту, вузли завантажилися без готової мережі або часткові дискові проблеми після різкого вимкнення.

Підхід: Підтвердіть синхронізацію часу, переконайтеся, що диски чисті, а потім піднімайте Corosync перед тим, як очікувати, що pmxcfs буде щасливим.

Жарт №2: Кворум — це як зустріч, яка потребує двох людей для прийняття рішення — допоки одна зникає, і ніхто не пам’ятає, як робити свою роботу.

Три корпоративні міні-історії (бо біль навчає)

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

У середній компанії був акуратний три-вузловий Proxmox кластер: обчислювальні вузли в стійці, сховище на окремій платформі, мережа «стандартизована». Одного дня на одній з машин інтерфейс почав видавати помилки кластера, і pve-cluster.service перейшов у стан failed. Молодий інженер зробив те, що багато хто робить під тиском: «Це тільки UI; ВМ працюють, отже кластер має бути в порядку.»

Неправильне припущення було тонким: вони вважали, що стан кластера потрібен лише для глобальних дій. Але їхні резервні копії ВМ, зміни файрволу і визначення сховищ зберігалися в /etc/pve через pmxcfs. Коли pmxcfs впав, резервні завдання почали тихо падати спочатку (конфіги читалися неконсистентно), а потім голосно (API-операції виходили з помилками). У звіті про інцидент пізніше вжили фразу «вторинний збій», що у корпоративній мові означає «ми все погіршили».

Кореневою причиною була зміна мережі на VLAN Corosync. Профіль порту комутатора оновили для «стандартного MTU», що на практиці означало, що мережа Corosync втратила jumbo-кадри, тоді як частина шляху й далі їх слала. Corosync не помер; він просто не міг підтримувати стабільне членство. pmxcfs відмовився брати участь, правильно обравши безпеку замість нісенітниці.

Що виправило проблему — не рестарти. Це була перевірка мережі кільця енд-ту-енд MTU-пінгами і потім вирівнювання MTU послідовно. Після цього Corosync відновив кворум, pmxcfs змонтувався як записуваний, і UI перестав бути загадкою.

Міні-історія 2: Оптимізація, що зіграла злий жарт

Інша організація вирішила, що мережа кластера «занадто гомонлива». Вони мали окремі мережі для сховища, ВМ і управління. Тому вирішили «оптимізувати», перемістивши Corosync на management-міст, бо «він уже має з’єднання скрізь». Зміну зробили в робочий час, бо інженер вважав, що Corosync швидко перепідключиться і pmxcfs буде толерантний. Оптимізм — відновлюваний ресурс.

Управлінська мережа мала правила файрволу, ліміти пропускної здатності й випадкові піки трафіку від моніторингу, патчінгу й управління конфігураціями. Членство Corosync почало «хвилюватися» під навантаженням, що спричинило періодичну втрату кворуму. pmxcfs чергувався між роботою і захисним режимом. UI Proxmox став як ігровий автомат: натискаєш «start VM» — можливо спрацює, можливо видасть помилку.

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

Відновлення полягало в скасуванні оптимізації. Corosync отримав виділену мережу зі стабільною затримкою і послідовним MTU, а команда припинила ставитися до членства кластера як «ще одного UDP-сервісу». Потім вони додали qdevice, бо кластер інколи працював лише з двома вузлами під час технічного обслуговування. Сумні, але правильні рішення. Дуже ефективні.

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

Фінансова команда мала Proxmox кластер, який рідко ламався — бо вони практикували неблискуче старанність. Вони документували топологію кільця Corosync, мали простий скрипт «здоров’я кластера», що запускався моніторингом, і контролювали синхронізацію часу як за ключовий елемент безпеки (бо так воно і є).

Одного ранку pve-cluster впав на вузлі після оновлення ядра. Інженер чергування не почав з рестарту сервісів. Він почав зі збору доказів: pvecm status, journalctl, df, timedatectl. Через кілька хвилин він побачив, що годинник вузла «косить» і NTP не синхронізується. Оновлення скинули політику мережі і заблокували NTP egress на тій VLAN.

Оскільки в них був відомий робочий чекліст, вони виправили правило файрволу, підтвердили стабілізацію chronyc tracking, а потім у правильному порядку перезапустили Corosync і pmxcfs. Кластер відновився без будь-яких хаків у конфігурації. ВМ працювали. UI повернувся. Нікому не довелося «форсити» нічого.

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

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

Чекліст A: Безпечне відновлення, коли кворум можна відновити

1. Заморозьте ризикові операції. Не мігруйте ВМ, не змінюйте визначення сховищ, не редагуйте конфіг кластера, поки кластер нестабільний.
2. Зберіть стан. Збережіть виводи systemctl status pve-cluster corosync, pvecm status та останні ~100 рядків журналів для обох сервісів.
3. Виправте базові речі першочергово:
   • Дисковий простір / inode
   • Синхронізація часу
   • Доступність мережі на лінках кільця (включно з MTU)
4. Перезапустіть Corosync після виправлення основної проблеми. Не перезапускайте його «за звичкою».
5. Підтвердіть, що кворум = Yes. Якщо ні — зупиніться і продовжуйте працювати над мережею/членством.
6. Перезапустіть pve-cluster. Перевірте, що findmnt /etc/pve показує pmxcfs.
7. Перевірте поведінку читання/запису. Якщо тільки для читання — у вас досі немає кворуму або стабільності.
8. Потім перевірте API-сервіси. pvedaemon, pveproxy.
9. Лише після цього відновлюйте нормальні операції.

Чекліст B: Контрольований одновузловий режим (в крайньому випадку, тимчасово)

Це місце, де люди роблять собі боляче. Якщо ви запускаєте один вузол як «кластер», поки інші можуть повернутися пізніше, ви ризикуєте split-brain конфігурацією. Якщо ви не розумієте цього речення — не робіть цього.

1. Підтвердіть, що інші вузли дійсно недоступні або ізольовані. Якщо вони можуть повернутися спонтанно, ви граєте в рулетку з конфігураціями.
2. Комунікація. Повідомте команді, що ви переходите в деградований режим і що зміни конфігів можуть потребувати синхронізації пізніше.
3. Віддавайте перевагу діям лише для читання. Тримайте робочі навантаження запущеними. Уникайте змін глобальних конфігурацій.
4. Якщо треба відновити записи, використайте свідому стратегію кворуму (qdevice або тимчасова корекція expected-votes) і задокументуйте зміни.
5. Заплануйте повернення до нормального стану. Складність не в уведенні в деградований режим — складність у виході з нього чисто.

Чекліст C: План виживання для двовузлового кластера

1. Краще: додайте qdevice/свідка в третій домен відмов (не на тому ж хості, по можливості не на тому ж комутаторі).
2. Під час інциденту: якщо один вузол недоступний, очікуйте втрату кворуму, якщо ви це не спланували.
3. Не робіть постійних «хаків» expected votes. Тимчасові зміни стають постійними на практиці, і тоді ви дізнаєтесь, як на смак split-brain.
4. Після відновлення: інвестуйте в третій голос. Це дешевше, ніж наступний інцидент.

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

1) «pve-cluster failed, тому я редагував /etc/pve вручну»

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

Причина: pmxcfs не був змонтований; ви редагували підлягаючу директорію або локальний заглушковий вигляд.

Виправлення: Перед будь-якими правками перевірте findmnt /etc/pve. Вносьте зміни лише коли pmxcfs змонтований і кластер у кворумі.

2) Corosync працює, але кворум = «No», тому я перезапустив pve-cluster 20 раз

Симптом: pmxcfs «хитається»; помилки UI не зникають.

Причина: Проблема членства (мережевий розділ, відсутні пірі, невідповідність expected votes).

Виправлення: Відновіть мережеву доступність і послідовну конфігурацію Corosync; перезапустіть Corosync один раз після виправлення причин; потім перезапустіть pve-cluster.

3) «У нас три вузли, отже кворум завжди є»

Симптом: Один вузол недоступний — і раптом кластер не в кворумі.

Причина: Два вузли насправді не спілкуються (мовчазний розділ), лишаючи видимим лише один голос.

Виправлення: Перевірте доступність між усіма вузлами на мережі кільця. Кластер — це граф, а не просто підрахунок голів.

4) Невідповідність MTU спричиняє періодичну втрату кворуму

Симптом: Членство Corosync «хитається», особливо під навантаженням або після змін мережі.

Причина: Змішаний MTU по шляху, блокування фрагментації або невідповідність конфігурацій портів.

Виправлення: Стандартизуйте MTU енд-ту-енд. Використовуйте ping -M do -s тести між вузлами на інтерфейсах кільця.

5) Повний диск викликає «помилки зв’язку кластера»

Симптом: Сервіси падають або відмовляються стартувати; журнали можуть бути обрізані; дивна поведінка після оновлень.

Причина: Вичерпано місце або inode на кореневому файловому просторі.

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

6) Дрейф часу робить усе схожим на мережеву проблему

Симптом: TLS-помилки, дивний стан кластера, непослідовні журнали, нестабільність членства.

Причина: NTP не синхронізовано; RTC неправильно; NTP заблоковано.

Виправлення: Відновіть синхронізацію часу, підтвердіть стабільне відстеження, потім переоцініть членство Corosync.

7) Видалення вузла «шляхом його видалення»

Симптом: З’являються привиди вузлів; expected votes неправильні; математика кворуму дивує.

Причина: Вузол виведено з експлуатації без правильних кроків видалення з кластера.

Виправлення: Використовуйте коректну процедуру видалення вузла, коли кластер здоровий; не імпровізуйте під час аварії.

Питання й відповіді (FAQ)

1) Що саме таке pve-cluster.service?

Це сервіс, який запускає pmxcfs — файлову систему Proxmox для кластера, змонтовану в /etc/pve. Якщо він впав, доступ до конфігурації кластера ламається так, що UI й API виглядають ненадійними.

2) Чи вплинуть на роботу моїх запущених ВМ збої pve-cluster?

Зазвичай ВМ залишаються запущеними. Більшість проблем стосуються керування: запуск/зупинка через UI, міграції, резервні копії, дії HA і записи конфігів можуть падати або ставати небезпечними.

3) Чому /etc/pve виглядає порожнім?

Тому що pmxcfs не змонтовано. Ви бачите підлеглу директорію, а не FUSE-монтування. Підтвердіть за допомогою findmnt /etc/pve.

4) Corosync працює. Чому кластер не працює?

Corosync може бути «запущеним», але не мати кворуму. Без кворуму pmxcfs може відмовлятись від записів або не запускатися. Перевірте pvecm status і журнали Corosync.

5) Можна просто перезапустити pve-cluster і corosync, поки не запрацює?

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

6) Який найшвидший спосіб визначити, мережа чи локальний вузол?

Якщо df -h і timedatectl виглядають нормальними, то pvecm status + journalctl -u corosync зазвичай відразу вкажуть на мережу/членство.

7) У мене двовузловий кластер. Чи нормально втрачати кворум при відмові одного вузла?

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

8) pmxcfs змонтовано лише для читання. Як примусово зробити його записуваним?

Зазвичай режим тільки для читання вказує на втрату кворуму або нестабільність. «Виправлення» — відновити кворум. Форсування записів без кворуму ризикує split-brain конфігурацією кластера.

9) Proxmox GUI каже «cluster not ready», але сервіси запущені. Що робити?

Перевірте монтування /etc/pve, кворум і чи здорові API-сервіси. Багато помилок GUI — це просто проблеми pmxcfs/кворуму, що відображаються через API.

10) Після відновлення один вузол все ще показує старий конфіг. Чи це можливо?

Так — особливо після розділів або якщо хтось робив локальні правки, поки pmxcfs був недоступний. Підтвердіть членство, версію конфігурації і уникайте ручної звірки, якщо ви не впевнені, який стан є авторитетним.

Наступні кроки, щоб уникнути повторних інцидентів

Повернення pve-cluster — це лише половина роботи. Інша половина — зробити його нудно стабільним.

• Забезпечте Corosync стабільним мережевим шляхом. Виділений VLAN за можливості, послідовний MTU енд-ту-енд, жодних «допоміжних» сюрпризів з файрволом.
• Вирішіть питання часу як критичні для продакшну. Моніторьте NTP-стан; сповіщайте про дрейф.
• Моніторьте кворум і монтування pmxcfs. Сповіщайте при Quorate: No або коли findmnt /etc/pve не показує pmxcfs.
• Припиніть створювати двовузлові кластери без свідка. Якщо бюджет дозволяє два вузли, придбайте маленький третій голос.
• Запишіть порядок відновлення. Corosync/кворум першим, потім pve-cluster, потім API-сервіси. Не імпровізуйте під час аварії.

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