Visão 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 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 balanceador de carga. A maioria das configurações tem valores padrão que permitem facilitar a configuração, se você precisar começar rapidamente.

É 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 usam as informações de configuração no recurso do serviço de back-end para 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). Um balanceador de carga HTTP(S) externo pode ser configurado para usar um bucket intervalo de back-end em vez de um serviço de back-end. Para informações sobre como usar buckets de back-end com balanceadores de carga HTTP(S) externos, consulte Como configurar um balanceador de carga com buckets de back-end.
  • Para distribuir o tráfego de acordo com um modo de balanceamento, que é uma configuração para cada back-end
  • Para determinar qual verificação de integridade está monitorando a integridade dos back-ends
  • Para especificar a afinidade da sessão
  • Para determinar se o Cloud CDN está ativado (somente balanceadores de carga HTTP(S) externos)
  • Para determinar se as políticas de segurança do Google Cloud Armor estão ativadas (somente balanceadores de carga HTTP(S) externos)
  • Para 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. Você define outros valores ao adicionar um back-end a um serviço de back-end.

Um serviço de back-end tem 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 número máximo de serviços de back-end por balanceador de carga, o escopo de um serviço de back-end, o tipo de back-end que cada serviço de back-end pode usar e o esquema de balanceamento de carga dependem do tipo de balanceador de carga:

Tipo de balanceador de carga 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-end gerenciados, não gerenciados ou uma combinação de back-end do grupo de instâncias gerenciadas e não gerenciadas ou
  • todos os NEGs zonais: um ou mais NEGs zonais, ou
  • uma Internet NEG
EXTERNAL
Balanceamento de carga HTTP(S) interno Vários Discos 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-end gerenciados, não gerenciados ou uma combinação de back-end do grupo de instâncias gerenciadas e não gerenciadas ou
  • todos os NEGs zonais: um ou mais NEGs zonais
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-end gerenciados, não gerenciados ou uma combinação de back-end do grupo de instâncias gerenciadas e não gerenciadas ou
  • todos os NEGs zonais: um ou mais NEGs zonais, 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-end gerenciados, não gerenciados ou uma combinação de back-end do grupo de instâncias gerenciadas e não gerenciadas ou
  • todos os NEGs zonais: um ou mais NEGs zonais, 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-end gerenciados, não gerenciados ou uma combinação de back-end 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-end gerenciados, não gerenciados ou uma combinação de back-end do grupo de instâncias gerenciadas e não gerenciadas ou
  • todos os NEGs zonais: um ou mais NEGs zonais
INTERNAL_SELF_MANAGED

1 Os serviços de back-end usados pelo balanceamento de carga HTTP(S), por proxy SSL e por proxy TCP sempre são globais no escopo, no nível de rede Padrão ou Premium. No entanto, no nível Padrão, as seguintes restrições se aplicam:

Back-ends

Um back-end é um recurso em que um balanceador de carga do Google Cloud distribui o tráfego. Cada serviço de back-end está associado a um ou mais back-ends compatíveis. Há três tipos de back-ends:

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 zonais. 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 referir-se 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 referir-se a ele.

Protocolo para os back-ends

Ao criar um serviço de back-end, especifique o protocolo usado pelo balanceador de carga para 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

Os protocolos são válidos de acordo com o tipo de balanceador de carga. Para mais informações, consulte Recursos do balanceador de carga.

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

Criptografia entre o balanceador de carga e os back-ends

Para balanceamento de carga HTTP(S), balanceamento de carga de proxy TCP e balanceamento de carga de proxy SSL, o Google criptografa automaticamente o tráfego entre o Google Front ends (GFEs) e os back-ends no Google Cloud. Para back-ends fora do Google Cloud, como endpoints em um grupo de endpoints de rede de Internet, o tráfego é criptografado automaticamente na rede do Google.

  • Além dessa criptografia no nível da rede, é possível optar por usar um protocolo seguro, como SSL, HTTPS ou HTTP/2 (usando TLS), como um protocolo de serviço de back-end.
  • Recomendamos o uso de HTTPS ou HTTP/2 ao se conectar a back-ends fora do Google Cloud, já que a comunicação com o back-end pode transitar pela Internet pública.
  • Ao usar SSL, HTTPS ou HTTP/2 como um protocolo de serviço de back-end, é necessário instalar chaves privadas e certificados e configurar o software em execução nos back-ends para operar como um servidor SSL ou HTTPS.

Quando um GFE se conecta aos back-ends usando um protocolo de serviço de back-end seguro, ele é o cliente SSL ou HTTPS.

  • Ao se conectar a back-ends no Google Cloud, os GFEs aceitam qualquer certificado presente nos back-ends, seja autoassinado ou assinado por uma autoridade de certificação. Os GFEs não realizam validação de certificado ao se conectar a back-ends usando um protocolo de serviço de back-end seguro neste caso.
  • Ao se conectar a back-ends pela Internet pública por meio de uma Internet NEG, o certificado precisa ser assinado por uma CA pública e atender aos requisitos de validação

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 balanceadores de carga 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 próprias VMs de back-end não exigem endereços IP externos.

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

Portas nomeadas

Os grupos de instâncias de back-end conectados a um desses tipos de balanceadores de carga precisam ter uma porta nomeada correspondente à porta nomeada em que o serviço de back-end do balanceador de carga se inscreve:

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

Cada grupo de instâncias pode ter várias portas nomeadas. Uma porta nomeada cria um mapeamento de um nome de serviço para um número de porta. Se a porta nomeada de um grupo de instâncias corresponder à porta nomeada em que os serviços de back-end se inscrevem, o mapeamento da porta nomeada no grupo de instâncias será usado para definir o número de porta que o serviço de back-end usa para se comunicar com as VMs que são membro do grupo.

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 a porta nomeada no serviço de back-end como my-service-name:

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

Lembre-se:

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

  • É possível que um serviço de back-end use 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 exclusivo 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 NEG por zona ou back-ends de internet, porque os NEGs definem portas usando um mecanismo diferente, ou seja, nos próprios pontos de extremidade;
  • para balanceadores de carga TCP/UDP internos porque um balanceador de carga TCP/UDP interno é 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, de um grupo de instâncias gerenciadas e um ou mais grupos de instâncias não gerenciadas, o Google Cloud limitará o uso de um desses grupos de instâncias por vez como 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 em que 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 serviço de back-end 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.

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 para 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 de CPU máxima.
  • 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 totalmente carregado. 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.

Defina o modo de balanceamento ao adicionar um back-end ao serviço de back-end.

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 Grupos de instâncias ou NEGs por zona
  • Balanceamento de carga HTTP(S) externo
  • Balanceamento de carga HTTP(S) interno
  • Traffic Director
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

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 zonais gerenciadas em diferentes zonas e grupos de instâncias zonais não gerenciadas. Esse desequilíbrio zonal é 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.

Além disso, 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 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, simultaneamente, para um balanceador de carga HTTP(S) externo, compatível com 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 de CPU máxima. Para cada modo de balanceamento, a capacidade de destino 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 chegado até ela.

  • 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 zonal usando max-connections-per-endpoint. Para NEGs zonais e para grupos de instâncias não gerenciadas zonais, 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 zonal usando max-rate-per-endpoint. Para NEGs zonais e para grupos de instâncias não gerenciadas zonais, 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 de destino 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 zonais
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 zona
3. máximo de conexões por instância
 (grupos de instâncias zonais ou regionais)
4. 1 e 2 juntos
5. 1 e 3 juntos
NEG de zona CONNECTION Você precisa especificar uma das seguintes opções:
1. máximo de conexões por NEG zonal
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 zonais
2. taxa máxima por instância
 (grupos de instâncias zonais 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 zonais
3. taxa máxima por instância
 (grupos de instâncias zonais ou regionais)
4. 1 e 2 juntos
5. 1 e 3 juntos
NEG de zona RATE Você precisa especificar uma das seguintes opções:
1. taxa máxima por NEG zonal
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

Você pode definir o dimensionador 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 escala 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

Em uma situação em que 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, você pode definir o escalonador de capacidade como 0.5 nos dois serviços de back-end e cada serviço de back-end receberia 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 e uma política de balanceamento de carga. O serviço de back-end direciona tráfego para um back-end (grupo de instância 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 zonais.

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

  • 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 está com uma capacidade igual ou superior a ela ou 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 compatível 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 • Nenhum
• 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 • Nenhum
• 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 entra em contato.

  • 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 do 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 o mesmo 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 em 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 tratar a conexão como nova.

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), incluindo esses valores.

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 especifica o nome do cabeçalho HTTP. A afinidade do campo de cabeçalho encaminha solicitações para VMs ou endpoints de back-end em um NEG zonal 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 especifica o nome do cookie HTTP.

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

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 zonal 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 zonal, que pode estar em uma zona diferente. É possível atenuar isso especificando a capacidade de destino 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 todas as verificações de integridade falham.
  • 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 que for compatível com o tipo de balanceador de carga.

Ao usar balanceamento de carga HTTP(S), balanceamento de carga de proxy SSL ou balanceamento de carga 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 balanceadores de carga HTTP(S) 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 se 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. Para esses balanceadores de carga, altere o valor do tempo limite se quiser permitir que os back-ends respondam completamente com mais ou menos tempo à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. Para esses 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.

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.

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

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 existente. 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 necessárias.

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 por meio de uma Conta do Google usando um fluxo de trabalho de login do OAuth 2.0 e controle o acesso usando permissões do IAM.

Outras observações

Os seguintes recursos são compatíveis apenas com balanceadores de carga HTTP(S) internos e 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: