Resolver problemas com balanceadores de carga de aplicativo externos

Neste guia, descrevemos como solucionar problemas de configuração de balanceadores de carga de aplicativos externos. Antes de investigar os problemas, conheça as páginas a seguir.:

• Visão geral do balanceador de carga de aplicativo externo
• Geração de registros e monitoramento do balanceador de carga de aplicativo externo

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:

• Restrições e orientações para grupos de instâncias
• Alterar o modo de balanceamento de um balanceador de carga

Resolver problemas gerais de conectividade

Erros 5XX inexplicáveis

Para condições de erro causadas por um problema de comunicação entre o proxy do balanceador de carga e os back-ends, o balanceador de carga gera um código de resposta de erro HTTP (5XX) e retorna esse código de resposta de erro para o 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 statusDetails dos registros do balanceador de carga.

Se statusDetails retornar uma string de registro response_sent_by_backend, o balanceador de carga está simplesmente redirecionando qualquer código de resposta que o back-end enviou a ele. Nesse caso, você precisará resolver problemas de respostas de erro HTTP nos seus back-ends.

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

• O balanceador de carga de aplicativo externo e global gera códigos de erro de resposta HTTP significativos, como 503 (serviço indisponível) e 504 (tempo limite do gateway).

• O balanceador de carga clássico do aplicativo sempre usa o código de erro de resposta HTTP 502.

Alterações na configuração do balanceador de carga de aplicativo externo global, 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 recebem o código de erro de resposta HTTP 502. Embora essas mudanças de configuração sejam propagadas para os GFEs no mundo inteiro, você verá entradas de registro em que o campo statusDetails corresponde à string de registro failed_to_pick_backend.

Se os erros HTTP 5XX persistirem após alguns minutos após a configuração do balanceador de carga, siga estas etapas para resolver problemas em 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 geralmente têm um statusDetails correspondente a failed_to_pick_backend, o que indica que o balanceador de carga não escolhe um back-end íntegro para processar a solicitação.

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 software nos back-ends está em execução. Para fazer isso, verifique se a resposta 5xx está sendo veiculada pelo balanceador de carga ou se ela é gerada a partir 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 5xx.

   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 5xx:

      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.

4. 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 resposta 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).

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.

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

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

• Conexão 1, do cliente original para o balanceador de carga (GFE ou sub-rede somente proxy)
• Conexão 2, do balanceador de carga (GFE ou sub-rede somente proxy) para a VM ou o endpoint de back-end

Os endereços IP de origem e destino para cada conexão são diferentes com base no tipo de balanceador de carga de aplicativo externo que você está usando. Para detalhes, consulte Endereços IP de origem para pacotes de cliente .

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 balanceador de carga de aplicativo externo 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 veiculadas pelo balanceador de carga 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 é um proxy, o balanceador de carga de aplicativo externo 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 seu servidor da Web para que ele compacte as respostas mesmo se a solicitação tiver 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 de aplicativo externo:

• defina a diretiva gzip_proxied (em inglês) de forma adequada (por exemplo, a any);
• defina a diretiva gzip_vary como on.

Para configurar back-ends do Apache para veicular respostas compactadas encaminhadas por meio de um balanceador de carga de aplicativo externo:

• use o filtro DEFLATE (em inglês);
• adicione Vary Accept-Encoding ao cabeçalho da resposta usando o módulo mod_headers

Solução de problemas de back-ends não íntegros

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

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.

Solucionar problemas de back-end externo e NEG da Internet

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

• Informações gerais sobre NEGs de Internet
• Configurar um balanceador de carga de aplicativo externo global com um back-end externo (NEG de Internet)

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

Depois de configurar um serviço, o novo endpoint se torna acessível por meio do balanceador de carga externo do aplicativo 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, consulte o registro TXT do DNS _cloud-eoips.googleusercontent.com usando ferramentas 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).

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

Resolver problemas de NEG sem servidor

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

• Visão geral dos NEGs sem servidor
• Configurar um balanceador de carga de aplicativo externo global com NEGs sem servidor

As solicitações falham com um erro 404

Verifique se o recurso subjacente sem servidor, como um serviço do App Engine, as funções do Cloud Run 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 de aplicativo 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 de aplicativo externo não consegue detectar se o recurso subjacente sem servidor está funcionando conforme o esperado. Isso significa que, se o serviço em uma região estiver retornando erros, mas a infraestrutura geral do Cloud Run, as funções do Cloud Run ou App Engine nessa região estiver funcionando normalmente, o balanceador de carga de aplicativo 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).

Funções do Cloud Run: 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.