Distribuzione delle richieste per i bilanciatori del carico delle applicazioni esterni

Questo documento analizza le complessità del modo in cui i bilanciatori del carico delle applicazioni esterni gestiscono le connessioni, indirizzano il traffico e mantengono l&#39affinità sessionee.

Come funzionano le connessioni

I bilanciatori del carico delle applicazioni esterni diTrusted 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 la distribuzione di applicazioni scalabili e conformi a livello mondiale 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. L'Application Load Balancer esterno regionale utilizza una subnet condivisa chiamata subnet solo proxy per provisionare 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 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 dalla subnet solo proxy.

A seconda della configurazione del servizio di backend, il protocollo utilizzato dai proxy Envoy per connettersi ai tuoi backend può essere HTTP, HTTPS o HTTP/2. Se HTTP o HTTPS, la versione HTTP è HTTP 1.1. HTTP keepalive è abilitato per impostazione predefinita, come specificato nella specifica HTTP 1.1. Il proxy Envoy imposta sia il timeout keep-alive HTTP del client sia il timeout keep-alive 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 di richiesta/risposta impostando il timeout del servizio di backend. Per saperne di più, consulta Timeout e tentativi.

Comunicazioni del client con il bilanciatore del carico

• I client possono comunicare con il bilanciatore del carico utilizzando il protocollo HTTP 1.1 o HTTP/2.
• Quando viene utilizzato HTTPS, i client moderni utilizzano HTTP/2 per impostazione predefinita. Questo comportamento è controllato sul client, non sul bilanciatore del carico HTTPS.
• Non puoi disattivare HTTP/2 apportando una modifica alla 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 per i pacchetti, come visto dai backend, non è l'indirizzo IP esterno del bilanciatore del carico.Trusted Cloud 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 inoltro).
  • Indirizzo IP di destinazione: l'indirizzo IP del bilanciatore del carico.

• Connessione 2, dal bilanciatore del carico (subnet solo proxy) alla VM di backend o endpoint:

  • 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 di backend o del container nella rete VPC.

Percorsi di routing speciali

Trusted Cloud utilizza route speciali non definiti nella 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à.

Trusted 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à distribuiti di Envoy.

Per i bilanciatori del carico delle applicazioni esterni regionali, Trusted 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 ne apre una nuova dalla subnet solo proxy della regione al backend. Le route definite all'interno della rete VPC facilitano la comunicazione dai proxy Envoy ai backend e dai backend ai proxy Envoy.

terminazione TLS

La seguente tabella riassume la gestione della terminazione TLS da parte dei bilanciatori del carico delle applicazioni esterni.

Modalità del bilanciatore del carico	terminazione TLS
Bilanciatore del carico delle applicazioni esterno regionale	Il protocollo TLS viene terminato sui proxy Envoy che si trovano 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 dal bilanciatore del carico al backend e la restituzione dell'ultimo byte della risposta HTTP al bilanciatore del carico. Se il backend non ha restituito l'intera risposta HTTP al bilanciatore del carico entro questo limite di tempo, i dati di risposta rimanenti vengono eliminati.	Per tutti gli altri tipi di backend su un servizio di backend: 30 secondi
Timeout keepalive HTTP client La quantità massima di tempo in cui 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.) Per i bilanciatori del carico delle applicazioni esterni regionali, il proxy del bilanciatore del carico è il software Envoy.	610 secondi
Timeout keepalive HTTP di 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.) Per i bilanciatori del carico delle applicazioni esterni regionali, il proxy del bilanciatore del carico è il software Envoy.	Per i servizi di backend: 10 minuti (600 secondi)

Timeout del servizio di backend

Il timeout del servizio di backend configurabile rappresenta la quantità massima di tempo in cui il bilanciatore del carico attende che il backend elabori una richiesta HTTP e restituisca la risposta HTTP corrispondente. Ad eccezione dei NEG serverless, il valore predefinito per il 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 questa situazione, 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 che il backend impieghi per elaborare una risposta HTTP. Se il software in esecuzione sul backend ha bisogno di 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 visualizzi 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, valori più grandi non sono opzioni di configurazione pratiche. Trusted Cloud inoltre non garantisce che una connessione TCP sottostante possa rimanere aperta per l'intera durata 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:

I timeout della connessione WebSocket non sono sempre uguali ai timeout del servizio di backend. I timeout della connessione WebSocket dipendono dal tipo di bilanciatore del carico:

Modalità del bilanciatore del carico	Valori predefiniti	Descrizione del timeout per i WebSocket
Bilanciatore del carico delle applicazioni esterno regionale	servizio di backend timeout: 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 il timeout del servizio di backend. Trusted Cloud riavvia o modifica periodicamente il numero di attività del software Envoy. Più lungo è il valore di timeout del servizio di backend, più è probabile che i task Envoy vengano riavviati o che le connessioni TCP vengano terminate.

I bilanciatori del carico delle applicazioni esterni regionali utilizzano il parametro routeActions.timeout configurato delle mappe URL e ignorano il timeout del servizio di backend. Quando routeActions.timeout non è configurato, viene utilizzato il valore del timeout del servizio di backend. Quando viene fornito routeActions.timeout, il timeout del servizio di backend viene ignorato e il valore di routeActions.timeout viene utilizzato come timeout di richiesta e risposta.

Timeout keepalive HTTP client

Il timeout keepalive HTTP del client rappresenta la quantità massima di tempo in cui 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:

Il timeout keepalive HTTP del client del bilanciatore del carico deve essere maggiore del timeout keepalive HTTP (inattività TCP) utilizzato dai client o dai proxy downstream. Se un client downstream ha un timeout HTTP keepalive (inattività TCP) maggiore del timeout HTTP keepalive del client del bilanciatore del carico, è possibile che si verifichi una condizione di competizione. Dal punto di vista di un client downstream, una connessione TCP stabilita può rimanere inattiva per un periodo di tempo più lungo di quello consentito dal bilanciatore del carico. Ciò significa che il client downstream può inviare pacchetti dopo che il bilanciamento del carico considera chiusa la connessione TCP. In questo caso, il bilanciatore del carico risponde con un pacchetto di ripristino TCP (RST).

Quando scade il timeout keepalive HTTP del client, il proxy GFE o 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 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 keepalive del backend è impostato su 10 minuti (600 secondi) e non può essere modificato. Ciò contribuisce a garantire che il bilanciatore del carico mantenga 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 (inattività TCP) sia superiore a 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 il software del server web comune.

Software del 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 per la logica di ripetizione dipende dalla modalità del bilanciatore del carico delle applicazioni esterno.

Modalità del bilanciatore del carico

Logica di ripetizione

Bilanciatore del carico delle applicazioni esterno regionale

Configurabile utilizzando un criterio di tentativo ripetuto nella mappa URL. Il numero predefinito di tentativi (numRetries) è 1. Il numero massimo di tentativi che possono essere configurati utilizzando il criterio di ripetizione è 25. Il perTryTimeout massimo configurabile è 24 ore. Senza un criterio di ripetizione, le richieste non andate a buon fine che non hanno un corpo HTTP (ad esempio, le richieste GET) che generano risposte HTTP 502, 503 o 504 vengono riprovate una volta. I tentativi di richiesta HTTP POST non vengono ripetuti. Le richieste riprovare generano una sola voce di log per la risposta finale.

Il protocollo WebSocket è supportato con GKE Ingress.

Gestione di richieste e risposte non consentite

Il bilanciatore del carico blocca le richieste dei client e le risposte del backend che raggiungono il backend o il client, rispettivamente, per diversi motivi. Alcuni motivi sono strettamente legati alla conformità a HTTP/1.1, mentre altri servono a evitare il passaggio di dati inattesi ai backend o dai backend. Nessuno dei controlli può essere disattivato.

Per conformità a HTTP/1.1, il bilanciatore del carico blocca le seguenti richieste:

