Disaster Recovery für eine private KI-Plattform: zweiter Standort, GPU-Kapazität und Failover

Disaster Recovery für eine KI-Plattform: was zuerst zu entscheiden ist

Disaster Recovery für eine private KI-Plattform beginnt mit einer Entscheidung je KI-Dienst: ob er weiterlaufen muss, wenn das Rechenzentrum am Hauptstandort ausfällt, und auf welchem Mindestniveau. Diese Antwort legt fest, was am zweiten Standort bereitsteht. Zur Wahl stehen volle GPU-Kapazität, reduzierte Kapazität mit weniger Karten, einem kleineren oder quantisierten Modell oder weniger gleichzeitigen Nutzern, oder gar keine GPUs und ein Neuaufbau aus Backups, sobald wieder Server verfügbar sind. In jeder Option werden die Daten, die nur auf der Plattform existieren, an den zweiten Standort repliziert oder dorthin gesichert, und die Inferenzknoten werden aus gepinnten Quellen neu aufgebaut.

Dieser Leitfaden behandelt den Verlust eines ganzen Standorts. Den Ausfall eines GPU-Servers am selben Standort zu überstehen ist Hochverfügbarkeit, die unser Leitfaden zur LLM-Hochverfügbarkeit mit zwei GPU-Knoten behandelt, und das Backup von Gewichten, Adaptern und Vektorspeichern steht in unserem Leitfaden zum Backup eines KI-Servers.

Wiederherstellungsstufen für KI-Dienste

KI-Dienste gehen wie jedes andere System mit ihren Prozessverantwortlichen in die Business Impact Analysis ein. Ein Code-Assistent für Entwickler, ein interner Chat-Assistent, ein RAG-Assistent für den Kundenservice und ein nächtlicher Job zur Dokumentenextraktion unterscheiden sich darin, wie schnell der Schaden wächst, wenn sie ausfallen.

Die Technical Implementation Guidance der ENISA zu NIS2 (Version 1.0, Juni 2025) ergänzt eine Messgröße, die gut zu KI-Diensten passt: das Service Delivery Objective, also „das Mindestleistungsniveau, das erreicht werden muss“, wenn Geschäftsfunktionen im Notbetrieb laufen. Für einen KI-Dienst wird das Mindestniveau in Anfragen in Bearbeitung, Kontextlänge und Modellqualität angegeben. Vereinbaren Sie es mit dem Prozessverantwortlichen, bevor Sie den zweiten Standort auslegen.

Ein RAG-Assistent braucht am zweiten Standort sein Embedding-Modell, seinen Reranker, den Vektorindex, die Dokumenten-Connectoren, das Gateway und den Identity Provider. NIST SP 800-34 Rev. 1 hält fest, dass „der RTO normalerweise kürzer sein muss als die MTD“; die Zeit, um jede dieser Komponenten der Reihe nach zu starten, muss also in den RTO des KI-Dienstes passen.

Was repliziert und was neu aufgebaut wird

Für eine KI-Plattform gilt die Regel, Zustand zu replizieren und Rechenleistung neu aufzubauen. Inferenzknoten halten nichts Einmaliges, wenn die Gewichte gepinnt sind und die Konfiguration in git liegt; die Datenbanken um sie herum halten Daten, die es nirgendwo sonst gibt.

Unsere Einordnung. README von pgvector (FAQ „Is replication supported?“), Dokumentation zu Velero v1.18, Dokumentation zu Argo CD und Benutzerhandbuch zum NVIDIA License System, gelesen am 10. Oktober 2026.

Für pgvector führt der Weg über die eigene Replikation der Datenbank: Seine README antwortet „Ja, pgvector nutzt das Write-Ahead-Log (WAL), das Replikation und Point-in-Time-Recovery ermöglicht.“ Speicher ohne WAL-basierte Replikation werden nach Zeitplan als Snapshots oder Backups kopiert, und die neueste Kopie bestimmt den Wiederherstellungspunkt des Index. Halten Sie das Embedding-Modell am zweiten Standort auf derselben Revision wie am Hauptstandort. Vektoren aus einem anderen Embedding-Modell passen nicht zu den gespeicherten, und ein Modellwechsel bedeutet, den gesamten Korpus neu einzubetten.

Halten Sie die Basisgewichte am zweiten Standort bereit, bevor Sie sie brauchen, denn ein Download am Tag des Ausfalls hängt vom Hub ab, vom Zugang zu einem zugangsbeschränkten Modell und davon, dass die Revision noch existiert. gpt-oss-120b ist ein Checkpoint mit 65,3 GB, und mit mehreren Modellen und Versionen kann der Modellspeicher Terabytes erreichen; kopieren Sie also jede neue Revision einmal, wenn sie freigegeben wird, und nicht bei jedem Backup-Lauf.

GPU-Kapazität am zweiten Standort

Das Rechenbeispiel stammt aus unserem Leitfaden zu privaten ChatGPT-Servern nach Unternehmensgröße: 2.000 Mitarbeiter erzeugen eine Spitze von 80 Anfragen in Bearbeitung mit gpt-oss-120b bei deklarierten 32K Kontext mit einem 16-Bit-KV-Cache, und eine RTX PRO 6000 hält rund 19 solche Gespräche, eine H200 NVL rund 55. Der Hauptstandort in unserem Leitfaden zur Hochverfügbarkeit betreibt zwei Server mit je 5 RTX PRO 6000 oder 2 H200 NVL, sodass jeder der beiden die Spitze hält.

Sitzungen bei 32K mit einem 16-Bit-Cache, 19 je RTX PRO 6000 und 55 je H200 NVL, und die L4 für Embedding und Reranking aus unserem Leitfaden zur Unternehmensgröße; die L40S, wenn jede Anfrage 40 Passagen rerankt, wie in unserem Leitfaden zur Plattformarchitektur; das Mindestniveau von 40 ist ein Beispielwert. Die Wiederanlaufklassen sind beschreibend und keine Zielwerte unseres Service.

Zwei RTX PRO 6000 halten rund 38 Gespräche, weniger als das Mindestniveau von 40 im Beispiel; deshalb braucht die reduzierte Option drei. Ein kleineres Modell unterscheidet sich außerdem in Kontextlänge, im Verhalten beim Systemprompt und bei Tool-Aufrufen; leiten Sie also unter einem Namen dorthin, den die Prozessverantwortlichen kennen, oder stellen Sie es mit --served-model-name von vLLM unter dem bisherigen Namen bereit, was seine Dokumentation als „The model name(s) used in the API“ beschreibt. Zwei Standorte können sich auch die alltägliche Last teilen, wobei jeder allein das vereinbarte Mindestniveau hält; der Aufwand dafür ist, die Plattform und ihre Updates an beiden Orten zu betreiben.

KI-Server bauen wir auf Bestellung mit 2 bis 8 GPUs je Knoten, für den Hauptstandort und den zweiten Standort, unter einem EU-Vertrag und auf einer Rechnung. Nennen Sie uns das Mindestleistungsniveau jedes KI-Dienstes und wo der zweite Standort liegt.

GPU-VMs: Passthrough, vGPU und Replikation

Wo die Inferenz in vSphere-VMs läuft, kommt es auf den GPU-Modus an. Broadcoms Dokumentation zu vSphere 9.0, aktualisiert am 24. August 2026, führt Snapshots unter den Funktionen auf, die „für virtuelle Maschinen, die mit DirectPath konfiguriert sind, nicht verfügbar“ sind; Werkzeuge, die eine VM über ihre Snapshots replizieren, können eine laufende Passthrough-VM also nicht kopieren. vSphere Replication arbeitet anders: Broadcoms Dokumentation zu VCF 9.1, aktualisiert am 10. September 2026, beschreibt einen Agenten, der „geänderte Blöcke in den Festplatten der virtuellen Maschine vom Quellstandort an den Zielstandort sendet“. Eine Aussage zu Passthrough-Geräten haben wir in dieser Dokumentation nicht gefunden; belegen Sie den Weg also mit einer Testreplikation und einer Wiederherstellung, bevor Sie sich darauf verlassen.

Das einfachere Design hält die Inferenz-VMs aus der Replikation heraus. Sie werden am zweiten Standort aus einer Vorlage neu aufgebaut, mit den Gewichten auf lokalen Platten und der Konfiguration aus git. Dynamic DirectPath I/O hilft dabei: Laut Broadcoms KB 312208 kann eine VM zulässige Kombinationen aus Hersteller und Gerät angeben und ESXi ein passendes Gerät „auf Grundlage dessen, was zum Zeitpunkt des Einschaltens der VM verfügbar ist“, wählen lassen, sodass eine Vorlage nicht von der Adresse einer bestimmten Karte abhängt. Eine vGPU-VM braucht einen Host, dessen GPU ihren vGPU-Typ anbietet. Die Regeln für beide Modi stehen in unserem Leitfaden zu GPUs in vSphere: Passthrough oder vGPU.

Lizenzen kommen als Abhängigkeit hinzu. VMs mit vGPU for Compute beziehen eine Lizenz vom NVIDIA License System, dessen On-Premises-Form in NVIDIAs Worten „im eigenen Haus an einem Ort gehostet wird, der aus Ihrem privaten Netzwerk erreichbar ist“. Der zweite Standort braucht eine Route zu einer solchen Instanz oder eine eigene Instanz mit Lizenzen aus Ihrer Berechtigung, die ihr im NVIDIA Licensing Portal zugewiesen sind. NVIDIA ergänzt, dass nach dem Ausfall einer Instanz in einem Cluster aus zwei Instanzen „die verbleibende Instanz zum Single Point of Failure wird“.

Kubernetes am Ausweichstandort: GitOps und Velero

Auf Kubernetes betreibt der zweite Standort einen eigenen Cluster statt eines gestreckten, denn eine über zwei Standorte verteilte Control Plane hängt von der Verbindung zwischen ihnen ab. Der Cluster wird aus denselben Definitionen gebaut wie der Hauptcluster. Argo CD beschreibt sein Prinzip mit „Anwendungsdefinitionen, Konfigurationen und Umgebungen sollten deklarativ und versioniert sein“ und führt die „Fähigkeit, mehrere Cluster zu verwalten und in sie auszurollen“ auf. Liegen Modell-Deployments, Gateway und Frontend in git, startet der zweite Cluster dieselben Versionen, und der git-Server selbst gehört in die replizierte Ebene.

Velero deckt ab, was nicht in git liegt, und seine Dokumentation zu v1.18 führt „Cluster-Ressourcen in andere Cluster migrieren“ unter seinen Einsatzzwecken auf. Sein Migrationsleitfaden richtet die Velero-Instanzen beider Cluster „auf denselben Speicherort im Cloud-Objektspeicher“ aus; dieser Speicher muss also außerhalb des Hauptstandorts liegen. Ein Volume-Snapshot auf dem Storage des Hauptstandorts geht mit dem Standort verloren, und um Volume-Daten zwischen Clustern zu verschieben, schlägt Velero „das Dateisystem-Backup oder den Snapshot Data Mover“ vor. Es hält außerdem fest: „Velero unterstützt keine Wiederherstellung in einen Cluster mit einer niedrigeren Kubernetes-Version als der, in dem das Backup erstellt wurde“; halten Sie also beide Cluster auf derselben Kubernetes-Version und aktualisieren Sie zuerst den zweiten Standort.

DNS- und Gateway-Failover

