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

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

Puede utilizar los mismos scripts que ha creado durante la configuración de DR, Replicar los artefactos del sistema de archivos en OCI y programar la réplica de 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 WebLogic Server, 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 tener actualizaciones frecuentes en el directorio raíz nodemanager después de la configuración inicial. El contenido de MSERVER_HOME cambiará con la misma frecuencia que ASERVER_HOME, porque contiene la carpeta de dominio que utilizan 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 importante replicar este artefacto con la misma 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 compartida
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 WebLogic Server.
Configuración privada de dominio WebLogic	`MSERVER_HOMES`, `nodemanager config`	Programar replicación. Normalmente, no es necesaria una frecuencia alta.
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 WebLogic Server, 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 operación de switchover en sí.
Pare los sistemas Oracle HTTP Server en la ubicación principal.
Detenga los servidores en el sitio 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 de la ubicación primaria puede permanecer activo durante el switchover. Sin embargo, se recomienda pararlo cuando la ubicación esté en rol en espera porque se espera que la configuración principal sustituya la configuración de dominio de la ubicación en espera durante el ciclo de vida. Si el servidor de administración está activo mientras ocurre esto, 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 que utiliza el sistema o modifique la resolución de host de archivo en los clientes para que el nombre virtual de front-end del sistema apunte a la IP pública que utiliza 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 de TTL de la entrada de DNS afectará al RTO del switchover: si el TTL es alto (por ejemplo, 20 min), el cambio de DNS tardará ese tiempo en ser efectivo en los clientes. El uso de valores TTL inferiores hará que sea más rápido; sin embargo, esto puede provocar una sobrecarga porque los clientes golpearán el DNS con más frecuencia en lugar de utilizar nombres en caché. Un buen enfoque es definir el 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 el TTL a su valor original.
Como usuario oracle, utilice el broker de Oracle Data Guard en el host de la base de datos principal 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 estaba en espera para que se apliquen.
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 un rol de base de datos en espera al rol de base de datos primaria cuando la base de datos primaria original falle y no haya posibilidad de recuperarla en tiempo. Puede haber pérdida de datos, dependiendo 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 Replicación de 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 operación de switchover en sí.
Pare los sistemas Oracle HTTP Server en la ubicación principal.
Pare 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 nodo principal.
Cambie el nombre de DNS del front-end.

Realice la transferencia de DNS necesaria en el servidor DNS que aloja los nombres que utiliza el sistema o modifique la resolución de host de archivo en los clientes para que el nombre virtual de front-end del sistema apunte a la IP pública que utiliza 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 min), el cambio de DNS tardará ese tiempo en ser efectivo en los clientes. El uso de valores TTL inferiores hará que esto sea más rápido; sin embargo, esto puede provocar una sobrecarga porque los clientes golpearán el DNS con más frecuencia en lugar de utilizar nombres en caché. Un buen enfoque es definir el 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 el 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 estaba en espera para que se apliquen.
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 que los servidores WebLogic Server secundarios se inicien en el sitio en espera y verifiquen 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 de JMS pendientes en la base de datos cuando se convierte en instantánea, los servidores 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 base de datos de instantánea en espera.

Como usuario oracle, utilice el broker de Oracle Data Guard en el host de la base de datos principal y convierta el secundario en una base de datos de 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.
Si aún no están activos, inicie los sistemas Oracle HTTP Server en el sitio secundario.
Inicie el servidor de administración en la ubicación secundaria.
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 las aplicaciones del servidor WebLogic del sitio secundario, debe actualizar el archivo /etc/hosts en un cliente controlado (por ejemplo, un equipo portátil), configurar 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 de 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 personalizada.

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

Nota:
Puede llevar tiempo validar el sitio secundario.
Pare los servidores gestionados y los servidores de administración en el sitio secundario.
Utilice la consola secundaria WebLogic para cerrar los servidores gestionados y el servidor de administración del sitio secundario.
Como usuario oracle, utilice Oracle Data Guard Broker en el host de la base de datos primaria y vuelva a convertir el secundario en la 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.

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 WebLogic Server en el que se estaba ejecutando el servidor de administración y para asociarla al host WebLogic Server al que se está moviendo la administración (desasocie la VIP de APPHOST1 y asóciela a APPHOST2 en el sitio de OCI):

Como usuario root, ejecute los siguientes comandos en APPHOST1 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 APPHOST1.
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 APPHOST1.
3. Haga clic en VNIC asociadas y, a continuación, seleccione la VNIC a la que está asociada la VIP del servidor de administración.
4. Haga clic en IPv4 Direcciones 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, hydrwls-vip.midtiersubnet.hydrvcn.oraclevcn.com).
6. Haga clic en Suprimir IP privada.
Conecte la VIP del servidor de administración a APPHOST2.
1. Vaya a la instancia informática. Haga clic en Compute, Instances y, a continuación, en APPHOST2.
2. Haga clic en VNIC asociadas y, a continuación, seleccione la VNIC a la que está asociada la VIP del servidor de administración.
3. Haga clic en Asignar dirección IP privada secundaria.
4. Haga clic en IPv4 Direcciones 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 hydrwls-vip como nombre de host.
Inicie sesión en APPHOST2 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.