Disaster Recovery mit regionsübergreifender Standbydatenbank auf Oracle Database@Azure implementieren

Disaster Recovery mit regionsübergreifender Standbydatenbank in Oracle Database@Azure implementieren

Die Gewährleistung einer unterbrechungsfreien Geschäftskontinuität ist für den Erfolg beim Entwerfen von Anwendungen von entscheidender Bedeutung. Um dies zu erreichen, ist eine robuste Disaster Recovery-Strategie erforderlich, mit der die Funktionalität bei Störungen schnell wiederhergestellt werden kann.

Seit Jahren verlassen sich Unternehmen auf Oracle Exadata Database Service, den führenden Disaster Recovery-Technologien von Oracle, um geschäftskritische Anwendungen zu unterstützen, sei es On-Premises oder innerhalb von Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Dedicated Infrastructure auf Oracle Database@Azure bietet die gleiche branchenführende Performance, dasselbe Featureset und dieselbe Preisparität wie Exadata auf OCI. Es nutzt die Verfügbarkeitszonen (AZs) und Regionen von Microsoft Azure, um den Anwendungen von Azure eine geringe Latenz zusätzlich zu unübertroffenen High Availability- und Disaster Recovery-Funktionen zu bieten und so einen nahtlosen Betrieb während der Wartung und im Falle einer Unterbrechung sicherzustellen.

Architektur

Diese Architektur zeigt Oracle Exadata Database Service on Dedicated Infrastructure auf Oracle Database@Azure in einer Disaster-Recovery-Topologie mit mehreren Regionen mit zwei Remotestandbydatenbanken an.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

Beschreibung von multi-region-standby-dr-db-azure-arch.png folgt

Beschreibung der Abbildung multi-region-standby-dr-db-azure-arch.png

Multi-Region-Standby-dr-db-azure-arch-oracle.zip

Die Oracle Database wird in einem Exadata-VM-Cluster in der Region "Primär" ausgeführt. Für Datenschutz und Disaster Recovery repliziert Oracle Active Data Guard die Daten in zwei Standbydatenbanken, die auf Exadata-VM-Clustern in zwei verschiedenen Standbyregionen ausgeführt werden. Ein Setup einer Remotestandbydatenbank stellt den Datenschutz vor regionalen Ausfällen sicher und kann auch zum Auslagern der schreibgeschützten Abfrageverarbeitung verwendet werden. Replizieren Sie die Anwendung regionsübergreifend, um eine höhere Latenz nach dem Wechsel zu einer Standbydatenbank zu vermeiden.

Sie können den Active Data Guard-Traffic über das Azure-Netzwerk weiterleiten. Diese Architektur konzentriert sich jedoch auf den Active Data Guard-Netzwerktraffic über das OCI-Netzwerk, um den Netzwerkdurchsatz und die Latenz zu optimieren.

Das Oracle Exadata Database Service on Dedicated Infrastructure im Oracle Database@Azure-Netzwerk ist mit einem von Oracle verwalteten dynamischen Routinggateway (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, das als Hub-VCN mit eigenem DRG fungiert, erforderlich, um die primären und Standby-VCNs in jeder Region zu verbinden. In dieser Architektur:

Das primäre Exadata-VM-Cluster wird in Region 1 in VCN1 mit CIDR 10.10.0.0/16 bereitgestellt.
Das Hub-VCN in der primären Region 1 ist HubVCN1 mit CIDR 10.11.0.0/16.
Das erste Standby-Exadata-VM-Cluster wird in Region 2 in VCN2 mit CIDR 10.20.0.0/16 bereitgestellt.
Das Hub-VCN in der ersten Standbyregion ist HubVCN2 mit CIDR 10.22.0.0/16.
Das zweite Standby-Exadata-VM-Cluster wird in Region 3 in VCN3 mit CIDR 10.30.0.0/16 bereitgestellt.
Das Hub-VCN in der zweiten Standbyregion ist HubVCN3 mit CIDR 10.33.0.0/16.

Für die Hub-VCNs ist kein Subnetz erforderlich, um das Transitrouting zu aktivieren. Daher können diese VCNs sehr kleine IP-CIDR-Bereiche verwenden. Die VCNs auf der untergeordneten OCI-Site werden erstellt, nachdem die Oracle Exadata Database Service on Dedicated Infrastructure-VM-Cluster auf Oracle Database@Azure für die Primär- und Standbydatenbank erstellt wurden.

Microsoft Azure stellt die folgenden Komponenten bereit:

Azure-Region
Eine Azure-Region ist ein geografisches Gebiet, in dem sich mindestens ein physisches Azure-Data Center, sogenannte Verfügbarkeitszonen, 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 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.
Azure-Verfügbarkeitszone
Azure-Verfügbarkeitszonen sind physisch separate Standorte innerhalb einer Azure-Region, die durch unabhängige Stromversorgung, Kühlung und Vernetzung eine hohe Verfügbarkeit und Resilienz gewährleisten.
Virtuelles Azure-Netzwerk (VNet)
Azure Virtual Network (VNet) ist der grundlegende Baustein für Ihr privates Netzwerk in Azure. Mit VNet können viele Arten von Azure-Ressourcen wie virtuelle Azure-Maschinen (VMs) sicher miteinander, mit dem Internet und On-Premises-Netzwerken kommunizieren.
Delegiertes Azure-Subnetz
Mit einem delegierten Subnetz können Sie einen verwalteten Service, insbesondere einen Platform-as-a-Service-(PaaS-)Service, direkt als Ressource in Ihr virtuelles Netzwerk einfügen. Sie verfügen über ein vollständiges Integrationsmanagement externer PaaS-Services in Ihren virtuellen Netzwerken.
Azure Virtual Network Interface Card (VNIC)
Die Dienste in Azure-Rechenzentren verfügen über physische Netzwerkkarten (NICs). Virtual-Machine-Instanzen 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.

OCI 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-Domains
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. Ein Fehler in einer Availability-Domain sollte sich also nicht auf die anderen Availability-Domains in der Region auswirken.
Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. 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 an Ziele außerhalb eines VCN, in der Regel über Gateways.
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.
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, z.B. ein VCN in einer anderen Oracle Cloud Infrastructure-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.
Objektspeicher
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 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. 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 das Disaster Recovery für Oracle Exadata Database Service on Dedicated Infrastructure auf Oracle Database@Azure. 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 und Auslagern der Workload in die Standbydatenbank mit vorwiegend horizontalem Lesezugriff.
Aktivieren Sie Application Continuity, um Datenbankausfälle bei geplanten und ungeplanten Ereignissen von Endbenutzern zu maskieren und unterbrechungsfreie Anwendungen sicherzustellen.
Richten Sie automatische Backups in Oracle Database Autonomous Recovery Service (in Azure oder 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 unbegrenzte Backups implementieren, die wöchentliche vollständige Backups eliminiert. Alternativ können Kunden OCI Object Storage für automatische Backups verwenden.
Aktivieren Sie Backups aus der Standbydatenbank, um eine regionsübergreifende Backupreplikation zu erreichen.
Mit OCI Full Stack DR können Sie Datenbank-Switchover- und Failover-Vorgänge orchestrieren.
Mit OCI Vault können Sie die Transparenten Datenverschlüsselungs-(TDE-)schlüssel der Datenbank mit vom Kunden verwalteten Schlüsseln speichern.

Hinweise

Beachten Sie Folgendes, wenn Sie ein mehrregionales Disaster Recovery für Oracle Exadata Database Service on Dedicated Infrastructure in Oracle Database@Azure ausführen.

Wenn Exadata-VM-Cluster auf der untergeordneten Site von Oracle Database@Azure erstellt werden, wird jedes VM-Cluster in seinem eigenen OCI-VCN erstellt. Oracle Data Guard erfordert, dass die Datenbanken miteinander kommunizieren, um redo-Daten zu versenden. Peeren Sie die VCNs, um diese Kommunikation zu aktivieren. Daher dürfen die Exadata-VM-Cluster-VCNs keine sich überschneidenden IP-CIDR-Bereiche gemeinsam verwenden.
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 und Disaster Recovery-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 ein einfaches, aber effektives Failover für die Disaster-Recovery-Konfiguration in Ihren OCI- und Microsoft Azure-Umgebungen verwenden.
OCI ist das bevorzugte Netzwerk, um eine bessere Performance zu erzielen, gemessen an Latenz und Durchsatz, und um reduzierte Kosten zu erreichen, einschließlich des kostenlosen ersten 10 TB/Monat-Egress.
Mit Cloud Tooling können Sie bis zu sechs Standbydatenbanken für eine Primärdatenbank erstellen.
Das Erstellen einer Standbydatenbank, die mit einer anderen Standbydatenbank verknüpft ist (kaskadierende Standbydatenbank), wird mit Cloud Tooling nicht unterstützt.

Stellen Sie

Führen Sie die folgenden Schritte aus, um die Netzwerkkommunikation zwischen Regionen im Architekturdiagramm zu konfigurieren:

So konfigurieren Sie die primäre Region:

Fügen Sie die folgenden Ingress-Regeln zur Sicherheitsliste des Clientsubnetzes von VCN1 hinzu, um eingehenden Traffic von VCN2 und VCN3 zuzulassen.

Zustandslos	Quelle	IP-Protokoll	Quellportbereich	Zielportbereich	Lässt Folgendes zu	Beschreibung
Nr.	`10.20.0.0/16`	TCP	1521	1521	TCP-Traffic für folgende Ports: 1521	Ingress von `VCN2` zulassen
Nr.	`10.30.0.0/16`	TCP	1521	1521	TCP-Traffic für folgende Ports: 1521	Ingress von `VCN3` zulassen

Erstellen Sie das virtuelle Cloud-Netzwerk HubVCN1 mit CIDR 10.11.0.0/16.
Erstellen Sie das lokale Peering-Gateway HubLPG1 im virtuellen Cloud-Netzwerk HubVCN1.
Erstellen Sie das lokale Peering-Gateway LPG1R im virtuellen Cloud-Netzwerk VCN1.
Richten Sie die lokale Peering-Verbindung zwischen LPG1R und HubLPG1 ein.

Fügen Sie Routingregeln zur Routentabelle des Clientsubnetzes von VCN1 hinzu, um Traffic, der für VCN2 und VCN3 bestimmt ist, an LPG1R weiterzuleiten.

Ziel	Zieltyp	Target	Routentyp	Beschreibung
`10.20.0.0/16`	Lokales Peering-Gateway	`LPG1R`	Statisch	Traffic zu `VCN2`
`10.30.0.0/16`	Lokales Peering-Gateway	`LPG1R`	Statisch	Traffic zu `VCN3`

Erstellen Sie die Routentabelle HubLPG1rt in HubVCN1.
Ordnen Sie die Routentabelle HubLPG1rt dem lokalen Peering-Gateway HubLPG1 zu.
Erstellen Sie das dynamische Routinggateway DRG1.
Erstellen Sie die Routentabelle DRG1rt in HubVCN1.

Fügen Sie der Routentabelle DRG1rt eine Routingregel hinzu, um Traffic, der für VCN1 als Ziel bestimmt ist, an HubLPG1 weiterzuleiten.

Ziel	Zieltyp	Target	Routentyp	Beschreibung
`10.10.0.0/16`	Lokales Peering-Gateway	`HubLPG1`	Statisch	Traffic zu `VCN1`

So hängen Sie DRG1 an HubVCN1 an:
1. Wählen Sie Automatisch generierte Drg-Routentabelle für VCN-Anhänge aus.
2. Wählen Sie die vorhandene Routentabelle DRG1rt aus.
3. Wählen Sie VCN-CIDR-Blöcke aus.
Erstellen Sie zwei Remote-Peering-Verbindungen in DRG1 mit den Namen RPC1a und RPC1b.

Fügen Sie zwei Routingregeln zu HubLPG1rt hinzu, um Traffic, der für VCN2 und VCN3 bestimmt ist, an DRG1 weiterzuleiten.

Ziel	Zieltyp	Target	Routentyp	Beschreibung
`10.20.0.0/16`	Dynamisches Routinggateway	`DRG1`	Statisch	Traffic zu `VCN2`
`10.30.0.0/16`	Dynamisches Routinggateway	`DRG1`	Statisch	Traffic zu `VCN3`

So erstellen Sie die erste Standbyregion (Region 2):

Fügen Sie die folgenden Ingress-Regeln zur Sicherheitsliste des Clientsubnetzes von VCN2 hinzu, um eingehenden Traffic von VCN1 und VCN3 zuzulassen.

Zustandslos	Quelle	IP-Protokoll	Quellportbereich	Zielportbereich	Lässt Folgendes zu	Beschreibung
Nr.	`10.10.0.0/16`	TCP	1521	1521	TCP-Traffic für folgende Ports: 1521	Ingress von `VCN1` zulassen
Nr.	`10.30.0.0/16`	TCP	1521	1521	TCP-Traffic für folgende Ports: 1521	Ingress von `VCN3` zulassen

Erstellen Sie das virtuelle Cloud-Netzwerk HubVCN2 mit CIDR 10.22.0.0/16.
Erstellen Sie das lokale Peering-Gateway HubLPG2 im virtuellen Cloud-Netzwerk HubVCN2.
Erstellen Sie das lokale Peering-Gateway LPG2R im virtuellen Cloud-Netzwerk VCN2.
Richten Sie die lokale Peering-Verbindung zwischen LPG2R und HubLPG2 ein.

Fügen Sie Routingregeln zur Routentabelle des Clientsubnetzes von VCN2 hinzu, um Traffic, der für VCN1 und VCN3 bestimmt ist, an LPG2R weiterzuleiten.

Ziel	Zieltyp	Target	Routentyp	Beschreibung
`10.10.0.0/16`	Lokales Peering-Gateway	`LPG2R`	Statisch	Traffic zu `VCN1`
`10.30.0.0/16`	Lokales Peering-Gateway	`LPG2R`	Statisch	Traffic zu `VCN3`

Erstellen Sie die Routentabelle HubLPG2rt in HubVCN2.
Ordnen Sie die Routentabelle HubLPG2rt dem lokalen Peering-Gateway HubLPG2 zu.
Erstellen Sie das dynamische Routinggateway DRG2.
Erstellen Sie die Routentabelle DRG2rt in HubVCN2.

Fügen Sie eine Routingregel zu DRG2rt hinzu, um Traffic, der für VCN2 als Ziel bestimmt ist, an HubLPG2 weiterzuleiten.

Ziel	Zieltyp	Target	Routentyp	Beschreibung
`10.20.0.0/16`	Lokales Peering-Gateway	`HubLPG2`	Statisch	Traffic zu `VCN2`

So hängen Sie DRG1 an HubVCN2 an:
1. Wählen Sie Automatisch generierte Drg-Routentabelle für VCN-Anhänge aus.
2. Wählen Sie die vorhandene Routentabelle DRG2rt aus.
3. Wählen Sie VCN-CIDR-Blöcke aus.
Erstellen Sie zwei Remote-Peering-Verbindungen in DRG2 mit den Namen RPC2a und RPC2c.
Richten Sie eine Remote-Peering-Verbindung zwischen RPC1a (Region 1) und RPC2a (Region 2) ein.

Fügen Sie zwei Routingregeln zu HubLPG2rt hinzu, um Traffic, der für VCN1 und VCN3 bestimmt ist, an DRG2 weiterzuleiten.

Ziel	Zieltyp	Target	Routentyp	Beschreibung
`10.10.0.0/16`	Dynamisches Routinggateway	`DRG2`	Statisch	Traffic zu `VCN1`
`10.30.0.0/16`	Dynamisches Routinggateway	`DRG2`	Statisch	Traffic zu `VCN3`

So erstellen Sie die zweite Standbyregion (Region 3):

Fügen Sie die folgenden Ingress-Regeln zur Sicherheitsliste des Clientsubnetzes von VCN3 hinzu, um eingehenden Traffic von VCN1 und VCN2 zuzulassen.

Zustandslos	Quelle	IP-Protokoll	Quellportbereich	Zielportbereich	Lässt Folgendes zu	Beschreibung
Nr.	10.10.0.0/16	TCP	1521	1521	TCP-Traffic für folgende Ports: 1521	Ingress von VCN1 zulassen
Nr.	10.20.0.0/16	TCP	1521	1521	TCP-Traffic für folgende Ports: 1521	Ingress von VCN2 zulassen

Erstellen Sie das virtuelle Cloud-Netzwerk HubVCN3 mit CIDR 10.33.0.0/16.
Erstellen Sie das lokale Peering-Gateway HubLPG3 im virtuellen Cloud-Netzwerk HubVCN3.
Erstellen Sie das lokale Peering-Gateway LPG3R im virtuellen Cloud-Netzwerk VCN3.
Richten Sie die lokale Peering-Verbindung zwischen LPG3R und HubLPG3 ein.

Fügen Sie Routingregeln zur Routentabelle des Clientsubnetzes von VCN3 hinzu, um Traffic, der für VCN1 und VCN2 bestimmt ist, an LPG3R weiterzuleiten.

Ziel	Zieltyp	Target	Routentyp	Beschreibung
`10.10.0.0/16`	Lokales Peering-Gateway	`LPG3R`	Statisch	Traffic zu `VCN1`
`10.20.0.0/16`	Lokales Peering-Gateway	`LPG3R`	Statisch	Traffic zu `VCN2`

Erstellen Sie die Routentabelle HubLPG3rt in HubVCN3.
Ordnen Sie die Routentabelle HubLPG3rt dem lokalen Peering-Gateway HubLPG3 zu.
Erstellen Sie das dynamische Routinggateway DRG3.
Erstellen Sie die Routentabelle DRG3rt in HubVCN3.

Fügen Sie eine Routingregel zu DRG3rt hinzu, um Traffic, der für VCN3 als Ziel bestimmt ist, an HubLPG3 weiterzuleiten.

Ziel	Zieltyp	Target	Routentyp	Beschreibung
`10.30.0.0/16`	Lokales Peering-Gateway	`HubLPG3`	Statisch	Traffic zu `VCN3`

So hängen Sie DRG1 an HubVCN3 an:
1. Wählen Sie Automatisch generierte Drg-Routentabelle für VCN-Anhänge aus.
2. Wählen Sie die vorhandene Routentabelle DRG3rt aus.
3. Wählen Sie VCN-CIDR-Blöcke aus.
Erstellen Sie zwei Remote-Peering-Verbindungen in DRG3 mit den Namen RPC3b und RPC3c.
Richten Sie eine Remote-Peering-Verbindung zwischen RPC1b (Region 1) und RPC3b (Region 3) ein.
Richten Sie eine Remote-Peering-Verbindung zwischen RPC2c (Region 2) und RPC3c (Region 3) ein.

Fügen Sie zwei Routingregeln zu HubLPG3rt hinzu, um Traffic, der für VCN1 und VCN2 bestimmt ist, an DRG3 weiterzuleiten.

Ziel	Zieltyp	Target	Routentyp	Beschreibung
`10.10.0.0/16`	Dynamisches Routinggateway	`DRG3`	Statisch	Traffic zu `VCN1`
`10.20.0.0/16`	Dynamisches Routinggateway	`DRG3`	Statisch	Traffic zu `VCN2`

Mehr erfahren

Weitere Informationen zu Oracle Database@Azure und Oracle Data Guard.

Prüfen Sie diese zusätzlichen Ressourcen:

Danksagungen

Autoren: Sinan Petrus Toma, Sebastian Solbach, Julien Silverston
Beitragender: Sreya Dutta