Erfahren Sie mehr über das Deployment von Active Data Guard Far Sync
Mit Oracle Database@Azure können Sie Ihre geschäftskritischen Oracle-Datenbanken mit Oracle Exadata Database Service on Dedicated Infrastructure im Data Center von Microsoft Azure ausführen.
Profitieren Sie von der integrierten High Availability, Performance und Skalierbarkeit von Oracle Exadata Database Service und Oracle Real Application Clusters (Oracle RAC), während Sie von einer geringen Latenz für Azure-Anwendungen profitieren.
Die Erweiterung der Architektur um eine Standbydatenbank, die auf einem anderen Exadata-VM-Cluster gehostet wird, bietet Disaster Recovery-(DR-)Schutz vor Datenbank- und Clusterausfällen. Wenn Sie die Standbydatenbank in einer anderen Azure-Verfügbarkeitszone (AZ) platzieren, wird die Lösung weiter verbessert und der Schutz vor einem gesamten AZ-Ausfall sichergestellt. Für ein umfassendes regionales Disaster Recovery muss die Standbydatenbank in einer separaten Region bereitgestellt werden.
Mit Oracle Data Guard können Sie das Redo synchron zur Standbydatenbank übertragen, um einen Datenverlust zu vermeiden. Wenn die Standbydatenbank jedoch geografisch zu weit ist, erhöht sich die Latenz, was sich auf die Commit-Antwortzeit und den Transaktionsdurchsatz in der Primärdatenbank auswirkt. Mit Active Data Guard Far Sync können Datenverluste in beliebiger Entfernung mit minimalen Auswirkungen auf die Performance der Primärdatenbank vermieden werden. Far Sync, eine Lightweight-Instanz, bietet synchronen Redo-Schutz und Failover ohne Datenverlust, ohne dass eine synchrone lokale Standbydatenbank erforderlich ist.
Architektur
Diese Referenzarchitektur zeigt ein regionsübergreifendes Disaster Recovery mit Active Data Guard an.
Zwei Active Data Guard-Far Sync-Instanzen werden in den entsprechenden Oracle Cloud Infrastructure-(OCI-)Regionen erstellt. Die Primärdatenbank in Toronto sendet die Redo-Daten im SYNC-Modus an die lokale Far SYNC-Instanz in Toronto. Diese leitet die Redo-Daten im ASYNC-Modus an die Standbydatenbank in der Remote-Region Sydney weiter.
Nachdem ein Rollenwechsel erfolgt und die Datenbank in Sydney zur primären Datenbank wird, sendet sie die Redo-Daten im SYNC-Modus an ihre lokale Far SYNC-Instanz in Sydney, die Redo-Daten im ASYNC-Modus an die Standbydatenbank in der Remote-Region Toronto weiterleitet.
Das Oracle Exadata Database Service im Oracle Database@Azure-Netzwerk ist mit dem Exadata-Clientsubnetz über ein von Oracle verwaltetes dynamisches Routinggateway (DRG) 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 einem eigenen DRG erforderlich, um die primären und Standby-VCNs in jeder Region zu verbinden.
Die Anwendung wird regionsübergreifend repliziert, um auf die Datenbank in derselben Region zuzugreifen und die geringste Latenz und höchste Performance zu erreichen.
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.
active-data-guard-far-sync-dba-oracle.zip
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 VNet
Microsoft 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 (VM) sicher miteinander, mit dem Internet und On-Premises-Netzwerken kommunizieren.
- Delegiertes Azure-Subnetz
Die Subnetzdelegierung ist die Fähigkeit von Microsoft, einen verwalteten Service, insbesondere einen Platform-as-a-Service-(PaaS-)Service, direkt in Ihr virtuelles Netzwerk zu injizieren. Auf diese Weise können Sie ein Subnetz als Home für einen externen verwalteten Service in Ihrem virtuellen Netzwerk festlegen oder delegieren, sodass der externe Service als virtuelle Netzwerkressource fungiert, obwohl es sich um einen externen PaaS-Service handelt.
- Azure-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.
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).
- Virtuelles Cloud-Netzwerk (VCN) und Subnetz
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.
- Sicherheitsliste
Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der im Subnetz und aus dem Subnetz zugelassen werden 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, z.B. ein VCN in einer anderen Oracle Cloud Infrastructure-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.
- Lokales Peering-Gateway (LPG)
Mit einem LPG 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.
- 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.
- Active Data Guard-Far Sync
Oracle Active Data Guard Far Sync ist eine ressourcensparende Oracle-Datenbankinstanz, die Redo-Daten synchron von der Primärdatenbank empfängt und asynchron an eine oder mehrere Standbydatenbanken weiterleitet. Es stellt keinen Datenverlust in beliebiger Entfernung sicher, mit minimalen Auswirkungen auf die Performance der Primärdatenbank und ohne dass eine lokale synchrone Standbydatenbank erforderlich ist.
- 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
- Die Far Sync-Instanz sollte weit genug von der Primärdatenbank entfernt sein, um sicherzustellen, dass sie nicht von demselben Fehler oder Disaster betroffen sein kann, aber nahe genug sein, um die Netzwerklatenz zu minimieren.
- Erstellen Sie zwei Far Sync-Instanzen pro Region für High Availability. Ohne eine alternative Far Sync-Instanz oder wenn alle Far Sync-Instanzen in der primären Region nicht verfügbar sind, wird der Oracle Data Guard-Redo-Transport direkt im ASYNC-Modus an die Standbydatenbank gesendet, was sich auf den Schutz vor Datenverlust ohne Auswirkungen auswirkt. Je nach Konfiguration und Entfernung kann dies zu einem Transportverzögerungsfehler führen, der sich weiter auf RPO auswirkt.
- Da die Speicherperformance der Far Sync-Instanz von entscheidender Bedeutung ist, muss die IOPS-Kapazität ausreichend sein, um die Workload zu unterstützen. Der Speicher der Far Sync-Instanz muss eine IOPS-Performance aufweisen, die dem Online-Redo-Logspeicher der Primärdatenbank entspricht oder höher ist.
- Verwenden Sie Oracle Data Guard regionsübergreifend für die Datenbanken, die im Exadata-VM-Cluster auf Oracle Database@Azure bereitgestellt sind, mit einem von OCI verwalteten Netzwerk.
Überlegungen zu regionsübergreifendem Disaster Recovery
Beachten Sie Folgendes, wenn Sie ein regionsübergreifendes Disaster Recovery für Oracle Exadata Database Service auf Oracle Database@Azure ausführen.
- Oracle Cloud Infrastructure ist das bevorzugte Netzwerk, um eine bessere Performance zu erzielen, gemessen an Latenz und Durchsatz, und um Kosten zu senken, da die ersten 10 TB/Monat kostenlos sind.
- Far Sync ist eine Lightweight-Instanz. Die Datenträgerperformance ist jedoch von entscheidender Bedeutung, da die Far Sync das empfangene Redo auf den Datenträger schreibt, bevor die Bestätigung an die Primärdatenbank zurückgegeben wird. Dies kann sich auf die Anwendungsperformance auswirken.
- Die Netzwerkperformance der Far Sync-Instanz ist für hohe Workloads von entscheidender Bedeutung.
- Bei mehreren Standbydatenbanken und Far Sync-Instanzen kann die Konfiguration komplizierter werden. Verwenden Sie die Eigenschaft RedoRoutes des Active Data Guard-Brokers, um die Definition des Redo-Transports zu den verschiedenen Zielen zu vereinfachen.
- Für die Verwendung der Far Sync ist die Option Active Data Guard erforderlich.