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.

Automatisieren Sie das Recovery für Oracle Enterprise Performance Management mit OCI Full Stack Disaster Recovery

Teil 1: Einführung

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

In diesem Tutorial werden die Verfahren zur Verwendung des OCI Full Stack DR-Service zur Verwaltung von Switchover- und Failover-Prozessen für eine Oracle Enterprise Performance Management-Systemumgebung 11.1.2.x und 11.2.x innerhalb eines OCI-Disaster Recovery Frameworks beschrieben. Es ist wichtig zu beachten, dass die Konfiguration der Systemtopologie und anderer Lebenszyklusaktivitäten (wie Patching, Testen, Erweitern usw.) nicht in den Geltungsbereich von OCI Full Stack DR fallen.

Bei der Disaster Recovery-(DR-)Strategie wird eine umfassende Replikation von Boot- und Block-Volumes für die Anwendung und von Oracle Data Guard für die Datenbank von der Produktionsumgebung auf die Standbysite verwendet. Dadurch wird die Konfiguration des Standbyspeicherorts erheblich vereinfacht. Diese Methode entspricht den DR-Richtlinien, die in der EPM System Deployment Options Guide beschrieben sind und die Empfehlungen für das Disaster Recovery für Fusion Middleware einhalten.

Oracle Enterprise Performance Management (Oracle EPM) und Hyperion EPM werden im Tutorial austauschbar verwendet.

Oracle Enterprise Performance Management ist normalerweise Teil eines größeren Systems

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

Dieses Tutorial konzentriert sich aus Gründen der Übersichtlichkeit ausschließlich auf Oracle EPM System. In der Praxis ist Oracle EPM in der Regel eine Komponente eines größeren Geschäftssystems, das verschiedene Services und Anwendungen innerhalb einer einzelnen OCI Full Stack DR-Schutzgruppe und einer Reihe von DR-Plänen umfasst. Sie werden wahrscheinlich ähnliche Oracle Help Center-(OHC-)Tutorials für andere Anwendungen und Services wie PeopleSoft,Oracle WebLogic Server,Oracle Analytics Cloud,Oracle Integration befolgen.

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.

OCI 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 nachweislich funktioniert. Wenn Ihr Geschäftssystem mehr als Oracle EPM umfasst, 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 Oracle EPM erfordert, dass OCI Full Stack DR eine Reihe von benutzerdefinierten Shellskripten während eines Recovery-Vorgangs wie Failover oder Switchover ausführt. Die in diesem Tutorial referenzierten Skripte werden vom EMEA Cloud Architecture Specialists-Team bereitgestellt und sind im Oracle EPM-Repository GitHub verfügbar, das speziell auf diese Hyperion EPM DR-Lösung zugeschnitten ist. Die Skripte werden in eine Compute-Instanz heruntergeladen, die Teil des Anwendungsstacks ist, den OCI 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.

Die folgenden Skripte dienen allgemeinen Anleitungen. Sie können entweder eigene Skripte verwenden oder die Skripte entsprechend Ihren Unternehmensrichtlinien und Sicherheitsanforderungen anpassen.

Oracle EPM - Deployment-Architektur

In diesem Tutorial verwenden wir die Topologie zum Verschieben von Instanzen für die Oracle EPM-Anwendung. In der allgemeinen Terminologie werden bewegte Instanzen als Cold VM/Pilot Light DR-Topologie bezeichnet. Anwendungs-VMs werden nur in der primären Region bereitgestellt. Während der DR-Laufzeit werden VMs in der Standbyregion erstellt. Oracle DB-System mit Oracle Data Guard muss in der Primär- und Standbyregion erstellt werden. Bevor die OCI Full Stack DR-Lösung implementiert werden kann, muss das primäre Hyperion EPM System in einer OCI-Region installiert und vollständig konfiguriert sein.

Dieses Design basiert auf der Referenz-DR-Architektur für Hyperion auf OCI, die im Detail überprüft werden kann. Weitere Informationen finden Sie unter Infrastruktur für das Deployment von Oracle Enterprise Performance Management in der Cloud entwerfen.

Privater OCI Load Balancer

Der Traffic Ihrer internen und On-Premise-Benutzer fließt über IPSec-VPN-Tunnel oder FastConnect-Virtual Circuits zum dynamischen Routinggateway (DRG), das an das VCN angehängt ist. Ein privater Load Balancer fängt die Anforderungen ab und verteilt sie an die private Web Tier.

Die Web Tier wird auf einer Compute-Instanz gehostet, die an ein privates Subnetz angehängt ist.

Application Tier

Alle Compute-Instanzen in der Application Tier sind an ein privates Subnetz angehängt. Diese Isolation auf Netzwerkebene schützt die Anwendungen vor unautorisiertem Netzwerkzugriff und anderen Ressourcen in der Topologie.

Das Servicegateway ermöglicht den privaten Compute-Instanzen in der Anwendungsebene den Zugriff auf Yum- und WSUS-Server in der Region, um Betriebssystemupdates und zusätzliche Packages abzurufen. Darüber hinaus können Sie mit dem Servicegateway die Anwendungen in OCI Object Storage innerhalb der Region sichern, ohne das öffentliche Internet zu durchlaufen.

In Block-Volumes und Dateisystemen gespeicherte Daten werden mit regionsübergreifender Replikation (CRR) in einer Standbyregion repliziert.

Datenbank-Tier

Oracle Base Database Service hostet die EPM System-Schemas. Daten werden mit Data Guard mit der Standby-Region synchronisiert.

Abbildung 1: Oracle EPM-Referenzarchitektur

Vertrautheit mit dem gesamten Prozess

Die EMEA OCI Specialist- und OCI Full Stack DR-Engineering-Teams haben eine Reihe von Begleitvideos für dieses Tutorial erstellt, um den gesamten Prozessablauf zu verstehen. Diese Videos sind Teil einer OCI Full Stack DR Oracle EPM-Wiedergabeliste in YouTube, auf die über die folgenden Links zugegriffen werden kann:

• Video 1: Oracle EPM für Disaster Recovery bereitstellen
• Video 2: Disaster-Recovery-Vorgänge für Oracle EPM mit OCI Full Stack DR automatisieren
• Video 3: Skripte zur Automatisierung der Wiederherstellung für Oracle EPM

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

Dieser Teil beginnt mit den schrittweisen Anweisungen, die zum Hinzufügen von Oracle EPM zu OCI Full Stack DR erforderlich sind.

Ziele

In diesem Tutorial werden die folgenden Schritte behandelt, in denen erläutert wird, wie Sie das Recovery für Oracle EPM mit Full Stack DR automatisieren:

1. Aufgabe 1: Oracle EPM für Disaster Recovery bereitstellen
   1. Regionsübergreifende Oracle Data Guard für Oracle Base Database Service konfigurieren
   2. DR-Kontrollknoten für die Ausführung benutzerdefinierter Automatisierung vorbereiten
   3. Block-Volume-Gruppe erstellen
   4. Oracle Cloud Infrastructure Identity and Access Management-(OCI IAM-)Policys für Full Stack DR erstellen
   5. OCI-IAM-Policys für andere OCI-Services erstellen
   6. OCI Object Storage-Buckets für Logs erstellen
   7. Standby-Load Balancer erstellen (optional)
2. Aufgabe 2: DR-Schutzgruppen (DRPG) erstellen
3. Aufgabe 3: Mitglieder zu DRPGs der Regionen 1 und 2 hinzufügen
4. Aufgabe 4: Grundlegende DR-Pläne in Region 2 erstellen (Newport)
   1. Switchover-Plan erstellen
   2. Failover-Plan erstellen
5. Aufgabe 5: Switchover-Plan in Region 2 (Newport) anpassen
6. Aufgabe 6: Failover-Plan in Region 2 (Newport) anpassen
7. Aufgabe 7: Switchover-Plan in Region 2 (Newport) ausführen
8. Aufgabe 8: Grundlegende DR-Pläne in Region 1 (London) erstellen
   1. Switchover-Plan erstellen
   2. Failover-Plan erstellen
9. Aufgabe 9: Switchover-Plan in Region 1 (London) anpassen
10. Aufgabe 10: Failover-Plan in Region 1 (London) anpassen

Definitionen und Annahmen im gesamten Tutorial

Bereiche

Region 1 ist London

• London 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 Newport

• Newport startet 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 Oracle EPM und OCI Full Stack DR in jedem Compartment-Schema organisieren, das Ihren Standards für die 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.

DR-Kontrollknoten

Der DR-Kontrollknoten ist eine beliebige Compute-Instanz, die Sie zum Hosten benutzerdefinierter Skripte angeben, die bestimmte Aufgaben zum Wiederherstellen des EPM-Systems ausführen. Die Skripte werden von Full Stack DR während eines Recovery-Vorgangs aufgerufen. Jede vorhandene Compute-Instanz, die Mitglied einer DR-Schutzgruppe (DRPG) ist, kann der Kontrollknoten sein. In diesem Beispiel hostet der EPM System-Anwendungsserver alle benutzerdefinierten Skripte, die im Recovery-Prozess verwendet werden. In diesem Tutorial sind sowohl der Anwendungsknoten als auch der Kontrollknoten identisch.

Voraussetzungen

• Ein vollständig konfiguriertes EPM-System muss in einer OCI-Region bereitgestellt werden. Es sollte einen Oracle Base Database Service mit einer Lizenz verwenden, die das Deployment eines regionsübergreifenden Oracle Data Guard ermöglicht.
• VCN und Subnetze in der Standbyregion. Es wird empfohlen, die Netzwerktopografie aus der primären Region in der Standby-Region zu spiegeln. Für die regionsübergreifende Oracle Data Guard-Replikation muss VCN-Peering zwischen Primär- und Standbyregionen aktiviert sein. Daher dürfen die VCNs keine sich überschneidenden IP-CIDR-Bereiche aufweisen.

Aufgabe 1: Oracle EPM für Disaster Recovery bereitstellen

OCI Full Stack DR ist an diesem Schritt nicht beteiligt.

Aufgabe 1.1: Regionsübergreifende Oracle Data Guard für Oracle Base Database Service konfigurieren

Informationen zum regionsübergreifenden Deployment von Oracle Data Guard für Oracle Base Database Service finden Sie unter Oracle Data Guard auf einem DB-System verwenden.

Bei der Synchronisierung von Datenbanken in Ihrem System mit Oracle Data Guard ist es wichtig, denselben Datenbankservicenamen oder TNS-Alias sowohl für die Primär- als auch für die Standbydatenbank zu verwenden. Diese Übung minimiert die Änderungen, die nach einem Switchover auf der Anwendungsebene erforderlich sind, und gewährleistet so einen reibungslosen Übergang. Ausführliche Anleitungen finden Sie im Abschnitt "Database Considerations" in der Fusion Middleware DR-Dokumentation. Dort werden verschiedene Ansätze ausführlich beschrieben.

Aufgabe 1.2: DR-Kontrollknoten für die Ausführung benutzerdefinierter Automatisierung vorbereiten

Geben Sie eine Compute-Instanz als DR-Kontrollknoten für EPM Full Stack DR an. Dabei kann es sich um eine vorhandene Compute-Instanz oder um eine Compute-Instanz handeln, die nur für diesen Zweck erstellt wurde. Weitere Details 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 Oracle Cloud Agent konfiguriert wurden: Befehle auf einer Instanz ausführen.

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 Gastbetriebssystem in beiden Regionen vornehmen, beibehalten, wenn für diese Rolle nicht verschiebbare Compute-Ressourcen verwendet werden.

Laden Sie die benutzerdefinierten Skripte von hier in den DR-Kontrollknoten herunter: Oracle EPM Github-Skripte, die speziell für dieses EPM System-DR-Beispiel geschrieben wurden. Die unten gezeigten Skripte müssen in jedes Unterverzeichnis auf der Compute-Instanz kopiert werden, das als DR-Kontrollknoten fungiert. In diesem Tutorial verwenden wir auch den EPM-Anwendungsknoten als DR-Kontrollknoten. Die Skripte wurden speziell für dieses Beispiel der EPM System-Wiederherstellung erstellt und müssen für die Verwendung in Ihrer Recovery-Lösung geändert werden. In diesem Tutorial wird die EPM-App auf einer Windows-VM ausgeführt. Daher werden die Powershell-(ps1-)Skripte verwendet. Wenn Sie eine Linux-VM verwenden, sind Shellskripte im selben Github-Repository verfügbar. Da wir EPM VM zur Ausführung der Skripte verwenden, wird DR Control Node auf dieselbe EPM VM verwiesen.

Aufgabe 1.3: Block-Volume-Gruppe erstellen

Erstellen Sie eine Block-Volume-Gruppe in Region 1, und stellen Sie sicher, dass sie 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. Weitere Informationen finden Sie unter Volume-Gruppe erstellen.

Stellen Sie sicher, dass alle anderen Boot- und Blockvorgänge, die zu anderen beweglichen Compute-Vorgängen für dieses OCI-Full Stack-DR-Projekt gehören, auch zu der Block-Volume-Gruppe gehören, die in Region 2 repliziert wird.

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

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

• Policys für OCI Full Stack DR
• Identity and Access Management-(IAM-)Policys zur Verwendung von Full Stack DR konfigurieren

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

OCI 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 hier erläuterte Services: Policys für andere von Full Stack Disaster Recovery verwaltete Services.

Aufgabe 1.6: OCI Object Storage-Buckets für DRPG-Logs erstellen

Aufgabe 1.6.1: Zu OCI Object Storage navigieren

Navigieren Sie zu Object Storage und Archive Storage, wie in Abbildung 1.1 dargestellt.

1. Stellen Sie sicher, dass der Browserkontext auf Region 1 (London) gesetzt ist.
2. Wählen Sie Speicher.
3. Wählen Sie Buckets aus.

Abbildung 1.1: Navigieren Sie zum Objektspeicher

Aufgabe 1.6.2: OCI Object Storage-Bucket in Region 1

Erstellen Sie einen OCI Object Storage-Bucket in Region 1. In einem späteren Schritt wird der Bucket der DR-Schutzgruppe in Region 1 zugewiesen.

1. Wählen Sie das Compartment aus, das EPM-Systemressourcen enthält.
2. Klicken Sie auf Bucket erstellen.
3. Geben Sie dem Bucket einen aussagekräftigen Namen, der leicht identifiziert, für welche Anwendung und welchen Zweck er zuständig ist.
4. Verwenden Sie den Standardwert für Default Storage Tier und Verschlüsselung.
5. Klicken Sie auf Erstellen, um den Bucket zu erstellen.

Abbildung 1.2: Objektspeicher-Bucket in Region 1 erstellen

Aufgabe 1.6.3: OCI Object Storage-Bucket in Region 2

Führen Sie denselben Prozess aus, um einen Objektspeicher-Bucket in Region 2 (Newport) zu erstellen. Stellen Sie sicher, dass Sie den Bereich Newport auswählen. In einem späteren Schritt wird der Bucket der DR-Schutzgruppe in Region 2 zugewiesen.

1. Ändern Sie den Kontext in Region 2.
2. Wählen Sie das Compartment aus, das EPM System-bezogene Ressourcen in Region 2 enthält.
3. Klicken Sie auf Erstellen, um den Bucket zu erstellen.

Abbildung 1.3: Objektspeicher-Bucket in Region 2 erstellen

Aufgabe 1.7: (Optional) OCI Load Balancer in Standbyregion erstellen

Die Verwendung von OCI Load Balancer ist optional. Wenn Ihr EPM-System sie nicht enthält, überspringen Sie diese Aufgabe.

OCI Load Balancer in der Standbyregion erstellen:

1. Spiegeln Sie die Konfiguration des primären Load Balancers.
2. Erstellen Sie ein leeres Backend-Set in diesem Load Balancer. An dieser Stelle in der Standby-Region gibt es keine Backends, die in die Konfiguration aufgenommen werden können. Daher sollte nur ein leeres Backend-Set erstellt werden.

Konfiguration während Switchover oder Failover:

1. Die Konfiguration des primären EPM System-Backend-Sets wird in das leere Standby-Backend-Set kopiert.

Zertifikate und Listener:

1. Wenn Sie Ihre eigenen Zertifikate verwenden, laden Sie sie in den Standby-Load Balancer.
2. Konfigurieren Sie Listener so, dass sie mit der Konfiguration des primären Load Balancers übereinstimmen.

Update nach Switchover:

1. Aktualisieren Sie nach dem Switchover die DNS-Informationen so, dass sie auf die IP-Adresse des Standby-Load Balancers verweisen.

Weitere Informationen finden Sie unter Überblick über Load Balancer.

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

Hinweis: Überspringen Sie Aufgabe 2 vollständig, wenn Oracle EPM 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 2.1: Zu DR-Schutzgruppen navigieren

Navigieren Sie zu DR-Schutzgruppen (OCI Full Stack DR), wie in Abbildung 2-1 unten dargestellt.

1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 1 (London) gesetzt ist.
2. Klicken Sie auf Migration und Disaster Recovery.
3. Klicken Sie auf DR-Schutzgruppen.

Abbildung 2-1: Zu DR-Schutzgruppen navigieren

Aufgabe 2.2: Schutzgruppe in Region 1 erstellen

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

1. Wählen Sie das Compartment aus, in dem das DRPG erstellt werden soll. Dies kann dasselbe Compartment sein, in dem EPM System-Ressourcen vorhanden sind.
2. Klicken Sie auf DR-Schutzgruppe erstellen, um das Dialogfeld zu öffnen.
3. Verwenden Sie einen sinnvollen Namen für das DRPG.
4. Wählen Sie den in Aufgabe 2 erstellten Objektspeicher-Bucket für Region 1 aus.
5. Klicken Sie auf Erstellen.

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

Aufgabe 2.3: Schutzgruppe in Region 2 erstellen

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

1. Ändern Sie den OCI-Regionskontext in Region 2 (Newport).
2. Wählen Sie das Compartment aus, in dem das DRPG erstellt werden soll. Dies kann dasselbe Compartment sein, in dem EPM System-Ressourcen vorhanden sind.
3. Klicken Sie auf DR-Schutzgruppe erstellen, um das Dialogfeld zu öffnen.
4. Verwenden Sie einen sinnvollen Namen für das DRPG.
5. Wählen Sie den Objektspeicher-Bucket aus, der in Aufgabe 2 für Region 2 erstellt wurde.
6. Klicken Sie auf Erstellen.

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

Aufgabe 2.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ß OCI Full Stack DR, welche beiden Regionen für die Wiederherstellung des Oracle EPM System zusammenarbeiten. Die Rollen der Primär- und Standbydatenbank werden automatisch von OCI Full Stack DR im Rahmen einer DR-Vorgang-/DR-Planausführung geändert. Es ist nicht erforderlich, die Rollen jederzeit manuell zu verwalten.

Aufgabe 2.4.1: Zuordnung beginnen

1. Stellen Sie sicher, dass der OCI-Regionskontext auf Region 1 (London) gesetzt ist.
2. Klicken Sie auf Zuordnen, um den Prozess zu starten.

Abbildung 2.4.1: DRPG-Verknüpfung beginnen

Aufgabe 2.4.2: Schutzgruppen in Region 1 und Region 2 zuordnen

Geben Sie die Parameter an, wie in Abbildung 2.4.2 dargestellt.

1. Wählen Sie die primäre Rolle aus. OCI Full Stack DR weist die Standbyrolle automatisch Region 2 zu.
2. Wählen Sie Region 2 (Newport), in der das andere DRPG erstellt wurde.
3. Wählen Sie das Peer-DRPG aus, in dem das DRPG erstellt wurde.
4. Klicken Sie auf Verknüpfen.

Abbildung 2.4.2: Erforderliche Parameter für die Verknüpfung der DRPGs

Aufgabe 2.4.3: Was Sie nach Abschluss der Zuordnung sehen sollten

OCI Full Stack DR zeigt nach Abschluss der Verknüpfung etwas wie Abbildung 2.4.3.

1. Das derzeitige primäre Peer-DRPG ist London (Region 1).
2. Das aktuelle Standby-Peer-DRPG ist Newport (Region 2).

Abbildung 2.4.3: Peer-Beziehung 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 2.4.4 unten gezeigt.

1. Das derzeitige primäre Peer-DRPG ist London (Region 1).
2. Das aktuelle Standby-Peer-DRPG ist Newport (Region 2).

Abbildung 2.4.4: Peer-Beziehung aus der globalen DRPG-Perspektive anzeigen

Aufgabe 3: Mitglieder zur DR-Schutzgruppe hinzufügen

Hinweis: Mit dieser Aufgabe werden alle vorhandenen DR-Pläne in beiden Regionen gelöscht, wenn Mitglieder zu vorhandenen DR-Schutzgruppen hinzugefügt werden. OCI 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 OCI 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 die Compute Nodes der Oracle EPM System-Anwendung als Mitglieder der DR-Schutzgruppen hinzu. Der DR-Kontrollknoten ist entweder eine Compute-Instanz, die Sie nur zur Unterstützung der DR-Orchestrierung erstellt haben, oder eine Compute-Instanz, die Teil des Anwendungsstacks ist, den Sie mit Full Stack DR verwalten möchten. In diesem Beispiel führt der EPM System-Anwendungsknoten auch die Funktion des DR-Kontrollknotens aus.

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

1. Der Compute Node der EPM System-Anwendung, der auch die Funktion des DR Control-Knotens ausführt.
2. Die Volume-Gruppe enthält das Boot-Volume des Compute Nodes der EPM-Systemanwendung. Falls vorhanden, müssen alle zusätzlichen Block-Volumes, die an die Compute Nodes angehängt sind, in die Volume-Gruppe aufgenommen werden.
3. Der primäre Oracle Base Database Service.
4. Der primäre Load Balancer.

Aufgabe 3.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 3-1 dargestellt.

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

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

Aufgabe 3.1.1: Compute-Instanz für DR-Kontrollknoten hinzufügen

Fügen Sie eine Compute-Instanz für das EPM System hinzu, das auch als DR-Kontrollknoten dient, wie in Abbildung 3.1.1 dargestellt. In diesem Beispiel hostet eine einzelne Compute-Instanz alle Module des EPM-Systems. Wenn Ihr EPM System in einer verteilten Umgebung mit mehreren Compute Nodes bereitgestellt wird, stellen Sie sicher, dass jeder Knoten in diesem Schritt enthalten ist.

1. Warnung zu DR-Plänen bestätigen.
2. Geben Sie Compute als Ressourcentyp für Elemente ein.
3. Wählen Sie die Compute-Instanz der EPM System-Anwendung aus. Dieselbe Compute-Instanz wird auch für die Ausführung benutzerdefinierter Skripte verwendet.
4. Wählen Sie Verschiebende Instanz aus.
5. Fügen Sie OCI Full Stack DR hinzu, das VCN und Subnetz den VNICs in Region 2 während eines Recoverys zuzuweisen sind. Abbildung 4-2 zeigt eine einzelne VNIC. Bei OCI Full Stack DR ist es egal, wie viele VNICs Sie haben oder wie sie in beiden Regionen konfiguriert sind. Geben Sie an, was Sie benötigen, um Ihre Anforderungen zu erfüllen. Stellen Sie sicher, dass Sie eine gültige IP-Adresse aus dem Zielsubnetz in der Standbyregion angeben. Dadurch wird die Aktualisierung von Hostdateien nach dem Switchover vereinfacht, da die Compute-Instanz konsistent dieselbe bekannte IP-Adresse verwendet.

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

Aufgabe 3.1.2: Block-Volume-Gruppe für DR-Kontrollknoten hinzufügen

Fügen Sie die Block-Volume-Gruppe mit Boot- und Block-Volumes hinzu, die an den EPM System-Anwendungsknoten angehängt sind. 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 Ressourcentyp für das Element 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 3.1.2: Erforderliche Parameter zum Hinzufügen einer Boot-Volume-Gruppe für EPM Compute

Aufgabe 3.1.3: Primären Oracle Base Database Service hinzufügen

Zu diesem Zeitpunkt sollte Oracle Data Guard bereits im Rahmen von Aufgabe 1 für das Oracle Base Database-Servicesystem konfiguriert sein. Fügen Sie die primäre DB als Mitglied des DRPG in Region 1 hinzu.

1. Wählen Sie Datenbank als Ressourcentyp des Elements aus.
2. Stellen Sie sicher, dass das richtige Compartment für die Datenbank ausgewählt ist.
3. Geben Sie Details zum Secret im OCI Vault mit dem SYS-Benutzerkennwort der EPM-Datenbank an. Sie haben dieses Secret während der Konfiguration von Oracle Data Guard in Aufgabe 1 erstellt.

Abbildung 3.1.3: Erforderliche Parameter zum Hinzufügen der primären DB, die vom Basis-DB-Service ausgeführt wird

Aufgabe 3.1.4: OCI Load Balancer hinzufügen

In diesem Beispiel wird der Load Balancer als Mitglied des DRPG in Region 1 hinzugefügt.

1. Wählen Sie Load Balancer als Ressourcentyp für das Element aus.
2. Stellen Sie sicher, dass die richtigen Compartments für den Load Balancer ausgewählt sind.
3. Wählen Sie Quell-Backend-Set: Dieses Backend-Set wird von Ihrer EPM System-Anwendung verwendet. Ein OCI Load Balancer kann von mehreren Anwendungen gemeinsam verwendet werden. Möglicherweise sind mehrere Backend-Sets konfiguriert. Während eines DR-Switchovers wird ihre Konfiguration nur für die hier angegebenen Backend-Sets in die Standbyregion verschoben.
4. Wählen Sie Ziel-Backend-Set: Dies ist das leere Backend-Set, das in Aufgabe 1.7 in Region 2 erstellt wurde.

Abbildung 3.1.4: Erforderliche Parameter zum Hinzufügen eines Load Balancers

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

Das DRPG für Region 1 sollte nun über vier Mitgliedsressourcen verfügen, wie in Abbildung 3.1.5 dargestellt. Die Namen Ihrer Mitgliedsressourcen sind unterschiedlich.

1. Die Primärdatenbank.
2. Die bewegliche Compute-Instanz.
3. Block-Volume-Gruppe für die Compute-Instanz.
4. OCI Load Balancer

Abbildung 3.1.5: Elemente von DRPG in Region 1 anzeigen

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

Wählen Sie zunächst das DRPG in Region 2 aus.

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

Sie fügen dem Standby-DRPG in Region 2 die folgenden Ressourcen hinzu, indem Sie ähnliche Schritte wie in der primären Region ausführen:

1. Das Standby-/Remote-System von Oracle Base Database Service.
2. Standby-OCI-Load Balancer.

Nachdem die Aufgabe abgeschlossen ist, muss das DRPG für Region 2 über zwei Member-Ressourcen verfügen, wie in Abbildung 3.2 unten dargestellt.

Abbildung 3.2: Elemente von DRPG in Region 2 anzeigen

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

Dieser Schritt erstellt grundlegende Switchover- und Failover-Pläne, die mit der Standby-DR-Schutzgruppe in Region 2 (Newport) 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.

OCI Full Stack DR füllt beide Pläne vorab mit integrierten Schritten auf, die auf den in den vorherigen Aufgaben hinzugefügten Mitgliedsressourcen basieren. Die Pläne werden in späteren Schritten angepasst, um alle Aufgaben im Zusammenhang mit EPM System während eines Recovery-Vorgangs zu bearbeiten.

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

Aufgabe 4.1: DR-Pläne erstellen

Erstellen Sie einen Basisplan, indem Sie das DRPG in Region 2 auswählen (Newport)

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

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

Aufgabe 4.1.1: Switchover-Plan erstellen

Das Erstellen eines DR-Plans ist einfach, wie in Abbildung 4.1.1 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 als Switchover (geplant) aus. Zum Zeitpunkt dieses Schreibens gibt es nur vier Plantypen.

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

Aufgabe 4.1.2: Failover-Plan erstellen

Führen Sie denselben Prozess aus, um einen grundlegenden Failover-Plan zu erstellen, wie in Abbildung 4.1.2 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 als Failover (ungeplant) aus. Zum Zeitpunkt dieses Schreibens gibt es nur vier Plantypen.

Abbildung 4.1.2: 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 im folgenden Bild gezeigt. Diese bewältigen den Übergang von Workloads von Region 1 zu Region 2. Sie erstellen ähnliche Pläne in Region 1, um in einer späteren Aufgabe Workloads von Region 2 zurück in Region 1 zu verlagern.

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

Aufgabe 5: Switchover-Plan in Region 2 anpassen (Newport)

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

• Stoppen Sie EPM System-Services in der aktuellen primären Region 1, bevor Sie VMs stoppen.
• Aktualisieren Sie die Hostdateien auf dem Compute Node, um Standby-IP-Adressen Hostnamen der primären Region zuzuordnen.
• Starten Sie EPM System-Services in der aktuellen Standbyregion 2, nachdem Sie VMs gestartet haben.

Aufgabe 5.1: Switchover-Plan auswählen

Navigieren Sie zu dem in Aufgabe 4 erstellten Switchover-Plan.

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

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

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 müssen aktiviert werden, sobald OCI 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 5.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 Object Storage-Vorgangs gestartet wurden, um die Replikation von Region 2 im Rahmen des Switchovers von Region 1 zurück in Region 1 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 5.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 5.2.1: So aktivieren Sie das Beenden von Compute-Instanzen

Aufgabe 5.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 5.2.2: So aktivieren Sie das Beenden von Volume-Gruppen

Aufgabe 5.3: Plangruppe zum Ausführen benutzerdefinierter Skripte in Region 1 erstellen (primär)

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

Die erste benutzerdefinierte Plangruppe führt benutzerdefinierte Skripte aus, um die in der primären Region 1 ausgeführten EPM System-Services zu stoppen. Diese Plangruppe enthält einen einzelnen Schritt, der das Windows-Skript PowerShell stop_services.ps1 aufruft. Dieses Skript wurde in Aufgabe 1.2 in den Ordner c:/scripts auf dem EPM-Anwendungsknoten heruntergeladen.

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

Beginnen Sie mit dem Hinzufügen einer Plangruppe.

1. Klicken Sie zum Beginnen auf Gruppe hinzufügen.
2. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen. Dies ist optional. Es empfiehlt sich jedoch, eine Notiz hinzuzufügen, in welcher Region die Plangruppe die Schritte ausführt.
3. 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 vor der integrierten Plangruppe einfügen, die die VMs in Region 1 stoppt.
4. Wählen Sie die integrierte Plangruppe Compute-Instanzen stoppen (primär) aus.
5. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Stoppen des EPM-Systems angeben.

Abbildung 5.3.1: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Stoppen von EPM

Aufgabe 5.3.2: Schrittnamen und lokale Skriptparameter angeben

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 werden EPM System-Services 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 Schrittname, der die von diesem Schritt ausgeführte Aufgabe erläutert.
2. Wählen Sie immer die Region aus, in der der EPM-Anwendungsknoten gerade ausgeführt wird, und nicht die Region, in der er während eines Switchovers ausgeführt wird. OCI 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 EPM-Anwendungsknoten in Region 1 (London) ausgeführt.
3. Wählen Sie das richtige Compartment aus, das den DR-Kontrollknoten enthält. Wählen Sie dann die Compute-Instanz aus, die als DR-Kontrollknoten angegeben ist. In diesem Beispiel ist es EPM-Systemanwendungs-Compute.
4. Wählen Sie Lokales Skript ausführen aus, um OCI Full Stack DR darüber zu informieren, dass sich das Skript auf einer Compute-Instanz befindet. Die Windows-Skripte PowerShell wurden in Aufgabe 1.2 auf den DR-Kontrollknoten heruntergeladen.
5. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript stop_services.ps1 auf dem DR-Kontrollknoten installiert haben. Fügen Sie "stop" als ersten Parameter und die OCI-Regions-ID als zweiten hinzu.
6. Der DR-Plan muss gestoppt werden, wenn das Skript EPM Services nicht stoppen kann. Dadurch kann jeder sehen, dass es ein Problem gibt und es beheben. OCI Full Stack DR bietet die Möglichkeit, den Switchover-Plan weiter auszuführen, nachdem das Problem behoben wurde.
7. 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.
8. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 5.3.2: Parameter zum Erstellen des Planschritts zum Stoppen von EPM

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

Der Schritt zum Stoppen des EPM-Systems wurde jetzt der DR-Plangruppe hinzugefügt, wie in Abbildung 5.3.3 unten dargestellt.

Zeigt den Planschritt an, der gerade hinzugefügt wurde. Sie können einer DR-Plangruppe zusätzliche Schritte hinzufügen. Diese Plangruppe enthält jedoch nur den Schritt zum Stoppen von EPM Services. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

Abbildung 5.3.3: Hinzufügen von Plangruppe und Schritt zum Stoppen von EPM abschließen

Aufgabe 5.4: Plangruppe zum Ausführen benutzerdefinierter Skripte in Region 2 erstellen (Standby)

Die zweite benutzerdefinierte Plangruppe aktualisiert Hostdateien auf Compute Nodes und startet EPM System-Services, nachdem der DR-Kontrollknoten in der Standbyregion 2 gestartet wurde. Diese Plangruppe enthält zwei Schritte, die Skripte host_switch_failover.ps1 und start_services.ps1 PowerShell aufrufen, die in Aufgabe 1.2 auf den DR-Kontrollknoten heruntergeladen wurden.

Aufgabe 5.4.1 DR-Plangruppe zum Aktualisieren der Hostdatei nach dem Switchover zur Standbyregion erstellen

1. Weisen Sie der Plangruppe einen einfachen, aber aussagekräftigen Gruppennamen zu.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall fügen wir unsere benutzerdefinierte Plangruppe ein, nachdem die integrierte Plangruppe die replizierte Version des EPM System-Anwendungsknotens gestartet hat. Dadurch wird auch die Funktion des DR-Kontrollknotens in Region 2 ausgeführt.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen starten aus
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zur Aktualisierung der Hostdatei angeben.

Abbildung 5.4.1: Parameter zum Erstellen des Planschritts zum Starten von EPM

Aufgabe 5.4.2: Schrittnamen und lokale Skriptparameter für Hostdateiaktualisierungsskript angeben

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. Das Skript host_switch_failover.ps1 aktualisiert die Hostdatei auf dem Compute Node, sodass die neuen IP-Adressen für die Compute- und Datenbankinstanzen in Region 2 dem ursprünglichen Hostnamen für Region 1 zugeordnet werden. Dadurch kann die Anwendung ohne weitere Änderungen in der Anwendungsschicht gestartet werden.

Dieser Schritt ist mit Aufgabe 5.3.2 identisch, mit Ausnahme der in Abbildung 5.4.2 unten dargestellten Elemente.

1. Ein aussagekräftiger Schrittname, der die von diesem Schritt ausgeführte Aufgabe erläutert.
2. Fügen Sie den absoluten Pfad zu PowerShell.exe und zu dem Ort ein, an dem Sie das Skript host_switch_failover.ps1 auf dem EPM-Anwendungsknoten installiert haben.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 5.4.2: Parameter zum Aktualisieren der Hostdatei

Aufgabe 5.4.3: Schrittnamen und lokale Skriptparameter für das Startskript für EPM System Service angeben

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 beginnen EPM-Systemservices in Region 2.

1. Ein aussagekräftiger Schrittname, der die von diesem Schritt ausgeführte Aufgabe erläutert.
2. Fügen Sie den absoluten Pfad zu PowerShell.exe und zu dem Ort ein, an dem Sie das Skript start_services.ps1 auf dem EPM-Anwendungsknoten installiert haben.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.
4. Klicken Sie auf Hinzufügen, um die Plangruppe hinzuzufügen, die jetzt zwei Schritte zum Ausführen von zwei benutzerdefinierten Skripten enthält.

Abbildung 5.4.3: Parameter zum Starten von EPM

Der Switchover-Plan sollte jetzt beide DR-Plangruppen enthalten, wie im folgenden Screenshot gezeigt.

Abbildung 5.4.4: Benutzerdefiniertes Skript nach dem Hochfahren

Aufgabe 6: Failover-Plan in Region 2 anpassen (Newport)

In dieser Aufgabe wird erläutert, wie Sie benutzerdefinierte, benutzerdefinierte DR-Plangruppen und Schritte zum Verwalten der Aufgaben hinzufügen, die während eines Failovers für das EPM-System in Region 2 bei einem tatsächlichen Ausfall oder Verlust des Zugriffs auf Region 1 ausgeführt werden müssen. Diese Schritte sind eine Teilmenge derselben Schritte, die gerade zum Switchover-Plan in Aufgabe 5 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.

Aufgabe 6.1: Failover-Plan auswählen

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 6-1: So erstellen Sie die Anpassung des Failover-Plans in Region 2.

Aufgabe 6.1.2: Schritte zur neuen benutzerdefinierten Plangruppe hinzufügen

1. Klicken Sie auf Gruppe hinzufügen.

   
   Abbildung 6.1.2 Parameter zum Erstellen des Planschritts zum Starten von EPM

2. Befolgen Sie die Anweisungen aus Aufgabe 5.4, um der benutzerdefinierten Plangruppe zwei Schritte zum Ausführen benutzerdefinierter Skripte hinzuzufügen: host_switch_failover.ps1 und start_services.ps1.

3. Nach dem Hinzufügen von Schritten und der benutzerdefinierten Plangruppe sollte der Failover-Plan wie folgt aussehen:

   
   Abbildung 6.1.3 Parameter zum Erstellen des Planschritts zum Starten von EPM und Aktualisieren von Hosts

Aufgabe 7: Switchover-Plan in Region 2 ausführen (Newport)

Sowohl Switchover- als auch Failover-DR-Pläne wurden in der Standbyregion 2 (Newport) abgeschlossen. Mit den DR-Plänen in Region 2 kann OCI 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 (London) zu erstellen, damit OCI 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 (London) in Region 2 (Newport) zu übertragen.

Aufgabe 7.1: Planausführung beginnen

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

1. Stellen Sie sicher, dass der Regionskontext weiterhin auf Standby-Region 2 (Newport) gesetzt ist.
2. Verwenden Sie die Navigationspfade oben in der Konsole, um sicherzustellen, dass DR-Schutzgruppendetails der aktuelle Plankontext sind.
3. Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Dabei muss es sich um die Standbyrolle handeln.
4. Stellen Sie vor dem Fortfahren sicher, dass sowohl der Failover- als auch der Switchover-Plan vorhanden sind. Wenn nicht, kehren Sie zu den vorherigen Aufgaben zurück, um beide DR-Pläne zu erstellen.
5. Klicken Sie auf DR-Plan ausführen.

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

Aufgabe 7.2: Switchover-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. Wählen Sie Vorabprüfungen aktivieren aus.
3. Klicken Sie auf DR-Plan ausführen, um zu beginnen.

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

Aufgabe 7.3: Nächste Schritte

Überwachen Sie den Switchover-Plan, bis die EPM System-Workload vollständig von Region 1 in Region 2 übergegangen ist. Full Stack DR bereinigt Artefakte und ändert die Primär- und die Standbyrolle zwischen den Regionen. Falls die Ausführung des Switchover-Plans nicht erfolgreich verläuft, prüfen Sie die Logs, und stellen Sie sicher, dass der Plan erfolgreich ausgeführt wurde.

Nachdem der Full Stack DR-Switchover abgeschlossen ist, wird Region 2 (Newport) zur primären Region, und Region 1 (London) wird zur Standbyregion.

Aufgabe 8: DR-Pläne in Region 1 erstellen (London)

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

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

OCI Full Stack DR füllt beide Pläne vorab mit integrierten Schritten auf, die auf den in der vorherigen Aufgabe hinzugefügten Mitgliedsressourcen basieren. In späteren Schritten werden die Pläne so angepasst, dass sie alle Aufgaben im Zusammenhang mit dem EPM-System während eines Recovery-Vorgangs 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 8.1: DR-Pläne erstellen

Erstellen Sie einen Basisplan, indem Sie das DRPG in Region 1 auswählen, wie in Abbildung 8.1 dargestellt.

1. Stellen Sie sicher, dass der OCI-Regionskontext Region 1 (London) ist.
2. Wählen Sie das Standby-DRPG in Region 1.
3. Wählen Sie Pläne aus.
4. Klicken Sie auf Plan erstellen, um den Prozess zu starten.
5. 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.
6. Wählen Sie unter Plantyp die Option Switchover (geplant) aus. Zum Zeitpunkt dieses Schreibens gibt es nur vier Plantypen.
7. Klicken Sie auf Erstellen, um einen grundlegenden Switchover-Plan zu erstellen, der mit grundlegenden integrierten Schritten vorab aufgefüllt wird.

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

Aufgabe 8.2: Failover-Plan erstellen

Führen Sie denselben Prozess aus, um einen grundlegenden Failover-Plan zu erstellen, wie in Abbildung 8.2 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 unter Plantyp den Wert Failover (nicht geplant) aus. Zum Zeitpunkt dieses Schreibens gibt es vier Plantypen.

3. Klicken Sie auf Erstellen, um einen grundlegenden Failover-Plan zu erstellen, der mit grundlegenden integrierten Schritten vorab aufgefüllt wird.

Abbildung 8.2: 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 8.3: Die beiden grundlegenden DR-Pläne werden angezeigt, die in Region 2 vorhanden sein müssen, bevor Sie fortfahren.

Aufgabe 9: Switchover-Plan in Region 1 (London) anpassen

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

Die in Aufgabe 8 erstellten grundlegenden DR-Pläne enthalten vorab aufgefüllte Schritte für Recovery-Aufgaben, die in OCI Full Stack DR integriert sind und keine für die EPM System-Anwendung spezifischen Recovery-Aufgaben enthalten. In diesem Schritt wird erläutert, wie Sie benutzerdefinierte, benutzerdefinierte DR-Plangruppen und Schritte zum Verwalten der Aufgaben hinzufügen, die während eines Switchovers für das EPM-System ausgeführt werden müssen:

• Stoppen Sie EPM System-Services in der aktuellen primären Region 1, bevor Sie VMs stoppen.
• Aktualisieren Sie die Hostdateien auf dem Compute Node, um Standby-IP-Adressen Hostnamen der primären Region zuzuordnen.
• Starten Sie EPM System-Services in der aktuellen Standbyregion 2, nachdem Sie VMs gestartet haben.

Aufgabe 9.1: Switchover-Plan auswählen

Navigieren Sie zu dem Switchover-Plan, der in der vorherigen Aufgabe erstellt wurde.

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

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

Dies sind die gleichen Schritte, die für Region 2 in einer früheren Aufgabe 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 müssen aktiviert werden, sobald OCI 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 9-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 9.2.1: "Compute-Plangruppe beenden" aktivieren

Aktivieren Sie die Plangruppe.

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

   
   Abbildung 9.2.1: So aktivieren Sie das Beenden von Compute-Instanzen

Aufgabe 9.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 9.2.2: So aktivieren Sie das Beenden von Volume-Gruppen

Aufgabe 9.3: Plangruppe zum Ausführen benutzerdefinierter Skripte in Region 2 erstellen (primär)

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

Die erste benutzerdefinierte Plangruppe führt benutzerdefinierte Skripte aus, um EPM System-Services zu stoppen, die in der primären Region 2 ausgeführt werden. Diese Plangruppe enthält einen einzelnen Schritt, der das Windows-Skript PowerShell stop_services.ps1 aufruft, das in Aufgabe 1.2 in den Ordner c:/scripts auf dem DR-Kontrollknoten heruntergeladen wurde.

Aufgabe 9.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.
2. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
3. 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 vor der integrierten Plangruppe einfügen, die die VMs in Region 2 stoppt.
4. Wählen Sie die integrierte Plangruppe Compute-Instanzen stoppen (primär) aus.
5. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Stoppen von EPM System angeben.

Abbildung 9.3.1: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Stoppen von EPM-Systemservices

Aufgabe 9.3.2: Schrittnamen und lokale Skriptparameter angeben

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 werden EPM System-Services 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 Schrittname, der die von diesem Schritt ausgeführte Aufgabe erläutert.
2. Der DR-Plan muss gestoppt werden, wenn das Skript EPM Services 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 OCI 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, und nicht die Region, in der er während eines Switchovers ausgeführt wird. OCI 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 (London) 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 Windows-Skripte PowerShell wurden in Aufgabe 1.2 auf den DR-Kontrollknoten heruntergeladen.
6. Wählen Sie das richtige Compartment aus, das den DR-Kontrollknoten enthält. Wählen Sie dann die Compute-Instanz aus, die als DR-Kontrollknoten angegeben wurde. In diesem Beispiel ist es EPM-Systemanwendungs-Compute.
7. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript stop_services.ps1 auf dem DR-Kontrollknoten installiert haben. Fügen Sie "stop" als ersten Parameter und die OCI-Regions-ID als zweiten hinzu.
8. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 9.3.2: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Starten von EPM-Systemservices

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

1. Der Schritt zum Stoppen von EPM System wird jetzt der DR-Plangruppe hinzugefügt, wie in Abbildung 9.3.3 dargestellt.

   
   Abbildung 9.3.3: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Stoppen von EPM-Systemservices

2. Zeigt den Planschritt an, der gerade hinzugefügt wurde. Sie können einer DR-Plangruppe zusätzliche Schritte hinzufügen. Diese Plangruppe enthält jedoch nur den Schritt zum Stoppen von EPM Services.

3. Klicken Sie auf Hinzufügen, um die DR-Plangruppe und den DR-Schritt zum DR-Plan hinzuzufügen.

   
   Abbildung 9.3.4: Parameter zum Erstellen von Plangruppe und -gruppe, die zum Stoppen von EPM-Systemservices hinzugefügt wurden

Aufgabe 9.4: Plangruppe zum Ausführen benutzerdefinierter Skripte in Region 1 erstellen (Standby)

Die zweite benutzerdefinierte Plangruppe aktualisiert Hostdateien auf Compute Nodes und startet EPM System-Services, nachdem der DR-Kontrollknoten in der Standbyregion 1 gestartet wurde. Diese Plangruppe enthält zwei Schritte, in denen die Skripte host_switch_failback.ps1 und start_services.ps1 PowerShell aufgerufen werden, die in Aufgabe 1.2 auf den DR-Kontrollknoten heruntergeladen wurden. Das Skript host_switch_failback.ps1 kehrt die vom Skript host_switch_failover.ps1 in der Region Newport eingeführten Änderungen um und stellt die ursprünglichen Hostdateien auf den Compute Nodes wieder her, nachdem sie wieder in die ursprüngliche primäre Region London verschoben wurden.

Aufgabe 9.4.1 DR-Plangruppe erstellen, um die Hostdatei nach dem Switchover zur Standbyregion zu aktualisieren

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. In diesem Fall fügen wir unsere benutzerdefinierte Plangruppe ein, nachdem die integrierte Plangruppe die replizierte Version des EPM System-Anwendungsknotens gestartet hat. Dadurch wird auch die Funktion des DR-Kontrollknotens in Region 1 ausgeführt.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen starten (Standby).
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Aktualisieren der Hostdatei angeben.

Abbildung 9.4.1: Parameter zum Erstellen einer Plangruppe und Gruppe, die zur Aktualisierung der Hostdatei hinzugefügt wurden

Aufgabe 9.4.2: Schrittnamen und lokale Skriptparameter für das Skript zur Aktualisierung der Hostdatei angeben

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. Das Skript host_switch_failback.ps1 aktualisiert die Hostdatei auf dem Compute Node. Dadurch werden die vom Skript host_switch_failback.ps1 in der Region Newport eingeführten Änderungen rückgängig gemacht, und die ursprüngliche Hostdatei für Region 1 (London) wird wiederhergestellt. Dadurch kann die Anwendung ohne weitere Änderungen in der Anwendungsschicht gestartet werden.

Dieser Schritt entspricht Aufgabe 9.3.2 mit Ausnahme der in der Abbildung dargestellten Elemente.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad zu PowerShell.exe und dem Ort ein, an dem Sie das Skript host_switch_failover.ps1 auf dem DR-Kontrollknoten installiert haben.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 9.4.2: Parameter zum Erstellen von Plangruppe und Schrittdetails zum Aktualisieren der Hostdatei hinzugefügt

Aufgabe 9.4.3: Schrittnamen und lokale Skriptparameter für das Startskript für EPM System Service angeben

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 beginnen EPM-Systemservices in Region 2.

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad zu PowerShell.exe und dem Ort ein, an dem Sie das Skript start_services.ps1 auf dem DR-Kontrollknoten installiert haben.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.
4. Klicken Sie auf Hinzufügen, um die Plangruppe hinzuzufügen, die jetzt zwei Schritte zum Ausführen von zwei benutzerdefinierten Skripten enthält.

Der Switchover-Plan sollte jetzt beide DR-Plangruppen enthalten, wie im folgenden Screenshot gezeigt.

Abbildung 9.4.3: Benutzerdefinierte Swichover-Plangruppen

Aufgabe 10: Failover-Plan in Region 1 (London) anpassen

In dieser Aufgabe wird erläutert, wie Sie benutzerdefinierte, benutzerdefinierte DR-Plangruppen und Schritte zum Verwalten der Aufgaben hinzufügen, die während eines Failovers für das EPM-System 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 9 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.

Aufgabe 10.1: Benutzerdefinierte Plangruppe zu Failover-Plan hinzufügen

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

Abbildung 10.1: Failover-Plan in Region 1

Aufgabe 10.1.1: Plangruppe hinzufügen

1. Stellen Sie sicher, dass Standbyregion 2 weiterhin der aktuelle Regionskontext in der Konsole ist.
2. Wählen Sie den Failover-Plan aus.
3. Klicken Sie auf Gruppe hinzufügen.
4. Geben Sie den Namen der Gruppe an.
5. Fügen Sie ihn nach dem integrierten Schritt Compute-Instanz starten zum Plan hinzu.

Abbildung 10.1: Parameter zum Erstellen einer Plangruppe zur Ausführung benutzerdefinierter Skripte nach einem Failover auf Region 2.

Aufgabe 10.1.2: Schritte zur neuen benutzerdefinierten Plangruppe hinzufügen

1. Befolgen Sie die Anweisungen aus Aufgabe 9.4, um der benutzerdefinierten Plangruppe zwei Schritte zum Ausführen des benutzerdefinierten Skripts hinzuzufügen: host_switch_failback.ps1.

   
   Abbildung 10.2: Parameter zum Erstellen des Plangruppenschritts für das Skript zur Aktualisierung der Hostdatei.

2. Fügen Sie einen zweiten Schritt in der Plangruppe hinzu, um die Services mit dem Skript start_services.ps1 zu starten.

   
   Abbildung 10.3: Parameter zum Erstellen des Plangruppenschritts für das Skript zur Aktualisierung der Hostdatei.

3. Nachdem Sie Schritte hinzugefügt haben, sollte die benutzerdefinierte Plangruppe wie folgt aussehen, und klicken Sie auf Hinzufügen.

   
   Abbildung 10.4: Plangruppe mit konfigurierten Schritten zur Ausführung von zwei lokalen Skripten nach dem Start der Compute-Instanz.

4. Der Failover-Plan sollte jetzt die benutzerdefinierte DR-Plangruppe für das EPM System enthalten, wie im folgenden Screenshot gezeigt. Möglicherweise haben Sie zusätzliche Plangruppen, wenn Ihre Schutzgruppe andere Anwendungen oder OCI-Services zusammen mit dem EPM-System enthält.

   
   Abbildung 10.5: Failover-Plan mit benutzerdefinierten Plangruppen

Nächste Schritte

OCI Full Stack DR für das EPM-System sollte an dieser Stelle vollständig implementiert werden. Die vollständige Funktionalität sollte jedoch vor der Verwendung in der 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 sind darauf ausgelegt, alle Artefakte zu bereinigen und sicherzustellen, dass alle Rollen für integrierte Recovery-Schritte, wie Load Balancer, Blockspeicher, Dateisysteme, BaseDB, ExaCS und Autonomous Database, 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 Oracle Data Guard den richtigen Status aufweist, Artefakte für Speicher- und Compute-Instanzen beendet wurden usw. Weitere Informationen finden Sie unter Resetting DR Configuration After a Failover.

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

Das Recovery-Team muss eine abschließende Validierung durchführen, um die Bereitschaft von OCI Full Stack DR-Schutzgruppen und -Plänen für Produktions-Workloads zu demonstrieren. Region 2 (Newport) muss 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.

• Optional können Sie auch die Pläne "Drill starten" und "Drill stoppen" basierend auf den Anforderungen erstellen und testen.

• 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

• Infrastruktur für das Deployment von Oracle Enterprise Performance Management in der Cloud entwerfen

• Dokumentation zu Deployment-Optionen: Disaster Recovery für Hyperion EPM System

• Überlegungen zu Datenbanken: Disaster Recovery für Fusion Middleware

• Beispielskripte Speicherort 1: EPM-Beispielskripte von GitHub herunterladen

• Beispielskripte Speicherort 2: EPM-Beispielskripte von GitHub herunterladen

• OCI Full Stack DR Oracle EPM-Playlist unter YouTube

  • Video 1: Oracle EPM für Disaster Recovery bereitstellen

  • Video 2: Automatisieren Sie Disaster Recovery-Vorgänge für Oracle EPM mit OCI Full Stack DR

  • Video 3: Skripte zur Automatisierung der Wiederherstellung für Oracle EPM

• Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery

• OCI Full Stack Disaster Recovery - Dokumentation

• OCI Full Stack Disaster Recovery - Benutzerdefinierte Gruppenskripte

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

Danksagungen

• Autor - Grzegorz Reizer (Oracle EPM Specialist)

• Beitragender - Suraj Ramesh (Produktmanager für OCI Full Stack DR)

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. Außerdem können Sie education.oracle.com/learning-explorer besuchen, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.

---

Titel und Copyright-Informationen

Automate Recovery for Oracle Enterprise Performance Management using OCI Full Stack Disaster Recovery

G11406-01

July 2024

Copyright ©2024,

Oracle und/oder verbundene Unternehmen.