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 confirme o status do servidor por meio do envio de 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 de back-end falhar na verificação, o CLB interrompe a distribuição de novas solicitações de clientes para esse servidor não íntegro.

O CLB utiliza o bloco CIDR 100.64.0.0/10 para as verificações de integridade. Seus servidores de back-end 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 de segurança.

Para mais informações, consulte CLB health checks.

Quais são as configurações recomendadas para verificações 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 obter sucesso ou falha em múltiplas tentativas consecutivas dentro de uma janela de tempo. Para mais informações, consulte Configure and gerencie CLB health checks.

Posso desativar as verificações de integridade?

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

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

Os listeners TCP suportam os 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á íntegra.

As verificações de integridade TCP consomem menos recursos do servidor. Se seus servidores de back-end forem altamente sensíveis à carga e você precisar apenas confirmar a disponibilidade da porta, escolha o método TCP. Caso necessite confirmar com mais precisão o status de integridade da aplicação, opte pelo método HTTP.

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

Definir o peso de uma instância ECS de back-end 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 origem das verificações de integridade

As verificações de integridade do CLB utilizam o bloco CIDR 100.64.0.0/10. Garanta que seus servidores de back-end não bloqueiem esse bloco CIDR. Não é necessário adicionar uma regra de permissão específica 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 proveniente desse bloco. O bloco CIDR 100.64.0.0/10 é um espaço de endereçamento reservado usado pela Alibaba Cloud e não apresenta riscos de segurança.

Quando uma verificação de integridade do CLB é iniciada?

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

Falha na verificação de integridade devido a 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 service de banco de dados de back-end 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 de back-end 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 de back-end.

• 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 de back-end 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 ativamente pacotes RST 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 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 do CLB envia um pacote SYN para o servidor de back-end.

  2. O servidor de back-end responde com um pacote SYN+ACK.

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

  4. O servidor do 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 originadas 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 íntegro

• Sintoma

  As verificações de integridade HTTP do listener CLB falham consistentemente, mas testar o servidor de back-end 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ê configure http_2xx como código de status esperado, qualquer resposta não-2xx do servidor de back-end 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.

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

Discrepância na frequência de verificações de integridade nos logs

O service de verificação de integridade do CLB executa 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 de back-end. 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 logs de verificação de integridade dos logs da aplicação?

• Sintoma

  Os logs de solicitações de verificação de integridade misturam-se aos 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 de back-end. O service de back-end 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 e não relacionado a negócios, como /health. Em seguida, filtre seus logs pelo caminho da solicitação para separar o tráfego de verificação de integridade.

  • Desativar verificações de integridade (não recomendado): Se tiver certeza de que as verificações de integridade 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 de back-end estão funcionando corretamente. Quando uma verificação falha, isso geralmente indica um problema no servidor de back-end, 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 de back-end não bloqueiem o bloco CIDR 100.64.0.0/10 usando iptables ou outros firewalls de terceiros ou softwares de segurança. O CLB usa endereços ip do bloco CIDR reservado interno 100.64.0.0/10 para se comunicar com os servidores de back-end. Se esse bloco CIDR estiver bloqueado, ocorrerão exceções na verificação de integridade.

2. Etapa 2: Teste o service de back-end 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 do 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 de back-end. 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 de back-end 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 de back-end 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 seu service de back-end 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 do CLB, acesse a página de detalhes do listener para visualize 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 de back-end (por exemplo, um sistema Linux), execute o comando nc ou curl para testar o service HTTP de back-end. O caminho, a porta e o domínio de verificação de integridade devem corresponder à configuração real no servidor de back-end. Caso contrário, as verificações de integridade 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 service HTTP de back-end está íntegro 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 de integridade existe, se o domínio de verificação está configurado no servidor de back-end e se a porta de verificação está correta.

Por que não consigo encontrar registros de falha de verificação de integridade do CLB no console?

Os logs de verificação de integridade são gerados uma vez por hora e retidos por apenas 3 dias por padrão. Se o status de verificação de integridade de um listener CLB não mudar dentro de 3 dias, nenhum log de verificação será gerado. Armazene os logs de verificação de integridade no oss para uma retenção mais longa.