Geschäftskontinuität und Notfallwiederherstellung (Business Continuity Disaster Recovery, BCDR) für Oracle auf dem Azure-VIM-Zielzonenbeschleuniger

Artikel
08/08/2024

Dieser Artikel baut auf Überlegungen und Empfehlungen auf, die unter Entwurfsbereich für Azure-Zielzonen für Geschäftskontinuität und Notfallwiederherstellung (BCDR) definiert sind. Dieser Artikel folgt dieser Anleitung und beschreibt Entwurfsüberlegungen und bewährte Methoden zu BCDR-Optionen für Oracle-Workload-Bereitstellungen auf virtuellen Azure-Infrastrukturcomputern (VMs).

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

Erste Schritte

Um eine stabile Architektur für Ihre Workload-Umgebung aufzubauen, müssen Sie die Verfügbarkeitsanforderungen für Ihre Lösung auf der Grundlage der Wiederherstellungszeit (RTO) und des Wiederherstellungspunkts (RPO) für verschiedene Ausfallszenarien bestimmen. RTO ist die maximale Zeit, in der eine Anwendung nach einem Vorfall nicht verfügbar ist. RPO ist die maximale Menge an Datenverlust während eines Notfalls. Nachdem Sie die Anforderungen an Ihre Lösung festgelegt haben, müssen Sie Ihre Architektur so gestalten, dass sie den festgelegten Grad an Ausfallsicherheit und Verfügbarkeit bietet.

Oracle auf Azure-Workloads verwenden in erster Linie Oracle Data Guard, ein integriertes Oracle Database Enterprise Edition-Feature, das Replikationstechnologie verwendet. Sie können Data Guard verwenden, um hohe Verfügbarkeits- und Notfallwiederherstellungsanforderungen 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 aus.

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 bietet nahezu echtzeitbasierte Datenreplikation mit potenziell schnellen Failover-Funktionen. Eine Konfiguration für hohe Verfügbarkeit bietet keinen Schutz für Fehler auf Azure-Rechenzentrumsebene oder auf Regionsebene.

Wählen Sie die richtige Hochverfügbarkeitsoption

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

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

Data Guard im Maximalverfügbarkeitsmodus bietet die höchste Verfügbarkeit mit einem Null-Datenverlust-Versprechen (RPO=0) für den Normalbetrieb. Für eine maximal verfügbare Konfiguration von zwei Oracle-Datenbankservern, die in einer flexiblen Orchestrierung für virtuelle Computer-Skalierungssätze erstellt werden, bietet Azure 99,95 % Dienstverfügbarkeit für eine Vereinbarung zum Servicelevel (SLA – Service Level Agreement) für Instanzen, die über Fehlerdomänen verteilt sind. Azure bietet 99,99 % Dienstverfügbarkeit für Instanzen, die über Verfügbarkeitszonen verteilt sind. Weitere Informationen finden Sie unter Hohe Verfügbarkeit für Virtual Machine Scale Sets.

Eine schrittweise Konfiguration von Data Guard auf 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 den Einsatz von Data Guard im maximalen Schutzmodus in Betracht ziehen. Der Maximalschutzmodus erlaubt jedoch nicht die Fortsetzung von Transaktionen, wenn die Standby-Datenbank 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 von Daten sicher, erhöht aber nicht unbedingt die Verfügbarkeit.

Andere Attribute dieser Architektur sind die gleichen wie beim Modus der maximalen Verfügbarkeit. Beispielsweise ist das RPO null, und die RTO ist kleiner oder gleich zwei Minuten.

Erwägen Sie weitere Möglichkeiten, um hohe Verfügbarkeit zu implementieren

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

Verwendung von Verfügbarkeitszonen für verbesserte Hochverfügbarkeit

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

Ein Vorteil von Verfügbarkeitszonen mit einer Virtual Machine Scale Sets flexiblen Orchestrierung besteht darin, dass Ihre VM-Verfügbarkeits-SLA auf 99,99 % erhöht wird.

Verwenden Sie gemeinsames Speicher-Clustering für Hochverfügbarkeit

