Panoramica dei servizi di backend

Un servizio di backend definisce la modalità di distribuzione del traffico 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. Un servizio di backend è globale o regionale.

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

• Indirizza il traffico ai backend 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 l'integrità dei backend.
• Specifica l'affinità sessione.
• Determina se sono attivati altri servizi, inclusi i seguenti servizi disponibili solo per determinati bilanciatori del carico:
  • Cloud CDN
  • Criteri di sicurezza di Google Cloud Armor
  • Identity-Aware Proxy
• Designa i servizi di backend a livello di regione come servizio nelle applicazioni App Hub.

Questi valori vengono impostati quando crei un servizio di backend o aggiungi un backend 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, valuta la possibilità 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 quali bilanciatori del carico 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 identificatore che Google utilizza per classificare le regole di forwarding e i servizi di backend. Ogni prodotto di bilanciamento del carico utilizza uno schema di bilanciamento del carico per le regole di forwarding 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 gestite, non gestite o una combinazione di backend del gruppo di istanze gestite e non gestite ^* 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 ibridi e a livello di zona: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT ^† Tutti i NEG serverless: una o più risorse App Engine, Cloud Run o Cloud Run 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 gestite, non gestite o una combinazione di backend di gruppi di istanze gestite e non gestite 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 ibridi e a livello di zona: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT ^† Tutti i NEG serverless: una o più risorse App Engine, Cloud Run o Cloud Run 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 gestite, non gestite o una combinazione di backend del gruppo di istanze gestite e non gestite ^* 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 ibridi e a livello di zona: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT ^† Un singolo NEG serverless (solo per Cloud Run o Cloud Run Functions2ª generazionen) Un singolo NEG Private Service Connect Tutti i NEG internet a livello di regione 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 gestite, non gestite o una combinazione di backend del gruppo di istanze gestite e non gestite ^* 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 ibridi e a livello di zona: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT ^† Un singolo NEG serverless (solo per Cloud Run o Cloud Run Functions2ª generazionen) 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 gestite, non gestite o una combinazione di backend del gruppo di istanze gestite e non gestite ^* 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 ibridi e a livello di zona: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT ^† Un singolo NEG serverless (solo per Cloud Run o Cloud Run Functions2ª generazionen) Un singolo NEG Private Service Connect Tutti i NEG internet a livello di regione 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 gestite, non gestite o una combinazione di backend del gruppo di istanze gestite e non gestite ^* 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 ibridi e a livello di zona: 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	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 gestite, non gestite o una combinazione di backend di gruppi di istanze gestite e non gestite 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 ibridi e a livello di zona: NEG di tipo GCE_VM_IP_PORT e 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 gestite, non gestite o una combinazione di backend del gruppo di istanze gestite e non gestite ^* 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 ibridi e a livello di zona: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT Tutti i NEG internet a livello di regione 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 gestite, non gestite o una combinazione di backend del gruppo di istanze gestite e non gestite ^* 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 ibridi e a livello di zona: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT Tutti i NEG internet a livello di regione 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 gestite, non gestite o una combinazione di backend del gruppo di istanze gestite e non gestite ^* 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 ibridi e a livello di zona: 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 gestite, non gestite o una combinazione di backend di gruppi di istanze gestite e non gestite 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	Regionale, 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 gestite, non gestite o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP Un NEG mappatura porte	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 gestite, non gestite o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG di zona: uno o più NEG di zona di tipo GCE_VM_IP_PORT o NON_GCP_PRIVATE_IP_PORT Un NEG internet di tipo INTERNET_FQDN_PORT Uno o più service binding	INTERNAL_SELF_MANAGED

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

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

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

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

^# È possibile collegare EXTERNAL_MANAGED servizi di backend a EXTERNAL regole di forwarding. Tuttavia, i servizi di backend EXTERNAL non possono essere collegati alle regole di forwarding 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 di migrazione descritta in Eseguire la migrazione delle risorse dal bilanciatore del carico delle applicazioni esterno classico a quello globale.

Denominazione del bilanciatore del carico

Per i bilanciatori del carico di rete proxy e i bilanciatori del carico di rete passthrough, il nome del bilanciatore del carico è sempre uguale al nome del servizio di backend. Il comportamento per ogni Google Cloud interfaccia è il seguente:

