Hinweis:

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

Recovery für Oracle E-Business Suite mit mehreren Knoten mit OCI Full Stack Disaster Recovery automatisieren

Einführung

OCI Full Stack Disaster Recovery basiert auf Anwendungstechnikteams, um ihre eigenen Disaster Recovery-Funktionen und -Features zu entwerfen, zu schreiben und zu verwalten. Wenn ein Application Engineering-Team integrierte, OCI-native Disaster Recovery-Funktionen hat, die OCI-SDK-APIs für die Disaster Recovery enthalten, kann diese Anwendung Full Stack DR als native Mitgliederressource hinzugefügt werden.

Oracle E-Business Suite verfügt derzeit über keine OCI-nativen Disaster Recovery-Funktionen oder -Features und ist daher keine native Mitgliedsressource in Full Stack DR. Das Oracle E-Business Suit Engineering-Team hat jedoch einen Prozess für die manuelle Bereitstellung und Wiederherstellung von EBS in OCI-Regionen dokumentiert. Der manuelle Prozess kann mit Full Stack DR automatisiert werden. In diesem Dokument wird erläutert, wie Sie den manuellen Wiederherstellungsprozess automatisieren, indem Sie benutzerdefinierte Plangruppen und Schritte zu grundlegenden DR-Plänen für Failover, Switchover und Drilldowns hinzufügen.

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

Oracle E-Business Suite unterstützt die sich entwickelnden Geschäftsmodelle von heute, steigert die Produktivität und erfüllt die Anforderungen moderner mobiler Benutzer. Aufbauend auf einer 30-jährigen Innovationsgeschichte bietet die Oracle E-Business Suite weiterhin neue Anwendungsfunktionen, erweitert die Funktionen bestehender Features und hilft Ihnen dabei, alle Vorteile von OCI zu nutzen.

Oracle E-Business Suite gehört in der Regel zu einem größeren System

Oracle E-Business Suite ist in der Regel die Grundlage für ein komplexeres Geschäftssystem, das eine Reihe zusätzlicher Datenbanken, OCI Marketplace-Anwendungen und OCI-Services umfasst, die alle als eine Einheit wiederhergestellt werden müssen. Dieses Tutorial zeigt nur die Aufgaben im Zusammenhang mit der Oracle E-Business Suite, damit die Dinge einfach und auf die Oracle E-Business Suite ausgerichtet sind. Es ist jedoch sehr ungewöhnlich, dass Oracle E-Business Suite die einzige Anwendung ist, die Teil der DR-Schutzgruppe und der DR-Pläne ist.

Vorsicht bei der inkrementellen Umsetzung

Wenn Sie nach dem Erstellen von DR-Plänen weitere Mitglieder zu einer DR-Schutzgruppe hinzufügen oder löschen, werden die vorhandenen DR-Pläne in den Schutzgruppen in beiden Regionen aktualisiert. Weitere Informationen finden Sie unter Disaster-Recovery-Plan aktualisieren.

OCI Full Stack DR wurde mit der Annahme entwickelt, dass der gesamte Anwendungsstack für ein bestimmtes Geschäftssystem bereits in allen OCI-Regionen bereitgestellt ist, und manuelle DR funktioniert bereits. Wenn Ihr Geschäftssystem mehr als Oracle E-Business Suite umfasst, fügen Sie alle anderen Compute-, Speicher-, Datenbank-, Anwendungs- oder OCI-Services zu den DR-Schutzgruppen hinzu, bevor Sie DR-Pläne erstellen.

Funktionsweise der Wiederherstellung

Die Recovery-Lösung für Oracle E-Business Suite erfordert, dass OCI Full Stack DR während eines Recovery-Vorgangs eine Reihe benutzerdefinierter bash-Skripte wie Failover, Switchover oder Drilldowns ausführt. In diesem Tutorial werden die Oracle E-Business Suite-Anwendungsknoten als Kontrollknoten zum Hosting und Ausführen von Skripten verwendet.

Die in diesem Tutorial referenzierten Skripte werden vom Oracle EMEA Cloud Engineering Oracle Apps-Spezialistenteam für OCI bereitgestellt und sind in Oracle E-Business Suite-Skripten für OCI Full Stack Disaster Recovery verfügbar. Die bash-Skripte müssen möglicherweise leicht geändert werden, damit sie den individuellen Anforderungen Ihres Deployments entsprechen.

Abbildung 1: Oracle E-Business Suite-Skripte, die im Oracle Beispiel-Repository GitHub verfügbar sind

In diesem Tutorial wird erläutert, wie Sie die Skripte herunterladen und in einem späteren Schritt verwenden. In diesem Tutorial wird Option 1 nur zum Hosten der bash-Skripte verwendet, weil das Tutorial nur Oracle E-Business Suite enthält.

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

Option 1 für Hosting-Skripte

Installieren Sie die bash-Skripte auf den Oracle E-Business Suite-Anwendungsservern, die in beiden Regionen ausgeführt werden. In diesem Tutorial werden die Compute-Instanzen beschrieben, auf denen Sie die Skripte als Kontrollknoten oder DR-Knoten installieren, obwohl es sich um einen oder mehrere Oracle E-Business Suite-Anwendungsserver in Ihrem Anwendungsstack handelt.

Option 2 für Hosting-Skripte

Erstellen Sie einen speziellen Kontrollknoten oder DR-Knoten, um alle Oracle E-Business Suite-Skripte sowie Skripte zu hosten, die für andere Anwendungen oder OCI-Services erforderlich sind.

Oracle E-Business Suite ist am häufigsten Teil eines größeren, komplexeren Geschäftssystems, das benutzerdefinierte interne Anwendungen, Oracle Cloud Marketplace-Anwendungen, Oracle Business Analytics sowie andere Datenbanken, Compute-Instanzen und selbst entwickelte Anwendungen umfasst. Wählen Sie in diesem Fall einfach eine der Compute-Instanzen aus, die bereits Teil des Geschäftssystems sind, um die Skripte zu hosten. Bei der ausgewählten Compute-Instanz kann es sich um eine beliebige Instanz handeln, bei der Oracle Linux installiert ist. Wahrscheinlich handelt es sich um eine vorhandene VM, die einen anderen Zweck erfüllt, wie einen Anwendungsserver oder einen Admin-Server irgendeiner Art.

Normalerweise erfordert OCI 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. 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 alle benutzerdefinierten Skripte gespeichert werden können und von OCI Full Stack DR während eines Recovery-Vorgangs aufgerufen werden können.

Hinweis: In diesem Tutorial verwenden wir die Option 1, in der die benutzerdefinierten Skripte für die Oracle E-Business Suite-Anwendung auf den Oracle E-Business Suite-Anwendungsservern gespeichert werden.

Oracle E-Business Suite – Deployment-Architektur

Oracle E-Business Suite muss zunächst für Disaster Recovery (DR) über OCI-Regionen hinweg bereitgestellt werden, bevor OCI Full Stack DR eingeführt wird. Es ist sehr wichtig, dass die manuellen Schritte zur Durchführung einer Wiederherstellung getestet werden und korrekt funktionieren, bevor versucht wird, den Wiederherstellungsprozess mit OCI Full Stack DR zu automatisieren.

Bei der Bereitstellung von Oracle E-Business Suite für DR über OCI-Regionen hinweg können die beiden folgenden Referenzarchitekturen befolgt werden. Beide Referenzarchitekturen veranschaulichen eine Multi-Tier-Topologie mit redundanten Ressourcen, die über zwei OCI-Regionen verteilt sind.

Die Multi-Instance-Datenbanken werden mit Oracle Real Application Clusters (Oracle RAC) erstellt und verwenden Oracle Data Guard, um die Datenbank über zwei OCI-Regionen hinweg synchron zu halten.

Referenzarchitektur für Oracle E-Business Suite mit Oracle Base Database Service

Wählen Sie diese Deployment-Architektur, wenn Oracle E-Business Suite Oracle Base Database Service verwendet. Oracle E-Business Suite muss für DR in zwei OCI-Regionen bereitgestellt werden, wie unter Business Continuity for Oracle E-Business Suite Release 12.2 mit Oracle Database 19c on Oracle Base Database Service DB Systems (Dok.-ID 2875417.1) beschrieben. Die Abbildung in Abbildung 1 wurde aus Dok.-ID 2875417.1 abgerufen.

Abbildung 1: DR-Deployment-Architektur von Oracle E-Business Suite mit OCI Base Database (weitere Informationen finden Sie in Doc ID 2875417.1)

Referenzarchitektur für Oracle E-Business Suite mit Oracle Exadata Database Service on Dedicated Infrastructure

Wählen Sie diese Deployment-Architektur aus, wenn Oracle E-Business Suite Oracle Exadata Database Service on Dedicated Infrastructure verwendet. Oracle E-Business Suite muss für DR in zwei OCI-Regionen bereitgestellt werden, wie in Business Continuity for Oracle E-Business Suite Release 12.2 mit Oracle Database 19c on Oracle Exadata Database Service on Dedicated Infrastructure (Dok.-ID 2919723.1) beschrieben. Die Abbildung in Abbildung 1 wurde aus Dok.-ID 2919723.1 abgerufen.

Abbildung 2: Oracle E-Business Suite DR-Deployment-Architektur mit OCI Exadata Database (weitere Informationen finden Sie in Doc ID 2919723.1)

Unterschied zwischen logischen Hostnamen und physischen Hostnamen

Oracle E-Business Suite empfiehlt dringend, logische Hostnamen für die Anwendungsserver zu verwenden und physische Hostnamen für die Datenbank zu verwenden. Sowohl Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems (Dok.-ID 2875417.1) als auch Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems (Dok.-ID 2919723.1), die von Oracle E-Business Suite Engineering geschrieben wurden, erfordern, dass die Anwendungsebene logische Hostnamen verwendet, während die Datenbankebene physische Hostnamen verwendet.

OCI Full Stack DR hat keine Anforderungen daran, ob Sie logische oder physische Hostnamen verwenden. Wir empfehlen jedoch, die Oracle E-Business Suite-Anforderungen zu befolgen, um den Support von Oracle E-Business Suite bei Problemen sicherzustellen. Einige Kunden verwenden logische Hostnamen für Anwendungs- und Datenbank-Tiers. Die mit dieser Lösung bereitgestellten Skripte sind so konzipiert, dass sie mit logischen Hostnamen für die Anwendungsebene und die Datenbankebene für physische Hostnamen verwendet werden. Anweisungen zum Herunterladen finden Sie in Aufgabe 1.2.

OCI Full Stack DR-Deployment-Architektur

Die folgenden Abbildungen zeigen die Compute-Ressourcen, die jeder DR-Schutzgruppe (DRPG) für OCI Full Stack DR als Mitglieder hinzugefügt wurden. Diese stellen die verschiedenen Komponenten dar, die OCI Full Stack DR außerhalb der Oracle E-Business Suite-Anwendung verwalten kann.

OCI Full Stack DR verfügt über eine integrierte Automatisierung zur Verarbeitung von OCI Compute-, OCI Block Storage-, OCI File Storage-, Oracle-Datenbanken, OCI Load Balancer-, Oracle Cloud Infrastructure Kubernetes Engine-(OKE-)Clustern und vielen anderen Ressourcen während eines Recoverys, verfügt jedoch nicht über eine integrierte Automatisierung für Oracle E-Business Suite selbst. Das Oracle E-Business Suite-Recovery wird durch eine Reihe von bash-Skripten gesteuert, die aus einem GitHub-Repository heruntergeladen werden können, das diesem Tutorial gewidmet ist. Die bash-Skripte müssen auf einer Compute-Instanz Ihrer Wahl installiert werden, indem Sie eine der folgenden Optionen zur Platzierung und Kontrolle der Skripte befolgen.

Option 1: Recovery für Oracle E-Business Suite mit Oracle Base Database Service automatisieren

Diese Deployment-Architektur ist nicht typisch und wurde für sehr seltene Situationen entwickelt, in denen Oracle E-Business Suite die einzige Anwendung ist, die von OCI Full Stack DR wiederhergestellt wird. In diesem Fall werden die benutzerdefinierten Skripte in den Anwendungsknoten der Oracle E-Business Suite gehostet.

Abbildung 3: Full Stack DR-Deployment-Architektur mit OCI Base Database Service

Option 2: Recovery für Oracle E-Business Suite mit Oracle Exadata Database Service on Dedicated Infrastructure automatisieren

Die in Abbildung 4 dargestellte vereinfachte Deployment-Architektur ist ein Beispiel für ein häufigeres Deployment von Oracle E-Business Suite, bei dem 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 im folgenden Bild gezeigten fiktiven. Sie umfassen in der Regel zusätzliche Datenbanken, andere Oracle- und/oder Nicht-Oracle-Anwendungen sowie andere OCI-Services wie OIC, ODI, OHS, OCI IAM usw.

Abbildung 4: Full Stack DR-Deployment-Architektur mit Oracle Exadata Database Service on Dedicated Infrastructure

Definitionen und Annahmen im gesamten Tutorial

Bereiche

Die Rolle von Primär- und Standbydatenbanken ist eine Funktion der OCI Full Stack DR-Schutzgruppen, nicht der Regionen selbst. Eine Region kann als primär für einen Anwendungsstack fungieren und gleichzeitig als Standby für einen völlig anderen Anwendungsstack fungieren. Die Rolle von Primär- und Standbydatenbank ist flüssig.

Dieses Tutorial beginnt mit der Ausführung des Oracle E-Business Suite-Anwendungsstacks in Phoenix und aller Standbyressourcen, die in Ashburn ausgeführt werden. Diese beiden Regionen sind nur Beispiele. Zwei OCI-Regionen, die Ihren Anwendungsstack unterstützen, können in der Praxis verwendet werden.

Region 1 ist Phoenix.
- Phoenix wird als primäre Region beginnen.
- Phoenix beginnt als primäre Region, weil:
  - Die Oracle E-Business Suite-Anwendung wird in Phoenix ausgeführt.
  - Der rsync-Cron-Job für Oracle E-Business Suite kopiert Daten von /u01 auf den Oracle E-Business Suite-Anwendungsservern (VMs) in Phoenix auf die Anwendungsserver, die in Ashburn ausgeführt werden.
  - Die Datenbank in Phoenix hat die primäre Rolle von Oracle Data Guard.
- Phoenix wird schließlich zur Standby-Datenbank, nachdem Sie angewiesen wurden, in späteren Aufgaben ein Switchover durchzuführen.
Region 2 ist Ashburn.
- Ashburn wird als Standbyregion gestartet.
- Ashburn beginnt als Standby-Region, weil:
  - Die Standby-Anwendungsserver (VMs) der Oracle E-Business Suite werden in Ashburn ausgeführt.
  - Die Oracle E-Business Suite-Anwendung wird in Ashburn nicht ausgeführt.
  - Daten in /u01 werden von Phoenix in die VMs in Ashburn kopiert.
  - Die Datenbank in Ashburn hat die Oracle Data Guard-Standbyrolle.
- Ashburn wird schließlich zur primären Person, nachdem Sie angewiesen wurden, in späteren Aufgaben ein Switchover durchzuführen.

Compartments

Es steht Ihnen frei, Oracle E-Business Suite und OCI Full Stack DR in jedem Compartment-Schema zu organisieren, das gemäß Ihren Standards für IT-Governance funktioniert. Wir haben uns entschieden, Anwendungen in ihren eigenen Compartments zu organisieren und dann alle DR-Schutzgruppen in einem einzigen Compartment zu organisieren, in dem auf einen Blick ganz andere Geschäftssysteme zu sehen sind.

Die Organisation aller DR-Schutzgruppen in einem einzigen Compartment neben den Anwendungen erleichtert es IT-Mitarbeitern, DR-Pläne für viele völlig unterschiedliche Geschäftssysteme zu finden und auszuführen.
Ein einzelnes Compartment für alle DR-Schutzgruppen trägt dazu bei, menschliche Fehler zu vermeiden, und erhöht die Geschwindigkeit, mit der DR-Pläne gefunden und ausgeführt werden können.
- Compartment für Oracle E-Business Suite (ebstesting). Das Compartment für Oracle E-Business Suite selbst, Speicher, Speicher-Buckets, Compute und Datenbank für Oracle E-Business Suite ist ebstesting in diesem Tutorial.
- Compartment für OCI Full Stack DR myprojects. Das Compartment für OCI Full Stack DR-Schutzgruppen und -Pläne ist in diesem Tutorial myprojects.

Ziele

Die folgenden Aufgaben werden in diesem Tutorial erläutert, wie Sie die Wiederherstellung für Oracle E-Business Suite mit OCI Full Stack DR automatisieren.

Hinweis: Wir beginnen mit Region 1 (Phoenix) und Region 2 (Ashburn). Die Oracle E-Business Suite-Produktionsanwendung wird in Region 1 ausgeführt, und DR ist in Region konfiguriert. Dies ist wirklich wichtig, da im gesamten Tutorial Region 1 und Region 2 und nicht die tatsächliche Region name.If genannt werden, in der Ihr Deployment verschiedene OCI-Regionen verwendet. Stellen Sie dann sicher, dass Sie sich auf die jeweiligen Produktions- und DR-Regionen beziehen.

Aufgabe 1: Oracle E-Business Suite für DR über OCI-Regionen hinweg bereitstellen.
1. Installieren und implementieren Sie Oracle E-Business Suite für DR manuell in zwei OCI-Regionen.
2. Testen Sie manuell alle Recovery-Schritte aus der gewünschten Region 1 in Region 2.
3. Testen Sie manuell alle Recovery-Schritte von der gewünschten Region 2 bis zur Region 1.
Aufgabe 2: Vorbereitung auf OCI Full Stack DR.
1. Richten Sie OCI-IAM-Policys für Full Stack DR ein.
2. Richten Sie OCI-IAM-Policys für andere OCI-Services ein.
3. Laden Sie benutzerdefinierte Oracle E-Business Suite-Skripte herunter, und installieren Sie sie auf Oracle E-Business Suite-Anwendungsservern.
4. Stellen Sie sicher, dass Oracle E-Business Suite-Anwendungsserver Skripte und Befehle ausführen können.
5. Vault Secrets für die Oracle E-Business Suite-Datenbank erstellen
6. Erstellen Sie Objektspeicher-Buckets für Logs.
Aufgabe 3: DR-Schutzgruppen erstellen und zuordnen
Aufgabe 4: Oracle E-Business Suite-Datenbank- und Compute-Member zu DR-Schutzgruppen in Region 1 und Region 2 hinzufügen
Aufgabe 5: DR-Pläne in Region 2 (Ashburn) erstellen
1. Switchover-Plan erstellen
2. Failover-Plan erstellen
3. Startaufgliederungsplan erstellen.
Aufgabe 6: DR-Pläne in Region 2 (Ashburn) anpassen
Aufgabe 7: Switchover-Plan in Region 2 (Ashburn) ausführen
Aufgabe 8: Erstellen Sie grundlegende DR-Pläne in Region 1 (Phoenix), und passen Sie die DR-Pläne in Region 1 (Phoenix) an.
1. Erstellen Sie einen Switchover-Plan, und passen Sie den Switchover-Plan in Region 1 (Phoenix) an.
2. Erstellen Sie einen Failover-Plan, und passen Sie den Failover-Plan in Region 1 (Phoenix) an.
3. Erstellen Sie einen Start-Drill-Plan, und passen Sie den Start-Drill-Plan in Region 1 (Phoenix) an.

Voraussetzungen

Oracle E-Business Suite sollte für die Disaster Recovery in beiden Regionen bereitgestellt werden, bevor Sie mit OCI Full Stack DR arbeiten. Dies wird in Aufgabe 1 behandelt.

Aufgabe 1: Oracle E-Business Suite für Disaster Recovery bereitstellen

OCI Full Stack DR ist an keinem Teil dieser Aufgabe beteiligt.

Oracle E-Business Suite muss für Disaster Recovery über OCI-Regionen hinweg mithilfe eines von zwei verschiedenen My Oracle Support-(MOS-)Knowledge-Artikeln (KM-Hinweise) bereitgestellt werden, bevor Sie mit OCI Full Stack DR arbeiten können.

Außerdem ist es sehr wichtig, dass die in den KM-Hinweisen beschriebenen manuellen Schritte sowie die benutzerdefinierten Skripte/Automatisierung, die zum Wiederherstellen der Oracle E-Business Suite erforderlich sind, vollständig getestet wurden, bevor mit OCI Full Stack DR begonnen wird.

Oracle E-Business Suite unterstützt derzeit Oracle Base Database Service- und Oracle Exadata Database Service on Dedicated Infrastructure-Services. Oracle Autonomous Database-Service wird derzeit nicht mit Oracle E-Business Suite unterstützt. Befolgen Sie die Anweisungen in den folgenden KM-Notizen:

Aufgabe 2: Mandant für OCI Full Stack DR vorbereiten

OCI Full Stack DR ist an keinem Teil dieser Aufgabe beteiligt. Die folgenden Schritte bereiten den Mandanten, das Compartment, die OCI-Services und die Oracle E-Business Suite für die automatisierte Wiederherstellung durch OCI Full Stack DR vor. Die meisten in diesem Abschnitt beschriebenen Aufgaben werden unter Voraussetzungen für Full Stack Disaster Recovery erläutert.

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

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

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

OCI Full Stack DR muss in der Lage sein, andere wichtige OCI-Services wie Compute, Networking, Storage, Vaults, Datenbanken und andere verschiedene Services zu kontrollieren 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: Benutzerdefiniertes Oracle E-Business SuiteScripts auf Oracle E-Business Suite-Anwendungsservern herunterladen und installieren

OCI Full Stack DR verfügt über integrierte Intelligenz zur Orchestrierung des Recoverys für OCI Infrastructure as a Service-(IaaS-) und Platform as a Service-(PaaS-)Ressourcen. OCI Full Stack DR verfügt über keine integrierte Intelligenz zur Orchestrierung der Wiederherstellung für Oracle E-Business Suite, da Oracle E-Business Suite derzeit keine OCI-nativen Disaster Recovery-APIs zur Bereitstellung oder Verwaltung ihrer eigenen integrierten Disaster Recovery bereitstellt.

OCI Full Stack DR kann das Recovery für Oracle E-Business Suite jedoch weiterhin orchestrieren, indem benutzerdefinierte DR-Plangruppen und -schritte zu den im weiteren Verlauf dieses Tutorials erstellten DR-Basisplänen hinzugefügt werden. Wie im 1. Teil dieses Tutorials erläutert, rufen die benutzerdefinierten Schritte eine Reihe von benutzerdefinierten Skripten auf, die verschiedene Aufgaben ausführen, die für das Recovery von Oracle E-Business Suite erforderlich sind. Die Skripte müssen heruntergeladen und auf allen Compute-Instanzen auf den Oracle E-Business Suite-Anwendungsservern in beiden Regionen installiert werden:

Laden Sie die Oracle E-Business Suite-Skripte hier herunter: Oracle E-Business Suite-Skripte für OCI Full Stack Disaster Recovery.
Kopieren Sie die Skripte in ein beliebiges Verzeichnis auf jedem der Oracle E-Business Suite-Anwendungsserver in Region 1.
Kopieren Sie die Skripte in dasselbe Verzeichnis auf jedem der Oracle E-Business Suite-Anwendungsserver in Region 2.
Stellen Sie sicher, dass der Benutzer oracle Eigentümer der Dateien ist.
Stellen Sie sicher, dass die Dateien ausführbar sind.

Aufgabe 2.4: Sicherstellen, dass Oracle E-Business Suite Application Server Skripte und Befehle ausführen können

OCI Full Stack DR muss die Oracle E-Business Suite-Skripte ausführen, die auf die Oracle E-Business Suite-Anwendungsserver heruntergeladen wurden. OCI Full Stack DR führt die Skripte mit dem Oracle Cloud Agent auf jeder Compute-Instanz aus. Es ist sehr wichtig, dass alle Compute-Instanzen, die als Oracle E-Business Suite-Anwendungsserver in beiden Regionen verwendet werden, Befehle über die OCI-Konsole mit dem Oracle Cloud Agent ausführen können.

Weitere Informationen finden Sie unter Compute-Instanzen für Full Stack Disaster Recovery vorbereiten. Beachten Sie insbesondere die Anweisungen zum Ausführen von Befehlen mit Administratorberechtigungen.

Validieren, ob Befehle über die OCI-Konsole ausgeführt werden können

Hinweis: Mit dieser Aufgabe wird sichergestellt, dass der Oracle Could Agent Befehle ausführen kann. Es wird nicht validiert, ob geeignete Policys vorhanden sind, damit Full Stack DR Befehle über den Oracle Cloud Agent ausführen kann. Dies wird in späteren Schritten deutlich, wenn das Tutorial erläutert, wie Sie den Switchover-DR-Plan in Region 2 validieren.

Verwenden Sie das Befehlsausführungsfeature der installierten Compute-Instanz, um zu validieren, dass Oracle Cloud Agent Befehle ausführen kann. Die folgenden Images zeigen den Befehl "Ausführen" auf der Detailseite für Compute-Instanzen in der OCI-Konsole.

Wählen Sie Befehl ausführen aus.
Wählen Sie Create command (Befehl erstellen), und geben Sie einen beliebigen gültigen Linux-Befehl ein, wie date. Ändern Sie den Timeout in etwa 3 Minuten, bevor Sie den Befehl ausführen.

Abbildung 2.4.1.1: Führen Sie einen Befehl über die OCI-Konsole aus

Aufgabe 2.5: OCI Vault-Secrets für die Oracle E-Business Suite-Datenbank erstellen

OCI Full Stack DR benötigt das Kennwort der Datenbank sys, damit Oracle Data Guard bei Failovers und Switchovers automatisch ausgelöst werden kann. Fügen Sie das sys-Datenbankkennwort in beiden Regionen zu einem Vault Secret hinzu, wie hier beschrieben: Oracle-Datenbanken für Full Stack Disaster Recovery vorbereiten.

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

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

Erstellen Sie OCI Object Storage-Buckets in der Primär- und Standbyregion, um Logs zu speichern, die von OCI Full Stack DR während Recovery-Vorgängen generiert wurden, wie hier beschrieben: Logspeicherort für Vorgangslogs vorbereiten.

Aufgabe 2.6.1: Zu OCI Object Storage navigieren

Navigieren Sie zunächst zu Object Storage & Archive Storage, wie in Abbildung 2-1 dargestellt.

Stellen Sie sicher, dass der Browserkontext auf Region 1 (Phoenix) gesetzt ist.
Klicken Sie auf Speicher.
Klicken Sie auf Buckets.

Abbildung 2.6.1.1: Zu Objektspeicher navigieren

Aufgabe 2.6.2: OCI-Objektspeicher-Bucket in Region 1 und 2 erstellen

Erstellen Sie einen OCI Object Storage-Bucket in Region 1. Erstellen Sie dann einen identischen Speicher-Bucket in Region 2. Die Buckets werden den DR-Schutzgruppen in Region 1 und 2 in einer späteren Aufgabe zugewiesen.

Wählen Sie das Compartment aus, das Oracle E-Business Suite-bezogene Ressourcen enthält. Das Compartment kann in jeder Region unterschiedlich sein.
Klicken Sie auf Bucket erstellen.
Geben Sie dem Bucket einen aussagekräftigen Namen, der einfach identifiziert, welcher Anwendung und welchem Zweck er dient. Es gibt keinen Grund, die Region als Teil des Namens aufzunehmen. Beispiel: Dieser Name gibt an, dass er für die OCI Full Stack DR-Logs verwendet wird, die sich auf DR-Vorgänge für Oracle E-Business Suite beziehen.
Verwenden Sie den Standardwert für Tier und Verschlüsselung.
Klicken Sie auf Erstellen, um den Bucket zu erstellen.

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

Aufgabe 3: DR-Schutzgruppen erstellen und zuordnen

Dies ist die erste Aufgabe, die Full Stack DR umfasst. Erstellen Sie DR-Schutzgruppen in Region 1 und Region 2, wenn die Schutzgruppen für diesen Anwendungsstack noch nicht vorhanden sind.

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

Mit dieser Aufgabe wird der erste Schritt zur Konfiguration von OCI Full Stack DR für den Anwendungsstack gestartet, der Oracle E-Business Suite enthält. DR-Schutzgruppen informieren OCI Full Stack DR, welche OCI-Services IaaS und PaaS Teil eines einzelnen Anwendungsstacks sind und welche zwei Regionen als Primär- und Standby-Services für das Geschäftssystem fungieren. DR-Schutzgruppen bilden die Grundlage, auf der alles andere aufgebaut ist.

Alle OCI-Ressourcen IaaS und PaaS, die in beiden Regionen zum Anwendungsstack gehören, werden als Teil von Aufgabe 4 hinzugefügt.

Hinweis: Obwohl dieses Tutorial nur Oracle E-Business Suite umfasst, enthalten DR-Schutzgruppen normalerweise OCI-Services IaaS und PaaS für viele verschiedene Oracle- und Nicht-Oracle-Anwendungen und zusätzlich zu den Services, die von Oracle E-Business Suite benötigt werden.

Aufgabe 3.1: Schutzgruppe in Standbyregion 2 erstellen (Ashburn)

Erstellen Sie zunächst eine nicht zugeordnete DR-Schutzgruppe in Region 2. Es ist nicht erforderlich, dass die Schutzgruppe in der Standby-Region erstellt wird. Der Prozess fließt nur ein wenig besser, wenn er in Region 2 gestartet wird.

Aufgabe 3.1.1: Zu DR-Schutzgruppen navigieren

Navigieren Sie zunächst zu DR-Schutzgruppen (OCI Full Stack DR), wie in Abbildung 3.1.1 dargestellt.

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

Abbildung 3.1.1: Zu DR-Schutzgruppen navigieren

Aufgabe 3.1.2: Schutzgruppe erstellen

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

Wählen Sie das Compartment aus, in dem das DRPG erstellt werden soll. Dies kann dasselbe Compartment sein, in dem Oracle E-Business Suite-Ressourcen vorhanden sind, oder ein anderes Compartment, das sich auf das Projekt bezieht.
Wählen Sie DR-Schutzgruppe erstellen aus, um das Dialogfeld zu öffnen, in dem Sie die Parameter zum Erstellen der Schutzgruppe eingeben.

Abbildung 3.1.2: Erstellen der DR-Schutzgruppe in Region 2 beginnen

Aufgabe 3.1.3: Erforderliche Parameter zum Erstellen der Schutzgruppe hinzufügen

Fügen Sie einen Namen und einen OCI Object Storage-Bucket für die Logs hinzu, wie in Abbildung 3.1.3 dargestellt.

Verwenden Sie einen aussagekräftigen, einfachen Namen für das DRGP. In diesem Beispiel werden der Name des Geschäftssystems und die Region angezeigt.
Wählen Sie das Compartment aus, in dem das DRPG in Region 2 erstellt werden soll.
Wählen Sie den Objektspeicher-Bucket aus, der in Aufgabe 2 für Region 2 erstellt wurde. Sie müssen das Compartment möglicherweise ändern, wenn Sie den Bucket in einem anderen Compartment erstellt haben.

Geben Sie keine zusätzlichen Parameter ein. Klicken Sie unten im Dialogfeld auf Erstellen (hier nicht dargestellt).

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

Was Sie nach dem Erstellen der Schutzgruppe sehen sollten

Die erste DR-Schutzgruppe wird erstellt, wie in Abbildung 3-2.3 gezeigt. Die Rollen- und Peerinformationen werden als Teil von Aufgabe 3.4 zugewiesen.

Abbildung 3.1.4: Die neu erstellte DR-Schutzgruppe in Region 2 wird angezeigt

Aufgabe 3.2: Schutzgruppe in primärer Region 1 erstellen (Phoenix)

Erstellen Sie eine Schutzgruppe in Region 1. In einer späteren Aufgabe fügen Sie alle OCI-Ressourcen hinzu, die zum Anwendungsstack in dieser Region gehören. So weiß OCI Full Stack DR, welche Assets als Teil eines Geschäftssystems in dieser Region gelten.

Aufgabe 3.2.1: Schutzgruppe erstellen

Erstellen Sie eine grundlegende DR-Schutzgruppe (DRPG) in Region 1, wie in Abbildung 3.2.1 gezeigt. Peer, Rolle und Mitglieder werden in späteren Schritten zugewiesen.

Ändern Sie den OCI-Regionskontext in Region 1.
Wählen Sie das Compartment aus, in dem das DRPG erstellt werden soll. Normalerweise wählen die Benutzer dasselbe Compartment aus, das zum Erstellen des DRPG in Region 2 verwendet wurde.
Wählen Sie DR-Schutzgruppe erstellen aus, um das Dialogfeld zu öffnen, in dem Sie die Parameter zum Erstellen der Schutzgruppe eingeben.

Abbildung 3.2.1: Erstellen der DR-Schutzgruppe in Region 1

Aufgabe 3.2.2: Erforderliche Parameter zum Erstellen der Schutzgruppe hinzufügen

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

Verwenden Sie einen aussagekräftigen, einfachen Namen für die DR-Gruppe PRotection. In diesem Beispiel werden der Name des Geschäftssystems und die Region angezeigt.
Wählen Sie das Compartment aus, in dem das DRPG in Region 1 erstellt werden soll. In beiden Regionen wird in der Regel dasselbe Compartment verwendet.
Wählen Sie den Objektspeicher-Bucket aus, der in Aufgabe 2 für Region 1 erstellt wurde. Sie müssen das Compartment möglicherweise ändern, wenn Sie den Bucket in einem anderen Compartment erstellt haben.

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

Was Sie nach dem Erstellen der Schutzgruppe sehen sollten

Die zweite DR-Schutzgruppe wird wie in Abbildung 3.2.3 dargestellt erstellt. Die Rollen- und Peerinformationen werden als Teil von Aufgabe 3.3 zugewiesen.

Abbildung 3.2.3: Die neu erstellte DR-Schutzgruppe in Region 2 wird angezeigt

Aufgabe 3.3: Schutzgruppen in Region 1 und Region 2 zuordnen

Verknüpfen Sie die DRPGs in jeder Region als Peers untereinander, und weisen Sie die Rollen von Primär- und Standbydatenbank zu. So weiß OCI Full Stack DR, welche zwei Regionen für die Wiederherstellung der Oracle E-Business Suite zusammenarbeiten. Die Rollen von Primär- und Standbydatenbank werden automatisch von OCI Full Stack DR im Rahmen einer DR-Operation/DR-Planausführung geändert. Die Rollen müssen nicht manuell verwaltet werden, nachdem den DRPGs ihre anfänglichen Rollen in dieser Aufgabe zugewiesen wurden.

Aufgabe 3.3.1: Verknüpfung beginnen

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

Abbildung 3.3.1: DRPG-Verknüpfung beginnen

Aufgabe 3.3.2: Schutzgruppen in Region 1 und Region 2 zuordnen

Geben Sie die Parameter wie in Abbildung 3.3.2 dargestellt an.

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

Abbildung 3.3.2: Erforderliche Parameter für die Zuordnung der DRPGs

Was Sie nach Abschluss der Zuordnung sehen sollten:

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

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

Abbildung 3.3.3: Peer-Beziehung aus der individuellen DRPG-Perspektive anzeigen

Die gleichen Informationen finden Sie, wenn der Kontext/die Ansicht aus globaler Perspektive alle DR-Schutzgruppen zeigt, wie in Abbildung 3.4.3.2 dargestellt.

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

Abbildung 3.4.3.2: Peerbeziehung aus globaler DRPG-Perspektive anzeigen

Aufgabe 4: Oracle E-Business Suite-Mitglieder zu DR-Schutzgruppen der Regionen 1 und 2 hinzufügen

Fügen Sie die Datenbank und die nicht verschiebenden Oracle E-Business Suite-Anwendungsserver als Mitglieder der DR-Schutzgruppe (DRPG) in beiden Regionen hinzu. Nicht bewegliches Computing bedeutet, dass die Oracle E-Business Suite-Anwendungsserver, die in Region 1 vorhanden sind, nie in Region 2 gestartet oder gestartet werden. Die Boot-Volumes für nicht verschiebende Compute-Instanzen werden nicht mit der OCI Storage-Replikation in Region 2 repliziert und nicht als Mitglieder einer der DR-Schutzgruppen hinzugefügt.

Dieses Tutorial zeigt nur Schritte im Zusammenhang mit Oracle E-Business Suite. Sie sollten jedoch auch diese Gelegenheit nutzen, um zusätzliche OCI-Services IaaS und PaaS hinzuzufügen, die zusammen mit Oracle E-Business Suite wiederhergestellt werden müssen. Beispiel: Andere verschiebende Compute-, nicht verschiebende Compute-, Datenbanken, Load Balancer, Dateisysteme, Blockspeicher oder Objektspeicher sind mit anderen internen oder Oracle-Anwendungen verknüpft, die Teil des Oracle E-Business Suite-Ökosystems sind.

Hinweis: Mit dieser Aufgabe werden alle vorhandenen DR-Pläne in beiden Regionen aktualisiert, wenn Mitglieder zu vorhandenen DR-Schutzgruppen hinzugefügt werden. Weitere Informationen finden Sie unter Disaster-Recovery-Plan aktualisieren.

Aufgabe 4.1: Mitgliederressourcen zu DR-Schutzgruppe zu Region 1 hinzufügen (Phoenix)

Sie fügen die folgenden Ressourcen als Mitglieder des primären DRPG in Region 1 hinzu.

Zwei nicht bewegliche Oracle E-Business Suite-Anwendungsserver (Oracle E-Business Suite installiert und ausgeführt).
Die Oracle RAC-Datenbank für Oracle E-Business Suite (primärer Peer von Oracle Data Guard).

Aufgabe 4.1.1: Zur primären DR-Schutzgruppe navigieren

Navigieren Sie zur DR-Schutzgruppe in Bereich 1, wie in Abbildung 4.1.1 dargestellt.

Stellen Sie sicher, dass der OCI-Regionskontext Region 1 (Phoenix) ist.
Wählen Sie die DR-Schutzgruppe in Region 1 aus.

Abbildung 4.1.1: Navigieren Sie zur DR-Schutzgruppe in Region 1

Aufgabe 4.1.2: Oracle E-Business Suite Application Server 1 hinzufügen

Öffnen Sie zunächst das Dialogfeld Element hinzufügen, um den ersten Anwendungsserver hinzuzufügen.

Klicken Sie auf Mitglieder.
Klicken Sie auf Mitglied hinzufügen.

Abbildung 4.1.2.1: Öffnen Sie das Dialogfeld "Elemente hinzufügen".

Wählen Sie Anwendungsserver 1 in Region 1 aus, wie in Abbildung 4.1.2.2 dargestellt. Sie müssen keine Block-Volume-Gruppen hinzufügen oder Netzwerkeigenschaften angeben, da es sich um eine nicht zu verschiebende Instanz handelt.

Wählen Sie Compute als Ressourcentyp aus.
Wählen Sie das Compartment mit den Oracle E-Business Suite-Anwendungsservern aus, und wählen Sie die Compute-Instanz aus, die Sie als Anwendungsserver 1 angegeben haben.
Wählen Sie Nicht zu verschiebende Instanz aus. Dadurch wird OCI Full Stack DR informiert, dass während eines DR-Vorgangs nicht versucht werden sollte, eine replizierte virtuelle Maschine in der Standbyregion zu starten.
Klicken Sie auf Hinzufügen, um die Compute-Instanz zum DRPG hinzuzufügen (nicht dargestellt).

Abbildung 4.1.2.2: Parameter für Anwendungsserver 1 angeben

Aufgabe 4.1.3: Oracle E-Business Suite Application Server 2 hinzufügen

Klicken Sie auf Mitglied hinzufügen.

Abbildung 4.1.3.1: Öffnen Sie das Dialogfeld "Elemente hinzufügen".

Wählen Sie Anwendungsserver 2 in Region 1 aus, wie in Abbildung 4.1.3.2 dargestellt. Sie müssen keine Block-Volume-Gruppen hinzufügen oder Netzwerkeigenschaften angeben, da es sich um eine nicht zu verschiebende Instanz handelt.

Wählen Sie Compute als Ressourcentyp aus.
Wählen Sie das Compartment mit den Oracle E-Business Suite-Anwendungsservern aus, und wählen Sie die Compute-Instanz aus, die Sie als Anwendungsserver 2 angegeben haben.
Wählen Sie Nicht zu verschiebende Instanz aus. Dadurch wird OCI Full Stack DR informiert, dass während eines DR-Vorgangs nicht versucht werden sollte, eine replizierte virtuelle Maschine in der Standbyregion zu starten.
Klicken Sie auf Hinzufügen, um die Compute-Instanz zum DRPG hinzuzufügen (nicht dargestellt).

Abbildung 4.1.3.2: Parameter für Anwendungsserver 2 angeben

Aufgabe 4.1.4: Primäre geclusterte Oracle Database hinzufügen

Klicken Sie auf Element hinzufügen, um die Datenbank als Element hinzuzufügen.

Abbildung 4.1.4.1: Öffnen Sie das Dialogfeld "Elemente hinzufügen".

Wählen Sie die RAC-Datenbank für Oracle E-Business Suite in Region 1 aus, wie in Abbildung 4.1.4.2 dargestellt. Dies funktioniert auch bei Einzelinstanzdatenbanken genau gleich.

Wählen Sie Datenbank als Ressourcentyp aus. Der Ressourcentyp Datenbank ermöglicht die Auswahl von Oracle Base Database Service oder Oracle Exadata Database Service on Dedicated Infrastructure, die beide von Oracle E-Business Suite Engineering als gültige Auswahl unterstützt werden.
Die Abbildung zeigt Oracle Base Database Service. Sie können jedoch auch den beliebten Oracle Exadata Database Service on Dedicated Infrastructure verwenden.
Wählen Sie die Werte für diese Felder aus, die Ihrer Bereitstellung entsprechen. Fragen Sie Ihren Datenbankadministrator, wenn Sie die Antworten auf diese Auswahl nicht kennen.
Wählen Sie das Compartment und das Vault Secret mit dem Kennwort für die Datenbank aus. Sie hätten einen ähnlichen Vault und ein ähnliches Secret in Region 2 als Teil von Aufgabe 2.4 erstellen müssen. Dieser Parameter befindet sich aus Gründen der Kompatibilität mit anderen DBaaS-APIs im Dialogfeld, aber das Kennwort wird überhaupt nicht verwendet.
Klicken Sie auf Hinzufügen, um die Datenbank als Mitglied hinzuzufügen (wird nicht angezeigt).

Abbildung 4.1.4.2: Parameter für RAC-Datenbank in Region 1 angeben

Die Liste der Mitglieder in der DR-Schutzgruppe sollte ungefähr wie der Screenshot in Abbildung 4.1.4.3 aussehen. Möglicherweise sieht Ihre Liste anders aus, wenn Sie dieser DR-Schutzgruppe mehr als Oracle E-Business Suite hinzufügen oder einer vorhandenen DR-Schutzgruppe Oracle E-Business Suite-Mitgliedsressourcen hinzufügen.

Abbildung 4.1.4.3: Vollständige Liste der Elemente, die für Oracle E-Business Suite in Region 1 erforderlich sind

Aufgabe 4.2: Mitgliederressourcen zu DRPG in Region 2 hinzufügen (Ashburn)

Sie fügen die in der Liste angezeigten Ressourcen als Mitglieder des Standby-DRPG in Region 2 hinzu.

Die beiden nicht beweglichen Oracle E-Business Suite-Anwendungsserver (Oracle E-Business Suite installiert, aber nicht ausgeführt).
Die RAC-Datenbank für Oracle E-Business Suite (Oracle Data Guard Standby Peer).

Für Oracle E-Business Suite müssen Anwendungsserver in beiden Regionen vorhanden sein, in denen die Anwendung installiert ist. Die Anwendungsserver müssen sich jederzeit in der Standby-Region in einem aktiven Status befinden, wobei die Oracle E-Business Suite-Anwendung installiert ist, jedoch nicht in der Standby-Region ausgeführt wird.

Das bedeutet, dass Betriebssystem- und Anwendungsupgrades, Patches und andere routinemäßige Wartungsarbeiten in beiden Regionen unabhängig voneinander durchgeführt werden müssen.

OCI Full Stack DR bezeichnet dieses Modell als nicht verschiebbares Compute, da die VMs nicht in einer anderen Region repliziert werden und während eines DR-Vorgangs niemals in andere Regionen verschieben werden. Bootgeräte für Compute-Instanzen, die in OCI Full Stack DR als nicht verschiebbares Compute angegeben sind, dürfen nicht in die Standbyregion repliziert werden. Daher werden den DR-Schutzgruppen (DRPG) keine replizierten Block-Volume-Gruppen hinzugefügt, die Bootgeräte für nicht verschiebbares Computing enthalten.

Hinweis: Wie bereits erwähnt, ist es ungewöhnlich, dass Oracle E-Business Suite die einzige Anwendung oder der einzige Service ist, die mit einem Paar OCI Full Stack DR-Schutzgruppen verknüpft ist. Sie können auch andere IaaS- und PaaS-Ressourcen als Mitglieder der DR-Schutzgruppe in der Standbyregion verwenden.

Aufgabe 4.2.1: Zu Standby-DR-Schutzgruppe navigieren

Navigieren Sie zur DR-Schutzgruppe in Bereich 2, wie in Abbildung 4.2.1 dargestellt.

Stellen Sie sicher, dass der OCI-Regionskontext Region 2 (Ashburn) ist.
Wählen Sie die DR-Schutzgruppe in Region 2 aus.

Abbildung 4.2.1: Navigieren Sie zur DR-Schutzgruppe in Region 2

Aufgabe 4.2.2: Oracle E-Business Suite Application Server 1 hinzufügen

Öffnen Sie zunächst das Element hinzufügen, um den ersten Anwendungsserver hinzuzufügen.

Wählen Sie Elemente aus.
Klicken Sie auf Mitglied hinzufügen.

Abbildung 4.2.2.1: Öffnen Sie das Dialogfeld "Elemente hinzufügen".

Wählen Sie Application Server 1 in Region 2 aus, wie in Abbildung 4.2.2.2 dargestellt. Sie müssen keine Block-Volume-Gruppen hinzufügen oder Netzwerkeigenschaften angeben, da es sich um eine nicht zu verschiebende Instanz handelt.

Wählen Sie Compute als Ressourcentyp aus.
Wählen Sie das Compartment mit den Oracle E-Business Suite-Anwendungsservern aus, und wählen Sie die Compute-Instanz aus, die Sie als Anwendungsserver 1 angegeben haben.
Wählen Sie Nicht zu verschiebende Instanz aus. Dadurch wird OCI Full Stack DR informiert, dass während eines DR-Vorgangs nicht versucht werden sollte, eine replizierte virtuelle Maschine in der Standbyregion zu starten.
Klicken Sie auf Hinzufügen, um die Compute-Instanz zum DRPG hinzuzufügen (nicht dargestellt).

Abbildung 4.2.2.2: Parameter für Anwendungsserver 1 angeben

Aufgabe 4.2.3: Oracle E-Business Suite Application Server 2 hinzufügen

Klicken Sie auf Element hinzufügen, um den 2. Anwendungsserver hinzuzufügen.

Abbildung 4.2.3.1: Öffnen Sie das Dialogfeld "Elemente hinzufügen".

Wählen Sie Anwendungsserver 2 in Region 2 aus, wie in Abbildung 4.2.3.2 dargestellt. Sie müssen keine Block-Volume-Gruppen hinzufügen oder Netzwerkeigenschaften angeben, da es sich um eine nicht zu verschiebende Instanz handelt.

Wählen Sie Compute als Ressourcentyp aus.
Wählen Sie das Compartment mit den Oracle E-Business Suite-Anwendungsservern aus, und wählen Sie die Compute-Instanz aus, die Sie als Anwendungsserver 2 angegeben haben.
Wählen Sie Nicht zu verschiebende Instanz aus. Dadurch wird OCI Full Stack DR informiert, dass während eines DR-Vorgangs nicht versucht werden sollte, eine replizierte virtuelle Maschine in der Standbyregion zu starten.
Klicken Sie auf Hinzufügen, um die Compute-Instanz zum DRPG hinzuzufügen (nicht dargestellt).

Abbildung 4.2.3.2: Parameter für Anwendungsserver 2 angeben

Aufgabe 4.2.4: Geclusterte Oracle Standby-Datenbank hinzufügen

Klicken Sie auf Element hinzufügen, um die Datenbank als Element hinzuzufügen.

Abbildung 4.2.4.1: Öffnen Sie das Dialogfeld "Elemente hinzufügen".

Wählen Sie die RAC-Datenbank für Oracle E-Business Suite in Region 2 aus, wie in Abbildung 4.2.4.2 dargestellt. Dies funktioniert auch bei Einzelinstanzdatenbanken genau gleich.

Wählen Sie Datenbank als Ressourcentyp aus. Der Ressourcentyp Datenbank ermöglicht die Auswahl von Oracle Base Database Service oder Oracle Exadata Database Service on Dedicated Infrastructure, die beide von Oracle E-Business Suite Engineering als gültige Auswahl unterstützt werden.
Die folgende Abbildung zeigt Oracle Base Database Service. Sie können jedoch auch den beliebten Oracle Exadata Database Service on Dedicated Infrastructure verwenden.
Wählen Sie die Werte für diese Felder aus, die Ihrer Bereitstellung entsprechen. Fragen Sie Ihren Datenbankadministrator, wenn Sie die Antworten auf diese Auswahl nicht kennen.
Wählen Sie das Compartment und das Vault Secret mit dem Kennwort für die Datenbank aus. Sie hätten einen ähnlichen Vault und ein ähnliches Secret in Region 2 als Teil von Aufgabe 2.4 erstellen müssen. Dieser Parameter befindet sich aus Gründen der Kompatibilität mit anderen DBaaS-APIs im Dialogfeld, das Kennwort wird jedoch überhaupt nicht verwendet.
Klicken Sie auf Hinzufügen, um die Datenbank als Mitglied hinzuzufügen (wird nicht angezeigt).

Abbildung 4.2.4.2: Parameter für RAC-Datenbank in Region 2 angeben

Die Liste der Mitglieder in der DR-Schutzgruppe sollte ungefähr wie der Screenshot in Abbildung 4.2.4.3 aussehen. Möglicherweise sieht Ihre Liste anders aus, wenn Sie dieser DR-Schutzgruppe mehr als Oracle E-Business Suite hinzufügen oder einer vorhandenen DR-Schutzgruppe Oracle E-Business Suite-Mitgliedsressourcen hinzufügen.

Abbildung 4.2.4.3: Vollständige Liste der Elemente, die für Oracle E-Business Suite in Region 2 erforderlich sind

Aufgabe 5: DR-Pläne in Teilsektor 2 erstellen

Mit dieser Aufgabe werden grundlegende Switchover-, Failover- und Start-Drill-Pläne erstellt, die der Standby-DR-Schutzgruppe in Region 2 (Ashburn) zugeordnet sind.

Der Zweck jedes Plans besteht darin, die Workload von der primären Region 1 in die Standby-Region 2 zu übertragen. Die Rollen der DR-Schutzgruppen in beiden Regionen werden automatisch im Rahmen eines DR-Vorgangs umgekehrt. Daher wird die Schutzgruppe in Region 1 zur Standby-Gruppe und die Schutzgruppe in Region 2 zur primären Gruppe nach einem Failover oder Switchover.

OCI Full Stack DR füllt beide Pläne vorab mit integrierten Schritten auf, die auf den Member-Ressourcen basieren, die in den vorherigen Aufgaben hinzugefügt wurden. Die Pläne werden in späteren Schritten angepasst, um alle Aufgaben im Zusammenhang mit Oracle E-Business Suite System während eines Recovery-Vorgangs zu bearbeiten.

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

Erstellen Sie grundlegende Pläne, indem Sie das DRPG in Region 2 auswählen, wie in Abbildung 5-1 gezeigt.

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

Abbildung 5-0: Grundlegende DR-Pläne in Region 2 erstellen

Aufgabe 5.1: DR-Plan für Switchover zu Region 2 erstellen

Die Erstellung eines DR-Plans ist einfach, wie in Abbildung 5-2 gezeigt.

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

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

Aufgabe 5.2: DR-Plan für Failover zu Region 2 erstellen

Folgen Sie dem gleichen Prozess, um einen einfachen Failover-Plan zu erstellen, wie in Abbildung 5-2 gezeigt.

Machen Sie den Namen des Failover-Plans einfach, aber aussagekräftig.
Wählen Sie Plantyp aus. Zum Zeitpunkt dieses Schreibens gibt es nur vier Plantypen.

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

Aufgabe 5.3: DR-Plan für Start-Drilldown in Region 2 erstellen

Folgen Sie dem gleichen Prozess, um einen Start-Drill-Plan zu erstellen, wie in Abbildung 5-3 gezeigt.

Machen Sie den Namen des Startaufgliederungsplans einfach, aber aussagekräftig.
Wählen Sie Plantyp aus. Zum Zeitpunkt dieses Schreibens gibt es nur vier Plantypen.

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

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

Abbildung 5-4: Drei grundlegende DR-Pläne anzeigen, die in Region 2 vorhanden sein müssen, bevor Sie fortfahren

Hinweis: OCI Full Stack DR unterstützt das Erstellen eines Stopp-Drill-Plans erst, nachdem der Start-Drill-Plan erfolgreich ausgeführt wurde. Für das Tutorial ist es nicht möglich, einen Stopp-Drill-Plan zu erstellen. Es wird jedoch dringend empfohlen, auch in beiden DR-Schutzgruppen einen Stopp-Drill zu erstellen.

Aufgabe 6: DR-Pläne in Region 2 anpassen (Ashburn)

OCI Full Stack DR kann das Recovery für Oracle E-Business Suite jedoch weiterhin orchestrieren, indem den im Rahmen von Aufgabe 5 erstellten Basis-DR-Plänen benutzerdefinierte DR-Plangruppen und -schritte hinzugefügt werden. Die benutzerdefinierten Schritte rufen die Oracle E-Business Suite-Skripte auf, die auf den Oracle E-Business Suite-Anwendungsservern in beiden Regionen oder in einem dedizierten DR-Kontrollknoten als Teil von Aufgabe 2.3 heruntergeladen und installiert wurden. Im Folgenden werden die benutzerdefinierten Plangruppen auf hoher Ebene aufgeführt. Die hinzuzufügenden Plangruppen variieren je nach DR-Plantyp.

Fahren Sie Oracle E-Business Suite herunter, und deaktivieren Sie rsync-Jobs auf node2 in Region 1.
Fahren Sie Oracle E-Business SuiteS herunter, und deaktivieren Sie rsync-Jobs in node1 in Region 1.
Löschen Sie Knotennamen in Datenbank-FND-Tabellen in Region 2.
Anwendungskontext in Datenbank auf node1 in Region 2 einrichten.
Anwendungskontext in Datenbank auf node2 in Region 2 einrichten.
Führen Sie autoconfig auf node1 in Region 2 aus.
Führen Sie autoconfig auf node2 in Region 2 aus.
Starten Sie Oracle E-Business Suite, und aktivieren Sie rsync-Jobs auf node1 in Region 2.
Starten Sie Oracle E-Business Suite, und aktivieren Sie rsync-Jobs auf node2 in Region 2.

Aufgabe 6.1: Switchover-Plan auswählen

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

alle Pläne-iad.png
Abbildung 6.1: Switchover-Plan in Region 2 auswählen

OCI Full Stack DR generiert die Plangruppen Prechecks-Built in und Databases-Switchover. Diese wurden basierend auf den Mitgliedern generiert, die wir den DR-Schutzgruppen in Region 1 und Region 2 hinzugefügt haben.

Abbildung 6.1.1: Standardplangruppen für Switchover-Plan in Region 2

Aufgabe 6.2: Plangruppe erstellen, um Oracle E-Business Suite herunterzufahren und Rsync-Jobs auf Knoten 2 in Region 1 zu deaktivieren

Fügen Sie nun benutzerdefinierte DR-Plangruppen hinzu.

Die erste benutzerdefinierte Plangruppe fährt Oracle E-Business Suite herunter und deaktiviert rsync-Jobs in node2 in Region 1. Diese Plangruppe enthält zwei Schritte, mit denen die bash-Skripte shutdownapps.sh und fsdr-rsync-ebs.sh aufgerufen werden, die in Aufgabe 2.3 auf die Serverknoten der Oracle E-Business Suite-App heruntergeladen wurden.

Aufgabe 6.2.1: Plangruppe hinzufügen

Beginnen Sie mit dem Prozess zum Hinzufügen einer Plangruppe.

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

Abbildung 6-2.1: Fügen Sie eine Plangruppe hinzu, um Oracle E-Business Suite herunterzufahren und rsync-Jobs auf node2 zu deaktivieren

Aufgabe 6.2.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Eine DR-Plangruppe kann viele Schritte enthalten, die alle parallel ausgeführt werden. Wir werden zwei Schritte hinzufügen, um bash-Skripte auszuführen, um Oracle E-Business Suite auf node2 zu stoppen und rsync-Cron-Jobs auf node2 in Region 1 zu deaktivieren. Im Beispielnamen node2 lautet ebshaapp02phx.

Geben Sie der Plangruppe einen einfachen, aber beschreibenden Namen.
Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall wird die benutzerdefinierte Plangruppe vor der Plangruppe Datenbanken-Switchover hinzugefügt.
Wählen Sie die integrierte Plangruppe Datenbanken - Switchover aus.
Wir werden zwei Schritte hinzufügen. Der erste Schritt besteht darin, Oracle E-Business Suite auf Knoten 2 zu stoppen, und das zweite Skript besteht darin, rsync-Jobs auf Knoten 2 zu deaktivieren.
Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Stoppen der Oracle E-Business Suite unter node2 angegeben wird.

Abbildung 6.2.2: Plangruppe zum Herunterfahren von Oracle E-Business Suite und Stoppen von rsync-Jobs

Aufgabe 6.2.3: Schrittnamen und lokale Skriptparameter angeben

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter angeben, wie dieser Schritt ausgeführt wird und wie er sich während des Recoverys verhalten soll. Wir werden dieser Plangruppe zwei Schritte hinzufügen.

Schritt 1: Stoppen Sie die Oracle E-Business Suite-App auf node2.
Schritt 2: dient zum Deaktivieren von rysnc-Jobs in node2.

Für dieses Setup ist Knoten 2 ebshaapp02phx

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

Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie die Region 1, in unserem Fall ist es Phoenix.
Wählen Sie Lokales Skript ausführen aus.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node2 aus, und wählen Sie Knoten 2 aus, in unserem Fall ebshaapp02phx.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript shutdownapps.sh in der Oracle E-Business Suite-App node2 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan muss gestoppt werden, wenn das Skript die Oracle E-Business Suite-App auf node2 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 1800 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.2.3.1: Parameter zum Erstellen des Planschritts für das Stoppen von Oracle E-Business Suite auf Knoten 2
Es wird wie folgt angezeigt, sobald der Schritt 1 hinzugefügt wird.

Abbildung 6.2.3.2: Schritt "Oracle E-Business Suite auf Knoten 2 stoppen" wird hinzugefügt
Klicken Sie auf Schritt hinzufügen, um dieser Plangruppe einen zweiten Schritt hinzuzufügen.
Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie die Region 1, in unserem Fall ist es Phoenix.
Wählen Sie Lokales Skript ausführen aus.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node2 aus, und wählen Sie Knoten 2 aus, in unserem Fall ebshaapp02phx.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript fsdr-rsync-ebs.sh in der Oracle E-Business Suite-App node2 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan sollte gestoppt werden, wenn das Skript rsync-Jobs auf node2 nicht deaktivieren 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 300 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.2.3.1: Parameter zum Erstellen des Planschritts zum Deaktivieren von rysnc-Jobs auf Knoten 2
Es wird wie folgt angezeigt, sobald der Schritt 2 hinzugefügt wird.

Abbildung 6.2.3.2: Rysnc-Jobs auf Knoten 2 deaktivieren wird hinzugefügt

Aufgabe 6.2.4: Hinzufügen der Plangruppe und -schritte abschließen

Sowohl Oracle E-Business Suite-App stoppen als auch rsync-Jobs auf node2 deaktivieren werden der DR-Plangruppe hinzugefügt.

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

Abbildung 6.2.4.1: Schließen Sie das Hinzufügen von Plangruppen und Schritten ab, um Oracle E-Business Suite zu stoppen und den rsync-Job auf node1 zu deaktivieren
Stellen Sie sicher, dass die hinzugefügte Plangruppe im Switchover-Plan verfügbar ist.

Abbildung 6.2.4.1: Stoppen Sie Oracle E-Business Suite, und deaktivieren Sie den rsync-Job für die hinzugefügte node1-Plangruppe

Aufgabe 6.3: Plangruppe erstellen, um Oracle E-Business Suite herunterzufahren und Rsync-Jobs auf Knoten 1 in Region 1 zu deaktivieren

Fügen Sie nun die nächste benutzerdefinierte Plangruppe hinzu.

Diese benutzerdefinierte Plangruppe fährt Oracle E-Business Suite herunter und deaktiviert rsync-Jobs in node1 in Region 1. Diese Plangruppe enthält zwei Schritte, mit denen die bash-Skripte shutdownapps.sh und fsdr-rsync-ebs.sh aufgerufen werden, die in Aufgabe 2.3 auf die Serverknoten der Oracle E-Business Suite-App heruntergeladen wurden.

Aufgabe 6.3.1: Plangruppe hinzufügen

Beginnen Sie mit dem Prozess zum Hinzufügen einer Plangruppe.

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

Abbildung 6-3.1: Fügen Sie eine Plangruppe hinzu, um Oracle E-Business Suite herunterzufahren und rsync-Jobs auf node1 zu deaktivieren

Aufgabe 6.3.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Eine DR-Plangruppe kann viele Schritte enthalten, die alle parallel ausgeführt werden. Wir werden zwei Schritte hinzufügen, um bash-Skripte auszuführen, um Oracle E-Business Suite auf node1 zu stoppen und rsync-Cron-Jobs auf node1 in Region 1 zu deaktivieren. Im Beispielnamen node1 lautet ebshaapp01phx.

Geben Sie der Plangruppe einen einfachen, aber beschreibenden Namen.
Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall wird die benutzerdefinierte Plangruppe nach der Plangruppe EBS auf node2 bei PHX herunterfahren eingefügt.
Wählen Sie die benutzerdefinierte EBS auf node2 in der PHX-Plangruppe herunterfahren.
Wir werden zwei Schritte hinzufügen. Der erste Schritt besteht darin, Oracle E-Business Suite auf Knoten 1 zu stoppen, und das zweite Skript besteht darin, rsync-Jobs auf Knoten 1 zu deaktivieren.
Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Stoppen der Oracle E-Business Suite unter node2 angegeben wird.

Abbildung 6.3.2: Plangruppe zum Herunterfahren von Oracle E-Business Suite und Stoppen von rsync-Jobs

Aufgabe 6.3.3: Schrittnamen und lokale Skriptparameter angeben

Schritt 1: Stoppen Sie die Oracle E-Business Suite-App auf node1.
In Schritt 2 werden rysnc-Jobs in node1 deaktiviert.

Für dieses Setup ist Knoten 1 ebshaapp01phx

Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie als benutzerdefinierten Typ Lokales Skript ausführen aus.
Wählen Sie die Region 1, in unserem Fall ist es Phoenix.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node1 aus, und wählen Sie Knoten 1 aus, in unserem Fall ebshaapp01phx.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript shutdownapps.sh in der Oracle E-Business Suite-App node2 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan muss gestoppt werden, wenn das Skript die Oracle E-Business Suite-App auf node1 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 1800 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.3.3.1: Parameter zum Erstellen des Planschritts für das Stoppen von Oracle E-Business Suite auf Knoten 1
Es wird wie folgt angezeigt, sobald der Schritt 1 hinzugefügt wird.

Abbildung 6.3.3.2: Stoppen Sie Oracle E-Business Suite auf Schritt 1 des Knotens.
Klicken Sie auf Schritt hinzufügen, um dieser Plangruppe einen zweiten Schritt hinzuzufügen.
Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie die Region 1, in unserem Fall ist es Phoenix.
Wählen Sie Lokales Skript ausführen aus.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node1 aus, und wählen Sie Knoten 1 aus, in unserem Fall ebshaapp02phx.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript fsdr-rsync-ebs.sh in der Oracle E-Business Suite-App node2 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan sollte gestoppt werden, wenn das Skript rsync-Jobs auf node1 nicht deaktivieren 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 300 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.3.3.1: Parameter zum Erstellen des Planschritts zum Deaktivieren von rysnc-Jobs auf Knoten 1
Es wird wie folgt angezeigt, sobald der Schritt 2 hinzugefügt wird.

Abbildung 6.3.3.2: "rysnc-Jobs auf Knoten 1 deaktivieren" wird hinzugefügt

Aufgabe 6.3.4: Hinzufügen von Plangruppen und -schritten abschließen

Sowohl Oracle E-Business Suite-App stoppen als auch rsync-Jobs auf node2 deaktivieren werden der DR-Plangruppe hinzugefügt.

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

Abbildung 6.3.4.1: Schließen Sie das Hinzufügen von Plangruppen und Schritten ab, um Oracle E-Business Suite zu stoppen und den rsync-Job auf node1 zu deaktivieren
Stellen Sie sicher, dass die hinzugefügte Plangruppe im Switchover-Plan verfügbar ist.

Abbildung 6.3.4.1: Stoppen Sie Oracle E-Business Suite, und deaktivieren Sie den rsync-Job für die hinzugefügte node1-Plangruppe

Aufgabe 6.4: Plangruppe erstellen, um Knotennamen in den Tabellen der Datenbank `fnd` in Region 2 zu löschen

Fügen Sie nun die nächste benutzerdefinierte Plangruppe hinzu.

Diese benutzerdefinierte Plangruppe löscht Knotennamen in Datenbank-fnd-Tabellen in Region 2. Diese Plangruppe enthält einen Schritt, der das bash-Skript fndnodeclean.sh aufruft, das in Aufgabe 2.3 auf die Oracle E-Business Suite-Anwendungsserverknoten heruntergeladen wurde.

Aufgabe 6.4.1: Plangruppe hinzufügen auswählen

Beginnen Sie mit dem Prozess zum Hinzufügen einer Plangruppe.

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

Abbildung 6.4.1: Fügen Sie eine Plangruppe hinzu, um Oracle E-Business Suite herunterzufahren und rsync-Jobs auf node1 zu deaktivieren

Aufgabe 6.4.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Sie fügen eines hinzu, um ein bash-Skript auszuführen, um Knotennamen in Datenbank-fnd-Tabellen in node1 in Region 1 zu löschen. Im Beispielnamen node1 lautet ebshaapp01iad.

Geben Sie der Plangruppe einen einfachen, aber beschreibenden Namen.
Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall wird die benutzerdefinierte Plangruppe nach der Plangruppe Datenbanken - Switchover eingefügt.
Wählen Sie die integrierte Plangruppe Datenbanken - Switchover aus.
Um Knotennamen in Datenbank-Fnd-Tabellen zu löschen, wird ein Schritt hinzugefügt.
Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Löschen von Knotennamen in den fnd-Tabellen der Datenbank angegeben wird.

Abbildung 6.4.2: Plangruppe zum Löschen von Knotennamen in Datenbank-FND-Tabellen.

Aufgabe 6.4.3: Schrittnamen und lokale Skriptparameter angeben

In Step wird fndnodeclean auf node1 ausgeführt.

Für dieses Setup ist Knoten 1 ebshaapp01iad

Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie als benutzerdefinierten Typ Lokales Skript ausführen aus.
Wählen Sie die Region 2 aus, in unserem Fall Ashburn.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node1 aus, und wählen Sie Knoten 1 aus, in unserem Fall ebshaapp01iad.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript fndnodeclean.sh in der Oracle E-Business Suite-App node1 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan muss gestoppt werden, wenn das Skript die Oracle E-Business Suite-App auf node1 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 900 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.4.3.1: Parameter zum Erstellen des Planschritts zum Löschen von Knotennamen in Datenbank-Fnd-Tabellen
Es wird wie folgt angezeigt, sobald der Schritt 1 hinzugefügt wird.

Abbildung 6.4.3.2: Knotennamen in Datenbank-Fnd-Tabellen löschen

Aufgabe 6.4.4: Hinzufügen der Plangruppe und -schritte abschließen

Schritt zum Löschen von Knotennamen in Datenbank-FND-Tabellen wird der DR-Plangruppe hinzugefügt.

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

Abbildung 6.4.4.1: Schließen Sie das Hinzufügen von Plangruppe und Schritt ab, um Knotennamen in Datenbank-Fnd-Tabellen zu löschen
Stellen Sie sicher, dass die hinzugefügte Plangruppe im Switchover-Plan verfügbar ist.

Abbildung 6.4.4.2: So löschen Sie Knotennamen in Datenbank-Fnd-Tabellen in der hinzugefügten node1-Plangruppe

Aufgabe 6.5: Plangruppe zum Einrichten des Anwendungskontexts in der Datenbank auf node1 in Region 2 erstellen

Fügen Sie nun die nächste benutzerdefinierte Plangruppe hinzu.

Diese benutzerdefinierte Plangruppe richtet den Anwendungskontext in der Datenbank auf node1 in Region 2 ein. Diese Plangruppe enthält einen Schritt, der das bash-Skript dbtxkconfig.sh aufruft, das in Aufgabe 2.3 auf die Oracle E-Business Suite-Anwendungsserverknoten heruntergeladen wurde.

Aufgabe 6.5.1: Plangruppe hinzufügen

Beginnen Sie mit dem Prozess zum Hinzufügen einer Plangruppe.

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

Abbildung 6.5.1: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Einrichten des Anwendungskontexts in der Datenbank auf node1

Aufgabe 6.5.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Wir fügen einen Schritt hinzu, um das bash-Skript auszuführen, um den Anwendungskontext in der Datenbank auf node1 in Region 2 einzurichten. Im Beispielnamen node1 lautet ebshaapp01iad.

Geben Sie der Plangruppe einen einfachen, aber beschreibenden Namen.
Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall wird die benutzerdefinierte Plangruppe nach den Knotennamen in Datenbank-Fnd-Tabellen in der IAD-Plangruppe löschen.
Wählen Sie die integrierten Knotennamen in Datenbank-FND-Tabellen in der IAD-Plangruppe aus.
Wir fügen einen Schritt zum Einrichten des App-Kontexts in der Datenbank auf node1 hinzu.
Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Einrichten des Anwendungskontexts in der Datenbank auf node1 angegeben wird.

Abbildung 6.5.2: Plangruppe zum Einrichten des Anwendungskontexts in der Datenbank auf node1

Aufgabe 6.5.3: Schrittnamen und lokale Skriptparameter angeben

Schritt: Führen Sie dbtxkconfig auf node1 aus (ändern Sie physische Hostnamen).

Für dieses Setup ist Knoten 1 ebshaapp01iad

Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie als benutzerdefinierten Typ Lokales Skript ausführen aus.
Wählen Sie die Region 2 aus, in unserem Fall Ashburn.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node1 aus, und wählen Sie Knoten 1 aus, in unserem Fall ebshaapp01iad.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript dbtxkconfig.sh in der Oracle E-Business Suite-App node1 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3. Die Bereitstellung aller Details mit den richtigen Parametern ist äußerst wichtig.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan sollte gestoppt werden, wenn das Skript den Anwendungskontext in der Datenbank node1 nicht einrichten 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 900 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.5.3.1: Parameter zum Erstellen des Planschritts zum Einrichten des Anwendungskontexts in der Datenbank node1
Es wird wie folgt angezeigt, sobald der Schritt 1 hinzugefügt wird.

Abbildung 6.5.3.2: So richten Sie den Anwendungskontext in Datenbank node1 ein

Aufgabe 6.5.4: Hinzufügen der Plangruppe und -schritte abschließen

Der Schritt zum Einrichten des Anwendungskontexts in Datenbank node1 wird der DR-Plangruppe hinzugefügt.

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

Abbildung 6.5.4.1: Schließen Sie das Hinzufügen der Plangruppe und den Schritt zum Einrichten des Anwendungskontexts in der Datenbank ab node1
Stellen Sie sicher, dass die hinzugefügte Plangruppe im Switchover-Plan verfügbar ist.

Abbildung 6.5.4.2: So richten Sie den Anwendungskontext in der Datenbank ein: node1 Plangruppe hinzugefügt

Aufgabe 6.6: Plangruppe zum Einrichten des Anwendungskontexts in der Datenbank auf node2 in Region 2 erstellen

Fügen Sie nun die nächste benutzerdefinierte Plangruppe hinzu.

Diese benutzerdefinierte Plangruppe richtet den Anwendungskontext in der Datenbank auf node2 in Region 2 ein. Diese Plangruppe enthält einen Schritt, der das bash-Skript dbtxkconfig.sh aufruft, das in Aufgabe 2.3 auf die Oracle E-Business Suite-Anwendungsserverknoten heruntergeladen wurde.

Aufgabe 6.6.1: Plangruppe hinzufügen

Beginnen Sie mit dem Prozess zum Hinzufügen einer Plangruppe.

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

Abbildung 6.6.1: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Einrichten des Anwendungskontexts in der Datenbank auf node2

Aufgabe 6.6.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Wir fügen einen Schritt hinzu, um das bash-Skript auszuführen, um den Anwendungskontext in der Datenbank auf node2 in Region 2 einzurichten. Im Beispielnamen node2 lautet ebshaapp02iad.

Geben Sie der Plangruppe einen einfachen, aber beschreibenden Namen.
Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall wird die benutzerdefinierte Plangruppe nach dem Anwendungskontext für das Setup in der Datenbank auf node1 in der IAD-Plangruppe eingefügt.
Wählen Sie den integrierten Anwendungskontext für das Setup in der Datenbank in node1 in der IAD-Plangruppe aus.
Wir fügen einen Schritt zum Einrichten des App-Kontexts in der Datenbank auf node2 hinzu.
Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Einrichten des Anwendungskontexts in der Datenbank auf node1 angegeben wird.

Abbildung 6.6.2: Plangruppe zum Einrichten des Anwendungskontexts in der Datenbank auf node2

Aufgabe 6.6.3: Schrittnamen und lokale Skriptparameter angeben

Schritt: Führen Sie dbtxkconfig auf node2 aus (ändern Sie physische Hostnamen).

Für dieses Setup ist Knoten 2 ebshaapp02iad

Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie als benutzerdefinierten Typ Lokales Skript ausführen aus.
Wählen Sie die Region 2 aus, in unserem Fall Ashburn.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node1 aus, und wählen Sie Knoten 1 aus, in unserem Fall ebshaapp02iad.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript dbtxkconfig.sh in der Oracle E-Business Suite-App node1 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3. Die Bereitstellung aller Details mit den richtigen Parametern ist äußerst wichtig.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan sollte gestoppt werden, wenn das Skript den Anwendungskontext in der Datenbank node2 nicht einrichten 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 900 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.6.3.1: Parameter zum Erstellen des Planschritts zum Einrichten des Anwendungskontexts in der Datenbank node2
Es wird wie folgt angezeigt, sobald der Schritt 1 hinzugefügt wird.

Abbildung 6.6.3.2: So richten Sie den Anwendungskontext in Datenbank node2 ein

Aufgabe 6.6.4: Hinzufügen von Plangruppen und Schritten abschließen

Der Schritt zum Einrichten des Anwendungskontexts in Datenbank node1 wird der DR-Plangruppe hinzugefügt.

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

Abbildung 6.6.4.1: Schließen Sie das Hinzufügen der Plangruppe und den Schritt zum Einrichten des Anwendungskontexts in der Datenbank ab node2
Stellen Sie sicher, dass die hinzugefügte Plangruppe im Switchover-Plan verfügbar ist.

Abbildung 6.6.4.2: So richten Sie den Anwendungskontext in der Datenbank ein: node2 Plangruppe hinzugefügt

Aufgabe 6.7: Plangruppe erstellen, um `autoconfig` in App node1 in Region 2 auszuführen

Fügen Sie nun die nächste benutzerdefinierte Plangruppe hinzu.

Diese benutzerdefinierte Plangruppe führt autoconfig in App node1 in Region 2 aus. Diese Plangruppe enthält einen Schritt, der das bash-Skript autoconfigapps.sh aufruft, das in Aufgabe 2.3 auf die Oracle E-Business Suite-Anwendungsserverknoten heruntergeladen wurde.

Aufgabe 6.7.1: Plangruppe hinzufügen

Beginnen Sie mit dem Prozess zum Hinzufügen einer Plangruppe.

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

Abbildung 6.7.1: Beginnen Sie mit dem Hinzufügen einer Plangruppe zur automatischen Konfiguration in App node1

Aufgabe 6.7.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Um das bash-Skript auszuführen, fügen wir einen Schritt hinzu, um autoconfig in App node1 in Region 2 auszuführen. Im Beispielnamen node1 lautet ebshaapp01iad.

Geben Sie der Plangruppe einen einfachen, aber beschreibenden Namen.
Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall wird die benutzerdefinierte Plangruppe nach dem Anwendungskontext für das Setup in der Datenbank auf node2 in der IAD-Plangruppe eingefügt.
Wählen Sie den integrierten Anwendungskontext für das Setup in der Datenbank in node2 in der IAD-Plangruppe aus.
Wir fügen einen Schritt zum Einrichten des App-Kontexts in der Datenbank auf node2 hinzu.
Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zur Ausführung von autoconfig in App node1 angegeben wird.

Abbildung 6.7.2: Plangruppe zur automatischen Konfiguration in App node1

Aufgabe 6.7.3: Geben Sie Schrittnamen und lokale Skriptparameter an

In Step wird autoconfig auf node1 ausgeführt.

Für dieses Setup ist Knoten 1 ebshaapp01iad

Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie als benutzerdefinierten Typ Lokales Skript ausführen aus.
Wählen Sie die Region 2 aus, in unserem Fall Ashburn.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node1 aus, und wählen Sie Knoten 1 aus, in unserem Fall ebshaapp01iad.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript autoconfigapps.sh in der Oracle E-Business Suite-App node1 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3. Die Bereitstellung aller Details mit den richtigen Parametern ist äußerst wichtig.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan muss gestoppt werden, wenn das Skript autoconfig in App node1 nicht ausführen 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 900 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.7.3.1: Parameter zum Erstellen des Planschritts zum Ausführen der automatischen Konfiguration in App node1
Es wird wie folgt angezeigt, sobald der Schritt 1 hinzugefügt wird.

Abbildung 6.7.3.2: So führen Sie die automatische Konfiguration in App node1 aus

Aufgabe 6.7.4: Hinzufügen von Plangruppen und Schritten abschließen

Der Schritt zum Ausführen von autoconfig in App node1 wird der DR-Plangruppe hinzugefügt.

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

Abbildung 6.7.4.1: Schließen Sie das Hinzufügen einer Plangruppe und einen Schritt ab, um die automatische Konfiguration in App node1 auszuführen
Stellen Sie sicher, dass die hinzugefügte Plangruppe im Switchover-Plan verfügbar ist.

Abbildung 6.7.4.2: So führen Sie die automatische Konfiguration für die App node1-Plangruppe aus

Aufgabe 6.8: Plangruppe erstellen, um `autoconfig` in App node2 in Region 2 auszuführen

Fügen Sie nun die nächste benutzerdefinierte Plangruppe hinzu.

Diese benutzerdefinierte Plangruppe führt autoconfig in App node2 in Region 2 aus. Diese Plangruppe enthält einen Schritt, der das bash-Skript autoconfigapps.sh aufruft, das in Aufgabe 2.3 auf die Oracle E-Business Suite-Anwendungsserverknoten heruntergeladen wurde.

Aufgabe 6.8.1: Plangruppe hinzufügen

Beginnen Sie mit dem Prozess zum Hinzufügen einer Plangruppe.

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

Abbildung 6.8.1: Beginnen Sie mit dem Hinzufügen einer Plangruppe zur automatischen Konfiguration in App node2

Aufgabe 6.8.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Um das bash-Skript auszuführen, fügen wir einen Schritt hinzu, um autoconfig in App node2 in Region 2 auszuführen. Im Beispielnamen node2 lautet ebshaapp02iad.

Geben Sie der Plangruppe einen einfachen, aber beschreibenden Namen.
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 hinzufügen nach der automatischen Konfiguration über App node1 bei IAD ausführen ein.
Wählen Sie die integrierte Automatische Konfiguration in App node1 bei IAD-Plangruppe aus.
Wir fügen einen Schritt zum Einrichten des App-Kontexts in der Datenbank auf node2 hinzu.
Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zur Ausführung von autoconfig in App node2 angegeben wird.

Abbildung 6.8.2: Plangruppe zur automatischen Konfiguration in App node2

Aufgabe 6.8.3: Schrittnamen und lokale Skriptparameter angeben

In Step wird autoconfig auf node2 ausgeführt.

Für dieses Setup ist Knoten 1 ebshaapp02iad

Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie als benutzerdefinierten Typ Lokales Skript ausführen aus.
Wählen Sie die Region 2 aus, in unserem Fall Ashburn.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node2 aus, und wählen Sie Knoten 2 aus, in unserem Fall ebshaapp02iad.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript autoconfigapps.sh in der Oracle E-Business Suite-App node1 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3. Die Bereitstellung aller Details mit den richtigen Parametern ist äußerst wichtig.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan sollte gestoppt werden, wenn das Skript die automatische Konfiguration in App node2 nicht ausführen 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 900 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.8.3.1: Parameter zum Erstellen des Planschritts zum Ausführen der automatischen Konfiguration in App node2
Es wird wie folgt angezeigt, sobald der Schritt 1 hinzugefügt wird.

Abbildung 6.8.3.2: So führen Sie die automatische Konfiguration in App node2 aus

Aufgabe 6.8.4: Hinzufügen von Plangruppen und Schritten abschließen

Der Schritt zum Ausführen von autoconfig in App node2 wird der DR-Plangruppe hinzugefügt.

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

Abbildung 6.8.4.1: Schließen Sie das Hinzufügen einer Plangruppe und einen Schritt ab, um die automatische Konfiguration in App node2 auszuführen
Stellen Sie sicher, dass die hinzugefügte Plangruppe im Switchover-Plan verfügbar ist.

Abbildung 6.8.4.2: So führen Sie die automatische Konfiguration für die App node2-Plangruppe aus

Aufgabe 6.9: Plangruppe zum Starten von Oracle E-Business Suite erstellen und Rsync-Jobs auf Knoten 1 in Region 2 aktivieren

Fügen Sie nun die nächste benutzerdefinierte Plangruppe hinzu.

Diese benutzerdefinierte Plangruppe startet Oracle E-Business Suite und aktiviert rsync-Jobs in node1 in Region 2. Diese Plangruppe enthält zwei Schritte, mit denen die bash-Skripte startapps.sh und fsdr-rsync-ebs.sh aufgerufen werden, die in Aufgabe 2.3 auf die Serverknoten der Oracle E-Business Suite-App heruntergeladen wurden.

Aufgabe 6.9.1: Plangruppe hinzufügen

Beginnen Sie mit dem Prozess zum Hinzufügen einer Plangruppe.

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

Abbildung 6-9.1: Fügen Sie der Oracle E-Business Suite eine Plangruppe hinzu, und aktivieren Sie rsync-Jobs auf node1

Aufgabe 6.9.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Eine DR-Plangruppe kann viele Schritte enthalten, die alle parallel ausgeführt werden. Wir werden zwei Schritte hinzufügen, um bash-Skripte auszuführen, um Oracle E-Business Suite auf node1 zu starten und rsync-Cron-Jobs auf node1 in Region 2 zu aktivieren. Im Beispielnamen node1 lautet ebshaapp01iad.

Geben Sie der Plangruppe einen einfachen, aber beschreibenden Namen.
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 hinzufügen nach der automatischen Konfiguration über App node2 bei IAD ausführen ein.
Wählen Sie die benutzerdefinierte Plangruppe Execute autoconfig on app node2 at IAD.
Wir werden zwei Schritte hinzufügen. Der erste Schritt ist das Starten von Oracle E-Business Suite auf Knoten 1 und das zweite Skript das Aktivieren von rsync-Jobs auf Knoten 1.
Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Starten von Oracle E-Business Suite auf node2 angegeben wird.

Abbildung 6.9.2: Plangruppe zum Hochfahren von EBS und Aktivieren von rsync-Jobs auf node1

Aufgabe 6.9.3: Schrittnamen und lokale Skriptparameter angeben

In Schritt 1 wird die Oracle E-Business Suite-App auf node1 gestartet.
In Schritt 2 werden rysnc-Jobs in node1 aktiviert.

Für dieses Setup ist Knoten 1 ebshaapp01iad.

Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie als benutzerdefinierten Typ Lokales Skript ausführen aus.
Wählen Sie die Region 2, in unserem Fall ist es Ashburn.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node1 aus, und wählen Sie Knoten 1 aus, in unserem Fall ebshaapp01iad.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript startapps.sh in der Oracle E-Business Suite-App node1 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan muss gestoppt werden, wenn das Skript die Oracle E-Business Suite-App nicht auf node1 starten 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 1800 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.9.3.1: Parameter zum Erstellen des Planschritts für das Starten von Oracle E-Business Suite auf Knoten 1
Es wird wie folgt angezeigt, sobald der Schritt 1 hinzugefügt wird.

Abbildung 6.9.3.2: Schritt "Oracle E-Business Suite auf Knoten 1 starten" wird hinzugefügt
Klicken Sie auf Schritt hinzufügen, um dieser Plangruppe einen zweiten Schritt hinzuzufügen.
Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie die Region 2, in unserem Fall ist es Ashburn.
Wählen Sie Lokales Skript ausführen aus.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node1 aus, und wählen Sie Knoten 1 aus, in unserem Fall ebshaapp0iad.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript fsdr-rsync-ebs.sh in der Oracle E-Business Suite-App node1 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan sollte gestoppt werden, wenn das Skript rsync-Jobs auf node1 nicht aktiviert. 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 300 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.9.3.1: Parameter zum Erstellen des Planschritts zum Aktivieren von rysnc-Jobs auf Knoten 1
Es wird wie folgt angezeigt, sobald der Schritt 2 hinzugefügt wird.

Abbildung 6.9.3.2: Aktivieren von rysnc-Jobs auf Knoten 1 wird hinzugefügt

Aufgabe 6.9.4: Hinzufügen von Plangruppen und Schritten abschließen

Sowohl Oracle E-Business Suite-App starten als auch rsync-Jobs auf node1 aktivieren werden der DR-Plangruppe hinzugefügt.

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

Abbildung 6.9.4.1: Schließen Sie das Hinzufügen von Plangruppen und Schritten ab, um Oracle E-Business Suite zu starten und rsync-Job auf node1 zu aktivieren
Stellen Sie sicher, dass die hinzugefügte Plangruppe im Switchover-Plan verfügbar ist.

Abbildung 6.9.4.1: Starten Sie Oracle E-Business Suite, und aktivieren Sie den rsync-Job für die hinzugefügte node1-Plangruppe

Aufgabe 6.10: Plangruppe zum Starten von Oracle E-Business Suite erstellen und Rsync-Jobs auf Knoten 2 in Region 2 aktivieren

Fügen Sie nun die nächste benutzerdefinierte Plangruppe hinzu.

Diese benutzerdefinierte Plangruppe startet Oracle E-Business Suite und aktiviert rsync-Jobs in node2 in Region 2. Diese Plangruppe enthält zwei Schritte, mit denen die bash-Skripte startapps.sh und fsdr-rsync-ebs.sh aufgerufen werden, die in Aufgabe 2.3 auf die Serverknoten der Oracle E-Business Suite-App heruntergeladen wurden.

Aufgabe 6.10.1: Plangruppe hinzufügen

Beginnen Sie mit dem Prozess zum Hinzufügen einer Plangruppe.

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

Abbildung 6-10.1: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Start von Oracle E-Business Suite und aktivieren Sie rsync-Jobs auf node2

Aufgabe 6.10.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Eine DR-Plangruppe kann viele Schritte enthalten, die alle parallel ausgeführt werden. Wir werden zwei Schritte hinzufügen, um bash-Skripte auszuführen, um Oracle E-Business Suite auf node1 zu starten und rsync-Cron-Jobs auf node1 in Region 2 zu aktivieren. Im Beispielnamen node1 lautet ebshaapp02iad.

Geben Sie der Plangruppe einen einfachen, aber beschreibenden Namen.
Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall wird die benutzerdefinierte Plangruppe nach der Plangruppe EBS auf node1 bei IAD starten eingefügt.
Wählen Sie die benutzerdefinierte Plangruppe EBS in node1 bei IAD starten aus.
Wir werden zwei Schritte hinzufügen. Der erste Schritt besteht darin, Oracle E-Business Suite auf Knoten 2 zu starten, und das zweite Skript besteht darin, rsync-Jobs auf Knoten 2 zu aktivieren.
Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Starten von Oracle E-Business Suite auf node2 angegeben wird.

Abbildung 6.10.2: Plangruppe zum Starten von Oracle E-Business Suite und Aktivieren von rsync-Jobs auf node2

Aufgabe 6.10.3: Schrittnamen und lokale Skriptparameter angeben

In Schritt 1 wird die Oracle E-Business Suite-App auf node2 gestartet.
In Schritt 2 werden rysnc-Jobs in node2 aktiviert.

Für dieses Setup ist Knoten 2 ebshaapp02iad

Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie als benutzerdefinierten Typ Lokales Skript ausführen aus.
Wählen Sie die Region 2, in unserem Fall ist es Ashburn.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node1 aus, und wählen Sie Knoten 2 aus, in unserem Fall ebshaapp02iad.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript startapps.sh in der Oracle E-Business Suite-App node1 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan muss gestoppt werden, wenn das Skript die Oracle E-Business Suite-App nicht auf node2 starten 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 1800 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.10.3.1: Parameter zum Erstellen des Planschritts für das Starten von Oracle E-Business Suite auf Knoten 2
Es wird wie folgt angezeigt, sobald der Schritt 1 hinzugefügt wird.

Abbildung 6.10.3.2: Schritt "Oracle E-Business Suite auf Knoten 2 starten" wird hinzugefügt
Klicken Sie auf Schritt hinzufügen, um dieser Plangruppe einen zweiten Schritt hinzuzufügen.
Ein beschreibender Name, der erklärt, welche Aufgabe dieser Schritt ausführt.
Wählen Sie die Region 2, in unserem Fall ist es Ashburn.
Wählen Sie Lokales Skript ausführen aus.
Wählen Sie das korrekte Compartment mit der Oracle E-Business Suite-App node1 aus, und wählen Sie Knoten 2 aus, in unserem Fall ebshaapp0iad.
Fügen Sie den absoluten Pfad ein, unter dem Sie das Skript fsdr-rsync-ebs.sh in der Oracle E-Business Suite-App node1 mit den richtigen Parametern installiert haben. Die genaue Syntax finden Sie in den Readme-Details unter dem Link GitHub in Aufgabe 2.3.
Geben Sie oracle als Benutzer an, der das Skript ausführen soll.
Der DR-Plan sollte gestoppt werden, wenn das Skript rsync-Jobs auf node2 nicht aktiviert. 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.
Der Standardwert, bevor OCI Full Stack DR einen Fehler deklariert, beträgt 60 Minuten (3600 Sekunden). Dieser Wert kann in 300 Sekunden geändert werden oder was als realistischerer Timeoutwert empfunden wird.
Klicken Sie auf Schritt hinzufügen, um diesen Schritt zur Plangruppe hinzuzufügen.

Abbildung 6.10.3.1: Parameter zum Erstellen des Planschritts zum Aktivieren von rysnc-Jobs auf Knoten 2
Es wird wie folgt angezeigt, sobald der Schritt 2 hinzugefügt wird.

Abbildung 6.10.3.2: Aktivieren von rysnc-Jobs auf Knoten 2 wird hinzugefügt

Aufgabe 6.10.4: Hinzufügen von Plangruppen und -schritten abschließen

Sowohl Oracle E-Business Suite-App starten als auch rsync-Jobs auf node2 aktivieren werden der DR-Plangruppe hinzugefügt.

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

Abbildung 6.10.4.1: Schließen Sie das Hinzufügen von Plangruppen und Schritten ab, um Oracle E-Business Suite zu starten und rsync-Job auf node2 zu aktivieren
Stellen Sie sicher, dass die hinzugefügte Plangruppe im Switchover-Plan verfügbar ist.

Abbildung 6.10.4.1: Starten Sie Oracle E-Business Suite, und aktivieren Sie den rsync-Job für die hinzugefügte node2-Plangruppe

Hinweis: Damit haben wir alle erforderlichen benutzerdefinierten Plangruppen für den Switchover-Plan abgeschlossen. Stellen Sie sicher, dass Sie die Plangruppen in der richtigen Reihenfolge erhalten haben, das ist wirklich wichtig.

Sobald der Switchover-Plan angepasst wurde, sollte er wie folgt aussehen:

Abbildung 6.10.5.1: Alle Plangruppen für Switchover-Plan in Region 2

Hinweis: Sie können die Plangruppe neu anordnen, falls Sie nicht in der richtigen Reihenfolge bestellt haben.

Aufgabe 6.11: Failover-Plan auswählen

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

Abbildung 6.11: Failover-Plan in Region 2 auswählen

OCI Full Stack DR generiert die Plangruppen Prechecks-Built in und Databases-Failover. Diese wurden basierend auf den Mitgliedern generiert, die wir den DR-Schutzgruppen in Region 1 und Region 2 hinzugefügt haben.

Abbildung 6.11.1: Standardplangruppen für Failover-Plan in Region 2

Ähnlich wie wir den Switchover-Plan angepasst haben, fügen wir die erforderlichen benutzerdefinierten Plangruppen für den Failover-Plan hinzu.

Nach der integrierten Plangruppe Datenbanken-Failover müssen Sie die folgenden angegebenen benutzerdefinierten Plangruppen hinzufügen.

Löschen Sie Knotennamen in den fnd-Tabellen der Datenbank in Region 2.
Anwendungskontext in Datenbank auf node1 in Region 2 einrichten.
Anwendungskontext in Datenbank auf node2 in Region 2 einrichten.
Führen Sie autoconfig auf node1 in Region 2 aus.
Führen Sie autoconfig auf node2 in Region 2 aus.
Starten Sie Oracle E-Business Suite, und aktivieren Sie rsync-Jobs auf node1 in Region 2.
Starten Sie Oracle E-Business Suite, und aktivieren Sie rsync-Jobs auf node2 in Region 2.

Hinweis: Es werden keine weiteren Schritte zum Hinzufügen benutzerdefinierter Plangruppen ausgeführt. Ausführliche Anweisungen finden Sie unter Aufgabe 6.4 bis 6.9.

Sobald der Failover-Plan angepasst wurde, sollte er wie folgt aussehen:

Abbildung 6.11.1: Alle Plangruppen für Failover-Plan in Region 2

Hinweis:

Sie können die Plangruppen neu anordnen, falls Sie nicht in der richtigen Reihenfolge angefordert haben.

Sie können den Plan Drilldown starten auch anpassen.

Beachten Sie, dass für den Start-Drill-Plan keine integrierten Plangruppen für die Datenbank erstellt werden.

Sie müssen eine benutzerdefinierte Plangruppe erstellen, um die physische Standbydatenbank in eine Snapshot-Standbydatenbank zu konvertieren. Mit Oracle Data Guard Broker-Standardbefehlen können Sie diesen Vorgang ausführen und ein Wrapper-Skript einfügen.

Darüber hinaus können Sie anwendungsbezogene benutzerdefinierte Plangruppen hinzufügen, ähnlich wie bei einem Failover-Plan.

OCI Full Stack DR ermöglicht die Erstellung eines Stopp-Drill-Plans, sobald der Start-Drill-Plan ausgeführt wurde. Weitere Informationen finden Sie unter DR-Drillpläne. Der Plan Drilldown stoppen storniert die Vorgänge, die im Start-Drill-Plan ausgeführt wurden.

Sie können den Plan Drilldown stoppen auch anpassen.

Beachten Sie, dass für den Stopp-Drill-Plan keine integrierten Plangruppen für die Datenbank erstellt werden.

Sie müssen eine benutzerdefinierte Plangruppe erstellen, um die Snapshot-Standbydatenbank in eine physische Datenbank zu konvertieren. Mit Oracle Data Guard Broker-Standardbefehlen können Sie diesen Vorgang ausführen und ein Wrapper-Skript einfügen.

Darüber hinaus können Sie anwendungsbezogene benutzerdefinierte Plangruppen hinzufügen, um alle Oracle E-Business Suite-Anwendungen zu stoppen.

Im Rahmen dieses Tutorials wird ein **Switchover-Plan in den nachfolgenden Aufgaben ausgeführt.**

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

Sowohl Switchover- als auch Failover-DR-Pläne wurden in der Standbyregion 2 (Ashburn) erstellt. Die DR-Pläne in Region 2 ermöglichen es OCI Full Stack DR, Workloads von Region 1 in Region 2 zu übertragen. Die nächste Aufgabe besteht darin, Switchover-, Failover- und Start-Drill-Pläne in der Schutzgruppe für Region 1 (Phoenix) zu erstellen, damit OCI Full Stack DR Workloads von Region 2 zurück in Region 1 migrieren 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, d.h. in Region 1 können keine DR-Pläne erstellt werden.

Daher müssen die Rollen der Schutzgruppen umgekehrt werden, sodass Region 1 die Standby-Region und Region 2 die primäre Region ist. Führen Sie den Switchover-Plan aus, der gerade erstellt wurde, um die Workload von Region 1 (Phoenix) in Region 2 (Ashburn) zu übertragen.

Aufgabe 7.1: Planausführung beginnen

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

Stellen Sie sicher, dass der Regionskontext weiterhin auf Standbyregion 2 (Ashburn) gesetzt ist.
Verwenden Sie die Navigationspfade oben in der Konsole, um sicherzustellen, dass DR-Schutzgruppendetails der aktuelle Plankontext ist.
Stellen Sie sicher, dass die richtige DR-Schutzgruppe in Region 2 ausgewählt ist. Sie muss die Rolle Standby sein.
Stellen Sie sicher, dass sowohl Failover- als auch Switchover-Pläne vorhanden sind, bevor Sie fortfahren. Wenn nicht, kehren Sie zu den vorherigen Schritten zurück, um beide DR-Pläne zu erstellen und anzupassen.
Klicken Sie auf DR-Plan ausführen.

Abbildung 7-1: So führen Sie einen Switchover zur Standbyregion aus

Aufgabe 7.2: Switchover-Plan auswählen und ausführen

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

Wählen Sie den Switchover-Plan aus.
Wählen Sie Vorabprüfungen aktivieren aus.
Klicken Sie auf DR-Plan ausführen, um zu beginnen.

Abbildung 7-2: Switchover-Plan auswählen und ausführen

Aufgabe 7.3: DR-Planausführung überwachen

Überwachen Sie den Switchover-Plan, bis die Oracle E-Business Suite-Workload vollständig von Region 1 auf Region 2 umgestellt wurde. Nachdem der Switchover-Plan erfolgreich abgeschlossen wurde, kümmert sich OCI Full Stack DR darum, die Rollen von primären und Standby-DR-Schutzgruppen zwischen den Regionen zu ändern.

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

Prüfen Sie die erfolgreiche Ausführung des Switchover-Plans.

Abbildung 7-2: Switchover-Plan in Region 2 erfolgreich abgeschlossen
Prüfen Sie die Rollenänderung in der DR-Schutzgruppe. Region 2 (Phoenix) hat jetzt die Standbyrolle, und Region 1 (Ashburn) hat jetzt die primäre Rolle.

Abbildung 7-2: Rollenänderung der DR-Schutzgruppe nach Switchover-Plan

Aufgabe 8: DR erstellen und DR-Pläne in Region 1 anpassen (Phoenix)

Erstellen Sie die DR-Pläne in der DR-Schutzgruppe in Region 1 (Phoenix), die jetzt der Standby-Peer ist.

Der Zweck jedes Plans besteht darin, die Workload 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 automatisch im Rahmen eines DR-Vorgangs umgekehrt. Daher wird die Schutzgruppe in Region 2 zur Standby-Gruppe und die Schutzgruppe in Region 1 zur primären Gruppe nach einem Failover oder Switchover.

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

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

Führen Sie denselben Prozess wie Aufgabe 5 aus, um die DR-Pläne in Region 1 zu erstellen. Nachdem die Pläne erstellt wurden, prüfen Sie die Pläne.

ebs-pläne-in-phx.png
Abbildung 8-1: DR-Pläne in Region 1

Befolgen Sie denselben Prozess wie in Aufgabe 6, um die DR-Pläne in Region 1 anzupassen. Stellen Sie sicher, dass Sie die benutzerdefinierten Plangruppen hinzufügen. Es ist äußerst wichtig, die richtigen Oracle E-Business Suite-Anwendungs-VMs für Produktions- und DR-Regionen für die Ausführung der Skripte auszuwählen.

Fahren Sie Oracle E-Business Suite herunter, und deaktivieren Sie rsync-Jobs auf node2 in Region 2.
Fahren Sie Oracle E-Business Suite herunter, und deaktivieren Sie rsync-Jobs auf node1 in Region 2.
Löschen Sie Knotennamen in Datenbank-FND-Tabellen in Region 1.
Richten Sie den Anwendungskontext in der Datenbank auf node1 in Region 1 ein.
Richten Sie den Anwendungskontext in der Datenbank auf node2 in Region 1 ein.
Führen Sie autoconfig auf node1 in Region 1 aus.
Führen Sie autoconfig auf node2 in Region 1 aus.
Starten Sie Oracle E-Business Suite, und aktivieren Sie rsync-Jobs auf node1 in Region 1.
Starten Sie Oracle E-Business Suite, und aktivieren Sie rsync-Jobs auf node2 in Region 1.

Sobald der Switchover-Plan angepasst wurde, sollte er wie folgt aussehen:

Abbildung 8.2: Alle Plangruppen für Switchover-Plan in Region 1

Sobald der Failover-Plan angepasst wurde, sollte er wie folgt aussehen:

Abbildung 8.3: Alle Plangruppen für Failover-Plan in Region 1

Hinweis:

Sie können die Plangruppen neu anordnen, falls Sie nicht in der richtigen Reihenfolge angefordert haben.

Sie können den Plan Drilldown starten auch anpassen.

Beachten Sie, dass für den Start-Drill-Plan keine integrierten Plangruppen für die Datenbank erstellt werden.

Sie müssen eine benutzerdefinierte Plangruppe erstellen, um die physische Standbydatenbank in eine Snapshot-Standbydatenbank zu konvertieren. Mit Oracle Data Guard Broker-Standardbefehlen können Sie diesen Vorgang ausführen und ein Wrapper-Skript einfügen.

Darüber hinaus können Sie anwendungsbezogene benutzerdefinierte Plangruppen hinzufügen, ähnlich wie bei einem Failover-Plan.

OCI Full Stack DR ermöglicht die Erstellung eines Stopp-Drill-Plans, sobald der Start-Drill-Plan ausgeführt wurde. Weitere Informationen finden Sie unter DR-Drillpläne. Der Plan Drilldown stoppen storniert die Vorgänge, die im Start-Drill-Plan ausgeführt wurden.

Sie können den Plan Drilldown stoppen auch anpassen.

Beachten Sie, dass für den Stopp-Drill-Plan keine integrierten Plangruppen für die Datenbank erstellt werden.

Sie müssen eine benutzerdefinierte Plangruppe erstellen, um die Snapshot-Standbydatenbank in eine physische Datenbank zu konvertieren. Mit Oracle Data Guard Broker-Standardbefehlen können Sie diesen Vorgang ausführen und ein Wrapper-Skript einfügen.

Darüber hinaus können Sie anwendungsbezogene benutzerdefinierte Plangruppen hinzufügen, um alle Oracle E-Business Suite-Anwendungen zu stoppen.

Nächste Schritte

OCI Full Stack DR für Oracle E-Business Suite sollte an dieser Stelle vollständig implementiert sein. Die vollständige Funktionalität sollte jedoch validiert werden, bevor OCI Full Stack DR für die Produktion verwendet wird. Alle Failover- und Switchover-Pläne sollten ausgeführt werden, um zu überprüfen, ob alles wie erwartet funktioniert, und das Recovery-Team versteht den gesamten Prozess vollständig.

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 OCI Load Balancer, OCI Block Storage, OCI File Systems, Oracle Base Database Service und Oracle 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 wieder in Region 1 umzuwandeln. 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 DR-Konfiguration nach einem Failover zurücksetzen.

Alle DR-Pläne für endgültige Annahme 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 (Ashburn) sollte zu diesem Zeitpunkt im Prozess die primäre Region sein. Beginnen Sie mit der endgültigen Validierung aller Pläne, indem Sie die folgenden Schritte ausführen:

Testen Sie die Umschaltung von Bereich 2 (primär) zurück zu Bereich 1 (Standby).
Testen Sie das Failover von Region 1 (primär) zu Region 2 (Standby).
Bereiten Sie Region 1 (primär) vor für den Failover aus Region 2.
Testen Sie das Failover von Region 2 (primär) zu Region 1 (Standby).
Bereitstellen von Region 2 (primär) 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.
Je nach Anforderung können Sie DR-Drillpläne auch in einer der Regionen ausführen.

Unterstützung für diese Lösung erhalten

OCI Full Stack DR-Engineering bietet Support auf 1. Ebene für diese Lösung.

Die Lösung und jede in diesem Tutorial dargestellte benutzerdefinierte Automatisierung wurde jedoch vom Oracle Cloud EMEA-Spezialistenteam unabhängig von der Oracle E-Business Suite-Organisation oder dem OCI Full Stack DR-Engineering-Team entwickelt und implementiert.

Beziehung zwischen Oracle E-Business Suite und OCI Full Stack DR

OCI Full Stack DR ist nicht Teil des Installations- oder Deployment-Prozesses der Oracle E-Business Suite und wird in keiner Dokumentation erwähnt, die von Oracle E-Business Suite geschrieben und gepflegt wird. Die Methode für die Installation, Konfiguration und Bereitstellung von Oracle E-Business Suite für Disaster Recovery zwischen OCI-Regionen wurde entwickelt und verfasst byOracle E-Business Suite Engineering und ist völlig unabhängig von diesem Tutorial oder OCI Full Stack DR.

Die Oracle E-Business Suite-Organisation ist mit OCI Full Stack DR nicht vertraut und kann nur bei der Lösung von Problemen mit dem Oracle E-Business Suite-Prozess helfen, wie in der Dokumentation von Oracle E-Business Suite für manuell ausgeführte Disaster Recovery außerhalb von OCI Full Stack DR beschrieben.

Die Behebung von Problemen mit dem manuellen Oracle E-Business Suite-Prozess, der von der Oracle E-Business Suite dokumentiert wurde, liegt in der Verantwortung des Oracle E-Business Suite-Supports und wird unabhängig von OCI Full Stack DR durchgeführt. OCI Full Stack DR hindert Kunden oder den Oracle E-Business Suite-Support nicht daran, den dokumentierten Disaster Recovery-Prozess der Oracle E-Business Suite manuell auszuführen. Daher wird der Oracle E-Business Suite-Support Probleme mit ihrem manuellen Disaster Recovery-Prozess ohne Beteiligung von OCI Full Stack DR lösen.

Wenn Sie jedoch den von der Oracle E-Business Suite dokumentierten manuellen Wiederherstellungsprozess durchlaufen, werden die OCI Full Stack DR-Schutzgruppen wahrscheinlich in einem nicht verwendbaren Status gehalten, der zurückgesetzt werden muss, bevor der Betrieb mit OCI Full Stack DR mit Oracle E-Business Suite fortgesetzt werden kann. Der OCI Full Stack DR-Support unterstützt Kunden beim Zurücksetzen der DR-Schutzgruppen, nachdem der Oracle E-Business Suite-Support die manuelle Fehlerbehebung und Lösung abgeschlossen hat.

Support beginnt mit OCI Full Stack DR

OCI Full Stack DR-Unterstützung ist der erste Ansprechpartner für Hilfe bei Problemen mit den Schritten und Aufgaben, die in diesem Tutorial erläutert werden. Der OCI Full Stack DR-Support isoliert das Problem und bestimmt, welche Supportorganisation am besten geeignet ist, um das Problem zu lösen.

OCI Full Stack DR-Support ist verantwortlich für:
1. Kunden helfen, die Bedeutung und Ursache von Fehlermeldungen zu verstehen, die während eines DR-Vorgangs generiert wurden.
2. Unterstützung von Kunden bei der Lösung von Problemen mit IAM-Policys, die verhindern, dass Full Stack DR Ressourcen während eines DR-Vorgangs verwaltet.
3. Probleme beim Erstellen oder Verwalten von DR-Schutzgruppen.
4. Probleme bei der Erstellung, Ausführung oder Fehler des DR-Plans beim ordnungsgemäßen Aufruf der benutzerdefinierten Automatisierung, die von Oracle E-Business Suite oder dem EMEA Cloud Solutions-Team bereitgestellt wird.
5. Kunden sind für die Fehlerbehebung und Lösung von Problemen mit benutzerdefinierten Skripten verantwortlich, die vom Kunden geschrieben wurden und nicht Teil dieses Tutorials sind.
Der OCI Full Stack DR-Support öffnet einen Service Request mit Oracle E-Business Suite-Support für alle Probleme, die direkt mit der Oracle E-Business Suite selbst in Zusammenhang stehen. Kunden arbeiten direkt mit dem Oracle E-Business Suite-Support zusammen, um Probleme mit der Oracle E-Business Suite zu lösen. Oracle E-Business Suite ist verantwortlich für:
1. Alle Probleme mit der von Oracle E-Business Suite geschriebenen und gepflegten Dokumentation zu My Oracle Support (MOS).
2. Probleme mit Skripten, die Kunden von Oracle E-Business Suite zur Verfügung gestellt werden.
3. Alle Datenbankprobleme im Zusammenhang mit Oracle E-Business Suite.
4. Alle Anwendungsprobleme im Zusammenhang mit Oracle E-Business Suite.
5. Alle Probleme mit dem dokumentierten Oracle E-Business Suite-Prozess zur manuellen Wiederherstellung von Oracle E-Business Suite außerhalb von OCI Full Stack DR.
Der OCI Full Stack DR-Support öffnet eine Serviceanfrage mit dem entsprechenden internen Oracle Cloud Solutions-Team für alle Probleme, die sich direkt auf die in diesem Tutorial beschriebenen Skripte oder Prozesse beziehen. Kunden arbeiten direkt mit dem Oracle Cloud Solutions-Team zusammen, um Probleme mit diesem Tutorial zu lösen. Das Oracle Cloud Solutions-Team ist verantwortlich für:
1. Alle Probleme mit den benutzerdefinierten Skripten, die vom Cloud-Lösungsteam bereitgestellt werden.
2. Alle Probleme mit dem Gesamtprozess, wie in diesem Tutorial beschrieben.

So öffnen Sie eine Supportanfrage

Verwenden Sie die OCI-Konsole, um eine Supportanfrage mit OCI Full Stack DR-Support zu öffnen. Stellen Sie sicher, dass im Browserkontext die DR-Schutzgruppe angezeigt wird, die Sie als Teil dieses Tutorials erstellt haben, bevor Sie diesen Prozess starten.

Stellen Sie sicher, dass der Browserkontext auf die entsprechende DR-Schutzgruppe festgelegt ist.
Wählen Sie den Life Preserver in der OCI-Konsole aus.
Wählen Sie Supportanfrage erstellen aus.

Abbildung 5: Mit dem Hilfetool der OCI-Konsole können Sie eine Serviceanfrage öffnen

Abbildung 6: Supportanfragen müssen über die Schaltfläche "Hilfe anfordern" geöffnet werden

Bestätigungen

Autoren – Chandra Dharanikota (Oracle Apps to OCI Specialist, Oracle Technology Cloud Engineering, EMEA), Suraj Ramesh – (Full Stack DR, technischer Prüfer)

Weitere Lernressourcen

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

Die Produktdokumentation finden Sie im Oracle Help Center.

Titel und Copyright-Informationen

Automate Recovery for Multi-Node Oracle E-Business Suite Using OCI Full Stack Disaster Recovery

G35480-02

Recovery für Oracle E-Business Suite mit mehreren Knoten mit OCI Full Stack Disaster Recovery automatisieren

Einführung

Oracle E-Business Suite gehört in der Regel zu einem größeren System

Vorsicht bei der inkrementellen Umsetzung

Funktionsweise der Wiederherstellung

Option 1 für Hosting-Skripte

Option 2 für Hosting-Skripte

Oracle E-Business Suite – Deployment-Architektur

Referenzarchitektur für Oracle E-Business Suite mit Oracle Base Database Service

Referenzarchitektur für Oracle E-Business Suite mit Oracle Exadata Database Service on Dedicated Infrastructure

Unterschied zwischen logischen Hostnamen und physischen Hostnamen

OCI Full Stack DR-Deployment-Architektur

Option 1: Recovery für Oracle E-Business Suite mit Oracle Base Database Service automatisieren

Option 2: Recovery für Oracle E-Business Suite mit Oracle Exadata Database Service on Dedicated Infrastructure automatisieren

Definitionen und Annahmen im gesamten Tutorial

Bereiche

Compartments

Ziele

Voraussetzungen

Aufgabe 1: Oracle E-Business Suite für Disaster Recovery bereitstellen

Aufgabe 2: Mandant für OCI Full Stack DR vorbereiten

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

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

Aufgabe 2.3: Benutzerdefiniertes Oracle E-Business SuiteScripts auf Oracle E-Business Suite-Anwendungsservern herunterladen und installieren

Aufgabe 2.4: Sicherstellen, dass Oracle E-Business Suite Application Server Skripte und Befehle ausführen können

Aufgabe 2.5: OCI Vault-Secrets für die Oracle E-Business Suite-Datenbank erstellen

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

Aufgabe 2.6.1: Zu OCI Object Storage navigieren

Aufgabe 2.6.2: OCI-Objektspeicher-Bucket in Region 1 und 2 erstellen

Aufgabe 3: DR-Schutzgruppen erstellen und zuordnen

Aufgabe 3.1: Schutzgruppe in Standbyregion 2 erstellen (Ashburn)

Aufgabe 3.1.1: Zu DR-Schutzgruppen navigieren

Aufgabe 3.1.2: Schutzgruppe erstellen

Aufgabe 3.1.3: Erforderliche Parameter zum Erstellen der Schutzgruppe hinzufügen

Aufgabe 3.2: Schutzgruppe in primärer Region 1 erstellen (Phoenix)

Aufgabe 3.2.1: Schutzgruppe erstellen

Aufgabe 3.2.2: Erforderliche Parameter zum Erstellen der Schutzgruppe hinzufügen

Aufgabe 3.3: Schutzgruppen in Region 1 und Region 2 zuordnen

Aufgabe 3.3.1: Verknüpfung beginnen

Aufgabe 3.3.2: Schutzgruppen in Region 1 und Region 2 zuordnen

Aufgabe 4: Oracle E-Business Suite-Mitglieder zu DR-Schutzgruppen der Regionen 1 und 2 hinzufügen

Aufgabe 4.1: Mitgliederressourcen zu DR-Schutzgruppe zu Region 1 hinzufügen (Phoenix)

Aufgabe 4.1.1: Zur primären DR-Schutzgruppe navigieren

Aufgabe 4.1.2: Oracle E-Business Suite Application Server 1 hinzufügen

Aufgabe 4.1.3: Oracle E-Business Suite Application Server 2 hinzufügen

Aufgabe 4.1.4: Primäre geclusterte Oracle Database hinzufügen

Aufgabe 4.2: Mitgliederressourcen zu DRPG in Region 2 hinzufügen (Ashburn)

Aufgabe 4.2.1: Zu Standby-DR-Schutzgruppe navigieren

Aufgabe 4.2.2: Oracle E-Business Suite Application Server 1 hinzufügen

Aufgabe 4.2.3: Oracle E-Business Suite Application Server 2 hinzufügen

Aufgabe 4.2.4: Geclusterte Oracle Standby-Datenbank hinzufügen

Aufgabe 5: DR-Pläne in Teilsektor 2 erstellen

Aufgabe 5.1: DR-Plan für Switchover zu Region 2 erstellen

Aufgabe 5.2: DR-Plan für Failover zu Region 2 erstellen

Aufgabe 5.3: DR-Plan für Start-Drilldown in Region 2 erstellen

Aufgabe 6: DR-Pläne in Region 2 anpassen (Ashburn)

Aufgabe 6.1: Switchover-Plan auswählen

Aufgabe 6.2: Plangruppe erstellen, um Oracle E-Business Suite herunterzufahren und Rsync-Jobs auf Knoten 2 in Region 1 zu deaktivieren

Aufgabe 6.2.1: Plangruppe hinzufügen

Aufgabe 6.2.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Aufgabe 6.2.3: Schrittnamen und lokale Skriptparameter angeben

Aufgabe 6.2.4: Hinzufügen der Plangruppe und -schritte abschließen

Aufgabe 6.3: Plangruppe erstellen, um Oracle E-Business Suite herunterzufahren und Rsync-Jobs auf Knoten 1 in Region 1 zu deaktivieren

Aufgabe 6.3.1: Plangruppe hinzufügen

Aufgabe 6.3.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Aufgabe 6.3.3: Schrittnamen und lokale Skriptparameter angeben

Aufgabe 6.3.4: Hinzufügen von Plangruppen und -schritten abschließen

Aufgabe 6.4: Plangruppe erstellen, um Knotennamen in den Tabellen der Datenbank fnd in Region 2 zu löschen

Aufgabe 6.4.1: Plangruppe hinzufügen auswählen

Aufgabe 6.4.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Aufgabe 6.4.3: Schrittnamen und lokale Skriptparameter angeben

Aufgabe 6.4.4: Hinzufügen der Plangruppe und -schritte abschließen

Aufgabe 6.5: Plangruppe zum Einrichten des Anwendungskontexts in der Datenbank auf node1 in Region 2 erstellen

Aufgabe 6.5.1: Plangruppe hinzufügen

Aufgabe 6.5.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Aufgabe 6.5.3: Schrittnamen und lokale Skriptparameter angeben

Aufgabe 6.5.4: Hinzufügen der Plangruppe und -schritte abschließen

Aufgabe 6.6: Plangruppe zum Einrichten des Anwendungskontexts in der Datenbank auf node2 in Region 2 erstellen

Aufgabe 6.6.1: Plangruppe hinzufügen

Aufgabe 6.6.2: Plangruppenname angeben, Anfordern und Schritt hinzufügen

Aufgabe 6.4: Plangruppe erstellen, um Knotennamen in den Tabellen der Datenbank `fnd` in Region 2 zu löschen

Aufgabe 6.7: Plangruppe erstellen, um `autoconfig` in App node1 in Region 2 auszuführen

Aufgabe 6.8: Plangruppe erstellen, um `autoconfig` in App node2 in Region 2 auszuführen