OCI Full Stack Disaster Recovery konfigurieren

Konfigurieren Sie Ihre Disaster Recovery-Schutzgruppen, und erstellen Sie Ihre Switchover- und Failover-Pläne. Die Schritte hängen vom verwendeten Disaster-Recovery-Modell ab.

Primäre DR-Schutzgruppe definieren

Die primäre Disaster-Recovery-(DR-)Schutzgruppe enthält die Komponenten des Systems in der primären Region. Sie enthält die Komponenten, die während eines Switchovers oder Failovers eine Aktion erfordern.

Führen Sie die folgenden Schritte aus, um die primäre DR-Schutzgruppe zu definieren:

  1. Melden Sie sich bei der Oracle Cloud Infrastructure-Konsole in der primären Region an.
  2. Navigieren Sie zu Migration und Disaster Recovery, und klicken Sie auf DR-Schutzgruppen.
  3. Klicken Sie auf DR-Schutzgruppe erstellen.
  4. Geben Sie einen Namen für die DR-Schutzgruppe ein.
  5. Wählen Sie das Compartment aus, und geben Sie einen Oracle Cloud Infrastructure Object Storage-Bucket für die Logs an.
  6. Lassen Sie die Rolle vorerst Nicht konfiguriert.
  7. Klicken Sie auf Mitglieder hinzufügen.
    1. Fügen Sie die primären Mid-Tier-Compute-Instanzen hinzu. Wählen Sie im Compute-Instanztyp die Option Nicht zu verschiebende Instanz aus.
      Ressourcentyp Instanz Compute-Instanztyp
      Berechnen Mid-Tier-Compute-Instanz 0 der primären Region Nicht zu verschiebende Instanz
      Berechnen Mid-Tier-Compute-Instanz 1 der primären Region Nicht zu verschiebende Instanz
      Berechnen Mid-Tier-Compute-Instanz n der primären Region Nicht zu verschiebende Instanz
    2. Fügen Sie die Primärdatenbank hinzu. Wählen Sie den entsprechenden Ressourcentyp (Database oder Autonomous Database) aus.
  8. Klicken Sie auf Create.

Standby-DR-Schutzgruppe definieren

Die Standby Disaster Recovery-(DR-)Schutzgruppe enthält die Komponenten des Systems in der sekundären Region. Sie enthält die Komponenten, die während eines Switchovers oder Failovers eine Aktion erfordern.

Führen Sie die folgenden Schritte aus, um die Standby-DR-Schutzgruppe zu definieren:

  1. Melden Sie sich bei der Oracle Cloud Infrastructure-Konsole in der Standby-Region an.
  2. Navigieren Sie zu Migration und Disaster Recovery, und klicken Sie auf DR-Schutzgruppen.
  3. Klicken Sie auf DR-Schutzgruppe erstellen.
  4. Geben Sie einen Namen für die DR-Schutzgruppe ein.
  5. Wählen Sie das Compartment aus, und geben Sie einen Oracle Cloud Infrastructure Object Storage-Bucket für die Logs an.
  6. Legen Sie die Rolle auf Standby fest.
    1. Wählen Sie die primäre Region in der Peerregion aus.
    2. Wählen Sie die zuvor erstellte DR-Schutzgruppe als Peer-DR-Schutzgruppe aus.
  7. Klicken Sie auf Mitglieder hinzufügen.
    1. Fügen Sie die Standby-Mid-Tier-Compute-Instanzen hinzu. Wählen Sie im Compute-Instanztyp die Option Nicht zu verschiebende Instanz aus.
      Ressourcentyp Instanz Compute-Instanztyp
      Berechnen Mid-Tier-Compute-Instanz 0 der Standbyregion Nicht zu verschiebende Instanz
      Berechnen Mid-Tier-Compute-Instanz 1 der Standbyregion Nicht zu verschiebende Instanz
      Berechnen Mid-Tier-Compute-Instanz n der Standbyregion Nicht zu verschiebende Instanz
    2. Fügen Sie die Standby-Datenbank hinzu. Wählen Sie den entsprechenden Ressourcentyp (Database oder Autonomous Database) aus.
  8. Klicken Sie auf Create.

Definition der DR-Schutzgruppen abschließen

Wenn Sie das DR-Modell basierend auf der regionsübergreifenden Block-Volume-Replikation verwenden, konfigurieren Sie das replizierte Block-Volume in jedem Compute-Member in der primären DR-Schutzgruppe und der Standby-DR-Schutzgruppe.

Hinweis:

Dieser Schritt gilt nur für das Disaster-Recovery-Modell basierend auf der regionsübergreifenden Replikation von OCI Block Volumes. Dieser Schritt gilt NICHT für Disaster-Recovery-Modelle, die auf den Methoden "OCI File Storage mit rsync" und "Database File System (DBFS)" für die Konfigurationsreplikation basieren.

  1. Konfigurieren Sie das replizierte Block-Volume in jedem Compute Member in der primären DR-Schutzgruppe.
    1. Bearbeiten Sie ein Compute-Element, klicken Sie auf Erweiterte Optionen und dann auf die Registerkarte Block-Volumes.
      • Wählen Sie unter Block-Volume das Block-Volume aus, das an die Instanz angehängt ist, die an die sekundäre Instanz repliziert wird.
      • Wählen Sie unter Referenzinstanz für Volume-Anhang die Peer-Compute-Instanz aus der Standbydatenbank aus.

        Mit dieser Compute-Instanz werden die Anhangsdetails beim Wechsel zu dieser Region abgerufen.

      • Geben Sie unter Einhängepunkt den Einhängepunkt an, an dem das Block-Volume gemountet ist.
    2. Die Compute-Instanz kann mehrere Block-Volumes enthalten, die repliziert werden. Beispiel: In Oracle WebLogic Server for OCI können Sie sowohl wlsociprefix-data-block-N als auch wlsociprefix-mw-block-N in die sekundäre replizieren. In diesem Fall fügen Sie der Definition des Compute-Instanzmitglieds zusätzliche replizierte Block-Volumes hinzu.

      Hinweis:

      Fügen Sie die BOOT-Volumes NICHT hinzu. Sie werden nicht repliziert.
    3. Wiederholen Sie den vorherigen Schritt für jedes Compute-Instanzmitglied in der primären Katastrophenschutzgruppe.
    Im Folgenden finden Sie ein Beispiel für die erweiterten Eigenschaften eines Block-Volumes in den Details der primären DR-Schutzgruppe für Compute-Member:
    Compute-Mitglied Block Volume Volume-Anhangsreferenzinstanz Mount Point
    Mid-Tier-Compute-Instanz 0 der primären Region wlsociprefix-data-block-1 Mid-Tier-Compute-Instanz 0 von Standby /u01/data
    Mid-Tier-Compute-Instanz 1 der primären Region wlsociprefix-data-block-2 Mid-Tier-Compute-Instanz 1 von Standby /u01/data
    Mid-Tier-Compute-Instanz n der primären Region wlsociprefix-data-block-N Mid-Tier-Compute-Instanz N von Standby /u01/data
  2. Konfigurieren Sie das replizierte Block-Volume in jedem Compute Member in der Standby-DR-Schutzgruppe:
    1. Bearbeiten Sie ein Standby-Compute Member, klicken Sie auf Erweiterte Optionen, und klicken Sie dann auf die Registerkarte Block-Volumes.
      • Wählen Sie unter Block-Volume das Block-Volume aus der primären Region aus, das an diese Compute-Instanz angehängt wird. In der Liste werden die Block-Volumes der Primärdatenbank direkt angezeigt.
      • Wählen Sie unter Referenzinstanz für Volume-Anhang die Peer-Compute-Instanz aus der primären Instanz aus.

        Damit werden die Anhangsdetails beim Wechsel zu dieser Region abgerufen.

      • Geben Sie unter Einhängepunkt den Einhängepunkt an, an dem das Block-Volume gemountet ist.
    2. Die Compute-Instanz kann mehrere Block-Volumes enthalten, die repliziert werden. Beispiel: In Oracle WebLogic Server for OCI können Sie sowohl wlsociprefix-data-block-N als auch wlsociprefix-mw-block-N in die sekundäre replizieren. In diesem Fall fügen Sie der Definition des Compute-Instanzmitglieds zusätzliche replizierte Block-Volumes hinzu.

      Hinweis:

      Fügen Sie die BOOT-Volumes NICHT hinzu. Sie werden nicht repliziert.
    3. Wiederholen Sie den vorherigen Schritt für jede Compute-Instanz, die Mitglied der Gruppe ist.
    Im Folgenden finden Sie ein Beispiel für die erweiterten Eigenschaften eines Block-Volumes in den Details der Standby-DR-Schutzgruppe für Compute-Member:
    Compute-Mitglied Block Volume Volume-Anhangsreferenzinstanz Mount Point
    Mid-Tier-Compute-Instanz 0 der Standbyregion wlsociprefix-data-block-1 Mid-Tier-Compute-Instanz 0 der primären Instanz /u01/data
    Mid-Tier-Compute-Instanz 1 der Standbyregion wlsociprefix-data-block-2 Mid-Tier-Compute-Instanz 1 der primären Instanz /u01/data
    Mid-Tier-Compute-Instanz n der Standbyregion wlsociprefix-data-block-N Mid-Tier-Compute-Instanz N der primären Instanz /u01/data
  3. Bearbeiten Sie die primäre DR-Schutzgruppe, um die Volume-Gruppen hinzuzufügen, die als Mitglieder der primären DR-Schutzgruppe repliziert werden.
    1. Klicken Sie auf Mitglied hinzufügen.
    2. Wählen Sie den Ressourcentyp Volume-Gruppe aus.
    3. Wählen Sie die Volume-Gruppe aus, die in die Standbydatenbank repliziert wird
    4. Wiederholen Sie den Vorgang für alle in der Primärdatenbank erstellten Volume-Gruppen, die in die Standbydatenbank repliziert werden.

      Hinweis:

      Führen Sie dies nur in der primären DR-Gruppe aus. Sie müssen der Standby-DR-Schutzgruppe keine Volume-Gruppe hinzufügen. OCI Full Stack Disaster Recovery Service fügt sie automatisch als Mitglieder zur Standby-DR-Schutzgruppe hinzu, wenn sie während des Switchover- oder Failover-Prozesses zur primären DR-Schutzgruppe wird.

Informationen zu DR-Plänen

Erstellen Sie Notfallwiederherstellungspläne (DR) für Ihre Schutzgruppen. Ein DR-Plan in einer bestimmten DR-Schutzgruppe ist für das Switchover oder Failover zu dieser DR-Schutzgruppe gültig.

Für die DR-Schutzgruppe von Region 1 definieren Sie die Switchover- und Failover-Pläne von Region 2 in Region 1. Für die DR-Schutzgruppe von Region 2 definieren Sie die Switchover- und Failover-Pläne von Region 1 in Region 2.

Hinweis:

Sie können nur Pläne in der DR-Schutzgruppe mit Standbyrolle erstellen und ändern.
Sie können folgende Plantypen erstellen:
  • Switchover-Plan

    Führt einen geplanten Übergang von Services von der primären DR-Schutzgruppe zur Standby-DR-Schutzgruppe aus. Mit Switchover-Plänen wird ein ordnungsgemäßer Übergang ausgeführt, indem der Anwendungsstack in der primären Region heruntergefahren und dann in der Standbyregion hochgefahren wird. Daher setzt ein Switchover-Plan voraus, dass Anwendungsstackkomponenten und andere erforderliche OCI-Services in beiden Regionen verfügbar sind. Switchover-Pläne werden in der Regel für geplante Sitewartung, Software-Patching, DR-Tests und zur Validierung verwendet.

  • Failover-Plan

    Führt einen ungeplanten Übergang von Services in die Standbyregion aus. Failover-Pläne führen in der Regel einen sofortigen Übergang aus, indem sie den Anwendungsstack in der Standbyregion hochfahren, ohne den Service in der primären Region herunterzufahren. Daher setzt ein Failover-Plan nur voraus, dass OCI-Services in der Standbyregion verfügbar sind. Failover-Pläne werden im Allgemeinen zur Ausführung von DR-Übergängen verwendet, wenn ein Ausfall oder ein Notfall in der primären Region auftritt.

Switchover-Plan erstellen

Erstellen Sie den Switchover-Plan in der Standby-Disaster-Recovery-(DR-)Schutzgruppe.

  1. Navigieren Sie in der Oracle Cloud Infrastructure-Konsole zur Standby-DR-Schutzgruppe, klicken Sie auf Pläne und dann auf Plan erstellen.
  2. Geben Sie einen Namen für den Plan an.
    Beispiel: switchover_to_region2.
  3. Wählen Sie Switchover für den Plantyp aus.

    Wenn der Plan erstellt wird, enthält er die integrierten Schritte: die Vorabprüfungen und den Datenbank-Switchover-Schritt sowie die Schritte zum Verwalten der regionsübergreifenden Block-Volumes-Replikation, sofern verwendet.

    Die Schritte sind in Plangruppen gruppiert. Alle Schritte unter derselben Plangruppe werden parallel ausgeführt.
    Im Folgenden werden die Plangruppen aufgeführt, die Out-of-the-box in einem Switchover-Plan für DR-Modelle auf Basis von OCI File Storage mit rsync- und Oracle Database File System-Konfigurationsreplikationsmethoden erwartet werden:
    • Integrierte Vorabprüfungen: Führt Vorabprüfungen für alle Schritte im Plan durch.
    • Switchover-Datenbanken (Standby): Führt das Switchover der Datenbank aus.
    Im Folgenden werden die Plangruppen aufgeführt, die Out-of-the-box in einem Switchover-Plan für das DR-Modell basierend auf der regionsübergreifenden Replikationsmethode von OCI Block Volumes erwartet werden:
    • Integrierte Vorabprüfungen: Führt Vorabprüfungen für alle Schritte im Plan durch.
    • Block-Volumes von Compute-Instanzen trennen: Hebt das Mounten und Trennen der Block-Volumes von den primären Compute-Instanzen auf.
    • Switchover-Volume-Gruppen: Aktiviert die Block-Volume-Gruppenreplikate auf der Standbysite, sodass neue Block-Volume-Gruppen und Block-Volumes in der Standbydatenbank erstellt werden. Sie sind eine Kopie der primären Block-Volumes.
    • Switchover-Datenbanken (Standby): Führt das Switchover der Datenbank aus.
    • Block-Volumes von Compute-Instanzen anhängen: Hängt die aktivierten Block-Volumes an die Standby-Compute-Instanzen an.
    • Replikation von Reverse Volume-Gruppen: Aktiviert die regionsübergreifende Replikation in den neuen Block Volume-Gruppen, die in der Standbyregion (neue Primärdatenbank) erstellt wurden. Sie werden jetzt auf die vorherige primäre Region repliziert.
    • Volume-Gruppe beenden: Beendet die Block-Volume-Gruppen und Block-Volumes in der vorherigen primären Region.
    • Volume-Gruppen aus DR-Schutzgruppe entfernen: Entfernt die Block-Volume-Gruppenmitglieder aus der vorherigen primären DR-Schutzgruppendefinition. Die Block-Volume-Gruppen werden jetzt als Mitglieder der neuen primären DR-Schutzgruppe hinzugefügt.

    Hinweis:

    Der Schritt Volume-Gruppe beenden ist standardmäßig deaktiviert.

    Wenn der Schritt deaktiviert ist, werden die Block-Volumes und Block-Volume-Gruppen in der vorherigen primären Instanz nicht gelöscht (nur getrennt). Sie müssen sie manuell löschen. Wenn der Schritt aktiviert ist, werden die Block-Volumes und Block-Volume-Gruppen in der vorherigen primären Instanz automatisch gelöscht.

    Nach anfänglichen Validierungstests empfiehlt Oracle, diesen Schritt zu aktivieren, um Block-Volume-Duplizierungen zu vermeiden. Andernfalls werden die verbleibenden Block-Volumes kontinuierlich repliziert, und selbst wenn sie nicht verwendet werden, fallen unerwünschte Kosten an.

  4. Fügen Sie für die restlichen Aktionen die benutzerdefinierten Plangruppen und Schritte für die Oracle WebLogic Server-(WLS-)Instanzen und das Frontend-DNS-Switchover hinzu, wie in der Tabelle gezeigt.
    Benutzerdefinierte Plangruppe Schritt Fehlermodus Bereich Script Zielinstanz Skriptparameter Ausführen als Benutzer
    WLS-Anschlag in remote_region (parallel) WLS-Stoppknoten 0 Bei Fehler stoppen Remote-Region Lokales Skript ausführen Mid-Tier-Compute-Instanz 0 /opt/scripts/custom_stop.sh oracle
    WLS-Anschlag in remote_region (parallel) WLS-Stoppknoten 1 Bei Fehler stoppen Remote-Region Lokales Skript ausführen Mid-Tier-Compute-Instanz 1 /opt/scripts/custom_stop.sh oracle
    WLS-Anschlag in remote_region (parallel) WLS-Stoppknoten N Bei Fehler stoppen Remote-Region Lokales Skript ausführen Mid-Tier-Compute-Instanz N /opt/scripts/custom_stop.sh oracle
    WLS-Admin-Server starten in this_region WLS-Admin-Server Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz 0 /opt/scripts/custom_start_aserver.sh oracle
    WLS-Managed Server werden in this_region gestartet (alle parallel) WLS-Startknoten 0 Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz 0 /opt/scripts/custom_start_mserver.sh oracle
    WLS-Managed Server werden in this_region gestartet (alle parallel) WLS-Startknoten 1 Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz 1 /opt/scripts/custom_start_mserver.sh oracle
    WLS-Managed Server werden in this_region gestartet (alle parallel) WLS-Startknoten N Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz N /opt/scripts/custom_start_mserver.sh oracle
    Frontend-DNS-Switchover Frontend-DNS-Switchover Bei Fehler stoppen Dieser Bereich Funktion / des lokalen Skripts ausführen Mid-Tier-Compute-Instanz 0 Pfad zum DNS-Skript im Host opc (oder der Benutzer, der das DNS-Skript ausführt)

    Hinweis:

    Der Standardtimeout für jeden Vorgang beträgt 3600 Sekunden. Dieser Wert wird in den meisten Fällen korrekt angepasst. Bei einigen Vorgängen, wie dem Starten und Stoppen von WLS-Managed Servern, müssen Sie diesen Wert möglicherweise basierend auf den bereitgestellten Anwendungen anpassen, und ob ordnungsgemäße Herunterfahren auf Java Transaction API-(JTA-)Einstellungen und Vorgänge mit langer Ausführungszeit warten müssen. Ebenso hängt der Starttimeout von Ihren Oracle WebLogic Server-Deployments ab. Beispiel: In einem SOA-System kann dies je nach Anzahl und Typ der bereitgestellten Composites variieren. Da sich dies direkt auf das erwartete Recovery Time Objective (RTO) auswirken kann, prüfen Sie zunächst jeden Vorgang manuell für Ihr System, und verwenden Sie den zulässigen Timeoutwert, um das RTO zu erfüllen (möglicherweise müssen Sie eingreifen, wenn ein Timeout auftritt).

    Die Schritte unter derselben Plangruppe werden parallel ausgeführt. Die Plangruppen werden im seriellen Modus ausgeführt. Stellen Sie daher die Schritte zum Stoppen der Oracle WebLogic Server-Instanzen unter derselben Plangruppe ein, sodass diese Oracle WebLogic Server-Instanzen parallel gestoppt werden. Die Schritte zum Starten von Oracle WebLogic Server-Instanzen sind jedoch in 2 Plangruppen unterteilt: eine Plangruppe zum Starten des Administrationsservers im ersten Knoten und eine andere Plangruppe mit N-Schritten, um die verwalteten Oracle WebLogic Server-Instanzen in allen Hosts parallel zu starten.

  5. Optional können Sie die folgenden benutzerdefinierten Schritte hinzufügen, wenn Sie ein DR-Modell basierend auf OCI File Storage mit rsync- oder Oracle Database File System-Konfigurationsreplikation verwenden. Diese Skripte replizieren die Oracle WebLogic-Konfiguration vor dem Switchover in die Standbydatenbank:
    Benutzerdefinierte Plangruppe Schritt Fehlermodus Bereich Script Zielinstanz Skriptparameter Ausführen als Benutzer
    (Optional,) Konfigurationssynchronisierung in primärer (vom primären zum Staging-Ordner) Konfigurationsreplikatskript auf Primärknoten 0 ausführen Bei Fehler stoppen Remote-Region Lokales Skript ausführen Mid-Tier-Compute-Instanz 0 /u01/scripts/config_replica.sh oracle
    (Optional) Konfigurationssynchronisierung in Standby (von Staging-Ordner zu Standby) Konfigurationsreplikatskript auf Standbyknoten 0 ausführen Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz 0 /u01/scripts/config_replica.sh oracle
  6. Fügen Sie diese benutzerdefinierten Schritte hinzu, wenn Sie das DR-Modell basierend auf dem regionsübergreifenden OCI-Block-Volumes-Replikat verwenden, um die Datenbankverbindungszeichenfolgen in der Oracle WebLogic-(WLS-)Konfiguration zu ersetzen und auf die lokale Datenbank zu verweisen:
    Benutzerdefinierte Plangruppe Schritt Fehlermodus Bereich Script Zielinstanz Skriptparameter Ausführen als Benutzer
    Ersetzen von DB-Connect String in WLS (alle parallel) in WLS-Knoten 0 Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz 0 /u01/scripts/replacement_script_BVmodel.sh oracle
    Ersetzen von DB-Connect String in WLS (alle parallel) in WLS-Knoten 1 Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz 1 /u01/scripts/replacement_script_BVmodel.sh oracle
    Ersetzen von DB-Connect String in WLS (alle parallel) in WLS-Knoten N Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz N /u01/scripts/replacement_script_BVmodel.sh oracle
  7. Ordnen Sie die Plangruppen im Plan wie folgt neu an, wenn Sie das DR-Modell basierend auf OCI File Storage mit rsync- oder Oracle Database File System-Konfigurationsreplikation verwenden:
    Plangruppenposition Plangruppe Plangruppentyp
    1 Integrierte Vorabprüfungen Integrierter Schritt
    2 (Optional) Konfigurationssynchronisierung im primären Ordner (vom primären zum Staging-Ordner) Benutzerdefinierter Schritt
    3 (Optional) Konfigurationssynchronisierung in Standby (von Staging-Ordner zu Standby) Benutzerdefinierter Schritt
    4 Oracle WebLogic Server wird in remote_region heruntergefahren (parallel) Benutzerdefinierter Schritt
    5 DNS-Switchover Benutzerdefinierter Schritt
    6 Switchover von Datenbanken (Standby) Integrierter Schritt
    7 Oracle WebLogic Server-Admin-Server starten in this_region Benutzerdefinierter Schritt
    8 Managed Server von Oracle WebLogic Server werden in this_region gestartet (alle Knoten parallel) Benutzerdefinierter Schritt
  8. Ordnen Sie die Plangruppen im Plan wie folgt neu an, wenn Sie ein DR-Modell basierend auf der regionsübergreifenden Replikation von OCI Block Volumes basierend auf der Standardreihenfolge verwenden:
    Plangruppenposition Plangruppe Plangruppentyp
    1 Integrierte Vorabprüfungen Integrierter Schritt
    2 Oracle WebLogic Server wird in remote_region heruntergefahren (parallel) Benutzerdefinierter Schritt
    3 Block-Volumes von Compute-Instanzen trennen Integrierter Schritt
    4 Switchover-Volume-Gruppen Integrierter Schritt
    5 DNS-Switchover Benutzerdefinierter Schritt
    6 Switchover von Datenbanken (Standby) Integrierter Schritt
    7 Block-Volumes von Compute-Instanzen anhängen Integrierter Schritt
    8 Ersetzen der DB-Verbindungszeichenfolge in Oracle WebLogic Server (alle parallel) Benutzerdefinierter Schritt
    9 Oracle WebLogic Server-Admin-Server starten in this_region Benutzerdefinierter Schritt
    10 Managed Server von Oracle WebLogic Server werden in this_region gestartet (alle Knoten parallel) Benutzerdefinierter Schritt
    11 Replikation von Reverse Volume-Gruppen Integrierter Schritt
    12 Volume-Gruppe beenden Integrierter Schritt
    13 Volume-Gruppen aus DR-Schutzgruppe entfernen Integrierter Schritt

    Die Ausfallzeit für diesen Switchover-Plan beginnt im 2. Schritt und endet, sobald Schritt 10 abgeschlossen ist.

    Um die Ausfallzeit während des Switchover-Plans zu minimieren, können Sie die folgende Reihenfolge verwenden:
    Plangruppenposition Plangruppe Plangruppentyp
    1 Integrierte Vorabprüfungen Integrierter Schritt
    2 Switchover-Volume-Gruppen Integrierter Schritt
    3 Block-Volumes von Compute-Instanzen anhängen Integrierter Schritt
    4 Ersetzen der DB-Verbindungszeichenfolge in Oracle WebLogic Server (alle parallel) Benutzerdefinierter Schritt
    5 Oracle WebLogic Server wird in remote_region heruntergefahren (parallel) Benutzerdefinierter Schritt
    6 DNS-Switchover Benutzerdefinierter Schritt
    7 Switchover von Datenbanken (Standby) Integrierter Schritt
    8 Oracle WebLogic Server-Admin-Server starten in this_region Benutzerdefinierter Schritt
    9 Managed Server von Oracle WebLogic Server werden in this_region gestartet (alle Knoten parallel) Benutzerdefinierter Schritt
    10 Block-Volumes von Compute-Instanzen trennen Integrierter Schritt
    11 Replikation von Reverse Volume-Gruppen Integrierter Schritt
    12 Volume-Gruppe beenden Integrierter Schritt
    13 Volume-Gruppen aus DR-Schutzgruppe entfernen Integrierter Schritt
    Die Ausfallzeit für diese Umschaltung erfolgt zwischen Schritt 5 und endet, sobald Schritt 9 abgeschlossen ist.

    Hinweis:

    Der Schritt zum Beenden der Volume-Gruppe ist standardmäßig deaktiviert.

    Wenn der Schritt deaktiviert ist, werden die Block-Volumes und Block-Volume-Gruppen in der vorherigen primären Instanz nicht gelöscht (sie werden nur getrennt, und das regionsübergreifende Replikat ist deaktiviert). Sie müssen sie manuell löschen. Wenn der Schritt aktiviert ist, werden die Block-Volumes und Block-Volume-Gruppen in der vorherigen primären Instanz automatisch gelöscht.

    Nach den ersten Validierungstests empfiehlt Oracle, diesen Schritt zu aktivieren, um Block-Volume-Duplizierungen zu vermeiden. Andernfalls replizieren sich die verbleibenden Block-Volumes kontinuierlich und verursachen, selbst wenn sie nicht verwendet werden, unerwünschte Kosten.

  9. Wiederholen Sie diese Schritte, um den Switchback-Plan in der DR-Schutzgruppe für die primäre Region zu erstellen.

    Hinweis:

    Um den Switchback-Plan in der DR-Schutzgruppe für die primäre Region zu erstellen, müssen Sie warten, bis er sich in der Standbyrolle befindet. Planen Sie daher ein Switchover in einem geplanten Ausfallzeitfenster, oder warten Sie bis zum nächsten geplanten Switchover, um die Switchback-Pläne in der anderen DR-Schutzgruppe zu erstellen.

Failover-Plan erstellen

Erstellen Sie den Failover-Plan in der Standby-DR-Schutzgruppe.

  1. Navigieren Sie in der OCI-Konsole zur Standby-DR-Schutzgruppe, klicken Sie auf Pläne und dann auf Plan erstellen.
  2. Geben Sie einen Namen für den Plan an.
    Beispiel: failover_to_region2.
  3. Wählen Sie Failover für den Plantyp aus.
    Wenn der Plan erstellt wird, enthält er die integrierten Schritte: die Vorabprüfungen und den Datenbank-Failover-Schritt sowie Schritte für die regionsübergreifende Replikation in Block Volumes, sofern verwendet.
    Im Folgenden werden die Plangruppen aufgeführt, die Out-of-the-box in einem Failover-Plan für DR-Modelle auf Basis von OCI File Storage mit rsync- und Oracle Database File System-Konfigurationsreplikationsmethoden erwartet werden:
    • Integrierte Vorabprüfungen: Führt Vorabprüfungen für alle Schritte im Plan durch.
    • Failover-Datenbanken (Standby): Führt das Failover der Datenbank aus.
    Im Folgenden werden die Plangruppen aufgeführt, die Out-of-the-box in einem Failover-Plan für das DR-Modell basierend auf der regionsübergreifenden Replikationsmethode von OCI Block Volumes erwartet werden:
    • Integrierte Vorabprüfungen: Führt Vorabprüfungen für alle Schritte im Plan durch.
    • Failover-Volume-Gruppen: Aktiviert die Block-Volume-Gruppenreplikate in der Standbyregion, sodass neue Block-Volume-Gruppen und Block-Volumes in der Standbyregion erstellt werden. Sie sind eine Kopie der primären Block-Volumes.
    • Failover-Datenbanken (Standby): Führt das Failover der Datenbank aus.
    • Block-Volumes von Compute-Instanzen anhängen: Hängt die Block-Volumes in der Standbydatenbank an die Standby-Compute-Instanzen an.

    Hinweis:

    Der Failover-Plan enthält keine Vorgänge in der primären DR-Gruppe. Nach einem Failover müssen Sie einige Aktionen manuell ausführen, sobald das primäre System wieder verfügbar ist. Weitere Einzelheiten finden Sie unter DR-Konfiguration nach einem Failover zurücksetzen.

  4. Fügen Sie für die restlichen Aktionen die Plangruppen und -schritte hinzu, wie in der Tabelle dargestellt.
    Benutzerdefinierte Plangruppe Schritt Fehlermodus Bereich Script Zielinstanz Skriptparameter Ausführen als Benutzer
    WLS-Anschlag in remote_region (parallel) WLS-Stoppknoten 0 Bei Fehler fortfahren Remote region Lokales Skript ausführen Mid-Tier-Compute-Instanz 0 /opt/scripts/custom_stop.sh oracle
    WLS-Anschlag in remote_region (parallel) WLS-Stoppknoten 1 Bei Fehler fortfahren Remote region Lokales Skript ausführen Mid-Tier-Compute-Instanz 1 /opt/scripts/custom_stop.sh oracle
    WLS-Anschlag in remote_region (parallel) WLS-Stoppknoten N Bei Fehler fortfahren Remote region Lokales Skript ausführen Mid-Tier-Compute-Instanz N /opt/scripts/custom_stop.sh oracle
    WLS-Admin-Server starten in this_region WLS-Admin-Server Bei Fehler stoppen This region Lokales Skript ausführen Mid-Tier-Compute-Instanz 0 /opt/scripts/custom_start_aserver.sh oracle
    WLS-Managed Server werden in this_region gestartet (alle parallel) WLS-Startknoten 0 Bei Fehler stoppen This region Lokales Skript ausführen Mid-Tier-Compute-Instanz 0 /opt/scripts/custom_start_mserver.sh oracle
    WLS-Managed Server werden in this_region gestartet (alle parallel) WLS-Startknoten 1 Bei Fehler stoppen This region Lokales Skript ausführen Mid-Tier-Compute-Instanz 1 /opt/scripts/custom_start_mserver.sh oracle
    WLS-Managed Server werden in this_region gestartet (alle parallel) WLS-Startknoten N Bei Fehler stoppen This region Lokales Skript ausführen Mid-Tier-Compute-Instanz N /opt/scripts/custom_start_mserver.sh oracle
    Frontend-DNS-Switchover Frontend-DNS-Switchover Bei Fehler stoppen This region Lokales Skript / Funktion ausführen Mid-Tier-Compute-Instanz 0 Pfad zum DNS-Skript im Host opc (oder der Benutzer, der das DNS-Skript ausführt)

    Die Schritte entsprechen den Schritten, die für den entsprechenden Switchover-Plan definiert wurden. Stellen Sie in diesem Fall jedoch sicher, dass Sie den Fehlermodus in den Schritten, mit denen Oracle WebLogic Server in der Primärdatenbank gestoppt wird, auf Bei Fehler fortfahren setzen. In einem Failover-Szenario sind die primären Komponenten möglicherweise nicht verfügbar.

    Hinweis:

    Der Standardtimeout für jeden Vorgang beträgt 3600 Sekunden. Dieser Wert wird in den meisten Fällen korrekt angepasst. Bei einigen Vorgängen, wie dem Starten und Stoppen von WLS-Managed Servern, müssen Sie diesen Wert möglicherweise basierend auf den bereitgestellten Anwendungen anpassen, und ob ordnungsgemäße Herunterfahren auf Java Transaction API-(JTA-)Einstellungen und Vorgänge mit langer Ausführungszeit warten müssen. Ebenso hängt der Starttimeout von Ihren Oracle WebLogic Server-Deployments ab. Beispiel: In einem SOA-System kann dies je nach Anzahl und Typ der bereitgestellten Composites variieren. Da sich dies direkt auf das erwartete Recovery Time Objective (RTO) auswirken kann, prüfen Sie zunächst jeden Vorgang manuell für Ihr System, und verwenden Sie den zulässigen Timeoutwert, um das RTO zu erfüllen (möglicherweise müssen Sie eingreifen, wenn ein Timeout auftritt).

    Die Plangruppen werden im seriellen Modus ausgeführt. Die Schritte unter derselben Plangruppe werden parallel ausgeführt. Stellen Sie daher die Schritte zum Stoppen der Oracle WebLogic Server-Instanzen unter derselben Plangruppe ein, sodass diese Oracle WebLogic Server-Instanzen parallel gestoppt werden. Die Schritte zum Starten von Oracle WebLogic Server-Instanzen sind jedoch in 2 Plangruppen unterteilt: eine Plangruppe zum Starten des Administrationsservers im ersten Knoten und eine andere Plangruppe mit N-Schritten, um die verwalteten Oracle WebLogic Server-Instanzen in allen Knoten parallel zu starten.

  5. Fügen Sie diese benutzerdefinierten Schritte hinzu, wenn Sie das DR-Modell basierend auf dem regionsübergreifenden OCI-Block-Volumes-Replikat verwenden, um die Datenbankverbindungszeichenfolgen in der Oracle WebLogic Server-(WLS-)Konfiguration zu ersetzen und auf die lokale Datenbank zu verweisen:
    Benutzerdefinierte Plangruppe Schritt Fehlermodus Bereich Script Zielinstanz Skriptparameter Ausführen als Benutzer
    Ersetzen von DB-Connect String in WLS (alle parallel) in WLS-Knoten 0 Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz 0 /u01/scripts/replacement_script_BVmodel.sh oracle
    Ersetzen von DB-Connect String in WLS (alle parallel) in WLS-Knoten 1 Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz 1 /u01/scripts/replacement_script_BVmodel.sh oracle
    Ersetzen von DB-Connect String in WLS (alle parallel) in WLS-Knoten N Bei Fehler stoppen Dieser Bereich Lokales Skript ausführen Mid-Tier-Compute-Instanz N /u01/scripts/replacement_script_BVmodel.sh oracle
  6. Ordnen Sie die Plangruppen im Failover-Plan wie folgt neu an, wenn Sie das DR-Modell basierend auf Oracle Cloud Infrastructure File Storage mit der Replikation rsync oder der Konfiguration des Oracle Database-Dateisystems verwenden:
    Plangruppenposition Plangruppe Plangruppentyp
    1 Integrierte Vorabprüfungen Integrierter Schritt
    2 Oracle WebLogic Server wird in remote_region heruntergefahren (parallel) Benutzerdefinierter Schritt
    3 DNS-Switchover Benutzerdefinierter Schritt
    4 Failover für Datenbanken (Standby) ausführen Integrierter Schritt
    5 Oracle WebLogic Server-Admin-Server starten in this_region Benutzerdefinierter Schritt
    6 Managed Server von Oracle WebLogic Server werden in this_region gestartet (alle Knoten parallel) Benutzerdefinierter Schritt
  7. Ordnen Sie die Plangruppen im Plan wie folgt neu an, wenn Sie ein DR-Modell basierend auf der regionsübergreifenden OCI-Block-Volumes-Replikation basierend auf der Standardreihenfolge verwenden.
    Plangruppenposition Plangruppe Plangruppentyp
    1 Integrierte Vorabprüfungen Integrierter Schritt
    2 Oracle WebLogic Server wird in remote_region heruntergefahren (parallel) Benutzerdefinierter Schritt
    3 Failover-Volume-Gruppen Integrierter Schritt
    4 DNS-Switchover Benutzerdefinierter Schritt
    5 Failover für Datenbanken (Standby) ausführen Integrierter Schritt
    6 Block-Volumes von Compute-Instanzen anhängen Integrierter Schritt
    7 Ersetzen der DB-Verbindungszeichenfolge in WLS in this_region (alle Knoten parallel) Benutzerdefinierter Schritt
    8 Oracle WebLogic Server-Admin-Server starten in this_region Benutzerdefinierter Schritt
    9 Managed Server von Oracle WebLogic Server werden in this_region gestartet (alle Knoten parallel) Benutzerdefinierter Schritt
  8. Wiederholen Sie diese Schritte, um den Failover-Plan in der DR-Schutzgruppe für die primäre Region zu erstellen.

    Hinweis:

    Um den Failover-Plan in der DR-Schutzgruppe für die primäre Region zu erstellen, müssen Sie warten, bis er die Standbyrolle hat.