• ConsoleGoogle Cloud . Se crei un bilanciatore del carico di rete proxy o un bilanciatore del carico di rete passthrough utilizzando la console Google Cloud , al servizio di backend viene assegnato automaticamente lo stesso nome che hai inserito per il nome del bilanciatore del carico.
• Google Cloud CLI o API. Se crei un bilanciatore del carico di rete proxy o un bilanciatore del carico di rete pass-through utilizzando l'interfaccia a riga di comando gcloud o l'API, inserisci un nome a tua scelta durante la creazione del servizio di backend. Il nome di questo servizio di backend viene poi visualizzato nella console Google Cloud come nome del bilanciatore del carico.

Per scoprire di più sul funzionamento della denominazione per i bilanciatori del carico delle applicazioni, consulta Panoramica delle mappe URL: denominazione del bilanciatore del carico.

Backend

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

• Un gruppo di istanze contenente istanze di macchine virtuali (VM). Un gruppo di istanze può essere un gruppo di istanze gestite (MIG), 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 Private Service Connect
• NEG internet
• NEG connettività ibrida
• NEG mappatura porte
• Service Directory service bindings

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

Gruppi di istanze

Questa sezione descrive 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) 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 unendo un identificatore per la rete VPC del backend all'indirizzo IPv4 interno del backend. La comunicazione tra GFE e VM o endpoint di backend è facilitata tramite route speciali.
  • Per i backend dei gruppi 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 primario associato a qualsiasi interfaccia di rete di una VM o qualsiasi indirizzo IPv4 da 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 unendo un identificatore per la rete VPC del backend con l'indirizzo IPv4 interno del backend.

  • Per i backend dei gruppi 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 primario 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, a condizione che 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 recapitati ai backend con gli indirizzi IP di origine e 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 di gruppi di istanze, i pacchetti vengono sempre inviati all'interfaccia nic0 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 subnet 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 backend di 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 nel seguente modo:

• 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 che scegli e il valore rappresenta il numero di porta che assegni 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).

In base a ogni backend del 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, quest'ultimo 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 nome my-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 forwarding del bilanciatore del carico. Un bilanciatore del carico proxy è in attesa di connessioni TCP inviate all'indirizzo IP e alla porta di destinazione delle relative regole di forwarding. 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 dei gruppi di istanze. I NEG di zona con endpoint GCE_VM_IP_PORT, i NEG ibridi con endpoint NON_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 di servizio utilizzando astrazioni che non comportano la specifica di una porta di destinazione.

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

Per scoprire come creare porte denominate, segui queste istruzioni:

• Gruppi di istanze non gestite: utilizzo di porte denominate
• Gruppi di istanze gestite: assegnazione di porte denominate a 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 fa parte di due o più gruppi di istanze non gestite oppure di un gruppo di istanze gestite e di uno o più gruppi di istanze non gestite, Google Cloudti consente di utilizzare solo uno di questi gruppi 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 porte diverse, specifica le porte denominate richieste su un gruppo di istanze e fai in modo che ogni servizio di backend si iscriva a una porta denominata univoca.

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

  Le combinazioni di modalità di bilanciamento incompatibili sono le seguenti:

  • CONNECTION con UTILIZATION
  • RATE con UTILIZATION
  • CUSTOM_METRICS con UTILIZATION
  • CUSTOM_METRICS con RATE
  • CUSTOM_METRICS con CONNECTION

  Considera l'esempio seguente:

  • Hai 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 chiamato 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 in external-https-backend-service con la modalità di bilanciamento UTILIZATION.

• Per modificare la modalità di bilanciamento per 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 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 del carico.

• Se il tuo gruppo di istanze è associato a più servizi di backend, ogni 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, soprattutto se utilizzi la metrica di scalabilità automatica Utilizzo del 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 Cloud Monitoring non correlata alla capacità di gestione del bilanciatore del carico. L'utilizzo di una di queste metriche di scalabilità automatica potrebbe impedire una scalabilità irregolare.

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 una singola subnet.

Un servizio di backend che utilizza i NEG zonali come backend distribuisce il traffico tra le applicazioni o i 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 i bilanciatori del carico di rete passthrough interni e i bilanciatori del carico di rete passthrough esterni basati su servizi di backend).
• GCE_VM_IP_PORT endpoint.

Per vedere quali prodotti supportano i backend NEG zonali, consulta la tabella: servizi di backend e tipi di backend supportati.

Per maggiori dettagli, vedi Panoramica dei NEG di zona.

Gruppi di endpoint di rete internet

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

Un NEG internet è la combinazione di un nome host o un indirizzo IP, più 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 vedere 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 del gruppo 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 una risorsa Cloud Run, App Engine, Cloud Run Functions o API Gateway.

Un NEG serverless può rappresentare uno dei seguenti elementi:

• Una risorsa Cloud Run o un gruppo di risorse.
• Una funzione Cloud Run o un gruppo di funzioni (in precedenza funzioni Cloud Run2ª generazionen.).
• Una funzione Cloud Run (1ª generazione.) o un gruppo di funzioni
• Un'app dell'ambiente standard di App Engine o dell'ambiente flessibile di App Engine, 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 risorse si trovi nello stesso NEG serverless, deve avere un pattern URL comune.

Per configurare un NEG serverless per 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 entrata e instradare la richiesta al servizio Cloud Run, Cloud Run Functions o App Engine corrispondente con lo stesso nome.

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

Per saperne di più sui NEG serverless, consulta la panoramica sui gruppi di endpoint di rete serverless.

Associazioni dei servizi

Un binding del servizio è 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ù binding di servizio. Un servizio di backend con un binding del servizio 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 sui backend compatibili con i servizi di backend, consulta la tabella nella sezione precedente.
• Con alcuni bilanciatori del carico proxy, puoi utilizzare una combinazione di NEG di zona (con endpoint GCE_VM_IP_PORT) e NEG di connettività ibrida (con endpoint NON_GCP_PRIVATE_IP_PORT) per configurare il bilanciamento del carico ibrido. Per vedere quali bilanciatori del carico hanno 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 fallback.

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

Tabella: protocollo per i backend

Prodotto	Opzioni di 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.

Policy di selezione degli indirizzi IP

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

Quando selezioni il criterio di selezione dell'indirizzo IP, assicurati che i backend supportino il tipo di traffico selezionato. Per maggiori informazioni, vedi Tabella: servizi di backend e tipi di backend supportati.

La norma di selezione dell'indirizzo IP viene utilizzata quando vuoi convertire il servizio di backend del bilanciatore del carico per supportare un tipo di traffico diverso. Per saperne di più, consulta Eseguire la conversione da single-stack a dual-stack.

Puoi specificare i seguenti valori per la policy di selezione degli indirizzi IP:

Policy di selezione degli indirizzi IP	Descrizione
Solo IPv4	Invia solo traffico IPv4 ai backend del servizio di backend, indipendentemente dal traffico dal client al GFE. Per controllare l'integrità dei backend vengono utilizzati solo i controlli di integrità IPv4.
Preferisci IPv6	Dai la priorità alla connessione IPv6 del backend rispetto alla connessione IPv4 (a condizione che esista un backend integro con indirizzi IPv6). I controlli di integrità monitorano periodicamente le connessioni IPv6 e IPv4 dei backend. Il GFE tenta prima la connessione IPv6; se la connessione IPv6 è interrotta o lenta, il GFE utilizza happy eyeballs per eseguire il failover e connettersi a IPv4. Anche se una delle connessioni IPv6 o IPv4 non è integra, il backend viene comunque considerato integro ed entrambe le connessioni possono essere provate dal GFE, con happy eyeballs che alla fine seleziona quella da utilizzare.
Solo IPv6	Invia solo traffico IPv6 ai backend del servizio di backend, indipendentemente dal traffico dal client al proxy. Per verificare l'integrità dei backend vengono utilizzati solo i controlli di integrità IPv6. Non è presente 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 comporta backend non integri perché il traffico non riesce a raggiungere questi backend 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, vedi Crittografia verso 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 il modo in cui il bilanciatore del carico misura la disponibilità del backend per nuove richieste o connessioni.
• Una capacità target definisce un numero massimo target di connessioni, un tasso massimo target o un utilizzo massimo target della CPU.
• Un gestore della scalabilità della capacità regola la capacità disponibile complessiva senza modificare la capacità target.

Modalità di bilanciamento

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

Google Cloud ha quattro modalità di bilanciamento:

• CONNECTION: determina come viene distribuito il carico in base al numero totale di connessioni che il backend può gestire.
• RATE: il numero massimo target di richieste (query) al secondo (RPS, QPS). Il RPS/QPS massimo target può essere superato se tutti i backend sono al di sopra della capacità.
• UTILIZATION: determina la modalità di distribuzione del carico in base all'utilizzo delle istanze in un gruppo di istanze.
• CUSTOM_METRICS: determina come viene distribuito il carico in base alle metriche personalizzate definite dall'utente.

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, UTILIZATION o CUSTOM_METRICS per i backend dei gruppi di istanze e le modalità di bilanciamento RATE o CUSTOM_METRICS per i NEG di zona (endpoint GCE_VM_IP_PORT) e 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, viene selezionata una regione in base alla posizione del client e alla disponibilità di capacità della 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 di quante richieste devono essere inviate a ciascun backend nella regione. Le richieste o le connessioni vengono quindi distribuite in modo round robin tra le istanze o gli endpoint all'interno del backend.

• Per i bilanciatori del carico delle applicazioni esterni globali, viene selezionata una regione in base alla posizione del client e alla disponibilità di capacità della 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 di quante richieste devono essere inviate 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 backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, la policy 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 di quante richieste devono essere inviate a ogni backend (gruppo di istanze o NEG) nella regione. All'interno di ogni gruppo di istanze o NEG, la policy 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 della policy di bilanciamento del carico del servizio (serviceLbPolicy) e delle impostazioni del backend preferito per influenzare la selezione di 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 di gruppi di istanze VM, la modalità di bilanciamento CONNECTION per i NEG di zona con endpoint GCE_VM_IP_PORT e la modalità di bilanciamento CONNECTION 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 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 di quante richieste devono essere inviate 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 backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, la policy 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 interni 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 di quante richieste devono essere inviate a ogni 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 backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, la policy 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, viene selezionata una regione in base alla posizione del client e alla disponibilità di capacità della regione in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità target della modalità di bilanciamento del carico viene utilizzata per calcolare le proporzioni di richieste o connessioni da inviare a ogni 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 di quante richieste devono essere inviate 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 seguente 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, UTILIZATION o CUSTOM_METRICS
	NEG a livello di zona (GCE_VM_IP_PORT endpoint)	RATE o CUSTOM_METRICS
	NEG ibridi (NON_GCP_PRIVATE_IP_PORT endpoint)	RATE o CUSTOM_METRICS
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 (GCE_VM_IP_PORT endpoint)	CONNECTION
	NEG ibridi (NON_GCP_PRIVATE_IP_PORT endpoint)	CONNECTION
Bilanciatore del carico di rete passthrough	Gruppi di istanze	CONNECTION
	NEG a livello di zona (GCE_VM_IP endpoint)	CONNECTION

Nota:

Se noti una scarsa distribuzione del traffico quando utilizzi la modalità di bilanciamento UTILIZATION, ti consigliamo di utilizzare RATE.

La modalità di bilanciamento UTILIZATION dipende dall'utilizzo della CPU o dell'istanza VM, oltre che da altri fattori. Quando questi fattori fluttuano, 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 per le 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. Ciò 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 zonale si risolve automaticamente man mano che viene inviato più traffico al bilanciatore del carico.

Per saperne di più, vedi gcloud compute backend-services add-backend.

Capacità target

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

• Numero di connessioni
• Tariffa
• Utilizzo CPU

Per ogni modalità di bilanciamento, la capacità target non è un interruttore di protezione. Un bilanciatore del carico può superare il valore massimo in determinate condizioni, ad esempio se tutte le VM o tutti gli endpoint 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 target di connessioni aperte. 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 di destinazione:

• max-connections-per-instance (per VM): il numero medio target di connessioni per una singola VM.
• max-connections-per-endpoint (per endpoint in un NEG di zona): numero medio target di connessioni per un singolo endpoint.
• max-connections (per i NEG a livello di zona e per i gruppi di istanze a livello di zona): Numero medio di connessioni di destinazione per l'intero NEG o 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 di 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 del carico CONNECTION

Tipo di backend	Capacità target
	Se specifichi	Capacità totale del backend	Capacità prevista per istanza o per endpoint
Gruppo di istanze N istanze, H integre	max-connections-per-instance=X	X × N	(X × N)/H
NEG a livello di zona N endpoint, H 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 integre	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 di destinazione per l'intero gruppo di istanze VM o l'intero NEG di zona:

• 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 N endpoint, l'impostazione max-connections-per-endpoint=X ha lo stesso significato dell'impostazione max-connections=X × N.

Modalità di bilanciamento della velocità

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 target di richieste HTTP per una singola VM.
• max-rate-per-endpoint (per endpoint in un NEG zonale): fornisci una velocità media di richieste HTTP di destinazione per un singolo endpoint.
• max-rate (per i NEG a livello di zona e per i gruppi di istanze a livello di zona): fornisci una frequenza media target delle richieste HTTP per l'intero NEG o gruppo di istanze. Per i gruppi di istanze gestite a livello di regione, utilizza invece max-rate-per-instance.

La tabella seguente mostra come il parametro di 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à totale del backend	Capacità prevista per istanza o per endpoint
Gruppo di istanze N istanze, H integre	max-rate-per-instance=X	X × N	(X × N)/H
NEG a livello di zona N endpoint, H 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 integre	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 velocità massima target di richieste HTTP per l'intero gruppo di istanze o 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 N endpoint, 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 diverse opzioni a seconda del tipo di backend, come riepilogato 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 particolare VM del gruppo.

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

Modalità di bilanciamento delle metriche personalizzate

La modalità di bilanciamento CUSTOM_METRICS ti consente di definire metriche personalizzate che possono essere utilizzate per determinare come viene distribuito il carico. Le metriche personalizzate ti consentono di configurare il comportamento di distribuzione del traffico del bilanciatore del carico in modo che si basi su metriche specifiche per i requisiti dell'applicazione o dell'infrastruttura, anziché sulle metriche standard di utilizzo o basate sulla frequenza diGoogle Cloud.

Per ulteriori informazioni, vedi Metriche personalizzate per i bilanciatori del carico delle applicazioni.

Modifica della modalità di bilanciamento di un bilanciatore del carico

Per alcuni bilanciatori del carico o configurazioni del bilanciatore 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 di capacità target, la capacità target non è un interruttore automatico. Quando viene raggiunto il valore massimo della capacità target configurata in una determinata zona, le nuove richieste o connessioni vengono distribuite ad altre zone che non elaborano richieste o connessioni alla capacità target. Se tutte le zone hanno raggiunto la capacità target, le nuove richieste o connessioni vengono distribuite tramite il riempimento eccessivo.

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 gestito a livello di zona gestito a livello di zona gestito a livello di regione	RATE	Devi specificare una delle seguenti opzioni: max-rate  (supportato solo dai gruppi di istanze a livello di zona) max-rate-per-instance  (supportato da tutti i gruppi di istanze)
	UTILIZATION	Facoltativamente, puoi specificare uno dei seguenti elementi: (1) max-utilization (2) max-rate  (supportato solo dai gruppi di istanze a livello di zona) (3) max-rate-per-instance  (supportato da tutti i gruppi di istanze) (1) e (2) insieme (1) e (3) insieme
	CUSTOM_METRICS	Facoltativamente, puoi specificare uno dei seguenti elementi: (1) Il max-utilization della metrica (ovvero il campo backends[].customMetrics[].maxUtilization della metrica) (2) max-rate  (supportato solo dai gruppi di istanze a livello di zona) (3) max-rate-per-instance  (supportato da tutti i gruppi di istanze) (1) e (2) insieme (1) e (3) insieme Per backend max-utilization non è supportato.
