Vista geral do balanceamento de carga avançado

O balanceamento de carga avançado consiste em funcionalidades que lhe permitem otimizar o balanceamento de carga global e a distribuição de tráfego para satisfazer melhor os seus objetivos de disponibilidade, desempenho e rentabilidade. Este documento destina-se a utilizadores que tenham, pelo menos, um conhecimento intermédio do Cloud Service Mesh e dos conceitos de balanceamento de carga.

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

Pode escolher entre as seguintes opções de algoritmo para o equilíbrio de carga avançado:

  • Cascata por região (algoritmo predefinido).
  • Pulverizar para região.
  • Pulverize o mundo.
  • Cascata por zona.

Estão disponíveis as seguintes opções adicionais:

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

Antes de configurar qualquer uma das opções avançadas de equilíbrio de carga, recomendamos que reveja a documentação do recurso de serviço de back-end.

Como o Cloud Service Mesh encaminha e equilibra a carga do tráfego

O diagrama seguinte mostra como a Cloud Service Mesh decide encaminhar o tráfego.

Como o Cloud Service Mesh toma decisões de equilíbrio de carga
Como o Cloud Service Mesh toma decisões de equilíbrio de carga (clique para aumentar)

Primeiro, a malha de serviços na nuvem escolhe um serviço de back-end com base nas caraterísticas do pedido e nas regras de encaminhamento no recurso Route ou no mapa de URLs, consoante a API que a sua implementação usa.

Em segundo lugar, o Cloud Service Mesh escolhe um MIG ou um NEG de back-end associado ao serviço de back-end com base na localização do cliente, na localização, no estado e na capacidade do MIG ou do NEG, e nas informações na política de balanceamento de carga do serviço associada ao serviço de back-end.

Por último, o Cloud Service Mesh escolhe uma instância ou um ponto final no MIG ou no NEG. Esta escolha baseia-se nas informações da política de equilíbrio de carga de localidade nos serviços de back-end.

Back-ends suportados e não suportados

Os seguintes tipos de back-end são suportados para o balanceamento de carga avançado:

  • Grupos de instâncias não geridos
  • Grupos de instâncias geridas (MIGs)
  • Grupos de pontos finais de rede zonais (NEGs GCE_VM_IP_PORT)
  • Grupos de pontos finais de rede de conetividade híbrida (NEG NON_GCP_PRIVATE_IP_PORT)

Os seguintes tipos de back-end não são suportados para o equilíbrio de carga avançado:

  • Grupos de instâncias geridas regionais
  • Grupos de pontos finais de rede da Internet (NEGs INTERNET_FQDN_PORT)

Exemplos de utilização

As secções seguintes descrevem como cada algoritmo funciona e qual deve escolher para as necessidades específicas da sua empresa.

Equilibre o tráfego entre back-ends numa região

O algoritmo de balanceamento de carga predefinido, em cascata por região, distribui o tráfego uniformemente por todos os MIGs ou NEGs em zonas numa região. Recomendamos que use o algoritmo predefinido, a menos que tenha requisitos especiais.

Com a cascata por região, os back-ends recebem tráfego proporcionalmente à respetiva capacidade, o que oferece proteção contra sobrecarga do back-end. O tráfego é enviado através dos limites das zonas quando necessário para manter os back-ends carregados uniformemente na região. Mesmo que a zona local para o cliente tenha capacidade restante, existe tráfego entre zonas. Os pedidos de cada cliente podem ser distribuídos por vários MIGs ou NEGs zonais na região, o que ajuda a manter a carga nos MIGs ou NEGs uniforme quando a carga de tráfego dos clientes não é uniforme.

Aumente a capacidade de recuperação distribuindo o tráfego de um cliente por várias zonas

O algoritmo de hierarquia predefinido por região tenta equilibrar a utilização da capacidade em vários GIGs ou NEGs zonais. No entanto, ao abrigo desse algoritmo, os pedidos originários de um único cliente não são enviados de forma consistente para todas as zonas e os pedidos de um único cliente são normalmente encaminhados para MIGs ou NEGs numa única zona.

Use o algoritmo de dispersão para a região quando quiser que os clientes distribuam os respetivos pedidos por todos os MIGs ou NEGs numa região, o que reduz o risco de sobrecarga dos MIGs ou NEGs numa única zona quando existe um aumento rápido e localizado no volume de tráfego.

Com o algoritmo de dispersão para a região, se tiver duas zonas, A e B, e houver um aumento repentino do tráfego na zona B, o tráfego é dividido entre as duas zonas. Com o algoritmo predefinido, um pico na zona B pode acionar uma sobrecarga na zona antes de o Cloud Service Mesh conseguir responder à alteração.

Tenha em atenção que, quando usa o algoritmo de dispersão para a região, o tráfego de cada cliente é sempre distribuído pelas zonas de back-end numa região. Isto resulta num tráfego entre zonas consistentemente mais elevado, mesmo quando existe capacidade restante na zona local, e pode resultar numa área afetada maior para o tráfego do Cloud Service Mesh, se dois clientes do Cloud Service Mesh estiverem a enviar tráfego para as mesmas zonas.

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

Conforme abordado nas secções anteriores, o algoritmo de pulverização para a região distribui o tráfego de cada cliente para todas as zonas numa região. Para serviços que tenham MIGs ou NEGs em várias regiões, o Cloud Service Mesh continua a otimizar a latência geral enviando tráfego para a região mais próxima.

Se preferir um raio de dispersão maior, use o algoritmo de pulverização para o mundo. Com este algoritmo, os clientes distribuem os respetivos pedidos a todos os MIGs ou NEGs no mundo em várias regiões.

É importante ter em atenção que, com este algoritmo, todo o tráfego é distribuído por todos os servidores de back-end a nível global. Uma consulta com defeito pode danificar todos os backends nas suas implementações. O algoritmo também resulta num maior tráfego entre regiões, o que pode aumentar a latência dos pedidos e criar custos adicionais.

Minimize o tráfego entre zonas

Pode otimizar a latência geral e reduzir o tráfego entre zonas através da definição de hierarquia por zona. Quando são configurados vários MIGs ou NEGs numa zona, o tráfego de clientes é encaminhado para o MIG ou o NEG mais próximo na zona, até à respetiva capacidade, antes de enviar tráfego para o MIG ou o NEG seguinte na zona até que toda a capacidade do MIG ou do NEG na zona seja usada. Só então o tráfego é derramado para a zona mais próxima seguinte.

Com este algoritmo, pode minimizar o tráfego desnecessário entre zonas. A latência geral pode ser ligeiramente melhorada porque os back-ends locais mais próximos são preferidos. No entanto, isto também pode criar um tráfego desigual nos GIGs ou nos NEGs numa região.

Comparação dos algoritmos de balanceamento de carga

A tabela seguinte apresenta uma comparação detalhada dos quatro algoritmos de equilíbrio de carga do Cloud Service Mesh.

Comportamento Cascata por região Pulverizar na região Humidade para o mundo Cascata por zona
Utilização uniforme da capacidade numa região em estado estável Sim Sim Sim Não
Utilização uniforme da capacidade em várias regiões num estado estável Não Não Sim Não
Divisão de tráfego uniforme numa região em estado estável Não Sim Sim Não
Tráfego entre zonas Sim. Este algoritmo distribui o tráfego uniformemente pelas zonas numa região, ao mesmo tempo que otimiza a latência da rede. Se necessário, o tráfego pode ser enviado entre zonas. Sim Sim Sim, o tráfego preenche a zona mais próxima até à sua capacidade. Em seguida, o cursor avança para a zona seguinte.
Sensibilidade a picos de tráfego na zona local Média; consoante o volume de tráfego já transferido para equilibrar entre zonas. Inferior, uma vez que os picos de uma única zona são distribuídos por todas as zonas na região. Inferior, uma vez que os picos de uma única zona são distribuídos por todas as regiões. Mais elevado, uma vez que é mais provável que os picos de zona única sejam publicados inteiramente por uma única zona até que a Cloud Service Mesh consiga reagir.

Opções avançadas adicionais de balanceamento de carga

As secções seguintes abordam as opções para modificar o equilíbrio de carga do Cloud Service Mesh.

Back-ends preferenciais

Pode configurar o equilíbrio de carga para que um grupo de back-ends de um serviço de back-end seja designado como preferencial. Estes back-ends são usados completamente antes de os pedidos subsequentes serem encaminhados para os back-ends restantes. O Cloud Service Mesh distribui o tráfego de clientes primeiro para os back-ends preferenciais, minimizando as latências de pedidos para os seus clientes.

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

Um exemplo de utilização é o overflow para Google Cloud, em que especifica recursos de computação no local, representados por um NEG de conetividade híbrida, a serem totalmente usados antes de os pedidos serem encaminhados para GIGs ou NEGs de back-end com escala automática Google Cloud . Esta configuração pode minimizar o consumo de computação e continuar a ter a capacidade de recuperação para transbordar ou comutação por falha gradual paraGoogle Cloud quando necessário. Google Cloud

Consumo automático da capacidade

Quando um back-end não está em bom estado, é normalmente desejável excluí-lo o mais rapidamente possível das decisões de balanceamento de carga. A exclusão do back-end impede o envio de pedidos para o back-end em mau estado de funcionamento. Além disso, o tráfego é equilibrado entre back-ends em bom estado para evitar a sobrecarga do back-end e otimizar a latência geral.

