Erfahren Sie mehr über Disaster Recovery für lokale und regionale Standbys

Die Sicherstellung der Geschäftskontinuität ist entscheidend für den Erfolg beim Entwerfen von Anwendungen. Um dies zu erreichen, ist eine Disaster-Recovery-Strategie erforderlich, die den Service bei Unterbrechungen schnell wiederherstellen kann.

Seit Jahrzehnten verlassen sich Unternehmen auf Oracle Exadata Database Machine und Oracle Data Guard, die führende Disaster-Recovery-Technologie von Oracle, um geschäftskritische Anwendungen zu unterstützen, sowohl On-Premises als auch innerhalb von Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Dedicated Infrastructure auf Oracle Database@AWS bietet dieselbe branchenführende Performance, dasselbe Featureset und dieselbe Preisparität wie Exadata auf OCI. Die Hardware befindet sich in den Rechenzentren von AWS, um AWS-Anwendungen eine geringe Latenz zu bieten, die auf unübertroffenen Hochverfügbarkeits- und Disaster Recovery-Funktionen basiert und einen nahtlosen Betrieb während der Wartung und im Falle einer Unterbrechung gewährleistet.

In diesem Lösungs-Playbook erfahren Sie, wie Sie Disaster Recovery mit lokalen und regionalen Standbydatenbanken auf Oracle Database@AWS implementieren.

Bevor Sie beginnen

Stellen Sie Folgendes sicher, bevor Sie beginnen.

• Die Exadata-Infrastruktur und die Exadata-VM-Cluster werden in der Standbyverfügbarkeitszone und -region bereitgestellt.
• Die Netzwerk-IP-CIDR-Bereiche für die primären und Standby-Exadata-VM-Cluster überschneiden sich nicht.

Prüfen Sie die folgenden Lösungen:

• Disaster Recovery mit regionsübergreifendem Data Guard auf Oracle Database@AWS implementieren
• Disaster Recovery mit zonenübergreifendem Data Guard auf Oracle Database@AWS implementieren
• Oracle Exadata Database Service on Dedicated Infrastructure
• Oracle Database@AWS bereitstellen

Prüfen Sie die folgenden zugehörigen Ressourcen:

• Lesen Sie die Best Practices zur Sicherheit für Ihre VPC in der Dokumentation zu Amazon Virtual Private Cloud
• Planen Sie den AWS-IP-Adressraum mit ODB-Netzwerkdesign

Architektur

Diese Architektur zeigt Oracle Exadata Database Service auf Oracle Database@AWS in einer Disaster-Recovery-Topologie mit zwei Standbydatenbanken:

• Eine lokale Standbydatenbank in derselben Region wie die primäre, jedoch in einer anderen Availability Zone.
• Eine Remote-Standbydatenbank in einer anderen Region.

Beschreibung der Abbildung exadb-dbaws-dr-arch.png

exadb-dbaws-dr-arch-oracle.zip

Oracle Database wird in einem Exadata-VM-Cluster in der primären Region 1 ausgeführt. Für Datenschutz und Disaster Recovery repliziert Active Data Guard die Daten in den folgenden beiden Exadata-VM-Clustern:

• Eine in derselben Region, jedoch in einer anderen Verfügbarkeitszone (lokale Standby-Datenbank). Eine lokale Standbydatenbank eignet sich ideal für Failover-Szenarien und bietet keinen Datenverlust für lokale Ausfälle, während Anwendungen ohne den Performance-Overhead für die Kommunikation mit einer Remoteregion weiter funktionieren.
• Eine zweite Standbydatenbank in einer anderen Region (Remote Standby). Eine Remotestandbydatenbank wird in der Regel für Disaster Recovery oder zum Auslagern von schreibgeschützten Workloads verwendet.

Obwohl der Active Data Guard-Netzwerktraffic das AWS-Backbone durchlaufen kann, empfiehlt Oracle diese Architektur, die ihn zur Optimierung des Durchsatzes und der Latenz über OCI leitet.

Das Oracle Exadata Database Service im Oracle Database@AWS-Netzwerk ist mit einem von Oracle verwalteten dynamischen Routinggateway (Dynamic Routing Gateway, DRG) mit dem Exadata-Clientsubnetz verbunden. Ein DRG ist auch erforderlich, um eine Peerverbindung zwischen VCNs in verschiedenen Regionen zu erstellen. Da pro VCN in OCI nur ein DRG zulässig ist, ist ein zweites VCN mit einem eigenen DRG erforderlich, um die Primär- und Standby-VCNs in jeder Region zu verbinden.

• Das primäre Exadata-VM-Cluster wird in Region 1, availability zone 1 in VCN1 mit CIDR 10.10.0.0/16 und Clientsubnetz-CIDR 10.10.1.0/24 bereitgestellt.
• VCN1 verfügt über lokale Peering-Gateways (LPGs) LPG1 remote und LPG1 local.
• Das Hub-VCN in der primären Region 1 ist Hub VCN1 mit CIDR 10.11.0.0/16.
• Das erste Standby-Exadata-VM-Cluster wird in Region 1, availability zone 2 in VCN2 mit CIDR 10.20.0.0/16 und Clientsubnetz-CIDR 10.20.1.0/24 bereitgestellt.
• VCN2 hat zwei LPGs LPG2 remote und LPG2 local.
• Das Hub-VCN ist mit dem Hub-VCN für die Primärdatenbank identisch. Hub VCN1 befindet sich in derselben Region.
• Hub VCN1 hat LPG Hub LPG1 und Hub LPG2 und DRG1.
• Das zweite Standby-Exadata-VM-Cluster wird in Region 2 in VCN3 mit CIDR 10.30.0.0/16 und Clientsubnetz-CIDR 10.30.1.0/24 bereitgestellt.
• VCN3 hat ein LPG LPG3 remote.
• Das Hub-VCN in der Remotestandbydatenbank Region 2 ist Hub VCN3 mit CIDR 10.33.0.0/16.
• Hub VCN3 hat das LPG Hub LPG3 und das DRG DRG3.
• Für die Hub-VCNs ist kein Subnetz erforderlich, um Transitrouting zu aktivieren. Daher können diese VCNs sehr kleine IP-CIDR-Bereiche verwenden.

Diese Architektur unterstützt die folgenden Komponenten:

• AWS-Region

  AWS-Regionen sind separate geografische Gebiete. Sie bestehen aus mehreren, physisch getrennten und isolierten Verfügbarkeitszonen, die mit einer niedrigen Latenz, einem hohen Durchsatz und hochredundanten Netzwerken verbunden sind.

• AWS-Verfügbarkeitszone

  Verfügbarkeitszonen sind hochverfügbare Rechenzentren in jeder AWS-Region.

• Virtuelles OCI-Cloud-Netzwerk und Subnetz

  Ein virtuelles Cloud-Netzwerk (VCN) ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer OCI-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten Sie über VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

• Routentabelle

  Virtuelle Routentabellen enthalten Regeln zum Weiterleiten von Traffic von Subnetzen zu Zielen außerhalb eines VCN, in der Regel über Gateways.

• Netzwerksicherheitsgruppe (NSG)

  NSGs fungieren als virtuelle Firewalls für Ihre Cloud-Ressourcen. Mit dem Zero-Trust-Sicherheitsmodell von OCI steuern Sie den Netzwerkverkehr innerhalb eines VCN. Eine NSG besteht aus einer Gruppe von Ingress- und Egress-Sicherheitsregeln, die ausschließlich für ein bestimmtes Set von virtuellen Netzwerkschnittstellenkarten (VNICs) in einem einzelnen VCN gelten.

• Lokales Peering

  Mit lokalem Peering können zwei VCNs innerhalb derselben OCI-Region direkt über private IP-Adressen kommunizieren. Diese Kommunikation durchläuft weder das Internet noch Ihr On-Premise-Netzwerk. Lokales Peering wird durch ein lokales Peering-Gateway (LPG) aktiviert, das als Verbindungspunkt zwischen VCNs dient. Konfigurieren Sie ein LPG in jedem VCN, und richten Sie eine Peering-Beziehung ein, damit Instanzen, Load Balancer und andere Ressourcen in einem VCN sicher auf Ressourcen in einem anderen VCN innerhalb derselben Region zugreifen können.

• Dynamisches Routinggateway (DRG)

  Das DRG ist ein virtueller Router, der einen Pfad für den privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, z.B. ein VCN in einer anderen OCI-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.

• Remote-Peering

  Remote-Peering ermöglicht die private Kommunikation zwischen Ressourcen in verschiedenen VCNs, die sich in derselben oder verschiedenen OCI-Regionen befinden können. Jedes VCN verwendet sein eigenes dynamisches Routinggateway (DRG) für Remote-Peering. Die DRGs leiten den Traffic zwischen den VCNs sicher über das private Backbone von OCI weiter, sodass Ressourcen mit privaten IP-Adressen kommunizieren können, ohne Traffic über das Internet oder über On-Premise-Netzwerke zu leiten. Beim Remote-Peering sind keine Internetgateways oder öffentlichen IP-Adressen mehr für Instanzen erforderlich, die regionsübergreifend verbunden sein müssen.

• Oracle Exadata Database Service on Dedicated Infrastructure

  Mit Oracle Exadata Database Service on Dedicated Infrastructure können Sie die Leistungsfähigkeit von Exadata in der Cloud nutzen. Oracle Exadata Database Service bietet bewährte Oracle AI Database-Funktionen auf einer speziell entwickelten, optimierten Oracle Exadata-Infrastruktur in der Public Cloud. Die integrierte Cloud-Automatisierung, elastische Ressourcenskalierung, Sicherheit und schnelle Performance für alle Oracle AI Database-Workloads helfen Ihnen, das Management zu vereinfachen und Kosten zu senken.

• Oracle Data Guard

  Oracle Data Guard und Active Data Guard bieten ein umfassendes Set an Services, mit denen eine oder mehrere Standbydatenbanken erstellt, gewartet, verwaltet und überwacht werden können und die es Oracle-Produktionsdatenbanken ermöglichen, ohne Unterbrechung verfügbar zu bleiben. Oracle Data Guard verwaltet diese Standbydatenbanken mit In-Memory-Replikation als Kopien der Produktionsdatenbank. Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, kann Oracle Data Guard jede Standbydatenbank auf die Produktionsrolle umstellen und so die Ausfallzeit minimieren, die mit dem Ausfall verbunden ist. Oracle Active Data Guard bietet die zusätzliche Möglichkeit, Workloads mit Lesezugriffen in Standbydatenbanken auszulagern, und bietet außerdem erweiterte Datenschutzfunktionen.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für das Disaster Recovery für Oracle Exadata Database Service auf Oracle Database@AWS. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.

• Verwenden Sie Active Data Guard zur umfassenden Vermeidung von Datenbeschädigungen mit automatischer Blockreparatur, Onlineupgrades und Migrationen sowie zum Auslagern der Workload in die Standbydatenbank mit meist horizontalem Lesezugriff.
• Aktivieren Sie Application Continuity, um Datenbankausfälle während geplanter und ungeplanter Ereignisse von Endbenutzern zu maskieren.
• Konfigurieren Sie automatische Backups in Oracle Database Autonomous Recovery Service in OCI. Obwohl Daten durch Oracle Data Guard geschützt sind, minimieren Sie die Backup-Workload in der Datenbank, indem Sie die Backupstrategie incremental-forever implementieren, mit der wöchentliche vollständige Backups eliminiert werden. Alternativ können Sie Amazon Simple Storage Service für automatische Backups verwenden.
• Führen Sie Backups aus der Standbydatenbank aus, um die regionsübergreifende Backupreplikation zu erreichen.
• Mit OCI Full Stack DR können Sie Datenbank-Switchover- und Failover-Vorgänge orchestrieren.
• Speichern Sie die Transparent Data Encryption-(TDE-)Schlüssel der Datenbank in OCI Vault mit vom Kunden verwalteten Schlüsseln.

Hinweise

Bei der Durchführung eines lokalen und regionalen Disaster Recoverys für Oracle Exadata Database Service auf Oracle Database@AWS sollten Sie Folgendes berücksichtigen:

• Wenn Exadata-VM-Cluster in der untergeordneten Oracle Database@AWS-Site erstellt werden, wird jedes Exadata-VM-Cluster in seinem eigenen OCI-VCN bereitgestellt. Peer der VCNs und Vermeidung sich überschneidender CIDRs. Stellen Sie sicher, dass die Datenbanken miteinander kommunizieren, damit Data Guard redo-Daten versenden kann.
• Die regionsübergreifende Latenz ist in der Regel zu hoch für den synchronen Transport in geschäftskritischen Anwendungen. Verwenden Sie daher die Data Guard-ASYNC-Replikation regionsübergreifend. Fügen Sie Active Data Guard Far Sync hinzu, um regionsübergreifend keinen Datenverlust zu gewährleisten.
• Konfigurieren Sie OCI als bevorzugtes Netzwerk für bessere Performance, geringere Latenz, höheren Durchsatz und geringere Kosten. Die ersten 10 TB/Monat des Daten-Egress sind regionsübergreifend kostenlos.
• Mit Cloud-Tooling können Sie bis zu sechs Standbydatenbanken pro Primärdatenbank erstellen.

Erforderliche Services und Rollen

Für diese Lösung sind die folgenden Services und Rollen erforderlich:

• Oracle Cloud Infrastructure Networking
• Oracle Exadata Database Service

Dies sind die Rollen, die für jeden Service erforderlich sind.

Servicename: Rolle	Erforderlich für...
Oracle Exadata Database Service: manage database-family	Datenbank verwalten, einschließlich Hinzufügen und Betreiben von Active Data Guard-Deployments
OCI Networking: manage vcn-family	Netzwerkkomponenten verwalten, einschließlich VCNs, Subnetze, Sicherheitsregeln und VCN-Peering

Informationen zu Ihren Anforderungen finden Sie unter Produkte, Lösungen und Services von Oracle.