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 senza proxy 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 globali e regionali 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 tabella seguente riepiloga 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 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 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 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 di 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 di zona: uno o più NEG 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 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 ^† Un singolo NEG serverless (solo per Cloud Run o Cloud Run Functions 2ª generazione.) 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 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 ^† Un singolo NEG serverless (solo per Cloud Run o Cloud Run Functions 2ª generazione.) NEG Private Service Connect: API di Google: un singolo NEG Private Service Connect Servizi gestiti: uno o più NEG di 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 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 ^† Un singolo NEG serverless (solo per Cloud Run o Cloud Run Functions 2ª generazione.) 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 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 ^† NEG Private Service Connect: API di Google: un singolo NEG Private Service Connect Servizi gestiti: uno o più NEG di 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 di zona: uno o più NEG 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 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 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 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 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 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 NEG Private Service Connect: API di Google: un singolo NEG Private Service Connect Servizi gestiti: uno o più NEG di 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 di zona: uno o più NEG 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 di zona: uno o più NEG 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 Una o più associazioni dei servizi	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 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 forwarding 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 ciascuna 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 gcloud CLI 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, da un proxy Envoy configurato con Cloud Service Mesho da 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 può essere 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 modalità di bilanciamento compatibili. Per ulteriori informazioni, consulta la sezione Restrizioni e indicazioni per i gruppi di istanze di questo documento.
• 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 vi fanno riferimento.

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 da 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 dei gruppi di istanze, i pacchetti vengono sempre inviati all'interfaccia nic0 della VM.
  • Per gli endpoint GCE_VM_IP in un NEG zonale, 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 al backend di ogni 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 prevedono 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 pass-through 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 delle porte denominate
• Gruppi di istanze gestite: assegnazione di porte denominate a gruppi di istanze gestite

Limitazioni e indicazioni per i gruppi di istanze

Quando utilizzi i backend di gruppo di istanze, tieni presente quanto segue:

• Un'istanza VM può appartenere a un solo gruppo di istanze con bilanciamento del carico. Ad esempio, una VM può far parte di due gruppi di istanze non gestite oppure di un gruppo di istanze gestite e di un gruppo di istanze non gestite. Quando una VM è membro di due o più gruppi di istanze, solo uno dei gruppi di istanze può essere referenziato da uno o più servizi di backend del bilanciatore del carico.

• Lo stesso gruppo di istanze può essere utilizzato da due o più servizi di backend. Ogni mapping tra un gruppo di istanze e un servizio di backend può utilizzare una modalità di bilanciamento diversa, ad eccezione delle combinazioni di modalità di bilanciamento incompatibili.

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

    • La modalità di bilanciamento UTILIZATION non è compatibile con tutte le altre modalità di bilanciamento. Se un gruppo di istanze è un backend di più servizi di backend, deve utilizzare la modalità di bilanciamento UTILIZATION su ogni servizio di backend.

    • La modalità di bilanciamento CUSTOM_METRICS non è compatibile con tutte le altre modalità di bilanciamento. Se un gruppo di istanze è un backend di più servizi di backend, deve utilizzare la modalità di bilanciamento CUSTOM_METRICS su ogni servizio di backend.

  • A causa delle combinazioni di modalità di bilanciamento incompatibili, se un gruppo di istanze utilizza la modalità di bilanciamento UTILIZATION o CUSTOM_METRICS come backend per almeno un servizio di backend, lo stesso gruppo di istanze non può essere utilizzato come backend per un bilanciatore del carico di rete pass-through perché i bilanciatori del carico di rete pass-through richiedono la modalità di bilanciamento CONNECTION.

• Non esiste un singolo comando che possa modificare la modalità di bilanciamento dello stesso gruppo di istanze su più servizi di backend. Per modificare la modalità di bilanciamento del carico per un gruppo di istanze che è il backend di due o più servizi di backend, puoi utilizzare questa tecnica:

  • Rimuovi il gruppo di istanze come backend da tutti i servizi di backend, tranne uno.
  • Modifica la modalità di bilanciamento del gruppo di istanze per l'unico servizio di backend rimanente.
  • Aggiungi di nuovo il gruppo di istanze come backend agli altri servizi di backend.

Prendi in esame le seguenti best practice, che offrono opzioni più flessibili:

• Evita di utilizzare lo stesso gruppo di istanze come backend per due o più servizi di backend. Utilizza invece più NEG.

  • A differenza dei gruppi di istanze, una VM può avere un endpoint in due o più NEG con bilanciamento del carico.

  • Ad esempio, se una VM deve essere contemporaneamente un backend di un bilanciatore del carico di rete passthrough e di un bilanciatore del carico di rete proxy o di un bilanciatore del carico delle applicazioni, utilizza più NEG con bilanciamento del carico. Inserisci un endpoint VM in un NEG univoco compatibile con ogni tipo di bilanciatore del carico. Poi associa ogni NEG al servizio di backend del bilanciatore del carico corrispondente.

• Non aggiungere un gruppo di istanze gestite con scalabilità automatica a più di un servizio di backend quando utilizzi la metrica di scalabilità automatica Utilizzo del bilanciamento del carico HTTP. Due o più servizi di backend che fanno riferimento allo stesso gruppo di istanze gestite con scalabilità automatica possono contraddirsi a vicenda, a meno che la metrica di scalabilità automatica non sia correlata all'attività del bilanciatore del carico.

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 NEG di zona sono risorse zonali che rappresentano raccolte di indirizzi IP o combinazioni di indirizzi IP e porte per risorseGoogle 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.

Sono disponibili due tipi di endpoint di rete per i NEG zonali:

• 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 servizio di backend).
• GCE_VM_IP_PORT endpoint.

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

Per maggiori dettagli, vedi la 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 all'interno di un'infrastruttura on-premise o su un'infrastruttura fornita da terze parti.

Un NEG internet è una 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 Cloud Run Functions2ª 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, devono 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 indirizzare 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 dei gruppi di endpoint di rete serverless.

Associazioni dei servizi

Un'associazione dei 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 diversi service binding. Un servizio di backend con un'associazione dei 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 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 scoprire 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 fallback.

I protocolli validi dipendono dal tipo di bilanciatore del carico o dal fatto che tu stia utilizzando 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 la policy di selezione dell'indirizzo IP per specificare il tipo di traffico inviato dal servizio di backend ai tuoi backend.

Quando selezioni il criterio di selezione dell'indirizzo IP, assicurati che i backend supportino il tipo di traffico selezionato. Per saperne di più, 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 ulteriori informazioni, 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 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. GFE tenta prima la connessione IPv6; se la connessione IPv6 è interrotta o lenta, 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 da 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 controllare l'integrità dei backend vengono utilizzati solo i controlli di integrità IPv6. Non è prevista 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 ai client viene restituito il codice di risposta HTTP 503.

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.

Modalità di bilanciamento, capacità target e gestore della scalabilità della capacità

Per i bilanciatori del carico delle applicazioni, Cloud Service Mesh e i bilanciatori del carico di rete proxy, la modalità di bilanciamento, la capacità di destinazione e lo scalatore di capacità sono parametri che fornisci quando aggiungi un backend supportato a un servizio di backend. I bilanciatori del carico utilizzano questi parametri per gestire la distribuzione di nuove richieste o nuove connessioni alle zone che contengono backend supportati:

• La modalità di bilanciamento definisce il modo in cui il bilanciatore del carico misura la capacità. Google Cloud ha le seguenti modalità di bilanciamento:
  • CONNECTION: definisce la capacità in base al numero di nuove connessioni TCP.
  • RATE: definisce la capacità in base alla frequenza delle nuove richieste HTTP.
  • IN-FLIGHT (Anteprima): definisce la capacità in base al numero di richieste HTTP in corso anziché alla frequenza delle richieste HTTP. Utilizza questa modalità di bilanciamento invece di RATE se le richieste richiedono più di un secondo per essere completate.
  • UTILIZATION: definisce la capacità in base all'utilizzo approssimativo della CPU delle VM in una zona di un gruppo di istanze.
  • CUSTOM_METRICS: definisce la capacità in base alle metriche personalizzate definite dall'utente.
• La capacità target definisce il numero della capacità target.
  • La capacità target non è un interruttore di sicurezza.
  • Quando l'utilizzo della capacità raggiunge la capacità target, il bilanciatore del carico indirizza nuove richieste o nuove connessioni a una zona diversa se i backend sono configurati in due o più zone.
  • I bilanciatori del carico delle applicazioni esterni globali, i bilanciatori del carico di rete proxy esterni globali, i bilanciatori del carico delle applicazioni interni tra regioni e i bilanciatori del carico di rete proxy interni tra regioni utilizzano anche la capacità per indirizzare le richieste alle zone in regioni diverse, se hai configurato i backend in più di una regione.
  • Quando tutte le zone hanno raggiunto la capacità target, le nuove richieste o le nuove connessioni vengono distribuite in modo proporzionale.
• Il gestore della scalabilità della capacità consente di scalare manualmente la capacità target. I valori per lo scalatore di capacità sono i seguenti:
  • 0: indica che il backend è completamente scarico. Non puoi utilizzare un valore di 0 se un servizio di backend ha un solo backend.
  • 0.1 (10%) - 1.0 (100%): indica la percentuale di capacità di backend in uso.

I bilanciatori del carico di rete passthrough utilizzano simbolicamente la modalità di bilanciamento CONNECTION, ma non supportano una capacità target o uno strumento di scalabilità della capacità. Per saperne di più su come i bilanciatori del carico di rete passthrough distribuiscono le nuove connessioni, consulta quanto segue:

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

Backend supportati

Per i bilanciatori del carico delle applicazioni, Cloud Service Mesh e i bilanciatori del carico di rete proxy, i seguenti tipi di backend supportano i parametri modalità di bilanciamento, capacità target e scalatore di capacità:

• Backend di gruppi di istanze
• NEG a livello di zona con endpoint GCE_VM_IP_PORT
• NEG connettività ibrida zonale

I NEG di internet, i NEG serverless e i NEG di Private Service Connect non supportano i parametri modalità di bilanciamento, capacità target e scalabilità della capacità.

Modalità di bilanciamento per i bilanciatori del carico delle applicazioni e Cloud Service Mesh

Le modalità di bilanciamento disponibili per i backend del bilanciatore del carico delle applicazioni e di Cloud Service Mesh dipendono dal tipo di backend supportato e da un'impostazione della durata del traffico (anteprima).

Impostazione della durata del traffico

Anteprima

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

Per i backend del bilanciatore del carico delle applicazioni e di Cloud Service Mesh, puoi specificare facoltativamente un'impostazione della durata del traffico. Questa impostazione è univoca per il mapping tra un backend supportato e un servizio di backend. L'impostazione della durata del traffico ha due valori validi:

• SHORT: consigliato per le richieste HTTP a cui viene risposto con risposte dai backend in meno di un secondo. Se non specifichi esplicitamente una durata del traffico, il bilanciatore del carico funziona come se avessi specificato SHORT.
• LONG: consigliato per le richieste HTTP per le quali il backend impiega più di un secondo per generare risposte.

Per impostare esplicitamente la durata del traffico quando aggiungi un backend a un servizio di backend, esegui una delle seguenti operazioni:

• Esegui il comando gcloud compute backend-services add-backend con il flag --traffic-duration.
• Crea un servizio di backend o aggiornalo con l'attributo trafficDuration.

Modalità di bilanciamento per una breve durata del traffico

Se l'impostazione della durata del traffico non è specificata o è impostata su SHORT(anteprima), le modalità di bilanciamento disponibili per i backend del bilanciatore del carico delle applicazioni e di Cloud Service Mesh dipendono dal tipo di backend supportato.

Tabella: modalità di bilanciamento per i backend di bilanciamento del carico delle applicazioni e Cloud Service Mesh che utilizzano l'impostazione della durata breve del traffico

Backend supportato	Modalità di bilanciamento
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Gruppi di istanze
NEG a livello di zona con endpoint GCE_VM_IP_PORT
NEG di connettività ibrida a livello di zona

Modalità di bilanciamento per traffico di lunga durata

Anteprima

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

Quando l'impostazione della durata del traffico è LONG, le modalità di bilanciamento disponibili per i backend di bilanciamento del carico delle applicazioni e Cloud Service Mesh dipendono dal tipo di backend supportato.

Tabella: modalità di bilanciamento per i backend del bilanciatore del carico delle applicazioni e di Cloud Service Mesh che utilizzano l'impostazione della durata del traffico lunga

Backend supportato	Modalità di bilanciamento
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Gruppi di istanze
NEG a livello di zona con endpoint GCE_VM_IP_PORT
NEG di connettività ibrida a livello di zona

Modalità di bilanciamento per i bilanciatori del carico di rete proxy

Le modalità di bilanciamento disponibili per i backend del bilanciatore del carico di rete proxy dipendono dal tipo di backend supportato.

Tabella: modalità di bilanciamento per i bilanciatori del carico di rete proxy

Backend supportato	Modalità di bilanciamento
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Gruppi di istanze
NEG a livello di zona con endpoint GCE_VM_IP_PORT
NEG di connettività ibrida a livello di zona

Specifiche della capacità target

Le specifiche della capacità di destinazione sono pertinenti per i backend del bilanciatore del carico delle applicazioni, di Cloud Service Mesh e del bilanciatore del carico di rete proxy che supportano le impostazioni di modalità di bilanciamento, capacità di destinazione e fattore di scalabilità della capacità.

Le specifiche della capacità target non sono pertinenti per i bilanciatori del carico di rete passthrough.

Modalità di bilanciamento della connessione

I backend del bilanciatore del carico di rete proxy possono utilizzare la modalità di bilanciamento CONNECTION con uno dei seguenti parametri di capacità di destinazione obbligatori:

Parametri di capacità target per la modalità di bilanciamento CONNECTION

Parametro di capacità target	Backend supportato
	Gruppi di istanze (gestite o non gestite) a livello di zona	Gruppi di istanze gestite regionali	NEG a livello di zona con endpoint GCE_VM_IP_PORT	NEG di connettività ibrida a livello di zona
max-connections Connessioni TCP di destinazione per zona di backend
max-connections-per-instance Connessioni TCP di destinazione per istanza VM. Cloud Load Balancing utilizza questo parametro per calcolare le connessioni TCP di destinazione per zona di backend.
max-connections-per-endpoint Connessioni TCP di destinazione per endpoint NEG. Cloud Load Balancing utilizza questo parametro per calcolare le connessioni TCP di destinazione per zona di backend.

Utilizzo del parametro max-connections

Quando specifichi il parametro max-connections, il valore che fornisci definisce la capacità per un'intera zona.

• Per un gruppo di istanze di zona con N istanze totali e h istanze integre (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-connections su X, la capacità target di zona è X.
  • Il numero medio di connessioni per istanza è X / h.

• I gruppi di istanze gestite a livello di regione non supportano il parametro max-connections perché sono costituiti da più zone. Utilizza invece il parametro max-connections-per-instance.

• Per un NEG zonale con N endpoint totali e h endpoint integri (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-connections su X, la capacità target di zona è X.
  • La media delle connessioni per endpoint è X / h.

Utilizzo del parametro max-connections-per-instance o max-connections-per-endpoint

Quando specifichi il parametro max-connections-per-instance o max-connections-per-endpoint, il bilanciatore del carico utilizza il valore che fornisci per calcolare una capacità per zona:

• Per un gruppo di istanze di zona con N istanze totali e h istanze integre (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-connections-per-instance su X, la capacità target di zona è N * X. Equivale a impostare max-connections su N * X.
  • Il numero medio di connessioni per istanza è (N * X) / h.

• Per un gruppo di istanze gestite a livello di regione, se imposti max-connections-per-instance su X, Google Cloud calcola una capacità target per zona per ogni zona del gruppo di istanze. In ogni zona, se ci sono K istanze totali e h istanze integre (dove h≤ K), i calcoli sono i seguenti:

  • La capacità target della zona è K * X.
  • Le connessioni medie per istanza nella zona sono (K * X) / h.

• Per un NEG zonale con N endpoint totali e h endpoint integri (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-connections-per-endpoint su X, la capacità target di zona è N * X. Equivale a impostare max-connections su N * X.
  • La media delle connessioni per endpoint è (N * X) / h.

Modalità di bilanciamento della velocità

I backend di bilanciamento del carico delle applicazioni e Cloud Service Mesh con un'impostazione di durata del traffico non specificata o breve (anteprima) possono utilizzare la modalità di bilanciamento RATE con uno dei seguenti parametri di capacità di destinazione obbligatori:

Tabella: parametri di capacità target per la modalità di bilanciamento RATE

Parametro di capacità target	Backend supportato
	Gruppi di istanze (gestite o non gestite) a livello di zona	Gruppi di istanze gestite regionali	NEG a livello di zona con endpoint GCE_VM_IP_PORT	NEG di connettività ibrida a livello di zona
max-rate Tasso di richieste HTTP di destinazione per zona di backend
max-rate-per-instance tasso di richieste HTTP di destinazione per istanza VM. Cloud Load Balancing utilizza questo parametro per calcolare tasso di richieste HTTP target per zona di backend.
max-rate-per-endpoint Tasso di richieste HTTP di destinazione per endpoint NEG. Cloud Load Balancing utilizza questo parametro per calcolare tasso di richieste HTTP target per zona di backend.

Utilizzo del parametro max-rate

Quando specifichi il parametro max-rate, il valore che fornisci definisce la capacità per un'intera zona.

• Per un gruppo di istanze di zona con N istanze totali e h istanze integre (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-rate su X, la capacità target zonale è di X richieste al secondo.
  • La media di richieste al secondo per istanza è X / h.

• I gruppi di istanze gestite a livello di regione non supportano il parametro max-rate perché sono costituiti da più zone. Utilizza invece il parametro max-rate-per-instance.

• Per un NEG zonale con N endpoint totali e h endpoint integri (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-rate su X, la capacità target zonale è di X richieste al secondo.
  • La media di richieste al secondo per endpoint è X / h.

Utilizzo del parametro max-rate-per-instance o max-rate-per-endpoint

Quando specifichi il parametro max-rate-per-instance o max-rate-per-endpoint, il bilanciatore del carico utilizza il valore che fornisci per calcolare una capacità per zona:

• Per un gruppo di istanze di zona con N istanze totali e h istanze integre (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-rate-per-instance su X, la capacità target zonale è N * X richieste al secondo. Equivale a impostare max-rate su N * X.
  • La media di richieste al secondo per istanza è (N * X) / h.

• Per un gruppo di istanze gestite a livello di regione, se imposti max-rate-per-instance su X, Google Cloud calcola una capacità target per zona per ogni zona del gruppo di istanze. In ogni zona, se ci sono K istanze totali e h istanze integre (dove h≤ K), i calcoli sono i seguenti:

  • La capacità target della zona è di K * X richieste al secondo.
  • La media di richieste al secondo per istanza nella zona è (K * X) / h.

• Per un NEG di zona con N endpoint totali e h endpoint integri (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-rate-per-endpoint su X, la capacità target zonale è N * X richieste al secondo. Equivale a impostare max-rate su N * X.
  • La media di richieste al secondo per endpoint è (N * X) / h.

Modalità di bilanciamento in volo

Anteprima

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

I backend del bilanciatore del carico delle applicazioni e di Cloud Service Mesh con un'impostazione di durata del traffico lunga possono utilizzare la modalità di bilanciamento IN_FLIGHT con uno dei seguenti parametri di capacità di destinazione obbligatori:

Tabella: parametri di capacità target per la modalità di bilanciamento IN_FLIGHT

Parametro di capacità target	Backend supportato
	Gruppi di istanze (gestite o non gestite) a livello di zona	Gruppi di istanze gestite regionali	NEG a livello di zona con endpoint GCE_VM_IP_PORT	NEG di connettività ibrida a livello di zona
max-in-flight-requests Numero target di richieste HTTP in corso per zona di backend
max-in-flight-requests-per-instance Numero target di richieste HTTP in corso per istanza VM. Cloud Load Balancing utilizza questo parametro per calcolare il numero target di richieste HTTP in corso per zona di backend.
max-in-flight-requests-per-endpoint Numero target di richieste HTTP in corso per endpoint NEG. Il bilanciamento del carico utilizza questo parametro per calcolare il numero target di richieste HTTP in corso per zona di backend.

Utilizzo del parametro max-in-flight-requests

Quando specifichi il parametro max-in-flight-requests, il valore che fornisci definisce la capacità di un'intera zona.

• Per un gruppo di istanze di zona con N istanze totali e h istanze integre (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-in-flight-requests su X, la capacità di destinazione zonale è X richieste HTTP in corso.
  • Il numero medio di richieste HTTP in corso per istanza è X / h.

• I gruppi di istanze gestite a livello di regione non supportano il parametro max-in-flight-requests perché sono costituiti da più zone. Utilizza invece il parametro max-in-flight-requests-per-instance.

• Per un NEG di zona con N endpoint totali e h endpoint integri (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-in-flight-requests su X, la capacità di destinazione zonale è X richieste HTTP in corso.
  • Il numero medio di richieste HTTP in corso per endpoint è X / h.

Utilizzo dei parametri max-in-flight-requests-per-instance o max-in-flight-requests-per-endpoint

Quando specifichi il parametro max-in-flight-requests-per-instance o max-in-flight-requests-per-endpoint, il bilanciatore del carico utilizza il valore che fornisci per calcolare una capacità per zona:

• Per un gruppo di istanze di zona con N istanze totali e h istanze integre (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-in-flight-requests-per-instance su X, la capacità di destinazione zonale è N * X richieste HTTP in corso. Equivale a impostare max-in-flight-requests su N * X.
  • La media delle richieste HTTP in corso per istanza è (N * X) / h.

• Per un gruppo di istanze gestite a livello di regione, se imposti max-in-flight-requests-per-instance su X, Google Cloud calcola una capacità target per zona per ogni zona del gruppo di istanze. In ogni zona, se ci sono K istanze totali e h istanze integre (dove h≤ K), i calcoli sono i seguenti:

  • La capacità target della zona è di K * X richieste HTTP in corso.
  • La media delle richieste HTTP in corso per istanza nella zona è (K * X) / h.

• Per un NEG di zona con N endpoint totali e h endpoint integri (dove h ≤ N), i calcoli sono i seguenti:

  • Se imposti max-in-flight-requests-per-endpoint su X, la capacità di destinazione zonale è N * X richieste HTTP in corso. Equivale a impostare max-in-flight-requests su N * X.
  • La media delle richieste HTTP in corso per endpoint è (N * X) / h.

Modalità di bilanciamento dell'utilizzo

I backend del bilanciatore del carico delle applicazioni, di Cloud Service Mesh e del gruppo di istanze del bilanciatore del carico di rete proxy possono utilizzare la modalità di bilanciamento UTILIZATION. I backend NEG non supportano questa modalità di bilanciamento.

La modalità di bilanciamento UTILIZATION dipende dall'utilizzo della CPU della VM e da altri fattori. Quando questi fattori fluttuano, il bilanciatore del carico potrebbe calcolare l'utilizzo in modo tale che alcune VM ricevano più richieste o connessioni rispetto ad altre. Pertanto, tieni presente quanto segue:

• Utilizza solo la modalità di bilanciamento UTILIZATION con l'affinità sessione impostata su NONE. Se il tuo servizio di backend utilizza un'affinità sessione diversa da NONE, utilizza invece le modalità di bilanciamento RATE, IN-FLIGHT o CONNECTION.

• Se l'utilizzo medio delle VM in tutti i gruppi di istanze è inferiore al 10%, alcuni bilanciatori del carico preferiscono distribuire nuove richieste o connessioni a zone specifiche. Questa preferenza zonale diventa meno prevalente quando la frequenza delle richieste o il numero di connessioni aumenta.

La modalità di bilanciamento UTILIZATION non prevede un'impostazione obbligatoria della capacità target, ma puoi definire facoltativamente una capacità target utilizzando uno dei parametri o le combinazioni di parametri della capacità target descritti nelle sezioni seguenti.

Parametri di capacità target di utilizzo per i backend del bilanciatore del carico delle applicazioni e di Cloud Service Mesh con un'impostazione di durata del traffico non specificata o breve

I backend di Application Load Balancer e Cloud Service Mesh con un'impostazione della durata del traffico non specificata o breve (anteprima) possono utilizzare la modalità di bilanciamento UTILIZATION con uno dei seguenti parametri di capacità di destinazione o combinazioni di parametri:

Tabella: parametri e combinazioni di parametri della capacità target della modalità di bilanciamento UTILIZATION per i backend del bilanciatore del carico delle applicazioni e di Cloud Service Mesh con un'impostazione di durata del traffico breve o non specificata

Parametro o combinazione di parametri della capacità target	Backend supportato
	Gruppi di istanze (gestite o non gestite) a livello di zona	Gruppi di istanze gestite regionali	NEG a livello di zona con endpoint GCE_VM_IP_PORT	NEG di connettività ibrida a livello di zona
max-utilization Utilizzo target per zona di backend
max-rate Tasso di richieste HTTP di destinazione per zona di backend
max-rate e max-utilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo target della zona Tasso di richieste HTTP di destinazione della zona
max-rate-per-instance tasso di richieste HTTP di destinazione per istanza VM. Cloud Load Balancing utilizza questo parametro per calcolare tasso di richieste HTTP target per zona di backend.
max-rate-per-instance e max-utilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo target della zona Tasso di richieste HTTP target della zona (calcolato in base al tasso di richieste HTTP target per istanza VM delle VM nella zona)

Per saperne di più sui parametri di capacità target max-rate e max-rate-per-instance, consulta la sezione Modalità di bilanciamento della velocità di questo documento.

Parametri di capacità target di utilizzo per i backend del bilanciatore del carico delle applicazioni e di Cloud Service Mesh con un'impostazione di durata del traffico lunga

I backend del bilanciatore del carico delle applicazioni e di Cloud Service Mesh con un'impostazione di durata del traffico lunga (anteprima) possono utilizzare la modalità di bilanciamento UTILIZATION con uno dei seguenti parametri di capacità target o combinazioni di parametri:

Tabella: parametri e combinazioni di parametri della capacità target della modalità di bilanciamento UTILIZATION per i backend di Application Load Balancer e Cloud Service Mesh con un'impostazione di durata del traffico lunga (anteprima)

Parametro o combinazione di parametri della capacità target	Backend supportato
	Gruppi di istanze (gestite o non gestite) a livello di zona	Gruppi di istanze gestite regionali	NEG a livello di zona con endpoint GCE_VM_IP_PORT	NEG di connettività ibrida a livello di zona
max-utilization Utilizzo target per zona di backend
max-in-flight-requests Numero target di richieste HTTP in corso per zona di backend
max-in-flight-requests e max-utilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo target della zona Numero di richieste HTTP in corso di una zona di destinazione
max-in-flight-requests-per-instance Numero target di richieste HTTP in corso per istanza VM. Cloud Load Balancing utilizza questo parametro per calcolare il numero target di richieste HTTP in corso per zona di backend.
max-in-flight-requests-per-instance e max-utilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo target della zona Numero target di richieste HTTP in corso della zona (calcolato dal numero target di richieste HTTP in corso per istanza VM delle VM nella zona)

Per ulteriori informazioni sui parametri di capacità target max-in-flight-requests e max-in-flight-requests-per-instance, consulta la sezione Modalità di bilanciamento in volo di questo documento.

Parametri di capacità target di utilizzo per i bilanciatori del carico di rete proxy

I backend dei gruppi di istanze dei bilanciatori del carico di rete proxy possono utilizzare la modalità di bilanciamento UTILIZATION con uno dei seguenti parametri o combinazioni di parametri di capacità target.

Tabella: UTILIZATION parametri e combinazioni di parametri della capacità target della modalità di bilanciamento per i backend del bilanciatore del carico di rete proxy

Parametro o combinazione di parametri della capacità target	Backend supportato
	Gruppi di istanze (gestite o non gestite) a livello di zona	Gruppi di istanze gestite regionali	NEG a livello di zona con endpoint GCE_VM_IP_PORT	NEG di connettività ibrida a livello di zona
max-utilization Utilizzo target per zona di backend
max-connections Connessioni TCP di destinazione per zona di backend
max-connections e max-utilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo target della zona Connessioni TCP di destinazione della zona
max-connections-per-instance Connessioni TCP di destinazione per istanza VM. Cloud Load Balancing utilizza questo parametro per calcolare le connessioni TCP di destinazione per zona di backend.
max-connections-per-instance e max-utilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo target della zona Connessioni TCP di destinazione della zona (calcolate in base alle connessioni TCP di destinazione per istanza VM delle VM nella zona)

Per saperne di più sui parametri di capacità target max-connections e max-connections-per-instance, consulta la sezione Modalità di bilanciamento delle connessioni di questo documento.

Modalità di bilanciamento delle metriche personalizzate

I backend del bilanciatore del carico delle applicazioni e del bilanciatore del carico di rete proxy possono <x0A>utilizzare la modalità di bilanciamento CUSTOM_METRICS. Le metriche personalizzate ti consentono di definire la capacità target in base ai dati dell'applicazione o dell'infrastruttura più importanti per te. Per ulteriori informazioni, consulta Metriche personalizzate per i bilanciatori del carico delle applicazioni.

La modalità di bilanciamento CUSTOM_METRICS non prevede un'impostazione obbligatoria della capacità target, ma puoi definire facoltativamente una capacità target utilizzando uno dei parametri di capacità target o combinazioni di parametri di capacità target descritti nelle sezioni seguenti.

Parametri di capacità target delle metriche personalizzate per i backend del bilanciatore del carico delle applicazioni con un'impostazione di durata del traffico non specificata o breve

I backend del bilanciatore del carico delle applicazioni con un'impostazione della durata del traffico non specificata o breve (anteprima) possono utilizzare la modalità di bilanciamento CUSTOM_METRICS con uno dei seguenti parametri di capacità di destinazione o combinazioni di parametri:

Tabella: parametri di capacità di destinazione della modalità di bilanciamento CUSTOM_METRICS e combinazioni di parametri per i backend del bilanciatore del carico delle applicazioni con un'impostazione di durata del traffico breve o non specificata

Parametro o combinazione di parametri della capacità target	Backend supportato
	Gruppi di istanze (gestite o non gestite) a livello di zona	Gruppi di istanze gestite regionali	NEG a livello di zona con endpoint GCE_VM_IP_PORT	NEG di connettività ibrida a livello di zona
backends[].customMetrics[].maxUtilization Utilizzo della metrica personalizzata target per zona di backend
max-rate Tasso di richieste HTTP di destinazione per zona di backend
max-rate e backends[].customMetrics[].maxUtilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo della metrica personalizzata target della zona Tasso di richieste HTTP di destinazione della zona
max-rate-per-instance tasso di richieste HTTP di destinazione per istanza VM. Cloud Load Balancing utilizza questo parametro per calcolare tasso di richieste HTTP target per zona di backend.
max-rate-per-instance e backends[].customMetrics[].maxUtilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo della metrica personalizzata target della zona Tasso di richieste HTTP target della zona (calcolato in base al tasso di richieste HTTP target per istanza VM delle VM nella zona)
max-rate-per-endpoint Tasso di richieste HTTP di destinazione per endpoint NEG. Cloud Load Balancing utilizza questo parametro per calcolare tasso di richieste HTTP target per zona di backend.
max-rate-per-endpoint e backends[].customMetrics[].maxUtilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo della metrica personalizzata target della zona Tasso di richieste HTTP target della zona (calcolata in base alla tasso di richieste HTTP target per endpoint NEG degli endpoint nella zona)

Per ulteriori informazioni sui parametri di capacità target max-rate, max-rate-per-instance e max-rate-per-endpoint, consulta la sezione Modalità di bilanciamento della velocità di questo documento.

Parametri di capacità target delle metriche personalizzate per i backend del bilanciatore del carico delle applicazioni con un'impostazione di durata del traffico lunga

I backend del bilanciatore del carico delle applicazioni con un'impostazione di durata del traffico lunga possono utilizzare la modalità di bilanciamento CUSTOM_METRICS con uno dei seguenti parametri di capacità target o combinazioni di parametri:

Tabella: CUSTOM_METRICS parametri di capacità e combinazioni di parametri di bilanciamento del carico di bilanciamento del carico delle applicazioni con un'impostazione di durata del traffico lunga (anteprima)

Parametro o combinazione di parametri della capacità target	Backend supportato
	Gruppi di istanze (gestite o non gestite) a livello di zona	Gruppi di istanze gestite regionali	NEG a livello di zona con endpoint GCE_VM_IP_PORT	NEG di connettività ibrida a livello di zona
backends[].customMetrics[].maxUtilization Utilizzo della metrica personalizzata target per zona di backend
max-in-flight-requests Numero target di richieste HTTP in corso per zona di backend
max-in-flight-requests e backends[].customMetrics[].maxUtilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo della metrica personalizzata target della zona Numero di richieste HTTP in corso di una zona di destinazione
max-in-flight-requests-per-instance Numero target di richieste HTTP in corso per istanza VM. Cloud Load Balancing utilizza questo parametro per calcolare il numero target di richieste HTTP in corso per zona di backend.
max-in-flight-requests-per-instance e backends[].customMetrics[].maxUtilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo della metrica personalizzata target della zona Numero target di richieste HTTP in corso della zona (calcolato dal numero target di richieste HTTP in corso per istanza VM delle VM nella zona)
max-in-flight-requests-per-endpoint Numero target di richieste HTTP in corso per endpoint NEG. Il bilanciamento del carico utilizza questo parametro per calcolare il numero target di richieste HTTP in corso per zona di backend.
max-in-flight-requests-per-endpoint e backends[].customMetrics[].maxUtilization Il target è il primo a essere raggiunto nella zona di backend: Utilizzo della metrica personalizzata target della zona Numero target di richieste HTTP in corso della zona (calcolato dal numero target di richieste HTTP in corso per endpoint NEG degli endpoint nella zona)

Per ulteriori informazioni sui parametri di capacità target max-in-flight-requests, max-in-flight-requests-per-instance e max-flight-requests-per-endpoint, consulta la sezione Modalità di bilanciamento in volo.

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 del bilanciamento del carico avanzate.

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 ogni 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, il criterio 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à del 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 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 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 globali e regionali.

• MAGLEV: implementa l'hashing coerente per i backend e può essere utilizzato in sostituzione della policy RING_HASH. Maglev non è stabile come 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à non legacy basato su HTTP 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 ai pesi per istanza riportati nelle ultime risposte al controllo di integrità elaborate, a condizione che ogni istanza riporti un peso valido 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 Configurare 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 proxy esterno globale
• Bilanciatore del carico di rete proxy esterno regionale
• Bilanciatore del carico di rete proxy interno tra regioni
• Bilanciatore del carico di rete proxy interno regionale
• Bilanciatore del carico di rete passthrough esterno

Tieni presente che il valore predefinito effettivo della policy di località di bilanciamento del carico (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).

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 di 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 di servizio specifici. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni delle fasi 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 solo connessioni 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 che dei proxy.

Il seguente diagramma mostra un bilanciatore del carico con due proxy. Senza il sottoinsieme del backend, il traffico di entrambi i proxy viene distribuito a tutti i backend nel servizio di backend 1. Se il sottoinsieme di backend è attivato, 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 Configurare 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). Le 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 Servizi di backend in "Quote e limiti".

Per impostazione predefinita, il sottoinsieme è disattivato, 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 abilitare 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 il sottoinsieme (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 il sottoinsieme.
• 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 sottoinsieme 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. Questa funzionalità è 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.

I bilanciatori del caricoGoogle Cloud 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 dalla 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 fornirà 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 bilanciatori del carico ha un timeout del servizio di backend. Google Cloud 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 regionali , 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 e i bilanciatori del carico di rete proxy interni, il timeout del servizio di backend configurato è il periodo di tempo durante il quale il bilanciatore del carico mantiene aperta la connessione TCP in assenza di dati trasmessi dal client o dal backend. Trascorso questo periodo di tempo senza che vengano trasmessi dati, il proxy chiude la connessione.

  • Valore predefinito: 30 secondi
  • Intervallo configurabile: da 1 a 2.147.483.647 secondi

• 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 il tempo di attesa prima che un backend restituisca 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.

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 zonali 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 gcloudControllo di integrità
• 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 è abilitato 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 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 una policy di sicurezza di Cloud Armor esistente.
• Accetta la configurazione di una policy di sicurezza di limitazione della frequenza Cloud Armor predefinita con nome, conteggio delle richieste, intervallo, chiave e parametri di limitazione di frequenza 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 Nessuna.

IAP

IAP ti consente di definire un livello di autorizzazione centrale per le applicazioni accessibili tramite HTTPS, in modo da poter 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 informazioni sulle funzionalità avanzate di gestione 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 i 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

• Pagina gcloud compute backend-services per i servizi di backend sia 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
• 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