1. Configuración de Oracle Fusion Middleware DR en Oracle Cloud con una base de datos autónoma
  2. Configuración de la topología de DR

Configuración de la topología de DR

Configurar la topología de recuperación ante desastres (DR). Los scripts están disponibles para simplificar el proceso.

Descarga de los Scripts

Obtenga los scripts de configuración más recientes del repositorio GitHub.

Nota:

Coloque todos los scripts descargados en la misma carpeta.
  1. Vaya al repositorio GitHub.
  2. Descargue todos los scripts en el directorio maa/fmw-wls-with-adb-dr.
  3. Descargue todos los scripts en el directorio maa/app_dr_common.
    Estos scripts se llaman entre sí. A pesar de la operación específica que se está realizando en un momento determinado, descargue los directorios completos y coloque todos los scripts en la misma carpeta. Necesitará los scripts tanto en el sitio principal como en el secundario.
  4. Siga las instrucciones de este documento y lea las variables necesarias en cada script para cada operación que realice.

El archivo descargado incluye scripts para realizar las siguientes tareas:

  1. Configurar un alias de TNS para orígenes de datos
  2. Configurar la DR inicial
  3. Configurar la replicación en curso
  4. Cambie las carteras de un sistema de Oracle WebLogic Server, Oracle SOA u Oracle Fusion Middleware.
Cada secuencia de comandos proporciona automatización para diferentes partes de la configuración de DR y el ciclo de vida de un sistema de protección ante desastres. En la tabla siguiente se proporciona un resumen de las utilidades:
Nombre de script Descripción
fmwadb_config_replica.sh Replicar la configuración entre sitios.
fmwadb_dr_prim.sh Prepara un sitio principal para la configuración de DR.
fmwadb_dr_stby.sh Prepara un sitio secundario para la configuración de DR.
fmwadb_rest_api_listabds.sh Obtenga la base de roles de Autonomous Database en la información de ID de ADB y arrendamiento.
fmwadb_switch_db_conn.sh Sustituye la información de conexión existente por un nuevo WALLET de ADBS.
fmw_change_to_tns_alias.sh Sustituya las cadenas de conexión utilizadas por los orígenes de datos de Oracle WebLogic y los archivos jps config por un alias tns.
fmw_dec_pwd.sh Descifra una contraseña cifrada de Oracle WebLogic.
fmw_enc_pwd.sh Cifra una contraseña mediante el cifrado de Oracle WebLogic.
fmw_get_connect_string.sh Devuelve la cadena de conexión que utiliza un origen de datos de Oracle WebLogic, Oracle SOA u Oracle Fusion Middleware.
fmw_get_ds_property.sh Devuelve el valor de una propiedad de origen de datos específica.

Preparación del nivel medio principal para el front-end virtual

Si el nivel medio principal aún no está configurado con un nombre de front-end virtual, realice estas acciones para prepararlo para la configuración de recuperación ante desastres (DR).

  1. Agregue el nombre de front-end virtual y la IP al archivo /etc/hosts en todos los hosts de nivel medio principales.
    Cada sitio siempre debe resolver el nombre de front-end en su equilibrador de carga local, independientemente de la resolución orientada al cliente a través del sistema de nombres de dominio (DNS). Como usuario root, edite el archivo /etc/hosts y asigne la IP pública del equilibrador de carga principal al nombre de dominio completo (FQDN) de front-end virtual. Repita el proceso en todos los hosts de Oracle WebLogic principales. Por ejemplo: 
    [oracle@wlsociprefix-wls-0 ~]$ more /etc/hosts
(...)
# Front-end virtual name
111.111.111.111 mywebapps.example.com

    Nota:

    El archivo /etc/hosts de los hosts de Oracle WebLogic principales no se debe modificar cuando hay un switchover o failover. Los hosts primarios de Oracle WebLogic siempre resolverán el nombre de front-end virtual con su IP de front-end. La actualización de DNS necesaria durante los procedimientos de switchover y failover se realiza en los archivos de host o DNS utilizados por los clientes.

  2. Configure el nombre de front-end como front-end de cluster.
    1. Inicie sesión en la consola de Oracle WebLogic de su instancia.
    2. Vaya a Entorno, Clusters y, a continuación, seleccione el cluster.
    3. Vaya a Configuración y, a continuación, a HTTP.
    4. Defina el host frontal en el FQDN de front-end.
      Por ejemplo, mywebapps.example.com.
    5. Asegúrese de que los puertos de frontend para HTTP y HTTPS estén configurados correctamente con valores.
    6. Haga clic en Guardar y, a continuación, en Activar.
  3. Reinicie el cluster para implementar los cambios.

Modificación de los Orígenes de Datos Primarios y la Configuración de JPS para Utilizar un Alias TNS

El uso de un alias de sustrato de red transparente (TNS) en URL de Java Database Connectivity (JDBC) facilita la reconfiguración de orígenes de datos de Oracle WebLogic Server for Oracle Cloud Infrastructure mediante clones de refrescamiento remoto para moverse entre la base de datos primaria y la base de datos en espera.

Nota:

Las instancias de Oracle SOA Suite on Marketplace aprovisionadas con la versión 23.1.1 (febrero de 2023) o posterior se configuran con el enfoque de alias TNS listo para usar. En este caso, puede omitir esta tarea.

