Hinweis:

Dieses Tutorial erfordert Zugriff auf Oracle Cloud. Informationen zur Registrierung für einen kostenlosen Account finden Sie unter Erste Schritte mit Oracle Cloud Infrastructure Free Tier.
Es verwendet Beispielwerte für Oracle Cloud Infrastructure-Zugangsdaten, -Mandanten und -Compartments. Ersetzen Sie diese Werte nach Abschluss der Übung durch Werte, die für Ihre Cloud-Umgebung spezifisch sind.

Automatisieren Sie Cold Disaster Recovery für Oracle HeatWave MySQL mit OCI Full Stack Disaster Recovery

Einführung

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orchestriert den Übergang von Compute, Datenbank und Anwendungen zwischen OCI-Regionen aus der ganzen Welt mit einem einzigen Klick. Kunden können die erforderlichen Schritte zur Wiederherstellung eines oder mehrerer Geschäftssysteme automatisieren, ohne vorhandene Infrastruktur, Datenbanken oder Anwendungen neu zu entwerfen oder neu zu strukturieren und ohne spezielle Verwaltungs- oder Konvertierungsserver zu benötigen.

Oracle HeatWave MySQL ist ein vollständig verwalteter Datenbankservice, der in Oracle Cloud Infrastructure (OCI) bereitgestellt wird und Betreiber und Entwickler unterstützt, die sichere, cloudnative Anwendungen schnell bereitstellen möchten. Oracle HeatWave MySQL ist das einzige MySQL-Angebot, das die Möglichkeit umfasst, HeatWave zu verwenden, einen integrierten, leistungsstarken In-Memory-Abfragebeschleuniger. Mit HeatWave können Kunden anspruchsvolle Analysen direkt für ihre betriebliche MySQL-Datenbank ausführen, sodass keine komplexe, zeitaufwendige und teure Datenmigration und -integration in eine separate Analysedatenbank erforderlich ist. HeatWave beschleunigt die MySQL-Performance für Analysen und gemischte Workloads enorm. HeatWave ist vollständig für OCI optimiert, und Oracle HeatWave MySQL wird zu 100% von den OCI- und MySQL-Entwicklungsteams erstellt, verwaltet und unterstützt.

In diesem Tutorial erfahren Sie, wie Sie ein Cold Disaster Recovery für Oracle HeatWave MySQL in OCI automatisieren. Es beschreibt die Verfahren zur Verwendung des OCI Full Stack DR-Service zur Verwaltung der Switchover- und Failover-Prozesse.

Hinweis: Diese Art von Disaster-Recovery-(DR-)Strategie basiert auf einem Backup- und Restore-Mechanismus und eignet sich somit am besten für nicht kritische Anwendungen, bei denen die Geschäftsanforderungen für Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) nicht übermäßig anspruchsvoll sind.

Architekturbeschreibung

Die in diesem Tutorial präsentierte Architektur zeigt eine WordPress-Anwendung, die auf virtuellen OCI-Maschinen (VMs) ausgeführt wird, die nahtlos in Oracle HeatWave MySQL integriert sind. Darüber hinaus nutzt das Setup den OCI File Storage-Service als NFS-(Network File System-)Freigabe zum Speichern von WordPress-Inhalten. Dieser Shared Storage wird auf jeder VM gemountet und stellt so einen sofortigen und synchronisierten Zugriff auf alle neuen Inhalte in der gesamten Umgebung sicher.

Ein OCI Load Balancer wird in einem öffentlichen Subnetz bereitgestellt, um externe Benutzerverbindungen effizient zu verwalten und eingehenden Traffic über die WordPress-VMs zu verteilen.

Beschreibung der Disaster Recovery-Architektur

Die DR-Strategie für die WordPress-Anwendungs-VMs umfasst einen umfassenden Ansatz, einschließlich der vollständigen Replikation jedes Boot-Volumes der VM mit Volume-Gruppenreplikation und der Nutzung der File Storage-Replikation, um die Synchronisierung von WordPress-Inhalten sicherzustellen.

Ein Load Balancer wird in der Remoteregion vorab bereitgestellt. Dadurch wird sichergestellt, dass er Traffic nahtlos verarbeiten kann, wenn die WordPress-VMs während eines Switchover- oder Failover-Szenarios in die Remoteregion übergehen.

Bei Oracle HeatWave MySQL werden Backups regelmäßig in die Remote-Region kopiert, um den Datenschutz und die Disaster Recovery-Bereitschaft sicherzustellen. Dieser Prozess kann über eine Anwendungs-VM mit einem benutzerdefinierten Skript initiiert werden, das über crontab für eine automatisierte und konsistente Ausführung geplant werden kann.

Das folgende Diagramm veranschaulicht den Workflow zum Kopieren des letzten verfügbaren MySQL-Backups aus der primären Region in die Remoteregion.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Copy_Backup_to_Remote.png

Das folgende crontab-Setup wurde unter dem Benutzer opc in der Anwendung WordPress VM1 konfiguriert, um das Skript mds_copy_bkp.py alle 4 Stunden auszuführen. Dadurch wird die automatische Backupsynchronisierung in der Standbyregion sichergestellt, was zu einer verbesserten Disaster Recovery beiträgt:

15 */4 * * * /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01

Dieser Job führt das Skript in der 15. Minute nach jeder 4. Stunde aus.

Alle Skripte sind unter GitHub verfügbar und werden in den folgenden Abschnitten ausführlich beschrieben.

Hinweis: Planen Sie dieses Skript (oder ein ähnliches) gemäß Ihren Geschäftsanforderungen, um das Backup MySQL regelmäßig in die Remoteregion zu kopieren. Ohne diesen Schritt verläuft der Wiederherstellungsprozess möglicherweise nicht erfolgreich, weil das Backup in der sekundären Region nicht verfügbar ist.

Wie funktioniert die Erholung?

Nach der Ausführung eines geplanten Switchovers kehren die Rollen um: Die primäre Workload wird in Region 2 ausgeführt, während die Standbydatenbank in Region 1 ausgeführt wird. Die Architektur wird wie folgt angezeigt:

fsdr_mds_copy_restore_bkp-Physical_Switchover_Architecture.png

Im aktuellen Setup verwenden wir den privaten OCI-DNS-Service, um einen DNS-Datensatz zu verwalten, der den Traffic an den aktiven Oracle HeatWave MySQL-Endpunkt weiterleitet. Während des Recovery-Prozesses wird dieser DNS-Datensatz über ein benutzerdefiniertes Skript aktualisiert, um das neue Oracle HeatWave MySQL widerzuspiegeln und so ein nahtloses Failover und eine kontinuierliche Serviceleistung sicherzustellen.

Das folgende Diagramm veranschaulicht den Workflow zum Wiederherstellen des letzten MySQL-Backups in der Standbyregion.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Restore_Backup_to_Remote.png

Die Recovery-Lösung für dieses Deployment erfordert, dass OCI Full Stack DR eine Reihe benutzerdefinierter Python-Skripte während eines Recovery-Vorgangs wie Failover oder Switchover ausführt. Die in diesem Tutorial referenzierten Skripte werden vom EMEA-Team für Cloud Architecture-Spezialisten bereitgestellt und sind hier verfügbar: Full-Stack-Disaster-Recovery, das speziell auf diese DR-Lösung zugeschnitten ist.

In diesem Tutorial wird erläutert, wie Sie die Skripte herunterladen und in einer späteren Aufgabe verwenden.

Hinweis: Die folgenden Skripte dienen der allgemeinen Anleitung. Sie können entweder Ihre eigenen Skripte verwenden oder die Skripte entsprechend Ihren Unternehmensrichtlinien und Sicherheitsanforderungen anpassen.

Definitionen und Annahmen im gesamten Tutorial

Bereiche:
- Region 1 ist Dubai: Dubai wird zunächst als primäre Region dienen. Diese Rolle wechselt jedoch während des Switchover-Prozesses in den Standby-Modus, der im Rahmen des Disaster Recovery-Plans in den späteren Aufgaben ausgeführt wird.
- Region 2 ist Abu Dhabi: Abu Dhabi wird zunächst als Standby-Region fungieren. Diese Rolle wird nach dem Switchover-Prozess, der im Rahmen des Disaster Recovery-Prozesses in den nachfolgenden Aufgaben ausgeführt wird, später in die primäre Rolle übergehen.
Compartments: Sie können dieses Deployment und OCI Full Stack DR in einem beliebigen Compartment-Schema organisieren, das Ihren Standards für IT-Governance entspricht. Wir haben beschlossen, alle OCI-Ressourcen für dieses Tutorial in einem einzigen Compartment zu organisieren.

WordPress Anwendungs-VMs und OCI File Storage

Die in diesem Tutorial verwendete Architektur bezieht sich auf OCI File Storage, um sicherzustellen, dass alle Anwendungs-VMs gemeinsamen Zugriff auf denselben WordPress-Inhalt haben.

Weitere Informationen zum korrekten Mounten des Dateisystems auf den Linux-Instanzen finden Sie unter Dateisystem für automatisches Mounten konfigurieren (Linux-Instanzen).

Im Folgenden finden Sie ein Beispiel für die Dateikonfiguration /etc/fstab zum Mounten des Dateisystems auf der Anwendungs-VM WordPress.

xxx.xxx.xxx.xxx:/wordpress /var/www/html nfs nfsvers=3,noacl,nosuid,nofail 0 0

Ersetzen Sie xxx.xxx.xxx.xxx durch die IP-Adresse des Mountziels in Region 1, um die ordnungsgemäße Konnektivität sicherzustellen.

Ziele

In diesem Tutorial werden die folgenden Aufgaben behandelt:

Aufgabe 1: Umgebung für Disaster Recovery vorbereiten
Aufgabe 2: DR-Schutzgruppen (DRPG) in beiden Regionen erstellen
Aufgabe 3: Mitglieder zur DR-Schutzgruppe hinzufügen
Aufgabe 4: Grundlegende DR-Pläne in Region 2 erstellen
Aufgabe 5: Switchover-Plan in Region 2 anpassen
Aufgabe 6: Failover-Plan in Region 2 anpassen
Aufgabe 7: Vorabprüfungen der DR-Pläne in Region 2 ausführen
Aufgabe 8: Switchover-Plan in Region 2 ausführen
Aufgabe 9: DR-Pläne in Region 1 erstellen und anpassen

Aufgabe 1: Umgebung für Disaster Recovery vorbereiten

Aufgabe 1.1: Volume-Gruppen erstellen und Replikation aktivieren

Erstellen Sie eine Volume-Gruppe für die WordPress-Anwendungs-VMs in Region 1, und stellen Sie sicher, dass sie in Region 2 repliziert wird. Stellen Sie sicher, dass das Boot-Volume für jede Anwendungs-VM (WordPress) ein Mitglied der Volume-Gruppe ist und die Volume-Gruppe in Region 2 repliziert wird.

Die folgende Abbildung zeigt die erstellte Volume-Gruppe mit den Boot-Volumes der beiden WordPress-Anwendungs-VMs, bei denen die Replikation erfolgreich in Region 2 aktiviert wurde. Weitere Informationen finden Sie unter Volume-Gruppen erstellen.

Aufgabe 1.2: File Storage-Replikation für WordPress-Inhalt aktivieren

Erstellen Sie in Region 2 ein Dateisystem, das speziell für die Replikation bestimmt ist. Dieses Dateisystem wird verwendet, um Daten nahtlos von Region 1 in Region 2 zu replizieren.
Erstellen Sie in Region 2 ein Mountziel, das während des Recovery-Prozesses von Region 1 bis Region 2 verwendet wird.
Verwenden Sie das in Schritt 1 erstellte Dateisystem, um die Replikation aus dem OCI File Storage-Quellspeicher in Region 1 zu aktivieren und zu konfigurieren.

Die folgende Abbildung zeigt die File Storage-Replikationsdetails zu Region 2.

Weitere Informationen finden Sie unter Dateisystemreplikation.

Aufgabe 1.3: Anwendungs-VMs zur Ausführung benutzerdefinierter Automatisierung vorbereiten

Installieren und konfigurieren Sie die Oracle Cloud Infrastructure-Befehlszeilenschnittstelle (OCI-CLI). In diesem Tutorial wird Oracle Linux 8 für die Anwendungs-VM WordPress verwendet. Weitere Informationen finden Sie unter CLI installieren.
Stellen Sie das Skript aus dem Repository GitHub (mds_colddr_scripts) im Ordner /home/opc bereit.
Installieren Sie die Pandas und tabellarischen Module, die vom bereitgestellten Skript verwendet werden.
```
pip install pandas
pip install tabulate
```
Aktualisieren Sie die Datei config.csv mit den erforderlichen Details für Oracle HeatWave MySQL in Region 1.
- Ersetzen Sie MYSQL_DB_SYSTEM_OCID durch die OCID von Oracle HeatWave MySQL. Sie können das Label MySQL beibehalten oder an Ihre spezifischen Anforderungen anpassen.
- Ersetzen Sie COMPARTMENT_OCID durch die OCID des Compartments, in dem sich das System MySQL befindet.
- Ersetzen Sie PRIMARY_SUBNET_OCID und STANDBY_SUBNET_OCID durch die Subnetz-OCIDs in beiden Regionen.
- Ersetzen Sie PRIMARY_DNS_VIEW_OCID und STANDBY_DNS_VIEW_OCID durch die OCIDs der privaten DNS-Ansichten, die mit der privaten DNS-Zone verknüpft sind, die den Oracle HeatWave MySQL-Endpunktdatensatz verwaltet.
Hinweis: Stellen Sie sicher, dass alle Werte korrekt aktualisiert werden.

Im Rahmen des Tutorials verwenden wir dieselbe VM für die Ausführung benutzerdefinierter Skripte. Stellen Sie sicher, dass die VM, die als DR-Kontrollknoten fungiert, für die Ausführung von Befehlen konfiguriert wurde. Weitere Informationen finden Sie unter Benutzerdefinierte Skripte mit dem Ausführungsbefehl mit Oracle Cloud Infrastructure Full Stack Disaster Recovery aufrufen.

Aufgabe 1.4: OCI-IAM-Policys für OCI Full Stack DR erstellen

Konfigurieren Sie die erforderlichen OCI IAM-Policys für OCI Full Stack DR, wie in den folgenden Dokumenten beschrieben.

Aufgabe 1.5: OCI-IAM-Policys für andere von OCI Full Stack DR verwaltete Services erstellen

OCI Full Stack DR muss in der Lage sein, andere wichtige OCI-Services wie Compute, Networking, Storage und andere verschiedene Services zu steuern und zu verwalten. Informationen zum Konfigurieren der erforderlichen OCI-IAM-Policys für andere Services finden Sie unter Policys für andere von Full Stack Disaster Recovery verwaltete Services und OCI-IAM-Policys.

Aufgabe 2: DR-Schutzgruppen (DRPG) in beiden Regionen erstellen

Erstellen Sie DR-Schutzgruppen in Region 1 und Region 2, wenn die Schutzgruppen für diesen Anwendungsstack noch nicht vorhanden sind.

Aufgabe 2.1: Schutzgruppe in Region 1 erstellen

Gehen Sie zur OCI-Konsole, und navigieren Sie zu DR-Schutzgruppen, wie in Abbildung 2.1 dargestellt.
1. Stellen Sie sicher, dass der Kontext der OCI-Region auf Region 1 (Dubai) gesetzt ist.
2. Klicken Sie auf Migration und Disaster Recovery.
3. Klicken Sie auf DR-Schutzgruppen.
Abbildung 2.1: Zu DR-Schutzgruppen navigieren
Erstellen Sie eine grundlegende DR-Schutzgruppe (DRPG) in Region 1, wie in Abbildung 2.2 dargestellt. Der Peer, die Rolle und die Mitglieder werden in späteren Schritten zugewiesen.
1. Wählen Sie das Compartment aus, in dem das DRPG erstellt werden soll.
2. Klicken Sie auf DR-Schutzgruppe erstellen, um das Dialogfeld zu öffnen.
3. Verwenden Sie einen sinnvollen Namen für das DRPG.
4. Wählen Sie den OCI Object Storage-Bucket für OCI Full Stack DR-Logs aus.
5. Klicken Sie auf Erstellen.
Abbildung 2.2: Erforderliche Parameter zum Erstellen einer DR-Schutzgruppe in Region 1

Aufgabe 2.2: Schutzgruppe in Region 2 erstellen

Gehen Sie zur OCI-Konsole, und navigieren Sie zu DR-Schutzgruppen (siehe Abbildung 2.3).
1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 2 (Abu Dhabi) gesetzt ist.
2. Klicken Sie auf Migration und Disaster Recovery.
3. Klicken Sie auf DR-Schutzgruppen.
Abbildung 2.3: Zu DR-Schutzgruppen navigieren
Erstellen Sie eine grundlegende DR-Schutzgruppe (DRPG) in Region 2, wie in Abbildung 2.4 dargestellt. Der Peer, die Rolle und die Mitglieder werden in späteren Schritten zugewiesen.
1. Wählen Sie das Compartment aus, in dem das DRPG erstellt werden soll.
2. Klicken Sie auf DR-Schutzgruppe erstellen, um das Dialogfeld zu öffnen.
3. Verwenden Sie einen sinnvollen Namen für das DRPG.
4. Wählen Sie den OCI Object Storage-Bucket für OCI Full Stack DR-Logs aus.
5. Klicken Sie auf Erstellen.
Abbildung 2.4: Erforderliche Parameter zum Erstellen einer DR-Schutzgruppe in Region 2

Aufgabe 2.3: Schutzgruppen in Region 1 und Region 2 zuordnen

Ordnen Sie die DRPGs in jeder Region als Peers miteinander zu, und weisen Sie die Peerrollen der Primär- und Standbydatenbank zu. Die Rollen der Primär- und Standbydatenbank werden automatisch von OCI Full Stack DR im Rahmen einer DR-Operation/DR-Planausführung geändert. Sie müssen die Rollen nicht jederzeit manuell verwalten.

Gehen Sie zur Seite DR-Schutzgruppendetails.
1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 1 (Dubai) gesetzt ist.
2. Klicken Sie auf Zuordnen, um den Prozess zu starten.
Abbildung: Beginn der DRPG-Verknüpfung
Geben Sie die Parameter wie in der folgenden Abbildung dargestellt ein.
1. Rolle: Wählen Sie die Rolle Primär aus. OCI Full Stack DR weist die Standbyrolle automatisch Region 2 zu.
2. Peer-Region: Wählen Sie Region 2 (Abu Dhabi) aus, in der das andere DRPG erstellt wurde.
3. Peer-DR-Schutzgruppe: Wählen Sie das Peer-DRPG aus, das erstellt wurde.
4. Klicken Sie auf Verknüpfen.
Abbildung: Erforderliche Parameter zum Verknüpfen der DRPGs

OCI Full Stack DR zeigt so etwas wie in der folgenden Abbildung an, sobald die Verknüpfung abgeschlossen ist.

Das derzeitige primäre Peer-DRPG ist Dubai (Region 1).
Der aktuelle Standby-Peer DRPG ist Abu Dhabi (Region 2).

Abbildung: Zeigt die Peerbeziehung aus der individuellen DRPG-Perspektive an

Dieselben Informationen finden Sie immer dann, wenn der Kontext/die Ansicht aus einer globalen Perspektive mit allen DR-Schutzgruppen angezeigt wird, wie in der folgenden Abbildung dargestellt.

Das derzeitige primäre Peer-DRPG ist Dubai (Region 1).
Der aktuelle Standby-Peer DRPG ist Abu Dhabi (Region 2).

Abbildung: Zeigt die Peerbeziehung aus der globalen DRPG-Perspektive an

Aufgabe 3: Mitglieder zur DR-Schutzgruppe hinzufügen

In dieser Aufgabe fügen wir die folgenden OCI-Ressourcen zum primären DRPG in Region 1 hinzu.

Die beiden Compute-Instanzen, die die Anwendung WordPress hosten, werden als verschiebende VMs hinzugefügt. Stellen Sie außerdem sicher, dass der Abschnitt Dateisysteme in den erweiterten Optionen ordnungsgemäß konfiguriert ist.
Die Volume-Gruppe, die das Boot-Volume der Compute Nodes der Anwendung WordPress enthält.
Der OCI File Storage mit dem WordPress-Inhalt.
Der primäre Load Balancer.

Aufgabe 3.1: Mitglieder zu DRPG in Region 1 hinzufügen

