Por predefinição, um Network Load Balancer de encaminhamento interno distribui novas ligações para back-ends elegíveis sem considerar a zona em que o cliente e o back-end estão localizados.
Com a afinidade zonal, o equilibrador de carga pode distribuir novas ligações de uma VM de cliente específica para um conjunto modificado de back-ends elegíveis que se encontram na zona da VM de cliente. Limitar o tráfego entre zonas mantendo o tráfego local na zona sempre que possível reduz o custo de transferência de dados entre zonas, reduz a latência e melhora o desempenho, ao mesmo tempo que mantém as vantagens da arquitetura multizonal.
A afinidade zonal está configurada no serviço de back-end de um Network Load Balancer de passagem interno. O balanceador de carga suporta diferentes opções de afinidade zonal que oferecem vários graus de preferência para encaminhar novas ligações para back-ends elegíveis que se encontram na mesma zona que um cliente compatível. Tenha em atenção que as ligações estabelecidas na tabela de acompanhamento de ligações do balanceador de carga não são afetadas pela afinidade zonal.
Compatibilidade de funcionalidades
Antes de ativar a afinidade zonal, tem de compreender que funcionalidades do Network Load Balancer de encaminhamento interno são suportadas com a afinidade zonal.
Funcionalidades suportadas
- Saltos seguintes para rotas estáticas
- Saltos seguintes para rotas baseadas em políticas
- Failover
- Serviço publicado do Private Service Connect. A afinidade zonal é suportada para clientes compatíveis que enviam pacotes para um ponto final do Private Service Connect cujo produtor de serviços publicado usa um balanceador de carga de passagem interno.
Funcionalidades não suportadas
A afinidade zonal é incompatível com equilibradores de carga de passagem internos que estão configurados com o seguinte:
- Subconjuntos de back-end
- Destinos do coletor para a replicação de pacotes
- Implementações de integração de segurança de redes: na banda ou fora da banda. A utilização da afinidade zonal com a integração da segurança de rede resulta em perdas de pacotes.
Clientes compatíveis
A afinidade zonal só é possível para clientes de VMs localizados na mesma região que o equilibrador de carga. A afinidade zonal não é compatível com os seguintes clientes, que funcionam sempre como se a afinidade zonal estivesse desativada:
Clientes ligados através de túneis do Cloud VPN e anexos de VLAN do Cloud Interconnect: os túneis do Cloud VPN e os anexos de VLAN do Cloud Interconnect são recursos regionais e não recursos zonais. Os pacotes encaminhados através de um túnel da Cloud VPN ou de uma ligação VLAN nunca suportam a afinidade zonal, independentemente de estarem ou não na mesma região que o balanceador de carga.
VMs de cliente em regiões que não correspondem à região do equilibrador de carga: um equilibrador de carga de rede de passagem interno localizado numa região é acessível por clientes em todas as outras regiões se o acesso global estiver ativado. Quando as VMs de cliente estão numa região diferente da região do balanceador de carga, as VMs de cliente nunca partilham uma zona comum com nenhum dos back-ends do balanceador de carga.
Compatibilidade com balanceadores de carga de rede de encaminhamento interno de próximo salto
Embora a afinidade zonal possa ser ativada para equilibradores de carga de rede de passagem interna usados como saltos seguintes para rotas estáticas, geralmente, não é recomendada para arquiteturas com estado em que os dispositivos virtuais, como firewalls, são configurados em paralelo e as entidades de equilíbrio de carga são colocadas em ambos os lados dos firewalls.
Para saber mais, consulte a secção de requisitos no guia Equilibrador de carga de rede de encaminhamento interno como saltos seguintes.
Opções de afinidade zonal
Os balanceadores de carga de rede de encaminhamento interno suportam as seguintes opções de afinidade zonal:
ZONAL_AFFINITY_DISABLED(predefinição): a afinidade zonal está desativada. O balanceador de carga seleciona um back-end elegível para uma nova ligação sem modificar o conjunto de back-ends elegíveis originais.ZONAL_AFFINITY_STAY_WITHIN_ZONE: a afinidade zonal está ativada. Quando ocorre uma correspondência zonal, o balanceador de carga mantém o tráfego na zona do cliente, mesmo que isso signifique usar back-ends não íntegros. Para ver detalhes sobre esta opção, consulte Como funciona oZONAL_AFFINITY_STAY_WITHIN_ZONE.ZONAL_AFFINITY_SPILL_CROSS_ZONE: a afinidade zonal está ativada. Quando ocorre uma correspondência zonal, o equilibrador de carga permite que as novas ligações sejam distribuídas na zona do cliente ou transbordem para outras zonas. O transbordo é controlado pela taxa de transbordo. Para mais informações sobre esta opção, consulte o artigo ComoZONAL_AFFINITY_SPILL_CROSS_ZONEfuncionam o rácio de preenchimento e o rácio de transbordo.
Para saber como configurar a afinidade zonal no serviço de back-end de um Network Load Balancer de encaminhamento interno, consulte o artigo Use a afinidade zonal.
Como funciona a afinidade zonal
As secções seguintes oferecem uma compreensão avançada do funcionamento da afinidade zonal. A compreensão destes detalhes não é necessária para configurar a afinidade zonal, mas pode ajudar a compreender casos extremos e o comportamento preciso da distribuição de tráfego.
Especificamente, estas secções abordam o seguinte:
Diferentes tipos de backends usados no processo de seleção.
Como o balanceador de carga determina uma correspondência zonal.
A lógica de afinidade zonal detalhada para diferentes opções de configuração.
Diferentes tipos de back-ends
A afinidade zonal cria um conjunto de back-ends elegíveis modificados com base nos back-ends elegíveis originais e nos back-ends configurados do equilibrador de carga. Para explicar como a afinidade zonal faz esta modificação, definimos precisamente cinco conjuntos de back-end diferentes. Este documento faz referência aos seguintes termos nas secções subsequentes ao explicar como funciona a afinidade zonal.
Conjuntos de entradas
Back-ends configurados: o conjunto de todos os back-ends que fazem parte do serviço de back-end do balanceador de carga. Isto inclui todos os back-ends principais e, se a funcionalidade de alternativa estiver ativada, todos os back-ends principais e de alternativa.
Back-ends originais elegíveis: um subconjunto de back-ends configurados que são elegíveis para receber novas ligações. O conjunto de back-ends originais elegíveis é produzido pelo passo Identificar back-ends elegíveis do processo de seleção de back-ends e acompanhamento da associação.
Conjuntos de intermediários
Back-ends de teste de correspondência zonal: um subconjunto de back-ends configurados usados para testar uma correspondência zonal. Tanto os backends configurados como os backends elegíveis originais determinam que VMs são backends de teste de correspondência zonal.
Back-ends correspondentes zonais: um subconjunto dos back-ends de teste de correspondência zonal que estão na mesma zona que um cliente compatível.
Conjunto de saída
- Back-ends elegíveis modificados: consoante o tipo de afinidade zonal configurada e a taxa de transbordo, os back-ends elegíveis modificados podem ser iguais aos back-ends elegíveis originais, um subconjunto dos back-ends elegíveis originais ou diferentes dos back-ends elegíveis originais. Este conjunto é usado para fornecer a afinidade zonal configurada.
Correspondência zonal
Uma correspondência zonal descreve as condições em que a afinidade zonal é acionada. Em seguida, o balanceador de carga pode modificar o conjunto de back-ends elegíveis originais para fornecer a afinidade zonal configurada. A modificação dos back-ends elegíveis originais ocorre depois de o equilibrador de carga selecionar um back-end elegível para uma nova ligação.
Para que a lógica de afinidade zonal seja acionada, tem de ocorrer a seguinte sequência de eventos:
A afinidade zonal tem de estar ativada.
Se a afinidade zonal estiver ativada, avance para o passo seguinte.
Determine se o cliente é um cliente compatível.
Se o cliente for compatível, avance para o passo seguinte.
Determinar se pode ocorrer uma correspondência zonal.
Uma correspondência zonal significa que a VM do cliente está numa zona que contém, pelo menos, um backend de teste de correspondência zonal. Os back-ends de teste de correspondência zonal são um conjunto de back-ends configurados com base nos back-ends elegíveis originais. Para ver detalhes, consulte as condições de correspondência zonal.
Uma correspondência zonal nunca é possível se uma das seguintes condições for verdadeira:
- A afinidade zonal está desativada
- O cliente não é um cliente compatível
Aplique a lógica de afinidade zonal.
Condições de correspondência zonais
Para ocorrer uma correspondência zonal, pelo menos uma instância ou um ponto final nos backends de teste de correspondência zonal tem de estar na mesma zona que um cliente compatível. Os backends configurados e os backends elegíveis originais são entradas usadas para determinar os backends de teste de correspondência zonal.
| Back-ends originais elegíveis | Back-ends de testes de correspondência zonais |
|---|---|
| Todos os back-ends principais em bom estado de funcionamento |
Todos os back-ends principais configurados Os backends principais configurados podem estar todos em bom estado ou ser uma combinação de em bom estado e em mau estado. |
| Todos os back-ends de comutação em caso de falha em bom estado de funcionamento |
Todos os back-ends de comutação em caso de falha configurados Todos os back-ends de alternativa configurados podem estar em bom estado ou ser uma combinação de em bom estado e em mau estado. |
| Todos os back-ends principais em mau estado de funcionamento |
Todos os back-ends principais configurados Os backends principais configurados estão todos em mau estado por definição quando os backends principais originais elegíveis estão todos em mau estado. |
Exemplo de correspondência zonal
Considere a seguinte configuração para um balanceador de carga de rede de encaminhamento interno para compreender se ocorre uma correspondência zonal.
- Back-ends principais: zonas A e B
- Back-ends de ativação pós-falha: zonas C e D
- Localização da VM do cliente: zona A
- Afinidade zonal ativada
- A política de alternativa predefinida está presente
Cenário 1:
- Back-ends elegíveis originais: todos os back-ends principais em bom estado (zonas A e B)
- Back-ends de teste de correspondência zonal: todos os back-ends primários configurados (zonas A e B)
- Existe uma correspondência zonal?: Sim. Neste caso, a VM do cliente está na mesma zona que os backends de teste de correspondência zonal, pelo que existe uma correspondência zonal.
Cenário 2:
- Back-ends originais elegíveis: todos os back-ends de alternativa saudáveis (zonas C e D)
- Back-ends de teste de correspondência zonal: todos os back-ends de alternativa configurados (zonas C e D)
- Existe uma correspondência zonal?: Não. Para ocorrer uma correspondência zonal, a VM do cliente tem de estar numa zona que contenha, pelo menos, um back-end do conjunto de back-ends de teste de correspondência zonal. Neste caso, o cliente está na zona A e os backends de teste de correspondência zonal estão nas zonas C e D.
Após ocorrer uma correspondência zonal, aplica a lógica de afinidade zonal, conforme descrito nas secções seguintes.
Lógica de afinidade zonal
Se ocorrer uma correspondência zonal, aplique a lógica de afinidade zonal consoante a opção de afinidade zonal configurada. As opções que ativam a afinidade zonal são as seguintes:
ZONAL_AFFINITY_STAY_WITHIN_ZONEZONAL_AFFINITY_SPILL_CROSS_ZONEcom uma taxa de transbordo de0ZONAL_AFFINITY_SPILL_CROSS_ZONEcom uma taxa de transbordo diferente de zero
Após uma correspondência zonal e consoante o tipo de opção de afinidade zonal configurada, os backends elegíveis modificados podem ser iguais aos backends elegíveis originais, um subconjunto dos backends elegíveis originais ou diferentes dos backends elegíveis originais.
Como funciona o ZONAL_AFFINITY_STAY_WITHIN_ZONE
Se a afinidade zonal estiver definida como ZONAL_AFFINITY_STAY_WITHIN_ZONE e ocorrer uma correspondência zonal, o equilibrador de carga distribui novas ligações para os back-ends elegíveis modificados. Os backends elegíveis modificados podem ser os mesmos que os backends elegíveis originais, um subconjunto dos backends elegíveis originais ou diferentes dos backends elegíveis originais.
Para criar backends elegíveis modificados, o balanceador de carga usa o seguinte processo:
Comece com os backends de teste de correspondência zonal identificados pela condição de correspondência zonal.
Remova todos os back-ends que não estejam na mesma zona que o cliente. Isto dá-nos um conjunto de backends correspondentes zonais. Este conjunto nunca está vazio porque ocorreu uma correspondência zonal.
Calcular a interseção dos backends correspondentes zonais com os backends elegíveis originais. Esta interseção pode estar preenchida ou vazia.
Se a interseção não estiver vazia, os back-ends elegíveis modificados são o conjunto de interseções. Os backends elegíveis modificados podem ser iguais aos backends elegíveis originais ou podem ser um subconjunto dos backends elegíveis originais.
Se a interseção estiver vazia, os backends elegíveis modificados são os próprios backends correspondentes zonais, que são sempre diferentes dos backends elegíveis originais. Nesta situação, todos os backends elegíveis modificados estão em mau estado.
A tabela seguinte resume o processo de criação do conjunto de backends elegíveis modificados quando a opção de afinidade zonal é ZONAL_AFFINITY_STAY_WITHIN_ZONE. Esta opção de afinidade zonal favorece os back-ends na zona do cliente, mesmo que isso signifique usar back-ends não íntegros.
| Back-ends elegíveis originais (A) | Back-ends de teste de correspondência zonal (B) | Back-ends com correspondência zonal (C) | Interseção (A∩C) | Back-ends elegíveis modificados |
|---|---|---|---|---|
| Todos os back-ends principais em bom estado de funcionamento |
Todos os back-ends principais configurados Os back-ends de teste de correspondência zonal podem estar todos em bom estado de funcionamento ou ser uma combinação de back-ends em bom e mau estado de funcionamento. |
Todos os backends principais na zona do cliente Os back-ends correspondentes zonais podem estar todos em bom estado de funcionamento, todos em mau estado de funcionamento ou uma combinação de ambos. |
Todos os back-ends principais em bom estado na zona do cliente |
Intersection not empty: os backends elegíveis modificados são todos os backends primários em bom estado na zona do cliente. Os back-ends elegíveis modificados podem ser os mesmos que os back-ends elegíveis originais ou um subconjunto dos back-ends elegíveis originais. Intersection is empty: os backends elegíveis modificados são todos os backends principais não íntegros na zona do cliente. Os back-ends elegíveis modificados são os mesmos que os back-ends correspondentes zonais, que são todos back-ends principais na zona do cliente. No entanto, todos estes back-ends não estão em bom estado porque a interseção com os back-ends elegíveis originais está vazia. |
| Todos os back-ends de comutação em caso de falha em bom estado de funcionamento |
Todos os back-ends de comutação em caso de falha configurados Os back-ends de teste de correspondência zonal podem estar todos em bom estado de funcionamento ou ser uma combinação de back-ends em bom e mau estado de funcionamento. |
Todos os backends de alternativa na zona do cliente Os back-ends correspondentes zonais podem estar todos em bom estado de funcionamento, todos em mau estado de funcionamento ou uma combinação de ambos. |
Todos os backends de comutação por falha em bom estado na zona do cliente |
Intersection not empty: os backends elegíveis modificados são todos os backends de alternativa saudáveis na zona do cliente. Os back-ends elegíveis modificados podem ser os mesmos que os back-ends elegíveis originais ou um subconjunto dos back-ends elegíveis originais. Intersection is empty: os backends elegíveis modificados são todos os backends de comutação por falha não íntegros na zona do cliente. Os back-ends elegíveis modificados são iguais aos back-ends correspondentes zonais, que são todos back-ends de alternativa na zona do cliente. No entanto, todos estes back-ends não estão em bom estado porque a interseção com os back-ends elegíveis originais está vazia. |
| Todos os back-ends principais em mau estado de funcionamento |
Todos os back-ends principais configurados Por definição, os back-ends de teste de correspondência zonal estão todos em mau estado de funcionamento quando os back-ends elegíveis originais estão todos em mau estado de funcionamento. |
Todos os backends principais não íntegros na zona do cliente |
Todos os backends principais não íntegros na zona do cliente |
A interseção nunca está vazia: os back-ends elegíveis modificados são todos os back-ends principais não íntegros na zona do cliente. Os back-ends elegíveis modificados podem ser os mesmos que os back-ends elegíveis originais ou um subconjunto dos back-ends elegíveis originais. |
Como funcionam o ZONAL_AFFINITY_SPILL_CROSS_ZONE e a taxa de transbordo
Se a afinidade zonal estiver definida como ZONAL_AFFINITY_SPILL_CROSS_ZONE e ocorrer uma correspondência zonal, o equilibrador de carga distribui novas ligações para os back-ends elegíveis modificados. Os backends elegíveis modificados podem ser os mesmos que os backends elegíveis originais ou um subconjunto dos backends elegíveis originais.
Quando os back-ends elegíveis modificados são os mesmos que os back-ends elegíveis originais, as novas ligações podem ser enviadas para back-ends elegíveis na zona do cliente ou podem ser enviadas para back-ends elegíveis em qualquer zona ("transbordo"). Esta distribuição depende de uma taxa de transbordo configurável.
Uma taxa de transbordo configurável indica o valor limite para manter o tráfego na zona do cliente. O valor da taxa de transbordo pode variar entre 0.0 e 1.0, inclusive. Se não especificar uma taxa de transbordo ao configurar o elemento
ZONAL_AFFINITY_SPILL_CROSS_ZONE, Google Cloud usa um valor predefinido de
0.0.
Rácio de transbordo zero
Se a taxa de transbordo configurada for 0.0, o balanceador de carga usa o seguinte processo para criar os backends elegíveis modificados:
Comece com os backends de teste de correspondência zonal identificados pela condição de correspondência zonal.
Remova todos os back-ends que não estejam na mesma zona que o cliente. Isto dá-nos um conjunto de backends correspondentes zonais. Este conjunto nunca está vazio porque ocorreu uma correspondência zonal.
Calcular a interseção dos backends correspondentes zonais com os backends elegíveis originais. Esta interseção pode estar preenchida ou vazia.
Se esta interseção não estiver vazia, os back-ends elegíveis modificados são o conjunto de interseção. Os backends elegíveis modificados podem ser os mesmos que os backends elegíveis originais ou os backends elegíveis modificados podem ser um subconjunto dos backends elegíveis originais.
Se a interseção estiver vazia, os back-ends elegíveis modificados são os mesmos que os back-ends elegíveis originais.
A tabela seguinte resume o processo de criação do conjunto de backends elegíveis modificados quando a opção de afinidade zonal é ZONAL_AFFINITY_SPILL_CROSS_ZONE e a proporção de transbordo configurada é 0.0.
| Back-ends elegíveis originais (A) | Back-ends de teste de correspondência zonal (B) | Back-ends com correspondência zonal (C) | Interseção (A∩C) | Back-ends elegíveis modificados |
|---|---|---|---|---|
| Todos os back-ends principais em bom estado de funcionamento |
Todos os back-ends principais configurados Os back-ends de teste de correspondência zonal podem estar todos em bom estado de funcionamento ou ser uma combinação de back-ends em bom e mau estado de funcionamento. |
Todos os backends principais na zona do cliente Os back-ends correspondentes zonais podem estar todos em bom estado de funcionamento, todos em mau estado de funcionamento ou uma combinação de ambos. |
Todos os back-ends principais em bom estado na zona do cliente |
Intersection not empty: os backends elegíveis modificados são todos os backends primários em bom estado na zona do cliente. As novas associações são distribuídas na zona do cliente. Os back-ends elegíveis modificados podem ser os mesmos que os back-ends elegíveis originais ou um subconjunto dos back-ends elegíveis originais. A interseção está vazia: os back-ends elegíveis modificados são iguais aos back-ends elegíveis originais. As novas associações podem ser distribuídas na zona do cliente ou noutras zonas. |
| Todos os back-ends de comutação em caso de falha em bom estado de funcionamento |
Todos os back-ends de comutação em caso de falha configurados Os back-ends de teste de correspondência zonal podem estar todos em bom estado de funcionamento ou ser uma combinação de back-ends em bom e mau estado de funcionamento. |
Todos os backends de alternativa na zona do cliente Os back-ends correspondentes zonais podem estar todos em bom estado de funcionamento, todos em mau estado de funcionamento ou uma combinação de ambos. |
Todos os backends de comutação por falha em bom estado na zona do cliente |
Intersection not empty: os backends elegíveis modificados são todos os backends de alternativa saudáveis na zona do cliente. As novas associações são distribuídas na zona do cliente. Os back-ends elegíveis modificados podem ser os mesmos que os back-ends elegíveis originais ou um subconjunto dos back-ends elegíveis originais. A interseção está vazia: os backends elegíveis modificados são iguais aos backends elegíveis originais. As novas associações podem ser distribuídas na zona do cliente ou noutras zonas. |
| Todos os back-ends principais em mau estado de funcionamento |
Todos os back-ends principais configurados Por definição, os back-ends de teste de correspondência zonal estão todos em mau estado de funcionamento quando os back-ends elegíveis originais estão todos em mau estado de funcionamento. |
Todos os backends principais não íntegros na zona do cliente |
Todos os backends principais não íntegros na zona do cliente |
A interseção nunca está vazia: os back-ends elegíveis modificados são todos os back-ends principais não íntegros na zona do cliente. As novas associações são distribuídas na zona do cliente. Os back-ends elegíveis modificados podem ser os mesmos que os back-ends elegíveis originais ou um subconjunto dos back-ends elegíveis originais. |
Rácio de transbordo não nulo
Se a relação de transbordo configurada for superior a 0.0, mas inferior ou igual a 1.0, o balanceador de carga usa o seguinte processo para criar os back-ends elegíveis modificados:
Comece com os backends de teste de correspondência zonal identificados pela condição de correspondência zonal.
Remova todos os back-ends que não estejam na mesma zona que o cliente. Isto dá-nos um conjunto de backends correspondentes zonais. Este conjunto nunca está vazio porque ocorreu uma correspondência zonal.
Calcular a interseção dos backends correspondentes zonais com os backends elegíveis originais. Este conjunto pode estar vazio ou não.
Calcule o seguinte rácio:
$$ \frac{\text{count}(\text{zonal matched backends} \; \cap \; \text{original eligible backends})}{\text{count}(\text{zonal matched backends})} $$Tenha em atenção que a proporção calculada é sempre zero quando o conjunto de interseção está vazio.
Use a relação calculada para determinar os servidores de processamento elegíveis modificados:
Se a relação calculada for igual ou superior à relação de transbordo, os back-ends elegíveis modificados são o conjunto de interseção. Os back-ends elegíveis modificados podem ser os mesmos que os back-ends elegíveis originais ou um subconjunto dos back-ends elegíveis originais.
Se a relação calculada for inferior à relação de transbordo, os backends elegíveis modificados são os mesmos que os backends elegíveis originais.
A tabela seguinte resume o processo de criação do conjunto de backends elegíveis modificados quando a opção de afinidade zonal é a opção ZONAL_AFFINITY_SPILL_CROSS_ZONE e a proporção de transbordo configurada não é 0.0:
| Back-ends elegíveis originais (A) | Back-ends de teste de correspondência zonal (B) | Back-ends com correspondência zonal (C) | Interseção (A∩C) | Back-ends elegíveis modificados |
|---|---|---|---|---|
| Todos os back-ends principais em bom estado de funcionamento |
Todos os back-ends principais configurados Os back-ends de teste de correspondência zonal podem estar todos em bom estado de funcionamento ou ser uma combinação de back-ends em bom e mau estado de funcionamento. |
Todos os backends principais na zona do cliente Os back-ends correspondentes zonais podem estar todos em bom estado de funcionamento, todos em mau estado de funcionamento ou uma combinação de ambos. |
Todos os backends principais em bom estado na zona do cliente |
Rácio calculado ≥ rácio de transbordo: os backends elegíveis modificados são todos os backends principais em bom estado na zona do cliente. As novas associações são distribuídas na zona do cliente. Os back-ends elegíveis modificados podem ser os mesmos que os back-ends elegíveis originais ou um subconjunto dos back-ends elegíveis originais. Rácio calculado < rácio de transbordo: os backends elegíveis modificados são iguais aos backends elegíveis originais. As novas associações podem ser distribuídas na zona do cliente ou noutras zonas. |
| Todos os back-ends de comutação em caso de falha em bom estado de funcionamento |
Todos os back-ends de comutação em caso de falha configurados Os back-ends de teste de correspondência zonal podem estar todos em bom estado de funcionamento ou ser uma combinação de back-ends em bom e mau estado de funcionamento. |
Todos os backends de alternativa na zona do cliente Os back-ends correspondentes zonais podem estar todos em bom estado de funcionamento, todos em mau estado de funcionamento ou uma combinação de ambos. |
Todos os backends de comutação por falha em bom estado na zona do cliente |
Relação calculada ≥ relação de transbordo: os backends elegíveis modificados são todos os backends de comutação por falha saudáveis na zona do cliente. As novas associações são distribuídas na zona do cliente. Os back-ends elegíveis modificados podem ser os mesmos que os back-ends elegíveis originais ou um subconjunto dos back-ends elegíveis originais. Rácio calculado < rácio de transbordo: os backends elegíveis modificados são iguais aos backends elegíveis originais. As novas associações podem ser distribuídas na zona do cliente ou noutras zonas. |
| Todos os back-ends principais em mau estado de funcionamento |
Todos os back-ends principais configurados Por definição, os back-ends de teste de correspondência zonal estão todos em mau estado de funcionamento quando os back-ends elegíveis originais estão todos em mau estado de funcionamento. |
Todos os backends principais não íntegros na zona do cliente |
Todos os backends principais não íntegros na zona do cliente |
A taxa calculada é sempre ≥ taxa de transbordo: os back-ends elegíveis modificados são todos os back-ends principais não íntegros na zona do cliente. As novas associações são distribuídas na zona do cliente. Os back-ends elegíveis modificados podem ser os mesmos que os back-ends elegíveis originais ou um subconjunto dos back-ends elegíveis originais. |
Exemplos de taxa de transbordo
Os exemplos seguintes mostram como funciona o ZONAL_AFFINITY_SPILL_CROSS_ZONE.
Uma taxa de transbordo de
1.0significa o seguinte:- Quando a interseção dos backends correspondentes zonais e dos backends elegíveis originais é o mesmo conjunto que os backends correspondentes zonais, os backends elegíveis modificados são o conjunto de interseção.
- Quando a interseção dos servidores de processamento correspondentes zonais e dos servidores de processamento elegíveis originais não é o mesmo conjunto que os servidores de processamento correspondentes zonais, os servidores de processamento elegíveis modificados são iguais aos servidores de processamento elegíveis originais.
Uma taxa de transbordo de
0.8significa o seguinte:- Quando o número de back-ends na interseção dos back-ends correspondentes zonais e dos back-ends elegíveis originais for, pelo menos, 80% do número de back-ends correspondentes zonais, o conjunto de back-ends elegíveis modificados é esse conjunto de interseção.
- Quando o número de back-ends na interseção dos back-ends correspondentes zonais e dos back-ends elegíveis originais for inferior a 80% do número de back-ends correspondentes zonais, os back-ends elegíveis modificados são iguais aos back-ends elegíveis originais.
Uma taxa de transbordo de
0.0significa o seguinte:- Se a interseção dos backends correspondentes zonais e dos backends originais elegíveis não estiver vazia, os backends elegíveis modificados são o conjunto de interseção.
- Se a interseção dos backends correspondentes zonais e dos backends elegíveis originais estiver vazia, os backends elegíveis modificados são iguais aos backends elegíveis originais.
Considere a seguinte configuração em que um equilibrador de carga de encaminhamento interno está configurado com uma opção de afinidade zonalZONAL_AFFINITY_SPILL_CROSS_ZONE com uma taxa de transbordo de 0.8:
- Back-ends configurados: dez back-ends principais (cinco na zona 1 e cinco na zona 2)
- Back-ends elegíveis originais: todos os back-ends primários em bom estado (Oito back-ends: cinco na zona 1 e três na zona 2)
- Back-ends de teste de correspondência zonal: todos os dez back-ends principais configurados
Cenário A: cliente compatível na zona 1
- Back-ends com correspondência zonal: cinco back-ends na zona 1.
- Interseção: a interseção de back-ends correspondentes zonais e back-ends elegíveis originais consiste nos cinco back-ends em bom estado de funcionamento na zona 1.
- Rácio calculado: 5 / 5 = 1,0
- Resultado: uma vez que a proporção calculada de 1,0 ≥ 0,8, os back-ends elegíveis modificados estão no conjunto de interseção, ou seja, todos os cinco back-ends principais em bom estado na zona 1 do cliente. As novas ligações são distribuídas exclusivamente na zona do cliente.
Cenário B: cliente compatível na zona 2
- Back-ends com correspondência zonal: cinco back-ends na zona 2.
- Interseção: a interseção de back-ends correspondentes zonais e back-ends elegíveis originais consiste nos três back-ends em bom estado de funcionamento na zona 2.
- Rácio calculado: 3 / 5 = 0,6
- Resultado: uma vez que a relação calculada de 0,6 é inferior a 0,8, os backends elegíveis modificados são os backends elegíveis originais. Os backends elegíveis originais são os oito backends em bom estado (cinco na zona 1 e três na zona 2). As novas associações são distribuídas pela zona 1 ou pela zona 2.
O que se segue?
- Para configurar o Cloud Monitoring para balanceadores de carga de rede de encaminhamento interno, consulte o artigo Registo e monitorização do balanceador de carga de rede de encaminhamento interno.
- Para resolver problemas com o balanceador de carga de rede de encaminhamento interno, consulte o artigo Resolva problemas com balanceadores de carga de rede de encaminhamento interno.