Questa pagina illustra i concetti relativi alla modalità di distribuzione del traffico da parte dei bilanciatori del carico di rete passthrough interni.
Selezione del backend e monitoraggio delle connessioni
La selezione del backend e il monitoraggio delle connessioni agiscono congiuntamente per bilanciare più connessioni su diversi backend e instradare tutti i pacchetti per ogni connessione allo stesso backend. Questo viene realizzato con una strategia in due parti. Per prima cosa viene selezionato un backend utilizzando l'hashing coerente. Questa selezione viene poi registrata in una tabella di monitoraggio delle connessioni.
I passaggi riportati di seguito descrivono la procedura di monitoraggio della selezione e della connessione del backend.
1. Verifica la presenza di una voce nella tabella di monitoraggio delle connessioni 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 associare ogni pacchetto bilanciato in base al carico a 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 delle connessioni del bilanciatore del carico è
PER_CONNECTION, vai al passaggio Identifica i backend idonei. In modalità di monitoraggioPER_CONNECTION, un pacchetto TCP con il flagSYNrappresenta sempre una nuova connessione, indipendentemente dall'affinità sessione configurata.Se la modalità di monitoraggio delle connessioni del bilanciatore del carico è
PER_SESSIONe l'affinità sessione èNONEoCLIENT_IP_PORT_PROTO, vai al passaggio Identifica i backend idonei. InPER_SESSIONmodalità di monitoraggio, un pacchetto TCP con il flagSYNrappresenta una nuova connessione solo se viene utilizzata una delle opzioni di affinità sessione di 5 tuple (NONEoCLIENT_IP_PORT_PROTO).
Per tutti gli altri pacchetti, il bilanciatore del carico controlla se il pacchetto corrisponde a una voce della tabella di monitoraggio delle connessioni esistente. La tupla di connessione (un insieme di caratteristiche dei pacchetti) utilizzata per confrontare il pacchetto con le voci della tabella di monitoraggio delle connessioni esistenti dipende dalla modalità di monitoraggio delle connessioni e dall'affinità della 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 delle connessioni, 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 su per quanto tempo persiste una voce della tabella di monitoraggio delle connessioni e in quali condizioni, consulta il passaggio Creare una voce 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 consistente per selezionare un backend tra quelli idonei del pool attivo.
I passaggi riportati di seguito 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.
Questo passaggio modella i backend candidati a ricevere nuove connessioni, tenendo conto dell'integrità e della configurazione dei criteri di failover:
Nessun criterio di failover: l'insieme 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 quelli idonei è costituito da tutti i backend.
Criterio di failover configurato: l'insieme di backend idonei dipende dai controlli di integrità e dalla configurazione del criterio di failover:
Quando almeno un backend è integro, l'insieme di backend idonei consiste di tutti i backend integri nel pool attivo.
Il pool attivo potrebbe essere costituito da tutti i backend principali integri o da tutti i backend di failover integri. L'appartenenza al pool attivo è determinata dal rapporto di failover configurato, dal numero di backend primari integri e dal numero totale di backend primari.
Nonostante il rapporto di failover, se non esistono backend di failover integri, ma esiste almeno un backend principale integro, il pool attivo è costituito da tutti i backend principali integri.
Quando non sono presenti backend integri e il criterio di failover del bilanciatore del carico è configurato per eliminare le nuove connessioni, in questa situazione l'insieme dei backend idonei è vuoto. Il bilanciatore del carico elimina i pacchetti per la connessione.
Quando non sono presenti backend integri e il criterio di failover del bilanciatore del carico non è configurato per eliminare le nuove connessioni, in questa situazione i controlli di integrità non sono pertinenti. I backend idonei sono costituiti da tutti i backend principali.
2.2 Seleziona un backend idoneo.
Il bilanciatore del carico utilizza la hashing coerente per selezionare un backend idoneo. Il bilanciatore del carico gestisce gli hash di backend idonei, mappati a un cerchio unitario. Quando elabora un pacchetto per una connessione 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 dei pacchetti utilizzato per calcolare l'hash del pacchetto è definito dall'impostazione di affinità della sessione.
Se l'affinità sessione non è configurata esplicitamente, l'affinità di sessione
NONEè predefinita.Il bilanciatore del carico assegna nuove connessioni ai backend idonei in modo il più coerente possibile, anche se il numero di backend idonei cambia. I seguenti vantaggi dell'hashing coerente mostrano in che modo il bilanciatore del carico seleziona i backend idonei per possibili nuove connessioni che non hanno voci della 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 dall'affinità sessione, se l'insieme di backend idonei non cambia.
Quando viene aggiunto un nuovo backend idoneo, circa
1/Npossibili nuove connessioni vengono associate al backend appena aggiunto. In questa situazione,Nè il numero di backend idonei dopo l'aggiunta del nuovo backend.Quando viene rimosso un backend idoneo, circa
1/Npossibili nuove connessioni vengono mappate a uno deiN-1backend rimanenti. In questa situazione,Nè il numero di backend prima della rimozione del backend idoneo.
2.3 Crea 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. 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 delle connessioni e dall'affinità sessione che hai configurato.
Il bilanciatore del carico rimuove le voci della tabella di monitoraggio delle connessioni secondo le seguenti regole:
Una voce della tabella di monitoraggio delle connessioni viene rimossa dopo che la connessione è stata inattiva. A meno che non configuri un timeout inattivo personalizzato, il bilanciatore del carico utilizza un timeout inattivo predefinito di 600 secondi. Per ulteriori informazioni, consulta Timeout inattività.
Le voci della tabella di monitoraggio delle connessioni non vengono rimosse quando una connessione TCP viene chiusa con un pacchetto
FINoRST. Qualsiasi nuova connessione TCP trasporta sempre il flagSYNe viene elaborata come descritto nel passaggio Verifica la presenza di una voce della tabella di monitoraggio delle connessioni.Se è configurato un criterio di failover e l'impostazione di svuotamento delle connessioni in caso di failover e failback è disattivata, il bilanciatore del carico rimuove tutte le voci della tabella di monitoraggio delle connessioni quando il pool attivo cambia durante il failover o il failback. Per ulteriori informazioni, consulta 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 della persistenza della connessione su backend non integri. 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 dello svuotamento della connessione che si verifica a seguito di 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 ulteriori informazioni, consulta Attivare lo svuotamento della connessione.
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 interni 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 Monitoraggio della selezione e della connessione dei backend. Configura l'affinità sessione sul servizio di backend, non su ogni gruppo di istanza di backend o NEG.
I bilanciatori del carico di rete passthrough interni supportano le seguenti impostazioni di affinità sessione. Ogni impostazione di affinità sessione utilizza l'hashing coerente per selezionare un backend idoneo. L'impostazione di affinità sessione determina quali campi dell'intestazione IP e degli intestazioni di livello 4 vengono utilizzati per calcolare l'hash.
| Metodo di hashing per la selezione del backend | Impostazione dell'affinità sessione |
|---|---|
|
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 ORHash 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 |
NONE1 |
|
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 ORHash 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 tre tuple (composto da indirizzo IP di origine, indirizzo IP di destinazione e protocollo) |
CLIENT_IP_PROTO |
| Hash a due tuple (è costituito dall'indirizzo IP di origine e dall'indirizzo IP di destinazione) |
CLIENT_IP |
| Hash a una tuple (è costituito solo dall'IP di origine) |
CLIENT_IP_NO_DESTINATION2 |
1 Un'impostazione di affinità sessione pari a NONE non significa che non esiste alcuna affinità sessione. Ciò significa che non è stata configurata esplicitamente alcuna opzione di affinità sessione.
L'hashing viene sempre eseguito per selezionare un backend. Un'impostazione di affinità della sessione pari a NONE indica che il bilanciatore del carico utilizza un hash di 5 tuple o un hash di 3 tuple per selezionare i backend, ovvero funzionalmente lo stesso comportamento di quando è impostato CLIENT_IP_PORT_PROTO.
CLIENT_IP_NO_DESTINATION è un
hash a una tupla basato solo sull'indirizzo IP di origine di ogni pacchetto ricevuto.
Questa impostazione può essere utile in situazioni in cui è necessaria la stessa VM di backend per elaborare tutti i pacchetti di un client, in base esclusivamente all'indirizzo IP di origine del pacchetto, senza tenere conto dell'indirizzo IP di destinazione del pacchetto. Queste situazioni solitamente si verificano quando un bilanciatore del carico di rete passthrough interno è un hop successivo per una route statica.
Per maggiori dettagli, consulta Affinità di sessione
e bilanciatore del carico di rete passthrough interno di hop successivo.
Per scoprire in che modo le diverse impostazioni di affinità sessione influiscono sui metodi di selezione del backend e sul monitoraggio delle connessioni, consulta la tabella nella sezione Modalità di monitoraggio delle connessioni.
Affinità di sessione e bilanciatore del carico di rete passthrough interno dell'hop successivo
Quando configuri una route statica per utilizzare un bilanciatore del carico di rete passthrough interno di hop successivo, il bilanciatore del carico utilizza lo stesso metodo di monitoraggio della selezione e della connessione del backend. La selezione del backend avviene ancora calcolando un hash in base all'affinità della sessione configurata. Ad eccezione dell'affinità sessione CLIENT_IP_NO_DESTINATION (hash di tupla 1),
l'hash di selezione del backend dipende in parte dall'indirizzo IP di destinazione del pacchetto.
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ò invece essere qualsiasi indirizzo IP che rientra nell'intervallo di destinazione della route statica.
Se il numero di VM di backend configurate e integre è costante (quando il failover non è configurato o quando è configurato, ma non si verificano eventi di failover o di failback), il bilanciatore del carico si comporta nel seguente modo:
Se esiste una sola VM di backend configurata e integra (nel pool attivo, se è configurato il failover), non importa quale affinità sessione utilizzi perché tutti gli hash sono mappati all'unica VM di backend.
Se sono presenti due o più VM di backend configurate e in buono stato (nel pool attivo, se è configurato il failover), la scelta dell'affinità sessione è importante:
Se hai bisogno che la stessa VM di backend elabori tutti i pacchetti di un client, in base esclusivamente all'indirizzo IP di origine del pacchetto, indipendentemente dagli indirizzi IP di destinazione del pacchetto, utilizza l'affinità sessione
CLIENT_IP_NO_DESTINATION. A seconda dei pattern di traffico, alcune VM di backend potrebbero ricevere più pacchetti o più connessioni rispetto ad altre VM di backend.Se utilizzi un'opzione di affinità sessione diversa da
CLIENT_IP_NO_DESTINATION, il bilanciatore del carico seleziona una VM di backend in base a informazioni che includono almeno entrambi l'indirizzo IP di origine e l'indirizzo IP di destinazione del pacchetto. I pacchetti inviati dallo stesso client, utilizzando lo stesso indirizzo IP di origine, ma indirizzi IP di destinazione diversi, possono essere instradati a VM di backend diverse.
Policy di tracciamento delle connessioni
Questa sezione descrive le impostazioni che controllano il comportamento del monitoraggio delle connessioni dei bilanciatori del carico di rete passthrough interni. Un criterio di monitoraggio delle connessioni include le seguenti impostazione:
- Modalità di monitoraggio delle connessioni
- Persistenza della connessione su backend non integri
- Timeout di inattività
Modalità di 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 di caratteristiche dei pacchetti che compongono ogni tupla di connessione è determinato dalla modalità di monitoraggio della connessione e dall'affinità sessione.
I bilanciatori del carico di rete passthrough interni monitorano le connessioni per tutti i protocolli supportati.
La modalità di monitoraggio delle connessioni si riferisce alla granularità di ogni tuple di connessione nella tabella di monitoraggio delle connessioni del bilanciatore del carico. La tupla di connessione può essere di 5 o 3 elementi (modalità PER_CONNECTION) oppure può corrispondere all'impostazione di affinità della sessione (modalità PER_SESSION).
PER_CONNECTION. Questa è la modalità di monitoraggio della connessione predefinita. Questa modalità di monitoraggio delle connessioni utilizza un hash di 5 tuple o un hash di 3 tuple. I pacchetti non frammentati che includono informazioni sulle porte, come i pacchetti TCP e UDP non frammentati, vengono monitorati con hash di tuple di 5 elementi. Tutti gli altri pacchetti vengono monitorati con hash di tuple di 3 elementi.PER_SESSION. Questa modalità di monitoraggio delle connessioni utilizza un hash costituito dalle stesse caratteristiche dei pacchetti utilizzate dall'hash di affinità della sessione. A seconda dell'affinità sessione scelta,PER_SESSIONpuò generare connessioni che corrispondono più spesso a una voce della tabella di monitoraggio delle connessioni esistente, riducendo la frequenza con cui è necessario selezionare un backend dall'hash dell'affinità sessione.
La tabella seguente riassume il modo in cui la modalità di monitoraggio delle connessioni e l'affinità sessione lavorano insieme per instradare tutti i pacchetti per ogni connessione allo stesso backend.
| Selezione del backend utilizzando l'affinità sessione | Modalità di monitoraggio delle connessioni | ||
|---|---|---|---|
| Impostazione dell'affinità sessione | Metodo di hashing per la selezione del backend | PER_CONNECTION (valore predefinito) |
PER_SESSION |
NONE |
TCP e UDP non frammentati: hash di 5 tuple UDP frammentato e tutti gli altri protocolli: hash a tre tuple |
TCP e UDP non frammentati: hash di 5 tuple UDP frammentato e tutti gli altri protocolli: hash a tre tuple |
TCP e UDP non frammentati: hash di 5 tuple UDP frammentato e tutti gli altri protocolli: hash a tre tuple |
CLIENT_IP_NO_DESTINATION |
Tutti i protocolli: hash con una tupla | TCP e UDP non frammentati: hash di 5 tuple UDP frammentato e tutti gli altri protocolli: hash a tre tuple |
Tutti i protocolli: hash con una tupla |
CLIENT_IP |
Tutti i protocolli: hash di tuple di 2 elementi | TCP e UDP non frammentati: hash di 5 tuple UDP frammentato e tutti gli altri protocolli: hash a tre tuple |
Tutti i protocolli: hash di tuple di 2 elementi |
CLIENT_IP_PROTO |
Tutti i protocolli: hash di tuple di 3 elementi | TCP e UDP non frammentati: hash di 5 tuple UDP frammentato e tutti gli altri protocolli: hash a tre tuple |
Tutti i protocolli: hash di tuple di 3 elementi |
CLIENT_IP_PORT_PROTO |
TCP e UDP non frammentati: hash di 5 tuple UDP frammentato e tutti gli altri protocolli: hash a tre tuple |
TCP e UDP non frammentati: hash di 5 tuple UDP frammentato e tutti gli altri protocolli: hash a tre tuple |
TCP e UDP non frammentati: hash di 5 tuple UDP frammentato e tutti gli altri protocolli: hash a tre tuple |
Per scoprire come modificare la modalità di monitoraggio delle connessioni, consulta Configurare un criterio di monitoraggio delle connessioni.
Persistenza della connessione su backend in stato non integro
Le impostazioni di persistenza della connessione controllano se una connessione esistente permane su un endpoint o una VM di backend selezionata dopo che il backend diventa non integro, a condizione che il backend rimanga nel gruppo di backend configurato del bilanciatore del carico (in un gruppo di istanze o in un NEG).
Sono disponibili le seguenti opzioni di persistenza della connessione:
DEFAULT_FOR_PROTOCOL(valore predefinito)NEVER_PERSISTALWAYS_PERSIST
La tabella seguente riassume le opzioni di persistenza delle connessioni 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 monitoraggio delle connessioni | |
|---|---|---|
PER_CONNECTION |
PER_SESSION |
|
DEFAULT_FOR_PROTOCOL |
TCP: le connessioni rimangono attive sui backend non integri (tutte le affinità sessione) UDP: le connessioni non vengono mai mantenute su backend non integri |
TCP: le connessioni persistono sui backend non integri se
l'affinità sessione è UDP: le connessioni non vengono mai mantenute su backend non integri |
NEVER_PERSIST |
TCP, UDP: le connessioni non persistono mai su backend non integri | |
ALWAYS_PERSIST
|
TCP, UDP: le connessioni persistono su backend in stato non integro (tutte le affinità di sessione) Questa opzione deve essere utilizzata solo per casi d'uso avanzati. |
Configurazione non possibile |
Per scoprire come modificare il comportamento di persistenza della connessione, consulta Configurare un criterio di monitoraggio delle connessioni.
Timeout di inattività
Per impostazione predefinita, una voce nella tabella di monitoraggio delle connessioni scade 600 secondi dopo che il bilanciatore del carico ha elaborato l'ultimo pacchetto corrispondente alla voce. Questo valore predefinito del timeout di inattività può essere modificato solo quando il monitoraggio delle connessioni è inferiore a 5 tuple (ovvero quando l'affinità sessione è configurata su CLIENT_IP o CLIENT_IP_PROTO e la modalità di monitoraggio è PER_SESSION).
Il valore massimo del timeout di inattività configurabile è 57.600 secondi (16 ore).
Per scoprire come modificare il valore del timeout inattivo, consulta Configurare un criterio di monitoraggio delle connessioni.
Connessioni per implementazioni con un solo client
Quando testi le connessioni all'indirizzo IP di un bilanciatore del carico di rete passthrough interno con un solo client, tieni presente quanto segue:
Se la VM client non è una VM bilanciata in base al carico, ovvero non è anche una VM di backend, le nuove connessioni vengono inviate alle VM di backend integre del bilanciatore del carico. Tuttavia, poiché tutte le opzioni di affinità sessione si basano almeno sull'indirizzo IP del sistema client, le connessioni dallo stesso client potrebbero essere distribuite alla stessa VM di backend più spesso di quanto potresti aspettarti.
In pratica, ciò significa che non puoi monitorare con precisione la distribuzione del traffico tramite un bilanciatore del carico di rete passthrough interno collegandoti da un singolo client. Il numero di client necessari per monitorare la distribuzione del traffico varia in base al tipo di bilanciatore del carico, al tipo di traffico e al numero di backend funzionanti.
Se la VM client è anche una VM di backend del bilanciatore del carico, le connessioni inviate all'indirizzo IP della regola di inoltro del bilanciatore del carico ricevono sempre risposta dalla stessa VM di backend (che è anche la VM client). Ciò accade indipendentemente dal fatto che la VM di backend sia integra. Questo accade per tutto il traffico inviato all'indirizzo IP del bilanciatore del carico, non solo per il traffico sul protocollo e sulle porte specificate nella regola di forwarding interna del bilanciatore del carico.
Per ulteriori informazioni, consulta la sezione Inviare richieste da VM con bilanciamento del carico.
Svuotamento della connessione
Lo svuotamento delle connessioni fornisce un periodo di tempo aggiuntivo configurabile per consentire alle connessioni stabilite di rimanere 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 interrotta o eliminata (sono incluse azioni automatiche come gli 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, svuotamento della connessione per le azioni sopra indicate è disattivato. Per informazioni su come viene attivato lo svuotamento della connessione e su come attivarlo, consulta Attivare lo svuotamento della connessione.
Frammentazione UDP
I bilanciatori del carico di rete passthrough interni possono elaborare pacchetti UDP sia frammentati che non frammentati. Se la tua applicazione utilizza pacchetti UDP frammentati, tieni presente quanto segue:- I pacchetti UDP potrebbero frammentarsi prima di raggiungere una Google Cloud rete VPC.
- Le reti VPC inoltrano i frammenti UDP man mano che arrivano (senza attendere l'arrivo di tutti i frammenti).Google Cloud
- Le reti nonGoogle Cloud e le apparecchiature di rete on-premise potrebbero forwardare i frammenti UDP man mano che arrivano, ritardare i pacchetti UDP frammentati finché non sono arrivati tutti i frammenti o eliminare i pacchetti UDP frammentati. Per maggiori dettagli, consulta la documentazione del fornitore di servizi di rete o dell'apparecchiatura di rete.
Se prevedi pacchetti UDP frammentati e devi inoltrarli agli stessi backend, utilizza la seguente regola di forwarding e i seguenti parametri di configurazione del servizio di backend:
Configurazione della regola di forwarding: utilizza una sola regola di forwarding
UDPper indirizzo IP bilanciato in base al 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 elaborare il traffico per tutte le porte la configura anche per ricevere frammenti UDP che non hanno informazioni sulla porta. Per configurare tutte le porte, utilizza Google Cloud CLI per impostare--ports=ALLo utilizza l'API per impostareallPortssuTrue.Configurazione del servizio di backend: imposta l'affinità della sessione del servizio di backend su
CLIENT_IP(hash di tupla 2) oCLIENT_IP_PROTO(hash di tupla 3) in modo che venga selezionato lo stesso backend per i pacchetti UDP che includono informazioni sulla porta e frammenti UDP (diversi dal primo frammento) che non contengono informazioni sulla porta. Imposta la modalità di monitoraggio delle connessioni del servizio di backend suPER_SESSIONin modo che le voci della tabella di monitoraggio delle connessioni vengano create utilizzando gli stessi hash di tuple di 2 o 3 elementi.
Failover
Un bilanciatore del carico di rete passthrough interno ti consente di designare alcuni backend come backend di failover. Questi backend vengono utilizzati solo quando il numero di VM integre nei gruppi di istanza di backend principali è inferiore a una soglia configurabile. Per impostazione predefinita, se tutte le VM principali e di failover non sono integre, come ultima risorsaGoogle Cloud distribuisce le nuove connessioni solo tra tutte le VM principali.
Quando aggiungi un backend al servizio di backend di un bilanciatore del carico di rete passthrough interno, per impostazione predefinita il backend è un backend principale. Puoi designare un backend come backend di failover quando lo aggiungi al servizio di backend del bilanciatore del carico o modificandolo 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 Failover per i bilanciatori del carico di rete passthrough interni.
Passaggi successivi
- Per configurare e testare un bilanciatore del carico di rete passthrough interno che utilizza il failover, consulta Configurare 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.