Replicarea, migrarea si backup-ul NFS trec acum pe o insula 10.10.10.0/24
(switch 1, fara gateway), iar vmbr0 a fost mutat de pe dongle-urile USB
Realtek pe placile Intel onboard.
Castigul nu e viteza. Masurat: replicarea mergea deja la 272 MB/s, adica
~95% din firul de 2.5G, iar criptarea SSH nu era limita. 10G e imposibil
cat timp pve1 si pveelite au doar dongle-uri USB de 2.5G si niciun slot
PCIe liber; placa X710 din pvemini e SFP+ cu cage-urile goale, iar switch-ul
are doar porturi RJ45. Replicarea ruleaza si strict secvential
(Replication.pm:138, un singur lock, fara fork), deci nici agregarea de
linkuri nu ar ajuta.
Castigul e ca IP-ul de cluster si corosync ring0 nu mai stau pe dongle-ul
USB care a lasat pveelite invizibil 16 ore pe 2026-08-27 - fara sa fie
nevoie de vreo modificare in corosync.conf, fiindca IP-urile au ramas
aceleasi. Plus izolarea replicarii de productie, WoL persistat pe onboard,
si o cale out-of-band catre noduri prin insula.
Aplicat si verificat: cvorum pe 3 pe tot parcursul, 262-273 MB/s pe insula,
job real de replicare confirmat cu numarare de octeti pe interfete
(4959 KB pe insula vs 1553 KB pe productie), NFS activ si scriibil.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RJFQZcA7uerXRaL1NrsXpS
Statia de admin e Windows si nu ruleaza .sh direct: `bash` din PATH e cel din
WSL, cu alt filesystem si alta configuratie de chei SSH. Adaug echivalentele
native PowerShell.
- cluster-shutdown.ps1 / cluster-startup.ps1, aceeasi logica si aceleasi
garantii ca variantele bash
- folosesc clientul OpenSSH din Windows, deja prezent in System32
- compatibile PowerShell 5.1: fara &&/||, fara ternar, fara ?., fara
-AsHashtable; ping prin System.Net.NetworkInformation.Ping, nu
Test-Connection (WMI, lent si des blocat)
- nu redirecteaza stderr-ul lui ssh: in 5.1 asta transforma fiecare linie
intr-un ErrorRecord si strica $LASTEXITCODE chiar cand comanda a reusit
- parsarea `pct list` / `qm list` se face in PowerShell, nu prin awk remote,
ca sa nu se incurce interpolarea $1/$2 din stringurile PowerShell
- scriu acelasi format de fisier de stare ca variantele bash, deci poti opri
cu una si porni cu cealalta
Ambele testate cu -DryRun pe clusterul live, rezultat identic cu bash.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
cluster-shutdown.sh / cluster-startup.sh — automatizeaza procedura din
docs/oprire-planificata-cluster.md. Ruleaza de pe statia de admin prin SSH,
nu de pe un nod: nodul care se opreste ultimul nu poate raporta rezultatul,
iar la pornire scriptul trebuie sa astepte nodurile din afara.
Decizii importante:
- guest-urile din HA se opresc/pornesc cu `ha-manager set --state`, NU cu
pct/qm shutdown; din CLI acestea nu actualizeaza state-ul HA si CRM-ul
poate reporni guest-ul in mijlocul opririi
- apartenenta la HA se descopera dinamic din `ha-manager config`
- ordinea de oprire e pe dependente: consumatorii intai, CT 108 Oracle
ultimul, cu `shutdown immediate` in baza inainte de a opri containerul
- shutdown-ul salveaza local ce rula; startup-ul porneste exact atat, ca sa
nu reporneasca VM-uri oprite intentionat
- NEVER_AUTOSTART (109, 301, 310) protejeaza fallback-ul fara fisier de
stare: VM 109 e DR-ul a carui pornire nedorita a declansat incidentul
2026-04-20, restul sunt template-uri
- garda impotriva rularii de pe un nod sau din CT 171 (s-ar sinucide)
- ping_host() portabil Git Bash / Linux
Corectat in runbook: ordinea de oprire spunea "Oracle primul", gresit ca
ordine de dependente — VM 201 si CT 104 consuma baza.
Ambele testate cu --dry-run pe clusterul live.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
- vm109-watchdog.sh ruleaza si pe pvemini, nu doar pe pveelite (contine
`qm start 109`); tabelul de cron-uri de dezactivat era incomplet
- weekly-dr-test-proxmox.sh ruleaza sambata 06:00 pe AMBELE noduri si
porneste VM 109 — avertisment nou, cu trimitere la incidentul 2026-04-20
- comanda gata de rulat pentru dezactivare + comanda de restaurare din backup
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
Runbook nou pentru oprirea controlata a celor 3 noduri (lucrari electrice,
mutare rack, mentenanta UPS) fara ca HA sa relocheze resursele si fara ca
watchdog-ul sa reseteze hard nodul ramas fara quorum.
Doua capcane documentate:
- /etc/pve/datacenter.cfg nu exista => shutdown_policy implicit `conditional`
=> poweroff pe nod declanseaza FAILOVER, nu freeze
- watchdog-ul face reset hard dupa ~60s pe nodul care pierde quorumul cu
servicii HA inca active
Corectii in failover/README.md, verificate pe clusterul live:
- VM 201 ESTE in HA (grup ha-prefer-pvemini), docul spunea ca nu e
- CT 108 e in ha-prefer-pvemini (pvemini:100, pve1:50, pveelite:10),
nu in ha-group-main cu pveelite:50/pve1:33
- replicare CT 108 si VM 201 la */15 min, nu */5 => RPO real 15 min
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
