DNS Failover com vários balanceadores de carga Nginx

Question

Nossa aplicação está hospedada no EC2, no entanto, devido à natureza do aplicativo, é necessária uma disponibilidade extremamente alta. Temos uma imagem do aplicativo em execução no Linode como um failover.

No entanto, fazer um flip DNS para o Linode levaria algum tempo. Nós criamos uma estratégia para minimizar esse tempo de inatividade, mas eu gostaria de alguns conselhos sobre como melhor implementá-lo.

O aplicativo é um aplicativo ROR. Estamos executando 6 nós front-end no EC2 e usamos o Nginx como um balanceador de carga com proxy_pass.

No entanto, nosso balanceador de carga no Linode não é balanceado para os nós do Linode, mas para os nós do EC2. É por isso que temos o IP do nosso Linode LB em nosso registro de DNS. Assim, quando um cliente se conecta, o DNS alterna para o EC2 ou o Linode LB. O LB escolhido redirecionará a solicitação para um dos nós no EC2. No caso de uma interrupção do EC2, nós simplesmente mudamos a configuração do Linode LB para balancear para o próprio nó (além de outras coisas como um flip do DB, etc, etc.).

Eu sei que isso não é ótimo para o desempenho, mas a confiabilidade é mais importante para nós.

Para emitir estamos tendo chegadas quando, por qualquer motivo, o Linode LB não pode se conectar ao EC2. O Nginx retornará, no caso, um erro 502 Bad Gateway, que não faz com que o cliente use o failover de DNS.

Esperamos uma maneira de forçar o cliente a usar o fallback do DNS quando essa situação surgir. Existe alguma forma de fazer isso? De preferência com o Nginx, mas outras soluções seriam consideradas se não suportarem isso.

Obrigado!

    

Answer 1

Eu amo essa abordagem, é a minha favorita e comprarei uma cerveja para você se estiver em São Francisco!

Duas respostas, primeiro para o seu problema 502, você deve adicionar isso ao seu nginx, então se houver pelo menos alguns nós capazes, o nginx tentará novamente (por padrão, em um 502, ele simplesmente desiste):

link

proxy_next_upstream 

syntax: proxy_next_upstream [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off];

Em segundo lugar, para o seu 'back to DNS', você precisa mudar um pouco a abordagem. Para essas configurações, o que eu geralmente faço é puxar o DNS todo o caminho de volta para os nós do aplicativo que testam a conectividade até o nó de fim. Como bônus, você pode integrar o DNS ao seu aplicativo e desligá-lo se o aplicativo estiver inativo. A ideia aqui é fazer com que o pedido de DNS dos clientes 'teste' que o caminho inteiro funciona, não apenas a conectividade com o LB. Obviamente você não pode usar o NGINX para isso, eu usei regras pf para isso, você pode fazer a mesma coisa no iptables. Onde você apenas arredonda solicitações robin para back-end e executa bind em seus servidores de back-end. A ideia então é ter certeza de que você tem múltiplas entradas NS, uma para cada 'LB' que você tem. O cliente vai cuidar de testar cada registro NS, em testes eu fiz o tempo médio de failover é de 2 segundos e funcionou para 99% dos sistemas operacionais que analisamos. Deixe-me saber se isso faz sentido. Ele funcionará melhor do que qualquer cenário que tente se recuperar depois que o cliente já tiver feito a primeira solicitação TCP.

Com esta solução, criei sites que mantêm 100% de disponibilidade de acordo com o monitoramento do Gomez e do Keynote. Como você mencionou anteriormente, isso pode causar uma penalidade de desempenho inicial para a pesquisa de DNS, mas o site sempre funciona e os clientes adoram isso (assim como o meu pager).