Acerca de la configuración de JD Edwards Disaster Recovery mediante OCI Full Stack Disaster Recovery

Arquitectura de JD Edwards

En esta ilustración se describe la arquitectura de despliegue de la aplicación JD Edwards, con regiones principales y secundarias.

Descripción de la ilustración jdr-dr-fsdr.png

jde-dr-fsdr-oracle.zip

Región Primaria

En la región principal, el entorno de JDE se despliega en una red virtual en la nube (VCN) segmentada en tres subredes dedicadas, separadas por la funcionalidad de recursos de aplicaciones, como se describe a continuación.

Nivel de equilibrador de carga
El nivel de equilibrador de carga aloja el equilibrador de carga de OCI, que proporciona acceso a los servicios web de JDE para los usuarios finales.
Capa de Aplicaciones
El nivel de aplicación contiene los componentes principales de la aplicación, incluidos el servidor de empresa, el servidor web y el servidor de servicios de interfaz de aplicación (AIS)
Nivel de gestión
El nivel de gestión incluye herramientas y servicios para la gestión y administración de JDE, como el servidor de despliegue y el servidor de la consola de Server Manager
Nivel de base de datos
En la capa de base de datos, la base de datos de JDE se despliega en Autonomous Transaction Processing–Shared (ATP-S). Los servidores de aplicaciones se conectan a la base de datos mediante puntos finales. Oracle Autonomous Data Guard está activado, lo que permite crear una base de datos en espera en la región secundaria y garantiza la replicación de datos en tiempo real para una alta disponibilidad y una recuperación ante desastres.
Almacenamiento y protección de datos
Los grupos de volúmenes en bloque que utilizan las instancias informáticas están protegidos por la replicación de grupos de volúmenes entre regiones, con la región secundaria configurada como destino de replicación.

Región secundaria

La región secundaria sirve como sitio de recuperación ante desastres y refleja los componentes críticos de region.It principal que contiene:

Estructura de VCN replicada que coincide con el diseño de red de la región principal.
Un equilibrador de carga de réplica para garantizar la continuidad del acceso durante el failover.
Una base de datos ATP-S en espera que se mantiene sincronizada con la principal mediante Autonomous Data Guard.
Replicas de grupos de volúmenes, lo que garantiza la disponibilidad de los datos en caso de que se produzca un fallo en la región principal.

Descripción de los archivos relacionados con la configuración de JD Edwards

JDE se basa en varios archivos de configuración para gestionar la conectividad entre sus componentes y otros niveles participantes, como bases de datos y servicios de autenticación. Estos archivos desempeñan un papel fundamental a la hora de definir los parámetros de conexión, la configuración de tiempo de ejecución y el comportamiento de integración. Conocer correctamente estos archivos y su contenido es esencial al configurar el escenario de Disaster Recovery (DR) para garantizar una funcionalidad de aplicación perfecta.

A continuación, se muestra un resumen de los archivos de configuración clave:

sqlnet.ora

Objetivo: almacena la configuración de Oracle Wallet utilizada por la aplicación para conectarse de forma segura a la base de datos.

Ubicación: servidores de JDE Enterprise/Batch. RD

Consideración: asegúrese de que la ruta de acceso de cartera apunta a la ubicación de cartera válida de la base de datos de DR.

Ruta de archivo: Oracle_ClientHome/network/admin

tnsnames.ora

Finalidad: almacena nombres de servicio de red, que actúan como alias para las direcciones de red de la base de datos.

Ubicación: JDE Enterprise, Batch y servidores Web.

Consideración de DR: actualice con la dirección de red correcta (FQDN/IP) de la base de datos de DR.

Ruta de archivo en servidores de empresa/lote: Oracle_ClientHome/network/admin

Ruta de acceso de archivo en servidores web: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jde.ini

Finalidad: almacena la configuración de tiempo de ejecución para la aplicación JDE, incluidos los detalles de conexión de la base de datos y los valores de seguridad.

Ubicación: servidores de JDE Enterprise y Batch.

Consideración de DR: actualice la sección DB SYSTEM SETTINGS con el nombre de servidor correcto para el entorno de DR.

Ruta de archivo: JDE_HOME/e920/ini

jdbj.ini

Propósito: contiene la configuración del controlador JDBj y los parámetros de conexión de base de datos para las aplicaciones JDE.

Ubicación: servidores web y AIS de JDE.

