Proxmox «cluster filesystem not ready»: чому це відбувається і як усунути

Що насправді означає «cluster filesystem not ready»

У Proxmox VE «файлова система кластера» — це не ваш CephFS, NFS, ZFS або щось, змонтоване під /mnt. Це — pmxcfs, користувацька файлова система (FUSE), що живе в /etc/pve. Там Proxmox зберігає та розповсюджує конфігурацію кластера: визначення вузлів, конфігурації ВМ, налаштування сховищ, конфіг corosync, правила фаєрволу та купу метаданих стану.

Коли Proxmox каже, що файлова система кластера не готова, він повідомляє вам:

• /etc/pve змонтовано некоректно (pmxcfs не працює або завис), або
• pmxcfs запущено, але відмовляється надавати записувану конфігурацію, бо кластер не в узгодженому стані (часто проблема з кворумом або corosync), або
• pmxcfs не може працювати через локальні проблеми вузла (диск заповнений, нестача RAM, стрибок часу, зависання FUSE).

UI і більшість CLI-дей використовують /etc/pve. Якщо цей монтування відсутнє або тільки для читання, Proxmox не може безпечно змінювати стан кластера. Ось чому ви бачите, здавалося б, несумісні помилки: «unable to parse storage config», «cannot write file», «failed to lock file» тощо. Вони всі — наслідок одного вузького місця: pmxcfs не надає файлову систему конфігурації.

Як pmxcfs і /etc/pve працюють (і чому воно чутливе)

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

Ключові операційні істини

• /etc/pve — це не звичайний каталог. Це живе монтування. «Виправляти» його шляхом редагування файлів під час відсутності pmxcfs може бути або розумно, або катастрофічно, залежно від того, що ви змінюєте.
• Кворум має значення. У багатовузловому кластері Proxmox вимагає більшості голосів перед тим, як дозволити запис конфігурації. Це не формальність; це запобігає розгалуженню конфігурацій (split-brain).
• Corosync — це транспорт. Якщо corosync не може сформувати стабільне членство, pmxcfs зазвичай не буде «готовим», або працюватиме в режимі тільки для читання.
• Затримка, втрата пакетів і зсув часу — це не «мережеві проблеми», це «проблеми цілісності кластера». Стек кластера трактує їх як загрози консистентності, бо саме такими вони є.

Ось операційна модель, яку хочу, щоб ви тримали в голові:

1. Система завантажується.
2. corosync намагається сформувати членство кластера.
3. pve-cluster (pmxcfs) монтує /etc/pve.
4. pvedaemon/pveproxy (API/UI) читають і пишуть конфіг під /etc/pve.

Якщо ви порушите #2 — #3 похитнеться. Якщо порушите #3 — #4 перетворюється на місце злочину.

Одна перефразована ідея, приписувана Werner Vogels (надійність і розподілені системи): все виходить з ладу, тому проектуйте так, ніби це станеться (перефразовано).

Жарт №1: Кластер Proxmox без кворуму — як нарада без протоколу: всі пам’ятають її по-різному, і ніхто не погоджується, що сталося.

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

Якщо у вас є п’ять хвилин і виклик дзвенить так, що руки тремтять, не блукайте. Виконуйте це у порядку. Кожен крок звужує вузьке місце.

По-перше: чи змонтовано /etc/pve і чи живий pmxcfs?

• Перевірте монтування і статус pve-cluster. Якщо pmxcfs мертвий або монтування відсутнє, ви в категорії «локальний вузол»: збій сервісу, зависання FUSE, повний диск, тиск пам’яті.

По-друге: чи здорове членство corosync і кворум?

• Перевірте pvecm status і corosync-cfgtool. Якщо кворум втрачен, вирішіть, чи можна відновити мережу/пір-вузли, або тимчасово форсувати кворум (рідко правильне довгострокове рішення).

По-третє: чи стабільні час і мережа для консенсусу?

• Перевірте синхронізацію часу (timedatectl) і логи corosync на предмет повторних передач, таймаутів токена, флапів лінку. Виправте зсув часу і втрату пакетів перед перезапуском сервісів; інакше ви просто отримаєте нові логи.

По-четверте: чи хворий сам вузол (диск/RAM/IO)?

