Otimizações avançadas de balanceamento de carga

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

O Cloud Service Mesh também oferece suporte a otimizações avançadas de balanceamento de carga. Para consulte Balanceamento de carga avançado informações gerais no documentação do Cloud Service Mesh.

O Cloud Load Balancing oferece os seguintes recursos avançados:

  • 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. Com uma política de balanceamento de carga de serviço, é possível personalizar os seguintes parâmetros para influenciar 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 balanceamento de carga usado para determinar como o tráfego é distribuído em uma determinada região ou zona.
    • Diminuir a capacidade automaticamente. 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.
    • Limite de failover. 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.
    • Isolamento de tráfego. Evite falhas em cascata limitando ou proibindo o excesso de tráfego entre regiões.

  • Back-ends preferenciais. É possível designar back-ends específicos como back-ends preferencial. Esses back-ends precisam ser usados de acordo com a capacidade antes que as solicitações sejam enviadas aos back-ends restantes.

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

Balanceadores de carga e back-ends compatíveis

Os balanceadores de carga a seguir oferecem suporte a políticas de balanceamento de carga de serviço e back-ends preferenciais:

  • 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

Os recursos descritos nesta página exigem back-ends compatíveis com um modo de balanceamento. Os back-ends compatíveis estão resumidos na tabela a seguir:

Back-end Compatível?
Grupos de instâncias
Os grupos de instâncias não gerenciadas e gerenciadas por zona são compatíveis, mas os grupos de instâncias gerenciadas por região não são.
NEGs zonais (endpoints GCE_VM_IP_PORT)
NEGs zonais (endpoints GCE_VM_IP)
Esses tipos de NEGs não são compatíveis com os balanceadores de carga de aplicativo e de rede de proxy.
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) na região mais próxima ao usuário 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.

Se todos os back-ends na região mais próxima estiverem sendo executados no limite de capacidade configurado, o tráfego vai começar a transbordar para a próxima região mais próxima, otimizando a latência da rede.

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.

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

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 e aumento automáticos de capacidade

A diminuição e o aumento da capacidade automática combinam os conceitos de verificações de integridade e capacidade de back-end. Com a diminuição da capacidade automática, as verificações de integridade são usadas como um indicador adicional para definir a capacidade de back-end eficaz como zero. Com o esgotamento de capacidade automática, as verificações de integridade são usadas como um indicador adicional para restaurar a capacidade de back-end eficaz ao valor anterior.

Sem o esgotamento e a retirada automática da capacidade, se você quiser direcionar as solicitações para longe de todos os back-ends em uma região específica, defina manualmente a capacidade efetiva de cada back-end nessa região como zero. Por exemplo, você pode usar o escalonador de capacidade para fazer isso.

Com o esgotamento e a retirada automática da capacidade, as verificações de integridade podem ser usadas como um sinal para ajustar a capacidade de um back-end, esgotando ou retirando.

Para ativar a diminuição e a restauração automáticas da capacidade, consulte Configurar uma política de balanceamento de carga de serviço.

Diminuição de capacidade automática

O esvaziamento automático de capacidade define a capacidade de cada grupo de instâncias ou NEG de back-end candidato a esvaziamento para zero, desde que a proporção de grupos de instâncias de back-end ou NEGs de candidato a esvaziamento em comparação com todos os grupos de instâncias de back-end 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 back-ends são incluídos no denominador.

Um back-end candidato de esvaziamento é um grupo de instâncias de back-end ou NEG que tem menos de 25% das instâncias ou endpoints de membros passando nas verificações de integridade 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 membro, em que a capacidade do grupo de instâncias é definida por instância.
  • NEGs de back-end sem endpoints de membro, em que a capacidade do NEG é definida por endpoint
  • Grupos de instâncias de back-end ou NEGs com escalonadores de capacidade definidos como zero

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

Diminuição automática de capacidade

A diminuição automática da capacidade retorna a capacidade de um back-end para o valor controlado pelo escalonador de capacidade do back-end quando 35% ou mais das instâncias ou dos endpoints do back-end passam nas verificações de integridade por pelo menos 60 segundos. O requisito de 60 segundos reduz as chances de esgotamento e esgotamento sequencial quando as verificações de integridade falham e são bem-sucedidas em sucessão rápida.

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.

Isolamento de tráfego

Por padrão, o Cloud Load Balancing usa o algoritmo WATERFALL_BY_REGION para decidir para onde o tráfego do usuário deve ser roteado. Com WATERFALL_BY_REGION, o tráfego estoura para outras regiões quando os back-ends na região mais próxima do usuário estão cheios ou inativos. Ativar o isolamento de tráfego permite que o balanceador de carga roteie o tráfego somente para a região mais próxima do usuário, mesmo que todos os back-ends nessa região estejam executando o limite de capacidade configurado. Ativar o isolamento de tráfego pode ajudar a evitar falhas regionais em cascata e limitar possíveis interrupções em uma única região.

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

  • NEAREST (padrão), em que o balanceador de carga (ou seja, o GFE de segunda camada ou o proxy Envoy que processa a conexão) envia tráfego para back-ends na região mais próxima do usuário. Se não houver back-ends configurados na região mais próxima ou se os back-ends na região mais próxima não estiverem íntegros, o tráfego será roteado para a próxima região mais próxima, otimizando a latência da rede. Isso continua conforme cada região fica sem capacidade de veiculação.

    O modo de isolamento NEAREST está disponível para todos os balanceadores de carga com suporte.

  • STRICT, em que o balanceador de carga (ou seja, o proxy Envoy que processa a conexão) envia tráfego apenas para back-ends na região mais próxima do usuário. Se não houver back-ends configurados na região mais próxima ou se os back-ends na região mais próxima não estiverem íntegros e não puderem atender às solicitações, o tráfego será interrompido e as solicitações começarão a falhar.

    O modo de isolamento STRICT está disponível apenas para balanceadores de carga de aplicativo internos entre regiões e balanceadores de carga de rede de proxy internos entre regiões.

Sem isolamento

O diagrama a seguir mostra como os balanceadores de carga entre regiões se comportam quando o isolamento de tráfego não está ativado.

Como o Cloud Load Balancing se comporta quando o isolamento de 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 a seguir mostra como os balanceadores de carga entre regiões se comportam quando o isolamento de tráfego é ativado com o modo NEAREST.

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

Estrito

O diagrama a seguir mostra como os balanceadores de carga entre regiões se comportam quando o isolamento de tráfego é ativado com o modo STRICT.

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

Considere as seguintes considerações antes de ativar esse recurso:

  • Se os back-ends de uma região estiverem sobrecarregados, o balanceador de carga ainda poderá enviar tráfego adicional para eles, mesmo que os back-ends de outras regiões consigam processar o tráfego. Isso significa que os back-ends em cada região têm mais probabilidade de sobrecarregar devido ao tráfego adicional, e você precisa se planejar de acordo.

  • Mesmo com o isolamento ativado, seu tráfego ainda é roteado por um plano de controle global. Isso significa que ainda há uma chance de falhas globais em várias regiões. Para um melhor isolamento no nível da infraestrutura, escolha um balanceador de carga regional.

Ao configurar o modo de isolamento de tráfego, também é necessário definir a granularidade de isolamento como REGION, o que impede o transbordamento de tráfego entre regiões. Se a granularidade não for configurada, o isolamento de tráfego não será aplicado. Para saber como ativar o isolamento de tráfego, consulte Configurar uma política de balanceamento de carga de serviço.

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
  • Isolamento de tráfego

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

Criar uma política

Siga as etapas abaixo para criar e configurar uma política de balanceamento de carga de serviço.

Console

Siga as etapas abaixo para criar uma política de balanceamento de carga de serviço.

  1. No console Google Cloud , acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique em Criar política de balanceamento de carga de serviço.

  3. Insira um Nome para a política de balanceamento de carga do serviço.

  4. Para ativar a drenagem de capacidade automática, selecione Drene o tráfego de back-ends não íntegros.

  5. Para Limite de integridade para failover, insira um número entre 1 e 99.

  6. Em Distribuição de tráfego, selecione o algoritmo de balanceamento de carga que você quer usar.

  7. Clique em Criar.

gcloud

  1. 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. Confira 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
failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
isolationConfig:
  isolationGranularity: ISOLATION_GRANULARITY
  isolationMode: ISOLATION_MODE

    Substitua:

    • 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 failover. Deve ser um número entre 1 e 99.
    • LOAD_BALANCING_ALGORITHM: o algoritmo de balanceamento de carga a ser usado. Pode ser SPRAY_TO_REGION, WATERFALL_BY_REGION ou WATERFALL_BY_ZONE.
    • ISOLATION_GRANULARITY: a granularidade da restrição de isolamento. Para evitar o excesso de tráfego entre regiões, defina essa opção como REGION. Se não for especificado, nenhum isolamento será aplicado.
    • ISOLATION_MODE: o comportamento de isolamento. Os valores possíveis são NEAREST ou STRICT.

    Depois de criar o arquivo YAML, importe-o para uma nova política de balanceamento de carga de serviço.

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

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

    Para configurar o isolamento de tráfego (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:

    • ISOLATION_GRANULARITY: a granularidade da restrição de isolamento. Para evitar o excesso de tráfego entre regiões, defina essa opção como REGION. Se não for especificado, nenhum isolamento será aplicado.
    • 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 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 compute backend-services update BACKEND_SERVICE_NAME \
 --service-lb-policy=SERVICE_LB_POLICY_NAME \
 --global

    Também é 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 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

Desativar os recursos configurados na política

Esta seção mostra como redefinir ou desativar recursos configurados na política de balanceamento de carga do serviço.

Redefinir o algoritmo de balanceamento de carga

Para redefinir o algoritmo de balanceamento de carga, use o comando a seguir para definir o algoritmo de balanceamento de carga de volta para o WATERFALL_BY_REGION padrão:

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

Redefinir o limite de failover

Para redefinir o limite de failover, use o comando a seguir para definir o limite de failover de volta para o padrão de 70 segundos:

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

Desativar a diminuição automática de capacidade

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

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

Desativar o isolamento de tráfego

Para desativar o isolamento de tráfego (pré-lançamento), defina os dois parâmetros de configuração de isolamento como UNSPECIFIED, conforme mostrado no comando a seguir:

gcloud beta network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --isolation-config-granularity=UNSPECIFIED \
    --isolation-config-mode=UNSPECIFIED \
    --location=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 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.

Console

É possível designar um back-end como preferencial ao criar um balanceador de carga global ou entre regiões no console Google Cloud .

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

gcloud

Adicionar um back-end preferido

Para definir um back-end preferido, use o comando gcloud compute backend-services add-backend para definir a sinalização --preference ao 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 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 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 compute backend-services update-backend.

gcloud 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 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 aparecer quando você ativa cada um desses recursos.

Algoritmos de balanceamento de carga

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.

Diminuição de capacidade automática

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.

Limite de failover

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.

Back-ends preferenciais

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.

Isolamento de tráfego

As solicitações enviadas para o balanceador de carga interno entre regiões estão falhando

Se o modo de isolamento STRICT estiver ativado e não houver back-ends configurados na mesma região que o balanceador de carga, o tráfego vai falhar. Se esse não for o comportamento desejado, verifique se você tem back-ends na região em que espera que o tráfego seja enviado. Ou defina o modo de isolamento como NEAREST para que o tráfego possa ser roteado para a próxima região mais próxima.

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

O isolamento de solicitações evita o excesso de tráfego com base na capacidade. Portanto, se os back-ends já estavam sobrecarregados antes de ativar esse recurso, o tráfego pode ter sido enviado para uma região remota. Nesse caso, ativar esse recurso pode fazer com que esse tráfego seja encaminhado de volta para a região mais próxima.

O tráfego não foi redirecionado depois de ativar o isolamento de tráfego

O isolamento de solicitações evita o excesso de tráfego com base na capacidade. Portanto, se os back-ends na região mais próxima não estiverem sobrecarregados antes de ativar esse recurso, é provável que a região mais próxima seja capaz de processar todo o tráfego. Nesse caso, não haverá mudanças nas rotas de tráfego no curto prazo. Isso pode mudar conforme o volume de tráfego muda.

O tráfego é movido quando os back-ends são adicionados ou removidos de uma região

Esse é o comportamento esperado, porque os balanceadores de carga tentam encaminhar o tráfego para otimizar a latência geral da rede. Portanto, quando novos back-ends são implantados em uma 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, dependendo da configuração de isolamento de solicitações, 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.