Failover de DNS baseado em navegador usando vários registros A

Question

Recentemente, chegou ao meu conhecimento que a configuração de vários registros A para um nome de host pode ser usada não apenas para balanceamento de carga round-robin, mas também para failover automático.

Então, tentei testá-lo:

1. Carreguei uma página do nosso domínio
2. Observou quais dos nossos servidores tinham servido a página
3. Desligou o servidor da web nesse host
4. Recarregou a página

E, de fato, o navegador tentou automaticamente um servidor diferente para carregar a página. Isso funcionou no Opera, Safari, IE e Firefox. Apenas o Chrome não conseguiu experimentar um servidor diferente.

Mas depois de deixar o servidor offline por alguns minutos e observar os logs de acesso, descobri que o número de solicitações para os outros servidores não aumentou significativamente . Com 1 de 3 servidores offline, esperava-se que os acessos a cada um dos 2 servidores restantes aumentassem cerca de 50%, mas em vez disso vi apenas 7-10%. Isso só pode significar que o failover de DNS no navegador não funciona para a maioria dos navegadores / visitantes, o que contradiz diretamente o que eu acabei de testar.

Alguém tem uma ideia do que há com o comportamento de failover de DNS dos navegadores? Qual possível razão poderia haver por que o failover automático funciona para mim, mas não para a maioria de nossos visitantes?

edit: Para deixar claro, eu fiz absolutamente nenhuma alteração para nossas configurações de DNS; não há TTL ou problema de propagação aqui, é tudo sobre como o cliente lida com vários registros A.

    

Answer 1

OK, vou começar dizendo que o DNS não é um bom sistema de failover de forma alguma, você precisa de um proxy reverso ou um balanceador de carga. Existem várias razões pelas quais a experiência não é a mesma. Primeiro de tudo no chrome, ele usa o sistema operacional para obter informações de DNS, de modo que é dependente do sistema operacional para os IPs, de modo que o sistema operacional, nesse caso, pode fornecer apenas um IP.

No que diz respeito aos demais navegadores, depende muito de como eles fazem o DNS e como isso funciona. Assim, o próprio navegador pode decidir não tentar os outros IPs ou até tentar o mesmo várias vezes, dependendo da resposta do servidor DNS.

Isso nos leva ao próprio servidor DNS, a maioria não respeita seus registros TTL e mantém o quanto se sente, o que significa que os usuários podem obter seu IP antigo por um bom tempo ...

Em quarto lugar, a experiência do usuário deseja que os usuários precisem atualizar três ou quatro vezes para acessar seu website? Você tem alguma sessão ou sessão baseada em login em seu site, o que acontece se o navegador receber outro IP no meio da sessão. Se você realmente precisa de HA e uptime, você realmente precisa considerar fazer isso da maneira certa, honestamente ou acabará mais fraturado do que usando apenas um servidor.

    

Answer 2

Para mim, é um ótimo negócio se você não quiser pagar por balanceadores de carga caros. Veja minha resposta aqui sobre como ele é gerenciado pelos navegadores : link

Agora, para sua preocupação, como você monitorou accesses ? Foi o tamanho de alguns access_log ? Foram os pedidos por segundo no seu servidor web?

Talvez você tenha alguma solução de armazenamento em cache no servidor, que não atingirá seu servidor dinâmico (PHP, Java ...) se a solicitação já estiver em cache. Quanto mais servidores, mais solicitações antes do armazenamento em cache (se eles não compartilharem o cache).

Antes de assumir que é um problema de DNS, adicione um monitoramento real: por exemplo, rastreador de análise ao vivo ou algo parecido. Em seguida, desligue um servidor e veja se o rastreador ao vivo mostra uma diminuição nos usuários atuais no site.

Por muitos anos eu usei e ainda uso essa configuração com um prazer real. Eu só adicionei mais algumas soluções de failover:

• Round-Robin em 2 ou 3 nós
• cada nó possui:
  • Envernizar com diretor / sondas para todos os backends
  • lighttpd (Apache ou nginx funcionarão!) em outra porta com fastcgi
  • pool PHP-FPM

Se um PHP-FPM ficar inativo, a sonda de verniz falhará e removerá o back-end até que a sonda esteja boa novamente. Se o Varnish falhar, o navegador Round-Robin + manipulará a alteração para outro nó.

    

Answer 3

Os navegadores geralmente são bastante agressivos ao tentar os registros alternativos quando um não está respondendo.

Algumas coisas:

1. Seu problema com o Chrome pode estar relacionado a como ele armazena em cache o DNS - ele faz seu próprio armazenamento em cache e é bem agressivo; poderia ter tido ainda a entrada em cache antes de você ter os múltiplos registros A no lugar?
2. Da mesma forma, você esperou pelo menos o TTL da zona DNS depois que os registros extras foram adicionados para testar os usuários vindos de fora?
3. Além disso, certifique-se de que a carga seja praticamente uniforme entre os servidores, em primeiro lugar; se um servidor tivesse apenas 10% do tráfego, você esperaria apenas um aumento modesto no outro nó quando ele morrer.

Além disso, o round robin de DNS é excelente para redundância geográfica e balanceamento de carga, mas lembre-se de que existem outras boas soluções para failover local.