Was ist Disaster Recovery?

Disaster Recovery (DR) ist ein Aspekt der übergreifenden Pläne für die Geschäftskontinuität, die von den verschiedenen Geschäftsbereichen innerhalb eines Unternehmens ausgearbeitet und gepflegt werden. Ein effektiver Disaster Recovery-Plan mindert die Auswirkungen ungeplanter – oder sogar geplanter – Ausfälle geschäfts- und unternehmenskritischer Systeme auf die Fähigkeit eines Unternehmens, zu arbeiten und weiter Umsätze zu erzielen.

Dazu stellt ein DR-Plan einem Unternehmen eine flexible Struktur zur Verfügung, die es diesem ermöglicht, auf einheitliche und kollaborative Weise seine Systeme wiederherzustellen, neu zu entwickeln und wieder zum Leben zu erwecken sowie eine resilientere Infrastruktur aufzubauen.

Warum ist Disaster Recovery so wichtig?

Wie lange könnte ein Unternehmen weiter arbeiten, wenn es sein System für die Entgeltabrechnung verlieren würde, kurz bevor die Gehaltszahlungen berechnet und überwiesen werden? Mit welchen Strafen müsste ein Unternehmen rechnen, wenn es Bundes-, Landes- und Gemeindesteuern zu spät begleichen würde? Welche Folgen hätte es für das Unternehmen, wenn es seine Mitarbeiter nicht pünktlich bezahlen würde – und wie lange würden die Mitarbeiter bei dem Unternehmen bleiben?

Disaster Recovery – ja oder nein? Das ist nicht länger die Frage. Die wirkliche Frage ist, was die wahren Kosten sind für den augenblicklichen Verlust an Minuten, Tagen oder Wochen an wichtigen Daten und des Vertrauens, das über Jahre aufgebaut wurde.

Disaster Recover darf nicht länger nur als Nebensächlichkeit angesehen oder als etwas betrachtet werden, das man sich nur leistet, wenn das Budget dafür ausreicht. Denn von den Unternehmen von heute wird erwartet, unmittelbar auf disruptive Ereignisse reagieren und ihren Betrieb aufrecht erhalten zu können. Anstatt sich von den Kosten zur Implementierung eines Resilienzplans abhalten zu lassen, sollten Unternehmen eine tiefergehende Analyse vornehmen und die tatsächlichen Kosten bewerten, wenn überhaupt kein Plan vorbereitet würde. Überprüfen Sie beispielsweise, welche Service Level Agreements (SLAs) nicht erfüllt werden könnten oder die Strafen und Umsatzeinbußen, die ein Ausfall mit sich bringen könnte. Vergleichen Sie die Kosten der Implementierung einer DR mit den Strafen, Umsatzeinbußen und dem Verlust des Kundenvertrauens und die Entscheidung ist eindeutig.

Das Bild trägt den Titel „Umsatz, Produktivität und verlorene Kundentreue.“ Auf dieser Abbildung sind drei Schlüsselstatistiken dargestellt. Diese Statistiken wurden 2019 aus einer Studie von Forrester Consulting im Auftrag von IBM abgeleitet. Die Umfrageteilnehmer sollten folgende Frage beantworten: „Welche der folgenden Kosten fallen bei Ihrem Unternehmen aufgrund geplanter oder ungeplanter Ausfallzeiten an?“
Auf der linken Seite zeigt die Statistik, dass 53 % der Befragten mit „Umsatzverlust“ antworteten. In der Mitte kann man sehen, dass 47 % mit „Produktivitätsverlust“ antworteten. Auf der rechten Seite zeigt die Statistik, dass 41 % mit „Verlust des Markenwerts und -vertrauens“ antworteten.

Ungeplante Ausfallzeiten

Ob der Ausfall nun durch eine Naturkatastrophe, Fehler des IT-Betreibers/Serviceanbieters, Datenbeschädigung oder Ransomware-Attacken verursacht wurde – ein Unternehmen muss sich selbst vor Störungen der Geschäftsabläufe schützen, da dies sonst zu katastrophalen Verlusten, einer Beschädigung der eignen Reputation und des Firmenwerts sowie dem Verlorengehen von Marktanteilen aufgrund opportunistischer Wettbewerber führen kann.

Auch wenn diese Konsequenzen dramatisch erscheinen, so spiegeln sie doch die Erfahrungen vieler bekannter Unternehmen wider, die nicht in der Lage waren, zeitnah ihre Daten wiederherzustellen und so große Mengen kritischer Transaktionsdaten, Kundeninformationen und Vertrauen verloren haben.

Eine Vielzahl von Szenarien und Ursachen können zur Störung der Geschäftsabläufe führen.

Dieses Bild trägt den Titel „Die wichtigsten Gründe für ungeplante Ausfallzeiten.“ Dieses Bild zeigt ein Balkendiagramm, das Gründe für ungeplante Ausfälle aufführt. Das Balkendiagramm ist in drei Kategorien aufgeteilt: betriebsbedingte Ausfälle, Naturkatastrophen und von Menschen verursachte Ereignisse. Die betriebsbedingten Ausfälle sind im linken Bereich des Balkendiagramms zusammengefasst, Naturkatastrophen in der Mitte und von Menschen verursachte Ereignisse sind im rechten Teil des Balkendiagramms aufgeführt. Die Quelle des Diagramms ist Forrester Research, Inc.

Geplante Ausfallzeiten

Disaster Recovery as a Service (DRaaS) in der Cloud bietet Unternehmen unvergleichliche Optionen für die betriebliche Flexibilität. Unternehmen nutzen Disaster Recovery-Lösungen für geplante Ausfallzeiten immer häufiger, um nach katastrophalen Ereignissen eine Wiederherstellung durchzuführen.

Typische Schwachstellen

• Traditionelle Ansätze zur Disaster Recovery erfordern Investitionen in Automatisierung.
• Selbst Geschäftssysteme in Tier 1-Datenzentren können durch Stromausfälle beeinträchtigt werden, wie sie nur allzu häufig auftreten. Wie oft schon hat ein nicht unüblicher Zwischenfall wie ein Stromausfall zu Produktivitätsverlusten von ein oder zwei Tagen geführt? IT-Mitarbeiter müssen viele Stunden oder gar viele Tage mit Telefonkonferenzen verbringen, um die Systeme mithilfe von Stopgap-Lösungen wieder zum Laufen zu bekommen. • Einige Unternehmen geben einen erheblichen Teil ihrer IT-Budgets für die Entwicklung einer betriebsinternen Automatisierung aus, um die Disaster Recovery zu verwalten, wagen es aber dann nicht , diese zu verwenden – oder gar nur regelmäßig zu testen, um sicherzustellen, das sie auch so funktioniert, wie geplant. • Oft erfordert es einen Tag (oder gar mehrere Tage), um nach einem geplanten Wartungsfenster eine Wiederherstellung durchzuführen. • Sogar gut dokumentierte DR-Pläne oder -Runbooks können zu tagelangen Produktivitätsverlusten führen und die IT-Teams müssen wahre Heldentaten vollbringen, um alles wieder zum Laufen zu bringen.

Wesentliche Ziele der Disaster Recovery

Die zwei Hauptziele der Disaster Recovery sind die schnellstmögliche Rückkehr betroffener Systeme zu einem normalen Betriebszustand und dass diese Wiederherstellung nach Katastrophenfällen oder einer geplanten Ausfallzeit mit so geringen Datenverlusten wie nur möglich geschieht. Die Metriken für diese zwei wesentlichen Ziele sind allgemein als das Ziel in Bezug auf die Rückgewinnungszeit (Recovery Time Objective, RTO) bzw. das Ziel in Bezug auf den Wiederherstellungspunkt (Recovery Point Objective, RPO) bekannt.

Bei jedem Geschäftssystem bestehen hinsichtlich dieser beiden Metriken unterschiedliche Anforderungen, je nachdem, welches Service Level Agreement zwischen dem IT-Bereich und den Unternehmenseigentümern gilt.

Das Bild trägt den Titel: „Datenschutzterminologie“. Die Toleranz für einen Datenverlust und die Toleranz für Ausfallzeiten sind auf einer geraden Linie dargestellt , die in entgegengesetzte Richtungen von der Mitte des Bildes aus verlaufen. Auf der linken Seite ist der „Datenverlust“ dargestellt auf der rechten die „Ausfallzeiten“.

Ziel in Bezug auf die Wiederherstellungszeit

Unter dem Ziel in Bezug auf die Wiederherstellungszeit versteht man die erforderliche Zeit zur Wiederherstellung eines Geschäftssystems zu einem vollständig operativen Zustand nach geplanten oder ungeplanten Ausfallzeiten.

Ziel in Bezug auf den Wiederherstellungspunkt

Unter dem Ziel in Bezug auf den Wiederherstellungspunkt (RPO) versteht man die maximale Menge an Daten, die verloren gehen kann, bevor es bei einem Geschäftssystem zu wesentlichen Beeinträchtigungen kommt. Der RPO wird üblicherweise als Zeit vom Delta des letzten Datenbackups, der letzten Datenreplikation oder des letzten Snapshots gemessen.

Disaster Recovery vs. High Availability

Traditionell schützt High Availability (HA) vor einzelnen Fehlerquellen, während die Disaster Recovery gegen mehrere Fehlerquellen schützt. Beim Cloud-Computing ist der Schutz gegen einzelne Fehlerquellen auf der Ebene der physischen Infrastruktur, einschließlich der Stromversorgung, Kühlung, dem Speicher, den Netzwerken und den physischen Servern durch Verfügbarkeit und Faultdomains im Rahmen der Gesamtarchitektur vollständig abstrahiert.

In diesem Fall ist High Availability skalierbar und hochresilient gegenüber Datenverlust und einem Verlust der Verarbeitungsleistung. Beinahe jeder Cloud-Anbieter der Unternehmensklasse bietet im Rahmen seines Angebots High Availability an.

High Availability-Lösungen für die Disaster Recovery, die einen Schutz ohne Datenverlust und ohne Ausfallzeiten bieten, sind oft teuer, wenn komplexe Datenzuordnungs- und Replikationstechnologien einbezogen werden. Diese Lösungen bieten keinen Schutz vor Ransomware, der stattdessen durch ein umfassendes Backup mit einem Ziel in Bezug auf den Wiederherstellungspunkt zu einem bestimmten Zeitpunkt und einem unveränderlichen Speicher sichergestellt werden muss.

Traditionelle High Availability-Lösungen funktionieren gut zusammen mit einer kostengünstigen Cloud-Data Recovery (CDR)-Lösung. Die Add-on-CDR-Technologie bietet eine zusätzliche Schutzebene für Datenbanken, bei denen eine High Availability ohne Datenverlust und ohne Ausfallzeiten erforderlich ist und die einen Schutz vor Ransomware mit einem langfristigen inkrementellen Rollback benötigen.

Eine On-Premises-DR ist eine unflexible und teure Lösung, da die Duplizierung der IT-Infrastruktur an einem Quellenstandort und einem festen Zielstandort des Datenzentrums mit hohen Kosten verbunden ist. Sie kann nicht über das WAN ausgeführt werden oder zwischen den Servern getrennter Umgebungen migrieren. Deshalb erfordert sie eine dedizierte Verbindung zwischen den Quell- und Zieldatenzentren, um wie eine einzelne vernetzte LAN-Umgebung fungieren zu können. Eine traditionelle DR kann auch nicht zwischen den Servern getrennter heterogener Umgebungen migrieren, wie etwa einer On-Premises-Umgebung und einer Cloud-Plattform oder zwischen zwei verschiedenen Cloud-Plattformen.

DRaaS verwendet ein Patchwork von Anbieter-Backup-Lösungen und Open Source-Migrationstools, um eine streng kontrollierte und hochgradig spezifische Umgebung zu erstellen. Der Endbenutzer kann so nur Workloads wiederherstellen, die sich in der traditionellen Hosting-Umgebung der VMware-On-Premises-Umgebung des DRaaS-Anbieters befinden. Diese Anbieterlösungen sind oft teuer und in Bezug auf die Workloads, die sie schützen, und die Compute-Umgebungen, die sie unterstützen können, eingeschränkt.

DR-Workflows, -Runbooks und -Pläne

Oracle bezeichnet einen DR-Workflow üblicherweise als DR-Plan. Bei einem Disaster Recovery-Plan – oder -Runbook – handelt es sich um eine Liste vordefinierter Schritte oder Aufgaben, die ausgeführt werden müssen, um die Compute-Instanz, Plattform, Datenbank und Anwendungen zu einer vordefinierten Recovery-Region in der Cloud zu migrieren. Das umfasst alle Aufgaben oder Einzelschritte, die entweder von einem Menschen oder durch irgendeine Form der Automatisierung während eines Disaster Recovery-Ablaufs wie einem Switchover oder einem Failover durchgeführt werden müssen. Die Begriffe „DR-Plan“, „DR-Runbook“ und „DR-Workflow“ sind synonym.

DR-Abläufe (Switchover vs. Failover)

Unter einem Disaster Recovery-Ablauf versteht man die Ausführung aller einzelnen vordefinierten Schritte oder Aufgaben in einem DR-Plan, die erforderlich sind, um die Infrastruktur, die Datenbank und die Anwendungen zur vollen Funktionalität wiederherzustellen. Für den den Wechsel eines Anwendungs-Stacks zu einem anderen Standort werden zwei verschiedene Begriffe verwendet.

Failover

Ein Failover impliziert eine ungeplante Ausfallzeit, bei der Anwendungen, Datenbanken und virtuelle Maschinen abgestürzt sind und sich sämtliche Ressourcen einschließlich des Speichers, der Daten und Gastbetriebssysteme in einem inkonsistenten Zustand befinden. In diesem Fall geht man davon aus, dass die primäre Cloud-Region vollkommen unzugänglich und nicht verfügbar ist, was darauf hinweist, dass ein vollständiger Disaster Recovery-Ablauf gestartet werden muss.

Daher können alle Aufgaben für die Disaster Recovery nur in der Standby-Cloud-Region ausgeführt werden. Es ist unabdingbar, dass die DRaaS-Lösung des Cloud-Anbieters in der Standby-Region auf High Availability ausgelegt ist, um sicherzustellen, dass sie zugänglich und funktional ist, wenn es zu einem Katastrophenfall kommt.

Umstellung

Ein Switchover impliziert eine geplante Ausfallzeit, die ein ordnungsgemäßes Herunterfahren von Anwendungen, Datenbanken und virtuellen Maschinen oder Servern beinhaltet. In diesem Fall werden sowohl die primäre wie auch die Standby-Region normal ausgeführt und das IT-Team konzentriert sich wahrscheinlich auf das „Verschieben“ eines oder mehrerer Systeme von einer Region zu einer anderen für Wartungszwecke oder für den Abschluss von Rolling-Upgrades.

Cloud-Bereitstellungsstrategie

Moderne Unternehmen können aus unterschiedlichen Gründen von einem oder mehreren der folgenden Cloud-Bereitstellungsmodelle profitieren. Die Vorteile können sich auf die Kosten, Performance oder auch die Anforderungen in Bezug auf die Geschäftskontinuität beziehen. Eine robuste Cloud-Bereitstellungsstrategie wird immer mehr zur vorherrschenden Herangehensweise, da Unternehmen Abläufe zunehmend in die Cloud verlagern.

Regionsübergreifende DR-Lösungen

Regionsübergreifende Disaster Recovery-Lösungen schützen Unternehmen vor vollständigen Ausfällen die sich auf den Zugriff auf Geschäftssysteme, die in der Cloud-Infrastruktur eines einzelnen Cloud-Anbieters gehostet sind, auswirken könnten. Wie der Name schon andeutet, kann dabei ein vollständiger Anwendungs-Stack eines beliebigen Geschäftssystems, einschließlich virtueller Maschinen, Datenbanken und Anwendungen, bei Bedarf auf eine vollständig verschiedene Cloud-Region in einem anderen geografischen Gebiet migriert werden.

DRaaS-Lösungen sollten in der Lage sein, ein vollständiges Unternehmenssystem wie ein Human Resources-Portal, ein Portal für Finanzdienstleistungen oder eine Enterprise Resource Management-Anwendung in eine vollständig andere Cloud-Region zu verlagern. Ein DRaaS sollte die Ziele in Bezug auf die Wiederherstellungszeit und den Wiederherstellungspunkt, die bei jeder einzelnen Anwendung durch das Service Level Agreement festgelegt sind, erfüllen können.

Regionsübergreifende DR-Lösungen wie Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery schützen ganze Unternehmensanwendungen vor einem katastrophalen Verlust des Zugangs zu einer ganzen Cloud-Region, einschließlich des Verlustes aller Availability-Domains in dieser Region.

Hybrid Cloud-DR-Lösungen

Eine Hybrid Cloud-DR ist eine sehr beliebte Lösung, die es Unternehmen ermöglicht, Workloads und virtuelle Maschinen von ihren eigenen Datenzentren in eine Cloud-Infrastruktur zu verlagern. Oft wird als Disaster Recovery-Lösung eine Hybrid Cloud verwendet, um die Daten und die Funktionsfähigkeit der kritischen Geschäftssysteme des Unternehmens zu schützen.

Für Kunden von Oracle stellt sich die Hybrid Cloud als ein loser Zusammenschluss von OCI, physischen Servern, Oracle Cloud-Anwendungen oder anderen Systemen im physischen Datenzentrum eines Unternehmens dar. Oracle Cloud-Anwendungen wie Oracle Private Cloud Appliance X9-2 und Oracle Exadata Cloud@Customer sind hervorragende Beispiele für On-Premises-Systeme, die sich gut mit OCI integrieren lassen.

Einige Produkte von Partnern von Oracle wie Rackware können verwendet werden, um eine DR zwischen der On-Premises-Infrastruktur und OCI zu erzielen. Rackware ist über den Oracle Cloud Marketplace verfügbar.

Multicloud-DR-Lösungen

Multicloud-DR-Lösungen schützen Anwendungen und Daten durch die Verteilung der verschiedenen Komponenten eines Anwendungs-Stacks über die Cloud-Infrastrukturen von zwei oder mehreren Cloud-Anbietern. Die Partnerschaft von Oracle mit Microsoft Azure ist ein gutes Beispiel für eine Multicloud-Beziehung.

Disaster Recovery as a Service sollte in der Lage sein, regionsübergreifende DR, Hybrid Cloud-DR und Multicloud-DR zu ermöglichen. OCI kann derzeit eine DRaaS für regionsübergreifende DR und Hybrid Cloud-DR bereitstellen.

Datenkonsistenz für Datenbanken

Tragfähige Disaster Recovery-Lösungen, die Datenbanken beinhalten, sollte immer auch Möglichkeiten beinhalten, um die Datenkonsistenz sicherzustellen. Der Punkt, an dem eine Datenbank zur vollen Datenkonsistenz, einschließlich laufender Transaktionen, wiederhergestellt werden kann, dient als Definition für das Ziel in Bezug auf den Wiederherstellungspunkt.

Die Datenkonsistenz stellt für serverlose oder Flat File-Datenbaken ein weit geringeres Problem dar. Aber die Wiederherstellung hochentwickelter relationaler Datenbanken wie Oracle Database oder MySQL zu einem datenkonsistenten Zustand in Bezug auf einen bestimmten Zeitpunkt ist überaus komplex – aber eben auch unerlässlich.

Überlegungen zur Disaster Recovery bei MySQL-Datenbanken

Bei der Verwendung des MySQL Database Service in OCI ist das MySQL-Datenbanksystem ein logischer Container für eine oder mehrere MySQL-Instanzen. Es stellt dabei eine Schnittstelle zur Verfügung, welche die Verwaltung von Aufgaben wie dem Provisioning, automatischen Backups und zeitpunktbezogenen Wiederherstellungen ermöglicht.

MySQL-Binärlog- und native Replikationstechnologien ermöglichen eine zeitpunktbezogene Wiederherstellung, High Availability und Disaster Recovery. MySQL Group Replication wird allgemein verwendet, um lokale fehlertolerante Cluster für High Availability zu erstellen, während die asynchrone MySQL-Replikation üblicherweise für eine geoverteilte Disaster Recovery genutzt wird.

Bei einem Datenbanksystem mit aktivierter High Availability sind drei MySQL-Instanzen in verschiedenen Availability- oder Faultdomains platziert. Das Datenbanksystem garantiert beim Ausfall einer Instanz, dass eine andere übernimmt und es dabei zu keinen Datenverlusten und nur zu minimalen Ausfallzeiten kommt. Für die Disaster Recovery in verschiedenen Regionen können auch eingehende Replikationskanäle zwischen zwei Datenbanksystemen erstellt werden.

Nutzen Sie die folgenden Links, um mehr über die Disaster Recovery für MySQL in der Cloud zu erfahren.

• Überblick zur Geschäftskontinuität für MySQL
• Überblick zur High Availability für MySQL
• Überblick zur eingehenden Replikation für MySQL

Aspekte bei der Disaster Recovery für Oracle Databases

Oracle Maximum Availability Architecture (MAA) bietet die Architektur, Konfiguration und die Best Practices in Bezug auf den Lebenszyklus für Oracle Databases. Das ermöglicht Service-Levels mit High Availability für Datenbanken, die sich On-Premises, in der Cloud oder hybriden Konfigurationen befinden.

Nutzen Sie die folgenden Links, um mehr über Oracle Maximum Availability Architecture für die Disaster Recovery in der Cloud zu erfahren.

• Oracle Maximum Availability Architecture – Landingpage
• Oracle Maximum Availability Architecture – Referenzarchitekturen
• Oracle Maximum Availability Architecture – Best Practices für Oracle Fusion Middleware
• Oracle Maximum Availability Architecture – Best Practices für Anwendungen

Cloudbasierte Bereitstellungsarchitekturen

Eine Bereitstellungsarchitektur beschreibt, wie verschiedene Komponenten wie Compute, Plattform/Datenbank und Anwendungen zwischen Cloud-Regionen bereitgestellt werden, um eine resiliente Möglichkeit zur Wiederherstellung nach einem Totalausfall eines Datenzentrums sicherzustellen. Die Bereitstellungsarchitektur beschreibt dabei, wo sich alles während des normalen Betriebs einer Anwendungs-Suite befindet und was in der Standby-Region wiederhergestellt werden muss, um den normalen Betrieb wieder aufzunehmen.

Oracle ist der Überzeugung, dass DRaaS-Lösungen über die Flexibilität verfügen sollten, jede Kombination von DR-Bereitstellungsarchitekturen zu integrieren, um die einzelnen Service Level Agreements aller Geschäftssysteme erfüllen zu können. Cloud-Anbieter sollten ihren Kunden die Freiheit bieten, alle oben genannten Lösungen wählen zu können, um die SLAs für die vielen verschiedenen Geschäftssysteme zu erfüllen, die Unternehmen üblicherweise nutzen.

Zur Beschreibung von DR-Strategien und Bereitstellungsarchitekturen werden viele Begriffe verwendet. Aber die verschiedenen Ansätze und Muster zur Beschreibung wie die Infrastruktur, Plattform und Anwendungen für die Disaster Recovery bereitgestellt werden sollten, fallen in zwei große Kategorien: Aktiv/Aktiv- und Aktiv/Standby-DR.

Die folgende Tabelle führt die üblichen Begriffe auf, die zur Beschreibung von Bereitstellungsarchitekturen verwendet werden, die einer der beiden großen DR-Strategien zugeordnet werden können.

Strategie	Bereitstellungsarchitektur	RPO	RTO
Aktiv/Standby	Cold Standby	Stunden	Stunden
Aktiv/Standby	Pilotflamme	Minuten	Stunden
Aktiv/Standby	Warm Standby	Sekunden	Stunden
Aktiv/Standby	Hot Standby	Sekunden	Minuten
Aktiv/Aktiv	Aktiv/Aktiv	Nahe Null	Nahe Null

Dieser Abschnitt versucht ein wenig, den Schleier in Bezug auf die Variationen bei Aktiv/Aktiv- und Aktiv/Standby-Ansätzen für die Disaster Recovery zu lüften. Beide Strategien für die Disaster Recovery haben ihren Platz unter den Maßnahmen zur Sicherstellung der Geschäftskontinuität.

Aktiv/Standby-Bereitstellungsarchitekturen

Es gibt zahlreiche Varianten an Aktiv/Standby-Bereitstellungsarchitekturen. Aktiv/Standby-Bereitstellungen, die manchmal auch Aktiv/Passiv-Bereitstellungen genannt werden, werden oft als Pilotflammen- sowie Cold, Warm und Hot Standby-Bereitstellungen bezeichnet.

Dabei stellen Pilotflammen-, Cold Standby-, Warm Standby- und Hot Standby-Szenarien alle irgendeine Form des selben Aufbaus dar, bei dem 100 % eines Anwendungs-Stacks in der primären Region ausgeführt wird, während weniger als 100 % des selben Geschäftssystems aktiv in der Standby-Region ausgeführt werden.

Die folgende Reihe von sehr allgemeinen Konzeptdiagrammen soll einige fundamentale Unterschiede zwischen üblichen Bereitstellungsarchitekturen veranschaulichen. Sie eignen sich nicht als Referenzarchitekturen und beschreiben nicht, wie eine DR für einen Anwendungs-Stack implementiert werden kann.

Cold Standby

In diesem Szenario existieren die virtuellen Maschinen (VMs), die Datenbank und die Anwendungen nur in der derzeitigen primären Region. Die Datei- und Blockspeicher-Volume-Gruppen, welche den Bootdatenträger und jeden beliebigen weiteren virtuellen Datenträger für die jeweiligen VMs enthalten, werden in der Standby-Region repliziert.

Zeigt ein Bild mit der primären Region auf der linken Seite und der Standby-Region auf der rechten Seite. Die primäre Region beinhaltet drei Blöcke: Anwendung, Datenbank und Infrastruktur, jeweils mit ihren Symbolen. Bei beiden Regionen repräsentiert ein Symbol an der Oberseite einen Load Balancer. Das Symbol für den Load Balancer in der Standby-Region ist in einer helleren Farbe als das der primären Region. Die Standby-Region beinhaltet drei Blöcke: Anwendung, Datenbank und Infrastruktur. In der Standby-Region befinden sich nur im Infrastrukturblock Symbole – jeweils eines für den Objektspeicher, den Blockspeicher und den Dateispeicher. Die Datenbank- und Anwendungsblöcke in der Standby-Region sind leer. Zwei Pfeile repräsentieren die Replikation des Objektspeichers und die Speicherreplikation wird dabei zwischen den beiden Infrastrukturblöcken angezeigt. Diese Pfeile stellen die Replikation von der primären zur Standby-Region dar.

Während eines DR-Ablaufs wie einem Switchover oder einem Failover wird der replizierte Speicher, der dieselben VMs enthält, in der Standby-Region aktiviert und genau dieselben VMs werden wieder an dem Punkt gestartet, an dem sie angehalten wurden oder abgestürzt sind. Bei den VMs handelt es sich um genau dieselben virtuellen Maschinen, die zuvor in der aktiven Region ausgeführt worden sind.

Diese Bereitstellungsarchitektur beinhaltet verschiedene Vorteile, einschließlich geringerer Bereitstellungskosten, geringerer Gemeinkosten für die Wartung und niedrigerer Betriebskosten. Allerdings stellt sie möglicherweise nicht die beste Lösung für Anwendungen dar, die auf relationalen Datenbanken für das Backend basieren, da die einzige Möglichkeit, die Datenkonsistenz sicherzustellen, in der Ausführung regelmäßiger Coldbackups besteht. Dieser Ansatz eignet sich gut für Anwendungen, die gelegentliche kurze Totalausfälle tolerieren können.

Die meisten IT-Abteilungen lösen dieses Problem durch das regelmäßige Herunterfahren der Datenbank, wobei ein Snapshot des Blockspeichers genommen wird, und der anschließenden Wiederaufnahme des Normalbetriebs. Das definiert das Ziel in Bezug auf den Wiederherstellungspunkt, denn man kann nur bis zu dem Zeitpunkt eine Wiederherstellung durchführen, an dem das Backup abgeschlossen wurde.

Diese Architektur zeichnet sich durch eine etwas längere Wiederherstellungszeit aus und es besteht ein wesentlich größeres Risiko eines Datenverlusts. Aber für passende Workloads handelt es sich dabei um eine tragfähige Lösung. Zum Beispiel wäre dies eine hervorragende Lösung für Anwendungen, die auf einer Flat File-Datenbank oder gar keiner Datenbank basieren, zum Beispiel bei Kunden, die einfach nur einen Satz virtueller Maschinen zwischen zwei Regionen mobil machen wollen, um die Flexibilität zu erhöhen.

Beispielhafte DR-Workflows für diese Bereitstellungsarchitektur

Die folgenden beiden Szenarios skizzieren, wie der Prozessfluss für DR-Abläufe bei Cold Standby-Bereitstellungen ablaufen könnte.

Bei einem Switchover werden die folgenden Aufgaben sowohl in der primären Region wie auch in der Standby-Region ausgeführt:

• Die Primäranwendungen werden stillgelegt.
• Die Primärdatenbanken werden stillgelegt und mit der Standby-Region synchronisiert.
• Die primären virtuellen Maschinen werden angehalten.
• Der primäre Speicher wird mit der Standby-Region synchronisiert.
• Der replizierte Speicher wird online gestellt, die Replikation wird umgekehrt und der Speicher in der Standby-Region ist nun primär.
• Die replizierten Kopien der primären virtuellen Maschinen werden gestartet und alle Systemanwendungen und Tools, die für den Anwendungs-Stack erforderlich sind, werden ebenfalls hochgefahren, sodass sie nun in der Standby-Region primär sind.
• Die replizierten Kopien der primären Datenbanken werden in der Standby-Region mittels des aktuellsten Coldbackups oder der aktuellen Transaktion und Redo-Logs aus dem replizierten Speicher wiederhergestellt
• Die replizierten Kopien der primären Datenbanken werden gestartet und gemountet und sind nun in der Standby-Region primär.
• Die replizierten Kopien der primären Anwendungen werden gestartet und validiert und sind nun in der Standby-Region primär.
• Am DNS und an den Load Balancern werden die erforderlichen Änderungen vorgenommen, um den Zugriff auf die Anwendung über das öffentlich zugängliche Netzwerk zu ermöglichen.

Im Fall eines Failovers werden die folgenden Aufgaben nur in der Standby-Region ausgeführt.

• Der replizierte Speicher wird online gestellt, die Replikation wird umgekehrt und der Speicher in der Standby-Region ist nun primär.
• Die replizierten Kopien der primären virtuellen Maschinen werden gestartet und alle Systemanwendungen und Tools, die für den Anwendungs-Stack erforderlich sind, werden ebenfalls hochgefahren, sodass sie nun in der Standby-Region primär sind.
• Die replizierten Kopien der primären Datenbanken werden in der Standby-Region mittels des aktuellsten Coldbackups oder der aktuellen Transaktion und Redo-Logs aus dem replizierten Speicher wiederhergestellt
• Die replizierten Kopien der primären Datenbanken werden gestartet und gemountet und sind nun in der Standby-Region primär.
• Die replizierten Kopien der primären Anwendungen werden gestartet und validiert und sind nun in der Standby-Region primär.
• Am DNS und an den Load Balancern werden die erforderlichen Änderungen vorgenommen, um den Zugriff auf die Anwendung über das öffentlich zugängliche Netzwerk zu ermöglichen.

Warm Standby

In diesem Szenario existieren virtuelle Maschinen sowohl in der primären wie auch in der Standby-Region. Aber sie sind vollständig unabhängig voneinander und verfügen über ihre eigenen individuellen Hostnamen und vorab zugewiesene IP-Adressen. Die in der Standby-Region existierenden VMs können je nach Kundenpräferenz angehalten werden oder weiterlaufen.

Zeigt ein Bild mit der primären Region auf der linken Seite und der Standby-Region auf der rechten Seite. Die primäre Region weist drei Blöcke auf: Anwendung, Datenbank und Infrastruktur. Jeder beinhaltet dabei seine jeweiligen Symbole. Bei beiden Regionen repräsentiert ein Symbol an der Oberseite einen Load Balancer. Das Symbol für den Load Balancer in der Standby-Region ist in einer helleren Farbe als das der primären Region. Die Standby-Region beinhaltet drei Blöcke: Anwendung, Datenbank und Infrastruktur. In der Standby-Region sind dem Infrastrukturblock ebenfalls Symbole zugeordnet – eines jeweils für den Objektspeicher, den Blockspeicher und den Dateispeicher. Außerdem gibt es ein Symbol für virtuelle Maschinen auf der Ebene der Infrastruktur, dieses ist jedoch heller. Die Datenbank- und Anwendungssymbole in der Standby-Region sind ebenfalls heller. Zwei Pfeile repräsentieren die Replikation des Objektspeichers und die Speicherreplikation wird dabei zwischen den beiden Infrastrukturblöcken angezeigt. Diese Pfeile stellen die Replikation von der primären zur Standby-Region dar.

Die Datenbanken sollten sowohl in den primären wie auch den Standby-Regionen ausgeführt werden.

Für Oracle Databases empfehlen wir Oracle Data Guard, um die primären und Standby-Datenbanken zu replizieren. Ziehen Sie für weitere Details unsere Gold MAA-Referenzarchitektur zu Rate.

Für Datenbanken von anderen Anbietern als Oracle werden die jeweiligen nativen Replikationstechnologien angewandt, um die Datenbanken zwischen der primären und der Standby-Region synchron zu halten.

Anwendungen existieren auch in der Standby-Cloudregion, aber sie werden nicht ausgeführt und es kann auf sie auch nicht zugegriffen werden.

Beispielhafte DR-Workflows für diese Bereitstellungsarchitektur

Die folgenden zwei Szenarien skizzieren, wie der Prozessfluss für DR-Abläufe bei Warm Standby-Bereitstellungen vonstatten gehen könnte.

Bei einem Switchover werden die folgenden Aufgaben sowohl in der primären Region wie auch in der Standby-Region ausgeführt:

• Die Primäranwendungen werden stillgelegt.
• Die Primärdatenbanken werden stillgelegt und mit der Standby-Region synchronisiert.
• Die primären virtuellen Maschinen werden angehalten.
• Der primäre Speicher wird mit der Standby-Region synchronisiert.
• Der replizierte Speicher wird online gestellt, die Replikation wird umgekehrt und der Speicher in der Standby-Region ist nun primär.
• Es werden Standby-virtuelle Maschinen gestartet, falls sie nicht schon bereits ausgeführt werden. Auch sämtliche Systemanwendungen oder Tools, die vom Anwendungs-Stack benötigt werden, werden hochgefahren und sind nun in der Standby-Region primär.
• Die Standby-Datenbanken werden auf den vollständigen Lese-/Schreibzugriff umgestellt und sind nun in der Standby-Region primär.
• Die Standby-Anwendungen werden gestartet und validiert und sind nun in der Standby-Region primär.
• Am DNS und an den Load Balancern werden die erforderlichen Änderungen vorgenommen, um den Zugriff auf die Anwendung über das öffentlich zugängliche Netzwerk zu ermöglichen.

Im Fall eines Failovers werden die folgenden Aufgaben nur in der Standby-Region ausgeführt.

• Der replizierte Speicher wird online gestellt, die Replikation wird, falls möglich, umgekehrt und der Speicher ist in der Standby-Region nun primär.
• Es werden Standby-virtuelle Maschinen gestartet, falls sie nicht schon bereits ausgeführt werden. Auch sämtliche Systemanwendungen oder Tools, die vom Anwendungs-Stack benötigt werden, werden hochgefahren und sind nun in der Standby-Region primär.
• Die Standby-Datenbanken werden mithilfe der aktuellsten Transaktion und Redo-Logs aus dem replizierten Speicher wiederhergestellt.
• Die Standby-Datenbanken werden auf den vollständigen Lese-/Schreibzugriff umgestellt und sind nun in der Standby-Region primär.
• Die Standby-Anwendungen werden gestartet und validiert und sind nun in der Standby-Region primär.
• Am DNS und an den Load Balancern werden die erforderlichen Änderungen vorgenommen, um den Zugriff auf die Anwendung über das öffentlich zugängliche Netzwerk zu ermöglichen.

Hot Standby

In diesem Szenario existieren virtuelle Maschinen sowohl in den primären wie auch Standby-Regionen und werden dort mit ihren individuellen Hostnamen und vorab zugewiesenen IP-Adressen ausgeführt.

Zeigt ein Bild mit der primären Region auf der linken Seite und der Standby-Region auf der rechten Seite. Die primäre Region weist drei Blöcke auf: Anwendung, Datenbank und Infrastruktur. Jeder beinhaltet dabei seine jeweiligen Symbole. Bei beiden Regionen repräsentiert ein Symbol an der Oberseite einen Load Balancer. Das Symbol für den Load Balancer in der Standby-Region ist in einer helleren Farbe als das der primären Region. Die Standby-Region beinhaltet drei Blöcke: Anwendung, Datenbank und Infrastruktur. Sowohl bei den primären wie auch bei den Standby-Regionen befinden sich Symbole in den Anwendungs-, Datenbank- und Infrastrukturblöcken. Der Infrastrukturblock weist Symbole für virtuelle Maschinen, Dateispeicher, Objektspeicher und Blockspeicher auf, und zwar sowohl in den primären wie auch in den Standby-Regionen. Nur die Datenbanksymbole in der Standby-Region sind dabei heller. Zwei Pfeile repräsentieren die Replikation des Objektspeichers und die Speicherreplikation wird dabei zwischen den beiden Infrastrukturblöcken angezeigt. Diese Pfeile stellen die Replikation von der primären zur Standby-Region dar.

Die Datenbanken sollten sowohl in den primären wie auch den Standby-Regionen ausgeführt werden.

Für Oracle Databases empfehlen wir Oracle Data Guard, um die primären und Standby-Datenbanken zu replizieren. Ziehen Sie für weitere Details unsere Gold MAA-Referenzarchitektur zu Rate.

Für Datenbanken von anderen Anbietern als Oracle werden die jeweiligen nativen Replikationstechnologien angewandt, um die Datenbanken zwischen der primären und der Standby-Region synchron zu halten.

Anwendungen werden zwar in der Standby-Cloudregion ausgeführt, sind aber nicht über das öffentliche Netzwerk zugänglich.

Beispielhafte DR-Workflows für diese Bereitstellungsarchitektur

Die folgenden beiden Szenarien skizzieren, wie der Prozessfluss für DR-Abläufe bei Hot Standby-Bereitstellungen vonstatten gehen könnte.

Bei einem Switchover werden die folgenden Aufgaben sowohl in der primären Region wie auch in der Standby-Region ausgeführt:

• Die Primäranwendungen werden stillgelegt.
• Die Primärdatenbanken werden stillgelegt und mit der Standby-Region synchronisiert.
• Die primären virtuellen Maschinen werden angehalten.
• Der primäre Speicher wird mit der Standby-Region synchronisiert.
• Der replizierte Speicher wird online gestellt, die Replikation wird umgekehrt und der Speicher in der Standby-Region ist nun primär.
• Die Standby-virtuellen Maschinen werden bereits ausgeführt und alle Systemanwendungen und Tools ,die vom Anwendungs-Stack benötigt werden, sind nun in der Standby-Region primär.
• Die Standby-Datenbanken werden auf den vollständigen Lese-/Schreibzugriff umgestellt und sind nun in der Standby-Region primär.
• Die Standby-Anwendungen werden gestartet und validiert und sind nun in der Standby-Region primär.
• Am DNS und an den Load Balancern werden die erforderlichen Änderungen vorgenommen, um den Zugriff auf die Anwendung über das öffentlich zugängliche Netzwerk zu ermöglichen.

Im Fall eines Failovers werden die folgenden Aufgaben nur in der Standby-Region ausgeführt.

• Der replizierte Speicher wird online gestellt, die Replikation wird, falls möglich, umgekehrt und der Speicher ist in der Standby-Region nun primär.
• Es werden Standby-virtuelle Maschinen gestartet, falls sie nicht schon bereits ausgeführt werden. Auch sämtliche Systemanwendungen oder Tools, die vom Anwendungs-Stack benötigt werden, werden hochgefahren und sind nun in der Standby-Region primär.
• Die Standby-Datenbanken werden mithilfe der aktuellsten Transaktion und Redo-Logs aus dem replizierten Speicher wiederhergestellt.
• Die Standby-Datenbanken werden auf den vollständigen Lese-/Schreibzugriff umgestellt und sind nun in der Standby-Region primär.
• Die Standby-Anwendungen werden gestartet und validiert und sind nun in der Standby-Region primär.
• Am DNS und an den Load Balancern werden die erforderlichen Änderungen vorgenommen, um den Zugriff auf die Anwendung über das öffentlich zugängliche Netzwerk zu ermöglichen.

Aktiv/Aktiv-Bereitstellungsarchitektur

In diesem Szenario ist der vollständige Anwendungs-Stack voll funktionsfähig und verarbeitet eine Workload sowohl in den primären wie auch in den Standby-Regionen.

Zeigt ein Bild mit der primären Region auf der linken Seite und der Standby-Region auf der rechten Seite. Die primäre und die Standby-Region weisen jeweils drei Blöcke auf: Anwendung, Datenbank und Infrastruktur, die jeweils spezifische Symbole beinhalten. Bei beiden Regionen repräsentiert ein Symbol an der Oberseite einen Load Balancer. Keines davon ist ausgegraut. Die Symbole in den Anwendungs-, Datenbank- und Infrastrukturblöcken in den primären und Standby-Regionen sind jeweils farbig dargestellt. Ein Pfeil steht für eine optionale Speicherreplikation und ist zwischen den zwei Infrastrukturblöcken dargestellt. Dieser Pfeil steht für die Replikation von der primären zur Standby-Region.

Die Datenbanken sollten sowohl in den primären wie auch den Standby-Regionen ausgeführt werden.

Für Oracle Databases empfehlen wir für eine Aktiv/Aktiv-Konfiguration Oracle GoldenGate. Zusätzlich dazu empfehlen wir, in jeder Region mit Oracle Data Guard lokale Standby-Datenbanken einzurichten, um ein RTO und RPO von nahezu Null zu erreichen. Ziehen Sie für weitere Details unsere Platin-MAA-Referenzarchitektur zu Rate.

Für Datenbanken von anderen Anbietern als Oracle werden die jeweiligen nativen Replikations- und Aktiv/Aktiv-Technologien verwendet, um die Datenbank zwischen den primären und Standby-Regionen synchron zu halten.

Die Anwendungen werden ausgeführt und sind über das öffentliche Netzwerk in der Standby-Region zugänglich. Dabei haben sie eine aktive Workload.

Automatisierung von Disaster Recovery-Aufgaben mit DRaaS

Die Teams von Oracle haben keine Mühen gescheut, um bei unseren Produkten High Availability bereitzustellen. Das beinhaltet auch die überwiegende Mehrheit der Datenbanken der Unternehmensklasse von Oracle. Wir stellen oft auch Best Practices und Bereitstellungsarchitekturen zur Verfügung, um eine Disaster Recovery in traditionellen On-Premises-Umgebungen wie auch in der Cloud sicherzustellen. Bei jeder Produktlinie wird ein DR-Ansatz für die einzelnen Anwendungen entwickelt, der lose miteinander verbundene Schritte umfasst, wie alle Komponenten, die zur Unterstützung einer Anwendung erforderlich sind, wiederhergestellt werden können.

Eine cloudbasierte Disaster Recovery as a Service kann alle lose verknüpften Schritte, die von Entwicklern, Cloud-Architekten und Produktlösungsarchitekten entwickelt wurden, in einen einzelnen nahtlosen Workflow zusammenführen, der mit einem einzigen Klick gestartet werden kann. OCI bietet eine DRaaS-Lösung namens Full Stack Disaster Recovery, die flexibel, hochskalierbar und hochgradig erweiterbar ist.

OCI Full Stack Disaster Recovery verwaltet mit einem Klick den Übergang von Infrastruktur, Datenbanken und Anwendungen zwischen OCI-Regionen auf der ganzen Welt. Die Kunden können dabei Disaster Recovery-Umgebungen bereitstellen, ohne bestehende Infrastrukturen, Datenbanken oder Anwendungen neu entwerfen oder neu bereitstellen zu müssen. Dadurch werden auch ein spezialisiertes Management oder Konvertierungsserver unnötig.

• Mehr über OCI Full Stack Disaster Recovery erfahren
• Mehr über Disaster Recovery für OCI