rsync mit einer zentralen Staging Area implementieren

Diese Implementierung verwendet die rsync-Technologie und folgt dem Modell basierend auf einer zentralen Staging Area. In diesem Modell gibt es einen Bastionhostknoten, der als Koordinator fungiert. Es stellt eine Verbindung zu jedem Host her, der repliziert werden muss, und kopiert den Inhalt in eine gemeinsame Staging Area.

Die Vorteile der Implementierung von rsync mit einer zentralen Staging Area sind:

• Es handelt sich um eine allgemeine Lösung für alle Mid-Tier-Systeme. Wenn Sie also über mehrere Systeme verfügen, können Sie in allen Systemen den gleichen Ansatz verwenden.
• Sie hängt nicht vom zugrunde liegenden Speichertyp ab. Sie gilt für das Replizieren von Dateiartefakten, die in Block-Volumes, in NFS usw. gespeichert sind.
• Der Speicher kann in den sekundären Knoten eingehängt bleiben. Daher sind keine zusätzlichen Schritte erforderlich, um den Speicher bei jedem Switchover- oder Failover-Vorgang im sekundären Speicher zu befestigen oder zu mounten.
• Im Vergleich zur Peer-to-Peer-Implementierung ist die Wartung einfacher, da ein zentraler Knoten für die Ausführung der Skripte vorhanden ist.

Überlegungen zur Implementierung der rsync mit einem zentralen Staging Area:

• Es liegt in der Verantwortung des Benutzers, die benutzerdefinierten Skripte für jede Umgebung zu erstellen und regelmäßig auszuführen.
• Es liegt in der Verantwortung des Benutzers, eine Möglichkeit zur Umkehrung der Replikationsrichtung zu implementieren.
• Für dieses Modell sind ein zusätzlicher Host und Speicher für die zentrale Staging Area erforderlich.

Ähnlich wie beim Peer-to-Peer-Modell können die rsync-Skripte ein Pull- oder ein Push-Modell verwenden. Im Modell "pull" kopiert das Skript die Dateien vom Remote-Knoten auf den lokalen Knoten. Im "Push"-Modell kopiert das Skript die Datei vom lokalen Knoten auf den Remote-Knoten. Oracle empfiehlt die Verwendung eines Pull-Modells zum Abrufen der Inhalte von primären Hosts, da die primären Knoten vom Overhead der Kopien ausgelagert werden.

Replikation für rsync mit Central Staging einrichten

Um rsync mit einem zentralen Staging Area zu implementieren, ist Folgendes erforderlich:

• Ein Bastionhost mit SSH-Konnektivität zu allen Hosts (primär und sekundär).
• Ein Staging-Ordner auf dem Bastionhost mit ausreichend Speicherplatz zum Speichern der replizierten Mid-Tier-Dateisysteminhalte.
• Skripte, die rsync verwenden, um die Mid-Tier-Dateiartefakte aus und in diesen Staging-Ordner zu kopieren. Die rsync-Skripte können bestimmte Ordner aus der Kopie überspringen (wie Sperrdateien, Logs, temporäre Dateien usw.).
• Eine Möglichkeit, die standortspezifischen Informationen zu verwalten, indem diese Informationen entweder aus der Kopie ausgeschlossen oder mit den entsprechenden Informationen nach dem Replikat aktualisiert werden.
• Planen Sie die regelmäßige Ausführung dieser Skripte.
• Ein Mechanismus zum Ändern der Richtung des Replikats nach einem Switchover oder Failover. Bei diesem Mechanismus kann es sich um eine dynamische Prüfung handeln, bei der die Rolle der Site identifiziert wird, oder um eine manuelle Änderung nach einem Switchover oder Failover (z.B. Deaktivieren und Aktivieren der entsprechenden Skripte).

Dieses Dokument enthält zwei verschiedene Implementierungsbeispiele für dieses Modell:

• Beispiel 1: Oracle Fusion Middleware Disaster Recovery Guide-Skripte verwenden
• Beispiel 2: WLS-HYDR-Framework verwenden

Beispiel 1: Oracle Fusion Middleware Disaster Recovery Guide-Skripte verwenden

Hinweis:

Dieses Beispiel gilt für alle Mid-Tier-Systeme. Als Referenz verwendet es die vom Oracle Fusion Middleware Disaster Recovery Guide bereitgestellten Skripte, um das Mid-Tier-Replikat für ein Oracle WebLogic DR-System auszuführen: rsync_for_WLS.sh und rsync_copy_and_validate.sh. Diese Skripte sind jedoch im Allgemeinen anwendbar und bieten genügend Flexibilität, um die Mid-Tier-Dateisystemartefakte in OCI zu synchronisieren.

Der Oracle Fusion Middleware Disaster Recovery Guide enthält rsync-Skripte, mit denen Remotekopien in einem Mid-Tier-System ausgeführt werden können. Diese Skripte sind für jedes rsync-Modell gültig. Dieses spezielle Beispiel zeigt, wie sie für das zentrale Staging-Modell verwendet werden. In dieser Implementierung werden Pull-Vorgänge in zwei Schritten verwendet:

• Ein Bastionhost ruft den Inhalt von allen primären Hosts ab und speichert ihn in der zentralen Staging Area.
• Anschließend führen alle sekundären Knoten einen Pull-Vorgang aus, um den Inhalt aus dem zentralen Staging zu sammeln.

Informationen zum Einrichten der Mid-Tier-Replikation mit diesen Skripten finden Sie unter Replicating the Primary File Systems to the Secondary Site im Oracle Fusion Middleware Disaster Recovery Guide sowie insbesondere in den Schritten Rsync Replication Approach und Using a Staging Location.

Beschreibung der Abbildung replica-rsync-scripts.png

replica-rsync-scripts-oracle.zip

Beispiel 2: WLS-HYDR-Framework verwenden

Hinweis:

Dieses Beispiel gilt für ein Oracle WebLogic Server-System. Es verwendet das Replikationsmodul des WLS-HYDR-Frameworks, gilt jedoch für jede Oracle WebLogic Server-DR-Umgebung, unabhängig davon, ob es mit dem WLS-HYDR-Framework erstellt wurde oder nicht.

In diesem Modell fungiert ein zentraler Hostknoten als Gesamtkoordinator und führt Pull- und Push-Vorgänge aus. Es stellt eine Verbindung zu jedem Host her, der repliziert werden muss, und kopiert den Inhalt in eine gemeinsame Staging Area. Dieser Knoten koordiniert auch die Kopie von der Staging Area zu den Zielhosts. Bei diesem Ansatz werden die einzelnen Knoten aus dem Overhead der Kopien ausgelagert.

Das WLS-HYDR-Framework verwendet diese Lösung für die erste Kopie während des DR-Setups. Anschließend können Sie das Replikationsmodul des Frameworks wiederverwenden, um den Pull-Vorgang und den Push-Vorgang regelmäßig zu wiederholen. In diesem Playbook finden Sie weitere Informationen zu Links zum WLS-HYDR-Framework und anderen Ressourcen.

Der Bastion-Knoten führt das Replikat in zwei Schritten aus:

• Ein Pull-Vorgang, bei dem eine Verbindung zu den primären Hosts hergestellt und der Inhalt des Dateisystems in einen Staging-Ordner im Bastionhost kopiert wird.
• Ein Push-Vorgang, bei dem der Inhalt aus dem Staging-Ordner der Bastion auf alle sekundären Hosts kopiert wird.

Ein zentraler Knoten führt alle Vorgänge aus, sodass Planung, Protokolle, Wartung usw. auf diesem Knoten zentralisiert sind. Wenn das System über viele Knoten verfügt, ist dies effizienter als das Peer-to-Peer-Modell oder das vorherige Beispiel.

Beschreibung der Abbildung replica-wls-hydr-framework.png

replica-wls-hydr-framework-oracle.zip

Wenn Sie das WLS-HYDR-Framework zum Erstellen des sekundären Systems verwendet haben, ist der Bastionhost bereits bereit, das Replikat auszuführen. Andernfalls können Sie ihn an dieser Stelle konfigurieren. Führen Sie die folgenden Schritte aus, um das Replikat einzurichten:

1. Bereite die Bastion vor.

   Wenn Sie das WLS-HYDR-Framework zum Erstellen des sekundären Systems verwendet haben, ist der Bastionhost bereits bereit, das Replikat auszuführen. Wenn nicht, prüfen Sie README im Repository GitHub des WLS-HYDR-Frameworks, um einen Bastionhost vorzubereiten.

2. Prüfen Sie die WLS-HYDR-Konfigurationsdateien.
   Stellen Sie sicher, dass die WLS-HYDR-Konfigurationsdateien (replication.properties, oci.env und prem.env) die richtigen Informationen für Ihr System enthalten.
3. Führen Sie das Replikationsmodul WLS-HYDR aus.
   Mit dem Replikationsmodul des Frameworks können Sie alle Elemente (die Oracle WebLogic Server-Domain und -Produkte) synchronisieren. Sie können diese Elemente auch unabhängig synchronisieren. In allen Fällen besteht die vollständige Synchronisierung aus zwei Vorgängen: einem Pull-Vorgang, um den Inhalt aus der Primärdatenbank abzurufen, und einem Push-Vorgang, um den Inhalt in die Sekundärdatenbank zu kopieren.

   Hinweis:

   Führen Sie immer den Vorgang PULL vor dem Vorgang PUSH aus. Andernfalls wird die neueste Version des Inhalts nicht übertragen.
   1. So synchronisieren Sie alle Inhalte:
      • So ziehen Sie alle Inhalte von den primären Hosts in das Staging des Bastionhosts:

        WLS-HYDR_BASE/lib/DataReplication.py pull

      • So übertragen Sie alle Inhalte vom Staging des Bastionhosts an die sekundären Hosts:

        WLS-HYDR_BASE/lib/DataReplication.py push

   2. So synchronisieren Sie nur Artefakte:
      • So ziehen Sie die Produkte von den primären Hosts in das Staging des Bastionhosts:

        WLS-HYDR_BASE/lib/DataReplication.py pull -d products

      • So übertragen Sie die Produkte vom Staging des Bastionhosts auf die sekundären Hosts:

        WLS-HYDR_BASE/lib/DataReplication.py push -d products

   3. So synchronisieren Sie nur die Konfiguration (die Domain WebLogic).
      • Um die Konfiguration von den primären Hosts zum Staging des Bastionhosts abzurufen, führen Sie diesen Pull-Vorgang aus:

        WLS-HYDR_BASE/lib/DataReplication.py pull -d private_config

      • Um die Konfiguration vom Staging des Bastionhosts auf die sekundären Hosts zu kopieren, führen Sie diesen Push-Vorgang aus:

        WLS-HYDR_BASE/lib/DataReplication.py push -d private_config

   4. In Fällen, in denen ein Ordner für eine gemeinsam verwendete Konfiguration vorhanden ist (gemeinsam verwendete Oracle WebLogic-Domain in einem OCI File Storage-Dateisystem):
      • Um die gemeinsame Konfiguration von den primären Hosts zum Staging des Bastionhosts abzurufen, führen Sie diesen Pull-Vorgang aus:

        WLS-HYDR_BASE/lib/DataReplication.py pull -d shared_config

      • Um die gemeinsame Konfiguration vom Staging des Bastionhosts auf die sekundären Hosts zu kopieren, führen Sie diesen Push-Vorgang aus:

        WLS-HYDR_BASE/lib/DataReplication.py push -d shared_config

4. Bereiten Sie die Ersetzung der Datenbankverbindungszeichenfolge vor.
   Die regulären Pull- und Push-Vorgänge von WLS-HYDR, bei denen die WebLogic-Konfiguration kopiert wird, überspringen die Datei tnsnames.ora aus den Kopien, sodass Sie die tnsnames.ora nicht bei jeder nachfolgenden Replikation aktualisieren müssen.

   Der Ansatz ist jedoch anders, wenn die Datenbank eine Autonomous Database ist. Um eine Verbindung zu einer autonomen Datenbank herzustellen, enthält der TNS-Admin-Ordner auch einen Keystore und Truststore-Dateien, die für die Primär- und die Standbydatenbank unterschiedlich sind.

   In der folgenden Tabelle wird zusammengefasst, wie Sie die Informationen zur Datenbankverbindung in jedem Szenario verwalten können:

   Datenbanktyp	Ersetzungsskript und Downloadschritte	Verwendung
   Oracle Base Database Service oder Oracle Exadata Database Service	Das Skript zur Verwaltung von tnsnames.ora ist im WLS-HYDR-Framework-Replikationsmodul enthalten.	Stellen Sie sicher, dass der JDBC-Abschnitt in der Datei replication.properties die richtigen Daten enthält. Dieser Vorgang wird in der Bastion ausgeführt und führt Pull, Update und Push für die Datei tnsnames.ora aus. So führen Sie den vollständigen Vorgang aus: WLS-HYDR/lib/DataReplication.py tnsnames Sie müssen nur ausgeführt werden, wenn Sie Änderungen an tnsnames.ora vornehmen (z.B. einen Alias hinzufügen).
   Autonomous Database	fmwadb_switch_db_conn.sh Gehen Sie zum Oracle MAA-Repository in GitHub https://github.com/oracle-samples/maa Laden Sie alle Skripte im Verzeichnis app_dr_common herunter. Laden Sie alle Skripte im Verzeichnis fmw-wls-with-adb-dr herunter. Auf alle Middle Tier-Hosts kopieren Die Skripte rufen einander an. Platzieren Sie alle Skripte beider Verzeichnisse im selben Ordner.	Dieses Skript muss auf alle Standby-Mid-Tier-Hosts ausgeführt werden. Sie muss ausgeführt werden, bevor die WebLogic-Server in der Standbydatenbank für einen Validierungs-, Switchover- oder Failover-Vorgang gestartet werden. Es ersetzt den von WebLogic verwendeten TNS-Admin-Ordner durch den als Eingabe angegebenen Ordner. Außerdem werden die Wallet-Kennworteigenschaften in den Datenquellen aktualisiert. Syntax zur Ausführung des Skripts: fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD Dabei ist WALLET_DIR ein Ordner, der die Dateien tnsnames.ora, Keystore und Truststore enthält, um eine Verbindung zur lokalen Datenbank herzustellen. Stellen Sie sicher, dass der Ordner WALLET_DIR im Replikat nicht außer Kraft gesetzt wird.

Replikation für rsync mit zentralem Staging validieren

Bei einem Switchover- oder Failover-Vorgang müssen die replizierten Informationen in der Standby Site verfügbar und verwendbar sein, bevor die Prozesse gestartet werden. Dies ist auch erforderlich, wenn Sie das sekundäre System validieren (durch Öffnen der Standbydatenbank im Snapshot-Modus).

In dieser Implementierung ist der Speicher immer auf dem sekundären Standort verfügbar. Sie müssen kein Volume anhängen oder mounten. Die einzige Maßnahme, die Sie benötigen, ist sicherzustellen, dass sie die neueste Version des Inhalts enthält:

1. Replikation ausführen
   Führen Sie die Skripte aus, um die letzte Version des Inhalts zu replizieren.
2. Deaktivieren Sie geplante Replikationen.
   Deaktivieren Sie nach Abschluss des letzten Replikats alle Replikatskripte. Andernfalls kann es die Switchover-, Failover- oder Validierungsprozedur beeinträchtigen. Sie aktivieren die Skripte nach dem Vorgang in der entsprechenden Richtung erneut.
3. Ersetzen Sie die standortspezifischen Informationen auf den sekundären Hosts der mittleren Netzwerkebene.
   Wenn die Dateisystemartefakte, die Sie replizieren, Informationen enthalten, die standortspezifisch sind, stellen Sie sicher, dass sie von der Kopie nicht überschrieben oder nach der Replikation aktualisiert werden.

   Tipp:

   Beispiel: Die rsync-Skripte des Oracle Fusion Middleware Disaster Recovery Guide und des WLS-HYDR-Replikationsmoduls überspringen die Datei tnsnames.ora von der Kopie, sodass Sie sie nach jeder Replikation nicht ändern müssen.

   Wenn das System Oracle Autonomous Database verwendet, stellen Sie den Wallet-Ordner wieder her, der in der sekundären Region erforderlich ist, um eine Verbindung zur Datenbank der sekundären Region herzustellen. Sie können das Ersetzungsskript fmwadb_switch_db_conn.sh in allen Standby-Mid-Tier-Hosts verwenden. Es erfordert als Eingabe den Pfad, in dem sich das sekundäre ursprüngliche Wallet befindet, und das Wallet-Kennwort.

Anschließend können Sie zusätzliche Schritte ausführen, die zur Validierung des Systems erforderlich sind.

Laufende Replikation für rsync mit zentraler Staging Area ausführen

Führen Sie die Replikationsskripte regelmäßig aus, um die sekundäre Domain mit der primären Domain synchron zu halten.

Befolgen Sie die folgenden Empfehlungen für die laufende Replikation, wenn Sie diese Implementierung verwenden:

• Verwenden Sie das Betriebssystem crontab oder ein anderes Planungstool, um die Replikationsskripte regelmäßig auszuführen. Beispiel: Wenn Sie die rsync-Skripte verwenden, die im Disaster Recovery Guide bereitgestellt werden, befolgen Sie die Schritte im Abschnitt Scheduling Ongoing Replication With Rsync Scripts des Oracle Fusion Middleware Disaster Recovery Guide. Weitere Informationen zu diesen und anderen Ressourcen finden Sie unter Weitere Informationen in diesem Handbuch. Befolgen Sie für die Replikationshäufigkeit die Richtlinien, die weiter oben in diesem Playbook unter Dateiartefakte der mittleren Netzwerkebene beschrieben sind.
• Halten Sie die Mid-Tier-Prozesse in der Standby Site gestoppt. Wenn die Server in der Standby Site hochgefahren sind, während die Änderungen repliziert werden, werden die Änderungen beim nächsten Start wirksam. Starten Sie sie nur, wenn Sie die Standby Site validieren oder während der Switchover- oder Failover-Prozeduren.
• Verwalten Sie die Informationen, die für jeden Standort aktuell sind. Beispiel: Wenn das Dateisystem einen Ordner mit den Artefakten enthält, um eine Verbindung zu einer Autonomous Database herzustellen, verwalten Sie eine Backupkopie dieses Ordners. Stellen Sie sicher, dass Sie das Backup des Wallet-Ordners aktualisieren, wenn Sie ein Update im Wallet ausführen. Auf diese Weise wird es bei nachfolgenden Switchover- und Failover-Vorgängen korrekt wiederhergestellt.
• Nach einem Switchover oder Failover reverse die Replikatrichtung. Dies hängt von der konkreten Umsetzung ab. Dies kann mit einer dynamischen Prüfung erfolgen, die angibt, wer die aktive Site ist, oder mit einer manuellen Änderung nach einem Switchover oder Failover, indem die entsprechenden Skripte deaktiviert und aktiviert werden.

  Tipp:

  • Wenn Sie die rsync-Skripte verwenden, die im DR-Handbuch bereitgestellt werden (Beispiel 1), müssen Sie die entsprechenden Skripte erstellen, um das Replikat in die andere Richtung auszuführen. Aktivieren Sie in der crontab-Datei oder im geplanten Tool nur die entsprechenden Skripte für die eigentliche Rolle.
  • Wenn Sie WLS-HYDR (Beispiel 2) verwenden, ändern Sie die Rolle der Primärdatenbank im WLS-HYDR-Framework, sodass die nächsten Replikationen in die andere Richtung gehen. Bearbeiten Sie dazu die WLS-HYRDR/lib/DataReplication.py, und ändern Sie sie wie folgt:

    if True:
           PRIMARY = PREM 
           STANDBY = OCI
          	 else:
    	        PRIMARY = OCI
                   STANDBY = PREM

    in diese:

    if False:
    	        PRIMARY = PREM
                    STANDBY = OCI
           	else:
                    PRIMARY = OCI
                    STANDBY = PREM