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

Estamos executando alguns sites da infraestrutura da AWS da Amazônia há cerca de dois anos e, há cerca de dois dias, o servidor da web começou a cair uma ou duas vezes por dia com o único erro que posso encontrar:

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

Nenhum alarme (CPU / Disco IO / DB Conn) está sendo acionado pelo CloudWatch. Tentei ir ao site via IP elástico para pular o ELB e consegui o seguinte:

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

Não vejo nada fora do comum nos logs do apache e verifiquei que eles estavam sendo rotacionados corretamente. Não tenho problemas para acessar a máquina quando ela está "inativa" via SSH e, olhando para a lista de processos, vejo 151 processos apache2 que parecem normais para mim. Reiniciar o apache corrige temporariamente o problema. Esta máquina funciona apenas como um servidor da web atrás de um ELB. Todas as sugestões serão muito apreciadas.

Média de utilização da CPU: 7,45%, mínimo: 0,00%, máximo: 25,82%

Média de utilização de memória: 11,04%, mínimo: 8,76%, máximo: 13,84%

Média de utilização de swap: N / A, Mínimo: N / A, Máximo: N / A

Utilização do espaço em disco para / dev / xvda1 montada em / Média: 62,18%, Mínimo: 53,39%, Máximo: 65,49%

Deixe-me esclarecer que acho que o problema é da instância individual do EC2 e não do ELB. Eu simplesmente não queria descartar isso, apesar de não ter conseguido alcançar o IP elástico. Suspeito que o ELB esteja retornando os resultados de atingir a instância do EC2 real.

Atualização: 26/08/2014 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 caiu desde então. Examinei a verificação de integridade quando ainda estava com problemas e podia acessar a página de verificação de integridade ( curl http://localhost/page.html) mesmo quando estava recebendo problemas de capacidade do balanceador de carga. Não estou convencido de que tenha sido 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.

Update: 06-05-2015 Pensei em voltar aqui e dizer que parte do problema agora acredito firmemente nas configurações de verificação de saúde. Não quero descartar que seja um problema com a AMI porque ela definitivamente melhorou após o lançamento da AMI de substituição, mas descobri que nossas verificações de integridade eram diferentes para cada balanceador de carga e aquela que estava com mais problemas tinha um limite insalubre realmente agressivo e tempo limite de resposta. Nosso tráfego tende a aumentar imprevisivelmente e acho que entre as configurações agressivas de verificação de saúde e os picos no tráfego foi uma tempestade perfeita.

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 host NameVirtual).

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

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

Isso normalmente gera 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? Mesmo um código de status ajudaria.

Acabei de me deparar com esse problema. O Amazon ELB retornará esse erro se não houver instâncias íntegras. Nossos sites foram configurados incorretamente; portanto, a verificação de integridade do ELB falhou, o que levou o ELB a tirar os dois servidores de rotação. Com zero sites íntegros, o ELB retornou 503 Serviço Indisponível: o servidor back-end está em capacidade.

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

O efeito é que, se o Apache entregar mais solicitações de conexão do que as processadas pelo back-end, as filas de entrada do 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 se encher. Quando as filas estão cheias, o Apache lança um 503. Daqui resulta que o mesmo poderia acontecer quando o Apache é o back-end, e o front-end é entregue a uma velocidade que faz com que as filas sejam preenchidas.

A solução (hipotética) é dimensionar os conectores de entrada do back-end e os conectores de saída do front-end. 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, como isso acontece, verifique as configurações de maxclients e monitore seus trabalhadores ocupados no Apache (mod_status.). Faça o mesmo, se possível, com o ELB que corresponda ao backlog do conector Tomcats, maxthreads etc. Resumindo, veja tudo sobre as filas de entrada do Apache e as 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 Apache. Você precisaria pesquisar os detalhes técnicos da fila ELB correspondente e, em seguida, fazer as contas: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during- full-gc /

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

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

Depois de aumentar o número de trabalhadores e as configurações correspondentes de maxclients pré-fork (esse foi o Apache multithread no Windows que possui algumas outras diretivas para as filas, se bem me lembro), o problema 503 desapareceu. Na verdade, eu não fiz as contas, mas apenas aprimorei os valores até que pude observar uma ampla margem para o pico de consumo dos recursos da fila. Eu deixei para lá.

Esperamos que tenha sido de alguma ajuda.

você pode aumentar os valores do verificador de integridade do elb, para que uma única resposta lenta não retire um servidor do elb. é melhor que alguns usuários obtenham o serviço indisponível, do que o site sendo disponibilizado para todos.

EDIT: somos capazes de fugir sem cache de pré-aquecimento, aumentando o tempo limite da verificação de integridade para 25 segundos ...... após 1-2 minutos ... o site é responsivo como o inferno

EDIT :: basta lançar um monte de demanda e, quando suas ferramentas de monitoramento mostrarem à gerência o quão rápido você é, basta pagar antecipadamente o RI amazon: P

EDIT: é possível, uma única instância registrada de backend elb não é suficiente. basta lançar mais alguns e registrá-los no elb, e isso ajudará você a diminuir o seu problema

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

Eu estava vendo esse erro quando a instância atrás do ELB não tinha um IP público apropriado atribuído. Eu precisava criar manualmente um IP Elastic e associá-lo à instância após a qual o ELB o captou quase instantaneamente.