Acerca de la gestión de fallos

La topología de cluster ampliado de Oracle Fusion Middleware (FMW) es resistente a fallos en cualquier componente individual.

Cada sitio sigue las mejores prácticas de alta disponibilidad descritas en la topología de despliegue empresarial de Oracle FMW, lo que garantiza que la redundancia local protege frente a interrupciones en el nivel de componente (como el equilibrador de carga, las instancias de Oracle HTTP Server, Oracle WebLogic Server o la instancia de base de datos).

Las consideraciones para abordar escenarios como un fallo completo del nivel dentro de un centro o un fallo total del centro se tratan en las siguientes secciones.

Gestionar el fallo de todos los servidores web en un sitio

Si un sitio pierde todas las instancias de Oracle HTTP Server, el sistema frontend (ya sea un equilibrador de carga global o una política de dirección de gestión de tráfico de Oracle Cloud Infrastructure (OCI), debe marcar el sitio como en mal estado.

Todas las solicitudes del cliente, independientemente de sus preferencias de centro, se enrutarán al otro centro.

Por lo tanto, los servidores de Oracle WebLogic del sitio con los servidores web fallidos no recibirán nuevas solicitudes. Pueden seguir realizando algún procesamiento (por ejemplo, el procesamiento de compuestos de Oracle SOA y mensajes del servicio de mensajes java [JMS]). Sin embargo, cualquier devolución de llamada HTTP generada internamente a partir de estos servidores fallará porque apuntan a su propio sitio, cuyos servidores web han fallado.

En el siguiente diagrama se muestran los fallos en todos los servidores web de un sitio

Descripción de la ilustración Failure-all-web-servers-one-site.png

fail-all-web-servers-onesite-oracle.zip

Recuperación del fallo

No se necesita ninguna intervención manual para la recuperación inmediata de un fallo en todos los servidores web de un sitio.

Los clientes se redirigen automáticamente al otro sitio gracias a las políticas de dirección de Oracle Cloud Infrastructure (OCI) Traffic Management o al equilibrador de carga global (GLBR).

Si la restauración de las instancias perdidas del servidor web no es posible a corto plazo, puede realizar lo siguiente para utilizar los servidores WebLogic del sitio con el nivel web fallido:

1. Configure las instancias de Oracle HTTP Server (OHS) en el otro sitio para direccionar las solicitudes a las instancias de Oracle WebLogic Server en el sitio con fallos.
   1. Actualice la configuración de OHS y defina el parámetro DynamicServerList en ON.
   2. Aplique este cambio reiniciando OHS de forma sucesiva para evitar el tiempo de inactividad.
   3. Además, asegúrese de que la comunicación entre regiones esté permitida desde los servidores web a los servidores WebLogic en el otro sitio.
2. Para evitar fallos en las devoluciones de llamada del protocolo de transferencia de hipertexto (HTTP) que se originan desde el sitio con servidores OHS no disponibles, actualice la entrada para el nombre de frontend en el archivo /etc/hosts o el sistema de nombres de dominio privado (DNS) de los hosts del servidor WebLogic para que apunte al equilibrador de carga en el otro sitio.

Una vez que los servidores con fallos estén disponibles de nuevo:

1. Inicie los procesos de OHS en el sitio con fallos.

   Una vez que Oracle Cloud Infrastructure Health Checks vuelva a ser correcto, la política de dirección de gestión de tráfico equilibrará la carga de solicitudes de cliente entre ambos sitios, según las reglas definidas.

2. Vuelva a definir DynamicServerList en OFF en el otro sitio.
3. Revertir cualquier cambio en el archivo /etc/hosts de los servidores WebLogic (o DNS privado) para que vuelvan a apuntar a su propio equilibrador de carga de sitio.

En la siguiente imagen se muestran los mensajes de cola de Java Message Service (JMS) y las solicitudes fallidas del cliente durante un fallo de todos los servidores web en un sitio:

Descripción de la ilustración failure-messages-all-web-servers-one-site.png

Objetivo de tiempo de recuperación esperado

Al utilizar las políticas de dirección de gestión de tráfico de Oracle Cloud Infrastructure (OCI) para el equilibrio global, se observan errores durante un período de alrededor de 1 minuto + tiempo de vida de DNS (TTL).

La actualización de DNS afecta a los clientes cuya preferencia de política de dirección se establece en la región con fallos. El valor de TTL determina cuánto tiempo estos clientes continuarán usando la entrada anterior antes de actualizarla para que apunte al sitio en buen estado. El tiempo adicional (alrededor de 1 minuto) depende de la frecuencia y el tiempo de espera de las comprobaciones del sistema configuradas en la política de dirección de OCI (se utilizaron 30 segundos en la prueba anterior para el intervalo de comprobación del sistema y un tiempo de espera de 10 segundos).

Al utilizar un equilibrador de carga global (GLBR), el tiempo de interrupción depende de la frecuencia de las comprobaciones del sistema configuradas en el GLBR. Tan pronto como el GLBR marque una agrupación como en mal estado, las solicitudes entrantes se redirigirán al otro sitio. Con un GLBR, no hay ninguna actualización de DNS, por lo que el valor TTL de la entrada de frontend es irrelevante.

Gestionar el fallo de todos los servidores de Oracle WebLogic en una ubicación

Cuando todos los servidores WebLogic se caen en un sitio, el otro sitio continúa procesando solicitudes.

El equilibrador de carga del sitio con fallos devolverá una respuesta con fallos, por lo que la función de equilibrio global de frontend, basada en las políticas de dirección de tráfico de Oracle Cloud Infrastructure (OCI) y las comprobaciones de estado, debe marcar el sitio como en mal estado. Todas las solicitudes del cliente, independientemente de su preferencia, se enrutarán al otro centro.

Los servicios WebLogic Java Message Service (JMS) y Java Transaction API (JTA) se migrarán automáticamente a los servidores del otro sitio cuando se utilice la migración automática de servicios junto con los almacenes persistentes de Java Database Connectivity (JDBC).

En el caso de SOA de Oracle Fusion Middleware (FMW), si el maestro de cluster de recuperación automática se ha alojado en los servidores con fallos, se generará un nuevo maestro de cluster en la ubicación disponible. Este servidor realiza una recuperación automatizada de las instancias de SOA iniciadas en el otro sitio.

En el siguiente diagrama se muestra el fallo de todos los servidores WebLogic en un sitio:

Descripción de la ilustración failure-all-weblogic-servers-one-site.png

fail-all-weblogic-servers-onesite-oracle.zip

En la siguiente imagen se muestran las solicitudes con fallos de cliente y los mensajes JMS por servidor cuando todos los servidores WebLogic fallan en un sitio.

Descripción de la ilustración failure-messages-all-weblogic-servers-one-site.png

En el gráfico de mensajes JMS, hay cuatro líneas, cada una de las cuales representa la cola JMS de un servidor. Las líneas verde y azul (que casi se superponen) corresponden a los servidores que se han matado. El número de mensajes de JMS para estas colas no aumenta una vez que comienza la interrupción.

Las líneas roja y amarilla representan los servidores que permanecen activos en la región 2. Cuando se redirigen todas las solicitudes a esta región, cada servidor restante recibe el 50% de la carga total. Sin embargo, el ratio al que se acumulan los mensajes en sus colas es diferente. Esto se debe a que los servidores JMS de los servidores fallidos se migraron a uno de los servidores restantes, por lo que los mensajes de ese servidor ahora son procesados por tres colas. Como resultado, la pendiente aparece más baja en la amarilla (tenga en cuenta que la herramienta de supervisión no muestra los recuentos de mensajes para las colas migradas).

Recuperación del fallo

No se necesita ninguna intervención manual para la recuperación inmediata de un fallo en todos los servidores de Oracle WebLogic Server en un sitio.

Una vez que los servidores con fallos estén disponibles de nuevo:

1. Inicie los servidores gestionados en el sitio con fallos.
2. En cuanto Oracle Cloud Infrastructure Health Checks vuelva a estar en buen estado, la política de dirección de gestión de tráfico equilibrará la carga de solicitudes de cliente entre ambos sitios, según las reglas definidas.

Objetivo de tiempo de recuperación esperado

Al utilizar las políticas de dirección de gestión de tráfico de Oracle Cloud Infrastructure (OCI) para el equilibrio global, se observan errores durante un período de alrededor de 1 minuto + tiempo de vida de DNS (TTL).

Esto es similar al escenario en el que se produce un fallo en todos los servidores web de un sitio,

La actualización de DNS afecta a los clientes cuya preferencia de política de dirección se establece en la región con fallos. El valor de TTL determina cuánto tiempo estos clientes continuarán usando la entrada anterior antes de actualizarla para que apunte al sitio en buen estado. El tiempo adicional (alrededor de 1 minuto) depende de la frecuencia y el tiempo de espera de las comprobaciones del sistema configuradas en la política de dirección de OCI Traffic Management (se utilizaron 30 segundos en la prueba para el intervalo de comprobación del sistema y un tiempo de espera de 10 segundos).

Al utilizar un equilibrador de carga global (GLBR), el tiempo de interrupción depende de la frecuencia de las comprobaciones del sistema configuradas en el GLBR. Tan pronto como el GLBR marque una agrupación como en mal estado, las solicitudes entrantes se redirigirán al otro sitio. Con un GLBR, no hay ninguna actualización de DNS, por lo que el valor TTL de la entrada de frontend es irrelevante.

Gestión de Fallos en la Base de Datos: Switchover y Failover de Data Guard

Si un problema afecta sólo a la base de datos primaria, realice una operación de switchover o failover de la base de datos en la otra ubicación lo antes posible.

La cadena de URL de Java Database Connectivity (JDBC) y la configuración de Oracle Notification Service (ONS) proporcionada anteriormente en "Configuración de orígenes de datos WebLogic" garantizan que la reconexión se realice automáticamente a la nueva base de datos primaria. Para estas pruebas precisas (mediante el FOD de SOA de Oracle Fusion Middleware (FMW) e incluso con cargas de trabajo altas de 160 llamadas simultáneas), la operación de switchover o failover de la base de datos tarda menos de un par de minutos. Este tiempo puede variar en función de la configuración y el entorno del sistema. En sistemas bien ajustados, los tiempos de switchover de 1 a 5 minutos son comunes, pero factores como el tamaño del sistema, los recursos, la carga de trabajo, la sincronización de redo logs y el rendimiento de la red pueden afectar a la duración total. Consulte la sección Explorar más para obtener enlaces a la documentación de Oracle Data Guard y otros recursos.

Durante una operación de switchover o failover de la base de datos, habrá errores de aplicación. Además, el gestor de nodos puede cerrar y reiniciar automáticamente los servidores WebLogic que utilizan la migración de servicios si no pueden actualizar su tabla de leasing. El comportamiento esperado con los parámetros de leasing por defecto es:

1. Si la interrupción de la base de datos es muy corta (<1-2 min), no se espera ningún reinicio automático del servidor WebLogic.
2. Si la interrupción de la base de datos es más larga (2-10 minutos), los servidores WebLogic pueden reiniciarse automáticamente debido a la "perdida de un permiso" cuando la base de datos se vuelva a iniciar.

   El límite inferior se puede aumentar ajustando los reintentos de leasing de bases de datos de WebLogic, como se describe anteriormente en "Configuración del Ajuste de WebLogic Database Leasing".

3. Si la interrupción de la base de datos es mucho más larga (>10 min), los servidores WebLogic pueden reiniciarse automáticamente debido a otros fallos, como la pérdida de acceso a los almacenes JDBC críticos ("el almacén JDBC de JTA no está disponible").

En el siguiente diagrama se muestra el switchover de la base de datos en la topología de clusters ampliados de FMW

Descripción de la ilustración estiched-clusters-db-switchover.png

estiramiento-clusters-db-switchover-oracle.zip

En la siguiente imagen se muestra el rendimiento de las solicitudes de cliente y los mensajes de Java Message Service (JMS) por cola de servidor durante un switchover de base de datos en un cluster ampliado de FMW.

Descripción de la ilustración estiramched-clusters-db-switchover-messages.png

Recuperación del fallo

Para recuperarse inmediatamente de un fallo de la base de datos:

1. Realice un switchover de base de datos mediante la consola de Oracle Cloud Infrastructure (OCI) o la interfaz de línea de comandos del broker de Oracle Data Guard.
2. Si no se trata de una base de datos primaria disponible, realice un failover de base de datos desde la base de Datos en espera.

   Los servidores de Oracle WebLogic Server se vuelven a conectar automáticamente a la nueva base de datos principal, por lo que no se necesitan acciones manuales, excepto para recuperarse de los errores específicos de la aplicación según sea necesario (por ejemplo, en Oracle SOA Suite, puede que necesite recuperar compuestos en el hospital de errores).

Una vez que los servidores con fallos estén disponibles de nuevo:

1. Vuelva a instanciar la base de datos con fallos si ha realizado un failover de la base de datos.

   Esta acción no es necesaria si ha realizado un switchover.

2. Realice un cambio de base de datos al sitio original.

Objetivo de tiempo de recuperación esperado

Para una operación de switchover planificada, el tiempo total de recuperación es corto y depende del tiempo que la base de datos necesite para la operación de switchover o failover.

Para las pruebas realizadas, el switchover tarda menos de 2 minutos.

Para un switchover o failover no planificados, el tiempo de inactividad total depende del tiempo de inactividad de la base de datos:

• Si realiza el failover o switchover de la base de datos casi inmediatamente, el tiempo total de recuperación es corto. Depende del tiempo que la base de datos necesite para el switchover o el failover. Para las pruebas realizadas, la operación de switchover tarda menos de 2 minutos, por lo que el objetivo de tiempo de recuperación (RTO) esperado es:

  RTO = DB DOWNTIME + SHORT TIME (1-2 min)

• Si el tiempo de inactividad de la base de datos es más largo, puede haber errores adicionales, como los reinicios automáticos de Oracle WebLogic Server, que aumentan el RTO. En este caso, el RTO esperado es:

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Gestión de Fallos en el Servidor de Administración WebLogic

El gestor de nodos WebLogic de ese nodo se encarga de los fallos de proceso para el servidor de administración.

El gestor de nodos reiniciará automáticamente el servidor fallido en el lugar.

Sin embargo, debe realizar un failover del servidor de administración en un nodo diferente si una interrupción afecta completamente al host en el que se ejecuta el servidor de administración.

Básicamente, esto consiste en reiniciar el servidor de administración en un nodo diferente, asegurándose de que apunta a la ubicación que contiene el directorio de dominio del servidor de administración y que utiliza una dirección de recepción que se asigna a la IP virtual (VIP) adecuada.

Este directorio de dominio del servidor de administración puede ser una ubicación de almacenamiento compartido disponible para diferentes nodos de la misma región, o una restauración a partir de una copia de seguridad o replicación del sistema de archivos disponible para los nodos de una región diferente.

Note:

Independientemente de la configuración de cluster ampliada, se espera que existan los procedimientos de copia de seguridad adecuados para el dominio de Oracle WebLogic.

Por lo tanto, en una topología de cluster ampliada de Oracle Fusion Middleware (FMW), se aplican diferentes consideraciones al migrar el servidor de administración a un nodo de una región diferente en lugar de migrarlo a un nodo de la misma región.

En el siguiente diagrama se muestra el failover del servidor de administración al otro sitio del cluster ampliado de FMW

Descripción de la ilustración Failure-admin-server.png

fallos-admin-server-oracle.zip

Failover en otra región

Para realizar una operación de failover del servidor de administración en una región diferente, siga estos pasos.

1. Haga que la copia de seguridad del directorio de dominio del servidor de administración (ASERVER_HOME) esté disponible en el sitio de failover.
2. Restaure el directorio ASERVER_HOME (incluido el dominio y el directorio de aplicaciones) en el sitio de failover para que la misma estructura de directorios de dominio sea coherente con el sitio original.
3. Las subredes de la región 1 y la región 2 suelen utilizar diferentes bloques de enrutamiento entre dominios (CIDR) sin clases. Como resultado, la IP virtual (VIP) utilizada por el servidor de administración en la región 1 (por ejemplo, 10.10.10.1) no es válida en la región 2. Cuando el servidor de administración se ejecuta en la región 2, utilizará una VIP diferente (por ejemplo, 20.20.20.1). Actualice la resolución del nombre de host para que la dirección de recepción (ADMINHOSTVHN) del servidor de administración se asigne a la nueva VIP.
   1. Asigne y asocie una IP virtual al host que ejecutará el servidor de administración en la región 2, como se describe en el blog Uso de una IP virtual (VIP) en Oracle Cloud Infrastructure.
   2. Actualice las vistas privadas /etc/hosts o del sistema de nombres de dominio (DNS) en ambas regiones para cambiar el registro ADMINHOSTVHN de la IP anterior (por ejemplo, 10.10.10.1) a la nueva IP (por ejemplo, 20.20.20.1).
4. Modifique el archivo $NM_HOME/nodemanager.domains en el nodo donde se restaurará el servidor de administración para incluir el archivo ASERVER_HOME y reinicie el gestor de nodos:

   domain_name=MSERVER_HOME;ASERVER_HOME

5. Inicie el servidor de administración en el nuevo host.
6. Las instancias de Oracle HTTP Server utilizan una caché DNS, controlada por la directiva WLDNSRefreshInterval en mod_wl_ohs.conf. Es 0 por defecto, lo que significa "caché para siempre". Debe reiniciar OHS para refrescar la caché de resolución de DNS. Tiene dos enfoques:
   1. Reinicie los servidores de OHS para refrescar la caché de resolución de DNS.
   2. O defina un valor distinto de cero para WLDNSRefreshInterval en mod_wl_ohs.conf.

   De lo contrario, OHS seguirá intentando conectarse al servidor de administración con la dirección IP anterior.

Verifique que el servidor de administración funciona correctamente accediendo a la WebLogic Remote Console y a Oracle Enterprise Manager Fusion Middleware Control.

Failover en la misma región

Para conmutar por error el servidor de administración a un host de la misma región, no es necesario copiar el directorio de dominio del servidor de administración y el valor de la IP virtual (VIP) no cambia.

Por lo tanto, el procedimiento de failover es el mismo que se describe en la Guía de Despliegue de Empresa para el servidor de administración, en Verificación de Failover Manual del Servidor de Administración.

Para gestionar la IP virtual (VIP) del servidor de administración en los sistemas de Oracle Cloud Infrastructure (OCI), puede utilizar los pasos descritos en el blog Uso de una IP virtual (VIP) en Oracle Cloud Infrastructure

Gestionar fallos de toda la región que aloja la base de datos primaria

Si una interrupción afecta a toda la región 1, realice una operación de switchover o failover de la base de datos en el otro sitio o región lo antes posible.

Las instancias de Oracle WebLogic Server del sitio restante se volverán a conectar automáticamente a la nueva base de datos primaria si utilizan la configuración recomendada que se describe en la sección anterior.

El equilibrador de carga del sitio con fallos devolverá una respuesta con fallos, por lo que la función de equilibrio global de front-end debe marcar el sitio como en mal estado. Todas las solicitudes del cliente, independientemente de su preferencia, se enrutarán al otro centro.

Los servicios JMS y JTA WebLogic se migrarán automáticamente a los servidores de la otra ubicación al utilizar la migración automática de servicios junto con los almacenes persistentes de JDBC. En el caso de Oracle Fusion Middleware (FMW) Oracle SOA Suite, si el maestro de cluster de recuperación automática se alojó en los servidores con fallos, se generará un nuevo maestro de cluster en la ubicación disponible. El nuevo gestor de clusters realizará una recuperación automatizada de las instancias de SOA iniciadas en la otra ubicación.

En el siguiente diagrama se muestra el fallo de toda la región 1 en la topología de clusters ampliados de FMW:

Descripción de la ilustración failure-entire-region.png

fallos-entire-region-oracle.zip

Recuperación del fallo

Para recuperarse inmediatamente de un fallo completo en la región 1:

1. Realice un switchover de base de datos mediante la consola de Oracle Cloud Infrastructure (OCI) o la interfaz de línea de comandos del broker de Oracle Data Guard.

   Si no se trata de una base de datos primaria disponible, realice un failover de base de datos desde la base de Datos en espera.

2. Las instancias de Oracle WebLogic Server se vuelven a conectar automáticamente a la nueva base de datos principal, por lo que no se necesitan acciones manuales, excepto para recuperarse de errores específicos de la aplicación (por ejemplo, en Oracle SOA Suite, puede que necesite recuperar compuestos en el hospital de errores).
3. Si es necesario, realice un failover del servidor de administración en la región 2.

Después de recuperar el sitio fallido y volver a estar disponible:

1. Reinicie los procesos en los hosts fallidos: servidores HTTP de Oracle, servidor de administración WebLogic y servidores gestionados.

   Asegúrese de que la IP virtual (VIP) del servidor de administración está definida y de que no existen archivos huérfanos que impidan el inicio.

2. Vuelva a instanciar la base de datos con fallos si ha realizado un failover de la base de datos.

   Esta acción no es necesaria si ha realizado un switchover.

3. Realice un switchover de la base de datos al sitio original.

Objetivo de tiempo de recuperación esperado

Mientras la base de datos esté caída, el sistema no estará disponible.

Los servidores del sitio restante pueden seguir procesando solicitudes tan pronto como la base de datos se vuelva a ejecutar en el sitio restante, por lo que el tiempo de inactividad depende del tiempo utilizado antes de realizar el switchover de la base de datos.

• Si realiza el failover o switchover de la base de datos casi inmediatamente, el tiempo total de recuperación es corto. Depende del tiempo que la base de datos necesite para el switchover o el failover. Para la prueba realizada, el switchover tarda menos de 2 minutos, por lo que el RTO esperado es:

  RTO = DB DOWNTIME + SHORT TIME (1-2 min).

• Si el tiempo de inactividad de la base de datos es más largo, puede haber errores adicionales, como los reinicios automáticos de Oracle WebLogic Server, que aumentan el RTO. El RTO esperado es:

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Gestionar fallos de toda la región que aloja la base de datos en espera

Si un fallo afecta a toda la región 2, la función de equilibrio global de frontend debe marcar el sitio como en mal estado.

Todas las solicitudes del cliente, independientemente de su preferencia de centro, se enrutarán a la región 1, que continúa procesando solicitudes. Los servicios JMS y JTA WebLogic se migrarán automáticamente a los servidores del sitio 1 cuando se utilice la migración automática de servicios junto con los almacenes persistentes de JDBC.

En el caso de Oracle Fusion Middleware (FMW) con Oracle SOA Suite, si el maestro de cluster de recuperación automática se alojó en los servidores con fallos, se generará un nuevo maestro de cluster en la ubicación disponible. Este servidor realiza una recuperación automatizada de las instancias de SOA iniciadas en el otro sitio.

No es necesario realizar un switchover de la base de datos, ya que la interrupción no afecta a la base de datos primaria.

En el siguiente diagrama se muestra el fallo de toda la región 2 en la topología de clusters ampliados de FMW.

Descripción de la ilustración failure-standby-db-region.png

fallos-standby-db-region-oracle.zip

Recuperación del fallo

No es necesaria ninguna intervención manual para la recuperación inmediata de un fallo completo en la región 2.

Una vez que el sitio con fallos esté disponible de nuevo, reinicie los procesos en los hosts con fallos para los servidores HTTP de Oracle y los servidores gestionados WebLogic.

Asegúrese de que no haya archivos huérfanos que impidan que WebLogic se inicie.

Gracias a la función de equilibrador de carga global (políticas de dirección de Oracle Cloud Infrastructure Traffic Management o un equilibrador de carga global), las solicitudes del cliente se volverán a equilibrar entre los 2 sitios.

Objetivo de tiempo de recuperación esperado

Al utilizar políticas de dirección de tráfico de Oracle Cloud Infrastructure (OCI) para el equilibrio global, el período con fallos es de alrededor de 1 minuto más que el tiempo de actividad (TTL) de la entrada de frontend definida en la política de dirección.

La actualización del sistema de nombres de dominio (DNS) afecta a los clientes que tienen la región 2 definida como su preferencia en la política de dirección de geolocalización. La actualización de DNS afecta a los clientes cuya preferencia de política de dirección se establece en la región con fallos. El valor de TTL determina cuánto tiempo estos clientes continuarán usando la entrada anterior antes de actualizarla para que apunte al sitio en buen estado. El tiempo adicional (alrededor de 1 minuto) depende de la frecuencia y el tiempo de espera de las comprobaciones de estado configuradas en la política de dirección de gestión de tráfico de OCI (se utilizaron 30 segundos en la prueba anterior para el intervalo de comprobación de estado y un tiempo de espera de 10 segundos).

Al utilizar un equilibrador de carga global (GLBR), el tiempo de interrupción depende de la frecuencia de las comprobaciones del sistema configuradas en el GLBR. Tan pronto como el GLBR marque una agrupación como en mal estado, las solicitudes entrantes se redirigirán al otro sitio. Con un GLBR, no hay ninguna actualización de DNS, por lo que el valor TTL de la entrada de frontend es irrelevante.