Otimizações avançadas de balanceamento de carga

Nesta página, descrevemos como usar uma política de balanceamento de carga de serviço para dar suporte a otimizações avançadas de custo, latência e resiliência dos seguintes balanceadores de carga:

Balanceador de carga de aplicativo externo global
Balanceador de carga de aplicativo interno entre regiões
Balanceador de carga de rede de proxy externo global
Balanceador de carga de rede de proxy interno entre regiões

O Traffic Director também oferece suporte a otimizações avançadas de balanceamento de carga. Para detalhes, consulte Visão geral do balanceamento de carga avançado na documentação do Traffic Director.

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

Personalizar o algoritmo de balanceamento de carga usado para determinar como o tráfego é distribuído em uma determinada região ou zona.
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.
Defina um limite de failover para determinar quando um back-end é considerado não íntegro. Isso permite que o tráfego faça o failover para um back-end diferente a fim de evitar 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 em relação à capacidade antes que as solicitações sejam enviadas aos outros back-ends.

No diagrama a seguir, mostramos como o Cloud Load Balancing avalia o roteamento, o balanceamento de carga e a distribuição de tráfego.

Como o Cloud Load Balancing toma decisões de roteamento e distribuição de tráfego.

Antes de começar

Antes de analisar o conteúdo desta página, analise cuidadosamente o Processo de solicitação de distribuição descrito na página de visão geral do balanceador de carga de aplicativo externo. Para balanceadores de carga de aplicativo externos globais que sempre são do nível Premium, todos os algoritmos de balanceamento de carga descritos nesta página são compatíveis com o compartilhamento entre regiões se uma região de primeira escolha já estiver cheia.

Back-ends compatíveis

Só é possível configurar as políticas de balanceamento de carga de serviço e os back-ends preferidos em balanceadores de carga que usam os back-ends compatíveis, conforme indicado na tabela a seguir.

Back-end	Compatível?
Grupos de instâncias Não gerenciado Gerenciado por zona
MIGs regionais
NEGs zonais (endpoints `GCE_VM_IP_PORT`)
NEGs híbridos (endpoints `NON_GCP_PRIVATE_IP_PORT`)
NEGs sem servidor
NEGs na Internet
NEGs do Private Service Connect

Algoritmos de balanceamento de carga

Nesta seção, descrevemos os algoritmos de balanceamento de carga que podem ser configurados em uma política de balanceamento de carga de serviço. Se você não configurar um algoritmo ou não configurar uma política de balanceamento de carga de serviço, o balanceador de carga usará WATERFALL_BY_REGION por padrão.

Cascata por região

WATERFALL_BY_REGION é o algoritmo de balanceamento de carga padrão. Com esse algoritmo, todos os Google Front Ends (GFEs) em uma região tentam preencher back-ends proporcionalmente às capacidades de destino configuradas (modificadas pelos escalonadores de capacidade).

Cada GFE de segunda camada prefere selecionar instâncias de back-end ou endpoints em uma zona o mais próxima possível (definida pelo tempo de retorno da rede) do GFE de segunda camada. Como WATERFALL_BY_REGION minimiza a latência entre zonas, a baixas taxas de solicitação, cada GFE de segunda camada pode enviar solicitações exclusivamente aos back-ends na zona preferida do GFE de segunda camada.

Distribuição por região

O algoritmo SPRAY_TO_REGION modifica o comportamento individual de cada GFE de segunda camada a ponto de que cada GFE de segunda camada não tenha preferência para selecionar instâncias de back-end ou endpoints que estão em uma zona o mais próximo possível do GFE de segunda camada. Com SPRAY_TO_REGION, cada GFE de segunda camada envia solicitações para todos os endpoints ou instâncias de back-end, em todas as zonas da região, sem preferência por um tempo de retorno mais curto entre o GFE de segunda camada e as instâncias ou endpoints de back-end.

Como WATERFALL_BY_REGION, em agregação, todos os GFEs de segunda camada na região preenchem back-ends na proporção às capacidades de destino configuradas (modificadas pelos escalonadores de capacidade).

Embora SPRAY_TO_REGION forneça uma distribuição mais uniforme entre back-ends em todas as zonas de uma região, especialmente em baixas taxas de solicitação, essa distribuição uniforme tem as seguintes considerações:

Quando os back-ends ficam inativos, mas continuam passando nas verificações de integridade, mais GFEs de segunda camada são afetados, embora o impacto individual seja menos grave.
Como cada GFE de segunda camada não tem preferência por uma zona em relação a outra, os GFEs de segunda camada criam mais tráfego entre zonas. Dependendo do número de solicitações que estão sendo processadas, cada GFE de segunda camada também pode criar mais conexões TCP com os back-ends.

Hierarquia por zona

O algoritmo WATERFALL_BY_ZONE modifica o comportamento individual de cada GFE de segunda camada, já que cada GFE de segunda camada tem uma preferência muito forte para selecionar instâncias ou endpoints de back-end que estão na zona mais próxima possível do GFE de segunda camada. Com WATERFALL_BY_ZONE, cada GFE de segunda camada envia solicitações apenas para instâncias de back-end ou endpoints em outras zonas da região quando a segunda camada O GFE preencheu instâncias ou endpoints de back-end proporcionalmente sobrecarregados na zona favorável dele.

O algoritmo WATERFALL_BY_ZONE minimiza a latência com as seguintes considerações:

WATERFALL_BY_ZONE não minimiza inerentemente as conexões entre zonas. O algoritmo é orientado apenas pela latência.
WATERFALL_BY_ZONE não garante que cada GFE de segunda camada sempre preencha a zona mais favorecida antes de preencher outras zonas. Os eventos de manutenção podem fazer com que todo o tráfego de um GFE de segunda camada seja enviado para instâncias de back-end ou endpoints em outra zona.
WATERFALL_BY_ZONE pode resultar em uma distribuição menos uniforme de solicitações entre todas as instâncias de back-end ou endpoints na região como um todo. Por exemplo, instâncias ou endpoints de back-end na zona mais favorecida do GFE de segunda camada podem estar preenchidos, enquanto os back-ends de outras zonas não estão preenchidos.

Comparar algoritmos de balanceamento de carga

Veja na tabela a seguir uma comparação dos diferentes algoritmos de balanceamento de carga.

Comportamento	Cascata por região	Distribuição por região	Hierarquia por zona
Uso de capacidade uniforme em uma única região	Sim	Sim	Não
Uso uniforme da capacidade em várias regiões	Não	Não	Não
Divisão de tráfego uniforme do balanceador de carga	Não	Sim	Não
Distribuição de tráfego entre zonas	Sim. O tráfego é distribuído uniformemente entre as zonas de uma região, otimizando a latência da rede. É possível que o tráfego seja enviado entre zonas, se necessário.	Sim	Sim. Primeiro, o trânsito segue para a zona mais próxima até atingir a capacidade máxima. Depois, ele vai para a zona seguinte mais próxima.
Sensibilidade a picos de tráfego em uma zona local	Média; depende da quantidade de tráfego que já foi deslocado para o balanceamento entre as zonas.	Menor; picos de zona única estão espalhados por todas as zonas da região.	Maior; picos de zona única provavelmente serão atendidos pela mesma zona até que o balanceador de carga consiga reagir.

Diminuição de capacidade automática

Quando um back-end não está íntegro, ele costuma ser excluído das decisões de balanceamento de carga o mais rápido possível. A exclusão de back-ends não íntegros otimiza a latência geral ao enviar tráfego apenas para back-ends íntegros.

Quando você ativa o recurso de diminuição da capacidade automática, o balanceador de carga escalona automaticamente a capacidade de um back-end para zero quando menos de 25% das instâncias ou endpoints do back-end estiverem passando nas verificações de integridade. Isso remove o back-end não íntegro do pool de balanceamento de carga global. Esta ação é funcionalmente equivalente a definir backendService.capacityScaler como 0 para um back-end quando você quiser evitar o roteamento de tráfego para esse back-end.

Se 35% (10% acima do limite) das instâncias ou endpoints de um back-end anteriormente reduzidos a serem aprovados nas verificações de integridade por 60 segundos, o back-end será automaticamente liberado e adicionado novamente ao pool de balanceamento de carga. Isso garante que o back-end esteja realmente íntegro e não alterne entre um estado drenado e não drenado.

Mesmo com a diminuição da capacidade automática ativada, o balanceador de carga não drena mais de 50% dos back-ends anexados a um serviço de back-end, independentemente do status de integridade de um back-end. Manter 50% dos back-ends anexados reduz o risco de sobrecarregar back-ends íntegros.

