Visão geral do balanceamento de carga avançado

O balanceamento de carga avançado consiste em recursos que permitem ajustar a carga global de tráfego e a distribuição de tráfego para atender melhor às suas necessidades de e metas de economia. Este documento é destinado a usuários que tenham pelo menos conhecimento intermediário dos conceitos do Cloud Service Mesh e de balanceamento de carga.

Para implementar o balanceamento de carga avançado, crie uma política de balanceamento de carga de serviço (recurso serviceLbPolicies), que contém valores que influenciam a seleção de um back-end. Em seguida, anexe a política de balanceamento de carga a um serviço de back-end. A política de balanceamento de carga de serviço especifica o algoritmo usado para determinar como o tráfego é balanceado para os back-ends.

É possível escolher entre as seguintes opções de algoritmo para balanceamento de carga avançado:

  • Hierarquia por região (algoritmo padrão)
  • Distribuição por região
  • Distribuição para o mundo
  • Hierarquia por zona

As seguintes opções adicionais estão disponíveis:

  • Designar back-ends preeridos. O Cloud Service Mesh envia o tráfego para esses MIGs ou NEGs antes de enviar o tráfego para outros back-ends.
  • Configure a diminuição automática da capacidade.
  • Personalize o comportamento de failover.

Antes de configurar qualquer uma das opções de balanceamento de carga avançado, recomendamos que você revise a documentação do recurso de serviço de back-end.

Como o Cloud Service Mesh roteia e faz o balanceamento de carga do tráfego

O diagrama a seguir mostra como a Cloud Service Mesh decide rotear o tráfego.

Como o Cloud Service Mesh toma decisões de balanceamento de carga
Como o Cloud Service Mesh toma decisões de balanceamento de carga (clique para ampliar)

Primeiro, o Cloud Service Mesh escolhe um serviço de back-end com base na solicitação e com base nas regras de roteamento no recurso Route ou no mapa de URL, dependendo da API usada pela implantação.

Depois, o Cloud Service Mesh escolhe um MIG ou NEG de back-end associado serviço de back-end com base no local do cliente, no local, na integridade e a capacidade do MIG ou NEG e as informações na rede de balanceamento política associada ao serviço de back-end.

Por fim, o Cloud Service Mesh escolhe uma instância ou um endpoint dentro do MIG ou NEG. Essa escolha é baseada nas informações da política de balanceamento de carga de região administrativa nos serviços de back-end.

Back-ends compatíveis e incompatíveis

Os seguintes tipos de back-end são compatíveis com o balanceamento de carga avançado:

  • Grupos de instâncias não gerenciadas
  • Grupos de instâncias gerenciadas (MIGs)
  • Grupos de endpoints de redes zonais (GCE_VM_IP_PORT NEGs)
  • Grupos de endpoints de rede de conectividade híbrida (NEG NON_GCP_PRIVATE_IP_PORT)

Os seguintes tipos de back-end não são compatíveis com o balanceamento de carga avançado:

  • Grupos gerenciados de instâncias regionais
  • Grupos de endpoints de rede de Internet (NEGs INTERNET_FQDN_PORT)

Casos de uso

As seções a seguir descrevem como cada algoritmo funciona e qual escolher para suas necessidades comerciais específicas.

Equilibrar o tráfego entre back-ends em uma região

O algoritmo de balanceamento de carga padrão, hierarquia por região, distribui o tráfego de maneira uniforme entre todos os MIGs ou NEGs em zonas de uma região. Recomendamos que você use o algoritmo padrão, a menos que tenha requisitos especiais.

Com a hierarquia por região, os back-ends recebem tráfego em proporção à capacidade, o que fornece proteção contra sobrecarga do back-end. Quando necessário, o tráfego é enviado para além dos limites da zona para que os back-ends sejam carregados de modo uniforme dentro da região. Mesmo que a zona local para o cliente tenha capacidade restante, há tráfego entre zonas. As solicitações de cada cliente podem ser distribuídas por vários MIGs ou NEGs por zona na região, o que ajuda a manter a carga neles uniforme quando a carga de tráfego dos clientes não é uniforme.

Aumentar a resiliência distribuindo o tráfego de um cliente entre as zonas

O algoritmo de hierarquia padrão por região tenta equilibrar o uso de capacidade em vários MIGs ou NEGs zonais. No entanto, nesse algoritmo, as solicitações provenientes de um único cliente não são enviadas de forma consistente a todas as zonas, e as solicitações de um único cliente normalmente são roteadas para MIGs ou NEGs em uma única zona.

Use o algoritmo de distribuição para região quando quiser que os clientes distribuam as solicitações para todos os MIGs ou NEGs em uma região, o que reduz o risco de sobrecarga de MIGs ou NEGs em uma única zona quando há um evento rápido e localizado de aumento no volume de tráfego.

Com o algoritmo de distribuição para região, se você tiver duas zonas, A e B, e houver um pico de tráfego na zona B, o tráfego será dividido entre as duas zonas. Com o algoritmo padrão, um pico na zona B pode acionar uma sobrecarga na zona antes que a Cloud Service Mesh consiga responder à mudança.

Quando você usa o algoritmo de distribuição para a região, o tráfego de cada cliente é sempre distribuído entre as zonas de back-end em uma região. Isso resulta em um tráfego consistentemente maior entre zonas, mesmo quando há capacidade restante na zona local. Isso pode resultar em uma área afetada maior para o tráfego do Cloud Service Mesh, se dois clientes do Cloud Service Mesh estiverem enviando tráfego para as mesmas zonas.

Propagar o tráfego do cliente por todos os back-ends em várias regiões

Conforme discutido nas seções anteriores, o algoritmo de distribuição para a região distribui o tráfego de cada cliente para todas as zonas de uma região. Para serviços que têm MIGs ou NEGs em várias regiões, o Cloud Service Mesh ainda otimiza a latência geral enviando tráfego para a região mais próxima.

Se preferir um raio de propagação maior, use o algoritmo de distribuição para o mundo. Com esse algoritmo, os clientes espalham as solicitações para todos os MIGs ou NEGs no mundo em várias regiões.

É importante observar que, com esse algoritmo, todo o tráfego é distribuído para todos os back-ends globalmente. Uma consulta com erros pode danificar todos os back-ends nas implantações. O algoritmo também resulta em mais tráfego entre regiões, o que pode aumentar a latência da solicitação e gerar custos adicionais.

Minimizar o tráfego entre zonas

É possível otimizar a latência geral e reduzir o tráfego entre zonas usando a configuração de hierarquia por zona. Quando vários MIGs ou NEGs são configurados em uma zona, o tráfego do cliente é roteado para o MIG ou NEG mais próximo na zona, até a capacidade, antes de enviar o tráfego para o próximo MIG ou NEG na zona até que toda a capacidade de MIG ou NEG na zona seja usada. Só então o tráfego será espalhado para a zona mais próxima.

Com esse algoritmo, é possível minimizar o tráfego entre as zonas desnecessário. A latência geral pode ser ligeiramente melhorada, porque os back-ends locais mais próximos são os preferidos. No entanto, isso também pode criar tráfego desigual entre os MIGs ou NEGs em uma região.

Comparação dos algoritmos de balanceamento de carga

A tabela a seguir fornece uma comparação detalhada dos quatro Cloud Service Mesh algoritmos de balanceamento de carga.

Comportamento Hierarquia por região Distribuição por região Distribuição para o mundo Hierarquia por zona
Uso de capacidade uniforme em uma região em estado estável Sim Sim Sim Não
Uso uniforme de capacidade em várias regiões em estado estável Não Não Sim Não
Divisão de tráfego uniforme em uma região em estado estável Não Sim Sim Não
Tráfego entre zonas Sim. Esse algoritmo distribui o tráfego de maneira uniforme entre as zonas de uma região, otimizando a latência da rede. O tráfego pode ser enviado entre zonas, se necessário. Sim Sim Sim, o tráfego encherá a zona mais próxima com a capacidade dela. Depois, ele irá para a próxima zona.
Sensibilidade a picos de tráfego na zona local Média; dependendo da quantidade de tráfego já deslocada para equilibrar as zonas. Menor; porque os picos de uma única zona serão espalhados por todas as zonas da região. Menor; já que os picos de uma única zona serão espalhados por todas as regiões. Maior; já que os picos de zona única têm mais chances de serem atendidos por uma zona até que o Cloud Service Mesh possa reagir.

Outras opções de balanceamento de carga avançado

As seções a seguir discutem as opções para modificar o balanceamento de carga do Cloud Service Mesh.

Back-ends preferenciais

É possível configurar o balanceamento de carga para que um grupo de back-ends de um serviço de back-end designado como preferencial. Esses back-ends são completamente usados antes que as solicitações subsequentes sejam roteadas para os back-ends restantes. O Cloud Service Mesh distribui o tráfego do cliente para os back-ends preferidos primeiro, minimizando as latências de solicitação para os clientes.

Qualquer tráfego que exceda a capacidade configurada dos back-ends preferidos é roteado para os back-ends não preferidos. O algoritmo de balanceamento de carga distribui o tráfego entre os back-ends não preferidos.

Um caso de uso é a sobrecarga do Google Cloud, em que você especifica recursos de computação no local, representados por um NEG de conectividade híbrida, que devem ser totalmente usados antes que as solicitações sejam roteadas para MIGs ou NEGs de back-end do Google Cloud com escalonamento automático. Essa configuração pode minimizar o consumo de computação do Google Cloud e ainda ter a resiliência para vazar ou fazer failover gradualmente para o Google Cloud quando necessário.

Diminuição automática de capacidade

Quando um back-end não está íntegro, geralmente é preferível excluí-lo o mais rápido possível das decisões de balanceamento de carga. A exclusão do back-end impede que solicitações sejam enviadas para o back-end não íntegro. Além disso, o tráfego é equilibrado entre back-ends íntegros para evitar a sobrecarga de back-end e otimizar a latência geral.

Essa opção é semelhante a definir o capacityscaler como zero. Ele solicita que o Cloud Service Mesh reduza a capacidade do back-end para zero automaticamente quando um back-end tem menos de 25% de suas instâncias ou endpoints individuais passar nas verificações de integridade. Com essa opção, os back-ends não íntegros são removidos do balanceador de carga global.

Quando os back-ends diminuídos automaticamente estiverem íntegros novamente, eles serão mantidos se pelo menos 35% dos endpoints ou das instâncias estiverem íntegros por 60 segundos. O Cloud Service Mesh não drena mais de 50% dos endpoints em um serviço de back-end, independentemente do status de integridade do back-end.

Um caso de uso é a diminuição automática da capacidade com back-ends preferidos. Se um MIG ou NEG de back-end for preferido e muitos dos endpoints nele não forem íntegros, essa configuração protegerá os endpoints restantes no MIG ou no NEG deslocando o tráfego do MIG ou NEG.

Personalizar o comportamento de failover

O Cloud Service Mesh normalmente envia tráfego para back-ends considerando vários fatores em conta. Em um estado estável, o Cloud Service Mesh envia tráfego para back-ends que são selecionados com base nos algoritmos discutidos anteriormente. Os back-ends selecionados são considerados ideais em termos de latência e utilização de capacidade. Eles são chamados de back-ends primários.

O Cloud Service Mesh também monitora os back-ends a serem usados quando os back-ends primários não estejam íntegras e não possam receber tráfego. Esses back-ends são chamados de back-ends de failover. Geralmente, eles são back-ends próximos com alguma capacidade restante.

Quando um back-end não está íntegro, o Cloud Service Mesh tenta evitar o envio de tráfego para ele e, em vez disso, o desloca o tráfego para back-ends íntegros.

O recurso serviceLbPolicy inclui um campo, failoverHealthThreshold, cujo valor pode ser personalizado para controlar o comportamento do failover. O valor limite que você define determina quando o tráfego é alternado de back-ends principais para back-ends de failover.

Quando alguns endpoints no back-end principal não estão íntegros, o Cloud Service Mesh não necessariamente deslocam o tráfego imediatamente. Em vez disso, o Cloud Service Mesh pode mudar o tráfego para endpoints íntegros no back-end principal para tentar estabilizar o tráfego.

Se muitos endpoints no back-end não estiverem íntegros, os restantes não poderão processar o tráfego adicional. Nesse caso, o limite de falha é usado para decidir se o failover será acionado ou não. O Cloud Service Mesh tolera a não integridade até o limite e, em seguida, desloca uma parte do tráfego para fora os back-ends primários aos de failover.

O limite de integridade de failover é um valor percentual. O valor que você define determina quando o Cloud Service Mesh direciona o tráfego para os back-ends de failover. É possível definir o valor como um número inteiro entre 1 e 99. O valor padrão da Cloud Service Mesh é 70 com o Envoy e 50 para o gRPC sem proxy. Um valor maior inicia o failover de tráfego antes de um valor menor.

Solução de problemas

Os padrões de distribuição de tráfego podem mudar dependendo de como você configura o novo serviceLbPolicy com o serviço de back-end.

Para depurar problemas de tráfego, use os sistemas de monitoramento atuais para examinar como o tráfego flui para os back-ends. Outras métricas do Cloud Service Mesh e da rede ajudam a entender como as decisões de balanceamento de carga são tomadas. Nesta seção, oferecemos sugestões gerais de solução de problemas e mitigação.

Em geral, o Cloud Service Mesh tenta atribuir tráfego para manter os back-ends em execução abaixo da capacidade configurada. No entanto, isso não é garantido. Consulte a documentação do serviço de back-end para mais detalhes.

Em seguida, o tráfego é atribuído com base no algoritmo usado. Por exemplo, com o algoritmo WATERFALL_BY_ZONE, o Cloud Service Mesh tenta manter o tráfego para a zona mais próxima. Se você verificar as métricas de rede, verá o Cloud Service Mesh prefere um back-end com a menor latência de RTT ao enviar solicitações para otimizar a latência geral do RTT.

Nas seções a seguir, descrevemos os problemas que podem ser encontrados com a política de balanceamento de carga de serviço e as configurações preferenciais de back-end.

O tráfego está sendo enviado para MIGs ou NEGs mais distantes antes daqueles mais próximos

Esse é o comportamento esperado quando os back-ends preferidos são configurados com MIGs ou NEGs mais distantes. Se você não quiser que isso aconteça, altere os valores no campo de back-ends preferidos.

O tráfego não está sendo enviado para MIGs ou NEGs com muitos endpoints não íntegros

Esse é o comportamento esperado quando os MIGs ou NEGs são drenados porque um autoCapacityDrain está configurado. Com essa configuração, os MIGs ou os NEGs com muitos endpoints não íntegros serão removidos das decisões de balanceamento de carga e, portanto, serão evitados. Se esse comportamento for indesejado, desative a configuração autoCapacityDrain. No entanto, isso significa que o tráfego pode ser enviado para MIGs ou NEGs com muitos endpoints não íntegros e, portanto, as solicitações podem falhar com erros.

O tráfego não está sendo enviado para alguns MIGs ou NEGs quando alguns deles têm preferência

Esse será o comportamento esperado se os MIGs ou os NEGs configurados como preferenciais não tiverem atingido a capacidade.

Quando os back-ends preferenciais estão configurados e não atingiram a capacidade limite, o tráfego não será enviado para outros MIGs ou NEGs. Os MIGs ou NEGs preferidos serão atribuídos primeiro com base na latência RTT para esses back-ends.

Se você preferir que o tráfego seja enviado para outro lugar, configure o serviço de back-end sem back-ends preferidos ou com estimativas de capacidade mais conservadoras para os MIGs ou NEGs preferidos.

O tráfego está sendo enviado para muitos MIGs ou NEGs diferentes de uma única origem

Esse é o comportamento esperado quando o pulverizador para a região ou a distribuição para o mundo são usados. No entanto, talvez você tenha problemas com a distribuição mais ampla do tráfego. Por exemplo, as taxas de ocorrência em cache podem ser reduzidas à medida que os back-ends veem o tráfego de uma seleção mais ampla de clientes. Nesse caso, considere usar outros algoritmos, como hierarquia por região.

O tráfego está sendo enviado para um cluster remoto quando a integridade do back-end muda

Quando failoverHealthThreshold é definido como um valor alto, esse é o comportamento esperado. Se você quiser que o tráfego permaneça nos back-ends primários quando houver alterações de integridade temporárias, defina failoverHealthThreshold com um valor mais baixo.

Os endpoints íntegros são sobrecarregados quando alguns não estão íntegros

Quando failoverHealthThreshold é definido como um valor baixo, esse é o comportamento esperado. Quando alguns endpoints não estiverem íntegros, o tráfego deles pode ser distribuído entre os endpoints restantes no mesmo MIG ou NEG. Se você quiser que o comportamento de failover seja acionado antecipadamente, defina failoverHealthThreshold como um valor mais alto.

Limitações e considerações

Veja a seguir as limitações e as considerações que você precisa conhecer ao configurar o balanceamento de carga avançado.

Cascata por zona

  • Durante eventos de manutenção transparente, é possível que o tráfego seja equilibrado temporariamente fora da zona local.

  • São esperados casos em que alguns MIGs ou NEGs estejam no limite da capacidade, enquanto outros MIGs ou NEGs na mesma região sejam subutilizados.

  • Se a origem do tráfego para o serviço estiver na mesma zona que os endpoints, você verá redução no tráfego entre zonas.

  • Uma zona pode ser mapeada para diferentes clusters de hardware físico interno nos data centers do Google. por exemplo, devido à virtualização de zona. Nesse caso, as VMs na mesma zona podem não ser carregadas de maneira uniforme. Em geral, a latência geral será otimizada.

Distribuição para a região

  • Se os endpoints em um MIG ou NEG falharem, as consequências geralmente são distribuídas por um conjunto maior de clientes: Em outras palavras, um número maior de clientes da malha pode ser afetado, mas de forma menos grave.

  • À medida que os clientes enviam solicitações para todos os MIGs ou NEGs na região, em alguns casos, isso pode aumentar a quantidade de tráfego entre zonas.

  • O número de conexões abertas para os endpoints pode aumentar, aumentando o uso de recursos.

Back-ends preferidos

  • Os MIGs ou NEGs configurados como back-ends preferidos podem estar longe dos clientes e podem causar uma latência média maior para eles. Isso pode acontecer mesmo se houver outros MIGs ou NEGs que possam atender aos clientes com menor latência.

  • Os algoritmos de balanceamento de carga global (hierarquia por região, distribuição para região, hierarquia por zona) não se aplicam a MIGs ou NEGs configurados como back-ends preferenciais.

Diminuição automática de capacidade

  • O número mínimo de MIGs que nunca são drenados é diferente do valor definido quando configurado usando serviceLbPolicies.

  • Por padrão, o número mínimo de MIGs que nunca são drenados é 1.

  • Se serviceLbPolicies estiver definido, a porcentagem mínima de MIGs ou NEGs que nunca foram drenados será 50%. Nas duas configurações, um MIG ou NEG será marcado como não íntegro se menos de 25% das instâncias ou endpoints no MIG ou NEG estiverem íntegras.

  • Para que um MIG ou NEG esvazie após uma drenagem, pelo menos 35% ou os endpoints precisam estar íntegros. Isso é necessário para garantir que um MIG ou NEG não erre entre os estados de drenagem e não drenagem.

  • As mesmas restrições do escalonador de capacidade para back-ends que não usam um modo de balanceamento também são aplicáveis aqui.

A seguir