In questa pagina viene descritto come utilizzare un criterio di bilanciamento del carico del servizio per supportare ottimizzazioni avanzate di costi, latenza e resilienza per il seguente carico bilanciatori del carico:
- Bilanciatore del carico delle applicazioni esterno globale
- Bilanciatore del carico delle applicazioni interno tra regioni
- Bilanciatore del carico di rete proxy esterno globale
- Bilanciatore del carico di rete proxy interno tra regioni
Cloud Service Mesh supporta anche le ottimizzazioni del bilanciamento del carico avanzate. Per vedi Bilanciamento del carico avanzato panoramica nel documentazione di Cloud Service Mesh.
Un criterio di bilanciamento del carico del servizio (serviceLbPolicy
) è una risorsa associata
con il backend del bilanciatore del carico
Google Cloud. Un criterio di bilanciamento del carico del servizio
consente 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 all'interno di una particolare regione o zona.
- Abilita lo svuotamento automatico della capacità in modo che il bilanciatore del carico possa svuotarsi rapidamente da backend in stato non integro.
- Imposta una soglia di failover per determinare quando un backend è considerato non integro. Questo consente il failover del traffico verso un backend diverso per evitare uno stato non integro di backend.
Inoltre, puoi designare backend specifici come backend preferiti. Questi i backend devono essere utilizzati al massimo prima che le richieste vengano inviate di backend.
Il seguente diagramma mostra in che modo Cloud Load Balancing valuta il routing, il carico di Google Cloud e la distribuzione del traffico.
Prima di iniziare
Prima di esaminare i contenuti di questa pagina, esamina attentamente la Richiesta di distribuzione del carico descritto nella panoramica del bilanciatore del carico delle applicazioni esterno . Per bilanciatori del carico che sono sempre di livello Premium, algoritmi descritti in questa pagina supportano lo sversamento tra regioni se una la regione di prima scelta è già piena.
Backend supportati
I criteri di bilanciamento del carico del servizio e i backend preferiti possono essere configurati solo sui bilanciatori del carico che utilizzano i backend supportati, come indicato seguente.
Backend | Supportata? |
---|---|
Gruppi di istanze
|
|
MIG a livello di area geografica | |
NEG a livello di zona (GCE_VM_IP_PORT endpoint) |
|
NEG ibrido (NON_GCP_PRIVATE_IP_PORT endpoint) |
|
NEG serverless | |
NEG Internet | |
NEG Private Service Connect |
Algoritmi di bilanciamento del carico
Questa sezione descrive gli algoritmi di bilanciamento del carico che puoi configurare in un
e il criterio di bilanciamento del carico
del servizio. Se non configuri un algoritmo o
non configura affatto un criterio di bilanciamento del carico del servizio, il bilanciatore del carico utilizza
WATERFALL_BY_REGION
per impostazione predefinita.
A cascata per regione
WATERFALL_BY_REGION
è l'algoritmo di bilanciamento del carico predefinito. Con questo
dell'algoritmo, in forma aggregata, tutti i Google Front End (GFE) in una regione tentano di
e riempie i backend in proporzione alle capacità target configurate (modificate
dei relativi scaler di capacità).
Ogni singolo GFE di secondo livello preferisce selezionare istanze di backend o
endpoint in una zona il più vicina possibile (definita dall'opzione
al GFE di secondo livello. Perché WATERFALL_BY_REGION
riduce al minimo la latenza
tra zone, con frequenze di richieste ridotte, ogni GFE di secondo livello può
di inviare richieste ai backend nella zona preferita del GFE di secondo livello.
Spray a regione
L'algoritmo SPRAY_TO_REGION
modifica il comportamento singolo di ogni
GFE di secondo livello nella misura in cui ogni GFE di secondo livello non ha preferenze
per selezionare istanze di backend o endpoint che si trovano in una zona il più vicina
possibile al GFE di secondo livello. Con SPRAY_TO_REGION
, ciascuno di secondo livello
GFE invia richieste a tutte le istanze di backend o a tutti gli endpoint, in tutte le zone
regione, senza la preferenza per un tempo di round trip più breve tra le
un GFE di secondo livello e le istanze o gli endpoint di backend.
Come WATERFALL_BY_REGION
, in forma aggregata, tutti i GFE di secondo livello della regione
e riempie i backend in proporzione alle capacità target configurate (modificate
dei relativi scaler di capacità).
Mentre SPRAY_TO_REGION
fornisce una distribuzione più uniforme tra i backend in tutto
zone di una regione, soprattutto con tassi di richiesta bassi, questa distribuzione uniforme
comporta le seguenti considerazioni:
- Quando i backend smettono di funzionare (ma continuano a superare i controlli di integrità), i GFE di secondo livello sono interessati, sebbene l'impatto individuale sia meno grave.
- Poiché ogni GFE di secondo livello non ha preferenze per una zona rispetto a un'altra, i GFE di secondo livello creano più traffico tra zone. In base al numero di richieste in fase di elaborazione, ogni GFE di secondo livello potrebbe creare e le connessioni ai backend.
A cascata per zona
L'algoritmo WATERFALL_BY_ZONE
modifica il comportamento singolo di ogni
GFE di secondo strato, nella misura in cui ogni GFE di secondo livello ha un
la preferenza per selezionare le istanze di backend o gli endpoint che si trovano
più vicina possibile
al GFE di secondo livello. Con WATERFALL_BY_ZONE
, ciascuno
i GFE di secondo livello inviano solo richieste alle istanze di backend o agli endpoint
le altre zone della regione quando il GFE di secondo livello ha riempito (o
(proporzionalmente sovraccarico) di backend o endpoint in quello più favorito
zona di destinazione.
Come WATERFALL_BY_REGION
, in forma aggregata, tutti i GFE di secondo livello della regione
e riempie i backend in proporzione alle capacità target configurate (modificate
dei relativi scaler di capacità).
L'algoritmo WATERFALL_BY_ZONE
riduce al minimo la latenza con quanto segue
considerazioni:
WATERFALL_BY_ZONE
non minimizza intrinsecamente le connessioni tra zone. La l'algoritmo è guidato solo dalla latenza.WATERFALL_BY_ZONE
non garantisce che ogni GFE di secondo livello sempre riempie la sua zona preferita prima di riempire altre zone. Gli eventi di manutenzione possono causano temporaneamente l'invio di tutto il traffico da un GFE di secondo livello al backend istanze o endpoint in un'altra zona.WATERFALL_BY_ZONE
può comportare una distribuzione meno uniforme delle richieste tra tutte le istanze di backend o gli endpoint all'interno della regione nel suo insieme. Ad esempio: istanze di backend o endpoint nella zona più preferita del GFE di secondo livello potrebbe essere riempito alla capacità massima mentre i backend in altre zone non sono riempiti e la capacità di archiviazione.
Confrontare gli algoritmi di bilanciamento del carico
La tabella seguente mette a confronto i diversi algoritmi di bilanciamento del carico.
Comportamento | A cascata per regione | Spray a regione | A cascata per zona |
---|---|---|---|
Utilizzo uniforme della capacità all'interno di una singola regione | Sì | Sì | No |
Utilizzo uniforme della capacità in più regioni | No | No | No |
Suddivisione uniforme del traffico dal bilanciatore del carico | No | Sì | No |
Distribuzione del traffico tra zone | Sì. Il traffico viene distribuito uniformemente tra le zone in un regione, ottimizzando al contempo la latenza di rete. Potrebbe essere inviato il traffico tra zone, se necessario. | Sì | Sì. Il traffico arriva prima alla zona più vicina fino al raggiungimento della capacità massima. Quindi va alla zona più vicina successiva. |
Sensibilità ai picchi di traffico in una zona locale | Nella media; dipende da quanto traffico è già stato spostato tra zone diverse. | Minore; i picchi di singola zona sono distribuiti in tutte le zone del regione. | Maggiore; è probabile che i picchi in una singola zona vengano gestiti completamente dalla stessa zona finché il bilanciatore del carico non è in grado di reagire. |
Svuotamento automatico della capacità
Quando un backend non è integro, in genere vuoi escluderlo dal bilanciamento del carico il più rapidamente possibile. L'esclusione dei backend in stato non integro ottimizza complessivamente e la latenza minima, inviando il traffico solo a backend integri.
Quando si abilita la funzionalità di svuotamento automatico della capacità, il bilanciatore del carico
scala automaticamente la capacità di un backend fino a zero quando è inferiore al 25%
delle istanze o degli endpoint del backend superano i controlli di integrità. Questo
rimuove il backend in stato non integro dal pool di bilanciamento del carico globale.
Questa azione equivale a impostare
da backendService.capacityScaler
a 0
per un backend quando vuoi evitare
indirizzando il traffico a quel backend.
Se il 35% (10% al di sopra della soglia) di un precedente svuotamento automatico le istanze o gli endpoint del backend superano i controlli di integrità per 60 secondi, non viene svuotato automaticamente e viene aggiunto di nuovo al pool di bilanciamento del carico. Ciò garantisce che il backend sia veramente integro e non si muova tra svuotato e non scaricato.
Anche con lo svuotamento della capacità automatico abilitato, il bilanciatore del carico non svuota di più del 50% dei backend collegati a un servizio di backend, indipendentemente di integrità del backend. Mantenendo collegati il 50% dei backend, si riduce il rischio di sovraccaricare i backend integri.
Un caso d'uso dello svuotamento automatico della capacità è quello di utilizzarlo per ridurre al minimo il rischio di sovraccaricando i tuoi backend preferiti. Ad esempio, se un è contrassegnato come preferito, ma la maggior parte delle istanze o degli endpoint lo svuotamento non integro e a capacità automatica rimuove il backend dal bilanciamento del carico piscina. Invece di sovraccaricare le istanze o gli endpoint in stato integro rimanenti nel backend preferito, lo svuotamento automatico della capacità trasferisce il traffico di backend.
Puoi abilitare lo svuotamento della capacità automatica come parte del bilanciamento del carico del servizio . Per maggiori dettagli, consulta Configurare il bilanciamento del carico di un servizio .
La capacità automatica non è supportata con i backend che non utilizzano un bilanciamento . Sono inclusi come NEG internet, NEG serverless e NEG PSC.
Soglia di failover
Il bilanciatore del carico determina la distribuzione del traffico tra i backend su più livelli. Quando è in stato stabile, invia il traffico ai backend vengono selezionate in base a uno degli algoritmi di bilanciamento del carico descritti in precedenza. Questi backend, denominati backend principali, sono considerati ottimali in termini di latenza e capacità.
Il bilanciatore del carico tiene traccia anche di altri backend che possono essere utilizzati se i backend primari sono in stato non integro e non sono in grado di gestire il traffico. Questi sono chiamati backend di failover. Questi backend in genere si trovano nelle vicinanze con capacità rimanente.
Se le istanze o gli endpoint nel backend principale non sono integri, il carico non sposta immediatamente il traffico su altri backend. Invece, il carico sposta innanzitutto il traffico su altre istanze o endpoint in stato integro del stesso backend per contribuire a stabilizzare il carico del traffico. Se ci sono troppi endpoint in una sono in stato non integro e gli endpoint rimanenti nello stesso backend in grado di gestire il traffico aggiuntivo, il bilanciatore del carico utilizza il failover per determinare quando iniziare a inviare traffico a un backend di failover. La il bilanciatore del carico tollera l'integrità del backend principale fino al failover soglia. In seguito, il traffico viene spostato dal backend principale.
La soglia di failover è un valore compreso tra 1 e 99, espressa come percentuale in un backend che deve essere integro. Se la percentuale di stato integro è inferiore alla soglia di failover, il bilanciatore del carico tenta di inviare a un backend di failover. Per impostazione predefinita, la soglia di failover è 70.
Se la soglia di failover è impostata troppo elevata, si possono verificare sversamenti non necessari di traffico a causa di cambiamenti temporanei dello stato di salute. Se la soglia di failover è impostata su un valore troppo basso, continua a inviare traffico ai backend primari anche se ci sono molti endpoint in stato non integro.
Le decisioni di failover sono localizzate. Ogni Google Front End (GFE) locale si comporta indipendentemente l'una dall'altra. È tua responsabilità garantire che i tuoi i backend di failover possono gestire il traffico aggiuntivo.
Il traffico di failover può causare backend sovraccarichi. Anche se un backend è in esecuzione in stato non integro, il bilanciatore del carico potrebbe comunque inviare traffico a quella posizione. Per escludere in stato non integro dal pool di backend disponibili, abilita funzionalità di svuotamento capacità automatica.
Backend preferiti
I backend preferiti sono quelli di cui vuoi utilizzare completamente la capacità prima sversando il traffico ad altri backend. Qualsiasi traffico oltre il valore la capacità dei backend preferiti viene instradata ai restanti di backend. L'algoritmo di bilanciamento del carico distribuisce quindi il traffico tra i backend non preferiti di un servizio di backend.
Puoi configurare il bilanciatore del carico in modo da preferire e utilizzare completamente uno o più backend collegati a un servizio di backend prima del routing successivo richieste ai backend rimanenti.
Considera le seguenti limitazioni quando utilizzi i backend preferiti:
- I backend configurati come backend preferiti potrebbero essere più lontani e comportano una latenza media più alta per le richieste dei client. Questo anche se ci sono altri backend più vicini che potrebbero aver gestito le con una latenza minore.
- Alcuni algoritmi di bilanciamento del carico (
WATERFALL_BY_REGION
,SPRAY_TO_REGION
, eWATERFALL_BY_ZONE
) non si applicano ai backend configurati come preferiti di backend.
Per scoprire come impostare i backend preferiti, consulta l'articolo Impostare i backend preferiti di backend.
Configura un criterio di bilanciamento del carico del servizio
La risorsa del criterio di bilanciamento del carico del servizio consente di configurare quanto segue campi:
- Algoritmo di bilanciamento del carico
- Svuotamento automatico della capacità
- Soglia di failover
Per impostare un backend preferito, consulta l'articolo Impostare il backend preferito di backend.
Crea un criterio
Per creare e configurare un criterio di bilanciamento del carico del servizio, completa il seguenti passaggi:
Creare una risorsa del criterio di bilanciamento del carico del servizio. Puoi eseguire questa operazione utilizzando un file YAML oppure direttamente tramite i parametri
gcloud
.Con un file YAML. Puoi specificare i criteri di bilanciamento del carico del servizio in un file YAML . Ecco un file YAML di esempio che mostra come configurare un carico di bilanciamento del carico, abilitare lo svuotamento automatico della capacità e impostare un'istanza soglia di failover:
name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME autoCapacityDrain: enable: True failoverConfig: failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
Sostituisci quanto segue:
- PROJECT_ID: l'ID progetto.
- SERVICE_LB_POLICY_NAME: il nome del servizio e il criterio di bilanciamento del carico.
- FAILOVER_THRESHOLD_VALUE: la soglia di failover valore. Deve essere un numero compreso tra 1 e 99.
- LOAD_BALANCING_ALGORITHM: il bilanciamento del carico
l'algoritmo da utilizzare. Può essere
SPRAY_TO_REGION
,WATERFALL_BY_REGION
oWATERFALL_BY_ZONE
.
Dopo aver creato il file YAML, importa il file in un nuovo servizio e il criterio di bilanciamento del carico.
gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \ --source=PATH_TO_POLICY_FILE \ --location=global
Senza un file YAML. In alternativa, puoi configurare il carico del servizio delle funzionalità dei criteri senza utilizzare un file YAML.
Per impostare l'algoritmo di bilanciamento del carico e abilitare il svuotamento automatico, utilizza la classe seguenti parametri:
gcloud network-services service-lb-policies create SERVICE_LB_POLICY_NAME \ --load-balancing-algorithm=LOAD_BALANCING_ALGORITHM \ --auto-capacity-drain \ --failover-health-threshold=FAILOVER_THRESHOLD_VALUE \ --location=global
Sostituisci quanto segue:
- SERVICE_LB_POLICY_NAME: il nome del servizio e il criterio di bilanciamento del carico.
- LOAD_BALANCING_ALGORITHM: il bilanciamento del carico
l'algoritmo da utilizzare. Può essere
SPRAY_TO_REGION
,WATERFALL_BY_REGION
oWATERFALL_BY_ZONE
. - FAILOVER_THRESHOLD_VALUE: la soglia di failover valore. Deve essere un numero compreso tra 1 e 99.
Aggiorna un servizio di backend in modo che il relativo campo
--service-lb-policy
fa riferimento alla risorsa del criterio di bilanciamento del carico del servizio appena creata. R il servizio di backend può essere associato a un solo bilanciamento del carico del servizio risorsa del criterio.gcloud compute backend-services update BACKEND_SERVICE_NAME \ --service-lb-policy=SERVICE_LB_POLICY_NAME \ --global
Puoi associare un criterio di bilanciamento del carico del servizio a un servizio di backend durante la creazione del servizio di backend.
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --protocol=PROTOCOL \ --port-name=NAMED_PORT_NAME \ --health-checks=HEALTH_CHECK_NAME \ --load-balancing-scheme=LOAD_BALANCING_SCHEME \ --service-lb-policy=SERVICE_LB_POLICY_NAME \ --global
Rimuovere un criterio
Per rimuovere un criterio di bilanciamento del carico del servizio da un servizio di backend, utilizza il seguente comando:
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --no-service-lb-policy \ --global
Imposta i backend preferiti
Puoi configurare i backend preferiti utilizzando Google Cloud CLI o l'API.
gcloud
Aggiungi un backend preferito
Per impostare un backend preferito, utilizza il comando gcloud compute backend-services
add-backend
per impostare il flag --preference
quando aggiungi il backend
di servizio di backend.
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ ... --preference=PREFERENCE \ --global
Sostituisci PREFERENCE con il livello di preferenza che vuoi
e assegnare al backend. Può essere PREFERRED
o DEFAULT
.
Il resto del comando dipende dal tipo di backend in uso
(gruppo di istanze o NEG). Per tutti i parametri obbligatori, consulta
Comando gcloud compute backend-services add-backend
.
Aggiorna la preferenza di un backend
Per aggiornare il parametro --preference
di un backend, utilizza la
Comando gcloud compute backend-services update-backend
.
gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \ ... --preference=PREFERENCE \ --global
Il resto del comando dipende dal tipo di backend in uso
(gruppo di istanze o NEG). Il comando di esempio seguente aggiorna un
la preferenza del gruppo di istanza di backend e la imposta su PREFERRED
:
gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \ --instance-group=INSTANCE_GROUP_NAME \ --instance-group-zone=INSTANCE_GROUP_ZONE \ --preference=PREFERRED \ --global
API
Per impostare un backend preferito, imposta il flag preference
su ogni
utilizzando la risorsa backendServices
globale.
Ecco un esempio che mostra come configurare la preferenza di backend:
name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
...
- backends
name: BACKEND_1_NAME
preference: PREFERRED
...
- backends
name: BACKEND_2_NAME
preference: DEFAULT
...
Sostituisci quanto segue:
- PROJECT_ID: ID progetto
- BACKEND_SERVICE_NAME: il nome del backend servizio
- BACKEND_1_NAME: il nome del preferito backend
- BACKEND_2_NAME: il nome del backend predefinito
Risoluzione dei problemi
I pattern di distribuzione del traffico possono cambiare quando colleghi un nuovo carico di servizio di bilanciamento del carico a un servizio di backend.
Per eseguire il debug dei problemi di traffico, usa Cloud Monitoring per scoprire come di traffico tra il bilanciatore del carico e il backend. Cloud Load Balancing log e metriche possono aiutarti a comprendere il comportamento di bilanciamento del carico.
Questa sezione riassume alcuni scenari comuni che potresti notare nella e una configurazione esposta al traffico.
Il traffico proveniente da una singola sorgente viene inviato a troppi backend distinti
Questo è il comportamento previsto dell'algoritmo SPRAY_TO_REGION
. Tuttavia,
potrebbero verificarsi problemi causati da una più ampia distribuzione del traffico. Per
Ad esempio, le percentuali di successo della cache potrebbero diminuire perché i backend rilevano il traffico proveniente
una più ampia selezione di clienti. In questo caso, valuta la possibilità di utilizzare altri algoritmi come
WATERFALL_BY_REGION
.
Il traffico non viene inviato a backend con molti endpoint in stato non integro
Questo è il comportamento previsto quando autoCapacityDrain
è abilitato. Backend
con molti endpoint in stato non integro vengono svuotati e rimossi dal carico
di bilanciamento del carico. Se non vuoi che questo comportamento sia corretto, puoi disattivare la capacità automatica.
svuotando la rete. Tuttavia, questo significa che il traffico può essere inviato ai backend con
di endpoint in stato non integro e le richieste possono non andare a buon fine.
Il traffico viene inviato a backend più distanti prima di quelli più vicini
Questo è il comportamento previsto se i tuoi backend preferiti si trovano a una distanza maggiore di dai backend predefiniti. Se non vuoi che sia così, aggiorna il le impostazioni delle preferenze per ogni backend di conseguenza.
Il traffico non viene inviato ad alcuni backend quando si utilizzano i backend preferiti
Questo è il comportamento previsto quando i tuoi backend preferiti non hanno ancora raggiunto e la capacità di archiviazione. I backend preferiti vengono assegnati per primi in base al tempo di round trip a questi backend.
Se vuoi che il traffico venga inviato ad altri backend, puoi procedere in uno dei seguenti modi:
- Aggiorna le impostazioni delle preferenze per gli altri backend.
- Configura un'impostazione di capacità target più bassa per i tuoi backend preferiti. Il target
la capacità viene configurata utilizzando
max-rate
omax-utilization
a seconda del bilanciamento del servizio di backend .
Il traffico viene inviato a un backend remoto durante cambiamenti di integrità temporanei
Questo è il comportamento previsto quando la soglia di failover è impostata su un valore valore. Se vuoi che il traffico continui verso i backend primari quando ci sono cambiamenti di integrità temporanei, imposta questo campo su un valore più basso.
Gli endpoint in stato integro sono sovraccaricati quando altri endpoint non sono integri
Questo è il comportamento previsto quando la soglia di failover è impostata su un valore basso valore. Quando gli endpoint sono in stato non integro, il traffico destinato a questi endpoint vengono invece distribuiti tra gli endpoint rimanenti nello stesso backend. Se vuoi che il comportamento di failover venga attivato prima, imposta questo campo su un un valore più alto.
Limitazioni
- Ogni servizio di backend può essere associato a un solo carico di servizio e la risorsa del criterio di bilanciamento.