Implementierungsarchitektur

Diese Architektur zeigt Oracle Exadata Database Service auf Oracle Database@AWS mit einem Active Data Guard-Deployment mit Primär- und Standbydatenbanken in zwei verschiedenen Regionen.

Architektur

Das folgende Diagramm veranschaulicht diese Architektur.


Beschreibung von db-aws-dr-cross-region.png folgt
Beschreibung der Abbildung db-aws-dr-cross-region.png

db-aws-dr-cross-region-oracle.zip

Die Oracle Database wird in einem Exadata-VM-Cluster in der primären Region ausgeführt. Für Datenschutz und Disaster Recovery repliziert Oracle Active Data Guard die Daten in einer anderen Region (Remote-Standby). Ein Remote Standby-Datenbanksetup gewährleistet den Datenschutz vor regionalen Ausfällen und kann auch zum Auslagern der schreibgeschützten Abfrageverarbeitung verwendet werden. Sie sollten die Anwendung auch regionsübergreifend replizieren, um eine höhere Latenz zu vermeiden, nachdem die Standbydatenbank zur primären Datenbank wird.

Sie können Active Data Guard-Traffic über das AWS-Netzwerk weiterleiten. Diese Architektur leitet den Active Data Guard-Netzwerktraffic jedoch durch das OCI-Netzwerk, um den Netzwerkdurchsatz und die Latenz zu optimieren. Die VCNs auf der OCI-Site werden erstellt, nachdem die Oracle Exadata Database Service on Dedicated Infrastructure-VM-Cluster auf Oracle Database@AWS für die Primär- und die Standbydatenbank erstellt wurden.

Der Oracle Exadata Database Service im Oracle Database@AWS-Netzwerk ist über ein von Oracle verwaltetes dynamisches Routinggateway (Dynamic Routing Gateway, DRG) mit dem Exadata-Clientsubnetz verbunden. Ein DRG ist auch erforderlich, um eine Peerverbindung zwischen virtuellen Cloud-Netzwerken (VCNs) in verschiedenen Regionen zu erstellen. Da pro VCN in OCI nur ein DRG zulässig ist, ist ein zweites VCN erforderlich, das als Hub-VCN mit einem eigenen DRG fungiert, um die Primär- und Standby-VCNs in jeder Region zu verbinden.

In dieser Architektur:

  • Das primäre Exadata-VM-Cluster wird in der primären Region in VCN1 mit CIDR 10.10.0.0/16 und Clientsubnetz-CIDR 10.10.1.0/24 bereitgestellt.
  • VCN1 verfügt über ein lokales Peering-Gateway LPG1remote.
  • Das Hub-VCN in der primären Region ist HubVCN1 mit CIDR 10.11.0.0/16.
  • HubVCN1 verfügt über ein lokales Peering-Gateway HubLPG1 und ein dynamisches Routinggateway DRG1.
  • VCN1 und HubVCN1 werden über LPG1remote und HubLPG1 mit einer lokalen Peering-Verbindung abgeglichen.
  • Das Standby-Exadata-VM-Cluster wird in der Standbyregion in VCN2 mit CIDR 10.20.0.0/16 und Clientsubnetz-CIDR 10.20.1.0/24 bereitgestellt.
  • VCN2 verfügt über ein lokales Peering-Gateway LPG2remote.
  • Das Hub-VCN in der Standbyregion ist HubVCN2 mit CIDR 10.22.0.0/16.
  • HubVCN2 verfügt über ein lokales Peering-Gateway HubLPG2 und ein dynamisches Routinggateway DRG2.
  • VCN2 und HubVCN2 werden über LPG2remote und HubLPG2 mit einer lokalen Peering-Verbindung abgeglichen.
  • HubVCN1 und HubVCN2 werden über DRG1 und DRG2 mit einer Romete-Peering-Verbindung abgeglichen.

