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. Para começar, a maioria das configurações tem valores padrão que permitem uma configuração rápida. Um serviço de back-end pode 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.

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 suportado e o esquema de balanceamento de carga do serviço de back-end. O esquema de balanceamento de carga é um identificador usado pelo Google para classificar regras de encaminhamento e serviços de back-end. Cada produto de balanceamento de carga usa um esquema de balanceamento de carga para as regras de encaminhamento e serviços de back-end. Alguns esquemas são compartilhados entre os produtos.

Como nomear o balanceador de carga

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

• Trusted Cloud console. Se você criar um balanceador de carga de rede de proxy ou de passagem usando o console Trusted Cloud , o serviço de back-end vai receber automaticamente o mesmo nome inserido para o balanceador de carga.
• CLI ou API do Google Cloud. Se você criar um balanceador de carga de rede de proxy ou de passagem usando a CLI gcloud ou a API, insira um nome de sua escolha ao criar o serviço de back-end. Esse nome do serviço de back-end é refletido no console Trusted Cloud como o nome do balanceador de carga.

Para saber como a nomenclatura funciona para balanceadores de carga de aplicativo, consulte Visão geral dos mapas de URL: nomenclatura do balanceador de carga.

Back-ends

Um back-end é um ou mais endpoints que recebem tráfego de um Trusted Cloud by S3NS balanceador de carga ou de um cliente gRPC sem proxy. Há vários tipos de back-ends:

• Grupo de instâncias que contém instâncias de máquina virtual (VM). Um grupo de instâncias pode ser um grupo de instâncias gerenciadas (MIG), com ou sem escalonamento automático, ou pode ser um grupo de instâncias não gerenciadas. Mais de um serviço de back-end pode se referir a um grupo de instâncias, mas todos os serviços de back-end que fazem referência ao grupo de instâncias precisam usar o mesmo modo de balanceamento.
• NEG por zona
• NEG da Internet
• NEG de conectividade híbrida
• NEG de mapeamento de portas
• Vinculações de serviço do Diretório de serviços

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 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, especifique o endereço IP do endpoint como o endereço IPv4 principal associado a qualquer interface de rede de uma VM ou qualquer endereço IPv4 de um intervalo de endereços IP do alias associado a qualquer rede de uma VM, desde que a interface de rede esteja 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 a back-ends 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.

  • Para back-ends de grupos de instâncias, os pacotes são sempre entregues à interface nic0 da VM.
  • Para endpoints GCE_VM_IP em um NEG zonal, os pacotes são entregues à interface de rede da VM que está na sub-rede associada ao NEG.

Portas nomeadas

O atributo porta nomeada do serviço de back-end só é aplicável a balanceadores de carga baseados em proxy (balanceadores de carga de aplicativo e balanceadores de carga de rede 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 as portas usando um mecanismo diferente, ou seja, nos próprios endpoints.

Os balanceadores de carga de rede de passagem interna e externos de passagem 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:

• Grupos de instâncias não gerenciadas: Como trabalhar com portas nomeadas
• Grupos de instâncias gerenciadas: Como atribuir portas nomeadas a grupos de instâncias gerenciadas

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 carga balanceada. 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 Trusted 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 uma combinação de modos compatíveis, como CONNECTION e RATE.

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

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

  Veja o exemplo a seguir.

  • Você tem dois serviços de back-end: external-https-backend-service para um balanceador de carga de aplicativo externo e internal-tcp-backend-service para um balanceador de carga de rede de passagem interna.
  • Você está usando um grupo de instâncias chamado instance-group-a em internal-tcp-backend-service.
  • Em internal-tcp-backend-service, é preciso aplicar o modo de balanceamento CONNECTION, porque os balanceadores de carga de rede de passagem interna são compatíveis apenas 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 e 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 grupos de endpoints de rede zonais (NEGs) são recursos zonais que representam coleções de endereços IP ou combinações de endereço IP e porta para recursos do Trusted 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:

• Endpoints GCE_VM_IP (compatíveis apenas com balanceadores de carga de rede de passagem interna e balanceadores de carga de rede de passagem com base em serviço de back-end).
• 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 que definem back-ends externos. Um back-end externo é um back-end hospedado em infraestrutura local ou em infraestrutura fornecida por terceiros.

O NEG da Internet é uma combinação de um nome de host ou endereço IP e uma porta opcional. Há dois tipos de endpoints de rede disponíveis para NEGs da Internet: INTERNET_FQDN_PORT e INTERNET_IP_PORT.

Para mais detalhes, consulte Visão geral do grupo de endpoints de rede da Internet.

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.

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 criptografia entre o balanceador de carga e os back-ends, consulte Criptografia para os 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 podem lidar com tráfego adicional ou estão totalmente carregados.

OTrusted Cloud tem quatro modos de balanceamento:

• CONNECTION: determina como a carga é distribuída com base no número total de conexões que o back-end pode processar.
• RATE: o número máximo desejado de solicitações (consultas) por segundo (RPS, QPS). O RPS/QPS máximo desejado pode ser excedido se todos os back-ends atingirem ou ultrapassarem a capacidade.
• UTILIZATION: determina como a carga é distribuída com base na utilização de instâncias em um grupo de instâncias.
• CUSTOM_METRICS: determina como a carga é distribuída com base em métricas personalizadas definidas pelo usuário.

Modos de balanceamento disponíveis para cada balanceador de carga

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 tipo de balanceador de carga e dos back-ends.

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

Os balanceadores de carga de aplicativo são compatíveis com os modos de balanceamento RATE, UTILIZATION ou CUSTOM_METRICS para back-ends de grupos de instâncias e com os modos RATE ou CUSTOM_METRICS para NEGs zonais (endpoints GCE_VM_IP_PORT) e 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 balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais, a capacidade desejada do modo de balanceamento é usada para calcular as proporções de quantas solicitações precisam ir para cada back-end (grupo de instâncias ou NEG) na região. Dentro de 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 dentro do grupo.

Os balanceadores de carga de rede de proxy são compatíveis com um destes modos de balanceamento, CONNECTION ou UTILIZATION, para back-ends de grupo de instâncias, o modo de balanceamento CONNECTION para NEGs zonais com endpoints 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 balanceadores de carga de rede de proxy externo regionais e balanceadores de carga de rede de proxy internos regionais, a capacidade desejada do modo de balanceamento de carga é usada para calcular as proporções de quantas solicitações precisam ir 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.

Se a utilização média de todas as VMs associadas a um serviço de back-end for inferior a 10%,o Trusted Cloud poderá preferir zonas específicas. Isso pode acontecer quando você usa grupos de instâncias gerenciadas por região, grupos de instâncias gerenciadas por zona em diferentes zonas e grupos de instâncias não gerenciadas por zona. 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 abertas. Exceto para balanceadores de carga de rede de passagem interna e externos de passagem, é 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

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 de instâncias de VM com instâncias N, definir max-connections-per-instance=X tem o mesmo significado que definir 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

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 Trusted Cloud para adicionar um grupo de instâncias de back-end a um serviço de back-end, o consoleTrusted Cloud define o valor de max-utilization como 0,8 (80%) se o modo de balanceamento UTILIZATION estiver 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.

Modo de balanceamento de métricas personalizadas

O modo de balanceamento CUSTOM_METRICS permite definir suas próprias métricas personalizadas que podem ser usadas para determinar como a carga é distribuída. Com as métricas personalizadas, é possível configurar o comportamento de distribuição de tráfego do balanceador de carga com base em métricas específicas dos requisitos de aplicativo ou infraestrutura, em vez de métricas padrão de utilização ou baseadas em taxa doTrusted Cloud.

Para mais informações, consulte Métricas personalizadas para balanceadores de carga de aplicativos.

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

Para produtos que aceitam uma especificação de capacidade desejada, ela não é um disjuntor. Quando o máximo de capacidade desejada configurado é atingido em uma determinada zona, novas solicitações ou conexões são distribuídas para outras zonas que não estão processando solicitações ou conexões na capacidade desejada. Se todas as zonas atingirem a capacidade desejada, novas solicitações ou conexões serão distribuídas por excesso de capacidade.

Balanceadores de carga de aplicativo e Cloud Service Mesh

Esta tabela lista as combinações disponíveis de modo de balanceamento e capacidade de destino para balanceadores de carga de aplicativo e Cloud Service Mesh.

Balanceadores de carga de rede proxy

Esta tabela lista as combinações disponíveis de modo de balanceamento e capacidade desejada para balanceadores de carga de rede de proxy.

Balanceadores de carga de rede de passagem

Esta tabela lista as combinações disponíveis de modo de balanceamento e capacidade de destino para balanceadores de carga de rede de passagem.

Escalonador de capacidade

Use o escalonador de capacidade para escalonar a capacidade desejada (uso máximo, taxa máxima ou conexões máximas) sem alterar a capacidade desejada.

Para a documentação de referência do Trusted Cloud , consulte:

• Google Cloud CLI: escalonador de capacidade
• API:
  • Regional

É possível ajustar o escalonador de capacidade para escalonar a capacidade desejada efetiva sem mudar explicitamente um dos parâmetros --max-*.

É possível definir o escalonador de capacidade como um destes valores:

• O valor padrão é 1, o que significa que o grupo disponibiliza até 100% da capacidade configurada (dependendo de balancingMode).
• Um valor de 0 significa que o grupo está completamente drenado, oferecendo 0% da capacidade disponível. Não é possível definir uma configuração de 0 quando há apenas um back-end anexado ao serviço de back-end.
• Um valor de 0.1 (10%) a 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, o max-rate será definido como 80 RPS e o escalonador de capacidade for 1.0, a capacidade disponível também será de 80 RPS.

• Se o modo de balanceamento for RATE, o max-rate for definido como 80 RPS e o escalonador de capacidade for 0.5, a capacidade disponível será 40 RPS (0.5 times 80).

• Se o modo de balanceamento for RATE, o max-rate será definido como 80 RPS e o escalonador de capacidade for 0.0, a capacidade disponível será zero (0).

Política de balanceamento de carga de serviço

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

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

Além disso, é possível designar back-ends específicos como back-ends preferenciais. Esses back-ends precisam ser usados de acordo com a capacidade (ou seja, a capacidade desejada especificada pelo modo de balanceamento do back-end) antes que as solicitações sejam enviadas aos back-ends restantes.

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

Política de localidade do balanceamento de carga

Em um serviço de back-end, a distribuição de tráfego é baseada em um modo de balanceamento e uma política de localidade de balanceamento de carga. O modo de balanceamento determina a fração de tráfego que precisa ser enviada para cada back-end (grupo de instâncias ou NEG). A política de localidade de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído entre instâncias ou endpoints em cada zona. Para grupos gerenciados de instâncias regionais, a política de localidade se aplica a cada zona constituinte.

A política de localidade de balanceamento de carga é configurada por serviço de back-end. As seguintes configurações estão disponíveis:

• ROUND_ROBIN (padrão): essa é a configuração padrão da política de localidade de balanceamento de carga em que o balanceador de carga seleciona um back-end íntegro em ordem de round robin.

• WEIGHTED_ROUND_ROBIN: o balanceador de carga usa métricas personalizadas definidas pelo usuário para selecionar a instância ou o endpoint ideal no back-end para atender à solicitação.

• LEAST_REQUEST: um algoritmo O(1) em que o balanceador de carga seleciona dois hosts íntegros aleatórios e escolhe o host com menos solicitações ativas.

• RING_HASH: esse algoritmo implementa hashing consistente para back-ends. O algoritmo tem a propriedade de que a adição ou remoção de um host de um conjunto de N hosts afeta apenas 1/N das solicitações.

• RANDOM: o balanceador de carga seleciona um host íntegro aleatório.

• ORIGINAL_DESTINATION: o balanceador de carga seleciona um back-end com base nos metadados de conexão do cliente. As conexões são abertas para o endereço IP de destino original especificado na solicitação do cliente recebida, antes de ela ser redirecionada para o balanceador de carga.

  ORIGINAL_DESTINATION não é compatível com balanceadores de carga de aplicativo externos globais e regionais.

• MAGLEV: implementa hashing consistente para back-ends e pode ser usado como uma substituição da política RING_HASH. O Maglev não é tão estável quanto o RING_HASH, mas é mais rápido na criação de tabela de pesquisa e na seleção de host. Para mais informações sobre o Maglev, consulte o white paper do Maglev (em inglês).

• WEIGHTED_MAGLEV: implementa o balanceamento de carga ponderado por instância usando pesos informados por verificações de integridade. Se essa política for usada, o serviço de back-end precisará configurar uma verificação de integridade não legada baseada em HTTP, e as respostas de verificação de integridade devem conter o campo de cabeçalho de resposta HTTP não padrão, X-Load-Balancing-Endpoint-Weight, para especificar os pesos por instância. As decisões de balanceamento de carga são tomadas com base nos pesos por instância informados nas últimas respostas de verificação de integridade processadas, desde que cada instância informe um peso válido ou UNAVAILABLE_WEIGHT. Caso contrário, o balanceamento de carga vai permanecer com peso igual.

  WEIGHTED_MAGLEV é compatível apenas com balanceadores de carga de rede de passagem externa. Por exemplo, consulte Configurar o balanceamento de carga ponderado para balanceadores de carga de rede de passagem externa.

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

• Balanceador de carga de aplicativo externo global
• Balanceador de carga de aplicativo externo regional
• Balanceador de carga de aplicativo interno entre regiões
• Balanceador de carga de aplicativo interno regional
• Balanceador de carga de rede de passagem externa

O valor padrão efetivo da política de localidade de balanceamento de carga (localityLbPolicy) muda de acordo com as configurações de afinidade da sessão. Se a afinidade da sessão não estiver configurada, ou seja, se a afinidade da sessão permanecer com o valor padrão de NONE, o valor padrão de localityLbPolicy será ROUND_ROBIN. Se a afinidade da sessão for definida como um valor diferente de NONE, o valor padrão de localityLbPolicy será MAGLEV.

Para configurar uma política de localidade de balanceamento de carga, use o console do Trusted Cloud , o gcloud (--locality-lb-policy) ou a API (localityLbPolicy).

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:

• Balanceador de carga de aplicativo interno regional
• Balanceador de carga de rede de passagem interna

Subconfiguração de back-end para balanceadores de carga de aplicativo internos regionais

Nos balanceadores de carga de aplicativo internos regionais, a subconfiguração de back-end atribui automaticamente a cada instância de proxy apenas um subconjunto dos back-ends contidos no serviço de back-end regional. Por padrão, cada instância de proxy abre conexões com todos os back-ends contidos em um serviço de back-end. Quando o número de instâncias de proxy e os back-ends são grandes, abrir conexões a todos os back-ends pode causar problemas de desempenho.

Ao ativar a subconfiguração, cada proxy só abre conexões para um subconjunto 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 dos 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.

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 ler sobre a configuração de subconjuntos de back-end para balanceadores de carga de aplicativo internos, consulte Configurar subconjunto do back-end.

Advertências relacionadas à criação de subconjuntos de back-end para o balanceador de carga de aplicativo 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 interrompem as conexões atuais.
• 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.

Subagrupamento de back-end para o balanceador de carga de rede de passagem interna

O subconjunto de back-end de balanceadores de carga de rede de passagem interna permite escalonar o balanceador de carga de rede de passagem interna 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.

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 à criação de subconjuntos de back-end para passagem do balanceador de carga de rede 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 subconjuntos.
• A ativação e a desativação da criação de subconfigurações interrompem as conexões atuais.
• Se os clientes no local precisarem acessar um balanceador de carga de rede 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 doTrusted Cloud fornecem afinidade da 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, mudanças nos pesos do back-end (incluindo ativar ou desativar o balanceamento ponderado) ou mudanças na integridade do back-end, conforme medido pelo modo de balanceamento, podem interromper a afinidade da sessão.

O balanceamento 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 vai 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 Trusted Cloud 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 saber mais sobre afinidade da sessão para balanceadores de carga de rede de passagem, consulte os seguintes documentos:

• Distribuição de tráfego para balanceadores de carga de rede de passagem externa
• Distribuição de tráfego para balanceadores de carga de rede de passagem interna

Para saber mais sobre afinidade da sessão para balanceadores de carga de aplicativo, consulte os seguintes documentos:

• Afinidade de sessão para balanceadores de carga de aplicativo externos
• Afinidade de sessão para balanceadores de carga de aplicativo internos

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

• Afinidade de sessão para balanceadores de carga de rede de proxy externo
• Afinidade de sessão para balanceadores de carga de rede de proxy interno

Tempo limite do serviço de back-end

A maioria dos balanceadores de carga do Trusted 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 de aplicativo 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 e resposta para HTTP(S) tráfego.

  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 aplicativo externos regionais, consulte Tempos limite e tentativas.
  • Para balanceadores de carga de aplicativos internos, consulte Tempos limite e tentativas.

• Para balanceadores de carga de rede de proxy externo, 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 de rede de passagem interna e externa de passagem, é possível definir 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.

Verificações de integridade

Cada serviço de back-end com back-ends que são grupos de instâncias ou NEGs zonais precisa ter uma verificação de integridade associada.

É possível criar a verificação de integridade ao gerar um balanceador de carga usando o console Trusted 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:

• Visão geral das verificações de integridade
• Como criar verificações de integridade
• Página de verificação de integridade de gcloud
• Página de verificação de integridade da API REST

IAP

Com o IAP, é possível estabelecer uma camada de autorização central para aplicativos acessados por HTTPS. Assim, você tem a opção de usar um modelo de controle de acesso no nível do aplicativo, em vez de contar apenas com os firewalls da rede. O IAP é compatível com determinados balanceadores de carga de aplicativo.

O IAP é incompatível com o Cloud CDN. Elas não podem ser ativadas no mesmo serviço de back-end.

Recursos avançados de gerenciamento de tráfego

Para saber mais sobre os recursos avançados de gerenciamento de tráfego configurados nos serviços de back-end e mapas de URL associados aos balanceadores de carga, consulte o seguinte:

• Visão geral do gerenciamento de tráfego para balanceadores de carga internos de aplicativos
• Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos globais
• Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos regionais

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:

• Recurso da API de serviço de back-end regional

• Página gcloud compute backend-services, para serviços de back-end globais e regionais

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:

• Criar cabeçalhos personalizados
• Criar um balanceador de carga de aplicativo externo
• Visão geral do balanceador de carga de aplicativo externo
• Ativar a diminuição da conexão
• Criptografia em trânsito no Trusted Cloud