Proxmox HA «не може запустити ресурс»: як знайти справжній блокувальник (кворум, сховище, мережа)

Що насправді означає «не може запустити ресурс» в термінах HA

У Proxmox HA «ресурс» зазвичай означає VM або контейнер, за розміщенням, запуском, зупинкою та переміщенням якого відповідає стек HA (CRM + LRM + менеджер). Коли ви бачите «не може запустити ресурс», це зазвичай означає:

• Менеджер HA спробував виконати дію (запуск/міграція/відновлення), і цільовий вузол відмовився або не міг її виконати.
• Або менеджер HA відмовився діяти, бо вважав, що це може створити split-brain, подвійне підключення диску або подвійний запуск.

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

Одне висловлювання варте запам’ятовування, бо воно відображає ставлення HA-систем:

«Сподівання — це не стратегія.» — Генерал Гордон Р. Салліван

HA не працює на сподіваннях. Вона працює на чіткому стані і перевіреній досяжності. Якщо цього немає — вона зупиняється.

Швидкий план діагностики (першочергово/друге/третє)

Що робити, коли керівник стоїть над плечем, VM впала, а інтерфейс HA відповідає знизуванням плечима.

Перше: підтвердьте, що кластер може приймати рішення (кворум + членство)

• Перевірте кворум (pvecm status). Без кворуму немає надійного «хто за що відповідає».
• Перевірте членство corosync (corosync-cfgtool -s, corosync-quorumtool -s). Шукайте відсутні вузли, проблеми з кільцем або «partitioned».
• Перевірте, що pmxcfs змонтовано і здорове (df -h /etc/pve).

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

Друге: переконайтеся, що стан менеджера HA не бреше (стан CRM/LRM)

• ha-manager status для ресурсу і вузла, на якому, за версією менеджера, він має працювати.
• На кожному вузлі: systemctl status pve-ha-lrm pve-ha-crm.
• Підгляньте логи: journalctl -u pve-ha-crm -u pve-ha-lrm -n 200 --no-pager.

Рішення: Якщо служби HA несправні або зависли на вузлі — виправте це, перш ніж робити ручні запуски VM. Перегони з HA — не та гра, в якій ви виграєте.

Третє: перевірте, чи потрібне сховище дійсно доступне на цільовому вузлі

• Перевірте стан сховища Proxmox (pvesm status) і підтвердіть, що диски VM знаходяться на доступному сховищі на вузлі.
• Для спільного сховища: перевірте монтаж/підключення (NFS/iSCSI/Ceph/ціль ZFS реплікації).
• Шукайте блокування (qm config вивід містить lock:) і перегляньте історію завдань.

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

Усе інше — навантаження CPU, пам’яті, системні логи, очікування на fencing — іде після цих трьох. Будьте спочатку правильними, потім — кмітливими.

Ментальна модель: кворум, членство, менеджер і реальність сховища

Кворум — це не «кластер працює». Це «кластер може погодитися».

Кворум — механізм, який запобігає split-brain: двом половинам кластера, що обидві думають, що вони справжні. Без кворуму Proxmox навмисно обмежує записи в файлову систему кластеру і блокує певні дії. Дії HA — серед перших, які відмовляються, бо HA без консенсусу — шлях до подвійних запусків VM і пошкодження дисків.

Corosync — це нервова система; затримки — її отрута

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

pmxcfs — ваш спільний мозок

/etc/pve підкріплено pmxcfs (файлова система кластеру Proxmox). Це не звичайна спільна файлова система; це база даних кластера, подана як файлову систему. Якщо її не змонтовано або вона не доступна для запису через втрату кворуму, конфігурації можуть здаватися «застарілими», HA не може надійно координувати дії, і ви отримаєте помилки, що виглядають як проблеми VM, але насправді — «метадані кластера неконсистентні».

Сховище — найпоширеніший реальний блокувальник, бо там можуть пошкодитися дані

HA може запустити VM на вузлі лише якщо диски доступні і безпечні. «Безпечні» означає: бекенд сховища присутній, диски VM не змонтовані десь ще, і будь-які блокування (міграція, снапшот, резервне копіювання) розв’язані. Багато бекендів можуть бути «вгору», але все ще небезпечними: застарілий NFS-монтаж, сесія iSCSI, що існує, але таймаутиться, Ceph у деградованому режимі з блокованим I/O, або ZFS, який живий, але у стані сильного латентного навантаження.

Жарт #1: Висока доступність як пожежна тривога: усім подобається ідея, доки не потягнули за ручку.

Цікаві факти і контекст (чому є гострі кути)

• Факт 1: Концепція кворуму передує багатьом віртуалізаційним стеком; це класичний розподілений механізм контролю, щоб запобігти split-brain у кластерних сховищах та базах даних.
• Факт 2: Corosync еволюціонував із ранніх зусиль з кластерного обміну повідомленнями в Linux, де стабільне членство вважалося наріжним каменем безпечного failover.
• Факт 3: pmxcfs у Proxmox навмисно поводиться інакше за умов відсутності кворуму: він віддає пріоритет безпеці над зручністю, тому записи можуть блокуватися навіть коли вузли «виглядають нормальними».
• Факт 4: HA-стеки зазвичай розділяють «прийняття рішень» (cluster resource manager) від «виконання» (local resource manager). Proxmox дотримується цієї моделі з компонентами CRM і LRM.
• Факт 5: Fencing сховища (забезпечення, щоб упавший вузол не міг писати в спільне сховище) старший за сучасні гіпервізори; він походить від кластерних файлових систем і SAN-середовищ, де один «шалений» записувач міг усе зіпсувати.
• Факт 6: Протоколи типу «heartbeat» історично страждали від хибних спрацьовувань під час заторів; сучасні стеки досі зіштовхуються з тією самою фізикою: втрати і jitter виглядають як смерть вузла.
• Факт 7: Підходи «shared-nothing» (наприклад локальний ZFS + реплікація) зменшують моди відмов спільного сховища, але вводять проблему «яка копія авторитетна» — це все ще питання кворуму, просто в іншому вигляді.
• Факт 8: Багато інцидентів HA викликані не повною відмовою, а частковою: вузол працює, лінк непевний, сховище напівживе. HA не любить часткових відмов, бо вони неоднозначні.
• Факт 9: «Не може запустити ресурс» часто є навмисним повідомленням безпеки. Це HA говорить, що не може довести безпечність запуску, а не те, що воно спробувало і зазнало поразки як при звичайному ручному запуску.

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

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

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

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

Quorum information
------------------
Date:             Fri Dec 26 10:14:03 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.22
Quorate:          Yes

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

Що це означає: Quorate: Yes означає, що кластер може приймати авторитетні рішення і pmxcfs має бути доступним для запису. Якщо там No, дії HA часто будуть заблоковані.

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

Завдання 2: Перевірте стан кілець corosync (чи всі лінки здорові?)

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

Що це означає: «active with no faults» — це бажаний результат. Помилки тут тісно корелюють з тим, що HA відмовляє в діях або ресурси «флапають».

Рішення: Якщо кільце має помилки — виправляйте мережу/MTU/vLAN/jumbo frames перед тим, як торкатися HA. Неправильна подвійна конфігурація кілець — класична пастка «виглядає як надмірність, поводиться як крихкий механізм».

Завдання 3: Перевірте деталі кворуму corosync (підказки по розділам)

cr0x@server:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Fri Dec 26 10:15:31 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          1
Ring ID:          1.22
Quorate:          Yes

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

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

Рішення: Якщо немає кворуму: ставте це інцидентом кластера, а не проблемою конкретної VM.

Завдання 4: Переконайтеся, що pmxcfs змонтовано (і не в сумному стані)

cr0x@server:~$ df -h /etc/pve
Filesystem      Size  Used Avail Use% Mounted on
pmxcfs            0     0     0    - /etc/pve

Що це означає: Це виглядає дивно, бо це не нормальна файлова система. Якщо ви бачите «not mounted» або воно вказує на щось інше, розповсюдження конфігурації кластера зламане.

Рішення: Якщо /etc/pve не pmxcfs — виправляйте сервіси кластера. HA не буде поводитися передбачувано.

Завдання 5: Перевірте, як HA бачить світ

cr0x@server:~$ ha-manager status
quorum OK
master pve01 (active, Fri Dec 26 10:16:12 2025)

service vm:101 (pve-ha-lrm:pve02, running)
service vm:105 (pve-ha-lrm:pve03, stopped)
service ct:210 (pve-ha-lrm:pve01, running)

Що це означає: Ви бачите HA-master, стан кворуму і де HA думає, що кожен ресурс має виконуватись. Якщо ваша проблемна VM «зупинена», але має бути запущеною — зосередьтеся на тому, чому її не розміщують.

Рішення: Якщо master флапає між вузлами — скоріше за все є нестабільність corosync. Виправте це раніше, ніж щось інше.

Завдання 6: Занурення в стан одного ресурсу і останні дії

cr0x@server:~$ ha-manager status vm:105
service vm:105
  state: stopped
  desired: started
  node: pve03
  last_error: unable to start VM 105 on node 'pve03': storage 'ceph-vm' is not available

Що це означає: Це — ключова рядок. HA часто говорить вам справжній блокувальник в last_error. Не ігноруйте його тільки тому, що його немає в GUI.

Рішення: Якщо last_error вказує на сховище — переключайтеся на перевірки сховища на цьому вузлі негайно.

Завдання 7: Перевірте здоров’я сервісів HA (CRM/LRM)

cr0x@server:~$ systemctl status pve-ha-crm pve-ha-lrm --no-pager
● pve-ha-crm.service - PVE Cluster Resource Manager Daemon
     Loaded: loaded (/lib/systemd/system/pve-ha-crm.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:01:12 UTC; 1h 15min ago

● pve-ha-lrm.service - PVE Local Resource Manager Daemon
     Loaded: loaded (/lib/systemd/system/pve-ha-lrm.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:01:14 UTC; 1h 15min ago

Що це означає: Якщо якийсь із сервісів не працює — оркестрація HA порушена. LRM — це «руки» на кожному вузлі; CRM — «мозок» координації.

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

Завдання 8: Читайте логи HA ніби маєте на це намір

cr0x@server:~$ journalctl -u pve-ha-crm -u pve-ha-lrm -n 200 --no-pager
Dec 26 10:12:44 pve01 pve-ha-crm[2123]: status change: node pve03 online
Dec 26 10:13:02 pve01 pve-ha-crm[2123]: trying to start vm:105 on pve03
Dec 26 10:13:07 pve03 pve-ha-lrm[1988]: unable to start vm 105: storage 'ceph-vm' is not available
Dec 26 10:13:07 pve01 pve-ha-crm[2123]: service vm:105 start failed on node pve03 (exit code 255)

Що це означає: Ви отримуєте часову лінію. Якщо лог каже «storage not available» — припиняйте дискусії. Це — сховище.

Рішення: Слідуйте за помилкою на вузлі, де LRM зазнав невдачі. Там знаходиться відсутня залежність.

Завдання 9: Підтвердьте стан сховища в погляді Proxmox

cr0x@server:~$ pvesm status
Name         Type     Status           Total        Used       Avail
local        dir      active        19528604     7824480    10716524
local-lvm    lvmthin  active        19000000     9200000     9800000
ceph-vm      rbd      inactive              0           0           0

Що це означає: inactive означає, що Proxmox не буде його використовувати. HA не запустить VM, чиї диски там лежать. Це не предмет переговорів.

Рішення: Виправте підключення Ceph/RBD на тому вузлі, або перемістіть/відновіть диски на інше сховище, або змініть обмеження розміщення HA.

Завдання 10: Перевірте диски VM і де вони зберігаються

cr0x@server:~$ qm config 105
boot: order=scsi0;net0
cores: 4
memory: 8192
name: api-prod-01
net0: virtio=DE:AD:BE:EF:00:01,bridge=vmbr0
scsi0: ceph-vm:vm-105-disk-0,size=80G
scsihw: virtio-scsi-pci

Що це означає: Диск на ceph-vm. Якщо pvesm status каже, що це сховище неактивне на цільовому вузлі — ви знайшли блокувальник.

Рішення: Не намагайтеся «запустити попри все». Активуйте сховище або перенесіть диски на доступний бекенд.

Завдання 11: Шукайте блокування, які перешкоджають запуску

cr0x@server:~$ qm config 105 | grep -E '^lock:|^template:'
lock: backup

Що це означає: Блокування може завадити старту/міграції. Блок backup часто лишається після перерваної резервної операції або проблем со сховищем.

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

Завдання 12: Перегляньте недавні завдання на предмет невдач, що залишили стан

cr0x@server:~$ tail -n 30 /var/log/pve/tasks/index
UPID:pve01:00012A1B:0A2F3C4D:676D9B12:vzdump:105:root@pam:
UPID:pve01:00012A40:0A2F3C99:676D9B55:qmstart:105:root@pam:
UPID:pve03:0000B120:0A2F3D01:676D9B90:ha-recover:105:root@pam:

Що це означає: Ви отримуєте «хлібні крихти» подій. Використайте UPID, щоб витягти подробиці.

Рішення: Якщо бачите повторювані невдалі старти чи відновлення — вважайте це системною проблемою (сховище/мережа), а не просто «спробуй ще раз».

Завдання 13: Витягніть реальний лог за UPID

cr0x@server:~$ cat /var/log/pve/tasks/0A/2F3C4D-676D9B12
INFO: starting new backup job: vzdump 105 --mode snapshot
ERROR: ceph-vm: rbd: error opening vm-105-disk-0: (2) No such file or directory
INFO: aborting backup

Що це означає: Якщо резервні копії падають через сховище — запуск HA може теж падати з тієї самої причини. Брак RBD-образів вказує на більш глибоку неконсистентність сховища.

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

Завдання 14: Швидко перевірте мережеве здоров’я кластера (втрати, помилки)

cr0x@server:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    8942349234 9023434      0     124       0       0
    TX:  bytes packets errors dropped carrier collsns
    7342342342 8234234      0       0       0       0

Що це означає: Втрати на мережі corosync (або на спільному bond) — це червоний прапор. Corosync терпить певні втрати, але стабільна робота HA вимагає нудної, надійної мережі.

Рішення: Якщо під час інцидентів кількість dropped зростає — перевіряйте буфери комутаторів, невідповідність MTU, LACP hashing або насичення лінку.

Завдання 15: Перевірте синхронізацію часу (так, це важливіше, ніж хочете)

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

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

Рішення: Якщо немає синхронізації — виправте NTP/chrony на всіх вузлах перед тим, як ганятися за «рандомним» поведінкою HA.

Завдання 16: Переконайтеся, що VM фактично не працює десь ще

cr0x@server:~$ qm list | awk '$1==105 {print}'
105 api-prod-01               stopped    8192     4

Що це означає: Proxmox каже, що VM зупинена на цьому вузлі. Повторіть на інших вузлах, якщо підозрюєте split-brain або застарілий стан.

Рішення: Якщо знайдете її запущеною на іншому вузлі — не запускайте другу копію. Негайно досліджуйте розміщення HA і блокування.

Виявлення справжнього блокувальника: кворум vs сховище vs мережа vs стан

1) Втрата кворуму: мовчазне «зупиніть усе»

Коли кворум втрачається, багато систем виглядають так, ніби працюють. Вузли завантажуються. Ви можете SSH. Можливо, навіть доступ до локального сховища є. Інтерфейс може відображатися. Але HA все одно відмовиться виконувати потрібну операцію, бо не може довести її безпечність.

Типові ознаки:

• pvecm status показує Quorate: No.
• /etc/pve доступний лише для читання або не синхронізується між вузлами.
• HA-master флапає або HA повідомляє «quorum not OK».

Що робити: Відновіть підключення між більшістю вузлів. Якщо у вас двовузловий кластер без третього голосу, ви навмисно ходите по краю. Додайте пристрій кворуму або третій вузол, якщо хочете, щоб HA поводився як реальна HA-система.

2) Мережевий поділ: кластер не може домовитися, бо не може спілкуватися

Поділи гірші за просто відмови. Відмова чесна; поділ — брехун. При поділі обидві сторони можуть бути живими. Обидві можуть вважати іншу померлою. Саме так і народжується пошкодження даних.

Типові ознаки:

• Помилки corosync на одному або кількох вузлах.
• Перемінні зміни членства в journalctl -u corosync.
• Втрати пакетів, невідповідність MTU або «допоміжне» правило firewall, додане кимось, хто ненавидить вихідні.

Що робити: Стабілізуйте мережу corosync: виділений VLAN, узгоджений MTU скрізь, жодного асиметричного маршруту, без фільтрації і передбачувана затримка. HA любить нудність. Дайте їй її.

3) Сховище недоступне: блокувальник, який HA правомірно забезпечує

Проблеми зі сховищем дають найпоширеніше «не може запустити ресурс», бо вони одночасно часті і небезпечні. HA відмовиться запускати, якщо не може безпечно отримати диски VM. «Безпечно» включає «не використовується десь ще».

Типові ознаки:

• pvesm status показує сховище inactive на цільовому вузлі.
• Помилки Ceph/RBD в логах, тайм-аути iSCSI або NFS «stale file handle».
• Конфіг VM вказує на сховище, якого немає на всіх вузлах групи HA.

Що робити: Забезпечте однакову доступність сховища для всіх вузлів, які можуть виконувати ресурс, або обмежте ресурс лише вузлами з потрібним доступом. Розміщення HA без симетрії сховища — це хаос у кілька додаткових кроків.

4) Блокування і застарілий стан: HA чекає умови, яка не зникає

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

Типові ознаки:

• qm config показує lock: значення як backup, migrate, snapshot.
• Завдання показують операції, що ніколи не завершились.
• Статус HA демонструє повторювані спроби з кодами помилок без прогресу.

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

Жарт #2: Єдина річ гірша за завислий менеджер HA — це два «розблокованих» менеджери, кожен переконаний, що він герой.

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

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

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

Корінь проблеми: Тимчасова втрата кворуму або нестабільність членства corosync під час перезавантаження; HA відмовляється діяти безпечно.

Виправлення: Перевірте pvecm status на наявність кворуму і здоров’я кілець corosync. Не ганяйтеся за логами VM, поки кластер не погодиться щодо членства.

2) Симптом: VM стартує вручну за qm start, але HA не запускає її

Корінь проблеми: Обмеження HA або стан HA-станової машини вважає, що VM належить іншому вузлу, або записана попередня невдача; HA забезпечує політику, а не лише можливість.

Виправлення: Перевірте ha-manager status vm:ID і HA-групи. Узгодьте ручні дії з HA: або тимчасово вимкніть HA для цієї VM, або виправте проблему розміщення.

3) Симптом: Сховище показує «active» на одному вузлі, «inactive» на іншому

Корінь проблеми: Підключення бекенду специфічне для вузла: відсутні маршрути, зламаний multipath, проблеми аутентифікації Ceph, застарілий NFS-монтаж або firewall.

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

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

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

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

5) Симптом: HA постійно переміщує VM туди-сюди («ping-pong»)

Корінь проблеми: Флапінг членства corosync, періодичні невдачі перевірок здоров’я вузла або занадто агресивні таймаути запуску ресурсу.

Виправлення: Стабілізуйте мережу corosync, відкотіть надто агресивні налаштування таймаутів і перевірте вузлові обмеження ресурсу (CPU, пам’ять, латентність сховища).

6) Симптом: UI показує вузол онлайн, але HA каже, що вузол офлайн

Корінь проблеми: Менеджерний (management) мережевий шлях працює, але шлях corosync ні (або навпаки). UI може вводити в оману, бо він не є джерелом істини членства.

Виправлення: Довіряйте інструментам corosync (corosync-cfgtool, corosync-quorumtool) і виправляйте corosync-шлях.

7) Симптом: «сховище недоступне», але Ceph/NFS «виглядає нормально» з одного вузла

Корінь проблеми: Часткова відмова: бекенд доступний, але занадто повільний, заблокований або таймаутиться; Proxmox позначає його як неактивний через провалені перевірки.

Виправлення: Перевірте стан бекенду з проблемного вузла конкретно. Для Ceph: перевірте клієнтську аутентифікацію і доступність моніторів. Для NFS: шукайте застарілі монтування і повідомлення в ядрових логах.

8) Симптом: HA відмовляється відновлювати після краху; ресурс застряг у «error»

Корінь проблеми: HA зафіксувала помилку і блокує петлі відновлення; або LRM на цільовому вузлі не працює; або ресурс досі «належить» десь через блокування/стан.

Виправлення: Читайте логи CRM/LRM, перевірте сервіси LRM, подивіться блокування і розгляньте контрольовану очистку ha-manager тільки після виправлення кореня проблеми.

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

Екстрений чек-лист: безпечно запустити один ресурс

1. Підтвердьте кворум: pvecm status має бути quorate. Якщо ні — спочатку відновіть більшість вузлів.
2. Підтвердьте стабільність членства: corosync-cfgtool -s має показувати активні кільця без помилок.
3. Підтвердьте стан /etc/pve: df -h /etc/pve покаже pmxcfs.
4. Прочитайте помилку HA: ha-manager status vm:ID і перевірте last_error.
5. Перевірте потрібне сховище на цільовому вузлі: pvesm status і валідуйте диск VM з qm config ID.
6. Перевірте блокування: qm config ID | grep '^lock:'.
7. Перегляньте історію завдань: читайте логи задач для VM і останніх операцій.
8. Лише потім: намагайтесь відновити через HA (переважно) або контрольований ручний запуск з вимкненим HA (тільки якщо ви розумієте наслідки).

Чек-лист стабільності: запобігання повторенню «не може запустити ресурс»

1. Зробіть мережу corosync нудною: виділений VLAN, узгоджений MTU, без втручання firewall, моніторинг втрат і затримок.
2. Перестаньте вважати двовузлові кластери HA: використовуйте пристрій кворуму або третій вузол для реального прийняття рішень.
3. Забезпечте симетрію сховища: якщо VM керується HA по вузлах, її сховище має бути доступне на цих вузлах, або обмежте HA-розміщення відповідно до реальності.
4. Стандартизуйте перевірки здоров’я сховища на кожному вузлі: не вважайте «працює на вузлі A» доказом для всіх.
5. Підтримуйте точну синхронізацію часу: єдиний NTP/chrony по всіх вузлах.
6. Опишіть очікування по fencing: навіть якщо Proxmox HA не робить зовнішнього управління живленням, ваш операційний рукопис має вказувати, як ви запобігаєте подвійним записам.
7. Проводьте навчання з відмов регулярно: не щоб вразити когось — а щоб знати, як виглядає «нормальна дивність» в логах.

Обережні рамки прийняття рішень (чого уникати під тиском)

• Уникайте: бездумного очищення блокувань. Робіть: переконайтеся, що підлягаюча задача дійсно завершилась.
• Уникайте: перезавантаження випадкових вузлів «щоб виправити HA». Робіть: спочатку ідентифікуйте, чи проблема в кворумі, сховищі чи мережі.
• Уникайте: зміни таймаутів corosync під час інциденту. Робіть: стабілізуйте шлях мережі; тонкі налаштування проводьте пізніше з даними.

FAQ

1) Чи означає «не може запустити ресурс» завжди проблеми з кворумом?

Ні. Кворум поширений, але недоступність сховища і блокування так само часті. Найшвидшу правду дають ha-manager status vm:ID і логи LRM на цільовому вузлі.

2) UI показує все зеленим. Чому HA все ще відмовляє?

UI відображає доступність plane-управління та частини стану кластера, але рішення HA залежать від членства corosync і перевірок сховища. Довіряйте інструментам corosync і логам HA більше, ніж оптимізму UI.

3) Чи можу я просто виконати qm start і ігнорувати HA?

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

4) Чому HA переймається статусом «inactive» сховища, якщо монтаж існує?

Тому що «змонтувано» не означає «працює нормально». NFS може бути змонтований, але зависати; iSCSI може бути залогінений, але таймаутитись; Ceph може бути підключений, але блокований. Proxmox позначає сховище неактивним, коли його перевірки провалюються або таймаутяться.

5) У чому різниця між CRM і LRM в Proxmox HA?

CRM координує рішення на рівні кластера (де має працювати ресурс). LRM виконує дії на вузлі (запуск/зупинка). «Не може запустити ресурс» часто означає, що CRM наказав, LRM спробував, і якась локальна залежність зазнала невдачі.

6) Якщо corosync нестабільний, чому мої VM все ще працюють?

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

7) Як швидко відрізнити відмову сховища від мережевого поділу?

Якщо кворум втрачається або кільця показують помилки — спочатку мережа/членство. Якщо кворум в порядку і HA каже «storage not available», запустіть pvesm status на цільовому вузлі і підтвердіть сховище для диску VM. Проблеми зі сховищем часто специфічні для вузла і не відображаються на здоровому сусідньому вузлі.

8) Чому двовузловий кластер відчувається таким крихким?

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

9) Що робити, якщо підозрюю, що стан менеджера HA застарів?

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

Висновок: наступні кроки, що реально запобігають повторенню

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

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

1. Складіть односторінковий рукопис, що починається з pvecm status, corosync-cfgtool -s і ha-manager status vm:ID. Зробіть його нудним і обов’язковим.
2. Аудитуйте ресурси HA на предмет симетрії сховища. Якщо VM може працювати лише на двох вузлах через реалії сховища — закодуйте це в HA-групах і обмеженнях.
3. Інструментуйте вашу мережу corosync: втрати, помилки, узгодженість MTU і насичення. Помилки HA часто починаються як мережеві проблеми, що чемно дочекались, щоб стати очевидними.
4. Практикуйте контрольований failover тоді, коли ніхто не панікує. Найкращий час вивчати поведінку HA — коли вона ще не принизила вас.