Visão geral dos serviços de back-end

Um serviço de back-end define como o Cloud Load Balancing distribui tráfego. A configuração do serviço de back-end contém um conjunto de valores, como o protocolo usado para se conectar a back-ends, várias configurações de distribuição e sessão, verificações de integridade e tempos limite. Essas configurações fornecem um controle refinado sobre o comportamento do seu balanceador de carga. Para começar, a maioria das configurações tem valores padrão que permitem uma configuração rápida. Um serviço de back-end pode ter escopo global ouregional.

Os balanceadores de carga, proxies Envoy e clientes gRPC sem proxy usam as informações de configuração no recurso do serviço de back-end para fazer o seguinte:

• direcionar o tráfego para os back-ends corretos, que são grupos de instâncias ou grupos de endpoints de rede (NEGs, na sigla em inglês).
• distribuir o tráfego de acordo com um modo de balanceamento, que é uma configuração para cada back-end;
• determinar qual verificação de integridade está monitorando a integridade dos back-ends;
• Especificar a afinidade da sessão.
• Determine se outros serviços estão ativados, incluindo os seguintes disponíveis apenas para determinados balanceadores de carga:
  • Cloud CDN
  • Políticas de segurança do Google Cloud Armor
  • Identity-Aware Proxy
• Designar serviços de back-end regionais como um serviço no App Hub, que está em pré-lançamento.

Você define esses valores quando cria um serviço de back-end ou adiciona um back-end a ele.

Observação: se você estiver usando o balanceador de carga de aplicativo externo global ou o balanceador de carga de aplicativo clássico e seus back-ends disponibilizarem conteúdo estático, use buckets de back-end em vez de serviços de back-end. Consulte Buckets de back-end para balanceadores de carga de aplicativo externos globais ou Buckets de back-end para balanceadores de carga de aplicativo clássicos.

A tabela a seguir resume quais balanceadores de carga usam serviços de back-end. O produto que você está usando também determina o número máximo de serviços de back-end, o escopo de um serviço de back-end, o tipo de back-end suportado e o esquema de balanceamento de carga do serviço de back-end. O esquema de balanceamento de carga é um identificador usado pelo Google para classificar regras de encaminhamento e serviços de back-end. Cada produto de balanceamento de carga usa um esquema de balanceamento de carga para as regras de encaminhamento e serviços de back-end. Alguns esquemas são compartilhados entre os produtos.

Tabela: serviços de back-end e tipos de back-end compatíveis

Produto	Número máximo de serviços de back-end	Escopo do serviço de back-end	Tipos de back-end compatíveis	Esquema de balanceamento de carga
Balanceador de carga de aplicativo externo global	Várias	Global	Cada serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas ^* Todos os NEGs por zona: um ou mais NEGs por zona tipo GCE_VM_IP_PORT^* Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT ^† Todos os NEGs sem servidor: um ou mais serviços do App Engine, Cloud Run ou Cloud Functions Um NEG global da Internet para um back-end externo NEGs do Private Service Connect: APIs do Google: um único NEG do Private Service Connect Serviços gerenciados: um ou mais NEGS do Private Service Connect	EXTERNAL_MANAGED
Balanceador de carga de aplicativo clássico	Várias	Global^‡	Cada serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT ^† Todos os NEGs sem servidor: um ou mais serviços do App Engine, Cloud Run ou Cloud Functions, ou Um NEG global da Internet para um back-end externo	EXTERNO^#
Balanceador de carga de aplicativo externo regional	Várias	Regional	Cada serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas ^* Todos os NEGs por zona: um ou mais NEGs por zona tipo GCE_VM_IP_PORT ^* Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT ^† Um único NEG sem servidor (somente Cloud Run) Um único NEG do Private Service Connect Todos os NEGs regionais da Internet para um back-end externo	EXTERNAL_MANAGED
Balanceador de carga de aplicativo interno entre regiões	Várias	Global	Cada serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas ^* Todos os NEGs por zona: um ou mais NEGs por zona tipo GCE_VM_IP_PORT ^* Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT ^† Um único NEG sem servidor (somente Cloud Run) NEGs do Private Service Connect: APIs do Google: um único NEG do Private Service Connect Serviços gerenciados: um ou mais NEGS do Private Service Connect	INTERNAL_MANAGED
Balanceador de carga de aplicativo interno regional	Várias	Regional	Cada serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas ^* Todos os NEGs por zona: um ou mais NEGs por zona tipo GCE_VM_IP_PORT ^* Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT ^† Um único NEG sem servidor (somente Cloud Run) Um único NEG do Private Service Connect Todos os NEGs regionais da Internet para um back-end externo	INTERNAL_MANAGED
Balanceador de carga de rede de proxy externo global	1	Global^‡	O serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo gerenciado ou não gerenciado de instâncias ^* Todos os NEGs por zona: um ou mais NEGs por zona tipo GCE_VM_IP_PORT^* Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT ^† NEGs do Private Service Connect: APIs do Google: um único NEG do Private Service Connect Serviços gerenciados: um ou mais NEGS do Private Service Connect	EXTERNAL_MANAGED
Balanceador de carga de rede de proxy clássico	1	Global^‡	O serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT ^†	EXTERNAL
Balanceador de carga de rede de proxy externo regional	1	Regional	O serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas ^* Todos os NEGs por zona: um ou mais NEGs por zona tipo GCE_VM_IP_PORT ^* Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT Todos os NEGs regionais da Internet para um back-end externo Um único NEG do Private Service Connect	EXTERNAL_MANAGED
Balanceador de carga de rede de proxy interno regional	1	Regional	O serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas ^* Todos os NEGs por zona: um ou mais NEGs por zona tipo GCE_VM_IP_PORT ^* Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT Todos os NEGs regionais da Internet para um back-end externo Um único NEG do Private Service Connect	INTERNAL_MANAGED
Balanceador de carga de rede de proxy interno entre regiões	Várias	Global	O serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas ^* Todos os NEGs por zona: um ou mais NEGs por zona tipo GCE_VM_IP_PORT ^* Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT NEGs do Private Service Connect: APIs do Google: um único NEG do Private Service Connect Serviços gerenciados: um ou mais NEGS do Private Service Connect	INTERNAL_MANAGED
Balanceador de carga de rede de passagem externa	1	Regional	O serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP por zona	EXTERNAL
Balanceador de carga de rede de passagem interna	1	Regional, mas configurável para acesso global	O serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP por zona Um NEG de mapeamento de portas	INTERNAL
Cloud Service Mesh	Várias	Global	Cada serviço de back-end é compatível com uma das seguintes combinações de back-end: Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT ou NON_GCP_PRIVATE_IP_PORT por zona, ou Um NEG de Internet do tipo INTERNET_FQDN_PORT Uma ou mais vinculações de serviço	INTERNAL_SELF_MANAGED

^* Oferece suporte a grupos de instâncias IPv4 e IPv6 (pilha dupla) e back-ends de NEG por zona. Os NEGs zonais oferecem suporte à pilha dupla apenas em endpoints do tipo GCE_VM_IP_PORT.

^† Em implantações do GKE, back-ends de NEGs mistos são compatíveis apenas com NEGs independentes.

^‡ Os serviços de back-end usados pelos balanceadores de carga de aplicativo clássico e de proxy clássico sempre têm escopo global, no nível de rede Padrão ou Premium. No entanto, no nível Standard, as seguintes restrições se aplicam:

• A regra de encaminhamento e o endereço IP externo são regionais.
• Todos os back-ends conectados ao serviço de back-end precisam estar localizados na mesma região da regra de encaminhamento.

^# É possível anexar serviços de back-end EXTERNAL_MANAGED a regras de encaminhamento EXTERNAL. No entanto, os serviços de back-end EXTERNAL não podem ser anexados às regras de encaminhamento EXTERNAL_MANAGED. Para aproveitar os novos recursos disponíveis apenas com o balanceador de carga de aplicativo externo global, recomendamos que você migre seus recursos EXTERNAL atuais para EXTERNAL_MANAGED usando o processo de migração descrito em Migrar recursos do balanceador de carga de aplicativo clássico para o balanceador de carga de aplicativo externo global.

Back-ends

Um back-end é um ou mais endpoints que recebem tráfego de um balanceador de carga do Google Cloud, de um proxy Envoy configurado pelo Cloud Service Mesh ou de um cliente gRPC sem proxy. Há vários tipos de back-ends:

• Grupo de instâncias que contém instâncias de máquina virtual (VM). Um grupo de instâncias pode ser um grupo de instâncias gerenciadas (MIG), com ou sem escalonamento automático, ou pode ser um grupo de instâncias não gerenciadas. Mais de um serviço de back-end pode se referir a um grupo de instâncias, mas todos os serviços de back-end que fazem referência ao grupo de instâncias precisam usar o mesmo modo de balanceamento.
• NEG por zona
• NEG sem servidor
• NEG da Internet
• NEG de conectividade híbrida
• NEG do Private Service Connect
• NEG de mapeamento de portas
• Vinculações de serviço do Diretório de serviços

Não é possível excluir um grupo de instâncias de back-end ou um NEG associado a um serviço de back-end. Antes de excluir um grupo de instâncias ou NEG, remova-o como um back-end de todos os serviços de back-end que se referem a ele.

Grupos de instâncias

Esta seção discute como os grupos de instâncias funcionam com o serviço de back-end.

VMs de back-end e endereços de IP externos

As VMs de back-end nos serviços de back-end não precisam de endereços IP externos:

• Para balanceadores de carga de aplicativos externos globais e balanceadores de carga de rede de proxy externo: os clientes se comunicam com um Google Front End (GFE) que hospeda o endereço IP externo do seu balanceador de carga. Os GFEs se comunicam com endpoints ou VMs de back-end enviando pacotes para um endereço interno criado com a junção de um identificador à rede VPC do back-end com o endereço IPv4 interno do back-end. A comunicação entre GFEs e VMs de back-end ou endpoints é facilitada por meio de rotas especiais.
  • Para back-ends de grupos de instâncias, o endereço IPv4 interno é sempre o endereço IPv4 interno principal que corresponde à interface nic0 da VM.
  • Para endpoints GCE_VM_IP_PORT em um NEG zonal, especifique o endereço IP do endpoint como o endereço IPv4 principal associado a qualquer interface de rede de uma VM ou qualquer endereço IPv4 de um intervalo de endereços IP do alias associado a qualquer rede de uma VM.

• Para balanceadores de carga HTTP(S) externos regionais: os clientes se comunicam com um proxy Envoy que hospeda o endereço IP externo do balanceador de carga. Os proxies do Envoy se comunicam com VMs ou endpoints de back-end enviando pacotes para um endereço interno criado mesclando um identificador na rede VPC do back-end com o endereço IPv4 interno do back-end.

  • Para back-ends de grupos de instâncias, o endereço IPv4 interno é sempre o endereço IPv4 interno principal que corresponde à interface nic0 da VM, e nic0 precisa estar na mesma rede que o balanceador de carga. de dados.
  • Para endpoints GCE_VM_IP_PORT em um NEG zonal, especifique o endereço IP do endpoint como o endereço IPv4 principal associado a qualquer interface de rede de uma VM ou qualquer endereço IPv4 de um intervalo de endereços IP do alias associado a qualquer rede de uma VM, desde que a interface de rede esteja na mesma rede que o balanceador de carga.

• Para balanceadores de carga de rede: os clientes se comunicam diretamente com back-ends por meio da infraestrutura de balanceamento de carga de Maglev do Google. Os pacotes são roteados e entregues a back-ends com os endereços IP de origem e destino originais preservados. Os back-ends respondem a clientes usando o retorno de servidor direto. Os métodos usados para selecionar um back-end e rastrear as conexões são configuráveis.

  • Para back-ends de grupos de instâncias, os pacotes são sempre entregues à interface nic0 da VM.
  • Para endpoints GCE_VM_IP em um NEG zonal, os pacotes são entregues à interface de rede da VM que está na sub-rede associada ao NEG.

Portas nomeadas

O atributo porta nomeada do serviço de back-end só é aplicável a balanceadores de carga baseados em proxy (balanceadores de carga de aplicativo e balanceadores de carga de rede proxy) que usam back-ends de grupos de instâncias. A porta nomeada define a porta de destino usada para a conexão TCP entre o proxy (GFE ou Envoy) e a instância de back-end.

As portas nomeadas são configuradas da seguinte maneira:

• Em cada back-end do grupo de instâncias, é preciso configurar uma ou mais portas nomeadas com pares de chave-valor. A chave representa um nome de porta significativo escolhido por você e o valor representa o número da porta que você atribui ao nome. O mapeamento de nomes para números é feito individualmente para cada back-end de grupo de instâncias.

• No serviço de back-end, especifique uma única porta nomeada usando apenas o nome da porta (--port-name).

Cada serviço de back-end converte o nome da porta em um número de porta. Quando a porta nomeada de um grupo de instâncias corresponde a --port-name do serviço de back-end, o serviço de back-end usa esse número de porta para se comunicar com as VMs do grupo de instâncias.

Por exemplo, defina a porta nomeada em um grupo de instâncias com o nome my-service-name e a porta 8888:

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

Em seguida, faça referência à porta nomeada na configuração do serviço de back-end com --port-name no serviço de back-end definido como my-service-name:

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

Um serviço de back-end poderá usar um número de porta diferente ao se comunicar com VMs em grupos de instâncias diferentes se cada grupo de instâncias especificar um número de porta diferente para o mesmo nome de porta.

O número da porta resolvida usado pelo serviço de back-end do balanceador de carga do proxy não precisa corresponder ao número da porta usado pelas regras de encaminhamento do balanceador de carga. Um balanceador de carga do proxy detecta conexões TCP enviadas ao endereço IP e à porta de destino das regras de encaminhamento. Como o proxy abre uma segunda conexão TCP para os back-ends, a porta de destino da segunda conexão TCP pode ser diferente.

As portas nomeadas são aplicáveis apenas aos back-ends de grupos de instâncias. NEGs zonais com endpoints GCE_VM_IP_PORT, híbridos com endpoints NON_GCP_PRIVATE_IP_PORT e NEGs da Internet definem as portas usando um mecanismo diferente, ou seja, nos próprios endpoints. NEGs sem servidor referenciam os Serviços do Google e os NEGs do PSC fazem referência a anexos de serviço usando abstrações que não envolvem a especificação de uma porta de destino.

Os balanceadores de carga de rede de passagem interna e externos de passagem não usam portas nomeadas. Isso ocorre porque eles são balanceadores de carga de passagem que encaminham conexões diretamente para back-ends, em vez de criar novas conexões. Os pacotes são entregues aos back-ends que preservam o endereço IP de destino e a porta da regra de encaminhamento do balanceador de carga.

Para saber como criar portas nomeadas, veja as seguintes instruções:

• Grupos de instâncias não gerenciadas: Como trabalhar com portas nomeadas
• Grupos de instâncias gerenciadas: Como atribuir portas nomeadas a grupos de instâncias gerenciadas

Restrições e orientações para grupos de instâncias

Lembre-se das seguintes restrições e orientações ao criar grupos de instâncias para os balanceadores de carga:

• Não coloque uma VM em mais de um grupo de instâncias com carga balanceada. Se uma VM for membro de dois ou mais grupos de instâncias não gerenciadas ou de um grupo de instâncias gerenciadas e de um ou mais grupos de instâncias não gerenciadas, o Google Cloud limitará o uso a um desses grupos de instâncias de cada vez como um back-end para um serviço de back-end específico.

  Se você precisar que uma VM participe de vários balanceadores de carga, use o mesmo grupo de instâncias como back-end em cada um dos serviços de back-end.

• Para balanceadores de carga de proxy, quando você quiser balancear o tráfego para portas diferentes, especifique as portas nomeadas necessárias em um grupo de instâncias e faça com que cada serviço de back-end se inscreva em uma porta nomeada exclusiva.

• É possível usar o mesmo grupo de instâncias como back-end para mais de um serviço de back-end. Nessa situação, os back-ends precisam usar modos de balanceamento compatíveis. Compatível significa que os modos de balanceamento precisam ser os mesmos ou precisam ser uma combinação de CONNECTION e RATE.

  As combinações de modo de balanceamento incompatíveis são as seguintes:

  • CONNECTION com UTILIZATION
  • RATE com UTILIZATION

  Veja o exemplo a seguir.

  • Você tem dois serviços de back-end: external-https-backend-service para um balanceador de carga de aplicativo externo e internal-tcp-backend-service para um balanceador de carga de rede de passagem interna.
  • Você está usando um grupo de instâncias chamado instance-group-a em internal-tcp-backend-service.
  • Em internal-tcp-backend-service, é preciso aplicar o modo de balanceamento CONNECTION, porque os balanceadores de carga de rede de passagem interna são compatíveis apenas com o modo de balanceamento CONNECTION.
  • Também será possível usar instance-group-a em external-https-backend-service se você aplicar o modo de balanceamento RATE em external-https-backend-service.
  • Não é possível usar instance-group-a em external-https-backend-service com o modo de balanceamento UTILIZATION.

• Para alterar o modo de balanceamento de um grupo de instâncias que serve como back-end para vários serviços de back-end:

  • Remova o grupo de instâncias de todos os serviços de back-end, exceto um.
  • Altere o modo de balanceamento do back-end para o serviço de back-end restante.
  • Adicione novamente o grupo de instâncias como back-end aos serviços de back-end restantes, se eles forem compatíveis com o novo modo de balanceamento.

• Se o grupo de instâncias estiver associado a vários serviços de back-end, cada um deles poderá fazer referência à mesma porta nomeada ou a uma porta nomeada diferente no grupo de instâncias.

• Recomendamos não adicionar um grupo de instâncias gerenciadas com escalonamento automático a mais de um serviço de back-end. Isso pode causar um escalonamento imprevisível e desnecessário de instâncias no grupo, especialmente se você usar a métrica de escalonamento automático Uso do balanceamento de carga HTTP.

  • Embora não seja recomendado, esse cenário pode funcionar se a métrica de escalonamento automático for Utilização da CPU ou uma Métrica do Cloud Monitoring que não esteja relacionada à capacidade de exibição do balanceador de carga. Usar uma dessas métricas de escalonamento automático pode impedir o escalonamento irregular.

Grupos de endpoints de rede por zona

Os endpoints de rede representam serviços pelo endereço IP ou uma combinação de endereço IP e porta, em vez de se referir a uma VM em um grupo de instâncias. Um grupo de endpoints de rede (NEG) é um agrupamento lógico de endpoints de rede.

Os NEGs zonais são recursos por zona que representam coleções de endereços IP ou combinações de endereço IP e porta para recursos do Google Cloud em uma única sub-rede.

Um serviço de back-end que usa NEGs zonais como back-ends distribui o tráfego entre aplicativos ou contêineres em execução em VMs.

Há dois tipos de endpoints de rede disponíveis para NEGs zonais:

• Endpoints GCE_VM_IP (compatíveis apenas com balanceadores de carga de rede de passagem interna e balanceadores de carga de rede de passagem com base em serviço de back-end).
• Endpoints GCE_VM_IP_PORT.

Para ver quais produtos são compatíveis com back-ends de NEG por zona, consulte Tabela: serviços de back-end e tipos de back-end compatíveis.

Para detalhes, consulte Visão geral de NEGs zonais.

Grupos de endpoints de rede de Internet

Os NEGs da Internet são recursos que definem back-ends externos. Um back-end externo é um back-end hospedado em infraestrutura local ou em infraestrutura fornecida por terceiros.

O NEG da Internet é uma combinação de um nome de host ou endereço IP e uma porta opcional. Há dois tipos de endpoints de rede disponíveis para NEGs da Internet: INTERNET_FQDN_PORT e INTERNET_IP_PORT.

Os NEGs da Internet estão disponíveis em dois escopos: global e regional. Para ver os produtos compatíveis com back-ends de NEG da Internet em cada escopo, consulte Tabela: serviços de back-end e tipos de back-end compatíveis.

Para mais detalhes, consulte Visão geral do grupo de endpoints de rede da Internet.

Grupos de endpoints de rede sem servidor

Um grupo de endpoints de rede (NEG) especifica um grupo de endpoints de back-end para um balanceador de carga. Um NEG sem servidor é um back-end que aponta para um serviço do Cloud Run, App Engine, Cloud Run functions ou gateway de API.

Um NEG sem servidor pode representar uma das seguintes opções:

• Um serviço ou um grupo de serviços do Cloud Run.
• Uma função ou um grupo de funções do Cloud Run functions.
• Um app do App Engine (Standard ou Flex), um serviço específico dentro de um app, uma versão específica de um app ou um grupo de serviços.
• Um gateway de API que fornece acesso aos serviços por meio de uma API REST consistente em todos os serviços, independentemente da implementação deles. Essa capacidade está em pré-lançamento.

Importante: para que um grupo de serviços esteja no mesmo NEG sem servidor, eles precisam ter um padrão de URL comum.

Para configurar um NEG sem servidor para aplicativos sem servidor que compartilham um padrão de URL, use uma máscara de URL. Uma máscara de URL é um modelo do esquema de URL (por exemplo, example.com/<service>). O NEG sem servidor vai usar esse modelo para extrair o nome <service> do URL da solicitação de entrada e encaminhar a solicitação para o serviço correspondente do Cloud Run, Cloud Functions ou App Engine com o mesmo nome.

Para ver quais balanceadores de carga são compatíveis com back-ends de NEG sem servidor, consulte Tabela: serviços de back-end e tipos de back-end compatíveis.

Para mais informações sobre NEGs sem servidor, consulte Visão geral de grupos de endpoints de rede sem servidor.

Vinculações de serviço

Uma vinculação de serviço é um back-end que estabelece uma conexão entre um serviço de back-end no Cloud Service Mesh e um serviço registrado no Diretório de serviços. Um serviço de back-end pode referir-se a várias vinculações de serviço. Um serviço de back-end com uma vinculação de serviço não pode se referir a nenhum outro tipo de back-end.

Back-ends mistos

As seguintes considerações se aplicam quando você adiciona diferentes tipos de back-ends a um único serviço de back-end:

• Um único serviço de back-end não pode usar simultaneamente grupos de instâncias e NEGs zonais.
• É possível usar uma combinação de diferentes tipos de grupos de instâncias no mesmo serviço de back-end. Por exemplo, um único serviço de back-end pode se referir a uma combinação de grupos de instâncias gerenciadas e não gerenciadas. Para informações completas sobre quais back-ends são compatíveis com quais serviços de back-end, consulte a tabela na seção anterior.
• Em determinados balanceadores de carga de proxy, é possível usar uma combinação de NEGs zonais (com endpoints GCE_VM_IP_PORT) e de conectividade híbrida (com endpoints NON_GCP_PRIVATE_IP_PORT ) para configurar a carga híbrida equilíbrio. Para ver quais balanceadores de carga têm esse recurso, consulte Tabela: serviços de back-end e tipos de back-end compatíveis.

Protocolo para os back-ends

Ao criar um serviço de back-end, especifique o protocolo usado para a comunicação com os back-ends. É possível especificar apenas um protocolo por serviço de back-end. Não é possível especificar um protocolo secundário para usar como substituto.

Os protocolos são válidos de acordo com o tipo de balanceador de carga ou se você estiver usando o Cloud Service Mesh.

Tabela: protocolo para os back-ends

Produto	Opções de protocolo do serviço de back-end
Balanceador de carga de aplicativo	HTTP, HTTPS, HTTP/2
Balanceador de carga de rede de proxy	TCP ou SSL Os balanceadores de carga de rede de proxy regionais dão suporte apenas a TCP.
Balanceador de carga de rede de passagem	TCP, UDP ou UNSPECIFIED
Cloud Service Mesh	HTTP, HTTPS, HTTP/2, gRPC, TCP

Se o protocolo de um serviço de back-end for alterado, os back-ends não poderão ser acessados pelos balanceadores de carga por alguns minutos.

Política de seleção de endereço IP

Este campo é aplicável aos balanceadores de carga de proxy. Use a política de seleção de endereço IP para especificar o tipo de tráfego enviado do serviço de back-end para os back-ends.

Ao selecionar a política de seleção de endereço IP, verifique se os back-ends oferecem suporte ao tipo de tráfego selecionado. Para mais informações, consulte Tabela: serviços de back-end e tipos de back-end compatíveis.

A política de seleção de endereço IP é usada quando você quer converter o serviço de back-end do balanceador de carga para aceitar um tipo de tráfego diferente. Para mais informações, consulte Converter de pilha única para pilha dupla.

É possível especificar os seguintes valores para a política de seleção de endereço IP:

Política de seleção de endereço IP	Descrição
Somente IPv4	Enviar tráfego IPv4 somente para os back-ends do serviço de back-end, independentemente do tráfego do cliente para o GFE. Somente as verificações de integridade IPv4 são usadas para conferir a integridade dos back-ends.
Preferir IPv6	Priorize a conexão IPv6 do back-end em vez da conexão IPv4 (desde que haja um back-end íntegro com endereços IPv6). As verificações de integridade monitoram periodicamente as conexões IPv6 e IPv4 dos back-ends. Primeiro, o GFE tenta a conexão IPv6. Se a conexão IPv6 estiver corrompida ou lenta, o GFE usará olhos felizes (link em inglês) para retornar e se conectar ao IPv4. Mesmo que uma das conexões IPv6 ou IPv4 não esteja íntegra, o back-end ainda será tratado como íntegro, e ambas as conexões poderão ser testadas pelo GFE, e os usuários poderão escolher qual usar.
Somente IPv6	Enviar tráfego IPv6 somente para os back-ends do serviço de back-end, independentemente do tráfego do cliente para o proxy. Somente as verificações de integridade IPv6 são usadas para conferir a integridade dos back-ends. Não há validação para verificar se o tipo de tráfego de back-end corresponde à política de seleção de endereço IP. Por exemplo, se você tiver back-ends somente para IPv4 e selecionar Only IPv6 como a política de seleção de endereço IP, a configuração resultará em back-ends não saudáveis porque o tráfego não consegue alcançar esses back-ends, e o código de resposta HTTP 503 é retornado aos clientes.

Criptografia entre o balanceador de carga e os back-ends

Para informações sobre criptografia entre o balanceador de carga e os back-ends, consulte Criptografia para os back-ends.

Distribuição de tráfego

Os valores dos campos a seguir no recurso de serviços de back-end determinam alguns aspectos do comportamento do back-end:

• Um modo de balanceamento define como o balanceador de carga mede a prontidão do back-end para novas solicitações ou conexões.
• Uma capacidade de destino define um número máximo de conexões, uma taxa máxima de destino ou a utilização máxima da CPU de destino.
• Um escalonador de capacidade ajusta a capacidade disponível geral sem modificar a capacidade desejada.

Modo de balanceamento

O modo de balanceamento determina se os back-ends de um balanceador de carga ou da Cloud Service Mesh podem lidar com tráfego adicional ou estão totalmente carregados.

O Google Cloud tem três modos de balanceamento:

• CONNECTION: determina como a carga é distribuída com base no número total de conexões que o back-end pode processar.
• RATE: o número máximo desejado de solicitações (consultas) por segundo (RPS, QPS). O RPS/QPS máximo desejado pode ser excedido se todos os back-ends atingirem ou ultrapassarem a capacidade.
• UTILIZATION: determina como a carga é distribuída com base na utilização de instâncias em um grupo de instâncias.

Modos de balanceamento disponíveis para cada balanceador de carga

Você define o modo de balanceamento ao adicionar um back-end ao serviço de back-end. Os modos de balanceamento disponíveis para um balanceador de carga dependem do tipo de balanceador de carga e dos back-ends.

Os balanceadores de carga de rede de passagem exigem o modo de balanceamento CONNECTION, mas não são compatíveis com a definição de uma capacidade desejada.

Os balanceadores de carga de aplicativo são compatíveis com um destes modos de balanceamento, RATE ou UTILIZATION, para back-ends de grupo de instâncias, o modo de balanceamento RATE para NEGs zonais com endpoints GCE_VM_IP_PORT e o modo de balanceamento RATE para NEGs híbridos (endpoints NON_GCP_PRIVATE_IP_PORT). Para qualquer outro tipo de back-end compatível, o modo de balanceamento precisa ser omitido.

• Para balanceadores de carga de aplicativo clássicos, uma região é selecionada com base na localização do cliente e se a região tem capacidade disponível, com base na capacidade de destino do modo de balanceamento de carga. Em seguida, dentro de uma região, a capacidade de destino do modo de balanceamento é usada para calcular as proporções de quantas solicitações precisam ser enviadas para cada back-end na região. Depois, as solicitações ou conexões são distribuídas de maneira aleatória entre instâncias ou endpoints no back-end.

• Para balanceadores de carga de aplicativo externos globais, uma região é selecionada com base no local do cliente e se a região tem capacidade disponível com base na capacidade de destino do modo de balanceamento de carga. Em uma região, a capacidade desejada do modo de balanceamento é usada para calcular as proporções de quantas solicitações precisam ser enviadas para cada back-end (grupo de instâncias ou NEG) na região. Use a política de balanceamento de carga de serviço (serviceLbPolicy) e a configuração de back-end preferencial para influenciar a seleção de qualquer back-end específico em uma região. Em cada grupo de instâncias ou NEG, a política de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído para instâncias ou endpoints no grupo.

• Para balanceadores de carga de aplicativo internos entre regiões, balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais, a capacidade desejada do modo de balanceamento é usada para calcular as proporções de quantas solicitações precisam ir para cada back-end (grupo de instâncias ou NEG) na região. Dentro de cada grupo de instâncias ou NEG, a política de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído para instâncias ou endpoints dentro do grupo. Somente a O balanceador de carga de aplicativo interno da região aceita o uso da política de balanceamento de carga de serviço (serviceLbPolicy) e das configurações de back-end preferencial para influenciar a seleção de back-ends específicos em uma região.

Os balanceadores de carga de rede de proxy são compatíveis com um destes modos de balanceamento, CONNECTION ou UTILIZATION, para back-ends de grupo de instâncias, o modo de balanceamento CONNECTION para NEGs zonais com endpoints GCE_VM_IP_PORT e o modo de balanceamento CONNECTION para NEGs híbridos (endpoints NON_GCP_PRIVATE_IP_PORT). Para qualquer outro tipo de back-end compatível, o modo de balanceamento precisa ser omitido.

• Para balanceadores de carga de proxy de rede externos globais, uma região é selecionada com base no local do cliente e se a região tem capacidade disponível com base na capacidade de destino do modo de balanceamento de carga. Em uma região, a capacidade desejada do modo de balanceamento é usada para calcular as proporções de quantas solicitações precisam ser enviadas para cada back-end (grupo de instâncias ou NEG) na região. Use a política de balanceamento de carga de serviço (serviceLbPolicy) e a configuração de back-end preferencial para influenciar a seleção de qualquer back-end específico em uma região. Em cada grupo de instâncias ou NEG, a política de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído para instâncias ou endpoints no grupo.

• Para balanceadores de carga de rede de proxy interno entre regiões, a região configurada é selecionada primeiro. Em uma região, a capacidade desejada do modo de balanceamento é usada para calcular as proporções de quantas solicitações precisam ser enviadas para cada back-end (grupo de instâncias ou NEG) na região. Use a política de balanceamento de carga de serviço (serviceLbPolicy) e a configuração de back-end preferencial para influenciar a seleção de qualquer back-end específico em uma região. Em cada grupo de instâncias ou NEG, a política de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído para instâncias ou endpoints no grupo.

