Server Load Balancer:Configure and manage CLB health checks

Pré-requisitos

Antes de configurar as verificações de integridade, certifique-se de que os services relevantes estejam implantados nos servidores de back-end.

Limites

O protocolo do listener e o protocolo de verificação de integridade devem obedecer às seguintes regras:

• Listeners TCP suportam apenas protocolos de verificação de integridade TCP ou HTTP.

• Listeners UDP aceitam protocolos de verificação de integridade TCP, UDP ou HTTP.

• Listeners HTTP e HTTPS suportam exclusivamente o protocolo de verificação de integridade HTTP.

Configurar verificações de integridade

Configure as verificações de integridade ao adicionar um listener. Na maioria dos casos, as configurações padrão são suficientes.

1. Faça login no console do CLB.

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

3. Na página Instances, localize a instância desejada e clique no ID da instância.

4. Na página de detalhes da instância, clique na aba Listener. Clique em Add Listener ou em Modify Listener na coluna Actions do listener alvo.

5. Siga o assistente de configuração até a etapa Health Check. As verificações de integridade vêm ativadas por padrão.

6. Clique em Advanced Settings e, em seguida, clique em Modify à direita para ajustar as configurações de verificação de integridade.

   Configuração de Verificação de Integridade	Descrição
   Health Check Protocol	Selecione um protocolo para as verificações de integridade. As verificações TCP operam na camada de rede enviando mensagens de handshake SYN para confirmar se a porta do servidor está ativa. Verificações UDP usam mensagens UDP para obter informações de status. Verificações HTTP enviam solicitações HEAD ou GET para simular o acesso de um navegador e validar a integridade da aplicação no servidor.
   Health Check Method (Suportado apenas para o protocolo de verificação de integridade HTTP)	Escolha entre o método HEAD ou GET. O método HEAD é usado por padrão. Nota Caso o método HEAD não seja suportado ou esteja desativado, use o método GET. Ao usar o método GET, respostas maiores que 8 KB são truncadas, sem impacto no resultado da verificação de integridade.
   Health Check Port	Porta usada para verificar a integridade dos servidores de back-end. Por padrão, o CLB usa a porta de cada servidor de back-end. Nota Se os servidores de back-end em um grupo usarem portas diferentes, não especifique uma porta de verificação de integridade. Nesse cenário, o CLB usa a porta individual de cada servidor para as verificações.
   Health Check Path (Suportado apenas para o protocolo de verificação de integridade HTTP)	Por padrão, o CLB envia uma solicitação HTTP para a página inicial padrão da aplicação nas verificações de integridade. Caso a página usada para verificação não seja a página inicial padrão, especifique o caminho exato. Recomenda-se o uso de uma página estática para as verificações de integridade.
   Health Check Domain Name (Optional) (Suportado apenas para o protocolo de verificação de integridade HTTP)	Ao configurar um domínio de verificação de integridade, o CLB define o campo Host no cabeçalho da solicitação com esse domínio. Se nenhum domínio for configurado, o campo Host será omitido. Alguns servidores de aplicação validam o campo Host. Sem a configuração de um domínio, as solicitações podem ser rejeitadas, causando falhas na verificação de integridade. Se o servidor validar o campo Host, configure um domínio de verificação para garantir o sucesso das verificações. Nota Ao executar uma verificação de integridade, o balanceador de carga ignora as regras de encaminhamento e envia solicitações para o caminho de verificação configurado no listener (o caminho raiz por padrão). Se seus services de back-end responderem de forma diferente dependendo do caminho da solicitação, as verificações enviadas para o caminho padrão ou incompatível poderão falhar. Configure um caminho personalizado de verificação de integridade para cada regra de encaminhamento conforme necessário.
   Healthy Status Codes (Suportado apenas para o protocolo de verificação de integridade HTTP)	Selecione os códigos de status HTTP que indicam um servidor de back-end íntegro. Os valores padrão são http_2xx e http_3xx. É possível selecionar http_2xx, http_3xx, http_4xx ou http_5xx. Por padrão, o CLB considera apenas os códigos de status HTTP 2xx e 3xx como íntegros. Se o servidor de back-end retornar um código 4xx (como 400, 403 ou 404) ou 5xx (como 500, 502 ou 503), a verificação de integridade falhará. Consequentemente, o CLB marcará o servidor como anormal e interromperá o encaminhamento de tráfego para ele. Aviso Aceitar códigos de status 4xx ou 5xx como íntegros pode impedir a remoção rápida de instâncias com falha do pool de servidores de back-end. Por exemplo, se um servidor retornar erro 500 e você tiver configurado http_5xx como status normal, o CLB continuará roteando tráfego para essa instância defeituosa. Use essa configuração somente após avaliação cuidadosa. Recomendamos garantir que o servidor de back-end retorne códigos 2xx ou 3xx sempre que possível. Causas comuns de erros 4xx: Erro 404: O caminho de verificação de integridade não existe, o service de back-end não foi implantado corretamente, há problemas na vinculação de domínio ou o método HEAD não é suportado. Erro 403: O servidor de back-end negou acesso, existem restrições baseadas em endereço IP ou houve falha na verificação de permissões. Erro 400: O cabeçalho Host está ausente, a versão HTTP é incompatível ou a solicitação está malformada.
   Health Check Response Timeout	Tempo máximo de espera por uma resposta à verificação de integridade. Se o servidor de back-end não responder dentro do tempo limite especificado, a verificação de integridade será considerada malsucedida.
   Health Check Interval	Intervalo entre as execuções das verificações de integridade. Todos os nós no cluster do CLB executam verificações de integridade independentemente no intervalo definido. Como essas verificações não são sincronizadas entre os nós, as solicitações recebidas pelo servidor de back-end podem não ter espaçamento uniforme. Por padrão, as verificações HTTP usam o método HEAD. Solicitações HEAD retornam apenas o código de status HTTP e cabeçalhos, sem o conteúdo completo da página, impondo carga mínima aos servidores de back-end. Reduzir o intervalo aumenta o número de solicitações de verificação, mas o overhead geralmente é insignificante comparado ao tráfego normal do service.
   Healthy Threshold	Número de verificações de integridade consecutivas bem-sucedidas necessárias para que um Elastic Compute Service com falha seja considerado íntegro.
   Unhealthy Threshold	Quantidade de falhas consecutivas nas verificações de integridade para que uma instância Elastic Compute Service seja considerada não íntegra.
   Health Check Request e Health Check Result (Suportado apenas para o protocolo de verificação de integridade UDP)	Ao configurar verificações para um listener UDP, insira o conteúdo da solicitação (por exemplo, youraccountID) no campo Health Check Request e a resposta esperada (por exemplo, slb123) no campo Health Check Result. Adicione também lógica à aplicação de back-end para tratar as respostas de verificação de integridade, configurando-a para responder com slb123 a solicitações contendo youraccountID. O CLB considera a verificação bem-sucedida apenas ao receber a resposta correta. Essa abordagem maximiza a confiabilidade das verificações de integridade UDP.

7. Clique em Next até concluir a configuração do listener.

Visualizar status de verificação de integridade

1. Faça login no console do CLB.

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

3. Na página Instances, encontre a instância desejada e clique no ID da instância.

4. Na página de detalhes da instância, clique na aba Listener para visualizar o status de verificação de integridade de cada listener.

   O status de verificação de integridade pode assumir um dos seguintes valores:

   • Initializing: A lista de servidores de back-end está sendo inicializada para as verificações de integridade.

   • Healthy: Todos os servidores de back-end estão íntegros.

   • Error: Um ou mais servidores de back-end apresentam falhas.

   • Disabled: As verificações de integridade não estão ativadas.

5. Clique em Error ou Initializing ao lado de um listener para ver detalhes, incluindo o listener ou regra de encaminhamento afetado, grupo de servidores, instância ECS e porta, status de integridade e motivo da falha.

Desativar verificações de integridade

É possível desativar as verificações de integridade. No entanto, se uma instância ECS de back-end apresentar falhas após a desativação, o CLB continuará encaminhando solicitações para ela, causando indisponibilidade parcial do service. Portanto, evite desativar as verificações de integridade.

1. Faça login no console do CLB.

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

3. Na página Instances, encontre a instância desejada e clique no ID da instância.

4. Na página de detalhes da instância, clique na aba Listener. Clique em Add Listener ou em Modify Listener na coluna Actions do listener alvo.

5. Siga o assistente de configuração até chegar à etapa Health Check.

6. Desative a chave de verificação de integridade, clique em Next e confirme as alterações.

Melhores práticas para verificações de integridade

Para garantir verificações de integridade precisas e confiáveis, siga estas melhores práticas:

• Crie um endpoint dedicado para verificação de integridade: Configure um endpoint específico no servidor de back-end, como /health, que sempre retorne código de status HTTP 200. Evite usar caminhos de negócio, como /, pois podem retornar códigos 4xx devido a verificações de permissão ou recursos inexistentes.

• Priorize a correção de problemas no back-end: Se as verificações retornarem códigos de status inesperados, diagnostique e corrija primeiro os problemas no service de back-end para assegurar que o caminho de verificação retorne códigos 2xx ou 3xx. Não simplesmente relaxe os critérios de status considerados normais.

• Simule verificações de integridade com curl: Durante a resolução de problemas, faça login em um servidor de back-end e execute o comando abaixo para simular as verificações do CLB:

  curl -Iv -X HEAD --http1.0 -H "Host: your-domain.com" http://127.0.0.1:80/health_path

  Neste comando, HEAD representa o método de verificação, your-domain.com é o domínio de verificação e /health_path corresponde ao caminho de verificação. Caso nenhum domínio esteja configurado, omita o parâmetro -H.

• Garanta que os blocos CIDR do CLB não estejam bloqueados: O CLB usa o bloco CIDR 100.64.0.0/10 para se comunicar com os servidores de back-end nas verificações de integridade. Certifique-se de que esse bloco não esteja bloqueado por iptables ou outras regras de firewall.

Referências

• Se você não estiver familiarizado com o mecanismo de verificação de integridade do CLB, consulte CLB health checks.

• Em caso de problemas com as verificações de integridade do CLB, veja CLB health check FAQ para troubleshooting.

• Use o recurso de log de verificação de integridade do CLB para analisar os logs dos servidores. Para mais informações, consulte Store and download health check logs.