• Non è in grado di analizzare la prima riga della richiesta.
• In un'intestazione manca il delimitatore dei 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.
• Esistono più chiavi di codifica del trasferimento o valori di codifica del trasferimento non riconosciuti.
• Il corpo non è suddiviso in blocchi e non è stata specificata la lunghezza dei contenuti.
• 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.

Gestione delle richieste

Il bilanciatore del carico blocca la richiesta se si verifica una delle seguenti condizioni:

• La dimensione totale delle intestazioni della richiesta e dell'URL della richiesta supera il limite per la dimensione massima dell'intestazione della richiesta per i bilanciatori del carico delle applicazioni esterni.
• Il metodo della richiesta non consente un corpo, ma la richiesta ne ha uno.
• La richiesta contiene un'intestazione Upgrade e l'intestazione Upgrade non viene utilizzata per attivare le connessioni WebSocket.
• La versione HTTP è sconosciuta.

Gestione delle risposte

Il bilanciatore del carico blocca la risposta del backend se una delle seguenti condizioni è vera:

• Le dimensioni totali delle intestazioni della risposta superano il limite per la dimensione massima dell'intestazione della risposta per i bilanciatori del carico delle applicazioni esterni.
• La versione HTTP è sconosciuta.

Quando gestisce sia la richiesta sia la 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 di misurazione del carico di backend e una capacità target. I bilanciatori del carico delle applicazioni esterni supportano due modalità di bilanciamento:

• RATE, ad esempio per gruppi di istanze o NEG, è il numero massimo target di richieste (query) al secondo (RPS, QPS). Il RPS/QPS massimo target può essere superato se tutti i backend sono al limite di capacità o lo superano.

• UTILIZATION è l'utilizzo del backend delle VM in un gruppo di istanze.

La 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 sul criterio di località di 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). Il criterio di località di bilanciamento del carico (LocalityLbPolicy) determina la modalità di bilanciamento del carico dei backend all'interno del gruppo.

Quando un servizio di backend riceve traffico, lo indirizza prima a un backend (gruppo di istanze o NEG) in base alla modalità di bilanciamento del backend. Una volta selezionato un backend, il traffico viene distribuito tra le istanze o gli endpoint del gruppo di backend in base al criterio di località del bilanciamento del carico.

Per ulteriori informazioni, consulta le seguenti risorse:

• Modalità di bilanciamento
• Policy di località di bilanciamento del carico (documentazione dell'API del servizio di backend regionale).

Affinità sessione

L'affinità di sessione, configurata nel servizio di backend dei bilanciatori del carico delle applicazioni, fornisce un tentativo ottimale di inviare le richieste di un determinato client allo stesso backend, a condizione che il numero di istanze o endpoint di backend integri rimanga costante e che l'istanza o l'endpoint di backend selezionato in precedenza non sia al massimo della capacità. La capacità target della modalità di bilanciamento determina quando il backend è al massimo della capacità.

La seguente tabella descrive i diversi tipi di opzioni di affinità sessione supportate per i diversi bilanciatori del carico delle applicazioni. Nella sezione che segue, Tipi di affinità sessione, ogni tipo di affinità sessione viene descritto in modo più dettagliato.

Tabella: impostazioni di affinità sessione supportate

Prodotto

Opzioni di affinità sessione

Bilanciatore del carico delle applicazioni esterno regionale

Nessuna (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE) Campo intestazione (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Affinità stateful basata sui cookie (STRONG_COOKIE_AFFINITY) Tieni presente anche: Il valore predefinito effettivo della policy di bilanciamento del carico per le località (localityLbPolicy) cambia in base alle impostazioni di affinità di sessione. Se l'affinità sessione non è configurata, ovvero se l'affinità sessione rimane al valore predefinito di NONE, allora il valore predefinito per localityLbPolicy è ROUND_ROBIN. Se l'affinità sessione è impostata su un valore diverso da NONE, il valore predefinito per localityLbPolicy è MAGLEV.

Tieni presente quanto segue durante la configurazione dell'affinità sessione:

• Non fare affidamento sull'affinità sessione per l'autenticazione o per motivi di 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 di pubblicazione integri. Per ulteriori dettagli, consulta Perdita dell'affinità di sessione.

• I valori predefiniti dei flag --session-affinity e --subsetting-policy sono entrambi NONE e 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 sull'hash (NONE, CLIENT_IP)
• Affinità sessione basata sull'intestazione HTTP (HEADER_FIELD)
• Affinità sessione basata sui cookie (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

Affinità sessione basata sull'hash

Per l'affinità sessione basata sull'hashing, 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 sull'hash può essere dei seguenti tipi:

• Nessuna
• Affinità IP client

Nessuno

Un'impostazione di affinità sessione pari a NONE non significa che non esiste 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 di NONE indica che il bilanciatore del carico utilizza un hash a 5 tuple per selezionare un backend. L'hash a 5 tuple è formato da indirizzo IP di origine, porta di origine, protocollo, indirizzo IP di destinazione e porta di destinazione.

Un'affinità sessione di NONE è il valore predefinito.

Affinità IP client

L'affinità sessione (CLIENT_IP) dell'IP client è un hash a due tuple creato a partire dagli indirizzi IP di origine e di destinazione del pacchetto. L'affinità IP client inoltra tutte le richieste dallo stesso indirizzo IP client allo stesso backend, a condizione che questo backend 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. Trusted 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 sull'intestazione HTTP

Con l'affinità del campo di intestazione (HEADER_FIELD), le richieste vengono instradate ai backend in base al valore dell'intestazione HTTP nel campo consistentHash.httpHeaderName del servizio di backend. Per distribuire le richieste su tutti i backend disponibili, ogni client deve utilizzare un valore di intestazione HTTP diverso.

L'affinità del campo di intestazione è supportata quando sono vere le seguenti condizioni:

• Il criterio di bilanciamento del carico per le località è RING_HASH o MAGLEV.
• consistentHash del servizio di backend specifica il nome dell'intestazione HTTP (httpHeaderName).

Affinità sessione basata sui cookie

L'affinità sessione basata sui cookie può essere dei seguenti tipi:

• Affinità cookie generato
• Affinità cookie HTTP
• Affinità sessione basata su cookie stateful

Affinità cookie generato

Quando utilizzi l'affinità basata sui 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 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 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 allo stesso endpoint o alla stessa istanza di backend, finché il cookie di affinità sessione rimane valido. Ciò avviene mappando il valore del cookie a un indice che fa riferimento a unistanza di backend o a un endpoint specifici e assicurandosi che i requisiti di affinità sessione dei cookie generati siano soddisfatti.

Per utilizzare l'affinità cookie generato, configura la seguente modalità di bilanciamento e le impostazioni localityLbPolicy:

• Per i gruppi di istanza di backend, utilizza la modalità di bilanciamento RATE.
• Per localityLbPolicy del servizio di backend, utilizza RING_HASH o MAGLEV. Se non imposti esplicitamente localityLbPolicy, il bilanciatore del carico utilizza MAGLEV come valore predefinito implicito.

Per saperne di più, consulta la sezione sulla perdita dell'affinità sessione.

Affinità cookie HTTP

Quando utilizzi l'affinità basata sui 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 sui cookie HTTP.

Puoi configurare i valori TTL del cookie utilizzando secondi, frazioni di secondo (come nanosecondi) o sia secondi che frazioni di secondo (come nanosecondi) utilizzando i seguenti parametri del servizio di backend e valori validi:

• consistentHash.httpCookie.ttl.seconds può essere impostato su un valore compreso tra 0 e 315576000000 (inclusi).
• consistentHash.httpCookie.ttl.nanos può essere impostato su un valore compreso tra 0 e 999999999 (inclusi). Poiché le unità sono nanosecondi, 999999999 significa .999999999 secondi.

Se non vengono specificati sia consistentHash.httpCookie.ttl.seconds che 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 allo stesso endpoint o alla stessa istanza di backend, finché il cookie di affinità sessione rimane valido. Ciò avviene mappando il valore del cookie a un indice che fa riferimento a unistanza di backend o a un endpoint specifico e assicurandosi che i requisiti di affinità sessione dei cookie generati siano soddisfatti.

Per utilizzare l'affinità dei cookie HTTP, configura la seguente modalità di bilanciamento e le impostazioni localityLbPolicy:

• Per i gruppi di istanza di backend, utilizza la modalità di bilanciamento RATE.
• Per localityLbPolicy del servizio di backend, utilizza RING_HASH o MAGLEV. Se non imposti esplicitamente localityLbPolicy, il bilanciatore del carico utilizza MAGLEV come valore predefinito implicito.

Per saperne di più, consulta la sezione sulla perdita dell'affinità sessione.

Affinità sessione stateful basata sui cookie

Quando utilizzi l'affinità basata sui 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 sui cookie con stato:

• 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 sia secondi che frazioni di secondo (come nanosecondi). La durata rappresentata da strongSessionAffinityCookie.ttl non può essere impostata su un valore che rappresenti 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 successive richieste HTTP, il bilanciatore del carico indirizza queste richieste all'istanza o all'endpoint di backend selezionato.

A differenza di altri metodi di affinità sessione:

• L'affinità basata sui cookie con stato non ha requisiti specifici per la modalità di bilanciamento o per la policy di bilanciamento del carico per le località (localityLbPolicy).

• L'affinità stateful basata sui cookie non è interessata quando la scalabilità automatica aggiunge una nuova istanza a un gruppo di istanze gestite.

• L'affinità stateful basata sui cookie non viene interessata quando la scalabilità automatica rimuove un'istanza da un gruppo di istanze gestite a meno che l'istanza selezionata non venga rimossa.

• L'affinità stateful basata sui cookie non viene interessata quando la riparazione automatica rimuove un'istanza da un gruppo di istanze gestite a meno che l'istanza selezionata non venga rimossa.

Per saperne di più, consulta la sezione sulla perdita dell'affinità sessione.

Significato di TTL zero per le affinità basate sui 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 considera il cookie come un cookie di sessione. La definizione di 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 in più richieste fino alla chiusura dell'applicazione.

• Gli 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 o l'endpoint di backend selezionato deve rimanere configurato come backend. L'affinità di sessione può interrompersi quando si verifica uno dei seguenti eventi:
  • L'istanza selezionata viene rimossa dal gruppo di istanze.
  • La scalabilità automatica o la riparazione automatica del gruppo di istanze gestite rimuove l'istanza selezionata dal gruppo di istanze gestite.
  • Rimuovi l'endpoint selezionato dal NEG.
  • Rimuovi il gruppo di istanze o il NEG che contiene l'istanza o l'endpoint selezionato dal servizio di backend.
• 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 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. Potrebbe essere selezionato un GFE di primo livello diverso se il percorso di routing da un client su internet a Google cambia tra richieste o connessioni.

Ad eccezione dell'affinità di sessione stateful basata sui cookie, tutte le opzioni di affinità sessione hanno i seguenti requisiti aggiuntivi:

• Il gruppo di istanze o il NEG che contiene l'istanza o l'endpoint selezionato non deve essere pieno come definito dalla capacità target. Per i gruppi di istanze gestite a livello di regione, il componente 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 modo imprevedibile quando si utilizza la modalità di bilanciamento UTILIZATION, devi utilizzare la modalità di bilanciamento RATE o CONNECTION per 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 o endpoint di backend configurati cambia e l&#39affinità sessionee può interrompersi:

  • Aggiunta di nuove istanze o endpoint:

    • Aggiungi istanze a un gruppo di istanze esistente nel servizio di backend.
    • La scalabilità automatica del gruppo 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 selezionato:

    • Rimuovi qualsiasi istanza da un backend del gruppo di istanze.
    • La scalabilità automatica o la riparazione automatica del gruppo di istanze gestite rimuove qualsiasi istanza da un backend del gruppo di istanze gestite.
    • Rimuovi qualsiasi 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 o endpoint di backend integri deve rimanere costante. Quando si verifica almeno uno dei seguenti eventi, il numero di endpoint o istanze di backend integri cambia e l&#39affinità sessionee 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.