1. Configurare Oracle Fusion Middleware DR su Oracle Cloud con un database autonomo
  2. Configurare la topologia DR

Configurare la topologia DR

Impostare la topologia di recupero da errori irreversibili (DR). Sono disponibili script per semplificare il processo.

Scarica gli script

Recuperare gli script di impostazione più recenti dal repository GitHub.

Nota:

Posizionare tutti gli script scaricati nella stessa cartella.
  1. Andare al repository GitHub.
  2. Scaricare tutti gli script nella directory maa/fmw-wls-with-adb-dr.
  3. Scaricare tutti gli script nella directory maa/app_dr_common.
    Questi script effettuano chiamate reciproche. Nonostante l'operazione specifica eseguita in un momento specifico, scaricare tutte le directory e inserire tutti gli script nella stessa cartella. Saranno necessari gli script sia nel sito principale che nel sito secondario.
  4. Seguire le istruzioni riportate in questo documento e leggere le variabili richieste in ogni script per ogni operazione eseguita.

Il file scaricato include script per l'esecuzione delle seguenti attività:

  1. Configurare un alias TNS per le origini dati
  2. Impostazione della configurazione di DR iniziale
  3. Impostazione della replica in corso
  4. Modificare i wallet per un sistema Oracle WebLogic Server, Oracle SOA o Oracle Fusion Middleware.
Ogni script offre l'automazione per diverse parti dell'impostazione e del ciclo di vita di un sistema di protezione da errori irreversibili. La seguente tabella fornisce un riepilogo delle utility:
Nome script Descrizione
fmwadb_config_replica.sh Replica la configurazione tra i siti.
fmwadb_dr_prim.sh Prepara un sito principale per l'impostazione di DR.
fmwadb_dr_stby.sh Prepara un sito secondario per la configurazione di DR.
fmwadb_rest_api_listabds.sh Ottenere il ruolo Autonomous Database basato sull'ID ADB e sulle informazioni sulla tenancy.
fmwadb_switch_db_conn.sh Sostituisce le informazioni di connessione esistenti con un nuovo WALLET ADBS.
fmw_change_to_tns_alias.sh Sostituire le stringhe di connessione utilizzate dalle origini dati Oracle WebLogic e dai file jps config con un alias tns.
fmw_dec_pwd.sh Decifra una password cifrata per Oracle WebLogic.
fmw_enc_pwd.sh Cifra una password utilizzando la cifratura Oracle WebLogic.
fmw_get_connect_string.sh Restituisce la stringa di connessione utilizzata da un'origine dati Oracle WebLogic, Oracle SOA o Oracle Fusion Middleware.
fmw_get_ds_property.sh Restituisce il valore di una proprietà di origine dati specifica.

Preparare il livello intermedio principale per il frontend virtuale

Se il livello intermedio primario non è già configurato con un nome front-end virtuale, eseguire queste azioni per prepararlo alla configurazione del disaster recovery (DR).

  1. Aggiungere il nome del front-end virtuale e l'IP al file /etc/hosts in tutti gli host di livello intermedio principali.
    Ogni sito deve sempre risolvere il nome frontend nel proprio load balancer locale, indipendentemente dalla risoluzione lato client tramite il DNS (Domain Name System). In qualità di utente root, modificare il file /etc/hosts ed eseguire il mapping dell'IP pubblico del load balancer primario al nome dominio completamente qualificato (FQDN) del frontend virtuale. Ripetere la procedura in tutti gli host Oracle WebLogic primari. Ad esempio: 
    [oracle@wlsociprefix-wls-0 ~]$ more /etc/hosts
(...)
# Front-end virtual name
111.111.111.111 mywebapps.example.com

    Nota:

    Il file /etc/hosts degli host Oracle WebLogic primari non deve essere modificato quando si verifica uno switchover o un failover. Gli host Oracle WebLogic primari risolveranno sempre il nome del front-end virtuale con l'IP front-end. L'aggiornamento DNS necessario durante le procedure di switchover e failover viene eseguito nei file DNS o host utilizzati dai client.

  2. Configurare il nome del frontend come frontend del cluster.
    1. Collegarsi alla console Oracle WebLogic dell'istanza.
    2. Passare a Ambiente, quindi a Cluster e selezionare il cluster.
    3. Passare a Configurazione, quindi a HTTP.
    4. Impostare l'host Fronted sul FQDN front-end.
      Ad esempio mywebapps.example.com.
    5. Assicurarsi che le porte Frontend per HTTP e HTTPS siano configurate correttamente con i valori.
    6. Fare clic su Salva, quindi su Attiva.
  3. Riavviare il cluster per implementare le modifiche.

Modificare le origini dati e la configurazione JPS del database primario per utilizzare un alias TNS

L'uso di un alias TNS (Transparent Network Substrate) negli URL JDBC (Java Database Connectivity) facilita la riconfigurazione delle origini dati Oracle WebLogic Server for Oracle Cloud Infrastructure utilizzando copie aggiornabili remote per lo spostamento tra database primario e in standby.

Nota:

Le istanze di Oracle SOA Suite su Marketplace di cui è stato eseguito il provisioning con la release 23.1.1 (febbraio 2023) o successive sono configurate con l'approccio predefinito all'alias TNS. In questo caso, è possibile saltare questo task.

L'uso di un alias TNS richiede che le origini dati e i file jps includano la variabile oracle.net.tns_admin nei file di configurazione di Oracle Fusion Middleware.

  1. Utilizzare il comando grep per cercare la variabile oracle.net.tns_admin nel file di configurazione di Oracle Fusion Middleware. 
    [oracle@soarefr-soa-0 ~]$ grep oracle.net.tns_admin ${DOMAIN_HOME}/config/fmwconfig/jps-config.xml 
<property name="oracle.net.tns_admin" value="/u01/data/domains/soarefr_domain/config/atp"/>

[oracle@soarefr-soa-0 ~]$ grep oracle.net.tns ${DOMAIN_HOME}/config/jdbc/opss-datasource-jdbc.xml  -A1 | grep value 
<value>/u01/data/domains/soarefr_domain/config/atp</value>
[oracle@soarefr-soa-0 ~]$
    La directory riflessa in jps-config.xml (e nelle origini dati) deve essere disponibile e accessibile da tutti i nodi nel dominio del server WebLogic.
    • In Oracle SOA Suite su Marketplace questa directory si trova nella directory $DOMAIN_HOME/config/atp (prima della release 23.1.1) o nella directory $DOMAIN_HOME/config/tnsadmin (per la release 23.1.1 e successive) e viene replicata automaticamente dal server WebLogic su tutti gli altri nodi all'avvio dei server gestiti.

      Nota:

      Se Oracle SOA Suite su Marketplace è precedente alla versione 23.1.1, si consiglia di spostare la cartella nella directory $DOMAIN_HOME/config/tnsadmin per renderla coerente con il database in standby.
    • In Oracle WebLogic Server for Oracle Cloud Infrastructure si trova in $DOMAIN_HOME/atpwallet.

      Nota:

      Se il wallet non si trova nella directory DOMAIN_HOME/config, le modifiche apportate al contenuto della directory del wallet NON verranno replicate automaticamente dall'infrastruttura Oracle WebLogic Server ad altri nodi. In questi casi, è necessario modificare la directory del wallet (e aggiornare le configurazioni delle origini dati necessarie) oppure copiarla manualmente in altri nodi quando viene aggiornata.
    • In altre configurazioni è possibile posizionare la directory sulla memoria condivisa.
    In ogni caso, la stessa directory tns_admin deve essere raggiungibile da tutti i diversi membri di un dominio WebLogic Server. Questa directory conterrà un file tnsnames.ora con alias diversi per i diversi servizi creati in Oracle Autonomous Database.

    Di seguito è riportato un file tnsnames.ora di esempio per la configurazione di Oracle Fusion Middleware con Oracle Autonomous Database Serverless. 

    [oracle@soarefr-soa-0 ~]$ cat 
$DOMAIN_HOME}}/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Le modifiche apportate al file tnsnames.ora vengono utilizzate in modo dinamico dalle origini dati WLS. Ciò significa che è possibile modificare il file tnsnames.ora (ad esempio per puntare a un servizio diverso) senza richiedere il riavvio dell'origine dati.

  2. Per modificare una configurazione di origine dati standard in modo da utilizzare un alias TNS in un Oracle SOA Suite su Marketplace o in un sistema Oracle WebLogic Server for Oracle Cloud Infrastructure che utilizza Autonomous Database, utilizzare lo script fmw_change_to_tns_alias.sh.

    L'alias deve essere utilizzato in tutti i file delle origini dati sotto $DOMAIN_HOME/config/jdbc e nei file jps config sotto $DOMAIN_HOME/config/fmwconfig.

    Nota:

    Questo script modificherà solo la stringa di connessione e la proprietà tns_admin. Se si aggiungono altre origini dati personalizzate, tali origini dovranno anche utilizzare un alias TNS proprio come quelle interne per Oracle WebLogic, Oracle SOA Suite su Marketplace e Oracle Fusion Middleware.
    Quando si esegue il provisioning di Oracle WebLogic Server for Oracle Cloud Infrastructure o di Oracle SOA Suite su Marketplace utilizzando Oracle Autonomous Database, la configurazione del wallet del database viene inclusa nelle origini dati (posizione dell'area di memorizzazione sicura, posizione del keystore e così via). Questi parametri NON vengono modificati dallo script fmw_change_to_tns_alias.sh e sono validi se si utilizza l'alias TNS. Una directory del wallet viene creata da Oracle WebLogic Server for Oracle Cloud Infrastructure e Oracle SOA Suite su Marketplace durante il provisioning e contiene già un file tnsnames.ora. Inoltre, puoi ottenere il wallet di Oracle Autonomous Database dall'interfaccia utente del database autonomo in OCI.

    Nota:

    Il wallet Oracle Autonomous Database utilizzato da Oracle WebLogic Server for Oracle Cloud Infrastructure e Oracle SOA Suite su Marketplace viene scaricato nel nodo del server di amministrazione quando viene eseguito il provisioning. È possibile aggiornare il wallet per i sistemi primario e in standby eseguendo di nuovo il download dall'interfaccia utente di Oracle Autonomous Database e aggiornando la password del wallet nella directory $DOMAIN_HOME/config/jdbc e nei file jps config sotto $DOMAIN_HOME/config/fmwconfig. L'uso della stessa password per i wallet del clone primario, in standby e aggiornabile facilita la manipolazione della configurazione dell'origine dati in entrambi i siti. Tuttavia, gli script forniti di seguito saranno in grado di gestire password diverse. Utilizzare lo script fmwadb_switch_db_conn.sh per aggiornare il sistema con un nuovo wallet.

    Al momento del provisioning del sistema primario, è stato scelto (nelle schermate di provisioning) uno dei livelli di servizio di Oracle Autonomous Database. Eseguire lo script fmw_change_to_tns_alias.sh con lo stesso livello di servizio. I livelli di servizio per un servizio DB in Oracle Autonomous Database sono: tpurgent basso, medio, alto. Di seguito è riportato un esempio di modifica dell'alias Oracle Fusion Middleware in TNS: 

    [oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/fmwconfig/jps-config.xml
<property name="jdbc.url" value="jdbc:oracle:thin:@(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))"/>
[oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml
<url>jdbc:oracle:thin:@(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))</url>
 
NOTICE the "low" label in g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com, that is the service flag that will allow you identify the tns alias that needs to be used
 
[oracle@soarefr-soa-0 good]$ cat $DOMAIN_HOME/config/atp/tnsnames.ora | grep low | awk -F '=' '{print $1}'
soaadb1_low
 
[oracle@soarefr-soa-0 good]$ ./fmw_change_to_tns_alias.sh soaadb1_low                                                                                          
Getting variables from current datasource ...............
An existing tns_admin property was found in /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml and will be used
Found soaadb1_low  as tns_alias
No modifications will be required in /u01/data/domains/soarefr_domain/config/atp/tnsnames.ora
*******************WILL USE THESE SETTINGS********************
**************************************************************
TNS admin:........................./u01/data/domains/soarefr_domain/config/atp
TNS alias:........................ soaadb1_low
Current connect string:............(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
Current jps connect string:........(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
Current tnsnames.ora:..............
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
**************************************************************
Taking backup of existing config...
************** Replacing DB connect information **************
Replacing jdbc url in config/jdbc files...
Replacing jdbc url in config/fmwconfig files...
Replacement complete!
 
[oracle@soarefr-soa-0 ~]$ grep url $DOMAIN_HOME/config/fmwconfig/jps-config.xml
<property name="jdbc.url" value="jdbc:oracle:thin:@soaadb1_low "/>
[oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml
    <url>jdbc:oracle:thin:@soaadb1_low </url>
<property name="jdbc.url" value="jdbc:oracle:thin:@soaadb1_low "/>
[oracle@soarefr-soa-0 ~]$
  3. Riavviare tutti i server Oracle WebLogic nel dominio per utilizzare le modifiche eseguite dallo script.

Crea una VCN e una subnet nell'area secondaria

Se non l'hai già fatto, creare una VCN nell'area in standby con un CIDR che non sia in conflitto con il CIDR dell'area primaria. Ad esempio, se la VCN primaria utilizza la versione 10.1.0.0/16, la VCN secondaria potrebbe utilizzare la versione 10.2.0.0/16.

  1. Crea una VCN e una subnet nell'area secondaria.
    Puoi creare uno stack cloud per eseguire il provisioning di un gruppo di servizi cloud correlati.
  2. Assicurarsi che gli elenchi di sicurezza consentano le comunicazioni appropriate tra i livelli.

    Verificare la comunicazione seguente:

    • Dal load balancer OCI al server WebLogic
    • Dal server WebLogic al database
    • Dal server WebLogic alla memoria condivisa

    Includere inoltre le regole necessarie per consentire le comunicazioni tra i nodi del server di amministrazione tramite il gateway di instradamento dinamico (DRG, Dynamic Routing Gateway) una volta creato.

Configurare un DRG tra i VCN primari e secondari

L'impostazione del ripristino di emergenza richiede che i nodi di amministrazione Oracle WebLogic Server primari e secondari comunichino tra loro per ricevere la configurazione del dominio tramite le copie di Oracle Cloud Infrastructure File Storage. Per questo motivo, è necessario creare un gateway di instradamento dinamico (DRG) tra i VCN di livello intermedio.

  1. Crea un DRG tra i VCN di livello intermedio.
  2. Verificare che il nuovo DRG venga visualizzato nella pagina Dynamic Routing Gateway del compartimento o dell'area scelta.
    Gli script di configurazione DR verificheranno che sia possibile stabilire le connessioni richieste.
  3. Configurare i percorsi e le regole di sicurezza appropriati nei VCN primari e in standby per consentire le connessioni SSH tra i mid-tiers.
  4. Verificare che sia possibile stabilire una connessione SSH dal nodo Oracle WebLogic Administration Server primario al nodo Oracle WebLogic Administration Server in secondario.
    Ad esempio, se 10.2.1.104 è l'IP del nodo del server di amministrazione secondario, eseguire quanto segue dal nodo del server di amministrazione primario.
    [opc@soarefr-soa-0 ~]$ ssh -i KeySOAMAA.ppk opc@10.2.1.104
Last login: Wed Dec 14 16:59:15 2022 from 10.2.0.83
[opc@soarefr-soa-0 ~]$

Crea un database di standby Oracle Autonomous Data Guard nell'area secondaria

Crea un database in standby per l'istanza primaria esistente di Oracle Autonomous Database.

  1. Per Oracle Autonomous Database Serverless, crea un Oracle Autonomous Database Serverless in standby nell'area secondaria.
    1. Nella console OCI, fare clic su Oracle Database nel menu di navigazione a sinistra per passare all'istanza primaria di Oracle Autonomous Database.
    2. Nella pagina Dettagli di Autonomous Database, in Risorse fare clic su Recupero da errori irreversibili, quindi su Aggiungi database peer.
    3. Utilizzare le subnet VCN e private create in precedenza.
  2. Per Oracle Autonomous Database on Dedicated Exadata Infrastructure
    1. Nella console OCI, andare alla pagina dei dettagli di Autonomous Container Database e selezionare la risorsa Associazioni Autonomous Data Guard nella sezione Risorse.
    2. Fare clic su Abilita Autonomous Data Guard.
    3. Immettere le informazioni sul cluster VM Autonomous peer, la modalità di protezione e la scelta di failover automatico. Dopo aver immesso tutte le informazioni necessarie, fare clic su Abilita Autonomous Data Guard.
      Nell'ambito di questo workflow, viene creato un nuovo Autonomous Container Database di standby con tutti i database autonomi di standby nel cluster VM Autonomous selezionato.

Preparare Autonomous Database in standby per l'impostazione DR

Questo task dipende dal fatto che si stia utilizzando l'approccio Snapshot in standby o Copia aggiornabile remota.

Per l'approccio di standby snapshot, vedere Convert the Standby in a Snapshot Standby.

Per l'approccio Copia aggiornabile da remoto, vedere Creare una copia aggiornabile da remoto nell'area secondaria.

Conversione del standby in standby snapshot

Utilizzando l'approccio di standby snapshot, convertire il database autonomo in standby snapshot.

  1. Dal menu di navigazione sinistro della console di Oracle Cloud Infrastructure fare clic su Autonomous Database.
  2. Nell'area secondaria selezionare Autonomous Database in standby.
  3. Nell'elenco a discesa Altre azioni fare clic su Converti nel database in standby snapshot.
  4. Se si utilizza l'infrastruttura dedicata, selezionare Usa servizi di database principali.

Nota:

Quando uno snapshot in standby in Oracle Dedicated Exadata Infrastructure non viene convertito in standby fisico entro 7 giorni, lo snapshot in standby viene convertito automaticamente in standby fisico.

Quando uno snapshot in standby in Oracle Autonomous Database Serverless non viene convertito in standby fisico entro 2 giorni, lo snapshot in standby viene automaticamente convertito in standby fisico.

Crea una copia aggiornabile remota nell'area secondaria

Utilizzando l'approccio Copia aggiornabile remota, creare una copia aggiornabile dall'Oracle Autonomous Database Serverless primario esistente nell'area remota.

  1. Creare una copia aggiornabile da Oracle Autonomous Database Serverless primario esistente.
    Posizionare la copia aggiornabile nell'area secondaria (remota) all'interno della VCN e della subnet privata creata in precedenza.

    Nota:

    Impossibile utilizzare lo stesso nome DB del database primario poiché il nome è già utilizzato dal database in standby fisico.
  2. Utilizzare Private Endpoint Access Only per accedere al database.

    Una volta creata, la copia aggiornabile rimane connessa e in modalità di sola lettura. Non è possibile eseguire il provisioning dei sistemi Oracle WebLogic Server, Oracle SOA e Oracle Fusion Middleware con UNLESS, viene convertito in lettura-scrittura (disconnesso dal database primario).

  3. Disconnettere la copia aggiornabile dal database autonomo primario e convertirla in modalità di lettura/scrittura.

    Nota:

    La copia aggiornabile remota non può rimanere disconnessa per più di 24 ore. Ad esempio, non è possibile richiedere più di 24 ore per creare i livelli intermedi secondari che puntano al database clone aggiornabile remoto.
    1. Nel menu di navigazione sinistro di Oracle Cloud Infrastructure fare clic su Autonomous Database.
    2. Selezionare il nome della copia aggiornabile.
    3. Selezionare il database di origine, quindi fare clic su Disconnetti.

Esegui provisioning del sistema secondario

Eseguire il provisioning del servizio secondario Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace o di un altro servizio di livello intermedio Oracle Cloud Infrastructure (OCI) che utilizza Oracle Fusion Middleware (sistema) che punta al database secondario (per l'approccio Snapshot Standby) o alla copia aggiornabile (per l'approccio remoto con copia aggiornabile).

  1. Segui i suggerimenti standard relativi a subnet, CIDR, regole di sicurezza e prefisso dell'istanza per il recupero da errori irreversibili.

    Il nome dello stack può essere diverso, ma è necessario utilizzare lo stesso prefisso del nome della risorsa EXACT utilizzato nella posizione principale. Oracle consiglia di utilizzare la stessa capacità e la stessa configurazione di computazione nelle posizioni primarie e in standby per il comportamento ideale di failover/switchover.

    Assicurarsi che la versione di Oracle WebLogic Server per OCI e il livello di patch di cui eseguire il provisioning nella posizione secondaria corrispondano a quello in esecuzione nel sito primario.

    Per ulteriori dettagli, vedere la tabella che riepiloga le opzioni della procedura guidata di provisioning per l'impostazione DR nella sezione "Provisioning WLS per OCI nel sito secondario" di Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery o nella sezione "Provisioning SOA Suite on Marketplace in Secondary Site" di SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery.

  2. Crea il sistema di livello intermedio secondario in base al processo di provisioning standard.
  3. Controllare lo standard Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace o qualsiasi altro servizio Oracle Cloud Infrastructure (OCI) di livello intermedio che utilizza gli URL di Oracle Fusion Middleware (ad esempio, Console, soa-infra e così via) per verificare che il sistema venga creato correttamente.
  4. Una volta convalidati, arrestare i processi Oracle WebLogic nel database in standby: server gestiti, server di amministrazione e Node Manager.
  5. Se si utilizza una copia aggiornabile remota, è possibile riconnetterla all'origine. Se si utilizza lo standby snapshot, è possibile convertirlo di nuovo in standby fisico.
    Non tentare di avviare i processi Oracle WebLogic in modalità secondaria fino al completamento dell'impostazione di DR.

Modificare le stringhe di connessione alias TNS secondario

Modificare l'alias usato nel sistema secondario usando lo stesso alias del sistema principale.

Come nel sistema primario, è necessario utilizzare un alias TNS (Transparent Network Substrate) in tutti i file delle origini dati in $DOMAIN_HOME/config/jdbc e nei file jps config in $DOMAIN_HOME/config/fmwconfig. L'alias utilizzato nel sistema secondario (standby) sarà lo stesso del sistema primario poiché le origini dati vengono replicate dal database primario che contiene l'alias creato in precedenza.

Questo task dipende dal fatto che si stia utilizzando un approccio Snapshot in standby o Copia aggiornabile remota.

Modificare le stringhe di connessione alias TNS secondario per l'approccio in standby snapshot

Per l'approccio in standby snapshot, è previsto che gli alias nel file tnsnames.ora siano uguali a quelli nel database primario (anche se le stringhe di connessione punteranno all'indirizzo del database in standby). Non è necessario modificarli.

  1. Se le stringhe nel file tnsnames.ora sono doppie (dove contengono sia host di database autonomi locali che remoti), Oracle consiglia di modificarle in modo che puntino SOLO al database locale.
    Ciò può verificarsi quando si utilizza Oracle Autonomous Database su un'infrastruttura dedicata. È sufficiente apportare questa modifica una volta, poiché il file tnsnames.ora per il database in standby non viene modificato dalla replica della configurazione e da altre operazioni del ciclo di vita.

    Di seguito è riportato un esempio in cui le voci del file tnsnames.ora sono doppie: 

    adbd1_tp=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST= host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_tp.atp.oraclecloud.com)))

adbd1_medium=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_medium.atp.oraclecloud.com)))

adbd1_tpurgent=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_tpurgent.atp.oraclecloud.com)))
…
  2. Se si dispone di voci doppie, modificarle in modo che puntino solo all'Autonomous Database locale rimuovendo l'INDIRIZZO del database remoto.

    Il file tnsnames.ora in secondario deve includere solo l'INDIRIZZO del database in standby. Ad esempio: 

    adbd1_tp=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST= host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_tp.atp.oraclecloud.com)))

adbd1_medium=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_medium.atp.oraclecloud.com)))

adbd1_tpurgent=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_tpurgent.atp.oraclecloud.com)))
…

Modificare le stringhe di connessione dell'alias TNS secondario per l'approccio di copia aggiornabile remota

Per l'approccio Copia aggiornabile remota, modificare l'alias utilizzato nel sistema secondario in modo che sia lo stesso alias del sistema primario.

Il file tnsnames.ora incluso nella creazione secondaria del sistema Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace o Oracle Fusion Middleware conterrà un alias basato sul nome della copia remota aggiornabile. Ad esempio, se viene creata una copia aggiornabile remota con il nome soaadb1rc2, il file tnsnames.ora (nella directory del wallet creata durante il provisioning) conterrà l'alias seguente: soaadb1rc2_high, soaadb1rc2_low, soaadb1rc2_medium, soaadb1rc2_tp, soaadb1rc2_tpurgent. Per semplificare la configurazione, è necessario utilizzare lo stesso nome alias nel file tnsnames.ora sia nei sistemi primari che nei sistemi secondari, quindi modificare l'alias TNS che Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite su Marketplace o il dominio Oracle Fusion Middleware è configurato con (copia aggiornabile remota) per utilizzare lo stesso nome alias come principale. È possibile ottenere il nome alias in primary dal file $tns_admin/tsnames.ora. Vengono creati alias diversi per servizi diversi e tutti deriveranno un prefisso dal nome DB. Si noti che si desidera modificare solo il nome alias, non i servizi. Non utilizzare una ricerca e una sostituzione globali nel file in quanto probabilmente modificherà anche i nomi dei servizi nelle stringhe di connessione nel file tnsnames.ora.

  • Modificare il file tnsnames.ora del sistema secondario usando lo stesso alias del sistema primario.

    Di seguito è riportato un file tnsnames.ora di esempio per una configurazione di Oracle Fusion Middleware con Oracle Autonomous Database Serverless nel sistema primary. 

    [oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Di seguito è riportato un file tnsnames.ora di esempio per una configurazione di Oracle Fusion Middleware con Oracle Autonomous Database Serverless in secondario con copia aggiornabile. 

    oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
rcsoaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Poiché si tratta di un'operazione una tantum, il modo più semplice per modificare l'alias per la copia aggiornabile consiste nel modificare il file. È possibile modificare l'alias per il livello di servizio in uso o per garantire la coerenza.

    Nota:

    Questa operazione deve essere eseguita ogni volta che viene utilizzata una nuova copia aggiornabile per i test o le convalide e viene utilizzato un nuovo wallet.

    Di seguito è riportato un file tnsnames.ora di esempio per una configurazione di Oracle Fusion Middleware con Oracle Autonomous Database Serverless nel secondario con copia aggiornabile utilizzando l'alias primario. 

    [oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

Come nel sistema primario, tutti i file delle origini dati in $DOMAIN_HOME/config/jdbc e nei file di configurazione jps in $DOMAIN_HOME/config/fmwconfig utilizzano l'alias scelto. Si prevede che con la copia aggiornabile remota sia stato scelto lo stesso livello di servizio come nel sistema primario (low, mid, high, tp o tpurgent). Poiché gli alias e le origini dati vengono copiati dal sistema primario, non è necessario eseguire lo script fmw_change_to_tns_alias.sh nel sistema secondario. L'impostazione del ripristino di emergenza gestirà le sostituzioni richieste.

Se si dispone di alias aggiuntivi per puntare ad altri database nel file tnsnames.ora primario, aggiungerli di conseguenza nel file tnsnames.ora del sistema secondario.

Aggiornamento degli alias dei nomi host e dell'indirizzo front-end nei livelli intermedi primario e in standby

Al termine dell'impostazione di DR, la configurazione del dominio WebLogic nel dominio secondario sarà una copia del dominio WebLogic primario. Pertanto, i nomi host utilizzati come indirizzi di ascolto dai server Oracle WebLogic primari (ovvero i nomi host degli host primari) devono essere validi nella posizione secondaria, ma essere mappati agli IP secondari.

È necessario utilizzare lo stesso indirizzo frontend sia nel database primario che in quello in standby. Durante il normale funzionamento, questo nome host frontend verrà mappato all'IP del load balancer Oracle Cloud Infrastructure (OCI) primario. Quando viene eseguita dalla versione secondaria (dopo uno switchover o un failover), questo nome host frontend verrà mappato all'IP del load balancer OCI secondario.

Nota:

Il file /etc/hosts degli host di livello intermedio non deve essere modificato quando si verifica uno switchover o un failover. Gli host di livello intermedio risolveranno sempre il nome del frontend 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.

È possibile implementare questo alias host nei modi seguenti:

  • Aggiungere i nomi host come alias ai file /etc/hosts delle istanze di computazione Oracle WebLogic Server for OCI.
  • Usa una vista DNS privata nella VCN OCI secondaria

Usa file /etc/hosts

I nomi host utilizzati da Oracle WebLogic Server primario vengono aggiunti ai file /etc/hosts degli host Oracle WebLogic Server secondari, che puntano agli indirizzi IP degli host Oracle WebLogic Server secondari. Questa modalità è valida quando il server DNS è la stessa nei siti Oracle Cloud Infrastructure (OCI) primari e secondari e anche quando i server DNS separati vengono utilizzati nei siti principali e secondari. Le voci nel file /etc/hosts hanno la precedenza sulla risoluzione DNS, perché si tratta della precedenza definita predefinita nella direttiva "hosts" del file /etc/nsswitch.conf.
  1. Modificare il file /etc/oci-hostname.conf di ogni istanza di computazione del server WebLogic e impostare la proprietà PRESERVE_HOSTINFO=3 per conservare le voci /etc/hosts tra i vari riavvii dell'istanza.
  2. Utilizzare il comando hostname --fqdn per identificare i nomi host completi delle istanze di computazione del server WebLogic OCI.
  3. Aggiungere le voci seguenti al file /etc/hosts delle istanze di computazione di livello intermedio:
    #################################
# ALIASES on OCI for DR
#################################
apphost1_compute_instance_IP  apphost1_fqdn   apphost1_hostname   ALIAS_OF_APPHOST1 
apphost2_compute_instance_IP  apphost2_fqdn   apphost2_hostname   ALIAS_OF_APPHOST2 
#################################
# Frontend name 
#################################
IP_OF_LBR  frontend_name_fqdn
    Di seguito è riportato un esempio del file /etc/hosts degli host Oracle WebLogic Server primari:
    # Aliases for DR in primary region
10.0.2.10 wlsociprefix-wls-0.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0 
10.0.2.11 wlsociprefix-wls-1.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-1

# Front-end virtual name to primary LBR IP
111.111.111.111 mywebapps.mycompany.com

    Di seguito è riportato un esempio del file /etc/hosts nell'istanza di computazione secondaria del server WebLogic OCI.

    Nota:

    I nomi host primari vengono aggiunti come alias dei nodi secondari e il nome virtuale front-end punta all'IP del load balancer secondario:

    # Aliases for DR in secondary region
10.1.2.5 wlsociprefix-wls-0.subnetfra.vcnfra.oraclevcn.com wlsociprefix-wls-0 wlsociprefix-wls-0.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0
10.1.2.4 wlsociprefix-wls-1. subnetfra.vcnfra.oraclevcn.com wlsociprefix-wls-1 wlsociprefix-wls-1.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0

# Front-end virtual name to secondary LBRIP
222.222.222.222 mywebapps.example.com

Usa DNS (Domain Name System) OCI

I nomi host utilizzati dagli host Oracle WebLogic Server primari vengono aggiunti al risolutore DNS utilizzato dalla VCN dei server di livello intermedio secondari, che punta agli indirizzi IP degli host Oracle WebLogic Server secondari. Questa modalità è valida quando i server DNS separati vengono utilizzati nei siti Oracle Cloud Infrastructure (OCI) primari e secondari. In caso contrario, può causare conflitti nella risoluzione dei nomi. Il server di ciascun sito dovrebbe risolvere questi nomi con i propri IP. Il vantaggio di questo metodo consiste nella possibilità di aggiungere tutte le voci a una vista DNS privata, invece di aggiungerle a tutti gli host /etc/hosts di Oracle WebLogic Server.

Di seguito sono riportati i passi per creare la vista privata nella VCN secondaria e risolvere i nomi host utilizzati dal database primario con gli IP secondari.

  1. Nella console OCI, andare all'area secondaria e creare la vista privata per risolvere i nomi degli host PRIMARY con gli indirizzi IP SECONDARY.
    1. Fare clic su Networking, DNS Management, Viste private, quindi su Crea vista privata.
      Ad esempio, è possibile assegnare un nome alla vista privata: PRIMARY_HOSTNAMES_PRIVATE_VIEW
    2. Fare clic su Crea zona nella vista privata.
      Per il nome della zona, è necessario usare il dominio completo degli host. Ad esempio: subnetpri.vcnpri.oraclevcn.com
    3. Aggiungere i nomi host primari a questa zona (nome breve), ma risolverli con l'indirizzo IP degli host Oracle WebLogic Server secondario.
    4. Fare clic su Pubblica modifiche.
  2. Aggiungere la vista privata al resolver VCN secondario.
    1. Fare clic sulla risorsa resolver DNS nella rete VCN.
    2. Aggiungere la vista privata DNS creata in precedenza.
      Gli host nella VCN secondaria risolveranno i nomi host utilizzati dagli host Oracle WebLogic Server primari utilizzando la vista privata.
  3. Convalidare la risoluzione degli host SECONDARY eseguendo le operazioni ping e nslookup dei nomi host.
    Essi devono essere risolti con gli equivalenti IP SECONDARI.

    Nota:

    È possibile trovare il codice Terraform per creare questa vista privata OCI e i relativi record in GitHub.

Configurare il sistema secondario

Per configurare il sistema come secondario, è necessario copiare la configurazione del dominio del server WebLogic dal database primario al server WebLogic secondario, Oracle SOA Suite o al dominio di sistema Oracle Fusion Middleware secondario.
L'impostazione del disaster recovery (DR) sostituisce tutto il dominio secondario, ad eccezione di directory e file specifici che devono rimanere validi a livello locale. Queste directory vengono escluse in modo esplicito dagli script. Inoltre, lo script sostituisce i file dell'origine dati in modo che il secondario utilizzi gli stessi nomi di schema DB come nel database primario, ma con il file jdbc url esistente che punta al database locale (copia aggiornabile durante l'impostazione di DR e in standby in preparazione allo switchover) con i wallet necessari.
  1. Eseguire lo script fmwadb_dr_prim.sh nel nodo di amministrazione del server WebLogic primario.
    Lo script controllerà la connettività tra i nodi del server di amministrazione del WebLogic Server tramite il gateway di instradamento dinamico e copierà il dominio nella directory intermedia in un'area di accesso Oracle Cloud Infrastructure File Storage nell'area secondaria.

    Utilizzare i seguenti parametri:

    • REMOTE_ADMIN_NODE_IP

      L'indirizzo IP del nodo secondario del server di amministrazione del WebLogic Server.

      Questo IP deve essere raggiungibile da questo HOST (nodo primario del server di amministrazione di Oracle WebLogic Server).

      Si consiglia di utilizzare il gateway di instradamento dinamico per interconnettere i siti primari e secondari, in modo da fornire l'indirizzo IP privato.

    • REMOTE_SSH_PRIV_KEYFILE

      Il file di chiavi SSH privato per connettersi al nodo remoto del server di amministrazione di Oracle WebLogic.

    • FSS_MOUNT

      Directory attivata dello storage di file OCI utilizzata per posizionare nell'area intermedia la copia della configurazione del dominio del server WebLogic. 

    ./fmwadb_dr_prim.sh [REMOTE_ADMIN_NODE_IP] [REMOTE_SSH_PRIV_KEYFILE] [FSS_MOUNT]
    Di seguito viene fornito un esempio del comando e dell'output:
    [oracle@soarefr-soa-0 ~]$ ./fmwadbs_dr_prim.sh '10.2.1.104' '/u01/soacs/dbfs/share/KeyWithoutPassPhraseSOAMAA.ppk' /u01/soacs/dbfs/share/
 Checking ssh connectivity to remote WebLogic Administration server node....
    Connectivity to 10.2.1.104 is OK
    REMOTE_ADMIN_HOSTNAME...... soarefr-soa-0.sub09051735411.soaadbvcnstby.oraclevcn.com
 Checking local FSS mount folder readiness........
     The FSS is expected to be mounted in /u01/soacs/dbfs/share
     The folder for the copy of the domain is expected to be /u01/soacs/dbfs/share/domain_config_copy
     Local folder /u01/soacs/dbfs/share/domain_config_copy exists.
 Checking remote FSS mount folder readiness........
     Remote folder 10.2.1.104:/u01/soacs/dbfs/share/domain_config_copy exists.
 
----------- Rsyncing from local domain to local FSS folder ---------------
 
Local rsync output to /u01/soacs/dbfs/share/domain_config_copy/last_primary_update_local_06-10-2022-09-47-50.log ....
Source and target directories are in sync. ALL GOOD!
 
----------- Local rsync complete -----------------------------------------
 
----------- Rsyncing from local FSS folder to remote site... --------------
Remote rsync output to /u01/soacs/dbfs/share/domain_config_copy/last_primary_update_remote_06-10-2022-09-47-50.log ....
Source and target directories are in sync. ALL GOOD!
  2. Quando lo script fmwadb_dr_prim.sh termina l'esecuzione, se non è già stato arrestato, arrestare tutti i sistemi del server WebLogic e i Node Manager nel sistema secondario.
  3. Eseguire il login al nodo di amministrazione del server WebLogic secondario ed eseguire lo script fmwadb_dr_stby.sh.

    Lo script copia il dominio del server WebLogic dalla directory intermedia in uno storage di file OCI nella directory del dominio del server WebLogic secondario e sostituisce le voci del wallet e della password richieste. Il wallet da fornire è la copia aggiornabile in modo che la versione secondaria possa essere convalidata dopo l'impostazione del DR iniziale.

    Utilizzare i seguenti parametri:

    • WALLET_DIR

      La directory per un wallet Oracle Autonomous Database decompresso. Nodo del server di amministrazione WebLogic Server.

      Questa directory deve contenere almeno file tnsnames.ora, keystore.jks e truststore.jks.

      Se si utilizza l'approccio di standby snapshot, si tratta solo della cartella tnsadmin.

    • WALLET_PASSWORD

      La password fornita quando il wallet è stato scaricato dall'interfaccia utente OCI di Oracle Autonomous Database Serverless.

      Se il wallet è quello iniziale creato dal sistema WebLogic Server, Oracle SOA Suite o Oracle Fusion Middleware durante il provisioning. È possibile ottenere il comando seguente:

      Oracle SOA:
      python /opt/scripts/atp_db_util.py generate-atp-wallet-password
      Oracle WebLogic Server:
      python3 /opt/scripts/atp_db_util.py generate-atp-wallet-password
    • FSS_MOUNT

      La directory di cui è stato eseguito il MOUNT dello storage di file OCI utilizzata per posizionare nell'area intermedia la configurazione del dominio del server WebLogic. 

    ./fmwadb_dr_stby.sh [WALLET_DIR] [WALLET_PASSWORD] [FSS_MOUNT]
    Di seguito viene fornito un esempio dell'esecuzione e dell'output del comando:
    [oracle@wsladbs2-wls-0 scripts]$ ./fmwadb_dr_stby.sh /u01/data/domains/wsladbs2_domain/config/atpwallet/  7f3e3ed8ee7921fed058b481298eca55 /u01/shared/
Backing up current domain...
Backup created at /u01/data/domains/wsladbs2_domain/ /u01/data/domains/wsladbs2_domain_backup_11_42_19-26-10-22
Rsyncing from FSS  mount to domain dir...
 Syncing the Weblogic Administration server node...
Rsync complete!
Switching config to /u01/data/domains/wsladbs2_domain/config/atpwallet/
The password provided for the wallet is valid. Proceeding...
Gathering Data Soure information...
The new wallet is the same as the one being used.
Will maintain existing wallet dir and just replace password
Backing up current config...
Backup created at  /u01/data/domains/wsladbs2_domain/DS_backup_11_42_33-26-10-22
Replacing values in datasources...
Replacement complete!
  4. Eseguire lo script fmwadb_dr_stby.sh negli altri nodi server gestiti del WebLogic Server nell'area secondaria.
  5. Assicurarsi che il database in standby sia accessibile in modalità di lettura-scrittura.
    • Se si utilizza l'approccio in standby dello snapshot, assicurarsi che il database in standby venga convertito nel database in standby dello snapshot in modo che sia accessibile in modalità di lettura-scrittura.
    • Se si utilizza l'approccio Copia aggiornabile remota, assicurarsi che sia disconnesso dall'origine, quindi sia accessibile in modalità di lettura-scrittura.
  6. Avviare Node Manager e Oracle WebLogic Administration Server in modalità secondaria. Accedere alla console e avviare i server gestiti del server WebLogic nel dominio.
  7. Verificare che anche le applicazioni e le distribuzioni esistenti nel database primario siano disponibili nel database secondario.
  8. Arrestare il server WebLogic in secondario.
  9. Convertire il database in standby fisico o riconnettere la copia aggiornabile.

    • Se si utilizza l'approccio di standby snapshot, convertire il database in standby fisico.

    • Se si utilizza la copia aggiornabile remota, riconnettere la copia aggiornabile. Promemoria: la copia aggiornabile non può rimanere disconnessa dal database primario per più di 24 ore.

Lascia il sistema pronto per lo switchover

Dopo aver configurato e convalidato il sistema secondario con una copia aggiornabile, lasciare il sistema pronto per lo switchover puntando l'alias TNS a Oracle Autonomous Database Serverless in standby.

Nota:

Questo task è necessario solo quando il sistema secondario è configurato e convalidato con una copia aggiornabile remota.

Scaricare il wallet per il database in standby dall'interfaccia utente del database secondario. Evitare di utilizzare stringhe di connessione doppie (sia host primari che in standby) nei casi di recupero da errori irreversibili (DR remoti, causa di tentativi non necessari).

  1. Eseguire il login all'interfaccia utente di Oracle Autonomous Database Serverless per il database di standby.
  2. Fare clic su Autonomous Database, selezionare autonomous_db_name, fare clic su Connessione DB, quindi fare clic su Scarica wallet.
  3. Se il wallet contiene stringhe doppie che puntano al database primario, rimuovere la voce della descrizione primaria dal file tnsnames.ora in modo che la stringa di connessione punti SOLO al database locale nell'area secondaria.

    Di seguito è riportata una modifica di esempio del file tnsnames.ora. 

    soaadb1_high = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_low = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_medium = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_tp = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_tpurgent = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))

SHOULD BE

soaadb1_high = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))) 
soaadb1_low = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_medium = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tp = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tpurgent = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
  4. Copiare il wallet in una cartella temporanea nel nodo del server di amministrazione WebLogic dell'area secondaria e passare alla directory.
    [oracle@wsladbs2-wls-0 scripts]$ cd /tmp
[oracle@wsladbs2-wls-0 tmp]$ mkdir wallet-stby
[oracle@wsladbs2-wls-0 tmp]$ cd wallet-stby/
  5. Decomprimere il wallet.
    [oracle@wsladbs2-wls-0 wallet-stby]$ unzip /tmp/Wallet_soaadb1-standby.zip
Archive:  ../Wallet_soaadb1-standby.zip
  inflating: ewallet.pem
  inflating: README
  inflating: cwallet.sso
  inflating: tnsnames.ora
  inflating: truststore.jks
  inflating: ojdbc.properties
  inflating: sqlnet.ora
  inflating: ewallet.p12
  inflating: keystore.jks
  6. Eseguire lo script fmwadb_switch_db_conn.sh per lasciare il livello intermedio pronto con il wallet secondario e la stringa di connessione.

    Di seguito è riportato un esempio dello script eseguito per puntare al wallet di standby Oracle Autonomous Database Serverless. 

    [oracle@wsladbs2-wls-0 scripts]$ ./fmwadb_switch_db_conn.sh /tmp/wallet-stby/ wallet_password
The password provided for the wallet is valid. Proceeding...
Gathering Data Source information...
The new wallet is the same as the one being used.
Will maintain existing wallet dir and just replace password
Backing up current config...
Backup created at  /u01/data/domains/wsladbs2_domain/DS_backup_10_38_32-27-10-22
Replacing values in datasources...
Replacement complete!

