Entwicklung einer Pilot-Light Disaster Recovery-(DR-)Topologie
Wenn sich ein großer Ausfall auf Ihre Produktionsanwendungen auswirkt, müssen Sie die Workloads schnell wiederherstellen. Ihr Business Continuity-Plan sollte eine DR-Strategie beinhalten, die Ihren Recovery Point, Ihrer Recovery-Zeit und Ihren Budgetzielen entspricht. Eine Pilot-Light-Topologie bietet ein Gleichgewicht zwischen Kosten- und Wiederherstellungsanforderungen.
Der Begriff Pilotlicht bezieht sich auf eine kleine Flamme, die bei Geräten wie gasbetriebenen Heizgeräten immer leuchtet und bei Bedarf schnell zum Starten der Geräte verwendet werden kann. Im Kontext von DR enthält eine Pilot-Lichtumgebung die Kernkomponenten einer bestimmten Workload mit den neuesten Konfigurations- und kritischen Daten, die in minimaler Skalierung an einem Standort ausgeführt werden, der vom primären Standort entfernt ist. Bei einer Katastrophe am primären Standort können Sie die Pilotlichtkomponenten am Remote-Standort verwenden, um eine Produktionsumgebung schnell wiederherzustellen.
Oracle Cloud Infrastructure bietet hochverfügbare und skalierbare Infrastruktur und Services, mit denen Sie eine Pilot-Light-DR-Topologie entwickeln können.
Architektur
Diese Architektur zeigt eine mehrstufige Topologie mit redundanten Ressourcen, die über zwei Oracle Cloud Infrastructure-Regionen verteilt sind.
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

Beschreibung der Abbildung x-region-pilot-light-topology.png
Die Architektur umfasst folgende Komponenten:
- Regionen
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center, sogenannte Availability-Domains, enthält. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie (über Länder oder sogar Kontinente) trennen.
- Availability-Domains
Availability-Domains sind eigenständige, unabhängige Data Center in einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Daher ist es wahrscheinlich, dass sich ein Fehler in einer Availability-Domain auf die anderen Availability-Domains in der Region auswirkt.
Das Architekturdiagramm zeigt keine Availability-Domains an. In Regionen mit mehreren Availability-Domains können Sie die Ressourcen in jeder Region jedoch für High Availability auf die Availability-Domains verteilen.
- Faultdomains
Eine Fehlerdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain hat drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverfehler, Systemwartung und Stromausfälle innerhalb einer Faultdomain tolerieren.
Das Architekturdiagramm zeigt keine Faultdomains an. Um jedoch vor Ausfällen in einer Faultdomain zu schützen, können Sie die Ressourcen in jeder Verfügbarkeit auf die Faultdomains verteilen.
- Virtual Cloud Networks (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 VCNs vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überlappende CIDR-Blöcke haben, 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 gelten können. Jedes Subnetz besteht aus einem fortlaufenden Adressbereich, der sich nicht mit den anderen Subnetzen im VCN überschneidet. Sie können die Größe eines Subnetzes nach dem Erstellen ändern. Ein Subnetz kann öffentlich oder privat sein.
In dieser Referenzarchitektur werden alle Ressourcen in jeder Region an ein einzelnes VCN angehängt.
- Bastion Host
Der Bastionhost ist eine Compute-Instanz, die als sicherer, kontrollierter Einstiegspunkt in die Topologie von außerhalb der Cloud dient. Der Bastionhost wird in der Regel in einer demilitarisierten Zone (DMZ) bereitgestellt. Dadurch können Sie sensible Ressourcen schützen, indem Sie sie in privaten Netzwerken platzieren, auf die nicht direkt von außerhalb der Cloud zugegriffen werden kann. Die Topologie hat einen einzigen, bekannten Einstiegspunkt, den Sie regelmäßig überwachen und auditieren können. Sie können also vermeiden, die sensibleren Komponenten der Topologie freizugeben, ohne den Zugriff darauf zu beeinträchtigen.
- Load Balancer
Der Oracle Cloud Infrastructure Load Balancing-Service ermöglicht automatisierte Trafficverteilung von einem einzelnen Einstiegspunkt auf mehrere Server im Backend.
- Internetgateway
Das Internetgateway ermöglicht Traffic zwischen den öffentlichen Subnetzen in einem VCN und dem öffentlichen Internet.
- Compute-Instanzen
Die primäre Region umfasst zwei Compute-Instanzen für die Anwendungsebene.
Die Standbyregion verfügt über eine Compute-Instanz zum Mounten des replizierten Dateispeichers. Die anderen beiden Compute-Instanzen in der Standby-Region stellen Server dar, die Sie mit replizierten Boot-Volumes und Block-Volumes im Falle einer Katastrophe in der primären Region erstellen können.
- Block-Volumes
Mit Block Storage-Volumes können Sie Speicher-Volumes erstellen, anhängen, verbinden und verschieben sowie die Volume-Performance entsprechend Ihren Speicher-, Performance- und Anwendungsanforderungen ändern. Nach dem Anhängen und Verbinden eines Volumes mit einer Instanz können Sie das Volume wie ein herkömmliches Festplattenlaufwerk verwenden. Sie können ein Volume auch trennen und an eine andere Instanz anhängen, ohne Daten zu verlieren.
Die Architektur zeigt die Boot-Volumes und Block-Volumes in der primären Region an, die in der Standby-Region repliziert werden. Bei diesem Design können Sie im Falle einer Katastrophe in der primären Region die Anwendungsebene schnell in der Standbyregion wiederherstellen, indem Sie Compute-Instanzen mit den replizierten Boot- und Block-Volumes bereitstellen.
- Dateispeicher
Oracle Cloud Infrastructure File Storage Service stellt ein dauerhaftes, skalierbares, sicheres Netzwerkdateisystem der Enterprise-Klasse bereit. Sie können über jede Bare-Metal- oder VM- oder Containerinstanz in einem VCN eine Verbindung mit einem File Storage Service-Dateisystem herstellen. Sie können auch außerhalb des VCN mit Oracle Cloud Infrastructure FastConnect und IPSec-VPN auf ein Dateisystem zugreifen.
Die Architektur zeigt den Dateispeicher in der primären Region an, der mit einem Skript in die Standby-Region repliziert wird.
- Objektspeicher
Object Storage bietet schnellen Zugriff auf große Mengen strukturierter und unstrukturierter Daten eines beliebigen Inhaltstyps, einschließlich Datenbankbackups, Analysedaten und umfangreicher Inhalte wie Bilder und Videos. Sie können Daten sicher speichern und dann direkt aus dem Internet oder aus der Cloud-Plattform abrufen. Sie können den Speicher nahtlos skalieren, ohne dass es zu einer Beeinträchtigung der Performance oder Servicezuverlässigkeit kommt. Verwenden Sie den Standardspeicher für "heiße" Speicher, auf den Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicher für "kalten" Speicher, den Sie über lange Zeiträume beibehalten und selten oder nur selten zugreifen.
Die Architektur zeigt den Objektspeicher in der primären Region an, der mit einer regionsübergreifenden Replikations-Policy automatisch auf die Standbyregion repliziert wird.
- Anwendungsserver
Anwendungsserver verwenden einen sekundären Peer, der wie die Datenbank im Katastrophenfall die Verarbeitung übernimmt. Anwendungsserver verwenden Konfiguration und Metadaten, die sowohl in der Datenbank als auch im Dateisystem gespeichert sind. Das Application Server-Clustering bietet Schutz im Geltungsbereich einer einzelnen Region. Laufende Änderungen und neue Deployments müssen jedoch kontinuierlich an den sekundären Speicherort repliziert werden, um ein konsistentes Disaster Recovery zu ermöglichen.
- Datenbank
Die Architektur umfasst eine Datenbank in jeder Region. Oracle Data Guard wird für die Datenreplikation verwendet und stellt sicher, dass die Standbydatenbank eine transaktionskonsistente Kopie der Primärdatenbank ist.
Die Synchronisierung zwischen den Datenbanken wird automatisch durch die Übertragung und Anwendung von Redo-Daten aus der Primärdatenbank in die Standby-Datenbank verwaltet. Bei einem Ausfall in der primären Region führt Data Guard ein Failover automatisch zur Standbydatenbank durch.
- Dynamisches Routinggateway (DRG)
Das DRG ist ein virtueller Router, der einen Pfad für privaten Netzwerktraffic zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, wie ein VCN in einer anderen Oracle Cloud Infrastructure-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloudprovider.
- NAT-Gateway
Mit dem NAT-Gateway können private Ressourcen in einem VCN auf Hosts im Internet zugreifen, ohne dass diese Ressourcen für eingehende Internetverbindungen freigegeben werden.
- Servicegateway
Das Servicegateway bietet Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zu dem Oracle-Service durchläuft das Oracle-Fabric und durchläuft nie das Internet.
Empfehlungen
Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für die Entwicklung Ihrer Pilot-Light-DR-Topologie. Ihre Anforderungen können sich von der hier beschriebenen Architektur unterscheiden.
- VCN
Bestimmen Sie beim Erstellen jedes VCN, wie viele IP-Adressen Ihre Cloud-Ressourcen in jedem Subnetz benötigen. Geben Sie mit der Classless Inter-Domain Routing-(CIDR-)Notation eine Subnetzmaske und einen Netzwerkadressbereich an, der groß genug für die erforderlichen IP-Adressen ist. Verwenden Sie einen Adressbereich innerhalb des standardmäßigen privaten IP-Adressbereichs.
Wählen Sie CIDR-Blöcke, die sich nicht mit einem anderen Netzwerk überschneiden (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider), in dem Sie private Verbindungen einrichten möchten.
Nachdem Sie ein VCN erstellt haben, können Sie die zugehörigen CIDR-Blöcke ändern, hinzufügen und entfernen.
Berücksichtigen Sie beim Entwerfen der Subnetze den Verkehrsfluss und die Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.
Regionale Subnetze verwenden
- Sicherheitslisten
Um die regionsübergreifende Replikation der Datenbank und des Dateispeichers zuzulassen, konfigurieren Sie die erforderlichen Sicherheitslisten. Beachten Sie, dass die Replikation der Boot-Volumes und Block-Volumes keine Kommunikation zwischen den Hosts erfordert, an die die Volumes angehängt sind.
- Backup-Policy für Block-Volumes
Konfigurieren Sie eine Policy, um Backups der Block-Volumes so häufig wie nötig zu erstellen, um Ihren RPO zu erfüllen.
- Anwendungsserver und benutzerdefinierte Anwendungen, die auf Oracle Platform as a Service (PaaS) ausgeführt werden
PaaS-Services, wie Oracle SOA Cloud Service und Oracle WebLogic Server for Oracle Cloud Infrastructure, verwenden die meisten der oben genannten Ressourcen intern (Compute, Block-Volumes, Dateispeicher, Netzwerk, Datenbank). Sie erfordern spezielle Disaster-Recovery-Strategien, die alle verschiedenen Schichten konsistent schützen. Oracle bietet detaillierte Best Practices zur Erstellung von Maximum Availability Architecture (MAA) und zum Schutz dieser Systeme vor Katastrophen. Weitere Informationen zur Disaster Recovery (DR) für PaaS finden Sie unter "Explore More".
Überlegungen
Berücksichtigen Sie bei der Implementierung des DR-Setups für Pilotlicht die folgenden Faktoren:
- Performance
Berücksichtigen Sie bei der Planung von RPO und RTO die Zeit, die für das regionsübergreifende Kopieren von Volume-Backups erforderlich ist.
- Verfügbarkeit
Mit der DNS-Lenkungsverwaltung können Sie Clientdatenverkehr nach einem Failover in die aktuelle Produktionsregion umleiten.
Wenn Sie Compute-Ausprägungen verwenden, die lokal angehängte NVMe-Geräte bereitstellen, können Sie die Daten auf diesen Geräten mit herkömmlichen Backuplösungen sichern, die Objektspeicher verwenden.
- Kostenfaktor
Bei einem Failover von der primären zur Standbyregion können Sie die erforderliche Infrastruktur schnell mit Terraform-Skripten bereitstellen. Sie können die Größe der Datenbanksysteme nach dem Provisioning ändern. Geben Sie daher zunächst die erforderliche Mindestausprägung an, und wechseln Sie nach dem Failover zu einer größeren Ausprägung.
Mehr anzeigen
Erfahren Sie mehr über Disaster Recovery und Resilienz in Oracle Cloud Infrastructure.
- Weitere Informationen zum Schutz Ihrer Cloud-Topologie vor Katastrophen
- Regionale private Konnektivität zwischen Mandanten konfigurieren
- Hochverfügbare Webanwendung bereitstellen
Weitere Informationen zu den folgenden Oracle PaaS-Services finden Sie in den technischen Anweisungen zur MAA-Disaster Recovery:
SOA Suite auf Oracle Cloud Infrastructure Marketplace Disaster Recovery
Oracle WebLogic Server für Oracle Cloud Infrastructure Disaster Recovery