Visão geral do balanceador de carga de aplicativo externo

Neste documento, apresentamos os conceitos necessários para configurar um balanceador de carga de aplicativo externo.

O balanceador de carga de aplicativo externo é um balanceador de carga global da camada 7 baseado em proxy que permite executar e escalonar serviços atrás de um único endereço IP externo. O balanceador de carga de aplicativo externo distribui o tráfego HTTP e HTTPS aos back-ends hospedados em várias plataformas do Google Cloud, como Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage e outras, assim como back-ends externos conectados pela Internet ou por conectividade híbrida. Para detalhes, consulte Visão geral do balanceador de carga de aplicativo: casos de uso.

Modos de operação

É possível configurar um balanceador de carga de aplicativo externo nos seguintes modos:

• Balanceador de carga de aplicativo externo global Este é um balanceador de carga global que é implementado como um serviço gerenciado no Google Front Ends (GFEs). Ele usa o proxy Envoy de código aberto para oferecer suporte a recursos avançados de gerenciamento de tráfego, como espelhamento de tráfego, divisão de tráfego baseada em peso, transformações de cabeçalho com base em solicitação/resposta e muito mais.
• Balanceador de carga de aplicativo clássico Este é o balanceador de carga de aplicativo externo clássico que é global no nível Premium, mas pode ser configurado para ser regional no nível Standard. Esse balanceador de carga é implementado no Google Front Ends (GFEs). Os GFEs são distribuídos globalmente e funcionam em conjunto usando a rede global e o plano de controle do Google.
• Balanceador de carga de aplicativo externo regional Esse é um balanceador de carga regional implementado como um serviço gerenciado no proxy Envoy de código aberto (em inglês). Ele inclui recursos avançados de gerenciamento de tráfego, como espelhamento de tráfego, divisão de tráfego baseada em peso, transformações de cabeçalho com base em solicitação/resposta e muito mais.

Modo balanceador de carga	Casos de uso recomendados	Recursos
Balanceador de carga de aplicativo externo global	Use esse balanceador de carga para cargas de trabalho HTTP(S) externas com usuários dispersos globalmente ou serviços de back-end em várias regiões.	Compatível com o GKE usando o gateway (totalmente orquestrado) ou NEGs independentes (orquestração manual). Suporta gerenciamento de tráfego avançado Endereços IP externos Anycast globais no nível Premium Pode acessar back-ends em várias regiões Compatível com Cloud CDN. Compatível com o Google Cloud Armor
Balanceador de carga de aplicativo clássico	Esse balanceador de carga é global no nível Premium, mas pode ser configurado para ser efetivamente regional no nível Standard. No nível do serviço de rede Premium, esse balanceador de carga oferece balanceamento de carga multirregional, tente redirecionar o tráfego para o back-end íntegro mais próximo que tiver capacidade e encerra o tráfego HTTP(S) o mais próximo possível dos usuários. Para detalhes sobre o processo de distribuição de solicitações, consulte Distribuição de tráfego. No nível de serviço de rede padrão, o balanceamento de carga é processado regionalmente.	Compatível com o GKE usando o Gateway (totalmente orquestrado), Entrada (totalmente orquestrada) ou NEGs independentes (orquestração manual). Compatível com o Google Cloud Armor Menos recursos de roteamento de tráfego Consulte a página de Recursos do balanceamento de carga para ver a lista completa de recursos.
Balanceador de carga de aplicativo externo regional	Esse balanceador de carga contém muitos dos recursos do balanceador de carga clássico do aplicativo atual, além de recursos de gerenciamento de tráfego avançado. Use este balanceador de carga se quiser veicular conteúdo de apenas uma geolocalização (por exemplo, para atender a regulamentações de conformidade). Este balanceador de carga pode ser configurado no nível Premium ou Standard.	Compatível com o GKE usando NEGs independentes (orquestração manual). Compatível com recursos avançados de gerenciamento de tráfego VIPs regionais usando o nível Padrão de rede Encerra o TLS em uma única região que você configura Veicula conteúdo somente da região configurada Para ver a lista completa, consulte Recursos de balanceamento de carga.

Identificar o modo

console do Cloud

1. No Console do Google Cloud, acesse a página Balanceamento de carga.
   Acessar balanceamento de carga

2. Na guia Balanceadores de carga, você verá o protocolo, a região e o tipo de balanceador. Se a região estiver em branco, o balanceador de carga será global. Veja na tabela a seguir como identificar o modo do balanceador de carga.

   Modo balanceador de carga	Tipo do balanceador de carga	Tipo de acesso	Região
   Balanceador de carga de aplicativo externo global	legado	Externos
   Balanceador de carga de aplicativo clássico	Aplicativo (clássico)	Externos
   Balanceador de carga de aplicativo externo regional	legado	Externos	Especifica uma região

gcloud

1. Para determinar o modo de um balanceador de carga, execute o seguinte comando:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

   Na saída do comando, verifique o esquema de balanceamento de carga, a região e o nível da rede. Veja na tabela a seguir como identificar o modo do balanceador de carga.

   Modo balanceador de carga	Esquema de balanceamento de carga	Regra de encaminhamento	Nível da rede
   Balanceador de carga de aplicativo externo global	EXTERNAL_MANAGED	Global	Premium
   Balanceador de carga de aplicativo clássico	EXTERNO	Global	Padrão ou Premium
   Balanceador de carga de aplicativo externo regional	EXTERNAL_MANAGED	Especifica uma região	Padrão ou Premium

Importante: depois de criar um balanceador de carga, não é possível editar o modo. Em vez disso, é preciso excluir o balanceador de carga e criar um novo.

Arquitetura

Os seguintes recursos são necessários para uma implantação externa do balanceador de carga de aplicativo:

• Somente para balanceadores de carga de aplicativo regionais externos, uma sub-rede somente proxy é usada para enviar conexões do balanceador de carga para os back-ends.

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

  • No balanceamento de carga HTTPS, o proxy HTTPS de destino usa certificados SSL para provar a identidade 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 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 distribui as solicitações para back-ends íntegros. Os balanceadores de carga de aplicativo externos globais também são compatíveis com buckets de back-end.

  • Um ou mais back-ends precisam estar conectados ao serviço ou bucket de back-end.

• Uma verificação de integridade 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.

• Regras de firewall para que os back-ends aceitem sondagens de verificação de integridade. Os balanceadores de carga de aplicativo regionais exigem uma regra de firewall extra para permitir que o tráfego da sub-rede somente proxy atinja os back-ends.

Global

Este diagrama mostra os componentes de uma implantação do balanceador de carga de aplicativo externo global. Essa arquitetura se aplica ao balanceador de carga de aplicativo externo global e ao balanceador de carga de aplicativo clássico no nível Premium.

Componentes globais do balanceador de carga de aplicativo externo

Regional

Este diagrama mostra os componentes de uma implantação do balanceador de carga de aplicativo externo regional.

Componentes regionais do balanceador de carga de aplicativo externo

Sub-rede somente proxy

Sub-redes somente proxy são necessárias apenas para balanceadores de carga regionais de aplicativos externos.

A sub-rede somente proxy fornece um conjunto de endereços IP que o Google usa para executar proxies Envoy em seu nome. É necessário criar uma sub-rede somente proxy em cada região de uma rede VPC em que você usa balanceadores de carga de aplicativo internos. A sinalização --purpose dessa sub-rede apenas de proxy é definida como REGIONAL_MANAGED_PROXY. Todos os balanceadores de carga regionais baseados em Envoy na mesma região e rede VPC compartilham um pool de proxies do Envoy da mesma sub-rede somente proxy. Além disso:

• As sub-redes somente proxy são usadas apenas para proxies Envoy, não para seus back-ends.
• As VMs de back-end ou os endpoints de todos os balanceadores de carga de aplicativo internos em uma região e uma rede VPC recebem conexões da sub-rede somente proxy.
• O endereço IP do balanceador de carga regional externo do aplicativo não está localizado na sub-rede somente proxy. O endereço IP do balanceador de carga é definido pela regra de encaminhamento gerenciada interna, descrita abaixo.

Se você já tiver criado uma sub-rede somente proxy com --purpose=INTERNAL_HTTPS_LOAD_BALANCER, é necessário migrar a finalidade da sub-rede para REGIONAL_MANAGED_PROXY antes de criar outros balanceadores de carga baseados no Envoy na mesma região da rede VPC.

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

Cada regra de encaminhamento para um balanceador de carga de aplicativo pode ter referência a uma única porta de 1 a 65535. Para permitir várias portas, configure várias regras de encaminhamento. É possível configurar várias regras de encaminhamento para usar o mesmo endereço IP externo (VIP) e ter referência ao mesmo proxy HTTP(S) de destino, desde que a combinação geral do endereço IP, da porta e do protocolo sejam exclusivos para cada regra de encaminhamento. Dessa forma, é possível usar um único balanceador de carga com um mapa de URL compartilhado como um proxy para vários aplicativos.

O tipo de regra de encaminhamento, o endereço IP e o esquema de balanceamento de carga usado por balanceadores de carga de aplicativo externos depende do modo do balanceador de carga e de qual nível de serviço de rede o balanceador está.

Modo balanceador de carga	Nível de serviço de rede	Regra de encaminhamento, endereço IP e esquema de balanceamento de carga	Como rotear da Internet para o front-end do balanceador de carga
Balanceador de carga de aplicativo externo global	Nível Premium	Regra de encaminhamento externo global Endereço IP externo global Esquema de balanceamento de carga: EXTERNAL_MANAGED	Solicitações encaminhadas para o GFE mais próximo do cliente na Internet.
Balanceador de carga de aplicativo clássico	Nível Premium	Regra de encaminhamento externo global Endereço IP externo global Esquema de balanceamento de carga: EXTERNAL	Solicitações encaminhadas para o GFE mais próximo do cliente na Internet.
	Nível Standard	Regra de encaminhamento externo regional Endereço IP externo regional Esquema de balanceamento de carga: EXTERNAL	Solicitações encaminhadas para um GFE na região do balanceador de carga.
Balanceador de carga de aplicativo externo regional	Nível Premium ou Standard ^*	Regra de encaminhamento externo regional Endereço IP externo regional Esquema de balanceamento de carga: EXTERNAL_MANAGED	Solicitações encaminhadas para os proxies do Envoy na mesma região que o balanceador de carga.

^* Não é possível usar o console do Google Cloud para criar um balanceador de carga de aplicativo externo regional no nível Premium. Além disso, apenas regiões com suporte ao nível Standard estão disponíveis para esses balanceadores de carga no console do Google Cloud. Use a gcloud ou a API.

Confira a lista completa de protocolos compatíveis com as regras de encaminhamento do balanceador de carga de aplicativo em cada modo em Recursos do balanceador de carga.

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.

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.

Observação: para grupos de endpoints de rede (NEGs, na sigla em inglês) da Internet, as solicitações do balanceador de carga vêm de diferentes intervalos de IPs, dependendo do tipo de NEG (global ou regional) ). Para mais informações, consulte Como autenticar solicitações.

A tabela a seguir especifica o tipo de proxy de destino exigido pelos balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Tipos de proxy de destino	Cabeçalhos adicionados pelo proxy	Cabeçalhos personalizados compatíveis	Cloud Trace compatível
Balanceador de carga de aplicativo externo global	HTTP global, HTTPS global	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: [<fornecido-valor>],<cliente-ip>,<load-balancer-ip> (consulte Cabeçalho X-Forwarded-For) (somente solicitações) Os proxies também podem definir o cabeçalho X-Cloud-Trace-Context.	Configurado no serviço ou bucket de back-end Sem suporte ao Cloud CDN
Balanceador de carga de aplicativo clássico	HTTP global, HTTPS global	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: [<fornecido-valor>],<cliente-ip>,<load-balancer-ip> (consulte Cabeçalho X-Forwarded-For) (somente solicitações) Os proxies também podem definir o cabeçalho X-Cloud-Trace-Context.	Configurado no serviço ou bucket de back-end
Balanceador de carga de aplicativo externo regional	HTTP regional, HTTPS regional	X-Forwarded-Proto: [http] https] (apenas solicitações) Via: 1.1 google (solicitações e respostas) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulte Cabeçalho X-Forwarded-For) (somente solicitações)

Observação: de acordo com a RFC 2616, os seguintes cabeçalhos de salto por salto não são propagados pelo proxy de destino: Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding e Upgrade.

Além dos cabeçalhos adicionados pelo proxy de destino, o balanceador de carga ajusta outros cabeçalhos HTTP das seguintes maneiras:

• Para o balanceador de carga de aplicativo externo global, os cabeçalhos de resposta e solicitação são sempre convertidos em letras minúsculas. Por exemplo, Host se torna host e Keep-ALIVE se torna keep-alive.

  A única exceção é quando você usa back-ends globais de NEG da Internet com HTTP/1.1. Para detalhes sobre como os cabeçalhos HTTP/1.1 são processados com NEGs globais da Internet, consulte a Visão geral de NEGs da Internet.

• Para o balanceador de carga clássico do aplicativo, os cabeçalhos de solicitação e resposta são convertidos em letras minúsculas, exceto quando você usa HTTP/1.1. No HTTP/1.1, os cabeçalhos são inseridos corretamente. A primeira letra da chave do cabeçalho e todas as letras após um hífen (-) são exibidas em maiúsculas para preservar a compatibilidade com clientes HTTP/1.1. Por exemplo, user-agent é alterado para User-Agent e content-encoding é alterado para Content-Encoding.

• Alguns cabeçalhos são agrupados. Quando houver várias instâncias da mesma chave de cabeçalho (por exemplo, Via), o balanceador de carga combinará os valores delas em uma lista separada por vírgulas para uma chave de cabeçalho. Serão agrupados somente cabeçalhos com valores que possam ser representados como uma lista separada por vírgulas. Outros cabeçalhos, como Set-Cookie, nunca são agrupados.

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 separados por uma única vírgula ao cabeçalho X-Forwarded-For, na seguinte ordem:

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

Se não houver nenhum cabeçalho X-Forwarded-For na solicitação recebida, esses dois endereços IP serão o valor inteiro do cabeçalho:

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Se a solicitação incluir um cabeçalho X-Forwarded-For, o balanceador de carga preservará o valor fornecido antes de <client-ip>,<load-balancer-ip>:

X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>

Atenção: o balanceador de carga não verifica endereços IP que precedem <client-ip>,<load-balancer-ip> neste cabeçalho. Os endereços IP anteriores podem conter outros caracteres, incluindo espaços.

Ao executar o software de proxy HTTP reverso nos back-ends do balanceador de carga, ele pode anexar um ou os dois endereços IP a seguir no final do cabeçalho X-Forwarded-For:

• O endereço IP do Google Front End (GFE) que se conectou ao back-end. Esses endereços IP estão nos intervalos 130.211.0.0/22 e 35.191.0.0/16.

• O endereço IP do próprio sistema de back-end.

Assim, um processo upstream após o back-end do balanceador de carga pode receber um cabeçalho X-Forwarded-For com este formato:

<existing-values>,<client-ip>,<load-balancer-ip><GFE-IP><backend-IP>

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 do 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 solicitações, o mapa de URL permite dividir o tráfego examinando os componentes do URL para enviar solicitações a diferentes conjuntos de back-ends.

Os mapas de URL usados com balanceadores de carga de aplicativo externos globais e externos oferecem suporte a vários recursos avançados de gerenciamento de tráfego, como direcionamento de tráfego baseado em cabeçalho, divisão de tráfego baseado em peso e espelhamento de solicitação. Para ver mais informações, consulte os seguintes tópicos:

• Visão geral do gerenciamento de tráfego para balanceador de carga de aplicativo externo global.
• Visão geral do gerenciamento de tráfego para balanceador de carga de aplicativo externo regional.

A tabela a seguir especifica o tipo de mapa de URL exigido pelos balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Tipo de mapa de URL
Balanceador de carga de aplicativo externo global	Global
Balanceador de carga de aplicativo clássico	Global (com apenas um subconjunto de recursos compatíveis)
Balanceador de carga de aplicativo externo regional	Regional

Certificados SSL

Os balanceadores de carga de aplicativo externos que usam proxies HTTPS de destino exigem chaves privadas e certificados SSL como parte da configuração do balanceador de carga:

• O Google Cloud oferece dois métodos de configuração para atribuir chaves privadas e certificados SSL a destinos de HTTPS: certificados SSL do Compute Engine e Gerenciador de certificados. Para uma descrição de cada configuração, consulte Métodos de configuração de certificado nas informações gerais dos certificados SSL.

• O Google Cloud oferece dois tipos de certificado: autogerenciados e gerenciados pelo Google. Para conferir uma descrição de cada tipo, consulte Tipos de certificado nas informações gerais de certificados SSL.

• O tipo de balanceador de carga de aplicativo externo (global, regional ou clássico) determina quais métodos de configuração e tipos de certificado são compatíveis. Para mais detalhes, consulte Certificados e balanceadores de carga do Google Cloud nas informações gerais dos certificados SSL.

TLS mútuo

Normalmente, com a comunicação HTTPS, a autenticação funciona apenas de uma maneira: o cliente verifica a identidade do servidor. Para aplicativos que exigem que o balanceador de carga autentique a identidade de clientes que se conectam a ele, um balanceador de carga de aplicativo externo global e um balanceador de carga de aplicativo clássico são compatíveis com TLS mútuo (mTLS, na sigla em inglês).

Com o mTLS, o balanceador de carga solicita que o cliente envie um certificado para se autenticar durante o handshake de TLS com o balanceador de carga. É possível configurar um repositório de confiança que o balanceador de carga usa para validar a cadeia de confiança do certificado do cliente.

O Google Cloud usa o recurso TrustConfig no Gerenciador de certificados para armazenar certificados que o servidor usa para verificar o certificado apresentado pelo cliente. Se você estiver usando um balanceador de carga de aplicativo clássico no nível de serviço de rede Premium ou um balanceador de carga de aplicativo externo global, poderá usar o Gerenciador de certificados para provisionar e gerenciar seus certificados SSL ou TrustConfig em várias instâncias do balanceador de carga em escala. Para mais informações, consulte a Visão geral do Gerenciador de certificados.

Para mais informações sobre mTLS, consulte Autenticação TLS mútua.

Políticas de SSL

As políticas de SSL especificam o conjunto de recursos de SSL que os balanceadores de carga do Google Cloud usam ao negociar SSL com clientes.

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 uma política de SSL para especificar o conjunto de recursos de SSL que o balanceador de carga usa ao negociar SSL com clientes. Além disso, é possível aplicar essa política de SSL ao proxy HTTPS de destino.

A tabela a seguir especifica o suporte da política de SSL com balanceadores de carga em cada modo.

Modo balanceador de carga	Políticas de SSL suportadas
Balanceador de carga de aplicativo externo global
Balanceador de carga de aplicativo clássico
Balanceador de carga de aplicativo externo regional

Bucket e serviços de back-end

Os serviços de back-end fornecem informações de configuração ao balanceador de carga. 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. Para um exemplo que mostra como configurar um balanceador de carga com um serviço de back-end e um back-end do Compute Engine, consulte Como configurar um balanceador de carga de aplicativo externo com um back-end do Compute Engine.

Os buckets de back-end direcionam o tráfego recebido para os buckets do Cloud Storage. Veja um exemplo de como adicionar um bucket a um balanceador de carga de aplicativo externo em Como configurar um balanceador de carga com buckets de back-end.

A tabela a seguir especifica os recursos de back-end compatíveis com balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Back-ends compatíveis em um serviço de back-end						Compatível com intervalos de back-end	Compatível com o Google Cloud Armor	Compatível com o Cloud CDN^#	Compatível com o IAP^#	Compatível com extensões de serviço
	Grupos de instâncias	NEGs por zona	NEGs na Internet	NEGs sem servidor	NEGs híbridos	NEGs do Private Service Connect
Balanceador de carga de aplicativo externo global	^‡	^†,‡
Balanceador de carga de aplicativo clássico		^*							Nível Premium
Balanceador de carga de aplicativo externo regional		^*

^* Use endpoints do tipo GCE_VM_IP_PORT com o GKE: Use NEGs zonais independentes ou use a Entrada

^† Use endpoints do tipo GCE_VM_IP_PORT com o GKE: Use NEGs zonais independentes

^‡Compatível apenas com o GKE Gateway Controller

^# O IAP e o Cloud CDN são incompatíveis entre si. Eles não podem ser ativados no mesmo serviço de back-end.

Para ver mais informações, consulte os seguintes tópicos:

• Visão geral dos serviços de back-end
• O que é o Cloud Storage?

Back-ends e redes VPC

