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 connettersi ai backend, varie impostazioni di distribuzione e sessione, controlli di integrità e timeout. Queste impostazioni offrono un'esperienza un controllo completo sul comportamento del bilanciatore del carico. Per iniziare, la maggior parte delle impostazioni ha valori predefiniti che consentono una configurazione rapida. L'ambito di un servizio di backend è globale o regionale.

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

• Indirizza il traffico ai 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 la salute dei backend.
• Specifica l'affinità sessione.
• Determina se sono attivati altri servizi, tra cui i seguenti che sono disponibili solo per determinati bilanciatori di carico:
  • Cloud CDN
  • Criteri di sicurezza di Google Cloud Armor
  • Identity-Aware Proxy
• Designa i servizi di backend regionali come servizio in App Hub, che è in anteprima.

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

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

La seguente tabella riassume i bilanciatori del carico che utilizzano i servizi di backend. Il prodotto che utilizzi determina anche il numero massimo di servizi di backend, l'ambito di un servizio di backend, il tipo di backend supportati e lo schema di bilanciamento del carico del servizio di backend. Lo schema di bilanciamento del carico è 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 inoltro e i servizi di backend. Alcuni schemi sono condivisi tra i prodotti.

Tabella: servizi di backend e tipi di backend supportati

Prodotto	Numero massimo di servizi di backend	Ambito del servizio di backend	Tipi di backend supportati	Schema di bilanciamento del carico
Bilanciatore del carico delle applicazioni esterno globale	Multiplo	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più gestiti, non gestiti o combinazione di backend di gruppi di istanze gestite e non gestite ^‡ Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT^‡ Tutti i NEG di connettività ibrida: uno o più NON_GCP_PRIVATE_IP_PORT NEG di tipo Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^† Tutti i NEG serverless: uno o più App Engine, Cloud Run, o funzioni Cloud Run Un NEG internet globale per un backend esterno NEG Private Service Connect: API di Google: un singolo Private Service Connect NEG Servizi gestiti: uno o più NEG Private Service Connect	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 del gruppo di istanze: uno o più backend di gruppi di istanze gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^† Tutti i NEG serverless: uno o più servizi App Engine, Cloud Run o Cloud Functions oppure Un NEG internet globale per un backend esterno	EXTERNAL
Bilanciatore del carico delle applicazioni esterno regionale	Multiplo	Regionale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più gestiti, non gestiti o combinazione di backend di gruppi di istanze gestite e non gestite ^‡ Tutti i NEG a livello di zona: uno o più di tipo GCE_VM_IP_PORT a livello di zona NEG ^‡ Tutti i NEG di connettività ibrida: uno o più NON_GCP_PRIVATE_IP_PORT NEG di tipo Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^† Un singolo NEG serverless (solo Cloud Run) Un singolo NEG Private Service Connect Tutti i NEG internet regionali per un backend esterno	EXTERNAL_MANAGED
Bilanciatore del carico delle applicazioni interno tra regioni	Multiplo	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend di gruppi di istanze gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti ^‡ Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT ^‡ Tutti i NEG di connettività ibrida: uno o più NON_GCP_PRIVATE_IP_PORT NEG di tipo Una combinazione di NEG a livello di zona e ibrido: GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT di tipo NEG ^† Un singolo NEG serverless (solo Cloud Run) NEG Private Service Connect: API di Google: un singolo Private Service Connect NEG Servizi gestiti: uno o più NEG Private Service Connect	INTERNAL_MANAGED
Bilanciatore del carico delle applicazioni interno regionale	Multiplo	Regionale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più gestiti, non gestiti o combinazione di backend di gruppi di istanze gestite e non gestite ^‡ Tutti i NEG a livello di zona: uno o più di tipo GCE_VM_IP_PORT a livello di zona NEG ^‡ 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: GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT di tipo NEG ^† Un singolo NEG serverless (solo Cloud Run) Un singolo NEG Private Service Connect Tutti i NEG internet regionali per un backend esterno	INTERNAL_MANAGED
Bilanciatore del carico di rete proxy esterno globale	1		Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestiti, non gestiti o una combinazione di backend del gruppo di istanze gestiti e non gestiti ^‡ Tutti i NEG a livello di zona: uno o più di tipo GCE_VM_IP_PORT a livello di zona NEG^‡ Tutti i NEG di connettività ibrida: uno o più NON_GCP_PRIVATE_IP_PORT NEG di tipo Una combinazione di NEG a livello di zona e ibrido: GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT di tipo NEG ^† NEG Private Service Connect: API di Google: un singolo Private Service Connect NEG Servizi gestiti: uno o più NEG Private Service Connect	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 di gruppi di istanze: uno o più gestiti, non gestiti o combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibridi: GCE_VM_IP_PORT e NEG di tipo NON_GCP_PRIVATE_IP_PORT ^†	EXTERNAL
Bilanciatore del carico di rete proxy esterno regionale	1	Regionale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestite, non gestite o una combinazione di backend del gruppo di istanze gestite e non gestite ^‡ Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT ^‡ Tutti i NEG di connettività ibrida: uno o più NEG di tipo NON_GCP_PRIVATE_IP_PORT Una combinazione di NEG a livello di zona e ibrido: GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT di tipo NEG Tutti i NEG internet a livello di regione per un backend esterno Un singolo NEG Private Service Connect	EXTERNAL_MANAGED
Bilanciatore del carico di rete proxy interno regionale	1	Regionale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più gestiti, non gestiti o combinazione di backend di gruppi di istanze gestite e non gestite ^‡ Tutti i NEG a livello di zona: uno o più di tipo GCE_VM_IP_PORT a livello di zona NEG ^‡ 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: GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT di tipo NEG Tutti i NEG internet a livello di regione per un backend esterno Un singolo NEG Private Service Connect	INTERNAL_MANAGED
Bilanciatore del carico di rete proxy interno tra regioni	Multiplo	Globale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend del gruppo di istanze gestiti, non gestiti o una combinazione di backend del gruppo di istanze gestiti e non gestiti ^‡ Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT ^‡ Tutti i NEG di connettività ibrida: uno o più NON_GCP_PRIVATE_IP_PORT NEG di tipo Una combinazione di NEG a livello di zona e ibrido: GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT di tipo NEG NEG Private Service Connect: API di Google: un singolo Private Service Connect NEG Servizi gestiti: uno o più NEG Private Service Connect	INTERNAL_MANAGED
Bilanciatore del carico di rete passthrough esterno	1	Regionale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend del gruppo di istanze: uno o più backend di gruppi di istanze gestiti, non gestiti o una combinazione di backend di gruppi di istanze gestiti e non gestiti Tutti i NEG a livello di zona: uno o più di tipo GCE_VM_IP a livello di zona NEG	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ù gestiti, non gestiti o combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP NEG mappatura di una porta (anteprima)	INTERNAL
Cloud Service Mesh	Multiplo	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend dei gruppi di istanze: uno o più gestiti, non gestiti o combinazione di backend di gruppi di istanze gestite e non gestite Tutti i NEG a livello di zona: uno o più NEG a livello di zona di tipo GCE_VM_IP_PORT 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 dai bilanciatori del carico delle applicazioni e dai bilanciatori del carico di rete con proxy classici hanno sempre ambito globale, sia nel livello di rete Standard che Premium. Tuttavia, nel livello Standard, le seguenti limitazioni applica:

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

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

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

