Soluções modernas de balanceamento de carga de DNS [fechadas]

Question

Estou aprendendo a distribuir sistemas e agora estou pesquisando o tópico sobre balanceamento de carga de DNS.

Eu tenho poucos servidores Linux e quero configurar a próxima configuração:

1. um balanceador de carga DNS que resolve o endereço IP do servidor menos carregado;
2. vários servidores de aplicativos que processam solicitações de usuários e enviam estatísticas de carga para o balanceador de carga DNS.

Eu pesquisei por um tempo e encontrei o lbnamed que parece ser construído de acordo com dlbDNS idéia e fazer o que eu preciso. O que eu estou confuso com isso que parece estar parado por um tempo (sem atualizações desde 2006), embora haja observações de que tem poucos problemas. Também não consegui encontrar outras soluções. Então eu pensei que talvez eu estivesse pesquisando uma coisa errada, ou talvez tal funcionalidade seja incluída em algum aplicativo amplo como bind.

Então, minha pergunta é: a abordagem de balanceamento de carga de DNS é atual atualmente e quais soluções modernas (aplicativos) podem ser usadas?

Obrigado antecipadamente!

    

Answer 1

A maior parte do balanceamento de carga baseado em DNS não é aplicado a clusters em um único data center, mas é mais usado para apontar os usuários para instâncias geograficamente próximas de um aplicativo.

O problema com o DNS é que os registros são armazenados em cache, geralmente mais longos do que o TTL, o que significa que quando você atualiza a configuração do cluster e o DNS, os clientes ainda podem ser direcionados para um nó inativo / sem resposta.

Isso significa que uma fração progressivamente menor de seus usuários enfrentará problemas temporários durante o tempo necessário para que o cache DNS seja removido.

Isso pode ser completamente aceitável ou não. Também depende se o seu aplicativo é público ou não na intranet corporativa e, por exemplo, seus clientes usam exclusivamente os controladores de domínio do Active Directory como os servidores DNS.

O segundo problema possível com o balanceamento de carga DNS é que vários usuários podem estar usando um único servidor de nomes de armazenamento em cache para que o número de consultas DNS recebidas pelo seu servidor de nomes tenha potencialmente nenhum impacto sobre o número de solicitações.

Portanto, não, no seu caso, você está melhor com o layer3, o balanceamento de carga de rede ou possivelmente algo como o HAproxy, e não o balanceamento de carga DNS.

    

Answer 2

Pessoalmente, eu nunca usaria o loadbalancing baseado em DNS. A razão mais importante é que existem muitos resolvedores mal-comportados nos ISPs e na máquina do cliente. Esses resolvedores podem, por exemplo, ignorar as respostas do DNS do cache do TTL e, possivelmente, retornar respostas incorretas. Como você não é capaz de influenciar adequadamente essas coisas, prefiro não depender delas para que o balanceamento de carga funcione corretamente.

Todas as configurações de loadbalancing que eu vi (F5, A10 e ferramentas de código aberto como keepalived) fazem o balanceamento de carga de sessões TCP (ou UDP, ICMP).

    

Answer 3

"balanceamento de carga" embora historicamente não seja "verdadeiro" balanceamento, atualmente, o balanceamento de carga baseado em dns é uma parte necessária e muito eficaz (primeira camada) de uma solução de alto volume e alta disponibilidade.

a camada dns é capaz de resolver um nome de DNS para o cliente com base em sua localização geográfica (GeoIP), reduzindo assim algumas centenas de ms do tempo de resposta.

isso não foi possível há alguns anos, quando o balanceamento de carga do dns, ou balanceamento do pobre, significava um único registro de dns com vários IPs. esses IPs, nem mesmo eram balanceadores de carga (como você vê hoje rodando CARP / VRRP / HSRP / etc), mas eles eram os verdadeiros servidores web de ponto final !!!! com esse modelo, qualquer servidor que esteja diminuindo resulta em uma fração de todo o tráfego sendo negros.

o uso atual de DNS sofisticado, como seu próprio nível de HA, é muito eficaz. Um exemplo disso é aws route53, que usa um registro "A / ALIAS" não-compatível com rfc, para vincular domínios de nível superior a ELBs para escalabilidade e tempo de atividade em massa. (Não, eu não trabalho para aws) no entanto, existem vários outros provedores que irão resolver o seu DNS para solicitações de clientes, com base no datacenter mais próximo do cliente que pode atender a solicitação.

http://dyn.com/managed-dns/

http://aws.amazon.com/route53/