Nutzer und Anwendungen erreichen die Plattform über einen Namen, den des Gateways; das Failover eines KI-Dienstes ist also vor allem eine Änderung des Ziels, auf das dieser Name zeigt. RFC 1035 definiert die TTL eines DNS-Eintrags als die Zeit, für die er „zwischengespeichert werden darf, bevor die Quelle der Information erneut befragt werden sollte“. Setzen Sie die TTL des Gateway-Eintrags lange vor jedem Notfall auf die Verzögerung, die Sie akzeptieren, denn eine erst am Tag des Ausfalls gesenkte TTL erreicht die Clients erst, wenn die alte abgelaufen ist. Betreiben Sie die Zone mit Nameservern an beiden Standorten, sonst lässt sich die Änderung nicht veröffentlichen, sobald der Hauptstandort ausgefallen ist.

Das Gateway am zweiten Standort braucht denselben Zertifikatsnamen, dieselben API-Schlüssel und dieselben Routing-Regeln wie das am Hauptstandort, und der Identity Provider dahinter muss an diesem Standort funktionieren.

DR-Tests, die die Qualität der Antworten prüfen

Ein DR-Test für einen KI-Dienst misst wie jeder Disaster-Recovery-Test die Zeit bis zum funktionierenden Dienst gegen den RTO und ergänzt Prüfungen, die zeigen, dass der KI-Dienst mit dem richtigen Verhalten zurückgekommen ist.

1. Starten Sie die Plattform am zweiten Standort in einem Netz ohne Route zur Produktion und notieren Sie, wann jede Komponente antwortet.
2. Prüfen Sie die Gewichte am zweiten Standort gegen das SHA-256-Manifest des Hauptstandorts.
3. Lassen Sie das feste Evaluierungsset über das Gateway laufen, gegen die Bestehensgrenze, die für das dort laufende Modell vereinbart ist; ein kleineres Modell bekommt seine eigene Grenze.
4. Führen Sie die festen Retrieval-Abfragen aus, eine je Berechtigungsstufe, und vergleichen Sie die Top-Treffer mit der Baseline.
5. Rufen Sie die API mit bestehenden Schlüsseln aus je einer Anwendung jeder Art auf und prüfen Sie, dass das Anfragelog die Aufrufe erfasst.
6. Halten Sie das Alter der Wiederherstellungspunkte fest, die für Vektorindex, Chatverlauf und Logs verwendet wurden, und vergleichen Sie es mit deren RPO.

Wiederholen Sie den Test nach jedem Wechsel von Modell, Embedding-Modell, Serving-Engine oder GPU-Typ an einem der beiden Standorte.

Unser Service Cloud Disaster Recovery repliziert virtuelle Maschinen mit Veeam an einen Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen und führt planmäßige Failover-Tests in einer isolierten Umgebung durch. Beschreiben Sie die CPU-Ebene Ihrer KI-Plattform im Formular unten.

Was wir liefern

Wir bauen KI-Server auf Bestellung für beide Standorte, mit 2 bis 8 GPUs je Knoten: Karten RTX PRO 6000 Server Edition oder H200 NVL für die Sprachmodelle und die L4 oder L40S für Embedding und Reranking, im Burn-in getestet, mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Lizenzen für NVIDIA AI Enterprise und vGPU kommen auf dieselbe Rechnung, und wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Soll der zweite Standort ein Rechenzentrum sein, führt unser Service Private AI/ML unter seinen Deployment-Optionen ein EU-Rechenzentrum auf, Tier-3 in Litauen, in dem die Daten in der EU auf dedizierter Hardware bleiben; die Option wird im Assessment gewählt, und das Engineering kommt von unserem Engineering-Partner Vixen.UNO. Für die virtuellen Maschinen rund um die Modelle bietet unser Service Cloud Disaster Recovery Veeam-Replikation ab 15-Minuten-Intervall, planmäßige Testwiederherstellungen sowie RPO und RTO, die im SLA fixiert sind.

FAQ