Como solucionar problemas de balanceamento de carga HTTP(S)

Neste guia, você verá como resolver problemas de configuração de um balanceador de carga de HTTP(S) externo do Google Cloud.

Visão geral

Tipos de problemas discutidos neste guia:

  • Problemas de configuração quando os back-ends têm modos de balanceamento incompatíveis
  • Problemas gerais de conectividade
  • Problemas com conexões HTTP/2 com back-ends
  • Problemas com back-end externo e NEG na Internet
  • Problemas de NEG sem servidor

Antes de começar

Antes de investigar os problemas, conheça as páginas a seguir.

Para conectividade geral:

Para geração de registros e monitoramento:

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

Erros 502 desconhecidos

Se os erros 502 persistirem por mais de alguns minutos depois de você concluir a configuração do balanceador de carga, é provável que:

Siga estas etapas para resolver problemas nas respostas 502:

  1. 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.
  2. Verifique se a resposta 502 está sendo exibida pelo balanceador de carga ou se é proveniente dos back-ends. Siga as etapas abaixo:

    1. Use o Cloud Logging para ver os registros do balanceador de carga. É possível criar uma consulta para procurar apenas códigos de resposta 502.
    2. Verifique o valor do campo statusDetails.

      • Se statusDetails retornar uma mensagem de sucesso, como response_sent_by_backend, significa que o back-end está exibindo respostas HTTP 502 Verifique os registros no back-end e resolva os problemas mais detalhadamente, dependendo do serviço em execução no back-end.
      • Se statusDetails retornar uma mensagem de falha, consulte a seguinte lista de soluções para algumas falhas comuns relacionadas às respostas 502:
      Mensagem de falha do statusDetail Causas e soluções em potencial
      failed_to_connect_to_backend

      O balanceador de carga falhou ao estabelecer uma conexão com o back-end. Isso significa que o serviço em execução no back-end não está escutando na porta definida no serviço de back-end.

      Recomendações:

      • Defina a porta da verificação de integridade para usar a porta de exibição. Isso significa que o back-end não será íntegro antes de estar qualificado para veicular o tráfego real.
      • Use o comando a seguir para garantir que haja algum serviço em execução na porta nomeada do serviço de back-end.
        
        $ netstat -tnl | grep PORT
      failed_to_pick_backend

      O balanceador de carga não pôde escolher um back-end. Isso pode significar que nenhum back-end está íntegro. Verifique se você configurou as regras de firewall corretas para as verificações de integridade.

      backend_connection_closed_before_data_sent_to_client O back-end fechou inesperadamente sua conexão com o balanceador de carga antes de a resposta ser encaminhada por proxy para o cliente. Isso poderá acontecer se o balanceador de carga estiver enviando tráfego para outra entidade. A outra entidade pode ser um balanceador de carga de terceiros que tem um tempo limite de TCP menor que o tempo limite do balanceador de carga. Para mais detalhes, consulte Tempos limite e tentativas.
      backend_timeout O back-end demorou muito para responder. O tempo limite do serviço de back-end pode ser definido como muito baixo para que o serviço fornecido responda. Considere aumentar o tempo limite do serviço de back-end ou observe por que seu serviço está demorando tanto para responder.

Tráfego com carga balanceada não tem endereço de origem do cliente original

O tráfego do balanceador de carga para suas instâncias tem um endereço IP nos intervalos de 130.211.0.0/22 e 35.191.0.0/16. Ao visualizar registros em suas instâncias de cargas balanceadas, não é possível ver o endereço de origem do cliente original. Em vez disso, você verá os endereços de origem desse intervalo.

Erro de permissão ao tentar visualizar um objeto em meu bucket do Cloud Storage

Para veicular objetos pelo balanceamento de carga, os objetos do Cloud Storage precisam ser publicamente acessíveis. Não se esqueça de atualizar as permissões dos objetos veiculados para que a leitura pública seja possível.

URL não exibe o objeto do Cloud Storage esperado

O objeto do Cloud Storage a ser veiculado é determinado com base no mapa de URL e no URL solicitado. Quando o caminho da solicitação aponta para um bucket de back-ends no mapa de URL, esse objeto é definido pelo acréscimo do caminho completo da solicitação ao bucket do Cloud Storage especificado no mapa.

Por exemplo, se você mapear /static/* para gs://[EXAMPLE_BUCKET], a solicitação para https://<GCLB IP or Host>/static/path/to/content.jpg tentará veicular gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Se esse objeto não existir, em vez dele, você receberá a seguinte mensagem de erro:


NoSuchKey
The specified key does not exist.

A compressão não funciona

O balanceamento de carga HTTP(S) não compacta nem descompacta as respostas, mas pode veicular as respostas geradas pelo serviço de back-end que foram compactadas usando ferramentas como gzip ou DEFLATE.

Se as respostas fornecidas pelo balanceamento de carga HTTP(S) não estiverem compactadas, mas deveriam estar, verifique se o software servidor da Web em execução nas instâncias está configurado para compactar as respostas. Por padrão, alguns softwares servidores da Web desativam automaticamente a compactação de solicitações que incluem um cabeçalho Via, que indica que a solicitação foi encaminhada por um proxy. Como se trata de um proxy, o balanceamento de carga HTTP(S) adiciona um cabeçalho Via a cada solicitação conforme exigido pela especificação HTTP. Para ativar a compactação, talvez seja necessário substituir a configuração padrão do servidor da Web para que ela compacte as respostas mesmo que a solicitação tenha um cabeçalho Via.

Para configurar back-ends do nginx (em inglês) para veicular respostas compactadas encaminhadas por meio de um balanceador de carga HTTP(S) externo:

Para configurar os back-ends do Apache (em inglês) e exibir respostas compactadas encaminhadas por meio de um balanceador de carga HTTP(S) externo:

Como resolver erros HTTP 408

Com o tráfego HTTP, o tempo máximo para o cliente concluir o envio da solicitação é igual ao tempo limite do serviço de back-end. Se você vir respostas HTTP 408 com o jsonPayload.statusDetail client_timed_out, significa que não houve progresso suficiente enquanto a solicitação do cliente foi colocada em proxy ou a resposta do back-end foi colocada em proxy. Se o problema for causado por clientes com problemas de desempenho, a solução é aumentar o tempo limite do serviço de back-end.

Solução de problemas com o HTTP/2 para back-ends

Valor inválido para o campo resource.loadBalancingScheme: "EXTERNAL"

Isso pode acontecer se você criar um serviço de back-end sem selecionar a opção global. Ao emitir um comando gcloud da maneira a seguir, é solicitado que você designe uma região ou determine o balanceador de carga como global:

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test1 \
    --protocol=http2

Para este serviço de back-end:

- [service-test] choose a region or global:
[1] global
[2] region: [REGION_A_NAME]
[3] region: [REGION_B_NAME]
....
Please enter your numeric choice:

Para o balanceador de carga HTTP(S), os serviços de back-end precisam ser globais. Portanto, é necessário escolher a opção 1 ou emitir o comando gcloud com a opção --global:

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test \
    --protocol=http2 \
    --global

Erros 502 desconhecidos

Verifique se a instância de back-end está íntegra e aceita o protocolo HTTP/2. Para isso, teste a conectividade com a instância de back-end usando HTTP/2. Confira se a VM usa pacotes de criptografia compatíveis com a especificação HTTP/2. Por exemplo, determinados pacotes de criptografia do TLS 1.2 não são permitidos pelo HTTP/2. Consulte a Lista negra de pacotes de criptografia do TLS 1.2 (em inglês).

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

Se não houver problemas com a configuração do firewall, verifique se o balanceador de carga está configurado para se comunicar com a porta correta na VM.

Como solucionar problemas de back-end externo e NEG da Internet

Antes de investigar os problemas, conheça as páginas a seguir.:

O tráfego não alcança os endpoints

Depois de configurar um serviço, o novo endpoint se tornará acessível por meio do balanceador de carga HTTP(S) externo quando:

  • o endpoint estiver anexado à Internet NEG;
  • for possível resolver o FQDN associado no DNS (se você estiver usando o tipo de endpoint FQDN);
  • o endpoint for acessível pela Internet.

Se o tráfego não alcançar o endpoint, o que resulta em um código de erro 502 para HTTP(s), verifique o seguinte:

  • Consulte o registro TXT do DNS _cloud-eoips.googleusercontent.com usando uma ferramenta como dig ou nslookup. Observe os CIDRs (após ip4:) e verifique se esses intervalos são permitidos pelo firewall ou pela lista de controle de acesso (ACL, na sigla em inglês) da nuvem.

Depois de configurar um back-end externo, as solicitações para back-end externo falharam com um erro 5xx

  • Verifique a Geração de registros.
  • Verifique se o grupo de endpoints da rede está configurado com o IP:Porta ou FQDN:Porta corretos para o backend externo
  • Se estiver usando o FQDN, certifique-se de que ele pode ser resolvido por meio do DNS público do Google. É possível verificar se o FQDN pode ser resolvido por meio do DNS público do Google usando estas etapas ou a interface da Web diretamente.
  • Se estiver acessando o balanceador de carga HTTP(S) somente no IP externo e seu servidor da Web de origem estiver esperando um nome de host, verifique se você está enviando um cabeçalho HTTP Host válido para seu back-end configurando um cabeçalho de solicitação personalizado.
  • Se estiver se comunicando com um back-end por HTTPS ou HTTP2 (conforme definido no campo protocol do serviço de back-end) configurado como um endpoint de back-end externo INTERNET_FQDN_PORT, certifique-se de que a origem apresenta um certificado TLS (SSL) e que o FQDN configurado corresponde a um SAN (nome alternativo do assunto) da lista de SANs dos certificados. Um certificado válido é aquele que foi assinado por uma autoridade de certificação pública e que não expirou.
  • Ao usar endpoints de back-end externos INTERNET_FQDN_PORT, os certificados autoassinados não são aceitos pelo balanceador de carga HTTPS e são rejeitados.
  • Ao usar HTTPS ou HTTP/2 com endpoints do tipo INTERNET_IP_PORT, nenhuma validação de certificado SSL ou verificação de SAN é realizada. Isso significa que é possível usar certificados autoassinados. Ao usar SSL, recomendamos usar endpoints INTERNET_FQDN_PORT para garantir que os certificados de servidor e os SANs sejam validados.

As respostas do meu back-end externo não são armazenadas em cache pelo Cloud CDN

Verifique se:

  • você ativou o Cloud CDN no serviço de back-end que contém o NEG que aponta para seu back-end externo configurando enableCDN como verdadeiro.
  • As respostas exibidas pelo back-end externo atendem aos requisitos de armazenamento em cache do Cloud CDN. Por exemplo, você está enviando cabeçalhos de resposta Cache-Control: public, max-age=3600 a partir da origem.

Solução de problemas de NEG sem servidor

Antes de investigar os problemas, conheça as páginas a seguir.:

As solicitações falham com um erro 404

Verifique se o recurso subjacente sem servidor, como um serviço do App Engine, Cloud Functions ou Cloud Run, ainda está em execução. Se o recurso sem servidor for excluído, mas o NEG sem servidor ainda existir, o balanceador de carga HTTP(S) externo continuará tentando encaminhar solicitações para o serviço que não existe mais. Isso resulta em uma resposta 404.

Em geral, um balanceador de carga HTTP(S) externo não consegue detectar se o recurso sem servidor subjacente está funcionando conforme esperado. Isso significa que, se o serviço em uma região estiver retornando erros, mas a infraestrutura geral do Cloud Run, Cloud Functions ou App Engine nessa região estiver funcionando normalmente, o balanceador de carga HTTP(S) externo não direcionará o tráfego automaticamente para outras regiões. Faça testes detalhados das novas versões dos serviços antes de encaminhar o tráfego de usuários para eles.

Como lidar com incompatibilidades de máscara de URL

Se a aplicação da máscara de URL configurada a um URL de solicitação do usuário não resultar em um nome de serviço ou se resultar em um nome de serviço que não existe, o balanceador de carga poderá lidar com essas incompatibilidades de maneira diferente, dependendo da plataforma de computação sem servidor em uso.

Cloud Run: no caso de uma máscara de URL incompatível, o balanceador de carga retorna um erro HTTP 404 (não encontrado).

Cloud Functions: no caso de uma máscara de URL incompatível, o balanceador de carga retorna um erro HTTP 404 (não encontrado).

App Engine: no caso de uma máscara de URL incompatível, o App Engine usa dispatch.yaml e a lógica de roteamento padrão do App Engine para determinar para qual serviço enviar a solicitação.