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 de configuração do balanceador de carga
  • 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.

Para conectividade geral:

Para failover:

Para o próximo salto:

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:

Solução de problemas gerais de conectividade

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

  • Verifique as 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 as regras de firewall exigidas pelo balanceador de carga TCP/UDP interno, 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 o seguinte:

    • 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 estão aceitando 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 é implementado 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 TCP/UDP interno 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.

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 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 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 em um endereço IP no intervalo de destino de uma rota cujo próximo salto é uma regra de encaminhamento para um balanceador de carga TCP/UDP interno, observe que uma rota que usa esse tipo de próximo salto pode não processar ICMP tráfego 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 TCP/UDP interno 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 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.

A seguir