Visão geral dos serviços de back-end

Um serviço de back-end define como o Cloud Load Balancing distribui tráfego. A configuração do serviço de back-end contém um conjunto de valores, como o protocolo usado para se conectar a back-ends, várias configurações de distribuição e sessão, verificações de integridade e tempos limite. Essas configurações fornecem um controle refinado sobre o comportamento do seu balanceador de carga. Se você precisar começar rapidamente, a maioria das configurações terá valores padrão que facilitam a configuração. Um serviço de back-end pode ter escopo global ou regional.

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

  • direcionar o tráfego para os back-ends corretos, que são grupos de instâncias ou grupos de endpoints de rede (NEGs, na sigla em inglês).
  • distribuir o tráfego de acordo com um modo de balanceamento, que é uma configuração para cada back-end;
  • determinar qual verificação de integridade está monitorando a integridade dos back-ends;
  • especificar a afinidade da sessão;
  • Determine se outros serviços estão ativados, incluindo os seguintes disponíveis apenas para determinados balanceadores de carga:
    • Cloud CDN
    • Políticas de segurança do Google Cloud Armor
    • Identity-Aware Proxy

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

A tabela a seguir resume quais balanceadores de carga usam serviços de back-end. O produto que você está usando também determina o número máximo de serviços de back-end, o escopo de um serviço de back-end, o tipo de back-end compatível e o esquema de balanceamento de carga do serviço de back-end.

Tabela: serviços de back-end e tipos de back-end compatíveis
Produto Número máximo de serviços de back-end Escopo do serviço de back-end Tipos de back-end compatíveis Esquema de balanceamento de carga
Balanceador de carga HTTP(S) externo global Várias Global Cada serviço de back-end é compatível com uma das seguintes combinações de back-end:
  • Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona
  • Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT 2
  • Todos os NEGs sem servidor: um ou mais serviços do App Engine, Cloud Run ou Cloud Functions
  • Um único NEG do Private Service Connect
EXTERNAL_MANAGED
Balanceador de carga HTTP(S) externo global (clássico) Várias Global1 Cada serviço de back-end é compatível com uma das seguintes combinações de back-end:
  • Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona
  • Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT 2
  • Todos os NEGs sem servidor: um ou mais serviços do App Engine, Cloud Run ou Cloud Functions, ou
  • Um NEG da Internet para um back-end externo
EXTERNO
Balanceador de carga HTTP(S) externo regional Várias Regional Cada serviço de back-end é compatível com uma das seguintes combinações de back-end:
  • Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona
  • Um único NEG do Private Service Connect
  • Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT 2
  • Um único NEG do Private Service Connect
EXTERNAL_MANAGED
Balanceador de carga HTTP(S) interno Várias Regional Cada serviço de back-end é compatível com uma das seguintes combinações de back-end:
  • Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona
  • Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT 2
  • Um único NEG do Private Service Connect
INTERNAL_MANAGED
Balanceador de carga de proxy SSL externo 1 Global1 O serviço de back-end é compatível com uma das seguintes combinações de back-end:
  • Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona
  • Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT 2
  • Um NEG da Internet para um back-end externo
EXTERNO
Balanceador de carga de proxy TCP externo 1 Global1 O serviço de back-end é compatível com uma das seguintes combinações de back-end:
  • Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona
  • Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT 2
  • Um NEG da Internet para um back-end externo
EXTERNO
Balanceador de carga de proxy TCP regional interno (Visualização) 1 Regional O serviço de back-end é compatível com uma das seguintes combinações de back-end:
  • Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT por zona
  • Todos os NEGs de conectividade híbrida: um ou mais NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Uma combinação de NEGs híbridos e zonais: GCE_VM_IP_PORT e NEGs do tipo NON_GCP_PRIVATE_IP_PORT
INTERNAL_MANAGED
Balanceador de carga de rede 1 Regional O serviço de back-end é compatível com as seguintes 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
EXTERNAL
Balanceador de carga TCP/UDP interno 1 Regional, mas configurável para acesso global O serviço de back-end é compatível com uma das seguintes combinações de back-end:
  • Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP por zona
INTERNAL
Traffic Director Vários Global Cada serviço de back-end é compatível com uma das seguintes combinações de back-end:
  • Todos os back-ends do grupo de instâncias: um ou mais back-ends gerenciados, não gerenciados ou uma combinação de back-ends do grupo de instâncias gerenciadas e não gerenciadas
  • Todos os NEGs por zona: um ou mais NEGs tipo GCE_VM_IP_PORT ou NON_GCP_PRIVATE_IP_PORT por zona, ou
  • Um NEG de Internet do tipo INTERNET_FQDN_PORT
  • Uma ou mais vinculações de serviço
INTERNAL_SELF_MANAGED
1 Os serviços de back-end usados pelo balanceador de carga HTTP(S) externo (clássico), balanceadores de carga de proxy SSL externo e balanceadores de carga de proxy TCP externo são sempre globais no escopo, em nível de rede Standard ou Premium. No entanto, no nível Standard, as seguintes restrições se aplicam:
2 Em implantações do GKE, back-ends de NEGs mistos são compatíveis apenas com NEGs independentes.

Back-ends

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

Não é possível excluir um grupo de instâncias de back-end ou um NEG associado a um serviço de back-end. Antes de excluir um grupo de instâncias ou NEG, remova-o como um back-end de todos os serviços de back-end que se referem a ele.

Grupos de instâncias

Esta seção discute como os grupos de instâncias funcionam com o serviço de back-end.

VMs de back-end e endereços 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 globais, balanceadores de carga de proxy SSL e de proxy TCP externos: os clientes se comunicam com um Google Front End (GFE) usando o endereço IP externo do balanceador de carga. Os GFEs se comunicam com endpoints ou VMs de back-end enviando pacotes para um endereço interno criado com a junção de um identificador à rede VPC do back-end com o 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. Para endpoints GCE_VM_IP_PORT em um NEG zonal, é possível especificar o endereço IPv4 do endpoint como o endereço IPv4 principal associado a qualquer NIC de uma VM ou qualquer endereço IPv4 de um intervalo de IP do alias associado. a qualquer NIC de uma VM. A comunicação entre GFEs e VMs de back-end ou endpoints é facilitada por meio de rotas especiais.
  • Para balanceadores de carga HTTP(S) externos regionais: os clientes se comunicam com um proxy Envoy que hospeda o endereço IP externo do balanceador de carga. Os proxies do Envoy se comunicam com VMs ou endpoints de back-end enviando pacotes para um endereço interno criado mesclando um identificador na rede VPC do back-end com o 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 precisa estar na mesma rede que o balanceador de carga. de dados.
    • Para endpoints GCE_VM_IP_PORT em um NEG zonal, é possível especificar o endereço IPv4 como o endereço IPv4 principal da NIC de uma VM ou um endereço IPv4 de um intervalo de IP do alias da NIC de uma VM, contanto que que a NIC da VM está na mesma rede que o balanceador de carga.
  • Para balanceadores de carga de rede: os clientes se comunicam diretamente com back-ends por meio da infraestrutura de balanceamento de carga de Maglev do Google. Os pacotes são roteados e entregues na interface nic0 de uma VM de back-end com os endereços IP de origem e destino originais preservados. Os back-ends respondem a clientes usando o retorno de servidor direto. Os métodos usados para selecionar um back-end e rastrear as conexões são configuráveis.

Portas nomeadas

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

As portas nomeadas são configuradas da seguinte maneira:

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

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

Cada serviço de back-end converte o nome da porta em um número de porta. Quando a porta nomeada de um grupo de instâncias corresponde a --port-name do serviço de back-end, o serviço de back-end usa esse número de porta para se comunicar com as VMs do grupo de instâncias.

Por exemplo, defina a porta nomeada em um grupo de instâncias com o nome my-service-name e a porta 8888:

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

Em seguida, faça referência à porta nomeada na configuração do serviço de back-end com --port-name no serviço de back-end definido como my-service-name:

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

Um serviço de back-end poderá usar um número de porta diferente ao se comunicar com VMs em grupos de instâncias diferentes se cada grupo de instâncias especificar um número de porta diferente para o mesmo nome de porta.

O número da porta resolvida usado pelo serviço de back-end do balanceador de carga do proxy não precisa corresponder ao número da porta usado pelas regras de encaminhamento do balanceador de carga. Um balanceador de carga do proxy detecta conexões TCP enviadas ao endereço IP e à porta de destino das regras de encaminhamento. Como o proxy abre uma segunda conexão TCP para os back-ends, a porta de destino da segunda conexão TCP pode ser diferente.

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

Os balanceadores de carga TCP/UDP internos e externos de rede TCP/UDP não usam portas nomeadas. Isso ocorre porque eles são balanceadores de carga de passagem que encaminham conexões diretamente para back-ends, em vez de criar novas conexões. Os pacotes são entregues aos back-ends que preservam o endereço IP de destino e a porta da regra de encaminhamento do balanceador de carga.

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

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

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

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

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

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

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

    As combinações de modo de balanceamento incompatíveis são as seguintes:

    • CONNECTION com UTILIZATION
    • RATE com UTILIZATION

    Considere o exemplo a seguir:

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

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

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

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

Grupos de endpoints de rede por zona

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

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

Um serviço de back-end que usa NEGs zonais como back-ends distribui o tráfego entre aplicativos ou contêineres em execução em VMs.

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

  • GCE_VM_IP endpoints (compatíveis apenas com balanceadores de carga TCP/UDP internos)
  • Endpoints GCE_VM_IP_PORT.

Para ver quais produtos são compatíveis com back-ends de NEG por zona, consulte Tabela: serviços de back-end e tipos de back-end compatíveis.

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

Grupos de endpoints de rede de Internet

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

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

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

Para ver quais produtos oferecem suporte a back-ends de NEG da Internet, consulte Tabela: Serviços de back-end e tipos de back-end compatíveis.

Para mais informações sobre NEGs da Internet, 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 Cloud Run, App Engine, Cloud Functions ou o serviço de gateway de API.

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

  • Um serviço ou um grupo de serviços do Cloud Run.
  • Uma função ou um grupo de funções do Cloud Functions.
  • Um app do App Engine (Standard ou Flex), um serviço específico dentro de um app, uma versão específica de um app ou um grupo de serviços.
  • Um gateway de API que fornece acesso aos serviços por meio de uma API REST consistente em todos os serviços, independentemente da implementação deles. Essa capacidade está em Visualização.

Para configurar um NEG sem servidor para aplicativos sem servidor que compartilham um padrão de URL, use uma máscara de URL. Uma máscara de URL é um modelo do esquema de URL (por exemplo, example.com/<service>). O NEG sem servidor usará esse modelo para extrair o nome <service> do URL da solicitação de entrada e rotear a solicitação para o serviço correspondente do Cloud Run, do Cloud Functions ou do App Engine com com o mesmo nome.

Para ver quais balanceadores de carga são compatíveis com back-ends de NEG sem servidor, consulte Tabela: serviços de back-end e tipos de back-end compatíveis.

Para mais informações sobre NEGs sem servidor, consulte Visão geral de grupos de endpoints de rede sem servidor.

Vinculações de serviço

Uma vinculação de serviço é um back-end que estabelece uma conexão entre um serviço de back-end no Traffic Director e um serviço registrado no Diretório de serviços. Um serviço de back-end pode referir-se a várias vinculações de serviço. Um serviço de back-end com uma vinculação de serviço não pode se referir a nenhum outro tipo de back-end.

Back-ends mistos

As seguintes considerações se aplicam quando você adiciona diferentes tipos de back-ends a um único serviço de back-end:

  • Um único serviço de back-end não pode usar simultaneamente grupos de instâncias e NEGs zonais.
  • É possível usar uma combinação de diferentes tipos de grupos de instâncias no mesmo serviço de back-end. Por exemplo, um único serviço de back-end pode se referir a uma combinação de grupos de instâncias gerenciadas e não gerenciadas. Para informações completas sobre quais back-ends são compatíveis com quais serviços de back-end, consulte a tabela na seção anterior.
  • Em determinados balanceadores de carga de proxy, é possível usar uma combinação de NEGs zonais (com endpoints GCE_VM_IP_PORT) e de conectividade híbrida (com endpoints NON_GCP_PRIVATE_IP_PORT ) para configurar a carga híbrida equilíbrio. Para ver quais balanceadores de carga têm esse recurso, consulte Tabela: serviços de back-end e tipos de back-end compatíveis.

Protocolo para os back-ends

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

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

Tabela: protocolo para os back-ends
Produto Esquema de balanceamento de carga Opções de protocolo do serviço de back-end
Balanceador de carga HTTP(S) externo global EXTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Balanceador de carga HTTP(S) externo global (clássico) EXTERNAL HTTP, HTTPS, HTTP/2
Balanceador de carga global externa HTTP(S) (Visualização) EXTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Balanceador de carga de proxy SSL externo EXTERNO SSL ou TCP
Balanceador de carga de proxy TCP externo EXTERNO TCP ou SSL
Balanceador de carga HTTP(S) interno INTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Balanceador de carga de proxy TCP regional interno (Visualização) INTERNAL_MANAGED TCP
Balanceador de carga de rede EXTERNAL TCP, UDP ou UNSPECIFIED
Balanceador de carga TCP/UDP interno INTERNAL TCP ou UDP
Traffic Director INTERNAL_SELF_MANAGED HTTP, HTTPS, HTTP/2, gRPC, TCP

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

