El patrón GSLB estándar es el siguiente: se monitoriza un endpoint, cuando deja de estar sano se desplazan las respuestas DNS hacia el backup, cuando vuelve a estar sano se desplazan de vuelta. Las implementaciones de los principales fabricantes de GSLB tratan ambas transiciones como la inversa de la misma condición.
La realidad de producción no es simétrica. Hacer failover a un backup es un movimiento defensivo ejecutado bajo presión; volver al primario es un movimiento ofensivo ejecutado con confianza. Las condiciones, las ventanas de espera, las aprobaciones del operador y los triggers que deben dispararse son diferentes en cada dirección.
Ejemplos: rápido para entrar / lento para salir — failover al primer error detectado para proteger al usuario, pero exigir 15 minutos de salud limpia antes de volver para evitar oscilaciones. Conservador para entrar / rápido para salir — exigir tres fallos consecutivos antes de iniciar el failover, pero volver inmediatamente cuando el primario se recupere para cumplir los compromisos de RPO/RTO. Automático para entrar / manual para salir — el failover está automatizado, pero el camino de vuelta requiere reconocimiento del SRE tras revisar el runbook.
Ninguno de estos casos puede expresarse con un escenario unidireccional. El operador o bien elige una dirección y vive con la política incorrecta en la otra, o bien construye scripts personalizados frágiles que se desvían de la fuente de verdad del GSLB.
Los escenarios bidireccionales de TR7 GTM permiten que la activación y la desactivación lleven condiciones independientes, comprobaciones de gating independientes y acciones de trigger independientes — la estructura de política que ya asume su runbook de respuesta a incidentes.
Un escenario es una máquina de estados nombrada y reutilizable con dos direcciones. Cada dirección se define mediante una expresión de condición combinada y un conjunto de triggers; las dos direcciones no necesitan ser inversas.
Una expresión de condición combinada evalúa los health-checks subyacentes. Cuando devuelve verdadero, el escenario se activa. Los triggers opcionales disparan acciones (webhooks HTTP/HTTPS, consultas Oracle) y una comprobación de gating opcional confirma que el trigger debe proceder.
Una expresión de condición combinada separada evalúa un conjunto separado de health-checks. El camino de desactivación puede ser la inversa de la activación, o puede exigir estabilidad adicional, sondas adicionales o triggers completamente distintos.
Las condiciones no son booleanos sueltos — son grupos de resultados de health-check unidos con AND dentro de un grupo y OR entre grupos, con negación opcional. El mismo DSL que rige la lógica de reglas de tráfico en el ADC también rige aquí la evaluación de escenarios.
Un escenario se define una vez y se referencia por nombre desde registros DNS, configuraciones de recuperación ante desastres y políticas de failover entre centros de datos. Los operadores no vuelven a escribir la misma lógica en múltiples sitios.
Los escenarios bidireccionales son la base de la política de failover y recuperación de TR7 GTM.
La condición de activación se construye a partir de resultados de health-check de uno o más perfiles de health-check. Los grupos unen las comprobaciones con AND; varios grupos se unen con OR. Cada comprobación individual puede negarse. Los operadores expresan condiciones como "(API operativa AND base de datos operativa) OR (ruta de failover A operativa AND ruta de failover B operativa)" sin scripting.
La condición de desactivación es independiente de la activación. Los operadores expresan condiciones como "el primario lleva sano 15 minutos AND la latencia está por debajo del umbral" mientras que la activación podía haber sido simplemente "el primario está caído".
Los triggers de activación y los de desactivación son conjuntos seleccionables separados. Un evento de activación puede notificar al SRE de guardia; un evento de desactivación puede notificar al SRE, ejecutar una transacción sintética y emitir un webhook hacia el sistema de despliegue.
Una condición de gating opcional se ejecuta antes de que los triggers de cada dirección se ejecuten. Si la comprobación de gating devuelve falso, la transición de estado se produce igualmente pero los triggers no se disparan. Caso de uso: las transiciones de estado se realizan automáticamente, pero las notificaciones externas solo se disparan dentro del horario laboral.
Cada dirección admite tres modos seleccionables por el operador. Auto sigue la expresión de condición. On fuerza la dirección a activarse independientemente de las condiciones (override manual). Off desactiva la dirección por completo (por ejemplo, deshabilitar el failback durante una ventana de mantenimiento).
Cuando se definen dos centros de datos, TR7 GTM autogenera cuatro escenarios por par: from-active, to-active, from-backup, to-backup — cada uno con su lógica de condiciones basada en las comprobaciones de acceso WAN, acceso LAN y alcanzabilidad de internet. Los operadores pueden usar los escenarios autogenerados tal cual, personalizarlos o crear los suyos desde cero.
El estado sano/no sano de los registros DNS puede gobernarse mediante un escenario en lugar de un booleano estático o un único health-check. El campo `cond` por registro acepta una referencia a un escenario: cuando el escenario se activa, el registro se excluye de las respuestas; cuando se desactiva, el registro vuelve.
Los registros de recuperación ante desastres pueden especificar `drCond` — un escenario que determina cuándo el conjunto de registros DR sustituye al conjunto de registros primarios en las respuestas. La evaluación del escenario DR es bidireccional, dando soporte a failover controlado y failback controlado.
Los triggers se disparan como llamadas HTTP/HTTPS (URI personalizado, método, cabeceras, cuerpo, códigos de estado esperados, consulta de coincidencia de contenido) o como llamadas a base de datos Oracle (SQL configurado). Los operadores conectan las activaciones de escenario a los pipelines existentes de gestión de incidentes, despliegue o auditoría.
Cada cambio de estado de un escenario se registra: qué dirección se disparó, qué condiciones evaluaron verdadero/falso, qué triggers se ejecutaron, qué comprobación de gating pasó. La revisión post-incidente reconstruye la secuencia exacta de decisiones automatizadas sin arqueología manual de logs.
Los escenarios se operan junto con las definiciones de health-check, las configuraciones de triggers, los enlaces a registros DNS y las configuraciones de recuperación ante desastres.
Dentro de un grupo de condiciones, todas las comprobaciones listadas deben evaluar verdadero (AND). Entre grupos, basta con que uno evalúe verdadero (OR). El sufijo `!` en un identificador de comprobación lo niega. La estructura de agrupación es simétrica para activación y desactivación; cada dirección tiene su propio conjunto de grupos.
Las condiciones referencian los health-checks por ID. Los perfiles de health-check definidos por el usuario y las comprobaciones autogeneradas de pares DC comparten el mismo espacio de IDs. Los operadores combinan comprobaciones manuales y automáticas dentro del mismo grupo de condición.
Cuando la activación se fuerza a on (override manual), la evaluación de desactivación normalmente continúa — los operadores pueden activar manualmente y dejar que la condición de desactivación decida cuándo restablecer. Forzar ambas direcciones a on crea un estado bloqueado y se registra como advertencia de configuración.
Los triggers se disparan con una carga útil estructurada que incluye el ID del escenario, la dirección, la marca de tiempo de la evaluación y la instantánea de la configuración en el momento del disparo. Los fallos del trigger (HTTP distinto de 2xx, error de Oracle) se registran y opcionalmente se reintentan según el perfil del trigger.
Los escenarios se evalúan ante cada cambio de estado de health-check, no con un temporizador de sondeo. El primer cambio de estado que cruza el umbral de activación o desactivación dispara la transición. El coste de evaluación se mantiene bajo porque las condiciones referencian estados de salud precomputados.
Los operadores ven el estado actual de cada escenario (activado / desactivado), la hora de la última transición, el último resultado de evaluación de cada grupo de condiciones y los resultados de los triggers. El cuadro de mandos hace visibles las transiciones bloqueadas y los overrides conflictivos.
Active el failover al primer error detectado para proteger al usuario. Desactive solo tras 15 minutos de salud limpia del primario para evitar oscilaciones. Condiciones diferentes, temporización diferente — el mismo objeto escenario.
El failover está automatizado; el camino de vuelta requiere reconocimiento del SRE. La dirección de desactivación se pone en off; un operador la cambia manualmente a on tras revisar el runbook. La activación sigue evaluándose automáticamente.
El failover DC A → DC B dispara un webhook HTTP al sistema de gestión de incidentes. El failback DC B → DC A dispara el mismo webhook más una llamada al sistema de despliegue para precalentar las cachés. Los triggers en cada dirección son independientes.
Use el trigger Oracle para consultar una base de datos antes del failover — por ejemplo, confirmar que la base de datos de backup se ha puesto al día mediante log shipping. El resultado del trigger condiciona la transición real de estado.
Recorra un escenario bidireccional construido sobre su propio runbook: rápido para entrar / lento para salir, failback manual, conjuntos de triggers asimétricos — su política, no el valor por defecto de la plataforma.