From 9b01f52dfa560565b6d064fc995cf386e8aa6185 Mon Sep 17 00:00:00 2001 From: Marius Mutu Date: Sat, 29 Aug 2026 12:42:33 +0000 Subject: [PATCH] docs(kb): document VM 109 SSH-key gap in DR failover, restore correct host VM 109 a ajuns pe pvemini pe 27 aug fara ca root-ul de acolo sa aiba cheia SSH autorizata pe Windows guest, ceea ce a stricat testul DR saptamanal (eroare de auth SSH mascata drept "NFS/restore failed"). Migrat inapoi pe pveelite (unde cheia originala functioneaza) si documentat gap-ul structural din procedura de failover/migrare pentru viitor. --- memory/kb/tools/infrastructure.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/memory/kb/tools/infrastructure.md b/memory/kb/tools/infrastructure.md index cc56df6..52a9e13 100644 --- a/memory/kb/tools/infrastructure.md +++ b/memory/kb/tools/infrastructure.md @@ -283,9 +283,13 @@ ssh echo@10.0.20.202 "sudo pct exec 171 -- df -h /" - **VMID:** 109 | **Host:** pveelite | **Status:** Stopped (pornit doar pentru DR/test) - **IP:** 10.0.20.37 | **OS:** Windows Server + Oracle 19c -- **HA group:** ha-prefer-pveelite | state=stopped, nofailback=1 +- **HA:** e în HA — grup `ha-prefer-pveelite`, resource `vm:109`, `state=stopped` (pornit doar de test-ul săptămânal). Verificat 29 aug 2026 cu `pvesh get /cluster/ha/resources/vm:109`. +- **Replicare ZFS:** job standing `oracle-dr-windows` (109-0, 109-1): `pveelite → pve1` și `pveelite → pvemini`, zilnic 20:00 (`pvesh get /cluster/replication`). Asta ține câte o copie caldă a discului pe toate 3 nodurile — de-asta o migrare `qm migrate` între noduri e rapidă (refolosește replica existentă ca bază incrementală). - **Scop:** Disaster Recovery pentru Oracle Database (backup RMAN de pe server Windows extern) +**Incident 2026-08-27 → 2026-08-29 (rezolvat):** VM 109 a ajuns migrat pe pvemini (motiv exact neclar — posibil legat de evenimentele UPS din jurul datei de 27 aug, vezi `/opt/scripts/ups-battery-trend-backfill.sh` cu timestamp similar). Testul DR de sâmbătă (29 aug) a eșuat cu `Permission denied` / `Too many authentication failures` la SSH către `romfast@10.0.20.37:22122` — **nu pentru că NFS sau restore-ul chiar ar fi stricate**, ci pentru că root-ul de pe pvemini nu are cheia SSH privată care se potrivește cu singura cheie autorizată în `C:\Users\romfast\.ssh\authorized_keys` (`ssh-rsa ... mmarius28@gmail.com`) — cheia aia există doar în `/root/.ssh` pe pveelite. **Gap structural:** procedura de failover/migrare (`failover-dr-to-pvemini.sh`, `DR_VM_MIGRATION_GUIDE.md`) mută storage-ul NFS și scripturile de transfer, dar nu sincronizează niciodată cheia SSH root între noduri — orice migrare reală (nu doar failover de storage) către alt nod decât pveelite va rupe din nou testul DR în același fel, până nu se copiază manual `/root/.ssh/id_rsa{,.pub}` de pe pveelite pe nodul țintă (necesită acces root — contul `echo` cu care rulează automatizările nu are voie, sudo e restrâns la `qm`/`pct`/`pvesh`/`crontab -l`). +Fix aplicat: `qm migrate 109 pveelite --with-local-disks` (offline, VM era oprit) — a mutat config-ul înapoi pe pveelite, unde cheia originală funcționează deja. Verificat după: guest agent răspunde, `Test-Path F:\ROA\autobackup` → `True`, `authorized_keys` neschimbat. Testul SSH complet ca root (identic cu ce rulează cron-ul) nu a putut fi verificat direct (același motiv de acces), dar pveelite nu a fost atins deloc în tot incidentul, deci ar trebui să funcționeze ca înainte de 27 aug — confirmare finală abia sâmbăta viitoare (05 sep, 06:00) sau printr-o rulare manuală a scriptului ca root. + **Oracle Database:** - DB Name: ROA | Dimensiune: ~80 GB | Tabele: 42.625 - Strategie: full backup zilnic (6-7 GB) + cumulative incremental (200-300 MB) @@ -357,6 +361,8 @@ ssh echo@10.0.20.201 "sudo qm status 302" - `ups-monthly-test.sh` — 1 ale lunii, test baterie UPS - `ups-maintenance-shutdown.sh` — shutdown mentenanță UPS - `vm107-monitor.sh` — monitorizare VM 107 +- `failover-dr-to-pvemini.sh` / `failback-dr-to-pveelite.sh` — failover manual storage NFS Oracle DR (vezi § VM 109); NU sincronizează cheia SSH root +- `weekly-dr-test-proxmox.sh` — instalat aici și pe pveelite; guard intern rulează testul doar pe host-ul cu `/etc/pve/qemu-server/109.conf` local — de obicei sărit aici, doar dacă VM 109 chiar rulează pe pvemini ### pveelite (10.0.20.202) - **Resurse:** 16GB RAM, 557GB disk (+ 8GB ZFS swap — adăugat 2026-04-20 anti-OOM) @@ -366,7 +372,7 @@ ssh echo@10.0.20.201 "sudo qm status 302" **Scripturi `/opt/scripts/`:** - `oracle-backup-monitor-proxmox.sh` — zilnic 21:00, verifică backup Oracle -- `weekly-dr-test-proxmox.sh` — sâmbătă 06:00, test restore Oracle DR (VM 109) +- `weekly-dr-test-proxmox.sh` — sâmbătă 06:00, test restore Oracle DR (VM 109) — rulează efectiv de aici cât timp config-ul VM 109 e local ### pve1 (10.0.20.200) - **Resurse:** 32GB RAM, 1.3TB disk