O padrão GSLB clássico é assim: monitora-se um endpoint; quando fica não saudável, as respostas DNS são deslocadas para o backup; quando volta a ficar saudável, retornam. Implementações dos principais fornecedores de GSLB tratam ambas as transições como o inverso da mesma condição.
A realidade em produção não é simétrica. Comutar para um backup é uma jogada defensiva executada sob pressão; retornar ao primário é uma jogada ofensiva executada com confiança. As condições, as janelas de espera, as aprovações do operador e os gatilhos que devem ser disparados são diferentes em cada direção.
Exemplos: fast-in / slow-out — failover ao primeiro erro detectado para proteger o usuário, mas exigindo 15 minutos de saúde limpa antes de retornar para evitar flapping. Conservador para entrar / rápido para sair — exigir três falhas consecutivas antes de iniciar o failover, mas retornar imediatamente quando o primário se recuperar para cumprir os compromissos de RPO/RTO. Auto-in / manual-out — o failover é automatizado, mas o caminho de retorno exige confirmação do SRE após revisão do runbook.
Nenhum desses casos é expressível em um cenário unidirecional. O operador ou escolhe uma direção e convive com a política errada na outra, ou amarra scripts customizados frágeis que se desviam da fonte da verdade do GSLB.
Os cenários bidirecionais do TR7 GTM permitem que ativação e desativação carreguem condições independentes, verificações de gating independentes e ações de gatilho independentes — exatamente a estrutura de política que seu runbook de resposta a incidentes já pressupõe.
Um cenário é uma máquina de estado nomeada e reutilizável com duas direções. Cada direção é definida por uma expressão de condição combinada e um conjunto de gatilhos; as duas direções não precisam ser inversas.
Uma expressão de condição combinada avalia os health-checks subjacentes. Quando retorna verdadeira, o cenário é ativado. Gatilhos opcionais disparam ações (webhooks HTTP/HTTPS, consultas Oracle) e uma verificação de gating opcional confirma se o gatilho deve prosseguir.
Uma expressão de condição combinada separada avalia um conjunto separado de health-checks. O caminho de desativação pode ser o inverso da ativação, ou pode exigir estabilidade adicional, sondas adicionais ou gatilhos inteiramente diferentes.
As condições não são booleanos simples — são grupos de resultados de health-check unidos por AND dentro de um grupo e OR entre grupos, com negação opcional. A mesma DSL que conduz a lógica de regras de tráfego no ADC também conduz a avaliação dos cenários aqui.
Um cenário é definido uma vez e referenciado pelo nome a partir de registros DNS, configurações de disaster-recovery e políticas de failover entre DCs. Os operadores não reescrevem a mesma lógica em múltiplos lugares.
Cenários bidirecionais são a base da política de failover e recuperação do TR7 GTM.
A condição de ativação é construída a partir dos resultados de health-check em um ou mais perfis. Grupos unem checks com AND; múltiplos grupos se unem com OR. Cada check individual pode ser negado. Os operadores expressam condições como "(API está ativa AND banco de dados está ativo) OR (caminho de failover A está ativo AND caminho de failover B está ativo)" sem scripts.
A condição de desativação é independente da ativação. Os operadores expressam condições como "o primário está saudável há 15 minutos AND a latência está abaixo do limite", enquanto a ativação pode ter sido apenas "o primário está fora do ar".
Gatilhos de ativação e gatilhos de desativação são conjuntos selecionáveis separados. Um evento de ativação pode notificar o SRE de plantão; um evento de desativação pode notificar o SRE, executar uma transação sintética e emitir um webhook para o sistema de implantação.
Uma condição de gating opcional é executada antes dos gatilhos de cada direção. Se a verificação de gating retornar falsa, a transição de estado ainda acontece, mas os gatilhos não disparam. Caso de uso: as transições de estado ocorrem automaticamente, mas as notificações externas só disparam em horário comercial.
Cada direção suporta três modos selecionáveis pelo operador. Auto segue a expressão de condição. On força a direção a ativar independentemente das condições (override manual). Off desabilita a direção inteiramente (por exemplo, desativar failback durante uma janela de manutenção).
Quando dois data centers são definidos, o TR7 GTM gera automaticamente quatro cenários por par: from-active, to-active, from-backup, to-backup — cada um com lógica de condição apropriada baseada em checks de acesso WAN, acesso LAN e alcançabilidade à internet. Os operadores podem usar os cenários auto-gerados como estão, customizá-los ou criar os seus do zero.
Os registros DNS podem ter seu estado saudável/não saudável conduzido por um cenário em vez de um booleano estático ou um único health-check. O campo `cond` por registro aceita uma referência a um cenário: quando o cenário é ativado, o registro é excluído das respostas; quando é desativado, o registro retorna.
Registros de disaster-recovery podem especificar `drCond` — um cenário que determina quando o conjunto de registros DR substitui o conjunto primário nas respostas. A avaliação do cenário DR é bidirecional, suportando failover e failback controlados.
Os gatilhos disparam como chamadas HTTP/HTTPS (URI, método, cabeçalhos, corpo, códigos de status esperados e consulta de correspondência de conteúdo customizáveis) ou chamadas a banco de dados Oracle (SQL configurado). Os operadores conectam ativações de cenário a pipelines existentes de gestão de incidentes, implantação ou auditoria.
Toda mudança de estado de cenário é registrada: qual direção disparou, quais condições avaliaram como verdadeiras/falsas, quais gatilhos executaram, qual verificação de gating passou. A revisão pós-incidente reconstrói a sequência exata de decisões automatizadas sem arqueologia manual de logs.
Os cenários são operados em conjunto com definições de health-check, configurações de gatilhos, vinculações a registros DNS e configurações de disaster-recovery.
Dentro de um grupo de condição, todos os checks listados precisam avaliar como verdadeiros (AND). Entre grupos, qualquer grupo avaliando como verdadeiro é suficiente (OR). O sufixo `!` em um ID de check o nega. A estrutura de agrupamento é simétrica para ativação e desativação; cada direção tem seu próprio conjunto de grupos.
As condições referenciam health-checks pelo ID. Perfis de health-check definidos pelo usuário e checks auto-gerados de pares de DC compartilham o mesmo espaço de IDs. Os operadores misturam checks manuais e automáticos no mesmo grupo de condição.
Quando a ativação é forçada para on (override manual), a avaliação de desativação normalmente continua — os operadores podem ativar manualmente e deixar que a condição de desativação decida quando restaurar. Forçar ambas as direções para on cria um estado travado e é registrado como aviso de configuração.
Os gatilhos disparam com uma carga útil estruturada contendo ID do cenário, direção, timestamp da avaliação e o snapshot da configuração no momento do disparo. Falhas de gatilho (HTTP não-2xx, erro Oracle) são registradas e opcionalmente repetidas conforme o perfil do gatilho.
Os cenários são avaliados a cada mudança de estado de health-check, não em um temporizador de polling. A primeira mudança de estado que cruza um limite de ativação ou desativação dispara a transição. O custo de avaliação permanece baixo porque as condições referenciam estados de saúde pré-computados.
Os operadores enxergam o estado atual de cada cenário (ativado / desativado), o horário da última transição, o último resultado de avaliação para cada grupo de condição e os resultados dos gatilhos. O dashboard destaca transições travadas e overrides conflitantes.
Ative o failover no primeiro erro detectado para proteger o usuário. Desative apenas após 15 minutos de saúde primária limpa para evitar flapping. Condições diferentes, tempos diferentes — o mesmo objeto de cenário.
O failover é automatizado; o caminho de retorno exige confirmação do SRE. A direção de desativação é definida como off; um operador a inverte manualmente para on após a revisão do runbook. A ativação continua a ser avaliada automaticamente.
O failover DC A → DC B dispara um webhook HTTP para o sistema de gestão de incidentes. O failback DC B → DC A dispara o mesmo webhook mais uma chamada ao sistema de implantação para reaquecer caches. Os gatilhos em cada direção são independentes.
Use o gatilho Oracle para consultar um banco de dados antes do failover — por exemplo, confirmar que o banco de backup foi sincronizado via log shipping. O resultado do gatilho governa a transição de estado real.
Percorra um cenário bidirecional construído sobre seu próprio runbook: fast-in / slow-out, failback manual, conjuntos de gatilhos assimétricos — sua política, não o padrão da plataforma.