rorapp/cluster-knaster
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(plan): Platten-Bestandsaufnahme vom 12.10. eintragen, Platzangaben in D1 und Task 3.2 korrigieren

Browse Source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Robert Rapp
2026-10-12 14:12:37 +02:00
co-authored by Claude Opus 5.5
parent f7ff7e8eab
commit c3020eafa8
1 changed files with 5 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md
+5 -3
View File
@@ -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) | – | | 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 | | 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: 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:** 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 | | # | 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. | | **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. | | **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. | | **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). - [ ] 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. - [ ] 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). - [ ] `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. 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.