1. Configurare una soluzione DR ibrida per Oracle SOA Suite
  2. Preparazione del livello Web su OCI

Preparazione del livello Web su OCI

Esegui il provisioning e configura il tuo sito secondario su Oracle Cloud Infrastructure (OCI) in modo che sia coerente con il tuo sito principale on premise.

Nota:

Puoi trovare il codice Terraform per creare le risorse descritte in questa sezione (il load balancer OCI, il certificato SSL, i set e i backend backend backend, i criteri di instradamento, i listener e i set di regole) in Scarica codice.

(Facoltativo) Preparare gli host Oracle HTTP Server

Crea e configura le istanze di computazione Oracle HTTP Server in Oracle Cloud Infrastructure.

Nota:

La creazione e la configurazione di Oracle HTTP Server è facoltativa. È possibile configurare il livello Web su OCI utilizzando solo il load balancer OCI (senza utilizzare Oracle HTTP Server).

Eseguire il provisioning degli host Oracle HTTP Server

Creare un'istanza di computazione nella subnet di livello Web Oracle Cloud Infrastructure (OCI) per ogni host Oracle HTTP Server primario in locale. Le istanze di computazione devono utilizzare l'immagine del sistema operativo e la forma di computazione più simili all'immagine e alla forma utilizzate dagli host Oracle HTTP Server on premise.

Ogni Oracle HTTP Server in esecuzione in OCI deve disporre di un contratto di licenza e supporto valido oltre al contratto di licenza e supporto utilizzato per coprire l'Oracle HTTP Server in esecuzione on premise. È possibile utilizzare le immagini di Oracle WebLogic Server per OCI per creare istanze di computazione per Oracle HTTP Server su Oracle Cloud. Le istanze di computazione create con queste immagini includono l'abilitazione per l'esecuzione di Oracle HTTP Server e vengono fatturate in base all'OCPU/ora per l'abilitazione all'esecuzione del software WebLogic quando sono in esecuzione. Quando si creano le istanze di computazione con Oracle WebLogic Server per OCI, è possibile utilizzare la console delle istanze di computazione o il Marketplace. Queste immagini sono disponibili per i sistemi operativi Oracle Linux 7.9 e Oracle Linux 8.5.

Questo esempio utilizza due istanze di computazione in un singolo dominio di disponibilità all'interno del compartimento, come mostrato nella tabella.

Nome Compartimento Dominio di disponibilità Immagine Forma VCN Sottorete
hydrohs1 HyDRCompmt AD1 Immagine UCM di Oracle WebLogic Enterprise Edition (Oracle Linux 7.9) VM.Standard2.2 idrvcn webTierSubnet
hydrohs2 HyDRCompmt AD1 Immagine UCM di Oracle WebLogic Enterprise Edition (Oracle Linux 7.9) VM.Standard2.2 idrvcn webTierSubnet

Per eseguire il provisioning delle istanze di computazione mediante la console delle istanze di computazione, effettuare le operazioni riportate di seguito.

  1. Eseguire il login alla console OCI per la tenancy.
  2. Selezionare l'area appropriata.
  3. Fare clic sul menu di navigazione, selezionare Computazione. Fare clic su Istanze, quindi su Crea istanza.
  4. Immettere i nomi per l'istanza di computazione e il compartimento.
  5. In Posizionamento selezionare il dominio di disponibilità in cui creare l'istanza. Se l'area OCI dispone di più domini di disponibilità, è possibile posizionare le istanze di computazione WebLogic in domini di disponibilità diversi.
  6. In Immagine e forma fare clic su Modifica immagine ed eseguire le operazioni riportate di seguito.
    1. Nell'elenco a discesa Origine immagine selezionare Immagini Oracle, quindi selezionare Immagine UCM Oracle WebLogic Server Enterprise Edition dalla lista di immagini Oracle WebLogic Server for OCI.
    2. Per l'immagine selezionata, fare clic sulla freccia a destra, quindi selezionare la versione di generazione dell'immagine per le immagini a pagamento.
      • Oracle Linux 7.9 (con etichetta release-ol7.9-build-timestamp)
      • Oracle Linux 8.5 (con etichetta release-ol8.5-build-timestamp)
    3. Rivedere i termini e le condizioni. Selezionare la casella di controllo Condizioni d'uso Oracle e fare clic su Seleziona immagine.
  7. In Immagine e forma fare clic su Modifica forma. Selezionare il tipo di istanza e la forma più simile agli host primari.
    Per un elenco delle forme supportate, vedere Immagini per Oracle WebLogic Server per OCI.
  8. Selezionare la VCN, la subnet (subnet del livello Web) e il dominio di disponibilità dell'ambiente.
    Per specificare il tipo di capacità e il dominio di errore, fare clic su Mostra opzioni avanzate.
  9. Configurare la rete per l'istanza. Per specificare le impostazioni di rete avanzate, fare clic su Mostra opzioni avanzate.
  10. In Aggiungi chiavi SSH generare una chiave, caricare la chiave pubblica o incollare le chiavi.
  11. In Volume di avvio, specificare le opzioni di dimensione e cifratura per il volume di avvio dell'istanza.
  12. Fare clic su Mostra opzioni avanzate per configurare le impostazioni avanzate.
  13. Fare clic su Crea.
  14. Ripetere i passi per creare un'altra istanza di computazione.

Preparare gli utenti e i gruppi del sistema operativo

Nelle istanze di computazione secondarie sono necessari gli stessi utenti e gruppi utilizzati dal software Oracle on premise primario.

Le immagini Oracle WebLogic Server for Oracle Cloud Infrastructure dispongono già di un utente e di un gruppo oracle. Tuttavia, questi valori (nome utente, nome gruppo, uid e gid) potrebbero non corrispondere ai valori presenti nell'istanza primaria e sarà necessario configurare gli host secondari in modo che corrispondano ai valori dell'utente e del gruppo oracle primario. Gli esempi riportati di seguito mostrano come configurare gli host secondari in questo livello in modo che corrispondano ai valori dell'utente e del gruppo oracle primario.

