Neste guia, descrevemos como solucionar problemas de configuração de um balanceador de carga de aplicativo interno do Google Cloud. Antes de seguir este guia, conheça bem os seguintes tópicos:
- Visão geral do balanceador de carga interno do aplicativo
- Sub-redes somente proxy
- Geração de registros e monitoramento do balanceador de carga de aplicativo interno
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 AnalyzerOs 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:
- Restrições e orientações para grupos de instâncias
- Alterar o modo de balanceamento de um balanceador de carga
Tráfego com carga balanceada não tem endereço de origem do cliente original
Esse comportamento é esperado. Um balanceador de carga de aplicativo interno opera como um proxy reverso(gateway) HTTP (S). Quando um programa cliente abre uma conexão com o endereço IP de uma regra de encaminhamento INTERNAL_MANAGED, a conexão é encerrada em um proxy. O proxy processa as solicitações que chegam por meio dessa conexão. Para cada solicitação, o proxy seleciona um back-end para receber a solicitação com base no mapa de URLs e em outros fatores. Em seguida, o proxy envia a solicitação ao back-end selecionado. Como resultado, do ponto de vista do back-end, a origem de um pacote de entrada é um endereço IP da sub-rede somente proxy da região.
As solicitações são rejeitadas pelo balanceador de carga
Para cada solicitação, o proxy seleciona um back-end para receber a solicitação com base em uma correspondência de caminho no mapa de URL do balanceador de carga. Se o mapa de URL não tiver uma correspondência
definida para a solicitação, ele não poderá selecionar um serviço de back-end, retornando o código de resposta
HTTP 404
(Não encontrado).
O balanceador de carga não se conecta a back-ends
Os firewalls que protegem seus servidores de back-end precisam ser configurados para permitir tráfego de entrada dos proxies no intervalo de sub-rede somente proxy alocado para a região do balanceador de carga HTTP(S).
Os proxies conectam-se a back-ends usando as definições de conexão especificadas pela configuração de seu serviço de back-end. Se esses valores não corresponderem à configuração dos servidores em execução nos seus back-ends, o proxy não poderá encaminhar solicitações para os back-ends.
As sondagens de verificação de integridade não conseguem alcançar os back-ends
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.
Os clientes não se conectam ao balanceador de carga
Os proxies detectam conexões com o endereço IP e a porta do balanceador de carga
configurados na regra de encaminhamento (por exemplo, 10.1.2.3:80
) e com o
protocolo especificado na regra de encaminhamento (HTTP ou HTTPS). Se seus clientes
não se conectarem, verifique se estão usando o endereço, a porta e o protocolo corretos.
Verifique se o firewall não está bloqueando o tráfego entre as instâncias do cliente e o endereço IP com balanceamento de carga.
Verifique se os clientes estão na mesma região que o balanceador de carga. O balanceamento de carga HTTP(S) interno é um produto regional, portanto todos os clientes (e back-ends) precisam estar na mesma região do recurso do balanceador de carga.
Restrição de política organizacional para VPC compartilhada
Se você estiver usando uma VPC compartilhada e não conseguir criar um novo balanceador de carga de aplicativo interno em uma sub-rede específica, uma política da organização poderá 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 constraints/compute.restrictSharedVpcSubnetworks
.
O balanceador de carga não distribui o tráfego de maneira uniforme pelas zonas
Você pode observar um desequilíbrio no tráfego do balanceador de carga interno do seu aplicativo entre as zonas. Isso pode acontecer especialmente quando há pouca utilização (menos de 10%) da sua capacidade de back-end.
Esse comportamento pode afetar a latência geral porque o tráfego é enviado apenas para alguns servidores em uma zona.
Para uniformizar a distribuição de tráfego entre zonas, faça as alterações de configuração a seguir:
- Use o modo de
balanceamento
RATE
com uma capacidade de destino baixa demax-rate-per-instance
. - Use a política de tráfego
de back-end
LocalityLbPolicy
com um algoritmo de balanceamento de carga deLEAST_REQUEST
.
Erros 5xx
desconhecidos
Para condições de erro causadas por um problema de comunicação entre o proxy do
balanceador de carga e os back-ends dele, o balanceador de carga gera um código de status HTTP
(5xx
) e retorna esse código ao cliente. Nem todos os erros HTTP 5xx
são gerados pelo balanceador de carga. Por exemplo, se um back-end envia
uma resposta HTTP 5xx
para o balanceador de carga, o balanceador de carga redireciona essa
resposta para o cliente. Para determinar se uma resposta HTTP 5xx
foi redirecionada
de um back-end ou se foi gerada pelo proxy do balanceador de carga, consulte o
campo proxyStatus
dos registros do balanceador
de carga..
As mudanças de configuração no balanceador de carga de aplicativo interno, como a adição ou
remoção de um serviço de back-end, podem resultar em um breve período em que os usuários
vêm o código de status HTTP 503
. Embora essas mudanças de configuração
sejam propagadas para os
Envoys no mundo inteiro,
você verá entradas de registro em que o campo proxyStatus
corresponde à
string de registro connection_refused
.
Se os códigos de status HTTP 5xx
persistirem por mais tempo após a conclusão
da configuração do balanceador de carga, siga estas etapas para resolver problemas
de respostas HTTP 5xx
:
Verifique se há uma regra de firewall configurada para permitir verificações de integridade. Na ausência de um, os registros do balanceador de carga normalmente têm um
proxyStatus
correspondente adestination_unavailable
, o que indica que o balanceador de carga considera o back-end indisponível.Confira se o tráfego de verificação de integridade atinge as VMs de back-end. Para fazer isso, ative a geração de registros de verificação de integridade e pesquise entradas de registro bem-sucedidas.
Para novos balanceadores de carga, a falta de entradas de registro de verificação de integridade bem-sucedidas não significa que o tráfego de verificação de integridade não esteja alcançando seus back-ends. Isso pode significar que o estado de integridade inicial do back-end ainda não mudou de
UNHEALTHY
para um estado diferente. Você verá entradas de registro de verificação de integridade bem-sucedidas somente depois que a sondagem de verificação de integridade receber uma resposta HTTP200 OK
do back-end.Verifique se o parâmetro de configuração do sinal de atividade do software do servidor HTTP em execução na instância de back-end não é menor que o tempo limite do sinal de atividade do balanceador de carga, cujo valor é fixo em 10 minutos (600 segundos) e é não configurável.
O balanceador de carga gera um código de status HTTP
5xx
quando a conexão com o back-end é fechada inesperadamente ao enviar a solicitação HTTP ou antes de receber a resposta HTTP completa. Isso pode acontecer porque o parâmetro de configuração do sinal de atividade do software de servidor da Web em execução na instância de back-end é menor que o tempo limite fixo do sinal de atividade do balanceador de carga. Verifique se a configuração de tempo limite do sinal de atividade do software de servidor HTTP em cada back-end está definida como um pouco maior que 10 minutos (o valor recomendado é 620 segundos).
Limitações
Se você estiver com problemas para usar um balanceador de carga de aplicativo interno com outros recursos de rede do Google Cloud, observe as atuais limitações de compatibilidade.