Panoramica del bilanciamento del carico avanzato

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Per informazioni sull'accesso a questa versione, consulta la pagina di richiesta di accesso.

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 gli obiettivi di disponibilità, prestazioni ed efficienza dei costi. Questo documento è destinato agli utenti che hanno almeno una conoscenza intermedia dei concetti di Cloud Service Mesh e del bilanciamento del carico.

Nota: questa guida supporta solo Cloud Service Mesh con le API Google Cloud e non supporta le API Istio. Per maggiori informazioni, consulta la panoramica di Cloud Service Mesh.

Per implementare il bilanciamento del carico avanzato, puoi creare un criterio di bilanciamento del carico del servizio (risorsa serviceLbPolicies), contenente valori che influenzano la selezione di un backend. Successivamente potrai collegare il criterio 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 il modo in cui il traffico viene bilanciato verso i backend.

Per il bilanciamento del carico avanzato puoi scegliere tra le seguenti opzioni dell'algoritmo:

• Struttura a cascata per regione (algoritmo predefinito).
• Spruzza sulla zona.
• Spruzza al mondo.
• Struttura a cascata per zona.

Sono disponibili le seguenti opzioni aggiuntive:

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

Prima di configurare una qualsiasi delle opzioni di bilanciamento del carico avanzato, ti consigliamo di rivedere la documentazione della risorsa del servizio di backend.

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

Il seguente diagramma mostra in che modo Cloud Service Mesh decide di instradare il traffico.

In che modo Cloud Service Mesh prende le 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 dal deployment.

In secondo luogo, Cloud Service Mesh sceglie un gruppo di istanze gestite o NEG di backend che viene associato al servizio di backend, in base alla posizione del client, alla posizione, all'integrità e alla capacità del gruppo di istanze gestite o del NEG e alle informazioni contenute nel criterio di bilanciamento del carico del servizio associato al servizio di backend.

Infine, Cloud Service Mesh sceglie un'istanza o un endpoint all'interno del gruppo di istanze gestite o NEG. Questa scelta si basa sulle informazioni contenute nel criterio 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 (NON_GCP_PRIVATE_IP_PORT NEG)

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

• Gruppi di istanze gestite a livello di regione
• Gruppi di endpoint di rete internet (INTERNET_FQDN_PORT NEG)

Casi d'uso

Le seguenti sezioni descrivono il funzionamento di ogni algoritmo e quali scegliere per le tue specifiche esigenze aziendali.

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 struttura a cascata per regione, i backend ricevono il traffico in proporzione alla loro capacità, il che fornisce la protezione da sovraccarico del backend. Il traffico viene inviato oltre i confini di 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, esiste traffico tra zone. Le richieste di ogni client possono essere distribuite tra più gruppi di istanze gestite o NEG a livello di zona nella regione, il che contribuisce a mantenere uniforme il carico sui gruppi di istanze gestite o NEG quando il carico del traffico dai client non è uniforme.

Aumenta la resilienza distribuendo il traffico di un client tra le zone

L'algoritmo con struttura a cascata predefinita per regione tenta di bilanciare l'utilizzo della capacità tra più MIG o NEG a livello di zona. 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 instradate a gruppi di istanze gestite o NEG in una singola zona.

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

Con l'algoritmo spray-to-region, 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 possa rispondere alla modifica.

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

Distribuisci il traffico dal tuo client su tutti i backend in più regioni

Come discusso nelle sezioni precedenti, l'algoritmo dello spray a regione distribuisce il traffico da ogni client a tutte le zone di una regione. Per i servizi con 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 Spray to World. Con questo algoritmo, i clienti diffondono le loro richieste a tutti i gruppi di istanze gestite o 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 con problemi potrebbe danneggiare tutti i backend nei deployment. L'algoritmo produce anche un maggiore traffico tra regioni, il che potrebbe aumentare la latenza delle richieste e creare costi aggiuntivi.

Ridurre 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 più MIG o NEG sono configurati in una zona, il traffico client viene instradato al MIG o al NEG più vicino nella zona, fino alla sua capacità, prima di inviarlo al MIG o al NEG successivo nella zona fino a quando non viene utilizzata tutta la capacità di MIG o NEG nella zona. Solo allora il traffico viene versato alla zona più vicina.

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

Confronto degli algoritmi di bilanciamento del carico

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

Comportamento	Cascata per regione	Spruzza su area	Spruzza nel mondo	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 distribuirà il traffico in modo uniforme tra le zone di un'area geografica ottimizzando al contempo la latenza di rete. Se necessario, il traffico può essere inviato tra le zone.	Sì	Sì	Sì, il traffico riempirà la zona più vicina alla sua capacità. Poi passerà alla zona successiva.
Sensibilità ai picchi di traffico delle zone locali	Media; in base a quanto traffico è già spostato per bilanciare tra le zone.	Inferiore; poiché i picchi di una singola zona verranno distribuiti in tutte le zone dell'area geografica.	Minore: poiché i picchi di una singola zona verranno distribuiti in tutte le regioni.	Maggiore; poiché i picchi in una singola zona hanno maggiori probabilità di essere gestiti interamente da una singola zona fino a quando Cloud Service Mesh non è in grado di reagire.

Ulteriori 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 innanzitutto il traffico dei client nei backend preferiti, riducendo al minimo le latenze delle richieste per i client.

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

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

Svuotamento automatico della capacità

Quando un backend non è integro, di solito è preferibile escluderlo il più rapidamente possibile dalle decisioni di bilanciamento del carico. L'esclusione del backend impedisce l'invio delle richieste al backend in stato 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 della capacità del backend fino a zero automaticamente quando un backend ha meno del 25% delle singole istanze o degli 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 svuotati automaticamente tornano in stato integro, vengono annullati se almeno il 35% degli endpoint o delle istanze rimane 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 è preferito un MIG o un NEG backend e molti endpoint sono in stato non integro, questa impostazione protegge gli endpoint rimanenti nel MIG o nel NEG allontanando il traffico dal MIG o dal NEG.

Personalizza il comportamento di failover

Cloud Service Mesh invia in genere il traffico ai backend prendendo in considerazione diversi fattori. In uno stato stazionario, Cloud Service Mesh invia il traffico ai backend selezionati in base agli algoritmi illustrati in precedenza. I backend selezionati sono considerati ottimali in termini di latenza e utilizzo della capacità. Sono detti backend primari.

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

Quando un backend non è integro, Cloud Service Mesh cerca di evitare di inviare traffico al backend, spostandolo invece verso backend integri.

La risorsa serviceLbPolicy include un campo, failoverHealthThreshold, il cui valore può essere personalizzato per controllare il comportamento del failover. Il valore della soglia che imposti determina quando il traffico viene spostato dai backend primari 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 principale, per cercare di stabilizzare il traffico.

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

La soglia di integrità del failover è un valore percentuale. Il valore impostato 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 maggiore avvia il failover del traffico prima di un valore inferiore.

Risoluzione dei problemi

I pattern di distribuzione del traffico possono cambiare in base alla configurazione del 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 del traffico verso i tuoi backend. Le metriche aggiuntive di Cloud Service Mesh e di rete possono aiutarti a comprendere 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 cerca di assegnare 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 per il servizio di backend.

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

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

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

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

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

Questo è il comportamento previsto quando i MIG o i NEG vengono svuotati perché è stato configurato un autoCapacityDrain. Con questa impostazione, i gruppi di istanze gestite o i NEG con molti endpoint in stato non integro verranno rimossi dalle decisioni di bilanciamento del carico e quindi sarebbero evitati. Se questo comportamento non è appropriato, puoi disattivare l'impostazione autoCapacityDrain. Tuttavia, tieni presente che questo significa che il traffico potrebbe essere inviato a MIG o NEG con molti endpoint non integri, quindi le richieste potrebbero non riuscire con errori.

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

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

Se i backend preferiti sono configurati e non hanno raggiunto il limite di capacità, il traffico non viene inviato ad altri MIG o NEG. I gruppi 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 della capacità più prudenti per i MIG o i NEG preferiti.

Il traffico viene inviato a troppi MIG o NEG distinti da una singola origine

Questo è il comportamento previsto in caso di utilizzo di spray-to-region o spray-to-world. Tuttavia, potresti riscontrare problemi con una distribuzione più ampia del tuo traffico. Ad esempio, le percentuali di successo della cache potrebbero essere ridotte quando i backend rilevano il traffico proveniente da una selezione più ampia di client. In questo caso, valuta l'utilizzo di altri algoritmi, come la struttura a cascata per regione.

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

Quando failoverHealthThreshold è impostato su un valore alto, si tratta del comportamento previsto. Se vuoi che il traffico rimanga nei backend principali in caso di modifiche temporanee allo stato, imposta failoverHealthThreshold su un valore più basso.

Gli endpoint integri sono sovraccarichi quando alcuni non sono integri

Se failoverHealthThreshold è impostato su un valore basso, si tratta del comportamento previsto. Quando alcuni endpoint non sono integri, il traffico per questi endpoint non integro potrebbe essere distribuito tra gli endpoint rimanenti nello stesso gruppo di istanze gestite 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 riportate le limitazioni e le considerazioni di cui devi tenere conto quando configuri il bilanciamento del carico avanzato.

Cascata per zona

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

• Aspettati i casi in cui alcuni MIG o NEG hanno raggiunto la capacità, 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 suoi endpoint, noterai una riduzione del traffico tra zone.

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

Spruzzatura

• Se gli endpoint in un MIG o un NEG non sono disponibili, le conseguenze sono generalmente distribuite su un insieme più ampio di client; in altre parole, un numero maggiore di client mesh potrebbe essere interessato, ma meno grave.

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

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

Backend preferiti

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

• Gli algoritmi di bilanciamento del carico globale (cascata per regione, spray-to-region, 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 se viene configurato utilizzando 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 è 50%. In entrambe le configurazioni, un MIG o un NEG è contrassegnato come non integro se meno del 25% delle istanze o degli endpoint nel MIG o nel NEG è integro.

• Affinché un MIG o un NEG venga annullato dopo uno svuotamento, almeno il 35% delle istanze o degli endpoint deve essere integro. Questo è necessario per garantire che un MIG o un NEG non vacili tra lo stato di svuotamento e lo stato non svuotato.

• Qui si applicano anche le stesse restrizioni per il gestore della scalabilità della capacità per i backend che non utilizzano una modalità di bilanciamento.

Passaggi successivi

• Per istruzioni sulla configurazione, consulta Configurare il bilanciamento del carico avanzato.