Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni

Questa pagina spiega i concetti relativi alla modalità di distribuzione del traffico dei bilanciatori del carico di rete passthrough esterni.

Selezione del backend e monitoraggio delle connessioni

La selezione del backend e il monitoraggio delle connessioni funzionano insieme per bilanciare più connessioni su backend diversi e per instradare tutti i pacchetti per ogni connessione allo stesso backend. Questo risultato si ottiene con una strategia in due parti. Per prima cosa, viene selezionato un backend utilizzando l'hashing coerente. Questa selezione viene registrata in una tabella di monitoraggio delle connessioni.

I seguenti passaggi acquisiscono il processo di selezione del backend e di monitoraggio della connessione.

1. Controllare se esiste una voce nella tabella di monitoraggio della connessione per utilizzare un backend selezionato in precedenza

Per una connessione esistente, il bilanciatore del carico utilizza la tabella di monitoraggio delle connessioni per identificare il backend selezionato in precedenza per quella connessione.

Il bilanciatore del carico tenta di abbinare ogni pacchetto bilanciato con una voce nella tabella di monitoraggio delle connessioni utilizzando la seguente procedura:

  • Se il pacchetto è un pacchetto TCP con il flag SYN:

    • Se la modalità di monitoraggio della connessione del bilanciatore del carico è PER_CONNECTION, vai al passaggio Identifica i backend idonei. Nella modalità di monitoraggio PER_CONNECTION, un pacchetto TCP con il flag SYN rappresenta sempre una nuova connessione, indipendentemente dall'affinità sessione configurata.

    • Se la modalità di monitoraggio delle connessioni del bilanciatore del carico è PER_SESSION e l'affinità sessione è NONE o CLIENT_IP_PORT_PROTO, vai al passaggio Identifica i backend idonei. In modalità di monitoraggio PER_SESSION, un pacchetto TCP con il flag SYN rappresenta una nuova connessione solo quando si utilizza una delle opzioni di affinità sessione a 5 tuple (NONE o CLIENT_IP_PORT_PROTO).

  • Se l'affinità sessione configurata non supporta il monitoraggio della connessione per il protocollo del pacchetto, vai al passaggio Identifica i backend idonei. Per informazioni sui protocolli di cui è possibile monitorare la connessione, consulta la tabella nella sezione Modalità di monitoraggio delle connessioni.

  • Per tutti gli altri pacchetti, il bilanciatore del carico verifica se il pacchetto corrisponde a una voce esistente nella tabella di monitoraggio delle connessioni. La tupla di connessione (un insieme di caratteristiche del pacchetto) utilizzata per confrontare il pacchetto con le voci esistenti della tabella di monitoraggio delle connessioni dipende dalla modalità di monitoraggio delle connessioni e dall'affinità di sessione che hai configurato. Per informazioni sulla tupla di connessione utilizzata per il monitoraggio delle connessioni, consulta la tabella nella sezione Modalità di monitoraggio delle connessioni.

    • Se il pacchetto corrisponde a una voce della tabella di monitoraggio della connessione, il bilanciatore del carico invia il pacchetto al backend selezionato in precedenza.

    • Se il pacchetto non corrisponde a una voce della tabella di monitoraggio delle connessioni, continua con il passaggio Identifica i backend idonei.

    Per informazioni sulla durata di un'entrata della tabella di monitoraggio delle connessioni e in quali condizioni persiste, consulta il passaggio Crea un'entrata della tabella di monitoraggio delle connessioni.

2. Seleziona un backend idoneo per una nuova connessione

Per una nuova connessione, il bilanciatore del carico utilizza l'algoritmo di hashing coerente per selezionare un backend tra quelli idonei.

I seguenti passaggi descrivono la procedura per selezionare un backend idoneo per una nuova connessione e quindi registrare la connessione in una tabella di monitoraggio delle connessioni.

2.1 Identificare i backend idonei

Questo passaggio modella i backend candidati a ricevere nuove connessioni, tenendo conto dell'integrità, del bilanciamento del carico ponderato e della configurazione dei criteri di failover.

La tabella seguente descrive in che modo il criterio di failover e il bilanciamento del carico ponderato influenzano i backend idonei.

