Vários data centers e tráfego HTTP: DNS Round Robin é a ÚNICA maneira de garantir failover instantâneo?

Vários registros A apontando para o mesmo domínio parecem ser usados ​​quase exclusivamente para implementar o DNS Round Robin como uma técnica barata de balanceamento de carga.

O aviso usual contra o DNS RR é que não é bom para alta disponibilidade. Quando um IP cair, os clientes continuarão a usá-lo por minutos.

Um balanceador de carga é frequentemente sugerido como uma melhor escolha.

Ambas as afirmações não são completamente verdadeiras:

1. Quando o tráfego é HTTP, a maioria dos navegadores HTML pode tentar automaticamente o próximo registro A, se o anterior estiver inativo, sem uma nova pesquisa de DNS. Leia aqui o capítulo 3.1 e aqui .

2. Quando vários centros de dados estão envolvidos, o DNS RR é a única opção para distribuir o tráfego entre eles.

Portanto, é verdade que, com vários data centers e tráfego HTTP, o uso do DNS RR é a ÚNICA maneira de garantir failover instantâneo quando um data center fica inoperante?

Obrigado,

Valentino

Editar:

• Obviamente, cada data center possui um balanceador de carga local com hot spare.
• Não há problema em sacrificar a afinidade da sessão por um failover instantâneo.
• No AFAIK, a única maneira de um DNS sugerir um data center em vez de outro é responder apenas com o IP (ou IPs) associado a esse data center. Se o datacenter se tornar inacessível, todos esses IPs também estarão inacessíveis. Isso significa que, mesmo que os navegadores HTML inteligentes consigam tentar instantaneamente outro registro A, todas as tentativas falharão até que a entrada do cache local expire e uma nova pesquisa de DNS seja feita, buscando os novos IPs em funcionamento (presumo que o DNS sugira automaticamente a um novo data center quando um falha). Portanto, o "DNS inteligente" não pode garantir failover instantâneo.
• Por outro lado, um round-robin do DNS permite isso. Quando um data center falha, os navegadores HTML inteligentes (a maioria deles) tentam instantaneamente os outros registros A armazenados em cache, pulando para outro data center (em funcionamento). Portanto, o round-robin do DNS não garante a afinidade da sessão ou o RTT mais baixo, mas parece ser a única maneira de garantir o failover instantâneo quando os clientes são navegadores HTML "inteligentes".

Edição 2:

• Algumas pessoas sugerem o TCP Anycast como uma solução definitiva. Em este papel (capítulo 6) é explicado que Anycast fail-over está relacionada com a convergência BGP. Por esse motivo, o Anycast pode empregar de 15 minutos a 20 segundos para concluir. São possíveis 20 segundos em redes nas quais a topologia foi otimizada para isso. Provavelmente, apenas os operadores de CDN podem conceder failover tão rápido.

Edição 3: *

• Fiz algumas pesquisas e rastreamentos de DNS (talvez algum especialista possa verificar novamente) e:
  • O único CDN que usa o TCP Anycast parece ser o CacheFly, outros operadores como redes CDN e BitGravity usam o CacheFly. Parece que suas bordas não podem ser usadas como proxies reversos. Portanto, eles não podem ser usados ​​para conceder failover instantâneo.
  • Akamai e LimeLight parecem usar DNS com reconhecimento geográfico. Mas! Eles retornam vários registros A. De rastreadores parece que os IPs retornados estão no mesmo data center. Então, estou intrigado com a forma como eles podem oferecer um SLA 100% quando um data center fica inoperante.

Quando uso o termo "DNS Round Robin", geralmente quero dizer no sentido da "técnica barata de balanceamento de carga", conforme a OP descreve.

Mas essa não é a única maneira de o DNS ser usado para alta disponibilidade global. Na maioria das vezes, é difícil as pessoas com diferentes origens (de tecnologia) se comunicarem bem.

A melhor técnica de balanceamento de carga (se o dinheiro não for um problema) é geralmente considerada:

1. Uma rede global Anycast de servidores DNS 'inteligentes',
2. e um conjunto de datacenters espalhados globalmente,
3. onde cada nó DNS implementa o DNS do Split Horizon,
4. e o monitoramento da disponibilidade e dos fluxos de tráfego estão disponíveis para os nós DNS 'inteligentes' de alguma forma,
5. para que a solicitação de DNS do usuário flua para o servidor DNS mais próximo via IP Anycast ,
6. e este servidor DNS entrega um registro A / TTL baixo de A / registro para o centro de dados mais próximo / melhor para esse usuário final por meio de DNS 'inteligente' com horizonte dividido.

O uso de anycast para DNS geralmente é bom, porque as respostas DNS são sem estado e quase extremamente curtas. Portanto, se as rotas do BGP mudarem, é altamente improvável que você interrompa uma consulta DNS.

O Anycast é menos adequado para conversas HTTP mais longas e com estado, portanto, este sistema usa DNS de horizonte dividido. Uma sessão HTTP entre um cliente e um servidor é mantida em um datacenter; geralmente não pode fazer failover para outro datacenter sem interromper a sessão.

Como indiquei com "conjunto de registros A", o que eu chamaria de 'DNS Round Robin' pode ser usado junto com a configuração acima. É normalmente usado para distribuir a carga de tráfego por vários balanceadores de carga altamente disponíveis em cada datacenter (para que você possa obter melhor redundância, use balanceadores de carga menores / mais baratos, não sobrecarregar os buffers de rede Unix de um único servidor host, etc.).

Então, é verdade que, com vários datacenters e tráfego HTTP, o uso do DNS RR é a ÚNICA maneira de garantir alta disponibilidade?

Não, não é verdade, não se por "DNS Round Robin" queremos simplesmente entregar vários registros A para um domínio. Mas é verdade que o uso inteligente do DNS é um componente crítico em qualquer sistema global de alta disponibilidade. O exemplo acima ilustra um caminho comum (geralmente o melhor) a seguir.

Edit: O artigo do Google "Indo além das informações do caminho de ponta a ponta para otimizar o desempenho da CDN" parece-me o estado da arte na distribuição de carga global para obter o melhor desempenho do usuário final.

Edição 2: Li o artigo "Por que o DNS é baseado? GSLB .. não funciona" ao qual o OP estava vinculado e é uma boa visão geral - recomendo analisá-lo. Leia-o de cima.

Na seção "A solução para o problema de cache do navegador", defende respostas DNS com vários registros A apontando para vários datacenters como a única solução possível para failover instantâneo.

Na seção "Aguando", na parte inferior, expande-se o óbvio, que enviar vários registros A não é legal se eles apontarem para datacenters em vários continentes, porque o cliente se conectará aleatoriamente e, portanto, muitas vezes ficará 'lento' DC em outro continente. Portanto, para que isso funcione muito bem, são necessários vários datacenters em cada continente.

Esta é uma solução diferente das etapas 1 - 6. Não posso fornecer uma resposta perfeita sobre isso, acho que é necessário um especialista em DNS como Akamai ou Google, porque muito disso se resume a conhecimentos práticos sobre as limitações dos caches e navegadores DNS implantados hoje. AFAIK, meus passos 1 a 6 são o que a Akamai faz com o DNS (alguém pode confirmar isso?).

Meu sentimento - por ter trabalhado como PM em portais de navegadores móveis (telefones celulares) - é que a diversidade e o nível de quebra total dos navegadores por aí são incríveis. Pessoalmente, não confio em uma solução de alta disponibilidade que exija que o terminal do usuário final 'faça a coisa certa'; portanto, acredito que o failover instantâneo global sem interromper uma sessão não é viável hoje.

Acho que meus passos 1 a 6 acima são os melhores disponíveis com a tecnologia de commodities. Esta solução não possui failover instantâneo.

Eu adoraria que um desses especialistas em DNS da Akamai, Google etc aparecesse e me provasse errado. :-)

Sua pergunta é: "O DNS Round Robin é a ÚNICA maneira de garantir failover instantâneo?"

A resposta é: "O DNS Round Robin NUNCA é o caminho certo para garantir o failover instantâneo".

(pelo menos não por conta própria)

A maneira correta de obter failover instantâneo é usar o roteamento BGP4, de modo que ambos os sites usem os mesmos endereços IP. Com isso, as principais tecnologias de roteamento da Internet são usadas para rotear as solicitações para o data center certo, em vez de usar a tecnologia de endereçamento principal da Internet .

Na configuração mais simples, isso fornece apenas failover. Também pode ser usado para fornecer ao Anycast, com a ressalva de que os protocolos baseados em TCP falharão no momento da comutação, se houver alguma instabilidade no roteamento.

Então, é verdade que, com vários datacenters e tráfego HTTP, o uso do DNS RR é a ÚNICA maneira de garantir alta disponibilidade?

Claramente, é uma afirmação falsa - você só precisa olhar para o Google, Akamai, Yahoo, para ver que eles não estão usando respostas round-robin [*] como sua única solução (alguns podem usá-lo em parte, juntamente com outras abordagens). .)

Existem muitas opções possíveis, mas isso realmente depende de outras restrições que você tem, com o seu serviço / aplicativo sobre o que você escolhe.

É possível usar técnicas round-robin em uma abordagem simples e co-localizada do servidor, e não se preocupe com a falha do servidor, se você também solicitar o 'failover' do endereço IP. (Mas a maioria opta por técnicas de balanceamento de carga, um único endereço IP e failover entre balanceadores de carga.)

Talvez você precise de todos os pedidos de uma única sessão para acessar os mesmos servidores, mas deseja que os pedidos sejam distribuídos por diferentes clusters de servidores regionais? O rodízio não é apropriado, para isso: você precisa fazer algo que garanta que um determinado cliente acesse o mesmo cluster de servidores físicos a cada vez (exceto quando ocorrerem "exceções", como falhas no servidor). Eles recebem um endereço IP consistente de uma consulta DNS ou são roteados para o mesmo cluster de servidor físico. As soluções para isso incluem vários "balanceadores de carga" DNS comerciais e não comerciais ou (se você tiver mais controle da sua rede) anúncios de rede BGP. Você pode simplesmente solicitar que os servidores de nomes de seu próprio domínio dêem respostas totalmente diferentes (mas, como as solicitações de DNS podem ser enviadas por todo o lugar, você ganha '

[* Vou usar "round-robin", porque 'RR' na terminologia DNS significa "registro de recurso".]

Observação muito agradável vmiazzo +1 para você !! Estou preso exatamente onde você está .. perplexo com a forma como esses CDN fazem sua mágica.

A seguir, suponho como a CDN executa sua rede:

• Use o Anycast DNS (mencionado por Jesper Mortensen) para obter o data center mais próximo
• Eles gerenciam uma rede local que abrange diferentes data centers, o que lhes permite fazer algo como o CARP em seus hosts em diferentes data centers

Ou

• Eles empregam o Protocolo de Balanceamento de Carga de Gateway em seus roteadores ou o HSRP (Hot Standby Router Protocol) . que lidam com a interrupção do datacenter.
• A razão pela qual eles incluem vários IP é para que o cliente tente novamente e, quando o cliente tentar novamente, o caminho de roteamento poderá ter sido alterado.

No momento, a seguinte solução funciona para mim: - DNS retorna vários IP, por exemplo:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Último ponto de entrada para um proxy reverso na amazon cloud, que passa de forma inteligente para o servidor disponível (ou é fornecido na página de manutenção)

O proxy reverso ainda é atingido, mas é tão pesado quanto o principal.

Por que o RFC 2782 (aplica o mesmo que MX / prioridade para serviços como http, imap, ...) não é implementado em nenhum tipo de navegador? As coisas seriam mais fáceis ... Há um bug, aberto por dez anos no Mozilla !!! porque será o fim da indústria do balanceador de carga comercial ??? Estou muito decepcionado com isso.

2 - Você pode fazer isso com o Anycast usando o Quagga

(Mesmo que haja informações de que o Anycast é ruim com o TCP, há várias grandes empresas usando-o como o CacheFly)

Gostaria de saber quantas pessoas que respondem a essas perguntas estão realmente executando uma grande rede mundial de servidores? O Google usa round robin e minha empresa o usa há anos. Pode funcionar muito bem, com algumas limitações. Sim, ele precisa ser aumentado com outras medidas.

A chave real é estar disposto a aceitar um ou dois soluços se um servidor cair. Quando eu puxo o plugue de um servidor, se um navegador estiver tentando acessar esse servidor, haverá um atraso de mais ou menos um minuto enquanto o navegador descobrir que o endereço IP está inoperante. Mas ele vai para outro servidor muito rapidamente.

Funciona muito bem, e as pessoas que afirmam que isso causa muitos problemas não sabem do que estão falando. Requer apenas o design certo.

Failover é uma porcaria. O melhor HA usa todos os recursos o tempo todo.

Trabalho com HA desde 1986. Passei por um treinamento extensivo para criar sistemas de failover e não sou fã de failover.

Além disso, o RR trabalha para distribuir a carga, mesmo que passivamente, e não ativamente. Os logs do nosso servidor mostram claramente a porcentagem apropriada de tráfego em cada servidor - dentro do motivo.

Uma outra opção muito simples é usar um TTL baixo (o quão baixo depende de suas necessidades) no registro DNS A ou CNAME e atualizar esse registro para escolher qual IP será usado.

Temos 2 ISP e vários serviços públicos e estamos usando com êxito esse método para alta disponibilidade a partir de 3 anos.

Uma chave inglesa em andamento é que vários ISPs têm resolvedores mal configurados que armazenam em cache registros por um intervalo definido e ignoram completamente as configurações TTL. Não deveria ser assim e não há desculpa para isso, mas infelizmente pela minha experiência em migrar vários sites e serviços, isso acontece.

O TCP Anycast é realmente muito estável e é usado pelo menos pelo CacheFly (desde 2002), Prolexic e BitGravity. Uma boa apresentação no TCP Anycast foi feita no NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

Vários registros A são a única maneira de eliminar um possível ponto único de falha. Qualquer outra solução força todas as solicitações recebidas a passarem por um único dispositivo em algum lugar entre o servidor e o cliente.

Portanto, para redundância absoluta, é necessário. É por isso que o Google faz isso, ou qualquer pessoa que queira ter certeza da disponibilidade contínua de serviços.

É bastante óbvio por que esse é o caso ... vários registros A são a única maneira de mover o ponto em que as solicitações são roteadas para o navegador do cliente. Qualquer outro método dependerá de um único ponto entre o navegador do cliente e o servidor no qual uma falha pode ocorrer, desativando o serviço. Usando registros A, o único ponto único de falha do cliente para o servidor se torna o próprio cliente.

Se você não possui vários registros de configuração A, está solicitando tempo de inatividade ...

Obviamente, esse método não pode ser utilizado para balanceamento de carga.