Resolva problemas de balanceadores de carga de rede de encaminhamento interno

Este guia descreve como resolver problemas de configuração de um Cloud de Confiance by S3NS Network Load Balancer de encaminhamento interno. Antes de investigar problemas, familiarize-se com as seguintes páginas:

Resolva problemas comuns com o analisador de rede

O Network Analyzer monitoriza automaticamente a configuração da sua rede VPC e deteta configurações abaixo do ideal e configurações incorretas. Identifica falhas de rede, fornece informações sobre a causa principal e sugere possíveis resoluções. Para saber mais acerca dos diferentes cenários de configuração incorreta que são detetados automaticamente pelo Network Analyzer, consulte as Estatísticas do equilibrador de carga na documentação do Network Analyzer.

O analisador de rede está disponível na Cloud de Confiance consola como parte do Network Intelligence Center.

Aceda ao Analisador de rede

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

Ao criar um equilibrador de carga, pode ver 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.

Isto acontece quando 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 mais informações, consulte o seguinte:

Resolva problemas gerais de conetividade

Se não conseguir estabelecer ligação ao seu Network Load Balancer de encaminhamento interno, verifique os seguintes problemas comuns.

Valide as regras de firewall

  • Certifique-se de que as regras de firewall de permissão de entrada estão definidas para permitir verificações de funcionamento em VMs de back-end.
  • Certifique-se de que as regras de firewall de permissão de entrada permitem o tráfego para as VMs de back-end a partir de clientes.
  • Certifique-se de que existem regras de firewall relevantes para permitir que o tráfego alcance as VMs de back-end nas portas usadas pelo balanceador de carga.
  • Se estiver a usar etiquetas de destino para as regras da firewall, certifique-se de que as VMs de back-end do equilibrador de carga estão etiquetadas adequadamente.

Para saber como configurar as regras de firewall necessárias pelo seu Network Load Balancer de passagem interno, consulte o artigo Configurar regras de firewall.

Verifique se o ambiente de convidado está a ser executado na VM de back-end

Se conseguir estabelecer ligação a uma VM de back-end em bom estado, mas não conseguir estabelecer ligação ao balanceador de carga, é possível que o ambiente convidado (anteriormente, o ambiente convidado do Windows ou o ambiente convidado do Linux) na VM não esteja em execução ou não consiga comunicar com o servidor de metadados (metadata.google.internal, 169.254.169.254).

Verifique o seguinte:

  • Certifique-se de que o ambiente de convidado está instalado e em execução na VM de back-end.
  • Certifique-se de que as regras de firewall no sistema operativo 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 tem de ser configurada para aceitar pacotes enviados para o balanceador de carga. Ou seja, o destino dos pacotes enviados para as VMs de back-end é o endereço IP do balanceador de carga. Na maioria dos casos, isto é feito com um trajeto local.

Para VMs criadas a partir de Cloud de Confiance imagens, o agente convidado instala a rota local para o endereço IP do balanceador de carga. As instâncias do Google Kubernetes Engine baseadas no SO otimizado para contentores implementam esta funcionalidade através da utilização de iptables.

Numa VM de back-end do Linux, pode verificar a presença da rota local executando o seguinte comando. Substitua LOAD_BALANCER_IP pelo endereço IP do balanceador de carga:

sudo ip route list table local | grep LOAD_BALANCER_IP

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

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

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

  • A escuta (associada) ao endereço IP do balanceador de carga ou a qualquer endereço IP (0.0.0.0 ou ::)
  • A ouvir (associado a) uma porta incluída na regra de encaminhamento do balanceador de carga

Para testar esta situação, estabeleça ligação a uma VM de back-end através de SSH ou RDP. Em seguida, faça os seguintes testes com o curl, o telnet ou uma ferramenta semelhante:

  • Tente aceder ao serviço contactando-o através do endereço IP interno da própria VM de back-end, 127.0.0.1 ou anfitrião local.
  • Tente alcançar o serviço contactando-o através do endereço IP da regra de encaminhamento do balanceador de carga.

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

Se o cliente que se liga ao balanceador de carga estiver noutra região, certifique-se de que o acesso global está ativado.

Confirme se o tráfego de verificação de funcionamento consegue alcançar as VMs de back-end

Para verificar se o tráfego de verificação de funcionamento chega às VMs de back-end, ative o registo da verificação de funcionamento e pesquise entradas de registo bem-sucedidas.

Também pode verificar se a funcionalidade do equilibrador de carga está em bom estado ao ver o estado"Em bom estado" para o back-end.

Se não existirem instâncias em bom estado no back-end, certifique-se de que a verificação de funcionamento adequada está configurada e que cada VM no back-end está a ouvir nas portas de verificação de funcionamento configuradas.

A partir de um cliente na mesma rede VPC, execute o seguinte comando para verificar se a VM de back-end está a escutar numa porta TCP específica:

telnet SERVER_IP_ADDRESS PORT

Substitua o seguinte:

  • SERVER_IP_ADDRESS: o endereço IP da VM de back-end.
  • PORT: a porta que configurou para a verificação de estado. Por predefinição, a porta de verificação de funcionamento é 80.

Em alternativa, pode usar o SSH para ligar a VM de back-end e executar o seguinte comando:

curl localhost:PORT

Mais uma vez, substitua PORT pela porta que configurou para a verificação de estado.

Outra forma de realizar este teste é executar o seguinte comando:

netstat -npal | grep LISTEN

No resultado, verifique o seguinte:

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

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

Resolva problemas de desempenho

Se estiver a notar problemas de desempenho e um aumento da latência, verifique os seguintes problemas comuns.

Valide a funcionalidade do servidor

Se todos os servidores de back-end estiverem a responder às verificações de estado, verifique se os pedidos do cliente estão a funcionar corretamente quando emitidos diretamente no servidor. Por exemplo, se o cliente estiver a enviar pedidos HTTP para o servidor através do balanceador de carga e não houver resposta ou a resposta for substancialmente mais lenta do que o normal, emita o mesmo pedido HTTP em cada um dos servidores de back-end e observe o comportamento.

Se algum dos servidores de back-end individuais não estiver a funcionar corretamente quando o pedido é emitido a partir do próprio servidor, pode concluir que a pilha de aplicações do servidor não está a funcionar corretamente. Pode concentrar-se na resolução de problemas da própria aplicação. Se todos os servidores estiverem a funcionar corretamente, o passo seguinte é analisar o lado do cliente e a rede.

Verifique a conetividade e a latência da rede

Se todos os servidores de back-end estiverem a responder aos pedidos corretamente, verifique a latência da rede. Numa VM cliente, emita um comando ping constante para cada um dos servidores, da seguinte forma:

ping SERVER_IP_ADDRESS

Este teste mostra a latência da rede incorporada e se a rede está a perder pacotes. Em alguns casos, as regras de firewall podem estar a bloquear o tráfego ICMP. Se for o caso, este teste não produz nenhum resultado. Confirme junto do administrador das regras de firewall se é este o caso.

Se o comando ping apresentar uma latência significativamente superior ao normal ou uma perda de pacotes significativa, abra um registo de Cloud de Confiance apoio técnico para investigar mais detalhadamente.

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

Se o teste de ping rede sugerir uma latência baixa e nenhuma perda de pacotes, o passo seguinte é identificar que combinação específica de cliente-servidor, se existir, produz resultados problemáticos. Pode fazê-lo reduzindo o número de servidores de back-end para metade até o número de servidores atingir 1, enquanto reproduz simultaneamente o comportamento problemático (por exemplo, latência elevada ou sem respostas).

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

Se não for identificada nenhuma combinação cliente-servidor problemática, avance para os testes de desempenho.

Realize a captura e a análise de tráfego

Se identificar uma combinação específica problemática de cliente-servidor, pode usar a captura de pacotes para identificar a parte da comunicação que está a causar atrasos ou falhas. A captura de pacotes pode ser feita com o tcpdump da seguinte forma:

  1. Instale o tcpdump no servidor.
  2. Inicie a captura do tcpdump no servidor.

  3. De um cliente, emita um pedido de exemplo, como o seguinte:

    curl URL

  4. Analise a saída do tcpdump para identificar o problema.

Faça testes de desempenho

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

  1. Um cliente e um servidor, sem equilíbrio de carga.

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

    Resultado: a combinação dos resultados dos testes [1] e [2] identifica se o problema está a ser causado pelo equilibrador de carga.

  3. Um cliente e vários servidores, com equilíbrio de carga.

    Resultado: identifique o limite de desempenho de um cliente.

  4. Vários clientes e um servidor, com balanceamento de carga.

    Resultado: identificar o limite de desempenho de um servidor.

  5. Vários clientes e vários servidores, sem equilíbrio de carga.

    Resultado: identifique o limite de desempenho da rede.

Quando executa um teste de esforço com vários clientes e servidores, os recursos do cliente ou do servidor (CPU, memória, E/S) podem tornar-se gargalos e reduzir os resultados agregados. Os resultados agregados degradados podem ocorrer mesmo que cada cliente e servidor esteja a funcionar corretamente.

Resolva problemas da VPC partilhada

Se estiver a usar a VPC partilhada e não conseguir criar um novo Network Load Balancer de encaminhamento interno numa sub-rede específica, a causa pode ser uma política da organização. Na política da organização, adicione a sub-rede à lista de sub-redes permitidas ou contacte o administrador da organização. Para mais informações, consulte a restrição constraints/compute.restrictSharedVpcSubnetworks.

Resolva problemas de comutação por falha

Se configurou a comutação por falha para um Network Load Balancer de encaminhamento interno, as secções seguintes descrevem os problemas que podem ocorrer.

Conetividade

  • Certifique-se de que designou, pelo menos, um back-end de alternativa.
  • Valide as definições da política de alternativa:
    • Rácio de comutação por falha
    • Diminuir o tráfego quando todas as VMs de back-end estão em mau estado de funcionamento
    • Desativar a drenagem da ligação na comutação por falha

Problemas com grupos de instâncias geridas e com a comutação por falha

  • Sintoma: o conjunto ativo está a alternar (a oscilar) entre os back-ends principal e de alternativa.
  • Motivo possível: a utilização de grupos de instâncias geridos com o dimensionamento automático e a comutação por falha pode fazer com que o conjunto ativo comute por falha e comute de volta repetidamente entre os back-ends principal e de comutação por falha. Cloud de Confiance não impede a configuração da comutação por falha com grupos de instâncias geridos, porque a sua implementação pode beneficiar desta configuração.

Desative a restrição de esgotamento de ligações para grupos de comutação por falha

A desativação da drenagem de ligações só funciona se o serviço de back-end estiver configurado com o protocolo TCP.

A seguinte mensagem de erro é apresentada se criar um serviço de back-end com UDP enquanto o esgotamento de ligações está desativado:

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.

O tráfego é enviado para VMs de back-end inesperadas

Primeiro, verifique o seguinte: se a VM do cliente também for uma VM de back-end do balanceador de carga, é um comportamento esperado que as ligações enviadas para o endereço IP da regra de encaminhamento do balanceador de carga sejam sempre respondidas pela própria VM de back-end. Para mais informações, consulte os artigos Testar ligações a partir de um único cliente e Enviar pedidos a partir de VMs com balanceamento de carga.

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

  • Para pedidos de um único cliente, consulte o artigo Testar ligações a partir de um único cliente para compreender as limitações deste método.

  • Certifique-se de que configurou regras de firewall de permissão de entrada para permitir verificações de estado.

  • Para uma configuração de alternativa, certifique-se de que compreende como funciona a associação ao conjunto ativo e quando oCloud de Confiance realiza a alternativa e a recuperação. Inspeccione a configuração do equilibrador de carga:

    • Use a Cloud de Confiance consola para verificar o número de VMs de back-end em bom estado em cada grupo de instâncias de back-end. A Cloud de Confiance consola também mostra as VMs que estão no conjunto ativo.

    • Certifique-se de que a taxa de comutação por falha do equilibrador de carga está definida corretamente. Por exemplo, se tiver dez VMs principais e uma relação de comutação por falha definida como 0.2, isto significa que Cloud de Confiance faz uma comutação por falha quando menos de duas (10 × 0.2 = 2) VMs principais estão em bom estado. Uma taxa de comutação por falha de 0.0 tem um significado especial: Cloud de Confiance faz uma comutação por falha quando nenhuma VM principal está em bom estado.

As ligações existentes são terminadas durante a comutação por falha ou a recuperação de falhas

Edite a política de comutação por falha do serviço de back-end. Certifique-se de que a eliminação de ligações na comutação por falha está ativada.

Resolva problemas de encaminhamento do equilibrador de carga

Quando define um balanceador de carga de rede de encaminhamento interno como um salto seguinte de uma rota estática personalizada, podem ocorrer os seguintes problemas:

Problemas de conetividade

  • Se não conseguir enviar um ping para um endereço IP no intervalo de destino de uma rota cujo salto seguinte seja uma regra de encaminhamento para um balanceador de carga de rede de passagem interna, tenha em atenção que uma rota que use este tipo de salto seguinte pode não processar tráfego ICMP, consoante a data de criação da rota. Se a rota foi criada antes de 15 de maio de 2021, apenas processa o tráfego TCP e UDP até 16 de agosto de 2021. A partir de 16 de agosto de 2021, todas as rotas encaminham automaticamente todo o tráfego de protocolo (TCP, UDP e ICMP), independentemente da data de criação de uma rota. Se não quiser esperar até essa data, pode ativar a funcionalidade de ping agora criando novas rotas e eliminando as antigas.

  • Quando usa um balanceador de carga de rede de passagem interno como um próximo salto para uma rota estática personalizada, todo o tráfego é entregue às VMs de back-end em bom estado do balanceador de carga, independentemente do protocolo configurado para o serviço de back-end interno do balanceador de carga e independentemente da porta ou das portas configuradas na regra de encaminhamento interno do balanceador de carga.

  • Certifique-se de que criou regras de firewall de permissão de entrada que identificam corretamente as origens de tráfego que devem ser fornecidas às VMs de back-end através do próximo salto da rota estática personalizada. Os pacotes que chegam às VMs de back-end preservam os respetivos endereços IP de origem, mesmo quando são entregues através 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 na sua rede VPC. Se 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 pode 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 secção Aplicabilidade e ordem para mais informações.

  • Se os pacotes forem para um destino inesperado, remova outros percursos na sua rede VPC com destinos mais específicos. Reveja a ordem do planeamento de trajeto para compreender a Cloud de Confiance seleção de trajetos.

Resolva problemas de registo

Se configurar o registo para um Network Load Balancer de encaminhamento interno, podem ocorrer os seguintes problemas:

  • As medições de RTT, como os valores de bytes, podem estar em falta em alguns dos registos se não forem amostrados pacotes suficientes para capturar o RTT. Isto é mais provável de acontecer para ligações de baixo volume.
  • Os valores de RTT só estão disponíveis para fluxos TCP.
  • Alguns pacotes são enviados sem payload. Se forem amostrados pacotes apenas com cabeçalho, o valor de bytes é 0.

O que se segue?