Hochverfügbare Bare Metal-Datenbank bereitstellen
Oracle Data Guard stellt hohe Verfügbarkeit, Datenschutz und Disaster Recovery für Unternehmensdaten sicher. Mit Data Guard kann das Failover der Primärdatenbank zur Standbydatenbank manuell über die Data Guard Broker-Befehlszeilenschnittstelle (DGMGRL CLI) oder Oracle Enterprise Manager oder automatisch durch Konfigurieren eines Compute-Knotens als Fast-Start Failover-(FSFO-)Observer ausgeführt werden. Der Observer kann automatisch Failover initiieren und automatisch eine nicht erfolgreiche Primärdatenbank als Standbydatenbank neu instanziieren. Wenn FSFO-Beobachter im Deployment vorhanden sind, entfällt die Notwendigkeit einer manuellen Intervention, wenn Datenbank-Failover erforderlich ist.
Architektur
Diese Referenzarchitektur zeigt, wie zwei Bare-Metal-DB-Systeme und die Infrastrukturkomponenten bereitgestellt werden, die für die Konfiguration von FSFO für eine Oracle Database 12c Release 2 (12.2) erforderlich sind, die in Oracle Cloud Infrastructure in zwei Regionen bereitgestellt wird.
Diese Cloud-Datenbankarchitektur kann als widerstandsfähige Datenbankebene für viele Anwendungen verwendet werden, einschließlich Oracle E-Business Suite, JD Edwards und PeopleSoft.
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.
Beschreibung der Abbildung ha-db.png
- Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Rechenzentrum (Availability-Domains) enthält. 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 Rechenzentren innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain werden von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Verfügbarkeitsdomänen teilen keine Infrastruktur wie Strom oder Kühlung oder das interne Availability-Domänennetzwerk. Somit ist es unwahrscheinlich, dass ein Fehler bei einer Availability-Domain die anderen Availability-Domains in der Region beeinträchtigt.
Verfügbarkeitsdomains werden im Architekturdiagramm nicht angezeigt.
- Fault-Domains
Eine Faultdomain ist eine Gruppierung von Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain verfügt über drei Fault-Domains mit unabhängiger Leistung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physischen Serverausfall, Systemwartung und Stromausfälle innerhalb einer Faultdomain tolerieren.
Fault-Domains werden im Architekturdiagramm nicht angezeigt.
- Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region eingerichtet haben. Wie herkömmliche Rechenzentrumsnetze geben VCNs Ihnen die vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überlappende CIDR-Blöcke enthalten, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die für eine Region oder eine Availability-Domain Geltungsbereich haben können. Jedes Subnetz besteht aus einem zusammenhängenden Adressbereich, der sich nicht mit den anderen Subnetzen im VCN überschneidet. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.
- Sicherheitslisten
Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die die Quelle, das Ziel und den Traffictyp angeben, die im Subnetz und außerhalb des Subnetzes zulässig sein müssen.
- Beobachter
Observer sind Compute-Knoten, auf denen die erforderliche Oracle Database-Software installiert und konfiguriert ist, um FSFO des Oracle Database zu initiieren, das auf dem Bare-Metal-DB-System ausgeführt wird. Eine FSFO Best Practice besteht darin, den Observer-Prozess auf einem Host auszuführen, der sich in einem anderen Rechenzentrum als der primären oder Standbydatenbank befindet. Um diese Best Practice zu erfüllen, stellt diese Referenzarchitektur drei Observer-Knoten bereit. Oracle Database Release 12.2 oder höher ist für dieses Setup erforderlich.
- Primär- und Standby-DB-Systeme
Für diese Bare-Metal-DB-Systeme ist eine Oracle Database 12c Release 2 (12.2) für die Data Guard-Replikation konfiguriert.
Empfehlungen
Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.
- DB-Systemformen
Diese Referenzarchitektur verwendet die Bare-Metal-Form von BM.Standard2.52 für die DB-Systeme. Diese Form hat 51.2 TB lokal angehängte NVMe-SSDs mit geringer Latenz. Wir haben die Bare-Metal-Form ausgewählt, weil es uns erlaubt, mehrere Datenbank-Homes und Datenbanken zu erstellen.
- Compute Shapes
Diese Referenzarchitektur verwendet eine VM-(VM.Standard2.1 Core Virtual Machine-) Form für die Observer-Knoten. Der Observerknoten ist ein Oracle Call Interface-Client mit niedrigem Footprint, der in die DGMGRL-CLI integriert ist. Eine zentrale VM-Form reicht für diese Architektur aus.
- VCN
Legen Sie beim Erstellen eines VCN die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen fest, die Sie Subnetzen in VCN zuordnen möchten. Verwenden Sie CIDR-Blöcke, die sich im standardmäßigen privaten IP-Adressraum befinden.
Wählen Sie CIDR-Blöcke, die sich nicht mit einem anderen Netzwerk überschneiden (in Oracle Cloud Infrastructure, Ihrem On-Premise-Rechenzentrum oder einem anderen Cloud-Provider), zu dem Sie private Verbindungen einrichten möchten.
Nachdem Sie ein VCN erstellt haben, können Sie die CIDR-Blöcke ändern, hinzufügen und entfernen.
Wenn Sie die Subnetze entwerfen, sollten Sie den Trafficfluss und die Sicherheitsanforderungen berücksichtigen. Ordnen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle demselben Subnetz zu, das als Sicherheitsgrenze dienen kann.
Regionale Subnetze verwenden
- Sicherheitslisten
Mit Sicherheitslisten können Sie Ingress- und Egressregeln definieren, die für das gesamte Subnetz gelten. Beispiel: Diese Referenzarchitektur ermöglicht ICMP intern für das gesamte private Subnetz.
- Cloud Guard
Klonen und passen Sie die von Oracle bereitgestellten Standardrezepte an, um benutzerdefinierte Detektor- und Antworterezepte zu erstellen. Mit diesen Rezepturen können Sie angeben, welche Art von Sicherheitsverletzungen eine Warnung generieren und welche Aktionen für sie ausgeführt werden dürfen. Beispiel: Sie möchten Object Storage-Buckets ermitteln, deren Sichtbarkeit auf öffentlich gesetzt ist.
Wenden Sie Cloud Guard auf Mandantenebene an, um den breitesten Geltungsbereich abzudecken und den administrativen Aufwand für die Verwaltung mehrerer Konfigurationen zu verringern.
Mit der Funktion "Verwaltete Liste" können Sie bestimmte Konfigurationen auch auf Detektoren anwenden.
- Sicherheitszonen
Für Ressourcen, die maximale Sicherheit erfordern, empfiehlt Oracle, Sicherheitszonen zu verwenden. Eine Sicherheitszone ist ein Compartment, das einem von Oracledefinierten Rezept von Sicherheits-Policys zugeordnet ist, die auf Best Practices basieren. Beispiel: Die Ressourcen in einer Sicherheitszone dürfen nicht über das öffentliche Internet zugänglich sein und müssen mit kundenverwalteten Schlüsseln verschlüsselt werden. Wenn Sie Ressourcen in einer Sicherheitszone erstellen und aktualisieren, validiert Oracle Cloud Infrastructure die Vorgänge für die Policys im Rezept für die Sicherheitszone und verweigert Vorgänge, die gegen eine der Policys verstoßen.
Überlegungen
Beachten Sie diese Punkte beim Deployment dieser Referenzarchitektur.
- Performance
Um die beste Performance für Ihre Anwendungs-Workloads zu erhalten, stellen Sie sicher, dass das primäre Bare-Metal-DB-System über ausreichende Cores verfügt, um die Anwendung und die Data Guard-Konfiguration zu unterstützen.
- Verfügbarkeit
Die Observer-Knoten werden in mehreren Verfügbarkeitsbereichen bereitgestellt, um sicherzustellen, dass FSFO automatisch auftreten kann, auch wenn einer der Observer-Knoten offline geht. Nach dem Failover wird die Standbydatenbank zur primären Datenbank.
- Kostenfaktor
Größe der CPUs auf den Bare-Metal-DB-Systemen basierend auf Ihren Bedürfnissen. Sie können mit zwei oder mehr Kernen beginnen und bis zu 52 Kerne in einer BM.DenseIO2.52-Form skalieren. Sie können die Kerne auch dynamisch ohne Ausfallzeiten skalieren.