Backend

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

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

Non puoi eliminare un gruppo di istanze di backend o un gruppo di istanze elastiche associato a un servizio di backend. Prima di eliminare un gruppo di istanze o un NEG, devi e 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 richiedono indirizzi IP esterni:

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

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

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

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

  • Per i backend dei gruppi di istanze, i pacchetti vengono sempre inviati all'nic0 interfaccia della VM.
  • Per GCE_VM_IP endpoint in un NEG a livello di zona, i pacchetti vengono consegnati a un'interfaccia di rete nella subnet associata al NEG.

Porte denominate

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

Le porte denominate sono configurate come segue:

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

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

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

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

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

Quindi fai riferimento alla porta denominata nella configurazione del servizio di backend con --port-name sul 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 una porta diversa per lo stesso nome di porta.

Il numero di porta risolta utilizzato dal servizio di backend del bilanciatore del carico proxy non deve necessariamente corrispondere al numero di porta usato dall'inoltro del bilanciatore del carico le regole del caso. Un bilanciatore del carico proxy rimane in ascolto delle connessioni TCP inviate all'indirizzo IP e la porta di destinazione delle relative regole di forwarding. Poiché il proxy apre un secondo connessione TCP ai suoi backend, la porta di destinazione della seconda connessione TCP essere diversi.

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

I bilanciatori del carico di rete passthrough interni e i bilanciatori del carico di rete passthrough esterni utilizzare porte denominate. Si tratta di bilanciatori del carico passthrough che instradano direttamente ai backend anziché crearne di nuove. I pacchetti vengono inviati ai backend preservando l'indirizzo IP e la porta di destinazione della regola di inoltro del bilanciatore del carico.

Per scoprire come creare porte denominate, consulta le seguenti istruzioni:

• Gruppi di istanze non gestite: utilizzo delle porte con nome
• Gruppi di istanze gestite: assegnazione di porte denominate a un'istanza gestita gruppi

Limitazioni e linee guida per i gruppi di istanze

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

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

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

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

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

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

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

• Per modificare la modalità di bilanciamento 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 un porta denominata sul gruppo di istanze.

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

  • Sebbene non sia consigliato, questo scenario potrebbe funzionare se la metrica di scalabilità automatica è Utilizzo della CPU o una metrica di monitoraggio del cloud non correlata alla capacità di gestione del bilanciatore del carico. L'utilizzo di uno di questi e le metriche di scalabilità automatica possono impedire la 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. Una rete gruppo di endpoint (NEG) è un raggruppamento logico di endpoint di rete.

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

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

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

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

Per vedere quali prodotti supportano i backend NEG a livello di zona, consulta Tabella: Servizi di backend e backend supportati di classificazione.

Per maggiori dettagli, vedi Panoramica dei NEG zonali.

Gruppi di endpoint di rete internet

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

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

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

Per maggiori dettagli, vedi Gruppo di endpoint di rete internet Panoramica.

Gruppi di endpoint di rete serverless

Un gruppo di endpoint di rete (NEG) specifica un gruppo di endpoint di backend per un carico con il bilanciatore del carico di rete passthrough esterno regionale. Un NEG serverless è un backend che punta a un Cloud Run, App Engine, Funzioni di Cloud Run oppure Gateway API completamente gestito di Google Cloud.

Un NEG serverless può rappresentare uno dei seguenti elementi:

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

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

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

Per vedere quali bilanciatori del carico supportano i backend NEG serverless, consulta Tabella: Servizi di backend e backend supportati di classificazione.

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 un servizio di backend in Cloud Service Mesh e un servizio registrato in Service Directory. Un servizio di backend può fare riferimento a diverse e le associazioni di servizi. Un servizio di backend con un'associazione di servizi non può fare riferimento con qualsiasi altro tipo di backend.