El uso de un alias TNS requiere que los orígenes de datos y los archivos jps incluyan la variable oracle.net.tns_admin en los archivos de configuración de Oracle Fusion Middleware.

  1. Utilice el comando grep para buscar la variable oracle.net.tns_admin en el archivo de configuración de 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 ~]$
    El directorio reflejado en jps-config.xml (y los orígenes de datos) debe estar disponible y se debe poder acceder a él desde todos los nodos del dominio WebLogic Server.
    • En Oracle SOA Suite on Marketplace, este directorio se encuentra en el directorio $DOMAIN_HOME/config/atp (antes de la versión 23.1.1) o en el directorio $DOMAIN_HOME/config/tnsadmin (para la versión 23.1.1 y posteriores) y es replicado automáticamente por el servidor WebLogic en todos los demás nodos cuando se inician los servidores gestionados.

      Nota:

      Si su Oracle SOA Suite en Marketplace principal es anterior a la versión 23.1.1, se recomienda mover la carpeta al directorio $DOMAIN_HOME/config/tnsadmin para que sea coherente con la base de datos en espera.
    • En Oracle WebLogic Server for Oracle Cloud Infrastructure, se encuentra en $DOMAIN_HOME/atpwallet.

      Nota:

      Si la cartera no se encuentra en el directorio DOMAIN_HOME/config, la infraestructura de Oracle WebLogic Server NO replicará automáticamente los cambios en el contenido del directorio de cartera en otros nodos. En estos casos, debe cambiar el directorio de cartera (y actualizar las configuraciones de orígenes de datos necesarias) o copiarlo manualmente en otros nodos cuando se actualice.
    • En otras configuraciones, puede colocar el directorio en almacenamiento compartido.
    En todos los casos, los diferentes miembros de un dominio WebLogic Server deben poder acceder al mismo directorio tns_admin. Este directorio contendrá un archivo tnsnames.ora con diferentes alias para los distintos servicios creados en Oracle Autonomous Database.

    A continuación se muestra un archivo tnsnames.ora de ejemplo para la configuración de 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)))

    Los orígenes de datos de WLS consumen dinámicamente las modificaciones en el archivo tnsnames.ora. Esto significa que puede modificar el archivo tnsnames.ora (por ejemplo, para apuntar a un servicio diferente) sin necesidad de reiniciar el origen de datos.

  2. Para modificar una configuración de origen de datos estándar para utilizar un alias TNS en Oracle SOA Suite on Marketplace o un sistema Oracle WebLogic Server for Oracle Cloud Infrastructure que utilice Autonomous Database, utilice el script fmw_change_to_tns_alias.sh.

    El alias se debe utilizar en todos los archivos de origen de datos de $DOMAIN_HOME/config/jdbc y en los archivos jps config de $DOMAIN_HOME/config/fmwconfig.

    Nota:

    Este script solo cambiará la cadena de conexión y la propiedad tns_admin. Si agrega otros orígenes de datos personalizados, también necesitarán utilizar un alias de TNS como los internos para Oracle WebLogic, Oracle SOA Suite on Marketplace y Oracle Fusion Middleware.
    Cuando Oracle WebLogic Server for Oracle Cloud Infrastructure u Oracle SOA Suite on Marketplace se aprovisionan mediante Oracle Autonomous Database, la configuración de la cartera de base de datos se incluye en los orígenes de datos (ubicación del almacén de confianza, ubicación del almacén de claves, etc.). Estos parámetros NO son modificados por el script fmw_change_to_tns_alias.sh y son válidos si se utiliza el alias TNS o no. Oracle WebLogic Server for Oracle Cloud Infrastructure y Oracle SOA Suite on Marketplace crean un directorio de cartera durante el aprovisionamiento y ya contiene un archivo tnsnames.ora. También puede obtener la cartera de Oracle Autonomous Database de la interfaz de usuario de la base de datos autónoma en OCI.

    Nota:

    La cartera de Oracle Autonomous Database utilizada por Oracle WebLogic Server for Oracle Cloud Infrastructure y Oracle SOA Suite on Marketplace se descarga al nodo del servidor de administración cuando se aprovisionan. Puede actualizar la cartera para los sistemas principal y en espera descargándola de nuevo desde la interfaz de usuario de Oracle Autonomous Database y actualizando la contraseña de la cartera en el directorio $DOMAIN_HOME/config/jdbc y en los archivos jps config en $DOMAIN_HOME/config/fmwconfig. El uso de la misma contraseña para las carteras de la base de datos primaria, en espera y de la clonación de refrescamiento facilitará la manipulación de la configuración del origen de datos en ambos sitios; sin embargo, los scripts proporcionados a continuación podrán manejar contraseñas diferentes. Utilice el script fmwadb_switch_db_conn.sh para actualizar el sistema con una nueva cartera.

    Cuando se aprovisionó el sistema principal, eligió (en las pantallas de aprovisionamiento) uno de los niveles de servicio de Oracle Autonomous Database. Ejecute el script fmw_change_to_tns_alias.sh con el mismo nivel de servicio. Los niveles de servicio para un servicio de base de datos en Oracle Autonomous Database son: bajo, medio, alto, tpurgente. A continuación, se muestra un ejemplo de cambio de Oracle Fusion Middleware a alias 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. Reinicie todos los servidores de Oracle WebLogic del dominio para consumir los cambios realizados por el script.

Creación de una VCN y una subred en la región secundaria

Si aún no lo ha hecho, cree una VCN en la región en espera con un CIDR que no entre en conflicto con el CIDR de la región principal. Por ejemplo, si la VCN principal utiliza 10.1.0.0/16, la VCN secundaria podría utilizar 10.2.0.0/16.

  1. Cree una VCN y una subred en la región secundaria.
    Puede crear una pila en la nube para aprovisionar un grupo de servicios en la nube relacionados.
  2. Asegúrese de que las listas de seguridad permitan las comunicaciones adecuadas entre niveles.

    Verifique la siguiente comunicación:

    • Desde el equilibrador de carga de OCI al servidor WebLogic
    • Del servidor WebLogic a la base de datos
    • Desde el servidor WebLogic al almacenamiento compartido

    Además, incluya las reglas necesarias para permitir las comunicaciones entre los nodos del servidor de administración mediante el gateway de direccionamiento dinámico (DRG) una vez creado.

Configuración de un DRG entre las VCN principal y secundaria

La configuración de recuperación ante desastres requiere que los nodos de administración de Oracle WebLogic Server principales y secundarios se comuniquen entre sí para recibir la configuración de dominio a través de copias de Oracle Cloud Infrastructure File Storage. Para ello, debe crear un gateway de enrutamiento dinámico (DRG) entre las VCN de nivel medio.

  1. Cree un DRG entre las VCN de nivel medio.
  2. Verifique que el nuevo DRG aparezca en la página Gateways de enrutamiento dinámico del compartimento o región que haya elegido.
    Las secuencias de comandos de configuración de DR verificarán que se puedan establecer las conexiones necesarias.
  3. Configure las rutas y las reglas de seguridad adecuadas en las VCN principales y en espera para permitir conexiones SSH entre los niveles intermedios.
  4. Verifique que puede establecer una conexión SSH desde el nodo de Oracle WebLogic Administration Server en el nodo primario al nodo de Oracle WebLogic Administration Server en el secundario.
    Por ejemplo, si 10.2.1.104 es la IP del nodo del servidor de administración secundario, ejecute lo siguiente desde el nodo del servidor de administración principal.
    [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 ~]$

Creación de una base de datos en espera de Oracle Autonomous Data Guard en la región secundaria

Cree una base de datos en espera para Oracle Autonomous Database principal existente.

  1. Para Oracle Autonomous Database Serverless, cree una instancia de Oracle Autonomous Database Serverless en espera en la región secundaria.
    1. En la consola de OCI, haga clic en Oracle Database en el menú de navegación izquierda para navegar a Oracle Autonomous Database principal.
    2. En la página Detalles de Autonomous Database, en Recursos, haga clic en Recuperación ante desastres y, a continuación, en Agregar base de datos peer.
    3. Utilice las subredes VCN y privadas que ha creado anteriormente.
  2. Para Oracle Autonomous Database on Dedicated Exadata Infrastructure
    1. En la consola de OCI, vaya a la página de detalles de la base de datos de contenedores autónoma y seleccione el recurso Asociaciones de Autonomous Data Guard en la sección Recursos.
    2. Haga clic en Activar Autonomous Data Guard.
    3. Introduzca la información del cluster de VM autónomo peer, el modo de protección y la opción de failover automático. Después de introducir toda la información necesaria, haga clic en Activar Autonomous Data Guard.
      Como parte de este flujo de trabajo, se crea una nueva base de datos de contenedores autónoma en espera con todas las bases de datos autónomas en espera del cluster de VM autónomo seleccionado.

Preparación de la instancia de Autonomous Database en espera para la configuración de DR

Esta tarea depende de si se utiliza el enfoque de instantánea en espera o clonación de refrescamiento remoto.

Para obtener información sobre el enfoque de instantánea en espera, consulte Conversión de la base de datos en espera en una instantánea en espera.

Para conocer el enfoque de clonación de refrescamiento remoto, consulte Create a Remote Refreshable Clone in the Secondary Region.

Conversión de la Base de Datos en Espera en una Base de Datos de Instantánea en Espera

Mediante el enfoque Snapshot Standby, convierta la base de datos autónoma en espera en Snapshot Standby.

  1. En el menú de navegación izquierda de la consola de Oracle Cloud Infrastructure, haga clic en Autonomous Database.
  2. En la región secundaria, seleccione la instancia de Autonomous Database en espera.
  3. En la lista desplegable Más acciones, haga clic en Convertir a base de datos de instantánea en espera.
  4. Si utiliza una infraestructura dedicada, seleccione Usar servicios de base de datos primaria.

Nota:

Cuando una base de datos de instantánea en espera de la infraestructura de Exadata dedicada de Oracle no se convierte a la base de datos física en espera en un plazo de 7 días, la base de datos de instantánea en espera se convierte automáticamente a la base de datos física en espera.

Cuando una base de datos de instantánea en espera de Oracle Autonomous Database Serverless no se convierte a la base de datos física en espera en un plazo de 2 días, la base de datos de instantánea en espera se convierte automáticamente a la base de datos física en espera.

Creación de una clonación de refrescamiento remoto en la región secundaria

Mediante el enfoque Clonación de refrescamiento remoto, cree una clonación de refrescamiento a partir de la instancia principal de Oracle Autonomous Database Serverless existente en la región remota.

  1. Cree una clonación de refrescamiento a partir de la instancia principal existente de Oracle Autonomous Database Serverless.
    Coloque la clonación de refrescamiento en la región secundaria (remota) dentro de la VCN y la subred privada que creó anteriormente.

    Nota:

    No puede utilizar el mismo nombre de base de datos que el nombre de la base de datos primaria porque ya lo está utilizando la base de datos física en espera.
  2. Utilice Private Endpoint Access Only para acceder a la base de datos.

    Una vez creada, la clonación de refrescamiento permanecerá conectada y en modo de solo lectura. Los sistemas de Oracle WebLogic Server, Oracle SOA y Oracle Fusion Middleware no se pueden aprovisionar en él. A menos que se convierta en sistemas de lectura-escritura (desconectado de la principal).

  3. Desconecte la clonación de refrescamiento de la base de datos autónoma principal y conviértala en modo de lectura/escritura.

    Nota:

    La clonación de refrescamiento remoto no puede permanecer desconectada durante más de 24 horas. Por ejemplo, no puede tardar más de 24 horas en crear los niveles medios secundarios que apuntan a la base de datos de clonación de refrescamiento remoto.
    1. En el menú de navegación izquierda de Oracle Cloud Infrastructure, haga clic en Autonomous Database.
    2. Seleccione el nombre de la clonación de refrescamiento.
    3. Seleccione la base de datos de origen y, a continuación, haga clic en Desconectar.

Aprovisionamiento del sistema secundario

Aprovisione el servicio secundario de Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace u otro servicio de nivel medio de Oracle Cloud Infrastructure (OCI) que utilice Oracle Fusion Middleware (sistema) que apunte a la base de datos secundaria (para el enfoque de instantánea en espera) o a la clonación de refrescamiento (para el enfoque de clonación de refrescamiento remoto).

  1. Siga las recomendaciones de prefijo de la instancia, las reglas de seguridad y la subred estándar para la recuperación ante desastres.

    El nombre de pila puede ser diferente, pero debe utilizar el mismo prefijo de nombre de recurso EXACT que utilizó en su ubicación principal. Oracle recomienda utilizar exactamente la misma capacidad y configuración informática en las ubicaciones primaria y en espera para obtener el comportamiento ideal de failover/switchover.

    Asegúrese de que la versión de Oracle WebLogic Server para OCI y el nivel de parche que se aprovisionarán en la ubicación secundaria coinciden con el que se ejecuta en la ubicación primaria.

    Si necesita más información, consulte la tabla que resume las opciones del asistente de aprovisionamiento para la configuración de DR en la sección "Aprovisionamiento de WLS para OCI en el sitio secundario" de Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery o en la sección "Aprovisionamiento de SOA Suite en Marketplace en el sitio secundario" de SOA Suite en Oracle Cloud Infrastructure Marketplace Disaster Recovery.

  2. Cree el sistema de capa media secundario según el proceso de aprovisionamiento estándar.
  3. Compruebe el estándar Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace o cualquier otro servicio de nivel medio de Oracle Cloud Infrastructure (OCI) que utilice URL de Oracle Fusion Middleware (por ejemplo, Consola, soa-infra, etc.) para validar que el sistema se ha creado correctamente.
  4. Una vez validados, pare los procesos de Oracle WebLogic en la base de datos en espera: servidores gestionados, servidor de administración y gestores de nodos.
  5. Si utiliza una clonación de refrescamiento remoto, puede volver a conectarla al origen. Si está utilizando la base de datos de instantánea en espera, puede volver a convertirla a la base de datos física en espera.
    No intente iniciar los procesos de Oracle WebLogic en segundo plano hasta que finalice la configuración de DR.

Modificación de las cadenas de conexión de alias TNS del secundario

Modifique el alias utilizado en el sistema secundario para que sea el mismo alias que en el sistema principal.

Al igual que en el sistema principal, debe utilizar un alias de sustrato de red transparente (TNS) en todos los archivos de origen de datos de $DOMAIN_HOME/config/jdbc y en los archivos jps config de $DOMAIN_HOME/config/fmwconfig. El alias utilizado en el sistema secundario (en espera) será el mismo que en el sistema principal porque los orígenes de datos se replican desde el principal que contiene el alias creado anteriormente.

Esta tarea depende de si se utiliza un enfoque de instantánea en espera o clonación de refrescamiento remoto.

Modificación de las cadenas de conexión de alias TNS del secundario para el enfoque de instantánea en espera

Para el enfoque de instantánea en espera, se espera que los alias del archivo tnsnames.ora sean los mismos que en la base de datos primaria (aunque las cadenas de conexión apuntarán a la dirección de la base de datos en espera). No es necesario modificarlos.

  1. Si las cadenas del archivo tnsnames.ora son dobles (donde contienen hosts de base de datos autónomos locales y remotos), Oracle recomienda modificarlas para que apunten SOLO a la base de datos local.
    Esto puede suceder cuando utiliza Oracle Autonomous Database en una infraestructura dedicada. Solo tiene que realizar este cambio una vez, ya que la replicación de configuración y otras operaciones del ciclo de vida no alteran el archivo tnsnames.ora para la base de datos en espera.

    A continuación, se muestra un ejemplo en el que las entradas del archivo tnsnames.ora son dobles: 

    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. Si tiene entradas dobles, modifíquelas para que solo apunten a la instancia local de Autonomous Database eliminando la DIRECCIÓN de la base de datos remota.

    El archivo tnsnames.ora en el secundario solo debe incluir la DIRECCIÓN de la base de datos en espera. Por ejemplo: 

    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)))
…

Modificación de las cadenas de conexión de alias TNS del secundario para el enfoque de clonación de refrescamiento remoto

Para el enfoque Clonación de refrescamiento remoto, modifique el alias utilizado en el sistema secundario para que sea el mismo alias que en el sistema principal.

