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)