Server Load Balancer:CLB Health Check FAQ

Este tópico responde às seguintes perguntas:

Como funcionam as verificações de integridade?

As verificações de integridade confirmam o status do servidor enviando solicitações periódicas.

O CLB é implantado em um cluster. Os nós desse cluster realizam tanto o encaminhamento de dados quanto as verificações de integridade. Se um servidor backend falhar na verificação, o CLB interrompe a distribuição de novas solicitações de clientes para esse servidor não saudável.

O CLB utiliza o bloco CIDR 100.64.0.0/10 para as verificações de integridade. Seus servidores backend não devem bloquear o tráfego proveniente dessa faixa de endereços. Não é necessário adicionar uma regra de permissão no grupo de segurança da sua instância ECS, mas caso tenha configurado outras políticas de segurança, como iptables, permita o tráfego desse bloco CIDR. A faixa 100.64.0.0/10 é um espaço de endereçamento reservado da Alibaba Cloud e não apresenta riscos à segurança.

Para mais informações, consulte Verificações de integridade do CLB.

Quais são as configurações recomendadas para verificação de integridade?

Recomendamos as seguintes configurações de verificação de integridade.

Para evitar que mudanças frequentes de estado afetem a disponibilidade do sistema, a verificação de integridade altera seu status somente após ter sucesso ou falhar várias vezes consecutivas dentro de uma janela de tempo. Para mais informações, consulte Configure e gerencie verificações de integridade do CLB.

É possível desativar as verificações de integridade?

Sim. Para mais informações, consulte Desativar verificações de integridade.

Como escolher o método de verificação de integridade para um listener TCP?

Os listeners TCP suportam métodos de verificação de integridade HTTP e TCP:

• O método TCP verifica se a porta do servidor está ativa enviando pacotes SYN para realizar um handshake básico de três vias.

• O método HTTP envia solicitações HEAD ou GET para simular o acesso de um navegador e verificar se a aplicação no servidor está saudável.

As verificações TCP consomem menos recursos do servidor. Caso seus servidores backend sejam altamente sensíveis a carga e você precise apenas confirmar a disponibilidade da porta, escolha o método TCP. Se for necessário confirmar com mais precisão o status de integridade da aplicação, opte pelo método HTTP.

O que acontece se eu definir o peso de uma instância ECS como zero?

Definir o peso de uma instância ECS de backend como 0 impede que o CLB encaminhe tráfego para ela, embora as verificações de integridade continuem sendo aprovadas. Essa prática é comum durante manutenções planejadas, como reinicializações ou alterações de configuração.

Método padrão para verificações de integridade HTTP

O método HEAD.

curl -v -0 -I -H "Host:" -X HEAD http://IP:port

Endereços IP de source da verificação de integridade

As verificações de integridade do CLB usam o bloco CIDR 100.64.0.0/10. Garanta que seus servidores backend não bloqueiem esse bloco CIDR. Não é necessário adicionar uma regra específica de permissão no grupo de segurança da sua instância ECS, mas se você utilizar outras políticas de segurança, como iptables, permita o tráfego desse bloco. O bloco CIDR 100.64.0.0/10 é um espaço de endereçamento reservado utilizado pela Alibaba Cloud e não representa risco à segurança.

Quando começa uma verificação de integridade do CLB?

A verificação de integridade do CLB começa imediatamente após você configurá-la para um listener, enviando solicitações periódicas no intervalo de verificação de integridade especificado.

Falha na verificação de integridade devido a banco de dados defeituoso

• Sintoma

  Uma instância ECS hospeda dois sites: www.example.com (um site estático) e aliyundoc.com (um site dinâmico), ambos configurados com balanceamento de carga. Um problema no serviço de banco de dados backend causa um erro 502 ao acessar www.example.com.

• Causa

  A verificação de integridade está configurada com o domínio de verificação aliyundoc.com. Uma falha na instância do ApsaraDB RDS backend ou em um banco de dados autogerenciado torna aliyundoc.com inacessível, o que causa a falha da verificação de integridade para todo o servidor backend.

• Solução

  Altere o domínio de verificação de integridade na configuração do seu listener CLB para um domínio estático que não dependa do banco de dados, como www.example.com.

Erros de conexão apesar de verificações de integridade TCP bem-sucedidas

• Sintoma

  Após configurar um listener TCP no CLB, os logs da aplicação backend mostram frequentemente erros de conexão de rede. A análise de captura de pacotes indica que as solicitações se originam dos servidores CLB, que enviam ativamente pacotes RST para encerrar a conexão.

  

• Causa

  Esse problema ocorre devido ao mecanismo de verificação de integridade TCP. O CLB verifica a integridade da porta de um listener TCP completando um handshake de três vias e, em seguida, enviando imediatamente um pacote RST para fechar a conexão. O processo é o seguinte:

  1. O servidor CLB envia um pacote SYN para o servidor backend.

  2. O servidor backend responde com um pacote SYN+ACK.

  3. Após receber a resposta, o servidor CLB considera a porta saudável e marca a verificação de integridade como bem-sucedida.

  4. O servidor CLB envia um pacote RST para encerrar a conexão sem enviar nenhum dado de aplicação.

  Como a conexão é encerrada imediatamente após uma verificação de integridade bem-sucedida, alguns frameworks de aplicação (como um pool de conexões Java) podem interpretar isso como uma conexão anormal, resultando em erros como Connection reset by peer.

• Solução

  • Altere o protocolo de verificação de integridade do listener de TCP para HTTP.

  • No nível da aplicação, filtre as entradas de log provenientes do bloco CIDR de verificação de integridade do CLB (100.64.0.0/10) para ignorar esses erros esperados.

Falhas de verificação de integridade em um servidor saudável

• Sintoma

  As verificações de integridade HTTP do listener CLB falham consistentemente, mas testar o servidor backend diretamente com um comando curl retorna um código de status normal.

• Causa

  Uma verificação de integridade falha se o código de resposta HTTP do servidor não corresponder aos códigos de status esperados na configuração do listener. Por exemplo, se você configurar http_2xx como código de status esperado, qualquer resposta não-2xx do servidor backend será considerada uma falha na verificação de integridade.

  Em uma configuração Tengine/Nginx, o comando curl executa sem problemas, mas o comando echo corresponde ao site padrão, fazendo com que o arquivo de teste test.html retorne um erro 404.

  

• Solução

  • No arquivo de configuração principal do seu servidor web, comente ou configure corretamente o host virtual padrão.

  • Especifique um domínio de verificação de integridade na configuração de verificação de integridade do listener CLB para garantir que as solicitações sejam roteadas para o host virtual correto.

Discrepância na frequência de verificação de integridade nos logs

O serviço de verificação de integridade do CLB opera em um cluster de nós para evitar pontos únicos de falha. Cada nó no cluster realiza verificações de integridade independentemente. Essa arquitetura aumenta o número total de solicitações de verificação enviadas aos seus servidores backend. Consequentemente, a frequência de entradas de verificação de integridade nos logs do seu servidor web será maior do que a frequência configurada no console. Esse comportamento é esperado.

Como separar os logs de verificação de integridade dos logs de aplicação?

• Sintoma

  Os logs de solicitações de verificação de integridade estão misturados com os logs de tráfego normal da aplicação, tornando os arquivos de log grandes e difíceis de analisar.

• Causa

  As verificações de integridade enviam solicitações HTTP, TCP ou UDP para testar a disponibilidade do servidor backend. O serviço backend registra essas solicitações como qualquer outro tráfego, misturando-as aos logs da aplicação.

• Solução

  • Reduzir a frequência de verificação: Aumente o intervalo de verificação de integridade para gerar menos entradas de log de verificação.

  • Usar um caminho dedicado para verificação (para verificações HTTP): Defina o caminho de verificação de integridade para um caminho exclusivo, fora do fluxo de negócios, como /health. Assim, filtre seus logs pelo caminho da solicitação para separar o tráfego de verificação.

  • Desativar verificações de integridade (não recomendado): Se tiver certeza de que as verificações não são necessárias para o seu caso de uso, desative-as para parar a geração de logs de verificação.

Como solucionar uma falha na verificação de integridade?

As verificações de integridade determinam se os servidores backend estão funcionando corretamente. Quando uma verificação falha, isso geralmente indica um problema no servidor backend, mas uma configuração incorreta da verificação também pode causar falhas. Siga estas etapas para solucionar o problema.

1. Etapa 1: Verifique se o bloco CIDR 100.64.0.0/10 não está bloqueado.

   Garanta que seus servidores backend não bloqueiem o bloco CIDR 100.64.0.0/10 usando iptables ou outros firewalls e softwares de segurança de terceiros. O CLB usa endereços IP do bloco CIDR reservado interno 100.64.0.0/10 para se comunicar com os servidores backend. Se esse bloco CIDR estiver bloqueado, ocorrerão exceções na verificação de integridade.

2. Etapa 2: Teste o serviço backend com base no protocolo do listener.

   Escolha o método de teste apropriado com base no tipo de listener:

   Layer 4 (TCP/UDP)

   No console CLB, acesse a página de detalhes do listener e verifique a configuração de verificação de integridade. Confirme a Health Check Port, que por padrão é a porta do servidor backend. Em seguida, a partir de uma máquina com acesso ao servidor, execute o comando telnet para tentar uma conexão com a porta de verificação de integridade:

   telnet 172.17.58.131 80

   Substitua 172.17.58.131 pelo endereço IP privado do servidor backend e 80 pela porta real de verificação de integridade.

   • Cenário normal: Retorna Connected to xxx.xxx.xxx.xxx, indicando que a porta especificada no servidor backend está funcionando corretamente e a verificação de integridade está normal.

   • Resultado inesperado: O comando falha com uma mensagem "Connection refused" ou "Unable to connect". Isso indica que nenhum processo está escutando nessa porta. Verifique se o seu serviço backend está em execução e se está escutando na mesma porta especificada na configuração de verificação de integridade.

   Se um listener de Camada 4 usar o método HTTP para verificações de integridade, consulte as etapas de solução de problemas na aba "Layer 7 (HTTP/HTTPS)".

   Layer 7 (HTTP/HTTPS)

   No console CLB, acesse a página de detalhes do listener para visualizar a configuração de verificação de integridade da Camada 7 e confirme a Health Check Port, o Health Check Domain Name e o Health Check Path. Em seguida, a partir de um servidor backend (por exemplo, um sistema Linux), execute o comando nc ou curl para testar o serviço HTTP backend. O caminho, a porta e o domínio de verificação de integridade devem corresponder à configuração real no servidor backend. Caso contrário, as verificações falharão.

   Exemplo usando o comando nc:

   echo -e "HEAD /test.html HTTP/1.0\r\nHost: www.slb-test.com\r\n\r\n" | nc -t 172.17.58.131 80

   Substitua o caminho, domínio, IP e porta pelos valores do seu ambiente.

   • Cenário normal: Um código de status 200 ou outro 2xx/3xx é retornado, indicando que o serviço HTTP backend está saudável e a verificação de integridade foi bem-sucedida.

   • Situação anormal: Um código de erro como 404 é retornado e não corresponde aos códigos de status 2xx/3xx configurados para o listener CLB. Verifique se o recurso no caminho de verificação existe, se o domínio de verificação está configurado no servidor backend e se a porta de verificação está correta.