AWS stellt folgende Komponenten bereit:

  • AWS-Verfügbarkeitszone

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

  • ODB-Netzwerk

    Ein ODB-Netzwerk ist ein privates Netzwerk, das Oracle Database@AWS in einer angegebenen Availability-Zone hostet. Sie können eine ODB-Peering-Verbindung zwischen einem ODB-Netzwerk und einer VPC einrichten, um eine Verbindung zu Ihren Oracle-Datenbanken herzustellen.

  • 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.

  • Virtuelle private Amazon-Cloud und Subnetz

    Mit der virtuellen privaten Amazon-Cloud (VPC) können Sie AWS-Ressourcen in einem von Ihnen definierten virtuellen Netzwerk starten. Dieses virtuelle Netzwerk ähnelt einem herkömmlichen Netzwerk, das Sie in Ihrem eigenen Rechenzentrum betreiben, mit den Vorteilen der Verwendung der skalierbaren Infrastruktur von AWS. Nachdem Sie eine VPC erstellt haben, können Sie Subnetze hinzufügen.

    Ein Subnetz ist ein Bereich von IP-Adressen in Ihrer Amazon VPC. Sie können AWS-Ressourcen, wie Amazon EC2-Instanzen, in bestimmten Subnetzen erstellen.

Oracle Cloud Infrastructure stellt die folgenden Komponenten bereit:

  • Oracle Data Guard

    Oracle Data Guard und Oracle Active Data Guard bieten ein umfassendes Set von Services, mit denen eine oder mehrere Standbydatenbanken erstellt, gewartet, verwaltet und überwacht werden 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.

  • 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.

  • 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 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 Database-Workloads helfen Ihnen, das Management zu vereinfachen und Kosten zu senken.

  • Lokale Peering-Gruppe (LPG)

    Ein LPG stellt Peering zwischen VCNs in derselben Region bereit. Peering bedeutet, dass die VCNs über private IP-Adressen kommunizieren, ohne das der Traffic über das Internet oder über das On-Premise-Netzwerk geleitet werden.

  • 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.

  • OCI-region

    Eine OCI-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Centre enthält, das Availability-Domains hostet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.

  • Remote-Peering

    Mit Remote-Peering können Ressourcen innerhalb verschiedener VCNs über private IP-Adressen kommunizieren. Beim Remote-Peering ist kein Internetgateway oder keine öffentlichen IP-Adressen für Instanzen erforderlich, die mit einem anderen VCN in einer andere Region kommunizieren müssen.

  • Routentabelle

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

  • 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.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für die Implementierung von 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 für umfassende Datenbeschädigungsvermeidung mit automatischer Blockreparatur, Onlineupgrades und Migrationen sowie Auslagerung 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 und unterbrechungsfreie Anwendungen sicherzustellen.
  • Richten Sie ein automatisches Backup in Oracle Database Autonomous Recovery Service (in OCI) ein, obwohl die Daten durch Oracle Data Guard geschützt sind, um die Backup-Workload in der Datenbank zu minimieren, indem Sie die inkrementelle Strategie für unbegrenztes Backup implementieren, mit der wöchentliche vollständige Backups eliminiert werden. Alternativ können Kunden AWS S3 Object Storage für automatische Backups verwenden.
  • Aktivieren Sie Backups aus der Standbydatenbank, um die regionsübergreifende Backupreplikation zu erreichen.
  • Mit OCI Full Stack Disaster Recovery können Sie Datenbank-Switchover- und Failover-Vorgänge orchestrieren.
  • Mit OCI Vault können Sie die TDE-(Transparent Data Encryption-)Schlüssel der Datenbank mit vom Kunden verwalteten Schlüsseln speichern.

Hinweise

Bei der Implementierung von Disaster Recovery für Oracle Exadata Database Service auf Oracle Database@AWS mit einer Remote-Standbydatenbank von Data Guard 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 erstellt. Data Guard erfordert, dass die Datenbanken miteinander kommunizieren, um redo-Daten zu versenden. Die VCNs müssen per Peering verbunden werden, um diese Kommunikation zu ermöglichen. Daher dürfen die Exadata-VM-Cluster-VCNs keine sich überschneidenden IP-CIDR-Bereiche gemeinsam verwenden.
  • Die Netzwerklatenz über Regionen hinweg ist in der Regel höher als die meisten geschäftskritischen Anwendungen tolerieren können. Daher sollten Sie den Schutzmodus für maximale Performance von Data Guard und die asynchrone Replikation verwenden. Verwenden Sie Active Data Guard Far Sync, um regionsübergreifend keinen Datenverlust sicherzustellen.
  • OCI ist das bevorzugte Netzwerk, um eine bessere Performance zu erreichen, gemessen an Latenz und Durchsatz, und um geringere Kosten zu erzielen, einschließlich der ersten 10 TB/Monat-Egress kostenlos.
  • Über Cloud-Tooling können Sie bis zu sechs Standbydatenbanken für eine Primärdatenbank erstellen.