Clustering-Technologien für gemeinsam genutzten Speicher bieten einzigartige Eigenschaften, die Ihnen helfen können, Ihre Geschäftsziele zu erreichen. Sie können beispielsweise einen Pacemaker- und Corosync-Cluster (PCS) mit gemeinsam genutztem Speicher implementieren. Sie können verwaltete Datenträger oder Azure NetApp Files als gemeinsamen Speicher für PCS Cluster-Instanzen 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. Beachten Sie diesen Faktor, wenn Sie Ihre Hochverfügbarkeitsarchitektur auswählen.

Verwenden von Näherungsplatzierungsgruppen

Um die niedrigste mögliche Latenz bereitzustellen, platzieren Sie virtuelle Computer so nah wie möglich. Sie können sie in einer Näherungsplatzierungsgruppe bereitstellen. Eine Näherungsplatzierungsgruppe ist eine logische Gruppierung, die eine geringe physische Entfernung zwischen Azure-Computeressourcen sicherstellt. Näherungsplatzierungsgruppen sind für Workloads hilfreich, die eine geringe Latenz erfordern.

Konfigurieren Ihrer Workload für die Notfallwiederherstellung

Eine Notfallwiederherstellungs-Architektur bietet Widerstandsfähigkeit gegen Ausfälle, die Azure-Rechenzentren oder -Regionen betreffen, oder gegen Ausfälle, 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 Notfallwiederherstellungs-Architektur basierend auf Ihren Lösungsanforderungen aus. Sie bestimmen Ihre Anforderungen basierend auf Ihrem RTO und RPO. Notfallwiederherstellungs-Architekturen sind für außergewöhnliche Fehlerfälle vorgesehen, sodass Failover-Prozesse manuell ausgeführt werden. Im Design für hohe Verfügbarkeit werden Failover-Prozesse automatisch ausgeführt. In einer Notfallwiederherstellungs-Architektur sollten Sie die Anforderungen für RTO und RPO entspannter erfüllen, 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 einen primären Server vor Ort und einen sekundären Server auf Azure für die Notfallwiederherstellung haben. Weitere Informationen finden Sie auf der primären Website lokal und auf der Notfallwiederherstellungs-Website in Azure.

Auswählen der richtigen Option für die Notfallwiederherstellung

Verwenden Sie das folgende Flussdiagramm, um auszuwählen, welche Notfallwiederherstellung für Ihre Oracle-Datenbank am besten geeignet ist.

Verwenden Sie Data Guard für die Notfallwiederherstellung

Sie können Data Guard zur Datenreproduktion an Ihrem Notfallwiederherstellungsstandort verwenden. Verwenden Sie diesen Standort als weitere Verfügbarkeitszone in derselben Region oder in einer anderen Region, je nach Ihren Anforderungen an den Datenschutz. Ihre Konfiguration hängt auch von der Verfügbarkeitszonenstruktur ihres Produktionsstandorts ab. Eine Data Guard-Implementierung in einem Notfallwiederherstellungsszenario ähnelt dem zuvor besprochenen Hochverfügbarkeitsszenario, wobei es einige wichtige Unterschiede gibt. Zum Beispiel:

Wenn Sie im Hochverfügbarkeitsszenario auf ein sekundäres Replikat umschalten, konfigurieren Sie Azure Load Balancer so, dass Anfragen an die neue primäre Datenbankinstanz umgeleitet werden.
Beim Failover zum Notfallwiederherstellungsstandort wird die gesamte Lösung auf den neuen Standort übertragen. Um Latenzprobleme zu vermeiden, müssen Sie in der Regel Failover für Anwendungsdienste konfigurieren.

Wenn sich der Standort für die Notfallwiederherstellung in einer anderen Region befindet, müssen Sie den Standort je nach Ihren Anforderungen für die Ausfallsicherung einrichten.

Die Latenz innerhalb eines einzelnen Rechenzentrums ist geringer als die Latenz zwischen Rechenzentren, die weit voneinander entfernt sind, und viel geringer als die Latenz zwischen verschiedenen Regionen. Daher ist die am wenigsten komplexe und kostengünstigste Option, Data Guard im Höchstleistungsmodus für die Notfallwiederherstellung zu verwenden. Wenn der potenzielle Datenverlust im Modus der maximalen Leistung zu hoch ist, können Sie den maximalen Verfügbarkeitsmodus 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 und der Standby-Umgebung aus. Weitere Informationen finden Sie unter Oracle-Lizenzdetails.

Wenn Sie Daten über Azure-Regionen oder -Rechenzentren hinweg senden, zahlen Sie außerdem Ausgangskosten für Daten, wie z. B. Wiederholungsprotokolle, die an einen Notfallwiederherstellungsstandort gesendet werden. Wenn Sie nicht alle Daten in Ihrer Datenbank replizieren müssen, können Sie die Oracle Golden Gate-basierte Replikation verwenden, um nur einen Teil der Daten zu replizieren, was die Ausgangskosten reduziert.

Eine schrittweise Konfiguration von Data Guard auf Azure finden Sie unter Implementierung von Data Guard auf einer Linux-basierten Azure Linux VM.

Verwenden Sie Golden Gate für die Notfallwiederherstellung

Golden Gate ist eine logische Replikationssoftware, die Sie nutzen können, um die Echtzeitreplikation, Filterung und Transformation von Daten aus einer Quelldatenbank in eine Zieldatenbank oder zwischen mehreren primären Datenbanken zu ermöglichen. Mit dieser Funktion wird sichergestellt, dass Änderungen in der Quelldatenbank nahezu in Echtzeit repliziert werden, so dass die Zieldatenbank immer auf dem neuesten Stand der Daten ist.

Sie können Golden Gate verwenden, um Daten von einer primären Datenbank auf eine sekundäre Datenbank in einer Notfallwiederherstellungskonfiguration zu replizieren. Golden Gate ist besonders praktisch, wenn Sie nur einige Ihrer Daten schützen müssen. Um die Replikation unnötiger Daten zu vermeiden, verwenden Sie Golden Gate zur selektiven Replikation von Tabellen und zum Herausfiltern von Tabellenzeilen während der Replikation.

Eine schrittweise Anleitung zur Implementierung von Golden Gate in Azure finden Sie unter Implementieren von Golden Gate auf einer Linux-basierten Azure-VM.

Verwenden der Sicherung für die Notfallwiederherstellung

Die Sicherung und Wiederherstellung ist eine traditionelle Methode für eine Notfallwiederherstellungs-Architektur. Es gibt zwei Hauptkomponenten für Backups als Notfallwiederherstellung für Oracle-Datenbanken in Azure:

Extrahieren und verschieben Sie die Sicherung von Daten aus einer Datenbank, um sicherzustellen, dass der Notfallwiederherstellungsstandort über aktuelle Daten verfügt.
Sorgen Sie dafür, dass die Daten am Standort der Notfallwiederherstellung auf dem neuesten Stand sind. Um den Standort zu aktualisieren, replizieren Sie die gleiche Bereitstellung aller Netzwerkkomponenten, Anwendungsserver und Konfigurationen auf den Notfallwiederherstellungsstandort.

Es gibt mehrere Sicherungsoptionen, mit denen Sie Daten replizieren können. Weitere Informationen finden Sie unter Sicherungsstrategien für Oracle-Datenbanken auf Azure.

Ziehen Sie einen der folgenden Ansätze für die Wartung einer Notfallwiederherstellung in Betracht:

Ansatz 1: Um den zusätzlichen Wartungsaufwand und die zusätzlichen Kosten zu vermeiden, sollten Sie keine physische Bereitstellung am Notfallwiederherstellungsstandort aufrechterhalten. Sie können die Infrastruktur als Code- und Sitezuverlässigkeits-Entwicklungs-Methoden für den Standort verwenden, um ein Repository zu entwickeln und zu verwalten. Dieses Repository kann die Bereitstellung als Konfiguration zu einem Notfallwiederherstellungsstandort zum Zeitpunkt des Failovers replizieren. Diese Methode optimiert die Kosten, da sie bis zum Failover keine physischen Ressourcen beansprucht.

Wichtig

Wenn Sie bei einem Failover eine komplette 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 unterbrochen wird, müssen Sie das Notfallwiederherstellungsszenario routinemäßig simulieren und testen.

Ansatz 2: Bereitstellung und Wartung einer skalierten Version Ihrer Produktionsumgebung. Verfügen Sie über eine Version, die für eine kleine Workload geeignet ist und die Sie bei Bedarf während eines Failover skalieren können, um die Produktionslast zu bedienen. Diese Methode wird häufig verwendet, insbesondere bei komplexen Bereitstellungen, bei denen Sie nicht das Risiko eingehen möchten, eine gesamte Umgebung zu erstellen, oder wenn Sie ein schnelles Failover durchführen möchten, um eine niedrige RTO bereitzustellen.

Ansatz 3: Bereitstellen und Verwalten Ihrer gesamten Lösung am Notfallwiederherstellungsstandort für die schnellsten RTO- und Failover-Zeiten. Diese Methode erhöht die Kosten, da eine vollständig redundante Infrastruktur ausgeführt wird.

Berücksichtigen Sie andere Möglichkeiten zum Implementieren der Notfallwiederherstellung

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

Far Sync verwenden

Far Sync verbessert nicht die Funktionen für hohe Verfügbarkeit, aber Sie können sie verwenden, um null Datenschutzfunktionen für Oracle-Datenbanken zu erreichen. Ihre Workload benötigt möglicherweise keinen Datenverlust, wenn ihre primäre Datenbank fehlschlägt. Weitere Informationen finden Sie unter Oracle Referenzarchitekturen auf Azure.

Wählen der richtigen Datenreplikationstechnologie

Zusätzlich zu den in diesem Artikel beschriebenen Technologien können Sie jede Technologie verwenden, die eine Datenreplikation zwischen zwei Oracle-Datenbanken ermöglicht, um eine Hochverfügbarkeitsreplik und eine Notfallwiederherstellungsreplik für Ihre Oracle-Datenbanken auf Azure zu erhalten. Die Technologie, für die Sie sich entscheiden, muss Ihre Lösungsanforderungen in allen diesen Kategorien erfüllen.

Latenz: Die Zeit, die für die Replikation einer Aktualisierung von einer primären Datenbank auf sekundäre Datenbanken für hohe Verfügbarkeit und Notfallwiederherstellung benötigt wird, sollte den Anforderungen Ihrer Lösung entsprechen.

Bandbreite: Der Umfang und die Kosten der Bandbreite, die Sie für die Replikation von Daten auf sekundäre Datenbanken für hohe Verfügbarkeit und Notfallwiederherstellung benötigen. Azure bietet eine Hochgeschwindigkeits-Netzwerkinfrastruktur zwischen Verfügbarkeitszonen. Wenn Sie eine Replikation in andere Azure-Regionen zur Notfallwiederherstellung in Betracht ziehen, sollten Sie die erreichbare Bandbreite und die Ausgangskosten für Daten, die das Azure-Rechenzentrum verlassen, berücksichtigen.

Auswirkung: Der Grad der Auswirkung, den die Replikation auf die Transaktionsverarbeitung in der primären Datenbank hat, sollte den Anforderungen Ihrer Lösung entsprechen.

Datenverlust: Die Höhe des zu erwartenden Datenverlustes bei einem plötzlichen Ausfall der primären Datenbank sollte den Anforderungen Ihrer Lösung entsprechen.

Gesamtbetriebskosten: Berücksichtigen Sie die Anschaffungskosten für eine Nicht-Microsoft-Replikationslösung und den Aufwand, den Sie zum Konfigurieren und Verwalten 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 Hochverfügbarkeits- oder Hochsicherheitsmodus verwenden, können Sie auch ein automatisches Failover konfigurieren, so dass bei einem Ausfall des Primärservers der Sekundärserver automatisch hochgefahren wird. Wenn Sie Anwendungsserver ordnungsgemäß konfigurieren, können Sie sicherstellen, dass während eines Failovers nahezu keine Anwendungsausfallzeiten auftreten.

In dieser Implementierung muss eine Datenbank nach einem Failover gleich ausgeführt werden. Daher müssen Sie einen sekundären Server mit derselben CPU-, Arbeitsspeicher- und Eingabe-/Ausgabekapazität (E/A) als primärer Server konfigurieren. Sie müssen eine hohe Kapazität mit einem zweiten Server aufrechterhalten, was Ihre Azure-Kosten und die Kosten für Oracle-Datenbanklizenzen erhöht. Der sekundäre Server verarbeitet in der Regel keine Benutzeranforderungen.

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

Bei diesem Ansatz ist die sekundäre Datenbank mit der Kapazität konfiguriert, die sie benötigt, um auf dem neuesten Stand zu bleiben. Im Falle eines Ausfalls wird die Größe der sekundären Datenbank angepasst, dass sie die gleiche Kapazität wie die primäre Datenbank erreicht. Dieser Vorgang tritt nur auf, wenn ein Fehler auftritt. Während des normalen Betriebs zahlen Sie also nur einen Bruchteil der Kosten des primären Servers. Die primäre Datenbank ist während des Fehlers nicht funktionsfähig, daher benötigen Sie keine anderen Oracle-Datenbanklizenzen.

Die Kapazität, die Sie für den Betrieb einer sekundären Datenbank als Replikationsziel benötigen, hängt von der von Ihnen verwendeten Replikationstechnologie ab. Im Wesentlichen hat ein Workload, der sich auf einem OLTP-System (Transactional Online Transaction Processing) befindet, hauptsächlich 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 von Schreibanforderungen in der Quelldatenbank repliziert. Bei diesem Setup können Sie davon ausgehen, dass die sekundäre Datenbank mit dem 1/10. (wenn Sie über ein 90 % Lese- und 10% Schreibverhältnis verfügen) der Kapazität der primären Datenbank ausgeführt wird.

Automatisieren Sie Failover-Verfahren, um sicherzustellen, dass Sie während des Failover-Prozesses die Unternehmensstandards einhalten. Sie können die Failover-Prozeduren so konfigurieren, dass sie Operationen zur Größenanpassung des Servers beinhalten, die den End-to-End-Prozess rationalisieren.

Konfigurieren Sie Ihre Netzwerktopologie für den Schutz von Diensten und Daten

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) gegen andere Kosten für Oracle-Lizenzen, VM-Wartung und Datenübertragung abwägen. Wenn Sie eine Workload auf einer einzelnen Azure-VM hosten, erhalten Sie grundlegenden Schutz für häufige Hardwarefehler zu niedrigen Kosten. Aber ein Fehler auf einem einzelnen virtuellen Computer verursacht wahrscheinlich Ausfallzeiten und Datenverlust. Schließen Sie also in Ihren Produktionsumgebungen mindestens eine sekundäre Oracle-Datenbank ein, die auf einer separaten VM mit Data Guard gehostet wird. Verwenden Sie je nach Ihren Anforderungen eine oder mehrere der folgenden Data Guard-Konfigurationen für die Datenreplikation:

Optimale RTO und RPO. Um die Latenz zu minimieren, sollten Sie eine sekundäre Oracle-Datenbank auf einer separaten VM innerhalb derselben Virtual Machine Scale Sets flexible Orchestrierung und in derselben Verfügbarkeitszone wie die primäre Datenbank integrieren. Diese Konfiguration bietet hohe Verfügbarkeit und Schutz vor einem Ausfall einer einzelnen Instanz.
Datenschutz vor einem Rechenzentrumsfehler. Platzieren Sie die sekundäre Oracle-Datenbank in einer zweiten Verfügbarkeitszone, um ein Hochverfügbarkeits-Setup bereitzustellen und Schutz bereitzustellen, wenn eine gesamte Verfügbarkeitszone fehlschlägt. Diese Konfiguration kann bis zu zwei Millisekunden Latenz zwischen der primären und sekundären Datenbank aufweisen, was sich auf die Leistung, RTOs und RPOs auswirken kann.
Datenschutz vor einem regionalen Fehler. Um den Schutz vor potenziellem Datenverlust aufgrund eines regionalen Azure-Ausfalls zu unterstützen, können Sie die sekundäre Datenbank in einer anderen Region platzieren. Diese Konfiguration kann zwischen 30 Millisekunden und 300 Millisekunden Latenz zwischen Regionen aufweisen, sodass Sie Ihre RTO- und RPO-Ziele möglicherweise nicht erfüllen. Diese Lösung eignet sich am besten für die regionale Notfallwiederherstellung und nicht für hohe Verfügbarkeit.

Die Geschäftskontinuität erfordert einen integrierten Ansatz, der alle Komponenten eines Workloads einbezieht. Die Netzwerkinfrastruktur ist eine primäre Komponente für jede Workload in Azure. Ihre Netzwerkinfrastruktur muss sich an Ihre Hochverfügbarkeits- oder Notfallwiederherstellungs-Architektur anpassen. Berücksichtigen Sie die folgenden Netzwerkinfrastrukturfaktoren:

Data Guard bietet Hochverfügbarkeit und in den meisten Szenarien eine ausreichende Unterstützung für häufige Ausfälle. Sie können VMs in einer flexiblen Orchestrierung für Virtual Machine Scale Sets platzieren. Um die Netzwerklatenz zu verringern, sollten sich alle Dienste in einer einzigen Lösung in derselben Verfügbarkeitszone befinden, und die Dienste sollten dasselbe virtuelle Netzwerk nutzen.

Für weiteren Schutz können Sie virtuelle Maschinen strategisch in separaten Verfügbarkeitszonen statt in einer einzigen Verfügbarkeitszone platzieren. Dieser Ansatz kann bei einem Ausfall des Rechenzentrums Ausfallzeiten verhindern.
Für maximalen Schutz können Sie eine sekundäre Datenbank in einer anderen Azure-Region als der primären Datenbankregion platzieren. Um fortlaufende Updates anzuwenden, können Sie Data Guard verwenden, um globales Peering virtueller Netzwerke zu implementieren. Mit diesem Ansatz können Sie Datenaktualisierungen in der sekundären Region privat über das Microsoft-Backbone vornehmen. Ressourcen kommunizieren direkt, ohne Gateways, zusätzliche Sprünge oder Transit über das öffentliche Internet.

Diese Netzwerkoption bietet eine Verbindung mit hoher Bandbreite und niedriger Latenz über geteilte virtuelle Netzwerke in verschiedenen Regionen. Sie können globales Peering virtueller Netzwerke verwenden, um Ihren primären Standort über ein Hochgeschwindigkeitsnetzwerk mit einem Standort für die Notfallwiederherstellung in einer anderen Region zu verbinden.

Zusammenfassung der Widerstandsfähigkeit gegenüber verschiedenen Ausfallarten

Fehlerszenario	Oracle in Azure-Szenario mit hoher Verfügbarkeit oder Notfallwiederherstellung	RPO / RTO
Ausfall einzelner Komponenten, wie ein Host-, Rack-, Kühlungs-, Netzwerk- oder Stromfehler	Data Guard mit zwei Knoten in den selben Virtual Machine Scale Sets legt flexible Orchestrierung im selben Rechenzentrum fest: - Schützt vor dem Ausfall einer einzelnen Instanz. - Verursacht Ausfallzeiten, wenn ein gesamtes Rechenzentrum fehlschlägt.	Wenn Sie Observer für den Schnellstartfailover und MAX_AVAILABILITY- oder MAX_PROTECTION-Modus für Data Guard verwenden: - RPO ist 0 (null). -RTO ist kleiner als oder gleich 2 min.
Rechenzentrumsfehler	Data Guard mit zwei Knoten in getrennten Verfügbarkeitszonen: - Schützt beim Ausfall eines Rechenzentrums. - Verursacht Ausfallzeiten, wenn eine ganze Region fehlschlägt. - Erfordert eine größere Failoverkonfiguration für App-Server zum Verwalten der Netzwerklatenz.	-RPO ist kleiner als oder gleich 5 min. -RTO ist kleiner als oder gleich 5 min. Wenn Sie MAX_PERFORMANCE-Modus und MAX_AVAILABILITY-Modus für Data Guard verwenden: - RPO ist 0 (null). -RTO ist kleiner als oder gleich 5 min.
Regionaler Ausfall	Data Guard mit zwei Knoten in separaten Azure-Regionen: - Schützt vor regionalen Fehlern. - Erfordert eine größere Failoverkonfiguration für App-Server zum Verwalten der Netzwerklatenz.	Wenn Sie MAX_PERFORMANCE-Modus für Data Guard verwenden: - RPO ist größer oder gleich als 10 min. - RTO ist größer oder gleich als 15 min.
Alle Szenarien: eine einzelne Komponente, ein Rechenzentrum und ein Regionsfehler	Sicherungen, die an eine andere Azure-Region ausgeliefert wurden: - Schützt vor regionalen Fehlern. - Erfordert, dass während eines Failovers die gesamte Azure-Umgebung in der Zielregion eingerichtet wird.	- RPO ist größer oder gleich als 24 Stunden. - RTO ist größer oder gleich als 4 Stunden.

Nächster Schritt

Erfahren Sie mehr über Designüberlegungen für die Sicherheit von Oracle in VM-Zielzonenbeschleunigern in einem Unternehmensszenario.

Sicherheitsrichtlinien für Zielzonenbeschleuniger für Oracle auf VMs

Freigeben über