Dado como certo

O DNS é uma daquelas coisas que para a maioria dos usuários é um problema resolvido. Você tem um servidor com software muito confiável e estável que pode funcionar por muito tempo com pouca manutenção. Os resolvers têm até mesmo um bom mecanismo embutido em failover para um servidor secundário. Então, o que mais há para dizer sobre este assunto? Desempenho.

O desempenho com os serviços de DNS tem sido visto como uma questão geográfica há anos. Sim, houve serviços de DNS pagos que são mais rápidos no próprio nível de pesquisa do DNS, especialmente se você está falando de registros complexos que têm lógica ligada a eles. No entanto, a discussão popular é principalmente em torno dos provedores globais de DNS. Neste post no blog, gostaríamos de examinar os ganhos de desempenho a serem obtidos em ambientes HPC e data center.

O Novo Caminho

Nos últimos meses, a equipe do Avance Network SRE se afastou dos servidores DNS independentes (e secundários como backup) nos diferentes data centers e em direção a clusters de servidores em execução sob o Anycast. O raciocínio por trás disso é simples e simples, quando o servidor DNS primário tem um problema, enquanto o resolver tem um backup secundário, o tempo de failover introduz latência. É simples assim. O tempo de failover do resolver para o DNS secundário, embora curto, ainda é muito longo no mundo da computação de alto desempenho.

A mudança de um servidor DNS para outro faz com que o aplicativo espere tempo extra que pode ser evitado. Sim, há a opção de definir esse tempo limite no arquivo resolver.conf, esse é um caminho a ser tomar que pode reduzir a questão do tempolimite. Mesmo com intervalos reduzidos, você ainda tem todos os servidores esperando esse período de tempo adicional para uma resposta. Isso parece um desperdício. Além disso, queríamos mais estrondo para o nosso dinheiro resolver, por assim dizer. Queríamos mais servidores em cada data center. Afinal, este é um serviço de "indutora de tempo de indutora" quando escurece.

Construindo a Solução

Nossa solução goto DNS por anos foi BIND. Funciona, é muito bem documentado, e há um grande conjunto de conhecimento facilmente disponível para a maioria dos casos que se pode encontrar. Para nós, depois de uma breve verificação de quais outras opções estão lá fora, optamos por continuar com o BIND e adicionar anycast (e servidores). Isso nos permitiria continuar com nossas ferramentas de automação existentes para DNS e trabalhar apenas no aspecto de balanceamento de carga da solução.

Escolher o mecanismo de agrupamento e balanceamento de carga para o DNS foi o próximo passo. Embora já operamos algumas soluções de balanceamento de carga, nenhuma foi relevante neste caso. O DNS é um serviço sem sessão, como tal, introduzir uma solução de qualquercast baseada em rede fez mais sentido para nós. Essa escolha significa que não precisamos de software adicional ou hosts rodando como balanceadores de carga, poderíamos usar nossa infraestrutura de rede existente.

Em nosso ambiente de produção (ou seja, cada data center) temos dois servidores DNS que compartilham o mesmo endereço ip, e a infraestrutura de roteamento faz todo o resto, direciona qualquer pacote para a instância topologicamente mais próxima do serviço. Cada servidor DNS está conectado com dois links 10G e cada link vai para um switch diferente, ambos os links são configurados com vinculação para redundância. O endereço IP do serviço DNS é o endereço de loopback configurado em cada servidor. Esse IP é anunciado via BGP dos servidores para os switches, que por sua vez aprendem a rota e permitem a conectividade. Existem várias soluções para bgp, mas escolhemos FRR(https://frrouting.org/). FRR é fácil de implantar e gerenciar, tornando-o uma escolha fácil (você deve notar um tema até agora). Adicionar o suporte a vários protocolos de roteamento como BGP, IS-IS, OSPF e a gestão de configurações via fantoche, é uma dose adicional de molho.

Monitoramento

Garantir que os servidores estejam realmente funcionando e que a rede não está enviando tráfego para um servidor com defeito é uma parte importante do quebra-cabeça. Tanto os exames de saúde quanto o monitoramento precisam estar prontos para a produção antes da implantação. Nossas verificações de saúde incluem a verificação de serviço em si e verificações adicionais, como resolução, taxa de erro e baixa taxa de resolução bem sucedida. Também verificamos se o roteamento do BGP está operacional. Há mais alguns, e a ideia é que algumas verificações expulsem o servidor do cluster e outras alertarão a equipe antes de agir.

A observabilidade do DNS é resolvida com o exportador prometheus enviando as métricas e permitindo-nos visualizar a atividade do DNS através do painel Grafana. A capacidade de visualizar graficamente diferentes métricas das operações de DNS permite uma solução fácil de problemas e, ao introduzir o DNSSEC ou outras configurações no mix, isso é algo que você deseja manter seu olho.

Em Produção

O lançamento para a produção foi baseado em nossa rede compartimentalizada. Operamos 9 data centers globais em uma configuração N+1. Isso nos permite implantar uma mudança crítica de infraestrutura como esta dentro de uma parte limitada de nossa infraestrutura global e observar o comportamento. Embora uma mudança na tecnologia DNS (neste caso stack) seja assustadora, a mudança foi inobservável para qualquer pessoa fora da equipe SRE. Uma vez que o primeiro data center estava operacional em carga total por uma semana, os outros data centers entraram em jogo em rápida sucessão.

O desempenho também foi um benefício quando se mudou para a nova configuração. Em nosso ambiente de produção, o tempo de resolução foi reduzido pela metade, em média, e no percentil de 99,9 em 16%. Esse desempenho melhorado é transferido para um desempenho mais rápido no próprio data center, à medida que os aplicativos agrupados ganham com tempos de resposta mais rápidos. Testes de desempenho e estresse foram feitos usando flamethrower (por NSONE) que pode ser encontrado aqui .

Conclusão

Investir tempo e esforço de engenharia em qualquer um dos serviços de infraestrutura de data center sempre vai pagar. Quando esse ganho de desempenho entra em ação e suas operações permanecem estáveis ou quando você tem um ciclo de manutenção DNS e ninguém é mais sábio. Manter o DNS funcionando no data center deve ser dado como certo. Quando um anfitrião pede para resolver, que um registro deve voltar voando rápido. Quando o DNS primário ou secundário falha, ninguém precisa saber. Nenhum serviço deve resolver mais devagar.

Trate-se de um DNS de qualquer elenco hoje.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.