Panoramica del bilanciamento del carico avanzato

Il bilanciamento del carico avanzato è costituito da funzionalità che consentono di ottimizzare il bilanciamento del carico globale e la distribuzione del traffico per soddisfare al meglio i tuoi obiettivi di disponibilità, prestazioni ed efficienza dei costi. Questo documento è destinato agli utenti che hanno almeno una conoscenza intermedia di Cloud Service Mesh e dei concetti di bilanciamento del carico.

Per implementare il bilanciamento del carico avanzato, crea un criterio di bilanciamento del carico del servizio (risorsa serviceLbPolicies), che contiene valori che influenzano la selezione di un backend. Dopodiché, collega la policy di bilanciamento del carico del servizio a un servizio di backend. Il criterio di bilanciamento del carico del servizio specifica l'algoritmo utilizzato per determinare come viene bilanciato il traffico verso i backend.

Puoi scegliere tra le seguenti opzioni di algoritmo per il bilanciamento del carico avanzato:

  • A cascata per regione (algoritmo predefinito).
  • Spray a regione.
  • Spray globale.
  • A cascata per zona.

Sono disponibili le seguenti opzioni aggiuntive:

  • Designa i backend preferiti. Cloud Service Mesh invia il traffico a questi MIG o NEG prima di inviarlo ad altri backend.
  • Configurare lo svuotamento automatico della capacità.
  • Personalizza il comportamento di failover.

Prima di configurare una delle opzioni avanzate di bilanciamento del carico, ti consigliamo di consultare la documentazione relativa alla risorsa del servizio di backend.

In che modo Cloud Service Mesh instrada e bilancia il carico del traffico

Il seguente diagramma mostra come Cloud Service Mesh decide di instradare il traffico.

In che modo Cloud Service Mesh prende decisioni di bilanciamento del carico
In che modo Cloud Service Mesh prende decisioni di bilanciamento del carico (fai clic per ingrandire)

Innanzitutto, Cloud Service Mesh sceglie un servizio di backend in base alle caratteristiche della richiesta e alle regole di routing nella risorsa Route o nella mappa URL, a seconda dell'API utilizzata dalla tua implementazione.

In secondo luogo, Cloud Service Mesh sceglie un MIG o un NEG di backend associato al servizio di backend in base alla posizione del client, alla posizione, allo stato e alla capacità del MIG o del NEG e alle informazioni nella policy di bilanciamento del carico del servizio associata al servizio di backend.

Infine, Cloud Service Mesh sceglie un'istanza o un endpoint all'interno del MIG o del NEG. Questa scelta si basa sulle informazioni contenute nella policy di bilanciamento del carico per le località nei servizi di backend.

Backend supportati e non supportati

Per il bilanciamento del carico avanzato sono supportati i seguenti tipi di backend:

  • Gruppi di istanze non gestite
  • Gruppi di istanze gestite (MIG)
  • Gruppi di endpoint di rete a livello di zona (NEG GCE_VM_IP_PORT)
  • Gruppi di endpoint di rete con connettività ibrida (NEG NON_GCP_PRIVATE_IP_PORT)

I seguenti tipi di backend non sono supportati per il bilanciamento del carico avanzato:

  • Gruppi di istanze gestite regionali
  • Gruppi di endpoint di rete internet (NEG INTERNET_FQDN_PORT)

Casi d'uso

Le sezioni seguenti descrivono il funzionamento di ciascun algoritmo e quale scegliere per le esigenze specifiche della tua attività.

Bilancia il traffico tra i backend di una regione

L'algoritmo di bilanciamento del carico predefinito, a cascata per regione, distribuisce il traffico in modo uniforme tra tutti i MIG o i NEG nelle zone di una regione. Ti consigliamo di utilizzare l'algoritmo predefinito, a meno che tu non abbia requisiti speciali.

Con la cascata per regione, i backend ricevono il traffico in proporzione alla loro capacità, il che fornisce protezione dal sovraccarico del backend. Il traffico viene inviato oltre i confini della zona quando necessario per mantenere i backend caricati in modo uniforme all'interno della regione. Anche se la zona locale del client ha capacità rimanente, il traffico è interzona. Le richieste di ogni client possono essere distribuite su più MIG o NEG a livello di zona nella regione, il che contribuisce a mantenere uniforme il carico sui MIG o sui NEG quando il carico di traffico dai client non è uniforme.

Aumenta la resilienza distribuendo il traffico proveniente da un client tra le zone

L'algoritmo a cascata predefinito per regione tenta di bilanciare l'utilizzo della capacità in più MIG o NEG zonali. Tuttavia, in base a questo algoritmo le richieste provenienti da un singolo client non vengono inviate in modo coerente a tutte le zone e le richieste di un singolo client vengono in genere indirizzate a MIG o NEG in una singola zona.

Utilizza l'algoritmo di distribuzione a livello di regione quando vuoi che i client distribuiscano le richieste a tutti i MIG o i NEG in una regione, il che riduce il rischio di sovraccarico dei MIG o dei NEG in una singola zona in caso di aumento rapido e localizzato del volume di traffico.

Con l'algoritmo di distribuzione del traffico in una regione, se hai due zone, A e B, e si verifica un picco di traffico nella zona B, il traffico viene suddiviso tra le due zone. Con l'algoritmo predefinito, un picco nella zona B potrebbe attivare un sovraccarico nella zona prima che Cloud Service Mesh sia in grado di rispondere alla modifica.

Tieni presente che quando utilizzi l'algoritmo di distribuzione a zone, il traffico per ogni client viene sempre distribuito tra le zone di backend di una regione. Ciò comporta un traffico tra zone costantemente più elevato anche quando la capacità rimanente nella zona locale è sufficiente e può comportare un'area interessata più ampia per il traffico da Cloud Service Mesh, se due client Cloud Service Mesh inviano traffico alle stesse zone.

Distribuisci il traffico proveniente dal client in tutti i backend di più regioni

Come discusso nelle sezioni precedenti, l'algoritmo di distribuzione a livello di regione distribuisce il traffico di ogni client a tutte le zone di una regione. Per i servizi che hanno MIG o NEG in più regioni, Cloud Service Mesh ottimizza comunque la latenza complessiva inviando il traffico alla regione più vicina.

Se preferisci un raggio di diffusione più ampio, utilizza l'algoritmo di spruzzo sul mondo. Con questo algoritmo, i client distribuiscono le loro richieste a tutti i MIG o i NEG del mondo in più regioni.

È importante notare che con questo algoritmo tutto il traffico viene distribuito a tutti i backend a livello globale. Una query difettosa potrebbe danneggiare tutti i backend delle tue implementazioni. L'algoritmo genera anche più traffico tra regioni, il che potrebbe aumentare la latenza delle richieste e creare costi aggiuntivi.

Riduci al minimo il traffico tra zone

Puoi ottimizzare la latenza complessiva e ridurre il traffico tra zone utilizzando l'impostazione a cascata per zona. Quando in una zona vengono configurati più MIG o NEG, il traffico client viene indirizzato al MIG o al NEG più vicino nella zona, fino alla sua capacità, prima di inviare il traffico al MIG o al NEG successivo nella zona, finché non viene utilizzata tutta la capacità del MIG o del NEG nella zona. Solo allora il traffico viene trasferito alla zona più vicina successiva.

Con questo algoritmo, puoi ridurre al minimo il traffico tra zone non necessario. La latenza complessiva potrebbe essere leggermente migliorata perché vengono preferiti i backend locali più vicini. Tuttavia, questo potrebbe anche creare un traffico non uniforme nei MIG o nei NEG all'interno di una regione.

Confronto degli algoritmi di bilanciamento del carico

La seguente tabella fornisce un confronto dettagliato dei quattro algoritmi di bilanciamento del carico di Cloud Service Mesh.

Comportamento A cascata per regione Spray a regione Spray globale A cascata per zona
Utilizzo uniforme della capacità all'interno di una regione in stato stabile Sì Sì Sì No
Utilizzo uniforme della capacità in più regioni in stato stabile No No Sì No
Suddivisione uniforme del traffico all'interno di una regione in stato stabile No Sì Sì No
Traffico tra zone Sì. Questo algoritmo distribuisce il traffico in modo uniforme tra le zone di una regione ottimizzando la latenza di rete. Se necessario, il traffico può essere inviato tra le zone. Sì Sì Sì, il traffico riempirà la zona più vicina fino alla sua capacità. Poi passerà alla zona successiva.
Sensibilità ai picchi di traffico nella zona locale Media, a seconda della quantità di traffico già spostata per bilanciare le zone. Più basso, poiché i picchi di una singola zona verranno distribuiti in tutte le zone della regione. Inferiore, poiché i picchi di una singola zona verranno distribuiti in tutte le regioni. Più alto, poiché i picchi di una singola zona hanno maggiori probabilità di essere gestiti interamente da una singola zona finché Cloud Service Mesh non è in grado di reagire.

Altre opzioni avanzate di bilanciamento del carico

Le sezioni seguenti descrivono le opzioni per modificare il bilanciamento del carico di Cloud Service Mesh.

Backend preferiti

Puoi configurare il bilanciamento del carico in modo che un gruppo di backend di un servizio di backend sia designato come preferito. Questi backend vengono utilizzati completamente prima che le richieste successive vengano instradate ai backend rimanenti. Cloud Service Mesh distribuisce il traffico client prima ai backend preferiti, riducendo al minimo le latenze delle richieste per i tuoi clienti.

Il traffico che supera la capacità configurata dei backend preferiti viene instradato ai backend non preferiti. L'algoritmo di bilanciamento del carico distribuisce il traffico tra i backend non preferiti.

Un caso d'uso è l'overflow a Google Cloud, in cui specifichi le risorse di calcolo on-premise, rappresentate da un NEG di connettività ibrida, da utilizzare completamente prima che le richieste vengano indirizzate ai MIG o ai NEG di backend con scalabilità automatica Google Cloud . Questa configurazione può ridurre al minimo Google Cloud il consumo di risorse di calcolo e mantenere comunque la resilienza per eseguire gradualmente lo spill o il failover su Google Cloud quando necessario.

Scarico automatico della capacità

Quando un backend non è integro, in genere è consigliabile escluderlo il più rapidamente possibile dalle decisioni di bilanciamento del carico. L'esclusione del backend impedisce l'invio di richieste al backend non integro. Inoltre, il traffico viene bilanciato tra i backend integri per evitare il sovraccarico del backend e ottimizzare la latenza complessiva.

Questa opzione è simile all'impostazione di capacityscalar su zero. Chiede a Cloud Service Mesh di fare lo scale down automaticamente a zero la capacità del backend quando un backend ha meno del 25% delle sue singole istanze o endpoint che superano i controlli di integrità. Con questa opzione, i backend in stato non integro vengono rimossi dal bilanciamento del carico globale.

Quando i backend con svuotamento automatico tornano integri, vengono svuotati se almeno il 35% degli endpoint o delle istanze è integro per 60 secondi. Cloud Service Mesh non svuota più del 50% degli endpoint in un servizio di backend, indipendentemente dallo stato di integrità del backend.

Un caso d'uso è che puoi utilizzare lo svuotamento automatico della capacità con i backend preferiti. Se un MIG o un NEG di backend è preferito e molti dei relativi endpoint non sono integri, questa impostazione protegge gli endpoint rimanenti nel MIG o nel NEG spostando il traffico lontano dal MIG o dal NEG.

Personalizzare il comportamento di failover

Cloud Service Mesh in genere invia il traffico ai backend tenendo conto di diversi fattori. In uno stato stazionario, Cloud Service Mesh invia il traffico ai backend selezionati in base agli algoritmi descritti in precedenza. I backend selezionati sono considerati ottimali in termini di latenza e utilizzo della capacità. Si chiamano backend principali.

Cloud Service Mesh tiene traccia anche dei backend da utilizzare quando i backend principali non sono integri e non sono in grado di ricevere traffico. Questi backend sono chiamati backend di failover. Di solito si tratta di backend vicini con una certa capacità rimanente.

Quando un backend non è integro, Cloud Service Mesh tenta di evitare di inviargli traffico e lo sposta invece sui backend integri.

