A seleção de DC por sinal único deixa de fora a pergunta que realmente importa.
A maioria das implementações de GSLB toma decisões de seleção de data center a partir de uma única classe de sinal. Distância geográfica é uma escolha comum; round-trip time medido pelos pontos de medição da plataforma é outra; consultas estáticas de topologia são uma terceira. Cada uma captura uma dimensão útil e ignora as outras.
A geografia ignora a carga — o data center mais próximo pode também ser aquele atualmente sob pressão de capacidade. A latência das sondas do GSLB ignora o usuário — o caminho de rede real do usuário não é o caminho que a sonda percorreu. A topologia estática assume que a rede não mudou desde que a configuração foi escrita.
Decisões em produção precisam das três visões ao mesmo tempo: a plataforma do DC está saudável? A aplicação no DC está, neste momento, performando? A rede do usuário até o DC está, neste momento, realmente boa? Cada visão tem sinais que as outras não podem substituir.
O TR7 GTM expõe as três classes de sinais — host, serviço, cliente — como entradas independentes para a seleção de DC, permitindo aos operadores descrever a política que realmente se ajusta à sua carga de trabalho.
Nossa abordagem
A seleção de DC é configurada por registro DNS. Os operadores escolhem qual origem de sinal usar, qual métrica específica dentro dessa origem, quantos DCs selecionar e como distribuir entre as escolhas.
Origem de host do DC — saúde no nível da plataforma
Cinco métricas medidas na plataforma do DC: CPU, memória, banda, status (composto up/down) e perda de pacotes. Útil quando a pressão na plataforma do DC é o sinal dominante para decisões de roteamento.
Origem de serviço — desempenho da aplicação
Oito métricas medidas por serviço: CPU, memória, banda, taxa de requisições, contagem de conexões, taxa de novas sessões, status e healthyBackends. Roteia o tráfego pelo que a aplicação está realmente fazendo, não apenas se o host está up.
Origem de cliente — caminho de rede até o requisitante
Quatro métricas medidas a partir do caminho de rede até o cliente requisitante: saltos, MOS (Mean Opinion Score), perda de pacotes e TTL. Captura a experiência do lado do usuário que as sondas do lado do DC não conseguem ver.
Seleção Pick-N com algoritmo de distribuição
`pickDcCount` escolhe quantos DCs retornar. `balanceAlgorithm` distribui entre os escolhidos — todos, top-N, round-robin, round-robin ponderado, aleatório, aleatório ponderado ou mais próximo.
Capacidades
Cada registro DNS em modo DC seleciona independentemente sua origem de sinal, critério e comportamento de distribuição.
Host do DC: cinco métricas no nível da plataforma
A origem de host do DC expõe cpu, mem, bw, status e packetLoss. Status é o estado composto de alcançabilidade/saúde calculado a partir dos pontos de acesso WAN e LAN do DC. Útil quando a capacidade no nível do host é o sinal dominante de roteamento.
Serviço: oito métricas no nível da aplicação
A origem de serviço expõe cpu, mem, bw, request, connection, session_new, status e healthyBackends. A contagem de healthyBackends é particularmente determinante — roteia o tráfego para o DC onde a aplicação tem mais capacidade funcional neste momento, e não apenas para o DC cuja plataforma está up.
Cliente: quatro medições de caminho de rede
A origem de cliente expõe hops (comprimento do caminho), mos (Mean Opinion Score para qualidade de tráfego VoIP/tempo real), packetLoss e ttl. Esses sinais são medidos contra a rede do cliente, capturando a experiência do usuário que as sondas de saúde no lado do DC não enxergam.
Seleção estática de DC para casos legados ou simples
O modo estático ignora a seleção multi-origem e atribui DCs com base em regras definidas pelo operador. Útil para registros DNS legados, roteamento orientado por compliance (DCs específicos para clientes específicos) e testes.
Expressão de critério definida pelo operador
O critério de seleção é controlado pelo operador: menor valor vence, maior valor vence, valor igual ao alvo ou valor difere por uma margem. A mesma DSL conduz a avaliação de critério nas três origens de sinal.
Contagem Pick-N para respostas multi-DC
`pickDcCount` tem padrão 1, mas pode ser definido como maior para retornar múltiplos DCs na resposta DNS. Isso permite verdadeiro load balancing multi-DC em vez de roteamento sempre-escolha-um — os clientes DNS recebem múltiplas respostas e o resolver ou stub do lado do cliente seleciona entre elas.
Nove algoritmos de distribuição de registros
Uma vez selecionados os DCs, os registros dentro de cada DC são distribuídos conforme `balanceAlgorithm`: all (retorna todos), top-1/2/3 (retorna os top N), round-robin, round-robin ponderado, aleatório, aleatório ponderado ou closest (proximidade ao requisitante). O algoritmo certo depende de você querer distribuição ampla, concentração top-N ou stickiness.
Roteamento por nome de serviço para DCs específicos de aplicação
Ao usar a origem de serviço, os operadores especificam o nome do serviço — diferentes aplicações rodando na mesma frota de DCs podem ter regras diferentes de roteamento. A contagem de healthyBackends para o serviço A e o serviço B pode conduzir escolhas separadas de DC.
Combinado com registros fail-safe
Se a seleção não retornar nenhum DC saudável, a lista fail-safe do registro fornece respostas de último recurso — IPs definidos pelo operador que são sempre retornados quando todos os sinais multi-origem falham. Evita NXDOMAIN como resposta final.
Seleção por registro — registros diferentes, origens diferentes
A seleção de DC é configurada por registro DNS. O mesmo domínio pode ter um registro A roteado por service.healthyBackends, um registro MX roteado por host.status e um CNAME roteado por client.packetLoss. Os operadores afinam cada registro à sua carga de trabalho.
Profundidade operacional
A seleção multi-origem trabalha em conjunto com definições de DC, cenários de health-check, algoritmos de DNS ponderado e registros fail-safe.
Cadência de coleta de sinais
Cada origem de sinal tem sua própria cadência de medição. As métricas de host e de serviço atualizam no ciclo de coleta de métricas do GTM (normalmente a cada 30-60 segundos). As métricas de cliente atualizam por sessão do resolver. Os operadores afinam a cadência por origem em relação à topologia de DCs.
Prioridade de origem quando critérios conflitam
A seleção usa uma origem por vez por registro. Quando os operadores querem que sinais de host condicionem sinais de serviço ("considere métricas de serviço apenas se o host estiver saudável"), eles vinculam um cenário baseado em host ao registro com origem de serviço. O encadeamento é explícito.
Fonte da verdade de healthyBackends
A contagem de healthyBackends é lida diretamente da camada de balanceamento de carga da aplicação em cada DC, e não aproximada por sondas externas. O número reflete o pool real de backends saudáveis por trás do serviço naquele momento.
Computação do MOS
O MOS é computado a partir de medições de qualidade de rede (jitter, perda de pacotes, latência) contra a rede do cliente requisitante. É mais preciso para sessões de cliente em andamento e converge em algumas janelas de medição para clientes novos.
Pick-N quando há menos DCs disponíveis
Se `pickDcCount` for maior do que a contagem de DCs saudáveis disponíveis, todos os DCs saudáveis disponíveis são retornados. A plataforma nunca inventa DCs falsos para atingir a meta de contagem — os operadores veem exatamente quais DCs reais eram elegíveis.
Interação do algoritmo com a seleção
Algoritmos de seleção e distribuição se compõem: a seleção escolhe os DCs elegíveis por critério; a distribuição determina como os registros dentro de cada DC são retornados. Um registro pode escolher 3 DCs por service.healthyBackends e depois retornar os registros dentro de cada DC por aleatório ponderado.
Quando usar
Roteie pela capacidade da aplicação, não apenas pela alcançabilidade do DC
A origem de serviço com o critério healthyBackends roteia o tráfego para o DC onde a aplicação tem mais capacidade funcional. Evita criar hot-spot em um DC cujo host está up mas cujos backends de aplicação estão degradados.
Roteie pela experiência de rede do cliente
A origem de cliente com o critério packetLoss roteia cada usuário para o DC com o caminho de rede mais limpo a partir da sua rede. Útil para VoIP, vídeo, jogos e aplicações em tempo real onde a qualidade do caminho importa mais do que a proximidade geográfica.
Balanceie a carga entre múltiplos DCs saudáveis
Combine pick-N (por exemplo, retornar os top 3 DCs) com distribuição aleatória ponderada para compartilhar o tráfego entre várias regiões saudáveis. Cada cliente DNS recebe múltiplas opções; resolvers e stubs naturalmente distribuem entre elas.
Seleção em camadas para cargas de trabalho de alto risco
Use um cenário baseado em host como gate ("o DC está saudável na plataforma") e um critério baseado em serviço como seletor ("o DC tem a maior contagem de healthyBackends entre os DCs gated"). Cargas críticas obtêm uma seleção em duas camadas sem script.
Perguntas frequentes
Como isso difere dos registros de topologia do F5?
Posso combinar sinais de múltiplas origens?
O que acontece se nenhuma métrica estiver disponível para um DC?
Como o healthyBackends é contado entre serviços?
A seleção por origem de cliente exige infraestrutura especial no cliente?
Escolha o data center usando os sinais que realmente importam.
Experimente a seleção de DC multi-origem na sua própria topologia: métricas de host, métricas de serviço e medições de rede do lado do cliente conduzindo a mesma decisão de roteamento.