Zum Inhalt
Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// installation

Speicher

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

Persistenter Speicher für Modellartefakte, Dokumente und Plattformdaten: Storage Classes, Kapazitätsplanung und Backup-Anknüpfungspunkte. basebox braucht keinen exotischen Speicher – aber genug davon, schnell genug für Datenbanken, und eine klare Trennung zwischen dem, was gesichert werden muss, und dem, was neu erzeugt werden kann.

Was persistent ist

Daten Wo Standardgröße im Chart Sichern?
AISRV-Datenbank – Benutzer, Organisationen, Apps, Einstellungen, Audit-Log, Konnektor-Zugangsdaten CloudNativePG-Cluster aisrv-db 10 Gi Ja – die wichtigste
storesrv-Datenbank storesrv-db 10 Gi Ja
ragsrv-Datenbank – Dokumentabschnitte und Embeddings (pgvector) ragsrv-db 5 Gi Ja (oder Wissensbasen neu aufnehmen)
Keycloak-Datenbank – Identitäten, Realms, Clients idp-db 5 Gi Ja
Medien / Uploads AISRV_MEDIA_ROOT (persistentes Volume) – Ja
Temporäre RAG-Dateien /tmp/ragsrv (z. B. PVC ragsrv-shared-storage) – Nein
Modellgewichte Inferenz PVC inference-models unter /data/.cache/huggingface 200 Gi im Beispiel Nein – neu ladbar (abgeschottet: Mirror vorhalten)
Modelle Service-Modelle PVC ragsrv-support-models unter /models 20–50 Gi im Beispiel Nein – neu ladbar
Caches (Numba, Triton) /data (emptyDir oder PVC) 50 Gi im Beispiel Nein
Secrets Kubernetes-Secrets (aisrv-database, keycloak-admin-secret, basebox-admin-secret, …) – Ja – etcd-Backup oder Export

Storage Class

  • Dynamische Bereitstellung ist Pflicht; das Chart legt PVCs an.
  • Evaluierung: local-path (Standard im Lokalen Schnellstart).
  • Produktion: eine Storage Class auf SSD/NVMe (die Service-Seiten nennen sie beispielhaft fast-ssd) – Datenbank-IOPS und Modellladezeiten hängen direkt daran. Snapshots oder Replikation auf Speicherebene sind ein Plus, ersetzen aber keine Datenbank-Backups.
  • Zugriffsmodus: Die meisten Volumes sind ReadWriteOnce. Ein von ragsrv und ragsrv-support gemeinsam genutztes Temp-Volume (/tmp/ragsrv, im Beispiel nfs-shared) braucht ReadWriteMany, wenn beide Pods auf verschiedenen Knoten laufen – auf einem Einzelknoten reicht RWO.
kubectl get storageclass
kubectl get pvc -n basebox

Kapazitätsplanung

Chart-Richtwerte: 200 GB+ minimal, 500 GB+ SSD/NVMe empfohlen, 1 TB+ wenn Modelle lokal vorgehalten werden. Konkreter:

Posten Faustregel
Modellgewichte Inferenz Größe des Modells in der gewählten Quantisierung (z. B. ~60 GB GPT-OSS 120B MXFP4, ~70 GB Llama 3.3 70B FP8, ~16 GB GPT-OSS 20B) plus Platz für ein zweites Modell beim Wechsel
Service-Modelle 20–50 GB für Embedding-, OCR- und STT-Modelle
Datenbanken In Produktion 20–50 Gi je Cluster statt der 5–10 Gi Standardwerte; ragsrv-db wächst mit der Anzahl Dokumentabschnitte
Medien Summe der hochgeladenen Dateien in Wissensbasen und Chats; abhängig von den Limits, die Administratoren je Organisation setzen
Shared Memory /dev/shm mit 64 GB in der geprüften Konfiguration für das Laden großer Modelle
Reserve 20–30 % für Wachstum, Backups vor Upgrades, Migrations-Backups (AISRV_DB_MIGRATE_BACKUP_DIR)

Größen in den Values setzen, z. B.:

aisrv:
  aisrv-db:
    cluster:
      instances: 3
      storage:
        size: 50Gi
        storageClass: fast-ssd

Backup-Anknüpfungspunkte

Zwei Wege, die sich ergänzen:

Datenbank-Dumps je Cluster:

kubectl exec -n basebox aisrv-db-1 -- pg_dump -U aisrv aisrv > aisrv-backup.sql

CloudNativePG-Backups nach S3-kompatiblem Speicher, in den Values konfiguriert (backup.barmanObjectStore, retentionPolicy: "30d") – Beispiel auf der Helm-Chart-Übersicht. Dazu Medien-Volume und Secrets sichern. Das Verfahren im Ganzen, inklusive Wiederherstellung und Test: Backup & Wiederherstellung.

Vor jedem Upgrade sichern

Datenbankmigrationen (etwa V32 ab basebox 1.8.6) sind vorwärts gerichtet. Ohne Backup der AISRV-Datenbank gibt es keinen Weg zurück.

Abgeschottete Umgebungen

Ohne Internetzugang werden Modellgewichte vorab auf die PVCs geladen (Download-Job oder Kopie) und die Inferenz mit HF_HUB_OFFLINE: "1" betrieben; Beispiel unter Inference Server → Offline-Konfiguration. Planen Sie den Speicher für einen lokalen Modell- und Image-Mirror ein.

Prüfen

kubectl get pvc -n basebox                 # alle Bound
kubectl get cluster -n basebox             # CNPG-Cluster healthy
df -h /dev/shm                             # Shared Memory
kubectl exec -n basebox deploy/aisrv -- df -h   # Medien-Volume gemountet

Nächster Schritt: Netzwerk