Panoramica dei servizi di backend

Un servizio di backend definisce la modalità di distribuzione del traffico da parte di Cloud Load Balancing. La configurazione del servizio di backend contiene un insieme di valori, ad esempio il protocollo utilizzato per connettersi ai backend, varie impostazioni di distribuzione e sessione, controlli di integrità e timeout. Queste impostazioni forniscono un controllo granulare sul comportamento del bilanciatore del carico. Per iniziare, la maggior parte delle impostazioni ha valori predefiniti che consentono una configurazione rapida. L'ambito di un servizio di backend è globale o regionale.

I bilanciatori del carico, i proxy Envoy e i client gRPC senza proxy utilizzano le informazioni di configurazione nella risorsa del servizio di backend per:

• Indirizza il traffico ai backends corretti, ovvero gruppi di istanze o gruppi di endpoint di rete (NEG).
• Distribuisci il traffico in base a una modalità di bilanciamento, che è un'impostazione per ogni backend.
• Determina quale controllo di integrità monitora la salute dei backend.
• Specifica l'affinità sessione.
• Determina se sono attivati altri servizi, tra cui i seguenti, disponibili solo per determinati bilanciatori del carico:
  • Cloud CDN
  • Criteri di sicurezza di Google Cloud Armor
  • Identity-Aware Proxy
• Designa i servizi di backend regionali come servizio in App Hub, che è in anteprima.

Imposti questi valori quando crei un servizio di backend o ne aggiungi uno al servizio di backend.

Nota: se utilizzi il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni classico e i tuoi backend pubblicano contenuti statici, ti consigliamo di utilizzare i bucket di backend anziché i servizi di backend. Consulta bucket di backend per il bilanciatore del carico delle applicazioni esterno globale o bucket di backend per il bilanciatore del carico delle applicazioni classico.

La seguente tabella riassume i bilanciatori del carico che utilizzano i servizi di backend. Il prodotto che utilizzi determina anche il numero massimo di servizi di backend, l'ambito di un servizio di backend, il tipo di backend supportati e lo schema di bilanciamento del carico del servizio di backend. Lo schema di bilanciamento del carico è un identificativo utilizzato da Google per classificare le regole di inoltro e i servizi di backend. Ogni prodotto di bilanciamento del carico utilizza uno schema di bilanciamento del carico per le regole di inoltro e i servizi di backend. Alcuni schemi sono condivisi tra i prodotti.

Tabella: servizi di backend e tipi di backend supportati

Prodotto	Numero massimo di servizi di backend	Ambito del servizio di backend	Tipi di backend supportati	Schema di bilanciamento del carico
Bilanciatore del carico delle applicazioni esterno globale	Multiplo	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestiti, non gestiti o una combinazione di backend del gruppo di istanze gestiti e non gestiti ^* Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT^* Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT ^† Tutti i NEG serverless: uno o più servizi App Engine, Cloud Run o Cloud Functions Un NEG internet globale per un backend esterno NEG Private Service Connect: API di Google: un singolo NEG Private Service Connect Servizi gestiti: uno o più NEG Private Service Connect	EXTERNAL_MANAGED
Bilanciatore del carico delle applicazioni classico	Multiplo	Globale^‡	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend di gruppi di istanze gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^† Tutti i NEG serverless: uno o più servizi App Engine, Cloud Run o Cloud Functions oppure Un NEG internet globale per un backend esterno	EXTERNAL^#
Bilanciatore del carico delle applicazioni esterno regionale	Multiplo	Regionale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestiti, non gestiti o una combinazione di backend del gruppo di istanze gestiti e non gestiti ^* Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT ^* Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^† Un singolo NEG serverless (solo Cloud Run) Un singolo NEG Private Service Connect Tutti i NEG internet regionali per un backend esterno	EXTERNAL_MANAGED
Bilanciatore del carico delle applicazioni interno tra regioni	Multiplo	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestiti, non gestiti o una combinazione di backend del gruppo di istanze gestiti e non gestiti ^* Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT ^* Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^† Un singolo NEG serverless (solo Cloud Run) NEG Private Service Connect: API di Google: un singolo NEG Private Service Connect Servizi gestiti: uno o più NEG Private Service Connect	INTERNAL_MANAGED
Bilanciatore del carico delle applicazioni interno regionale	Multiplo	Regionale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestiti, non gestiti o una combinazione di backend del gruppo di istanze gestiti e non gestiti ^* Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT ^* Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^† Un singolo NEG serverless (solo Cloud Run) Un singolo NEG Private Service Connect Tutti i NEG internet regionali per un backend esterno	INTERNAL_MANAGED
Bilanciatore del carico di rete proxy esterno globale	1	Globale^‡	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestiti, non gestiti o una combinazione di backend del gruppo di istanze gestiti e non gestiti ^* Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT^* Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^† NEG Private Service Connect: API di Google: un singolo NEG Private Service Connect Servizi gestiti: uno o più NEG Private Service Connect	EXTERNAL_MANAGED
Bilanciatore del carico di rete proxy classico	1	Globale^‡	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend di gruppi di istanze gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^†	EXTERNAL
Bilanciatore del carico di rete proxy esterno regionale	1	Regionale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestiti, non gestiti o una combinazione di backend del gruppo di istanze gestiti e non gestiti ^* Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT ^* Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibride: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT Tutti i NEG internet regionali per un backend esterno Un singolo NEG Private Service Connect	EXTERNAL_MANAGED
Bilanciatore del carico di rete proxy interno regionale	1	Regionale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestiti, non gestiti o una combinazione di backend del gruppo di istanze gestiti e non gestiti ^* Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT ^* Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibride: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT Tutti i NEG internet regionali per un backend esterno Un singolo NEG Private Service Connect	INTERNAL_MANAGED
Bilanciatore del carico di rete proxy interno tra regioni	Multiplo	Globale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestiti, non gestiti o una combinazione di backend del gruppo di istanze gestiti e non gestiti ^* Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT ^* Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibride: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT NEG Private Service Connect: API di Google: un singolo NEG Private Service Connect Servizi gestiti: uno o più NEG Private Service Connect	INTERNAL_MANAGED
Bilanciatore del carico di rete passthrough esterno	1	Regionale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend di gruppi di istanze gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP	EXTERNAL
Bilanciatore del carico di rete passthrough interno	1	A livello di regione, ma configurabile per essere accessibile a livello globale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend di gruppi di istanze gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP NEG mappatura di una porta (anteprima)	INTERNAL
Cloud Service Mesh	Multiplo	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend di gruppi di istanze gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT o NON_GCP_PRIVATE_IP_PORT Un NEG internet di tipo INTERNET_FQDN_PORT Una o più associazioni di servizi	INTERNAL_SELF_MANAGED

^* Supporta gruppi di istanze IPv4 e IPv6 (a doppio stack) e backend NEG a livello di zona. I NEG a livello di zona supportano il dual-stack solo per gli endpoint di tipo GCE_VM_IP_PORT.

^† Per i deployment GKE, i backend NEG misti sono supportati solo con NEG autonomi.

^‡ I servizi di backend utilizzati dai bilanciatori del carico delle applicazioni e dai bilanciatori del carico di rete con proxy classici hanno sempre ambito globale, sia nel livello di rete Standard che Premium. Tuttavia, nel livello Standard si applicano le seguenti limitazioni:

• La regola di inoltro e il relativo indirizzo IP esterno sono a livello di regione.
• Tutti i backend collegati al servizio di backend devono trovarsi nella stessa regione della regola di forwarding.

^# È possibile collegare servizi di backend EXTERNAL_MANAGED alle regole di forwarding EXTERNAL. Tuttavia, i servizi di backend EXTERNAL non possono essere collegati alle regole di inoltro EXTERNAL_MANAGED. Per usufruire delle nuove funzionalità disponibili solo con il bilanciatore del carico delle applicazioni esterno globale, ti consigliamo di eseguire la migrazione delle risorse EXTERNAL esistenti a EXTERNAL_MANAGED utilizzando la procedura descritta in Eseguire la migrazione delle risorse dal bilanciatore del carico delle applicazioni classico a quello esterno globale.

Backend

Un backend è costituito da uno o più endpoint che ricevono traffico da un bilanciatore del carico Google Cloud, da un proxy Envoy configurato con Cloud Service Mesh o da un client gRPC senza proxy. Esistono diversi tipi di backend:

• Gruppo di istanze contenente istanze di macchine virtuali (VM). Un gruppo di istanze può essere un gruppo di istanze gestite con o senza scalabilità automatica oppure un gruppo di istanze non gestite. Più di un servizio di backend può fare riferimento a un gruppo di istanze, ma tutti i servizi di backend che fanno riferimento al gruppo di istanze devono utilizzare la stessa modalità di bilanciamento.
• NEG a livello di zona
• NEG serverless
• NEG internet
• NEG connettività ibrida
• NEG Private Service Connect
• NEG mappatura porte (anteprima)
• Associazioni di servizi di Service Directory

Non puoi eliminare un gruppo di istanza di backend o un gruppo NEG associato a un servizio di backend. Prima di eliminare un gruppo di istanze o un gruppo di istanze elastiche, devi primarimuoverlo come backend da tutti i servizi di backend che fanno riferimento.

Gruppi di istanze

Questa sezione illustra il funzionamento dei gruppi di istanze con il servizio di backend.

VM di backend e indirizzi IP esterni

Le VM di backend nei servizi di backend non richiedono indirizzi IP esterni:

• Per i bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico di rete proxy esterni: i client comunicano con un Google Front End (GFE) (GFE) che ospita l'indirizzo IP esterno del bilanciatore del carico. I GFE comunicano con le VM o gli endpoint di backend inviando pacchetti a un indirizzo interno creato congiungendo un identificatore per la rete VPC del backend con l'indirizzo IPv4 interno del backend. La comunicazione tra GFE e VM o endpoint di backend è facilitata tramite route speciali.
  • Per i backend del gruppo di istanze, l'indirizzo IPv4 interno è sempre l'indirizzo IPv4 interno principale che corrisponde all'interfaccia nic0 della VM.
  • Per gli endpoint GCE_VM_IP_PORT in un NEG zonale, puoi specificare l'indirizzo IP dell'endpoint come indirizzo IPv4 principale associato a qualsiasi interfaccia di rete di una VM o qualsiasi indirizzo IPv4 di un intervallo di indirizzi IP alias associato a qualsiasi interfaccia di rete di una VM.

• Per i bilanciatori del carico delle applicazioni esterni regionali: i client comunicano con un proxy Envoy che ospita l'indirizzo IP esterno del bilanciatore del carico. I proxy Envoy comunicano con le VM o gli endpoint di backend inviando pacchetti a un indirizzo interno creato congiungendo un identificatore per la rete VPC del backend con l'indirizzo IPv4 interno del backend.

  • Per i backend del gruppo di istanze, l'indirizzo IPv4 interno è sempre l'indirizzo IPv4 interno principale che corrisponde all'interfaccia nic0 della VM e nic0 deve trovarsi nella stessa rete del bilanciatore del carico.
  • Per gli endpoint GCE_VM_IP_PORT in un NEG zonale, puoi specificare l'indirizzo IP dell'endpoint come indirizzo IPv4 principale associato a qualsiasi interfaccia di rete di una VM o qualsiasi indirizzo IPv4 di un intervallo di indirizzi IP alias associato a qualsiasi interfaccia di rete di una VM, purché l'interfaccia di rete si trovi nella stessa rete del bilanciatore del carico.

• Per i bilanciatori del carico di rete passthrough esterni: i client comunicano direttamente con i backend tramite l'infrastruttura di bilanciamento del carico passthrough Maglev di Google. I pacchetti vengono instradati e inviati ai backend con gli indirizzi IP di origine e di destinazione originali conservati. I backend rispondono ai client utilizzando il ritorno diretto del server. I metodi utilizzati per selezionare un backend e monitorare le connessioni sono configurabili.

  • Per i backend dei gruppi di istanze, i pacchetti vengono sempre inviati all'nic0 interfaccia della VM.
  • Per gli endpoint GCE_VM_IP in un NEG di zona, i pacchetti vengono inviati all'interfaccia di rete della VM che si trova nella sottorete associata al NEG.

Porte denominate

L'attributo porta denominata del servizio di backend è applicabile solo ai bilanciatori del carico basati su proxy (bilanciatori del carico delle applicazioni e bilanciatori del carico di rete proxy) che utilizzano i backend dei gruppi di istanze. La porta denominata definisce la porta di destinazione utilizzata per la connessione TCP tra il proxy (GFE o Envoy) e l'istanza di backend.

Le porte denominate sono configurate come segue:

• In ogni backend del gruppo di istanze, devi configurare una o più porte denominate utilizzando coppie chiave-valore. La chiave rappresenta un nome di porta significativo scelto da te e il valore rappresenta il numero di porta assegnato al nome. La mappatura dei nomi ai numeri viene eseguita singolarmente per ogni backend del gruppo di istanze.

• Nel servizio di backend, specifica una singola porta denominata utilizzando solo il nome della porta (--port-name).

Su base di backend per gruppo di istanze, il servizio di backend traduce il nome della porta in un numero di porta. Quando la porta denominata di un gruppo di istanze corrisponde a --port-name del servizio di backend, il servizio di backend utilizza questo numero di porta per la comunicazione con le VM del gruppo di istanze.

Ad esempio, puoi impostare la porta denominata su un gruppo di istanze con il nomemy-service-name e la porta 8888:

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

Poi fai riferimento alla porta denominata nella configurazione del servizio di backend con --port-name impostato su my-service-name nel servizio di backend:

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

Un servizio di backend può utilizzare un numero di porta diverso quando comunica con le VM in gruppi di istanze diversi se ogni gruppo di istanze specifica un numero di porta diverso per lo stesso nome di porta.

Il numero di porta risolto utilizzato dal servizio di backend del bilanciatore del carico proxy non deve corrispondere al numero di porta utilizzato dalle regole di inoltro del bilanciatore del carico. Un bilanciatore del carico proxy ascolta le connessioni TCP inviate all'indirizzo IP e alla porta di destinazione delle sue regole di inoltro. Poiché il proxy apre una seconda connessione TCP ai suoi backend, la porta di destinazione della seconda connessione TCP può essere diversa.

Le porte denominate sono applicabili solo ai backend del gruppo di istanze. I NEG di zona con endpointGCE_VM_IP_PORT, i NEG ibridi con endpointNON_GCP_PRIVATE_IP_PORT e i NEG internet definiscono le porte utilizzando un meccanismo diverso, ovvero sugli endpoint stessi. I NEG serverless fanno riferimento ai servizi Google e i NEG PSC fanno riferimento agli allegati dei servizi utilizzando astratti che non richiedono la specifica di una porta di destinazione.

I bilanciatori del carico di rete passthrough interni e esterni non utilizzano porte denominate. Questo perché sono bilanciatori del carico passthrough che indirizzano le connessioni direttamente ai backend anziché creare nuove connessioni. I pacchetti vengono inviati ai backend preservando l'indirizzo IP e la porta di destinazione della regola di inoltro del bilanciatore del carico.

Per scoprire come creare porte denominate, segui le istruzioni riportate di seguito:

• Gruppi di istanze non gestite: utilizzo delle porte con nome
• Gruppi di istanze gestite: assegnazione di porte denominate ai gruppi di istanze gestite

Limitazioni e indicazioni per i gruppi di istanze

Tieni presente le seguenti limitazioni e indicazioni quando crei gruppi di istanze per i bilanciatori del carico:

• Non inserire una VM in più di un gruppo di istanze con bilanciamento del carico. Se una VM è membro di due o più gruppi di istanze non gestite o di un gruppo di istanze gestite e di uno o più gruppi di istanze non gestite, Google Cloud ti limita a utilizzare un solo gruppo di istanze alla volta come backend per un determinato servizio di backend.

  Se hai bisogno che una VM partecipi a più bilanciatori del carico, devi utilizzare lo stesso gruppo di istanze come backend su ciascuno dei servizi di backend.

• Per i bilanciatori del carico proxy, quando vuoi bilanciare il traffico su diverse porte, specifica le porte denominate richieste in un gruppo di istanze e fai in modo che ogni servizio di backend si abboni a una porta denominata univoca.

• Puoi utilizzare lo stesso gruppo di istanze come backend per più di un servizio di backend. In questo caso, i backend devono utilizzare modalità di bilanciamento compatibili. Compatibile significa che le modalità di bilanciamento devono essere uguali o devono essere una combinazione di CONNECTION e RATE.

  Le combinazioni di modalità di bilanciamento non compatibili sono le seguenti:

  • CONNECTION con UTILIZATION
  • RATE con UTILIZATION

  Considera l'esempio seguente:

  • Sono presenti due servizi di backend: external-https-backend-service per un bilanciatore del carico delle applicazioni esterno e internal-tcp-backend-service per un bilanciatore del carico di rete passthrough interno.
  • Stai utilizzando un gruppo di istanze denominato instance-group-a in internal-tcp-backend-service.
  • In internal-tcp-backend-service, devi applicare la modalità di bilanciamento CONNECTION perché i bilanciatori del carico di rete passthrough interni supportano solo la modalità di bilanciamento CONNECTION.
  • Puoi anche utilizzare instance-group-a in external-https-backend-service se applichi la modalità di bilanciamento RATE in external-https-backend-service.
  • Non puoi utilizzare instance-group-a anche in external-https-backend-service con la modalità di bilanciamento UTILIZATION.

• Per modificare la modalità di bilanciamento di un gruppo di istanze che funge da backend per più servizi di backend:

  • Rimuovi il gruppo di istanze da tutti i servizi di backend tranne da uno.
  • Modifica la modalità di bilanciamento per il backend nell'unico servizio di backend rimanente.
  • Aggiungi di nuovo il gruppo di istanze come backend ai servizi di backend rimanenti, se supportano la nuova modalità di bilanciamento.

• Se il gruppo di istanze è associato a più servizi di backend, ciascun servizio di backend può fare riferimento alla stessa porta denominata o a una porta denominata diversa nel gruppo di istanze.

• Ti consigliamo di non aggiungere un gruppo di istanze gestite con scalabilità automatica a più di un servizio di backend. In questo modo potresti causare una scalabilità imprevedibile e non necessaria delle istanze nel gruppo, in particolare se utilizzi la metrica di scalabilità automatica Utilizzo bilanciamento del carico HTTP.

  • Sebbene non sia consigliato, questo scenario potrebbe funzionare se la metrica di scalabilità automatica è Utilizzo della CPU o una metrica di monitoraggio del cloud non correlata alla capacità di gestione del bilanciatore del carico. L'utilizzo di una di queste metriche di scalabilità automatica potrebbe impedire una scalabilità erratica.

Gruppi di endpoint di rete a livello di zona

Gli endpoint di rete rappresentano i servizi in base al loro indirizzo IP o a una combinazione di indirizzo IP e porta, anziché fare riferimento a una VM in un gruppo di istanze. Un gruppo di endpoint di rete (NEG) è un raggruppamento logico di endpoint di rete.

I gruppi di endpoint di rete (NEG) di zona sono risorse di zona che rappresentano raccolte di indirizzi IP o combinazioni di indirizzi IP e porte per le risorse Google Cloud all'interno di un'unica sottorete.

Un servizio di backend che utilizza NEG zonali come backend distribuisce il traffico tra applicazioni o container in esecuzione all'interno delle VM.

Per i NEG zonali sono disponibili due tipi di endpoint di rete:

• endpoint GCE_VM_IP (supportati solo con bilanciatori del carico di rete passthrough interni e bilanciatori del carico di rete passthrough esterni basati su servizi di backend).
• GCE_VM_IP_PORT endpoint.

Per sapere quali prodotti supportano i backend NEG a livello di zona, consulta la Tabella: servizi di backend e tipi di backend supportati.

Per maggiori dettagli, vedi Panoramica dei NEG zonali.

Gruppi di endpoint di rete internet

I NEG internet sono risorse che definiscono i backend esterni. Un backend esterno è un backend ospitato nell'infrastruttura on-premise o in un'infrastruttura fornita da terze parti.

Un NEG di internet è una combinazione di un nome host o un indirizzo IP, oltre a una porta facoltativa. Esistono due tipi di endpoint di rete disponibili per i NEG internet: INTERNET_FQDN_PORT e INTERNET_IP_PORT.

