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à sessionee, il bilanciamento del carico ponderato e il failover.
Comprendere il funzionamento combinato di tutte queste funzionalità ti aiuta a ottimizzare la configurazione del bilanciamento del carico per un rendimento affidabile e un utilizzo efficiente delle risorse. Questi meccanismi sono fondamentali per le applicazioni che richiedono la persistenza della sessione, in quanto consentono di mantenere un comportamento coerente per ogni interazione dell'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 monitoraggioPER_CONNECTION, un pacchetto TCP con il flagSYNrappresenta sempre una nuova connessione, indipendentemente dall'affinità sessionee configurata.Se la modalità di monitoraggio della connessione del bilanciatore del carico è
PER_SESSIONe l'affinità sessione èNONEoCLIENT_IP_PORT_PROTO, vai al passaggio Identifica i backend idonei. In modalità di monitoraggioPER_SESSION, un pacchetto TCP con il flagSYNrappresenta una nuova connessione solo quando si utilizza una delle opzioni di affinità di sessione con 5 tuple (NONEoCLIENT_IP_PORT_PROTO).
- Monitoraggio della connessione non supportato: se la combinazione di protocollo e affinità sessione non supporta il monitoraggio della connessione, vai al passaggio Identifica i backend idonei. Per informazioni su quali protocolli sono tracciabili, consulta la tabella nella sezione Modalità di tracciamento delle connessioni.
Tutti gli altri pacchetti: il bilanciatore del carico verifica 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 delle connessioni, continua con il 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 per la 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 registrare la connessione 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 e che il bilanciamento del carico ponderato sia attivato.
| Failover | Bilanciamento del carico ponderato | Backend idonei |
|---|---|---|
Quando le funzionalità di failover e bilanciamento del carico ponderato sono disattivate, tutti i backend configurati sono backend principali. L'insieme di backend idonei è definito come segue:
|
||
Quando la funzionalità di bilanciamento del carico di failover è disattivata e la funzionalità di bilanciamento del carico ponderato è attivata, i backend idonei sono quelli che provengono dal primo dei seguenti insiemi non vuoti:
|
||
Quando la funzionalità di bilanciamento del carico di failover è abilitata e la funzionalità di bilanciamento del carico ponderato è disabilitata, 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 sono attivate sia le funzionalità di failover sia quelle di bilanciamento del carico ponderato, il bilanciatore del carico utilizza le informazioni sul peso, sui controlli di integrità e sulla configurazione della policy di failover per definire l'insieme di backend idonei:
|
2.2 Seleziona un backend idoneo
Il bilanciatore del carico gestisce gli hash dei backend idonei, con ogni hash del backend mappato a un cerchio unitario. Il bilanciamento del carico ponderato modifica la mappatura dei backend idonei al cerchio in modo che i backend con ponderazioni più elevate abbiano maggiori probabilità di essere selezionati, in proporzione alle loro ponderazioni.
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 l'affinità sessione non è configurata in modo esplicito, l'affinità di sessione
NONEè il valore predefinito.
L'hashing coerente garantisce che il bilanciatore del carico assegni nuove connessioni a backend idonei in modo da ridurre al minimo le interruzioni del mapping anche se il numero di backend idonei o i relativi pesi cambiano.
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 a quelle definite dall'impostazione di affinità di 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.
Se un backend idoneo viene aggiunto, rimosso o il suo peso viene modificato, 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 i possibili hash dei pacchetti definiti dall'impostazione di affinità sessione configurata (e, più nello specifico, per tutte le possibili connessioni quando l'affinità sessione genera un hash a 5 tuple per la selezione del backend):
Se il bilanciamento del carico ponderato non è configurato, circa
1/Nhash di pacchetti possibili vengono mappati a ogni backend idoneo, doveNè il numero di backend idonei.Se è configurato il bilanciamento del carico ponderato, il rapporto tra gli hash dei pacchetti possibili che vengono mappati a ciascun backend idoneo è approssimativamente: il peso di un backend idoneo diviso per la somma di tutti i pesi dei backend idonei.
I due esempi seguenti mostrano in che modo il bilanciamento del carico ponderato influisce sulle probabilità di selezione di ogni backend idoneo:
Se il servizio di backend ha due backend idonei, il primo con peso
1e il secondo con peso4, 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, ovvero il backend idoneo
acon peso0, il backend idoneobcon peso2e il backend idoneoccon peso6, il backendaha una probabilità di selezione dello 0% (0÷(0+2+6)), il backendbha una probabilità di selezione del 25% (2÷(0+2+6)) e il backendcha una probabilità di selezione del 75% (6÷(0+2+6)).
2.3 Crea una voce della tabella di monitoraggio della connessione
Dopo aver selezionato un backend, il bilanciatore del carico crea una voce nella tabella di monitoraggio della connessione se l'affinità sessione configurata supporta il monitoraggio della connessione per il protocollo del pacchetto.Se la combinazione di protocollo e affinità sessione non supporta il monitoraggio della connessione, salta 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 configurate.
Per informazioni sui protocolli di cui è possibile monitorare la connessione in base alle tue scelte di configurazione e sulle caratteristiche dei pacchetti utilizzate per l'hash nella tabella di monitoraggio della connessione, consulta la tabella nella sezione Modalità di monitoraggio della connessione.
3. Gestisci le voci della tabella di monitoraggio delle connessioni
Il bilanciatore del carico gestisce le voci della tabella di monitoraggio della connessione, se la combinazione di protocollo e affinità sessione supporta il monitoraggio della connessione, in base ai seguenti eventi e regole:
- Le voci inattive vengono rimosse: una voce della tabella di monitoraggio delle connessioni viene rimossa dopo 60 secondi se nessun nuovo pacchetto in entrata viene elaborato da un Maglev. Per maggiori informazioni, consulta Timeout di inattività.
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
FINoRST. Potrebbero essere rimosse in un secondo momento come voci inattive. Ogni nuova connessione TCP trasporta sempre il flagSYNed è soggetta all'elaborazione descritta nel passaggio Controlla una voce della tabella di monitoraggio delle connessioni.Quando le connessioni non persistono in caso di failover: quando è configurato almeno un backend di failover e l'impostazione di svuotamento della connessione in caso di failover è disabilitata, il bilanciatore del carico rimuove tutte le voci nella tabella di monitoraggio della connessione dopo che il set 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 delle connessioni nel momento in cui l'insieme di backend idonei passa dai backend primari 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 il set 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ù, vedi Svuotamento delle connessioni 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 delle connessioni a un backend selezionato in precedenza nel momento in cui il backend diventa non integro. Invece, 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 in stato 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 da integro a non integro e poi di nuovo a integro e non sono arrivati pacchetti per la connessione mentre il backend selezionato in precedenza non era 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 esterno regionale 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 esterni regionali supportano le seguenti impostazioni di affinità sessione.
| Metodo hash per la selezione del backend | Impostazione dell'affinità di sessione |
|---|---|
|
Hash a 5 tuple (composto 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) ORHash 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 (costituito 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 |
1 L'affinità sessione NONE non indica che non esiste un'affinità sessione. Significa invece che l'affinità sessione viene eseguita con un hash a 5 tuple o a 3 tuple delle caratteristiche dei pacchetti, ovvero con lo stesso comportamento di quando è impostato CLIENT_IP_PORT_PROTO.
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 delle connessioni
Questa sezione descrive quando e come il bilanciatore del carico crea voci nella tabella di monitoraggio delle connessioni. I bilanciatori del carico di rete passthrough esterni regionali supportano il monitoraggio delle connessioni in base al protocollo e all'affinità 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. Per l'affinità sessioneNONE, questi protocolli non sono tracciabili per la connessione.Tutti gli altri protocolli, come ICMP e ICMPv6, non sono tracciabili per la connessione per tutte le opzioni di affinità sessione.
Quando il monitoraggio delle connessioni è possibile, la modalità di monitoraggio delle connessioni, il protocollo e l'affinità sessione determinano l'insieme delle caratteristiche dei pacchetti utilizzate per creare l'hash dei pacchetti in ogni voce della tabella di monitoraggio delle connessioni.
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 hash a 5 tuple o hash a 3 tuple delle caratteristiche del pacchetto, a seconda che le informazioni sulla porta siano presenti 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 monitoraggioPER_SESSIONpuò 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 riassume:
- 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 (impostazione predefinita) |
Quando utilizzi la modalità di monitoraggio PER_SESSION |
||
NONE (valore predefinito) |
|
|
|
CLIENT_IP_PORT_PROTO |
|
|
|
CLIENT_IP_PROTO |
|
|
|
CLIENT_IP |
|
|
|
Per scoprire come modificare la modalità di monitoraggio delle connessioni, consulta Configura 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 in stato non integro. 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 e che la combinazione di protocollo e affinità sessione supporti il monitoraggio della connessione.
Sono disponibili le seguenti opzioni di persistenza della connessione:
DEFAULT_FOR_PROTOCOL(valore predefinito)NEVER_PERSISTALWAYS_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 (predefinita) |
Quando utilizzi la modalità di monitoraggio PER_SESSION |
|
DEFAULT_FOR_PROTOCOL |
|
|
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. |
|
Configurazione non possibile |
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 delle connessioni 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_SESSIONe l'affinità sessione èNONEoCLIENT_IP_PORT_PROTO.
Quando il bilanciatore del carico utilizza il monitoraggio delle connessioni hash a 5 tuple per le connessioni TCP, tieni presente i seguenti comportamenti:
- 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 TCP reset (RST) o non risponde ai pacchetti, il client potrebbe riprovare con una nuova connessione, consentendo al bilanciatore del carico di selezionare un altro backend idoneo. (I pacchetti TCP
SYNvengono trattati come nuove connessioni nel passaggio Identifica i backend idonei).
Timeout di inattività
Le voci nelle tabelle di monitoraggio della connessione scadono 60 secondi dopo che il bilanciatore del carico ha elaborato l'ultimo pacchetto corrispondente alla voce. Questo valore di timeout di inattività non può essere modificato.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 (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, lo svuotamento della connessione quando i backend vengono rimossi, arrestati o eliminati è disabilitato. Per saperne di più, vedi Attivazione dello svuotamento delle connessioni.
Bilanciamento del carico ponderato
Il bilanciamento del carico ponderato influenza i backend idonei nei passaggi di selezione del backend. Ogni VM o endpoint di backend comunica il proprio peso al bilanciatore del carico utilizzando un controllo di integrità HTTP e un'intestazione della risposta personalizzata. Per utilizzare il bilanciamento del carico ponderato, devi configurare quanto segue nel servizio di backend del bilanciatore del carico:
- La policy di località (
localityLbPolicy) deve essere impostata suWEIGHTED_MAGLEV. Il controllo di integrità deve essere un controllo di integrità HTTP che invia un'intestazione di risposta speciale:
- Il nome del campo dell'intestazione della risposta deve essere
X-Load-Balancing-Endpoint-Weight. - I valori dei campi dell'intestazione della risposta possono essere compresi tra
0e1000inclusi.
- Il nome del campo dell'intestazione della risposta deve essere
Per saperne di più, consulta Configurare il bilanciamento del carico ponderato.
Considerazioni sul bilanciamento del carico ponderato
Il bilanciamento del carico ponderato è utile nei seguenti scenari, che consentono a un backend di continuare a elaborare le connessioni esistenti:
Il bilanciamento del carico ponderato consente a un backend che elabora connessioni a esecuzione prolungata o connessioni che coinvolgono grandi quantità di dati di comunicare al bilanciatore del carico di ridurre il numero di nuove connessioni che riceve.
Il bilanciamento del carico ponderato consente a un backend sovraccarico o in fase di manutenzione di rimuovere se stesso dai backend idonei per le nuove connessioni. Per farlo, il backend sovraccarico invia l'intestazione della risposta
X-Load-Balancing-Endpoint-Weight: 0(e può continuare a superare o non superare il controllo di integrità del bilanciatore del carico). Questo funziona perché tutti i backend con peso diverso da zero (indipendentemente dallo stato del controllo di integrità) sono backend idonei più preferibili nel passaggio Identifica i backend idonei.
Quando utilizzi il bilanciamento del carico, tieni presente quanto segue:
Se i backend idonei cambiano spesso i propri pesi, il bilanciamento del carico ponderato può influire negativamente sull'affinità sessione. Per saperne di più, consulta il passaggio Seleziona un backend idoneo.
Se utilizzi lo stesso gruppo di istanze o NEG come backend di due o più servizi di backend del bilanciatore del carico, puoi segnalare un peso univoco per ogni servizio di backend utilizzando la seguente strategia:
Utilizza un controllo di integrità HTTP univoco per ogni servizio di backend. Ogni controllo di integrità può utilizzare una porta di destinazione o un parametro
request-pathunivoco.Configura le istanze o gli endpoint di backend in modo che rispondano con informazioni sul peso appropriate per ogni controllo di integrità.
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 Elimina il traffico se i backend non sono integri nella policy di failover
- Se utilizzi il failover da solo o in combinazione con il bilanciamento del carico ponderato
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.0e1.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 principali a quelli di failover e viceversa.
Rapporto di failover
Il rapporto di failover determina quando l'insieme di backend idonei passa dai backend principali a quelli di failover. Il rapporto può essere un numero compreso tra 0.0 e 1.0, inclusi. Se non specifichi un rapporto di failover, Google Cloud 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
Lo svuotamento della connessione al failover controlla se una connessione esistente persiste su una VM o un endpoint di backend selezionato in precedenza quando l'insieme di backend idonei passa dai backend principali a quelli di failover e viceversa.
Lo svuotamento della connessione al failover è abilitato 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) |
Per informazioni su quali protocolli sono tracciabili per la connessione, consulta la tabella nella sezione Modalità di monitoraggio della connessione. |
| Disabilitato | Tutti i protocolli:le connessioni non vengono mantenute quando l'insieme di backend idonei passa da backend principali a backend 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 delle patch, puoi configurare i backend primari integri con peso diverso da zero in modo che non superino i controlli di integrità oppure puoi impostare i loro pesi su zero. In questo modo, i backend idonei possono essere backend di failover integri con peso diverso da zero. Se disattivi lo svuotamento della connessione in caso di failover, il bilanciatore del carico rimuove le voci della tabella di monitoraggio della connessione, 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 ripristino TCP, in modo che le VM client possano stabilire rapidamente una nuova connessione al bilanciatore del carico.
VM di backend singola 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 esterno regionale 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 esterni regionali 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 Google Cloud rete VPC.
- Le reti VPCGoogle Cloud 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 network provider o dell'apparecchiatura 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
UDPoL3_DEFAULTper indirizzo IP bilanciato dal 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 hanno informazioni sulla porta. Per configurare tutte le porte, utilizza Google Cloud CLI per impostare--ports=ALLo l'API per impostareallPortssuTrue.Configurazione del servizio di backend: imposta l'affinità di sessione del servizio di backend su
CLIENT_IP(hash a 2 tuple) oCLIENT_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 suPER_SESSIONin 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 esterno regionale 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, pertanto le connessioni dallo stesso client potrebbero essere distribuite allo stesso backend idoneo più frequentemente di quanto ti aspetti. Di conseguenza, non puoi modellare con precisione la distribuzione complessiva delle nuove connessioni connettendoti a un bilanciatore del carico di rete passthrough esterno regionale 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 un bilanciatore del carico di rete passthrough esterno con un servizio di backend solo per il traffico TCP o UDP (che supporta il traffico IPv4 e IPv6), consulta Configura un bilanciatore del carico di rete passthrough esterno con un servizio di backend.
- Per configurare un bilanciatore del carico di rete passthrough esterno per più protocolli IP (che supportano il traffico IPv4 e IPv6), consulta Configurare un bilanciatore del carico di rete passthrough esterno per più protocolli IP.
- Per configurare un bilanciatore del carico di rete passthrough esterno con un backend NEG di zona, consulta Configura un bilanciatore del carico di rete passthrough esterno con NEG di zona.
- Per scoprire come eseguire la transizione di un bilanciatore del carico di rete passthrough esterno da un backend del pool di destinazione a un servizio di backend regionale, consulta Eseguire la transizione di un bilanciatore del carico di rete passthrough esterno da un pool di destinazione a un servizio di backend.