romfast/ROMFASTSQL
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Marius
2026-08-29 21:13:34 +03:00
parent fd2105d1f9
commit d7b4007af8
10 changed files with 801 additions and 113 deletions
Download Patch File Download Diff File Expand all files Collapse all files

159
proxmox/cluster/docs/oprire-planificata-cluster.md
View File

@@ -6,7 +6,15 @@ relocheze resursele** și **fără ca watchdog-ul să reseteze hard vreun nod**.
Se aplică oricărei opriri planificate a întregului cluster: lucrări electrice,
mutare rack, mentenanță UPS, intervenții la switch.
**Autor:** Claude Code · **Ultima verificare pe cluster live:** 2026-08-27
**Autor:** Claude Code · **Ultima verificare pe cluster live:** 2026-08-29
> **Atenție, s-a schimbat ceva important pe 2026-08-29.** Clusterul are acum o rețea
> dedicată, `10.10.10.0/24` („insula"), pe un switch separat — vezi
> [switch 2.5G dedicat nodurilor](switch-2.5g-dedicat-noduri.md). De ea atârnă
> **toată replicarea ZFS** (`migration: network=10.10.10.0/24` în `datacenter.cfg`)
> și storage-ul NFS `backup-pvemini-nfs` (server `10.10.10.201`). Pe pve1 și
> pveelite IP-ul de insulă stă pe **dongle-ul USB**, deci la revenire trebuie
> verificat că a urcat — vezi [Repornirea, pasul 3](#repornirea).
---
@@ -24,11 +32,18 @@ cd E:\proiecte\ROMFASTSQL\proxmox\cluster\scripts
.\cluster-shutdown.ps1 -DryRun # arată exact ce ar face, nu atinge nimic
.\cluster-shutdown.ps1 # oprire completă, cu confirmări
# ... după revenirea curentului, cu nodurile pornite fizic ...
# ... după revenirea curentului ...
.\wake-cluster.ps1 # trezește nodurile prin Wake-on-LAN
.\cluster-startup.ps1 # repornire completă
```
**Wake-on-LAN merge pe toate trei nodurile** — verificat pe 2026-08-29, trezire în ~15 secunde.
E posibil abia de la mutarea lui `vmbr0` pe interfețele onboard: dongle-urile USB nu suportă WoL
și pierd alimentarea la oprire. Dacă lucrarea e la rețeaua electrică și nodurile sunt oprite
de tine, `wake-cluster.ps1` te scutește de drumul până la ele. Stația de admin trebuie să fie
pe același segment L2 (`10.0.20.0/24`) — magic packet-ul e broadcast, nu trece prin router.
Cere doar clientul OpenSSH din Windows (`C:\Windows\System32\OpenSSH\ssh.exe`),
deja prezent, și cheia SSH pentru root pe noduri. Testate pe PowerShell 5.1.
@@ -57,13 +72,15 @@ necesar și cum se face manual din GUI, dacă preferi.
## TL;DR (procedura manuală)
1. **Datacenter → Options → HA Settings → Shutdown Policy = `Freeze`** ← fără asta, HA mută resursele
1. **Shutdown Policy = `Freeze`** ← fără asta, HA mută resursele. Din 2026-08-29 e deja setat permanent — doar verifică (Pas 0), nu adăuga o linie nouă în `datacenter.cfg`
2. Dezactivează cron-urile de alertă (`pvemini-down-alert`, `vm109-watchdog`, `pveelite-down-alert`, `oom-alert`)
3. Oprește guest-urile manual — **Oracle CT 108 primul**, cu `shutdown immediate` în DB
4. `ha-manager status` → toate serviciile trebuie să fie `stopped`
5. Oprește nodurile: **pveelite → pve1 → pvemini**
La revenire: pornești **toate trei nodurile aproape simultan** (altfel nu ai quorum).
La revenire: pornești **toate trei nodurile aproape simultan** (altfel nu ai quorum),
apoi verifici că insula `10.10.10.0/24` a urcat pe pve1 și pveelite **înainte** de a
porni guest-urile.
---
@@ -71,8 +88,8 @@ La revenire: pornești **toate trei nodurile aproape simultan** (altfel nu ai qu
### Capcana 1 — politica implicită de shutdown este `conditional`
Pe clusterul `romfast` **nu există** `/etc/pve/datacenter.cfg`, deci PVE folosește
default-ul `shutdown_policy=conditional`:
Fără o linie `ha:` în `/etc/pve/datacenter.cfg`, PVE folosește default-ul
`shutdown_policy=conditional`:
| Acțiune pe nod | Comportament HA cu `conditional` |
|----------------|----------------------------------|
@@ -84,6 +101,11 @@ VM 201 și restul resurselor HA pe pve1/pveelite — pe noduri care oricum urmea
să fie și ele oprite, cu 16 GB RAM pe pveelite și riscul din
[incidentul 2026-04-20](../incidents/2026-04-20-cluster-outage.md).
> **Din 2026-08-29 capcana asta e deja dezamorsată permanent.** Fișierul
> `/etc/pve/datacenter.cfg` **există** și conține `ha: shutdown_policy=freeze`.
> Pasul 0 de mai jos e, în mod normal, doar o verificare. Nu presupune că fișierul
> lipsește — mai conține și linia `migration:`, care nu trebuie pierdută.
### Capcana 2 — watchdog-ul se auto-fence la pierderea quorumului
Cu 3 noduri, quorum = 2. Dacă oprești două noduri și al treilea **încă are
@@ -106,14 +128,37 @@ inofensivă.
## Pas 0 — Shutdown Policy = Freeze
**GUI:** `Datacenter → Options → HA Settings → Edit → Shutdown Policy: Freeze`
**CLI (echivalent):**
De obicei **nu ai nimic de făcut aici** — politica e `freeze` din 2026-08-29.
Verifică întâi:
```bash
ssh root@10.0.20.201 "echo 'ha: shutdown_policy=freeze' >> /etc/pve/datacenter.cfg"
ssh root@10.0.20.201 "cat /etc/pve/datacenter.cfg"
```
Așteptat (ambele linii):
```
ha: shutdown_policy=freeze
migration: network=10.10.10.0/24,type=insecure
```
Dacă `shutdown_policy` **nu** e `freeze`, **nu adăuga o linie nouă cu `>>`** —
fișierul are deja o linie `ha:`, iar a doua e o duplicare. Comanda corectă
înlocuiește linia existentă și lasă `migration:` neatinsă:
```bash
ssh root@10.0.20.201 "cp /etc/pve/datacenter.cfg /root/datacenter.cfg.backup-mentenanta && \
sed -i '/^ha:/d' /etc/pve/datacenter.cfg && \
printf 'ha: shutdown_policy=freeze\n' >> /etc/pve/datacenter.cfg && \
cat /etc/pve/datacenter.cfg"
```
**GUI (echivalent):** `Datacenter → Options → HA Settings → Edit → Shutdown Policy: Freeze`
> **Nu șterge linia `migration:`.** Fără ea replicarea ZFS se întoarce tăcut pe
> rețeaua de producție — merge, dar pe altă cale decât cea proiectată, iar
> traficul de replicare ajunge peste producție.
`Freeze` = la oprirea nodului serviciile HA sunt înghețate, **nu relocate**;
repornesc pe același nod când nodul revine.
@@ -200,17 +245,18 @@ VM 201 (IIS) și CT 104 (flowise) folosesc baza din CT 108.
| # | Nod | Guest | În HA | Cum |
|---|-----|-------|-------|-----|
| 1 | pvemini | VM 303 Win11-Adina | Nu | Shutdown |
| 2 | pvemini | VM 302 oracle-test | Nu | Shutdown |
| 3 | pvemini | VM 201 roacentral | Da | Shutdown (guest agent) |
| 4 | pve1 | CT 101 minecraft | Da | Shutdown |
| 5 | pve1 | CT 110 moltbot | Da | Shutdown |
| 6 | pvemini | CT 104 flowise | Da | Shutdown |
| 7 | pvemini | CT 106 gitea | Da | Shutdown |
| 8 | pvemini | CT 103 dokploy | Da | Shutdown |
| 9 | pvemini | CT 102 docker.romfast.ro | Nu | Shutdown |
| 10 | pvemini | CT 100 portainer | Da | Shutdown |
| 11 | pvemini | CT 171 claude-agent | Da | Shutdown |
| 12 | pvemini | **CT 108 central-oracle** | Da | `shutdown immediate` în DB, apoi Shutdown CT |
| 2 | pvemini | VM 304 Win11-Marius | Nu | Shutdown |
| 3 | pvemini | VM 302 oracle-test | Nu | Shutdown |
| 4 | pvemini | VM 201 roacentral | Da | Shutdown (guest agent) |
| 5 | pve1 | CT 101 minecraft | Da | Shutdown |
| 6 | pve1 | CT 110 moltbot | Da | Shutdown |
| 7 | pvemini | CT 104 flowise | Da | Shutdown |
| 8 | pvemini | CT 106 gitea | Da | Shutdown |
| 9 | pvemini | CT 103 dokploy | Da | Shutdown |
| 10 | pvemini | CT 102 docker.romfast.ro | Nu | Shutdown |
| 11 | pvemini | CT 100 portainer | Da | Shutdown |
| 12 | pvemini | CT 171 claude-agent | Da | Shutdown |
| 13 | pvemini | **CT 108 central-oracle** | Da | `shutdown immediate` în DB, apoi Shutdown CT |
pveelite nu are nimic pornit în mod normal (CT 301 și VM 109 sunt `stopped`).
@@ -275,9 +321,10 @@ Așteaptă ca nodul să nu mai răspundă la ping înainte de a-l opri pe următ
## Repornirea
1. **Pornește toate trei nodurile aproximativ simultan.** Un singur nod pornit
nu are quorum → `/etc/pve` rămâne read-only → nu poți porni niciun guest și
nu poți modifica nimic în GUI.
1. **Pornește toate trei nodurile aproximativ simultan** — fizic, sau cu
`.\wake-cluster.ps1` (Wake-on-LAN, verificat pe 2026-08-29). Un singur nod
pornit nu are quorum → `/etc/pve` rămâne read-only → nu poți porni niciun guest
și nu poți modifica nimic în GUI.
2. Așteaptă quorum complet:
@@ -286,19 +333,56 @@ Așteaptă ca nodul să nu mai răspundă la ping înainte de a-l opri pe următ
ssh root@10.0.20.201 "ha-manager status"
```
3. **Pornește guest-urile în ordine inversă:** CT 108 Oracle întâi, apoi VM 201,
3. **Verifică rețeaua de cluster `10.10.10.0/24` — pasul cel mai ușor de uitat.**
Pe pve1 și pveelite IP-ul de insulă stă pe dongle-ul USB, adus la boot de un
`auto enx...` din `/etc/network/interfaces`. Dacă nucleul enumerează adaptorul
USB **după** ce `networking.service` a terminat, interfața rămâne fără IP.
Nodul pornește perfect normal pe producție — dar **replicarea ZFS și storage-ul
NFS `backup-pvemini` tac**, fără nicio alertă.
```bash
ssh root@10.0.20.200 "ip -br a | grep -E 'vmbr0|enx'" # 10.10.10.200 pe dongle
ssh root@10.0.20.202 "ip -br a | grep -E 'vmbr0|enx'" # 10.10.10.202 pe dongle
ssh root@10.0.20.201 "ip -br a | grep -E 'vmbr0|enp87s0'" # 10.10.10.201 pe enp87s0
ssh root@10.0.20.201 "ping -c1 -W2 10.10.10.200; ping -c1 -W2 10.10.10.202"
ssh root@10.0.20.200 "findmnt -no SOURCE /mnt/pve/backup-pvemini" # 10.10.10.201:/mnt/backup
```
Dacă un IP lipsește, reparația e `ifreload -a` pe nodul respectiv:
```bash
ssh root@10.0.20.202 "PATH=/usr/sbin:/sbin:/usr/bin:/bin ifreload -a"
```
pvemini are interfața de insulă onboard (Intel `enp87s0`) — el nu are problema asta.
**Testat pe 2026-08-29, la o oprire completă reală: insula a urcat singură pe
toate trei nodurile.** Ipoteza enumerării târzii nu s-a materializat. Pe pve1
s-a declanșat în plus și regula udev `usb-lan-hotplug@` la boot, care oricum ar
fi reparat-o. Verificarea rămâne totuși în procedură — un singur test reușit nu
exclude o cursă de sincronizare care depinde de temporizări.
**Ce a găsit totuși testul:** o linie rămasă în `/etc/fstab` pe pve1 și pveelite
monta storage-ul NFS de pe `10.0.20.201` (producție) înainte ca `pvestatd` să
apuce, deci backup-ul mergea tăcut pe rețeaua greșită, cu `storage.cfg` arătând
corect. Liniile au fost comentate (backup: `/root/fstab.bak-2026-08-29`).
Dacă vezi vreodată NFS-ul montat de pe alt server decât `10.10.10.201`, acolo
să te uiți întâi. `cluster-startup` verifică asta automat.
4. **Pornește guest-urile în ordine inversă:** CT 108 Oracle întâi, apoi VM 201,
apoi restul. Pornirea unui guest HA îi repune state-ul pe `started`.
4. Verifică Oracle:
5. Verifică Oracle:
```bash
ssh root@10.0.20.201 "pct exec 108 -- docker exec oracle-xe bash -lc \
\"printf 'select status from v\\\$instance;\nexit\n' | sqlplus -s / as sysdba\""
```
5. **Re-activează cron-urile** dezactivate la Pasul 1 și job-urile de backup.
6. **Re-activează cron-urile** dezactivate la Pasul 1 și job-urile de backup.
6. Verifică replicarea:
7. Verifică replicarea:
```bash
ssh root@10.0.20.201 "pvesr status"
@@ -306,7 +390,8 @@ Așteaptă ca nodul să nu mai răspundă la ping înainte de a-l opri pe următ
Job-urile `*/15` (108, 171, 201) au ratat rulări; recuperează la primul tick.
7. Decide ce faci cu Shutdown Policy — vezi recomandarea de la Pasul 0.
8. Decide ce faci cu Shutdown Policy — vezi recomandarea de la Pasul 0.
În mod normal rămâne `freeze`, deci nu ai ce face.
---
@@ -329,7 +414,7 @@ orchestrat care poate intra peste procedura de aici.
---
## Stare de referință a clusterului (2026-08-27)
## Stare de referință a clusterului (2026-08-29)
Resurse HA configurate — 10 în total:
@@ -346,16 +431,28 @@ Resurse HA configurate — 10 în total:
| vm:109 | pveelite | ha-prefer-pveelite | oracle-dr-windows (`stopped`) |
| vm:201 | pvemini | ha-prefer-pvemini | roacentral |
Guest-uri **în afara** HA: CT 102, CT 301, VM 302, VM 303, VM 310.
Guest-uri **în afara** HA: CT 102, CT 301, VM 302, VM 303, **VM 304**, VM 310.
`nofailback` este `1` doar pe `ha-prefer-pveelite`; celelalte două grupuri au
`nofailback 0`, deci resursele se întorc automat pe nodul preferat când acesta revine.
Rețea și storage de care depinde procedura, verificate pe 2026-08-29:
| Ce | Valoare |
|---|---|
| `datacenter.cfg` | `ha: shutdown_policy=freeze` + `migration: network=10.10.10.0/24,type=insecure` |
| insulă pve1 / pvemini / pveelite | `10.10.10.200` (USB) / `10.10.10.201` (`enp87s0`) / `10.10.10.202` (USB) |
| NFS `backup-pvemini-nfs` | server `10.10.10.201`, montat pe pve1 și pveelite |
| corosync | **două linkuri**: `LINK ID 0` pe `10.0.20.20x`, `LINK ID 1` pe `10.10.10.20x`, `config_version: 17` |
| Wake-on-LAN | merge pe toate 3 (`ethtool <if>` → `Wake-on: g`); unealta: `../scripts/wake-cluster.ps1` |
---
## Referințe
- [Switch 2.5G dedicat nodurilor — rețeaua `10.10.10.0/24`](switch-2.5g-dedicat-noduri.md)
- [Strategia de failover și HA](../failover/README.md)
- [Incident 2026-04-20 — cluster outage](../incidents/2026-04-20-cluster-outage.md)
- [Incident 2026-08-27 — pveelite fără rețea 16h (USB LAN reset)](../incidents/2026-08-27-pveelite-down.md)
- [Cluster README — SSH, storage, noduri](../README.md)
- [UPS](../ups/README.md)

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

@@ -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,