From a7da3c1096d428b70251d6417389e2742e01c673 Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Mon, 12 Oct 2026 12:03:49 +0200 Subject: [PATCH 1/9] =?UTF-8?q?docs:=20Aufbauplan=20auf=20echter=20Hardwar?= =?UTF-8?q?e,=20zusammengef=C3=BChrt=20mit=20Planner=20Epic=207?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Chronologischer Plan (Phasen 0-9) für pve44/46/48/52/61 mit Entscheidungen D1-D5 (ZFS, GPU-VM pro Knoten, Ada unter Windows, ein LiteLLM mit PSE, IP-Plan), Duplikat-Zuordnung zu Epic 7 und Parallelspur NEX. PLAN §8 und IMPLEMENTATION "Gemeinsames Deployment" als abgelöst markiert. Co-Authored-By: Claude Opus 5.5 --- README.md | 3 +- docs/IMPLEMENTATION.md | 2 + docs/PLAN.md | 2 + .../2026-10-12-aufbau-cluster-knaster.md | 362 ++++++++++++++++++ 4 files changed, 368 insertions(+), 1 deletion(-) create mode 100644 docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md diff --git a/README.md b/README.md index ff0db42..27d4d4d 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,8 @@ Anfrage → n8n → Router-Service ──▶ Stufe 3 Embedding-Classifier (CPU) | [docs/PLAN.md](docs/PLAN.md) | Architektur und Betrieb: Proxmox, Pflege, Autohealing, Lifecycle, Finetuning, Problemerkennung, Portabilität | | [docs/adr/](docs/adr/) | Architekturentscheidungen | | [docs/spec/](docs/spec/) | Spezifikationen der Komponenten | -| [docs/IMPLEMENTATION.md](docs/IMPLEMENTATION.md) | Arbeitspakete, Teststrategie, Stand der Verifikation, Ablauf des Deployments | +| [docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md](docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md) | **Aufbauplan auf echter Hardware**: Phasen, Entscheidungen D1–D5, Zuordnung zu Planner Epic 7 | +| [docs/IMPLEMENTATION.md](docs/IMPLEMENTATION.md) | Arbeitspakete, Teststrategie, Stand der Verifikation | | [docs/BETRIEB.md](docs/BETRIEB.md) | Skill-Lebenszyklus, Rolle von Hermes, Pflege per Prompt, Dry-Run aufheben, Rollback | | [n8n/README.md](n8n/README.md) | Workflows und Import | | [platform/proxmox/README.md](platform/proxmox/README.md) | Proxmox-Ablauf (OpenTofu + Ansible) | diff --git a/docs/IMPLEMENTATION.md b/docs/IMPLEMENTATION.md index 44eb8dc..033ee92 100644 --- a/docs/IMPLEMENTATION.md +++ b/docs/IMPLEMENTATION.md @@ -49,6 +49,8 @@ Vorgehen pro Baustein: **Spec → Implementierung → Tests → Commit**. Bis zu ## Gemeinsames Deployment (später) +> **Abgelöst** durch [docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md](superpowers/plans/2026-10-12-aufbau-cluster-knaster.md). Dort steht der Ablauf auf der echten Hardware, zusammengeführt mit Planner Epic 7. Die Liste unten bleibt nur zur Nachvollziehbarkeit stehen. + 1. Inventarlauf auf allen Nodes → `sites/knaster/inventory.yaml` ergänzen → `knaster placement plan` 2. Proxmox: ZFS-Pools, Resource Mappings, Templates (`platform/proxmox`) 3. Infra-LXC: `deploy/compose/infra` mit `KNASTER_DRY_RUN=true` diff --git a/docs/PLAN.md b/docs/PLAN.md index d444337..782dc73 100644 --- a/docs/PLAN.md +++ b/docs/PLAN.md @@ -279,6 +279,8 @@ Die Portabilität beruht also auf den **Daten und der Pipeline**, nicht auf Gewi ## 8. Roadmap +> **Abgelöst** durch [superpowers/plans/2026-10-12-aufbau-cluster-knaster.md](superpowers/plans/2026-10-12-aufbau-cluster-knaster.md). Dort ist der chronologische Ablauf auf der echten Hardware beschrieben, mit den Entscheidungen D1–D5 und der Zuordnung zu Planner Epic 7. Die Tabelle unten bleibt nur zur Nachvollziehbarkeit stehen (Zuordnung: 0 → Phasen 0–5, 1 → 6, 2 → 7, 3–6 → 9). + | Phase | Inhalt | Fertig, wenn … | |---|---|---| | **0 Fundament** | Proxmox-Templates, Resource Mappings, OpenTofu/Ansible, Monitoring-Stack | eine GPU-VM lässt sich per Code neu erzeugen, Grafana zeigt GPU- und Proxmox-Metriken | diff --git a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md new file mode 100644 index 0000000..e135f4c --- /dev/null +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -0,0 +1,362 @@ +# 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 `, idempotent. Ausgabe endet mit `BOOTSTRAP OK ` oder Exit ≠ 0. + +- [ ] **Step 1:** Das Skript (läuft auf dem Laptop, Git-Bash) erledigt Folgendes: + - alten Hostschlüssel mit `ssh-keygen -R ` 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 ` → `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 `. 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:`. 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://: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:/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. From 12a373227eba3aaca39bc4bf5d7522424680f7c1 Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Mon, 12 Oct 2026 12:06:28 +0200 Subject: [PATCH 2/9] =?UTF-8?q?docs(plan):=20RAM-Budget,=20vfio-pci-Bindun?= =?UTF-8?q?g,=20iGPU-Pr=C3=BCfpunkt,=20Laptop-Reservierung,=20Ada-Inventar?= =?UTF-8?q?=20korrigiert?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5.5 --- .../2026-10-12-aufbau-cluster-knaster.md | 45 +++++++++++++++---- 1 file changed, 36 insertions(+), 9 deletions(-) diff --git a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md index e135f4c..22a0c4a 100644 --- a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -31,7 +31,7 @@ Dieser Plan **löst** die Abläufe in `docs/PLAN.md` §8 („Roadmap“) und `do 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`). +- **GODE-PC-05/06:** laut Nutzer zwei Geräte mit vermutlich je einer RTX 4000 Ada (20 GB). Das Repo-Inventar nahm zwei Karten in einem Gerät an, deshalb wird das in Task 0.1 geprüft. 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. @@ -71,6 +71,24 @@ Außerhalb des Clusters: | **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. + +| Gast | RAM | pve48 ohne GPU (Task 0.1) | pve48 mit GPU | +|---|---|---|---| +| `gpu-pve44`, `gpu-pve46`, `gpu-pve52` (ggf. `gpu-pve48`) | je 12 GB, fest | auf dem eigenen Knoten | auf dem eigenen Knoten | +| `infra` (LXC) | 8 GB | pve48, Replikation nach pve44 | pve44, Replikation nach pve52 | +| `ops` (LXC) | 1 GB | pve48 | pve46 | +| `pbs` (VM) | 4 GB | pve48 | pve52 | +| `grp-test` (LXC) | 4 GB | pve48 | pve46 | +| pve61 | 8 GB gesamt | keine Gäste, nur Kiosk | 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//status --output-format json | jq .memory`. + --- ## Phase 0 – Bestandsaufnahme und Repo an die Wirklichkeit anpassen @@ -86,12 +104,13 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins 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). +- [ ] **e:** Ada-Rechner GODE-PC-05/06: Karte und VRAM je Gerät mit `nvidia-smi -L` erfassen, an der Konsole oder über die Worker-Registry. Erwartet wird je Gerät eine Zeile `RTX 4000 Ada Generation`. ### 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). +- [ ] 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. @@ -110,11 +129,14 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins - 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`. +- 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` (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 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.5). Die Ada-Slots zeigen auf `engine: worker-registry` (siehe Task 6.4). +- [ ] **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`. @@ -145,7 +167,11 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins 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`. +- [ ] 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 ` → `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`. @@ -192,8 +218,9 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig. - [ ] 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. +- [ ] Rolle `pve-host` ergänzen: `/etc/modprobe.d/vfio.conf` mit `options vfio-pci ids=` 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.0` auf jedem GPU-Knoten → `Kernel driver in use: vfio-pci`. Auf pve61: `lspci -k -s 00:02.0` → `i915`. + 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 @@ -248,7 +275,7 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig. **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:`. 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`. +- [ ] 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. @@ -315,7 +342,7 @@ Am Ende von Phase 9 wird das Betriebshandbuch abgeschlossen („PVE-Config: Betr | # | Planner-Aufgabe | Warum jetzt | |---|---|---| -| P1 | LiteLLM Swarm: PSE-Fix ausrollen (Klartext-Abfluss) | Datenschutz-Leck; Voraussetzung für D4 | +| 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 | From f7ff7e8eabfca253d8dd3586e233b5e102b7941c Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Mon, 12 Oct 2026 12:51:59 +0200 Subject: [PATCH 3/9] docs(plan): D1 Empfehlung B (ZFS-Pool tank remote, ohne Neuinstallation), Planner-Neuanlagen ohne Duplikate Co-Authored-By: Claude Opus 5.5 --- .../2026-10-12-aufbau-cluster-knaster.md | 29 +++++++++++++++---- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md index 22a0c4a..dfd3b07 100644 --- a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -65,7 +65,7 @@ Außerhalb des Clusters: | # | 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. | +| **D1** | Speicher | **B – keine Neuinstallation:** Die System-SSD bleibt, wie sie ist. Die zweite SSD wird remote per SSH zum ZFS-Pool `tank` (pve44, pve52, ggf. pve48). pve46 und pve61 bleiben ohne ZFS. | Kein Einsatz vor Ort, und es bleibt mehr Platz (256 GB System plus 256 GB `tank` statt 256 GB gespiegelt). Das entspricht dem ursprünglichen ADR-0002 („SSD 1 System, SSD 2+ `tank`“). Replikation und HA für den Infra-LXC laufen zwischen pve44 und pve52. 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. | @@ -78,7 +78,7 @@ Bei einem Knoten mit 32 GB sind 6 GB fest belegt: 2 GB für den Host und 4 GB ZF | Gast | RAM | pve48 ohne GPU (Task 0.1) | pve48 mit GPU | |---|---|---|---| | `gpu-pve44`, `gpu-pve46`, `gpu-pve52` (ggf. `gpu-pve48`) | je 12 GB, fest | auf dem eigenen Knoten | auf dem eigenen Knoten | -| `infra` (LXC) | 8 GB | pve48, Replikation nach pve44 | pve44, Replikation nach pve52 | +| `infra` (LXC) | 8 GB | pve48, Replikation nach pve44 (nur wenn pve48 eine zweite SSD für `tank` hat, sonst wie rechts) | pve44, Replikation nach pve52 | | `ops` (LXC) | 1 GB | pve48 | pve46 | | `pbs` (VM) | 4 GB | pve48 | pve52 | | `grp-test` (LXC) | 4 GB | pve48 | pve46 | @@ -161,9 +161,20 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins - [ ] **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) +### Task 1.2: Speicher (D1) -**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)“ +**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 und pve52 (ggf. pve48): Partitionen von `sdb` mit `wipefs -a /dev/disk/by-id/` entfernen, danach `zpool create -o ashift=12 -O compression=lz4 -O atime=off tank /dev/disk/by-id/` und `pvesm add zfspool tank --pool tank --content images,rootdir --nodes pve44,pve52`. + 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). @@ -382,7 +393,15 @@ Am Ende von Phase 9 wird das Betriebshandbuch abgeschlossen („PVE-Config: Betr | 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). +**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. From c3020eafa84ba976ed9c4cd638fdcafdd92c48a0 Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Mon, 12 Oct 2026 14:12:37 +0200 Subject: [PATCH 4/9] docs(plan): Platten-Bestandsaufnahme vom 12.10. eintragen, Platzangaben in D1 und Task 3.2 korrigieren Co-Authored-By: Claude Opus 5.5 --- .../plans/2026-10-12-aufbau-cluster-knaster.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md index dfd3b07..bc8ea5a 100644 --- a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -28,7 +28,9 @@ Dieser Plan **löst** die Abläufe in `docs/PLAN.md` §8 („Roadmap“) und `do | 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. +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 erreichbaren 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:** laut Nutzer zwei Geräte mit vermutlich je einer RTX 4000 Ada (20 GB). Das Repo-Inventar nahm zwei Karten in einem Gerät an, deshalb wird das in Task 0.1 geprüft. Windows, tagsüber Arbeitsplätze, laufen heute schon als LLM-Worker (`LocalLLMWorker.ps1`). @@ -65,7 +67,7 @@ Außerhalb des Clusters: | # | 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, pve52, ggf. pve48). pve46 und pve61 bleiben ohne ZFS. | Kein Einsatz vor Ort, und es bleibt mehr Platz (256 GB System plus 256 GB `tank` statt 256 GB gespiegelt). Das entspricht dem ursprünglichen ADR-0002 („SSD 1 System, SSD 2+ `tank`“). Replikation und HA für den Infra-LXC laufen zwischen pve44 und pve52. 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. | +| **D1** | Speicher | **B – keine Neuinstallation:** Die System-SSD bleibt, wie sie ist. Die zweite SSD wird remote per SSH zum ZFS-Pool `tank` (pve44, pve52, ggf. pve48). 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 lässt sich ohnehin nur auf pve44 und pve52, die übrigen Knoten haben eine einzige Platte. Das entspricht dem ursprünglichen ADR-0002 („SSD 1 System, SSD 2+ `tank`“). Replikation und HA für den Infra-LXC laufen zwischen pve44 und pve52. 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. | @@ -239,7 +241,7 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig. - [ ] 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. +- [ ] `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-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. From 3fdc5815612546b62f514fc42f378a2d5ada6d46 Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Mon, 12 Oct 2026 14:32:27 +0200 Subject: [PATCH 5/9] docs(plan): pve48 inventarisiert (vierter GPU-Knoten, drei Platten), Platzierung und D1 angepasst Co-Authored-By: Claude Opus 5.5 --- .../2026-10-12-aufbau-cluster-knaster.md | 40 ++++++++++--------- 1 file changed, 21 insertions(+), 19 deletions(-) diff --git a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md index bc8ea5a..a2a09bb 100644 --- a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -24,13 +24,13 @@ Dieser Plan **löst** die Abläufe in `docs/PLAN.md` §8 („Roadmap“) und `do |---|---|---|---|---|---| | 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) | +| 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“**) | 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. -Aufteilung der Systemplatte (per SSH geprüft, auf allen erreichbaren 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. +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:** laut Nutzer zwei Geräte mit vermutlich je einer RTX 4000 Ada (20 GB). Das Repo-Inventar nahm zwei Karten in einem Gerät an, deshalb wird das in Task 0.1 geprüft. Windows, tagsüber Arbeitsplätze, laufen heute schon als LLM-Worker (`LocalLLMWorker.ps1`). @@ -67,7 +67,7 @@ Außerhalb des Clusters: | # | 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, pve52, ggf. pve48). 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 lässt sich ohnehin nur auf pve44 und pve52, die übrigen Knoten haben eine einzige Platte. Das entspricht dem ursprünglichen ADR-0002 („SSD 1 System, SSD 2+ `tank`“). Replikation und HA für den Infra-LXC laufen zwischen pve44 und pve52. 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. | +| **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. | @@ -77,14 +77,16 @@ Außerhalb des Clusters: 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. -| Gast | RAM | pve48 ohne GPU (Task 0.1) | pve48 mit GPU | -|---|---|---|---| -| `gpu-pve44`, `gpu-pve46`, `gpu-pve52` (ggf. `gpu-pve48`) | je 12 GB, fest | auf dem eigenen Knoten | auf dem eigenen Knoten | -| `infra` (LXC) | 8 GB | pve48, Replikation nach pve44 (nur wenn pve48 eine zweite SSD für `tank` hat, sonst wie rechts) | pve44, Replikation nach pve52 | -| `ops` (LXC) | 1 GB | pve48 | pve46 | -| `pbs` (VM) | 4 GB | pve48 | pve52 | -| `grp-test` (LXC) | 4 GB | pve48 | pve46 | -| pve61 | 8 GB gesamt | keine Gäste, nur Kiosk | keine Gäste, nur Kiosk | +pve48 hat laut Inventar vom 12.10. M4000 und P2000 und ist damit der vierte GPU-Knoten. + +| 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). @@ -101,10 +103,10 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins **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. +- [x] **a:** Richtiges Passwort in `.env` (`PVE48_PASS`) eingetragen (12.10., der alte Wert war falsch). +- [x] **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:** Gesundheitscheck auf pve48 ausführen und `healthcheck-2026-10-08.txt` ergänzen. Notieren: CPU, RAM, Platten, GPUs, IOMMU-Gruppen. +- [x] **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 (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). - [ ] **e:** Ada-Rechner GODE-PC-05/06: Karte und VRAM je Gerät mit `nvidia-smi -L` erfassen, an der Konsole oder über die Worker-Registry. Erwartet wird je Gerät eine Zeile `RTX 4000 Ada Generation`. @@ -120,7 +122,7 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins **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. +- [ ] D1: Ausdrückliche Freigabe zum Löschen von pve44 sdb (NTFS), pve52 sdb (BitLocker „GODEL55“) und pve48 sdb (altes Windows, 220 GB belegt). pve48 sdc (Windows 10, 101 GB) bleibt vorerst. 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 @@ -131,7 +133,7 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins - 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` (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`. +- 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}`. @@ -169,7 +171,7 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins **Variante B (Empfehlung) – remote, ohne Neuinstallation** -- [ ] Freigabe aus Task 0.3 liegt vor. Dann auf pve44 und pve52 (ggf. pve48): Partitionen von `sdb` mit `wipefs -a /dev/disk/by-id/` entfernen, danach `zpool create -o ashift=12 -O compression=lz4 -O atime=off tank /dev/disk/by-id/` und `pvesm add zfspool tank --pool tank --content images,rootdir --nodes pve44,pve52`. +- [ ] Freigabe aus Task 0.3 liegt vor. Dann auf pve44, pve48 und pve52: Partitionen von `sdb` mit `wipefs -a /dev/disk/by-id/` entfernen, danach `zpool create -o ashift=12 -O compression=lz4 -O atime=off tank /dev/disk/by-id/` 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. @@ -230,7 +232,7 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig. **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. +- [ ] `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=` 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`. @@ -241,7 +243,7 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig. - [ ] 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-lvm` (Variante B) bzw. `local-zfs` (Variante A), IPs aus D5. +- [ ] `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. From d46037272abf8ddf38975be033df1099de5265cf Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Mon, 12 Oct 2026 14:38:26 +0200 Subject: [PATCH 6/9] =?UTF-8?q?docs(plan):=20D1=20als=20Variante=20B=20ent?= =?UTF-8?q?schieden,=20L=C3=B6schfreigabe=20nach=20Pr=C3=BCfung=20der=20Wi?= =?UTF-8?q?ndows-Platten?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5.5 --- docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md index a2a09bb..950fd98 100644 --- a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -122,7 +122,8 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins **Wo:** Gespräch mit dem Nutzer -- [ ] D1: Ausdrückliche Freigabe zum Löschen von pve44 sdb (NTFS), pve52 sdb (BitLocker „GODEL55“) und pve48 sdb (altes Windows, 220 GB belegt). pve48 sdc (Windows 10, 101 GB) bleibt vorerst. Vorher klären, ob Daten oder Recovery-Key gebraucht werden. +- [x] 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 From e9c0c2c9338548896a2a926f03d3e5feaf3f351a Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Mon, 12 Oct 2026 16:03:03 +0200 Subject: [PATCH 7/9] =?UTF-8?q?docs(plan):=20pve52=20nur=20mit=20M4000,=20?= =?UTF-8?q?3=C3=97=20P2000=20im=20Einsatz?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5.5 --- .../superpowers/plans/2026-10-12-aufbau-cluster-knaster.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md index 950fd98..a2b7588 100644 --- a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -25,7 +25,7 @@ Dieser Plan **löst** die Abläufe in `docs/PLAN.md` §8 („Roadmap“) und `do | 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“**) | M4000 (P2000 nicht erkannt) | – | +| 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. @@ -77,7 +77,7 @@ Außerhalb des Clusters: 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. +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 | |---|---|---| @@ -107,7 +107,8 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins - [x] **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`. - [x] **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 (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). +- [x] **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: Karte und VRAM je Gerät mit `nvidia-smi -L` erfassen, an der Konsole oder über die Worker-Registry. Erwartet wird je Gerät eine Zeile `RTX 4000 Ada Generation`. ### Task 0.2: DHCP-Bereich und IP-Plan (D5) From cbc41e9e67c1835199a8ce919a0e372688272117 Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Mon, 12 Oct 2026 16:05:02 +0200 Subject: [PATCH 8/9] docs(plan): Ada-Worker je eine RTX 4000 Ada (20 GB) laut mygodel/scripts Co-Authored-By: Claude Opus 5.5 --- docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md index a2b7588..f785a6a 100644 --- a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -33,7 +33,7 @@ Alle Knoten: PVE 9.2.2, Kernel 7.0.2, **ext4 + LVM-thin auf einer SSD (kein ZFS) 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:** laut Nutzer zwei Geräte mit vermutlich je einer RTX 4000 Ada (20 GB). Das Repo-Inventar nahm zwei Karten in einem Gerät an, deshalb wird das in Task 0.1 geprüft. Windows, tagsüber Arbeitsplätze, laufen heute schon als LLM-Worker (`LocalLLMWorker.ps1`). +- **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. @@ -109,7 +109,7 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins - [x] **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`. - [x] **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: Karte und VRAM je Gerät mit `nvidia-smi -L` erfassen, an der Konsole oder über die Worker-Registry. Erwartet wird je Gerät eine Zeile `RTX 4000 Ada Generation`. +- [ ] **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) From c6b0b4e3805244de88417ef59aa191cd8182a729 Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Mon, 12 Oct 2026 16:08:14 +0200 Subject: [PATCH 9/9] =?UTF-8?q?docs(plan):=20Ada-Worker=20best=C3=A4tigt:?= =?UTF-8?q?=20je=20RTX=204000=20Ada=2020=20GB=20und=2064=20GB=20RAM?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5.5 --- docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md index f785a6a..eb85949 100644 --- a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -33,7 +33,7 @@ Alle Knoten: PVE 9.2.2, Kernel 7.0.2, **ext4 + LVM-thin auf einer SSD (kein ZFS) 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`). +- **GODE-PC-05/06:** zwei Geräte mit je **einer RTX 4000 Ada (20 GB)** und **64 GB RAM** (Nutzer, 12.10.). Die CPU ist noch offen. `nvidia-smi` meldet 20475 MiB (`mygodel/scripts`, `tests/LocalLLMWorker.Tests.ps1`). 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. @@ -109,7 +109,8 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins - [x] **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`. - [x] **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`. +- [x] **e:** Ada-Rechner GODE-PC-05/06: je Gerät eine RTX 4000 Ada (20 GB) und 64 GB RAM (Nutzer, 12.10.). +- [ ] **e2:** CPU der Ada-Rechner erfassen, nebenbei aus dem Heartbeat der Worker-Registry v2 (`cpuCores`) oder mit `Get-CimInstance Win32_Processor`. ### Task 0.2: DHCP-Bereich und IP-Plan (D5)