Visão geral do balanceamento de carga avançado

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Para informações sobre o acesso a esta versão, consulte a página de solicitação de acesso.

O Balanceamento de carga avançado consiste em recursos que permitem ajustar o balanceamento de carga global e a distribuição de tráfego para atender melhor às suas metas de disponibilidade, desempenho e eficiência de custo. Este documento é destinado a usuários que têm pelo menos um entendimento intermediário dos conceitos do Traffic Director 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 Traffic Director 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 Traffic Director encaminha e faz o balanceamento de carga do tráfego

O diagrama a seguir mostra como o Traffic Director decide encaminhar o tráfego.

Como o Traffic Director toma decisões sobre o balanceamento de carga (clique para ampliar)

Primeiro, o Traffic Director escolhe um serviço de back-end com base nas características da solicitação e nas regras de roteamento no recurso Route ou no mapa de URLs, dependendo da API usada pela implantação.

Depois, o Traffic Director escolhe um MIG ou NEG de back-end associado ao serviço de back-end, com base no local do cliente, no local, na integridade, na capacidade do MIG ou NEG e nas informações da política associada ao balanceamento de carga do serviço com o serviço de back-end.

Por fim, o Traffic Director escolhe uma instância ou um endpoint no 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 o Traffic Director 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 Traffic Director, se dois clientes do Traffic Director estiverem enviando para as mesmas zonas.

Propagar o tráfego do seu 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 Traffic Director 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 e assim por diante, 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

Na tabela a seguir, mostramos uma comparação detalhada dos quatro algoritmos de balanceamento de carga do Traffic Director.

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ânsito vai preencher a zona mais próxima da capacidade máxima. 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 é mais provável que os picos de zona única sejam atendidos por uma única zona até que o Traffic Director possa reagir.

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

Nas seções a seguir, explicamos as opções para modificar o balanceamento de carga do Traffic Director.

Back-ends preferidos

É 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 Traffic Director 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. Ela solicita que o Traffic Director reduza automaticamente a capacidade de back-end para zero quando um back-end tiver menos de 25% das instâncias individuais ou endpoints passando 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 Traffic Director 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 Traffic Director geralmente envia tráfego para back-ends considerando vários fatores. Em um estado estável, o Traffic Director envia o tráfego para os 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 Traffic Director também monitora os back-ends a serem usados quando os back-ends principais não estiverem íntegros e não puderem 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 Traffic Director 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 Traffic Director não precisa mudar o tráfego imediatamente. Em vez disso, o Traffic Director 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 Traffic Director tolera a falta de integridade até o limite e desloca uma parte do tráfego dos back-ends primários para os de failover.

O limite de integridade de failover é um valor percentual. O valor que você define determina quando o Traffic Director 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 do Traffic Director é 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 Traffic Director 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.

No geral, o Traffic Director 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 de WATERFALL_BY_ZONE, o Traffic Director tenta manter o tráfego na zona mais próxima. Se você verificar as métricas de rede, verá que o Traffic Director prefere um back-end com a menor latência RTT ao enviar solicitações para otimizar a latência RTT geral.

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 preferidos estiverem configurados e não tiverem atingido o limite de capacidade, 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.

Drenagem 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% das instâncias/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

• Para ver instruções de configuração, consulte Configurar o balanceamento de carga avançado.