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.

Para informações sobre as diferenças entre os balanceadores de carga do Google Cloud, consulte os 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

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 NEG de zona.
  • 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 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 de 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ância de middleware enviam o tráfego para balanceadores de carga TCP/UDP internos, que balanceam 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

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 até um número documentado de certificados SSL.

  • O proxy HTTP(S) usa um mapa de URLs globais para fazer a determinação do roteamento com base em atributos HTTP, como caminho de 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 solicitações para back-ends íntegros (grupos de instâncias contendo VMs do Compute Engine, NEGs contendo contêineres do GKE) ou buckets do Cloud Storage.

  • 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 possam 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 de back-end (VM), são um endereço IP desses intervalos:

  • 35.191.0.0/16
  • 130.211.0.0/22

O endereço IP de origem para o tráfego de balanceador de carga real é 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: 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 por meio de uma alteração de 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 do 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, outras portas parecerão 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 fazer referência somente às 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 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 e o proxy de destino consulta o mapa de URLs para determinar como rotear o tráfego para 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-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in Google Cloud> (apenas solicitações)

    O cabeçalho X-Forwarded-For (XFF) contém uma lista de endereços IP separados por vírgula que representa proxies por meio de que a solicitação passou. Cada proxy pode anexar o endereço IP do próprio cliente à lista. Por isso, o número de endereços IP no cabeçalho XFF pode variar. Um balanceador de carga HTTP(S) externo do Google Cloud adiciona dois endereços IP ao cabeçalho: o endereço IP do cliente solicitante e o endereço IP externo da regra de encaminhamento do balanceador de carga, nessa ordem.

    Portanto, o endereço IP que precede imediatamente o endereço IP do balanceador de carga do Google Cloud é o endereço IP do sistema que entra em contato com o balanceador de carga. O sistema pode ser um cliente ou outro servidor proxy, externo ao Google Cloud, que encaminha solicitações em nome de um cliente.

    Quando um servidor proxy de fora do Google Cloud entra em contato com o balanceador de carga HTTP(S) externo do Google Cloud em nome de um cliente, o balanceador de carga pode não receber o endereço IP do cliente do sistema que entra em contato com esse proxy. O proxy externo pode não anexar o endereço IP do cliente dele ao cabeçalho XFF. Se todos os proxies externos anexarem um endereço IP de cliente ao cabeçalho XFF, o primeiro endereço IP na lista será o endereço IP do cliente original.

    Se as VMs de back-end de um balanceador de carga HTTP(S) externo atuam como proxies internos, podem adicionar mais endereços IP do cliente ao cabeçalho XFF. Nesse caso, o endereço IP da regra de encaminhamento do balanceador de carga HTTP(S) externo pode não ser o último endereço IP na lista.

  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (apenas solicitações)

    Contém parâmetros para o Cloud Trace.

É possível criar cabeçalhos de solicitação 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 de solicitação definidos pelo usuário.

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.

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 HTTPS, será necessário instalar 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, na sigla em inglês) e o cliente. Esses certificados podem ser autogerenciados ou SSL gerenciados pelo Google.

Para mais informações sobre limites e cotas de certificados SSL, consulte esta seção na 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 de HTTPS externo. Para mais informações, consulte Criptografia do balanceador de carga nos back-ends.

Para mais informações gerais sobre como o Google criptografa o tráfego dos usuários, consulte o 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 tanto 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. Para mais informações, consulte Algoritmo de distribuição de carga.

O balanceamento de carga HTTP(S) é compatível com o autoescalador 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. Para mais informações, consulte Escalonamento baseado na capacidade de veiculaçã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 autoescalador. Para saber mais, consulte 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 é implementado. É 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 é utilizado. Todos os grupos de instância 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.

Para mais informações sobre verificações de integridade, consulte 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 sobre o 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 HTTP/2 com o Google Kubernetes Engine Ingress ou usando o gRPC e HTTP/2 com Ingress, consulte HTTP/2 para balanceamento de carga com Ingress.

Consulte Como resolver problemas com o HTTP/2 para os back-ends para saber mais sobre o assunto.

Consulte Limitações do HTTP/2 para saber mais sobre elas.

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 outras 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)

Para ver um exemplo que mostra como adicionar um bucket a um balanceador de carga existente, consulte Como configurar um balanceador de carga com buckets de back-end.

Regras de firewall

É preciso 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 de back-end ou endpoints. Esses intervalos de endereços IP são usados como origens para pacotes de verificação de integridade e para todos os pacotes com balanceamento de carga enviados aos back-ends.

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

  • É 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, 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.

Para mais informações sobre sondagens de verificação de integridade e porque é necessário permitir tráfego de 130.211.0.0/22 e 35.191.0.0/16, consulte 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. Para mais informações, consulte Caminhos de retorno do balanceador de carga.

Algoritmo de distribuição de carga

O balanceamento de carga HTTP(S) externo é compatível com dois modos de balanceamento para back-ends:

  • RATE para back-ends de grupo de instância ou NEGs
  • UTILIZATION para back-ends de grupos de instâncias

Os back-ends de um serviço de back-end podem ser grupos de instância ou NEGs, mas não uma combinação de ambas as 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. Para back-ends de grupos de instâncias, você pode usar o modo de balanceamento UTILIZATION ou RATE. Para NEGs, use RATE.

Ao usar o modo de balanceamento RATE, é preciso especificar um número máximo desejado de solicitações (consultas) por segundo (RPS, QPS). Essa meta é usada para definir quando uma instância ou um endpoint atingiu a capacidade. A RPS/QPS máxima desejada pode ser excedida se todos os back-ends atingirem ou ultrapassarem a capacidade.

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

Assim que a região for selecionada:

  • Um balanceador de carga HTTP(S) externo tenta equilibrar solicitações da maneira mais uniforme possível dentro das zonas de uma região, sujeito à afinidade da sessão. Quando você configura vários grupos de instâncias regionais ou NEGs na mesma região, ou um ou mais grupos de instâncias regionais gerenciados, o balanceador de carga externo HTTP(S) apresenta esse comportamento.

  • Em uma zona, um balanceador de carga HTTP(S) externo tenta equilibrar solicitações com algoritmo de ordem aleatória, sujeito à afinidade da sessão.

Consulte Como funciona o balanceamento de carga HTTP(S) para ver exemplos específicos do algoritmo de distribuição de carga.

Afinidade da sessão

A afinidade da sessão oferece uma tentativa de melhor esforço de enviar solicitações de um determinado cliente para o mesmo back-end enquanto o back-end estiver íntegro e a capacidade dele não tiver sido ultrapassada, 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, então, envia solicitações com esse cookie para o mesmo back-end.

Recomendamos o modo de balanceamento RATE, em vez de UTILIZATION, ao usar a afinidade da sessão. A afinidade da sessão tem um melhor desempenho quando o modo de balanceamento é configurado como solicitações por segundo (RPS).

Suporte ao proxy WebSocket

O balanceamento de carga HTTP(S) tem suporte nativo para o protocolo WebSocket ao usar HTTP ou HTTPS, e não HTTP/2, como o protocolo para o back-end.

Os back-ends que usam o protocolo WebSocket para se comunicar com os clientes podem usar o balanceador de carga HTTP(S) externo como front-end para escalonamento e disponibilidade. O balanceador de carga não precisa de configuração adicional para conexões WebSocket via proxy.

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

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

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

Se você tiver configurado o IP do cliente ou a afinidade de sessão de cookie gerado para seu balanceador de carga HTTP(S) externo, todas as conexões WebSocket de um cliente serão enviadas para a mesma instância de back-end, se essa instância continuar a ser aprovada nas verificações de integridade e não tiver atingido a capacidade máxima.

O protocolo WebSocket é compatível com o Ingress.

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, 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 quando o QUIC é usado. 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.

Para ver informações sobre como ativar e desativar o suporte ao QUIC, consulte Proxies de destino. É possível ativar ou desativar o suporte ao QUIC na seção de configuração de front-end do Console do Google Cloud usando a ferramenta de linha de comando gcloud ou a API REST.

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

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: incluída no SDK do Cloud. Na documentação do balanceamento de carga HTTP(S), essa ferramenta é frequentemente usada para a realização de tarefas. Para uma visão geral completa da ferramenta, consulte o Guia da ferramenta gcloud. Encontre comandos relacionados ao balanceamento de carga no grupo de comandos gcloud compute.

    Também é possível acessar a ajuda detalhada de qualquer comando gcloud usando a sinalização --help:

    gcloud compute http-health-checks create --help
    
  • O Console do Cloud: tarefas de balanceamento de carga podem ser realizadas usando o Console do Cloud.

  • A API REST: todas as tarefas de balanceamento de carga podem ser realizadas usando a API Cloud Load Balancing. Os documentos de referência da API descrevem os recursos e métodos disponíveis para você.

Suporte TLS

Por padrão, um proxy de destino HTTPS só aceita TLS 1.0, 1.1, 1.2 e 1.3 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 resposta 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 de resposta é 30 segundos. Considere aumentar esse número em uma destas circunstâncias:

    • Você espera que um back-end demore mais para retornar respostas HTTP.
    • A conexão foi atualizada para um WebSocket. Esse caso se aplica somente ao balanceamento de carga HTTP(S).

    Para o tráfego do 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 do WebSocket pode permanecer aberta, seja ela inativa ou não. Para mais informações, consulte 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 de resposta está 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.

Para mais informações, consulte Geração de registros e monitoramento de balanceamento de carga HTTP(S).

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 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. 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 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 e URL de resposta exceder o limite de tamanho máximo de cabeçalhos de resposta para balanceamento de carga de HTTP(S) externo.
  • A versão do HTTP é desconhecida.

Limitações

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:
    • push de servidor
    • WebSockets

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