1. Hybrid-DR-Lösung für Oracle SOA Suite konfigurieren
  2. Web-Tier auf OCI vorbereiten

Web-Tier auf OCI vorbereiten

Stellen Sie Ihre sekundäre Site auf Oracle Cloud Infrastructure (OCI) bereit, und konfigurieren Sie sie so, dass sie mit Ihrer primären On-Premise-Site konsistent ist.

Hinweis:

Sie finden den Terraform-Code zum Erstellen der in diesem Abschnitt beschriebenen Ressourcen (OCI Load Balancer, SSL-Zertifikat, Backend-Sets und -Backends, Routing-Policys, Listener und Regelsets) unter Code herunterladen.

(Optional) Oracle HTTP Server-Hosts vorbereiten

Erstellen und konfigurieren Sie die Oracle HTTP Server-Compute-Instanzen in Oracle Cloud Infrastructure.

Hinweis:

Das Erstellen und Konfigurieren von Oracle HTTP Server ist optional. Sie können die Web-Tier auf OCI nur mit dem OCI Load Balancer konfigurieren (ohne Oracle HTTP Server zu verwenden).

Oracle HTTP Server-Hosts bereitstellen

Erstellen Sie eine Compute-Instanz im Oracle Cloud Infrastructure-(OCI-)Web-Tier-Subnetz für jeden primären On-Premise-Oracle HTTP Server-Host. Die Compute-Instanzen müssen das BS-Image und die Compute-Ausprägung verwenden, die dem Image und der Ausprägung ähneln, die von den On-Premise-Hosts von Oracle HTTP Server verwendet werden.

Jeder in OCI ausgeführte Oracle HTTP Server muss zusätzlich zum Lizenz- und Supportvertrag einen gültigen Lizenz- und Supportvertrag haben, der für den On-Premises ausgeführten Oracle HTTP Server verwendet wird. Mit Oracle WebLogic Server für OCI-Images können Sie Compute-Instanzen für Oracle HTTP Server in Oracle Cloud erstellen. Die mit diesen Images erstellten Compute-Instanzen umfassen die Berechtigung zur Ausführung von Oracle HTTP Server und werden pro OCPU/Stunde für die Berechtigung zur Ausführung der WebLogic-Software in Rechnung gestellt, wenn sie sich im Ausführungsstatus befinden. Wenn Sie die Compute-Instanzen mit Oracle WebLogic Server for OCI erstellen, können Sie die Compute-Instanzkonsole oder den Marketplace verwenden. Diese Images sind für die Betriebssysteme Oracle Linux 7.9 und Oracle Linux 8.5 verfügbar.

In diesem Beispiel werden zwei Compute-Instanzen in einer einzelnen Availability-Domain innerhalb des Compartments verwendet, wie in der Tabelle dargestellt.

Name Compartment Availability-Domain Bild Form VCN Subnetz
hydrohs1 HyDRCompmt AD1 Oracle WebLogic Enterprise Edition UCM-Image (Oracle Linux 7.9) VM.Standard2.2 Hydrvcn webTierSubnet
hydrohs2 HyDRCompmt AD1 Oracle WebLogic Enterprise Edition UCM-Image (Oracle Linux 7.9) VM.Standard2.2 Hydrvcn webTierSubnet

Führen Sie die folgenden Schritte aus, um die Compute-Instanzen mit der Compute-Instanzkonsole bereitzustellen:

  1. Melden Sie sich in der OCI-Konsole für Ihren Mandanten an.
  2. Wählen Sie den richtigen Bereich aus.
  3. Klicken Sie auf das Navigationsmenü, und wählen Sie Compute aus. Klicken Sie auf Instanzen und dann auf Instanz erstellen.
  4. Geben Sie Namen für die Compute-Instanz und das Compartment ein.
  5. Wählen Sie unter Platzierung die Availability-Domain aus, in der die Instanz erstellt werden soll. Wenn die OCI-Region mehrere Availability-Domains umfasst, können Sie die WebLogic-Compute-Instanzen in verschiedenen Availability-Domains platzieren.
  6. Klicken Sie unter Image und Ausprägung auf Image ändern, und führen Sie folgende Schritte aus:
    1. Wählen Sie in der Dropdown-Liste "Imagequelle" die Option Oracle-Images und dann Oracle WebLogic Server Enterprise Edition UCM-Image aus der Liste der Oracle WebLogic Server for OCI-Images aus.
    2. Klicken Sie für das ausgewählte Image auf den Pfeil auf der rechten Seite, und wählen Sie die Image-Build-Version für die kostenpflichtigen Images aus.
      • Oracle Linux 7.9 (mit dem Label release-ol7.9-build-timestamp)
      • Oracle Linux 8.5 (mit dem Label release-ol8.5-build-timestamp)
    3. Prüfen Sie die Vertragsbedingungen. Aktivieren Sie das Kontrollkästchen Oracle-Nutzungsbedingungen, und klicken Sie auf Image auswählen.
  7. Klicken Sie unter Image und Ausprägung auf Ausprägung ändern. Wählen Sie den Instanztyp aus, und wählen Sie die Ausprägung aus, die den primären Hosts am ähnlichsten ist.
    Eine Liste der unterstützten Ausprägungen finden Sie unter Images für Oracle WebLogic Server für OCI.
  8. Wählen Sie das VCN, das Subnetz (Web-Tier-Subnetz) und die Availability-Domain Ihrer Umgebung aus.
    Um Kapazitätstyp und Faultdomain anzugeben, klicken Sie auf Erweiterte Optionen anzeigen.
  9. Konfigurieren Sie das Netzwerk für die Instanz. Um erweiterte Netzwerkeinstellungen anzugeben, klicken Sie auf Erweiterte Optionen anzeigen.
  10. Generieren Sie unter SSH-Schlüssel hinzufügen einen Schlüssel, laden Sie Ihren Public Key hoch, oder fügen Sie die Schlüssel ein.
  11. Geben Sie unter "Boot-Volume" die Größen- und Verschlüsselungsoptionen für das Boot-Volume der Instanz an.
  12. Klicken Sie auf Erweiterte Optionen anzeigen, um erweiterte Einstellungen zu konfigurieren.
  13. Klicken Sie auf Erstellen.
  14. Wiederholen Sie die Schritte, um eine weitere Compute-Instanz zu erstellen.

Betriebssystembenutzer und -gruppen vorbereiten

In den sekundären Compute-Instanzen sind derselbe Benutzer und die gleiche Gruppe erforderlich, die auch von der primären On-Premise-Software von Oracle verwendet werden.

Oracle WebLogic Server for Oracle Cloud Infrastructure-Images haben bereits einen Benutzer und eine Gruppe "oracle". Diese Werte (Benutzername, Gruppenname, uid und gid) stimmen jedoch möglicherweise nicht mit den Werten in der primären Instanz überein. Sie müssen die sekundären Hosts so konfigurieren, dass sie mit den Werten des primären Benutzers "oracle" und der primären Gruppe übereinstimmen. Die folgenden Beispiele zeigen, wie die sekundären Hosts in dieser Tier so konfiguriert werden, dass sie mit den Werten des primären Benutzers oracle und der primären Gruppe übereinstimmen.

Jede Gruppe und jeder Benutzer in OCI-Compute-Instanzen muss dieselbe ID auf jedem Knoten und dieselbe ID wie in der Primärinstanz aufweisen.
  1. Identifizieren Sie den Benutzer, die Gruppe und die IDs des Benutzers "oracle" auf den primären Hosts, indem Sie sich mit dem Benutzer oracle bei einem On-Premise-Host anmelden und dann den Befehl id verwenden.
    [oracle@host3.myopnetwork.com ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)

