Server Load Balancer:Perguntas frequentes sobre health check do CLB

Este tópico responde às seguintes perguntas:

Como funcionam os health checks?

Os health checks confirmam o status do servidor enviando solicitações periódicas.

O CLB opera em um cluster. Os nós desse cluster realizam tanto o encaminhamento de dados quanto os health checks. Se um servidor de backend falhar em um health check, o CLB para de distribuir novas solicitações de clientes para esse servidor com problema.

O CLB usa o bloco CIDR 100.64.0.0/10 para os health checks. Seus servidores de backend não devem bloquear o tráfego desse intervalo de endereços. Não é necessário adicionar uma regra de permissão no grupo de segurança do ECS, mas se você configurou outras políticas de segurança, como iptables, é preciso permitir o tráfego desse bloco CIDR. O intervalo 100.64.0.0/10 é um espaço de endereços reservado do Alibaba Cloud e não apresenta risco de segurança.

Para mais informações, consulte Health checks do CLB.

Quais são as configurações de health check recomendadas?

Recomendamos as seguintes configurações de health check.

Para evitar que mudanças frequentes de status afetem a disponibilidade do sistema, o health check só altera seu status após obter sucesso ou falha múltiplas vezes consecutivas dentro de uma janela de tempo. Para mais informações, consulte Configurar e gerenciar health checks do CLB.

Posso desativar os health checks?

Sim. Para mais informações, consulte Desativar health checks.

Como escolher o método de health check para um listener TCP?

Os listeners TCP suportam os métodos de health check 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á íntegra.

Os health checks TCP consomem menos recursos do servidor. Se seus servidores de backend forem muito sensíveis à carga e você precisar apenas confirmar a disponibilidade da porta, use o método TCP. Se precisar confirmar com mais precisão o status de integridade da aplicação, use o 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 faz com que o CLB pare de encaminhar tráfego para ela, embora os health checks continuem sendo aprovados. Essa prática é comum durante manutenções programadas, como reinicializações ou alterações de configuração.

Método padrão para health checks HTTP

O método HEAD.

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

Endereços IP de origem do health check

Os health checks do CLB usam o bloco CIDR 100.64.0.0/10. Certifique-se de que seus servidores de backend não bloqueiem esse bloco CIDR. Não é necessário adicionar uma regra de permissão específica no grupo de segurança do ECS, mas se você usar outras políticas de segurança como iptables, é preciso permitir o tráfego desse bloco. O bloco CIDR 100.64.0.0/10 é um espaço de endereços reservado usado pelo Alibaba Cloud e não apresenta risco de segurança.

Quando o health check do CLB é iniciado?

O health check do CLB inicia imediatamente após você configurá-lo para um listener, enviando solicitações periódicas no intervalo de health check especificado.

Falha de health check por banco de dados com defeito

• 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 de backend causa um erro 502 ao acessar www.example.com.

• Causa

  O health check está configurado com o domínio de health check aliyundoc.com. Uma falha na instância do ApsaraDB RDS de backend ou em um banco de dados autogerenciado torna aliyundoc.com inacessível, o que causa a falha do health check para todo o servidor de backend.

• Solução

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

Erros de conexão mesmo com health checks TCP aprovados

• Sintoma

  Após configurar um listener TCP no CLB, os logs da aplicação de 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 do CLB, que enviam pacotes RST ativamente para encerrar a conexão.

  java.io.IOException  Connection reset by peer
  	at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
  	at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
  	at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
  	at sun.nio.ch.IOUtil.read(IOUtil.java:192)
  	at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
  	at io.netty.buffer.UnpooledUnsafeDirectByteBuf.setBytes(UnpooledUnsafeDirectByteBuf.java:446)
  	at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:871)
  	at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:225)
  	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:115)
  	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
  	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
  	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
  	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
  	at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
  	at java.lang.Thread.run(Thread.java:745)

• Causa

  Esse problema ocorre devido ao mecanismo de health check 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 funciona da seguinte forma:

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

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

  3. Ao receber a resposta, o servidor do CLB considera a porta íntegra e marca o health check como bem-sucedido.

  4. O servidor do CLB envia um pacote RST para encerrar a conexão, sem enviar dados da aplicação.

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

• Solução

  • Altere o protocolo de health check do listener de TCP para HTTP.

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

Falhas de health check em um servidor íntegro

• Sintoma

  Os health checks HTTP do listener do CLB falham consistentemente, mas testar o servidor de backend diretamente com o comando curl retorna um código de status normal.

• Causa

  Um health check 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 que não seja 2xx do servidor de backend é considerada uma falha de health check.

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

  [root@iZ28sxxxZ home]# echo -e "HEAD /test.html HTTP/1.0\r\n\r\n" | nc -t 10.161.93.136 80
  HTTP/1.1 404 Not Found
  Server: Tengine/2.1.0
  Date: Mon, 16 Feb 2015 07:29:32 GMT
  Content-Type: text/html
  Content-Length: 585
  Connection: close
  
  [root@iZ28sxxxZ home]# curl -I http://10.161.93.136/test.html
  HTTP/1.1 200 OK
  Server: Tengine/2.1.0
  Date: Mon, 16 Feb 2015 07:29:41 GMT
  Content-Type: text/html
  Content-Length: 5
  Last-Modified: Mon, 16 Feb 2015 07:27:00 GMT
  Connection: keep-alive
  ETag: "54e19bc4-5"
  Accept-Ranges: bytes

• 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 health check na configuração de health check do listener do CLB para garantir que as solicitações sejam roteadas para o host virtual correto.

Incompatibilidade de frequência de health check nos logs

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

Como separar os logs de health check dos logs da aplicação?

• Sintoma

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

• Causa

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

• Solução

  • Reduza a frequência do health check: Aumente o intervalo de health check para gerar menos entradas de log de health check.

  • Use um caminho dedicado para health check (para health checks HTTP): Defina o caminho de health check para um caminho dedicado, fora do fluxo de negócio, como /health. Em seguida, filtre seus logs pelo caminho da solicitação para separar o tráfego de health check.

  • Desative os health checks (não recomendado): Se você tiver certeza de que os health checks não são necessários para o seu caso de uso, desative-os para parar de gerar logs de health check.

Como solucionar uma falha de health check?

Os health checks determinam se os servidores de backend estão funcionando corretamente. Quando um health check falha, isso geralmente indica um problema no servidor de backend, mas uma configuração de health check incorreta 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.

   Certifique-se de que seus servidores de backend não bloqueiem o bloco CIDR 100.64.0.0/10 usando iptables ou outro firewall ou software 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 de backend. Se esse bloco CIDR estiver bloqueado, ocorrerão exceções de health check.

2. Etapa 2: Teste o serviço de backend de acordo com o protocolo do listener.

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

   Camada 4 (TCP/UDP)

   No console do CLB, acesse a página de detalhes do listener e verifique a configuração de health check. Confirme a Health Check Port, que por padrão é a porta do servidor de 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 health check:

   telnet 172.17.58.131 80

   Substitua 172.17.58.131 pelo endereço IP privado do servidor de backend e 80 pela porta de health check real.

   • Caso normal: Retorna Connected to xxx.xxx.xxx.xxx, indicando que a porta especificada no servidor de backend está funcionando corretamente e o health check 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 serviço de backend está em execução e se está escutando na mesma porta especificada na configuração de health check.

   Se um listener de camada 4 usar o método HTTP para health checks, consulte as etapas de solução de problemas na aba "Camada 7 (HTTP/HTTPS)".

   Camada 7 (HTTP/HTTPS)

   No console do CLB, acesse a página de detalhes do listener para visualizar a configuração de health check de 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 de backend (por exemplo, um sistema Linux), execute o comando nc ou curl para testar o serviço HTTP de backend. O caminho, a porta e o domínio de health check devem corresponder à configuração real no servidor de backend. Caso contrário, os health checks 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, o domínio, o IP e a porta pelos valores do seu ambiente.

   • Caso normal: É retornado um código de status 200 ou outro código 2xx/3xx, indicando que o serviço HTTP de backend está íntegro e o health check foi bem-sucedido.

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

Por que não consigo encontrar registros de falha de health check do CLB no console?

Os logs de health check são gerados uma vez por hora e retidos por apenas 3 dias por padrão. Se o status de health check de um listener do CLB não mudar dentro de 3 dias, nenhum log de health check é gerado. Você pode armazenar logs de health check no OSS para uma retenção mais longa.