Resolva problemas com equilibradores de carga de aplicações externos

Este guia descreve como resolver problemas de configuração de equilibradores de carga de aplicações externos. Antes de investigar problemas, familiarize-se com as seguintes páginas:

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 rede

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:

Resolva problemas gerais de conetividade

Erros 5XX inexplicáveis

Para condições de erro causadas por um problema de comunicações entre o proxy do balanceador de carga e os respetivos back-ends, o balanceador de carga gera um código de resposta de erro HTTP (5XX) e devolve esse código de resposta de erro ao cliente. Nem todos os erros HTTP 5XX são gerados pelo balanceador de carga. Por exemplo, se um back-end enviar uma resposta HTTP 5XX ao balanceador de carga, o balanceador de carga retransmite essa resposta ao respetivo cliente. Para determinar se uma resposta HTTP 5XX foi retransmitida a partir de um back-end ou se foi gerada pelo proxy do balanceador de carga, consulte o campo statusDetails dos registos do balanceador de carga.

Se statusDetails devolver uma string de registo response_sent_by_backend, o balanceador de carga está apenas a retransmitir o código de resposta que o back-end lhe enviou. Nesse caso, tem de resolver os problemas das respostas de erro HTTP nos seus back-ends.

Para respostas de erro HTTP com statusDetails que não correspondem à string de registo response_sent_by_backend:

  • O balanceador de carga de aplicações externo global e o balanceador de carga de aplicações externo regional geram códigos de erro de resposta HTTP significativos, como 503 (Serviço indisponível) e 504 (Tempo limite do gateway).

  • O Application Load Balancer clássico usa sempre o código de erro de resposta HTTP 502.

As alterações de configuração ao balanceador de carga de aplicações externo global, como a adição ou a remoção de um serviço de back-end, podem resultar num breve período em que os utilizadores veem o código de erro de resposta HTTP 502. Embora estas alterações de configuração sejam propagadas para os GFEs a nível global, verá entradas de registo em que o campo statusDetails corresponde à string de registo failed_to_pick_backend.

