Este guia descreve como resolver problemas de configuração de um Google Cloud equilibrador de carga de rede de encaminhamento externo. Antes de investigar problemas, familiarize-se com as seguintes páginas:
- Vista geral do balanceador de carga de rede de encaminhamento externo
- Vista geral do balanceador de carga de rede de encaminhamento externo baseado em serviços de back-end
- Vista geral do Network Load Balancer de encaminhamento externo baseado em pool alvo
- Conceitos de comutação por falha para balanceadores de carga de rede de encaminhamento externo
- Registo e monitorização do balanceador de carga de rede de encaminhamento externo
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 Google Cloud consola como parte do Network Intelligence Center.
Aceda ao Analisador de redeResolva problemas de configuração
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:
- Restrições e orientações para grupos de instâncias
- Altere o modo de balanceamento de um balanceador de carga
Resolva problemas gerais de conetividade
Se não conseguir estabelecer ligação ao Network Load Balancer de encaminhamento externo, 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 externo, consulte o artigo Configurar regras de firewall.
Verifique se o agente convidado da Google está em execução 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 equilibrador de carga, é possível que o agente convidado da Google (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 agente convidado da Google 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 estão a aceitar pacotes enviados para o equilibrador 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 é implementado com uma rota local.
Para VMs criadas a partir de Google Cloud 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
Verifique 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 encaminhamento externo 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.
Para ver os serviços que estão a ouvir numa porta, execute o seguinte comando:
netstat -nl | grep ':PORT'
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 usando
curl
,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.
- A escuta (associada) ao endereço IP do balanceador de carga ou a qualquer endereço IP
(
Verifique 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.
Resolva problemas da VPC partilhada
Se estiver a usar a VPC partilhada e não conseguir criar um novo Network Load Balancer de passagem externo 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 externo, siga estes passos para validar a configuração:
- Certifique-se de que designou, pelo menos, um back-end de alternativa.
- Valide as definições da política de alternativa.
Certifique-se de que compreende como funciona a associação ao conjunto ativo e quando o sistema Google Cloud realiza a comutação por falha e a recuperação de falhas. Faça o seguinte para inspecionar a configuração do equilibrador de carga:
Use a Google Cloud consola para verificar o número de VMs de back-end em bom estado em cada grupo de instâncias de back-end. A Google Cloud 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 10 VMs principais e uma relação de comutação por falha definida como
0.2
, isto significa que Google Cloud faz uma comutação por falha quando menos de 2 (10 × 0.2 = 2
) VMs principais estão em bom estado. Uma taxa de comutação por falha de0.0
tem um significado especial: Google Cloud faz uma comutação por falha quando nenhuma VM principal está em bom estado.
Outros problemas que podem ocorrer:
O conjunto ativo está a alternar (a oscilar) entre os back-ends principal e de alternativa.
A utilização de grupos de instâncias geridos com escalamento automático e comutação por falha pode fazer com que o conjunto ativo comute por falha e volte a comutar por falha repetidamente entre os back-ends principal e de comutação por falha.O Google Cloud Load Balancing não impede que configure a comutação por falha com grupos de instâncias geridos, porque a sua implementação pode beneficiar desta configuração. Google Cloud
A desativação da drenagem da ligação não funciona.
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 --load-balancing-scheme external \ --health-checks-region us-central1 \ --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.
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 drenagem de ligações na comutação por falha está ativada.
Resolva problemas de registo
Se configurar o registo para um balanceador de carga de rede de encaminhamento externo, 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
.