[oracle@host3.myopnetwork.com ~]$ more /etc/passwd | grep oracle
oracle:x:1001:1002::/home/oracle:/bin/bash

    In der folgenden Tabelle sind Beispielbenutzer und -gruppen für eine typische On-Premise-Umgebung aufgeführt.

    Benutzer oder Gruppe Name ID Beschreibung
    Benutzer oracle 1001 Der Eigentümer von Oracle-Software
    Gruppen oinstall 1002 Principal-Gruppe des oracle-Benutzers
    dba 1001 Sekundäre Gruppe des Benutzers oracle
  2. Identifizieren Sie die Benutzer, Gruppen und IDs, die in den sekundären Hosts vorhanden sind, indem Sie mit SSH auf die zuletzt erstellte Instanz als Benutzer opc zugreifen. Melden Sie sich bei einem sekundären Host mit dem Benutzer opc, sudo bei dem Benutzer oracle an, und führen Sie den Befehl id aus.
    [opc@hydrsoa1 ~]$ sudo su - oracle
[oracle@hydrsoa1 ~]$ id
uid=1001(oracle) gid=1001(oracle) groups=1001(oracle),1002(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

    In der folgenden Tabelle werden der Benutzer und die Gruppe oracle angezeigt, die bereits in den sekundären Compute-Instanzen vorhanden sind.

    Benutzer oder Gruppe Name ID Beschreibung
    Benutzer oracle 1001 Der Eigentümer von Oracle-Software
    Gruppen oracle 1001 Principal-Gruppe des oracle-Benutzers
    docker 1002 Sekundäre Gruppe des Benutzers oracle
  3. Die folgenden Szenarios und Lösungen sind möglich:
    • Die sekundären Benutzer und Gruppen haben andere Namen und IDs als die primären.

      Lösung: Erstellen Sie die Benutzer und Gruppen in der sekundären Datenbank so, wie sie in der primären Datenbank vorhanden sind.

    • Die sekundären Benutzer und Gruppen haben dieselben Namen, jedoch andere IDs als die primären.

      Lösung: Ändern Sie die IDs in der Sekundärdatenbank, sodass sie mit den IDs der Primärdatenbank übereinstimmen.

    • Die Benutzer und Gruppen in der sekundären Datenbank haben andere Namen als die Namen in der primären Datenbank, jedoch dieselben IDs.

      Lösung: Ändern Sie die Namen des Benutzers und der Gruppe in der sekundären Gruppe.

    • Es gibt Konflikte: Einige IDs des primären Benutzers oder der primären Gruppen werden von anderen Benutzern oder Gruppen im sekundären Benutzer verwendet.

      Lösung: Korrigieren Sie den Konflikt, indem Sie die ID des konfliktauslösenden Benutzers oder der konfliktauslösenden Gruppe in der sekundären Gruppe ändern. Erstellen Sie dann den oder die Benutzergruppen in der sekundären Gruppe, damit sie mit den Gruppen in der primären Datenbank übereinstimmen.

    Die folgende Tabelle enthält eine Zusammenfassung der Befehle, mit denen Sie Konflikte auflösen können:

    Aktion Befehl (als Root ausführen)
    So erstellen Sie eine neue Gruppe groupadd group_name -g group_id

    Beispiel:

    groupadd oinstall -g 1002 groupadd dba -g 1001
    So erstellen Sie einen neuen Benutzer useradd -u user_id user_name -g principal_group -G other groups

    Beispiel:

    useradd -u 1001 oracleuser -g oinstall -G dba
    So ändern Sie die primäre Gruppe des Benutzers usermod -g new_primary_groupname user_name
    So fügen Sie einer Gruppe einen Benutzer hinzu usermod -a -G secondary_groupname user_name
    So ändern Sie die ID eines Benutzers

    usermod -u new_id user_name

    find / -user old_uid -exec chown -h user_name {} \;

    Beispiel: Mit dem folgenden Befehl wird die ID des Benutzers oracle von 1001 in 501 geändert:

    usermod -u 501 oracle

    find / -user 1001 -exec chown -h oracle {} \;
    So ändern Sie die ID einer Gruppe:

    groupmod -g new_id group_name

    find / -group old_id -exec chgrp -h group_name {} \;

    Beispiel: Mit dem folgenden Befehl wird die ID der Gruppe oracle von 1001 in 501 geändert:

    groupmod -g 501 oracle

    find / -user 1001 -exec chgrp -h oracle {} \;

    Hinweis:

    Oracle empfiehlt, die Änderungen in den sekundären OCI-Compute-Instanzen auszuführen. Ändern Sie die ID-Werte im primären Feld nicht.

    Im Folgenden finden Sie ein Beispiel, bei dem die IDs der Gruppen, die in den primären Hosts verwendet werden, bereits von anderen Gruppen in den sekundären Hosts verwendet werden. Um diesen Konflikt zu lösen, sind folgende Aktionen erforderlich:

    1. Die Gruppe docker in der sekundären Gruppe verwendet ID 1002, was mit der ID der primären Gruppe oinstall in Konflikt steht.
      Um den Konflikt zu lösen, ändern Sie die ID der Gruppe docker in den sekundären Hosts in eine andere, nicht widersprüchliche ID. Beispiel: Wählen Sie 1005 als neue ID aus, und prüfen Sie, ob sie nicht verwendet wird, indem Sie bestätigen, dass sie nicht in der Datei /etc/group angezeigt wird.
      [opc@hydrsoa1 ~]$ sudo -s  
[root@hydrsoa1 ~]$ more /etc/group | grep 1005
      Wenn Sie bestätigen, dass die Kennung nicht verwendet wird, setzen Sie die Kennung der Gruppe auf die neue Kennung.
      [opc@hydrsoa1 ~]$ sudo -s 
[root@hydrsoa1 ~]$ groupmod -g 1005 docker
[root@hydrsoa1 ~]$ find / -group 1002 -exec chgrp -h docker {} \;
    2. Die Gruppe oracle in der sekundären verwendet ID 1001, die mit der ID der primären Gruppe dba in Konflikt steht.
      Um den Konflikt zu lösen, ändern Sie die ID der Gruppe oracle in den sekundären Hosts in eine andere, nicht widersprüchliche ID. Beispiel: Wählen Sie 1006 als neue ID aus, und prüfen Sie, ob sie nicht verwendet wird, indem Sie bestätigen, dass sie nicht in der Datei /etc/group angezeigt wird.
      [opc@hydrsoa1 ~]$ sudo -s 
[root@hydrsoa1 ~]$ more /etc/group | grep 1006
      Wenn Sie bestätigen, dass die Kennung nicht verwendet wird, setzen Sie die Kennung der Gruppe auf die neue Kennung.
      [opc@hydrsoa1 ~]$ sudo -s 
[root@hydrsoa1 ~]$ groupmod -g 1006 oracle
[root@hydrsoa1 ~]$ find / -group 1001 -exec chgrp -h oracle {} \;
    3. Erstellen Sie die Gruppen oinstall und dba des Benutzers "oracle" auf den sekundären Hosts mit denselben IDs wie die primären IDs. 
      [opc@hydrsoa1 ~]$ sudo -s
[root@hydrsoa1 ~]$ groupadd oinstall -g 1002
[root@hydrsoa1 ~]$ groupadd dba -g 1001
    4. Der Benutzer oracle hat denselben Namen und dieselbe ID in der Primär- und Standbydatenbank, sodass keine Änderungen erforderlich sind.
      Sie müssen jedoch die Hauptgruppe des Benutzers auf den sekundären Hosts in oinstall ändern.
      [root@hydrsoa1 ~]$ usermod -g oinstall oracle
      Fügen Sie den Benutzer dann der Gruppe dba hinzu. 
      [root@hydrsoa1 ~]$ usermod -a -G dba oracle
    5. Stellen Sie sicher, dass die Ausgabe des Befehls id für den Benutzer oracle auf den sekundären Hosts mit der Primärdatenbank für die Haupt- und Sekundärgruppe übereinstimmt.
      Ausgabe in der Primärdatenbank:
      [oracle@host3.myopnetwork.com ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)
      Ausgabe in der sekundären (die sekundäre kann zusätzliche Gruppen haben):
      oracle@hydrsoa1 ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba),1005(docker)
        …
    6. (Empfohlen) Führen Sie nach diesen Änderungen einen Neustart des Hosts aus.
  4. (Optional, aber empfohlen) Aktivieren Sie den SSH-Zugriff auf den Benutzer "oracle".
    Sie ist in dieser DR-Topologie nützlich, weil sie dem Benutzer oracle eine direkte Verbindung ermöglicht, um die Befehle auszuführen, mit denen der Inhalt des Dateisystems von der primären in die sekundäre kopiert wird.
    1. Kopieren Sie den Public Key, den Sie für die Verbindung mit den Compute-Instanzen verwenden, in eine Textdatei. Sie verwenden es später in diesem Verfahren.
    2. Melden Sie sich bei der Instanz an, und wechseln Sie mit sudo zum Root-Benutzer.
    3. Erstellen Sie ein .ssh-Verzeichnis im Standardverzeichnis des neuen Benutzers.
      mkdir -p /home/oracle/.ssh
    4. Kopieren Sie den SSH-Public Key, mit dem Sie eine Verbindung zum Compute herstellen, in die Datei.
      /home/oracle/.ssh/authorized_keys
    5. Ändern Sie den Eigentümer und die Gruppe des Verzeichnisses /home/oracle/.ssh in den Benutzer oracle.
      chown -R oracle:oinstall /home/oracle/.ssh
    6. Prüfen Sie die Verbindung, indem Sie die SSH-Verbindung mit dem oracle-Benutzer und dem Private Key herstellen.
    7. Setzen Sie die Berechtigungen für die Datei authorized_keys auf 600.
      chmod 600 /home/oracle/.ssh/authorized_keys

