Por que o failover de DNS não é recomendado?

Pela leitura, parece que o failover de DNS não é recomendado apenas porque o DNS não foi projetado para isso. Mas se você tiver dois servidores da Web em sub-redes diferentes que hospedam conteúdo redundante, que outros métodos existem para garantir que todo o tráfego seja roteado para o servidor ativo se um servidor cair?

Para mim, parece que o failover de DNS é a única opção de failover aqui, mas o consenso é que não é uma boa opção. No entanto, serviços como o DNSmadeeasy.com fornecem, por isso deve haver mérito. Algum comentário?

Por 'failover de DNS', entendo o DNS Round Robin combinado com algum monitoramento, ou seja, publicando vários endereços IP para um nome de host DNS e removendo um endereço morto quando o monitoramento detecta que um servidor está inoperante. Isso pode ser viável para sites pequenos e com menos tráfego.

Por padrão, quando você responde a uma solicitação de DNS, também fornece um TTL (Time To Live) para a resposta que você distribui. Em outras palavras, você está dizendo a outros servidores e caches de DNS "você pode armazenar esta resposta e usá-la por x minutos antes de retornar comigo". As desvantagens advêm disso:

• Com o failover de DNS, uma porcentagem desconhecida de seus usuários terá seus dados DNS armazenados em cache com diferentes quantidades de TTL restantes. Até o TTL expirar, eles podem se conectar ao servidor inoperante. Existem maneiras mais rápidas de concluir o failover do que isso.
• Por causa do exposto, você está inclinado a definir o TTL bastante baixo, por exemplo, de 5 a 10 minutos. Porém, a configuração mais alta oferece um benefício (muito pequeno) ao desempenho e pode ajudar a sua propagação de DNS a funcionar de maneira confiável, mesmo que exista uma pequena falha no tráfego da rede. Portanto, o uso do failover baseado em DNS vai contra TTLs altos, mas TTLs altos fazem parte do DNS e podem ser úteis.

Os métodos mais comuns de obter um bom tempo de atividade envolvem:

• Colocando Servidores juntos na Mesma LAN.
• Coloque a LAN em um datacenter com planos de energia e rede altamente disponíveis.
• Use um balanceador de carga HTTP para distribuir a carga e o failover em falhas individuais do servidor.
• Obtenha o nível de redundância / tempo de atividade esperado necessário para seus firewalls, balanceadores de carga e comutadores.
• Tenha uma estratégia de comunicação para falhas em todo o datacenter e a falha ocasional de um switch / servidor de banco de dados / outro recurso que não possa ser facilmente espelhado.

Uma minoria muito pequena de sites usa configurações de vários datacenters, com 'balanceamento geográfico' entre os datacenters.

O failover de DNS definitivamente funciona muito bem. Eu o uso há muitos anos para alternar manualmente o tráfego entre os datacenters, ou automaticamente, ao monitorar os sistemas detectados interrupções, problemas de conectividade ou servidores sobrecarregados. Quando você vê a velocidade com que ele funciona e os volumes de tráfego do mundo real que podem ser alterados com facilidade - você nunca olha para trás. Eu uso o Zabbix para monitorar todos os meus sistemas e os gráficos visuais que mostram o que acontece durante uma situação de failover de DNS colocam todas as minhas dúvidas e terminam. Pode haver alguns ISPs por aí que ignoram TTLs, e ainda existem usuários com navegadores antigos - mas quando você está olhando para o tráfego de milhões de visualizações de página por dia em dois locais do datacenter e faz uma mudança no tráfego do DNS - o tráfego residual que ignora TTLs é risível.

O DNS não foi projetado para failover - mas foi projetado com TTLs que funcionam surpreendentemente para as necessidades de failover quando combinados com um sólido sistema de monitoramento. TTLs podem ser definidos muito curtos. Utilizei efetivamente TTLs de 5 segundos na produção para soluções rápidas baseadas em failover de DNS. Você precisa ter servidores DNS capazes de lidar com a carga extra - e o nome não será suficiente. No entanto, os powerdns se encaixam perfeitamente quando apoiados com bancos de dados replicados mysql em servidores de nomes redundantes. Você também precisa de um sistema de monitoramento distribuído sólido em que possa confiar para a integração automatizada de failover. O Zabbix funciona para mim - posso verificar falhas de vários sistemas Zabbix distribuídos quase instantaneamente - atualizar registros mysql usados ​​por powerdns em tempo real - e fornecer failover quase instantâneo durante interrupções e picos de tráfego.

