feat(cluster): corosync ring1 pe insula, test de repornire cu WoL, fixuri in scripturi

Ring1 aplicat si verificat pe cluster live: config_version 17, ring1_addr pe
10.10.10.20x la fiecare nod, interface{linknumber:1}. Validat cu `corosync -t`
inainte de instalare. Testat prin oprirea reala a lui ring0 pe pveelite: link0
disconnected, link1 connected, cvorum 3/3 neatins - exact scenariul care pe
27 august a lasat nodul mort 16 ore.

Test de repornire completa a clusterului, cu Wake-on-LAN (trezire in ~15s).
Insula a urcat singura pe toate trei nodurile; ipoteza enumerarii tarzii a
USB-ului nu s-a materializat. Unealta noua: wake-cluster.ps1.

Testul a scos la iveala o linie ramasa in /etc/fstab pe pve1 si pveelite, care
monta storage-ul NFS de pe IP-ul de productie inaintea lui pvestatd. Backup-ul
trecea tacut pe reteaua gresita, cu storage.cfg corect. cluster-startup verifica
acum asta automat, impreuna cu IP-urile de insula si conectivitatea reala.

Patru bug-uri gasite prin rulare pe cluster live:

- sonda Oracle nu avea timeout: un sqlplus agatat pe o instanta in pornire a
  blocat cluster-startup 14 minute, fara mesaj, cu propriul prag de 600s
  nefolosit, fiindca bucla n-a apucat o iteratie;
- `bash -c` in loc de `bash -lc`: sqlplus lipsea din PATH, deci baza nu se
  oprea si containerul s-ar fi inchis peste ea;
- PowerShell 5.1 pierde ghilimelele duble catre exe-uri native, deci comanda
  ajungea rupta pe nod - trecut pe trimitere codificata base64;
- backup-ul de crontab si fisierul de stare se rescriau la o a doua rulare,
  lasand monitorizarea oprita permanent si lista de repornit goala.

Documentatia de oprire planificata pornea de la o afirmatie devenita falsa
("nu exista datacenter.cfg") si de la o comanda care ar fi adaugat o a doua
linie `ha:`. Actualizata, impreuna cu inventarul de guest-uri (VM 304 lipsea
din toate listele de ordine si cadea in maturarea de dupa Oracle).

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

proxmox/cluster/docs/switch-2.5g-dedicat-noduri.md

@@ -4,8 +4,12 @@
 **Autor:** Claude Code (mmarius28@gmail.com)
 **Status: TERMINAT pe 2026-08-29.** Rețeaua dedicată de cluster `10.10.10.0/24` e activă pe toate
 3 nodurile, `vmbr0` a fost mutat pe interfețele onboard, uplink-ul dintre switch-uri a fost scos,
-iar replicarea și backup-ul NFS trec verificat pe insulă. Singurele lucruri rămase sunt
-opționale — vezi „Ce a rămas de făcut".
+iar replicarea și backup-ul NFS trec verificat pe insulă.
+
+**Completat în seara aceleiași zile:** al doilea inel corosync (ring1) pe insulă, verificat prin
+oprirea reală a lui ring0; testul de repornire completă a clusterului, cu Wake-on-LAN. Testul a
+scos la iveală o linie rămasă în `/etc/fstab` care fixa tăcut backup-ul NFS pe rețeaua de
+producție. Toate trei sunt descrise mai jos. Singurul lucru rămas e opțional (MTU 9000).
 
 ---
 
@@ -278,13 +282,42 @@ fiecare pas: link 2500 Mbps, ping pe toată insula, **262 / 272 MB/s**, job real
 
 Opționale, în ordinea valorii:
 
-1. **corosync ring1** pe `10.10.10.0/24` — vezi mai jos, cere fereastră dedicată.
+1. ~~**corosync ring1** pe `10.10.10.0/24`~~ — **APLICAT pe 2026-08-29 seara**, vezi mai jos.
 2. **MTU 9000** pe segmentul dedicat — de testat, nu se știe dacă switch-ul suportă.
-3. **Test la reboot.** Configurația nu a fost validată printr-o repornire. Dongle-urile USB au
-   acum `auto` în loc să fie porturi de punte; dacă la boot USB-ul se enumeră târziu, interfața
-   de insulă poate rămâne neconfigurată. Chiar și atunci nodul pornește normal pe producție și
-   doar replicarea are de suferit — invers față de cum era înainte, când o problemă pe dongle
-   lua nodul offline complet. De verificat la următoarea repornire planificată.
+3. ~~**Test la reboot.**~~ — **FĂCUT pe 2026-08-29 seara**, vezi mai jos.
+
+### Test la repornire — făcut pe 2026-08-29, ipoteza infirmată
+
+Clusterul a fost oprit complet (toate 3 nodurile) și pornit înapoi. **Insula a urcat singură pe
+toate trei nodurile**, fără intervenție: enumerarea târzie a USB-ului nu s-a produs. Pe pve1
+s-a declanșat în plus și regula udev `usb-lan-hotplug@` la boot (20:27:33, terminată cu succes),
+care oricum ar fi reparat situația; pe pveelite a fost suficientă strofa `auto`.
+
+**Wake-on-LAN merge pe toate trei nodurile** — nodurile oprite au fost trezite cu magic packet
+de pe stația de admin, timp de răspuns ~15 secunde. E câștigul mutării lui `vmbr0` pe interfețele
+onboard: dongle-urile USB nu suportă WoL. Unealta: `../scripts/wake-cluster.ps1` (MAC-urile de
+producție sunt în ea). `Wake-on: g` era deja armat pe toate trei, iar BIOS-urile nu taie
+alimentarea plăcii în S5.
+
+### Ce a găsit testul: o linie rămasă în `/etc/fstab`
+
+Repornirea a scos la iveală o deriva tăcută pe **pve1 și pveelite**:
+
+```
+10.0.20.201:/mnt/backup /mnt/pve/backup-pvemini nfs4 defaults,_netdev 0 0
+```
+
+Montarea NFS a storage-ului PVE e treaba lui `pvestatd`, din `/etc/pve/storage.cfg` (unde
+serverul e corect, `10.10.10.201`). Linia din fstab o lua însă înainte la boot, ocupa punctul
+de montare, iar PVE o lăsa așa. Rezultatul: **tot traficul de backup trecea pe rețeaua de
+producție**, cu `storage.cfg` arătând perfect corect.
+
+Remontarea manuală făcută pe 29 august a corectat simptomul, dar nu și cauza — starea bună a
+supraviețuit exact până la prima repornire. Liniile au fost comentate pe ambele noduri
+(backup: `/root/fstab.bak-2026-08-29`), montările refăcute și verificate:
+`clientaddr=10.10.10.200` / `10.10.10.202`, scriibile.
+
+`cluster-startup` verifică acum asta automat la fiecare pornire.
 
 **De reținut:** `vmbr0` și-a schimbat MAC-ul pe toate 3 nodurile (a preluat MAC-ul noii
 interfețe). Dacă apar reguli pe router legate de MAC, acolo e cauza.
@@ -293,7 +326,7 @@ interfețe). Dacă apar reguli pe router legate de MAC, acolo e cauza.
 
 ## Îmbunătățiri posibile, în ordinea impactului
 
-### 1. Al doilea inel corosync (link1) pe switch-ul nou — cel mai valoros pas următor
+### 1. Al doilea inel corosync (link1) pe switch-ul nou — APLICAT pe 2026-08-29
 
 Cluster-ul are azi un singur inel corosync (`linknumber: 0`, peste `vmbr0`/IP-ul principal —
 vezi `/etc/pve/corosync.conf`). Când adaptorul USB al lui pveelite s-a resetat (aprilie și
@@ -305,14 +338,49 @@ inclusiv pe pve1 dacă i s-ar întâmpla la fel.
 verificate. Ring0 stă acum pe interfețele onboard (mai robuste), iar ring1 pe insulă ar acoperi
 și cazul în care dongle-ul USB sau portul din switch cedează.
 
+#### Cum s-a aplicat
+
+Fereastra: guest-urile oprite cu `cluster-shutdown.ps1 -NoNodes`, care lasă exact starea
+necesară — toate resursele HA în `stopped`, watchdog-ul dezarmat, dar clusterul **pornit și
+cvorat**, fiindcă `corosync.conf` stă pe pmxcfs și fără cvorum devine read-only.
+
 ```bash
-pvecm status   # verifică starea curentă înainte de orice modificare
-# adăugare link1 se face editând /etc/pve/corosync.conf, incrementând config_version,
-# adăugând ring1_addr = 10.10.10.20x la fiecare nod + interface { linknumber: 1 } în totem
+# backup pe FIECARE nod, si copia din /etc/pve, si cea locala pe care o citeste corosync
+cp /etc/pve/corosync.conf   /root/corosync.conf.bak-2026-08-29
+cp /etc/corosync/corosync.conf /root/corosync.local.bak-2026-08-29
+
+# validare INAINTE de instalare - corosync stie sa-si testeze propriul fisier
+COROSYNC_MAIN_CONFIG_FILE=/root/corosync.new.conf corosync -t   # exit 0 = sintaxa buna
+
+cp /root/corosync.new.conf /etc/pve/corosync.conf.new
+mv /etc/pve/corosync.conf.new /etc/pve/corosync.conf            # pmxcfs propaga singur
 ```
 
-**Neaplicat** — schimbarea corosync.conf e sensibilă (poate rupe cvorumul dacă sintaxa greșește)
-și merită o fereastră dedicată.
+Modificările: `ring1_addr: 10.10.10.20x` la fiecare nod, un al doilea bloc
+`interface { linknumber: 1 }` în `totem`, `config_version` 16 → 17. `link_mode` era deja
+`passive`, potrivit pentru două linkuri. Propagarea pe toate 3 nodurile a durat sub 12 secunde.
+
+#### Verificat prin oprirea reală a lui ring0
+
+Nu doar configurat — **testat**. Cu `eno1` scos administrativ pe pveelite (plasă de siguranță:
+`ifreload -a` programat la 120s), corosync a arătat de pe pvemini:
+
+```
+LINK ID 0  nodeid 3: disconnected
+LINK ID 1  nodeid 3: connected
+Quorate: Yes, Total votes: 3
+```
+
+Exact situația din 27 august, când pveelite a fost declarat mort 16 ore. Acum clusterul nici
+nu clipește. Restaurarea s-a făcut prin **calea out-of-band de pe insulă**
+(`ssh` de pe pvemini către `10.10.10.202`), care a funcționat cu nodul invizibil pe producție.
+
+#### Ce NU rezolvă ring1 — de reținut
+
+În timpul testului, **pveelite a apărut gri/indisponibil în GUI-ul Proxmox**, deși cvorumul era
+intact. E corect: GUI-ul nu se uită la corosync, ci vorbește prin API pe `8006`, peste IP-ul de
+management din `10.0.20.x`. Ring1 protejează **cvorumul, pmxcfs și HA** — nu accesul de
+management. Pentru management out-of-band există SSH pe insulă, de pe un nod pe altul.
 
 ### 2, 3 și 4 — aplicate pe 2026-08-29
 
@@ -327,9 +395,9 @@ pe 1G nu costă nimic pe pve1/pveelite.
 
 ## Ce NU s-a schimbat
 
-- `/etc/pve/corosync.conf` — **neatins.** Ring0 folosește în continuare IP-urile `10.0.20.20x`,
-  care acum stau pe interfețele onboard — deci corosync a câștigat robustețe fără nicio
-  modificare de configurație.
+- `/etc/pve/corosync.conf` — neatins la mutarea rețelei; **modificat seara aceleiași zile**,
+  pentru ring1 (`config_version: 17`) — vezi mai sus. Ring0 folosește în continuare IP-urile
+  `10.0.20.20x`, care acum stau pe interfețele onboard.
 - Cablurile nodurilor — **niciunul mutat de scripturi.** Toate mutările fizice au fost făcute
   manual de utilizator (routerul pe switch 2, dongle-ul lui pveelite pe p4, al lui pve1 pe p3).
 - Cage-urile SFP+ ale plăcii X710 de pe pvemini — rămân goale, placa nefolosită. La verificări,