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

I bilanciatori del carico di rete passthrough distribuiscono il traffico in entrata tra le istanze di backend disponibili. Questo documento spiega come il bilanciatore del carico seleziona i backend, monitora le connessioni e gestisce l'affinità sessione, il bilanciamento del carico ponderato e il failover.

Comprendere come interagiscono tutte queste funzionalità ti aiuta a ottimizzare la configurazione del bilanciamento del carico per ottenere prestazioni affidabili e un utilizzo efficiente delle risorse. Questi meccanismi sono fondamentali per le applicazioni che richiedono la persistenza della sessione, consentendo loro di mantenere un comportamento coerente per ogni interazione utente.

Selezione del backend e monitoraggio delle connessioni

La selezione del backend e il monitoraggio della connessione interagiscono per bilanciare più connessioni tra backend diversi e per instradare tutti i pacchetti di ogni connessione allo stesso backend. Questo obiettivo viene raggiunto con una strategia in due parti. Innanzitutto, viene selezionato un backend utilizzando l'hashing coerente. Questa selezione viene quindi registrata in una tabella di monitoraggio delle connessioni.

I seguenti passaggi descrivono la selezione del backend e il monitoraggio della connessione.

1. Controlla se è presente una voce nella tabella di monitoraggio della connessione

Il bilanciatore del carico determina se un pacchetto con bilanciamento del carico appartiene a una nuova connessione o a una connessione esistente utilizzando la seguente procedura:

• 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&#39affinità sessionee configurata.

  • Se la modalità di monitoraggio della connessione 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à di sessione a 5 tuple (NONE o CLIENT_IP_PORT_PROTO).

• Tutti gli altri pacchetti: il bilanciatore del carico controlla se il pacchetto corrisponde a una voce esistente della tabella di monitoraggio della connessione. La granularità dell'hash del pacchetto utilizzato per verificare la presenza di una voce della tabella di monitoraggio della connessione esistente dipende dalla modalità di monitoraggio della connessione e dall'affinità sessione configurate. Per saperne di più, 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 lo invia al backend selezionato in precedenza.

  • Se il pacchetto non corrisponde a una voce della tabella di monitoraggio della connessione, vai al passaggio Identifica i backend idonei.

  Per informazioni su quanto tempo persiste una voce della tabella di monitoraggio delle connessioni e in quali condizioni persiste, vedi il passaggio Gestisci le voci della tabella di monitoraggio delle connessioni.

2. Passaggi di selezione del backend

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

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

2.1 Identifica i backend idonei

I backend idonei sono quelli candidati a ricevere nuove connessioni. La tabella seguente definisce l'insieme di backend idonei a seconda che il bilanciatore del carico utilizzi il failover.

Failover	Backend idonei
	Quando la funzionalità di bilanciamento del carico di failover è disattivata, tutti i backend configurati sono backend principali. L'insieme di backend idonei è definito come segue: 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 dei backend idonei è costituito da tutti i backend.
	Quando la funzionalità di bilanciamento del carico di failover è abilitata, il bilanciatore del carico utilizza le informazioni del controllo di integrità e la configurazione della policy di failover per definire l'insieme di backend idonei: Quando almeno un backend (primario o di failover) è integro, i backend idonei sono quelli che provengono dal primo dei seguenti insiemi non vuoto: Se non sono presenti backend principali 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 principali integri. Se il rapporto di failover è impostato su 0.0 (il valore predefinito), i backend idonei sono tutti i backend principali integri. Se il rapporto tra il numero di backend principali integri e il numero totale di backend principali è maggiore o uguale al rapporto di failover configurato, i backend idonei sono tutti i backend principali integri. I backend idonei sono tutti i backend di failover integri. Quando non sono presenti backend integri (principale e di failover), l'insieme di backend idonei dipende esclusivamente dalla configurazione della policy di failover: Se il criterio di failover è configurato per eliminare le nuove connessioni quando tutti i backend primari e di failover non sono integri, l'insieme di backend idonei è vuoto. Di conseguenza, il bilanciatore del carico elimina i pacchetti per le nuove connessioni. Se la policy di failover non è configurata per eliminare le nuove connessioni quando tutti i backend principali e di failover non sono integri, i backend idonei sono tutti i backend principali non integri.

