O round-robin clássico de DNS distribui endereços IP sob o mesmo registro de forma aproximadamente igual. Esse modelo pode ser adequado para compartilhamento simples de carga, mas não fornece o controle exigido para rollouts de nova release, testes A/B, cutovers blue/green ou migrações de data centre. As equipes de operação tipicamente querem enviar apenas 5 % do tráfego a um novo destino e deixar o resto no sistema existente.
Sem ponderação no nível DNS, a divisão de tráfego precisa ser resolvida na camada de aplicação ou em uma camada separada de divisão de tráfego. Isso significa arquitetura adicional, monitoramento adicional, gerenciamento adicional de certificados e pontos de falha adicionais. Quando a decisão pode, em vez disso, ser tomada na resposta DNS, o cliente é direcionado ao destino certo desde a primeira consulta.
Cenários de manutenção e drain também são pouco precisos quando tratados por exclusão de registros. Remover um IP de um registro DNS é efetivo para novas consultas, mas não atende à necessidade de reduzir gradualmente a parcela de tráfego ou retirar um alvo de rotação de forma controlada. O comportamento do cache do cliente e dos resolvers intermediários durante a janela de TTL também precisa ser considerado.
O modelo correto é atribuir um peso separado a cada registro DNS e escolher o algoritmo para o cenário. O round-robin ponderado se adequa a distribuição equilibrada e ordenada; o aleatório ponderado fornece seleção estatística baseada em percentual. Um peso de 0 coloca o alvo em modo drain efetivo, removendo-o de novas respostas DNS.
O TR7 Weighted DNS entrega distribuição de tráfego controlada na camada DNS por meio de pesos por registro, round-robin ponderado, aleatório ponderado, recarregamento ao vivo da configuração e comportamento de drain com peso=0.
O TR7 tira a resposta DNS de uma lista estática de registros e a transforma em uma decisão de distribuição de tráfego governada por valores de peso e algoritmos selecionáveis.
Um peso inteiro é definido para cada IP ou membro de registro. O algoritmo round-robin ponderado usa esses pesos para distribuir respostas DNS proporcionalmente entre o pool.
O algoritmo aleatório ponderado realiza uma seleção aleatória proporcional ao peso em cada consulta. Em volumes elevados de consultas, a distribuição observada converge para as razões de peso definidas.
As mudanças de peso entram no pipeline de recarregamento ao vivo da configuração e novas consultas recebem imediatamente a distribuição atualizada. Como respostas previamente cacheadas vivem até seu TTL expirar, o planejamento de TTL é essencial em cenários de transição rápida.
Quando o peso de um registro é definido como 0, ele é removido da lista ativa de candidatos. Esse comportamento fornece drain controlado para manutenção, rollback ou descomissionamento de um data centre.
O Weighted DNS gerencia valores de peso por registro em conjunto com seleção de algoritmo, atualizações ao vivo, integração com topologia e cenários de manutenção.
No TR7, cada membro de registro pode ter seu próprio valor de peso. Esse valor determina sua parcela relativa na distribuição de tráfego — pesos de 5 e 2 visam uma razão aproximada de 5:2. Se um float é fornecido, ele é arredondado para inteiro antes do uso. O modelo torna direto dar uma parcela maior a alvos de maior capacidade e uma menor a alvos de teste.
O round-robin ponderado seleciona registros em rotação conforme suas razões de peso. É a escolha preferida quando se espera distribuição equilibrada e o uso sequencial dos registros é aceitável. É um algoritmo prático para canary releases, rollouts graduais e compartilhamento de tráfego proporcional à capacidade. Os operadores remodelam a distribuição simplesmente alterando os valores de peso.
O aleatório ponderado produz uma seleção aleatória proporcional ao peso em cada consulta DNS. Pequenos desvios podem aparecer em janelas curtas; em volumes elevados, a distribuição converge para as razões definidas. É bem adequado para testes A/B e roteamento experimental de tráfego. Novos alvos com peso baixo podem ser testados com segurança dentro do mesmo pool de registros.
Quando os valores de peso mudam, a configuração do GTM entra no processo de reload ao vivo. Um mecanismo de debounce agrupa mudanças sucessivas rápidas, reduzindo re-renderizações desnecessárias; a latência típica do reload ao vivo é de cerca de 3 segundos. Novas consultas DNS recebem a distribuição de pesos atualizada. Respostas previamente cacheadas em caches de cliente e resolver permanecem até seus TTLs expirarem.
Quando um peso DNS muda, o sistema atualiza novas respostas imediatamente; entretanto, respostas DNS já emitidas vivem em caches intermediários até seus TTLs expirarem. Para cenários de canary, blue/green ou rollback rápido, o TTL deve ser mantido baixo. Valores na faixa de 5-60 segundos permitem que as transições entrem em vigor mais rapidamente. Um TTL maior é apropriado durante períodos estáveis de operação.
Quando o peso de um IP ou membro de registro chega a 0, esse alvo é removido de novas respostas DNS. Isso torna possível drenar um registro para manutenção sem excluí-lo. Respostas em cache existentes continuam usando a resposta antiga até seus TTLs expirarem; novas consultas não recebem mais o alvo. É um método controlado e reversível para manutenção, rollback ou descomissionamento de data centre.
No TR7, a distribuição não é confinada a um único nível de IP — o grupo de data centre e a lógica de peso de membro de registro podem trabalhar em combinação. O data centre ou grupo candidato apropriado é selecionado primeiro; os registros dentro desse grupo são, então, distribuídos por peso. Esse modelo ajuda a considerar tanto capacidade quanto localização no gerenciamento global de tráfego. Em grandes implantações, a distribuição fica mais em camadas e gerenciável.
Quando a seleção baseada em geo ou topologia está em uso, o grupo candidato apropriado é identificado primeiro. A distribuição por peso é, então, aplicada dentro desse conjunto candidato. Usuários europeus, por exemplo, são roteados para o grupo de data centre europeu, enquanto os IPs dentro desse grupo são ponderados. A decisão de topologia e a decisão de peso são aplicadas sequencialmente sem interferir entre si.
Registros que não exigem distribuição ponderada podem usar round-robin clássico ou seleção aleatória. O round-robin distribui registros igualmente; o random seleciona aleatoriamente. Esses algoritmos são suficientes para cenários simples e são gerenciados pelo mesmo modelo de registro, então mudar para algoritmos ponderados não exige mudanças estruturais. Os operadores escolhem o comportamento de distribuição apropriado para cada registro DNS.
O algoritmo closest está disponível para registros A e AAAA que exigem seleção por proximidade de IP. Diferentemente da distribuição ponderada, ele foca em selecionar o alvo mais próximo ou mais apropriado para o cliente. Topologia, closest e peso podem servir como camadas distintas de decisão no gerenciamento global de tráfego. O resultado é uma resposta DNS consciente do contexto, em vez de meramente aleatória.
O DNS Ponderado é operado em conjunto com formato de peso, seleção de algoritmo, latência de reload ao vivo, impacto de TTL e comportamento de seleção de registro.
O peso é definido como um número e usado como inteiro. Se um float é fornecido, ele é arredondado. As razões de peso representam parcelas relativas entre registros, não percentuais absolutos.
Os algoritmos round-robin ponderado e aleatório ponderado usam a lista de registros em conjunto com um mapa de pesos. Valores de peso indexados são gerados para cada registro. Essa estrutura é avaliada pela função seletora durante a geração da resposta DNS.
As alterações de configuração passam por um processo de reload ao vivo com debounce. O valor típico de debounce é de 3 segundos; um limite máximo de espera pode ser aplicado durante rajadas de mudanças sucessivas rápidas. Esse comportamento reduz operações de re-render frequentes desnecessárias.
Uma alteração de peso entra em vigor em novas consultas DNS. Clientes ou resolvers que já receberam uma resposta anterior continuam usando o registro cacheado até seu TTL expirar. Por essa razão, o TTL é um parâmetro operacional tão importante quanto o peso ao planejar transições.
O peso 0 é usado para remover um registro da lista ativa de candidatos. Isso permite executar manutenção ou migração sem excluir totalmente o registro. Para restabelecer o registro, defina o peso de volta para um valor positivo.
Em certos cenários, um número pode ser fornecido em vez de um algoritmo para selecionar os primeiros N registros da lista de candidatos. Esse comportamento é útil para limitação simples e determinística de registros. É uma opção prática para casos especiais onde a distribuição ponderada não é necessária.
O IP da nova release recebe peso baixo; a release atual recebe peso alto. A nova versão começa em cerca de 5 % do tráfego; conforme as métricas parecem saudáveis, o peso é elevado incrementalmente. Se um problema aparece, a nova release é drenada definindo seu peso como 0.
Enquanto o ambiente blue está ativo, o ambiente green é testado em peso baixo. No cutover, o peso de blue é reduzido a 0 e o green se torna o único alvo ativo. Quando é necessário um rollback, os pesos são invertidos para retornar ao ambiente anterior.
Duas landing pages ou duas variantes de serviço são definidas com registros de IP separados. Os pesos podem ser definidos 1:1 para um teste equilibrado ou 9:1 para um experimento limitado. Com base na análise de resultados, a razão de tráfego é ajustada no nível DNS.
O data centre antigo começa com peso alto; o novo data centre é introduzido com peso baixo. A equipe de operações desloca o tráfego para o novo centre por meio de uma redução em etapas como 100 → 80 → 50 → 20 → 0. Quando o TTL é mantido baixo, o impacto de cada etapa é observado mais rapidamente.
Backends de maior capacidade recebem um peso maior; recursos mais restritos recebem um peso menor. A distribuição de tráfego se torna proporcional à capacidade do servidor. Os operadores remodelam a distribuição puramente atualizando os valores de peso.
O peso do backend que entra em manutenção é reduzido a 0. Novas consultas DNS não roteiam mais para esse alvo; respostas previamente cacheadas continuam a ser usadas até seus TTLs expirarem. Quando a manutenção termina, o peso é restaurado para um valor positivo e o backend volta a entrar em serviço.
Pesos por registro e reload ao vivo para canary releases, cutovers blue/green, testes A/B e migrações de data centre. Vamos percorrer uma configuração ao vivo no seu ambiente.