1. Configurar una solución de DR híbrida para Oracle SOA Suite
  2. Configurar el entorno

Configurar el entorno

Configure el sistema secundario en OCI y configúrelo como el sistema local principal en espera.

Los scripts están disponibles para automatizar algunos de los pasos. Estos scripts no automatizan la configuración completa, por lo que debe completar las tareas y puede usar los scripts cuando se hace referencia a ellos.

Vaya a Descargar código del enlace para descargar los scripts a los que se hace referencia en este documento.

Preparación de los orígenes de datos WebLogic en el centro de datos principal

Hay varios enfoques que puede utilizar para la cadena de conexión de base de datos de los orígenes de datos WebLogic en una topología de recuperación ante desastres, como cadena doble, cadenas de conexión diferentes y alias TNS. Consulte la Guía de recuperación ante desastres de Oracle Fusion Middleware para obtener más información y comparar los diferentes enfoques. Utilizaremos el alias TNS porque requiere una configuración única. El uso de un alias TNS significa que no tendrá que modificar la configuración WebLogic cada vez que la copie en el secundario. El uso de un alias TNS en orígenes de datos GridLink está soportado al iniciar la versión de FMW 12.2.1.3.

El alias TNS es el mismo nombre en el primario y el secundario; por lo tanto, los orígenes de datos utilizan la misma cadena de conexión de base de datos. Se resuelve con un archivo tnsnames.ora que no se copia en espera, por lo que puede tener contenido tnsnames.ora diferente en cada sitio. Puede colocarlo por separado de la configuración de dominio WebLogic, en un sistema de archivos que no se replica entre sitios. O bien, dado que forma parte de la configuración, también puede almacenarlo en una carpeta en la configuración de dominio. En este caso, asegúrese de excluir esa carpeta al copiar la configuración de dominio de principal a en espera. Cada sitio resolverá el alias TNS con la cadena de conexión adecuada en cada sitio, apuntando solo a la base de datos local. Por ejemplo: 

Connect string in data sources in primary site:
jdbc:oracle:thin:@soapdb

The tnsnames.ora file in primary contains:
SOAPDB =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=soapdb.example.com))
)

Connect string in data sources in secondary site:
jdbc:oracle:thin:@soapdb
The tnsnames.ora file in secondary: 
SOAPDB =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=soapdb.example.com))
)

A continuación, se muestran las ventajas del uso del alias TNS:

  • Dado que se utiliza la misma cadena de conexión de base de datos en el dominio WebLogic config, no es necesario modificar la configuración WebLogic después de replicar config de la base de datos primaria a la base de datos en espera.
  • Puesto que cada sitio apunta únicamente a la base de datos local, no hay riesgo de interconexiones del nivel medio a la base de datos remota.

Si aún no está utilizando este enfoque en el sistema SOA principal, realice los siguientes pasos para utilizar un alias TNS en los orígenes de datos.

  1. Cree la carpeta tns en los hosts de nivel medio principales:

    El usuario de Oracle debe poder leer esta carpeta y colocarla en un sistema de archivos que no se replica entre sitios.

    Dado que la carpeta tns forma parte de la configuración, también puede crearla en la carpeta config que comparten todos los servidores. Sin embargo, en ese caso, asegúrese de excluir la carpeta tns al copiar la configuración de dominio de primaria a en espera o actualice tnsnames.ora en el sistema en espera, después de un failover o switchover, para que apunte a la base de datos secundaria. 

    [oracle@host3 ~]$ mkdir -p /home/oracle/tnsnames_dir
[oracle@host4 ~]$ mkdir -p /home/oracle/tnsnames_dir
  2. Cree un archivo tnsnames.ora en el directorio con el alias TNS que se utilizará en los orígenes de datos, como se muestra en el ejemplo.
    Oracle recomienda introducir la cadena en una sola línea.
    SOAPDB = 
