Otimizações avançadas do balanceamento de carga

Esta página descreve como configurar otimizações avançadas de custo, latência e resiliência para equilibradores de carga de aplicações e equilibradores de carga de rede de proxy.

O Cloud Service Mesh também suporta otimizações avançadas do equilíbrio de carga. Para ver detalhes, consulte a vista geral do equilíbrio de carga avançado na documentação do Cloud Service Mesh.

O Cloud Load Balancing oferece as seguintes funcionalidades avançadas:

• Política de balanceamento de carga de serviços. Uma política de balanceamento de carga de serviço (serviceLbPolicy) é um recurso associado ao serviço de back-end do balanceador de carga. Uma política de balanceamento de carga do serviço permite-lhe personalizar os seguintes parâmetros para influenciar a forma como o tráfego é distribuído entre os back-ends associados a um serviço de back-end:

  • Algoritmos de balanceamento de carga. Personalize o algoritmo de equilíbrio de carga usado para determinar como o tráfego é distribuído numa região ou numa zona específica.
  • Diminuição automática da capacidade. Ative a drenagem automática da capacidade para que o balanceador de carga possa drenar rapidamente o tráfego de back-ends não íntegros.
  • Limiar de alternativa. Defina um limite de comutação por falha para determinar quando um back-end é considerado não saudável. Isto permite que o tráfego seja transferido para um back-end diferente para evitar back-ends não saudáveis.
  • Isolamento de tráfego. Evite falhas em cascata limitando ou proibindo o excesso de tráfego entre regiões.

• Back-ends preferenciais. Pode designar back-ends específicos como back-ends preferenciais. Estes backends têm de ser usados na capacidade máxima antes de os pedidos serem enviados para os backends restantes.

O diagrama seguinte mostra como o Cloud Load Balancing avalia o encaminhamento, o balanceamento de carga e a distribuição de tráfego.

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

Antes de começar

Antes de rever o conteúdo desta página, reveja cuidadosamente o processo de pedido de distribuição descrito na página de vista geral do External Application Load Balancer. Para os balanceadores de carga que são sempre de nível Premium, todos os algoritmos de balanceamento de carga descritos nesta página suportam o transbordo entre regiões se uma região de primeira escolha já estiver cheia.

Balanceadores de carga e back-ends suportados

Os seguintes balanceadores de carga suportam políticas de balanceamento de carga de serviços e back-ends preferenciais:

• Balanceador de carga de aplicações externo global
• Balanceador de carga de aplicações interno entre regiões
• Balanceador de carga de rede de proxy externo global
• Balanceador de carga de rede de proxy interno entre regiões

As funcionalidades descritas nesta página requerem back-ends compatíveis que suportem um modo de equilíbrio. Os backends suportados estão resumidos na tabela seguinte:

Back-end	Suportado?
Grupos de instâncias	Os grupos de instâncias não geridas zonais e geridas zonais são suportados, mas os grupos de instâncias geridas regionais não são.
NEGs zonais (GCE_VM_IP_PORT pontos finais)
NEGs zonais (GCE_VM_IP pontos finais)	Estes tipos de NEGs não são suportados por equilibradores de carga de aplicações e equilibradores de carga de rede de proxy.
NEGs híbridos (NON_GCP_PRIVATE_IP_PORT pontos finais)
NEGs sem servidor
NEGs da Internet
NEGs do Private Service Connect

Algoritmos de balanceamento de carga

Esta secção descreve os algoritmos de equilíbrio de carga que pode configurar numa política de equilíbrio de carga do serviço. Se não configurar um algoritmo ou não configurar nenhuma política de equilíbrio de carga do serviço, o equilibrador de carga usa WATERFALL_BY_REGION por predefinição.

Cascata por região

WATERFALL_BY_REGION é o algoritmo de balanceamento de carga predefinido. Com este algoritmo, no total, todos os front-ends da Google (GFEs) na região mais próxima do utilizador tentam preencher os back-ends proporcionalmente às respetivas capacidades de destino configuradas (modificadas pelos respetivos escaladores de capacidade).

Cada GFE de segunda camada individual prefere selecionar instâncias ou pontos finais de back-end numa zona o mais próxima possível (definida pelo tempo de resposta de ida e volta da rede) do GFE de segunda camada. Uma vez que WATERFALL_BY_REGION minimiza a latência entre zonas, a taxas de pedidos baixas, cada GFE de segunda camada pode enviar pedidos exclusivamente para back-ends na zona preferencial do GFE de segunda camada.

