Panoramica dei servizi di backend

Un servizio di backend definisce il modo in cui Cloud Load Balancing distribuisce il traffico. 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 sessione, controlli di integrità e timeout. Queste impostazioni forniscono un controllo dettagliato 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 oa livello di regione.

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 abilitati altri servizi, inclusi quelli seguenti che sono disponibili solo per determinati bilanciatori del carico:
  • Cloud CDN
  • Criteri di sicurezza di Google Cloud Armor
  • Identity-Aware Proxy
• Designa i servizi di backend regionali come servizi in App Hub, che è in anteprima.

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

Nota: se utilizzi il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni 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 i bilanciatori del carico che 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	Multiplo	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti ‡ Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT‡ Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT † Tutti i NEG serverless: uno o più servizi App Engine, Cloud Run o Cloud Functions NEG Private Service Connect: se viene specificato più di un NEG, i NEG devono trovarsi in regioni diverse Un NEG internet globale per un backend esterno	EXTERNAL_MANAGED
Bilanciatore del carico delle applicazioni classico	Multiplo	Tutto il mondo*	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT † Tutti i NEG serverless: uno o più servizi App Engine, Cloud Run o Cloud Functions 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 dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT † 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	Multiplo	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT † Un singolo NEG serverless (solo Cloud Run) Un singolo NEG Private Service Connect	INTERNAL_MANAGED
Bilanciatore del carico delle applicazioni interno regionale	Multiplo	Regionale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT † 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 dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti ‡ Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT‡ Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: NEG di tipo GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT †	EXTERNAL_MANAGED
Bilanciatore del carico di rete proxy classico	1	Tutto il mondo*	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: 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 dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: 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 dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: 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	Multiplo	Globale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: 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 dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP	EXTERNAL
Bilanciatore del carico di rete passthrough interno	1	A livello di regione, ma configurabile in modo da essere accessibile a livello globale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP	INTERNAL
Cloud Service Mesh	Multiplo	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend dei gruppi di istanze: uno o più backend gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona 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

Backend

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

• Gruppo di istanze contenente istanze di macchine virtuali (VM). Un gruppo di istanze può essere un gruppo di istanze gestite, con o senza scalabilità automatica, oppure un gruppo di istanze non gestite. Più di un servizio di backend può fare riferimento a un gruppo di istanze, ma tutti i servizi di backend che fanno riferimento al gruppo di istanze devono utilizzare la stessa modalità di bilanciamento.
• NEG a livello di zona
• NEG serverless
• NEG internet
• NEG connettività ibrida
• NEG Private Service Connect
• Associazioni dei 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 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 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 GCE_VM_IP_PORT endpoint 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 VM o 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 primario che corrisponde all'interfaccia nic0 della VM e nic0 deve trovarsi nella stessa rete del bilanciatore del carico.
  • Per GCE_VM_IP_PORT endpoint 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 attraverso l'infrastruttura di bilanciamento del carico passthrough Maglev di Google. I pacchetti vengono indirizzati e consegnati ai backend con gli indirizzi IP di origine e di destinazione originali conservati. I backend rispondono ai client utilizzando il ritorno diretto del server. I metodi utilizzati per selezionare un backend e tenere traccia delle 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 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 come segue:

• Sul backend di ogni gruppo di istanze, devi configurare una o più porte denominate mediante coppie chiave/valore. La chiave rappresenta un nome di porta significativo che hai scelto e il valore rappresenta il numero di porta assegnato al nome. La mappatura dei nomi ai numeri viene eseguita singolarmente per il backend di ogni gruppo di istanze.

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

In base al backend di un 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 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 necessariamente 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 ai 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 GCE_VM_IP_PORT endpoint, 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, mentre i NEG PSC fanno riferimento agli allegati di servizio che utilizzano astrazioni che non prevedono l'indicazione 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. Si tratta di bilanciatori del carico passthrough che instradano le connessioni direttamente ai backend anziché crearne di nuove. I pacchetti vengono recapitati ai backend, conservando 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: utilizzare le porte denominate
• Gruppi di istanze gestite: assegnazione di porte denominate ai gruppi di istanze gestite

Limitazioni e linee guida per i gruppi di istanze

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

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

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

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

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

  Di seguito sono riportate le combinazioni di modalità di bilanciamento incompatibili:

  • CONNECTION con UTILIZATION
  • RATE con UTILIZATION

  Considera il seguente esempio:

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

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

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

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

• Ti consigliamo di non aggiungere un gruppo di istanze gestite con scalabilità automatica a più di un servizio di backend. Ciò potrebbe causare una scalabilità imprevedibile e non necessaria delle istanze nel gruppo, soprattutto se utilizzi la metrica di scalabilità automatica Utilizzo del bilanciamento del carico HTTP.

  • Sebbene non sia consigliato, questo scenario potrebbe funzionare se la metrica di scalabilità automatica è Utilizzo CPU o Metrica di Cloud Monitoring non correlata alla capacità di gestione del bilanciatore del carico. L'uso di una di queste metriche con scalabilità automatica può impedire una scalabilità irregolare.

Gruppi di endpoint di rete a livello di zona

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

I gruppi di endpoint di rete (NEG) di zona sono risorse a livello di zona che rappresentano raccolte di indirizzi IP o combinazioni di indirizzo IP e porta per le risorse Google Cloud all'interno di una singola subnet.

Un servizio di backend che utilizza NEG a livello di zona come 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 (supportato solo con bilanciatori del carico di rete passthrough interni e bilanciatori del carico di rete esterni basati sul servizio di backend).
• GCE_VM_IP_PORT endpoint.

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

Per maggiori dettagli, consulta Panoramica dei NEG a livello di zona.

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 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: globale e regionale. Per sapere quali prodotti supportano i backend di NEG internet in ogni ambito, consulta Tabella: Servizi di backend e tipi di backend supportati.

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

Gruppi di endpoint di rete serverless

Un gruppo di endpoint di rete (NEG) specifica un gruppo di endpoint di backend per un bilanciatore del carico. Un NEG serverless è un backend che punta a un servizio Cloud Run, App Engine, 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 tra tutti i servizi, indipendentemente dall'implementazione del servizio. Questa funzionalità è in Anteprima.

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

Per vedere quali bilanciatori del carico supportano i backend NEG serverless, consulta 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 Cloud Service Mesh 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ò usare contemporaneamente sia gruppi di istanze sia NEG a livello di zona.
• Puoi utilizzare una combinazione di diversi tipi di gruppi di istanze nello stesso servizio di backend. Ad esempio, un singolo servizio di backend può fare riferimento a una combinazione di gruppi di istanze gestite e non gestite. Per informazioni complete sui backend compatibili con i vari servizi di backend, consulta la tabella nella sezione precedente.
• Con determinati bilanciatori del carico proxy, puoi utilizzare una combinazione di NEG a livello di zona (con GCE_VM_IP_PORT endpoint) e NEG di connettività ibrida (con NON_GCP_PRIVATE_IP_PORT endpoint) 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 dal fatto che utilizzi Cloud Service Mesh.

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 del proxy regionale supportano solo TCP.
Bilanciatore del carico di rete passthrough	TCP, UDP o UNSPECIFIED
Cloud Service Mesh	HTTP, HTTPS, HTTP/2, gRPC, TCP

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

Criterio di selezione degli indirizzi IP

Questo campo è applicabile ai bilanciatori del carico delle applicazioni esterni globali e ai bilanciatori del carico di rete proxy esterni globali con schema di bilanciamento del carico EXTERNAL_MANAGED. Devi utilizzare il criterio di selezione dell'indirizzo IP per specificare il tipo di traffico che viene inviato dal GFE ai backend.

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

Il criterio di selezione degli indirizzi IP viene utilizzato quando vuoi eseguire la migrazione del servizio di backend del bilanciatore del carico per supportare un tipo di traffico diverso. Per ulteriori informazioni, vedi Scegliere un flusso di lavoro per la migrazione da IPv4 a IPv6.

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

