Un servizio di backend definisce la modalità di distribuzione del traffico di Cloud Load Balancing. La configurazione del servizio di backend contiene un insieme di valori, ad esempio il protocollo utilizzato per connettersi ai backend, varie impostazioni di distribuzione e sessione, controlli di integrità e timeout. Queste impostazioni forniscono un controllo granulare sul comportamento del bilanciatore del carico. Per iniziare, la maggior parte delle impostazioni ha valori predefiniti che consentono una configurazione rapida. Un servizio di backend è globale o regionale.
I bilanciatori del carico, i proxy Envoy e i client gRPC proxyless utilizzano le informazioni di configurazione nella risorsa del servizio di backend per:
- Indirizza il traffico ai backend corretti, ovvero gruppi di istanze o gruppi di endpoint di rete (NEG).
- Distribuisci il traffico in base a una modalità di bilanciamento, che è un'impostazione per ogni backend.
- Determina quale controllo di integrità monitora l'integrità dei backend.
- Specifica l'affinità sessione.
- Determina se sono attivati altri servizi, inclusi i seguenti
servizi disponibili solo per determinati bilanciatori
del carico:
- Cloud CDN
- Criteri di sicurezza di Google Cloud Armor
- Identity-Aware Proxy
- Designa i servizi di backend a livello di regione come servizio nelle applicazioni App Hub.
Questi valori vengono impostati quando crei un servizio di backend o aggiungi un backend al servizio di backend.
Nota: se utilizzi il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni classico e i tuoi backend pubblicano contenuti statici, valuta la possibilità di utilizzare i bucket di backend anziché i servizi di backend. Consulta bucket di backend per il bilanciatore del carico delle applicazioni esterno globale o bucket di backend per il bilanciatore del carico delle applicazioni classico.La seguente tabella riassume quali bilanciatori del carico utilizzano i servizi di backend. Il prodotto che utilizzi determina anche il numero massimo di servizi di backend, l'ambito di un servizio di backend, il tipo di backend supportati e lo schema di bilanciamento del carico del servizio di backend. Lo schema di bilanciamento del carico è un identificatore che Google utilizza per classificare le regole di forwarding e i servizi di backend. Ogni prodotto di bilanciamento del carico utilizza uno schema di bilanciamento del carico per le regole di forwarding e i servizi di backend. Alcuni schemi sono condivisi tra i prodotti.
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:
|
EXTERNAL_MANAGED |
Bilanciatore del carico delle applicazioni classico | Multiplo | Globale‡ | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL# |
Bilanciatore del carico delle applicazioni esterno regionale | Multiplo | Regionale | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL_MANAGED |
Bilanciatore del carico delle applicazioni interno tra regioni | Multiplo | Globale | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL_MANAGED |
Bilanciatore del carico delle applicazioni interno regionale | Multiplo | Regionale | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL_MANAGED |
Bilanciatore del carico di rete proxy esterno globale | 1 | Globale‡ | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL_MANAGED |
Bilanciatore del carico di rete proxy classico | 1 | Globale‡ | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL |
Bilanciatore del carico di rete proxy esterno regionale | 1 | Regionale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL_MANAGED |
Bilanciatore del carico di rete proxy interno regionale | 1 | Regionale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL_MANAGED |
Bilanciatore del carico di rete proxy interno tra regioni | Multiplo | Globale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL_MANAGED |
Bilanciatore del carico di rete passthrough esterno | 1 | Regionale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
EXTERNAL |
Bilanciatore del carico di rete passthrough interno | 1 | Regionale, ma configurabile per essere accessibile a livello globale | Il servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL |
Cloud Service Mesh | Multiplo | Globale | Ogni servizio di backend supporta una delle seguenti combinazioni di backend:
|
INTERNAL_SELF_MANAGED |
GCE_VM_IP_PORT
.
- La regola di inoltro e il relativo indirizzo IP esterno sono regionali.
- Tutti i backend connessi al servizio di backend devono trovarsi nella stessa regione della regola di forwarding.
EXTERNAL_MANAGED
servizi di backend a
EXTERNAL
regole di forwarding. Tuttavia, i servizi di backend EXTERNAL
non possono essere collegati alle regole di forwarding EXTERNAL_MANAGED
.
Per usufruire delle nuove funzionalità disponibili
solo con il bilanciatore del carico delle applicazioni esterno globale, ti
consigliamo di eseguire la migrazione delle risorse EXTERNAL
esistenti a
EXTERNAL_MANAGED
utilizzando la procedura di migrazione descritta in
Eseguire la migrazione
delle risorse dal bilanciatore del carico delle applicazioni esterno classico a quello globale.
Denominazione del bilanciatore del carico
Per i bilanciatori del carico di rete proxy e i bilanciatori del carico di rete passthrough, il nome del bilanciatore del carico è sempre uguale al nome del servizio di backend. Il comportamento per ogni Google Cloud interfaccia è il seguente:
- ConsoleGoogle Cloud . Se crei un bilanciatore del carico di rete proxy o un bilanciatore del carico di rete passthrough utilizzando la console Google Cloud , al servizio di backend viene assegnato automaticamente lo stesso nome che hai inserito per il nome del bilanciatore del carico.
- Google Cloud CLI o API. Se crei un bilanciatore del carico di rete proxy o un bilanciatore del carico di rete pass-through utilizzando l'interfaccia a riga di comando gcloud o l'API, inserisci un nome a tua scelta durante la creazione del servizio di backend. Il nome di questo servizio di backend viene poi visualizzato nella console Google Cloud come nome del bilanciatore del carico.
Per scoprire di più sul funzionamento della denominazione per i bilanciatori del carico delle applicazioni, consulta Panoramica delle mappe URL: denominazione del bilanciatore del carico.
Backend
Un backend è uno o più endpoint che ricevono traffico da un bilanciatore del carico Google Cloud, un proxy Envoy configurato con Cloud Service Mesho un client gRPC senza proxy . Esistono diversi tipi di backend:
- Un gruppo di istanze contenente istanze di macchine virtuali (VM). Un gruppo di istanze può essere un gruppo di istanze gestite (MIG), con o senza scalabilità automatica, oppure 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 Private Service Connect
- NEG internet
- NEG connettività ibrida
- NEG mappatura porte
- Service Directory service bindings
Non puoi eliminare un gruppo di istanza di backend o un NEG associato a un servizio di backend. Prima di eliminare un gruppo di istanze o un NEG, devi prima rimuoverlo come backend da tutti i servizi di backend che fanno riferimento a esso.
Gruppi di istanze
Questa sezione descrive il funzionamento dei gruppi di istanze con il servizio di backend.
VM di backend e indirizzi IP esterni
Le VM di backend nei servizi di backend non richiedono indirizzi IP esterni:
- Per i bilanciatori del carico delle applicazioni esterni globali e
i bilanciatori del carico di rete proxy esterni:i client comunicano con un Google Front End (GFE) che
ospita l'indirizzo IP esterno del bilanciatore del carico. I GFE comunicano con le VM o gli endpoint di backend inviando pacchetti a un indirizzo interno creato unendo un identificatore per la rete VPC del backend all'indirizzo IPv4 interno del backend. La comunicazione tra GFE e VM o endpoint di backend è facilitata tramite route speciali.
- Per i backend dei gruppi di istanze, l'indirizzo IPv4 interno è sempre l'indirizzo IPv4 interno principale che corrisponde all'interfaccia
nic0
della VM. - Per gli endpoint
GCE_VM_IP_PORT
in un NEG zonale, puoi specificare l'indirizzo IP dell'endpoint come indirizzo IPv4 primario associato a qualsiasi interfaccia di rete di una VM o qualsiasi indirizzo IPv4 da un intervallo di indirizzi IP alias associato a qualsiasi interfaccia di rete di una VM.
- Per i backend dei gruppi di istanze, l'indirizzo IPv4 interno è sempre l'indirizzo IPv4 interno principale che corrisponde all'interfaccia
Per i bilanciatori del carico delle applicazioni esterni regionali:i client comunicano con un proxy Envoy che ospita l'indirizzo IP esterno del bilanciatore del carico. I proxy Envoy comunicano con le VM o gli endpoint di backend inviando pacchetti a un indirizzo interno creato unendo un identificatore per la rete VPC del backend con l'indirizzo IPv4 interno del backend.
- Per i backend dei gruppi di istanze, l'indirizzo IPv4 interno è sempre l'indirizzo IPv4 interno principale che corrisponde all'interfaccia
nic0
della VM enic0
deve trovarsi nella stessa rete del bilanciatore del carico. - Per gli endpoint
GCE_VM_IP_PORT
in un NEG zonale, puoi specificare l'indirizzo IP dell'endpoint come indirizzo IPv4 primario associato a qualsiasi interfaccia di rete di una VM o qualsiasi indirizzo IPv4 di un intervallo di indirizzi IP alias associato a qualsiasi interfaccia di rete di una VM, a condizione che l'interfaccia di rete si trovi nella stessa rete del bilanciatore del carico.
- Per i backend dei gruppi di istanze, l'indirizzo IPv4 interno è sempre l'indirizzo IPv4 interno principale che corrisponde all'interfaccia
Per i bilanciatori del carico di rete passthrough esterni:i client comunicano direttamente con i backend tramite l'infrastruttura di bilanciamento del carico passthrough Maglev di Google. I pacchetti vengono instradati e recapitati ai backend con gli indirizzi IP di origine e destinazione originali conservati. I backend rispondono ai client utilizzando il ritorno diretto del server. I metodi utilizzati per selezionare un backend e monitorare le connessioni sono configurabili.
- Per i backend di gruppi di istanze, i pacchetti vengono sempre inviati all'interfaccia
nic0
della VM. - Per gli endpoint
GCE_VM_IP
in un NEG di zona, i pacchetti vengono inviati all'interfaccia di rete della VM che si trova nella subnet associata al NEG.
- Per i backend di gruppi di istanze, i pacchetti vengono sempre inviati all'interfaccia
Porte denominate
L'attributo porta denominata del servizio di backend è applicabile solo ai bilanciatori del carico basati su proxy (bilanciatori del carico delle applicazioni e bilanciatori del carico di rete proxy) che utilizzano backend di gruppi di istanze. La porta denominata definisce la porta di destinazione utilizzata per la connessione TCP tra il proxy (GFE o Envoy) e l'istanza di backend.
Le porte denominate sono configurate nel seguente modo:
In ogni backend del gruppo di istanze, devi configurare una o più porte denominate utilizzando coppie chiave-valore. La chiave rappresenta un nome di porta significativo che scegli e il valore rappresenta il numero di porta che assegni al nome. La mappatura dei nomi ai numeri viene eseguita singolarmente per ogni backend del gruppo di istanze.
Nel servizio di backend, specifica una singola porta denominata utilizzando solo il nome della porta (
--port-name
).
In base a ogni backend del gruppo di istanze, il servizio di backend traduce il nome della porta in un numero di porta. Quando la porta denominata di un gruppo di istanze corrisponde a --port-name
del servizio di backend, quest'ultimo utilizza questo numero di porta per la comunicazione con le VM del gruppo di istanze.
Ad esempio, puoi impostare la porta denominata su un gruppo di istanze con il nome
my-service-name
e la porta 8888
:
gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \ --named-ports=my-service-name:8888
Poi fai riferimento alla porta denominata nella configurazione del servizio di backend con
--port-name
impostato su my-service-name
nel servizio di backend:
gcloud compute backend-services update my-backend-service \ --port-name=my-service-name
Un servizio di backend può utilizzare un numero di porta diverso quando comunica con le VM in gruppi di istanze diversi se ogni gruppo di istanze specifica un numero di porta diverso per lo stesso nome di porta.
Il numero di porta risolto utilizzato dal servizio di backend del bilanciatore del carico proxy non deve corrispondere al numero di porta utilizzato dalle regole di forwarding del bilanciatore del carico. Un bilanciatore del carico proxy è in attesa di connessioni TCP inviate all'indirizzo IP e alla porta di destinazione delle relative regole di forwarding. Poiché il proxy apre una seconda connessione TCP ai suoi backend, la porta di destinazione della seconda connessione TCP può essere diversa.
Le porte denominate sono applicabili solo ai backend dei gruppi di istanze. I NEG di zona con endpoint GCE_VM_IP_PORT
, i NEG ibridi con endpoint NON_GCP_PRIVATE_IP_PORT
e i NEG internet definiscono le porte utilizzando un meccanismo diverso, ovvero sugli endpoint stessi. I NEG serverless fanno riferimento ai servizi Google e i NEG PSC fanno riferimento agli allegati di servizio utilizzando astrazioni che non comportano la specifica di una porta di destinazione.
I bilanciatori del carico di rete passthrough interni e i bilanciatori del carico di rete passthrough esterni non utilizzano porte denominate. Questo perché sono bilanciatori del carico passthrough che instradano le connessioni direttamente ai backend anziché crearne di nuove. I pacchetti vengono inviati ai backend conservando l'indirizzo IP e la porta di destinazione della regola di forwarding del bilanciatore del carico.
Per scoprire come creare porte denominate, segui queste istruzioni:
- Gruppi di istanze non gestite: utilizzo di porte denominate
- Gruppi di istanze gestite: assegnazione di porte denominate a gruppi di istanze gestite
Limitazioni e indicazioni 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 fa parte di due o più gruppi di istanze non gestite oppure di un gruppo di istanze gestite e di uno o più gruppi di istanze non gestite, Google Cloudti consente di utilizzare solo uno di questi gruppi di istanze alla volta come backend per un determinato servizio di backend.
Se hai bisogno che una VM partecipi a più bilanciatori del carico, devi utilizzare lo stesso gruppo di istanze come backend su ciascuno dei servizi di backend.
Per i bilanciatori del carico proxy, quando vuoi bilanciare il traffico su porte diverse, specifica le porte denominate richieste su un gruppo di istanze e fai in modo che ogni servizio di backend si iscriva a una porta denominata univoca.
Puoi utilizzare lo stesso gruppo di istanze come backend per più di un servizio di backend. In questa situazione, i backend devono utilizzare modalità di bilanciamento compatibili. Compatibile significa che le modalità di bilanciamento devono essere le stesse o una combinazione di modalità di bilanciamento compatibili, ad esempio
CONNECTION
eRATE
.Le combinazioni di modalità di bilanciamento incompatibili sono le seguenti:
CONNECTION
conUTILIZATION
RATE
conUTILIZATION
CUSTOM_METRICS
conUTILIZATION
CUSTOM_METRICS
conRATE
CUSTOM_METRICS
conCONNECTION
Considera l'esempio seguente:
- Hai due servizi di backend:
external-https-backend-service
per un bilanciatore del carico delle applicazioni esterno einternal-tcp-backend-service
per un bilanciatore del carico di rete passthrough interno. - Stai utilizzando un gruppo di istanze chiamato
instance-group-a
ininternal-tcp-backend-service
. - In
internal-tcp-backend-service
, devi applicare la modalità di bilanciamentoCONNECTION
perché i bilanciatori del carico di rete passthrough interni supportano solo la modalità di bilanciamentoCONNECTION
. - Puoi anche utilizzare
instance-group-a
inexternal-https-backend-service
se applichi la modalità di bilanciamentoRATE
inexternal-https-backend-service
. - Non puoi utilizzare
instance-group-a
inexternal-https-backend-service
con la modalità di bilanciamentoUTILIZATION
.
Per modificare la modalità di bilanciamento per un gruppo di istanze che funge da backend per più servizi di backend:
- Rimuovi il gruppo di istanze da tutti i servizi di backend tranne uno.
- Modifica la modalità di bilanciamento per il backend nell'unico servizio di backend rimanente.
- Aggiungi di nuovo il gruppo di istanze come backend ai servizi di backend rimanenti, se supportano la nuova modalità di bilanciamento del carico.
Se il tuo gruppo di istanze è associato a più servizi di backend, ogni servizio di backend può fare riferimento alla stessa porta denominata o a una porta denominata diversa nel gruppo di istanze.
Ti consigliamo di non aggiungere un gruppo di istanze gestite con scalabilità automatica a più di un servizio di backend. In questo modo, potresti causare una scalabilità imprevedibile e non necessaria delle istanze nel gruppo, soprattutto se utilizzi la metrica di scalabilità automatica Utilizzo del bilanciamento del carico HTTP.
- Sebbene non sia consigliato, questo scenario potrebbe funzionare se la metrica di scalabilità automatica è Utilizzo della CPU o una metrica di Cloud Monitoring non correlata alla capacità di gestione del bilanciatore del carico. L'utilizzo di una di queste metriche di scalabilità automatica potrebbe impedire una scalabilità irregolare.
Gruppi di endpoint di rete a livello di zona
Gli endpoint di rete rappresentano i servizi in base al loro indirizzo IP o a una combinazione di indirizzo IP e porta, anziché fare riferimento a una VM in un gruppo di istanze. Un gruppo di endpoint di rete (NEG) è un raggruppamento logico di endpoint di rete.
I gruppi di endpoint di rete (NEG) 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 una singola subnet.
Un servizio di backend che utilizza i NEG zonali come backend distribuisce il traffico tra le applicazioni o i container in esecuzione all'interno delle VM.
Per i NEG zonali sono disponibili due tipi di endpoint di rete:
- endpoint
GCE_VM_IP
(supportati solo con i bilanciatori del carico di rete passthrough interni e i bilanciatori del carico di rete passthrough esterni basati su servizi di backend). GCE_VM_IP_PORT
endpoint.
Per vedere quali prodotti supportano i backend NEG zonali, consulta la tabella: servizi di backend e tipi di backend supportati.
Per maggiori dettagli, vedi Panoramica dei NEG di zona.
Gruppi di endpoint di rete internet
I NEG di internet sono risorse che definiscono i backend esterni. Un backend esterno è un backend ospitato all'interno di un'infrastruttura on-premise o su un'infrastruttura fornita da terze parti.
Un NEG internet è la combinazione di un nome host o un indirizzo IP, più una porta facoltativa. Esistono due tipi di endpoint di rete disponibili per i NEG internet: INTERNET_FQDN_PORT
e INTERNET_IP_PORT
.
Per maggiori dettagli, consulta la panoramica del gruppo di endpoint di rete internet.
Gruppi di endpoint di rete serverless
Un gruppo di endpoint di rete (NEG) specifica un gruppo di endpoint di backend per un bilanciatore del carico. Un NEG serverless è un backend che punta a una risorsa Cloud Run, App Engine, Cloud Run Functions o API Gateway.
Un NEG serverless può rappresentare uno dei seguenti elementi:
- Una risorsa Cloud Run o un gruppo di risorse.
- Una funzione Cloud Run o un gruppo di funzioni (in precedenza funzioni Cloud Run2ª generazionen.).
- Una funzione Cloud Run (1ª generazione.) o un gruppo di funzioni
- Un'app dell'ambiente standard di App Engine o dell'ambiente flessibile di App Engine, un servizio specifico all'interno di un'app, una versione specifica di un'app o un gruppo di servizi.
- Un API Gateway che fornisce l'accesso ai tuoi servizi tramite un'API REST coerente in tutti i servizi, indipendentemente dall'implementazione del servizio. Questa funzionalità è in anteprima.
Per configurare un NEG serverless per applicazioni serverless che condividono un pattern URL, utilizza una maschera
URL. Una maschera URL è un modello dello schema URL (ad esempio example.com/<service>
). Il NEG serverless utilizzerà questo modello per estrarre il nome <service>
dall'URL della richiesta in entrata e instradare la richiesta al servizio Cloud Run, Cloud Run Functions o App Engine corrispondente con lo stesso nome.
Per vedere quali bilanciatori del carico supportano i backend NEG serverless, consulta la tabella: servizi di backend e tipi di backend supportati.
Per saperne di più sui NEG serverless, consulta la panoramica sui gruppi di endpoint di rete serverless.
Associazioni dei servizi
Un binding del servizio è un backend che stabilisce una connessione tra un servizio di backend in Cloud Service Mesh e un servizio registrato in Service Directory. Un servizio di backend può fare riferimento a più binding di servizio. Un servizio di backend con un binding del servizio non può fare riferimento a nessun altro tipo di backend.
Backend misti
Quando aggiungi diversi tipi di backend a un singolo servizio di backend, si applicano le seguenti considerazioni sull'utilizzo:
- Un singolo servizio di backend non può utilizzare contemporaneamente gruppi di istanze e NEG a livello di zona.
- Puoi utilizzare una combinazione di diversi tipi di gruppi di istanze nello stesso servizio di backend. Ad esempio, un singolo servizio di backend può fare riferimento a una combinazione di gruppi di istanze gestite e non gestite. Per informazioni complete sui backend compatibili con i servizi di backend, consulta la tabella nella sezione precedente.
- Con alcuni bilanciatori del carico proxy, puoi utilizzare una combinazione di NEG di zona (con endpoint
GCE_VM_IP_PORT
) e NEG di connettività ibrida (con endpointNON_GCP_PRIVATE_IP_PORT
) per configurare il bilanciamento del carico ibrido. Per vedere quali bilanciatori del carico hanno questa funzionalità, consulta la tabella: servizi di backend e tipi di backend supportati.
Protocollo per i backend
Quando crei un servizio di backend, devi specificare il protocollo utilizzato per comunicare con i backend. Puoi specificare un solo protocollo per servizio di backend. Non puoi specificare un protocollo secondario da utilizzare come fallback.
I protocolli validi dipendono dal tipo di bilanciatore del carico o dall'utilizzo di Cloud Service Mesh.
Prodotto | Opzioni di protocollo del servizio di backend |
---|---|
Bilanciatore del carico delle applicazioni | HTTP, HTTPS, HTTP/2 |
Bilanciatore del carico di rete proxy | TCP o SSL I bilanciatori del carico di rete proxy regionali supportano solo TCP. |
Bilanciatore del carico di rete passthrough | TCP, UDP o UNSPECIFIED |
Cloud Service Mesh | HTTP, HTTPS, HTTP/2, gRPC, TCP |
La modifica del protocollo di un servizio di backend rende i backend inaccessibili tramite i bilanciatori del carico per alcuni minuti.
Policy di selezione degli indirizzi IP
Questo campo è applicabile ai bilanciatori del carico proxy. Devi utilizzare il criterio di selezione dell'indirizzo IP per specificare il tipo di traffico inviato dal servizio di backend ai backend.
Quando selezioni il criterio di selezione dell'indirizzo IP, assicurati che i backend supportino il tipo di traffico selezionato. Per maggiori informazioni, vedi Tabella: servizi di backend e tipi di backend supportati.
La norma di selezione dell'indirizzo IP viene utilizzata quando vuoi convertire il servizio di backend del bilanciatore del carico per supportare un tipo di traffico diverso. Per saperne di più, consulta Eseguire la conversione da single-stack a dual-stack.
Puoi specificare i seguenti valori per la policy di selezione degli indirizzi IP:
Policy di selezione degli indirizzi IP | Descrizione |
---|---|
Solo IPv4 | Invia solo traffico IPv4 ai backend del servizio di backend, indipendentemente dal traffico dal client al GFE. Per controllare l'integrità dei backend vengono utilizzati solo i controlli di integrità IPv4. |
Preferisci IPv6 | Dai la priorità alla connessione IPv6 del backend rispetto alla connessione IPv4 (a condizione che esista un backend integro con indirizzi IPv6). I controlli di integrità monitorano periodicamente le connessioni IPv6 e IPv4 dei backend. Il GFE tenta prima la connessione IPv6; se la connessione IPv6 è interrotta o lenta, il GFE utilizza happy eyeballs per eseguire il failover e connettersi a IPv4. Anche se una delle connessioni IPv6 o IPv4 non è integra, il backend viene comunque considerato integro ed entrambe le connessioni possono essere provate dal GFE, con happy eyeballs che alla fine seleziona quella da utilizzare. |
Solo IPv6 | Invia solo traffico IPv6 ai backend del servizio di backend, indipendentemente dal traffico dal client al proxy. Per verificare l'integrità dei backend vengono utilizzati solo i controlli di integrità IPv6. Non è presente alcuna convalida per verificare se il tipo di traffico di backend corrisponde al
criterio di selezione degli indirizzi IP. Ad esempio, se hai backend solo IPv4
e selezioni |
Crittografia tra il bilanciatore del carico e i backend
Per informazioni sulla crittografia tra il bilanciatore del carico e i backend, vedi Crittografia verso i backend.
Distribuzione del traffico
I valori dei seguenti campi nella risorsa dei servizi di backend determinano alcuni aspetti del comportamento del backend:
- Una modalità di bilanciamento definisce il modo in cui il bilanciatore del carico misura la disponibilità del backend per nuove richieste o connessioni.
- Una capacità target definisce un numero massimo target di connessioni, un tasso massimo target o un utilizzo massimo target della CPU.
- Un gestore della scalabilità della capacità regola la capacità disponibile complessiva 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 possono gestire traffico aggiuntivo o sono completamente carichi.
Google Cloud ha quattro modalità di bilanciamento:
CONNECTION
: determina come viene distribuito il carico in base al numero totale di connessioni che il backend può gestire.RATE
: il numero massimo target di richieste (query) al secondo (RPS, QPS). Il RPS/QPS massimo target può essere superato se tutti i backend sono al di sopra della capacità.UTILIZATION
: determina la modalità di distribuzione del carico in base all'utilizzo delle istanze in un gruppo di istanze.CUSTOM_METRICS
: determina come viene distribuito il carico in base alle metriche personalizzate definite dall'utente.
Modalità di bilanciamento disponibili per ogni bilanciatore del carico
Imposti la modalità di bilanciamento quando aggiungi un backend al servizio di backend. Le modalità di bilanciamento disponibili per un bilanciatore del carico dipendono dal tipo di bilanciatore del carico e dal tipo di backend.
I bilanciatori del carico di rete passthrough richiedono la modalità di bilanciamento CONNECTION
, ma non
supportano l'impostazione di alcuna capacità target.
I bilanciatori del carico delle applicazioni supportano le modalità di bilanciamento RATE
, UTILIZATION
o
CUSTOM_METRICS
per i backend dei gruppi di istanze e le modalità di bilanciamento RATE
o
CUSTOM_METRICS
per i NEG di zona (endpoint GCE_VM_IP_PORT
) e
i NEG ibridi (endpoint NON_GCP_PRIVATE_IP_PORT
). Per qualsiasi altro tipo di backend supportato, la modalità di bilanciamento deve essere omessa.
Per i bilanciatori del carico delle applicazioni classici, viene selezionata una regione in base alla posizione del client e alla disponibilità di capacità della regione, in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni di quante richieste devono essere inviate a ciascun backend nella 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 posizione del client e alla disponibilità di capacità della regione, in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni di quante richieste devono essere inviate a ciascun backend (gruppo di istanze o NEG) nella regione. Puoi utilizzare il criterio di bilanciamento del carico del servizio (
serviceLbPolicy
) e l'impostazione backend preferito per influenzare la selezione di backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, la policy 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 delle applicazioni interni tra regioni, i bilanciatori del carico delle applicazioni esterni regionali, e i bilanciatori del carico delle applicazioni interni regionali, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni di quante richieste devono essere inviate a ogni backend (gruppo di istanze o NEG) nella regione. All'interno di ogni gruppo di istanze o NEG, la policy di bilanciamento del carico (
LocalityLbPolicy
) determina la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo. Solo il bilanciatore del carico delle applicazioni interno tra regioni supporta l'utilizzo della policy di bilanciamento del carico del servizio (serviceLbPolicy
) e delle impostazioni del backend preferito per influenzare la selezione di backend specifici all'interno di una regione.
I bilanciatori del carico di rete proxy supportano le modalità di bilanciamento CONNECTION
o
UTILIZATION
per i backend di gruppi di istanze VM, la modalità di bilanciamento CONNECTION
per i NEG di zona con endpoint GCE_VM_IP_PORT
e la modalità di bilanciamento CONNECTION
per i NEG ibridi (endpoint NON_GCP_PRIVATE_IP_PORT
). Per qualsiasi
altro tipo di backend supportato, la modalità di bilanciamento deve essere omessa.
Per i bilanciatori del carico di rete proxy esterni globali, viene selezionata una regione in base alla posizione del client e alla disponibilità di capacità nella regione, in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità target della modalità di bilanciamento viene utilizzata per calcolare le proporzioni di quante richieste devono essere inviate a ciascun backend (gruppo di istanze o NEG) nella regione. Puoi utilizzare il criterio di bilanciamento del carico del servizio (
serviceLbPolicy
) e l'impostazione backend preferito per influenzare la selezione di backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, la policy 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 interni 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 di quante richieste devono essere inviate a ogni backend (gruppo di istanze o NEG) nella regione. Puoi utilizzare il criterio di bilanciamento del carico del servizio (
serviceLbPolicy
) e l'impostazione backend preferito per influenzare la selezione di backend specifici all'interno di una regione. Inoltre, all'interno di ogni gruppo di istanze o NEG, la policy 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 classici, viene selezionata una regione in base alla posizione del client e alla disponibilità di capacità della regione in base alla capacità target della modalità di bilanciamento del carico. All'interno di una regione, la capacità target della modalità di bilanciamento del carico viene utilizzata per calcolare le proporzioni di richieste o connessioni da inviare a ogni backend (gruppo di istanze o NEG) nella regione. Dopo che il bilanciatore del carico ha selezionato un backend, le richieste o le connessioni vengono distribuite in modo round robin tra le istanze VM o gli endpoint di rete all'interno di ogni singolo backend.
- Per i bilanciatori del carico di rete 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 di quante richieste devono essere inviate a ciascun backend (gruppo di istanze o NEG). All'interno di ogni
gruppo di istanze o NEG, il criterio di bilanciamento del carico (
localityLbPolicy
) determina la modalità di distribuzione del traffico alle istanze o agli endpoint all'interno del gruppo.
La tabella seguente riassume le modalità di bilanciamento del carico disponibili per ogni combinazione di bilanciatore del carico e backend.
Bilanciatore del carico | Backend | Modalità di bilanciamento disponibili |
---|---|---|
Bilanciatore del carico delle applicazioni | Gruppi di istanze | RATE , UTILIZATION
o CUSTOM_METRICS |
NEG a livello di zona (GCE_VM_IP_PORT endpoint) |
RATE o CUSTOM_METRICS |
|
NEG ibridi (NON_GCP_PRIVATE_IP_PORT endpoint) |
RATE o CUSTOM_METRICS |
|
Bilanciatore del carico di rete proxy
|
Gruppi di istanze | CONNECTION o UTILIZATION |
NEG a livello di zona (GCE_VM_IP_PORT endpoint) |
CONNECTION |
|
NEG ibridi ( |
CONNECTION |
|
Bilanciatore del carico di rete passthrough | Gruppi di istanze | CONNECTION |
NEG a livello di zona (GCE_VM_IP endpoint) |
CONNECTION |
Se l'utilizzo medio di tutte le VM associate a un servizio di backend è inferiore al 10%, Google Cloud potrebbe preferire zone specifiche. Ciò 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 zonale si risolve automaticamente man mano che viene inviato più traffico al bilanciatore del carico.
Per saperne di più, vedi gcloud compute backend-services add-backend.
Capacità target
Ogni modalità di bilanciamento ha una capacità target corrispondente, che definisce uno dei seguenti massimi target:
- Numero di connessioni
- Tariffa
- Utilizzo CPU
Per ogni modalità di bilanciamento, la capacità target non è un interruttore di protezione. Un bilanciatore del carico può superare il valore massimo in determinate condizioni, ad esempio se tutte le VM o tutti gli endpoint di backend hanno raggiunto il valore massimo.
Modalità di bilanciamento della connessione
Per la modalità di bilanciamento CONNECTION
, la capacità target definisce un numero massimo target di connessioni aperte. Ad eccezione dei bilanciatori del carico di rete passthrough interni e dei bilanciatori del carico di rete passthrough esterni, devi utilizzare una delle seguenti impostazioni per specificare un numero massimo di connessioni di destinazione:
max-connections-per-instance
(per VM): il numero medio target di connessioni per una singola VM.max-connections-per-endpoint
(per endpoint in un NEG di zona): numero medio target di connessioni per un singolo endpoint.max-connections
(per i NEG a livello di zona e per i gruppi di istanze a livello di zona): Numero medio di connessioni di destinazione per l'intero NEG o gruppo di istanze. Per i gruppi di istanze gestite a livello di regione, utilizzamax-connections-per-instance
.
La tabella seguente mostra come il parametro di capacità target definisce quanto segue:
- La capacità target per l'intero backend
- La capacità target prevista per ogni istanza o endpoint
Tipo di backend | Capacità target | ||
---|---|---|---|
Se specifichi | Capacità totale del backend | Capacità prevista per istanza o per endpoint | |
Gruppo di istanzeN istanze,H integre |
max-connections-per-instance=X
|
X × N
|
(X × N)/H
|
NEG a livello di zonaN endpoint,H in stato integro
|
max-connections-per-endpoint=X
|
X × N
|
(X × N)/H
|
Gruppi di istanze (tranne i gruppi di istanze gestite a livello di regione) H istanze integre
|
max-connections=Y
|
Y
|
Y/H
|
Come illustrato, le impostazioni max-connections-per-instance
e
max-connections-per-endpoint
sono proxy per il calcolo di un
numero massimo di connessioni di destinazione per l'intero gruppo di istanze VM o l'intero
NEG di zona:
- In un gruppo di istanze VM con
N
istanze, l'impostazionemax-connections-per-instance=X
ha lo stesso significato dell'impostazionemax-connections=X × N
. - In un NEG di zona con
N
endpoint, l'impostazionemax-connections-per-endpoint=X
ha lo stesso significato dell'impostazionemax-connections=X × N
.
Modalità di bilanciamento della velocità
Per la modalità di bilanciamento RATE
, devi definire la capacità target utilizzando
uno dei seguenti parametri:
max-rate-per-instance
(per VM): specifica una frequenza media target di richieste HTTP per una singola VM.max-rate-per-endpoint
(per endpoint in un NEG zonale): fornisci una velocità media di richieste HTTP di destinazione per un singolo endpoint.max-rate
(per i NEG a livello di zona e per i gruppi di istanze a livello di zona): fornisci una frequenza media target delle richieste HTTP per l'intero NEG o gruppo di istanze. Per i gruppi di istanze gestite a livello di regione, utilizza invecemax-rate-per-instance
.
La tabella seguente mostra come il parametro di capacità target definisce quanto segue:
- La capacità target per l'intero backend
- La capacità target prevista per ogni istanza o endpoint
Tipo di backend | Capacità target | ||
---|---|---|---|
Se specifichi | Capacità totale del backend | Capacità prevista per istanza o per endpoint | |
Gruppo di istanzeN istanze,H integre |
max-rate-per-instance=X
|
X × N
|
(X × N)/H
|
NEG a livello di zonaN 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 il calcolo di una velocità massima target di richieste HTTP per l'intero
gruppo di istanze o l'intero NEG zonale:
- In un gruppo di istanze con
N
istanze, l'impostazionemax-rate-per-instance=X
ha lo stesso significato dell'impostazionemax-rate=X × N
. - In un NEG a livello di zona con
N
endpoint, l'impostazionemax-rate-per-endpoint=X
ha lo stesso significato dell'impostazionemax-rate=X × N
.
Modalità di bilanciamento dell'utilizzo
La modalità di bilanciamento UTILIZATION
non ha una capacità target obbligatoria. Hai diverse opzioni a seconda del tipo di backend, come riepilogato nella tabella della sezione seguente.
La capacità target max-utilization
può essere specificata solo per gruppo di istanze e non può essere applicata a una particolare VM del gruppo.
La modalità di bilanciamento UTILIZATION
non ha una capacità target obbligatoria. Quando utilizzi
la Google Cloud console per aggiungere un gruppo di istanza di backend a un servizio di backend, la
Google Cloud console imposta il valore di max-utilization
su 0,8 (80%) se è selezionata la modalità di bilanciamento del carico UTILIZATION
. Oltre a max-utilization
, la modalità di bilanciamento UTILIZATION
supporta capacità target più complesse, come riepilogato nella tabella della sezione seguente.
Modalità di bilanciamento delle metriche personalizzate
La modalità di bilanciamento CUSTOM_METRICS
ti consente di definire metriche personalizzate
che possono essere utilizzate per determinare come viene distribuito il carico. Le metriche personalizzate ti consentono di configurare il comportamento di distribuzione del traffico del bilanciatore del carico in modo che si basi su metriche specifiche per i requisiti dell'applicazione o dell'infrastruttura, anziché sulle metriche standard di utilizzo o basate sulla frequenza diGoogle Cloud.
Per ulteriori informazioni, vedi Metriche personalizzate per i bilanciatori del carico delle applicazioni.
Modifica della modalità di bilanciamento di un bilanciatore del carico
Per alcuni bilanciatori del carico o configurazioni del bilanciatore 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 scoprire quali modalità di bilanciamento sono supportate per ogni bilanciatore del carico, consulta la Tabella: modalità di bilanciamento disponibili per ogni bilanciatore del carico
Modalità di bilanciamento e impostazioni della capacità target
Per i prodotti che supportano una specifica di capacità target, la capacità target non è un interruttore automatico. Quando viene raggiunto il valore massimo della capacità target configurata in una determinata zona, le nuove richieste o connessioni vengono distribuite ad altre zone che non elaborano richieste o connessioni alla capacità target. Se tutte le zone hanno raggiunto la capacità target, le nuove richieste o connessioni vengono distribuite tramite il riempimento eccessivo.
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.
Tipo di backend | Modalità di bilanciamento | Specifiche della capacità target |
---|---|---|
Gruppi di istanze
|
RATE |
Devi specificare una delle seguenti opzioni:
|
UTILIZATION |
Facoltativamente, puoi specificare uno dei seguenti elementi:
|
|
CUSTOM_METRICS |
Facoltativamente, puoi specificare uno dei seguenti elementi:
max-utilization non è supportato. |
|
NEG a livello di zona
NEG ibridi
|
RATE |
Devi specificare una delle seguenti opzioni:
|
CUSTOM_METRICS |
Facoltativamente, puoi specificare uno dei seguenti elementi:
max-utilization non è supportato. |
Bilanciatori del carico di rete proxy
Questa tabella elenca le combinazioni di modalità di bilanciamento e capacità target disponibili per i bilanciatori del carico di rete proxy.
Tipo di backend | Modalità di bilanciamento | Specifiche della capacità target |
---|---|---|
Gruppi di istanze
|
CONNECTION |
Devi specificare una delle seguenti opzioni:
|
UTILIZATION |
Facoltativamente, puoi specificare uno dei seguenti elementi:
|
|
NEG a livello di zona
NEG ibridi
|
CONNECTION |
Devi specificare una delle seguenti opzioni:
|
Bilanciatori del carico di rete passthrough
Questa tabella elenca le combinazioni di modalità di bilanciamento e capacità target disponibili per i bilanciatori del carico di rete passthrough.
Tipo di backend | Modalità di bilanciamento | Specifiche della capacità target |
---|---|---|
Gruppi di istanze
|
CONNECTION |
Non puoi specificare un numero massimo di connessioni di destinazione. |
NEG a livello di zona
|
CONNECTION |
Non puoi specificare un numero massimo di connessioni di destinazione. |
Scalatore di capacità
Utilizza lo strumento di scalabilità della capacità per scalare la capacità target (utilizzo massimo, velocità massima o connessioni massime) senza modificarla.
Per la Google Cloud documentazione di riferimento, consulta quanto segue:
- Google Cloud CLI: capacity-scaler
- API:
Puoi regolare il gestore della scalabilità della capacità per scalare la capacità target effettiva
senza modificare esplicitamente uno dei parametri --max-*
.
Puoi impostare lo scalatore della capacità su uno di questi valori:
- Il valore predefinito è
1
, il che significa che il gruppo utilizza fino al 100% della capacità configurata (a seconda dibalancingMode
). - Un valore di
0
significa che il gruppo è completamente esaurito e offre lo 0% della sua capacità disponibile. Non puoi configurare un'impostazione di0
quando è collegato un solo backend al servizio di backend. - Un valore compreso tra
0.1
(10%) e1.0
(100%).
I seguenti esempi mostrano come funziona lo strumento di scalabilità della capacità in combinazione con l'impostazione della capacità target:
Se la modalità di bilanciamento è
RATE
, ilmax-rate
è impostato su80
RPS e lo scaler della capacità è1.0
, la capacità disponibile è anche80
RPS.Se la modalità di bilanciamento è
RATE
,max-rate
è impostato su80
RPS e lo scalatore di capacità è0.5
, la capacità disponibile è40
RPS (0.5 times 80
).Se la modalità di bilanciamento è
RATE
,max-rate
è impostato su80
RPS e il fattore di scalabilità della capacità è0.0
, la capacità disponibile è zero (0
).
Policy di bilanciamento del carico del servizio
Una policy di bilanciamento del carico del servizio (serviceLbPolicy
) è una risorsa associata
al servizio di backend del bilanciatore del carico. Consente di personalizzare i parametri che influenzano il modo in cui il traffico viene distribuito all'interno dei backend associati a un servizio di backend:
- Personalizza l'algoritmo di bilanciamento del carico utilizzato per determinare come viene distribuito il traffico tra regioni o zone.
- Abilita lo svuotamento automatico della capacità in modo che il bilanciatore del carico possa svuotare rapidamente il traffico dai backend non integri.
Inoltre, puoi designare backend specifici come backend preferiti. Questi backend devono essere utilizzati al massimo della capacità (ovvero la capacità target specificata dalla modalità di bilanciamento del backend) prima che le richieste vengano inviate ai backend rimanenti.
Per saperne di più, consulta Ottimizzazioni avanzate del bilanciamento del carico con una policy di bilanciamento del carico del servizio.
Policy di bilanciamento del carico per le località
Per un servizio di backend, la distribuzione del traffico si basa su una modalità di bilanciamento e su un
criterio di località di bilanciamento del carico. La modalità di bilanciamento determina la frazione di
traffico da inviare a ciascun backend (gruppo di istanze o NEG). La policy di località di bilanciamento del carico (LocalityLbPolicy
) determina quindi la modalità di distribuzione del traffico tra le istanze o gli endpoint all'interno di ogni zona. Per i gruppi di istanze gestite a livello di regione, la norma di località si applica a ogni zona costituente.
Il criterio di località di bilanciamento del carico viene configurato per servizio di backend. Sono disponibili le seguenti impostazioni:
ROUND_ROBIN
(impostazione predefinita): questa è l'impostazione predefinita del criterio di località di bilanciamento del carico in cui il bilanciatore del carico seleziona un backend integro in ordine round robin.WEIGHTED_ROUND_ROBIN
: il bilanciatore del carico utilizza le metriche personalizzate definite dall'utente per selezionare l'istanza o l'endpoint ottimale all'interno del backend per gestire la richiesta.LEAST_REQUEST
: Un algoritmoO(1)
in cui il bilanciatore del carico seleziona due host casuali in stato integro e sceglie quello con meno richieste attive.RING_HASH
: questo algoritmo implementa l'hashing coerente per i backend. L'algoritmo ha la proprietà per la quale l'aggiunta o la rimozione di un host da un set di N host influisce solo su 1/N delle richieste.RANDOM
: il bilanciatore del carico seleziona un host casuale in stato integro.ORIGINAL_DESTINATION
: il bilanciatore del carico seleziona un backend in base ai metadati di connessione del client. Le connessioni vengono aperte all'indirizzo IP di destinazione originale specificato nella richiesta client in entrata, prima che la richiesta venga reindirizzata al bilanciatore del carico.ORIGINAL_DESTINATION
non è supportato per i bilanciatori del carico delle applicazioni esterno globali e regionali.MAGLEV
: implementa l'hashing coerente ai backend e può essere utilizzato in sostituzione della policyRING_HASH
. Maglev non è stabile comeRING_HASH
, ma i tempi di creazione della ricerca nelle tabelle e di selezione dell'host sono più rapidi. Per ulteriori informazioni su Maglev, consulta il white paper su Maglev.WEIGHTED_MAGLEV
: implementa il bilanciamento del carico ponderato per istanza utilizzando i pesi segnalati dai controlli di integrità. Se viene utilizzato questo criterio, il servizio di backend deve configurare un controllo di integrità basato su HTTP non legacy e le risposte del controllo di integrità devono contenere il campo dell'intestazione della risposta HTTP non standard,X-Load-Balancing-Endpoint-Weight
, per specificare i pesi per istanza. Le decisioni di bilanciamento del carico vengono prese in base alle ponderazioni per istanza riportate nelle ultime risposte al controllo di integrità elaborate, a condizione che ogni istanza riporti una ponderazione valida oUNAVAILABLE_WEIGHT
. In caso contrario, il bilanciamento del carico rimarrà con pesi uguali.WEIGHTED_MAGLEV
è supportato solo per i bilanciatori del carico di rete passthrough esterni. Per un esempio, consulta Configura il bilanciamento del carico ponderato per i bilanciatori del carico di rete passthrough esterni.
La configurazione di una policy di località di bilanciamento del carico è supportata solo sui servizi di backend utilizzati con i seguenti bilanciatori del carico:
- Bilanciatore del carico delle applicazioni esterno globale
- Bilanciatore del carico delle applicazioni esterno regionale
- Bilanciatore del carico delle applicazioni interno tra regioni
- Bilanciatore del carico delle applicazioni interno regionale
- Bilanciatore del carico di rete passthrough esterno
Tieni presente che il valore predefinito effettivo della policy di bilanciamento del carico per le località
(localityLbPolicy
) cambia in base alle impostazioniaffinità sessionee. Se l'affinità sessione non è configurata, ovvero se l'affinità di sessione rimane al valore predefinito di NONE
, il valore predefinito per localityLbPolicy
è ROUND_ROBIN
. Se
l'affinità sessione è impostata su un valore diverso da NONE
, il
valore predefinito per localityLbPolicy
è MAGLEV
.
Per configurare una policy di località di bilanciamento del carico, puoi utilizzare la
consoleGoogle Cloud , gcloud
(--locality-lb-policy
)
o l'API
(localityLbPolicy
).
Cloud Service Mesh e distribuzione del traffico
Cloud Service Mesh utilizza anche le risorse del 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, la distribuzione del traffico
si basa sulla combinazione di una modalità di bilanciamento del carico e di una
policy di bilanciamento del carico. Il servizio di backend indirizza il traffico a un backend
in base alla modalità di bilanciamento del backend. Poi Cloud Service Mesh distribuisce
il traffico in base a un criterio di bilanciamento del carico.
I servizi di backend interni con gestione indipendente supportano le seguenti modalità di bilanciamento del carico:
UTILIZATION
, se tutti i backend sono gruppi di istanzeRATE
, 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.
Sottoinsieme del backend
Il sottoinsieme di backend è una funzionalità facoltativa che migliora le prestazioni e la scalabilità assegnando un sottoinsieme di backend a ciascuna delle istanze proxy.
Il sottoinsieme del backend è supportato per quanto segue:
- Bilanciatore del carico delle applicazioni interno regionale
- Bilanciatore del carico di rete passthrough interno
Impostazione secondaria del backend per i bilanciatori del carico delle applicazioni interni regionali
Il bilanciatore del carico delle applicazioni interno tra regioni non supporta il sottoinsieme di backend.Per i bilanciatori del carico delle applicazioni interni regionali, il sottoinsieme di backend assegna automaticamente solo un sottoinsieme dei backend all'interno del servizio di backend regionale a ogni istanza proxy. Per impostazione predefinita, ogni istanza proxy apre connessioni a tutti i backend all'interno di un servizio di backend. Quando il numero di istanze proxy e i backend sono entrambi elevati, l'apertura di connessioni a tutti i backend può causare problemi di prestazioni.
Se attivi il sottoinsieme, ogni proxy apre connessioni solo a un sottoinsieme dei backend, riducendo il numero di connessioni mantenute aperte a ogni backend. La riduzione del numero di connessioni aperte contemporaneamente a ogni backend può migliorare le prestazioni sia dei backend sia dei proxy.
Il seguente diagramma mostra un bilanciatore del carico con due proxy. Senza il sottoinsieme di backend, il traffico di entrambi i proxy viene distribuito a tutti i backend nel servizio di backend 1. Se il sottoinsieme di backend è abilitato, il traffico di ogni proxy viene distribuito a un sottoinsieme dei backend. Il traffico dal proxy 1 viene distribuito ai backend 1 e 2, mentre il traffico dal proxy 2 viene distribuito ai backend 3 e 4.
Puoi perfezionare ulteriormente il traffico di bilanciamento del carico verso i backend impostando il criterio
localityLbPolicy
.
Per saperne di più, consulta le norme sul traffico.
Per informazioni sulla configurazione dell'impostazione secondaria del backend per i bilanciatori del carico delle applicazioni interni, consulta Configura l'impostazione secondaria del backend.
Avvertenze relative all'impostazione secondaria del backend per il bilanciatore del carico delle applicazioni interno
- Sebbene il sottoinsieme di backend sia progettato per garantire che tutte le istanze di backend
rimangano ben utilizzate, può introdurre un certo bias nella quantità di traffico che
ogni backend riceve. L'impostazione di
localityLbPolicy
suLEAST_REQUEST
è consigliata per i servizi di backend sensibili al bilanciamento del carico di backend. - L'attivazione o la disattivazione del sottoinsieme interrompe le connessioni esistenti.
- Il sottoinsieme del backend richiede che l'affinità sessione sia
NONE
(un hash a 5 tuple). Altre opzioni di affinità sessione possono essere utilizzate solo se il sottoinsieme di backend è disabilitato. I valori predefiniti dei flag--subsetting-policy
e--session-affinity
sono entrambiNONE
e solo uno di questi alla volta può essere impostato su un valore diverso.
Impostazione secondaria del backend per il bilanciatore del carico di rete passthrough interno
Il sottoinsieme di backend per i bilanciatori del carico di rete passthrough interni consente di scalare il bilanciatore del carico di rete passthrough interno per supportare un numero maggiore di istanze VM di backend per servizio di backend interno.
Per informazioni su come il sottoinsieme influisce su questo limite, consulta la sezione "Servizi di backend" di Quote e limiti delle risorse di bilanciamento del carico.
Per impostazione predefinita, il sottoinsieme è disabilitato, il che limita il servizio di backend alla distribuzione a un massimo di 250 istanze o endpoint di backend. Se il tuo servizio di backend deve supportare più di 250 backend, puoi attivare la creazione di sottoinsiemi. Quando il sottoinsieme è abilitato, per ogni connessione client viene selezionato un sottoinsieme di istanze di backend.
Il seguente diagramma mostra un modello ridotto della differenza tra queste due modalità di funzionamento.
Senza il sottoinsieme, l'insieme completo di backend integri viene utilizzato meglio e le nuove connessioni client vengono distribuite tra tutti i backend integri in base alla distribuzione del traffico. Il sottoinsieme impone limitazioni al bilanciamento del carico, ma consente al bilanciatore del carico di supportare più di 250 backend.
Per le istruzioni di configurazione, vedi Sottoinsieme.
Avvertenze relative al sottoinsieme di backend per il bilanciatore del carico di rete passthrough interno
- Quando il subset è abilitato, non tutti i backend riceveranno traffico da un determinato mittente anche quando il numero di backend è ridotto.
- Per il numero massimo di istanze di backend quando è abilitata la creazione di sottoinsiemi, consulta la pagina delle quote .
- È supportata solo l'affinità sessione a 5 tuple con il sottoinsieme.
- Mirroring pacchetto non è supportato con la selezione di sottoinsiemi.
- L'attivazione o la disattivazione del sottoinsieme interrompe le connessioni esistenti.
- Se i client on-premise devono accedere a un bilanciatore del carico di rete passthrough interno, il subset può ridurre notevolmente il numero di backend che ricevono connessioni dai client on-premise. Questo perché la regione del tunnel Cloud VPN o del collegamento VLAN di Cloud Interconnect determina il sottoinsieme dei backend del bilanciatore del carico. Tutti gli endpoint Cloud VPN e Cloud Interconnect in una regione specifica utilizzano lo stesso sottoinsieme. In regioni diverse vengono utilizzati sottoinsiemi diversi.
Prezzi del sottoinsieme di backend
Non è previsto alcun costo per l'utilizzo del sottoinsieme del backend. Per ulteriori informazioni, consulta la pagina Tutti i prezzi di networking.
Affinità sessione
L'affinità di sessione ti consente di controllare in modo prevedibile la modalità di selezione dei backend da parte del bilanciatore del carico per le nuove connessioni, a condizione che il numero di backend integri rimanga costante. Ciò è utile per le applicazioni che richiedono che più richieste di un determinato utente vengano indirizzate allo stesso backend o endpoint. Queste applicazioni in genere includono server stateful utilizzati per la pubblicazione di annunci, giochi o servizi con memorizzazione nella cache interna pesante.
Google Cloud I bilanciatori del carico forniscono l'affinità sessione al meglio delle possibilità. Fattori come la modifica degli stati del controllo di integrità del backend, l'aggiunta o la rimozione di backend, le modifiche ai pesi del backend (inclusa l'attivazione o la disattivazione del bilanciamento ponderato) o le modifiche alla pienezza del backend, misurate in base alla modalità di bilanciamento, possono interrompere l'affinità sessione.
Il bilanciamento del carico con affinità sessione funziona bene quando la distribuzione delle connessioni uniche è ragionevolmente ampia. Un numero ragionevolmente elevato significa almeno diverse volte il numero di backend. Il test di un bilanciatore del carico con un numero ridotto di connessioni non produrrà una rappresentazione accurata della distribuzione delle connessioni client tra i backend.
Per impostazione predefinita, tutti i bilanciatori del carico Google Cloud selezionano i backend utilizzando un hash a cinque tuple (--session-affinity=NONE
), come segue:
- Indirizzo IP di origine del pacchetto
- Porta di origine del pacchetto (se presente nell'intestazione del pacchetto)
- Indirizzo IP di destinazione del pacchetto
- Porta di destinazione del pacchetto (se presente nell'intestazione del pacchetto)
- Protocollo del pacchetto
Per saperne di più sull'affinità sessione per i bilanciatori del carico di rete passthrough, consulta i seguenti documenti:
- Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni
- Distribuzione del traffico per i bilanciatori del carico di rete passthrough interni
Per saperne di più sull'affinità sessione per i bilanciatori del carico delle applicazioni, consulta i seguenti documenti:
- Affinità sessione per i bilanciatori del carico delle applicazioni esterni
- Affinità sessione per i bilanciatori del carico delle applicazioni interni
Per saperne di più sull'affinità sessione per i bilanciatori del carico di rete proxy, consulta i seguenti documenti:
- Affinità sessione per i bilanciatori del carico di rete proxy esterni
- Affinità sessione per i bilanciatori del carico di rete proxy interni
Timeout del servizio di backend
La maggior parte dei Google Cloud bilanciatori del carico ha un timeout del servizio di backend. Il valore predefinito è 30 secondi. L'intervallo completo di valori di timeout consentiti è 1 - 2.147.483.647 secondi.
Per i bilanciatori del carico delle applicazioni esterni e interni che utilizzano il protocollo HTTP, HTTPS o HTTP/2, il timeout del servizio di backend è un timeout di richiesta e risposta per il traffico HTTP(S).
Per ulteriori dettagli sul timeout del servizio di backend per ogni bilanciatore del carico, consulta quanto segue:
- Per i bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico delle applicazioni esterni a livello di regione, consulta Timeout e tentativi.
- Per i bilanciatori del carico delle applicazioni interni, consulta Timeout e tentativi.
Per i bilanciatori del carico di rete proxy esterni,il timeout è un timeout di inattività. Per consentire più o meno tempo prima dell'eliminazione della connessione, modifica il valore di timeout. Questo timeout di inattività viene utilizzato anche per le connessioni WebSocket.
Per i bilanciatori del carico di rete passthrough interni ed esterni,puoi impostare il valore del timeout del servizio di backend utilizzando
gcloud
o l'API, ma il valore viene ignorato. Il timeout del servizio di backend non ha significato per questi bilanciatori del carico pass-through.
- Per Cloud Service Mesh, il campo timeout del servizio di backend (specificato utilizzando
timeoutSec
) non è supportato con i servizi gRPC senza proxy. Per questi servizi, configura il timeout del servizio di backend utilizzando il campomaxStreamDuration
. Questo perché gRPC non supporta la semantica ditimeoutSec
, che specifica la quantità di tempo da attendere prima che un backend restituisca una risposta completa dopo l'invio della richiesta. Il timeout di gRPC specifica la quantità di tempo da attendere dall'inizio dello stream fino al completamento dell'elaborazione della risposta, inclusi tutti i tentativi.
Controlli di integrità
Ogni servizio di backend i cui backend sono gruppi di istanze o NEG a livello di zona deve avere un controllo di integrità associato. I servizi di backend che utilizzano un NEG serverless o un NEG internet globale come backend non devono fare riferimento a un controllo di integrità.
Quando crei un bilanciatore del carico utilizzando la console Google Cloud , puoi creare il controllo di integrità, se necessario, quando crei il bilanciatore del carico oppure puoi fare riferimento a un controllo di integrità esistente.
Quando crei un servizio di backend utilizzando backend di gruppi di istanze o NEG di zona utilizzando Google Cloud CLI o l'API, devi fare riferimento a un controllo di integrità esistente. Per informazioni dettagliate sul tipo e sull'ambito del controllo di integrità richiesto, consulta la guida al bilanciatore del carico nella panoramica dei controlli di integrità.
Per saperne di più, leggi i seguenti documenti:
- Panoramica dei controlli di integrità
- Creazione di controlli di integrità
- Pagina del controllo di integrità di
gcloud
- Pagina di controllo di integrità dell'API REST
Funzionalità aggiuntive abilitate sulla risorsa del servizio di backend
Le seguenti funzionalità facoltative sono supportate da alcuni servizi di backend.
Cloud CDN
Cloud CDN utilizza la rete perimetrale globale di Google per distribuire i contenuti nelle aree più vicine agli utenti al fine di velocizzare i siti web e le applicazioni. Cloud CDN è attivato sui servizi di backend utilizzati dai bilanciatori del carico delle applicazioni esterni globali. Il bilanciatore del carico fornisce porte e indirizzi IP frontend che ricevono le richieste e backend che rispondono alle richieste.
Per maggiori dettagli, consulta la documentazione di Cloud CDN.
Cloud CDN non è compatibile con IAP. Non possono essere abilitati sullo stesso servizio di backend.
Cloud Armor
Se utilizzi uno dei seguenti bilanciatori del carico, puoi aggiungere ulteriore protezione alle tue applicazioni attivando Cloud Armor sul servizio di backend durante la creazione del bilanciatore del carico:
- Bilanciatore del carico delle applicazioni esterno globale
- Bilanciatore del carico delle applicazioni classico
- Bilanciatore del carico di rete proxy esterno globale
- Bilanciatore del carico di rete proxy classico
Se utilizzi la console Google Cloud , puoi eseguire una delle seguenti operazioni:
- Seleziona un criterio di sicurezza di Cloud Armor esistente.
- Accetta la configurazione di un criterio di sicurezza di limitazione della frequenza di Cloud Armor predefinito con parametri di limitazione della frequenza, chiave, intervallo, conteggio delle richieste e nome personalizzabili. Se utilizzi Cloud Armor con un servizio proxy upstream, ad esempio un provider CDN,
Enforce_on_key
deve essere impostato come indirizzo IP XFF. - Scegli di disattivare la protezione Cloud Armor selezionando Nessuno.
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 dell'accesso a livello di applicazione invece di dover fare affidamento su firewall a livello di rete. IAP è supportato da alcuni bilanciatori del carico delle applicazioni.
IAP non è compatibile con Cloud CDN. Non possono essere abilitati sullo stesso servizio di backend.
Funzionalità di gestione avanzata del traffico
Per scoprire di più sulle funzionalità di gestione avanzata del traffico configurate nei servizi di backend e nelle mappe URL associate ai bilanciatori del carico, consulta quanto segue:
- Panoramica della gestione del traffico per i bilanciatori del carico delle applicazioni interni
- Panoramica della gestione del traffico per bilanciatori del carico delle applicazioni esterni globali
- Panoramica della gestione del traffico per i bilanciatori del carico delle applicazioni esterni regionali
API e riferimenti gcloud
Per ulteriori informazioni sulle proprietà della risorsa del servizio di backend, consulta i seguenti riferimenti:
Passaggi successivi
Per la documentazione correlata e informazioni su come vengono utilizzati i servizi di backend nel bilanciamento del carico, consulta quanto segue:
- Creare intestazioni personalizzate
- Crea un bilanciatore del carico delle applicazioni esterno
- Panoramica del bilanciatore del carico delle applicazioni esterno
- Abilita svuotamento delle connessioni
- Crittografia dei dati in transito in Google Cloud
Per i video correlati: