Um utilizador encaminhado a um data center distante paga o custo de ida e volta em cada requisição.
Quando o DNS entrega a todos os utilizadores o mesmo data center independentemente de onde estão, os utilizadores distantes desse DC carregam um caminho de rede mais longo em cada requisição. A distância extra aparece como maior tempo de ida e volta, estabelecimento de conexão mais lento e uma experiência degradada que nenhum ajuste de backend no destino consegue recuperar.
O roteamento simples apenas por país ajuda, mas é grosseiro. Um utilizador pode estar no país certo e, ainda assim, muito mais próximo de um de dois data centers no mesmo país do que do outro, e uma regra de fronteira nacional não consegue distingui-los. A distribuição que ignora completamente a proximidade — round-robin ou aleatória entre todos os DCs — envia ativamente uma fração dos utilizadores pelo caminho mais longo.
Terceirizar a decisão de proximidade a um serviço de geolocalização externo introduz os seus próprios problemas: o contexto da consulta DNS sai da organização, a camada de decisão depende da disponibilidade de um terceiro e as obrigações de residência de dados tornam-se difíceis de cumprir. Uma decisão de tráfego crítica não deve ficar dependente de uma API externa.
Há também uma armadilha de correção. A proximidade do data center mais próximo só é útil se esse data center estiver de facto saudável. Direcionar um utilizador ao DC mais próximo enquanto ele está a falhar é pior do que enviá-lo um pouco mais longe para um que funciona.
O Roteamento DNS por latência do TR7 resolve exatamente isto: escolhe o data center saudável mais próximo de cada solicitante usando dados de proximidade offline, mantendo o caminho curto sem vazar contexto de consulta nem ignorar a saúde do DC.
Nossa abordagem
O TR7 implementa o direcionamento por proximidade através do seletor de proximidade, dados GeoIP offline, consciência de sub-rede de cliente e conjuntos de candidatos filtrados por saúde.
O seletor de proximidade escolhe o candidato mais próximo por consulta
Quando um registo DNS usa o algoritmo de balanceamento por proximidade, o GTM ordena as respostas candidatas pela proximidade do solicitante a cada data center e devolve a mais próxima. A decisão é executada por consulta, de modo que cada solicitante recebe como resposta o data center que minimiza a sua distância de rede.
As bases de dados GeoIP offline mantêm a consulta no dispositivo
A proximidade é resolvida a partir de bases de dados de país, cidade e ASN armazenadas localmente no appliance. A decisão nunca envia o contexto da consulta DNS a uma API de geolocalização externa — a resolução geográfica permanece dentro da infraestrutura da organização.
O EDNS Client Subnet segue o utilizador real, não o resolvedor
Com o EDNS Client Subnet, a decisão de proximidade pode basear-se na sub-rede real do utilizador em vez do IP do resolvedor de encaminhamento. Isso evita direcionar utilizadores em resolvedores públicos ao data center mais próximo do resolvedor em vez de mais próximo deles próprios.
Os data centers não saudáveis saem primeiro do conjunto de candidatos
O estado das verificações de saúde filtra os registos candidatos antes de a decisão de proximidade ser executada. Um data center em falha é removido do conjunto, de modo que a resposta mais próxima é sempre o data center saudável mais próximo — a proximidade nunca se sobrepõe à disponibilidade.
Capacidades
O Roteamento DNS por latência transforma a proximidade numa decisão DNS por consulta, delimitada a cada registo e decidida localmente.
A seleção do mais próximo por consulta encurta o caminho de rede
O algoritmo de balanceamento por proximidade avalia cada registo candidato em relação à localização da rede solicitante e devolve o data center mais próximo. Como uma distância geográfica menor geralmente significa menor tempo de ida e volta, os utilizadores são mantidos no caminho viável mais curto até a aplicação sem qualquer configuração por utilizador. A decisão é recalculada para cada consulta, em vez de ser fixada no momento da configuração.
A proximidade é resolvida em conjunto a partir de dados de país, cidade e ASN
O GTM resolve a localização do solicitante usando bases de dados offline de país, cidade e ASN. Os dados de nível de cidade permitem à plataforma distinguir entre dois data centers no mesmo país, e os dados de ASN refinam a decisão pela rede através da qual o solicitante está ligado. Isto é mais granular do que o roteamento por fronteira nacional, mantendo-se uma consulta local determinística.
O EDNS Client Subnet melhora a precisão da proximidade
Quando o resolvedor fornece a sub-rede do cliente, o GTM baseia a decisão de proximidade na localização de rede real do utilizador em vez da do resolvedor. Isto importa sobretudo para clientes que usam resolvedores públicos distantes, onde uma decisão baseada apenas no resolvedor poderia enviar um utilizador a um data center próximo do resolvedor em vez de próximo do utilizador. A resposta mais próxima segue onde o utilizador realmente está.
A filtragem por saúde mantém a proximidade honesta
Os registos candidatos são filtrados pela saúde do data center antes de a decisão de proximidade ser aplicada. Um data center não saudável não é elegível para ser a resposta mais próxima, de modo que a plataforma nunca troca disponibilidade por proximidade. Quando um data center próximo recupera, ele volta automaticamente ao conjunto de candidatos na decisão seguinte.
A proximidade compõe-se com regras de topologia
O seletor de proximidade pode atuar como seletor dentro de um conjunto de regras de topologia, de modo que um operador pode primeiro delimitar os candidatos por rede, país, cidade, continente ou ASN e depois escolher a resposta mais próxima entre as correspondências. Isto permite que restrições de conformidade ou de operadora e o direcionamento por proximidade operem no mesmo pipeline de decisão.
Configurado por registo DNS, não globalmente
O algoritmo de balanceamento é definido em cada registo DNS. O mesmo domínio pode responder a um registo por proximidade e a outro com uma estratégia diferente, de modo que o direcionamento por proximidade é aplicado exatamente onde acrescenta valor e os outros registos mantêm o seu próprio comportamento. Os operadores ajustam o roteamento registo a registo.
Decisão no dispositivo, sem dependência externa
Tanto a consulta de proximidade quanto a seleção de registo são executadas no appliance. Não há API de geolocalização externa no caminho da requisição, o que elimina uma dependência de disponibilidade de terceiros e mantém o contexto da consulta DNS dentro da organização. A decisão de proximidade continua a funcionar mesmo quando a conectividade de saída para serviços externos está indisponível.
Profundidade operacional
O direcionamento por proximidade é operado em conjunto com o conjunto de bases de dados GeoIP, o campo de algoritmo de balanceamento, os seletores de topologia, a filtragem por saúde e a recarga de configuração ao vivo.
Conjunto de bases de dados GeoIP
As decisões de proximidade baseiam-se em três bases de dados offline no appliance: uma base de dados de ASN, uma base de dados de nível de cidade e uma base de dados de nível de país. Em conjunto, suportam a proximidade consciente de país, cidade e ASN. Como os dados são locais, as decisões em tempo de execução não dependem de um serviço externo; o fluxo de atualização das bases de dados é planeado separadamente do caminho de decisão ao vivo.
Campo de algoritmo de balanceamento
A proximidade é selecionada definindo o algoritmo de balanceamento do registo como o mais próximo, um dos algoritmos de balanceamento de registo DNS disponíveis, ao lado de todos, primeiros-N, round-robin, round-robin ponderado, aleatório e aleatório ponderado. O campo é definido por registo e as mudanças são aplicadas através do pipeline de configuração.
Composição com seletor de topologia
Dentro de um conjunto de regras de topologia, o mais próximo pode ser usado como seletor aplicado aos registos que correspondem a uma regra. Isto permite que a proximidade seja executada depois de uma restrição geográfica ou de rede já ter reduzido os candidatos, combinando a filtragem por política com a seleção da resposta mais próxima num único registo.
Candidatos filtrados por saúde
O conjunto de candidatos entregue à decisão de proximidade reflete a saúde atual do data center. Os registos de data centers não saudáveis são removidos antes da seleção, de modo que a proximidade é calculada apenas sobre data centers que conseguem efetivamente servir tráfego. Essa filtragem faz parte do pipeline de decisão, e não é uma regra manual separada.
Recarga de configuração ao vivo
As mudanças nos algoritmos de registo e nos conjuntos de candidatos entram no pipeline de regeneração de configuração e são aplicadas sem reiniciar o serviço. As novas consultas recebem respostas que refletem a configuração atual; as respostas já em cache nos clientes permanecem até que o seu TTL expire, de modo que TTLs mais baixos fazem com que as mudanças de proximidade e saúde tenham efeito mais rapidamente.
Proximidade versus sinais de rede ao vivo
O seletor de proximidade decide com base na proximidade geográfica, que serve como indicador de latência em vez de uma medição ao vivo dela. Quando uma decisão precisa refletir o caminho de rede real em tempo real ou a carga do data center, a seleção de DC multifonte fornece sinais ao vivo de host, serviço e caminho de cliente que complementam o direcionamento por proximidade geográfica.
Em quais cenários é usado
Direcionar utilizadores globais à região mais próxima
Para serviços com utilizadores espalhados por várias regiões, o seletor de proximidade responde a cada consulta com o data center geograficamente mais próximo, encurtando o caminho de rede e reduzindo o tempo de ida e volta sem regras por utilizador.
Escolher entre dois data centers num mesmo país
Quando um país hospeda mais de um data center, a proximidade de nível de cidade distingue qual está mais próximo do solicitante — mais fina do que uma regra apenas por país que trataria ambos como equivalentes.
Direcionamento por proximidade com residência de dados
Como a consulta de geolocalização é executada sobre bases de dados offline no próprio dispositivo, as organizações com obrigações de residência de dados ou de privacidade de consultas obtêm roteamento por proximidade sem enviar o contexto da consulta DNS a um fornecedor de geolocalização externo.
Proximidade dentro de uma política de topologia
Delimite primeiro os candidatos por país, ASN ou CIDR por razões de conformidade ou de operadora e depois deixe o seletor de proximidade escolher a resposta mais próxima entre os data centers permitidos — política e proximidade num único registo.
Perguntas frequentes
O TR7 GTM mede a latência ao vivo do resolvedor a cada data center?
Como é determinada a localização do solicitante?
Por que usar o EDNS Client Subnet com o roteamento por proximidade?
O que impede que uma consulta seja direcionada ao data center mais próximo enquanto ele está fora do ar?
O roteamento por proximidade pode ser combinado com regras de país ou ASN?
O roteamento por proximidade é aplicado a toda a zona ou por registo?
Mantenha cada utilizador no caminho mais curto até um data center saudável
Direcionamento DNS por proximidade decidido nos seus próprios appliances — GeoIP offline, consciência de sub-rede de cliente e filtragem por saúde. Vamos percorrê-lo sobre a sua própria topologia.