Problemas com o DNS e o roteamento do EC2 Elastic Load Balancer

Question

Estamos tentando executar uma configuração bastante simples no Amazon EC2 - vários servidores HTTP que estão 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.

Tivemos alguns problemas em que alguns locais, mas não todos, são intermitentemente incapazes de se conectar ao balanceador de carga. parece que esta pode ser a resolução do nome de domínio do ELB.

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

Amazon também confirmou que durante o período em que percebemos o tempo de inatividade de alguns locais, o tráfego passando pelo ELB caiu significativamente - de modo que o problema não é com os nossos terminais

.

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 são saudáveis em todos os momentos. Eles são todos

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

Obrigado,

    

Answer 1

Encontrei essa pergunta enquanto pesquisava como diagnosticar os ELBs (Amazon Elastic Load Balancers) e quero respondê-la para qualquer outra pessoa como eu que teve esse problema sem muita orientação.

Propriedades de ELB

Os ELBs possuem 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 do ELB
• Esses nós podem falhar ou ser desligados, e as conexões não serão fechadas com graça
• Geralmente, é necessário um bom relacionamento com o suporte da Amazon ($$$) para que alguém consiga resolver problemas de ELB

NOTA: Outra propriedade interessante, mas um pouco menos pertinente, é que os ELBs não foram projetados para lidar com picos súbitos de tráfego. Eles normalmente exigem 15 minutos de tráfego pesado antes de aumentar ou podem ser pré-aquecidos mediante solicitação por meio de um ticket de suporte

Solucionando problemas de ELBs (manualmente)

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

Sabendo disso, você pode fazer um pouco de solução de problemas por conta própria. 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 tcp sinalizador é sugerido como 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á somente até 6 nós a menos que você execute uma consulta ANY . A execução desse comando fornecerá uma saída semelhante a essa (reduzida para 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 registros A , use, e. curl para testar uma conexão com o ELB. Claro, você também quer isolar seu teste apenas para o ELB sem conectar-se aos seus backends. Uma propriedade final e pouco fato conhecido sobre ELBs:

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

Isso significa que podemos aproveitar esse 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ê vir HTTP/1.1 405 METHOD_NOT_ALLOWED , o ELB está respondendo com êxito. Você também pode querer ajustar os tempos limite da onda a valores aceitáveis para você.

Solucionando problemas de ELBs usando o elbping

É claro que fazer isso pode ser entediante, então eu criei uma ferramenta para automatizar isso chamado elbping . Está disponível como uma jóia rubi, por isso, se tiver rubygems, pode instalá-lo 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 vir code=405 , significa que o ELB está respondendo.

Próximos passos

Qualquer que seja o método escolhido, você pelo menos saberá se os nós do seu ELB estão respondendo ou não. Armado com esse conhecimento, você pode voltar seu foco para a solução de outras partes da sua pilha ou ser capaz de fazer um caso bem razoável para a AWS de que algo está errado.

Espero que isso ajude!

    

Answer 2

A correção é realmente simples: use um registro A em vez de um CNAME no 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.

    

Answer 3

Existem algumas possíveis soluções que você pode experimentar neste fórum de desenvolvedores da AWS. link .

Por exemplo:

correção potencial nº 1

We had a similar problem when we moved to ELB, we resolved this by reducing the name of our ELB to a single character. Even a 2 char name for ELB caused random problems with network solutions DNS resolutions.

Your ELB's DNS name should be something like -> X.<9chars>.us-east-1.elb.amazonaws.com

correção potencial nº 2

I'm the original poster. Thanks for all the responses. We were able to reduce the frequency with which we experienced DNS issues by setting the TTL very high (so they would cached by non-Network Solutions servers). However, we were still getting enough problems where we just couldnt stay with Network Solutions any longer. We thought of moving to UltraDNS based on good reports on the service, but it looked like Route 53 (which uses UltraDNS under the covers, it would appear) would be cheaper for us. Since switching to Route 53, we have no more DNS issues, and our ELB names can be nice and long too.

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