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. Se você precisar começar rapidamente, a maioria das configurações terá valores padrão que facilitam a configuração.

É possível configurar um serviço de back-end para os seguintes balanceadores de carga do Google Cloud:

  • Balanceador de carga HTTP(S) externo
  • Balanceador de carga HTTP(S) interno
  • balanceador de carga do proxy SSL;
  • balanceador de carga do proxy TCP.
  • Balanceador de carga TCP/UDP interno
  • Balanceador de carga de rede

O Traffic Director também usa serviços de back-end.

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;
  • determinar se outros serviços estão ativados, inclusive:
    • Cloud CDN (somente balanceadores de carga HTTP(S) externos);
    • Políticas de segurança do Google Cloud Armor (somente balanceadores de carga HTTP(S) externos);
    • Identity-Aware Proxy (somente balanceadores de carga HTTP(S) externos).

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

Um serviço de back-end pode ter escopo global ou regional.

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

O produto que você está usando, que é um balanceador de carga ou um Traffic Director, determina o seguinte:

  • Número máximo de serviços de back-end
  • Escopo de um serviço de back-end
  • Tipos de back-ends que cada serviço de back-end pode usar
  • Esquema de balanceamento de carga do serviço de back-end
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 HTTP(S) externo Várias Global1 Cada serviço de back-end é compatível com estas 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 sem servidor: um ou mais serviços do App Engine, Cloud Run ou Cloud Functions
  • Um NEG da Internet para um back-end externo
  • Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT
EXTERNAL
Balanceador de carga HTTP(S) interno Várias Regional Cada serviço de back-end é compatível com estas 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 ou
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona, ou
  • Um único NEG do Private Service Connect
INTERNAL_MANAGED
balanceador de carga do proxy SSL; 1 Global1 O serviço de back-end é compatível com estas 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 ou
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona, ou
  • Um NEG da Internet para um back-end externo
EXTERNAL
balanceador de carga do proxy TCP. 1 Global1 O serviço de back-end é compatível com estas 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 ou
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona, ou
  • Um NEG da Internet para um back-end externo
EXTERNAL
Balanceador de carga de rede 1 Regional O serviço de back-end é compatível com esta combinação 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
EXTERNAL
Balanceador de carga TCP/UDP interno 1 Regional, mas configurável para acesso global O serviço de back-end é compatível com estas 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 ou
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP por zona
INTERNAL
Traffic Director Vários Global Cada serviço de back-end é compatível com estas 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 ou
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT por zona
  • Um NEG de Internet do tipo INTERNET_FQDN_PORT
INTERNAL_SELF_MANAGED
1 Os serviços de back-end usados pelo balanceamento de carga HTTP(S) ou proxy SSL e por proxy TCP sempre são globais no escopo, tanto no nível de rede Standard como no Premium. No entanto, no nível Standard, as seguintes restrições se aplicam:

Back-ends

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

Além disso, ao usar um bucket de back-end em vez de um serviço de back-end, é possível ter um back-end de bucket do Cloud Storage.

Não é possível usar diferentes tipos de back-ends com o mesmo serviço de back-end. Por exemplo, um único serviço de back-end não pode referir-se a uma combinação de grupos de instâncias e NEGs por zona. No entanto, é 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.

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.

Protocolo para os back-ends

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

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

Produto Esquema de balanceamento de carga Opções de protocolo do serviço de back-end
Balanceador de carga HTTP(S) externo EXTERNAL HTTP, HTTPS, HTTP/2
balanceador de carga do proxy SSL; EXTERNAL SSL
balanceador de carga do proxy TCP. EXTERNAL TCP
Balanceador de carga HTTP(S) interno INTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Balanceador de carga de rede EXTERNAL TCP, UDP ou UNSPECIFIED (Pré-lançamento)
Balanceador de carga TCP/UDP interno INTERNAL TCP ou UDP
Traffic Director INTERNAL_SELF_MANAGED HTTP, HTTPS, HTTP/2, gRPC, TCP

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

Criptografia entre o balanceador de carga e os back-ends

Para informações sobre esse tópico, consulte Criptografia para back-ends.

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 HTTP(S) externos, balanceadores de carga de proxy SSL e de proxy TCP: os clientes se comunicam com um Google Front End (GFE) usando o endereço IP externo do balanceador de carga. O GFE se comunica com VMs ou endpoints de back-end usando uma combinação de um identificador para a rede VPC do back-end e o endereço IP interno da VM ou do endpoint. Os endereços IP internos precisam ser associados à interface de rede principal (nic0) do back-end. A comunicação entre GFEs e VMs de back-end ou endpoints é facilitada por meio de rotas especiais.
  • No caso dos balanceadores de carga de rede, os pacotes são encaminhados primeiro para o endereço IP externo do balanceador de carga. O balanceador de carga usa hash consistente para roteá-los para VMs de back-end.
  • Para balanceadores de carga HTTP(S) internos, balanceadores de carga TCP/UDP internos e Traffic Director: as VMs de back-end não exigem endereços IP externos.

Portas nomeadas

No back-end, o balanceador de carga encaminha o tráfego para os números de porta em que suas instâncias de back-end (instâncias do Compute Engine) estão ouvindo. Configure esse número de porta no grupo de instâncias e faça referência a ele na configuração do serviço de back-end.

Se a porta nomeada de um grupo de instâncias corresponder a --port-name na configuração do serviço de back-end, o serviço de back-end usará esse número de porta para se comunicar com as VMs do grupo de instâncias.

O número da porta de back-end é chamado de porta nomeada porque é um par de nome/valor. No grupo de instâncias, defina o nome e o valor da chave para a porta.

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

Se você usar vários números para uma porta nomeada (por exemplo, http:80,http:8080), todos eles precisarão ser para o mesmo aplicativo. Isso ocorre porque o tráfego é balanceado entre todas as portas com o mesmo nome. Por exemplo, não é possível criar uma porta nomeada com os valores 80 e 443. Isso não funciona porque a porta 80 geralmente não é compatível com TLS.

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

Observações:

  • Cada serviço de back-end se inscreve em um único nome de porta. Cada grupo de instâncias de back-end precisa ter pelo menos uma porta nomeada para esse nome.

  • 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. No entanto, todas as portas precisam representar o mesmo aplicativo. Por exemplo, http:80,http:8080 funciona, mas http:80,http:443 não funciona.

  • O número da porta resolvida usado pelo serviço de back-end não precisa corresponder ao número da porta usado pelas regras de encaminhamento do balanceador de carga. Um balanceador de carga detecta no front-end um ou mais números de porta configurados na regra de encaminhamento do balanceador de carga. As instâncias de back-end podem estar detectando em diferentes números de porta.

As portas nomeadas não são usadas nestas circunstâncias:

  • Para back-ends de NEGs por zonas ou da Internet, porque esses NEGs definem portas usando um mecanismo diferente, ou seja, nos próprios endpoints
  • Para back-ends de NEG sem servidor, porque esses NEGs não têm endpoints
  • Para balanceadores de carga TCP/UDP internos porque eles são balanceadores de carga de passagem, não proxies, e seu serviço de back-end não se inscreve em uma porta nomeada.
  • Para balanceadores de carga de rede, porque um balanceador de carga de rede é de passagem, não um proxy, e o serviço de back-end não se inscreve em uma porta nomeada.

Para mais informações sobre portas nomeadas, consulte gcloud compute instance-groups managed set-named-ports e gcloud compute instance-groups unmanaged set-named-ports na documentação do SDK.

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

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

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

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

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

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

    • CONNECTION com UTILIZATION
    • RATE com UTILIZATION

    Considere o exemplo a seguir:

    • Você tem dois serviços de back-end: external-https-backend-service para um balanceador de carga HTTP(S) externo e internal-tcp-backend-service para um balanceador de carga TCP/UDP interno.
    • Você está usando um grupo de instâncias chamado instance-group-a em internal-tcp-backend-service.
    • Em internal-tcp-backend-service, aplique o modo de balanceamento CONNECTION, porque os balanceadores de carga TCP/UDP internos são compatíveis somente com o modo de balanceamento CONNECTION.
    • Também será possível usar instance-group-a em external-https-backend-service se você aplicar o modo de balanceamento RATE em external-https-backend-service.
    • Não é possível usar instance-group-a em external-https-backend-service com o modo de balanceamento UTILIZATION.
  • Para alterar o modo de balanceamento de um grupo de instâncias que serve como back-end para vários serviços de back-end:

    • Remova o grupo de instâncias de todos os serviços de back-end, exceto um.
    • Altere o modo de balanceamento do back-end para o serviço de back-end restante.
    • Adicione novamente o grupo de instâncias como back-end aos serviços de back-end restantes, se eles forem compatíveis com o novo modo de balanceamento.
  • Se o grupo de instâncias estiver associado a vários serviços de back-end, cada um deles poderá fazer referência à mesma porta nomeada ou a uma porta nomeada diferente no grupo de instâncias.

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

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

Grupos de endpoints de rede por zona

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

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

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

  • Endpoints GCE_VM_IP.
  • Endpoints GCE_VM_IP_PORT.

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

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.

Os NEGs zonais que usam endpoints GCE_VM_IP_PORT podem ser usados como back-ends para os seguintes tipos de balanceador de carga:

  • Balanceador de carga HTTP(S) interno
  • Balanceador de carga HTTP(S) externo
  • balanceador de carga do proxy SSL;
  • balanceador de carga do proxy TCP.

O Traffic Director também é compatível com back-ends zonais de NEG com endpoints GCE_VM_IP_PORT.

Os NEGs zonais que usam endpoints GCE_VM_IP podem ser usados apenas como back-ends para balanceamento de carga TCP/UDP interno.

Os NEGs zonais não são compatíveis com o balanceamento de carga de rede.

Para mais informações, consulte Visão geral dos grupos de endpoints da rede no balanceamento de carga.

Grupos de endpoints de rede de Internet

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

Um NEG da Internet é uma combinação de um endereço IP ou nome do host, além de uma porta opcional:

  • um nome de domínio totalmente qualificado que pode ser resolvido publicamente e uma porta opcional. Por exemplo, backend.example.com:443 (portas padrão: 80 para HTTP e 443 para HTTPS);
  • um endereço IP que pode ser acessado publicamente e uma porta opcional. Por exemplo, 203.0.113.8:80 ou 203.0.113.8:443 (portas padrão: 80 para HTTP e 443 para HTTPS).

Um serviço de back-end de um balanceador de carga HTTP(S) externo que usa um grupo de endpoints de rede de Internet como back-end distribui o tráfego para um destino fora do Google Cloud.

Para mais informações, incluindo quais balanceadores de carga são compatíveis com NEGs da Internet, consulte Visão geral do grupo de endpoints de rede da Internet.

Grupos de endpoints de rede sem servidor

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

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

  • Um serviço ou um grupo de serviços do Cloud Run.
  • Uma função ou um grupo de funções do Cloud Functions.
  • Um app do App Engine (Standard ou Flex), um serviço específico dentro de um app, uma versão específica de um app ou um grupo de serviços.

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 rotear a solicitação para o serviço correspondente do Cloud Run, do Cloud Functions ou do App Engine com com o mesmo nome.

Para mais informações, incluindo quais balanceadores de carga são compatíveis com NEGs sem servidor, consulte Visão geral do grupo de endpoints da rede sem servidor.

Distribuição de tráfego

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

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

Modo de balanceamento

O modo de balanceamento determina se os back-ends de um balanceador de carga podem lidar com tráfego adicional ou estão totalmente carregados. O Google Cloud tem três modos de balanceamento:

  • CONNECTION
  • RATE
  • UTILIZATION

As opções do modo de balanceamento dependem do esquema de balanceamento de carga do serviço de back-end, do protocolo do serviço de back-end e dos tipos de back-ends conectados ao serviço de back-end.

Você define o modo de balanceamento ao adicionar um back-end ao serviço de back-end. Não é possível especificar um modo de balanceamento ao usar NEGs sem servidor ou NEGs de Internet como back-ends para um balanceador de carga.

Para balanceamento de carga HTTP(S), o modo de balanceamento é usado para selecionar o back-end mais favorável (grupo de instâncias ou NEG). O tráfego é distribuído em estilo round-robin entre instâncias ou endpoints no back-end.

No balanceamento de carga HTTP(S) interno, o balanceamento de carga tem duas camadas. O modo de balanceamento determina a ponderação/fração de tráfego que precisa ser enviada para cada back-end (grupo de instâncias ou NEG). Em seguida, a política de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído para as instâncias ou endpoints no grupo. A capacidade de destino max-utilization só pode ser especificada por grupo de instâncias e não pode ser aplicada a uma determinada VM no grupo.

Modo de balanceamento Esquemas de balanceamento de carga compatíveis Protocolos de serviço de back-end compatíveis1 Back-ends compatíveis2 Produtos aplicáveis
CONNECTION EXTERNAL
INTERNAL
SSL, TCP, UDP
Grupos de instâncias ou NEGs por zona, caso sejam compatíveis.
  • balanceador de carga do proxy SSL;
  • balanceador de carga do proxy TCP.
  • Balanceador de carga TCP/UDP interno
  • Balanceador de carga de rede
RATE EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
HTTP, HTTPS, HTTP2, gRPC Grupos de instâncias ou NEGs por zona
  • Balanceador de carga HTTP(S) externo
  • Balanceador de carga HTTP(S) interno
  • Traffic Director (somente INTERNAL_SELF_MANAGED; HTTPS, HTTP, TCP e protocolos gRPC)
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
Nenhuma restrição especial Somente grupos de instâncias. Os NEGs por zona não são compatíveis com o modo de utilização.
  • Balanceador de carga HTTP(S) externo
  • balanceador de carga do proxy SSL;
  • balanceador de carga do proxy TCP.
  • Balanceador de carga HTTP(S) interno
  • Traffic Director (somente INTERNAL_SELF_MANAGED; HTTPS, HTTP, TCP e protocolos gRPC)
1Os protocolos são ainda mais restritos dependendo do tipo de balanceador de carga.
2Para ver os tipos de back-end compatíveis (por exemplo, grupos de instâncias e NEGs zonais), consulte Back-ends na página de recursos do balanceador de carga.

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

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

Como alterar o modo de balanceamento de um balanceador de carga

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

Balanceador de carga Back-ends Modos de balanceamento disponíveis
Balanceador de carga HTTP(S) externo Grupos de instâncias RATE ou UTILIZATION
NEGs zonais (endpoints GCE_VM_IP_PORT) RATE
Balanceador de carga HTTP(S) interno Grupos de instâncias RATE ou UTILIZATION
NEGs zonais (endpoints GCE_VM_IP_PORT) RATE
balanceador de carga do proxy TCP. Grupos de instâncias CONNECTION ou UTILIZATION
NEGs zonais (endpoints GCE_VM_IP_PORT) CONNECTION
balanceador de carga do proxy SSL; Grupos de instâncias CONNECTION ou UTILIZATION
NEGs zonais (endpoints GCE_VM_IP_PORT) CONNECTION
Balanceador de carga de rede Grupos de instâncias CONNECTION
Balanceador de carga TCP/UDP interno Grupos de instâncias CONNECTION
NEGs zonais (endpoints GCE_VM_IP) CONNECTION

Capacidade desejada

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

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

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

Modo de balanceamento de conexão

Para o modo de balanceamento CONNECTION, a capacidade desejada define um número máximo de conexões simultâneas. Exceto para balanceadores de carga TCP/UDP internos e balanceadores de carga de rede, é preciso usar uma das seguintes configurações para especificar um número máximo de conexões de destino:

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

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

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

H instâncias íntegras
max-connections=Y Y Y/H

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

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

Modo de balanceamento de taxa

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

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

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

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

H instâncias íntegras
max-rate=Y Y Y/H

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

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

Modo de balanceamento de utilização

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

Modos de balanceamento compatíveis e configurações de capacidade desejadas

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

Balanceador de carga Tipo de back-end Modo de balanceamento Capacidade desejada
Balanceador de carga TCP/UDP interno Grupo de instâncias CONNECTION Não é possível especificar um número máximo de conexões.
NEGs por zona (GCP_VM_IP) CONNECTION Não é possível especificar um número máximo de conexões.
Balanceador de carga de rede TCP/UDP externo Grupo de instâncias CONNECTION Não é possível especificar um número máximo de conexões.
Balanceador de carga do proxy SSL, balanceador de carga do proxy TCP Grupo de instâncias CONNECTION É obrigatório especificar uma das seguintes opções:
  • max-connections por grupo de instâncias zonais
  • max-connections-per-instance  (grupos de instâncias regionais ou zonais)
UTILIZATION Você tem a opção de especificar o seguinte:
  • (1) max-utilization
  • (2) max-connections por grupo de instâncias zonais
  • (3) max-connections-per-instance
     (grupos de instâncias regionais ou zonais)
  • (1) e (2) juntos
  • (1) e (3) juntos
NEG por zona (GCP_VM_IP_PORT) CONNECTION É obrigatório especificar uma das seguintes opções:
  • max-connections por NEG zonal
  • max-connections-per-endpoint
Balanceador de carga HTTP(S) externo, balanceador de carga HTTP(S) interno, Traffic Director Grupo de instâncias RATE É obrigatório especificar uma das seguintes opções:
  • max-rate por grupo de instâncias zonais
  • max-rate-per-instance
     (grupos de instâncias por zona ou regionais)
UTILIZATION Você tem a opção de especificar o seguinte:
  • (1) max-utilization
  • (2) max-rate por grupo de instâncias zonais
  • (3) max-rate-per-instance
     (grupos de instâncias por zona ou regionais)
  • (1) e (2) juntos
  • (1) e (3) juntos
NEG por zona (GCP_VM_IP_PORT) RATE É obrigatório especificar uma das seguintes opções:
  • max-rate por NEG zonal
  • max-rate-per-endpoint

Escalonador de capacidade

Como opção, é possível ajustar o escalonador de capacidade para reduzir a capacidade desejada (utilização máxima, taxa máxima ou conexões máximas) sem alterar a capacidade desejada. O escalonador de capacidade é compatível com todos os balanceadores de carga compatíveis com a capacidade desejada. As únicas exceções são o balanceador de carga de rede e o balanceador de carga TCP/UDP interno.

Por padrão, o valor do escalonador de capacidade é 1.0 (100%). É possível definir o escalonador de capacidade como um destes valores:

  • exatamente 0.0, o que impedirá todas as novas conexões
  • um valor entre 0.1 (10%) e 1.0 (100%)

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

  • Se o modo de balanceamento for RATE, a taxa máxima será definida como 80 RPS e o escalonador de capacidade for 1.0. A capacidade de destino efetiva também será 80 RPS.

  • Se o modo de balanceamento for RATE, a utilização máxima será definida como 80 RPS e o escalonador de capacidade será 0.5. A capacidade de destino efetiva será 40 RPS (0.5 times 80.

  • Se o modo de balanceamento for RATE, a utilização máxima será definida como 80 RPS e o escalonador de capacidade será 0.0. A capacidade desejada efetiva será zero. Um escalonador de capacidade igual a zero retira o back-end da rotação.

Traffic Director e distribuição de tráfego

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

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

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

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

Para mais informações sobre o Traffic Director, consulte Conceitos do Traffic Director.

Afinidade da sessão

Alguns aplicativos precisam que várias solicitações de 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. A desvantagem da afinidade de sessão é que sua carga pode ser menos distribuída.

A afinidade da sessão opera com base no melhor esforço para entregar solicitações ao mesmo back-end que atendeu à solicitação inicial. Por padrão, a afinidade da sessão está desativada (--session-affinity=NONE). Sem a afinidade da sessão ativada, os balanceadores de carga distribuem as novas solicitações com base em um hash de cinco tuplas, da seguinte maneira:

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

Para balanceadores de carga de passagem, se uma instância ou um endpoint de back-end estiver íntegro, as solicitações subsequentes vão para a mesma VM ou endpoint de back-end.

Para balanceadores de carga baseados em proxy, se uma instância ou um endpoint de back-end estiver íntegro e não estiver no limite de solicitações subsequentes, acesse o mesmo endpoint ou VM de back-end. O modo de balanceamento determina quando o back-end está no limite da capacidade.

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

  • Não confie na afinidade da sessão para fins de autenticação ou segurança. A afinidade da sessão é projetada para falhar quando um back-end estiver acima ou atingir sua capacidade, ou ainda se não estiver íntegro.

  • Os balanceadores de carga do Google Cloud fornecem afinidade de sessão com base no melhor esforço. Fatores como a alteração de estados de verificação de integridade do back-end ou alterações na integridade do back-end, conforme medido pelo modo de balanceamento, podem interromper a afinidade da sessão. Não é recomendado usar uma afinidade de sessão que não seja None com o modo de balanceamento UTILIZATION. Isso ocorre porque as alterações na utilização da instância podem fazer com que o serviço de balanceamento de carga direcione novas solicitações ou conexões para VMs de back-end que estejam menos completas. Isso quebra a afinidade da sessão. Em vez disso, use o modo de balanceamento RATE ou CONNECTION para reduzir a diferença da afinidade da sessão.

  • Quando os balanceadores de carga têm a afinidade da sessão ativada, eles equilibram bem a carga quando há uma distribuição razoavelmente grande de sessões únicas. Razoavelmente grande significa pelo menos várias vezes o número de instâncias de back-end no grupo de instâncias. Quando você testa um balanceador de carga com um número pequeno de sessões, o tráfego não é distribuído uniformemente.

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

    • Um balanceador de carga tem um NEG e três endpoints.
    • Cada endpoint tem uma capacidade desejada de 1 RPS.
    • O modo de balanceamento é RATE.
    • No momento, cada endpoint está processando 1,1, 0,8 e 1,6 RPS, respectivamente.
    • Quando uma solicitação HTTP com afinidade para o último endpoint chega ao balanceador de carga, a afinidade da sessão reivindica o endpoint que está processando a 1,6 RPS.
    • A nova solicitação pode ir para o endpoint do meio com 0,8 RPS.
  • Para informações específicas sobre o balanceamento de carga de rede e a afinidade da sessão, consulte a Visão geral do balanceamento de carga de rede TCP/UDP externo.

  • Consulte Visão geral do balanceamento de carga TCP/UDP interno para informações específicas.

  • Quando os serviços gRPC sem proxy forem configurados, o Traffic Director não será compatível com a afinidade de sessão.

A tabela a seguir mostra as opções de afinidade da sessão:

Produto Opções de afinidade de sessão
Balanceador de carga TCP/UDP interno
  • Nenhum (5 tuplas)
  • IP do cliente, IP de destino (2 tuplas)
  • IP do cliente, IP de destino, protocolo (3 tuplas)
  • IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo (5-tuplas)
Balanceador de carga de proxy TCP
Balanceador de carga de proxy SSL
  • Nenhum
  • IP do cliente
Balanceador de carga HTTP(S) externo • Nenhuma
• IP do cliente
• Cookie gerado
Balanceador de carga HTTP(S) interno
  • Nenhum
  • IP do cliente
  • Cookie gerado
  • Campo de cabeçalho
  • Cookie HTTP
Balanceador de carga de rede
  • Nenhum (5 tuplas)
  • IP do cliente, IP de destino (2 tuplas)
  • IP do cliente, IP de destino, protocolo (3 tuplas)
  • IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo (5-tuplas)
Traffic Director
  • Nenhum
  • IP do cliente
  • Cookie gerado (somente protocolos HTTP)
  • Campo de cabeçalho (somente protocolos HTTP)
  • Cookie HTTP (apenas protocolos HTTP)

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

Afinidade de IP do cliente

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

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

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

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

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

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

  • Em balanceadores de carga HTTP(S) externos, o cookie é chamado de GCLB.
  • Em balanceadores de carga HTTP(S) internos e no Traffic Director, o cookie é denominado GCILB.

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

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

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

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

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

Afinidade do campo de cabeçalho

A afinidade de campo de cabeçalho é compatível quando os dois itens a seguir são verdadeiros:

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

A afinidade do campo de cabeçalho encaminha solicitações para VMs ou endpoints de back-end em um NEG por zona com base no valor do cabeçalho HTTP nomeado na sinalização --custom-request-header.

Os seguintes produtos podem usar a afinidade de campo de cabeçalho:

  • Traffic Director
  • Balanceador de carga HTTP(S) interno

Para mais informações sobre o balanceamento de carga HTTP(S) interno, em que a afinidade do campo de cabeçalho é usada, consulte Visão geral do balanceamento de carga HTTP(S) interno.

A afinidade de cookie HTTP é compatível quando os dois itens a seguir são verdadeiros:

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

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

Os produtos a seguir podem usar a afinidade de cookie HTTP:

  • Traffic Director
  • Balanceador de carga HTTP(S) interno

Para mais informações sobre o balanceamento de carga HTTP(S) interno, em que a afinidade de cookie HTTP é usada, consulte Visão geral do balanceamento de carga HTTP(S) interno.

Perda da afinidade da sessão

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

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

Ao usar balanceamento de carga HTTP(S), de proxy SSL ou de proxy TCP, lembre-se dos seguintes pontos adicionais:

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

Tempo limite do serviço de back-end

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

  • Para balanceadores de carga HTTP(S) 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/resposta para o tráfego HTTP(S). Esse é o tempo que o balanceador de carga aguarda até que um back-end retorne uma resposta completa a uma solicitação. Por exemplo, se o valor do tempo limite do serviço de back-end for o valor padrão de 30 segundos, os back-ends terão 30 segundos para fornecer uma resposta completa às solicitações. O balanceador de carga repetirá a solicitação HTTP GET uma vez se o back-end fechar a conexão ou expirar antes de enviar cabeçalhos de resposta para o balanceador de carga. Se o back-end enviar cabeçalhos de resposta (mesmo que o corpo da resposta esteja incompleto) ou a solicitação enviada ao back-end não for uma solicitação HTTP GET, o balanceador de carga não tentará novamente. Se o back-end não responder, o balanceador de carga retornará uma resposta HTTP 5xx ao cliente. Se quiser alterar o tempo limite para que os back-ends respondam às solicitações, altere o valor de tempo limite.

  • Para o tráfego HTTP, o tempo máximo para o cliente concluir o envio da solicitação é igual ao tempo limite do serviço de back-end. Se você vir respostas HTTP 408 com o jsonPayload.statusDetail client_timed_out, significa que não houve progresso suficiente enquanto a solicitação do cliente foi colocada em proxy ou a resposta do back-end foi colocada em proxy. Se o problema for causado por clientes com problemas de desempenho, a solução é aumentar o tempo limite do serviço de back-end.

  • Para balanceadores de carga HTTP(S) externos e balanceadores de carga HTTP(S) internos, se a conexão HTTP for atualizada para um WebSocket, o tempo limite do serviço de back-end definirá o tempo máximo que um WebSocket pode ficar aberto, estando inativo ou não.

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

  • Para balanceadores de carga TCP/UDP internos e balanceadores de carga de rede, defina 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.

  • Quando os serviços gRPC sem proxy são configurados, o Traffic Director não é compatível com o tempo limite do serviço de back-end especificado usando o campo timeoutSec. 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 em que back-ends são grupos de instâncias ou NEGs por zona precisa ter uma verificação de integridade associada. Os serviços de back-end que usam um NEG sem servidor ou um NEG 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 do Google Cloud, caso seja necessário, ou referir-se a uma verificação de integridade atual.

Ao criar um serviço de back-end usando o grupo de instâncias ou os back-ends de NEG por zona usando a ferramenta de linha de comando gcloud 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:

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

Alguns recursos opcionais do Google Cloud estão disponíveis para serviços de back-end usados por um balanceador de carga HTTP(S) externo. Eles não são discutidos neste documento, mas estão listados na Visão geral do balanceamento de carga HTTP(S).

Recursos de gerenciamento de tráfego

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

Esses recursos são compatíveis com os seguintes itens:

  • Balanceadores de carga HTTP(S) internos
  • Traffic Director (mas não compatível com serviços gRPC sem proxy)

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: