Informazioni sulla configurazione di JD Edwards Disaster Recovery mediante OCI Full Stack Disaster Recovery

Architettura JD Edwards

Questa illustrazione illustra l'architettura di implementazione dell'applicazione JD Edwards, con aree sia primarie che secondarie.

Segue la descrizione dell'immagine jdr-dr-fsdr.png

Descrizione dell'illustrazione jdr-dr-fsdr.png

jde-dr-fsdr-oracle.zip

Area primaria

Nell'area primaria, l'ambiente JDE viene distribuito all'interno di una rete cloud virtuale (VCN) segmentata in tre subnet dedicate, separate dalla funzionalità delle risorse dell'applicazione, come descritto di seguito.

Livello load balancer
Il livello del load balancer ospita il load balancer OCI, che fornisce l'accesso ai servizi Web JDE per gli utenti finali.
Livello applicazioni
Il livello dell'applicazione contiene i componenti principali dell'applicazione, inclusi il server enterprise, il server Web e il server AIS (Application Interface Services)
Livello di gestione
Il livello di gestione include strumenti e servizi per la gestione e l'amministrazione di JDE, ad esempio il server di distribuzione e il server della console di Server Manager
Livello database
Nel livello di database, il database JDE viene distribuito in Autonomous Transaction Processing condiviso (ATP-S). Gli Application Server si connettono al database utilizzando gli endpoint. Oracle Autonomous Data Guard è abilitato, creando un database in standby nell'area secondaria e garantendo la replica dei dati in tempo reale per l'alta disponibilità e il disaster recovery.
Conservazione e protezione dei dati
I gruppi di volumi a blocchi utilizzati dalle istanze di computazione sono protetti dalla replica del gruppo di volumi tra più aree, con l'area secondaria configurata come destinazione di replica.

Area secondaria

L'area secondaria funge da sito di disaster recovery e esegue il mirroring dei componenti critici dall'indirizzo region.It primario contiene:

Struttura VCN replicata che corrisponde al layout di rete dell'area primaria.
Load balancer replica per garantire la continuità dell'accesso durante il failover.
Database ATP-S in standby che viene mantenuto sincronizzato con il database primario utilizzando Autonomous Data Guard.
Repliche dei gruppi di volumi, che garantiscono la disponibilità dei dati in caso di errore dell'area primaria.

Comprendere i file correlati alla configurazione di JD Edwards

JDE si basa su più file di configurazione per gestire la connettività tra i suoi componenti e altri livelli partecipanti, come database e servizi di autenticazione. Questi file svolgono un ruolo fondamentale nella definizione dei parametri di connessione, delle impostazioni di runtime e del comportamento di integrazione. Avere una corretta comprensione di questi file e dei relativi contenuti è essenziale durante la configurazione dello scenario di Disaster Recovery (DR) per garantire la perfetta funzionalità delle applicazioni.

Di seguito è riportato un riepilogo dei file di configurazione chiave:

sqlnet.ora

Scopo: memorizza la configurazione di Oracle Wallet utilizzata dall'applicazione per connettersi in modo sicuro al database.

Posizione: server JDE Enterprise/Batch. DR.

Considerazione: assicurarsi che il percorso del wallet punti alla posizione del wallet valida del database DR.

Percorso file: Oracle_ClientHome/network/admin

tnsnames.ora

Scopo: memorizza i nomi dei servizi di rete, che fungono da alias per gli indirizzi di rete del database.

Posizione: server JDE Enterprise, batch e Web.

Considerazioni sul DR: eseguire l'aggiornamento con l'indirizzo di rete corretto (FQDN/IP) del database DR.

Percorso file sui server Enterprise/Batch: Oracle_ClientHome/network/admin

Percorso file sui server Web: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jde.ini

Scopo: memorizza la configurazione runtime per l'applicazione JDE, inclusi i dettagli di connessione al database e le impostazioni di sicurezza.

Posizione: server JDE Enterprise e Batch.

Considerazioni sul DR: aggiornare la sezione DB SYSTEM SETTINGS con il nome del server corretto per l'ambiente DR.

Percorso file: JDE_HOME/e920/ini

jdbj.ini

Scopo: contiene le impostazioni del driver JDBj e i parametri di connessione al database per le applicazioni JDE.

Posizione: server Web e AIS JDE.

Considerazioni sul DR: assicurarsi che nella sezione JDBj-BOOTSTRAP DATA SOURCE sia specificato il nome del server corretto.

Percorso file: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jas.ini

Scopo: memorizza la configurazione per il componente Server HTML dei client Web EnterpriseOne.

Posizione: server Web JDE.

Considerazioni su DR: aggiornare quanto riportato di seguito.

Sezione FORMSERVICE con l'host e la porta AIS corretti.
Sezione Security con il valore OracleAccessSSOSignOffURL appropriato se SSO è abilitato.

Percorso file: SM_Agent_Home/SCFHA/Target/Managed Instance/config

rest.ini

Scopo: contiene la configurazione per il server AIS, inclusi i percorsi delle API REST, le impostazioni di autenticazione e i collegamenti al server JAS.

Posizione: server AIS JDE.

Considerazioni su DR: aggiornare quanto segue:

Sezione BASIC CONFIG con l'host e la porta JAS corretti.
Sezione Security con il file IDCSSSOSignOffURL aggiornato se SSO è abilitato.

Percorso file: SM_Agent_Home/SCFHA/Target/Managed Instance/config

gestione-console.xml

Scopo: questo file XML contiene informazioni sui diversi server, le relative configurazioni e le autorizzazioni di accesso utente.

Posizione: Server Server Manager

Considerazioni sul DR: assicurarsi che il nome host corretto sia specificato in management-console.xml

Percorso file: SM_Console_Home/SCFMC/targets/home

agente. proprietà

Scopo: file di configurazione con impostazioni per il Management Agent, un componente che interagisce con la Management Console e gestisce i server EnterpriseOne

Posizione: Server Server Manager

Considerazioni su DR: assicurarsi che nella sezione agent.properties sia specificato il nome server corretto.

Percorso file: SM_Console_Home/ SCFMC/config

Aggiornamenti aggiuntivi a livello di sistema

Oltre ai file di configurazione delle applicazioni, durante un'implementazione DR è necessario rivedere e aggiornare i file di sistema indicati di seguito.

Host Linux e file fstab: assicurarsi che siano definiti indirizzi IP e FQDN validi.
File host Windows: aggiornamento con i mapping IP e FQDN correnti in base alle esigenze.
File wallet WebLogic: deve essere aggiornato per riflettere il wallet del database specifico di DR per garantire la connettività se il database è Autonomous.

La corretta manutenzione e l'aggiornamento di questi file di configurazione assicura che JDE continui a funzionare correttamente in un ambiente di Disaster Recovery, riducendo al minimo i tempi di inattività e mantenendo una connettività delle applicazioni sicura e coerente.

Comprendere i concetti di Full Stack Disaster Recovery

Durante la configurazione e l'implementazione di FSDR, sarà necessario comprendere i concetti e le terminologie seguenti.

Gruppo di protezione DR
- Definizione: un gruppo di protezione DR include tutte le risorse OCI necessarie, come istanze di computazione, gruppi di volumi, load balancer e database, che insieme formano uno stack di applicazioni completo.
- Vantaggio: un gruppo di protezione DR viene trattato come una singola unità per gli scenari di failover, failback e test. Garantisce che tutte le risorse vengano recuperate insieme, riducendo al minimo i tempi di inattività e la perdita di dati.
Piano DR
Un piano DR è un runbook automatico creato da FSDR per eseguire il disaster recovery per tutte le risorse del gruppo di protezione DR primario. È costituito da passi che definiscono il modo in cui tutte le risorse in un'area del gruppo di protezione DR primario vengono trasferite all'area del gruppo di protezione DR secondario peer. Di seguito sono riportati i vari tipi di piani DR.
- Failover (non pianificato): utilizzare un piano di failover quando si desidera eseguire una transizione immediata attivando lo stack di applicazioni nella standby region, senza tentare di chiudere il servizio nell'area primaria. I piani di failover vengono in genere utilizzati per eseguire le transizioni DR quando un'indisponibilità o una calamità si ripercuote sull'area primaria.
- Switchover (pianificato): utilizzare un piano di switchover quando si desidera eseguire una transizione ordinata chiudendo lo stack di applicazioni nell'area primaria e riportandolo nella standby region. I piani di switchover vengono in genere utilizzati ai fini della manutenzione pianificata del sito, dell'applicazione di patch software, del test DR e della convalida.
- Start drill: un start drill genera un piano per eseguire il drill DR senza interrompere le risorse del gruppo di protezione DR primario. Crea una replica delle risorse nel gruppo di protezione DR in standby.
- Interrompi drilling: questo piano DR interrompe il drilling DR rimuovendo la replica delle risorse create dal drilling iniziale.
Spostamento istanza
- Definizione: istanze distribuite solo nell'area principale.
- Caso d'uso: comune nelle topologie DR fredde, in cui è necessario pre-distribuire pochissimi o nessuno dei componenti di un'applicazione o di un servizio nella standby region in preparazione di una transizione DR futura.
- Comportamento: durante un evento di emergenza, lo spostamento delle istanze viene spostato dal gruppo di protezione DR dell'area primaria al gruppo di protezione DR della standby region.
- Vantaggio: efficienza in termini di costi, poiché le risorse nella standby region non sono in esecuzione continuamente.
- Considerazione: questo metodo richiede tempi di recupero più lunghi a causa della necessità di eseguire il provisioning e avviare le istanze nella standby region.
Istanza non in movimento
- Definizione: istanze pre-distribuite in entrambe le region primarie e standby.
- Caso d'uso: comune nelle topologie DR attivo-passivo, in cui alcuni o tutti i componenti di un'applicazione o di un servizio vengono pre-distribuiti nella standby region per prepararsi a una transizione DR futura.
- Comportamento: durante le operazioni DR, queste istanze vengono avviate o arrestate in base alle esigenze per la transizione del servizio tra le aree.
- Vantaggio: questo metodo garantisce un recupero più rapido a causa di un'infrastruttura preesistente nella standby region.
- Considerazione: ciò può comportare costi più elevati perché l'infrastruttura deve essere gestita in entrambe le aree.

Prerequisiti di Full Stack Disaster Recovery

Prima di procedere con il processo FSDR, è necessario completare i prerequisiti riportati di seguito.

Eseguire il provisioning di una VCN, subnet, tabelle di instradamento, liste di sicurezza e gateway di rete nell'area DR. Per supportare la funzionalità di failover e la connettività, assicurarsi che le configurazioni di rete rispecchino quelle dell'area primaria.
Definire un gruppo dinamico per consentire i criteri che concedono privilegi di amministratore alle istanze create nell'ambito dell'ambiente DR.
Sono necessari i diritti di amministratore per eseguire gli script sulle istanze di computazione. Il plugin Esegui comando utilizza l'utente ocarun per eseguire questi script. Assicurarsi che questo utente disponga delle autorizzazioni appropriate.
1. Aprire oracle-cloud-agent-run-command per la modifica:
```
 vi ./101-oracle-cloud-agent-run-command
```
2. Aggiungere le righe seguenti nel file di configurazione:
```
ocarun ALL=(ALL) 
NOPASSWD:ALL
```
3. Quindi eseguire:
```
vi sudo -cf ./101-oracle-cloud-agent-run-command
```
4. Aggiungere il file di configurazione a /etc/sudoers.d:
```
sudo cp ./101-oracle-cloud-agent-run-command /etc/sudoers.d/
```
Attiva la funzionalità di backup tra più aree per i gruppi di volumi.
Distribuire un load balancer nell'area secondaria. Nell'ambito della configurazione FSDR, solo il set backend (istanze) verrà spostato dal database primario alla standby region; il load balancer stesso deve essere creato manualmente nella standby region in anticipo.
Impostare un'istanza di database (peer) corrispondente nell'area DR per supportare il failover dell'applicazione.
Creare un bucket di storage degli oggetti per i log nell'area primaria. Questo bucket memorizzerà i log e gli artifact DR specifici dell'ambiente.
Creare un bucket di storage degli oggetti aggiuntivo nell'area di standby. Questo bucket verrà utilizzato a scopo di replica o log per garantire la disponibilità del DR nella standby region.
Inserire i seguenti script personalizzati nella posizione corretta.

Applica gli script personalizzati

Questi script personalizzati vengono eseguiti durante il processo FSDR.

update_rest

Server applicabile: AIS

#Define the old and new file names
old_file1="rest_dr.ini"
new_file1="rest.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"
 # Copy the new second file back to the original name, preserving attributes
 cp -p "$new_file1" "$old_file1"
 echo "Copied $new_file1 back to $old_file1 (preserving attributes)"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_tnsnames_jdbj

Server applicabili: JAS, AIS

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="jdbj_dr.ini"
old_file3="jas_dr.ini"
new_file1="tnsnames.ora"
new_file2="jdbj.ini"
new_file3="jas.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"

 # Rename the third file
 mv "$old_file3" "$new_file3"
 echo "Renamed $old_file3 to $new_file3"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_wallet

Server applicabili: tutti i server JDE (Enterprise, AIS, JAS, Fatclient, integrazioni e così via)

# Define old and new wallet folder names
old_wallet="Wallet_jdeorcl_hyderabad"
new_wallet="Wallet_jdeorcl"

# Check if the old wallet directory exists
if [ -d "$old_wallet" ]; then
  # Remove any existing new_wallet directory to avoid conflict
  if [ -d "$new_wallet" ]; then
    echo "Removing existing $new_wallet directory..."
    rm -rf "$new_wallet"
  fi

  # Rename the old wallet to the new name
  mv "$old_wallet" "$new_wallet"
  echo "Renamed $old_wallet to $new_wallet"

  # Copy the new wallet back to the old wallet directory for reuse
  cp -r "$new_wallet" "$old_wallet"
  echo "Copied $new_wallet back to $old_wallet for reuse"

else
  echo "Directory $old_wallet does not exist. Aborting operation."
fi

update_ini

Server applicabile: Enterprise

# Define the old and new file names
old_file2="JDE_DR.INI"
old_file3="jdbj_dr.ini"
new_file2="JDE.INI"
new_file3="jdbj.ini"

# Check if the old files exist in the folder
if [ -e "$old_file2" ] && [ -e "$old_file3" ] ; then
    # Rename the second file
    mv "$old_file2" "$new_file2"
    echo "Renamed $old_file2 to $new_file2"

    # Rename the third file
    mv "$old_file3" "$new_file3"
    echo "Renamed $old_file3 to $new_file3"
else
    echo "Old files do not exist in the folder."
fi

update_tnsnames_sqlnet

Server applicabili: Enterprise, Deployment, Fatclients

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="sqlnet_dr.ora"
new_file1="tnsnames.ora"
new_file2="sqlnet.ora"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"
else
 echo "One or both of the old files do not exist in the folder."
fi

update_agent_properties

Server applicabili: tutti i server gestiti da Server Manager

# Define the old and new file names
old_file1="agent.properties"
new_file1="agent_dr.properties"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi

update_management_console

Server Applicabile: Sever Manager

# Define the old and new file names
old_file1="management-console_dr.xml"
new_file1="management-console.xml"

# Check if the old files exist in the folder
if [ -e "$old_file1" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi