Questa pagina descrive come configurare ottimizzazioni avanzate di costi, latenza e resilienza per i bilanciatori del carico delle applicazioni e i bilanciatori del carico di rete proxy.
Cloud Service Mesh supporta anche ottimizzazioni avanzate del bilanciamento del carico. Per maggiori dettagli, consulta la panoramica del bilanciamento del carico avanzato nella documentazione di Cloud Service Mesh.
Cloud Load Balancing offre le seguenti funzionalità avanzate:
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. Un criterio di bilanciamento del carico del servizio consente di personalizzare i seguenti parametri per influenzare la modalità di distribuzione del traffico tra i gruppi di backend associati a un servizio di backend:- Algoritmi di bilanciamento del carico. Personalizza l'algoritmo di bilanciamento del carico utilizzato per determinare come viene distribuito il traffico all'interno di una determinata regione o zona.
- Scarico rapido automatico della capacità. Attiva lo svuotamento automatico della capacità in modo che il bilanciatore del carico possa svuotare rapidamente il traffico dai backend non integri.
- Soglia di failover. Imposta una soglia di failover per determinare quando un backend è considerato in stato non integro. In questo modo il traffico esegue il failover su un backend diverso per evitare backend non integri.
- Isolamento del traffico. Previeni errori a cascata limitando o vietando l'overflow del traffico tra regioni.
Backend preferiti. 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.
Il seguente diagramma mostra come Cloud Load Balancing valuta il routing, il bilanciamento del carico e la distribuzione del traffico.
Prima di iniziare
Prima di esaminare i contenuti di questa pagina, rivedi attentamente la procedura di distribuzione delle richieste descritta nella pagina Panoramica del bilanciatore del carico delle applicazioni esterno. Per i bilanciatori del carico che sono sempre di livello Premium, tutti gli algoritmi di bilanciamento del carico descritti in questa pagina supportano lo spillover tra regioni se una regione di prima scelta è già piena.
Bilanciatori del carico e backend supportati
I seguenti bilanciatori del carico supportano le policy di bilanciamento del carico del servizio e i backend preferiti:
| Bilanciatore del carico | Policy di bilanciamento del carico del servizio | Backend preferiti |
|---|---|---|
| Bilanciatore del carico delle applicazioni esterno globale | ||
| Bilanciatore del carico delle applicazioni interno tra regioni | ||
| Bilanciatore del carico delle applicazioni esterno regionale (anteprima) | ||
| Bilanciatore del carico delle applicazioni interno regionale (anteprima) | ||
| Bilanciatore del carico di rete proxy esterno globale | ||
| Bilanciatore del carico di rete proxy interno tra regioni | ||
| Bilanciatore del carico di rete passthrough esterno globale |
Le funzionalità descritte in questa pagina richiedono backend compatibili che supportino una modalità di bilanciamento. I backend supportati sono riassunti nella tabella seguente:
| Backend | Supportata? |
|---|---|
| Gruppi di istanze | Sono supportati i gruppi di istanze gestite e non gestite a livello di zona, ma non i gruppi di istanze gestite a livello di regione. |
NEG a livello di zona (GCE_VM_IP_PORT endpoint) |
(per i bilanciatori del carico delle applicazioni e i bilanciatori del carico di rete proxy) |
NEG a livello di zona (GCE_VM_IP endpoint) |
(per i bilanciatori del carico di rete passthrough esterni globali) |
NEG ibridi (endpoint NON_GCP_PRIVATE_IP_PORT) |
(per i bilanciatori del carico delle applicazioni e i bilanciatori del carico di rete proxy) |
| 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 una
policy di bilanciamento del carico del servizio. Se non configuri un algoritmo o se non configuri una policy 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
algoritmo, in totale, tutti i front-end Google (GFE) di secondo livello nella
regione più vicina all'utente tentano di riempire i backend in proporzione alle
capacità target configurate (modificate dai relativi scalatori di capacità).
Ogni GFE di secondo livello preferisce selezionare istanze backend o endpoint in una zona il più vicino possibile (definito dal tempo di andata e ritorno della rete) al GFE di secondo livello. Poiché WATERFALL_BY_REGION riduce al minimo il traffico
tra le zone, a basse frequenze di richieste, ogni GFE di secondo livello potrebbe inviare richieste esclusivamente
ai backend nella stessa zona del GFE di secondo livello.
Se tutti i backend nella regione più vicina vengono eseguiti al limite di capacità configurato, il traffico inizierà a superare il limite nella regione più vicina successiva, ottimizzando al contempo la latenza di rete.
Spray a regione
L'algoritmo SPRAY_TO_REGION modifica il comportamento individuale di ogni
GFE di secondo livello in modo che ogni GFE di secondo livello non abbia preferenze
per la selezione di istanze o endpoint di backend che si trovano in una zona il più vicino
possibile al GFE di secondo livello. Con SPRAY_TO_REGION, ogni GFE di secondo livello
invia richieste a tutte le istanze o gli endpoint di backend, in tutte le zone della
regione, senza preferenza per un tempo di round trip più breve tra il
GFE di secondo livello e le istanze o gli endpoint di backend.
Come WATERFALL_BY_REGION, in totale, tutti i GFE di secondo livello nella regione
riempiono i backend in proporzione alle loro capacità target configurate (modificate dai
relativi scalatori di capacità).
Sebbene SPRAY_TO_REGION fornisca una distribuzione più uniforme tra i backend in tutte le zone di una regione, soprattutto a basse velocità di richiesta, questa distribuzione uniforme comporta le seguenti considerazioni:
- Quando i backend non funzionano (ma continuano a superare i controlli di integrità), vengono interessati più GFE di secondo livello, anche se l'impatto individuale è 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. A seconda del numero di richieste in elaborazione, ogni GFE di secondo livello potrebbe creare più connessioni TCP anche ai backend.
A cascata per zona
L'algoritmo WATERFALL_BY_ZONE modifica il comportamento individuale di ogni
GFE di secondo livello in modo che ognuno di questi GFE abbia una forte
preferenza per la selezione di istanze o endpoint di backend che si trovano nella
zona più vicina possibile al GFE di secondo livello. Con WATERFALL_BY_ZONE, ogni
GFE di secondo livello invia richieste a istanze o endpoint di backend in
altre zone della regione solo quando il GFE di secondo livello ha riempito (o
riempito proporzionalmente) istanze o endpoint di backend nella sua zona preferita.
Come WATERFALL_BY_REGION, in totale, tutti i GFE di secondo livello nella regione
riempiono i backend in proporzione alle loro capacità target configurate (modificate dai
relativi scalatori di capacità).
L'algoritmo WATERFALL_BY_ZONE riduce al minimo la latenza tenendo conto dei seguenti
fattori:
WATERFALL_BY_ZONEnon riduce intrinsecamente le connessioni tra zone. L'algoritmo è guidato solo dalla latenza.WATERFALL_BY_ZONEnon garantisce che ogni GFE di secondo livello riempia sempre la sua zona preferita prima di riempire le altre zone. Gli eventi di manutenzione possono causare temporaneamente l'invio di tutto il traffico da un GFE di secondo livello a istanze o endpoint di backend in un'altra zona.WATERFALL_BY_ZONEpuò comportare una distribuzione meno uniforme delle richieste tra tutte le istanze o tutti gli endpoint di backend all'interno della regione nel suo complesso. Ad esempio, le istanze o gli endpoint di backend nella zona più favorita del GFE di secondo livello potrebbero essere pieni, mentre i backend in altre zone non lo sono.
Confrontare gli algoritmi di bilanciamento del carico
La seguente tabella confronta 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 di una regione ottimizzando la latenza di rete. Se necessario, il traffico potrebbe essere inviato tra le zone. | Sì | Sì. Il traffico viene indirizzato prima alla zona più vicina finché non raggiunge la capacità massima. Poi, passa alla zona più vicina successiva. |
| Sensibilità ai picchi di traffico in una zona locale | Media; dipende dalla quantità di traffico già spostato per bilanciare tra le zone. | Inferiore; i picchi di una singola zona vengono distribuiti in tutte le zone della regione. | Più alto; è probabile che i picchi di una singola zona vengano gestiti interamente dalla stessa zona finché il bilanciatore del carico non è in grado di reagire. |
Scarico rapido automatico della capacità
Lo scarico rapido automatico della capacità e il ripristino della capacità combinano i concetti di controlli di integrità e capacità di backend. Con lo svuotamento automatico della capacità, i controlli di integrità vengono utilizzati come indicatore aggiuntivo per impostare la capacità di backend effettiva su zero. Con l'annullamento automatico dell'addestramento della capacità, i controlli di integrità vengono utilizzati come indicatore aggiuntivo per ripristinare la capacità di backend effettiva al suo valore precedente.
Senza il drenaggio e il ripristino automatici della capacità, se vuoi indirizzare le richieste lontano da tutti i backend di una determinata regione, devi impostare manualmente la capacità effettiva di ogni backend di quella regione su zero. Ad esempio, puoi utilizzare il gestore della scalabilità della capacità per farlo.
Con lo svuotamento e il ripristino automatici della capacità, i controlli di integrità possono essere utilizzati come segnale per regolare la capacità di un backend, tramite lo svuotamento o il ripristino.
Per abilitare lo svuotamento e il ripristino automatici della capacità, consulta Configura una policy di bilanciamento del carico del servizio.
Svuotamento automatico della capacità
Lo svuotamento automatico della capacità imposta la capacità di ogni gruppo di istanze di backend candidati allo svuotamento o NEG a zero, a condizione che il rapporto tra i gruppi di istanza di backend candidati allo svuotamento o i NEG e tutti i gruppi di istanze di backend o i NEG di backend sia inferiore al 50%. Nel calcolo del rapporto del 50%, i backend con capacità pari a zero non sono inclusi nel numeratore. Tuttavia, tutti i backend sono inclusi nel denominatore.
Un backend candidato svuotabile è un gruppo di istanza di backend o un NEG che ha meno del 25% delle istanze o degli endpoint membri che superano i controlli di integrità del bilanciatore del carico.
I backend con capacità pari a zero sono i seguenti:
- Gruppi di istanze di backend senza istanze membro, in cui la capacità del gruppo di istanze è definita in base alle singole istanze
- NEG di backend senza endpoint membri, in cui la capacità del NEG è definita in base a ogni endpoint
- Gruppi di istanze di backend o NEG i cui scalatori di capacità sono stati impostati su zero
La capacità di backend svuotata automaticamente è funzionalmente equivalente all'impostazione manuale di backendService.backends[].capacityScaler di un backend su 0, ma senza impostare il valore dello scalatore di capacità.
Annullamento dello scarico rapido automatico della capacità
L'annullamento dell'addestramento della capacità automatica riporta la capacità di un backend al valore controllato dallo strumento di scalabilità della capacità del backend quando il 35% o più delle istanze o degli endpoint del backend supera i controlli di integrità per almeno 60 secondi. Il requisito di 60 secondi riduce le probabilità di svuotamento e riempimento sequenziali quando i controlli di integrità non riescono e riescono in rapida successione.
Soglia di failover
Il bilanciatore del carico determina la distribuzione del traffico tra i backend in modo multilivello. In stato stazionario, invia il traffico ai backend selezionati in base a uno degli algoritmi di bilanciamento del carico descritti in precedenza. Questi backend, chiamati 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 principali non sono integri e non sono in grado di gestire il traffico. Questi backend sono chiamati backend di failover. Questi backend si trovano in genere nelle vicinanze dei backend con capacità rimanente.
Se le istanze o gli endpoint nel backend primario non sono integri, il bilanciatore del carico non sposta immediatamente il traffico su altri backend. Il bilanciatore del carico sposta prima il traffico su altre istanze o endpoint integri nello stesso backend per contribuire a stabilizzare il carico di traffico. Se troppi endpoint in un backend principale non sono integri e gli endpoint rimanenti nello stesso backend non sono in grado di gestire il traffico aggiuntivo, il bilanciatore del carico utilizza la soglia di failover per determinare quando iniziare a inviare traffico a un backend di failover. Il bilanciatore del carico tollera lo stato non integro nel backend principale fino alla soglia di failover. Dopodiché, il traffico viene spostato dal backend principale.
La soglia di failover è un valore compreso tra 1 e 99, espresso come percentuale di endpoint in un backend che devono essere integri. Se la percentuale di endpoint integri scende al di sotto della soglia di failover, il bilanciatore del carico tenta di inviare traffico a un backend di failover. Per impostazione predefinita, la soglia di failover è 70.
Se la soglia di failover è impostata su un valore troppo alto, possono verificarsi spillover di traffico non necessari a causa di variazioni temporanee dello stato. Se la soglia di failover è impostata su un valore troppo basso, il bilanciatore del carico continua a inviare traffico ai backend principali anche se sono presenti molti endpoint non integri.
Le decisioni di failover sono localizzate. Ogni Google Front End (GFE) locale si comporta in modo indipendente dagli altri. È tua responsabilità assicurarti che i backend di failover possano gestire il traffico aggiuntivo.
Il traffico di failover può causare il sovraccarico dei backend. Anche se un backend non è integro, il bilanciatore del carico potrebbe comunque inviare traffico. Per escludere i backend non integri dal pool di backend disponibili, attiva la funzionalità di scarico rapido automatico della capacità.
Isolamento del traffico
Per impostazione predefinita, Cloud Load Balancing utilizza l'algoritmo WATERFALL_BY_REGION per
decidere dove instradare il traffico degli utenti. Con WATERFALL_BY_REGION,
il traffico viene trasferito ad altre regioni quando i backend nella regione più vicina all'utente sono pieni o non integri. L'attivazione dell'isolamento del traffico consente al bilanciatore del carico di instradare il traffico solo alla regione più vicina all'utente, anche se tutti i backend di quella regione funzionano al limite di capacità configurato. L'attivazione dell'isolamento del traffico può aiutarti a prevenire errori regionali a cascata e a limitare le potenziali interruzioni a una singola regione.
Sono disponibili due modalità di isolamento:
NEAREST (impostazione predefinita), in cui il bilanciatore del carico (ovvero il GFE di secondo livello o il proxy Envoy che gestisce la connessione) invia il traffico ai backend nella regione più vicina all'utente. Se non sono configurati backend nella regione più vicina o se i backend nella regione più vicina non sono integri, il traffico viene indirizzato alla regione più vicina successiva, ottimizzando al contempo la latenza di rete. Questo continua man mano che ogni regione esaurisce la capacità di pubblicazione.
STRICT, in cui il bilanciatore del carico (ovvero il proxy Envoy che gestisce la connessione) invia il traffico solo ai backend nella regione più vicina all'utente. Se non sono configurati backend nella regione più vicina o se i backend nella regione più vicina non sono integri e non possono gestire le richieste, il traffico viene eliminato e le richieste iniziano a non andare a buon fine.
Nessun isolamento
Il seguente diagramma mostra il comportamento dei bilanciatori del carico cross-region quando l'isolamento del traffico non è abilitato.
Più vicino
Il seguente diagramma mostra il comportamento dei bilanciatori del carico multiregionali quando
l'isolamento del traffico è abilitato con la modalità NEAREST.
Restrittiva
Il seguente diagramma mostra il comportamento dei bilanciatori del carico multiregionali quando
l'isolamento del traffico è abilitato con la modalità STRICT.
Tieni presente le seguenti considerazioni prima di attivare questa funzionalità:
Se i backend in una regione sono sovraccarichi, il bilanciatore del carico potrebbe comunque inviare traffico aggiuntivo anche se i backend in altre regioni possono gestirlo. Ciò significa che è più probabile che i backend di ogni singola regione si sovraccarichino a causa del traffico aggiuntivo e devi pianificare di conseguenza.
Anche con l'isolamento abilitato, il traffico viene comunque instradato da un control plane globale. Ciò significa che esiste ancora la possibilità di guasti globali in più regioni. Per un migliore isolamento a livello di infrastruttura, scegli un bilanciatore del carico regionale.
Quando configuri la modalità di isolamento del traffico, devi impostare anche la granularità
dell'isolamento su REGION, il che impedisce l'overflow del traffico tra regioni. Se la granularità non è configurata, l'isolamento del traffico non verrà applicato. Per informazioni dettagliate
su come attivare l'isolamento del traffico, consulta Configurare una policy di bilanciamento del carico
del servizio.
Backend preferiti
I backend preferiti sono quelli di cui vuoi usare completamente la capacità prima di trasferire il traffico ad altri backend. Il traffico superiore alla capacità configurata dei backend preferiti viene indirizzato ai backend non preferiti rimanenti. 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 che preferisca e utilizzi completamente uno o più backend collegati a un servizio di backend prima di indirizzare le richieste successive ai backend rimanenti.
Tieni presenti le seguenti limitazioni quando utilizzi i backend preferiti:
- I backend configurati come backend preferiti potrebbero essere più distanti dai client e comportare una latenza media più elevata per le richieste dei client. Ciò si verifica anche se sono presenti altri backend più vicini che avrebbero potuto servire i client con una latenza inferiore.
- Alcuni algoritmi di bilanciamento del carico (
WATERFALL_BY_REGION,SPRAY_TO_REGIONeWATERFALL_BY_ZONE) non si applicano ai backend configurati come backend preferiti.
Per scoprire come impostare i backend preferiti, consulta Impostare i backend preferiti.
Configura una policy di bilanciamento del carico del servizio
La risorsa policy di bilanciamento del carico del servizio ti consente di configurare i seguenti campi:
- Algoritmo di bilanciamento del carico
- Svuotamento automatico della capacità
- Soglia di failover
- Isolamento del traffico
Per impostare un backend preferito, consulta Impostare i backend preferiti.
Crea un criterio
Per creare e configurare una policy di bilanciamento del carico del servizio:
Console
Per creare una policy di bilanciamento del carico del servizio:
Nella console Google Cloud , vai alla pagina Bilanciamento del carico.
Fai clic su Crea policy di bilanciamento del carico del servizio.
Inserisci un Nome per la policy di bilanciamento del carico del servizio.
Per abilitare lo svuotamento automatico della capacità, seleziona Svuota il traffico dai backend non integri.
Per Soglia di integrità failover, inserisci un numero compreso tra 1 e 99.
Per Distribuzione del traffico, seleziona l'algoritmo di bilanciamento del carico che vuoi utilizzare.
Per Isolamento del traffico, seleziona Isola a livello di regione.
Seleziona la modalità di isolamento del traffico che preferisci.
Fai clic su Crea.
gcloud
Crea una risorsa policy di bilanciamento del carico del servizio. Puoi farlo utilizzando un file YAML o direttamente, utilizzando i parametri
gcloud.Con un file YAML
Specifichi le policy di bilanciamento del carico del servizio in un file YAML. Ecco un file YAML di esempio che mostra come configurare un algoritmo di bilanciamento del carico, attivare lo svuotamento automatico della capacità e impostare una soglia di failover personalizzata:
globale
name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME autoCapacityDrain: enable: True failoverConfig: failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM isolationConfig: isolationGranularity: ISOLATION_GRANULARITY isolationMode: ISOLATION_MODESostituisci quanto segue:
- PROJECT_ID: l'ID progetto
- SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
- FAILOVER_THRESHOLD_VALUE: il valore della soglia di failover. Deve essere un numero compreso tra 1 e 99.
- LOAD_BALANCING_ALGORITHM: l'algoritmo di bilanciamento del carico da utilizzare. Può essere
SPRAY_TO_REGION,WATERFALL_BY_REGIONoWATERFALL_BY_ZONE. - ISOLATION_GRANULARITY: la granularità della limitazione
dell'isolamento. Per evitare l'overflow del traffico tra regioni, imposta
questo valore su
REGION. Se non specificato, non viene applicato alcun isolamento. - ISOLATION_MODE: il comportamento di isolamento. I valori possibili sono
NEARESToSTRICT.
Dopo aver creato il file YAML, importalo in una nuova policy di bilanciamento del carico del servizio.
gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \ --source=PATH_TO_POLICY_FILE \ --location=globalSostituisci quanto segue:
- SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
- PATH_TO_POLICY_FILE: il percorso del file YAML contenente la policy di bilanciamento del carico del servizio.
regionale
name: projects/PROJECT_ID/locations/REGION/serviceLbPolicies/SERVICE_LB_POLICY_NAME autoCapacityDrain: enable: True failoverConfig: failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHMSostituisci quanto segue:
- PROJECT_ID: l'ID progetto
- REGION: la regione in cui viene creata la policy. Deve corrispondere alla regione del servizio di backend a cui vuoi applicare la policy.
- SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
- FAILOVER_THRESHOLD_VALUE: il valore della soglia di failover. Deve essere un numero compreso tra 1 e 99.
- LOAD_BALANCING_ALGORITHM: l'algoritmo di bilanciamento del carico da utilizzare. Può essere
SPRAY_TO_REGION,WATERFALL_BY_REGIONoWATERFALL_BY_ZONE.
Dopo aver creato il file YAML, importalo in una nuova policy di bilanciamento del carico del servizio.
gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \ --source=PATH_TO_POLICY_FILE \ --location=REGIONSostituisci quanto segue:
- SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
- PATH_TO_POLICY_FILE: il percorso del file YAML contenente la policy di bilanciamento del carico del servizio.
- REGION: la regione in cui si trova la policy. Deve corrispondere alla regione del servizio di backend a cui vuoi applicare la policy.
Senza un file YAML
In alternativa, puoi configurare le funzionalità dei criteri di bilanciamento del carico del servizio senza utilizzare un file YAML.
Per impostare l'algoritmo di bilanciamento del carico e abilitare lo svuotamento automatico, utilizza il comando seguente:
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=LOCATIONSostituisci quanto segue:
- SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
- LOAD_BALANCING_ALGORITHM: l'algoritmo di bilanciamento del carico da utilizzare. Può essere
SPRAY_TO_REGION,WATERFALL_BY_REGIONoWATERFALL_BY_ZONE. - FAILOVER_THRESHOLD_VALUE: il valore della soglia di failover. Deve essere un numero compreso tra 1 e 99.
- LOCATION: la località in cui viene creata la policy. Può essere
globalo una regione Google Cloud . Per le policy regionali, questa località deve corrispondere alla regione del servizio di backend a cui vuoi applicare la policy.
Per configurare l'isolamento del traffico (in anteprima, supportato solo per i bilanciatori del carico globali e cross-region), utilizza il seguente comando:
gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \ --isolation-config-granularity=ISOLATION_GRANULARITY \ --isolation-config-mode=ISOLATION_MODE \ --location=globalSostituisci quanto segue:
- ISOLATION_GRANULARITY: la granularità della limitazione
dell'isolamento. Per evitare l'overflow del traffico tra regioni, imposta
questo valore su
REGION. Se non specificato, non viene applicato alcun isolamento. - ISOLATION_MODE: il comportamento di isolamento. I valori possibili sono
NEARESToSTRICT.
Aggiorna un servizio di backend in modo che il relativo campo
--service-lb-policyfaccia riferimento alla risorsa della policy di bilanciamento del carico del servizio appena creata. Un servizio di backend può essere associato a una sola risorsa di policy di bilanciamento del carico del servizio.gcloud compute backend-services update BACKEND_SERVICE_NAME \ --service-lb-policy=SERVICE_LB_POLICY_NAME \ {--global | --region=REGION}Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome del servizio di backend.
- SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
- REGION: la regione del servizio di backend (se configuri un servizio di backend regionale).
Puoi anche 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 | --region=REGION}Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome del servizio di backend.
- PROTOCOL: il protocollo utilizzato per comunicare
con i backend, ad esempio
HTTP,HTTPSoTCP. - NAMED_PORT_NAME: il nome della porta su cui il servizio di backend è in ascolto.
- HEALTH_CHECK_NAME: il nome del controllo di integrità.
- LOAD_BALANCING_SCHEME: lo schema di bilanciamento del carico, ad esempio
EXTERNAL_MANAGEDoINTERNAL_MANAGED. - SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
- REGION: la regione del servizio di backend (se configuri un servizio di backend regionale).
Disattiva le funzionalità configurate nella policy
Questa sezione mostra come reimpostare o disattivare le funzionalità configurate nel bilanciamento del carico del servizio.
Reimposta l'algoritmo di bilanciamento del carico
Per reimpostare l'algoritmo di bilanciamento del carico, utilizza il seguente comando per impostare
l'algoritmo di bilanciamento del carico sul valore predefinito WATERFALL_BY_REGION:
gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
--load-balancing-algorithm=WATERFALL_BY_REGION \
--location=LOCATION
Sostituisci quanto segue:
- SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
- LOCATION: la posizione in cui viene creata la policy. Può essere
globalo una regione Google Cloud .
Reimposta la soglia di failover
Per reimpostare la soglia di failover, utilizza il seguente comando per impostare la soglia di failover di nuovo a 70 secondi, il valore predefinito:
gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
--failover-health-threshold=70 \
--location=LOCATION
Sostituisci quanto segue:
- SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
- LOCATION: la posizione in cui viene creata la policy. Può essere
globalo una regione Google Cloud .
Disattivare lo scarico rapido automatico della capacità
Per disattivare lo svuotamento automatico della capacità, utilizza il seguente comando:
gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
--no-auto-capacity-drain \
--location=LOCATION
Sostituisci quanto segue:
- SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
- LOCATION: la posizione in cui viene creata la policy. Può essere
globalo una regione Google Cloud .
Disattivare l'isolamento del traffico
Per disattivare l'isolamento del traffico
(anteprima), imposta entrambi i parametri di configurazione
dell'isolamento su UNSPECIFIED come mostrato nel seguente comando:
gcloud beta network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
--isolation-config-granularity=UNSPECIFIED \
--isolation-config-mode=UNSPECIFIED \
--location=global
Sostituisci quanto segue:
- SERVICE_LB_POLICY_NAME: il nome della policy di bilanciamento del carico del servizio.
Rimuovere una norma
Per rimuovere una policy 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 | --region=REGION}
Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome del servizio di backend.
- REGION: la regione del servizio di backend (se configuri un servizio di backend regionale).
Impostare i backend preferiti
Puoi configurare i backend preferiti utilizzando Google Cloud CLI o l'API.
Console
Puoi designare un backend come backend preferito durante la creazione di un bilanciatore del carico globale o tra regioni nella console Google Cloud .
Imposta il campo Livello di preferenza backend su Preferito quando aggiungi il backend al servizio di backend.
Non puoi configurare i backend preferiti per i bilanciatori del carico regionali nella consoleGoogle Cloud . Utilizza l'interfaccia a riga di comando gcloud o l'API REST.
gcloud
Aggiungere 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 al
servizio di backend.
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
...
--preference=PREFERENCE \
{--global | --region=REGION}
Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome del servizio di backend.
- PREFERENCE: il livello di preferenza che vuoi assegnare al backend,
PREFERREDoDEFAULT. - REGION: la regione del servizio di backend (se configuri un servizio di backend regionale).
Il resto del comando dipende dal tipo di backend che utilizzi
(gruppo di istanze o NEG). Per tutti i parametri obbligatori, consulta il comando gcloud compute backend-services add-backend.
Aggiorna la preferenza di un backend
Per aggiornare il parametro --preference di un backend, utilizza il
comando gcloud compute backend-services update-backend.
gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
...
--preference=PREFERENCE \
{--global | --region=REGION}
Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome del servizio di backend.
- PREFERENCE: il livello di preferenza che vuoi assegnare al backend,
PREFERREDoDEFAULT. - REGION: la regione del servizio di backend (se configuri un servizio di backend regionale).
Il resto del comando dipende dal tipo di backend che utilizzi
(gruppo di istanze o NEG). Il seguente comando di esempio aggiorna la preferenza di un
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 | --region=REGION}
Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome del servizio di backend.
- INSTANCE_GROUP_NAME: il nome del gruppo di istanze.
- INSTANCE_GROUP_ZONE: la zona in cui si trova il gruppo di istanze.
- REGION: la regione del servizio di backend (se configuri un servizio di backend regionale).
API
Per impostare un backend preferito, imposta il flag preference su ogni backend utilizzando la risorsa backendServices globale.
Ecco un esempio che mostra come configurare la preferenza di backend:
name: projects/PROJECT_ID/locations/LOCATION/backendServices/BACKEND_SERVICE_NAME
...
- backends
name: BACKEND_1_NAME
preference: PREFERRED
...
- backends
name: BACKEND_2_NAME
preference: DEFAULT
...
Sostituisci quanto segue:
- PROJECT_ID: l'ID progetto
- BACKEND_SERVICE_NAME: il nome del servizio di backend
- BACKEND_1_NAME: il nome del backend preferito
- BACKEND_2_NAME: il nome del backend predefinito
- LOCATION: la località in cui viene creato il servizio di backend. Può essere
globalo una regione Google Cloud .
Risoluzione dei problemi
I pattern di distribuzione del traffico possono cambiare quando colleghi una nuova policy di bilanciamento del carico del servizio a un servizio di backend.
Per eseguire il debug dei problemi di traffico, utilizza Cloud Monitoring per esaminare il flusso di traffico tra il bilanciatore del carico e il backend. I log e le metriche di Cloud Load Balancing possono anche aiutarti a comprendere il comportamento del bilanciamento del carico.
Questa sezione riassume alcuni scenari comuni che potresti riscontrare quando attivi ciascuna di queste funzionalità.
Algoritmi di bilanciamento del carico
Il traffico proveniente da una singola origine viene inviato a troppi backend distinti
Questo è il comportamento previsto dell'algoritmo SPRAY_TO_REGION. Tuttavia, potresti riscontrare problemi causati da una distribuzione più ampia del traffico. Ad esempio, i tassi di successo della cache potrebbero diminuire perché i backend vedono il traffico proveniente da una selezione più ampia di client. In questo caso, valuta la possibilità di utilizzare altri algoritmi come
WATERFALL_BY_REGION.
Svuotamento automatico della capacità
Il traffico non viene inviato ai backend con molti endpoint non integri
Questo è il comportamento previsto quando autoCapacityDrain è abilitato. I backend con molti endpoint in stato non integro vengono svuotati e rimossi dal pool di bilanciamento del carico. Se non vuoi questo comportamento, puoi disattivare lo scaricamento automatico della capacità. Tuttavia, ciò significa che il traffico può essere inviato a backend con molti
endpoint non integri e le richieste possono non riuscire.
Soglia di failover
Il traffico viene inviato a un backend remoto durante le modifiche temporanee dello stato
Questo è il comportamento previsto quando la soglia di failover è impostata su un valore elevato. Se vuoi che il traffico continui a essere indirizzato ai backend primari quando si verificano cambiamenti temporanei dello stato, imposta questo campo su un valore inferiore.
Gli endpoint integri sono sovraccarichi quando gli altri endpoint non sono integri
Questo è il comportamento previsto quando la soglia di failover è impostata su un valore basso. Quando gli endpoint non sono integri, il traffico destinato a questi endpoint non integri viene invece distribuito tra gli endpoint rimanenti nello stesso backend. Se vuoi che il comportamento di failover venga attivato prima, imposta questo campo su un valore più alto.
Backend preferiti
Il traffico viene inviato ai backend più distanti prima di quelli più vicini
Questo è il comportamento previsto se i backend preferiti sono più distanti dei backend predefiniti. Se non vuoi questo comportamento, aggiorna le impostazioni delle preferenze per ogni backend di conseguenza.
Il traffico non viene inviato ad alcuni backend quando vengono utilizzati i backend preferiti
Questo è il comportamento previsto quando i backend preferiti non hanno ancora raggiunto la capacità. I backend preferiti vengono assegnati per primi in base alla latenza del 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.
- Imposta un'impostazione della capacità target inferiore per i backend che preferisci. La capacità
di destinazione viene configurata utilizzando i campi
max-rateomax-utilization, a seconda della modalità di bilanciamento del carico del servizio di backend.
Isolamento del traffico
Le richieste inviate al bilanciatore del carico interno tra regioni non vanno a buon fine
Se la modalità di isolamento STRICT è attivata e non sono configurati backend nella stessa regione del bilanciatore del carico, è previsto un errore del traffico. Se questo non è il comportamento previsto, assicurati di avere backend
nella regione in cui prevedi che venga inviato il traffico. In alternativa, imposta la modalità di isolamento su
NEAREST in modo che il traffico possa essere indirizzato alla regione più vicina successiva.
Il traffico viene instradato da una regione remota a una più vicina
L'isolamento delle richieste impedisce l'overflow del traffico basato sulla capacità. Pertanto, se i tuoi backend erano già sovraccarichi prima di attivare questa funzionalità, il traffico potrebbe essere già stato inviato a una regione remota. In questo caso, l'attivazione di questa funzionalità potrebbe causare il reindirizzamento di questo traffico alla regione più vicina.
Il traffico non è stato reindirizzato dopo l'attivazione dell'isolamento del traffico
L'isolamento delle richieste impedisce l'overflow del traffico basato sulla capacità. Pertanto, se i tuoi backend nella regione più vicina non erano sovraccarichi prima di attivare questa funzionalità, è probabile che la regione più vicina sia in grado di gestire tutto il traffico. In questo caso, è normale che non vedrai modifiche alle strade trafficate nel breve periodo. Questo valore potrebbe cambiare in base al volume di traffico.
Il traffico si sposta quando i backend vengono aggiunti o rimossi da una regione
Questo è il comportamento previsto perché i bilanciatori del carico tentano di instradare il traffico per ottimizzare la latenza di rete complessiva. Pertanto, quando vengono implementati nuovi backend in una regione più vicina, il bilanciatore del carico potrebbe inviare più traffico a quella regione. Allo stesso modo, quando i backend vengono rimossi, a seconda dell'impostazione di isolamento delle richieste, il bilanciatore del carico inizia a inviare il traffico in eccesso a una regione più lontana.
Limitazioni
- Ogni servizio di backend può essere associato a una sola risorsa di bilanciamento del carico del servizio.
- I bilanciatori del carico delle applicazioni regionali non supportano l'isolamento del traffico.