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.
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.
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.
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.
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.
`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.
Cada registro DNS em modo DC seleciona independentemente sua origem de sinal, critério e comportamento de distribuição.
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.
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.
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.
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.
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.
`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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.