Hinweis:

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

Automatisieren Sie das Recovery für Oracle Integration mit OCI Full Stack Disaster Recovery

Teil 1: Einführung

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

Oracle Integration ist eine sichere, einheitliche Plattform, mit der Sie Cloud- und On-Premises-Anwendungen verbinden, Geschäftsprozesse automatisieren, durch Geschäftskennzahlenanalysen Einblicke in Ihr Unternehmen gewinnen und Web- und Mobilanwendungen entwickeln können. Oracle Integration ist in einer OCI-Region verfügbar, die durch Service Level Agreements (SLAs) geregelt ist. Dieses Tutorial beschreibt das Verfahren zum Erstellen einer regionsübergreifenden, vom Kunden verwalteten Disaster Recovery-Lösung für Oracle Integration, insbesondere für das Integrationsfeature in Oracle Integration.

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

OCI Full Stack Disaster Recovery (DR) wird nicht zum Provisioning oder Konfigurieren von Oracle Integration verwendet. Oracle Integration muss regionsübergreifend für DR bereitgestellt und konfiguriert werden. Befolgen Sie dazu die Schritt-für-Schritt-Anweisungen unter Disaster-Recovery-Lösung für Oracle Integration der 2. Generation konfigurieren, bevor Sie OCI Full Stack DR in irgendeiner Weise verwenden.

Die manuellen Failover-Schritte, die vom Oracle Integration-Engineering in dieser Dokumentation vorgeschrieben sind: Disaster-Recovery-Lösung für Oracle Integration der 2. Generation konfigurieren, müssen auch erfolgreich auf Switchover und Switchback getestet werden, bevor OCI Full Stack DR verwendet wird.

Oracle Integration ist normalerweise Teil eines größeren Systems

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

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

Hinweis: Die Schritte in diesem Tutorial wurden mit Oracle Integration der 2. Generation getestet. Dieses Tutorial zeigt nur, wie Sie DR für die Anwendungsintegrationsfunktion von Oracle Integration der 2. Generation implementieren, da wir den Leser nicht durch die Einführung zu vieler beweglicher Teile und Teile überfordern möchten.

Vorsicht bei der schrittweisen Implementierung

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

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

Funktionsweise der Wiederherstellung

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

Die folgenden Skripte dienen allgemeinen Anleitungen. Sie können entweder eigene Skripte verwenden oder die Skripte entsprechend Ihren Unternehmensrichtlinien und Sicherheitsanforderungen anpassen. Sie müssen die OCI-CLI installieren und Ihre Zugangsdaten für die Verwendung der Skripte konfigurieren.

Um sicherzustellen, dass die primäre Instanz mit den neuesten geplanten Parametern aktualisiert wird, stellen Sie außerdem sicher, dass die Datei integrations.json mit allen Integrationsnamen zusammen mit den Versionsdetails sowie der Datei integration_parameters.json aktualisiert wird, die mit den neuesten geplanten Parameterwerten für alle geplanten Integrationen aktualisiert werden muss. Dazu können Sie den bevorzugten CI/CD-Prozess verwenden.

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

Option 1 für Hosting-Skripte

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

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

Option 2 für Hosting-Skripte

Wenn dies ein ungewöhnlicher Fall ist, bei dem Oracle Integration der einzige Anwendungsservice ist, den OCI Full Stack DR während eines Recovery-Vorgangs verwalten wird, muss eine Compute-Instanz nur erstellt werden, um die Skripte zu hosten.

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, da Oracle Integration nicht nativ von OCI Full Stack DR verwaltet werden kann. Der spezialisierte Management-Server wird in diesem Dokument als Kontrollknoten oder DR-Knoten angezeigt. Der gesamte Zweck des Kontrollknotens besteht darin, einfach als Server zu fungieren, auf dem benutzerdefinierte Skripte gespeichert und von OCI Full Stack DR während eines Recovery-Vorgangs aufgerufen werden können. In diesem Tutorial wird erläutert, wie Sie benutzerdefinierte, benutzerdefinierte DR-Plangruppen und -schritte im Rahmen Ihrer DR-Pläne zum Aufrufen der auf dem Kontrollknoten installierten Skripte erstellen.

Oracle Integration - Deployment-Architektur

Wie in der Abbildung dargestellt, umfasst die Oracle Integration-DR-Architektur der 2. Generation zwei Oracle Integration-Instanzen, die sich als primäre und sekundäre Instanzen unterscheiden und gleichzeitig ausgeführt werden. Traffic wird jedoch jeweils nur an eine Instanz weitergeleitet. Zunächst fließt Traffic zur primären Instanz. Wenn die primäre Instanz nicht verfügbar ist, wird der DNS-Datensatz so angepasst, dass Traffic an die sekundäre Instanz umgeleitet wird.

Abbildung 1: DR-Referenzarchitektur von Oracle Integration

Nachdem die Instanzen bereitgestellt wurden, exportieren Sie die Metadaten von der primären Instanz in die Standbyinstanz. Dazu können Sie entweder REST-APIs verwenden oder die Oracle Integration-UI zum Exportieren und Importieren der Metadaten verwenden. Nachdem diese anfängliche einmalige Migration der Metadaten abgeschlossen ist, müssen Sie die Metadaten mit CICD zwischen den Instanzen synchronisieren. Sie können Jenkins oder ein ähnliches Tool verwenden, um CICD für Ihre Instanzen zu implementieren und die Metadaten zu synchronisieren. Sie können auch eine OCI Compute-Instanz als Jenkins CI-Server und CD-Hub verwenden.

Oracle Integration muss zuerst für Disaster Recovery (DR) in OCI-Regionen bereitgestellt und konfiguriert werden, bevor OCI Full Stack DR eingeführt wird. It is extremely important that the manual steps to switchover Oracle Integration as documented by Oracle Integration engineering are tested and work correctly before attempting to automate the switchover/failover process using OCI Full Stack DR.

Den gesamten Prozess kennen lernen

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

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

Teil 2: Schritt für Schritt

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

Ziele

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

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

Definitionen und Annahmen im gesamten Tutorial

Bereiche

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

Compartments

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

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

Oracle Integration DR-Kontrollknoten

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

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

Voraussetzungen

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

Aufgabe 1: Oracle Integration für Disaster Recovery bereitstellen

OCI Full Stack DR ist an diesem Schritt nicht beteiligt.

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

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

Option 1: Oracle Integration als Standalone-Anwendung

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

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

Option 2: Oracle Integration als Teil eines Anwendungsstacks

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

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

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

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

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

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

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

Aufgabe 1.3: bash-Skripte auf DR-Kontrollknoten herunterladen

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

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

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

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

Aufgabe 1.4: Oracle Integration für DR bereitstellen

Bereitstellen von Oracle Integration für DR über OCI-Regionen hinweg mit den Schritt-für-Schritt-Anweisungen des Oracle Integration Engineering-Teams.

Aufgabe 1.5: Recovery von Oracle Integration manuell testen

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

Aufgabe 1.6: Nächste Schritte

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

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

Aufgabe 2: OCI Full Stack DR vorbereiten

OCI Full Stack DR ist an diesem Schritt nicht beteiligt. Die folgenden Schritte bereiten den Mandanten, das Compartment, OCI-Services und Oracle Integration für die automatisierte Wiederherstellung durch OCI Full Stack DR vor.

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

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

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

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

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

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

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

Hinweis: Überspringen Sie Aufgabe 2.3 vollständig, wenn Sie Oracle Integration 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 bei Recovery-Vorgängen generiert wurden: Object Storage.

Aufgabe 2.3.1: Zu OCI Object Storage navigieren

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

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

Abbildung 2-1: Navigieren Sie zum Objektspeicher

Aufgabe 2.3.2: OCI-Speicher-Bucket in Region 1

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

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

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

Aufgabe 2.3.3: OCI-Speicher-Bucket in Region 2

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

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

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

Aufgabe 3: DR-Schutzgruppen in beiden Regionen erstellen

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

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

Aufgabe 3.1: Zu DR-Schutzgruppen navigieren

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

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

Abbildung 3-1: Zu DR-Schutzgruppen navigieren

Aufgabe 3.2: Schutzgruppe in Region 1 erstellen

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

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

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

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

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

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

Aufgabe 3.3: Schutzgruppe in Region 2 erstellen

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

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

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

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

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

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

Aufgabe 3.4: Schutzgruppen in Region 1 und Region 2 zuordnen

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

Aufgabe 3.4.1: Beginn der Zuordnung

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

Abbildung 3-6: DRPG-Verknüpfung beginnen

Aufgabe 3.4.2: Schutzgruppen in Region 1 und Region 2 zuordnen

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

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

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

Aufgabe 3.4.3: Was Sie nach Abschluss der Zuordnung sehen sollten

OCI Full Stack DR zeigt nach Abschluss der Verknüpfung etwas wie Abbildung 3-8 unten.

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

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

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

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

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

Aufgabe 4: Mitglieder zur DR-Schutzgruppe hinzufügen

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

