Freigeben über


Geschäftskontinuität und Notfallwiederherstellung für Oracle in Azure Virtual Machines Zielzonenbeschleuniger

Dieser Artikel baut auf den Überlegungen und Empfehlungen auf, die im Entwurfsbereich der Azure-Zielzone für Geschäftskontinuität und Notfallwiederherstellung (Business Continuity and Disaster Recovery, BCDR) definiert sind. Dieser Artikel folgt dieser Anleitung und beschreibt Entwurfsüberlegungen und bewährte Methoden zu BCDR-Optionen für Oracle-Workloadbereitstellungen auf virtuellen Computern (VMs) der Azure-Infrastruktur.

Azure bietet Dienste, mit denen Sie hochverfügbare und resiliente Architekturen entwerfen können. In diesem Leitfaden werden verschiedene Optionen und bewährte Methoden beschrieben, die Sie beim Entwerfen von Hochverfügbarkeit und Notfallwiederherstellung für Oracle-Datenbanken im Zielzonenbeschleuniger für Azure Virtual Machines unterstützen. Außerdem wird beschrieben, wie Sie begleitende Azure-Dienste konfigurieren, um eine hohe End-to-End-Verfügbarkeit für Ihre Lösung zu erreichen.

Loslegen

Um eine ausfallsichere Architektur für Ihre Workload-Umgebung zu erstellen, ermitteln Sie die Verfügbarkeitsanforderungen für Ihre Lösung basierend auf dem Recovery Time Objective (RTO) und dem Recovery Point Objective (RPO) für verschiedene Fehlerstufen. RTO ist die maximale Zeit, die eine Anwendung nach dem Auftreten eines Vorfalls nicht verfügbar ist. RPO ist die maximale Menge an Datenverlust während einer Katastrophe. Nachdem Sie die Anforderungen für Ihre Lösung ermittelt haben, entwerfen Sie Ihre Architektur so, dass die festgelegten Resilienz- und Verfügbarkeitsstufen bereitgestellt werden.

Oracle in Azure-Workloads verwenden in erster Linie Oracle Data Guard, eine integrierte Oracle Database Enterprise Edition-Funktion, die Replikationstechnologie verwendet. Sie können Data Guard verwenden, um Anforderungen an Hochverfügbarkeit und Notfallwiederherstellung zu erfüllen. Data Guard bietet drei Schutzmodi: maximale Leistung, maximale Verfügbarkeit und maximaler Schutz. Wählen Sie Ihren Schutzmodus basierend auf Ihrem Architekturentwurf und Ihren spezifischen RPO- und RTO-Anforderungen.

Konfigurieren Ihrer Workload für Hochverfügbarkeit

Azure Virtual Machines-Instanzen, die Oracle-Workloads ausführen, profitieren von der Azure Virtual Machine Scale Sets-Architektur, insbesondere vom flexiblen Orchestrierungsmodus. Eine Hochverfügbarkeitskonfiguration ermöglicht eine Datenreplikation nahezu in Echtzeit mit potenziell schnellen Failover-Funktionen. Eine Hochverfügbarkeitskonfiguration bietet keinen Schutz vor Fehlern auf Azure-Rechenzentrums- oder Regionsebene.

Wählen Sie die richtige Option für hohe Verfügbarkeit

Verwenden Sie das folgende Flussdiagramm, um die beste Hochverfügbarkeitsoption für Ihre Oracle-Datenbank auszuwählen.

Diagramm, das die Prozesszuordnung zum Servicedesign-Schutz von Oracle im Zielzonenbeschleuniger für virtuelle Maschinen zeigt.

Verwenden von Data Guard im Modus mit maximaler Verfügbarkeit für hohe Verfügbarkeit

Data Guard im Modus "Maximale Verfügbarkeit" bietet die höchste Verfügbarkeit mit einer Zusage von null Datenverlust (RPO=0) für den normalen Betrieb. Für eine hochverfügbare Konfiguration von zwei Oracle-Datenbankservern, die in einer flexiblen Orchestrierung für VM-Skalierungsgruppen erstellt werden, bietet Azure eine Dienstverfügbarkeit von 99,95% für eine Vereinbarung zum Servicelevel (Service Level Agreement, SLA) für Instanzen, die über Fehlerdomänen verteilt sind. Azure bietet eine Dienstverfügbarkeit von 99,99% für Instanzen, die über Verfügbarkeitszonen verteilt sind. Weitere Informationen finden Sie unter Hochverfügbarkeit für VM-Skalierungsgruppen.

Das Diagramm zeigt eine Hochverfügbarkeitskonfiguration mit Data Guard für Oracle auf dem Zielzonenbeschleuniger für virtuelle Computer.

Eine Schritt-für-Schritt-Konfiguration von Data Guard in Azure finden Sie unter Implementieren von Oracle Data Guard auf einer Linux-basierten Azure-VM.

Verwenden Sie Data Guard im maximalen Schutzmodus für hohe Verfügbarkeit

Wenn Sie eine transaktionskonsistente Kopie Ihrer Datenbank benötigen, sollten Sie die Verwendung von Data Guard im Modus mit maximalem Schutz in Betracht ziehen. Der maximale Schutzmodus lässt jedoch nicht zu, dass Transaktionen fortgesetzt werden, wenn die Standbydatenbank nicht verfügbar ist. Daher wird Ihre SLA trotz der Verwendung der flexiblen Orchestrierung von VM-Skalierungsgruppen auf 99,9% x 99,9% = 99,8% reduziert, wenn Sie den maximalen Schutzmodus verwenden. Diese Konfiguration stellt eine konsistente Kopie der Daten sicher, erhöht jedoch nicht unbedingt die Verfügbarkeit.

Andere Attribute dieser Architektur sind die gleichen wie im Modus für maximale Verfügbarkeit. Beispiel: Der RPO ist null und der RTO ist kleiner oder gleich zwei Minuten.

Erwägen Sie andere Möglichkeiten zum Implementieren von Hochverfügbarkeit

In den folgenden Abschnitten werden besondere Überlegungen zur Hochverfügbarkeit beschrieben.

Verwenden von Verfügbarkeitszonen für eine verbesserte Hochverfügbarkeit

Azure-Verfügbarkeitszonen sind Azure-Rechenzentren, die sich in derselben Azure-Region befinden. Verfügbarkeitszonen haben eine Roundtriplatenz von weniger als zwei Millisekunden. In der Regel werden Verfügbarkeitszonen für die Notfallwiederherstellung verwendet, aber Sie können sie auch verwenden, um die Hochverfügbarkeit zu verbessern. Wenn Sie dies tun, müssen Sie sicherstellen, dass Ihre Lösung mit der Latenz und dem Durchsatz ausgeführt werden kann, die Ihre Verfügbarkeitszonen bieten.

Ein Vorteil von Verfügbarkeitszonen mit einer flexiblen Orchestrierung für VM-Skalierungsgruppen besteht darin, dass Ihre SLA für die VM-Verfügbarkeit auf 99,99%erhöht wird.

Verwenden von Shared Storage-Clustering für Hochverfügbarkeit

Shared Storage-Clustering-Technologien bieten einzigartige Attribute, die Ihnen helfen können, Ihre Geschäftsziele zu erreichen. Sie können z. B. einen Pacemaker- und Corosync-Cluster (PCS) mit freigegebenem Speicher implementieren. Sie können verwaltete Datenträger oder Azure NetApp Files als freigegebenen Speicher für PCS-Clusterinstanzen verwenden. Ein PCS-Cluster dupliziert keine Daten. Er stellt einen virtuellen IP-Dienst mit einer statischen IP-Adresse oder einem IP-Netzwerknamen bereit, der sich bei Failovern nicht ändert.

Hinweis

Ein PCS-Cluster ist keine Oracle-zertifizierte Lösung. Berücksichtigen Sie diesen Faktor, wenn Sie Ihre Hochverfügbarkeitsarchitektur auswählen.

Diagramm, das eine Hochverfügbarkeitskonfiguration mit Pacemaker für Oracle in der Zielzone für virtuelle Computer zeigt.

Verwenden von Näherungsplatzierungsgruppen

Um die geringstmögliche Latenz zu erzielen, platzieren Sie VMs so nah wie möglich. Sie können sie innerhalb einer Näherungsplatzierungsgruppe bereitstellen. Eine Näherungsplatzierungsgruppe ist eine logische Gruppierung, die sicherstellt, dass sich Azure-Computeressourcen physisch nahe beieinander befinden. Näherungsplatzierungsgruppen sind nützlich für Workloads, die eine geringe Latenz erfordern.

Konfigurieren Ihrer Workload für die Notfallwiederherstellung

Eine Notfallwiederherstellungsarchitektur bietet Resilienz gegen Fehler, die sich auf Azure-Rechenzentren oder -Regionen auswirken, oder gegen Fehler, die die Anwendungsfunktionalität in einer gesamten Region beeinträchtigen. In einem solchen Szenario sollten Sie Ihre gesamte Workload in ein anderes Rechenzentrum oder eine andere Region verschieben.

Wählen Sie Ihre Disaster Recovery-Architektur basierend auf Ihren Lösungsanforderungen. Sie ermitteln Ihre Anforderungen auf Basis Ihrer RTO und RPO. Disaster Recovery-Architekturen sind für außergewöhnliche Fehlerfälle gedacht, daher sind Failover-Prozesse manuell. Im Hochverfügbarkeitsdesign erfolgen Failoverprozesse automatisch. In einer Disaster Recovery-Architektur sollten Sie lockerere Anforderungen an RTO und RPO haben, was Geld spart.

Dieser Artikel konzentriert sich auf Szenarien, in denen sich sowohl der primäre Server als auch der sekundäre Server in Azure befinden. Sie können auch über einen lokalen primären Server und einen sekundären Server in Azure für die Notfallwiederherstellung verfügen. Weitere Informationen finden Sie unter Lokaler primärer Standort und Standort für die Notfallwiederherstellung in Azure.

Wählen Sie die richtige Disaster Recovery-Option

Verwenden Sie das folgende Flussdiagramm, um die beste Disaster Recovery-Option für Ihre Oracle-Datenbank auszuwählen.

Diagramm, das die Übersicht über den Datenschutzentwurfsprozess von Oracle auf dem Zielzonenbeschleuniger für virtuelle Maschinen zeigt.

Verwenden von Data Guard für die Notfallwiederherstellung

Sie können Data Guard verwenden, um Daten an Ihren Disaster Recovery-Standort zu replizieren. Verwenden Sie diesen Standort als weitere Verfügbarkeitszone in derselben Region oder in einer anderen Region, je nachdem, welche Anforderungen Sie an den Datenschutz stellen. Ihre Konfiguration hängt auch von der Struktur der Verfügbarkeitszone an Ihrem Produktionsstandort ab. Eine Data Guard-Implementierung in einem Notfallwiederherstellungsszenario ähnelt dem zuvor beschriebenen Hochverfügbarkeitsszenario, weist jedoch einige wichtige Unterschiede auf. Beispiel:

  • Wenn Sie im Hochverfügbarkeitsszenario ein Failover auf ein sekundäres Replikat ausführen, konfigurieren Sie Azure Load Balancer so, dass Anforderungen an die neue primäre Datenbankinstanz umgeleitet werden.

  • Wenn Sie ein Failover auf den Notfallwiederherstellungsstandort ausführen, führen Sie ein Failover der gesamten Lösung auf den neuen Standort durch. Um Latenzprobleme zu vermeiden, müssen Sie in der Regel ein Failover für Anwendungsdienste konfigurieren.

Wenn sich der Standort für die Notfallwiederherstellung in einer anderen Region befindet, müssen Sie den Standort für das Failover entsprechend Ihren Anforderungen entwerfen.

Die Latenz innerhalb eines einzelnen Datencenters ist geringer als die Latenz zwischen Datencentern, die weit voneinander entfernt sind, und viel geringer als die Latenz zwischen verschiedenen Regionen. Daher ist die am wenigsten komplexe und kostengünstigste Option die Verwendung von Data Guard im Modus mit maximaler Leistung für die Notfallwiederherstellung. Wenn der potenzielle Datenverlust im Modus mit maximaler Leistung zu hoch ist, können Sie den Modus mit maximaler Verfügbarkeit mit dem Oracle Data Guard Far Sync-Mechanismus verwenden. Eine Far Sync-Instanz löst jedoch die Active Data Guard-Lizenzierung in der primären Umgebung und der Standby-Umgebung aus. Weitere Informationen finden Sie unter Details zur Oracle-Lizenz.

Wenn Sie Daten über Azure-Regionen oder Rechenzentren senden, zahlen Sie außerdem Ausgangskosten für Daten, z. B. Wiederholungsprotokolle, die an einen Standort für die Notfallwiederherstellung gesendet werden. Wenn Sie nicht alle Daten in Ihrer Datenbank replizieren müssen, können Sie die Oracle Golden Gate-basierte Replikation verwenden, um bei Bedarf nur Teildaten zu replizieren, wodurch die Kosten für ausgehenden Datenverkehr gesenkt werden.

Das Diagramm zeigt eine Notfallwiederherstellungskonfiguration mit Data Guard for Oracle on Virtual Machines Landing Zone Accelerator.

Eine Schritt-für-Schritt-Konfiguration von Data Guard in Azure finden Sie unter Implementieren von Data Guard auf einer Linux-basierten Azure Linux-VM.

Verwenden von Golden Gate für die Notfallwiederherstellung

Golden Gate ist eine logische Replikationssoftware, die Sie für die Echtzeitreplikation, Filterung und Transformation von Daten von einer Quelldatenbank in eine Zieldatenbank oder zwischen mehreren Primärdatenbanken verwenden können. Diese Funktion stellt sicher, dass Änderungen in der Quelldatenbank nahezu in Echtzeit repliziert werden, sodass die Zieldatenbank mit den neuesten Daten auf dem neuesten Stand ist.

Sie können Golden Gate verwenden, um Daten aus einer primären Datenbank in eine sekundäre Datenbank in einer Notfallwiederherstellungskonfiguration zu replizieren. Golden Gate ist besonders praktisch, wenn Sie nur einen Teil Ihrer Daten schützen müssen. Um die Replikation unnötiger Daten zu vermeiden, verwenden Sie Golden Gate, um Tabellen selektiv zu replizieren und Tabellenzeilen während der Replikation herauszufiltern.

Eine Schritt-für-Schritt-Anleitung zum Implementieren von Golden Gate in Azure finden Sie unter Implementieren von Golden Gate auf einer Linux-basierten Azure-VM.

Verwenden von Backups für die Notfallwiederherstellung

Backup und Wiederherstellung ist eine traditionelle Methode für eine Disaster Recovery-Architektur. Es gibt zwei Hauptkomponenten für die Sicherung als Notfallwiederherstellungsmethode für Oracle-Datenbanken in Azure:

  • Extrahieren und verschieben Sie die Sicherung von Daten aus einer Datenbank, um sicherzustellen, dass der Notfallwiederherstellungsstandort über up-to-date-Daten verfügt.

  • Stellen Sie sicher, dass die Bereitstellung am Disaster Recovery-Standort up-toDatum ist. Um den Standort zu aktualisieren, replizieren Sie dieselbe Bereitstellung aller Netzwerkkomponenten, Anwendungsserver und Konfigurationen auf den Notfallwiederherstellungsstandort.

Es gibt mehrere Sicherungsoptionen, die Sie zum Replizieren von Daten verwenden können. Weitere Informationen finden Sie unter Sicherungsstrategien für Oracle Database in Azure.

Erwägen Sie die Verwendung eines der folgenden Ansätze zum Verwalten eines Notfallwiederherstellungsstandorts:

Ansatz 1: Um zusätzlichen Wartungsaufwand und zusätzliche Kosten zu vermeiden, sollten Sie keine physische Bereitstellung am Disaster Recovery-Standort aufrechterhalten. Sie können Infrastructure-as-Code- und Site Reliability Engineering-Methoden verwenden, um ein Repository zu entwickeln und zu verwalten. Dieses Repository kann die Bereitstellung zum Zeitpunkt des Failovers als Konfiguration an einen Disaster Recovery-Standort replizieren. Diese Methode optimiert die Kosten, da bis zum Failover keine physischen Ressourcen verwendet werden.

Von Bedeutung

Wenn Sie während eines Failovers eine gesamte Bereitstellung von Grund auf neu erstellen, müssen Sie sicherstellen, dass Ihre Bereitstellung die RTO-Anforderungen der Lösung erfüllen kann. Um sicherzustellen, dass der Bereitstellungscode nicht beschädigt wird, müssen Sie das Notfallwiederherstellungsszenario routinemäßig simulieren und testen.

Ansatz 2: Bereitstellen und Verwalten einer skalierten Version Ihrer Produktionsumgebung. Sie verfügen über eine Version, die für eine kleine Workload ordnungsgemäß funktioniert und die Sie möglicherweise bei Bedarf während eines Failovers hochskalieren können, um die Produktionslast zu unterstützen. Diese Methode wird häufig verwendet, insbesondere für komplexe Bereitstellungen, bei denen Sie nicht riskieren möchten, eine gesamte Umgebung zu erstellen, oder wenn Sie ein schnelles Failover ausführen möchten, um eine niedrige RTO bereitzustellen.

Ansatz 3: Implementieren und verwalten Sie Ihre gesamte Lösung am Disaster Recovery-Standort, um die schnellsten RTO- und Failover-Zeiten zu erzielen. Diese Methode erhöht die Kosten, da eine vollständig redundante Infrastruktur betrieben wird.

Ziehen Sie andere Möglichkeiten zur Implementierung der Notfallwiederherstellung in Betracht

In den folgenden Abschnitten werden besondere Überlegungen zur Notfallwiederherstellung beschrieben.

Verwenden von Far Sync

Far Sync verbessert die Hochverfügbarkeitsfunktionen nicht, aber Sie können es verwenden, um Funktionen zum Schutz vor Datenverlusten für Oracle-Datenbanken ohne Datenverlust zu erreichen. Ihre Workload erfordert möglicherweise keinen Datenverlust, wenn Ihre primäre Datenbank ausfällt. Weitere Informationen finden Sie unter Oracle-Referenzarchitekturen in Azure.

Wählen Sie die richtige Datenreplikationstechnologie

Zusätzlich zu den Technologien in diesem Artikel können Sie jede Technologie verwenden, die die Datenreplikation zwischen zwei Oracle-Datenbanken erleichtert, um ein Hochverfügbarkeitsreplikat und ein Notfallwiederherstellungsreplikat für Ihre Oracle-Datenbanken in Azure zu verwalten. Die Technologie, die Sie auswählen, muss Ihre Lösungsanforderungen in diesen Kategorien erfüllen.

Latenz: Die Zeit, die zum Replizieren eines Updates von einer primären Datenbank in sekundäre Datenbanken für Hochverfügbarkeit und Notfallwiederherstellung benötigt wird, sollte den Anforderungen Ihrer Lösung entsprechen.

Bandbreite: Die Menge und die Kosten der Bandbreite, die Sie benötigen, um Daten in sekundäre Datenbanken zu replizieren, um Hochverfügbarkeit und Notfallwiederherstellung zu gewährleisten. Azure bietet eine Hochgeschwindigkeitsnetzwerkinfrastruktur zwischen Verfügbarkeitszonen. Wenn Sie die Replikation in andere Azure-Regionen für die Notfallwiederherstellung in Betracht ziehen, sollten Sie die Bandbreite und die Kosten für ausgehende Daten berücksichtigen, die das Azure-Rechenzentrum verlassen.

Aufprall: Die Auswirkungen, die die Replikation auf die Transaktionsverarbeitung in der primären Datenbank hat, sollten den Anforderungen Ihrer Lösung entsprechen.

Datenverlust: Das Ausmaß des Datenverlusts, das Sie bei einem abrupten Ausfall der primären Datenbank erwarten, sollte den Anforderungen Ihrer Lösung entsprechen.

Gesamtbetriebskosten: Berücksichtigen Sie die Anschaffungskosten für eine Replikationslösung, die nicht von Microsoft stammt, und den Aufwand, den Sie für die Konfiguration und Wartung der Replikationslösung benötigen. Stellen Sie sicher, dass diese Faktoren den Anforderungen Ihrer Lösung entsprechen.

Optimieren einer Failover-Instanz

Wenn Sie Data Guard im Modus für hohe Verfügbarkeit oder im Modus für hohen Schutz verwenden, können Sie das automatische Failover konfigurieren, sodass der sekundäre Server automatisch hochgefahren wird, wenn der primäre Server ausfällt. Wenn Sie Anwendungsserver richtig konfigurieren, können Sie sicherstellen, dass es während eines Failovers fast keine Anwendungsausfallzeiten gibt.

In dieser Implementierung muss eine Datenbank nach einem Failover genauso ausgeführt werden. Daher müssen Sie einen sekundären Server mit der gleichen CPU-, Arbeitsspeicher- und E/A-Kapazität (Input/Output) wie der primäre Server konfigurieren. Sie müssen eine hohe Kapazität mit einem sekundären Server aufrechterhalten, was Ihre Azure-Kosten und die Lizenzkosten für Oracle Database erhöht. Der sekundäre Server verarbeitet in der Regel keine Benutzeranforderungen.

Azure bietet eine Verfügbarkeit von 99,9% für VMs in einer Verfügbarkeitszone. Weitere Informationen finden Sie unter SLA für die VM-Betriebszeit. Wenn Sie eine Datenreplikationstechnologie verwenden, um ein sekundäres Replikat Ihrer Datenbank in derselben Verfügbarkeitszone, einer anderen Verfügbarkeitszone oder einer anderen Region zu verwalten, können Sie die sekundäre Kapazität optimieren.

Bei diesem Ansatz wird die sekundäre Datenbank mit der Kapazität konfiguriert, die sie benötigt, um auf dem neuesten Stand zu bleiben. Wenn ein Fehler auftritt, wird die Größe der sekundären Datenbank auf die gleiche Kapazität wie die primäre Datenbank geändert. Dieser Vorgang wird nur ausgeführt, wenn ein Fehler auftritt. Im normalen Betrieb zahlen Sie also nur einen Bruchteil der Kosten des primären Servers. Die primäre Datenbank ist während des Ausfalls nicht betriebsbereit, sodass Sie keine weiteren Oracle-Datenbanklizenzen benötigen.

Die Kapazität, die Sie benötigen, um eine sekundäre Datenbank als Replikationsziel zu betreiben, hängt von der verwendeten Replikationstechnologie ab. Im Wesentlichen besteht eine Workload, die sich auf einem OLTP-System (Transactional Online Transaction Processing) befindet, hauptsächlich aus Leseanforderungen. In OLTP-Anwendungen sind z. B. 90% Lese- und 10% Schreibvorgänge oder 95% Lese- und 5% Schreibvorgänge üblich. Bei der Datenreplikation wird im Wesentlichen das Ergebnis des Schreibens von Anforderungen in die Quelldatenbank repliziert. Bei dieser Konfiguration können Sie davon ausgehen, dass die sekundäre Datenbank mit 1/10 (bei einem Lese- und Schreibverhältnis von 90% und 10% Schreibvorgängen) der Kapazität der primären Datenbank arbeitet.

Automatisieren Sie Failover-Verfahren, um sicherzustellen, dass Sie während des Failover-Prozesses die Unternehmensstandards erfüllen. Sie können die Failoververfahren so konfigurieren, dass sie Vorgänge zur Größenänderung des Servers umfassen, die den End-to-End-Prozess optimieren.

Konfigurieren der Netzwerktopologie für Dienst- und Datenschutz

Um Hochverfügbarkeit und Notfallwiederherstellung zu erreichen, müssen Sie finanzielle und geschäftliche Entscheidungen treffen, die die Wiederherstellungszeit (RTO) und den potenziellen Datenverlust (RPO) mit anderen Kosten für Oracle-Lizenzierung, VM-Wartung und Datenübertragung in Einklang bringen. Wenn Sie eine Workload auf einer einzelnen Azure-VM hosten, erhalten Sie zu geringen Kosten grundlegenden Schutz vor häufigen Hardwarefehlern. Ein Ausfall auf einer einzelnen VM führt jedoch wahrscheinlich zu Ausfallzeiten und Datenverlust. Fügen Sie daher in Ihren Produktionsumgebungen mindestens eine sekundäre Oracle-Datenbank ein, die mit Data Guard auf einer separaten VM gehostet wird. Verwenden Sie je nach Ihren Anforderungen eine oder mehrere der folgenden Data Guard-Konfigurationen für die Datenreplikation:

  • Optimales RTO und RPO. Um die Latenz zu minimieren, integrieren Sie eine sekundäre Oracle-Datenbank auf einer separaten VM innerhalb derselben flexiblen Orchestrierung für VM-Skalierungsgruppen und in derselben Verfügbarkeitszone wie die primäre Datenbank. Diese Konfiguration bietet Hochverfügbarkeit und Schutz vor einem Ausfall einer einzelnen Instanz.

  • Schutz der Daten vor einem Ausfall eines Rechenzentrums. Platzieren Sie die sekundäre Oracle-Datenbank in einer zweiten Verfügbarkeitszone, um eine Hochverfügbarkeitseinrichtung bereitzustellen und Schutz zu bieten, wenn eine gesamte Verfügbarkeitszone ausfällt. Diese Konfiguration kann eine Latenz von bis zu zwei Millisekunden zwischen der primären und der sekundären Datenbank aufweisen, was sich auf die Leistung, RTOs und RPOs auswirken kann.

  • Datenschutz vor einem regionalen Ausfall. Zum Schutz vor potenziellem Datenverlust aufgrund eines Ausfalls in der Azure-Region können Sie die sekundäre Datenbank in einer anderen Region platzieren. Diese Konfiguration kann eine Latenz zwischen 30 Millisekunden und 300 Millisekunden zwischen Regionen aufweisen, sodass Sie Ihre RTO- und RPO-Ziele möglicherweise nicht erreichen. Diese Lösung eignet sich am besten für die regionale Notfallwiederherstellung anstelle von Hochverfügbarkeit.

Business Continuity erfordert einen integrierten Ansatz, der alle Komponenten einer Workload umfasst. Die Netzwerkinfrastruktur ist eine primäre Komponente für alle Workloads in Azure. Ihre Netzwerkinfrastruktur muss auf Ihre Hochverfügbarkeits- oder Disaster-Recovery-Architektur abgestimmt sein. Berücksichtigen Sie die folgenden Faktoren für die Netzwerkinfrastruktur:

  • Data Guard bietet Hochverfügbarkeit und in den meisten Szenarien ausreichende Unterstützung für häufige Fehler. Sie können VMs in einer flexiblen Orchestrierung für VM-Skalierungsgruppen platzieren. Um die Netzwerklatenz zu reduzieren, sollten sich alle Dienste in einer einzelnen Lösung in derselben Verfügbarkeitszone befinden, und die Dienste sollten dasselbe virtuelle Netzwerk gemeinsam nutzen.

    Für weiteren Schutz können Sie VMs strategisch in separaten Verfügbarkeitszonen statt in einer einzelnen Verfügbarkeitszone platzieren. Auf diese Weise können Ausfallzeiten während eines Rechenzentrumsausfalls verhindert werden.

  • Für maximalen Schutz können Sie eine sekundäre Datenbank in einer anderen Azure-Region als der primären Datenbankregion platzieren. Zum Anwenden fortlaufender Updates können Sie Data Guard verwenden, um globales Peering virtueller Netzwerke zu implementieren. Verwenden Sie diesen Ansatz, um Datenupdates privat über den Microsoft-Backbone auf die sekundäre Region anzuwenden. Ressourcen kommunizieren direkt ohne Gateways, zusätzliche Hops oder Transit über das öffentliche Internet.

    Diese Netzwerkoption bietet eine Verbindung mit hoher Bandbreite und geringer Latenz über virtuelle Peering-Netzwerke in verschiedenen Regionen. Sie können das Peering globaler virtueller Netzwerke verwenden, um Ihren primären Standort über ein Hochgeschwindigkeitsnetzwerk mit einem Notfallwiederherstellungsstandort in einer anderen Region zu verbinden.

Zusammenfassung der Resilienz gegen verschiedene Fehlertypen

Fehlerszenario Oracle in Azure-Hochverfügbarkeits- oder Notfallwiederherstellungsszenario RPO/RTO
Ausfall einer einzelnen Komponente, z. B. Server-, Rack-, Kühl-, Netzwerk- oder Stromausfall Data Guard mit zwei Knoten im selben VM-Scale-Set Flexible Orchestrierung im selben Rechenzentrum:

- Schützt vor dem Ausfall einer einzelnen Instanz.
- Verursacht Ausfallzeiten, wenn ein gesamtes Rechenzentrum ausfällt.
Wenn Sie Observer für das Schnellstartfailover und den MAX_AVAILABILITY- oder MAX_PROTECTION-Modus für Data Guard verwenden:
- RPO ist Null.
- Die RTO ist kleiner oder gleich 2 Minuten.
Ausfall des Rechenzentrums Data Guard mit zwei Knoten in separaten Verfügbarkeitszonen:

- Schützt vor einem Ausfall eines Rechenzentrums.
- Verursacht Ausfallzeiten, wenn eine ganze Region ausfällt.
- Erfordert eine stärkere Failover-Konfiguration für App-Server, um die Netzwerklatenz zu verwalten.
- Der RPO beträgt höchstens 5 Minuten.
- Die RTO beträgt höchstens 5 Minuten.

Wenn Sie den MAX_PERFORMANCE-Modus und den MAX_AVAILABILITY-Modus für Data Guard verwenden:
- RPO ist Null.
- Die RTO beträgt höchstens 5 Minuten.
Regionaler Ausfall Data Guard mit zwei Knoten in separaten Azure-Regionen:

- Schützt vor regionalen Ausfällen.
- Erfordert eine stärkere Failover-Konfiguration für App-Server, um die Netzwerklatenz zu verwalten.
Wenn Sie MAX_PERFORMANCE Modus für Data Guard verwenden:
- Der RPO ist größer oder gleich 10 Minuten.
- Die RTO ist größer oder gleich 15 Minuten.
Alle Szenarien: Ausfall einer einzelnen Komponente, eines Rechenzentrums und einer Region Sicherungen, die an eine andere Azure-Region gesendet werden:

- Schützen Sie sich vor regionalen Ausfällen.
- Während eines Failovers muss eine gesamte Azure-Umgebung in der Zielregion eingerichtet werden.
- RPO ist größer oder gleich 24 h.
- Die RTO ist größer oder gleich 4 h.

Nächster Schritt

Erfahren Sie mehr über Entwurfsüberlegungen für die Sicherheit von Oracle on Virtual Machines Landing Zone Accelerator in einem Szenario auf Unternehmensebene.

Sicherheitsrichtlinien für Oracle on Virtual Machines Landing Zone Accelerator