docs: Ergänzung der Simka Core Server Dokumentation
Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -0,0 +1,202 @@
|
||||
# System-Dokumentation: Simka Core Server
|
||||
|
||||
## 1. Wer oder was ist Simka?
|
||||
**Simka** ist einer der beiden zentralen Pfeiler deiner hochperformanten, selbstgehosteten **Keller-Server-Landschaft** (neben dem zweiten Server *Zora*). Während Zora (dein Minisforum MS-R1 ARM64-Arbeitstier) primär für Core-Dienste und Datenhoheit zuständig ist, fungiert Simka als das eigentliche **Performance- und Rechenzentrum** im Keller.
|
||||
|
||||
### Core-Spezifikationen & Hardware-Zustand (Stand: Mai 2026)
|
||||
* **Architektur:** x86_64 High-Performance Mini-PC / Server.
|
||||
* **Betriebssystem / Hypervisor:** **Proxmox VE 9.2** (aktuell auf Kernel/PVE-Stand 9.2.2).
|
||||
* **Kühlung & Wartung:** Frisch saniert im Mai 2026 mit **ARCTIC MX-7** Wärmeleitpaste auf der CPU und **ARCTIC TP-4** High-Performance Wärmeleitpads für optimale thermische Stabilität unter Volllast.
|
||||
* **Speichermedium:** Ultraschnelle NVMe-SSDs für die lokale Container- und VM-Ausführung.
|
||||
|
||||
### Das anstehende "Monster-Upgrade" (Lieferung bis Ende der Woche)
|
||||
Simka wird in den nächsten Tagen hardwareseitig massiv aufgerüstet, um für lokale KI-Workloads und rechenintensive Pipelines bereitzuhoben:
|
||||
1. **Arbeitsspeicher:** Erweiterung auf **64 GB DDR5 4800Mhz RAM** (maximale Kapazität für massives Multitasking und In-Memory-Datenbanken).
|
||||
2. **Grafikkarte / GPU:** **PNY NVIDIA RTX 2000E Ada Generation**
|
||||
* *Formfaktor:* Single-Slot & Low-Profile (perfekt für kompakte Servergehäuse, zieht Strom rein über den PCIe-Steckplatz).
|
||||
* *Leistung:* Extrem energieeffiziente Ada-Lovelace-Architektur mit maximal **50W TDP** im Peak.
|
||||
* *VRAM:* **16 GB Videospeicher mit ECC-Fehlerkorrektur** – das absolute Fundament für den ausfallsicheren 24/7-Betrieb von lokalen LLMs (Large Language Models).
|
||||
|
||||
---
|
||||
|
||||
## 2. Netzwerk-Konfiguration in der Keller-Landschaft
|
||||
|
||||
Simka ist netzwerktechnisch perfekt redundant und isoliert aufgestellt. Die Kommunikation teilt sich auf zwei dedizierte Leitungen auf:
|
||||
|
||||
```
|
||||
[ Erdgeschoss / Internet ]
|
||||
│ (A1-Router / Fritzbox)
|
||||
▼
|
||||
[ Keller-Switch ]
|
||||
│ │
|
||||
│ (10.0.0.20)
|
||||
│ ▼
|
||||
│ ┌───────────┐
|
||||
│ │ ZORA │◄──────┐
|
||||
│ └───────────┘ │
|
||||
│ (10.0.0.40) │ Der exklusive
|
||||
└──────►┌───────────┐ │ Keller-Highway
|
||||
│ SIMKA │ │ (192.168.99.X)
|
||||
└───────────┘ │ Latenz: ~0.3 ms
|
||||
▲ │
|
||||
└───────────┘
|
||||
```
|
||||
|
||||
### A. Der primäre Uplink (`vmbr0`)
|
||||
* **Physisches Interface:** `nic0`
|
||||
* **Lokale IP:** `10.0.0.40/24`
|
||||
* **Gateway:** `10.0.0.138` (A1-Router / Fritzbox)
|
||||
* **Zweck:** Dieser Port verbindet Simka mit dem Hausnetzwerk und dem Internet. Über diesen Pfad greifst du via **Pangolin-Tunnel** (z. B. unter `https://fotos.mo-home.at`) sicher von außen (Remote von der Arbeit) auf deine Dienste zu.
|
||||
|
||||
### B. Der exklusive "Keller-Highway" (`vmbr1`) – *Neu eingerichtet!*
|
||||
* **Physisches Interface:** `nic1` (Direktverbindung per Standard-Netzwerkkabel zu Zoras Interface `enp49s0`).
|
||||
* **Lokale IP:** `192.168.99.2/24`
|
||||
* **Gateway / DNS:** *Keines* (isoliertes Subnetz).
|
||||
* **Status:** Aktiviert mit **Autostart** bei Boot.
|
||||
* **Performance:** Saubere **0,33 ms Latenz** im Ping-Test, 0% Paketverlust.
|
||||
* **Zweck:** Blitzschnelle, vom restlichen Heimnetzwerk komplett isolierte Direktverbindung zwischen Zora und Simka. Hierüber laufen zukünftig automatisierte Backup-Pipelines, CI/CD-Prozesse und der interne Datenaustausch, ohne das normale LAN oder die Router-CPU zu belasten.
|
||||
|
||||
---
|
||||
|
||||
## 3. Container & Dienste: Wer läuft wo?
|
||||
|
||||
Aktuell ist die Bereitstellung auf Simka modular und ressourceneffizient über Proxmox-Strukturen gelöst. Das Herzstück bildet die frisch migrierte Fotosammlung.
|
||||
|
||||
### LXC-Container: `simka-immich`
|
||||
* **Umgebung:** `/opt/immich`
|
||||
* **Konfiguration:** Docker Compose Stack.
|
||||
* **Dienste im Stack:**
|
||||
* `immich_server`: Das Hauptsystem der App (erreichbar lokal unter `http://10.0.0.40:2283`).
|
||||
* `immich_machine_learning`: Zuständig für Objekterkennung und CLIP-Inferenz.
|
||||
* `immich_postgres`: Die relationale Datenbank (PostgreSQL 14 mit `pgvector`/`vectorchord` Erweiterung).
|
||||
* `immich_redis`: In-Memory-Datenstruktur-Store für Caching und Job-Queues.
|
||||
* **Daten-Zustand:**
|
||||
* **Datenbank:** Erfolgreich importiert aus der `immich-db-backup.sql` (**610 MB** an Metadaten, Pfaden und Strukturen). Die alte, leere Auto-Datenbank wurde zuvor sauber via `dropdb` gelöscht.
|
||||
* **Bilderpool:** Satte **~780 GB an Daten (131.578 Fotos/Videos)** liegen direkt lokal auf Simkas schneller NVMe-SSD.
|
||||
* **Aktueller Betriebsmodus:** Reine **CPU-Ausführung** (x86_64). Die Mitternachts-Jobs und Worker-Anzahlen für Video-Transcoding sind CPU-schonend konfiguriert (max. 1–2 Worker), um den Server bis zum Wochenende nicht zu überlasten.
|
||||
* **Zugriff:** Voll funktionsfähig lokal sowie mobil über die Android-App via Pangolin-Tunnel (Plattform-SSO wurde für den reibungslosen API-Sync der App deaktiviert).
|
||||
|
||||
---
|
||||
|
||||
## 4. Die Roadmap für das kommende Wochenende 🚀
|
||||
|
||||
Sobald die Hardware geliefert wurde, wird Simka schrittweise zum KI-Kraftpaket ausgebaut:
|
||||
|
||||
1. **Hardware-Injektion:** Einbau der 64 GB DDR5 RAM und der NVIDIA RTX 2000E Ada.
|
||||
2. **Die "Simka Core AI" VM:** Erstellung einer dedizierten virtuellen Maschine (z. B. Ubuntu/Fedora Server) in Proxmox.
|
||||
* *PCIe-Passthrough:* Die RTX 2000E wird exklusiv direkt in diese KI-VM durchgereicht.
|
||||
* *LLM-Infrastruktur:* Installation von **Ollama**. Dank der 16 GB ECC-VRAM laden wir dort mächtige Coding-Modelle wie `qwen2.5-coder:7b` (oder quantisierte 14b-Versionen) für blitzschnelle Code-Generierung in deiner IntelliJ-IDE auf deinem Ubuntu-Entwicklungs-PC.
|
||||
3. **Immich-Beschleunigung:** Umstellung des `simka-immich` Docker-Stacks auf GPU-Inferenz. Die 88 Tensor-Kerne der RTX übernehmen dann die Gesichtserkennung und das Video-Transcoding in Millisekunden, wodurch die CPU komplett entlastet wird.
|
||||
4. **CI/CD-Ausbau:** Migration des Gitea-Runners für dein Projekt **Meldestelle** aus der alten VM-Infrastruktur in einen schlanken, nativen LXC-Container auf Simka, der über den 0,3-ms-Highway direkt an dein Gitea auf Zora andockt.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 5. Architektur- und Betriebs-Einschätzung (Ablage)
|
||||
|
||||
🏗️ [Lead Architect]
|
||||
|
||||
### Einschätzung der Architektur
|
||||
- Starker, sinnvoller Plattform-Split: Zora = Core/Control-Plane, Simka = Compute/Throughput. Das entspricht einer sauberen Trennung von „Authority“ und „Acceleration“ und passt zur Desktop-/Offline‑First Strategie der Meldestelle.
|
||||
- Netzwerk-Topologie mit dediziertem „Keller-Highway“ (vmbr1, 192.168.99.0/24) ist genau richtig für Replikation, CI/CD und Bulk-Daten. Minimiert Latenz/Jitter und entkoppelt vom Heimnetz.
|
||||
- Hardware-Entscheidung: RTX 2000E Ada (16 GB ECC, 50 W) ist ein hoch‑effizienter, 24/7‑tauglicher Inferenz‑Beschleuniger. Für LLMs bis 7B (FP16) und 14B (ggf. quantisiert) sowie NVENC/Transcoding ist sie sehr passend. Gegenüber „dickeren“ Karten (z. B. 4090/6000 Ada) verlierst du Peak‑Throughput, gewinnst aber Effizienz, Geräusch, thermische Stabilität und ECC.
|
||||
|
||||
### Architektur-Empfehlungen (kurz & konkret)
|
||||
- Datenpfade klar trennen:
|
||||
- „Hot“ AI/Transcode scratch auf lokaler NVMe (Simka)
|
||||
- „Warm“ Artifacts/Backups via vmbr1 zu Zora
|
||||
- Standards definieren (Doku‑as‑Code):
|
||||
- ADR: „GPU‑Passthrough für Compute‑VMs“ (Begründung, Alternativen, Trade‑offs)
|
||||
- ADR: „LXC vs. VM für Runner/Builds“ (siehe DevOps‑Teil)
|
||||
- Observability als Querschnitt: Einheitliche Metrik‑Namen/Labels für Hosts, VMs, LXC (Node exporter/Nvidia exporter), damit Kapazitätsplanung reproduzierbar ist.
|
||||
|
||||
---
|
||||
|
||||
🐧 [DevOps Engineer]
|
||||
|
||||
### Was ist gut gelaufen
|
||||
- Proxmox VE 9.2 auf aktuellem Stand, dedizierter LXC‑Stack für Immich, Ping‑Latenz ~0,33 ms auf vmbr1: sehr solide Grundlage.
|
||||
- Saubere Migration der Immich‑Datenbank und großer Medienpool lokal auf NVMe → I/O‑Bottlenecks minimiert.
|
||||
|
||||
### Konkreter Wochenend‑Plan (Checkliste)
|
||||
1) Hardware‑Einbau und Firmware
|
||||
- RAM auf 64 GB einsetzen, Memtest (mind. 1 Pass) → Verifikation erforderlich.
|
||||
- GPU einsetzen; BIOS/UEFI:
|
||||
- Primäre Anzeige auf iGPU/Onboard setzen (damit dGPU frei für Passthrough bleibt)
|
||||
- Resizable BAR an (falls angeboten), SR‑IOV/IOMMU aktiv.
|
||||
|
||||
2) Proxmox: NVIDIA GPU‑Passthrough für KI‑VM
|
||||
- Kernel/Boot: IOMMU aktivieren (`amd_iommu=on`), Neustart; prüfen, dass GPU in eigenem IOMMU‑Group landet.
|
||||
- Host: `vfio-pci` binden, Nouveau/NVIDIA‑Hosttreiber nicht laden (Host soll die GPU nicht claimen).
|
||||
- VM anlegen (Ubuntu Server LTS oder Fedora Server), PCIe‑Gerät hinzufügen (GPU + ggf. GPU‑Audio Function), MSI‑Interrupts aktivieren.
|
||||
- In‑Guest: NVIDIA Treiber + CUDA/CuDNN installieren; `nvidia-smi` muss die Karte stabil zeigen.
|
||||
|
||||
3) „Simka Core AI“ VM: Modelle & Runtime
|
||||
- Ollama + optional OpenWebUI installieren.
|
||||
- Modelle (Beispiele mit 16 GB VRAM):
|
||||
- qwen2.5‑coder:7b (FP16) oder 14b quantisiert (Q4_K_M/Q6_K)
|
||||
- DeepSeek‑coder 6.7B, Llama‑3.1/3.2 8B Instruct quantisiert für Tools/Chat
|
||||
- Policies:
|
||||
- Max. Parallelität und KV‑Cache Limits definieren, um OOM zu vermeiden.
|
||||
- Watchdog/Service‑Unit für automatischen Neustart bei Treiber‑Resets.
|
||||
|
||||
4) Immich auf GPU beschleunigen
|
||||
- Auf dem LXC‑Host NVIDIA Container Toolkit bereitstellen oder, falls LXC zu restriktiv ist: Immich in eine leichte VM oder in einen privilegierten LXC migrieren.
|
||||
- docker‑compose Anpassungen:
|
||||
- `immich_machine_learning` mit `--gpus=all`/`runtime: nvidia`
|
||||
- FFmpeg HWAccel aktivieren: `-hwaccel cuda -hwaccel_output_format cuda -c:v h264_nvenc/hevc_nvenc`
|
||||
- Worker‑Limits neu justieren (mehr Transcode‑Jobs, wenn GPU an Bord)
|
||||
- Verifikation: Testtranscode und Embedding‑Job messen (Metriken/Logs sichern).
|
||||
|
||||
5) Gitea Runner Migration (Meldestelle CI/CD)
|
||||
- Entscheidung: LXC vs. VM
|
||||
- LXC (privileged, `nesting=1`, `keyctl=1`) ist ressourcenschonend, aber Docker‑in‑LXC erfordert Sorgfalt.
|
||||
- Alternativ: kleine „Runner‑VM“ mit Docker – oft robuster bei komplexen Build‑Needs (z. B. Android/Compose Desktop Toolchains).
|
||||
- Netzwerk: Runner nutzt vmbr1, verbindet sich mit Gitea auf Zora, DNS via Hostfile/Static Route, kein Default‑GW nötig.
|
||||
- Caching: Maven/Gradle Cache persistent auf separatem Volume; Artefakt‑Upload über vmbr1.
|
||||
|
||||
6) Netzwerk‑Feinschliff
|
||||
- vmbr1 ohne Gateway belassen; auf Hosts `metric`/Policy‑Routing setzen, damit Traffic für 192.168.99.0/24 strikt lokal bleibt.
|
||||
- Optional Jumbo Frames (MTU 9000) testen, wenn NICs/Switch/Direct‑Link es stabil können.
|
||||
- Proxmox‑Firewall:
|
||||
- vmbr0 restriktiv (nur notwendige Ingress‑Ports)
|
||||
- vmbr1 nur Host‑zu‑Host/Backup/CI erlauben
|
||||
|
||||
7) Backup & Wiederherstellung
|
||||
- Immich: DB Dumps (pg_dump) + Objekt‑Speicher Sync via vmbr1 zu Zora (z. B. borg/restic/ZFS send‑recv).
|
||||
- Proxmox: regelmäßige VM/LXC Snapshots + Offhost‑Kopie.
|
||||
- Recovery‑Drills: 1x/Quartal Wiederherstellung in Test‑VM durchführen → „Verifikation ausstehend“ bis Log vorhanden.
|
||||
|
||||
8) Observability & Betrieb
|
||||
- Node Exporter + NVIDIA DCGM/Exporter auf Simka; Prometheus/Grafana auf Zora aggregiert.
|
||||
- Alarme: NVMe Wear‑Level, GPU ECC Errors, Temp, OOM‑Kills, Docker/Container Restarts.
|
||||
- Energie: Optional `nvidia-smi -pl` Power‑Limit dokumentieren (wenn thermisch nötig), persistent via Systemd Unit.
|
||||
|
||||
### Risiken/Watchouts
|
||||
- LXC + GPU ist möglich, aber distributions‑/kernel‑abhängig; wenn Treiber‑Bindung hakelt, früh auf VM umschwenken.
|
||||
- RTX 2000E hat 16 GB VRAM: bei mehreren gleichzeitigen LLM‑Sessions aggressiv quantisieren oder serielle Ausführung planen.
|
||||
- Pangolin‑Tunnel: Secrets/Token sicher hinterlegen und Rotation terminieren; 2FA erzwingen.
|
||||
|
||||
---
|
||||
|
||||
🧹 [Curator]
|
||||
|
||||
### Dokumentations- und Abschluss‑Tasks
|
||||
- Dieses „Simka Core Server“ Dokument ist ein sehr guter Start. Ergänze bitte:
|
||||
- Abschnitt „Verifikation/Beweise“ mit Links/Screenshots/Logs zu: Memtest, `nvidia-smi`, Immich‑GPU‑Transcode‑Probe, Ollama Inferenz‑Benchmark, CI‑Runner „connected“ Status.
|
||||
- ADR‑Einträge unter `docs/01_Architecture/ADRs/`:
|
||||
- ADR‑00X „Dedizierter Keller‑Highway (vmbr1) für Bulk/CI/Backup“
|
||||
- ADR‑00X „GPU‑Passthrough für KI‑VM auf Proxmox“
|
||||
- ADR‑00X „Runner: LXC (privileged) vs. kleine VM – Entscheidung & Gründe“
|
||||
- Runbook „Simka Operations“: Boot‑Reihenfolge, Health‑Checks, Troubleshooting (GPU Reset, Treiber‑Reinstall, Container‑Restart).
|
||||
- Anti‑Halluzinations‑Protokoll anwenden:
|
||||
- Kein „erledigt“ ohne Build/Test‑Beweis; markiere alle neuen Punkte als „Verifikation ausstehend“, bis Logs/Artefakte abgelegt sind.
|
||||
- Inventar & Versionen pflegen:
|
||||
- BIOS/UEFI‑Version, Proxmox‑Kernel, NVIDIA‑Treiber, Docker Compose Hash, Immich Version, DB Schema Version.
|
||||
|
||||
### Verifikation/Beweise (Platzhalter – Verifikation ausstehend)
|
||||
- [ ] Memtest86+ Log (mind. 1 Pass, fehlerfrei)
|
||||
- [ ] `nvidia-smi` Ausgabe in der KI‑VM (GPU erkannt, ECC aktiv, Treiber‑Version)
|
||||
- [ ] Immich: GPU‑beschleunigter Transcode‑Test (Log + Metriken)
|
||||
- [ ] Ollama: Inferenz‑Benchmark (Modell + Prompt + Zeit + VRAM‑Auslastung)
|
||||
- [ ] Gitea Runner: „connected“ Status + Beispiel‑Build‑Log über vmbr1
|
||||
Reference in New Issue
Block a user