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 em aplicativos do App Hub.

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

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.

Nome do 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 do Google Cloud , o serviço de back-end receberá automaticamente o mesmo nome que você inseriu para o balanceador de carga.
• Google Cloud CLI ou API. Se você criar um balanceador de carga de rede de proxy ou um balanceador de carga de rede 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 de serviço de back-end é refletido no console do Google Cloud como o nome do balanceador de carga.

Para saber como funciona a nomenclatura dos 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 balanceador de carga do Google Cloud , de um proxy Envoy configurado pelo Cloud Service Mesh ou de um cliente gRPC sem proxy. Há vários tipos de back-ends:

• Grupo de instâncias que contém instâncias de máquina virtual (VM). Um grupo de instâncias pode ser um grupo de instâncias gerenciadas (MIG), com ou sem escalonamento automático, ou pode ser um grupo de instâncias não gerenciadas. Mais de um serviço de back-end pode se referir a um grupo de instâncias, mas todos os serviços de back-end que fazem referência ao grupo de instâncias precisam usar 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 para mapeamento de portas
• Vinculações de serviço do Diretório de Serviços (pré-lançamento)
• Back-ends de serviço publicados (pré-lançamento)

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 IP externo

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

• Para balanceadores de carga de aplicativo externos globais e balanceadores de carga de rede de proxy externo: os clientes se comunicam com um Google Front End (GFE) de primeira camada que hospeda o endereço IP externo do balanceador de carga. O GFE de primeira camada se comunica com um GFE de segunda camada, localizado na mesma região que a VM ou o endpoint de back-end. Cada GFE de segunda camada se comunica com VMs ou endpoints de back-end de acordo com as seguintes regras:

  • Interface de rede com balanceamento de carga: a interface de rede para que o GFE de segunda camada envia o tráfego de solicitação depende do tipo de grupo de back-end:

    • Para back-ends de grupos de instâncias, o balanceador de carga sempre entrega pacotes à interface nic0 de cada VM de back-end. Essa regra é válida mesmo que a VM tenha várias interfaces de rede nas mesmas redes VPC ou em redes VPC diferentes.

    • Para back-ends de NEG por zona GCE_VM_IP_PORT, o balanceador de carga entrega pacotes a uma interface de destino do balanceador de carga.

  • Endereço IP de destino na interface com balanceamento de carga: o GFE de segunda camada envia tráfego de solicitação com pacotes que têm os seguintes endereços IP de destino:

    • Para back-ends de grupos de instâncias, o destino do pacote é o endereço IPv4 interno principal da interface de rede nic0 ou o primeiro endereço IPv6 /128 do intervalo IPv6 /96 atribuído à interface nic0, dependendo da política de seleção de endereço IP do serviço de back-end e do tipo de pilha da interface de rede.

    • Para back-ends de NEG zonal GCE_VM_IP_PORT, o destino do pacote corresponde a um endereço IP de endpoint especificado no NEG, dependendo da política de seleção de endereço IP do serviço de back-end e do tipo de pilha de interface de rede. Para endereços IP de endpoint válidos, consulte NEGs com endpoints GCE_VM_IP_PORT.

  A comunicação entre GFEs de segunda camada e back-ends é facilitada por meio de rotas especiais.

• Para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de rede de proxy externo regionais: os clientes se comunicam com um proxy Envoy gerenciado que hospeda o endereço IP externo do balanceador de carga. O proxy Envoy está localizado em uma sub-rede somente proxy. Cada proxy do Envoy se comunica com VMs ou endpoints de back-end de acordo com as seguintes regras:

  • Interface de rede com balanceamento de carga: a interface de rede para onde o proxy do Envoy envia o tráfego de solicitação depende do tipo de grupo de back-end:

    • Para back-ends de grupos de instâncias, o balanceador de carga sempre entrega pacotes à interface nic0 de cada VM de back-end. Essa regra é válida mesmo que a VM tenha várias interfaces de rede nas mesmas redes VPC ou em redes VPC diferentes.

    • Para back-ends de NEG por zona GCE_VM_IP_PORT, o balanceador de carga entrega pacotes a uma interface de destino do balanceador de carga.

  • Endereço IP de destino na interface com balanceamento de carga: o proxy do Envoy envia tráfego de solicitação com pacotes que têm os seguintes endereços IP de destino:

    • Para back-ends de grupos de instâncias, o destino do pacote é o endereço IPv4 interno principal da interface de rede nic0 ou o primeiro endereço IPv6 /128 do intervalo IPv6 /96 atribuído à interface nic0, dependendo da política de seleção de endereço IP do serviço de back-end e do tipo de pilha da interface de rede.

    • Para back-ends de NEG zonal GCE_VM_IP_PORT, o destino do pacote corresponde a um endereço IP de endpoint especificado no NEG, dependendo da política de seleção de endereço IP do serviço de back-end e do tipo de pilha de interface de rede. Para endereços IP de endpoint válidos, consulte NEGs com endpoints GCE_VM_IP_PORT.

• Para balanceadores de carga de rede de passagem externa globais e regionais: os clientes se comunicam diretamente com os back-ends usando a infraestrutura do Google Maglev. Os pacotes são roteados e entregues a back-ends com os endereços IP de origem e destino originais preservados. O balanceador de carga entrega pacotes para uma das seguintes interfaces de rede:

  • Para balanceadores de carga de rede de passagem externa global com back-ends de grupo de instâncias, o balanceador de carga sempre entrega pacotes para a interface nic0. Para mais informações, consulte Back-ends de grupos de instâncias e interfaces de rede.

  • Para balanceadores de carga de rede de passagem externa global com back-ends de NEG GCE_VM_IP, o balanceador de carga entrega pacotes a uma interface de destino do balanceador de carga.

  • Para balanceadores de carga de rede de passagem externa regionais baseados em serviço de back-end com back-ends de grupo de instâncias, o balanceador de carga sempre entrega pacotes para a interface nic0. Para mais informações, consulte Back-ends de grupos de instâncias e interfaces de rede.

  • Para balanceadores de carga de rede de passagem externa regionais baseados em serviço de back-end com back-ends de NEG GCE_VM_IP, o balanceador de carga entrega pacotes a uma interface de destino do balanceador de carga.

  • Para balanceadores de carga de rede de passagem externa regional baseados em pool de destino, o balanceador de carga sempre entrega pacotes para a interface nic0.

• Para balanceadores de carga de rede de passagem interna: os clientes se comunicam diretamente com os back-ends usando a pilha de virtualização de rede Andromeda. Os pacotes são roteados e entregues a back-ends com os endereços IP de origem e destino originais preservados. Para back-ends de grupos de instâncias e back-ends de NEG GCE_VM_IP, o balanceador de carga entrega pacotes a uma interface de rede na rede VPC do serviço de back-end:

  • A rede VPC do serviço de back-end pode ser especificada explicitamente ou herdada do primeiro grupo de instâncias de back-end ou NEG adicionado ao serviço de back-end ou da primeira regra de encaminhamento que faz referência ao serviço de back-end. Para mais informações, consulte Especificação de rede de serviços de back-end.

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 de 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 os balanceadores de carga de rede de passagem externa regional 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 do seguinte ao usar back-ends de grupo de instâncias:

• Uma instância de VM só pode pertencer a um único grupo de instâncias com carga balanceada. 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 de 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 de modo de balanceamento 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 de balanceamento. 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 de balanceamento. 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 back-end para pelo menos um serviço de back-end, o mesmo grupo de instâncias não poderá ser usado como back-end para o balanceador de carga de rede de passagem interna e o balanceador de carga de rede de passagem externa regional. Isso ocorre porque os back-ends do grupo de instâncias de balanceadores de carga de rede de passagem regionais (balanceador de carga de rede de passagem interno e balanceador de carga de rede de passagem externo regional) usam CONNECTION como modo de balanceamento.

• Não há um único comando que possa alterar o modo de balanceamento do mesmo grupo de instâncias em vários serviços de back-end. Se um grupo de instâncias for um back-end para dois ou mais serviços de back-end, e os modos de balanceamento precisarem ser atualizados para um novo modo incompatível com o atual, use a seguinte técnica:

  • Remova o grupo de instâncias como 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 um 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ários 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 de utilização do balanceamento de carga HTTP. Dois ou mais serviços de back-end que fazem referência ao 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 com todos os balanceadores de carga de passagem, exceto balanceadores de carga de rede de passagem externa regional baseados em pool de destino.

• Endpoints GCE_VM_IP_PORT que são compatíveis com todos os balanceadores de carga baseados em proxy (balanceadores de carga de aplicativo e de rede de proxy) e com o Cloud Service Mesh.

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.

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 ou serviços de back-end para um balanceador de carga. Um NEG sem servidor é um back-end que aponta para um aplicativo sem servidor, permitindo que você conecte cargas de trabalho sem servidor a balanceadores de carga de aplicativo. Ao configurar um balanceador de carga de aplicativo para seu aplicativo sem servidor, é possível usar recursos de balanceamento de carga, como um endereço IP de front-end dedicado, roteamento de mapa de URL e certificados SSL compartilhados entre tipos de back-end, Cloud CDN e Google Cloud Armor.

Um NEG sem servidor aponta para um recurso do Cloud Run, App Engine, Cloud Run functions ou gateway de API e pode representar um dos seguintes:

• Um recurso ou um grupo de recursos do Cloud Run.
• Uma função ou um grupo de funções do Cloud Run (antigo Cloud Run functions de 2ª geração).
• Uma função do Cloud Run (1ª geração) ou um grupo de funções.
• 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.

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, das funções do Cloud Run ou do 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 do Diretório de Serviços

Uma vinculação de serviço do Diretório de Serviços é um recurso de 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 referenciar várias vinculações de serviço do Diretório de Serviços. No entanto, um serviço de back-end com uma vinculação de serviço do Diretório de Serviços não pode se referir a nenhum outro tipo de recurso de back-end. Para mais informações, consulte Integração do Cloud Service Mesh com o Diretório de Serviços.

Back-ends de serviços publicados

Se as redes VPC do produtor e do consumidor pertencerem à mesma organização, será possível acessar um serviço publicado usando back-ends de serviço publicado. Os back-ends de serviço publicados permitem configurar balanceadores de carga compatíveis ou o Cloud Service Mesh para rotear o tráfego para serviços publicados por meio de endpoints do Private Service Connect. Para rotear o tráfego para o serviço publicado, associe um serviço de back-end regional a um anexo de serviço. Essa configuração é conhecida como back-end de serviço publicado.

Esses back-ends oferecem conectividade unificada, permitindo que balanceadores de carga compatíveis e o Cloud Service Mesh compartilhem endpoints do Private Service Connect. Para estabelecer essa conexão, forneça uma referência ao anexo de serviço do produtor. Os back-ends de serviço publicados também permitem o gerenciamento e a observabilidade avançados de tráfego, como a aplicação de políticas de segurança centralizadas e a coleta de métricas centralizadas.

Para mais informações sobre como configurar back-ends de serviço publicados para balanceadores de carga, consulte Acessar serviços publicados por meio de back-ends e endpoints de serviço publicados.

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 o balanceamento de carga híbrido. 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.

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

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

Este campo é aplicável 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:

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, balanceadores de carga de rede de proxy e balanceadores de carga de rede de passagem externa global, 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 (para balanceamento de carga HTTP) ou novas conexões (para balanceamento de carga de proxy TCP e balanceamento de carga de passagem global) para zonas que contêm back-ends compatíveis:

• O modo de balanceamento define como o balanceador de carga mede a capacidade. Em outras palavras, o modo de balanceamento é a unidade que define a capacidade.

  Google 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 por segundo (para balanceadores de carga de aplicativo) ou pacotes por segundo (para balanceadores de carga de rede de passagem externa global).
  • IN-FLIGHT: 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 da 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 de destino define o número da capacidade de destino.

  • A capacidade de destino 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 globais e entre regiões também usam a capacidade para direcionar solicitações ou novas conexões para zonas em diferentes regiões, se você tiver configurado back-ends em mais de uma região.
  • Quando todas as zonas atingirem a capacidade desejada, as novas solicitações ou conexões serão distribuídas por preenchimento excessivo proporcional.

• O escalonador de capacidade permite escalonar a capacidade de destino manualmente. Os valores do escalonador de capacidade são os seguintes:

  • 0: indica que o back-end foi completamente drenado. 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 do back-end que está em uso.

Back-ends compatíveis

Para balanceadores de carga baseados em proxy (balanceadores de carga de aplicativo e de rede de proxy) e Cloud Service Mesh, os seguintes tipos de back-ends são compatíveis com o modo de balanceamento, a capacidade de destino e os parâmetros de 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

Para balanceadores de carga de rede de passagem externa globais, 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

Os NEGs de Internet, sem servidor e 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.

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

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, siga um destes procedimentos:

• 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 curta duração de tráfego

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

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

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.

Modos de balanceamento para balanceadores de carga de rede de proxy

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

Modos de balanceamento para balanceadores de carga de rede de passagem

As tabelas a seguir descrevem os modos de balanceamento para balanceadores de carga de rede de passagem globais e regionais.

Modos de balanceamento para balanceadores de carga de rede de passagem externa global

Os modos de balanceamento disponíveis para back-ends de balanceador de carga de rede de passagem externa global dependem do tipo de back-end compatível.

Modos de balanceamento para balanceadores de carga de rede de passagem regionais

A tabela a seguir mostra os modos de balanceamento para balanceadores de carga de rede de passagem regionais: balanceador de carga de rede de passagem externa regional e balanceador de carga de rede de passagem interna.

Especificações de capacidade de destino para balanceadores de carga baseados em proxy

Nesta seção, abordamos as especificações de capacidade de destino para back-ends do balanceador de carga de aplicativo, do Cloud Service Mesh e do balanceador de carga de rede de proxy que oferecem suporte às configurações de modo de balanceamento, capacidade de destino e escalonador de capacidade.

Para saber mais sobre as especificações de capacidade de destino para balanceadores de carga de rede de passagem externa global, consulte Especificações de capacidade de destino para balanceadores de carga de rede de passagem externa global.

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 de destino necessários:

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 no total 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.
  • A média de conexões por instância é X / h.

• Os grupos gerenciados de instâncias 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 no total 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 de destino da zona será N * X. Isso equivale a definir max-connections como N * X.
  • A média de conexões por instância é (N * X) / h.

• Para um grupo gerenciado de instâncias regional, 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 um total de K instâncias e h instâncias íntegras (em que h≤ K), os cálculos serão os seguintes:

  • A capacidade de destino da zona é K * X.
  • A média 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 de destino da zona 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 de tráfego não especificada ou curta podem usar o modo de balanceamento RATE com um dos seguintes parâmetros de capacidade de destino obrigatórios:

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 no total 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 gerenciados de instâncias 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 no total 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 regional, se você definir max-rate-per-instance como X, o Google Cloud vai calcular uma capacidade desejada por zona para cada zona do grupo de instâncias. Em cada zona, se houver um total de K instâncias 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 trânsito

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

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 no total 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 de destino 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 de destino 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 no total 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 regional, 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 um total de K instâncias 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 grupos 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 maneira que leva algumas VMs a receber mais solicitações ou conexões do que outras. Portanto, lembre-se do seguinte:

• Use o modo de balanceamento UTILIZATION apenas 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 de todas as VMs associadas a um serviço de back-end for inferior a 10%, o balanceador de carga se tornará altamente sensível a pequenas variações de tráfego. Consequentemente, é esperado algum desequilíbrio de tráfego, e pequenas mudanças na carga podem fazer com que a distribuição de tráfego mude entre diferentes back-ends.

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

Parâmetros de capacidade de utilização de destino 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 de tráfego não especificada ou curta podem usar o modo de balanceamento UTILIZATION com um dos seguintes parâmetros de capacidade de destino ou combinações de parâmetros:

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 longa duração de 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 podem usar o modo de balanceamento UTILIZATION com um dos seguintes parâmetros de capacidade de destino ou combinações de parâmetros:

Parâmetros de capacidade de utilização de destino 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.

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. As métricas personalizadas permitem 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 aplicativo.

O modo de balanceamento CUSTOM_METRICS não tem uma configuração de capacidade desejada obrigatória, mas é possível definir uma capacidade desejada usando um dos parâmetros de capacidade desejada 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 curta ou não especificada

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

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

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

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

Especificações de capacidade de destino para balanceadores de carga de rede de passagem externa global

As especificações de capacidade de destino são relevantes apenas para back-ends de balanceadores de carga de rede de passagem externa global. Eles não são relevantes para back-ends de balanceadores de carga de rede de passagem regional.

Modo de balanceamento de taxa

Os back-ends de um balanceador de carga de rede de passagem externa global podem usar o modo de balanceamento RATE com um dos seguintes parâmetros de capacidade de destino obrigatórios:

Modo de balanceamento de utilização

Os balanceadores de carga de rede de passagem externa globais com back-ends de grupo de instâncias 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 não tem uma configuração de capacidade desejada obrigatória, mas é possível definir uma capacidade desejada usando um dos parâmetros de capacidade desejada ou combinações de parâmetros de capacidade desejada, conforme descrito nesta seção.

Se você omitir max-utilization e max-rate-per-instance, a capacidade da zona de back-end será determinada apenas pela utilização de destino da zona (max-utilization) usando o valor padrão de 0,8 (80%), sem taxa de pacotes de destino.

Back-ends preferenciais

É 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 quais balanceadores de carga são compatíveis com back-ends preferenciais, consulte Otimizações avançadas de balanceamento de carga.

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 de um balanceador de carga de aplicativo, balanceador de carga de rede de proxy ou Cloud Service Mesh. Para mais informações, consulte:

• Otimizações avançadas de balanceamento de carga para balanceadores de carga de aplicativo e balanceadores de carga de rede proxy

• Visão geral do balanceamento de carga avançado para o Cloud Service Mesh.

Política de localidade do balanceamento de carga

Em todos os balanceadores de carga, exceto os balanceadores de carga de rede de passagem regional, a distribuição de tráfego é baseada em um modo de balanceamento de carga e uma política de localidade do balanceamento de carga. O modo de balanceamento de carga 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 do 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.

Para balanceadores de carga de rede de passagem externa regionais, a distribuição de tráfego é baseada apenas na política de localidade de balanceamento de carga. Ela determina como o tráfego é distribuído entre todas as instâncias de back-end ou endpoints (de todos os grupos de instâncias ou NEGs do serviço de back-end).

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): é 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 round-robin.

• 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 que a solicitação seja redirecionada para o balanceador de carga.

• MAGLEV: implementa hashing consistente para back-ends e pode ser usado como um substituto para a política RING_HASH. O Maglev não é tão estável quanto o RING_HASH, mas é mais rápido na criação de tabelas de pesquisa e na seleção de back-ends. Para mais informações sobre o Maglev, consulte o whitepaper do Maglev.

• WEIGHTED_MAGLEV: implementa o balanceamento de carga ponderado por instância para balanceadores de carga de rede de passagem externa regionais usando pesos informados por 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 da verificação de integridade precisarão 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.

  Para ver um exemplo, consulte Configurar o balanceamento de carga ponderado para balanceadores de carga de rede de passagem externa regionais.

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

Para balanceadores de carga baseados em proxy (balanceadores de carga de aplicativo e balanceadores de carga de rede proxy), 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 balanceadores de carga de rede de passagem, MAGLEV é o valor padrão da política de localidade de balanceamento de carga (localityLbPolicy).

Para configurar uma política de localidade de balanceamento de carga, use o console doGoogle Cloud , a 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 balanceador de carga.

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

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.

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

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

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

• A subconfiguração do back-end foi projetada para garantir que todas as instâncias de back-end permaneçam bem usadas, mas pode introduzir um viés na quantidade de tráfego que cada back-end recebe. A configuração localityLbPolicy como LEAST_REQUEST é recomendada para serviços de back-end que são sensíveis ao balanceamento de carga do back-end.
• Ativar ou desativar a criação de subconjuntos interrompe 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 a coluna Cotas e limites em Serviços de back-end.

Por padrão, a subconfiguração fica desativada, o que limita o serviço de back-end à distribuição para 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.

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

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

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

• Quando a criação de subconfigurações estiver ativada, nem todos os back-ends receberão tráfego de um determinado remetente, mesmo quando o número de back-ends for pequeno.
• Para ver o número máximo de instâncias de back-end quando a subconfiguração estiver ativada, consulte a página de cotas.
• Somente a afinidade da sessão de cinco tuplas é compatível com a criação de subconfigurações.
• O espelhamento de pacotes não é compatível com a criação de subconjuntos.
• Ativar ou desativar a criação de subconjuntos interrompe 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, alterações nos pesos do back-end (incluindo ativar ou desativar o balanceamento ponderado) ou alterações na integridade do back-end, conforme medido pelo modo de balanceamento, podem quebrar a afinidade da sessão.

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

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

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

Para saber mais sobre a 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 regionais

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

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

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

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

• Afinidade da sessão para balanceadores de carga de rede de proxy externo
• Afinidade da 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 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 e balanceadores de carga de rede de proxy 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 que esse tempo passar sem que nenhum dado seja transmitido, o proxy fechará a conexão.

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

• Para balanceadores de carga de rede 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 de passagem.

• 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 precisam não fazem referência a uma verificação de integridade.

Ao criar um balanceador de carga usando o console do Google Cloud , é possível criar a verificação de integridade, se necessário, ao criar o balanceador de carga, ou referenciar 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
• Balanceador de carga de rede de passagem externa regional

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

• 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 balanceadores de carga de aplicativo

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

• Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo internos
• 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
• Serviços de back-end em balanceadores de carga de rede de proxy externo
• Serviços de back-end em balanceadores de carga de rede de passagem externa globais

Para vídeos relacionados:

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