Affinità di zona per i bilanciatori del carico di rete passthrough interni

L'affinità di zona, configurata sul servizio di backend del bilanciatore del carico, consente di limitare il traffico tra zone, ridurre la latenza e migliorare le prestazioni, mantenendo al contempo i vantaggi di un'architettura multizona.

I bilanciatori del carico di rete passthrough interni supportano diverse opzioni di affinità a livello di zona che offrono vari gradi di preferenza per il routing di nuove connessioni a backend idonei che si trovano nella stessa zona di un client compatibile. Tieni presente che le connessioni stabilite nella tabella di monitoraggio delle connessioni del bilanciatore del carico non sono interessate dall'affinità di zona.

Prima di iniziare

Prima di attivare l'affinità di zona, devi capire quali funzionalità del bilanciatore del carico di rete passthrough interno sono supportate con l'affinità di zona.

Funzionalità supportate

Funzionalità non supportate

L'affinità di zona non è compatibile con i bilanciatori del carico di rete passthrough interni configurati con quanto segue:

Client compatibili

L'affinità di zona è possibile solo per i client VM che si trovano nella stessa regione del bilanciatore del carico. L'affinità di zona non è compatibile con i seguenti client, che funzionano sempre come se l'affinità di zona fosse disattivata:

  • Client connessi tramite tunnel Cloud VPN e collegamenti VLAN Cloud Interconnect: i tunnel Cloud VPN e i collegamenti VLAN Cloud Interconnect sono risorse regionali, non di zona. I pacchetti instradati tramite un tunnel Cloud VPN o un collegamento VLAN non supportano mai l'affinità di zona, indipendentemente dal fatto che si trovino o meno nella stessa regione del bilanciatore del carico.

  • VM client in regioni che non corrispondono alla regione del bilanciatore del carico: un bilanciatore del carico di rete passthrough interno che si trova in una regione è raggiungibile dai client in tutte le altre regioni se è abilitato l'accesso globale. Quando le VM client si trovano in una regione diversa da quella del bilanciatore del carico, non condividono mai una zona comune con nessuno dei backend del bilanciatore del carico.

Compatibilità con i bilanciatori del carico di rete passthrough interni dell'hop successivo

Sebbene l'affinità di zona possa essere abilitata per i bilanciatori del carico di rete passthrough interni utilizzati come hop successivi per le route statiche, in genere è sconsigliata per le architetture stateful in cui le appliance virtuali come i firewall sono configurate in parallelo e le entità di bilanciamento del carico sono posizionate su entrambi i lati dei firewall.

Per saperne di più, consulta la sezione Requisiti della guida Bilanciatore del carico di rete passthrough interno come hop successivi.

Opzioni di affinità a livello di zona

I bilanciatori del carico di rete passthrough interni supportano le seguenti opzioni di affinità a livello di zona:

  • ZONAL_AFFINITY_DISABLED (valore predefinito): l'affinità a livello di zona è disattivata. Il bilanciatore del carico seleziona un backend idoneo per una nuova connessione senza modificare l'insieme dei backend idonei originali.

  • ZONAL_AFFINITY_STAY_WITHIN_ZONE: l'affinità a livello di zona è abilitata. Quando si verifica una corrispondenza zonale, il bilanciatore del carico mantiene il traffico nella zona del client anche se ciò significa utilizzare backend non integri. Per informazioni dettagliate su questa opzione, vedi Come funziona ZONAL_AFFINITY_STAY_WITHIN_ZONE.

  • ZONAL_AFFINITY_SPILL_CROSS_ZONE: l'affinità a livello di zona è abilitata. Quando si verifica una corrispondenza zonale, il bilanciatore del carico consente di distribuire nuove connessioni all'interno della zona del client o di trasferirle in altre zone. Il report è controllato dal rapporto di overflow. Per saperne di più su questa opzione, consulta Come funzionano ZONAL_AFFINITY_SPILL_CROSS_ZONE e il rapporto di overflow.

Per scoprire come configurare l'affinità di zona nel servizio di backend di un bilanciatore del carico di rete passthrough interno, consulta Utilizzare l'affinità di zona.

Come funziona l'affinità a livello di zona

Le sezioni seguenti forniscono una comprensione avanzata del funzionamento dell'affinità di zona. La comprensione di questi dettagli non è necessaria per configurare l'affinità di zona, ma può aiutarti a comprendere i casi limite e il comportamento preciso della distribuzione del traffico.

Nello specifico, queste sezioni riguardano quanto segue:

Diversi tipi di backend

L'affinità di zona crea un insieme di backend idonei modificati in base ai backend idonei originali e ai backend configurati del bilanciatore del carico. Per spiegare come l'affinità di zona esegue questa modifica, definiamo con precisione cinque diversi set di backend. Questo documento fa riferimento ai seguenti termini nelle sezioni successive mentre spiega come funziona l'affinità di zona.

  • Set di input

    • Backend configurati: l'insieme di tutti i backend che fanno parte del servizio di backend del bilanciatore del carico. Sono inclusi tutti i backend primari e, se la funzionalità di failover è attivata, tutti i backend primari e di failover.

    • Backend idonei originali: un sottoinsieme di backend configurati idonei a ricevere nuove connessioni. Il set di backend idonei originali viene prodotto dal passaggio Identifica i backend idonei del processo di selezione del backend e monitoraggio della connessione.

  • Set intermediari

    • Backend di test di corrispondenza zonale: un sottoinsieme di backend configurati utilizzati per testare una corrispondenza zonale. Sia i backend configurati sia i backend idonei originali determinano quali VM sono backend di test di corrispondenza zonale.

    • Backend con corrispondenza a livello di zona: un sottoinsieme dei backend di test con corrispondenza a livello di zona che si trovano nella stessa zona di un client compatibile.

  • Set di output

    • Backend idonei modificati: a seconda del tipo di affinità di zona configurata e del rapporto di overflow, i backend idonei modificati potrebbero essere uguali a quelli idonei originali, un sottoinsieme di questi o diversi. Questo insieme viene utilizzato per fornire l'affinità zonale configurata.

Corrispondenza zonale

Una corrispondenza zonale descrive le condizioni in base alle quali viene attivata l'affinità zonale. Il bilanciatore del carico potrebbe quindi modificare l'insieme di backend idonei originali per fornire l'affinità di zona configurata. La modifica dei backend idonei originali avviene dopo che il bilanciatore del carico seleziona un backend idoneo per una nuova connessione.

Affinché la logica di affinità di zona venga attivata, deve verificarsi la seguente sequenza di eventi:

  1. L'affinità zonale deve essere abilitata.

    Se l'affinità di zona è abilitata, vai al passaggio successivo.

  2. Determina se il client è un client compatibile.

    Se il client è compatibile, vai al passaggio successivo.

  3. Determinare se può verificarsi una corrispondenza zonale.

    Una corrispondenza zonale significa che la VM client si trova in una zona che contiene almeno un backend di test di corrispondenza zonale. I backend di test di corrispondenza zonale sono un insieme di backend configurati in base ai backend idonei originali. Per maggiori dettagli, vedi Condizioni di corrispondenza zonale.

    Una corrispondenza zonale non è possibile se si verifica una delle seguenti condizioni:

    • L'affinità a livello di zona è disattivata
    • Il client non è compatibile

  4. Applica la logica di affinità a livello di zona.

Condizioni di corrispondenza zonale

Affinché si verifichi una corrispondenza a livello di zona, almeno un'istanza o un endpoint nei backend di test di corrispondenza a livello di zona deve trovarsi nella stessa zona di un client compatibile. Sia i backend configurati sia i backend idonei originali sono input utilizzati per determinare i backend di test di corrispondenza zonale.

Backend idonei originali Backend di test di corrispondenza a livello di zona
Tutti i backend principali integri

Tutti i backend principali configurati

I backend primari configurati potrebbero essere tutti integri o una combinazione di integri e non integri.
Tutti i backend di failover integri

Tutti i backend di failover configurati

Tutti i backend di failover configurati potrebbero essere integri o una combinazione di integri e non integri.
Tutti i backend principali in stato non integro

Tutti i backend principali configurati

I backend primari configurati non sono integri per definizione quando i backend primari originali idonei non sono integri.

Esempio di corrispondenza zonale

Considera la seguente configurazione per un bilanciatore del carico di rete passthrough interno per capire se si verifica una corrispondenza zonale.

  • Backend principali: zone A e B
  • Backend di failover: zone C e D
  • Posizione VM client: zona A
  • Affinità a livello di zona attivata
  • Il criterio di failover predefinito è presente

Scenario 1:

  • Backend idonei originali: tutti i backend primari integri (zone A e B)
  • Backend di test di corrispondenza zonale: tutti i backend principali configurati (zone A e B)
  • Esiste una corrispondenza zonale?: Sì. In questo caso, la VM client si trova nella stessa zona dei backend di test di corrispondenza zonale, quindi c'è una corrispondenza zonale.

Scenario 2:

  • Backend idonei originali: tutti i backend di failover integri (zone C e D)
  • Backend di test di corrispondenza zonale: tutti i backend di failover configurati (zone C e D)
  • Esiste una corrispondenza zonale?: No. Affinché si verifichi una corrispondenza zonale, la VM client deve trovarsi in una zona che contiene almeno un backend del set di backend di test di corrispondenza zonale. In questo caso, il client si trova nella zona A e i backend di test di corrispondenza zonale si trovano nelle zone C e D.

Dopo che si è verificata una corrispondenza zonale, applichi la logica di affinità zonale come descritto nelle sezioni seguenti.

Logica di affinità zonale

Se si verifica una corrispondenza zonale, applica la logica di affinità zonale a seconda dell'opzione di affinità zonale configurata. Le opzioni che attivano l'affinità zonale sono le seguenti:

  • ZONAL_AFFINITY_STAY_WITHIN_ZONE
  • ZONAL_AFFINITY_SPILL_CROSS_ZONE con un rapporto di spillover pari a 0
  • ZONAL_AFFINITY_SPILL_CROSS_ZONE con un rapporto di spillover diverso da zero

Dopo che si è verificata una corrispondenza zonale e a seconda del tipo di opzione di affinità zonale configurata, i backend idonei modificati potrebbero essere uguali a quelli idonei originali, un sottoinsieme di quelli idonei originali o diversi da quelli idonei originali.

Come funziona ZONAL_AFFINITY_STAY_WITHIN_ZONE

Se l'affinità di zona è impostata su ZONAL_AFFINITY_STAY_WITHIN_ZONE e si verifica una corrispondenza di zona, il bilanciatore del carico distribuisce le nuove connessioni ai backend idonei modificati. I backend idonei modificati potrebbero essere uguali a quelli idonei originali, un sottoinsieme di questi o diversi.

Per creare backend idonei modificati, il bilanciatore del carico utilizza la seguente procedura:

  1. Inizia con i backend di test di corrispondenza zonale identificati dalla condizione di corrispondenza zonale.

  2. Rimuovi tutti i backend che non si trovano nella stessa zona del client. In questo modo otteniamo un insieme di backend corrispondenti alla zona. Questo insieme non è mai vuoto perché si è verificata una corrispondenza zonale.

  3. Calcola l'intersezione dei backend corrispondenti alla zona con i backend originali idonei. Questa intersezione potrebbe essere non vuota o vuota.

    • Se l'intersezione non è vuota, i backend idonei modificati sono l'insieme di intersezione. I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali oppure un sottoinsieme dei backend idonei originali.

    • Se l'intersezione è vuota, i backend idonei modificati sono gli stessi backend corrispondenti zonali, che sono sempre diversi dai backend idonei originali. In questa situazione, tutti i backend idonei modificati sono in stato non integro.

La seguente tabella riassume la procedura per creare l'insieme di backend idonei modificati quando l'opzione di affinità di zona è ZONAL_AFFINITY_STAY_WITHIN_ZONE. Questa opzione di affinità di zona favorisce i backend nella zona del client anche se ciò significa utilizzare backend non integri.

Backend idonei originali (A) Backend di test di corrispondenza zonale (B) Backend corrispondenti a livello di zona (C) Intersezione (A∩C) Backend idonei modificati
Tutti i backend principali integri

Tutti i backend principali configurati

I backend di test di corrispondenza zonale potrebbero essere tutti integri o una combinazione di integri e non integri.

Tutti i backend principali nella zona del client

I backend corrispondenti alla zona potrebbero essere tutti integri, tutti non integri o una combinazione di integri e non integri.

 Tutti i backend primari integri nella zona del client

Intersezione non vuota: i backend idonei modificati sono tutti i backend primari integri nella zona del cliente.

I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali o un sottoinsieme di questi.

L'intersezione è vuota: i backend idonei modificati sono tutti i backend principali non integri nella zona del client.

I backend idonei modificati sono gli stessi dei backend corrispondenti a livello di zona, che sono tutti backend primari nella zona del client; tuttavia, tutti questi backend non sono integri perché l'intersezione con i backend idonei originali è vuota.
Tutti i backend di failover integri

Tutti i backend di failover configurati

I backend di test di corrispondenza zonale potrebbero essere tutti integri o una combinazione di integri e non integri.

