Solução de problemas de balanceadores de carga de rede de passagem interna

Neste guia, descrevemos como resolver problemas de configuração de um balanceador de carga de rede de passagem interna do Google Cloud. Antes de investigar os problemas, conheça as páginas a seguir.

Resolver problemas comuns com o Network Analyzer

O Network Analyzer monitora automaticamente as configurações da rede VPC e detecta configurações incorretas e não ideais. Ele identifica falhas de rede, fornece informações sobre a causa raiz e sugere possíveis soluções. Para saber mais sobre os diferentes cenários de configuração incorreta que são detectados automaticamente pelo Network Analyzer, consulte Insights do balanceador de carga na documentação do Network Analyzer.

O Network Analyzer está disponível no console do Google Cloud como parte do Network Intelligence Center.

Acessar o Network Analyzer

Os back-ends têm modos de balanceamento incompatíveis

Ao criar um balanceador de carga, talvez você veja o erro:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Isso acontece quando você tenta usar o mesmo back-end em dois balanceadores de carga diferentes, e os back-ends não têm modos de balanceamento compatíveis.

Para ver mais informações, consulte os seguintes tópicos:

Resolver problemas gerais de conectividade

Se você não conseguir se conectar ao balanceador de carga de rede de passagem interna, verifique os seguintes problemas comuns.

Verificar regras de firewall

Verifique se as regras de firewall de permissão de entrada estão configuradas para permitir verificações de integridade em VMs de back-end.
Verifique se as regras de firewall de permissão de entrada permitem o tráfego nas VMs de back-end dos clientes.
Verifique se há regras de firewall relevantes para permitir que o tráfego alcance as VMs de back-end nas portas usadas pelo balanceador de carga.
Se você estiver usando tags de destino para as regras de firewall, verifique se as VMs de back-end do balanceador de carga estão marcadas corretamente.

Para saber como configurar regras de firewall exigidas pelo balanceador de carga de rede de passagem interna, consulte Como configurar regras de firewall.

Verifique se o ambiente de convidado está em execução na VM de back-end

Se você consegue se conectar a uma VM de back-end íntegra, mas não consegue se conectar ao balanceador de carga, pode ser que o ambiente de convidado (antes chamado de ambiente de convidado do Windows/Linux) da VM não esteja em execução ou não consiga se comunicar com o servidor de metadados (metadata.google.internal, 169.254.169.254).

Verifique:

Verifique se o ambiente do convidado está instalado e em execução na VM de back-end.
Verifique se as regras de firewall no sistema operacional convidado da VM de back-end (iptables ou firewall do Windows) não bloqueiam o acesso ao servidor de metadados.

Verifique se as VMs de back-end aceitam pacotes enviados para o balanceador de carga

Cada VM de back-end precisa ser configurada para aceitar os pacotes enviados ao balanceador de carga. Ou seja, o destino dos pacotes entregues às VMs de back-end é o endereço IP do balanceador de carga. Na maioria das vezes, isso é feito com uma rota local.

Para VMs criadas com base em imagens do Google Cloud, o agente de convidado instala a rota local para o endereço IP do balanceador de carga. As instâncias do Google Kubernetes Engine baseadas no Container-Optimized OS implementam isso usando iptables.

Em uma VM de back-end do Linux, execute o comando a seguir para verificar a presença da rota local. Substitua LOAD_BALANCER_IP pelo endereço IP do balanceador de carga:

sudo ip route list table local | grep LOAD_BALANCER_IP

Verifique o endereço IP e a vinculação de porta do serviço nas VMs de back-end

Os pacotes enviados para um balanceador de carga de rede de passagem interna chegam às VMs de back-end com o endereço IP de destino do próprio balanceador de carga. Esse tipo de balanceador de carga não é um proxy e esse é o comportamento esperado.

O software em execução na VM de back-end precisa fazer o seguinte:

Detectar (vincular a) o endereço IP do balanceador de carga ou qualquer endereço IP (0.0.0.0 ou ::)
Detectar (vincular a) uma porta incluída na regra de encaminhamento do balanceador de carga

Para testar isso, conecte-se a uma VM de back-end usando SSH ou RDP. Em seguida, execute os seguintes testes usando curl, telnet ou uma ferramenta semelhante:

Tente acessar o serviço entrando em contato com ele pelo endereço IP interno da própria VM de back-end, 127.0.0.1 ou localhost.
Tente acessar o serviço entrando em contato com ele pelo endereço IP da regra de encaminhamento do balanceador de carga.

Verifique se a VM cliente está na mesma região que o balanceador de carga

Se o cliente conectado ao balanceador de carga estiver em outra região, verifique se o acesso global está ativado.

Verifique se o tráfego da verificação de integridade pode alcançar as VMs de back-end

Para confirmar se o tráfego de verificação de integridade atinge as VMs de back-end, ative a geração de registros de verificação de integridade e pesquise entradas de registro bem-sucedidas.

Também é possível verificar se a funcionalidade do balanceador de carga está íntegra visualizando o estado "íntegro" do back-end.

Se não houver instâncias íntegras no back-end, confira se a verificação de integridade apropriada está configurada e se cada VM no back-end está escutando nas portas de verificação de integridade configuradas.

Em um cliente na mesma rede VPC, execute o seguinte comando para verificar se a VM de back-end está escutando em uma porta TCP específica:

telnet SERVER_IP_ADDRESS PORT

Substitua:

SERVER_IP_ADDRESS: o endereço IP da VM de back-end.
PORT: a porta que você configurou para a verificação de integridade. Por padrão, a porta da verificação de integridade é 80.

Como alternativa, é possível usar o SSH para conectar a VM de back-end e executar o seguinte comando:

curl localhost:PORT

Novamente, substitua PORT pela porta que você configurou para a verificação de integridade.

Outra maneira de realizar esse teste é executar o seguinte comando:

netstat -npal | grep LISTEN

Na saída, verifique por:

<var>LB_IP_ADDRESS</var>:<var>PORT</var>
0.0.0.0:<var>PORT</var>
:::<var>PORT</var>

Isso não determina se o roteamento está configurado corretamente para responder ao endereço IP do balanceador de carga. Esse é um problema separado com um sintoma parecido. Para roteamento, execute o comando ip route list table local e verifique se o endereço IP do balanceador de carga está listado, conforme descrito em Verificar se as VMs de back-end aceitam pacotes enviados ao balanceador de carga.

Resolver problemas de desempenho

Se você estiver com problemas de desempenho e aumentar a latência, verifique os problemas comuns a seguir.

Verificar a funcionalidade do servidor

Se todos os servidores de back-end estiverem respondendo a verificações de integridade, verifique se as solicitações do cliente estão funcionando corretamente quando emitidas diretamente no servidor. Por exemplo, se o cliente estiver enviando solicitações HTTP ao servidor por meio do balanceador de carga, e não houver resposta ou a resposta for substancialmente mais lenta do que o normal, emita a mesma solicitação HTTP emcada um dos servidores de back-end e observe o comportamento.

Se algum dos servidores de back-end individuais não estiver se comportando corretamente quando a solicitação for emitida no próprio servidor, conclua que a pilha de aplicativos do servidor não está funcionando corretamente. É possível se concentrar ainda mais na solução de problemas do aplicativo. Se todos os servidores estiverem se comportando corretamente, a próxima etapa será analisar o lado do cliente e a rede.

Verifique a conectividade e a latência da rede

Se todos os servidores de back-end estiverem respondendo às solicitações corretamente, verifique a latência da rede. Em uma VM cliente, emita um comando de ping constante para cada um dos servidores, da seguinte forma:

ping SERVER_IP_ADDRESS

Este teste mostra a latência de rede integrada e se a rede está descartando pacotes. Em alguns casos, as regras de firewall podem estar bloqueando o tráfego ICMP. Nesse caso, essa falha no teste não produzirá nenhum resultado. Verifique com seu administrador de regras de firewall se esse é o caso.

Se o comando ping mostrar latência significativamente maior do que a perda de pacote normal ou significativa, abra um caso de suporte do Google Cloud para investigar mais.

Identificar combinações problemáticas de cliente-servidor

Se o teste de rede ping sugerir baixa latência e nenhuma perda de pacotes, a próxima etapa será identificar qual combinação específica de cliente-servidor, se houver, produzirá problemas. Para isso, reduza o número de servidores de back-end pela metade até que o número de servidores chegue a 1. Ao mesmo tempo, reproduz o comportamento problemático (por exemplo, alta latência ou nenhuma resposta).

Se você identificar uma ou mais combinações problemáticas de cliente-servidor, realize a captura e a análise do tráfego.

Se nenhuma combinação problemática de cliente-servidor for identificada, pule para o teste de desempenho.

Capturar e analisar tráfego

Se você identificar uma combinação problemática específica de cliente-servidor, poderá usar a captura de pacotes para identificar a parte da comunicação que está causando atraso ou quebra. A captura de pacote pode ser feita com tcpdump da seguinte maneira:

Instale o tcpdump no servidor.
Inicie a captura de tcpdump no servidor.
A partir de um cliente, emita uma solicitação de amostra, como esta:
```
curl URL
```
Analise a saída do tcpdump para identificar o problema.

Fazer testes de desempenho

Se você não identificar combinações problemáticas de cliente-servidor e o desempenho agregado de todos os clientes e servidores juntos for menor que o esperado, considere os seguintes testes:

Um cliente e um servidor, sem balanceamento de carga.
Um cliente e um servidor, com balanceamento de carga.

Resultado: a combinação de resultados dos testes [1] e [2] identifica se o balanceador de carga está causando o problema.
Um cliente e vários servidores, com balanceamento de carga.

Resultado: identifique o limite de desempenho de um cliente.
Vários clientes e um servidor, com balanceamento de carga.

Resultado: identifique o limite de desempenho de um servidor.
Vários clientes e vários servidores, sem balanceamento de carga.

Resultado: identifique o limite de desempenho da rede.

Ao executar um teste de estresse com vários clientes e servidores, os recursos deles (como CPU, memória e E/S) podem se tornar gargalos e reduzir os resultados agregados. Os resultados agregados degradados podem acontecer mesmo se cada cliente e servidor estiverem se comportando corretamente.

Resolver problemas de VPC compartilhada

Se você estiver usando a VPC compartilhada e não for possível criar um novo balanceador de carga de rede de passagem interna em uma sub-rede específica, uma política da organização pode ser a causa. Na política da organização, adicione a sub-rede à lista de sub-redes permitidas ou entre em contato com o administrador da organização. Para ver mais informações, consulte a restrição constraints/compute.restrictSharedVpcSubnetworks.

Resolver problemas de failover

Se você tiver configurado o failover para um balanceador de carga de rede de passagem interna, verá nas seções a seguir descrições dos problemas que podem ocorrer.

Conectividade

Verifique se você designou pelo menos um back-end de failover.
Verifique suas configurações de política de failover:
- Proporção de failover
- Tráfego em queda quando todas as VMs de back-end não forem íntegras
- Desativação da diminuição da conexão no failover

Problemas com failover e grupos de instâncias gerenciadas

Sintoma: o pool ativo está alternando entre os back-ends primário e de failover.
Causa possível: o uso de grupos de instâncias gerenciadas com escalonamento automático e failover pode fazer com que o pool ativo realize failover e failback repetidamente entre os back-ends primário e de failover. O Google Cloud não impede que você configure o failover com grupos de instâncias gerenciadas, porque sua implantação pode se beneficiar dessa configuração.

Desativar a restrição da diminuição da conexão para grupos de failover

Desativar a diminuição da conexão só funciona se o serviço de back-end estiver configurado com o protocolo TCP.

A seguinte mensagem de erro será exibida se você criar um serviço de back-end com UDP enquanto a diminuição da conexão estiver desativada:

gcloud compute backend-services create my-failover-bs \
    --global-health-checks \
    --load-balancing-scheme=internal \
    --health-checks=my-tcp-health-check \
    --region=us-central1 \
    --no-connection-drain-on-failover \
    --drop-traffic-if-unhealthy \
    --failover-ratio=0.5 \
    --protocol=UDP
ERROR: (gcloud.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

Tráfego enviado para VMs de back-end inesperadas

Primeiro, verifique o seguinte: se a VM cliente também for uma VM de back-end do balanceador de carga, as conexões enviadas ao endereço IP da regra de encaminhamento do balanceador de carga serão sempre respondidas pela própria VM de back-end. Para mais informações, consulte como testar conexões a partir de um único cliente e como enviar solicitações a partir de VMs com balanceamento de carga.

Se a VM cliente não for uma VM de back-end do balanceador de carga:

Para solicitações de um único cliente, consulte como testar conexões de um único cliente para entender as limitações desse método.
Verifique se você configurou a permissão de entrada nas regras de firewall para permitir verificações de integridade.
Para uma configuração de failover, compreenda como funciona a assinatura no pool ativo e quando o Google Cloud realiza failover e failback. Inspecione a configuração do seu balanceador de carga:
- Use o console do Google Cloud para verificar o número de VMs de back-end íntegras em cada grupo de instâncias de back-end. O console do Google Cloud também mostra quais VMs estão no pool ativo.
- Verifique se a proporção de failover do seu balanceador de carga está definida corretamente. Por exemplo, se você tiver 10 VMs primárias e uma taxa de failover configurada em 0.2, o Google Cloud realizará um failover quando menos de 2 (10 × 0.2 = 2) VMs primárias forem íntegras. Uma proporção de failover de 0.0 tem um significado especial: o Google Cloud realiza um failover quando nenhuma VM primária for íntegra.

Conexões atuais encerradas durante o failover ou o failback

Edite a política de failover do seu serviço de back-end. Verifique se a diminuição da conexão no failover está ativada.

Resolver problemas de balanceador de carga como próximo salto

Quando você define um balanceador de carga de rede de passagem interna como próximo salto de uma rota estática personalizada, os seguintes problemas podem ocorrer:

Problemas de conectividade

Se não for possível dar um ping em um endereço IP no intervalo de destino de uma rota em que o próximo salto é uma regra de encaminhamento para um balanceador de carga de rede de passagem interna, observe que uma rota que usa esse tipo de próximo salto pode não processar tráfego ICMP dependendo de quando a rota foi criada. Se a rota foi criada antes de 15 de maio de 2021, ela processa apenas o tráfego TCP e UDP até 16 de agosto de 2021. A partir de 16 de agosto de 2021, todas as rotas encaminharão automaticamente todo o tráfego de protocolo (TCP, UDP e ICMP), independentemente de quando uma rota foi criada. Se não quiser esperar até lá, é possível ativar a funcionalidade de ping agora criando novas rotas e excluindo as antigas.
Ao usar um balanceador de carga de rede de passagem interna como próximo salto para uma rota estática personalizada, todo o tráfego é entregue às VMs de back-end íntegras do balanceador de carga, independentemente do protocolo configurado para o serviço de back-end interno do balanceador de carga e independentemente das portas configuradas na regra de encaminhamento interno do balanceador de carga.
Certifique-se de que você criou regras de firewall de permissão de entrada que identificam corretamente as origens de tráfego que precisam ser entregues às VMs de back-end por meio do próximo salto da rota estática personalizada. Os pacotes que chegam nas VMs de back-end preservam os endereços IP de origem, mesmo quando são entregues por meio de uma rota estática personalizada.

Valor inválido para o intervalo de destino

O intervalo de destino de uma rota estática personalizada não pode ser mais específico do que qualquer rota de sub-rede em sua rede VPC. Se você receber a seguinte mensagem de erro ao criar uma rota estática personalizada:

Invalid value for field 'resource.destRange': [ROUTE_DESTINATION].
[ROUTE_DESTINATION] hides the address space of the network .... Cannot change
the routing of packets destined for the network.

Não é possível criar uma rota estática personalizada com um destino que corresponda exatamente ou seja mais específico (com uma máscara mais longa) do que uma rota de sub-rede. Consulte a aplicabilidade e a ordem para mais informações.
Se os pacotes forem para um destino inesperado, remova outras rotas na sua rede VPC com destinos mais específicos. Leia a ordem de roteamento para entender a seleção de rotas do Google Cloud.

Resolver problemas de geração de registros

Se você configurar a geração de registros para um balanceador de carga de rede de passagem interna, os seguintes problemas poderão ocorrer:

As medições de RTT, como valores de bytes, poderão estar ausentes em alguns dos registros se não houver pacotes suficientes na amostragem para capturar RTT. É mais provável que isso aconteça para conexões de baixo volume.
Valores RTT estão disponíveis apenas para fluxos TCP.
Alguns pacotes são enviados sem payload. Se houver amostras de pacotes somente de cabeçalho, o valor de bytes será 0.

A seguir

Para informações sobre como configurar o Logging e o Monitoring dos balanceadores de carga de rede de passagem interna, consulte esta página.
Para informações sobre como acessar balanceadores de carga de rede de passagem interna por redes de peering conectadas à rede VPC, consulte esta página.