Wählen Sie das DRPG in Region 1 aus, wie in der folgenden Abbildung dargestellt.
1. Stellen Sie sicher, dass der OCI-Regionskontext Region 1 (Dubai) lautet.
2. Wählen Sie das DRPG in Region 1 aus.
3. Wählen Sie Members.
4. Klicken Sie auf Element hinzufügen, um den Prozess zu starten.
Abbildung: So beginnen Sie mit dem Hinzufügen von Mitgliedern zur DR-Schutzgruppe in Region 1
Fügen Sie eine Compute-Instanz für die WordPress-Anwendungs-VMs hinzu.
1. Warnung zu DR-Plänen bestätigen.
2. Geben Sie Compute als Ressourcentyp für das Element ein.
3. Wählen Sie die Compute-Instanz aus, auf der die Anwendung WordPress gehostet wird.
4. Wählen Sie Gleitende Instanz aus.
5. Klicken Sie auf VNIC-Zuordnung hinzufügen, um auszuwählen, welches VCN und Subnetz den VNICs in Region 2 während eines Recoverys zugewiesen werden soll.
6. Klicken Sie auf Erweiterte Optionen anzeigen.
7. Wählen Sie unter Einstellungen die Option Faultdomain beibehalten aus.
8. Füllen Sie unter Dateisysteme den Abschnitt "Exportzuordnung" entsprechend Ihrem Setup aus, wie in den folgenden Bildern dargestellt.
Abbildung: Erforderliche Parameter zum Hinzufügen der Anwendungs-VM WordPress

Abbildung: Erforderliche Parameter für die Zuordnung der VNIC in Region 2

Abbildung: Erweiterte Optionen, Faultdomain beibehalten

Abbildung: Erweiterte Optionen, Dateisystemzuordnung

Abbildung: Compute-Instanz dem DRPG in Region 1 hinzugefügt

Hinweis: Wiederholen Sie die vorherigen Unterschritte für alle Compute-Instanzen für die WordPress-Anwendungs-VMs.

Abbildung: Zwei Compute-Instanzen, die dem DRPG in Region 1 hinzugefügt wurden
Fügen Sie die Block-Volume-Gruppe hinzu, die das Boot-Volume der Anwendungs-VMs WordPress enthält.
1. Warnung zu DR-Plänen bestätigen.
2. Wählen Sie als Mitglied Ressourcentyp die Option Volume-Gruppe aus.
3. Stellen Sie sicher, dass das richtige Compartment mit der Volume-Gruppe ausgewählt ist, und wählen Sie die Volume-Gruppe aus.
Abbildung: Erforderliche Parameter zum Hinzufügen der Volume-Gruppe für WordPress Compute

Abbildung: Volume-Gruppe für Compute WordPress, die dem DRPG in Region 1 hinzugefügt wurde
Fügen Sie den OCI File Storage hinzu, der den WordPress-Inhalt enthält.
1. Warnung zu DR-Plänen bestätigen.
2. Wählen Sie Dateisystem als Element Ressourcentyp aus.
3. Stellen Sie sicher, dass das richtige Compartment mit dem Dateisystem ausgewählt ist, und wählen Sie das Dateisystem aus.
4. Wählen Sie die Ziel-Availability-Domain aus, die in Region 2 verwendet werden soll.
5. Wählen Sie Quellexportpfad für dieses Dateisystem aus. Dieser Exportpfad wird nach dem Wiederherstellen des Dateisystems in der Zielregion 2 erstellt.
6. Wählen Sie in Region 2 die Option Zielmountziel aus, mit der ein Export für das wiederhergestellte Dateisystem erstellt wird.
Abbildung: Erforderliche Parameter zum Hinzufügen des Dateisystems für WordPress-Inhalt

Abbildung: Dateisystem für WordPress-Inhalt, der dem DRPG in Region 1 hinzugefügt wurde
OCI Load Balancer hinzufügen.

In diesem Beispiel wird der Load Balancer als Mitglied des DRPG in Region 1 hinzugefügt.
1. Warnung zu DR-Plänen bestätigen.
2. Wählen Sie Load Balancer als Ressourcentyp für das Element aus.
3. Stellen Sie sicher, dass die richtigen Compartments für den Load Balancer ausgewählt sind, und wählen Sie den Load Balancer aus, den Sie hinzufügen möchten.
4. Wählen Sie den Ziel-Load-Balancer aus, der in Region 2 verwendet werden soll.
5. Wählen Sie Quell-Backend-Set aus. Dies ist das Backend-Set, das von den WordPress-Anwendungs-VMs verwendet wird. Ein OCI Load Balancer kann von mehreren Anwendungen gemeinsam verwendet werden und kann über mehrere Backend-Sets verfügen. Bei einem DR-Switchover wird die Konfiguration nur für die hier angegebenen Backend-Sets in die Standbyregion verschoben.
6. Wählen Sie Ziel-Backend-Set aus. Dies ist das leere Backend-Set, das in Region 2 erstellt wurde.
Abbildung: Erforderliche Parameter zum Hinzufügen eines Load Balancers

Abbildung: Load Balancer zu DRPG in Region 1 hinzugefügt

Aufgabe 3.2: Mitglieder zu DRPG in Region 2 hinzufügen

Wählen Sie das DRPG in Region 2 aus, wie in der folgenden Abbildung dargestellt.
1. Stellen Sie sicher, dass der OCI-Regionskontext Region 1 (Abu Dhabi) lautet.
2. Wählen Sie das DRPG in Region 2 aus.
3. Wählen Sie Members.
4. Klicken Sie auf Element hinzufügen, um den Prozess zu starten.
Abbildung: So beginnen Sie mit dem Hinzufügen von Mitgliedern zur DR-Schutzgruppe in Region 2
OCI Load Balancer hinzufügen.

In diesem Beispiel wird der Load Balancer als Mitglied des DRPG in Region 2 hinzugefügt.
1. Warnung zu DR-Plänen bestätigen.
2. Wählen Sie Load Balancer als Ressourcentyp für das Element aus.
3. Stellen Sie sicher, dass das richtige Compartment für den Load Balancer ausgewählt ist, und wählen Sie den Load Balancer aus, den Sie hinzufügen möchten.
4. Wählen Sie den Ziel-Load-Balancer aus, der in Region 1 verwendet werden soll.
5. Wählen Sie Quell-Backend-Set aus. Dies ist das Backend-Set, das von den WordPress-Anwendungs-VMs verwendet wird. Ein OCI Load Balancer kann von mehreren Anwendungen gemeinsam verwendet werden und kann über mehrere Backend-Sets verfügen. Bei einem DR-Switchover wird die Konfiguration nur für die hier angegebenen Backend-Sets in die Standbyregion verschoben.
6. Wählen Sie Ziel-Backend-Set aus. Dieses Backend-Set wird in Region 2 erstellt.
Abbildung: Erforderliche Parameter zum Hinzufügen eines Load Balancers

Abbildung: Load Balancer zu DRPG in Region 2 hinzugefügt

Aufgabe 4: Grundlegende DR-Pläne in Region 2 erstellen

In dieser Aufgabe erstellen wir die ersten Switchover- und Failover-Pläne, die mit der Standby-DR-Schutzgruppe in Region 2 (Abu Dhabi) verknüpft sind.

Der Zweck dieser Pläne besteht darin, die Workload nahtlos von der primären Region (Region 1) in die Standbyregion (Region 2) zu verschieben. Im Rahmen eines DR-Vorgangs werden die Rollen der DR-Schutzgruppen in beiden Regionen automatisch umgekehrt: Die Schutzgruppe in Region 1 wird zur Standbydatenbank, während die Schutzgruppe in Region 2 die Primärrolle nach einem Failover oder Switchover übernimmt.

OCI Full Stack DR füllt diese Pläne vorab mit integrierten Schritten aus den bei den vorherigen Aufgaben hinzugefügten Mitgliedsressourcen auf. Diese Pläne werden später angepasst, um während des Recovery-Prozesses spezifische Aufgaben für Oracle HeatWave MySQL zu verwalten.

Switchover-Pläne werden immer innerhalb der Schutzgruppe mit der Standbyrolle erstellt. Da Region 2 (Abu Dhabi) derzeit die Standby-Schutzgruppe ist, werden wir dort mit der Erstellung der Pläne beginnen.

Aufgabe 4.1: DR-Pläne erstellen

Erstellen Sie einen Basisplan, indem Sie das DRPG in Region 2 (Abu Dhabi) auswählen
1. Stellen Sie sicher, dass der OCI-Regionskontext Region 2 (Abu Dhabi) lautet.
2. Wählen Sie das Standby-DRPG in Region 2.
3. Wählen Sie Pläne aus.
4. Klicken Sie auf Plan erstellen, um den Prozess zu starten.
Abbildung: So beginnen Sie mit der Erstellung grundlegender DR-Pläne in Region 2
Erstellen Sie einen Switchover-Plan.
1. Geben Sie einen einfachen, aber aussagekräftigen Namen für den Switchover-Plan ein. Der Name sollte so kurz wie möglich sein, aber auf einen Blick leicht zu verstehen, um Verwirrung und menschliches Versagen während einer Krise zu reduzieren.
2. Wählen Sie unter Plantyp die Option Switchover (geplant) aus.
Abbildung: Die zum Erstellen des DR-Switchover-Plans erforderlichen Parameter
Erstellen Sie einen Failover-Plan.

Befolgen Sie denselben Prozess, um einen allgemeinen Failover-Plan zu erstellen, wie in der folgenden Abbildung dargestellt.
1. Geben Sie den Namen des Failover-Plans einfach, aber aussagekräftig ein. Der Name sollte so kurz wie möglich sein, aber auf einen Blick leicht zu verstehen, um Verwirrung und menschliches Versagen während einer Krise zu reduzieren.
2. Wählen Sie unter Plantyp die Option Failover (nicht geplant) aus.
Abbildung: Die zum Erstellen des DR-Failover-Plans erforderlichen Parameter

Die Standby-DR-Schutzgruppe in Region 2 muss jetzt über die beiden DR-Pläne verfügen, wie in der folgenden Abbildung dargestellt. Diese behandeln den Übergang von Workloads von Region 1 zu Region 2. Sie erstellen ähnliche Pläne in Region 1, um Workloads in einer späteren Aufgabe von Region 2 zurück in Region 1 zu verschieben.

Abbildung: Zeigt die beiden grundlegenden DR-Pläne an, die in Region 2 vorhanden sein müssen, bevor Sie fortfahren

Aufgabe 5: Switchover-Plan in Region 2 anpassen

Die in Aufgabe 4 erstellten grundlegenden DR-Pläne enthalten vorab aufgefüllte Schritte für Recovery-Aufgaben, die in OCI Full Stack DR integriert sind und nichts zur Verwaltung von Recovery-Aufgaben enthalten, die für Oracle HeatWave MySQL spezifisch sind. In dieser Aufgabe wird erläutert, wie Sie benutzerdefinierte DR-Plangruppen und Schritte hinzufügen, um die Aufgaben zu verwalten, die während eines Switchovers ausgeführt werden müssen:

Erstellen Sie ein Datenbankbackup, nachdem Sie die Anwendungs-VMs ordnungsgemäß heruntergefahren haben, um die Datenkonsistenz sicherzustellen.
Übertragen Sie das letzte Datenbankbackup zur Redundanz und Disaster Recovery in die Remote-OCI-Region 2.
Stellen Sie das letzte Datenbankbackup in Region 2 wieder her, um die Umgebung für das Switchover vorzubereiten.
Aktualisieren Sie den DNS-Datensatz der privaten Datenbank, sodass sich die Anwendungs-VMs nahtlos bei der Datenbank in Region 2 anmelden können.
Beenden Sie die Quelldatenbank MySQL in Region 1.

Aufgabe 5.1: Switchover-Plan auswählen

Navigieren Sie zum Switchover-Plan, der in Aufgabe 4 erstellt wurde.

Abbildung: So beginnen Sie mit der Anpassung des Switchover-Plans in Region 2

Aufgabe 5.2: (Optional) DR-Plangruppen aktivieren, die Artefakte beenden

Es gibt drei Plangruppen, die in den Switchover-Plänen standardmäßig deaktiviert sind, wie in der folgenden Abbildung dargestellt. Diese Plangruppen sind deaktiviert, um beim Testen Sicherheit zu bieten. Dadurch wird sichergestellt, dass keine Artefakte gelöscht werden und dass eine funktionsfähige Backupkopie bei Problemen während der Testphase intakt bleibt.

Diese drei Plangruppen sind jedoch so ausgelegt, dass Artefakte beendet (gelöscht) werden, die für zukünftige DR-Vorgänge nicht mehr erforderlich sind. Wenn diese Plangruppen nicht aktiviert sind, sammeln sich nicht verwendete Artefakte im Laufe der Zeit weiter an, wenn Sie Switchover zwischen den beiden Regionen ausführen. Dies kann zu Verwirrung darüber führen, welche Compute-Instanzen, OCI File Storage und Volume-Gruppen aktiv sein sollten.

Wenn Sie diese Plangruppen jetzt aktivieren, können Sie optional vermeiden, dass unnötige Artefakte vor dem Produktionsstart manuell bereinigt werden müssen. Dieser proaktive Schritt kann den Übergang zur Produktion optimieren und eine sauberere, überschaubarere Umgebung aufrechterhalten.

Abbildung: Standardmäßig deaktivierte Plangruppen

Um die Plangruppen zu aktivieren, wählen Sie im Kontextmenü rechts neben dem Plangruppennamen die Option Alle Schritte aktivieren aus.

Abbildung: So aktivieren Sie das Beenden des Dateisystems

Abbildung: Klicken Sie zum Validieren auf "Aktivieren".

Abbildung: So aktivieren Sie das Beenden von Compute-Instanzen

Abbildung: Klicken Sie zum Validieren auf "Aktivieren".

Abbildung: So aktivieren Sie das Beenden der Volume-Gruppe

Abbildung: Klicken Sie zum Validieren auf "Aktivieren".

Aufgabe 5.3: DR-Plangruppen neu anordnen

Sie müssen das Dateisystem auf den neuen VMs mounten, die in Region 2 verschoben wurden, bevor Sie die Load-Balancer-Backend-Sets aktualisieren. Dadurch wird sichergestellt, dass die Anwendung den richtigen Zugriff auf die erforderlichen Speicherressourcen hat, was einen reibungslosen Übergang während des Switchover-Prozesses erleichtert.

Abbildung: Screenshot mit der anfänglichen Reihenfolge des Switchover-Plans und dem Beginn der Neuanordnung

Abbildung: Neuanordnung starten

Verschieben Sie Dateisysteme - Auf Compute-Instanzen mounten vor Load Balancer - Ziel-Backend-Sets aktualisieren.
Klicken Sie auf Änderungen speichern.

Abbildung: Reihenfolge des endgültigen Switchover-Plans

Aufgabe 5.4: Plangruppe zum Ausführen benutzerdefinierter Skripte erstellen

Fügen Sie zunächst benutzerdefinierte DR-Plangruppen hinzu, um den DR-Workflow an die spezifischen Anforderungen des DR-Prozesses MySQL anzupassen.

Diese Plangruppen rufen die erforderlichen Skripte aus der WordPress VM1 in Region 1 auf und müssen im DR-Workflow positioniert werden, bevor die WordPress-Anwendungs-VMs gestartet werden. Dadurch wird sichergestellt, dass die Datenbank MySQL vollständig wiederhergestellt und betriebsbereit ist, bevor die Anwendungs-VMs online gesetzt werden.

Der folgende benutzerdefinierte Plan sollte dem vorab ausgefüllten Switchover-Plan hinzugefügt werden: MySQL Database-Backup erstellen, MySQL Database-Backup kopieren, MySQL Database-Backup wiederherstellen, MySQL Database-DNS aktualisieren und MySQL Database-Quelle beenden.

Fügen Sie eine benutzerdefinierte Plangruppe hinzu, um das Datenbankbackup MySQL zu erstellen.
1. Klicken Sie auf Gruppe hinzufügen.
2. Geben Sie einen einfachen, aber aussagekräftigen Plangruppen-Namen ein. In diesem Beispiel verwenden wir Create MySQL DB Backup.
3. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Beispiel wählen Sie Hinzufügen nach aus, um unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe Compute-Instanzen - Starten einzufügen.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Erstellen des Datenbankbackups MySQL angegeben wird.
Abbildung: Parameter zum Erstellen der Plangruppe "MySQL-DB-Backup erstellen"

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Create MySQL DB Backup. Entspricht dem Plangruppennamen.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die WordPress-Anwendung VM1 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie Zielinstanz aus. Dies ist die WordPress-Anwendung VM1 in Region 1.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/mds_copy_restore_bkp/mds_create_bkp.py mds01.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Erstellen von "Schritt erstellen: MySQL-DB-Backup hinzufügen"

Klicken Sie auf Hinzufügen.

Abbildung: Fügen Sie eine Plangruppe hinzu. Erstellen Sie das DB-Backup MySQL.
Fügen Sie eine benutzerdefinierte Plangruppe hinzu, um das Datenbankbackup MySQL zu kopieren.
1. Klicken Sie auf Gruppe hinzufügen.
2. Geben Sie den Namen der einfachen, aber beschreibenden Plangruppe ein. In diesem Beispiel verwenden wir Copy MySQL DB Backup.
3. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Beispiel wählen Sie Hinzufügen nach aus, um unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe DB-Backup MySQL erstellen einzufügen.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Kopieren des Datenbankbackups der MySQL angeben.
Abbildung: Parameter zum Erstellen der Plangruppe "MySQL DB-Backup kopieren"

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Copy MySQL DB Backup. Entspricht dem Plangruppennamen.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die WordPress-Anwendung VM1 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM1 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Hinzufügen eines Schrittkopie-MySQL-DB-Backups

Klicken Sie auf Hinzufügen.

Abbildung: Plangruppe hinzufügen MySQL-DB-Backup kopieren
Fügen Sie eine benutzerdefinierte Plangruppe hinzu, um das Datenbankbackup MySQL wiederherzustellen.
1. Klicken Sie auf Gruppe hinzufügen.
2. Geben Sie einen einfachen, aber aussagekräftigen Plangruppen-Namen ein. In diesem Beispiel verwenden wir Restore MySQL DB Backup.
3. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Beispiel wählen Sie Hinzufügen nach aus, um unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe DB-Backup MySQL kopieren einzufügen.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Wiederherstellen des Datenbankbackups der MySQL angeben.
Abbildung: Parameter zum Erstellen von Plangruppenwiederherstellung MySQL DB-Backup

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Restore MySQL DB Backup. Entspricht dem Plangruppennamen.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die WordPress-Anwendung VM1 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM1 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config --switch.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Hinzufügen eines Schritt-Restore-DB-Backups MySQL

Klicken Sie auf Hinzufügen.

Abbildung: Fügen Sie eine Plangruppe hinzu, und stellen Sie das DB-Backup MySQL wieder her
Fügen Sie eine benutzerdefinierte Plangruppe hinzu, um das DNS der MySQL-Datenbank zu aktualisieren.
1. Klicken Sie auf Gruppe hinzufügen.
2. Geben Sie den Namen der einfachen, aber beschreibenden Plangruppe ein. In diesem Beispiel verwenden wir Update MySQL DB DNS.
3. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Beispiel wählen Sie Hinzufügen nach aus, um unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe DB-Backup MySQL wiederherstellen einzufügen.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Aktualisieren des DNS der MySQL-Datenbank angegeben wird.
Abbildung: Parameter zum Erstellen der Plangruppe "MySQL DB DNS aktualisieren"

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Update MySQL DB DNS. Entspricht dem Plangruppennamen.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die WordPress-Anwendung VM1 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM1 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local --remote.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Hinzufügen einer Schrittaktualisierung von MySQL DB-DNS

Klicken Sie auf Hinzufügen.

Abbildung: Fügen Sie eine Plangruppe hinzu, und aktualisieren Sie MySQL DB-DNS
Fügen Sie eine benutzerdefinierte Plangruppe hinzu, um die Quelldatenbank MySQL zu beenden.
1. Klicken Sie auf Gruppe hinzufügen.
2. Geben Sie einen einfachen, aber aussagekräftigen Plangruppen-Namen ein. In diesem Beispiel verwenden wir Terminate MySQL DB Source.
3. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Beispiel wählen Sie Hinzufügen nach aus, um unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe Dateisysteme - Aus DR-Schutzgruppe entfernen einzufügen.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Beenden der Datenbankquelle MySQL angeben.
Abbildung: Parameter zum Erstellen der Plangruppe Beenden der Quell-DB MySQL

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Terminate MySQL Source DB. Entspricht dem Plangruppennamen.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die WordPress-Anwendung VM1 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM1 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/mds_copy_restore_bkp/mds_terminate_db.py mds01.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Hinzufügen eines Schrittes zum Beenden der MySQL-Quell-DB

Klicken Sie auf Hinzufügen.

Abbildung: Fügen Sie eine Plangruppe hinzu. MySQL-Quell-DB beenden
(Optional) Fügen Sie eine benutzerdefinierte Plangruppe hinzu, um die Anwendung WordPress zu stoppen.
1. Klicken Sie auf Gruppe hinzufügen.
2. Geben Sie einen einfachen, aber aussagekräftigen Plangruppen-Namen ein. In diesem Beispiel verwenden wir Application - Stop.
3. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Beispiel wählen Sie Hinzufügen nach aus, um unsere benutzerdefinierte Plangruppe am Ende nach der integrierten Plangruppe Load Balancer - Backend-Sets für Quelle aktualisieren einzufügen.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Stoppen der Anwendung angegeben wird.
Abbildung: Parameter zum Erstellen der Plangruppe Anwendung - Stoppen

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Application - Stop - VM1.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die WordPress-Anwendung VM1 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM1 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/fsdrscripts/wdp_stop.sh.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Erstellen einer Schrittanwendung - Stoppen - VM1

Klicken Sie auf Schritt hinzufügen, um einen zweiten Schritt hinzuzufügen und die Anwendung auf VM2 zu stoppen.

Abbildung: Schrittanwendung hinzufügen - Stoppen - VM2

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Application - Stop - VM2.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die WordPress-Anwendung VM2 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM2 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/fsdrscripts/wdp_stop.sh.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Erstellen einer Schrittanwendung - Stoppen - VM2

Klicken Sie auf Hinzufügen.

Abbildung: Plangruppe hinzufügen Anwendung - Stoppen
(Optional) Fügen Sie eine benutzerdefinierte Plangruppe hinzu, um die Anwendung WordPress zu starten.
1. Klicken Sie auf Gruppe hinzufügen.
2. Geben Sie einen einfachen, aber aussagekräftigen Plangruppen-Namen ein. In diesem Beispiel verwenden wir Application - Start.
3. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. Wählen Sie in diesem Fall Hinzufügen nach aus, um unsere benutzerdefinierte Plangruppe am Ende nach der integrierten Plangruppe Dateisysteme - Auf Compute-Instanzen mounten einzufügen.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Starten der Anwendung angegeben wird.
Abbildung: Parameter zum Erstellen der Plangruppe Anwendung - Starten

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Application - Start - VM1.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Fall wird das Skript für die WordPress-Anwendung VM1 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM1 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/fsdrscripts/wdp_start.sh.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Erstellen einer Schrittanwendung - Start - VM1

Klicken Sie auf Schritt hinzufügen, um einen zweiten Schritt zum Starten der Anwendung auf VM2 hinzuzufügen.

Abbildung: Schrittanwendung hinzufügen - Start - VM2

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Application - Start - VM2.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Fall wird das Skript für die WordPress-Anwendung VM2 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM2 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/fsdrscripts/wdp_start.sh.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Erstellen einer Schrittanwendung - Start - VM2

Klicken Sie auf Hinzufügen.

Abbildung: Plangruppe hinzufügen Anwendung - Starten

Die Anpassung des Switchover-Plans wurde erfolgreich abgeschlossen.

Aufgabe 6: Failover-Plan in Region 2 anpassen

Fügen Sie in dieser Aufgabe benutzerdefinierte DR-Plangruppen und -Schritte hinzu, um die Aufgaben zu verwalten, die während eines Failovers ausgeführt werden müssen.

Stellen Sie das letzte Datenbankbackup in Region 2 wieder her, um die Umgebung für das Switchover vorzubereiten.
Aktualisieren Sie den DNS-Datensatz der privaten Datenbank, sodass sich die Anwendungs-VMs nahtlos bei der Datenbank in Region 2 anmelden können.

Aufgabe 6.1: Failover-Plan auswählen

Navigieren Sie zum Failover-Plan, der in Aufgabe 4 erstellt wurde.

Abbildung: So beginnen Sie mit der Anpassung des Failover-Plans in Bereich 2

Aufgabe 6.2: Plangruppe zum Ausführen benutzerdefinierter Skripte in Region 2 erstellen

Fügen Sie zunächst benutzerdefinierte DR-Plangruppen hinzu, um den DR-Workflow an die spezifischen Anforderungen des DR-Prozesses MySQL anzupassen.

Diese Plangruppen rufen die erforderlichen Skripte von der Anwendungs-VM WordPress auf und müssen im DR-Workflow positioniert werden, bevor die Anwendungs-VMs WordPress neu gestartet werden. Dadurch wird sichergestellt, dass die Datenbank MySQL vollständig wiederhergestellt und betriebsbereit ist, bevor die Anwendungs-VMs online gesetzt werden.

Der folgende benutzerdefinierte Plan sollte dem vorab aufgefüllten Failover-Plan hinzugefügt werden: MySQL Database-Backup wiederherstellen und MySQL Database-DNS aktualisieren.

Fügen Sie eine benutzerdefinierte Plangruppe hinzu, um das Datenbankbackup MySQL wiederherzustellen.
1. Klicken Sie auf Gruppe hinzufügen, um zu beginnen.
2. Geben Sie einen einfachen, aber aussagekräftigen Plangruppen-Namen ein. In diesem Beispiel verwenden wir Restore MySQL DB Backup.
3. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Beispiel wählen Sie Hinzufügen nach aus, um unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe Compute-Instanzen - Starten einzufügen.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Wiederherstellen des Datenbankbackups der MySQL angeben.
Abbildung: Parameter zum Erstellen von Plangruppenwiederherstellung MySQL DB-Backup

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Restore MySQL DB Backup. Entspricht dem Plangruppennamen.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die WordPress-Anwendung VM1 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM1 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Hinzufügen eines Schritt-Restore-DB-Backups MySQL

Klicken Sie auf Hinzufügen.

Abbildung: Fügen Sie eine Plangruppe hinzu, und stellen Sie das DB-Backup MySQL wieder her
Fügen Sie eine benutzerdefinierte Plangruppe hinzu, um das MySQL-Datenbank-DNS zu aktualisieren.
1. Klicken Sie auf Gruppe hinzufügen, um zu beginnen.
2. Geben Sie einen einfachen, aber aussagekräftigen Plangruppen-Namen ein. In diesem Beispiel verwenden wir Update MySQL DB DNS.
3. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Beispiel wählen Sie Hinzufügen nach aus, um unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe DB-Backup MySQL wiederherstellen einzufügen.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Aktualisieren des DNS der MySQL-Datenbank angegeben wird.
Abbildung: Parameter zum Erstellen der Plangruppe "MySQL DB DNS aktualisieren"

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Update MySQL DB DNS. Entspricht dem Plangruppennamen.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die Anwendung WordPress VM1 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM1 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Erstellen von "Schrittaktualisierung hinzufügen" MySQL DB-DNS

Klicken Sie auf Hinzufügen.

Abbildung: Fügen Sie eine Plangruppe hinzu, und aktualisieren Sie MySQL DB-DNS
(Optional) Fügen Sie eine benutzerdefinierte Plangruppe hinzu, um die Anwendung WordPress neu zu starten.
1. Klicken Sie auf Gruppe hinzufügen.
2. Geben Sie einen einfachen, aber aussagekräftigen Plangruppen-Namen ein. In diesem Beispiel verwenden wir Application - Restart.
3. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Beispiel wählen Sie Hinzufügen nach aus, um unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe Dateisysteme - Auf Compute-Instanzen mounten einzufügen.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Starten der Anwendung angegeben wird.
Abbildung: Parameter zum Erstellen der Plangruppe Anwendung - Neustart

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Application - Restart - VM1.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die WordPress-Anwendung VM1 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM1 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/fsdrscripts/wdp_restart.sh.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Erstellen einer Schrittanwendung - Neustart - VM1

Klicken Sie auf Schritt hinzufügen, um einen zweiten Schritt zum Neustart der Anwendung in VM2 hinzuzufügen.

Abbildung: Schrittanwendung hinzufügen - Neu starten - VM2

Geben Sie unter Plangruppenschritt hinzufügen die folgenden Informationen ein.
1. Geben Sie einen einfachen, aber beschreibenden Schrittnamen ein. In diesem Beispiel verwenden wir Application - Start - VM2.
2. Wählen Sie eine Region aus, die die Instanz enthält, auf der dieser Schritt ausgeführt wird. In diesem Beispiel wird das Skript für die WordPress-Anwendung VM2 in Region 1 ausgeführt.
3. Wählen Sie Lokales Skript ausführen aus.
4. Wählen Sie die Zielinstanz aus, bei der es sich um die WordPress-Anwendung VM2 in Region 1 handelt.
5. Geben Sie unter Skriptparameter den vollständigen Pfad des Skripts mit den Parametern ein. Beispiel: /home/opc/fsdrscripts/wdp_restart.sh.
6. Geben Sie unter Als Benutzer ausführen den Wert opc ein.
7. Klicken Sie auf Schritt hinzufügen.
Abbildung: Parameter zum Erstellen einer Schrittanwendung - Neustart - VM2

Klicken Sie auf Hinzufügen.

Abbildung: Plangruppe hinzufügen Anwendung - Neustart

Die Anpassung des Failover-Plans wurde erfolgreich abgeschlossen.

Aufgabe 7: Vorabprüfungen in Region 2 ausführen

Sowohl Switchover- als auch Failover-DR-Pläne wurden in der Standbyregion 2 erfolgreich erstellt. Mit diesen Plänen kann OCI Full Stack DR Workloads von Region 1 in Region 2 überführen. Die nachfolgende Aufgabe umfasst die Ausführung der Vorabprüfungen für Switchover- und Failover-Pläne, um die Bereitschaft sicherzustellen und den Übergangsprozess zu validieren.

Aufgabe 7.1: Vorabprüfungen für den Switchover-Plan starten

Führen Sie Vorabprüfungen für den Switchover-DR-Plan aus.

Stellen Sie sicher, dass der Regionskontext auf Standbyregion 2 gesetzt ist.
Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standbyrolle sein.
Klicken Sie auf den Namen des Switchover-Plans.
Klicken Sie auf Vorabprüfungen ausführen.

Abbildung: Zeigen, wie Vorabprüfungen des Switchover-Plans ausgeführt werden

Abbildung: Abgeschlossene Vorabprüfungen des Switchover-Plans anzeigen

Aufgabe 7.2: Vorabprüfungen für den Failover-Plan starten

Führen Sie die Vorabprüfungen für den Failover-DR-Plan aus.

Stellen Sie sicher, dass der Regionskontext auf Standbyregion 2 gesetzt ist.
Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standbyrolle sein.
Klicken Sie auf den Namen des Failover-Plans.
Klicken Sie auf Vorabprüfungen ausführen.

Abbildung: So führen Sie Vorabprüfungen des Failover-Plans aus

Abbildung: Abgeschlossene Vorabprüfungen des Failover-Plans anzeigen

Aufgabe 8: Switchover-Plan in Region 2 ausführen

Führen Sie den Switchover-DR-Plan aus, um mit dem Übergang der Anwendung WordPress mit Oracle HeatWave MySQL von Region 1 in Region 2 zu beginnen.

Stellen Sie sicher, dass der Regionskontext auf Standbyregion 2 gesetzt ist.
Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standbyrolle sein.
Klicken Sie auf den Namen des Switchover-Plans.
Klicken Sie auf Plan ausführen.

Mit dieser Aufgabe wird der Switchover-Plan in Region 2 ausgeführt.

Heben Sie die Auswahl von Vorabprüfungen aktivieren auf, da sie bereits in Aufgabe 7 ausgeführt wurden.
Klicken Sie auf DR-Plan ausführen, um zu beginnen.

Abbildung: Zeigen, wie der Switchover-Plan ausgeführt wird

Abbildung: Zeigt den Switchover-Plan in Bearbeitung an

Überwachen Sie den Switchover-Plan, bis die vollständige Workload vollständig von Region 1 in Region 2 überführt wurde.

Die Ausführung des Switchover-Plans wurde in ca. 52 Minuten erfolgreich abgeschlossen.

Abbildung: Eine abgeschlossene Switchover-Planausführung wird angezeigt.

Aufgabe 9: DR-Pläne in Region 1 erstellen und anpassen

Mit dem erfolgreichen Abschluss des Switchovers durch OCI Full Stack DR hat Region 2 jetzt die Rolle der primären Region übernommen, während Region 1 als Standbyregion übergegangen ist.

Befolgen Sie den in Aufgabe 1 bis 8 beschriebenen Ansatz, und erstellen und passen Sie die Switchover- und Failover-Pläne innerhalb der DR-Schutzgruppe für Region 1 an, die jetzt als Standby-Peer-Region dient.

Abbildung: Screenshot mit erstellten Plänen in Region 1

Abbildung: Screenshot mit dem Switchover-Plan in Region 1

Abbildung: Screenshot mit Failover-Plan in Region 1

Nächste Schritte

Weitere Informationen finden Sie in der Dokumentation zu OCI Full Stack DR und Oracle HeatWave MySQL im Abschnitt Zugehörige Links.

Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery
Oracle HeatWave MySQL
OCI Full Stack Disaster Recovery
HeatWave MySQL
Slack Channel #full-stack-dr beitreten

Danksagungen

Autor - Antoun Moubarak (Hyperscaler zu OCI Specialist)
Mitwirkender – Suraj Ramesh (Produktmanager für OCI Full Stack DR)

Weitere Lernressourcen

Sehen Sie sich andere Übungen zu docs.oracle.com/learn an, oder greifen Sie im Oracle Learning YouTube-Channel auf weitere kostenlose Lerninhalte zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.

Titel und Copyright-Informationen

Automate Cold Disaster Recovery for Oracle HeatWave MySQL using OCI Full Stack Disaster Recovery

G24408-01

January 2025

Oracle und/oder verbundene Unternehmen.