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

Ментальна модель: що насправді означає «видалити вузол»

У Proxmox VE «видалити вузол» — це не одна дія. Це щонайменше чотири різні речі, що мають однакову кнопку:
членство в кластері, стан файлової системи кластера, очікування на рівні сервісів (HA-менеджер, планування, плагіни сховища),
і те, які робочі навантаження були прив’язані до цього вузла (VM, контейнери, демони сховища).

В основі — членство Corosync плюс розподілена база конфігурації Proxmox (pmxcfs), змонтована під
/etc/pve. Коли ви виконуєте pvecm delnode, ви кажете кластерам, що лишилися:
«Припиніть очікувати від цього вузла участі в рішеннях кворуму і видаліть його присутність у спільному стані.»
Якщо у вас немає кворуму або залишилися вузли не погоджуються зі спільним станом, чистого видалення не буде — бо кластери ворожі до односторонніх змін. І не без причин.

Правило просте, але дратівливе: зміни членства вимагають здорового кластера.
Коли кластер не в порядку, перестаньте вигадувати та починайте контролювану операцію:
стабілізуйте кворум, заморозьте зміни, потім видаліть вузол. Якщо не стабілізувати спочатку, ви можете створити split brain,
який виглядає нормально в UI доти, доки не стане не нормально. А «доки не стане не нормально» зазвичай відбувається під час перезавантаження хоста.

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

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

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

1) Спочатку кворум і членство (завжди)

• Перевірте pvecm status. Якщо немає кворуму — ви нічого чисто не видалите.
• Перегляньте journalctl -u corosync на предмет змін членства, таймаутів токена або повідомлень «not in quorum».
• Перевірте, чи вузол, який ви видаляєте, все ще фігурує в «Expected votes» у кластері.

2) Файлова система кластера (pmxcfs) друге

• Підтвердіть, що pve-cluster здоровий на залишених вузлах.
• Перевірте, чи відгукується /etc/pve; завислий FUSE-монтаж робить будь-яку команду керування жахливою.
• Шукайте застарілі lock-файли (рідко) або вузол, що застряг із застарілими версіями конфігу.

3) Робочі навантаження й HA третє

• Якщо увімкнено HA, впевніться, що вузол більше не посилається в HA-групах чи ресурсах.
• Переконайтеся, що жодна конфігурація VM/CT не посилається на локальне сховище цього вузла як на основне місце.
• Якщо є Ceph, упевніться, що ви не плутаєте «видалити Proxmox-вузол» із «видалити хост з Ceph». Це пов’язані, але не ідентичні кроки.

4) Тепер виконуйте видалення

• Запустіть pvecm delnode з одного з здорових вузлів.
• Перевірте corosync.conf і оновлення списку вузлів, що реплікуються через /etc/pve.
• Лише після цього очистіть видалений вузол, щоб він не зміг випадково повернутися.

Цікаві факти та контекст (чому Proxmox так поводиться)

• Corosync походить із світу Linux HA, створений для координації членства в кластерах, де правильність важливіша за зручність.
• Кворум — це засіб безпеки, а не функція продуктивності: він запобігає утворенню «двох кластерів у одному» (split brain), які обидва вносять зміни.
• Proxmox зберігає конфігурацію кластера у розподіленій файловій системі (pmxcfs), змонтованій у /etc/pve, тому правки там впливають на всі вузли.
• Історично split brain сформував інструменти для кластерів: багато суворих поведінок — це шрами від попередніх HA-стеків, де «best effort» корумпував стан.
• Кластери з двома вузлами за визначенням незручно поводяться, бо більшість голосів крихка; зазвичай потрібен tiebreaker (qdevice) або варто приймати ризик простою.
• Голоси важливі: кворум Corosync базується на голосах; «expected votes», що включають мертві вузли, можуть залишити кластер без кворуму.
• HA-менеджер Proxmox має жорсткі припущення: він радше зафенсить або зупинить робочі навантаження, ніж дозволить невизначений стан — це дратує, поки не врятує.
• Членство Ceph відокремлене від членства Proxmox: видалення вузла Proxmox автоматично не видаляє OSD/моніторів Ceph, і хаотичне змішування цих кроків — типовий рецепт простою.
• Зміни кластера серіалізуються через кворум: якщо не можете досягти консенсусу, Proxmox віддасть перевагу відмові операції, а не вгадуванню.

