Cuando el GTM hace failover, el resto de la organización necesita saberlo.
En una arquitectura GTM, un cambio en el estado de health-check puede cambiar la respuesta DNS — pero una operación rara vez es solo una respuesta DNS. Cuando un centro de datos queda fuera de servicio, el sistema de alarma, el ticketing, la automatización DR, el pipeline de auditoría y el equipo de aplicación necesitan saberlo. Sin esa conexión, el GTM toma la decisión mientras el resto de la cadena operativa de la organización se entera demasiado tarde.
Resolver esto con una capa de orquestación separada es posible, pero significa un nuevo servicio, nuevas credenciales, nueva monitorización y un nuevo punto de fallo. El health check ya corre dentro del GTM; la propagación de los cambios de estado a sistemas externos debería gestionarse desde la misma plataforma.
En el lado del reenvío DNS, el problema es similar. Algunos dominios pertenecen al DNS interno, algunos a un resolver externo, algunos a la zona autoritativa propia de TR7. Cuando un forwarder simple envía todo a un único destino, el split-DNS, las zonas internas, los dominios de partner y los comportamientos de geo-routing entran en conflicto.
Si se pierde la información ECS, el problema se agrava. Las decisiones basadas en geo y topología dependen del contexto de red del cliente; si el forwarder descarta ese contexto, el routing geográfico upstream puede hacerse contra la ubicación equivocada. Un forwarder no debería limitarse a llevar la consulta — también debería preservar el contexto de decisión.
Triggers y Forwarders de TR7 GTM atan los cambios de estado de health-check a cadenas de acción HTTP/HTTPS u Oracle DB, y hacen que el reenvío DNS sea operativamente manejable mediante reenvío selectivo por dominio, reenvío de zona a localhost y pass-through de ECS.
Nuestro enfoque
TR7 diseña el GTM no solo como un motor DNS que responde consultas, sino como una capa de operaciones activa que reacciona al estado de salud y reenvía las consultas DNS según el contexto.
Un cambio de estado de health-check inicia la cadena de triggers
Cuando cambia el estado base del escenario HC, pueden ejecutarse las acciones turn o return. Cuando el escenario se activa, triggerTurnActions se ejecuta en orden; cuando vuelve a la normalidad, triggerReturnActions se ejecuta en orden.
Los triggers HTTP y HTTPS pueden validar contenido de respuesta
Los triggers HTTP/HTTPS se definen con método, URI, cabeceras, cuerpo, códigos de estado esperados y timeout. El cuerpo de la respuesta puede validarse con una comprobación JSONata o de contenido básica para determinar si la acción tuvo éxito.
Los triggers Oracle DB ejecutan escenarios de base de datos
Los triggers Oracle operan con una cadena de conexión y un array de pasos de escenario. Los pasos wait y executeCmd pueden ejecutar comprobaciones o acciones contra la base de datos; pueden verificarse conteos de filas esperados o valores de texto esperados.
El forwarder DNS proporciona routing por dominio y preservación de ECS
El forwarder puede enviar dominios específicos a destinos DNS específicos; puede definirse un destino por defecto para el dominio raíz. El pass-through de ECS preserva el contexto de subred del cliente para que las decisiones de geo-routing no se rompan.
Capacidades
Triggers y Forwarders del GTM reúnen las acciones de health-check, la validación HTTP/HTTPS y Oracle, los flujos de triggers encadenados y el reenvío DNS selectivo en un único modelo de gestión.
Los triggers HTTP se configuran con método, URI, cabeceras y cuerpo
Un trigger HTTP se define con dirección de destino, puerto, método de petición, URI, lista de cabeceras y cuerpo de petición. Una lista de códigos de estado esperados determina si la llamada tuvo éxito. Un timeout limita las llamadas a sistemas externos de larga duración. Objetivos basados en HTTP como runbooks DR, endpoints de auditoría o sistemas de alarma pueden todos dispararse mediante este modelo.
Una acción de disparador que ejecuta algo más que un cambio de DNS
Un disparador GTM no se limita a dirigir nombres. La misma decisión de salud que mueve el DNS puede ejecutar la acción asociada — incluido un switchover de Oracle Data Guard — de modo que la base de datos sigue al tráfico en lugar de esperar una segunda decisión de un segundo equipo. Lo que si no sería una llamada puente sobre quién va primero se convierte en un único movimiento automático y registrado: disparador, acción y resultado en el mismo registro de auditoría.
Los triggers HTTPS hacen llamadas seguras con control de validación de certificado
Un trigger HTTPS aplica el mismo modelo de petición que HTTP, sobre TLS. El flag verifyCertificate determina si se valida el certificado del destino. Se recomienda mantener la validación de certificado habilitada en producción. Este patrón se usa para entregar cambios de escenario del GTM a sistemas de acción externos seguros.
La comprobación de contenido JSONata hace flexible la validación del cuerpo de respuesta
Las respuestas de los triggers HTTP/HTTPS pueden parsearse como JSON o XML y validarse con una expresión JSONata. El contexto de la expresión incluye body, bodyRaw, headers y status. Por ejemplo, aunque el sistema de runbook externo devuelva 200, puede comprobarse por separado un campo success=true dentro del cuerpo de respuesta. Esto habilita una validación de trigger más robusta que no se basa solo en el código de estado.
La comprobación de contenido básica proporciona validación simple por subcadena
Cuando no se necesita JSONata, puede usarse una comprobación de contenido básica. Se prueba que el cuerpo de la respuesta contenga una cadena específica usando semántica de .includes(). Esto es suficiente para integraciones pequeñas, sistemas heredados o endpoints que devuelven una respuesta de salud simple. Los operadores pueden validar rápidamente sin escribir una expresión compleja.
Los triggers Oracle DB ejecutan conexiones a base de datos y pasos de escenario
Un trigger Oracle se conecta a la base de datos con un usuario, contraseña y cadena de conexión. Los pasos de escenario pueden incluir operaciones wait y executeCmd. Pueden verificarse conteos de filas o valores de texto esperados desde executeCmd. Este modelo se usa para validar de forma cruzada el estado de base de datos de la aplicación o para ejecutar acciones controladas en el lado de la base de datos.
El encadenamiento de triggers ejecuta múltiples acciones en secuencia
Los arrays triggerTurnActions y triggerReturnActions ejecutan múltiples IDs de trigger en orden. Si una acción falla, la cadena se rompe y las acciones posteriores no se ejecutan. Esto evita que pasos dependientes del runbook avancen sin control. Pueden construirse así flujos como escribir primero a un endpoint de auditoría y luego iniciar un job DR.
Las direcciones turn y return manejan las transiciones de escenario por separado
turn representa el momento en que el escenario se activa; return representa el momento en que se desactiva y vuelve a la normalidad. Pueden definirse una lista de triggers y una condición separadas para cada dirección. Pueden dispararse acciones distintas durante el failover y durante la recuperación. Esta separación permite un diseño más limpio de los flujos operativos.
La limpieza de triggers activos evita colisiones entre procesos antiguos
Cuando llega una nueva clave de grupo, los procesos de trigger antiguos pueden detenerse. El ciclo de vida del trigger se rastrea con entradas de log started, succeeded y failed; tras un breve retraso el evento activeTrigger se limpia. Este comportamiento reduce la posibilidad de que acciones antiguas colisionen con un nuevo flujo cuando se producen cambios de estado de salud en sucesión rápida. El servicio principal permanece aislado del fork del trigger.
La ejecución de triggers se confina al nodo maestro
En un clúster, los triggers se ejecutan solo en el nodo maestro. Otros nodos que ven el mismo cambio de estado de salud no vuelven a disparar la acción externa. Esto evita el doble disparo de acciones webhook o DB. El comportamiento del clúster se vuelve más determinista.
El forwarder PowerDNS Recursor se ejecuta como un proceso separado en su propio puerto
La capa forwarder se posiciona como un proceso recursor separado. Recibe consultas DNS sobre el rango forwarderInnerPort y las reenvía a los destinos upstream definidos. El comportamiento de DNS autoritativo y de reenvío de recursor se desacopla. Esta separación permite a TR7 gestionar sus propias zonas y la resolución DNS externa de forma controlada dentro de la misma arquitectura.
El reenvío selectivo por dominio define un destino distinto por dominio
La lista domainBasedForwarding permite dirigir dominios específicos a direcciones DNS específicas. Los dominios internos pueden ir al DNS corporativo; otras consultas pueden ir al resolver upstream por defecto. Este diseño importa para arquitecturas split-DNS y DNS híbridas. Va más allá de un forwarder grueso que envía cada consulta a un único destino.
El pass-through de ECS preserva el contexto del cliente para decisiones geo
El forwarder pasa la información ECS a los resolvers upstream para que puedan tomar decisiones con contexto de subred del cliente. El comportamiento de ECS se controla mediante los ajustes ecs-ipv4-bits, ecs-add-for y allow-list. Este contexto es crítico para decisiones upstream basadas en geo o topología. Si se descarta el ECS, el routing geográfico puede hacerse contra la ubicación equivocada del resolver.
Profundidad operativa
Los triggers GTM y el forwarder se operan junto con el comportamiento de timeout, el rastreo del ciclo de vida, el aislamiento de procesos hijos, la prioridad de parseo, el orden de zonas de reenvío y las líneas de metadatos.
Comportamiento de timeout del trigger
El timeout por defecto para un trigger HTTP puede ser de 120 segundos. Un trigger Oracle puede correr más tiempo dependiendo de su propio procesamiento. El proceso global del trigger puede limitarse a 24 horas — un límite superior importante para runbooks largos o escenarios de base de datos multietapa.
Comportamiento de reintento
No hay reintento automático en la cadena de triggers. Si un trigger falla, la cadena se rompe y las acciones posteriores no se ejecutan. Los sistemas destino deberían diseñarse por tanto para ser idempotentes y fiables.
Logging del ciclo de vida del trigger
Los triggers se registran con estados started, succeeded y failed. Estos registros muestran qué acción se ejecutó durante un evento de failover o recuperación. El estado de trigger activo se limpia tras un breve retraso.
Ejecución en proceso separado
La ejecución de triggers puede correr como un proceso hijo separado. Este modelo evita que el servicio principal del GTM se vea afectado por llamadas externas o operaciones de BD de larga duración. Un trigger que falla no derriba el servicio principal.
Prioridad de parseo de respuesta
El cuerpo de la respuesta HTTP se parsea primero como JSON, luego como XML, según el content type. Si ninguno tiene éxito, se usa un fallback a cadena bruta. La expresión JSONata se evalúa contra este contexto.
Orden de zonas de reenvío
Las líneas forward-zones-recurse se producen en un orden definido. La primera definición de reenvío por dominio se escribe como línea primaria; las definiciones posteriores se escriben como líneas adicionales. Este orden importa para la aplicación limpia del comportamiento de reenvío selectivo.
Metadatos del forwarder
El campo forwarder.metaData lleva líneas adicionales de configuración del recursor. Proporciona un punto de extensión para ajustes personalizados de caché, política u operativos. Las líneas de metadatos en uso deben validarse cuidadosamente.
Cuándo utilizarlo
Alarma webhook cuando cae el centro de datos primario
Cuando el escenario de health-check se activa, se dispara un trigger HTTP POST. El sistema de alarmas o de gestión de incidentes recibe la notificación de caída del centro de datos. La decisión de failover DNS se hace visible para el sistema operativo externo en el mismo momento.
Lanzamiento automático de runbook cuando se activa el escenario DR
Cuando se activa un escenario DR, un trigger HTTPS puede iniciar un job en la plataforma de automatización. El primer trigger crea un registro de auditoría; el segundo trigger ejecuta el job de levantamiento DR. Si la cadena de triggers falla, el siguiente paso no avanza sin control.
Escribir cambios de health-check en un endpoint de auditoría
En cada evento turn y return, un trigger HTTP puede enviar un registro de evento al endpoint de auditoría. La información sobre qué zona, qué escenario y a qué hora ocurrió el cambio se envía al sistema de logs externo. Las decisiones del GTM se vuelven auditables.
Validación cruzada del estado de la base de datos de aplicación con un trigger Oracle
Cuando un heartbeat de aplicación falla, un trigger Oracle puede ejecutar una comprobación independiente en BD. Si se devuelve el conteo de filas esperado o el valor de texto esperado, el evento se valida de forma cruzada. Esto produce una señal de decisión más fuerte sin depender únicamente del resultado del health-check HTTP.
Reenvío de consultas de dominios internos al DNS corporativo
Dominios como internal.example.com pueden reenviarse a destinos DNS corporativos mediante domainBasedForwarding. Otras consultas van al DNS upstream por defecto. Las zonas autoritativas propias de TR7 pueden reenviarse al proceso DNS local vía localhost.
Usar un forwarder selectivo en una arquitectura DNS split-horizon
Los clientes internos pueden resolver dominios de aplicación internos a través del recursor corporativo mientras los clientes externos reciben respuestas autoritativas de TR7 GTM. El reenvío selectivo y el pass-through de ECS usados juntos desacoplan el comportamiento de resolución interna y externa. La arquitectura DNS no queda bloqueada en un reenvío de dirección única.
Preguntas frecuentes
¿Qué tipos de trigger soporta el GTM?
¿Qué ocurre cuando una cadena de triggers falla en una acción?
¿Qué nodo ejecuta los triggers en un clúster?
¿Cómo preserva el forwarder DNS la información ECS?
¿Cómo se configura el reenvío selectivo por dominio?
¿Cómo funciona la validación de respuesta de los triggers HTTP/HTTPS?
Conecte las decisiones de failover del GTM con sus sistemas externos
Cadenas de trigger HTTP/HTTPS y Oracle DB, reenvío DNS selectivo y un recursor consciente de ECS. Hagamos un recorrido en vivo en su propio entorno.