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, come usato per la connessione a backend, varie distribuzioni e sessioni impostazioni, 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 configurazione. Un servizio di backend è globale o nell'ambito di ciascuna regione.

I bilanciatori del carico, i proxy Envoy e i client gRPC senza proxy utilizzano la 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 per ogni backend.
• Determina quale controllo di integrità viene monitorato l'integrità dei backend.
• Specifica l'affinità sessione.
• Determina se sono abilitati altri servizi, tra cui: disponibili solo per determinati carichi di lavoro bilanciatori:
  .
  • Cloud CDN
  • Criteri di sicurezza di Google Cloud Armor
  • Identity-Aware Proxy
• Designa i servizi di backend regionali come servizi in App Hub, ovvero in anteprima.

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

Nota: se utilizzi il bilanciatore del carico delle applicazioni esterno globale o dell'Application Load Balancer classico e i tuoi backend gestiscono contenuti statici, prendi in considerazione utilizzando i bucket di backend anziché dai servizi di backend.

La tabella seguente riassume i bilanciatori del carico che utilizzano i servizi di backend. La del prodotto che stai utilizzando determina anche il numero massimo i servizi, l'ambito di un servizio di backend, il tipo di backend supportati e 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. Ciascuna Il prodotto di bilanciamento del carico utilizza uno schema di bilanciamento del carico per le relative regole di forwarding e 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ù 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 ^† Tutti i NEG serverless: uno o più App Engine, Cloud Run, o i servizi Cloud Functions 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 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 ibrido: GCE_VM_IP_PORT e NON_GCP_PRIVATE_IP_PORT di tipo NEG ^† Tutti i NEG serverless: uno o più App Engine, Cloud Run, o servizi 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 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 a livello di regione per un backend esterno	EXTERNAL_MANAGED
Bilanciatore del carico delle applicazioni interno tra regioni	Multiplo	Globale	Ogni servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend 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 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ù 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) Un singolo NEG Private Service Connect Tutti i NEG internet a livello di regione per un backend esterno	INTERNAL_MANAGED
Bilanciatore del carico di rete proxy esterno globale	1		Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più 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 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ù 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 ^†	EXTERNAL
Bilanciatore del carico di rete proxy esterno regionale	1	Regionale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend di gruppi di istanze: uno o più 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 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ù 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 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 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 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 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 a livello di zona NEG	EXTERNAL
Bilanciatore del carico di rete passthrough interno	1	A livello di regione, ma configurabile in modo da essere accessibile a livello globale	Il servizio di backend supporta una delle seguenti combinazioni di backend: Tutti i backend 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 a livello di zona NEG Un NEG di mappatura delle porte (anteprima)	INTERNAL
Cloud Service Mesh	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ù GCE_VM_IP_PORT o Tipo di NON_GCP_PRIVATE_IP_PORT NEG a livello di zona Un NEG internet di tipo INTERNET_FQDN_PORT Una o più associazioni di servizi	INTERNAL_SELF_MANAGED

^* Backend usati dai bilanciatori del carico delle applicazioni classici I bilanciatori del carico di rete proxy classici hanno sempre un ambito globale, in Standard o Livello di rete 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 connessi al servizio di backend devono trovarsi nella stessa località come regola di forwarding.

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

^‡ Supportano IPv4 e Gruppi di istanze IPv6 (a doppio stack) e backend NEG a livello di zona. Assistenza per NEG a livello di zona dual stack solo su 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'istanza gestita (MIG), con o senza scalabilità automatica oppure può essere una istanza non gestita gruppo. Più di un servizio di backend può fare riferimento a un gruppo di istanze, ma tutti i servizi di backend i servizi 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 dei servizi Service Directory

Non puoi eliminare un gruppo di istanza di backend o un NEG associato a un di 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 hanno bisogno di indirizzi IP esterni:

• Per i bilanciatori del carico delle applicazioni esterni globali e bilanciatori del carico di rete proxy esterni: i client comunicano con un Google Front End (GFE), che che ospita l'indirizzo IP esterno del tuo 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. Comunicazione tra GFE e VM di backend tramite speciali route.
  • Per i backend di gruppi di istanze, il protocollo IPv4 interno è sempre l'indirizzo IPv4 interno primario che corrisponde interfaccia nic0 della VM.
  • Per GCE_VM_IP_PORT endpoint in un NEG a livello di zona, puoi specificare il indirizzo IP dell'endpoint come indirizzo IPv4 principale associato a interfaccia di rete di una VM o qualsiasi indirizzo IPv4 da un intervallo di indirizzi IP alias associati 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. Proxy Envoy comunicare con endpoint o VM di backend inviando pacchetti a un server indirizzo creato unendo un identificatore per il 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 GCE_VM_IP_PORT endpoint in un NEG a livello di zona, puoi specificare il indirizzo IP dell'endpoint come indirizzo IPv4 principale associato a interfaccia di rete di una VM o qualsiasi indirizzo IPv4 da un intervallo di indirizzi IP alias associati a qualsiasi interfaccia di rete di una VM, purché la rete si trova nella stessa rete del bilanciatore del carico.

• Per i bilanciatori del carico di rete passthrough esterni: i client comunicano direttamente con i backend del Maglev di Google di bilanciamento del carico passthrough. I pacchetti vengono indirizzati e consegnati ai backend con il codice sorgente originale e mantenere gli indirizzi IP di destinazione. I backend rispondono ai client usando reso del server web. I metodi utilizzati per selezionare un backend e monitorare le connessioni sono configurabile.

  • Per i backend di gruppi di istanze, i pacchetti vengono sempre consegnati all'nic0 all'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 al carico del proxy utilizzando backend di gruppi di istanze. La porta denominata definisce la destinazione porta utilizzata per la connessione TCP tra il proxy (GFE o Envoy) e di istanza di backend.

Le porte denominate sono configurate come segue:

• Sul backend di ogni gruppo di istanze, devi configurare una o più porte con nome 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 backend.

• 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 al backend del servizio --port-name, il servizio di backend utilizza questo numero di porta per la comunicazione con le VM del gruppo di istanze.

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

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

Quindi fai riferimento alla porta denominata nella configurazione del servizio di backend con --port-name 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 utilizzato 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. NEG a livello di zona con GCE_VM_IP_PORT endpoint, NEG ibridi con NON_GCP_PRIVATE_IP_PORT e i NEG internet definiscono le porte utilizzando un meccanismo diverso, ovvero sugli endpoint stessi. I NEG serverless fanno riferimento ai servizi Google e a PSC I NEG fanno riferimento ai collegamenti ai servizi che utilizzano astrazioni che non implicano che specifica 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. Pacchetti vengono consegnati ai backend che conservano l'indirizzo IP e la porta la regola di forwarding del bilanciatore del carico.

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

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

Limitazioni e linee guida per i gruppi di istanze

Quando crei l'istanza, tieni presenti le restrizioni e le indicazioni seguenti 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 verso specifiche, specifica le porte denominate richieste su uno gruppo di istanze e fare in modo che ogni servizio di backend si abboni a un .

• 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 o devono essere una combinazione di CONNECTION e RATE.

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

  • CONNECTION con UTILIZATION
  • RATE con UTILIZATION

  Considera il seguente esempio:

  • Hai due servizi di backend: external-https-backend-service per un un bilanciatore del carico delle applicazioni esterno e internal-tcp-backend-service per un il 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 usare instance-group-a anche in external-https-backend-service se applicherai la modalità di bilanciamento RATE in external-https-backend-service.
  • Non puoi utilizzare anche instance-group-a in external-https-backend-service con la modalità di bilanciamento UTILIZATION.

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

  • Rimuovi il gruppo di istanze da tutti i servizi di backend tranne uno.
  • Cambia la modalità di bilanciamento per il backend sull'unico servizio di backend rimanente.
  • Aggiungi nuovamente il gruppo di istanze come backend per i 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. Questo potrebbe causare danni imprevedibili e delle istanze nel gruppo, soprattutto se utilizzi il protocollo HTTP Load Metrica di scalabilità automatica Utilizzo del bilanciamento.

  • Sebbene non sia consigliabile, questo scenario potrebbe funzionare se la scalabilità automatica è Utilizzo della CPU o Metrica di Cloud Monitoring che non è correlato alla capacità di gestione del carico. L'utilizzo di uno di questi 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 un indirizzo IP e di porte, 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) a livello di zona sono a livello di zona che rappresentano raccolte di indirizzi IP o di indirizzi e porte per le risorse Google Cloud all'interno di un una subnet.

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

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