Перед тим як щось торкатися: запобіжні заходи

Визначте тип видалення: планове чи непланове

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

Переконайтеся, що ви не видаляєте єдину копію чогось

Локальне сховище — пастка. Якщо ви використовували node-local ZFS, LVM-Thin або каталогове сховище та ніколи не реплікували, то «видалити вузол»
може означати «видалити єдине місце, де існували ці диски». Членство кластера — легко. Дані — складно.

Операційні правила (запишіть на стікері)

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

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

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

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

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

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

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

Quorum information
------------------
Date:             Fri Dec 26 13:10:43 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2f
Quorate:          Yes

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

Значення: «Quorate: Yes» означає, що зміни кластера дозволені. «Expected votes» має відповідати кількості вузлів, які ви плануєте мати.
Рішення: Якщо не quorate, зупиніться тут і виправте кворум (див. Завдання 2–4). Якщо quorate — продовжуйте планове видалення.

Завдання 2 — Перелічіть вузли, що відомі кластеру

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

Значення: Це членство кластеру, як його бачить Corosync.
Рішення: Якщо мертвий вузол ще фігурує та ви хочете його видалити, використайте pvecm delnode <name> з здорового вузла.

Завдання 3 — Перевірте стан служби Corosync на залишених вузлах

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-12-26 10:02:11 UTC; 3h 8min ago
       Docs: man:corosync
   Main PID: 1320 (corosync)
      Tasks: 11
     Memory: 38.4M
        CPU: 2.112s
     CGroup: /system.slice/corosync.service
             └─1320 /usr/sbin/corosync -f

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

Завдання 4 — Прочитайте логи Corosync на предмет втрати кворуму або проблем кільцевого зв’язку

cr0x@server:~$ journalctl -u corosync -n 50 --no-pager
Dec 26 13:02:18 pve01 corosync[1320]:   [KNET  ] link: host: 2 link: 0 is up
Dec 26 13:02:19 pve01 corosync[1320]:   [QUORUM] Members[2]: 1 2
Dec 26 13:02:19 pve01 corosync[1320]:   [QUORUM] This node is within the primary component and will provide service.
Dec 26 13:05:31 pve01 corosync[1320]:   [TOTEM ] Token has not been received in 3000 ms
Dec 26 13:05:31 pve01 corosync[1320]:   [TOTEM ] A processor failed, forming new configuration.
Dec 26 13:05:33 pve01 corosync[1320]:   [QUORUM] Members[3]: 1 2 3

Значення: «Token has not been received» вказує на сітьову нестабільність, невідповідний MTU або перевантажений хост.
Рішення: Якщо бачите часті переконфігурації, відкладіть видалення і стабілізуйте мережу кластера. Видалення вузла під час нестабільності — шлях до вихідних вихідних.

Завдання 5 — Підтвердіть, що pmxcfs (/etc/pve) відповідає

cr0x@server:~$ pvesh get /cluster/status
[
  {
    "id":"cluster",
    "name":"prod-pve",
    "quorate":1,
    "version":27
  },
  {
    "id":"node/pve01",
    "ip":"10.10.10.11",
    "local":1,
    "name":"pve01",
    "online":1,
    "type":"node"
  },
  {
    "id":"node/pve02",
    "ip":"10.10.10.12",
    "local":0,
    "name":"pve02",
    "online":1,
    "type":"node"
  }
]

Значення: API швидко читає статус кластера; pmxcfs, ймовірно, у порядку.
Рішення: Якщо це зависає або повертає помилку, може бути проблема з pmxcfs; вирішіть сервіс pve-cluster і кворум перед подальшими діями.

Завдання 6 — Перевірте посилання HA на вузол

cr0x@server:~$ ha-manager status
quorum OK
master pve01 (active, Fri Dec 26 13:12:19 2025)
lrm pve01 (active, Fri Dec 26 13:12:19 2025)
lrm pve02 (active, Fri Dec 26 13:12:17 2025)
service vm:101 (started)
service vm:203 (started)

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