I NEG internet sono disponibili in due ambiti: globale e regionale. Per sapere quali prodotti supportano i backend NEG internet in ogni ambito, consulta la Tabella: servizi di backend e tipi di backend supportati.

Per maggiori dettagli, consulta la panoramica dei gruppi di endpoint di rete internet.

Gruppi di endpoint di rete serverless

Un gruppo di endpoint di rete (NEG) specifica un gruppo di endpoint di backend per un bilanciatore del carico. Un NEG serverless è un backend che punta a un servizio Cloud Run, App Engine, funzioni Cloud Run o API Gateway.

Un NEG serverless può rappresentare uno dei seguenti elementi:

• Un servizio Cloud Run o un gruppo di servizi.
• Una funzione Cloud Run o un gruppo di funzioni.
• Un'app App Engine (standard o flessibile), un servizio specifico all'interno di un'app, una versione specifica di un'app o un gruppo di servizi.
• Un API Gateway che fornisce l'accesso ai tuoi servizi tramite un'API REST coerente in tutti i servizi, indipendentemente dall'implementazione del servizio. Questa funzionalità è in anteprima.

Importante: affinché un gruppo di servizi si trovi nello stesso NEG serverless, deve avere un pattern URL comune.

Per configurare un NEG serverless per le applicazioni serverless che condividono un pattern URL, utilizza una maschera URL. Una maschera URL è un modello dello schema URL (ad esempio example.com/<service>). Il NEG serverless utilizzerà questo modello per estrarre il nome <service> dall'URL della richiesta in arrivo e inoltrarla al servizio Cloud Run, Cloud Functions o App Engine corrispondente con lo stesso nome.

Per sapere quali bilanciatori del carico supportano i backend NEG serverless, consulta la Tabella: servizi di backend e tipi di backend supportati.

Per ulteriori informazioni sui NEG serverless, consulta la panoramica dei gruppi di endpoint di rete serverless.

Associazioni dei servizi

Un collegamento di servizi è un backend che stabilisce una connessione tra un servizio di backend in Cloud Service Mesh e un servizio registrato in Service Directory. Un servizio di backend può fare riferimento a più associazioni di servizi. Un servizio di backend con un'associazione di servizi non può fare riferimento a nessun altro tipo di backend.

Backend misti

Quando aggiungi diversi tipi di backend a un singolo servizio di backend, si applicano le seguenti considerazioni sull'utilizzo:

• Un singolo servizio di backend non può utilizzare contemporaneamente gruppi di istanze e NEG a livello di zona.
• Puoi utilizzare una combinazione di diversi tipi di gruppi di istanze nello stesso servizio di backend. Ad esempio, un singolo servizio di backend può fare riferimento a una combinazione di gruppi di istanze gestite e non gestite. Per informazioni complete su quali backend sono compatibili con quali servizi di backend, consulta la tabella nella sezione precedente.
• Con alcuni bilanciatori del carico proxy, puoi utilizzare una combinazione di NEG a livello di zona (con endpoint GCE_VM_IP_PORT) e NEG connettività ibrida (con endpoint NON_GCP_PRIVATE_IP_PORT) per configurare il bilanciamento del carico ibrida. Per sapere quali bilanciatori del carico dispongono di questa funzionalità, consulta la Tabella: servizi di backend e tipi di backend supportati.

Protocollo per i backend

Quando crei un servizio di backend, devi specificare il protocollo utilizzato per comunicare con i backend. Puoi specificare un solo protocollo per servizio di backend. Non puoi specificare un protocollo secondario da utilizzare come opzione di riserva.

I protocolli validi dipendono dal tipo di bilanciatore del carico o dall'utilizzo di Cloud Service Mesh.

Tabella: protocollo per i backend

Prodotto	Opzioni del protocollo del servizio di backend
Bilanciatore del carico delle applicazioni	HTTP, HTTPS, HTTP/2
Bilanciatore del carico di rete proxy	TCP o SSL I bilanciatori del carico di rete proxy regionali supportano solo TCP.
Bilanciatore del carico di rete passthrough	TCP, UDP o UNSPECIFIED
Cloud Service Mesh	HTTP, HTTPS, HTTP/2, gRPC, TCP

La modifica del protocollo di un servizio di backend rende i backend inaccessibili tramite i bilanciatori del carico per alcuni minuti.

Criterio di selezione degli indirizzi IP

Questo campo è applicabile ai bilanciatori del carico proxy. Devi utilizzare il criterio di selezione degli indirizzi IP per specificare il tipo di traffico inviato dal servizio di backend ai tuoi backend.

Quando selezioni il criterio di selezione degli indirizzi IP, assicurati che i tuoi backend supportino il tipo di traffico selezionato. Per ulteriori informazioni, consulta la Tabella: servizi di backend e tipi di backend supportati.

Il criterio di selezione dell'indirizzo IP viene utilizzato quando vuoi convertire il servizio di backend del bilanciatore del carico in modo che supporti un tipo di traffico diverso. Per ulteriori informazioni, consulta Eseguire la conversione da single-stack a dual-stack.

Puoi specificare i seguenti valori per il criterio di selezione degli indirizzi IP:

Criterio di selezione degli indirizzi IP	Descrizione
Solo IPv4	Invia solo traffico IPv4 ai backend del servizio di backend, indipendentemente dal traffico dal client a GFE. Per controllare l'integrità dei backend vengono utilizzati solo i controlli di integrità IPv4.
Preferenza per IPv6	Assegna la priorità alla connessione IPv6 del backend rispetto alla connessione IPv4 (a condizione che sia presente un backend funzionante con indirizzi IPv6). I controlli di integrità monitorano periodicamente le connessioni IPv6 e IPv4 dei backend. La GFE tenta prima la connessione IPv6. Se la connessione IPv6 è interrotta o lenta, la GFE utilizza gli happy eyeballs per eseguire il fallback e connettersi a IPv4. Anche se una delle connessioni IPv6 o IPv4 non è attiva, il backend viene comunque trattato come attivo e GFE può provare entrambe le connessioni, con gli utenti che alla fine scelgono quale utilizzare.
Solo IPv6	Invia solo traffico IPv6 ai backend del servizio di backend, indipendentemente dal traffico dal client al proxy. Per controllare l'integrità dei backend vengono utilizzati solo i controlli di integrità IPv6. Non viene eseguita alcuna convalida per verificare se il tipo di traffico di backend corrisponde al criterio di selezione degli indirizzi IP. Ad esempio, se hai backend solo IPv4 e selezioni Only IPv6 come criterio di selezione dell'indirizzo IP, la configurazione genera backend non validi perché il traffico non riesce a raggiungerli e il codice di risposta HTTP 503 viene restituito ai client.

Crittografia tra il bilanciatore del carico e i backend

Per informazioni sulla crittografia tra il bilanciatore del carico e i backend, consulta Crittografia per i backend.

Distribuzione del traffico

I valori dei seguenti campi nella risorsa dei servizi di backend determinano alcuni aspetti del comportamento del backend:

• Una modalità di bilanciamento definisce in che modo il bilanciatore del carico misura l'idoneità del backend per nuove richieste o connessioni.
• Una capacità target definisce un numero massimo target di connessioni, una frequenza massima target o un utilizzo massimo della CPU target.
• Un gestitore della scalabilità della capacità regola la capacità complessiva disponibile senza modificare la capacità target.

Modalità di bilanciamento

La modalità di bilanciamento determina se i backend di un bilanciatore del carico o di Cloud Service Mesh possono gestire traffico aggiuntivo o sono completamente caricati.

Google Cloud ha tre modalità di bilanciamento:

• CONNECTION: determina la modalità di distribuzione del carico in base al numero totale di collegamenti che il backend può gestire.
• RATE: il numero massimo target di richieste (query) al secondo (RPS, QPS). Il valore RPS/QPS massimo target può essere superato se tutti i backend sono in uso o superano la capacità.
• UTILIZATION: determina la modalità di distribuzione del carico in base all'utilizzo delle istanze in un gruppo di istanze.

Modalità di bilanciamento disponibili per ogni bilanciatore del carico

Imposti la modalità di bilanciamento quando aggiungi un backend al servizio di backend. Le modalità di bilanciamento disponibili per un bilanciatore del carico dipendono dal tipo di bilanciatore del carico e dal tipo di backend.

I bilanciatori del carico di rete passthrough richiedono la modalità di bilanciamento CONNECTION, ma non supportano l'impostazione di alcuna capacità target.

I bilanciatori del carico delle applicazioni supportano le modalità di bilanciamento RATE o UTILIZATION per i backend dei gruppi di istanze, la modalità di bilanciamento RATE per i NEG zonali con endpoint GCE_VM_IP_PORT e la modalità di bilanciamento RATE per i NEG ibridi (endpoint NON_GCP_PRIVATE_IP_PORT). Per qualsiasi altro tipo di backend supportato, la modalità di bilanciamento deve essere omessa.

• Per i bilanciatori del carico delle applicazioni classici, una regione viene selezionata in base alla posizione del cliente e alla disponibilità di capacità nella regione, in base alla capacità target della modalità di bilanciamento del carico. Poi, all'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste da indirizzare a ciascun backend della regione. Le richieste o le connessioni vengono poi distribuite in un round robin tra le istanze o gli endpoint all'interno del backend.

• Per gli Application Load Balancer esterni globali, viene selezionata una regione in base alla posizione del cliente e alla disponibilità di capacità nella regione, in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste da indirizzare a ciascun backend (gruppo di istanze o NEG) nella regione. Puoi utilizzare il criterio di bilanciamento del carico del servizio (serviceLbPolicy) e l'impostazione backend preferito per influenzare la selezione di eventuali backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo.

• Per i bilanciatori del carico delle applicazioni interni tra regioni, i bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico delle applicazioni interni regionali, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste da indirizzare a ciascun backend (gruppo di istanze o NEG) nella regione. All'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo. Solo il bilanciatore del carico delle applicazioni interno tra regioni supporta l'utilizzo del criterio di bilanciamento del carico del servizio (serviceLbPolicy) e delle impostazioni del backend preferito per influenzare la selezione di eventuali backend specifici all'interno di una regione.

I bilanciatori del carico di rete proxy supportano le modalità di bilanciamento CONNECTION o UTILIZATION per i backend dei gruppi di istanze VM, la modalità di bilanciamento CONNECTION per i NEG a livello di zona con endpoint GCE_VM_IP_PORT e la modalità di bilanciamento CONNECTION per i NEG ibride (endpoint NON_GCP_PRIVATE_IP_PORT). Per qualsiasi altro tipo di backend supportato, la modalità di bilanciamento deve essere omessa.

• Per i bilanciatori del carico di rete proxy esterni globali, viene selezionata una regione in base alla posizione del client e alla disponibilità di capacità nella regione, in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste da indirizzare a ciascun backend (gruppo di istanze o NEG) nella regione. Puoi utilizzare il criterio di bilanciamento del carico del servizio (serviceLbPolicy) e l'impostazione backend preferito per influenzare la selezione di eventuali backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo.

• Per i bilanciatori del carico di rete proxy interno tra regioni, viene selezionata prima la regione configurata. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste da indirizzare a ciascun backend (gruppo di istanze o NEG) nella regione. Puoi utilizzare il criterio di bilanciamento del carico del servizio (serviceLbPolicy) e l'impostazione backend preferito per influenzare la selezione di eventuali backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo.

• Per i bilanciatori del carico di rete proxy classici, una regione viene selezionata in base alla posizione del client e alla disponibilità di capacità in base alla capacità target della modalità di bilanciamento del carico. Poi, all'interno di una regione, la capacità target della modalità di bilanciamento del carico viene utilizzata per calcolare le proporzioni relative al numero di richieste o connessioni da indirizzare a ciascun backend (gruppo di istanze o NEG) nella regione. Dopo che il bilanciatore del carico ha selezionato un backend, le richieste o le connessioni vengono distribuite in modo round robin tra le istanze VM o gli endpoint di rete all'interno di ogni singolo backend.

• Per i bilanciatori del carico di rete proxy esterni regionali e i bilanciatori del carico di rete proxy interni regionali, la capacità target della modalità di bilanciamento del carico viene utilizzata per calcolare le proporzioni relative al numero di richieste da inviare a ciascun backend (gruppo di istanze o NEG). All'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (localityLbPolicy) determina la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo.

La tabella riportata di seguito riassume le modalità di bilanciamento del carico disponibili per ogni combinazione di bilanciatore del carico e backend.

Tabella: modalità di bilanciamento disponibili per ogni bilanciatore del carico

Bilanciatore del carico	Backend	Modalità di bilanciamento disponibili
Bilanciatore del carico delle applicazioni	Gruppi di istanze	RATE o UTILIZATION
	NEG a livello di zona (endpoint GCE_VM_IP_PORT)	RATE
	NEG ibride (endpoint NON_GCP_PRIVATE_IP_PORT)	RATE
Bilanciatore del carico di rete proxy Bilanciatore del carico di rete proxy esterno globale Bilanciatore del carico di rete proxy classico Bilanciatore del carico di rete proxy esterno regionale Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy interno tra regioni	Gruppi di istanze	CONNECTION o UTILIZATION
	NEG a livello di zona (endpoint GCE_VM_IP_PORT)	CONNECTION
	NEG ibride (endpoint NON_GCP_PRIVATE_IP_PORT)	CONNECTION
Bilanciatore del carico di rete passthrough	Gruppi di istanze	CONNECTION
	NEG a livello di zona (endpoint GCE_VM_IP)	CONNECTION

Nota:

Se noti una scarsa distribuzione del traffico durante l'utilizzo della modalità di bilanciamento UTILIZATION, ti consigliamo di utilizzare RATE.

La modalità di bilanciamento UTILIZATION dipende dall'utilizzo della CPU o dell'istanza VM, nonché da altri fattori. Quando questi fattori variano, il bilanciatore del carico calcola le capacità in modo inefficace, il che spesso porta a una scarsa distribuzione del traffico tra i gruppi di backend. Al contrario, per la modalità di bilanciamento RATE, il bilanciatore del carico invia le richieste al gruppo di backend con la latenza media più bassa rispetto alle richieste recenti oppure, per HTTP/2 e HTTP/3, le richieste vengono inviate al gruppo di backend con il minor numero di richieste in attesa.

Se l'utilizzo medio di tutte le VM associate a un servizio di backend è inferiore al 10%, Google Cloud potrebbe preferire zone specifiche. Questo può accadere quando utilizzi gruppi di istanze gestite a livello di regione, gruppi di istanze gestite a livello di zona in zone diverse e gruppi di istanze non gestite a livello di zona. Questo squilibrio in base alla zona si risolve automaticamente man mano che viene inviato più traffico al bilanciatore del carico.

Per ulteriori informazioni, consulta gcloud compute backend-services add-backend.

Capacità target

Ogni modalità di bilanciamento ha una capacità target corrispondente, che definisce uno dei seguenti valori massimi target:

• Numero di connessioni
• Frequenza
• Utilizzo CPU

Per ogni modalità di bilanciamento, la capacità target non è un interruttore di sicurezza. Un bilanciatore del carico può superare il valore massimo in determinate condizioni, ad esempio se tutti gli endpoint o le VM di backend hanno raggiunto il valore massimo.

Modalità di bilanciamento della connessione

Per la modalità di bilanciamento CONNECTION, la capacità target definisce un numero massimo di connessioni aperte target. Ad eccezione dei bilanciatori del carico di rete passthrough interni e dei bilanciatori del carico di rete passthrough esterni, devi utilizzare una delle seguenti impostazioni per specificare un numero massimo di connessioni target:

• max-connections-per-instance (per VM): numero medio di connessioni target per una singola VM.
• max-connections-per-endpoint (per endpoint in un NEG zonale): numero medio di connessioni di destinazione per un singolo endpoint.
• max-connections (per NEG a livello di zona e per gruppi di istanze a livello di zona): numero medio di connessioni target per l'intero NEG o per il gruppo di istanze. Per i gruppi di istanze gestite a livello di regione, utilizza max-connections-per-instance.

La tabella seguente mostra come il parametro della capacità target definisce quanto segue:

• La capacità target per l'intero backend
• La capacità target prevista per ogni istanza o endpoint

Tabella: capacità target per i backend che utilizzano la modalità di bilanciamento CONNESSIONE

Tipo di backend	Capacità target
	Se specifichi	Capacità dell'intero backend	Capacità prevista per istanza o per endpoint
Gruppo di istanze N istanze, H in stato integro	max-connections-per-instance=X	X × N	(X × N)/H
Endpoint NNEG H a livello di zona in stato integro	max-connections-per-endpoint=X	X × N	(X × N)/H
Gruppi di istanze (tranne i gruppi di istanze gestite a livello di regione) H istanze sane	max-connections=Y	Y	Y/H

Come illustrato, le impostazioni max-connections-per-instance e max-connections-per-endpoint sono proxy per il calcolo di un numero massimo di connessioni target per l'intero gruppo di istanze VM o per l'intero NEG zonale:

• In un gruppo di istanze VM con N istanze, l'impostazione max-connections-per-instance=X ha lo stesso significato dell'impostazione max-connections=X × N.
• In un NEG di zona con endpoint N, l'impostazionemax-connections-per-endpoint=X ha lo stesso significato dell'impostazionemax-connections=X × N.

Modalità di bilanciamento delle tariffe

Per la modalità di bilanciamento RATE, devi definire la capacità target utilizzando uno dei seguenti parametri:

• max-rate-per-instance (per VM): specifica una frequenza media di richieste HTTP target per una singola VM.
• max-rate-per-endpoint (per endpoint in un NEG zonale): fornisci una frequenza media di richieste HTTP target per un singolo endpoint.
• max-rate (per NEG e gruppi di istanze a livello di zona): fornisci una frequenza media delle richieste HTTP target per l'intero NEG o gruppo di istanze. Per i gruppi di istanze gestite regionali, utilizza max-rate-per-instance.

La tabella seguente mostra come il parametro della capacità target definisce quanto segue:

• La capacità target per l'intero backend
• La capacità target prevista per ogni istanza o endpoint

Tabella: capacità target per i backend che utilizzano la modalità di bilanciamento RATE

Tipo di backend	Capacità target
	Se specifichi	Capacità dell'intero backend	Capacità prevista per istanza o per endpoint
Gruppo di istanze N istanze, H in stato integro	max-rate-per-instance=X	X × N	(X × N)/H
Nendpoint H NEG a livello di zona in stato integro	max-rate-per-endpoint=X	X × N	(X × N)/H
Gruppi di istanze (tranne i gruppi di istanze gestite a livello di regione) H istanze sane	max-rate=Y	Y	Y/H

Come illustrato, le impostazioni max-rate-per-instance e max-rate-per-endpoint sono proxy per il calcolo di una frequenza massima target delle richieste HTTP per l'intero gruppo di istanze o per l'intero NEG zonale:

• In un gruppo di istanze con N istanze, l'impostazione max-rate-per-instance=X ha lo stesso significato dell'impostazione max-rate=X × N.
• In un NEG a livello di zona con endpoint N, l'impostazione max-rate-per-endpoint=X ha lo stesso significato dell'impostazione max-rate=X × N.

Modalità di bilanciamento dell'utilizzo

La modalità di bilanciamento UTILIZATION non ha una capacità target obbligatoria. Hai a disposizione una serie di opzioni che dipendono dal tipo di backend, come descritto nella tabella della sezione seguente.

La capacità target max-utilization può essere specificata solo per gruppo di istanze e non può essere applicata a una determinata VM del gruppo.

La modalità di bilanciamento UTILIZATION non ha una capacità target obbligatoria. Quando utilizzi la console Google Cloud per aggiungere un gruppo di istanza di backend a un servizio di backend, la console imposta il valore di max-utilization su 0,8 (80%) se è selezionata la modalità di bilanciamento UTILIZATION. Oltre a max-utilization, la modalità di bilanciamento UTILIZATION supporta capacità target più complesse, come riepilogato nella tabella della sezione seguente.

Modificare la modalità di bilanciamento di un bilanciatore del carico

Per alcuni bilanciatori del carico o configurazioni di bilanciatori del carico, non puoi modificare la modalità di bilanciamento perché il servizio di backend ha una sola modalità di bilanciamento possibile. Per altri, a seconda del backend utilizzato, puoi modificare la modalità di bilanciamento perché per questi servizi di backend è disponibile più di una modalità.

Per scoprire quali modalità di bilanciamento sono supportate per ogni bilanciatore del carico, consulta la tabella: Modalità di bilanciamento disponibili per ogni bilanciatore del carico

Modalità di bilanciamento e impostazioni della capacità target

Per i prodotti che supportano una specifica della capacità target, la capacità target non è un interruttore di sicurezza. Quando la capacità target massima configurata viene raggiunta in una determinata zona, le nuove richieste o connessioni vengono distribuite ad altre zone che non stanno elaborando richieste o connessioni alla capacità target. Se tutte le zone hanno raggiunto la capacità target, le nuove richieste o connessioni vengono distribuite in base al sovraccarico.

Bilanciatori del carico delle applicazioni e Cloud Service Mesh

Questa tabella elenca le combinazioni di modalità di bilanciamento e capacità target disponibili per i bilanciatori del carico delle applicazioni e Cloud Service Mesh.

Tabella: combinazioni di modalità di bilanciamento e capacità target per i bilanciatori del carico delle applicazioni e Cloud Service Mesh

Tipo di backend	Modalità di bilanciamento	Specifiche della capacità target
Gruppi di istanze non gestita a livello di zona gestita a livello di zona gestito a livello di regione	RATE	Devi specificare una delle seguenti opzioni: max-rate  (supportato solo dai gruppi di istanze zonali) max-rate-per-instance  (supportato da tutti i gruppi di istanze)
	UTILIZATION	Facoltativamente, puoi specificare una delle seguenti opzioni: (1) max-utilization (2) max-rate  (supportato solo dai gruppi di istanze zonali) (3) max-rate-per-instance  (supportato da tutti i gruppi di istanze) (1) e (2) insieme (1) e (3) insieme
NEG a livello di zona GCP_VM_IP_PORT NEGS ibridi NON_GCP_PRIVATE_IP_PORT	RATE	Devi specificare una delle seguenti opzioni: max-rate per NEG a livello di zona max-rate-per-endpoint

Bilanciatori del carico di rete proxy

Questa tabella elenca le combinazioni di modalità di bilanciamento e capacità target disponibili per i bilanciatori del carico di rete proxy.

Tabella: combinazioni di modalità di bilanciamento e capacità target per i bilanciatori del carico di rete proxy

Tipo di backend	Modalità di bilanciamento	Specifiche della capacità target
Gruppi di istanze non gestita a livello di zona gestita a livello di zona gestito a livello di regione	CONNECTION	Devi specificare una delle seguenti opzioni: max-connections  (supportato solo dai gruppi di istanze zonali) max-rate-per-instance  (supportato da tutti i gruppi di istanze)
	UTILIZATION	Facoltativamente, puoi specificare una delle seguenti opzioni: (1) max-utilization (2) max-connections  (supportato solo dai gruppi di istanze zonali) (3) max-connections-per-instance  (supportato da tutti i gruppi di istanze) (1) e (2) insieme (1) e (3) insieme
NEG a livello di zona GCP_VM_IP_PORT NEGS ibridi NON_GCP_PRIVATE_IP_PORT	CONNECTION	Devi specificare una delle seguenti opzioni: max-connections per NEG a livello di zona max-connections-per-endpoint

Bilanciatori del carico di rete passthrough

Questa tabella elenca le combinazioni di modalità di bilanciamento e capacità target disponibili per i bilanciatori del carico di rete passthrough.

Tabella: combinazioni di modalità di bilanciamento e capacità target per i bilanciatori del carico di rete passthrough

Tipo di backend	Modalità di bilanciamento	Specifiche della capacità target
Gruppi di istanze non gestita a livello di zona gestita a livello di zona gestito a livello di regione	CONNECTION	Non puoi specificare un numero massimo di connessioni target.
NEG a livello di zona GCP_VM_IP	CONNECTION	Non puoi specificare un numero massimo di connessioni target.

Scalatore della capacità

Utilizza lo scalare della capacità per scalare la capacità target (utilizzazione massima, frequenza massima o connessioni massime) senza modificarla.

Per la documentazione di riferimento di Google Cloud, consulta quanto segue:

• Google Cloud CLI: capacity-scaler
• API:
  • Regionale
  • Globale

Puoi modificare lo scalare della capacità per scalare la capacità target effettiva senza modificare esplicitamente uno dei parametri --max-*.

Puoi impostare lo scalare della capacità su uno dei seguenti valori:

• Il valore predefinito è 1, il che significa che il gruppo pubblica fino al 100% della sua capacità configurata (a seconda di balancingMode).
• Un valore 0 indica che il gruppo è completamente esaurito e offre lo 0% della sua capacità disponibile. Non puoi configurare un'impostazione di 0 se al servizio di backend è collegato un solo backend.
• Un valore compreso tra 0.1 (10%) e 1.0 (100%).

I seguenti esempi mostrano come funziona lo scalare della capacità in combinazione con l'impostazione della capacità target:

• Se la modalità di bilanciamento è RATE, max-rate è impostato su 80 RPS e lo scalare della capacità è 1.0, la capacità disponibile è anche 80 RPS.

• Se la modalità di bilanciamento è RATE, max-rate è impostato su 80 RPS e lo scalare della capacità è 0.5, la capacità disponibile è 40 RPS (0.5 times 80).

• Se la modalità di bilanciamento è RATE, max-rate è impostato su 80 RPS e lo scalare della capacità è 0.0, la capacità disponibile è zero (0).

Nota: lo scalare della capacità non è supportato per i backend che non supportano una modalità di bilanciamento. Sono inclusi i backend come i NEG internet, i NEG serverless e i NEG PSC.

Criterio di bilanciamento del carico del servizio

Un criterio di bilanciamento del carico del servizio (serviceLbPolicy) è una risorsa associata al servizio di backend del bilanciatore del carico. Ti consente di personalizzare i parametri che influenzano la modalità di distribuzione del traffico all'interno dei backend associati a un servizio di backend:

• Personalizza l'algoritmo di bilanciamento del carico utilizzato per determinare la modalità di distribuzione del traffico tra regioni o zone.
• Attiva lo scarico automatico della capacità in modo che il bilanciatore del carico possa scaricare rapidamente il traffico dai backend non funzionanti.

Inoltre, puoi designare backend specifici come backend preferiti. Questi backend devono essere utilizzati fino alla capacità (ovvero la capacità target specificata dalla modalità di bilanciamento del backend) prima che le richieste vengano inviate ai backend rimanenti.

Per scoprire di più, consulta Ottimizzazioni del bilanciamento del carico avanzate con un criterio di bilanciamento del carico del servizio.

Criterio di bilanciamento del carico per le località

Per un servizio di backend, la distribuzione del traffico si basa su una modalità di bilanciamento e su un criterio di bilanciamento del carico per le località. La modalità di bilanciamento determina la frazione di trafico da inviare a ciascun backend (gruppo di istanze o NEG). Il criterio di località per il bilanciamento del carico (LocalityLbPolicy) determina quindi la modalità di distribuzione del traffico tra le istanze o gli endpoint all'interno di ogni zona. Per i gruppi di istanze gestite regionali, il criterio di località si applica a ogni zona costituente.

Il criterio di località del bilanciamento del carico è configurato per servizio di backend. Sono disponibili le seguenti impostazioni:

• ROUND_ROBIN (valore predefinito): si tratta dell'impostazione predefinita del criterio di bilanciamento del carico per le località in cui il bilanciatore del carico seleziona un backend in stato integro in ordine di tipo round robin.

• LEAST_REQUEST: un algoritmo O(1) in cui il bilanciatore del carico seleziona due host casuali in stato integro e sceglie quello con meno richieste attive.

• RING_HASH: questo algoritmo implementa l'hashing coerente nei backend. L'algoritmo ha la proprietà per la quale l'aggiunta o la rimozione di un host da un insieme di N host influisce solo su 1/N delle richieste.

• RANDOM: il bilanciatore del carico seleziona un host casuale in stato integro.

• ORIGINAL_DESTINATION: il bilanciatore del carico seleziona un backend in base ai metadati di connessione del client. Le connessioni vengono aperte all'indirizzo IP di destinazione originale specificato nella richiesta del client in entrata, prima che la richiesta venga reindirizzata al bilanciatore del carico.

  ORIGINAL_DESTINATION non è supportato per i bilanciatori del carico delle applicazioni esterni regionali e globali.

• MAGLEV: implementa l'hashing coerente nei backend e può essere utilizzato come sostituzione del criterio RING_HASH. Maglev non è stabile quanto RING_HASH ma ha tempi di creazione della ricerca nelle tabelle e di selezione dell'host più rapidi. Per ulteriori informazioni su Maglev, consulta il white paper su Maglev.

• WEIGHTED_MAGLEV: implementa il bilanciamento del carico ponderato per istanza utilizzando i pesi segnalati dai controlli di integrità. Se viene utilizzato questo criterio, il servizio di backend deve configurare un controllo di integrità basato su HTTP non legacy e le risposte al controllo di integrità devono contenere il campo dell'intestazione di risposta HTTP non standard X-Load-Balancing-Endpoint-Weight per specificare i pesi per istanza. Le decisioni di bilanciamento del carico vengono prese in base ai pesi per istanza riportati nelle ultime risposte al controllo di integrità elaborate, a condizione che ogni istanza riporti un valore valido o UNAVAILABLE_WEIGHT. In caso contrario, il bilanciamento del carico rimarrà con lo stesso peso.

  WEIGHTED_MAGLEV è supportato solo per i bilanciatori del carico di rete passthrough esterni. Per un esempio, consulta Configurare il bilanciamento del carico ponderato per i bilanciatori del carico di rete passthrough esterni.

La configurazione di un criterio di località per il bilanciamento del carico è supportata solo per i servizi di backend utilizzati con i seguenti bilanciatori del carico:

• Bilanciatore del carico delle applicazioni esterno globale
• Bilanciatore del carico delle applicazioni esterno regionale
• Bilanciatore del carico delle applicazioni interno tra regioni
• Bilanciatore del carico delle applicazioni interno regionale
• Bilanciatore del carico di rete passthrough esterno

Tieni presente che il valore predefinito effettivo del criterio di località per il bilanciamento del carico (localityLbPolicy) cambia in base alle impostazioni di affinità della sessione. Se l'affinità sessione non è configurata, ovvero se rimane al valore predefinito NONE, 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 configurare un criterio di località del bilanciamento del carico, puoi utilizzare la console Google Cloud, gcloud (--locality-lb-policy) o l'API (localityLbPolicy).

Cloud Service Mesh e distribuzione del traffico

Cloud Service Mesh utilizza anche le risorse di servizio di backend. Nello specifico, Cloud Service Mesh utilizza servizi di backend il cui schema di bilanciamento del carico è INTERNAL_SELF_MANAGED. Per un servizio di backend autogestito interno, la distribuzione del traffico si basa sulla combinazione di una modalità di bilanciamento del carico e di un criterio di bilanciamento del carico. Il servizio di backend indirizza il traffico a un backend in base alla modalità di bilanciamento del backend. Cloud Service Mesh distribuisce quindi il traffico in base a un criterio di bilanciamento del carico.

I servizi di backend interni con gestione indipendente supportano le seguenti modalità di bilanciamento:

• UTILIZATION, se tutti i backend sono gruppi di istanze
• RATE, se tutti i backend sono gruppi di istanze o NEG a livello di zona

Se scegli la modalità di bilanciamento RATE, devi specificare una frequenza massima, una frequenza massima per istanza o una frequenza massima per endpoint.

Per saperne di più su Cloud Service Mesh, consulta Concetti di Cloud Service Mesh.

Sottoinsieme di backend

La sottoimpostazione del backend è una funzionalità facoltativa che migliora il rendimento e la scalabilità assegnando un sottoinsieme di backend a ciascuna istanza proxy.

La sottoimpostazione del backend è supportata per quanto segue:

• Bilanciatore del carico delle applicazioni interno regionale
• Bilanciatore del carico di rete passthrough interno

Sottoinsieme di backend per bilanciatori del carico delle applicazioni interni regionali

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Il bilanciatore del carico delle applicazioni interno tra regioni non supporta i sottoinsiemi di backend.

Per i bilanciatori del carico delle applicazioni interni regionali, il sottoinsieme di backend assegna automaticamente solo un sottoinsieme di backend all'interno del servizio di backend regionale a ogni istanza proxy. Per impostazione predefinita, ogni istanza proxy apre connessioni a tutti i backend all'interno di un servizio di backend. Quando il numero di istanze proxy e di backend è elevato, l'apertura di connessioni a tutti i backend può causare problemi di prestazioni.

Se attivi i sottoinsiemi, ogni proxy apre connessioni solo a un sottoinsieme di backend, riducendo il numero di connessioni mantenute aperte per ciascun backend. La riduzione del numero di connessioni aperte contemporaneamente a ciascun backend può migliorare le prestazioni sia dei backend che dei proxy.

Il seguente diagramma mostra un bilanciatore del carico con due proxy. Senza il sottoinsieme di backend, il traffico di entrambi i proxy viene distribuito a tutti i backend nel servizio di backend 1. Con l'attivazione dei sottoinsiemi di backend, il traffico di ciascun proxy viene distribuito a un sottoinsieme di backend. Il traffico del proxy 1 viene distribuito ai backend 1 e 2, mentre il traffico del proxy 2 viene distribuito ai backend 3 e 4.

Confronto tra bilanciatore del carico delle applicazioni interno senza e con sottoinsieme di backend (fai clic per ingrandire).

Puoi anche perfezionare il traffico di bilanciamento del carico verso i backend impostando il criteriolocalityLbPolicy. Per ulteriori informazioni, consulta le norme sul traffico.

Per informazioni sulla configurazione dell'impostazione secondaria del backend per i bilanciatori del carico delle applicazioni interni, consulta Configurare l'impostazione secondaria del backend.

Limitazioni relative all'impostazione secondaria del backend per il bilanciatore del carico delle applicazioni interno

• Sebbene la sottoimpostazione del backend sia progettata per garantire che tutte le istanze di backend rimangano ben utilizzate, può introdurre un certo bias nella quantità di traffico che ciascun backend riceve. L'impostazione di localityLbPolicy su LEAST_REQUEST è consigliata per i servizi di backend sensibili al bilanciamento del carico di backend.
• L'attivazione o la disattivazione dei sottoinsiemi interrompe le connessioni esistenti.
• La sottoimpostazione del backend richiede che l'affinità sessione sia NONE (un hash di 5 tuple). Le altre opzioni di affinità sessione possono essere utilizzate solo se il sottoinsieme di backend è disabilitato. I valori predefiniti degli indicatori --subsetting-policy e --session-affinity sono entrambi NONE e solo uno alla volta può essere impostato su un valore diverso.

Sottoinsieme di backend per il bilanciatore del carico di rete passthrough interno

La sottoimpostazione del backend per i bilanciatori del carico di rete passthrough interni ti consente di scalare il bilanciatore del carico di rete passthrough interno per supportare un numero maggiore di istanze VM di backend per servizio di backend interno.

Per informazioni su come i sottoinsiemi influiscono su questo limite, consulta la sezione"Servizi di backend" di Quote e limiti delle risorse di bilanciamento del carico.

Per impostazione predefinita, il sottoinsieme è disabilitato, il che limita la distribuzione del servizio di backend a un massimo di 250 istanze o endpoint di backend. Se il tuo servizio di backend deve supportare più di 250 backend, puoi attivare i sottoinsiemi. Quando il sottoinsieme è attivato, viene selezionato un sottoinsieme di istanze di backend per ogni connessione del client.

Il seguente diagramma mostra un modello ridotto della differenza tra queste due modalità di funzionamento.

Confronto di un bilanciatore del carico di rete passthrough interno senza e con sottoinsieme (fai clic per ingrandire).

Senza sottoinsiemi, l'insieme completo di backend integri viene utilizzato meglio e le nuove connessioni dei client vengono distribuite tra tutti i backend integri in base alla distribuzione del traffico. Il sottoinsieme impone limitazioni al bilanciamento del carico, ma consente al bilanciatore del carico di supportare più di 250 backend.

Per le istruzioni di configurazione, consulta Subsetting.

Limitazioni relative al sottoinsieme di backend per il bilanciatore del carico di rete passthrough interno

• Quando i sottoinsiemi sono abilitati, non tutti i backend riceveranno traffico da un determinato mittente anche se il numero di backend è ridotto.
• Per il numero massimo di istanze di backend quando è abilitato il sottoinsieme, consulta la pagina delle quote .
• Con il sottoinsieme è supportata solo l'affinità sessione con 5 tuple.
• Mirroring pacchetto non è supportato con i sottoinsiemi.
• L'attivazione o la disattivazione dei sottoinsiemi interrompe le connessioni esistenti.
• Se i client on-premise devono accedere a un bilanciatore del carico di rete passthrough interno, i sottoinsiemi possono ridurre notevolmente il numero di backend che ricevono connessioni dai client on-premise. Questo perché la regione del tunnel Cloud VPN o del collegamento VLAN Cloud Interconnect determina il sottoinsieme dei backend del bilanciatore del carico. Tutti gli endpoint Cloud VPN e Cloud Interconnect in una regione specifica utilizzano lo stesso sottoinsieme. Vengono utilizzati sottoinsiemi diversi in regioni diverse.

Prezzi dei sottoinsiemi di backend

Non è previsto alcun costo per l'utilizzo della sottoimpostazione del backend. Per ulteriori informazioni, consulta la sezione Tutti i prezzi di networking.

Affinità sessione

L'affinità di sessione ti consente di controllare in che modo il bilanciatore del carico seleziona i backend per le nuove connessioni in modo prevedibile, purché il numero di backend operativi rimanga costante. Questo è utile per le applicazioni che richiedono l'invio di più richieste da parte di un determinato utente allo stesso backend o endpoint. Queste applicazioni in genere includono server stateful utilizzati per la pubblicazione di annunci, giochi o servizi con una cache interna elevata.

I bilanciatori del carico di Google Cloud forniscono l'affinità sessione su una base di miglior impegno. Fattori come la modifica degli stati del controllo di integrità del backend, l'aggiunta o la rimozione di backend, le modifiche ai pesi del backend (inclusa l'abilitazione o la disattivazione del bilanciamento ponderato) o le modifiche al grado di saturazione del backend, misurato dalla modalità di bilanciamento, possono interrompere l'affinità sessione.

Il bilanciamento del carico con affinità sessione funziona bene quando esiste una distribuzione ragionevolmente ampia di connessioni univoche. Una quantità ragionevolmente elevata indica almeno diverse volte il numero di backend. Il test di un bilanciatore del carico con un numero ridotto di connessioni non produrrà una rappresentazione accurata della distribuzione delle connessioni dei client tra i backend.

Per impostazione predefinita, tutti i bilanciatori del carico Google Cloud selezionano i backend utilizzando un hashing a cinque tuple (--session-affinity=NONE), come segue:

• Indirizzo IP di origine del pacchetto
• Porta di origine del pacchetto (se presente nell'intestazione del pacchetto)
• Indirizzo IP di destinazione del pacchetto
• Porta di destinazione del pacchetto (se presente nell'intestazione del pacchetto)
• Protocollo del pacchetto

Per i bilanciatori del carico pass-through, le nuove connessioni vengono distribuite a endpoint o istanze di backend integri (nel pool attivo, se è configurato un criterio di failover). Puoi controllare quanto segue:

• Indica se le connessioni stabilite persistono su backend non integri. Per maggiori dettagli, consulta Persistenza della connessione su backend non integri nella documentazione del bilanciatore del carico di rete passthrough interno e Persistenza della connessione su backend non integri nella documentazione del bilanciatore del carico di rete passthrough esterno basato sul servizio di backend.
• Indica se le connessioni stabilite persistono durante il failover e il failback, se è configurato un criterio di failover. Per maggiori dettagli, consulta la documentazione sul ritiro delle connessioni in caso di failover e failback nel bilanciatore del carico di rete passthrough interno e la documentazione sul ritiro delle connessioni in caso di failover e failback nel bilanciatore del carico di rete passthrough esterno basato sul servizio di backend.
• Il tempo per cui le connessioni stabilite possono persistere quando viene rimosso un backend dal bilanciatore del carico. Per maggiori dettagli, vedi Attivare il ritiro delle connessioni.

Per i bilanciatori del carico basati su proxy, purché il numero di endpoint o istanze di backend integri rimanga costante e purché l'endpoint o l'istanza di backend selezionata in precedenza non sia al limite della capacità, le richieste o le connessioni successive vengono indirizzate alla stessa VM o allo stesso endpoint di backend. La capacità target della modalità di bilanciamento determina quando il backend ha raggiunto la capacità.

La tabella seguente mostra le opzioni di affinità sessione supportate per ciascun prodotto:

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	Nessuno (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE) Campo intestazione (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Affinità basata su cookie stateful (STRONG_COOKIE_AFFINITY) Tieni inoltre presente quanto segue: Il valore predefinito effettivo del criterio di bilanciamento del carico per le località (localityLbPolicy) varia in base alle impostazioni di affinità della sessione. Se l'affinità sessione non è configurata, ovvero se rimane al valore predefinito NONE, 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 l'affinità sessione se utilizzi la suddivisione del traffico ponderata. In questo caso, la configurazione della suddivisione del traffico ponderata avrà la precedenza.
Bilanciatore del carico delle applicazioni classico	Nessuno (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE)
Bilanciatore del carico delle applicazioni interno tra regioni Bilanciatore del carico delle applicazioni interno regionale	Nessuno (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE) Campo intestazione (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Affinità basata su cookie stateful (STRONG_COOKIE_AFFINITY) Tieni inoltre presente quanto segue: Il valore predefinito effettivo del criterio di bilanciamento del carico per le località (localityLbPolicy) varia in base alle impostazioni di affinità della sessione. Se l'affinità sessione non è configurata, ovvero se rimane al valore predefinito NONE, 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 interno, non configurare l'affinità sessione se utilizzi la suddivisione del traffico ponderata. In questo caso, la configurazione della suddivisione del traffico ponderata avrà la precedenza.
Bilanciatore del carico di rete passthrough interno	Nessuno (NONE) CLIENT IP, nessuna destinazione (CLIENT_IP_NO_DESTINATION) IP client, IP di destinazione (CLIENT_IP) IP client, IP di destinazione, Protocollo (CLIENT_IP_PROTO) IP client, porta client, IP destinazione, porta destinazione, protocollo (CLIENT_IP_PORT_PROTO) Per informazioni specifiche sul bilanciatore del carico di rete passthrough interno e sull'affinità sessione, consulta la panoramica del bilanciatore del carico di rete passthrough interno.
Bilanciatore del carico di rete passthrough esterno^*	Nessuno (NONE) IP client, IP di destinazione (CLIENT_IP) IP client, IP di destinazione, Protocollo (CLIENT_IP_PROTO) IP client, porta client, IP destinazione, porta destinazione, protocollo (CLIENT_IP_PORT_PROTO) Per informazioni specifiche sul bilanciatore del carico di rete passthrough esterno e sull'affinità sessione, consulta la panoramica del bilanciatore del carico di rete passthrough esterno TCP/UDP.
Bilanciatore del carico di rete proxy esterno globale Bilanciatore del carico di rete proxy classico Bilanciatore del carico di rete proxy esterno regionale Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy interno tra regioni	Nessuno (NONE) IP client (CLIENT_IP)
Cloud Service Mesh	Nessuno (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE) (solo protocolli HTTP) Campo dell'intestazione (HEADER_FIELD) (solo protocolli HTTP) Cookie HTTP (HTTP_COOKIE) (solo protocolli HTTP)

^* Questa tabella descrive le affinità di sessione supportate dai bilanciatori del carico di rete passthrough esterni basati su servizi di backend. I bilanciatori del carico di rete passthrough esterni basati su pool di destinazione non utilizzano i servizi di backend. Devi invece impostare l'affinità sessione per i bilanciatori del carico di rete passthrough esterni tramite il parametro sessionAffinity in Pool di destinazione.

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

• Non fare affidamento sull'affinità sessione per motivi di autenticazione o sicurezza. L'affinità sessione, ad eccezione dell'affinità sessione basata su cookie stateful, è progettata per interrompersi ogni volta che cambia il numero di backend di pubblicazione e integri. Per maggiori dettagli, consulta Perdita di affinità di sessione.

• I valori predefiniti degli indicatori --session-affinity e --subsetting-policy sono entrambi NONE e solo uno di questi alla volta può essere impostato su un valore diverso.

Tipi di affinità sessione

Le sezioni seguenti illustrano i diversi tipi di affinità sessione:

IP client, nessuna affinità di destinazione

L'affinità sessione IP client, nessuna destinazione (CLIENT_IP_NO_DESTINATION) è un hash a una tupla basato solo sull'indirizzo IP di origine di ogni pacchetto ricevuto. Questa affinità sessione è disponibile solo per i bilanciatori del carico di rete passthrough interni.

Questa opzione può essere utile in situazioni in cui è necessaria la stessa VM di backend per elaborare tutti i pacchetti di un client, in base esclusivamente all'indirizzo IP di origine del pacchetto, senza tenere conto dell'indirizzo IP di destinazione del pacchetto. Queste situazioni solitamente si verificano quando un bilanciatore del carico di rete passthrough interno è un hop successivo per una route statica. Per maggiori dettagli, consulta Affinità di sessione e bilanciatori del carico di rete passthrough interni per hop successivo.

Affinità IP client

L'affinità sessione IP client (CLIENT_IP) è un hash a due tuple creato dagli indirizzi IP di origine e di destinazione del pacchetto. L'affinità sessione dell'IP client è disponibile per tutti i bilanciatori del carico Google Cloud che utilizzano servizi di backend. I bilanciatori del carico di rete passthrough esterni chiamano questa opzione di affinità sessione IP client, IP destinazione.

Quando utilizzi l'affinità IP client, tieni presente quanto segue:

• L'indirizzo IP di destinazione del pacchetto corrisponde all'indirizzo IP della regola di forwarding del bilanciatore del carico solo se il pacchetto viene inviato direttamente al bilanciatore del carico.

• I pacchetti inoltrati a un bilanciatore del carico di rete passthrough interno di hop successivo da una route statica hanno indirizzi IP di destinazione che non corrispondono all'indirizzo IP della regola di inoltro del bilanciatore del carico. Per dettagli importanti, consulta Affinità di sessione e bilanciatori del carico di rete passthrough interni di hop successivo.

• L'indirizzo IP sorgente del pacchetto potrebbe non corrispondere a un indirizzo IP associato al client originale se il pacchetto viene elaborato da un sistema proxy o NAT intermedio prima di essere inviato 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 di altre.

Affinità cookie generata

Quando utilizzi l'affinità basata su cookie generata, 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. I seguenti prodotti supportano i cookie generati:

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
Bilanciatori del carico delle applicazioni interni tra regioni	GCILB
Bilanciatori del carico delle applicazioni interni regionali	GCILB
Cloud Service Mesh	GCILB

L'attributo path del cookie generato è sempre una barra (/), pertanto 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'Cookie intestazione della richiesta delle richieste HTTP, il bilanciatore del carico indirizza queste richieste alla stessa istanza o allo stesso endpoint di backend, purché il cookie di affinità sessione rimanga valido. Ciò viene fatto mappando il valore del cookie a un indice che fa riferimento a un'istanza o a un endpoint del backend specifico e assicurandosi che i requisiti di affinità sessione del cookie generato siano soddisfatti.

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

• Per i gruppi di istanza di backend, utilizza la modalità di bilanciamento RATE.
• Per il 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 ulteriori informazioni, consulta la sezione sulla perdita dell'affinità sessione.

Affinità del campo intestazione

Con l'affinità del campo dell'intestazione, 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 dell'intestazione HTTP diverso.

I seguenti bilanciatori del carico utilizzano l'affinità del campo dell'intestazione:

• Cloud Service Mesh
• Bilanciatore del carico delle applicazioni interno tra regioni
• Bilanciatore del carico delle applicazioni esterno globale
• Bilanciatore del carico delle applicazioni esterno regionale
• Bilanciatore del carico delle applicazioni interno regionale

L'affinità dei campi dell'intestazione è supportata quando le seguenti condizioni sono vere:

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

Per scoprire quali prodotti supportano l'affinità dei campi di intestazione, consulta la Tabella: impostazioni di affinità sessione supportate.

Affinità cookie HTTP

Quando utilizzi l'affinità basata su cookie HTTP, il bilanciatore del carico include un cookie HTTP nell'intestazione Set-Cookie in risposta alla richiesta HTTP iniziale. Devi specificare il nome, il percorso e la durata (TTL) del cookie.

I seguenti prodotti supportano l'affinità basata su cookie HTTP:

• Tutti i bilanciatori del carico delle applicazioni
• Cloud Service Mesh

Puoi configurare i valori TTL del cookie utilizzando secondi, frazioni di secondo (in nanosecondi) o entrambi i secondi più le frazioni di secondo (in nanosecondi) utilizzando i seguenti parametri di 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 entrambi i valori consistentHash.httpCookie.ttl.seconds e 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'Cookie intestazione della richiesta delle richieste HTTP, il bilanciatore del carico indirizza queste richieste alla stessa istanza o allo stesso endpoint di backend, a condizione che il cookie di affinità della sessione rimanga valido. Ciò viene fatto mappando il valore del cookie a un indice che fa riferimento a un'istanza o a un endpoint del backend specifico e assicurandosi che vengano soddisfatti i requisiti di affinità sessione del cookie generato.

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

• Per i gruppi di istanza di backend, utilizza la modalità di bilanciamento RATE.
• Per il 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 ulteriori informazioni, consulta la sezione sulla perdita dell'affinità sessione.

Affinità sessione basata su cookie stateful

Quando utilizzi l'affinità basata su cookie stateful, il bilanciatore del carico include un cookie HTTP nell'intestazione Set-Cookie in risposta alla richiesta HTTP iniziale. Specifica il nome, il percorso e durata (TTL) del cookie.

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

Puoi configurare i valori TTL del cookie utilizzando secondi, frazioni di secondo (in nanosecondi) o entrambi i secondi più le frazioni di secondo (in 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 richieste HTTP successive, il bilanciatore del carico indirizza queste richieste all'istanza o all'endpoint del backend selezionato.

A differenza di altri metodi di affinità sessione:

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

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

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

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

Per ulteriori informazioni, consulta la sezione sulla perdita dell'affinità sessione.

Significato di TTL zero per le affinità basate sui cookie

Tutte le affinità sessione basate su cookie, come l'affinità cookie generato, l'affinità cookie HTTP e l'affinità basata su cookie stateful, hanno un attributo TTL.

Un TTL di zero secondi indica che il bilanciatore del carico non assegna un attributo Expires al cookie. In questo caso, il client tratta il cookie come un cookie di sessione. La definizione di una sessione varia in base al client:

• Alcuni client, come i browser web, mantengono il cookie per l'intera sessione di navigazione. Ciò significa che il cookie persiste su più richieste fino alla chiusura dell'applicazione.

• Altri client trattano una sessione come una singola richiesta HTTP, ignorando il cookie subito dopo.

Perdita dell'affinità sessione

Tutte le opzioni di affinità sessione per i bilanciatori del carico delle applicazioni e i bilanciatori del carico di rete proxy richiedono quanto segue:

• L'endpoint o l'istanza di backend selezionato deve rimanere configurato come backend. L'affinità di sessione può essere interrotta quando si verifica uno dei seguenti eventi:

  • Rimuovi l'istanza selezionata 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 relativo 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à delle sessioni può essere interrotta quando l'istanza o l'endpoint selezionato non supera i controlli di stato.

• Per i bilanciatori del carico delle applicazioni esterni globali, i bilanciatori del carico delle applicazioni classici, i bilanciatori del carico di rete con proxy esterno globale e i bilanciatori del carico di rete con proxy classici, l'affinità sessione può essere interrotta se viene utilizzato un altro Google Front End (GFE) di primo livello 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 instradamento da un client su internet a Google cambia tra richieste o connessioni.

Ad eccezione dell'affinità di sessione basata su cookie stateful, tutte le opzioni di affinità sessione per i bilanciatori del carico delle applicazioni e i bilanciatori del carico di rete proxy hanno i seguenti requisiti aggiuntivi:

• Il gruppo di istanze o il gruppo di endpoint di rete che contiene l'istanza o l'endpoint selezionato non deve essere pieno come definito dalla relativa capacità target. Per i gruppi di istanze gestite regionali, il componente a livello di zona del gruppo di istanze che contiene l'istanza selezionata non deve essere pieno. L'affinità di sessione può essere interrotta quando il gruppo di istanze o il NEG è pieno e altri gruppi di istanze o NEG non lo sono. Poiché il grado di completezza può variare in modo imprevedibile quando si utilizza la modalità di bilanciamento UTILIZATION, ti consigliamo di utilizzare la modalità di bilanciamento RATE o CONNECTION per ridurre al minimo le situazioni in cui l'affinità sessione può essere interrotta.

• 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'affinità sessione può essere interrotta:

  • Aggiunta di nuove istanze o endpoint:

    • Aggiungi istanze a un gruppo di istanze esistente nel servizio di backend.
    • La scalabilità automatica dei gruppi di istanze gestite aggiunge istanze a un gruppo di istanze gestite sul 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.

  • La rimozione di qualsiasi istanza o endpoint, non solo dell'istanza o dell'endpoint selezionato:

    • Rimuovi qualsiasi istanza dal backend di un 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 dal backend di un NEG.
    • Rimuovi eventuali gruppi di istanze o NEG di backend esistenti non vuoti dal servizio di backend.

• Il numero totale di endpoint o istanze di backend integri deve rimanere costante. Quando si verifica almeno uno dei seguenti eventi, il numero di istanze o endpoint di backend integri cambia e l'affinità sessione può essere interrotta:

  • Qualsiasi istanza o endpoint supera il controllo di integrità, passando da stato non integro a stato integro.
  • Qualsiasi istanza o endpoint non supera il controllo di integrità, passando da stato integro a non integro o a timeout.

Timeout del servizio di backend

La maggior parte dei bilanciatori del carico di Google Cloud ha un timeout del servizio di backend. Il valore predefinito è 30 secondi. L'intervallo completo di valori di timeout consentiti è da 1 a 2.147.483.647 secondi.

• Per i bilanciatori del carico delle applicazioni esterni e interni che utilizzano il protocollo HTTP, HTTPS o HTTP/2, il timeout del servizio di backend è un timeout di richiesta e risposta per il traffico HTTP(S).

  Per ulteriori dettagli sul timeout del servizio di backend per ogni bilanciatore del carico, consulta quanto segue:

  • Per i bilanciatori del carico delle applicazioni esterni globali e regionali, consulta Timeout e ripetizioni.
  • Per i bilanciatori del carico delle applicazioni interni, consulta Timeout e ripetizioni.

• Per i bilanciatori del carico di rete proxy esterni,il timeout è un timeout di inattività. Per concedere più o meno tempo prima dell'eliminazione della connessione, modifica il valore di timeout. Questo timeout inattivo viene utilizzato anche per le connessioni WebSocket.

• Per i bilanciatori del carico di rete passthrough interni e esterni,puoi impostare il valore del timeout del servizio di backend utilizzando gcloud o l'API, ma il valore viene ignorato. Il timeout del servizio di backend non ha significato per questi bilanciatori del carico pass-through.

• Per Cloud Service Mesh, il campo del timeout del servizio di backend (specificato utilizzando timeoutSec) non è supportato con i servizi gRPC senza proxy. Per questi servizi, configura il timeout del servizio di backend utilizzando il campo maxStreamDuration. Questo perché gRPC non supporta la semantica di timeoutSec che specifica il tempo di attesa per un backend per restituire una risposta completa dopo l'invio della richiesta. Il timeout di gRPC specifica il tempo di attesa dall'inizio dello stream fino al completamento dell'elaborazione della risposta, inclusi tutti i tentativi di nuovo invio.

Controlli di integrità

Ogni servizio di backend i cui backend sono gruppi di istanze o NEG a livello di zona deve avere un controllo di integrità associato. I servizi di backend che utilizzano un NEG serverless o un NEG internet globale come backend non devono fare riferimento a un controllo di integrità.

Quando crei un bilanciatore del carico utilizzando la console Google Cloud, puoi creare il controllo di integrità, se necessario, durante la creazione del bilanciatore del carico oppure puoi fare riferimento a un controllo di integrità esistente.

Quando crei un servizio di backend utilizzando i backend NEG di gruppo di istanze o zonali utilizzando l'API o Google Cloud CLI, devi fare riferimento a un controllo di integrità esistente. Per informazioni dettagliate sul tipo e sull'ambito del controllo di integrità richiesto, consulta la guida al bilanciatore del carico nella Panoramica dei controlli di integrità.

Per ulteriori informazioni, leggi i seguenti documenti:

• Panoramica dei controlli di integrità
• Creazione di controlli di integrità
• gcloud pagina del controllo di integrità
• Pagina di controllo di integrità dell'API REST

Funzionalità aggiuntive abilitate nella risorsa del servizio di backend

Le seguenti funzionalità facoltative sono supportate da alcuni servizi di backend.

Cloud CDN

Cloud CDN utilizza la rete perimetrale globale di Google per distribuire i contenuti nelle aree più vicine agli utenti al fine di velocizzare i siti web e le applicazioni. Cloud CDN è attivato sui servizi di backend utilizzati dai bilanciatori del carico delle applicazioni esterni globali. Il bilanciatore del carico fornisce le porte e gli indirizzi IP frontend che ricevono le richieste e i backend che rispondono alle richieste.

Per ulteriori dettagli, consulta la documentazione di Cloud CDN.

Cloud CDN non è compatibile con IAP. Non possono essere attivati nello stesso servizio di backend.

Google Cloud Armor

Se utilizzi uno dei seguenti bilanciatori del carico, puoi aggiungere ulteriore protezione alle tue applicazioni attivando Google Cloud Armor nel servizio di backend durante la creazione del bilanciatore del carico:

• Bilanciatore del carico delle applicazioni esterno globale
• Bilanciatore del carico delle applicazioni classico
• Bilanciatore del carico di rete proxy esterno globale
• Bilanciatore del carico di rete proxy classico

Se utilizzi la console Google Cloud, puoi eseguire una delle seguenti operazioni:

• Seleziona un criterio di sicurezza di Google Cloud Armor esistente.
• Accetta la configurazione di un criterio di sicurezza di Google Cloud Armor con limitazione della frequenza predefinito con un nome, un conteggio delle richieste, un intervallo, una chiave e parametri di limitazione di frequenza personalizzabili. Se utilizzi Google Cloud Armor con un servizio proxy upstream, ad esempio un provider CDN, Enforce_on_key deve essere impostato come indirizzo IP XFF.
• Scegli di disattivare la protezione di Google Cloud Armor selezionando Nessuna.

IAP

IAP consente di definire un livello di autorizzazione centrale per le applicazioni accessibili tramite HTTPS, che ti permette di utilizzare un modello di controllo dell'accesso dell'accesso a livello di applicazione invece di dover fare affidamento su firewall a livello di rete. IAP è supportato da determinati bilanciatori del carico delle applicazioni.

IAP non è compatibile con Cloud CDN. Non possono essere attivati sullo stesso servizio di backend.

Funzionalità avanzate di gestione del traffico

Per informazioni sulle funzionalità di gestione avanzata del traffico configurate sui servizi di backend e sulle mappe URL associate ai bilanciatori del carico, consulta quanto segue:

• Panoramica della gestione del traffico per i bilanciatori del carico delle applicazioni interni
• Panoramica della gestione del traffico per bilanciatori del carico delle applicazioni esterni globali
• Panoramica della gestione del traffico per bilanciatori del carico delle applicazioni esterni regionali

API e riferimenti gcloud

Per ulteriori informazioni sulle proprietà della risorsa del servizio di backend, consulta i seguenti riferimenti:

• Risorsa API di servizio di backend globale

• Risorsa API di servizio di backend regionale

• gcloud compute backend-services pagina, per sia i servizi di backend globali che regionali

Passaggi successivi

Per la documentazione e le informazioni correlate su come vengono utilizzati i servizi di backend nel bilanciamento del carico, consulta quanto segue:

• Creare intestazioni personalizzate
• Creare un bilanciatore del carico delle applicazioni esterno
• Panoramica del bilanciatore del carico delle applicazioni esterno
• Attivare lo svuotamento della connessione
• Crittografia dei dati in transito in Google Cloud

Per i video correlati:

• Come configurare i servizi di backend per i bilanciatori del carico delle applicazioni esterni globali