1. Konfigurieren einer hybriden DR-Lösung für Oracle WebLogic Server
  2. Dateisystemartefakte in OCI replizieren

Dateisystemartefakte in OCI replizieren

Die sekundären Middle Tiers müssen über ein Replikat der Artefakte verfügen, die von der Domain WebLogic Server in der primären Domain 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. Diese 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ärdatei-Installation erstellen. Sie können Binärdateien an einem einzigen Speicherort in einem Shared Storage installieren und diese Installation von Servern auf verschiedenen Knoten wiederverwenden. Für maximale Verfügbarkeit empfiehlt Oracle die Verwendung von redundanten 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 den Speicherort von orainventory.
  • Dynamische Artefakte: sind Dateien, die sich häufig ändern. Zu diesen Artefakten gehören:
    • Domain-Home: Domainverzeichnisse des Administrationsservers und der Managed Server. In einer EDG-Topologie befindet sich ASERVER_HOME in einem gemeinsam verwendeten Verzeichnis, und MSERVER_HOME befindet sich in einem privaten Verzeichnis, und jeder Server hat 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 Anwendungsschemas.
    • Persistente Speicher wie JMS-Provider und Transaktionslogs. Oracle empfiehlt, diese Artefakte in der Datenbank zu speichern. Dieser Ansatz wird in der EDG-Topologie empfohlen und ist insbesondere für Disaster Recovery-(DR-)Umgebungen nützlich, da sie 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 Verzeichnis gespeichert werden, auf das alle Knoten im Cluster zugreifen können, in denen die Artefakte bereitgestellt werden.
    • Andere Laufzeitartefakte, wie Dateien, die von Dateiadaptern verwendet werden, Dateien, die von MFT übertragen werden, oder andere benutzerdefinierte Laufzeitartefakte.

Alle Inhalte in der Datenbank (wie das MDS-Repository, Anwendungsschemas, JMS- und TLOG-Schemas 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 WebLogic Server-Hosts der primären Umgebung und deren Inhalt 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/wls/products1 APPHOST 1 /u01/oracle/products Volume für die JDK- und FMW-Binärdateien. Statisch
NFS VOLFMW2 /export/wls/products2 APPHOST 2 /u01/oracle/products Volume für die JDK- und FMW-Binärdateien. Statisch
NFS-VOLUME-ADMIN/export/wls/config APPHOST1, APPHOST2 /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 APPHOST 1 /u02/oracle/config Volume für private Konfiguration in APPHOST1 Dynamisch
LOKAL* /u02/oracle/config APPHOST 2 /u02/oracle/config Volume für private Konfiguration in APPHOST2 Dynamisch
NFS-VOLLAUFZEIT /export/wls/runtime APPHOST1, APPHOST2 /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 mit persistenten JDBC-Speichern anstelle in diesem Ordner zu speichern.

Dynamisch

* Die lokalen Dateisystem-Volumes können private (nicht gemeinsam genutzte) Mounts in NFS anstelle von lokalem Speicher sein.

Die folgende Tabelle ist 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/mydomain
DEPLOY_PLAN_HOME /u01/oracle/config/dp
KEYSTORE_HOME /u01/oracle/config/keystores
ASERVER_HOME /u01/oracle/config/domains/mydomain
PRIVATE_CONFIG_DIR /u02/oracle/config
MSERVER_HOME /u02/oracle/config/domains/mydomain
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 WebLogic Server-Hosts müssen eine Verbindung zu den Remote Standbyhosts von Oracle Cloud Infrastructure (OCI) WebLogic Server herstellen und umgekehrt.

Die physischen Namen der Remotehosts des WebLogic-Servers können in DNS aufgelöst werden, oder Sie können den Remotepeer WebLogic-Server als Host für physische Namen und IPs in die /etc/hosts-Dateien aufnehmen. Das heißt, fügen Sie die sekundären WebLogic Server-Hosts mit physischen Namen und deren IPs zur Datei /etc/hosts der primären WebLogic Server-Hosts hinzu. Fügen Sie in ähnlicher Weise die physischen Namen und deren IPs der primären WebLogic Server-Hosts zur Datei /etc/hosts der sekundären WebLogic Server-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 Hostnamen der primären physischen Knoten von den OCI-WebLogic-Server-Hosts-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-Hosts des WebLogic-Servers, um die physischen Namen und IP-Adressen der Remote-Peer-Hosts des WebLogic-Servers 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              APPHOST1.example.com    APPHOST1
10.10.10.14   host4.myopnnetwork.com       host4              APPHOST2.example.com    APPHOST2
# Front-end name (resolved but primary Load Balancer IP
10.10.10.100    wlsfrontend.example.com
# Remote OCI wls hosts physical names (without virtual host name aliases!)
100.70.10.13    hydrwls1.midTiersubnet.hydrvcn.oraclevcn.com      hydrwls1        
100.70.10.14   hydrwls2.midTiersubnet.hydrvcn.oraclevcn.com       hydrwls2
  2. Bearbeiten Sie die Datei /etc/hosts in den Standby-OCI-Hosts des WebLogic-Servers, um die physischen Namen der Remotehosts des On-Premise-WebLogic-Servers einzubeziehen. Geben Sie die Aliasnamen des virtuellen Hostnamens nicht an.
    Im Folgenden finden Sie ein Beispiel für die Aliasnamen auf den Standby-OCI-Hosts WebLogic Server. 
    #################################
# ALIASES in OCI
#################################
100.70.10.20   hydrwls-vip.midTiersubnet.hydrvcn.oraclevcn.com   hydrwls-vip    ADMINVHN.example.com    ADMINVHN
100.70.10.13   hydrwls1.midtiersubnet.hydrvcn.oraclevcn.com      hydrwls1       APPHOST1.example.com    APPHOST1
100.70.10.14   hydrwls2.midtiersubnet.hydrvcn.oraclevcn.com      hydrwls2       APPHOST2.example.com    APPHOST2
# Front-end name (resolved by secondary OCI LBR IP)
1070.70.70    wlsfrontend.example.com
# Remote on-prem wls 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-Hosts des WebLogic-Servers zu den sekundären OCI-Hosts des WebLogic-Servers prüfen.
    Für die Verbindung mit OCI-Compute-Instanzen ist ein SSH-Schlüssel erforderlich.
    ssh -i my_private_key oracle@hydrwls1.midtiersubnet.hydrvcn.oraclevcn.com
ssh -i my_private_key oracle@hydrwls2.midtiersubnet.hydrvcn.oraclevcn.com
  4. Mit dem SSH-Befehl können Sie die Crossconnectivity zwischen den sekundären OCI-Hosts des WebLogic-Servers und den primären On-Premise-Hosts des WebLogic-Servers 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 sind die Oracle Cloud Infrastructure-(OCI-)Compute-Instanzen WebLogic Server bereits mit FSS 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 APPHOST1.
    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/mydomain
mkdir -p /u01/oracle/config/applications/mydomain
mkdir -p /u01/oracle/config/dp/mydomain
mkdir -p /u01/oracle/config/keystores
  2. Erstellen Sie als Benutzer oracle die Ordner in OCI APPHOST2.
    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-APPHOST1 in den Remote-APPHOST1.
  2. Kopieren Sie den Home-Ordner für Produkte aus dem primären On-Premise-Ordner APPHOST2, und speichern Sie ihn in dem Remoteordner APPHOST2. Wiederholen Sie den Vorgang für alle anderen Compute-Instanzen.
  3. Kopieren Sie die Datei /etc/oraInst.loc aus den primären Hosts, und speichern Sie sie auf den sekundären Hosts.
    Diese Datei enthält lediglich den Speicherort von 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 Oracle Home kopiert. Wenn sich Ihr oraInventory in einem anderen Speicherort befindet, müssen Sie sicherstellen, dass Sie ihn auch in die sekundären Hosts kopieren.

    Hinweis:

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

Domainkonfigurationsordner WebLogic auf die Standbyhosts kopieren

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

  1. Kopieren Sie den freigegebenen Konfigurationsordner der Domain WebLogic aus dem primären On-Premise-APPHOST1 in den Remote-OCI-Ordner APPHOST1.
    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-APPHOST1 in den Remote-APPHOST1 kopieren. Dies ist ein freigegebener Ordner. Daher müssen Sie ihn nur auf einen der OCI WebLogic Server-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 APPHOST1, und speichern Sie ihn in der Remote-OCI-Instanz APPHOST1
    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 WebLogic Server-Host. Daher müssen Sie die Kopie für jeden Server ausführen. Sie müssen die private Konfiguration von On-Premise-APPHOST1 auf OCI APPHOST1, die private Konfiguration von On-Premise-APPHOST2 auf OCI-APPHOST2 usw. kopieren.

    Hinweis:

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

Freigegebenen Laufzeitordner kopieren

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

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-Speichern zu speichern. Da sie sich in der Datenbank befinden, werden sie mit Oracle Data Guard automatisch auf das sekundäre System 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.