Solução de problemas de balanceamento de carga TCP/UDP interno

Neste guia, você verá como solucionar problemas de configuração de balanceadores de carga TCP/UDP internos do Google Cloud.

Visão geral

Tipos de problemas discutidos neste guia:

  • Problemas gerais de conectividade
  • Problemas de failover de back-end
  • Problemas de balanceador de carga como próximo salto

Antes de começar

Antes de investigar os problemas, conheça as páginas a seguir.

Sobre conectividade geral:

Sobre failover:

Sobre próximo salto:

Solução de problemas gerais de conectividade

  • Sintoma: não consigo me conectar ao meu balanceador de carga TCP/UDP interno de um cliente de VM em outra região.
  • Motivo: o acesso global não está ativado.

Se você não conseguir se conectar a um balanceador de carga TCP/UDP interno, verifique os seguintes problemas:

  • 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 o cliente conectado ao balanceador de carga está na mesma região do balanceador de carga. Se o cliente estiver em outra região, verifique se o acesso global está ativado.

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

  • Sintoma: não consigo me conectar ao meu serviço por meio do meu balanceador de carga TCP/UDP interno, mas consigo me conectar diretamente a uma VM de back-end.

  • Motivo: O ambiente do convidado não está em execução ou não consegue se comunicar com o servidor de metadados (metadata.google.internal, 169.254.169.254).

Verifique:

  • se o ambiente do convidado está instalado e em execução na VM de back-end;
  • se as regras de firewall no sistema operacional convidado da VM de back-end (iptables, firewall do Windows) não bloqueiam o acesso ao servidor de metadados;
  • se o serviço na VM de back-end está escutando ao endereço IP da regra de encaminhamento do balanceador de carga.

Solução de problemas de VPC compartilhada

Se você estiver usando a VPC compartilhada e não for possível criar um novo balanceador de carga TCP/UDP interno 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.

Solução de problemas de failover

Se você tiver configurado o failover para um balanceador de carga TCP/UDP interno, 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 GCP 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 Cloud para verificar o número de VMs de back-end íntegras em cada grupo de instâncias de back-end. O Console do 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.

Solução de problemas do balanceador de carga como próximo salto

Quando você define um balanceador de carga TCP/UDP interno como o próximo salto de uma rota estática personalizada, os seguintes problemas podem ocorrer:

Conectividade

  • Se não for possível dar um ping no seu back-end, lembre-se de que uma rota com o balanceador de carga TCP/UDP interno definido como o próximo salto só é suportada para tráfego TCP e UDP. Outros pacotes de protocolo, como ICMP, são ignorados pelo balanceador de carga. Para mais informações, consulte TCP, UDP e outro tráfego de protocolo.

  • Ao usar um balanceador de carga TCP/UDP interno como próximo salto para uma rota estática personalizada, todo o tráfego TCP e UDP é 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 da porta ou 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.

Tags de rede não são compatíveis

Não é possível atribuir uma tag de rede a uma rota estática personalizada quando o próximo salto for um balanceador de carga TCP/UDP interno. Por exemplo, o seguinte comando gcloud produz a mensagem de erro mostrada abaixo:

$ gcloud compute routes create example-route \
--destination-range=0.0.0.0/0 \
--next-hop-ilb=internal-lb-forwarding-rule \
--tags='my_tag'

ERROR: (gcloud.compute.routes.create) Could not fetch resource:
 - Invalid value for field 'resource.tags': ''. Tag is not supported for routes
 with next hop ilb.

A seguir