Backend misti

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

• Un singolo servizio di backend non può utilizzare contemporaneamente gruppi di istanze e NEG a livello di zona.
• Puoi utilizzare una combinazione di diversi tipi di gruppi di istanze nello stesso servizio di backend. Ad esempio, un singolo servizio di backend può fare riferimento a una combinazione di gruppi di istanze gestite e non gestite. Per informazioni complete su quali backend sono compatibili con quali servizi di backend, consulta la tabella nella sezione precedente.
• Con 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: Backend e tipi di backend supportati.

Protocollo per i backend

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

I protocolli validi dipendono dal tipo di bilanciatore del carico o dal fatto che tu utilizzano Cloud Service Mesh.

Tabella: protocollo per i backend

Prodotto	Opzioni del protocollo del servizio di backend
Bilanciatore del carico delle applicazioni	HTTP, HTTPS, HTTP/2
Bilanciatore del carico di rete proxy	TCP o SSL I bilanciatori del carico di rete 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 proxy. Devi utilizzare il criterio di selezione degli indirizzi IP per specificare il tipo di traffico inviato dal servizio di backend ai tuoi backend.

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

Il criterio di selezione degli indirizzi IP viene utilizzato quando vuoi convertire il bilanciatore del carico per supportare un tipo di traffico diverso. Per ulteriori informazioni, vedi Eseguire la conversione da stack singolo a doppio stack.

Puoi specificare i seguenti valori per il criterio di selezione dell'indirizzo IP:

Criterio di selezione degli indirizzi IP	Descrizione
Solo IPv4	Invia solo traffico IPv4 ai backend del servizio di backend, a prescindere dal traffico dal client al GFE. Solo IPv4 per controllare l'integrità dei backend.
Preferenza per IPv6	Dai la priorità alla connessione IPv6 del backend rispetto alla Connessione IPv4 (a condizione che sia presente un backend integro con indirizzi IPv6). I controlli di integrità monitorano periodicamente IPv6 e IPv4 e connessioni a Internet. La GFE tenta prima la connessione IPv6. Se la connessione IPv6 è interrotta o lenta, la GFE utilizza gli happy eyeballs per eseguire il fallback e connettersi a IPv4. Anche se una delle connessioni IPv6 o IPv4 non è attiva, il backend viene comunque trattato come attivo e GFE può provare entrambe le connessioni, con gli utenti che alla fine scelgono quale utilizzare.
Solo IPv6	Invia solo traffico IPv6 ai backend del servizio di backend, indipendentemente dal traffico dal client al proxy. Per controllare l'integrità dei backend vengono utilizzati solo i controlli di integrità IPv6. Non viene eseguita alcuna convalida per verificare se il tipo di traffico di backend corrisponde al criterio di selezione degli indirizzi IP. Ad esempio, se hai backend IPV4 e selezioni Only IPv6 come criterio di selezione dell'indirizzo IP, non riscontrerai errori di configurazione, ma il traffico non verrà 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 per i backend.

Distribuzione del traffico

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

• Una modalità di bilanciamento definisce in che modo il bilanciatore del carico misura l'idoneità del backend per nuove richieste o connessioni.
• Una capacità target definisce un numero massimo target di connessioni, una frequenza massima target o un utilizzo massimo della CPU target.
• 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 Cloud Service Mesh può gestire traffico aggiuntivo o è completamente caricato.

Google Cloud prevede tre modalità di bilanciamento:

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

Modalità di bilanciamento disponibili per ogni bilanciatore del carico

La modalità di bilanciamento viene impostata quando aggiungi un backend al servizio di backend. La le modalità di bilanciamento disponibili per un bilanciatore del carico dipendono dal tipo e il 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 RATE o UTILIZATION modalità di bilanciamento per i backend di gruppi di istanze, RATE modalità di bilanciamento per i backend NEG con GCE_VM_IP_PORT endpoint e RATE modalità di bilanciamento per i NEG ibridi (NON_GCP_PRIVATE_IP_PORT endpoint). Per qualsiasi altro tipo di backend supportato, e la modalità di bilanciamento del carico.

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

• Per i bilanciatori del carico delle applicazioni esterni globali, viene selezionata una regione in base alla località dal client e se la regione ha capacità disponibile, in base al carico la capacità target della modalità di bilanciamento. All'interno di una regione, il target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste che devono essere inviate ogni backend (gruppo di istanze o NEG) nella regione. Puoi utilizzare il servizio criterio di bilanciamento del carico (serviceLbPolicy) e l'impostazione di backend preferito per influenzare la selezione di qualsiasi tipo di 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 applicazione del traffico distribuite alle istanze o agli endpoint all'interno del gruppo.

• Per i bilanciatori del carico delle applicazioni interni tra regioni, i bilanciatori del carico delle applicazioni esterni regionali e gli Application Load Balancer interni regionali, la modalità di bilanciamento la capacità target viene utilizzata per calcolare le proporzioni di quante richieste Vai a ciascun backend (gruppo di istanze o NEG) della regione. All'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la distribuzione del traffico verso istanze o endpoint all'interno del gruppo. Solo il il bilanciatore del carico delle applicazioni interno tra regioni supporta l'uso del bilanciamento del carico del servizio (serviceLbPolicy) e le impostazioni di backend preferito per influenzare la selezione di specifiche all'interno di una regione.

I bilanciatori del carico di rete proxy supportano le modalità di bilanciamento CONNECTION o UTILIZATION per i backend dei gruppi di istanze VM, la modalità di bilanciamento CONNECTION per i NEG zonali con endpoint GCE_VM_IP_PORT e la modalità di bilanciamento CONNECTION per i NEG ibride (endpoint NON_GCP_PRIVATE_IP_PORT). Per qualsiasi 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à dal client e se la regione ha capacità disponibile, in base al carico la capacità target della modalità di bilanciamento. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni relative al numero di richieste da indirizzare a ciascun backend (gruppo di istanze o NEG) nella regione. Puoi utilizzare il servizio criterio di bilanciamento del carico (serviceLbPolicy) e l'impostazione di backend preferito per influenzare la selezione di qualsiasi tipo di all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, il criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo.

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

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

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

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

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

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

Nota:

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

La modalità di bilanciamento di UTILIZATION dipende dall'istanza VM o dell'utilizzo della CPU insieme ad altri fattori. Quando questi fattori variano, calcola le capacità in modo inefficace, cosa che spesso 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 gruppo di backend con la latenza media più bassa nelle richieste recenti o per HTTP/2 e HTTP/3, le richieste vengono inviate al gruppo di backend con il numero 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ò accadere quando utilizzi gruppi di istanze gestite a livello di regione, gruppi di istanze gestite a livello di zona in zone diverse e gruppi di istanze non gestite a livello di zona. Questo squilibrio in base alla zona si risolve automaticamente man mano che viene inviato più traffico al bilanciatore del carico.

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

Capacità target

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

• Numero di connessioni
• Frequenza
• Utilizzo CPU

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

Modalità di bilanciamento delle connessioni

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

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

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

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

Tabella: capacità 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
Endpoint NNEG H a livello di zona in stato integro	max-connections-per-endpoint=X	X × N	(X × N)/H
Gruppi di istanze (tranne i gruppi di istanze gestite a livello di regione) H Istanze sane	max-connections=Y	Y	Y/H

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

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

Modalità di bilanciamento delle tariffe

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

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

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

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

Tabella: capacità 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
Nendpoint H NEG a livello di zona in stato integro	max-rate-per-endpoint=X	X × N	(X × N)/H
Gruppi di istanze (tranne i gruppi di istanze gestite a livello di regione) H istanze integre	max-rate=Y	Y	Y/H

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

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

Modalità di bilanciamento dell'utilizzo

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

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

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

Modificare la modalità di bilanciamento di un bilanciatore del carico

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

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

Modalità di bilanciamento e impostazioni della capacità target

Per i prodotti che supportano una specifica della capacità target, la capacità target non è un interruttore di sicurezza. Se la capacità target massima configurata è raggiunte in una determinata zona, le nuove richieste o connessioni vengono distribuite zone che non elaborano richieste o connessioni alla capacità target. Se tutte le zone hanno raggiunto la capacità target, le nuove richieste o connessioni sono distribuite per via di un eccesso di informazioni.

Bilanciatori del carico delle applicazioni e Cloud Service Mesh

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

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

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

Bilanciatori del carico di rete proxy

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

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

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

Bilanciatori del carico di rete passthrough

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

Tabella: combinazioni di modalità di bilanciamento e capacità di destinazione Per i bilanciatori del carico di rete passthrough

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

Scaler della capacità

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

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

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

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

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

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

I seguenti esempi mostrano come funziona lo 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 scalare della capacità è 1.0, la capacità disponibile è anche 80 RPS.

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

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

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

Criterio di bilanciamento del carico del servizio

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

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

Inoltre, puoi designare backend specifici come backend preferiti. Questi i backend devono essere utilizzati per la capacità (vale a dire, la capacità target specificata alla modalità di bilanciamento del backend) prima che le richieste vengano inviate all'istanza di backend.

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

Criterio di bilanciamento del carico per le località

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

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

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

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

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

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

• ORIGINAL_DESTINATION: il bilanciatore del carico seleziona un backend in base alla e metadati della connessione client. Le connessioni vengono aperte verso la destinazione originale Indirizzo IP specificato nella richiesta client in entrata, prima che la richiesta fosse viene reindirizzato al bilanciatore del carico.

  ORIGINAL_DESTINATION non è supportato per le lingue globali e di Application Load Balancer esterni regionali.

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

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

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

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

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

Tieni presente che il valore predefinito effettivo del criterio per le località di bilanciamento del carico (localityLbPolicy) cambia in base all'affinità sessione impostazioni. Se l'affinità sessione non è configurata, ovvero se di affinità rimane sul valore predefinito di NONE, il valore Il valore predefinito di localityLbPolicy è ROUND_ROBIN. Se l'affinità di sessione è impostata su un valore diverso da NONE, il valore predefinito per localityLbPolicy è MAGLEV.

Per configurare un criterio per le località di bilanciamento del carico, puoi utilizzare Console Google Cloud, gcloud (--locality-lb-policy) o l'API (localityLbPolicy).

Cloud Service Mesh e distribuzione del traffico

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

I servizi di backend 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 frequenza massima, una frequenza massima per istanza o una frequenza massima per endpoint.

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

Creazione secondaria di backend

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

L'impostazione secondaria di backend è supportata per:

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

Sottoinsieme di backend per bilanciatori del carico delle applicazioni interni regionali

Anteprima

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

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

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