Ogni gruppo e utente nelle istanze di computazione OCI deve avere lo stesso ID in ogni nodo e lo stesso ID presente nel nodo primario.
  1. Identificare l'utente, il gruppo e gli ID dell'utente oracle negli host primari eseguendo il login a un host in locale con l'utente oracle, quindi utilizzare il comando id.
    [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

    La tabella riportata di seguito mostra alcuni esempi di utenti e gruppi per un tipico ambiente in locale.

    Utente o gruppo Nome ID Descrizione
    Utente oracle 1001 Il proprietario del software Oracle
    Gruppi oinstall 1002 Gruppo di principal dell'utente oracle
    dba 1001 Gruppo secondario dell'utente oracle
  2. Identificare gli utenti, i gruppi e gli ID esistenti negli host secondari utilizzando la shell SSH per accedere all'istanza creata di recente come utente opc. Eseguire il login a un host secondario con l'utente opc, quindi sudo per l'utente oracle ed eseguire il comando id.
    [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

    La tabella riportata di seguito mostra l'utente e il gruppo oracle già esistenti nelle istanze di computazione secondarie.

    Utente o gruppo Nome ID Descrizione
    Utente oracle 1001 Il proprietario del software Oracle
    Gruppi oracle 1001 Gruppo di principal dell'utente oracle
    docker 1002 Gruppo secondario dell'utente oracle
  3. Di seguito sono riportati gli scenari e le soluzioni possibili.
    • Gli utenti e i gruppi secondari sono nomi e ID diversi da quelli primari.

      Soluzione: creare gli utenti e i gruppi nel database secondario così come esistono nel database primario.

    • Gli utenti e i gruppi secondari sono gli stessi nomi, ma ID diversi rispetto a quelli principali.

      Soluzione: modificare gli ID nella secondaria in modo che corrispondano agli ID della principale.

    • Gli utenti e i gruppi nel nome secondario sono nomi diversi da quelli nel nome principale, ma gli stessi ID.

      Soluzione: modificare i nomi dell'utente e del gruppo nel gruppo secondario.

    • Sono presenti conflitti: alcuni ID dell'utente o dei gruppi principali vengono utilizzati da altri utenti o gruppi nella pagina secondaria.

      Soluzione: correggere il conflitto modificando l'ID dell'utente o del gruppo in conflitto nella parte secondaria, quindi creare l'utente o i gruppi nella parte secondaria in modo che corrispondano a quelli presenti nella parte principale.

    La tabella seguente contiene un riepilogo dei comandi che è possibile utilizzare per risolvere i conflitti:

    Azione Comando (eseguire come utente root)
    Per creare un nuovo gruppo groupadd group_name -g group_id

    Ad esempio:

    groupadd oinstall -g 1002 groupadd dba -g 1001
    Per creare un nuovo utente useradd -u user_id user_name -g principal_group -G other groups

    Ad esempio:

    useradd -u 1001 oracleuser -g oinstall -G dba
    Per modificare il gruppo principale dell'utente usermod -g new_primary_groupname user_name
    Per aggiungere un utente a un gruppo usermod -a -G secondary_groupname user_name
    Per modificare l'ID di un utente

    usermod -u new_id user_name

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

    Ad esempio, l'ID dell'utente oracle viene modificato da 1001 a 501:

    usermod -u 501 oracle

    find / -user 1001 -exec chown -h oracle {} \;
    Per modificare l'ID di un gruppo

    groupmod -g new_id group_name

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

    Ad esempio, l'ID del gruppo oracle viene modificato da 1001 a 501:

    groupmod -g 501 oracle

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

    Nota:

    Oracle consiglia di apportare le modifiche nelle istanze di computazione OCI secondarie. Non modificare i valori ID nel database primario.

    Di seguito è riportato un esempio in cui gli ID dei gruppi utilizzati negli host primari sono già utilizzati da altri gruppi negli host secondari. Per risolvere il conflitto, sono necessarie le azioni riportate di seguito.

    1. Il gruppo docker nel gruppo secondario utilizza l'ID 1002, che è in conflitto con l'ID del gruppo primario oinstall.
      Per risolvere il conflitto, modificare l'ID del gruppo docker negli host secondari in un ID diverso e non in conflitto. Ad esempio, selezionare 1005 come nuovo ID e verificare che non venga utilizzato confermando che non venga visualizzato nel file /etc/group.
      [opc@hydrsoa1 ~]$ sudo -s  
[root@hydrsoa1 ~]$ more /etc/group | grep 1005
      Quando si conferma che l'ID non è utilizzato, modificare l'ID del gruppo nel nuovo ID.
      [opc@hydrsoa1 ~]$ sudo -s 
[root@hydrsoa1 ~]$ groupmod -g 1005 docker
[root@hydrsoa1 ~]$ find / -group 1002 -exec chgrp -h docker {} \;
    2. Il gruppo oracle nel gruppo secondario utilizza l'ID 1001, che è in conflitto con l'ID del gruppo primario dba.
      Per risolvere il conflitto, modificare l'ID del gruppo oracle negli host secondari in un ID diverso e non in conflitto. Ad esempio, selezionare 1006 come nuovo ID e verificare che non venga utilizzato confermando che non venga visualizzato nel file /etc/group.
      [opc@hydrsoa1 ~]$ sudo -s 
[root@hydrsoa1 ~]$ more /etc/group | grep 1006
      Quando si conferma che l'ID non è utilizzato, modificare l'ID del gruppo nel nuovo ID.
      [opc@hydrsoa1 ~]$ sudo -s 
[root@hydrsoa1 ~]$ groupmod -g 1006 oracle
[root@hydrsoa1 ~]$ find / -group 1001 -exec chgrp -h oracle {} \;
    3. Creare i gruppi dell'utente oracle oinstall e dba negli host secondari con gli stessi ID degli ID primari. 
      [opc@hydrsoa1 ~]$ sudo -s
[root@hydrsoa1 ~]$ groupadd oinstall -g 1002
[root@hydrsoa1 ~]$ groupadd dba -g 1001
    4. Poiché l'utente oracle ha lo stesso nome e ID sia nel database primario che in standby, non sono necessarie modifiche.
      È tuttavia necessario modificare il gruppo principale dell'utente in oinstall negli host secondari.
      [root@hydrsoa1 ~]$ usermod -g oinstall oracle
      Aggiungere quindi l'utente al gruppo dba. 
      [root@hydrsoa1 ~]$ usermod -a -G dba oracle
    5. Verificare che l'output del comando id per l'utente oracle negli host secondari corrisponda al primario per i gruppi principale e secondario.
      Output nel database primario:
      [oracle@host3.myopnetwork.com ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)
      Output nel secondario (il secondario può avere gruppi aggiuntivi):
      oracle@hydrsoa1 ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba),1005(docker)
        …
    6. (Consigliato) Eseguire un reboot dell'host dopo le modifiche.
  4. (Facoltativo ma consigliato) Abilitare l'accesso SSH all'utente oracle.
    È utile in questa topologia DR in quanto consente all'utente oracle una connessione diretta per eseguire i comandi utilizzati per copiare il contenuto del file system dal database primario al file system secondario.
    1. Copiare la chiave pubblica utilizzata per connettersi alle istanze di computazione in un file di testo. Sarà necessario utilizzarla in seguito in questa procedura.
    2. Eseguire il login all'istanza e sudo all'utente root.
    3. Creare una directory .ssh nella home directory del nuovo utente.
      mkdir -p /home/oracle/.ssh
    4. Copiare la chiave pubblica SSH utilizzata per connettersi al calcolo nel file.
      /home/oracle/.ssh/authorized_keys
    5. Modificare il proprietario e il gruppo della directory /home/oracle/.ssh nell'utente oracle.
      chown -R oracle:oinstall /home/oracle/.ssh
    6. Verificare la connessione mediante SSH utilizzando l'utente oracle e la chiave privata.
    7. Impostare le autorizzazioni del file authorized_keys su 600.
      chmod 600 /home/oracle/.ssh/authorized_keys

Preparare i requisiti del sistema operativo

I file binari Oracle HTTP Server verranno copiati dagli host Oracle HTTP Server primari agli host Oracle HTTP Server secondari. Non è pertanto necessario eseguire runinstaller negli host secondari. Poiché le immagini Oracle WebLogic Server for Oracle Cloud Infrastructure sono preparate per il software WebLogic, non è necessario aggiungere manualmente i package per WebLogic. Tuttavia, questi host Oracle HTTP Server eseguiranno il prodotto Oracle HTTP Server. Accertarsi che gli host secondari soddisfino i requisiti per Oracle HTTP Server.
  1. Assicurarsi che l'ambiente soddisfi i requisiti di installazione minimi per i prodotti installati negli host principali. Controllare il documento corrispondente in Oracle Fusion Middleware System Requirements and Specifications.
  2. Verificare i pacchetti di sistema necessari per la versione e il sistema operativo in uso.
  3. Installare i pacchetti di sistema mancanti con yum.

    In questo esempio vengono utilizzati Oracle HTTP Server 12.2.1.4 e Oracle Linux 7. Alcuni dei pacchetti necessari sono già installati nelle istanze di computazione di livello intermedio di Oracle Cloud Infrastructure (OCI). In questo esempio, mancavano i seguenti componenti e doveva essere installato con yum: 

    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. Configurare i limiti di file e proc nel file /etc/security/limits.conf. Rivedere i limiti negli host Oracle HTTP Server in locale e impostare di conseguenza i valori nelle istanze di computazione Oracle HTTP Server OCI.

Preparazione degli alias dei nomi host per Oracle HTTP Server

Configurare gli stessi nomi host virtuali utilizzati dagli host Oracle HTTP Server nell'ambiente primario come alias nelle istanze di computazione Oracle Cloud Infrastructure (OCI) Oracle HTTP Server secondarie, ma puntare agli indirizzi IP degli host secondari.

Ciò può essere implementato in 2 modi:

  • Aggiungere i nomi host come alias ai file /etc/hosts delle istanze di computazione Oracle WebLogic Server for OCI.
  • Utilizza una vista DNS privata nella VCN OCI secondaria.
Usa file /etc/hosts
I nomi host virtuali utilizzati come alias nei server primari vengono aggiunti ai file /etc/hosts degli host secondari, indicando gli indirizzi IP degli host secondari. Questa modalità è valida in tutti gli scenari quando il server DNS è lo stesso nei siti principali in locale e in quelli secondari di Oracle Cloud Infrastructure (OCI) e anche quando vengono utilizzati server DNS separati nei siti primari e secondari. Le voci nel file /etc/hosts hanno la precedenza sulla risoluzione DNS, poiché questa è la precedenza definita out-of-the-box nella direttiva "hosts" del file /etc/nsswitch.conf.

Tuttavia, questo metodo richiede l'aggiunta manuale delle voci a tutti gli host di Oracle HTTP Server:

  1. Modificare il file /etc/oci-hostname.conf di ogni istanza di computazione Oracle HTTP Server e impostare la proprietà PRESERVE_HOSTINFO=3 per conservare le voci /etc/hosts tra i riavvii dell'istanza.
  2. Utilizzare il comando hostname --fqdn per identificare i nomi host completi delle istanze di computazione OCI.
  3. Aggiungere le voci seguenti al file /etc/hosts delle istanze di computazione Oracle HTTP Server OCI:
    #################################
# 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

    Nota:

    Oltre ad aggiungere i nomi virtuali degli host Oracle HTTP Server come alias, vengono aggiunti i nomi virtuali degli host Oracle WebLogic Server, puntando agli IP dell'host WebLogic Server secondario. Poiché Oracle HTTP Server comunicherà con gli host WebLogic Server utilizzando i nomi degli host virtuali.
    The following is an example of the /etc/hosts file in the secondary Oracle HTTP Server compute instance:
    #################################
# 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
    Di seguito è riportato un esempio del file /etc/hosts esistente degli host primari di Oracle HTTP Server:
    #################################
# 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
Usa DNS (Domain Name System)
I nomi host virtuali utilizzati dagli host Oracle HTTP Server primari vengono aggiunti al resolver DNS utilizzato dalla VCN degli host Oracle HTTP Server secondari, indicando gli indirizzi IP degli host Oracle HTTP Server secondari. Questa modalità è valida quando vengono utilizzati server DNS separati in locale primario e secondario su Oracle Cloud Infrastructure (OCI). In caso contrario, può causare conflitti nella risoluzione dei nomi. Il server di ciascun sito deve risolvere questi nomi con i propri IP.
Il vantaggio di questo metodo è che è possibile aggiungere tutte le voci a una vista DNS privata, invece di aggiungerle ai file /etc/hosts di tutti gli host.

Aggiungere le voci per i nomi host virtuali di Oracle HTTP Server alla vista privata creata in OCI nel passo Preparare il livello intermedio in OCI:

  1. Nella console OCI andare all'area secondaria e individuare la vista privata:
    1. Fare clic su Networking, Gestione DNS, Viste private.
      Ad esempio HYBRID_DR_VIRTUAL_HOSTNAMES
    2. Nella vista privata, fare clic sul nome della zona creato per aggiungere gli host virtuali.
      In questo esempio: example.com.
    3. Aggiungere i nomi host virtuali di Oracle HTTP Server a questa zona, ma risolti con gli IP degli host Oracle HTTP Server secondari.

      Per aggiungere il record, è sufficiente fornire il nome non FQDN nel menu della console OCI. Il dominio DNS della zona viene aggiunto automaticamente al record.

    4. Fare clic su Pubblica modifiche.
  2. Convalidare gli host SECONDARY di risoluzione eseguendo ping e nslookup dei nomi host virtuali aggiunti.
    Devono essere risolti con gli IP SECONDARI equivalenti.

Aprire le porte necessarie nei firewall dell'host OCI

Ogni istanza di computazione ha un servizio firewall locale. Per motivi di sicurezza, la configurazione predefinita prevede il rifiuto delle connessioni per tutte le porte, ad eccezione del minimo richiesto (ssh, dhcp). È necessario aprire le porte utilizzate da Oracle HTTP Server.
  1. Controllare lo stato e le regole del servizio firewall.
    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:
    Questo output indica che non vi sono porte aperte diverse da 22.
  2. Come utente root, utilizzare i comandi firewall-cmd per aprire le porte utilizzate come porte di ascolto da Oracle HTTP Server in ogni istanza di computazione Oracle HTTP Server.
    Ad esempio:
    firewall-cmd --permanent --add-port=7001/tcp 
firewall-cmd --permanent --add-port=8890/tcp 
service firewalld reload
  3. Controllare lo stato e le regole del servizio firewall.
    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:

Creare le variabili di ambiente utente oracle per Oracle HTTP Server

È comune disporre di variabili di ambiente relative a Oracle HTTP Server nel profilo dell'utente oracle negli host Oracle HTTP Server. Ad esempio, ORACLE_HOME, JDK_HOME, PATH, WEB_DOMAIN_HOME e altri.
  1. Rivedere i file del profilo dell'utente oracle negli host Oracle HTTP Server principali.
  2. In secondario, aggiungere le stesse variabili di ambiente relative a Oracle HTTP Server ai file di profilo dell'utente oracle (.bashrc o .bash_profile).

    Tenere presente che il file .bashrc dell'utente oracle negli host di Oracle HTTP Server potrebbe già contenere variabili definite (MIDDLEWARE_HOME, WLS_HOME e così via), ma probabilmente si riferiscono alle cartelle dell'ambiente e non sono valide per l'utente. Assicurarsi di rimuoverli o modificarli in base alle cartelle dell'ambiente.

Replicare il prodotto e la configurazione di Oracle HTTP Server dal database primario

Poiché le istanze di computazione OCI di Oracle HTTP Server secondarie vengono create come host Oracle HTTP Server principali (lo stesso sistema operativo, gli stessi ID utente, gli alias dei nomi host e così via), è possibile utilizzare rsync per copiare i file binari e la configurazione di Oracle HTTP Server dai nodi Oracle HTTP Server principali.

In alternativa, è possibile scaricare il software Oracle HTTP Server, installarlo e configurarlo da zero nelle istanze di computazione Oracle HTTP Server OCI. Questo approccio non rientra nell'ambito di applicazione del presente documento. Tuttavia, è necessario utilizzare questo approccio quando le istanze di computazione OCI di Oracle HTTP Server hanno un sistema operativo diverso rispetto agli host Oracle HTTP Server primari.

I file binari e i file di configurazione di Oracle HTTP Server in genere risiedono nella memoria privata. In OCI, puoi utilizzare il volume a blocchi di cui dispone l'istanza di computazione per impostazione predefinita. In alternativa, puoi creare un nuovo volume a blocchi per ogni computazione Oracle HTTP Server (come descritto in Preparare i volumi a blocchi OCI) ed eseguire il MOUNT di ciascun volume nelle istanze di computazione Oracle HTTP Server (come descritto in Eseguire il MOUNT dei volumi a blocchi OCI).

Questo esempio utilizza il volume a blocchi predefinito delle istanze di computazione Oracle HTTP Server senza creare ulteriori volumi a blocchi.

  1. Identificare le cartelle dei file binari Oracle HTTP Server e la configurazione nei nodi Oracle HTTP Server principali.
    Ad esempio:
  2. Creare le stesse cartelle nelle istanze di computazione Oracle HTTP Server OCI. È necessario utilizzare lo stesso percorso utilizzato nel percorso principale.
    1. SSH per le istanze di computazione del sistema operativo e da sudo a utente root.
    2. Creare le cartelle e impostare oracle come proprietario.
      Ad esempio:
      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. Ripetere le operazioni per ogni istanza di computazione OCI di Oracle HTTP Server.
  3. Utilizzare rsync per copiare la cartella prodotti dal file WEBHOST1 primario in locale al file WEBHOST1 remoto. Ripetere il passo per copiare la cartella dei prodotti da WEBHOST2 a WEBHOST2 remoto. Ripetere questo passo per qualsiasi altra istanza di calcolo di Oracle HTTP Server.

    Nota:

    È possibile utilizzare uno script di esempio per copiare la cartella dei prodotti Oracle HTTP Server dal file WEBHOST1 primario in locale al file WEBHOST1 remoto.

    Andare a Scarica codice per scaricare lo script.

  4. Utilizzare rsync per copiare la cartella di configurazione Oracle HTTP Server dal file primario in locale WEBHOST1 al file WEBHOST1 remoto. Ripetere il passo per copiare la cartella di configurazione da WEBHOST2 a WEBHOST2 remoto. Ripetere questo passo per qualsiasi altra istanza di calcolo di Oracle HTTP Server.

    Nota:

    È possibile utilizzare uno script di esempio per copiare la cartella di configurazione Oracle HTTP Server dal file WEBHOST1 primario in locale al file WEBHOST1 remoto.

    Andare a Scarica codice per scaricare lo script.

  5. Copiare il file /etc/oraInst.loc dagli host Oracle HTTP Server primari e salvarlo negli host secondari.
    Questo file contiene solo la posizione di oraInventory e non cambia nel tempo, quindi questa copia è un'azione una tantum.
  6. Se la cartella oraInventory si trova nella cartella dei prodotti, viene copiata insieme alla Oracle home di Oracle HTTP Server. Se la cartella oraInventory si trova in una posizione diversa, assicurarsi di copiarla anche negli host secondari.

La configurazione di Oracle HTTP Server e i file binari non cambiano di frequente nel tempo. Dopo questa replica iniziale, è possibile ripetere la stessa replica durante il ciclo di vita. In alternativa, è possibile gestire manualmente la configurazione di Oracle HTTP Server nel database primario e secondario implementando le modifiche di configurazione di Oracle HTTP Server in entrambi i siti.

Prepara load balancer OCI

Crea e configura il load balancer di Oracle Cloud Infrastructure sul cloud.

Nota:

Puoi trovare il codice Terraform per creare le risorse descritte in questa sezione (il load balancer OCI, il certificato SSL, i set e i backend backend backend, i criteri di instradamento, i listener e i set di regole) in Scarica codice.

Esegui provisioning load balancer OCI

Per garantire la coerenza con il sito primario in locale, eseguire il provisioning di un load balancer nel sito secondario in Oracle Cloud Infrastructure (OCI) come punto di accesso al sistema.

  1. Eseguire il login alla console OCI.
  2. Selezionare l'area e il compartimento appropriati.
  3. Passare a Networking, quindi a Load balancer. Fare clic su Crea load balancer.
  4. Selezionare il tipo di Load balancer.
  5. Fornire un nome per il load balancer.
    Ad esempio: hyDRlbr.
  6. Scegliere il tipo di visibilità (pubblico o privato) e la larghezza di banda corrispondente alle proprie esigenze.
    • Se si accede al sistema da client esterni tramite Internet, scegliere la visibilità pubblica. Il load balancer OCI utilizzerà un IP pubblico.
    • Se l'accesso al sistema avviene solo internamente, puoi scegliere la visibilità privata per eseguire il provisioning del load balancer solo con un IP privato.
  7. Selezionare la VCN e la subnet appropriate.
    Ad esempio, hydrvcn e webTierSubnet.
  8. Non aggiungere alcun back-end a questo punto.
  9. Lasciare il listener predefinito con i valori predefiniti
  10. Fare clic su Invia.
Salvare l'IP del load balancer OCI (ad esempio 100.100.100.10).

Carica i certificati

Caricare i certificati utilizzati dal load balancer primario.

  1. Nella console fare clic su Load balancer, Certificati, quindi su Aggiungi certificato.
  2. Caricare il certificato SSL pubblico e la chiave privata del certificato utilizzato dal load balancer primario. Caricare i certificati CA (autorità di certificazione), se utilizzati.
  3. Immettere un nome per il certificato, quindi fare clic su Aggiungi certificato.
    Il nuovo certificato viene visualizzato nell'elenco dei certificati per il load balancer.
  4. Se si utilizzano più certificati per accedere al sistema principale, ripetere questi passaggi per caricare tutti i certificati.

Creare i set backend

Per set backend si intende un'entità logica contenente un elenco di server backend che eseguono le stesse applicazioni. Quando si definisce un set backend, è necessario specificare un criterio di bilanciamento del carico e un test di controllo dello stato. Successivamente, puoi aggiungere l'elenco dei server backend.

La configurazione dei set backend dipende dal fatto che si stia utilizzando Oracle HTTP Server o meno davanti agli host WebLogic Server.

Se si utilizza Oracle HTTP Server, il load balancer di Oracle Cloud Infrastructure (OCI) invia le richieste ai server HTTPS. Creare un set backend per ogni porta esposta dai server HTTPS. Ad esempio, creare un set backend per il listener di Oracle HTTP Server che fornisce l'accesso alle applicazioni e un altro set backend per il listener di Oracle HTTP Server che fornisce l'accesso a ogni console di amministrazione di Oracle WebLogic Server.

Se non si utilizza Oracle HTTP Server, il load balancer OCI invia direttamente le richieste ai server WebLogic. Creare un set backend per ogni cluster di Oracle WebLogic Server e un altro set backend per il server di amministrazione.

  1. Eseguire il login alla console OCI.
  2. Selezionare l'area e il compartimento appropriati.
  3. Nel menu di navigazione fare clic su Networking, quindi su Load balancer.
  4. Fare clic sul load balancer al quale si desidera aggiungere un backend.
  5. Fare clic su Set backend nel menu Risorse, quindi fare clic su Crea set backend.
  6. Immettere quanto riportato di seguito nella finestra di dialogo Crea set backend.
    1. Nome: specificare un nome per il set backend.
      I nomi di set backend validi includono solo caratteri alfanumerici, lineette e caratteri di sottolineatura.
    2. Criterio di distribuzione del traffico: selezionare Arrotondamento ponderato.
    3. Persistenza sessione: selezionare Abilita persistenza cookie del load balancer.
    4. Nome cookie: immettere un nome per il cookie utilizzato per abilitare la persistenza della sessione.
    5. Attributi: selezionare Secure.
    6. Controllo dello stato: selezionare TCP per controllare la porta o HTTP per controllare il percorso URL (URI) e il codice di risposta previsto.
      Di seguito sono riportati alcuni esempi HTTP per il controllo dello stato.
      • OHS_Admin_backendset: percorso URL /console, codice stato 302
      • OHS_HTTP_backendset:
        • Percorso URL /, codice stato 200 (o 404, a seconda della configurazione di Oracle HTTP Server)
        • Percorso URL /app1, codice stato 200
  7. Fare clic su Crea.

Se Oracle HTTP Server ascolta porte aggiuntive per altri servizi, creare un set backend per ogni servizio in modo simile.

Di seguito viene riportato un esempio dei set backend quando si utilizza Oracle HTTP Server.

Componente Nome set backend Politica di distribuzione del traffico Persistenza sessione Nome cookie (esempio) Attributo: sicuro Controllo stato
Server di amministrazione OHS_Admin_backendset Round Robin ponderato Abilitare la persistenza dei cookie del load balancer X-Oracle-LBR-ADMIN-Backendset Deselezionato TCP o HTTP
Tutti i componenti SOA
  • Oracle SOA Suite
  • Oracle Service Bus
  • Oracle B2B
  • Gestione business process
  • Oracle Enterprise Scheduler (ESS)
  • Business Activity Monitoring (BAM)
 OHS_HTTP_backendset Round Robin ponderato Abilitare la persistenza dei cookie del load balancer X-Oracle-LBR-OHS-HTTP-Backendset Selezionata TCP o HTTP
Oracle Web Services Manager OHS_HTTP_internal_backendset Round Robin ponderato Abilitare la persistenza dei cookie del load balancer X-Oracle-LBR-OHS-Internal-HTTP-Backendset Deselezionato TCP o HTTP

Se Oracle HTTP Server ascolta porte aggiuntive per altri servizi, creare un set backend per ogni servizio in modo simile.

Di seguito viene riportato un esempio dei set backend quando non si utilizza Oracle HTTP Server.

Componente Nome set backend Criteri di distribuzione del traffico Persistenza sessione Nome cookie (esempio) Attributo: sicuro Controllo stato
Tutti i prodotti (admin) Admin_backendset Round Robin ponderato Abilitare la persistenza dei cookie del load balancer X-Oracle-LBR-ADMIN-Backendset Deselezione TCP o HTTP
Oracle Web Services Manager WSM_backendset Round Robin ponderato Abilitare la persistenza dei cookie del load balancer X-Oracle-LBR-WSM-Backendset Deselezione TCP o HTTP
Oracle SOA Suite, Business Process Management e Oracle B2B SOA_backendset Round Robin ponderato Abilitare la persistenza dei cookie del load balancer X-Oracle-LBR-SOA-Backendset Selezionata TCP o HTTP
Oracle Service Bus OSB_backendset Instradamento sequenziale ponderato Abilita persistenza cookie del load balancer X-Oracle-LBR-OSB-Backendset Selezionata TCP o HTTP
Oracle Enterprise Scheduler (ESS) ESS_backendset Instradamento sequenziale ponderato Abilita persistenza cookie del load balancer X-Oracle-LBR-ESS-Backendset Selezionata TCP o HTTP
Business Activity Monitoring (BAM) BAM_backendset Instradamento sequenziale ponderato Abilita persistenza cookie del load balancer X-Oracle-LBR-BAM-Backendset Selezionata TCP o HTTP

Se si dispone di cluster WebLogic aggiuntivi, creare un set backend per ogni cluster in modo simile.

Definire i backend per ogni set backend

Definire i backend per ogni set backend nel load balancer di Oracle Cloud Infrastructure (OCI).

Se si utilizza Oracle HTTP Server, aggiungere i nodi Oracle HTTP Server e le porte appropriate come backend in ciascun set backend.

Se non si utilizza Oracle HTTP Server, aggiungere i nodi Oracle WebLogic Server e le porte appropriate come backend in ciascun set backend.

  1. Nella console selezionare un set backend. Fare clic su Backend, quindi su Aggiungi backend.
  2. Immettere l'indirizzo IP e la porta per il server backend.

La tabella mostra i set backend creati nell'esempio di questo documento quando si utilizza Oracle HTTP Server:

Nome set backend Backend
OHS_Admin_backendset Istanze di computazione:
  • hydrohs1, la porta Oracle HTTP Server per il listener delle console (ad esempio, 7001)
  • hydrohs2, la porta Oracle HTTP Server per il listener delle console (ad esempio, 7001)
OHS_HTTP_backendset Istanze di computazione:
  • hydrohs1, la porta Oracle HTTP Server per il listener HTTP (ad esempio 8890)
  • hydrohs2, la porta Oracle HTTP Server per il listener HTTP (ad esempio 8890)
OHS_HTTP_internal_backendset Istanze di computazione:
  • hydrohs1, la porta Oracle HTTP Server per il listener interno HTTP, ad esempio 8891.
  • hydrohs2, la porta Oracle HTTP Server per il listener interno HTTP, ad esempio 8891.

La tabella mostra i set backend creati nell'esempio di questo documento quando NON si utilizza Oracle HTTP Server:

Nome set backend Backend
Admin_backendset Indirizzi IP:
  • IP virtuale del server di amministrazione creato in precedenza, porta del server di amministrazione (7001)
WSM_backendset Istanze di computazione:
  • hydrsoa1, porta server1 WSM (7010)
  • hydrsoa2, porta server2 WSM (7010)
SOA_backendset Istanze di computazione:
  • hydrsoa1, porta SOA server1 (8001)
  • hydrsoa2, porta SOA server2 (8001)
OSB_backendset Istanze di computazione:
  • hydrsoa1, porta server1 OSB (8010)
  • hydrsoa2, porta server2 OSB (8010)
ESS_backendset Istanze di computazione:
  • hydrsoa1, porta ESS server1 (8021)
  • hydrsoa2, porta ESS server2 (8021)
BAM_backendset Istanze di computazione:
  • hydrsoa1, porta BAM server1 (9001)
  • hydrsoa2, porta BAM server2 (9001)

Definire i criteri di instradamento e configurare le regole

I criteri di instradamento vengono utilizzati per inviare le richieste in entrata al set backend corretto. Ad esempio, una richiesta a /console viene inviata al set backend di amministrazione e una richiesta a /app1 viene inviata al set backend del cluster in cui è in esecuzione app1.

Se si utilizza Oracle HTTP Server, gli instradamenti (ad esempio /app1, /app2, /console e così via) vengono definiti in genere nella configurazione di Oracle HTTP Server. In questo caso, non è necessario definire i criteri e le regole di instradamento nel load balancer di Oracle Cloud Infrastructure (OCI).

Se non si utilizza Oracle HTTP Server, è necessario definire i criteri e le regole di instradamento nel load balancer OCI per inviare le richieste al set backend appropriato.

  1. Nella console Oracle Cloud Infrastructure fare clic sul load balancer.
  2. Fare clic su Criteri di instradamento, quindi su Crea criteri di instradamento per definire i criteri.
    I criteri di instradamento vengono aggiunti ai listener del load balancer in un secondo momento.
  3. Immettere un nome per il criterio di instradamento (insieme di regole).
    Ad esempio Admin_Rules.
  4. Per creare regole nei criteri di instradamento, immettere un nome per la regola.
    Ad esempio Admin_routerule.
  5. Definire le condizioni delle regole per instradare le richieste a set backend diversi. Selezionare Se esiste una corrispondenza, quindi selezionare Tipo di condizione: Percorso, Operatore: Inizia con e immettere una stringa URL.
    Ad esempio, se una corrispondenza qualsiasi, Percorso, Inizia con, /console.
  6. Selezionare il set backend dal menu per configurare l'azione.
    Ad esempio OHS_Admin_backendset.
La tabella mostra i criteri e le regole di instradamento nel load balancer di Oracle Cloud Infrastructure creato in base all'esempio riportato in questo documento quando non si utilizza Oracle HTTP Server.
Componente Nome criterio di instradamento Regola Condizioni: se un percorso di corrispondenza qualsiasi inizia con Azione: percorso al set backend
Tutti i prodotti (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

(*) è possibile che siano necessari altri alias personalizzati per i task personalizzati

 SOA_backendset
Gestione business process 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

È possibile creare il numero desiderato di criteri di instradamento, regole e condizioni per l'ambiente in uso.

Creare i listener

Creare i listener per ogni combinazione di nome front-end e porta utilizzata per accedere al sistema. Devi utilizzare gli stessi nomi host (nomi frontend virtuali) e le stesse porte utilizzate dal load balancer primario.

  1. Aggiungere il nome host front-end virtuale come nome host nel load balancer di Oracle Cloud Infrastructure.
  2. Creare i listener.

La tabella riportata di seguito contiene un riepilogo dei listener creati nell'esempio di questo documento e dei relativi protocolli, porte, set backend, criteri di instradamento, nome host e uso SSL associati. Questo è solo un esempio di riferimento. Se il sistema utilizza altri nomi host front-end, porte o protocolli nel sistema Oracle WebLogic Server primario, è necessario creare i listener e i nomi host corrispondenti in base alle proprie esigenze. Ad esempio, se si utilizza un frontend alternativo per accedere alla console di Oracle WebLogic Server e alla console di Oracle Enterprise Manager.

Listener Protocollo Porta Set backend Criteri di instradamento HostName Usa SSL
Admin_listener HTTP 7001

OHS_Admin_backendset (se si utilizza Oracle HTTP Server)

Admin_backendset (se non si utilizza Oracle HTTP Server)

Admin_Rules mysoa.example.com No
HTTPS_listener HTTPS 443

OHS_HTTP_backendset (se si utilizza Oracle HTTP Server)

SOA_backendset (se non si utilizza Oracle HTTP Server)

SOA_Rules mysoa.example.com Sì
HTTP_listener HTTP 80 N/D* N/D mysoa.example.com No
Internal_listener HTTP 8888

OHS_HTTP_internal_backendset (se si utilizza Oracle HTTP Server)

WSM_backendset (se non si utilizza Oracle HTTP Server)

Internal_Rules mysoa.example.com No

* Il valore HTTP_listener in questo esempio viene utilizzato solo per il reindirizzamento delle richieste a HTTPS_listener (HTTPS). Il backend a esso assegnato non verrà utilizzato. Tuttavia, poiché è obbligatorio fornirne uno, è necessario fornirne uno senza SSL selezionato (utilizzare un set backend vuoto predefinito).

Crea il set di regole per le intestazioni SSL

Creare un set di regole per le intestazioni SSL nel load balancer Oracle Cloud Infrastructure (OCI) e associarlo al listener HTTPS.

Come nel sito principale, OCI Load Balancer interrompe SSL e la comunicazione tra il load balancer e il server backend viene eseguita tramite il protocollo HTTP. Per un funzionamento corretto, è necessario aggiungere intestazioni di richiesta nel load balancer OCI. Queste intestazioni vengono aggiunte alle richieste client fornite nel listener HTTPS, prima di essere inviate al backend WebLogic. Le intestazioni informano WebLogic che la comunicazione dal client finale al load balancer utilizzava HTTPS. In tal modo, qualsiasi URL creato dinamicamente da WebLogic verrà generato correttamente mediante HTTPS.
  1. Selezionare il Load balancer nella console. Fare clic su Set di regole, quindi su Crea set di regole.
  2. Immettere un nome per la regola.
    Ad esempio, SSLHeaders.
  3. Selezionare Specifica regole intestazione richiesta e aggiungere le azioni riportate di seguito.
    Azione Intestazione Valore
    Aggiungi intestazione richiesta is_ssl SSL
    Aggiungi intestazione richiesta WL-Proxy-SSL True
  4. Fare clic su Crea.
  5. Fare clic su Load balancer, quindi su Listener. Modificare il listener che utilizza HTTPS per associare la regola al listener HTTPS.
  6. Fare clic su +Additional Rule Set, quindi selezionare il set di regole SSLHeaders.

Creazione del set di regole per reindirizzare il protocollo HTTP a HTTPS

Creare una regola di reindirizzamento e associarla a HTTP_listener per reindirizzare la porta 80 alla porta 443. Per la topologia EDG, tutte le richieste che raggiungono la porta 80 (HTTP) nel load balancer devono essere reindirizzate alla porta 443 (HTTPS).

  1. Nella console selezionare il load balancer.
  2. Fare clic su Set di regole, quindi su Crea set di regole.
  3. Immettere un nome per la regola.
    Ad esempio, HTTP_to_HTTPS_redirect.
  4. Selezionare Specifica regole di reindirizzamento URL e aggiungere le azioni riportate di seguito.
    • Percorso di origine: /
    • Tipo di corrispondenza: forza una corrispondenza prefisso più lunga
    • Reindirizza a:
    • Protocollo: HTTPS
    • Host: {host} (lasciare il valore predefinito)
    • Porta: 443
    • Percorso: /{path} (lasciare il valore predefinito)
    • Query: ?{query} (lasciare il valore predefinito)
    • Codice risposta: 301 - Spostato definitivamente
  5. Fare clic su Load balancer, quindi su Listener. Modificare il listener che utilizza la porta HTTP 80 per associarlo al listener HTTP.
  6. Fare clic su +Additional Set di regole e selezionare la regola HTTP_to_HTTPS_redirect.

Aggiungere il nome e l'IP del frontend virtuale alle istanze di computazione SOA

In una topologia di recupero da errori irreversibili i client devono accedere al sistema utilizzando un nome FQDN frontend (in genere denominato nome frontend virtuale o URL vanity) indipendente dal centro dati. Questo nome frontend virtuale dovrebbe risolvere l'indirizzo IP del load balancer del sito attivo (primario) corrente.

Il sistema primario deve già utilizzare un nome virtuale frontend risolto dal DNS con l'IP del load balancer primario. Tuttavia, gli host Oracle SOA Suite di ciascun sito devono sempre risolvere il nome frontend con il load balancer locale, indipendentemente dalla risoluzione lato client con DNS. A tale scopo, il nome del front-end virtuale viene aggiunto al file /etc/hosts con l'indirizzo IP appropriato in ogni sito. È inoltre possibile ottenere questo risultato utilizzando diversi server DNS in ogni sito. In questo caso, il server DNS locale risolverà il nome frontend con l'IP del load balancer appropriato in ogni sito.

Usa file /etc/hosts
Il file /etc/hosts degli host Oracle WebLogic Server primari e secondari non deve essere modificato quando è presente uno switchover o un failover. Gli host Oracle WebLogic Server risolveranno sempre il nome front-end virtuale con il relativo IP front-end. L'aggiornamento DNS necessario durante le procedure di switchover e failover viene eseguito nei file DNS o host utilizzati dai client Oracle WebLogic Server.
  1. Come utente root, modificare il file /etc/oci-hostname.conf nelle istanze di computazione di Oracle WebLogic Server for Oracle Cloud Infrastructure secondarie e mappare il nome frontend all'IP del load balancer di Oracle Cloud Infrastructure (OCI).

    Di seguito è riportato un esempio del file /etc/hosts dell'istanza di computazione Oracle WebLogic Server for OCI secondaria, inclusa la voce per il nome front-end. 

    #################################
# 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. Se non è già stato fatto, eseguire gli stessi passi negli host Oracle WebLogic Server principali. Il nome frontend deve puntare all'IP del load balancer primario.
    Di seguito è riportato un esempio del file /etc/hosts dell'host Oracle WebLogic Server in locale primario, inclusa la voce per il nome front-end. 
    #################################
# 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. Se il sistema Oracle WebLogic Server utilizza più nomi front-end virtuali, aggiungerli al file seguendo la stessa regola.
Usa DNS (Domain Name System)
Questa modalità è valida quando i server DNS separati sono utilizzati in locale primario e secondario su Oracle Cloud Infrastructure (OCI). In caso contrario, può causare conflitti nella risoluzione dei nomi.

Se stai seguendo questo approccio, puoi aggiungere il nome frontend (che punta all'IP del load balancer secondario) al servizio DNS utilizzato dai livelli medi secondari. Nel database primario, il nome frontend è già stato risolto e punta all'IP del load balancer primario.

Nel database primario, è previsto che il nome front-end sia già stato risolto puntando all'IP del load balancer primario.