El archivo tnsnames.ora incluido en la creación secundaria del sistema Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace u Oracle Fusion Middleware contendrá un alias basado en el nombre de clonación de refrescamiento remoto. Por ejemplo, si se crea una clonación de refrescamiento remoto con el nombre soaadb1rc2, el archivo tnsnames.ora (en el directorio de cartera creado durante el aprovisionamiento) contendrá el siguiente alias: soaadb1rc2_high, soaadb1rc2_low, soaadb1rc2_medium, soaadb1rc2_tp, soaadb1rc2_tpurgent. Para simplificar la configuración, debe utilizar el mismo nombre de alias en el archivo tnsnames.ora tanto en el sistema principal como en el secundario, de modo que modifique el alias TNS con el que está configurado el dominio de Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace u Oracle Fusion Middleware (clonación de refrescamiento remoto) para utilizar el mismo nombre de alias que el principal. Puede obtener el nombre de alias en la base de datos primaria del archivo $tns_admin/tsnames.ora. Se crean diferentes alias para distintos servicios y todos inferirán un prefijo a partir del nombre de la base de datos. Tenga en cuenta que desea modificar sólo el nombre de alias, no los servicios. No utilice una búsqueda global y sustitúyala en el archivo, ya que probablemente también alterará los nombres de servicio en las cadenas de conexión del archivo tnsnames.ora.

  • Modifique el archivo tnsnames.ora del sistema secundario para utilizar el mismo alias que el sistema principal.

    A continuación se muestra un archivo tnsnames.ora de ejemplo para una configuración de Oracle Fusion Middleware con Oracle Autonomous Database Serverless en el 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)))

    A continuación se muestra un archivo tnsnames.ora de ejemplo para una configuración de Oracle Fusion Middleware con Oracle Autonomous Database Serverless en la secundaria con clonación de refrescamiento. 

    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)))

    Como se trata de una operación única, la forma más sencilla de cambiar el alias para la clonación de refrescamiento es editar el archivo. Puede modificar el alias para el nivel de servicio en uso o para que todos ellos sean coherentes.

    Nota:

    Esto se debe realizar cada vez que se utiliza una nueva clonación de refrescamiento para pruebas o validaciones y se utiliza una nueva cartera.

    A continuación se muestra un archivo tnsnames.ora de ejemplo para una configuración de Oracle Fusion Middleware con Oracle Autonomous Database Serverless en la secundaria con clonación de refrescamiento mediante el alias de la principal. 

    [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)))

Al igual que en el sistema principal, todos los archivos de origen de datos de $DOMAIN_HOME/config/jdbc y en los archivos de configuración de jps de $DOMAIN_HOME/config/fmwconfig utilizan el alias seleccionado. Se espera que se haya elegido el mismo nivel de servicio con la clonación de refrescamiento remoto que en el sistema principal (low, mid, high, tp o tpurgent). Debido a que el alias y los orígenes de datos se copian desde el sistema principal, no es necesario ejecutar el script fmw_change_to_tns_alias.sh en el sistema secundario. La configuración de recuperación ante desastres gestionará los reemplazos necesarios.

Si tiene alias adicionales para apuntar a otras bases de datos en el archivo tnsnames.ora principal, agréguelos en consecuencia en el archivo tnsnames.ora del sistema secundario.

Actualización de alias de nombre de host y dirección front-end en los niveles medio principal y en espera

La configuración del dominio WebLogic en el secundario será una copia del dominio WebLogic principal una vez finalizada la configuración de DR. Por lo tanto, los nombres de host utilizados como direcciones de recepción por los servidores de Oracle WebLogic principales (que son los nombres de host de los hosts principales) deben ser válidos en la ubicación secundaria, pero asignarse a las IP secundarias.

Se debe utilizar la misma dirección de front-end tanto en la principal como en la base de datos en espera. Durante el funcionamiento normal, este nombre de host de front-end se asignará a la IP del equilibrador de carga de Oracle Cloud Infrastructure (OCI) principal. Cuando se ejecuta desde una instancia secundaria (después de un switchover o failover), este nombre de host de front-end se asignará a la IP del equilibrador de carga de OCI secundario.

Nota:

El archivo /etc/hosts de los hosts de nivel medio no se debe modificar cuando hay una operación de switchover o failover. Los hosts de nivel medio siempre resolverán el nombre de front-end virtual con su IP de front-end. La actualización de DNS necesaria durante los procedimientos de switchover y failover se realiza en los archivos de host o DNS utilizados por los clientes.

Puede implementar este alias de host de las siguientes maneras:

  • Agregue los nombres de host como alias a los archivos /etc/hosts de las instancias informáticas de Oracle WebLogic Server para OCI
  • Utilizar una vista de DNS privada en la VCN de OCI secundaria

Uso de archivos /etc/hosts

Los nombres de host utilizados por Oracle WebLogic Server principal se agregan a los archivos /etc/hosts de los hosts secundarios de Oracle WebLogic Server, apuntando a las direcciones IP de los hosts secundarios de Oracle WebLogic Server. Este modo es válido cuando el servidor DNS es el mismo en sitios de Oracle Cloud Infrastructure (OCI) principales y secundarios, y también cuando se utilizan servidores DNS separados en los sitios principal y secundario. Las entradas del archivo /etc/hosts tienen prioridad sobre la resolución de DNS, porque esta es la prioridad definida lista para usar en la directiva "hosts" del archivo /etc/nsswitch.conf.
  1. Edite el archivo /etc/oci-hostname.conf de cada instancia informática del servidor WebLogic y defina la propiedad PRESERVE_HOSTINFO=3 para conservar las entradas /etc/hosts en los reinicios de la instancia.
  2. Utilice el comando hostname --fqdn para identificar los nombres de host completos de las instancias informáticas del servidor WebLogic de OCI.
  3. Agregue las siguientes entradas al archivo /etc/hosts de las instancias informáticas de nivel medio:
    #################################
# 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
    A continuación se muestra un ejemplo del archivo /etc/hosts de los hosts Oracle WebLogic Server principales:
    # 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

    A continuación, se muestra un ejemplo del archivo /etc/hosts en la instancia informática WebLogic Server de OCI secundario.

    Nota:

    Los nombres de host principales se agregan como alias de los nodos secundarios y ese nombre virtual de front-end apunta a la IP del equilibrador de carga secundario:

    # 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

Uso del sistema de nombres de dominio (DNS) de OCI

Los nombres de host utilizados por los hosts de Oracle WebLogic Server principales se agregan al solucionador de DNS utilizado por la VCN de los servidores de nivel medio secundarios, apuntando a las direcciones IP de los hosts de Oracle WebLogic Server secundarios. Este modo es válido cuando se utilizan servidores DNS independientes en sitios de Oracle Cloud Infrastructure (OCI) principales y secundarios. De lo contrario, puede provocar conflictos en la resolución de nombres. El servidor de cada sitio debe resolver estos nombres con sus propias IP. La ventaja de este método es que puede agregar todas las entradas a una vista de DNS privada, en lugar de agregarlas a todos los /etc/hosts de todos los hosts de Oracle WebLogic Server.

A continuación, se muestran los pasos para crear la vista privada en la VCN secundaria y resolver los nombres de host que utiliza la principal con las IP secundarias:

  1. En la consola de OCI, vaya a la región secundaria y cree la vista privada para resolver los nombres de los hosts PRIMARY CON las direcciones IP SECUNDARIAS.
    1. Haga clic en Redes, Gestión de DNS, Vistas privadas y, a continuación, en Crear vista privada.
      Por ejemplo, puede asignar un nombre a la vista privada: PRIMARY_HOSTNAMES_PRIVATE_VIEW
    2. Haga clic en Crear zona en la vista privada.
      Para el nombre de zona, debe utilizar el dominio completo de los hosts. Por ejemplo: subnetpri.vcnpri.oraclevcn.com
    3. Agregue los nombres de host principales a esta zona (nombre abreviado), pero se resuelve con la dirección IP de los hosts secundarios de Oracle WebLogic Server.
    4. Haga clic en Publicar cambios.
  2. Agregue la vista privada al solucionador de VCN secundario.
    1. Haga clic en el recurso de solucionador de DNS en la VCN.
    2. Agregue la vista privada de DNS creada anteriormente.
      Los hosts de la VCN secundaria resolverán los nombres de host utilizados por los hosts de Oracle WebLogic Server principales mediante la vista privada.
  3. Valide los hosts SECONDARY de resolución mediante ping y nslookup de los nombres de host.
    Se deben resolver con las IP SECONDARY equivalentes.

    Nota:

    Puede encontrar el código de Terraform para crear esta vista y registros privados de OCI en GitHub.

Configuración del sistema secundario

Para configurar el sistema como secundario, debe copiar la configuración de dominio WebLogic Server del dominio del sistema principal al secundario WebLogic Server, Oracle SOA Suite u Oracle Fusion Middleware.
La configuración de recuperación ante desastres (DR) reemplaza todo el dominio secundario, excepto directorios y archivos específicos que deben permanecer localmente válidos. Estos directorios están explícitamente excluidos por las secuencias de comandos. Además, el script sustituye los archivos de origen de datos para que el secundario utilice los mismos nombres de esquema de base de datos que en el primario, pero con el jdbc url existente que apunta a la base de datos local (clonación de refrescamiento durante la configuración de DR y en espera como preparación para el switchover) con las carteras necesarias.
  1. Ejecute el script fmwadb_dr_prim.sh en el nodo de administración del servidor WebLogic principal.
    El script comprobará la conectividad entre los nodos del servidor de administración del WebLogic Server a través del gateway de direccionamiento dinámico y copiará el dominio en el directorio temporal en un montaje de Oracle Cloud Infrastructure File Storage en la región secundaria.

    Utilice los siguientes parámetros:

    • REMOTE_ADMIN_NODE_IP

      La dirección IP del nodo de servidor de administración de WebLogic Server secundario.

      Se debe poder acceder a esta IP desde este HOST (nodo principal del servidor de administración de Oracle WebLogic Server).

      Se recomienda utilizar el gateway de direccionamiento dinámico para interconectar los sitios principales y secundarios, lo que le permite proporcionar la dirección IP privada.

    • REMOTE_SSH_PRIV_KEYFILE

      Archivo de claves ssh privado para conectarse al nodo del servidor de administración de Oracle WebLogic remoto.

    • FSS_MOUNT

      Directorio montado de OCI File Storage que se utiliza para almacenar temporalmente la copia de la configuración de dominio del servidor WebLogic. 

    ./fmwadb_dr_prim.sh [REMOTE_ADMIN_NODE_IP] [REMOTE_SSH_PRIV_KEYFILE] [FSS_MOUNT]
    El siguiente es un ejemplo del comando y la salida:
    [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. Cuando la secuencia de comandos fmwadb_dr_prim.sh termine de ejecutarse, si aún no se ha parado, detenga todos los sistemas WebLogic Server y los gestores de nodos del sistema secundario.
  3. Inicie sesión en el nodo de administración WebLogic Server del secundario y ejecute la secuencia de comandos fmwadb_dr_stby.sh.

    El script copia el dominio WebLogic Server del directorio temporal en un montaje de OCI File Storage en el directorio secundario del dominio WebLogic Server y sustituye las entradas de cartera y contraseña necesarias. La cartera que se va a proporcionar es la clonación de refrescamiento para que la secundaria se pueda validar después de la configuración de DR inicial.

    Utilice los siguientes parámetros:

    • WALLET_DIR

      Directorio para una cartera de Oracle Autonomous Database descomprimida. Nodo del servidor de administración WebLogic Server.

      Este directorio debe contener al menos archivos tnsnames.ora, keystore.jks y truststore.jks.

      Si está utilizando el enfoque de instantánea en espera, esta es solo la carpeta tnsadmin.

    • WALLET_PASSWORD

      Contraseña proporcionada al descargar la cartera de la interfaz de usuario de OCI de Oracle Autonomous Database Serverless.

      Si la cartera es la inicial creada por el sistema WebLogic Server, Oracle SOA Suite u Oracle Fusion Middleware al aprovisionar. Puede obtenerlo con el siguiente comando:

      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

      Directorio montado de OCI File Storage que se utiliza para almacenar temporalmente la configuración de dominio del servidor WebLogic. 

    ./fmwadb_dr_stby.sh [WALLET_DIR] [WALLET_PASSWORD] [FSS_MOUNT]
    El siguiente es un ejemplo de la ejecución y la salida 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. Ejecute el script fmwadb_dr_stby.sh en los otros nodos de servidor gestionado WebLogic Server de la región secundaria.
  5. Asegúrese de que se puede acceder a la base de datos en espera en modo de lectura-escritura.
    • Si está utilizando el enfoque de instantánea en espera, asegúrese de que la base de datos en espera se convierta en la base de datos de instantánea en espera, de modo que se pueda acceder a ella en modo de lectura-escritura.
    • Si utiliza el enfoque de clonación de refrescamiento remoto, asegúrese de que esté desconectado del origen, de modo que se pueda acceder a él en modo de lectura-escritura.
  6. Inicie el gestor de nodos y el servidor de administración de Oracle WebLogic Administration Server en segundo plano. Acceda a la consola e inicie los servidores gestionados del servidor WebLogic en el dominio.
  7. Valide que las aplicaciones y despliegues existentes en la base de datos primaria también están disponibles en la secundaria.
  8. Cierre los WebLogic Server en el secundario.
  9. Convierta la base de datos en espera en una base de datos física en espera o vuelva a conectar la clonación de refrescamiento.

    • Si utiliza el enfoque de instantánea en espera, conviértala en la base de datos física en espera.

    • Si utiliza la clonación de refrescamiento remoto, vuelva a conectar la clonación de refrescamiento. Recordatorio: la clonación de refrescamiento no puede permanecer desconectada de la principal durante más de 24 horas.

Deje el sistema listo para el switchover

Una vez configurado y validado el sistema secundario con una clonación de refrescamiento, deje el sistema listo para el switchover apuntando el alias TNS a Oracle Autonomous Database Serverless en espera.

Nota:

Esta tarea sólo es necesaria cuando el sistema secundario está configurado y validado con una clonación de refrescamiento remoto.

Descargue la cartera de la base de datos en espera desde la interfaz de usuario de la base de datos secundaria. Evite las cadenas de conexión dual (tanto hosts principales como en espera) en los casos de DR remotos porque provocan reintentos innecesarios.

  1. Conéctese a la interfaz de usuario de Oracle Autonomous Database Serverless para la base de datos en espera.
  2. Haga clic en Autonomous Database, seleccione autonomous_db_name, haga clic en Conexión de base de datos y, a continuación, haga clic en Descargar cartera.
  3. Si la cartera contiene cadenas dobles que apuntan a la base de datos primaria, elimine la entrada de la descripción principal del archivo tnsnames.ora para que la cadena de conexión apunte SOLO a la base de datos local en la región secundaria.

    A continuación, se muestra un ejemplo de modificación del archivo 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. Copie la cartera en una carpeta temporal del nodo del servidor de administración WebLogic Server de la región secundaria y navegue al directorio.
    [oracle@wsladbs2-wls-0 scripts]$ cd /tmp
[oracle@wsladbs2-wls-0 tmp]$ mkdir wallet-stby
[oracle@wsladbs2-wls-0 tmp]$ cd wallet-stby/
  5. Descomprima la cartera.
    [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. Ejecute el script fmwadb_switch_db_conn.sh para dejar el nivel medio listo con la cartera secundaria y la cadena de conexión.

    A continuación se muestra un ejemplo de la ejecución del script para apuntar a la cartera de Oracle Autonomous Database Serverless en espera: 

    [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!

Configuración de replicación de configuración continua

Cuando el ciclo de vida del sistema implica actualizaciones de frecuencias en el sistema de archivos de dominio, puede utilizar una secuencia de comandos para automatizar el proceso de replicación de configuración. El script fmwadb_config_replica.sh replica los cambios a través del directorio temporal de Oracle Cloud Infrastructure File Storage (OCI File Storage) de forma regular.

La configuración está lista (preparada) para un switchover después de cada replicación.

Al utilizar la clonación de refrescamiento remoto, se asume que la configuración replicada se "adaptará" para la base de datos física en espera (no para la clonación de refrescamiento). Si necesita una validación o prueba con clones de refrescamiento, puede modificar la configuración del dominio en espera para que apunte a la clonación de refrescamiento.

Debe ejecutar la secuencia de comandos fmwadb_config_replica.sh en los nodos de administración del servidor WebLogic (en la base de datos primaria y en espera) para replicar la configuración. Normalmente, este script se programa con un trabajo cron para replicar la configuración entre un sistema WebLogic Server principal y un sistema en espera, Oracle SOA Suite u Oracle Fusion Middleware en el sistema Oracle Autonomous Database a intervalos regulares. Este script comprueba el rol actual de la base de datos local para determinar si se está ejecutando en la ubicación primaria o en espera.

  • Cuando el script se ejecuta en el sitio PRIMARY, copia la configuración del dominio desde el dominio principal a la carpeta de asistencia local (FSS) y, a continuación, a la carpeta de asistencia del sitio secundario (mediante rsync).
  • Cuando el script se ejecuta en el sitio STANDBY, copia la configuración de dominio de la carpeta de asistencia secundaria (OCI File Storage) en el dominio secundario y realiza las sustituciones necesarias para que los orígenes de datos funcionen con la base de datos local.

Debe recopilar diferentes parámetros de la consola de OCI y cifrar la contraseña para acceder a las carteras de Oracle Autonomous Database por motivos de seguridad.

A continuación, se muestra una descripción de las variables utilizadas en el script y cómo obtenerlas:

  • REMOTE_WLSADMIN_NODE_IP

    IP del nodo del servidor de administración WebLogic Server peer y remoto.

    Esta es la IP del host de nodo en el servidor de administración del servidor WebLogic en el sitio del igual. Debe ser accesible desde el nodo local. Se recomienda conectarse a la IP privada remota del nodo mediante un gateway de direccionamiento dinámico.

  • REMOTE_SSH_PRIV_KEYFILE

    Archivo de claves SSH privado para conectarse al nodo del servidor de administración de Oracle WebLogic remoto.

  • TENANCY_OCID

    OCID del arrendamiento donde reside Oracle Autonomous Database. Puede obtener el OCID de la interfaz de usuario (IU) de Oracle Cloud Infrastructure (OCI).

  • USER_OCID

    El OCID del usuario propietario de la instancia de base de datos autónoma. Puede encontrar el OCID en la interfaz de usuario de OCI.

  • PRIVATE_KEY

    Ruta de acceso a la clave de formato PEM privada para este usuario.

  • LOCAL_ADB_OCID

    OCID de la Oracle Autonomous Database que se está inspeccionando. Puede encontrar el OCID en la pantalla Oracle Autonomous Database de la consola de OCI.

  • WALLET_DIR

    Directorio de la cartera local de Oracle Autonomous Database (descomprima la cartera descargada de la consola de OCI). Este directorio debe contener al menos los archivos tnsnames.ora, keystore.jks y truststore.jks. Al utilizar el enfoque de instantánea en espera, esta es la carpeta tnsadmin

  • ENC_WALLET_PASSWORD

    Encarnación WLS ENCRYPTED de la contraseña proporcionada al descargar la cartera desde la interfaz de usuario de OCI de Oracle Autonomous Database.

    Si la cartera es la inicial creada por WebLogic Server, Oracle SOA Suite u Oracle Fusion Middleware durante el aprovisionamiento de WebLogic Server, puede utilizar los siguientes comandos para obtener la contraseña:

    Para WebLogic:
    [oracle@wsladbs2-wls-1 ~]$ python3 /opt/scripts/atp_db_util.py generate-atp-wallet-password
    Para SOA:
    [oracle@soarefr-soa-0 ~]$ python /opt/scripts/atp_db_util.py generate-atp-wallet-password
    Para cifrar la contraseña, tanto si la proporcionada en la consola de OCI como la utilizada durante el aprovisionamiento, puede utilizar el script fmw_enc_pwd.sh.
    ./fmw_enc_pwd.sh UNENC_WALLET_PASSWORD

    Utilice la cadena obtenida para la variable ENC_WALLET_PASSWORD.

  • FSS_MOUNT

    Directorio montado de OCI File Storage que se utilizará para almacenar temporalmente la configuración de dominio del servidor WebLogic.

Una vez que haya recopilado la información de las variables, realice los siguientes pasos para copiar y personalizar los scripts de su entorno:

  1. Cifre la contraseña para acceder a las carteras de Oracle Autonomous Database por motivos de seguridad.
  2. Copie el script en el sitio principal y, a continuación, edite el script completando las variables necesarias para el sitio principal.
    Consulte la descripción anterior de las variables utilizadas en el script.
  3. Copie el script en la ubicación en espera y, a continuación, edite el script rellenando las variables necesarias para la ubicación en espera.
    Consulte la descripción anterior de las variables utilizadas en el script.
  4. Una vez personalizada para cada región (debe proporcionar el OCID de la base de datos LOCAL para cada región), realice las siguientes tareas:
    1. Ejecute el script en el host de administración de Oracle WebLogic en la base de datos primaria.
    2. Ejecute el script en el host de administración de Oracle WebLogic en la región secundaria.
  5. Agregue el script a un trabajo cron en cada región.