Proxmox «вузол не в кластері»: що сталося і як правильно повторно приєднатися

Що насправді означає «вузол не в кластері»

У Proxmox VE повідомлення «вузол не в кластері» зазвичай з’являється, коли вузол вважає, що має бути в кластері, але не бачить (або не може підтвердити) стан кластера. Цей стан передає Corosync і він зберігається/розповсюджується через pmxcfs (файлова система кластера Proxmox), змонтовану в /etc/pve.

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

• Corosync не запущений (або не може прив’язатися до кластерної мережі).
• Немає кворуму, тому pmxcfs стає доступним лише для читання або взагалі не монтується, і конфігурацію кластера не можна довіряти.
• Ідентичність вузла застаріла (неправильний corosync.conf, неправильний node ID, неправильні адреси кільця або невірні відповідності hostname/IP).
• Split brain: вузол сформував або зберіг інший вигляд кластера і тепер несумісний.
• Дрейф часу ламає автентифікацію Corosync або спричиняє несподіване закінчення життєвого циклу токенів.
• Ви змінили мережу (VLAN, MTU, bonding, firewall) і трафік Corosync тепер не проходить.

Ось думка з практики: ставтеся до повідомлення як до запобіжника. Proxmox каже: «Я не можу довести стан кластера; я не буду прикидатися». Ваше завдання — з’ясувати, чому він не може підтвердити стан, і вибрати найменш руйнівний шлях відновлення.

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

Факти й контекст, що пояснюють дивну поведінку

Це не дрібниці. Це ті історичні міни, що пояснюють, чому Proxmox поводиться так, як поводиться.

1. Corosync походить із HA Linux середовища і успадкував підхід «спочатку членство й кворум». Якщо членство невизначене, краще припинити роботу, ніж гадати.
2. Proxmox зберігає більшість конфігурації кластера в pmxcfs, FUSE‑файловій системі, підсиленій ін‑пам’ятью базою, що реплікується через Corosync. Ось чому втрата Corosync часто ламає «прості» операції з конфігурацією.
3. /etc/pve — не те саме, що /etc. Воно монтується динамічно. Якщо воно не змонтоване, сервіси Proxmox, що очікують його, можуть поводитися так, ніби ви видалили контрольну площину.
4. Правила кворуму існують, щоб запобігти split brain, а не щоб вас дратувати. Саме тому двовузловий кластер без третього голосуючого (qdevice) працює незручно.
5. Ідентичність вузла в кластері залежить від node ID і імен, що зберігаються в конфігурації Corosync і внутрішньому стані; невідповідність hostname може виглядати як поява іншої машини.
6. Proxmox історично оптимізований під on‑prem надійність, де «вузол пропав» часто означало проблему кабелю або комутатора, а не автоскейлінг. UI і налаштування це відображають.
7. Раніше multicast був важливим для кластерів. Сучасний Corosync зазвичай використовує unicast, але правило «кластерна мережа має бути простим і передбачуваним» лишилося.
8. Синхронізація часу — залежність кластера, бо автентифікація і таймаути залежать від часу. Проблеми з NTP можуть маскуватися під мережеві збої.
9. HA‑стек Proxmox передбачає важливість fencing. Без надійного членства він уникає дій, які можуть запустити одну й ту саму ВМ двічі.

Одна парафразована ідея для шафи оперування: надія — не стратегія; проектуйте так, щоб відмови були очікуваними і відновлюваними. — (парафразована думка)

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

Це послідовність «припини скролити і знайди вузьке місце». Ви намагаєтеся відповісти на три питання: Чи є кворум? Чи здоровий Corosync? Чи змонтовано і чи консистентне /etc/pve?

1) Спершу: перевірте, чи вузол просто ізольований

• Чи може він досягти інших вузлів за IP‑адресами кільця Corosync?
• Чи інтерфейс кластерної мережі піднятий, правильний VLAN/MTU, немає блокувань фаєрволом?
• Чи час синхронізований?

2) По‑друге: перевірте кворум і членство з робочого вузла

• Якщо кластер має кворум в іншому місці, то проблемний — локальний вузол.
• Якщо кворум втрачено весь кластер — не намагайтесь одразу «приєднати» вузол. Відновіть кворум спочатку.

3) По‑третє: оберіть трек відновлення

• Трек A (найкращий): ідентичність вузла дійсна; виправте мережу/час/Corosync і він автоматично приєднається.
• Трек B (поширений): вузол було видалено або стан розійшовся; потрібно видалити та додати його з pvecm delnode потім pvecm add.
• Трек C (гірший): split brain або конфлікт станів; треба обрати «джерело істини» і акуратно очистити іншу сторону.

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

Як працює кластеризація Proxmox (важливі частини)

Corosync: оракул членства

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

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

pmxcfs: ваша конфігурація — це реплікована файловина

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

Якщо /etc/pve не змонтовано (або змонтовано, але зависло), ви помітите дивні симптоми:

• Файли конфігурацій ВМ «відсутні», хоча ВМ все ще є на диску.
• GUI показує застарілий або пустий стан кластера.
• Зміни конфігурації кластера не вдаються або відкатуються.

Кворум: чому два вузли — пастка без плану

У три вузловому кластері втрата одного вузла зазвичай залишає кворум. У двовузловому кластері втрата будь‑якого вузла втрачає кворум, якщо ви не додали третій голос (qdevice) або не прийняли обмеження. Це не театральність Proxmox; це математика.

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

Split brain: режим відмови, якого треба уникати

Split brain означає, що дві сторони кластера вважають себе авторитетними. Якщо обидві сторони можуть записувати в спільне сховище або запускати ту саму ВМ, ви отримаєте корупцію даних або дублікати. Політика кворуму Proxmox активно запобігає цьому. Ваша задача — не обійти її «тимчасовими» хакерськими рішеннями.

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

Нижче — конкретні кроки, які можна виконати. Кожен включає (1) команду, (2) що означає ймовірний вивід, і (3) яке рішення прийняти далі. Виконуйте їх на проблемному вузлі і принаймні на одному здоровому вузлі коли можливо.

Завдання 1: Підтвердьте, як Proxmox називає свій вузол

cr0x@server:~$ hostnamectl --static
pve03

Значення: Proxmox очікує, що ім’я вузла відповідатиме конфігурації кластера. Якщо кластер знає цей вузол як pve03, а хост тепер називається pve3, ви створили нову ідентичність.

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

Завдання 2: Перевірте резолюцію імен (часто трафік кластера використовує імена)

cr0x@server:~$ getent hosts pve01 pve02 pve03
10.10.10.11   pve01
10.10.10.12   pve02
10.10.10.13   pve03

Значення: Імена мають резолвитися у очікувані IP кільця. Якщо це неправильно (старі IP, інша підмережа), членство Corosync ламається.

Рішення: Вирівняйте DNS або /etc/hosts на всіх вузлах; не латайте лише одиничний вузол.

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

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

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

Рішення: Якщо не змонтовано, зосередьтеся на стані Corosync і сервісі pve-cluster.

Завдання 4: Перевірте сервіси pve-cluster і Corosync

cr0x@server:~$ systemctl status pve-cluster corosync --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running)
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: failed (Result: exit-code)

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

Рішення: Перегляньте логи Corosync і конфіг; не поспішайте з «повторним приєднанням».

Завдання 5: Прочитайте логи Corosync для справжньої помилки

cr0x@server:~$ journalctl -u corosync -b --no-pager | tail -n 25
Dec 25 10:11:12 pve03 corosync[1321]: [TOTEM ] Token has not been received in 2730 ms
Dec 25 10:11:12 pve03 corosync[1321]: [TOTEM ] A processor failed, forming new configuration.
Dec 25 10:11:14 pve03 corosync[1321]: [KNET  ] link: host: 2 link: 0 is down
Dec 25 10:11:15 pve03 corosync[1321]: [MAIN  ] Corosync Cluster Engine exiting with status 1

Значення: Помилка шляху в мережі (knet link down) або сильна втрата пакетів/невідповідність MTU. Corosync не любить ненадійні мережі.

Рішення: Перевірте мережевий інтерфейс, MTU, VLAN‑теги і фаєрвол. Не торкайтеся членства кластера, поки пакети не підуть.

Завдання 6: Підтвердьте зв’язок кільця Corosync (ICMP недостатньо, але початок хороший)

cr0x@server:~$ ping -c 3 10.10.10.11
PING 10.10.10.11 (10.10.10.11) 56(84) bytes of data.
64 bytes from 10.10.10.11: icmp_seq=1 ttl=64 time=0.356 ms
64 bytes from 10.10.10.11: icmp_seq=2 ttl=64 time=0.331 ms
64 bytes from 10.10.10.11: icmp_seq=3 ttl=64 time=0.342 ms

--- 10.10.10.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2034ms

Значення: Базова досяжність є. Якщо ping не проходить, кластер не зможе працювати. Якщо ping проходить, але Corosync падає — дивіться MTU, фаєрвол або асиметрію.

Рішення: Якщо ping в порядку — тестуйте MTU і UDP‑поведінку далі.

Завдання 7: Перевірте узгодженість MTU (тиха катастрофа для knet)

cr0x@server:~$ ip -br link show
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eno1             UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>
vmbr0            UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>
vmbr1            UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>

cr0x@server:~$ ip link show vmbr1 | grep -E 'mtu|state'
2: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Значення: Якщо на цьому вузлі MTU 9000, а на комутаторі або на інших вузлах 1500 — ви отримаєте «інколи працює» поведінку, яку Corosync карає.

Рішення: Зробіть MTU однаковим end‑to‑end. Якщо не можете гарантувати jumbo frames — лишіть 1500.

Завдання 8: Перевірте синхронізацію часу (Corosync не любить дрейф)

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

Значення: Потрібно бачити «synchronized: yes». Якщо «no» — відновіть NTP перш ніж звинувачувати Corosync.

Рішення: Запустіть або виправте chrony/systemd‑timesyncd і повторно перевірте членство.

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

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

Quorum information
------------------
Date:             Thu Dec 25 10:15:10 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.6
Quorate:          Yes

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

Значення: Кластер здоровий в іншому місці. Проблемний вузол — поза членством.

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

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

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 pve01
0x00000002          1 pve02
0x00000003          1 pve03

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

Рішення: Якщо вузол відсутній у цьому списку — скоріше за все знадобиться pvecm add після очищення.

Завдання 11: Перевірте локальний Corosync‑конфіг на проблемному вузлі

cr0x@server:~$ grep -E 'cluster_name|ring0_addr|nodeid|bindnetaddr' -n /etc/pve/corosync.conf
2:  cluster_name: prod-cluster
12:     bindnetaddr: 10.10.10.0
18:         ring0_addr: pve01
23:         nodeid: 1
28:         ring0_addr: pve02
33:         nodeid: 2
38:         ring0_addr: pve03
43:         nodeid: 3

Значення: Node ID і адреси кільця повинні відповідати очікуваному кластеру. Якщо цей файл відсутній або відрізняється — ви не дивитесь на ту саму реальність кластера.

Рішення: Якщо файл відрізняється від конфігурації здорового вузла — має місце дрейф конфігурації або /etc/pve не змонтовано коректно.

Завдання 12: Переконайтеся, що ключ автентифікації Corosync існує і відповідає (лише якщо ви впевнені)

cr0x@server:~$ ls -l /etc/corosync/authkey
-r-------- 1 root root 128 Dec 10 09:02 /etc/corosync/authkey

Значення: Відсутній authkey = неможливо аутентифікувати трафік кластера. Невідповідний ключ = неможливо приєднатися.

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

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

cr0x@server:~$ test -f /etc/pve/.members && echo "members file exists" || echo "members file missing"
members file exists

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

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

Завдання 14: Перевірте, чи /etc/pve доступний лише для читання (симптом втрати кворуму)

cr0x@server:~$ touch /etc/pve/test-write 2>&1 || true
touch: cannot touch '/etc/pve/test-write': Read-only file system

Значення: Ви не маєте кворуму з перспективи цього вузла, або pmxcfs захищає стан.

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

Завдання 15: Переконайтеся, що фаєрвол не блокує трафік Corosync

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

cr0x@server:~$ iptables -S | grep -E 'DROP|REJECT' | head
-A INPUT -j PVEFW-INPUT
-A PVEFW-INPUT -j DROP

Значення: Якщо фаєрвол увімкнений і правила суворі — UDP‑трафік Corosync може відкидатися.

Рішення: Помістіть мережу кластера у довірену зону або явно дозвольте Corosync. Не вимикайте фаєрвол назавжди; виправте правила.

Завдання 16: Переконайтеся, що Ceph (якщо використовується) не є справжньою причиною інциденту

cr0x@server:~$ ceph -s
cluster:
  id:     7d2c1c2a-9b9c-4e5b-9a65-1f9b6c1a1b11
  health: HEALTH_WARN
          1 osds down

services:
  mon: 3 daemons, quorum a,b,c
  mgr: x(active), standbys: y
  osd: 12 osds: 11 up, 12 in

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

Рішення: Відновіть членство кластера, якщо вам потрібне централізоване керування; у паралельному процесі відновлюйте OSD, якщо це впливає на IO.

Ще один короткий жарт: якщо ваша перша думка — «перевстановити вузол», — вітаю — ви винайшли IT‑версію «перевезти його вмиканням екскаватором».

Чеклісти / покроковий план: як правильно повторно приєднати вузол

Не існує єдиного «процедура приєднання». Є три варіанти, і лише один безпечний для вашого випадку. Обирайте на основі перевірених фактів вище.

План 0: Зупиніться і захистіть робочі навантаження (завжди починайте з цього)

• Визначте, чи на проблемному вузлі ще працюють ВМ/CT і чи вони використовують спільне сховище (Ceph, NFS, iSCSI, спільний ZFS).
• Якщо HA увімкнено, розгляньте тимчасове вимкнення дій HA для уражених сервісів, доки членство не стабілізується, щоб уникнути дублювань запусків.
• Якщо вузол ізольований, але все ще виконує робочі навантаження — вважайте його «деградованим автономним». Не дозволяйте іншому вузлу запускати ті ж навантаження.

План A: Вузол все ще в списку членства, просто відключився (найкращий варіант)

Використовуйте коли: кворум в іншому місці здоровий; pvecm nodes перераховує вузол; і ідентичність вузла (hostname, відповідності IP, authkey) не змінилася.

1. Виправте мережу: VLAN/MTU/bonding, порти комутатора, правила фаєрволу.
2. Відновіть синхронізацію часу.
3. Перезапустіть Corosync і pve-cluster на проблемному вузлі (якщо Corosync був вниз — починайте з нього).

cr0x@server:~$ systemctl restart corosync
cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Quorate:          Yes

Значення: Якщо він стає quorate і членство повертається — ви завершили. Тепер перевірте стан сховищ і HA.

Рішення: Якщо Corosync не стартує або не може приєднатися — зупиніться і переходьте до Плану B або C в залежності від виявлених проблем.

План B: Вузол треба чисто додати заново (поширений випадок після перевстановлення чи дрейфу ідентичності)

Використовуйте коли: кластер в іншому місці здоровий, але локальний стан вузла застарілий, відсутній або не відповідає (перевстановлений ОС, новий authkey, перейменований хост, змінені IP).

Крок 1: На здоровому вузлі видаліть запис про померлий вузол (якщо він є)

cr0x@server:~$ pvecm delnode pve03
Removed node pve03 from cluster

Значення: Це видаляє метадані членства для того вузла. Це не зітре диски, але змінить стан кластера.

Рішення: Якщо видалення не вдається через відсутність кворуму — не форсуйте; відновіть кворум спочатку.

Крок 2: Очистіть конфігурацію кластера на вузлі, який приєднуються (робіть акуратно)

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

cr0x@server:~$ systemctl stop pve-cluster corosync
cr0x@server:~$ rm -f /etc/corosync/corosync.conf
cr0x@server:~$ rm -f /etc/corosync/authkey
cr0x@server:~$ rm -rf /etc/pve/corosync.conf /etc/pve/nodes /etc/pve/.members
cr0x@server:~$ systemctl start pve-cluster

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

Рішення: Якщо на вузлі є унікальні, нерепліковані конфіги ВМ — зупиніться і зробіть бекап /etc/pve перед видаленням.

Крок 3: Додайте вузол у кластер з того вузла, що приєднується

cr0x@server:~$ pvecm add 10.10.10.11
Please enter superuser (root) password for '10.10.10.11':
Establishing API connection with host '10.10.10.11'
The authenticity of host '10.10.10.11' can't be established.
Fingerprint: SHA256:0mJ0QwqN7ZpVtJcXxq0b3oYzYl6s9Qx9fYqVQ4oSx2s
Are you sure you want to continue connecting (yes/no)? yes
Successfully added node 'pve03' to cluster.

Значення: Proxmox скопіював правильні файли конфігурації Corosync/автентифікації і зареєстрував вузол.

Рішення: Негайно перевірте членство і кворум з обох сторін.

Крок 4: Перевірте стан після приєднання

cr0x@server:~$ pvecm status | grep -E 'Name:|Quorate:|Nodes:'
Name:             prod-cluster
Nodes:            3
Quorate:          Yes

Значення: Контрольна площина відновлена. Тепер перевірте монтування сховищ, конфіги ВМ і задачі реплікації.

План C: Split brain або конфліктні стани кластера (відповідальна хірургія)

Використовуйте коли: підозрюєте дві незалежні копії стану кластера: наприклад, хтось виконав pvecm create на ізольованому вузлі або відновив /etc/pve з бекапу на одній зі сторін без координації.

Як це виглядає на практиці:

• Те саме ім’я кластера, але різні node ID.
• Вузли з’являються двічі або з дивними ID.
• Логи Corosync згадують несумісні версії конфігів або постійні помилки автентифікації, навіть за правильної мережі.
• /etc/pve/corosync.conf відрізняється між вузлами, хоча цього не повинно бути.

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

У сценаріях split brain потрібно також врахувати спільне сховище:

• Якщо обидві сторони можуть писати в той самий датастор — зупиніться. Переконайтеся, що тільки одна сторона активна на спільному сховищі.
• Якщо використовується Ceph — підтвердіть кворум MON і переконайтеся, що ізольований вузол не формує другий Ceph‑кластер.
• Якщо використовується реплікація ZFS — перевірте GUID наборів даних і напрям реплікації перед повторним увімкненням задач.

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

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

1) Симптом: «вузол не в кластері» після перезавантаження; інші вузли в порядку

Корінь: Corosync не прив’язався до правильного інтерфейсу після зміни мережі (зміна імені мосту, перенумерація bond, VLAN не піднятий вчасно).

Виправлення: Перевірте адреси кільця і готовність інтерфейсу; виправте /etc/network/interfaces або systemd‑networkd; перезапустіть Corosync; підтвердіть логи членства.

2) Симптом: /etc/pve змонтовано лише для читання

Корінь: Немає кворуму (часто дводузловий кластер з одним вузлом вимкнений) або вузол не бачить достатньо пірів.

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

3) Симптом: Лог Corosync показує «token has not been received» і knet link флапає

Корінь: Втрата пакетів у мережі, невідповідність MTU або фільтрація UDP фаєрволом між пірівами.

Виправлення: Уніфікуйте MTU, виправте комутатор/VLAN, дозвольте Corosync‑трафік, уникайте маршрутизації трафіку кластера через «розумні» фаєрволи.

4) Симптом: Вузол був перевстановлений і тепер не може приєднатися; помилки автентифікації

Корінь: Нова інсталяція має інший Corosync authkey і, можливо, інший hostname/SSH host key. Це інший вузол, навіть якщо апарат той самий.

Виправлення: Видаліть старий запис вузла з кластера, очистіть локальний стан і додайте заново за допомогою pvecm add.

5) Симптом: Кластер показує дублікати вузлів або дивні ID

Корінь: Split brain або ручне копіювання файлів у /etc/pve; конфліктні бази членства.

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

6) Симптом: У GUI кластер є, а в CLI кажуть, що немає кворуму (або навпаки)

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

Виправлення: Довіряйте CLI (pvecm status, journalctl). Перезапустіть сервіси у контрольованому порядку; підтвердьте монтування і режим читання/запису /etc/pve.

7) Симптом: Все працювало, поки хтось «оптимізував» мережу кластера

Корінь: Jumbo frames увімкнені лише на частині портів; змінилася хеш‑функція LACP; змінено налаштування offload; або кластерна мережа переміщена за фаєрвол‑пристрій.

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

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

Коротка історія 1: Інцидент через хибні припущення

У регіональному офісі був три‑вузловий Proxmox‑кластер з Windows ВМ та кількома Linux‑пристроями. Один день один вузол зник. Фасіліті сказали, що це був «просто power cycle». Молодший адміністратор вирішив, що вузол сам приєднається після завантаження.

Він завантажився, але Proxmox показав «вузол не в кластері». Адмін зробив те, що часто роблять під тиском: скопіював /etc/pve/corosync.conf з робочого вузла на проблемний і перезапустив сервіси. Здавалося, стало краще хвилин на п’ять. Потім Corosync почав флапати.

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

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

Постмортем висновок: сприймайте «вузол не в кластері» як проблему підключення і кворуму перш за все, а не як проблему файлів. Кластер — це система, а не папка.

Коротка історія 2: Оптимізація, що обернулася проти

Середня компанія вирішила зробити мережу Proxmox «швидшою». Хтось ввімкнув MTU 9000 на VLAN сховища і подумав, чому б не застосувати це й до кільця Corosync. Половина комутаторів підтримувала jumbo frames end‑to‑end, половина — «трохи», а деякі NIC вимагали тонкого налаштування драйверів.

Одразу нічого не вибухнуло — так зазвичай починаються такі історії. Протягом кількох тижнів з’явилися періодичні короткі зміни членства кластера. Вузол падав, повертався, падав знову. HA вагалася. У логах згадувалися втрачені токени. Усіх обурювало «Proxmox нестабільний».

Проблема була в тому, що Corosync цінує передбачуваність, а не теоретичну пропускну здатність. Невідповідність jumbo frames спричинила мікробурсти і локальні втрати, які звичайний трафік не помітив, а Corosync помітив.

Вони вирішили повернути Corosync‑мережу до MTU 1500 і залишити jumbo лише там, де могли гарантувати end‑to‑end підтримку. Кластер став «нудним» знову. Продуктивність майже не змінилася. Доступність покращилася.

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

Інша організація мала п’яти вузловий Proxmox‑кластер з Ceph і строгим контролем змін. Кожна зміна мережі проходила через чекліст: перевірити резолюцію імен, NTP, досяжність кільця Corosync, підтвердити pvecm status quorate і зберегти поточну версію corosync.conf.

Одного дня перезавантаження комутатору спричинило короткий outage кластерної мережі. Один вузол повернувся з повідомленням «вузол не в кластері». Команда не імпровізувала — витягла чекліст.

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

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

Часті запитання

1) Чи означає «вузол не в кластері», що мої ВМ зникли?

Ні. Це означає, що контрольна площина не може підтвердити стан кластера. Диски ВМ зазвичай знаходяться на локальному або спільному сховищі або в Ceph; вони не зникають через проблему Corosync. Але конфіги ВМ, що зберігаються в /etc/pve, можуть бути невидимі, якщо pmxcfs не змонтовано.

2) Чи можна просто виконати pvecm add і рухатися далі?

Тільки якщо ви впевнені, що вузол було коректно видалено або це чиста інсталяція, яку ви маєте намір додати. Якщо кластер ще вважає, що вузол існує, приєднання без очищення може створити конфлікти. Перевірте pvecm nodes з робочого вузла перед діями.

3) Яка найбезпечніша перша дія при цьому?

Перевірте кворум і стан Corosync з робочого вузла. Якщо кластер має кворум, проблема локалізована. Якщо ні — відновіть кворум перед будь‑якими руйнівними діями.

4) Чому /etc/pve іноді стає доступним тільки для читання?

Тому що Proxmox відмовляється приймати записи, коли членство кластера недовірене (часто через втрату кворуму). Це запобігає split brain і розбіжностям конфігурації.

5) Як чинити в двовузловому кластері?

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

6) Чи безпечно копіювати corosync.conf з іншого вузла?

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

7) Після приєднання чому мої сховища відсутні в UI?

Тому що визначення сховищ знаходяться в конфігу кластера (/etc/pve/storage.cfg). Якщо pmxcfs не змонтовано або ви неправильно приєднали вузол, він може не мати реплікованого конфігу. Перевірте монтування /etc/pve і порівняйте storage.cfg між вузлами.

8) Чи ускладнює Ceph повторне приєднання Proxmox‑вузла?

Ceph збільшує площу ураження, але не кардинально не змінює механіку приєднання. Керування членством Proxmox і Ceph — окремі системи. Потрібно переконатися, що вузол не спричинить подвійних монтувань або плутанини з OSD, але спочатку виправляється Corosync/кворум.

9) Що робити, якщо вузол було перейменовано і я хочу зберегти нове ім’я?

Не перейменовуйте «на місці» й не сподівайтеся, що кластер «підтягне» зміну. Видаліть вузол з кластера, очистіть його стан, встановіть нове hostname послідовно всюди, і потім додайте його як нового учасника. Заплануйте вплив на конфіги ВМ і моніторинг.

10) Коли перевстановлення дійсно виправдане?

Коли ОС скомпрометовано, безнадійно неправильно налаштовано, або ви не довіряєте стану вузла — і ви маєте чистий процес видалення/додавання вузлів. Перевстановлення як перша реакція зазвичай є виявом нетерплячки, замаскованої під рішучість.

Наступні кроки, які вам варто виконати

Якщо у вас зараз інцидент у тикеті, виконайте ці кроки в порядку:

1. Визначте статус кворуму з робочого вузла за допомогою pvecm status. Якщо немає кворуму — відновіть його перед «повторним приєднанням».
2. На проблемному вузлі: підтвердіть hostname, резолюцію імен, синхронізацію часу і що /etc/pve змонтовано.
3. Прочитайте логи Corosync. Вони рідко поетичні, але зазвичай чесні.
4. Виправте нудні мережеві речі: невідповідність MTU, VLAN‑теги, фаєрвол, зміни імен інтерфейсів.
5. Оберіть правильний план відновлення:
   • План A, якщо ідентичність цілісна і вузол ще в списку.
   • План B, якщо ідентичність застаріла (перевстановлення/перейменування/новий ключ).
   • План C, якщо підозрюється split brain — оберіть джерело істини і додавайте решту акуратно.
6. Після відновлення: перевірте сховища, стан HA і задачі реплікації. Не оголошуйте перемогу, поки нудні перевірки не пройдені.

Потім зробіть послугу собі в майбутньому:

• Документуйте кластерну мережу (інтерфейси, VLAN, MTU, зони фаєрволу) і зробіть її навмисно нудною.
• Якщо у вас два вузли — додайте quorum device або явно прийміть операційні обмеження.
• Програйте процедуру видалення/додавання вузла в лабораторії один раз. Інциденти — поганий час вчитися, що таке pmxcfs.