AWS ELB Apache2 503 Serviço indisponível: servidor back-end está com capacidade

Question

Há cerca de dois anos, executamos alguns sites da infraestrutura da Amazon AWS e, há cerca de dois dias, o servidor começou a funcionar uma ou duas vezes por dia, com o único erro que eu posso encontrar:

HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

Nenhum alarme (CPU / IO / DB Conn) está sendo disparado pelo CloudWatch. Eu tentei ir ao site através do IP elástico para pular o ELB e consegui isto:

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.

Eu não vejo nada fora do comum nos logs do Apache e verifiquei que eles estavam sendo rotacionados corretamente. Eu não tenho problemas para acessar a máquina quando ela está "inativa" via SSH e olhando para a lista de processos eu vejo 151 processos apache2 que parecem normais para mim. Reiniciar o apache corrige temporariamente o problema. Esta máquina funciona apenas como um servidor web por trás de um ELB. Qualquer sugestão seria muito apreciada.

CPU Utilization Average: 7.45%, Minimum: 0.00%, Maximum: 25.82%

Memory Utilization Average: 11.04%, Minimum: 8.76%, Maximum: 13.84%

Swap Utilization Average: N/A, Minimum: N/A, Maximum: N/A

Disk Space Utilization for /dev/xvda1 mounted on / Average: 62.18%, Minimum: 53.39%, Maximum: 65.49%

Deixe-me esclarecer que o problema é com a instância individual do EC2 e não com o ELB. Eu não queria descartá-la, mesmo não conseguindo alcançar o IP elástico. Eu suspeito que o ELB está apenas retornando os resultados de acertar a instância real do EC2.

Atualização: 2014-08-26 Eu deveria ter atualizado isso mais cedo, mas a "correção" era tirar um instantâneo da instância "ruim" e iniciar a AMI resultante. Não diminuiu desde então. Analisei a verificação de integridade quando ainda estava com problemas e consegui acessar a página de verificação de integridade ( curl http://localhost/page.html ) mesmo quando recebia problemas de capacidade do balanceador de carga. Não estou convencido de que foi um problema de verificação de saúde, mas como ninguém, incluindo a Amazon, pode fornecer uma resposta melhor, estou marcando-a como a resposta. Obrigado.

Atualização: 2015-05-06 Pensei que voltaria aqui e diria que parte da questão que agora acredito firmemente é a configuração da verificação de integridade. Eu não quero descartar o fato de eles serem um problema com a AMI porque definitivamente melhorou depois que a AMI de substituição foi lançada, mas descobri que nossas verificações de saúde eram diferentes para cada balanceador de carga e aquele que estava tendo mais problemas tinha um limiar pouco saudável e um tempo limite de resposta muito agressivos. Nosso tráfego tende a aumentar de forma imprevisível e acho que entre as configurações agressivas de verificação de saúde e os picos de tráfego foi uma tempestade perfeita. Ao diagnosticar o problema, concentrei-me no fato de poder alcançar o ponto final da verificação de saúde no momento, mas é possível que a verificação de saúde tenha falhado por causa da latência e, em seguida, tenhamos um limiar alto e saudável. leve um tempo para ver a instância como saudável novamente.

    

Answer 1

Você receberá um "servidor back-end com capacidade" quando o balanceador de carga ELB executar suas verificações de integridade e receber uma "página não encontrada" (ou outro erro simples) devido a uma configuração incorreta (normalmente com o NameVirtual host).

Tente usar a pasta de arquivos de log usando o agente do usuário "ELB-HealthChecker". por exemplo.

grep ELB-HealthChecker  /var/log/httpd/*

Isso normalmente lhe dará um erro de 4x ou 5x, que é facilmente corrigido. por exemplo. Inundações, MaxClients, etc. estão dando muito crédito ao problema.

FYI Amazon: Por que não mostrar a resposta retornada da solicitação? Até mesmo um código de status ajudaria.

    

Answer 2

Eu acabei de me deparar com essa questão. O Amazon ELB retornará esse erro se não houver instâncias íntegras. Nossos sites foram configurados incorretamente, então o healthbeck do ELB estava falhando, o que fez com que o ELB retirasse os dois servidores da rotação. Com zero sites íntegros, o ELB retornou 503 Serviço não disponível: o servidor back-end está com capacidade.

    

Answer 3

[EDIT depois de entender melhor a pergunta] Não tendo nenhuma experiência com o ELB, eu ainda acho que isso soa suspeitamente como o erro 503 que pode ser lançado quando o Apache está na frente de um Tomcat e inunda a conexão.

O efeito é que, se o Apache fornecer mais solicitações de conexão do que pode ser processado pelo back-end, as filas de entrada de back-end serão preenchidas até que nenhuma outra conexão possa ser aceita. Quando isso acontece, as filas de saída correspondentes do Apache começam a ser preenchidas. Quando as filas estão cheias, o Apache lança um 503. O seguinte poderia acontecer quando o Apache é o backend, e o frontend entrega a uma taxa que faz as filas se esgotarem.

A solução (hipotética) é dimensionar os conectores de entrada dos conectores backend e de saída do frontend. Isso se transforma em um ato de equilíbrio entre o nível de inundação previsto e a RAM disponível dos computadores envolvidos.

Então, quando isso acontecer, verifique suas configurações de maxclients e monitore seus trabalhadores ocupados no Apache (mod_status.). Faça o mesmo, se possível, com qualquer ELB que corresponda ao backlog do conector Tomcats, maxthreads etc. Resumindo, observe tudo relacionado às filas de entrada do Apache e às filas de saída do ELB.

Embora eu entenda perfeitamente que não é diretamente aplicável, este link contém um guia de dimensionamento para o conector do Apache. Você precisaria pesquisar os detalhes técnicos correspondentes da fila ELB e fazer as contas: link

Como observado no comentário abaixo, para sobrecarregar o conector do Apache, um aumento no tráfego não é a única possibilidade. Se algumas solicitações forem mais lentas do que outras, uma proporção maior delas também poderá resultar no preenchimento das filas de conectores. Isso foi verdade no meu caso.

Além disso, quando isso aconteceu comigo, fiquei perplexo por ter que reiniciar o serviço Apache para não receber 503: s novamente. Simplesmente esperando a inundação do conector não foi suficiente. Eu nunca percebi isso, mas pode-se especular em Apache servindo de seu cache, talvez?

Depois de aumentar o número de trabalhadores e as configurações de maxclients pré-fork correspondentes (isso era o Apache multithreaded no Windows que tem algumas outras diretivas para as filas, se bem me lembro), o problema 503 desapareceu. Na verdade, não fiz as contas, mas apenas alterei os valores até conseguir observar uma ampla margem para o pico de consumo dos recursos da fila. Eu deixo passar isso.

Espero que isso tenha sido de alguma ajuda.

    

Answer 4

você pode subir os valores do verificador de integridade de elb, assim como uma única resposta lenta não vai puxar um servidor de elb. É melhor que alguns usuários tenham o serviço indisponível, que o site esteja indisponível para todos.

EDIT: Somos capazes de sair sem pré-aquecimento de cache, aumentando o tempo limite de verificação de saúde para 25 segundos ...... depois de 1-2 minutos ... site é responsivo como o inferno

EDITE: apenas inicie um monte de sob demanda, e quando suas ferramentas de monitoramento mostrarem o quão rápido você é, então pré-pague RI amazon: P

EDIT: é possível, uma única instância de backb elb registrada não é suficiente. apenas inicie mais alguns, e registre-os com elb, e isso ajudará você a refinar seu problema

    

Answer 5

Está alguns anos atrasado, mas espero que isso ajude alguém.

Eu estava vendo esse erro quando a instância por trás do ELB não tinha um IP público adequado atribuído. Eu precisava criar manualmente um IP elástico e associá-lo à instância, após o que, no momento em que o ELB o detectou, quase instantaneamente.