Regionsübergreifendes Disaster Recovery für Oracle Exadata Database Service auf Oracle Database@Azure implementieren

Bei der Entwicklung von Anwendungen ist es wichtig, die Geschäftskontinuität sicherzustellen, indem ein robuster Disaster Recovery-Mechanismus für die Wiederherstellung von Vorgängen im Falle eines Ausfalls eingerichtet wird.

Seit vielen Jahren vertrauen Kunden Oracle Exadata Database Service mit Oracle Maximum Availability Architecture (MAA), um geschäftskritische Anwendungen sowohl On Premise als auch auf Oracle Cloud Infrastructure (OCI) zu betreiben. Oracle Exadata Database Service auf Oracle Database@Azure bietet Feature- und Preisparität mit Exadata auf OCI und kann über mehrere Microsoft Azure-Verfügbarkeitszonen (AZs) und Regionen bereitgestellt werden, um High Availability und Disaster Recovery sicherzustellen.

Architektur

Diese Architektur zeigt eine hochverfügbare, containerisierte Azure Kubernetes Service-(AKS-)Anwendung mit Oracle Exadata Database Service auf Oracle Database@Azure in einer regionsübergreifenden Disaster-Recovery-Topologie.

Eine hochverfügbare, containerisierte Azure Kubernetes Service-(AKS-)Anwendung wird in zwei Azure-Regionen bereitgestellt: einer primären Region und einer Standbyregion. Die Containerimages werden in der Azure-Container-Registry gespeichert und zwischen primären und Standbyregionen repliziert. Benutzer greifen über einen öffentlichen Load Balancer extern auf die Anwendung zu.

Zum Datenschutz wird Oracle Database in einem Exadata-VM-Cluster in der primären Region ausgeführt. Dabei replizieren Oracle Data Guard oder Oracle Active Data Guard die Daten in der Standbydatenbank, die auf einem Exadata-VM-Cluster in der Standbyregion ausgeführt wird.

Die Datenbankschlüssel für transparente Datenverschlüsselung (TDE) werden in Oracle Cloud Infrastructure Vault gespeichert und zwischen den Azure- und OCI-Regionen repliziert. Die automatischen Backups befinden sich sowohl für die primäre als auch für die Standbyregion in OCI. Kunden können Oracle Cloud Infrastructure Object Storage oder Oracle Database Autonomous Recovery Service als bevorzugte Speicherlösung verwenden.

Das Oracle Exadata Database Service-Netzwerk auf Oracle Database@Azure ist mit einem von Oracle verwalteten dynamischen Routinggateway (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 eigenem DRG erforderlich, um die primären und Standby-VCNs in jeder Region zu verbinden. In diesem Beispiel:

  • Das primäre Exadata-VM-Cluster wird im primären VCN-Clientsubnetz des VCN bereitgestellt (10.5.0.0/24).
  • Das VCN für das primäre Hub-VCN für das Transitnetzwerk lautet 10.15.0.0/29.
  • Das Standby-Exadata-VM-Cluster wird im VCN-Standby-VCN-Clientsubnetz (10.6.0.0/24) bereitgestellt.
  • Das VCN Hub-VCN-Standby für das Transfernetzwerk lautet 10.16.0.0/29.

Damit die Hub-VCNs das Transitrouting aktivieren können, ist kein Subnetz erforderlich. Daher können diese VCNs ein sehr kleines Netzwerk verwenden. Die VCNs auf der untergeordneten OCI-Site werden erstellt, nachdem die Oracle Exadata Database Service-VM-Cluster auf Oracle Database@Azure für die Primär- und Standbydatenbank erstellt wurden.

Im folgenden Diagramm wird die Architektur dargestellt:


Beschreibung von exadb-dr-db-azure.png folgt
Beschreibung der Abbildung exadb-dr-db-azure.png

exadb-dr-db-azure-oracle.zip

Microsoft Azure stellt die folgenden Komponenten bereit:

  • Microsoft Azure-Region

    Eine Azure-Region ist ein geografisches Gebiet, in dem sich mindestens ein physisches Azure-Data Center, sogenannte Availability Zones, befindet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).

    Azure- und OCI-Regionen sind lokalisierte geografische Bereiche. Bei Oracle Database@Azure ist eine Azure-Region mit einer OCI-Region verbunden, wobei Verfügbarkeitszonen (Availability Zones, AZs) in Azure mit Availability-Domains (ADs) in OCI verbunden sind. Azure- und OCI-Regionspaare werden ausgewählt, um Entfernung und Latenz zu minimieren.

  • Microsoft Azure-Verfügbarkeitszone

    Eine Verfügbarkeitszone ist ein physisch getrenntes Data Center innerhalb einer Region, das hochverfügbar und fehlertolerant ist. Verfügbarkeitszonen sind nahe genug, um Verbindungen mit geringer Latenz zu anderen Verfügbarkeitszonen zu haben.

  • Microsoft Azure Virtual Netwok

    Microsoft Azure Virtual Network (VNet) ist der grundlegende Baustein für ein privates Netzwerk in Azure. Mit VNet können viele Arten von Azure-Ressourcen wie virtuelle Azure-Maschinen (VM) sicher miteinander, mit dem Internet und mit On-Premise-Netzwerken kommunizieren.

  • Delegiertes Microsoft Azure-Subnetz

    Mit der Subnetzdelegierung können Sie einen verwalteten Service, insbesondere einen Platform-as-a-Service-(PaaS-)Service, direkt in Ihr virtuelles Netzwerk injizieren. Ein delegiertes Subnetz kann ein Home für einen extern verwalteten Service in Ihrem virtuellen Netzwerk sein, sodass der externe Service als virtuelle Netzwerkressource fungiert, obwohl es sich um einen externen PaaS-Service handelt.

  • Microsoft Azure-VNIC

    Die Dienste in Azure-Data Centern weisen physische Netzwerkkarten (NICs) auf. Instanzen virtueller Maschinen kommunizieren über virtuelle NICs (VNICs), die mit den physischen NICs verknüpft sind. Jede Instanz verfügt über eine primäre VNIC, die beim Start automatisch erstellt und angehängt wird und während der Lebensdauer der Instanz verfügbar ist.

  • Microsoft Azure-Routentabelle

    Virtuelle Routentabellen enthalten Regeln zum Weiterleiten von Traffic von Subnetzen zu Zielen außerhalb einer VNet, in der Regel über Gateways. Routentabellen sind mit Subnetzen in einer VNet verknüpft.

  • Virtuelles Azure-Netzwerkgateway

    Der Azure Virtual Network Gateway-Service stellt eine sichere, standortübergreifende Konnektivität zwischen einem virtuellen Azure-Netzwerk und einem On-Premise-Netzwerk her. Es ermöglicht Ihnen, ein hybrides Netzwerk zu erstellen, das Ihr Rechenzentrum und Azure umfasst.

Oracle Cloud Infrastructure stellt die folgenden Komponenten bereit:

  • Region

    Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält und Availability-Domains hostet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).

  • Availability-Domain

    Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz sicherstellt. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Daher sollte ein Fehler in einer Availability-Domain sich nicht auf die anderen Availability-Domains in der Region auswirken.

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetze

    Ein VCN ist ein anpassbares, benutzerdefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich 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.

  • Sicherheitsliste

    Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der in und aus dem Subnetz zulässig ist.

  • Dynamisches Routinggateway (DRG)

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

  • Servicegateway

    Ein Servicegateway ermöglicht den Zugriff von einem VCN auf andere Services wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zum Oracle-Service wird über die Oracle-Netzwerkstruktur geleitet und durchläuft nicht das Internet.

  • Lokales Peering

    Mit lokalem Peering können Sie ein VCN mit einem anderen VCN in derselben Region verknüpfen. Peering bedeutet, dass die VCNs über private IP-Adressen kommunizieren, ohne dass der Traffic über das Internet oder das On-Premise-Netzwerk geleitet wird.

  • Netzwerksicherheitsgruppe (NSG)

    NSGs fungieren als virtuelle Firewalls für Ihre Cloud-Ressourcen. Mit dem Zero-Trust-Sicherheitsmodell von Oracle Cloud Infrastructure steuern Sie den Netzwerktraffic in einem VCN. Eine NSG besteht aus einer Gruppe von Ingress- und Egress-Sicherheitsregeln, die nur für eine bestimmte Gruppe von VNICs in einem einzelnen VCN gelten.

  • Object Storage

    Mit OCI Object Storage können Sie auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps zugreifen, darunter Datenbankbackups, Analysedaten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher im Internet oder in der Cloud-Plattform speichern. Sie können den Speicher skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird.

    Verwenden Sie Standardspeicher für "guten" Speicher, auf den Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicher für "Cold Storage", den Sie über lange Zeiträume beibehalten und auf den Sie nur selten zugreifen.

  • Data Guard

    Oracle Data Guard und Oracle Active Data Guard stellen ein umfassendes Set von Services bereit, mit denen eine oder mehrere Standbydatenbanken erstellt, gewartet, verwaltet und überwacht werden und Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben können. 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 in die Produktionsrolle umschalten, wodurch die Ausfallzeit im Zusammenhang mit dem Ausfall minimiert wird. Oracle Active Data Guard bietet die zusätzliche Möglichkeit, Workloads, die hauptsächlich gelesen werden, in Standbydatenbanken auszulagern, und bietet außerdem erweiterte Datenschutzfunktionen.

  • Oracle Database Autonomous Recovery Service

    Oracle Database Autonomous Recovery Service ist ein Oracle Cloud-Service, der Oracle-Datenbanken schützt. Mit Backupautomatisierung und erweiterten Datenschutzfunktionen für OCI-Datenbanken können Sie alle Backupverarbeitungs- und Speicheranforderungen an Oracle Database Autonomous Recovery Service auslagern, was die Kosten der Backupinfrastruktur und den manuellen Administrationsaufwand reduziert.

  • Exadata Database Service

    Oracle Exadata ist eine Unternehmensdatenbankplattform, die Oracle Database-Workloads jeder Größenordnung und Kritikalität mit hoher Performance, Verfügbarkeit und Sicherheit ausführt. Das Scale-Out-Design von Exadata nutzt einzigartige Optimierungen, mit denen Transaktionsverarbeitung, Analysen, maschinelles Lernen und gemischte Workloads schneller und effizienter ausgeführt werden können. Durch die Konsolidierung verschiedener Oracle Database-Workloads auf Exadata-Plattformen in Unternehmens-Data Centern, auf Oracle Cloud Infrastructure (OCI) und in Multicloud-Umgebungen können Unternehmen die betriebliche Effizienz steigern, die IT-Administration reduzieren und Kosten senken.

    ermöglicht es Ihnen, die Leistungsfähigkeit von Exadata in der Cloud zu nutzen. Oracle Exadata Database Service bietet bewährte Oracle Database-Funktionen auf einer speziell entwickelten, optimierten Oracle Exadata-Infrastruktur in der Public Cloud. Dank integrierter Cloud-Automatisierung, elastischer Ressourcenskalierung, Sicherheit und schneller Performance für alle Oracle Database-Workloads können Sie die Verwaltung vereinfachen und Kosten senken.

  • Oracle Database@Azure

    Oracle Database@Azure ist der auf Oracle Cloud Infrastructure (OCI) ausgeführte Oracle Database-Service (Oracle Exadata Database Service on Dedicated Infrastructure und Oracle Autonomous Database Serverless), der in Microsoft Azure-Data Centern bereitgestellt wird. Der Service bietet Features und Preisparität mit OCI. Erwerben Sie den Service im Azure Marketplace.

    Oracle Database@Azure integriert die Technologien Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) und Oracle Data Guard in die Azure-Plattform. Benutzer verwalten den Service auf der Azure-Konsole und mit Azure-Automatisierungstools. Der Service wird im virtuellen Azure-Netzwerk (VNet) bereitgestellt und in das Identitäts- und Zugriffsverwaltungssystem von Azure integriert. Die generischen Metriken und Auditlogs von OCI und Oracle Database sind nativ in Azure verfügbar. Für den Service müssen Benutzer über ein Azure-Abonnement und einen OCI-Mandanten verfügen.

    Autonomous Database basiert auf der Oracle Exadata-Infrastruktur und ist selbstverwaltend, selbstsichernd und selbstreparierend, wodurch manuelle Datenbankverwaltung und menschliche Fehler vermieden werden. Autonomous Database ermöglicht die Entwicklung skalierbarer KI-gestützter Apps mit beliebigen Daten mithilfe integrierter KI-Funktionen unter Verwendung des LLM-Modells (Großsprache) und des Bereitstellungsorts Ihrer Wahl.

    Sowohl Oracle Exadata Database Service als auch Oracle Autonomous Database Serverless können einfach über das native Azure-Portal bereitgestellt werden, um den Zugriff auf das breitere Azure-Ökosystem zu ermöglichen.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für die regionsübergreifende Disaster Recovery für Oracle Exadata Database Service in Oracle Database@Azure. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.
  • Stellen Sie die erforderliche Exadata-Infrastruktur sowohl in der Primär- als auch in der Standbyregion bereit. Stellen Sie für jede Exadata-Instanz ein Exadata-VM-Cluster im delegierten Subnetz eines virtuellen Microsoft Azure-Netzwerks bereit (VNet). Die Oracle Real Application Clusters-(RAC-)Datenbank kann dann im Cluster instanziiert werden. Stellen Sie in derselben VNet Azure Kubernetes Service (AKS) in einem separaten Subnetz bereit. Konfigurieren Sie Oracle Data Guard so, dass Daten regionsübergreifend von einer Oracle Database in die andere repliziert werden.
  • Wenn Exadata-VM-Cluster in der untergeordneten Oracle Database@Azure-Site erstellt werden, wird jedes in seinem eigenen virtuellen Oracle Cloud Infrastructure-Cloud-Netzwerk (VCN) erstellt. Oracle Data Guard erfordert, dass die Datenbanken miteinander kommunizieren, um Redo-Daten zu senden. Um diese Kommunikation zu ermöglichen, müssen die VCNs per Peering verbunden werden.

Hinweise

Beachten Sie beim regionsübergreifenden Disaster Recovery für Oracle Exadata Database Service auf Oracle Database@Azure Folgendes.

  • Die Vorbereitung auf ein Disaster-Szenario erfordert einen umfassenden Ansatz, der verschiedene Geschäftsanforderungen und Verfügbarkeitsarchitekturen berücksichtigt und diese Überlegungen in einem umsetzbaren, hochverfügbaren (HA), Disaster-Recovery-(DR-)Plan umfasst. Das hier beschriebene Szenario enthält Richtlinien, mit denen Sie den Ansatz auswählen können, der am besten zu Ihrem Anwendungs-Deployment passt, indem Sie einen einfachen, aber effektiven Failover für die Disaster-Recovery-Konfiguration in Ihren Oracle Cloud Infrastructure-(OCI-) und Microsoft Azure-Umgebungen verwenden.
  • Verwenden Sie Oracle Data Guard regionsübergreifend für die Datenbanken, die im Exadata-VM-Cluster auf Oracle Database@Azure bereitgestellt sind, indem Sie ein von OCI verwaltetes Netzwerk verwenden.
  • Oracle Cloud Infrastructure ist das bevorzugte Netzwerk, um eine bessere Performance zu erzielen, gemessen an Latenz und Durchsatz, und um reduzierte Kosten zu erzielen, da die ersten 10 TB/Monat kostenlos sind.

Stellen Sie

Führen Sie die folgenden allgemeinen Schritte aus, um die Netzwerkkommunikation zwischen Regionen zu konfigurieren, die im obigen Architekturdiagramm dargestellt sind.

Primärbereich

  1. Erstellen Sie ein virtuelles Cloud-Netzwerk (VCN), HUB-VCN primär, in der primären Region von Oracle Cloud Infrastructure (OCI).
  2. Stellen Sie zwei lokale Peering-Gateways (LPGs), Primär-LPG und HUB-Primär-LPG in VCN-Primär bzw. HUB-VCN-Primär bereit.
  3. Richten Sie eine Peer-LPG-Verbindung zwischen den LPGs für HUB-VCN primär und VCN primär ein.
  4. Erstellen Sie ein dynamisches Routinggateway (DRG), Primäres DRG im VCN mit dem primären Hub-VCN.
  5. Erstellen Sie im VCN HUB-VCN primär die Routentabelle primary_hub_transit_drg, und weisen Sie das Ziel des primären VCN-Clientsubnetzes, den Zieltyp LPG und das Ziel-HUB-Primär-LPG zu. Beispiel: 
    10.5.0.0/24 target type: LPG, Target: Hub-Primary-LPG
  6. Erstellen Sie im HUB-VCN-Primär-VCN eine zweite Routentabelle, primary_hub_transit_lpg, und weisen Sie das Ziel des VCN-Standby-Clientsubnetzes, ein Zieltyp-DRG und ein Ziel-Primär-DRG zu. Beispiel: 
    10.6.0.0/24 target type: DRG, Target: Primary-DRG
  7. Hängen Sie im VCN mit der primären Hub-VCN die primäre Hub-VCN an das DRG an. Bearbeiten Sie die DRG-VCN-Anhänge, und bearbeiten Sie unter "Erweiterte Optionen" die VCN-Registerkartentabelle, um sie mit der Routentabelle primary_hub_transit_drg zu verknüpfen. Diese Konfiguration ermöglicht das Transitrouting.
  8. Verknüpfen Sie im VCN mit der primären Hub-VCN die Routentabelle primary_hub_transit_lpg mit dem Gateway Hub-Primary-LPG.
  9. Fügen Sie in der Standardroutentabelle Primäres Hub-VCN eine Routingregel für den IP-Adressbereich des primären VCN-Clientsubnetzes hinzu, um das LPG zu verwenden. Fügen Sie eine weitere Routingregel für den IP-Adressbereich des VCN-Standby-Clientsubnetzes hinzu, um das DRG zu verwenden. Beispiel:
    10.5.0.0/24 LPG Hub-Primary-LPG
10.6.0.0/24 DRG Primary-DRG
  10. Wählen Sie unter Primäres DRG die DRG-Routentabelle, die automatisch generierte DRG-Routentabelle für RPC-, VC- und IPSec-Anhänge aus. Fügen Sie eine statische Route zum IP-Adressbereich des VCN-Primär-Subnetzclients hinzu, der das Primär-VCN des Hub-VCN mit dem Anhangstyp des nächsten Hops VCN und dem Anhangsnamen des nächsten Hops Primärhubanhang verwendet. Beispiel: 
    10.5.0.0/24 VCN Primary Hub attachment
  11. Verwenden Sie das Menü "Anhänge für Primär-DRG-Remote-Peering-Verbindungen", um eine Remote-Peering-Verbindung zu erstellen, RPC.
  12. Aktualisieren Sie im Subnetz des primären VCN-Clients die Netzwerksicherheitsgruppe (NSG), um eine Sicherheitsregel zu erstellen, die Ingress für TCP-Port 1521 zulässt. Optional können Sie SSH-Port 22 für direkten SSH-Zugriff auf die Datenbankserver hinzufügen.

    Hinweis:

    Um eine genauere Konfiguration zu erhalten, deaktivieren Sie die Importroutenverteilung der automatisch generierten DRG-Routentabelle für RPC-, VC- und IPSec-Anhänge-Routentabelle. Erstellen und weisen Sie unter Automatisch generierte DRG-Routentabelle für VCN-Anhänge eine neue Importroutenverteilung zu, die nur den erforderlichen RPC-Anhang enthält.

Standby-Region

  1. Erstellen Sie das VCN HUB-VCN-Standbydatenbank in der OCI-Standbydatenbankregion.
  2. Stellen Sie zwei LPGs, Standby-LPG und HUB-Standby-LPG, in den VCNs VCN-Standby und HUB-VCN-Standby bereit.
  3. Richten Sie eine Peer-LPG-Verbindung zwischen LPGs für die VCN-Standby und die HUB-VCN-Standby ein.
  4. Erstellen Sie ein DRG, Standby-DRG, im VCN der Hub-VCN-Standby.
  5. Erstellen Sie im HUB-VCN-Standby-VCN eine Routentabelle, standby_hub_transit_drg, und weisen Sie das Ziel des VCN-Standby-Clientsubnetzes, den Zieltyp LPG und ein HUB-Standby-LPG-Ziel zu. Beispiel: 
    10.6.0.0/24 target type: LPG, Target: Hub-Standby-LPG
  6. Erstellen Sie im HUB-VCN-Standby-VCN eine zweite Routentabelle, standby_hub_transit_lpg, und weisen Sie das Ziel des VCN-Primär-Clientsubnetzes, ein Zieltyp-DRG und ein Ziel-Standby-DRG zu. Beispiel: 
    10.5.0.0/24 target type: DRG, Target: Standby-DRG
  7. Hängen Sie im HUB-VCN-Standby-VCN das HUB-VCN-Standby-VCN an das DRG an. Bearbeiten Sie die DRG-VCN-Anhänge, und bearbeiten Sie unter "Erweiterte Optionen" die VCN-Routentabelle, um sie mit der Routentabelle standby_hub_transit_drg zu verknüpfen. Diese Konfiguration ermöglicht das Transitrouting.
  8. Fügen Sie im HUB-VCN-Standby-VCN in der Standardroutentabelle HUB-VCN-Standby Routingregeln für den IP-Adressbereich des VCN-Standby-Clientsubnetzes hinzu, um das LPG zu verwenden, und für den IP-Adressbereich des VCN-Primär-Clientsubnetzes, um das DRG zu verwenden. Beispiel: 
    10.6.0.0/24 LPG Hub-Standby-LPG
