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

221 lines
12 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 | `<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`](../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)
Reference in New Issue View Git Blame Copy Permalink