mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
e4988b4397bd31a516c484f08b442757d0f4901a
meldestelle/docs/Ablage/Simka_Server_Zusammenfassung.md
T
stefan 0a90b57c2a docs: Ergänzung der Simka Core Server Dokumentation 
Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-05-22 13:13:24 +02:00

13 KiB
Raw Blame History

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.
  1. 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.
  1. „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.
  1. 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).
  1. 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.
  1. 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
  1. 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.
  1. 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 View Git Blame Copy Permalink