• Перевірте використання диску (df), інодів, тиск пам’яті і IO-затримки. pmxcfs легкий, але не чарівний; він може впасти під крайнім навантаженням.

По-п’яте: чи це split brain або ізольований одиночний вузол?

• Якщо кілька вузлів претендують на активність з неконсистентним членством, зупиніться і сплануйте дії. Split brain — це те, де «швидкі виправлення» стають кар’єрними подіями.

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

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

Завдання 1: Підтвердіть, що /etc/pve змонтовано як pmxcfs

cr0x@server:~$ mount | grep -E '(/etc/pve|pmxcfs)'
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

Значення: Якщо ви бачите fuse.pmxcfs, монтування існує. Якщо нічого не повертається, UI-помилка пояснена: pmxcfs не змонтовано.

Рішення: Якщо відсутнє, перейдіть до перевірки сервісів pve-cluster (Завдання 2) і логів (Завдання 3). Якщо є, але все ще «не готово», дивіться кворум і corosync (Завдання 5–8).

Завдання 2: Перевірте стан сервісу pve-cluster (pmxcfs)

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 Fri 2025-12-26 09:41:18 UTC; 3min ago
   Main PID: 1187 (pmxcfs)
      Tasks: 3 (limit: 154214)
     Memory: 38.2M
        CPU: 1.012s
     CGroup: /system.slice/pve-cluster.service
             └─1187 /usr/bin/pmxcfs

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

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

Завдання 3: Прочитайте логи pve-cluster для реальної скарги

cr0x@server:~$ journalctl -u pve-cluster -n 200 --no-pager
Dec 26 09:41:18 server pmxcfs[1187]: [main] notice: starting pmxcfs
Dec 26 09:41:18 server pmxcfs[1187]: [main] notice: resolved node name 'server' to '10.10.0.11'
Dec 26 09:41:19 server pmxcfs[1187]: [dcdb] notice: data verification successful
Dec 26 09:41:20 server pmxcfs[1187]: [status] notice: quorum not present - operations restricted
Dec 26 09:41:20 server pmxcfs[1187]: [status] notice: continuing in local mode

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

Рішення: Якщо кворум відсутній, переходьте до перевірки corosync/kvorumу (Завдання 5–8). Якщо згадується корупція, сплануйте відновлення і бекапи перед будь-якими змінами.

Завдання 4: Перезапустіть pve-cluster (тільки після читання логів)

cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ systemctl is-active pve-cluster
active

Значення: Якщо перезапуск вдається і монтування з’являється, можливо, ви повернулися до роботи. Якщо відразу знову падає — ви не виправили причину; повертайтеся до логів і corosync.

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

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

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

Quorum information
------------------
Date:             Fri Dec 26 09:44:02 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.1
Quorate:          Yes

Значення: Quorate: Yes — це те, чого ви прагнете. Якщо бачите No, pmxcfs ймовірно обмежує записи, і UI сигналізує про проблему.

Рішення: Якщо не кворум, перевірте, які вузли видимі (Завдання 6) і чому лінки впали (Завдання 7–8).

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

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve-a (local)
         2          1 pve-b
         3          1 pve-c

Значення: Відсутні вузли тут пояснюють втрату кворуму. Якщо в 2- або 3-вузловому кластері показує лише один вузол, ви ізольовані.

Рішення: Якщо вузли відсутні, перевірте лінки corosync (Завдання 7) і доступність мережі (Завдання 9).

Завдання 7: Перевірте статус лінків кільця corosync

cr0x@server:~$ corosync-cfgtool -s
Printing link status.
Local node ID 1
LINK ID 0
        addr    = 10.10.0.11
        status  = connected
LINK ID 1
        addr    = 172.16.0.11
        status  = disconnected

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

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

Завдання 8: Пошукайте таймаути токена corosync і повторні передачі

cr0x@server:~$ journalctl -u corosync -n 200 --no-pager
Dec 26 09:42:10 pve-a corosync[1050]: [TOTEM ] Token has not been received in 15000 ms
Dec 26 09:42:10 pve-a corosync[1050]: [TOTEM ] Retransmit List: 12
Dec 26 09:42:11 pve-a corosync[1050]: [KNET  ] link: host: 2 link: 0 is down
Dec 26 09:42:12 pve-a corosync[1050]: [QUORUM] Members[1]: 1

Значення: Таймер токена не отримано + лінк вниз означає, що corosync не може підтримувати членство. Зазвичай це втрата мережі, невідповідний MTU або комутатор, що «допомагає» з мультикастом/унікастом.

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

Завдання 9: Перевірте L2/L3 досяжність між вузлами (і вловіть проблеми MTU)

cr0x@server:~$ ping -c 3 10.10.0.12
PING 10.10.0.12 (10.10.0.12) 56(84) bytes of data.
64 bytes from 10.10.0.12: icmp_seq=1 ttl=64 time=0.435 ms
64 bytes from 10.10.0.12: icmp_seq=2 ttl=64 time=0.401 ms
64 bytes from 10.10.0.12: icmp_seq=3 ttl=64 time=0.398 ms

--- 10.10.0.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2022ms
rtt min/avg/max/mdev = 0.398/0.411/0.435/0.016 ms

Значення: Базова досяжність необхідна, але не достатня. Corosync може падати через джиттер/втрату пакетів, що ping не покаже.

Рішення: Якщо ping не проходить — виправте адресацію/VLAN/маршрутизацію. Якщо ping успішний, але corosync нестабільний — тестуйте MTU і втрату пакетів під навантаженням.

Завдання 10: Перевірте синхронізацію часу (corosync ненавидить подорожі у часі)

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

Значення: Бажано бачити System clock synchronized: yes. Значний зсув може сприяти нестабільності членства і заплутаним логам.

Рішення: Якщо не синхронізовано — налагодьте NTP/chrony/systemd-timesyncd. Потім перезапустіть corosync/pve-cluster за потреби.

Завдання 11: Перевірте простір на диску і виснаження інодів (тихі вбивці)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/pve/root    96G   92G  0.0G 100% /

Значення: Повна коренева ФС викликає дивні збої сервісів, в тому числі pmxcfs та логування. Навіть якщо pmxcfs в основному в пам’яті, система навколо нього потребує місця.

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

cr0x@server:~$ df -ih /
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/pve/root    6.1M  6.1M     0  100% /

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

Рішення: Знайдіть і видаліть директорії з мільйонами файлів (типові винуватці: runaway логи, неправильно налаштовані бекапи, overlay контейнерів).

Завдання 12: Перевірте тиск пам’яті та OOM-убивства

cr0x@server:~$ journalctl -k -n 100 --no-pager | grep -E 'Out of memory|Killed process' || true
Dec 26 09:35:07 pve-a kernel: Out of memory: Killed process 28814 (pveproxy) total-vm:620004kB, anon-rss:112344kB

Значення: Якщо ядро вбиває pveproxy/pvedaemon/corosync, ваш «cluster filesystem not ready» — побічний збиток від виснаження ресурсів.

Рішення: Усуньте тиск: зупиніть процеси, що пожирають пам’ять, додайте swap (обережно), зменшіть overcommit і дослідіть навантаження, що спричинило OOM.

Завдання 13: Підтвердьте, що /etc/pve записуваний (і не брешеться)

cr0x@server:~$ touch /etc/pve/.pmxcfs-write-test && echo "ok"
ok
cr0x@server:~$ rm -f /etc/pve/.pmxcfs-write-test

Значення: Якщо touch завершується помилкою «Read-only file system» або «Input/output error», pmxcfs змонтовано, але не годиться для записів.

Рішення: Режим тільки для читання часто означає відсутність кворуму. IO-помилки натякають на завислий FUSE-монт або внутрішню помилку pmxcfs — повертайтеся до логів і розгляньте перезапуск pve-cluster після усунення базових проблем.

Завдання 14: Перевірте узгодженість corosync-конфігурації (ще не редагуйте)

cr0x@server:~$ sed -n '1,120p' /etc/pve/corosync.conf
totem {
  version: 2
  cluster_name: prod-cluster
  transport: knet
  interface {
    linknumber: 0
    bindnetaddr: 10.10.0.0
  }
}

nodelist {
  node {
    name: pve-a
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.10.0.11
  }
  node {
    name: pve-b
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.10.0.12
  }
  node {
    name: pve-c
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 10.10.0.13
  }
}

Значення: Ви перевіряєте очевидні помилки: неправильні IP, bindnetaddr, відсутній вузол, дубль nodeid. Також підтвердіть, що файл можна прочитати; якщо ні — pmxcfs його не надає.

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

Завдання 15: Подивіться, чи pveproxy/pvedaemon падають через відсутність /etc/pve

cr0x@server:~$ systemctl status pveproxy pvedaemon --no-pager
● pveproxy.service - PVE API Proxy Server
     Active: active (running) since Fri 2025-12-26 09:41:22 UTC; 6min ago
● pvedaemon.service - PVE API Daemon
     Active: active (running) since Fri 2025-12-26 09:41:21 UTC; 6min ago

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

Рішення: Якщо UI не працює, але сервіси запущені, перевірте їхні логи на помилки читання/запису /etc/pve, і зосередьтеся назад на pmxcfs/corosync.

Кореневі причини за підсистемами

1) Втрата кворуму (найпоширеніша, і зазвичай правильна поведінка)

Кворум — це не кара; це ремінь безпеки. Без кворуму кластер не може бути впевнений, що зміна конфігурації, яку ви збираєтеся зробити, не конфліктуватиме з тим, що паралельно робить інший вузол. pmxcfs реагує обмеженням операцій. UI тлумачить це як «cluster filesystem not ready», бо з його точки зору він не може виконувати завдання.

Типові тригери:

• Один вузол впав у двовузловому кластері (немає більшості).
• Мережева сегментація (вузли не бачать один одного; обидві сторони можуть думати, що інша мертва).
• Інтерфейс corosync впав, зміна VLAN, проблема комутатора, невідповідний MTU.
• Зсув часу плюс нестабільна мережа викликають хвилювання членства.

Шаблон виправлення: відновіть членство (поверніть вузли, виправте мережу), або додайте quorum device для малих кластерів, або перерахуйте архітектуру, щоб уникнути двовузлових кластерів без тетрабрюка.

2) Нестабільність транспорту corosync (knet, флапи лінків і «він же пінгується»)

Corosync потребує не лише з’єднання; йому потрібна передбачувана доставка. Втрата пакетів, мікросплески, bufferbloat або «розумний» фаєрвол на шляху можуть спричиняти таймаути токена. Коли це відбувається, членство постійно змінюється, і pmxcfs стає нервовим або відмовляє у готовності.

Шаблон виправлення: виділіть corosync на окрему, нудну мережу. Без NAT. Без stateful фаєрволу посеред шляху. Узгодьте MTU. Уникайте асиметричної маршрутизації. Якщо потрібна відмовостійкість, використовуйте кілька лінків обдумано і тестуйте перемикання.

3) Зсув часу (потайний інгредієнт)

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

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

4) Виснаження ресурсів локального вузла (диск повний, іноди, OOM, IO-затримки)

pmxcfs невеликий, але живе в реальній ОС. Якщо коренева ФС заповнена, journald не може писати, сервіси не стартують, і FUSE-mount може поводитися дивно. Якщо пам’ять обмежена, ядро вбиває процеси у невідповідний момент. Якщо сховище підвисає, процеси блокуються, включаючи corosync.

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

5) Завислий FUSE-монт або стан pmxcfs

Іноді pmxcfs «запущено», але монтування /etc/pve заклинено. Ви бачите IO-помилки, довгі зависання на ls /etc/pve або процеси у стані D. Це може спричинити ядро/FUSE-проблема, екстремальне навантаження або внутрішній дедлок pmxcfs.

Шаблон виправлення: стабілізуйте вузол спочатку (CPU/IO/пам’ять), потім перезапустіть pve-cluster. Якщо монтування не відмонтується, можливо, знадобиться перезавантаження вузла (так, справді).

6) Розходження конфігурацій і split brain

Split brain — це коли частини кластера не погоджуються про членство і діють незалежно. У термінах Proxmox це коли вузли записують суперечливі версії «правди» під /etc/pve. Платформа робить багато, щоб запобігти цьому; адміністратори все одно можуть обійти ці захисти, форсуючи кворум, копіюючи конфіги або вводячи вузли у неправильному порядку.

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

Жарт №2: «Просто форсуйте кворум» — це версія розподілених систем вислову «тримаю пиво».

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

Інцидент №1: хибне припущення (пастка двох вузлів)

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

Коли мережа повернулася, команда побачила «cluster filesystem not ready» на ізольованому вузлі. Жодних міграцій. Жодних редагувань сховища. Деякі ВМ ще працювали локально, але будь-які операції, що стосуються конфігурації кластера, були заблоковані. На виклику думали, що файлова система кластера — це «монтування сховища» і почали перевіряти NFS. NFS був у порядку, але проблема була не в ньому.

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

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

Кінцеве виправлення було нудне: додали quorum device і перестали вважати два вузли повноцінним кластером без додаткового арбітра. Також вони відвели corosync на окремий VLAN. Великий виграш не в доступності, а в тому, що кластер перестав сперечатися про реальність.

Інцидент №2: оптимізація, що обернулася проти (jumbo frames і зникнення токена)

Інша організація хотіла зменшити навантаження CPU і підвищити пропускну здатність на «кластерній» мережі, тому увімкнула jumbo frames повністю. Проблема була в тому, що не всюди це було реалізовано. Один проміжний порт комутатора залишався з MTU 1500, бо він був у частині старого транку і ніхто не хотів його чіпати під час робочого часу.

Трафік ВМ майже не помітив цього. TCP може домовитися і відновитися. Corosync помітив це відразу, бо йому потрібна своєчасна доставка повідомлень. Воно не падало акуратно. Воно флапало: таймаути токена, повторні передачі, члени відпадають і повертаються. Кожні кілька хвилин хтось бачив «cluster filesystem not ready» в UI, потім воно зникає, потім знову з’являється.

Команда оптимізувала для продуктивності і випадково оптимізувала надійність. Ще гірше — симптом не вказував на MTU. Він вказував на Proxmox. Вони годинами перезапускали сервіси, що в основному генерувало нові лог-рядки і впевненість, що «це випадково».

Виправили просто: зробили MTU консистентним. Не «більшим», а узгодженим. Після цього corosync перестало таймаутитися, кворум стабілізувався, і pmxcfs став знову нудним — а саме це вам і потрібно для розподілу конфігурацій.

Інцидент №3: нудна, але правильна практика, що врятувала день (виділені NIC та дисципліна змін)

Фінансова компанія тримала Proxmox у стійці колокації, де мережеві зміни траплялися часто. Вони вже обпеклися, тому тримали трафік corosync на виділеній парі NIC, підключених до окремої пари комутаторів, і документували точні IP і MTU як контракт.

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

Що спрацювало — це не героїзм. Це те, що вони проектувалися під «нудні» відмови: втрата комутатора. Також у них була операційна заборона: без змін corosync під час активного інциденту. Коли все хитко, люди роблять «креативні» кроки. Заборона це зупинила.

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

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

1) Симптом: банер UI «cluster filesystem not ready», але ВМ все ще працюють

Корінь: pmxcfs обмежує записи через втрату кворуму; робочі навантаження можуть працювати локально, але зміни конфігурації блокуються.

Виправлення: відновіть членство corosync і кворум. Поверніть відсутні вузли, виправте мережу corosync або встановіть quorum device для малих кластерів.

2) Симптом: ls /etc/pve зависає або повертає «Input/output error»

Корінь: FUSE-монт заклинено, pmxcfs завис або вузол зазнає сильного IO-навантаження.

Виправлення: перевірте IO-залежання та логи ядра, потім перезапустіть pve-cluster. Якщо монтування не відновлюється, перезавантажте вузол після забезпечення безпечного стану ВМ (міграція або зупинка для локального сховища).

3) Симптом: «quorum not present – operations restricted» у логах pve-cluster

Корінь: кластер не має більшості членів; часто проблема двовузлової архітектури або збою вузла/мережі.

Виправлення: відновіть зв’язок відсутнього вузла або додайте qdevice. Уникайте форсування expected votes, якщо ви не свідомо працюєте в режимі єдиного вузла і розумієте ризики split brain.

4) Симптом: логи corosync показують таймаути токена, список повторних передач зростає

Корінь: втрата пакетів, невідповідність MTU, неправильні теги VLAN або фаєрвол/ACL, що заважає трафіку corosync.

