Visão geral do balanceador de carga interno do aplicativo

Neste documento, apresentamos os conceitos que você precisa entender para configurar balanceadores de carga de aplicativo internos.

Um balanceador de carga de aplicativo interno do Google Cloud é um balanceador de carga de camada 7 baseado em proxy que permite a execução e o escalonamento dos serviços protegidos por um endereço IP interno. O balanceador de carga de aplicativo interno distribui o tráfego HTTP e HTTPS aos back-ends hospedados em várias plataformas do Google Cloud, como o Compute Engine, o Google Kubernetes Engine (GKE) e o Cloud Run. Veja detalhes em Casos de uso.

Modos de operação

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

• Balanceador de carga de aplicativo interno entre regiões. Trata-se de um balanceador de carga multirregional que é implementado como um serviço gerenciado, baseado no proxy Envoy de código aberto. O modo entre regiões permite balancear a carga do tráfego para serviços de back-end distribuídos globalmente, incluindo o gerenciamento de tráfego, que garante que o tráfego seja direcionado para o back-end mais próximo. Esse balanceador de carga também possibilita a alta disponibilidade. Colocar back-ends em várias regiões ajuda a evitar falhas em uma única região. Se os back-ends de uma região estiverem inativos, o tráfego poderá fazer failover para outra região.

• Balanceador de carga de aplicativo interno regional. Esse é um balanceador de carga regional que é implementado como um serviço gerenciado no proxy Envoy de código aberto. O modo regional garante que todos os clientes e back-ends sejam de uma região específica, o que ajuda quando você precisa de conformidade regional. Esse balanceador de carga é ativado com recursos avançados de controle de tráfego com base em parâmetros HTTP(S). Depois que o balanceador de carga é configurado, ele aloca proxies Envoy automaticamente para atender às suas necessidades de tráfego.

  A seguinte tabela descreve diferenças importantes entre os modos regional e entre regiões:

  Engenharia de	Balanceador de carga de aplicativo interno entre regiões	Balanceador de carga de aplicativo interno regional
  Endereço IP virtual (VIP) do balanceador de carga.	Alocação por meio de uma sub-rede em uma região específica do Google Cloud. Endereços VIP de várias regiões podem compartilhar o mesmo serviço de back-end global. É possível configurar o balanceamento de carga global baseado em DNS usando políticas de roteamento de DNS a fim de encaminhar solicitações de clientes para o endereço VIP mais próximo.	Alocação por meio de uma sub-rede em uma região específica do Google Cloud.
  Acesso de cliente	Sempre acessível globalmente. Clientes de qualquer região do Google Cloud em uma VPC podem enviar tráfego para o balanceador de carga.	Por padrão, não é acessível globalmente. Como opção, é possível ativar o acesso global.
  Back-ends com carga balanceada	Back-ends globais. O balanceador de carga pode enviar tráfego para back-ends em qualquer região.	Back-ends regionais. O balanceador de carga só pode enviar tráfego para back-ends que estejam na mesma região que o proxy associado a ele.
  Alta disponibilidade e failover	Failover automático em back-ends íntegros na mesma região ou em regiões diferentes.	Failover automático em back-ends íntegros na mesma região.

Identificar o modo

console do Cloud

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

   Acessar o "Balanceamento de carga"

2. Na guia Balanceadores de carga, você verá o tipo do balanceador de carga, o protocolo e a região. Se a região estiver em branco, o balanceador de carga estará no modo entre regiões. 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 interno regional	Aplicativo	Internos	Especifica uma região
   Balanceador de carga de aplicativo interno entre regiões	Aplicativo	Internos

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
   Balanceador de carga de aplicativo interno entre regiões	INTERNAL_MANAGED	Global
   Balanceador de carga de aplicativo interno regional	INTERNAL_MANAGED	Regional

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 e recursos

O seguinte diagrama mostra os recursos do Google Cloud necessários para balanceadores de carga de aplicativo internos em cada modo:

