Como faço para descobrir a causa das falhas na verificação de integridade de um Application Load Balancer e corrigi‑las?

8 minuto de leitura
0

Os destinos registrados no meu Application Load Balancer não estão íntegros. Como faço para descobrir por que os destinos estão falhando nas verificações de integridade?

Resolução

Para descobrir a causa das falhas nas verificações de integridade de um Application Load Balancer e corrigi-las:

  1. Faça uma verificação de integridade nos destinos para conseguir achar o código de erro e a descrição do problema.
  2. Siga as etapas de solução a seguir de acordo com o erro recebido.

Elb.InitialHealthChecking

Descrição: as verificações de integridade iniciais estão em andamento.

Resolução: antes que um destino possa receber solicitações do balanceador de carga, ele deve passar por verificações de integridade iniciais. Espere o destino passar pelas verificações de integridade iniciais e, em seguida, verifique novamente seu status de integridade.

Elb.RegistrationInProgress

Descrição: o destino está sendo registrado.

Resolução: o balanceador de carga começará a encaminhar as solicitações para o destino assim que o processo de registro for concluído e que o destino passar pelas verificações de integridade iniciais.

Target.DeregistrationInProgress

Descrição: o cancelamento de registro do destino está em andamento.

Resolução: ao cancelar o registro de um destino, o balanceador de carga espera até que as solicitações em andamento sejam concluídas. Isso se chama atraso do cancelamento de registro. Por padrão, o Elastic Load Balancing espera 300 segundos antes de concluir o processo de cancelamento do registro. No entanto, você pode alterar esse valor.

Quando não há solicitações em andamento nem conexões ativas durante o cancelamento do registro de um destino, o Elastic Load Balancing cancela o registro imediatamente, sem esperar o período de atraso. O estado inicial de um destino durante o processo de cancelamento do registro é drenando. Passado o período de atraso do cancelamento de registro, o processo é concluído e o estado do destino passa a ser não utilizado. Caso o destino faça parte de um grupo do Auto Scaling, pode ser encerrado e substituído.

Target.FailedHealthChecks

Descrição: o balanceador de carga recebeu um erro ao estabelecer conexão com o destino, ou o destino retornou uma resposta malformada.

Resolução:

  • Confira se a aplicação está em execução. Use o comando service para verificar o status dos serviços em destinos do Linux. Nos destinos do Windows, verifique a aba Serviços no Gerenciador de Tarefas do Windows. Inicie o serviço se ele estiver interrompido. Se o serviço não for reconhecido, verifique se ele está mesmo instalado.
  • Confira se o destino está escutando o tráfego na porta da verificação de integridade. Use o comando ss em destinos do Linux para verificar as portas que o servidor está usando para escutar o tráfego. Para destinos do Windows, use o comando netstat.
  • Confira se a aplicação responde às solicitações de verificação de integridade do balanceador de carga da maneira esperada. O exemplo a seguir mostra uma solicitação típica de verificação de integridade do Application Load Balancer, para a qual os destinos devem retornar uma resposta HTTP válida. O valor do cabeçalho Host é o endereço IP privado do destino, seguido pela porta da verificação de integridade. O User-agent está definido como ELB-HealthChecker/2.0. A sequência CRLF é usada para quebrar a linha entre cabeçalhos. O cabeçalho termina na primeira linha vazia seguida por um CRLF. Se necessário, adicione um host virtual padrão à configuração do servidor web para receber as solicitações de verificação de integridade.
GET / HTTP/1.1
Host: 10.0.0.1:80
Connection: close
User-Agent: ELB-HealthChecker/2.0
Accept-Encoding: gzip, compressed
  • O tipo de destino do grupo de destino define a interface de rede para a qual o balanceador de carga deve enviar as verificações de integridade nos destinos. Por exemplo, você pode registrar IDs de instância, endereços IP e funções do Lambda. Se o tipo de destino for o ID de uma instância, o balanceador de carga enviará solicitações de verificação de integridade para a interface de rede primária dos destinos. Se o tipo de destino for um endereço IP, o balanceador de carga enviará solicitações de verificação de integridade para a interface de rede associada àquele endereço IP. Se os destinos tiverem várias interfaces associadas a eles, confira se a aplicação está escutando a interface de rede correta.
  • A política de segurança ELBSecurityPolicy-2016-08 é usada para as conexões de destinos e para as verificações de integridade HTTPS. Confira se o destino fornece um certificado de servidor e uma chave no formato indicado na política. Verifique também se o destino tem uma ou mais cifras compatíveis e um protocolo compatível com as cifras e protocolo fornecidos pelo balanceador de carga para poder estabelecer o handshake do TLS.

Target.InvalidState

Descrição: o estado do destino consta como interrompido ou encerrado.

Resolução: se o destino for uma instância do Amazon Elastic Compute Cloud (Amazon EC2), abra o console do Amazon EC2. Em seguida, verifique se a instância está em execução. Inicie a instância, se necessário.

Target.IpUnusable

Descrição: não é possível usar o endereço IP como destino porque ele está sendo usado por um balanceador de carga.

Resolução: ao criar um grupo de destino, você especifica o tipo de destino. Quando o tipo for IP, não escolha um endereço IP que já esteja sendo usado por um balanceador de carga.

Target.NotInUse

Descrição: o grupo de destino não está sendo usado por nenhum balanceador de carga, ou então o destino está em uma zona de disponibilidade que não foi habilitada no balanceador de carga.

Resolução:

  • Verifique o grupo de destino e confira se a configuração dele permite receber tráfego do balanceador de carga.
  • Confira se a zona de disponibilidade do destino está habilitada no balanceador de carga.

Target.NotRegistered

Descrição: o destino não está registrado no grupo de destino.

Resolução: confira se o destino está registrado no grupo de destino.

Target.ResponseCodeMismatch

Descrição: as verificações de integridade não retornaram o código HTTP esperado.

Resolução:

  • Códigos de sucesso são códigos HTTP usados para verificar se o destino retornou uma resposta bem-sucedida. Você pode indicar valores específicos ou intervalos de valores entre 200 e 499. O valor padrão é 200. Verifique a configuração da verificação de integridade do balanceador de carga para ver quais códigos de sucesso ele espera receber. Em seguida, inspecione os logs de acesso do servidor web para ver se os códigos de sucesso esperados estão sendo recebidos. Modifique o valor do código de sucesso, caso necessário.
  • Confira se o caminho do ping é válido. O caminho do ping é o destino das verificações de integridade. Especifique um URI válido (/path?query). O padrão é /. Modifique o valor do caminho do ping, se necessário.

Target.Timeout

Descrição: a solicitação atingiu o tempo limite.

Resolução: se você consegue se conectar, pode ser que a página de destino não esteja respondendo antes de atingir o tempo limite da verificação de integridade. A maioria dos servidores web, como o NGINX e o IIS, permite registrar quanto tempo o servidor leva para responder. Se as solicitações de verificação de integridade demorarem mais do que o tempo limite configurado, você pode:

Se você não consegue se conectar:

  • Confira se o grupo de segurança associado ao destino permite que o tráfego do balanceador de carga use a porta e o protocolo da verificação de integridade. Você pode adicionar uma regra ao grupo de segurança para permitir todo o tráfego vindo do grupo de segurança do balanceador de carga. Além disso, o grupo de segurança do balanceador de carga deve permitir que os destinos recebam tráfego.
  • Confira se a ACL da rede associada às sub‑redes do destino permite o tráfego de entrada na porta da verificação de integridade. Confira se ela permite também o tráfego de saída nas portas dinâmicas (1024-65535).
  • Confira se a ACL da rede associada às sub‑redes dos nós do balanceador de carga permite o tráfego de entrada nas portas dinâmicas. Verifique se ela permite também o tráfego de saída na porta da verificação de integridade e nas portas dinâmicas.
  • Confira se todos os firewalls no sistema operacional do destino permitem a entrada e a saída do tráfego de verificação de integridade.
  • Confira se a tabela de rotas das sub‑redes associadas ao destino contém uma entrada permitindo que o tráfego de verificação de integridade retorne ao balanceador de carga.
  • Confira se a utilização de memória e de CPU dos destinos está dentro dos limites da normalidade. Se estiver muito alta, registre mais destinos ou aumente a capacidade do grupo do Auto Scaling. Se o destino for uma instância do EC2, você também pode alterar o tipo da instância para um tipo maior.

Informações relacionadas

Solucionar problemas do Application Load Balancer

AWS OFICIAL
AWS OFICIALAtualizada há um ano