Como configurar o balanceamento de carga HTTP(S)

O balanceamento de carga HTTP(S) do Google Cloud Platform (GCP) fornece balanceamento global de carga para solicitações HTTP(S) destinadas a suas instâncias. É possível configurar regras de URL que direcionem alguns URLs para um conjunto de instâncias e direcionem outros URLs para outras instâncias. As solicitações são sempre direcionadas para o grupo de instâncias que está mais próximo do usuário, desde que o grupo tenha capacidade suficiente e seja adequado para a solicitação. Se o grupo mais próximo não tem capacidade suficiente, a solicitação é enviada ao grupo mais próximo que tenha capacidade.

O balanceamento de carga HTTP(S) é compatível com endereços IPv4 e IPv6 para o tráfego do cliente. As solicitações IPv6 do cliente são encerradas na camada global de balanceamento de carga e, em seguida, encaminhadas por proxy sobre IPv4 para seus back-ends.

O balanceamento de carga das solicitações HTTP pode ser feito com base na porta 80 ou na porta 8080. O balanceamento de carga das solicitações HTTPS pode ser feito na porta 443.

O balanceador de carga atua como uma camada de conversão de HTTP/2 para HTTP/1.1. Isso significa que os servidores da Web sempre consultam e respondem às solicitações HTTP/1.1, mas as solicitações do navegador podem ser HTTP/1.0, HTTP/1.1 ou HTTP/2. O push do servidor HTTP/2 não é compatível.

Antes de começar

O balanceamento de carga HTTP(S) usa grupos de instâncias para organizar as instâncias. Familiarize-se com os grupos de instâncias antes de usar o balanceamento de carga.

Exemplos de configurações

Se você preferir ir em frente e criar um balanceador de carga funcional para teste, há nos seguintes guias dois cenários diferentes com o serviço de balanceamento de carga HTTP(S). Nesses cenários, há um contexto prático para balanceamento de carga HTTP(S) e demonstrações de como é possível configurar o balanceamento de carga para suas necessidades específicas.

No restante dessa página, há mais detalhes sobre como os balanceadores de carga são construídos e como funcionam.

Criar um balanceador de carga entre regiões

Representação de balanceamento de carga entre regiões

É possível usar um endereço IP global que possa direcionar de modo inteligente os usuários com base na proximidade. Por exemplo, se você configurar instâncias na América do Norte, na Europa e na Ásia, usuários em todo o mundo serão automaticamente enviados aos back-ends mais próximos, supondo que aquelas instâncias tenham capacidade suficiente. Se as instâncias mais próximas não têm capacidade suficiente, o balanceamento de carga entre regiões encaminha automaticamente os usuários para a região mais próxima seguinte.

Primeiros passos com o balanceamento de carga entre regiões


Criar um balanceador de carga baseado em conteúdo

Representação de balanceamento de carga baseado em conteúdo

O balanceamento de carga baseado em conteúdo ou de acordo com o conteúdo usa o balanceamento de carga HTTP(S) para distribuir o tráfego a diferentes instâncias com base no URL HTTP(S) de entrada. Por exemplo, configure algumas instâncias para administrar seu conteúdo de vídeo e outras para o conteúdo restante. É possível configurar seu balanceador de carga para direcionar o tráfego para example.com/video para os servidores de vídeo e para example.com/ para os servidores padrão.

Primeiros passos com o balanceamento de carga baseado em conteúdo

Você também pode usar o balanceamento de carga de HTTP(S) com intervalos do Google Cloud Storage. Depois de configurar o balanceador de carga baseado em conteúdo, é possível adicionar um intervalo do Cloud Storage a ele.


O balanceamento de carga baseado em conteúdo e o balanceamento de carga entre regiões podem funcionar juntos usando serviços de vários back-end e várias regiões. É possível criar usando os cenários acima para definir uma configuração de balanceamento de carga própria que satisfaça suas necessidades.

Princípios básicos

Visão geral

Um balanceador de carga HTTP(S) tem diversos componentes. O diagrama a seguir representa a arquitetura de um balanceador de carga HTTP(S) completo:

Diagrama de balanceamento de carga entre regiões (clique para ampliar)

Nas seções a seguir, há informações sobre como cada componente funciona em conjunto para criar cada tipo de balanceador de carga. Para uma descrição detalhada de cada componente, consulte Componentes a seguir.

Balanceamento de carga HTTP

Um balanceador de carga HTTP completo é estruturado da seguinte maneira:

  1. Uma regra de encaminhamento global direciona as solicitações de entrada para um proxy HTTP de destino.
  2. O proxy HTTP de destino verifica cada solicitação em um mapa de URLs para determinar o serviço de back-end apropriado para a solicitação.
  3. O serviço de back-end direciona cada solicitação a um back-end apropriado com base na capacidade de serviço, zona e integridade da instância de seus back-ends anexados. A integridade de cada instância de back-end é verificada com uma verificação de integridade HTTP ou uma verificação de integridade HTTPS. Se o serviço de back-end está configurado para usar a última, a solicitação é criptografada ao ser direcionada à instância de back-end.

