636d83b883bad998b0ef40cf6c1d8b9903cd1d4c
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
Description
No description provided
Languages
Python
29.2%
PLSQL
24.7%
PowerShell
22.6%
Shell
15.4%
Batchfile
3.7%
Other
4.4%