10.5.0.0/24 DRG Standby-DRG
  9. Verknüpfen Sie die Routentabelle standby_hub_transit_lpg mit dem Gateway Hub-Standby-LPG.
  10. Wählen Sie unter Standby-DRG die DRG-Routentabelle Automatisch generierte Drg-Routentabelle für RPC-, VC- und IPSec-Anhänge aus. Fügen Sie eine statische Route zum IP-Adressbereich des VCN-Standby-Subnetzclients hinzu, der das Hub-VCN-Standby-VCN mit dem nächsten Hop-Anhangstyp "VCN" und dem nächsten Hop-Anhangsnamen Standby-Hub-Anhang verwendet. Beispiel: 
    10.6.0.0/24 VCN Standby Hub attachment
  11. Verwenden Sie das Menü "Anhänge für Standby-DRG-Remote-Peering-Verbindungen", um eine Remote-Peering-Verbindung, RPC, zu erstellen.
  12. Wählen Sie die Remote-Peering-Verbindung aus, wählen Sie Verbindung herstellen aus, und geben Sie die OCID des Primär-DRG an. Der Peering-Status wird "Peering". Beide Regionen sind miteinander verbunden.
  13. Aktualisieren Sie im VCN-Standbydatenbank-Clientsubnetz die NSG, um eine Sicherheitsregel zu erstellen, die Ingress für TCP-Port 1521 zulässt. Optional können Sie SSH-Port 22 für direkten SSH-Zugriff auf die Datenbankserver hinzufügen.

Data Guard-Verbindung

  1. Um Oracle Data Guard oder Oracle Active Data Guard für Oracle Database zu aktivieren, klicken Sie auf der Detailseite für Oracle Database auf "Data Guard-Verknüpfungen", und klicken Sie dann auf Data Guard aktivieren.
  2. Auf der Seite "Data Guard aktivieren":
    1. Wählen Sie die Standby-Region.
    2. Wählen Sie die Standby-Availability-Domain aus, die Azure AZ zugeordnet ist.
    3. Wählen Sie die Standby-Exadata-Infrastruktur aus.
    4. Wählen Sie das gewünschte Standby-VM-Cluster aus.
    5. Wählen Sie Oracle Data Guard oder Oracle Active Data Guard aus. MAA empfiehlt Oracle Active Data Guard für die automatische Blockreparatur von Datenbeschädigungen und die Möglichkeit, Berichte auszulagern.
    6. Bei regionsübergreifenden Oracle Data Guard-Verbindungen wird nur der Schutzmodus für maximale Performance unterstützt.
    7. Wählen Sie ein vorhandenes Datenbank-Home aus, oder erstellen Sie ein Datenbank-Home. Es wird empfohlen, für das Standbydatenbank-Home dasselbe Datenbanksoftwareimage der Primärdatenbank zu verwenden, damit für beide dieselben Patches verfügbar sind.
    8. Geben Sie das Kennwort für den SYS-Benutzer ein, und aktivieren Sie Oracle Data Guard.

    Nachdem Oracle Data Guard aktiviert wurde, wird die Standbydatenbank im Abschnitt "Data Guard-Verknüpfungen" aufgeführt.

  3. (Optional) Aktivieren Sie das automatische Failover (Fast-Start Failover), um die Recovery-Zeit bei Ausfällen zu verkürzen, indem Sie Data Guard Observer auf einer separaten VM installieren, vorzugsweise an einem separaten Speicherort oder im Anwendungsnetzwerk.

Mehr erfahren

Erfahren Sie mehr über die Features dieser Architektur und die zugehörigen Architekturen.

Bestätigungen

  • Autoren: Ricardo Anda, Srikanth Bolisetty, Julien Silverston, Andy Steinorth, Lingaraj Nayak
  • Beitragende: Tammy Bednar, Wei Han, Glen Hawkins, Gavin Parish, Sinan Petrus Toma, Lawrence To, Thomas Van Buggenhout, Robert Lies