• Para balanceadores de carga de proxy de rede, uma região é selecionada com base na localização do cliente e se a região tem capacidade disponível, com base na capacidade de destino do modo de balanceamento de carga. Em seguida, em uma região, a capacidade de destino do modo de balanceamento de carga é usada para calcular as proporções de quantas solicitações ou conexões precisam ser enviadas para cada back-end (grupo de instâncias ou NEG) na região. Depois que o balanceador de carga seleciona um back-end, as solicitações ou conexões são distribuídas de maneira aleatória entre instâncias de VM ou endpoints de rede em cada back-end individual.

• Para balanceadores de carga de rede de proxy externo regionais e balanceadores de carga de rede de proxy internos regionais, a capacidade desejada do modo de balanceamento de carga é usada para calcular as proporções de quantas solicitações precisam ir para cada back-end (grupo de instâncias ou NEG). Em cada grupo de instâncias ou NEG, a política de balanceamento de carga (localityLbPolicy) determina como o tráfego é distribuído para instâncias ou endpoints no grupo.

Veja na tabela a seguir um resumo dos modos de balanceamento de carga disponíveis para cada combinação de balanceador de carga e back-end.

Tabela: modos de balanceamento disponíveis para cada balanceador de carga

Balanceador de carga	Back-ends	Modos de balanceamento disponíveis
Balanceador de carga de aplicativo	Grupos de instâncias	RATE ou UTILIZATION
	NEGs zonais (endpoints GCE_VM_IP_PORT)	RATE
	NEGs híbridos (endpoints NON_GCP_PRIVATE_IP_PORT)	RATE
Balanceador de carga de rede de proxy Balanceador de carga de rede de proxy externo global Balanceador de carga de rede de proxy clássico Balanceador de carga de rede de proxy externo regional Balanceador de carga de rede de proxy interno regional Balanceador de carga de rede de proxy interno entre regiões	Grupos de instâncias	CONNECTION ou UTILIZATION
	NEGs zonais (endpoints GCE_VM_IP_PORT)	CONNECTION
	NEGs híbridos (endpoints NON_GCP_PRIVATE_IP_PORT)	CONNECTION
Balanceador de carga de rede de passagem	Grupos de instâncias	CONNECTION
	NEGs zonais (endpoints GCE_VM_IP)	CONNECTION

Observação:

Caso aconteça uma distribuição de tráfego ruim ao usar o modo de balanceamento UTILIZATION, recomendamos o uso de RATE.

O modo de balanceamento UTILIZATION depende da instância de VM ou do uso da CPU, além de outros fatores. Quando esses fatores variam, o balanceador de carga calcula as capacidades de maneira ineficaz, o que geralmente leva a uma distribuição ruim de tráfego entre grupos de back-end. Por outro lado, no modo de balanceamento RATE, o balanceador de carga envia solicitações para o grupo de back-end com a menor latência média nas solicitações recentes ou, para HTTP/2 e HTTP/3, as solicitações são enviados ao grupo de back-ends com o menor número de solicitações pendentes.

Se a utilização média de todas as VMs associadas a um serviço de back-end for inferior a 10%, o Google Cloud poderá preferir zonas específicas. Isso pode acontecer quando você usa grupos de instâncias gerenciadas por região, grupos de instâncias gerenciadas por zona em diferentes zonas e grupos de instâncias não gerenciadas por zona. Esse desequilíbrio por zona é resolvido automaticamente à medida que mais tráfego é enviado para o balanceador de carga.

Para mais informações, consulte gcloud compute backend-services add-backend.

Capacidade desejada

Cada modo de balanceamento tem uma capacidade de destino correspondente, que define um dos seguintes limites de destino:

• Número de conexões
• Taxa
• Utilização da CPU

Para cada modo de balanceamento, a capacidade desejada não é um disjuntor. Um balanceador de carga pode exceder o máximo em determinadas condições, por exemplo, se todos os endpoints ou VMs de back-end tiverem atingido o valor máximo.

Modo de balanceamento de conexão

Para o modo de balanceamento CONNECTION, a capacidade desejada define um número máximo de conexões abertas. Exceto para balanceadores de carga de rede de passagem interna e externos de passagem, é preciso usar uma das seguintes configurações para especificar um número máximo de conexões de destino:

• max-connections-per-instance (por VM): número médio desejado de conexões de uma VM.
• max-connections-per-endpoint (por endpoint em um NEG zonal): número médio de conexões desejado para um único endpoint.
• max-connections (por NEGs zonais e para grupos de instâncias por zona): número médio desejado de conexões para todo o NEG ou grupo de instâncias. Para grupos de instâncias gerenciadas por região, use max-connections-per-instance.

Na tabela a seguir, mostramos como o parâmetro de capacidade de destino define o seguinte:

• A capacidade desejada para todo o back-end
• A capacidade esperada para cada instância ou endpoint

Tabela:capacidade de destino para back-ends usando o modo de balanceamento CONNECTION

Tipo de back-end	Capacidade desejada
	Se você especificar	Capacidade para todo o back-end	Capacidade esperada por instância ou por endpoint
Grupo de instâncias N instâncias, H íntegro	max-connections-per-instance=X	X × N	(X × N)/H
NEG zonal N endpoints, H íntegro	max-connections-per-endpoint=X	X × N	(X × N)/H
Grupos de instâncias (exceto grupos de instâncias gerenciadas regionais) H instâncias íntegras	max-connections=Y	Y	Y/H

Conforme ilustrado, as configurações max-connections-per-instance e max-connections-per-endpoint são proxies para calcular um número máximo desejado de conexões para todo o grupo de instâncias ou todo o NEG zonal:

• Em um grupo de instâncias de VM com instâncias N, definir max-connections-per-instance=X tem o mesmo significado que definir max-connections=X × N.
• Em um NEG zonal com endpoints N, definir max-connections-per-endpoint=X tem o mesmo significado que definir max-connections=X × N.

Modo de balanceamento de taxa

Para o modo de balanceamento RATE, é preciso definir a capacidade desejada usando um dos parâmetros a seguir:

• max-rate-per-instance (por VM): forneça uma taxa média de solicitação HTTP desejada para uma única VM.
• max-rate-per-endpoint (por endpoint em um NEG zonal): forneça uma taxa média de solicitação HTTP desejada para um único endpoint.
• max-rate (por NEGs zonais e para grupos de instâncias zonais): forneça uma taxa média de solicitação de HTTP desejada para todo o NEG ou grupo de instâncias. No caso de grupos de instâncias gerenciadas por região, use max-rate-per-instance.

Na tabela a seguir, mostramos como o parâmetro de capacidade de destino define o seguinte:

• A capacidade desejada para todo o back-end
• A capacidade esperada para cada instância ou endpoint

Tabela:capacidade de destino para back-ends usando o modo de balanceamento RATE

Tipo de back-end	Capacidade desejada
	Se você especificar	Capacidade para todo o back-end	Capacidade esperada por instância ou por endpoint
Grupo de instâncias N instâncias, H íntegro	max-rate-per-instance=X	X × N	(X × N)/H
NEG zonal N endpoints, H íntegro	max-rate-per-endpoint=X	X × N	(X × N)/H
Grupos de instâncias (exceto grupos de instâncias gerenciadas regionais) H instâncias íntegras	max-rate=Y	Y	Y/H

Conforme ilustrado, as configurações max-rate-per-instance e max-rate-per-endpoint são proxies para calcular uma taxa máxima de solicitações HTTP desejadas para todo o grupo de instâncias ou NEG por zona:

• Em um grupo com instâncias N, a configurar max-rate-per-instance=X é o mesmo que configurar max-rate=X × N.
• Em um NEG zonal com endpoints N, configurar max-rate-per-endpoint=X é o mesmo que configurar max-rate=X × N.

Modo de balanceamento de utilização

O modo de balanceamento UTILIZATION não tem capacidade desejada obrigatória. Existem várias opções que dependem do tipo de back-end, como resumido na tabela da seção a seguir.

A capacidade de destino max-utilization só pode ser especificada por grupo de instâncias e não pode ser aplicada a uma determinada VM no grupo.

O modo de balanceamento UTILIZATION não tem capacidade desejada obrigatória. Ao usar o Console do Google Cloud para adicionar um grupo de instâncias de back-end a um serviço de back-end, o Console do Google Cloud define o valor de max-utilization como 0,8 (80%) se o modo de balanceamento UTILIZATION está selecionado. Além de max-utilization, o modo de balanceamento UTILIZATION é compatível com capacidades de destino mais complexas, como resumido na tabela da seção a seguir.

Como alterar o modo de balanceamento de um balanceador de carga

Para alguns balanceadores de carga ou configurações de balanceador de carga, não é possível alterar o modo de balanceamento porque o serviço de back-end tem apenas um modo de balanceamento possível. Para outros, dependendo do back-end usado, você pode alterar o modo de balanceamento porque mais de um modo está disponível para esses serviços.

Para ver quais modos de balanceamento são compatíveis com cada balanceador de carga, consulte Tabela: modos de balanceamento disponíveis para cada balanceador de carga.

Modos de balanceamento e configurações de capacidade desejadas

Para produtos que oferecem suporte a uma especificação de capacidade desejada, a capacidade desejada não é um disjuntor. Quando o máximo da capacidade desejada configurada é atingido em uma determinada zona, novas solicitações ou conexões são distribuídas para outras zonas que não estão processando solicitações ou conexões na capacidade desejada. Se todos os zonas tiverem atingido a capacidade desejada, novas solicitações ou conexões serão distribuídas por transbordamento.

Balanceadores de carga de aplicativos e Cloud Service Mesh

Esta tabela lista as combinações de modo de balanceamento e capacidade de destino disponíveis para Application Load Balancers e Cloud Service Mesh.

Tabela:combinações de modo de balanceamento e capacidade desejada para balanceadores de carga de aplicativo e Cloud Service Mesh

Tipo de back-end	Modo de balanceamento	Especificação da capacidade desejada
Grupos de instâncias não gerenciado por zona Gerenciado por zona gerenciado regional	RATE	É obrigatório especificar uma das seguintes opções: max-rate (somente com suporte de grupos de instâncias zonais) max-rate-per-instance  (compatível com todos os grupos de instâncias)
	UTILIZATION	Você tem a opção de especificar o seguinte: (1) max-utilization (2) max-rate  (somente com suporte de grupos de instâncias zonais) (3) max-rate-per-instance  (compatível com todos os grupos de instâncias) (1) e (2) juntos (1) e (3) juntos
NEGs por zona GCP_VM_IP_PORT NEGs híbridos NON_GCP_PRIVATE_IP_PORT	RATE	É obrigatório especificar uma das seguintes opções: max-rate por NEG zonal max-rate-per-endpoint

Balanceadores de carga de rede proxy

Esta tabela lista as combinações de modo de balanceamento e capacidade desejada disponíveis para balanceadores de carga de rede de proxy.

Tabela:combinações de modo de balanceamento e capacidade desejada para balanceadores de carga de rede proxy

Tipo de back-end	Modo de balanceamento	Especificação da capacidade desejada
Grupos de instâncias não gerenciado por zona Gerenciado por zona gerenciado regional	CONNECTION	É obrigatório especificar uma das seguintes opções: max-connections (somente com suporte de grupos de instâncias zonais) max-rate-per-instance  (compatível com todos os grupos de instâncias)
	UTILIZATION	Você tem a opção de especificar o seguinte: (1) max-utilization (2) max-connections  (somente com suporte de grupos de instâncias zonais) (3) max-connections-per-instance  (compatível com todos os grupos de instâncias) (1) e (2) juntos (1) e (3) juntos
NEGs por zona GCP_VM_IP_PORT NEGs híbridos NON_GCP_PRIVATE_IP_PORT	CONNECTION	É obrigatório especificar uma das seguintes opções: max-connections por NEG zonal max-connections-per-endpoint

Balanceadores de carga de rede de passagem

Esta tabela lista as combinações de modo de balanceamento e capacidade de destino disponíveis para balanceadores de carga de rede de passagem.

Tabela:combinações de modo de balanceamento e capacidade desejada para balanceadores de carga de rede de passagem

Tipo de back-end	Modo de balanceamento	Especificação da capacidade desejada
Grupos de instâncias não gerenciado por zona Gerenciado por zona gerenciado regional	CONNECTION	Não é possível especificar um número máximo de conexões.
NEGs por zona GCP_VM_IP	CONNECTION	Não é possível especificar um número máximo de conexões.

Escalonador de capacidade

Use o escalonador de capacidade para escalonar a capacidade desejada (uso máximo, taxa máxima ou conexões máximas) sem alterar a capacidade desejada.

Para a documentação de referência do Google Cloud, consulte:

• Google Cloud CLI: escalonador de capacidade
• API:
  • Regional
  • Global

É possível ajustar o escalonador de capacidade para escalonar a capacidade desejada efetiva sem mudar explicitamente um dos parâmetros --max-*.

É possível definir o escalonador de capacidade como um destes valores:

• O valor padrão é 1, o que significa que o grupo disponibiliza até 100% da capacidade configurada (dependendo de balancingMode).
• Um valor de 0 significa que o grupo está completamente drenado, oferecendo 0% da capacidade disponível. Não é possível definir uma configuração de 0 quando há apenas um back-end anexado ao serviço de back-end.
• Um valor de 0.1 (10%) a 1.0 (100%).

Os exemplos a seguir demonstram como o escalonador de capacidade funciona em conjunto com a configuração de capacidade de destino:

• Se o modo de balanceamento for RATE, o max-rate será definido como 80 RPS e o escalonador de capacidade for 1.0, a capacidade disponível também será de 80 RPS.

• Se o modo de balanceamento for RATE, o max-rate for definido como 80 RPS e o escalonador de capacidade for 0.5, a capacidade disponível será 40 RPS (0.5 times 80).

• Se o modo de balanceamento for RATE, o max-rate será definido como 80 RPS e o escalonador de capacidade for 0.0, a capacidade disponível será zero (0).

Observação: o escalonador de capacidade não é compatível com back-ends que não oferecem suporte a um modo de balanceamento. Isso inclui back-ends como NEGsda internet, NEGs sem servidor e NEGs de PSC.

Política de balanceamento de carga de serviço

Uma política de balanceamento de carga de serviço (serviceLbPolicy) é um recurso associado ao serviço de back-end do balanceador de carga. Ela permite personalizar os parâmetros que influenciam como o tráfego é distribuído nos back-ends associados a um serviço de back-end:

• Personalize o algoritmo de balanceamento de carga usado para determinar como o tráfego é distribuído entre regiões ou zonas.
• Ative a drenagem de capacidade automática para que o balanceador de carga possa drenar rapidamente o tráfego de back-ends não íntegros.

Além disso, é possível designar back-ends específicos como back-ends preferenciais. Esses back-ends precisam ser usados de acordo com a capacidade (ou seja, a capacidade desejada especificada pelo modo de balanceamento do back-end) antes que as solicitações sejam enviadas aos back-ends restantes.

Para saber mais, consulte Otimizações avançadas de balanceamento de carga com uma política de balanceamento de carga de serviço.

Política de localidade do balanceamento de carga

Em um serviço de back-end, a distribuição de tráfego é baseada em um modo de balanceamento e uma política de localidade de balanceamento de carga. O modo de balanceamento determina a fração de tráfego que precisa ser enviada para cada back-end (grupo de instâncias ou NEG). A política de localidade de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído entre instâncias ou endpoints em cada zona. Para grupos de instâncias gerenciadas regionais, a política de localidade se aplica a cada zona constituinte.

A política de localidade do balanceamento de carga é configurada por serviço de back-end. As seguintes configurações estão disponíveis:

• ROUND_ROBIN (padrão): essa é a configuração padrão da política de localidade de balanceamento de carga, em que o balanceador de carga seleciona um back-end saudável em ordem circular.

• LEAST_REQUEST: um algoritmo O(1) em que o balanceador de carga seleciona dois hosts íntegros aleatórios e escolhe o host com menos solicitações ativas.

• RING_HASH: esse algoritmo implementa hashing consistente em back-ends. O algoritmo tem a propriedade de que a adição ou remoção de um host de um conjunto de N hosts só afeta 1/N das solicitações.

• RANDOM: o balanceador de carga seleciona um host íntegro aleatório.

• ORIGINAL_DESTINATION: o balanceador de carga seleciona um back-end com base nos metadados de conexão do cliente. As conexões são abertas para o endereço IP de destino original especificado na solicitação de cliente recebida, antes que a solicitação seja direcionada ao balanceador de carga.

  ORIGINAL_DESTINATION não é compatível com balanceadores de carga de aplicativo externos globais e regionais.

• MAGLEV: implementa hashing consistente em back-ends e pode ser usado como substituto da política RING_HASH. O Maglev não é tão estável quanto o RING_HASH, mas tem tempos de build de pesquisa de tabela e tempos de seleção de host mais rápidos. Para mais informações sobre o Maglev, consulte o whitepaper do Maglev.

• WEIGHTED_MAGLEV: implementa o balanceamento de carga ponderado por instância usando os pesos informados pelas verificações de integridade. Se essa política for usada, o serviço de back-end precisa configurar uma verificação de integridade não legada baseada em HTTP, e as respostas de verificação de integridade precisam conter o campo de cabeçalho de resposta HTTP não padrão, X-Load-Balancing-Endpoint-Weight, para especificar os pesos por instância. As decisões de balanceamento de carga são tomadas com base nos pesos por instância informados nas últimas respostas de verificação de integridade processadas, desde que cada instância informe um peso válido ou informe UNAVAILABLE_WEIGHT. Caso contrário, o balanceamento de carga vai permanecer igual.

  O WEIGHTED_MAGLEV é compatível apenas com balanceadores de carga de rede de passagem externa. Para conferir um exemplo, consulte Configurar o balanceamento de carga ponderado para balanceadores de carga de rede de passagem externa.

A configuração de uma política de localidade de balanceamento de carga só é compatível com os serviços de back-end usados com os seguintes balanceadores de carga:

• Balanceador de carga de aplicativo externo global
• Balanceador de carga de aplicativo externo regional
• Balanceador de carga de aplicativo interno entre regiões
• Balanceador de carga de aplicativo interno regional
• Balanceador de carga de rede de passagem externa

O valor padrão efetivo da política de localidade de balanceamento de carga (localityLbPolicy) muda de acordo com as configurações de afinidade da sessão. Se a afinidade da sessão não estiver configurada, ou seja, se a afinidade da sessão permanecer com o valor padrão de NONE, o valor padrão de localityLbPolicy será ROUND_ROBIN. Se a afinidade da sessão for definida como um valor diferente de NONE, o valor padrão de localityLbPolicy será MAGLEV.

Para configurar uma política de localidade de balanceamento de carga, use o console do Google Cloud, o gcloud (--locality-lb-policy) ou a API (localityLbPolicy).

Cloud Service Mesh e distribuição de tráfego

O Cloud Service Mesh também usa recursos de serviço de back-end. Especificamente, o Cloud Service Mesh usa serviços de back-end com um esquema de balanceamento de carga que é INTERNAL_SELF_MANAGED. Para um serviço de back-end autogerenciado interno, a distribuição de tráfego é baseada na combinação de um modo com uma política de balanceamento de carga. O serviço de back-end direciona o tráfego para um back-end de acordo com o modo de balanceamento do back-end. Em seguida, o Cloud Service Mesh distribui o tráfego de acordo com uma política de balanceamento de carga.

Os serviços de back-end autogerenciados internos são compatíveis com os seguintes modos de balanceamento:

• UTILIZATION, se todos os back-ends forem grupos de instâncias;
• RATE, se todos os back-ends forem grupos de instâncias ou NEGs por zonas.

Se você escolher o modo de balanceamento RATE, precisará especificar uma taxa máxima, uma taxa máxima por instância ou uma taxa máxima por endpoint.

Para mais informações sobre o Cloud Service Mesh, consulte Conceitos do Cloud Service Mesh.

Subconfiguração de back-ends

A subconfiguração de back-end é um recurso opcional que melhora o desempenho e a escalonabilidade ao atribuir um subconjunto de back-ends a cada uma das instâncias de proxy.

A subconfiguração de back-end é compatível com os itens a seguir:

• Balanceador de carga de aplicativo interno regional
• Balanceador de carga de rede de passagem interna

Subconfiguração de back-end para balanceadores de carga de aplicativo internos regionais

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.

O balanceador de carga de aplicativo interno entre regiões não é compatível com a subconfiguração de back-end.

Nos balanceadores de carga de aplicativo internos regionais, a subconfiguração de back-end atribui automaticamente a cada instância de proxy apenas um subconjunto dos back-ends contidos no serviço de back-end regional. Por padrão, cada instância de proxy abre conexões com todos os back-ends contidos em um serviço de back-end. Quando o número de instâncias de proxy e os back-ends são grandes, abrir conexões a todos os back-ends pode causar problemas de desempenho.

Ao ativar a subconfiguração, cada proxy só abre conexões para um subconjunto de back-ends, reduzindo o número de conexões mantidas abertas para cada back-end. Reduzir o número de conexões abertas simultaneamente para cada back-end pode melhorar o desempenho dos back-ends e dos proxies.

O diagrama a seguir mostra um balanceador de carga com dois proxies. Sem a subconfiguração do back-end, o tráfego dos dois proxies é distribuído a todos os back-ends no serviço de back-end 1. Com a subconfiguração de back-end ativada, o tráfego de cada proxy é distribuído para um subconjunto dos back-ends. O tráfego do proxy 1 é distribuído aos back-ends 1 e 2, e o tráfego do proxy 2 é distribuído aos back-ends 3 e 4.

Comparação do balanceador de carga de aplicativo interno com e sem a subconfiguração de back-end (clique para ampliar).

Também é possível refinar o tráfego do balanceamento de carga para os back-ends definindo a política localityLbPolicy. Para mais informações, consulte Políticas de tráfego.

Para ler sobre a configuração de subconjuntos de back-end para balanceadores de carga de aplicativo internos, consulte Configurar subconjunto do back-end.

Advertências relacionadas à criação de subconjuntos de back-end para o balanceador de carga de aplicativo interno

• A subconfiguração do back-end foi projetada para garantir que todas as instâncias de back-end permaneçam bem usadas, mas pode introduzir um viés na quantidade de tráfego que cada back-end recebe. A configuração localityLbPolicy como LEAST_REQUEST é recomendada para serviços de back-end que são sensíveis ao balanceamento de carga do back-end.
• Ativar ou desativar a criação de subconfigurações interrompe as conexões existentes.
• A subconfiguração do back-end requer que a afinidade da sessão seja NONE (um hash de cinco tuplas). Outras opções de afinidade da sessão só poderão ser usadas se a subconfiguração do back-end estiver desativada. Os valores padrão das sinalizações --subsetting-policy e --session-affinity são NONE, e apenas uma delas por vez pode ser definida como um valor diferente.

Subagrupamento de back-end para o balanceador de carga de rede de passagem interna

O subconjunto de back-end de balanceadores de carga de rede de passagem interna permite escalonar o balanceador de carga de rede de passagem interna para aceitar um número maior de instâncias de VM de back-end por serviço de back-end interno.

Para informações sobre como a criação de subconfigurações afeta esse limite, consulte a seção "Serviços de back-end" de cotas e limites de recursos de balanceamento de carga.

Por padrão, a subconfiguração está desativada, o que limita o serviço de back-end a distribuir até 250 instâncias ou endpoints de back-end. Se seu serviço de back-end precisar ser compatível com mais de 250 back-ends, será possível ativar a criação de subconjuntos. Quando a criação de subconfiguraçãos é ativada, um subconjunto de instâncias de back-end é selecionado para cada conexão de cliente.

No diagrama a seguir, mostramos um modelo de diferença reduzida entre esses dois modos de operação.

Como comparar um balanceador de carga de rede de passagem interna com e sem o subconjunto (clique para ampliar)

Sem subconfiguração, o conjunto completo de back-ends íntegros é melhor utilizado e novas conexões de clientes são distribuídas entre todos os back-ends íntegros de acordo com a distribuição de tráfego. A criação implica restrições de balanceamento de carga, mas permite que o balanceador de carga aceite mais de 250 back-ends.

Para mais instruções de configuração, consulte Como configurar.

Advertências relacionadas à criação de subconjuntos de back-end para passagem do balanceador de carga de rede interno

• Quando a criação de subconfigurações estiver ativada, nem todos os back-ends receberão tráfego de um determinado remetente, mesmo quando o número de back-ends for pequeno.
• Para ver o número máximo de instâncias de back-end quando a subconfiguração estiver ativada, consulte a página de cotas.
• Somente a afinidade da sessão de cinco tuplas é compatível com a criação de subconfigurações.
• O espelhamento de pacotes não é compatível com a criação de subconjuntos.
• Ativar ou desativar a criação de subconfigurações interrompe as conexões existentes.
• Se os clientes no local precisarem acessar um balanceador de carga de rede interno, a subconfiguração poderá reduzir substancialmente o número de back-ends que recebem conexões dos clientes no local. Isso acontece porque a região do túnel do Cloud VPN ou do anexo da VLAN do Cloud Interconnect determina o subconjunto dos back-ends do balanceador de carga. Todos os endpoints do Cloud VPN e do Cloud Interconnect em uma região específica usam o mesmo subconjunto. Subconjuntos diferentes são usados em regiões distintas.

Preços de subconfiguração de back-end

Não há cobrança pelo uso da subconfiguração do back-end. Para mais informações, consulte Todos os preços de rede.

Afinidade da sessão

A afinidade da sessão permite controlar como o balanceador de carga seleciona back-ends para novas conexões de maneira previsível, desde que o número de back-ends saudáveis permaneça constante. Isso é útil para aplicativos que precisam que várias solicitações de um determinado usuário sejam direcionadas para o mesmo back-end ou endpoint. Esses aplicativos incluem servidores com estado usados pela veiculação de anúncios, jogos ou serviços com uso intenso do cache interno.

Os balanceadores de carga do Google Cloud fornecem afinidade de sessão com base no melhor esforço. Fatores como alterar os estados de verificação de integridade do back-end, adicionar ou remover back-ends, mudanças nos pesos do back-end (incluindo ativar ou desativar o balanceamento ponderado) ou mudanças na integridade do back-end, conforme medido pelo modo de balanceamento, podem interromper a afinidade da sessão.

O balanceamento de carga com afinidade da sessão funciona bem quando há uma distribuição razoavelmente grande de conexões únicas. Razoavelmente grande significa pelo menos várias vezes o número de back-ends. Testar um balanceador de carga com um pequeno número de conexões não vai resultar em uma representação precisa da distribuição de conexões de cliente entre back-ends.

Por padrão, todos os balanceadores de carga do Google Cloud selecionam back-ends usando um hash de cinco tuplas (--session-affinity=NONE), da seguinte maneira:

• Endereço IP de origem do pacote
• Porta de origem do pacote (se presente no cabeçalho do pacote)
• Endereço IP de destino do pacote
• Porta de destino do pacote (se presente no cabeçalho do pacote)
• Protocolo do pacote

Para balanceadores de carga de passagem, as novas conexões são distribuídas para instâncias de back-end ou endpoints íntegros (no pool ativo, se uma política de failover estiver configurada). É possível controlar o seguinte:

• Se as conexões estabelecidas persistem em back-ends não íntegros. Para mais detalhes, consulte Persistência de conexão em back-ends não íntegros na documentação do balanceador de carga de rede de passagem interna e Persistência de conexão em back-ends não íntegros na documentação do balanceador de carga de rede de passagem externa baseada em serviço.
• Se as conexões estabelecidas persistem durante o failover e o failover, se uma política de failover estiver configurada. Para detalhes, consulte Redução da conexão em failover e failback na documentação da passagem de carga de rede interna e Redução de conexão em failover e failback no back-end Documentação de um balanceador de carga de rede externo de passagem com base em serviço.
• Por quanto tempo as conexões estabelecidas podem persistir ao remover um back-end do balanceador de carga. Para mais detalhes, consulte Como ativar a diminuição da conexão.

Para balanceadores de carga baseados em proxy, desde que o número de instâncias ou endpoints de back-end íntegros permaneça constante e desde que a instância ou o endpoint de back-end selecionado anteriormente não esteja atingindo a capacidade, as solicitações ou conexões subsequentes vão para a mesma VM ou endpoint de back-end. A capacidade de destino do modo de balanceamento determina quando o back-end está no limite.

A tabela a seguir mostra as opções de afinidade da sessão compatíveis com cada produto:

Tabela:configurações de afinidade da sessão compatíveis

Produto	Opções de afinidade de sessão
Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo externo regional	Nenhum (NONE) IP do cliente (CLIENT_IP) Cookie gerado (GENERATED_COOKIE) Campo de cabeçalho (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Afinidade com estado baseada em cookies (STRONG_COOKIE_AFFINITY) Outras observações: O valor padrão efetivo da política de localidade de balanceamento de carga (localityLbPolicy) muda de acordo com as configurações de afinidade da sessão. Se a afinidade da sessão não estiver configurada, ou seja, se a afinidade da sessão permanecer com o valor padrão de NONE, o valor padrão de localityLbPolicy será ROUND_ROBIN. Se a afinidade da sessão for definida como um valor diferente de NONE, o valor padrão de localityLbPolicy será MAGLEV. No caso dos balanceadores de carga de aplicativo externos globais, não configure a afinidade da sessão se você estiver usando a divisão de tráfego ponderada. Ao fazer isso, a configuração da divisão de tráfego ponderada terá precedência.
Balanceador de carga de aplicativo clássico	Nenhum (NONE) IP do cliente (CLIENT_IP) Cookie gerado (GENERATED_COOKIE)
Balanceador de carga de aplicativo interno entre regiões Balanceador de carga de aplicativo interno regional	Nenhum (NONE) IP do cliente (CLIENT_IP) Cookie gerado (GENERATED_COOKIE) Campo de cabeçalho (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Afinidade com estado baseada em cookies (STRONG_COOKIE_AFFINITY) Outras observações: O valor padrão efetivo da política de localidade de balanceamento de carga (localityLbPolicy) muda de acordo com as configurações de afinidade da sessão. Se a afinidade da sessão não estiver configurada, ou seja, se a afinidade da sessão permanecer com o valor padrão de NONE, o valor padrão de localityLbPolicy será ROUND_ROBIN. Se a afinidade da sessão for definida como um valor diferente de NONE, o valor padrão de localityLbPolicy será MAGLEV. No caso dos balanceadores de carga de aplicativo internos, não configure a afinidade da sessão se você estiver usando a divisão de tráfego ponderada. Se você fizer isso, a configuração da divisão de tráfego ponderada terá precedência.
Balanceador de carga de rede de passagem interna	Nenhum (NONE) IP DO CLIENTE, sem destino (CLIENT_IP_NO_DESTINATION) IP do cliente, IP de destino (CLIENT_IP) IP do cliente, IP de destino, protocolo (CLIENT_IP_PROTO) IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo (CLIENT_IP_PORT_PROTO) Para informações específicas sobre o balanceador de carga de rede de passagem interna e a afinidade da sessão, consulte a Visão geral do balanceador de carga de rede de passagem interna.
Balanceador de carga de rede de passagem externa^*	Nenhum (NONE) IP do cliente, IP de destino (CLIENT_IP) IP do cliente, IP de destino, protocolo (CLIENT_IP_PROTO) IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo (CLIENT_IP_PORT_PROTO) Para informações específicas sobre o balanceador de carga de rede de passagem externa e a afinidade da sessão, consulte a Visão geral do balanceador de carga de rede externo de TCP/UDP externo.
Balanceador de carga de rede de proxy externo global Balanceador de carga de rede de proxy clássico Balanceador de carga de rede de proxy externo regional Balanceador de carga de rede de proxy interno regional Balanceador de carga de rede de proxy interno entre regiões	Nenhum (NONE) IP do cliente (CLIENT_IP)
Cloud Service Mesh	Nenhum (NONE) IP do cliente (CLIENT_IP) Cookie gerado (GENERATED_COOKIE) (somente protocolos HTTP) Campo de cabeçalho (HEADER_FIELD) (somente protocolos HTTP) Cookie HTTP (HTTP_COOKIE) (apenas protocolos HTTP)

^* Esta tabela documenta afinidades de sessão compatíveis com balanceadores de carga de rede de passagem externa baseados em serviço. Os balanceadores de carga de rede de passagem externa baseados em pool de destino não usam serviços de back-end. Em vez disso, defina a afinidade de sessão para balanceadores de carga de rede de passagem externa por meio do parâmetro sessionAffinity em Pools de destino.

Lembre-se do seguinte ao configurar a afinidade da sessão:

• Não confie na afinidade da sessão para fins de autenticação ou segurança. A afinidade da sessão, exceto a afinidade de sessão baseada em cookie com estado, foi projetada para quebrar sempre que o número de back-ends de exibição e íntegros muda. Para mais detalhes, consulte Perda de afinidade da sessão.

• Os valores padrão das sinalizações --session-affinity e --subsetting-policy são NONE, e apenas um por vez pode ser definido como um valor diferente.

Tipos de afinidade da sessão

As seções a seguir discutem os diferentes tipos de afinidade da sessão:

IP do cliente, sem afinidade de destino

Afinidade da sessão IP do cliente, sem destino (CLIENT_IP_NO_DESTINATION) é um hash de uma tupla com base apenas no endereço IP de origem de cada pacote recebido. Essa afinidade da sessão está disponível apenas para balanceadores de carga de rede de passagem interna.

Essa opção pode ser útil em situações em que você precisa que a mesma VM de back-end processe todos os pacotes de um cliente com base apenas no endereço IP de origem do pacote, sem considerar o endereço IP de destino do pacote. Essas situações geralmente surgem quando um balanceador de carga de rede de passagem interna é o próximo salto de uma rota estática. Para mais detalhes, consulte Afinidade da sessão e balanceadores de carga de rede de passagem interna de próximo salto.

Afinidade de IP do cliente

A afinidade da sessão do IP do cliente (CLIENT_IP) é um hash de duas tuplas criado a partir dos endereços IP de origem e destino do pacote. Afinidade da sessão de IP do cliente está disponível para todos os balanceadores de carga do Google Cloud que usam serviços de back-end. Os balanceadores de carga de rede de passagem externa chamam essa opção afinidade da sessão de IP do cliente, IP de destino.

Ao usar a afinidade de IP do cliente, lembre-se do seguinte:

• O endereço IP de destino do pacote só será igual ao endereço IP da regra de encaminhamento do balanceador de carga se o pacote for enviado diretamente para o balanceador de carga.

• Os pacotes roteados para um balanceador de carga de rede de passagem interna de próximo salto por uma rota estática têm endereços IP de destino que não correspondem ao endereço IP da regra de encaminhamento do balanceador de carga. Para detalhes importantes, consulte Afinidade de sessão e balanceadores de carga de rede de passagem interna.

• O endereço IP de origem do pacote pode não corresponder a um endereço IP associado ao cliente original se o pacote for processado por um sistema intermediário de NAT ou proxy antes de ser entregue a um balanceador de carga do Google Cloud. Em situações em que muitos clientes compartilham o mesmo endereço IP de origem efetivo, algumas VMs de back-end podem receber mais conexões ou solicitações do que outras.

Afinidade de cookie gerado

Quando você usa a afinidade baseada em cookie gerado, o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta à solicitação HTTP inicial.

O nome do cookie gerado varia de acordo com o tipo de balanceador de carga. Os seguintes produtos oferecem suporte a cookies gerados:

Produto	Nome do cookie
Balanceadores de carga de aplicativos externos globais	GCLB
Balanceadores de carga de aplicativo clássicos	GCLB
Balanceadores de carga de aplicativo externos regionais	GCILB
Balanceadores de carga de aplicativo internos entre regiões	GCILB
Balanceadores de carga de aplicativo internos regionais	GCILB
Cloud Service Mesh	GCILB

O atributo de caminho do cookie gerado é sempre um caractere de barra (/). Portanto, ele se aplica a todos os serviços de back-end no mesmo mapa de URL, desde que os outros serviços de back-end também usem a afinidade de cookie gerada.

É possível configurar o valor de time to live (TTL) do cookie entre 0 e 1,209,600 segundos (inclusive) usando o parâmetro de serviço de back-end affinityCookieTtlSec. Se affinityCookieTtlSec não for especificado, o valor de TTL padrão será 0.

Quando o cliente inclui o cookie afinidade da sessão gerado no cabeçalho de solicitação Cookie de solicitações HTTP, o balanceador de carga direciona essas solicitações para a mesma instância ou endpoint de back-end, desde que o cookie de afinidade de sessão permaneça válido. Isso é feito mapeando o valor do cookie para um índice que faz referência a uma instância de back-end específica ou um endpoint e garantindo que os requisitos afinidade da sessão do cookie gerado sejam atendidos.

Para usar a afinidade de cookie gerada, configure o modo de balanceamento e as configurações localityLbPolicy a seguir:

• Para grupos de instâncias de back-end, use o modo de balanceamento RATE.
• Para o localityLbPolicy do serviço de back-end, use RING_HASH ou MAGLEV. Se você não definir explicitamente o localityLbPolicy, o balanceador de carga vai usar MAGLEV como padrão implícito.

Para mais informações, consulte Perda de afinidade de sessão.

Afinidade do campo de cabeçalho

Com a afinidade do campo de cabeçalho, as solicitações são roteadas para os back-ends com base no valor do cabeçalho HTTP no campo consistentHash.httpHeaderName do serviço de back-end. Para distribuir solicitações em todos os back-ends disponíveis, cada cliente precisa usar um valor de cabeçalho HTTP diferente.

Os seguintes balanceadores de carga usam a afinidade do campo de cabeçalho:

• Cloud Service Mesh
• Balanceador de carga de aplicativo interno entre regiões
• Balanceador de carga de aplicativo externo global
• Balanceador de carga de aplicativo externo regional
• Balanceador de carga de aplicativo interno regional

A afinidade do campo de cabeçalho é aceita quando as seguintes condições são verdadeiras:

• A política de localidade do balanceamento de carga é RING_HASH ou MAGLEV.
• O consistentHash do serviço de back-end especifica o nome do cabeçalho HTTP (httpHeaderName).

Para saber quais produtos são compatíveis com a afinidade de campo de cabeçalho, consulte Tabela: Configurações de afinidade da sessão compatíveis.

Afinidade de cookie HTTP

Quando você usa a afinidade baseada em cookies HTTP, o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta à solicitação HTTP inicial. Você especifica o nome, o caminho e o time to live (TTL) do cookie.

Os produtos a seguir oferecem suporte à afinidade baseada em cookie HTTP:

• Todos os balanceadores de carga de aplicativos
• Cloud Service Mesh

É possível configurar os valores de TTL do cookie usando segundos, frações de segundo (em nanossegundos) ou segundos e frações de segundo (em nanossegundos) usando os seguintes parâmetros de serviço de back-end e valores válidos:

• consistentHash.httpCookie.ttl.seconds pode ser definido como um valor entre 0 e 315576000000 (inclusive).
• consistentHash.httpCookie.ttl.nanos pode ser definido como um valor entre 0 e 999999999 (inclusive). Como as unidades são nanossegundos, 999999999 significa .999999999 segundos.

Se consistentHash.httpCookie.ttl.seconds e consistentHash.httpCookie.ttl.nanos não forem especificados, o valor do parâmetro de serviço de back-end affinityCookieTtlSec será usado. Se affinityCookieTtlSec não for especificado, o valor de TTL padrão será 0.

Quando o cliente inclui o cookie afinidade da sessão HTTP no cabeçalho de solicitação Cookie de solicitações HTTP, o balanceador de carga direciona essas solicitações para a mesma instância de back-end ou endpoint, desde que o cookie de afinidade de sessão permaneça válido. Isso é feito mapeando o valor do cookie para um índice que faz referência a uma instância de back-end específica ou um endpoint e garantindo que os requisitos afinidade da sessão do cookie gerado sejam atendidos.

Para usar a afinidade de cookie HTTP, configure o modo de balanceamento e as configurações de localityLbPolicy a seguir:

• Para grupos de instâncias de back-end, use o modo de balanceamento RATE.
• Para o localityLbPolicy do serviço de back-end, use RING_HASH ou MAGLEV. Se você não definir explicitamente o localityLbPolicy, o balanceador de carga vai usar MAGLEV como padrão implícito.

Para mais informações, consulte Perda de afinidade de sessão.

Afinidade da sessão com estado baseada em cookies

Quando você usa a afinidade baseada em cookie stateful, o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta à solicitação HTTP inicial. Você especifica o nome, o caminho e o time to live (TTL) do cookie.

Todos os balanceadores de carga de aplicativo, exceto os balanceadores de carga de aplicativo clássicos, oferecem suporte à afinidade stateful baseada em cookies.

É possível configurar os valores de TTL do cookie usando segundos, frações de segundo (como nanossegundos) ou segundos e frações de segundo (como nanossegundos). A duração representada por strongSessionAffinityCookie.ttl não pode ser definida como um valor que represente mais de duas semanas (1.209.600 segundos).

O valor do cookie identifica uma instância ou um endpoint de back-end selecionado codificando a instância ou o endpoint selecionado no próprio valor. Enquanto o cookie for válido, se o cliente incluir o cookie afinidade da sessão no cabeçalho de solicitação Cookie de solicitações HTTP subsequentes, o balanceador de carga encaminhará essas solicitações para a instância ou o endpoint de back-end selecionado.

Ao contrário de outros métodos de afinidade da sessão:

• A afinidade baseada em cookie com estado não tem requisitos específicos para o modo de balanceamento ou para a política de localidade de balanceamento de carga (localityLbPolicy).

• A afinidade baseada em cookies com estado não é afetada quando o escalonamento automático adiciona uma nova instância a um grupo gerenciado de instâncias.

• A afinidade baseada em cookies com estado não é afetada quando o escalonamento automático remove uma instância de um grupo gerenciado de instâncias a menos que a instância selecionada seja removida.

• A afinidade baseada em cookies com estado não é afetada quando a recuperação automática remove uma instância de um grupo gerenciado de instâncias a menos que a instância selecionada seja removida.

Para mais informações, consulte Perda de afinidade de sessão.

Significado de TTL zero para afinidades baseadas em cookies

Todas as afinidades de sessão baseadas em cookies, como a afinidade de cookie gerado, a afinidade de cookie HTTP e a afinidade de cookie com estado, têm um atributo TTL.

Um TTL de zero segundos significa que o balanceador de carga não atribui um atributo Expires ao cookie. Nesse caso, o cliente trata o cookie como um cookie de sessão. A definição de uma sessão varia de acordo com o cliente:

• Alguns clientes, como navegadores da Web, retêm o cookie para toda a sessão de navegação. Isso significa que o cookie persiste em várias solicitações até que o aplicativo seja fechado.

• Outros clientes tratam uma sessão como uma única solicitação HTTP, descartando o cookie imediatamente depois.

Perda da afinidade da sessão

Todas as opções de afinidade da sessão para balanceadores de carga de aplicativo e balanceadores de carga de rede de proxy exigem o seguinte:

• A instância ou o endpoint de back-end selecionado precisa permanecer configurado como um back-end. A afinidade da sessão pode ser interrompida quando um dos seguintes eventos ocorre:

  • Você remove a instância selecionada do grupo de instâncias.

  • O escalonamento automático ou a recuperação automática do grupo de instâncias gerenciadas remove a instância selecionada do grupo gerenciado de instâncias.

  • Você remove o endpoint selecionado do NEG.

  • Remova o grupo de instâncias ou o NEG que contém a instância ou o endpoint selecionado do serviço de back-end.

• A instância de back-end ou o endpoint selecionado precisa permanecer saudável. A afinidade da sessão pode ser interrompida quando a instância ou o endpoint selecionado falha nas verificações de integridade.

• Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos, balanceadores de carga de rede de proxy externos globais e balanceadores de carga de rede de proxy clássicos, a afinidade da sessão pode ser interrompida se um Google Front End (GFE) de primeira camada diferente for usado para solicitações ou conexões subsequentes após a mudança no caminho de roteamento. Um GFE de primeira camada diferente poderá ser selecionado se o caminho de roteamento de um cliente na Internet para o Google mudar entre solicitações ou conexões.

Exceto a afinidade de sessão baseada em cookie stateful, todas as opções de afinidade da sessão para balanceadores de carga de aplicativo e balanceadores de carga de rede proxy têm os seguintes requisitos adicionais:

• O grupo de instâncias ou o NEG que contém a instância ou o endpoint selecionado não pode estar cheio, conforme definido pela capacidade desejada. Para grupos de instâncias gerenciadas por região, o componente zonal do grupo de instâncias que contém a instância selecionada não pode estar cheio. A afinidade de sessão pode ser interrompida quando o grupo de instâncias ou o NEG está cheio e outros grupos de instâncias ou NEGs não estão. Como a plenitude pode mudar de forma imprevisível ao usar o modo de balanceamento UTILIZATION, use o modo de balanceamento RATE ou CONNECTION para minimizar as situações em que a afinidade da sessão pode ser interrompida.

• O número total de instâncias ou endpoints de back-end configurados precisa permanecer constante. Quando pelo menos um dos eventos a seguir ocorre, o número de instâncias ou endpoints de back-end configurados muda, e a afinidade da sessão pode ser interrompida:

  • Adicionar novas instâncias ou endpoints:

    • Você adiciona instâncias a um grupo de instâncias no serviço de back-end.
    • O escalonamento automático de grupos de instâncias gerenciadas adiciona instâncias a um grupo de instâncias gerenciadas no serviço de back-end.
    • Você adiciona endpoints a um NEG existente no serviço de back-end.
    • Você adiciona grupos de instâncias ou NEGs não vazios ao serviço de back-end.

  • Remova qualquer instância ou endpoint, não apenas a instância ou o endpoint selecionado:

    • Você remove qualquer instância do back-end de um grupo de instâncias.
    • O escalonamento automático ou a recuperação automática do grupo de instâncias gerenciadas remove qualquer instância do back-end do grupo gerenciado de instâncias.
    • Você remove qualquer endpoint de um back-end de NEG.
    • Remova qualquer grupo de instâncias de back-end ou NEG existente e não vazio do serviço de back-end.

• O número total de instâncias ou endpoints de back-end íntegros precisa permanecer constante. Quando pelo menos um dos eventos a seguir ocorre, o número de instâncias ou endpoints de back-end íntegros muda, e a afinidade da sessão pode ser interrompida:

  • Qualquer instância ou endpoint passa na verificação de integridade, fazendo a transição de não íntegra para íntegra.
  • Qualquer instância ou endpoint falha na verificação de integridade, fazendo a transição de "integridade" para "não íntegra" ou timeout.

Tempo limite do serviço de back-end

A maioria dos balanceadores de carga do Google Cloud tem um tempo limite de serviço de back-end. O valor padrão é de 30 segundos. O intervalo completo permitido para valores de tempo limite é 1 a 2.147.483.647 segundos.

• Para balanceadores de carga de aplicativo externos e internos que usam o protocolo HTTP, HTTPS ou HTTP/2, o tempo limite do serviço de back-end é um tempo limite de solicitação e resposta para HTTP(S) tráfego.

  Para mais detalhes sobre o tempo limite do serviço de back-end de cada balanceador de carga, consulte os tópicos a seguir:

  • Para saber sobre balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo externos regionais, consulte Tempos limite e tentativas.
  • Para balanceadores de carga de aplicativos internos, consulte Tempos limite e tentativas.

• Para balanceadores de carga de rede de proxy externo, o tempo limite é de inatividade. Para permitir mais ou menos tempo antes que a conexão seja excluída, altere o valor de tempo limite. Esse tempo limite de inatividade também é usado para conexões WebSocket.

• Para balanceadores de carga de rede de passagem interna e externa de passagem, é possível definir o valor do tempo limite do serviço de back-end usando gcloud ou a API, mas o valor é ignorado. O tempo limite do serviço de back-end não tem significado para esses balanceadores de carga.

• Para a Cloud Service Mesh, o campo de tempo limite do serviço de back-end (especificado usando timeoutSec) não é compatível com serviços gRPC sem proxy. Para esses serviços, configure o tempo limite do serviço de back-end usando o campo maxStreamDuration. Isso ocorre porque o gRPC não é compatível com a semântica de timeoutSec, que especifica o tempo a aguardar até que um back-end retorne uma resposta completa após o envio da solicitação. O tempo limite do gRPC especifica a quantidade de tempo a aguardar desde o início do stream até que a resposta seja totalmente processada, incluindo todas as novas tentativas.

Verificações de integridade

Cada serviço de back-end com back-ends que são grupos de instâncias ou NEGs zonais precisa ter uma verificação de integridade associada. Os serviços de back-end que usam um NEG sem servidor ou um NEG global da Internet como back-end precisam não fazem referência a uma verificação de integridade.

É possível criar a verificação de integridade ao gerar um balanceador de carga usando o Console do Google Cloud, caso seja necessário, ou referir-se a uma verificação de integridade atual.

Ao criar um serviço de back-end usando o grupo de instâncias ou os back-ends de NEG por zona usando a Google Cloud CLI ou a API, é preciso referir-se a uma verificação de integridade atual. Consulte o guia do balanceador de carga na Visão geral das verificações de integridade para ver detalhes sobre o tipo e o escopo da verificação de integridade exigida.

Para mais informações, leia os seguintes documentos:

• Visão geral das verificações de integridade
• Como criar verificações de integridade
• Página de verificação de integridade de gcloud
• Página de verificação de integridade da API REST

Recursos adicionais ativados no recurso do serviço de back-end

Os recursos opcionais a seguir têm suporte de alguns serviços de back-end.

Cloud CDN

O Cloud CDN usa a rede de borda global do Google para exibir conteúdo mais próximo dos usuários, o que acelera seus sites e aplicativos. O Cloud CDN é ativado em serviços de back-end usados por balanceadores de carga de aplicativo externos globais. O balanceador de carga fornece os endereços IP do front-end e as portas que recebem solicitações, assim como os back-ends que respondem às solicitações.

Para mais detalhes, consulte a documentação do Cloud CDN.

O Cloud CDN é incompatível com o IAP. Elas não podem ser ativadas no mesmo serviço de back-end.

Google Cloud Armor

Se você usa um dos seguintes balanceadores de carga, pode adicionar mais proteção aos seus aplicativos ativando o Google Cloud Armor no serviço de back-end durante a criação do balanceador de carga:

• Balanceador de carga de aplicativo externo global
• Balanceador de carga de aplicativo clássico
• Balanceador de carga de rede de proxy externo global
• Balanceador de carga de rede de proxy clássico

Se você usar o Console do Google Cloud, siga um destes procedimentos:

• Selecione uma política de segurança do Google Cloud Armor existente.
• Aceite a configuração de uma política de segurança de limitação de taxa padrão do Google Cloud Armor com um nome personalizável, uma contagem de solicitações, um intervalo, uma chave e parâmetros de limitação de taxa. Se você usar o Google Cloud Armor com um serviço de proxy upstream, como um provedor de CDN, o Enforce_on_key precisará ser definido como um endereço IP XFF.
• Para desativar a proteção do Google Cloud Armor, selecione Nenhum.

IAP

Com o IAP, é possível estabelecer uma camada de autorização central para aplicativos acessados por HTTPS. Assim, você tem a opção de usar um modelo de controle de acesso no nível do aplicativo, em vez de contar apenas com os firewalls da rede. O IAP é compatível com determinados balanceadores de carga de aplicativo.

O IAP é incompatível com o Cloud CDN. Elas não podem ser ativadas no mesmo serviço de back-end.

Recursos avançados de gerenciamento de tráfego

Para saber mais sobre os recursos avançados de gerenciamento de tráfego configurados nos serviços de back-end e mapas de URL associados aos balanceadores de carga, consulte:

• Visão geral do gerenciamento de tráfego para balanceadores de carga internos de aplicativos
• Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos globais
• Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos regionais

API e referência gcloud

Para mais informações sobre as propriedades do recurso de serviço de back-end, consulte as seguintes referências:

• Recurso da API de serviço de back-end global

• Recurso da API de serviço de back-end regional

• Página gcloud compute backend-services, para serviços de back-end globais e regionais

A seguir

Para documentação relacionada e informações sobre como os serviços de back-end são usados no balanceamento de carga, reveja:

• Criar cabeçalhos personalizados
• Criar um balanceador de carga de aplicativo externo
• Visão geral do balanceador de carga de aplicativo externo
• Ativar a diminuição da conexão
• Criptografia em trânsito no Google Cloud

Para vídeos relacionados:

• Como configurar serviços de back-end para balanceadores de carga de aplicativos externos globais