Estamos tentando executar uma configuração bastante direta no Amazon EC2 - vários servidores HTTP sentados atrás de um ELB (Amazon Elastic Load Balancer).

Nosso domínio é gerenciado no Route53 e temos um registro CNAME configurado para apontar para o ELB.

Ocorremos alguns problemas em que alguns - mas não todos - locais não conseguem intermitentemente se conectar ao balanceador de carga; parece que essa pode ser a resolução do nome de domínio do ELB.

O suporte da Amazon nos informou que o IP Elastic subjacente do balanceador de carga está mudando e que o problema é que alguns servidores DNS de ISPs não respeitam o TTL. Não estamos satisfeitos com esta explicação, porque replicamos o problema usando os servidores DNS da Amazon a partir de uma instância do EC2, bem como ISPs locais na Austrália e através do servidor DNS do Google ( 8.8.8.8).

A Amazon também confirmou que, durante o período em que observamos o tempo de inatividade de alguns locais, o tráfego que passava pelo ELB diminuiu significativamente - portanto, o problema não está nos nossos pontos de extremidade.

Curiosamente, o domínio parece resolver o IP correto nos servidores que não podem se conectar - mas a tentativa de estabelecer uma conexão TCP falha.

Todas as instâncias anexadas ao ELB sempre foram saudáveis. São todos

Alguém sabe como podemos diagnosticar esse problema mais profundamente? Alguém mais teve esse problema com o Elastic Load Balancer?

Obrigado,

Encontrei essa pergunta no Google sobre como diagnosticar ELBs (Amazon Elastic Load Balancers) e quero respondê-la para qualquer pessoa como eu que tenha enfrentado esse problema sem muita orientação.

Propriedades ELB

ELBs têm algumas propriedades interessantes. Por exemplo:

• ELBs são compostos de 1 ou mais nós
• Esses nós são publicados como registros A para o nome ELB
• Esses nós podem falhar ou ser desligados e as conexões não serão fechadas normalmente
• Geralmente, é necessário um bom relacionamento com o suporte da Amazon ($$$) para que alguém se envolva em problemas de ELB

NOTA: Outra propriedade interessante, mas um pouco menos pertinente, é que os ELBs não foram projetados para lidar com picos repentinos de tráfego. Eles normalmente exigem 15 minutos de tráfego intenso antes de aumentarem de escala ou podem ser pré-aquecidos mediante solicitação por meio de um tíquete de suporte

Solução de problemas de ELBs (manualmente)

Atualização: desde então, a AWS migrou todos os ELBs para usar o Route 53 para DNS. Além disso, todos os ELBs agora têm um all.$elb_nameregistro que retornará a lista completa de nós para o ELB. Por exemplo, se o seu nome ELB for elb-123456789.us-east-1.elb.amazonaws.com, você obterá a lista completa de nós fazendo algo parecido dig all.elb-123456789.us-east-1.elb.amazonaws.com. Para nós IPv6, all.ipv6.$elb_nametambém funciona. Além disso, o Route 53 pode retornar até 4KB de dados ainda usando UDP, portanto, +tcppode não ser necessário usar o sinalizador.

Sabendo disso, você pode solucionar um pouco sozinho. Primeiro, resolva o nome do ELB para uma lista de nós (como registros A):

$ dig @ns-942.amazon.com +tcp elb-123456789.us-east-1.elb.amazonaws.com ANY

O tcpsinalizador é sugerido, pois seu ELB pode ter muitos registros para caber dentro de um único pacote UDP. Também me disseram, mas não confirmei pessoalmente, que a Amazon exibirá apenas 6 nós, a menos que você faça uma ANYconsulta. A execução deste comando fornecerá uma saída parecida com esta (aparada por questões de brevidade):

;; ANSWER SECTION:
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN SOA ns-942.amazon.com. root.amazon.com. 1376719867 3600 900 7776000 60
elb-123456789.us-east-1.elb.amazonaws.com. 600 IN NS ns-942.amazon.com.
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 54.243.63.96
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 23.21.73.53

Agora, para cada um dos Aregistros, use, por exemplo, curlpara testar uma conexão com o ELB. Obviamente, você também deseja isolar seu teste apenas no ELB sem conectar-se aos seus back-ends. Uma propriedade final e fato pouco conhecido sobre os ELBs:

• O tamanho máximo do método de solicitação (verbo) que pode ser enviado por meio de um ELB é de 127 caracteres . Qualquer maior e o ELB responderá com um HTTP 405 - Método não permitido .

Isso significa que podemos tirar proveito desse comportamento para testar apenas se o ELB está respondendo:

$ curl -X $(python -c 'print "A" * 128') -i http://ip.of.individual.node
HTTP/1.1 405 METHOD_NOT_ALLOWED
Content-Length: 0
Connection: Close

Se você HTTP/1.1 405 METHOD_NOT_ALLOWEDvir, o ELB está respondendo com sucesso. Você também pode ajustar o tempo limite da onda com valores aceitáveis ​​para você.

Solucionando problemas de ELBs usando elbping

Claro, fazer isso pode ser muito entediante, então eu criei uma ferramenta para automatizar isso chamado elbping . Está disponível como uma gema de rubi, portanto, se você tiver rubygems, poderá instalá-la simplesmente fazendo:

$ gem install elbping

Agora você pode executar:

$ elbping -c 4 http://elb-123456789.us-east-1.elb.amazonaws.com
Response from 54.243.63.96: code=405 time=210 ms
Response from 23.21.73.53: code=405 time=189 ms
Response from 54.243.63.96: code=405 time=191 ms
Response from 23.21.73.53: code=405 time=188 ms
Response from 54.243.63.96: code=405 time=190 ms
Response from 23.21.73.53: code=405 time=192 ms
Response from 54.243.63.96: code=405 time=187 ms
Response from 23.21.73.53: code=405 time=189 ms
--- 54.243.63.96 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 187/163/210 ms
--- 23.21.73.53 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 188/189/192 ms
--- total statistics ---
8 requests, 8 responses, 0% loss
min/avg/max = 188/189/192 ms

Lembre-se, se você vir code=405, isso significa que o ELB está respondendo.

Próximos passos

Seja qual for o método escolhido, você saberá pelo menos se os nós do seu ELB estão respondendo ou não. Armado com esse conhecimento, você pode se concentrar na solução de problemas de outras partes da sua pilha ou ser capaz de apresentar à AWS um argumento bastante razoável de que algo está errado.

Espero que isto ajude!

A correção é realmente simples: use um Aregistro em vez de um CNAMEno Route53.

No AWS Management Console, escolha "Um registro" e mova o botão de opção "Alias" para "Sim". Em seguida, selecione seu ELB no menu suspenso.

Existem algumas soluções em potencial que você pode tentar neste fórum de desenvolvedores da AWS. https://forums.aws.amazon.com/message.jspa?messageID=387552 .

Por exemplo:

correção potencial # 1

Tivemos um problema semelhante quando mudamos para o ELB, resolvemos isso reduzindo o nome do nosso ELB para um único caractere. Mesmo um nome de 2 caracteres para ELB causou problemas aleatórios nas resoluções de DNS das soluções de rede.

O nome DNS do seu ELB deve ser algo como -> X. <9chars> .us-east-1.elb.amazonaws.com

correção potencial # 2

Eu sou o pôster original. Obrigado por todas as respostas. Conseguimos reduzir a frequência com que enfrentamos problemas de DNS, definindo o TTL muito alto (para que eles fossem armazenados em cache por servidores que não são da Network Solutions). No entanto, ainda estávamos com problemas suficientes, onde não podíamos mais ficar com as soluções de rede. Pensamos em mudar para o UltraDNS com base em bons relatórios sobre o serviço, mas parecia que a Rota 53 (que usa o UltraDNS debaixo das cobertas, ao que parece) seria mais barata para nós. Desde a mudança para o Route 53, não temos mais problemas de DNS e nossos nomes ELB também podem ser bons e longos.

Havia outras coisas para tentar nesse post, mas essas parecem ser as melhores pistas.