Se todos os back-ends na região mais próxima estiverem a funcionar no limite de capacidade configurado, o tráfego começa a transbordar para a região seguinte mais próxima enquanto otimiza a latência da rede.

Pulverize para a região

O algoritmo SPRAY_TO_REGION modifica o comportamento individual de cada GFE de segunda camada na medida em que cada GFE de segunda camada não tem preferência por selecionar instâncias ou pontos finais de back-end que estejam numa zona o mais próxima possível do GFE de segunda camada. Com o SPRAY_TO_REGION, cada GFE de segunda camada envia pedidos a todas as instâncias ou pontos finais de back-end, em todas as zonas da região, sem preferência por um tempo de resposta mais curto entre o GFE de segunda camada e as instâncias ou os pontos finais de back-end.

Tal como WATERFALL_BY_REGION, no total, todos os GFEs de segunda camada na região preenchem os back-ends proporcionalmente às respetivas capacidades de destino configuradas (modificadas pelos respetivos escaladores de capacidade).

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

• Quando os back-ends ficam indisponíveis (mas continuam a passar nas verificações de estado), mais GFEs de segunda camada são afetados, embora o impacto individual seja menos grave.
• Uma vez que cada GFE de segunda camada não tem preferência por uma zona em detrimento de outra, os GFEs de segunda camada criam mais tráfego entre zonas. Consoante o número de pedidos que estão a ser processados, cada GFE de segunda camada também pode criar mais ligações TCP aos back-ends.

Hierarquia de publicação por zona

O algoritmo WATERFALL_BY_ZONE modifica o comportamento individual de cada GFE de segunda camada na medida em que cada GFE de segunda camada tem uma preferência muito forte por selecionar instâncias ou pontos finais de back-end que se encontram na zona mais próxima possível do GFE de segunda camada. Com o WATERFALL_BY_ZONE, cada GFE de segunda camada só envia pedidos para instâncias ou pontos finais de back-end noutras zonas da região quando o GFE de segunda camada tiver preenchido (ou preenchido proporcionalmente) instâncias ou pontos finais de back-end na sua zona mais favorecida.

Tal como WATERFALL_BY_REGION, no total, todos os GFEs de segunda camada na região preenchem os back-ends proporcionalmente às respetivas capacidades de destino configuradas (modificadas pelos respetivos escaladores de capacidade).

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

• WATERFALL_BY_ZONE não minimiza inerentemente as associações entre zonas. O algoritmo é orientado apenas pela latência.
• WATERFALL_BY_ZONE não garante que cada GFE de segunda camada preenche sempre a sua zona mais favorecida antes de preencher outras zonas. Os eventos de manutenção podem fazer com que, temporariamente, todo o tráfego de um GFE de segunda camada seja enviado para instâncias ou pontos finais de back-end noutra zona.
• WATERFALL_BY_ZONE pode resultar numa distribuição menos uniforme de pedidos entre todas as instâncias ou pontos finais de back-end na região como um todo. Por exemplo, as instâncias ou os pontos finais de back-end na zona mais favorecida do GFE de segunda camada podem estar cheios, enquanto os back-ends noutras zonas não estão cheios.

Compare algoritmos de balanceamento de carga

A tabela seguinte compara os diferentes algoritmos de equilíbrio de carga.

Comportamento	Cascata por região	Pulverize para a região	Hierarquia de publicação por zona
Utilização uniforme da capacidade numa única região	Sim	Sim	Não
Utilização uniforme da capacidade em várias regiões	Não	Não	Não
Divisão de tráfego uniforme a partir do balanceador de carga	Não	Sim	Não
Distribuição de tráfego entre zonas	Sim. O tráfego é distribuído uniformemente pelas zonas numa região enquanto otimiza a latência da rede. O tráfego pode ser enviado entre zonas, se necessário.	Sim	Sim. O tráfego é primeiro direcionado para a zona mais próxima até atingir a capacidade máxima. Em seguida, passa para a zona mais próxima seguinte.
Sensibilidade a picos de tráfego numa zona local	Média; depende da quantidade de tráfego que já foi mudada para equilibrar entre zonas.	Mais baixo; os picos de uma única zona são distribuídos por todas as zonas da região.	Mais elevado; é provável que os picos de uma única zona sejam totalmente servidos pela mesma zona até que o balanceador de carga consiga reagir.

Drenagem e não drenagem automáticas da capacidade

A drenagem e a não drenagem automáticas da capacidade combinam os conceitos de verificações de funcionamento e capacidade do back-end. Com a diminuição automática da capacidade, as verificações de funcionamento são usadas como um sinal adicional para definir a capacidade efetiva do back-end como zero. Com a anulação da drenagem automática da capacidade, as verificações de estado são usadas como um sinal adicional para restaurar a capacidade efetiva do back-end para o valor anterior.

Sem a redução e o aumento automáticos da capacidade, se quiser direcionar pedidos para longe de todos os back-ends numa região específica, tem de definir manualmente a capacidade efetiva de cada back-end nessa região como zero. Por exemplo, pode usar o ajuste de escala da capacidade para o fazer.

Com a drenagem e a não drenagem automáticas da capacidade, as verificações de estado podem ser usadas como um sinal para ajustar a capacidade de um back-end, através da drenagem ou da não drenagem.

Para ativar a drenagem e a não drenagem automáticas da capacidade, consulte o artigo Configure uma política de balanceamento de carga do serviço.

Consumo automático da capacidade

A redução automática da capacidade define a capacidade de cada grupo de instâncias ou NEG candidato a redução como zero, desde que a proporção de grupos de instâncias ou NEGs candidatos a redução em comparação com todos os grupos de instâncias ou NEGs seja inferior a 50%. Ao calcular a proporção de 50%, os back-ends com capacidade zero não são incluídos no numerador. No entanto, todos os backends estão incluídos no denominador.

Um back-end candidato drenável é um grupo de instâncias ou um NEG de back-end que tem menos de 25% das respetivas instâncias ou pontos finais membros a passar nas verificações de estado do balanceador de carga.

Os back-ends com capacidade zero são os seguintes:

• Grupos de instâncias de back-end sem instâncias de membros, em que a capacidade do grupo de instâncias é definida por instância
• NEGs de back-end sem pontos finais de membros, em que a capacidade do NEG é definida por ponto final
• Grupos de instâncias ou NEGs de back-end cujos escaladores de capacidade definiu como zero

A capacidade do back-end esgotada automaticamente é funcionalmente equivalente a definir manualmente o valor backendService.backends[].capacityScaler de um back-end como 0, mas sem definir o valor do escalador de capacidade.

Auto-capacity undraining

A reposição automática da capacidade devolve a capacidade de um back-end ao valor controlado pelo escalador de capacidade do back-end quando 35% ou mais das instâncias ou dos pontos finais do back-end passam nas verificações de estado durante, pelo menos, 60 segundos. O requisito de 60 segundos reduz as hipóteses de esgotamento e não esgotamento sequenciais quando as verificações de funcionamento falham e são aprovadas em rápida sucessão.

Limite de comutação por falha

O balanceador de carga determina a distribuição do tráfego entre os back-ends de forma multinível. No estado estável, envia tráfego para os back-ends que são selecionados com base num dos algoritmos de equilíbrio de carga descritos anteriormente. Estes backends, denominados backends principais, são considerados ideais em termos de latência e capacidade.

O equilibrador de carga também monitoriza outros back-ends que podem ser usados se os back-ends principais ficarem em mau estado e não conseguirem processar o tráfego. Estes backends são denominados backends de alternativa. Normalmente, estes backends são backends próximos com capacidade restante.

Se as instâncias ou os pontos finais no back-end principal ficarem em mau estado, o equilibrador de carga não transfere imediatamente o tráfego para outros back-ends. Em alternativa, o balanceador de carga muda primeiro o tráfego para outras instâncias ou pontos finais em bom estado no mesmo back-end para ajudar a estabilizar a carga de tráfego. Se demasiados pontos finais num back-end principal estiverem em mau estado e os pontos finais restantes no mesmo back-end não conseguirem processar o tráfego adicional, o equilibrador de carga usa o limite de failover para determinar quando começar a enviar tráfego para um back-end de failover. O balanceador de carga tolera o estado não saudável no back-end principal até ao limite de comutação por falha. Após isso, o tráfego é desviado do back-end principal.

O limiar de comutação por falha é um valor entre 1 e 99, expresso como uma percentagem de pontos finais num back-end que têm de estar em bom estado. Se a percentagem de pontos finais em bom estado ficar abaixo do limite de comutação por falha, o balanceador de carga tenta enviar tráfego para um back-end de comutação por falha. Por predefinição, o limite de comutação por falha é 70.

Se o limite de ativação pós-falha estiver definido demasiado alto, podem ocorrer derrames de tráfego desnecessários devido a alterações de estado transitórias. Se o limite de comutação por falha estiver definido como demasiado baixo, o balanceador de carga continua a enviar tráfego para os back-ends principais, mesmo que existam muitos pontos finais não íntegros.

As decisões de alternativa são localizadas. Cada front-end da Google (GFE) local comporta-se de forma independente dos outros. É da sua responsabilidade garantir que os backends de failover conseguem processar o tráfego adicional.

O tráfego de ativação pós-falha pode resultar em back-ends sobrecarregados. Mesmo que um back-end esteja em mau estado, o balanceador de carga pode continuar a enviar tráfego para aí. Para excluir back-ends não íntegros do conjunto de back-ends disponíveis, ative a funcionalidade de redução automática da capacidade.

Isolamento de tráfego

Pré-visualização

Este produto ou funcionalidade está sujeito aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. Os produtos e as funcionalidades pré-GA estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Por predefinição, o Cloud Load Balancing usa o algoritmo WATERFALL_BY_REGION para decidir para onde o tráfego de utilizadores deve ser encaminhado. Com o WATERFALL_BY_REGION, o tráfego transborda para outras regiões quando os back-ends na região mais próxima do utilizador estão cheios ou não estão em bom estado. A ativação do isolamento de tráfego permite que o balanceador de carga encaminhe o tráfego apenas para a região mais próxima do utilizador, mesmo que todos os back-ends nessa região estejam a ser executados no respetivo limite de capacidade configurado. A ativação do isolamento de tráfego pode ajudar a evitar falhas regionais em cascata e limitar potenciais interrupções a uma única região.

O isolamento do tráfego é configurado como parte da política de balanceamento de carga do serviço. Existem dois modos de isolamento disponíveis:

• NEAREST (predefinição), em que o balanceador de carga (ou seja, o GFE de segunda camada ou o proxy Envoy que processa a ligação) envia tráfego para back-ends na região mais próxima do utilizador. Se não existirem back-ends configurados na região mais próxima ou se os back-ends na região mais próxima não estiverem em bom estado, o tráfego é encaminhado para a região mais próxima seguinte, enquanto se otimiza a latência da rede. Este processo continua à medida que cada região fica sem capacidade de publicação.

• STRICT, em que o balanceador de carga (ou seja, o proxy Envoy que processa a ligação) envia tráfego apenas para os back-ends na região mais próxima do utilizador. Se não existirem back-ends configurados na região mais próxima ou se os back-ends na região mais próxima não estiverem em bom estado e não puderem publicar pedidos, o tráfego é rejeitado e os pedidos começam a falhar.

Sem isolamento

O diagrama seguinte mostra o comportamento dos balanceadores de carga entre regiões quando o isolamento do tráfego não está ativado.

Como o Cloud Load Balancing se comporta quando o isolamento de tráfego não está ativado.

Mais perto

O diagrama seguinte mostra o comportamento dos balanceadores de carga entre regiões quando o isolamento do tráfego está ativado com o modo NEAREST.

Como o Cloud Load Balancing se comporta quando o isolamento de tráfego está ativado no modo NEAREST.

Rigoroso

O diagrama seguinte mostra o comportamento dos balanceadores de carga entre regiões quando o isolamento do tráfego está ativado com o modo STRICT.

Como o Cloud Load Balancing se comporta quando o isolamento do tráfego está ativado no modo STRICT.

Tenha em atenção as seguintes considerações antes de ativar esta funcionalidade:

• Se os seus back-ends numa região estiverem sobrecarregados, o balanceador de carga pode continuar a enviar-lhes tráfego adicional, mesmo que os back-ends noutras regiões consigam processar o tráfego. Isto significa que é mais provável que os backends em cada região individual fiquem sobrecarregados devido ao tráfego adicional, pelo que tem de planear em conformidade.

• Mesmo com o isolamento ativado, o seu tráfego continua a ser encaminhado por um plano de controlo global. Isto significa que ainda existe a possibilidade de falhas globais em várias regiões. Para um melhor isolamento ao nível da infraestrutura, escolha um balanceador de carga regional.