As restrições de onde os back-ends podem estar localizados dependem do tipo de balanceador de carga.

• Para o balanceador de carga de aplicativo externo global e o balanceador de carga de aplicativo clássico, todas as instâncias de back-end dos back-ends de grupos de instâncias e todos os endpoints de back-end dos back-ends de NEG precisam estar localizados no mesmo projeto. No entanto, um back-end de grupo de instâncias ou um NEG pode usar uma rede VPC diferente nesse projeto. As diferentes redes VPC não precisam estar conectadas usando peering de rede VPC porque os GFEs se comunicam diretamente com back-ends nas respectivas redes VPC.
• Para o balanceador de carga de aplicativo externo regional, todos os back-ends precisam estar localizados na mesma rede e região VPC.

Protocolo para os back-ends

Ao configurar um serviço de back-end para o balanceador de carga, 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.

Para ver a lista completa de protocolos compatíveis, consulte Recursos de balanceamento de carga: protocolos do balanceador de carga para os back-ends.

Suporte a WebSocket

Os balanceadores de carga baseados em HTTP(S) do Google Cloud têm suporte integrado 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 da conexão WebSocket depende do tipo de balanceador de carga (global, regional ou clássico). Para mais detalhes, consulte Tempo limite do serviço de back-end.

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.

Como usar o gRPC com seus aplicativos do Google Cloud

O gRPC é uma biblioteca de código aberto para chamadas de procedimento remoto. Ele é baseado no padrão HTTP/2. Veja alguns casos de uso do gRPC:

• Sistemas distribuídos de baixa latência e altamente escalonáveis.
• Desenvolvimento de clientes de dispositivos móveis que se comunicam 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:

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

Ative o TLS nos back-ends. Saiba mais em Criptografia do balanceador de carga nos back-ends.

Se quiser configurar um balanceador de carga de aplicativo 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.

Verificações de integridade

Cada serviço de back-end especifica uma verificação de integridade que monitora periodicamente a prontidão dos back-ends para receber uma conexão do balanceador de carga. Isso reduz o risco de as solicitações serem enviadas para back-ends que não possam atender à solicitação. As verificações de integridade não conferem se o aplicativo em si está funcionando.

Para as sondagens de verificação de integridade, é necessário criar uma regra de firewall de permissão de entrada que permita que as sondagens de verificação de integridade alcancem as instâncias de back-end. Normalmente, as sondagens de verificação de integridade são originadas do mecanismo centralizado de verificação de integridade do Google.

Os balanceadores de carga de aplicativo externos regionais que usam back-ends de NEG híbridos são uma exceção a essa regra, porque as verificações de integridade são originadas da sub-rede somente proxy. Para mais detalhes, consulte a Visão geral de NEGs híbridos.

Protocolo de verificação de integridade

Embora não seja obrigatório e nem sempre possível, é recomendável usar uma verificação de integridade que tenha um protocolo que corresponda ao protocolo do 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. Por outro lado, os balanceadores de carga de aplicativo externos regionais que usam back-ends de NEG híbridos não são compatíveis com verificações de integridade do gRPC. Para ver a lista de protocolos de verificação de integridade compatíveis, consulte Recursos de balanceamento de carga.

A tabela a seguir especifica o escopo das verificações de integridade compatíveis com balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Tipo de verificação de integridade
Balanceador de carga de aplicativo externo global	Global
Balanceador de carga de aplicativo clássico	Global
Balanceador de carga de aplicativo externo regional	Regional

Para saber mais sobre verificações de integridade, consulte:

• Visão geral das verificações de integridade
• Como criar verificações de integridade

Regras de firewall

O balanceador de carga requer as seguintes regras de firewall:

• Para os balanceadores de carga de aplicativo externos globais, uma regra de permissão de entrada para permitir que o tráfego dos Google Front Ends (GFEs) alcance os back-ends.
  Para o balanceador de carga de aplicativo externo regional, uma regra de permissão de entrada para permitir que o tráfego da sub-rede somente proxy alcance seus back-ends.
• Uma regra de permissão de entrada para permitir o tráfego dos intervalos de verificação de integridade Saiba mais sobre sondagens de verificação de integridade e por que é necessário permitir tráfego delas em Intervalos de IP de sondagem e regras de firewall.

As regras de firewall são implementadas no nível da instância de VM, não nos proxies do GFE. Não é possível usar regras de firewall do Google Cloud para impedir que o tráfego chegue ao balanceador de carga. Para o balanceador de carga de aplicativo externo global e o balanceador de carga de aplicativo clássico, use o Google Cloud Armor para fazer isso.

As portas dessas regras de firewall precisam ser configuradas da seguinte maneira:

• Permite o tráfego para a porta de destino da verificação de integridade de cada serviço de back-end.

• Para back-ends de grupos de instâncias: determine as portas a serem configuradas pelo mapeamento entre a porta nomeada do serviço de back-end e os números de porta associados a essa porta nomeada em cada grupo de instâncias. Os números podem variar entre os grupos de instâncias atribuídos ao mesmo serviço de back-end.

• Para back-ends NEG de GCE_VM_IP_PORT: permite tráfego para os números de portas dos endpoints.

A tabela a seguir resume os intervalos de endereços IP de origem obrigatórios para as regras de firewall:

Modo balanceador de carga	Intervalos de origem da verificação de integridade	Solicitar intervalos de origem
Balanceador de carga de aplicativo externo global	35.191.0.0/16 130.211.0.0/22 Para tráfego IPv6 para os back-ends: 2600:2d00:1:b029::/64	A origem do tráfego do GFE depende do tipo de back-end: Grupos de instâncias e NEGs zonais (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Para tráfego IPv6 para os back-ends: 2600:2d00:1:1::/64 NEGs de conectividade híbrida (NON_GCP_PRIVATE_IP_PORT): 130.211.0.0/22 35.191.0.0/16 NEGs da Internet (INTERNET_FQDN_PORT e INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEGs e buckets de back-end: a rede de produção do Google processa o roteamento de pacotes.
Balanceador de carga de aplicativo clássico	35.191.0.0/16 130.211.0.0/22	A origem do tráfego do GFE depende do tipo de back-end: Grupos de instâncias, NEGs zonais (GCE_VM_IP_PORT) e NEGs de conectividade híbrida (NON_GCP_PRIVATE_IP_PORT): 35.191.0.0/16 130.211.0.0/22 NEGs da Internet (INTERNET_FQDN_PORT e INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEGs e buckets de back-end: a rede de produção do Google processa o roteamento de pacotes.
Balanceador de carga de aplicativo externo regional	35.191.0.0/16 130.211.0.0/22 Não é necessário colocar intervalos de sondagem de verificação de integridade do Google na lista de permissões para NEGs híbridos. No entanto, se você estiver usando uma combinação de NEGs híbridos e zonais em um único serviço de back-end, será necessário usar lista de permissões dos intervalos de sondagem de verificação de integridade do Google para NEGs zonais.	A sub-rede somente proxy que você configura.

Importante: permita pacotes dos intervalos completos de verificação de integridade. Se a regra de firewall permitir pacotes de apenas um subconjunto dos intervalos, poderão ocorrer falhas na verificação de integridade porque o balanceador de carga não pode se comunicar com os back-ends. Isso gera respostas HTTP 502.

Arquitetura da VPC compartilhada

Os balanceadores de carga de aplicativo externos são compatíveis com redes que usam a VPC compartilhada. A VPC compartilhada permite que as organizações conectem recursos de vários projetos a uma rede VPC comum para comunicarem-se umas com as outras de maneira segura e eficiente usando os endereços IP internos dessa rede. Se você ainda não tiver familiaridade com a VPC compartilhada, leia a visão geral da VPC compartilhada.

Há muitas maneiras de configurar um balanceador de carga de aplicativo externo em uma rede VPC compartilhada. Independentemente do tipo de implantação, todos os componentes do balanceador de carga precisam estar na mesma organização.

Balanceador de carga	Componentes de front-end	Componentes de back-end
Balanceador de carga de aplicativo externo global	Se você estiver usando uma rede VPC compartilhada para seus back-ends, crie a rede necessária no projeto host da VPC compartilhada. O endereço IP externo global, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URL associado precisam ser definidos no mesmo projeto. Esse projeto pode ser o projeto host ou um projeto de serviços.	Você tem estas opções: Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou qualquer outro tipo de back-end compatível) no mesmo projeto de serviço que os componentes de front-end. Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou qualquer outro tipo de back-end compatível) em projetos de serviço. Um único mapa de URL pode referenciar serviços de back-end em diferentes projetos. Esse tipo de implantação é conhecido como referência de serviço entre projetos e está atualmente em versão prévia. Cada serviço de back-end precisa ser definido no mesmo projeto que os back-ends a que ele faz referência. As verificações de integridade associadas aos serviços de back-end precisam ser definidas no mesmo projeto que o serviço de back-end. Os back-ends podem ser parte de uma rede VPC compartilhada do projeto host ou de uma rede VPC independente, ou seja, uma rede VPC não compartilhada no projeto de serviços.
Balanceador de carga de aplicativo clássico	O endereço IP externo global, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URL associado precisam ser definidos no mesmo projeto host ou de serviço dos back-ends.	Um serviço de back-end global precisa ser definido no mesmo projeto host ou de serviço que os back-ends (grupos de instâncias ou NEGs). As verificações de integridade associadas aos serviços de back-end também precisam ser definidas no mesmo projeto que o serviço de back-end.
Balanceador de carga de aplicativo externo regional	Crie a rede e a sub-rede somente proxy necessárias no projeto host da VPC compartilhada. O endereço IP externo regional, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URL associado precisam ser definidos no mesmo projeto. Esse projeto pode ser o projeto host ou de serviços.	Você tem estas opções: Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou qualquer outro tipo de back-end compatível) no mesmo projeto de serviço que os componentes de front-end. Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou quaisquer outros tipos de back-end compatíveis) em quantos projetos de serviço forem necessários. Um único mapa de URL pode referenciar serviços de back-end em diferentes projetos. Esse tipo de implantação é conhecido como referência de serviço entre projetos. Cada serviço de back-end precisa ser definido no mesmo projeto que os back-ends a que ele faz referência. As verificações de integridade associadas aos serviços de back-end também precisam ser definidas no mesmo projeto que o serviço de back-end.

Embora seja possível criar todos os componentes e back-ends de balanceamento de carga no projeto host da VPC compartilhada, esse tipo de implantação não separa as responsabilidades de administração de rede e desenvolvimento de serviços.

