Panoramica dei servizi di backend

Un servizio di backend definisce la modalità di distribuzione del traffico da parte di Cloud Load Balancing. La configurazione del servizio di backend contiene un insieme di valori, ad esempio il protocollo utilizzato per la connessione ai backend, varie impostazioni di distribuzione e di 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 ha un ambito 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 fare quanto segue:

• Indirizza il traffico ai backend corretti, che sono gruppi di istanze o gruppi di endpoint di rete (NEG).
• Distribuisci il traffico secondo 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 abilitati 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
• Specifica i servizi di backend regionali come servizio in App Hub, che è in anteprima.

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

Nota: se utilizzi l'Application Load Balancer esterno globale o l'Application Load Balancer classico e i tuoi backend gestiscono contenuti statici, valuta la possibilità di utilizzare i bucket di backend anziché i servizi di backend.

La tabella seguente riassume quali bilanciatori del carico utilizzano i servizi di backend. Il prodotto che stai utilizzando 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 utilizzato da Google 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	Multiple	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP_PORT a livello di zona Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^2 Tutti i NEG serverless: uno o più servizi App Engine, Cloud Run o Cloud Functions NEG Private Service Connect: se vengono specificati più NEG, i NEG devono trovarsi in regioni diverse Un NEG internet globale per un backend esterno	EXTERNAL_MANAGED
Bilanciatore del carico delle applicazioni classico	Multiple	Tutto il mondo^1	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP_PORT a livello di zona Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^2 Tutti i NEG serverless: uno o più servizi App Engine, Cloud Run o Cloud Functions oppure Un NEG internet globale per un backend esterno	EXTERNAL
Bilanciatore del carico delle applicazioni esterno regionale	Multiple	Regionale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP_PORT a livello di zona Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^2 Un singolo NEG serverless (solo Cloud Run) 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	Multiple	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP_PORT a livello di zona Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^2 Un singolo NEG serverless (solo Cloud Run) Un singolo NEG Private Service Connect	INTERNAL_MANAGED
Bilanciatore del carico delle applicazioni interno regionale	Multiple	Regionale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP_PORT a livello di zona Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^2 Un singolo NEG serverless (solo Cloud Run) 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		Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP_PORT a livello di zona Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^2	EXTERNAL_MANAGED
Bilanciatore del carico di rete proxy classico	1	Tutto il mondo^1	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP_PORT a livello di zona Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^2	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 di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP_PORT a livello di zona Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: 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	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 di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP_PORT a livello di zona Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: 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	INTERNAL_MANAGED
Bilanciatore del carico di rete proxy interno tra regioni	Multiple	Globale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP_PORT a livello di zona Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT	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 di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP a livello di zona	EXTERNAL
Bilanciatore del carico di rete passthrough interno	1	A livello di regione, ma configurabile per essere accessibile a livello globale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG di tipo GCE_VM_IP a livello di zona	INTERNAL
Traffic Director	Multiple	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più backend di gruppi di istanze gestite, non gestiti o una combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello 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 di servizi	INTERNAL_SELF_MANAGED

¹ I servizi di backend utilizzati dagli Application Load Balancer classici e dai bilanciatori del carico di rete proxy classici hanno sempre un 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 a livello di regione.
• Tutti i backend connessi al servizio di backend devono trovarsi nella stessa regione della regola di forwarding.

² Per i deployment GKE, i backend di NEG misti sono supportati solo con NEG autonomi.

Backend

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

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

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 rimuoverlo come backend da tutti i servizi di backend che vi fanno riferimento.

Gruppi di istanze

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

VM di backend e indirizzi IP esterni

Le VM di backend nei servizi di backend non hanno bisogno di indirizzi IP esterni:

• Per bilanciatori del carico delle applicazioni esterni globali e bilanciatori del carico di rete con proxy esterno: 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 della rete VPC del backend con l'indirizzo IPv4 interno del backend. La comunicazione tra i GFE e le VM o gli endpoint di backend è facilitata tramite route speciali.
  • Per i backend di 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 a livello di zona, puoi specificare l'indirizzo IP dell'endpoint come indirizzo IPv4 principale 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 di 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 a livello di zona, puoi specificare l'indirizzo IP dell'endpoint come indirizzo IPv4 principale 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, purché l'interfaccia di rete si trovi nella stessa rete del bilanciatore del carico.

• Per i bilanciatori del carico di rete passthrough esterni: i client comunicano direttamente con i backend tramite l'infrastruttura di bilanciamento del carico passthrough Maglev di Google. I pacchetti vengono instradati e consegnati ai backend mantenendo gli indirizzi IP di origine e di destinazione originali. 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 consegnati all'interfaccia nic0 della VM.
  • Per GCE_VM_IP endpoint in un NEG a livello di zona, i pacchetti vengono consegnati 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 del 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:

• Sul backend di ciascun gruppo di istanze, devi configurare una o più porte con nome utilizzando coppie chiave-valore. La chiave rappresenta il nome di una porta significativo che scegli e il valore rappresenta il numero di porta che assegni a quel nome. La mappatura dei nomi ai numeri viene eseguita singolarmente per ogni backend di gruppo di istanze.

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

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

Ad esempio, potresti 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

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

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

Un servizio di backend può utilizzare un numero di porta diverso durante la comunicazione 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 rimane in ascolto delle connessioni TCP inviate all'indirizzo IP e alla porta di destinazione delle sue regole di forwarding. Poiché il proxy apre una seconda connessione TCP con i suoi backend, la porta di destinazione della seconda connessione TCP può essere diversa.

Le porte denominate sono applicabili solo ai backend di 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 ai collegamenti ai servizi di riferimento dei NEG PSC 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. perché sono bilanciatori del carico passthrough che instradano le connessioni direttamente ai backend, invece di crearne di nuove. I pacchetti vengono consegnati ai backend mantenendo l'indirizzo IP di destinazione e la porta della regola di forwarding del bilanciatore del carico.

Per scoprire come creare porte denominate, consulta le seguenti 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 crei gruppi di istanze per i bilanciatori del carico, tieni presente le seguenti restrizioni e indicazioni:

• Non inserire una VM in più di un gruppo di istanze con bilanciamento del carico. Se una VM è membro di due o più gruppi di istanze non gestite o di un gruppo di istanze gestite e di uno o più gruppi di istanze non gestite, Google Cloud limita l'utilizzo di uno di questi gruppi di istanze alla volta come backend per un particolare servizio di backend.

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

• Nel caso dei bilanciatori del carico proxy, quando vuoi bilanciare il traffico verso porte diverse, specifica le porte con nome richieste in un gruppo di istanze e fai in modo che ogni servizio di backend sottoscriva a una porta denominata univoca .

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

  Ecco le combinazioni incompatibili con la modalità di bilanciamento:

  • CONNECTION con UTILIZATION
  • RATE con UTILIZATION

  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 denominato instance-group-a in internal-tcp-backend-service.
  • In internal-tcp-backend-service, devi applicare la modalità di bilanciamento di CONNECTION perché i bilanciatori del carico di rete passthrough interni supportano solo la modalità di bilanciamento di CONNECTION.
  • Puoi anche utilizzare instance-group-a in external-https-backend-service se applichi la modalità di bilanciamento di RATE in external-https-backend-service.
  • Non puoi utilizzare instance-group-a anche in external-https-backend-service con la modalità di bilanciamento UTILIZATION.

• Per modificare la modalità di bilanciamento 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 nuovamente il gruppo di istanze come backend ai restanti servizi di backend, se supportano la nuova modalità di bilanciamento.

• Se il gruppo di istanze è associato a più servizi di backend, ciascun servizio di backend può fare riferimento alla stessa porta denominata o a una porta con nome 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. Questa operazione potrebbe causare una scalabilità imprevedibile e non necessaria delle istanze nel gruppo, soprattutto se utilizzi la metrica di scalabilità automatica dell'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) a livello di zona sono risorse a livello 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 NEG a livello di zona per i backend distribuisce il traffico tra applicazioni o container in esecuzione all'interno delle VM.

Sono disponibili due tipi di endpoint di rete per i NEG a livello di zona:

• GCE_VM_IP endpoint (supportati solo con bilanciatori del carico di rete passthrough interni e 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 a livello di zona, consulta la tabella: servizi di backend e tipi di backend supportati.

Per i dettagli, consulta la panoramica sui NEG a livello di zona.

Gruppi di endpoint di rete internet

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

Un NEG internet è una combinazione di un nome host o di un indirizzo IP, più una porta facoltativa. Sono disponibili due tipi di endpoint di rete per i NEG internet: INTERNET_FQDN_PORTe INTERNET_IP_PORT.

I NEG internet sono disponibili in due ambiti: globali e a livello di regione. Per sapere quali prodotti supportano i backend NEG internet in ogni ambito, consulta la tabella: servizi di backend e tipi di backend supportati.

Per maggiori dettagli, vedi 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 un servizio Cloud Run, App Engine, Cloud Functions o Gateway API.

Un NEG serverless può rappresentare uno dei seguenti elementi:

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

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

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

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

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

Associazioni dei servizi

Un'associazione di servizi è un backend che stabilisce una connessione tra un servizio di backend in Traffic Director e un servizio registrato in Service Directory. Un servizio di backend può fare riferimento a diverse associazioni di servizi. Un servizio di backend con un'associazione di servizi non può fare riferimento ad altri tipi di backend.

Backend misti

Le seguenti considerazioni sull'utilizzo si applicano quando aggiungi diversi tipi di backend a un singolo servizio di backend:

• Un singolo servizio di backend non può utilizzare contemporaneamente sia i gruppi di istanze sia i NEG di zona.
• Puoi utilizzare una combinazione di tipi di gruppi di istanze diversi sullo stesso servizio di backend. Ad esempio, un singolo servizio di backend può fare riferimento a una combinazione di gruppi di istanze gestite e non gestite. Per informazioni complete su quali backend sono compatibili con i singoli 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 NON_GCP_PRIVATE_IP_PORTendpoint) per configurare il bilanciamento del carico ibrido. Per vedere quali bilanciatori del carico dispongono di questa funzionalità, consulta la tabella: servizi di backend e tipi di backend supportati.

Protocollo ai 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 e non puoi specificare un protocollo secondario da utilizzare come fallback.

I protocolli validi dipendono dal tipo di bilanciatore del carico o dall'utilizzo o meno di Traffic Director.

Tabella: protocollo ai backend

Prodotto	Opzioni del protocollo del servizio di backend
Bilanciatore del carico delle applicazioni	HTTP, HTTPS, HTTP/2
Bilanciatore del carico di rete proxy	TCP o SSL I bilanciatori del carico di rete proxy regionali supportano solo TCP.
Bilanciatore del carico di rete passthrough	TCP, UDP o UNSPECIFIED
Traffic Director	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.

Crittografia tra il bilanciatore del carico e i backend

Per informazioni sulla crittografia tra il bilanciatore del carico e i backend, consulta Crittografia nei 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 l'idoneità del backend per le nuove richieste o connessioni.
• Una capacità target definisce un numero massimo target di connessioni, una frequenza massima target o l'utilizzo massimo target della CPU.
• Un scaler della capacità regola la capacità complessiva disponibile senza modificare la capacità target.

Modalità di bilanciamento

La modalità di bilanciamento determina se i backend di un bilanciatore del carico o di Traffic Director possono gestire traffico aggiuntivo o sono completamente caricati. Google Cloud prevede tre modalità di bilanciamento:

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

Modalità di bilanciamento disponibili per ciascun bilanciatore del carico

Puoi impostare 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 di CONNECTION, ma non supportano l'impostazione della capacità target.

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

• Per gli Application Load Balancer classici, viene selezionata una regione in base alla località del client e alla capacità disponibile della regione, in base alla capacità di destinazione della modalità di bilanciamento del carico. Quindi, all'interno di una regione, la capacità di destinazione della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste inviate a ciascun backend nella regione. Le richieste o le connessioni vengono quindi distribuite in modo round robin tra istanze o endpoint all'interno del backend.

• Per gli Application Load Balancer esterni globali, viene selezionata una regione in base alla località del client e alla capacità disponibile della regione, in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità di destinazione della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste che 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 del backend preferito per influenzare la selezione di backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico nelle istanze o negli endpoint all'interno del gruppo.

• Per gli bilanciatori del carico delle applicazioni interni tra regioni, gli Application Load Balancer esterni regionali e gli Application Load Balancer interni regionali, la capacità di destinazione della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste che devono essere inviate a ciascun backend (gruppo di istanze o NEG) nella regione. All'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico nelle istanze o negli endpoint all'interno del gruppo. Solo l'Application Load Balancer interno tra regioni supporta l'utilizzo del criterio di bilanciamento del carico del servizio (serviceLbPolicy) e delle impostazioni del backend preferito per influenzare la selezione di 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 a livello di zona con endpoint GCE_VM_IP_PORT e la modalità di bilanciamento CONNECTION per 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 con proxy esterno globale, viene selezionata una regione in base alla località del client e alla capacità disponibile della regione, in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità di destinazione della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste che 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 del backend preferito per influenzare la selezione di backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico nelle istanze o negli 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à di destinazione della modalità di bilanciamento viene utilizzata per calcolare le proporzioni per il numero di richieste che 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 del backend preferito per influenzare la selezione di backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico nelle istanze o negli endpoint all'interno del gruppo.

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

• Per i bilanciatori del carico di rete con proxy esterno regionale e i bilanciatori del carico di rete del proxy interno regionale, la capacità di destinazione della modalità di bilanciamento del carico viene utilizzata per calcolare le proporzioni relative al numero di richieste 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 nelle istanze o negli endpoint all'interno del gruppo.

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

Tabella: Modalità di bilanciamento disponibili per ciascun bilanciatore del carico

Bilanciatore del carico	Backend	Modalità di bilanciamento disponibili
Bilanciatore del carico delle applicazioni	Gruppi di istanze	RATE o UTILIZATION
	NEG a livello di zona (GCE_VM_IP_PORT endpoint)	RATE
	NEG ibridi (NON_GCP_PRIVATE_IP_PORT endpoint)	RATE
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 durante l'utilizzo della modalità di bilanciamento di UTILIZATION, ti consigliamo di utilizzare invece RATE.

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

Se l'utilizzo medio di tutte le VM associate a un servizio di backend è inferiore al 10%, Google Cloud potrebbe preferire zone specifiche. Questo può verificarsi 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 di zona si risolve automaticamente man mano che viene inviato più traffico al bilanciatore del carico.

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

Capacità target

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

• Numero di connessioni
• Frequenza
• Utilizzo CPU

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

Modalità bilanciamento delle connessioni

Per la modalità di bilanciamento di 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 target:

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

La seguente tabella mostra in che modo il parametro della capacità target definisce quanto segue:

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

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

Tipo di backend	Capacità target
	Se specifichi	Intera capacità di backend	Capacità prevista per istanza o per endpoint
Gruppo di istanze N istanze, H in stato integro	max-connections-per-instance=X	X × N	(X × N)/H
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 in stato integro	max-connections=Y	Y	Y/H

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

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

Modalità bilanciamento della frequenza

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

• max-rate-per-instance (per VM): fornisci una tasso di richieste HTTP media target per una singola VM.
• max-rate-per-endpoint (per endpoint in un NEG a livello di zona): fornisci una frequenza media di richieste HTTP target per un singolo endpoint.
• max-rate (per NEG a livello di zona e per gruppi di istanze a livello di zona): fornisci una frequenza media di richieste HTTP target 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 seguente tabella mostra in che modo il parametro della capacità target definisce quanto segue:

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

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

Tipo di backend	Capacità target
	Se specifichi	Intera capacità di backend	Capacità prevista per istanza o per endpoint
Gruppo di istanze N istanze, H in stato integro	max-rate-per-instance=X	X × N	(X × N)/H
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 in stato integro	max-rate=Y	Y	Y/H

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

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

Modalità Bilanciamento dell'utilizzo

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

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

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

Modifica della modalità di bilanciamento di un bilanciatore del carico

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

Per vedere quali modalità di bilanciamento sono supportate per ciascun bilanciatore del carico, consulta la Tabella: Modalità di bilanciamento disponibili per ciascun bilanciatore del carico

Modalità di bilanciamento e impostazioni della capacità target

Questa tabella riassume tutte le possibili modalità di bilanciamento per un determinato bilanciatore del carico e tipo di backend. Mostra inoltre le impostazioni di capacità disponibili o richieste che devi specificare con la modalità di bilanciamento.

Tabella: Specifica della capacità target per le modalità di bilanciamento

Bilanciatore del carico	Tipo di backend	Modalità di bilanciamento	Capacità target
Bilanciatore del carico delle applicazioni Traffic Director	Gruppo di istanze	RATE	Devi specificare una delle seguenti opzioni: max-rate per gruppo di istanze a livello di zona max-rate-per-instance (gruppi di istanze a livello di zona o di regione)
		UTILIZATION	Facoltativamente, puoi specificare una delle seguenti opzioni: (1) max-utilization (2) max-rate per gruppo di istanze a livello di zona (3) max-rate-per-instance (gruppi di istanze a livello di zona o di regione) (1) e (2) insieme (1) e (3) insieme
	NEG a livello di zona (GCP_VM_IP_PORT)	RATE	Devi specificare una delle seguenti opzioni: max-rate per NEG a livello di zona max-rate-per-endpoint
	NEG ibrido (NON_GCP_PRIVATE_IP_PORT)	RATE	Devi specificare una delle seguenti opzioni: max-rate per NEG ibrido max-rate-per-endpoint
Bilanciatore del carico di rete proxy esterno globale Bilanciatore del carico di rete proxy classico Network Load Balancer proxy esterno regionale Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy interno tra regioni	Gruppo di istanze	CONNECTION	Devi specificare una delle seguenti opzioni: max-connections per gruppo di istanze a livello di zona max-connections-per-instance (gruppi di istanze a livello di zona o di regione)
		UTILIZATION	Facoltativamente, puoi specificare una delle seguenti opzioni: (1) max-utilization (2) max-connections per gruppo di istanze a livello di zona (3) max-connections-per-instance (gruppi di istanze a livello di zona o di regione) (1) e (2) insieme (1) e (3) insieme
	NEG a livello di zona (GCP_VM_IP_PORT)	CONNECTION	Devi specificare una delle seguenti opzioni: max-connections per NEG a livello di zona max-connections-per-endpoint
	NEG ibrido (NON_GCP_PRIVATE_IP_PORT)	CONNECTION	Devi specificare una delle seguenti opzioni: max-connections per NEG ibrido max-connections-per-endpoint
Bilanciatore del carico di rete passthrough	Gruppo di istanze	CONNECTION	Non puoi specificare un numero massimo di connessioni target.
	NEG a livello di zona (GCP_VM_IP)	CONNECTION	Non puoi specificare un numero massimo di connessioni target.

Nota: per la modalità di bilanciamento RATE o UTILIZATION, quando viene raggiunta la capacità massima target in tutti i backend, il bilanciatore del carico distribuisce il traffico in proporzione alla capacità. Il bilanciatore del carico non ignora le richieste.

Gestore della scalabilità della capacità

Utilizza il gestore di scalabilità della capacità per scalare la capacità target (utilizzo massimo, velocità massima o numero massimo di connessioni) senza modificare la capacità target.

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

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

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

Puoi impostare il gestore di scalabilità della capacità su uno dei seguenti valori:

• Il valore predefinito è 1, il che significa che il gruppo pubblica fino al 100% della capacità configurata (in base a balancingMode).
• Il valore 0 indica che il gruppo è completamente svuotato e offre lo 0% della capacità disponibile. Non puoi configurare un'impostazione 0 se esiste un solo backend collegato 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 congiunzione con l'impostazione della capacità target:

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

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

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

Nota: il gestore della scalabilità della capacità non è supportato per i backend che non supportano una modalità di bilanciamento. Ciò include backend come NEG internet, NEG serverless e NEG PSC.

Criterio di bilanciamento del carico del servizio

Anteprima

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

Un criterio 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 la distribuzione del traffico all'interno dei backend associati a un servizio di backend:

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

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

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

Traffic Director e distribuzione del traffico

Traffic Director usa anche le risorse del servizio di backend. In particolare, Traffic Director utilizza i 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 un criterio di bilanciamento del carico. Il servizio di backend indirizza il traffico a un backend in base alla modalità di bilanciamento del backend. Traffic Director distribuisce quindi il traffico in base a un criterio di bilanciamento del carico.

I servizi di backend autogestiti interni supportano le seguenti modalità di bilanciamento:

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

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

Per ulteriori informazioni su Traffic Director, consulta i concetti di Traffic Director.

Creazione di sottoinsiemi di backend

L'impostazione di sottoinsiemi di backend è una funzionalità facoltativa che migliora le prestazioni e la scalabilità assegnando un sottoinsieme di backend a ciascuna istanza proxy.

L'impostazione di sottoinsiemi di backend è supportata per:

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

Creazione di sottoinsiemi di backend per Application Load Balancer interni regionali

Anteprima

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

Il bilanciatore del carico delle applicazioni interno tra regioni non supporta l'impostazione di sottoinsiemi di backend.

Per gli Application Load Balancer interni regionali, l'impostazione secondaria di backend assegna automaticamente a ogni istanza proxy solo un sottoinsieme di backend all'interno del servizio di backend regionale. Per impostazione predefinita, ogni istanza proxy apre le connessioni a tutti i backend all'interno di un servizio di backend. Quando il numero di istanze proxy e di backend sono entrambi grandi, l'apertura delle connessioni a tutti i backend può causare problemi di prestazioni.

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

Il seguente diagramma mostra un bilanciatore del carico con due proxy. Senza l'impostazione secondaria di backend, il traffico proveniente da entrambi i proxy viene distribuito a tutti i backend nel servizio di backend 1. Con l'impostazione di sottoinsiemi di backend abilitata, il traffico proveniente da ogni proxy viene distribuito a un sottoinsieme di backend. Il traffico proveniente dal proxy 1 viene distribuito verso i backend 1 e 2, mentre quello proveniente dal proxy 2 viene distribuito verso i backend 3 e 4.

Confronto del bilanciatore del carico delle applicazioni interno senza e con impostazione secondaria del backend (fai clic per ingrandire).

Puoi inoltre perfezionare il traffico del bilanciamento del carico verso i backend impostando il criterio localityLbPolicy. Per ulteriori informazioni, vedi Criteri sul traffico.

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

Avvertenze relative alla creazione di sottoinsiemi di backend per il bilanciatore del carico delle applicazioni interno

• Sebbene l'impostazione dei sottoinsiemi di backend sia progettata per garantire che tutte le istanze di backend rimangano ben utilizzate, può introdurre alcuni bias nella quantità di traffico ricevuta da ogni backend. L'impostazione di localityLbPolicy su LEAST_REQUEST è consigliata per i servizi di backend sensibili al bilanciamento del carico di backend.
• L'attivazione e la disattivazione dell'impostazione secondaria interrompe le connessioni esistenti.
• L'impostazione di sottoinsiemi di backend richiede che l'affinità sessione sia NONE (un hash a 5 tuple). Altre opzioni di affinità sessione possono essere utilizzate solo se l'impostazione secondaria di backend è disabilitata. I valori predefiniti dei flag --subsetting-policy e --session-affinity sono entrambi NONE e solo uno alla volta può essere impostato su un valore diverso.

Creazione di sottoinsiemi di backend per il bilanciatore del carico di rete passthrough interno

L'impostazione secondaria di backend per 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 l'uso di sottoinsiemi influisce su questo limite, consulta la sezione "Servizi di backend" delle quote e dei limiti delle risorse di bilanciamento del carico.

Per impostazione predefinita, l'impostazione di sottoinsiemi è disabilitata, limitando la distribuzione del servizio di backend a un massimo di 250 istanze o endpoint di backend. Se il tuo servizio di backend deve supportare più di 250 backend, puoi abilitare l'impostazione secondaria. Quando l'impostazione secondaria è abilitata, viene selezionato un sottoinsieme di istanze di backend per ogni connessione client.

Il seguente diagramma mostra un modello in scala per la differenza tra queste due modalità di funzionamento.

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

Senza l'impostazione di un sottoinsieme, viene utilizzato meglio l'insieme completo di backend integri e le nuove connessioni client vengono distribuite tra tutti i backend integri in base alla distribuzione del traffico. L'impostazione secondaria impone restrizioni per il bilanciamento del carico, ma consente al bilanciatore del carico di supportare più di 250 backend.

Per le istruzioni di configurazione, consulta Impostazione secondaria.

Avvertenze relative alla creazione di sottoinsiemi di backend per il bilanciatore del carico di rete passthrough interno

• Quando l'impostazione di un sottoinsieme è abilitata, non tutti i backend riceveranno traffico da un determinato mittente, anche se il numero di backend è ridotto.
• Per il numero massimo di istanze di backend quando è abilitata l'impostazione di sottoinsieme, consulta la pagina delle quote .
• Per l'impostazione di sottoinsiemi sono supportate solo l'affinità sessione a 5 tuple.
• Il mirroring pacchetto non è supportato con l'impostazione di sottoinsiemi.
• L'attivazione e la disattivazione dell'impostazione secondaria interrompe le connessioni esistenti.
• Se i client on-premise hanno bisogno di accedere a un bilanciatore del carico di rete passthrough interno, l'impostazione di sottoinsiemi può ridurre notevolmente il numero di backend che ricevono connessioni dai client on-premise. Il motivo è che 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. Vengono utilizzati sottoinsiemi diversi in regioni diverse.
• Non puoi utilizzare il protocollo del servizio di backend UNSPECIFIED.

Prezzi dei sottoinsiemi di backend

Non è previsto alcun costo per l'utilizzo dell'impostazione secondaria di backend. Per saperne di più, consulta Tutti i prezzi di networking.

Affinità sessione

L'affinità sessione ti consente di controllare in modo prevedibile in che modo il bilanciatore del carico seleziona i backend per le nuove connessioni, purché il numero di backend in stato integro rimanga costante. Questo è utile per le applicazioni che richiedono più richieste da un determinato utente per essere indirizzate allo stesso backend o endpoint. Queste applicazioni di solito includono server stateful utilizzati dalla pubblicazione di annunci, giochi o servizi con memorizzazione nella cache interna di grandi dimensioni.

I bilanciatori del carico Google Cloud forniscono l'affinità sessione secondo il criterio del "best effort". Fattori come la modifica degli stati del controllo di integrità dei backend, l'aggiunta o la rimozione di backend o le modifiche all'intero livello di integrità del backend, misurati dalla modalità di bilanciamento, possono interrompere l'affinità sessione.

Il bilanciamento del carico con l'affinità sessione funziona bene in presenza di una distribuzione ragionevolmente grande di connessioni univoche. Per "ragionevolmente grande" si intende almeno diverse volte il numero di backend. Il test di un bilanciatore del carico con un numero ridotto di connessioni non produce una rappresentazione accurata della distribuzione delle connessioni client tra i backend.

Per impostazione predefinita, tutti i bilanciatori del carico di 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 i bilanciatori del carico pass-through, le nuove connessioni vengono distribuite in istanze o endpoint di backend integri (nel pool attivo, se è configurato un criterio di failover). Puoi controllare quanto segue:

• Consente di stabilire se le connessioni stabilite vengono mantenute su backend in stato non integro. Per maggiori dettagli, consulta Persistenza della connessione sui backend in stato non integro nella documentazione sul bilanciatore del carico di rete passthrough interno e Persistenza della connessione sui backend in stato non integro nella documentazione sul bilanciatore del carico di rete passthrough esterno esterno basato su servizi di backend.
• Indica se le connessioni stabilite vengono mantenute durante il failover e il failover, nel caso in cui sia configurato un criterio di failover. Per maggiori dettagli, consulta Svuotamento della connessione in caso di failover e failover nella documentazione del bilanciatore del carico di rete passthrough interno e Svuotamento della connessione in caso di failover e failover nella documentazione sul bilanciatore del carico di rete passthrough esterno esterno basato sul servizio di backend.
• Per quanto tempo possono rimanere le connessioni stabilite durante la rimozione di un backend dal bilanciatore del carico. Per maggiori dettagli, consulta Attivare lo svuotamento della connessione.

Per i bilanciatori del carico basati su proxy, a condizione che il numero di istanze o endpoint di backend integri rimanga costante e a condizione che l'istanza o l'endpoint di istanza di backend selezionati in precedenza non abbiano raggiunto la capacità, le richieste o le connessioni successive passano alla stessa VM o allo stesso endpoint di backend. La capacità target della modalità di bilanciamento determina quando il backend ha raggiunto la capacità.

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

Tabella: impostazioni di affinità sessione supportate

Prodotto	Opzioni di affinità sessione
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni esterno regionale	Nessuna (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE) Campo intestazione (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Nota anche: Il valore predefinito effettivo del criterio di località del bilanciamento del carico (localityLbPolicy) cambia in base alle impostazioni di affinità della sessione. Se l'affinità sessione non è configurata, ovvero se l'affinità 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 il bilanciatore del carico delle applicazioni esterno globale, non configurare l'affinità sessione se utilizzi la suddivisione del traffico ponderata. In questo caso, la configurazione della suddivisione del traffico ponderata avrà la precedenza.
Bilanciatore del carico delle applicazioni classico	Nessuna (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE)
Bilanciatore del carico delle applicazioni interno tra regioni Bilanciatore del carico delle applicazioni interno regionale	Nessuna (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE) Campo intestazione (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Nota anche: Il valore predefinito effettivo del criterio di località del bilanciamento del carico (localityLbPolicy) cambia in base alle impostazioni di affinità della sessione. Se l'affinità sessione non è configurata, ovvero se l'affinità 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 l'Application Load Balancer interno, non configurare l'affinità sessione se utilizzi la suddivisione del traffico ponderata. In questo caso, la configurazione della suddivisione del traffico ponderata avrà la precedenza.
Bilanciatore del carico di rete passthrough interno	Nessuna (NONE) IP CLIENT, nessuna destinazione (CLIENT_IP_NO_DESTINATION) IP client, IP di destinazione (CLIENT_IP) IP client, IP di destinazione, protocollo (CLIENT_IP_PROTO) IP client, porta client, IP di destinazione, porta di destinazione, protocollo (CLIENT_IP_PORT_PROTO) Per informazioni specifiche sul bilanciatore del carico di rete passthrough interno e sull'affinità sessione, consulta la panoramica del bilanciatore del carico di rete passthrough interno.
Bilanciatore del carico di rete passthrough esterno^1	Nessuna (NONE) IP client, IP di destinazione (CLIENT_IP) IP client, IP di destinazione, protocollo (CLIENT_IP_PROTO) IP client, porta client, IP di destinazione, porta di destinazione, protocollo (CLIENT_IP_PORT_PROTO) Per informazioni specifiche sul bilanciatore del carico di rete passthrough esterno e sull'affinità sessione, consulta la panoramica del bilanciatore del carico di rete passthrough esterno TCP/UDP esterno.
Bilanciatore del carico di rete proxy esterno globale Bilanciatore del carico di rete proxy classico Network Load Balancer proxy esterno regionale Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy interno tra regioni	Nessuna (NONE) IP client (CLIENT_IP)
Traffic Director	Nessuna (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE) (solo protocolli HTTP) Campo intestazione (HEADER_FIELD) (solo protocolli HTTP) Cookie HTTP (HTTP_COOKIE) (solo protocolli HTTP)

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

Quando configuri l'affinità sessione, tieni presente quanto segue:

• Non fare affidamento sull'affinità sessione per l'autenticazione o la sicurezza. L'affinità sessione è progettata per interrompersi ogni volta che cambia il numero di backend di pubblicazione e integri. Le attività che comportano l'interruzione dell'affinità sessione includono:

  • Aggiunta di gruppi di istanza di backend o NEG al servizio di backend
  • Rimozione di gruppi di istanza di backend o NEG dal servizio di backend
  • Aggiunta di istanze a un gruppo di istanza di backend esistente (operazione automatica quando abiliti la scalabilità automatica con i gruppi di istanze gestite)
  • Rimozione di istanze da un gruppo di istanza di backend esistente (operazione automatica quando abiliti la scalabilità automatica con i gruppi di istanze gestite)
  • Aggiunta di endpoint a un NEG di backend esistente
  • Rimozione degli endpoint da un NEG di backend esistente
  • Quando un backend integro non supera il controllo di integrità e diventa non integro
  • Quando un backend in stato non integro supera il controllo di integrità e diventa integro
  • Per i bilanciatori del carico pass-through: durante il failover e il failover, se è configurato un criterio di failover
  • Per i bilanciatori del carico proxy: quando un backend ha raggiunto o ha superato la capacità

• Non è consigliabile utilizzare un'affinità sessione diversa da None con la modalità di bilanciamento di UTILIZATION. Questo perché le modifiche all'utilizzo delle istanze possono far sì che il servizio di bilanciamento del carico indirizzi nuove richieste o connessioni alle VM di backend meno piene. Questo comporta l'interruzione dell'affinità sessione. Utilizza invece la modalità di bilanciamento RATE o CONNECTION per ridurre la possibilità di interrompere l'affinità sessione. Per maggiori dettagli, consulta Perdere affinità sessione.

• Per i bilanciatori del carico HTTP(S) esterni ed interni, l'affinità sessione potrebbe non funzionare quando l'endpoint o l'istanza previsti supera il limite massimo di destinazione della modalità di bilanciamento. Considera l'esempio seguente:

  • Un bilanciatore del carico ha un NEG e tre endpoint.
  • Ogni endpoint ha una capacità target di 1 RPS.
  • La modalità di bilanciamento è RATE.
  • Al momento, ciascun endpoint elabora rispettivamente 1,1, 0,8 e 1,6 RPS.
  • Quando una richiesta HTTP con affinità per l'ultimo endpoint arriva sul bilanciatore del carico, l'affinità sessione rivendica l'endpoint in fase di elaborazione a 1,6 RPS.
  • La nuova richiesta potrebbe andare all’endpoint intermedio con 0,8 RPS.

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

Le seguenti sezioni descrivono i diversi tipi di affinità sessione.

IP client, nessuna affinità destinazione

L'IP client, nessuna affinità di destinazione (CLIENT_IP_NO_DESTINATION) indirizza le richieste dallo stesso indirizzo IP di origine client alla stessa istanza di backend.

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

• L'IP client, nessuna affinità di destinazione è un hash a una tupla costituito dall'indirizzo IP di origine del client.

• Se un client passa da una rete all'altra, il suo indirizzo IP cambia, causando un'affinità non funzionante.

L'IP client, nessuna affinità di destinazione è un'opzione solo per i bilanciatori del carico di rete passthrough interni.

Affinità IP client

L'affinità IP client (CLIENT_IP) indirizza le richieste dallo stesso indirizzo IP client alla stessa istanza di backend. L'affinità IP client è un'opzione per ogni bilanciatore del carico Google Cloud che utilizza i servizi di backend.

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

• L'affinità IP client è un hash a due tuple composto dall'indirizzo IP del client e dall'indirizzo IP della regola di forwarding del bilanciatore del carico contattata dal client.

• L'indirizzo IP del client visto dal bilanciatore del carico potrebbe non essere il client di origine se si trova dietro NAT o se effettua richieste tramite un proxy. Le richieste effettuate tramite NAT o proxy utilizzano l'indirizzo IP del router o del proxy NAT come indirizzo IP client. Di conseguenza, il traffico in entrata può essere raggruppato inutilmente nelle stesse istanze di backend.

• Se un client passa da una rete all'altra, il suo indirizzo IP cambia, causando un'affinità non funzionante.

Per sapere quali prodotti supportano l'affinità IP client, consulta la Tabella: Impostazioni di affinità sessione supportate.

Affinità cookie generata

Quando imposti l'affinità cookie generato, il bilanciatore del carico invia un cookie alla prima richiesta. Per ogni richiesta successiva con lo stesso cookie, il bilanciatore del carico indirizza la richiesta alla stessa VM o allo stesso endpoint di backend.

• Per gli Application Load Balancer esterni globali, il cookie è denominato GCLB.

• Per Traffic Director, Application Load Balancer esterni regionali e gli Application Load Balancer interni, il cookie è denominato GCILB.

L'affinità basata sui cookie consente di identificare in modo più accurato un client rispetto a un bilanciatore del carico rispetto all'affinità basata su IP del client. Ad esempio:

1. Con l'affinità basata sui cookie, il bilanciatore del carico può identificare in modo univoco due o più sistemi client che condividono lo stesso indirizzo IP di origine. Utilizzando l'affinità basata su IP client, il bilanciatore del carico tratta tutte le connessioni dallo stesso indirizzo IP di origine come se provenissero dallo stesso sistema client.

2. Se un client modifica il proprio indirizzo IP, l'affinità basata sui cookie consente al bilanciatore del carico di riconoscere le connessioni successive provenienti da quel client, invece di considerarla come nuova. Un esempio di quando un client cambia l'indirizzo IP è il passaggio di un dispositivo mobile da una rete all'altra.

Quando un bilanciatore del carico crea un cookie per l'affinità basata sui cookie generata, imposta l'attributo path del cookie su /. Se il matcher percorso della mappa URL dispone di più servizio di backend per un nome host, tutti i servizi di backend condividono lo stesso cookie di sessione.

La durata del cookie HTTP generato dal bilanciatore del carico è configurabile. Puoi impostarlo su 0 (valore predefinito), il che significa che il cookie è solo un cookie di sessione. In alternativa, puoi impostare la durata del cookie su un valore compreso tra 1 e 86400 secondi (24 ore) inclusi.

Per sapere quali prodotti supportano l'affinità cookie generato, consulta la Tabella: Impostazioni di affinità sessione supportate.

Affinità campo intestazione

Traffic Director e Application Load Balancer interni possono utilizzare l'affinità del campo intestazione quando si verificano entrambe le seguenti condizioni:

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

Per sapere quali prodotti supportano l'affinità del campo dell'intestazione, consulta la Tabella: Impostazioni di affinità sessione supportate.

Affinità cookie HTTP

Traffic Director, Application Load Balancer esterno globale, bilanciatore del carico delle applicazioni esterno regionale, bilanciatore del carico di rete proxy esterno globale, bilanciatore del carico delle applicazioni interno regionale e bilanciatore del carico delle applicazioni interno regionale possono utilizzare l'affinità dei cookie HTTP quando entrambe le seguenti condizioni sono vere:

• Il criterio di località del bilanciamento del carico è RING_HASH o MAGLEV.
• L'hash coerente del servizio di backend specifica il nome del cookie HTTP.

L'affinità dei cookie HTTP instrada le richieste alle VM o agli endpoint di backend in un NEG in base al cookie HTTP denominato nel flag HTTP_COOKIE. Se il client non fornisce il cookie, il proxy genera il cookie e lo restituisce al client in un'intestazione Set-Cookie.

Per sapere quali prodotti supportano l'affinità IP dei cookie HTTP, consulta la Tabella: Impostazioni di affinità sessione supportate.

Affinità sessione persa

Indipendentemente dal tipo di affinità scelto, un client può perdere l'affinità con un backend nelle seguenti situazioni:

• Se il gruppo di istanza di backend o il NEG a livello di zona esaurisce la capacità, come definito dalla capacità di destinazione della modalità di bilanciamento. In questa situazione, Google Cloud indirizza il traffico a un gruppo di istanza di backend o a un NEG a livello di zona diverso, che potrebbe trovarsi in una zona diversa. Puoi mitigare questo problema assicurandoti di specificare la capacità di destinazione corretta per ogni backend in base ai tuoi test.
• La scalabilità automatica aggiunge o rimuove istanze da un gruppo di istanze gestite. In questo caso, il numero di istanze nel gruppo di istanze cambia, quindi il servizio di backend ricalcola gli hash per l'affinità sessione. Puoi attenuare questo problema garantendo che la dimensione minima del gruppo di istanze gestite sia in grado di gestire un carico tipico. La scalabilità automatica viene quindi eseguita solo durante gli aumenti imprevisti del carico.
• Se una VM o un endpoint di backend in un NEG non supera i controlli di integrità, il bilanciatore del carico indirizza il traffico a un backend integro diverso. Consulta la documentazione relativa a ciascun bilanciatore del carico Google Cloud per i dettagli sul comportamento del bilanciatore del carico quando tutti i suoi backend non superano i controlli di integrità.
• Quando la modalità di bilanciamento di UTILIZATION è attiva per i gruppi di istanza di backend, l'affinità sessione si interrompe a causa di modifiche nell'utilizzo del backend. Puoi attenuare questo problema utilizzando la modalità di bilanciamento RATE o CONNECTION, a seconda di quella supportata dal tipo di bilanciatore del carico.

Quando utilizzi bilanciatori del carico delle applicazioni esterni o bilanciatori del carico di rete con proxy esterno, tieni presente quanto segue:

• Se il percorso di routing da un client su internet a Google cambia tra richieste o connessioni, potrebbe essere selezionato un altro Google Front End (GFE) come proxy. Ciò può interrompere l'affinità sessione.
• Quando utilizzi la modalità di bilanciamento di UTILIZATION, soprattutto senza una capacità target massima definita, è probabile che l'affinità sessione si interrompa quando il traffico verso il bilanciatore del carico è ridotto. Passa alla modalità di bilanciamento RATE o CONNECTION, come supportata dal bilanciatore del carico scelto.

Timeout del servizio di backend

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

• Per gli Application Load Balancer esterni e per gli Application Load Balancer 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 maggiori dettagli sul timeout del servizio di backend per ciascun bilanciatore del carico, consulta quanto segue:

  • Per gli bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico delle applicazioni esterni regionali, consulta Timeout e nuovi tentativi.
  • Per gli Application Load Balancer interni, consulta Timeout e nuovi tentativi.

• Per i bilanciatori del carico di rete proxy esterni,il timeout è un timeout di inattività. Per consentire più o meno tempo prima che la connessione venga eliminata, 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 e i bilanciatori del carico di rete passthrough 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 alcun significato per questi bilanciatori del carico passthrough.

• Per Traffic Director, il campo di 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 che un backend restituisca una risposta completa dopo l'invio della richiesta. Il timeout di gRPC specifica il tempo di attesa dall'inizio del flusso fino al completamento dell'elaborazione della risposta, inclusi tutti i nuovi tentativi.

Controlli di integrità

A ogni servizio di backend i cui backend sono gruppi di istanze o NEG a livello di zona deve essere associato a un controllo di integrità. 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, al momento della creazione del bilanciatore del carico oppure fare riferimento a un controllo di integrità esistente.

Quando crei un servizio di backend utilizzando backend di gruppi di istanze o di NEG a livello di zona utilizzando Google Cloud CLI o l'API, devi fare riferimento a un controllo di integrità esistente. Per maggiori dettagli sul tipo e sull'ambito del controllo di integrità richiesto, consulta la guida relativa al bilanciatore del carico in Panoramica dei controlli di integrità.

Per maggiori informazioni, consulta i seguenti documenti:

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

Funzionalità aggiuntive abilitate nella risorsa del servizio di backend

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

Cloud CDN

Cloud CDN utilizza la rete perimetrale globale di Google per fornire contenuti più vicino agli utenti, accelerando 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 gli indirizzi IP frontend e le porte che ricevono le richieste, nonché i backend che rispondono alle richieste.

Per maggiori dettagli, consulta la documentazione di Cloud CDN.

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

Google Cloud Armor

Se utilizzi uno dei seguenti bilanciatori del carico, puoi aggiungere ulteriore protezione alle tue applicazioni abilitando Google 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 Google Cloud Armor esistente.
• Accettare la configurazione di un criterio di sicurezza per la limitazione di frequenza di Google Cloud Armor predefinito con parametri personalizzabili per nome, conteggio delle richieste, intervallo, chiave e limitazione della frequenza. Se utilizzi Google Cloud Armor con un servizio proxy upstream, ad esempio un provider CDN, Enforce_on_key deve essere impostato come un indirizzo IP XFF.
• Scegli di disattivare la protezione di Google Cloud Armor selezionando Nessuna.

IAP

IAP consente di stabilire un livello di autorizzazione centrale per le applicazioni a cui si accede tramite HTTPS, in modo da poter utilizzare un modello di controllo dell'accesso dell'accesso a livello di applicazione invece di affidarsi a firewall a livello di rete. IAP è supportato da determinati bilanciatori del carico delle applicazioni.

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

Funzionalità di gestione del traffico

Le seguenti funzionalità sono supportate solo per alcuni prodotti:

• Criteri di bilanciamento del carico (localityLbPolicy) ad eccezione di ROUND_ROBIN
• Si è verificato un interruzione del circuito, tranne il campo maxRequests
• Rilevamento outlier

Queste funzionalità sono supportate dai seguenti bilanciatori del carico:

• Bilanciatore del carico delle applicazioni esterno globale (l'interruzione del circuito non è supportata)

• Bilanciatore del carico delle applicazioni esterno regionale

• Bilanciatore del carico delle applicazioni interno tra regioni

• Bilanciatore del carico delle applicazioni interno regionale

• Traffic Director (ma non supportato con i servizi gRPC senza proxy)

API e riferimento 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 servizio di backend a livello di regione

• gcloud compute backend-services pagina, per i servizi di backend globali e a livello di regione

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 lo svuotamento della connessione
• Crittografia dei dati in transito in Google Cloud

Per i video correlati:

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