1. Configurare una soluzione DR ibrida per Oracle SOA Suite
  2. Replica degli artifact del file system a OCI

Replica degli artifact del file system a OCI

I livelli medi secondari devono avere una replica degli artifact utilizzati dal dominio SOA 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 frequentemente. Ad esempio:
    • Home Oracle: 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 una singola installazione di file binari. È possibile installare i file binari in una singola posizione su una memorizzazione condivisa e riutilizzare questa installazione dai server in nodi diversi. Per una disponibilità massima, Oracle consiglia di utilizzare installazioni binarie ridondanti.
    • Oracle Inventory: orainventory è una cartella che contiene una lista delle Oracle home esistenti e si trova in una cartella separata separata dalla Oracle home. Il file /etc/oraInst.loc determina la posizione di orainventory.
  • Artifact dinamici: sono file che cambiano frequentemente. Questi artifact includono:
    • Home dominio: directory dominio del server di amministrazione e dei server gestiti. In una topologia EDG, il file ASERVER_HOME si trova in una posizione condivisa e il file MSERVER_HOME si trova in una posizione privata e ogni server dispone del proprio MSERVER_HOME, anche se può essere memorizzato in un file NFS.
    • Artifact dell'applicazione, ad esempio file .ear o .war.
    • Artifact di database, ad esempio il repository MDS e gli schemi SOAINFRA.
    • Negozi persistenti, ad esempio provider JMS e log transazioni. Oracle consiglia di memorizzare questi artifact nel database. Questo è l'approccio consigliato nella topologia EDG e particolarmente utile per gli ambienti di recupero da errori irreversibili (DR), in quanto vengono replicati automaticamente nel sito in standby tramite Oracle Data Guard di base.
    • Piani di distribuzione utilizzati per l'aggiornamento degli adattatori tecnologia, ad esempio adattatori file e 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 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 SOAINFRA, 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 SOA 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 del file system Host Cartella punto di accesso Commenti Tipo di artifact
NFS VOLFMW1 /export/soa/products1 SOAHOST1 /u01/oracle/products Volume per i file binari JDK e FMW. Statico
NFS VOLFMW2 /export/soa/products2 SOAHOST2 /u01/oracle/products Volume per i file binari JDK e FMW. Statico
NFS VOLADMIN/export/soa/config SOAHOST1, SOAHOST2 /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 SOAHOST1 /u02/oracle/config Volume per la configurazione privata in SOAHOST1 Dinamico
LOCALE* /u02/oracle/config SOAHOST2 /u02/oracle/config Volume per la configurazione privata in SOAHOST2 Dinamico
VOLRUNTIME NFS /export/soa/runtime SOAHOST1, SOAHOST2 /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 attivati da dispositivi privati (non condivisi) in NFS anziché in memoria locale.

La tabella seguente mostra un esempio di 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/mysoadomain
DEPLOY_PLAN_HOME /u01/oracle/config/dp
KEYSTORE_HOME /u01/oracle/config/keystores
ASERVER_HOME /u01/oracle/config/domains/mysoadomain
PRIVATE_CONFIG_DIR /u02/oracle/config
MSERVER_HOME /u02/oracle/config/domains/mysoadomain
NM_HOME /u02/oracle/config/nodemanager
ORACLE_RUNTIME /u01/oracle/runtime

Verifica della connettività tra gli host primari e in standby

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

È possibile risolvere i nomi fisici degli host SOA remoti in DNS oppure includere gli host SOA del peer remoto con nomi fisici e IP nei file /etc/hosts. In altre parole, aggiungere i nomi fisici degli host SOA secondari e i relativi IP al file /etc/hosts degli host SOA primari. Analogamente, aggiungere i nomi fisici degli host SOA principali e i relativi IP al file /etc/hosts degli host SOA 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 SOA 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 SOA in locale primari per includere i nomi fisici e gli indirizzi IP degli host SOA 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              SOAHOST1.example.com    SOAHOST1
10.10.10.14   host4.myopnnetwork.com       host4              SOAHOST2.example.com    SOAHOST2
# Front-end name (resolved but primary Load Balancer IP
10.10.10.100    mysoa.example.com
# Remote OCI soa hosts physical names (without virtual host name aliases!)
100.70.10.13    hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com      hydrsoa1        
100.70.10.14   hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com       hydrsoa2
  2. Modificare il file /etc/hosts negli host SOA OCI in standby in modo da includere i nomi fisici SOA remoti in locale. Non includere gli alias dei nomi host virtuali.
    Di seguito è riportato un esempio degli alias negli host SOA OCI in standby. 
    #################################
# ALIASES in OCI
#################################
100.70.10.20   hydrsoa-vip.midTiersubnet.hydrvcn.oraclevcn.com   hydrsoa-vip    ADMINVHN.example.com    ADMINVHN
100.70.10.13   hydrsoa1.midtiersubnet.hydrvcn.oraclevcn.com      hydrsoa1       SOAHOST1.example.com    SOAHOST1
100.70.10.14   hydrsoa2.midtiersubnet.hydrvcn.oraclevcn.com      hydrsoa2       SOAHOST2.example.com    SOAHOST2
# Front-end name (resolved by secondary OCI LBR IP)
1070.70.70    mysoa.example.com
# Remote on-prem soa hosts physical names (without virtual host name aliases!)
10.10.10.13   host3.myopnnetwork.com       host3
10.10.10.14   host4.myopnnetwork.com       host4
  3. Utilizzare il comando SSH per verificare la connettività incrociata dagli host SOA in locale primari agli host SOA OCI secondari.
    È necessaria una chiave ssh per la connessione alle istanze di computazione OCI.
    ssh -i my_private_key oracle@hydrsoa1.midtiersubnet.hydrvcn.oraclevcn.com
ssh -i my_private_key oracle@hydrsoa2.midtiersubnet.hydrvcn.oraclevcn.com
  4. Utilizzare il comando SSH per verificare la connettività incrociata tra gli host SOA OCI secondari e gli host SOA principali in locale.
    È possibile che una chiave ssh non sia 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) SOA 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 di questo documento.
  1. In qualità di utente oracle, creare le cartelle in SOAHOST1 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/mysoadomain
mkdir -p /u01/oracle/config/applications/mysoadomain
mkdir -p /u01/oracle/config/dp/mysoadomain
mkdir -p /u01/oracle/config/keystores
  2. In qualità di utente oracle, creare le cartelle in SOAHOST2 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 dalla cartella primaria SOAHOST1 in locale alla cartella remota SOAHOST1.
  2. Copiare la cartella home dei prodotti da SOAHOST2 principale in locale e salvarla in SOAHOST2 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, pertanto questa copia è un'azione singola.

    Nell'esempio fornito, oraInventory si trova in /u01/oracle/products e viene copiato insieme alla jdk e alla Oracle home. Se 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 SOAHOST1 primario in locale al SOAHOST1 remoto in Scarica codice. Repeat the same to copy the products home to the rest of the secondary compute instances (that is, from SOAHOST2 to remote SOAHOST2).

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 SOA (OCI) di Oracle Cloud Infrastructure.

  1. Copiare la cartella di configurazione condivisa del dominio WebLogic dal file SOAHOST1 primario in locale al file SOAHOST1 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 SOAHOST1 primario in locale in SOAHOST1 remoto. Questa è una cartella condivisa, pertanto è sufficiente copiarla in uno degli host SOA OCI.

    Uno script di esempio è disponibile in Scarica codice.

  2. Copiare la cartella di configurazione privata del dominio WebLogic di SOAHOST1 primario in locale e salvarla in SOAHOST1 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 SOA. Pertanto, è necessario eseguire la copia per ciascun server: è necessario copiare la configurazione privata di SOAHOST1 in locale in SOAHOST1 OCI, la configurazione privata di SOAHOST2 in locale in SOAHOST2 OCI e così via.

    Nota:

    In Scarica codice è possibile trovare uno script di esempio che utilizza rsync per copiare la cartella di configurazione privata dal SOAHOST1 primario in locale al SOAHOST1 remoto.

Copia cartella runtime condivisa

Copiare la cartella runtime condivisa negli host Oracle Cloud Infrastructure (OCI) SOA, 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 nel database i negozi persistenti JMS e i negozi TLOGS utilizzando le aree di memorizzazione persistenti JDBC. Dal momento che 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.