(DESCRIPTION=
  (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=dbhost-scan.example.com)(PORT=1521))
  )
  (CONNECT_DATA=(SERVICE_NAME= soapdb.example.com))
)
  3. Especifique la propiedad oracle.net.tns_admin que apunta a la ubicación del directorio del archivo tnsnames.ora. Utilice uno de los siguientes métodos:

    • Opción 1: defina la propiedad como propiedad de conexión de origen de datos. Oracle recomienda este método.

      1. Especifique la propiedad oracle.net.tns_admin=tns_directory en la configuración del origen de datos.

        Para especificar esta propiedad en la consola de administración WebLogic, vaya a Servicios, haga clic en Orígenes de datos, seleccione un origen de datos de la lista, haga clic en Pool de conexiones y, a continuación, agréguelo al cuadro de texto Propiedades. Repita este paso para cada origen de datos.

        Por ejemplo: oracle.net.tns_admin=/home/oracle/tnsnames_dir

      2. Especifique esta propiedad en la seguridad de OPSS almacena los archivos jps-config-jse.xml y jps-config.xm disponibles en la carpeta $ASERVER_HOME/config/fmwconfig.

        Para modificar estos archivos jps, edítelos y agregue la propiedad oracle.net.tns_admin después de la propiedad jdbc.url. Por ejemplo, 

        …
<property name="jdbc.url" value="jdbc:oracle:thin:@soaedg"/>
<property name="oracle.net.tns_admin" value="tns_directory"/>
…

        Nota:

        Esta propiedad se aplica al archivo específico (origen de datos, archivo jps) en el que se especifica.

    • Opción 2: defina la propiedad como una propiedad de sistema java.

      1. Especifique la propiedad del sistema -Doracle.net.tns_admin=tns_directory donde tns_directory es la ubicación del directorio del archivo tnsnames.ora.

        Para definirla como una propiedad java para los servidores, edite los siguientes archivos:
        • $ASERVER_HOME/bin/setUserOverrides.sh and
        • $MSERVER_HOME/bin/setUserOverrides.sh (Este archivo no se comparte. Por lo tanto, debe editar el archivo en todos los hosts de nivel medio de SOA).

      2. Agregue el siguiente contenido a estos archivos: 

        # For using tns alias in the datasources 
export EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Doracle.net.tns_admin=/home/oracle/tnsnames_dir

        Nota:

        Esta propiedad se aplica a todos los orígenes de datos y archivos jps de Oracle WebLogic Server. Antes de ejecutar algunos de los comandos de WLST y el asistente de configuración, este enfoque requiere que defina la propiedad en el entorno.
        • Antes de ejecutar WLST, defina la propiedad en la variable de entorno WLST_PROPERTIES.
        • Antes de ejecutar el asistente de configuración, agregue la propiedad a la variable de entorno JVM_ARGS del script config_internal.sh.
      3. Opción 3: defina la propiedad en la URL jdbc.

        Especifique la ubicación del archivo tnsnames.ora como parte de la cadena de conexión en los orígenes de datos y los archivos jps: 

        jdbc:oracle:thin:@alias?TNS_ADMIN=tns_directory

      Nota:

      Esta propiedad se aplica al archivo específico (origen de datos, archivo jps) en el que se especifica.

      Puede utilizar este método con el controlador JDBC 18.3 y posterior. Esto se aplica a Fusion Middleware 12.2.1.4 (que utiliza el controlador JDBC 19.3) y posterior.

  4. Utilice el alias en la URL de definición de origen de datos sustituyendo la cadena de conexión por el alias.
    jdbc:oracle:thin:@soapdb
    Modifique los archivos siguientes:
    • En archivos de origen de datos, ubicados en $ASERVER_HOME/config/jdbc/
    • En los archivos jps-config.xml y jps-config-jse.xml, situados en $ASERVER_HOME/config/fmwconfig/
    Puede utilizar la consola de administración de Oracle WebLogic Server para modificar los orígenes de datos, pero debe editar manualmente los archivos jps-config xml. Puede utilizar el script update_dbconnect.sh para realizar la sustitución en todos los archivos mencionados.

    Vaya a Download Code (Descargar código) para que el enlace descargue el script.

  5. Reinicie cada Oracle WebLogic Server en el dominio.
    1. Detenga todos los servidores WebLogic en el dominio principal (servidor de administración y servidores gestionados).
    2. Inicie el servidor de administración en el dominio principal.
    3. Una vez que se esté ejecutando el servidor de administración, inicie los servidores gestionados.
    4. Verifique que las conexiones se hayan establecido correctamente con la base de datos.
  6. Mejores prácticas adicionales: al utilizar Oracle Database 12c o versiones posteriores, los valores de configuración de host y puerto de Oracle Notification Service (ONS) no son necesarios en los orígenes de datos GridLink.
    El controlador de cliente obtiene automáticamente la lista de Oracle Notification Service de la base de datos. Oracle recomienda utilizar esta función en lugar de proporcionar la dirección de exploración o la lista de nodos de Oracle RAC en la configuración de ONS de cada origen de datos. Asegúrese de que FAN está activado y de que la propiedad ONS nodes está vacía en cada origen de datos.
    1. Abra la consola de administración de Oracle WebLogic Server.
    2. Vaya a Servicios y, a continuación, a Orígenes de datos. Seleccione el nombre del origen de datos, Configuración y ONS.
    3. Verifique que la lista de nodos de ONS está vacía.

Configuración de la Red

Se necesita conectividad entre la red local principal y la red secundaria de Oracle Cloud Infrastructure (OCI). Oracle recomienda utilizar Oracle Cloud Infrastructure FastConnect, que le permite conectarse directamente a su red virtual en la nube de OCI mediante una conexión dedicada, privada y de gran ancho de banda. Puede elegir una velocidad de puerto adecuada en función de la cantidad de datos. También puede utilizar VPN de sitio a sitio, aunque proporciona un ancho de banda inferior y latencia variable, jitter y costo.
  1. Cree la VCN y las subredes en el compartimento de OCI según se define en Determinación de los recursos necesarios en OCI. Configure Oracle Cloud Infrastructure FastConnect (o VPN de sitio a sitio) para permitir la comunicación entre la red local y la VCN. Consulte FastConnect y la VPN de sitio a sitio para obtener información.
  2. Cree las reglas de red necesarias en OCI y en el firewall local y configure el origen, los destinos, los protocolos y los puertos, como se muestra en la tabla.

    Se supone que todo el tráfico está activado dentro de cada subred.

    Consulte la documentación de OCI para obtener información sobre las reglas de seguridad de red.

    Origen Destino Protocolo y puerto Uso
    Red local Subred de nivel medio de OCI SSH (puerto 22) Configuración y ciclo de vida
    Red local Subred de capa web de OCI SSH (puerto 22) Configuración y ciclo de vida (cuando se utiliza Oracle HTTP Server en OCI)
    Red local Subred de nivel de base de datos de OCI SSH (puerto 22) Configuración y ciclo de vida
    Hosts de base de datos locales Subred de nivel de base de datos de OCI SQLNET (puerto 1521) Para Oracle Data Guard redo transport
    Red local Subred de capa web de OCI HTTPS/HTTP (443, 80, 7001, 8888) Acceso a consolas de administración y servicios de Oracle SOA Suite
    Red local Subred de nivel medio de OCI HTTP (7001,7010,8001,8011,8021,9001) Para comprobaciones directas a Oracle WebLogic Server
    Subred de capa web de OCI Subred de nivel medio de OCI HTTP (7001,7010,8001,8011,8021,9001) Para la conectividad desde los componentes de capa web (Equilibrador de carga de OCI, Oracle HTTP Server) a los servidores WebLogic
    Subred de nivel medio de OCI Subred de nivel de base de datos de OCI SQLNET (1521), ONS (6200) Para la conectividad de los servidores WebLogic a la base de datos
    Subred de nivel medio de OCI Subred de capa fss de OCI Consulte Configuración de reglas de seguridad de VCN para File Storage para obtener información específica. Para montar las exportaciones del sistema de archivos de OCI File Storage con NFS.
    Subred de nivel medio de OCI Hosts de nivel medio locales SSH (puerto 22) Para rsync
    Subred de nivel de base de datos de OCI Hosts de bases de datos locales SQLNET (1521) Para Oracle Data Guard redo transport
    Subred de nivel medio de OCI Subred de capa web de OCI HTTPS (443) Para devoluciones de llamada desde la aplicación al front-end

    Nota:

    Puede encontrar código de terraform para crear la VCN, las subredes y las reglas de seguridad en Código de descarga.

Configurar Oracle Data Guard

Configure Oracle Data Guard entre la base de datos local principal y la base de datos en espera en Oracle Cloud Infrastructure (OCI).
  1. Configure Oracle Data Guard entre una base de datos principal, local y una base de datos en espera en OCI, como se describe en Hybrid Data Guard to Oracle Cloud Infrastructure.
    Para ayudar a configurar Oracle Data Guard, los scripts están disponibles en GitHub y se hace referencia a ellos en Código de descarga.
  2. Verifique que la configuración de Oracle Data Guard sea correcta mediante la interfaz de línea de comandos de Oracle Data Guard (DGMGRL).
    DGMGRL> show configuration verbose
  3. Una vez que haya terminado de configurar Oracle Data Guard (paso 2), cree los mismos servicios de base de datos en el sistema de base de datos OCI que los utilizados en el sistema local principal. Configure el servicio con el rol PRIMARY y con el rol SNAPSHOT_STANDBY.
    La configuración del servicio con ambos roles permite que DG Broker inicie automáticamente el servicio cuando la base de datos se convierte en una base de datos de instantánea en espera, que es necesaria cuando desea validar el sistema secundario sin realizar un switchover completo.
    Por ejemplo, si la base de datos principal utiliza el servicio de base de datos soapdb.example.com para acceder a la PDB, cree el mismo servicio en el sistema de base de datos OCI secundario. 
    srvctl add service -db $ORACLE_UNQNAME -service soapdb.example.com -preferred ORCL1,ORCL2 -pdb PDB1 -role "PRIMARY,SNAPSHOT_STANDBY"
srvctl modify service -db $ORACLE_UNQNAME -service soapdb.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT
srvctl config service -db $ORACLE_UNQNAME -service soapdb.example.com
  4. Si el servicio de la base de datos primaria se ha creado con el rol PRIMARY únicamente (que es el valor por defecto), puede modificarlo para agregar el rol de instantánea en espera.
    srvctl modify service -db $ORACLE_UNQNAME -s soapdb.example.com -role "PRIMARY,SNAPSHOT_STANDBY"
  5. Revise las políticas de Oracle Recovery Manager (RMAN) en la base de datos primaria para evitar que los archive logs se supriman antes de que se apliquen a la base de datos en espera.
    Asegúrese de que tiene la cláusula applied on all standby en la política de supresión archivelog de RMAN, en las bases de datos primaria y en espera.

Acerca de la versión de la base de datos y el nivel de parche

El directorio raíz de Oracle en la base de datos local y la base de datos en espera en OCI debe ser de la misma versión y en el mismo nivel de parche. Puede realizar esta acción de las siguientes formas:

  • Al seleccionar la imagen de software de base de datos durante el aprovisionamiento del sistema de base de datos en OCI, seleccione Mostrar todas las versiones y seleccione la misma versión de base de datos y el mismo nivel de juego de parches que la base de datos local.
  • Si la versión del directorio raíz de Oracle de la base de datos origen ya no está disponible en OCI para el aprovisionamiento, tendrá que aplicar parches al entorno de origen en el mismo nivel de parche de base de datos que el directorio raíz de la base de datos en el entorno en la nube.

El siguiente escenario es un ejemplo real de referencia. El directorio raíz de base de datos local es la 19.6 y el directorio raíz de base de datos de OCI es la 19.11.

  1. Ejecute el comando $ORACLE_HOME/OPatch/opatch lspatches para identificar los parches instalados en los entornos de origen y de destino.
    $ORACLE_HOME/OPatch/opatch lspatches

    La siguiente es la salida de este ejemplo:

    Parches del directorio raíz de Oracle de base de datos locales Parches de directorio raíz de Oracle de base de datos en OCI

    30676209;LNX64-20.1-RAC ASM HIT ORA-07445 EXCEPCIÓN ENCONTRADO AL VOLCADO DEL NÚCLEO [KSXPOSDIFQRY()+556]

    30613937;IPCOR TOPO SERVICE FIX IP TYPE BUG IN IP SELECTION

    30484981;ACTUALIZACIÓN DE LA VERSIÓN DE OJVM: 19.6.0.0.200114 (30484981)

    30489227;ACTUALIZACIÓN DE VERSIÓN DE OCW 19.6.0.0.0 (30489227)

    30557433;Actualización de versión de base de datos: 19.6.0.0.200114 (30557433)

    29780459;AUMENTAR _LM_RES_HASH_BUCKET Y REVERTIR CAMBIOS DE LA CORRECCIÓN DEL BUG 29416368

    30310195;DBSAT INFORMÓ DE RESTRICCIONES DESACTIVADAS PARA FRAGMENTACIÓN STS_CHUNKS EN GSMADMIN_INTERNAL.SHARD_TS

    32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E

    31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A

    30432118;SOLICITUD DE FUSIÓN SOBRE 19.0.0.0.0 PARA ERRORES 28852325 29997937

    31732095;ACTUALIZAR PERL EN 19C DATABASE ORACLE HOME A V5.32

    32490416; PARCHE DE PAQUETE DE JDK 19.0.0.0.210420

    32399816;ACTUALIZACIÓN DE LA VERSIÓN DE OJVM: 19.11.0.0.210420 (32399816)

    32579761;ACTUALIZACIÓN DE VERSIÓN DE OCW 19.11.0.0.0 (32579761)

    32545013;Actualización de la versión de la base de datos: 19.11.0.0.210420 (32545013)
  2. Analice los parches existentes: determine qué parches son puntuales, revise si ya están corregidos en los nuevos parches de RU o si se necesitan nuevos parches superpuestos, determine cuál de ellos se debe desinstalar, localice los archivos de parches adecuados para RU, etc.
  3. En función del análisis, desinstale los parches puntuales que ya están corregidos en la nueva RU antes de instalar la actualización de la RU (de lo contrario, causarán conflictos). En este ejemplo, los parches puntuales se corrigen en 19.11, por lo que se debe realizar un rollback de los parches antes de instalar la 19.11 RU.
    30676209;LNX64-20.1-RAC  ASM HIT ORA-07445  EXCEPTION ENCOUNTERED  CORE DUMP [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO SERVICE  FIX IP TYPE BUG IN IP SELECTION
  4. Localice, descargue e instale los parches de RU. En este ejemplo, los parches de 19,11 RU están ubicados en el parche de combinación 32578973: COMBO OF OJVM RU COMPONENT 19.11.0.0.210420 + GI RU 19.11.0.0.210420 y son los siguientes:
    32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)  
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)            
32545013;Database Release Update : 19.11.0.0.210420 (32545013)
  5. Localice, descargue e instale las superposiciones, los parches puntuales y otros parches que el directorio raíz de base de datos de OCI tenga sobre la RU. Por ejemplo: 
    29780459;INCREASE _LM_RES_HASH_BUCKET AND BACK OUT CHANGES FROM THE BUG 29416368 FIX
30310195;DBSAT REPORTED DISABLED CONSTRAINTS FOR SHARDING STS_CHUNKS ON GSMADMIN_INTERNAL.SHARD_TS
30432118;MERGE REQUEST ON TOP OF 19.0.0.0.0 FOR BUGS 28852325 (DSTV33 update) 29997937 (DSTV34 update)
31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A
32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E
32490416;JDK BUNDLE PATCH 19.0.0.0.210420
31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32
  6. Realice un análisis similar para los parches de GI.

Nota:

Este ejemplo sólo incluye el directorio raíz de Oracle de RDBMS. Puede que no sea estrictamente necesario aplicar parches a la instalación de GI local en el mismo nivel que el secundario:
  • Desde la perspectiva de Oracle Data Guard, no es estrictamente necesario tener las mismas versiones de GI en la base de datos primaria y en espera: Oracle Data Guard es completamente independiente de cualquier elemento de la base de datos, por lo que puede ejecutar diferentes versiones del sistema operativo, Oracle Clusterware, hardware o software de almacenamiento en diferentes ubicaciones sin restricciones de versiones ni tiempo. (ID de documento 12655700.1)
  • Independientemente de Oracle Data Guard, no es necesario tener la misma versión en las versiones de GI y RDBMS en una base de datos RAC: a partir de la versión 18c, la versión de Oracle Grid Infrastructure (GI) /Clusterware (CRS) debe ser igual o la versión más alta hasta el primer dígito en las combinaciones posibles en todo momento. Por ejemplo: la infraestructura de Grid puede estar en 18.1.0.0 y la base de datos en 18.3.0.0. (ID de documento 337737.1)

Se recomienda aplicar parches a GI en el mismo nivel que el directorio raíz de base de datos. Una vez que tenga que aplicar parches al directorio raíz de base de datos en una actualización de versión (RU) más reciente, muchos de los parches son comunes para DB y GI, y puede utilizar OPatchAuto para ambos directorios raíz al mismo tiempo.