Ottimizzazioni avanzate del bilanciamento del carico

In questa pagina viene descritto come utilizzare un criterio di bilanciamento del carico dei servizi 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

Traffic Director supporta inoltre ottimizzazioni avanzate del bilanciamento del carico. Per i dettagli, consulta la Panoramica sul bilanciamento del carico avanzato nella documentazione di Traffic Director.

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 dei servizi 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 in che modo il traffico viene distribuito all'interno di una determinata regione o zona.
Abilita lo svuotamento automatico della capacità in modo che il bilanciatore del carico possa scaricare rapidamente il traffico dai backend in stato non integro.
Imposta una soglia di failover per determinare quando un backend è considerato non integro. In questo modo il traffico può eseguire il failover su un backend diverso per evitare backend in stato non integro.

Inoltre, puoi designare backend specifici come backend preferiti. Questi backend devono essere utilizzati per raggiungere la capacità prima che le richieste vengano inviate ai backend rimanenti.

Il seguente diagramma mostra in che modo Cloud Load Balancing valuta il routing, il bilanciamento del carico e la distribuzione del traffico.

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

Prima di iniziare

Prima di esaminare i contenuti di questa pagina, esamina attentamente il Processo di distribuzione delle richieste descritto nella pagina di 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 il reindirizzamento da una regione all'altra se una regione di prima scelta è già al completo.

Backend supportati

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

Backend	Supportato?
Gruppi di istanze Non gestito Gestita a livello di zona
MIG a livello di area geografica
NEG di zona (`GCE_VM_IP_PORT` endpoint)
NEG ibridi (`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 criterio di bilanciamento del carico di un servizio. Se non configuri un algoritmo o se non configuri affatto un criterio di bilanciamento del carico del servizio, il bilanciatore del carico utilizza WATERFALL_BY_REGION per impostazione predefinita.

Struttura a cascata per regione

WATERFALL_BY_REGION è l'algoritmo di bilanciamento del carico predefinito. Con questo algoritmo, in forma aggregata, tutti i Google Front End (GFE) in una regione tentano di riempire i backend in proporzione alle capacità target configurate (modificate dai rispettivi scaler della capacità).

Ogni singolo GFE di secondo livello preferisce selezionare le istanze o gli endpoint di backend in una zona il più vicina possibile (definita in base al tempo di round trip della rete) al GFE di secondo livello. Poiché WATERFALL_BY_REGION riduce al minimo la latenza tra le zone, a basse frequenze di richieste, ogni GFE di secondo livello può inviare esclusivamente richieste ai backend nella zona preferita del GFE secondo livello.

Spruzza sulla zona

L'algoritmo SPRAY_TO_REGION modifica il comportamento singolo di ogni GFE di secondo livello nella misura in cui ciascun GFE di secondo livello non ha preferenze per la selezione di istanze o endpoint di backend che si trovano in una zona il più vicina possibile al GFE di secondo livello. Con SPRAY_TO_REGION, ciascun GFE di secondo livello invia richieste a tutte le istanze o endpoint di backend, in tutte le zone dell'area geografica, 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 forma aggregata, tutti i GFE di secondo livello nella regione riempiono i backend in proporzione alle capacità target configurate (modificate dai rispettivi scaler della capacità).

Sebbene SPRAY_TO_REGION fornisca una distribuzione più uniforme tra i backend in tutte le zone di una regione, soprattutto a basse percentuali di richieste, questa distribuzione uniforme include le seguenti considerazioni:

Quando i backend non funzionano (ma continuano a superare i controlli di integrità), sono 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 da elaborare, ogni GFE di secondo livello potrebbe creare anche più connessioni TCP con i backend.

Struttura a cascata per zona

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

L'algoritmo WATERFALL_BY_ZONE riduce al minimo la latenza con le seguenti considerazioni:

WATERFALL_BY_ZONE non riduce al minimo le connessioni tra zone. L'algoritmo è controllato solo dalla latenza.
WATERFALL_BY_ZONE non garantisce che ogni GFE di secondo livello riempia sempre la 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_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, le istanze o gli endpoint di backend nella zona preferita del GFE secondo livello potrebbero essere riempiti al massimo, mentre i backend in altre zone non vengono riempiti al massimo.

Confrontare gli algoritmi di bilanciamento del carico

La tabella seguente mette a confronto i diversi algoritmi di bilanciamento del carico.

Comportamento	Struttura a cascata per regione	Spruzza sulla zona	Struttura 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 è distribuito uniformemente tra le zone di una regione ottimizzando la latenza di rete. Se necessario, il traffico può essere inviato tra zone diverse.	Sì	Sì. Il traffico arriva prima alla zona più vicina fino al raggiungimento della capacità massima. Poi, passa alla zona immediatamente più vicina.
Sensibilità ai picchi di traffico in una zona locale	Media; dipende dalla quantità di traffico già spostata per bilanciare le zone.	Inferiore; i picchi di singola zona sono distribuiti in tutte le zone della regione.	Maggiore: è probabile che i picchi di singole zone vengano gestiti interamente dalla stessa zona finché il bilanciatore del carico non riesce a reagire.

Svuotamento 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 in stato non integro ottimizza la latenza complessiva inviando il traffico solo a backend integri.

Quando abiliti la funzionalità di svuotamento automatico della capacità, il bilanciatore del carico scala automaticamente la capacità di un backend fino a zero quando meno del 25% delle istanze o degli endpoint del backend supera i controlli di integrità. Il backend in stato non integro viene rimosso dal pool di bilanciamento del carico globale. Questa azione equivale a impostare backendService.capacityScaler su 0 per un backend quando vuoi evitare di instradare il traffico a quel backend.

Se il 35% (10% sopra la soglia) delle istanze o degli endpoint del backend precedentemente scaricati automaticamente supera i controlli di integrità per 60 secondi, il backend viene automaticamente scaricato e aggiunto nuovamente al pool di bilanciamento del carico. Ciò garantisce che il backend sia veramente integro e non cada tra uno stato svuotato e uno non svuotato.

Anche se è abilitato lo svuotamento automatico della capacità, il bilanciatore del carico non svuota più del 50% dei backend collegati a un servizio di backend, indipendentemente dallo stato di integrità del backend. Mantenere collegati il 50% dei backend riduce il rischio di sovraccarico dei backend integri.

Un caso d'uso dello svuotamento automatico delle capacità è quello di 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 istanze o degli endpoint non è integro, lo svuotamento automatico della capacità rimuove il backend dal pool di bilanciamento del carico. Invece di sovraccaricare le istanze o gli endpoint integri rimanenti nel backend preferito, lo svuotamento automatico delle capacità sposta il traffico ad altri backend.

Puoi abilitare lo svuotamento automatico della capacità nell'ambito del criterio di bilanciamento del carico del servizio. Per maggiori dettagli, consulta Configurare un criterio di bilanciamento del carico dei servizi.

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

Soglia di failover

Il bilanciatore del carico determina la distribuzione del traffico tra i backend in modo multilivello. In stato stabile, il traffico viene inviato ai backend selezionati in base a uno degli algoritmi di bilanciamento del carico descritti in precedenza. Questi backend, denominati backend primari, sono considerati ottimali in termini di latenza e capacità.

Il bilanciatore del carico tiene traccia anche degli altri backend che possono essere utilizzati se i backend primari diventano non integri e non sono in grado di gestire il traffico. Questi backend sono chiamati backend di failover. Questi sono in genere backend vicini con capacità rimanente.

Se lo stato di uno stato non integro delle istanze o degli endpoint nel backend principale, il bilanciatore del carico non sposta immediatamente il traffico verso altri backend. Al contrario, il bilanciatore del carico sposta prima il traffico in 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 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 il traffico a un backend di failover. Il bilanciatore del carico tollera l'integrità nel backend principale fino alla soglia di failover. Successivamente, 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 deve essere integro. 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 è pari a 70.

Se la soglia di failover è impostata su un valore troppo elevato, possono verificarsi perdite di traffico non necessarie a causa di modifiche temporanee dell'integrità. Se la soglia di failover è impostata su un valore troppo basso, il bilanciatore del carico continua a inviare traffico ai backend primari 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 è integro, il bilanciatore del carico potrebbe comunque inviare traffico lì. Per escludere i backend in stato non integro dal pool di backend disponibili, abilita la funzionalità di svuotamento automatico della capacità.

Backend preferiti

I backend preferiti sono backend la cui capacità vuoi utilizzare completamente prima di trasferire il traffico ad altri backend. Tutto il traffico che supera la 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 da preferire e utilizzare completamente uno o più backend collegati a un servizio di backend prima di eseguire il routing delle richieste successive ai backend rimanenti.

Considera le seguenti limitazioni quando utilizzi backend preferiti:

I backend configurati come backend preferiti potrebbero essere più lontani dai client e comportare una latenza media maggiore per le richieste del client. Ciò si verifica anche nel caso in cui fossero presenti altri backend più vicini che avrebbero potuto gestire 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 backend preferiti.

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

Configura un criterio di bilanciamento del carico dei servizi

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

Algoritmo di bilanciamento del carico
Svuotamento automatico della capacità
Soglia di failover

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

Crea un criterio

Per creare e configurare un criterio di bilanciamento del carico dei servizi, completa i seguenti passaggi:

Crea una risorsa del criterio di bilanciamento del carico del servizio. A questo scopo, puoi usare un file YAML o direttamente, usando 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 algoritmo di bilanciamento del carico, abilitare 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
- loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
- failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
```
  Sostituisci quanto segue:
  - PROJECT_ID: l'ID progetto.
  - SERVICE_LB_POLICY_NAME: il nome del criterio 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.
  Dopo aver creato il file YAML, importalo in un nuovo criterio di bilanciamento del carico del servizio.
```
gcloud beta 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 caratteristiche dei criteri di bilanciamento del carico del servizio senza usare un file YAML.
  
  Per impostare l'algoritmo di bilanciamento del carico e abilitare il svuotamento automatico, utilizza i parametri seguenti:
```
gcloud beta 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 criterio 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.
Aggiorna un servizio di backend in modo che il campo --service-lb-policy faccia riferimento alla risorsa dei criteri di bilanciamento del carico del servizio appena creata. Un servizio di backend può essere associato a una sola risorsa del criterio di bilanciamento del carico del servizio.
```
gcloud beta 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 beta 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 beta compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

Imposta backend preferiti

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

gcloud

Aggiungi un backend preferito

Per impostare un backend preferito, usa il comando gcloud beta compute backend-services add-backend per impostare il flag --preference quando aggiungi il backend al servizio di backend.

gcloud beta 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 in uso (gruppo di istanze o NEG). Per tutti i parametri obbligatori, consulta il comando gcloud beta compute backend-services add-backend.

Aggiorna la preferenza di un backend

Per aggiornare il parametro --preference di un backend, utilizza il comando gcloud beta compute backend-services update-backend.

gcloud beta 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 la preferenza di un gruppo di istanza di backend e la imposta su PREFERRED:

gcloud beta 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 del 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 un nuovo criterio di bilanciamento del carico del servizio a un servizio di backend.

Per eseguire il debug dei problemi di traffico, utilizza Cloud Monitoring per osservare il flusso del traffico tra il bilanciatore del carico e il backend. Inoltre, i log e le metriche di Cloud Load Balancing possono aiutarti a comprendere il comportamento di bilanciamento del carico.

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

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 tuo traffico. Ad esempio, le percentuali di successo della cache potrebbero diminuire perché i backend rilevano il traffico da una selezione più ampia di client. In questo caso, valuta l'utilizzo di altri algoritmi come WATERFALL_BY_REGION.

Il traffico non viene inviato ai backend con molti endpoint in stato non integro

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 il download automatico della capacità. Tuttavia, questo significa che il traffico può essere inviato ai backend con molti endpoint in stato non integro e le richieste possono avere esito negativo.

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

Questo è il comportamento previsto se i tuoi backend preferiti sono più lontani rispetto a quelli 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 si utilizzano 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 di tempo di round trip per questi backend.

Se vuoi che il traffico venga inviato ad altri backend, puoi eseguire una delle seguenti operazioni:

Aggiorna le impostazioni delle preferenze per gli altri backend.
Imposta un'impostazione di capacità target inferiore per i tuoi backend preferiti. 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 cambiamenti di integrità temporanei

Questo è il comportamento previsto quando la soglia di failover è impostata su un valore alto. Se vuoi che il traffico continui verso i backend primari in caso di 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 distribuito tra gli endpoint rimanenti nello stesso backend. Se vuoi che il comportamento di failover venga attivato prima, imposta questo campo su un valore maggiore.

Limitazioni

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