Todos os componentes e back-ends do balanceador de carga em um projeto de serviço

O diagrama de arquitetura a seguir mostra uma implantação de VPC compartilhada padrão em que todos os componentes e back-ends do balanceador de carga estão em um projeto de serviço. Todos os balanceadores de carga de aplicativo oferecem suporte a esse tipo de implantação.

Os componentes e os back-ends do balanceador de carga precisam usar a mesma rede VPC.

Balanceador de carga de aplicativo externo regional em rede VPC compartilhada

Back-ends sem servidor em um ambiente de VPC compartilhada

Para um balanceador de carga que usa um back-end NEG sem servidor, o serviço de back-end do Cloud Run ou do Cloud Functions precisa estar no mesmo projeto que o NEG sem servidor.

Além disso, para o balanceador de carga de aplicativo externo regional que aceita referência de serviço entre projetos, o serviço de back-end, o NEG sem servidor e o serviço do Cloud Run precisam estar sempre no mesmo projeto de serviço.

Referência de serviço entre projetos

Nesse modelo, o front-end e o mapa de URL do balanceador de carga estão em um projeto host ou de serviço. Os serviços e back-ends de balanceador de carga podem ser distribuídos entre projetos no ambiente de VPC compartilhada. Os serviços de back-end entre projetos podem ser referenciados em um mapa de URL. Isso é chamado de referência de serviço entre projetos.

A referência de serviços entre projetos permite que as organizações configurem um balanceador de carga central e direcionem o tráfego para centenas de serviços distribuídos em vários projetos diferentes. É possível gerenciar de maneira centralizada todas as regras e políticas de roteamento de tráfego em um mapa de URL. Também é possível associar o balanceador de carga a um único conjunto de nomes de host e certificados SSL. Portanto, é possível otimizar o número de balanceadores de carga necessários para implantar o aplicativo e reduzir os gerenciamentos, os custos operacionais e os requisitos de cota.

Com projetos diferentes para cada uma das equipes funcionais, também é possível alcançar a separação de papéis dentro da organização. Os proprietários de serviço podem se concentrar na criação de serviços em projetos de serviço, enquanto as equipes de rede podem provisionar e manter os balanceadores de carga em outro projeto. Ambos podem ser conectados por referência de serviço entre projetos.

Os proprietários de serviços podem manter a autonomia sobre a exposição dos próprios serviços e controlar quais usuários podem acessá-los pelo balanceador de carga. Isso é alcançado por um papel especial do IAM chamado função do usuário dos serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser).

Saiba como configurar a VPC compartilhada para um balanceador de carga de aplicativo externo regional, com ou sem a referência de serviço entre projetos, em Configurar um balanceador de carga de aplicativo externo regional com a VPC compartilhada.

Limitações conhecidas com referência a serviços entre projetos

• A referência de serviço entre projetos pode ser usada com grupos de instâncias, NEGs sem servidor e a maioria dos outros tipos de back-ends compatíveis. No entanto, as seguintes limitações se aplicam:

  • Com os balanceadores de carga de aplicativo globais externos, não será possível referenciar um serviço de back-end entre projetos se ele tiver os seguintes back-ends:

    • Buckets de back-end
    • NEGs sem servidor com o App Engine
    • NEGs globais da Internet
  • Com balanceadores de carga de aplicativo externos regionais, não é possível referenciar um serviço de back-end entre projetos se o serviço de back-end tiver back-ends NEG da Internet regionais.
• A referência de serviço entre projetos não é compatível com o balanceador de carga de aplicativo clássico.
• O Google Cloud não diferencia recursos (por exemplo, serviços de back-end) usando o mesmo nome em vários projetos. Portanto, ao usar a referência de serviços entre projetos, recomendamos o uso de nomes exclusivos de serviço de back-end em todos os projetos da organização.

Exemplo 1: front-end e back-end do balanceador de carga em projetos de serviço diferentes

Veja um exemplo de uma implantação em que o mapa de URL e o front-end do balanceador de carga são criados no projeto de serviço A e o mapa de URL faz referência a um serviço de back-end no projeto de serviço B.

Nesse caso, os administradores de rede ou administradores do balanceador de carga no projeto de serviço A precisarão de acesso aos serviços de back-end no projeto de serviço B. Os administradores do projeto de serviço B concedem o papel compute.loadBalancerServiceUser do IAM aos administradores do balanceador de carga no projeto de serviço A que querem referenciar o serviço de back-end no projeto de serviço B.

Front-end e balanceador de carga do balanceador de carga em projetos de serviço diferentes

Exemplo 2: front-end do balanceador de carga no projeto host e back-ends em projetos de serviço

Nesse tipo de implantação, o front-end e o mapa de URL do balanceador de carga são criados no projeto host, e os serviços de back-end (e back-ends) são criados em projetos de serviço.

Nesse caso, os administradores de rede ou de balanceador de carga no projeto host precisarão de acesso aos serviços de back-end nos projetos de serviço. Os administradores do projeto de serviço concedem o papel compute.loadBalancerServiceUser do IAM aos administradores do balanceador de carga no projeto host A que querem referenciar o serviço de back-end no projeto de serviço.

Front-end do balanceador de carga e mapa de URL no projeto host

Como funcionam as conexões

Conexões do balanceador de carga de aplicativo externo global

Os balanceadores de carga de aplicativo externos globais são implementados 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 é divulgado a partir de vários pontos de presença, e as solicitações do cliente são direcionadas 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.

Observação: para NEGs da Internet, as solicitações do balanceador de carga vêm de diferentes intervalos de IP, dependendo do tipo de NEG (global ou regional). Para mais informações, consulte Como autenticar solicitações.

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. Para conexões HTTP ou HTTPS, a versão HTTP usada é HTTP 1.1.

O sinal de atividade HTTP está ativado por padrão, conforme a especificação HTTP 1.1. Os sinais de atividade HTTP tentam usar de forma eficiente a mesma sessão TCP. No entanto, não há garantias. O GFE usa um tempo limite do sinal de atividade HTTP do cliente de 610 segundos e um valor padrão do tempo limite de sinal de atividade do back-end de 600 segundos. É possível atualizar o tempo limite do sinal de atividade HTTP do cliente, mas o valor do tempo limite do sinal de atividade do back-end é fixo. É possível configurar o tempo limite da solicitação/resposta definindo o tempo limite do serviço de back-end. Embora esteja estreitamente relacionado, um sinal de atividade HTTP e um sinal de inatividade TCP não são a mesma coisa. Saiba mais em Tempos limite e novas tentativas.

Para garantir que o tráfego tenha a carga balanceada uniformemente, o balanceador de carga pode fechar uma conexão TCP enviando um pacote FIN ACK depois de concluir uma resposta que inclui um cabeçalho Connection: close ou pode emitir um frame HTTP/2 GOAWAY depois de concluir uma resposta. Esse comportamento não interfere em solicitações ou respostas ativas.

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.

Para mais informações, consulte Como funcionam os balanceadores de carga de aplicativo externos no guia de soluções: otimizações de capacidade de aplicativos com balanceamento de carga global.

Conexões externas regionais do balanceador de carga de aplicativo

O balanceador de carga de aplicativo externo regional é um serviço gerenciado implementado no proxy Envoy. O balanceador de carga de aplicativo externo regional usa uma sub-rede compartilhada chamada sub-rede apenas de proxy para provisionar um conjunto de endereços IP que o Google usa para executar proxies Envoy em seu nome. A sinalização --purpose dessa sub-rede somente proxy está definida como REGIONAL_MANAGED_PROXY. Todos os balanceadores de carga regionais baseados no Envoy em uma rede e região específicas compartilham essa sub-rede.

Os clientes usam o endereço IP e a porta do balanceador de carga para se conectar ao balanceador de carga. As solicitações do cliente são direcionadas para a sub-rede somente proxy na mesma região do cliente. O balanceador de carga encerra solicitações de clientes e depois abre novas conexões da sub-rede somente proxy para os back-ends. Portanto, os pacotes enviados do balanceador de carga têm endereços IP de origem da sub-rede somente proxy.

Dependendo da configuração do serviço de back-end, o protocolo usado por cada Envoy 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 proxy Envoy define o tempo limite do sinal de atividade HTTP do cliente e o tempo limite do sinal de atividade do back-end como um valor padrão de 600 segundos cada. É possível atualizar o tempo limite do sinal de atividade HTTP do cliente, mas o valor do tempo limite do sinal de atividade do back-end é fixo. É 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.

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 de aplicativo externos são compatíveis com a resposta HTTP/1.1 100 Continue.

Confira a lista completa de protocolos compatíveis com as regras de encaminhamento do balanceador de carga de aplicativo em cada modo em Recursos do balanceador de carga.

Endereços IP de origem para pacotes de clientes

O endereço IP de origem dos pacotes, como visto pelos back-ends, não é o endereço IP externo do Google Cloud do balanceador de carga. Em outras palavras, há duas conexões TCP:

Para os balanceadores de carga de aplicativo externos globais:

• Conexã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 atrás de NAT ou de um proxy de encaminhamento).
  • Endereço IP de destino: o endereço IP do seu balanceador de carga.

• Conexão 2, do balanceador de carga (GFE) para o endpoint ou VM de back-end:

  • Endereço IP de origem: um endereço IP em um dos intervalos especificados nas regras de firewall.

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

Observação: para NEGs da Internet, as solicitações do balanceador de carga vêm de diferentes intervalos de IP. Para mais informações, consulte Como autenticar solicitações.

Para os balanceadores de carga regionais de aplicativos externos:

• Conexão 1, do cliente original para o balanceador de carga (sub-rede somente proxy):

  • Endereço IP de origem: o cliente original (ou endereço IP externo se o cliente estiver atrás de NAT ou de um proxy de encaminhamento).
  • Endereço IP de destino: o endereço IP do seu balanceador de carga.

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

  • Endereço IP de origem: um endereço IP na sub-rede somente proxy compartilhado entre todos os balanceadores de carga baseados em Envoy implantados na mesma região e rede como o balanceador de carga.

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

Caminho de retorno

Para os balanceadores de carga de aplicativo externos globais, o Google Cloud usa rotas especiais não definidas na rede VPC para verificações de integridade. Saiba mais em Caminhos de retorno do balanceador de carga.