Se attivi i sottoinsiemi, ogni proxy apre connessioni solo a un sottoinsieme di backend, riducendo il numero di connessioni mantenute aperte per ciascun backend. Ridurre il numero di connessioni aperte contemporaneamente a ciascun backend le prestazioni dei backend e dei proxy possono migliorare.

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

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

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

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

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

• Sebbene la sottoimpostazione del backend sia progettata per garantire che tutte le istanze di backend rimangano ben utilizzate, può introdurre un certo bias nella quantità di traffico che ciascun backend riceve. L'impostazione di localityLbPolicy su LEAST_REQUEST è consigliato per i servizi di backend sensibili al bilanciamento del backend caricamento.
• L'attivazione e la disattivazione del sottoinsieme interrompe le connessioni esistenti.
• La creazione di sottoinsiemi di backend richiede che l'affinità sessione sia NONE (un hash a 5 tuple). Le altre opzioni di affinità della sessione possono essere utilizzate solo se il sottoinsieme di backend è disabilitato. I valori predefiniti di --subsetting-policy e I flag --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

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

Per informazioni su come l'impostazione secondaria influisce su questo limite, consulta la sezione "Backend servizi" delle quote delle risorse di bilanciamento del carico limiti.

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

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

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

Senza la suddivisione in sottoinsiemi, viene utilizzato meglio l'insieme completo di backend integre e le nuove connessioni client sono distribuite tra tutti i backend integre alla distribuzione del traffico. Impostazione secondaria impone restrizioni sul bilanciamento del carico, ma consente al bilanciatore del carico di supportare più di 250 backend.

Per le istruzioni di configurazione, consulta Subsetting.

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

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

Prezzi dei sottoinsiemi di backend

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

Affinità sessione

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

