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

// installation

Multi-Node

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

basebox-Plattform, Service-Modelle und Inferenz über mehrere Knoten verteilen: was damit möglich wird (Kapazität, Sicherheitszonen, Ausfallsicherheit) und was schwieriger (Zustand, gemeinsamer Speicher, Modell-Caches). Ein Teil davon ist dokumentiert und erprobt – die Trennung von Anwendungs- und Inferenz-Host –, Hochverfügbarkeit ist eine eigene Architektur mit eigenem Aufwand.

Die drei Topologien

Aus Deployment-Topologien:

Topologie Wann Status
Ein Server, ein Cluster Evaluierung, kompakte Appliance – alle Referenzkonfigurationen Validated
Ein Cluster mit CPU- und GPU-Knoten Kubernetes trennt die Knoten bereits; Plattform auf CPU-Knoten, Inferenz und Service-Modelle auf GPU-Knoten Supported
Getrennte Anwendungs- und Inferenzserver GPU-System wird separat verwaltet oder liegt in einer anderen Sicherheitszone; Anwendungsserver rein CPU Supported – dokumentiert und mit basebox 1.7.1 / vLLM 0.15.0 erprobt

Was in allen drei gleich bleibt: Nutzer sprechen mit basebox, nie mit dem Inferenzserver; AISRV erreicht die Inferenz über eine authentifizierte OpenAI-kompatible API.

Was auf welchen Knoten gehört

Schicht Komponenten Knotentyp Was zu beachten ist
Plattform frontend, AISRV, storesrv, Keycloak, PostgreSQL-Cluster, MCP-Konnektoren CPU-Knoten Zustand liegt in den Datenbanken und im Medien-Volume
Service-Modelle ragsrv, ragsrv-support, OCR-/STT-Endpunkte GPU-Knoten (MIG oder eigene GPU) oder CPU-Modus Gemeinsames Temp-Volume /tmp/ragsrv braucht ReadWriteMany, wenn ragsrv und ragsrv-support auf verschiedenen Knoten laufen
Inferenz vLLM oder kompatible Runtime GPU-Knoten Modell-Cache je Knoten; Kaltstart mehrere Minuten

Platzierung über nodeSelector/Tolerations – das Chart bringt für GPU-Workloads bereits nvidia.com/gpu: "true" und die zugehörige Toleration mit (Multi-GPU → Konfiguration). Für CPU-Knoten sorgen Sie umgekehrt dafür, dass Plattformdienste nicht auf GPU-Knoten landen und dort Ressourcen blockieren.

Getrennte Anwendungs- und Inferenzserver

Der dokumentierte Weg für Organisationen mit vorhandenem GPU-System:

  1. Anwendungsserver rein CPU vorbereiten: Kubernetes, Ingress, Speicher, CloudNativePG – ohne NVIDIA-Stack. ragsrv/ragsrv-support im CPU-Modus oder auf einem eigenen GPU-Host.
  2. Inferenzserver mit der Runtime Ihrer Wahl; Endpunkt verlangt API-Schlüssel, TLS, nur von AISRV erreichbar.
  3. Anbinden nach Inferenz anbinden: inference.enabled: false, AISRV_LLM_URL, Provider, Modell, Kontext, Schlüssel aus Secret; private CA in den basebox-Workload importieren, falls nötig.
  4. Firewall: genau ein Pfad AISRV → Inferenz-Endpunkt; keine Freigabe für Nutzer.

Beide Hosts liegen in derselben freigegebenen Datenverarbeitungsgrenze – Prompts, abgerufener Kontext und Dokumentinhalte wandern zwischen ihnen. Was das für Sicherheitsprüfer heißt: Sicherheit → Datenflüsse.

Was Multi-Node schwieriger macht

  • Zustand. Die vier PostgreSQL-Cluster halten den Zustand; Pods der Plattform sind austauschbar, die Datenbanken nicht. CloudNativePG kann mit instances: 3 über Knoten replizieren – dann brauchen Sie Anti-Affinität und eine Storage Class, die auf jedem Knoten bereitstellt.
  • Gemeinsamer Speicher. Medien-Volume (AISRV_MEDIA_ROOT) und das RAG-Temp-Volume müssen von den Pods erreichbar sein, die sie brauchen – bei mehreren Replikaten oder getrennten Knoten heißt das ReadWriteMany (NFS oder vergleichbar), siehe Speicher.
  • Modell-Caches. Jeder Inferenz- und Service-Knoten hält seinen eigenen Cache; im abgeschotteten Betrieb muss der Mirror jeden Knoten versorgen.
  • Netz. Mehr Hops, mehr TLS, mehr Firewall-Regeln – je Pfad genau eine Freigabe (Netzwerk).
  • Betrieb. Updates, Backups und Monitoring erstrecken sich über mehrere Hosts; das Manifest wird wichtiger, nicht unwichtiger.

Hochverfügbarkeit

Multi-Node ermöglicht Ausfallsicherheit, liefert sie aber nicht von selbst. Bausteine einer HA-Architektur:

Baustein Mittel Anmerkung
Plattformdienste Mehrere Replikate von frontend, AISRV, storesrv, Keycloak auf verschiedenen Knoten Zustandslos; Keycloak-Clustering beachten
Datenbanken CloudNativePG instances: 3, automatischer Failover auf -rw-Service Backups bleiben Pflicht (Backup & Wiederherstellung)
Ingress Redundanter Ingress-Controller, virtuelle IP oder externer Load Balancer Zertifikat auf allen Instanzen
Speicher Replizierter oder externer Speicher mit ReadWriteMany Lokaler Speicher (local-path) ist nicht HA
Inferenz Zweite Instanz auf eigenem GPU-Knoten (Mehrere Inferenz-Instanzen) Verdoppelt GPU-Bedarf; ohne zweite Instanz bleibt die Inferenz der Single Point of Failure

Status: Custom. basebox hat einzelne Bausteine im Einsatz, aber keine HA-Gesamtkonfiguration als Referenz vermessen. Wer sie baut, dokumentiert sie nach der Vorlage Kundenhardware und stimmt sie mit basebox ab.

Prüfen

kubectl get nodes -o wide                                   # Rollen, Bereitschaft
kubectl get pods -n basebox -o wide                         # Platzierung je Knoten
kubectl -n basebox describe node <gpu-node> | grep nvidia   # GPU-Ressourcen nur auf GPU-Knoten
kubectl get cluster -n basebox                              # CNPG-Instanzen und Primary

Dann: Chat, Upload, Wissensbasis, Audio – die Abnahme aus Installation prüfen. Bei HA zusätzlich einen Knoten drainen und beobachten, ob die Anwendung erreichbar bleibt.

Häufige Fehlerbilder

Symptom Ursache Lösung
Plattform-Pod Pending auf GPU-Knoten Toleration gesetzt, aber kein CPU-Knoten frei Ressourcen/Selector prüfen
ragsrv-support findet Dateien nicht Temp-Volume nicht gemeinsam (RWO auf anderem Knoten) ReadWriteMany-Volume oder beide Dienste auf denselben Knoten
Inferenz nach Failover nicht erreichbar DNS/Firewall zeigt auf alten Host Stabile Adresse (Service, VIP) für den Endpunkt
Datenbank read-only nach Knotenausfall CNPG-Primary weg, kein Replikat instances: 3 und Storage auf mehreren Knoten
TLS-Fehler zwischen Hosts Private CA nicht importiert CA in den basebox-Workload einbinden

Nächster Schritt: Betrieb