Cuando el failover de DC se gestiona con cambios manuales en el DNS, el RTO está limitado por la velocidad humana.
En el modelo DNS clásico primario/backup, se detecta una caída de centro de datos, el equipo de operaciones recibe una alerta, se actualiza el registro de zona, se recarga el servicio y los clientes esperan a que la nueva respuesta DNS se propague. Esta cadena parece sencilla en un runbook; en un incidente real, los retrasos que introducen la toma de decisiones, el control de acceso, la aprobación y la ejecución estiran el RTO considerablemente.
En muchas organizaciones, health checking y DNS funcionan como sistemas separados. Una herramienta de monitorización ve que un DC es inalcanzable, pero el servidor DNS sigue respondiendo con las mismas direcciones IP. El puente entre ambos suele ser un script, un runbook manual o una capa de automatización separada. Esa brecha se convierte en el eslabón más débil en el momento del failover.
El failback conlleva un riesgo equivalente. Si un DC entra y sale rápidamente, la respuesta DNS puede oscilar repetidamente — los clientes se dispersan entre distintos centros de datos y el tráfico puede volver antes de que se complete la sincronización de estado. Una lógica simple de "eliminar cuando cae, reañadir cuando vuelve" no es suficiente.
El modelo correcto evalúa la salud del DC mediante lógica booleana de escenarios, reduce el riesgo de oscilación con umbrales consecutivos de éxito/fallo y hace que la respuesta DNS sea el resultado natural de esa decisión. El mismo modelo también debe cubrir el cutover manual para mantenimientos planificados, una respuesta fail-safe cuando todos los DCs están en mal estado y condiciones de DR.
TR7 DC Failover entrega este modelo: refresca automáticamente la respuesta DNS cuando cambia un escenario de salud de DC y ata todo el proceso de failover al TTL del DNS y a los parámetros de salud definidos por el operador.
Nuestro enfoque
TR7 implementa las decisiones de failover de DC mediante escenarios de salud, lógica de condición booleana, protección frente a oscilaciones y un mecanismo de cutover manual.
El escenario de salud gobierna directamente la respuesta DNS
Cuando cambia el estado del health check de un DC, el escenario asociado se reevalúa. Si el resultado del escenario cambia, los registros DNS correspondientes se regeneran y el DC en mal estado se elimina de la respuesta.
Las condiciones booleanas modelan decisiones complejas de salud de DC
Los grupos de condiciones se combinan con lógica AND; los grupos se combinan con lógica OR. También puede definirse una condición negativa para cada health check, habilitando escenarios inversos como "activar este registro cuando esta comprobación esté en mal estado".
La protección de estado bloqueado reduce la oscilación en el failback
Mientras un DC está en transición, el resultado de la evaluación anterior puede conservarse. Este comportamiento ayuda a evitar que fluctuaciones cortas de up/down cambien continuamente la respuesta DNS.
El modo mantenimiento proporciona un cutover manual para paradas planificadas
Durante un mantenimiento planificado, un operador puede sacar un DC fuera de servicio con el modo mantenimiento. Aunque el DC parezca sano, puede excluirse de la respuesta DNS para que el tráfico se dirija a otro DC.
Capacidades
DC Failover es la capa de failover del GTM que gestiona automáticamente las respuestas DNS entre múltiples centros de datos en función del estado de salud.
La cadena de prioridad N-DC admite flujos primario, secundario y terciario
TR7 puede evaluar los registros de DC como una cadena de prioridad ordenada por posición en el array. Cuando el DC primario está en mal estado, el secundario toma el relevo; cuando el secundario también está en mal estado, entra el terciario — y las cadenas más largas también están soportadas. El modelo de código no está limitado teóricamente a dos endpoints. Esta estructura simplifica el diseño de continuidad multietapa en entornos financieros, públicos y de SaaS a gran escala.
El único GSLB que mueve la base de datos junto con el tráfico
Cuando un centro de datos falla su escenario de salud, TR7 no solo desvía el DNS: la acción de disparo ejecuta la conmutación de la base de datos como parte del mismo evento. El switchover de Oracle Data Guard arranca desde la misma decisión de salud que redirigió el tráfico, así la recuperación ante desastres es un único movimiento automatizado en vez de dos equipos en una llamada puente acordando quién va primero.
Route Health Injection — la conmutación se anuncia a la red, no solo se decide dentro
El sitio que falla sus comprobaciones deja de anunciar el prefijo del servicio y el que sobrevive sigue anunciándolo: la decisión llega a los routers superiores como una actualización de enrutamiento en segundos. Así es como el tráfico se mueve de verdad, en lugar de limitarse a quedar marcado como movido. Como solo el sitio sano anuncia la dirección, no hay ventana en la que ambos la reclamen ni agujero negro mientras caduca un registro DNS. BFD reduce la detección a bastante menos de un segundo.
Hay disponibles cinco tipos de health check automáticos por DC
TR7 puede evaluar señales de salud a nivel de DC: wanAccess, lanAccess, access, internet y maintenanceMode. La alcanzabilidad WAN, la alcanzabilidad LAN, el estado general de acceso, el acceso a internet y el estado manual de mantenimiento se modelan por separado. Un DC se evalúa así en múltiples dimensiones de acceso, no solo en un único resultado de ping. La respuesta DNS refleja una imagen más realista de la salud del DC.
Los umbrales consecutivos de éxito y fallo reducen el riesgo de oscilación
requiredSuccess y requiredFailure determinan cuántos resultados consecutivos hacen falta antes de declarar un DC como sano o en mal estado. Este modelo evita cambios innecesarios en el DNS causados por pérdida transitoria de paquetes, interrupciones breves de red o ralentizaciones momentáneas del servicio. Los operadores pueden usar umbrales más estrictos para servicios críticos y más tolerantes para enlaces más ruidosos. El RTO se planifica junto con estos umbrales y el intervalo de comprobación.
Los modos backupBehavior controlan el comportamiento del DC pasivo
El modo noResponse mantiene un DC pasivo en silencio en condiciones normales. El modo onlyNew puede evitar que un DC que ha estado caído mucho tiempo responda con datos obsoletos cuando vuelve. Este comportamiento garantiza que, durante el failover, solo los DCs en el estado correcto generen respuestas DNS — no simplemente los que sean alcanzables. Es una capa de protección importante en entornos donde el riesgo de datos obsoletos es relevante.
El modo DR activa registros de recuperación ante desastres de forma condicional
El modo DR por registro permite que registros específicos se activen solo cuando se cumple una condición DR. El escenario drCond o el flag drIfNoRecords dispara el registro DR cuando se agotan los destinos primario y secundario. Este modelo mantiene las IPs remotas de recuperación ante desastres fuera de las respuestas DNS normales y las deja en standby para situaciones críticas. La estrategia DR pasa a controlarse a nivel de DNS.
La respuesta FailSafe proporciona un último recurso cuando todos los DCs están en mal estado
Si ningún DC está sano, puede generarse una respuesta a partir del array fallbackRecords. Estos registros pueden apuntar a una página de mantenimiento, a un endpoint estático de emergencia o a un servicio alternativo de recuperación. El comportamiento FailSafe garantiza que el DNS produzca una respuesta controlada de último recurso en lugar de no devolver nada. Los operadores definen estos registros según el plan de crisis de su organización.
La persistencia de estado preserva la continuidad de evaluación tras un reinicio
TR7 puede almacenar los datos locales de health check y de estado de escenario a nivel de fichero. Tras un reinicio o recarga de servicio, se restaura el estado anterior para que la evaluación no empiece de cero. Este enfoque reduce oscilaciones innecesarias en las decisiones de failover durante un reinicio transitorio. Es especialmente útil para mantener la consistencia durante operaciones de mantenimiento que reinician el servicio GTM.
La alcanzabilidad de un DC se verifica mediante múltiples objetivos WAN y LAN
Pueden definirse listas de objetivos wanAccess y lanAccess por DC. Múltiples objetivos de acceso ofrecen una imagen más precisa de la alcanzabilidad externa e interna de un DC. Un problema transitorio con un único objetivo no marca necesariamente todo el DC como caído. Esta estructura permite un modelado más completo de la salud del centro de datos.
El cutover manual permite una transferencia controlada de tráfico durante un mantenimiento planificado
Cuando se activa maintenanceMode, el DC correspondiente se saca conscientemente fuera de servicio. Esto resulta útil durante parches, ventanas de mantenimiento, migraciones o pruebas DR controladas. El operador puede eliminar el DC de la respuesta DNS — incluso estando sano — y redirigir el tráfico a otro DC. Al finalizar el mantenimiento, el modo se desactiva y la evaluación normal se reanuda.
La enumeración de estado clasifica los fallos de DC con más claridad
El estado del DC puede expresarse como ok, noInternet, noAccess, noWan o noLan. Esta clasificación indica qué dimensión de acceso es problemática en lugar de decir simplemente "caído". Los equipos de operaciones pueden distinguir más rápido entre problemas de salida a internet, alcanzabilidad WAN y alcanzabilidad LAN. La razón detrás de una decisión de failover se vuelve más legible.
La regeneración de configuración DNS se dispara automáticamente ante un cambio de estado de salud
Cuando cambia el estado del health check, el escenario asociado puede reevaluarse de inmediato. Los registros vinculados al escenario entran en el pipeline de regeneración dinámica de configuración y la respuesta DNS se actualiza. Este comportamiento reduce la necesidad de ediciones manuales de zona o scripts externos. Los cambios se agrupan mediante un breve debounce para evitar regeneraciones repetidas innecesarias.
Las escrituras de DNS maestro en un clúster HA las gestiona un único nodo
En un escenario de clúster HA, las escrituras de configuración DNS se controlan mediante el rol maestro. Si el nodo maestro falla, el nodo standby puede asumir el rol tras un periodo de seguridad definido. Este modelo ayuda a evitar que dos nodos produzcan configuraciones DNS distintas simultáneamente. El comportamiento del GTM permanece alineado con el estado del clúster.
Profundidad operativa
Una operación de failover de DC se planifica junto con el intervalo de comprobación, los umbrales consecutivos, la estructura del ID de HC, las condiciones del escenario, el pipeline de regeneración y los parámetros de RTO.
Intervalo del checker de DC
accessPeriod define con qué frecuencia se ejecutan los health checks del DC. Puede configurarse en segundos o minutos. Un periodo más corto proporciona detección más rápida; uno más largo aporta una evaluación más tranquila y con menos ruido.
Éxitos/fallos requeridos
requiredSuccess define cuántos éxitos consecutivos hacen falta antes de considerar un DC como up. requiredFailure define cuántos fallos consecutivos hacen falta antes de considerarlo down. Estos dos valores fijan el equilibrio entre velocidad de failover y protección frente a oscilaciones.
Tipo de acceso al DC
Las listas wanAccess y lanAccess definen los objetivos de acceso de un DC. Esto permite evaluar si un DC es alcanzable no solo desde el exterior sino también desde la red interna. La distinción es especialmente importante en escenarios de routing inter-DC e híbridos.
Formato del ID de HC
Los registros HC automáticos siguen el formato `auto|
Estructura de la condición del escenario
Las condiciones dentro de un grupo se combinan con lógica AND; los grupos se combinan con lógica OR. Esta estructura soporta una amplia gama de modelos de decisión, desde comprobaciones simples de caída del primario hasta escenarios complejos multidimensión de salud de DC. Los operadores no están limitados a un único resultado de comprobación.
Pipeline de decisión de failover
Cuando cambia el estado del HC, el escenario se reevalúa, se identifican los registros vinculados y se dispara la regeneración dinámica de configuración. El pipeline se ejecuta con un breve debounce para que cambios sucesivos rápidos se fusionen en un único pase de regeneración. La respuesta DNS se vuelve a renderizar según el estado de salud actual.
Dependencias del parámetro RTO
El RTO depende de accessPeriod, el conteo de requiredFailure, la duración del debounce de regeneración y el comportamiento del TTL DNS del cliente. En lugar de afirmar un tiempo único fijo, la ventana de failover debería planificarse en función de los requisitos del servicio. Los servicios críticos se benefician de TTL más cortos y comprobaciones más frecuentes.
Cuándo utilizarlo
Par clásico DC activo/pasivo
DC1 se define como primario y DC2 como standby pasivo. Cuando falla el escenario de internet o de acceso para DC1, los registros de DC1 se eliminan de la respuesta DNS y DC2 empieza a responder.
Cadena de prioridad de tres DCs en una institución financiera
Las instituciones financieras pueden construir una cadena de failover secuencial DC1 → DC2 → DC3. Cada nivel se evalúa con su propio escenario de salud y un DC en mal estado se elimina automáticamente de la respuesta DNS.
Mantenimiento planificado con cutover manual
En la ventana de mantenimiento, DC1 se pone en modo mantenimiento y el tráfico se dirige a DC2. Al finalizar el mantenimiento, el modo mantenimiento se desactiva y se reanuda la evaluación normal de salud.
Activación de un sitio remoto de recuperación ante desastres
Cuando los DCs primario y secundario están ambos en mal estado, pueden activarse los registros del modo DR. En este escenario, el sitio remoto de recuperación ante desastres permanece pasivo en condiciones normales y se añade a la respuesta DNS solo cuando se cumplen las condiciones definidas.
DC secundario protegido frente a datos obsoletos
Cuando un DC que ha estado caído un periodo prolongado vuelve a estar online, puede no ser deseable que responda con datos desactualizados. El comportamiento onlyNew mantiene pasivo a un DC obsoleto, reduciendo el riesgo de publicar registros obsoletos.
Routing híbrido de geofence y failover
Primero se selecciona el DC más cercano por país o región y, si ese DC deja de estar sano, se activa el DC de standby. Este modelo combina la dirección basada en rendimiento con las decisiones de continuidad en una única configuración GTM.
Preguntas frecuentes
¿Cuándo y cómo se dispara una decisión de failover de DC?
¿Cómo funciona la protección frente a oscilaciones?
¿Cuánto tarda el RTO?
¿En qué se diferencia el modo DR del failover normal?
¿Se pierde el estado de failover si el servicio GTM se reinicia?
¿Cómo se saca un DC fuera de servicio para un mantenimiento planificado?
Lleve el failover de DC a la velocidad del TTL del DNS
Escenario de salud, respuesta DNS y cutover manual unificados en un único pipeline de decisión. Hagamos un recorrido por una configuración en vivo con su propia arquitectura de DC.