Betriebssystemanforderungen vorbereiten

Die Oracle HTTP Server-Binärdateien werden von den primären Oracle HTTP Server-Hosts auf die sekundären Oracle HTTP Server-Hosts kopiert. Daher ist es nicht erforderlich, runinstaller auf den sekundären Hosts auszuführen. Da die Oracle WebLogic Server for Oracle Cloud Infrastructure-Images für die WebLogic-Software vorbereitet sind, müssen Sie keine Packages für WebLogic manuell hinzufügen. Diese Oracle HTTP Server-Hosts führen jedoch das Oracle HTTP Server-Produkt aus. Stellen Sie sicher, dass die sekundären Hosts die Anforderungen für Oracle HTTP Server erfüllen.
  1. Stellen Sie sicher, dass Ihre Umgebung die Mindestinstallationsanforderungen für die Produkte erfüllt, die auf primären Hosts installiert sind. Prüfen Sie das entsprechende Dokument in Oracle Fusion Middleware System Requirements and Specifications.
  2. Prüfen Sie die erforderlichen Systempackages für Ihre Version und Ihr BS.
  3. Installieren Sie die fehlenden Systempackages mit yum.

    In diesem Beispiel werden Oracle HTTP Server 12.2.1.4 und Oracle Linux 7 verwendet. Einige der erforderlichen Packages sind bereits in den Oracle Cloud Infrastructure-(OCI-)Middle Tier Compute-Instanzen installiert. In diesem Beispiel fehlten die folgenden Elemente und mussten mit yum installiert werden: 

    yum install compat-libcap1.x86_64
yum install compat-libstdc++-33.x86_64
yum install compat-libstdc++-33.i686 
yum install gcc-c++.x86_64
yum install libaio-devel.x86_64
yum install libstdc++.i686    
yum install libstdc++-devel.x86_64
yum install dejavu-serif-fonts
yum install numactl.x86_64
yum install numactl-devel.x86_64
yum install motif.x86_64
yum install motif-devel.x86_64
yum install redhat-lsb.x86_64
yum install xorg-x11-utils.x86_64
  4. Konfigurieren Sie Datei- und Prozessgrenzwerte in der Datei /etc/security/limits.conf. Prüfen Sie die Grenzwerte in Ihren On-Premise-Oracle HTTP Server-Hosts, und legen Sie die Werte in den OCI Oracle HTTP Server-Compute-Instanzen entsprechend fest.

Hostnamen-Aliasnamen für Oracle HTTP Server vorbereiten

Konfigurieren Sie dieselben virtuellen Hostnamen, die von den Oracle HTTP Server-Hosts in der primären Umgebung verwendet werden, wie Aliasnamen in den sekundären Oracle Cloud Infrastructure-(OCI-)Oracle HTTP Server-Compute-Instanzen, verweisen jedoch auf die IP-Adressen der sekundären Hosts.

Dies kann auf 2 Arten implementiert werden:

  • Fügen Sie die Hostnamen als Aliasnamen zu den /etc/hosts-Dateien der Oracle WebLogic Server for OCI-Compute-Instanzen hinzu.
  • Verwenden Sie eine private DNS-Ansicht im sekundären OCI-VCN.
/etc/hosts-Dateien verwenden
Die virtuellen Hostnamen, die als Aliasnamen in den primären Servern verwendet werden, werden den /etc/hosts-Dateien der sekundären Hosts hinzugefügt, wobei auf die IP-Adressen der sekundären Hosts verwiesen wird. Dieser Modus ist in allen Szenarios gültig, wenn der DNS-Server in der primären On-Premise und auf den sekundären Oracle Cloud Infrastructure-(OCI-)Sites identisch ist und wenn separate DNS-Server in der primären und sekundären Site verwendet werden. Die Einträge in der Datei /etc/hosts haben Vorrang vor der DNS-Auflösung, da dies die standardmäßig in der Anweisung "hosts" der Datei /etc/nsswitch.conf definierte Priorität ist.

Bei dieser Methode müssen Sie die Einträge jedoch allen Oracle HTTP Server-Hosts manuell hinzufügen:

  1. Bearbeiten Sie die Datei /etc/oci-hostname.conf jeder Oracle HTTP Server-Compute-Instanz, und legen Sie die Eigenschaft PRESERVE_HOSTINFO=3 fest, um /etc/hosts-Einträge über Instanzneustarts hinweg beizubehalten.
  2. Verwenden Sie den Befehl hostname --fqdn, um die vollständigen Hostnamen der OCI-Compute-Instanzen zu identifizieren.
  3. Fügen Sie der Datei /etc/hosts der OCI Oracle HTTP Server-Compute-Instanzen die folgenden Einträge hinzu:
    #################################
# ALIASES for SOA DR
#################################
# Aliases of the Oracle HTTP Server hosts
ohshost1_compute_instance_IP  ohshost1_fqdn  ohshost1_hostname    ALIASES_OF_WEBHOST1
ohshost2_compute_instance_IP  ohshost2_fqdn  ohshost2_hostname    ALIASES_OF_WEBHOST2
# The aliases for SOA are added too
virtual_IP_for_admin          virtualIP_fqdn  virtualIP_hostname    ALIASES_OF_ADMINVHN
soahost1_compute_instance_IP  soahost1_fqdn   soahost1_hostname     ALIASES_OF_SOAHOST1
soahost2_compute_instance_IP  soahost2_fqdn   soahost2_hostname     ALIASES_OF_SOAHOST2

    Hinweis:

    Neben den virtuellen Namen der Oracle HTTP Server-Hosts als Aliasnamen werden die virtuellen Namen der Oracle WebLogic Server-Hosts hinzugefügt, die auf die IPs des sekundären WebLogic Server-Hosts verweisen. Weil Oracle HTTP Server mit den Hosts des WebLogic-Servers über die Namen der virtuellen Hosts kommuniziert.
    Im Folgenden finden Sie ein Beispiel für die Datei /etc/hosts in der sekundären Oracle HTTP Server-Compute-Instanz:
    #################################
# ALIASES for SOA DR - SECONDARY
#################################
# The aliases of the Oracle HTTP Server hosts
100.60.10.11 hydrohs1.webTiersubnet.hydrvcn.oraclevcn.com    hydrohs1    WEBHOST1.example.com WEBHOST1
100.60.10.12 hydrohs2.webTiersubnet.hydrvcn.oraclevcn.com    hydrohs2    WEBHOST2.example.com WEBHOST2
# The aliases of the SOA hosts
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
    Im Folgenden finden Sie ein Beispiel für die vorhandene Datei /etc/hosts der primären Oracle HTTP Server-Hosts:
    #################################
# ALIASES for SOA DR - PRIMARY
#################################
# The aliases of the Oracle HTTP Server hosts
100.10.10.11 host1.myopnetwork.com    host1    WEBHOST1.example.com WEBHOST1
100.10.10.12 host2.myopnetwork.com    host2    WEBHOST2.example.com WEBHOST2
# The aliases of the SOA hosts
10.10.10.20    host-vip1.myopnetwork.com         host-vip1       ADMINVHN.example.com   ADMINVHN
10.10.10.13    host3.myopnetwork.com             host3           SOAHOST1.example.com   SOAHOST1
10.10.10.14    host4.myopnetwork.com             host4           SOAHOST2.example.com   SOAHOST2
Domain Name System (DNS) verwenden
Die von den primären Oracle HTTP Server-Hosts verwendeten virtuellen Hostnamen werden dem DNS-Resolver hinzugefügt, der vom VCN der sekundären Oracle HTTP Server-Hosts verwendet wird, wobei auf die IP-Adressen der sekundären Oracle HTTP Server-Hosts verwiesen wird. Dieser Modus ist gültig, wenn separate DNS-Server in der primären On-Premise-Umgebung und in der sekundären Datenbank in Oracle Cloud Infrastructure (OCI) verwendet werden. Andernfalls kann dies zu Konflikten bei der Namensauflösung führen. Der Server jeder Site muss diese Namen mit eigenen IPs auflösen.
Der Vorteil dieser Methode besteht darin, dass Sie alle Einträge zu einer privaten DNS-Ansicht hinzufügen können, anstatt sie den /etc/hosts-Dateien aller Hosts hinzuzufügen.

Fügen Sie die Einträge für die virtuellen Oracle HTTP Server-Hostnamen zur privaten Ansicht hinzu, die in OCI erstellt wurde, indem Sie die Mid-Tier auf OCI vorbereiten:

  1. Gehen Sie in der OCI-Konsole zur sekundären Region, und suchen Sie die private Ansicht:
    1. Klicken Sie auf Networking, DNS-Verwaltung, Private Ansichten.
      Beispiel: HYBRID_DR_VIRTUAL_HOSTNAMES
    2. Klicken Sie in der privaten Ansicht auf den von Ihnen erstellten Zonennamen, um die virtuellen Hosts hinzuzufügen.
      In diesem Beispiel: example.com.
    3. Fügen Sie dieser Zone die Namen der virtuellen Oracle HTTP Server-Hosts hinzu, die jedoch mit den IPs der sekundären Oracle HTTP Server-Hosts aufgelöst werden.

      Sie müssen nur den Nicht-Fqdn-Namen im OCI-Konsolenmenü angeben, um den Datensatz hinzuzufügen. Die DNS-Domäne der Zone wird automatisch dem Datensatz hinzugefügt.

    4. Klicken Sie auf Änderungen veröffentlichen.
  2. Validieren Sie die Auflösung der SECONDARY-Hosts, indem Sie ping und nslookup der hinzugefügten virtuellen Hostnamen ausführen.
    Sie müssen mit den entsprechenden SECONDARY IPs aufgelöst werden.

Erforderliche Ports in den Firewalls des OCI-Hosts öffnen

Jede Compute-Instanz verfügt über einen lokalen Firewallservice. Aus Sicherheitsgründen wird in der Standardkonfiguration die Verbindung für alle Ports abgelehnt, mit Ausnahme der minimal erforderlichen Verbindungen (ssh, dhcp). Sie müssen die von Oracle HTTP Server verwendeten Ports öffnen.
  1. Prüfen Sie den Status und die Regeln des Firewall-Service:
    bash-4.2# firewall-cmd --state
running
bash-4.2# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
    Diese Ausgabe bedeutet, dass keine anderen Ports als 22 geöffnet sind.
  2. Verwenden Sie als Root-Benutzer firewall-cmd-Befehle, um die Ports zu öffnen, die von Oracle HTTP Server in jeder Oracle HTTP Server-Compute-Instanz als Listening-Ports verwendet werden.
    Beispiel:
    firewall-cmd --permanent --add-port=7001/tcp 
firewall-cmd --permanent --add-port=8890/tcp 
service firewalld reload
  3. Prüfen Sie den Status und die Regeln des Firewall-Service:
    bash-4.2# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: dhcpv6-client ssh
  ports: 7001/tcp 8890/tcp 8888/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

oracle-Benutzerumgebungsvariablen für Oracle HTTP Server erstellen

Es ist üblich, dass Oracle HTTP Server-bezogene Umgebungsvariablen im Profil des Benutzers oracle auf den Oracle HTTP Server-Hosts vorhanden sind. Beispiel: ORACLE_HOME, JDK_HOME, PATH, WEB_DOMAIN_HOME und andere.
  1. Prüfen Sie die Profildateien des Benutzers oracle auf den primären Oracle HTTP Server-Hosts.
  2. Fügen Sie sekundär dieselben Oracle HTTP Server-bezogenen Umgebungsvariablen zu den Profildateien des Benutzers oracle hinzu (.bashrc oder .bash_profile).

    Beachten Sie, dass die Datei .bashrc des Benutzers oracle in den Oracle HTTP Server-Hosts möglicherweise bereits definierte Variablen enthalten (MIDDLEWARE_HOME, WLS_HOME usw.), die jedoch wahrscheinlich für die Ordner Ihrer Umgebung gelten und für Sie nicht gültig sind. Stellen Sie sicher, dass Sie sie entsprechend Ihren Umgebungsordnern entfernen oder ändern.

Oracle HTTP Server-Produkt und -Konfiguration aus der primären Datenbank replizieren

Da die sekundären Oracle HTTP Server-OCI-Compute-Instanzen als primäre Oracle HTTP Server-Hosts erstellt werden ( dasselbe Betriebssystem, dieselben Benutzer-IDs, Hostnamenaliasnamen usw.), können Sie rsync verwenden, um die Binärdateien und die Oracle HTTP Server-Konfiguration aus den primären Oracle HTTP Server-Knoten zu kopieren.

Alternativ können Sie die Oracle HTTP Server-Software herunterladen, von Null in den OCI Oracle HTTP Server-Compute-Instanzen installieren und konfigurieren. Dieser Ansatz liegt außerhalb des Anwendungsbereichs dieses Dokuments. Sie müssen diesen Ansatz jedoch verwenden, wenn die Oracle HTTP Server-OCI-Compute-Instanzen ein anderes Betriebssystem als die primären Oracle HTTP Server-Hosts verwenden.

Oracle HTTP Server-Binärdateien und -Konfigurationsdateien befinden sich normalerweise im privaten Speicher. In OCI können Sie standardmäßig das Block-Volume der Compute-Instanz verwenden. Alternativ können Sie ein neues Block-Volume für jedes Oracle HTTP Server-Compute erstellen (wie unter OCI-Block-Volumes vorbereiten beschrieben) und jedes Volume in den Oracle HTTP Server-Compute-Instanzen mounten (wie unter OCI-Block-Volumes mounten beschrieben).

In diesem Beispiel wird das Standardblock-Volume der Oracle HTTP Server-Compute-Instanzen verwendet, ohne zusätzliche Block-Volumes zu erstellen.

  1. Identifizieren Sie die Ordner der Oracle HTTP Server-Binärdateien und die Konfiguration in den primären Oracle HTTP Server-Knoten.
    Beispiel:
  2. Erstellen Sie dieselben Ordner in den OCI Oracle HTTP Server-Compute-Instanzen. Sie müssen denselben Pfad verwenden, der auch in der Primärdatenbank verwendet wird.
    1. Stellen Sie mit SSH eine Verbindung zu den BS-Compute-Instanzen her, und wechseln Sie mit sudo zum root-Benutzer.
    2. Erstellen Sie die Ordner, und legen Sie oracle als Eigentümer fest.
      Beispiel:
      bash-4.2# mkdir -p /u02/oracle/products/ohs_12214
bash-4.2# mkdir -p /u02/oracle/config/ohsdomain_12214
bash-4.2# chown -R oracle:oinstall /u02
    3. Wiederholen Sie den Vorgang für jede Oracle HTTP Server-OCI-Compute-Instanz.
  3. Kopieren Sie mit rsync den Ordner products aus der primären On-Premise-WEBHOST1 in die Remote-WEBHOST1. Wiederholen Sie den Schritt, um den Produktordner von WEBHOST2 in den Remote-Ordner WEBHOST2 zu kopieren. Wiederholen Sie diesen Schritt für alle anderen Oracle HTTP Server-Compute-Instanzen.

    Hinweis:

    Es gibt ein Beispielskript, mit dem Sie den Oracle HTTP Server-Produktordner aus der primären On-Premise-WEBHOST1 in die Remote-WEBHOST1 kopieren können.

    Gehen Sie zu Code herunterladen, um das Skript herunterzuladen.

  4. Verwenden Sie rsync, um den Oracle HTTP Server-Konfigurationsordner aus der primären On-Premise-Datei WEBHOST1 in die Remote-Datei WEBHOST1 zu kopieren. Wiederholen Sie den Schritt, um den Konfigurationsordner von WEBHOST2 in die Remote-Datei WEBHOST2 zu kopieren. Wiederholen Sie diesen Schritt für alle anderen Oracle HTTP Server-Compute-Instanzen.

    Hinweis:

    Es gibt ein Beispielskript, mit dem Sie den Konfigurationsordner von Oracle HTTP Server aus der primären On-Premise-Instanz WEBHOST1 in die Remote-Datei WEBHOST1 kopieren können.

    Gehen Sie zu Code herunterladen, um das Skript herunterzuladen.

  5. Kopieren Sie die Datei /etc/oraInst.loc aus den primären Oracle HTTP Server-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.
  6. Wenn sich der Ordner oraInventory unter dem Produktordner befindet, wird er zusammen mit dem Oracle Home-Verzeichnis von Oracle HTTP Server kopiert. Wenn sich der Ordner oraInventory in einem anderen Speicherort befindet, müssen Sie ihn auch in die sekundären Hosts kopieren.

Die Oracle HTTP Server-Konfiguration und -Binärdateien ändern nicht häufig Überstunden. Nach dieser anfänglichen Replikation können Sie dieselbe Replikation während des Lebenszyklus wiederholen. Alternativ können Sie die Konfiguration von Oracle HTTP Server in der Primär- und Sekundärdatenbank manuell verwalten, indem Sie die Oracle HTTP Server-Konfigurationsänderungen in beiden Sites implementieren.

OCI Load Balancer vorbereiten

Erstellen und konfigurieren Sie den Oracle Cloud Infrastructure-Load Balancer in der Cloud.

Hinweis:

Sie finden den Terraform-Code zum Erstellen der in diesem Abschnitt beschriebenen Ressourcen (OCI Load Balancer, SSL-Zertifikat, Backend-Sets und -Backends, Routing-Policys, Listener und Regelsets) unter Code herunterladen.

OCI-Load Balancer bereitstellen

Um mit der primären On-Premise-Site konsistent zu sein, stellen Sie einen Load Balancer auf Ihrer sekundären Site in Oracle Cloud Infrastructure (OCI) als Einstiegspunkt für das System bereit.

  1. Melden Sie sich bei der OCI-Konsole an.
  2. Wählen Sie die richtige Region und das richtige Compartment aus.
  3. Navigieren Sie zu Networking und dann zu Load Balancer. Klicken Sie auf Load Balancer erstellen.
  4. Wählen Sie den Load-Balancerstyp aus.
  5. Geben Sie einen Namen für den Load Balancer an.
    Beispiel: hyDRlbr.
  6. Wählen Sie den Sichtbarkeitstyp (öffentlich oder privat) und die Bandbreite aus, die Ihren Anforderungen entsprechen.
    • Wenn von externen Clients über das Internet auf Ihr System zugegriffen wird, wählen Sie die Sichtbarkeit öffentlich aus. Der OCI-Load Balancer verwendet eine öffentliche IP.
    • Wenn nur von Clients intern auf Ihr System zugegriffen wird, können Sie die private Sichtbarkeit auswählen, um dem Load Balancer nur eine private IP bereitzustellen.
  7. Wählen Sie das entsprechende VCN und Subnetz aus.
    Beispiel: hydrvcn und webTierSubnet.
  8. Fügen Sie zu diesem Zeitpunkt kein Backend hinzu.
  9. Standard-Listener mit Standardwerten beibehalten
  10. Klicken Sie auf Senden.
Speichern Sie die IP des OCI-Load Balancers (Beispiel: 100.100.100.10).

Zertifikate hochladen

Laden Sie die vom primären Load Balancer verwendeten Zertifikate hoch.

  1. Klicken Sie in der Konsole auf Load Balancer, Zertifikate und dann auf Zertifikat hinzufügen.
  2. Laden Sie das öffentliche SSL-Zertifikat und den Private Key des Zertifikats hoch, das der primäre Load Balancer verwendet. Laden Sie CA-(Certificate Authority-)Zertifikate hoch, sofern verwendet.
  3. Geben Sie einen Namen für das Zertifikat ein, und klicken Sie auf Zertifikat hinzufügen.
    Das neue Zertifikat wird in der Liste der Zertifikate für den Load Balancer angezeigt.
  4. Wenn Sie für den Zugriff auf das Primärsystem mehrere Zertifikate verwenden, wiederholen Sie diese Schritte, um alle Zertifikate hochzuladen.

Backend-Sets erstellen

Ein Backend-Set ist eine logische Entity, die eine Liste mit Backend-Servern enthält, auf denen dieselben Anwendungen ausgeführt werden. Wenn Sie ein Backend-Set definieren, müssen Sie eine Load Balancing Policy und einen Health-Check-Test angeben. Anschließend können Sie die Liste der Backend-Server hinzufügen.

Die Konfiguration der Backend-Sets hängt davon ab, ob Sie Oracle HTTP Server vor den WebLogic Server-Hosts verwenden.

Wenn Sie Oracle HTTP Server verwenden, sendet der Oracle Cloud Infrastructure-(OCI-)Load Balancer die Anforderungen an die HTTPS-Server. Erstellen Sie ein Backend-Set für jeden Port, der von den HTTPS-Servern bereitgestellt wird. Beispiel: Erstellen Sie ein Backend-Set für den Oracle HTTP Server-Listener, der Zugriff auf die Anwendungen ermöglicht, und ein weiteres Backend-Set für den Oracle HTTP Server-Listener, das Zugriff auf jede Oracle WebLogic Server-Administrationskonsole bietet.

Wenn Sie Oracle HTTP Server nicht verwenden, sendet der OCI Load Balancer die Anforderungen direkt an die WebLogic-Server. Erstellen Sie ein Backend-Set für jedes Oracle WebLogic Server-Cluster und ein weiteres Backend-Set für den Admin-Server.

  1. Melden Sie sich bei der OCI-Konsole an.
  2. Wählen Sie die richtige Region und das richtige Compartment aus.
  3. Klicken Sie im Navigationsmenü auf Networking, Load Balancer.
  4. Klicken Sie auf den Load Balancer, dem Sie ein Backend hinzufügen möchten.
  5. Klicken Sie im Menü Ressourcen auf Backend-Sets und dann auf Backend-Set erstellen.
  6. Geben Sie im Dialogfeld "Backend-Set erstellen" Folgendes ein:
    1. Name: Geben Sie einen Namen für das Backend-Set an.
      Backend-Set-Namen dürfen nur alphanumerische Zeichen, Gedankenstriche und Unterstriche enthalten.
    2. Verkehrsverteilungs-Policy: Wählen Sie Gewichtetes Round-Robin aus.
    3. Sessionpersistenz: Wählen Sie Load-Balancer-Cookiepersistenz aktivieren aus.
    4. Cookiename: Geben Sie einen Namen für das Cookie ein, mit dem Sessionpersistenz aktiviert wird.
    5. Attribute: Wählen Sie Sicher aus.
    6. Health Check: Wählen Sie TCP aus, um den Port zu prüfen, oder HTTP, um den URL-Pfad (URI) und den erwarteten Antwortcode zu prüfen.
      Im Folgenden finden Sie HTTP-Beispiele für Health Check:
      • OHS_Admin_backendset: URL-Pfad /console, Statuscode 302
      • OHS_HTTP_backendset:
        • URL-Pfad /, Statuscode 200 (oder 404, je nach Oracle HTTP Server-Konfiguration)
        • URL-Pfad /app1, Statuscode 200
  7. Klicken Sie auf Erstellen.

Wenn Oracle HTTP Server zusätzliche Ports für andere Services empfängt, erstellen Sie ein Backend-Set für jeden Service auf ähnliche Weise.

Im Folgenden finden Sie ein Beispiel für die Backend-Sets, wenn Sie Oracle HTTP Server verwenden.

Komponente Backend-Setname Verkehrsverteilungs-Policy Sessionpersistenz Cookie-Name (Beispiel) Attribut: sicher Health Check
Admin-Server OHS_Admin_backendset Gewichtetes Round Robin Load-Balancer-Cookiepersistenz aktivieren X-Oracle-LBR-ADMIN-Backendset Nicht aktiviert TCP oder HTTP
Alle SOA-Komponenten
  • Oracle SOA Suite
  • Oracle Service Bus
  • Oracle B2B
  • Geschäftsprozessverwaltung
  • Oracle Enterprise Scheduler (ESS)
  • Überwachung der Geschäftsaktivität (BAM)
 OHS_HTTP_backendset Gewichtetes Round Robin Load-Balancer-Cookiepersistenz aktivieren X-Oracle-LBR-OHS-HTTP-Backendset Aktiviert TCP oder HTTP
Oracle Web Services Manager OHS_HTTP_internal_backendset Gewichtetes Round Robin Load-Balancer-Cookiepersistenz aktivieren X-Oracle-LBR-OHS-Internal-HTTP-Backendset Nicht aktiviert TCP oder HTTP

Wenn Oracle HTTP Server zusätzliche Ports für andere Services empfängt, erstellen Sie ein Backend-Set für jeden Service auf ähnliche Weise.

Im Folgenden finden Sie ein Beispiel für die Backend-Sets, wenn Sie Oracle HTTP Server nicht verwenden.

Komponente Backend-Setname Verkehrsverteilungs-Policy Sessionpersistenz Cookiename (Beispiel) Attribut: sicher Health Check
Alle Produkte (admin) Admin_backendset Gewichtetes Round Robin Load-Balancer-Cookiepersistenz aktivieren X-Oracle-LBR-ADMIN-Backendset Deaktiviert TCP oder HTTP
Oracle Web Services Manager WSM_backendset Gewichtetes Round Robin Load-Balancer-Cookiepersistenz aktivieren X-Oracle-LBR-WSM-Backendset Deaktiviert TCP oder HTTP
Oracle SOA Suite, Geschäftsprozessverwaltung und Oracle B2B SOA_backendset Gewichtetes Round Robin Load-Balancer-Cookiepersistenz aktivieren X-Oracle-LBR-SOA-Backendset Aktiviert TCP oder HTTP
Oracle Service Bus OSB_backendset Gewichtetes Round-Robin Load-Balancer-Cookiepersistenz aktivieren X-Oracle-LBR-OSB-Backendset Aktiviert TCP oder HTTP
Oracle Enterprise Scheduler (ESS) ESS_backendset Gewichtetes Round-Robin Load-Balancer-Cookiepersistenz aktivieren X-Oracle-LBR-ESS-Backendset Aktiviert TCP oder HTTP
Überwachung der Geschäftsaktivität (BAM) BAM_backendset Gewichtetes Round-Robin Load-Balancer-Cookiepersistenz aktivieren X-Oracle-LBR-BAM-Backendset Aktiviert TCP oder HTTP

Wenn Sie über zusätzliche WebLogic-Cluster verfügen, erstellen Sie auf ähnliche Weise ein Backend-Set für jedes Cluster.

Backends für jedes Backend-Set definieren

Definieren Sie die Backends für jedes Backend-Set im Oracle Cloud Infrastructure-(OCI-)Load Balancer.

Wenn Sie Oracle HTTP Server verwenden, fügen Sie die Oracle HTTP Server-Knoten und die entsprechenden Ports als Backends in jedem Backend-Set hinzu.

Wenn Sie Oracle HTTP Server nicht verwenden, fügen Sie die Oracle WebLogic Server-Knoten und die entsprechenden Ports als Backends in jedem Backend-Set hinzu.

  1. Wählen Sie in der Konsole ein Backend-Set aus. Klicken Sie auf Backends und dann auf Backends hinzufügen.
  2. Geben Sie die IP-Adresse und den Port für den Server ein, der das Backend ist.

Die Tabelle zeigt die Backend-Sets, die im Beispiel dieses Dokuments bei Verwendung von Oracle HTTP Server erstellt wurden:

Backend-Setname Backends
OHS_Admin_backendset Compute-Instanzen:
  • hydrohs1, der Oracle HTTP Server-Port für den Konsolen-Listener (z.B. 7001)
  • hydrohs2, der Oracle HTTP Server-Port für den Konsolen-Listener (z.B. 7001)
OHS_HTTP_backendset Compute-Instanzen:
  • hydrohs1, der Oracle HTTP Server-Port für den HTTP-Listener (z.B. 8890)
  • hydrohs2, der Oracle HTTP Server-Port für den HTTP-Listener (z.B. 8890)
OHS_HTTP_internal_backendset Compute-Instanzen:
  • hydrohs1, der Oracle HTTP Server-Port für den internen HTTP-Listener (z.B. 8891)
  • hydrohs2, der Oracle HTTP Server-Port für den internen HTTP-Listener (z.B. 8891)

Die Tabelle zeigt die Backend-Sets, die im Beispiel dieses Dokuments erstellt werden, wenn Oracle HTTP Server NICHT verwendet wird:

Backend-Setname Backends
Admin_backendset IP-Adressen:
  • Die zuvor erstellte virtuelle IP des Admin-Servers, Admin-Serverport (7001)
WSM_backendset Compute-Instanzen:
  • hydrsoa1, WSM server1-Port (7010)
  • hydrsoa2, WSM server2-Port (7010)
SOA_backendset Compute-Instanzen:
  • hydrsoa1, SOA server1-Port (8001)
  • hydrsoa2, SOA server2-Port (8001)
OSB_backendset Compute-Instanzen:
  • hydrsoa1, OSB server1-Port (8010)
  • hydrsoa2, OSB server2-Port (8010)
ESS_backendset Compute-Instanzen:
  • hydrsoa1, ESS server1-Port (8021)
  • hydrsoa2, ESS server2-Port (8021)
BAM_backendset Compute-Instanzen:
  • hydrsoa1, BAM server1-Port (9001)
  • hydrsoa2, BAM server2-Port (9001)

Routing-Policys definieren und Regeln konfigurieren

Mit den Routing-Policys werden die eingehenden Anforderungen an das korrekte Backend-Set verteilt. Beispiel: Eine Anforderung an /console wird an das Admin-Backend-Set gesendet, und eine Anforderung an /app1 wird an das Backend-Set des Clusters gesendet, in dem app1 ausgeführt wird.

Wenn Sie Oracle HTTP Server verwenden, definieren Sie normalerweise die Routen (wie /app1, /app2, /console usw.) in der Oracle HTTP Server-Konfiguration. In diesem Fall müssen Sie die Routing-Policys und -Regeln nicht im Oracle Cloud Infrastructure-(OCI-)Load Balancer definieren.

Wenn Sie Oracle HTTP Server nicht verwenden, müssen Sie die Routing-Policys und -regeln im OCI Load Balancer definieren, um die Anforderungen an das entsprechende Backend-Set zu verteilen.

  1. Klicken Sie in der Oracle Cloud Infrastructure-Konsole auf den Load Balancer.
  2. Klicken Sie auf Routing-Policys und dann auf Routing-Policys erstellen, um die Policys zu definieren.
    Die Routing-Policys werden später den Load Balancer Listenern hinzugefügt.
  3. Geben Sie einen Namen für die Routing-Policy (Regelset) ein.
    Beispiel: Admin_Rules.
  4. Um Regeln in der Routing-Policy zu erstellen, geben Sie einen Namen für die Regel ein.
    Beispiel: Admin_routerule.
  5. Definieren Sie die Regelbedingungen, um Anforderungen an verschiedene Backend-Sets weiterzuleiten. Wählen Sie Wenn eine Übereinstimmung vorhanden aus, und wählen Sie Bedingungstyp: Pfad aus. Wählen Sie Operator: Beginnt mit aus, und geben Sie eine URL-Zeichenfolge ein.
    Beispiel: Wenn eine Übereinstimmung, Pfad, Beginnt mit, /console.
  6. Wählen Sie im Menü das Backend-Set aus, um die Aktion zu konfigurieren.
    Beispiel: OHS_Admin_backendset.
Die Tabelle enthält die Routing-Policys und -Regeln im Oracle Cloud Infrastructure Load Balancer, der gemäß dem Beispiel in diesem Dokument erstellt wurde, wenn Oracle HTTP Server nicht verwendet wird.
Komponente Routing-Policy-Name Regel Bedingungen: Wenn ein beliebiger Übereinstimmungspfad beginnt mit Aktion: An Backend-Set weiterleiten
Alle Produkte (admin) Admin_Rules Admin_routerule

/console

/em

 Admin_backendset
Oracle Service Bus (Admin) Admin_Rules Admin_routerule

/sbconsole

/servicebus

 Admin_backendset
Oracle Web Services Manager Internal_Rules WSM_routerule

/wsm-pm

 WSM_backendset
Oracle Service Bus SOA_Rules OSB_routerule

/sbinspection.wsil

/sbresource

/osb

/alsb

OSB_backendset
Oracle SOA Suite SOA_Rules SOA_routerule

/soa-infra

/integration

/sdpmessaging

/userprefs-ui

/DefaultToDoTaskFlow

/workflow

/ADFAttachmentHelper

/soa/composer

(*) Mehr benutzerdefinierter Aliasname möglicherweise für benutzerdefinierte Aufgaben erforderlich

 SOA_backendset
Geschäftsprozessverwaltung SOA_Rules SOA_routerule

/bpm/composer

/bpm/workspace

/bpm/casemgmt

 SOA_backendset
Oracle Enterprise Scheduler (ESS) SOA_Rules ESS_routerule

/ess

/EssHealthCheck

/ess-async

/ess-wsjob

 ESS_backenset
Business Activity Monitoring (BAM) SOA_Rules BAM_routerule

/bam

/composer

/OracleBAMWS

/oracle/bam

 BAM_backendset
Oracle B2B SOA_Rules B2B_routerule

/b2bconsole

/b2b/services

/b2b/httpreceiver

 SOA_backendset

Sie können so viele Routing-Policys, Regeln und Bedingungen erstellen, wie Sie für Ihre Umgebung benötigen.

Listener erstellen

Erstellen Sie die Listener für jede Kombination aus Frontend-Name und Port, mit der auf das System zugegriffen wird. Sie müssen dieselben Hostnamen (virtuelle Frontend-Namen) und Ports verwenden, die vom primären Load Balancer verwendet werden.

  1. Fügen Sie den virtuellen Frontend-Hostnamen als Hostnamen im Oracle Cloud Infrastructure Load Balancer hinzu.
  2. Erstellen Sie die Listener.

Die folgende Tabelle enthält eine Zusammenfassung der Listener, die im Beispiel dieses Dokuments erstellt wurden, sowie zugehörige Protokolle, Ports, Backend-Sets, Routing-Policys, Hostnamen und SSL-Verwendung. Dies ist ein Referenzbeispiel. Wenn Ihr System zusätzliche Frontend-Hostnamen, Ports oder Protokolle im primären Oracle WebLogic Server-System verwendet, müssen Sie die entsprechenden Listener und Hostnamen entsprechend Ihren Anforderungen erstellen. Beispiel: Wenn Sie über ein alternatives Frontend auf die Oracle WebLogic Server-Konsole und die Oracle Enterprise Manager-Konsole zugreifen.

Listener Protokoll Port Backend-Set Routing-Policy HostName SSL verwenden
Admin_listener HTTP 7001

OHS_Admin_backendset (wenn Oracle HTTP Server verwendet wird)

Admin_backendset (wenn Oracle HTTP Server nicht verwendet wird)

Admin_Rules mysoa.example.com Nein
HTTPS_listener HTTPS 443

OHS_HTTP_backendset (wenn Oracle HTTP Server verwendet wird)

SOA_backendset (wenn Oracle HTTP Server nicht verwendet wird)

SOA_Rules mysoa.example.com Ja
HTTP_listener HTTP 80 N/V* N/V mysoa.example.com Nein
Internal_listener HTTP (8888)

OHS_HTTP_internal_backendset (wenn Oracle HTTP Server verwendet wird)

WSM_backendset (wenn Oracle HTTP Server nicht verwendet wird)

Internal_Rules mysoa.example.com Nein

* Die HTTP_listener in diesem Beispiel wird nur zum Umleiten von Anforderungen an die HTTPS_listener (HTTPS) verwendet. Das ihr zugewiesene Backend wird nicht verwendet. Da jedoch eine Angabe obligatorisch ist, müssen Sie eine angeben, für die kein SSL aktiviert ist (verwenden Sie ein leeres Standard-Backend-Set).

Regelset für SSL-Header erstellen

Erstellen Sie ein Regelset für SSL-Header im Oracle Cloud Infrastructure-(OCI-)Load Balancer, und verknüpfen Sie es mit dem HTTPS-Listener.

Wie auf der primären Site beendet der OCI-Load Balancer SSL, und die Kommunikation zwischen dem Load Balancer und dem Backend-Server erfolgt über das HTTP-Protokoll. Damit dies ordnungsgemäß funktioniert, müssen Sie Anforderungsheader im OCI-Load Balancer hinzufügen. Diese Header werden den Clientanforderungen hinzugefügt, die an den HTTPS-Listener gesendet werden, bevor sie an das WebLogic-Backend gesendet werden. Die Header informieren WebLogic, dass die Kommunikation vom Endclient zum Load Balancer HTTPS verwendet hat. Auf diese Weise wird jede URL, die WebLogic dynamisch erstellt, korrekt mit HTTPS generiert.
  1. Wählen Sie den Load Balancer in der Konsole aus. Klicken Sie auf Regelgruppen und dann auf Regelgruppe erstellen.
  2. Geben Sie einen Namen für die Regel an.
    Beispiel: SSLHeaders.
  3. Aktivieren Sie Anforderungsheaderregeln angeben, und fügen Sie die folgenden Aktionen hinzu:
    Aktion Kopfzeile Wert
    Anforderungsheader hinzufügen is_ssl SSL
    Anforderungsheader hinzufügen WL-Proxy-SSL Wahr
  4. Klicken Sie auf Erstellen.
  5. Klicken Sie auf Load Balancer und dann auf Listener. Bearbeiten Sie den Listener, der die Regel über HTTPS mit dem HTTPS-Listener verknüpft.
  6. Klicken Sie auf +Additional-Regelset, und wählen Sie dann das Regelset SSLHeaders aus.

Erstellen Sie das Regelset, um das HTTP-Protokoll an HTTPS umzuleiten

Erstellen Sie eine Umleitungsregel, und verknüpfen Sie sie mit HTTP_listener, um Port 80 zu Port 443 umzuleiten. Für die EDG-Topologie müssen alle Anforderungen, die Port 80 (HTTP) im Load Balancer erreichen, zu Port 443 (HTTPS) umgeleitet werden.

  1. Wählen Sie in der Konsole den Load Balancer aus.
  2. Klicken Sie auf Regelgruppen und dann auf Regelgruppe erstellen.
  3. Geben Sie einen Namen für die Regel ein.
    Beispiel: HTTP_to_HTTPS_redirect.
  4. Wählen Sie URL-Umleitungsregeln angeben aus, und fügen Sie die folgenden Aktionen hinzu
    • Quellpfad: /
    • Abgleichstyp: Longest Prefix Match erzwingen
    • Umleiten zu:
    • Protokoll: HTTPS
    • Host: {host} (Standardwert beibehalten)
    • Port: 443
    • Pfad: /{path} (Standardwert beibehalten)
    • Abfrage: ?{query} (Standardwert beibehalten)
    • Antwortcode: 301 - Endgültig verschoben
  5. Klicken Sie auf Load Balancer, Listener. Bearbeiten Sie den Listener, der den HTTP-Port 80 verwendet, um ihn mit dem HTTP-Listener zu verknüpfen.
  6. Klicken Sie auf +Additional-Regelset, und wählen Sie die Regel HTTP_to_HTTPS_redirect aus.

Virtuellen Frontend-Namen und IP zu SOA-Compute-Instanzen hinzufügen

In einer Disaster Recovery-Topologie müssen die Clients mit einem Frontend-FQDN (in der Regel als virtueller Frontend-Name oder Vanity-URL bezeichnet) auf das System zugreifen, der für das Data Center agnostisch ist. Dieser virtuelle Frontend-Name muss in die Load Balancer-IP-Adresse der aktuell aktiven (primären) Site aufgelöst werden.

Das Primärsystem sollte bereits einen virtuellen Frontend-Namen verwenden, der von dem DNS mit der IP des primären Load Balancers aufgelöst wird. Die Oracle SOA Suite-Hosts jeder Site müssen jedoch immer den Frontend-Namen mit dem lokalen Load Balancer auflösen, unabhängig von der clientseitigen Auflösung mit DNS. Dazu wird der virtuelle Frontend-Name der /etc/hosts-Datei mit der entsprechenden IP-Adresse auf jeder Site hinzugefügt. Dazu können Sie auch verschiedene DNS-Server auf jeder Site verwenden. In diesem Fall würde der lokale DNS-Server den Frontend-Namen mit der entsprechenden Load-Balancer-IP an jedem Standort auflösen.

/etc/hosts-Dateien verwenden
Die Datei /etc/hosts der primären und sekundären Oracle WebLogic Server-Hosts darf bei einem Switchover oder Failover nicht geändert werden. Die Oracle WebLogic Server-Hosts lösen den virtuellen Frontend-Namen immer mit der zugehörigen Frontend-IP auf. Die DNS-Aktualisierung, die während der Switchover- und Failover-Prozeduren erforderlich ist, wird in den DNS- oder Hostdateien ausgeführt, die von den Oracle WebLogic Server-Clients verwendet werden.
  1. Bearbeiten Sie als Root-Benutzer die Datei /etc/oci-hostname.conf in den sekundären Oracle WebLogic Server for Oracle Cloud Infrastructure-Compute-Instanzen, und ordnen Sie den Frontend-Namen der Oracle Cloud Infrastructure-(OCI-)Load Balancer-IP zu.

    Im Folgenden finden Sie ein Beispiel für die Datei /etc/hosts der sekundären Oracle WebLogic Server for OCI-Compute-Instanz, einschließlich des Eintrags für den Frontend-Namen. 

    #################################
# 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 to secondary OCI LBR IP)
100.100.100.10    mysoa.example.com
  2. Falls dies noch nicht geschehen ist, führen Sie dieselben Schritte auf den primären Oracle WebLogic Server-Hosts aus. Der Frontend-Name muss auf die IP des primären Load Balancers verweisen.
    Im Folgenden finden Sie ein Beispiel für die Datei /etc/hosts des primären On-Premise-Hosts von Oracle WebLogic Server, einschließlich des Eintrags für den Frontend-Namen. 
    #################################
# 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 to primary Load Balancer IP)
10.10.10.100    mysoa.example.com
  3. Wenn Ihr Oracle WebLogic Server-System mehr virtuelle Frontend-Namen verwendet, fügen Sie sie der Datei nach derselben Regel hinzu.
Domain Name System (DNS) verwenden
Dieser Modus ist gültig, wenn getrennte DNS-Server in primären On-Premise- und sekundären Oracle Cloud Infrastructure-(OCI-)Instanzen verwendet werden. Andernfalls kann dies zu Konflikten bei der Namensauflösung führen.

Wenn Sie diese Lösung verwenden, können Sie den Frontend-Namen (der auf die IP des sekundären Load Balancers verweist) zu dem DNS-Service hinzufügen, der von den sekundären Middle Tiers verwendet wird. In der Primärdatenbank wird erwartet, dass der Frontend-Name bereits aufgelöst ist, der auf die IP des primären Load Balancers verweist.

In der Primärdatenbank wird erwartet, dass der Frontend-Name bereits aufgelöst ist, der auf die IP des primären Load Balancers verweist.