I bilanciatori del carico Google Cloud offrono l'affinità sessione secondo il criterio del "best effort" base. Fattori come la modifica degli stati del controllo di integrità del backend, l'aggiunta o la rimozione di backend, le modifiche ai pesi del backend (inclusa l'abilitazione o la disattivazione del bilanciamento ponderato) o le modifiche al grado di saturazione del backend, misurato dalla modalità di bilanciamento, possono interrompere l'affinità della sessione.

Il bilanciamento del carico con l'affinità sessione funziona bene in presenza di un'entità abbastanza grande distribuzione di connessioni univoche. Abbastanza grande significa che almeno diversi moltiplicata per il numero di backend. Test di un bilanciatore del carico con un numero ridotto di connessioni non produrranno una rappresentazione accurata della distribuzione delle connessioni client tra i backend.

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

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

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

• Indica se le connessioni stabilite persistono su backend non integri. Per maggiori dettagli, consulta la documentazione sulla persistenza della connessione su backend non integri nel bilanciatore del carico di rete passthrough interno e la documentazione sulla persistenza della connessione su backend non integri nel bilanciatore del carico di rete passthrough esterno basato sul servizio di backend.
• Indica se le connessioni stabilite persistono durante il failover e il failback, se è configurato un criterio di failover. Per maggiori dettagli, consulta Svuotamento della connessione attivo failover e failback nel bilanciatore del carico di rete passthrough interno documentazione e lo svuotamento della connessione durante il failover e il failover nel backend bilanciatore del carico di rete passthrough esterno basato su servizio documentazione.
• Per quanto tempo possono rimanere le connessioni stabilite quando si rimuove un backend da tramite il bilanciatore del carico. Per maggiori dettagli, vedi Attivazione della connessione drenaggio.

Per i bilanciatori del carico basati su proxy, purché il numero di backend in stato integro le istanze o gli endpoint rimangono costanti, a condizione che l'istanza selezionata in precedenza l'istanza o l'endpoint di backend non ha raggiunto la capacità massima, le richieste successive o le connessioni vanno alla stessa VM di backend o allo stesso endpoint. La capacità target della modalità di bilanciamento determina quando il backend ha raggiunto la capacità.

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

Tabella: impostazioni di affinità sessione supportate

Prodotto	Opzioni di affinità sessione
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni esterno regionale	Nessuno (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE) Campo intestazione (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Affinità basata sui cookie stateful (STRONG_COOKIE_AFFINITY) (anteprima) Tieni inoltre presente quanto segue: Il valore predefinito effettivo del criterio per le località di bilanciamento del carico (localityLbPolicy) cambia in base alla tua sessione impostazioni di affinità. Se l'affinità di sessione non è configurata, ovvero se rimane al valore predefinito NONE, il valore predefinito per localityLbPolicy è ROUND_ROBIN. Se l'affinità sessione è impostata su un valore diverso da NONE, Il valore predefinito di localityLbPolicy è MAGLEV. Per il bilanciatore del carico delle applicazioni esterno globale, non configurare l'affinità sessione se stai utilizzando la suddivisione del traffico ponderata. In questo caso, il traffico ponderato configurazione di suddivisione 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) Affinità basata sui cookie stateful (STRONG_COOKIE_AFFINITY) (anteprima) Nota anche: Il valore predefinito effettivo del criterio di bilanciamento del carico per le località (localityLbPolicy) varia in base alle impostazioni di affinità della sessione. Se l'affinità di sessione non è configurata, ovvero se rimane al valore predefinito NONE, il valore predefinito per localityLbPolicy è ROUND_ROBIN. Se l'affinità di 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 stai utilizzando 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à di sessione, consulta la panoramica del bilanciatore del carico di rete passthrough interno.
Bilanciatore del carico di rete passthrough esterno^*	Nessuno (NONE) IP client, IP di destinazione (CLIENT_IP) IP client, IP di destinazione, Protocollo (CLIENT_IP_PROTO) IP client, porta client, IP di destinazione, porta di destinazione, protocollo (CLIENT_IP_PORT_PROTO) Per informazioni specifiche sul bilanciatore del carico di rete passthrough esterno e sull'affinità di sessione, consulta la panoramica del bilanciatore del carico di rete passthrough esterno TCP/UDP.
Bilanciatore del carico di rete proxy esterno globale Bilanciatore del carico di rete proxy classico Bilanciatore del carico di rete proxy esterno regionale Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy interno tra regioni	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 dal backend basato sui servizi bilanciatori del carico di rete passthrough esterni. Bilanciatori del carico di rete passthrough esterni basati su pool di destinazione e non utilizzano servizi di backend. Devi invece impostare l'affinità di sessione per i bilanciatori del carico di rete passthrough esterni tramite il parametro sessionAffinity in Pool di destinazione.

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

• Non fare affidamento sull'affinità di sessione per scopi di autenticazione o sicurezza. Affinità sessione, tranne sessione basata su cookie stateful affinità, è progettato per interrompersi ogni volta di modifiche al numero di modifiche di gestione e backend integre. Le attività che comportano la violazione dell'affinità di sessione includono:

  • Aggiunta di gruppi di istanze o NEG di backend al servizio di backend
  • Rimozione dei gruppi di istanza di backend o NEG dal servizio di backend
  • Aggiunta di istanze a un gruppo di istanze di backend esistente (operazione che avviene automaticamente quando attivi la scalabilità automatica con i gruppi di istanze gestite)
  • Rimuovere istanze da un gruppo di istanza di backend esistente (operazione che avviene automaticamente quando abiliti la scalabilità automatica con i gruppi di istanze gestite)
  • Aggiunta di endpoint a un NEG di backend esistente
  • Rimozione di 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 failback, se è configurato un criterio di failover
  • Per i bilanciatori del carico proxy: quando un backend ha raggiunto o superato la capacità

• Utilizzo di un'affinità sessione diversa da None con UTILIZATION la modalità di bilanciamento non è consigliata. Questo perché le modifiche all'utilizzo dell'istanza possono causare il reindirizzamento di nuove richieste o connessioni alle VM di backend meno piene da parte del servizio di bilanciamento del carico. Questo interrompe l'affinità sessione. Utilizza invece la modalità di bilanciamento RATE o CONNECTION per ridurre la probabilità di interrompere l'affinità sessione. Per ulteriori dettagli, consulta la sezione Perdere affinità sessione.

• Per i bilanciatori del carico HTTP(S) esterni e interni, l'affinità sessione può essere non funzionante quando l'endpoint o l'istanza previsto supera la durata della modalità di bilanciamento target massimo. 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, ciascun endpoint sta elaborando 1,1, 0,8 e 1,6 RPS, rispettivamente.
  • Quando una richiesta HTTP con affinità per l'ultimo endpoint arriva al carico bilanciatore del carico, l'affinità sessione richiede che l'endpoint in fase di elaborazione sia 1,6 RPS.
  • La nuova richiesta potrebbe andare all'endpoint intermedio con 0,8 RPS.

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

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

IP client, nessuna affinità di destinazione

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

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

Affinità IP client

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

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

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

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

• L'indirizzo IP di origine del pacchetto potrebbe non corrispondere a un indirizzo IP associato a il client originale se il pacchetto viene elaborato da un NAT intermedio prima della consegna a un bilanciatore del carico Google Cloud. Nella situazioni in cui molti client condividono lo stesso indirizzo IP di origine effettivo, le VM di backend potrebbero ricevere più connessioni o richieste di altre.

Affinità cookie generata

Quando utilizzi l'affinità basata su cookie generata, il bilanciatore del carico include un cookie HTTP nell'intestazione di risposta Set-Cookie di una richiesta HTTP iniziale.

Il nome del cookie generato varia a seconda del tipo di caricamento con il bilanciatore del carico di rete passthrough esterno regionale. I seguenti prodotti supportano i cookie generati:

Prodotto	Nome cookie
Bilanciatori del carico delle applicazioni esterni globali	GCLB
Bilanciatori del carico delle applicazioni classici	GCLB
Bilanciatori del carico delle applicazioni esterni regionali	GCILB
Bilanciatori del carico delle applicazioni interni tra regioni	GCILB
Bilanciatori del carico delle applicazioni interni regionali	GCILB
Cloud Service Mesh	GCILB

L'attributo del percorso del cookie generato è sempre una barra (/), quindi viene applicato a tutte di backend sulla stessa mappa URL, a condizione che gli altri servizi di backend usano anche affinità cookie generato.

Puoi configurare la durata (TTL) del cookie tra il giorno 0 e il giorno 86400 secondi (inclusi). Poiché un cookie generato con un TTL di zero secondi scade immediatamente, è utile solo come identificatore di sessione univoco e non fornisce alcuna affinità per le richieste HTTP successive.

Quando il cliente include il cookie di affinità sessione generato nell'Cookie delle richieste HTTP successive, il bilanciatore del carico le indirizza di richieste alla stessa istanza di backend o allo stesso endpoint, purché la sessione il cookie di affinità rimane valido. Per farlo, viene mappato il valore del cookie a un indice che fa riferimento a un'istanza di backend o a un endpoint specifici e assicurandosi che i requisiti di affinità sessione dei cookie generati siano soddisfatti.

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

• Per i gruppi di istanze di backend, utilizza la modalità di bilanciamento RATE.
• Per il localityLbPolicy del servizio di backend, utilizza RING_HASH o MAGLEV. Se non imposti esplicitamente localityLbPolicy, il bilanciatore del carico utilizza MAGLEV come impostazione predefinita implicita.

Inoltre, l'affinità cookie generato richiede che il numero di le istanze di backend o gli endpoint in stato integro rimangono costanti sul backend completamente gestito di Google Cloud.

L'affinità sessione per alcuni client si interrompe per i seguenti motivi:

• Il numero di endpoint o istanze di backend configurati e operativi cambia. L'aggiunta o la rimozione di istanze o endpoint di backend influisce sul calcolo dei valori dell'indice. Se il numero di valori dell'indice cambia, l'affinità della sessione può essere interrotta perché un hash potrebbe essere mappato a un indice diverso o un indice potrebbe fare riferimento a un backend diverso o a entrambi.

  Il numero di istanze o endpoint di backend configurati e operativi cambia quando si verificano le seguenti condizioni:

  • Aggiungi gruppi di istanze di backend o NEG non vuoti al servizio di backend.
  • Rimuovi i gruppi di istanza di backend o i NEG esistenti dal backend completamente gestito di Google Cloud.
  • Puoi aggiungere istanze all'istanza di backend esistente o rimuoverle dall'istanza di backend esistente. gruppi sul servizio di backend.
  • Aggiungi o rimuovi endpoint dai NEG di backend esistenti sul servizio di backend.
  • Le istanze o gli endpoint esistenti non superano i controlli di integrità, passando da da uno a uno.
  • Le istanze o gli endpoint esistenti superano i controlli di integrità, passando da stato non integro a stato integro.
  • Combinazioni di due o più elementi precedenti.

• Un endpoint o un'istanza di backend selezionata in precedenza diventa piena raggiungendo la sua capacità target.

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: sono vere:

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

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

Affinità cookie HTTP

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

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

• Bilanciatori del carico delle applicazioni esterni globali
• Bilanciatori del carico delle applicazioni classici
• Bilanciatori del carico delle applicazioni esterni regionali
• Bilanciatori del carico delle applicazioni interni tra regioni
• Bilanciatori del carico delle applicazioni interni regionali
• Cloud Service Mesh

Puoi configurare i valori TTL dei cookie. I valori TTL validi sono compresi tra:

• 0 e 315576000000 (inclusi), se specificati in secondi.
• 0 e 999999999 (inclusi), se specificato in nanosecondi.

Poiché un cookie HTTP con un TTL di zero secondi scade immediatamente, il cookie è utile solo come identificatore di sessione univoco: non fornisce alcuna affinità per le richieste HTTP successive.

Quando il client include il cookie di affinità sessione HTTP nell'elemento Cookie delle richieste HTTP successive, il bilanciatore del carico le indirizza di richieste alla stessa istanza di backend o allo stesso endpoint, purché la sessione il cookie di affinità rimane valido. Ciò viene fatto mappando il valore del cookie a un indice che fa riferimento a un'istanza o a un endpoint del backend specifico e assicurandosi che i requisiti di affinità della sessione del cookie generati siano soddisfatti.

Per utilizzare l'affinità dei cookie HTTP, configura il seguente bilanciamento modalità e impostazioni di localityLbPolicy:

• Per i gruppi di istanza di backend, utilizza la modalità di bilanciamento RATE.
• Per localityLbPolicy del servizio di backend, utilizza RING_HASH o MAGLEV. Se non imposti esplicitamente localityLbPolicy, il bilanciatore del carico utilizza MAGLEV come valore predefinito implicito.

Inoltre, l'affinità dei cookie HTTP richiede che il numero di endpoint o istanze di backend configurati e in buono stato rimanga costante nel servizio di backend. L'affinità di sessione per alcuni client si interrompe per i seguenti motivi:

• Il numero di endpoint o istanze di backend configurati e operativi vari. L'aggiunta o la rimozione di istanze o endpoint di backend influisce sul calcolo dei valori dell'indice. Se il numero di valori dell'indice cambia, la sessione affinità può interrompere perché un hash potrebbe mappare a un indice diverso, o potrebbero riferirsi a backend diversi o a entrambi.

  Il numero di istanze o endpoint di backend configurati e operativi cambia quando si verificano le seguenti condizioni:

  • Aggiungi gruppi di istanze di backend o NEG non vuoti al servizio di backend.
  • Rimuovi i gruppi di istanza di backend o i NEG esistenti dal backend completamente gestito di Google Cloud.
  • Puoi aggiungere istanze all'istanza di backend esistente o rimuoverle dall'istanza di backend esistente. gruppi sul servizio di backend.
  • Aggiungi o rimuovi endpoint dai NEG di backend esistenti sul servizio di backend.
  • Le istanze o gli endpoint esistenti non superano i controlli di integrità, passando da da uno a uno.
  • Le istanze o gli endpoint esistenti superano i controlli di integrità, passando da stato non integro a stato integro.
  • Combinazioni di due o più elementi precedenti.

• Un endpoint o un'istanza di backend selezionata in precedenza diventa piena raggiungendo la sua capacità target.

Affinità sessione basata su cookie stateful

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.

Quando utilizzi l'affinità basata sui cookie stateful, il bilanciatore del carico include una Cookie HTTP nell'intestazione della risposta Set-Cookie di una richiesta HTTP iniziale. Specifica il nome, il percorso e il tempo di vita (TTL) del cookie.

I seguenti bilanciatori del carico supportano l'affinità stateful basata sui cookie:

• Bilanciatori del carico delle applicazioni esterni globali
• Bilanciatori del carico delle applicazioni esterni regionali
• Bilanciatori del carico delle applicazioni interni tra regioni
• Bilanciatori del carico delle applicazioni interni regionali

Puoi configurare i valori TTL del cookie. I valori TTL validi sono compresi tra:

• 0 e 315576000000 (inclusi), se specificati in secondi.
• 0 e 999999999 (inclusi), se specificato in nanosecondi.

Poiché un cookie con un TTL di zero secondi scade immediatamente, il parametro è utile solo come identificatore di sessione univoco e non fornisce per le successive richieste HTTP.

Il valore del cookie identifica un'istanza di backend o un endpoint selezionati tramite che codifica l'istanza o l'endpoint selezionato nel valore stesso. Finché il cookie è valido, se il client include il cookie di affinità alla sessione nell'intestazione della richiesta Cookie delle richieste HTTP successive, il bilanciatore del carico indirizza queste richieste all'istanza o all'endpoint di backend selezionato.

L'affinità basata sui cookie stateful non ha requisiti specifici per la modalità di bilanciamento o localityLbPolicy.

L'affinità basata sui cookie stateful richiede che l'istanza di backend selezionata l'endpoint rimane configurato e integro. L'affinità di sessione per alcuni client si interrompe per i seguenti motivi:

• Il gruppo di istanza di backend o NEG che contiene l'istanza o il NEG dell'endpoint viene rimosso dal servizio di backend.
• L'istanza o l'endpoint selezionato viene rimosso dal relativo gruppo di istanza di backend o NEG.
• L'istanza o l'endpoint selezionato non supera i controlli di integrità.

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 istanze di backend o il NEG a livello di zona esaurisce la capacità, come definito dalla capacità target della modalità di bilanciamento. In questo caso, Google Cloud indirizza il traffico a un gruppo di istanze di backend o a un NEG zonale diverso, che potrebbe trovarsi in una zona diversa. Puoi mitigare questo problema assicurandoti di specificare la capacità target 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, pertanto il servizio di backend ricalcola gli hash per l'affinità di sessione. Tu può mitigare questo problema assicurando che la dimensione minima dell'istanza gestita in grado di gestire un carico tipico. a questo punto viene eseguita solo 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 di ciascun bilanciatore del carico Google Cloud per informazioni dettagliate sul comportamento del bilanciatore del carico quando tutti i relativi backend non superano i controlli di integrità.
• Quando la modalità di bilanciamento UTILIZATION è attiva per i gruppi di istanze di backend, l'affinità sessione viene interrotta a causa delle modifiche all'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 proxy esterni, tieni presente i seguenti punti aggiuntivi:

• Se il percorso di routing da un client su internet a Google cambia tra richieste o connessioni, potrebbe essere selezionato un Google Front End (GFE) diverso come proxy. Questo può interrompere l'affinità sessione.
• Quando utilizzi la modalità di bilanciamento UTILIZATION, in particolare senza una capacità massima target definita, l'affinità di sessione potrebbe interrompersi quando il traffico verso il bilanciatore del carico è basso. Passa alla modalità di bilanciamento RATE o CONNECTION, come supportato 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 i bilanciatori del carico delle applicazioni esterni e interni che utilizzano il protocollo HTTP, HTTPS o HTTP/2, il timeout del servizio di backend è un timeout di richiesta e risposta per il traffico HTTP(S).

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

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

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

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

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

Controlli di integrità

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

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

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

Per ulteriori informazioni, leggi i seguenti documenti:

• Panoramica dei controlli di integrità
• Creazione di controlli di integrità
• gcloud pagina del controllo di integrità
• Pagina 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 distribuire i contenuti più vicino agli utenti, al fine di velocizzare i siti web e le applicazioni. Cloud CDN è attivato sui servizi di backend utilizzati dai bilanciatori del carico delle applicazioni esterni globali. Il bilanciatore del carico fornisce le porte e gli indirizzi IP frontend che ricevono le richieste e i backend che rispondono alle richieste.

Per ulteriori dettagli, consulta la documentazione di Cloud CDN.

Cloud CDN non è compatibile con IAP. Non è possibile abilitato per lo stesso servizio di backend.

Google Cloud Armor

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

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

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

• Seleziona un criterio di sicurezza di Google Cloud Armor esistente.
• Accetta la configurazione di un criterio di sicurezza di Google Cloud Armor con limitazione della frequenza predefinito con un nome, un conteggio delle richieste, un intervallo, una chiave e parametri di limitazione della frequenza personalizzabili. Se utilizzi Google Cloud Armor con un upstream come 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 definire un livello di autorizzazione centrale per le applicazioni accessibili tramite HTTPS, che ti permette di utilizzare un modello di controllo dell'accesso a livello di applicazione invece di dover fare affidamento su firewall a livello di rete. IAP è supportato da determinate Bilanciatori del carico delle applicazioni.

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

Funzionalità avanzate di gestione del traffico

Per scoprire di più sulle funzionalità di gestione avanzata del traffico che sono configurate nella per i servizi di backend e le mappe URL associati ai bilanciatori del carico, consulta quanto segue:

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

Riferimento API e gcloud

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

• API del servizio di backend globale risorsa

• API del servizio di backend regionale risorsa

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

Passaggi successivi

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

• Crea intestazioni personalizzate
• Creare 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