Regionsübergreifendes Disaster Recovery für Oracle Exadata Database Service auf Oracle Database@Azure ausführen
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:
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, das als Availability-Domain bezeichnet wird. 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 sein muss.
- 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
Das Servicegateway ermöglicht den Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zum Oracle-Service durchläuft die Oracle-Netzwerkstruktur und nicht das Internet.
- Lokales Peering-Gateway (LPG)
Mit einem LPG können Sie ein VCN per Peering mit einem anderen VCN in derselben Region verbinden. Peering bedeutet, dass die VCNs über private IP-Adressen kommunizieren, ohne dass der Traffic über das Internet oder Routing über das On-Premise-Netzwerk geleitet wird.
- Netzwerksicherheitsgruppe (NSG)
Netzwerksicherheitsgruppe (NSG) fungiert als virtuelle Firewall für Ihre Cloud-Ressourcen. Mit dem Zero-Trust-Sicherheitsmodell von Oracle Cloud Infrastructure wird der gesamte Traffic abgelehnt, und Sie können den Netzwerktraffic in einem VCN kontrollieren. 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 Object Storage können Sie schnell auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps zugreifen, darunter Datenbankbackups, analytische Daten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher und geschützt speichern und dann direkt aus dem Internet oder aus der Cloud-Plattform abrufen. Sie können den Speicher skalieren, ohne die Performance oder Servicezuverlässigkeit zu beeinträchtigen. Verwenden Sie Standardspeicher für "Hot Storage", 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 möchten und auf den Sie nur selten zugreifen.
- Data Guard
Oracle Data Guard und Oracle Active Data Guard bieten ein umfassendes Set von Services, mit denen Sie eine oder mehrere Standbydatenbanken erstellen, verwalten und überwachen können und mit denen Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben können. Oracle Data Guard verwaltet diese Standbydatenbanken als Kopien der Produktionsdatenbank mit speicherresidenter Replikation. Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht mehr verfügbar ist, kann Oracle Data Guard jede Standbydatenbank auf die Produktionsrolle umstellen und die mit dem Ausfall verbundene Ausfallzeit minimieren. Oracle Active Data Guard bietet die zusätzliche Möglichkeit, Workloads mit Lesezugriff hauptsächlich auf Standbydatenbanken auszulagern. Außerdem bietet es erweiterte Datenschutzfunktionen.
- Oracle Database Autonomous Recovery Service
Mit Oracle Database Autonomous Recovery Service können Sie einen Point-in-Time Snapshot der Daten auf Block-Volumes, Boot-Volumes und in Oracle Databases erstellen. Mit Backupautomatisierung und erweiterten Datenschutzfunktionen für OCI-Datenbanken können Sie alle Backupverarbeitungs- und Speicheranforderungen an Oracle Database Autonomous Recovery Service auslagern, wodurch die Kosten für die Backupinfrastruktur und der manuelle Administrationsaufwand vermieden werden.
- 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.
Mit Oracle Exadata Database Service können Sie die Vorteile 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 und auf Cloud@Customer. 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 integriert Oracle-Technologien wie Oracle Exadata Database Service, Oracle Autonomous Database Serverless, Oracle Real Application Clusters (Oracle RAC) und Oracle Data Guard in die Microsoft Azure-Plattform.
Oracle Database@Azure ist der Oracle Database-Service, der auf Oracle Cloud Infrastructure (OCI) ausgeführt wird und in Microsoft Azure-Rechenzentren untergebracht ist. Der Service bietet Feature- und Preisparität mit OCI. Sie können den Service im Azure Marketplace erwerben. Oracle Database@Azure bietet dieselbe geringe Latenz wie andere Azure-native Services und erfüllt erfolgsrelevante Workload- und cloudnative Entwicklungsanforderungen. Sie können den Service über die Azure-Konsole und mit Azure-Automatisierungstools verwalten. Der Service wird im virtuellen Azure-Netzwerk (VNet) bereitgestellt und ist in das Identitäts- und Zugriffsmanagementsystem von Azure integriert. Die OCI- und Oracle Database-Metriken und -Auditlogs sind nativ in Azure verfügbar. Der Service erfordert, dass Benutzer einen Azure-Mandanten und einen OCI-Mandanten haben.
Empfehlungen
- 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
Wenn Sie ein regionsübergreifendes Disaster Recovery für Oracle Exadata Database Service auf Oracle Database@Azure ausführen, beachten Sie 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
- Erstellen Sie ein virtuelles Cloud-Netzwerk (VCN), HUB-VCN primär, in der primären Region von Oracle Cloud Infrastructure (OCI).
- 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.
- Richten Sie eine Peer-LPG-Verbindung zwischen den LPGs für HUB-VCN primär und VCN primär ein.
- Aktualisieren Sie im VCN VCN-Primär die Standardroutentabelle, um Traffic für die mit dem VCN-Standby-Clientsubnetz verknüpfte IP-Adresse zur Verwendung von LPG-Peering weiterzuleiten. Beispiel:
10.6.0.0/24 to Primary-LPGHinweis:
Um die Standardroutentabelle zu aktualisieren, müssen Sie derzeit ein Supportticket mit dem Titel Erforderliche Berechtigung zum Aktualisieren der VCN-Routentabelle erstellen und die Region, die Mandanten-OCID, die VCN-OCID und die Service-DRG-OCID angeben. - Erstellen Sie ein dynamisches Routinggateway (DRG), Primäres DRG im VCN mit dem primären Hub-VCN.
- 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 - Erstellen Sie im VCN HUB-VCN primär eine zweite Routentabelle, primary_hub_transit_lpg, und weisen Sie das Ziel des primären VCN-Clientsubnetzes, einen Zieltyp DRG und ein primäres DRG-Ziel zu. Beispiel:
10.6.0.0/24 target type: DRG, Target: Primary-DRG - Hängen Sie das VCN für das primäre Hub-VCN an das DRG an. Bearbeiten Sie die DRG-VCN-Anhänge, und bearbeiten Sie unter "Erweiterte Optionen" die VCN-Routentabelle der Registerkarte, um sie mit der Routentabelle primary_hub_transit_drg zu verknüpfen. Diese Konfiguration ermöglicht das Transitrouting.
- Verknüpfen Sie die Routentabelle primary_hub_transit_lpg mit dem Gateway Hub-Primary-LPG.
- 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 - Wählen Sie unter Primäres DRG die DRG-Routentabelle Automatisch generierte DRG-Routentabelle für RPC-, VC- und IPSec-Anhänge aus. Fügen Sie dem IP-Adressbereich des primären VCN-Subnetzclients eine statische Route hinzu, die das VCN primäres Hub-VCN mit dem nächsten Hop-Anhangstyp VCN und dem nächsten Hop-Anhangsnamen Primärer Hub-Anhang verwendet. Beispiel:
10.5.0.0/24 VCN Primary Hub attachment - Verwenden Sie das Menü "Anhänge für Primär-DRG-Remote-Peering-Verbindungen", um eine Remote-Peering-Verbindung zu erstellen, RPC.
- 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
- Erstellen Sie das VCN HUB-VCN-Standbydatenbank in der OCI-Standbydatenbankregion.
- Stellen Sie zwei LPGs, Standby-LPG und HUB-Standby-LPG, in den VCNs VCN-Standby und HUB-VCN-Standby bereit.
- Richten Sie eine Peer-LPG-Verbindung zwischen LPGs für die VCN-Standby und die HUB-VCN-Standby ein.
- Aktualisieren Sie im VCN-Standbydatenbank-VCN die Standardroutentabelle, um Traffic für die IP-Adresse weiterzuleiten, die mit dem VCN-Primärclientsubnetz verknüpft ist, um LPG-Peering zu verwenden. Beispiel:
10.5.0.0/24 to Standby-LPGHinweis:
Um die Standardroutentabelle zu aktualisieren, müssen Sie derzeit ein Supportticket mit dem Titel Erforderliche Berechtigung zum Aktualisieren der VCN-Routentabelle erstellen und die Region, die Mandanten-OCID, die VCN-OCID und die Service-DRG-OCID angeben. - Erstellen Sie ein DRG, Standby-DRG, im VCN der Hub-VCN-Standby.
- Erstellen Sie im VCN HUB-VCN-Standbydatenbank eine Routentabelle standby_hub_transit_lpg, und weisen Sie das Ziel des VCN-Standbydatenbank-Clientsubnetzes, den Zieltyp LPG und das Ziel-HUB-Standbydatenbank-LPG zu. Beispiel:
10.6.0.0/24 target type: LPG, Target: Hub-Standby-LPG - Erstellen Sie im VCN HUB-VCN-Standbydatenbank eine zweite Routentabelle standby_hub_transit_drg, und weisen Sie das Ziel des VCN-Standbydatenbank-Clientsubnetzes, ein Zieltyp-DRG und ein Standbydatenbank-DRG-Ziel zu. Beispiel:
10.5.0.0/24 target type: DRG, Target: Standby-DRG - Hängen Sie das VCN für die Hub-VCN-Standby 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.
- Fügen Sie 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 das DRG zu verwenden. Beispiel:
10.6.0.0/24 LPG Hub-Standby-LPG 10.5.0.0/24 DRG Standby-DRG - Verknüpfen Sie die Routentabelle standby_hub_transit_lpg mit dem Gateway Hub-Standby-LPG.
- 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 dem IP-Adressbereich des VCN-Standby-Subnetzclients eine statische Route hinzu, die das VCN Hub-VCN-Standby mit dem Anhangstyp "VCN" und dem Namen des nächsten Hop-Anhangs Standby-Hub-Anhang verwendet. Beispiel:
10.6.0.0/24 VCN Standby Hub attachment - Verwenden Sie das Menü "Anhänge für Standby-DRG-Remote-Peering-Verbindungen", um eine Remote-Peering-Verbindung, RPC, zu erstellen.
- 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.
- 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
- 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.
- Auf der Seite "Data Guard aktivieren":
- Wählen Sie die Standby-Region.
- Wählen Sie die Standby-Availability-Domain aus, die Azure AZ zugeordnet ist.
- Wählen Sie die Standby-Exadata-Infrastruktur aus.
- Wählen Sie das gewünschte Standby-VM-Cluster aus.
- 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.
- Bei regionsübergreifenden Oracle Data Guard-Verbindungen wird nur der Schutzmodus für maximale Performance unterstützt.
- 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.
- 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.
- (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.