Criptografia entre o balanceador de carga e os back-ends

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

Distribuição de tráfego

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

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

Modo de balanceamento

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

  • CONNECTION
  • RATE
  • UTILIZATION

Você define o modo de balanceamento ao adicionar um back-end ao serviço de back-end. Os modos de balanceamento disponíveis para um balanceador de carga dependem do esquema do serviço de back-end, do protocolo do serviço de back-end e do tipo de back-ends de balanceamento de carga conectados ao serviço de back-end.

Os balanceadores de carga de passagem exigem o modo de balanceamento CONNECTION, mas não são compatíveis com a definição de capacidade de destino.

A páginaBalanceadores de carga de proxy HTTP(S) oferece suporte aos modos de balanceamento RATE ouUTILIZATION para back-ends de grupos de instâncias, modo de balanceamento RATE para NEGs zonais com endpoints GCE_VM_IP_PORT e modo de balanceamento RATE para NEGs híbridos (NON_GCP_PRIVATE_IP_PORT endpoints). Para qualquer outro tipo de back-end compatível, o modo de balanceamento precisa ser omitido.

  • Para o balanceador de carga HTTP(S) externo global (clássico), uma região é selecionada com base no local do cliente e se a região tem capacidade disponível com base na capacidade desejada do modo de balanceamento de carga. Em seguida, dentro de uma região, a capacidade de destino do modo de balanceamento é usada para calcular as proporções de quantas solicitações precisam ser enviadas para cada back-end na região. Depois, as solicitações ou conexões são distribuídas de maneira aleatória entre instâncias ou endpoints no back-end.
  • Para balanceadores de carga HTTP(S) externos globais, uma região é selecionada com base no local do cliente e se a região tem capacidade disponível com base na capacidade de destino do modo de balanceamento de carga. Em uma região, a capacidade desejada do modo de balanceamento é usada para calcular as proporções de quantas solicitações precisam ser enviadas para cada back-end (grupo de instâncias ou NEG) na região. 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 endpoints no grupo.
  • Para balanceadores de carga HTTP(S) externos e internos, a capacidade de destino do modo de balanceamento é usada para calcular proporções de quantas solicitações devem ser enviadas para cada back-end (grupo de instâncias ou NEG). na região. 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 endpoints no grupo.

Os balanceadores de carga do proxy TCP/SSL são compatíveis com os modos de balanceamento CONNECTION ou UTILIZATION para back-ends de grupos de instâncias e o modo de balanceamento CONNECTION para NEGs zonais com GCE_VM_IP_PORT e o modo de balanceamento CONNECTION para NEGs híbridos (endpoints NON_GCP_PRIVATE_IP_PORT). Para qualquer outro tipo de back-end compatível, o modo de balanceamento precisa ser omitido.

  • Para o balanceador de carga do proxy TCP externo e do balanceador de carga do proxy SSL, uma região é selecionada com base no local 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, dentro de uma região, a capacidade de destino do modo de balanceamento é usada para calcular as proporções de quantas solicitações precisam ser enviadas para cada back-end na região. Depois, as solicitações ou conexões são distribuídas de maneira redonda entre as instâncias ou endpoints no back-end.
  • Para o balanceador de carga do proxy TCP regional interno, a capacidade de destino do modo de balanceamento é usada para calcular proporções para quantas solicitações devem ser enviadas 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 endpoints no grupo.

Veja na tabela a seguir um resumo dos modos de balanceamento de carga disponíveis para cada combinação de balanceador de carga e back-end.

Tabela: modos de balanceamento disponíveis para cada balanceador de carga
Balanceador de carga Back-ends Modos de balanceamento disponíveis
  • Balanceador de carga HTTP(S) externo global
  • Balanceador de carga HTTP(S) externo global (clássico)
  • Balanceador de carga regional externa HTTP(S) (Visualização)
Grupos de instâncias RATE ou UTILIZATION
NEGs zonais (endpoints GCE_VM_IP_PORT) RATE
NEGs híbridos (endpoints NON_GCP_PRIVATE_IP_PORT) RATE
  • Balanceador de carga de proxy TCP externo
  • Balanceador de carga de proxy SSL externo
  • Balanceador de carga de proxy TCP regional interno (Visualização)
