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 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 la distribuzione di applicazioni scalabili e conformi a livello mondiale o regionale.

Connessioni del bilanciatore del carico delle applicazioni esterno globale

I bilanciatori del carico delle applicazioni esterni globali sono implementati da molti proxy chiamati Google Front Ends (GFE). Non esiste un solo proxy. Nel livello Premium, lo stesso indirizzo IP esterno globale viene pubblicizzato da vari punti di presenza e le richieste dei client vengono indirizzate al GFE più vicino al client.

A seconda della posizione dei tuoi client, più GFE possono avviare connessioni HTTP(S) ai tuoi backend. I pacchetti inviati dai GFE hanno indirizzi IP di origine dello stesso intervallo utilizzato dai probe di controllo di integrità: 35.191.0.0/16 e 130.211.0.0/22.

A seconda della configurazione del servizio di backend, il protocollo utilizzato da ogni GFE per connettersi ai tuoi backend può essere HTTP, HTTPS o HTTP/2. Per le connessioni HTTP o HTTPS, la versione HTTP utilizzata è HTTP 1.1.

HTTP Keep-Alive è abilitato per impostazione predefinita, come specificato nella specifica HTTP 1.1. I keepalive HTTP tentano di utilizzare in modo efficiente la stessa sessione TCP; tuttavia, non vi è alcuna garanzia. GFE utilizza un timeout keepalive HTTP client di 610 secondi e un valore di timeout keepalive backend predefinito di 600 secondi. Puoi aggiornare il timeout keepalive HTTP del client, ma il valore del timeout keepalive del backend è fisso. Puoi configurare il timeout di richiesta e risposta impostando il timeout del servizio di backend. Sebbene strettamente correlati, un keepalive HTTP e un timeout di inattività TCP non sono la stessa cosa. Per saperne di più, consulta timeout e tentativi.

Per garantire che il traffico sia bilanciato in modo uniforme, il bilanciatore del carico potrebbe chiudere correttamente una connessione TCP inviando un pacchetto FIN ACK dopo aver completato una risposta che includeva un'intestazione Connection: close oppure potrebbe emettere un frame GOAWAY HTTP/2 dopo aver completato una risposta. Questo comportamento non interferisce con richieste o risposte attive.

Il numero di connessioni HTTP e sessioni TCP varia a seconda del numero di GFE che si connettono, del numero di client che si connettono ai GFE, del protocollo per i backend e della posizione in cui vengono implementati i backend.

Per ulteriori informazioni, consulta la sezione Come funzionano i bilanciatori del carico delle applicazioni esterni nella guida alle soluzioni: Ottimizzazioni della capacità delle applicazioni con il bilanciamento del carico globale.

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.Google Cloud In altre parole, esistono due connessioni TCP.

Per i bilanciatori del carico delle applicazioni esterni globali:

• Connessione 1, dal client originale al bilanciatore del carico (GFE):

  • 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 (GFE) alla VM o all'endpoint di backend:

  • Indirizzo IP di origine: un indirizzo IP in uno degli intervalli specificati in Regole firewall.

  • Indirizzo IP di destinazione: l'indirizzo IP interno della VM di backend o del container nella rete VPC.

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

Google 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à.

• Tra i GFE e i backend dei bilanciatori del carico delle applicazioni esterni globali e dei bilanciatori del carico delle applicazioni classici. Per ulteriori informazioni, consulta Percorsi tra i frontend e i backend di Google.

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

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 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.

Porte aperte

I GFE hanno diverse porte aperte per supportare altri servizi Google che vengono eseguiti sulla stessa architettura. Quando esegui una scansione delle porte, potresti visualizzare altre porte aperte per altri servizi Google in esecuzione su GFE.

Entrambi i bilanciatori del carico basati su GFE, ovvero i bilanciatori del carico delle applicazioni esterni globali e classici, mostrano sempre le porte 80 e 443 come aperte (insieme a qualsiasi altra porta configurata nelle regole di forwarding del bilanciatore del carico). Tuttavia, se non hai configurato una regola di forwarding per la porta 80 o per la porta 443, tutte le connessioni inviate a queste porte vengono rifiutate. Al contrario, i bilanciatori del carico delle applicazioni esterni regionali vengono implementati utilizzando i proxy Envoy e non mostrano porte aperte aggiuntive durante una scansione.

L'esecuzione di una scansione delle porte sull'indirizzo IP di un bilanciatore del carico basato su GFE non è utile dal punto di vista dell'audit per i seguenti motivi:

• Una scansione delle porte (ad esempio con nmap) in genere non prevede pacchetti di risposta o un pacchetto TCP RST durante l'esecuzione del probing TCP SYN. I GFE inviano pacchetti SYN-ACK in risposta ai probe SYN solo per le porte su cui hai configurato una regola di forwarding. I GFE inviano pacchetti ai backend solo in risposta ai pacchetti inviati all'indirizzo IP del bilanciatore del carico e alla porta di destinazione configurata nella regola di forwarding. I pacchetti inviati a un indirizzo IP o a una porta diversi non vengono inviati ai tuoi backend.

  I GFE implementano funzionalità di sicurezza come Google Cloud Armor. Con Cloud Armor Standard, i GFE forniscono protezione sempre attiva da attacchi DDoS volumetrici e basati su protocollo e da SYN flood. Questa protezione è disponibile anche se non hai configurato esplicitamente Cloud Armor. Ti vengono addebitati costi solo se configuri policy di sicurezza o se ti registri a Managed Protection Plus.

• I pacchetti inviati all'indirizzo IP del bilanciatore del carico possono ricevere risposta da qualsiasi GFE nella flotta di Google. Tuttavia, la scansione di una combinazione di indirizzo IP del bilanciatore del carico e porta di destinazione interroga una sola GFE per connessione TCP. L'indirizzo IP del bilanciatore del carico non è assegnato a un singolo dispositivo o sistema. Pertanto, la scansione dell'indirizzo IP di un bilanciatore del carico basato su GFE non esegue la scansione di tutti i GFE nel parco risorse di Google.

Tenendo presente questo, di seguito sono riportati alcuni modi più efficaci per controllare la sicurezza delle istanze di backend:

• Un revisore della sicurezza deve ispezionare la configurazione delle regole di forwarding per la configurazione del bilanciatore del carico. Le regole di forwarding definiscono la porta di destinazione per cui il bilanciatore del carico accetta i pacchetti e li inoltra ai backend. Per i bilanciatori del carico basati su GFE, ogni regola di forwarding esterno può fare riferimento a una sola porta TCP di destinazione. Per un bilanciatore del carico che utilizza la porta TCP 443, la porta UDP 443 viene utilizzata quando la connessione viene aggiornata a QUIC (HTTP/3).

• Un revisore della sicurezza deve ispezionare la configurazione delle regole firewall applicabili alle VM di backend. Le regole firewall che imposti bloccano il traffico dai GFE alle VM di backend, ma non bloccano il traffico in entrata verso i GFE. Per le best practice, consulta la sezione sulle regole firewall.

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 globale	TLS viene terminato su un GFE, che può trovarsi in qualsiasi parte del mondo.
Bilanciatore del carico delle applicazioni classico	TLS viene terminato su un GFE, che potrebbe trovarsi in qualsiasi parte del mondo.
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
		Globale	Classico	Regionale
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 i NEG serverless su un servizio di backend: 60 minuti Per tutti gli altri tipi di backend su un servizio di backend: 30 secondi Per i bucket di backend: 24 ore (86.400 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 globali e i bilanciatori del carico delle applicazioni classici, il proxy del bilanciatore del carico è un GFE di primo livello. 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 globali e i bilanciatori del carico delle applicazioni classici, il proxy del bilanciatore del carico è un GFE di secondo livello. 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) Per i bucket di backend: 6 minuti (360 secondi)
Timeout di inattività della sessione QUIC Il periodo di tempo massimo durante il quale una sessione QUIC può rimanere inattiva tra il client (downstream) e il GFE di un bilanciatore del carico delle applicazioni esterno globale o di un bilanciatore del carico delle applicazioni classico.	Per i bilanciatori del carico delle applicazioni esterni globali e classici: Il timeout di inattività della sessione QUIC è il valore minimo tra il timeout di inattività del client e il timeout di inattività di GFE (300 secondi). Il timeout di inattività di GFE è impostato su 300 secondi. È possibile configurare il timeout per inattività del client.

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. Google Cloud inoltre non garantisce che una connessione TCP sottostante possa rimanere aperta per l'intera durata del timeout del servizio di backend. Nel caso dei bilanciatori del carico delle applicazioni globali e classici, i GFE impongono un timeout effettivo massimo del servizio di backend di 86,400 secondi (1 giorno). 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 globale	servizio di backend timeout: 30 secondi	Le connessioni WebSocket attive non utilizzano il timeout del servizio di backend configurato del bilanciatore del carico. Le connessioni vengono chiuse automaticamente dopo 24 ore (86.400 secondi). Questo limite di 24 ore è fisso e sostituisce il timeout del servizio di backend se è superiore a 24 ore. Le connessioni WebSocket inattive vengono chiuse dopo il timeout del servizio di backend. Non consigliamo valori di timeout del servizio di backend superiori a 24 ore (86.400 secondi) perché Google Cloud riavvia periodicamente i GFE per aggiornamenti software e altre operazioni di manutenzione di routine. Il valore di timeout del servizio di backend non ritarda le attività di manutenzione. Più lungo è il valore di timeout del servizio di backend, maggiore è la probabilità che Google Cloudtermini le connessioni TCP per la manutenzione.
Bilanciatore del carico delle applicazioni classico	servizio di backend timeout: 30 secondi	Le connessioni WebSocket, inattive o attive, si chiudono automaticamente dopo il timeout del servizio di backend. Non consigliamo valori di timeout del servizio di backend superiori a 24 ore (86.400 secondi) perché Google Cloud riavvia periodicamente i GFE per aggiornamenti software e altre operazioni di manutenzione di routine. Il valore di timeout del servizio di backend non ritarda le attività di manutenzione. Più lungo è il valore di timeout del servizio di backend, più è probabile che Google Cloudtermini le connessioni TCP per la manutenzione.
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. Google 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 globale o un bilanciatore del carico delle applicazioni classico: un Google Front End (GFE) di primo livello

• 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 globale o un bilanciatore del carico delle applicazioni classico, esiste una prima connessione TCP tra il client (downstream) e un GFE di primo livello. I GFE del primo livello si connettono ai GFE del secondo livello, che a loro volta aprono una seconda connessione TCP ai tuoi backend.

• 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;

Timeout per sessione inattiva QUIC

Il timeout di inattività della sessione QUIC rappresenta il periodo di tempo massimo in cui una sessione QUIC può rimanere inattiva tra il client e il GFE di un bilanciatore del carico delle applicazioni esterno globale o di un bilanciatore del carico delle applicazioni classico.

Il valore di timeout di inattività della sessione QUIC è definito come il minimo tra il timeout di inattività del client e il timeout di inattività di GFE (300 secondi). Il timeout di inattività di GFE è impostato su 300 secondi. Il timeout per inattività del client può essere configurato.

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 globale	Configurabile utilizzando un criterio di ripetizione nella mappa URL. Il numero massimo di tentativi (numRetries) che possono essere configurati utilizzando i criteri per i tentativi ripetuti è 25. Il valore massimo configurabile di perTryTimeout è 24 ore. Se vuoi disattivare i tentativi, devi impostare numRetries in modo esplicito su 1. Senza un criterio di ripetizione, le richieste non riuscite che non hanno un corpo HTTP (ad esempio, le richieste GET) che generano risposte HTTP 502, 503 o 504 (retryConditions=["gateway-error"]) 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.
Bilanciatore del carico delle applicazioni classico	Il criterio di ripetizione non può essere modificato per i tentativi di connessione. I tentativi di richiesta HTTP POST non vengono ripetuti. I tentativi di richiesta HTTP GET vengono sempre ripetuti una volta, a condizione che l'80% o più dei backend sia integro. Se in un gruppo è presente una sola istanza di backend e la connessione a questa istanza di backend non va a buon fine, la percentuale di istanze di backend non integre è del 100%, quindi GFE non riprova a inviare la richiesta. Il bilanciatore del carico riprova una richiesta GET non riuscita se la prima richiesta non è riuscita prima di ricevere le intestazioni di risposta dall'istanza di backend. Le richieste riprovare generano una sola voce di log per la risposta finale. Per saperne di più, consulta Logging e monitoraggio del bilanciatore del carico delle applicazioni esterno. Le richieste non riuscite comportano la sintesi da parte del bilanciatore del carico di una risposta HTTP 502.
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 globale

Prima che un Google Front End (GFE) invii richieste alle istanze di backend, il GFE stima quali istanze di backend hanno la capacità di ricevere richieste. Questa stima della capacità viene effettuata in modo proattivo, non contemporaneamente all'arrivo delle richieste. I GFE ricevono periodicamente informazioni sulla capacità disponibile e distribuiscono le richieste in entrata di conseguenza.

Il significato di capacità dipende in parte dalla modalità di bilanciamento. Per la modalità RATE, è relativamente semplice: un GFE determina esattamente quante richieste può assegnare al secondo. Il bilanciamento del carico basato su UTILIZATION è più complesso: il bilanciatore del carico controlla l'utilizzo corrente delle istanze e poi stima un carico di query che ogni istanza può gestire. Questa stima cambia nel tempo man mano che cambiano l'utilizzo delle istanze e i modelli di traffico.

Entrambi i fattori, la stima della capacità e l'assegnazione proattiva, influiscono sulla distribuzione tra le istanze. Pertanto, Cloud Load Balancing si comporta in modo diverso da un semplice bilanciatore del carico round robin che distribuisce le richieste esattamente al 50% tra due istanze. Il Google Cloud bilanciamento del carico tenta invece di ottimizzare la selezioneistanza di backendd per ogni richiesta.

Per il bilanciatore del carico delle applicazioni esterno globale, il bilanciamento del carico è a due livelli. La modalità di bilanciamento determina la ponderazione o la frazione di traffico da inviare a ogni backend (gruppo di istanze o NEG). Quindi, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo. Per ulteriori informazioni, consulta la policy di località del bilanciamento del carico (documentazione dell'API del servizio di backend).

Per il bilanciatore del carico delle applicazioni classico, la modalità di bilanciamento viene utilizzata per selezionare il backend (gruppo di istanze o NEG) più favorevole. Il traffico viene quindi distribuito in modo round robin tra le istanze o gli endpoint all'interno del backend.

Come vengono distribuite le richieste

I bilanciatori del carico delle applicazioni esterni basati su GFE utilizzano il seguente processo per distribuire le richieste in entrata:

1. Dal client al GFE di primo livello. I router di frontiera annunciano l'indirizzo IP esterno della regola di forwarding ai confini della rete di Google. Ogni annuncio elenca un hop successivo a un sistema di bilanciamento del carico di livello 3 e livello 4 (Maglev). I sistemi Maglev indirizzano il traffico a un Google Front End (GFE) di primo livello.
   • Quando utilizzi il livello Premium, Google pubblicizza l'indirizzo IP del bilanciatore del carico da tutti i punti di presenza in tutto il mondo. Ogni indirizzo IP del bilanciatore del carico è anycast globale.
   • Quando utilizzi il livello Standard, Google pubblicizza l'indirizzo IP del bilanciatore del carico dai punti di presenza associati alla regione della regola di forwarding. Il bilanciatore del carico utilizza un indirizzo IP esterno regionale. L'utilizzo di una regola di forwarding di livello Standard ti limita ai backend di gruppi di istanze e NEG zonali nella stessa regione della regola di forwarding del bilanciatore del carico.
2. Dal GFE di primo livello al GFE di secondo livello. Il GFE del primo livello termina TLS, se necessario, e poi instrada il traffico ai GFE del secondo livello in base alla seguente procedura:
   • I GFE del primo livello analizzano la mappa URL e selezionano un servizio di backend o un bucket di backend.
   • Per i servizi di backend con NEG di internet, i GFE del primo livello selezionano un gateway di inoltro esterno di secondo livello collocato insieme al GFE del primo livello. Il gateway di inoltro invia le richieste all'endpoint NEG internet. Con questo si conclude la procedura di distribuzione delle richieste per i NEG internet.
   • Per i servizi di backend con NEG serverless e NEG Private Service Connect (PSC) e bucket di backend a una sola regione, i GFE di primo livello selezionano un GFE di secondo livello nella regione corrispondente a quella del NEG o del bucket. Per i bucket Cloud Storage multiregionali, i GFE del primo livello selezionano i GFE del secondo livello nella regione del bucket o in una regione il più vicino possibile al bucket multiregionale (definito dal tempo di andata e ritorno della rete).
   • Per i servizi di backend con gruppi di istanze, NEG zonali con endpoint GCE_VM_IP_PORT e NEG ibridi, il sistema di gestione della capacità di Google comunica ai GFE di primo livello la capacità utilizzata e configurata per ogni backend. La capacità configurata per un backend è definita dalla modalità di bilanciamento, dalla capacità target della modalità di bilanciamento e dal gestore della scalabilità della capacità.
     • Livello Standard:i GFE del primo livello selezionano un GFE del secondo livello nella regione contenente i backend.
     • Livello Premium:i GFE di primo livello selezionano i GFE di secondo livello da un insieme di regioni applicabili. Le regioni applicabili sono tutte le regioni in cui sono stati configurati i backend, escluse quelle con backend configurati con capacità pari a zero. Le GFE di primo livello selezionano la GFE di secondo livello più vicina in una regione applicabile (definita dal tempo di round trip della rete). Se i backend sono configurati in due o più regioni, i GFE di primo livello possono trasferire le richieste ad altre regioni applicabili se una regione di prima scelta è piena. Il trasferimento ad altre regioni è possibile quando tutti i backend nella regione di prima scelta sono al completo.
3. I GFE del secondo livello selezionano i backend. I GFE di secondo livello si trovano nelle zone di una regione. Utilizzano la seguente procedura per selezionare un backend:
   • Per i servizi di backend con NEG serverless, NEG Private Service Connect e bucket di backend, i GFE di secondo livello inoltrano le richieste ai sistemi di produzione di Google. Si conclude così la procedura di distribuzione delle richieste per questi backend.

   • Per i servizi di backend con gruppi di istanze, i NEG di zona con endpoint GCE_VM_IP_PORT e i NEG ibridi, i sistemi di probe di controllo di integrità di Google comunicano alle GFE di secondo livello lo stato del controllo di integrità delle istanze o degli endpoint di backend.

     Solo livello Premium:se il GFE di secondo livello non ha backend integri o endpoint nella sua regione, potrebbe inviare richieste a un altro GFE di secondo livello in una regione applicabile diversa con backend configurati. Il trasferimento tra GFE di secondo livello in regioni diverse non esaurisce tutte le possibili combinazioni regione-regione. Se devi indirizzare il traffico lontano dai backend in una determinata regione, anziché configurare i backend in modo che non superino i controlli di integrità, imposta lo scaler di capacità del backend su zero in modo che il GFE di primo livello escluda la regione durante il passaggio precedente.

   Il GFE di secondo livello indirizza quindi le richieste alle istanze di backend o agli endpoint nelle zone all'interno della sua regione, come descritto nel passaggio successivo.

4. Il secondo livello GFE seleziona una zona. Per impostazione predefinita, i GFE di secondo livello utilizzano l'algoritmo WATERFALL_BY_REGION, in cui ogni GFE di secondo livello preferisce selezionare istanze o endpoint di backend nella stessa zona della zona che contiene il GFE di secondo livello. Poiché WATERFALL_BY_REGION riduce al minimo il traffico tra le zone, a basse frequenze di richiesta, ogni GFE di secondo livello potrebbe inviare richieste esclusivamente ai backend nella stessa zona del GFE di secondo livello.

   Solo per i bilanciatori del carico delle applicazioni esterni globali, i GFE di secondo livello possono essere configurati per utilizzare uno dei seguenti algoritmi alternativi utilizzando un serviceLbPolicy:

   • SPRAY_TO_REGION: i GFE di secondo livello non preferiscono selezionare istanze o endpoint di backend nella stessa zona del GFE di secondo livello. I GFE di secondo livello tentano di distribuire il traffico a tutte le istanze o gli endpoint di backend in tutte le zone della regione. Ciò può portare a una distribuzione più uniforme del carico a scapito di un aumento del traffico tra le zone.
   • WATERFALL_BY_ZONE: i GFE di secondo livello preferiscono vivamente selezionare istanze o endpoint di backend nella stessa zona del GFE di secondo livello. I GFE di secondo livello indirizzano le richieste ai backend in zone diverse solo dopo che tutti i backend nella zona attuale hanno raggiunto le capacità configurate.
5. Il secondo livello GFE seleziona istanze o endpoint all'interno della zona. Per impostazione predefinita, un GFE di secondo livello distribuisce le richieste tra i backend in modo round robin. Solo per i bilanciatori del carico delle applicazioni esterni globali, puoi modificare questa impostazione utilizzando un criterio di località di bilanciamento del carico (localityLbPolicy). Il criterio di località di bilanciamento del carico si applica solo ai backend all'interno della zona selezionata descritta nel passaggio precedente.

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 globale 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. Per il bilanciatore del carico delle applicazioni esterno globale, non configurare la affinità sessione se utilizzi la suddivisione del traffico ponderata. In questo caso, ha la precedenza la configurazione di suddivisione del traffico ponderata.
Bilanciatore del carico delle applicazioni classico	Nessuna (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE)

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. 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 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.

Tutti i bilanciatori del carico delle applicazioni, ad eccezione di quelli classici, supportano l'affinità basata sui cookie con stato.

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.