Entre regiões

Este diagrama mostra os componentes de uma implantação de balanceador de carga de aplicativo interno entre regiões no nível Premium na mesma rede VPC. Cada regra de encaminhamento global conta com um endereço IP regional que os clientes usam para se conectar.

Componentes de um balanceador de carga de aplicativo interno entre regiões (clique para ampliar).

Regional

Este diagrama mostra os componentes de uma implantação de balanceador de carga de aplicativo interno regional no nível Premium.

Componentes de um balanceador de carga de aplicativo interno regional (clique para ampliar).

Cada balanceador de carga de aplicativo interno usa os recursos de configuração a seguir do Google Cloud.

Sub-rede somente proxy

No diagrama acima, 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 HTTP(S) internos.

A seguinte tabela descreve as diferenças entre as sub-redes somente proxy nos modos regional e entre regiões:

Modo balanceador de carga	Valor da flag de sub-rede somente proxy --purpose
Balanceador de carga de aplicativo interno entre regiões	GLOBAL_MANAGED_PROXY Balanceadores de carga regionais e entre regiões não podem compartilhar as mesmas sub-redes O balanceador de carga entre regiões baseado no Envoy precisa ter uma sub-rede somente proxy em cada região em que está configurado. Os proxies do balanceador de carga entre regiões na mesma região e rede compartilham a mesma sub-rede somente proxy.
Balanceador de carga de aplicativo interno regional	REGIONAL_MANAGED_PROXY Balanceadores de carga regionais e entre regiões não podem compartilhar as mesmas sub-redes Todos os balanceadores de carga regionais baseados no Envoy em uma região e rede VPC compartilham a 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 interno em uma região e rede VPC recebem conexões da sub-rede somente proxy.
• O endereço IP virtual de um balanceador de carga de aplicativo interno 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.

Regra de encaminhamento e endereço IP

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 e serviço de back-end.

Cada regra de encaminhamento faz referência a um endereço IP regional único que pode ser usado nos registros DNS do aplicativo. É possível reservar um endereço IP estático que possa ser usado ou permitir que o Cloud Load Balancing atribua um para você. Recomendamos reservar um endereço IP estático. Caso contrário, será necessário atualizar o registro DNS com o endereço IP temporário recém-atribuído sempre que uma regra de encaminhamento for excluída e uma nova for criada.

Os clientes usam o endereço IP e a porta para se conectar aos proxies do Envoy relativos ao balanceador de carga. O endereço IP da regra de encaminhamento é o endereço IP do balanceador de carga, que é chamado frequentemente de endereço IP virtual ou VIP. Os clientes que se conectam a um balanceador de carga precisam usar a versão 1.1 ou posterior do HTTP. Para ver a lista completa dos protocolos compatíveis, consulte Recursos do balanceador de carga.

O endereço IP interno associado à regra de encaminhamento pode ser proveniente de uma sub-rede na mesma rede e região que os back-ends.

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

A seguinte tabela mostra as diferenças entre as regras de encaminhamento nos modos regional e entre regiões:

Modo balanceador de carga	Regra de encaminhamento, endereço IP e sub-rede somente proxy --purpose	Roteamento do cliente para o front-end do balanceador de carga
Balanceador de carga de aplicativo interno entre regiões	Regra de encaminhamento global Endereços IP regionais Esquema de balanceamento de carga: INTERNAL_MANAGED Sub-rede somente proxy --purpose: GLOBAL_MANAGED_PROXY Endereço IP --purpose: SHARED_LOADBALANCER_VIP	O acesso global é ativado por padrão para permitir que clientes de qualquer região em uma VPC acessem o balanceador de carga. Os back-ends podem estar em várias regiões.
Balanceador de carga de aplicativo interno regional	Regra de encaminhamento regional Endereço IP regional Esquema de balanceamento de carga: INTERNAL_MANAGED Sub-rede somente proxy --purpose: REGIONAL_MANAGED_PROXY Endereço IP --purpose: SHARED_LOADBALANCER_VIP	É possível ativar o acesso global para permitir que clientes de qualquer região em uma VPC acessem o balanceador de carga. Os back-ends também precisam estar na mesma região que o balanceador de carga.

Proxy de destino

Um proxy HTTP(S) de destino encerra as conexões HTTP(S) dos clientes. O proxy HTTP(S) consulta o mapa de URLs para determinar como rotear o tráfego para os back-ends. Um proxy HTTPS de destino usa um certificado SSL para fazer a autenticação para os clientes.

O balanceador de carga preserva o cabeçalho Host da solicitação original do cliente. O balanceador de carga também anexa dois endereços IP ao cabeçalho X-Forwarded-For:

• O endereço IP do cliente que se conecta ao balanceador de carga
• O endereço IP 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. Se a solicitação tiver um cabeçalho X-Forwarded-For, outras informações, como os endereços IP registrados por proxies no caminho até o balanceador de carga, serão preservadas antes dos dois endereços IP. O balanceador de carga não verifica endereços IP que precedem os dois últimos endereços IP nesse cabeçalho.

Se você estiver executando um proxy como servidor de back-end, esse proxy normalmente anexará mais informações ao cabeçalho X-Forwarded-For, e o software poderá precisar considerar isso. As solicitações por proxy do balanceador de carga vêm de um endereço IP na sub-rede somente proxy, e seu proxy na instância de back-end pode registrar esse endereço e o endereço IP da própria instância.

Dependendo do tipo de tráfego que o aplicativo precisa processar, é possível configurar um balanceador de carga com um proxy HTTP ou HTTPS de destino.

A seguinte tabela mostra as APIs de proxy de destino exigidas pelos balanceadores de carga de aplicativo internos em cada modo:

Proxy de destino	Balanceador de carga de aplicativo interno entre regiões	Balanceador de carga de aplicativo interno regional
HTTP	targetHttpProxies global	regionTargetHttpProxies
HTTPS	targetHttpsProxies global	regionTargetHttpsProxies

Certificados SSL

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

A seguinte tabela especifica o tipo de certificados SSL exigidos pelos balanceadores de carga de aplicativo internos em cada modo:

Modo balanceador de carga	Tipo de certificado SSL
Balanceador de carga de aplicativo interno regional	Certificados SSL regionais do Compute Engine Certificados gerenciados pelo Google e certificados autogerenciados regionais do gerenciador de certificados. Os seguintes tipos de certificados gerenciados pelo Google são compatíveis com o gerenciador de certificados: Certificados regionais gerenciados pelo Google com autorização de DNS por projeto. Para mais informações, consulte Implantar um certificado regional gerenciado pelo Google. Certificados regionais gerenciados pelo Google com o Certificate Authority Service particular. Para mais informações, consulte Implantar um certificado regional gerenciado pelo Google com o serviço de AC. Não há suporte para certificados gerenciados pelo Google com autorização do balanceador de carga.
Balanceador de carga de aplicativo interno entre regiões	Certificados gerenciados pelo Google e certificados autogerenciados do gerenciador de certificados. Os seguintes tipos de certificados gerenciados pelo Google são compatíveis com o gerenciador de certificados: Autorização de DNS com DNS público. Para mais informações, consulte Criar um certificado gerenciado pelo Google com autorização de DNS. Certificate Authority Service particular. Para mais informações, consulte Criar um certificado gerenciado pelo Google emitido pela instância de serviço de CA. Não há suporte para certificados gerenciados pelo Google com autorização do balanceador de carga. Os certificados SSL do Compute Engine não são compatíveis.

Mapas de URL

O proxy HTTP(S) de destino usa mapas de URL para determinar o roteamento com base em atributos HTTP, como o caminho da solicitação, cookies ou cabeçalhos. Com base na decisão de roteamento, o proxy encaminha as solicitações do cliente para serviços de back-end regionais específicos. O mapa de URL pode especificar outras ações a serem tomadas, como regravar cabeçalhos, enviar redirecionamentos a clientes e configurar políticas de tempo limite, entre outras.

A seguinte tabela especifica o tipo de mapa de URL exigido pelos balanceadores de carga de aplicativo internos em cada modo:

Modo balanceador de carga	Tipo de mapa de URL
Balanceador de carga de aplicativo interno entre regiões	Mapas de URLs globais
Balanceador de carga de aplicativo interno regional	Mapas de URLs regionais

Serviço de back-end

Um serviço de back-end distribui as solicitações para back-ends íntegros: grupos de instâncias contendo VMs do Compute Engine, o Cloud Run ou NEGs contendo contêineres do GKE.

Os serviços de back-end oferecem suporte aos protocolos HTTP, HTTPS ou HTTP/2. O HTTP/2 só é compatível com TLS. Clientes e back-ends não precisam usar o mesmo protocolo de solicitação. Por exemplo, os clientes podem enviar solicitações para o balanceador de carga usando HTTP/2, e o balanceador de carga pode encaminhar essas solicitações para back-ends usando HTTP/1.1.

A seguinte tabela especifica o tipo de serviço de back-end exigido pelos balanceadores de carga de aplicativo internos em cada modo:

Modo balanceador de carga	Tipo de serviço de back-end
Balanceador de carga de aplicativo interno entre regiões	backendServices globais
Balanceador de carga de aplicativo interno regional	backendServices regionais

A seguinte tabela especifica os recursos de back-end compatíveis com os balanceadores de carga de aplicativo internos 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 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 interno entre regiões		^2		Cloud Run
Balanceador de carga de aplicativo interno regional		^1		Cloud Run

¹ 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

Observação:

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

• Ao compartilhar os mesmos grupos de instâncias para serviços de back-end globais e regionais, configure a política de escalonamento automático do grupo de instâncias para usar vários sinais.

Para mais informações, consulte Visão geral dos serviços de back-end.

Back-ends e redes VPC

Todos os back-ends precisam estar na mesma rede VPC. Não é possível colocar back-ends em redes VPC diferentes, mesmo aqueles conectados por peering de rede VPC. Para detalhes sobre como os sistemas de cliente em redes VPC com peering podem acessar balanceadores de carga, consulte Balanceadores de carga de aplicativo internos e redes conectadas.

Subconfiguração de back-ends

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

A subconfiguração de back-end é um recurso opcional compatível com balanceadores de carga de aplicativo internos regionais que melhora o desempenho e a escalonabilidade por meio da atribuição de um subconjunto de back-ends a cada uma das instâncias de proxy.

Por padrão, a subconfiguração de back-end fica desativada. Para informações sobre como ativar esse recurso, consulte Subagrupamento de back-end para o balanceador de carga interno do aplicativo.

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 realizar sondagens de verificação de integridade com sucesso, é necessário criar uma regra de firewall de permissão do Ingress que permita que as sondagens de verificação de integridade acessem 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. No entanto, para NEGs híbridos, as verificações de integridade são originadas na sub-rede somente proxy. Para detalhes, consulte as verificações de integridade distribuídas do Envoy na 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 internos 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 seguinte tabela especifica o escopo das verificações de integridade compatíveis com balanceadores de carga de aplicativo internos em cada modo:

Modo balanceador de carga	Tipo de verificação de integridade
Balanceador de carga de aplicativo interno entre regiões	Global
Balanceador de carga de aplicativo interno 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

Um balanceador de carga de aplicativo interno requer as seguintes regras de firewall:

• Uma regra de permissão de entrada que permita o tráfego dos intervalos de verificação de integridade central do Google.
  • 35.191.0.0/16
  • 130.211.0.0/22
• Uma regra de permissão de entrada que permita o tráfego da sub-rede somente proxy.

Há algumas exceções aos requisitos de regras de firewall para esses intervalos:

• Não é necessário adicionar intervalos de sondagem de verificação de integridade do Google à 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.
• Para NEGs regionais da Internet, as verificações de integridade são opcionais. O tráfego de balanceadores de carga que usam NEGs regionais da Internet é proveniente da sub-rede somente proxy e, em seguida, é convertido por NAT (usando o Cloud NAT) para endereços IP NAT alocados automaticamente ou manualmente. Esse tráfego inclui sondagens de verificação de integridade e solicitações de usuários do balanceador de carga aos back-ends. Para detalhes, consulte NEGs regionais: usar o Cloud NAT para saída.

Acesso de cliente

Os clientes podem estar na mesma rede ou em uma rede VPC conectada usando o peering de rede VPC.

Para balanceadores de carga de aplicativo internos entre regiões, o acesso global é ativado por padrão. Clientes de qualquer região em uma VPC podem acessar seu balanceador de carga.

Para balanceadores de carga de aplicativo internos regionais, os clientes precisam estar, por padrão, na mesma região que o balanceador de carga. É possível ativar o acesso global para permitir que clientes de qualquer região em uma VPC acessem o balanceador de carga.

A seguinte tabela resume o acesso do cliente para balanceadores de carga de aplicativo internos regionais:

Acesso global desativado	Acesso global ativado
Os clientes precisam estar na mesma região que o balanceador de carga. Também precisam estar na mesma rede VPC do balanceador de carga ou em uma conectada à do balanceador usando o peering da rede VPC.	Os clientes podem estar em qualquer região. Ainda precisam estar na mesma rede VPC do balanceador de carga ou em uma conectada à do balanceador usando peering da rede VPC.
Os clientes locais podem acessar o balanceador de carga por meio de túneis VPN do Cloud ou anexos da VLAN. Esses túneis ou anexos precisam estar na mesma região do balanceador de carga.	Os clientes locais podem acessar o balanceador de carga por meio de túneis VPN do Cloud ou anexos da VLAN. Esses túneis ou anexos podem estar em qualquer região.

Arquiteturas de VPC compartilhada

Os balanceadores de carga de aplicativo internos 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 que eles possam se comunicar uns com os outros com segurança e eficiência usando IPs internos dessa rede. Se você ainda não estiver familiarizado com a VPC compartilhada, leia a documentação de visão geral da VPC compartilhada.

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

Sub-redes e endereço IP	Componentes de front-end	Componentes de back-end
Crie a rede e as sub-redes necessárias (incluindo a sub-rede somente proxy) no projeto host da VPC compartilhada. O endereço IP interno do balanceador de carga pode ser definido no projeto host ou em um projeto de serviço, mas precisa usar uma sub-rede na rede VPC compartilhada desejada no host projeto. O endereço vem do intervalo de IP principal da sub-rede referenciada.	O endereço IP interno 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 dex 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 dão suporte a esse tipo de implantação.

O balanceador de carga usa endereços IP e sub-redes a partir do projeto host. Os clientes poderão acessar um balanceador de carga de aplicativo interno se estiverem na mesma região e rede VPC compartilhada que ele. Os clientes podem estar no projeto host, em um projeto de serviço anexado ou em qualquer rede conectada.

Balanceador de carga de aplicativo interno na rede VPC compartilhada

Back-ends sem servidor em um ambiente de VPC compartilhada**

No caso de um balanceador de carga de aplicativo interno que esteja usando um back-end de NEG sem servidor, o serviço de backup do Cloud Run precisa estar no mesmo projeto de serviço que o serviço de back-end e o NEG sem servidor. Os componentes do front-end do balanceador de carga (regra de encaminhamento, proxy de destino, mapa de URL) podem ser criados no projeto host, no mesmo projeto de serviço dos componentes de back-end ou em qualquer outro projeto de serviço no mesmo ambiente de VPC compartilhada.

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

Para saber como configurar a VPC compartilhada para um balanceador de carga de aplicativo interno, com e sem a referência de serviço entre projetos, consulte Configurar um balanceador de carga de aplicativo interno com VPC compartilhada.

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

• Não será possível referenciar um serviço de back-end entre projetos se ele tiver back-ends de NEG da Internet regionais. Há suporte para todos os outros tipos de back-end.
• O Google Cloud não diferencia recursos (por exemplo, serviços de back-end) que usam 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

Tempo limite e tentativas

Os balanceadores de carga de aplicativo interno 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
		Tempo limite do serviço de back-end 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 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
Tempo limite do sinal de atividade HTTP do cliente O tempo máximo que a conexão TCP entre um cliente e o proxy Envoy gerenciado do balanceador de carga pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP.	10 minutos (600 segundos)
Tempo limite do sinal de atividade HTTP do back-end O tempo máximo que a conexão TCP entre o proxy Envoy gerenciado 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.	10 minutos (600 segundos)

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.

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.

Para conexões WebSocket usadas com balanceadores de carga de aplicativo internos, 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.

Periodicamente, o Google Cloud reinicia ou altera o número de tarefas de software do Envoy em atendimento. 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.

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: 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 o tempo máximo em que uma conexão TCP pode ficar inativa entre o cliente (downstream) e um proxy Envoy. O valor de tempo limite do sinal de atividade HTTP do cliente é fixado em 600 segundos.

Um tempo limite do sinal de atividade HTTP também é chamado de tempo limite de inatividade do TCP.

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 internos são proxies que usam uma primeira conexão TCP entre o cliente (downstream) e um proxy Envoy e uma segunda conexão TCP entre o proxy Envoy e 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;

Novas tentativas

Para configurar novas tentativas, use uma política de nova tentativa no mapa de URL. O número padrão de novas tentativas (numRetries) é 1. 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 para a resposta final.

Para mais informações, consulte Geração de registros e monitoramento do balanceador de carga interno do aplicativo.

Como acessar redes conectadas

É possível acessar um balanceador de carga de rede de passagem interno na sua rede VPC a partir de uma rede conectada usando o seguinte:

• Peering de rede VPC
• Cloud VPN e Cloud Interconnect

Para exemplos detalhados, consulte Balanceadores de carga de aplicativos internos e redes conectadas.

Failover

Se um back-end não estiver íntegro, o tráfego será redirecionado automaticamente para back-ends íntegros.

A seguinte tabela descreve o comportamento de failover em cada modo:

Modo balanceador de carga	Comportamento de failover	Comportamento quando nenhum back-end estiver íntegro
Balanceador de carga de aplicativo interno entre regiões	Failover automático para back-ends íntegros na mesma região ou em outras regiões. O tráfego é distribuído entre back-ends íntegros que abrangem várias regiões com base na distribuição de tráfego configurada.	Retorna HTTP 503
Balanceador de carga de aplicativo interno regional	Failover automático em back-ends íntegros na mesma região. O proxy do Envoy envia o tráfego para back-ends íntegros em uma região com base na distribuição de tráfego configurada.	Retorna HTTP 503

Alta disponibilidade e failover entre regiões

É possível configurar um balanceador de carga de aplicativo interno entre regiões em várias regiões para ter os seguintes benefícios:

1. Se o balanceador de carga de aplicativo interno entre regiões falhar em uma região, as políticas de roteamento de DNS vão encaminhar o tráfego para um balanceador de carga de aplicativo interno entre regiões em outra região.

   O exemplo de implantação de alta disponibilidade mostra o seguinte:

   • Um balanceador de carga de aplicativo interno entre regiões com endereço IP virtual (VIP, na sigla em inglês) de front-end nas regiões RegionA e RegionB da rede VPC. Seus clientes estão localizados na região RegionA.
   • É possível tornar o balanceador de carga acessível usando VIPs de front-end de duas regiões e usar políticas de roteamento de DNS para retornar o VIP ideal aos seus clientes. Use as políticas de roteamento de geolocalização se quiser que seus clientes usem o VIP geograficamente mais próximo.
   • As políticas de roteamento de DNS podem detectar se um VIP está ou não respondendo durante uma interrupção regional e retornar o próximo VIP mais ideal aos clientes, garantindo que o aplicativo permaneça ativo mesmo durante interrupções regionais.

   

   Balanceador de carga de aplicativo interno entre regiões com uma implantação de alta disponibilidade (clique para ampliar).

2. Se os back-ends de uma determinada região estiverem inativos, o tráfego do balanceador de carga de aplicativo interno entre regiões fará o failover para os back-ends de outra região normalmente.

   O exemplo de implantação do failover entre regiões mostra o seguinte:

   • Um balanceador de carga de aplicativo interno entre regiões com um endereço VIP de front-end na região RegionA da sua rede VPC. Seus clientes também estão localizados na região RegionA.
   • Um serviço de back-end global que faz referência aos back-ends nas regiões do Google Cloud RegionA e RegionB.
   • Quando os back-ends da região RegionA estão inativos, o tráfego faz o failover para a região RegionB.

   

   Balanceador de carga de aplicativo interno entre regiões com uma implantação de failover entre regiões (clique para ampliar).

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.

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.

Suporte ao gRPC

O gRPC é um framework 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.

Suporte TLS

Por padrão, um proxy de destino HTTPS só aceita TLS 1.0, 1.1 e 1.2 e 1.3 ao encerrar solicitações SSL do cliente.

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

Limitações

• Não há garantia de que uma solicitação de um cliente em uma zona da região seja enviada para um back-end que esteja na mesma zona que o cliente. A afinidade da sessão não reduz a comunicação entre as zonas.

• Os balanceadores de carga de aplicativo interno não são compatíveis com os seguintes recursos:

  • Cloud CDN
  • Google Cloud Armor
  • Buckets do Cloud Storage
  • Certificados SSL gerenciados pelo Google

• Um balanceador de carga de aplicativo interno é compatível com HTTP/2 somente por TLS.

• Os clientes que se conectam a um balanceador de carga interno de aplicativo precisam usar a versão 1.1 ou posterior do HTTP. O HTTP 1.0 não é compatível.

• O Google Cloud não alerta se os endereços IP da sub-rede apenas de proxy acabarem.

• A regra de encaminhamento interno usada pelo balanceador de carga interno do aplicativo precisa ter exatamente uma porta.

• Os balanceadores de carga de aplicativo internos não são compatíveis com o Cloud Trace.

• Ao usar um balanceador de carga de aplicativo interno com o Cloud Run em um ambiente de VPC compartilhada, as redes VPC autônomas em projetos de serviço podem enviar tráfego para qualquer outro serviço do Cloud Run implantado em qualquer outro projetos 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.

A seguir

• Para configurar o balanceamento de carga em uma configuração de VPC compartilhada, consulte Configurar um balanceador de carga de aplicativo interno para VPC compartilhada.
• Saiba como configurar o balanceamento de carga para seus serviços em execução nos pods do GKE em Como implantar gateways do GKE, Balanceamento de carga nativo de contêiner com NEGs independentes e na seção Como anexar um balanceador de carga de aplicativo interno a NEGs independentes.
• Para configurar um balanceador de carga de aplicativo interno regional com o Private Service Connect, consulte Como configurar o Private Service Connect com controles de serviço HTTP(S) do consumidor.
• Para gerenciar o recurso de sub-rede somente proxy, consulte Sub-redes somente proxy.
• Para configurar a subconfiguração de back-end em balanceadores de carga de aplicativo internos regionais, consulte Subconfiguração de back-end.
• Para injetar lógica personalizada no caminho de dados de balanceamento de carga, configure chamadas de extensões de serviço.