ROMFASTSQL

romfast/ROMFASTSQL

Fork 0

Commit Graph

Author	SHA1	Message	Date
Marius	5e31d975df	docs(cluster): pveelite - cauza confirmata, resetul adaptorului USB LAN Nodul nu s-a oprit niciodata. La verificarea de azi avea uptime 17h46m, cu boot pornit la 27.08 ora 16:03:06 - a mers toata noaptea, fara retea. Jurnalul continua cu 58.454 de linii dupa 17:26:44, ceea ce inchide definitiv discutia alimentare vs retea. Vinovatul, din jurnalul kernel: Realtek RTL8156B (0bda:8156, driver r8152) pe usb 2-3. La 16:01:45 si la 17:26:41 adaptorul s-a resetat si a fost re-enumerat. Kernelul sterge interfata si o recreeaza - dar nimeni nu o readauga in vmbr0 si nu o ridica, pentru ca nu exista regula de hotplug. Din acel moment masina merge perfect si e invizibila in retea. Partea care merita retinuta e de ce la 16:01 si-a revenit si la 17:26 nu. La 16:01 LRM-ul HA era activ, deci watchdog-ul era armat: pierderea retelei a dus la pierderea quorumului, watchdog-mux a expirat la 16:02:39 si a resetat masina la 16:02:44 - repornire care a readus reteaua din intamplare, pentru ca la boot interfetele se ridica prin auto. La 17:26 fence-ul mutase deja vm:109 pe pvemini, LRM-ul era idle, watchdog-ul nearmat. Nimic nu a mai repornit masina. Singurul lucru care "repara" defectul asta era un efect secundar, nu un mecanism proiectat - pe un nod fara servicii HA, aceeasi defectiune devine permanenta si tacuta. Reparat cu ifreload -a de la consola, la 09:49. Restul verificarii e curat: ZFS ONLINE fara erori, cluster 3/3, SMART fara FAILED, replicarea se reia singura. Reparatia de fond intra in Tier 1: eno1 exista si e functional, doar ca nu are cablu (Link detected: no). Adaptorul USB e cauza a doua incidente pe nodul asta. Am scris si ordinea operatiilor, pentru ca inversata te lasa fara retea cu drum pana la nod. Prima rulare reala a scriptului a scos la iveala trei defecte ale lui, toate reparate aici: - tiparele de semnatura hardware prindeau linii normale de boot ("Registered thermal governor", "NMI watchdog: Enabled", "EDAC MC: Ver: 3.0.0") si produceau un verdict de defect hardware care contrazicea concluzia corecta din acelasi bilant. Strans tiparele si filtrat prin -p warning; verificat pe nod: 0 potriviri. - LRM idle era raportat ca "stare neclara". E starea normala a unui nod fara servicii HA - iar scriptul spune acum explicit ca idle inseamna watchdog nearmat, adica exact motivul pentru care caderea de la 17:26 nu s-a auto-reparat. - Tailscale era raportat [ok] desi e delogat: systemctl is-active zice active, dar tailscale status zice "Logged out". De aici si cele 27 de zile de offline. Consemnat si raspunsul la intrebarea cu magic packet, cu MAC-urile ambelor interfete, ca sa nu se reia: WoL nu ar fi ajutat oricum, masina nu era oprita. Dupa mutarea pe eno1 devine insa realmente utilizabil. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8	2026-08-28 09:55:10 +03:00
Marius	c67e7d8361	docs(cluster): pveelite are LAN pe USB - a doua ipoteza pentru caderea de ieri Intrebarea "nu-l putem trezi cu un magic packet?" a scos la iveala ceva ce schimba diagnosticul, nu doar raspunsul la ea. Pe WoL, pe scurt: nu se poate nici macar incerca. MAC-ul lui pveelite nu mai exista nicaieri - intrarea ARP a expirat pe pvemini (INCOMPLETE), pe pve1 (FAILED), in tabela statiei de admin si pe LXC-urile de pe LAN; nodurile au IP static, deci nu exista lease DHCP; in documentatie nu e consemnat. Raman tabela routerului sau citirea fizica de pe nod. Si chiar cu MAC-ul, placa de retea e pe USB, iar un dongle USB e nealimentat in soft-off, deci nu asculta dupa magic packet. Partea care conteaza insa e alta: pveelite ARE placa de retea pe USB, si deconectarea ei e modul de defectare deja documentat al acestui nod - incidentul 2026-04-20 a pornit exact de la un USB LAN disconnect, motiv pentru care tokenul corosync a fost marit la 10 s. Un nod care si-a pierdut adaptorul de retea arata din exterior identic cu unul oprit: fara ping, fara ARP, fara corosync, fara SSH. Toate observatiile din incident sunt compatibile cu ambele scenarii, iar eu scrisesem doar unul. Pentru 16:01 dovezile inclina in continuare spre repornire - curba de memorie din RRD se reseteaza (2,43 GB la 16:00 -> 2,10 GB la 16:30, sub valoarea de dupa boot) si NFS-ul se reataseaza. Pentru 17:26 nu exista niciun indiciu echivalent: nodul pur si simplu a incetat sa fie vizibil, ceea ce o deconectare USB explica la fel de bine ca o pierdere de alimentare. Am slabit corespunzator formularile din TL;DR si din cronologie, unde afirmasem repornirea ca fapt. Consecinta practica, pusa in document ca avertisment inainte de orice altceva: prima observatie la fata locului e daca masina merge - ventilatoare, LED-uri, imagine. Daca e pornita, nu a fost o cadere de alimentare, jurnalul e intact si reparatia e la dongle, cablu sau portul de switch. Nu apasa butonul de power inainte sa te uiti. In script, pasul 1 nu mai citeste boot-urile dupa index - indexurile difera intre cele doua scenarii si ar fi dus la concluzii gresite. Acum taie jurnalul dupa ora si pune intai testul decisiv: exista intrari dupa 17:26:44? Daca da, masina a mers mai departe si a cazut doar reteaua, iar verdictul si remediile se schimba complet. Adaugat si un bloc de diagnostic pentru adaptorul USB (interfete, drivere, lsusb, deconectari si evenimente de link in jurnalul kernel). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8	2026-08-27 21:53:34 +03:00
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

Author

SHA1

Message

Date

Marius

5e31d975df

docs(cluster): pveelite - cauza confirmata, resetul adaptorului USB LAN

Nodul nu s-a oprit niciodata. La verificarea de azi avea uptime 17h46m, cu boot
pornit la 27.08 ora 16:03:06 - a mers toata noaptea, fara retea. Jurnalul
continua cu 58.454 de linii dupa 17:26:44, ceea ce inchide definitiv discutia
alimentare vs retea.

Vinovatul, din jurnalul kernel: Realtek RTL8156B (0bda:8156, driver r8152) pe
usb 2-3. La 16:01:45 si la 17:26:41 adaptorul s-a resetat si a fost re-enumerat.
Kernelul sterge interfata si o recreeaza - dar nimeni nu o readauga in vmbr0 si
nu o ridica, pentru ca nu exista regula de hotplug. Din acel moment masina merge
perfect si e invizibila in retea.

Partea care merita retinuta e de ce la 16:01 si-a revenit si la 17:26 nu. La
16:01 LRM-ul HA era activ, deci watchdog-ul era armat: pierderea retelei a dus la
pierderea quorumului, watchdog-mux a expirat la 16:02:39 si a resetat masina la
16:02:44 - repornire care a readus reteaua din intamplare, pentru ca la boot
interfetele se ridica prin auto. La 17:26 fence-ul mutase deja vm:109 pe pvemini,
LRM-ul era idle, watchdog-ul nearmat. Nimic nu a mai repornit masina. Singurul
lucru care "repara" defectul asta era un efect secundar, nu un mecanism proiectat
- pe un nod fara servicii HA, aceeasi defectiune devine permanenta si tacuta.

Reparat cu ifreload -a de la consola, la 09:49. Restul verificarii e curat: ZFS
ONLINE fara erori, cluster 3/3, SMART fara FAILED, replicarea se reia singura.

Reparatia de fond intra in Tier 1: eno1 exista si e functional, doar ca nu are
cablu (Link detected: no). Adaptorul USB e cauza a doua incidente pe nodul asta.
Am scris si ordinea operatiilor, pentru ca inversata te lasa fara retea cu drum
pana la nod.

