1. Configurare una soluzione DR ibrida per Oracle WebLogic Server
  2. Replica artifact del file system in OCI

Replica artifact del file system in OCI

I livelli medi secondari devono disporre di una replica degli artifact utilizzati dal dominio WebLogic Server nel database primario. Gli artifact possono essere statici o dinamici, a seconda della frequenza di modifica. Nell'ambito dell'impostazione DR, è necessario eseguire una replica iniziale degli artifact. Questa replica iniziale viene aggiornata durante il ciclo di vita del sistema.

Informazioni sugli artifact

Determinare il tipo di artifact da replicare.

  • Artifact statici: sono file e directory che non cambiano di frequente. tra cui:
    • Oracle home: in genere è costituita da una home Oracle e da una home Oracle WebLogic Server. Oracle Fusion Middleware consente di creare più server gestiti Oracle WebLogic Server da un'unica installazione di file binario. È possibile installare i file binari in una singola posizione in una memoria condivisa e riutilizzare questa installazione da server in nodi diversi. Per garantire la massima disponibilità, Oracle consiglia di utilizzare installazioni binarie ridondanti.
    • Oracle Inventory: orainventory è una cartella contenente una lista delle Oracle home esistenti e si trova in una cartella separata separata rispetto alla Oracle home. Il file /etc/oraInst.loc determina la posizione del file orainventory.
  • Artifact dinamici: sono file che cambiano di frequente. Questi artifact includono:
    • Home dominio: directory di dominio del server di amministrazione e dei server gestiti. In una topologia EDG, ASERVER_HOME si trova in una posizione condivisa e MSERVER_HOME si trova in una posizione privata e ogni server dispone del proprio MSERVER_HOME (anche se può essere memorizzato in un NFS).
    • Artifact di applicazione, ad esempio file .ear o .war.
    • Artifact di database, ad esempio il repository MDS e gli schemi dell'applicazione.
    • Aree di memorizzazione persistenti, ad esempio i provider JMS e i log delle transazioni. Oracle consiglia di memorizzare questi artifact nel database. Questo è l'approccio consigliato nella topologia EDG e particolarmente utile per gli ambienti DR (Disaster Recovery), in quanto vengono replicati automaticamente nel sito in standby tramite l'Oracle Data Guard di base.
    • Piani di distribuzione, utilizzati per aggiornare gli adattatori tecnologici, ad esempio file e adattatori JMS. Devono essere salvate in una posizione accessibile a tutti i nodi del cluster in cui vengono distribuiti gli artifact.
    • Altri artifact di runtime, ad esempio i file utilizzati dagli adattatori di file, i file trasferiti da MFT o altri artifact di runtime personalizzati.

Tutto il contenuto che risiede nel database (ad esempio il repository MDS, gli schemi di applicazione, JMS e TLOG e i dati personalizzati) viene replicato automaticamente nel sito secondario tramite Oracle Data Guard.

Per replicare il contenuto che risiede nel file system (ad esempio Oracle home e la configurazione del dominio WebLogic) in una topologia di recupero da errori irreversibili, è possibile utilizzare approcci diversi. Le più comuni sono la replica a livello di storage, la replica basata su rsync o la replica basata su DBFS.

Il modello di DR ibrido, descritto qui, è il punto in cui il database primario si trova on premise e il modello secondario si trova in OCI. La replica a livello di storage non è disponibile nel modello DR ibrido. rsync è invece l'approccio consigliato per replicare gli artifact dal database primario al database in standby. È possibile utilizzare la replica basata su Oracle Database File System (DBFS) per replicare alcuni artifact. Vedere i dettagli in Informazioni su Oracle Database File System in Ulteriori informazioni.

Identificare le cartelle e gli artifact del file system

Identificare i volumi e le cartelle NFS utilizzati dagli host WebLogic Server primari dell'ambiente primario e il relativo contenuto.

Le tabelle riportate di seguito forniscono un esempio degli artifact del file system primario utilizzati in questo esempio.

Volume file system Host Cartella del punto di accesso Commenti Tipo di artifact
NFS VOLFMW1 /export/wls/products1 APPHOST1 /u01/oracle/products Volume per i file binari JDK e FMW. Statico
NFS VOLFMW2 /export/wls/products2 APPHOST 2 /u01/oracle/products Volume per i file binari JDK e FMW. Statico
NFS VOLADMIN/export/wls/config APPHOST1, APPHOST2 /u01/oracle/config Volume per la directory del dominio del server di amministrazione e altre configurazioni condivise, ad esempio piani di distribuzione, applicazioni e keystore. Dinamico
LOCALE* /u02/oracle/config APPHOST1 /u02/oracle/config Volume per la configurazione privata in APPHOST1 Dinamico
LOCALE* /u02/oracle/config APPHOST 2 /u02/oracle/config Volume per la configurazione privata in APPHOST2 Dinamico
VOLRUNTIME NFS /export/wls/runtime APPHOST1, APPHOST2 /u01/oracle/runtime

Volume per il contenuto runtime condiviso, come i file utilizzati dagli adattatori file e da altri artifact runtime.

Nota: si consiglia di memorizzare i messaggi JMS e TLOGS nel database, utilizzando le aree di memorizzazione persistenti JDBC, anziché in questa cartella.

Dinamico

* I volumi del file system locale possono essere installazioni private (non condivise) in NFS anziché storage locale.

La tabella riportata di seguito è un esempio delle variabili EDG per le posizioni delle cartelle.

Variabili EDG Valore
ORACLE_BASE /u01/oracle/products
ORACLE_HOME /u01/oracle/products/fmw
JAVA_HOME /u01/oracle/products/jdk
SHARED_CONFIG_DIR /u01/oracle/config
APPLICATION_HOME /u01/oracle/config/applications/mydomain
DEPLOY_PLAN_HOME /u01/oracle/config/dp
KEYSTORE_HOME /u01/oracle/config/keystores
ASERVER_HOME /u01/oracle/config/domains/mydomain
PRIVATE_CONFIG_DIR /u02/oracle/config
MSERVER_HOME /u02/oracle/config/domains/mydomain
NM_HOME /u02/oracle/config/nodemanager
ORACLE_RUNTIME /u01/oracle/runtime

Verifica della connettività tra gli host primari e in standby

Gli host WebLogic Server primari devono connettersi agli host Oracle Cloud Infrastructure (OCI) WebLogic Server in standby remoto e viceversa,

I nomi fisici degli host WebLogic Server remoti possono essere risolvibili in DNS oppure è possibile includere il peer remoto WebLogic Server che funge da host per i nomi fisici e gli IP nei file /etc/hosts. In altre parole, aggiungere il server WebLogic secondario con i nomi fisici e i relativi IP al file /etc/hosts degli host WebLogic Server primari. Analogamente, aggiungere il server WebLogic primario con i nomi fisici e i relativi IP al file /etc/hosts degli host WebLogic Server secondari.

Nota:

Se il primario non utilizza i nomi host virtuali e utilizza i nomi host dei nodi fisici come indirizzi di ascolto per i server, non eseguire questi passi. Poiché in questo scenario, i nomi host del nodo fisico primario devono essere risolti dagli IP host WebLogic Server OCI in standby. In questo scenario, anziché eseguire i passi riportati di seguito, utilizzare gli IP degli host per la connessione con SSH ai nodi remoti.
  1. Modificare il file /etc/hosts negli host WebLogic Server in locale primari per includere i nomi fisici e gli indirizzi IP degli host WebLogic Server peer remoti.
    Di seguito è riportato un esempio degli alias negli host in locale.
    
#################################
# ALIASES in on-prem
#################################
10.10.10.20   host-vip1.myopnetwork.com    host-vip1          ADMINVHN.example.com   ADMINVHN 
10.10.10.13   host3.myopnnetwork.com       host3              APPHOST1.example.com    APPHOST1
10.10.10.14   host4.myopnnetwork.com       host4              APPHOST2.example.com    APPHOST2
# Front-end name (resolved but primary Load Balancer IP
10.10.10.100    wlsfrontend.example.com
# Remote OCI wls hosts physical names (without virtual host name aliases!)
100.70.10.13    hydrwls1.midTiersubnet.hydrvcn.oraclevcn.com      hydrwls1        
100.70.10.14   hydrwls2.midTiersubnet.hydrvcn.oraclevcn.com       hydrwls2
  2. Modificare il file /etc/hosts negli host WebLogic Server OCI in standby in modo da includere i nomi fisici degli host WebLogic Server remoti in locale. Non includere gli alias dei nomi host virtuali.
    Di seguito è riportato un esempio degli alias negli host WebLogic Server OCI in standby. 
    #################################
# ALIASES in OCI
#################################
100.70.10.20   hydrwls-vip.midTiersubnet.hydrvcn.oraclevcn.com   hydrwls-vip    ADMINVHN.example.com    ADMINVHN
100.70.10.13   hydrwls1.midtiersubnet.hydrvcn.oraclevcn.com      hydrwls1       APPHOST1.example.com    APPHOST1
100.70.10.14   hydrwls2.midtiersubnet.hydrvcn.oraclevcn.com      hydrwls2       APPHOST2.example.com    APPHOST2
# Front-end name (resolved by secondary OCI LBR IP)
1070.70.70    wlsfrontend.example.com
# Remote on-prem wls hosts physical names (without virtual host name aliases!)
10.10.10.13   host3.myopnnetwork.com       host3
10.10.10.14   host4.myopnnetwork.com       host4
  3. Utilizzare il comando SSH per verificare la cross connectectivity dagli host WebLogic Server in locale primari agli host WebLogic Server OCI secondari.
    Per la connessione alle istanze di computazione OCI è necessaria una chiave ssh.
    ssh -i my_private_key oracle@hydrwls1.midtiersubnet.hydrvcn.oraclevcn.com
ssh -i my_private_key oracle@hydrwls2.midtiersubnet.hydrvcn.oraclevcn.com
  4. Utilizzare il comando SSH per verificare la connettività incrociata tra gli host WebLogic Server OCI secondari e gli host WebLogic Server principali in locale.
    Una chiave ssh potrebbe non essere necessaria.
    ssh  oracle@host3.myopnnetwork.com
ssh  oracle@host4.myopnnetwork.com

Duplicare la struttura delle cartelle negli host OCI secondari

A questo punto, le istanze di computazione Oracle Cloud Infrastructure (OCI) WebLogic Server dispongono già del MOUNT FSS. Prima di replicare il contenuto, creare la struttura di cartelle appropriata per EDG.

L'esempio riportato di seguito mostra i comandi per creare la struttura di cartelle EDG utilizzata dall'ambiente EDG del presente documento.
  1. Come utente oracle, creare le cartelle in APPHOST1 OCI.
    mkdir -p  /u01/oracle/products/fmw
mkdir -p  /u01/oracle/products/jdk
mkdir -p  /u01/oracle/products/oraInventory
mkdir -p /u02/oracle/config
mkdir -p /u01/oracle/config/domains/mydomain
mkdir -p /u01/oracle/config/applications/mydomain
mkdir -p /u01/oracle/config/dp/mydomain
mkdir -p /u01/oracle/config/keystores
  2. Come utente oracle, creare le cartelle in APPHOST2 OCI.
    mkdir -p  /u01/oracle/products/fmw
mkdir -p  /u01/oracle/products/jdk
mkdir -p  /u01/oracle/products/oraInventory
mkdir -p /u02/oracle/config

Copiare ORACLE_HOME e JAVA_HOME negli host secondari

Copiare ORACLE_HOME e JAVA_HOME dagli host primari agli host secondari.

ORACLE_HOME e JAVA_HOME si trovano in genere nella stessa cartella di prodotti, insieme a oraInventory. Vedere Identificare le cartelle e gli artifact del file system per le posizioni identificate in precedenza.

  1. Copiare la cartella dei prodotti dal file APPHOST1 primario in locale al file APPHOST1 remoto.
  2. Copiare la cartella home dei prodotti dall'app APPHOST2 principale in locale e salvarla in APPHOST2 remoto. Ripetere l'operazione per qualsiasi altra istanza di computazione.
  3. Copiare il file /etc/oraInst.loc dagli host 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.

    Nell'esempio fornito, oraInventory si trova in /u01/oracle/products e viene copiato insieme a jdk e Oracle home. Se il file oraInventory si trova in una posizione diversa, assicurarsi di copiarlo anche negli host secondari.

    Nota:

    È possibile trovare uno script di esempio che utilizza rsync per copiare la cartella dei prodotti dal APPHOST1 primario in locale al APPHOST1 remoto in Download Code. Repeat the same to copy the products home to the rest of the secondary compute instances (that is, from APPHOST2 to remote APPHOST2).

Copiare le cartelle di configurazione del dominio WebLogic negli host in standby

Copiare la cartella di configurazione condivisa del dominio WebLogic e la cartella di configurazione privata negli host Oracle Cloud Infrastructure (OCI) WebLogic Server.

  1. Copiare la cartella di configurazione condivisa del dominio WebLogic dall'app APPHOST1 primario in locale all'app APPHOST1 OCI remoto.
    La configurazione condivisa del dominio WebLogic risiede nella posizione progettata dalla variabile SHARED_CONFIG_DIR e include le cartelle di configurazione condivise quali APPLICATION_HOME, DEPLOY_PLAN_HOME, KEYSTORE_HOME e ASERVER_HOME.

    Nota:

    È possibile copiare la cartella di configurazione condivisa da APPHOST1 primario in locale a APPHOST1 remoto. Questa è una cartella condivisa, pertanto è sufficiente copiarla in uno degli host WebLogic Server OCI.

    Uno script di esempio è disponibile in Scarica codice.

  2. Copiare la cartella di configurazione privata del dominio WebLogic dell'app APPHOST1 primario in locale e salvarla nell'app APPHOST1 OCI remoto
    La configurazione privata WebLogic risiede nella posizione specificata dalla variabile PRIVATE_CONFIG_DIR e contiene le cartelle MSERVER_HOME e NM_HOME. Queste cartelle non sono condivise, sono specifiche (private) per ogni host WebLogic Server. Pertanto, è necessario eseguire la copia per ciascun server: è necessario copiare la configurazione privata di APPHOST1 in locale in APPHOST1 OCI, la configurazione privata di APPHOST2 in locale in APPHOST2 OCI e così via.

    Nota:

    In Scarica codice è possibile trovare uno script di esempio che utilizza rsync per copiare la cartella di configurazione privata dall'APPHOST1 primario in locale all'APPHOST1 remoto.

Copia la cartella runtime condivisa

Copiare la cartella runtime condivisa negli host Oracle Cloud Infrastructure (OCI) WebLogic Server, se necessario.

La cartella runtime condivisa si trova nella posizione specificata dalla variabile ORACLE_RUNTIME. Vedere Identificare le cartelle e gli artifact del file system per le posizioni identificate in precedenza.

Nota:

Si consiglia di memorizzare le aree di memorizzazione persistenti e TLOGS JMS nel database utilizzando le aree di memorizzazione persistenti JDBC. Poiché si trovano nel database, vengono replicati automaticamente nel sistema secondario con Oracle Data Guard.
  • Poiché si tratta di informazioni di runtime, in genere non è necessario replicarle durante la fase di impostazione. Tuttavia, se è necessario replicare questa cartella negli host in standby, è possibile copiare il contenuto seguendo un approccio simile utilizzato per copiare il file di configurazione condiviso del dominio WebLogic.