Mid-Tier Replikation

Es gibt verschiedene Replikationstechnologien und -methoden für die fortlaufende Replikation der Mid-Tier-Dateiartefakte. Bei den hier beschriebenen Szenarios wird davon ausgegangen, dass die Mid-Tier-Dateisystemartefakte, wie die Ordner config und products, bereits in der sekundären Mid-Tier verfügbar sind.

Es spielt keine Rolle, ob Sie sie während des DR-Setups mit einer bestimmten Technologie kopiert haben. Sie können einen anderen Ansatz für nachfolgende Replikationen während des gesamten Lebenszyklus verwenden.

Zur Dokumentation und Veranschaulichung konzentrieren sich die meisten Beispiele auf ein Oracle WebLogic Server-System, bei dem das primäre ein WLS für OCI-Stack ist und das sekundäre System mit dem WLS-HYDR-Framework erstellt wurde. Als Beispiel für die Verwaltung der spezifischen Informationen der Site verarbeiten die Implementierungen auch die Datenbankverbindungszeichenfolge für die Mid-Tier, vorausgesetzt, die Oracle WebLogic Server-Umgebung verwendet einen TNS-Alias für die Anmeldung bei der Datenbank.

Mid-Tier-Dateiartefakte

Idealerweise sollten Sie alle Dateien, die am Mid-Tier-System beteiligt sind, gleichzeitig vom primären zum sekundären System replizieren.

Unterschiedliche Dateitypen benötigen jedoch möglicherweise unterschiedliche Replikationsfrequenzen, um die Verwaltungskosten zu vereinfachen und die Gesamtbetriebskosten eines Katastrophenschutzsystems zu senken. Dies ist wichtig, wenn Sie die Volumes und Dateisysteme entwerfen, die Sie für die Replikation verwenden möchten. Einige Artefakte sind statisch, während andere dynamisch sind.

  • Produktartefakte

    Produktartefakte sind das oder die Verzeichnisse, in denen die Mid-Tier-Software installiert ist.

    Es ist nicht obligatorisch, die Software am sekundären Standort zu installieren. Wenn der Speicher des Produktionsstandorts auf den Speicher des sekundären Standorts repliziert wird, wird die auf den Volumes des Produktionsstandorts installierte Software auf die Volumes des sekundären Standorts repliziert.

    Ein sekundäres System muss sich bei einem Failover oder Switchover genau so verhalten wie das primäre System. Es sollte Patches und Upgrades als erstklassige Installation zulassen. Das bedeutet, dass das sekundäre System bei einem Failover oder Switchover einen Standardbestand für Patches und Upgrades verwenden muss.

    Die Produktartefakte sind statisch und erfordern in der Regel ein geringes RTO. Sie müssen sie nicht häufig regionsübergreifend kopieren, da sie sich nur ändern, wenn Patches und Fixes eingespielt werden.

    Tipp:

    Beispiel: In einem Oracle WebLogic Server-System ist das Produktartefakt das Oracle Home, in dem die gesamte Oracle-Software installiert ist und von FMW- und Oracle WebLogic-Umgebungsvariablen referenziert wird. Um die Konsistenz aufrechtzuerhalten, müssen Sie Oracle Inventory mit derselben Häufigkeit replizieren wie die Oracle Homes, die von den verschiedenen FMW-Komponenten verwendet werden. Oracle Inventory umfasst die Dateien oraInst.loc und oratab, die sich im Verzeichnis /etc befinden.

  • Konfigurationsartefakte

    Die Konfigurationsartefakte enthalten die Konfiguration der Middle Tier und sind Dateien, die sich häufig ändern. Konfigurationsartefakte ändern sich häufig, je nach Anwendungsupdates. Sie erfordern ein geringes RTO und eine hohe Replikationsfrequenz.

    Tipp:

    Beispiel: In einem WebLogic- oder FMW-System umfassen die Konfigurationsartefakte Folgendes:
    • WebLogic Domain-Home: Domainverzeichnisse des Administrationsservers und der Managed Server.
    • Oracle-Instanzen von Systemkomponenten, wie Oracle HTTP Server: Home-Verzeichnisse der Oracle-Instanz.
    • Anwendungsartefakte, wie .ear- oder .war-Dateien.
    • Datenbankartefakte, wie das MDS-Repository und die Definitionen für persistente JDBC-Speicher.
    • Deployment-Pläne, die zum Aktualisieren von Technologieadaptern wie Datei- und JMS-Adaptern verwendet werden. Sie müssen in einem Verzeichnis gespeichert werden, auf das alle Knoten im Cluster zugreifen können, für das die Artefakte bereitgestellt werden.

    Es ist wichtig, die Konsistenz für Konfigurationsartefakte über verschiedene Speicher hinweg aufrechtzuerhalten. Andernfalls funktionieren Anwendungen möglicherweise nach einem Restore nicht mehr.

    Tipp:

    Beispiel: Die Domainkonfiguration WebLogic, die einen neuen JMS-Server widerspiegelt, muss an der Datenbanktabelle ausgerichtet sein, die als persistenter Speicher verwendet wird. Wenn Sie nur die WebLogic-Domainkonfiguration replizieren, ohne die zugehörige Tabelle zu replizieren, wird ein Oracle WebLogic Server-Fehler verursacht.
  • Laufzeitartefakte

    Laufzeitartefakte sind Dateien, die von Anwendungen zur Laufzeit generiert werden.

    Diese Dateien können sich sehr häufig ändern. Ihre RTO und RPO sind rein von den Geschäftsanforderungen bestimmt. In einigen Fällen müssen diese Artefakte nach kurzer Zeit verworfen werden. Beispiel: Ein Gebotsauftrag, der in einer kurzen Periode abläuft. In anderen Fällen können diese Dateien Transaktionsdatensätze von Vorgängen enthalten, die von einer Anwendung abgeschlossen wurden und beibehalten werden müssen. Wie oft sie repliziert werden müssen und wie wichtig es ist, diese Dateien in einem Katastrophenfall zu speichern, ist in der Regel eine geschäftsorientierte Entscheidung.

    Tipp:

    Beispiele für Laufzeitartefakte in einem WebLogic-System sind die Dateien, die von SOA-Datei- oder FTP-Adaptern generiert werden, die von Oracle MFT verwalteten Dateien oder andere Informationen, die Anwendungen über ihre Geschäftslogik generieren und die direkt im Dateisystem gespeichert werden.

    Die folgende Tabelle enthält eine Zusammenfassung der Empfehlungen zum Replizieren von Dateisystemartefakten während des Lebenszyklus:

    Mid-Tier-Dateiformat Beispiele in WebLogic System Replikationshäufigkeit und Empfehlungen
    Produktartefakte FMW-Home, JDK, Bestand Niedrige Replikationshäufigkeit oder geringer Bedarf (z. B. nach dem Patching). Alternativ können Sie Produkte auch nicht replizieren und separat verwalten, um die Patches zuerst in einer Standbyumgebung zu testen.
    Konfigurationsartefakte WebLogic Domain, Oracle-Instanzen, Anwendungen, Deployment-Pläne, Keystores Die Häufigkeit hängt davon ab, wie oft die Konfigurationsänderungen durchgeführt werden. In der Regel ist eine hohe Replikationsfrequenz erforderlich.
    Laufzeitartefakte Von Datei- und FTP-Adaptern generierte Dateien Durch die Geschäftsanforderungen bestimmt.