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

docs(cluster): procedura de oprire planificata + corectii stare HA reala

Browse Source 
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
This commit is contained in:
Marius
2026-08-27 12:28:54 +03:00
parent 3ba36b6119
commit ff7e7da6d1
4 changed files with 316 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

278
proxmox/cluster/docs/oprire-planificata-cluster.md Normal file
View File

@@ -0,0 +1,278 @@
# 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](../incidents/2026-04-20-cluster-outage.md).
### 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):**
```bash
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.
**Pe pveelite (10.0.20.202)** — `crontab -e`, comentează:
```
* * * * * /opt/scripts/pvemini-down-alert.sh
* * * * * /opt/scripts/vm109-watchdog.sh
* * * * * /opt/scripts/oom-alert.sh
```
**Pe pvemini (10.0.20.201):** `pveelite-down-alert.sh`
**Pe pve1 (10.0.20.200):** `oom-alert.sh`
> `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.
### 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
```bash
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
```bash
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:
```bash
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:
```bash
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:
```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. Verifică replicarea:
```bash
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](../failover/README.md)
- [Incident 2026-04-20 — cluster outage](../incidents/2026-04-20-cluster-outage.md)
- [Cluster README — SSH, storage, noduri](../README.md)
- [UPS](../ups/README.md)