Grupos de instâncias CONNECTION ou UTILIZATION
NEGs zonais (endpoints GCE_VM_IP_PORT) CONNECTION
NEGs híbridos (endpoints NON_GCP_PRIVATE_IP_PORT)
(compatíveis apenas com o balanceador de carga do proxy TCP regional)
CONNECTION
Balanceador de carga de rede Grupos de instâncias CONNECTION
Balanceador de carga TCP/UDP interno Grupos de instâncias CONNECTION
NEGs zonais (endpoints GCE_VM_IP) CONNECTION

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 compute backend-services add-backend.

Capacidade desejada

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

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

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

Modo de balanceamento de conexão

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

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

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

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

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

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

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

Modo de balanceamento de taxa

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

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

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

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

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

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

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

Modo de balanceamento de utilização

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

A capacidade de destino max-utilization só pode ser especificada por grupo de instâncias e não pode ser aplicada a uma determinada VM no grupo.

O modo de balanceamento UTILIZATION não tem capacidade desejada obrigatória. Ao usar o console do Google Cloud para adicionar um grupo de instâncias de back-end a um serviço de back-end, o console define o valor de max-utilization como 0,8 (80%) se o modo de balanceamento UTILIZATION está selecionado. Além de max-utilization, o modo de balanceamento UTILIZATION é compatível com capacidades de destino mais complexas, como resumido na tabela da seção a seguir.

Como alterar o modo de balanceamento de um balanceador de carga

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

Para ver quais modos de balanceamento são compatíveis com cada balanceador de carga, consulte Tabela: modos de balanceamento disponíveis para cada balanceador de carga.

Modos de balanceamento e configurações de capacidade desejadas

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

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

Escalonador de capacidade

Para determinadas configurações do balanceador de carga do proxy, você pode ajustar o escalonador de capacidade para escalonar a capacidade de destino efetiva (utilização de destino efetiva, taxa de destino efetiva ou conexões de meta efetivas) sem alterar explicitamente um dos parâmetros --max-*.

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

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

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

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

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

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

Traffic Director e distribuição de tráfego

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

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

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

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

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

Subconfiguração de back-ends

A subconfiguração de back-end é um recurso opcional que melhora o desempenho e a escalonabilidade ao atribuir um subconjunto de back-ends a cada uma das instâncias de proxy.

A subconfiguração de back-end é compatível com os itens a seguir:

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

Subconfiguração de back-end para balanceador de carga HTTP(S) interno

Nos balanceadores de carga HTTP(S) internos, a subconfiguração de back-end atribui automaticamente apenas um subconjunto dos back-ends no serviço de back-end regional a cada instância de proxy.

Por padrão, cada instância de proxy do balanceador de carga HTTP(S) interno abre conexões com todos os back-ends em um serviço de back-end. Quando o número de instâncias de proxy e os back-ends são grandes conexões de abertura para todos os back-ends, isso pode causar problemas de desempenho. Ao ativar a subconfiguração, cada proxy só abre conexões para uma subconfiguração de back-ends, reduzindo o número de conexões mantidas abertas para cada back-end. Reduzir o número de conexões abertas simultaneamente para cada back-end pode melhorar o desempenho dos back-ends e dos proxies.

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

Comparação do balanceador de carga interno de HTTPS sem e com a subconfiguração de back-end.
Comparar o balanceador de carga HTTP(S) interno com e com a subconfiguração de back-end.

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

Para saber mais sobre como configurar a subconfiguração de back-end para balanceadores de carga HTTP(S) internos, consulte Configurar subconfiguração de back-end.

Advertências relacionadas à subconfiguração de back-end do balanceador de carga HTTP(S) interno
  • A subconfiguração do back-end foi projetada para garantir que todas as instâncias de back-end permaneçam bem usadas, mas pode introduzir um viés na quantidade de tráfego que cada back-end recebe. A configuração localityLbPolicy como LEAST_REQUEST é recomendada para serviços de back-end que são sensíveis ao balanceamento de carga do back-end.
  • A ativação e a desativação da criação de subconfigurações interrompe as conexões existentes.
  • A subconfiguração do back-end requer que a afinidade da sessão seja NONE (um hash de cinco tuplas). Outras opções de afinidade da sessão só poderão ser usadas se a subconfiguração do back-end estiver desativada. Os valores padrão das sinalizações --subsetting-policy e --session-affinity são NONE, e apenas uma delas por vez pode ser definida como um valor diferente.

Subconfiguração de back-end para balanceador de carga TCP/UDP interno

A criação de subconfigurações para balanceadores de carga TCP/UDP internos permite que você dimensione o balanceador de carga TCP/UDP interno para aceitar um número maior de instâncias de VM de back-end por serviço de back-end interno.

