1. Hybrid-DR-Lösung für Oracle SOA Suite konfigurieren
  2. Dateisystemartefakte zu OCI replizieren

Dateisystemartefakte zu OCI replizieren

Die sekundären Middle Tiers müssen über ein Replikat der Artefakte verfügen, die von der SOA-Domain in der Primärdatenbank verwendet werden. Die Artefakte können statisch oder dynamisch sein, je nachdem, wie oft sie geändert werden. Im Rahmen des DR-Setups muss eine anfängliche Replikation der Artefakte durchgeführt werden. Dieses anfängliche Replikat wird während des Lebenszyklus des Systems aktualisiert.

Informationen zu Artefakten

Bestimmen Sie den Typ der Artefakte, die Sie replizieren müssen.

  • Statische Artefakte: sind Dateien und Verzeichnisse, die sich nicht häufig ändern. Sie umfassen:
    • Oracle Home: besteht in der Regel aus einem Oracle Home und einem Oracle WebLogic Server Home. Mit Oracle Fusion Middleware können Sie mehrere Oracle WebLogic Server Managed Server aus einer einzelnen Binärdateiinstallation erstellen. Sie können Binärdateien an einem einzigen Speicherort auf einem Shared Storage installieren und diese Installation von Servern in verschiedenen Knoten wiederverwenden. Für maximale Verfügbarkeit empfiehlt Oracle die Verwendung redundanter Binärinstallationen.
    • Oracle Inventory: orainventory ist ein Ordner, der eine Liste der vorhandenen Oracle Homes enthält und sich in einem separaten Ordner befindet, der vom Oracle Home getrennt ist. Die Datei /etc/oraInst.loc bestimmt, welches Verzeichnis der orainventory ist.
  • Dynamische Artefakte: sind Dateien, die sich häufig ändern. Diese Artefakte umfassen:
    • Domain-Home: Domainverzeichnisse des Administration Servers und der Managed Server. In einer EDG-Topologie befindet sich ASERVER_HOME in einem gemeinsamen Speicherort, und MSERVER_HOME befindet sich in einem privaten Speicherort, und jeder Server verfügt über einen eigenen MSERVER_HOME (obwohl er auch in einem NFS gespeichert werden kann).
    • Anwendungsartefakte, wie .ear- oder .war-Dateien.
    • Datenbankartefakte, wie das MDS-Repository und SOAINFRA-Schemas.
    • Persistente Speicher, wie JMS-Provider und Transaktionslogs. Oracle empfiehlt, diese Artefakte in der Datenbank zu speichern. Dies ist der in der EDG-Topologie empfohlene Ansatz, der insbesondere für Disaster Recovery-(DR-)Umgebungen nützlich ist, da diese automatisch über die zugrunde liegende Oracle Data Guard auf die Standbysite repliziert werden.
    • Deployment-Pläne für die Aktualisierung von Technologieadaptern wie Datei- und JMS-Adaptern. Sie müssen in einem Speicherort gespeichert werden, auf den alle Knoten im Cluster zugreifen können, in denen die Artefakte bereitgestellt werden.
    • Andere Laufzeitartefakte, wie von Dateiadaptern verwendete Dateien, von MFT übertragene Dateien oder andere benutzerdefinierte Laufzeitartefakte.

Alle Inhalte in der Datenbank (wie das MDS-Repository, SOAINFRA-Schemas, JMS- und TLOGs sowie benutzerdefinierte Daten) werden automatisch über Oracle Data Guard auf die sekundäre Site repliziert.

Um den Inhalt im Dateisystem (wie Oracle Home und die Domainkonfiguration WebLogic) in einer Disaster Recovery-Topologie zu replizieren, können Sie verschiedene Ansätze verwenden. Die häufigsten Replikationen sind Replikation auf Speicherebene, rsync-basiertes Replikat oder DBFS-basiertes Replikat.

Das hier beschriebene Hybrid-DR-Modell ist der Ort, an dem sich das Primärmodell On Premise und das Sekundärmodell in OCI befindet. Die Replikation auf Speicherebene ist im hybriden DR-Modell nicht verfügbar. Stattdessen ist rsync der empfohlene Ansatz zur Replikation der Artefakte von der Primär- in die Standbydatenbank. Sie können das auf Oracle Database File System (DBFS) basierende Replikat verwenden, um einige Artefakte zu replizieren. Weitere Informationen finden Sie unter Informationen zum Oracle Database-Dateisystem.

Ordner und Dateisystemartefakte identifizieren

Identifizieren Sie die NFS-Volumes und -Ordner, die von den primären SOA-Hosts der primären Umgebung und ihres Inhalts verwendet werden.

Die folgenden Tabellen enthalten ein Beispiel für die primären Dateisystemartefakte, die in diesem Beispiel verwendet werden.

Dateisystem-Volume Host Mount Point-Ordner Kommentare Artefakttyp
NFS VOLFMW1 /export/soa/products1 SOOST1 /u01/oracle/products Volume für die JDK- und FMW-Binärdateien. Statisch
NFS VOLFMW2 /export/soa/products2 SOOST2 /u01/oracle/products Volume für die JDK- und FMW-Binärdateien. Statisch
NFS-VOLUME-ADMIN/export/soa/config SOAHOST1, SOAHOST2 /u01/oracle/config Volume für das Domainverzeichnis des Administrationsservers und andere gemeinsam verwendete Konfigurationen, wie Deployment-Pläne, Anwendungen und Keystores. Dynamisch
LOKAL* /u02/oracle/config SOOST1 /u02/oracle/config Volume für private Konfiguration in SOAHOST1 Dynamisch
LOKAL* /u02/oracle/config SOOST2 /u02/oracle/config Volume für private Konfiguration in SOAHOST2 Dynamisch
NFS-VOLLAUFZEIT /export/soa/runtime SOAHOST1, SOAHOST2 /u01/oracle/runtime

Volume für gemeinsam verwendeten Laufzeitinhalt, wie Dateien, die von Dateiadaptern verwendet werden, und andere Laufzeitartefakte.

Hinweis: Es wird empfohlen, JMS-Nachrichten und TLOGS in der Datenbank unter Verwendung von persistenten JDBC-Speichern anstelle in diesem Ordner zu speichern.

Dynamisch

* Bei den lokalen Dateisystem-Volumes kann es sich um private (nicht gemeinsam genutzte) Mounts in NFS anstelle von lokalem Speicher handeln.

Die folgende Tabelle zeigt ein Beispiel für die EDG-Variablen für Ordnerspeicherorte.

EDG-Variablen Wert
ORACLE_BASE /u01/oracle/products
ORACLE_HOME /u01/oracle/products/fmw
JAVA_HOME /u01/oracle/products/jdk
SHARED_CONFIG_DIR /u01/oracle/config
APPLICATION_HOME /u01/oracle/config/applications/mysoadomain
DEPLOY_PLAN_HOME /u01/oracle/config/dp
KEYSTORE_HOME /u01/oracle/config/keystores
ASERVER_HOME /u01/oracle/config/domains/mysoadomain
PRIVATE_CONFIG_DIR /u02/oracle/config
MSERVER_HOME /u02/oracle/config/domains/mysoadomain
NM_HOME /u02/oracle/config/nodemanager
ORACLE_RUNTIME /u01/oracle/runtime

Konnektivität zwischen dem primären und dem Standbyhost prüfen

Die primären SOA-Hosts müssen eine Verbindung zu den Remote Standby-Oracle Cloud Infrastructure-(OCI-)SOA-Hosts herstellen und umgekehrt.

Die physischen Namen der Remote-SOA-Hosts können in DNS aufgelöst werden. Sie können auch die physischen Namen und IPs der Remote-Peer-SOA-Hosts in die /etc/hosts-Dateien aufnehmen. Das heißt, fügen Sie die physischen Namen und deren IPs der sekundären SOA-Hosts zur Datei /etc/hosts der primären SOA-Hosts hinzu. Entsprechend fügen Sie die physischen Namen und deren IPs der primären SOA-Hosts zur Datei /etc/hosts der sekundären SOA-Hosts hinzu.

Hinweis:

Wenn die primäre Instanz keine virtuellen Hostnamen verwendet und die physischen Knotenhostnamen als Listening-Adressen für die Server verwendet, führen Sie diese Schritte nicht aus. Da in diesem Szenario die primären physischen Knotenhostnamen von den OCI-SOA-Host-IPs in Standby aufgelöst werden müssen. In diesem Szenario verwenden Sie die IPs der Hosts für die Verbindung mit SSH zu den Remoteknoten, anstatt die folgenden Schritte auszuführen.
  1. Bearbeiten Sie die Datei /etc/hosts in den primären On-Premise-SOA-Hosts, um die physischen Namen und IP-Adressen der Remote-Peer-SOA-Hosts einzubeziehen.
    Im Folgenden finden Sie ein Beispiel für die Aliasnamen auf den On-Premise-Hosts.
    
#################################
# ALIASES in on-prem
#################################
10.10.10.20   host-vip1.myopnetwork.com    host-vip1          ADMINVHN.example.com   ADMINVHN 
10.10.10.13   host3.myopnnetwork.com       host3              SOAHOST1.example.com    SOAHOST1
10.10.10.14   host4.myopnnetwork.com       host4              SOAHOST2.example.com    SOAHOST2
# Front-end name (resolved but primary Load Balancer IP
10.10.10.100    mysoa.example.com
# Remote OCI soa hosts physical names (without virtual host name aliases!)
100.70.10.13    hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com      hydrsoa1        
100.70.10.14   hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com       hydrsoa2
  2. Bearbeiten Sie die Datei /etc/hosts auf den OCI-SOA-Standbyhosts, um die physischen Namen der Remote-, On-Premise-SOA-Hosts einzubeziehen. Geben Sie die Aliasnamen des virtuellen Hostnamens nicht an.
    Im Folgenden finden Sie ein Beispiel für die Aliasnamen auf den OCI-SOA-Standbyhosts. 
    #################################
# ALIASES in OCI
#################################
100.70.10.20   hydrsoa-vip.midTiersubnet.hydrvcn.oraclevcn.com   hydrsoa-vip    ADMINVHN.example.com    ADMINVHN
100.70.10.13   hydrsoa1.midtiersubnet.hydrvcn.oraclevcn.com      hydrsoa1       SOAHOST1.example.com    SOAHOST1
100.70.10.14   hydrsoa2.midtiersubnet.hydrvcn.oraclevcn.com      hydrsoa2       SOAHOST2.example.com    SOAHOST2
# Front-end name (resolved by secondary OCI LBR IP)
1070.70.70    mysoa.example.com
# Remote on-prem soa hosts physical names (without virtual host name aliases!)
10.10.10.13   host3.myopnnetwork.com       host3
10.10.10.14   host4.myopnnetwork.com       host4
  3. Mit dem SSH-Befehl können Sie die Crossconnectivity von den primären On-Premise-SOA-Hosts zu den sekundären OCI-SOA-Hosts prüfen.
    Für die Verbindung mit OCI-Compute-Instanzen ist ein SSH-Schlüssel erforderlich.
    ssh -i my_private_key oracle@hydrsoa1.midtiersubnet.hydrvcn.oraclevcn.com
ssh -i my_private_key oracle@hydrsoa2.midtiersubnet.hydrvcn.oraclevcn.com
  4. Mit dem SSH-Befehl können Sie die Crossconnectivity zwischen den sekundären OCI-SOA-Hosts und den primären On-Premise-SOA-Hosts prüfen.
    Möglicherweise ist kein SSH-Schlüssel erforderlich.
    ssh  oracle@host3.myopnnetwork.com
ssh  oracle@host4.myopnnetwork.com

Ordnerstruktur auf sekundären OCI-Hosts duplizieren

Zu diesem Zeitpunkt ist der FSS bereits in den Oracle Cloud Infrastructure-(OCI-)SOA-Compute-Instanzen gemountet. Bevor Sie den Inhalt replizieren, erstellen Sie die entsprechende Ordnerstruktur für das EDG.

Das folgende Beispiel zeigt die Befehle zum Erstellen der EDG-Ordnerstruktur, die von der EDG-Umgebung dieses Dokuments verwendet wird.
  1. Erstellen Sie als Benutzer oracle die Ordner in OCI SOAHOST1.
    mkdir -p  /u01/oracle/products/fmw
mkdir -p  /u01/oracle/products/jdk
mkdir -p  /u01/oracle/products/oraInventory
mkdir -p /u02/oracle/config
mkdir -p /u01/oracle/config/domains/mysoadomain
mkdir -p /u01/oracle/config/applications/mysoadomain
mkdir -p /u01/oracle/config/dp/mysoadomain
mkdir -p /u01/oracle/config/keystores
  2. Erstellen Sie als Benutzer oracle die Ordner in OCI SOAHOST2.
    mkdir -p  /u01/oracle/products/fmw
mkdir -p  /u01/oracle/products/jdk
mkdir -p  /u01/oracle/products/oraInventory
mkdir -p /u02/oracle/config

Kopieren Sie ORACLE_HOME und JAVA_HOME auf die sekundären Hosts

Kopieren Sie ORACLE_HOME und JAVA_HOME von den primären Hosts in die sekundären Hosts.

ORACLE_HOME und JAVA_HOME befinden sich in der Regel im selben Produktordner wie oraInventory. Informationen zu den zuvor identifizierten Speicherorten finden Sie unter Ordner und Dateisystemartefakte identifizieren.

  1. Kopieren Sie den Produktordner aus dem primären On-Premise-SOAHOST1 in den Remote-SOAHOST1.
  2. Kopieren Sie den Home-Ordner für Produkte aus dem primären On-Premise-SOAHOST2, und speichern Sie ihn im Remote-SOAHOST2. Wiederholen Sie den Vorgang für alle anderen Compute-Instanzen.
  3. Kopieren Sie die Datei /etc/oraInst.loc von den primären Hosts, und speichern Sie sie auf den sekundären Hosts.
    Diese Datei enthält nur den Speicherort oraInventory und ändert sich im Laufe der Zeit nicht. Daher ist diese Kopie eine einmalige Aktion.

    Im angegebenen Beispiel befindet sich oraInventory unter /u01/oracle/products und wird zusammen mit jdk und dem Oracle Home kopiert. Wenn sich Ihr oraInventory an einem anderen Speicherort befindet, müssen Sie ihn auch auf die sekundären Hosts kopieren.

    Hinweis:

    Sie finden ein Beispielskript, das rsync verwendet, um den Produktordner vom primären On-Premise-SOAHOST1 in den Remote-SOAHOST1 unter Code herunterladen zu kopieren. Wiederholen Sie diesen Vorgang, um die Produkte in das Home-Verzeichnis der restlichen sekundären Compute-Instanzen zu kopieren (d.h. von SOAHOST2 in Remote-SOAHOST2).

Domainkonfigurationsordner WebLogic auf die Standbyhosts kopieren

Kopieren Sie den freigegebenen Konfigurationsordner der Domain WebLogic und den privaten Konfigurationsordner in die Oracle Cloud Infrastructure-(OCI-)SOA-Hosts.

  1. Kopieren Sie den freigegebenen Konfigurationsordner der Domain WebLogic aus dem primären On-Premise-SOAHOST1 in den Remote-OCI-Ordner SOAHOST1.
    Die gemeinsame Domainkonfiguration WebLogic befindet sich in dem von der Variablen SHARED_CONFIG_DIR entworfenen Verzeichnis und enthält die gemeinsamen Konfigurationsordner wie APPLICATION_HOME, DEPLOY_PLAN_HOME, KEYSTORE_HOME und ASERVER_HOME.

    Hinweis:

    Sie können den freigegebenen Konfigurationsordner aus dem primären On-Premise-SOAHOST1 in den Remote-SOAHOST1 kopieren. Dies ist ein freigegebener Ordner. Daher müssen Sie ihn nur in einen der OCI-SOA-Hosts kopieren.

    Ein Beispielskript ist unter Code herunterladen verfügbar.

  2. Kopieren Sie den privaten Konfigurationsordner der Domain WebLogic der primären On-Premise-Instanz SOAHOST1, und speichern Sie ihn in der Remote-OCI-Instanz SOAHOST1
    Die private WebLogic-Konfiguration befindet sich in dem von der Variablen PRIVATE_CONFIG_DIR angegebenen Verzeichnis und enthält die Ordner MSERVER_HOME und NM_HOME. Diese Ordner werden nicht gemeinsam verwendet, sie sind spezifisch (privat) für jeden SOA-Host. Daher müssen Sie die Kopie für jeden Server ausführen. Sie müssen die private Konfiguration von On-Premise-SOAHOST1 in OCI-SOAHOST1, die private Konfiguration von On-Premise-SOAHOST2 in OCI-SOAHOST2 usw. kopieren.

    Hinweis:

    Unter Code herunterladen finden Sie ein Beispielskript, das rsync verwendet, um den privaten Konfigurationsordner vom primären On-Premise-SOAHOST1 in den Remote-SOAHOST1 zu kopieren.

Shared Runtime-Ordner kopieren

Kopieren Sie bei Bedarf den freigegebenen Laufzeitordner in die Oracle Cloud Infrastructure-(OCI-)SOA-Hosts.

Der freigegebene Laufzeitordner befindet sich in dem durch die Variable ORACLE_RUNTIME angegebenen Verzeichnis. Informationen zu den zuvor identifizierten Speicherorten finden Sie unter Ordner und Dateisystemartefakte identifizieren.

Hinweis:

Es wird empfohlen, die persistenten JMS-Speicher und TLOGS-Speicher in der Datenbank mit persistenten JDBC-Speicher zu speichern. Da sie sich in der Datenbank befinden, werden sie automatisch auf dem sekundären System mit Oracle Data Guard repliziert.
  • Da dies Laufzeitinformationen sind, müssen Sie diese normalerweise nicht während der Einrichtungsphase replizieren. Wenn Sie diesen Ordner jedoch auf die Standbyhosts replizieren müssen, können Sie den Inhalt nach einer ähnlichen Methode kopieren, die Sie zum Kopieren der gemeinsam genutzten Konfigurationsdatei der Domain WebLogic verwendet haben.