Quando configura o modo de isolamento de tráfego, também tem de definir a granularidade do isolamento como REGION, o que impede o excesso de tráfego entre regiões. Se a granularidade não for configurada, o isolamento de tráfego não é aplicado. Para ver detalhes sobre como ativar o isolamento de tráfego, consulte o artigo Configure uma política de balanceamento de carga de serviço.

Back-ends preferenciais

Os backends preferenciais são backends cuja capacidade quer usar completamente antes de encaminhar o tráfego para outros backends. Todo o tráfego acima da capacidade configurada dos back-ends preferenciais é encaminhado para os back-ends não preferenciais restantes. Em seguida, o algoritmo de balanceamento de carga distribui o tráfego entre os back-ends não preferenciais de um serviço de back-end.

Pode configurar o equilibrador de carga para preferir e usar completamente um ou mais back-ends associados a um serviço de back-end antes de encaminhar pedidos subsequentes para os back-ends restantes.

Considere as seguintes limitações quando usa backends preferenciais:

• Os back-ends configurados como back-ends preferenciais podem estar mais distantes dos clientes e resultar numa latência média mais elevada para os pedidos de clientes. Isto acontece mesmo que existam outros backends mais próximos que pudessem ter publicado os clientes com uma latência inferior.
• Determinados 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 preferenciais.

Para saber como definir backends preferenciais, consulte o artigo Defina backends preferenciais.

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

Nota: esta secção pressupõe um nível de familiaridade intermédio a avançado com o Cloud Load Balancing. Os passos não explicam a criação de um serviço de back-end nem qualquer outra configuração básica do equilibrador de carga. Para configurar primeiro a configuração básica, consulte a documentação do equilibrador de carga respetiva.

O recurso de política de equilíbrio de carga do serviço permite-lhe configurar os seguintes campos:

• Algoritmo de balanceamento de carga
• Consumo automático da capacidade
• Limite de comutação por falha
• Isolamento de tráfego

Para definir um back-end preferencial, consulte o artigo Defina back-ends preferenciais.

Criar uma política

Siga os passos seguintes para criar e configurar uma política de balanceamento de carga de serviço.

Consola

Nota: não é possível configurar o isolamento de tráfego através da Google Cloud consola. Em alternativa, use a CLI gcloud ou a API.

Execute os passos seguintes para criar uma política de equilíbrio de carga de serviço.

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. Clique em Criar política de equilíbrio de carga do serviço.

3. Introduza um nome para a política de balanceamento de carga do serviço.

4. Para ativar a redução automática da capacidade, selecione Reduzir o tráfego dos back-ends não saudáveis.

5. Para Limite de estado de funcionamento de alternativa, introduza um número entre 1 e 99.

6. Para a Distribuição de tráfego, selecione o algoritmo de equilíbrio de carga que quer usar.

7. Clique em Criar.

gcloud

1. Crie um recurso de política de balanceamento de carga de serviço. Pode fazê-lo através de um ficheiro YAML ou diretamente, através de parâmetros gcloud.

   • Com um ficheiro YAML. Especifica as políticas de balanceamento de carga do serviço num ficheiro YAML. Segue-se um ficheiro YAML de exemplo que mostra como configurar um algoritmo de equilíbrio de carga, ativar a drenagem automática da capacidade e definir um limite de comutação por falha personalizado:

   name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
   autoCapacityDrain:
       enable: True
   failoverConfig:
       failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
   loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
   isolationConfig:
     isolationGranularity: ISOLATION_GRANULARITY
     isolationMode: ISOLATION_MODE
   

   Substitua o seguinte:

   • PROJECT_ID: o ID do projeto.
   • SERVICE_LB_POLICY_NAME: o nome da política de balanceamento de carga do serviço.
   • FAILOVER_THRESHOLD_VALUE: o valor do limite de alternativa. Este valor deve ser um número entre 1 e 99.
   • LOAD_BALANCING_ALGORITHM: o algoritmo de balanceamento de carga a usar. Pode ser SPRAY_TO_REGION, WATERFALL_BY_REGION ou WATERFALL_BY_ZONE.
   • ISOLATION_GRANULARITY: o nível de detalhe da restrição de isolamento. Para evitar o excesso de tráfego entre regiões, defina esta opção como REGION. Se não for especificado, não é aplicada nenhuma isolação.
   • ISOLATION_MODE: o comportamento de isolamento. Os valores possíveis são NEAREST ou STRICT.

   Depois de criar o ficheiro YAML, importe-o para uma nova política de equilíbrio de carga.

   gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
      --source=PATH_TO_POLICY_FILE \
      --location=global
   

   • Sem um ficheiro YAML. Em alternativa, pode configurar as funcionalidades da política de equilíbrio de carga do serviço sem usar um ficheiro YAML.

   Para definir o algoritmo de equilíbrio de carga e ativar a drenagem automática, use o seguinte comando:

   gcloud 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 o seguinte:

   • 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 usar. Pode ser SPRAY_TO_REGION, WATERFALL_BY_REGION ou WATERFALL_BY_ZONE.
   • FAILOVER_THRESHOLD_VALUE: o valor do limite de comutação por falha. Este valor deve ser um número entre 1 e 99.

   Para configurar o isolamento do tráfego (Pré-visualização), use o seguinte comando:

   gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
      --isolation-config-granularity=ISOLATION_GRANULARITY \
      --isolation-config-mode=ISOLATION_MODE \
      --location=global
   

   Substitua o seguinte:

   • ISOLATION_GRANULARITY: o nível de detalhe da restrição de isolamento. Para evitar o excesso de tráfego entre regiões, defina esta opção como REGION. Se não for especificado, não é aplicada nenhuma isolação.
   • ISOLATION_MODE: o comportamento de isolamento. Os valores possíveis são NEAREST ou STRICT.

2. Atualize um serviço de back-end para que o respetivo campo --service-lb-policy faça referência ao recurso de política de balanceamento de carga do serviço recém-criado. Só é possível associar um serviço de back-end a um recurso de política de balanceamento de carga de serviço.

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

   Também pode associar uma política de balanceamento de carga de serviço a um serviço de back-end ao criar o serviço de back-end.

   gcloud 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
   

Desative as funcionalidades configuradas na política

Esta secção mostra-lhe como repor ou desativar funcionalidades configuradas na política de equilíbrio de carga do serviço.

Reponha o algoritmo de balanceamento de carga

Para repor o algoritmo de equilíbrio de carga, use o seguinte comando para definir o algoritmo de equilíbrio de carga novamente para o valor predefinido WATERFALL_BY_REGION:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --load-balancing-algorithm=WATERFALL_BY_REGION \
    --location=global

Reponha o limite de comutação por falha

Para repor o limite de comutação por falha, use o seguinte comando para definir o limite de comutação por falha novamente para os 70 segundos predefinidos:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --failover-health-threshold=70 \
    --location=global

Desative a redução automática da capacidade

Para desativar o esgotamento automático da capacidade, use o seguinte comando:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --no-auto-capacity-drain \
    --location=global

Desative o isolamento do tráfego

Para desativar o isolamento de tráfego (pré-visualização), defina ambos os parâmetros de configuração de isolamento como UNSPECIFIED, conforme mostrado no comando seguinte:

gcloud beta network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --isolation-config-granularity=UNSPECIFIED \
    --isolation-config-mode=UNSPECIFIED \
    --location=global

Remova uma política

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

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

Defina backends preferenciais

Pode configurar back-ends preferenciais através da CLI do Google Cloud ou da API.

Consola

Pode designar um back-end como back-end preferencial enquanto cria um balanceador de carga global ou entre regiões na Google Cloud consola.

Defina o campo Nível de preferência de back-end como Preferido quando adicionar o back-end ao serviço de back-end.

gcloud

Adicione um motor de processamento preferencial

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

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

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

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

Atualize a preferência de um back-end

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

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

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

gcloud 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 preferencial, defina a flag preference em cada back-end através do recurso globalbackendServices.

Segue-se 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 o seguinte:

• PROJECT_ID: o ID do projeto
• BACKEND_SERVICE_NAME: o nome do serviço de back-end
• BACKEND_1_NAME: o nome do motor preferido
• BACKEND_2_NAME: o nome do back-end predefinido

Resolução de problemas

Os padrões de distribuição de tráfego podem mudar quando 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 ver como o tráfego flui entre o balanceador de carga e o back-end. Os registos e as métricas do Cloud Load Balancing também podem ajudar a compreender o comportamento do balanceamento de carga.

Esta secção resume alguns cenários comuns que pode encontrar quando ativa cada uma destas funcionalidades.

Algoritmos de balanceamento de carga

O tráfego de uma única origem é enviado para demasiados backends distintos

Este é o comportamento pretendido do algoritmo SPRAY_TO_REGION. No entanto, pode ter problemas causados por uma distribuição mais ampla do seu tráfego. Por exemplo, as taxas de acertos da cache podem diminuir porque os back-ends veem tráfego de uma seleção mais ampla de clientes. Neste caso, considere usar outros algoritmos, como WATERFALL_BY_REGION.

Consumo automático da capacidade

O tráfego não está a ser enviado para back-ends com muitos pontos finais não íntegros

Este é o comportamento pretendido quando autoCapacityDrain está ativado. Os back-ends com muitos pontos finais em mau estado de funcionamento são esgotados e removidos do conjunto de equilíbrio de carga. Se não quiser este comportamento, pode desativar a redução automática da capacidade. No entanto, isto significa que o tráfego pode ser enviado para back-ends com muitos pontos finais não íntegros e os pedidos podem falhar.

Limite de comutação por falha

O tráfego está a ser enviado para um back-end remoto durante alterações de estado temporárias

Este é o comportamento pretendido quando o limite de comutação por falha está definido para um valor elevado. Se quiser que o tráfego continue a ser encaminhado para os back-ends principais quando existirem alterações de estado de funcionamento transitórias, defina este campo para um valor inferior.

Os pontos finais em bom estado estão sobrecarregados quando outros pontos finais estão em mau estado

Este é o comportamento pretendido quando o limite de comutação por falha está definido para um valor baixo. Quando os pontos finais não estão em bom estado, o tráfego destinado a estes pontos finais não em bom estado é, em alternativa, distribuído pelos restantes pontos finais no mesmo back-end. Se quiser que o comportamento de alternativa seja acionado mais cedo, defina este campo com um valor mais elevado.

Back-ends preferenciais

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

Este é o comportamento pretendido se os seus back-ends preferenciais estiverem mais distantes do que os back-ends predefinidos. Se não quiser este comportamento, atualize as definições de preferências de cada back-end em conformidade.

O tráfego não está a ser enviado para alguns backends quando usa backends preferenciais

Este é o comportamento pretendido quando os back-ends preferenciais ainda não atingiram a capacidade máxima. Os backends preferenciais são atribuídos primeiro com base na latência do tempo de ida e volta para estes backends.

Se quiser enviar tráfego para outros backends, pode fazer uma das seguintes ações:

• Atualize as definições de preferências para os outros back-ends.
• Defina uma capacidade alvo inferior para os seus backends preferidos. A capacidade alvo é configurada através dos campos max-rate ou max-utilization, consoante o modo de equilíbrio do serviço de back-end.

Isolamento de tráfego

Os pedidos enviados para o seu equilibrador de carga interno entre regiões estão a falhar

Se o modo de isolamento STRICT estiver ativado e não existirem back-ends configurados na mesma região que o equilibrador de carga, espera-se que o tráfego falhe. Se este não for o comportamento pretendido, certifique-se de que tem back-ends na região onde espera que o tráfego seja enviado. Em alternativa, defina o modo de isolamento como NEAREST para que o tráfego possa ser encaminhado para a região mais próxima seguinte.

O tráfego é encaminhado de uma região remota para uma região mais próxima

O isolamento de pedidos impede o excesso de tráfego baseado na capacidade. Assim, se os seus back-ends já estivessem sobrecarregados antes de ativar esta funcionalidade, o tráfego pode já ter sido enviado para uma região remota. Nesse caso, a ativação desta funcionalidade pode fazer com que este tráfego seja encaminhado novamente para a região mais próxima.

O tráfego não foi reencaminhado após ativar o isolamento de tráfego

O isolamento de pedidos impede o excesso de tráfego baseado na capacidade. Assim, se os seus back-ends na região mais próxima não estavam sobrecarregados antes de ativar esta funcionalidade, é provável que a região mais próxima seja capaz de processar todo o tráfego. Nesse caso, é esperado que não veja alterações às rotas de trânsito a curto prazo. Isto pode mudar à medida que o volume de tráfego muda.

O tráfego move-se quando são adicionados ou removidos back-ends de uma região

Este é o comportamento esperado, uma vez que os balanceadores de carga tentam encaminhar o tráfego para otimizar a latência geral da rede. Por conseguinte, quando são implementados novos back-ends numa região mais próxima, o balanceador de carga pode enviar mais tráfego para essa região. Da mesma forma, quando os back-ends são removidos, consoante a definição de isolamento do pedido, o balanceador de carga começa a enviar tráfego de overflow para uma região mais distante.

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.