Visão geral do balanceamento de carga de HTTP(S) externo

Neste documento, apresentamos os conceitos que você precisa entender para configurar o balanceamento de carga HTTP(S) externo do Google Cloud.

Conheça as diferenças entre os balanceadores de carga do Google Cloud nos documentos a seguir:

Casos de uso

Os balanceadores de carga HTTP(S) externos abordam muitos casos de uso. Esta seção fornece alguns exemplos detalhados.

Balanceamento de carga com diversos tipos de back-end

O balanceamento de carga HTTP(S) externo é compatível com os seguintes tipos de back-end:

Um caso de uso comum é o tráfego de balanceamento de carga entre os serviços. No exemplo a seguir, os clientes IPv4 e IPv6 externos podem solicitar conteúdo de vídeo, API e imagem usando o mesmo URL de base, com os caminhos /api, /video e /images.

O mapa de URLs do balanceador de carga HTTP(S) externo especifica que:

  • As solicitações para o caminho /api vão para um serviço de back-end com um grupo de instâncias de VM ou um back-end de NEG zonal.
  • As solicitações para o caminho /images vão para um bucket de back-end com um back-end do Cloud Storage.
  • As solicitações para o caminho /video vão para um serviço de back-end que indica um NEG da Internet que contém um endpoint externo no local, fora do Google Cloud.

Quando um cliente envia uma solicitação para o endereço IPv4 ou IPv6 externo do balanceador de carga, este avalia a solicitação de acordo com o mapa de URL e envia a solicitação ao serviço correto.

O diagrama a seguir mostra esse caso de uso.

Diagrama de balanceamento de carga com origem personalizada (clique para ampliar)
Diagrama de balanceamento de carga com origem personalizada (clique para ampliar)

Em cada serviço de back-end, você tem a opção de ativar o Cloud CDN e o Google Cloud Armor. Se você estiver usando o Google Cloud Armor com o Cloud CDN, as políticas de segurança serão aplicadas apenas para solicitações de conteúdo dinâmico, ausências no cache ou outras solicitações destinadas ao servidor de origem CDN. As ocorrências em cache serão exibidas mesmo se a política de segurança downstream do Google Cloud Armor impedir que a solicitação chegue ao servidor de origem CDN.

Os buckets de back-end são compatíveis com o Cloud CDN, mas não com o Google Cloud Armor.

Serviços da Web de três camadas

É possível usar balanceamento de carga HTTP(S) externo para dar suporte a serviços da Web de três camadas tradicionais. O exemplo a seguir mostra como é possível usar três tipos de balanceadores de carga do Google Cloud para escalonar três camadas. Em cada camada, o tipo do balanceador de carga depende do seu tipo de tráfego:

O diagrama mostra como o tráfego passa pelas camadas:

  1. Um balanceador de carga HTTP(S) externo (objeto desta visão geral) distribui o tráfego da Internet para um grupo de instâncias de front-end da Web em várias regiões.
  2. Esses front-ends enviam o tráfego HTTP(S) para um conjunto de balanceadores de carga HTTP(S) regionais internos.
  3. Os balanceadores de carga HTTP(S) internos distribuem o tráfego para grupos de instâncias de middleware.
  4. Esses grupos de instâncias de middleware enviam o tráfego para balanceadores de carga TCP/UDP internos, que balanceiam a carga do tráfego para clusters de armazenamento de dados.
Roteamento baseado na camada 7 para camadas internas em um app de várias camadas (clique para ampliar)
Roteamento baseado na camada 7 para camadas internas em um app de várias camadas

Balanceamento de carga entre regiões

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

Quando você configura um balanceador de carga HTTP(S) externo no nível Premium, ele usa um endereço IP externo global e pode encaminhar solicitações de usuários de maneira inteligente para o grupo de instâncias de back-end ou NEG mais próximo, com base na proximidade. Por exemplo, se você configurar grupos de instâncias na América do Norte, Europa e Ásia e anexá-los ao serviço de back-end de um balanceador de carga, as solicitações de usuários do mundo inteiro serão enviadas automaticamente para as VMs mais próximas dos usuários, supondo que as VMs sejam aprovadas nas verificações de integridade e tenham capacidade suficiente (definida pelo modo de balanceamento). Se todas as VMs mais próximas não estiverem íntegras ou se o grupo de instâncias mais próximo estiver no limite da capacidade e outro não estiver no limite, o balanceador de carga enviará automaticamente as solicitações para a região seguinte mais próxima com capacidade.


Balanceamento de carga baseado em conteúdo

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

O balanceamento de carga HTTP(S) é compatível com balanceamento de carga baseado em conteúdo usando mapas de URL para selecionar um serviço de back-end com base no nome do host solicitado, no caminho da solicitação ou ambos. Por exemplo, você pode usar um conjunto de grupos de instâncias ou NEGs para processar seu conteúdo de vídeo e outro conjunto para processar o restante.

Também é possível usar o balanceamento de carga HTTP(S) com buckets do Cloud Storage. Depois de configurar o balanceador de carga, é possível adicionar buckets do Cloud Storage a ele.


Como criar um balanceador de carga combinado

Representação de
  balanceamento de carga baseado em conteúdo e entre regiões

É possível configurar um balanceador de carga HTTP(S) externo no nível Premium para fornecer balanceamento de carga baseado em conteúdo e entre regiões, usando vários serviços de back-end, cada um com grupos de instâncias de back-end ou NEGs em várias regiões. É possível combinar e estender os casos de uso para configurar um balanceador de carga HTTP(S) externo que atenda às suas necessidades.


Exemplo de configuração

Se você já quiser começar e criar um balanceador de carga funcional para fazer testes, veja estes links para saber como configurar um balanceador de carga externo e simples que seja HTTP ou HTTPS.

Veja um exemplo mais complexo que usa balanceamento de carga (HTTPS) com base em conteúdo e entre regiões em Como criar um balanceador de carga HTTPS.

Como as conexões funcionam no balanceamento de carga de HTTP(S)

O balanceamento de carga HTTP(S) externo é um serviço implementado por muitos proxies chamados Google Front Ends (GFEs). Não existe apenas um proxy. No nível Premium, o mesmo endereço IP externo global é anunciado a partir de vários pontos de presença, e o tráfego é direcionado para o GFE mais próximo do cliente.

Dependendo de onde seus clientes estão, vários GFEs podem iniciar conexões HTTP(S) com os back-ends. Os pacotes enviados de GFEs têm endereços IP de origem do mesmo intervalo usado pelas sondagens de verificação de integridade: 35.191.0.0/16 e 130.211.0.0/22.

Dependendo da configuração do serviço de back-end, o protocolo usado por cada GFE para se conectar aos back-ends pode ser HTTP, HTTPS ou HTTP/2. Se HTTP ou HTTPS, a versão HTTP é HTTP 1.1. O sinal de atividade HTTP está ativado por padrão, conforme a especificação HTTP 1.1. O GFE usa um tempo limite de sinal de atividade de 600 segundos e não é possível configurá-lo. No entanto, é possível configurar o tempo limite da solicitação/resposta definindo o tempo limite do serviço de back-end. Saiba mais em Tempos limite e novas tentativas.

Os sinais de atividade HTTP tentam usar de forma eficiente a mesma sessão TCP. No entanto, não há garantias. Embora esteja estreitamente relacionado, um sinal de atividade HTTP e um sinal de inatividade TCP não são a mesma coisa.

Os números de conexões HTTP e sessões TCP variam de acordo com o número de GFEs conectados, o número de clientes que se conectam aos GFEs, o protocolo aos back-ends e onde os back-ends são implantados.

Saiba mais em Como funciona o balanceamento de carga HTTP(S) no guia de soluções: Otimizações de capacidade de aplicativos com balanceamento de carga global.

Arquitetura e recursos

Veja no diagrama a seguir os recursos do Google Cloud necessários em um balanceador de carga HTTP(S) externo.

Componentes do balanceamento de carga HTTP(S) (clique para ampliar)
Componentes de balanceamento de carga HTTP(S)

Os recursos a seguir definem um balanceador de carga HTTP(S) externo:

  • Uma regra de encaminhamento externo especifica um endereço IP externo, uma porta e um proxy HTTP(S) de destino global. Os clientes usam o endereço IP e a porta para se conectar ao balanceador de carga.

  • Um proxy HTTP(S) de destino global recebe uma solicitação do cliente. O proxy HTTP(S) avalia a solicitação usando o mapa de URLs para tomar decisões de roteamento de tráfego. O proxy também pode autenticar comunicações usando certificados SSL.

  • Se você estiver usando o balanceamento de carga HTTPS, o proxy HTTPS de destino usará certificados SSL globais para provar a identidade dele aos clientes. Um proxy HTTPS de destino é compatível com um número documentado de certificados SSL.

  • O proxy HTTP(S) usa um mapa de URLs globais para determinar o roteamento com base em atributos HTTP, como caminho da solicitação, cookies ou cabeçalhos. Com base na decisão de roteamento, o proxy encaminha solicitações de cliente para serviços ou buckets de back-end específicos. O mapa de URLs pode especificar ações adicionais, como o envio de redirecionamentos para clientes.

  • Um serviço de back-end ou bucket de back-end distribui as solicitações para back-ends íntegros.

  • Um ou mais back-ends precisam estar conectados ao serviço ou bucket de back-end. Os back-ends podem ser grupos de instâncias, NEGs ou buckets em qualquer uma das seguintes configurações:

    • Grupos de instâncias gerenciadas (zonais ou regionais)
    • Grupos de instâncias não gerenciadas (zonais)
    • Grupos de endpoints de rede (zonais)
    • Grupos de endpoints da rede (Internet)
    • Buckets do Cloud Storage

    Não é possível ter grupos de instâncias e NEGs no mesmo serviço de back-end.

  • Uma verificação de integridade global monitora periodicamente a prontidão de seus back-ends. Isso reduz o risco de que solicitações sejam enviadas para back-ends que não podem atender à solicitação.

  • Um firewall para que os back-ends aceitem sondagens de verificação de integridade.

Endereços IP de origem

Os endereços IP de origem dos pacotes, conforme vistos por cada instância ou contêiner de máquina virtual (VM) de back-end, são um endereço IP destes intervalos:

  • 35.191.0.0/16
  • 130.211.0.0/22

O endereço IP de origem para o tráfego real com carga balanceada é o mesmo que o intervalo de IP da sondagem das verificações de integridade.

Os endereços IP de origem para o tráfego, conforme vistos pelos back-ends, não são o endereço IP externo do Google Cloud do balanceador de carga. Em outras palavras, há duas sessões HTTP, SSL ou TCP:

  • Sessão 1, do cliente original para o balanceador de carga (GFE):

    • Endereço IP de origem: o cliente original ou endereço IP externo se o cliente estiver usando NAT.
    • Endereço IP de destino: o endereço IP do seu balanceador de carga.
  • Sessão 2: do balanceador de carga (GFE) para a VM ou contêiner de back-end:

    • Endereço IP de origem: um endereço IP em um destes intervalos: 35.191.0.0/16 ou 130.211.0.0/22.

      Não é possível prever o endereço de origem real.

    • Endereço IP de destino: o endereço IP interno da VM ou contêiner de back-end na rede da nuvem privada virtual (VPC).

Comunicações do cliente com o balanceador de carga

  • Os clientes podem se comunicar com o balanceador de carga por meio do protocolo HTTP 1.1 ou HTTP/2.
  • Quando HTTPS é usado, o padrão dos clientes modernos é HTTP/2. Isso é controlado no cliente, não no balanceador de carga HTTPS.
  • Não é possível desativar o HTTP/2 alterando a configuração no balanceador de carga. No entanto, é possível configurar alguns clientes para usar HTTP 1.1 em vez de HTTP/2. Por exemplo, com curl, use o parâmetro --http1.1.
  • Os balanceadores de carga HTTPS não são compatíveis com a autenticação baseada em certificado de cliente, também conhecida como autenticação TLS mútua.

Portas abertas

Os balanceadores de carga HTTP(S) externos são balanceadores de carga de proxy reverso. O balanceador de carga encerra as conexões de entrada e depois abre novas conexões do balanceador de carga para os back-ends. A funcionalidade de proxy reverso é fornecida pelos front-ends do Google (GFEs).

As regras de firewall definidas por você bloqueiam o tráfego dos GFEs para os back-ends, mas não bloqueiam o tráfego de entrada para os GFEs.

Os balanceadores de carga HTTP(S) externos têm diversas portas abertas para oferecer suporte a outros serviços do Google executados na mesma arquitetura. Se você executar uma verificação de segurança ou de porta em relação ao endereço IP externo do balanceador de carga HTTP(S) externo do Google Cloud, outras portas parecerão estar abertas.

Isso não afeta os balanceadores de carga HTTP(S) externos. As regras de encaminhamento externas, que são usadas na definição de um balanceador de carga HTTP(S) externo, podem referenciar somente as portas TCP 80, 8080 e 443. O tráfego com uma porta de destino TCP diferente não é encaminhado para o back-end do balanceador de carga.

Componentes

A seguir, veja os componentes dos balanceadores de carga HTTP(S) externos.

Regras e endereços de encaminhamento

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

Cada regra de encaminhamento fornece um único endereço IP que pode ser usado em registros DNS do aplicativo. Não é necessário nenhum balanceamento de carga baseado no DNS. É possível especificar o endereço IP a ser usado ou permitir que o Cloud Load Balancing atribua um para você.

  • A regra de encaminhamento de um balanceador de carga HTTP só pode referenciar as portas TCP 80 e 8080.
  • A regra de encaminhamento de um balanceador de carga HTTPS só pode referenciar a porta TCP 443.

O tipo de regra de encaminhamento exigido por balanceadores de carga HTTP(S) externos depende do Nível de serviço da rede do balanceador de carga.

  • Os balanceadores de carga HTTP(S) externos no nível Premium usam regras globais de encaminhamento externo.
  • Os balanceadores de carga HTTP(S) externos no nível Standard usam regras regionais de encaminhamento externo.

Proxies de destino

Os proxies de destino encerram as conexões HTTP(S) dos clientes. Uma ou mais regras de encaminhamento direcionam o tráfego para o proxy de destino, que consulta o mapa de URLs para determinar como rotear o tráfego para os back-ends.

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] (apenas solicitações)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (somente solicitações)
    Contém parâmetros para o Cloud Trace.

É possível criar cabeçalhos de solicitação e resposta personalizados se os cabeçalhos padrão não atenderem às suas necessidades. Para mais informações sobre esse recurso, consulte Como criar cabeçalhos personalizados.

Não espere que o proxy mantenha a capitalização dos nomes de cabeçalho de solicitação ou resposta. Por exemplo, um cabeçalho de resposta Server: Apache/1.0 pode aparecer no cliente como server: Apache/1.0.

Cabeçalho Host

Quando o balanceador de carga faz a solicitação HTTP, o balanceador de carga preserva o cabeçalho Host da solicitação original.

Cabeçalho X-Forwarded-For

O balanceador de carga anexa dois endereços IP ao cabeçalho X-Forwarded-For:

  • O endereço IP do cliente que se conecta ao balanceador de carga

  • O endereço IP do balanceador de carga

Se não houver um cabeçalho X-Forwarded-For na solicitação de entrada, esses dois endereços IP serão o valor inteiro do cabeçalho. Se a solicitação tiver um cabeçalho X-Forwarded-For, outras informações, como os endereços IP registrados por proxies a caminho do balanceador de carga, serão preservadas antes dos dois endereços IP. O balanceador de carga não verifica endereços IP que precedem os dois últimos endereços IP nesse cabeçalho.

Se você estiver executando um proxy em sua instância de back-end, esse proxy geralmente anexará mais informações ao cabeçalho X-Forwarded-For. Seu software precisará levar isso em consideração. As solicitações por proxy do balanceador de carga vêm de um endereço IP no intervalo 130.211.0.0/22 ou 35.191.0.0/16, e o proxy na instância de back-end pode registrar esse endereço, bem como o endereço IP da própria instância de back-end.

Mapas de URL

Os mapas de URL definem os padrões de correspondência do roteamento de solicitações baseado em URL aos 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 roteamento 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 o balanceamento de carga baseado em HTTPS, precisará instalar um ou mais certificados SSL no proxy HTTPS de destino.

Esses certificados são usados por proxies HTTPS de destino para proteger as comunicações entre o balanceador de carga e o cliente.

Saiba mais sobre limites e cotas de certificados SSL nesta seção da página de cotas de balanceamento de carga.

Para ter a melhor segurança, use a criptografia de ponta a ponta na implantação do balanceador de carga HTTPS. Saiba mais em Criptografia do balanceador de carga nos back-ends.

Saiba mais sobre como o Google criptografa o tráfego dos usuários no artigo Criptografia em trânsito no Google Cloud.

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 de SSL e criptografias são usadas nas próprias conexões HTTPS ou SSL. É possível 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.

Controle geográfico sobre o local em que o TLS é encerrado

O balanceador de carga HTTPS encerra o TLS em locais que são distribuídos globalmente, de modo a minimizar a latência entre os clientes e o balanceador de carga. Se você precisar de controle geográfico sobre o local em que o TLS é encerrado, use o Balanceamento de carga de rede do Google Cloud e encerre o TLS nos back-ends localizados em regiões adequadas às suas necessidades.

Serviços de back-end

Os serviços de back-end fornecem informações de configuração ao balanceador de carga. Um balanceador de carga HTTP(S) externo precisa ter, no mínimo, um serviço de back-end, mas pode ter vários.

Os balanceadores de carga usam as informações de um serviço de back-end para direcionar o tráfego de entrada para um ou mais back-ends anexados.

Os back-ends de um serviço de back-end podem ser grupos de instâncias ou grupos de endpoints de rede (NEGs), mas não uma combinação dessas duas opções. Ao adicionar um grupo de instâncias de back-end ou NEG, você especifica um modo de balanceamento, que define um método de distribuição de solicitações e uma capacidade de destino. Saiba mais em Algoritmo de distribuição de carga.

O balanceamento de carga HTTP(S) é compatível com o escalonador automático do Cloud Load Balancing, com que os usuários podem fazer escalonamento automático nos grupos de instâncias de um serviço de back-end. Saiba mais Como escalonar com base na capacidade de exibição do balanceamento de carga HTTP(S).

Ative a diminuição da conexão em serviços de back-end para garantir interrupção mínima aos usuários quando uma instância que está veiculando tráfego é encerrada, removida manualmente ou removida por um escalonador automático. Saiba mais em Como ativar a diminuição da conexão.

As alterações em um serviço de back-end associado a um balanceador de carga HTTP(S) externo não são instantâneas. Pode levar vários minutos para que as alterações sejam propagadas pela rede.

Comportamento do balanceador de carga em diferentes Níveis de serviço de rede

