# 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`](../scripts/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](2026-04-20-cluster-outage.md). 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 | ` 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`](../scripts/verifica-pveelite.ps1) din stația de admin: ```powershell .\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ă. ```bash 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 - [Incident 2026-04-20 — cluster outage pvemini + pveelite](2026-04-20-cluster-outage.md) — precedentul de „nod care moare fără niciun log" - [Incident 2026-04-30 — Kingston backup SSD hang](2026-04-30-pvemini-backup-ssd-hang.md) - [Oprire planificată a clusterului](../docs/oprire-planificata-cluster.md) - [Failover și replicare](../failover/README.md) - Script de verificare: [`../scripts/verifica-pveelite.ps1`](../scripts/verifica-pveelite.ps1)