Failover do site de DR geográfico transparente

Question

Já temos servidores Web com balanceamento de carga. E mesmo que as interrupções não devam acontecer, elas acontecem por várias razões. (falha do switch central, roteadores ISP configurados incorretamente, falhas de backbone, ataque do DOS na infraestrutura compartilhada) Eu quero colocar um segundo conjunto de servidores em uma localização geográfica completamente diferente com conexões totalmente diferentes. Eu posso sincronizar os servidores SQL com várias técnicas diferentes, então isso não é um problema. Mas o que eu não sei como fazer é redirecionar de forma transparente as sessões da web do usuário existente para os servidores de backup quando o principal ficar inativo ou ficar inacessível.

AFAIK, as três formas mais comuns de lidar com isso são:

• Balanceamento de carga DNS, que usa um TTL muito baixo para inteligentemente resolver solicitações DNS para IPs do servidor no melhor ambiente.
• Redirecionamento inteligente, que usa um terceiro site para autoritariamente redirecionar os usuários para nomes DNS conhecidos, mas secundários na1.mysite.com e eu.mysite.com.
• Use um servidor proxy inteligente e mínimo para retransmitir as solicitações para sites diferentes enquanto hospeda o servidor proxy na nuvem em algum lugar.

Mas, no caso de uma falha no site, o primeiro deixaria os usuários impossibilitados de acessar o servidor até que o TTL fizesse com que os clientes repetissem a solicitação do DNS e resolvessem o site de DR ou causassem solicitações extras excessivas de DNS. O segundo método ainda nos deixa com um possível ponto único de falha (embora eu possa ver vários A-records sendo usados para duplicar a função de "login" mestre entre ambientes), mas ainda não redirecionar os usuários quando o site que eles usam está usando atualmente desce. E o terceiro não é redundante se a nuvem cair. (como todos têm de vez em quando)

Do que eu sei sobre rede, não posso dar dois servidores diferentes em dois ambientes separados geograficamente o mesmo endereço IP sobreposto e permitir que o roteamento de pacotes IP assuma e direcione o tráfego para o servidor aceitando solicitações? Isso só é viável com o IPv6? Como é chamado e por que os failovers de site de DR não usam atualmente essa técnica? Update: Isso é chamado de anycast . Como faço isso acontecer? E vale a pena?

Para esclarecer: essa pergunta é específica do tráfego do servidor HTTP apenas com a interrupção do serviço permitida por até 60 segundos. Os usuários não precisam fechar o navegador, voltar para a página de login ou atualizar qualquer coisa. Os usuários móveis não podem aceitar uma consulta DNS extra para cada solicitação de página.

    

Answer 1

Eu já estive aqui antes.

Algumas vezes.

Aqui estão algumas das minhas perguntas anteriores.

O TL geral, DR, é que o DNS não é uma solução, por muitas razões, algumas das quais você identificou. Algumas das quais estão nas respostas às perguntas relacionadas acima.

A única maneira real de fazer resiliência geográfica é com o BGP, e subdividir um / 23 em 2 / 24s, ter aqueles anunciados por seus upstreams e depois fazer coisas individuais de DNS a partir dali. / p>

Então você começa o problema irritante de sincronização entre eles, mas isso é outra história.

 I can sync the SQL servers with a number of different techniques, so that's not a problem.

Bem, não é um problema que você teve ainda.

Se você usou o redirecionamento inteligente, seja alterando o nome do host ou fazendo proxy na solicitação, você terá outro problema. "Onde você coloca o proxy, para que não seja um SPOF"

Caso contrário, você terá N sites geograficamente separados, mas um único ponto de falha (o mecanismo de proxy / redirecionamento).

Suponho que, em teoria, você poderia usar o MPLS para fazer com que seus locais pareçam estar na mesma rede L2, embora eu não tenha certeza de como isso realmente ajudaria a melhorar a resiliência ao fracasso.

    

Answer 2

O DNS por si só não oferece capacidade automática de failover. Mas, combinado com a repetição de clientes do navegador, ele oferece uma solução gratuita (em termos de investimento de rede) e baixa latência (~ 1s). Veja as referências abaixo para mais detalhes.

link
Múltiplos data centers e tráfego http://DNS Round Robin é a única maneira de garantir o failover instantâneo?