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. A maioria das opções tem valores padrão que facilitam a configuração e permitem um início rápido.

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

  • Balanceamento de carga HTTP(S) externo
  • Balanceamento de carga HTTP(S) interno
  • Balanceamento de carga de proxy SSL
  • Balanceamento de carga de proxy TCP
  • Balanceamento de carga TCP/UDP interno

O Traffic Director também usa serviços de back-end. O balanceamento de carga de rede não usa um serviço de back-end.

Os balanceadores de carga, proxies Envoy e clientes gRPC sem proxy usam as informações de configuração no recurso de serviço de back-end para executar as seguintes funções:

  • 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). Um balanceador de carga HTTP(S) externo pode ser configurado para usar um bucket de back-end em vez de um serviço de back-end. Para informações sobre o uso de buckets de back-end com balanceadores de carga HTTP(S) externos, consulte Como configurar um balanceador de carga com buckets de back-end.
  • 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 o Cloud CDN está ativado (somente balanceadores de carga HTTP(S) externos).
  • Determinar se as políticas de segurança do Google Cloud Armor estão ativadas (somente balanceadores de carga HTTP(S) externos).
  • Determinar se o Identity-Aware Proxy está ativado (somente balanceadores de carga HTTP(S) externos).

Você define alguns valores ao criar um serviço de back-end. E define outros valores ao adicionar um back-end a um serviço de back-end.

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 número máximo de serviços de back-end, o escopo de um serviço de back-end, o tipo de back-ends que cada serviço de back-end pode usar e o 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
Balanceamento de carga HTTP(S) externo Vários 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 por zona
  • Todos os NEGs sem servidor: um ou mais serviços do App Engine, Cloud Run ou Cloud Functions
  • Uma Internet NEG
EXTERNAL
Balanceamento de carga HTTP(S) interno Vários 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 por zona
INTERNAL_MANAGED
Balanceamento de carga de 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 por zona, ou
  • Uma Internet NEG
EXTERNAL
Balanceamento de carga de 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 por zona, ou
  • Uma Internet NEG
EXTERNAL
Balanceamento de carga TCP/UDP interno 1 Regional, mas pode ser configurado para ser globalmente acessível 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
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 por zona
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 recurso em que um balanceador de carga do Google Cloud, um proxy Envoy configurado ou o cliente gRPC configurado pelo Traffic Director distribui o tráfego. Cada serviço de back-end está associado a um ou mais back-ends compatíveis. Há vários tipos de back-ends:

Além disso, usando um bucket de back-end em vez do serviço de back-end, você pode configurar o back-end do 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 disponíveis são:

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP
  • gRPC (somente no Traffic Director)

Os protocolos são válidos de acordo com o tipo de balanceador de carga ou se você estiver usando o Traffic Director. Para mais informações, consulte Recursos do balanceador de carga e Recursos do Traffic Director.

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 balanceamento de carga HTTP(S), de proxy TCP e de proxy SSL, o Google criptografa automaticamente o tráfego entre o Google Front ends (GFEs) e os back-ends que residem no Google Cloud.

Além dessa criptografia no nível da rede, é possível usar um protocolo seguro, como SSL, HTTPS ou HTTP/2 (usando TLS), como o protocolo de serviço de back-end para balanceadores de carga baseados em GFE e também para balanceamento de carga HTTP(S) interno e Traffic Director.

Quando um balanceador de carga se conecta aos back-ends usando um protocolo de serviço de back-end seguro, o balanceador de carga é o cliente SSL ou HTTPS. Da mesma forma, quando um proxy do lado do cliente configurado com Traffic Director se conecta aos back-ends usando um protocolo de serviço de back-end seguro, o proxy é o cliente SSL ou HTTPS.

Um protocolo seguro para se conectar a instâncias de back-end é recomendado nos seguintes casos:

  • Quando você precisa de uma conexão criptografada e auditável do balanceador de carga (ou do Traffic Director) para as instâncias de back-end

  • Quando o balanceador de carga se conecta a uma instância de back-end fora do Google Cloud (por meio de um NEG da Internet). A comunicação com um back-end do NEG da Internet pode transitar pela Internet pública. Quando o balanceador de carga se conecta a um NEG da Internet, o certificado precisa ser assinado por uma CA pública e atender aos requisitos de validação.

Para usar um protocolo seguro entre o balanceador de carga e os back-ends, lembre-se dos seguintes requisitos:

  • É preciso configurar os serviços de back-end do balanceador de carga para usar o protocolo SSL (TLS), HTTPS ou HTTP/2

  • Nas instâncias de back-end, é preciso configurar o software para disponibilizar o tráfego usando o mesmo protocolo do serviço de back-end. Por exemplo, se o serviço de back-end usa HTTPS, configure as instâncias de back-end para usar HTTPS. Se você usar o protocolo HTTP/2, seus back-ends precisarão usar TLS. Para instruções de configuração, consulte a documentação do software da instância de back-end

  • É necessário instalar chaves privadas e certificados nas instâncias de back-end. Esses certificados não precisam corresponder ao certificado SSL do balanceador de carga. Para instruções de instalação, consulte a documentação do software da instância de back-end

  • É preciso configurar o software em execução nas instâncias de back-end para operar como um servidor SSL ou HTTPS. Para instruções de configuração, consulte a documentação do software da instância de back-end.

Lembre-se também das seguintes ressalvas:

  • quando um balanceador de carga inicia uma sessão TLS para back-ends, o GFE não usa a extensão SNI (Server Name Indication);

  • quando um balanceador de carga se conecta a back-ends que estão no Google Cloud, ele aceita qualquer certificado presente nos back-ends; Os balanceadores de carga não realizam a validação do certificado. Por exemplo, o certificado é tratado como válido mesmo nas seguintes circunstâncias:

    • O certificado é autoassinado
    • O certificado é assinado por uma autoridade de certificação (CA, na sigla em inglês) desconhecida
    • O certificado expirou ou ainda não é válido
    • Os atributos CN e subjectAlternativeName não correspondem a um cabeçalho Host ou registro PTR DNS.

Para mais informações sobre criptografia do Google, consulte Criptografia em trânsito no Google Cloud.

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 os endereços IP internos da interface de rede principal. Como o GFE é um proxy, as VMs de back-end não exigem endereços IP externos.

  • Para balanceadores de carga HTTP(S) internos, balanceadores de carga TCP/UDP internos e Traffic Director: as VMs de back-end para balanceadores de carga internos e para o Traffic Director não exigem endereços IP externos.

Portas nomeadas

Um balanceador de carga pode detectar no front-end um ou mais números de porta configurados na regra de encaminhamento do balanceador de carga. No back-end, o balanceador de carga pode encaminhar o tráfego para o mesmo ou para um número de porta diferente. Esse é o número da 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.

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. Em seguida, consulte a porta nomeada 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.

Os seguintes tipos de balanceador de carga exigem que cada grupo de instâncias do back-end do Compute Engine tenha uma porta nomeada:

  • Balanceamento de carga HTTP(S) interno
  • Balanceamento de carga HTTP(S)
  • Balanceamento de carga de proxy SSL
  • Balanceamento de carga de proxy TCP

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

Por exemplo, é possível definir a porta nomeada em um grupo de instâncias da seguinte maneira, em que o nome do serviço é 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, defina --port-name no serviço de back-end como my-service-name:

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

Observe o seguinte:

  • Cada serviço de back-end se inscreve em um único nome de porta. Consequentemente, cada um dos grupos 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.

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

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 um balanceador de carga de passagem, não um proxy, e seu 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 equilibrar o tráfego para diferentes portas, crie 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 nomeada exclusiva.

  • É possível usar o mesmo grupo de instâncias de um back-end para mais de um serviço de back-end. Nessa situação, todos os serviços de back-end precisam usar o mesmo modo de balanceamento.

    Essa é uma configuração complexa e nem sempre possível. Por exemplo, o mesmo grupo de instâncias não pode ser simultaneamente um back-end para um serviço de back-end de um balanceador de carga TCP/UDP interno e um balanceador de carga HTTP(S) externo. Um balanceador de carga TCP/UDP interno usa serviços de back-end cujos back-ends precisam usar o modo de balanceamento CONNECTION, enquanto um balanceador de carga HTTP(S) externo usa serviços de back-end com suporte aos modos RATE ou UTILIZATION. Como nenhum modo de balanceamento é comum a ambos, não é possível usar o mesmo grupo de instâncias como um back-end para os dois tipos de balanceador de carga.

    • 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 do grupo de instâncias gerenciadas for Utilização da CPU ou Métrica do Cloud Monitoring, que não estão relacionadas à capacidade de serviço do balanceador de carga. O uso de uma dessas métricas de escalonamento automático pode impedir o escalonamento errático resultante da métrica de escalonamento automático Uso do balanceamento de carga HTTP.

Grupos de endpoints de rede por zona

Um serviço de back-end que usa grupos de endpoints de rede por zona (NEGs, na sigla em inglês) como back-ends distribui o tráfego entre aplicativos ou contêineres em execução nas VMs.

Um endpoint de rede por zona é uma combinação de um endereço IP e uma porta, especificados de duas maneiras:

  • Especificando um par IP address:port, como 10.0.1.1:80.
  • Especificando apenas um endereço IP de endpoint de rede. A porta padrão do NEG é usada automaticamente como a porta do par IP address:port.

Os endpoints de rede representam serviços pelos respectivos endereço IP e porta em vez de se referir a determinada VM. Um grupo de endpoints de rede é um agrupamento lógico de endpoints 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 hospedados 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, consulte Visão geral do grupo de endpoints da 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:

  • Um serviço ou um grupo de serviços do Cloud Run que compartilham o mesmo padrão de URL.
  • Uma função ou um grupo de funções do Cloud Functions que compartilham o mesmo padrão de URL.
  • Um aplicativo do App Engine (Standard ou Flex), um serviço específico dentro de um aplicativo ou até mesmo uma versão específica de um aplicativo.

Para mais informações, 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 usado pelo balanceador de carga para determinar back-ends candidatos a novas solicitações ou conexões.
  • Uma capacidade desejada, que define um número máximo de conexões, uma taxa máxima ou uma meta de utilização máxima da CPU.
  • Um escalonador de capacidade, que pode ser usado para ajustar a capacidade geral disponível 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 definir um modo de balanceamento para um NEG sem servidor.

Modo de balanceamento Esquemas de balanceamento de carga compatíveis Protocolos de serviço de back-end compatíveis Tipos de back-end compatíveis Produtos aplicáveis
CONNECTION EXTERNAL
INTERNAL
As opções de protocolo SSL, TCP, UDP
são limitadas pelo tipo de balanceador de carga. Por exemplo, o balanceamento de carga TCP/UDP interno usa apenas o protocolo TCP ou UDP.
Grupos de instâncias ou NEGs por zona, caso sejam compatíveis.
Por exemplo, o balanceamento de carga TCP/UDP interno não é compatível com NEGs por zona.
  • Balanceamento de carga de proxy SSL
  • Balanceamento de carga de proxy TCP
  • Balanceamento de carga TCP/UDP interno
RATE EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
HTTP, HTTPS, HTTP2, gRPC Grupos de instâncias ou NEGs por zona
  • Balanceamento de carga HTTP(S) externo
  • Balanceamento de carga HTTP(S) interno
  • Traffic Director (INTERNAL_SELF_MANAGED; HTTP e somente protocolos gRPC)
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
Qualquer protocolo Somente grupos de instâncias. Os NEGs por zona não são compatíveis com o modo de utilização.
  • Balanceamento de carga HTTP(S) externo
  • Balanceamento de carga HTTP(S) interno
  • Balanceamento de carga de proxy SSL
  • Balanceamento de carga de proxy TCP
  • Traffic Director (INTERNAL_SELF_MANAGED; HTTP e somente protocolos gRPC)

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:

  • Os serviços de back-end para balanceadores de carga TCP/UDP internos só podem usar o modo de balanceamento CONNECTION
  • Os serviços de back-end para balanceadores de carga HTTP(S) externos em que todos os back-ends são NEGs podem usar apenas o modo de balanceamento RATE
  • Os serviços de back-end para balanceadores de carga HTTP(S) internos em que todos os back-ends são NEGs podem usar apenas o modo de balanceamento RATE
  • Os serviços de back-end para balanceadores de carga de proxy SSL em que todos os back-ends são NEGs podem usar apenas o modo de balanceamento CONNECTION
  • Os serviços de back-end para balanceadores de carga de proxy TCP em que todos os back-ends são NEGs podem usar apenas o modo de balanceamento CONNECTION.

Para alguns balanceadores de carga, é possível alterar o modo de balanceamento, porque mais de um modo está disponível para os serviços de back-end:

  • Os serviços de back-end para balanceadores de carga HTTP(S) externos em que todos os back-ends são grupos de instâncias podem usar o modo de balanceamento RATE ou UTILIZATION
  • Os serviços de back-end para balanceadores de carga HTTP(S) internos em que todos os back-ends são grupos de instâncias podem usar o modo de balanceamento RATE ou UTILIZATION
  • Os serviços de back-end para balanceadores de carga de proxy SSL em que todos os back-ends são grupos de instâncias podem usar o modo de balanceamento CONNECTION ou UTILIZATION
  • Os serviços de back-end para balanceadores de carga de proxy TCP em que todos os back-ends são grupos de instâncias podem usar o modo de balanceamento CONNECTION ou UTILIZATION.

Se o mesmo grupo de instâncias for um back-end para vários serviços de back-end, ele precisará usar o mesmo modo de balanceamento para cada serviço de back-end. 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.

Também não é possível usar o mesmo grupo de instâncias de um back-end para algumas combinações diferentes de serviço de back-end. Por exemplo, não é possível usar, simultaneamente, o mesmo grupo de instâncias como back-end para um balanceador de carga TCP/UDP interno, compatível apenas com o modo de balanceamento CONNECTION, e para um balanceador de carga HTTP(S) externo, que aceita os modos de balanceamento RATE ou UTILIZATION.

Capacidade desejada

Cada modo de balanceamento tem uma capacidade desejada correspondente, que define um número máximo de conexões, uma taxa máxima ou uma meta de utilização máxima de CPU. Para cada modo de balanceamento, a capacidade desejada não é um disjuntor. Um balanceador de carga excederá o máximo em determinadas condições. Por exemplo, se todas as VMs ou endpoints de back-end tiverem atingido esse máximo.

  • 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, especifique um número máximo de conexões usando um destes três métodos: especifique o número máximo de conexões para cada VM usando max-connections-per-instance ou para cada endpoint em um NEG por zona usando max-connections-per-endpoint. Para NEGs por zona e para grupos de instâncias não gerenciadas por zonas, especifique max-connections para todo o grupo.

    Quando você especifica max-connections-per-instance ou max-connections-per-endpoint, o Google Cloud calcula o objetivo efetivo por VM ou endpoint da seguinte maneira:

    • (máximo de conexões por VM * número total de VMs) / número de VMs íntegras
    • (máximo de conexões por endpoint * número total de endpoints) / número de endpoints íntegros

    Quando você especifica max-connections, o Google Cloud calcula o objetivo efetivo por VM ou endpoint desta maneira:

    • máximo de conexões / número de VMs íntegras
    • máximo de conexões / número de endpoint íntegros
  • Para o modo de balanceamento RATE, a capacidade desejada define uma taxa máxima desejada para solicitações HTTP. Especifique uma taxa desejada usando um destes três métodos: especifique uma taxa máxima desejada para cada VM usando max-rate-per-instance ou para cada endpoint em um NEG por zona usando max-rate-per-endpoint. Para NEGs por zona e para grupos de instâncias não gerenciadas por zonas, especifique max-rate para todo o grupo.

    Quando você especifica max-rate-per-instance ou max-rate-per-endpoint, o Google Cloud calcula a taxa do objetivo efetivo por VM ou endpoint da seguinte maneira:

    • taxa máxima por VM * número total de VMs / número de VMs íntegras
    • taxa máxima por endpoint * número total de endpoints / número de endpoints íntegros

    Quando você especifica max-rate, o Google Cloud calcula a taxa do objetivo efetivo por VM ou endpoint desta maneira:

    • taxa máxima / número de VMs íntegras
    • taxa máxima / número de endpoints íntegros
  • Para o modo de balanceamento UTILIZATION, não há uma capacidade desejada obrigatória. Você tem várias opções que dependem do tipo de back-end, conforme resumido na tabela a seguir.

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
Balanceamento de carga TCP/UDP interno Grupo de instâncias CONNECTION Não é possível especificar um número máximo de conexões.
Balanceamento de carga de proxy SSL, balanceamento de carga de proxy TCP Grupo de instâncias CONNECTION Você precisa especificar uma das seguintes opções:
1. máximo de conexões por grupo de instâncias por zonas
2. máximo de conexões por instância
 (grupos de instâncias regionais ou por zona)
UTILIZATION É possível opcionalmente especificar uma das seguintes opções:
1. máximo de utilização
2. máximo de conexões por grupo de instâncias por zonas
3. máximo de conexões por instância
 (grupos de instâncias por zonas ou regionais)
4. 1 e 2 juntos
5. 1 e 3 juntos
NEG por zona CONNECTION Você precisa especificar uma das seguintes opções:
1. máximo de conexões por NEG por zona
2. máximo de conexões por endpoint
Balanceamento de carga HTTP(S), balanceamento de carga HTTP(S) interno, Traffic Director Grupo de instâncias RATE Você precisa especificar uma das seguintes opções:
1. taxa máxima por grupo de instâncias por zonas
2. taxa máxima por instância
 (grupos de instâncias por zonas ou regionais)
UTILIZATION É possível opcionalmente especificar uma das seguintes opções:
1. utilização máxima
2. taxa máxima por grupo de instâncias por zonas
3. taxa máxima por instância
 (grupos de instâncias por zonas ou regionais)
4. 1 e 2 juntos
5. 1 e 3 juntos
NEG por zona RATE Você precisa especificar uma das seguintes opções:
1. taxa máxima por NEG por zona
2. taxa máxima por 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. A única exceção é o balanceador de carga TCP/UDP interno.

Por padrão, o escalonador de capacidade é 1.0 (100%). Isso significa, por exemplo, que, se a porcentagem de uso de uma instância de back-end for de 80% e a utilização máxima for definida como 80%, o serviço de back-end deixará de enviar solicitações para essa instância:

capacity-scaler: 1 * 0.8

Defina o escalonador de capacidade como 0.0 ou de 0.1 (10%) para 1.0 (100%). Não é possível definir uma configuração maior que 0.0 e menor que 0.1. Um fator de escalonamento de zero (0.0) impede todas as novas conexões. Não é possível definir uma configuração 0.0 quando há apenas um back-end anexado ao serviço de back-end.

Como usar o escalonador de capacidade quando dois serviços de back-end compartilham um back-end de grupo de instâncias

Quando você tem dois serviços de back-end que usam o mesmo back-end de grupo de instâncias, é necessário alocar a capacidade do grupo de instâncias entre os dois serviços de back-end.

Por exemplo, defina o escalonador de capacidade como 0.5 nos dois serviços de back-end e cada serviço de back-end recebe 40% da capacidade do grupo de instâncias:

capacity-scaler: 0.5 * 0.8

Quando cada serviço de back-end usa 40% da capacidade do grupo de instâncias, as solicitações não são mais enviadas para esse grupo.

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 (grupo de instâncias ou NEG) de acordo com o modo de balanceamento do back-end e, depois de selecionar um back-end, 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

Sem a afinidade da sessão, os balanceadores de carga distribuem novas solicitações com base em um hash de cinco tuplas que consiste no endereço IP e na porta de origem do cliente, no endereço IP e na porta de destino do balanceador de carga e no protocolo L3 (protocolo TCP para todos os balanceadores de carga que usam serviços de back-end). O modo de balanceamento do grupo de instâncias de back-end ou do NEG por zona determina quando o back-end atingiu sua capacidade. Alguns aplicativos, como servidores com estado usados pela veiculação de anúncios, jogos ou serviços com uso intenso do cache interno, precisam de várias solicitações de um determinado usuário para serem direcionados para o mesmo back-end ou endpoint.

A afinidade da sessão está disponível para o tráfego TCP, incluindo os protocolos SSL, HTTP(S) e HTTP/2. Enquanto uma instância de back-end ou endpoint permanece íntegra e não atingiu sua capacidade, conforme definido pelo modo de balanceamento, o balanceador de carga direciona as solicitações subsequentes para a mesma VM ou endpoint de back-end. Lembre-se do seguinte ao configurar a afinidade da sessão:

  • O tráfego UDP não tem o conceito de sessão. Portanto, a afinidade da sessão não faz sentido para esse tipo de tráfego.

  • Quando os serviços gRPC sem proxy forem configurados, o Traffic Director não será compatível com afinidade de 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 diferente de None com o modo de balanceamento UTILIZATION 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 cheias, interrompendo a afinidade da sessão. Em vez disso, use o modo de balanceamento RATE ou CONNECTION, conforme compatibilidade com o balanceador de carga escolhido, para reduzir a chance de corromper a afinidade da sessão.

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

Produto Opções de afinidade de sessão
TCP/UDP interno • Nenhuma
• IP do cliente
• IP e protocolo do cliente
• IP, protocolo e porta do cliente
Proxy TCP
Proxy SSL
• Nenhuma
• IP do cliente
HTTP(S) externo • Nenhuma
• IP do cliente
• Cookie gerado
HTTP(S) interno • Nenhuma
• IP do cliente
• cookie gerado
• campo de cabeçalho
• cookie HTTP
Rede O balanceamento de carga de rede não usa serviços de back-end. Em vez disso, você define a afinidade da sessão para balanceadores de carga de rede por meio de pools de destino. Consulte o parâmetro sessionAffinity em Pools de destino.
Traffic Director • Nenhuma
• IP do cliente
• cookie gerado
• campo de cabeçalho
• cookie 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 próprio endereço IP (por exemplo, um dispositivo móvel migrando de rede para rede), a afinidade baseada em cookie permitirá que o balanceador de carga reconheça conexões subsequentes desse cliente em vez de tratá-las como novas.

Quando um balanceador de carga cria um cookie para a afinidade gerada baseada em cookie, ele define o atributo path do cookie como /. Se o mapa de URLs do balanceador de carga tiver uma correspondência de caminhos que especifique mais de um serviço de back-end para um determinado nome de host, todos os serviços de back-end que usam a afinidade da sessão baseada em cookie compartilharão o mesmo cookie de sessão.

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

Afinidade do campo de cabeçalho

Um balanceador de carga HTTP(S) interno pode usar a afinidade do campo de cabeçalho quando a política de localidade do balanceamento de carga for RING_HASH ou MagLEV e o hash consistente do serviço de back-end especificar 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.

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.

Um balanceador de carga TCP/UDP interno pode usar a afinidade de cookie HTTP quando a política de localidade de balanceamento de carga for RING_HASH ou MagLEV e o hash consistente do serviço de back-end especificar o nome do cookie HTTP.

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

Para 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. Alterne para o modo de balanceamento RATE ou CONNECTION.

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.

  • 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 para o cliente. No caso desses balanceadores de carga, altere o valor do tempo limite se quiser dar mais ou menos tempo para que os back-ends respondam completamente às solicitações.

  • Para balanceadores de carga HTTP(S) externos, 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 ser aberto, esteja ele inativo ou não.

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

  • Os balanceadores de carga TCP/UDP internos ignoram o valor do tempo limite do serviço de back-end.

  • Quando os serviços gRPC sem proxy estiverem configurados, o Traffic Director não será compatível com o tempo limite do serviço de back-end.

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 da Internet como back-end não precisam referir-se a uma verificação de integridade.

É possível criar a verificação de integridade ao gerar um balanceador de carga usando o Console do Google Cloud, caso seja necessário, ou referir-se a uma verificação de integridade atual.

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

Os seguintes recursos opcionais do Google Cloud estão disponíveis para serviços de back-end usados por um balanceamento de carga HTTP(S). Eles não são abordados neste documento, mas são discutidos nas seguintes páginas:

  • O Google Cloud Armor fornece proteção contra ataques DDoS e de outros tipos, usando políticas de segurança.
  • O Cloud CDN é um sistema de envio de conteúdo de baixa latência.
  • Os cabeçalhos de solicitação definidos pelo usuário são cabeçalhos adicionais que o balanceador de carga acrescenta às solicitações.
  • O IAP permite que você exija uma autenticação com uma Conta do Google por meio de um fluxo de trabalho logado no OAuth 2.0 e controle o acesso com permissões do IAM.

Outras observações

Os seguintes recursos são compatíveis apenas com balanceadores de carga HTTP(S) internos e com o Traffic Director. No entanto, eles não serão compatíveis quando você usar serviços gRPC sem proxy com o Traffic Director.

  • Disjuntores
  • Detecção de outliers
  • Políticas de balanceamento de carga
  • Afinidade da sessão baseada em cookie HTTP
  • Afinidade da sessão baseada em cabeçalho HTTP

A seguir

Para documentação relacionada e informações sobre como os serviços de back-end são usados no balanceamento de carga, analise o seguinte: