No modelo tradicional de DNS primário/backup, uma interrupção de data center é detectada, a equipe de operações recebe um alerta, o registro de zona é atualizado, o serviço é recarregado e os clientes esperam que a nova resposta DNS se propague. Essa cadeia parece simples em um runbook; em um incidente real, os atrasos introduzidos por tomada de decisão, controle de acesso, aprovação e execução esticam o RTO consideravelmente.
Em muitas organizações, health checking e DNS operam como sistemas separados. Uma ferramenta de monitoramento vê que um DC está inalcançável, mas o servidor DNS continua respondendo com os mesmos endereços IP. A ponte entre eles é tipicamente um script, um runbook manual ou uma camada de automação separada. Essa lacuna se torna o elo mais fraco no momento do failover.
O failback carrega risco equivalente. Se um DC oscila para dentro e para fora rapidamente, a resposta DNS pode mudar repetidamente — os clientes ficam dispersos entre diferentes data centers e o tráfego pode retornar antes que a sincronização de estado esteja completa. Uma lógica simples de "remova quando cair, readicione quando subir" não basta.
O modelo correto avalia a saúde do DC por meio de lógica booleana de cenário, reduz o risco de flap com limiares de sucessos/falhas consecutivos e torna a resposta DNS a saída natural dessa decisão. O mesmo modelo deve também cobrir cutover manual para manutenção planejada, uma resposta fail-safe quando todos os DCs estão não saudáveis e condições de DR.
O DC Failover do TR7 entrega esse modelo: atualiza automaticamente a resposta DNS quando um cenário de saúde de DC muda e amarra todo o processo de failover ao TTL do DNS e aos parâmetros de saúde definidos pelo operador.
O TR7 implementa decisões de DC failover por meio de cenários de saúde, lógica de condição booleana, proteção contra flap e um mecanismo de cutover manual.
Quando o estado de health check de um DC muda, o cenário associado é reavaliado. Se o resultado do cenário muda, os registros DNS relevantes são regenerados e o DC não saudável é removido da resposta.
Grupos de condição se combinam com lógica AND; grupos se combinam com lógica OR. Uma condição negativa também pode ser definida para cada health check, permitindo cenários inversos como "ative este registro quando este check estiver não saudável".
Enquanto um DC está em transição, o resultado da avaliação anterior pode ser preservado. Esse comportamento ajuda a evitar que flutuações curtas de up/down mudem continuamente a resposta DNS.
Durante uma manutenção planejada, um operador pode colocar um DC offline com o modo de manutenção. Mesmo que o DC pareça saudável, ele pode ser excluído da resposta DNS para que o tráfego seja direcionado a outro DC.
O DC Failover é a camada de failover do GTM que gerencia automaticamente respostas DNS entre múltiplos data centers com base no estado de saúde.
O TR7 pode avaliar registros de DC como uma cadeia de prioridade ordenada pela posição no array. Quando o DC primário está não saudável, o secundário assume; quando o secundário também está não saudável, o terciário entra em cena — e cadeias mais longas são igualmente suportadas. O modelo de código não é teoricamente limitado a dois endpoints. Essa estrutura simplifica o desenho de continuidade em múltiplos estágios em ambientes financeiros, governamentais e SaaS de larga escala.
O TR7 pode avaliar sinais de saúde no nível do DC: wanAccess, lanAccess, access, internet e maintenanceMode. Alcançabilidade WAN, alcançabilidade LAN, estado geral de acesso, acesso à internet e estado manual de manutenção são modelados separadamente. Um DC é, portanto, avaliado em múltiplas dimensões de acesso, não apenas em um resultado de ping. A resposta DNS reflete um quadro mais realista da saúde do DC.
requiredSuccess e requiredFailure determinam quantos resultados consecutivos são necessários antes de um DC ser declarado up ou down. Esse modelo evita mudanças desnecessárias de DNS causadas por perda momentânea de pacotes, breves interrupções de rede ou lentidão pontual de serviço. Os operadores podem usar limiares mais apertados para serviços críticos e mais tolerantes para links mais ruidosos. O RTO é planejado em conjunto com esses limiares e o intervalo de check.
O modo noResponse mantém um DC passivo silencioso sob condições normais. O modo onlyNew pode impedir que um DC fora do ar há muito tempo responda com dados obsoletos quando voltar a subir. Esse comportamento garante que, durante o failover, apenas DCs no estado correto produzam respostas DNS — não apenas aqueles meramente alcançáveis. É uma camada de proteção importante em ambientes onde o risco de dados obsoletos preocupa.
O modo DR por registro permite que registros específicos se tornem ativos apenas quando uma condição DR for atendida. O cenário drCond ou a flag drIfNoRecords aciona o registro DR quando alvos primários e secundários estão esgotados. Esse modelo mantém endereços IP de disaster-recovery remoto fora das respostas DNS normais, deixando-os em standby para situações críticas. A estratégia DR fica controlada no nível do DNS.
Se nenhum DC está saudável, uma resposta pode ser gerada a partir do array fallbackRecords. Esses registros podem apontar para uma página de manutenção, um endpoint estático de emergência ou um serviço alternativo de recuperação. O comportamento FailSafe garante que o DNS produza uma resposta controlada de último recurso em vez de não retornar nada. Os operadores definem esses registros conforme o plano de crise da organização.
O TR7 pode armazenar dados de estado de health check e de cenário localmente em arquivo. Após uma reinicialização ou recarregamento do serviço, o estado anterior é restaurado para que a avaliação não comece do zero. Essa abordagem reduz oscilação desnecessária nas decisões de failover durante uma reinicialização transitória. É especialmente útil para manter consistência durante operações de manutenção que reiniciam o serviço GTM.
Listas de alvos wanAccess e lanAccess podem ser definidas por DC. Múltiplos alvos de acesso dão um quadro mais preciso da alcançabilidade externa e interna de um DC. Um problema transitório com um único alvo não necessariamente marca o DC inteiro como caído. Essa estrutura permite uma modelagem mais abrangente da saúde do data center.
Quando maintenanceMode é ativado, o DC relevante é conscientemente colocado offline. Isso é útil durante patches, janelas de manutenção, migrações ou testes controlados de DR. O operador pode remover o DC da resposta DNS — mesmo quando saudável — e redirecionar o tráfego para outro DC. Quando a manutenção termina, o modo é desativado e a avaliação normal recomeça.
O estado do DC pode ser expresso como ok, noInternet, noAccess, noWan ou noLan. Essa classificação mostra qual dimensão de acesso é problemática em vez de apenas dizer "caído". As equipes de operação podem distinguir mais rapidamente problemas de egress de internet, alcançabilidade WAN e alcançabilidade LAN. A razão por trás de uma decisão de failover fica mais legível.
Quando o estado de health check muda, o cenário associado pode ser reavaliado imediatamente. Os registros vinculados ao cenário entram no pipeline de regeneração de config dinâmica e a resposta DNS é atualizada. Esse comportamento reduz a necessidade de edições manuais de zona ou scripts externos. As alterações são agrupadas por um curto debounce para evitar regenerações repetidas desnecessárias.
Em um cenário de cluster HA, as escritas de config DNS são controladas pelo papel de master. Se o nó master falhar, o nó standby pode assumir o papel após um período de segurança definido. Esse modelo ajuda a evitar que dois nós produzam configs DNS diferentes simultaneamente. O comportamento do GTM permanece alinhado com o estado do cluster.
Uma operação de DC failover é planejada em conjunto com o intervalo de check, os limiares consecutivos, a estrutura de ID de HC, as condições de cenário, o pipeline de regeneração e os parâmetros de RTO.
accessPeriod define com que frequência os health checks de DC são executados. Pode ser configurado em segundos ou minutos. Um período menor proporciona detecção mais rápida; um período maior oferece uma avaliação mais quieta, com menos ruído.
requiredSuccess define quantos sucessos consecutivos são necessários antes de um DC ser considerado up. requiredFailure define quantas falhas consecutivas são necessárias antes de um DC ser considerado down. Esses dois valores estabelecem o equilíbrio entre velocidade de failover e proteção contra flap.
As listas wanAccess e lanAccess definem os alvos de acesso para um DC. Isso permite avaliar se um DC está alcançável não apenas do exterior, mas também da rede interna. A distinção é particularmente importante em cenários de roteamento entre DCs e híbridos.
Registros automáticos de HC seguem o formato `auto|
Condições dentro de um grupo se combinam com lógica AND; grupos se combinam com lógica OR. Essa estrutura suporta uma ampla gama de modelos de decisão, de simples verificações de primário-caído a cenários complexos de saúde de DC em múltiplas dimensões. Os operadores não ficam limitados a um único resultado de check.
Quando o estado de HC muda, o cenário é reavaliado, os registros vinculados são identificados e a regeneração de config dinâmica é disparada. O pipeline roda com um curto debounce para que mudanças sucessivas e rápidas sejam mescladas em uma única passada de regeneração. A resposta DNS é renderizada novamente conforme o estado de saúde atual.
O RTO depende de accessPeriod, da contagem de requiredFailure, da duração do debounce de regeneração e do comportamento de TTL do DNS no cliente. Em vez de afirmar um tempo único e fixo, a janela de failover deve ser planejada para atender aos requisitos do serviço. Serviços críticos se beneficiam de TTL menor e checks mais frequentes.
O DC1 é definido como primário e o DC2 como standby passivo. Quando o cenário de internet ou acesso para o DC1 falha, os registros do DC1 são removidos da resposta DNS e o DC2 passa a responder.
Instituições financeiras podem construir uma cadeia de failover sequencial DC1 → DC2 → DC3. Cada nível é avaliado por seu próprio cenário de saúde e um DC não saudável é automaticamente removido da resposta DNS.
Na janela de manutenção, o DC1 é colocado em modo de manutenção e o tráfego é direcionado ao DC2. Quando a manutenção termina, o modo de manutenção é desativado e a avaliação normal de saúde retoma.
Quando os DCs primário e secundário estão ambos não saudáveis, registros em modo DR podem ser ativados. Nesse cenário, o site remoto de disaster-recovery permanece passivo em condições normais e é adicionado à resposta DNS apenas quando as condições definidas forem atendidas.
Quando um DC que esteve fora do ar por um período prolongado volta a entrar em operação, pode não ser desejável que ele responda com dados desatualizados. O comportamento onlyNew mantém um DC desatualizado passivo, reduzindo o risco de publicar registros obsoletos.
O DC mais próximo é selecionado primeiro por país ou região, e se esse DC se tornar não saudável, o DC de standby é ativado. Esse modelo combina steering baseado em desempenho com decisões de continuidade em uma única configuração GTM.
Cenário de saúde, resposta DNS e cutover manual unificados em um único pipeline de decisão. Vamos percorrer uma configuração ao vivo com sua própria arquitetura de DC.