• GCE_VM_IP endpoint (supportato solo con bilanciatori del carico di rete passthrough interni e backend bilanciatori del carico di rete passthrough esterni basati su servizi).
• 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, consulta NEG a livello di zona Panoramica.

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 internet è una combinazione di un nome host o di un indirizzo IP, più un 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: globali e a livello di regione. Per vedere quali supportano i backend NEG internet in ogni ambito, consulta Tabella: 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, Cloud Functions, 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 Cloud Functions o un gruppo di funzioni.
• Un'app App Engine (Standard o Flex), un servizio specifico all'interno di un'app, una specifica versione di un'app o un gruppo di servizi.
• Un gateway API che fornisce l'accesso ai tuoi servizi tramite una API REST e coerente in tutti i servizi, indipendentemente dalla sua implementazione. Questa funzionalità è in Anteprima.

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

Per configurare un NEG serverless per le applicazioni serverless che condividono un URL pattern, utilizzi un URL maschera. 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, Cloud Functions 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 Endpoint di rete serverless Panoramica dei gruppi.

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

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

• Un singolo servizio di backend non può utilizzare contemporaneamente entrambe le istanze e i NEG a livello di zona.
• Puoi utilizzare una combinazione di tipi di gruppi di istanze diversi sulla stessa di servizio di backend. Ad esempio, un singolo servizio di backend può fare riferimento a un dei gruppi di istanze gestite e non gestite. Per completamento e informazioni su quali backend sono compatibili con i vari servizi di backend, consulta la tabella nella sezione precedente.
• Con determinati bilanciatori del carico proxy, puoi utilizzare una combinazione di NEG a livello di zona (con GCE_VM_IP_PORT endpoint) e NEG di connettività ibrida (con NON_GCP_PRIVATE_IP_PORT endpoint) per configurare il bilanciamento del carico ibrido. Per vedere quali bilanciatori del carico dispongono di questa funzionalità, consulta la Tabella: Backend e tipi di backend supportati.

Protocollo ai backend

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

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

Tabella: protocollo ai backend

Prodotto	Opzioni del protocollo del servizio di backend
Bilanciatore del carico delle applicazioni	HTTP, HTTPS, HTTP/2
Bilanciatore del carico di rete proxy	TCP o SSL I bilanciatori del carico di rete del proxy regionale supportano solo TCP.
Bilanciatore del carico di rete passthrough	TCP, UDP o UNSPECIFIED
Cloud Service Mesh	HTTP, HTTPS, HTTP/2, gRPC, TCP

La modifica del protocollo di un servizio di backend rende i backend inaccessibili tramite 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 dell'indirizzo IP per specificare il tipo di traffico inviate dal servizio di backend ai tuoi backend.

Quando selezioni il criterio di selezione degli indirizzi IP, assicurati che i backend per supportare 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 Convertire i bilanciatori del carico in backend a doppio stack.

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

Criterio di selezione degli indirizzi IP	Descrizione
Solo IPv4	Invia solo traffico IPv4 ai backend del servizio di backend, 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 altre connessioni. Il GFE tenta prima la connessione IPv6. se il protocollo IPv6 la connessione è interrotta o lenta, occhi felici per eseguire il fallback e la connessione a IPv4. Anche se una delle connessioni IPv6 o IPv4 non è integro, il backend trattate come integre ed entrambe le connessioni possono essere provate dal GFE, con occhi felici che alla fine scelgono quale usare.
Solo IPv6	Invia solo traffico IPv6 ai backend del servizio di backend, a prescindere dal traffico dal client al proxy. Solo IPv6 per controllare l'integrità dei backend. Non esiste una convalida per verificare se il tipo di traffico di backend corrisponde alla Criterio di selezione dell'indirizzo IP. Ad esempio, se hai backend IPV4 seleziona Only IPv6 come criterio di selezione degli indirizzi IP, non potrai o non osservare errori di configurazione, ma il traffico non arriva al tuo di backend.

Crittografia tra il bilanciatore del carico e i backend