NEG a livello di zona GCP_VM_IP_PORT NEG 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
	CUSTOM_METRICS	Facoltativamente, puoi specificare uno dei seguenti elementi: (1) Il max-utilization della metrica (ovvero il campo backends[].customMetrics[].maxUtilization della metrica) (2) max-rate per NEG a livello di zona (3) max-rate-per-endpoint (1) e (2) insieme (1) e (3) insieme Per backend max-utilization non è supportato.

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 gestito a livello di zona gestito a livello di zona gestito a livello di regione	CONNECTION	Devi specificare una delle seguenti opzioni: max-connections  (supportato solo dai gruppi di istanze a livello di zona) max-rate-per-instance  (supportato da tutti i gruppi di istanze)
	UTILIZATION	Facoltativamente, puoi specificare uno dei seguenti elementi: (1) max-utilization (2) max-connections  (supportato solo dai gruppi di istanze a livello di zona) (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 NEG 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 gestito a livello di zona gestito a livello di zona gestito a livello di regione	CONNECTION	Non puoi specificare un numero massimo di connessioni di destinazione.
NEG a livello di zona GCP_VM_IP	CONNECTION	Non puoi specificare un numero massimo di connessioni di destinazione.

Scalatore di capacità

Utilizza lo strumento di scalabilità della capacità per scalare la capacità target (utilizzo massimo, velocità massima o connessioni massime) senza modificarla.

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

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

Puoi regolare il gestore della scalabilità della capacità per scalare la capacità target effettiva senza modificare esplicitamente uno dei parametri --max-*.

Puoi impostare lo scalatore della capacità su uno di questi valori:

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

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

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

• Se la modalità di bilanciamento è RATE, max-rate è impostato su 80 RPS e lo scalatore di 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 il fattore di scalabilità della capacità è 0.0, la capacità disponibile è zero (0).

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

Policy di bilanciamento del carico del servizio

Una policy di bilanciamento del carico del servizio (serviceLbPolicy) è una risorsa associata al servizio di backend del bilanciatore del carico. Consente di personalizzare i parametri che influenzano il modo in cui il traffico viene distribuito all'interno dei backend associati a un servizio di backend:

• Personalizza l'algoritmo di bilanciamento del carico utilizzato per determinare come viene distribuito il traffico tra regioni o zone.
• Abilita lo svuotamento automatico della capacità in modo che il bilanciatore del carico possa svuotare rapidamente il traffico dai backend non integri.

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

Per saperne di più, consulta Ottimizzazioni avanzate del bilanciamento del carico con una policy di bilanciamento del carico del servizio.

Policy 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 località di bilanciamento del carico. La modalità di bilanciamento determina la frazione di traffico da inviare a ciascun backend (gruppo di istanze o NEG). La policy di località di 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 a livello di regione, la norma di località si applica a ogni zona costituente.

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

• ROUND_ROBIN (impostazione predefinita): questa è l'impostazione predefinita del criterio di località di bilanciamento del carico in cui il bilanciatore del carico seleziona un backend integro in ordine round robin.

• WEIGHTED_ROUND_ROBIN: il bilanciatore del carico utilizza le metriche personalizzate definite dall'utente per selezionare l'istanza o l'endpoint ottimale all'interno del backend per gestire la richiesta.

• 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 per i backend. L'algoritmo ha la proprietà per la quale l'aggiunta o la rimozione di un host da un set 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 client in entrata, prima che la richiesta venga reindirizzata al bilanciatore del carico.

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

• MAGLEV: implementa l'hashing coerente ai backend e può essere utilizzato in sostituzione della policy RING_HASH. Maglev non è stabile come RING_HASH, ma i tempi di creazione della ricerca nelle tabelle e di selezione dell'host sono 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 del controllo di integrità devono contenere il campo dell'intestazione della 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 alle ponderazioni per istanza riportate nelle ultime risposte al controllo di integrità elaborate, a condizione che ogni istanza riporti una ponderazione valida o UNAVAILABLE_WEIGHT. In caso contrario, il bilanciamento del carico rimarrà con pesi uguali.

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

La configurazione di una policy di località di bilanciamento del carico è supportata solo sui 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 della policy di bilanciamento del carico per le località (localityLbPolicy) cambia in base alle impostazioniaffinità sessionee. Se l'affinità sessione non è configurata, ovvero se l'affinità di sessione rimane al valore predefinito di 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 una policy di località di bilanciamento del carico, puoi utilizzare la consoleGoogle Cloud , gcloud (--locality-lb-policy) o l'API (localityLbPolicy).

Cloud Service Mesh e distribuzione del traffico

Cloud Service Mesh utilizza anche le risorse del 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 una policy di bilanciamento del carico. Il servizio di backend indirizza il traffico a un backend in base alla modalità di bilanciamento del backend. Poi Cloud Service Mesh distribuisce 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 del carico:

• 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 del backend

Il sottoinsieme di backend è una funzionalità facoltativa che migliora le prestazioni e la scalabilità assegnando un sottoinsieme di backend a ciascuna delle istanze proxy.

Il sottoinsieme del backend è supportato per quanto segue:

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

Impostazione secondaria del backend per i bilanciatori del carico delle applicazioni interni regionali

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. 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 il sottoinsieme di backend.

Per i bilanciatori del carico delle applicazioni interni regionali, il sottoinsieme di backend assegna automaticamente solo un sottoinsieme dei 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 i backend sono entrambi elevati, l'apertura di connessioni a tutti i backend può causare problemi di prestazioni.

Se attivi il sottoinsieme, ogni proxy apre connessioni solo a un sottoinsieme dei backend, riducendo il numero di connessioni mantenute aperte a ogni backend. La riduzione del numero di connessioni aperte contemporaneamente a ogni backend può migliorare le prestazioni sia dei backend sia 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. Se il sottoinsieme di backend è abilitato, il traffico di ogni proxy viene distribuito a un sottoinsieme dei backend. Il traffico dal proxy 1 viene distribuito ai backend 1 e 2, mentre il traffico dal proxy 2 viene distribuito ai backend 3 e 4.

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

Puoi perfezionare ulteriormente il traffico di bilanciamento del carico verso i backend impostando il criterio localityLbPolicy. Per saperne di più, consulta le norme sul traffico.

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

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

• Sebbene il sottoinsieme di backend sia progettato per garantire che tutte le istanze di backend rimangano ben utilizzate, può introdurre un certo bias nella quantità di traffico che ogni 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 del sottoinsieme interrompe le connessioni esistenti.
• Il sottoinsieme del backend richiede che l'affinità sessione sia NONE (un hash a 5 tuple). Altre opzioni di affinità sessione possono essere utilizzate solo se il sottoinsieme di backend è disabilitato. I valori predefiniti dei flag --subsetting-policy e --session-affinity sono entrambi NONE e solo uno di questi alla volta può essere impostato su un valore diverso.

Impostazione secondaria del backend per il bilanciatore del carico di rete passthrough interno

Il sottoinsieme di backend per i bilanciatori del carico di rete passthrough interni 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 il sottoinsieme influisce 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 il servizio di backend alla distribuzione a un massimo di 250 istanze o endpoint di backend. Se il tuo servizio di backend deve supportare più di 250 backend, puoi attivare la creazione di sottoinsiemi. Quando il sottoinsieme è abilitato, per ogni connessione client viene selezionato un sottoinsieme di istanze di backend.

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

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

Senza il sottoinsieme, l'insieme completo di backend integri viene utilizzato meglio e le nuove connessioni 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, vedi Sottoinsieme.

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

• Quando il subset è abilitato, non tutti i backend riceveranno traffico da un determinato mittente anche quando il numero di backend è ridotto.
• Per il numero massimo di istanze di backend quando è abilitata la creazione di sottoinsiemi, consulta la pagina delle quote .
• È supportata solo l'affinità sessione a 5 tuple con il sottoinsieme.
• Mirroring pacchetto non è supportato con la selezione di sottoinsiemi.
• L'attivazione o la disattivazione del sottoinsieme interrompe le connessioni esistenti.
• Se i client on-premise devono accedere a un bilanciatore del carico di rete passthrough interno, il subset può 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 di 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. In regioni diverse vengono utilizzati sottoinsiemi diversi.

Prezzi del sottoinsieme di backend

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

Affinità sessione

L'affinità di sessione ti consente di controllare in modo prevedibile la modalità di selezione dei backend da parte del bilanciatore del carico per le nuove connessioni, a condizione che il numero di backend integri rimanga costante. Ciò è utile per le applicazioni che richiedono che più richieste di un determinato utente vengano indirizzate allo stesso backend o endpoint. Queste applicazioni in genere includono server stateful utilizzati per la pubblicazione di annunci, giochi o servizi con memorizzazione nella cache interna pesante.

Google Cloud I bilanciatori del carico forniscono l'affinità sessione al meglio delle possibilità. 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'attivazione o la disattivazione del bilanciamento ponderato) o le modifiche alla pienezza del backend, misurate in base alla modalità di bilanciamento, possono interrompere l'affinità sessione.

Il bilanciamento del carico con affinità sessione funziona bene quando la distribuzione delle connessioni uniche è ragionevolmente ampia. Un numero ragionevolmente elevato significa 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 client tra i backend.

Per impostazione predefinita, tutti i bilanciatori del carico Google Cloud selezionano i backend utilizzando un hash 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 saperne di più sull'affinità sessione per i bilanciatori del carico di rete passthrough, consulta i seguenti documenti:

• Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni
• Distribuzione del traffico per i bilanciatori del carico di rete passthrough interni

Per saperne di più sull'affinità sessione per i bilanciatori del carico delle applicazioni, consulta i seguenti documenti:

• Affinità sessione per i bilanciatori del carico delle applicazioni esterni
• Affinità sessione per i bilanciatori del carico delle applicazioni interni

Per saperne di più sull'affinità sessione per i bilanciatori del carico di rete proxy, consulta i seguenti documenti:

• Affinità sessione per i bilanciatori del carico di rete proxy esterni
• Affinità sessione per i bilanciatori del carico di rete proxy interni

Timeout del servizio di backend

La maggior parte dei Google Cloud bilanciatori del carico ha un timeout del servizio di backend. Il valore predefinito è 30 secondi. L'intervallo completo di valori di timeout consentiti è 1 - 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 i bilanciatori del carico delle applicazioni esterni a livello di regione, consulta Timeout e tentativi.
  • Per i bilanciatori del carico delle applicazioni interni, consulta Timeout e tentativi.

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

• Per i bilanciatori del carico di rete passthrough interni ed 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 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 la quantità di tempo da attendere prima che un backend restituisca una risposta completa dopo l'invio della richiesta. Il timeout di gRPC specifica la quantità di tempo da attendere dall'inizio dello stream fino al completamento dell'elaborazione della risposta, inclusi tutti i tentativi.

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, quando crei il bilanciatore del carico oppure puoi fare riferimento a un controllo di integrità esistente.

Quando crei un servizio di backend utilizzando backend di gruppi di istanze o NEG di zona utilizzando Google Cloud CLI o l'API, 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 saperne di più, leggi i seguenti documenti:

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

Funzionalità aggiuntive abilitate sulla 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 porte e indirizzi IP frontend che ricevono le richieste e backend che rispondono alle richieste.

Per maggiori dettagli, consulta la documentazione di Cloud CDN.

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

Cloud Armor

Se utilizzi uno dei seguenti bilanciatori del carico, puoi aggiungere ulteriore protezione alle tue applicazioni attivando Cloud Armor sul 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 Cloud Armor esistente.
• Accetta la configurazione di un criterio di sicurezza di limitazione della frequenza di Cloud Armor predefinito con parametri di limitazione della frequenza, chiave, intervallo, conteggio delle richieste e nome personalizzabili. Se utilizzi 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 Cloud Armor selezionando Nessuno.

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 alcuni bilanciatori del carico delle applicazioni.

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

Funzionalità di gestione avanzata del traffico

Per scoprire di più sulle funzionalità di gestione avanzata del traffico configurate nei servizi di backend e nelle 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 i 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 del servizio di backend globale

• Risorsa API del servizio di backend regionale

• gcloud compute backend-services per i servizi di backend globali e regionali

Passaggi successivi

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

• Creare intestazioni personalizzate
• Crea un bilanciatore del carico delle applicazioni esterno
• Panoramica del bilanciatore del carico delle applicazioni esterno
• Abilita svuotamento delle connessioni
• 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