Tareas de ciclo de vida

Se necesita un mantenimiento regular del ciclo de vida para mantener el sitio secundario sincronizado con el sitio principal. Durante el ciclo de vida, podrá realizar un switchover planificado para cambiar los roles de los sitios principales y secundarios, y responder a operaciones inesperadas o no planificadas.

Acerca de la replicación de configuración

Durante la configuración de DR se realizó una replicación inicial del contenido que reside en los sistemas de archivos. Debe repetir la replicación del sistema de archivos de forma regular para mantener actualizada el sitio secundario con el sitio principal.

Puede utilizar los mismos scripts que creó durante la configuración de DR, Replicar los artefactos del sistema de archivos en OCI y programar la réplica de los sistemas de archivos con las siguientes consideraciones para cada artefacto:

Replicación de los directorios raíz de Oracle durante el ciclo de vida
Este es un artefacto estático. No cambia con frecuencia, por lo que no es necesario replicarlo con regularidad. Sólo cuando realice una modificación en el directorio raíz de Oracle (como la actividad de aplicación de parches), tendrá que replicarla.
Replicación de la configuración compartida del dominio WebLogic durante el ciclo de vida
Este es un artefacto dinámico. Entre otras cosas, contiene ASERVER_HOME, que es el origen de la autenticación de la configuración de dominio de SOA, y APPLICATION_HOME, que se actualiza cada vez que se despliega una aplicación, se anula su despliegue, se actualiza, etc.

Se espera que esta configuración compartida del dominio WebLogic cambie con frecuencia. Programe una réplica normal de este artefacto, que debe ser más o menos frecuente en función de la frecuencia con la que se produzcan cambios de configuración en el sistema. Otro enfoque controlado es realizar una réplica cada vez que realice un cambio de configuración en la base de datos principal.
Replicación de la configuración privada del dominio WebLogic durante el ciclo de vida
También es un artefacto dinámico, contiene MSERVER_HOME y NM_HOME. No se espera que tenga actualizaciones frecuentes en el directorio raíz nodemanager después de la configuración inicial. El contenido de MSERVER_HOME cambiará con la frecuencia que ASERVER_HOME, ya que contiene la carpeta de dominio utilizada por los servidores gestionados. Sin embargo, la mayor parte de su contenido (ASERVER_HOME/config) se refresca y descarga desde AdminServer cuando se inician los servidores gestionados y cuando se aplican cambios de configuración mediante la herramienta de script WebLogic (WLST) o la consola de administración de Oracle WebLogic Server. No es tan crítico replicar este artefacto con la frecuencia que la configuración compartida. Es obligatorio replicar esto solo cuando se realizan modificaciones en otras carpetas de MSERVER_HOME (por ejemplo, una modificación en la carpeta MSERVER_HOME/bin).
Replicación de la carpeta de tiempo de ejecución compartido
Si almacena cualquier artefacto de tiempo de ejecución en esta carpeta, programe la réplica en espera según las necesidades de su negocio.

En lugar de utilizar el sistema de archivos de Oracle Cloud Infrastructure File Storage y replicar con rsync, puede utilizar un montaje de Oracle Database File System (DBFS) para el contenido de tiempo de ejecución compartido. De esta forma, el contenido reside en la base de datos y se replica automáticamente en la secundaria con la réplica subyacente de Oracle Data Guard. Consulte Acerca de Oracle Database File System en Más información para obtener más información sobre el uso de DBFS.

La siguiente tabla es un resumen de las recomendaciones para la replicación de artefactos del sistema de archivos durante el ciclo de vida.

Artefacto	Contiene	Recomendación
Directorios Raíz de Oracle	Directorio raíz de FMW, JDK, inventario	Replicar solo bajo demanda (por ejemplo, después de la aplicación de parches)
Configuración compartida de dominio WebLogic	`ASERVER_HOME`, aplicaciones, planes de despliegue, almacenes de claves	Programar replicación, puede que sea necesaria una alta frecuencia. La frecuencia depende de la frecuencia con la que se realicen los cambios de configuración en el sistema SOA.
Configuración privada de dominio WebLogic	`MSERVER_HOMES`, `nodemanager config`	Programar replicación. Normalmente, no se requiere alta frecuencia.
Tiempo de ejecución compartido	Artefactos de tiempo de ejecución específicos del cliente (no JMS, no TLOGS)	Determinado por sus requisitos. Si se trata de un montaje de DBFS, Oracle Data Guard replica automáticamente el contenido.

Realización de un switchover

Un switchover es una operación planificada en la que un administrador revierte los roles de los dos sitios. Después de un switchover, el sistema principal pasa a ser secundario y el sistema secundario pasa a ser principal. Si se realiza un switchover, se producirá un tiempo de inactividad en la ubicación principal.

Antes de realizar un switchover en una configuración de DR híbrida de SOA, propague los cambios de configuración pendientes. Asegúrese de que no haya cambios replicados en el sitio secundario pendientes.

Desactive cualquier replicación programada mientras se realiza el switchover, ya que puede fallar e interferir con la propia operación de switchover.
Pare los sistemas Oracle HTTP Server en la ubicación principal.
Pare los servidores de la ubicación principal.
Utilice la consola o los scripts del servidor de administración WebLogic para parar los servidores WebLogic en la ubicación principal.

Nota:
El servidor de administración del sitio principal puede permanecer activo durante el switchover. Sin embargo, se recomienda detenerlo cuando el sitio tenga un rol en espera porque se espera que la configuración de dominio en el sitio en espera se sustituya por la configuración principal durante el ciclo de vida. Si el servidor de administración está activo mientras esto ocurre, se ejecutará con una configuración obsoleta.
Switchover del nombre de DNS de front-end.

Realice la transferencia de DNS necesaria en el servidor DNS que aloja los nombres utilizados por el sistema o modifique la resolución del host de archivos en los clientes para que apunte el nombre virtual front-end del sistema a la IP pública utilizada por el equilibrador de carga en el sitio secundario.

En los escenarios en los que se utiliza DNS para la resolución de front-end externa (como OCI DNS o DNS comercial), puede utilizar una API para impulsar el cambio. Para ver un ejemplo que transfiera este cambio en un DNS de OCI, vaya a GitHub, por ejemplo, scripts.

Tenga en cuenta que el valor TTL de la entrada DNS afectará al RTO del switchover: si el TTL es alto (ejemplo, 20 minutos), el cambio de DNS tardará ese tiempo en ser efectivo en los clientes. El uso de valores TTL más bajos hará que esto sea más rápido; sin embargo, esto puede causar una sobrecarga porque los clientes golpearán el DNS con más frecuencia en lugar de utilizar nombres almacenados en caché. Un buen enfoque es definir la TTL en un valor bajo temporalmente (por ejemplo, 1 min), antes del cambio en el DNS. A continuación, realice el cambio y, una vez finalizado el procedimiento de switchover, vuelva a revertir la TTL a su valor original.
Como usuario oracle, utilice Oracle Data Guard Broker en el host de la base de datos primaria para realizar el switchover de la base de datos.
Necesitará la contraseña del sistema y el nombre único de la base de datos primaria.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
Si aún no están activos, inicie los sistemas Oracle HTTP Server en el sitio secundario (nuevo principal).
Inicie el servidor de administración en el sitio secundario (nuevo principal) o reinicie el servidor si ya se ha iniciado.
Al iniciar el servidor de administración, se activan los cambios de configuración que se replicaron mientras se trataba de una base de datos en espera en vigor.
Inicie los servidores gestionados secundarios en el sitio secundario (nuevo principal).
Utilice la consola o los scripts WebLogic para iniciar los servidores gestionados secundarios.

Realización de un failover

Una operación de failover suele ser una operación no planificada que se realiza cuando el sitio principal deja de estar disponible. Puede realizar la transición de roles de una base de datos en espera a un rol de base de datos primaria cuando la base de datos primaria original falle y no haya posibilidad de recuperarla en un tiempo. Puede que se pierdan datos, en función de si las bases de datos primaria y de destino en espera eran consistentes en el momento del fallo de la base de datos primaria.

Propague los cambios de configuración pendientes, si es posible.
Consulte Replicar los artefactos del sistema de archivos en OCI para replicar los cambios en el sitio secundario.
Desactive cualquier replicación programada mientras se realiza el switchover, ya que puede fallar e interferir con la propia operación de switchover.
Pare los sistemas Oracle HTTP Server en la ubicación principal.
Detenga los servidores gestionados en el sitio principal, si es posible.

Utilice la consola o los scripts del servidor de administración WebLogic para parar los servidores gestionados en el servidor principal.
Cambie el nombre de DNS del front-end.

Realice la transferencia de DNS necesaria en el servidor DNS que aloja los nombres utilizados por el sistema o modifique la resolución del host de archivos en los clientes para que apunte el nombre virtual front-end del sistema a la IP pública utilizada por el equilibrador de carga en el sitio secundario.

Para los escenarios en los que se utiliza DNS para la resolución de front-end externa (DNS de OCI, DNS comercial, etc.), utilice la API adecuada para impulsar el cambio. Para ver un ejemplo que impulsa este cambio en un DNS de OCI, vaya aquí.

Nota:
el valor TTL de la entrada DNS afectará al RTO del switchover. Si el TTL es alto (por ejemplo, 20 minutos), el cambio de DNS tardará ese tiempo en ser efectivo en los clientes. El uso de valores TTL más bajos hará esto más rápido; sin embargo, esto puede causar una sobrecarga porque los clientes golpearán el DNS con más frecuencia en lugar de utilizar nombres almacenados en caché. Un buen enfoque es definir la TTL en un valor bajo temporalmente (por ejemplo, 1 min), antes del cambio en el DNS. A continuación, realice el cambio y, una vez finalizado el procedimiento de switchover, revierta la TTL a su valor original.
Como usuario oracle, utilice el broker de Oracle Data Guard en el host de la base de datos secundaria para realizar el failover.
Necesitará la contraseña del sistema y el nombre único de la base de datos primaria.
```
[oracle@hydrdb1 ~]$ dgmgrl sys/your_sys_password@secondary_db_unqname
DGMGRL> failover to secondary_db_unqname
```
Si aún no están activos, inicie los sistemas Oracle HTTP Server en el sitio secundario (nuevo principal).
Inicie el servidor de administración en el sitio secundario (nuevo principal) o reinicie el servidor si ya se ha iniciado.
Al iniciar el servidor de administración, se activan los cambios de configuración que se replicaron mientras se trataba de una base de datos en espera en vigor.
Inicie los servidores gestionados secundarios en el sitio secundario (nuevo principal).
Utilice la consola o los scripts WebLogic para iniciar los servidores gestionados secundarios.

Abrir secundario para validación

Puede validar la ubicación en espera sin realizar un switchover completo convirtiendo la base de datos en espera en una base de datos de instantánea en espera. Esto permite iniciar los servidores SOA secundarios en el sitio en espera y verificar el sistema secundario. Cualquier cambio realizado en la base de datos de ubicación en espera mientras está en modo de instantánea en espera se desechará una vez que se vuelva a convertir en física en espera. Los datos principales no se ven afectados por las validaciones de sitios secundarios.

Nota:

Esta operación se debe realizar con precaución: si hay mensajes pendientes o compuestos en la base de datos cuando se convierte en instantánea, los servidores SOA de la ubicación en espera los procesarán cuando se inicien. Compruebe que no hay acciones pendientes en la base de datos primaria al convertir a la instantánea en espera. De lo contrario, elimine los registros de las tablas SOA de tiempo de ejecución en la base de datos en espera después de convertirlas en base de datos de instantánea en espera y antes de iniciar los servidores SOA de la ubicación secundaria. Consulte Eliminación de Registros de las Tablas de Tiempo de Ejecución sin Borrar las Tablas para conocer los pasos para validar la ubicación en espera sin realizar un switchover.

Como usuario oracle, utilice Oracle Data Guard Broker en el host de base de datos principal y convierta el secundario en una instantánea en espera.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
Utilice el comando show configuration para verificar que la conversión se ha realizado correctamente.
Verifique que no haya acciones pendientes en el entorno secundario.
Si hay acciones pendientes (transacciones, mensajes) en la base de datos primaria cuando la base de datos en espera se convierte en instantánea, los servidores SOA secundarios intentarán procesarlas cuando start.You pueda utilizar el script de truncamiento de SOA para eliminar los registros de las tablas de tiempo de ejecución de SOA en la base de datos secundaria para limpiar los datos de tiempo de ejecución antes de iniciar los servidores secundarios. Ejecute esta acción con precaución; no trunque las tablas en la base de datos primaria. Consulte Eliminación de registros de las tablas de tiempo de ejecución sin borrar las tablas.
Si aún no están activos, inicie los sistemas Oracle HTTP Server en el sitio secundario.
Inicie el servidor de administración en el sitio secundario.
Inicie los servidores gestionados secundarios en el sitio secundario.
Utilice la consola o los scripts WebLogic para iniciar los servidores gestionados secundarios.
Valide el sitio secundario.

Como no se trata de un switchover y la ubicación principal aún está activa, el nombre de front-end virtual se resolverá en la dirección IP del equilibrador de carga de la ubicación principal, por lo que, por defecto, cualquier acceso al explorador se redirigirá a la ubicación principal activa.

Para acceder directamente a los servicios SOA del sitio secundario, debe actualizar el archivo /etc/hosts en un cliente controlado (por ejemplo, un equipo portátil), definir el nombre de front-end virtual para que se resuelva en la dirección IP del equilibrador de carga front-end del sitio secundario y ejecutar cualquier validación desde este cliente.

Nota:
Verifique que el cliente utilizado para las validaciones no acceda al sistema a través de un proxy HTTP, porque el proxy HTTP puede seguir resolviendo el nombre de front-end virtual con la dirección IP del equilibrador de carga del sitio principal, independientemente del nombre que se encuentre en /etc/hosts del cliente.

Es posible que los clientes que no son Linux requieran un restablecimiento de su caché DNS local antes de que un explorador resuelva la dirección IP mediante la entrada de archivo de host personalizado.

Una vez que se haya validado el sitio secundario, vaya al paso siguiente para revertirlo al rol en espera.

Nota:
Puede tardar tiempo en validar el sitio secundario.
Pare los servidores gestionados y los servidores de administración en el sitio secundario.
Utilice la consola WebLogic secundaria para cerrar los servidores gestionados y el servidor de administración en el sitio secundario.
Como usuario oracle, utilice Oracle Data Guard Broker en el host de la base de datos primary y vuelva a convertir el secundario en una base de datos física en espera.
Necesitará la contraseña del sistema y el nombre único de la base de datos primaria.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
Utilice show configuration para verificar la conversión.
Revierta los archivos /etc/hosts actualizados.
Si ha actualizado cualquier archivo /etc/hosts en un cliente para que apunte al sitio secundario para las validaciones, vuelva a revertir para que el nombre de front-end virtual apunte de nuevo a la dirección IP de front-end principal.

Nota:

ORA-01403: no se han encontrado datos con errores ORA-06512

Al validar la ubicación secundaria como se describe aquí (sin realizar una operación de switchover completa, es decir, simplemente abrir la base de datos en espera en modo de instantánea en espera) "ORA-01403: no se han encontrado datos ORA-06512" pueden aparecer errores en los logs de los servidores SOA en espera. Estos errores están relacionados con el trabajo de depuración automática de SOA. Estos errores surgen porque los trabajos de la base de datos pueden tener dependencias de roles de base de datos (se definen para activarse solo cuando la base de datos tiene el rol principal). Se trata de un comportamiento esperado y deseado que evita que los trabajos se ejecuten dos veces (una vez en la base de datos primaria y otra en la base de datos en espera). El trabajo de depuración automática de SOA se define con el rol principal, por lo que no se muestra en la vista DBA_SCHEDULER_JOBS cuando la base de datos está en modo de instantánea en espera. La opción database_role definida para cada trabajo se puede ver en la vista DBA_SCHEDULER_JOB_ROLE. En resumen, estos errores se pueden ignorar siempre que aparezcan en el sistema en espera. El trabajo del programador para la depuración automática de SOA se ejecutará en la base de datos si la instancia cambia su rol a PRIMARY y solo si lo hace.

Failover local del servidor de administración en OCI

Puede iniciar el servidor de administración en un nodo diferente del mismo sitio si hay un fallo en el host en el que se estaba ejecutando originalmente el servidor de administración. No es necesario realizar un switchover completo del sistema al otro sitio.

Nota:

Esta tarea de ciclo de vida solo se aplica cuando los servidores de administración WebLogic utilizan una VIP para fines de alta disponibilidad local y la carpeta de configuración del servidor de administración (ASERVER_HOME) está en una ubicación compartida.

El procedimiento para hacerlo se explica en Verifying Manual Failover of the Administration Server. Esto proporciona protección de failover local para el servidor de administración. Tenga en cuenta que esto no es necesario para los servidores gestionados, que tienen protección de alta disponibilidad local basada en la función de migración automática de servicios.

Si necesita realizar un failover del servidor de administración a otro host cuando el principal se esté ejecutando en el sitio de OCI, puede seguir ese procedimiento. Sin embargo, se requiere una acción adicional relacionada con el paso "Migración de la dirección IP virtual de ADMINVHN al segundo host".

Realice los siguientes pasos para desasociar la VIP del host de SOA en el que se estaba ejecutando el servidor de administración y para asociarla al host de SOA al que se está moviendo la administración (desasocie la VIP de SOAHOST1 y asóciela a SOAHOST2 en el sitio de OCI):

Como usuario root, ejecute los siguientes comandos en SOAHOST1 para eliminar la VIP del servidor de administración de la interfaz de red.
1. Parar el servidor de administración en caso de que aún se esté ejecutando
2. Confirme dónde se está ejecutando la VIP.
```
ip addr show dev ens3
```
3. Elimine la IP de la interfaz de red.
```
ip addr del 100.70.8.120/20 dev ens3
```
Desconecte la VIP del servidor de administración de SOAHOST1.
1. Conéctese a la consola de OCI y seleccione la región y el compartimento adecuados.
2. Vaya a la instancia informática. Haga clic en Compute, Instances y, a continuación, en SOAHOST1.
3. Haga clic en VNIC asociadas y, a continuación, seleccione la VNIC en la que está conectada la VIP del servidor de administración.
4. Haga clic en Direcciones IPv4 y edite la VIP que utiliza el servidor de administración.
5. Guarde la dirección IP de la VIP y el nombre fqdn en una nota (por ejemplo: 100.70.8.120, hydrsoa-vip.midtiersubnet.hydrvcn.oraclevcn.com).
6. Haga clic en Suprimir IP privada.
Conecte la VIP del servidor de administración a SOAHOST2.
1. Vaya a la instancia informática. Haga clic en Compute, Instances y, a continuación, en SOAHOST2.
2. Haga clic en VNIC asociadas y, a continuación, seleccione la VNIC en la que está conectada la VIP del servidor de administración.
3. Haga clic en Asignar dirección IP privada secundaria.
4. Haga clic en Direcciones IPv4 y, a continuación, en Asignar dirección IP privada secundaria.
5. Introduzca los valores de dirección IP privada y nombre de host que se han utilizado anteriormente. Por ejemplo: 100.70.8.120 para la IP y hydrsoa-vip como nombre de host.
Inicie sesión en SOAHOST2 como usuario root y, a continuación, ejecute los siguientes comandos para conectar la VIP del servidor de administración a la interfaz de red.
1. Confirme dónde se está ejecutando la interfaz de red.
```
ip addr show dev ens3
```
2. Agregue la VIP del servidor de administración a la interfaz de red.
```
ip addr add 100.70.8.120/20 dev ens3 label ens3:1
```
Realice el resto de los pasos como se describe en Verifying Manual Failover of the Administration Server.