romfast/ROMFASTSQL
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
636d83b883bad998b0ef40cf6c1d8b9903cd1d4c
ROMFASTSQL/proxmox/cluster/incidents/2026-08-27-pveelite-down.md
Marius 636d83b883 docs(cluster): incident 2026-08-27 pveelite mort + verificarea de la revenire 
pveelite s-a resetat singur la 16:01 si a murit definitiv la 17:26, pe o masina
complet idle (CPU 0,4%, load 0,10, RAM 2,15 din 15,3 GB). E inaccesibil si la
nivel L2 - ip neigh raporteaza FAILED - deci diagnosticul nu se poate duce mai
departe de la distanta.

Ce exclud dovezile: nu e resurse (RRD-ul de pe pvemini arata nodul inactiv), nu e
retea (niciun flap knet in 7 zile in afara zilei de azi, pve1 si pvemini stabile
de la 13:20), nu e UPS (OL, baterie 100%, input 239,6 V), nu e comanda de la noi
(singura rulare ups-shutdown de azi a fost dry-run, iar in jurnal nu exista niciun
poweroff catre .202). Ramane alimentarea sau hardware-ul.

Oprirea de la pranz a fost planificata, nu o cadere: qmshutdown:303 de la root@pam
la 12:25, statia de admin conectata la 12:28:59, poweroff curat pe toate trei la
12:33-12:36. pveelite a revenit normal la 13:20 si a mers 2h40m. Cedarea vine deci
dupa ciclul de oprire-pornire, ceea ce intareste ipoteza de alimentare.

Impactul pe productie e zero - pe nod nu era decat CT 301, care e template oprit,
iar vm:109 era oprit si a fost recuperat curat pe pvemini de fence la 17:28.
Replicarea catre pve1 e intacta si la zi (RPO 15 min respectat). Ce ramane in
aer: clusterul sta pe 2 voturi din 3, fara marja, si replicarea catre pveelite e
oprita pe toate cele 9 job-uri.

Trei lucruri au mers pentru ca au fost reparate dupa aprilie: fence-ul a recuperat
un singur serviciu si i-a respectat starea oprita, consolidarea sarcinii pe
pvemini/pve1 a facut caderea un non-eveniment, iar alerta a plecat pe email la
17:31.

Scriptul de verificare se ruleaza cand nodul e pornit fizic la loc. Ordinea nu e
intamplatoare - intai de ce a cazut, din jurnalul boot-urilor care abia acum devin
citibile, si abia apoi starea. Daca jurnalul e tacut inainte de ambele caderi,
scriptul NU declara nodul sanatos: da verdict de alimentare/hardware si cere
testarea sursei si a memoriei inainte ca pveelite sa fie iar tinta de failover.
Exact capcana din 2026-04-20, unde pvemini a repornit singur si parea in regula.

Verificat pe clusterul viu: cei trei parseri (voturi quorum, job-uri de replicare
esuate, stare LRM) intorc 2, 9 si "LRM mort", adica starea reala de acum.

Doua lucruri colaterale, consemnate in document, nu rezolvate aici: tailscaled e
mort pe pveelite de 27 de zile, deci nu exista acces out-of-band, iar textul
alertei pveelite-down-alert.sh trimite la un export NFS care nu mai e in
storage.cfg.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
2026-08-27 21:38:35 +03:00

12 KiB
Raw Blame History

Incident 2026-08-27 — pveelite cade definitiv la 4 ore după repornirea planificată a clusterului

Severity: Medium (zero impact pe producție — nodul nu găzduia niciun serviciu viu — dar clusterul rămâne pe 2 voturi din 3, fără marjă de quorum, și replicarea către pveelite e oprită) Detected: 2026-08-27 17:31 EEST (alertă automată pveelite-down-alert.sh → email) Status: DESCHIS — nodul e inaccesibil, necesită intervenție fizică Author: Claude Code (mmarius28@gmail.com)

TL;DR — lanțul cauzal

  1. 12:25–12:36 — oprire planificată a întregului cluster, comandată din stația de admin (10.0.20.144). Guest-urile oprite ordonat prin API (qmshutdown:303 la 12:25 de la root@pam), apoi nodurile. Oprirea a fost curată pe toate trei — systemd-poweroff.service: Finished, Reached target poweroff.target. Tiparul e exact al lui cluster-shutdown.ps1.
  2. 13:20:26–13:20:41 — toate trei nodurile pornesc la loc și reformează clusterul complet (membership 1.1c7, Members: 1 2 3). pveelite a revenit normal și a funcționat 2h40m.
  3. 16:01:48 → 16:03:17 — pveelite dispare din corosync și revine după ~89 de secunde. Nu a fost un flap de rețea: la 16:03:10 se reatașează ca client NFS (rpc.mountd: v4.2 client attached from 10.0.20.202:986), iar mount-ul NFS se reface doar la boot. Nodul s-a resetat singur. Nimeni nu i-a comandat asta.
  4. 17:15:01 — ultimul semn de viață: cronul de pe pveelite se conectează prin SSH la pvemini, ca la fiecare 15 minute.
  5. 17:26:44 — pveelite pică definitiv. Nu a mai revenit.
  6. 17:27:03 — corosync formează membership 1.1d8 fără nodul 3. Quorum păstrat (2/3).
  7. 17:28:04–17:28:23 — HA fence executat corect: lock obținut, vm:109 recuperat de pe nodul fenced pe pvemini și lăsat în starea în care era (stopped). Fără repornire nedorită, fără buclă OOM — spre deosebire de incidentul din 2026-04-20.
  8. 17:31 — alerta a plecat pe email, după cele 5 minute de prag din script. Lanțul de alertare a funcționat end-to-end.

Root cause: nedeterminabilă de la distanță — nodul e mort la nivel L2. Dovezile disponibile exclud însă cauzele software și indică defect hardware / de alimentare pe cutia pveelite, cel mai probabil declanșat de ciclul de oprire-pornire de la prânz:

  • Nu e resurse: RRD-ul de pe pvemini arată nodul complet inactiv în ora dinaintea căderii — CPU 0,4 %, load 0,10, RAM 2,15 din 15,3 GB, rootfs 18,5 GB constant. Nu e repetarea scenariului OOM din aprilie.
  • Nu e rețea: în ultimele 7 zile nu există niciun flap knet în afara zilei de azi. pve1 ↔ pvemini sunt stabile continuu de la 13:20.
  • Nu e UPS: ups.status: OL, baterie 100 %, input 239,6 V, load 8 %. Ultimul test de autonomie de azi a fost pe UPS-ul serverului 36, nu pe cel al clusterului.
  • Nu e comandă de la noi: singura rulare ups-shutdown de azi (14:12) a fost în dry-run, iar în jurnal nu există niciun poweroff/reboot trimis către 10.0.20.202.
  • Tiparul e de hardware: reset spontan la 16:01, apoi moarte definitivă 85 de minute mai târziu, pe o mașină idle. Semnătură clasică de PSU / RAM / termic.

Cronologie (EEST)

Ora Nod Eveniment Sursa
12:25:02 pvemini <root@pam> qmshutdown:303 — începe oprirea ordonată a guest-urilor pvedaemon
12:28:59 pvemini Stația de admin (10.0.20.144) se conectează prin SSH sshd
12:33:56 pvemini Members left: 3 — pveelite se oprește primul corosync
12:35:58 pvemini Members left: 1 — pve1 se oprește corosync
12:36:58 pvemini Finished systemd-poweroff.service — oprire curată, ultimul nod journalctl -b -1
13:20:24 pve1 boot uptime -s
13:20:26 pvemini boot uptime -s
13:20:41 — Cluster complet: membership 1.1c7, Members[3]: 1 2 3 corosync
14:12:26 pvemini ups-shutdown orchestrat — DRY-RUN, fără efect. Status OL, baterie 100 % /var/log/ups-shutdown.log
16:00:02 pvemini cron de pe pveelite, SSH normal sshd
16:01:48 pvemini link: host: 3 link: 0 is down — pveelite dispare corosync
16:02:07 pvemini Members left: 3, Failed to receive the leave message corosync
16:03:10 pvemini rpc.mountd: v4.2 client attached from 10.0.20.202 — remount NFS ⇒ pveelite a bootat rpc.mountd
16:03:17 pvemini Members joined: 3 — pveelite revine în cluster corosync
16:15 / 16:30 / 16:45 / 17:00 pvemini cronurile de pe pveelite rulează normal sshd
17:15:01 pvemini ultimul semn de viață al lui pveelite sshd
17:26:35 — ultimul timestamp LRM pveelite ha-manager status
17:26:44 pvemini link: host: 3 link: 0 is down — cădere definitivă corosync
17:26:48 pvemini Token has not been received in 7987 ms corosync
17:27:03 pvemini Membership 1.1d8, Members[2]: 1 2. Quorum păstrat corosync
17:27:13 pvemini node 'pveelite': online => unknown pve-ha-crm
17:28:04 pvemini node 'pveelite': unknown => fence; vm:109 → fence pve-ha-crm
17:28:13 pvemini Lock de fence obținut; vm:109 recuperat pe pvemini, recovery → request_stop pve-ha-crm
17:28:23 pvemini vm:109 → stopped. Recovery încheiat curat pve-ha-crm
17:31 pvemini Alertă email trimisă (prag de 5 minute atins) /var/run/pveelite-down-alerted
21:22 — Verificare: ping 100 % loss, ip neigh → FAILED, nod inaccesibil de 4 ore investigație

Starea la momentul investigației (21:22)

Cluster

Expected votes: 3 | Total votes: 2 | Quorum: 2 | Quorate: Yes
Members: 0x1 10.0.20.200 (pve1), 0x2 10.0.20.201 (pvemini, local)
/etc/pve/.members: pveelite online: 0

Clusterul funcționează, dar fără nicio marjă. Dacă mai cade un nod, se pierde quorumul și /etc/pve devine read-only pe tot clusterul — toate guest-urile îngheață.

Ce rula pe pveelite

Nimic viu. Singurul guest asignat nodului era CT 301 docker-portainer-template (template: 1, oprit). vm:109 era înregistrat în HA pe pveelite, dar în starea stopped, și a fost recuperat pe pvemini la 17:28. Niciun serviciu HA activ nu era pe pveelite.

Motivul pentru care asta a mers bine: după incidentul din aprilie, sarcina a fost consolidată pe pvemini/pve1, iar pveelite a rămas doar țintă de replicare + rezervă de failover.

Replicare

Job Țintă Ultima sincronizare Stare
100-1, 102-1, 103-1, 104-1 pveelite 2026-08-26 ~21:05–21:21 ✗ eșec, FailCount 1
106-1 pveelite 2026-08-27 16:00:03 ✗ eșec, FailCount 1
108-1, 171-1, 201-1 pveelite 2026-08-27 17:15 ✗ eșec, FailCount 1
109-1 pveelite niciodată ✗ eșec, FailCount 1
toate *-0 pve1 2026-08-27 20:00–21:20 ✓ OK

Eroarea e uniformă: ssh ... root@10.0.20.202 -- pvesr prepare-local-job ... failed: exit code 255 (SSH nu poate deschide conexiunea).

Copia DR pe pve1 e intactă și la zi — CT 108 Oracle și VM 201 replicate la 21:15, RPO 15 min respectat. Redundanța a scăzut de la 2 copii la 1, nu la 0.

Fără acces out-of-band

tailscale status → pveelite ... offline, last seen 27d ago. Nu doar că nodul e mort, dar tailscaled nu mai rulează pe el de 27 de zile — deci nici dacă ar fi doar o problemă de rețea LAN, tot n-am putea ajunge la el. Singura cale rămasă e fizică.

Colateral observat

  • local-zfs pe pvemini la 92,06 % (69 GB liberi din 875 GB). Nu e cauza incidentului, dar e o problemă separată care merită tratată.
  • Scriptul /opt/scripts/pveelite-down-alert.sh descrie în corpul alertei un export NFS 10.0.20.202:/mnt/pve/oracle-backups care nu mai există în storage.cfg. Textul alertei e depășit și induce în eroare la citire.

Ce a funcționat bine

Merită consemnat, pentru că sunt exact lucrurile reparate după aprilie:

  1. Fence-ul a mers curat. Lock obținut, un singur serviciu recuperat, starea stopped respectată. Fără repornire nedorită, fără cascadă.
  2. Consolidarea sarcinii pe pvemini/pve1 a făcut incidentul un non-eveniment pentru producție. În aprilie, căderea unui nod muta 4 containere pe o mașină de 16 GB și declanșa 3 ore de buclă OOM.
  3. Alertarea a funcționat — prag de 5 minute, email livrat la 17:31 prin mail.romfast.ro, coadă goală, status=sent.
  4. Replicarea către pve1 nu a fost afectată — a doua țintă și-a făcut treaba.

Ce urmează — verificare la repornirea nodului

Nodul se pornește fizic. Imediat după ce revine, se rulează verifica-pveelite.ps1 din stația de admin:

.\proxmox\cluster\scripts\verifica-pveelite.ps1

Scriptul acoperă, în ordine:

  1. De ce s-a resetat la 16:01 și de ce a murit la 17:26 — journalctl -b -1 și -b -2 pentru erori, mcelog/MCE în dmesg, evenimente termice, Hardware Error. Dacă log-urile sunt tăcute (ca la pvemini în aprilie), concluzia e alimentare/hardware, nu software — și atunci nodul nu mai e de încredere ca țintă de failover.
  2. Integritatea ZFS — zpool status -v după două opriri necurate; se așteaptă eventual un resilver automat, ca în aprilie.
  3. Revenirea în cluster — quorum 3/3, pvecm status, /etc/pve/.members.
  4. Repornirea replicării — pvesr status, FailCount înapoi la 0, toate cele 9 job-uri recuperate. Nu necesită intervenție manuală; se reiau singure.
  5. HA — LRM pveelite active, nu dead.
  6. SMART pe discuri — temperaturi și erori, dat fiind precedentul Kingston.
  7. Tailscale — repornit și Online, ca să existe acces out-of-band data viitoare.

Plan de prevenție

🔴 Tier 1 — la repornirea nodului

1. Tailscale pe pveelite Mort de 27 de zile. Fără el, orice incident viitor pe nodul ăsta cere din nou deplasare fizică.

ssh root@10.0.20.202 "systemctl enable --now tailscaled && tailscale up && tailscale status"

2. Verdictul hardware, scris explicit. Dacă journalctl -b -1 nu conține nimic înainte de 17:26 (tăcere completă, ca la pvemini pe 2026-04-20), atunci cauza e hardware și nodul trebuie tratat ca nesigur până la înlocuirea sursei / testare RAM. Nu se lasă concluzia „a mers, deci e bine".

3. Textul alertei — scos exportul NFS inexistent. /opt/scripts/pveelite-down-alert.sh menționează 10.0.20.202:/mnt/pve/oracle-backups, care nu mai e în storage.cfg. Cine citește alerta la 3 noaptea o ia pe o pistă falsă.

🟡 Tier 2 — de decis după verdictul hardware

4. Ce se întâmplă cu marja de quorum. Cât timp pveelite e nesigur, clusterul funcționează pe 2 din 3 voturi. Nu se umblă la expected votes cât timp e quorate — dar dacă nodul urmează să stea oprit zile întregi, merită decis conștient dacă rămâne în cluster sau se scoate temporar.

5. local-zfs pe pvemini la 92 %. Separat de incident, dar pe același nod pe care stă acum toată producția.

Referințe