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 gli obiettivi di disponibilità, prestazioni ed efficienza in termini di costi. Questo documento è rivolto 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, puoi creare un criterio di bilanciamento del carico del servizio (risorsa serviceLbPolicies), che contiene valori che influenzano la selezione di un backend. Potrai quindi 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 la modalità di bilanciamento del traffico 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.
- Spruzzi 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 qualsiasi opzione di bilanciamento del carico avanzato, 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 in che modo Cloud Service Mesh decide di instradare il traffico.
In primo luogo, Cloud Service Mesh sceglie un servizio di backend in base alle caratteristiche delle richieste e alle regole di routing nella risorsa o nella mappa URL Route, a seconda dell'API utilizzata dal deployment.
In secondo luogo, Cloud Service Mesh sceglie un gruppo di istanze gestite o un NEG di backend associato al servizio di backend, in base alla località 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 del gruppo di istanze gestite. 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 (NEG INTERNET_FQDN_PORT)
Casi d'uso
Le seguenti sezioni descrivono come funziona ciascun algoritmo e quale scegliere per le tue specifiche esigenze aziendali.
Bilancia il traffico tra i backend in una regione
L'algoritmo di bilanciamento del carico predefinito, a cascata per regione, distribuisce il traffico in modo uniforme tra tutti i MIG o 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 protezione da sovraccarico. 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, esiste traffico tra zone. Le richieste di ogni client possono essere distribuite su più MIG o NEG a livello di zona nella regione, il che aiuta a mantenere uniforme il carico sui MIG o sui NEG quando il carico del traffico dai client non è uniforme.
Aumenta la resilienza distribuendo il traffico da un client tra zone
L'algoritmo con struttura a cascata predefinita per regione cerca di bilanciare l'utilizzo della capacità in più MIG o NEG 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 to Region quando vuoi che i client distribuiscano le proprie richieste a tutti i MIG o NEG in una regione, in modo da ridurre il rischio di sovraccaricare i MIG o NEG in una singola zona quando si verifica un aumento rapido e localizzato del volume di traffico.
Con l'algoritmo Spray to Region, se sono presenti 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 al cambiamento.
Tieni presente che quando utilizzi l'algoritmo spray to Region, il traffico per ciascun client è sempre distribuito tra le zone di backend di una regione. Ciò si traduce in un traffico tra zone costantemente più elevato anche quando è disponibile capacità 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 di spray a regione distribuisce il traffico da 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 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 MIG o NEG del mondo in più regioni.
È importante notare che con questo algoritmo tutto il traffico viene distribuito su tutti i backend a livello globale. Una query con problemi potrebbe danneggiare tutti i backend nei deployment. L'algoritmo comporta inoltre un aumento del 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 instradato al MIG o NEG più vicino nella zona, fino alla sua capacità, prima di inviare il traffico al MIG o NEG successivo nella zona fino a quando non viene utilizzata tutta la capacità MIG o NEG nella zona. Solo a quel punto il traffico viene trasferito alla zona più vicina.
Con questo algoritmo, puoi ridurre al minimo il traffico tra zone non necessario. 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 tra gli algoritmi di bilanciamento del carico
La tabella seguente offre un confronto dettagliato dei quattro algoritmi di bilanciamento del carico di Cloud Service Mesh.
| Comportamento | Cascata per regione | Spray sull'area | Spray al mondo | Cascata per zona |
|---|---|---|---|---|
| Utilizzo uniforme della capacità all'interno di una regione in stato stabile | Sì | Yes | 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 una regione, ottimizzando al contempo la latenza di rete. Il traffico potrebbe essere inviato tra le zone, se necessario. | Sì | Sì | Sì, il traffico riempirà la zona più vicina alla sua capacità. Passa quindi alla zona successiva. |
| Sensibilità ai picchi di traffico nelle zone locali | Media: in base alla quantità di traffico già spostata per bilanciare le varie zone. | Minimo; poiché i picchi a zona singola verranno distribuiti in tutte le zone della regione. | Minimo; poiché i picchi a zona singola saranno distribuiti in tutte le regioni. | Maggiore; poiché i picchi di singola zona hanno maggiori probabilità di essere gestiti interamente da una singola zona fino a quando Cloud Service Mesh non è in grado di reagire. |
Altre opzioni avanzate di bilanciamento del carico
Le sezioni seguenti illustrano le opzioni per modificare il bilanciamento del carico di Cloud Service Mesh.
Backend preferiti
È possibile 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 prima il traffico 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 indirizzato a backend non preferiti. L'algoritmo di bilanciamento del carico distribuisce il traffico tra i backend non preferiti.
Un caso d'uso è l'overflow in 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 MIG o NEG di backend Google Cloud con scalabilità automatica. Questa configurazione può ridurre al minimo il consumo di computing di Google Cloud e avere comunque la resilienza necessaria per trasferire gradualmente o eseguire il failover su Google Cloud quando necessario.
Svuotamento 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 delle richieste al backend non integro. Inoltre, il traffico viene bilanciato tra backend in stato integro per prevenire il sovraccarico e ottimizzare la latenza complessiva.
Questa opzione è simile all'impostazione di capacityscalar su zero. Chiede a Cloud Service Mesh di fare automaticamente fare lo scale down a zero della capacità del backend quando le istanze o gli endpoint individuali di un backend superano i controlli di integrità inferiore al 25%. Con questa opzione, i backend in stato non integro vengono rimossi dal bilanciamento del carico globale.
Quando i backend sottoposti a svuotamento automatico sono nuovamente integri, non vengono scaricati 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 si preferisce un gruppo di istanze gestite o un NEG di backend e molti degli endpoint sono in stato non integro, questa impostazione protegge gli endpoint rimanenti nel gruppo di istanze gestite o nel NEG di backend spostando il traffico dal gruppo di istanze gestite o dal NEG.
Personalizza comportamento di failover
Cloud Service Mesh in genere invia il traffico ai backend prendendo in considerazione diversi fattori. In stato stabile, 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à. Sono chiamati backend primari.
Cloud Service Mesh tiene anche traccia dei backend da utilizzare quando i backend primari non sono integri e non sono in grado di ricevere traffico. Questi backend sono chiamati backend di failover. Di solito sono backend vicini con una certa capacità rimanente.
Quando un backend non è integro, Cloud Service Mesh cerca di evitare di inviarti traffico, spostando invece il traffico su 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 impostato determina quando il traffico viene spostato dai backend primari ai backend di failover.
Quando alcuni endpoint nel backend principale non sono integro, 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 sono in grado di gestire 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 a quelli di failover.
La soglia di integrità di 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 più alto avvia il failover del traffico prima di un valore inferiore.
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 del traffico verso i tuoi backend. Le metriche aggiuntive di Cloud Service Mesh e di rete possono aiutarti a capire come vengono prese le decisioni relative al 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 con la capacità configurata. Tieni presente che ciò non è garantito. Per ulteriori dettagli, puoi consultare la documentazione relativa al servizio di backend.
Il traffico viene quindi assegnato in base all'algoritmo utilizzato. Ad esempio, con l'algoritmo WATERFALL_BY_ZONE, Cloud Service Mesh tenta di mantenere il traffico verso la zona più vicina. Se controlli le metriche di rete, noterai che Cloud Service Mesh preferisce un backend con la latenza RTT più bassa durante l'invio di richieste per ottimizzare la latenza RTT complessiva.
Le sezioni seguenti descrivono i problemi che potresti riscontrare con il criterio di bilanciamento del carico del servizio e le impostazioni di backend preferite.
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. Per evitare questo comportamento, modifica i valori nel campo Backend preferiti.
Il traffico non viene inviato a MIG o NEG che hanno molti endpoint in stato non integro
Questo è il comportamento previsto quando i MIG o NEG vengono svuotati perché è 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 evitati. Se questo comportamento è indesiderato, puoi disabilitare l'impostazione autoCapacityDrain. Tuttavia, tieni presente che questo significa che il traffico potrebbe essere inviato a MIG o NEG con molti
endpoint in stato non integro, quindi le richieste potrebbero non riuscire 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à.
Se i backend preferiti sono configurati e non hanno raggiunto il limite di capacità, il traffico non verrà inviato ad altri MIG o NEG. I MIG o NEG preferiti verranno assegnati per primi in base alla latenza RTT di questi backend.
Se preferisci che il traffico venga inviato altrove, puoi configurare il servizio di backend senza backend preferiti o con stime più prudenti della capacità per i gruppi di istanze gestite o i NEG preferiti.
Il traffico viene inviato a troppi MIG o NEG distinti da un'unica origine
Questo è il comportamento previsto nei casi di utilizzo 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 man mano che i backend rilevano il traffico da una selezione più ampia di client. In questo caso, valuta la possibilità di usare altri algoritmi, ad esempio una cascata per regione.
Il traffico viene inviato a un cluster remoto quando cambia l'integrità del backend
Quando failoverHealthThreshold è impostato su un valore alto, questo è il comportamento previsto. Se vuoi che il traffico rimanga nei backend primari in caso di cambiamenti di integrità temporanei, imposta failoverHealthThreshold su un valore inferiore.
Gli endpoint in stato integro sono sovraccarichi quando alcuni endpoint non sono integri
Quando failoverHealthThreshold è impostato su un valore basso, questo è il comportamento previsto. Quando uno stato non è integro in alcuni endpoint, il traffico per questi endpoint in stato non integro 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 riportate le limitazioni e le considerazioni di cui è necessario tenere conto quando si configura il bilanciamento del carico avanzato.
Cascata per zona
Durante gli eventi di manutenzione trasparenti, è possibile che il traffico venga bilanciato temporaneamente al di fuori della zona locale.
Aspettati casi in cui alcuni MIG o NEG hanno raggiunto la capacità massima, mentre altri MIG o NEG nella stessa regione siano sottoutilizzati.
Se la sorgente del traffico verso il tuo servizio si trova nella stessa zona dei suoi endpoint, noterai una riduzione del traffico tra zone.
Una zona può essere mappata a diversi cluster di hardware fisico interno all'interno dei data center 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 sarà ottimizzata.
Spray verso una regione
Se gli endpoint in un MIG o NEG smettono di funzionare, le conseguenze sono generalmente distribuite su un gruppo 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 MIG o NEG nella regione, in alcuni casi potrebbe aumentare la quantità di traffico tra zone.
Il numero di connessioni aperte agli endpoint può aumentare, con un conseguente aumento dell'utilizzo delle risorse.
Backend preferiti
I gruppi di istanze gestite o i NEG configurati come backend preferiti potrebbero essere lontani dai client e causare una latenza media più elevata per i client. Questo può accadere anche se sono presenti altri MIG o NEG che potrebbero gestire i client con una latenza inferiore.
Gli algoritmi di bilanciamento del carico globale (cascata per regione, cascata per regione, cascata per zona) non si applicano ai gruppi di istanze gestite o ai NEG configurati come backend preferiti.
Scarico rapido automatico della capacità
Il numero minimo di gruppi di istanze gestite che non vengono mai svuotati è diverso dal valore impostato quando viene configurato utilizzando
serviceLbPolicies.Per impostazione predefinita, il numero minimo di gruppi di istanze gestite che non vengono mai svuotati è 1.
Se viene impostato il criterio
serviceLbPolicies, la percentuale minima di MIG o NEG che non vengono mai scaricati è del 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 è in stato integro.Affinché un MIG o un NEG venga annullato dopo uno svuotamento, almeno il 35% delle istanze o degli endpoint deve essere integro. Questa operazione è necessaria per garantire che un MIG o un NEG non vacilli tra gli stati di drenaggio e non drenati.
Qui si applicano le stesse restrizioni per lo scaler della capacità per i backend che non utilizzano una modalità di bilanciamento.
Passaggi successivi
- Per le istruzioni di configurazione, vedi Configurare il bilanciamento del carico avanzato.