Server Load Balancer:Troubleshoot ALB health check failures

Descrição do problema

O Health Check Status de um listener em uma instância do ALB está como Unhealthy.

Causas

Soluções

Falhas na verificação de integridade durante a configuração inicial

Causa 1: Parâmetros de verificação de integridade incorretos

1. Faça login no console do ALB.

2. Na barra de menus superior, selecione a região onde a instância do ALB está localizada.

3. No painel de navegação à esquerda, escolha ALB > Server Groups.

4. Na página Server Groups, encontre o grupo de servidores anexado à instância ALB de destino e clique em id do grupo de servidores.

5. Na página de detalhes do grupo de servidores, na seção Health Check, clique em Modify Health Check.

6. Na caixa de diálogo Modify Health Check, verifique os parâmetros de verificação de integridade. Recomendamos o uso dos valores padrão.

   Health checks for ALB

Causa 2: Problemas na porta de verificação de integridade

1. Faça login no console do ALB.

2. Na barra de menus superior, selecione a região onde a instância do ALB está localizada.

3. No painel de navegação à esquerda, escolha ALB > Server Groups.

4. Na página Server Groups, encontre o grupo de servidores anexado à instância ALB de destino e clique em id do grupo de servidores.

5. Na página de detalhes do grupo de servidores, clique em aba Backend Servers e visualize e anote a porta do servidor de back-end.

6. Na página de detalhes do grupo de servidores, clique em aba Details e, na seção Health Check, clique em Modify Health Check. Na caixa de diálogo Modify Health Check, visualize e anote os parâmetros de verificação de integridade.

7. Faça login no servidor de back-end e use o comando nc ou curl para testar o servidor.

   Connect to an ecs instance

   # nc command:
   echo -e "[$Method] [$PATH] [$VERSION]\r\nHost: [$Domain]\r\n\r\n" | nc -t [$IP] [$Port] # Format
   echo -e "HEAD /index.html HTTP/1.0\r\nHost: www.example.org\r\n\r\n" | nc -t 127.0.0.1 80 # Example
   # curl command:
   curl -X [$Method] -H "Host: [$Domain]" -I http://[$IP]:[$Port][$PATH]  # Format
   curl -X HEAD --http1.0 -H "Host: www.example.org" -I http://127.0.0.1:80/index.html # Example

   Nota

   • [$Method] é o método de verificação de integridade configurado para o grupo de servidores.

   • [$PATH] é o caminho de verificação de integridade configurado para o grupo de servidores.

   • [$VERSION] é a versão HTTP usada para a verificação de integridade, por exemplo, HTTP/1.0.

   • [$Domain] é o nome de domínio configurado para a verificação de integridade. Se este valor for -----, o endereço IP privado de cada instância ecs de back-end será usado por padrão. Nesse caso, você pode usar [$IP] no lugar.

   • [$IP] é o endereço IP privado da instância ecs de back-end.

   • [$Port] é a porta de verificação de integridade configurada para o grupo de servidores. Se nenhuma porta de verificação de integridade for configurada manualmente, a porta da instância ecs de back-end será usada por padrão. Se uma porta de verificação de integridade estiver configurada, a porta configurada será utilizada.

8. Verifique se o código de status retornado indica uma resposta normal para o seu service.

   • Se o código de status for normal, mas não estiver entre os códigos de status de integridade configurados, adicione-o à configuração de verificação de integridade.

   • Se o código de status indicar um erro, solucione o problema usando a tabela a seguir.

     Código de status	Descrição	Solução de problemas
     400	Requisição inválida. Geralmente causada por uma requisição HTTP malformada, incompatibilidade entre o protocolo de verificação de integridade e o service de back-end, ou lógica de negócio que sempre retorna códigos de status 400.	Verifique os seguintes itens um a um: Cabeçalhos HTTP malformados, por exemplo, um cabeçalho Content-Length vazio. Verifique o formato da requisição HTTP. O protocolo de verificação de integridade não corresponde ao service de back-end, por exemplo, o protocolo de verificação HTTP é usado em uma porta HTTPS. Use o protocolo de verificação de integridade correto. Se a própria lógica de negócio sempre retorna códigos de status 4xx, como 400, selecione http_4xx para Health Check Status Codes na configuração de verificação de integridade para tratar códigos 4xx como respostas normais. Isso evita que nós de back-end sejam removidos pelas verificações de integridade devido a códigos de retorno específicos do negócio. Aviso Adicionar códigos de status 4xx ou 5xx como códigos de integridade pode impedir que instâncias não íntegras sejam removidas a tempo. Certifique-se primeiro de que o service de back-end retorne códigos de status 2xx ou 3xx corretos.
     403	Acesso proibido. Geralmente causado pela configuração do service web de back-end.	Verifique se o service de back-end (por exemplo, Nginx ou Tomcat) possui regras de controle de acesso que bloqueiam requisições de endereços IP de source ou padrões de requisição específicos. Se o back-end bloquear a source das requisições de verificação de integridade, as verificações retornarão 403 continuamente. Ajuste a configuração de controle de acesso do service de back-end para permitir requisições de verificação de integridade.
     404	O recurso de destino não foi encontrado. Geralmente causado por uma incompatibilidade entre o caminho de verificação de integridade e os caminhos realmente disponíveis no servidor de back-end.	Solucione o problema da seguinte forma: Verifique o prefixo de caminho exposto pelo gateway de back-end (por exemplo, Nginx), como /api/v1, e garanta que o Health Check Path configurado corresponda a um caminho realmente acessível no back-end. Se o acesso direto ao IP do servidor de back-end retornar uma resposta normal, mas o acesso via nome de domínio retornar 404, o service de back-end geralmente está realizando correspondência de host virtual com base no nome de domínio (cabeçalho Host). Verifique se o Health Check Domain configurado para a verificação de integridade corresponde à configuração de domínio do service de back-end.
     405	O método de requisição de verificação de integridade não é suportado.	Verifique se o service de back-end suporta o método de verificação de integridade configurado.
     500	Ocorreu um erro interno do servidor e a requisição não pôde ser concluída.	Verifique a lógica de negócio do service de back-end.
     503	O servidor está temporariamente indisponível.	Verifique a lógica de negócio do service de back-end ou determine se a carga do servidor está muito alta.

Falhas na verificação de integridade em uma configuração existente

Causa 1: Interferência de software de segurança

O ALB usa endereços IP de um bloco CIDR reservado para se comunicar com as instâncias ecs de back-end. Se este bloco CIDR da instância ALB for bloqueado, as verificações de integridade falharão e o ALB não poderá funcionar corretamente. O exemplo a seguir usa o iptables para verificar bloqueios em 100.64.0.0/10.

1. Faça login na instância ecs de back-end afetada e execute o seguinte comando para listar as regras da tabela de filtros.

   iptables -nL

   Uma saída semelhante à seguinte indica que a instância ecs de back-end está bloqueando requisições do bloco CIDR do ALB.

   [root@xxx Z ~]# iptables -nL
   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination
   DROP       all  --  100.64.0.0/10        0.0.0.0/0
   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination
   Chain OUTPUT (policy ACCEPT)
   target     prot opt source               destination
   Chain L (0 references)
   target     prot opt source               destination

2. Exclua esta regra com o seguinte comando:

   iptables -t filter -D INPUT -s 100.64.0.0/10 -j DROP

3. Confirme que o bloco CIDR do ALB não está mais bloqueado:

   iptables -nL

Além das regras do iptables, verifique as seguintes configurações de segurança para garantir que o tráfego de verificação de integridade do ALB possa alcançar o service de back-end:

1. Verifique o status de escuta da porta do servidor de back-end: Confirme se o servidor de back-end está escutando na porta de back-end configurada no grupo de servidores (por exemplo, porta 80). Execute o seguinte comando para verificar o status de escuta da porta:

   netstat -tlnp | grep <port>
   # Or use the ss command:
   ss -tlnp | grep <port>

   Se a porta não estiver no estado LISTEN, verifique se o service de back-end foi iniciado corretamente.

   Nota

   Para um service de back-end implantado em docker ou outro contêiner, uma porta de host acessível não garante que o service dentro do contêiner esteja escutando corretamente na porta de verificação de integridade. Se a porta do host estiver acessível, mas a verificação de integridade falhar, acesse o contêiner e confirme se o service está escutando na porta de verificação de integridade (por exemplo, porta 80) e se o endereço de escuta é 0.0.0.0 (e não apenas 127.0.0.1). Verifique também se uma política de segurança dentro do contêiner restringe os endereços IP de verificação de integridade do ALB.

2. Verifique as regras de entrada do grupo de segurança da ecs de back-end: Certifique-se de que as regras de entrada do grupo de segurança permitam o acesso da seguinte source. Caso contrário, as sondas de verificação de integridade do ALB podem ser bloqueadas pelo grupo de segurança:

   • Objeto de autorização (endereço de source): Para uma instância do ALB atualizada, o bloco CIDR do vSwitch onde reside seu Local IP; para uma instância do ALB não atualizada, o bloco CIDR 100.64.0.0/10.

   • Protocolo: tcp

   • Intervalo de portas: A porta do service de back-end configurada no grupo de servidores e a porta de verificação de integridade em uso.

Causa 2: Configuração de rota incorreta

Uma rota incorreta para o bloco CIDR 100.64.0.0/10 em uma instância ecs de back-end pode impedir que as respostas de verificação de integridade cheguem à instância ALB. O exemplo a seguir usa o comando route do Linux para verificar a configuração.

1. Faça login na instância ecs de back-end e execute o seguinte comando para verificar a configuração de rota:

   route -n

   A rota está incorreta se uma entrada com Destination 100.64.0.0 e Genmask 255.192.0.0 tiver um Gateway diferente do gateway padrão da NIC (o valor de Gateway onde Destination é 0.0.0.0).

   [root@test-server2 ~]# route -n
   Kernel IP routing table
   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   0.0.0.0         <Default gateway of eth0>  0.0.0.0         UG    100    0        0 eth0
   xxx             xxx             xxx             xxx   xxx    xxx      xxx xxx
   100.64.0.0      0.0.0.0         255.192.0.0     U     0      0        0 eth0

2. Exclua a rota incorreta para o bloco CIDR 100.64.0.0/10 com o seguinte comando:

   route del -net 100.64.0.0/10

Causa 3: Alta carga no servidor de back-end

Quando uma instância ecs de back-end fica com poucos recursos, ela pode não conseguir responder às sondas de verificação de integridade dentro do tempo limite configurado, causando falhas na verificação. A insuficiência de recursos pode resultar de uma sobrecarga geral do sistema ou de um problema específico, como um vazamento de conexão, que esgota gradualmente os recursos do sistema. Solucione os dois subcenários a seguir.

Subcenário 1: Sobrecarga de recursos do sistema

Quando a CPU, a memória ou a E/S do disco está saturada, o servidor não consegue responder às sondas de verificação de integridade a tempo. Consulte Troubleshoot and handle high load on Linux instances para verificar se o servidor está sobrecarregado.

Subcenário 2: Vazamento de conexão esgotando recursos (acúmulo de CLOSE_WAIT)

Se as instâncias ecs de back-end acumularem um grande número de conexões tcp CLOSE_WAIT, a causa geralmente é que a aplicação de back-end (por exemplo, um Java service gerenciado por jsvc.exec) não chama ativamente close() para liberar conexões após lidar com as requisições. Isso deixa as conexões no estado CLOSE_WAIT e faz com que se acumulem ao longo do tempo. O excesso de conexões CLOSE_WAIT consome recursos do sistema e pode afetar as respostas de verificação de integridade.

Etapas de solução de problemas:

1. Faça login na instância ecs de back-end e execute o seguinte comando para verificar o número atual de conexões CLOSE_WAIT:

   netstat -an | grep CLOSE_WAIT | wc -l

2. Se o número de conexões CLOSE_WAIT continuar crescendo ou estiver anormalmente alto, verifique o código da aplicação de back-end ou a configuração do service para garantir que a aplicação feche corretamente as conexões após processar as requisições (por exemplo, chamando close() ou shutdown()). Para frameworks que usam um pool de conexões, verifique as configurações de tempo limite de ociosidade e recuperação do pool.

Perguntas frequentes

Por que os servidores de back-end recebem requisições de verificação de integridade com alta frequência?

O ALB usa uma arquitetura de cluster distribuído multizona. Todos os nós de encaminhamento no cluster enviam sondas de verificação de integridade de forma independente para os servidores de back-end. Como resultado, a frequência real de requisições de verificação de integridade recebida por um servidor de back-end é igual à frequência de verificação por nó multiplicada pelo número de nós. Por exemplo, se o intervalo de verificação de integridade estiver definido como 5 segundos e o cluster contiver 10 nós de encaminhamento, o servidor de back-end receberá cerca de 10 requisições de verificação de integridade a cada 5 segundos, ou quase 2 requisições por segundo. Este é um comportamento esperado por design e não um problema.

Para reduzir a frequência das sondas de verificação de integridade ou seu impacto nos servidores de back-end, use os seguintes métodos:

1. Aumente moderadamente o Health Check Interval para reduzir o número de sondas por unidade de tempo. No entanto, um intervalo maior aumenta o tempo necessário para detectar e remover nós não íntegros, o que pode afetar a agilidade na detecção de falhas. Equilibre isso com os requisitos de disponibilidade do seu negócio.

2. Altere o protocolo de verificação de integridade para verificação tcp (Camada 4): o ALB realiza apenas um handshake tcp sem enviar requisições HTTP, o que reduz o consumo de recursos de cada sonda na aplicação de back-end.