Ottimizzazioni del bilanciamento del carico avanzate

Questa pagina descrive come utilizzare un criterio di bilanciamento del carico del servizio per supportare ottimizzazioni avanzate di costi, latenza e resilienza per i seguenti 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 ottimizzazioni del bilanciamento del carico avanzate. Per maggiori dettagli, consulta la Panoramica del bilanciamento del carico avanzato nella documentazione di Cloud Service Mesh.

Un criterio 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 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 la modalità di distribuzione del traffico all'interno di una determinata regione o zona.
• Attiva lo scarico automatico della capacità in modo che il bilanciatore del carico possa scaricare rapidamente il traffico dai backend non funzionanti.
• Imposta una soglia di failover per determinare quando un backend è considerato non integro. In questo modo, il traffico viene eseguito in un altro backend per evitare quelli non funzionanti.

Inoltre, puoi designare backend specifici come backend preferiti. Questi backend devono essere utilizzati al massimo della loro capacità 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.

In che modo Cloud Load Balancing prende decisioni di routing e distribuzione del traffico.

Prima di iniziare

Prima di esaminare i contenuti di questa pagina, esamina attentamente la procedura di distribuzione delle richieste descritta nella pagina Panoramica del bilanciatore del carico delle applicazioni esterno. Per i bilanciatori del carico 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.

Backend supportati

I criteri di bilanciamento del carico del servizio e i backend preferiti possono essere configurati solo su bilanciatori del carico che utilizzano i backend supportati come indicato nella tabella seguente.

Backend	Supportato?
Gruppi di istanze Non gestita Gestito a livello di zona
MIG a livello di area geografica
NEG a livello di zona (endpoint GCE_VM_IP_PORT)
NEG ibride (endpoint NON_GCP_PRIVATE_IP_PORT)
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 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 algoritmo, in aggregato, tutti i front-end Google (GFEs) nella regione più vicina all'utente tentano di riempire i backend in proporzione alle loro capacità target configurate (modificate dai relativi fattori di scalabilità della capacità).

Ogni singolo GFE di secondo livello preferisce selezionare istanze o endpoint di backend in una zona il più vicina possibile (definita dal tempo di percorrenza della rete) al GFE di secondo livello. Poiché WATERFALL_BY_REGION riduce al minimo la latenza tra le zone, a tassi di richiesta ridotti, ogni GFE di secondo livello potrebbe inviare esclusivamente richieste ai backend nella zona preferita del GFE di secondo livello.

Se tutti i backend nella regione più vicina funzionano al limite della capacità configurata, il traffico inizierà a essere trasferito alla regione più vicina, ottimizzando al contempo la latenza della rete.

Spray a regione

L'algoritmo SPRAY_TO_REGION modifica il comportamento individuale di ogni GFE di secondo livello nella misura in cui ogni GFE di secondo livello non ha 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 preferire 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 aggregato, tutti i GFE di secondo livello nella regione compilano i backend in proporzione alle loro capacità target configurate (modificate dai loro scalari di capacità).

Sebbene SPRAY_TO_REGION fornisca una distribuzione più uniforme tra i backend in tutte le zone di una regione, in particolare a tassi di richiesta ridotti, questa distribuzione uniforme comporta le seguenti considerazioni:

• Quando i backend si arrestano (ma continuano a superare i controlli di integrità), sono interessati più GFEs 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 fase di elaborazione, ogni GFE di secondo livello potrebbe creare anche più connessioni TCP ai backend.

A cascata per zona

L'algoritmo WATERFALL_BY_ZONE modifica il comportamento individuale di ogni GFE di secondo livello nella misura in cui ogni GFE di secondo livello ha una preferenza molto forte per selezionare 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 soltanto invia richieste a istanze o endpoint di backend in altre zone della regione quando il GFE di secondo livello ha riempito (o ha riempito in modo proporzionale) le istanze o gli endpoint di backend nella sua zona più favorita.

Come WATERFALL_BY_REGION, in aggregato, tutti i GFE di secondo livello nella regione compilano i backend in proporzione alle loro capacità target configurate (modificate dai loro scalari di capacità).

L'algoritmo WATERFALL_BY_ZONE riduce al minimo la latenza tenendo conto dei seguenti aspetti:

• WATERFALL_BY_ZONE non riduce intrinsecamente al minimo le connessioni tra zone. L'algoritmo è guidato solo dalla latenza.
• WATERFALL_BY_ZONE non garantisce che ogni GFE di secondo livello sempre compili la sua zona più favorita prima di compilare altre zone. Gli eventi di manutenzione possono temporaneamente causare l'invio di tutto il traffico da un GFE di secondo livello a istanze o endpoint di backend in un'altra zona.
• WATERFALL_BY_ZONE può comportare una distribuzione meno uniforme delle richieste tra tutte le istanze o gli endpoint di backend all'interno della regione nel suo complesso. Ad esempio, gli endpoint o le istanze di backend nella zona più scelta del GFE di secondo livello potrebbero essere utilizzati al massimo della capacità, mentre i backend in altre zone non lo sono.

