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 no lugar de serviços de back-end.

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 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 ^2 Todos os NEGs sem servidor: um ou mais serviços do App Engine, Cloud Run ou Cloud Functions NEGs do Private Service Connect: se mais de um NEG for especificado, os NEGs precisam estar em regiões diferentes. Um NEG global da Internet para um back-end externo	EXTERNAL_MANAGED
Balanceador de carga de aplicativo clássico	Várias	Global^1	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 ^2 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	EXTERNAL
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 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 ^2 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 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 ^2 Um único NEG sem servidor (somente Cloud Run) Um único NEG 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 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 ^2 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 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 ^2	EXTERNAL_MANAGED
Balanceador de carga de rede de proxy clássico	1	Global^1	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 ^2	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 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 regionais da Internet para um back-end externo	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 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 regionais da Internet para um back-end externo	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 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	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	INTERNAL
Traffic Director	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

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

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

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 Traffic Director 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
• 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 do 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 obrigatórias em um grupo de instâncias e faça com que cada serviço de back-end se inscreva em uma porta com um nome exclusivo.

• É 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 Cloud Run, App Engine, Cloud Functions ou o serviço de 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 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 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 Traffic Director 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 Traffic Director.

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

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 do Traffic Director 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 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

Esta tabela explica todos os modos de balanceamento possíveis para um determinado balanceador de carga e tipo de back-end. Ela também mostra as configurações de capacidade disponíveis ou necessárias que você precisa especificar com o modo de balanceamento.

Tabela:especificação da capacidade desejada para os modos de balanceamento

Balanceador de carga	Tipo de back-end	Modo de balanceamento	Capacidade desejada
Balanceador de carga de aplicativo Traffic Director	Grupo de instâncias	RATE	É obrigatório especificar uma das seguintes opções: max-rate por grupo de instâncias zonais max-rate-per-instance  (grupos de instâncias por zona ou regionais)
		UTILIZATION	Você tem a opção de especificar o seguinte: (1) max-utilization (2) max-rate por grupo de instâncias zonais (3) max-rate-per-instance  (grupos de instâncias por zona ou regionais) (1) e (2) juntos (1) e (3) juntos
	NEG por zona (GCP_VM_IP_PORT)	RATE	É obrigatório especificar uma das seguintes opções: max-rate por NEG zonal max-rate-per-endpoint
	NEG híbrido (NON_GCP_PRIVATE_IP_PORT)	RATE	É obrigatório especificar uma das seguintes opções: max-rate por NEG híbrido max-rate-per-endpoint
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	Grupo de instâncias	CONNECTION	É obrigatório especificar uma das seguintes opções: max-connections por grupo de instâncias zonais max-connections-per-instance  (grupos de instâncias regionais ou zonais)
		UTILIZATION	Você tem a opção de especificar o seguinte: (1) max-utilization (2) max-connections por grupo de instâncias zonais (3) max-connections-per-instance  (grupos de instâncias regionais ou zonais) (1) e (2) juntos (1) e (3) juntos
	NEG por zona (GCP_VM_IP_PORT)	CONNECTION	É obrigatório especificar uma das seguintes opções: max-connections por NEG zonal max-connections-per-endpoint
	NEG híbrido (NON_GCP_PRIVATE_IP_PORT)	CONNECTION	É obrigatório especificar uma das seguintes opções: max-connections por NEG híbrido max-connections-per-endpoint
Balanceador de carga de rede de passagem	Grupo de instâncias	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.

Observação: no modo de balanceamento RATE ou UTILIZATION, quando a capacidade máxima desejada for alcançada em todos os back-ends, o balanceador de carga vai distribuir o tráfego proporcional à capacidade. O balanceador de carga não descarta solicitaçõ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

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.

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.

Traffic Director e distribuição de tráfego

O Traffic Director também usa recursos do serviço de back-end. Especificamente, o Traffic Director 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. Depois, o Traffic Director 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 Traffic Director, consulte Conceitos do Traffic Director.

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.
• A ativação e a desativação da 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.
• A ativação e a desativação da 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.
• Não é possível usar o protocolo de serviço de back-end UNSPECIFIED.

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 ou alterações na integridade do back-end, conforme medido pelo modo de balanceamento, podem quebrar a afinidade da sessão.

O equilíbrio 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 de back-end ou o endpoint 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) 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) 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^1	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)
Traffic Director	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 foi projetada para quebrar sempre que o número de back-ends de exibição e íntegros muda. As atividades que resultam na interrupção da afinidade de sessão incluem:

  • Adicionar grupos de instâncias de back-end ou NEGs ao serviço de back-end
  • Remover grupos de instâncias de back-end ou NEGs do serviço de back-end
  • Adicionar instâncias a um grupo de instâncias de back-end existente, o que acontece automaticamente quando você ativa o escalonamento automático com grupos de instâncias gerenciadas
  • Remover instâncias de um grupo de instâncias de back-end atual, o que acontece automaticamente quando você ativa o escalonamento automático com grupos de instâncias gerenciadas.
  • Como adicionar endpoints a um NEG de back-end atual
  • Como remover endpoints de um NEG de back-end atual
  • Quando um back-end íntegro falha na verificação de integridade e perde a integridade
  • Quando um back-end não íntegro passa na verificação de integridade e se torna íntegro
  • Para balanceadores de carga de passagem: durante o failover e o failover, se uma política de failover estiver configurada.
  • Para balanceadores de carga de proxy: quando um back-end está acima da capacidade máxima

• Não é recomendado usar uma afinidade de sessão que não seja None com o modo de balanceamento UTILIZATION. Isso ocorre porque as alterações na utilização da instância podem fazer com que o serviço de balanceamento de carga direcione novas solicitações ou conexões para VMs de back-end que estejam menos completas. Isso quebra a afinidade da sessão. Em vez disso, use o modo de balanceamento RATE ou CONNECTION para reduzir a diferença da afinidade da sessão. Para mais detalhes, consulte Perda de afinidade da sessão.

• Nos balanceadores de carga HTTP(S) externos e internos, a afinidade da sessão pode ser interrompida quando o endpoint ou a instância pretendida exceder o máximo de destino do modo de balanceamento. Veja o exemplo a seguir.

  • Um balanceador de carga tem um NEG e três endpoints.
  • Cada endpoint tem uma capacidade desejada de 1 RPS.
  • O modo de balanceamento é RATE.
  • No momento, cada endpoint está processando 1,1, 0,8 e 1,6 RPS, respectivamente.
  • Quando uma solicitação HTTP com afinidade para o último endpoint chega ao balanceador de carga, a afinidade da sessão reivindica o endpoint que está processando a 1,6 RPS.
  • A nova solicitação pode ir para o endpoint do meio com 0,8 RPS.

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

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

IP do cliente, sem afinidade de destino

IP do cliente, nenhuma afinidade de destino (CLIENT_IP_NO_DESTINATION) direciona solicitações do mesmo endereço IP de origem do cliente para a mesma instância de back-end.

Ao usar o IP do cliente, sem afinidade de destino, lembre-se do seguinte:

• IP do cliente, sem afinidade de destino, é um hash de uma tupla que consiste no endereço IP de origem do cliente.

• Se um cliente mudar de uma rede para outra, o endereço IP dele será alterado, resultando em afinidade corrompida.

IP do cliente, nenhuma afinidade de destino é apenas uma opção para balanceadores de carga de rede de passagem interna.

Afinidade de IP do cliente

A afinidade de IP do cliente (CLIENT_IP) direciona solicitações do mesmo endereço IP do cliente para a mesma instância de back-end. A afinidade de IP do cliente é uma opção para todos os balanceadores de carga do Google Cloud que usam serviços de back-end.

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

• A afinidade de IP do cliente é um hash de duas tuplas que consiste no endereço IP do cliente e no endereço IP da regra de encaminhamento do balanceador de carga que o cliente acessa.

• O endereço IP do cliente, como visto pelo balanceador de carga, pode não ser o cliente de origem se estiver por trás de NAT ou fizer solicitações por meio de um proxy. As solicitações feitas por meio de NAT ou proxy usam o endereço IP do roteador NAT ou do proxy como endereço IP do cliente. Isso pode fazer com que o tráfego se acumule desnecessariamente nas mesmas instâncias de back-end.

• Se um cliente mudar de uma rede para outra, o endereço IP dele será alterado, resultando em afinidade corrompida.

Para saber quais produtos oferecem suporte à afinidade de IP do cliente, consulte Tabela: configurações de afinidade de sessão compatíveis.

Afinidade de cookie gerado

Quando você define a afinidade de cookie gerado, o balanceador de carga emite um cookie na primeira solicitação. Em cada solicitação subsequente com o mesmo cookie, o balanceador de carga direciona a solicitação para a mesma VM ou o mesmo endpoint de back-end.

• Para balanceadores de carga de aplicativo externos globais, o cookie é chamado de GCLB.

• Para Traffic Director, balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos, o cookie é chamado de GCILB.

A afinidade baseada em cookie pode identificar com mais precisão um cliente para um balanceador de carga, em comparação com a afinidade baseada no IP do cliente. Exemplo:

1. Com a afinidade baseada em cookie, o balanceador de carga pode identificar de forma exclusiva dois ou mais sistemas clientes que compartilham o mesmo endereço IP de origem. Usando a afinidade baseada em IP do cliente, o balanceador de carga trata todas as conexões do mesmo endereço IP de origem como se fossem do mesmo sistema cliente.

2. Se um cliente alterar o endereço IP, a afinidade baseada em cookie permitirá que o balanceador de carga reconheça conexões subsequentes desse cliente em vez de tratar a conexão como nova. Um exemplo de quando um cliente altera o endereço IP é quando um dispositivo móvel muda de uma rede para outra.

Quando um balanceador de carga cria um cookie para a afinidade gerada baseada em cookie, ele define o atributo path do cookie como /. Se a correspondência de caminho do mapa de URL tiver vários serviços de back-end para um nome de host, todos os serviços de back-end compartilharão o mesmo cookie de sessão.

A duração do cookie HTTP gerado pelo balanceador de carga é configurável. É possível defini-la como 0 (padrão), o que significa que o cookie é apenas um cookie de sessão. Se preferir, defina a vida útil do cookie como um valor de 1 a 86400 segundos (24 horas).

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

Afinidade do campo de cabeçalho

O Traffic Director e os balanceadores de carga de aplicativo internos podem usar a afinidade de campo de cabeçalho quando as duas condições a seguir 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

O Traffic Director, o balanceador de carga de aplicativo externo global, o balanceador de carga de aplicativo externo regional, o balanceador de carga de rede de proxy externo global, o balanceador de carga de rede de proxy externo regional, o balanceador de carga de aplicativo interno entre regiões e o balanceador de carga de aplicativo interno regional podem usar a afinidade de cookie HTTP quando as duas afirmações a seguir forem verdadeiras:

• A política de localidade do balanceamento de carga é RING_HASH ou MAGLEV.
• O hash consistente do serviço de back-end especifica o nome do cookie HTTP.

A afinidade do cookie HTTP encaminha solicitações para VMs ou endpoints de back-end em um NEG com base no cookie HTTP nomeado na sinalização HTTP_COOKIE. Se o cliente não fornecer o cookie, o proxy gerará o cookie e o retornará ao cliente em um cabeçalho Set-Cookie.

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

Perda da afinidade da sessão

Independentemente do tipo de afinidade escolhido, um cliente pode perder a afinidade com um back-end nas seguintes situações:

• Se o grupo de instâncias de back-end ou o NEG por zona ficarem sem capacidade, conforme definido pela capacidade desejada do modo de balanceamento. Nessa situação, o Google Cloud direciona o tráfego para um grupo de instâncias de back-end diferente ou para o NEG por zona, que pode estar em uma zona diferente. É possível atenuar isso especificando a capacidade desejada correta para cada back-end com base no seu próprio teste.
• O escalonamento automático adiciona ou remove instâncias de um grupo de instâncias gerenciadas. Quando isso acontece, o número de instâncias no grupo de instâncias é alterado. Portanto, o serviço de back-end recalcula os hashes para a afinidade da sessão. É possível atenuar isso garantindo que o tamanho mínimo do grupo de instâncias gerenciadas possa lidar com uma carga típica. O escalonamento automático é realizado apenas durante aumentos inesperados na carga.
• Se uma VM de back-end ou um endpoint em um NEG falhar nas verificações de integridade, o balanceador de carga direcionará o tráfego para um back-end íntegro diferente. Consulte a documentação de cada balanceador de carga do Google Cloud para ver mais detalhes sobre como o balanceador de carga se comporta quando todos os back-ends falham suas verificações de integridade.
• Quando o modo de balanceamento UTILIZATION está em vigor para grupos de instâncias de back-end, a afinidade da sessão é interrompida devido a alterações na utilização do back-end. É possível atenuar isso usando o modo de balanceamento RATE ou CONNECTION compatível com o tipo de balanceador de carga.

Ao usar balanceadores de carga de aplicativo externos ou de proxy externo, tenha em mente os seguintes pontos adicionais:

• Se o caminho de roteamento de um cliente da Internet para o Google mudar entre solicitações ou conexões, um Google Front End (GFE) diferente poderá ser selecionado como o proxy. Isso pode interromper a afinidade da sessão.
• Quando você usa o modo de balanceamento UTILIZATION (especialmente sem uma capacidade desejada máxima definida), a afinidade da sessão pode ser interrompida quando o tráfego para o balanceador de carga for baixo. Use o modo de balanceamento RATE ou CONNECTION, conforme compatível com o balanceador de carga escolhido.

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 o Traffic Director, 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 de gerenciamento de tráfego

Os seguintes recursos são compatíveis apenas com alguns produtos:

• Políticas de balanceamento de carga (localityLbPolicy) exceto ROUND_ROBIN.
• Disjuntores, exceto campo maxRequests.
• Detecção de outlier

Esses recursos são compatíveis com os seguintes balanceadores de carga:

• Balanceador de carga de aplicativo externo global (não há possibilidade de quebra de circuito)

• Balanceador de carga de aplicativo externo regional

• Balanceador de carga de aplicativo interno entre regiões

• Balanceador de carga de aplicativo interno regional

• Traffic Director (mas não compatível com serviços gRPC sem proxy)

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