Завдання 7 — Знайдіть VM/CT, які все ще налаштовані на вузлі, що видаляється

cr0x@server:~$ pvesh get /nodes/pve03/qemu --output-format yaml
- vmid: 310
  name: build-runner-03
  status: stopped
- vmid: 311
  name: legacy-db-test
  status: running

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

Завдання 8 — Перевірте залежності сховища (чи є щось локальне?)

cr0x@server:~$ pvesm status
Name             Type     Status           Total        Used       Avail
local            dir      active        19632040     3921040    14750212
local-zfs        zfspool  active        247463936   90218496   157245440
ceph-rbd         rbd      active       104857600    52428800    52428800
nfs-backup       nfs      active       209715200    73400320   136314880

Значення: «local-zfs» зазвичай локальне, якщо тільки це не якесь спільне ZFS-рішення (рідко). «ceph-rbd» і NFS — спільні.
Рішення: Якщо навантаження залежать від локального сховища, реплікуйте або перемістіть диски перед видаленням. Якщо вузол уже мертвий і диски були локальні, ваше завдання тепер — «відновлення з бекапу».

Завдання 9 — Перевірте завдання реплікації (якщо ви використовуєте ZFS replication)

cr0x@server:~$ pvesh get /cluster/replication
[
  {
    "id":"101-0",
    "source":"pve03",
    "target":"pve01",
    "schedule":"*/15",
    "last_sync":1735218600,
    "duration":42,
    "comment":"critical VM replication"
  }
]

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

Завдання 10 — Планове видалення: мігруйте гостей із вузла

cr0x@server:~$ qm migrate 311 pve01 --online
migration started
migration status: active
migration status: completed

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

Завдання 11 — Видаліть вузол з кластера (фактичне видалення)

cr0x@server:~$ pvecm delnode pve03
Removing node 'pve03' from the cluster
Stopping pve-cluster on removed node if reachable...
Updating corosync config
Waiting for quorum...

Значення: Кластер оновлює членство та синхронізує конфіг.
Рішення: Якщо завершилося успішно — перевірте Завдання 12–13. Якщо помилка з кворумом — спочатку відновіть кворум; не повторюйте безкінечно, як щось із нестабільним завантаженням.

Завдання 12 — Підтвердьте, що вузол зник із членства й очікувані голоси оновлено

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

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

Votequorum information
----------------------
Expected votes:   2
Total votes:      2
Quorum:           2
Flags:            Quorate

Значення: Кластер тепер очікує 2 голоси. Це коректно для кластера з 2 вузлів, але це також знак-увага.
Рішення: Якщо у вас залишилося 2 вузли, негайно вирішіть, чи додавати третій вузол або qdevice. Два вузли без tiebreaker — це ставка на надійність.

Завдання 13 — Перевірте, що в /etc/pve/nodes немає застарілої директорії вузла

cr0x@server:~$ ls -1 /etc/pve/nodes
pve01
pve02

Значення: Спільна конфігурація більше не відслідковує видалений вузол.
Рішення: Якщо директорія видаленого вузла все ще існує, pmxcfs може бути застряглий або кворум ніколи не був реальним. Перевірте Завдання 1–5 і уникайте ручного видалення, якщо ви не виконуєте контрольоване відновлення.

Завдання 14 — Переконайтеся, що видалений вузол більше не в corosync.conf (з будь-якого залишеного вузла)

cr0x@server:~$ grep -R "pve03" -n /etc/pve/corosync.conf || echo "no references"
no references

Значення: Конфіг Corosync чистий.
Рішення: Якщо посилання залишилися, ви фактично не видалили вузол або маєте проблеми з поширенням конфігу. Виправте pmxcfs/кворум, потім спробуйте ще раз.

Завдання 15 — Очищення на видаленому вузлі (якщо він все ще доступний)

cr0x@server:~$ systemctl stop pve-cluster corosync
cr0x@server:~$ rm -f /etc/pve/corosync.conf
cr0x@server:~$ rm -f /etc/corosync/authkey
cr0x@server:~$ rm -f /var/lib/corosync/*
cr0x@server:~$ systemctl disable corosync pve-cluster
Removed "/etc/systemd/system/multi-user.target.wants/corosync.service".
Removed "/etc/systemd/system/multi-user.target.wants/pve-cluster.service".

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

Завдання 16 — Якщо видалення не вдається через «not quorate»: ідентифікуйте залишені вузли, які погоджуються

cr0x@server:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Fri Dec 26 13:18:22 2025
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1.30
Quorate:          No

Votequorum information
----------------------
Expected votes:   3
Total votes:      2
Quorum:           2

Значення: Маєте два вузли вгору, але expected votes все ще 3, отже ви не в кворумі.
Рішення: Негайне виправлення — відновити кворум (повернути третій, або використати qdevice, якщо це була ваша архітектура). Тільки в екстреному випадку тимчасово налаштуйте expected votes, щоб повернути кворум для кроків відновлення — див. покрокову секцію для запобіжних заходів.

Жарт №2: Найшвидший спосіб вивчити математику кворуму — зламати її одного разу, бажано в лабораторії, а не під час обробки заробітної плати.

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

План A: Планова дейкомісія (вузол доступний)

1. Оголосіть вікно змін. Тримайте його коротким, але не робіть цього під час мережевих робіт на тих самих комутаторах.
2. Перевірте здоров’я кластера та кворум на залишеному вузлі.
   Виконайте Завдання 1–5. Якщо щось флапає, зупиніться й виправте стабільність.
3. Злийте вузол.
   • Міграція або завершення роботи VM/CT (Завдання 10, і для CT відповідник pct migrate, якщо потрібно).
   • Вимкніть очікування планувальника: якщо є HA, впевніться, що ресурси не прив’язані до вузла (Завдання 6).
4. Перевірте залежності сховища.
   Виконайте Завдання 8. Якщо залучено локальне сховище, реплікуйте або перемістіть диски спочатку (Завдання 9).
5. Виконайте видалення з здорового залишеного вузла: Завдання 11.
6. Підтвердіть видалення: Завдання 12–14.
7. Очистіть видалений вузол: Завдання 15.
8. Збалансуйте та укріпіть.
   Якщо у вас залишилося два вузли, вирішіть: додати третій або додати qdevice. Не «відкладайте на потім», якщо «потім» не заплановано.

План B: Непланована втрата (вузол мертвий або недосяжний)

1. Фізично або логічно ізолюйте мертвий вузол.
   Якщо він флапає в мережі, може порушувати Corosync. Відключіть NIC, вимкніть порт комутатора або вимкніть живлення.
2. Стабілізуйте кворум на тих вузлах, що вижили.
   Використайте Завдання 1 і 4. Якщо немає кворуму, ваш пріоритет — відновлення кворуму, а не косметика очищення.
3. Підтвердьте робочі навантаження і місце даних мертвого вузла.
   Виконайте Завдання 7 і 8 з вузлів, що вижили. Прийміть рішення:
   • Якщо диски на спільному сховищі (Ceph/NFS/iSCSI), ви можете перезапустити гостей в інших вузлах.
   • Якщо диски були локальними, перейдіть у режим відновлення: бекапи, репліки або відновлення.
4. Видаляйте вузол тільки після того, як ви в кворумі.
   Завдання 11. Якщо кластер відмовляється через кворум, не робіть випадкових правок у /etc/pve, якщо не виконуєте відновлення.
5. Після видалення підтвердіть членство та чистий стан конфігу.
   Завдання 12–14.

План C: Екстрене відновлення, коли кворум неможливий (використовуйте рідко)

Іноді у вас був 3-вузловий кластер, ви втратили 2 вузли, і керівництво хоче, щоб «останній вузол» обслуговував навантаження.
Це не режим кластеру. Це режим виживання. Можна це зробити, але ставтесь до цього як до екстреного живлення: голосно, неприємно, тимчасово.

Безпечна порада: відновіть достатню кількість вузлів, щоб повернути кворум, або використовуйте належний quorum device, якщо середовище дозволяє.
Якщо ви наполегливо йдете до роботи з одним вузлом, ви свідомо відключаєте механізм безпеки, який запобігає split brain.
Зробіть це явно, задокументуйте та заплануйте відновлення до підтримуваного стану.

Якщо вам потрібно тимчасово примусово змінити expected votes для операцій відновлення (не для «нормальної роботи»), робіть це усвідомлено:

cr0x@server:~$ pvecm expected 1
Setting expected votes to 1
WARNING: forcing expected votes can lead to split-brain if other nodes are active

Значення: Ви кажете Corosync, що одиночний вузол вважається кворумом.
Рішення: Робіть це лише коли впевнені, що інші вузли не роблять одночасних змін (вимкніть їх/ізолюйте). Після відновлення вузлів відновіть expected votes, дозволивши членству нормалізуватися (або повторно приєднати вузли коректно).

Три корпоративні міні-історії з реального життя

Інцидент через неправильне припущення: «офлайн — значить безпечно видалити»

Середня компанія мала три вузловий Proxmox кластер для внутрішніх сервісів. Один вузол почав викидати помилки ECC.
Він був все ще досяжний, але перезавантажувався непередбачувано. Інженер на чергуванні зробив розумне припущення:
«Якщо він офлайн в UI, видалення — це просто прибирання».

Вони запустили pvecm delnode, коли Corosync уже мав періодичні таймаути токена.
Кластер технічно був кворумним в момент команди. Через десять хвилин хисткий вузол повернувся,
ненадовго приєднався зі старим станом, потім знову впав. Залишені вузли довго не погоджувалися щодо членства, і pmxcfs
почав відставати, а рутинна операція запуску VM застопорилась.

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

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

Оптимізація, яка відбилася бумерангом: «попрацюємо на 2 вузлах деякий час»

Інша організація мала тиск на бюджет і обмеження по місцю в шафі. Вони вирішили тимчасово видалити один вузол Proxmox,
працювати на двох вузлах протягом кварталу, а потім додати потужність. На папері все виглядало добре:
більшість сховища була на спільному iSCSI, а VM були легкі.

Вони видалили вузол чисто. Кворум усе ще показував «Yes», бо expected votes відповідали двом вузлам.
І в повсякденній роботі це працювало — поки не стався перший реальний інцидент мережі.
Комутатор верхнього рівня перезавантажився і два вузли втратили зв’язок Corosync настільки, що обидва вузли
вирішили, що вони у біді. HA став консервативним. Деякі сервіси відновилися, інші зупинилися, а кілька зависли у статусі «unknown».

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

Оптимізацію скасували: вони додали легкий quorum device в окремій доменній зоні відмови.
Після цього планове обслуговування вузлів перестало бути драмою. Урок не в «ніколи не працювати на двох вузлах».
Урок — «не прикидатися, що два вузли поводяться як три».

Нудна, але правильна практика, яка врятувала день: «runbook дейкомісії + очищення»

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

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

Вузол піднявся як звичайний Debian-хост без ідентичності кластера. Ніхто не намагався приєднатись. Голоси не змінились.
Кластер навіть не помітив. Найголоснішим було зітхання з полегшенням і розуміння, що чекліст має сенс.

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

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

1) Симптом: pvecm delnode не вдається з помилкою «cluster not ready» або «not quorate»

Корінь: Немає кворуму (expected votes все ще включає відсутній вузол або нестабільність кільця Corosync).

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

2) Симптом: Вузол зникає з pvecm nodes, але все ще показується в UI / /etc/pve/nodes

Корінь: Реплікація pmxcfs відстає, pve-cluster застряг або вузол фактично не кворумний.

Виправлення: Перевірте сервіс pve-cluster, підтвердьте відповідання API (Завдання 5), підтвердьте кворум (Завдання 1),
потім повторіть видалення. Уникайте ручного видалення в /etc/pve, якщо ви не виконуєте контрольоване відновлення.

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

Корінь: У вас тепер 2-вузловий кластер без tiebreaker або мережевий дизайн, що не терпить розділень.

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

4) Симптом: HA продовжує намагатися відновити ресурси «на видаленому вузлі»

Корінь: HA-конфіг все ще посилається на вузол/групи; застарілі обмеження розміщення ресурсів.

Виправлення: Перевірте статус ha-manager, оновіть HA-групи, відключіть/видаліть ресурси, що посилаються на вузол, потім перевірте знову.

5) Симптом: Гості не запускаються в інших вузлах після втрати вузла

Корінь: Диски були на локальному сховищі; «кластер» не означає спільного сховища.

Виправлення: Відновіть з бекапу, промотуйте репліки або відновіть сховище. На майбутнє: реплікуйте ZFS-датасети або використовуйте спільне сховище (Ceph/NFS/iSCSI) для критичних навантажень.

6) Симптом: Видалений вузол повертається пізніше і «заново приєднується» або спричиняє плутанину в членстві

Корінь: Ви видалили його з кластера, але не очистили облікові дані/стан на хості; він зберіг /etc/corosync/authkey та старі конфіги.

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

7) Симптом: Операції з /etc/pve повільні/зависають під час спроб видалення

Корінь: pmxcfs заблокований через втрату кворуму або нестабільність corosync; FUSE-монтаж залежить від здоров’я кластера.

Виправлення: Спочатку стабілізуйте Corosync. Не вважайте це проблемою файлової системи; зазвичай це захист стану кластера.

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

1) Чому Proxmox відмовляється видалити вузол, коли він офлайн?

Тому що «офлайн» не рівно «консенсус». Видалення вузла оновлює спільний стан кластера. Без кворуму Proxmox не може безпечно
довести, що залишені вузли погоджуються зі зміною, тож блокує операцію, щоб уникнути split brain.

2) Чи можна просто видалити директорію вузла під /etc/pve/nodes?

Не робіть цього, якщо ви не виконуєте відновлення і не розумієте наслідків.
/etc/pve — не звичайна файлова система; це керований кластером стан. Ручні правки можуть розсинхронізувати вузли або приховати реальну проблему (кворум).

3) Який порядок безпеки: спочатку міграція навантажень чи видалення вузла?

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

4) Я видалив вузол і тепер у мене 2-вузловий кластер. Це «підтримується»?

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

5) Як дізнатися, чи диски VM на спільному чи локальному сховищі?

Перевірте визначення сховищ (pvesm status) і конфіг VM (qm config <vmid>), щоб побачити бекенди дисків.
Якщо вказано local-zfs або local, вважайте це локальним, якщо ви не спеціально не зробили інше.

6) Чи видалення вузла Proxmox також видаляє його з Ceph?

Ні. Ceph — окремий кластер. Ви маєте окремо видаляти OSD, монітори та записи CRUSH, якщо хост брав участь у Ceph.
Координуйте послідовність, щоб не відрізати розміщення даних або не втратити кворум у Ceph під час виправлення кворуму в Proxmox.

7) Що мені каже «Expected votes»?

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

8) Що якщо ім’я вузла потім буде повторно використане для нового хоста?

Не використовуйте ім’я, доки старий вузол повністю не видалено і очищено. Інструменти кластера часто орієнтуються на імена вузлів у шляхах конфігу.
Якщо мусите повторно використати ім’я, переконайтеся, що попереднє членство зникло і новий хост приєднується з новими ключами.

9) Чому UI іноді ще показує видалений вузол деякий час?

Стан UI може відставати від стану кластера, особливо якщо pmxcfs або API мали проблеми під час зміни.
Перевіряйте з pvecm nodes та /etc/pve/nodes; не довіряйте графічному інтерфейсу як єдиному джерелу правди під час інциденту кластера.

10) Яка найпоширеніша причина, через яку видалення вузла йде не так?

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

Висновок: подальші кроки, які не переслідуватимуть вас

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

Якщо ви зробите одну річ після читання: стандартизуйте runbook дейкомісії, що включає (1) перевірку кворуму,
(2) перевірки залежностей сховища, і (3) очищення на видаленому хості. Це нудна практика, яка не дозволяє «не вдається видалити вузол»
перетворитись на «не можу керувати кластером».

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

• Запустіть Завдання 1–5 на вашому кластері зараз і зафіксуйте, як «здоровий» виглядає у вашому середовищі.
• Якщо ви коли-небудь працюєте з двома вузлами, визначте стратегію третього голосу і заплануйте її реалізацію.
• Аудитуйте, які навантаження все ще залежать від локального сховища, і або реплікуйте їх, або свідомо прийміть біль відновлення.
• Зробіть правило непорушним: «ізолюйте видалені вузли»: вимкнення живлення, відключений порт або витерто. Краще — усі три.