Policy di failover Bilanciamento del carico ponderato Backend idonei
Consulta Nessuna policy di failover, bilanciamento del carico ponderato disattivato
Consulta Nessuna policy di failover, bilanciamento del carico ponderato abilitato
Consulta Criterio di failover configurato, bilanciamento del carico ponderato disattivato
Consulta Criterio di failover configurato, bilanciamento del carico ponderato abilitato

Nessuna policy di failover, bilanciamento del carico ponderato disattivato

Il set di backend idonei dipende solo dai controlli di integrità:

  • Quando almeno un backend è integro, l'insieme di backend idonei è costituito da tutti i backend integri.

  • Quando tutti i backend non sono integri, l'insieme di backend idonei è costituito da tutti i backend.

Nessuna policy di failover, bilanciamento del carico ponderato abilitato

L'insieme dei backend idonei dipende sia dai controlli di integrità sia dai pesi e consiste nel primo dei seguenti elementi non vuoto:

  • Tutti i backend integri con peso diverso da zero
  • Tutti i backend non integri con peso diverso da zero
  • Tutti i backend integri e con peso pari a zero
  • Tutti i backend in stato non integro e con peso pari a zero

Policy di failover configurata, bilanciamento del carico ponderato disabilitato

Il set di backend idonei dipende dai controlli di integrità e dalla configurazione della policy di failover:

  • Quando almeno un backend è integro, l'insieme dei backend idonei viene definito come segue, utilizzando la prima condizione vera di questo elenco ordinato:

    • Se non sono presenti backend primari integri, i backend idonei sono tutti i backend di failover integri.
    • Se non sono presenti backend di failover integri, i backend idonei sono tutti i backend primari integri.
    • Se il rapporto di failover è impostato su 0.0 (il valore predefinito), i backend idonei sono tutti i backend primari integri.
    • Se il rapporto tra il numero di backend primari integri e il numero totale di backend primari è maggiore o uguale al rapporto di failover configurato, i backend idonei sono costituiti da tutti i backend primari integri.
    • I backend idonei sono costituiti da tutti i backend di failover integri.
  • Quando non ci sono backend integri, l'insieme dei backend idonei è definito come segue:

    • Se il criterio di failover del bilanciatore del carico è configurato per eliminare le nuove connessioni quando nessun backend è integro, l'insieme dei backend idonei è vuoto. Il bilanciatore del carico elimina i pacchetti per le nuove connessioni.
    • Se la policy di failover del bilanciatore del carico non è configurata per eliminare le nuove connessioni quando nessun backend è integro, i controlli di integrità non sono pertinenti. I backend idonei sono costituiti da tutti i backend principali.

Criterio di failover configurato, bilanciamento del carico ponderato abilitato

Il set di backend idonei dipende dai controlli di integrità, dai pesi e dalla configurazione della policy di failover:

  • Quando almeno un backend è integro e ha un peso diverso da zero, l'insieme dei backend idonei è definito come segue, utilizzando la prima condizione vera di questo elenco ordinato:

    • Se non sono presenti backend primari integri con peso diverso da zero, i backend idonei sono tutti i backend di failover integri con peso diverso da zero.
    • Se non sono presenti backend di failover integri con peso diverso da zero, i backend idonei sono tutti i backend primari integri con peso diverso da zero.
    • Se il rapporto di failover è impostato su 0.0 (il valore predefinito), i backend idonei sono tutti i backend primari integri e con peso diverso da zero.
    • Se il rapporto tra il numero di backend primari integri con peso diverso da zero e il numero totale di backend primari è maggiore o uguale al rapporto di failover configurato, i backend idonei sono costituiti da tutti i backend primari integri con peso diverso da zero.
    • I backend idonei sono costituiti da tutti i backend di failover integri e con peso diverso da zero.
  • Quando non sono presenti backend integri con peso diverso da zero, l'insieme dei backend idonei è definito come segue:

    • Se il criterio di failover del bilanciatore del carico è configurato per eliminare le nuove connessioni quando nessun backend è integro, l'insieme dei backend idonei è vuoto. Il bilanciatore del carico elimina i pacchetti per le nuove connessioni.
    • Se la policy di failover del bilanciatore del carico non è configurata per eliminare le nuove connessioni quando nessun backend è integro, l'insieme di backend idonei è il primo dei seguenti che non è vuoto:

      • Tutti i backend principali in stato non integro con peso diverso da zero
      • Tutti i backend di failover non integri e con peso diverso da zero
      • Tutti i backend principali integri con peso pari a zero
      • Tutti i backend integri, con failover zero
      • Tutti i backend principali non integri e con peso zero
      • Tutti i backend di failover in stato non integro e con peso zero

2.2 Selezionare un servizio di backend idoneo

Il bilanciatore del carico utilizza l'hashing coerente per selezionare un backend idoneo. Il bilanciatore del carico mantiene gli hash dei backend idonei, mappati a un cerchio unitario. Il bilanciamento del carico ponderato modifica la mappatura dei backend idonei al cerchio in modo che i backend con pesi maggiori abbiano più probabilità di essere selezionati, in proporzione ai loro pesi.

Quando elabora un pacchetto per una connessione che non è presente nella tabella di monitoraggio delle connessioni, il bilanciatore del carico calcola un hash delle caratteristiche del pacchetto e lo mappa allo stesso cerchio unitario, selezionando un backend idoneo sulla circonferenza del cerchio. L'insieme di caratteristiche del pacchetto utilizzato per calcolare l'hash del pacchetto è definito dall'impostazione di affinità di sessione.

  • Se l'affinità sessione non è configurata in modo esplicito, l'affinità di sessione NONE è quella predefinita.

  • I due esempi seguenti mostrano in che modo il bilanciamento del carico ponderato influisce sulla selezione di un backend idoneo:

    • Se il servizio di backend ha due backend idonei, il primo con peso 1 e il secondo con peso 4, il primo backend idoneo ha una probabilità di selezione del 20% (1÷(1+4)) e il secondo backend idoneo ha una probabilità di selezione dell'80% (4÷(1+4)).

    • Se il servizio di backend ha tre backend idonei: il backend idoneo a con peso 0, il backend idoneo b con peso 2 e il backend idoneo c con peso 6, il backend a ha una probabilità di selezione dello 0% (0÷(0+2+6)), il backend b ha una probabilità di selezione del 25% (2÷(0+2+6)) e il backend c ha una probabilità di selezione del 75% (6÷(0+2+6)).

  • Il bilanciatore del carico assegna nuove connessioni ai backend idonei in modo il più coerente possibile anche se il numero di backend idonei o i relativi pesi cambiano. I seguenti vantaggi dell'hashing coerente mostrano come il bilanciatore del carico seleziona i backend idonei per le possibili nuove connessioni che non hanno voci nella tabella di monitoraggio delle connessioni:

    • Il bilanciatore del carico seleziona lo stesso backend per tutte le nuove connessioni possibili che hanno caratteristiche dei pacchetti identiche, come definito dallaffinità sessione, nelle seguenti situazioni:

      • Se il bilanciamento del carico ponderato non è configurato, quando l'insieme di backend idonei non cambia.

      • Se è configurato il bilanciamento del carico ponderato, quando l'insieme di backend idonei non cambia, e il peso di ogni backend idoneo rimane costante.

    • Il bilanciatore del carico distribuisce le possibili nuove connessioni tra i backend idonei nel modo più equo possibile:

      • Se il bilanciamento del carico ponderato non è configurato, circa 1/N possibili nuove connessioni vengono mappate a ogni backend idoneo, dove N è il conteggio dei backend idonei.

      • Se è configurato il bilanciamento del carico ponderato, il rapporto tra le possibili nuove connessioni che vengono mappate a ogni backend idoneo è approssimativamente: la ponderazione di un backend idoneo divisa per la somma di tutte le ponderazioni dei backend idonei.

      • Se un backend idoneo viene aggiunto, rimosso o il suo peso cambia, l'hashing coerente mira a ridurre al minimo l'interruzione dei mapping agli altri backend idonei, ovvero la maggior parte delle connessioni che vengono mappate ad altri backend idonei continua a essere mappata allo stesso backend idoneo.

2.3 Creare una voce della tabella di monitoraggio delle connessioni

Dopo aver selezionato un backend, il bilanciatore del carico crea una voce della tabella di monitoraggio delle connessioni se l'affinità sessione configurata supporta il monitoraggio delle connessioni per il protocollo del pacchetto.

  • Se l'affinità sessione configurata non supporta il monitoraggio della connessione per il protocollo del pacchetto, ignora questo passaggio.

  • Se l'affinità sessione configurata supporta il monitoraggio della connessione per il protocollo del pacchetto, la voce della tabella di monitoraggio della connessione creata mappa le caratteristiche del pacchetto al backend selezionato. I campi dell'intestazione del pacchetto utilizzati per questa mappatura dipendono dalla modalità di monitoraggio della connessione e dall'affinità sessione che hai configurato.

Per informazioni sui protocolli tracciabili in base alle tue scelte di configurazione e sulle caratteristiche dei pacchetti utilizzate per l'hash, consulta la sezione Modalità di monitoraggio della connessione.

Il bilanciatore del carico rimuove le voci della tabella di monitoraggio della connessione in base alle seguenti regole:

  • Una voce della tabella di monitoraggio della connessione viene rimossa dopo 60 secondi di inattività della connessione. Per ulteriori informazioni, vedi Timeout inattività.

  • Le voci della tabella di monitoraggio delle connessioni non vengono rimosse quando una connessione TCP viene chiusa con un pacchetto FIN o RST. Qualsiasi nuova connessione TCP trasporta sempre il flag SYN e viene elaborata come descritto nel passaggio Controlla una voce della tabella di monitoraggio delle connessioni.

  • Se è configurata una policy di failover e l'impostazione di svuotamento della connessione al failover e failback è disattivata, il bilanciatore del carico rimuove tutte le voci nella tabella di monitoraggio delle connessioni quando i backend idonei passano da quelli primari a quelli di failover (failover) o da quelli di failover a quelli primari (failback). Per saperne di più, vedi Svuotamento connessioni al failover e al failback.

  • Le voci nella tabella di monitoraggio delle connessioni possono essere rimosse se un backend diventa non integro. Questo comportamento dipende dalla modalità di monitoraggio delle connessioni, dal protocollo e dall'impostazione di persistenza della connessione su backend in stato non integro. Per saperne di più, vedi Persistenza della connessione su backend in stato non integro.

  • Le voci nella tabella di monitoraggio delle connessioni vengono rimosse dopo il timeout di svuotamento della connessione che si verifica in seguito a un evento come l'eliminazione di una VM di backend o la rimozione di una VM di backend da un gruppo di istanze o da un NEG. Per saperne di più, vedi Attivare lo svuotamento delle connessioni.

Affinità sessione

L'affinità di sessione controlla la distribuzione delle nuove connessioni dai client ai backend del bilanciatore del carico. I bilanciatori del carico di rete passthrough esterni utilizzano l'affinità sessione per selezionare un backend da un insieme di backend idonei, come descritto nei passaggi Identifica i backend idonei e Seleziona un backend idoneo nella sezione Selezione del backend e monitoraggio della connessione. Configuri l'affinità sessione sul servizio di backend, non su ogni gruppo di istanze o NEG di backend.

I bilanciatori del carico di rete passthrough esterni supportano le seguenti impostazioni di affinità sessione. Ogni impostazione di affinità sessione utilizza l'hashing coerente per selezionare un backend idoneo. L'impostazione dell'affinità sessione determina quali campi delle intestazioni IP e TCP/UDP vengono utilizzati per calcolare l'hash.

Metodo hash per la selezione del backend Impostazione dell'affinità sessione1

Hash a 5 tuple (composto da indirizzo IP di origine, porta di origine, protocollo, indirizzo IP di destinazione e porta di destinazione) per pacchetti non frammentati che includono informazioni sulla porta, come pacchetti TCP e pacchetti UDP non frammentati

OR

Hash a tre tuple (composto da indirizzo IP di origine, indirizzo IP di destinazione e protocollo) per pacchetti UDP frammentati e pacchetti di tutti gli altri protocolli

NONE2

Hash a 5 tuple (composto da indirizzo IP di origine, porta di origine, protocollo, indirizzo IP di destinazione e porta di destinazione) per pacchetti non frammentati che includono informazioni sulla porta, come pacchetti TCP e pacchetti UDP non frammentati

OR

Hash a tre tuple (composto da indirizzo IP di origine, indirizzo IP di destinazione e protocollo) per pacchetti UDP frammentati e pacchetti di tutti gli altri protocolli

CLIENT_IP_PORT_PROTO
Hash a 3 tuple
(formato da indirizzo IP di origine, indirizzo IP di destinazione e protocollo)
CLIENT_IP_PROTO
Hash a due tuple
(formato da indirizzo IP di origine e indirizzo IP di destinazione)
CLIENT_IP
1 Queste affinità di sessione sono supportate dai bilanciatori del carico di rete passthrough esterni basati sui servizi di backend. I bilanciatori del carico di rete passthrough esterni basati su pool di destinazione non utilizzano servizi di backend e supportano meno opzioni di affinità sessione. Per i bilanciatori del carico di rete passthrough esterni basati su pool di destinazione, imposti il parametro session affinity su ogni pool di destinazione.

2 Un'impostazione di affinità sessione pari a NONE non significa che non esiste affinità sessione. Significa che non è configurata esplicitamente alcuna opzione di affinità sessione.

L'hashing viene sempre eseguito per selezionare un backend. Un'impostazione di affinità di sessione di NONE significa che il bilanciatore del carico utilizza un hash a 5 tuple o a 3 tuple per selezionare i backend, ovvero lo stesso comportamento di quando è impostato CLIENT_IP_PORT_PROTO.

Per informazioni su come le diverse impostazioni di affinità sessione influiscono sui metodi di selezione del backend e di monitoraggio delle connessioni, consulta la tabella nella sezione Modalità di monitoraggio delle connessioni.

Policy di tracciamento delle connessioni

Questa sezione descrive le impostazioni che controllano il comportamento del monitoraggio della connessione dei bilanciatori del carico di rete passthrough esterni. Un criterio di monitoraggio delle connessioni include le seguenti impostazioni:

Modalità di tracciamento delle connessioni

Quando è possibile il monitoraggio delle connessioni, la tabella di monitoraggio delle connessioni del bilanciatore del carico mappa le tuple di connessione ai backend selezionati in precedenza in una tabella hash. L'insieme delle caratteristiche dei pacchetti che compongono ogni tupla di connessione dipende dalla modalità di monitoraggio della connessione e dall'affinità sessione.

I bilanciatori del carico di rete passthrough esterni supportano il monitoraggio delle connessioni in base alle opzioni di affinità di protocollo e sessione:

  • Le connessioni TCP sono sempre tracciabili per tutte le opzioni di affinità sessione.

  • Le connessioni UDP, ESP e GRE sono tracciabili per tutte le opzioni di affinità di sessione ad eccezione di NONE.

  • Tutti gli altri protocolli, come ICMP e ICMPv6, non sono tracciabili per la connessione.

La modalità di monitoraggio delle connessioni si riferisce alla granularità di ogni tupla di connessione nella tabella di monitoraggio delle connessioni del bilanciatore del carico. La tupla di connessione può essere a 5 tuple o a 3 tuple (modalità PER_CONNECTION) oppure può corrispondere all'impostazione di affinità di sessione (modalità PER_SESSION).

  • PER_CONNECTION. Questa è la modalità di monitoraggio della connessione predefinita. Questa modalità di monitoraggio delle connessioni utilizza un hash a 5 tuple o un hash a 3 tuple. I pacchetti non frammentati che includono informazioni sulla porta come i pacchetti TCP e i pacchetti UDP non frammentati vengono monitorati con hash a 5 tuple. Tutti gli altri pacchetti vengono monitorati con hash a 3 tuple.

  • PER_SESSION. Questa modalità di monitoraggio della connessione utilizza un hash costituito dalle stesse caratteristiche del pacchetto utilizzate dall'hash di affinità sessione. A seconda dell'affinità sessione scelta, PER_SESSION può comportare connessioni che corrispondono più frequentemente a una voce della tabella di monitoraggio delle connessioni esistente, riducendo la frequenza con cui un backend deve essere selezionato dall'hash di affinità sessione.

La tabella seguente riepiloga il funzionamento combinato della modalità di monitoraggio delle connessioni e dell'affinità sessione per indirizzare tutti i pacchetti di ogni connessione allo stesso backend.

Selezione del backend tramite l'affinità sessione Modalità di tracciamento delle connessioni
Impostazione dell'affinità sessione Metodo hash per la selezione del backend PER_CONNECTION (valore predefinito) PER_SESSION
Predefinito

(NONE)

TCP e UDP non frammentato:hash a 5 tuple

UDP frammentato e tutti gli altri protocolli: hash di 3 tuple

  • TCP:monitoraggio della connessione a 5 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
  • TCP: monitoraggio delle connessioni a 5 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
IP client, IP di destinazione

(CLIENT_IP)

Tutti i protocolli:hash a 2 tuple
  • TCP e UDP non frammentato:monitoraggio della connessione a 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio della connessione a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
  • TCP, UDP, ESP, GRE: monitoraggio delle connessioni a 2 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
IP client, IP di destinazione, protocollo

(CLIENT_IP_PROTO)

Tutti i protocolli:hash a 3 tuple
  • TCP e UDP non frammentato:monitoraggio della connessione a 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio della connessione a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
  • TCP, UDP, ESP, GRE: monitoraggio della connessione a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
IP client, porta client, IP di destinazione, porta di destinazione, protocollo

(CLIENT_IP_PORT_PROTO)

TCP e UDP non frammentato:hash a 5 tuple

UDP frammentato e tutti gli altri protocolli: hash di 3 tuple

  • TCP e UDP non frammentato:monitoraggio della connessione a 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio della connessione a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
  • TCP e UDP non frammentato:monitoraggio della connessione a 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio della connessione a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato

Per scoprire come modificare la modalità di monitoraggio della connessione, consulta Configurare un criterio di monitoraggio della connessione.

Persistenza della connessione su backend in stato non integro

Le impostazioni di persistenza della connessione controllano se una connessione esistente persiste su una VM o un endpoint di backend selezionato dopo che il backend diventa non integro, a condizione che rimanga nel gruppo di backend configurato del bilanciatore del carico (in un gruppo di istanze o un NEG).

Sono disponibili le seguenti opzioni di persistenza della connessione:

  • DEFAULT_FOR_PROTOCOL (valore predefinito)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

La tabella seguente riassume le opzioni di persistenza della connessione e la modalità di persistenza delle connessioni per diversi protocolli, opzioni di affinità sessione e modalità di monitoraggio.

Opzione Persistenza della connessione su backend in stato non integro Modalità di tracciamento delle connessioni
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP: le connessioni persistono sui backend in stato non integro (tutte le affinità sessione)

Tutti gli altri protocolli: le connessioni non vengono mai mantenute su backend in stato non integro

TCP:le connessioni persistono sui backend in stato non integro se l'affinità sessione è NONE o CLIENT_IP_PORT_PROTO

Tutti gli altri protocolli: le connessioni non vengono mai mantenute su backend in stato non integro

NEVER_PERSIST Tutti i protocolli: le connessioni non vengono mai mantenute sui backend in stato non integro
ALWAYS_PERSIST

TCP: le connessioni persistono sui backend in stato non integro (tutte le affinità sessione)

ESP, GRE, UDP: le connessioni persistono sui backend in stato non integro se l'affinità sessione non è NONE

ICMP, ICMPv6:non applicabile perché non sono tracciabili

Questa opzione deve essere utilizzata solo per casi d'uso avanzati.

Configurazione non possibile

Comportamento di persistenza della connessione TCP sui backend in stato non integro

Ogni volta che una connessione TCP con monitoraggio a 5 tuple persiste su un backend in stato non integro:

  • Se il backend non integro continua a rispondere ai pacchetti, la connessione continua finché non viene reimpostata o chiusa (dal backend non integro o dal client).
  • Se il backend non integro invia un pacchetto di ripristino TCP (RST) o non risponde ai pacchetti, il client potrebbe riprovare con una nuova connessione, consentendo al bilanciatore del carico di selezionare un backend diverso e integro. I pacchetti TCP SYN selezionano sempre un nuovo backend integro.

Per scoprire come modificare il comportamento di persistenza della connessione, consulta Configurare un criterio di monitoraggio delle connessioni.

Timeout di inattività

Le voci nelle tabelle di monitoraggio delle connessioni scadono 60 secondi dopo che il bilanciatore del carico elabora l'ultimo pacchetto corrispondente alla voce. Questo valore di timeout per inattività non può essere modificato.

Bilanciamento del carico ponderato

Il bilanciamento del carico ponderato per i bilanciatori del carico di rete passthrough esterni utilizza le informazioni sul peso riportate da un controllo di integrità HTTP. Il bilanciamento del carico ponderato richiede la configurazione di tutti i seguenti elementi:

  • Il criterio di località del bilanciatore del carico del servizio di backend (localityLbPolicy) deve essere WEIGHTED_MAGLEV.
  • Il servizio di backend deve utilizzare un controllo di integrità HTTP.
  • Le risposte del controllo di integrità di ogni VM di backend o endpoint di backend devono contenere un'intestazione della risposta HTTP personalizzata. Il nome del campo di intestazione della risposta è X-Load-Balancing-Endpoint-Weight e i valori validi del campo vanno da 0 a 1000.

Se devi utilizzare lo stesso gruppo di istanze o NEG come backend per due o più servizi di backend, ti consigliamo la seguente strategia in modo che ciascuna delle istanze o degli endpoint di backend comuni possa fornire informazioni sul peso univoche per ogni servizio di backend:

  • Utilizza un controllo di integrità HTTP univoco per ogni servizio di backend. Ad esempio, utilizza un parametro di controllo di integrità request-path univoco.
  • Configura le istanze o gli endpoint di backend in modo che rispondano con informazioni sul peso appropriate per ogni controllo di integrità.

Quando utilizzi il bilanciamento del carico ponderato, il bilanciatore del carico classifica le VM o gli endpoint di backend in base al peso, che deve essere maggiore di zero o uguale a zero, e poi in base ai controlli di integrità. Lo stato del controllo di integrità è determinato dai criteri di esito positivo per i controlli di integrità HTTP, HTTPS e HTTP/2.

Peso Sano o malsano Rango
Ponderazione maggiore di zero Stato integro Prima scelta
Ponderazione maggiore di zero Stato non integro Seconda scelta
Il peso è uguale a zero Stato integro Terza scelta
Il peso è uguale a zero Stato non integro Quarta (ultima) opzione

Per ulteriori informazioni su come il bilanciamento del carico ponderato influisce sui backend idonei, consulta i passaggi Identifica i backend idonei e Seleziona un backend idoneo nella sezione Selezione del backend e monitoraggio della connessione.

Il bilanciamento del carico ponderato può essere utilizzato nei seguenti scenari:

  • Se alcune connessioni elaborano più dati di altre o se alcune connessioni durano più a lungo di altre, la distribuzione del carico di backend potrebbe diventare irregolare. Segnalando un peso inferiore per istanza, un'istanza con carico elevato può ridurre la sua quota di nuove connessioni, continuando a gestire le connessioni esistenti.

  • Se un backend è sovraccarico e l'assegnazione di più connessioni potrebbe interrompere le connessioni esistenti, questi backend si assegnano un peso pari a zero. Se segnali un peso pari a zero, un'istanza di backend interrompe la gestione di nuove connessioni, ma continua a gestire quelle esistenti.

  • Se un backend sta esaurendo le connessioni esistenti prima della manutenzione, si assegna un peso pari a zero. Se viene segnalato un peso pari a zero, l'istanza di backend interrompe la gestione di nuove connessioni, ma continua a gestire quelle esistenti.

Per saperne di più, consulta Configurare il bilanciamento del carico ponderato.

Svuotamento della connessione

Lo svuotamento delle connessioni fornisce un periodo di tempo aggiuntivo configurabile per le connessioni stabilite da conservare nella tabella di monitoraggio delle connessioni del bilanciatore del carico quando si verifica una delle seguenti azioni:

  • Un'istanza di macchina virtuale (VM) viene rimossa da un gruppo di istanza di backend (incluso l'abbandono di un'istanza in un gruppo di istanze gestite di backend)
  • Una VM viene arrestata o eliminata (incluse le azioni automatiche come gli aggiornamenti in sequenza o la riduzione delle dimensioni di un gruppo di istanze gestite di backend)
  • Un endpoint viene rimosso da un gruppo di endpoint di rete (NEG) di backend

Per impostazione predefinita, svuotamento della connessione per le azioni sopra menzionate è disattivato. Per informazioni su come viene attivato svuotamento della connessione e su come abilitarlo, vedi Abilitazione dello svuotamento delle connessioni.

Frammentazione UDP

I bilanciatori del carico di rete passthrough esterni basati sui servizi di backend possono elaborare pacchetti UDP frammentati e non frammentati. Se la tua applicazione utilizza pacchetti UDP frammentati, tieni presente quanto segue:

  • I pacchetti UDP potrebbero essere frammentati prima di raggiungere una rete VPC. Google Cloud
  • Google Cloud Le reti VPC inoltrano i frammenti UDP man mano che arrivano (senza attendere l'arrivo di tutti i frammenti).
  • Le reti nonGoogle Cloud e le apparecchiature di rete on-premise potrebbero inoltrare i frammenti UDP man mano che arrivano, ritardare i pacchetti UDP frammentati fino all'arrivo di tutti i frammenti o scartare i pacchetti UDP frammentati. Per maggiori dettagli, consulta la documentazione del provider di rete o delle apparecchiature di rete.

Se prevedi pacchetti UDP frammentati e devi indirizzarli agli stessi backend, utilizza i seguenti parametri di configurazione del servizio di backend e della regola di forwarding:

  • Configurazione della regola di forwarding:utilizza una sola regola di forwarding UDP o L3_DEFAULT per indirizzo IP bilanciato del carico e configura la regola di forwarding in modo che accetti il traffico su tutte le porte. In questo modo, tutti i frammenti arrivano alla stessa regola di forwarding. Anche se i pacchetti frammentati (diversi dal primo frammento) non hanno una porta di destinazione, la configurazione dellaregola di forwardingo per elaborare il traffico per tutte le porte consente anche di ricevere frammenti UDP che non contengono informazioni sulla porta. Per configurare tutte le porte, utilizza Google Cloud CLI per impostare --ports=ALL o utilizza l'API per impostare allPorts su True.

  • Configurazione del servizio di backend:imposta l'affinità di sessione del servizio di backend su CLIENT_IP (hash a 2 tuple) o CLIENT_IP_PROTO (hash a 3 tuple) in modo che venga selezionato lo stesso backend per i pacchetti UDP che includono informazioni sulla porta e per i frammenti UDP (diversi dal primo frammento) che non includono informazioni sulla porta. Imposta la modalità di monitoraggio delle connessioni del servizio di backend su PER_SESSION in modo che le voci della tabella di monitoraggio delle connessioni vengano create utilizzando gli stessi hash a 2 o 3 tuple.

Failover

Puoi configurare un bilanciatore del carico di rete passthrough esterno per distribuire le connessioni tra le istanze VM o gli endpoint nei backend principali (gruppi di istanze o NEG) e poi passare, se necessario, all'utilizzo dei backend di failover. Il failover fornisce un altro metodo per aumentare la disponibilità, offrendo al contempo un maggiore controllo su come gestire il carico di lavoro quando i backend principali non sono integri.

Per impostazione predefinita, quando aggiungi un backend al servizio di backend di un bilanciatore del carico di rete passthrough esterno, questo backend è un backend principale. Puoi designare un backend come backend di failover quando lo aggiungi al servizio di backend del bilanciatore del carico o modificando il servizio di backend in un secondo momento.

Per saperne di più su come viene utilizzato il failover per la selezione del backend e il monitoraggio delle connessioni, consulta i passaggi Identifica i backend idonei e Crea una voce della tabella di monitoraggio delle connessioni nella sezione Selezione del backend e monitoraggio delle connessioni.

Per ulteriori informazioni sul funzionamento del failover, consulta la Panoramica del failover per i bilanciatori del carico di rete passthrough esterni.

Passaggi successivi