2.2 Regolare i backend idonei per l'affinità a livello di zona

Questo passaggio viene saltato se si verifica una delle seguenti condizioni:

• L'affinità a livello di zona è disattivata
• Il client è incompatibile con l'affinità zonale
• Una corrispondenza zonale con la zona di un client compatibile non si verifica

Se l'affinità di zona è abilitata, un client è compatibile con l'affinità di zona e si verifica una corrispondenza di zona, le nuove connessioni dal client vengono indirizzate a un insieme modificato di backend idonei. Per ulteriori informazioni, consulta le seguenti risorse:

• Come ZONAL_AFFINITY_STAY_WITHIN_ZONE funziona

• Come funzionano ZONAL_AFFINITY_SPILL_CROSS_ZONE e la percentuale di spillover

2.3 Seleziona un backend idoneo

Il bilanciatore del carico gestisce gli hash dei backend idonei, con ogni hash del backend mappato a un cerchio unitario.

Quando elabora un pacchetto per una connessione che non si trova 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 dei pacchetti utilizzato per calcolare l'hash dei pacchetti è definito dall'impostazione di affinità di sessione. Ad esempio, quando l'affinità sessione selezionata genera un hash di selezione del backend a 2 o 3 tuple, tutte le connessioni TCP da un indirizzo IP di origine vengono mappate allo stesso backend idoneo.

• Se non viene configurata esplicitamente un'affinità sessione, l'affinità di sessione NONE è quella predefinita.

• L'hashing coerente garantisce che il bilanciatore del carico assegni nuove connessioni ai backend idonei in modo da ridurre al minimo le interruzioni della mappatura, anche se il numero di backend idonei cambia.

  • Il bilanciatore del carico seleziona sempre lo stesso backend idoneo per una connessione e, più in generale, seleziona sempre lo stesso backend idoneo per tutti i pacchetti con caratteristiche identiche, come definito dall'impostazione di affinità di sessione, se l'insieme di backend idonei non cambia.

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

• Inoltre, l'hashing coerente garantisce che il bilanciatore del carico distribuisca le nuove connessioni tra i backend idonei nel modo più equo possibile. Per tutti gli hash dei pacchetti possibili, come definito dall'impostazione di affinità sessione configurata (e più nello specifico, per tutte le connessioni possibili quando l'affinità sessione genera un hash a 5 tuple per la selezione del backend):

  • Quando viene aggiunto un backend idoneo, circa 1/N nuove connessioni vengono mappate al backend appena aggiunto. In questo caso, N è il numero di backend dopo l'aggiunta del nuovo backend.

  • Quando viene rimosso un backend idoneo, circa 1/N nuove connessioni vengono mappate a uno dei N-1 backend rimanenti. In questa situazione, N è il conteggio dei backend prima della rimozione del backend idoneo.

2.4 Crea una voce della tabella di monitoraggio delle connessioni

Dopo aver selezionato un backend, il bilanciatore del carico crea una voce nella tabella di monitoraggio della connessione. La voce della tabella di monitoraggio delle connessioni mappa le caratteristiche dei pacchetti al backend selezionato. I campi dell'intestazione del pacchetto utilizzati per questa mappatura dipendono dalla modalità di monitoraggio della connessione e dall'affinità sessione configurate.

Per informazioni sulle caratteristiche dei pacchetti utilizzate per l'hash nella tabella di monitoraggio delle connessioni, consulta la tabella nella sezione Modalità di monitoraggio delle connessioni.

3. Gestisci le voci della tabella di monitoraggio delle connessioni

Il bilanciatore del carico gestisce le voci della tabella di monitoraggio delle connessioni in base ai seguenti eventi e regole:

• Le voci inattive vengono rimosse: una voce della tabella di monitoraggio della connessione viene rimossa dopo un determinato periodo di tempo se il bilanciatore del carico non elabora nuovi pacchetti in entrata. A meno che non configuri un timeout di inattività personalizzato, il bilanciatore del carico utilizza un timeout di inattività predefinito di 600 secondi. Per saperne di più, consulta Timeout di inattività.

• Le voci vengono rimosse quando le tabelle di monitoraggio delle connessioni client sono piene: le tabelle di monitoraggio delle connessioni per i bilanciatori del carico di rete passthrough interni sono implementate sui sistemi client, ad esempio un host che esegue un'istanza VM, un host che alimenta un collegamento VLAN o un host che esegue un tunnel Cloud VPN. Quando la tabella di monitoraggio delle connessioni di un client è piena, rimuove le voci relative alle connessioni utilizzate meno di recente.

• Connessioni TCP chiuse: le voci della tabella di monitoraggio della connessione per le connessioni TCP non vengono rimosse quando una connessione TCP viene chiusa con un pacchetto FIN o RST. Potrebbero essere rimosse in un secondo momento come voci inattive. Ogni nuova connessione TCP contiene sempre il flag SYN ed è soggetta all'elaborazione descritta nel passaggio Verifica la presenza di una voce nella tabella di monitoraggio della connessione.

• Quando le connessioni non vengono mantenute durante il failover: quando è configurato almeno un backend di failover e l'impostazione di svuotamento delle connessioni durante il failover è disattivata, il bilanciatore del carico rimuove tutte le voci nella tabella di monitoraggio delle connessioni dopo che l'insieme di backend idonei passa dai backend principali a quelli di failover, in base alle seguenti regole:

  • Il bilanciatore del carico non rimuove in modo proattivo le voci della tabella di monitoraggio della connessione nel momento in cui l'insieme di backend idonei passa dai backend principali a quelli di failover. Il bilanciatore del carico rimuove invece ogni voce della tabella di monitoraggio della connessione quando arriva un pacchetto successivo per la connessione, a condizione che l'insieme di backend idonei non sia tornato indietro.

  • Se l'insieme di backend idonei passa dai backend principali a quelli di failover e viceversa (ad esempio, da principale a failover, poi di nuovo a principale) e non sono arrivati pacchetti per la connessione tra gli eventi di passaggio, la voce della tabella di monitoraggio delle connessioni viene conservata, a meno che un altro motivo o evento non la rimuova.

  Per saperne di più, consulta Svuotamento della connessione in caso di failover.

• Quando le connessioni non persistono su backend non integri: quando la persistenza della connessione su backend non integri è disabilitata per il protocollo del pacchetto, il bilanciatore del carico rimuove le voci della tabella di monitoraggio delle connessioni sui backend non integri in base alle seguenti regole:

  • Il bilanciatore del carico non rimuove in modo proattivo le voci della tabella di monitoraggio della connessione a un backend selezionato in precedenza nel momento in cui il backend diventa in stato non integro. Il bilanciatore del carico rimuove una voce della tabella di monitoraggio della connessione quando arriva un pacchetto successivo per la connessione, a condizione che il backend selezionato in precedenza rimanga non integro. I pacchetti successivi per la connessione vengono trattati come una nuova connessione, perché il bilanciatore del carico seleziona un nuovo backend idoneo e crea una nuova voce della tabella di monitoraggio della connessione.

  • Se un backend selezionato in precedenza passa dallo stato integro a non integro e poi di nuovo a integro e non sono arrivati pacchetti per la connessione mentre il backend selezionato in precedenza era non integro, la voce della tabella di monitoraggio della connessione viene conservata, a meno che un altro motivo o evento non la rimuova.

• Svuotamento della connessione per i backend rimossi, arrestati o eliminati: se lo svuotamento della connessione per i backend rimossi, arrestati o eliminati è abilitato, le voci della tabella di monitoraggio della connessione vengono rimosse dopo un timeout di svuotamento della connessione configurabile. Il conteggio del timeout inizia quando viene ricevuto il comando per rimuovere (abbandonare), arrestare o eliminare un backend (inclusi i comandi di eliminazione che sono il risultato della riduzione delle dimensioni di un gruppo di istanze gestite). Se lo svuotamento della connessione per i backend rimossi, arrestati o eliminati è disattivato, le voci della tabella di monitoraggio delle connessioni vengono rimosse quando viene ricevuto il comando per rimuovere, arrestare o eliminare un backend. Per saperne di più, consulta Abilita lo svuotamento della connessione.

Affinità di sessione

L'impostazione di affinità sessione di un bilanciatore del carico di rete passthrough interno definisce l'hash del pacchetto per la selezione del backend e, in base alla modalità di monitoraggio della connessione, l'hash del pacchetto per il monitoraggio della connessione.

L'affinità sessione viene configurata sul servizio di backend, non su ogni gruppo di istanze o NEG di backend. L'affinità sessione determina quali intestazioni IP e di livello 4 vengono utilizzate per calcolare un hash delle caratteristiche dei pacchetti. L'hash delle caratteristiche del pacchetto viene utilizzato nei passaggi di selezione del backend.

I bilanciatori del carico di rete passthrough interni supportano le seguenti impostazioni di affinità sessione.

Metodo hash per la selezione del backend	Impostazione dell'affinità di sessione
Hash a 5 tuple (costituito da indirizzo IP di origine, porta di origine, protocollo, indirizzo IP di destinazione e porta di destinazione) per i pacchetti non frammentati che includono informazioni sulla porta (pacchetti TCP e pacchetti UDP non frammentati) OR Hash a 3 tuple (costituito da indirizzo IP di origine, indirizzo IP di destinazione e protocollo) per pacchetti UDP frammentati e pacchetti di tutti gli altri protocolli	NONE1 OPPURE CLIENT_IP_PORT_PROTO
Hash a 3 tuple (composto da indirizzo IP di origine, indirizzo IP di destinazione e protocollo)	CLIENT_IP_PROTO
Hash a 2 tuple (composto da indirizzo IP di origine e indirizzo IP di destinazione)	CLIENT_IP
Hash a una tupla (costituito solo dall'IP di origine)	CLIENT_IP_NO_DESTINATION

Affinità di sessione e hop successivo del bilanciatore del carico

Quando un bilanciatore del carico di rete passthrough interno è un hop successivo di una route statica, l'indirizzo IP di destinazione non è limitato all'indirizzo IP della regola di forwarding del bilanciatore del carico. L'indirizzo IP di destinazione del pacchetto può essere qualsiasi indirizzo IP che rientri nell'intervallo di destinazione della route statica.

La selezione di un backend idoneo dipende dal calcolo di un hash delle caratteristiche dei pacchetti. Ad eccezione dell'affinità di sessione CLIENT_IP_NO_DESTINATION (hash a 1 tupla), l'hash dipende, in parte, dall'indirizzo IP di destinazione del pacchetto.

Il bilanciatore del carico seleziona lo stesso backend per tutte le possibili nuove connessioni con caratteristiche dei pacchetti identiche, come definito dall'affinità sessione, se l'insieme di backend idonei non cambia. Se hai bisogno che la stessa VM di backend elabori tutti i pacchetti di un client, in base esclusivamente all'indirizzo IP di origine, indipendentemente dagli indirizzi IP di destinazione, utilizza l'affinità sessione CLIENT_IP_NO_DESTINATION.

Policy di tracciamento delle connessioni

Questa sezione descrive le impostazioni della policy di monitoraggio della connessione del bilanciatore del carico:

• Modalità di monitoraggio della connessione
• Persistenza della connessione su backend in stato non integro
• Timeout di inattività

Modalità di monitoraggio della connessione

Questa sezione descrive come il bilanciatore del carico crea le voci nella tabella di monitoraggio della connessione. I bilanciatori del carico di rete passthrough interni monitorano le connessioni per tutti i protocolli supportati e per tutte le opzioniaffinità sessionee.

La modalità di monitoraggio della connessione, il protocollo e l'affinità sessione determinano l'insieme di caratteristiche del pacchetto utilizzate per creare l'hash del pacchetto in ogni voce della tabella di monitoraggio della connessione.

La modalità di monitoraggio della connessione può essere una delle seguenti:

• PER_CONNECTION. Questa è la modalità di monitoraggio della connessione predefinita e più granulare. Ogni connessione è definita come un hash di 5 tuple o un hash di 3 tuple delle caratteristiche del pacchetto, a seconda che le informazioni sulla porta siano presenti o meno nel pacchetto. 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 meno granulare utilizza un hash che corrisponde all'hash di affinità sessione. A seconda dell'affinità di sessione scelta, la modalità di monitoraggio PER_SESSION può trattare più connessioni distinte come un'unica connessione ai fini del monitoraggio della connessione. In questo modo si riduce la frequenza con cui una connessione viene considerata nuova e soggetta ai passaggi di selezione del backend.

La tabella seguente riepiloga:

• Gli hash dei pacchetti utilizzati per la selezione del backend e
• Gli hash dei pacchetti utilizzati per il monitoraggio delle connessioni, in base alla modalità di monitoraggio delle connessioni, al protocollo e all'affinità sessione.

Affinità di sessione	Hash del pacchetto per la selezione del backend	Hash del pacchetto per il monitoraggio della connessione
		Quando utilizzi la modalità di monitoraggio PER_CONNECTION (predefinita)	Quando utilizzi la modalità di monitoraggio PER_SESSION
NONE (predefinito) OPPURE CLIENT_IP_PORT_PROTO	TCP e UDP non frammentato:hash a 5 tuple UDP frammentato e tutti gli altri protocolli: hash a 3 tuple	TCP e UDP non frammentato:monitoraggio della connessione attivo, hash a 5 tuple UDP frammentato e tutti gli altri protocolli:monitoraggio delle connessioni attivo, hash a 3 tuple	TCP e UDP non frammentato:monitoraggio delle connessioni attivo, hash a 5 tuple UDP frammentato e tutti gli altri protocolli: monitoraggio della connessione attivo, hash a 3 tuple
CLIENT_IP_PROTO	Tutti i protocolli:hash a 3 tuple	TCP e UDP non frammentato: monitoraggio delle connessioni attivo, hash a 5 tuple UDP frammentato e tutti gli altri protocolli: monitoraggio della connessione attivo, hash a 3 tuple	Tutti i protocolli: monitoraggio della connessione attivo, hash a 3 tuple
CLIENT_IP	Tutti i protocolli: hash a 2 tuple	TCP e UDP non frammentato: monitoraggio delle connessioni attivo, hash a 5 tuple UDP frammentato e tutti gli altri protocolli: monitoraggio della connessione attivo, hash a 3 tuple	Tutti i protocolli: monitoraggio della connessione attivo, hash a 2 tuple
CLIENT_IP_NO_DESTINATION	Tutti i protocolli: hash a 1 tupla	TCP e UDP non frammentato: monitoraggio delle connessioni attivo, hash a 5 tuple UDP frammentato e tutti gli altri protocolli: monitoraggio delle connessioni attivo, hash a 3 tuple	Tutti i protocolli: monitoraggio della connessione attivo, hash a 1 tupla

Per scoprire come modificare la modalità di monitoraggio delle connessioni, consulta Configurare una policy di monitoraggio delle connessioni.

Persistenza della connessione su backend in stato non integro

Persistenza della connessione su backend in stato non integro controlla se le connessioni esistenti possono persistere su una VM di backend selezionata in precedenza se la VM selezionata in precedenza diventa non integra. La persistenza della connessione su backend in stato non integro richiede che la VM di backend rimanga un membro di un gruppo di istanze o di un NEG con bilanciamento del carico.

Sono disponibili le seguenti opzioni di persistenza della connessione:

• DEFAULT_FOR_PROTOCOL (valore predefinito)
• NEVER_PERSIST
• ALWAYS_PERSIST

La tabella seguente descrive il comportamento della persistenza della connessione su backend in stato non integro a seconda dell'opzione di persistenza della connessione su backend in stato non integro, della modalità di monitoraggio della connessione, dell'affinità sessione e del protocollo.

Opzione Persistenza della connessione su backend in stato non integro	Comportamento della persistenza della connessione su backend in stato non integro
	Quando utilizzi la modalità di monitoraggio PER_CONNECTION (impostazione predefinita)	Quando utilizzi la modalità di monitoraggio PER_SESSION
DEFAULT_FOR_PROTOCOL	TCP, SCTP (tutte le affinità di sessione): le connessioni persistono sui backend in stato non integro, in base agli altri eventi e regole nel passaggio Gestisci voci della tabella di monitoraggio delle connessioni. Tutti gli altri protocolli: le connessioni non persistono sui backend in stato non integro	TCP, SCTP (affinità di sessione NONE e CLIENT_IP_PORT_PROTO): le connessioni persistono sui backend in stato non integro, in base agli altri eventi e alle regole nel passaggio Gestisci le voci della tabella di monitoraggio della connessione TCP, SCTP (tutte le altre affinità di sessione) e tutti gli altri protocolli: le connessioni non persistono sui backend in stato non integro
NEVER_PERSIST	Tutti i protocolli: le connessioni non persistono sui backend in stato non integro
ALWAYS_PERSIST Questa opzione deve essere utilizzata solo per casi d'uso avanzati.	Tutti i protocolli (tutte le affinità di sessione): le connessioni persistono sui backend in stato non integro, in base agli altri eventi e alle regole nel passaggio Gestisci le voci della tabella di monitoraggio della connessione	Configurazione impossibile

Per scoprire come modificare il comportamento di persistenza della connessione, consulta Configura una policy di monitoraggio della connessione.

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

Il bilanciatore del carico utilizza il monitoraggio della connessione con hash a 5 tuple per le connessioni TCP in queste situazioni:

• Quando utilizzi la modalità di monitoraggio PER_CONNECTION (tutte le affinità di sessione) o
• Quando utilizzi la modalità di monitoraggio PER_SESSION e l'affinità sessione è NONE o CLIENT_IP_PORT_PROTO.

Quando il bilanciatore del carico utilizza il monitoraggio della connessione con hash a 5 tuple per le connessioni TCP, tieni presente i seguenti comportamenti:

• Se il backend in stato non integro continua a rispondere ai pacchetti, la connessione continua finché non viene reimpostata o chiusa (dal backend in stato non integro o dal client).
• Se il backend non integro invia un pacchetto di reimpostazione TCP (RST) o non risponde ai pacchetti, il client potrebbe riprovare con una nuova connessione, consentendo al bilanciatore del carico di selezionare un backend idoneo diverso. I pacchetti TCP SYN vengono trattati come nuove connessioni nel passaggio Identifica i backend idonei.

Timeout di inattività

Una voce della tabella di monitoraggio delle connessioni viene rimossa dopo un periodo di inattività della connessione. A meno che tu non configuri un timeout di inattività personalizzato, il bilanciatore del carico utilizza un valore di timeout di inattività predefinito di 600 secondi (10 minuti).

La tabella seguente mostra i valori di timeout di inattività configurabili minimi e massimi per diverse combinazioni di impostazioni di modalità diaffinità sessionee e monitoraggio delle connessioni.

Affinità di sessione	Modalità di monitoraggio delle connessioni	Timeout di inattività predefinito	Timeout di inattività minimo configurabile	Timeout di inattività massimo configurabile
Qualsiasi tupla di connessione	PER_CONNECTION	600 secondi	60 secondi	600 secondi
Tupla di 1 elemento (CLIENT_IP_NO_DESTINATION) Tupla di 2 elementi (CLIENT_IP) Tupla di tre elementi (CLIENT_IP_PROTO)	PER_SESSION	600 secondi	60 secondi	57.600 secondi
5-tuple (NONE, CLIENT_IP_PORT_PROTO)	PER_SESSION	600 secondi	60 secondi	600 secondi

Per scoprire come modificare il valore di timeout di inattività, consulta Configurare un criterio di monitoraggio delle connessioni.

Svuotamento della connessione per i backend rimossi, arrestati o eliminati

Lo svuotamento della connessione fornisce un periodo di tempo minimo configurabile per la persistenza delle connessioni esistenti nella tabella di monitoraggio delle connessioni del bilanciatore del carico quando si verifica uno dei seguenti eventi:

• 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 (sono incluse azioni automatiche come aggiornamenti in sequenza o lo scale down 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, lo svuotamento della connessione quando i backend vengono rimossi, arrestati o eliminati è disattivato. Per saperne di più, vedi Attivazione dello svuotamento delle connessioni.

Failover

La funzionalità di failover ti consente di influenzare l'insieme di backend idonei classificando i gruppi di istanza di backend o i NEG e i relativi endpoint in questo modo:

• I backend principali sono VM o endpoint in un gruppo di istanze o NEG configurato come gruppo di backend principale.
• I backend di failover sono VM o endpoint in un gruppo di istanze o NEG configurato come gruppo di backend di failover.

Per impostazione predefinita, quando aggiungi un gruppo di istanze o un NEG a un servizio di backend, il gruppo di istanze o il NEG è un gruppo di backend principale. Puoi aggiungere fino a 50 gruppi di backend principali e 50 gruppi di backend di failover a un servizio di backend.

Per abilitare la funzionalità di failover, devi configurare il servizio di backend del bilanciatore del carico con quanto segue:

• Almeno un gruppo di backend principale non vuoto
• Almeno un gruppo di backend di failover non vuoto

Quando il failover è abilitato, i seguenti fattori determinano l'insieme di backend idonei:

• Lo stato di integrità di ogni backend
• Il rapporto di failover nel criterio di failover
• L'impostazione Interrompi il traffico se i backend non sono integri nella policy di failover

Policy di failover

Puoi modificare le seguenti impostazioni nel criterio di failover di un servizio di backend. La policy di failover è pertinente solo se il failover è abilitato.

• Rapporto di failover: un numero compreso tra 0.0 e 1.0, inclusi.
• Elimina il traffico se i backend non sono integri: un valore booleano che determina il comportamento di ultima istanza del bilanciatore del carico. Il rapporto di failover e l'impostazione Interrompi il traffico se i backend non sono integri interagiscono con altri fattori per controllare l'insieme di backend idonei.
• Svuotamento della connessione al failover: un valore booleano che controlla se le connessioni persistono sui backend selezionati in precedenza quando l'insieme di backend idonei passa dai backend primari a quelli di failover.

Rapporto di failover

Il rapporto di failover determina quando l'insieme di backend idonei passa dai backend principali a quelli di failover e viceversa. Il rapporto può essere un numero compreso tra 0.0 e 1.0, inclusi. Se non specifichi un rapporto di failover, Cloud de Confiance utilizza un valore predefinito di 0.0. Una best practice consiste nell'impostare il rapporto di failover su un numero adatto al tuo caso d'uso anziché fare affidamento a questo valore predefinito.

Svuotamento della connessione al failover

Svuotamento della connessione al failover controlla se una connessione esistente persiste su una VM o un endpoint di backend selezionati in precedenza quando l'insieme di backend idonei passa dai backend primari a quelli di failover.

Lo svuotamento della connessione al failover è attivato per impostazione predefinita. La tabella seguente riassume se le connessioni persistono, a seconda dell'opzione di svuotamento della connessione al failover e del protocollo:

Opzione Svuotamento della connessione al failover	Comportamento quando l'insieme di backend idonei passa dai backend principali a quelli di failover e viceversa
Abilitati (impostazione predefinita)	Tutti i protocolli: le connessioni persistono, purché esista una voce corrispondente nella tabella di monitoraggio delle connessioni, quando l'insieme di backend idonei passa dai backend principali a quelli di failover. Per saperne di più, consulta il passaggio Gestisci le voci della tabella di monitoraggio della connessione.
Disabilitato	Tutti i protocolli: le connessioni non persistono quando l'insieme di backend idonei passa dai backend principali a quelli di failover

La disattivazione dello svuotamento della connessione al failover è utile per i seguenti scenari:

• Applicazione di patch alle VM di backend. Prima dell'applicazione di patch, puoi configurare i backend primari integri in modo che non superino i controlli di integrità, in modo che i backend idonei possano essere backend di failover integri. Disattivando lo svuotamento delle connessioni in caso di failover, il bilanciatore del carico rimuove le voci della tabella di monitoraggio delle connessioni, applica i passaggi di selezione del backend ai pacchetti successivi e li invia a un backend idoneo diverso. Il backend diverso chiude quindi la connessione con un reset TCP, in modo che le VM client possano stabilire rapidamente una nuova connessione al bilanciatore del carico.

• Singola VM di backend per la coerenza dei dati. Se devi assicurarti che l'insieme di backend idonei abbia al massimo una VM o un endpoint membro, la disattivazione dello svuotamento della connessione in caso di failover riduce la possibilità di incoerenze dei dati.

Per scoprire come disattivare lo svuotamento della connessione al failover, consulta Definizione di una policy di failover.

Best practice e indicazioni

Puoi ottimizzare un bilanciatore del carico di rete passthrough interno seguendo queste linee guida operative. Le sezioni seguenti forniscono i requisiti tecnici per la gestione dei pacchetti UDP frammentati e le best practice per testare la distribuzione del carico da un singolo client.

Gestione della frammentazione UDP

I bilanciatori del carico di rete passthrough interni 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 Cloud de Confiance.
• Le reti VPCCloud de Confiance inoltrano i frammenti UDP man mano che arrivano (senza attendere l'arrivo di tutti i frammenti).
• Le reti nonCloud de Confiance 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 instradarli agli stessi backend, utilizza i seguenti parametri di configurazione della regola di forwarding e del servizio di backend:

• Configurazione della regola di forwarding: utilizza una sola regola di forwarding UDP per indirizzo IP con bilanciamento 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 della regola di forwarding per l'elaborazione del traffico per tutte le porte la configura anche per la ricezione di frammenti UDP che non contengono informazioni sulla porta. Per configurare tutte le porte, utilizza Google Cloud CLI per impostare --ports=ALL oppure 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 i frammenti UDP (diversi dal primo frammento) che non contengono informazioni sulla porta. Imposta la modalità di monitoraggio della connessione del servizio di backend su PER_SESSION in modo che le voci della tabella di monitoraggio della connessione vengano create utilizzando gli stessi hash a 2 o 3 tuple.

Test da un singolo client

Quando testi un bilanciatore del carico di rete passthrough interno da un singolo client, tieni presente quanto segue:

• Se la VM client non è un backend del bilanciatore del carico: le nuove connessioni vengono elaborate come descritto nei passaggi Selezione del backend e monitoraggio della connessione. Nel passaggio Seleziona un backend idoneo, il bilanciatore del carico crea un hash delle caratteristiche dei pacchetti in base all'affinità di sessione.

  Ricorda che tutte le opzioni di affinità sessione si basano almeno sull'indirizzo IP del client, quindi le connessioni dallo stesso client potrebbero essere distribuite allo stesso backend idoneo più spesso di quanto potresti aspettarti. Di conseguenza, non puoi modellare con precisione la distribuzione complessiva delle nuove connessioni connettendoti a un bilanciatore del carico di rete passthrough interno da un singolo client.

• Se la VM client è anche una VM di backend del bilanciatore del carico: le nuove connessioni non vengono effettivamente elaborate dal bilanciatore del carico. I pacchetti in uscita con l'indirizzo IP di destinazione della regola di forwarding del bilanciatore del carico vengono instradati localmente all'interno del sistema operativo guest del client a causa della presenza di una route locale per la regola di forwarding.

Passaggi successivi

• Per configurare e testare un bilanciatore del carico di rete passthrough interno che utilizza il failover, consulta Configura il failover per i bilanciatori del carico di rete passthrough interni.
• Per configurare e testare un bilanciatore del carico di rete passthrough interno, consulta Configura un bilanciatore del carico di rete passthrough interno.