From f7ff7e8eabfca253d8dd3586e233b5e102b7941c Mon Sep 17 00:00:00 2001 From: Robert Rapp Date: Mon, 12 Oct 2026 12:51:59 +0200 Subject: [PATCH] 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.