Informationen zum Fast-Start Failover von Oracle Data Guard

Oracle AI Database@Azure ermöglicht geschäftskritische Oracle AI Database-Workloads in Azure-Rechenzentren mit Oracle Exadata Database Service on Exascale Infrastructure und Oracle Exadata Database Service on Dedicated Infrastructure.

Sie erhalten integrierte High Availability, Performance und Skalierbarkeit von Oracle Exadata Database Machine und Oracle Real Application Clusters (Oracle RAC) mit geringer Latenz für Azure-basierte Anwendungen.

Die Erweiterung der Lösung um eine Standbydatenbank in einer anderen Availability Zone oder Region bietet Datenschutz und Disaster Recovery für Data Center- und regionale Ausfälle.

Data Guard transportiert Daten synchron zur Standbydatenbank, um einen Datenverlust zu vermeiden. Mit Fast-Start Failover kann der Broker automatisch ein Failover der Standby-Zieldatenbank zur Primärrolle ohne manuelle Failover-Schritte ausführen.

Observer Sites überwachen die Fast-Start Failover-Umgebung. Ein Observer ist eine separate clientseitige Komponente, die auf einer anderen Compute-VM als die Primär- und Standbydatenbank ausgeführt wird und die Verfügbarkeit der Primärdatenbank überwacht.

Fast-Start Failover ermöglicht ein schnelleres Failover mit einem konfigurierbaren Recovery Time Objective (RTO), bei dem entweder kein Datenverlust im synchronen Modus oder ein gebundenes Recovery Point Objective (RPO) im asynchronen Modus auftreten.

In diesem Lösungs-Playbook erfahren Sie, wie Sie Data Guard konfigurieren und bereitstellen und ein Fast-Start Failover in Oracle AI Database@Azure-Verfügbarkeitszonen mit Oracle Exadata Database Service on Exascale Infrastructure aktivieren. Dieselbe Lösung gilt für Oracle Exadata Database Service on Dedicated Infrastructure.

Bevor Sie beginnen

Bestätigen Sie die Voraussetzungen, und prüfen Sie Referenzen, bevor Sie Data Guard und Fast-Start Failover konfigurieren.

Stellen Sie Folgendes sicher, bevor Sie beginnen.

• Die Exascale-VM-Cluster werden in verschiedenen Azure-Verfügbarkeitszonen bereitgestellt.
• Oracle AI Database 26ai wird in der primären Availability-Zone erstellt.
• Die Netzwerk-IP-CIDR-Bereiche für die primären und Standby-Exascale-VM-Cluster überschneiden sich nicht.

Prüfen Sie die folgenden Lösungen:

• Oracle Exadata Database Service auf Exascale-Infrastruktur
• Oracle AI Database@Azure

Als Nächstes müssen Sie eine Compute-VM in Azure bereitstellen, um den Observer zu hosten, vorzugsweise in einer anderen Verfügbarkeitszone als die Primär- und Standbydatenbank. Der Observer kann auf einer Lightweight-VM ausgeführt werden, da er als Oracle-Client eine Verbindung zu der Primär- und Standbydatenbank herstellt.

Architektur

Die Oracle AI Database wird in einem Exascale-VM-Cluster in der primären Availability-Zone ausgeführt. Zum Datenschutz repliziert Data Guard die Daten in einer anderen Verfügbarkeitszone (lokale Standbydatenbank) in derselben Region.

Die folgende Architektur zeigt einen zonenübergreifenden Data Guard, bei dem der Observer in einer anderen Verfügbarkeitszone ausgeführt wird:

Beschreibung der Abbildung cross-zones-dg-oracledb-azure.png

cross-zones-dg-oracledb-azure-oracle.zip

Sie können Data Guard-Traffic über das Oracle Cloud Infrastructure-(OCI-) oder Azure-Netzwerk weiterleiten. Diese Architektur leitet den Data Guard-Netzwerktraffic über das Azure-Netzwerk weiter, um alle Daten innerhalb der Azure-Plattform zu speichern. Die VCNs auf der OCI-Site werden erstellt, nachdem die Oracle Exadata Database Service on Exascale Infrastructure-VM-Cluster auf Oracle AI Database@Azure für die Primär- und die Standbydatenbank erstellt wurden.

In dieser Architektur:

• Das primäre Exascale-VM-Cluster wird in der primären Availability-Zone in VNet1 mit CIDR 10.10.0.0/16 und dem delegierten Subnetz-CIDR 10.10.1.0/24 bereitgestellt.
• Das Standby-Exascale-VM-Cluster wird in der Standbyverfügbarkeitszone in VNet2 mit CIDR 10.20.0.0/16 und dem delegierten Subnetz-CIDR 10.20.1.0/24 bereitgestellt.
• Der Observer wird in VNet3 mit CIDR 10.30.0.0/16 und Subnetz-CIDR 10.30.1.0/24 bereitgestellt.
• VNet1 wird mit VNet2 per Peering versehen, damit Data Guard-Traffic zwischen der Primär- und der Standbydatenbank fließen kann.
• VNet3 wird mit VNet1 und VNet2 per Peering verbunden, damit Observer eine Verbindung zu beiden Datenbanken herstellen kann.

Diese Architektur umfasst die folgenden Komponenten:

• Region Azure

  Eine Azure-Region ist ein geografischer Bereich, in dem sich mindestens ein physisches Azure-Data Center, die sogenannten Availability Zones, befindet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.

  Azure- und OCI-Regionen sind lokalisierte geografische Gebiete. Für Oracle AI 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-Availability-Domain

  Die Azure-Availability-Domain oder das Verfügbarkeitsset ist eine logische Gruppierung virtueller Maschinen.

• Virtuelles Azure-Netzwerk und Subnetz

  Mit dem virtuellen Azure-Netzwerk (VNet) können Sie Azure-Ressourcen in einem privaten, logisch isolierten Netzwerk bereitstellen, das Sie definieren. Dieses Netzwerk ähnelt einem herkömmlichen On-Premises-Netzwerk und profitiert gleichzeitig von der skalierbaren, hochverfügbaren Cloud-Infrastruktur von Azure. Nachdem Sie ein VNet erstellt haben, können Sie es in ein oder mehrere Subnetze segmentieren, um den Netzwerkverkehr für Ihre Workloads zu organisieren und zu steuern.

• Delegiertes Azure-Subnetz

  Ein delegiertes Subnetz ist ein VNet-Subnetz, das reserviert und an den Oracle AI Database@Azure-Service delegiert wird. Dadurch kann Oracle die erforderlichen Datenbankressourcen in Ihrem privaten Netzwerk-IP-Bereich bereitstellen und verwalten.

• Azure Virtual Network-Schnittstellenkarte (VNIC)

  Die Dienste in Azure-Rechenzentren verfügen über physische Netzwerkkarten (NICs). Virtual-Machine-Instanzen kommunizieren mit virtuellen 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 Laufzeit der Instanz verfügbar ist.

• Microsoft Azure-Compute-VM

  Virtuelle Azure-Maschinen (VMs) bieten skalierbare On-Demand-Compute-Ressourcen, die Sie wie ein physischer Server oder Desktop verwenden können. Verwenden Sie VMs, wenn Sie vollständige Kontrolle über das Betriebssystem und die Softwareumgebung benötigen.

  VMs müssen keine physische Hardware verwalten, aber Sie konfigurieren, patchen und verwalten weiterhin die auf ihnen ausgeführte Software. Sie unterstützen benutzerdefinierte und Legacy-Workloads.

• 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. Ein Fehler in einer Availability-Domain sollte sich also nicht auf die anderen Availability-Domains in der Region auswirken.

• Virtuelles OCI-Cloud-Netzwerk und Subnetz

  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.

• Netzwerksicherheitsgruppe (NSG)

  NSGs fungieren als virtuelle Firewalls für Ihre Cloud-Ressourcen. Mit dem Zero-Trust-Sicherheitsmodell von OCI steuern Sie den Netzwerktraffic 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.

• 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. Außerdem bietet es erweiterte Datenschutzfunktionen.

• Oracle AI Database@Azure

  Oracle AI 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 AI Database@Azure integriert Oracle Exadata Database Service-, Oracle Real Application Clusters (Oracle RAC)- und Oracle Data Guard-Technologien in die Azure-Plattform. Benutzer verwalten den Service über die Azure-Konsole und mit Azure-Automatisierungstools. Der Service wird in Azure Virtual Network (VNet) bereitgestellt und in das Identitäts- und Zugriffsverwaltungssystem von Azure integriert. Die generischen Metriken und Auditlogs von OCI und Oracle AI Database sind nativ in Azure verfügbar. Für den Service müssen Benutzer ein Azure-Abonnement und einen OCI-Mandanten haben.

  Autonome KI-Datenbank 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, wenn Sie Fast-Start Failover für Oracle Exadata Database Service on Exascale Infrastructure auf Oracle AI Database@Azure aktivieren.

Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.

• Platzieren Sie den Observer auf einem Host an einer separaten dritten Site. Dadurch wird sichergestellt, dass Observer aktiv bleibt, um das Failover zu koordinieren oder die verbleibende Site zu überwachen, wenn die primäre Site oder die Standby Site vollständig ausfällt.
• Falls keine dritte Site verfügbar ist, platzieren Sie den Observer an der primären Site.
• Konfigurieren Sie mehrere Beobachter auf verschiedenen Servern für High Availability. Während nur ein Beobachter der primäre Beobachter sein kann, dienen zusätzliche Beobachter als Backup-Beobachter.
• Befolgen Sie die Oracle-Dokumentation, um die Werte für Fast-Start Failover-Konfigurationseigenschaften festzulegen, wie Fast-Start Failover-Eigenschaften, wie FastStartFailoverThreshold, FastStartFailoverLagLimit und FastStartFailoverAutoReinstate.
• Führen Sie den Data Guard Broker Observer immer mit demselben Major Release und derselben Patchebene (einschließlich Release Update [RU]) aus wie die Oracle AI Database Homes in Ihrer Data Guard-Konfiguration. Diese Kombination erhält die gründlichsten Tests und minimiert die Betriebsrisiken. Außerdem wird sichergestellt, dass alle Fixes, die sowohl clientseitigen (Beobachter-) als auch serverseitigen (Datenbank-)Code betreffen, jederzeit vorhanden sind. Ein Unterschied von bis zu einem großen Long-Term Support Release (LTS) zwischen Observer und der Datenbank ist zulässig, hauptsächlich um Rolling Upgrades zu erleichtern und Ausfallzeiten zu minimieren. Beispiel: Der Observer bei 26ai mit der Datenbank bei 19c während der Upgradeprozeduren oder umgekehrt.

Hinweise

Beim Aktivieren von Fast-Start Failover für Oracle Exadata Database Service on Exascale Infrastructure auf Oracle AI Database@Azure sollten Sie Folgendes berücksichtigen:

• Platzieren Sie Observer niemals auf derselben Site wie die Standby-Datenbank. Wenn die Standby Site heruntergefahren wird, wird die primäre Site ebenfalls heruntergefahren, da sie nicht mit dem Observer kommunizieren kann, was zu einem vollständigen Ausfall führt
• Der Observer kann auf einer einfachen VM ausgeführt werden. Die Stabilität der Netzwerkverbindung zur Primär- und Standbydatenbank ist jedoch von entscheidender Bedeutung, um ordnungsgemäße Vorgänge sicherzustellen und unnötige Failover zu vermeiden.
• Konfigurieren Sie den Modus für die maximale Verfügbarkeit von Data Guard, um sicherzustellen, dass keine Daten verloren gehen. Wenn Sie sich mehr um die Performance der Primärdatenbank als um einen minimalen Datenverlust kümmern, sollten Sie Fast-Start Failover aktivieren, wenn der Konfigurationsschutzmodus auf maximale Performance gesetzt ist.

• Die Failover-Zeit hängt davon ab, ob die Standby-Zieldatenbank alle Redo-Daten angewendet hat, die sie von der Primärdatenbank empfangen hat. Das Fast-Start Failover ist schneller, wenn Sie Schritte zur Optimierung des Recoverys unternehmen, damit die Anwendung von Redo-Daten in der Standby-Datenbank mit der Redo-Anwendungsrate der primären Datenbank auf dem neuesten Stand gehalten wird. Weitere Informationen finden Sie im Abschnitt Überlegungen zur Performance beim Fast-Start Failover in der Dokumentation zu Data Guard, Broker-Konzepte.

• Die Failover-Zeit hängt vom Redo Apply-Status in der Standbydatenbank ab.

Erforderliche Services und Rollen

Prüfen Sie die erforderlichen Services und Rollen, um eine Standbydatenbank zu erstellen und Networking für Fast-Start Failover zu verwalten.

Für diese Lösung sind die folgenden Services und Rollen erforderlich:

• Oracle Exadata Database Service auf Exascale-Infrastruktur
• Oracle Cloud Infrastructure Networking

Dies sind die Rollen, die für jeden Service erforderlich sind.

Servicename: Rolle	Erforderlich für...
OCI-Datenbank: manage database-family	Data Guard-Standbydatenbank erstellen
OCI Networking: manage vcn-family	Netzwerksicherheitsgruppe in OCI verwalten

Informationen zu Ihren Anforderungen finden Sie unter Produkte, Lösungen und Services von Oracle.