Consideración de DR: asegúrese de que el nombre de servidor correcto esté especificado en la sección JDBj-BOOTSTRAP DATA SOURCE.

Ruta de archivo: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jas.ini

Objetivo: almacena la configuración del componente del servidor HTML de los clientes web EnterpriseOne.

Ubicación: servidores web de JDE.

Consideración de DR: actualice lo siguiente:

Sección FORMSERVICE con el host y el puerto AIS correctos.
Sección Security con el valor OracleAccessSSOSignOffURL adecuado si SSO está activado.

Ruta de archivo: SM_Agent_Home/SCFHA/Target/Managed Instance/config

rest.ini

Finalidad: contiene la configuración del servidor AIS, incluidas las rutas de la API de REST, la configuración de autenticación y los enlaces del servidor JAS.

Ubicación: servidores AIS de JDE.

Consideración de DR: actualice lo siguiente:

Sección BASIC CONFIG con el host y el puerto de JAS correctos.
Sección Security con el IDCSSSOSignOffURL actualizado si SSO está activado.

Ruta de archivo: SM_Agent_Home/SCFHA/Target/Managed Instance/config

gestión-console.xml

Propósito: este archivo XML tiene información sobre los diferentes servidores, sus configuraciones y permisos de acceso de usuario.

Ubicación: Servidor Server Manager

Consideración de DR: asegúrese de que el nombre de host correcto esté especificado en management-console.xml

Ruta de archivo: SM_Console_Home/SCFMC/targets/home

propiedades de agente

Propósito: archivo de configuración que tiene valores para Management Agent, un componente que interactúa con la consola de gestión y gestiona los servidores EnterpriseOne

Ubicación: Servidor Server Manager

Consideración de DR: asegúrese de que el nombre de servidor correcto se especifique en la sección agent.properties.

Ruta de archivo: SM_Console_Home/ SCFMC/config

Actualizaciones adicionales de nivel de sistema

Además de los archivos de configuración de la aplicación, también se deben revisar y actualizar los siguientes archivos del sistema durante una implementación de DR:

Archivos fstab y hosts de Linux: asegúrese de que se hayan definido las direcciones IP y los FQDN válidos.
Archivo de hosts de Windows: actualice con las asignaciones actuales de IP y FQDN según sea necesario.
WebLogic archivos de cartera: se deben actualizar para reflejar la cartera de base de datos específica de DR a fin de garantizar la conectividad si la base de datos es autónoma.

El mantenimiento y la actualización adecuados de estos archivos de configuración garantizan que JDE siga funcionando correctamente en un entorno de recuperación ante desastres, lo que minimiza el tiempo de inactividad y mantiene una conectividad de aplicaciones segura y coherente.

Comprensión de los conceptos de recuperación ante desastres de pila completa

Al configurar e implantar FSDR, deberá comprender los siguientes conceptos y terminologías.

Grupo de protección de DR
- Definición: un grupo de protección de DR incluye todos los recursos de OCI necesarios, como instancias informáticas, grupos de volúmenes, equilibradores de carga y bases de datos, que juntas forman una pila de aplicaciones completa.
- Ventaja: un grupo de protección de DR se trata como una sola unidad para failover, failback y en escenarios de prueba. Garantiza que todos los recursos se recuperen juntos, lo que minimiza el tiempo de inactividad y la pérdida de datos.
Plan de DR
Un plan de DR es un flujo de trabajo de FSDR automatizado creado por Full Stack Disaster Recovery para realizar una recuperación ante desastres para todos los recursos del grupo para la protección del DR principal. Consta de pasos que definen cómo se realiza la transición de todos los recursos de una región de grupo de protección de DR principal a su región de grupo de protección de DR secundaria peer. Estos son los distintos tipos de planes de DR:
- Failover (no planificado): utilice un plan de failover cuando desee realizar una transición inmediata al activar la pila del servicio en la región de espera, sin intentar cerrarlo en la región principal. Los planes de failover se suelen utilizar para realizar transiciones de DR cuando una interrupción o un desastre afecta a la región principal.
- Switchover (planificado): utilice un plan de switchover cuando desee realizar una transición ordenada mediante el cierre de la pila del aplicativo en la región principal y, a continuación, su desactivación en la región de espera. Los planes de switchover se suelen utilizar para el mantenimiento del sitio planificado, la aplicación de parches de software, las pruebas de DR y la validación.
- Iniciar cambio de nivel: un cambio de nivel de inicio genera un plan para realizar el cambio de nivel de DR sin interrumpir los recursos del grupo de protección de DR principal. Crea una réplica de recursos en el grupo de protección de DR en espera.
- Detener detalle: este plan de DR detiene el detalle de DR eliminando la réplica de los recursos creados por el inicio del detalle.
Movimiento de una instancia
- Definición: las instancias desplegadas solo en la región principal.
- Caso de uso: común en las topologías de DR frías, en las que muy pocos o ninguno de los componentes de una aplicación o servicio se deben desplegar previamente en la región en espera para prepararse para una transición en DR futura.
- Comportamiento: durante un evento de desastre, el movimiento de instancias del grupo de protección de DR de la región principal al grupo de protección de DR de la región en espera.
- Ventaja: rentabilidad, ya que los recursos de la región en espera no se ejecutan continuamente.
- Consideración: este método requiere tiempos de recuperación más largos debido a la necesidad de aprovisionar e iniciar instancias en la región en espera.
Instancia no móvil
- Definición: las instancias se han desplegado previamente en las regiones principal y en espera.
- Caso de uso: común en las topologías de DR active-passive, en las que algunos o todos los componentes de una aplicación o servicio se despliegan previamente en la región de espera para prepararse para una transición en DR futura.
- Comportamiento: durante las operaciones de DR, estas instancias se inician o paran según sea necesario para realizar la transición del servicio entre regiones.
- Ventaja: este método proporciona una recuperación más rápida debido a la infraestructura preexistente en la región en espera.
- Consideración: esto puede generar un costo más alto porque la infraestructura se debe mantener en ambas regiones.

Requisitos de recuperación ante desastres de pila completa

Antes de continuar con el proceso FSDR, debe completar los siguientes requisitos previos:

Aprovisione una VCN, subredes, tablas de rutas, listas de seguridad y gateways de red en la región de DR. Para admitir la funcionalidad de failover y la conectividad, asegúrese de que las configuraciones de red reflejen las de la región principal.
Defina un grupo dinámico para permitir políticas que otorguen privilegios de administrador a las instancias creadas como parte del entorno de DR.
Necesita derechos de administrador para ejecutar scripts en instancias informáticas. El plugin Run Command utiliza el usuario ocarun para ejecutar estas secuencias de comandos. Asegúrese de que este usuario tiene los permisos adecuados.
1. Abra oracle-cloud-agent-run-command para editar:
```
 vi ./101-oracle-cloud-agent-run-command
```
2. Agregue las siguientes líneas en el archivo de configuración:
```
ocarun ALL=(ALL) 
NOPASSWD:ALL
```
3. A continuación, ejecute:
```
vi sudo -cf ./101-oracle-cloud-agent-run-command
```
4. Agregue el archivo de configuración a /etc/sudoers.d:
```
sudo cp ./101-oracle-cloud-agent-run-command /etc/sudoers.d/
```
Active la funcionalidad de copia de seguridad entre regiones para los grupos de volúmenes.
Despliegue un equilibrador de carga en la región secundaria. Como parte de la configuración de FSDR, solo se moverán del juego de backends (instancias) de la región principal a la región en espera; el propio equilibrador de carga se debe crear manualmente en la región en espera con antelación.
Configure una instancia de base de datos (igual) correspondiente en la región de DR para soportar el failover de la aplicación.
Cree un cubo de almacenamiento de objetos para los logs en la región principal. Este cubo almacenará logs y artefactos de DR específicos del entorno.
Cree un cubo de almacenamiento de objetos adicional en la región en espera. Este cubo se utilizará con fines de replicación o registro para garantizar la preparación de DR en la región en espera.
Coloque los siguientes scripts personalizados en la ubicación adecuada.

Aplicación de scripts personalizados

Estos scripts personalizados se ejecutan durante el proceso FSDR.

update_rest

Servidor aplicable: 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

Servidores aplicables: 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

Servidores aplicables: todos los servidores de JDE (Enterprise, AIS, JAS, Fatclient, integraciones, etc.)

# 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

Servidor aplicable: 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

Servidores aplicables: 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

Servidores aplicables: todos los servidores gestionados por el gestor de servidores

# 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

Servidor aplicable: Gestor de servidores

# 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