Para balanceadores de carga de aplicativo externos regionais, o Google Cloud usa proxies Envoy de código aberto para encerrar solicitações de clientes ao balanceador de carga. O balanceador de carga encerra a sessão TCP e abre uma nova sessão da sub-rede somente proxy da região para o back-end. As rotas definidas na sua rede VPC facilitam a comunicação dos proxies Envoy para seus back-ends e vice-versa.

Portas abertas

Os GFEs têm várias portas abertas para oferecer suporte a outros serviços do Google, executados na mesma arquitetura. Ao executar uma verificação de portas, é possível ver outras portas abertas para outros serviços do Google em execução nos GFEs.

Os balanceadores de carga baseados no GFE (balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo clássicos) sempre mostram as portas 80 e 443 como abertas (com qualquer outra porta que você tenha configurado nas regras de encaminhamento do balanceador de carga). No entanto, se você não tiver configurado uma regra de encaminhamento para a porta 80 ou 443, todas as conexões enviadas para essas portas serão recusadas. Por outro lado, os balanceadores de carga de aplicativo externos regionais são implementados usando proxies Envoy e não mostram portas abertas extras durante uma verificação.

Executar uma verificação de porta no endereço IP de um balanceador de carga baseado no GFE não é útil do ponto de vista de auditoria pelos seguintes motivos:

• Uma verificação de porta (por exemplo, com nmap) geralmente não espera nenhum pacote de resposta ou um pacote TCP RST ao realizar a sondagem de TCP SYN. Os GFEs enviarão pacotes SYN-ACK em resposta a sondagens SYN apenas para portas em que você configurou uma regra de encaminhamento. Os GFEs só enviam pacotes para os back-ends em resposta aos enviados para o endereço IP do balanceador de carga e para a porta de destino configurada na regra de encaminhamento. Os pacotes enviados para um endereço IP ou uma porta diferente não são enviados para os back-ends.

  Os GFEs implementam recursos de segurança, como o Google Cloud Armor. Com o Google Cloud Armor Standard, os GFEs oferecem proteção sempre ativada contra ataques DDoS volumétricos e baseados em protocolo e inundações de SYN. Essa proteção está disponível mesmo que você não tenha configurado explicitamente o Google Cloud Armor. Você só vai receber cobranças se configurar políticas de segurança ou se se inscrever no Managed Protection Plus.

• Os pacotes enviados para o endereço IP do balanceador de carga poderiam ser respondidos por qualquer GFE na frota do Google; No entanto, a verificação de uma combinação de endereço IP e porta de balanceador de carga interroga apenas um único GFE por conexão TCP. O endereço IP do seu balanceador de carga não é atribuído a um único dispositivo ou sistema. Portanto, a verificação do endereço IP de um balanceador de carga baseado em GFE não verifica todos os GFEs na frota do Google.

Com isso em mente, veja a seguir algumas maneiras mais eficazes de auditar a segurança das instâncias de back-end:

• Um auditor de segurança precisa inspecionar a configuração das regras de encaminhamento para a configuração do balanceador de carga. As regras de encaminhamento definem a porta de destino para a qual o balanceador de carga aceita pacotes e os encaminha para os back-ends. Para balanceadores de carga baseados em GFE, cada regra de encaminhamento externo só pode referenciar uma única porta TCP de destino. Para um balanceador de carga que usa a porta TCP 443, a porta UDP 443 é usada quando a conexão recebe upgrade para QUIC (HTTP/3).

• Um auditor de segurança deve inspecionar a configuração da regra de firewall aplicável às VMs de back-end. As regras de firewall definidas bloqueiam o tráfego dos GFEs para as VMs de back-end, mas não bloqueiam o tráfego de entrada para os GFEs. Para ver as práticas recomendadas, consulte a seção de regras de firewall.

término de TLS

A tabela a seguir resume como a terminação TLS é processada pelos balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	término de TLS
Balanceador de carga de aplicativo externo global	O TLS é encerrado em um GFE, que pode estar em qualquer lugar do mundo.
Balanceador de carga de aplicativo clássico	O TLS é encerrado em um GFE, que pode estar em qualquer lugar do mundo.
Balanceador de carga de aplicativo externo regional	O TLS é encerrado nos proxies do Envoy localizados em uma sub-rede apenas de proxy em uma região escolhida pelo usuário. Use esse modo de balanceador de carga se você precisar de controle geográfico sobre a região em que o TLS é encerrado.

Tempo limite e tentativas

Os balanceadores de carga de aplicativo externos são compatíveis com os seguintes tipos de tempo limite:

Tipo e descrição de tempo limite	Valores padrão	Compatível com valores personalizados
		Global	Clássico	Regional
Tempo limite do serviço de back-end^1 Tempo limite de solicitação e resposta. Representa o tempo máximo que pode decorrer entre o momento em que o balanceador de carga envia o primeiro byte da solicitação HTTP para o back-end e o momento em que ele retorna o último byte da resposta HTTP. Se toda a resposta HTTP não for retornada ao balanceador de carga dentro do tempo limite de solicitação ou resposta, os dados de resposta restantes serão descartados. Para WebSockets usados com balanceadores de carga de aplicativo clássicos, a duração máxima do WebSocket, seja inativo ou ativo.	Para NEGs sem servidor em um serviço de back-end: 60 minutos Para todos os outros tipos de back-end em um serviço de back-end: 30 segundos Para buckets de back-end: 24 horas (86.400 segundos)	^2		^2
Tempo limite do sinal de atividade HTTP do cliente O tempo máximo que a conexão TCP entre um cliente e o proxy do balanceador de carga pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP. Para os balanceadores de carga de aplicativo externos globais e clássicos, o proxy do balanceador de carga é um GFE de primeira camada. Para balanceadores de carga de aplicativo externos regionais, o proxy do balanceador de carga é o software Envoy.	Para um balanceador de carga de aplicativo externo global e um balanceador de carga de aplicativo clássico: 610 segundos Para um balanceador de carga de aplicativo externo regional: 600 segundos
Tempo limite do sinal de atividade HTTP de back-end O tempo máximo que a conexão TCP entre o proxy do balanceador de carga e um back-end pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP. Para os balanceadores de carga de aplicativo externos globais e clássicos, o proxy do balanceador de carga é um GFE de segunda camada. Para balanceadores de carga de aplicativo externos regionais, o proxy do balanceador de carga é o software Envoy.	Para serviços de back-end: 10 minutos (600 segundos) Para buckets de back-end: 6 minutos (360 segundos)
Tempo limite de inatividade da sessão QUIC O tempo máximo que uma sessão QUIC pode ficar inativa entre o cliente (downstream) e o GFE de um balanceador de carga de aplicativo externo global e um balanceador de carga de aplicativo clássico.	Para balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo clássicos: O tempo limite de inatividade da sessão QUIC é o mínimo de um destes: tempo limite de inatividade do cliente ou tempo limite de inatividade do GFE (300 segundos). O tempo limite de inatividade do GFE é fixo em 300 segundos. O tempo limite de inatividade do cliente pode ser configurado.

¹Não configurável para back-ends de NEG sem servidor. Não é configurável para buckets de back-end.

²O suporte à configuração não é aplicável a WebSockets.

Tempo limite do serviço de back-end

O tempo limite do serviço de back-end configurável representa o tempo máximo que o balanceador de carga aguarda até o back-end processar uma solicitação HTTP e retornar a resposta HTTP correspondente. Exceto para NEGs sem servidor, o valor padrão do tempo limite do serviço de back-end é de 30 segundos.

Por exemplo, se você quiser fazer o download de um arquivo de 500 MB e o valor do tempo limite do serviço de back-end for de 90 segundos, o balanceador de carga aguardará o back-end enviar todo o arquivo de 500 MB em até 90 segundos. É possível configurar o tempo limite do serviço de back-end como insuficiente para que o back-end envie a resposta HTTP completa. Nessa situação, se o balanceador de carga tiver recebido do back-end pelo menos os cabeçalhos de resposta HTTP, ele retornará os cabeçalhos completos e o máximo possível do corpo de resposta dentro do tempo limite do serviço de back-end.

Exceto para WebSockets, defina o tempo limite do serviço de back-end como o período mais longo que você espera ser necessário para o back-end processar uma resposta HTTP. Aumente o tempo limite do serviço de back-end se o software em execução no back-end precisar de mais tempo para processar uma solicitação HTTP e retornar toda a resposta. Por exemplo, aumente o tempo limite se você receber respostas HTTP 408 com jsonPayload.statusDetail client_timed_out.

O tempo limite do serviço de back-end aceita valores entre 1 e 2,147,483,647 segundos. Valores maiores não são opções de configuração possíveis. O Google Cloud não garante que uma conexão TCP subjacente possa permanecer aberta durante todo o valor do tempo limite do serviço de back-end. Os sistemas clientes precisam implementar a lógica de nova tentativa em vez de depender que uma conexão TCP permaneça aberta por períodos longos.

Outras observações:

• O tempo limite da conexão WebSocket depende do tipo de balanceador de carga:

  • Para os balanceadores de carga de aplicativo clássicos, 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 é de 30 segundos por padrão. Esse tempo limite se aplica a conexões WebSocket, estando em uso ou não.
  • Para balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo externos regionais, as conexões WebSocket ativas não seguem o tempo limite do serviço de back-end. As conexões WebSocket inativas são fechadas após o tempo limite do serviço de back-end.
  • Além disso, as conexões WebSocket usadas por balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo clássicos são fechadas automaticamente após 24 horas. Esse limite de 24 horas não é personalizável e ocorre independentemente de as conexões estarem em uso ou se o valor de tempo limite do serviço de back-end estiver definido como um valor maior que 86.400 segundos (24 horas).

• Para um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico, os valores de tempo limite do serviço de back-end maiores que um dia (86.400 segundos) não são recomendados porque o Google Cloud reinicia periodicamente os front-ends do Google para atualizações de software e outras manutenções de rotina. O valor de tempo limite do serviço de back-end não atrasa as atividades de manutenção do Google. Quanto maior for o valor de tempo limite do serviço de back-end, maior será a probabilidade de o Google encerrar as conexões TCP para manutenção.

• Para um balanceador de carga de aplicativo externo regional, o Google Cloud reinicia periodicamente ou altera o número de tarefas de software do Envoy em exibição. Quanto maior o valor do tempo limite do serviço de back-end, maiores as chances de conexões TCP serem encerradas por reiniciações ou substituições de tarefas do Envoy.

Os balanceadores de carga regionais de aplicativos externos aceitam um parâmetro de mapa de URL routeActions.timeout, que pode modificar o tempo limite do serviço de back-end. Quando routeActions.timeout é omitido, o valor do tempo limite do serviço de back-end é usado. Quando routeActions.timeout é fornecido, o tempo limite do serviço de back-end é ignorado, e o valor de routeActions.timeout é usado como o tempo limite de solicitação e resposta.

Para configurar o tempo limite do serviço de back-end, use um dos seguintes métodos:

• Console do Google Cloud: modifique o campo Tempo limite do serviço de back-end do balanceador de carga.
• Google Cloud CLI: use o comando gcloud compute backend-services update para modificar o parâmetro --timeout do recurso de serviço de back-end.
• API: para um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico, modifique o parâmetro timeoutSec para o recurso backendServices global.
• API: para um balanceador de carga de aplicativo externo regional, modifique o parâmetro timeoutSec para o recurso regionBackendServices.

Tempo limite do sinal de atividade HTTP do cliente

O tempo limite do sinal de atividade HTTP do cliente representa a quantidade máxima de tempo que uma conexão TCP pode ficar ociosa entre o cliente (downstream) e um dos seguintes tipos de proxies:

• Para um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico: um front-end do Google de primeira camada
• Para um balanceador de carga de aplicativo externo regional: um proxy Envoy

Um tempo limite de sinal de atividade HTTP representa o tempo limite de inatividade TCP das conexões TCP subjacentes. O tempo limite de sinal de atividade HTTP do cliente não se aplica aos WebSockets.

• Para um balanceador de carga de aplicativo externo global, o valor padrão é de 610 segundos. É possível configurar o tempo limite do sinal de atividade HTTP do cliente com um valor entre 5 e 1.200 segundos.
• Para um balanceador de carga de aplicativo clássico, o tempo limite do sinal de atividade HTTP do cliente é fixo em 610 segundos.
• Para um balanceador de carga de aplicativo externo regional, o tempo limite do sinal de atividade HTTP do cliente é fixo em 600 segundos.

Para configurar o parâmetro de tempo limite do sinal de atividade, use um dos seguintes métodos:

• Console do Google Cloud: modifique o campo Tempo limite do sinal de atividade HTTP da configuração de front-end do balanceador de carga.
• Google Cloud CLI: use o comando gcloud compute target-http-proxies update ou o comando gcloud compute target-https-proxies update para modificar o parâmetro --http-keep-alive-timeout-sec do proxy HTTP de destino ou do recurso de proxy HTTPS de destino.
• API: modifique o parâmetro httpKeepAliveTimeoutSec para o recurso targetHttpProxies ou recurso targetHttpsProxies.

O tempo limite do sinal de atividade do cliente HTTP do balanceador de carga precisa ser maior que o tempo limite do sinal de atividade HTTP (TCP inativo) usado por clientes downstream ou proxies. Se um cliente downstream tiver o tempo limite do sinal de atividade HTTP (TCP inativo) maior do que o tempo limite do sinal de atividade HTTP do cliente do balanceador de carga, ocorrerá uma possível disputa. Da perspectiva de um cliente downstream, uma conexão TCP estabelecida pode ficar inativa por mais tempo do que o balanceador de carga permite. Isso significa que o cliente downstream pode enviar pacotes depois que o balanceador de carga considerar a conexão TCP encerrada. Quando isso acontece, o balanceador de carga responde com um pacote de redefinição (RST) TCP.

Tempo limite do sinal de atividade HTTP do back-end

Os balanceadores de carga de aplicativo externos são proxies que usam pelo menos duas conexões TCP:

• Para um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico, há uma primeira conexão TCP entre o cliente (downstream) e um GFE de primeira camada. Os GFEs de primeira camada se conectam a GFEs de segunda camada e, em seguida, os GFEs de segunda camada abrem uma segunda conexão TCP com os back-ends.

• Para um balanceador de carga de aplicativo externo regional, há uma primeira conexão TCP entre o cliente (downstream) e um proxy Envoy. Em seguida, o proxy Envoy abre uma segunda conexão TCP com os back-ends.

As conexões TCP secundárias do balanceador de carga talvez não sejam encerradas após cada solicitação. Elas podem permanecer abertas para lidar com várias solicitações e respostas HTTP. O tempo limite do sinal de atividade HTTP do back-end define o tempo limite de inatividade do TCP entre o balanceador de carga e os back-ends. O tempo limite do sinal de atividade HTTP de back-end não se aplica a WebSockets.

O tempo limite do sinal de atividade do back-end é fixado em 10 minutos (600 segundos) e não pode ser alterado. O tempo limite do sinal de atividade do back-end do balanceador de carga precisa ser menor que o tempo limite do sinal de atividade usado pelo software em execução nos back-ends. Isso evita uma disputa em que o sistema operacional dos back-ends pode encerrar conexões TCP com uma redefinição (RST) TCP. Como o tempo limite do sinal de atividade do back-end do balanceador de carga não é configurável, é necessário configurar o software do back-end para que o valor de tempo limite do sinal de atividade HTTP (TCP inativo) seja maior que 600 segundos.

A tabela a seguir lista as alterações necessárias para modificar os valores de tempo limite do sinal de atividade para software servidor da Web comum.

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;

Tempo limite de inatividade da sessão QUIC

O tempo limite de inatividade da sessão QUIC representa o tempo máximo que essa sessão pode ficar inativa entre o cliente e o GFE de um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico.

O valor do tempo limite de inatividade da sessão QUIC é definido como o mínimo de um destes: tempo limite de inatividade do cliente ou tempo limite de inatividade do cliente do GFE (300 segundos). O tempo limite de inatividade do GFE é fixo em 300 segundos. O tempo limite de inatividade do cliente pode ser configurado.

Novas tentativas

A compatibilidade com a lógica de repetição depende do modo do balanceador de carga de aplicativo externo.

Modo balanceador de carga	Repetir lógica
Balanceador de carga de aplicativo externo global	Configurável usando uma política de repetição no mapa de URL. O número padrão de novas tentativas (numRetries) é 1. O número máximo de novas tentativas que pode ser configurado usando a política é 25. O tempo limite padrão de cada tentativa (perTryTimeout) é de 30 segundos, com um perTryTimeout configurável máximo de 24 horas. Sem uma política de nova tentativa, solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações GET) que resultarem em respostas HTTP 502, 503 ou 504 (retryConditions=["gateway-error"]) serão repetidas uma vez. As solicitações HTTP POST não são repetidas. As solicitações repetidas geram apenas uma entrada de registro como resposta final.
Balanceador de carga de aplicativo clássico	Não é possível alterar a política de novas tentativas de conexão. As solicitações HTTP POST não são repetidas. As solicitações HTTP GET são sempre repetidas uma vez, desde que 80% ou mais dos back-ends estejam íntegros. Se houver uma única instância de back-end em um grupo e a conexão com essa instância falhar, a porcentagem de instâncias de back-end não íntegras será 100%. Por isso, o GFE não tentará repetir a solicitação. O balanceador de carga repetirá uma solicitação GET com falha se a primeira solicitação falhar antes de receber cabeçalhos de resposta da instância de back-end. As solicitações repetidas geram apenas uma entrada de registro como resposta final. Para mais informações, consulte Geração de registros e monitoramento do balanceador de carga de aplicativo externo. Solicitações malsucedidas resultam em um balanceador de carga sintetizando uma resposta HTTP 502.
Balanceador de carga de aplicativo externo regional	Configurável usando uma política de nova tentativa no mapa de URL. O número padrão de novas tentativas (numRetries) é 1. O número máximo de novas tentativas que pode ser configurado usando a política é 25. O tempo limite padrão de cada tentativa (perTryTimeout) é de 30 segundos, com um perTryTimeout configurável máximo de 24 horas. Sem uma política de nova tentativa, solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações GET) que resultarem em respostas HTTP 502, 503 ou 504 serão repetidas uma vez. As solicitações HTTP POST não são repetidas. As solicitações repetidas geram apenas uma entrada de registro como resposta final.

O protocolo WebSocket é suportado pela Entrada do GKE.

Tratamento de solicitações e respostas inválidas

O balanceador de carga bloqueia a chegada de solicitações de cliente e respostas de back-end no back-end ou no cliente, respectivamente, por alguns 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 conformidade 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 URL de solicitação excede o limite de tamanho máximo de cabeçalhos de solicitação para balanceadores de carga de aplicativo externos.
• 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 balanceadores de carga de aplicativo externos.
• A versão do HTTP é desconhecida.

Distribuição de tráfego

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. Os balanceadores de carga de aplicativo externos são compatíveis 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.

A distribuição do tráfego entre back-ends depende do modo do balanceador de carga.

Balanceador de carga de aplicativo externo global

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.

Para o balanceador de carga de aplicativo externo global, o balanceamento de carga é de duas camadas. O modo de balanceamento determina a ponderação ou fração de tráfego que precisa ser enviada para cada back-end (grupo de instâncias ou NEG). Em seguida, a política de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído para as instâncias ou endpoints no grupo. Para mais informações, consulte a política de localidade de balanceamento de carga (documentação da API Backend Service).

Para o balanceador de carga clássico do aplicativo, o modo de balanceamento é usado para selecionar o back-end mais favorável (grupo de instâncias ou NEG). O tráfego é distribuído em estilo round-robin entre instâncias ou endpoints no back-end.

Como as solicitações são distribuídas

Balanceadores de carga de aplicativo externos baseados no GFE usam o seguinte processo para distribuir solicitações recebidas:

1. Do cliente para o GFE de primeira camada. Os roteadores de borda divulgam o endereço IP externo da regra de encaminhamento nas bordas da rede do Google. Cada divulgação lista um próximo salto para um sistema de balanceamento de carga de camada 3/4 (Maglev). Os sistemas Maglev encaminham o tráfego para o Google Front End (GFE) de primeira camada.
   • Ao usar o nível Premium, o Google divulga o endereço IP do seu balanceador de carga de todos os pontos de presença em todo o mundo. Cada endereço IP do balanceador de carga é anycast global.
   • Ao usar o nível Standard, o Google divulga o endereço IP do balanceador de carga de pontos de presença associados à região da regra de encaminhamento. O balanceador de carga usa um endereço IP externo regional. Ao usar uma regra de encaminhamento de nível Standard, você se limita a grupo de instâncias e back-ends de NEG zonal na mesma região da regra de encaminhamento do balanceador de carga.
2. Do GFE de primeira camada para o GFE de segunda camada. O GFE de primeira camada encerra o TLS, se necessário, e depois encaminha o tráfego para os GFEs de segunda camada de acordo com este processo:
   • Os GFEs de primeira camada analisam o mapa de URLs e selecionam um serviço ou bucket de back-end.
   • Para serviços de back-end com NEGs da Internet, os GFEs de primeira camada selecionam um gateway de encaminhamento externo de segunda camada que está em colocation com o GFE de primeira camada. O gateway de encaminhamento envia solicitações para o endpoint do NEG na Internet. Isso conclui o processo de distribuição de solicitações para NEGs da Internet.
   • Para serviços de back-end com NEGs sem servidor, NEGs do Private Service Connect (PSC) e buckets de back-end, os GFEs de primeira camada selecionam um GFE de segunda camada na região correspondente àquela do NEG ou bucket. Para buckets multirregionais do Cloud Storage, os GFEs de primeira camada selecionam GFEs de segunda camada na região mais próxima possível dos GFEs de primeira camada (definido pelo tempo de retorno da rede).
   • Para serviços de back-end com grupos de instâncias, NEGs zonais com endpoints GCE_VM_IP_PORT e NEGs híbridos, o sistema de gerenciamento de capacidade do Google informa aos GFEs de primeira camada a capacidade usada e configurada de cada back-end. A capacidade configurada de um back-end é definida pelo modo de balanceamento, a capacidade desejada do modo de balanceamento e o escalonador de capacidade.
     • Nível Standard: os GFEs de primeira camada selecionam um GFE de segunda camada na região que contém os back-ends.
     • Nível Premium: os GFEs de primeira camada selecionam GFEs de segunda camada de um conjunto de regiões aplicáveis. As regiões aplicáveis são todas aquelas em que os back-ends foram configurados, exceto as regiões com back-ends configurados com capacidade zero. Os GFEs de primeira camada selecionam o GFE de segunda camada mais próximo em uma região aplicável (definido pelo tempo de retorno da rede). Se os back-ends estiverem configurados em duas ou mais regiões, os GFEs de primeira camada poderão distribuir solicitações para outras regiões aplicáveis se uma região de primeira escolha estiver cheia. A distribuição para outras regiões é possível quando todos os back-ends na região de primeira escolha estão no limite da capacidade.
3. Os GFEs de segunda camada selecionam back-ends. Os GFEs de segunda camada estão localizados em zonas de uma região. Eles usam o seguinte processo para selecionar um back-end:
   • Para serviços de back-end com NEGs sem servidor, NEGs do Private Service Connect e buckets de back-end, os GFEs de segunda camada encaminham solicitações para os sistemas de produção do Google. Isso conclui o processo de distribuição de solicitações para esses back-ends.

   • Para serviços de back-end com grupos de instâncias, NEGs zonais com endpoints GCE_VM_IP_PORT e NEGs híbridos, os sistemas de sondagem de verificação de integridade do Google informam aos GFEs de segunda camada sobre o status da verificação de integridade dos endpoints ou das instâncias de back-end.

     Somente nível Premium: se o GFE de segunda camada não tiver endpoints ou instâncias de back-end íntegros na região, ele poderá enviar solicitações para outro GFE de segunda camada em uma região aplicável diferente com back-ends configurados. A distribuição entre GFEs de segunda camada em diferentes regiões não esgota todas as combinações possíveis entre regiões. Se você precisar direcionar o tráfego para longe dos back-ends em uma região específica, em vez de configurar os back-ends para que falhem nas verificações de integridade, defina o escalonador de capacidade do back-end como zero para que o GFE de primeira camada exclua a região durante a etapa anterior.

   Em seguida, o GFE de segunda camada direciona as solicitações para endpoints ou instâncias de back-end em zonas dentro da região dele, conforme discutido na próxima etapa.

4. O GFE de segunda camada seleciona uma zona. Por padrão, os GFEs de segunda camada usam o algoritmo WATERFALL_BY_REGION, em que cada GFE de segunda camada prefere selecionar endpoints ou instâncias de back-end na mesma zona que contém o GFE de segunda camada. Como WATERFALL_BY_REGION minimiza o tráfego entre zonas, com baixas taxas de solicitação, cada GFE de segunda camada pode enviar solicitações exclusivamente para back-ends na mesma zona que o próprio GFE de segunda camada.

   Somente para balanceadores de carga de aplicativo globais externos, os GFEs de segunda camada podem ser configurados para que usem um dos seguintes algoritmos alternativos com um serviceLbPolicy:

   • SPRAY_TO_REGION: os GFEs de segunda camada não preferem selecionar endpoints ou instâncias de back-end na mesma zona que o GFE de segunda camada. Os GFEs de segunda camada tentam distribuir o tráfego para todos os endpoints ou instâncias de back-end em todas as zonas da região. Isso pode levar a uma distribuição mais uniforme da carga, à custa do aumento do tráfego entre as zonas.
   • WATERFALL_BY_ZONE: os GFEs de segunda camada preferem expressamente selecionar instâncias de back-end ou endpoints na mesma zona que o GFE de segunda camada. Os GFEs de segunda camada só direcionam solicitações para back-ends em zonas diferentes depois que todos os back-ends na zona atual atingirem as capacidades configuradas.
5. O GFE de segunda camada seleciona instâncias ou endpoints dentro da zona. Por padrão, um GFE de segunda camada distribui solicitações entre back-ends de maneira round-robin. Somente para balanceadores de carga de aplicativo externos globais, é possível alterar isso usando uma política de localidade de balanceamento de carga (localityLbPolicy). Essa política se aplica apenas aos back-ends dentro da zona selecionada discutida na etapa anterior.

Balanceador de carga de aplicativo externo regional

Para balanceadores de carga de aplicativo externos regionais, a distribuição de tráfego é baseada no modo de balanceamento de carga e na política de localidade do balanceamento de carga.

O modo de balanceamento determina a ponderação e fração do tráfego que precisa ser enviada para cada back-end (grupo de instâncias ou NEG). A política de localidade do balanceamento de carga (LocalityLbPolicy) determina como os back-ends do grupo são balanceados por carga.

Quando um serviço de back-end recebe tráfego, ele direciona primeiro o tráfego para um back-end (grupo de instâncias ou NEG ) de acordo com o modo de balanceamento do back-end. Depois que um back-end é selecionado, o tráfego é distribuído entre as instâncias ou os endpoints do grupo, de acordo com a política de localidade do balanceamento de carga.

Para ver mais informações, consulte os seguintes tópicos:

• Modos de balanceamento
• Política de localidade do balanceamento de carga (documentação da API de serviço de back-end regional).

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.

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

Os balanceadores de carga de aplicativo externos oferecem os seguintes tipos de afinidade de sessão:

• NONE. A afinidade de sessão não está definida para o balanceador de carga.
• Afinidade de IP do cliente
• Afinidade de cookie gerado
• Afinidade do campo de cabeçalho
• Afinidade de cookie HTTP

A tabela a seguir resume as opções de afinidade de sessão compatíveis com os balanceadores de carga de aplicativo externos em cada modo:

Modo balanceador de carga	Opções de afinidade de sessão
	Nenhum	IP do cliente	Cookie gerado	Campo de cabeçalho	Cookie HTTP
Balanceador de carga de aplicativo externo global
Balanceador de carga de aplicativo clássico
Balanceador de carga de aplicativo externo regional

Suporte a HTTP/2

HTTP/2 é uma revisão importante do protocolo HTTP/1. O HTTP/2 é compatível com conexões entre clientes e o balanceador de carga de aplicativo externo e para conexões entre o balanceador de carga e os back-ends dele.

O balanceador de carga negocia o HTTP/2 com clientes como parte do handshake SSL usando a extensão ALPN TLS. Mesmo que um balanceador de carga esteja configurado para usar HTTPS, os clientes modernos usam HTTP/2 como padrão. Isso é controlado no lado do cliente, não no balanceador de carga.

Se um cliente não oferecer suporte a HTTP/2 e o balanceador de carga estiver configurado para usar HTTP/2 entre o balanceador de carga e as instâncias de back-end, o balanceador de carga ainda poderá negociar uma conexão HTTPS ou aceitar solicitações HTTP não seguras , Essas solicitações HTTPS ou HTTP são transformadas pelo balanceador de carga para fazer proxy das solicitações por HTTP/2 para as instâncias de back-end.

Para usar HTTP/2, ative o TLS nos seus back-ends. Saiba mais em Criptografia do balanceador de carga nos back-ends.

Máximo de streams simultâneos HTTP/2

A configuração HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS descreve o número máximo de streams aceitos por um endpoint, iniciado pelo peer. O valor divulgado por um cliente HTTP/2 para um balanceador de carga do Google Cloud é efetivamente insignificante, porque o balanceador de carga não inicia streams para o cliente.

Nos casos em que o balanceador de carga usa HTTP/2 para se comunicar com um servidor em execução em uma VM, o balanceador de carga respeita o valor SETTINGS_MAX_CONCURRENT_STREAMS anunciado pelo servidor. Se um valor igual a zero for anunciado, o balanceador de carga não poderá encaminhar solicitações para o servidor. Isso poderá gerar erros.

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. Como resultado, talvez você veja altas latências de back-end porque as conexões de back-end são feitas com mais frequência.
• 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 8441).
• 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 Google 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.

Suporte a HTTP/3

O HTTP/3 é um protocolo de Internet de última geração. Ele é baseado no IETF QUIC, um protocolo desenvolvido a partir protocolo Google QUIC original. O HTTP/3 é compatível entre o balanceador de carga de aplicativo externo, o Cloud CDN e os clientes.

A compatibilidade com o Google QUIC (também conhecido como gQUIC) foi removido em abril de 2023 e foi substituído pelo HTTP/3 em vez do IETF QUIC, que é um padrão IETF e tem desempenho melhor que o gQUIC.

Especificamente:

• O IETF QUIC é um protocolo de camada de transporte que oferece controle de congestionamento e confiabilidade semelhantes ao TCP, usa TLS 1.3 para segurança e melhor desempenho.
• O HTTP/3 é uma camada de aplicativo criada com base no IETF QUIC e depende do QUIC para lidar com a multiplexação, o controle de congestionamento, a detecção de perdas e a retransmissão.
• O HTTP/3 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 HTTP/3 é compatível com conexões entre clientes e o balanceador de carga, e não conexões entre o balanceador de carga e os back-ends dele.
• As conexões HTTP/3 usam o algoritmo de controle de congestionamento BBR.

O HTTP/3 no balanceador de carga pode melhorar os tempos de carregamento de páginas da Web, reduzir o armazenamento em buffer de vídeo e melhorar a capacidade em conexões de maior latência.

A tabela a seguir especifica o suporte HTTP/3 para balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Suporte a HTTP/3
Balanceador de carga de aplicativo externo global (sempre nível Premium)
Balanceador de carga de aplicativo clássico no nível Premium
Balanceador de carga de aplicativo clássico no nível Standard
Balanceador de carga de aplicativo externo regional (nível Premium ou Standard)

Como o HTTP/3 é negociado

Quando o HTTP/3 está ativado, o balanceador de carga anuncia essa compatibilidade para os clientes, permitindo que clientes que aceitam HTTP/3 tentem estabelecer conexões HTTP/3 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 HTTP/3.
• Os clientes que aceitam HTTP/3 usam o conhecimento prévio em cache dessa compatibilidade para salvar viagens de ida e volta desnecessárias no futuro.
• Por isso, ativar ou desativar o HTTP/3 no balanceador de carga não afeta a capacidade do balanceador de carga de se conectar com os clientes.

O suporte é divulgado no cabeçalho de resposta HTTP Alt-Svc. Quando o HTTP/3 está ativado, as respostas do balanceador de carga incluem o seguinte valor de cabeçalho alt-svc:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

Observação: o cabeçalho Alt-Svc divulga várias versões do HTTP/3 para permitir rascunhos anteriores usados por alguns clientes (por exemplo, h3-29).

Se o HTTP/3 tiver sido definido explicitamente como DISABLE, as respostas não incluirão um cabeçalho de resposta alt-svc.

Quando o HTTP/3 está ativado no balanceador de carga HTTPS, algumas circunstâncias podem fazer com que o cliente recorra a HTTPS ou HTTP/2 em vez de negociar o HTTP/3. Isso inclui o seguinte:

• quando um cliente aceita versões do HTTP/3 que não são compatíveis com as versões do HTTP/3 compatíveis com o 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 HTTP/3.
• O cliente não é compatível com HTTP/3 e, portanto, não tenta negociar uma conexão HTTP/3.

Quando uma conexão retorna para HTTPS ou HTTP/2, isso não é considerado uma falha do balanceador de carga.

Antes de ativar o HTTP/3, verifique se os comportamentos descritos acima são aceitáveis para suas cargas de trabalho.

Configurar HTTP/3

Tanto NONE (o padrão) quanto ENABLE ativam suporte a HTTP/3 para o balanceador de carga.

Quando o HTTP/3 está ativado, o balanceador de carga o anuncia para os clientes, o que permite que os clientes compatíveis com ele negociem uma versão HTTP/3 com o balanceador de carga. Clientes não compatíveis com HTTP/3 não negociam uma conexão HTTP/3. Não é necessário desativar o HTTP/3 explicitamente, a menos que você tenha identificado implementações de cliente corrompidas.

Os balanceadores de carga de aplicativo externos oferecem três maneiras de configurar o HTTP/3, conforme mostrado na tabela a seguir.

Valor quicOverride	Comportamento
NONE	A compatibilidade com HTTP/3 é anunciada para os clientes.
ENABLE	A compatibilidade com HTTP/3 é anunciada para os clientes. Observação: o TLS 0-RTT (também conhecido como dados antecipados do TLS) ainda não é compatível com HTTP/3.
DISABLE	Desativa explicitamente a divulgação de HTTP/3 e do Google QUIC para clientes.

Para ativar (ou desativar) o HTTP/3 explicitamente, siga estas etapas.

Console: HTTPS

Observação: No momento, a configuração da negociação HTTP/3 não é compatível com a página de proxies de destino e precisa ser definida editando a configuração do balanceador de carga.

1. No Console do Google Cloud, acesse a página Balanceamento de carga.

   Acessar o "Balanceamento de carga"

2. Selecione o balanceador de carga que você quer editar.

3. Clique em Configuração de front-end.

4. Selecione o endereço IP do front-end e a porta que você quer editar. Para editar uma configuração HTTP/3, o protocolo precisa ser HTTPS.

Ativar HTTP/3

1. Selecione a lista suspensa negociação QUIC.
2. Para ativar explicitamente o HTTP/3 para esse front-end, selecione Ativado.
3. Se você tiver várias regras de front-end representando IPv4 e IPv6, certifique-se de ativar o HTTP/3 em cada regra.

Desativar HTTP/3

1. Selecione a lista suspensa negociação QUIC.
2. Para desativar explicitamente o HTTP/3 para este front-end, selecione Desativado.
3. Se você tiver várias regras de front-end representando IPv4 e IPv6, desative o HTTP/3 para cada regra.

gcloud: HTTPS

Antes de executar este comando, é necessário criar um recurso de certificado SSL para cada certificado.

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

Substitua QUIC_SETTING por um dos seguintes:

• NONE (padrão): permite que o Google controle quando o HTTP/3 é anunciado.

  Quando você seleciona NONE, o HTTP/3 é anunciado para os clientes, mas o Google QUIC não. No console do Google Cloud, essa opção é chamada de Automática (padrão).

• ENABLE: divulga o HTTP/3 para os clientes.

• DISABLE: não anuncia HTTP/3 para os clientes.

API: HTTPS

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

Substitua QUIC_SETTING por um dos seguintes:

• NONE (padrão): permite que o Google controle quando o HTTP/3 é anunciado.

  Atualmente, quando você seleciona NONE, o HTTP/3 é anunciado para os clientes, mas o Google QUIC não.

  No console do Google Cloud, essa opção é chamada de Automática (padrão).

• ENABLE: anuncia HTTP/3 e Google QUIC para os clientes.

• DISABLE: não divulga HTTP/3 ou Google QUIC para os clientes.

Limitações

• Os balanceadores de carga HTTPS não enviam um alerta de encerramento close_notify ao encerrar conexões SSL. Ou seja, o balanceador de carga fecha a conexão TCP em vez de executar um encerramento SSL.
• Os balanceadores de carga HTTPS são compatíveis apenas com caracteres em minúsculas nos domínios em um atributo de nome comum (CN) ou em um atributo de nome alternativo do assunto (SAN) do certificado. Os certificados com caracteres maiúsculos em domínios são retornados somente quando definidos como o certificado principal no proxy de destino.
• Os balanceadores de carga HTTPS não usam a extensão de indicação de nome do servidor (SNI, na sigla em inglês) ao se conectar ao back-end, exceto para balanceadores de carga com back-ends de NEG da Internet. Veja mais detalhes em Criptografia do balanceador de carga aos back-ends.
• Ao usar balanceadores de carga de aplicativo externos regionais com o Cloud Run em um ambiente de VPC compartilhada, as redes VPC independentes em projetos de serviço podem enviar tráfego para qualquer outro serviço do Cloud Run implantado em qualquer outro projeto de serviço no mesmo ambiente de VPC compartilhada. Esse é um problema conhecido e essa forma de acesso será bloqueada no futuro.
• O Google Cloud não garante que uma conexão TCP subjacente possa permanecer aberta durante todo o valor do tempo limite do serviço de back-end. Os sistemas clientes precisam implementar a lógica de nova tentativa em vez de depender que uma conexão TCP permaneça aberta por períodos longos.
• Não é possível criar um balanceador de carga de aplicativo externo regional no nível Premium usando o console do Google Cloud. Além disso, apenas regiões com suporte ao nível Standard estão disponíveis para esses balanceadores de carga no console do Google Cloud. Use a gcloud CLI ou a API REST. Use a gcloud CLI ou a API REST.
• O Cloud CDN permite forçar um objeto ou conjunto de objetos a ser ignorado pelo cache solicitando uma invalidação de cache. Por padrão, quando você usa um balanceador de carga de aplicativo externo global com a referência de serviço entre projetos da VPC compartilhada, os administradores do projeto de serviço não têm as permissões necessárias para solicitar invalidações de cache. Isso ocorre porque a invalidação de cache é configurada no projeto de front-end, ou seja, no projeto que tem a regra de encaminhamento, o proxy de destino e o mapa de URL do balanceador de carga. Assim, as invalidações de cache só podem ser emitidas por principais que tenham os papéis do IAM necessários para configurar os recursos relacionados ao balanceador de carga nos projetos de front-end (por exemplo, o papel de administrador de rede do Compute). Os administradores de serviços, que controlam o provisionamento dos serviços de back-end em um projeto separado, precisarão trabalhar com o administrador do balanceador de carga do projeto de front-end para emitir a invalidação de cache para os serviços entre projetos.

A seguir

• Para saber como implantar um balanceador de carga de aplicativo externo global, consulte Como configurar um balanceador de carga de aplicativo externo com um back-end do Compute Engine.
• Para saber como implantar um balanceador de carga de aplicativo externo regional, consulte Como configurar um balanceador de carga de aplicativo externo regional com um back-end do Compute Engine.
• Se você já for usuário do balanceador de carga clássico do aplicativo, consulte Planejar a migração para o balanceador de carga de aplicativo externo global ao planejar uma nova implantação. com o balanceador de carga de aplicativo externo global.
• Para saber como automatizar a configuração do balanceador de carga de aplicativo externo com o Terraform, consulte Exemplos de módulo do Terraform para balanceadores de carga de aplicativo externos.
• Para saber como configurar recursos avançados de gerenciamento de tráfego disponíveis com o balanceador de carga externo de aplicativos global, consulte Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos globais.
• Para saber como configurar recursos avançados de gerenciamento de tráfego disponíveis com o balanceador de carga de aplicativo externo regional, consulte Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos regionais.
• Para encontrar os locais dos PoPs do Google, consulte locais do GFE.
• Saiba mais sobre o gerenciamento de capacidade em Tutorial sobre gerenciamento de capacidade com balanceamento de carga e Otimizações de capacidade de aplicativo com balanceamento de carga global.
• Saiba mais sobre como exibir sites em Como exibir sites.
• Para saber como usar o Gerenciador de certificados para provisionar e gerenciar certificados SSL, consulte a Visão geral do Gerenciador de certificados.
• Para injetar lógica personalizada no caminho de dados de balanceamento de carga, configure chamadas de extensões de serviço.