Questo documento approfondisce i dettagli di come i bilanciatori del carico delle applicazioni esterni gestiscono le connessioni, instradano il traffico e mantengono l'affinità sessione.
Come funzionano le connessioni
I bilanciatori del carico delle applicazioni esterni diGoogle Cloud, globali e regionali, semplificano il routing utilizzando proxy distribuiti (GFE) o subnet gestite da Envoy. Con timeout configurabili, terminazione TLS e sicurezza integrata, garantiscono una distribuzione delle applicazioni conforme e scalabile a livello globale o regionale.
Connessioni del bilanciatore del carico delle applicazioni esterno regionale
Il bilanciatore del carico delle applicazioni esterno regionale è un servizio gestito implementato sul proxy Envoy.
Il bilanciatore del carico delle applicazioni esterno regionale utilizza una subnet condivisa, chiamata subnet solo proxy, per eseguire il provisioning di un insieme di indirizzi IP che Google utilizza per eseguire i proxy Envoy per tuo conto. Il flag --purpose per questa subnet solo proxy è impostato su REGIONAL_MANAGED_PROXY. Tutti i bilanciatori del carico basati su Envoy a livello di regione in una determinata rete e regione condividono questa subnet.
I client utilizzano l'indirizzo IP e la porta del bilanciatore del carico per connettersi al bilanciatore del carico. Le richieste dei client vengono indirizzate alla subnet solo proxy nella stessa regione del client. Il bilanciatore del carico termina le richieste dei client e poi apre nuove connessioni dalla subnet solo proxy ai tuoi backend. Pertanto, i pacchetti inviati dal bilanciatore del carico hanno indirizzi IP di origine della subnet solo proxy.
A seconda della configurazione del servizio di backend, il protocollo utilizzato dai proxy Envoy per connettersi ai backend può essere HTTP, HTTPS o HTTP/2. Se HTTP o HTTPS, la versione HTTP è HTTP 1.1. Il keepalive HTTP è abilitato per impostazione predefinita, come specificato nella specifica HTTP 1.1. Il proxy Envoy imposta sia il timeout keepalive HTTP del client sia il timeout keepalive del backend su un valore predefinito di 600 secondi ciascuno. Puoi aggiornare il timeout keepalive HTTP del client, ma il valore del timeout keepalive del backend è fisso. Puoi configurare il timeout della richiesta/risposta impostando il timeout del servizio di backend. Per saperne di più, consulta Timeout e nuovi tentativi.
Comunicazioni del client con il bilanciatore del carico
- I client possono comunicare con il bilanciatore del carico utilizzando il protocollo HTTP/1.0, HTTP/1.1, HTTP/2 o HTTP/3.
- Quando viene utilizzato HTTPS, i client moderni utilizzano per impostazione predefinita HTTP/2. Questo viene controllato sul client, non sul bilanciatore del carico HTTPS.
- Non puoi disattivare HTTP/2 modificando la configurazione del bilanciatore del carico. Tuttavia, puoi configurare alcuni client in modo che utilizzino HTTP 1.1 anziché HTTP/2. Ad esempio, con
curl, utilizza il parametro--http1.1. - I bilanciatori del carico delle applicazioni esterni supportano la risposta
HTTP/1.1 100 Continue.
Per l'elenco completo dei protocolli supportati dalle regole di forwarding del bilanciatore del carico delle applicazioni esterno in ogni modalità, consulta Funzionalità del bilanciatore del carico.
Indirizzi IP di origine per i pacchetti client
L'indirizzo IP di origine dei pacchetti, come visto dai backend, non è l'indirizzo IP esternoGoogle Cloud del bilanciatore del carico. In altre parole, esistono due connessioni TCP.
Per i bilanciatori del carico delle applicazioni esterni regionali:Connessione 1, dal client originale al bilanciatore del carico (subnet solo proxy):
- Indirizzo IP di origine: il client originale (o l'indirizzo IP esterno se il client si trova dietro un gateway NAT o un proxy di forwarding).
- Indirizzo IP di destinazione: l'indirizzo IP del bilanciatore del carico.
Connessione 2, dal bilanciatore del carico (subnet solo proxy) alla VM o all'endpoint di backend:
Indirizzo IP di origine: un indirizzo IP nella subnet solo proxy condiviso tra tutti i bilanciatori del carico basati su Envoy di cui è stato eseguito il deployment nella stessa regione e nella stessa rete del bilanciatore del carico.
Indirizzo IP di destinazione: l'indirizzo IP interno della VM o del container di backend nella rete VPC.
Percorsi di routing speciali
Google Cloud utilizza route speciali non definite nella tua rete VPC per instradare i pacchetti per i seguenti tipi di traffico:
- Per i controlli di integrità, ad eccezione dei controlli di integrità Envoy distribuiti. Per saperne di più, consulta Percorsi per i controlli di integrità.
Google Cloud utilizza le route di subnet per le subnet solo proxy per instradare i pacchetti per i seguenti tipi di traffico:
- Quando utilizzi i controlli di integrità Envoy distribuiti.
Per i bilanciatori del carico delle applicazioni esterni regionali, Google Cloud utilizza proxy Envoy open source per terminare le richieste dei client al bilanciatore del carico. Il bilanciatore del carico termina la sessione TCP e apre una nuova sessione TCP dalla subnet solo proxy della regione al backend. Le route definite all'interno della tua rete VPC facilitano la comunicazione dai proxy Envoy ai tuoi backend e dai tuoi backend ai proxy Envoy.
terminazione TLS
La tabella seguente riassume il modo in cui la terminazione TLS viene gestita dai bilanciatori del carico delle applicazioni esterni.
| Modalità del bilanciatore del carico | terminazione TLS |
|---|---|
| Bilanciatore del carico delle applicazioni esterno regionale | TLS viene terminato sui proxy Envoy situati in una subnet solo proxy in una regione scelta dall'utente. Utilizza questa modalità del bilanciatore del carico se hai bisogno di un controllo geografico sulla regione in cui viene terminato TLS. |
Timeout e nuovi tentativi
I bilanciatori del carico delle applicazioni esterni supportano i seguenti tipi di timeout per il traffico HTTP o HTTPS:
| Tipo e descrizione del timeout | Valori predefiniti | Supporta valori di timeout personalizzati | ||
|---|---|---|---|---|
| Timeout del servizio di backend1
Un timeout di richiesta e risposta. Rappresenta il tempo massimo consentito tra l'invio del primo byte di una richiesta al backend da parte del bilanciatore del carico e la restituzione dell'ultimo byte della risposta HTTP al bilanciatore del carico da parte del backend. Se il backend non ha restituito l'intera risposta HTTP al bilanciatore del carico entro questo limite di tempo, i dati della risposta rimanenti vengono ignorati. |
|
|||
Timeout della configurazione della connessione Il tempo massimo consentito al proxy per stabilire una connessione al backend. Una configurazione corretta include il completamento dell'handshake TCP a tre vie e, se il protocollo di backend è HTTPS, il completamento dell'handshake TLS.
|
4,5 secondi | |||
Timeout TLS client Il tempo massimo di attesa del proxy del bilanciatore del carico per il completamento del TLS handshake.
|
10 secondi | |||
| Timeout keepalive HTTP client
Il tempo massimo durante il quale la connessione TCP tra un client e il proxy del bilanciatore del carico può rimanere inattiva. La stessa connessione TCP potrebbe essere utilizzata per più richieste HTTP.
|
610 secondi | |||
| Timeout keepalive HTTP del backend
Il tempo massimo durante il quale la connessione TCP tra il proxy del bilanciatore del carico e un backend può rimanere inattiva. (La stessa connessione TCP potrebbe essere utilizzata per più richieste HTTP).
|
|
|||
1 Non configurabile per i backend NEG serverless. Non configurabile per i bucket di backend.
Timeout del servizio di backend
Il timeout del servizio di backend configurabile rappresenta il tempo massimo che il bilanciatore del carico attende affinché il backend elabori una richiesta HTTP e restituisca la risposta HTTP corrispondente. Ad eccezione dei NEG serverless, il valore predefinito del timeout del servizio di backend è 30 secondi.
Ad esempio, se vuoi scaricare un file da 500 MB e il valore del timeout del servizio di backend è 90 secondi, il bilanciatore del carico si aspetta che il backend fornisca l'intero file da 500 MB entro 90 secondi. È possibile configurare il timeout del servizio di backend in modo che non sia sufficiente per consentire al backend di inviare la risposta HTTP completa. In questo caso, se il bilanciatore del carico ha ricevuto almeno le intestazioni della risposta HTTP dal backend, restituisce le intestazioni della risposta complete e la parte del corpo della risposta che è riuscito a ottenere entro il timeout del servizio di backend.
Ti consigliamo di impostare il timeout del servizio di backend sul periodo di tempo più lungo che prevedi sia necessario al backend per elaborare una risposta HTTP.
Se il software in esecuzione sul backend richiede più tempo per elaborare una richiesta HTTP e restituire l'intera risposta, ti consigliamo di aumentare il timeout del servizio di backend.
Ad esempio, ti consigliamo di aumentare il timeout se vedi risposte con codice di stato HTTP 408 con errori jsonPayload.statusDetail client_timed_out.
Il timeout del servizio di backend accetta valori compresi tra 1 e 2,147,483,647
secondi; tuttavia, i valori più grandi non sono opzioni di configurazione pratiche.
Google Cloud Inoltre, non garantisce che una connessione TCP sottostante possa
rimanere aperta per l'intero valore del timeout del servizio di backend.
I sistemi client devono implementare la logica di ripetizione anziché fare affidamento su una connessione TCP aperta per lunghi periodi di tempo.
Per configurare il timeout del servizio di backend, utilizza uno dei seguenti metodi:
Console
Modifica il campo Timeout del servizio di backend del bilanciatore del carico.
gcloud
Utilizza il
comando gcloud compute backend-services update per modificare il parametro --timeout della risorsa del servizio di backend.
API
Per un bilanciatore del carico delle applicazioni esterno regionale, modifica il parametro timeoutSec per la
risorsa regionBackendServices.
| Modalità del bilanciatore del carico | Valori predefiniti | Descrizione del timeout per i websocket |
|---|---|---|
| Bilanciatore del carico delle applicazioni esterno regionale | Timeout del servizio di backend: 30 secondi | Le connessioni WebSocket attive non utilizzano il timeout del servizio di backend del bilanciatore del carico. Le connessioni WebSocket inattive vengono chiuse dopo la scadenza del timeout del servizio di backend. Google Cloud riavvia o modifica periodicamente il numero di attività software Envoy di gestione. Più lungo è il valore di timeout del servizio di backend, più è probabile che le attività Envoy riavviino o terminino le connessioni TCP. |
I bilanciatori del carico delle applicazioni esterni regionali utilizzano il parametro routeAction.timeout configurato delle mappe URL e ignorano il timeout del servizio di backend. Quando routeAction.timeout non è configurato, viene utilizzato il valore del timeout del servizio di backend. Quando viene fornito routeAction.timeout, il timeout del servizio di backend viene ignorato e il valore di routeAction.timeout viene utilizzato come timeout della richiesta e della risposta.
Timeout keepalive HTTP client
Il timeout keepalive HTTP del client rappresenta il tempo massimo durante il quale una connessione TCP può rimanere inattiva tra il client (downstream) e uno dei seguenti tipi di proxy:
- Per un bilanciatore del carico delle applicazioni esterno regionale: un proxy Envoy
Il timeout keepalive HTTP del client rappresenta il timeout di inattività TCP per le connessioni TCP sottostanti. Il timeout keepalive HTTP del client non si applica ai websocket.
Il valore predefinito per il timeout keepalive HTTP del client è 610 secondi. Per i bilanciatori del carico delle applicazioni esterni globali e regionali, puoi configurare il timeout keepalive HTTP del client con un valore compreso tra 5 e 1200 secondi.
Per configurare il timeout keepalive HTTP del client, utilizza uno dei seguenti metodi:
Console
Modifica il campo Timeout keepalive HTTP della configurazione del frontend del bilanciatore del carico.
gcloud
Per i bilanciatori del carico delle applicazioni esterni globali, utilizza il
comando gcloud compute target-http-proxies update
o il comando gcloud compute target-https-proxies update
per modificare il parametro --http-keep-alive-timeout-sec
della risorsa proxy HTTP di destinazione o proxy HTTPS di destinazione.
Per un bilanciatore del carico delle applicazioni esterno regionale, non puoi aggiornare direttamente il parametro di timeout keepalive di un proxy HTTP(S) di destinazione regionale. Per aggiornare il parametro di timeout keepalive di un proxy di destinazione a livello di regione, devi:
- Crea un nuovo proxy di destinazione con le impostazioni di timeout previste.
- Esegui il mirroring di tutte le altre impostazioni dal proxy di destinazione corrente a quello nuovo. Per i proxy HTTPS di destinazione, questo include il collegamento di eventuali certificati SSL o mappe di certificati al nuovo proxy di destinazione.
- Aggiorna le regole di forwarding in modo che puntino al nuovo proxy di destinazione.
- Elimina il proxy di destinazione precedente.
API
Per i bilanciatori del carico delle applicazioni esterni globali, modifica il parametro httpKeepAliveTimeoutSec per la
risorsa targetHttpProxies o la
risorsa targetHttpsProxies.
Per un bilanciatore del carico delle applicazioni esterno regionale, non puoi aggiornare direttamente il parametro di timeout keepalive di un proxy HTTP(S) di destinazione regionale. Per aggiornare il parametro di timeout keepalive di un proxy di destinazione a livello di regione, devi:
- Crea un nuovo proxy di destinazione con le impostazioni di timeout previste.
- Esegui il mirroring di tutte le altre impostazioni dal proxy di destinazione corrente a quello nuovo. Per i proxy HTTPS di destinazione, questo include il collegamento di eventuali certificati SSL o mappe di certificati al nuovo proxy di destinazione.
- Aggiorna le regole di forwarding in modo che puntino al nuovo proxy di destinazione.
- Elimina il proxy di destinazione precedente.
Il timeout keepalive HTTP del client del bilanciatore del carico deve essere maggiore del timeout keepalive HTTP (TCP inattivo) utilizzato dai client o dai proxy downstream. Se un client downstream ha un timeout di keepalive HTTP (inattività TCP) maggiore del timeout di keepalive HTTP del client del bilanciatore del carico, è possibile che si verifichi una race condition. Dal punto di vista di un client downstream, una connessione TCP stabilita può rimanere inattiva per un periodo di tempo superiore a quello consentito dal bilanciatore del carico. Ciò significa che il client downstream può inviare pacchetti dopo che il bilanciatore del carico considera chiusa la connessione TCP. In questo caso, il bilanciatore del carico risponde con un pacchetto di reimpostazione TCP (RST).
Quando scade il timeout keepalive HTTP del client, il GFE o il proxy Envoy invia un TCP FIN al client per chiudere correttamente la connessione.
Timeout keepalive HTTP del backend
I bilanciatori del carico delle applicazioni esterni sono proxy che utilizzano almeno due connessioni TCP:
- Per un bilanciatore del carico delle applicazioni esterno regionale, esiste una prima connessione TCP tra il client (downstream) e un proxy Envoy. Il proxy Envoy apre quindi una seconda connessione TCP ai tuoi backend.
Le connessioni TCP secondarie del bilanciatore del carico potrebbero non essere chiuse dopo ogni richiesta; possono rimanere aperte per gestire più richieste e risposte HTTP. Il timeout keepalive HTTP del backend definisce il timeout di inattività TCP tra il bilanciatore del carico e i backend. Il timeout keepalive HTTP del backend non si applica ai WebSocket.
Il timeout di keepalive del backend è fissato a 10 minuti (600 secondi) e non può essere modificato. In questo modo, il bilanciatore del carico mantiene le connessioni inattive per almeno 10 minuti. Trascorso questo periodo, il bilanciatore del carico può inviare pacchetti di terminazione al backend in qualsiasi momento.
Il timeout keepalive del backend del bilanciatore del carico deve essere inferiore al timeout keepalive utilizzato dal software in esecuzione sui backend. In questo modo si evita una race condition in cui il sistema operativo dei backend potrebbe chiudere le connessioni TCP con un reset TCP (RST). Poiché il timeout keepalive del backend per il bilanciatore del carico non è configurabile, devi configurare il software di backend in modo che il valore di timeout keepalive HTTP (TCP inattivo) sia maggiore di 600 secondi.
Quando scade il timeout keepalive HTTP del backend, il GFE o il proxy Envoy invia un TCP FIN alla VM di backend per chiudere correttamente la connessione.
La tabella seguente elenca le modifiche necessarie per modificare i valori di timeout keepalive per i software server web più comuni.
| Software server web | Parametro | Impostazione predefinita | Impostazione consigliata |
|---|---|---|---|
| Apache | KeepAliveTimeout | KeepAliveTimeout 5 |
KeepAliveTimeout 620 |
| nginx | keepalive_timeout | keepalive_timeout 75s; |
keepalive_timeout 620s; |
Nuovi tentativi
Il supporto della logica di ripetizione dipende dalla modalità del bilanciatore del carico delle applicazioni esterno.
| Modalità del bilanciatore del carico | Logica di ripetizione dei tentativi |
|---|---|
| Bilanciatore del carico delle applicazioni esterno regionale |
Configurabile utilizzando una policy di ripetizione nella mappa URL. Il numero predefinito di nuovi tentativi ( Senza una policy di ripetizione, le richieste non riuscite che non hanno un corpo HTTP (ad esempio, le richieste Le richieste HTTP Le richieste ripetute generano una sola voce di log per la risposta finale. |
Il protocollo WebSocket è supportato con GKE Ingress.
Gestione di richieste e risposte illegali
Il bilanciatore del carico impedisce alle richieste del client e alle risposte del backend di raggiungere rispettivamente il backend o il client per una serie di motivi. Alcuni motivi sono strettamente legati alla conformità con HTTP/1.1, mentre altri servono a evitare che vengano trasmessi dati imprevisti da o verso i backend. Nessuno dei controlli può essere disattivato.
La tabella seguente specifica i diversi tipi di richieste bloccate dai bilanciatori del carico delle applicazioni esterni per la conformità a HTTP/1.1.
In questa tabella, indica una richiesta bloccata dal bilanciatore del carico, mentre indica una richiesta consentita dal bilanciatore del carico.
| Tipo di richiesta | Bilanciatore del carico delle applicazioni esterno globale | Bilanciatore del carico delle applicazioni classico | Bilanciatore del carico delle applicazioni esterno regionale |
|---|---|---|---|
| Impossibile analizzare la prima riga della richiesta. | |||
| In un'intestazione manca il delimitatore due punti (:). | |||
| Le intestazioni o la prima riga contengono caratteri non validi. | |||
| La lunghezza dei contenuti non è un numero valido o sono presenti più intestazioni di lunghezza dei contenuti. | |||
| Sono presenti più chiavi di codifica di trasferimento o sono presenti valori di codifica di trasferimento non riconosciuti. | |||
| È presente un corpo non suddiviso in blocchi e non è specificata la lunghezza dei contenuti. | 1 | ||
| I blocchi del corpo non sono analizzabili. Questo è l'unico caso in cui alcuni dati raggiungono il backend. Il bilanciatore del carico chiude le connessioni al client e al backend quando riceve un chunk non analizzabile. |
1 Il proxy restituisce una risposta HTTP 411 per la richiesta, ma tenta di analizzare il corpo non suddiviso in blocchi come richiesta successiva. Se il corpo non in chunk è una richiesta HTTP valida, viene analizzato e inviato al backend.
Gestione delle richieste
La tabella seguente specifica quali bilanciatori del carico delle applicazioni esterni bloccano una richiesta se soddisfa una delle condizioni elencate nella prima colonna della tabella.
In questa tabella, indica una richiesta bloccata dal bilanciatore del carico, mentre indica una richiesta consentita dal bilanciatore del carico.
Gestione delle risposte
La tabella seguente specifica quali bilanciatori del carico delle applicazioni esterni bloccano una richiesta se soddisfa una delle condizioni elencate nella prima colonna della tabella.
In questa tabella, indica una richiesta bloccata dal bilanciatore del carico, mentre indica una richiesta consentita dal bilanciatore del carico.
| Condizione | Bilanciatore del carico delle applicazioni esterno globale | Bilanciatore del carico delle applicazioni classico | Bilanciatore del carico delle applicazioni esterno regionale |
|---|---|---|---|
| La dimensione totale delle intestazioni della risposta supera il limite per la dimensione massima dell'intestazione della risposta per il bilanciatore del carico. | |||
| La versione HTTP è sconosciuta. |
Durante la gestione della richiesta e della risposta, il bilanciatore del carico potrebbe rimuovere o sovrascrivere le intestazioni hop-by-hop in HTTP/1.1 prima di inoltrarle alla destinazione prevista.
Distribuzione del traffico
Quando aggiungi un gruppo di istanza di backend o un NEG a un servizio di backend, specifichi una modalità di bilanciamento, che definisce un metodo per misurare il carico del backend e una capacità target. I bilanciatori del carico delle applicazioni esterni supportano due modalità di bilanciamento:
RATE, per i gruppi di istanze o i NEG, è il numero massimo target di richieste (query) al secondo (RPS, QPS). Il numero massimo di RPS/QPS target può essere superato se tutti i backend hanno raggiunto o superato la capacità.UTILIZATIONè l'utilizzo del backend delle VM in un gruppo di istanze.
La modalità di distribuzione del traffico tra i backend dipende dalla modalità del bilanciatore del carico.
Bilanciatore del carico delle applicazioni esterno regionale
Per i bilanciatori del carico delle applicazioni esterni regionali, la distribuzione del traffico si basa sulla modalità di bilanciamento del carico e sulla policy di località del bilanciamento del carico.
La modalità di bilanciamento determina il peso e la frazione di traffico da inviare a ciascun gruppo (gruppo di istanze o NEG). La policy di località del bilanciamento del carico (LocalityLbPolicy) determina il modo in cui viene bilanciato il carico dei backend all'interno del gruppo.
Quando un servizio di backend riceve il traffico, lo indirizza prima a un backend (gruppo di istanze o NEG) in base alla modalità di bilanciamento del backend. Dopo aver selezionato un backend, il traffico viene distribuito tra le istanze o gli endpoint nel gruppo di backend in base alla policy di località del bilanciamento del carico.
Per ulteriori informazioni, consulta le seguenti risorse:
- Modalità di bilanciamento
- Policy di località del bilanciamento del carico (documentazione dell'API del servizio di backend regionale).
Affinità di sessione
L'affinità di sessione, configurata sul servizio di backend dei bilanciatori del carico delle applicazioni, fornisce un tentativo best effort di inviare richieste da un determinato client allo stesso backend, purché il numero di istanze o endpoint di backend integri rimanga costante e l'istanza o l'endpoint di backend selezionato in precedenza non abbia raggiunto la capacità massima. La capacità target della modalità di bilanciamento determina quando il backend è al massimo della capacità.
La tabella seguente illustra i diversi tipi di opzioni di affinità sessione supportati per i diversi bilanciatori del carico delle applicazioni. Nella sezione seguente, Tipi di affinità di sessione, ogni tipo di affinità sessione viene descritto in maggiore dettaglio.
| Prodotto | Opzioni di affinità di sessione |
|---|---|
|
Bilanciatore del carico delle applicazioni esterno regionale |
Inoltre, tieni presente quanto segue:
|
Tieni presente quanto segue quando configuri l'affinità sessione:
Non fare affidamento sull'affinità sessione per scopi di autenticazione o sicurezza. L'affinità di sessione, ad eccezione dell'affinità di sessione basata su cookie stateful, può interrompersi ogni volta che cambia il numero di backend attivi e integri. Per maggiori dettagli, consulta Perdita dell'affinità di sessione.
I valori predefiniti dei flag
--session-affinitye--subsetting-policysono entrambiNONEe solo uno alla volta può essere impostato su un valore diverso.
Tipi di affinità sessione
L'affinità sessione per i bilanciatori del carico delle applicazioni esterni può essere classificata in una delle seguenti categorie:- Affinità sessione basata su hash (
NONE,CLIENT_IP) - Affinità sessione basata su intestazione HTTP (
HEADER_FIELD) - Affinità sessione basata sui cookie (
GENERATED_COOKIE,HTTP_COOKIE,STRONG_COOKIE_AFFINITY)
Affinità sessione basata su hash
Per l'affinità sessione basata su hash, il bilanciatore del carico utilizza l'algoritmo di hashing coerente per selezionare un backend idoneo. L'impostazione dell'affinità sessione determina quali campi dell'intestazione IP vengono utilizzati per calcolare l'hash.
L'affinità sessione basata su hash può essere dei seguenti tipi:
Nessuno
Un'impostazione di affinità sessione pari a NONE non significa che non esiste un'affinità sessione. Ciò significa che non è configurata esplicitamente alcuna opzione di affinità sessione.
L'hashing viene sempre eseguito per selezionare un backend. Un'impostazione di affinità sessione pari a NONE indica che il bilanciatore del carico utilizza un hash a 5 tuple per selezionare un backend. L'hash a 5 tuple è costituito dall'indirizzo IP di origine, dalla porta di origine, dal protocollo, dall'indirizzo IP di destinazione e dalla porta di destinazione.
Un'affinità sessione NONE è il valore predefinito.
Affinità IP client
L'affinità sessione IP client (CLIENT_IP) è un hash di 2 tuple creato dagli indirizzi IP di origine e di destinazione del pacchetto. L'affinità IP client inoltra tutte le richieste provenienti dallo stesso indirizzo IP client allo stesso backend, purché quest'ultimo abbia capacità e rimanga integro.
Quando utilizzi l'affinità IP client, tieni presente quanto segue:
- L'indirizzo IP di destinazione del pacchetto è uguale all'indirizzo IP della regola di forwarding del bilanciatore del carico solo se il pacchetto viene inviato direttamente al bilanciatore del carico.
- L'indirizzo IP di origine del pacchetto potrebbe non corrispondere a un indirizzo IP associato al client originale se il pacchetto viene elaborato da un sistema NAT o proxy intermedio prima di essere consegnato a un bilanciatore del carico Google Cloud . In situazioni in cui molti client condividono lo stesso indirizzo IP di origine effettivo, alcune VM di backend potrebbero ricevere più connessioni o richieste rispetto ad altre.
Affinità sessione basata su intestazione HTTP
Con l'affinità del campo di intestazione (HEADER_FIELD), le richieste vengono indirizzate ai backend in base al valore dell'intestazione HTTP nel campo consistentHash.httpHeaderName del servizio di backend. Per distribuire le richieste tra tutti i backend disponibili,
ogni client deve utilizzare un valore di intestazione HTTP diverso.
L'affinità del campo dell'intestazione è supportata se sono soddisfatte le seguenti condizioni:
- La policy di località di bilanciamento del carico è
RING_HASHoMAGLEV. - Il campo
consistentHashdel servizio di backend specifica il nome dell'intestazione HTTP (httpHeaderName).
Affinità sessione basata sui cookie
L'affinità sessione basata su cookie può essere dei seguenti tipi:
Affinità cookie generato
Quando utilizzi l'affinità basata su cookie generati (GENERATED_COOKIE), il bilanciatore del carico include un cookie HTTP nell'intestazione Set-Cookie in risposta alla richiesta HTTP iniziale.
Il nome del cookie generato varia a seconda del tipo di bilanciatore del carico.
| Prodotto | Nome cookie |
|---|---|
| Bilanciatori del carico delle applicazioni esterni globali | GCLB |
| Bilanciatori del carico delle applicazioni classici | GCLB |
| Bilanciatori del carico delle applicazioni esterni regionali | GCILB |
L'attributo del percorso del cookie generato è sempre una barra (/), quindi si applica a tutti i servizi di backend nella stessa mappa URL, a condizione che anche gli altri servizi di backend utilizzino l'affinità cookie generato.
Puoi configurare il valore della durata (TTL) del cookie tra 0 e
1,209,600 secondi (inclusi) utilizzando il parametro del servizio di backend affinityCookieTtlSec. Se affinityCookieTtlSec non è specificato, il valore TTL predefinito è 0.
Quando il client include il cookie di affinità sessione generato nell'intestazione della richiesta Cookie delle richieste HTTP, il bilanciatore del carico indirizza queste richieste alla stessa istanza di backend o allo stesso endpoint, purché il cookie di affinità di sessione rimanga valido. A questo scopo, il valore del cookie viene mappato a un indice che fa riferimento a un'istanza di backend o a un endpoint specifico e viene verificato che i requisiti di affinità sessione del cookie generato siano soddisfatti.
Per utilizzare l'affinità cookie generato, configura le seguenti impostazioni della modalità di bilanciamento e di localityLbPolicy:
- Per i gruppi di istanza di backend, utilizza la modalità di bilanciamento
RATE. - Per
localityLbPolicydel servizio di backend, utilizzaRING_HASHoMAGLEV. Se non imposti esplicitamentelocalityLbPolicy, il bilanciatore del carico utilizzaMAGLEVcome valore predefinito implicito.
Per saperne di più, consulta la sezione sulla perdita dell'affinità di sessione.
Affinità cookie HTTP
Quando utilizzi l'affinità basata su cookie HTTP (HTTP_COOKIE), il bilanciatore del carico include un cookie HTTP nell'intestazione Set-Cookie in risposta alla richiesta HTTP iniziale. Specifica il nome, il percorso e la durata (TTL) del cookie.
Tutti i bilanciatori del carico delle applicazioni supportano l'affinità basata su cookie HTTP.
Puoi configurare i valori TTL del cookie utilizzando secondi, frazioni di secondo (come nanosecondi) o entrambi i secondi più frazioni di secondo (come nanosecondi) utilizzando i seguenti parametri del servizio di backend e i valori validi:
consistentHash.httpCookie.ttl.secondspuò essere impostato su un valore compreso tra0e315576000000(inclusi).consistentHash.httpCookie.ttl.nanospuò essere impostato su un valore compreso tra0e999999999(inclusi). Poiché le unità sono nanosecondi,999999999significa.999999999secondi.
Se non vengono specificati né consistentHash.httpCookie.ttl.seconds né consistentHash.httpCookie.ttl.nanos, viene utilizzato il valore del parametro del servizio di backend affinityCookieTtlSec. Se affinityCookieTtlSec non è specificato, il valore TTL predefinito è 0.
Quando il client include il cookie di affinità sessione HTTP nell'intestazione della richiesta Cookie delle richieste HTTP, il bilanciatore del carico indirizza queste richieste alla stessa istanza di backend o allo stesso endpoint, purché il cookie di affinità di sessione rimanga valido. A questo scopo, il valore del cookie viene mappato a un indice che fa riferimento a un'istanza di backend o a un endpoint specifico e viene verificato che i requisiti di affinità sessione del cookie generato siano soddisfatti.
Per utilizzare l'affinità cookie HTTP, configura le seguenti impostazioni della modalità di bilanciamento e di localityLbPolicy:
- Per i gruppi di istanza di backend, utilizza la modalità di bilanciamento
RATE. - Per
localityLbPolicydel servizio di backend, utilizzaRING_HASHoMAGLEV. Se non imposti esplicitamentelocalityLbPolicy, il bilanciatore del carico utilizzaMAGLEVcome valore predefinito implicito.
Per saperne di più, consulta la sezione sulla perdita dell'affinità di sessione.
Affinità sessione basata su cookie stateful
Quando utilizzi l'affinità basata su cookie stateful (STRONG_COOKIE_AFFINITY), il bilanciatore del carico include un cookie HTTP nell'intestazione Set-Cookie in risposta alla richiesta HTTP iniziale. Specifica il nome, il percorso e la durata (TTL) del cookie.
I seguenti bilanciatori del carico supportano l'affinità basata su cookie stateful:
- Bilanciatori del carico delle applicazioni esterni regionali
- Bilanciatori del carico delle applicazioni interni regionali
Puoi configurare i valori TTL del cookie utilizzando secondi, frazioni di secondo (come nanosecondi) o entrambi i secondi più frazioni di secondo (come nanosecondi).
La durata rappresentata da strongSessionAffinityCookie.ttl non può essere impostata su un valore che rappresenta più di due settimane (1.209.600 secondi).
Il valore del cookie identifica un'istanza o un endpoint di backend selezionato codificando l'istanza o l'endpoint selezionato nel valore stesso. Finché il cookie è valido, se il client include il cookie di affinità sessione nell'intestazione della richiesta Cookie delle richieste HTTP successive, il bilanciatore del carico indirizza queste richieste all'istanza di backend o all'endpoint selezionato.
A differenza di altri metodi di affinità sessione:
L'affinità basata su cookie stateful non ha requisiti specifici per la modalità di bilanciamento o per la policy di bilanciamento del carico per le località (
localityLbPolicy).L'affinità basata su cookie stateful non è interessata quando la scalabilità automatica aggiunge una nuova istanza a un gruppo di istanze gestite.
L'affinità stateful basata su cookie non è interessata quando la scalabilità automatica rimuove un'istanza da un gruppo di istanze gestite, a meno che non venga rimossa l'istanza selezionata.
L'affinità stateful basata su cookie non è interessata quando la riparazione automatica rimuove un'istanza da un gruppo di istanze gestite, a meno che non venga rimossa l'istanza selezionata.
Per saperne di più, consulta la sezione sulla perdita dell'affinità di sessione.
Significato di TTL pari a zero per le affinità basate su cookie
Tutte le affinità di sessione basate su cookie, come l'affinità cookie generato, l'affinità cookie HTTP e l'affinità basata su cookie stateful, hanno un attributo TTL.
Un TTL di zero secondi indica che il bilanciatore del carico non assegna un attributo Expires al cookie. In questo caso, il client tratta il cookie come un cookie di sessione. La definizione di una sessione varia a seconda del client:
Alcuni client, come i browser web, conservano il cookie per l'intera sessione di navigazione. Ciò significa che il cookie persiste tra più richieste fino alla chiusura dell'applicazione.
Altri client trattano una sessione come una singola richiesta HTTP, eliminando il cookie immediatamente dopo.
Perdita dell'affinità sessione
Tutte le opzioni di affinità sessione richiedono quanto segue:
- L'istanza di backend o l'endpoint selezionato deve rimanere configurato come backend. L'affinità di sessione può interrompersi quando si verifica uno dei seguenti eventi:
- Rimuovi l'istanza selezionata dal relativo gruppo di istanze.
- La scalabilità automatica o la riparazione automatica del gruppo di istanze gestite rimuove l'istanza selezionata dal relativo gruppo di istanze gestite.
- Rimuovi l'endpoint selezionato dal relativo NEG.
- Rimuovi dal servizio di backend il gruppo di istanze o il NEG che contiene l'istanza o l'endpoint selezionato.
- L'istanza o l'endpoint di backend selezionato deve rimanere integro. L'affinità di sessione può interrompersi quando l'istanza o l'endpoint selezionato non supera i controlli di integrità.
- Per i bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico delle applicazioni classici, l'affinità sessione può interrompersi se viene utilizzato un Google Front End (GFE) di primo livello diverso per le richieste o le connessioni successive dopo la modifica del percorso di routing. Se il percorso di routing da un client su internet a Google cambia tra le richieste o le connessioni, potrebbe essere selezionato un GFE di primo livello diverso.
Il gruppo di istanze o il NEG che contiene l'istanza o l'endpoint selezionato non deve essere pieno, come definito dalla sua capacità target. (Per i gruppi di istanze gestite a livello di regione, il componente a livello di zona del gruppo di istanze che contiene l'istanza selezionata non deve essere pieno.) L'affinità di sessione può interrompersi quando il gruppo di istanze o il NEG è pieno e altri gruppi di istanze o NEG non lo sono. Poiché la pienezza può cambiare in modi imprevedibili quando utilizzi la modalità di bilanciamento
UTILIZATION, devi utilizzare la modalità di bilanciamentoRATEoCONNECTIONper ridurre al minimo le situazioni in cui l'affinità sessione può interrompersi.Il numero totale di istanze o endpoint di backend configurati deve rimanere costante. Quando si verifica almeno uno dei seguenti eventi, il numero di istanze di backend o endpoint configurati cambia e l'affinità sessione può interrompersi:
Aggiunta di nuove istanze o endpoint:
- Aggiungi istanze a un gruppo di istanze esistente nel servizio di backend.
- La scalabilità automatica dei gruppi di istanze gestite aggiunge istanze a un gruppo di istanze gestite nel servizio di backend.
- Aggiungi endpoint a un NEG esistente nel servizio di backend.
- Aggiungi gruppi di istanze o NEG non vuoti al servizio di backend.
Rimozione di qualsiasi istanza o endpoint, non solo dell'istanza o dell'endpoint selezionati:
- Rimuovi un'istanza dal backend di un gruppo di istanze.
- La scalabilità automatica o il ripristino automatico del gruppo di istanze gestite rimuove un'istanza dal backend di un gruppo di istanze gestite.
- Rimuovi un endpoint da un backend NEG.
- Rimuovi dal servizio di backend qualsiasi gruppo di istanza di backend o NEG esistente e non vuoto.
Il numero totale di istanze di backend o endpoint integri deve rimanere costante. Quando si verifica almeno uno dei seguenti eventi, il numero di istanze o endpoint di backend integri cambia e l'affinità sessione può interrompersi:
- Qualsiasi istanza o endpoint supera il controllo di integrità, passando da non integro a integro.
- Qualsiasi istanza o endpoint non supera il controllo di integrità, passando da integro a non integro o timeout.