Para informações sobre como a criação de subconfigurações afeta esse limite, consulte a seção "Serviços de back-end" de cotas e limites de recursos de balanceamento de carga.

Por padrão, a subconfiguração está desativada, o que limita o serviço de back-end a distribuir até 250 instâncias ou endpoints de back-end. Se seu serviço de back-end precisar ser compatível com mais de 250 back-ends, será possível ativar a criação de subconjuntos. Quando a criação de subconfiguraçãos é ativada, um subconjunto de instâncias de back-end é selecionado para cada conexão de cliente.

No diagrama a seguir, mostramos um modelo de diferença reduzida entre esses dois modos de operação.

Comparação de um balanceador de carga TCP/UDP interno sem e com subconfiguração (clique para ampliar)
Comparação de um balanceador de carga TCP/UDP interno sem e com subconfiguração (clique para ampliar)

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

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

Advertências relacionadas à subconfiguração de back-end para o balanceador de carga TCP/UDP interno
  • Quando a criação de subconfigurações estiver ativada, nem todos os back-ends receberão tráfego de um determinado remetente, mesmo quando o número de back-ends for pequeno.
  • Para ver o número máximo de instâncias de back-end quando a subconfiguração estiver ativada, consulte a página de cotas.
  • Somente a afinidade da sessão de cinco tuplas é compatível com a criação de subconfigurações.
  • O espelhamento de pacotes não é compatível com a criação de subconfigurações.
  • A ativação e a desativação da criação de subconfigurações interrompe as conexões existentes.
  • Se os clientes no local precisarem acessar um balanceador de carga TCP/UDP interno, a subconfiguração poderá reduzir substancialmente o número de back-ends que recebem conexões dos clientes no local. Isso acontece porque a região do túnel do Cloud VPN ou do anexo da VLAN do Cloud Interconnect determina o subconjunto dos back-ends do balanceador de carga. Todos os endpoints do Cloud VPN e do Cloud Interconnect em uma região específica usam o mesmo subconjunto. Subconjuntos diferentes são usados em regiões distintas.

Preços de subconfiguração de back-end

Não há cobrança pelo uso da subconfiguração do back-end. Para mais informações, consulte Todos os preços de rede.

Afinidade da sessão

A afinidade da sessão permite controlar como o balanceador de carga seleciona back-ends para novas conexões de maneira previsível, desde que o número de back-ends saudáveis permaneça constante. Isso é útil para aplicativos que precisam que várias solicitações de um determinado usuário sejam direcionadas para o mesmo back-end ou endpoint. Esses aplicativos incluem servidores com estado usados pela veiculação de anúncios, jogos ou serviços com uso intenso do cache interno.

Os balanceadores de carga do Google Cloud fornecem afinidade de sessão com base no melhor esforço. Fatores como alterar os estados de verificação de integridade do back-end, adicionar ou remover back-ends ou alterações na integridade do back-end, conforme medido pelo modo de balanceamento, podem quebrar a afinidade da sessão.

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

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

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

Para balanceadores de carga de passagem, as novas conexões são distribuídas para instâncias de back-end ou endpoints íntegros (no pool ativo, se uma política de failover estiver configurada). É possível controlar o seguinte:

Para balanceadores de carga baseados em proxy, desde que o número de instâncias ou endpoints de back-end íntegros permaneça constante e desde que a instância de back-end ou o endpoint selecionado anteriormente não esteja atingindo a capacidade , as solicitações ou conexões subsequentes vão para a mesma VM ou endpoint de back-end. A capacidade de destino do modo de balanceamento determina quando o back-end está no limite.

A tabela a seguir mostra as opções de afinidade da sessão compatíveis com cada produto:

Tabela:configurações de afinidade da sessão compatíveis
Produto Opções de afinidade de sessão
  • Nenhum (NONE)
  • IP do cliente (CLIENT_IP)
  • Cookie gerado (GENERATED_COOKIE)
  • Campo de cabeçalho (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)

Além disso:

  • As configurações de afinidade da sessão só serão atendidas se a política de localidade de balanceamento de carga (LocalityLbPolicy) estiver definida como RING_HASH ou MAGLEV.
  • Para os balanceadores de carga HTTP(S) externos globais, não configure a sessão afinidade se você estiver usando a divisão de tráfego ponderada. Se você fizer isso, a configuração da divisão de tráfego ponderada terá precedência.
Balanceador de carga HTTP(S) externo global (clássico)
  • Nenhum (NONE)
  • IP do cliente (CLIENT_IP)
  • Cookie gerado (GENERATED_COOKIE)
Balanceador de carga HTTP(S) interno
  • Nenhum (NONE)
  • IP do cliente (CLIENT_IP)
  • Cookie gerado (GENERATED_COOKIE)
  • Campo de cabeçalho (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)

As configurações de afinidade da sessão só serão atendidas se a política de localidade de balanceamento de carga (LocalityLbPolicy) estiver definida como RING_HASH ou MAGLEV.

Balanceador de carga TCP/UDP interno
  • Nenhum (NONE)
  • IP DO CLIENTE, sem destino (Prévia) (CLIENT_IP_NO_DESTINATION)
  • IP do cliente, IP de destino (CLIENT_IP)
  • IP do cliente, IP de destino, protocolo (CLIENT_IP_PROTO)
  • IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo (CLIENT_IP_PORT_PROTO)

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

Balanceador de carga de rede1
  • Nenhum (NONE)
  • IP do cliente, IP de destino (CLIENT_IP)
  • IP do cliente, IP de destino, protocolo (CLIENT_IP_PROTO)
  • IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo (CLIENT_IP_PORT_PROTO)

Para informações específicas sobre o balanceamento de carga de rede e a afinidade da sessão, consulte a Visão geral do balanceamento de carga de rede TCP/UDP externo.

  • Nenhum (NONE)
  • IP do cliente (CLIENT_IP)
Traffic Director
  • Nenhum (NONE)
  • IP do cliente (CLIENT_IP)
  • Cookie gerado (GENERATED_COOKIE) (somente protocolos HTTP)
  • Campo de cabeçalho (HEADER_FIELD) (somente protocolos HTTP)
  • Cookie HTTP (HTTP_COOKIE) (apenas protocolos HTTP)

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

1 Nesta tabela, você encontra as afinidades de sessão compatíveis com os balanceadores de carga de rede baseados em serviço de back-end. Balanceadores de carga de rede baseados em pool de destino não usam serviços de back-end. Em vez disso, você define a afinidade da sessão para balanceadores de carga de rede por meio do parâmetro sessionAffinity em Pools de destino.

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

  • Não confie na afinidade da sessão para fins de autenticação ou segurança. A afinidade da sessão foi projetada para quebrar sempre que o número de back-ends de exibição e íntegros muda. As atividades que resultam na interrupção da afinidade de sessão incluem:

    • Adicionar grupos de instâncias de back-end ou NEGs ao serviço de back-end
    • Remover grupos de instâncias de back-end ou NEGs do serviço de back-end
    • Adicionar instâncias a um grupo de instâncias de back-end existente, o que acontece automaticamente quando você ativa o escalonamento automático com grupos de instâncias gerenciadas
    • Remover instâncias de um grupo de instâncias de back-end atual, o que acontece automaticamente quando você ativa o escalonamento automático com grupos de instâncias gerenciadas.
    • Como adicionar endpoints a um NEG de back-end atual
    • Como remover endpoints de um NEG de back-end atual
    • Quando um back-end íntegro falha na verificação de integridade e perde a integridade
    • Quando um back-end não íntegro passa na verificação de integridade e se torna íntegro
    • Para balanceadores de carga de passagem: durante o failover e o failover, se uma política de failover estiver configurada.
    • Para balanceadores de carga de proxy: quando um back-end está acima da capacidade máxima
  • Não é recomendado usar uma afinidade de sessão que não seja None com o modo de balanceamento UTILIZATION. Isso ocorre porque as alterações na utilização da instância podem fazer com que o serviço de balanceamento de carga direcione novas solicitações ou conexões para VMs de back-end que estejam menos completas. Isso quebra a afinidade da sessão. Em vez disso, use o modo de balanceamento RATE ou CONNECTION para reduzir a diferença da afinidade da sessão. Para mais detalhes, consulte Perda de afinidade da sessão.

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

    • Um balanceador de carga tem um NEG e três endpoints.
    • Cada endpoint tem uma capacidade desejada de 1 RPS.
    • O modo de balanceamento é RATE.
    • No momento, cada endpoint está processando 1,1, 0,8 e 1,6 RPS, respectivamente.
    • Quando uma solicitação HTTP com afinidade para o último endpoint chega ao balanceador de carga, a afinidade da sessão reivindica o endpoint que está processando a 1,6 RPS.
    • A nova solicitação pode ir para o endpoint do meio com 0,8 RPS.
  • Os valores padrão das sinalizações --session-affinity e --subsetting-policy são NONE, e apenas um por vez pode ser definido como um valor diferente.

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

IP do cliente, sem afinidade de destino

IP do cliente, nenhuma afinidade de destino (CLIENT_IP_NO_DESTINATION) direciona solicitações do mesmo endereço IP de origem do cliente para a mesma instância de back-end.

Ao usar o IP do cliente, sem afinidade de destino, lembre-se do seguinte:

  • IP do cliente, sem afinidade de destino, é um hash de uma tupla que consiste no endereço IP de origem do cliente.

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

IP do cliente, nenhuma afinidade de destino é uma opção para balanceadores de carga TCP/UDP internos.

Afinidade de IP do cliente

A afinidade de IP do cliente (CLIENT_IP) 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.

Para saber quais produtos oferecem suporte à afinidade de IP do cliente, consulte Tabela: configurações de afinidade de sessão compatíveis.

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 o mesmo endpoint de back-end.

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

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

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

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

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

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

Para saber quais produtos são compatíveis com a afinidade de cookie gerado, consulte a Tabela: Configurações de afinidade da sessão compatíveis.

Afinidade do campo de cabeçalho

O Traffic Director e um balanceador de carga HTTP(S) interno podem usar quando os dois itens a seguir são verdadeiros:

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

Para saber quais produtos são compatíveis com a afinidade de campo de cabeçalho, consulte Tabela: Configurações de afinidade da sessão compatíveis.

O Traffic Director e um balanceador de carga HTTP(S) interno podem usar afinidade de cookie HTTP quando as seguintes condições forem verdadeiras:

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

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

Para saber quais produtos são compatíveis com a afinidade de IP de cookie HTTP, consulte Tabela: Configurações de afinidade da sessão compatíveis.

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 externo ou de proxy TCP externo, lembre-se dos seguintes pontos adicionais:

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

Tempo limite do serviço de back-end

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

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

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

    Se a conexão HTTP for atualizada para um WebSocket, o tempo limite do serviço de back-end definirá o tempo máximo que um WebSocket pode ficar aberto, estando inativo ou não.

    Para mais detalhes sobre o tempo limite do serviço de back-end de cada balanceador de carga, consulte os tópicos a seguir:

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

  • Para balanceadores de carga TCP/UDP internos e balanceadores de carga de rede, defina o valor do tempo limite do serviço de back-end usando gcloud ou a API, mas o valor é ignorado. O tempo limite do serviço de back-end não tem significado para esses balanceadores de carga.

  • Para o Traffic Director, o campo de tempo limite do serviço de back-end (especificado usando timeoutSec) não é compatível com serviços gRPC sem proxy. Para esses serviços, configure o tempo limite do serviço de back-end usando o campo maxStreamDuration. Isso ocorre porque o gRPC não é compatível com a semântica de timeoutSec, que especifica o tempo a aguardar até que um back-end retorne uma resposta completa após o envio da solicitação. O tempo limite do gRPC especifica a quantidade de tempo a aguardar desde o início do stream até que a resposta seja totalmente processada, incluindo todas as novas tentativas.

Verificações de integridade

Cada serviço de back-end em que back-ends são grupos de instâncias ou NEGs por zona precisa ter uma verificação de integridade associada. Os serviços de back-end que usam um NEG sem servidor ou um NEG da Internet como back-end não podem referenciar uma verificação de integridade.

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

Ao criar um serviço de back-end usando o grupo de instâncias ou os back-ends de NEG por zona usando a Google Cloud CLI ou a API, é preciso referir-se a uma verificação de integridade atual. Consulte o guia do balanceador de carga na Visão geral das verificações de integridade para ver detalhes sobre o tipo e o escopo da verificação de integridade exigida.

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

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

Alguns recursos opcionais do Google Cloud, como o Cloud CDN e o Google Cloud Armor, estão disponíveis para serviços de back-end usados por balanceadores de carga HTTP(S) globais externos. O Google Cloud Armor também é compatível com balanceadores de carga de proxy SSL e de proxy TCP externos.

Veja mais informações em:

Recursos de gerenciamento de tráfego

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

Esses recursos são compatíveis com os seguintes balanceadores de carga:

  • Balanceador de carga HTTP(S) externo global (não é compatível com quebra de circuito)
  • Balanceador de carga HTTP(S) externo regional
  • Balanceador de carga HTTP(S) interno
  • Traffic Director (mas não compatível com serviços gRPC sem proxy)

API e referência gcloud

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

A seguir

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

Para vídeos relacionados: