Os clientes geralmente implementam failover / balanceamento de carga em vários registros A?

Question

Normalmente, balanceadores de carga como os Elastic Load Balancers da Amazon usam um conjunto de registros DNS com vários registros A para fornecer várias instâncias do balanceador de carga que podem manipular o tráfego para solicitar pontos de extremidade:

$ dig +short my-fancy-elb.us-east-1.elb.amazonaws.com
10.0.1.1
10.0.1.2

Se eu tentar encurralar esse URL no modo detalhado, observo que curl parece tentar executar round-robin nos dois endereços IP:

$ curl -ivs http://my-fancy-elb.us-east-1.elb.amazonaws.com | grep -i 'connected'
* Connected to my-fancy-elb.us-east-1.elb.amazonaws.com (10.0.1.1)
$ curl -ivs http://my-fancy-elb.us-east-1.elb.amazonaws.com | grep -i 'connected'
* Connected to my-fancy-elb.us-east-1.elb.amazonaws.com (10.0.1.2)

É o fato de que curl faz round-robin nos registros A descritos no conjunto de registros feito pelo próprio binário curl ou é algo que o kernel Linux faz por ele?

O TCP existe na camada 4 e o DNS existe na camada 7, portanto, imagino que bibliotecas e binários individuais precisariam implementar seu próprio balanceamento de carga e failover: buscando o conjunto de registros DNS para o nome de domínio fornecido e escolhendo um Endereço TCP para conectar a partir desse conjunto.

Posso razoavelmente esperar que linguagens de programação, navegadores e bibliotecas como curl farão balanceamento de carga e failover em registros A para mim?

    

Answer 1

A resposta curta é que isso varia.

Quando vários registros de endereço estão presentes no conjunto de respostas, um servidor DNS consultado normalmente os retorna em uma ordem aleatória. O sistema operacional normalmente apresentará o conjunto de registros retornados para o aplicativo na ordem em que foram recebidos. Dito isso, há opções em ambos os lados da transação (o servidor de nomes e o sistema operacional) que podem resultar em comportamentos diferentes. Geralmente estes não são empregados. Como exemplo, um arquivo pouco conhecido chamado /etc/gai.conf controla isso em sistemas baseados em glibc.

O livro sobre o Zytrax (DNS para cientistas de foguetes) tem um bom resumo sobre a história deste tópico , e conclui que RFC 6724 é o padrão atual que as implementações de aplicativos e resolvedores devem seguir .

A partir daqui, vale a pena notar uma escolha da cotação da RFC 6724:

   Well-behaved applications SHOULD NOT simply use the first address
   returned from an API such as getaddrinfo() and then give up if it
   fails.  For many applications, it is appropriate to iterate through
   the list of addresses returned from getaddrinfo() until a working
   address is found.  For other applications, it might be appropriate to
   try multiple addresses in parallel (e.g., with some small delay in
   between) and use the first one to succeed.

O padrão encoraja os aplicativos a não pararem no primeiro endereço de falha, mas isso não é um requisito nem o comportamento que muitos aplicativos escritos casualmente implementarão. Você nunca deve confiar somente em vários registros de endereço para alta disponibilidade, a menos que tenha certeza de que a maior (ou pelo menos a mais importante) porcentagem de seus aplicativos de consumo funcionará bem. Navegadores modernos tendem a ser bons nisso, mas lembre-se de que eles não são os únicos consumidores com os quais você está lidando.

(também, como observa @kasperd abaixo, é importante distinguir entre o que isso compra no HA x balanceamento de carga)

    

Answer 2

Meu palpite é que o TTL do DNS para o registro está muito baixo e o curl precisa ser resolvido sempre e receberá outro IP do servidor DNS.

Nem curl nem o kernel estão cientes de que esse balanceamento de carga no nível de DNS ocorre e você não pode razoavelmente esperar algo assim.

    

Answer 3

A coisa básica é que os servidores DNS geralmente alternam os registros de maneira pseudo-aleatória.

fedor@piecka:~$ dig +short @ns1.yahoo.com yahoo.com
206.190.36.45
98.138.253.109
98.139.183.24
fedor@piecka:~$ dig +short @ns1.yahoo.com yahoo.com
98.139.183.24
206.190.36.45
98.138.253.109
fedor@piecka:~$ dig +short @ns1.yahoo.com yahoo.com
98.139.183.24
98.138.253.109
206.190.36.45

No caso do curl, ele possui sua própria biblioteca de resolução de DNS, que respeita a ordem apresentada pelo servidor.

Há uma história sobre esse assunto em link . A implementação da onda é mencionada lá também.

    

Answer 4

Is the fact that curl does round-robin on the A records described in the record set done by the curl binary itself or is it something that the Linux kernel does for it?

Nem Seu servidor DNS que altera o endereço IP normalmente. A biblioteca de curl precisa resolver o nome do host para obter o endereço IP para cada solicitação. Ele envia a solicitação para o servidor DNS que envia de volta uma lista de endereços IP. O servidor DNS também pode ser local na mesma máquina para armazenamento em cache. A maioria do servidor DNS rotaciona o round robin da lista de IPs em todas as solicitações. Assim, você obtém um IP diferente em cada solicitação, pois o IP superior da lista foi alterado. Se você pingar www.google.com em uma máquina linux, provavelmente verá endereços diferentes a cada vez.

Do clients typically implement failover/load-balancing on multiple A records?

Eu fiz um teste com o curl para buscar um arquivo pelo http. Curl é capaz de repetir com outro IP quando o primeiro ip não está acessível (failover). Então, o 'failover' está trabalhando com o curl para solicitação http.