Alta disponibilidade do site sem load-balancer?

Question

Estou considerando opções para alterar um site de 'alta disponibilidade' que fornece um serviço por meio de uma https api.

A configuração atual é:

• Duas VMs independentes, de diferentes provedores de nuvem (AWS e RackSpace)
• Um balanceador de carga de DNS: é nesse ponto que a HA também entra, o serviço monitora as duas VMs e, se uma delas parece não estar disponível, direciona todas as consultas DNS para a outra

Se o balanceamento de carga não fosse um requisito, poderíamos fazer sem o balanceador de carga, simplesmente co-localizando os servidores DNS nas duas máquinas, cada um respondendo apenas com seu próprio endereço quando consultado pelo DNS. Nesse cenário, se uma VM estiver inativa, isso removerá tanto o serviço quanto o servidor DNS que aponta para o serviço, de forma que nenhum cliente será direcionado para o servidor que está inativo, correto?

edite para maior clareza:

estamos felizes com o 'HA' menos que perfeito que temos atualmente, essa questão é especificamente sobre se as mudanças em que estou pensando vão piorar ou não as coisas.

    

Answer 1

A resposta direta à sua pergunta é Sim, vai piorar.

Isso ocorre porque um dos seus servidores de nome não está respondendo causará atrasos de resolução o tempo todo para os clientes que tentam resolver através do servidor de nomes com falha, enquanto a técnica atual falhará + - metade dos clientes até você detectar a VM. para baixo + segundos TTL.

Geralmente, os servidores de nomes são armazenados em cache por 48 horas, portanto, durante o menor tempo de inatividade ou as atualizações do servidor de nomes + 48 horas, os usuários terão uma experiência aleatoriamente lenta.

Sua implementação atual é melhor a menos que sua detecção de down de VM seja lenta. Para o período entre a VM descendo e você detectando + TTL, a solução proposta será realmente melhor. Mas estou assumindo que isso é um período de tempo tão pequeno que é ignorável.

    

Answer 2

Se eu entendi corretamente, você propõe que os dois servidores distribuídos sejam os servidores de nomes listados para o domínio em questão, cada um com um arquivo de zonas autoritativo que contém um único registro A apontando para o servidor local para o nome do host no qual seu serviço HTTPS corre.

Se isso estiver correto, então sim, eu esperaria que isso funcionasse com base na natureza round-robin / estocástica de solicitações para servidores de nomes. Se um servidor ficar inativo, ele não conseguirá responder a consultas com seu próprio endereço, portanto, os clientes devem rapidamente fazer failover para o outro para a pesquisa de DNS .

Você diz que entende e aceita que o cache de DNS significa que um servidor inativo pode quebrar clientes que armazenaram em cache a pesquisa que aponta para esse servidor, possivelmente por longos períodos de tempo devido a ISPs que não honram TTLs curtos. Se isso é tudo, então não vejo nenhum furo óbvio em sua proposta.

Eu não faria isso sozinho em um mês aos domingos.

    

Answer 3

O balanceamento de carga do DNS costumava ser a "coisa" a ser usada, mas com o cache em uso comum hoje em dia não é tão prático.

No Windows, você tem o "Balanceador de carga de rede", que pode ajudar com o que você deseja fazer usando multicast em uma rede privada. Você ainda pode fazer isso em provedores com uma VPN entre os dois.

No Linux, você precisaria usar algo como haproxy ou outro pacote para realizar o balanceamento de carga. Isso produz desafios por conta própria.

Veja as suas opções e decida quais seriam mais rentáveis para as suas necessidades. Eu não posso especular além das opções muito populares.