Criterio di selezione degli indirizzi IP	Descrizione
Solo IPv4	Invia solo traffico IPv4 ai backend del servizio di backend, indipendentemente dal traffico dal client al GFE. Solo i controlli di integrità IPv4 vengono utilizzati per verificare l'integrità dei backend.
Preferenza per IPv6	Dai la priorità alla connessione IPv6 del backend sulla connessione IPv4 (a condizione che sia presente un backend integro con indirizzi IPv6). I controlli di integrità monitorano periodicamente le connessioni IPv6 e IPv4 dei backend. Il GFE tenta prima la connessione IPv6; se la connessione IPv6 è interrotta o lenta, GFE usa occhi felici per passare e connettersi a IPv4. Anche se una delle connessioni IPv6 o IPv4 non è integro, il backend viene comunque considerato integro ed entrambe le connessioni possono essere provate dal GFE, con un occhio felice alla scelta della connessione da utilizzare.
Solo IPv6	Invia solo traffico IPv6 ai backend del servizio di backend, indipendentemente dal traffico dal client al proxy. Solo i controlli di integrità IPv6 vengono utilizzati per verificare l'integrità dei backend. Non esiste una convalida per verificare se il tipo di traffico di backend corrisponde al criterio di selezione dell'indirizzo IP. Ad esempio, se hai backend IPV4 e selezioni Only IPv6 come criterio di selezione degli indirizzi IP, non osserverai errori di configurazione ma il traffico non sarà indirizzato ai tuoi backend.

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 di connessioni target, una frequenza massima target o un utilizzo massimo della CPU target.
• Uno scaler di capacità regola la capacità complessiva disponibile senza modificare la capacità target.

Modalità di bilanciamento

La modalità di bilanciamento determina se i backend di un bilanciatore del carico o di Cloud Service Mesh possono gestire traffico aggiuntivo o se 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 di richieste (query) al secondo (RPS, QPS) target. Il valore RPS/QPS massimo 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 ogni bilanciatore del carico

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

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

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

• Per i bilanciatori del carico delle applicazioni classici, viene selezionata una regione in base alla località del client e all'eventuale capacità disponibile nella regione, in base alla capacità target della modalità di bilanciamento del carico. Quindi, all'interno di una regione, viene utilizzata la capacità target della modalità di bilanciamento per calcolare le proporzioni relative al numero di richieste che dovrebbero essere inviate a ogni backend della regione. Le richieste o le connessioni vengono quindi distribuite in modo round robin tra le istanze o gli endpoint all'interno del backend.

• Per i bilanciatori del carico delle applicazioni esterni globali, viene selezionata una regione in base alla località del client e all'eventuale capacità disponibile nella regione, in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste 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 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 delle applicazioni interni tra regioni, i bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico delle applicazioni interni regionali, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni del 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 a istanze o endpoint all'interno del gruppo. Solo il bilanciatore del carico delle applicazioni interno tra regioni supporta l'uso delle impostazioni del criterio di bilanciamento del carico del servizio (serviceLbPolicy) e del backend preferito per influenzare la selezione di backend specifici all'interno di una regione.

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

• Per i bilanciatori del carico di rete proxy esterni globali, viene selezionata una regione in base alla località del client e al fatto che la regione abbia capacità disponibile, in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste 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 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 tra le istanze o gli endpoint all'interno del gruppo.

• Per i bilanciatori del carico di rete proxy interni tra regioni, viene selezionata per prima la regione configurata. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni per la quantità 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 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 tra le istanze o gli 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 al fatto che la regione abbia capacità disponibile in base alla capacità target della modalità di bilanciamento del carico. Quindi, all'interno di una regione, la capacità target della modalità di bilanciamento del carico viene utilizzata per calcolare le proporzioni relative al numero di richieste o connessioni 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 secondo modalità round robin tra le istanze VM o gli endpoint di rete all'interno di ogni singolo backend.

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

La 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 ogni bilanciatore del carico

Bilanciatore del carico	Backend	Modalità di bilanciamento disponibili
Bilanciatore del carico delle applicazioni	Gruppi di istanze	RATE o UTILIZATION
	NEG a livello di zona (GCE_VM_IP_PORT endpoint)	RATE
	NEG ibrido (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 ibrido (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

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 più traffico viene inviato al bilanciatore del carico.

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

Capacità target

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

• Numero di connessioni
• Frequenza
• Utilizzo CPU

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

Modalità di bilanciamento delle connessioni

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

• max-connections-per-instance (per VM): il 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): 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 tabella seguente 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à di destinazione per i backend che utilizzano la modalità di bilanciamento della connessione

Tipo di backend	Capacità target
	Se specifichi	Intera capacità del backend	Prevista per capacità di istanza o 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 integre	max-connections=Y	Y	Y/H

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

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

Modalità di bilanciamento delle tariffe

Per la modalità di bilanciamento RATE, devi definire la capacità di destinazione 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 tariffa media target per le richieste HTTP per un singolo endpoint.
• max-rate (per NEG a livello di zona e per gruppi di istanze a livello di zona): fornisci una tasso di richieste HTTP media 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 tabella seguente 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à di destinazione per i backend che utilizzano la modalità di bilanciamento RATE

Tipo di backend	Capacità target
	Se specifichi	Intera capacità del backend	Prevista per capacità di istanza o 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 integre	max-rate=Y	Y	Y/H

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

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

Modalità di bilanciamento dell'utilizzo

La modalità di bilanciamento UTILIZATION non ha una capacità target obbligatoria. Le opzioni disponibili dipendono dal tipo di backend, come riepilogato nella tabella nella sezione seguente.

La capacità target di 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 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 max-utilization su 0,8 (80%) se è selezionata la modalità di bilanciamento UTILIZATION. Oltre a max-utilization, la modalità di bilanciamento di UTILIZATION supporta capacità di destinazione più complesse, come riassunte nella tabella nella sezione seguente.

Modifica della modalità di bilanciamento di un bilanciatore del carico

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

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

Modalità di bilanciamento e impostazioni di 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 della capacità disponibile o richiesta che devi specificare con la modalità di bilanciamento.

Tabella: specifica della capacità di destinazione per le modalità di bilanciamento

Bilanciatore del carico	Tipo di backend	Modalità di bilanciamento	Capacità target
Bilanciatore del carico delle applicazioni Cloud Service Mesh	Gruppo di istanze	RATE	Devi specificare uno dei seguenti elementi: 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	Puoi facoltativamente 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 uno dei seguenti elementi: max-rate per NEG a livello di zona max-rate-per-endpoint
	NEG ibrido (NON_GCP_PRIVATE_IP_PORT)	RATE	Devi specificare uno dei seguenti elementi: 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 uno dei seguenti elementi: 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	Puoi facoltativamente 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 uno dei seguenti elementi: max-connections per NEG a livello di zona max-connections-per-endpoint
	NEG ibrido (NON_GCP_PRIVATE_IP_PORT)	CONNECTION	Devi specificare uno dei seguenti elementi: 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.

Scaler della capacità

Utilizza lo scaler della capacità per scalare la capacità target (utilizzo massimo, frequenza massima o connessioni massime) senza modificare la capacità target.

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

• Google Cloud CLI: capacity-scaler
• dell'API:
  • A livello di regione
  • Globale

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

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

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

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

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

Criterio di bilanciamento del carico del servizio

Un criterio di bilanciamento del carico del servizio (serviceLbPolicy) è una risorsa associata al servizio di backend del bilanciatore del carico. 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 svuotare rapidamente il traffico dai backend in stato non integro.

Inoltre, puoi designare backend specifici come backend preferiti. Questi backend devono essere utilizzati per definire la 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 avanzato con un criterio di bilanciamento del carico del servizio.

Cloud Service Mesh e distribuzione del traffico

Cloud Service Mesh utilizza anche le risorse servizio di backend. In particolare, Cloud Service Mesh utilizza servizi di backend il cui schema di bilanciamento del carico è INTERNAL_SELF_MANAGED. Per un servizio di backend autogestito interno, la distribuzione del traffico si basa sulla combinazione di una modalità di bilanciamento del carico e di un criterio di bilanciamento del carico. Il servizio di backend indirizza il traffico a un backend in base alla modalità di bilanciamento del backend. Quindi, Cloud Service Mesh distribuisce 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 RATE, devi specificare una tariffa massima, una tariffa massima per istanza o una tariffa massima per endpoint.

Per ulteriori informazioni su Cloud Service Mesh, consulta i concetti di Cloud Service Mesh.

Creazione secondaria di backend

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

L'impostazione secondaria dei backend è supportata per:

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

Creazione di sottoinsiemi di backend per i bilanciatori del carico delle applicazioni interni regionali

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

Per i bilanciatori del carico delle applicazioni interni regionali, l'impostazione secondaria dei 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 le connessioni a tutti i backend all'interno di un servizio di backend. Quando il numero di istanze proxy e di backend sono di grandi dimensioni, l'apertura di connessioni a tutti i backend può portare a problemi di prestazioni.

Se abiliti l'impostazione secondaria, ogni proxy apre le connessioni solo a un sottoinsieme di backend, riducendo il numero di connessioni che vengono mantenute aperte per ciascun backend. La riduzione del numero di connessioni aperte contemporaneamente a ciascun backend può migliorare le prestazioni sia per i backend che per i 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 del servizio di backend 1. Con l'impostazione secondaria dei backend abilitata, il traffico proveniente da 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.

Puoi anche perfezionare il traffico di bilanciamento del carico verso i backend impostando il criterio localityLbPolicy. Per maggiori informazioni, consulta le Norme sul traffico.

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

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

• Anche se l'impostazione secondaria dei backend è progettata per garantire che tutte le istanze di backend restino utilizzate in modo adeguato, può introdurre qualche bias nella quantità di traffico ricevuta da ciascun backend. È consigliabile impostare localityLbPolicy su LEAST_REQUEST per i servizi di backend sensibili al bilanciamento del carico del backend.
• L'abilitazione e la disattivazione dell'impostazione secondaria interrompe le connessioni esistenti.
• La creazione 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 del 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.

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

L'impostazione secondaria del 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 l'impostazione secondaria 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 secondaria è disabilitata, il che limita la distribuzione del servizio di backend a un massimo di 250 istanze o endpoint di backend. Se il tuo servizio di backend deve supportare più di 250 backend, puoi abilitare l'impostazione secondaria. Quando si abilita l'impostazione secondaria, viene selezionato un sottoinsieme di istanze di backend per ogni connessione client.

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

Senza il sottoinsieme, viene utilizzato al 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 sul bilanciamento del carico, ma consente al bilanciatore del carico di supportare più di 250 backend.

Per istruzioni di configurazione, vedi Impostazione secondaria.

Avvertenze relative all'impostazione secondaria del backend per il bilanciatore del carico di rete passthrough interno

• Se è abilitata l'impostazione secondaria, 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 secondaria, consulta la pagina delle quote .
• Con l'impostazione secondaria è supportata solo l'affinità sessione a 5 tuple.
• Mirroring pacchetto non è supportato con l'impostazione secondaria.
• L'abilitazione 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, il sottoinsieme può ridurre in modo sostanziale 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. Vengono utilizzati sottoinsiemi diversi in regioni diverse.

Prezzi di sottoinsiemi di backend

Non è previsto alcun costo per l'utilizzo dell'impostazione secondaria dei backend. Per ulteriori informazioni, consulta Tutti i prezzi di networking.

Affinità sessione

L'affinità sessione consente di controllare in che modo il bilanciatore del carico seleziona i backend per le nuove connessioni in modo prevedibile, purché il numero di backend 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 in genere includono server stateful utilizzati dalla pubblicazione di annunci, giochi o servizi con una memorizzazione nella cache interna intensa.

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

Il bilanciamento del carico con affinità sessione funziona bene quando esiste una distribuzione ragionevolmente grande di connessioni univoche. Un numero di backend abbastanza grande indica almeno alcune 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 passthrough, le nuove connessioni vengono distribuite a istanze di backend o endpoint integri (nel pool attivo, se è configurato un criterio di failover). Puoi controllare:

• Se le connessioni stabilite vengono mantenute su backend in stato non integro. Per maggiori dettagli, consulta Persistenza della connessione su backend in stato non integro nella documentazione del bilanciatore del carico di rete passthrough interno e Persistenza della connessione sui backend in stato non integro nella documentazione del bilanciatore del carico di rete passthrough esterno esterno basato sul servizio di backend.
• Indica se le connessioni stabilite persistono durante il failover e il failover, se è 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 del bilanciatore del carico di rete passthrough esterno basato sul servizio di backend.
• Per quanto tempo possono rimanere le connessioni stabilite quando si rimuove un backend dal bilanciatore del carico. Per maggiori dettagli, vedi Attivazione del svuotamento della connessione.

Per i bilanciatori del carico basati su proxy, finché il numero di istanze di backend o endpoint in stato integro rimane costante e, finché l'istanza o l'endpoint di backend selezionati in precedenza non ha raggiunto la capacità massima, le richieste o le connessioni successive vanno alla stessa VM di backend o allo stesso endpoint. La capacità target della modalità di bilanciamento determina quando il backend raggiunge la capacità massima.

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

Tabella: Impostazioni di affinità sessione supportate

Prodotto	Opzioni di affinità sessione
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni esterno regionale	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 per le località di 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 sul valore predefinito NONE, il valore predefinito per localityLbPolicy è ROUND_ROBIN. Se l'affinità sessione è impostata su un valore diverso da NONE, il valore predefinito per localityLbPolicy è MAGLEV. Per il bilanciatore del carico delle applicazioni esterno globale, non configurare l'affinità sessione se utilizzi la suddivisione del traffico ponderata. In questo caso, la configurazione della suddivisione del traffico ponderata ha 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 per le località di 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 sul valore predefinito NONE, il valore predefinito per localityLbPolicy è ROUND_ROBIN. Se l'affinità sessione è impostata su un valore diverso da NONE, il valore predefinito per localityLbPolicy è MAGLEV. Per il bilanciatore del carico delle applicazioni interno, non configurare l'affinità sessione se utilizzi la suddivisione del traffico ponderata. In questo caso, la configurazione della suddivisione del traffico ponderata ha 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*	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)
Cloud Service Mesh	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 nei 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 in stato e di gestione integro. Le attività che comportano l'interruzione dell'affinità sessione includono:

  • Aggiunta di gruppi di istanza di backend o NEG al servizio di backend
  • Rimozione dei gruppi di istanza di backend o NEG dal servizio di backend
  • Aggiunta di istanze a un gruppo di istanza di backend esistente (questa operazione viene eseguita automaticamente quando abiliti la scalabilità automatica con i gruppi di istanze gestite)
  • Rimuovere istanze da un gruppo di istanza di backend esistente (questa operazione viene eseguita automaticamente 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 non integro supera il controllo di integrità e diventa integro
  • Per i bilanciatori del carico passthrough: durante il failover e il failover, se è configurato un criterio di failover
  • Per i bilanciatori del carico proxy: quando un backend ha raggiunto o superato la capacità

• Non è consigliabile utilizzare un'affinità sessione diversa da None con la modalità di bilanciamento UTILIZATION. Questo perché le modifiche nell'utilizzo dell'istanza possono indurre il servizio di bilanciamento del carico a indirizzare nuove richieste o connessioni a VM di backend meno piene. Viene interrotta l'affinità sessione. Utilizza invece la modalità di bilanciamento RATE o CONNECTION per ridurre la probabilità di interruzione dell'affinità sessione. Per ulteriori dettagli, consulta Affinità sessioni perse.

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

  • 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, ogni endpoint sta elaborando 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 richiede che l'endpoint in fase di elaborazione sia pari a 1,6 RPS.
  • La nuova richiesta potrebbe andare all'endpoint centrale 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 sezioni seguenti discutono i diversi tipi di affinità sessione.

IP client, nessuna affinità di destinazione

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 del client, nessuna affinità di destinazione, tieni presente quanto segue:

• 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 a un'altra, il suo indirizzo IP cambia, generando così un'affinità interrotta.

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 usa 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 che contatta il client.

• L'indirizzo IP del client visto dal bilanciatore del carico potrebbe non essere quello di origine se è protetto da 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 potrebbe aggregarsi inutilmente nelle stesse istanze di backend.

• Se un client passa da una rete a un'altra, il suo indirizzo IP cambia, generando così un'affinità interrotta.

Per informazioni su 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 per la prima richiesta. Per ogni richiesta successiva con lo stesso cookie, il bilanciatore del carico inoltra la richiesta alla stessa VM di backend o allo stesso endpoint.

• Per i bilanciatori del carico delle applicazioni esterni globali, il cookie è denominato GCLB.

• Per Cloud Service Mesh, i bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico delle applicazioni interni, il cookie è denominato GCILB.

L'affinità basata sui cookie può 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 del client, il bilanciatore del carico tratta tutte le connessioni provenienti dallo stesso indirizzo IP di origine come se provenissero dallo stesso sistema client.

2. Se un client cambia il proprio indirizzo IP, l'affinità basata sui cookie consente al bilanciatore del carico di riconoscere le connessioni successive da quel client, invece di considerare la connessione come nuova. Ad esempio, quando un client cambia l'indirizzo IP, si verifica quando un dispositivo mobile si sposta 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 del percorso della mappa URL ha 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 (impostazione predefinita), 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 scoprire quali prodotti supportano l'affinità cookie generato, consulta la Tabella: Impostazioni di affinità sessione supportate.

Affinità campo intestazione

I seguenti bilanciatori del carico utilizzano l'affinità dei campi di intestazione:

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

L'affinità del campo dell'intestazione è supportata quando le seguenti condizioni sono vere:

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

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

Affinità cookie HTTP

Cloud Service Mesh, il bilanciatore del carico delle applicazioni esterno globale, il bilanciatore del carico delle applicazioni esterno regionale, il bilanciatore del carico di rete proxy esterno globale, il bilanciatore del carico di rete proxy esterno regionale, il bilanciatore del carico delle applicazioni interno tra regioni e il bilanciatore del carico delle applicazioni interno regionale possono utilizzare l'affinità dei cookie HTTP se entrambe le seguenti condizioni sono vere:

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

L'affinità del cookie HTTP instrada le richieste a VM di backend o endpoint 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 scoprire 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 di zona esaurisce la capacità, come definito dalla capacità target della modalità di bilanciamento. In questa situazione, Google Cloud indirizza il traffico a un gruppo di istanza di backend o a un NEG 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. Quando ciò accade, il numero di istanze nel gruppo di istanze cambia, quindi il servizio di backend ricalcola gli hash per l'affinità sessione. Puoi mitigare questo problema assicurandoti che la dimensione minima del gruppo di istanze gestite sia in grado di gestire un carico tipico. La scalabilità automatica viene quindi eseguita solo in caso di aumenti imprevisti del carico.
• Se una VM di backend o un endpoint in un NEG non supera i controlli di integrità, il bilanciatore del carico indirizza il traffico a un backend integro diverso. Per informazioni dettagliate sul funzionamento del bilanciatore del carico quando tutti i backend non superano i controlli di integrità, consulta la documentazione relativa a ciascun bilanciatore del carico di Google Cloud.
• Quando la modalità di bilanciamento UTILIZATION è attiva per i gruppi di istanza di backend, l'affinità sessione si interrompe a causa delle modifiche all'utilizzo del backend. Puoi mitigare questo problema utilizzando la modalità di bilanciamento RATE o CONNECTION, a seconda di quale è supportata dal tipo di bilanciatore del carico.

Quando utilizzi bilanciatori del carico delle applicazioni esterni o bilanciatori del carico di rete proxy esterni, tieni presente i seguenti punti aggiuntivi:

• Se il percorso di routing da un client su internet a Google cambia tra le richieste o le connessioni, è possibile che venga selezionato un Google Front End (GFE) diverso come proxy. Questo può interrompere l'affinità sessione.
• Quando utilizzi la modalità di bilanciamento 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 che hai 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 è compreso tra 1 e 2.147.483.647 secondi.

• Per i bilanciatori del carico delle applicazioni esterni e i bilanciatori del carico delle applicazioni 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 nuovi tentativi.
  • Per i bilanciatori del carico delle applicazioni interni, consulta Timeout e nuovi tentativi.

• Per i bilanciatori del carico di rete proxy esterni, il timeout è un timeout per inattività. Per attendere 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 Cloud Service Mesh, il campo relativo al timeout del servizio di backend (specificato mediante timeoutSec) non è supportato con i servizi gRPC senza proxy. Per questi servizi, configura il timeout del servizio di backend utilizzando il campo maxStreamDuration. Questo perché gRPC non supporta la semantica di timeoutSec che specifica la quantità di tempo 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 del flusso fino al completamento dell'elaborazione della risposta, inclusi tutti i nuovi 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, al momento della creazione oppure puoi fare riferimento a un controllo di integrità esistente.

Quando crei un servizio di backend utilizzando backend di gruppi di istanze o NEG di zona utilizzando Google Cloud CLI o l'API, devi fare riferimento a un controllo di integrità esistente. Consulta la guida ai bilanciatori del carico nella panoramica dei controlli di integrità per maggiori dettagli sul tipo e sull'ambito del controllo di integrità richiesti.

Per ulteriori informazioni, leggi 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 così i siti web e le applicazioni. Cloud CDN è abilitato per i servizi di backend utilizzati da Application Load Balancer esterni globali. Il bilanciatore del carico fornisce gli indirizzi IP e le porte frontend che ricevono le richieste e i backend che rispondono alle richieste.

Per ulteriori dettagli, consulta la documentazione di Cloud CDN.

Cloud CDN non è compatibile con IAP. Non possono essere 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.
• Accetta la configurazione di un criterio di sicurezza predefinito per la limitazione di frequenza di Google Cloud Armor con parametri personalizzabili per nome, conteggio delle richieste, intervallo, chiave e limitazione di frequenza. Se utilizzi Google Cloud Armor con un servizio proxy upstream, ad esempio un provider CDN, Enforce_on_key deve essere impostato come indirizzo IP XFF.
• Scegli di disattivare la protezione di Google Cloud Armor selezionando Nessuna.

IAP

IAP consente di stabilire un livello di autorizzazione centrale per le applicazioni a cui si accede tramite HTTPS, che ti consente di utilizzare un modello di controllo dell'accesso dell'accesso a livello di applicazione anziché 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 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 errore di circuito, ad eccezione del campo maxRequests
• Rilevamento outlier

Queste funzionalità sono supportate dai seguenti bilanciatori del carico:

• Bilanciatore del carico delle applicazioni esterno globale (la rottura di circuiti non è supportata)

• Bilanciatore del carico delle applicazioni esterno regionale

• Bilanciatore del carico delle applicazioni interno tra regioni

• Bilanciatore del carico delle applicazioni interno regionale

• Cloud Service Mesh (ma non supportato con i servizi gRPC senza proxy)

Riferimento API e gcloud

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

* Risorsa API del servizio di backend globale

* Risorsa API del servizio di backend regionale

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

Passaggi successivi

Per la documentazione correlata e informazioni sull'utilizzo dei servizi di backend nel bilanciamento del carico, consulta quanto segue:

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