Imposta replica configurazione in corso

Quando il ciclo di vita del sistema richiede aggiornamenti di frequenza al file system del dominio, è possibile utilizzare uno script per automatizzare il processo di replica della configurazione. Lo script fmwadb_config_replica.sh replica le modifiche tramite la directory intermedia Oracle Cloud Infrastructure File Storage (OCI File Storage) a intervalli regolari.

La configurazione è pronta (preparata) per uno switchover dopo ogni replica.

Quando si utilizza la copia aggiornabile remota, si presuppone che la configurazione replicata sia "adattata" per il database in standby fisico (non per la copia aggiornabile). Se hai bisogno di una convalida o di un test utilizzando le copie aggiornabili, puoi modificare la configurazione del dominio in standby in modo che punti alla copia aggiornabile.

È necessario eseguire lo script fmwadb_config_replica.sh nei nodi di amministrazione del server WebLogic (sia nel database primario che in quello in standby) per replicare la configurazione. In genere, questo script è pianificato con un job cron per replicare la configurazione tra un server primario e uno in standby WebLogic, Oracle SOA Suite o un sistema Oracle Fusion Middleware a intervalli regolari su un sistema Oracle Autonomous Database. Questo script controlla il ruolo corrente del database locale per determinare se è in esecuzione nel sito primario o in standby.

  • Quando lo script viene eseguito nel sito PRIMARY, copia la configurazione del dominio dal dominio primario alla cartella di assistenza locale (FSS) e quindi alla cartella di assistenza del sito secondario (tramite rsync).
  • Quando lo script viene eseguito nel sito STANDBY, copia la configurazione del dominio dalla cartella di assistenza secondaria (OCI File Storage) nel dominio secondario e rende le sostituzioni necessarie per l'utilizzo delle origini dati con il database locale.