O balanceamento de carga HTTP(S) é um serviço global quando o Nível de serviço da rede Premium é usado. É possível ter mais de um serviço de back-end em uma região e criar serviços de back-end em mais de uma região, todos atendidos pelo mesmo balanceador de carga global. O tráfego é alocado aos serviços de back-end da seguinte forma:

  1. Quando uma solicitação de usuário chega, o serviço de balanceamento de carga determina a origem aproximada da solicitação pelo endereço IP de origem.
  2. O serviço de balanceamento de carga sabe a localização das instâncias pertencentes ao serviço de back-end, a capacidade total e o uso atual geral.
  3. Se as instâncias mais próximas do usuário tiverem capacidade disponível, a solicitação é encaminhada a esse conjunto mais próximo de instâncias.
  4. Solicitações recebidas para a região determinada são distribuídas uniformemente em todos os serviços de back-end e instâncias disponíveis naquela região. No entanto, em cargas muito pequenas, a distribuição pode parecer irregular.
  5. Se não houver instâncias íntegras com capacidade disponível em uma determinada região, o balanceador de carga envia a solicitação para a região seguinte mais próxima com capacidade disponível.

O balanceamento de carga HTTP(S) é um serviço regional quando o Nível de serviço da rede Standard é usado. Todos os grupos de instâncias de back-end ou NEGs precisam estar localizados na região usada pelo endereço IP externo do balanceador de carga e pela regra de encaminhamento.

Verificações de integridade

Cada serviço de back-end também especifica qual verificação de integridade é executada em cada instância disponível. Para que as sondagens de verificação de integridade funcionem corretamente, crie uma regra de firewall que permita que o tráfego de 130.211.0.0/22 e 35.191.0.0/16 alcance suas instâncias.

Saiba mais sobre verificações de integridade em Como criar verificações de integridade.

Protocolo para os back-ends

Ao configurar um serviço de back-end para o balanceador de carga HTTP(S) externo, você define o protocolo que o serviço de back-end usará para se comunicar com os back-ends. As opções são HTTP, HTTPS ou HTTP/2. O balanceador de carga usará apenas o protocolo que você especificar. O balanceador de carga não recorrerá a um dos outros protocolos se não conseguir negociar uma conexão com o back-end usando o protocolo especificado.

Se você usar HTTP/2, use o TLS. O HTTP/2 sem criptografia não é compatível.

Embora não seja obrigatório, é recomendável usar uma verificação de integridade que tenha um protocolo que corresponda ao usado pelo serviço de back-end. Por exemplo, uma verificação de integridade HTTP/2 testa com mais precisão a conectividade HTTP/2 aos back-ends.

Como usar o gRPC com seus aplicativos do Google Cloud

gRPC (em inglês) é um framework de código aberto de chamadas de procedimento remoto. Ele é baseado no padrão HTTP/2. Veja alguns casos de uso para o gRPC:

  • sistemas distribuídos de baixa latência e altamente escalonáveis
  • desenvolvimento de clientes de dispositivos móveis que se comuniquem com um servidor em nuvem
  • criação de novos protocolos que ofereçam precisão, eficiência e não dependam de linguagem
  • design em camadas que permita extensão, autenticação e geração de registros

Para usar o gRPC com seus aplicativos do Google Cloud, é necessário enviar solicitações de proxy completas pelo HTTP/2. Para fazer isso com um balanceador de carga HTTP(S) externo:

  1. Configure um balanceador de carga HTTPS.
  2. Ative o HTTP/2 como o protocolo do balanceador de carga para os back-ends.

O balanceador de carga negocia o HTTP/2 com clientes como parte do handshake SSL usando a extensão ALPN TLS.

O balanceador de carga ainda pode negociar HTTPS com alguns clientes ou aceitar solicitações HTTP não seguras em um balanceador de carga HTTP(S) externo configurado para usar HTTP/2 entre o balanceador de carga e as instâncias de back-end. Essas solicitações HTTP ou HTTPS são transformadas pelo balanceador de carga para representar as solicitações por HTTP/2 para as instâncias de back-end.

Se quiser configurar um balanceador de carga HTTP(S) externo usando o HTTP/2 com a Entrada do Google Kubernetes Engine ou usando o gRPC e o HTTP/2 com a Entrada, consulte HTTP/2 para balanceamento de carga com Entrada.

Saiba mais sobre a solução de problemas com o HTTP/2 em Como resolver problemas com o HTTP/2 para os back-ends.

Saiba mais sobre as limitações do HTTP/2 em Limitações do HTTP/2.

Buckets de back-end

Os buckets de back-end direcionam o tráfego recebido para os buckets do Cloud Storage.

Como mostrado no diagrama a seguir, o balanceador de carga pode enviar tráfego com um caminho de /static para um bucket de armazenamento e todas as demais solicitações para seus outros back-ends.

Como distribuir tráfego para vários tipos de back-ends com balanceamento de carga HTTP(S) (clique para ampliar)
Como distribuir tráfego para vários tipos de back-ends com balanceamento de carga HTTP(S) (clique para ampliar)

Veja um exemplo de como adicionar um bucket a um balanceador de carga existente em Como configurar um balanceador de carga com buckets de back-end.

Regras de firewall

As instâncias de back-end precisam permitir conexões dos intervalos de verificação de integridade/GFE do balanceador de carga. Isso significa que você precisa criar uma regra de firewall que permita que o tráfego de 130.211.0.0/22 e 35.191.0.0/16 alcance suas instâncias ou endpoints de back-end. Esses intervalos de endereços IP são usados como origens para pacotes de verificação de integridade e para todos os pacotes com carga balanceada enviados aos back-ends.

As portas configuradas para essa regra de firewall precisam permitir o tráfego para instâncias ou endpoints de back-end:

  • É preciso permitir as portas usadas por cada regra de encaminhamento
  • É preciso permitir as portas usadas por cada verificação de integridade configurada para cada serviço de back-end

As regras de firewall são implementadas no nível da instância de VM, e não nos proxies do Google Front End (GFE). Não é possível usar regras de firewall do Google Cloud para impedir que o tráfego chegue ao balanceador de carga.

Saiba mais sobre sondagens de verificação de integridade e por que é necessário permitir tráfego de 130.211.0.0/22 e 35.191.0.0/16 em Intervalos de IP de sondagem e regras de firewall.

Caminho de retorno

O Google Cloud usa rotas especiais não definidas em sua rede VPC para verificações de integridade. Saiba mais em Caminhos de retorno do balanceador de carga.

Algoritmo de distribuição de carga

Ao adicionar um grupo de instâncias de back-end ou NEG a um serviço de back-end, você especifica um modo de balanceamento, que define um método de medição da carga de back-end e uma capacidade de destino. O balanceamento de carga HTTP(S) externo é compatível com dois modos de balanceamento:

  • RATE, para grupos de instâncias ou NEGs, é o número máximo de solicitações (consultas) por segundo (RPS, QPS). O RPS/QPS máximo do destino pode ser excedido se todos os back-ends atingirem ou ultrapassarem a capacidade.

  • UTILIZATION é o uso de back-ends de VMs em um grupo de instâncias.

Antes de um Google Front End (GFE) enviar solicitações a instâncias de back-end, o GFE avalia quais delas têm capacidade para receber solicitações. Essa estimativa de capacidade é feita proativamente, e não ao mesmo tempo que as solicitações chegam. Os GFEs recebem informações periódicas sobre a capacidade disponível e distribuem as solicitações recebidas de acordo.

O significado de capacidade depende, em parte, do modo de balanceamento. Quanto ao modo RATE, é relativamente simples: um GFE determina exatamente quantas solicitações ele pode atribuir por segundo. O balanceamento de carga baseado em UTILIZATION é mais complexo: o balanceador de carga verifica o uso atual das instâncias e, em seguida, calcula uma carga de consulta que cada instância pode processar. Essa estimativa muda ao longo do tempo à medida que o uso da instância e os padrões de tráfego mudam.

Ambos os fatores (a estimativa de capacidade e a atribuição proativa) influenciam a distribuição entre as instâncias. Assim, o Cloud Load Balancing se comporta de maneira diferente de um balanceador de carga round-robin simples que distribui as solicitações exatamente meio a meio entre duas instâncias. Em vez disso, o balanceamento de carga do Google Cloud tenta otimizar a seleção de instância de back-end para cada solicitação.

Saiba mais em Distribuição de tráfego.

Saiba mais sobre os modos de balanceamento em Modo de balanceamento.

Network Service Tiers

Quando um balanceador de carga HTTP(S) externo está no nível Premium, as solicitações enviadas ao balanceador de carga são entregues aos grupos de instâncias de back-end ou NEGs na região mais próxima do usuário, se a capacidade do back-end nessa região estiver disponível. A capacidade disponível é configurada pelo modo de balanceamento do balanceador de carga.

Quando um balanceador de carga HTTP(S) externo está no nível Standard, os grupos de instância de back-end ou NEGs dele precisam estar todos localizados na região usada pelo endereço IP externo do balanceador de carga e pela regra de encaminhamento.

Regiões e zonas

Assim que a região for selecionada:

  • Quando você configura back-ends em várias zonas de uma região, um balanceador de carga HTTP(S) externo tenta equilibrar as solicitações da maneira mais uniforme possível em todas as zonas, sujeito à capacidade da instância de back-end e à afinidade da sessão.

  • Dentro de uma zona, um balanceador de carga HTTP(S) externo tenta equilibrar solicitações usando o algoritmo de balanceamento de carga, sujeito à capacidade disponível e à afinidade de sessão.

Afinidade da sessão

A afinidade de sessão oferece uma tentativa de melhor esforço de enviar solicitações de um determinado cliente para o mesmo back-end enquanto ele está íntegro e com capacidade, de acordo com o modo de balanceamento configurado.

O balanceamento de carga do Google Cloud HTTP(S) oferece três tipos de afinidade de sessão:

  • NENHUMA. A afinidade de sessão não está definida para o balanceador de carga.
  • A afinidade de IP do cliente envia solicitações do mesmo endereço IP do cliente para o mesmo back-end.
  • A afinidade de cookie gerado define um cookie de cliente quando a primeira solicitação é realizada e depois envia solicitações com esse cookie para o mesmo back-end.

Ao usar a afinidade de sessão, recomendamos o modo de balanceamento RATE, e não UTILIZATION. A afinidade de sessão tem um melhor desempenho quando o modo de balanceamento é configurado como solicitações por segundo (RPS).

Suporte a WebSocket

Os balanceadores de carga baseados em HTTP(S) do Google Cloud têm suporte nativo para o protocolo WebSocket ao usar HTTP ou HTTPS como protocolo para o back-end. O balanceador de carga não precisa de configuração para representar conexões WebSocket.

O protocolo WebSocket fornece um canal de comunicação full-duplex entre clientes e servidores. Uma solicitação HTTP(S) inicia o canal. Para informações detalhadas sobre o protocolo, consulte RFC 6455.

Quando o balanceador de carga reconhece uma solicitação WebSocket Upgrade de um cliente HTTP(S) seguida por uma resposta Upgrade bem-sucedida da instância de back-end, o balanceador de carga faz o proxy do tráfego bidirecional durante a conexão atual. Se a instância de back-end não retornar uma resposta Upgrade bem-sucedida, o balanceador de carga encerrará a conexão.

O tempo limite de uma conexão WebSocket depende do tempo limite configurável do serviço de back-end do balanceador de carga, que é 30 segundos, por padrão. Esse tempo limite se aplica a conexões WebSocket, estando em uso ou não. Para mais informações sobre o tempo limite do serviço de back-end e como configurá-lo, consulte Tempos limite e tentativas.

A afinidade de sessão para WebSockets funciona da mesma forma que qualquer outra solicitação. Para mais informações, consulte Afinidade da sessão.

Compatibilidade do balanceamento de carga HTTPS com o protocolo QUIC

O balanceamento de carga HTTPS é compatível com o protocolo QUIC (em inglês) nas conexões entre o balanceador de carga e os clientes. O QUIC é um protocolo de camada de transporte que oferece controle de congestionamento semelhante ao TCP e segurança equivalente a SSL/TLS para HTTP/2, com desempenho aprimorado. O QUIC permite uma inicialização mais rápida da conexão do cliente, elimina o bloqueio "head-of-line" em fluxos multiplexados e aceita a migração da conexão quando o endereço IP de um cliente é alterado.

O QUIC afeta as conexões entre os clientes e o balanceador de carga, e não as conexões entre o balanceador de carga e os back-ends.

A configuração de modificação do QUIC do proxy de destino permite ativar uma das seguintes opções:

  • Negociar o QUIC para um balanceador de carga quando possível.
  • Sempre desativar o QUIC para um balanceador de carga.

Se você não especificar um valor para a configuração de substituição do QUIC, o Google poderá gerenciar o uso do QUIC. O Google ativa o QUIC somente quando a sinalização --quic-override na ferramenta de linha de comando gcloud está definida como ENABLE ou quando a sinalização quicOverride na API REST está definida como ENABLE.

Saiba mais sobre como ativar e desativar o suporte ao QUIC em Proxies de destino. Você pode ativar ou desativar o suporte ao QUIC da seguinte maneira:

Como o QUIC é negociado

Quando você ativa o QUIC, o balanceador de carga pode divulgar o próprio recurso QUIC para os clientes. Isso permite que os clientes que aceitam o QUIC tentem estabelecer conexões QUIC com o balanceador de carga HTTPS. Os clientes implementados corretamente sempre recorrem a HTTPS ou HTTP/2 quando não conseguem estabelecer uma conexão QUIC. Por causa disso, ativar ou desativar o QUIC no balanceador de carga não afeta a capacidade do balanceador de carga de se conectar com os clientes.

Quando o QUIC está ativado no seu balanceador de carga HTTPS, algumas circunstâncias podem fazer com que seu cliente recorra a HTTPS ou HTTP/2 em vez de negociar o QUIC. Por exemplo:

  • quando um cliente aceita versões do QUIC que não são compatíveis com as versões do QUIC aceitas pelo balanceador de carga HTTPS;
  • quando o balanceador de carga detecta que o tráfego UDP está bloqueado ou tem limitação de taxa de modo que impediria o funcionamento do QUIC;
  • se o QUIC estiver temporariamente desativado para balanceadores de carga HTTPS em resposta a bugs, vulnerabilidades ou outras preocupações.

Quando uma conexão retorna para HTTPS ou HTTP/2 devido a essas circunstâncias, não consideramos isso uma falha do balanceador de carga.

Verifique se os comportamentos descritos acima são aceitáveis para suas cargas de trabalho antes de ativar o QUIC.

Certificados SSL

Referencie um ou mais certificados SSL no proxy HTTPS de destino.

Eles são usados por proxies HTTPS de destino para proteger comunicações entre um front-end do Google (GFE) e o cliente. Esses certificados podem ser autogerenciados ou SSL gerenciados pelo Google.

Saiba mais sobre limites e cotas de certificados SSL nesta seção da página de cotas de balanceamento de carga.

Para ter a melhor segurança, você também pode criptografar o tráfego dos GFEs para seus back-ends. Saiba mais em Criptografia do balanceador de carga para os back-ends.

Saiba mais sobre como o Google criptografa o tráfego dos usuários no artigo Criptografia em trânsito no Google Cloud.

Suporte TLS

Por padrão, um proxy de destino HTTPS só aceita TLS 1.0, 1.1 e 1.2 ao encerrar solicitações SSL do cliente. É possível 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 serviço de back-end HTTP configurável, que representa o tempo que o balanceador de carga aguarda até que o back-end retorne uma resposta HTTP completa. O valor padrão do tempo limite do serviço de back-end é de 30 segundos. Considere aumentar esse tempo limite em qualquer uma destas circunstâncias:

    • Você espera que um back-end demore mais para retornar respostas HTTP.
    • Você vê respostas HTTP 408 com o jsonPayload.statusDetail client_timed_out.
    • A conexão recebeu um upgrade para um WebSocket

    Para o tráfego WebSocket enviado pelo balanceador de carga, o tempo limite do serviço de back-end é interpretado como o tempo máximo em que uma conexão WebSocket pode permanecer aberta, esteja ela inativa ou não. Saiba mais em Configurações do serviço de back-end.

  • O tempo limite de uma sessão TCP, que tem o valor fixado em 10 minutos (600 segundos). Esse período de sessão às vezes é chamado de tempo limite do sinal de atividade ou ocioso e o valor dele não é configurável pela modificação do serviço de back-end. É necessário configurar o software servidor da Web usado pelos seus back-ends para que o tempo limite do sinal de atividade 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 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 balanceador de carga repete solicitações GET com falha em determinadas circunstâncias, como quando o tempo limite do serviço de back-end é esgotado. Ele não repete solicitações POST com falha. As repetições são limitadas a duas tentativas. As solicitações repetidas geram apenas uma entrada de registro como resposta final.

Saiba mais em Como gerar registros e monitorar balanceamento de carga HTTP(S).

O protocolo WebSocket é compatível com a Entrada.

Tratamento de solicitações e respostas inválidas

O balanceador de carga HTTP(S) externo impede que as solicitações do cliente e as respostas do back-end cheguem ao back-end ou ao cliente, respectivamente, por diversos motivos. Alguns deles referem-se estritamente à conformidade com HTTP/1.1 e outros servem para evitar a passagem de dados inesperados para ou de back-ends. Nenhuma das verificações pode ser desativada.

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

  • Não é possível analisar a primeira linha da solicitação.
  • Falta o delimitador : em um cabeçalho.
  • Cabeçalhos ou a primeira linha contêm caracteres inválidos.
  • O comprimento do 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 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. Esse é o único caso em que alguns dados chegam ao back-end. O balanceador de carga fecha as conexões com o cliente e o back-end quando recebe um bloco não analisável.

O balanceador de carga bloqueará a solicitação se alguma das seguintes condições for verdadeira:

  • O tamanho total dos cabeçalhos de solicitação e o URL de solicitação excedem o limite de tamanho máximo de cabeçalhos de solicitação para balanceamento de carga HTTP(S) externo.
  • O método de solicitação não permite corpo, mas a solicitação tem um.
  • A solicitação contém um cabeçalho Upgrade, mas Upgrade não é usado para permitir conexões WebSocket.
  • A versão do HTTP é desconhecida.

O balanceador de carga bloqueará a resposta do back-end se alguma das seguintes condições for verdadeira:

  • O tamanho total dos cabeçalhos de resposta excede o limite de tamanho máximo de cabeçalhos de resposta para balanceamento de carga HTTP(S) externo.
  • A versão do HTTP é desconhecida.

Especificações e limitações

  • O balanceamento de carga HTTP(S) é compatível com a resposta HTTP/1.1 100 Continue.

Limitações do HTTP/2

  • O HTTP/2 entre o balanceador de carga e a instância pode exigir muito mais conexões TCP com a instância do que o HTTP(S). O pool de conexões, uma otimização que reduz o número dessas conexões com HTTP(S), não está disponível atualmente com o HTTP/2.
  • O HTTP/2 entre o balanceador de carga e o back-end não é compatível com a execução do protocolo WebSocket em um único stream de uma conexão HTTP/2 (RFC 8461).
  • O HTTP/2 entre o balanceador de carga e o back-end não é compatível com push do servidor.
  • A taxa de erros do gRPC e o volume da solicitação não são visíveis na API do Google Cloud ou no Console do Cloud. Se o endpoint do gRPC retornar um erro, os registros do balanceador de carga e os dados de monitoramento reportarão o código de resposta HTTP "OK 200".

Restrição ao usar o Cloud CDN

  • Não é possível ativar o Identity-Aware Proxy ou o Cloud CDN com o mesmo serviço de back-end. Se você tentar fazer isso, o processo de configuração falhará.

A seguir