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

---

TL;DR

1. Datacenter → Options → HA Settings → Shutdown Policy = Freeze ← fără asta, HA mută resursele
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).

---

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

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:

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.

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

GUI: Datacenter → Options → HA Settings → Edit → Shutdown Policy: Freeze

CLI (echivalent):

ssh root@10.0.20.201 "echo 'ha: shutdown_policy=freeze' >> /etc/pve/datacenter.cfg"

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

Ordine importantă: Oracle primul, restul după.

Nod	Guest	În HA	Cum
pvemini	CT 108 central-oracle	Da	shutdown immediate în DB, apoi Shutdown CT
pvemini	VM 201 roacentral	Da	Shutdown (guest agent)
pvemini	VM 302 oracle-test	Nu	Shutdown
pvemini	VM 303 Win11-Adina	Nu	Shutdown
pvemini	CT 100 portainer	Da	Shutdown
pvemini	CT 102 docker.romfast.ro	Nu	Shutdown
pvemini	CT 103 dokploy	Da	Shutdown
pvemini	CT 104 flowise	Da	Shutdown
pvemini	CT 106 gitea	Da	Shutdown
pvemini	CT 171 claude-agent	Da	Shutdown
pve1	CT 101 minecraft	Da	Shutdown
pve1	CT 110 moltbot	Da	Shutdown
pveelite	—	—	nimic pornit (CT 301 și VM 109 sunt stopped)

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

   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. Verifică replicarea:

   ssh root@10.0.20.201 "pvesr status"
   

   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.

---

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-27)

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

---

Referințe

• Strategia de failover și HA
• Incident 2026-04-20 — cluster outage
• Cluster README — SSH, storage, noduri
• UPS