Se o DNS Failover não for recomendado, o que é?

6

Como uma pergunta importante para sua pergunta muito popular: Por que o failover de DNS não é recomendado? , acho que foi acordado que o failover de DNS não é 100% confiável devido ao armazenamento em cache.

No entanto, a resposta mais votada não discutiu realmente qual é a melhor solução para obter o failover entre dois datacenters diferentes. A única solução apresentada foi o balanceamento de carga local (data center único).

Então, minha pergunta é simplesmente qual é a solução real para cruzar o failover do data center?

    
por IMB 06.09.2012 / 05:42

3 respostas

5

Um data center inteiro precisaria ficar inativo ou inacessível para que isso se aplique. Seu backup em outro data center seria atingido roteando os endereços IP para o outro centro de dados. Isso aconteceria através dos anúncios de rota BGP do data center primário que não são mais fornecidos. Os anúncios secundários do data center secundário seriam usados.

Empresas menores geralmente não são grandes o suficiente para justificar a despesa de alocações de endereços IP portáteis e seu próprio número de sistema autônomo para anunciar rotas BGP. Nesse caso, um provedor faria com que vários locais fossem o caminho a seguir.

Você precisa ser alcançado por meio de seus endereços IP originais ou por meio de uma alteração de endereço IP feita pelo DNS. Como o DNS não foi projetado para fazer isso da maneira necessária pelo que o "failover" significa (os usuários podem ficar fora de alcance por pelo menos o TTL, ou o TTL imposto por alguns servidores de cache), indo para o site de backup com os mesmos IPs são a melhor solução.

    
por 06.09.2012 / 05:56
10

Isso começou como um comentário ... mas está ficando muito longo.

Infelizmente, a maioria das respostas a pergunta anterior está errada: elas Suponha que o failover tenha algo a ver com o TTL. A resposta mais votada é ESPETAMENTE errada, e notadamente não cita fontes. O TTL se aplica ao registro da zona como um todo e não tem nada a ver com o Round Robin.

A partir do RFC 1794 (que é tudo sobre o serviço de Round Robin DNS )

There is no use in handing out information with TTLs of an hour [or less]

(IME está mais perto de 3 horas antes de você obter a propagação completa).

Do RFC 1035

When several RRs of the same type are available for a
 particular owner name, the resolver should either cache them
 all or none at all

A RFC 1034 estabelece os requisitos para o armazenamento em cache negativo - um método para indicar que todas as solicitações devem ser atendidas no servidor DNS autoritativo (nesse caso, o TTL controla o failover) - na minha experiência, o suporte a isso varia.

Como qualquer failover teria que ser implementado no topo da pilha de clientes, é indiscutivelmente parte do TCP / IP ou DNS - de fato, SIP, SMTP, RADIUS e outros protocolos executando no topo do TCP / IP define como o cliente deve trabalhar com Round Robin - RFC 2616 (HTTP / 1.1) é notável em não mencionar como deve se comportar.

No entanto, na minha experiência, cada navegador e a maioria dos outros clientes HTTP escritos nos últimos 10 anos irão verificar de forma transparente os RRs adicionais se a conexão parecer demorar mais do que o esperado. E não sou só eu:

Os tempos de failover variam de acordo com a implementação, mas estão na região em segundos. Não é uma solução ideal, pois (devido aos limites do DNS) a publicação de um nó com falha leva o DNS TTL - enquanto isso, você precisa confiar na detecção do lado do cliente.

Round-Robin não é um substituto para outros mecanismos de HA dentro de um site. Mas ele complementa (os caras que escreveram o HAProxy recomendam usar um par de instalações acessadas via round robin DNS). É o melhor mecanismo suportado para implementar o HA em vários sites: na verdade, até onde posso determinar, é o único mecanismo de suporte suportado por failover disponível em clientes padrão.

    
por 06.09.2012 / 13:49
2

A abordagem mais simples para redundância dual DC seria uma VPN MPLS L2 entre os dois sites, junto com a manutenção das sessões BGP entre os dois.

Você basicamente pode ter apenas um IP físico por servidor e um IP virtual que flutua entre os dois (HSRP / VRRP / CARP etc.). Seu DNS seria roteado para esse IP específico e direcionado de acordo.

A próxima consideração seria dividir o cérebro - mas essa é outra questão para outra ocasião.

Juniper escreveu um bom white paper sobre gerenciamento dual DC com MPLS, você pode pegar o PDF aqui link

    
por 06.09.2012 / 15:17