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 6b6dc8a..6356fd8 100644 --- a/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md +++ b/docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md @@ -75,7 +75,7 @@ Außerhalb des Clusters: ## Was hängt woran (Stand 12.10.) -Die Speicherfreigabe (D1) blockiert nur wenig. D2 ist entschieden (12.10.). D5 ist zurückgestellt: Gäste starten mit DHCP; feste IPs müssen vor Phase 6 stehen, weil STT und die LiteLLM-Slots IP-Literale nutzen. +Die Speicherfreigabe (D1) liegt seit 12.10. vor, `tank` steht auf pve44, pve48 und pve52; die rechte Spalte ist damit freigeschaltet. D2 ist entschieden (12.10.). D5 ist zurückgestellt: Gäste starten mit DHCP; feste IPs müssen vor Phase 6 stehen, weil STT und die LiteLLM-Slots IP-Literale nutzen. | Sofort möglich | Braucht D2 (entschieden) | Braucht die Speicherfreigabe | |---|---|---| @@ -135,7 +135,7 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins **Wo:** Gespräch mit dem Nutzer - [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“. +- [x] D1-Freigabe zum Löschen (12.10., „festplatten alle platt machen“): pve44 sdb NTFS, pve52 sdb BitLocker „GODEL55“, pve48 sdb und sdc. Alle vier gelöscht (Task 1.2). - [x] D2 entschieden (12.10.): eine GPU-VM pro Knoten. Vorteil, der schon heute greift: Das anstehende Kernel-Update 7.0.2 → 7.0.14 berührt keinen NVIDIA-Treiber. - [ ] D5 zurückgestellt (12.10., „Schritt zwei“): Gäste vorerst per DHCP. Für feste IPs braucht es keinen DNS-Eintrag, sondern einen Ausschluss bzw. Reservierungen im DHCP-Server. Den verwaltet nicht der Nutzer. Dabei auch die Knoten-IPs .207–.214 reservieren lassen (Corosync bindet an sie). - [ ] D3 und D4 bestätigen. Ergebnis als Abschnitt „Entscheidungen 2026-10“ in `docs/PLAN.md` §9 eintragen. @@ -187,10 +187,20 @@ 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, 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 pve44, pve48 und pve52. +- [x] Freigabe aus Task 0.3 liegt vor (12.10.). Auf pve44, pve48 und pve52 die zweite SSD gelöscht und `tank` angelegt. Die Platten wurden nur über ihre Seriennummer angesprochen; vor dem Löschen wurde geprüft, dass sie nicht die Systemplatte, nicht eingehängt und nicht in Benutzung sind: + + | Knoten | `tank` auf | Systemplatte (unberührt) | + |---|---|---| + | pve44 | `ata-SAMSUNG_MZ7LN256HAJQ-000L7_S3S7NY0K403015` | Samsung S20HNAAH271598 | + | pve48 | `ata-SanDisk_SD6SB1M256G1022I_140877401621` | SanDisk 164862429106 | + | pve52 | `ata-SAMSUNG_MZ7LN256HAJQ-000L7_S3S7NY0K403017` | Samsung S3S7NY0K403016 (gleiches Modell, nur die letzte Ziffer unterscheidet sich) | + + Ablauf je Platte: `wipefs -a` (Partitionen, dann Platte), `sgdisk --zap-all`, `blkdiscard`. Danach `zpool create -o ashift=12 -O compression=lz4 -O atime=off tank /dev/disk/by-id/` und `systemctl enable zfs-import@tank.service`. Einmal im Cluster: `pvesm add zfspool tank --pool tank --content images,rootdir --sparse 1 --nodes pve44,pve48,pve52`. + pve48 `sdc` (SanDisk 128 GB, 140621401586) ist ebenfalls gelöscht und bleibt vorerst ungenutzt. Als Stripe in `tank` würde sie das Ausfallrisiko verdoppeln. +- [x] ZFS-ARC auf 4 GiB begrenzt: `/etc/modprobe.d/zfs.conf`, `update-initramfs -u -k all`, zusätzlich sofort über `/sys/module/zfs/parameters/zfs_arc_max`. + Prüfung 12.10.: `zpool status tank` → `ONLINE` auf allen drei Knoten. `pvesm status` → `tank active` auf pve44, pve48 und pve52 (auf pve46 und pve61 `disabled`, wie gewollt). +- [x] Neustart-Probe (12.10.): pve48 (Legacy-BIOS) und pve44 (UEFI) neu gestartet. Beide starten von `sda`, `tank` wird importiert (`ONLINE`, `pvesm` active), ARC = `4294967296`, keine fehlgeschlagenen Dienste, GPU-Stand unverändert, Quorum 5/5. +- [ ] Nebenbefund pve44: Die EFI-Partition `sda2` ist nicht unter `/boot/efi` eingehängt (kein Eintrag in `/etc/fstab`). Der Start klappt, aber GRUB-Updates erreichen die EFI-Partition nicht. Eintrag `UUID=BB96-13D2 /boot/efi vfat defaults 0 1` nachtragen, `grub-install` prüfen. Die alten Windows-Starteinträge im UEFI (pve44 `Boot000E`, pve52 `Boot000D`) zeigen ins Leere und können mit `efibootmgr -b -B` entfernt werden. **Variante A – Neuinstallation mit ZFS**