From e33b24997c8406e9c40b08561ffb93d261651498 Mon Sep 17 00:00:00 2001 From: root Date: Sat, 27 Jun 2026 20:50:31 +0200 Subject: [PATCH] =?UTF-8?q?Doku:=20CARP-Verhalten,=20Agenten-Verbot=20f?= =?UTF-8?q?=C3=BCr=20Router-Start/Stop.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Erfasst warum ungeplantes Start/Stop die Verbindung killt, dass beide Nodes parallel laufen müssen, und dass Agenten VM 104 niemals eigenmächtig anfassen dürfen. --- pve1/00_README.md | 6 +- pve1/01_uebersicht.md | 6 +- pve1/04_fallback_aktivierung.md | 116 +++++++++++++++++-------------- pve1/infrastructure-host.md | 2 +- shared/infrastruktur-netzwerk.md | 4 +- 5 files changed, 77 insertions(+), 57 deletions(-) diff --git a/pve1/00_README.md b/pve1/00_README.md index dd3d0e0..26599d3 100644 --- a/pve1/00_README.md +++ b/pve1/00_README.md @@ -24,9 +24,13 @@ ## Besonderheiten pve1 - **Keine NVIDIA-GPU** → Power-Agent nur CPU (Intel RAPL) -- **Fallback-OPNsense** VM 104 (Klon von pve2) — nur bei Ausfall pve2 starten +- **Fallback-OPNsense** VM 104 — CARP-Backup parallel zu pve2 (advskew 100) - CT **100** (files) — Datei-Server +## ⛔ Agenten-Regel + +**Niemals** VM 104 (OPNsense) auf pve1 oder pve2 starten/stoppen — nur der Betreiber. Siehe [04_fallback_aktivierung.md](04_fallback_aktivierung.md). + ## Schnellbefehle ```bash diff --git a/pve1/01_uebersicht.md b/pve1/01_uebersicht.md index 16cd56b..c3dce0d 100644 --- a/pve1/01_uebersicht.md +++ b/pve1/01_uebersicht.md @@ -12,9 +12,9 @@ - **VMID:** 104 - **Name:** `opnsense-fallback` - **Quelle:** OPNsense (VM 104) von pve2 -- **Status:** Gestoppt, `onboot: 0` -- **Zweck:** Ersatz-Router falls pve2 oder der originale OPNsense ausfällt +- **Status:** CARP-Backup, `onboot: 0` +- **Zweck:** Parallel zu pve2:104 im CARP-Paar — übernimmt VIPs bei Master-Ausfall ## Wichtig -Die Fallback-VM darf **nicht parallel** zum Original auf pve2 laufen — gleiche Konfiguration und IPs würden kollidieren. +Beide OPNsense-Instanzen **laufen parallel**. CARP regelt die VIPs (`.1`): Master pve2 (advskew 0), Backup pve1 (advskew 100). Physische IPs: `.2` (Master) und `.3` (Backup). diff --git a/pve1/04_fallback_aktivierung.md b/pve1/04_fallback_aktivierung.md index 69a4516..2b9ae13 100644 --- a/pve1/04_fallback_aktivierung.md +++ b/pve1/04_fallback_aktivierung.md @@ -1,6 +1,19 @@ # OPNsense-Fallback & CARP -VM **104** (`opnsense-fallback`) auf pve1 ist als **CARP-Backup** vorbereitet. Die Config wurde **offline** auf der Disk angepasst (ZFS-Pool gemountet, VM nicht gestartet). +## ⛔ Regeln für Agenten / KI — STRIKT + +**NIEMALS** eigenmächtig VM 104 (OPNsense) auf pve1 oder pve2 **starten, stoppen, neustarten oder suspenden**. + +- Kein `qm start 104`, kein `qm stop 104`, kein `qm reboot 104`, kein `qm shutdown 104` +- **Nur** der Betreiber führt Router-Start/Stop aus — explizit, manuell, bewusst +- Agenten dürfen: Doku schreiben, Config offline auf Disk bearbeiten (wenn beauftragt), beraten +- Agenten dürfen **nicht**: Router zur „Prüfung“, zum „Testen“ oder „weil es so aussieht“ anfassen + +**Hintergrund:** CARP-Gateway ist `192.168.10.1`. Jeder ungeplante Start/Stop kann VIPs flappen → gesamtes Netz/internet weg. Das ist bereits passiert (2026-06-27). + +--- + +VM **104** (`opnsense-fallback`) auf pve1 ist als **CARP-Backup** vorbereitet. Die Config wurde **offline** auf der Disk angepasst (ZFS-Pool gemountet). ## Rollen @@ -9,6 +22,9 @@ VM **104** (`opnsense-fallback`) auf pve1 ist als **CARP-Backup** vorbereitet. D | **Master** | pve2 | 104 `opnsense` | 192.168.10.2 | 192.168.10.1 | 0 | | **Backup** | pve1 | 104 `opnsense-fallback` | 192.168.10.3 | 192.168.10.1 | 100 | +- **advbase:** 1 (beide) +- **Regel:** niedrigerer advskew = höhere Priorität → Master (0) hält VIPs, solange erreichbar + Weitere CARP-Gateways (VIP jeweils `.1`, physische Backup-IPs `.3`): | Netz | VLAN | CARP VIP | Backup-IP | @@ -21,9 +37,31 @@ Weitere CARP-Gateways (VIP jeweils `.1`, physische Backup-IPs `.3`): | VoIP | 60 | 192.168.60.1 | 192.168.60.3 | - **CARP-VHIDs:** 10, 20, 30, 40, 50, 60 (identisch auf beiden Nodes) +- **CARP-Passwort:** identisch auf beiden Nodes - **pfsync/XMLRPC:** Primary-Peer `192.168.10.2`, Backup-Peer `192.168.10.3` - **Hostname Backup:** `OPNsense-Fallback` +## Beide Router laufen parallel + +Bei CARP **müssen** Master (pve2) und Backup (pve1) **gleichzeitig laufen**. CARP regelt, wer die `.1`-VIPs hält — nicht Start/Stop als Normalbetrieb. + +## Warum ungeplanter Start/Stop die Verbindung killt + +Das Gateway im gesamten Netz ist die **CARP-VIP** `192.168.10.1` (und analog `.1` in anderen VLANs) — keine feste physische IP. + +Beim Start oder Stop eines Router-Knotens passiert: + +1. **CARP-Neuverhandlung** — wer hält `.1`? +2. **VIP flapped** — kurz weg, doppelt, oder falsche MAC +3. **Clients verlieren Gateway** → Internet/Management weg + +**Besonders kritisch:** + +- **Start + Stop hintereinander** = zwei CARP-Transitions → doppelter Ausfall +- **Backup hört Master nicht** (kein sauberes L2 auf dem VLAN-Trunk zwischen pve1 und pve2): Backup denkt „kein Master“, übernimmt `.1` trotz advskew 100 → **Split-Brain** mit laufendem Master → ARP-Chaos + +advskew 0/100 schützt **nur**, wenn beide Nodes sich gegenseitig am Trunk sehen. + ## Was beim Failover zählt — und was nicht ### vmbr0 + VLAN-Trunk (relevant) @@ -34,19 +72,11 @@ Weitere CARP-Gateways (VIP jeweils `.1`, physische Backup-IPs `.3`): ### vmbr1 / Services (nicht Teil von CARP) -`vmbr1` ist auf **jedem Host eine lokale, isolierte Bridge** ohne physischen Port — **kein vSwitch**, kein geteiltes L2 zwischen pve1 und pve2. +`vmbr1` ist auf **jedem Host eine lokale, isolierte Bridge** — kein vSwitch, kein geteiltes L2 zwischen pve1 und pve2. -| Host | vmbr1 | Anbindung | -|------|-------|-----------| -| pve2 | lokal | OPNsense `net1`, Docker CT 101, Home Assistant VM 106, … | -| pve1 | lokal | nur OPNsense-Fallback `net1` (keine weiteren Gäste) | - -- OPNsense-Interface **opt7 (SERVICES)** → `vtnet1` → `vmbr1` -- IP auf **beiden** Router-Instanzen: **`10.100.2.1/24`** (Gateway-Rolle, Endung `.1`) -- **Kein CARP** auf `10.100.2.0/24` — bewusst ausgenommen -- Interface bleibt **aktiv**, wird aber **nicht deaktiviert** - -**Konsequenz:** Docker/HA auf pve2 (`10.100.2.10` → Gateway `10.100.2.1`) erreichen beim Router-Failover auf pve1 **nicht** automatisch den Fallback-Router — pve2-vmbr1 und pve1-vmbr1 sind getrennte Netze. Diese Dienste laufen im Failover-Fall weiter über **192.168.10.x** (Management/VLAN 10), solange der VLAN-Trunk erreichbar ist. +- OPNsense **opt7 (SERVICES)** → `vtnet1` → `vmbr1` +- IP auf beiden Router-Instanzen: **`10.100.2.1/24`** +- **Kein CARP** auf `10.100.2.0/24` ## VM-Netzwerk pve1 (104) @@ -55,8 +85,6 @@ Weitere CARP-Gateways (VIP jeweils `.1`, physische Backup-IPs `.3`): | net0 | vtnet0 (VLAN-Trunk) | vmbr0 | BC:24:11:A1:B2:C3 | | net1 | vtnet1 (SERVICES) | vmbr1 | BC:24:11:D4:E5:F6 | -MACs bewusst **abweichend** von pve2, um Konflikte zu vermeiden wenn nur eine Instanz läuft. - ## Offline-Vorbereitung (bereits erledigt) Config-Änderungen direkt auf `/dev/pve/vm-104-disk-0` (ZFS `zroot`): @@ -64,10 +92,7 @@ Config-Änderungen direkt auf `/dev/pve/vm-104-disk-0` (ZFS `zroot`): 1. Physische VLAN-IPs von `.2` → `.3` (Backup) 2. CARP `advskew` von `0` → `100` 3. HA-Peer auf Primary `192.168.10.2` zeigen lassen -4. **opt7 (SERVICES):** `10.100.2.1` belassen (kein CARP, kein `.2`/`.3`-Schema) - -Referenz altes apollo-Image: `/mnt/nvme1/libvirt/images/router.qcow2` -(dort advskew=100, aber VLAN-Zuordnung damals über `vlan05` statt `lan`/`vtnet0` — **nicht** übernommen) +4. **opt7 (SERVICES):** `10.100.2.1` belassen Backup der Config vor Änderung: `/tmp/config.xml.bak-failover` @@ -83,47 +108,36 @@ zfs umount -a -f; zpool export -f new-zroot qemu-nbd -d /dev/nbd1 ``` -## Manueller Failover (kein automatischer Dry-Run) +## Manueller Failover — nur durch Betreiber -**Hinweis:** Failover manuell ausführen. Bei Fehlern ist ggf. physischer/serieller Zugang nötig — kein automatischer Test empfohlen. +**Kein automatischer Test. Kein Agent-Start/Stop.** ### Voraussetzungen -- pve2-OPNsense gestoppt **oder** pve2 ausgefallen -- Keine parallele Instanz auf pve2 (gleiche CARP-VIPs!) -- VLAN-Trunk auf pve1 (`vmbr0`) korrekt +- Beide Nodes normalerweise **parallel** im CARP-Betrieb +- Echter Failover-Test: bewusst geplant, physischer Zugang als Fallback +- VLAN-Trunk: pve1 und pve2 müssen sich CARP-seitig am Trunk sehen -### Schritte +### Prüfliste (Betreiber) -1. **Primary stoppen** (falls pve2 erreichbar): +- [ ] pve2 Master läuft, VIP `.1` antwortet +- [ ] pve1 Backup läuft parallel, **hält keine VIPs** (skew 100) +- [ ] pve1 pingt `192.168.10.2`, pve2 pingt `192.168.10.3` +- [ ] Erst bei geplantem Test: Master stoppen → Backup übernimmt VIPs - ```bash - ssh root@192.168.10.4 "qm stop 104" - ``` +### Befehle (nur Betreiber, nicht Agent) -2. **Fallback starten:** +```bash +# Failover-Test (Beispiel — nur manuell!) +ssh root@192.168.10.4 "qm stop 104" # Master stoppen +# Backup auf pve1 sollte VIPs übernehmen +qm terminal 104 # Konsole prüfen - ```bash - qm start 104 - ``` - -3. **Prüfen:** - - ```bash - qm terminal 104 - ``` - - - CARP-VIPs erreichbar: `192.168.10.1`, `192.168.20.1`, … - - Web-UI über Management-VIP - - **Nicht** erwarten, dass pve2-Dienste über `10.100.2.1` erreichbar sind - -4. **Zurück zum Normalbetrieb:** - - ```bash - qm stop 104 - ssh root@192.168.10.4 "qm start 104" - ``` +# Zurück +qm stop 104 # Backup stoppen +ssh root@192.168.10.4 "qm start 104" # Master wieder +``` ## Fallback-Kopie aktualisieren -Bei größeren OPNsense-Änderungen auf pve2: Backup/Restore erneut (siehe `03_backup_restore.md`), danach Backup-Rolle (advskew 100, IPs `.3`) wieder offline setzen. +Bei größeren OPNsense-Änderungen auf pve2: Backup/Restore (siehe `03_backup_restore.md`), danach Backup-Rolle (advskew 100, IPs `.3`) wieder **offline** setzen. diff --git a/pve1/infrastructure-host.md b/pve1/infrastructure-host.md index 3c37195..8f68054 100644 --- a/pve1/infrastructure-host.md +++ b/pve1/infrastructure-host.md @@ -15,7 +15,7 @@ Details: [05_speicher_wartung.md](05_speicher_wartung.md) | VMID | Name | Status | Rolle | |------|------|--------|-------| -| 104 | opnsense-fallback | **stopped** | OPNsense-Klon für Notfall — **nicht parallel zu pve2:104** | +| 104 | opnsense-fallback | running | CARP-Backup zu pve2:104 (parallel, advskew 100) | Konfiguration: `/etc/pve/qemu-server/104.conf` diff --git a/shared/infrastruktur-netzwerk.md b/shared/infrastruktur-netzwerk.md index 011097d..7c6a6ea 100644 --- a/shared/infrastruktur-netzwerk.md +++ b/shared/infrastruktur-netzwerk.md @@ -41,4 +41,6 @@ Details CT/VM-Netze: siehe Host-Doku unter `pve1/` bzw. `pve2/`. ## Failover-Hinweis -OPNsense-Fallback auf pve1 (VM 104) und Original auf pve2 **dürfen nicht parallel** laufen — gleiche CARP-VIPs. Failover betrifft **vmbr0/VLAN/CARP**, nicht das host-lokale Service-Netz `10.100.2.0/24` auf vmbr1. Siehe [pve1/04_fallback_aktivierung.md](../pve1/04_fallback_aktivierung.md). +OPNsense auf pve1 (Backup) und pve2 (Master) **laufen parallel** im CARP-Paar — VIPs (`.1`) hält der Master (advskew 0), der Backup (advskew 100) übernimmt bei Ausfall. Failover betrifft **vmbr0/VLAN/CARP**, nicht das host-lokale Service-Netz `10.100.2.0/24` auf vmbr1. + +**Agenten: niemals** VM 104 starten/stoppen — CARP-VIP-Flapping wirft das gesamte Netz raus. Siehe [pve1/04_fallback_aktivierung.md](../pve1/04_fallback_aktivierung.md).