Se os erros HTTP 5XX persistirem durante mais de alguns minutos após concluir a configuração do balanceador de carga, siga estes passos para resolver problemas de respostas HTTP 5XX:

  1. Verifique se existe uma regra de firewall configurada para permitir verificações de estado. Na ausência de um, os registos do balanceador de carga têm normalmente uma statusDetailscorrespondênciafailed_to_pick_backend, o que indica que o balanceador de carga não conseguiu selecionar um back-end saudável para processar o pedido.

  2. Verifique se o tráfego de verificação de estado atinge as VMs de back-end. Para tal, ative o registo da verificação de funcionamento e pesquise entradas de registo bem-sucedidas.

    Para novos equilibradores de carga, a ausência de entradas de registo de verificações de funcionamento bem-sucedidas não significa que o tráfego de verificações de funcionamento não está a chegar aos seus back-ends. Isto pode significar que o estado de funcionamento inicial do back-end ainda não foi alterado de UNHEALTHY para um estado diferente. Só vê entradas de registo de verificação do estado bem-sucedidas depois de o verificador do estado receber uma resposta HTTP 200 OK do back-end.

  3. Verifique se o software nos backends está em execução. Para o fazer, verifique se a resposta 5xx está a ser publicada pelo balanceador de carga ou se é gerada a partir dos back-ends. Siga estes passos:

    1. Use o Cloud Logging para ver os registos do balanceador de carga. Pode criar uma consulta para procurar apenas códigos de resposta 5xx.

    2. Verifique o valor do campo statusDetails:

      • Se statusDetails devolver uma mensagem de êxito, como response_sent_by_backend, significa que é o back-end que está a servir respostas HTTP 502. Verifique os registos no back-end e resolva problemas adicionais consoante o serviço em execução no back-end.
      • Se statusDetails devolver uma mensagem de falha, consulte a seguinte lista de soluções para algumas falhas comuns relacionadas com respostas 5xx:
      statusDetail failure message Potenciais causas e soluções
      failed_to_connect_to_backend

      O equilibrador de carga não conseguiu estabelecer uma ligação ao back-end. Isto pode significar que o serviço em execução no back-end não está a detetar na porta definida no serviço de back-end.

      Recomendações:

      • Defina a porta da verificação de funcionamento para usar a porta de publicação. Isto significa que o back-end é considerado não saudável antes de ser elegível para publicar tráfego real.
      • Use o seguinte comando para se certificar de que existe um serviço em execução na porta com nome do serviço de back-end: 
        $ netstat -tnl | grep PORT
      failed_to_pick_backend

      O equilibrador de carga não conseguiu escolher um back-end. Isto pode significar que todos os servidores de back-end estão em mau estado. Certifique-se de que configurou as regras de firewall corretas para as verificações de estado.

      backend_connection_closed_before_data_sent_to_client O back-end fechou inesperadamente a respetiva ligação ao equilibrador de carga antes de a resposta ser enviada por proxy para o cliente. Isto pode acontecer se o balanceador de carga estiver a enviar tráfego para outra entidade. A outra entidade pode ser um equilibrador de carga de terceiros que tenha um limite de tempo limite de TCP inferior ao limite de tempo limite do equilibrador de carga. Para mais detalhes, consulte a secção Tempos limite e novas tentativas.
      backend_timeout O back-end demorou demasiado tempo a responder. O limite de tempo do serviço de back-end pode estar definido como demasiado baixo para o serviço dado responder. Considere aumentar o limite de tempo do serviço de back-end ou investigar por que motivo o seu serviço está a demorar tanto tempo a responder.

  4. Verifique se o parâmetro de configuração de keepalive para o software do servidor HTTP em execução na instância de back-end não é inferior ao limite de tempo de keepalive 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 resposta HTTP 5XX quando a ligação ao back-end foi fechada inesperadamente durante o envio do pedido HTTP ou antes de a resposta HTTP completa ter sido recebida. Isto pode acontecer porque o parâmetro de configuração keepalive para o software do servidor Web em execução na instância de back-end é inferior ao limite de tempo keepalive fixo do equilibrador de carga. Certifique-se de que a configuração do limite de tempo de keepalive para o software do servidor HTTP em cada back-end está definida para um valor ligeiramente superior a 10 minutos (o valor recomendado é de 620 segundos).

Resolver erros HTTP 408

Com o tráfego HTTP, o tempo máximo para o cliente concluir o envio do pedido é igual ao tempo limite do serviço de back-end. Se vir respostas HTTP 408 com o código jsonPayload.statusDetail client_timed_out, significa que não houve progresso suficiente enquanto o pedido do cliente foi enviado por proxy ou a resposta do back-end foi enviada por proxy. Se o problema for devido a clientes com problemas de desempenho, pode resolvê-lo aumentando o limite de tempo do serviço de back-end.

O tráfego com balanceamento de carga não tem o endereço de origem do cliente original

O endereço IP de origem dos pacotes, conforme visto pelos back-ends, não é o endereço IP externo do balanceador de carga. Os balanceadores de carga baseados em proxy, como os balanceadores de carga de aplicações externos, usam duas ligações TCP para transmitir tráfego do cliente para os back-ends:

  • Ligação 1, do cliente original ao equilibrador de carga (GFE ou sub-rede apenas de proxy)
  • Ligação 2, do equilibrador de carga (GFE ou sub-rede apenas de proxy) à VM ou ao ponto final de back-end

Os endereços IP de origem e de destino de cada ligação diferem consoante o tipo de Application Load Balancer externo que está a usar. Para ver detalhes, consulte a secção Endereços IP de origem para pacotes de clientes .

Receber um erro de autorização ao tentar ver um objeto no meu contentor do Cloud Storage

Para publicar objetos através do balanceamento de carga, os objetos do Cloud Storage têm de estar acessíveis publicamente. Certifique-se de que atualiza as autorizações dos objetos que estão a ser publicados para que sejam publicamente legíveis.

