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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Los registros HC automáticos siguen el formato `auto|
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.