Fügen Sie den DR-Kontrollknoten als Mitglieder zur primären DR-Schutzgruppe hinzu. Der DR-Kontrollknoten ist entweder eine Compute-Instanz, die Sie nur zur Kontrolle von Oracle Integration erstellt haben, oder eine Compute-Instanz, die Teil des Anwendungsstacks ist, den Sie mit OCI Full Stack DR verwalten möchten.

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

1. Der DR-Kontrollknoten,
2. Die Volume-Gruppe mit dem Boot-Volume des DR-Kontrollknotens.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Die verschiebbare Compute-Instanz und die Block-Volume-Gruppe für die Compute-Instanz, die als OIC-DR-Kontrollknoten angegeben wurde.

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

In der Standby-DR-Schutzgruppe müssen keine Mitglieder hinzugefügt werden, da die Compute-Instanz als DR-Knoten verschoben wird, um die Oracle Integration-Skripte zu hosten

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

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

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

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 während eines Recovery-Vorgangs zu bearbeiten.

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

Aufgabe 5.1: DR-Pläne erstellen

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

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

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

Aufgabe 5.1.1: Switchover-Plan erstellen

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

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

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

Aufgabe 5.1.2: Failover-Plan erstellen

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

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

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

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

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

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

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

1. Geplante Parameter aus Region 1 mit Region 2 synchronisieren
2. Relevante Integrationen in Region 2 aktivieren
3. Geplante Integrationen in Region 2 starten
4. DNS-Datensatz in Region 2 aktualisieren
5. Geplante Integrationen in Region 1 deaktivieren

Aufgabe 6.1: Switchover-Plan auswählen

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

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

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

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

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

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

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

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

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

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

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

Aufgabe 6.2.1: Beenden der Compute-Plangruppe aktivieren

Aktivieren Sie die Plangruppe.

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

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

Aufgabe 6.2.2 "Volume-Gruppen beenden" aktivieren - Plangruppe

Aktivieren Sie die Plangruppe.

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

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

Aufgabe 6.3: Plangruppe erstellen, um geplante Parameter aus Region 1 mit Region 2 zu synchronisieren

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

Die erste benutzerdefinierte Plangruppe synchronisiert geplante Parameter von Region 1 mit Region. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oic-sync-schedule-parameters.sh aufruft, das in Aufgabe 1.4 auf den DR-Kontrollknoten heruntergeladen wurde.

Aufgabe 6.3.1: Plangruppe hinzufügen auswählen

Beginnen Sie den Prozess zum Hinzufügen einer Plangruppe.

1. Klicken Sie zum Starten auf Gruppe hinzufügen.

Abbildung 6-5: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Synchronisieren geplanter Parameter.

Aufgabe 6.3.2: Geben Sie den Namen der Plangruppe an, ordnen Sie sie an, und fügen Sie den Schritt hinzu

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

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall fügen wir die benutzerdefinierte Plangruppe ein, bevor die integrierte Plangruppe, mit der die VMs in Region 1 gestoppt werden.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen stoppen (primär) aus.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Synchronisieren von geplanten Parametern angeben.

Abbildung 6-6: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Synchronisieren geplanter Parameter

Aufgabe 6.3.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall werden geplante Parameter von Region 1 mit Region 2 synchronisiert.

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

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

Abbildung 6-7: Parameter zum Erstellen des Planschritts für die Synchronisierung geplanter Parameter

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

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

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

Abbildung 6-8: Hinzufügen von Plangruppe und Schritt zur Synchronisierung geplanter Parameter abschließen

Aufgabe 6.4: Plangruppe erstellen, um relevante Integrationen im Standby-Modus zu aktivieren

Die zweite benutzerdefinierte Plangruppe aktiviert relevante Integrationen im Standby, nachdem der DR-Kontrollknoten in der Standbyregion 2 gestartet wurde. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oic-integration-switch.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

Aufgabe 6.4.1: Plangruppe hinzufügen auswählen

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

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

Aufgabe 6.4.2: Geben Sie den Namen der Plangruppe an, ordnen Sie sie an, und fügen Sie den Schritt hinzu

Erstellen Sie eine DR-Plangruppe, um relevante Integrationen in der Standbydatenbank zu aktivieren.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall werden wir unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe einfügen, die die replizierte Version des DR-Kontrollknotens in Region 2 startet.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen starten (Standby) aus
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript angeben, um relevante Integrationen in der Standbydatenbank zu aktivieren.

Abbildung 6-10: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Aktivieren relevanter Integrationen in der Standbydatenbank

Aufgabe 6.4.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

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

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

1. Ein aussagekräftiger Name, der erläutert, welche Aufgabe dieser Schritt ausführt.
2. Fügen Sie den absoluten Pfad ein, in dem Sie das Skript oic-integration-switch.sh auf dem DR-Kontrollknoten installiert haben. Fügen Sie activate als ersten Parameter und PHX hinzu, da second.This die Zielregion ist, in der relevante Integrationen aktiviert werden sollen. Möglicherweise müssen Sie korrekte Regionsparameter angeben, wenn Sie verschiedene OCI-Regionen und Aktualisierungsskripte verwenden.
3. Klicken Sie auf Schritt hinzufügen, um diesen Schritt der Plangruppe hinzuzufügen.

Abbildung 6-11: Parameter zum Erstellen des Planschritts zum Aktivieren relevanter Integrationen in der Standbydatenbank

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

Der Schritt zum Aktivieren relevanter Integrationen im Standby wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 6-12 unten dargestellt.

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

Abbildung 6-12: Schließen Sie das Hinzufügen von Plangruppe und Schritt ab, um relevante Integrationen in der Standbydatenbank zu aktivieren

Aufgabe 6.5: Plangruppe erstellen, um geplante Integrationen in Region 2 zu starten

Die dritte benutzerdefinierte Plangruppe startet geplante Integrationen im Standby, nachdem der DR-Kontrollknoten in der Standbyregion 2 gestartet wurde. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oic-integration-schedule.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

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

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

Abbildung 6-13: Beginnen Sie mit dem Hinzufügen einer Plangruppe, um geplante Integrationen in der Standbydatenbank zu starten.

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

Erstellen Sie eine DR-Plangruppe, um geplante Integrationen in der Standbyregion 2 zu starten.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. Fügen Sie in diesem Fall die benutzerdefinierte Plangruppe nach der in der vorherigen Aufgabe erstellten benutzerdefinierten Plangruppe ein, um relevante Integrationen zu aktivieren.
3. Wählen Sie die integrierte Plangruppe Relevante Integrationen in Standby aktivieren aus
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Starten von geplanten Integrationen in der Standbydatenbank angeben.

Abbildung 6-14: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Starten geplanter Integrationen in der Standbydatenbank

Aufgabe 6.5.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

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

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

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

Abbildung 6-15: Parameter zum Erstellen des Planschritts zum Starten geplanter Integrationen in der Standbydatenbank

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

Der Schritt zum Starten von geplanten Integrationen in der Standby-Datenbank wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 6-16 unten dargestellt.

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

Abbildung 6-16: Schließen Sie das Hinzufügen einer Plangruppe ab, und starten Sie geplante Integrationen in der Standbydatenbank

Aufgabe 6.6: Plangruppe zum Aktualisieren des DNS-Datensatzes in Region 2 erstellen

Die vierte benutzerdefinierte Plangruppe aktualisiert den DNS-Datensatz im Standby-Modus, nachdem der DR-Kontrollknoten in der Standbyregion 2 gestartet wurde. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript dns_record_update.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

Aufgabe 6.6.1: Plangruppe hinzufügen auswählen

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

Abbildung 6-17: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Aktualisieren des DNS-Datensatzes in der Standbydatenbank

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

Erstellen Sie eine DR-Plangruppe, um den DNS-Datensatz in Region 2 zu aktualisieren.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall werden wir unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe einfügen, um geplante Integrationen in der Standbydatenbank zu starten
3. Wählen Sie die integrierte Plangruppe Geplante Integrationen in Standby starten aus.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Aktualisieren des DNS-Datensatzes in der Standbydatenbank angeben.

Abbildung 6-18: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Aktualisieren des DNS-Datensatzes in der Standbydatenbank

Aufgabe 6.6.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird der DNS-Datensatz im Standby-Modus aktualisiert.

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

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

Abbildung 6-19: Parameter zum Erstellen des Planschritts zum Aktualisieren des DNS-Datensatzes in der Standbydatenbank

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

Der Schritt zum Aktualisieren des DNS-Datensatzes im Standby-Modus wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 6-20 unten dargestellt.

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

Abbildung 6-20: Hinzufügen von Plangruppe und Schritt zum Aktualisieren des DNS-Datensatzes in der Standbydatenbank abschließen

Aufgabe 6.7: Plangruppe erstellen, um geplante Integrationen in Region 1 zu deaktivieren

Die endgültige benutzerdefinierte Plangruppe deaktiviert geplante Integrationen in Region 1, nachdem der DR-Kontrollknoten in der Standbyregion 2 gestartet wurde. Diese Plangruppe enthält einen einzelnen Schritt, der das Skript oic-integration-switch.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

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

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

Abbildung 6-21: Beginnen Sie mit dem Hinzufügen einer Plangruppe, um geplante Integrationen in Region 1 zu deaktivieren.

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

DR-Plangruppe erstellen, um geplante Integrationen in Region 1 zu deaktivieren

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall werden wir unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe einfügen, um den DNS-Datensatz in der Standbydatenbank zu aktualisieren
3. Wählen Sie die integrierte Plangruppe DNS-Datensatz in Standby aktualisieren aus.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zum Deaktivieren geplanter Integrationen in Region 1 angegeben wird

Abbildung 6-22: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Deaktivieren geplanter Integrationen in Region 1

Aufgabe 6.7.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

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

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

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

Abbildung 6-23: Parameter zum Erstellen des Planschritts zum Deaktivieren geplanter Integrationen in Region 1

Aufgabe 6.7.4: Hinzufügen von Plangruppe und -schritt abschließen

Der Schritt zum Deaktivieren geplanter Integrationen in Region 1 wird jetzt der DR-Plangruppe hinzugefügt, wie in Abbildung 6-20 unten dargestellt.

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

Abbildung 6-24: Schließen Sie das Hinzufügen einer Plangruppe und eines Schritts ab, um geplante Integrationen in Region 1 zu deaktivieren.

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

Abbildung 6-25: Fünf benutzerdefinierte Plangruppen anzeigen, die dem Switchover-Plan hinzugefügt wurden

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

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

1. Relevante Integrationen in Region 2 aktivieren
2. Geplante Parameter in Region 2 aktualisieren
3. Geplante Integrationen in Region 2 starten
4. DNS-Datensatz in Region 2 aktualisieren

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

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

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

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

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

Die erste benutzerdefinierte Plangruppe aktiviert relevante Integrationen in Region 2. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oic-integration-switch.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

1. Klicken Sie zum Starten auf Gruppe hinzufügen.

Abbildung 7-2: Beginnen Sie mit dem Hinzufügen einer Plangruppe, um relevante Integrationen zu aktivieren.

Aufgabe 7.2.1: Geben Sie den Namen der Plangruppe an, ordnen Sie sie an, und fügen Sie den Schritt hinzu

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

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall fügen wir die benutzerdefinierte Plangruppe nach der integrierten Plangruppe ein, mit der die replizierten VMs in Region 2 gestartet werden.
3. Wählen Sie die integrierte Plangruppe Compute-Instanzen starten (Standby) aus
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem das Skript zur Aktivierung der relevanten Integrationen angegeben wird

Abbildung 7-3: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Aktivieren relevanter Integrationen in der Standbydatenbank

Aufgabe 7.2.2: Geben Sie den Schrittnamen und lokale Skriptparameter an

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

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

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

Abbildung 7-4: Parameter zum Erstellen des Planschritts zum Aktivieren relevanter Integrationen in der Standbydatenbank

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

Der Schritt zum Aktivieren relevanter Integrationen wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 7-5 unten dargestellt.

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

Abbildung 7-5: Schließen Sie das Hinzufügen von Plangruppe und -schritt ab, um relevante Integrationen zu aktivieren

Aufgabe 7.3: Plangruppe erstellen, um geplante Parameter in Region 2 zu aktualisieren

Die zweite benutzerdefinierte Plangruppe aktualisiert geplante Parameter in der Standbyregion 2. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oic-update-parameters.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

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

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

Abbildung 7-6: Beginnen Sie mit dem Hinzufügen einer Plangruppe, um geplante Parameter in der Standbydatenbank zu aktualisieren

Aufgabe 7.3.2: Geben Sie den Namen der Plangruppe an, ordnen Sie sie an, und fügen Sie den Schritt hinzu

Erstellen Sie eine DR-Plangruppe, um geplante Parameter in Region 2 zu aktualisieren.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. Fügen Sie in diesem Fall die benutzerdefinierte Plangruppe nach der in der vorherigen Aufgabe erstellten benutzerdefinierten Plangruppe ein, um relevante Integrationen zu aktivieren.
3. Wählen Sie die Plangruppe Relevante Integrationen in Standby aktivieren aus.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript angeben, um geplante Parameter in der Standbydatenbank zu aktualisieren.

Abbildung 7-7: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Aktualisieren geplanter Parameter in der Standbydatenbank

Aufgabe 7.3.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

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

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

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

Abbildung 7-8: Parameter zum Erstellen des Planschritts zum Aktualisieren geplanter Parameter in der Standbydatenbank

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

Der Schritt zum Aktualisieren geplanter Parameter in der Standby-Datenbank wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 7-9 unten dargestellt.

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

Abbildung 7-9: Beenden Sie das Hinzufügen geplanter Parameter für die Plangruppe und die Schrittaktualisierung in der Standbydatenbank

Aufgabe 7.4: Plangruppe erstellen, um geplante Integrationen in Region 2 zu starten

Die dritte benutzerdefinierte Plangruppe startet geplante Integrationen im Standby, nachdem der DR-Kontrollknoten in der Standbyregion 2 gestartet wurde. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript oic-integration-schedule.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

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

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

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

Aufgabe 7.4.2: Geben Sie den Namen der Plangruppe an, ordnen Sie sie an, und fügen Sie den Schritt hinzu

DR-Plangruppe erstellen, um geplante Integrationen in der Standbydatenbank zu starten

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall fügen wir unsere benutzerdefinierte Plangruppe nach den geplanten Aktualisierungsparametern in Standbyplangruppen ein.
3. Wählen Sie die integrierte Plangruppe Geplante Parameter in Standby aktualisieren aus.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Starten geplanter Integrationen in der Standbydatenbank angeben.

Abbildung 7-11: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Starten geplanter Integrationen in der Standbydatenbank

Aufgabe 7.4.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält.

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

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

Abbildung 7-12: Parameter zum Erstellen des Planschritts zum Starten geplanter Integrationen in der Standbydatenbank

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

Der Schritt zum Starten von geplanten Integrationen in der Standby-Datenbank wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 7-13 unten dargestellt.

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

Abbildung 7-13: Schließen Sie das Hinzufügen einer Plangruppe und eines Schritts ab, um geplante Integrationen in der Standbydatenbank zu starten

Aufgabe 7.5: Plangruppe zum Aktualisieren des DNS-Datensatzes in Region 2 erstellen

Die vierte benutzerdefinierte Plangruppe aktualisiert den DNS-Datensatz im Standby-Modus, nachdem der DR-Kontrollknoten in der Standbyregion 2 gestartet wurde. Diese Plangruppe enthält einen einzelnen Schritt, der das bash-Skript dns_record_update.sh aufruft, das in Aufgabe 1.3 auf den DR-Kontrollknoten heruntergeladen wurde.

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

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

Abbildung 7-14: Beginnen Sie mit dem Hinzufügen einer Plangruppe zum Aktualisieren des DNS-Datensatzes in der Standbydatenbank

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

Erstellen Sie eine DR-Plangruppe, um den DNS-Datensatz in Region 2 zu aktualisieren.

1. Geben Sie der Plangruppe einen einfachen, aber aussagekräftigen Namen.
2. Wählen Sie eine Position aus, an der die Plangruppe in den DR-Plan eingefügt wird. In diesem Fall werden wir unsere benutzerdefinierte Plangruppe nach der integrierten Plangruppe einfügen, um geplante Integrationen in der Standbydatenbank zu starten
3. Wählen Sie die integrierte Plangruppe Geplante Integrationen in Standby starten aus.
4. Klicken Sie auf Schritt hinzufügen, um das Dialogfeld zu öffnen, in dem Sie das Skript zum Aktualisieren des DNS-Datensatzes in der Standbydatenbank angeben.

Abbildung 7-14: Parameter zum Erstellen einer Plangruppe und zum Hinzufügen eines Schritts zum Aktualisieren des DNS-Datensatzes in der Standbydatenbank

Aufgabe 7.5.3: Geben Sie den Schrittnamen und lokale Skriptparameter an

Im Dialogfeld Plangruppenschritt hinzufügen können Sie Parameter darüber angeben, was dieser eine Schritt ausführt und wie er sich während des Recoverys verhält. In diesem Fall wird der DNS-Datensatz im Standby-Modus aktualisiert.

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

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

Abbildung 7-15: Parameter zum Erstellen des Planschritts zum Aktualisieren des DNS-Datensatzes in der Standbydatenbank

Aufgabe 7.5.4: Hinzufügen von Plangruppe und -schritt abschließen

Der Schritt zum Aktualisieren des DNS-Datensatzes im Standby-Modus wird nun der DR-Plangruppe hinzugefügt, wie in Abbildung 7-16 unten dargestellt.

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

Abbildung 7-16: Hinzufügen von Plangruppe und Schritt zum Aktualisieren des DNS-Datensatzes in der Standbydatenbank abschließen

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

Abbildung 7-14: Vier benutzerdefinierte Plangruppen anzeigen, die dem Failover-Plan hinzugefügt wurden

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

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

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

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

Aufgabe 8.1: Planausführung beginnen

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

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

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

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

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

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

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

Aufgabe 8.3: Nächste Schritte

Überwachen Sie den Switchover-Plan, bis die Oracle Integration-Workload vollständig von Region 1 in Region 2 übertragen wurde. OCI Full Stack DR kümmert sich um die Bereinigung von Artefakten und die Änderung der Rollen der Primär- und Standbydatenbank zwischen den Regionen.

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

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

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

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

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 während eines Recovery-Vorgangs zu bearbeiten.

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

Aufgabe 9.1: DR-Pläne erstellen

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

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

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

Aufgabe 9.1.1: Switchover-Plan erstellen

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

1. Machen Sie den Namen des Switchover-Plans einfach, aber aussagekräftig. Der Name sollte so kurz wie möglich, aber auf einen Blick leicht zu verstehen sein, um Verwirrung und menschliches Versagen während einer Krise zu reduzieren.

2. Wählen Sie den Plantyp aus. Zum Zeitpunkt dieses Schreibens gibt es nur zwei Plantypen.

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

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

Aufgabe 9.2: Failover-Plan erstellen

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

1. Machen Sie den Namen des Failover-Plans einfach, aber aussagekräftig. Der Name sollte so kurz wie möglich, aber auf einen Blick leicht zu verstehen sein, um Verwirrung und menschliches Versagen während einer Krise zu reduzieren.

2. Wählen Sie den Plantyp aus. Zum Zeitpunkt dieses Schreibens gibt es nur zwei Plantypen.

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

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

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

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

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

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

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

1. Synchronisieren Sie geplante Parameter aus Region 1 mit Region 2.
2. Aktivieren Sie relevante Integrationen in Region 2.
3. Geplante Integrationen in Region 2 starten.
4. Aktualisieren Sie den DNS-Datensatz in Region 2.
5. Deaktivieren Sie geplante Integrationen in Region 1.

Aufgabe 10.1: Switchover-Plan auswählen

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

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

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

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

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

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

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

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

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

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

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

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

Aufgabe 10.2.1: Beenden der Compute-Plangruppe aktivieren

Aktivieren Sie die Plangruppe.

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

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

Aufgabe 10.2.2 "Volume-Gruppen beenden" aktivieren - Plangruppe

Aktivieren Sie die Plangruppe.

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

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

Aufgabe 10.3: Verschiedene benutzerdefinierte Pläne für den Switchover-Plan erstellen

Wir haben bereits gezeigt, wie Sie den verschiedenen benutzerdefinierten Plan für den Switchover-Plan von Aufgabe 6.3 auf 6.7 erstellen. Erstellen Sie mit dem ähnlichen Prozess fünf benutzerdefinierte Plangruppen. Sie müssen die Compute-Instanz verwenden, die in der Region Phoenix ausgeführt wird, um Skripte auszuführen.

1. Synchronisieren Sie geplante Parameter von der Primärdatenbank mit dem Standby-IAD /home/opc/oic-scripts/oic-sync-schedule-parameters.sh.
2. Aktivieren Sie relevante Integrationen bei Standby /home/opc/oic-scripts/oic-integration-switch.sh, und aktivieren Sie IAD.
3. Starten Sie geplante Integrationen bei Standby-/home/opc/oic-scripts/oic-integration-schedule.sh, und starten Sie IAD.
4. Aktualisieren Sie den DNS-Datensatz bei Standby-IAD /home/opc/oic-scripts/DNS-record-update.sh.
5. Deaktivieren Sie geplante Integrationen bei primärer /home/opc/oic-scripts/oic-integration-switch.sh, und deaktivieren Sie IAD.

Nachdem diese erstellt wurden, sollte der Switchover-Plan jetzt die fünf DR-Plangruppen für die Oracle-Integration enthalten, wie im Screenshot unten gezeigt. Möglicherweise haben Sie zusätzliche Plangruppen, wenn Ihre Schutzgruppe andere Anwendungen oder OCI-Services zusammen mit der Oracle-Integration enthält.

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

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

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

1. Aktivieren Sie relevante Integrationen in Region 1.
2. Geplante Parameter in Region 1 aktualisieren.
3. Geplante Integrationen in Region 1 starten.
4. Aktualisieren Sie den DNS-Datensatz in Region 1.

Aufgabe 11.1: Switchover-Plan auswählen

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

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

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

Aufgabe 11.2: Mehrere benutzerdefinierte Plangruppen in Region 1 erstellen (Standby)

Wir haben bereits gezeigt, wie Sie den verschiedenen benutzerdefinierten Plan für den Failover-Plan von Aufgabe 7.2 bis 7.5 erstellen. Erstellen Sie mit dem ähnlichen Prozess die folgenden vier benutzerdefinierten Plangruppen. Sie müssen die Compute-Instanz verwenden, die in der Region Phoenix ausgeführt wird, um Skripte auszuführen.

1. Aktivieren Sie relevante Integrationen bei Standby /home/opc/oic-scripts/oic-integration-switch.sh, und aktivieren Sie IAD.

2. Aktualisieren Sie geplante Parameter in Standby-IAD /home/opc/oic-scripts/oic-update-parameters.sh.

3. Starten Sie geplante Integrationen bei Standby-/home/opc/oic-scripts/oic-integration-schedule.sh, und starten Sie IAD.

4. Aktualisieren Sie den DNS-Datensatz bei Standby-IAD /home/opc/oic-scripts/DNS-record-update.sh.

Nachdem diese erstellt wurden, sollte der Failover-Plan jetzt die vier DR-Plangruppen für die Oracle-Integration enthalten, wie im Screenshot unten gezeigt. Möglicherweise haben Sie zusätzliche Plangruppen, wenn Ihre Schutzgruppe andere Anwendungen oder OCI-Services zusammen mit der Oracle-Integration enthält.

Abbildung 11-14: Vier benutzerdefinierte Plangruppen anzeigen, die dem Failover-Plan hinzugefügt wurden

Nächste Schritte

OCI Full Stack DR für Oracle Integration sollte an dieser Stelle vollständig implementiert werden. Die vollständige Funktionalität muss 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 sicherzustellen, dass alles wie erwartet funktioniert und das Recovery-Team den gesamten Prozess vollständig versteht.

Switchover-Pläne testen

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

Failover-Pläne testen

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

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 (Phoenix) sollte die primäre Region an diesem Punkt im Prozess sein. Gehen Sie folgendermaßen vor, um die endgültige Validierung aller Pläne zu beginnen:

• Test-Switchover von Region 2 (primär) zurück zu Region 1 (Standby).

• Testen Sie das Failover von Region 1 (primär) zu Region 2 (Standby).

• Region 1 (primär) vorbereiten für Failover von Region 2.

• Testen Sie das Failover von Region 2 (primär) zu Region 1 (Standby).

• Region 2 (primär) vorbereiten für einen Failover oder Switchover zu Region 2.

• Die DR-Schutzgruppen und der Anwendungsstack müssen sich in einem normalen Betriebszustand befinden und zu diesem Zeitpunkt für ein Failover oder Switchover bereit sein.

Hinweis: Um sicherzustellen, dass dieselbe Clientanwendung zur Authentifizierung der restlichen APIs für beide Oracle Integration-Instanzen verwendet werden kann, können Sie den Geltungsbereich der beiden Instanzen (d.h. primär und sekundär) der OAuth-Clientanwendung hinzufügen. Informationen zum Setup der OAuth-Clientanwendung finden Sie in der offiziellen Dokumentation.

Verwandte Links

• Technical Paper: Disaster-Recovery-Lösung für Oracle Integration der 2. Generation konfigurieren

• Beispielskripte: Laden Sie Beispielskripte von GitHub herunter

• OCI Full Stack DR Oracle Integration-Wiedergabeliste in YouTube

  • Oracle Integration für Disaster Recovery bereitstellen (Video 1)

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

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

• OCI-Vollstack-Datenwiederherstellung

• OCI Full Stack Disaster Recovery - Dokumentation

• OCI Full Stack Disaster Recovery - Benutzerdefinierte Gruppenskripte

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

Danksagungen

• Autor - Suraj Ramesh (Full Stack Disaster Recovery Product Manager)

• Mitwirkende - Bonnie Rockey (Cloud Engineering, Oracle Integration Specialist), Akshay Saxena (Cloud Engineering, Oracle Integration Specialist)

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

Weitere Lernressourcen

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

Produktdokumentation finden Sie im Oracle Help Center.

---

Titel und Copyright-Informationen

Automate Recovery for Oracle Integration using OCI Full Stack Disaster Recovery

F99101-01

May 2024

Copyright ©2024,

Oracle und/oder verbundene Unternehmen.