Um caso de uso de diminuição automática da capacidade é usá-la para minimizar o risco de sobrecarga dos seus back-ends preferidos. Por exemplo, se um back-end for marcado como preferencial, mas a maioria das instâncias ou endpoints não estiver íntegra, a drenagem automática da capacidade removerá o back-end do pool de balanceamento de carga. Em vez de sobrecarregar as instâncias ou endpoints íntegros restantes no back-end preferido, a drenagem automática da capacidade transfere o tráfego para outros back-ends.

É possível ativar a diminuição automática da capacidade como parte da política de balanceamento de carga de serviço. Para saber mais detalhes, consulte Configurar uma política de balanceamento de carga de serviço.

A capacidade automática não é compatível com back-ends que não usam um modo de balanceamento. Isso inclui back-ends como NEGs da internet, NEGs sem servidor e NEGs de PSC.

Limite de failover

O balanceador de carga determina a distribuição de tráfego entre back-ends de vários níveis. No estado estável, ele envia tráfego para back-ends selecionados com base em um dos algoritmos de balanceamento de carga descritos anteriormente. Esses back-ends, chamados de back-ends primários, são considerados ideais em termos de latência e capacidade.

O balanceador de carga também monitora outros back-ends que podem ser usados se os back-ends primários se tornarem não íntegros e não conseguirem lidar com o tráfego. Esses back-ends são chamados de back-ends de failover. Esses back-ends geralmente são back-ends próximos com capacidade restante.

Se as instâncias ou os endpoints no back-end primário não estiverem íntegros, o balanceador de carga não vai transferir o tráfego para outros back-ends imediatamente. Em vez disso, o balanceador de carga transfere primeiro o tráfego para outras instâncias íntegras ou endpoints no mesmo back-end para ajudar a estabilizar a carga do tráfego. Se muitos endpoints em um back-end primário não estiverem íntegros e os endpoints restantes no mesmo back-end não conseguirem lidar com o tráfego extra, o balanceador de carga vai usar o limite de failover para determinar quando começar a enviar tráfego para um back-end de failover. O balanceador de carga tolera a falta de integridade no back-end principal até o limite de failover. Depois disso, o tráfego é transferido do back-end principal.

O limite de failover é um valor entre 1 e 99, expresso como uma porcentagem de endpoints em um back-end que precisam estar íntegros. Se a porcentagem de endpoints íntegros ficar abaixo do limite de failover, o balanceador de carga tentará enviar tráfego para um back-end de failover. Por padrão, o limite de failover é 70.

Se o limite de failover for muito alto, poderão ocorrer vazamentos de tráfego desnecessários devido a mudanças temporárias na integridade. Se o limite de failover for muito baixo, o balanceador de carga continuará enviando tráfego para os back-ends principais, mesmo que haja muitos endpoints não íntegros.

As decisões de failover são localizadas. Cada Google Front End (GFE) local se comporta de maneira independente do outro. Você é responsável por garantir que seus back-ends de failover possam lidar com o tráfego adicional.

O tráfego de failover pode resultar em back-ends sobrecarregados. Mesmo que um back-end não esteja íntegro, o balanceador de carga ainda poderá enviar tráfego para ele. Para excluir back-ends não íntegros do pool de back-ends disponíveis, ative o recurso de drenagem automática de capacidade.

Back-ends preferenciais

Back-ends preferidos são aqueles que têm uma capacidade que você quer usar completamente antes de distribuir o tráfego para outros back-ends. Qualquer tráfego acima da capacidade configurada de back-ends preferidos é encaminhado para os demais back-ends não preferenciais. Em seguida, o algoritmo de balanceamento de carga distribui o tráfego entre os back-ends não preferidos de um serviço de back-end.

É possível configurar o balanceador de carga de aplicativo externo global para preferir e usar completamente um ou mais back-ends anexados a um serviço de back-end antes de rotear solicitações subsequentes para os back-ends restantes.

Considere as seguintes limitações ao usar back-ends preferidos:

Os back-ends configurados como back-ends preferidos podem estar mais longe dos clientes e resultar em uma latência média maior para solicitações de clientes. Isso acontece mesmo se houver outros back-ends mais próximos que poderiam ter atendido aos clientes com menor latência.
Alguns algoritmos de balanceamento de carga (WATERFALL_BY_REGION, SPRAY_TO_REGION e WATERFALL_BY_ZONE) não se aplicam a back-ends configurados como back-ends preferidos.

Para saber como definir back-ends preferidos, consulte Definir back-ends preferenciais.

Configurar uma política de balanceamento de carga de serviço

O recurso de política de balanceamento de carga de serviço permite configurar os seguintes campos:

Algoritmo de balanceamento de carga
Diminuição de capacidade automática
Limite de failover

Para definir um back-end preferido, consulte Definir back-ends preferenciais.

Criar uma política

Para criar e configurar uma política de balanceamento de carga de serviço, conclua as seguintes etapas:

Criar um recurso de política de balanceamento de carga de serviço. É possível fazer isso usando um arquivo YAML ou diretamente, usando parâmetros gcloud.
- Com um arquivo YAML. Especifique as políticas de balanceamento de carga de serviço em um arquivo YAML. Veja um exemplo de arquivo YAML que mostra como configurar um algoritmo de balanceamento de carga, ativar a diminuição da capacidade automática e definir um limite de failover personalizado:
```
name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
- autoCapacityDrain:
    enable: True
- loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
- failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
```
  Substitua:
  - PROJECT_ID: o ID do projeto.
  - SERVICE_LB_POLICY_NAME: o nome da política de balanceamento de carga do serviço.
  - LOAD_BALANCING_ALGORITHM: o algoritmo de balanceamento de carga a ser usado. Pode ser SPRAY_TO_REGION, WATERFALL_BY_REGION ou WATERFALL_BY_ZONE.
  - FAILOVER_THRESHOLD_VALUE: o valor do limite de failover. Deve ser um número entre 1 e 99.
  Depois de criar o arquivo YAML, importe-o para uma nova política de balanceamento de carga de serviço.
```
gcloud beta network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
 --source=PATH_TO_POLICY_FILE \
 --location=global
```
- Sem um arquivo YAML. Como alternativa, é possível configurar os recursos da política de balanceamento de carga de serviço sem usar um arquivo YAML.
  
  Para definir o algoritmo de balanceamento de carga e ativar a drenagem automática, use os seguintes parâmetros:
```
gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
 --load-balancing-algorithm=LOAD_BALANCING_ALGORITHM \
 --auto-capacity-drain \
 --failover-health-threshold=FAILOVER_THRESHOLD_VALUE \
 --location=global
```
  Substitua:
  - SERVICE_LB_POLICY_NAME: o nome da política de balanceamento de carga do serviço.
  - LOAD_BALANCING_ALGORITHM: o algoritmo de balanceamento de carga a ser usado. Pode ser SPRAY_TO_REGION, WATERFALL_BY_REGION ou WATERFALL_BY_ZONE.
  - FAILOVER_THRESHOLD_VALUE: o valor do limite de failover. Deve ser um número entre 1 e 99.

Atualize um serviço de back-end para que o campo --service-lb-policy faça referência ao recurso de política de balanceamento de carga de serviço recém-criado. Um serviço de back-end só pode ser associado a um recurso de política de balanceamento de carga de serviço.

gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
  --service-lb-policy=SERVICE_LB_POLICY_NAME \
  --global

É possível associar uma política de balanceamento de carga a um serviço de back-end durante a criação desse serviço.

gcloud beta compute backend-services create BACKEND_SERVICE_NAME \
    --protocol=PROTOCOL \
    --port-name=NAMED_PORT_NAME \
    --health-checks=HEALTH_CHECK_NAME \
    --load-balancing-scheme=LOAD_BALANCING_SCHEME \
    --service-lb-policy=SERVICE_LB_POLICY_NAME \
    --global

Remover uma política

Para remover uma política de balanceamento de carga de um serviço de back-end, use o seguinte comando:

gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

Definir back-ends preferidos

É possível configurar back-ends preferidos usando a Google Cloud CLI ou a API.

gcloud

Adicionar um back-end preferido

Para definir um back-end preferido, use o comando gcloud beta compute backend-services add-backend para definir a sinalização --preference ao adicionar o back-end ao serviço de back-end.

gcloud beta compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

