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 globais e regionais como um serviço nos aplicativos do App Hub.

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 balanceador de carga de aplicativo externo global ou buckets de back-end para balanceador de carga de aplicativo clássico.

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 gerenciado ou não gerenciado de instâncias ^* Todos os NEGs por zona: um ou mais NEGs zonal 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 recursos do App Engine, Cloud Run ou Cloud Run 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 recursos do App Engine, Cloud Run ou Cloud Run 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 gerenciado ou não gerenciado de instâncias ^* Todos os NEGs por zona: um ou mais NEGs zonal 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 para Cloud Run ou funções do Cloud Run de segunda geração) 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 gerenciado ou não gerenciado de instâncias ^* Todos os NEGs por zona: um ou mais NEGs zonal 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 para Cloud Run ou funções do Cloud Run de segunda geração) 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 gerenciado ou não gerenciado de instâncias ^* Todos os NEGs por zona: um ou mais NEGs zonal 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 para Cloud Run ou funções do Cloud Run de segunda geração) 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 zonal 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 gerenciado ou não gerenciado de instâncias ^* Todos os NEGs por zona: um ou mais NEGs zonal 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 gerenciado ou não gerenciado de instâncias ^* Todos os NEGs por zona: um ou mais NEGs zonal 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 gerenciado ou não gerenciado de instâncias ^* Todos os NEGs por zona: um ou mais NEGs zonal 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 EXTERNAL_MANAGED serviços de back-end a EXTERNAL regras de encaminhamento. 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 migrar os 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 externo global.

Como nomear o balanceador de carga

Para balanceadores de carga de rede de proxy e de passagem, o nome do balanceador de carga é sempre o mesmo do serviço de back-end. O comportamento de cada interface Google Cloud é o seguinte:

• Console doGoogle Cloud . Se você criar um balanceador de carga de rede de proxy ou de passagem usando o console Google Cloud , o serviço de back-end vai receber automaticamente o mesmo nome inserido para o balanceador de carga.
• CLI ou API do Google Cloud. Se você criar um balanceador de carga de rede de proxy ou de passagem usando a CLI gcloud ou a API, insira um nome de sua escolha ao criar o serviço de back-end. Esse nome do serviço de back-end é refletido no console Google Cloud como o nome do balanceador de carga.

Para saber como a nomenclatura funciona para balanceadores de carga de aplicativo, consulte Visão geral dos mapas de URL: nomenclatura do balanceador de carga.

Back-ends

Um back-end é um ou mais endpoints que recebem tráfego de um Google Cloud balanceador de carga, 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 modos de balanceamento compatíveis. Para mais informações, consulte Restrições e orientações para grupos de instâncias neste documento.
• NEG por zona
• NEG sem servidor
• NEG do Private Service Connect
• NEG da Internet
• NEG de conectividade híbrida
• 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 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

Considere o seguinte ao usar back-ends de grupo de instâncias:

• Uma instância de VM só pode pertencer a um grupo de instâncias com balanceamento de carga. Por exemplo, uma VM pode ser membro de dois grupos de instâncias não gerenciadas ou de um grupo gerenciado de instâncias e um grupo de instâncias não gerenciadas. Quando uma VM é membro de dois ou mais grupos de instâncias, apenas um deles pode ser referenciado por um ou mais serviços de back-end do balanceador de carga.

• O mesmo grupo de instâncias pode ser usado por dois ou mais serviços de back-end. Cada mapeamento entre um grupo de instâncias e um serviço de back-end pode usar um modo de balanceamento diferente, exceto para as combinações incompatíveis.

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

    • O modo de balanceamento UTILIZATION é incompatível com todos os outros modos. Se um grupo de instâncias for um back-end de vários serviços de back-end, ele precisará usar o modo de balanceamento UTILIZATION em todos os serviço de back-end.

    • O modo de balanceamento CUSTOM_METRICS é incompatível com todos os outros modos. Se um grupo de instâncias for um back-end de vários serviços de back-end, ele precisará usar o modo de balanceamento CUSTOM_METRICS em todos os serviço de back-end.

  • Como consequência das combinações incompatíveis de modo de balanceamento, se um grupo de instâncias usar o modo de balanceamento UTILIZATION ou CUSTOM_METRICS como um back-end para pelo menos um serviço de back-end, o mesmo grupo de instâncias não poderá ser usado como um back-end para um balanceador de carga de rede de passagem, porque eles exigem o modo de balanceamento CONNECTION.

• Não há um único comando que possa mudar o modo de balanceamento do mesmo grupo de instâncias em vários serviços de back-end. Para mudar o modo de balanceamento de um grupo de instâncias que é um back-end de dois ou mais serviços de back-end, use esta técnica:

  • Remova o grupo de instâncias como um back-end de todos os serviços de back-end, exceto um.
  • Altere o modo de balanceamento do grupo de instâncias para o serviço de back-end restante.
  • Adicione novamente o grupo de instâncias como back-end aos outros serviços de back-end.

Considere as práticas recomendadas a seguir, que oferecem opções mais flexíveis:

• Evite usar o mesmo grupo de instâncias como back-end para dois ou mais serviços de back-end. Em vez disso, use várias NEGs.

  • Ao contrário dos grupos de instâncias, uma VM pode ter um endpoint em dois ou mais NEGs com balanceamento de carga.

  • Por exemplo, se uma VM precisar ser simultaneamente um back-end de um balanceador de carga de rede de passagem e de um balanceador de carga de rede de proxy ou de um balanceador de carga de aplicativo, use vários NEGs com balanceamento de carga. Coloque um endpoint de VM em um NEG exclusivo compatível com cada tipo de balanceador de carga. Em seguida, associe cada NEG ao serviço de back-end do balanceador de carga correspondente.

• Não adicione um grupo gerenciado de instâncias com escalonamento automático a mais de um serviço de back-end ao usar a métrica de escalonamento automático Utilização do balanceamento de carga HTTP. Dois ou mais serviços de back-end que referenciam o mesmo grupo gerenciado de instâncias com escalonamento automático podem entrar em conflito, a menos que a métrica de escalonamento automático não esteja relacionada à atividade do balanceador de carga.

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 zonais que representam conjuntos de endereços IP ou combinações de endereço IP e porta para recursos doGoogle 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 recurso do Cloud Run, App Engine, Cloud Run functions ou gateway de API.

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

• Um recurso ou um grupo de recursos do Cloud Run.
• Uma função ou um grupo de funções do Cloud Run (anteriormente Cloud Run functions 2ª geração).
• Uma função ou um grupo de funções do Cloud Run (1ª geração)
• Um app do ambiente padrão ou flexível do App Engine, 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 recursos 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 Run 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

Esse campo é aplicável a 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 IPv4 e selecionar Only IPv6 como a política de seleção de endereço IP, a configuração vai resultar em back-ends não íntegros porque o tráfego não vai chegar a esses back-ends, e o código de resposta HTTP 503 será 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.

Modo de balanceamento, capacidade desejada e escalonador de capacidade

Para balanceadores de carga de aplicativo, Cloud Service Mesh e balanceadores de carga de rede de proxy, o modo de balanceamento, a capacidade de destino e o escalonador de capacidade são parâmetros fornecidos ao adicionar um back-end compatível a um serviço de back-end. Os balanceadores de carga usam esses parâmetros para gerenciar a distribuição de novas solicitações ou conexões para zonas que contêm back-ends compatíveis:

• O modo de balanceamento define como o balanceador de carga mede a capacidade. OGoogle Cloud tem os seguintes modos de balanceamento:
  • CONNECTION: define a capacidade com base no número de novas conexões TCP.
  • RATE: define a capacidade com base na taxa de novas solicitações HTTP.
  • IN-FLIGHT (prévia): define a capacidade com base no número de solicitações HTTP em andamento, em vez da taxa de solicitações HTTP. Use esse modo de balanceamento em vez de RATE se as solicitações levarem mais de um segundo para serem concluídas.
  • UTILIZATION: define a capacidade com base na utilização aproximada de CPU das VMs em uma zona de um grupo de instâncias.
  • CUSTOM_METRICS: define a capacidade com base em métricas personalizadas definidas pelo usuário.
• A capacidade desejada define o número de capacidade desejada.
  • A capacidade desejada não é um disjuntor.
  • Quando o uso da capacidade atinge a capacidade de destino, o balanceador de carga direciona novas solicitações ou conexões para uma zona diferente se os back-ends estiverem configurados em duas ou mais zonas.
  • Os balanceadores de carga de aplicativo externos globais, os balanceadores de carga de rede de proxy externos globais, os balanceadores de carga de aplicativo internos entre regiões e os balanceadores de carga de rede de proxy internos entre regiões também usam capacidade para direcionar solicitações a zonas em regiões diferentes, se você tiver configurado back-ends em mais de uma região.
  • Quando todas as zonas atingem a capacidade desejada, novas solicitações ou conexões são distribuídas por excesso proporcionalmente.
• O escalonador de capacidade oferece uma maneira de escalonar a capacidade desejada manualmente. Os valores do escalonador de capacidade são os seguintes:
  • 0: indica que o back-end foi completamente esvaziado. Não é possível usar um valor de 0 se um serviço de back-end tiver apenas um back-end.
  • 0.1 (10%) - 1.0 (100%): indica a porcentagem da capacidade de back-end em uso.

Os balanceadores de carga de rede de passagem usam simbolicamente o modo de balanceamento CONNECTION, mas não são compatíveis com uma capacidade desejada ou um escalonador de capacidade. Para mais informações sobre como os balanceadores de carga de rede de passagem distribuem novas conexões, consulte o seguinte:

• Distribuição de tráfego para balanceadores de carga de rede de passagem interna
• Distribuição de tráfego para balanceadores de carga de rede de passagem externa

Back-ends compatíveis

Para balanceadores de carga de aplicativo, Cloud Service Mesh e balanceadores de carga de rede de proxy, os seguintes tipos de back-ends são compatíveis com os parâmetros de modo de balanceamento, capacidade de destino e escalonador de capacidade:

• Back-ends de grupo de instâncias
• NEGs zonais com endpoints GCE_VM_IP_PORT
• NEGs de conectividade híbrida por zona

NEGs da Internet, NEGs sem servidor e NEGs do Private Service Connect não são compatíveis com os parâmetros de modo de balanceamento, capacidade de destino e escalonador de capacidade.

Modos de balanceamento para balanceadores de carga de aplicativo e Cloud Service Mesh

Os modos de balanceamento disponíveis para back-ends do balanceador de carga de aplicativo e do Cloud Service Mesh dependem do tipo de back-end compatível e de uma configuração de duração do tráfego (Visualização).

Configuração de duração do tráfego

Pré-lançamento

Este produto ou recurso está sujeito aos "Termos das Soluções Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os produtos e recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

Para back-ends do balanceador de carga de aplicativo e do Cloud Service Mesh, é possível especificar uma configuração de duração do tráfego. Essa configuração é exclusiva do mapeamento entre um back-end compatível e um serviço de back-end. A configuração de duração do tráfego tem dois valores válidos:

• SHORT: recomendado para solicitações HTTP respondidas com respostas de back-ends em menos de um segundo. Se você não especificar explicitamente uma duração de tráfego, o balanceador de carga vai operar como se você tivesse especificado SHORT.
• LONG: recomendado para solicitações HTTP em que o back-end precisa de mais de um segundo para gerar respostas.

Para definir explicitamente a duração do tráfego ao adicionar um back-end a um serviço de back-end, faça o seguinte:

• Execute o comando gcloud compute backend-services add-backend com a flag --traffic-duration.
• Crie ou atualize um serviço de back-end com o atributo trafficDuration.

Modos de balanceamento para tráfego de curta duração

Quando a configuração de duração do tráfego não é especificada ou é definida como SHORT(prévia), os modos de balanceamento disponíveis para balanceadores de carga de aplicativo e back-ends do Cloud Service Mesh dependem do tipo de back-end compatível.

Tabela:modos de balanceamento para balanceador de carga de aplicativo e back-ends do Cloud Service Mesh usando a configuração de curta duração do tráfego

Back-end compatível	Modo de balanceamento
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Grupos de instâncias
NEGs zonais com endpoints GCE_VM_IP_PORT
NEGs de conectividade híbrida por zona

Modos de balanceamento para tráfego de longa duração

Pré-lançamento

Este produto ou recurso está sujeito aos "Termos das Soluções Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os produtos e recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

Quando a configuração de duração do tráfego é LONG, os modos de balanceamento disponíveis para back-ends do balanceador de carga de aplicativo e do Cloud Service Mesh dependem do tipo de back-end compatível.

Tabela:modos de balanceamento para balanceador de carga de aplicativo e back-ends do Cloud Service Mesh usando a configuração de longa duração do tráfego

Back-end compatível	Modo de balanceamento
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Grupos de instâncias
NEGs zonais com endpoints GCE_VM_IP_PORT
NEGs de conectividade híbrida por zona

Modos de balanceamento para balanceadores de carga de rede proxy

Os modos de balanceamento disponíveis para back-ends de balanceadores de carga de rede de proxy dependem do tipo de back-end compatível.

Tabela:modos de balanceamento para balanceadores de carga de rede proxy

Back-end compatível	Modo de balanceamento
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Grupos de instâncias
NEGs zonais com endpoints GCE_VM_IP_PORT
NEGs de conectividade híbrida por zona

Especificações de capacidade desejada

As especificações de capacidade desejada são relevantes para balanceadores de carga de aplicativo, Cloud Service Mesh e back-ends de balanceadores de carga de rede de proxy que oferecem suporte a configurações de modo de balanceamento, capacidade desejada e escalonador de capacidade.

As especificações de capacidade desejada não são relevantes para balanceadores de carga de rede de passagem.

Modo de balanceamento de conexão

Os back-ends do balanceador de carga de rede de proxy podem usar o modo de balanceamento CONNECTION com um dos seguintes parâmetros de capacidade desejada obrigatórios:

Parâmetros de capacidade desejada para o modo de balanceamento CONNECTION

Parâmetro de capacidade desejada	Back-end compatível
	Grupos de instâncias zonais (gerenciadas ou não gerenciadas)	Grupos gerenciados de instâncias regionais	NEGs zonais com endpoints GCE_VM_IP_PORT	NEGs de conectividade híbrida por zona
max-connections Conexões TCP de destino por zona de back-end
max-connections-per-instance Conexões TCP de destino por instância de VM. O Cloud Load Balancing usa esse parâmetro para calcular as conexões TCP de destino por zona de back-end.
max-connections-per-endpoint Conexões TCP desejadas por endpoint do NEG. O Cloud Load Balancing usa esse parâmetro para calcular as conexões TCP de destino por zona de back-end.

Como usar o parâmetro max-connections

Quando você especifica o parâmetro max-connections, o valor fornecido define a capacidade de uma zona inteira.

• Para um grupo de instâncias zonal com N instâncias totais e h instâncias íntegras (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-connections como X, a capacidade desejada zonal será X.
  • O número médio de conexões por instância é X / h.

• Os grupos de instâncias gerenciadas regionais não são compatíveis com o parâmetro max-connections porque consistem em várias zonas. Em vez disso, use o parâmetro max-connections-per-instance.

• Para um NEG zonal com N endpoints totais e h endpoints íntegros (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-connections como X, a capacidade desejada zonal será X.
  • A média de conexões por endpoint é X / h.

Como usar o parâmetro max-connections-per-instance ou max-connections-per-endpoint

Quando você especifica o parâmetro max-connections-per-instance ou max-connections-per-endpoint, o balanceador de carga usa o valor fornecido para calcular uma capacidade por zona:

• Para um grupo de instâncias zonal com N instâncias totais e h instâncias íntegras (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-connections-per-instance como X, a capacidade zonal de destino será N * X. Isso equivale a definir max-connections como N * X.
  • O número médio de conexões por instância é (N * X) / h.

• Para um grupo gerenciado de instâncias regionais, se você definir max-connections-per-instance como X,o Google Cloud vai calcular uma capacidade de destino por zona para cada zona do grupo de instâncias. Em cada zona, se houver K instâncias totais e h instâncias íntegras (em que h≤ K), os cálculos serão os seguintes:

  • A capacidade de destino da zona é K * X.
  • O número médio de conexões por instância na zona é (K * X) / h.

• Para um NEG zonal com N endpoints totais e h endpoints íntegros (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-connections-per-endpoint como X, a capacidade zonal de destino será N * X. Isso equivale a definir max-connections como N * X.
  • A média de conexões por endpoint é (N * X) / h.

Modo de balanceamento de taxa

Os back-ends do balanceador de carga de aplicativo e do Cloud Service Mesh com uma configuração de duração do tráfego não especificada ou curta (prévia) podem usar o modo de balanceamento RATE com um dos seguintes parâmetros de capacidade de destino obrigatórios:

Tabela:parâmetros de capacidade desejada para o modo de balanceamento RATE

Parâmetro de capacidade desejada	Back-end compatível
	Grupos de instâncias zonais (gerenciadas ou não gerenciadas)	Grupos gerenciados de instâncias regionais	NEGs zonais com endpoints GCE_VM_IP_PORT	NEGs de conectividade híbrida por zona
max-rate Taxa de solicitação HTTP desejada por zona de back-end
max-rate-per-instance Taxa de solicitação HTTP desejada por instância de VM. O Cloud Load Balancing usa esse parâmetro para calcular a taxa de solicitações HTTP de destino por zona de back-end.
max-rate-per-endpoint Taxa de solicitação HTTP desejada por endpoint do NEG. O Cloud Load Balancing usa esse parâmetro para calcular a taxa de solicitações HTTP de destino por zona de back-end.

Como usar o parâmetro max-rate

Quando você especifica o parâmetro max-rate, o valor fornecido define a capacidade de uma zona inteira.

• Para um grupo de instâncias zonal com N instâncias totais e h instâncias íntegras (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-rate como X, a capacidade de destino zonal será de X solicitações por segundo.
  • A média de solicitações por segundo por instância é X / h.

• Os grupos de instâncias gerenciadas regionais não são compatíveis com o parâmetro max-rate porque consistem em várias zonas. Em vez disso, use o parâmetro max-rate-per-instance.

• Para um NEG zonal com N endpoints totais e h endpoints íntegros (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-rate como X, a capacidade de destino zonal será de X solicitações por segundo.
  • A média de solicitações por segundo por endpoint é X / h.

Como usar o parâmetro max-rate-per-instance ou max-rate-per-endpoint

Quando você especifica o parâmetro max-rate-per-instance ou max-rate-per-endpoint, o balanceador de carga usa o valor fornecido para calcular uma capacidade por zona:

• Para um grupo de instâncias zonal com N instâncias totais e h instâncias íntegras (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-rate-per-instance como X, a capacidade de destino zonal será de N * X solicitações por segundo. Isso equivale a definir max-rate como N * X.
  • A média de solicitações por segundo por instância é (N * X) / h.

• Para um grupo gerenciado de instâncias regionais, se você definir max-rate-per-instance como X, Google Cloud calculará uma capacidade de destino por zona para cada zona do grupo de instâncias. Em cada zona, se houver K instâncias totais e h instâncias íntegras (em que h≤ K), os cálculos serão os seguintes:

  • A capacidade de destino da zona é de K * X solicitações por segundo.
  • A média de solicitações por segundo por instância na zona é (K * X) / h.

• Para um NEG zonal com N endpoints totais e h endpoints íntegros (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-rate-per-endpoint como X, a capacidade de destino zonal será de N * X solicitações por segundo. Isso equivale a definir max-rate como N * X.
  • A média de solicitações por segundo por endpoint é (N * X) / h.

Modo de balanceamento em voo

Pré-lançamento

Este produto ou recurso está sujeito aos "Termos das Soluções Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os produtos e recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

Os back-ends do balanceador de carga de aplicativo e do Cloud Service Mesh com uma configuração de duração do tráfego longa podem usar o modo de balanceamento IN_FLIGHT com um dos seguintes parâmetros de capacidade de destino obrigatórios:

Tabela:parâmetros de capacidade desejada para o modo de balanceamento IN_FLIGHT

Parâmetro de capacidade desejada	Back-end compatível
	Grupos de instâncias zonais (gerenciadas ou não gerenciadas)	Grupos gerenciados de instâncias regionais	NEGs zonais com endpoints GCE_VM_IP_PORT	NEGs de conectividade híbrida por zona
max-in-flight-requests Número de destino de solicitações HTTP em andamento por zona de back-end
max-in-flight-requests-per-instance Número de destino de solicitações HTTP em andamento por instância de VM. O Cloud Load Balancing usa esse parâmetro para calcular o número de destino de solicitações HTTP em andamento por zona de back-end.
max-in-flight-requests-per-endpoint Número desejado de solicitações HTTP em andamento por endpoint do NEG. O balanceamento de carga usa esse parâmetro para calcular o número desejado de solicitações HTTP em andamento por zona de back-end.

Como usar o parâmetro max-in-flight-requests

Quando você especifica o parâmetro max-in-flight-requests, o valor fornecido define a capacidade de uma zona inteira.

• Para um grupo de instâncias zonal com N instâncias totais e h instâncias íntegras (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-in-flight-requests como X, a capacidade desejada zonal será de X solicitações HTTP em andamento.
  • O número médio de solicitações HTTP em andamento por instância é X / h.

• Os grupos gerenciados de instâncias regionais não são compatíveis com o parâmetro max-in-flight-requests porque consistem em várias zonas. Em vez disso, use o parâmetro max-in-flight-requests-per-instance.

• Para um NEG zonal com N endpoints totais e h endpoints íntegros (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-in-flight-requests como X, a capacidade desejada zonal será de X solicitações HTTP em andamento.
  • O número médio de solicitações HTTP em andamento por endpoint é X / h.

Como usar os parâmetros max-in-flight-requests-per-instance ou max-in-flight-requests-per-endpoint

Quando você especifica o parâmetro max-in-flight-requests-per-instance ou max-in-flight-requests-per-endpoint, o balanceador de carga usa o valor fornecido para calcular uma capacidade por zona:

• Para um grupo de instâncias zonal com N instâncias totais e h instâncias íntegras (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-in-flight-requests-per-instance como X, a capacidade de destino zonal será de N * X solicitações HTTP em andamento. Isso equivale a definir max-in-flight-requests como N * X.
  • A média de solicitações HTTP em andamento por instância é (N * X) / h.

• Para um grupo gerenciado de instâncias regionais, se você definir max-in-flight-requests-per-instance como X,o Google Cloud vai calcular uma capacidade de destino por zona para cada zona do grupo de instâncias. Em cada zona, se houver K instâncias totais e h instâncias íntegras (em que h≤ K), os cálculos serão os seguintes:

  • A capacidade de destino da zona é de K * X solicitações HTTP em andamento.
  • A média de solicitações HTTP em andamento por instância na zona é (K * X) / h.

• Para um NEG zonal com N endpoints totais e h endpoints íntegros (em que h ≤ N), os cálculos são os seguintes:

  • Se você definir max-in-flight-requests-per-endpoint como X, a capacidade de destino zonal será de N * X solicitações HTTP em andamento. Isso equivale a definir max-in-flight-requests como N * X.
  • A média de solicitações HTTP em andamento por endpoint é (N * X) / h.

Modo de balanceamento de utilização

Os back-ends de grupo de instâncias do balanceador de carga de aplicativo, do Cloud Service Mesh e do balanceador de carga de rede de proxy podem usar o modo de balanceamento UTILIZATION. Os back-ends de NEG não são compatíveis com esse modo de balanceamento.

O modo de balanceamento UTILIZATION depende do uso da CPU da VM, além de outros fatores. Quando esses fatores variam, o balanceador de carga pode calcular a utilização de uma forma que faz com que algumas VMs recebam mais solicitações ou conexões do que outras. Portanto, lembre-se do seguinte:

• Use somente o modo de balanceamento UTILIZATION com a afinidade da sessão definida como NONE. Se o serviço de back-end usar uma afinidade da sessão diferente de NONE, use os modos de balanceamento RATE, IN-FLIGHT ou CONNECTION.

• Se a utilização média das VMs em todos os grupos de instâncias for inferior a 10%, alguns balanceadores de carga vão preferir distribuir novas solicitações ou conexões para zonas específicas. Essa preferência zonal se torna menos comum quando a taxa de solicitação ou a contagem de conexões aumenta.

O modo de balanceamento UTILIZATION não tem uma configuração de capacidade desejada obrigatória, mas você pode definir uma capacidade desejada usando um dos parâmetros ou combinações de parâmetros descritos nas seções a seguir.

Parâmetros de capacidade de destino de utilização para back-ends do balanceador de carga de aplicativo e do Cloud Service Mesh com uma configuração de duração de tráfego não especificada ou curta

Os back-ends do balanceador de carga de aplicativo e do Cloud Service Mesh com uma configuração de duração do tráfego não especificada ou curta (prévia) podem usar o modo de balanceamento UTILIZATION com um dos seguintes parâmetros de capacidade de destino ou combinações de parâmetros:

Tabela:parâmetros e combinações de parâmetros de capacidade de destino do modo de balanceamento UTILIZATION para balanceadores de carga de aplicativo e back-ends do Cloud Service Mesh com uma configuração de duração de tráfego não especificada ou curta

Parâmetro de capacidade de destino ou combinação de parâmetros	Back-end compatível
	Grupos de instâncias zonais (gerenciadas ou não gerenciadas)	Grupos gerenciados de instâncias regionais	NEGs zonais com endpoints GCE_VM_IP_PORT	NEGs de conectividade híbrida por zona
max-utilization Uso da meta por zona de back-end
max-rate Taxa de solicitação HTTP desejada por zona de back-end
max-rate e max-utilization O destino é o primeiro a ser alcançado na zona de back-end: Uso pretendido da zona Taxa de solicitação HTTP de destino da zona
max-rate-per-instance Taxa de solicitação HTTP desejada por instância de VM. O Cloud Load Balancing usa esse parâmetro para calcular a taxa de solicitações HTTP de destino por zona de back-end.
max-rate-per-instance e max-utilization O destino é o primeiro a ser alcançado na zona de back-end: Uso pretendido da zona Taxa de solicitação HTTP de destino da zona (calculada com base na taxa de solicitação HTTP de destino por instância de VM das VMs na zona)

Para mais informações sobre os parâmetros de capacidade de destino max-rate e max-rate-per-instance, consulte Modo de balanceamento de taxa neste documento.

Parâmetros de capacidade de destino de utilização para back-ends do balanceador de carga de aplicativo e do Cloud Service Mesh com uma configuração de duração longa do tráfego

Os back-ends do balanceador de carga de aplicativo e do Cloud Service Mesh com uma configuração de duração de tráfego longa (pré-lançamento) podem usar o modo de balanceamento UTILIZATION com um dos seguintes parâmetros de capacidade de destino ou combinações de parâmetros:

Tabela:parâmetros de capacidade de destino do modo de balanceamento UTILIZATION e combinações de parâmetros para balanceador de carga de aplicativo e back-ends do Cloud Service Mesh com uma configuração de duração longa do tráfego (prévia)

Parâmetro de capacidade de destino ou combinação de parâmetros	Back-end compatível
	Grupos de instâncias zonais (gerenciadas ou não gerenciadas)	Grupos gerenciados de instâncias regionais	NEGs zonais com endpoints GCE_VM_IP_PORT	NEGs de conectividade híbrida por zona
max-utilization Uso da meta por zona de back-end
max-in-flight-requests Número de destino de solicitações HTTP em andamento por zona de back-end
max-in-flight-requests e max-utilization O destino é o primeiro a ser alcançado na zona de back-end: Uso pretendido da zona Número de destino da zona de solicitações HTTP em andamento
max-in-flight-requests-per-instance Número de destino de solicitações HTTP em andamento por instância de VM. O Cloud Load Balancing usa esse parâmetro para calcular o número de destino de solicitações HTTP em andamento por zona de back-end.
max-in-flight-requests-per-instance e max-utilization O destino é o primeiro a ser alcançado na zona de back-end: Uso pretendido da zona Número de solicitações HTTP em andamento de destino da zona (calculado com base no número de solicitações HTTP em andamento de destino por instância de VM das VMs na zona)

Para mais informações sobre os parâmetros de capacidade de destino max-in-flight-requests e max-in-flight-requests-per-instance neste documento, consulte Modo de balanceamento em andamento.

Parâmetros de capacidade de destino de utilização para balanceadores de carga de rede de proxy

Os back-ends de grupos de instâncias de balanceadores de carga de rede de proxy podem usar o modo de balanceamento UTILIZATION com um dos seguintes parâmetros de capacidade de destino ou combinações de parâmetros.

Tabela:parâmetros e combinações de parâmetros de capacidade desejada do modo de balanceamento UTILIZATION para back-ends do balanceador de carga de rede proxy

Parâmetro de capacidade de destino ou combinação de parâmetros	Back-end compatível
	Grupos de instâncias zonais (gerenciadas ou não gerenciadas)	Grupos gerenciados de instâncias regionais	NEGs zonais com endpoints GCE_VM_IP_PORT	NEGs de conectividade híbrida por zona
max-utilization Uso da meta por zona de back-end
max-connections Conexões TCP de destino por zona de back-end
max-connections e max-utilization O destino é o primeiro a ser alcançado na zona de back-end: Uso pretendido da zona Conexões TCP de destino da zona
max-connections-per-instance Conexões TCP de destino por instância de VM. O Cloud Load Balancing usa esse parâmetro para calcular as conexões TCP de destino por zona de back-end.
max-connections-per-instance e max-utilization O destino é o primeiro a ser alcançado na zona de back-end: Uso pretendido da zona Conexões TCP de destino da zona (calculadas com base nas conexões TCP de destino por instância de VM das VMs na zona)

Para mais informações sobre os parâmetros de capacidade de destino max-connections e max-connections-per-instance, consulte Modo de balanceamento de conexão neste documento.

Modo de balanceamento de métricas personalizadas

Os back-ends do balanceador de carga de aplicativo e do balanceador de carga de rede de proxy podem usar o modo de balanceamento CUSTOM_METRICS. Com as métricas personalizadas, é possível definir a capacidade de destino com base nos dados de aplicativo ou infraestrutura mais importantes para você. Para mais informações, consulte Métricas personalizadas para balanceadores de carga de aplicativos.

O modo de balanceamento CUSTOM_METRICS não tem uma configuração de capacidade desejada obrigatória, mas você pode definir uma capacidade desejada usando um dos parâmetros ou combinações de parâmetros de capacidade desejada descritos nas seções a seguir.

Parâmetros de capacidade desejada de métricas personalizadas para back-ends do balanceador de carga de aplicativo com uma configuração de duração de tráfego não especificada ou curta

Os back-ends do balanceador de carga de aplicativo com uma configuração de duração do tráfego não especificada ou curta (prévia) podem usar o modo de balanceamento CUSTOM_METRICS com um dos seguintes parâmetros de capacidade de destino ou combinações de parâmetros:

Tabela:parâmetros de capacidade de destino do modo de balanceamento CUSTOM_METRICS e combinações de parâmetros para back-ends do balanceador de carga de aplicativo com uma configuração de duração de tráfego não especificada ou curta

Parâmetro de capacidade de destino ou combinação de parâmetros	Back-end compatível
	Grupos de instâncias zonais (gerenciadas ou não gerenciadas)	Grupos gerenciados de instâncias regionais	NEGs zonais com endpoints GCE_VM_IP_PORT	NEGs de conectividade híbrida por zona
backends[].customMetrics[].maxUtilization Utilização da métrica personalizada de destino por zona de back-end
max-rate Taxa de solicitação HTTP desejada por zona de back-end
max-rate e backends[].customMetrics[].maxUtilization O destino é o primeiro a ser alcançado na zona de back-end: Utilização da métrica personalizada de destino da zona Taxa de solicitação HTTP de destino da zona
max-rate-per-instance Taxa de solicitação HTTP desejada por instância de VM. O Cloud Load Balancing usa esse parâmetro para calcular a taxa de solicitações HTTP de destino por zona de back-end.
max-rate-per-instance e backends[].customMetrics[].maxUtilization O destino é o primeiro a ser alcançado na zona de back-end: Utilização da métrica personalizada de destino da zona Taxa de solicitação HTTP de destino da zona (calculada com base na taxa de solicitação HTTP de destino por instância de VM das VMs na zona)
max-rate-per-endpoint Taxa de solicitação HTTP desejada por endpoint do NEG. O Cloud Load Balancing usa esse parâmetro para calcular a taxa de solicitações HTTP de destino por zona de back-end.
max-rate-per-endpoint e backends[].customMetrics[].maxUtilization O destino é o primeiro a ser alcançado na zona de back-end: Utilização da métrica personalizada de destino da zona Taxa de solicitação HTTP desejada da zona (calculada com base na taxa de solicitação HTTP desejada por endpoint do NEG dos endpoints na zona)

Para mais informações sobre os parâmetros de capacidade de destino max-rate, max-rate-per-instance e max-rate-per-endpoint neste documento, consulte Modo de balanceamento de taxa.

Parâmetros de capacidade de destino de métricas personalizadas para back-ends do balanceador de carga de aplicativo com uma configuração de duração longa do tráfego

Os back-ends do Application Load Balancer com uma configuração de duração do tráfego longa podem usar o modo de balanceamento CUSTOM_METRICS com um dos seguintes parâmetros de capacidade desejada ou combinações de parâmetros:

Tabela:parâmetros de capacidade de destino do modo de balanceamento CUSTOM_METRICS e combinações de parâmetros para back-ends do balanceador de carga de aplicativo com uma configuração de duração longa do tráfego (prévia)

Parâmetro de capacidade de destino ou combinação de parâmetros	Back-end compatível
	Grupos de instâncias zonais (gerenciadas ou não gerenciadas)	Grupos gerenciados de instâncias regionais	NEGs zonais com endpoints GCE_VM_IP_PORT	NEGs de conectividade híbrida por zona
backends[].customMetrics[].maxUtilization Utilização da métrica personalizada de destino por zona de back-end
max-in-flight-requests Número de destino de solicitações HTTP em andamento por zona de back-end
max-in-flight-requests e backends[].customMetrics[].maxUtilization O destino é o primeiro a ser alcançado na zona de back-end: Utilização da métrica personalizada de destino da zona Número de destino da zona de solicitações HTTP em andamento
max-in-flight-requests-per-instance Número de destino de solicitações HTTP em andamento por instância de VM. O Cloud Load Balancing usa esse parâmetro para calcular o número de destino de solicitações HTTP em andamento por zona de back-end.
max-in-flight-requests-per-instance e backends[].customMetrics[].maxUtilization O destino é o primeiro a ser alcançado na zona de back-end: Utilização da métrica personalizada de destino da zona Número de solicitações HTTP em andamento de destino da zona (calculado com base no número de solicitações HTTP em andamento de destino por instância de VM das VMs na zona)
max-in-flight-requests-per-endpoint Número desejado de solicitações HTTP em andamento por endpoint do NEG. O balanceamento de carga usa esse parâmetro para calcular o número de solicitações HTTP em andamento por zona de back-end.
max-in-flight-requests-per-endpoint e backends[].customMetrics[].maxUtilization O destino é o primeiro a ser alcançado na zona de back-end: Utilização da métrica personalizada de destino da zona Número desejado de solicitações HTTP em andamento da zona (calculado com base no número desejado de solicitações HTTP em andamento por endpoint do NEG dos endpoints na zona)

Para mais informações sobre os parâmetros de capacidade pretendida max-in-flight-requests, max-in-flight-requests-per-instance e max-flight-requests-per-endpoint, consulte o modo de balanceamento em andamento.

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.

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 gerenciados de instâncias regionais, a política de localidade se aplica a cada zona constituinte.

A política de localidade de 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 íntegro em ordem de round robin.

• WEIGHTED_ROUND_ROBIN: o balanceador de carga usa métricas personalizadas definidas pelo usuário para selecionar a instância ou o endpoint ideal no back-end para atender à solicitação.

• 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 para back-ends. O algoritmo tem a propriedade de que a adição ou remoção de um host de um conjunto de N hosts afeta apenas 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 do cliente recebida, antes de ela ser redirecionada para o balanceador de carga.

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

• MAGLEV: implementa hashing consistente para back-ends e pode ser usado como uma substituição da política RING_HASH. O Maglev não é tão estável quanto o RING_HASH, mas é mais rápido na criação de tabela de pesquisa e na seleção de host. Para mais informações sobre o Maglev, consulte o white paper do Maglev (em inglês).

• WEIGHTED_MAGLEV: implementa o balanceamento de carga ponderado por instância usando pesos informados pelas verificações de integridade. Se essa política for usada, o serviço de back-end precisará configurar uma verificação de integridade não legada baseada em HTTP, e as respostas de verificação de integridade devem 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 UNAVAILABLE_WEIGHT. Caso contrário, o balanceamento de carga vai permanecer com peso igual.

  WEIGHTED_MAGLEV é compatível apenas com balanceadores de carga de rede de passagem externa. Por 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 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 proxy externo global
• Balanceador de carga de rede de proxy externo regional
• Balanceador de carga de rede de proxy interno entre regiões
• Balanceador de carga de rede de proxy 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 doGoogle Cloud , o gcloud (--locality-lb-policy) ou a API (localityLbPolicy).

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

Pré-lançamento

Este produto ou recurso está sujeito aos "Termos das Soluções Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os produtos e recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases 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 interrompem as conexões atuais.
• 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 Serviços de back-end em "Cotas e limites".

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 interrompem as conexões atuais.
• 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 doGoogle Cloud fornecem afinidade da 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 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 saber mais sobre afinidade da sessão para balanceadores de carga de rede de passagem, consulte os seguintes documentos:

• Distribuição de tráfego para balanceadores de carga de rede de passagem externa
• Distribuição de tráfego para balanceadores de carga de rede de passagem interna

Para saber mais sobre afinidade da sessão para balanceadores de carga de aplicativo, consulte os seguintes documentos:

• Afinidade de sessão para balanceadores de carga de aplicativo externos
• Afinidade de sessão para balanceadores de carga de aplicativo internos

Para saber mais sobre afinidade da sessão para balanceadores de carga de rede de proxy, consulte os seguintes documentos:

• Afinidade de sessão para balanceadores de carga de rede de proxy externo
• Afinidade de sessão para balanceadores de carga de rede de proxy interno

Tempo limite do serviço de back-end

A maioria dos balanceadores de carga 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 e interno, o tempo limite configurado do serviço de back-end é o período em que o balanceador de carga mantém a conexão TCP aberta na ausência de dados transmitidos do cliente ou do back-end. Depois desse período sem transmissão de dados, o proxy fecha a conexão.

  • Valor padrão: 30 segundos
  • Intervalo configurável: de 1 a 2.147.483.647 segundos

• Para balanceadores de carga de rede de passagem interna e externa, é 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 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 não podem referenciar uma verificação de integridade.

É possível criar a verificação de integridade ao gerar um balanceador de carga usando o console 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.

Cloud Armor

Se você usa um dos seguintes balanceadores de carga, pode adicionar mais proteção aos seus aplicativos ativando o 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ê usa o console Google Cloud , faça o seguinte:

• Selecione uma política de segurança do Cloud Armor.
• Aceite a configuração de uma política de segurança de limitação de taxa padrão do 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 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 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 o seguinte:

• 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