O URL não disponibiliza o objeto do Cloud Storage esperado

O objeto do Cloud Storage a publicar é determinado com base no seu mapa de URLs e no URL que pede. Se o caminho do pedido for mapeado para um contentor de back-end no seu mapa de URLs, o objeto do Cloud Storage é determinado anexando o caminho do pedido completo ao contentor do Cloud Storage especificado pelo mapa de URLs.

Por exemplo, se mapear /static/* para gs://[EXAMPLE_BUCKET], o pedido para https://<GCLB IP or Host>/static/path/to/content.jpg vai tentar publicar gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Se esse objeto não existir, recebe a seguinte mensagem de erro em vez do objeto:


NoSuchKey
The specified key does not exist.

A compressão não está a funcionar

Um Application Load Balancer externo não comprime nem descomprime as respostas, mas pode publicar respostas geradas pelo seu serviço de back-end que são comprimidas através de ferramentas como gzip ou DEFLATE.

Se as respostas publicadas pelo equilibrador de carga não estiverem comprimidas, mas deveriam estar, certifique-se de que o software do servidor Web em execução nas suas instâncias está configurado para comprimir as respostas. Por predefinição, alguns softwares de servidor Web desativam automaticamente a compressão para pedidos que incluem um cabeçalho Via, o que indica que o pedido foi encaminhado por um proxy. Uma vez que é um proxy, o balanceador de carga de aplicações externo adiciona um cabeçalho Via a cada pedido, conforme exigido pela especificação HTTP. Para ativar a compressão, pode ter de substituir a configuração predefinida do servidor Web para lhe indicar que comprima as respostas, mesmo que o pedido tenha um cabeçalho Via.

Para configurar back-ends nginx para publicar respostas comprimidas através de um balanceador de carga de aplicações externo:

Para configurar back-ends do Apache para servir respostas comprimidas através de um balanceador de carga de aplicações externo:

Resolva problemas de back-ends em mau estado de funcionamento

Resolva problemas com o HTTP/2 para os back-ends

Certifique-se de que a instância de back-end está em bom estado e suporta o protocolo HTTP/2. Pode verificar isto testando a conetividade à instância de back-end através de HTTP/2. Certifique-se de que a VM usa conjuntos de cifras compatíveis com a especificação HTTP/2. Por exemplo, determinados conjuntos de cifras TLS 1.2 não são permitidos pelo HTTP/2. Consulte a lista negra de conjuntos de cifras TLS 1.2.

Depois de verificar se a VM usa o protocolo HTTP/2, certifique-se de que a configuração da firewall permite a passagem do verificador de funcionamento e do balanceador de carga.

Se não existirem problemas com a configuração da firewall, certifique-se de que o balanceador de carga está configurado para comunicar com a porta correta na VM.

Resolva problemas de NEG da Internet e de back-end externo

Antes de investigar problemas, familiarize-se com as seguintes páginas:

O tráfego não chega aos pontos finais

Depois de configurar um serviço, o novo ponto final fica acessível através do equilibrador de carga da aplicação externo quando:

  • O ponto final está associado ao NEG da Internet.
  • O FQDN associado pode ser resolvido com êxito pelo DNS (se estiver a usar o tipo de ponto final FQDN).
  • O ponto final está acessível através da Internet.

Se o tráfego não conseguir alcançar o ponto final, o que resulta num código de erro 502, consulte o registo TXT de DNS _cloud-eoips.googleusercontent.com através de uma ferramenta como dig ou nslookup. Tome nota dos CIDRs (a seguir a ip4:) e certifique-se de que estes intervalos são permitidos pela sua firewall ou lista de controlo de acesso (ACL) na nuvem.

Após configurar um back-end externo, os pedidos ao back-end externo falharam com um erro 5xx

  • Selecione Registo.
  • Verifique se o grupo de pontos finais de rede está configurado com o IP:Port ou o FQDN:Port correto para o seu back-end externo.
  • Se estiver a usar o FQDN, certifique-se de que é resolvível através do DNS público da Google. Pode verificar se o FQDN é resolvível através do DNS público da Google seguindo estes passos ou diretamente na interface Web.
  • Se estiver a aceder ao balanceador de carga no respetivo IP externo apenas, e o servidor Web de origem estiver à espera de um nome de anfitrião, certifique-se de que está a enviar um cabeçalho de anfitrião HTTP válido para o seu back-end configurando um cabeçalho de pedido personalizado.
  • Se estiver a comunicar com um back-end através de HTTPS ou HTTP2 (conforme definido no campo protocol do serviço de back-end) configurado como um ponto final de back-end INTERNET_FQDN_PORT externo, certifique-se de que a sua origem está a apresentar um certificado TLS (SSL) válido e que o FQDN configurado corresponde a um SAN (nome alternativo do assunto) na lista de SANs dos certificados. Um certificado válido é definido como um certificado assinado por uma autoridade de certificação pública e que não expirou.
  • Quando usar pontos finais de back-end externos INTERNET_FQDN_PORT, os certificados autossinados não são aceites pelo equilibrador de carga e são rejeitados.
  • Quando usar HTTPS ou HTTP/2 com pontos finais do tipo INTERNET_IP_PORT, não é feita nenhuma validação/verificação SAN do certificado SSL. Isto significa que é possível usar certificados autossinados. Quando usar SSL, recomendamos que use os pontos finais INTERNET_FQDN_PORT para garantir que os certificados do servidor e os SANs podem ser validados.

As respostas do meu back-end externo não são colocadas em cache pela RFC do Google Cloud

Certifique-se de que:

  • Ativou a RFC no serviço de back-end que contém o NEG que aponta para o seu back-end externo definindo enableCDN como verdadeiro.
  • As respostas fornecidas pelo seu back-end externo cumprem os requisitos de colocação em cache do Cloud CDN. Por exemplo, está a enviar cabeçalhos de resposta Cache-Control: public, max-age=3600 da origem.

Resolva problemas do NEG sem servidor

Antes de investigar problemas, familiarize-se com as seguintes páginas:

As solicitações falham com um erro 404

Certifique-se de que o recurso sem servidor subjacente (como um App Engine, funções do Cloud Run ou serviço do Cloud Run) ainda está em execução. Se o recurso sem servidor for eliminado, mas o NEG sem servidor ainda existir, o Application Load Balancer externo continua a tentar encaminhar pedidos para o serviço inexistente. Isto resulta numa resposta 404.

Em geral, um Application Load Balancer externo não consegue detetar se o recurso sem servidor subjacente está a funcionar conforme esperado. Isto significa que, se o seu serviço numa região estiver a devolver erros, mas a infraestrutura geral do Cloud Run, das funções do Cloud Run ou do App Engine nessa região estiver a funcionar normalmente, o seu Application Load Balancer externo não direciona automaticamente o tráfego para outras regiões. Certifique-se de que testa exaustivamente as novas versões dos seus serviços antes de encaminhar o tráfego de utilizadores para as mesmas.

Como lidar com não correspondências de máscaras de URLs

Se a aplicação da máscara de URL configurada a um URL de pedido do utilizador não resultar num nome de serviço ou resultar num nome de serviço que não existe, o equilibrador de carga pode processar estas incompatibilidades de forma diferente, consoante a plataforma de computação sem servidor em utilização.

Cloud Run: em caso de incompatibilidade da máscara de URL, o balanceador de carga devolve um erro HTTP 404 (Não encontrado).

Funções do Cloud Run: em caso de incompatibilidade da máscara de URL, o balanceador de carga devolve um erro HTTP 404 (Não encontrado).

App Engine: em caso de incompatibilidade da máscara de URL, o App Engine usa dispatch.yaml e a lógica de encaminhamento predefinida do App Engine para determinar a que serviço enviar o pedido.