Hinweis:

• Dieses Tutorial erfordert Zugriff auf Oracle Cloud. Informationen zum Registrieren eines kostenlosen Accounts finden Sie unter Erste Schritte mit Oracle Cloud Infrastructure Free Tier.
• Es verwendet Beispielwerte für Oracle Cloud Infrastructure-Zugangsdaten, -Mandanten und -Compartments. Wenn Sie Ihre Übung abgeschlossen haben, ersetzen Sie diese Werte durch spezifische Werte für Ihre Cloud-Umgebung.

Automatisierung der Wiederherstellung für Oracle Analytics Cloud mit OCI Full Stack Disaster Recovery

Teil 1 - Einführung

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

Oracle Analytics Cloud (OAC) ist ein verwaltetes OCI Platform-as-a-Service-Angebot (PaaS). Full Stack DR kann nicht nativ verwaltet werden, da OAC selbst OCI-Benutzern keine Compute-, Speicher- oder Datenbankressourcen zur Verfügung stellt. Full Stack DR kann jedoch die Wiederherstellung für PaaS-Angebote automatisieren, solange das Entwicklungsteam für einen bestimmten Service wie OAC eine Möglichkeit dokumentiert hat, seinen Service für die Disaster Recovery zwischen OCI-Regionen bereitzustellen und wiederherzustellen. Das OAC-Engineering-Team hat Disaster-Recovery-Konfiguration für Oracle Analytics Cloud geschrieben und erläutert, wie Sie OAC manuell bereitstellen und wiederherstellen.

Full Stack DR wird nicht zur Installation, Konfiguration oder Bereitstellung von Oracle Analytics Cloud (OAC) verwendet, einschließlich Networking, Compute, Speicher, Speicherreplikation, Datenbanken oder der OAC-Anwendung/-Service selbst. OAC muss vollständig für DR über Regionen hinweg bereitgestellt werden, indem Sie die Schritt-für-Schritt-Anweisungen unter Disaster-Recovery-Konfiguration für Oracle Analytics Cloud befolgen, bevor Sie versuchen, Full Stack DR in irgendeiner Weise zu verwenden.

Die manuellen Wiederherstellungsschritte, die vom OAC-Engineering in der Disaster-Recovery-Konfiguration für Oracle Analytics Cloud beschrieben werden, müssen auch erfolgreich auf Switchover und Switchback getestet werden (in der OAC-Dokumentation auch als Fallback bezeichnet), bevor Full Stack DR verwendet wird.

OAC ist normalerweise Teil eines größeren Systems

In diesem Tutorial wird davon ausgegangen, dass Oracle Analytics Cloud die einzige Anwendung ist, die den DR-Schutzgruppen hinzugefügt wird. Dies ist nicht normal.

Dieses Tutorial ist in der Tatsache ungewöhnlich, dass nur OAC im gesamten Dokument angezeigt und diskutiert wird, um die Dinge einfach zu halten. Normalerweise ist OAC nur ein kleiner Teil eines viel größeren, komplexeren Geschäftssystems, das viele verschiedene Services und Anwendungen in einer einzelnen Full Stack DR-Schutzgruppe und einer Reihe von DR-Plänen umfasst. Es ist sehr wahrscheinlich, dass Sie ähnliche Oracle Help Center-Tutorials für andere Anwendungen und Services wie PeopleSoft, WebLogic Server, Oracle Integration Cloud usw. befolgen.

Dieses Tutorial zeigt nur, wie Sie Oracle Analytics Cloud selbst implementieren, weil wir den Leser nicht überfordern möchten, indem wir zu viele bewegliche Teile und Teile vorstellen. Dieses Tutorial zeigt OAC an sich, um Verwirrung zu vermeiden und sich auf das zu konzentrieren, was zur Automatisierung der Wiederherstellung für Oracle Analytics Cloud erforderlich ist.

Vorsicht bei der schrittweisen Implementierung

Wenn Sie einer DR-Schutzgruppe nach dem Erstellen von DR-Plänen weitere Mitglieder hinzufügen, werden alle vorhandenen DR-Pläne in den Schutzgruppen in beiden Regionen gelöscht.

Full Stack DR wurde unter der Annahme entwickelt, dass der gesamte Anwendungsstack für ein bestimmtes Geschäftssystem bereits in OCI-Regionen bereitgestellt ist und manuelle DR bereits funktioniert. Wenn Ihr Geschäftssystem mehr als OAC enthält, fügen Sie alle Mitglieder für alle anderen Anwendungen oder OCI-Services zu den DR-Schutzgruppen hinzu, bevor Sie DR-Pläne erstellen.

Funktionsweise der Wiederherstellung

Die Recovery-Lösung für OAC erfordert Full Stack DR, um eine Reihe benutzerdefinierter bash-Skripte während eines Recovery-Vorgangs wie Failover oder Switchover auszuführen. Die in diesem Tutorial referenzierten Skripte werden vom North American Analytics Specialists-Team bereitgestellt und sind in einem GitHub-Repository verfügbar, das speziell auf diese OAC DR-Lösung zugeschnitten ist. Die bash-Skripte werden in eine Compute-Instanz heruntergeladen, die Teil des Anwendungsstacks ist, den Full Stack DR während eines Recovery-Vorgangs verwaltet.

In diesem Tutorial wird erläutert, wie Sie die Skripte herunterladen und in einem späteren Schritt verwenden. Dieses Tutorial verwendet Option 2 unten nur zum Hosten der bash-Skripte, da das Tutorial nichts anderes als OAC enthält.

Option 1 für Hosting-Skripte

OAC ist meistens Teil eines größeren, komplexeren Geschäftssystems, das eine Anwendung wie Oracle E-Business Suite, PeopleSoft oder JD Edwards Enterprise sowie andere Datenbanken, Compute-Instanzen und selbst entwickelte Anwendungen umfasst. In diesem Fall wählen Sie einfach eine der "beweglichen" Compute-Instanzen, die bereits Teil des Geschäftssystems sind, um die Skripte zu hosten. Bei der ausgewählten Compute-Instanz kann es sich um einen beliebigen Ort handeln, an dem Oracle Linux installiert ist. Wahrscheinlich handelt es sich um eine vorhandene VM, die einem anderen Zweck dient, wie einem Anwendungsserver oder einem Admin-Server irgendeiner Art.

In diesem Tutorial wird diese bestimmte Compute-Instanz als Kontrollknoten oder DR-Knoten bezeichnet, obwohl sie einen anderen Zweck im Anwendungsstack erfüllt.

Option 2 für Hosting-Skripte

Wenn dies ein ungewöhnlicher Fall ist, bei dem OAC der einzige Anwendungsservice ist, den Full Stack DR während eines Recovery-Vorgangs verwalten wird, muss eine Compute-Instanz nur zum Hosten der Skripte erstellt werden.

Normalerweise erfordert Full Stack DR keine spezialisierten Verwaltungsserver, um Wiederherstellungsvorgänge zu automatisieren. Sie erstellen jedoch eine Compute-Instanz, die in diesem Fall als spezialisierter Verwaltungsserver fungiert, da OAC nicht nativ von Full Stack DR verwaltet werden kann. Der spezialisierte Management-Server wird in diesem Dokument als Kontrollknoten oder DR-Knoten angezeigt. Der gesamte Zweck des Kontrollknotens besteht darin, einfach als Server zu fungieren, auf dem benutzerdefinierte Skripte gespeichert und von Full Stack DR während eines Recovery-Vorgangs aufgerufen werden können. In diesem Tutorial wird erläutert, wie Sie benutzerdefinierte, benutzerdefinierte DR-Plangruppen und -schritte im Rahmen Ihrer DR-Pläne zum Aufrufen der auf dem Kontrollknoten installierten Skripte erstellen.

OAC-Deployment-Architektur

Oracle Analytics Cloud (OAC) muss zuerst für Disaster Recovery (DR) in OCI-Regionen bereitgestellt werden, bevor Full Stack DR eingeführt werden kann. Es ist äußerst wichtig, dass die manuellen Schritte zum Wiederherstellen von OAC gemäß der Dokumentation des OAC-Engineering getestet werden und ordnungsgemäß funktionieren, bevor versucht wird, den Wiederherstellungsprozess mit Full Stack DR zu automatisieren.

Beim Deployment von OAC für DR in OCI-Regionen kann eine der folgenden beiden Referenzarchitekturen befolgt werden. Beide Referenzarchitekturen veranschaulichen eine Multi-Tier-Topologie mit redundanten Ressourcen, die über zwei OCI-Regionen verteilt sind.

Option 1: Öffentliche OAC-Instanz bereitstellen

Eine öffentliche Oracle Analytics Cloud-Instanz befindet sich im Oracle Service Network und kann direkt über das Internet aufgerufen werden. Die öffentliche IP-Adresse von Oracle Analytics Cloud wird direkt mit dem DNS-Registrar konfiguriert.

Abbildung 1: OIC-Referenzarchitektur bei Verwendung öffentlicher OAC-Instanzen

Option 2: Private OAC-Instanz bereitstellen

Auf eine private Oracle Analytics Cloud-Instanz kann nicht über das öffentliche Internet zugegriffen werden. Daher ist ein öffentlicher OCI Load Balancer erforderlich, um den Zugriff zu erleichtern. Die IP-Adresse des öffentlichen Load Balancers wird dem DNS-Registrar hinzugefügt.

Abbildung 2: OIC-Referenzarchitektur bei Verwendung privater OAC-Instanzen

Full Stack DR-Deployment-Architektur

Die folgenden Abbildungen zeigen die Compute-Ressourcen, die jeder DR-Schutzgruppe (DRPG) für Full Stack-DR als Mitglieder hinzugefügt wurden. Diese stellen die verschiedenen Komponenten dar, die Full Stack DR außerhalb des Oracle Analytics Cloud-Service (OAC) verwalten kann.

In keiner der unten gezeigten DRPG-Referenzarchitekturen werden andere OAC-Komponenten als Autonomous Data Warehouse (ADW) angezeigt, da OAC PaaS für Full Stack DR nicht sichtbar ist. Daher wird nichts anderes als ADW zu DRPGs in beiden Regionen hinzugefügt.

Full Stack DR verfügt über eine integrierte Automatisierung zur Verarbeitung von Compute-, Blockspeicher-, Dateispeicher-, Oracle-Datenbanken, Load Balancern und vielen anderen Ressourcen während eines Recoverys, verfügt jedoch nicht über eine integrierte Automatisierung für OAC selbst. Das OAC-Recovery wird von einer Reihe von bash-Skripten gesteuert, die aus einem für dieses Tutorial dedizierten GitHub-Repository heruntergeladen werden können. Die bash-Skripte müssen auf einer Compute-Instanz Ihrer Wahl installiert werden, indem Sie eine der folgenden Optionen für die Platzierung und Kontrolle der Skripte befolgen.

Option 1: Automatisierung der Wiederherstellung für OAC als eigenständige Anwendung

Diese Deployment-Architektur ist nicht typisch und wurde für sehr seltene Situationen entwickelt, in denen OAC die einzige Anwendung ist, die von Full Stack DR wiederhergestellt wird. In diesem Fall wird eine spezialisierte Compute-Instanz, die unten als DR-Knoten angezeigt wird, erstellt, um die benutzerdefinierten bash-Skripte zu hosten, die Full Stack DR aufruft, um das Recovery von OAC zu verwalten.

Abbildung 3: Full Stack DR-Deployment-Architektur, die einen speziellen DR-Kontrollknoten erfordert

Option 2: Automatisierung der Wiederherstellung für OAC als Teil eines Anwendungsstacks

Die in Abbildung 4 dargestellte vereinfachte Bereitstellungsarchitektur ist ein Beispiel für eine häufigere Bereitstellung von OAC, bei der es sich einfach um eine Komponente eines größeren, komplexeren Anwendungsstacks handelt, bei dem viele Services und Anwendungen gemeinsam wiederhergestellt werden müssen. Die meisten Geschäftssysteme sind viel komplexer als die unten gezeigte fiktive und umfassen in der Regel zusätzliche Datenbanken, andere Oracle- und/oder Nicht-Oracle-Anwendungen sowie andere OCI-Services wie OIC, ODI, OHS, IAM usw.

In diesem Fall ist es nicht erforderlich, einen speziellen DR-Knoten wie den in Abbildung 3 oben gezeigten zu erstellen. Die benutzerdefinierten bash-Skripte, mit denen das Recovery von OAC verwaltet wird, können auf einem der Server installiert werden, die in Abbildung 4 unten als bewegliches Compute dargestellt sind.

Abbildung 4: Full Stack DR-Deployment-Architektur, ohne dass ein spezieller DR-Kontrollknoten erforderlich ist

Den gesamten Prozess kennen lernen

Das Full Stack Disaster Recovery-Engineering-Team hat eine Reihe von Begleitvideos für dieses Tutorial erstellt, um den gesamten Prozessablauf zu verstehen. Diese Videos sind Teil einer YouTube-Wiedergabeliste, auf die über die folgenden Links zugegriffen werden kann:

• Video 1: Oracle Analytics Cloud für DR bereitstellen
• Video 2: Wiederherstellung für Oracle Analytics Cloud automatisieren
• Video 3: Skripte zur Automatisierung der Wiederherstellung für Oracle Analytics Cloud

Teil 2 - Schritt-für-Schritt-Anweisungen

Dieser Teil beginnt mit den Schritt-für-Schritt-Anweisungen, die zum Hinzufügen von Oracle Analytics CLoud zu Full Stack DR erforderlich sind.

Ziele dieses Tutorials

In diesem Tutorial wird erläutert, wie Sie das Recovery für Oracle Analytics Cloud (OAC) mit Full Stack DR automatisieren:

1. Aufgabe 1: OAC für DR über OCI-Regionen hinweg bereitstellen
   1. OAC DR-Kontrollknoten vorbereiten
   2. Benutzerdefinierte Skripte auf den DR-Kontrollknoten herunterladen
   3. OAC für DR manuell in zwei OCI-Regionen installieren und bereitstellen
   4. Alle Recovery-Schritte aus der gewünschten Region 1 in die Region 2 manuell testen
   5. Alle Recovery-Schritte aus der gewünschten Region 2 in die Region 1 manuell testen
2. Aufgabe 2: Full Stack DR vorbereiten
   1. IAM-Policys für Full Stack DR erstellen
   2. IAM-Policys für andere OCI-Services erstellen
   3. Objektspeicher-Buckets für Logs erstellen
3. Aufgabe 3: DR-Schutzgruppen (DRPG) erstellen
4. Aufgabe 4: Mitglieder zu DRPGs für Region 1 und Region 2 hinzufügen
5. Aufgabe 5: Grundlegende DR-Pläne in Region 2 erstellen (Phoenix)
   1. Switchover-Plan erstellen
   2. Failover-Plan erstellen
6. Aufgabe 6: Switchover-Plan in Region 2 anpassen (Phoenix)
7. Aufgabe 7: Failover-Plan in Region 2 anpassen (Phoenix)
8. Aufgabe 8: Switchover-Plan in Region 2 ausführen (Phoenix)
9. Aufgabe 9: Grundlegende DR-Pläne in Region 1 (Ashburn) erstellen
   1. Switchover-Plan erstellen
   2. Failover-Plan erstellen
10. Aufgabe 10: Switchover-Plan in Region 1 (Ashburn) anpassen
11. Aufgabe 11: Failover-Plan in Region 1 (Ashburn) anpassen

Definitionen & Annahmen im gesamten Tutorial

Bereiche

• Region 1 ist Ashburn
  • Ashburn wird als primäre Region beginnen.
  • Diese Rolle wechselt schließlich zu Standby, nachdem Sie angewiesen wurden, ein Switchover in späteren Schritten auszuführen.
• Region 2 ist Phoenix
  • Phoenix beginnt als Standby-Region.
  • Diese Rolle wird schließlich in "Primär" geändert, nachdem Sie angewiesen wurden, ein Switchover in späteren Schritten auszuführen.

Compartments

Sie können OAC und Full Stack DR in jedem Compartment-Schema organisieren, das Ihren Standards für IT-Governance entspricht. Wir haben uns entschieden, Anwendungen in ihren eigenen individuellen Compartments zu organisieren und dann alle DR-Schutzgruppen in einem einzigen Compartment zu organisieren, in dem ganz unterschiedliche Geschäftssysteme auf einen Blick zu sehen sind.

• Die Organisation aller DR-Schutzgruppen in einem einzigen Compartment, abgesehen von den Anwendungen, macht es IT-Mitarbeitern viel einfacher, DR-Pläne für viele völlig verschiedene Geschäftssysteme zu finden und auszuführen.
• Ein einzelnes Compartment für alle DR-Schutzgruppen hilft dabei, menschliche Fehler zu beseitigen und erhöht die Geschwindigkeit, mit der DR-Pläne gefunden und ausgeführt werden können
  • Compartment für Oracle Analytics Cloud: oac-demo. Das Compartment für OAC selbst, Speicher, Speicher-Buckets, Compute und Datenbanken im Zusammenhang mit OAC ist in diesem Tutorial oac-demo.
  • Compartment für Full Stack-DR: myprojects_NA. Das Compartment für Full Stack-DR-Schutzgruppen und -Pläne ist in diesem Tutorial myprojects_NA.

OAC DR-Kontrollknoten

Der DR-Kontrollknoten ist eine beliebige Compute-Instanz, die Sie zum Hosten benutzerdefinierter bash-Skripte angeben, die bestimmte Aufgaben zum Wiederherstellen von OAC ausführen. Die Skripte werden von Full Stack DR während eines Recovery-Vorgangs aufgerufen. In diesem Tutorial wird erläutert, wie Sie die Skripte in den Schritten 6, 7, 10 und 11 zu Full Stack DR hinzufügen.

• Bei OAC als Standalone-Anwendung: Dies ist eine spezialisierte Compute-Instanz, die Sie erstellen, um als Host für die benutzerdefinierten Skripte zu fungieren
• Für OAC als Teil eines Anwendungsstacks: Dies ist eine vorhandene Compute-Instanz, die Mitglied einer DR-Schutzgruppe (DRPG) ist. Beispiel: Oracle E-Business Suite oder PeopleSoft enthält Anwendungsserver, die Mitglieder derselben DRPGs sind, die das Recovery für OAC verwalten. Jeder dieser Server kann in diesem Tutorial die Rolle des DR-Kontrollknotens erfüllen.

Voraussetzungen

Oracle Analytics Cloud sollte für das Disaster Recovery in beiden Regionen bereitgestellt werden, bevor Sie mit der Arbeit mit Full Stack DR beginnen. Dies wird in Aufgabe 1 unten behandelt.

Aufgabe 1: Oracle Analytics Cloud für Disaster Recovery bereitstellen

Full Stack DR ist an keinem Teil dieses Schritts beteiligt.

Aufgabe 1.1: DR-Kontrollknoten für die Ausführung der benutzerdefinierten Automatisierung vorbereiten

Geben Sie eine Compute-Instanz an, die als DR-Kontrollknoten für OAC fungiert. Dabei kann es sich um eine vorhandene Compute-Instanz oder um eine Compute-Instanz handeln, die nur für diesen Zweck erstellt wurde. Weitere Einzelheiten finden Sie in den folgenden Optionen. Stellen Sie sicher, dass die Compute-Instanzen, die als DR-Kontrollknoten fungieren, für die Ausführung von Befehlen mit dem OCI Cloud Agent konfiguriert wurden: Befehle auf einer Instanz ausführen.

Option 1: OAC als Standalone-Anwendung

In diesem Tutorial wird davon ausgegangen, dass OAC ein Standalone-Service ist. Daher erstellen Sie eine Compute-Instanz mit Oracle Linux in Region 1. Verwenden Sie die kostengünstigste Ausprägung mit Oracle Linux, da sie nur zum Hosten der benutzerdefinierten bash-Skripte verwendet wird. Die Notwendigkeit einer speziellen Compute-Instanz zur Erfüllung dieser Rolle ist ungewöhnlich. Option 2 ist das häufigste Szenario für eine Mehrheit der Unternehmen.

Die spezialisierte Compute-Instanz wird in einem späteren Schritt als Mitglied der DR-Schutzgruppe in Region 1 hinzugefügt.

Option 2: OAC als Teil eines Anwendungsstacks

Sie können jedes einzelne vorhandene bewegliche Compute verwenden, das Teil einer beliebigen Oracle- oder Nicht-Oracle-Anwendung ist, die von Full Stack DR in Region 1 verwaltet wird. Dies erfüllt die Rolle des DR-Kontrollknotens jedes Mal, wenn dieses Tutorial den DR-Kontrollknoten referenziert.

Am besten verwenden Sie eine bewegliche Compute-Instanz. Sie können jedoch auch eine nicht bewegliche Compute-Instanz in Region 1 und eine andere in Region 2 angeben, wenn Sie keine beweglichen Compute-Instanzen als Teil Ihrer DR-Lösung haben. Sie müssen alle Änderungen, die Sie an Skripten oder dem Gast-BS in beiden Regionen vornehmen, beibehalten, wenn für diese Rolle nicht bewegliches Compute verwendet wird.

Option 3: OAC als Teil eines Anwendungsstacks mit mehreren PaaS-Angeboten

Möglicherweise verfügt Ihr Business-System auch über Oracle HTTP Server (OHS), Oracle Integration Cloud (OIC) und Oracle Data Integrator (ODI). In diesem Fall können Sie eine spezialisierte Compute-Instanz wie bei Option 1 zum Hosten von DR-Recovery-Skripten für alle verschiedenen PaaS-Services erstellen.

Aufgabe 1.2: Stellen Sie sicher, dass die Volume-Gruppe in Region 2 repliziert wird

Stellen Sie sicher, dass das Boot-Volume für den DR-Kontrollknoten Mitglied einer Block-Volume-Gruppe ist und die Block-Volume-Gruppe in Region 2 repliziert wird.

Stellen Sie sicher, dass alle anderen Boot- und Blockdateien, die zu anderen beweglichen Compute-Instanzen für dieses Full Stack-DR-Projekt gehören, auch zu Block-Volume-Gruppen gehören, die in Region 2 repliziert werden.

Aufgabe 1.3: bash-Skripte auf DR-Kontrollknoten herunterladen

Laden Sie die benutzerdefinierten bash-Skripte von github herunter, die speziell für diese OAC DR-Lösung geschrieben wurden. Die unten gezeigten Skripte müssen in jedes Unterverzeichnis auf der Compute-Instanz kopiert werden, das als DR-Kontrollknoten für OAC fungiert

Der obige Link muss in das Repository GitHub aufgelöst werden:

1. Dadurch wird der Repository-Pfad angezeigt, in dem sich die bash-Skripte auf GitHub befinden.
2. Dadurch wird das Repository mit den bash-Skripten angezeigt.

Abbildung 2-4: Screenshot des Github-Repositorys mit bash-Skripten für OAC

Aufgabe 1.4: Oracle Analytics Cloud für DR bereitstellen

Stellen Sie Oracle Analytics Cloud für DR über OCI-Regionen hinweg bereit, indem Sie die Schritt-für-Schritt-Anweisungen in den folgenden Dokumenten befolgen:

1. Oracle Blog zur Erläuterung der Lösung: Disaster-Recovery-Plan für Oracle Analytics Cloud mit manueller Switchover-Methode.
2. Oracle Technical Paper von OAC engineering: Disaster Recovery Configuration for Oracle Analytics Cloud.
3. Oracle Architecture Center-Referenzarchitektur von Data Platform-Cloud-Architekten: Entwerfen Sie eine Oracle Analytics Cloud-DR-Topologie mit Full Stack Disaster Recovery Service.

Aufgabe 1.5: Recovery von Oracle Analytics Cloud manuell testen

Es ist eine Best Practice, die manuellen Wiederherstellungsschritte sicherzustellen. Die in der Disaster-Recovery-Konfiguration für Oracle Analytics Cloud dokumentierten manuellen Schritte zum Wiederherstellen von OAC müssen erfolgreich sein, bevor Sie mit Full Stack DR arbeiten können.

Aufgabe 1.6: Nächste Schritte

Kehren Sie zu diesem Dokument zurück, um mit der Arbeit mit Full Stack DR zu beginnen, sobald die folgenden Anforderungen erfüllt sind.

1. Stellen Sie OAC für DR manuell in zwei gewünschten OCI-Regionen bereit.
2. Testen Sie manuell alle Wiederherstellungsschritte von Region 1 (Ashburn) bis Region 2 (Phoenix).
3. Testen Sie manuell alle Wiederherstellungsschritte von Region 2 (Phoenix) bis Region 1 (Ashburn).

Aufgabe 2: Full Stack Disaster Recovery vorbereiten

Full Stack DR ist an keinem Teil dieses Schritts beteiligt. Die folgenden Schritte bereiten den Mandanten, das Compartment, OCI-Services und OAC für die automatisierte Wiederherstellung durch Full Stack DR vor.

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

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

• Policys für Full Stack Disaster Recovery.
• Identity and Access Management-(IAM-)Policys konfigurieren, die für Full Stack Disaster Recovery erforderlich sind.

Aufgabe 2.2: IAM-Policys für andere Services erstellen, die von Full Stack DR verwaltet werden

Full Stack DR muss die Möglichkeit haben, andere wichtige OCI-Services wie Compute, Networking, Storage, Vaults, Datenbanken und andere verschiedene Services zu steuern und zu verwalten. Konfigurieren Sie die erforderlichen OCI-IAM-Policys für andere Services, wie im folgenden Dokument beschrieben.

• Policys für andere von Full Stack Disaster Recovery verwaltete Services.

Aufgabe 2.3: Speicher-Buckets für DRPG-Logs erstellen

Hinweis: Überspringen Sie Aufgabe 2.3 vollständig, wenn Sie OAC zu vorhandenen DR-Schutzgruppen hinzufügen.

Erstellen Sie Object Storage-Buckets in der Primär- und Standbyregion, um Logs zu speichern, die von Full Stack DR bei Recovery-Vorgängen generiert wurden: Object Storage.

Aufgabe 2.3.1: Zu OCI Object Storage navigieren

Navigieren Sie zu Object Storage und Archive Storage, wie in Abbildung 2-1 unten dargestellt.

1. Stellen Sie sicher, dass der Browserkontext auf Region 1 (Ashburn) festgelegt ist.
2. Speicher wählen.
3. Wählen Sie "Buckets".

Abbildung 2-1: Navigieren Sie zum Objektspeicher

Aufgabe 2.3.2: OCI-Speicher-Bucket in Region 1

Erstellen Sie einen Objektspeicher-Bucket in Region 1. Der Bucket wird in einem späteren Schritt der DR-Schutzgruppe in Region 1 zugewiesen.

1. Wählen Sie das Compartment aus, das OAC-bezogene Ressourcen enthält.
2. Wählen Sie "Create Bucket" aus.
3. Geben Sie dem Bucket einen aussagekräftigen Namen, der leicht identifiziert, für welche Anwendung und welchen Zweck er dient. Es gibt keinen Grund, die Region als Teil des Namens einzuschließen. Beispiel: Dieser Name gibt an, dass er für die Full Stack-DR-Logs verwendet wird, die sich auf DR-Vorgänge für OAC beziehen.
4. Verwenden Sie den Standardwert für Tier und Verschlüsselung.
5. Wählen Sie "Erstellen", um den Bucket zu erstellen.

Abbildung 2-2: Objektspeicher-Bucket in Region 1 erstellen

Aufgabe 2.3.3: OCI-Speicher-Bucket in Region 2

Führen Sie denselben Prozess aus, um einen Objektspeicher-Bucket in Region 2 (Phoenix) zu erstellen. Der Bucket wird in einem späteren Schritt der DR-Schutzgruppe in Region 2 zugewiesen.

1. Ändern Sie den Kontext in Region 2.
2. Wählen Sie das Compartment aus, das OAC-bezogene Ressourcen in Region 2 enthält.
3. Verwenden Sie denselben exakten Namen, der dem Bucket in Region 1 zugewiesen wurde. Dies erleichtert die Identifizierung in einem späteren Schritt.
4. Wählen Sie "Erstellen", um den Bucket zu erstellen.

Abbildung 2-3: Objektspeicher-Bucket in Region 2 erstellen

Aufgabe 3: DR-Schutzgruppen in beiden Regionen erstellen

Hinweis: Überspringen Sie Aufgabe 3 vollständig, wenn OAC vorhandenen DR-Schutzgruppen hinzugefügt wird.

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

Aufgabe 3.1: Zu DR-Schutzgruppen navigieren

Navigieren Sie zunächst zu DR-Schutzgruppen (Full Stack DR), wie in Abbildung 3-1 unten dargestellt.

1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 1 (Ashburn) festgelegt ist.
2. Wählen Sie "Migration und Disaster Recovery" aus.
3. Wählen Sie DR-Schutzgruppen aus.

Abbildung 3-1: Zu DR-Schutzgruppen navigieren

Aufgabe 3.2: Schutzgruppe in Region 1 erstellen

Erstellen Sie eine DR-Basisschutzgruppe (DRPG) in Region 1, wie in Abbildung 3-2 unten dargestellt. Peer, Rolle und Mitglieder werden in späteren Schritten zugewiesen.

1. Wählen Sie das Compartment aus, in dem das DRPG erstellt werden soll. Dies kann dasselbe Compartment sein, in dem OAC-Ressourcen vorhanden sind, oder wie in diesem Fall ein Compartment, das als Repository fungiert und DRPGs für viele verschiedene Geschäftssysteme enthält.
2. Wählen Sie "DR-Schutzgruppe erstellen", um das Dialogfeld zu öffnen.

Abbildung 3-2: Erstellen der DR-Schutzgruppe in Region 1 beginnen

Fügen Sie einen Namen und einen Objektspeicher-Bucket für die Logs hinzu, wie in Abbildung 3-3 unten dargestellt.

1. Verwenden Sie einen aussagekräftigen, einfachen Namen für DRGP. Dieses Beispiel zeigt den Namen des Geschäftssystems und der Region.
2. Wählen Sie den in Aufgabe 2 erstellten Objektspeicher-Bucket für Region 1 aus.

Abbildung 3-3: Erforderliche Parameter zum Erstellen einer DR-Schutzgruppe in Region 1

Aufgabe 3.3: Schutzgruppe in Region 2 erstellen

Erstellen Sie eine DR-Basisschutzgruppe (DRPG) in Region 2, wie in Abbildung 3-4 unten dargestellt. Peer, Rolle und Mitglieder werden in späteren Schritten zugewiesen.

1. Ändern Sie den OCI-Regionskontext in Region 2.
2. Wählen Sie das Compartment aus, in dem das DRPG erstellt werden soll. Dies kann dasselbe Compartment sein, in dem OAC-Ressourcen vorhanden sind, oder wie in diesem Fall ein Compartment, das als Repository fungiert und DRPGs für viele verschiedene Geschäftssysteme enthält.
3. Wählen Sie "DR-Schutzgruppe erstellen", um das Dialogfeld zu öffnen.

Abbildung 3-4: Erstellen der DR-Schutzgruppe in Region 2 beginnen

Fügen Sie einen Namen und einen Objektspeicher-Bucket für die Logs hinzu, wie in Abbildung 3-5 unten dargestellt.

1. Verwenden Sie einen aussagekräftigen, einfachen Namen für DRGP. Dieses Beispiel zeigt den Namen des Geschäftssystems und der Region.
2. Wählen Sie den in Aufgabe 2 erstellten Objektspeicher-Bucket für Region 2 aus

Abbildung 3-5: Erforderliche Parameter zum Erstellen einer DR-Schutzgruppe in Region 2

Aufgabe 3.4: Schutzgruppen in Region 1 und Region 2 zuordnen

Verknüpfen Sie die DRPGs in jeder Region als Peers voneinander, und weisen Sie die Peerrollen der Primär- und Standbydatenbank zu. So weiß Full Stack DR, welche zwei Regionen für das OAC-Recovery zusammenarbeiten. Die Rollen der Primär- und Standbydatenbank werden automatisch von Full Stack DR im Rahmen einer DR-Vorgang-/DR-Planausführung geändert. Es ist nicht erforderlich, die Rollen jederzeit manuell zu verwalten.

Aufgabe 3.4.1: Beginn der Zuordnung

1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 1 (Ashburn) festgelegt ist.
2. Wählen Sie "Verknüpfen", um den Prozess zu starten.

Abbildung 3-6: DRPG-Verknüpfung beginnen

Aufgabe 3.4.2: Schutzgruppen in Region 1 und Region 2 zuordnen

Geben Sie die Parameter an, wie in Abbildung 3-7 unten dargestellt.

1. Wählen Sie die primäre Rolle aus. Full Stack DR weist die Standbyrolle automatisch Region 2 zu.
2. Wählen Sie Region 2 (Phoenix), in der das andere DRPG erstellt wurde.
3. Wählen Sie das Peer-DRPG aus, in dem das DRPG erstellt wurde.

Abbildung 3-7: Erforderliche Parameter für die Verknüpfung der DRPGs

Aufgabe 3.4.3: Was Sie nach Abschluss der Zuordnung sehen sollten

Full Stack DR zeigt etwas wie Abbildung 3-8 unten, sobald die Zuordnung abgeschlossen ist.

1. Das aktuelle primäre Peer-DRPG ist Ashburn (Region 1).
2. Das aktuelle Standby-Peer-DRPG ist Phoenix (Region 2).

Abbildung 3-8: Peerbeziehung aus der individuellen DRPG-Perspektive anzeigen

Die gleichen Informationen finden Sie immer dann, wenn der Kontext/die Ansicht aus globaler Perspektive alle DR-Schutzgruppen zeigt, wie in Abbildung 3-9 unten gezeigt.

1. Das aktuelle primäre Peer-DRPG ist Ashburn (Region 1).
2. Das aktuelle Standby-Peer-DRPG ist Phoenix (Region 2).

Abbildung 3-9: Peer-Beziehung aus der globalen DRPG-Perspektive anzeigen

Aufgabe 4: Mitglieder zu den DR-Schutzgruppen hinzufügen

Hinweis: Dieser Schritt löscht alle vorhandenen DR-Pläne in beiden Regionen, wenn Mitglieder zu vorhandenen DR-Schutzgruppen hinzugefügt werden. Full Stack DR kann zum Zeitpunkt des Schreibens keine Kopien speichern oder Backups von DR-Schutzgruppen erstellen. Stellen Sie sicher, dass Sie alle Informationen zu DR-Plangruppen und -schritten in einer Textdatei oder Tabelle aufgezeichnet haben, um die benutzerdefinierten, benutzerdefinierten Plangruppen und -schritte neu zu erstellen. Sie können auch bash-Skripte erstellen, die Full Stack DR-CLI-Befehle aufrufen, um die benutzerdefinierten, benutzerdefinierten Plangruppen und -schritte neu zu erstellen (dies gilt nicht für dieses Tutorial).

Fügen Sie die Datenbank und den DR-Kontrollknoten als Mitglieder der DR-Schutzgruppen hinzu. Der DR-Kontrollknoten ist entweder eine Compute-Instanz, die Sie nur zur Kontrolle von OAC erstellt haben, oder eine Compute-Instanz, die Teil des Anwendungsstacks ist, den Sie mit Full Stack DR verwalten möchten.

Sie fügen dem primären DRPG in Region 1 die folgenden Ressourcen hinzu:

1. Der DR-Kontrollknoten,
2. Die Volume-Gruppe, die das Boot-Volume des DR-Kontrollknotens enthält,
3. Das primäre Autonomous Data Warehouse.

Aufgabe 4.1: Hinzufügen von Mitgliedern zu DRPG in Region 1 beginnen

Wählen Sie zunächst das DRPG in Bereich 1 aus, wie in Abbildung 4-1 unten dargestellt.

1. Stellen Sie sicher, dass der OCI-Regionskontext Region 1 (Ashburn) ist.
2. Wählen Sie das DRPG in Region 1 aus.
3. Elemente auswählen.
4. Klicken Sie auf "Mitglied hinzufügen", um den Prozess zu starten.

Abbildung 4-1: So beginnen Sie mit dem Hinzufügen von Mitgliedern zur DR-Schutzgruppe in Region 1

Aufgabe 4.1.1: Compute-Instanz für DR-Knoten hinzufügen

Fügen Sie eine Compute-Instanz für den DR-Kontrollknoten hinzu, wie in Abbildung 4-2 unten dargestellt.

1. Warnung zu DR-Plänen bestätigen.
2. Wählen Sie als Elementressourcentyp "Compute" aus.
3. Wählen Sie die Compute-Instanz aus, die Sie mit dem DR-Kontrollknoten verwenden möchten.
4. Wählen Sie die zu verschiebende Instanz aus.
5. Teilen Sie Full Stack DR mit, welches VCN und Subnetz den VNICs in Region 2 während eines Recoverys zugewiesen werden sollen. Abbildung 4-2 zeigt eine einzelne VNIC. Bei Full Stack DR ist es egal, wie viele VNICs Sie haben oder wie sie in beiden Regionen konfiguriert sind. Geben Sie an, welche Anforderungen Sie benötigen.

Abbildung 4-2: Erforderliche Parameter zum Hinzufügen des DR-Kontrollknotens

Aufgabe 4.1.2: Block-Volume-Gruppe für DR-Knoten hinzufügen

Fügen Sie die Block-Volume-Gruppe mit Boot für den DR-Kontrollknoten hinzu. Für die Block-Volume-Gruppe muss bereits eine regionsübergreifende Replikation zwischen den beiden Regionen konfiguriert sein, bevor sie der DR-Schutzgruppe hinzugefügt wird.

1. Wählen Sie "Volume-Gruppe" als Elementressourcentyp aus.
2. Stellen Sie sicher, dass das richtige Compartment mit der Volume-Gruppe ausgewählt ist, und wählen Sie die Volume-Gruppe aus.

Abbildung 4-3: Erforderliche Parameter zum Hinzufügen einer Boot-Volume-Gruppe für DR-Kontrollknoten

Aufgabe 4.1.3: Primäres Autonomous Data Warehouse hinzufügen

Autonomous Data Guard muss zu diesem Zeitpunkt bereits im Rahmen von Aufgabe 1 für Autonomous Data Warehouse (ADW) konfiguriert sein. Fügen Sie das primäre ADW als Mitglied des DRPG in Region 1 hinzu.

1. Wählen Sie als Elementressourcentyp "Autonome Datenbank" aus.
2. Stellen Sie sicher, dass das richtige Compartment mit ADW ausgewählt ist, und wählen Sie das primäre ADW für OAC aus.

Abbildung 4-4: Erforderliche Parameter zum Hinzufügen des primären ADW

Aufgabe 4.1.4: Elementressourcen für Region 1 prüfen

Das DRPG für Region 1 sollte mindestens über drei Mitgliedsressourcen verfügen, wie in Abbildung 4-5 unten dargestellt. Die Namen Ihrer Mitgliedsressourcen sind unterschiedlich.

1. Das primäre ADW.
2. Die verschiebbare Compute-Instanz und die Block-Volume-Gruppe für die Compute-Instanz, die wir als OAC DR-Kontrollknoten angegeben haben.

Abbildung 4-5: Elemente von DRPG in Region 1 anzeigen

Aufgabe 4.2: Hinzufügen von Mitgliedern zu DRPG in Region 2 beginnen

Sie fügen dem primären DRPG in Region 2 die folgenden Ressourcen hinzu:

1. Das Standby-/Remote-Autonomous Data Warehouse (ADW).

Wählen Sie zunächst das DRPG in Bereich 2 aus, wie in Abbildung 4-6 unten dargestellt.

1. Stellen Sie sicher, dass der OCI-Regionskontext Region 2 (Phoenix) ist.
2. Wählen Sie das DRPG in Region 2 aus.
3. Elemente auswählen.
4. Klicken Sie auf "Mitglied hinzufügen", um den Prozess zu starten.

Abbildung 4-6: So beginnen Sie mit dem Hinzufügen von Mitgliedern zur DR-Schutzgruppe in Region 2

Aufgabe 4.2.1: Standby-Autonomous Data Warehouse hinzufügen

Fügen Sie Standby-ADW als Mitglied des DRPG in Region 2 hinzu, wie in Abbildung 4-7 unten dargestellt.

1. Ändern Sie den OCI-Regionskontext in Region 2 (Phoenix).
2. Wählen Sie das in Aufgabe 3.3 erstellte DRPG aus

Abbildung 4-7: Erforderliche Parameter zum Hinzufügen von Standby-ADW

Aufgabe 4.2.2: Elementressourcen für Region 2 prüfen

Das DRPG für Region 2 muss mindestens eine Mitgliedsressource aufweisen, wie in Abbildung 4-8 unten dargestellt. Der Name Ihrer Mitgliedsressourcen ist unterschiedlich.

1. Standby/Remote-ADW.

Abbildung 4-8: Einzelmitglied von DRPG in Region 2 anzeigen

Aufgabe 5: Grundlegende DR-Pläne in Region 2 erstellen (Phoenix)

In diesem Schritt werden grundlegende Switchover- und Failover-Pläne erstellt, die mit der Standby-DR-Schutzgruppe in Region 2 (Phoenix) verknüpft sind.

Jeder Plan hat den Zweck, die Workload von der primären Region 1 in die Standby-Region 2 zu übertragen. Die Rollen der DR-Schutzgruppen in beiden Regionen werden im Rahmen eines beliebigen DR-Vorgangs automatisch umgekehrt. Daher wird die Schutzgruppe in Region 1 zur Standbydatenbank, und die Schutzgruppe in Region 2 wird nach einem Failover oder Switchover zur Primärgruppe.

Full Stack DR füllt beide Pläne vorab mit integrierten Schritten auf, die auf den im vorherigen Schritt hinzugefügten Elementressourcen basieren. Die Pläne werden in späteren Schritten angepasst, um alle mit OAC verbundenen Aufgaben während eines Recovery-Vorgangs zu verarbeiten.

Die Switchover-Pläne werden immer in der Schutzgruppe mit der Standby-Rolle erstellt. Region 2 ist derzeit die Standby-Schutzgruppe. Daher beginnen wir in Phoenix.

Aufgabe 5.1: DR-Pläne erstellen

Erstellen Sie einen Basisplan, indem Sie das DRPG in Region 2 auswählen, wie in Abbildung 5-1 unten dargestellt.

1. Stellen Sie sicher, dass der OCI-Regionskontext Region 2 (Phoenix) ist.
2. Wählen Sie das Standby-DRPG in Region 2.
3. Pläne auswählen.
4. Klicken Sie auf "Plan erstellen", um den Prozess zu starten.

Abbildung 5-1: So erstellen Sie grundlegende DR-Pläne in Region 2

Aufgabe 5.1.1: Switchover-Plan erstellen

Das Erstellen eines DR-Plans ist einfach, wie in Abbildung 5-2 unten dargestellt.

1. Machen Sie den Namen des Switchover-Plans einfach, aber aussagekräftig. Der Name sollte so kurz wie möglich, aber auf einen Blick leicht zu verstehen sein, um Verwirrung und menschliches Versagen während einer Krise zu reduzieren.
2. Wählen Sie den Plantyp aus. Zum Zeitpunkt dieses Schreibens gibt es nur zwei Plantypen.

Abbildung 5-2: Die Parameter, die zum Erstellen eines DR-Switchover-Plans erforderlich sind

Aufgabe 5.1.2: Failover-Plan erstellen

Führen Sie denselben Prozess aus, um einen grundlegenden Failover-Plan zu erstellen, wie in Abbildung 5-3 unten dargestellt.

1. Machen Sie den Namen des Failover-Plans einfach, aber aussagekräftig. Der Name sollte so kurz wie möglich, aber auf einen Blick leicht zu verstehen sein, um Verwirrung und menschliches Versagen während einer Krise zu reduzieren.
2. Wählen Sie den Plantyp aus. Zum Zeitpunkt dieses Schreibens gibt es nur zwei Plantypen.

Abbildung 5-3: Die Parameter, die zum Erstellen eines DR-Failover-Plans erforderlich sind

Die Standby-DR-Schutzgruppe in Region 2 sollte jetzt die beiden DR-Pläne aufweisen, wie unten gezeigt. Diese bewältigen den Übergang von Workloads von Region 1 zu Region 2. In einem späteren Schritt erstellen Sie ähnliche Pläne in Region 1, um Workloads von Region 2 zurück in Region 1 zu verlagern.

Abbildung 5-4: Die beiden grundlegenden DR-Pläne werden angezeigt, die in Region 2 vorhanden sein müssen, bevor Sie fortfahren.

Aufgabe 6: Switchover-Plan in Region 2 anpassen (Phoenix)

Die in Aufgabe 5 erstellten grundlegenden DR-Pläne enthalten vorab aufgefüllte Schritte für Recovery-Aufgaben, die in Full Stack DR integriert sind und nichts zur Verwaltung von OAC-spezifischen Recovery-Aufgaben enthalten. In diesem Schritt wird erläutert, wie Sie benutzerdefinierte, benutzerdefinierte DR-Plangruppen und Schritte zum Verwalten der Dinge hinzufügen, die während eines Switchovers für OAC ausgeführt werden müssen:

1. Stoppen Sie OAC in der aktuellen primären Region 1, bevor Sie VMs stoppen.
2. Starten Sie OAC in der aktuellen Standbyregion 2, nachdem Sie VMs gestartet haben.
3. Stellen Sie den periodischen Snapshot in der Standby-Region 2 wieder her. Der periodische Snapshot wurde im Rahmen von Aufgabe 1.4 oben eingerichtet.
4. Ändern Sie den Snapshot-Cron-Job in der Standbyregion 2. Der Cron-Job wurde im Rahmen von Aufgabe 1.4 oben eingerichtet.

Aufgabe 6.1: Switchover-Plan auswählen

Navigieren Sie zu dem im vorherigen Schritt erstellten Switchover-Plan.

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

Aufgabe 6.2: DR-Plangruppen aktivieren, die Artefakte beenden (optional)

Es gibt zwei Plangruppen, die standardmäßig in Switchover-Plänen deaktiviert sind, wie im folgenden Screenshot gezeigt. Sie sind deaktiviert, um ein gewisses Maß an Komfort beim Testen zu bieten, dass nichts tatsächlich gelöscht wird, und Sie haben immer noch eine tragfähige Kopie der Artefakte als Backup, falls während des Tests etwas schief geht.

Diese beiden Plangruppen beenden (löschen) Artefakte, die in Zukunft nicht mehr als Teil eines DR-Vorgangs verwendet werden. Die Artefakte werden sich im Laufe der Zeit einfach weiter akkumulieren, wenn Sie zwischen den beiden Regionen hin und her wechseln, was zu Verwirrung darüber führt, welche Compute-Instanzen und Volume-Gruppen tatsächlich aktiv sein sollten.

Diese Plangruppen sollten aktiviert werden, sobald Full Stack DR in Betrieb genommen wird. Alle Artefakte, die beim Testen von Switchover und Switchbacks verbleiben, während diese beiden Plangruppen deaktiviert wurden, sollten beendet und bereinigt werden, bevor sie in die Produktion gehen, um Verwirrung und die Wahrscheinlichkeit menschlicher Fehler während des normalen Betriebs zu reduzieren.

Optional können diese Plangruppen jetzt aktiviert werden, um zu vermeiden, dass die überflüssigen Artefakte manuell bereinigt werden müssen, bevor sie in die Produktion gehen.

Abbildung 6-2: Plangruppen sind standardmäßig deaktiviert

Folgende Aktionen werden von deaktivierten Plangruppen ausgeführt, wenn sie aktiviert sind:

1. Diese Plangruppe beendet Artefakte von Compute-Instanzen, die in Region 1 zurückbleiben, nachdem die replizierten Versionen der VMs in Region 2 während des OCI-Blockspeichervorgangs gestartet wurden, um die Replikation von Region 2 zurück in Region 1 im Rahmen des Switchovers umzukehren. Die übrig gebliebenen VMs werden bei einem Switchback nicht verwendet, da durch den Vorgang zum Rückgängigmachen der Block-Volume-Replikation alle neuen VMs in vollständig neuen Block-Volume-Gruppen erstellt werden.

2. Diese Plangruppe beendet Artefakte von Block-Volume-Gruppen (VGs), die in Region 1 zurückbleiben, nachdem die replizierten Versionen der VGs in Region 2 aktiviert wurden und die Volume-Gruppenreplikation während des Switchovers rückgängig gemacht wurde. Die verbleibenden Block-Volume-Gruppen werden nie wieder verwendet, auch nicht im Rahmen eines Switchovers von Region 2 zurück zu Region 1.

Aufgabe 6.2.1: Beenden der Compute-Plangruppe aktivieren

Aktivieren Sie die Plangruppe.

1. Wählen Sie im Kontextmenü rechts neben dem Plangruppennamen die Option Alle Schritte aktivieren.

Abbildung 6-3: So aktivieren Sie das Beenden von Compute-Instanzen

Aufgabe 6.2.2 "Volume-Gruppen beenden" aktivieren - Plangruppe

Aktivieren Sie die Plangruppe.

1. Wählen Sie im Kontextmenü rechts neben dem Plangruppennamen die Option Alle Schritte aktivieren.

Abbildung 6-4: So aktivieren Sie das Beenden von Volume-Gruppen

Aufgabe 6.3: Plangruppe zum Stoppen von OAC in Region 1 erstellen (primär)

Fügen Sie jetzt benutzerdefinierte, benutzerdefinierte DR-Plangruppen hinzu.

Die erste benutzerdefinierte Plangruppe stoppt OAC, das in der primären Region 1 ausgeführt wird. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oac-start-stop.sh aufruft, das in Aufgabe 1.4 auf den DR-Kontrollknoten heruntergeladen wurde.

Aufgabe 6.3.1: Plangruppe hinzufügen auswählen

Beginnen Sie den Prozess zum Hinzufügen einer Plangruppe.

1. Klicken Sie zum Beginnen auf "Gruppe hinzufügen".

Abbildung 6-5: Mit dem Hinzufügen einer Plangruppe zum Stoppen von OAC beginnen

Aufgabe 6.3.2: Plangruppennamen angeben, sortieren und Schritt hinzufügen

Eine DR-Plangruppe kann viele Schritte enthalten, die alle parallel ausgeführt werden. Wir fügen gerade einen einzelnen Schritt hinzu, um ein bash-Skript auszuführen, um OAC zu stoppen.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Dies ist natürlich optional. Es empfiehlt sich jedoch, eine Notiz hinzuzufügen, in welcher Region die Plangruppe die Schritte ausführt. In diesem Fall ist es die primäre Region, daher haben wir dem Gruppennamen "(Primär)" hinzugefügt.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall fügen wir die benutzerdefinierte Plangruppe ein, bevor die integrierte Plangruppe, mit der die VMs in Region 1 gestoppt werden.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen stoppen (primär) aus.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Stoppen von OAC angeben.

Abbildung 6-6: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Stoppen von OAC

Aufgabe 6.3.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird OAC in Region 1 gestoppt.

Wir werden alle Felder in diesem Dialog erklären, aber lassen Sie dieses Detail in allen verbleibenden Screenshots in den folgenden Schritten weg, da wir gerade denselben Prozess wiederholt durchführen.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Der DR-Plan muss gestoppt werden, wenn das Skript OAC nicht stoppen kann. Dadurch kann jeder sehen, dass es ein Problem gibt und es beheben. Full Stack DR bietet die Möglichkeit, den Switchover-Plan weiter auszuführen, nachdem das Problem behoben wurde.
3. Der Standardwert, bevor Full Stack DR einen Fehler deklariert, beträgt eine Stunde. Dieser Wert kann auf 30 Minuten geändert werden oder was immer als realistischerer Timeoutwert empfunden wird.
4. Wählen Sie immer die Region aus, in der der DR-Kontrollknoten gerade ausgeführt wird, nicht, in der er während eines Switchovers ausgeführt wird. Full Stack DR verfolgt, wo die VM ausgeführt wird, sodass Sie nur angeben müssen, wo sie sich gerade befindet. In diesem Fall wird der DR-Kontrollknoten in Region 1 (Ashburn) ausgeführt.
5. Wählen Sie Lokales Skript ausführen aus, um Full Stack DR zu informieren, dass sich das Skript auf einer Compute-Instanz befindet. Die bash-Skripte wurden in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen.
6. Wählen Sie das richtige Compartment aus, das den DR-Kontrollknoten enthält. Dabei kann es sich um ein beliebiges Compartment handeln. Wählen Sie die Compute-Instanz aus, die als DR-Kontrollknoten angegeben wurde (es kann sich um einen Anwendungsserver oder eine VM handeln, die nur für dieses Projekt/Tutorial erstellt wurde).
7. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-start-stop.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie stop als ersten Parameter und die OCI-Regions-ID als zweiten Parameter hinzu.
8. Geben Sie opc als Benutzer an, um das Skript auszuführen.
9. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 6-7: Parameter zum Erstellen des Planschritts zum Stoppen von OAC

Aufgabe 6.3.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Stoppen von OAC wird jetzt der DR-Plangruppe hinzugefügt, wie in Abbildung 6-8 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde. Es ist möglich, einer DR-Plangruppe zusätzliche Schritte hinzuzufügen. Diese Plangruppe enthält jedoch nur den Schritt zum Stoppen von OAC.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 6-8: Hinzufügen von Plangruppe und Schritt zum Stoppen von OAC abschließen

Aufgabe 6.4: Plangruppe erstellen, um OAC in Region 2 zu starten (Standby)

Die zweite benutzerdefinierte Plangruppe startet OAC, nachdem der DR-Kontrollknoten in der Standbyregion 2 gestartet wurde. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oac-start-stop.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

Aufgabe 6.4.1: Plangruppe hinzufügen auswählen

Klicken Sie wie zuvor auf Gruppe hinzufügen, um zu beginnen.

Abbildung 6-9: Beginnen Sie mit dem Hinzufügen einer Plangruppe, um OAC in der Standbydatenbank zu starten

Aufgabe 6.4.2: Plangruppennamen angeben, bestellen und Schritt hinzufügen

Erstellen Sie eine DR-Plangruppe, um OAC zu starten.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Es ist immer ratsam, dem Gruppennamen "(Standby)" hinzuzufügen, sodass auf einen Blick ersichtlich ist, welcher Bereich die Schritte gelten.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall werden wir unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe einfügen, die die replizierte Version des DR-Kontrollknotens in Region 2 startet.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen starten (Standby) aus
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Starten von OAC angegeben wird

Abbildung 6-10: Parameter zum Erstellen einer Plangruppe und Hinzufügen eines Schritts zum Starten von OAC in der Standbydatenbank

Aufgabe 6.4.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird OAC in Region 2 gestartet.

Alles in diesem Schritt entspricht Aufgabe 6.3.3, mit Ausnahme der Elemente, die in Abbildung 6-11 unten angezeigt werden.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-start-stop.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie start als ersten Parameter und die OCI-Regions-ID als zweiten Parameter hinzu.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 6-11: Parameter zum Erstellen des Planschritts zum Starten von OAC in der Standbydatenbank

Aufgabe 6.4.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Starten von OAC wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 6-12 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 6-12: Schließen Sie das Hinzufügen einer Plangruppe und eines Schritts ab, um OAC in der Standbydatenbank zu starten

Aufgabe 6.5: Plangruppe erstellen, um Snapshot in Region 2 wiederherzustellen (Standby)

Im Rahmen von Aufgabe 1.4 wurde ein Cron-Job auf dem DR-Kontrollknoten eingerichtet. Der cron-Job ruft ein bash-Skript namens OAC-create-snapshot.sh auf, das für den Export eines Snapshots von OAC-Daten in Region 1 und das Speichern im Objektspeicher-Bucket in Standbyregion 2 verantwortlich ist. Der Cron-Job und die Buckets wurden ebenfalls in Aufgabe 1.4 erstellt.

Die dritte benutzerdefinierte Plangruppe stellt OAC in der Standbyregion 2 mit dem periodischen Snapshot wieder her, der aus dem Objektspeicher-Bucket in Region 1 in Region 2 repliziert wird. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oac-register-snapshot.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

Aufgabe 6.5.1: "Plangruppe hinzufügen" auswählen

Klicken Sie wie zuvor auf Gruppe hinzufügen, um zu beginnen.

Abbildung 6-13: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Wiederherstellen des Snapshots in der Standbydatenbank

Aufgabe 6.5.2: Plangruppennamen angeben, bestellen und Schritt hinzufügen

Erstellen Sie eine DR-Plangruppe, um OAC in der Standbyregion 2 wiederherzustellen.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. Fügen Sie in diesem Fall die benutzerdefinierte Plangruppe nach der in der vorherigen Aufgabe erstellten benutzerdefinierten Plangruppe ein, um OAC zu starten.
3. Wählen Sie die integrierte Plangruppe OAC starten (Standby) aus
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zur Wiederherstellung des OAC-Snapshots angeben.

Abbildung 6-14: Parameter zum Erstellen einer Plangruppe und Hinzufügen eines Schritts zum Wiederherstellen des OAC-Snapshots in der Standbydatenbank

Aufgabe 6.5.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird der OAC-Snapshot in Region 2 wiederhergestellt. Der Snapshot wird während normaler Vorgänge in der primären Region erstellt und in einem Objektspeicher-Bucket in Region 2 gespeichert.

Alles in dieser Aufgabe ist dasselbe wie Aufgabe 6.3.3, mit Ausnahme der Elemente, die in Abbildung 6-15 unten angezeigt werden.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-start-stop.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie OCI-Regions-ID als einzigen Parameter hinzu (in diesem Beispiel PHX).
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 6-15: Parameter zum Erstellen des Planschritts zum Wiederherstellen des Snapshots in der Standbydatenbank

Aufgabe 6.5.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Wiederherstellen von OAC wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 6-16 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 6-16: Hinzufügen von Plangruppe und Schritt zum Wiederherstellen des Snapshots in der Standbydatenbank abschließen

Aufgabe 6.6: Plangruppe erstellen, um Snapshot in Region 2 umzukehren (Standby)

Die letzte benutzerdefinierte Plangruppe ändert den in Aufgabe 6.5 oben beschriebenen Cron-Job. Full Stack DR ruft OAC-chg-cronjob.sh auf, um den Cron-Job zu ändern und den exportierten OAC-Snapshot im Speicher-Bucket in Region 1 zu speichern.

Aufgabe 6.6.1: Plangruppe hinzufügen auswählen

Klicken Sie wie zuvor auf Gruppe hinzufügen, um zu beginnen.

Abbildung 6-17: Beginnen Sie mit dem Hinzufügen einer Plangruppe zur umgekehrten Snapshot-Kopie in der Standbydatenbank

Aufgabe 6.6.2: Plangruppennamen angeben, sortieren und Schritt hinzufügen

Erstellen Sie eine DR-Plangruppe, um den OAC-Snapshot in Region 1 umzukehren.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Es ist immer ratsam, dem Gruppennamen "(Standby)" hinzuzufügen, sodass auf einen Blick ersichtlich ist, welcher Bereich die Schritte gelten.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall werden wir unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe einfügen, die den OAC-Snapshot in Region 2 wiederherstellt.
3. Wählen Sie die integrierte Plangruppe OAC-Snapshot wiederherstellen (Standby).
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Starten von OAC angeben.

Abbildung 6-18: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Reverse-Snapshot-Kopieren in der Standbydatenbank

Aufgabe 6.6.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall kehrt er den OAC-Snapshot um, sodass er in Region 1 gespeichert wird, die nach Abschluss des Switchovers automatisch zur Standbyregion wird.

Alles in dieser Aufgabe ist dasselbe wie Aufgabe 6.3.3, mit Ausnahme der Elemente, die in Abbildung 6-19 unten angezeigt werden.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-chg-cronjob.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie den OCI-Regionsschlüssel für Region 1 (in diesem Beispiel iad) als ersten Parameter und Regionsschlüssel für Region 2 (in diesem Beispiel phx) als zweiten Parameter hinzu.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 6-19: Parameter zum Erstellen des Planschritts zum Rückgängigmachen der Snapshot-Kopie in der Standbydatenbank

Aufgabe 6.6.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Umkehren der OAC-Snapshot-Richtung wird jetzt der DR-Plangruppe hinzugefügt, wie in Abbildung 6-20 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 6-20: Schließen Sie das Hinzufügen einer Plangruppe und eines Schritts ab, um die Snapshot-Kopie in der Standbydatenbank umzukehren

Der Switchover-Plan sollte jetzt die vier DR-Plangruppen für OAC enthalten, wie im folgenden Screenshot gezeigt. Möglicherweise haben Sie zusätzliche Plangruppen, wenn Ihre Schutzgruppe andere Anwendungen oder OCI-Services zusammen mit OAC enthält.

Abbildung 6-21: Vier benutzerdefinierte Plangruppen anzeigen, die dem Switchover-Plan hinzugefügt wurden

Aufgabe 7: Failover-Plan in Region 2 anpassen (Phoenix)

In dieser Aufgabe wird erläutert, wie Sie benutzerdefinierte, benutzerdefinierte DR-Plangruppen und Schritte zum Verwalten der Dinge hinzufügen, die während eines Failovers für OAC in Region 2 bei einem tatsächlichen Ausfall oder Verlust des Zugriffs auf Region 1 ausgeführt werden müssen. Dies ist eine Teilmenge derselben Schritte, die gerade zum Switchover-Plan in Aufgabe 6 oben hinzugefügt wurden. Dem Failover-Plan werden jedoch nur Schritte hinzugefügt, die in der Standby-Region 2 ausgeführt werden, da davon ausgegangen wird, dass der Bereich 1 während eines Failovers vollständig nicht zugänglich ist.

1. Starten Sie OAC in Standbyregion 2, nachdem Sie VMs gestartet haben.
2. Stellen Sie den periodischen Snapshot in der Standby-Region 2 wieder her. Der periodische Snapshot wurde im Rahmen von Aufgabe 1.4 oben eingerichtet.
3. Ändern Sie den Snapshot-Cron-Job in der Standbyregion 2. Der Cron-Job wurde im Rahmen von Aufgabe 1.4 oben eingerichtet.

Aufgabe 7.1: Wählen Sie den Failover-Plan aus

Navigieren Sie zu dem Failover-Plan, der in Aufgabe 5 erstellt wurde.

1. Stellen Sie sicher, dass Standbyregion 2 weiterhin der aktuelle Regionskontext in der Konsole ist.
2. Wählen Sie den Failover-Plan aus.

Abbildung 7-1: So erstellen Sie die Anpassung des Failover-Plans in Region 2

Aufgabe 7.2: Wählen Sie "Plangruppe hinzufügen".

Die erste benutzerdefinierte Plangruppe startet OAC, das in Standby-Region 2 ausgeführt wird. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oac-start-stop.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

1. Klicken Sie zum Beginnen auf "Gruppe hinzufügen".

Abbildung 7-2: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Starten von OAC

Aufgabe 7.2.1: Plangruppennamen angeben, sortieren und Schritt hinzufügen

Eine DR-Plangruppe kann viele Schritte enthalten, die alle parallel ausgeführt werden. Wir fügen gerade einen einzelnen Schritt hinzu, um ein bash-Skript auszuführen, um OAC zu starten.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Dies ist natürlich optional. Es empfiehlt sich jedoch, eine Notiz hinzuzufügen, in welcher Region die Plangruppe die Schritte ausführt. In diesem Fall ist es die Standby-Region 2, daher haben wir dem Gruppennamen "(Standby)" hinzugefügt.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall fügen wir die benutzerdefinierte Plangruppe nach der integrierten Plangruppe ein, mit der die replizierten VMs in Region 2 gestartet werden.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen starten (Standby) aus
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Starten von OAC angegeben wird

Abbildung 7-3: Parameter zum Erstellen einer Plangruppe und Hinzufügen eines Schritts zum Starten von OAC

Aufgabe 7.2.2: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird OAC in Region 2 gestartet, wie in Abbildung 7-4 unten dargestellt.

Wir werden alle Felder in diesem Dialog erklären, aber lassen Sie dieses Detail in allen verbleibenden Screenshots in den folgenden Schritten weg, da wir gerade denselben Prozess wiederholt durchführen.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Der DR-Plan muss gestoppt werden, wenn das Skript OAC nicht starten kann. Dadurch kann jeder sehen, dass es ein Problem gibt und es beheben. Full Stack DR bietet die Möglichkeit, den Switchover-Plan weiter auszuführen, nachdem das Problem behoben wurde.
3. Der Standardwert, bevor Full Stack DR einen Fehler deklariert, beträgt eine Stunde. Dieser Wert kann auf 30 Minuten geändert werden oder was immer als realistischerer Timeoutwert empfunden wird.
4. Wählen Sie immer die Region aus, in der der DR-Kontrollknoten gerade ausgeführt wird, nicht, in der er während eines Switchovers ausgeführt wird. Full Stack DR verfolgt, wo die VM ausgeführt wird, sodass Sie nur angeben müssen, wo sie sich gerade befindet. In diesem Fall wird der DR-Kontrollknoten in Region 1 (Ashburn) ausgeführt.
5. Wählen Sie Lokales Skript ausführen aus, um Full Stack DR zu informieren, dass sich das Skript auf einer Compute-Instanz befindet. Die bash-Skripte wurden in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen.
6. Wählen Sie das richtige Compartment aus, das den DR-Kontrollknoten enthält. Dabei kann es sich um ein beliebiges Compartment handeln. Wählen Sie die Compute-Instanz aus, die als DR-Kontrollknoten angegeben wurde (es kann sich um einen Anwendungsserver oder eine VM handeln, die nur für dieses Projekt/Tutorial erstellt wurde).
7. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-start-stop.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie start als ersten Parameter und die OCI-Regions-ID als zweiten Parameter hinzu.
8. Geben Sie opc als Benutzer an, um das Skript auszuführen.
9. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 7-4: Parameter zum Erstellen des Planschritts zum Starten von OAC in der Standbydatenbank

Aufgabe 7.2.3: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Starten von OAC wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 7-5 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 7-5: Hinzufügen von Plangruppe und Schritt zum Starten von OAC abschließen

Aufgabe 7.3: Plangruppe erstellen, um Snapshot in Region 2 wiederherzustellen (Standby)

Die zweite benutzerdefinierte Plangruppe stellt OAC in der Standbyregion 2 mit dem periodischen Snapshot wieder her, der aus dem Objektspeicher-Bucket in Region 1 in Region 2 repliziert wird. Dieselbe Aufgabe, die dem Switchover-Plan hinzugefügt wurde, ist Aufgabe 6.

Aufgabe 7.3.1: "Plangruppe hinzufügen" auswählen

Klicken Sie wie zuvor auf Gruppe hinzufügen, um zu beginnen.

Abbildung 7-6: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Wiederherstellen des Snapshots in der Standbydatenbank

Aufgabe 7.3.2: Plangruppennamen angeben, bestellen und Schritt hinzufügen

Erstellen Sie eine DR-Plangruppe, um OAC in der Standbyregion 2 wiederherzustellen.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. Fügen Sie in diesem Fall die benutzerdefinierte Plangruppe nach der in der vorherigen Aufgabe erstellten benutzerdefinierten Plangruppe ein, um OAC zu starten.
3. Wählen Sie die integrierte Plangruppe OAC (Standby) starten.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zur Wiederherstellung des OAC-Snapshots angeben.

Abbildung 7-7: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Wiederherstellen des OAC-Snapshots in der Standbydatenbank

Aufgabe 7.3.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird der OAC-Snapshot in Region 2 wiederhergestellt. Der Snapshot wird während normaler Vorgänge in der primären Region erstellt und in einem Objektspeicher-Bucket in Region 2 gespeichert.

Alles in dieser Aufgabe ist dasselbe wie Aufgabe 7.3.2, mit Ausnahme der Elemente, die in Abbildung 7-8 unten angezeigt werden.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-start-stop.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie OCI-Regions-ID als einzigen Parameter hinzu (in diesem Beispiel PHX).
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen

Abbildung 7-8: Parameter zum Erstellen des Planschritts zum Wiederherstellen des Snapshots in der Standbydatenbank

Aufgabe 7.3.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Wiederherstellen von OAC wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 7-9 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 7-9: Hinzufügen von Plangruppe und Schritt zum Wiederherstellen des Snapshots in der Standbydatenbank abschließen

Aufgabe 7.4: Plangruppe erstellen, um Snapshot in Region 2 umzukehren (Standby)

Die letzte benutzerdefinierte Plangruppe ändert den Cron-Job, sodass der OAC-Snapshot in Region 1 gespeichert wird, sobald wieder darauf zugegriffen werden kann. Dies ist dieselbe Aufgabe, die dem Switchover-Plan in Aufgabe 6 hinzugefügt wurde.

Aufgabe 7.4.1: "Plangruppe hinzufügen" auswählen

Klicken Sie wie zuvor auf Gruppe hinzufügen, um zu beginnen.

Abbildung 7-10: Beginnen Sie mit dem Hinzufügen einer Plangruppe zur umgekehrten Snapshot-Kopie in der Standbydatenbank

Aufgabe 7.4.2: Plangruppennamen angeben, bestellen und Schritt hinzufügen

Erstellen Sie eine DR-Plangruppe, um den OAC-Snapshot in Region 1 umzukehren.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Es ist immer ratsam, dem Gruppennamen "(Standby)" hinzuzufügen, sodass auf einen Blick ersichtlich ist, welcher Bereich die Schritte gelten.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall werden wir unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe einfügen, die den OAC-Snapshot in Region 2 wiederherstellt.
3. Wählen Sie die integrierte Plangruppe OAC-Snapshot wiederherstellen (Standby).
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Starten von OAC angeben.

Abbildung 7-11: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Reverse-Snapshot-Kopieren in der Standbydatenbank

Aufgabe 7.4.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall kehrt er den OAC-Snapshot um, sodass er in Region 1 gespeichert wird, die nach Abschluss des Switchovers automatisch zur Standbyregion wird.

Alles in dieser Aufgabe ist dasselbe wie Aufgabe 7.2.2, mit Ausnahme der Elemente, die in Abbildung 6-19 unten angezeigt werden.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-chg-cronjob.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie den OCI-Regionsschlüssel für Region 1 (iad in diesem Beispiel) als ersten Parameter und Regionsschlüssel für Region 2 (phx in diesem Beispiel) als zweiten Parameter hinzu.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 7-12: Parameter zum Erstellen des Planschritts zum Rückgängigmachen der Snapshot-Kopie in der Standbydatenbank

Aufgabe 7.4.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Umkehren der OAC-Snapshot-Richtung wird jetzt der DR-Plangruppe hinzugefügt, wie in Abbildung 7-13 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 7-13: Schließen Sie das Hinzufügen einer Plangruppe und eines Schritts ab, um die Snapshot-Kopie in der Standbydatenbank umzukehren

Der Failover-Plan sollte nun die drei DR-Plangruppen für OAC enthalten, wie im folgenden Screenshot gezeigt. Möglicherweise haben Sie zusätzliche Plangruppen, wenn Ihre Schutzgruppe andere Anwendungen oder OCI-Services zusammen mit OAC enthält.

Abbildung 7-14: Die drei benutzerdefinierten Plangruppen werden dem Failover-Plan hinzugefügt

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

Sowohl Switchover- als auch Failover-DR-Pläne wurden in der Standbyregion 2 (Phoenix) abgeschlossen. Mit den DR-Plänen in Region 2 kann Full Stack DR Workloads von Region 1 in Region 2 übertragen. Die nächste Aufgabe besteht darin, Switchover- und Failover-Pläne in der Schutzgruppe für Region 1 (Ashburn) zu erstellen, damit Full Stack DR Workloads von Region 2 zurück in Region 1 übertragen kann.

DR-Pläne können jedoch nur in der Schutzgruppe mit der Standbyrolle erstellt und geändert werden. Die DR-Schutzgruppe in Region 1 ist derzeit die primäre Gruppe. Das bedeutet, dass in Region 1 keine DR-Pläne erstellt werden können.

Daher müssen wir die Rollen der Schutzgruppen umkehren, sodass Region 1 die Standbydatenbank und Region 2 die Primärdatenbank ist. Führen Sie den soeben erstellten Switchover-Plan aus, um die Workload von Region 1 (Ashburn) in Region 2 (Phoenix) zu übertragen.

Aufgabe 8.1: Planausführung beginnen

Führen Sie einen DR-Plan aus, um den Übergang der OAC-Workload von Region 1 in Region 2 zu beginnen.

1. Stellen Sie sicher, dass der Regionskontext weiterhin auf Standby-Region 2 (Phoenix) eingestellt ist.
2. Mit den Navigationspfaden oben in der Konsole können Sie sicherstellen, dass DR-Schutzgruppendetails der aktuelle Plankontext sind.
3. Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Standby-Rolle sein.
4. Stellen Sie sicher, dass sowohl der Failover- als auch der Switchover-Plan vorhanden sind, bevor Sie fortfahren. Wenn nicht, gehen Sie zu den vorherigen Schritten zurück, um beide DR-Pläne zu erstellen.
5. Klicken Sie auf die Schaltfläche DR-Plan ausführen.

Abbildung 8-1: Zeigen, wie ein Switchover zur Standbyregion ausgeführt wird

Aufgabe 8.2: Failover-Plan auswählen und ausführen

Diese Aufgabe führt den Switchover-Plan in Region 2 aus.

1. Wählen Sie den Switchover-Plan aus.
2. Stellen Sie sicher, dass "Vorabprüfungen aktivieren" aktiviert ist.
3. Klicken Sie auf die Schaltfläche DR-Plan ausführen, um zu beginnen.

Abbildung 8-2: Wählen Sie den Switchover-Plan aus, und führen Sie ihn aus

Aufgabe 8.3: Nächste Schritte

Überwachen Sie den Failover-Plan, bis die OAC-Workload vollständig von Region 1 in Region 2 übertragen wurde. Full Stack DR kümmert sich um das Bereinigen von Artefakten und das Ändern der Rollen von Primär- und Standbydatenbank zwischen den Regionen.

Region 2 (Phoenix) ist die primäre Region, und Region 1 (Ashburn) ist die Standbyregion, sobald Full Stack DR das Switchover abgeschlossen hat.

Aufgabe 9: DR-Pläne in Region 1 (Ashburn) erstellen

Erstellen Sie dieselben grundlegenden Switchover- und Failover-Pläne in der DR-Schutzgruppe für Region 1 (Ashburn), die jetzt der Standby-Peer ist.

Jeder Plan hat den Zweck, die Arbeitslast von Region 2 in Region 1 zu übertragen, wenn Region 2 der primäre Peer ist. Die Rollen der DR-Schutzgruppen in beiden Regionen werden im Rahmen eines beliebigen DR-Vorgangs automatisch umgekehrt. Daher wird die Schutzgruppe in Region 2 zur Standbydatenbank, und die Schutzgruppe in Region 1 wird nach einem Failover oder Switchover zur Primärgruppe.

Full Stack DR füllt beide Pläne vorab mit integrierten Schritten auf, die auf den im vorherigen Schritt hinzugefügten Elementressourcen basieren. Die Pläne werden in späteren Schritten angepasst, um alle mit OAC verbundenen Aufgaben während eines Recovery-Vorgangs zu verarbeiten.

Die Switchover-Pläne werden immer in der Schutzgruppe mit der Standbyrolle erstellt. Region 1 ist derzeit die Standby-Schutzgruppe, nachdem der Switchover-Plan in Aufgabe 8 ausgeführt wurde.

Aufgabe 9.1: DR-Pläne erstellen

Erstellen Sie einen Basisplan, indem Sie das DRPG in Region 2 auswählen, wie in Abbildung 9-1 unten dargestellt.

1. Stellen Sie sicher, dass der OCI-Regionskontext Region 1 (Ashburn) ist.
2. Wählen Sie das Standby-DRPG in Region 1.
3. Pläne auswählen.
4. Klicken Sie auf "Plan erstellen", um den Prozess zu starten.

Abbildung 9-1: So erstellen Sie grundlegende DR-Pläne in Region 1

Aufgabe 9.1.1: Switchover-Plan erstellen

Das Erstellen eines DR-Plans ist einfach, wie in Abbildung 9-2 unten dargestellt.

1. Machen Sie den Namen des Switchover-Plans einfach, aber aussagekräftig. Der Name sollte so kurz wie möglich, aber auf einen Blick leicht zu verstehen sein, um Verwirrung und menschliches Versagen während einer Krise zu reduzieren.
2. Wählen Sie den Plantyp aus. Zum Zeitpunkt dieses Schreibens gibt es nur zwei Plantypen.

Abbildung 9-2: Die Parameter, die zum Erstellen eines DR-Switchover-Plans erforderlich sind

Aufgabe 9.2: Failover-Plan erstellen

Führen Sie denselben Prozess aus, um einen grundlegenden Failover-Plan zu erstellen, wie in Abbildung 9-3 unten dargestellt.

1. Machen Sie den Namen des Failover-Plans einfach, aber aussagekräftig. Der Name sollte so kurz wie möglich, aber auf einen Blick leicht zu verstehen sein, um Verwirrung und menschliches Versagen während einer Krise zu reduzieren.
2. Wählen Sie den Plantyp aus. Zum Zeitpunkt dieses Schreibens gibt es nur zwei Plantypen.
3. Klicken Sie auf "Erstellen", um einen grundlegenden Failover-Plan zu erstellen, der mit grundlegenden integrierten Schritten vorab aufgefüllt wird.

Abbildung 9-3: Die Parameter, die zum Erstellen eines DR-Failover-Plans erforderlich sind

Die Standby-DR-Schutzgruppe in Region 1 sollte jetzt die beiden DR-Pläne aufweisen, wie unten gezeigt. Diese verarbeiten den Übergang von Workloads von Region 2 zurück in Region 1.

Abbildung 9-4: Die beiden grundlegenden DR-Pläne werden angezeigt, die in Region 2 vorhanden sein müssen, bevor Sie fortfahren.

Aufgabe 10: Switchover-Plan in Region 1 (Ashburn) anpassen

Alles an dieser Aufgabe ist fast genau das gleiche wie in Aufgabe 6 für Region 2, außer dass dies in Region 1 geschieht.

Die in Aufgabe 9 erstellten grundlegenden DR-Pläne enthalten keine für OAC spezifischen Recovery-Aufgaben. In dieser Aufgabe wird erläutert, wie Sie benutzerdefinierte, benutzerdefinierte DR-Plangruppen und Schritte zum Verwalten der Dinge hinzufügen, die während eines Switchovers für OAC ausgeführt werden müssen:

1. Stoppen Sie OAC in der aktuellen primären Region 2, bevor Sie VMs stoppen.
2. Starten Sie OAC in der aktuellen Standbyregion 1, nachdem Sie VMs gestartet haben.
3. Stellen Sie den periodischen Snapshot in der Standby-Region 1 wieder her. Der periodische Snapshot wurde im Rahmen von Aufgabe 1.4 oben eingerichtet.
4. Ändern Sie den Snapshot-Cron-Job in der Standbyregion 1. Der Cron-Job wurde im Rahmen von Aufgabe 1.4 oben eingerichtet.

Aufgabe 10.1: Switchover-Plan auswählen

Navigieren Sie zu dem im vorherigen Schritt erstellten Switchover-Plan.

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

Aufgabe 10.2: DR-Plangruppen aktivieren, die Artefakte beenden (optional)

Dies sind die gleichen Schritte, die in einem früheren Schritt für Region 2 ausgeführt werden. Für Region 1 muss derselbe Prozess ausgeführt werden.

Zwei Plangruppen sind in Switchover-Plänen standardmäßig deaktiviert, wie im folgenden Screenshot gezeigt. Sie sind deaktiviert, um beim Testen ein gewisses Maß an Komfort zu bieten, dass nichts tatsächlich gelöscht wird, und Sie haben immer noch eine tragfähige Kopie der Artefakte als Backup, falls während des Tests etwas schief geht.

Diese beiden Plangruppen beenden (löschen) Artefakte, die in Zukunft nicht mehr als Teil eines DR-Vorgangs verwendet werden. Die Artefakte werden sich im Laufe der Zeit einfach weiter ansammeln, wenn Sie zwischen den beiden Regionen hin und her wechseln, was für Menschen Verwirrung darüber verursacht, welche Compute-Instanzen und Volume-Gruppen tatsächlich aktiv sein sollten.

Diese Plangruppen sollten aktiviert werden, sobald Full Stack DR in Betrieb genommen wird. Alle Artefakte, die beim Testen von Switchover und Switchbacks verbleiben, während diese beiden Plangruppen deaktiviert wurden, sollten beendet und bereinigt werden, bevor sie in die Produktion gehen, um Verwirrung und die Wahrscheinlichkeit menschlicher Fehler während des normalen Betriebs zu reduzieren.

Optional können diese Plangruppen jetzt aktiviert werden, um zu vermeiden, dass die überflüssigen Artefakte manuell bereinigt werden müssen, bevor sie in die Produktion gehen.

Abbildung 10-2: Plangruppen sind standardmäßig deaktiviert

Folgende Aktionen werden von deaktivierten Plangruppen ausgeführt, wenn sie aktiviert sind:

1. Diese Plangruppe beendet Artefakte von Compute-Instanzen, die in Region 2 zurückbleiben, nachdem die replizierten Versionen der VMs in Region 1 während des OCI-Blockspeichervorgangs gestartet wurden, um die Replikation von Region 1 im Rahmen des Switchovers von Region 2 zurück in Region 2 umzukehren. Die übrig gebliebenen VMs werden bei einem Switchback nicht verwendet, da durch den Vorgang zum Rückgängigmachen der Block-Volume-Replikation alle neuen VMs in vollständig neuen Block-Volume-Gruppen erstellt werden.

2. Diese Plangruppe beendet Artefakte von Block-Volume-Gruppen (VGs), die in Region 2 zurückbleiben, nachdem die replizierten Versionen der VGs in Region 1 aktiviert wurden und die Volume-Gruppenreplikation während des Switchovers rückgängig gemacht wurde. Die verbleibenden Block-Volume-Gruppen werden nie wieder verwendet, auch nicht im Rahmen eines Switchovers von Region 1 zurück zu Region 2.

Aufgabe 10.2.1: Beenden der Compute-Plangruppe aktivieren

Aktivieren Sie die Plangruppe.

1. Wählen Sie im Kontextmenü rechts neben dem Plangruppennamen die Option Alle Schritte aktivieren.

Abbildung 10-3: OW zum Aktivieren von Beendigungs-Compute-Instanzen

Aufgabe 10.2.2 "Volume-Gruppen beenden" aktivieren - Plangruppe

Aktivieren Sie die Plangruppe.

1. Wählen Sie im Kontextmenü rechts neben dem Plangruppennamen die Option Alle Schritte aktivieren.

Abbildung 10-4: So aktivieren Sie das Beenden von Volume-Gruppen

Aufgabe 10.3: Plangruppe zum Stoppen von OAC in Region 2 erstellen (primär)

Fügen Sie jetzt benutzerdefinierte, benutzerdefinierte DR-Plangruppen hinzu.

Die erste benutzerdefinierte Plangruppe stoppt OAC, das in der primären Region 1 ausgeführt wird. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oac-start-stop.sh aufruft, das in Aufgabe 1.4 auf den DR-Kontrollknoten heruntergeladen wurde.

Aufgabe 10.3.1: Plangruppe hinzufügen auswählen

Beginnen Sie den Prozess zum Hinzufügen einer Plangruppe.

1. Klicken Sie zum Beginnen auf "Gruppe hinzufügen".

Abbildung 10-5: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Stoppen von OAC

Aufgabe 10.3.2: Plangruppennamen angeben, sortieren und Schritt hinzufügen

Eine DR-Plangruppe kann viele Schritte enthalten, die alle parallel ausgeführt werden. Wir fügen gerade einen einzelnen Schritt hinzu, um ein bash-Skript auszuführen, um OAC zu stoppen.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Dies ist natürlich optional. Es empfiehlt sich jedoch, eine Notiz hinzuzufügen, in welcher Region die Plangruppe die Schritte ausführt. In diesem Fall ist es die primäre Region, daher haben wir dem Gruppennamen "(Primär)" hinzugefügt.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall fügen wir die benutzerdefinierte Plangruppe ein, bevor die integrierte Plangruppe, mit der die VMs in Region 2 gestoppt werden.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen stoppen (primär) aus.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Stoppen von OAC angeben.

Abbildung 10-6: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Stoppen von OAC

Aufgabe 10.3.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird OAC in Region 2 gestoppt.

Wir werden alle Felder in diesem Dialog erklären, aber lassen Sie dieses Detail in allen verbleibenden Screenshots in den folgenden Schritten weg, da wir gerade denselben Prozess wiederholt durchführen.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Der DR-Plan muss gestoppt werden, wenn das Skript OAC nicht stoppen kann. Dadurch kann jeder sehen, dass es ein Problem gibt und es beheben. Full Stack DR bietet die Möglichkeit, den Switchover-Plan weiter auszuführen, nachdem das Problem behoben wurde.
3. Der Standardwert, bevor Full Stack DR einen Fehler deklariert, beträgt eine Stunde. Dieser Wert kann auf 30 Minuten geändert werden oder was immer als realistischerer Timeoutwert empfunden wird.
4. Wählen Sie immer die Region aus, in der der DR-Kontrollknoten gerade ausgeführt wird, nicht, in der er während eines Switchovers ausgeführt wird. Full Stack DR verfolgt, wo die VM ausgeführt wird, sodass Sie nur angeben müssen, wo sie sich gerade befindet. In diesem Fall wird der DR-Kontrollknoten in Region 2 (Phoenix) ausgeführt.
5. Wählen Sie Lokales Skript ausführen aus, um Full Stack DR zu informieren, dass sich das Skript auf einer Compute-Instanz befindet. Die bash-Skripte wurden in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen.
6. Wählen Sie das richtige Compartment aus, das den DR-Kontrollknoten enthält. Dabei kann es sich um ein beliebiges Compartment handeln. Wählen Sie die Compute-Instanz aus, die als DR-Kontrollknoten angegeben wurde (es kann sich um einen Anwendungsserver oder eine VM handeln, die nur für dieses Projekt/Tutorial erstellt wurde).
7. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-start-stop.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie stop als ersten Parameter und die OCI-Regions-ID als zweiten Parameter hinzu.
8. Geben Sie opc als Benutzer an, um das Skript auszuführen.
9. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 10-7: Parameter zum Erstellen des Planschritts zum Stoppen von OAC

Aufgabe 10.3.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Stoppen von OAC wird jetzt der DR-Plangruppe hinzugefügt, wie in Abbildung 10-8 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde. Es ist möglich, einer DR-Plangruppe zusätzliche Schritte hinzuzufügen. Diese Plangruppe enthält jedoch nur den Schritt zum Stoppen von OAC.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 10-8: Hinzufügen von Plangruppe und Schritt zum Stoppen von OAC abschließen

Aufgabe 10.4: Plangruppe erstellen, um OAC in Region 1 (Standby) zu starten

Die zweite benutzerdefinierte Plangruppe startet OAC, nachdem der DR-Kontrollknoten in der Standbyregion 2 gestartet wurde. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oac-start-stop.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

Aufgabe 10.4.1: "Plangruppe hinzufügen" auswählen

Klicken Sie wie zuvor auf Gruppe hinzufügen, um zu beginnen.

Abbildung 10-9: Beginnen Sie mit dem Hinzufügen einer Plangruppe, um OAC in der Standbydatenbank zu starten.

Aufgabe 10.4.2: Plangruppennamen angeben, sortieren und Schritt hinzufügen

Erstellen Sie eine DR-Plangruppe, um OAC zu starten.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Es ist immer ratsam, dem Gruppennamen "(Standby)" hinzuzufügen, sodass auf einen Blick ersichtlich ist, welcher Bereich die Schritte gelten.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall werden wir unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe einfügen, die in Region 1 die replizierte Version des DR-Kontrollknotens startet.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen (Standby) starten aus.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Starten von OAC angeben.

Abbildung 10-10: Parameter zum Erstellen einer Plangruppe und Hinzufügen eines Schritts zum Starten von OAC in der Standbydatenbank

Aufgabe 10.4.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird OAC in Region 1 gestartet.

Alles in dieser Aufgabe ist dasselbe wie Aufgabe 10.3.3, mit Ausnahme der Elemente, die in Abbildung 10-11 unten angezeigt werden.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-start-stop.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie start als ersten Parameter und die OCI-Regions-ID als zweiten Parameter hinzu.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 10-11: Parameter zum Erstellen des Planschritts zum Starten von OAC in der Standbydatenbank

Aufgabe 10.4.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Starten von OAC wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 10-12 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 10-12: Schließen Sie das Hinzufügen einer Plangruppe und eines Schritts ab, um OAC in der Standbydatenbank zu starten

Aufgabe 10.5: Plangruppe erstellen, um Snapshot in Region 1 wiederherzustellen (Standby)

Die dritte benutzerdefinierte Plangruppe stellt OAC in der Standbyregion 1 mit dem periodischen Snapshot wieder her, der aus dem Objektspeicher-Bucket in Region 2 in Region 1 repliziert wird. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oac-register-snapshot.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

Aufgabe 10.5.1: "Plangruppe hinzufügen" auswählen

Klicken Sie wie zuvor auf Gruppe hinzufügen, um zu beginnen.

Abbildung 10-13: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Wiederherstellen des Snapshots in der Standbydatenbank

Aufgabe 10.5.2: Plangruppennamen angeben, sortieren und Schritt hinzufügen

Erstellen Sie eine DR-Plangruppe, um OAC in der Standbyregion 1 wiederherzustellen.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. Fügen Sie in diesem Fall die benutzerdefinierte Plangruppe nach der im vorherigen Schritt erstellten benutzerdefinierten Plangruppe ein, um OAC zu starten.
3. Wählen Sie die integrierte Plangruppe OAC (Standby) starten.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zur Wiederherstellung des OAC-Snapshots angeben.

Abbildung 10-14: Parameter zum Erstellen einer Plangruppe und Hinzufügen eines Schritts zum Wiederherstellen des OAC-Snapshots in der Standbydatenbank

Aufgabe 10.5.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird der OAC-Snapshot in Region 1 wiederhergestellt. Der Snapshot wird während normaler Vorgänge in der primären Region erstellt und in einem Objektspeicher-Bucket in Region 1 gespeichert.

Alles in dieser Aufgabe ist dasselbe wie Aufgabe 10.3.3, mit Ausnahme der Elemente, die in Abbildung 10-15 unten angezeigt werden.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-start-stop.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie OCI-Regions-ID als einzigen Parameter hinzu (in diesem Beispiel PHX).
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 10-15: Parameter zum Erstellen des Planschritts zum Wiederherstellen des Snapshots in der Standbydatenbank

Aufgabe 10.5.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Wiederherstellen von OAC wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 10-16 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 10-16: Hinzufügen von Plangruppe und Schritt zum Wiederherstellen des Snapshots in der Standbydatenbank abschließen

Aufgabe 10.6: Plangruppe erstellen, um Snapshot in Region 1 umzukehren (Standby)

Die letzte benutzerdefinierte Plangruppe ändert den in Aufgabe 10.5 oben beschriebenen Cron-Job. Full Stack DR ruft OAC-chg-cronjob.sh auf, um den Cron-Job zu ändern und den exportierten OAC-Snapshot im Speicher-Bucket in Region 2 zu speichern.

Aufgabe 10.6.1: Plangruppe hinzufügen auswählen

Klicken Sie wie zuvor auf Gruppe hinzufügen, um zu beginnen.

Abbildung 10-17: Beginnen Sie mit dem Hinzufügen einer Plangruppe zur umgekehrten Snapshot-Kopie in der Standbydatenbank

Aufgabe 10.6.2: Plangruppennamen angeben, sortieren und Schritt hinzufügen

Erstellen Sie eine DR-Plangruppe, um den OAC-Snapshot in Region 2 umzukehren.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Es ist immer ratsam, dem Gruppennamen "(Standby)" hinzuzufügen, sodass auf einen Blick ersichtlich ist, welcher Bereich die Schritte gelten.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall werden wir unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe einfügen, die den OAC-Snapshot in Region 1 wiederherstellt.
3. Wählen Sie die integrierte Plangruppe OAC-Snapshot wiederherstellen (Standby).
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Starten von OAC angeben.

Abbildung 10-18: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Reverse Snapshot-Kopieren in der Standbydatenbank

Aufgabe 10.6.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall kehrt er den OAC-Snapshot um, sodass er in Region 2 gespeichert wird, die nach Abschluss des Switchovers automatisch zur Standbyregion wird.

Alles in dieser Aufgabe ist dasselbe wie Aufgabe 10.3.3, mit Ausnahme der Elemente, die in Abbildung 10-19 unten angezeigt werden.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-chg-cronjob.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie den OCI-Regionsschlüssel für Region 2 (phx in diesem Beispiel) als ersten Parameter und Regionsschlüssel für Region 1 (iad in diesem Beispiel) als zweiten Parameter hinzu.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 10-19: Parameter zum Erstellen des Planschritts zum Rückgängigmachen der Snapshot-Kopie in der Standbydatenbank

Aufgabe 10.6.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Umkehren der OAC-Snapshot-Richtung wird jetzt der DR-Plangruppe hinzugefügt, wie in Abbildung 10-20 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

3.
Abbildung 10-20: Schließen Sie das Hinzufügen einer Plangruppe und eines Schritts ab, um die Snapshot-Kopie in der Standbydatenbank umzukehren

Der Switchover-Plan sollte jetzt die vier DR-Plangruppen für OAC enthalten, wie im folgenden Screenshot gezeigt. Möglicherweise haben Sie zusätzliche Plangruppen, wenn Ihre Schutzgruppe andere Anwendungen oder OCI-Services zusammen mit OAC enthält.

Abbildung 10-21: Vier benutzerdefinierte Plangruppen anzeigen, die dem Switchover-Plan hinzugefügt wurden

Aufgabe 11: Failover-Plan in Region 1 (Ashburn) anpassen

In dieser Aufgabe wird erläutert, wie Sie benutzerdefinierte, benutzerdefinierte DR-Plangruppen und Schritte zum Verwalten der Dinge hinzufügen, die während eines Failovers für OAC in Region 1 bei einem tatsächlichen Ausfall oder Verlust des Zugriffs auf Region 2 ausgeführt werden müssen. Dies ist eine Teilmenge derselben Schritte, die gerade zum Switchover-Plan in Aufgabe 10 oben hinzugefügt wurden. Dem Failover-Plan werden jedoch nur Schritte hinzugefügt, die in der Standby-Region 1 ausgeführt werden, da davon ausgegangen wird, dass der Bereich 2 während eines Failovers vollständig nicht zugänglich ist.

1. Starten Sie OAC in der Standbyregion 1, nachdem Sie VMs gestartet haben.
2. Stellen Sie den periodischen Snapshot in der Standby-Region 1 wieder her. Der periodische Snapshot wurde im Rahmen von Aufgabe 1.4 oben eingerichtet.
3. Ändern Sie den Snapshot-Cron-Job in der Standbyregion 1. Der Cron-Job wurde im Rahmen von Aufgabe 1.4 oben eingerichtet.

Aufgabe 11.1: Plangruppe erstellen, um OAC in Region 1 zu starten (Standby)

Navigieren Sie zu dem Failover-Plan, der in Aufgabe 9 erstellt wurde.

1. Stellen Sie sicher, dass Standbyregion 1 weiterhin der aktuelle Regionskontext in der Konsole ist.
2. Wählen Sie den Failover-Plan aus.

Abbildung 11-1: So erstellen Sie die Anpassung des Failover-Plans in Region 1

Aufgabe 11.2: Plangruppe hinzufügen auswählen

Die erste benutzerdefinierte Plangruppe startet OAC, das in Standby-Region 1 ausgeführt wird. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oac-start-stop.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

1. Klicken Sie zum Beginnen auf "Gruppe hinzufügen".

Abbildung 11-2: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Starten von OAC.

Aufgabe 11.2.1: Plangruppennamen angeben, sortieren und Schritt hinzufügen

Eine DR-Plangruppe kann viele Schritte enthalten, die alle parallel ausgeführt werden. Wir fügen gerade einen einzelnen Schritt hinzu, um ein bash-Skript auszuführen, um OAC zu starten.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Dies ist natürlich optional. Es empfiehlt sich jedoch, eine Notiz hinzuzufügen, in welcher Region die Plangruppe die Schritte ausführt. In diesem Fall ist es die Standby-Region 1, daher haben wir dem Gruppennamen "(Standby)" hinzugefügt.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall fügen wir die benutzerdefinierte Plangruppe nach der integrierten Plangruppe ein, mit der die replizierten VMs in Region 1 gestartet werden.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen starten (Standby) aus
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Starten von OAC angegeben wird

Abbildung 11-3: Parameter zum Erstellen einer Plangruppe und Hinzufügen eines Schritts zum Starten von OAC

Aufgabe 11.2.2: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird OAC in Region 2 gestartet, wie in Abbildung 7-4 unten dargestellt.

Wir werden alle Felder in diesem Dialog erklären, aber lassen Sie dieses Detail in allen verbleibenden Screenshots in den folgenden Schritten weg, da wir gerade denselben Prozess wiederholt durchführen.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Der DR-Plan muss gestoppt werden, wenn das Skript OAC nicht starten kann. Dadurch kann jeder sehen, dass es ein Problem gibt und es beheben. Full Stack DR bietet die Möglichkeit, den Switchover-Plan weiter auszuführen, nachdem das Problem behoben wurde.
3. Der Standardwert, bevor Full Stack DR einen Fehler deklariert, beträgt eine Stunde. Dieser Wert kann auf 30 Minuten geändert werden oder was immer als realistischerer Timeoutwert empfunden wird.
4. Wählen Sie immer die Region aus, in der der DR-Kontrollknoten gerade ausgeführt wird, nicht, in der er während eines Switchovers ausgeführt wird. Full Stack DR verfolgt, wo die VM ausgeführt wird, sodass Sie nur angeben müssen, wo sie sich gerade befindet. In diesem Fall wird der DR-Kontrollknoten in Region 2 (Phoenix) ausgeführt.
5. Wählen Sie Lokales Skript ausführen aus, um Full Stack DR zu informieren, dass sich das Skript auf einer Compute-Instanz befindet. Die bash-Skripte wurden in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen.
6. Wählen Sie das richtige Compartment aus, das den DR-Kontrollknoten enthält. Dabei kann es sich um ein beliebiges Compartment handeln. Wählen Sie die Compute-Instanz aus, die als DR-Kontrollknoten angegeben wurde (es kann sich um einen Anwendungsserver oder eine VM handeln, die nur für dieses Projekt/Tutorial erstellt wurde).
7. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-start-stop.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie start als ersten Parameter und die OCI-Regions-ID als zweiten Parameter hinzu.
8. Geben Sie opc als Benutzer an, um das Skript auszuführen.
9. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen

Abbildung 11-4: Parameter zum Erstellen des Planschritts zum Starten von OAC in der Standbydatenbank

Aufgabe 11.2.3: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Starten von OAC wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 11-5 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 11-5: Hinzufügen von Plangruppe und Schritt zum Starten von OAC abschließen

Aufgabe 11.3: Plangruppe erstellen, um Snapshot in Region 1 wiederherzustellen (Standby)

Die zweite benutzerdefinierte Plangruppe stellt OAC in der Standbyregion 1 mit dem periodischen Snapshot wieder her, der aus dem Objektspeicher-Bucket in Region 2 in Region 1 repliziert wird. Dieselbe Aufgabe, die dem Switchover-Plan hinzugefügt wurde, ist Aufgabe 9.

Aufgabe 11.3.1: Plangruppe hinzufügen auswählen

Klicken Sie wie zuvor auf Gruppe hinzufügen, um zu beginnen.

Abbildung 11-6: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Wiederherstellen des Snapshots in der Standbydatenbank

Aufgabe 11.3.2: Plangruppennamen angeben, sortieren und Schritt hinzufügen

Erstellen Sie eine DR-Plangruppe, um OAC in der Standbyregion 1 wiederherzustellen.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. Fügen Sie in diesem Fall die benutzerdefinierte Plangruppe nach der im vorherigen Schritt erstellten benutzerdefinierten Plangruppe ein, um OAC zu starten.
3. Wählen Sie die integrierte Plangruppe OAC (Standby) starten.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zur Wiederherstellung des OAC-Snapshots angeben.

Abbildung 11-7: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Recovery des OAC-Snapshots in der Standbydatenbank

Aufgabe 11.3.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird der OAC-Snapshot in Region 1 wiederhergestellt. Der Snapshot wird während normaler Vorgänge in der primären Region erstellt und in einem Objektspeicher-Bucket in Region 1 gespeichert.

Alles in dieser Aufgabe ist dasselbe wie Aufgabe 11.3.2, mit Ausnahme der Elemente, die in Abbildung 11-8 unten angezeigt werden.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-start-stop.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie OCI-Regions-ID als einzigen Parameter hinzu (in diesem Beispiel PHX).
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 11-8: Parameter zum Erstellen des Planschritts zum Wiederherstellen des Snapshots in der Standbydatenbank

Aufgabe 11.3.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Wiederherstellen von OAC wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 11-9 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 11-9: Hinzufügen von Plangruppe und Schritt zum Wiederherstellen des Snapshots in der Standbydatenbank abschließen

Aufgabe 11.4: Plangruppe erstellen, um Snapshot in Region 1 umzukehren (Standby)

Die letzte benutzerdefinierte Plangruppe ändert den Cron-Job, sodass der OAC-Snapshot in Region 2 gespeichert wird, sobald wieder darauf zugegriffen werden kann. Dies ist dieselbe Aufgabe, die dem Switchover-Plan in Aufgabe 10 hinzugefügt wurde.

Aufgabe 11.4.1: Plangruppe hinzufügen auswählen

Klicken Sie wie zuvor auf Gruppe hinzufügen, um zu beginnen.

Abbildung 11-10: Beginnen Sie mit dem Hinzufügen einer Plangruppe zur umgekehrten Snapshot-Kopie in der Standbydatenbank

Aufgabe 11.4.2: Plangruppennamen angeben, sortieren und Schritt hinzufügen

Erstellen Sie eine DR-Plangruppe, um den OAC-Snapshot in Region 2 umzukehren.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Es ist immer ratsam, dem Gruppennamen "(Standby)" hinzuzufügen, sodass auf einen Blick ersichtlich ist, welcher Bereich die Schritte gelten.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall werden wir unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe einfügen, die den OAC-Snapshot in Region 1 wiederherstellt.
3. Wählen Sie die integrierte Plangruppe OAC-Snapshot wiederherstellen (Standby).
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Starten von OAC angeben.

Abbildung 11-11: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Reverse Snapshot-Kopieren in der Standbydatenbank

Aufgabe 11.4.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall kehrt er den OAC-Snapshot um, sodass er in Region 2 gespeichert wird, die nach Abschluss des Switchovers automatisch zur Standbyregion wird.

Alles in dieser Aufgabe ist dasselbe wie Aufgabe 11.3.2, mit Ausnahme der Elemente, die in Abbildung 11-19 unten angezeigt werden.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oac-chg-cronjob.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie den OCI-Regionsschlüssel für Region 2 (in diesem Beispiel "phx") als ersten Parameter und Regionsschlüssel für Region 1 (siehe Beispiel) als zweiten Parameter hinzu.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 11-12: Parameter zum Erstellen des Planschritts zum Rückgängigmachen der Snapshot-Kopie in der Standbydatenbank

Aufgabe 11.4.4: Hinzufügen von Plangruppe und Schritt abschließen

Der Schritt zum Umkehren der OAC-Snapshot-Richtung wird jetzt der DR-Plangruppe hinzugefügt, wie in Abbildung 11-13 unten dargestellt.

1. Zeigt den Planschritt an, der gerade hinzugefügt wurde.
2. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 11-13: Schließen Sie das Hinzufügen einer Plangruppe und eines Schritts ab, um die Snapshot-Kopie in der Standbydatenbank umzukehren

Der Failover-Plan sollte nun die drei DR-Plangruppen für OAC enthalten, wie im folgenden Screenshot gezeigt. Möglicherweise haben Sie zusätzliche Plangruppen, wenn Ihre Schutzgruppe andere Anwendungen oder OCI-Services zusammen mit OAC enthält.

Abbildung 11-14: Die drei benutzerdefinierten Plangruppen werden dem Failover-Plan hinzugefügt

Nächste Schritte

Full Stack DR für OAC sollte an dieser Stelle vollständig implementiert werden. Die vollständige Funktionalität sollte jedoch vor der Verwendung von Full Stack DR für die Produktion validiert werden. Alle Failover- und Switchover-Pläne sollten ausgeführt werden, um sicherzustellen, dass alles wie erwartet funktioniert und das Recovery-Team den gesamten Prozess vollständig versteht.

Switchover-Pläne testen

Switchover-Pläne wurden entwickelt, um alle Artefakte zu bereinigen und sicherzustellen, dass alle Rollen für integrierte Recovery-Schritte wie Load Balancer, Blockspeicher, Dateisysteme, BaseDB, ExaCS und Autonomous Data Base ohne menschliches Eingreifen aus der Standbyregion wiederhergestellt werden können.

Failover-Pläne testen

Failover sind anders. Failover können naturgemäß keine Artefakte bereinigen oder sicherstellen, dass Services und Datenbanken in der ausgefallenen Region bereit sind, Workloads zurück in Region 1 zu verlagern. Das Recovery-Team muss Aufgaben verstehen und ausführen, um sicherzustellen, dass Data Guard den richtigen Status aufweist, Artefakte für Speicher- und Compute-Instanzen beendet wurden usw. Lesen Sie DR-Konfiguration nach einem Failover zurücksetzen in der OCI Full Stack DR-Dokumentation, um den Prozess zu verstehen.

Alle DR-Pläne für endgültige Annahme validieren

Das Recovery-Team muss eine abschließende Validierung durchführen, um die Bereitschaft von Full Stack DR-Schutzgruppen und Plänen für Produktions-Workloads zu demonstrieren. Region 2 (Phoenix) sollte die primäre Region an diesem Punkt im Prozess sein. Gehen Sie folgendermaßen vor, um die endgültige Validierung aller Pläne zu beginnen:

• Test-Switchover von Region 2 (primär) zurück zu Region 1 (Standby).
• Testen Sie das Failover von Region 1 (primär) zu Region 2 (Standby).
• Region 1 (primär) vorbereiten für Failover von Region 2.
• Testen Sie das Failover von Region 2 (primär) zu Region 1 (Standby).
• Region 2 (primär) vorbereiten für einen Failover oder Switchover zu Region 2.
• Die DR-Schutzgruppen und der Anwendungsstack müssen sich in einem normalen Betriebszustand befinden und zu diesem Zeitpunkt für ein Failover oder Switchover bereit sein.

Verwandte Links

• Referenzarchitektur: Oracle Analytics Cloud-DR-Topologie mit Full Stack Disaster Recovery Service entwerfen im Oracle Architecture Center

• Technisches Dokument: Disaster Recovery-Konfiguration für Oracle Analytics Cloud

• Beispielskripte: Laden Sie Beispielskripte von GitHub herunter

• Blog: Disaster-Recovery-Plan für Oracle Analytics Cloud mit manueller Switchover-Methode

• Full Stack DR Oracle Analytics Cloud-Playlist unter YouTube

  • Stellen Sie Oracle Analytics Cloud für DR bereit (Video 1)

  • Automatisierung der Wiederherstellung für Oracle Analytics Cloud (Video 2)

  • Skripte zur Automatisierung der Wiederherstellung für Oracle Analytics Cloud (Video 3)

• OCI Full Stack Disaster Recovery - Produktseite

• OCI Full Stack Disaster Recovery - Dokumentation

• Full Stack Disaster Recovery - Benutzerdefinierte Gruppenskripte

• Werden Sie Teil des öffentlichen Slack-Kanals #full-stack-dr

Danksagungen

• Autor - Bala Guddeti (NACE Cloud Solution Specialist)

• Mitwirkende - Greg King (Full Stack Disaster Recovery Product Manager), Suraj Ramesh (Full Stack Disaster Recovery Product Manager)

Weitere Lernressourcen

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

Produktdokumentation finden Sie im Oracle Help Center.

---

Titel und Copyright-Informationen

Automate Recovery for Oracle Analytics Cloud Using OCI Full Stack Disaster Recovery

F88861-01

December 2023

Copyright © 2023, Oracle and/or its affiliates.