Per informazioni sulla crittografia tra il bilanciatore del carico e i backend, consulta La crittografia di 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 il modo in cui il bilanciatore del carico misura l'idoneità del backend per le nuove richieste o connessioni.
• Una capacità target definisce un numero massimo di connessioni target. una frequenza massima target o l'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 sono completamente caricati. Google Cloud prevede tre modalità di bilanciamento:

• CONNECTION: determina la distribuzione del carico in base al numero totale di e le connessioni che il backend è in grado di 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à capacità superiore a quella massima.
• UTILIZATION: determina la distribuzione del carico in base all'utilizzo di 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 supportare l'impostazione di qualsiasi 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, 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. 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 quindi distribuite in modo round robin tra le istanze o gli endpoint all'interno del backend.

• Per i bilanciatori del carico delle applicazioni esterni globali, viene selezionata una regione in base alla località 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 CONNECTION o Modalità di bilanciamento di UTILIZATION per i backend di gruppi di istanze VM, CONNECTION modalità di bilanciamento per i NEG a livello di zona con GCE_VM_IP_PORT endpoint e CONNECTION modalità di bilanciamento per NEG ibridi (NON_GCP_PRIVATE_IP_PORT endpoint). 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, 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, criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di trasferimento del traffico distribuite alle istanze o agli endpoint all'interno del gruppo.

• Per i bilanciatori del carico di rete proxy interni tra regioni, viene selezionata per prima la regione configurata. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni del numero di richieste 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, criterio di bilanciamento del carico (LocalityLbPolicy) determina la modalità di trasferimento del traffico distribuite alle istanze o agli 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. Quindi, all'interno di una regione, la capacità target della modalità di bilanciamento del carico viene utilizzata per calcolare le proporzioni molte richieste o connessioni devono essere indirizzate a ogni backend (gruppo di istanze o NEG) della 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 devono essere inviate molte richieste 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.

Nella tabella seguente sono riepilogate le modalità di bilanciamento del carico disponibili per ogni bilanciatore del carico e backend.

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

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

Nota:

Se noti una scarsa distribuzione del traffico durante l'utilizzo del parametro UTILIZATION modalità di bilanciamento, 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ò si verificano quando utilizzi gruppi di istanze gestite a livello di regione, istanze gestite a livello di zona, gruppi in zone diverse e gruppi di istanze non gestite a livello di zona. Questo servizio Lo sbilanciamento si risolve automaticamente man mano che più traffico viene inviato al bilanciatore del carico.

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

Capacità target

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

• 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 di CONNECTION, la capacità target definisce un target il numero massimo di connessioni aperte. Fatta eccezione per i bilanciatori del carico di rete passthrough interni e bilanciatori del carico di rete passthrough esterni, devi utilizzare una delle seguenti impostazioni per specificare numero massimo di connessioni target:

• max-connections-per-instance (per VM): media target di connessioni 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 in alternativa.

La tabella seguente mostra in che modo il parametro della capacità target definisce la seguenti:

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

Tabella: capacità di destinazione per i backend che utilizzano la modalità di bilanciamento della connessione

Tipo di backend	Capacità target
	Se specifichi	Intera capacità del backend	Prevista per capacità di istanza o endpoint
Gruppo di istanze N istanze, H in stato integro	max-connections-per-instance=X	X × N	(X × N)/H
NEG a livello di zona N endpoint, H in stato integro	max-connections-per-endpoint=X	X × N	(X × N)/H
Gruppi di istanze (tranne i gruppi di istanze gestite a livello di regione) H istanze integre	max-connections=Y	Y	Y/H

Come illustrato, 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 a livello di zona con N endpoint, l'impostazione max-connections-per-endpoint=X ha lo stesso significato dell'impostazione max-connections=X × N.

Modalità di bilanciamento delle tariffe

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

• max-rate-per-instance (per VM): fornisci un valore HTTP medio target per una singola VM.
• max-rate-per-endpoint (per endpoint in un NEG a livello di zona): fornisci una destinazione percentuale media di richieste HTTP 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 in che modo il parametro della capacità target definisce la seguenti:

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

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

Tipo di backend	Capacità target
	Se specifichi	Intera capacità del backend	Prevista per capacità di istanza o endpoint
Gruppo di istanze N istanze, H in stato integro	max-rate-per-instance=X	X × N	(X × N)/H
NEG a livello di zona N endpoint, H in stato integro	max-rate-per-endpoint=X	X × N	(X × N)/H
Gruppi di istanze (tranne i gruppi di istanze gestite a livello di regione) H istanze integre	max-rate=Y	Y	Y/H

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

• 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 un di opzioni che dipendono dal tipo di backend, come riepilogato la tabella nella 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 nella console Google Cloud per aggiungere un gruppo di istanza di backend a un servizio di backend, La console Google Cloud imposta il valore di max-utilization su 0,8 (80%) se È selezionata la modalità di bilanciamento UTILIZATION. Oltre a max-utilization, La modalità di bilanciamento di UTILIZATION supporta capacità target più complesse, come riassunte nella tabella della sezione seguente.

Modifica della modalità di bilanciamento di un bilanciatore del carico

Per alcuni bilanciatori del carico o configurazioni dei bilanciatori del carico, non puoi modificare 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 di capacità target

Questa tabella riassume tutte le possibili modalità di bilanciamento per un determinato bilanciatore del carico e tipo di backend. Mostra inoltre le impostazioni relative alla capacità disponibile o richiesta devi specificare la modalità di bilanciamento.

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

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

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

Scaler della capacità

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

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

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

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

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

• Il valore predefinito è 1, il che significa che il gruppo pubblica fino al 100% del capacità configurata (a seconda di balancingMode).
• Il valore 0 indica che il gruppo è completamente svuotato e offre lo 0% del suo capacità massima disponibile. Non puoi configurare l'impostazione 0 se c'è solo un backend collegato al servizio di 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, il valore di max-rate è impostato su 80 RPS e lo scaler di capacità è 1.0, la capacità disponibile è anche 80 RPS.

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

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

Nota: lo scaler 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 con il backend del bilanciatore del carico Google Cloud. Ti permette di personalizzare parametri che influenzano la distribuzione del traffico all'interno dei backend associati a un servizio di backend:

• Personalizza l'algoritmo di bilanciamento del carico utilizzato per determinare la modalità di traffico del traffico. distribuiti 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.

Cloud Service Mesh e distribuzione del traffico

Cloud Service Mesh utilizza anche le risorse servizio di backend. In particolare, Cloud Service Mesh utilizza servizi di backend il cui schema di bilanciamento del carico è INTERNAL_SELF_MANAGED. Per un servizio di backend autogestito interno, 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. Quindi, Cloud Service Mesh distribuisce il traffico in base a un criterio di bilanciamento del carico.

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

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

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

Per ulteriori informazioni 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 dei backend è supportata per:

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

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

Anteprima

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

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

Per i bilanciatori del carico delle applicazioni interni regionali, l'impostazione di sottoinsiemi backend assegna automaticamente solo un sottoinsieme dei backend all'interno del servizio di backend regionale a ciascun proxy in esecuzione in un'istanza Compute Engine. 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 sono entrambi di grandi dimensioni e l'apertura di connessioni a tutti i backend o problemi di prestazioni.

Se abiliti l'impostazione secondaria, ogni proxy apre solo le connessioni a un sottoinsieme dei backend, riducendo il numero di connessioni che vengono mantenute aperte 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 inoltre perfezionare il traffico di bilanciamento del carico verso i backend impostando la classe localityLbPolicy criterio. 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.

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

• Sebbene l'impostazione secondaria dei backend sia progettata per garantire che tutte le istanze di backend rimangono ben utilizzati, ciò può introdurre alcuni bias nella quantità di traffico ricevuti da ciascun backend. L'impostazione di localityLbPolicy su LEAST_REQUEST è consigliato per i servizi di backend sensibili al bilanciamento del backend caricamento.
• L'abilitazione e la disattivazione dell'impostazione secondaria interrompe le connessioni esistenti.
• La creazione di sottoinsiemi di backend richiede che l'affinità sessione sia NONE (un hash a 5 tuple). Altre opzioni di affinità sessione possono essere utilizzate solo se l'impostazione secondaria del backend è disattivata. 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

L'impostazione secondaria del backend per i bilanciatori del carico di rete passthrough interni consente di scalare il bilanciatore del carico di rete passthrough interno per supportare un numero maggiore di istanze VM di backend per backend interno completamente gestito di Google Cloud.

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

Il seguente diagramma mostra un modello di scale down della differenza tra questi 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 istruzioni di configurazione, vedi Impostazione secondaria.

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

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

Prezzi di sottoinsiemi di backend

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

Affinità sessione

L'affinità sessione consente di controllare il modo in cui il bilanciatore del carico seleziona i backend delle nuove connessioni in modo prevedibile purché il numero di i backend rimangono costanti. È utile per le applicazioni che necessitano di più applicazioni richieste da un determinato utente di essere indirizzate allo stesso backend o endpoint. Tale di solito includono server stateful utilizzati dalla pubblicazione di annunci, dai giochi con un'intensa memorizzazione nella cache interna.

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, o modifiche alla completezza dei backend, in base a quanto misurato dalla modalità di bilanciamento, interruzione dell'affinità 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 passthrough, le nuove connessioni sono distribuite nell'integrità alle istanze di backend o agli endpoint (nel pool attivo, se un criterio di failover configurato). Puoi controllare:

• Se le connessioni stabilite vengono mantenute su backend in stato non integro. Per maggiori dettagli, consulta Persistenza della connessione su backend in stato non integro nel bilanciatore del carico di rete passthrough interno documentazione e Persistenza della connessione su backend in stato non integro nel backend basato sul servizio documentazione del bilanciatore del carico di rete passthrough esterno esterno.
• Se le connessioni stabilite persistono durante il failover e il failover, nel caso in cui che il criterio di failover sia configurato. 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 del di bilanciamento del carico determina quando il backend ha raggiunto la capacità massima.

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

Tabella: Impostazioni di affinità sessione supportate

Prodotto	Opzioni di affinità sessione
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni esterno regionale	Nessuna (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE) Campo intestazione (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Nota anche: Il valore predefinito effettivo del criterio per le località di bilanciamento del carico (localityLbPolicy) cambia in base alla tua sessione impostazioni di affinità. Se l'affinità sessione non è configurata, ovvero l'affinità sessione rimane sul valore predefinito di NONE, quindi 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) Nota anche: 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à sessione non è configurata, ovvero l'affinità sessione rimane sul valore predefinito di NONE, quindi 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 interno, non configurare l'affinità sessione se stai utilizzando la suddivisione del traffico ponderata. In tal caso, la metrica ponderata configurazione della suddivisione del traffico ha la precedenza.
Bilanciatore del carico di rete passthrough interno	Nessuna (NONE) IP CLIENT, nessuna destinazione (CLIENT_IP_NO_DESTINATION) IP client, IP di destinazione (CLIENT_IP) IP client, IP di destinazione, Protocollo (CLIENT_IP_PROTO) IP client, porta client, IP di destinazione, porta di destinazione, protocollo (CLIENT_IP_PORT_PROTO) Per informazioni specifiche sul bilanciatore del carico di rete passthrough interno e sull'affinità sessione, vedi il Bilanciatore del carico di rete passthrough interno Panoramica.
Bilanciatore del carico di rete passthrough esterno^*	Nessuna (NONE) IP client, IP di destinazione (CLIENT_IP) IP client, IP di destinazione, Protocollo (CLIENT_IP_PROTO) IP client, porta client, IP di destinazione, porta di destinazione, protocollo (CLIENT_IP_PORT_PROTO) Per informazioni specifiche sul bilanciatore del carico di rete passthrough esterno e sull'affinità sessione, vedi il Esterni 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 Network Load Balancer proxy esterno regionale Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy interno tra regioni	Nessuna (NONE) IP client (CLIENT_IP)
Cloud Service Mesh	Nessuna (NONE) IP client (CLIENT_IP) Cookie generato (GENERATED_COOKIE) (solo protocolli HTTP) Campo intestazione (HEADER_FIELD) (solo protocolli HTTP) Cookie HTTP (HTTP_COOKIE) (solo protocolli HTTP)

^* Questa tabella documenta le affinità di sessione supportate 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. Puoi invece impostare l'affinità sessione per bilanciatori del carico di rete passthrough esterni tramite il parametro sessionAffinity in Pool di destinazione.

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

• Non fare affidamento sull'affinità sessione per l'autenticazione o la sicurezza. L'affinità sessione è progettata per interrompersi ogni volta che il numero le modifiche ai backend integri. Attività che comportano l'interruzione dell'affinità sessione include:

  • Aggiunta di gruppi di istanza di backend o NEG al servizio di backend
  • Rimozione dei gruppi di istanza di backend o NEG dal servizio di backend
  • Aggiunta di istanze a un gruppo di istanza di backend esistente (operazione che accade automaticamente quando abiliti 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 degli endpoint da un NEG di backend esistente
  • Quando un backend integro non supera il controllo di integrità e diventa non integro
  • Quando un backend non integro supera il controllo di integrità e diventa integro
  • Per i bilanciatori del carico passthrough: durante il failover e il failover, in caso di il criterio è configurato
  • 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'istanza può far sì che il servizio di bilanciamento del carico indirizzi nuove richieste o a VM di backend meno piene. Viene interrotta l'affinità sessione. Utilizza invece la modalità di bilanciamento RATE o CONNECTION per ridurre la probabilità di 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 centrale con 0,8 RPS.

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

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

IP client, nessuna affinità di destinazione

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

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

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

• Se un client passa da una rete a un'altra, il suo indirizzo IP cambia, con conseguente interruzione dell'affinità.

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

Affinità IP client

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

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

• L'affinità IP client è un hash a due tuple costituito dall'indirizzo IP del client e l'indirizzo IP della regola di forwarding del bilanciatore del carico che il client contatti.

• L'indirizzo IP client visto dal bilanciatore del carico potrebbe non essere client di origine se è protetto da NAT o effettua richieste tramite un proxy. Le richieste effettuate tramite NAT o proxy utilizzano l'indirizzo IP del Router o proxy NAT come indirizzo IP client. Ciò può causare traffico in entrata per raggruppare inutilmente le stesse istanze di backend.

• Se un client passa da una rete a un'altra, il suo indirizzo IP cambia, con conseguente interruzione dell'affinità.

Per informazioni sui prodotti che supportano l'affinità IP client, consulta la Tabella: impostazioni di affinità sessione.

Affinità cookie generata

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

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

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

L'affinità basata sui cookie può identificare più accuratamente un client per un bilanciatore del carico, rispetto all'affinità basata sull'IP del client. Ad esempio:

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

2. Se un client cambia il proprio indirizzo IP, l'affinità basata sui cookie consente al caricamento il bilanciatore del carico riconosce le connessioni successive da quel client anziché trattando la connessione come nuova. Un esempio di quando un client cambia il proprio IP si verifica quando un dispositivo mobile si sposta da una rete all'altra.

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

La durata del cookie HTTP generato dal bilanciatore del carico è configurabile. Puoi impostarlo su 0 (impostazione predefinita), il che significa che il cookie viene un cookie di sessione. Oppure puoi impostare la durata del cookie su un valore compreso tra Da 1 a 86400 secondi (24 ore) inclusi.

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

Affinità campo intestazione

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

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

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

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

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

Affinità cookie HTTP

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

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

L'affinità dei cookie HTTP instrada le richieste a VM di backend o endpoint in un NEG basato sul cookie HTTP denominato nel flag HTTP_COOKIE. Se il cliente non fornisce il cookie, il proxy genera il cookie e lo restituisce al client in una Intestazione Set-Cookie.

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

Affinità sessione persa

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

• Se il gruppo di istanza di backend o il NEG di zona esaurisce la capacità, come definito la capacità target della modalità di bilanciamento. In questa situazione, Google Cloud indirizza il traffico a un diverso gruppo di istanza di backend o a un NEG a livello di zona, che potrebbe 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'istanza gestita gruppo. In questo caso, il numero di istanze nel gruppo modifiche, quindi il servizio di backend ricalcola gli hash per l'affinità 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 di backend o un endpoint in un NEG non supera i controlli di integrità, il bilanciatore del carico indirizza il traffico a un backend integro diverso. Consulta la documentazione per ogni bilanciatore del carico di Google Cloud per maggiori dettagli su come si comporta quando tutti i backend non superano i controlli di integrità.
• Quando la modalità di bilanciamento UTILIZATION è attiva per i gruppi di istanza di backend, si interrompe l'affinità sessione a causa di modifiche nell'utilizzo del backend. Puoi mitigare il problema utilizzando la modalità di bilanciamento RATE o CONNECTION, a seconda di quale sia supportate dal tipo di bilanciatore del carico.

Quando usi bilanciatori del carico delle applicazioni esterni 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 di UTILIZATION, soprattutto senza una capacità target massima definita: è probabile che l'affinità sessione e un'interruzione di servizio quando il traffico al bilanciatore del carico è ridotto. Passa all'utilizzo di RATE o Modalità di bilanciamento di CONNECTION, supportata dal bilanciatore del carico che hai scelto.

Timeout del servizio di backend

La maggior parte dei bilanciatori del carico Google Cloud ha un timeout del servizio di backend. La 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 i bilanciatori del carico delle applicazioni interni che utilizzano HTTP, HTTPS o HTTP/2, il timeout del servizio di backend è un timeout per richiesta e risposta per il traffico HTTP(S).

  Per maggiori dettagli sul timeout del servizio di backend per ogni bilanciatore del carico, consulta le seguenti:

  • 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 per inattività. Per attendere più o meno tempo prima che la connessione venga eliminata, modifica il di timeout. Questo timeout di inattività viene utilizzato anche per le connessioni WebSocket.

• Per i bilanciatori del carico di rete passthrough interni e i bilanciatori del carico di rete passthrough esterni, puoi impostare il valore 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 una semantica di timeoutSec che specifica la quantità di tempo di attesa per restituire una risposta completa dopo l'invio della richiesta. Timeout di gRPC specifica la quantità di tempo che deve trascorrere dall'inizio del flusso di dati la risposta è stata completamente elaborata, inclusi tutti i nuovi tentativi.

Controlli di integrità

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

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

Quando crei un servizio di backend utilizzando un gruppo di istanze o un NEG a livello di zona utilizzando Google Cloud CLI o l'API, devi fare riferimento a un un controllo di integrità esistente. Fai riferimento al bilanciatore del carico guida nella sezione Salute Controlla Panoramica per informazioni dettagliate sul tipo e sull'ambito del controllo di integrità richiesto.

Per ulteriori informazioni, leggi i seguenti documenti:

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

Funzionalità aggiuntive abilitate nella risorsa del servizio di backend

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

Cloud CDN

Cloud CDN utilizza la rete perimetrale globale di Google per fornire contenuti più vicino per velocizzare i siti web e le applicazioni. Cloud CDN è abilitati sui servizi di backend utilizzati Bilanciatori del carico delle applicazioni esterni globali. Il bilanciatore del carico fornisce gli indirizzi IP frontend e le porte che ricevono le richieste, 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 altri la protezione delle tue applicazioni abilitando Google Cloud Armor sul 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 elemento esistente Criterio di sicurezza di Google Cloud Armor.
• Accetta la configurazione di una limitazione di frequenza predefinita di Google Cloud Armor criterio di sicurezza con nome, conteggio delle richieste, intervallo, chiave e parametri di limitazione di frequenza. 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 ti consente di stabilire una di autorizzazione per le applicazioni a cui si accede tramite HTTPS, quindi puoi utilizzare di controllo dell'accesso a livello di applicazione, invece di affidarsi a quelli a livello di rete firewall. IAP è supportato da determinate Bilanciatori del carico delle applicazioni.

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

Funzionalità di gestione del traffico

Le seguenti funzionalità sono supportate solo per alcuni prodotti:

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

Queste funzionalità sono supportate dai seguenti bilanciatori del carico:

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

• Bilanciatore del carico delle applicazioni esterno regionale

• Bilanciatore del carico delle applicazioni interno tra regioni

• Bilanciatore del carico delle applicazioni interno regionale

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

Riferimento API e gcloud

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

* API del servizio di backend globale risorsa

* API del servizio di backend regionale risorsa

• gcloud compute backend-services per servizi di backend globali e a livello regionale

Passaggi successivi

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

• Crea intestazioni personalizzate
• Crea un bilanciatore del carico delle applicazioni esterno
• Panoramica del bilanciatore del carico delle applicazioni esterno
• Attiva lo svuotamento della connessione
• Crittografia dei dati in transito in Google Cloud

Per i video correlati:

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