rorapp/cluster-knaster
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
cbc41e9e67c1835199a8ce919a0e372688272117
cluster-knaster/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md
T
Robert RappandClaude Opus 5.5 cbc41e9e67
ci / test (push) Successful in 27s
Details
docs(plan): Ada-Worker je eine RTX 4000 Ada (20 GB) laut mygodel/scripts 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 16:05:02 +02:00

36 KiB
Raw Blame History

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 ThinkStation P310, i7-6700, 32 GB 3 Platten (SanDisk): sda 256 GB Proxmox, sdb 256 GB altes Windows, 220 GB belegt, sdc 128 GB Windows 10, 101 GB belegt M4000 + P2000 bootet Legacy statt UEFI
pve52 192.168.100.207 ThinkStation P320, i7-7700, 32 GB 2× 256 GB (sdb: altes Windows, BitLocker „GODEL55“) nur M4000 (keine P2000 verbaut) –
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.

Aufteilung der Systemplatte (per SSH geprüft, auf allen fünf Knoten gleich, alles noch leer): 69 GB local (System, ISOs, Vorlagen, lokale Backups), 141 GB local-lvm (Platten der VMs und Container), 8 GB Swap, 16 GB frei in der Volume Group. SMART: alle Platten PASSED. Samsung-SSDs (pve44, pve52) zu 3–17 % verschlissen, Surface-NVMe (pve61) zu 46 %. Bei der SanDisk in pve46 steht der Rohwert für umgelagerte Sektoren auf 100; der Wert wird überwacht. 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: zwei Geräte mit je einer Karte (Nutzer, 12.10.: „A4000“). Laut Repo mygodel/scripts ist es die RTX 4000 Ada mit 20 GB: nvidia-smi meldet 20475 MiB (tests/LocalLLMWorker.Tests.ps1). Eine RTX A4000 (Ampere) hätte 16 GB. Auf GODE-PC-06 läuft llama-server (CUDA, Port 8080) mit Qwen3.8-27B-IQ4-MIX (rund 15 GB), 32K Kontext, alle Layer auf der GPU, Stufe expert (start-llama-server.ps1). Job NEX-1 lief dort in 102 s erfolgreich. Das Repo-Inventar von cluster-knaster nahm zwei Karten in einem Gerät an; das wird in Task 0.4 korrigiert. Windows, tagsüber Arbeitsplätze, 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 B – keine Neuinstallation: Die System-SSD bleibt, wie sie ist. Die zweite SSD wird remote per SSH zum ZFS-Pool tank (pve44, pve48, pve52). pve46 und pve61 bleiben ohne ZFS. Kein Einsatz vor Ort, und es bleibt mehr Platz für Gäste: 141 GB local-lvm plus 238 GB tank statt rund 200 GB auf einem Spiegel aus zwei 256-GB-Platten. Spiegeln ließe sich nur auf pve44, pve48 und pve52, pve46 und pve61 haben eine einzige Platte. Das entspricht dem ursprünglichen ADR-0002 („SSD 1 System, SSD 2+ tank“). Replikation und HA laufen zwischen pve44, pve48 und pve52. Ohne ZFS bleiben nur pve46 (GPU-VM und ops, beide brauchen kein HA) und pve61 (Kiosk). Fällt eine System-SSD aus, wird dieser Knoten neu installiert; die Gäste sind repliziert. A – Neuinstallation mit ZFS (vor Ort, USB-Stick, Monitor, Tastatur): RAID1 auf Knoten mit zwei SSDs, local-zfs überall, Systemplatte gespiegelt, pve46 auf UEFI. Lässt sich später je Knoten nachholen.
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.

RAM-Budget je Knoten

Bei einem Knoten mit 32 GB sind 6 GB fest belegt: 2 GB für den Host und 4 GB ZFS-ARC. Eine GPU-VM reserviert ihre 12 GB vollständig, Passthrough erlaubt kein Ballooning. Damit bleiben auf einem GPU-Knoten 14 GB für Container und als Reserve für den Failover.

pve48 hat laut Inventar vom 12.10. M4000 und P2000 und ist damit der vierte GPU-Knoten. Im Einsatz sind insgesamt 4× M4000 und 3× P2000; pve52 hat nur die M4000.

Gast RAM Knoten
gpu-pve44, gpu-pve46, gpu-pve48, gpu-pve52 je 12 GB, fest auf dem eigenen Knoten
infra (LXC) 8 GB pve44 auf tank, Replikation nach pve52 und pve48
ops (LXC) 1 GB pve46 (kein HA nötig, per Ansible neu aufsetzbar)
pbs (VM) 4 GB pve52
grp-test (LXC) 4 GB pve48 auf tank, Replikation nach pve44
pve61 8 GB gesamt keine Gäste, nur Kiosk

Regeln:

  • Die Summe der Gäste je Knoten bleibt bei höchstens 26 GB (32 − 6).
  • Das Replikationsziel von infra hat immer mindestens 8 GB frei, sonst scheitert der HA-Neustart still.
  • Prüfung nach jedem neuen Gast: pvesh get /nodes/<knoten>/status --output-format json | jq .memory.

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: Richtiges Passwort in .env (PVE48_PASS) eingetragen (12.10., der alte Wert war falsch).
  • b: Schlüssel verteilt (push_keys.py pve48), Paketquellen auf pve-no-subscription umgestellt (Sicherung /root/apt-backup-2026-10-12/, 184 Updates offen, kein Upgrade). Prüfung: ssh -o BatchMode=yes pve48 hostname → pve48.
  • c: Inventar pve48 (12.10.): P310, i7-6700, 32 GB, Legacy-Boot, VT-d aktiv, M4000 in Gruppe 1, P2000 in Gruppe 8, 1 GbE, Wake-on-LAN g, SMART aller drei Platten PASSED. Eingetragen in Ausgangslage und healthcheck-2026-10-08.txt.
  • d: pve52 hat nur die M4000, eine P2000 ist dort nicht verbaut (Nutzer, 12.10.). Es sind 3× P2000 im Einsatz (pve44, pve46, pve48).
  • d2: Verbleib von Godel45 klären (im STT-Plan aufgeführt).
  • e: Ada-Rechner GODE-PC-05/06: je Gerät eine Karte (Nutzer, 12.10.), laut Repo mygodel/scripts RTX 4000 Ada mit 20 GB. Offen ist nur die Bestätigung je Gerät über den Heartbeat der Worker-Registry v2 (vramGB 20 = RTX 4000 Ada, 16 = RTX A4000) oder nvidia-smi -L.

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). Ebenso eine Reservierung für den Admin-Laptop (heute .151 per WLAN). Die Firewall in 4.4 lässt nur diese Adresse zu, ein Lease-Wechsel würde sonst aussperren.
  • 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 entschieden (12.10.): Variante B, keine Neuinstallation. Alle alten Windows-Platten werden für den Cluster vollständig gelöscht.
  • D1-Freigabe zum Löschen: Der Nutzer prüft die alten Windows-Platten zuerst (pve44 sdb NTFS, pve52 sdb BitLocker „GODEL55“, pve48 sdb mit 220 GB und sdc mit 101 GB belegt). Gelöscht wird erst nach seinem ausdrücklichen „Freigabe“.
  • 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: Proxmox-Knoten pve44, pve46, pve48, pve52, pve61, dazu die Inventar-Knoten gode-pc-05 und gode-pc-06 (Ada, ohne Proxmox, nur im Inventar). PCI-Mappings gpu-m4000-pve44, gpu-p2000-pve44, gpu-m4000-pve46, gpu-p2000-pve46, gpu-m4000-pve52, gpu-m4000-pve48, gpu-p2000-pve48. GPU-VMs gpu-pve44 (vmid 244), gpu-pve46 (246), gpu-pve48 (248), 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, gode-pc-05, gode-pc-06}.
    • proxmox.yaml enthält keine IP aus 10.20.0.0/24.
    • Jedes pci_mappings[*].node und jedes vms[*].node liegt in {pve44, pve46, pve48, pve52}.

  • 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.3). Die Ada-Slots (tier1-general, tier1-flex, tts-de-hq) behalten vorerst ihre Engine. In registry.yaml entfallen bei ihnen nur pve_node und vmid. Die Umstellung auf die Worker-Registry folgt in 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: Speicher (D1)

Planner: „Proxmox: Speicher aller Knoten richtig konfigurieren“ (enthält die frühere Aufgabe zur RAM-Planung)

Variante B (Empfehlung) – remote, ohne Neuinstallation

  • Freigabe aus Task 0.3 liegt vor. Dann auf pve44, pve48 und pve52: Partitionen von sdb mit wipefs -a /dev/disk/by-id/<ssd2> entfernen, danach zpool create -o ashift=12 -O compression=lz4 -O atime=off tank /dev/disk/by-id/<ssd2> und pvesm add zfspool tank --pool tank --content images,rootdir --nodes pve44,pve48,pve52. Auf pve48 bleibt sdc unberührt. Das Löschen ist nicht umkehrbar. Vorher lsblk -o NAME,SIZE,FSTYPE,LABEL /dev/sdb prüfen: Es muss die freigegebene Windows-Platte sein, nie sda.
  • ZFS-ARC auf 4 GiB begrenzen (/etc/modprobe.d/zfs.conf, update-initramfs -u, wirksam beim nächsten Neustart). Prüfung: zpool status tank → ONLINE. pvesm status → tank active auf beiden Knoten.

Variante A – Neuinstallation mit ZFS

Wo: vor Ort, USB-Stick mit PVE 9.2 (ISO und Prüfsumme in C:\Users\r.rapp\it\proxmox)

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. Installer: gleicher Hostname und gleiche IP wie bisher, ZFS (RAID1) bzw. ZFS (RAID0) bei einer Platte, ashift=12, compress=on.
  • Prüfpunkt iGPU (GPU-Knoten): Im BIOS die Onboard-Grafik als primäre Anzeige einstellen und den Monitor ans Mainboard anschließen. Prüfung: Die Proxmox-Konsole erscheint am Mainboard-Anschluss. Rückfall, falls das BIOS die iGPU bei eingesteckter Karte abschaltet: die P2000 in Steckplatz 1 und die M4000 in Steckplatz 2 tauschen. Die Boot-Grafik ist dann die P2000; für sie gilt beim Passthrough in Task 3.2 x-vga/ROM-Prüfung.
  • Neues root-Passwort trägt der Nutzer vor dem nächsten Schritt in .env ein (PVExx_PASS), sonst scheitert das Bootstrap-Skript.
  • 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, pve48, pve52). pve61 steht in pve_kiosk ohne VFIO und Blacklist.
  • Rolle pve-host ergänzen: /etc/modprobe.d/vfio.conf mit options vfio-pci ids=<liste> und softdep nvidia pre: vfio-pci. Die Liste enthält die Grafik- und die Audio-Funktionen der Karten. Die IDs aus lspci -nn -s 01:00 und lspci -nn -s 02:00 auf dem Knoten lesen, nicht aus dem Gedächtnis eintragen; bekannt sind bisher nur die VGA-IDs 10de:13f1 und 10de:1c30.
  • 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 und lspci -nnk -s 02:00 auf jedem GPU-Knoten → bei allen Funktionen 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, gpu-pve48 und gpu-pve52: alle Karten des Knotens, 12 GB RAM, 4 Kerne, Systemplatte 40 GB und Modellplatte 60 GB auf local-lvm (Variante B) bzw. local-zfs (Variante A), 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, 8 GB, Knoten laut RAM-Budget) 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 auf dem Swarm (D4 nutzt den schon reparierten LiteLLM auf appsrv08)
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 angelegt (nur Schritte ohne bestehende Aufgabe, keine Duplikate):

  • „knaster: Entscheidungen D1–D5 bestätigen“ (0.3)
  • „knaster: Site-Dateien und ADRs an echte Hardware anpassen“ (0.4)
  • „knaster: GPU-Dienste (llama.cpp) in den GPU-VMs“ (6.1)
  • „knaster: STT-Dienst whisper-server im Haus“ (6.2)
  • „knaster: lokale Slots im LiteLLM auf appsrv08“ (6.3)
  • „knaster: Kernpfad Ende-zu-Ende im Dry-Run“ (Phase 7)

Cluster und GPU-VMs laufen über „GPU-Knoten 3“, der Infra-LXC über „Proxmox: Grafana-Dashboard für den Cluster“.

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.

Reference in New Issue View Git Blame Copy Permalink