Tutti i backend di failover nella zona del client

I backend corrispondenti alla zona potrebbero essere tutti integri, tutti non integri o una combinazione di integri e non integri.

 Tutti i backend di failover integri nella zona del client

Intersezione non vuota: i backend idonei modificati sono tutti i backend di failover integri nella zona del client.

I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali o un sottoinsieme di questi.

L'intersezione è vuota: i backend idonei modificati sono tutti i backend di failover non integri nella zona del client.

I backend idonei modificati sono gli stessi dei backend corrispondenti a livello di zona, che sono tutti backend di failover nella zona del client; tuttavia, tutti questi backend non sono integri perché l'intersezione con i backend idonei originali è vuota.
Tutti i backend principali in stato non integro

Tutti i backend principali configurati

Per definizione, tutti i backend di test di corrispondenza zonale non sono integri quando tutti i backend primari idonei originali non sono integri.

Tutti i backend principali non integri nella zona del client

 Tutti i backend principali non integri nella zona del client

L'intersezione non è mai vuota: i backend idonei modificati sono tutti i backend principali non integri nella zona del client.

I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali o un sottoinsieme di questi.

Come funzionano ZONAL_AFFINITY_SPILL_CROSS_ZONE e il rapporto di spillover

Se l'affinità di zona è impostata su ZONAL_AFFINITY_SPILL_CROSS_ZONE e si verifica una corrispondenza di zona, il bilanciatore del carico distribuisce le nuove connessioni ai backend idonei modificati. I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali o un sottoinsieme di questi.

Quando i backend idonei modificati sono gli stessi dei backend idonei originali, le nuove connessioni potrebbero essere inviate ai backend idonei nella zona del client oppure potrebbero essere inviate ai backend idonei in qualsiasi zona ("spill over"). Questa distribuzione dipende da un rapporto di spillover configurabile.

Una percentuale di spillover configurabile indica il valore di soglia per mantenere il traffico nella zona del client. Il valore del rapporto di spillover può variare da 0.0 a 1.0, estremi inclusi. Se non specifichi un rapporto di overflow durante la configurazione di ZONAL_AFFINITY_SPILL_CROSS_ZONE, Google Cloud utilizza un valore predefinito di 0.0.

Percentuale di spillover pari a zero

Se il rapporto di overflow configurato è 0.0, il bilanciatore del carico utilizza il seguente processo per creare i backend idonei modificati:

  1. Inizia con i backend di test di corrispondenza zonale identificati dalla condizione di corrispondenza zonale.

  2. Rimuovi tutti i backend che non si trovano nella stessa zona del client. In questo modo otteniamo un insieme di backend corrispondenti alla zona. Questo insieme non è mai vuoto perché si è verificata una corrispondenza zonale.

  3. Calcola l'intersezione dei backend corrispondenti alla zona con i backend originali idonei. Questa intersezione potrebbe essere non vuota o vuota.

    • Se questa intersezione non è vuota, i backend idonei modificati sono l'insieme di intersezione. I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali oppure un sottoinsieme di questi ultimi.

    • Se l'intersezione è vuota, i backend idonei modificati sono gli stessi dei backend idonei originali.

La tabella seguente riepiloga la procedura per creare l'insieme di backend idonei modificati quando l'opzione di affinità di zona è ZONAL_AFFINITY_SPILL_CROSS_ZONE e il rapporto di overflow configurato è 0.0.

Backend idonei originali (A) Backend di test di corrispondenza zonale (B) Backend corrispondenti a livello di zona (C) Intersezione (A∩C) Backend idonei modificati
Tutti i backend principali integri

Tutti i backend principali configurati

I backend di test di corrispondenza zonale potrebbero essere tutti integri o una combinazione di integri e non integri.

Tutti i backend principali nella zona del client

I backend corrispondenti alla zona potrebbero essere tutti integri, tutti non integri o una combinazione di integri e non integri.

 Tutti i backend primari integri nella zona del client

Intersezione non vuota: i backend idonei modificati sono tutti i backend primari integri nella zona del cliente.

Le nuove connessioni vengono distribuite all'interno della zona del client. I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali o un sottoinsieme di questi.

L'intersezione è vuota: i backend idonei modificati sono uguali a quelli idonei originali.

Le nuove connessioni potrebbero essere distribuite all'interno della zona del client o in altre zone.
Tutti i backend di failover integri

Tutti i backend di failover configurati