Balanceamento de carga HTTPS

Um balanceador de carga HTTPS tem a mesma estrutura básica de um balanceador de carga HTTP (descrito acima), mas difere dos seguintes modos:

  • Usa um proxy HTTPS de destino em vez de um proxy HTTP de destino.
  • Requer pelo menos um certificado SSL assinado instalado no proxy HTTPS de destino para o balanceador de carga.
  • A sessão do cliente SSL termina no balanceador de carga. Sessões entre o balanceador de carga e a instância podem ser HTTPS (recomendado) ou HTTP. Se você usar HTTPS, é necessário que cada instância nos serviços de back-end tenha um certificado SSL.

Componentes

Regras e endereços globais de encaminhamento

As regras de encaminhamento globais direcionam o tráfego por endereço IP, porta e protocolo para uma configuração de balanceamento de carga que consiste em um proxy de destino, mapa de URL e um ou mais serviços de back-end.

Cada regra de encaminhamento global fornece um endereço IP global único que pode ser usado nos registros de DNS de seu aplicativo. Não é necessário nenhum balanceamento de carga baseado no DNS. Especifique o endereço IP a ser usado ou deixe que o Google Compute Engine atribua um para você.

Proxies de destino

Os proxies de destino terminam conexões HTTP(S) de clientes, são referenciados por uma ou mais regras de encaminhamento globais e direcionam as solicitações de entrada para um mapa de URL.

Os proxies definem cabeçalhos de solicitação/resposta HTTP da seguinte maneira:

  • Via: 1.1 google (solicitações e respostas)
  • X-Forwarded-Proto: [http | https] (somente solicitações)
  • X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP> (somente solicitações)
    Uma lista separada por vírgulas de endereços IP anexada pelos intermediários pelos quais a solicitação passou. Se você está executando proxies no GCP que associam dados ao cabeçalho X-Forwarded-For, seu software precisa levar em consideração a existência e o número desses proxies. Somente as entradas <immediate client IP> e <global forwarding rule external IP> são fornecidas pelo balanceador de carga. Todas as outras entradas na lista são transmitidas sem verificação. A entrada <immediate client IP> é o cliente que se conectou diretamente ao balanceador de carga. A entrada <global forwarding rule external IP> é o endereço IP externo da regra de encaminhamento do balanceador de carga. Se houver mais entradas do que isso, a primeira entrada na lista é o endereço do cliente original. Outras entrada antes de <immediate client IP> representam outros proxies que encaminharam a solicitação para o balanceador de carga.
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (somente solicitações)
    Parâmetros para o Stackdriver Trace.

Mapas de URL

Os mapas de URL definem os padrões de correspondência do direcionamento de solicitações baseado em URL para os serviços de back-end apropriados. Um serviço padrão é definido para lidar com qualquer solicitação que não corresponda a uma regra de host ou regra de correspondência de caminho especificada. Em algumas situações, como o exemplo de balanceamento de carga entre regiões, é possível não definir nenhuma regra de URL e depender apenas do serviço padrão. Para direcionamento de tráfego baseado em conteúdo, o mapa de URL permite dividir o tráfego examinando os componentes do URL para enviar solicitações a diferentes conjuntos de back-ends.

Certificados SSL

Se você estiver usando balanceamento de carga HTTPS, é necessário instalar um ou mais certificados SSL no proxy HTTPS de destino. Até dez (10) certificados SSL podem ser instalados. Eles são usados por proxies HTTPS de destino para autenticar comunicações entre o balanceador de carga e o cliente.

Para mais informações sobre como instalar certificados SSL, consulte Certificados SSL.

Se você está usando HTTPS do balanceador de carga para os back-ends, é necessário instalar certificados SSL em cada instância de VM. Para instalar certificados SSL em uma instância de VM, use as instruções contidas na documentação do aplicativo.

Políticas de SSL

As políticas de SSL oferecem a capacidade de controlar os recursos de SSL que seu balanceador de carga HTTPS negocia com os clientes HTTPS.

Por padrão, o balanceamento de carga HTTPS usa um conjunto de recursos SSL que oferece boa segurança e ampla compatibilidade. Alguns aplicativos exigem mais controle sobre quais versões SSL e criptografias são usadas para as conexões HTTPS ou SSL deles. Você pode definir políticas SSL que controlam os recursos de SSL que seu balanceador de carga negocia e associar uma política de SSL ao seu proxy HTTPS de destino.

Serviços de back-end

Os serviços de back-end direcionam o tráfego de entrada a um ou mais back-ends anexados. Cada back-end é composto por um grupo de instâncias e metadados com capacidade adicional de serviço. A capacidade de serviço do back-end pode ser baseada em CPU ou em solicitações por segundo (RPS).

Cada serviço de back-end também especifica quais verificações de integridade serão feitas nas instâncias disponíveis.

O balanceamento de carga HTTP(S) é compatível com o Compute Engine Autoscaler, que permite aos usuários fazer escalonamentos automáticos nos grupos de instâncias em um serviço de back-end. Para mais informações, consulte Escalonamento com base na capacidade de serviço de balanceamento de carga HTTP.

É possível ativar a diminuição da conexão em serviços de back-end para garantir interrupção mínima para seus usuários quando uma instância que está servindo ao tráfego é terminada, removida manualmente ou removida por um autoescalador. Para saber mais sobre diminuição de conexão, leia a documentação Como ativar diminuição de conexão.

Intervalos de back-end

Os intervalos de back-end direcionam o tráfego recebido para os intervalos do Google Cloud Storage. Para um exemplo de como adicionar intervalos a uma configuração de balanceador de carga existente, consulte Como adicionar um intervalo do Cloud Storage a um balanceamento de carga baseado em conteúdo.

Regras de firewall

É necessário criar uma regra de firewall para permitir que o tráfego proveniente de 130.211.0.0/22 e 35.191.0.0/16 chegue às instâncias. Esses são os intervalos de endereços IP que o balanceador de carga usa para se conectar a instâncias de back-end. Essa regra permite tráfego do balanceador de carga e do verificador de integridade. A regra precisa permitir o tráfego na porta em que a regra de encaminhamento global foi configurada, e é necessário que seu verificador de integridade seja configurado para usar a mesma porta. Se o verificador de integridade usar uma porta diferente, é necessário criar outra regra de firewall para essa porta.

Observe que as regras de firewall bloqueiam e permitem o tráfego em nível de instância, não nos limites da rede. Não é possível usá-las para impedir o tráfego de chegar ao próprio balanceador de carga.

Se for necessário determinar endereços IP externos em determinado momento, use as instruções nas Perguntas frequentes do Google Compute Engine.

Algoritmo de distribuição de carga

O balanceamento de carga HTTP(S) fornece dois métodos para determinar a carga da instância. Dentro do objeto de serviço de back-end, a propriedade balancingMode escolhe o modo de solicitações por segundo (RPS, na sigla em inglês) ou de utilização de CPU. Ambos permitem especificar um valor máximo. O balanceador de carga HTTP tentará garantir que a carga permaneça abaixo do limite, mas podem ocorrer picos curtos acima do limite durante eventos de failover ou de picos de carga.

As solicitações recebidas são enviadas à região mais próxima do usuário, desde que essa região tenha capacidade disponível. Se mais de uma zona for configurada com back-ends em uma região, o tráfego será distribuído entre os grupos de instâncias em cada zona, de acordo com a capacidade de cada grupo. Dentro da zona, as solicitações são distribuídas de modo uniforme entre as instâncias por meio de um algoritmo round-robin. A distribuição round-robin pode ser substituída pela configuração de afinidade da sessão.

Afinidade da sessão

A afinidade da sessão envia todas as solicitações do mesmo cliente para a mesma instância de máquina virtual desde que a instância permaneça íntegra e tenha capacidade.

O balanceamento de carga HTTP(S) do GCP tem dois tipos de afinidade da sessão:

Suporte ao proxy WebSocket

O balanceador de carga HTTP(S) tem suporte nativo para o protocolo WebSocket. Os back-ends que usam o WebSocket para se comunicarem com clientes podem usar o balanceador de carga HTTP(S) como um front-end, com a finalidade de escalonamento e disponibilidade. O balanceador de carga não precisa de nenhuma configuração adicional para conexões WebSocket do proxy.

O protocolo WebSocket, definido em RFC6455, oferece um canal de comunicação full-duplex entre clientes e servidores. O canal é iniciado a partir de uma solicitação HTTP(S).

Ao reconhecer uma solicitação de upgrade do WebSocket proveniente de um cliente HTTP(S) e a quando a solicitação é acompanhada de uma resposta de upgrade bem-sucedida proveniente da instância de back-end, o balanceador de carga HTTP(S) encaminha por meio de proxy o tráfego durante o período de conexão atual. Se o back-end não retornar uma resposta de upgrade bem-sucedida, o balanceador de carga fechará a conexão.

O tempo limite para uma conexão WebSocket depende do tempo limite de resposta configurável do balanceador de carga, que é de 30 segundos por padrão. Esse tempo limite é aplicado às conexões WebSocket, independentemente de estarem em uso ou não. Para mais informações sobre o tempo limite da resposta e sobre como configurá-lo, consulte Tempos limite e tentativas.

Se você configurou o IP do cliente ou gerou uma afinidade de sessão por cookie para seu balanceador de carga HTTP(S), todas as conexões WebSocket de um cliente serão enviadas para a mesma instância de back-end, contanto que a instância continue a transmitir verificações de integridade e tenha capacidade.

Interfaces

Seu serviço de balanceamento de carga HTTP(S) pode ser configurado e atualizado por meio das seguintes interfaces:

  • Ferramenta de linha de comando gcloud: uma ferramenta incluída no Cloud SDK. A documentação de balanceamento de carga HTTP(S) chama essa ferramenta frequentemente para realizar tarefas. Para uma visão geral completa da ferramenta, consulte o Guia da ferramenta gcloud. Os comandos relativos ao balanceamento de carga podem ser encontrados no grupo de comandos gcloud compute.

    Também é possível acessar a ajuda detalhada para os comandos do gcloud usando a sinalização --help:

    gcloud compute http-health-checks create --help
    
  • Console do Google Cloud Platform: as tarefas de balanceamento de carga podem ser feitas por meio do Console do Google Cloud Platform.

  • REST API: todas as tarefas de balanceamento de carga podem ser realizadas por meio da Google Compute Engine API. Na documentação de referência da API é apresentada a descrição dos recursos e métodos disponíveis.

Compatibilidade com TLS

Por padrão, um proxy de destino HTTPS aceita somente TLS 1.0, 1.1 e 1.2 ao finalizar solicitações de SSL do cliente. Você pode usar políticas de SSL para alterar esse comportamento padrão e controlar como o balanceador de carga negocia SSL com os clientes.

Quando o balanceador de carga usa HTTPS como um protocolo de serviço de back-end, ele pode negociar TLS 1.0, 1.1 ou 1.2 para o back-end.

Tempo limite e tentativas

O balanceamento de carga HTTP(S) tem dois tipos distintos de tempo limite:

  • Um tempo limite de resposta configurável, que representa a quantidade de tempo que o balanceador de carga aguardará para que o back-end retorne uma resposta completa. Não é um tempo de espera ocioso (keepalive). Esse tempo limite é configurável modificando a configuração de tempo limite para seu serviço de back-end. O valor padrão é de 30 segundos. Pense na possibilidade de aumentar esse tempo limite se:

    • você espera que um back-end demore mais para retornar respostas HTTP; ou
    • a conexão for atualizada para um WebSocket.
  • O tempo limite de uma sessão TCP, que tem o valor corrigido em 10 minutos (600 segundos). Esse período de sessão às vezes é chamado de tempo limite de espera ou ocioso e o valor não é configurável pela modificação de seu serviço de back-end. É necessário configurar o software do servidor da Web usado pelos seus back-ends para que o tempo limite de keepalive seja maior que 600 segundos para impedir que as conexões sejam fechadas prematuramente pelo back-end. Esse tempo limite não se aplica a WebSockets.

Esta tabela ilustra as mudanças necessárias para modificar os tempos limite de keepalive para o software comum do servidor da Web:

Software de servidor da Web Parâmetro Configuração padrão Configuração recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

O balanceamento de carga HTTP(S) faz novas tentativas de solicitações GET com falha em determinadas circunstâncias, como quando o tempo limite de resposta está esgotado. Ele não tenta novamente pedidos POST com falha. As tentativas são limitadas a duas vezes. As novas tentativas de solicitações apenas geram uma entrada de registro para a resposta final. Consulte Como gerar registros para mais informações.

Tratamento de solicitações incorretas

O balanceador de carga HTTP(S) bloqueia as solicitações do cliente e impede que atinjam o back-end por diversas razões: algumas estritamente por compliance HTTP/1.1 e outras para evitar que dados inesperados passem para os back-ends.

O balanceador de carga bloqueia os casos seguintes por compliance HTTP/1.1:

  • Não pode analisar a primeira linha da solicitação.
  • Falta o delimitador : de um cabeçalho.
  • Cabeçalhos ou a primeira linha contêm caracteres inválidos.
  • O comprimento de conteúdo não é um número válido, ou há cabeçalhos com vários comprimentos de conteúdo.
  • Há várias chaves de codificação de transferência, ou há valores de codificação de transferência não reconhecidos.
  • Há um corpo não fragmentado e sem comprimento de conteúdo especificado.
  • Não é possível analisar os fragmentos do corpo. Este é o único caso em que alguns dados chegarão ao back-end. O balanceador de carga fechará as conexões com o cliente e o back-end quando receber um fragmento não analisável.

O balanceador de carga também bloqueia a solicitação se ocorrer qualquer um destes casos:

  • A combinação de URL e cabeçalhos da solicitação for maior do que 15 KB.
  • O método de solicitação não permite corpo, mas a solicitação tem um.
  • A solicitação contém um cabeçalho de upgrade.
  • A versão do HTTP é desconhecida.

Registros

Cada solicitação HTTP(S) é registrada temporariamente com o Stackdriver Logging. Se você foi aceito para a fase de teste Alfa, o registro é automático e não precisa ser ativado.

Como visualizar os registros

Para visualizar os registros, vá para o Visualizador de registros.