Substitua PREFERENCE pelo nível de preferência que você quer atribuir ao back-end. Pode ser PREFERRED ou DEFAULT.

O restante do comando depende do tipo de back-end que você está usando (grupo de instâncias ou NEG). Para todos os parâmetros obrigatórios, consulte o comando gcloud beta compute backend-services add-backend.

Atualizar a preferência de um back-end

Para atualizar o parâmetro --preference de um back-end, use o comando gcloud beta compute backend-services update-backend.

gcloud beta compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

O restante do comando depende do tipo de back-end que você está usando (grupo de instâncias ou NEG). O comando de exemplo a seguir atualiza a preferência de um grupo de instâncias de back-end e a define como PREFERRED:

gcloud beta compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    --global

API

Para definir um back-end preferido, defina a sinalização preference em cada back-end usando o recurso backendServices global.

Este é um exemplo que mostra como configurar a preferência de back-end:

  name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: DEFAULT
      ...

Substitua:

PROJECT_ID: o ID do projeto;
BACKEND_SERVICE_NAME: o nome do serviço de back-end
BACKEND_1_NAME: o nome do back-end preferencial.
BACKEND_2_NAME: o nome do back-end padrão.

Solução de problemas

Os padrões de distribuição de tráfego podem mudar quando você anexa uma nova política de balanceamento de carga de serviço a um serviço de back-end.

Para depurar problemas de tráfego, use o Cloud Monitoring para analisar como o tráfego flui entre o balanceador de carga e o back-end. Os registros e as métricas do Cloud Load Balancing também podem ajudar a entender o comportamento do balanceamento de carga.

Esta seção resume alguns cenários comuns que podem ser encontrados na configuração recém-exposta.

O tráfego de uma única origem é enviado para muitos back-ends distintos

Esse é o comportamento pretendido do algoritmo SPRAY_TO_REGION. No entanto, talvez você tenha problemas causados pela distribuição mais ampla do seu tráfego. Por exemplo, as taxas de ocorrência em cache podem diminuir porque os back-ends veem o tráfego de uma seleção mais ampla de clientes. Nesse caso, use outros algoritmos, como WATERFALL_BY_REGION.

O tráfego não está sendo enviado para back-ends com muitos endpoints não íntegros

Esse é o comportamento esperado quando autoCapacityDrain está ativado. Os back-ends com muitos endpoints não íntegros são drenados e removidos do pool de equilíbrio de carga. Se você não quiser esse comportamento, desative a redução de capacidade automática. No entanto, isso significa que o tráfego pode ser enviado para back-ends com muitos endpoints não íntegros e as solicitações podem falhar.

O tráfego está sendo enviado para back-ends mais distantes antes dos mais próximos

Esse será o comportamento pretendido se seus back-ends preferidos estiverem mais longe do que os back-ends padrão. Se você não quiser esse comportamento, atualize as configurações de preferência de cada back-end.

O tráfego não está sendo enviado para alguns back-ends ao usar back-ends preferidos

Esse é o comportamento esperado quando seus back-ends preferidos ainda não atingiram a capacidade. Os back-ends preferidos são atribuídos primeiro com base na latência de tempo de retorno.

Se você quiser que o tráfego seja enviado para outros back-ends, siga um destes procedimentos:

Atualize as configurações de preferência dos outros back-ends.
Defina uma configuração de capacidade desejada mais baixa para seus back-ends preferidos. A capacidade desejada é configurada usando os campos max-rate ou max-utilization, dependendo do modo de balanceamento do serviço de back-end.

O tráfego está sendo enviado para um back-end remoto durante mudanças de integridade temporárias

Esse é o comportamento esperado quando o limite de failover é definido como um valor alto. Se você quiser que o tráfego continue indo para os back-ends primários quando houver alterações de integridade temporárias, defina esse campo com um valor mais baixo.

Os endpoints íntegros são sobrecarregados quando os outros não estão íntegros

Esse é o comportamento esperado quando o limite de failover é definido como um valor baixo. Quando os endpoints não estão íntegros, o tráfego destinado a esses endpoints não íntegros é distribuído entre os endpoints restantes no mesmo back-end. Se você quiser que o comportamento de failover seja acionado mais rapidamente, defina esse campo com um valor mais alto.

Limitações

Cada serviço de back-end só pode ser associado a um único recurso de política de balanceamento de carga de serviço.