È necessario raccogliere parametri diversi dalla console OCI e cifrare la password per accedere ai wallet di Oracle Autonomous Database per motivi di sicurezza.

Di seguito è riportata una descrizione delle variabili utilizzate nello script e come ottenerle:

  • REMOTE_WLSADMIN_NODE_IP

    IP del nodo del server di amministrazione WebLogic Server remoto e peer.

    Questo è l'IP dell'host nodo nel server di amministrazione WebLogic Server nel sito peer. Deve essere raggiungibile dal nodo locale. Si consiglia di connettersi all'IP privato remoto del nodo utilizzando un gateway di instradamento dinamico.

  • REMOTE_SSH_PRIV_KEYFILE

    Il file di chiavi SSH privato per connettersi al nodo remoto del server di amministrazione di Oracle WebLogic.

  • TENANCY_OCID

    L'OCID della tenancy in cui risiede Oracle Autonomous Database. È possibile ottenere l'OCID dall'interfaccia utente di Oracle Cloud Infrastructure (OCI).

  • USER_OCID

    OCID dell'utente proprietario dell'istanza di database autonomo. Puoi trovare l'OCID nell'interfaccia utente OCI.

  • PRIVATE_KEY

    Percorso della chiave di formato PEM privata per questo utente.

  • LOCAL_ADB_OCID

    L'OCID di Oracle Autonomous Database in fase di ispezione. Puoi trovare l'OCID nella schermata Oracle Autonomous Database nella console OCI.

  • WALLET_DIR

    La directory per il wallet Oracle Autonomous Database locale (estrazione del wallet scaricato dalla console OCI). Questa directory deve contenere almeno i file tnsnames.ora, keystore.jks e truststore.jks. Quando si utilizza l'approccio in standby snapshot, si tratta della cartella tnsadmin.

  • ENC_WALLET_PASSWORD

    Incarnazione WLS ENCRYPTED della password fornita quando il wallet è stato scaricato dall'interfaccia utente OCI di Oracle Autonomous Database.

    Se il wallet è quello iniziale creato dal server WebLogic, da Oracle SOA Suite o da Oracle Fusion Middleware durante il provisioning del server WebLogic, è possibile utilizzare i comandi riportati di seguito per ottenere la password.

    Per WebLogic:
    [oracle@wsladbs2-wls-1 ~]$ python3 /opt/scripts/atp_db_util.py generate-atp-wallet-password
    Per SOA:
    [oracle@soarefr-soa-0 ~]$ python /opt/scripts/atp_db_util.py generate-atp-wallet-password
    Per cifrare la password, sia quella fornita nella console di OCI sia quella utilizzata durante il provisioning, è possibile utilizzare lo script fmw_enc_pwd.sh.
    ./fmw_enc_pwd.sh UNENC_WALLET_PASSWORD

    Utilizzare la stringa ottenuta per la variabile ENC_WALLET_PASSWORD.

  • FSS_MOUNT

    Directory attivata dello storage dei file OCI che verrà utilizzata per posizionare nell'area intermedia la configurazione del dominio del server WebLogic.

Dopo aver raccolto le informazioni per le variabili, eseguire le operazioni riportate di seguito per copiare e personalizzare gli script per l'ambiente in uso.

  1. Cifrare la password per accedere ai wallet di Oracle Autonomous Database per motivi di sicurezza.
  2. Copiare lo script nel sito principale, quindi modificare lo script che completa le variabili richieste per il sito principale.
    Vedere sopra per la descrizione delle variabili utilizzate nello script.
  3. Copiare lo script nel sito in standby, quindi modificare la compilazione dello script nelle variabili richieste per il sito in standby.
    Vedere sopra per la descrizione delle variabili utilizzate nello script.
  4. Dopo aver personalizzato ogni area (è necessario fornire l'OCID del database LOCAL per ogni area), eseguire i task riportati di seguito.
    1. Eseguire lo script nell'host di amministrazione di Oracle WebLogic nel database primario.
    2. Eseguire lo script nell'host di amministrazione di Oracle WebLogic nell'area secondaria.
  5. Aggiungere lo script a un job cron in ogni area.