ROMFASTSQL/proxmox/cluster/docs/oprire-planificata-cluster.md

Oprire planificată a clusterului (lucrări la rețeaua electrică)

Procedura de oprire controlată a tuturor celor 3 noduri Proxmox fără ca HA să 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-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. 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.

---

Varianta automată

Toată procedura de mai jos e implementată în două scripturi, de rulat de pe stația de admin (nu de pe un nod). Există în două variante echivalente — folosește-o pe cea potrivită shell-ului tău.

PowerShell (Windows, varianta obișnuită aici):

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 ...

.\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.

Dacă politica de execuție blochează scriptul: powershell -ExecutionPolicy Bypass -File .\cluster-shutdown.ps1 -DryRun

Bash (Git Bash, WSL sau de pe CT 171 claude-agent):

cd proxmox/cluster/scripts
./cluster-shutdown.sh --dry-run
./cluster-shutdown.sh
./cluster-startup.sh

Cele două variante scriu același fișier de stare, deci poți opri cu una și porni cu cealaltă.

cluster-shutdown.sh salvează local ce guest-uri rulau, iar cluster-startup.sh pornește exact ce era pornit — nu repornește VM-uri oprite intenționat.

Rulează întâi cu --dry-run. Restul documentului explică de ce fiecare pas e necesar și cum se face manual din GUI, dacă preferi.

---

TL;DR (procedura manuală)

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), apoi verifici că insula 10.10.10.0/24 a urcat pe pve1 și pveelite înainte de a porni guest-urile.

---

De ce nu poți pur și simplu să apeși „Shutdown"

Capcana 1 — politica implicită de shutdown este 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
Reboot	freeze — serviciile rămân pe nod
Shutdown (poweroff)	failover — serviciile se relochează pe alt nod

Adică exact ce vrei să eviți: un „Shutdown" pe pvemini trimite CT 108 Oracle, VM 201 și restul resurselor HA pe pve1/pveelite — pe noduri care oricum urmează să fie și ele oprite, cu 16 GB RAM pe pveelite și riscul din incidentul 2026-04-20.

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 servicii HA active, LRM-ul pierde agent lock-ul și watchdog-ul face reset hard după ~60 s. Nu shutdown curat — reset brutal, peste Oracle pornit.

Soluția e la Pasul 3: cu toate resursele HA în state stopped, LRM-ul nu mai are nimic activ, watchdog-ul nu mai e armat, iar pierderea quorumului devine inofensivă.

Ce să NU faci

• ❌ Nu folosi node maintenance mode (ha-manager crm-command node-maintenance enable <nod>) — acela migrează intenționat resursele, exact opusul scopului.
• ❌ Nu opri două noduri și nu lăsa unul pornit cu servicii HA active — vezi capcana 2.
• ❌ Nu lăsa nodul să oprească el guest-urile — Oracle și Windows au nevoie de shutdown curat, nu de timeout.

---

Pas 0 — Shutdown Policy = Freeze

De obicei nu ai nimic de făcut aici — politica e freeze din 2026-08-29. Verifică întâi:

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ă:

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.

Recomandare permanentă: lasă freeze și după intervenție. Docul de failover descrie deja un incident în care VM 201 a migrat nedorit în timpul unei mentenanțe — freeze e politica potrivită pentru acest cluster.

---

Pas 1 — dezactivează alertele automate

Altfel primești zeci de mailuri, iar vm109-watchdog.sh conține un qm start 109 care poate porni VM 109 fix când nu trebuie.

Ce trebuie dezactivat pe fiecare nod:

Nod	Script	De ce
pveelite	pvemini-down-alert.sh	mail la fiecare minut cât pvemini e jos
pveelite	vm109-watchdog.sh	conține qm start 109
pveelite	oom-alert.sh	zgomot
pvemini	vm109-watchdog.sh	rulează și aici, nu doar pe pveelite
pvemini	pveelite-down-alert.sh	zgomot
pvemini	oom-alert.sh	zgomot
pve1	oom-alert.sh	zgomot

Comandă unică, rulată pe fiecare nod — face backup și comentează exact liniile astea, lăsând restul crontab-ului neatins:

for h in 10.0.20.200 10.0.20.201 10.0.20.202; do
  ssh root@$h 'crontab -l > /root/crontab.backup-mentenanta.txt; \
    crontab -l | sed -E "/^[^#]/ s%^(.*(oom-alert|pvemini-down-alert|pveelite-down-alert|vm109-watchdog)\.sh.*)$%#MENTENANTA \1%" | crontab -'
done

Restaurare după intervenție:

for h in 10.0.20.200 10.0.20.201 10.0.20.202; do
  ssh root@$h 'crontab /root/crontab.backup-mentenanta.txt && crontab -l | grep -c MENTENANTA'
done   # trebuie sa intoarca 0 pe fiecare nod

pvemini-down-alert.sh doar trimite mail cu comanda de failover, nu o execută singur — verificat în cod. vm109-watchdog.sh însă chiar pornește VM 109, și rulează pe ambele noduri (pvemini și pveelite).

⚠️ Dacă fereastra de lucrări prinde sâmbătă dimineața

weekly-dr-test-proxmox.sh rulează sâmbătă la 06:00, pe pvemini ȘI pe pveelite, și pornește VM 109. Conform incidentului 2026-04-20, scriptul are istoric de a lăsa VM 109 pornit după un eșec (bug set -e) — exact declanșatorul buclei OOM de atunci.

Dacă intervenția atinge sâmbătă 06:00, comentează-l pe ambele noduri. La fel vm109-patch-window.sh (zilele 1-7 ale lunii, ora 03:00) dacă fereastra prinde începutul de lună.

Job-uri de backup

Verifică dacă fereastra de lucrări prinde un job vzdump. Dacă da, dezactivează-l din Datacenter → Backup înainte:

Job	Program
backup-impare-oracle (CT 108)	zile impare 02:00
backup-impare-rest (100, 103, 106, 171)	zile impare 03:00
backup-pare-flowise (CT 104)	zile pare 02:00
backup-pare-windows (VM 201)	zile pare 03:30
backup-pve1-minecraft (CT 101)	zile impare 22:00
backup-f1c87584 (VM 109)	sâmbătă 15:00, prima săptămână

Replicarea ZFS (pvesr) nu trebuie dezactivată — job-urile ratate se recuperează singure la primul tick după revenire.

---

Pas 2 — oprește guest-urile manual

Ordinea corectă e cea de dependențe: consumatorii întâi, Oracle ULTIMUL. 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 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 e template, nepornibil; VM 109 e stopped).

Din CLI, folosește ha-manager set <sid> --state stopped pentru guest-urile din HA, nu pct shutdown / qm shutdown. Din linia de comandă acestea nu actualizează state-ul HA, iar CRM-ul poate reporni guest-ul în mijlocul opririi. Din GUI nu e o problemă — butonul Shutdown trece oricum prin HA.

Oracle CT 108 — shutdown curat al bazei

ssh root@10.0.20.201 "pct exec 108 -- docker exec oracle-xe bash -lc \
  \"printf 'shutdown immediate\nexit\n' | sqlplus -s / as sysdba\""

Abia după ce comanda întoarce Database closed / Database dismounted / ORACLE instance shut down, oprești containerul din GUI.

Restul

După ce Oracle e jos, poți folosi Bulk Actions → Bulk Shutdown pe fiecare nod.

Oprirea unui guest HA din GUI îi setează automat state-ul HA pe stopped — CRM-ul nu îl va reporni. Consecință: la revenire trebuie să le pornești tu manual (pornirea îi pune state-ul înapoi pe started).

---

Pas 3 — verificare obligatorie înainte de oprirea nodurilor

ssh root@10.0.20.201 "ha-manager status"

Toate liniile service ... trebuie să arate (nod, stopped).

Dacă vreuna arată started, migrate, relocate sau fence — oprește-te. Nu opri niciun nod până nu se stabilizează, altfel intri fix în scenariul de la capcana 2.

Verificare rapidă că nu a mai rămas nimic pornit:

for h in 10.0.20.200 10.0.20.201 10.0.20.202; do
  echo "=== $h ==="
  ssh root@$h "pct list; qm list"
done

---

Pas 4 — oprirea nodurilor

Ordine: pveelite (.202) → pve1 (.200) → pvemini (.201)

pvemini ultimul: e nodul principal și serverul NFS.

GUI: selectezi nodul în arbore → Shutdown (dreapta sus). Așteaptă ca nodul să nu mai răspundă la ping înainte de a-l opri pe următorul.

---

Repornirea

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:

   ssh root@10.0.20.201 "pvecm status"      # Quorate: Yes, Total votes: 3
   ssh root@10.0.20.201 "ha-manager status"
   

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ă.

   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:

   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.

5. Verifică Oracle:

   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\""
   

6. Re-activează cron-urile dezactivate la Pasul 1 și job-urile de backup.

7. Verifică replicarea:

   ssh root@10.0.20.201 "pvesr status"
   

   Job-urile */15 (108, 171, 201) au ratat rulări; recuperează la primul tick.

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.

---

Capcane de mediu

BIOS „Power On After AC Loss"

Dacă setarea e pe Power On, nodurile pornesc singure în secunda în care revine curentul — posibil eșalonat, posibil înainte să fii tu pregătit. Primul nod care pornește nu are quorum. Incidentul 2026-04-20 conține exact acest simptom („pvemini revine SINGUR — BIOS auto-power-on sau watchdog reset").

Verifică setarea înainte de intervenție sau fii lângă servere la revenirea curentului.

UPS

Dacă lucrarea implică și UPS-ul, vezi ../ups/README.md și ../ups/docs/UPS-SHUTDOWN-README.md — NUT are propria logică de shutdown orchestrat care poate intra peste procedura de aici.

---

Stare de referință a clusterului (2026-08-29)

Resurse HA configurate — 10 în total:

Serviciu	Nod	Grup	Comentariu
ct:100	pvemini	ha-prefer-pvemini	portainer
ct:101	pve1	ha-prefer-pve1	minecraft
ct:103	pvemini	ha-prefer-pvemini	dokploy
ct:104	pvemini	ha-prefer-pvemini	flowise
ct:106	pvemini	ha-prefer-pvemini	gitea
ct:108	pvemini	ha-prefer-pvemini	central-oracle
ct:110	pve1	ha-prefer-pve1	moltbot
ct:171	pvemini	ha-prefer-pvemini	claude-agent
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 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
• Strategia de failover și HA
• Incident 2026-04-20 — cluster outage
• Incident 2026-08-27 — pveelite fără rețea 16h (USB LAN reset)
• Cluster README — SSH, storage, noduri
• UPS