Prima rulare reala a scriptului a scos la iveala trei defecte ale lui, toate
reparate aici:

- tiparele de semnatura hardware prindeau linii normale de boot ("Registered
  thermal governor", "NMI watchdog: Enabled", "EDAC MC: Ver: 3.0.0") si produceau
  un verdict de defect hardware care contrazicea concluzia corecta din acelasi
  bilant. Strans tiparele si filtrat prin -p warning; verificat pe nod: 0
  potriviri.
- LRM idle era raportat ca "stare neclara". E starea normala a unui nod fara
  servicii HA - iar scriptul spune acum explicit ca idle inseamna watchdog
  nearmat, adica exact motivul pentru care caderea de la 17:26 nu s-a auto-reparat.
- Tailscale era raportat [ok] desi e delogat: systemctl is-active zice active, dar
  tailscale status zice "Logged out". De aici si cele 27 de zile de offline.

Consemnat si raspunsul la intrebarea cu magic packet, cu MAC-urile ambelor
interfete, ca sa nu se reia: WoL nu ar fi ajutat oricum, masina nu era oprita.
Dupa mutarea pe eno1 devine insa realmente utilizabil.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8

2026-08-28 09:55:10 +03:00

Marius

c67e7d8361

docs(cluster): pveelite are LAN pe USB - a doua ipoteza pentru caderea de ieri

Intrebarea "nu-l putem trezi cu un magic packet?" a scos la iveala ceva ce
schimba diagnosticul, nu doar raspunsul la ea.

Pe WoL, pe scurt: nu se poate nici macar incerca. MAC-ul lui pveelite nu mai
exista nicaieri - intrarea ARP a expirat pe pvemini (INCOMPLETE), pe pve1
(FAILED), in tabela statiei de admin si pe LXC-urile de pe LAN; nodurile au IP
static, deci nu exista lease DHCP; in documentatie nu e consemnat. Raman tabela
routerului sau citirea fizica de pe nod. Si chiar cu MAC-ul, placa de retea e pe
USB, iar un dongle USB e nealimentat in soft-off, deci nu asculta dupa magic
packet.

Partea care conteaza insa e alta: pveelite ARE placa de retea pe USB, si
deconectarea ei e modul de defectare deja documentat al acestui nod - incidentul
2026-04-20 a pornit exact de la un USB LAN disconnect, motiv pentru care tokenul
corosync a fost marit la 10 s. Un nod care si-a pierdut adaptorul de retea arata
din exterior identic cu unul oprit: fara ping, fara ARP, fara corosync, fara SSH.
Toate observatiile din incident sunt compatibile cu ambele scenarii, iar eu
scrisesem doar unul.

Pentru 16:01 dovezile inclina in continuare spre repornire - curba de memorie din
RRD se reseteaza (2,43 GB la 16:00 -> 2,10 GB la 16:30, sub valoarea de dupa boot)
si NFS-ul se reataseaza. Pentru 17:26 nu exista niciun indiciu echivalent: nodul
pur si simplu a incetat sa fie vizibil, ceea ce o deconectare USB explica la fel
de bine ca o pierdere de alimentare. Am slabit corespunzator formularile din TL;DR
si din cronologie, unde afirmasem repornirea ca fapt.

Consecinta practica, pusa in document ca avertisment inainte de orice altceva:
prima observatie la fata locului e daca masina merge - ventilatoare, LED-uri,
imagine. Daca e pornita, nu a fost o cadere de alimentare, jurnalul e intact si
reparatia e la dongle, cablu sau portul de switch. Nu apasa butonul de power
inainte sa te uiti.

In script, pasul 1 nu mai citeste boot-urile dupa index - indexurile difera intre
cele doua scenarii si ar fi dus la concluzii gresite. Acum taie jurnalul dupa ora
si pune intai testul decisiv: exista intrari dupa 17:26:44? Daca da, masina a mers
mai departe si a cazut doar reteaua, iar verdictul si remediile se schimba complet.
Adaugat si un bloc de diagnostic pentru adaptorul USB (interfete, drivere, lsusb,
deconectari si evenimente de link in jurnalul kernel).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8

2026-08-27 21:53:34 +03:00

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

3 Commits