Troubleshoot NLB health check failures - Server Load Balancer: Central de Documentação do Alibaba Cloud

A verificação de integridade de um Network Load Balancer (NLB) confirma se os servidores de back-end estão funcionando corretamente. Uma falha nessa verificação geralmente indica problemas em um servidor de back-end. No entanto, configurações incorretas da própria verificação ou dos servidores também podem causar essas falhas. Este tópico descreve como solucionar falhas de verificação de integridade do NLB.

Sintomas

O Health Check Status de um listener de uma instância NLB apresenta o status Unhealthy.

Causas

Se a verificação de integridade falhar logo após a configuração inicial, verifique primeiro as definições da verificação. A falha pode ocorrer pelos seguintes motivos:

Parâmetros de verificação de integridade incorretos
Problemas na porta do listener

Se a verificação de integridade falhar após ter funcionado com sucesso anteriormente, investigue primeiramente os servidores de back-end. A falha pode ser causada por um dos seguintes fatores:

Problemas com software de segurança
Configuração de rota incorreta
Alta carga no servidor de back-end
Limite de conexões atingido no servidor de back-end

Soluções

Falhas na verificação de integridade após a configuração inicial

Causa 1: Parâmetros de verificação de integridade incorretos

Faça login no console do NLB.
Na barra de navegação superior, selecione a região onde a instância NLB está implantada.
No painel de navegação à esquerda, escolha NLB > Server Groups.
Na página Server Groups, localize o grupo de servidores associado à instância NLB desejada e clique em Modify Health Check Settings.
Na caixa de diálogo Modify Health Check Settings, verifique se os parâmetros de verificação de integridade estão corretos. Recomenda-se utilizar as configurações padrão.

Causa 2: Problemas na porta do listener

Verifique a porta de verificação de integridade.
1. Faça login no console do NLB.
2. Na barra de navegação superior, selecione a região onde a instância NLB está implantada.
3. No painel de navegação à esquerda, escolha NLB > Server Groups.
4. Na página Server Groups, encontre o grupo de servidores vinculado à instância NLB alvo e clique no id do grupo de servidores.
5. Na página de detalhes do grupo de servidores, clique na aba Backend Servers para visualizar e anotar as portas dos servidores de back-end.
6. Ainda na página de detalhes do grupo de servidores, clique na aba Details. Na seção Health Check, clique em Modify Health Check Settings. Na caixa de diálogo Modify Health Check Settings, visualize e registre os parâmetros de verificação de integridade.
TCP listener
1. Acesse o servidor de back-end e execute o comando abaixo para testar a conectividade com a porta de verificação de integridade.
  Para obter informações sobre como acessar um servidor de back-end, consulte Connect to an ECS instance.
  
  telnet [$IP] [$Port]
  
  Nota
  
  [$IP] representa o endereço ip privado do servidor de back-end.
  
  [$Port] corresponde à porta de sondagem da verificação de integridade do grupo de servidores. Por padrão, trata-se da porta do próprio servidor de back-end. Caso uma porta específica tenha sido configurada para a verificação, essa porta será utilizada.
2. Analise a saída do comando.
  
  Uma resposta semelhante a "telnet: connect to address [$IP]: Connection refused" indica que a conexão foi recusada e que a porta de verificação de integridade está inoperante.
  Trying xxx.xxx.xxx.xxx... telnet: connect to address xxx.xxx.xxx.xxx: Connection refused
  Já uma resposta como "Connected to [$IP]" sinaliza que a porta de verificação de integridade está escutando adequadamente.
  Trying 1xxx... Connected to 1xxx.
UDP listener
1. Conecte-se ao servidor de back-end e execute o seguinte comando para verificar o status da porta de verificação de integridade.
  Para saber como acessar um servidor de back-end, veja Connect to an ECS instance.
  
  netstat -anu | grep [$IP]:[$Port]
  
  Nota
  
  [$IP] é o endereço ip privado do servidor de back-end.
  
  [$Port] refere-se à porta de sondagem da verificação de integridade do grupo de servidores. O valor padrão é a porta do servidor de back-end, mas se houver uma porta específica configurada para a verificação, esta prevalecerá.
2. Verifique o resultado do comando.
  
  Caso nenhum registro para [$IP]:[$Port] seja retornado, a porta de verificação de integridade não está saudável.
  [rxxxxx xjZ ~]# netstat -anu | grep 192.168 :53 [xxxxx pxjZ ~]#
  Se houver um retorno para [$IP]:[$Port], significa que a porta de verificação de integridade está operando normalmente.
  [rxxx ~]# netstat -anu | grep 192.168.xxx.xxx:53 udp 0 0 192.168.xxx.xxx:53 0.0.0.0:*
Confirme se a aplicação está em execução no servidor de back-end e se utiliza a porta correta para a verificação de integridade. Esta seção toma um service Nginx como exemplo.
1. Acesse o servidor de back-end com problema e execute o comando a seguir para checar o status do service Nginx.
```
systemctl status nginx
```
2. Uma saída similar à apresentada abaixo indica que o service não está ativo.
```
● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
```
3. Execute o comando seguinte para iniciar o service Nginx.
```
systemctl start nginx
```
4. Execute novamente o comando para validar o status do service Nginx.
```
systemctl status nginx
```
  Uma resposta conforme o exemplo abaixo confirma que o service está em execução.
```
● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: active (running) since Mon xxx CST; 2h 20min ago
```
5. Faça login no console do Network Load Balancer (NLB) e siga os passos abaixo.
  1. No painel de navegação à esquerda, escolha NLB > Server Groups.
  2. Na página Server Groups, localize o grupo de servidores desejado e clique em Modify Health Check Settings na coluna Actions.
  3. Na caixa de diálogo Modify Health Check Settings, verifique a porta de verificação de integridade [$Port]. Certifique-se de que a opção Health Check esteja ativada, que o Health Check Protocol esteja definido como TCP e que a Health Check Port seja 80.
  4. Verifique o status da verificação de integridade. Se ainda estiver como Unhealthy, execute o comando abaixo para identificar a porta de escuta do service Nginx.
```
netstat -tanp |grep nginx
```
6. Caso a saída seja parecida com a seguinte, a porta de escuta não corresponde ao valor de [$Port].
```
tcp        0      0 0.0.0.0:81              0.0.0.0:*               LISTEN      22855/nginx: master
tcp6       0      0 :::81                   :::*                    LISTEN      22855/nginx: master
```
  Edite o arquivo /etc/nginx/nginx.conf. Localize e altere o valor de listen para [$Port], salve as alterações e saia.
  
  Nota
  Se não for possível alterar o valor de listen devido aos requisitos do seu cenário, modifique a porta de verificação de integridade para o protocolo correspondente. Para mais detalhes, consulte NLB listeners.
```
server {
    listen       80;
    listen       [::]:80;
    server_name  _;
    root         /usr/share/nginx/html;
    # Load configuration files for the default server block.
    include /etc/nginx/default.d/*.conf;
}
```
7. Execute o comando a seguir para reiniciar o service Nginx. Aguarde alguns instantes e confirme se a verificação de integridade voltou ao normal.
```
systemctl restart nginx
```

Falhas na verificação de integridade após funcionamento prévio

Causa 1: Problemas com software de segurança

A instância NLB utiliza um bloco CIDR da VPC para se comunicar com os servidores de back-end. Softwares de segurança nesses servidores, como iptables ou outras soluções de políticas de terceiros, não devem bloquear o tráfego proveniente desse bloco CIDR. O bloqueio desse tráfego provoca falhas na verificação de integridade e impede o funcionamento correto do NLB. Esta seção usa o iptables como exemplo para verificar se há intervalos de endereços ip privados bloqueados.

Acesse o console do Network Load Balancer (NLB) e identifique o endereço ip local que a instância NLB usa para se comunicar com os servidores de back-end.

Na lista de instâncias, encontre a instância alvo e visualize o endereço ip na coluna Local IP, por exemplo, 192.168.20.75.

Nota
Uma instância NLB pode possuir múltiplos endereços Local IP (distribuídos por várias zonas, podendo haver mais de um dentro de uma única zona). No console, visualize e permita todos os endereços Local IP. Qualquer controle de acesso baseado em ip de source (como iptables, grupos de segurança ou listas de permissões do RDS) deve permitir todos eles. Se algum endereço Local IP for bloqueado, poderão ocorrer falhas na verificação de integridade ou timeouts intermitentes de conexão.

Conecte-se à instância do servidor de back-end com problema e execute o comando abaixo para listar todas as regras da tabela filter.

iptables -nL

Uma resposta semelhante à seguinte indica que o servidor de back-end está rejeitando requisições originadas do endereço ip local da instância NLB.

# iptables  -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       all  --  192.168.20.75        0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Execute o comando a seguir para remover essa regra.
```
iptables -t filter -D INPUT -s 192.168.20.75 -j DROP  # The IP address is for demonstration purposes only.
```
Nota
Substitua o endereço ip no comando pelo endereço ip privado utilizado pela sua instância NLB.
Execute o comando abaixo para confirmar que as requisições vindas do intervalo de ips privados do NLB não estão mais sendo bloqueadas.
```
iptables -nL
```
Confirme se o Health Check Status do listener do NLB mudou para Healthy.

Causa 2: Configuração de rota incorreta

Uma rota mal configurada no servidor de back-end para o bloco CIDR da VPC usado pela instância NLB pode impedir que as sondagens de verificação de integridade cheguem ao destino, resultando em falhas. Esta seção utiliza o comando Linux route como exemplo para validar a configuração de rotas.

Acesse o console do Network Load Balancer (NLB) e verifique o endereço ip local que a instância NLB utiliza para comunicação com os servidores de back-end.
Entre no servidor de back-end com falha e execute o comando seguinte para inspecionar a configuração atual de rotas.
```
route -n
```
A configuração de rota estará incorreta se existir uma entrada onde o Destination seja o endereço ip local da instância NLB, o Genmask seja 255.255.255.255 e o Gateway não corresponda ao gateway padrão da interface de rede. O gateway padrão é o endereço ip listado na coluna Gateway quando o Destination é 0.0.0.0.
```
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         xxx             0.0.0.0         UG    0      0        0 eth0
xxx             0.0.0           255.255.0.0     U     1002   0        0 xxx
192.168.20.75   0.0.0.0         255.255.255.255 UH    0      0        0 *
```
Execute o comando abaixo para excluir a rota incorreta.
```
ip route del blackhole 192.168.20.75 # The IP address is for demonstration purposes only.
```
Nota
Substitua o endereço ip presente no comando pelo endereço ip privado utilizado pela sua instância NLB.
Valide se o Health Check Status do listener do NLB passou para Healthy.

Causa 3: Alta carga no servidor de back-end

Consulte Troubleshoot and resolve high load issues on Linux instances para determinar se a alta carga do servidor está provocando a falha.

Causa 4: Limite de conexões atingido no servidor de back-end

Quando um servidor de back-end (como um Pod ACS) atinge seu limite de conexões TCP, ele fica impossibilitado de aceitar novas conexões. Se o NLB estiver configurado com verificações de integridade via TCP, a sonda falhará porque o back-end não consegue estabelecer a nova conexão, fazendo com que o NLB marque automaticamente o backend como Unhealthy.

Um back-end marcado como Unhealthy deixa de receber novas conexões. Conexões persistentes já estabelecidas não são afetadas e continuam funcionando normalmente.
Esse comportamento gera alertas de Unhealthy. Configure alertas de limiar de contagem de conexões no Cloud Monitor para receber avisos prévios antes que o limite de conexões seja atingido.
Assim que o back-end se recuperar e voltar a aceitar novas conexões, as verificações de integridade serão aprovadas automaticamente e o NLB remarcará o back-end como Healthy, retomando o encaminhamento de novas conexões.

Nota

O NLB não possui um recurso nativo para limitar o encaminhamento de conexões com base na quantidade de conexões ativas. O uso de verificações de integridade para essa finalidade é um mecanismo indireto. Essa abordagem se aplica quando o limite de conexões do back-end impede a porta de aceitar novas conexões.

Referências

Você também pode utilizar o recurso de diagnóstico de instâncias NLB para solucionar falhas de verificação de integridade. Para mais informações, consulte NLB instance diagnostics.