I backend di test di corrispondenza zonale potrebbero essere tutti integri o una combinazione di integri e non integri.

Tutti i backend di failover nella zona del client

I backend corrispondenti alla zona potrebbero essere tutti integri, tutti non integri o una combinazione di integri e non integri.

 Tutti i backend di failover integri nella zona del client

Intersezione non vuota: i backend idonei modificati sono tutti i backend di failover integri nella zona del client.

Le nuove connessioni vengono distribuite all'interno della zona del client. I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali o un sottoinsieme di questi.

L'intersezione è vuota: i backend idonei modificati sono uguali a quelli idonei originali.

Le nuove connessioni potrebbero essere distribuite all'interno della zona del client o in altre zone.
Tutti i backend principali in stato non integro

Tutti i backend principali configurati

Per definizione, tutti i backend di test di corrispondenza zonale non sono integri quando tutti i backend primari idonei originali non sono integri.

Tutti i backend principali non integri nella zona del client

 Tutti i backend principali non integri nella zona del client

L'intersezione non è mai vuota: i backend idonei modificati sono tutti i backend principali non integri nella zona del client.

Le nuove connessioni vengono distribuite all'interno della zona del client. I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali o un sottoinsieme di questi.

Rapporto di spillover diverso da zero

Se il rapporto di overflow configurato è maggiore di 0.0 ma minore o uguale a 1.0, il bilanciatore del carico utilizza la seguente procedura per creare i backend idonei modificati:

  1. Inizia con i backend di test di corrispondenza zonale identificati dalla condizione di corrispondenza zonale.

  2. Rimuovi tutti i backend che non si trovano nella stessa zona del client. In questo modo otteniamo un insieme di backend corrispondenti alla zona. Questo insieme non è mai vuoto perché si è verificata una corrispondenza zonale.

  3. Calcola l'intersezione dei backend corrispondenti alla zona con i backend originali idonei. Questo insieme potrebbe essere non vuoto o vuoto.

  4. Calcola il seguente rapporto:

    $$ \frac{\text{count}(\text{zonal matched backends} \; \cap \; \text{original eligible backends})}{\text{count}(\text{zonal matched backends})} $$

    Tieni presente che il rapporto calcolato è sempre zero quando l'insieme di intersezione è vuoto.

  5. Utilizza il rapporto calcolato per determinare i backend idonei modificati:

    • Se il rapporto calcolato è maggiore o uguale al rapporto di overflow, i backend idonei modificati sono l'insieme di intersezione. I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali oppure un sottoinsieme di questi ultimi.

    • Se il rapporto calcolato è inferiore al rapporto di overflow, i backend idonei modificati sono gli stessi dei backend idonei originali.

La tabella seguente riepiloga la procedura per creare l'insieme di backend idonei modificati quando l'opzione di affinità di zona è l'opzione ZONAL_AFFINITY_SPILL_CROSS_ZONE e il rapporto di overflow configurato non è 0.0:

Backend idonei originali (A) Backend di test di corrispondenza zonale (B) Backend corrispondenti a livello di zona (C) Intersezione (A∩C) Backend idonei modificati
Tutti i backend principali integri

Tutti i backend principali configurati

I backend di test di corrispondenza zonale potrebbero essere tutti integri o una combinazione di integri e non integri.

Tutti i backend principali nella zona del client

I backend corrispondenti alla zona potrebbero essere tutti integri, tutti non integri o una combinazione di integri e non integri.

 Tutti i backend primari integri nella zona del client

Rapporto calcolato ≥ rapporto di spillover: i backend idonei modificati sono tutti i backend primari integri nella zona del client.

Le nuove connessioni vengono distribuite all'interno della zona del client. I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali o un sottoinsieme di questi.

Rapporto calcolato < rapporto di overflow: i backend idonei modificati sono uguali ai backend idonei originali.

Le nuove connessioni potrebbero essere distribuite all'interno della zona del client o in altre zone.
Tutti i backend di failover integri

Tutti i backend di failover configurati

I backend di test di corrispondenza zonale potrebbero essere tutti integri o una combinazione di integri e non integri.

Tutti i backend di failover nella zona del client

I backend corrispondenti alla zona potrebbero essere tutti integri, tutti non integri o una combinazione di integri e non integri.

 Tutti i backend di failover integri nella zona del client

Rapporto calcolato ≥ rapporto di spillover: i backend di failover idonei modificati sono tutti i backend di failover integri nella zona del client.

Le nuove connessioni vengono distribuite all'interno della zona del client. I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali o un sottoinsieme di questi.

Rapporto calcolato < rapporto di overflow: i backend idonei modificati sono uguali a quelli idonei originali.

Le nuove connessioni potrebbero essere distribuite all'interno della zona del client o in altre zone.
Tutti i backend principali in stato non integro

Tutti i backend principali configurati

Per definizione, tutti i backend di test di corrispondenza zonale non sono integri quando tutti i backend primari idonei originali non sono integri.

Tutti i backend principali non integri nella zona del client

 Tutti i backend principali non integri nella zona del client

Il rapporto calcolato è sempre ≥ del rapporto di spillover: i backend idonei modificati sono tutti i backend principali non integri nella zona del client.

Le nuove connessioni vengono distribuite all'interno della zona del client. I backend idonei modificati potrebbero essere gli stessi dei backend idonei originali o un sottoinsieme di questi.

Esempi di rapporto di spillover

I seguenti esempi mostrano come funziona ZONAL_AFFINITY_SPILL_CROSS_ZONE.

  • Un rapporto di spillover di 1.0 significa quanto segue:

    • Quando l'intersezione dei backend corrispondenti a livello di zona e dei backend idonei originali è lo stesso insieme dei backend corrispondenti a livello di zona, i backend idonei modificati sono l'insieme di intersezione.
    • Quando l'intersezione dei backend corrispondenti alla zona e dei backend idonei originali non è lo stesso insieme dei backend corrispondenti alla zona, i backend idonei modificati sono gli stessi dei backend idonei originali.

  • Un rapporto di spillover di 0.8 significa quanto segue:

    • Quando il numero di backend nell'intersezione dei backend con corrispondenza zonale e dei backend idonei originali è almeno l'80% del numero di backend con corrispondenza zonale, i backend idonei modificati sono l'insieme di intersezione.
    • Quando il numero di backend nell'intersezione dei backend con corrispondenza zonale e dei backend idonei originali è inferiore all'80% del numero di backend con corrispondenza zonale, i backend idonei modificati sono uguali ai backend idonei originali.

  • Un rapporto di spillover di 0.0 significa quanto segue:

    • Se l'intersezione dei backend con corrispondenza zonale e dei backend idonei originali non è vuota, i backend idonei modificati sono l'insieme di intersezione.
    • Se l'intersezione dei backend corrispondenti zonali e dei backend idonei originali è vuota, i backend idonei modificati sono uguali ai backend idonei originali.

Considera la seguente configurazione in cui un bilanciatore del carico di rete passthrough interno è configurato con un'opzione di affinità di zona ZONAL_AFFINITY_SPILL_CROSS_ZONE con un rapporto di overflow di 0.8:

  • Backend configurati: dieci backend principali (cinque nella zona 1, cinque nella zona 2)
  • Backend originali idonei: tutti i backend principali integri (otto backend: cinque nella zona 1 e tre nella zona 2)
  • Backend di test di corrispondenza zonale: tutti i dieci backend principali configurati
esempio di affinità di zona del bilanciatore del carico di rete passthrough interno.
Traffico moderato che si riversa in una zona diversa (fai clic per ingrandire).

Scenario A: client compatibile nella zona 1

  • Backend corrispondenti a livello di zona: cinque backend nella zona 1.
  • Intersezione: l'intersezione tra i backend corrispondenti zonali e i backend idonei originali è costituita dai cinque backend integri nella zona 1.
  • Rapporto calcolato: 5 / 5 = 1,0
  • Risultato: poiché il rapporto calcolato di 1,0 ≥ 0,8, i backend idonei modificati si trovano nell'insieme di intersezione, ovvero tutti e cinque i backend principali integri nella zona 1 del client. Le nuove connessioni vengono distribuite esclusivamente all'interno della zona del client.

Scenario B: client compatibile nella zona 2

  • Backend corrispondenti a livello di zona: cinque backend nella zona 2.
  • Intersezione: l'intersezione tra i backend corrispondenti zonali e i backend idonei originali è costituita dai tre backend integri nella zona 2.
  • Rapporto calcolato: 3 / 5 = 0,6
  • Risultato: poiché il rapporto calcolato di 0,6 < 0,8, i backend idonei modificati sono i backend idonei originali. I backend idonei originali sono gli otto backend integri (cinque nella zona 1 e tre nella zona 2). Le nuove connessioni vengono distribuite nella zona 1 o nella zona 2.

Passaggi successivi