Esta opção é semelhante a definir o capacityscalar como zero. Pede ao Cloud Service Mesh para reduzir automaticamente a capacidade do back-end para zero quando um back-end tem menos de 25% das respetivas instâncias ou pontos finais individuais a passar nas verificações de estado. Com esta opção, os back-ends não íntegros são removidos do equilíbrio de carga global.

Quando os back-ends com esgotamento automático voltam a estar em bom estado, o esgotamento é anulado se, pelo menos, 35% dos pontos finais ou das instâncias estiverem em bom estado durante 60 segundos. O Cloud Service Mesh não esgota mais de 50% dos pontos finais num serviço de back-end, independentemente do estado de funcionamento do back-end.

Um exemplo de utilização é que pode usar a redução automática da capacidade com back-ends preferenciais. Se for preferível um MIG ou um NEG de back-end e muitos dos respetivos pontos finais não estiverem em bom estado, esta definição protege os pontos finais restantes no MIG ou no NEG desviando o tráfego do MIG ou do NEG.

Personalize o comportamento de comutação por falha

Normalmente, o Cloud Service Mesh envia tráfego para os back-ends tendo em conta vários fatores. Num estado estável, o Cloud Service Mesh envia tráfego para back-ends selecionados com base nos algoritmos abordados anteriormente. Os backends selecionados são considerados ideais em termos de latência e utilização da capacidade. Estes são denominados backends principais.

O Cloud Service Mesh também monitoriza os back-ends a usar quando os back-ends principais não estão em bom estado e não conseguem receber tráfego. Estes back-ends são denominados back-ends de failover. Normalmente, são backends próximos com alguma capacidade restante.

Quando um back-end não está em bom estado, o Cloud Service Mesh tenta evitar o envio de tráfego para o mesmo e, em alternativa, transfere o tráfego para back-ends em bom estado.

O recurso serviceLbPolicy inclui um campo, failoverHealthThreshold, cujo valor pode ser personalizado para controlar o comportamento de comutação por falha. O valor do limite que define determina quando o tráfego é mudado dos back-ends principais para os back-ends de alternativa.

Quando alguns pontos finais no back-end principal não estão em bom estado, o Cloud Service Mesh não altera necessariamente o tráfego imediatamente. Em alternativa, a malha de serviços na nuvem pode mudar o tráfego para pontos finais saudáveis no back-end principal para tentar estabilizar o tráfego.

Se demasiados pontos finais no back-end não estiverem em bom estado, os pontos finais restantes não conseguem processar tráfego adicional. Neste caso, o limite de falhas é usado para decidir se a comutação por falha é acionada ou não. A malha de serviços na nuvem tolera a indisponibilidade até ao limite e, em seguida, transfere uma parte do tráfego dos back-ends principais para os back-ends de alternativa.

O limite de estado de funcionamento da comutação por falha é um valor percentual. O valor que define determina quando o Cloud Service Mesh direciona o tráfego para os back-ends de alternativa. Pode definir o valor como um número inteiro entre 1 e 99. O valor predefinido para o Cloud Service Mesh é 70 com o Envoy e 50 para o gRPC sem proxy. Um valor maior inicia a comutação por falha do tráfego mais cedo do que um valor menor.

Resolução de problemas

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

Para depurar problemas de tráfego, use os sistemas de monitorização existentes para examinar como o tráfego flui para os seus back-ends. As métricas de rede e do Cloud Service Mesh adicionais podem ajudar a compreender como são tomadas as decisões de equilíbrio de carga. Esta secção oferece sugestões gerais de resoluçã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 respetiva capacidade configurada. Tenha em atenção que isto não é garantido. Pode rever a documentação do serviço de back-end para ver mais detalhes.

Em seguida, o tráfego é atribuído com base no algoritmo que usa. Por exemplo, com o algoritmo de WATERFALL_BY_ZONE, o Cloud Service Mesh tenta manter o tráfego na zona mais próxima. Se verificar as métricas de rede, vê que o Cloud Service Mesh prefere um back-end com a latência de RTT mais pequena quando envia pedidos para otimizar a latência de RTT geral.

As secções seguintes descrevem os problemas que pode ver com a política de equilíbrio de carga do serviço e as definições de back-end preferenciais.

O tráfego está a ser enviado para MIGs ou NEGs mais distantes antes de ser enviado para os mais próximos

Este é o comportamento pretendido quando os back-ends preferenciais são configurados com MIGs ou NEGs mais distantes. Se não quiser este comportamento, altere os valores no campo preferred backends.

O tráfego não está a ser enviado para MIGs ou NEGs com muitos pontos finais não íntegros

Este é o comportamento esperado quando os MIGs ou os NEGs são esgotados porque está configurado um autoCapacityDrain. Com esta definição, os MIGs ou os NEGs com muitos pontos finais não íntegros são removidos das decisões de equilíbrio de carga e, por isso, são evitados. Se este comportamento for indesejável, pode desativar a definição autoCapacityDrain. No entanto, tenha em atenção que isto significa que o tráfego pode ser enviado para MIGs ou NEGs com muitos pontos finais não íntegros e, por isso, os pedidos podem falhar com erros.

O tráfego não está a ser enviado para alguns MIGs ou NEGs quando alguns MIGs ou NEGs são preferenciais

Este é o comportamento pretendido se os MIGs ou os NEGs configurados como preferenciais ainda não tiverem atingido a capacidade.

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

Se preferir que o tráfego seja enviado para outro local, pode configurar o respetivo serviço de back-end sem back-ends preferenciais ou com estimativas de capacidade mais conservadoras para os MIGs ou os NEGs preferenciais.

O tráfego está a ser enviado para demasiados MIGs ou NEGs distintos a partir de uma única origem

Este é o comportamento pretendido se for usado o preenchimento por pulverização na região ou no mundo. No entanto, pode ter problemas com uma distribuição mais ampla do seu tráfego. Por exemplo, as taxas de acertos da cache podem ser reduzidas à medida que os back-ends veem tráfego de uma seleção mais ampla de clientes. Neste caso, considere usar outros algoritmos, como o de cascata por região.

O tráfego está a ser enviado para um cluster remoto quando o estado de funcionamento do back-end muda

Quando failoverHealthThreshold está definido como um valor elevado, este é o comportamento pretendido. Se quiser que o tráfego permaneça nos back-ends principais quando existirem alterações de estado de funcionamento transitórias, defina failoverHealthThreshold para um valor inferior.

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

Quando failoverHealthThreshold está definido como um valor baixo, este é o comportamento pretendido. Quando alguns pontos finais não estão em bom estado, o tráfego para estes pontos finais em mau estado pode ser distribuído pelos restantes pontos finais no mesmo MIG ou NEG. Se quiser que o comportamento de comutação por falha seja acionado antecipadamente, defina failoverHealthThreshold com um valor mais elevado.

Limitações e considerações

Seguem-se as limitações e as considerações que deve ter em atenção quando configura o balanceamento de carga avançado.

Hierarquia de publicação por zona

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

  • Espere casos em que alguns MIGs ou NEGs estão no limite da capacidade, enquanto outros MIGs ou NEGs na mesma região estão subutilizados.

  • Se a origem do tráfego para o seu serviço estiver na mesma zona que os respetivos pontos finais, vê uma redução do tráfego entre zonas.

  • Uma zona pode ser mapeada para diferentes clusters de hardware físico interno nos centros de dados da Google; por exemplo, devido à virtualização de zonas. Neste caso, as VMs na mesma zona podem não ser carregadas de forma uniforme. Em geral, a latência geral é otimizada.

Pulverizar para região

  • Se os pontos finais num MIG ou num NEG ficarem inativos, as consequências são normalmente distribuídas por um conjunto maior de clientes. Por outras palavras, um número maior de clientes da malha pode ser afetado, mas de forma menos grave.

  • À medida que os clientes enviam pedidos a todos os MIGs ou NEGs na região, em alguns casos, isto pode aumentar a quantidade de tráfego entre zonas.

  • O número de ligações abertas a pontos finais pode aumentar, o que provoca um aumento da utilização de recursos.

Back-ends preferenciais

  • Os MIGs ou os NEGs configurados como back-ends preferenciais podem estar longe dos clientes e podem causar uma latência média mais elevada para os clientes. Isto pode acontecer mesmo que existam outros MIGs ou NEGs que possam publicar os clientes com uma latência inferior.

  • Os algoritmos de balanceamento de carga global (por região, distribuição para região e por zona) não se aplicam a GIGs nem a GNEs configurados como back-ends preferenciais.

Consumo automático da capacidade

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

  • Por predefinição, o número mínimo de GIGs que nunca são esgotados é 1.

  • Se serviceLbPolicies estiver definido, a percentagem mínima de MIGs ou NEGs que nunca são esgotados é de 50%. Em ambas as configurações, um MIG ou um NEG é marcado como não saudável se menos de 25% das instâncias ou dos pontos finais no MIG ou no NEG estiverem saudáveis.

  • Para que um MIG ou um NEG não seja esvaziado após um esvaziamento, pelo menos 35% das instâncias ou dos pontos finais têm de estar em bom estado. Isto é necessário para garantir que um MIG ou um NEG não oscila entre os estados de drenagem e sem drenagem.

  • As mesmas restrições para o escalador de capacidade para back-ends que não usam um modo de equilíbrio também se aplicam aqui.

O que se segue?