Resolver problemas com balanceadores de carga de aplicativos internos

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:

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 Analyzer

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:

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 de max-rate-per-instance.
  • Use a política de tráfego de back-end LocalityLbPolicy com um algoritmo de balanceamento de carga de LEAST_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:

  1. 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 a destination_unavailable, o que indica que o balanceador de carga considera o back-end indisponível.

  2. 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 HTTP 200 OK do back-end.

  3. 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.