Confrontare gli algoritmi di bilanciamento del carico

La seguente tabella 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 un'unica 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 in modo uniforme tra le zone di una regione, ottimizzando al contempo la latenza della rete. Se necessario, il traffico potrebbe essere inviato tra le zone.	Sì	Sì. Il traffico viene inviato prima alla zona più vicina finché non raggiunge la capacità massima. Poi passa alla zona più vicina.
Sensibilità agli picchi di traffico in una zona locale	Media; dipende dalla quantità di traffico già spostata per bilanciare il traffico tra le zone.	Più basso; gli picchi di una singola zona vengono distribuiti in tutte le zone della regione.	Più elevato; è probabile che gli picchi in una singola zona vengano gestiti interamente dalla stessa zona finché il bilanciatore del carico non è in grado di reagire.

Scarico automatico della capacità

Quando un backend non è integro, in genere è consigliabile escluderlo dalle decisioni di bilanciamento del carico il più rapidamente possibile. L'esclusione dei backend non integri ottimizza la latenza complessiva inviando il traffico solo ai backend integri.

Quando attivi la funzionalità di svuotamento automatico della capacità, il bilanciatore del carico scala automaticamente la capacità di un backend a zero quando meno del 25 percento delle istanze o degli endpoint del backend supera i controlli di integrità. In questo modo, il backend non integro viene rimosso dal pool di bilanciamento del carico globale. Questa azione è funzionalmente equivalente all'impostazione di backendService.capacityScaler su 0 per un backend quando vuoi evitare di instradare il traffico verso quel backend.

Se il 35% (10% sopra la soglia) degli endpoint o delle istanze di un backend precedentemente sottoposto a svuotamento automatico supera i controlli di integrità per 60 secondi, il backend viene automaticamente svuotato e aggiunto di nuovo al pool di bilanciamento del carico. In questo modo, il backend è effettivamente integro e non passa da uno stato di svuotamento a uno di svuotamento.

Anche con lo svuotamento automatico della capacità abilitato, il bilanciatore del carico non scarica più del 50% dei backend collegati a un servizio di backend, indipendentemente dallo stato di integrità di un backend. Mantenendo collegato il 50% dei backend, si riduce il rischio di sovraccaricare i backend integri.

Un caso d'uso del ritiro automatico della capacità è utilizzarlo per ridurre al minimo il rischio di sovraccaricare i backend preferiti. Ad esempio, se un backend è contrassegnato come preferito, ma la maggior parte delle sue istanze o dei suoi endpoint è in stato non integro, lo svuotamento automatico della capacità rimuove il backend dal pool di bilanciamento del carico. Anziché sovraccaricare le istanze o gli endpoint rimanenti in buono stato nel backend preferito, lo svuotamento automatico della capacità trasferisce il traffico ad altri backend.

Puoi attivare lo svuotamento automatico della capacità come parte del criterio di bilanciamento del carico del servizio. Per maggiori dettagli, vedi Configurare un criterio di bilanciamento del carico del servizio.

La capacità automatica non è supportata con i backend che non utilizzano una modalità di bilanciamento. Sono inclusi i backend come i NEG di internet, i NEG serverless e i NEG PSC.

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. In genere si tratta di backend nelle vicinanze con capacità rimanente.

Se le istanze o gli endpoint nel backend principale non sono più disponibili, il bilanciamento del carico non trasferisce immediatamente il traffico ad altri backend. Il bilanciatore del carico, invece, sposta prima il traffico su altre istanze o endpoint integri nello stesso backend per contribuire a stabilizzare il carico del traffico. Se troppi endpoint in un backend primario non sono operativi 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 corretto 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 il traffico a un backend di failover. Per impostazione predefinita, la soglia di failover è 70.

Se la soglia di failover è impostata su un valore troppo elevato, possono verificarsi trasferimenti di traffico non necessari a causa di variazioni temporanee dello stato. Se la soglia di failover è impostata troppo bassa, 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 dall'altro. È 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 è in stato attivo, il bilanciatore del carico potrebbe comunque inviarvi traffico. Per escludere i backend non funzionanti dal pool di backend disponibili, attiva la funzionalità di scarico automatico della capacità.

Backend preferiti

I backend preferiti sono quelli di cui vuoi usare completamente la capacità prima di trasferire il traffico ad altri backend. Qualsiasi traffico superiore alla capacità configurata dei backend preferiti viene instradato 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 inoltrare le richieste successive ai backend rimanenti.

Tieni presenti le seguenti limitazioni quando utilizzi i backend preferiti:

• I backend configurati come preferiti potrebbero essere più lontani dai client e comportare una latenza media più elevata per le richieste dei client. Questo accade anche se sono presenti altri backend più vicini che potrebbero aver servito i client con una latenza inferiore.
• Alcuni algoritmi di bilanciamento del carico (WATERFALL_BY_REGION, SPRAY_TO_REGION e WATERFALL_BY_ZONE) non si applicano ai backend configurati come preferiti.

Per scoprire come impostare i backend preferiti, consulta Impostare i backend preferiti.

Configura una policy di bilanciamento del carico del servizio

Nota: questa sezione presuppone una conoscenza di livello intermedio o avanzato di Cloud Load Balancing. I passaggi non illustrano la creazione di un servizio di backend né qualsiasi altra configurazione di base del bilanciatore del carico. Per eseguire la configurazione di base, consulta la rispettiva documentazione del bilanciatore del carico.

La risorsa criterio di bilanciamento del carico del servizio consente di configurare i seguenti campi:

• Algoritmo di bilanciamento del carico
• Scarico automatico della capacità
• Soglia di failover

Per impostare un backend preferito, consulta la sezione Impostare i backend preferiti.

Crea un criterio

Per creare e configurare una policy di bilanciamento del carico del servizio, completa i seguenti passaggi:

1. Crea una risorsa di criteri di bilanciamento del carico del servizio. Puoi farlo utilizzando un file YAML o direttamente utilizzando i parametri gcloud.

   • Con un file YAML. Specifica 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:

     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 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_REGION o WATERFALL_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=global
     

   • 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 attivare lo svuotamento automatico, utilizza i 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 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_REGION o WATERFALL_BY_ZONE.
     • FAILOVER_THRESHOLD_VALUE: il valore della soglia di failover. Deve essere un numero compreso tra 1 e 99.

2. Aggiorna un servizio di backend in modo che il relativo campo --service-lb-policy faccia 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 criteri di bilanciamento del carico del servizio.

   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 una norma

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

Impostare i backend preferiti

Puoi configurare i backend preferiti utilizzando Google Cloud CLI o l'API.

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

Sostituisci PREFERENCE con il livello di preferenza che vuoi assegnare al backend. Può essere PREFERRED o DEFAULT.

Il resto del comando dipende dal tipo di backend utilizzato (gruppo di istanze o NEG). Per tutti i parametri obbligatori, consulta il comando gcloud compute backend-services add-backend.

Aggiornare 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

Il resto del comando dipende dal tipo di backend utilizzato (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

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/global/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

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. Anche i log e le metriche di Cloud Load Balancing possono aiutarti a comprendere il comportamento del bilanciamento del carico.

Questa sezione riassume alcuni scenari comuni che potresti riscontrare nella configurazione appena esposta.

Il traffico da una singola sorgente 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 rilevano il traffico da una selezione più ampia di client. In questo caso, ti consigliamo di utilizzare altri algoritmi come WATERFALL_BY_REGION.

Il traffico non viene inviato ai backend con molti endpoint non integri

Questo è il comportamento previsto quando autoCapacityDrain è attivato. I backend con molti endpoint non integri vengono svuotati e rimossi dal pool di bilanciamento del carico. Se non vuoi questo comportamento, puoi disattivare lo svuotamento 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.

Il traffico viene inviato a backend più lontani prima di quelli più vicini

Questo è il comportamento previsto se i backend preferiti sono più lontani rispetto ai backend predefiniti. Se non vuoi questo comportamento, aggiorna di conseguenza le impostazioni di preferenza per ogni backend.

Il traffico non viene inviato ad alcuni backend quando vengono utilizzati i backend preferiti

Questo è il comportamento previsto quando i tuoi backend preferiti non hanno ancora raggiunto la capacità. I backend preferiti vengono assegnati per primi in base alla latenza tempo di round trip per questi backend.

Se vuoi che il traffico venga inviato ad altri backend, puoi:

• Aggiorna le impostazioni delle preferenze per gli altri backend.
• Imposta una capacità target inferiore per i backend che preferisci. La capacità di destinazione viene configurata utilizzando i campi max-rate o max-utilization, a seconda della modalità di bilanciamento del servizio di backend.

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 inviato ai backend principali quando si verificano modifiche temporanee dell'integrità, imposta questo campo su un valore inferiore.

Gli endpoint integri sono sovraccaricati quando 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 viene 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.

Limitazioni

• Ogni servizio di backend può essere associato a una sola risorsa del criterio di bilanciamento del carico del servizio.