Mas, ei, eu construí uma empresa que fornece serviços de failover de DNS depois de anos trabalhando para grandes empresas. Então, tome minha opinião com um grão de sal. Se você quiser ver alguns gráficos de tráfego do zabbix de sites de alto volume durante uma interrupção - para ver por si mesmo exatamente como funciona o failover de DNS - envie-me um e-mail. Fico feliz em compartilhar.

O problema do failover de DNS é que, em muitos casos, não é confiável. Alguns ISPs ignoram seus TTLs, isso não acontece imediatamente, mesmo que respeitem seus TTLs e, quando o site volta, isso pode causar estranheza nas sessões quando o cache DNS de um usuário atinge o tempo limite e eles acabam indo para o cabeçalho. para o outro servidor.

Infelizmente, é praticamente a única opção, a menos que você seja grande o suficiente para fazer seu próprio roteamento (externo).

A opinião predominante é que, com o DNS RR, quando um IP cai, alguns clientes continuarão usando o IP quebrado por minutos. Isso foi afirmado em algumas das respostas anteriores à pergunta e também está escrito na Wikipedia.

De qualquer forma,

http://crypto.stanford.edu/dns/dns-rebinding.pdf explica que isso não é verdade para a maioria dos navegadores HTML atuais. Eles tentarão o próximo IP em segundos.

http://www.tenereillo.com/GSLBPageOfShame.htm parece ser ainda mais forte:

O uso de vários registros A não é um truque comercial ou um recurso concebido pelos fornecedores de equipamentos de balanceamento de carga. O protocolo DNS foi projetado com suporte para vários registros A por esse mesmo motivo. Aplicativos como navegadores e proxies e servidores de email fazem uso dessa parte do protocolo DNS.

Talvez algum especialista possa comentar e dar uma explicação mais clara do motivo pelo qual o DNS RR não é bom para alta disponibilidade.

Obrigado,

Valentino

PS: desculpe pelo link quebrado, mas, como novo usuário, não posso postar mais de 1

Executei o failover de DNS RR em um site com tráfego moderado, mas crítico para a produção (em duas regiões) por muitos anos.

Funciona bem, mas há pelo menos três sutilezas que aprendi da maneira mais difícil.

1) Os navegadores realizarão failover de um IP não ativo para um IP ativo após 30 segundos (última vez que verifiquei) se ambos forem considerados ativos em qualquer DNS em cache disponível para seus clientes. Isso é basicamente uma coisa boa.

Mas ter metade dos seus usuários aguardando 30 segundos é inaceitável; portanto, você provavelmente desejará atualizar seus registros TTL para alguns minutos, não alguns dias ou semanas, para que, em caso de falha, você possa remover rapidamente o servidor inativo do seu DNS. Outros aludiram a isso em suas respostas.

2) Se um de seus servidores de nomes (ou uma de suas duas regiões geográficas) ficar inoperante, servindo seu domínio round-robin, e se o principal deles cair, lembro-me vagamente de que você pode encontrar outros problemas tentando remover esse servidor de nomes inativo do DNS se você não tiver definido seu TTA / expiração de SOA para o servidor de nomes com um valor suficientemente baixo também. Eu poderia estar errado com os detalhes técnicos aqui, mas há mais do que apenas uma configuração TTL que você precisa acertar para realmente se defender contra pontos únicos de falha.

3) Se você publica APIs da web, serviços REST, etc., normalmente não são chamados por navegadores e, portanto, na minha opinião, o failover de DNS começa a mostrar falhas reais. Pode ser por isso que alguns dizem, como você diz "não é recomendado". Aqui está o porquê de eu dizer isso. Primeiro, os aplicativos que consomem esses URLs normalmente não são navegadores; portanto, eles não possuem as propriedades / lógica de failover de 30 segundos dos navegadores comuns. Segundo, se a segunda entrada DNS é chamada ou mesmo se o DNS é pesquisado novamente depende muito dos detalhes de programação de baixo nível das bibliotecas de rede nas linguagens de programação usadas por esses clientes API / REST, além de exatamente como elas são chamadas por o aplicativo cliente API / REST. (Sob as capas, a biblioteca chama get_addr e quando? Se os soquetes travam ou fecham, o aplicativo reabre novos soquetes? Existe algum tipo de lógica de tempo limite? Etc etc)

É barato, bem testado e "funciona principalmente". Assim como na maioria das coisas, sua milhagem pode variar.

Existem várias pessoas que nos usam (Dyn) para failover. É a mesma razão pela qual os sites podem criar uma página de status quando estão inativos (pense em coisas como a Fail Whale do Twitter) ... ou simplesmente redirecionar o tráfego com base nos TTLs. Algumas pessoas podem pensar que o Failover de DNS é um gueto ... mas projetamos seriamente nossa rede com failover desde o início ... para que funcionasse tão bem quanto em hardware. Não sei ao certo como o DME faz isso, mas temos 3 de 17 de nossos PoPs não-broadcast mais próximos que monitoram seu servidor a partir do local mais próximo. Quando ele detecta de um dos três que está inativo, simplesmente redirecionamos o tráfego para o outro IP. O único tempo de inatividade é para aqueles que foram solicitados pelo restante do intervalo TTL.

Algumas pessoas gostam de usar os dois servidores ao mesmo tempo ... e, nesse caso, podem fazer algo como um balanceamento de carga round robin ... ou balanceamento de carga baseado em região geográfica. Para aqueles que realmente se preocupam com o desempenho ... nosso gerenciador de tráfego em tempo real monitorará cada servidor ... e se um for mais lento ... redirecione o tráfego para o mais rápido com base nos IPs que você vincula nos nomes de host. Novamente ... isso funciona com base nos valores que você coloca no nosso UI / API / Portal.

Acho que meu argumento é ... projetamos o failover de DNS de propósito. Embora o DNS não tenha sido criado para failover quando foi criado originalmente ... nossa rede DNS foi projetada para implementá-lo desde o início. Geralmente, pode ser tão eficaz quanto o hardware ... sem depreciação ou custo do hardware. Espero que isso não me pareça ruim para conectar Dyn ... existem muitas outras empresas que fazem isso ... Estou apenas falando da perspectiva de nossa equipe. Espero que isto ajude...

Outra opção seria configurar o servidor de nomes 1 no local A e o servidor de nomes 2 no local B, mas configurar cada um para que todos os registros A no NS1 aponte o tráfego para IPs do local A e no NS2 todos os registros A aponte para IPs para local B. Em seguida, defina seus TTLs para um número muito baixo e verifique se o registro do seu domínio no registrador foi configurado para NS1 e NS2. Dessa forma, ele carregará automaticamente o equilíbrio e o failover se um servidor ou um link para um local cair.

Eu usei essa abordagem de uma maneira um pouco diferente. Eu tenho um local com dois ISPs e uso esse método para direcionar o tráfego por cada link. Agora, pode ser um pouco mais de manutenção do que você deseja fazer ... mas consegui criar um software simples que extrai automaticamente registros NS1, atualiza endereços IP de registro A para zonas selecionadas e envia essas zonas para NS2.

A alternativa é um sistema de failover baseado em BGP. Não é simples de configurar, mas deve ser à prova de balas. Configure o site A em um local, o site B em um segundo, todos com endereços IP locais, obtenha uma classe C ou outro bloco de ips portáteis e configure o redirecionamento dos IPs portáteis para os IPs locais.

Existem armadilhas, mas é melhor que as soluções baseadas em DNS se você precisar desse nível de controle.

Uma opção para failover de vários data centers é treinar seus usuários. Anunciamos a nossos clientes que fornecemos vários servidores em várias cidades e em nossos e-mails de inscrição, incluindo links diretamente para cada "servidor", para que os usuários saibam que se um servidor estiver inativo, poderão usar o link para outro servidor.

Isso ignora totalmente o problema do failover de DNS, mantendo apenas vários nomes de domínio. Os usuários que acessam www.company.com ou company.com e o login são direcionados para server1.company.com ou server2.company.com e têm a opção de marcar como favorito se perceberem que obtêm melhor desempenho usando um ou outro . Se um cair, os usuários são treinados para ir para o outro servidor.

Eu tenho usado o balanceamento e o failover de sites baseados em DNS nos últimos dez anos, e há alguns problemas, mas esses podem ser atenuados. O BGP, embora superior em alguns aspectos, não é uma solução 100% com maior complexidade, provavelmente custos adicionais de hardware, tempos de convergência, etc.

Descobri que a combinação de balanceamento de carga local (baseado em LAN), GSLB e hospedagem de zona baseada em nuvem está funcionando muito bem para fechar alguns dos problemas normalmente associados ao balanceamento de carga DNS.

Todas essas respostas têm alguma validade para elas, mas acho que realmente depende do que você está fazendo e do seu orçamento. Aqui no CloudfloorDNS, uma grande porcentagem de nossos negócios é DNS e oferece não apenas DNS rápido, mas também opções baixas de TTL e failover de DNS. Não estaríamos no negócio se isso não funcionasse e funcionasse bem.

Se você é uma empresa multinacional com orçamento ilimitado em tempo de atividade, sim, os balanceadores de carga GSLB de hardware e os datacenters de camada 1 são ótimos, mas seu DNS ainda precisa ser rápido e sólido. Como muitos de vocês sabem, o DNS é um aspecto crítico de qualquer infraestrutura, além do próprio nome de domínio, é o serviço de nível mais baixo em que todas as outras partes da sua presença online utilizam. Começando com um sólido registrador de domínio, o DNS é tão crítico quanto não deixar seu domínio expirar. O DNS fica inoperante, significa que todo o aspecto on-line da sua organização também está inoperante!

Ao usar o Failover DNS, os outros aspectos críticos são o monitoramento do servidor (sempre vários locais geográficos a serem verificados e sempre vários (pelo menos 3) devem ser verificados para evitar falsos positivos) e o gerenciamento adequado dos registros DNS, quando uma falha é detectada. TTL baixo e algumas opções com o failover podem tornar esse processo sem interrupções, e é muito bom acordar com um pager no meio da noite, se você é um administrador de sistemas.

No geral, o Failover de DNS realmente funciona e pode ser muito acessível. Na maioria dos casos, conosco ou com a maioria dos provedores de DNS gerenciados, você obtém o DNS do Anycast juntamente com o monitoramento e o failover do servidor por uma fração do custo das opções de hardware.

Portanto, a resposta real é sim, funciona, mas é para todos e todos os orçamentos? Talvez não, mas até que você faça os testes por si mesmo, é difícil ignorar se você é uma empresa de pequeno a médio porte com um orçamento de TI limitado e deseja o melhor tempo de atividade possível.

"e por que você está se arriscando a usá-lo na maioria dos ambientes de produção (embora seja melhor que nada)."

Na verdade, "melhor que nada" é melhor expresso como "a única opção" quando as presenças são geograficamente diversas. Os balanceadores de carga de hardware são ótimos para um único ponto de presença, mas um único ponto de presença também é um único ponto de falha.

Existem muitos sites que usam a manipulação de tráfego baseada em DNS com bons resultados. Eles são o tipo de site que sabe a cada hora se as vendas estão desativadas. Parece que eles são os últimos a aceitar "se arriscar usando-o na maioria dos ambientes de produção". De fato, eles revisaram suas opções cuidadosamente, selecionaram a tecnologia e pagaram bem por ela. Se eles pensassem que algo era melhor, partiriam em um piscar de olhos. O fato de eles ainda optarem por ficar fala muito sobre o uso no mundo real.

O failover baseado em DNS sofre de uma certa quantidade de latência. Não há maneira de contornar isso. Porém, ainda é a única abordagem viável para o gerenciamento de failover em um cenário multipop. Como única opção, é muito mais do que "melhor que nada".

Hoje, bons balanceadores de carga globais que funcionam usando essa técnica e funcionam muito bem. Verifique, por exemplo, o Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/

Se você quiser saber mais, leia as notas do aplicativo em

http://edgedirector.com

Eles abrangem: failover, balanceamento de carga global e uma série de assuntos relacionados.

Se sua arquitetura de back-end permitir, a melhor opção é o balanceamento de carga global com a opção de failover. Dessa forma, todos os servidores e largura de banda estão em jogo o máximo possível. Em vez de inserir um servidor adicional disponível em caso de falha, essa configuração retira um servidor com falha do serviço até que seja recuperado.

A resposta curta: funciona, mas você precisa entender as limitações.

Acredito que a idéia de failover foi planejada para cluster, mas, como também poderia ser executada em solo, ainda era possível operar em uma disponibilidade individual.

Eu recomendaria que você A, selecione um datacenter com hospedagem múltipla por conta própria, AS ou B, hospede seus servidores de nomes em uma nuvem pública. É REALMENTE improvável que EC2, HP ou IBM caiam. Apenas um pensamento. Embora o DNS funcione como uma correção, é simplesmente uma correção para um design inadequado na base da rede nesse caso.

Outra opção, dependendo do seu ambiente, é usar uma combinação com IPSLA, PBR e FHRP para atender às suas necessidades de redundância.