cluster-knaster/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md

Aufbau Cluster „knaster“ – zusammengeführter Umsetzungsplan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Die fünf installierten Proxmox-Knoten werden Schritt für Schritt zum Cluster „knaster“ ausgebaut, auf dem die Architektur aus docs/PLAN.md läuft. Grundlage sind die echte Hardware und die Aufgaben aus Planner Epic 7.

Architecture: Fünf Proxmox-Knoten mit ZFS bilden einen Cluster. Jeder GPU-Knoten bekommt eine Ubuntu-VM, an die alle seine Karten durchgereicht werden; darin laufen Docker-Container pro Rolle. Die Infrastruktur (Router, Postgres, Monitoring) läuft als LXC mit Docker und HA. Die beiden RTX-4000-Ada-Rechner bleiben Windows-Arbeitsplätze und stellen ihre Leistung über die vorhandene Worker-Registry v2 bereit. Starke Modelle laufen ausschließlich über den LiteLLM mit PSE auf appsrv08.

Tech Stack: Proxmox VE 9.2 (Debian 13, ZFS), Ubuntu 24.04 in den GPU-VMs, NVIDIA R580 (Maxwell/Pascal), llama.cpp, whisper.cpp, Docker Compose, OpenTofu (bpg/proxmox), Ansible, Prometheus/Alertmanager/Grafana, Proxmox Backup Server, n8n (n8n.mindboost.app), LiteLLM (appsrv08), Python-Paket knaster.

Spec/Quellen (bei der Umsetzung mitlesen):

• docs/PLAN.md, docs/adr/0001–0006, docs/IMPLEMENTATION.md, docs/BETRIEB.md (dieses Repo)
• Planner „Epic 7 — CCO KI-Agent Infrastruktur“ (Plan NLQ0gHCZkUmdMv3ko__DmZgAHU_S, Bucket IeG9IcsEG0-_ZEW5unBaiZgAEtoE)
• C:\Users\r.rapp\it\proxmox\STAND-2026-10-08.md und healthcheck-2026-10-08.txt (Ist-Stand der Knoten)
• Repo mygodel/nex: docs/plans/2026-10-07-nex-stt-gpu.md (Whisper im Haus), docs/plans/2026-09-29-nex-worker-registry-v2.md (Ada-Worker)

Dieser Plan löst die Abläufe in docs/PLAN.md §8 („Roadmap“) und docs/IMPLEMENTATION.md („Gemeinsames Deployment“) ab. Deren Phasen sind unten zugeordnet.

---

Ausgangslage (Stand 12.10.2026)

Knoten	IP	Hardware	Platten	GPUs	Besonderheit
pve44	192.168.100.210	ThinkStation P310, i7-6700, 32 GB	2× 256 GB (sdb: altes Windows, NTFS)	M4000 + P2000	–
pve46	192.168.100.209	ThinkStation P310, i7-6700, 32 GB	1× 256 GB	M4000 + P2000	bootet Legacy statt UEFI
pve48	192.168.100.212	unbekannt	unbekannt	unbekannt	kein SSH (Passwort aus .env falsch)
pve52	192.168.100.207	ThinkStation P320, i7-7700, 32 GB	2× 256 GB (sdb: altes Windows, BitLocker „GODEL55“)	M4000 (P2000 nicht erkannt)	–
pve61	192.168.100.214	Surface Book, i5-8350U, 8 GB	1× 256 GB NVMe	Intel UHD 620	LAN nur über USB-NIC im Lenovo-Dock, 2 Akkus

Alle Knoten: PVE 9.2.2, Kernel 7.0.2, ext4 + LVM-thin auf einer SSD (kein ZFS), 1 GbE, kein Cluster. VT-x und VT-d sind aktiv. IOMMU ist geprüft: Jede Karte liegt mit ihrer Audio-Funktion in einer eigenen Gruppe (M4000 in Gruppe 1, P2000 in Gruppe 8), Passthrough ist also möglich.

Außerhalb des Clusters:

• GODE-PC-05/06: je eine RTX 4000 Ada mit 20 GB, Windows, tagsüber Arbeitsplätze. Sie laufen heute schon als LLM-Worker (LocalLLMWorker.ps1).
• appsrv08 (.29): GRP produktiv, NEX und LiteLLM mit PSE-Filter.
• n8n: n8n.mindboost.app.
• Gitea: gitea.mindboost.team.

---

Global Constraints

• Starke Modelle (tier0, OpenRouter) nur über den LiteLLM mit PSE auf appsrv08. Kein zweiter Gateway-Weg nach außen, sonst wird die Pseudonymisierung umgangen (Epic 7 „LiteLLM Swarm: PSE-Fix“).
• Netz: flach 192.168.100.0/24, Gateway .1, DNS .120. Feste IP-Literale, kein DNS-Name in Konfigurationen, vorerst kein VLAN.
• Container zuerst: Dienste laufen als Docker-Container, in LXC oder in einer VM. Eine VM gibt es nur dort, wo sie ein Treiberproblem löst (GPU-VM pro Knoten, D2) oder ein Produkt sie verlangt.
• Dry-Run: Alle knaster-Aktionen gegen Infrastruktur starten mit KNASTER_DRY_RUN=true und werden erst nach einer Woche Beobachtung einzeln freigeschaltet.
• STT: whisper-server auf Port 8178, nur von 192.168.100.29 erreichbar. stt.openai.base_url nur als IP-Literal (nex-STT-Plan, Annahmen).
• Ada-Rechner: Windows bleibt, Mitarbeitende haben tagsüber Vorrang, kein Proxmox darauf.
• Datacenter-weite Einstellungen (Benutzer, 2FA, Firewall, Benachrichtigungen, Pools, Metriken) erst, wenn alle Knoten im Cluster sind.
• Alte Windows-SSDs (pve44 sdb, pve52 sdb) nur nach ausdrücklicher Freigabe löschen (D1).
• Geheimnisse nie ins Repo. Zugangsdaten liegen in C:\Users\r.rapp\it\proxmox\.env, der Schlüssel unter …\proxmox\keys\.
• Planner-Webhook tdo-codex-update: pro Aufruf nur eine Aktualisierung, vorhandene Titel nie umbenennen (Abgleich läuft über den Titel, Schwelle 0.8).

Review Focus

1. Eine Neuinstallation löscht die Einrichtung vom 08.10. Betroffen sind Schlüssel, Paketquellen, Dock-Bindung und SSH-Hostschlüssel. Erwartung: Das Bootstrap-Skript stellt alles wieder her, und ssh -o BatchMode=yes pveXX hostname klappt danach ohne Nachfrage (Task 1.1, Test im Skript).
2. Der Cluster-Beitritt ersetzt authorized_keys. Erwartung: Nach jedem pvecm add funktioniert der Laptop-Zugang auf allen Knoten weiter (Task 2.1, Prüfschritt).
3. Die USB-NIC von pve61 verschwindet nach einem Stromausfall oder einem Umstecken des Docks. Erwartung: vmbr0 hängt danach wieder an der Karte, ohne Eingriff (Task 1.3, Test: Dock aus- und einstecken).
4. Ein Ada-Worker ist tagsüber belegt oder aus. Erwartung: tier1-Anfragen landen ohne Fehler bei tier0 über PSE (Task 6.4, Unit-Test im Router).
5. Die Rolle pve-host sperrt NVIDIA und setzt VFIO. Erwartung: Das passiert nur auf GPU-Knoten. pve61 behält seine iGPU für den Kiosk (Task 3.1, Ansible-Gruppen, Prüfung lspci -k).

---

Entscheidungen (vor der jeweiligen Phase bestätigen)

#	Frage	Empfehlung	Begründung	Alternative
D1	Speicher	Alle Knoten mit ZFS neu installieren: RAID1 auf Knoten mit zwei SSDs (pve44, pve52, ggf. pve48), Einzel-ZFS auf pve46 und pve61. Gast-Speicher ist überall local-zfs.	Es steht noch nichts auf den Knoten, ein Neuaufbau kostet etwa 30 Min. pro Knoten. Gleicher Speichername überall ermöglicht Replikation und HA zwischen beliebigen Knoten. Dazu kommen Snapshots und Ausfallsicherheit der Systemplatte. pve46 kommt dabei auf UEFI. Das Video empfiehlt ZFS RAID1. Kapazität: 256 GB je Knoten reichen für das Speicherbudget aus PLAN §1.4.	Kein Neuaufbau: SSD2 als Einzel-ZFS tank nur auf pve44 und pve52, Replikation nur zwischen diesen beiden. pve46 und pve61 bleiben ohne ZFS.
D2	GPU als VM oder LXC	Pro GPU-Knoten eine Ubuntu-24.04-VM mit allen Karten des Knotens, darin Docker Compose pro Rolle.	Der Host-Kernel (7.0) bleibt ohne NVIDIA, Proxmox-Updates gefährden den Treiber nicht. R580 kommt als Ubuntu-Paket und ist per Snapshot rückrollbar. IOMMU-Gruppen sind geprüft. Eine VM pro Knoten statt pro Rolle (ADR-0001) spart RAM. Das Argument „gemischte Generationen“ aus ADR-0001 gilt im Cluster nicht mehr, alle Karten sind Maxwell/Pascal. Kosten: 2–5 % CPU, fest reservierter VM-RAM (12–16 GB von 32 GB).	LXC mit Host-Treiber: braucht R580 auf Kernel 7.0 oder einen festgehaltenen älteren Kernel.
D3	Ada-Rechner	Windows bleibt. LocalLLMWorker.ps1 mit llama-server (CUDA) meldet sich über die Worker-Registry v2. Die knaster-Slots tier1-general/tier1-flex lösen auf einen Worker auf, der online ist, sonst tier0.	Die Registry v2 ist fast fertig (44 von 55 Schritten). Mitarbeitende werden nicht gestört. vLLM läuft unter Windows nicht nativ, Multi-LoRA, QLoRA und Qwen3-TTS kommen deshalb erst mit einer späteren WSL2-Entscheidung (Phase 9).	Dual-Boot mit Proxmox: scheidet aus, die Rechner werden tagsüber genutzt.
D4	LiteLLM	Kein eigener LiteLLM im knaster-Infra. Der Router nutzt den LiteLLM auf appsrv08 (mit PSE), die lokalen Slots werden dort als Modelle eingetragen.	Es läuft bereits ein dritter LiteLLM; noch einer würde PSE für tier0 umgehen. Ein Modellwechsel bleibt eine Datenänderung.	Eigener LiteLLM nur für lokale Slots, ohne OpenRouter-Zugang.
D5	IP-Plan	Knoten behalten .207–.214. Gäste bekommen einen festen Block außerhalb des DHCP-Bereichs. Vorschlag .220–.239, wird in Task 0.3 gegen den DHCP-Bereich geprüft.	Die STT-Konfiguration braucht IP-Literale. Die alten GODEL-DNS-Einträge zeigen, dass die Knoten-IPs aus DHCP stammen, deshalb Reservierungen anlegen.	VLAN svc (PLAN §1.4) später, wenn der Switch das zulässt.

---

Phase 0 – Bestandsaufnahme und Repo an die Wirklichkeit anpassen

Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeinsames Deployment“ Schritt 1.

Task 0.1: Zugang zu pve48 und Inventar aller Knoten

Wo: Teil a vor Ort an der Konsole von pve48, Teil b remote · Planner: „Proxmox: pve48 root-Passwort klären und SSH-Schlüssel nachtragen“

• a (vor Ort): An pve48 als root anmelden, gegebenenfalls passwd, neuen Wert in .env (PVE48_PASS) eintragen.
• b: Schlüssel verteilen (Verfahren vom 08.10., push_keys.py) und Paketquellen umstellen. Prüfung: ssh -o BatchMode=yes pve48 hostname → pve48.
• c: Gesundheitscheck auf pve48 ausführen und healthcheck-2026-10-08.txt ergänzen. Notieren: CPU, RAM, Platten, GPUs, IOMMU-Gruppen.
• d (vor Ort, falls nötig): pve52 – steckt neben der M4000 eine P2000? Falls ja: Sitz und Steckplatz prüfen, bis lspci | grep -c NVIDIA zwei VGA-Geräte zeigt. Verbleib von Godel45 klären (im STT-Plan aufgeführt).

Task 0.2: DHCP-Bereich und IP-Plan (D5)

Wo: remote (DHCP-Server, vermutlich DC .120 oder UniFi) · Planner: „PVE-Config: Netzwerk prüfen – Bridge, VLAN-Fähigkeit und NIC-Kompatibilität“

• DHCP-Bereich auslesen. Für .207, .209, .210, .212 und .214 Reservierungen auf die MACs der Knoten anlegen (MACs stehen im Healthcheck).
• Gäste-Block festlegen (Vorschlag .220–.239) und als Ausschluss im DHCP eintragen. Prüfung: ping auf jede Adresse des Blocks → keine Antwort. DHCP-Ausschluss sichtbar.

Task 0.3: Entscheidungen D1–D5 bestätigen

Wo: Gespräch mit dem Nutzer

• D1: Ausdrückliche Freigabe zum Löschen von pve44 sdb (NTFS) und pve52 sdb (BitLocker „GODEL55“). Vorher klären, ob Daten oder Recovery-Key gebraucht werden.
• D2–D5 bestätigen. Ergebnis als Abschnitt „Entscheidungen 2026-10“ in docs/PLAN.md §9 eintragen.

Task 0.4: Site-Dateien, Ansible-Inventar und ADRs an die echte Hardware anpassen

Wo: remote, Repo · Files:

• Modify: sites/knaster/inventory.yaml, sites/knaster/proxmox.yaml, sites/knaster/registry.yaml, platform/proxmox/ansible/inventory.yml, docs/PLAN.md §1.3, §1.4 und §9
• Modify: docs/adr/0001-gpu-vms-infra-lxc.md (eine VM pro Knoten), docs/adr/0002-storage-zfs-kein-ceph.md (D1), docs/adr/0006-legacy-gpus-llamacpp-tts-auf-ada.md (Ada unter Windows, D3)
• Test: core/tests/test_inventory_validate.py

Interfaces:

• Produces: Knotennamen pve44, pve46, pve48, pve52, pve61. PCI-Mappings gpu-m4000-pve44, gpu-p2000-pve44, gpu-m4000-pve46, gpu-p2000-pve46, gpu-m4000-pve52 (plus pve48 nach Task 0.1). GPU-VMs gpu-pve44 (vmid 244), gpu-pve46 (246), gpu-pve52 (252). Infra-LXC infra (vmid 101). Ansible-Gruppen pve_all, pve_gpu_hosts, pve_kiosk.

• Step 1: Failing test. In test_inventory_validate.py den Test test_site_knaster_matches_real_nodes anlegen: Die Inventar-Knoten sind genau {pve44, pve46, pve48, pve52, pve61}, proxmox.yaml enthält keine IP aus 10.20.0.0/24, und jedes pci_mappings[*].node ist ein Inventar-Knoten.

• Step 2: make test → FAIL (alte Annahmen pve-ada, pve1–pve4).

• Step 3: Site-Dateien umschreiben. Werte für IDs und Pfade aus lspci -nn und dem Healthcheck: M4000 10de:13f1 auf 0000:01:00, P2000 10de:1c30 auf 0000:02:00. Gateway 192.168.100.1, DNS 192.168.100.120, keine vlan_svc, Gast-IPs aus D5. Die M4000 bleiben disabled: true bis zum Benchmark-Tag (Task 3.5). Die Ada-Slots zeigen auf engine: worker-registry (siehe Task 6.4).

• Step 4: make test && make validate → PASS. knaster placement plan --inventory sites/knaster/inventory.yaml liefert eine Zuordnung ohne Fehler.

• Step 5: Commit sites: Inventar und Zielbild an echte Knoten (pve44–pve61) angepasst; ADR-0001/0002/0006 ergänzt.

---

Phase 1 – Knoten-Grundlage (vor dem Cluster)

Task 1.1: Bootstrap-Skript für einen frischen Knoten

Wo: remote · Planner: „PVE-Config: Erst-Update aller Knoten (apt full-upgrade)“ · Files: Create platform/proxmox/scripts/bootstrap-node.sh, Create platform/proxmox/scripts/README.md

Interfaces:

• Produces: bootstrap-node.sh <knoten>, idempotent. Ausgabe endet mit BOOTSTRAP OK <hostname> oder Exit ≠ 0.

• Step 1: Das Skript (läuft auf dem Laptop, Git-Bash) erledigt Folgendes:

  • alten Hostschlüssel mit ssh-keygen -R <ip> entfernen
  • Schlüssel per Passwort aus .env eintragen, mit dem SSH_ASKPASS-Verfahren vom 08.10. (nur anhängen, grep -qxF)
  • Enterprise-Quellen auf Enabled: no setzen, proxmox.sources mit pve-no-subscription anlegen, vorher sichern
  • apt-get update && apt-get -y full-upgrade
  • Pakete ethtool lm-sensors installieren
  • Prüfen: timedatectl show -p NTPSynchronized = yes

• Step 2: Zweiter Lauf gegen denselben Knoten → keine Änderung, wieder BOOTSTRAP OK.

• Step 3: Commit.

Task 1.2: Neuinstallation mit ZFS (nur wenn D1 = Empfehlung)

Wo: vor Ort, USB-Stick mit PVE 9.2 (ISO und Prüfsumme in C:\Users\r.rapp\it\proxmox) · Planner: „Proxmox: Speicher aller Knoten richtig konfigurieren“, „PVE-Config: RAM-Planung je Knoten (Host-Reserve, ZFS-ARC, KSM, Swap)“

Reihenfolge: pve46 (eine Platte, Legacy → UEFI), dann pve44, pve52, pve48 und zuletzt pve61 mit angestecktem Dock (der USB-C-Adapter ist zurückgegeben).

• Pro Knoten: BIOS auf UEFI, Secure Boot aus, iGPU als primäre Anzeige (GPU-Knoten). Installer: gleicher Hostname und gleiche IP wie bisher, ZFS (RAID1) bzw. ZFS (RAID0) bei einer Platte, ashift=12, compress=on.
• Danach bootstrap-node.sh <knoten> → BOOTSTRAP OK.
• ZFS-ARC begrenzen: zfs_arc_max = 4 GiB auf 32-GB-Knoten, 1 GiB auf pve61 (/etc/modprobe.d/zfs.conf, update-initramfs -u). Prüfung: zpool status → ONLINE. pvesm status → local-zfs active. cat /sys/module/zfs/parameters/zfs_arc_max → 4294967296 bzw. 1073741824.

Task 1.3: pve61 – Netzwerk am Dock robust machen, Akku schonen

Wo: remote, Akku-Einstellung vor Ort · Planner: Teil von „Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk“

• NIC des Docks per systemd-.link auf den Namen nic0 festlegen, Zuordnung über die MAC 3c:e1:a1:c0:83:9d. bridge-ports nic0 in /etc/network/interfaces. Nach dem Ausstecken hängt ein udev-Hook ifup/ifreload die Karte wieder an vmbr0.
• Test (vor Ort): Dock 10 s ausstecken und wieder einstecken → nach höchstens 30 s ping 192.168.100.214 vom Laptop ok.
• Surface-UEFI „Battery Limit“ einschalten (Lauter-Taste + Einschalten). Prüfung: grep . /sys/class/power_supply/BAT*/capacity pendelt bei etwa 50 %.

---

Phase 2 – Cluster

Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist kein QDevice nötig.

Task 2.1: Cluster „knaster“ bilden

Wo: remote · Planner: „GPU-Knoten 3: Cluster mit QDevice (Container auf appsrv08), NVIDIA-Treiber, GPU-Container“ (Teil Cluster)

• Auf pve44: pvecm create knaster --link0 192.168.100.210.
• Nacheinander auf pve46, pve48, pve52 und pve61: pvecm add 192.168.100.210 --link0 <eigene IP>. Nach jedem Beitritt den Laptop-Schlüssel in /etc/pve/priv/authorized_keys prüfen und gegebenenfalls einmal ergänzen. Prüfung: pvecm status → Quorate: Yes, Total votes: 5. for n in pve44 pve46 pve48 pve52 pve61; do ssh -o BatchMode=yes $n hostname; done → fünf Namen.
• Datacenter-Optionen: Migrationsnetz 192.168.100.0/24, Typ secure.

Task 2.2: HA-Regeln und Replikation

Wo: remote

• Node-Affinity-Regeln: Infra-Dienste nur auf pve44, pve48, pve52. pve61 bekommt keine HA-Gäste, GPU-VMs bleiben an ihrem Knoten.
• Replikationspartner festlegen: Infra-LXC von seinem Knoten auf einen zweiten, */15. Prüfung: ha-manager rules config bzw. ha-manager groupconfig zeigt die Regeln.

---

Phase 3 – GPU-Grundlage und Benchmark-Tag

Task 3.1: Steuerrechner „ops“ und Host-Rolle nur für GPU-Knoten

Wo: remote · Files: Modify platform/proxmox/ansible/inventory.yml, platform/proxmox/ansible/playbooks/site.yml, Create platform/proxmox/README.md (Abschnitt ops-LXC)

• LXC ops (Debian 13, vmid 100, auf pve44, IP aus D5) mit ansible-core, opentofu, git und dem Repo-Clone. Ansible läuft nicht auf dem Windows-Laptop.
• site.yml: pve-host nur für pve_gpu_hosts (pve44, pve46, pve52, ggf. pve48). pve61 steht in pve_kiosk ohne VFIO und Blacklist.
• ansible-playbook playbooks/site.yml --limit pve_gpu_hosts --check, danach der echte Lauf. Knoten einzeln neu starten. Prüfung: lspci -nnk -s 01:00.0 auf jedem GPU-Knoten → Kernel driver in use: vfio-pci. Auf pve61: lspci -k -s 00:02.0 → i915.

Task 3.2: Resource Mappings, Template und GPU-VMs

Wo: remote (ops-LXC) · Planner: „GPU-Knoten 3 …“ (Teil NVIDIA, GPU-Container)

• PCI-Resource-Mappings aus sites/knaster/proxmox.yaml anlegen (Namen aus Task 0.4).
• Ubuntu-24.04-Cloud-Template vmid 9000 auf jedem GPU-Knoten.
• tofu plan und dann tofu apply für gpu-pve44, gpu-pve46 und gpu-pve52: alle Karten des Knotens, 12 GB RAM, 4 Kerne, Systemplatte 40 GB und Modellplatte 60 GB auf local-zfs, IPs aus D5.
• ansible-playbook … --limit gpu_vms (Rollen docker-host und gpu-node, driver_generation: legacy = R580). Prüfung in jeder VM: nvidia-smi -L → beide Karten. docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu24.04 nvidia-smi → beide Karten.

Task 3.3: Benchmark-Tag (fasst drei Pläne zusammen)

Wo: remote, Strommessung vor Ort (Messgerät an der Steckdose) · Planner: „GPU-Knoten 4: Geschwindigkeitstests (Gate) auf M4000 und P2000“ · ersetzt außerdem den „Benchmark-Tag“ aus IMPLEMENTATION und den Gate-Task 1 des nex-STT-Plans

• llama-bench je Kartentyp: Embedding-Modell, 3–4B Q4 (verifier/signature), 7B Q4. Tokens/s und VRAM messen.
• whisper.cpp large-v3-turbo, Sprache de: Sekunden je 10 s Diktat auf M4000 und P2000. Klärt, ob CC 5.2 überhaupt rechnet. Zusätzlich die Dialekt-Testsätze.
• knaster bench tts (Piper, CPU).
• Strom je Knoten: Leerlauf und Volllast beider Karten (400-W-Netzteil, erwartet etwa 300 W).
• Ergebnis eintragen in catalog/models.yaml und sites/knaster/registry.yaml, in ADR-0006 „M4000 wieder aufnehmen ja/nein“ und in die STT-Entscheidung D131/D133 (nex). Commit. Prüfung: make validate → PASS, Placement ordnet jede aktive Rolle einer gemessenen Karte zu.

---

Phase 4 – Cluster-Grundkonfiguration (erst wenn alle Knoten drin sind)

Wo: remote. Jede Aufgabe hier entspricht einer Planner-Aufgabe.

• 4.1 Benutzer und Token („PVE-Config: Persönlicher Admin-Benutzer, Rollen und API-Token anlegen“): Admin-Benutzer und Gruppe, root@pam nur als Notfallzugang. Token monitoring@pve!prom (PVEAuditor), healer@pve!knaster (nur VM.PowerMgmt auf GPU-VMs, PLAN §3), tofu@pve!ops.
• 4.2 2FA („PVE-Config: Zwei-Faktor-Authentifizierung für Admin-Konten aktivieren“): TOTP für root@pam und Admin. Recovery-Keys offline ablegen.
• 4.3 Benachrichtigungen („PVE-Config: Benachrichtigungen (Notification Center) einrichten“): SMTP-Ziel Büro-Postfach, Matcher für Backup, Fencing und Updates. Testnachricht kommt an.
• 4.4 Firewall („PVE-Config: Firewall auf Datacenter- und Knotenebene einrichten“): IP-Set admin (Laptop) und appsrv08 (.29). Zuerst Allow-Regeln für 8006, 22 und ICMP, dann aktivieren. Konsole als Rückfall bereithalten. Prüfung: Weboberfläche vom Laptop ok, von einem anderen Rechner gesperrt.
• 4.5 Ordnung („PVE-Config: Ressourcenpools und Tags festlegen“, „PVE-Config: Standard für neue LXC-Container festlegen“): Pools infra, gpu, test. Tags gpu, infra, test. LXC-Standard: unprivilegiert, Debian-13-Vorlage, Nesting nur für Docker.
• 4.6 Zertifikat („PVE-Config: Web-GUI-Zertifikat festlegen (niedrige Priorität)“): /etc/pve/pve-root-ca.pem auf dem Laptop als vertrauenswürdig importieren.
• 4.7 Update-Routine („PVE-Config: Update- und Neustart-Routine festlegen (rollierend, Knoten für Knoten)“): Ablauf in docs/BETRIEB.md eintragen (Wartungsmodus, ein Knoten nach dem anderen, GPU-VMs vorher sauber stoppen).

---

Phase 5 – Backup und Monitoring

Task 5.1: Proxmox Backup Server

Wo: remote, Speicherort vor Ort · Planner: „Proxmox: Backup-System überlegen“ (beantwortet PLAN §9, offener Punkt 6)

• Ziel-Speicher entscheiden. Empfehlung: externer Datenträger oder NAS, nicht die Toshiba-Platte „BACKUP“ des Nutzers. PBS als VM pbs (vmid 110), Datastore auf dem Ziel.
• Jobs: nächtlich Infra-LXC, ops-LXC und GPU-VMs (ohne Modellplatte), Aufbewahrung 7 Tage, 4 Wochen und 6 Monate. Dazu ein wöchentlicher Verify-Job.
• Restore-Test: Infra-LXC als Kopie zurückspielen. Prüfung: Die Kopie startet, docker ps zeigt die Dienste.

Task 5.2: Infra-LXC mit Monitoring (ein Stack)

Wo: remote · Planner: „Proxmox: Grafana-Dashboard für den Cluster“, „PVE-Config: Verfügbarkeits-Monitoring und Log-Kontrolle ergänzen“ · Files: Modify deploy/compose/infra/docker-compose.yml, deploy/prometheus/prometheus.yml

• deploy/compose/infra ohne den Dienst litellm (D4). Router zeigt auf http://192.168.100.29:<LiteLLM-Port>. Image-Tags pinnen (offener Punkt aus IMPLEMENTATION).
• LXC infra (vmid 101, Nesting, 4 Kerne, 12 GB) mit HA und Replikation (Task 2.2). Compose mit KNASTER_DRY_RUN=true.
• Prometheus-Ziele: pve-exporter (Token aus 4.1), node-exporter und nvidia_gpu_exporter in den GPU-VMs, Router.
• Grafana: Dashboards für Proxmox, Knoten, GPU (Community-JSON) und knaster. Konto kiosk mit Rolle Viewer.
• Alertmanager an den Router (Healer, Dry-Run) und an n8n knaster-notify. Der Workflow wird inaktiv importiert, dann aktiviert. Prüfung: Grafana zeigt alle 5 Knoten und alle GPUs. Ein Test-Alert (amtool alert add test) erscheint im Kanal.

Task 5.3: Kiosk auf pve61

Wo: remote, Abnahme vor Ort · Planner: „Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk“

• Empfehlung: minimaler Kiosk direkt auf dem Host (cage + chromium als eigener Benutzer, systemd-Dienst, Bildschirmschoner aus). Das ist eine bewusste kleine Ausnahme von „Container zuerst“, weil ein Kiosk Bildschirm und Eingabe des Geräts braucht.
• URL: Grafana-Playlist im Kiosk-Modus mit Konto kiosk. Prüfung: Nach einem Neustart von pve61 zeigt der Bildschirm ohne Eingriff das Dashboard.

---

Phase 6 – Data Plane

Ersetzt PLAN §8 „1 Data Plane“.

• 6.1 GPU-Rollen: deploy/compose/gpu-llamacpp in den GPU-VMs nach der Zuordnung aus Task 3.3, also Embedding und Rerank redundant auf zwei Knoten, Chat für verifier und signature. Prüfung: Canary-Checks grün (knaster Canary-Prober).
• 6.2 STT (nex-STT-Plan Tasks 2–4): whisper-server als zusätzlicher Dienst in der GPU-VM des in Task 3.3 gewählten Knotens. Neuer Slot stt-de im Katalog. Port 8178 nur von 192.168.100.29 (Firewall der VM bzw. des Gasts). Prüfung: Von appsrv08 liefert curl -F file=@probe.wav http://<IP>:8178/v1/audio/transcriptions deutschen Text, von einem anderen Rechner wird der Zugriff abgelehnt.
• 6.3 Lokale Slots in LiteLLM (D4): embed-default, rerank-default, verifier-small und signature-extractor als Modelle im LiteLLM auf appsrv08 eintragen (IP-Literale). Prüfung: curl http://192.168.100.29:<port>/v1/models listet die Slots, ein Aufruf je Slot antwortet.
• 6.4 Ada-Worker (D3) · Planner: „LLM-Worker: direkte Inferenz-Schnittstelle für LiteLLM (zusätzlich zum Job-Poll), Tunnel, Registry, Fallback-Kette“
  • Offene Schritte der Worker-Registry v2 im Repo mygodel/nex abschließen.
  • Gefilterte Ports auf GODE-PC-05/06 freigeben (nex-STT-Plan, Anhang A).
  • Im knaster-Router engine: worker-registry umsetzen: GET /webhook/llm-worker-list lesen und einen Worker wählen, der online ist; sonst Eskalation auf tier0.
  • Tests in core/tests/test_router.py:
    • test_worker_registry_slot_uses_online_worker
    • test_worker_registry_slot_falls_back_to_tier0_when_list_empty
    • test_worker_registry_slot_falls_back_when_list_unreachable
  • Prüfung: make test PASS. Live tagsüber geht eine tier1-Anfrage an tier0, nachts an GODE-PC-05.

---

Phase 7 – Kernpfad

Ersetzt PLAN §8 „2 Kernpfad“.

• n8n-Workflows knaster-request, knaster-jobs und knaster-service-routine inaktiv importieren und Credentials setzen (n8n/README.md).
• Ende-zu-Ende: Eine Anfrage läuft über Router, Verifier und Eskalation über den PSE-LiteLLM. Die Dry-Run-Woche beginnt.
• Nex-STT-Plan Tasks 5–8: Hermes-Overlay stt.openai.base_url mit IP-Literal, Rückfall auf CPU, Abnahme.
• Offen und hier zu entscheiden: Langfuse (PLAN §2.4) steht nicht im Infra-Compose.

Phase 8 – GRP als Testdienst

Planner: „Proxmox: GRP als Testservice in einen LXC-Container umziehen“ · Voraussetzung: PBS (Task 5.1)

• LXC grp-test (Pool test, Docker) mit einer Kopie der GRP-Daten von appsrv08. Die Produktion bleibt unangetastet. Feste IP aus D5, Zugriff nur intern. Prüfung: Die Testinstanz läuft, das Backup des Containers ist im PBS sichtbar.

Phase 9 – knaster-Ausbau (eigene Pläne folgen)

Die Software-Phasen aus PLAN §8 bleiben inhaltlich gültig und bekommen jeweils einen eigenen Plan:

• „3 Skills“: Hermes als Skill-Autor
• „4 Robustheit“: Healer live, Aktionen einzeln freischalten
• „5 Lifecycle“: QLoRA-Training. Voraussetzung ist die Entscheidung über WSL2 bzw. vLLM auf den Ada-Rechnern nachts (D3, Folgeentscheidung).
• „6 Portabilität“

Am Ende von Phase 9 wird das Betriebshandbuch abgeschlossen („PVE-Config: Betriebshandbuch und Testvorgehen anlegen“). Das geschieht als Erweiterung von docs/BETRIEB.md, nicht als neues Dokument.

---

Parallelspur NEX (ohne Cluster-Bezug, nach Dringlichkeit)

#	Planner-Aufgabe	Warum jetzt
P1	LiteLLM Swarm: PSE-Fix ausrollen (Klartext-Abfluss)	Datenschutz-Leck; Voraussetzung für D4
P2	NEX: Startpasswort astreit ändern	Passwort lag lesbar in S:\IT\Nex
P3	NEX aufräumen: Testinstanz, Schlüsseldateien	ca.key liegt ungeschützt
P4	NEX: Gitea/Portainer-Schritte für Port je Agent und Registry (Teil 1 der Checkliste)	blockiert nex-admin
P5	nex-admin 1: eigene Tokens anlegen und Stack nex deployen → nex-admin 2 → nex-admin 3 → nex-admin 4	in dieser Reihenfolge
P6	NEX - Admin Mail in n8n anlegen und Wächter-Mail testen	nach nex-admin 1
P7	Arbeitsplatz-Setup-Skript am eigenen PC testen	unabhängig
P8	NEX Websuche: eigenes SearXNG im Stack nex	unabhängig

---

Zuordnung Epic 7 → Plan (Duplikate zusammengeführt)

Planner-Aufgabe (exakter Titel)	Im Plan	Planner-Aktion nach Freigabe
Proxmox: pve48 root-Passwort klären und SSH-Schlüssel nachtragen	Task 0.1	bleibt
PVE-Config: Netzwerk prüfen – Bridge, VLAN-Fähigkeit und NIC-Kompatibilität	Task 0.2 (D5), VLAN später	bleibt, Beschreibung ergänzen
Proxmox: Konfiguration aller Knoten durcharbeiten	aufgeteilt auf 0.1, 1.1–1.3	schließen mit Verweis auf diesen Plan
PVE-Config: Erst-Update aller Knoten (apt full-upgrade)	Task 1.1	bleibt
Proxmox: Speicher aller Knoten richtig konfigurieren	D1, Task 1.2	bleibt
PVE-Config: RAM-Planung je Knoten (Host-Reserve, ZFS-ARC, KSM, Swap)	Task 1.2 (ARC), Task 3.2 (VM-RAM)	zusammengeführt in „Speicher …“, schließen
GPU-Knoten 3: Cluster mit QDevice (Container auf appsrv08), NVIDIA-Treiber, GPU-Container	Tasks 2.1, 2.2, 3.1, 3.2	bleibt (Titel unverändert), Beschreibung: kein QDevice, GPU als VM
GPU-Knoten 4: Geschwindigkeitstests (Gate) auf M4000 und P2000	Task 3.3 (mit knaster-Benchmark-Tag und STT-Gate)	bleibt, Beschreibung ergänzen
PVE-Config: Persönlicher Admin-Benutzer, Rollen und API-Token anlegen	4.1	bleibt
PVE-Config: Zwei-Faktor-Authentifizierung für Admin-Konten aktivieren	4.2	bleibt
PVE-Config: Benachrichtigungen (Notification Center) einrichten	4.3	bleibt
PVE-Config: Firewall auf Datacenter- und Knotenebene einrichten	4.4	bleibt
PVE-Config: Ressourcenpools und Tags festlegen	4.5	bleibt
PVE-Config: Standard für neue LXC-Container festlegen	4.5	zusammengeführt in „Ressourcenpools …“, schließen
PVE-Config: Web-GUI-Zertifikat festlegen (niedrige Priorität)	4.6	bleibt
PVE-Config: Update- und Neustart-Routine festlegen (rollierend, Knoten für Knoten)	4.7	bleibt
Proxmox: Backup-System überlegen	Task 5.1	bleibt
Proxmox: Grafana-Dashboard für den Cluster	Task 5.2 (knaster-Stack statt InfluxDB)	bleibt, Beschreibung ändern
PVE-Config: Verfügbarkeits-Monitoring und Log-Kontrolle ergänzen	Task 5.2 (Alertmanager, Healer)	zusammengeführt in „Grafana-Dashboard …“, schließen
Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk	Tasks 1.3, 5.3	bleibt
LLM-Worker: direkte Inferenz-Schnittstelle für LiteLLM (zusätzlich zum Job-Poll), Tunnel, Registry, Fallback-Kette	Task 6.4	bleibt, Beschreibung: Registry v2 + knaster-Brücke
Proxmox: GRP als Testservice in einen LXC-Container umziehen	Phase 8	bleibt
PVE-Config: Betriebshandbuch und Testvorgehen anlegen	Phase 9 (docs/BETRIEB.md)	bleibt
P1–P8 (NEX-Aufgaben)	Parallelspur	bleiben

Neu anzulegen (nach Freigabe): „knaster: Entscheidungen D1–D5 bestätigen“ (0.3), „knaster: Site-Dateien an echte Hardware“ (0.4), „knaster: Cluster bilden“ (2.1/2.2), „knaster: GPU-VMs und Resource Mappings“ (3.1/3.2), „knaster: Infra-LXC mit Monitoring“ (5.2), „knaster: STT-Dienst whisper-server“ (6.2), „knaster: lokale Slots in LiteLLM“ (6.3), „knaster: Kernpfad Ende-zu-Ende“ (Phase 7).

Zuordnung der knaster-Roadmap (PLAN §8): 0 Fundament → Phasen 0–5 · 1 Data Plane → Phase 6 · 2 Kernpfad → Phase 7 · 3–6 → Phase 9.

Zuordnung nex-STT-Plan: Task 0 erledigt · Task 1 → 3.3 · Tasks 2–4 → 6.2 · Tasks 5–8 → Phase 7.