Server Load Balancer:Configurar e gerenciar verificações de integridade do CLB

Pré-requisitos

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

Limites

O protocolo do listener e o protocolo de verificação de integridade devem estar em conformidade com as seguintes regras:

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

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

• Listeners HTTP e HTTPS aceitam apenas o protocolo de verificação de integridade HTTP.

Configurar verificações de integridade

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

1. Faça logon no console do CLB.

2. Na barra de menu 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 desejado.

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

6. Clique em Advanced Settings e, em seguida, clique em Edit à direita para configurar as definiçõ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 de integridade TCP operam na camada de rede, enviando mensagens de handshake SYN para verificar se a porta do servidor está ativa. As verificações de integridade UDP utilizam mensagens UDP para obter informações de status. As verificações de integridade HTTP enviam solicitações HEAD ou GET para simular o acesso de um navegador e verificar se a aplicação do servidor está íntegra.
   Health Check Method (Compatível apenas com o protocolo de verificação de integridade HTTP)	Selecione o método HEAD ou GET. Por padrão, o método HEAD é utilizado. null Se o método HEAD não for compatível ou estiver desativado, utilize o método GET. Ao utilizar o método GET, as respostas com mais de 8 KB são truncadas. Isso não afeta o resultado da verificação de integridade.
   Health Check Port	A porta utilizada para verificações de integridade nos servidores de backend. Por padrão, o CLB utiliza a porta de cada servidor de backend. null Se os servidores de backend em um grupo de servidores utilizarem portas diferentes, não especifique uma porta de verificação de integridade. Nesse caso, o CLB utiliza a porta de cada servidor de backend para as verificações de integridade.
   Health Check Path (Compatível apenas com o protocolo de verificação de integridade HTTP)	Por padrão, o CLB envia uma solicitação HTTP para a página de índice padrão da aplicação para verificações de integridade. Se a página utilizada para verificações de integridade não for a página de índice padrão da aplicação, especifique o caminho exato. Recomendamos utilizar uma página estática para verificações de integridade.
   Health Check Domain Name (Optional) (Compatível apenas com 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 como o domínio. Se nenhum domínio estiver configurado, o campo Host é omitido. Alguns servidores de aplicação validam o campo Host. Se nenhum domínio estiver configurado, as solicitações podem ser rejeitadas, o que pode causar falhas na verificação de integridade. Se o servidor validar o campo Host, configure um domínio de verificação de integridade para garantir o sucesso das verificações. null When performing a health check, the load balancer ignores forwarding rules and sends requests to the health check path configured on the listener (the root path by default). If your backend services respond differently based on the request path, health checks sent to the default or a non-matching path may fail. You can configure a custom health check path for each forwarding rule as needed.
   Healthy Status Codes (Compatível apenas com o protocolo de verificação de integridade HTTP)	Selecione os códigos de status HTTP que indicam um servidor de backend í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 backend retornar um código de status 4xx, como 400, 403 ou 404, ou um código de status 5xx, como 500, 502 ou 503, a verificação de integridade falhará. O CLB então marca o servidor de backend como anormal e para de encaminhar tráfego para o servidor. null Se você aceitar códigos de status 4xx ou 5xx como íntegros, as instâncias com defeito podem não ser removidas prontamente do pool de servidores de backend. Por exemplo, se um servidor de backend retornar um erro 500 e você tiver configurado http_5xx como código de status normal, o CLB continuará encaminhando tráfego para a instância com defeito. Use essa configuração somente após avaliação cuidadosa. Recomendamos garantir que o servidor de backend retorne um código de status 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 serviço de backend não está implantado corretamente, há um problema de vinculação de domínio ou o método HEAD não é compatível. Erro 403: o servidor de backend nega acesso, há restrições baseadas em endereço IP ou a verificação de permissão falha. Erro 400: o cabeçalho Host está ausente, a versão HTTP é incompatível ou a solicitação está malformada.
   Health Check Response Timeout	O período máximo de espera por uma resposta de verificação de integridade. Se um servidor de backend não retornar uma resposta dentro do período de tempo limite especificado, a verificação de integridade falhará.
   Health Check Interval	O intervalo em que as verificações de integridade são realizadas. Todos os nós no cluster do CLB realizam verificações de integridade de forma independente no intervalo especificado. Como as verificações de integridade de diferentes nós não são sincronizadas, as solicitações de verificação de integridade recebidas por um servidor de backend podem não ter espaçamento uniforme. Por padrão, as verificações de integridade HTTP utilizam o método HEAD. As solicitações HEAD retornam apenas o código de status HTTP e os cabeçalhos, não o conteúdo completo da página. Portanto, cada verificação de integridade impõe uma carga mínima nos servidores de backend. Ao reduzir o intervalo, o número de solicitações de verificação de integridade aumenta. No entanto, a sobrecarga geralmente é desprezível em comparação com o tráfego de serviço normal.
   Healthy Threshold	O número de verificações de integridade bem-sucedidas consecutivas necessárias para que um Elastic Compute Service com falha seja considerado íntegro.
   Unhealthy Threshold	O número de verificações de integridade consecutivas com falha após o qual uma instância Elastic Compute Service é considerada não íntegra.
   Health Check Request e Health Check Result (Compatível apenas com o protocolo de verificação de integridade UDP)	Ao configurar verificações de integridade 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 backend para processar as respostas de verificação de integridade, como configurá-la para responder com slb123 a solicitações que contenham youraccountID. O CLB considera uma verificação de integridade bem-sucedida somente ao receber a resposta correta. Esse método maximiza a confiabilidade das verificações de integridade UDP.

7. Clique em Next até que o listener esteja configurado.

Visualizar o status de verificação de integridade

1. Faça logon no console do CLB.

2. Na barra de menu 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 para visualizar o status de verificação de integridade de cada listener.

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

   • Inicializando: a lista de servidores de backend está sendo inicializada para verificações de integridade.

   • Normal: todos os servidores de backend estão íntegros.

   • Anormal: um ou mais servidores de backend apresentam anomalias.

   • Desativado: as verificações de integridade não estão ativadas.

5. Clique em Error ou Initializing ao lado de um listener para visualizar detalhes, incluindo o listener ou a regra de encaminhamento afetados, 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 backend apresentar anomalias após a desativação, o CLB continuará encaminhando solicitações para a instância, o que causa indisponibilidade parcial do serviço. Portanto, recomendamos não desativar as verificações de integridade.

1. Faça logon no console do CLB.

2. Na barra de menu 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 desejado.

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

6. Desative o botão de alternância de verificação de integridade, clique em Next e confirme as alterações.

Práticas recomendadas para verificação de integridade

Para garantir verificações de integridade precisas e confiáveis, recomendamos seguir estas práticas recomendadas:

• Crie um endpoint dedicado para verificação de integridade: crie um endpoint dedicado no servidor de backend, como /health, que sempre retorne um código de status HTTP 200. Evite usar caminhos de negócio, como /, para verificações de integridade, pois eles podem retornar códigos de status 4xx devido a verificações de permissão ou recursos ausentes.

• Priorize a correção de problemas no backend: se as verificações de integridade retornarem códigos de status inesperados, primeiro diagnostique e corrija os problemas do serviço de backend para garantir que o caminho de verificação de integridade retorne um código de status 2xx ou 3xx. Não relaxe simplesmente os critérios para códigos de status normais.

• Simule verificações de integridade com curl: ao solucionar problemas, faça logon em um servidor de backend e execute o seguinte comando para simular verificações de integridade do CLB:

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

  Nesse comando, HEAD é o método de verificação de integridade, your-domain.com é o domínio de verificação de integridade e /health_path é o caminho de verificação de integridade. Se nenhum domínio estiver configurado, omita o parâmetro -H.

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

Referências

• Se você não está familiarizado com o mecanismo de verificação de integridade do CLB, consulte Verificações de integridade do CLB.

• Se encontrar problemas com as verificações de integridade do CLB, consulte FAQ de verificações de integridade do CLB para solução de problemas.

• Utilize o recurso de log de verificação de integridade do CLB para analisar logs de verificação de integridade dos servidores. Para mais informações, consulte Armazenar e baixar logs de verificação de integridade.