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:

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

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

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

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

  • 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 Object Storage

    OCI Object Storage bietet Zugriff auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps, darunter Datenbankbackups, Analysedaten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher und sicher direkt aus Anwendungen oder aus der Cloud-Plattform speichern. Sie können den Storage 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.

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

  • Oracle Database Autonomous Recovery Service

    Oracle Database Autonomous Recovery Service ist ein vollständig verwalteter Service, der Oracle Databases vor Datenverlust und Cyberbedrohungen schützt. Es bietet schnellere Backups mit reduziertem Datenbankoverhead, zuverlässiger Wiederherstellung mit validierten Backups und Echtzeitschutz, der eine Wiederherstellung innerhalb von weniger als einer Sekunde nach einem Ausfall oder Ransomware-Angriff ermöglicht. Dieser Service bietet ein zentrales Datenschutz-Dashboard. Es wird empfohlen, Oracle Databases mit hoher Resilienz zu sichern.

  • Exadata Database Service

    Oracle Exadata ist eine Unternehmensdatenbankplattform, auf der Oracle Database-Workloads jeder Größenordnung und Kritikalität mit hoher Performance, Verfügbarkeit und Sicherheit ausgeführt werden. 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 Unternehmensrechenzentren, auf OCI und in Multicloud-Umgebungen können Unternehmen die betriebliche Effizienz steigern, die IT-Administration reduzieren und die 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 Oracle Database-Service (Oracle Exadata Database Service on Dedicated Infrastructure und Oracle Autonomous AI Database Serverless), der auf OCI ausgeführt wird und in Microsoft Azure-Rechenzentren 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 AI Database basiert auf der Oracle Exadata-Infrastruktur, ist selbstverwaltend, selbstsichernd und selbstreparierend und trägt dazu bei, manuelles Datenbankmanagement und menschliche Fehler zu vermeiden. Autonome KI-Datenbank ermöglicht die Entwicklung skalierbarer KI-gestützter Apps mit beliebigen Daten mithilfe integrierter KI-Funktionen, wobei Sie das Large Language Model (LLM) und den Bereitstellungsort Ihrer Wahl nutzen.

    Sowohl Oracle Exadata Database Service als auch Oracle Autonomous AI 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.

Bereitstellen

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 Primär-VCN des Hub-VCN Primär-VCN-Hub an das DRG an. Bearbeiten Sie die DRG-VCN-Anhänge, und bearbeiten Sie unter den erweiterten Optionen die Registerkarten-VCN-Routentabelle, um sie mit der Routentabelle primary_hub_transit_drg zu verknüpfen. Diese Konfiguration ermöglicht 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.

Bereitstellen

Führen Sie die folgenden Schritte aus, um den Code von GitHub herunterzuladen, den Code anzupassen und bereitzustellen:

  1. Gehen Sie zu GitHub.
  2. Klonen oder laden Sie das Repository herunter.
  3. Befolgen Sie die Anweisungen im README-Dokument.

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