From 8bd790b6d61a8e82a5477ccaacccf9155b35029b Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Tue, 14 Jul 2026 20:34:42 +0200 Subject: [PATCH] =?UTF-8?q?docs=20=F0=9F=94=80=20TP15:=20CSS326=E2=86=92CR?= =?UTF-8?q?S326=20(RouterOS/in-model)=20+=20TP20.1=20Vaultwarden=20ausgela?= =?UTF-8?q?gert?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Switches: CSS326-Fehlbestellung storniert, 2x CRS326-24G-2S+RM bestellt → RouterOS-fähig, damit in MikroMCP + Nautobot Golden Config (in-model statt SwOS-Insel). Kein PoE → EAP via Injektor. - TP21 Scope-Grenze: Golden Config deckt jetzt Router + beide CRS-Switches (ganzer Kabel-Fabric); außerhalb nur noch Omada-WLAN. - TP20.1 neu: Vaultwarden MariaDB→PG-Migration + Cross-Site-2-Site-HA aus TP20 ausgelagert (User-Wunsch). TP20 = reine Plattform (Cluster/Tiering/Backup/Nautobot-DB). Co-Authored-By: Claude Opus 4.8 --- docs/hw-refresh-requirements.md | 2 +- docs/teilprojekte.md | 27 +++++++++++++++++---------- 2 files changed, 18 insertions(+), 11 deletions(-) diff --git a/docs/hw-refresh-requirements.md b/docs/hw-refresh-requirements.md index a87c363..38bd828 100644 --- a/docs/hw-refresh-requirements.md +++ b/docs/hw-refresh-requirements.md @@ -4,7 +4,7 @@ > **Ziel:** ALLNET-Core + 2 Branch-Switches ablösen, Energieeffizienz + zentrales Management + DC-USV-Konzept > **⚠️ ENTSCHEIDUNGEN 2026-07-14 (überschreiben Teile dieses Recherche-Docs):** -> Ecosystem-Commit **MikroTik** (Kabel+Routing) / **Omada nur WLAN**. **2× CSS326-24G-2S+RM im Zulauf** als Switches (⚠️ **SwOS-only** → nicht in MikroMCP/Nautobot; **kein PoE** → EAPs via Injektor). WLAN → **Omada-EAP** (nicht hAP be³). Router → **RB5009** (mittelfristig). Die **A/B/C/D-Switch-Varianten unten sind damit Archiv**; DC-USV/Energie-Abschnitte bleiben gültig. **SSoT = TP15/TP20/TP21 in `teilprojekte.md`** + Memory `project_mikrotik_commit_nautobot_gc`. +> Ecosystem-Commit **MikroTik** (Kabel+Routing) / **Omada nur WLAN**. **2× CRS326-24G-2S+RM bestellt** als Switches (RouterOS → **in-model** bei MikroMCP/Nautobot; ⚠️ **kein PoE** → EAPs via Injektor). WLAN → **Omada-EAP** (nicht hAP be³). Router → **RB5009** (mittelfristig). Die **A/B/C/D-Switch-Varianten unten sind damit Archiv**; DC-USV/Energie-Abschnitte bleiben gültig. **SSoT = TP15/TP20/TP20.1/TP21 in `teilprojekte.md`** + Memory `project_mikrotik_commit_nautobot_gc`. --- diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 4d44e9a..7dc0d53 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -323,9 +323,9 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". ### TP15 — HW-Refresh: Switching + WLAN-Ecosystem + DC-USV ▸ 🟡 ENTSCHIEDEN, Beschaffung läuft (2026-07-14) — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc` - **🧭 Grundsatzentscheid (2026-07-14): Ecosystem-Split nach Layer.** **MikroTik = config-gemanagter Kern** (Routing/L3/CAKE + alle Switches), **Omada = ausschließlich WLAN**. Begründung: Projektziel #1 **CAKE** nur RouterOS/OpenWrt/OPNsense (Omada-Gateway kann kein CAKE); WLAN = Schmerzpunkt → Omada-EAP; Switching = MikroTik. Grenze **„MikroTik = Kabel+Routing, Omada = Funk"** deckt sich mit den 2 bestehenden Control-Planes (MikroMCP + Omada-Controller). Verworfene Vollvarianten (Omada-only, MikroTik-only) samt Begründung + Ansible/Nautobot-Recherche → Memory. -- **🛒 Switches: 2× CSS326-24G-2S+RM im Zulauf (2026-07-14).** 24×1G + 2×SFP+, lüfterlos, DC-input (USV-tauglich). Lösen ALLNET-Core (sw1) + Omada-ES208G (sw2 raus aus Switching-Rolle) + Cudy ab. - - ⚠️ **CSS = SwOS-only, KEIN RouterOS** → **außerhalb** MikroMCP/Nautobot-Golden-Config; VLANs statisch per SwOS-Web-UI. Die Config-as-Code-Grenze liegt damit am RouterOS-**Router**, nicht an den Switches. ⚠️ **kein PoE** → Omada-EAPs + Sonoff via **PoE-Injektoren**. - - 🚩 **Offener Flag (Switches „im Zulauf", noch änderbar):** wer die Switches *im* Golden-Config-Modell will → **CRS326-24G-2S+RM** (RouterOS, +~€50/St.) statt CSS. Sonst CSS = bewusste, billigere SwOS-L2-Insel (für statische VLANs robust). +- **🛒 Switches: 2× CRS326-24G-2S+RM bestellt (2026-07-14 — CSS326-Fehlbestellung storniert → CRS).** 24×1G + 2×SFP+, lüfterlos, DC-input (USV-tauglich). Lösen ALLNET-Core (sw1) + Omada-ES208G (sw2 raus aus Switching-Rolle) + Cudy ab. + - ✅ **CRS = RouterOS-fähig → in-model:** MikroMCP-Write + Nautobot Golden Config (TP21) managen auch die **Switches**, nicht nur den Router → config-as-code deckt den **ganzen Kabel-Fabric**. (SwOS-Boot bliebe als Fallback möglich, aber nicht genutzt.) + - ⚠️ **kein PoE** → Omada-EAPs + Sonoff via **PoE-Injektoren**. - **📶 WLAN → Omada EAPs** (ersetzt hAP-Funk + CAPsMAN): löst CAP-ARP/Broadcast-Quirks (P750W-Fall), reifes 802.11k/v/r-Roaming, VLAN→SSID im bereits laufenden Controller. hAP ax² werden Reserve. (Ersetzt die alte hAP-be³-Linie dieses Docs.) - **🧭 Router → RB5009 (mittelfristig):** L3/CAKE/Firewall vom hAP ax² lösen (device-mode=home blockt scheduler/fetch; „AP=Router"-Fragilität) → dedizierte RouterOS-Box, in MikroMCP + Nautobot. hAP ax² danach nur noch WLAN/Reserve. - **🔋 DC-USV** (unverändert gültig): MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CSS326 DC-input passt. @@ -410,17 +410,24 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". ### TP20 — Platform-Datenbank (Postgres Precious-Tier + MariaDB Tier-2) ▸ 🔜 KONZEPT (2026-07-14) — Memory `project_mikrotik_commit_nautobot_gc` - **Auslöser:** Mehrere Dienste brauchen zentrale DB (Nautobot-SoT [TP21], Vaultwarden, HA-Recorder). Grundsatzentscheid statt Nautobot-Insellösung — „wir skalieren schneller als wir schauen können" (User). - **✅ 2-Tier (User 2026-07-14):** - - **Tier-1 „Platform-Postgres" (precious):** EIN Postgres-Cluster, getrennte DBs für **Nautobot + Vaultwarden**. **PG 16** (Nautobot-Matrix-safe; **Nautobot unterstützt kein MariaDB**, nur PG/MySQL-8 → Postgres ist gesetzt, nicht optional). - - **Tier-2 (Bestand):** **HA-Recorder + Vaultwarden laufen aktuell auf MariaDB.** HA **bleibt** MariaDB (Write-Churn, andere Zuverlässigkeitsklasse, single-site). **Vaultwarden migriert MariaDB→Postgres** (in Tier-1 hochgezogen). Engine-Split fällt sauber entlang der Tier-Grenze. *(Alternative, dokumentiert-aber-verworfen: vw auf MariaDB lassen + MariaDB-Repl — verworfen zugunsten EINER Replikations-/Backup-Mechanik im Precious-Tier.)* + - **Tier-1 „Platform-Postgres" (precious):** EIN Postgres-Cluster, getrennte DBs für **Nautobot** (hier provisioniert) **+ Vaultwarden** (Onboarding = **TP20.1**). **PG 16** (Nautobot-Matrix-safe; **Nautobot unterstützt kein MariaDB**, nur PG/MySQL-8 → Postgres ist gesetzt, nicht optional). + - **Tier-2 (Bestand):** **HA-Recorder bleibt MariaDB** (Write-Churn, andere Zuverlässigkeitsklasse, single-site). *(Vaultwarden liegt heute ebenfalls auf MariaDB → wandert per TP20.1 nach Tier-1.)* Engine-Split fällt sauber entlang der Tier-Grenze. - **✅ Single-Site-first (User 2026-07-14):** jetzt nur BF-Primary. Nimmt das **2-Site-Quorum/Split-Brain**-Problem (bräuchte 3. Witness) vom Tisch. **ABER replication-ready ab Tag 1:** `wal_level=replica`, `archive_mode=on`, **pgBackRest (WAL+Base) → Garage-S3 (TP18)** = PITR sofort (DR auch ohne Standby) + späterer Standby = `pg_basebackup`, **kein** Primary-Umbau/Restart. - **Substrat:** Postgres in **LXC auf pve** (DB-Klasse, nicht Docker). -- **Phase 2 (später):** Cross-Site-Standby für Vaultwarden — `db-platform-standby`-LXC am 2. Standort, Streaming-Replication über WG (TP10), manuelles Promote-Runbook. Patroni + Witness nur falls Auto-Failover gewünscht. -- **Offene Sub-Steps:** Vaultwarden MariaDB→PG-Migration (`vw` .20.127); pgBackRest-Bucket in Garage (Abh. TP18-Startpfad ①); PG-Version final (16 vs 17). -- Abh.: **TP18** (Garage-S3 für Backups — mind. BF-Node ①), **TP10** (WG-Transport für Phase-2). **Blockt TP21.** +- **Scope TP20 = Plattform:** Cluster hoch, Tiering, Backup/PITR, **Nautobot-DB** anlegen. **vw-Migration + Cross-Site-HA = TP20.1** (ausgelagert). +- **Offene Sub-Steps:** pgBackRest-Bucket in Garage (Abh. TP18-Startpfad ①); PG-Version final (16 vs 17); Rollen/DB-Anlage Nautobot. +- Abh.: **TP18** (Garage-S3 für Backups — mind. BF-Node ①). **Blockt TP21 + TP20.1.** + +#### TP20.1 — Vaultwarden → Platform-Postgres + Cross-Site-HA ▸ 🔜 KONZEPT (2026-07-14, ausgelagert aus TP20) +- **Ziel:** `vw` (`.20.127`, heute MariaDB) auf den Precious-Tier holen **und** das eigentliche User-Ziel erfüllen: **DB-Replikation über 2 Sites** (Standort-Verlust überlebbar). +- **Phase 1 — Migration (single-site):** vw **MariaDB→Postgres** (Export → Import in Tier-1-DB `vaultwarden` → `DATABASE_URL` umstellen → verifizieren). Danach ist vw precious + im pgBackRest/PITR-Schirm von TP20. *(Alternative verworfen: vw auf MariaDB lassen + MariaDB-Repl — zugunsten EINER Replikations-/Backup-Mechanik im Precious-Tier.)* +- **Phase 2 — Cross-Site-Standby:** `db-platform-standby`-LXC am 2. Standort → `pg_basebackup`/Streaming-Replication über **WG (TP10)** → **manuelles Promote-Runbook**. Repliziert den ganzen Tier-1-Cluster (vw = HA-Ziel, Nautobot bekommt Gratis-DR-Kopie). **Patroni + 3. Witness** nur, falls später Auto-Failover statt manuellem Promote gewünscht. +- **Verwandt/Abgrenzung:** vw ist auch in **TP16** offen (CF-Access: `bypass`→WARP-geschützt) — **DB-HA ≠ Access**, getrennt behandeln. Reziprokes 2-Site-Muster analog **TP16**/**TP18**. +- Abh.: **TP20** (Tier-1 Postgres muss stehen), **TP10** (WG-Transport für Phase-2), **TP18** (Backup-Schirm). Kein Blocker für TP21. ### TP21 — Nautobot Golden Config (config-as-code Control-Plane) ▸ 🔜 KONZEPT (2026-07-14) — Memory `project_mikrotik_commit_nautobot_gc` - **Ziel:** modellierter Control-Plane über den MikroTik-**RouterOS**-Kern: GUI-SoT + **Config-Compliance/Drift** + intended-config + Push. **Ergänzt** MikroMCP (interaktiv/Debug), **ersetzt es nicht** (deklarativ/DR/Compliance). Aus User-Recherche 2026-07-14: MikroTik in Golden Config **erstklassig** (`mikrotik_routeros` + `_api`, Nornir/NAPALM, backup+deploy). -- **Scope-Grenze (wichtig):** RouterOS in-model (ap1 heute / RB5009 künftig). **CSS326-Switches = SwOS = NICHT in Golden Config** (s. TP15-Flag); **Omada-WLAN = eigener Controller**. Golden Config deckt also den **RouterOS-Router**, nicht den ganzen Fabric. *(Wenn Switches in-model sollen → CRS statt CSS, TP15-Flag.)* +- **Scope-Grenze:** RouterOS in-model = **Router (ap1 heute / RB5009 künftig) + beide CRS326-Switches** (RouterOS-Boot) → Golden Config deckt den **ganzen Kabel-Fabric**. Außerhalb bleibt nur **Omada-WLAN** (eigener Controller). - **Stack:** `nautobot-docker-compose` (Django/gunicorn + Redis + Celery worker/beat) auf Docker-Host; **DB extern → Platform-Postgres (TP20)**; Redis lokal/ephemer; **Git-Backend (backups/intended/templates) → bestehendes Gitea** (`project_gitea_backup_state`). - **PoC-Pfad:** Nautobot-Stack hoch → ap1 via RouterOS-API adoptieren → Backup + Compliance/Drift an *einem* Gerät zeigen → dann Templates/intended für VLAN-/Firewall-Standards. - **Offen:** Nautobot- + GC-App-Version; ob OpenWrt je in-model muss (custom Nornir-Dispatcher — nur relevant falls Router doch OpenWrt+cake-autorate statt RB5009). @@ -447,4 +454,4 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". ⏳ **TP3.3 (WLAN-Coverage-Kur) offen** — Fortsetzung neue Session (`docs/wifi-p750w-coverage-and-map.md`). 5. ~~**TP10 (VPN)**~~ ✅ Kern durch (2026-06-27) + Edge-Cutover (2026-07-01) → DURCH. Offen nur: DDNS-Auto-Updater. 6. **Nachgelagert/Research-getrieben:** TP8 (Access), TP9 (HA), TP11 (Monitoring + CF-Tunnel-Track-B/C), TP12 (IPv6), TP13 (Spaß). -7. **Foundation (2026-07-14):** **TP15** (MikroTik-Switching / Omada-WLAN, 2× CSS326 im Zulauf) ∥ **TP20 (Platform-Postgres, single-site replication-ready)** → **TP21 (Nautobot Golden Config)**. TP20 hängt an **TP18 ①** (Garage-Bucket für pgBackRest). +7. **Foundation (2026-07-14):** **TP15** (MikroTik-Switching / Omada-WLAN, 2× CRS326 bestellt) ∥ **TP20 (Platform-Postgres, single-site replication-ready)** → **TP21 (Nautobot Golden Config)** ∥ **TP20.1 (Vaultwarden→PG + 2-Site-HA)**. TP20 hängt an **TP18 ①** (Garage-Bucket für pgBackRest).