Peer-to-Peers-rsync-Replikation implementieren

Diese Implementierung verwendet die rsync-Technologie und folgt dem Peer-to-Peer-Modell. In diesem Modell erfolgt die Kopie direkt zwischen den Middle Tier-Peer-Hosts. Jeder Knoten verfügt über SSH-Konnektivität zu seinem Peer und verwendet rsync-Befehle über SSH, um die primären Mid-Tier-Dateiartefakte zu replizieren.

Die Implementierung der Peer-to-Peer-Replikation rsync bietet folgende Vorteile:

• 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.
• Es benötigt keine zusätzliche Hardware, wie einen zentralen Host oder Speicher.
• 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.

Überlegungen zur Implementierung des Peer-to-Peers rsync:

• 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.
• Da Skripte nicht zentralisiert sind, ist eine Wartung über viele Knoten hinweg erforderlich. Daher ist die Lösung in großen Clustern komplexer.

Die Peer-to-Peer-Skripte rsync können 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 Dateien vom lokalen Knoten auf den Remote-Knoten. Wenn die rsync-Skripte auf den Knoten mit der Standbyrolle ausgeführt werden, führen sie einen "Pull"-Vorgang aus, um den Inhalt aus der Primärdatenbank abzurufen. Wenn die rsync-Skripte auf den Knoten mit der primären Rolle ausgeführt werden, führen sie einen Pushvorgang aus, um den Inhalt in die sekundären Knoten zu kopieren. Oracle empfiehlt das Pull-Modell für Peer-to-Peer. Auf diese Weise verwenden die rsync-Skripte weniger Ressourcen der Hosts des primären Systems, da alle Vorgänge der Kopie (z.B. der checksum-Vergleich der Kopie) auf den sekundären Knoten ausgeführt werden.

Replikation für rsync Peer-to-Peer einrichten

Um das Peer-to-Peer-Modell rsync zu implementieren, ist Folgendes erforderlich:

• SSH-Konnektivität zwischen den Hosts und den zugehörigen Peerhosts zulassen.
• Erstellen Sie Skripte, die rsync verwenden, um die Mid-Tier-Dateiartefakte von primären auf sekundäre Hosts zu kopieren. Die rsync-Skripte können bestimmte Ordner aus der Kopie überspringen (wie Sperrdateien, Logs, temporäre Dateien usw.)
• Implementieren Sie eine Möglichkeit, die standortspezifischen Informationen zu verwalten, indem Sie diese Informationen entweder aus der Kopie ausschließen oder sie mit den entsprechenden Informationen nach dem Replikat aktualisieren.
• 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).

Beispiel 1: rsync-Skripte des Oracle Fusion Middleware Disaster Recovery Guide für die Peer-to-Peer-Replikation verwenden

Hinweis:

Dieses Beispiel gilt für alle Mid-Tier-Systeme. Es verwendet die von Oracle Fusion Middleware Disaster Recovery Guide bereitgestellten Skripte, um das Mid-Tier-Replikat für ein 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 beliebige Mid-Tier-Dateiartefakte in OCI zu synchronisieren. Weitere Informationen finden Sie unter Weitere Informationen zu diesen und anderen Ressourcen.

In diesem Beispiel stellt jeder Host auf dem sekundären Standort eine Verbindung zu seinem primären Peerknoten her und führt einen Pull des Inhalts durch. 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 Peer-to-Peer.

Beschreibung der Abbildung dr-scripts-peer-peer.png

dr-scripts-peer-peer-oracle.zip

Replikation für rsync Peer-to-Peer 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 in der Standbydatenbank 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 überspringen die Datei tnsnames.ora aus 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.

Laufende Replikation für rsync Peer-to-Peer durchführen

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

Befolgen Sie diese Empfehlungen, wenn Sie rsync von den Mid-Tier-Hosts 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 Oracle Fusion Middleware Disaster Recovery Guide bereitgestellt werden, führen Sie die Schritte aus, die im Abschnitt Scheduling Ongoing Replication With Rsync Scripts beschrieben werden. 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 unter Mid-Tier-Dateiartefakte am Anfang dieses Playbooks beschrieben werden.
• 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.
• Die für jede Site spezifischen Informationen auf dem neuesten Stand halten. 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. Beispiel: Stellen Sie bei den rsync-Skripten, die vom Oracle Fusion Middleware Disaster Recovery Guide bereitgestellt werden, sicher, dass Sie die entsprechenden Skripte erstellen, um das Replikat in die andere Richtung auszuführen. Aktivieren Sie im crontab- oder geplanten Tool nur die entsprechenden Skripte für die eigentliche Rolle.