Vista geral dos serviços de back-end

Um serviço de back-end define como o Cloud Load Balancing distribui o tráfego. A configuração do serviço de back-end contém um conjunto de valores, como o protocolo usado para estabelecer ligação aos back-ends, várias definições de distribuição e sessão, verificações de estado e limites de tempo. Estas definições oferecem um controlo detalhado sobre o comportamento do seu equilibrador de carga. Para começar, a maioria das definições tem valores predefinidos que permitem uma configuração rápida. Um serviço de back-end é global ouregional no âmbito.

Os equilibradores de carga, os proxies Envoy e os 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 servidores de back-end corretos, que são grupos de instâncias ou grupos de pontos finais de rede (NEGs).
  • Distribuir o tráfego de acordo com um modo de equilíbrio, que é uma definição para cada back-end.
  • Determine que verificação de funcionamento está a monitorizar o estado dos back-ends.
  • Especifique a afinidade de sessão.
  • Determine se outros serviços estão ativados, incluindo os seguintes serviços que só estão disponíveis para determinados equilibradores de carga:
    • Cloud CDN
    • Políticas de segurança do Google Cloud Armor
    • Identity-Aware Proxy
  • Designar serviços de back-end regionais como um serviço nas aplicações do App Hub.

Define estes valores quando cria um serviço de back-end ou adiciona um back-end ao serviço de back-end.

Nota: se estiver a usar o Application Load Balancer externo global ou o Application Load Balancer clássico, e os seus back-ends servirem conteúdo estático, considere usar contentores de back-end em vez de serviços de back-end. Consulte os contentores de back-end para o balanceador de carga de aplicações externo global ou os contentores de back-end para o balanceador de carga de aplicações clássico.

A tabela seguinte resume os balanceadores de carga que usam serviços de back-end. O produto que está a usar também determina o número máximo de serviços de back-end, o âmbito de um serviço de back-end, o tipo de back-ends suportados e o esquema de balanceamento de carga do serviço de back-end. O esquema de equilíbrio de carga é um identificador que a Google usa 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 respetivas regras de encaminhamento e serviços de back-end. Alguns esquemas são partilhados entre produtos.

Tabela: serviços de back-end e tipos de back-end suportados
Produto Número máximo de serviços de back-end Âmbito do serviço de back-end Tipos de back-end suportados Esquema de balanceamento de carga
Balanceador de carga de aplicações externo global Vários Global Cada serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os backends de grupos de instâncias: um ou mais backends de grupos de instâncias geridos, não geridos ou uma combinação de backends de grupos de instâncias geridos e não geridos *
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT*
  • Todos os NEGs de conetividade híbrida: um ou mais NEGs do tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs zonais e híbridos: NEGs do tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT †
  • Todos os NEGs sem servidor: um ou mais recursos do App Engine, do Cloud Run ou das funções do Cloud Run
  • Um NEG global da Internet para um back-end externo
  • NEGs do Private Service Connect:
    • APIs Google: um único NEG do Private Service Connect
    • Serviços geridos: um ou mais NEGs do Private Service Connect
EXTERNAL_MANAGED
Balanceador de carga de aplicações clássico Vários Global‡ Cada serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os back-ends de grupos de instâncias: um ou mais back-ends de grupos de instâncias geridos, não geridos ou uma combinação de back-ends de grupos de instâncias geridos e não geridos
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT
  • Todos os NEGs de conetividade híbrida: um ou mais NEGs do tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs zonais e híbridos: NEGs do tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT †
  • Todos os NEGs sem servidor: um ou mais recursos do App Engine, do Cloud Run ou das funções do Cloud Run, ou
  • Um NEG global da Internet para um back-end externo
 EXTERNAL#
Balanceador de carga de aplicações externo regional Vários Regional Cada serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os backends de grupos de instâncias: um ou mais backends de grupos de instâncias geridos, não geridos ou uma combinação de backends de grupos de instâncias geridos e não geridos *
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT*
  • Todos os NEGs de conetividade híbrida: um ou mais NEGs do tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs zonais e híbridos: NEGs do tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT †
  • Um NEG sem servidor (apenas para o Cloud Run ou as funções do Cloud Run de 2.ª geração)
  • Um único NEG do Private Service Connect
  • Todos os NEGs de Internet regionais para um back-end externo
 EXTERNAL_MANAGED
Balanceador de carga de aplicações interno entre regiões Vários Global Cada serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os backends de grupos de instâncias: um ou mais backends de grupos de instâncias geridos, não geridos ou uma combinação de backends de grupos de instâncias geridos e não geridos *
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT*
  • Todos os NEGs de conetividade híbrida: um ou mais NEGs do tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs zonais e híbridos: NEGs do tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT †
  • Um NEG sem servidor (apenas para o Cloud Run ou as funções do Cloud Run de 2.ª geração)
  • NEGs do Private Service Connect:
    • APIs Google: um único NEG do Private Service Connect
    • Serviços geridos: um ou mais NEGs do Private Service Connect
INTERNAL_MANAGED
Balanceador de carga de aplicações interno regional Vários Regional Cada serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os backends de grupos de instâncias: um ou mais backends de grupos de instâncias geridos, não geridos ou uma combinação de backends de grupos de instâncias geridos e não geridos *
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT*
  • Todos os NEGs de conetividade híbrida: um ou mais NEGs do tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs zonais e híbridos: NEGs do tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT †
  • Um NEG sem servidor (apenas para o Cloud Run ou as funções do Cloud Run de 2.ª geração)
  • Um único NEG do Private Service Connect
  • Todos os NEGs de Internet regionais para um back-end externo
 INTERNAL_MANAGED
Balanceador de carga de rede de proxy externo global 1 Global‡ O serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os back-ends de grupos de instâncias: um ou mais back-ends de grupos de instâncias geridos, não geridos ou uma combinação de back-ends de grupos de instâncias geridos e não geridos *
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT*
  • Todos os NEGs de conetividade híbrida: um ou mais NEGs do tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs zonais e híbridos: NEGs do tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT †
  • NEGs do Private Service Connect:
    • APIs Google: um único NEG do Private Service Connect
    • Serviços geridos: um ou mais NEGs do Private Service Connect
EXTERNAL_MANAGED
Balanceador de carga de rede de proxy clássico 1 Global‡ O serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os back-ends de grupos de instâncias: um ou mais back-ends de grupos de instâncias geridos, não geridos ou uma combinação de back-ends de grupos de instâncias geridos e não geridos
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT
  • Todos os NEGs de conetividade híbrida: um ou mais NEGs do tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs zonais e híbridos: NEGs do tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT †
 EXTERNO
Balanceador de carga de rede de proxy externo regional 1 Regional O serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os backends de grupos de instâncias: um ou mais backends de grupos de instâncias geridos, não geridos ou uma combinação de backends de grupos de instâncias geridos e não geridos *
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT*
  • Todos os NEGs de conetividade híbrida: um ou mais NEGs do tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs zonais e híbridos: NEGs do tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT
  • Todos os NEGs de Internet regionais para um back-end externo
  • Um único NEG do Private Service Connect
 EXTERNAL_MANAGED
Balanceador de carga de rede de proxy interno regional 1 Regional O serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os backends de grupos de instâncias: um ou mais backends de grupos de instâncias geridos, não geridos ou uma combinação de backends de grupos de instâncias geridos e não geridos *
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT*
  • Todos os NEGs de conetividade híbrida: um ou mais NEGs do tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs zonais e híbridos: NEGs do tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT
  • Todos os NEGs de Internet regionais para um back-end externo
  • Um único NEG do Private Service Connect
 INTERNAL_MANAGED
Balanceador de carga de rede de proxy interno entre regiões Vários Global O serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os backends de grupos de instâncias: um ou mais backends de grupos de instâncias geridos, não geridos ou uma combinação de backends de grupos de instâncias geridos e não geridos *
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT*
  • Todos os NEGs de conetividade híbrida: um ou mais NEGs do tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs zonais e híbridos: NEGs do tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT
  • NEGs do Private Service Connect:
    • APIs Google: um único NEG do Private Service Connect
    • Serviços geridos: um ou mais NEGs do Private Service Connect
INTERNAL_MANAGED
Balanceador de carga de rede de encaminhamento externo 1 Regional O serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os back-ends de grupos de instâncias: um ou mais back-ends de grupos de instâncias geridos, não geridos ou uma combinação de back-ends de grupos de instâncias geridos e não geridos
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP
 EXTERNO
Balanceador de carga de rede de encaminhamento interno 1 Regional, mas configurável para ser acessível globalmente O serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os back-ends de grupos de instâncias: um ou mais back-ends de grupos de instâncias geridos, não geridos ou uma combinação de back-ends de grupos de instâncias geridos e não geridos
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP
  • NEG de mapeamento de uma porta
 INTERNO
Cloud Service Mesh Vários Global Cada serviço de back-end suporta uma das seguintes combinações de back-end:
  • Todos os back-ends de grupos de instâncias: um ou mais back-ends de grupos de instâncias geridos, não geridos ou uma combinação de back-ends de grupos de instâncias geridos e não geridos
  • Todos os NEGs zonais: um ou mais NEGs zonais do tipo GCE_VM_IP_PORT ou NON_GCP_PRIVATE_IP_PORT
  • Um NEG da Internet do tipo INTERNET_FQDN_PORT
  • Uma ou mais associações de serviços
 INTERNAL_SELF_MANAGED
* Suporte grupos de instâncias IPv4 e IPv6 (dual-stack) e back-ends NEG zonais. Os NEGs zonais suportam a pilha dupla apenas em pontos finais do tipo GCE_VM_IP_PORT.

† Para implementações do GKE, os back-ends de NEG mistos só são suportados com NEGs autónomos.
‡ Os serviços de back-end usados pelos Application Load Balancers clássicos e pelos Network Load Balancers de proxy clássicos têm sempre âmbito global, no nível de rede Standard ou Premium. No entanto, no nível Standard, aplicam-se as seguintes restrições:
# É possível anexar serviços de back-end a EXTERNAL regras de encaminhamento.EXTERNAL_MANAGED No entanto, não é possível anexar serviços de back-end da EXTERNAL a regras de encaminhamento da EXTERNAL_MANAGED. Para tirar partido das novas funcionalidades disponíveis apenas com o Application Load Balancer externo global, recomendamos que migre os seus recursos EXTERNAL existentes para EXTERNAL_MANAGED através do processo de migração descrito em Migre recursos do Application Load Balancer externo clássico para o global.

Nomenclatura do balanceador de carga

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

  • Google Cloud consola. Se criar um Network Load Balancer de proxy ou um Network Load Balancer de passagem através da consola Google Cloud , o serviço de back-end é automaticamente atribuído ao mesmo nome que introduziu para o nome do balanceador de carga.
  • CLI do Google Cloud ou API. Se criar um balanceador de carga de rede de proxy ou um balanceador de carga de rede de encaminhamento direto através da CLI gcloud ou da API, introduz um nome à sua escolha ao criar o serviço de back-end. Em seguida, o nome deste serviço de back-end é refletido na consola como o nome do balanceador de carga. Google Cloud

Para saber como funciona a atribuição de nomes para balanceadores de carga de aplicações, consulte o resumo dos mapas de URLs: atribuição de nomes aos balanceadores de carga.

Back-ends

Um back-end é um ou mais pontos finais que recebem tráfego de um Google Cloudbalanceador de carga, um proxy Envoy configurado na Cloud Service Mesh ou um cliente gRPC sem proxy. Existem vários tipos de back-ends:

Não pode eliminar um grupo de instâncias ou um NEG de back-end associado a um serviço de back-end. Antes de eliminar um grupo de instâncias ou um NEG, tem de o remover primeiro como um back-end de todos os serviços de back-end que o referenciam.

Grupos de instâncias

Esta secção aborda o funcionamento dos grupos de instâncias com o serviço de back-end.

VMs de back-end e endereços IP externos

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

  • Para balanceadores de carga de aplicações externos globais e balanceadores de carga de rede de proxy externos: os clientes comunicam com um Google Front End (GFE) que alojam o endereço IP externo do seu balanceador de carga. Os GFEs comunicam com VMs ou pontos finais de back-end enviando pacotes para um endereço interno criado através da associação de um identificador para a rede VPC do back-end com o endereço IPv4 interno do back-end. A comunicação entre GFEs e VMs ou pontos finais de back-end é facilitada através de rotas especiais.
    • Por exemplo, para back-ends de grupos, o endereço IPv4 interno é sempre o endereço IPv4 interno principal que corresponde à interface nic0 da VM.
    • Para os pontos finais GCE_VM_IP_PORT num NEG zonal, pode especificar o endereço IP do ponto final como o endereço IPv4 principal associado a qualquer interface de rede de uma VM ou qualquer endereço IPv4 de um intervalo de endereços IP de alias associado a qualquer interface de rede de uma VM.

  • Para balanceadores de carga de aplicações externos regionais: os clientes comunicam com um proxy Envoy que aloja o endereço IP externo do balanceador de carga. Os proxies Envoy comunicam com as VMs ou os pontos finais de back-end enviando pacotes para um endereço interno criado através da associação de um identificador da rede VPC do back-end ao endereço IPv4 interno do back-end.

    • Para back-ends de grupos de instâncias, o endereço IPv4 interno é sempre o endereço IPv4 interno principal que corresponde à interface nic0 da VM e nic0 tem de estar na mesma rede que o balanceador de carga.
    • Para os pontos finais GCE_VM_IP_PORT num NEG zonal, pode especificar o endereço IP do ponto final como o endereço IPv4 principal associado a qualquer interface de rede de uma VM ou qualquer endereço IPv4 de um intervalo de endereços IP de alias associado a qualquer interface de rede de uma VM, desde que a interface de rede esteja na mesma rede que o equilibrador de carga.

  • Para equilibradores de carga de encaminhamento externos: os clientes comunicam diretamente com os back-ends através da infraestrutura de equilíbrio de carga de encaminhamento Maglev da Google. Os pacotes são encaminhados e entregues aos back-ends com os endereços IP de origem e de destino originais preservados. Os backends respondem aos clientes através do retorno direto do servidor. Os métodos usados para selecionar um back-end e monitorizar as ligações são configuráveis.

    • Para os back-ends do grupo de instâncias, os pacotes são sempre entregues à interface nic0 da VM.
    • Para os pontos finais GCE_VM_IP num NEG zonal, os pacotes são entregues à interface de rede da VM que está na sub-rede associada ao NEG.

Portas com nome

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

As portas com nome são configuradas da seguinte forma:

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

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

Com base no back-end do grupo de instâncias, o serviço de back-end traduz o nome da porta num número de porta. Quando a porta com nome de um grupo de instâncias corresponde ao --port-name do serviço de back-end, o serviço de back-end usa este número da porta para a comunicação com as VMs do grupo de instâncias.

Por exemplo, pode definir a porta com nome num 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, consulte a porta com nome na configuração do serviço de back-end com o --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 pode usar um número de porta diferente quando comunica com VMs em diferentes grupos de instâncias se cada grupo de instâncias especificar um número de porta diferente para o mesmo nome de porta.

O número da porta resolvido usado pelo serviço de back-end do equilibrador de carga do proxy não tem de corresponder ao número da porta usado pelas regras de encaminhamento do equilibrador de carga. Um balanceador de carga de proxy ouve as ligações TCP enviadas para o endereço IP e a porta de destino das respetivas regras de encaminhamento. Uma vez que o proxy abre uma segunda ligação TCP aos respetivos back-ends, a porta de destino da segunda ligação TCP pode ser diferente.

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

Os balanceadores de carga de rede de encaminhamento interno e os balanceadores de carga de rede de encaminhamento externo não usam portas com nome. Isto deve-se ao facto de serem equilibradores de carga de passagem que encaminham as ligações diretamente para os back-ends em vez de criarem novas ligações. Os pacotes são entregues aos back-ends preservando o endereço IP de destino e a porta da regra de encaminhamento do balanceador de carga.

Para saber como criar portas com nome, consulte as seguintes instruções:

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

Tenha em atenção as seguintes restrições e orientações quando criar grupos de instâncias para os seus equilibradores de carga:

  • Não coloque uma VM em mais do que um grupo de instâncias com balanceamento de carga. Se uma VM for membro de dois ou mais grupos de instâncias não geridos, ou membro de um grupo de instâncias gerido e um ou mais grupos de instâncias não geridos, Google Cloud limita a utilização de apenas um desses grupos de instâncias de cada vez como back-end para um determinado serviço de back-end.

    Se precisar de uma VM para participar em vários balanceadores de carga, tem de usar 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 quiser equilibrar o tráfego para diferentes portas, especifique as portas com nome necessárias num grupo de instâncias e faça com que cada serviço de back-end subscreva uma porta com nome exclusiva.

  • Pode usar o mesmo grupo de instâncias como back-end para mais do que um serviço de back-end. Nesta situação, os back-ends têm de usar modos de equilíbrio de carga compatíveis. Compatível significa que os modos de equilíbrio têm de ser iguais ou têm de ser uma combinação de modos de equilíbrio compatíveis, por exemplo, CONNECTION e RATE.

    Seguem-se as combinações de modos de equilíbrio incompatíveis:

    • CONNECTION com UTILIZATION
    • RATE com UTILIZATION
    • CUSTOM_METRICS com UTILIZATION
    • CUSTOM_METRICS com RATE
    • CUSTOM_METRICS com CONNECTION

    Considere o seguinte exemplo:

    • Tem dois serviços de back-end: external-https-backend-service para um balanceador de carga de aplicações externo e internal-tcp-backend-service para um balanceador de carga de rede de passagem interno.
    • Está a usar um grupo de instâncias denominado instance-group-a em internal-tcp-backend-service.
    • No internal-tcp-backend-service, tem de aplicar o modo de balanceamento de carga CONNECTION, porque os balanceadores de carga de rede de encaminhamento interno só suportam o modo de balanceamento de carga CONNECTION.
    • Também pode usar instance-group-a em external-https-backend-service se aplicar o modo de equilíbrio RATE em external-https-backend-service.
    • Também não pode usar instance-group-a em external-https-backend-service com o modo de equilíbrio UTILIZATION.

  • Para alterar o modo de balanceamento de um grupo de instâncias que funciona 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 de carga para o back-end no serviço de back-end restante.
    • Adicione novamente o grupo de instâncias como back-end aos serviços de back-end restantes, se suportarem o novo modo de balanceamento.

  • Se o seu grupo de instâncias estiver associado a vários serviços de back-end, cada serviço de back-end pode referenciar a mesma porta com nome ou uma porta com nome diferente no grupo de instâncias.

  • Recomendamos que não adicione um grupo de instâncias gerido com escalamento automático a mais de um serviço de back-end. Tal pode causar um dimensionamento imprevisível e desnecessário de instâncias no grupo, especialmente se usar a métrica de dimensionamento automático Utilização do balanceamento de carga HTTP.

    • Embora não seja recomendado, este cenário pode funcionar se a métrica de dimensionamento automático for a utilização da CPU ou uma métrica do Cloud Monitoring que não esteja relacionada com a capacidade de publicação do balanceador de carga. A utilização de uma destas métricas de dimensionamento automático pode evitar o dimensionamento errático.

Grupos de pontos finais da rede zonais

Os pontos finais de rede representam serviços pelo respetivo endereço IP ou uma combinação de endereço IP e porta, em vez de fazer referência a uma VM num grupo de instâncias. Um grupo de pontos finais de rede (NEG) é um agrupamento lógico de pontos finais de rede.

Os grupos de pontos finais de rede (NEGs) zonais são recursos zonais que representam coleções de endereços IP ou combinações de endereços IP e portas para Google Cloud recursos numa única sub-rede.

Um serviço de back-end que usa NEGs zonais como back-ends distribui o tráfego entre aplicações ou contentores em execução em VMs.

Existem dois tipos de pontos finais de rede disponíveis para NEGs zonais:

  • GCE_VM_IP (suportados apenas com balanceadores de carga de rede de encaminhamento interno e balanceadores de carga de rede de encaminhamento externo baseados em serviços de back-end).
  • GCE_VM_IP_PORT pontos finais.

Para ver que produtos suportam back-ends de NEG zonais, consulte a Tabela: serviços de back-end e tipos de back-end suportados.

Para obter detalhes, consulte a vista geral dos NEGs zonais.

Grupos de pontos finais da rede da Internet

Os NEGs de Internet são recursos que definem back-ends externos. Um back-end externo é um back-end alojado numa infraestrutura no local ou numa infraestrutura fornecida por terceiros.

Um NEG da Internet é uma combinação de um nome de anfitrião ou um endereço IP, além de uma porta opcional. Existem dois tipos de pontos finais de rede disponíveis para NEGs de Internet: INTERNET_FQDN_PORTe INTERNET_IP_PORT.

Os NEGs da Internet estão disponíveis em dois âmbitos: global e regional. Para ver que produtos suportam back-ends NEG em cada âmbito, consulte a Tabela: serviços de back-end e tipos de back-end suportados.

Para ver detalhes, consulte a vista geral do grupo de pontos finais da rede de Internet.

Grupos de pontos finais de rede sem servidor

Um grupo de pontos finais da rede (NEG) especifica um grupo de pontos finais do back-end para um balanceador de carga. Um NEG sem servidor é um back-end que aponta para um recurso do Cloud Run, App Engine, Cloud Run Functions ou API Gateway.

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

  • Um recurso do Cloud Run ou um grupo de recursos.
  • Uma função do Cloud Run ou um grupo de funções (anteriormente, funções do Cloud Run de 2.ª geração).
  • Uma função do Cloud Run (1.ª geração) ou um grupo de funções
  • Uma app do ambiente padrão do App Engine ou do ambiente flexível do App Engine, um serviço específico numa app, uma versão específica de uma app ou um grupo de serviços.
  • Um gateway da API que fornece acesso aos seus serviços através de uma API REST consistente em todos os serviços, independentemente da implementação do serviço. Esta capacidade está em pré-visualização.

Para configurar um NEG sem servidor para aplicações sem servidor que partilham um padrão de URL, usa uma máscara de URL. Uma máscara de URL é um modelo do seu esquema de URL (por exemplo, example.com/<service>). O NEG sem servidor usa este modelo para extrair o nome <service> do URL do pedido recebido e encaminhar o pedido para o serviço do Cloud Run, das funções do Cloud Run ou do App Engine correspondente com o mesmo nome.

Para ver que balanceadores de carga suportam back-ends de NEG sem servidor, consulte a Tabela: serviços de back-end e tipos de back-end suportados.

Para mais informações sobre NEGs sem servidor, consulte a vista geral dos grupos de pontos finais de rede sem servidor.

Vínculos de serviços

Uma associação de serviços é um back-end que estabelece uma ligação entre um serviço de back-end na malha de serviço do Google Cloud e um serviço registado no diretório de serviços. Um serviço de back-end pode fazer referência a várias associações de serviços. Um serviço de back-end com uma associação de serviço não pode fazer referência a nenhum outro tipo de back-end.

Back-ends mistos

As seguintes considerações de utilização aplicam-se quando 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.
  • Pode 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 fazer referência a uma combinação de grupos de instâncias geridos e não geridos. Para ver informações completas sobre que backends são compatíveis com que serviços de backend, consulte a tabela na secção anterior.
  • Com determinados balanceadores de carga de proxy, pode usar uma combinação de NEGs zonais (com pontos finais GCE_VM_IP_PORT) e NEGs de conetividade híbrida (com pontos finais NON_GCP_PRIVATE_IP_PORT) para configurar o balanceamento de carga híbrido. Para ver que balanceadores de carga têm esta capacidade, consulte a Tabela: serviços de back-end e tipos de back-end suportados.

Protocolo para os back-ends

Quando cria um serviço de back-end, tem de especificar o protocolo usado para comunicar com os back-ends. Só pode especificar um protocolo por serviço de back-end. Não pode especificar um protocolo secundário para usar como alternativa.

Os protocolos válidos dependem do tipo de equilibrador de carga ou se está a usar o Cloud Service Mesh.

Tabela: protocolo para os back-ends
Produto Opções de protocolo do serviço de back-end
Balanceador de carga de aplicações HTTP, HTTPS e HTTP/2
Balanceador de carga de rede de proxy

TCP ou SSL

Os equilibradores de carga de rede de proxy regionais só suportam TCP.
Balanceador de carga de rede de passagem TCP, UDP ou UNSPECIFIED
Cloud Service Mesh HTTP, HTTPS, HTTP/2, gRPC e TCP

A alteração do protocolo de um serviço de back-end torna os back-ends inacessíveis através de balanceadores de carga durante alguns minutos.

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

Este campo aplica-se a balanceadores de carga de proxy. Tem de usar a política de seleção de endereços IP para especificar o tipo de tráfego que é enviado do serviço de back-end para os seus back-ends.

Quando selecionar a política de seleção de endereços IP, certifique-se de que os seus back-ends suportam o tipo de tráfego selecionado. Para mais informações, consulte a Tabela: serviços de back-end e tipos de back-end compatíveis.

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

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

Política de seleção de endereços IP Descrição
Apenas IPv4 Envie apenas tráfego IPv4 para os back-ends do serviço de back-end, independentemente do tráfego do cliente para o GFE. As verificações de funcionamento IPv4 são usadas para verificar o estado dos back-ends.
Preferir IPv6

Priorizar a ligação IPv6 do back-end em relação à ligação IPv4 (desde que exista um back-end em bom estado com endereços IPv6).

As verificações de funcionamento monitorizam periodicamente as ligações IPv6 e IPv4 dos back-ends. O GFE tenta primeiro a ligação IPv6. Se a ligação IPv6 estiver interrompida ou for lenta, o GFE usa o happy eyeballs para voltar atrás e estabelecer ligação ao IPv4.

Mesmo que uma das ligações IPv6 ou IPv4 não esteja em bom estado, o back-end continua a ser tratado como estando em bom estado, e o GFE pode tentar ambas as ligações, sendo que o Happy Eyeballs acaba por selecionar qual usar.
Apenas IPv6

Envie apenas tráfego IPv6 para os back-ends do serviço de back-end, independentemente do tráfego do cliente para o proxy. As verificações de funcionamento IPv6 são usadas apenas para verificar o estado dos back-ends.

Não existe validação para verificar se o tipo de tráfego de back-end corresponde à política de seleção de endereços IP. Por exemplo, se tiver back-ends apenas IPv4 e selecionar Only IPv6 como a política de seleção de endereços IP, a configuração resulta em back-ends não íntegros porque o tráfego não consegue alcançar esses back-ends e o código de resposta HTTP 503 é devolvido aos clientes.

Encriptação entre o balanceador de carga e os back-ends

Para obter informações sobre a encriptação entre o equilibrador de carga e os back-ends, consulte o artigo Encriptação para os back-ends.

Distribuição de tráfego

Os valores dos seguintes campos no recurso de serviços de back-end determinam alguns aspetos do comportamento do back-end:

  • Um modo de balanceamento define como o balanceador de carga mede a disponibilidade do back-end para novos pedidos ou ligações.
  • Uma capacidade alvo define um número máximo alvo de ligações, uma taxa máxima alvo ou uma utilização máxima alvo da CPU.
  • Um escalador de capacidade ajusta a capacidade disponível geral sem modificar a capacidade alvo.

Modo de equilíbrio

O modo de equilíbrio determina se os back-ends de um equilibrador de carga ou Cloud Service Mesh conseguem processar tráfego adicional ou estão totalmente carregados.

Google Cloud tem quatro modos de equilíbrio:

  • CONNECTION: determina como a carga é distribuída com base no número total de ligações que o back-end pode processar.
  • RATE: o número máximo alvo de pedidos (consultas) por segundo (RPS/CPS). O RPS/CPS máximo alvo pode ser excedido se todos os back-ends estiverem na capacidade ou acima desta.
  • UTILIZATION: Determina como a carga é distribuída com base na utilização de instâncias num grupo de instâncias.
  • CUSTOM_METRICS: determina como a carga é distribuída com base em métricas personalizadas definidas pelo utilizador.

Modos de balanceamento disponíveis para cada balanceador de carga

Define o modo de balanceamento quando adiciona um back-end ao serviço de back-end. Os modos de balanceamento disponíveis para um balanceador de carga dependem do tipo de balanceador de carga e do tipo de back-ends.

Os equilibradores de carga de rede de passagem requerem o modo de equilíbrio CONNECTION, mas não suportam a definição de uma capacidade alvo.

Os equilibradores de carga de aplicações suportam os modos de equilíbrio RATE, UTILIZATION ou CUSTOM_METRICS para back-ends de grupos de instâncias e os modos de equilíbrio RATE ou CUSTOM_METRICS para NEGs zonais (pontos finais GCE_VM_IP_PORT) e NEGs híbridos (pontos finais NON_GCP_PRIVATE_IP_PORT). Para qualquer outro tipo de back-end suportado, o modo de balanceamento tem de ser omitido.

  • Para os balanceadores de carga de aplicações clássicos, é selecionada uma região com base na localização do cliente e se a região tem capacidade disponível, com base na capacidade de destino do modo de balanceamento de carga. Em seguida, numa região, a capacidade alvo do modo de equilíbrio é usada para calcular as proporções de quantos pedidos devem ser enviados para cada back-end na região. Os pedidos ou as ligações são, em seguida, distribuídos de forma rotativa entre instâncias ou pontos finais no back-end.

  • Para os balanceadores de carga de aplicações externos globais, é selecionada uma região com base na localização do cliente e se a região tem capacidade disponível, com base na capacidade de destino do modo de balanceamento de carga. Numa região, a capacidade alvo do modo de equilíbrio de carga é usada para calcular as proporções de quantos pedidos devem ser enviados para cada back-end (grupo de instâncias ou NEG) na região. Pode usar a política de balanceamento de carga do serviço (serviceLbPolicy) e a definição de servidor de back-end preferencial para influenciar a seleção de quaisquer servidores de back-end específicos numa região. Além disso, em cada grupo de instâncias ou NEG, a política de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído para instâncias ou pontos finais no grupo.

Os balanceadores de carga de rede de proxy suportam os modos de balanceamento CONNECTION ou UTILIZATION para back-ends de grupos de instâncias de VMs, o modo de balanceamento CONNECTION para NEGs zonais com pontos finais GCE_VM_IP_PORT e o modo de balanceamento CONNECTION para NEGs híbridos (pontos finais NON_GCP_PRIVATE_IP_PORT). Para qualquer outro tipo de back-end suportado, o modo de balanceamento tem de ser omitido.

  • Para os balanceadores de carga de rede de proxy externos globais, é selecionada uma região com base na localização do cliente e se a região tem capacidade disponível, com base na capacidade de destino do modo de balanceamento de carga. Numa região, a capacidade alvo do modo de equilíbrio de carga é usada para calcular as proporções de quantos pedidos devem ser enviados para cada back-end (grupo de instâncias ou NEG) na região. Pode usar a política de balanceamento de carga do serviço (serviceLbPolicy) e a definição de servidor de back-end preferencial para influenciar a seleção de quaisquer servidores de back-end específicos numa região. Além disso, em cada grupo de instâncias ou NEG, a política de equilíbrio de carga (LocalityLbPolicy) determina como o tráfego é distribuído às instâncias ou aos pontos finais no grupo.

  • Para equilibradores de carga de rede de proxy interno entre regiões, a região configurada é selecionada primeiro. Numa região, a capacidade alvo do modo de equilíbrio é usada para calcular as proporções de quantos pedidos devem ser enviados para cada back-end (grupo de instâncias ou NEG) na região. Pode usar a política de balanceamento de carga do serviço (serviceLbPolicy) e a definição de servidor de back-end preferencial para influenciar a seleção de quaisquer servidores de back-end específicos numa região. Além disso, em cada grupo de instâncias ou NEG, a política de equilíbrio de carga (LocalityLbPolicy) determina como o tráfego é distribuído às instâncias ou aos pontos finais no grupo.

  • Para equilibradores de carga de rede de proxy clássicos, é selecionada uma região com base na localização do cliente e se a região tem capacidade disponível com base na capacidade de destino do modo de equilíbrio de carga. Em seguida, numa região, a capacidade alvo do modo de equilíbrio de carga é usada para calcular as proporções de quantos pedidos ou ligações devem ser direcionados para cada back-end (grupo de instâncias ou NEG) na região. Depois de o balanceador de carga selecionar um back-end, os pedidos ou as ligações são distribuídos de forma rotativa entre as instâncias de VM ou os pontos finais da rede em cada back-end individual.

  • Para equilibradores de carga de rede de proxy externos regionais e equilibradores de carga de rede de proxy internos regionais, a capacidade alvo do modo de equilíbrio de carga é usada para calcular as proporções de quantos pedidos devem ser enviados para cada back-end (grupo de instâncias ou NEG). Em cada grupo de instâncias ou NEG, a política de balanceamento de carga (localityLbPolicy) determina como o tráfego é distribuído para instâncias ou pontos finais no grupo.

A tabela seguinte resume os modos de equilíbrio de carga disponíveis para cada combinação de equilibrador de carga e back-end.

Tabela: modos de equilíbrio disponíveis para cada equilibrador de carga
Balanceador de carga Back-ends Modos de equilíbrio disponíveis
Balanceador de carga de aplicações Grupos de instâncias RATE, UTILIZATION ou CUSTOM_METRICS
NEGs zonais (GCE_VM_IP_PORT pontos finais) RATE ou CUSTOM_METRICS
NEGs híbridos (NON_GCP_PRIVATE_IP_PORT pontos finais) RATE ou CUSTOM_METRICS

Balanceador de carga de rede de proxy

  • Balanceador de carga de rede de proxy externo global
  • Balanceador de carga de rede de proxy clássico
  • Balanceador de carga de rede de proxy externo regional
  • Balanceador de carga de rede de proxy interno regional
  • Balanceador de carga de rede de proxy interno entre regiões
 Grupos de instâncias CONNECTION ou UTILIZATION
NEGs zonais (GCE_VM_IP_PORT pontos finais) CONNECTION

NEGs híbridos (NON_GCP_PRIVATE_IP_PORT pontos finais)

 CONNECTION
Balanceador de carga de rede de passagem Grupos de instâncias CONNECTION
NEGs zonais (GCE_VM_IP pontos finais) CONNECTION

Se a utilização média de todas as VMs associadas a um serviço de back-end for inferior a 10%, Google Cloud pode preferir zonas específicas. Isto pode acontecer quando usa grupos de instâncias geridas regionais, grupos de instâncias geridas zonais em zonas diferentes e grupos de instâncias não geridas zonais. Este desequilíbrio zonal resolve-se automaticamente à medida que é enviado mais tráfego para o balanceador de carga.

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

Capacidade alvo

Cada modo de equilíbrio tem uma capacidade alvo correspondente, que define um dos seguintes máximos alvo:

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

Para cada modo de equilíbrio, a capacidade alvo não é um disjuntor. Um equilibrador de carga pode exceder o máximo em determinadas condições, por exemplo, se todas as VMs ou os pontos finais de back-end tiverem atingido o máximo.

Modo de equilíbrio da ligação

Para o modo de equilíbrio CONNECTION, a capacidade de destino define um número máximo de ligações abertas. Exceto para balanceadores de carga de rede de encaminhamento interno e balanceadores de carga de rede de encaminhamento externo, tem de usar uma das seguintes definições para especificar um número máximo de destinos de ligações:

  • max-connections-per-instance (por VM): número médio alvo de ligações para uma única VM.
  • max-connections-per-endpoint (por ponto final num NEG zonal): número médio de destinos de ligações para um único ponto final.
  • max-connections (por NEGs zonais e para grupos de instâncias zonais): número médio de ligações de destino para todo o NEG ou grupo de instâncias. Para grupos de instâncias geridos regionais, use max-connections-per-instance em alternativa.

A tabela seguinte mostra como o parâmetro de capacidade alvo define o seguinte:

  • A capacidade de destino para todo o back-end
  • A capacidade alvo esperada para cada instância ou ponto final
Tabela: capacidade alvo para back-ends que usam o modo de equilíbrio CONNECTION
Tipo de back-end Capacidade alvo
Se especificar Capacidade total do back-end Capacidade esperada por instância ou por ponto final
Grupo de instâncias
N instâncias,
H em bom estado
 max-connections-per-instance=X X × N (X × N)/H
NEG zonal
N pontos finais,
H em bom estado 		max-connections-per-endpoint=X X × N (X × N)/H
Grupos de instâncias
(exceto grupos de instâncias geridas regionais)

H instâncias em bom estado 		max-connections=Y Y Y/H

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

  • Num grupo de instâncias de VMs com N instâncias, a definição de max-connections-per-instance=X tem o mesmo significado que a definição de max-connections=X × N.
  • Num NEG zonal com N pontos finais, a definição de max-connections-per-endpoint=X tem o mesmo significado que a definição de max-connections=X × N.

Modo de equilíbrio de taxas

Para o modo de RATEequilíbrio, tem de definir a capacidade alvo através de um dos seguintes parâmetros:

  • max-rate-per-instance (por VM): forneça uma taxa de pedidos HTTP média alvo para uma única VM.
  • max-rate-per-endpoint (por ponto final num NEG zonal): forneça uma taxa de pedidos HTTP média de destino para um único ponto final.
  • max-rate (por NEGs zonais e para grupos de instâncias zonais): forneça uma taxa de pedidos HTTP média de destino para todo o NEG ou grupo de instâncias. Para grupos de instâncias geridos regionais, use max-rate-per-instance em alternativa.

A tabela seguinte mostra como o parâmetro de capacidade alvo define o seguinte:

  • A capacidade de destino para todo o back-end
  • A capacidade alvo esperada para cada instância ou ponto final
Tabela: capacidade alvo para back-ends que usam o modo de equilíbrio RATE
Tipo de back-end Capacidade alvo
Se especificar Capacidade total do back-end Capacidade esperada por instância ou por ponto final
Grupo de instâncias
N instâncias,
H em bom estado
 max-rate-per-instance=X X × N (X × N)/H
Pontos finais de NEG zonal
N,
H em bom estado 		max-rate-per-endpoint=X X × N (X × N)/H
Grupos de instâncias
(exceto grupos de instâncias geridas regionais)

H instâncias em bom estado 		max-rate=Y Y Y/H

Conforme ilustrado, as definições max-rate-per-instance e max-rate-per-endpoint são proxies para calcular uma taxa máxima alvo de pedidos HTTP para todo o grupo de instâncias ou todo o NEG zonal:

  • Num grupo de instâncias com N instâncias, a definição de max-rate-per-instance=X tem o mesmo significado que a definição de max-rate=X × N.
  • Num NEG zonal com pontos finais N, a definição de max-rate-per-endpoint=X tem o mesmo significado que a definição de max-rate=X × N.

Modo de equilíbrio da utilização

O modo de equilíbrio UTILIZATION não tem uma capacidade de destino obrigatória. Tem várias opções que dependem do tipo de back-end, conforme resumido na tabela na secção seguinte.

A capacidade alvo max-utilizationsó pode ser especificada por grupo de instâncias e não pode ser aplicada a uma VM específica no grupo.

O modo de equilíbrio UTILIZATION não tem uma capacidade de destino obrigatória. Quando usa a consola para adicionar um grupo de instâncias de back-end a um serviço de back-end, a consola define o valor de max-utilization como 0,8 (80%) se o modo de balanceamento de carga UTILIZATION estiver selecionado. Google Cloud Google Cloud Além disso, o modo de max-utilizationequilíbrioUTILIZATION suporta capacidades de destino mais complexas, conforme resumido na tabela na secção seguinte.

Modo de equilíbrio de métricas personalizadas

O modo de equilíbrio CUSTOM_METRICS permite-lhe definir as suas próprias métricas personalizadas que podem ser usadas para determinar como a carga é distribuída. As métricas personalizadas permitem-lhe configurar o comportamento de distribuição de tráfego do seu equilibrador de carga com base em métricas específicas dos requisitos da sua aplicação ou infraestrutura, em vez das métricas de utilização padrão ou baseadas em taxas do Google Cloud.Google Cloud

Para mais informações, consulte o artigo Métricas personalizadas para equilibradores de carga de aplicações.

Alterar o modo de balanceamento de um balanceador de carga

Para alguns equilibradores de carga ou configurações de equilibradores de carga, não pode alterar o modo de equilíbrio porque o serviço de back-end só tem um modo de equilíbrio possível. Para outros, consoante o back-end usado, pode alterar o modo de equilíbrio de carga, porque está disponível mais do que um modo para esses serviços de back-end.

Para ver que modos de balanceamento são suportados para cada equilibrador de carga, consulte a Tabela: Modos de balanceamento disponíveis para cada equilibrador de carga

Modos de equilíbrio e definições de capacidade alvo

Para produtos que suportam uma especificação de capacidade alvo, a capacidade alvo não é um disjuntor. Quando o máximo de capacidade alvo configurado é atingido numa determinada zona, os novos pedidos ou ligações são distribuídos a outras zonas que não estão a processar pedidos ou ligações na capacidade alvo. Se todas as zonas tiverem atingido a capacidade alvo, os novos pedidos ou ligações são distribuídos por excesso de preenchimento.

Balanceadores de carga de aplicações e Cloud Service Mesh

Esta tabela apresenta as combinações de modo de equilíbrio de carga e capacidade alvo disponíveis para equilibradores de carga de aplicações e a malha de serviços na nuvem.

Tabela: combinações do modo de equilíbrio e da capacidade alvo para equilibradores de carga de aplicações e Cloud Service Mesh
Tipo de back-end Modo de equilíbrio Especificação da capacidade alvo
Grupos de instâncias
  • zonal não gerido
  • zonal gerido
  • gerido regionalmente
 RATE Tem de especificar uma das seguintes opções:
  • max-rate
     (apenas suportado por grupos de instâncias zonais)
  • max-rate-per-instance
     (compatível com todos os grupos de instâncias)
UTILIZATION Opcionalmente, pode especificar uma das seguintes opções:
  • (1) max-utilization
  • (2) max-rate
     (suportado apenas por grupos de instâncias zonais)
  • (3) max-rate-per-instance
     (suportado por todos os grupos de instâncias)
  • (1) e (2) em conjunto
  • (1) e (3) em conjunto
CUSTOM_METRICS Opcionalmente, pode especificar uma das seguintes opções:
  • (1) O max-utilization da métrica (ou seja, o campo backends[].customMetrics[].maxUtilization da métrica)
  • (2) max-rate
     (suportado apenas por grupos de instâncias zonais)
  • (3) max-rate-per-instance
     (suportado por todos os grupos de instâncias)
  • (1) e (2) em conjunto
  • (1) e (3) em conjunto
O max-utilization por back-end não é suportado.

NEGs zonais

  • GCP_VM_IP_PORT

NEGs híbridos

  • NON_GCP_PRIVATE_IP_PORT
 RATE Tem de especificar uma das seguintes opções:
  • max-rate por NEG zonal
  • max-rate-per-endpoint
CUSTOM_METRICS Opcionalmente, pode especificar uma das seguintes opções:
  • (1) O max-utilization da métrica (ou seja, o campo backends[].customMetrics[].maxUtilization da métrica)
  • (2) max-rate por NEG zonal
  • (3) max-rate-per-endpoint
  • (1) e (2) em conjunto
  • (1) e (3) em conjunto
O max-utilization por back-end não é suportado.

Balanceadores de carga de rede de proxy

Esta tabela apresenta as combinações de modo de equilíbrio e capacidade alvo disponíveis para equilibradores de carga de rede de proxy.

Tabela: combinações do modo de equilíbrio e da capacidade alvo para equilibradores de carga de rede de proxy
Tipo de back-end Modo de equilíbrio Especificação da capacidade alvo
Grupos de instâncias
  • zonal não gerido
  • zonal gerido
  • gerido regionalmente
 CONNECTION Tem de especificar uma das seguintes opções:
  • max-connections
     (apenas suportado por grupos de instâncias zonais)
  • max-rate-per-instance
     (compatível com todos os grupos de instâncias)
UTILIZATION Opcionalmente, pode especificar uma das seguintes opções:
  • (1) max-utilization
  • (2) max-connections
     (suportado apenas por grupos de instâncias zonais)
  • (3) max-connections-per-instance
     (suportado por todos os grupos de instâncias)
  • (1) e (2) em conjunto
  • (1) e (3) em conjunto

NEGs zonais

  • GCP_VM_IP_PORT

NEGs híbridos

  • NON_GCP_PRIVATE_IP_PORT
 CONNECTION Tem de especificar uma das seguintes opções:
  • max-connections por NEG zonal
  • max-connections-per-endpoint

Balanceadores de carga de rede de passagem

Esta tabela apresenta as combinações de modo de equilíbrio e capacidade de destino disponíveis para equilibradores de carga de passagem.

Tabela: combinações do modo de equilíbrio e da capacidade alvo para equilibradores de carga de rede de passagem
Tipo de back-end Modo de equilíbrio Especificação da capacidade alvo
Grupos de instâncias
  • zonal não gerido
  • zonal gerido
  • gerido regionalmente
 CONNECTION Não pode especificar um número máximo de ligações de destino.
NEGs zonais
  • GCP_VM_IP
 CONNECTION Não pode especificar um número máximo de ligações de destino.

Dimensionador de capacidade

Use o escalador de capacidade para dimensionar a capacidade alvo (utilização máxima, taxa máxima ou ligações máximas) sem alterar a capacidade alvo.

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

Pode ajustar o fator de escala da capacidade para dimensionar a capacidade alvo efetiva sem alterar explicitamente um dos parâmetros --max-*.

Pode definir o fator de escala da capacidade para qualquer um destes valores:

  • O valor predefinido é 1, o que significa que o grupo publica até 100% da respetiva capacidade configurada (consoante balancingMode).
  • Um valor de 0 significa que o grupo está completamente esgotado, oferecendo 0% da sua capacidade disponível. Não pode configurar uma definição de 0 quando existe apenas um back-end associado ao serviço de back-end.
  • Um valor de 0.1 (10%) a 1.0 (100%).

Os exemplos seguintes demonstram como o fator de escala da capacidade funciona em conjunto com a definição da capacidade alvo:

  • Se o modo de equilíbrio for RATE, o max-rate é definido como 80 RPS e o escalador de capacidade é 1.0, a capacidade disponível também é 80 RPS.

  • Se o modo de equilíbrio for RATE, o max-rate é definido como 80 RPS e o fator de escala da capacidade é 0.5. A capacidade disponível é 40 RPS (0.5 times 80).

  • Se o modo de equilíbrio for RATE, o max-rate é definido como 80 RPS e o fator de escala da capacidade é 0.0, a capacidade disponível é zero (0).

Política de balanceamento de carga do serviço

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

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

Além disso, pode designar backends específicos como backends preferenciais. Estes back-ends têm de ser usados até à capacidade (ou seja, a capacidade de destino especificada pelo modo de equilíbrio do back-end) antes de os pedidos serem enviados para os back-ends restantes.

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

Política de localidade de balanceamento de carga

Para um serviço de back-end, a distribuição de tráfego baseia-se num modo de equilíbrio e numa política de localidade de equilíbrio de carga. O modo de balanceamento determina a fração do tráfego que deve ser enviada para cada back-end (grupo de instâncias ou NEG). A política de localidade de equilíbrio de carga determina (LocalityLbPolicy) como o tráfego é distribuído pelas instâncias ou pelos pontos finais em cada zona. Para grupos de instâncias geridos regionais, a política de localidade aplica-se a cada zona constituinte.

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

  • ROUND_ROBIN (predefinição): esta é a definição da política de localidade de balanceamento de carga predefinida na qual o balanceador de carga seleciona um back-end em bom estado de funcionamento por ordem rotativa.

  • WEIGHTED_ROUND_ROBIN: O balanceador de carga usa métricas personalizadas definidas pelo utilizador para selecionar a instância ou o ponto final ideal no back-end para publicar o pedido.

  • LEAST_REQUEST: Um algoritmo O(1) no qual o equilibrador de carga seleciona dois anfitriões aleatórios em bom estado e escolhe o anfitrião com menos pedidos ativos.

  • RING_HASH: este algoritmo implementa o hash consistente para os back-ends. O algoritmo tem a propriedade de que a adição ou a remoção de um anfitrião de um conjunto de N anfitriões afeta apenas 1/N dos pedidos.

  • RANDOM: o balanceador de carga seleciona um anfitrião aleatório em bom estado.

  • ORIGINAL_DESTINATION: O balanceador de carga seleciona um back-end com base nos metadados de ligação do cliente. As ligações são abertas ao endereço IP de destino original especificado no pedido do cliente recebido, antes de o pedido ser redirecionado para o equilibrador de carga.

    ORIGINAL_DESTINATION não é suportado para balanceadores de carga de aplicações externos globais e regionais.

  • MAGLEV: implementa a aplicação de hash consistente aos back-ends e pode ser usado como substituição da política RING_HASH. O Maglev não é tão estável como o RING_HASH, mas tem tempos de criação de procura de tabelas e tempos de seleção de anfitriões mais rápidos. Para mais informações sobre o Maglev, consulte o livro branco do Maglev.

  • WEIGHTED_MAGLEV: implementa o balanceamento de carga ponderado por instância através de ponderações comunicadas pelas verificações de estado. Se esta política for usada, o serviço de back-end tem de configurar uma verificação de funcionamento baseada em HTTP não antiga, e espera-se que as respostas da verificação de funcionamento contenham 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 equilíbrio de carga são tomadas com base nas ponderações por instância comunicadas nas respostas da verificação de estado processadas mais recentemente, desde que todas as instâncias comuniquem uma ponderação válida ou comuniquem UNAVAILABLE_WEIGHT. Caso contrário, o balanceamento de carga permanece com peso igual.

    WEIGHTED_MAGLEV só é suportado para equilibradores de carga de rede de encaminhamento externo. Para ver um exemplo, consulte o artigo Configure o balanceamento de carga ponderado para balanceadores de carga de rede de passagem externos.

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

  • Balanceador de carga de aplicações externo global
  • Balanceador de carga de aplicações externo regional
  • Balanceador de carga de aplicações interno entre regiões
  • Balanceador de carga de aplicações interno regional
  • Balanceador de carga de rede de encaminhamento externo

Tenha em atenção que o valor predefinido efetivo da política de localidade de equilíbrio de carga (localityLbPolicy) muda de acordo com as definições de afinidade de sessão. Se a afinidade de sessão não estiver configurada, ou seja, se a afinidade de sessão permanecer no valor predefinido de NONE, o valor predefinido para localityLbPolicy é ROUND_ROBIN. Se a afinidade de sessão estiver definida para um valor diferente de NONE, o valor predefinido de localityLbPolicy é MAGLEV.

Para configurar uma política de localidade de equilíbrio de carga, pode usar a consola, o gcloud (--locality-lb-policy) ou a API (localityLbPolicy).Google Cloud

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

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

Os serviços de back-end autogeridos internos suportam 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 zonais

Se escolher o RATEmodo de equilíbrio, tem de especificar uma taxa máxima, uma taxa máxima por instância ou uma taxa máxima por ponto final.

Para mais informações sobre a malha de serviços do Google Cloud, consulte o artigo Conceitos da malha de serviços do Google Cloud.

Subconjunto de back-end

A subdivisão de back-ends é uma funcionalidade opcional que melhora o desempenho e a escalabilidade ao atribuir um subconjunto de back-ends a cada uma das instâncias de proxy.

A criação de subconjuntos no back-end é suportada para o seguinte:

  • Balanceador de carga de aplicações interno regional
  • Balanceador de carga de rede de encaminhamento interno

Subconjuntos de back-end para balanceadores de carga de aplicações internos regionais

O Application Load Balancer interno entre regiões não suporta a criação de subconjuntos de back-end.

Para os Application Load Balancers internos regionais, a subdivisão de back-ends atribui automaticamente apenas um subconjunto dos back-ends no serviço de back-end regional a cada instância de proxy. Por predefinição, cada instância de proxy abre ligações a todos os back-ends num serviço de back-end. Quando o número de instâncias de proxy e os back-ends são elevados, a abertura de ligações a todos os back-ends pode causar problemas de desempenho.

Ao ativar a subdivisão, cada proxy só abre ligações a um subconjunto dos back-ends, o que reduz o número de ligações mantidas abertas a cada back-end. Reduzir o número de ligações abertas em simultâneo a cada back-end pode melhorar o desempenho dos back-ends e dos proxies.

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

Comparação do balanceador de carga de aplicações interno sem e com a subdivisão do back-end.
Comparação do balanceador de carga de aplicações interno sem e com subconjuntos de back-end (clique para aumentar).

Além disso, pode refinar o tráfego de equilíbrio de carga para os back-ends definindo a política localityLbPolicy. Para mais informações, consulte as políticas de tráfego.

Para ler acerca da configuração da subdivisão de back-end para balanceadores de carga de aplicações internos, consulte o artigo Configure a subdivisão de back-end.

Advertências relacionadas com a subdivisão do back-end para o balanceador de carga de aplicações interno
  • Embora a criação de subconjuntos no back-end seja concebida para garantir que todas as instâncias do back-end permanecem bem utilizadas, pode introduzir algum viés na quantidade de tráfego que cada back-end recebe. Recomendamos que defina o localityLbPolicy como LEAST_REQUEST para serviços de back-end sensíveis ao equilíbrio da carga de back-end.
  • A ativação ou a desativação da criação de subconjuntos interrompe as associações existentes.
  • A subdivisão de back-end requer que a afinidade de sessão seja NONE (um hash de 5 tuplos). As outras opções de afinidade de sessão só podem ser usadas se a restrição de subconjuntos de back-end estiver desativada. Os valores predefinidos das flags --subsetting-policy e --session-affinity são ambos NONE, e só uma delas de cada vez pode ser definida com um valor diferente.

Subconjuntos de back-end para o balanceador de carga de rede de encaminhamento interno

A subdivisão de back-ends para balanceadores de carga de rede de passagem interna permite-lhe dimensionar o balanceador de carga de rede de passagem interna para suportar um número maior de instâncias de VM de back-end por serviço de back-end interno.

Para ver informações sobre como a criação de subconjuntos afeta este limite, consulte a secção "Serviços de back-end" de Quotas e limites de recursos de equilíbrio de carga.

Por predefinição, a criação de subconjuntos está desativada, o que limita o serviço de back-end à distribuição a um máximo de 250 instâncias ou pontos finais de back-end. Se o seu serviço de back-end precisar de suportar mais de 250 back-ends, pode ativar a subdivisão. Quando a divisão em subconjuntos está ativada, é selecionado um subconjunto de instâncias de back-end para cada ligação do cliente.

O diagrama seguinte mostra um modelo reduzido da diferença entre estes dois modos de funcionamento.

Comparação de um balanceador de carga de rede de encaminhamento interno sem e com a criação de subconjuntos.
Comparação de um Network Load Balancer de encaminhamento interno sem e com subconjuntos (clique para aumentar).

Sem a criação de subconjuntos, o conjunto completo de back-ends saudáveis é melhor utilizado e as novas ligações de clientes são distribuídas por todos os back-ends saudáveis de acordo com a distribuição de tráfego. A criação de subconjuntos impõe restrições de balanceamento de carga, mas permite que o balanceador de carga suporte mais de 250 back-ends.

Para ver instruções de configuração, consulte a secção Subconjuntos.

Advertências relacionadas com a subdivisão do back-end para o balanceador de carga de rede de passagem interno
  • Quando a criação de subconjuntos está ativada, nem todos os back-ends recebem tráfego de um determinado remetente, mesmo quando o número de back-ends é pequeno.
  • Para o número máximo de instâncias de back-end quando a criação de subconjuntos está ativada, consulte a página de quotas .
  • Apenas a afinidade de sessão de 5 tuplos é suportada com a criação de subconjuntos.
  • O espelhamento de pacotes não é suportado com a seleção de subconjuntos.
  • A ativação ou a desativação da criação de subconjuntos interrompe as associações existentes.
  • Se os clientes no local precisarem de aceder a um Network Load Balancer de passagem interno, a criação de subconjuntos pode reduzir substancialmente o número de back-ends que recebem ligações dos seus clientes no local. Isto deve-se ao facto de a região do túnel do Cloud VPN ou do anexo de VLAN do Cloud Interconnect determinar o subconjunto dos back-ends do balanceador de carga. Todos os pontos finais do Cloud VPN e do Cloud Interconnect numa região específica usam o mesmo subconjunto. São usados diferentes subconjuntos em diferentes regiões.

Preços de subconjuntos de back-end

Não é cobrado qualquer valor pela utilização da segmentação secundária de back-end. Para mais informações, consulte a secção Preços de todas as redes.

Afinidade de sessão

A afinidade de sessão permite-lhe controlar a forma como o balanceador de carga seleciona back-ends para novas ligações de forma previsível, desde que o número de back-ends em bom estado permaneça constante. Isto é útil para aplicações que precisam que vários pedidos de um determinado utilizador sejam direcionados para o mesmo back-end ou ponto final. Normalmente, estas aplicações incluem servidores com estado usados pela publicação de anúncios, jogos ou serviços com uma grande quantidade de cache interna.

Google Cloud Os balanceadores de carga oferecem afinidade de sessão com base no melhor esforço. Fatores como a alteração dos estados de verificação de funcionamento do back-end, a adição ou a remoção de back-ends, as alterações nos pesos do back-end (incluindo a ativação ou a desativação do equilíbrio ponderado) ou as alterações à capacidade do back-end, conforme medido pelo modo de equilíbrio, podem interromper a afinidade de sessão.

O equilíbrio de carga com afinidade de sessão funciona bem quando existe uma distribuição razoavelmente grande de ligações únicas. Razoavelmente grande significa, pelo menos, várias vezes o número de back-ends. Testar um equilibrador de carga com um pequeno número de ligações não resulta numa representação precisa da distribuição de ligações de clientes entre os back-ends.

Por predefinição, todos os Google Cloud equilibradores de carga selecionam back-ends através de um hash de 5 tuplos (--session-affinity=NONE), da seguinte forma:

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

Para saber mais sobre a afinidade de sessão para equilibradores de carga de rede de encaminhamento, consulte os seguintes documentos:

Para saber mais sobre a afinidade de sessão para equilibradores de carga de aplicações, consulte os seguintes documentos:

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

Limite de tempo do serviço de back-end

A maioria dos Google Cloud balanceadores de carga tem um tempo limite do serviço de back-end. O valor predefinido é 30 segundos. O intervalo completo de valores de tempo limite permitidos é de 1 a 2 147 483 647 segundos.

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

    Para mais detalhes sobre o limite de tempo do serviço de back-end para cada balanceador de carga, consulte o seguinte:

  • Para balanceadores de carga de rede de proxy externos, o limite de tempo é um limite de tempo de inatividade. Para permitir mais ou menos tempo antes de a ligação ser eliminada, altere o valor de tempo limite. Este limite de tempo de inatividade também é usado para ligações WebSocket.

  • Para equilibradores de carga de rede de encaminhamento interno e equilibradores de carga de rede de encaminhamento externo, pode definir o valor do tempo limite do serviço de back-end através de gcloud ou da API, mas o valor é ignorado. O limite de tempo do serviço de back-end não tem significado para estes balanceadores de carga de encaminhamento.

  • Para a Cloud Service Mesh, o campo de tempo limite do serviço de back-end (especificado através de timeoutSec) não é suportado com serviços gRPC sem proxy. Para esses serviços, configure o limite de tempo do serviço de back-end através do campo maxStreamDuration. Isto deve-se ao facto de o gRPC não suportar a semântica de timeoutSec que especifica o tempo de espera de um back-end para devolver uma resposta completa após o envio do pedido. O tempo limite do gRPC especifica o tempo de espera desde o início da stream até a resposta ser totalmente processada, incluindo todas as novas tentativas.

Verificações de funcionamento

Cada serviço de back-end cujos back-ends sejam grupos de instâncias ou NEGs zonais tem de ter uma verificação de estado associada. Os serviços de back-end que usam um NEG sem servidor ou um NEG de Internet global como back-end não podem fazer referência a uma verificação de estado.

Quando cria um balanceador de carga através da Google Cloud consola, pode criar a verificação de funcionamento, se for necessária, quando cria o balanceador de carga, ou pode fazer referência a uma verificação de funcionamento existente.

Quando cria um serviço de back-end com um grupo de instâncias ou back-ends NEG zonais através da CLI do Google Cloud ou da API, tem de fazer referência a uma verificação de estado existente. Consulte o guia do balanceador de carga na vista geral das verificações de funcionamento para ver detalhes sobre o tipo e o âmbito da verificação de funcionamento necessária.

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

Funcionalidades adicionais ativadas no recurso de serviço de back-end

As seguintes funcionalidades opcionais são suportadas por alguns serviços de back-end.

Cloud CDN

A RFC usa a rede de limite global da Google para publicar conteúdo mais perto dos utilizadores, o que acelera os seus Websites e aplicações. O Cloud CDN está ativado nos serviços de back-end usados pelos balanceadores de carga de aplicações externos globais. O balanceador de carga fornece os endereços IP e as portas de front-end que recebem pedidos, e os back-ends que respondem aos pedidos.

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

O Cloud CDN é incompatível com o IAP. Não é possível ativá-las no mesmo serviço de back-end.

Cloud Armor

Se usar um dos seguintes balanceadores de carga, pode adicionar proteção adicional às suas aplicações ativando o Cloud Armor no serviço de back-end durante a criação do balanceador de carga:

Se usar a Google Cloud consola, pode fazer uma das seguintes ações:

  • Selecione uma política de segurança do Cloud Armor existente.
  • Aceitar a configuração de uma política de segurança de limitação de taxa do Cloud Armor predefinida com um nome, uma contagem de pedidos, um intervalo, uma chave e parâmetros de limitação de taxa personalizáveis. Se usar o Cloud Armor com um serviço de proxy a montante, como um fornecedor de RFC, o Enforce_on_key deve ser definido como um endereço IP XFF.
  • Opte por desativar a proteção do Cloud Armor selecionando Nenhum.

IAP

A IAP permite-lhe estabelecer uma camada de autorização central para aplicações acedidas por HTTPS, para que possa usar um modelo de controlo de acesso ao nível da aplicação em vez de depender de firewalls ao nível da rede. O IAP é suportado por determinados balanceadores de carga de aplicações.

O IAP é incompatível com o Cloud CDN. Não é possível ativá-las no mesmo serviço de back-end.

Funcionalidades avançadas de gestão de tráfego

Para saber mais acerca das funcionalidades avançadas de gestão de tráfego configuradas nos serviços de back-end e nos mapas de URLs associados aos equilibradores de carga, consulte o seguinte:

API e gcloud referência

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

O que se segue?

Para ver documentação e informações relacionadas sobre como os serviços de back-end são usados no equilíbrio de carga, reveja o seguinte:

Para vídeos relacionados: