Zusammenfassung

  • Der RHEL-Leitfaden ordnet aktive synchrone und asynchrone Volume-Replikation zwischen Systemen dem kostenpflichtigen Hot DR zu. Fehlender regulärer Kundenverkehr allein bestimmt die Kategorie nicht.
  • Selbstverwaltetes OpenShift hat eine eigene Regel für replizierende externe Speichergeräte. Auch das Aufwecken für Wartung, Tests oder laufende Workloads wird unterschieden. Der Einkauf muss den tatsächlichen Wiederanlaufweg bewerten.

Eine Speicherfunktion aus dem Cluster zu verlagern klingt nach einer technischen Detailentscheidung. Im Leitfaden für selbstverwaltetes OpenShift kann genau dieser Ort eine kommerzielle Grenze markieren: Replizierende externe Speichergeräte gelten dort weiterhin als Warm DR. Wer die Reserve lediglich mit einem Etikett versieht, verschenkt die wichtigste Information für den Einkauf.

Die Januar-Fassung des OpenShift-Leitfadens und der RHEL-Leitfaden vom 21. Juli 2026 beschreiben produktspezifische Regeln. Beide verlangen bezahlte Abonnements für Hot DR. Welche Bereitschaft darunter fällt, muss jedoch am jeweiligen Produkt und am Datenweg geprüft werden. Eine Farbe im Architekturplan reicht dafür nicht.

Die Kopie arbeitet schon vor dem Ausfall

Bei RHEL umfasst die Hot-DR-Definition voll funktionsfähige Systeme, die parallel zur Produktion laufen und unmittelbar Verkehr übernehmen können. Aktive synchrone oder asynchrone Datenvolume-Replikation zwischen Systemen zählt ebenfalls als heiß. Das Ausweichsystem kann also bereits vorbereitende Arbeit leisten, obwohl kein regulärer Nutzer dort bedient wird.

Warm DR ist auf ähnliche Workloads vorbereitet, enthält aber keine Kunden-Workloads des Quellsystems und soll keine aktive Volume-Replikation betreiben. Für die Wiederherstellung müssen Kundendaten von außerhalb des Quellsystems auf vorhandene Hardware zurückgespielt werden. Cold DR hat noch nicht die gesamte zur Wiederaufnahme nötige Technik.

Abonnements können bei einem Katastrophenfall vom Primärsystem in die warme oder kalte Umgebung übertragen werden. Damit ist eine Softwareberechtigung neu zugeordnet. Datenwiederherstellung, Anwendungsstart und funktionierender Geschäftsdienst bleiben eigene Schritte.

Der Preisvergleich muss diese Schritte mitnehmen. Mehr parallele Bereitschaft wird vorher finanziert; mehr Wiederherstellungsarbeit fällt später an. Spart eine Abteilung das Abonnement und eine andere übernimmt ungeplante Arbeit im Ausfall, ist zunächst nur die Kostenstelle gewechselt. Das Unternehmen hat noch keinen besseren Wiederanlauf gekauft.

OpenShift trennt den Speicher genauer

Der Leitfaden für selbstverwaltetes OpenShift vom 23. Januar 2026 nennt aktive Replikation zwischen Clustern durch in OpenShift betriebenen softwaredefinierten Speicher in seiner Hot-DR-Definition. Die Warm-DR-Regel berücksichtigt auch, ob der sekundäre Standort replizierte Daten in aktiv laufende Container-Workloads einbindet. Externe Speichergeräte mit Volume-Replikation werden weiterhin als warm behandelt.

Bei warmem DR mit OpenShift-internem softwaredefiniertem Speicher verlangt die Wiederherstellung, Daten von außerhalb des Clusters auf dessen vorhandene Hardware zurückzuspielen. Speicherort, Einbindung und Arbeitslast hängen somit am selben Beschaffungsproblem. Die Zahl der Reserveknoten bildet es nur teilweise ab.

Die externe Speicherregel gehört zu OpenShift. Sie darf nicht still in RHEL übernommen werden. Ein gemeinsamer Anbieter macht aus zwei Produktdefinitionen keine gemeinsame Flatrate. Umgekehrt würde die Behauptung, jede Replikation sei überall kostenpflichtiges Hot DR, die ausdrücklich beschriebene OpenShift-Unterscheidung ausradieren.

Schlaf allein senkt die Kategorie nicht

OpenShift-Cluster in Hibernation benötigen weiterhin Abonnements, wenn sie nicht ausdrücklich als Warm oder Cold DR konfiguriert und entworfen wurden. Der Leitfaden nennt etwa Cloud-Cluster, die wegen geringerer Nachfrage vorübergehend ruhen. Weniger Auslastung beschreibt einen anderen Zweck als ein vorbereitetes Wiederanlaufverfahren.

Werden warme oder kalte DR-Cluster für Workloads aufgeweckt, sind Abonnements erforderlich. Ein vorübergehendes Aufwecken für Routinewartung oder Tests benötigt dagegen kein zusätzliches Abonnement für Komponenten der OpenShift-Softwareangebote. Das lässt Raum, Bereitschaft zu pflegen und zu erproben.

Diese Erprobung hat einen wirtschaftlichen Wert: Sie macht sichtbar, welche Arbeit erst nach der Aktivierung beginnt. Ein sauberes Reserveetikett ohne getestete Rücksicherung kann im Budget tadellos aussehen und im Ernstfall sehr beschäftigt sein. Der Übungszweck muss ebenso erkennbar bleiben wie der Übergang zu tatsächlichen Workloads.

Es fehlen der konkrete Speicher- und Workload-Pfad des Käufers, gemessene Wiederanlaufzeiten und das anwendbare Angebot; mit diesen Angaben kann sich die wirtschaftlich beste Variante ändern.

Ein sinnvoller Vergleich legt Bereitschaft, Personal, externe Infrastruktur und nachgelagerte Wiederherstellung nebeneinander. Schutz abzuschalten, um allein das Abonnement zu verkleinern, verändert zugleich das Betriebsrisiko. Diese Entscheidung gehört den Verantwortlichen für den Geschäftsausfall mit auf den Tisch.

Die Reserve wird als künftige Handlungsfähigkeit gekauft. Ihr Preis steht teilweise im Vertrag und teilweise in der Arbeit, die während einer Störung noch übrig bleibt. Der rote Hut auf dem Angebot hält keine einzige Wiederherstellungsminute warm.

Quellen