Виправлення: виділіть corosync на стабільну мережу; перевірте MTU; приберіть stateful пристрої на шляху. Потім перезапустіть corosync і підтвердьте стабільне членство.

5) Симптом: сервіси постійно перезапускаються; логи малі; «випадкова» поведінка

Корінь: коренева ФС заповнена або вичерпані іноди; journald не може писати, сервіси ламаються незрозумілими шляхами.

Виправлення: негайно звільніть простір/іноди. Потім перезапустіть сервіси і перевірте. Не ганяйтеся за привидами, доки ОС не може створювати файли.

6) Симптом: після «виправлення» конфіги кластера відрізняються між вузлами

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

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

7) Симптом: лише один вузол постійно показує «not ready» після перезавантажень

Корінь: невідповідність імені хоста/IP, неправильний ring0_addr, поламана DNS-резолюція або перейменування інтерфейсу NIC змінило інтерфейс для corosync.

Виправлення: підтвердіть розв’язання імен вузла, bindnetaddr corosync і правильний інтерфейс. Виправте OS-мережу спочатку, потім corosync, потім pmxcfs.

Чеклісти / поетапний план

Чекліст A: Безпечно відновити стан «ready» (один уражений вузол)

1. Припиніть робити зміни. Ніяких редагувань сховища, приєднань вузлів або довільних копіювань файлів.
2. Перевірте монтування: mount | grep /etc/pve. Якщо відсутнє, зосередьтеся на pve-cluster.
3. Перевірте сервіс: systemctl status pve-cluster і journalctl -u pve-cluster.
4. Перевірте кворум: pvecm status. Якщо не кворум, не очікуйте записуваної конфігурації.
5. Перевірте corosync: journalctl -u corosync, corosync-cfgtool -s.
6. Перевірте час: timedatectl.
7. Перевірте диск/іноди: df -h /, df -ih /.
8. Лише потім перезапускайте: перезапустіть corosync, якщо транспорт виправлено; перезапустіть pve-cluster після стабілізації corosync.
9. Підтвердіть: pvecm status показує кворум, touch /etc/pve/test працює, банер у UI зникає.

Чекліст B: Двовузловий кластер «not ready» після відключення вузла

1. Припускайте, що втрата кворуму — очікувана поведінка.
2. Поверніть другий вузол (або виправте міжз’єднання), замість форсування записів.
3. Якщо це повторювана операційна проблема: впровадьте quorum device.
4. Документуйте жорстке правило: «нуль форсування кворуму під час інцидентів без дозволу та запису».

Чекліст C: Підозра на split brain

1. Заморозьте записи конфігів. Забороніть людям «виправляти» шляхом редагування файлів кластера.
2. Визначте розділення: які вузли бачать які члени (запустіть pvecm status на кожному).
3. Оберіть джерело істини на основі більшості та останньої узгодженої версії конфігурації.
4. Відновіть мережу і переконайтеся, що кластер сформував одне членство.
5. Лише потім зведіть розбіжні конфіги. Перевірте визначення сховищ і конфіг ВМ перед виконанням дій HA.

Чекліст D: Коли перезавантаження — правильна відповідь

Перезавантаження виправдане коли:

• /etc/pve зависло і ви не можете плавно розблокувати FUSE.
• Вузол у сильному IO-wait або на рівні ядра є дивні процеси в D-state і перезапуски сервісів не допомагають.
• Постійні OOM-умови і потрібно скинути стан до відомого (після зменшення навантаження).

Перезавантаження не виправдане коли:

• Ви не перевірили диск/іноди/час/мережу і просто сподіваєтеся.
• Кластер розділений і перезавантаження просто перемішає карти без відновлення зв’язку.

Цікаві факти та історичний контекст (для тих, хто любить знати чому)