La risorsa serviceLbPolicy include un campo, failoverHealthThreshold, il cui valore può essere personalizzato per controllare il comportamento di failover. Il valore di soglia che imposti determina quando il traffico viene spostato dai backend principali ai backend di failover.

Quando alcuni endpoint nel backend principale non sono integri, Cloud Service Mesh non sposta necessariamente il traffico immediatamente. Cloud Service Mesh potrebbe invece spostare il traffico verso endpoint integri nel backend primario per cercare di stabilizzare il traffico.

Se troppi endpoint nel backend non sono integri, gli endpoint rimanenti non sono in grado di gestire il traffico aggiuntivo. In questo caso, la soglia di errore viene utilizzata per decidere se attivare o meno il failover. Cloud Service Mesh tollera l'integrità fino alla soglia, quindi sposta una parte del traffico dai backend primari ai backend di failover.

La soglia di integrità failover è un valore percentuale. Il valore che imposti determina quando Cloud Service Mesh indirizza il traffico ai backend di failover. Puoi impostare il valore su un numero intero compreso tra 1 e 99. Il valore predefinito per Cloud Service Mesh è 70 con Envoy e 50 per gRPC senza proxy. Un valore più grande avvia il failover del traffico prima di un valore più piccolo.

Risoluzione dei problemi

I pattern di distribuzione del traffico possono cambiare in base a come configuri il nuovo serviceLbPolicy con il servizio di backend.

Per eseguire il debug dei problemi di traffico, utilizza i sistemi di monitoraggio esistenti per esaminare il flusso di traffico verso i backend. Altre metriche di Cloud Service Mesh e di rete possono aiutarti a capire come vengono prese le decisioni di bilanciamento del carico. Questa sezione offre suggerimenti generali per la risoluzione dei problemi e la mitigazione.

Nel complesso, Cloud Service Mesh tenta di assegnare il traffico per mantenere i backend in esecuzione al di sotto della capacità configurata. Tieni presente che non è garantito. Per ulteriori dettagli, puoi consultare la documentazione del servizio di backend.

Il traffico viene quindi assegnato in base all'algoritmo che utilizzi. Ad esempio, con l'algoritmo WATERFALL_BY_ZONE, Cloud Service Mesh tenta di mantenere il traffico nella zona più vicina. Se controlli le metriche di rete, noterai che Cloud Service Mesh preferisce un backend con la latenza RTT più bassa quando invia richieste per ottimizzare la latenza RTT complessiva.

Le sezioni seguenti descrivono i problemi che potresti riscontrare con il bilanciamento del carico del servizio e le impostazioni del backend preferito.

Il traffico viene inviato a MIG o NEG più distanti prima di quelli più vicini

Questo è il comportamento previsto quando i backend preferiti sono configurati con MIG o NEG più distanti. Se non vuoi questo comportamento, modifica i valori nel campo backend preferiti.

Il traffico non viene inviato a MIG o NEG con molti endpoint non integri

Questo è il comportamento previsto quando i MIG o i NEG vengono svuotati perché è configurato un autoCapacityDrain. Con questa impostazione, i MIG o i NEG con molti endpoint non integri verranno rimossi dalle decisioni di bilanciamento del carico e quindi evitati. Se questo comportamento non è desiderato, puoi disattivare l'impostazione autoCapacityDrain. Tieni presente, tuttavia, che il traffico potrebbe essere inviato a MIG o NEG con molti endpoint non integri e quindi le richieste potrebbero non andare a buon fine e generare errori.

Il traffico non viene inviato ad alcuni MIG o NEG quando alcuni MIG o NEG sono preferiti

Questo è il comportamento previsto se i MIG o i NEG configurati come preferiti non hanno ancora raggiunto la capacità.

Quando i backend preferiti sono configurati e non hanno raggiunto il limite di capacità, il traffico non viene inviato ad altri gruppi di istanze gestite o gruppi di endpoint di rete. I MIG o NEG preferiti verranno assegnati per primi in base alla latenza RTT a questi backend.

Se preferisci che il traffico venga inviato altrove, puoi configurare il servizio di backend senza backend preferiti o con stime di capacità più conservative per i MIG o i NEG preferiti.

Il traffico viene inviato a troppi gruppi di istanze gestite o NEG distinti da una singola origine

Questo è il comportamento previsto se viene utilizzato spray-to-region o spray-to-world. Tuttavia, potresti riscontrare problemi con una distribuzione più ampia del tuo traffico. Ad esempio, i tassi di successo della cache potrebbero essere ridotti man mano che i backend vedono il traffico proveniente da una selezione più ampia di client. In questo caso, valuta la possibilità di utilizzare altri algoritmi, ad esempio la cascata per regione.

Il traffico viene inviato a un cluster remoto quando lo stato del backend cambia

Quando failoverHealthThreshold è impostato su un valore elevato, questo è il comportamento previsto. Se vuoi che il traffico rimanga nei backend primari quando si verificano cambiamenti temporanei dello stato, imposta failoverHealthThreshold su un valore inferiore.

Gli endpoint integri sono sovraccarichi quando alcuni endpoint non sono integri

Quando failoverHealthThreshold è impostato su un valore basso, questo è il comportamento previsto. Quando alcuni endpoint non sono integri, il traffico per questi endpoint non integri potrebbe essere distribuito tra gli endpoint rimanenti nello stesso MIG o NEG. Se vuoi che il comportamento di failover venga attivato in anticipo, imposta failoverHealthThreshold su un valore più alto.

Limitazioni e considerazioni

Di seguito sono riportati i limiti e le considerazioni di cui devi tenere conto quando configuri il bilanciamento del carico avanzato.

A cascata per zona

  • Durante gli eventi di manutenzione trasparenti, è possibile che il traffico venga temporaneamente bilanciato al di fuori della zona locale.

  • Prevedi casi in cui alcuni MIG o NEG raggiungono la capacità massima, mentre altri MIG o NEG nella stessa regione sono sottoutilizzati.

  • Se l'origine del traffico verso il tuo servizio si trova nella stessa zona dei relativi endpoint, il traffico tra zone viene ridotto.

  • Una zona potrebbe essere mappata a diversi cluster di hardware fisico interno all'interno dei data center Google, ad esempio a causa della virtualizzazione della zona. In questo caso, le VM nella stessa zona potrebbero non essere caricate in modo uniforme. In generale, la latenza complessiva verrà ottimizzata.

Spray a regione

  • Se gli endpoint di un MIG o NEG non funzionano, le conseguenze in genere si distribuiscono su un insieme più ampio di client. In altre parole, un numero maggiore di client mesh potrebbe essere interessato, ma in modo meno grave.

  • Poiché i client inviano richieste a tutti i gruppi di istanze gestite o NEG nella regione, in alcuni casi, ciò potrebbe aumentare la quantità di traffico tra zone.

  • Il numero di connessioni aperte agli endpoint può aumentare, causando un maggiore utilizzo delle risorse.

Backend preferiti

  • I MIG o i NEG configurati come backend preferiti potrebbero essere lontani dai client e potrebbero causare una latenza media più elevata per i client. Questo può accadere anche se esistono altri MIG o NEG che potrebbero servire i client con una latenza inferiore.

  • Gli algoritmi di bilanciamento del carico globale (a cascata per regione, spray-to-region, a cascata per zona) non si applicano ai MIG o ai NEG configurati come backend preferiti.

Scarico rapido automatico della capacità

  • Il numero minimo di MIG che non vengono mai svuotati è diverso dal valore impostato durante la configurazione tramite serviceLbPolicies.

  • Per impostazione predefinita, il numero minimo di MIG che non vengono mai svuotati è 1.

  • Se serviceLbPolicies è impostato, la percentuale minima di MIG o NEG che non vengono mai svuotati è del 50%. In entrambe le configurazioni, un MIG o un NEG viene contrassegnato come non integro se meno del 25% delle istanze o degli endpoint nel MIG o nel NEG sono integri.

  • Affinché un MIG o un NEG si svuoti dopo uno svuotamento, almeno il 35% delle istanze o degli endpoint deve essere integro. Questo è necessario per assicurarsi che un MIG o NEG non oscilli tra gli stati di scarico e non scarico.

  • Qui si applicano anche le stesse limitazioni per lo scalatore di capacità per i backend che non utilizzano una modalità di bilanciamento.

Passaggi successivi