Os registros HTTP(S) são indexados primeiro pela regra de encaminhamento e, depois, pelo mapa de URL.

  • Para ver todos os registros no primeiro menu suspenso, selecione Balanceador de carga de HTTP do Cloud > Todas as forwarding_rule_name.
  • Para ver os registros de apenas uma regra de encaminhamento, selecione um único nome de regra de encaminhamento na lista.
  • Para ver os registros de apenas um mapa de URL usado por uma regra de encaminhamento, selecione uma regra de encaminhamento e escolha o mapa de URL desejado.

Campos de registro do tipo booleano geralmente só aparecem se tiverem um valor true. Se um campo booleano tem um valor de false, esse campo é omitido do registro.

A codificação UTF-8 é obrigatória para campos de registro. Os caracteres que não sejam UTF-8 são substituídos por pontos de interrogação.

O que é registrado

As entradas do registro do balanceamento de carga HTTP(S) contêm informações úteis para monitorar e depurar seu tráfego HTTP(S). As entradas do registro contêm:

  • informações gerais mostradas na maioria dos registros do GCP, como gravidade, project ID, número do projeto, timestamp e assim por diante;
  • campos de registro HttpRequest;
  • O código do rastreio e o código da extensão são registrados a partir do X-Cloud-Trace-Context enviado para o back-end. O campo trace é formatado como "projects/[PROJECT_ID]/traces/[TRACE_ID]", enquanto o campo spanId é o valor do código da extensão, mas formatado como uma string hexadecimal 16 caracteres.
  • um campo statusDetails dentro do structPayload. Este campo tem uma string que explica por que o balanceador de carga retornou o status HTTP específico. As tabelas abaixo contêm mais explicações dessas strings de registro.

Mensagens de sucesso de HTTP statusDetail

statusDetails (bem-sucedida) Significado Códigos comuns de resposta associados
response_from_cache A solicitação HTTP foi atendida pelo cache. Qualquer código de resposta armazenável é possível.
response_from_cache_validated O código de retorno foi definido por um entrada de cache que foi validada por um back-end. Qualquer código de resposta armazenável é possível.
response_sent_by_backend A solicitação HTTP foi encaminhada com sucesso por um proxy para o back-end. Devolvido do back-end da VM - qualquer código de resposta é possível.

Mensagens de falha de HTTP statusDetail

statusDetails (falha) Significado Códigos comuns de resposta associados
aborted_request_due_to_backend_early_response Uma solicitação com corpo foi cancelada devido ao back-end enviar uma resposta inicial com um código de erro. A resposta foi encaminhada ao cliente. A solicitação foi encerrada. 4XX ou 5XX
backend_503_propagated_as_error O back-end enviou um 503 do qual o balanceador de carga não pôde se recuperar com novas tentativas. 503
backend_connection_closed_after_partial_response_sent A conexão do back-end fechou inesperadamente depois de uma resposta parcial ter sido enviada ao cliente. Devolvido do back-end da VM - qualquer código de resposta é possível. O valor 0 indica que o back-end não enviou cabeçalhos de resposta completos.
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 pode acontecer se o balanceador de carga estiver enviando tráfego para outra entidade, como um balanceador de carga de terceiros executado em uma instância de VM, que tenha um tempo limite de TCP menor que o tempo limite de 10 minutos (600 segundos) do balanceador de carga HTTP(S). Definir manualmente o tempo limite de TCP (keepalive) no serviço de destino para mais de 600 segundos pode resolver esse problema. 502
backend_early_response_with_non_error_status O backend enviou uma resposta sem erro (1XX ou 2XX) a uma solicitação antes de receber todo o corpo da solicitação. 502
backend_response_corrupted O corpo da resposta HTTP enviada pelo back-end tem uma codificação de transferência fragmentada inválida ou corrompida de outro modo. Qualquer código de resposta é possível, dependendo da natureza da corrupção. Geralmente, 502.
backend_timeout O tempo limite do back-end foi atingido enquanto uma resposta era gerada. 502
body_not_allowed O cliente enviou uma solicitação HTTP com corpo, mas o método HTTP usado não permite um corpo. 400
cache_lookup_failed_after_partial_response O balanceador de carga falhou em fornecer uma resposta completa do cache devido a um erro interno. 2XX
client_disconnected_after_partial_response A conexão com o cliente foi interrompida depois de o balanceador de carga enviar uma resposta parcial. Devolvido do back-end da VM - qualquer código de resposta é possível.
client_disconnected_before_any_response A conexão com o cliente foi interrompida antes de o balanceador de carga enviar uma resposta. 0
client_timed_out O balanceador de carga deixou inativa a conexão com o cliente devido à falta de progresso enquanto a solicitação ou a resposta era encaminhada por proxy. 0
error_uncompressing_gzipped_body Houve um erro ao descompactar uma resposta HTTP compactada como gzip. 503
failed_to_connect_to_backend O balanceador de carga falhou ao se conectar com o back-end. 502
failed_to_pick_backend O balanceador de carga falhou ao escolher um back-end íntegro para administrar a solicitação. 502
headers_too_long Os cabeçalhos da solicitação eram maiores do que o tamanho máximo permitido. 413
http_version_not_supported Versão HTTP não compatível. Atualmente, apenas HTTP 0.9, 1.0, 1.1 e 2.0 são compatíveis. 400
http2_server_push_canceled_invalid_response_code O balanceador de carga cancelou o push do servidor HTTP/2 porque o back-end retornou um código de resposta inválido. Pode ocorrer apenas ao usar http2 para o back-end. O cliente receberá um RST_STREAM contendo INTERNAL_ERROR.
internal_error Erro interno no balanceador de carga. 400
invalid_http2_client_header_format Os cabeçalhos HTTP/2 do cliente são inválidos. 400
malformed_chunked_body O corpo da solicitação foi codificado inadequadamente em fragmentos. 411
required_body_but_no_content_length A solicitação HTTP requer um corpo, mas os cabeçalhos da solicitação não incluem um comprimento de conteúdo ou cabeçalho fragmentado de codificação de transferência. 400 ou 403
secure_url_rejected Uma solicitação com um URL https:// foi recebida em uma conexão HTTP/1.1 de texto simples. 400
unsupported_method O cliente forneceu um método de solicitação HTTP não compatível. 400
upgrade_header_rejected A solicitação HTTP do cliente continha o cabeçalho Upgrade e foi recusada. 400
uri_too_long O URI da solicitação HTTP era mais longo do que o comprimento máximo permitido. 414
websocket_closed A conexão WebSocket foi fechada.
websocket_handshake_failed O handshake do WebSocket falhou. 501

Como registrar listas negra e de permissões de IP

As entradas de registro a seguir no Visualizador de registros são para registro de listas negra e de permissões de IP de HTTP(S) e incluem a estrutura a seguir em jsonPayload. Os detalhes da solicitação HTTP aparecem na mensagem httpRequest.

  • status_details (string): uma descrição em texto do código de resposta
  • enforced_security_policy: a regra da política de segurança que foi aplicada
    • outcome (string): ACCEPT, DENY ou UNKNOWN_OUTCOME
    • configured_action (string): igual à entrada "outcome"
    • name (string): nome da política de segurança
    • priority (número): correspondência com a prioridade da regra
  • preview_security_policy: preenchida se a solicitação atingir uma regra configurada para visualização (presente apenas quando uma regra de visualização tiver prioridade sobre a aplicada)
    • outcome (string): ACCEPT, DENY ou UNKNOWN_OUTCOME
    • configured_action (string): igual à entrada "outcome"
    • name (string): nome da política de segurança
    • priority (número): correspondência com a prioridade da regra

Você pode interagir com os registros do Balanceador de carga de HTTP(S) usando a Stackdriver Logging API. Ela fornece maneiras interativas de filtrar os registros que têm campos específicos definidos e de exportar os registros correspondentes para o Console do Stackdriver, o Google Cloud Storage, o BigQuery ou o Cloud Pub/Sub. Para mais informações sobre a Stackdriver Logging API, consulte Como visualizar registros.

Como monitorar

O balanceamento de carga HTTP(S) exporta dados de monitoramento para Stackdriver. As métricas de monitoramento podem ser usadas para avaliar a configuração, o uso e o desempenho do balanceador de carga HTTP(S), solucionar problemas e melhorar a utilização dos recursos e a experiência do usuário.

Além dos painéis predefinidos no Stackdriver, você pode criar painéis personalizados, configurar alertas e consultar as métricas por meio da Stackdriver Monitoring API.

Como visualizar os painéis de monitoramento do Stackdriver

  1. Acesse o Stackdriver no Console do Google Cloud Platform.
    Ir para o Stackdriver
  2. Selecione Recursos > Balanceadores de carga do Google Cloud.
  3. Clique no nome do seu balanceador de carga.

No painel esquerdo, você pode ver vários detalhes desse balanceador de carga HTTP(S). No painel direito, você pode ver gráficos de séries temporais. Clique no link Detalhamentos para ver os detalhamentos específicos.

Como definir alertas do Stackdriver

Você pode definir alertas do Stackdriver em várias métricas de balanceamento de carga HTTP(S):

  1. Acesse o Stackdriver no Console do Google Cloud Platform.
    Ir para o Stackdriver
  2. Selecione Alertas > Criar uma política.
  3. Clique em Adicionar condição e selecione o tipo de condição.
  4. Selecione as métricas e os filtros. Para métricas, o tipo de recurso é Balanceador de carga HTTP(S).
  5. Clique em Salvar condição.
  6. Digite o nome da política e clique em Salvar política.

Como definir os painéis personalizados do Stackdriver

Você pode criar painéis personalizados do Stackdriver com as métricas de balanceamento de carga HTTP(S):

  1. Acesse o Stackdriver no Console do Google Cloud Platform.
    Ir para o Stackdriver
  2. Selecione Painéis > Criar Painel.
  3. Clique em Adicionar gráfico.
  4. Dê um título ao gráfico.
  5. Selecione as métricas e os filtros. Para métricas, o tipo de recurso é Balanceador de carga HTTP(S).
  6. Clique em Salvar.

Frequência e retenção de relatórios de métricas

As métricas dos balanceadores de carga HTTP(S) são exportadas para o Stackdriver em lotes com granularidade de um minuto. Os dados de monitoramento são retidos por seis semanas. O painel fornece análise de dados em intervalos padrão de uma hora, seis horas, um dia, uma semana e seis semanas. Você pode solicitar análises manualmente em qualquer intervalo de seis semanas a um minuto.

Como monitorar métricas de balanceadores de carga HTTP(S)

As seguintes métricas de balanceadores de carga HTTP(S) são informadas no Stackdriver:

Métrica Descrição
Contagem de solicitações O número de solicitações atendidas pelo balanceador de carga HTTP(S)
Contagem de bytes da solicitação O número de bytes enviados como solicitações dos usuários para o balanceador de carga HTTP(S)
Contagem de bytes da resposta O número de bytes enviados como respostas do balanceador de carga HTTP(S) para usuários
Latências totais Uma distribuição da latência medida a partir do momento em que o primeiro byte da solicitação foi recebido pelo proxy do balanceador de carga, até o proxy receber um ACK do cliente solicitante no último byte de resposta. As latências totais são medidas por solicitação/resposta. Portanto, as pausas entre solicitações na mesma conexão usando "Connection: keep-alive" não afetam a medição. Essa medida geralmente é reduzida para o 95º percentil nas visualizações do Stackdriver.
Exemplo: um balanceador de carga tem 1 solicitação por segundo do Reino Unido com uma latência de 100 ms e 9 solicitações por segundo dos EUA com latência de 50 ms. Durante um determinado minuto, houve 60 solicitações do Reino Unido e 540 solicitações dos EUA. As métricas de monitoramento preservam a distribuição em todas as dimensões. Você pode solicitar o seguinte:
  • latência global mediana (300/600) - 50 ms
  • latência do Reino Unido (30/60) - 100 ms
  • latência geral do 95º percentil (570/600) - 100 ms
  • e assim por diante...
RTT do front-end(*) Uma distribuição do RTT suavizado medido para cada conexão entre cliente e proxy (medida pela pilha TCP do proxy). Normalmente reduzida para o 95º percentil nas visualizações do Stackdriver.
Latências de back-end(*) Uma distribuição da latência medida a partir de quando o primeiro byte de solicitação foi enviado pelo proxy para o back-end, até que o proxy tenha recebido do back-end o último byte da resposta. Normalmente, reduzida para o 95º percentil nas visualizações do Stackdriver.
Fração de classe de código de resposta Porcentagem do total de respostas do balanceador de carga HTTP(S) que estão em cada classe de código de resposta (2XX, 4XX etc.). No Stackdriver, esse valor só está disponível nos painéis padrão e não é possível vê-lo nos painéis personalizados. Você pode definir alertas para ele por meio da API.

(*) Não há garantias de que a soma das latências do RTT de front-end e do back-end será menor ou igual à soma das latências totais. O motivo disso é que, mesmo que pesquisemos o RTT no soquete do proxy para o cliente no momento em que a resposta HTTP é ACKed, confiamos no relatório do kernel para algumas dessas medidas e não podemos garantir que o kernel tenha a medição de RTT para uma determinada resposta HTTP. O resultado final é um valor RTT suavizado que também é afetado por respostas HTTP anteriores, SYN/ACKs e handshakes SSL que não têm impacto sobre os verdadeiros tempos da solicitação HTTP real.

Como filtrar dimensões das métricas do balanceador de carga HTTP(S)

As métricas são agregadas para cada balanceador de carga HTTP(S). Você pode filtrar métricas agregadas pelas seguintes dimensões(*):

Propriedade Descrição
ESCOPO DO BACK-END O escopo do GCP (região ou zona) do grupo de instâncias de back-end que serviu à conexão.

Se nenhum grupo de instâncias estava disponível ou se a solicitação foi atendida por outra entidade, você verá um dos valores a seguir em vez de uma região ou zona do grupo de instâncias do serviço de back-end.
  • FRONTEND_5XX: devido a um erro interno ou falta de back-ends íntegros, o proxy não pôde atribuir um grupo de instâncias para a solicitação. Em vez disso, o proxy retornou uma resposta 5xx ao solicitante.
  • SERVED_FROM_BACKEND_BUCKET: a solicitação foi processada por um intervalo de back-end, não por um grupo de instâncias de serviço de back-end.
  • SERVED_FROM_CACHE: a solicitação foi processada pelo cache do proxy, portanto, não havia nenhum back-end atribuído.
ZONA DO BACK-END Se o grupo de instâncias fosse um grupo de instâncias zonal, a zona do GCP do grupo de instâncias que veiculou a solicitação do usuário. Exemplos: us-central1-a, europe-west1-b, asia-east1-c
REGIÃO DO BACK-END A região do GCP do grupo de instâncias que veiculou a solicitação do usuário, em caso de grupo de istância regional.Exemplos: us-central1, europe-west1, asia-east1
CONTINENTE DO PROXY Continente do proxy HTTP(S) que encerrou a conexão HTTP(S) do usuário. Exemplos: America, Europe, Asia.
GRUPO DE INSTÂNCIAS O nome do grupo de instâncias que atendeu a solicitação do usuário.

Se nenhum grupo de instâncias estava disponível ou se a solicitação foi atendida por outra entidade, você verá um dos valores a seguir em vez de um grupo de instâncias.
  • FRONTEND_5XX: ocorreu um erro interno antes que o proxy pudesse selecionar um back-end. O proxy retornou 5xx ao cliente.
  • INVALID_BACKEND: o proxy não conseguiu encontrar um back-end íntegro para atribuir a solicitação e devolveu uma resposta 5xx ao solicitante.
  • SERVED_FROM_BACKEND_BUCKET: a solicitação foi processada por um intervalo de back-end, não por um grupo de instâncias de serviço de back-end.
  • SERVED_FROM_CACHE: a solicitação foi processada pelo cache do proxy, portanto, não havia nenhum back-end atribuído.
SERVIÇO DE BACK-END O nome do serviço de backend que atendeu a solicitação do usuário.
REGRA DE URL CORRESPONDENTE A regra do caminho do mapa de URL que corresponde ao prefixo da solicitação HTTP(S) do usuário (até 50 caracteres).
REGRA DE ENCAMINHAMENTO O nome da regra de encaminhamento usada pelo cliente para enviar a solicitação.

(*) Atualmente, a métrica "Fração de classe do código de resposta" está disponível apenas no balanceador de carga completo, sem mais detalhamentos disponíveis.

Observações e restrições

  • O balanceamento de carga HTTP(S) é compatível com a resposta HTTP/1.1 100 Continue.
  • Se as instâncias de carga balanceada estão executando uma imagem de sistema operacional público, fornecida pelo Compute Engine, as regras do firewall no sistema operacional são configuradas automaticamente para permitir tráfego de carga balanceada. Se usar uma imagem personalizada, é preciso configurar manualmente o firewall do sistema operacional. Isso é feito separadamente da regra de firewall do GCP, que é preciso criar como parte da configuração de um balanceador de carga HTTP(S).
  • O balanceamento de carga não mantém instâncias em sincronização. É preciso configurar seus próprios mecanismos, como usar o Administrador de implantação, para garantir que suas instâncias tenham configurações e dados consistentes.
  • O balanceador de carga HTTP(S) não é compatível com o envio de um HTTP DELETE com um corpo para o balanceador de carga. Essas solicitações receberão uma mensagem de erro: Error 400 (Bad Request)!! Your client has issued a malformed or illegal request. Apenas as solicitações DELETE sem corpo são compatíveis.

Como solucionar problemas

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

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

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

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


NoSuchKey
The specified key does not exist.

A compressão não está funcionando

O Balanceamento de carga HTTP(S) não comprime nem descomprime respostas, mas pode veicular respostas geradas pelo seu serviço de back-end, comprimidas com ferramentas como gzip ou DEFLATE.

Se as respostas veiculadas por o Balanceamento de carga HTTP(S) não forem comprimidas como deveriam, confirme se o software servidor da Web em execução nas suas instâncias está configurado para comprimir respostas. Por padrão, alguns softwares servidor da Web desativam automaticamente a compactação de solicitações que incluem o cabeçalho Via. A presença de um cabeçalho Via indica que a solicitação foi encaminhada por um proxy. Como é 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, pode ser necessário modificar a configuração padrão do seu servidor da Web para que ele compacte respostas mesmo que a solicitação tenha um cabeçalho Via.

Se você estiver usando o software do servidor da Web nginx, modifique o arquivo de configuração nginx.conf para ativar a compactação. O local deste arquivo depende de onde o nginx está instalado. Em muitas distribuições do Linux, o arquivo fica armazenado em /etc/nginx/nginx.conf. Para permitir que a compressão do nginx funcione com o balanceamento de carga HTTP(S), adicione as duas linhas seguintes à seção http do nginx.conf:

gzip_proxied any;
gzip_vary on;

A primeira linha ativa a compressão até mesmo para solicitações encaminhadas por um proxy como o balanceamento de carga HTTP(S). A segunda linha adiciona um cabeçalho Vary: Accept-Encoding às respostas. Vary: Accept-Encoding notifica proxies de armazenamento em cache, como o Cloud CDN, de que precisam manter entradas de cache separadas para variantes compactadas e não compactadas de recursos compactáveis.

Após modificar o nginx.conf, você precisa reiniciar o nginx antes que ele use a nova configuração. Em muitas distribuições do Linux, o nginx pode ser reiniciado ao executar sudo service nginx restart ou /etc/init.d/nginx restart.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine