# 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