• pmxcfs — це FUSE-файлова система, тому /etc/pve поводиться не як звичайні каталоги і може «зависати», коли користувацький демон хворий.
• Кластерна конфігурація Proxmox розподілена, а не базується на спільному сховищі. Вам не потрібен SAN для реплікації конфігів; потрібен працюючий corosync.
• Historically corosync leaned on multicast — ця фраза збережена як історичний факт; у сучасному Proxmox часто використовується knet transport, який може працювати через унікаст і краще обробляє кілька лінків.
• Логіка кворуму існує, щоб запобігти split brain, режиму відмови, відомому з ранніх HA-кластерів, коли обидві половини вважали себе первинними і писали суперечливі стани.
• Двовузлові кластери за визначенням неоднозначні без арбітра. Це не дивина Proxmox; це математична проблема розподілених систем у системі операцій.
• /etc/pve містить більше, ніж конфіги ВМ: визначення сховищ, правила фаєрволу та параметри на рівні кластера. Коли воно недоступне, радіус ураження виглядає ширшим, ніж «тільки кластеризація».
• Config Version у pvecm status — корисна крихта під час інцидентів: вона показує, чи вузли прогресують разом або сходять нанівець.
• Зсув часу викликає «неможливе» відлагодження, бо логи не вирівнюються і події членства виглядають поза порядком; стек кластера посилює цю плутанину.

FAQ

1) Чи означає «cluster filesystem not ready», що диски моїх ВМ недоступні?

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

2) Чи можу я продовжувати працювати ВМ, коли файлова система кластера не готова?

Часто так. Запущені навантаження не обов’язково зупиняються. Ризик — це операційна сторона: ви можете не змогти мігрувати, змінити конфіг або коректно управляти HA, доки pmxcfs і кворум не стануть здоровими.

3) Чому Proxmox блокує записи при втраті кворуму?

Щоб запобігти split brain у конфігурації. Без кворуму дві частини кластера могли б приймати зміни і пізніше конфліктувати. Блокування записів — безпечний вибір.

4) Чи безпечно форсувати кворум / expected votes до 1?

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

5) У чому різниця між тим, що corosync «запущено», і тим, що кворум «quorate»?

corosync «запущено» означає, що демон працює локально. «Quorate» значить, що утворено дійсне членство з достатньою кількістю голосів для прийняття рішень. pmxcfs орієнтується на друге.

6) Чому це відбувається після мережевої зміни, що «не мала вплинути» на Proxmox?

Бо corosync дуже чутливий до втрати пакетів, невідповідності MTU і флапів лінків. Ваш трафік ВМ може вижити на «шляхетній» мережі; консенсусний трафік менш терпимий.

7) Як дізнатися, чи /etc/pve справді змонтовано, а не просто каталог?

Запустіть mount | grep /etc/pve. Має показувати fuse.pmxcfs. Якщо ні — ви не дивитесь на файлову систему кластера.

8) Чи варто перевстановлювати вузол, якщо pmxcfs зламався?

Майже ніколи не як перший крок. Більшість випадків — проблема кворуму/мережі/часу/тиску на диск. Перевстановлення може знищити докази і ускладнити відновлення. Спочатку діагностуйте.

9) Чи можуть проблеми з Ceph спричинити «cluster filesystem not ready»?

Опосередковано. Якщо проблеми Ceph спричиняють величезний IO-wait або тиск на вузол, вони можуть дестабілізувати corosync і pmxcfs. Але pmxcfs сам по собі не зберігається на Ceph.

10) Чому UI показує помилку навіть коли pve-cluster активний?

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

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

Якщо ви візьмете лише один операційний урок з цієї помилки — візьміть цей: не сприймайте це як проблему зі сховищем; сприймайте це як проблему консенсусу кластера. Перевірте, чи змонтовано /etc/pve, потім перевірте кворум і стан corosync, а вже потім виправляйте час/мережу/ресурсний тиск у цьому порядку.

Наступні кроки, що дають ефект:

• Якщо у вас два вузли — додайте quorum device. Припиніть гратися з нічиями.
• Виділіть corosync у нудну мережу. Стабільний MTU, без «сек’юріті-пристроїв» посеред шляху, надлишкові лінки лише якщо ви можете їх тестувати.
• Моніторьте нудні речі: диск/іноди на root, стан NTP синхронізації, стабільність лінків corosync. Помилка файлової системи кластера — зазвичай посланець, а не лиходій.
• Напишіть інцидентне правило: без форсування кворуму і без ручних редагувань конфігів під час розділення, якщо не призначено відповідальну одиницю і не оцінено радіусу ураження.