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 carico globale di bilanciamento e distribuzione del traffico per soddisfare al meglio le tue esigenze di disponibilità, di efficienza e costi. Questo documento è rivolto agli utenti che hanno una conoscenza intermedia di Cloud Service Mesh e dei concetti di bilanciamento del carico.

Nota: questa guida supporta Cloud Service Mesh solo con le API Google Cloud e non supporta le API Istio. Per ulteriori informazioni, vedi Panoramica di Cloud Service Mesh.

Per implementare il bilanciamento del carico avanzato, puoi creare un criterio di bilanciamento del carico del servizio (risorsa serviceLbPolicies), che contiene i valori che influenzano la selezione di un backend. Quindi collegherai il criterio di bilanciamento del carico del servizio a un backend completamente gestito di Google Cloud. Il criterio di bilanciamento del carico del servizio specifica l'algoritmo utilizzato determinare come bilanciare il 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 traffico a questi gruppi di istanze gestite oppure NEG prima di inviare traffico ad altri backend.
• Configura lo svuotamento automatico della capacità.
• Personalizza il comportamento di failover.

Prima di configurare qualsiasi opzione di bilanciamento del carico avanzata, di rivedere 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 che modo Cloud Service Mesh prende le decisioni sul bilanciamento del carico (fai clic per ingrandire)

Innanzitutto, Cloud Service Mesh sceglie un servizio di backend in base alla richiesta caratteristiche e, in base 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 il servizio di backend, in base alla località, alla località, all'integrità capacità del gruppo di istanze gestite o del NEG e informazioni nel 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 (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, struttura a cascata per regione, distribuisce il traffico in modo uniforme su tutti i MIG o NEG nelle zone di una regione. I nostri suggerimenti che utilizzi 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 che fornisce protezione dal sovraccarico del backend. Il traffico viene inviato attraverso limiti delle zone quando necessario per mantenere i backend caricati in modo uniforme all'interno regione. Anche se la zona locale del client ha capacità rimanente, è il traffico tra zone. Le richieste di ogni client possono essere distribuite più MIG o NEG a livello di zona nella regione, il che aiuta a mantenere il carico i MIG o i NEG sono uniformi 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à su più MIG o NEG a livello di zona. Tuttavia, in questo algoritmo provenienti da un solo client non vengono inviati in modo coerente a tutte le zone le richieste da un singolo client vengono generalmente instradate a MIG o NEG in un zona di destinazione.

Usa l'algoritmo spray to Region quando vuoi che i clienti diffondano i loro a tutti i MIG o NEG in una regione, il che riduce il rischio sovraccaricano MIG o NEG in una singola zona quando è presente una di aumento del volume di traffico.

Con l'algoritmo Spray to Region, se ci sono due zone, A e B, 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 innescare un sovraccarico nella zona prima Cloud Service Mesh è in grado di rispondere alla modifica.

Tieni presente che quando utilizzi l'algoritmo spray to Region, il traffico per ogni client viene sempre distribuiti tra le zone di backend di una regione. Ciò porta un aumento costante del traffico tra zone anche quando è disponibile capacità rimanente nella zona locale e ciò può comportare un'area interessata più ampia per il traffico da Cloud Service Mesh, se due client Cloud Service Mesh inviano il traffico verso le stesse zone.

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

Come discusso nelle sezioni precedenti, il traffico proveniente da ciascun client verso 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 traffico alla regione più vicina.

Se preferisci un raggio di diffusione più ampio, utilizza l'algoritmo spray to World. Con tramite questo algoritmo, i client diffondono le loro richieste a tutti i MIG o NEG nel mondo in più regioni.

È importante notare che con questo algoritmo, tutto il traffico viene distribuito di backend a livello globale. Una query con problemi potrebbe danneggiare tutti i backend in deployment di machine learning. L'algoritmo inoltre determina un aumento del traffico tra regioni, potrebbe aumentare la latenza delle richieste e generare costi aggiuntivi.

Riduci al minimo il traffico tra zone

Puoi ottimizzare la latenza complessiva e ridurre il traffico tra zone utilizzando il metodo 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 al prima di inviare il traffico al MIG o al NEG successivo nella zona fino a quando non viene utilizzata tutta la capacità MIG o NEG nella zona. Solo in questo caso il traffico si diffonde fino alla zona più vicina.

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

Confronto tra gli algoritmi di bilanciamento del carico

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

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ì	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 in un regione, ottimizzando al contempo la latenza di rete. Il traffico può essere inviato attraverso zone, se necessario.	Sì	Sì	Sì, il traffico riempirà la zona più vicina alla sua capacità. Poi andrà alla zona successiva.
Sensibilità ai picchi di traffico nelle zone locali	Nella media; a seconda della quantità di traffico già spostata tra zone diverse.	Minore; poiché i picchi a singola zona verranno distribuiti tra tutte le zone regione.	Minore; poiché i picchi a zona singola saranno distribuiti in tutte le regioni.	Maggiore; poiché è più probabile che i picchi di singola zona vengano gestiti completamente da una singola zona finché Cloud Service Mesh non è in grado di reagire.

Altre opzioni avanzate di bilanciamento del carico

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

Backend preferiti

Puoi configurare il bilanciamento del carico in modo che un gruppo di backend di un backend è designato come preferito. Questi backend vengono utilizzati completamente prima le richieste successive sono instradate ai backend rimanenti. Cloud Service Mesh distribuisce prima il traffico client ai backend preferiti, riducendo al minimo le richieste e la latenza minima per i tuoi clienti.

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

Un caso d'uso è l'overflow di Google Cloud, dove specifichi le risorse di risorse, rappresentate da un NEG di connettività ibrida, da utilizzare completamente prima le richieste vengono instradate a MIG o NEG di backend Google Cloud con scalabilità automatica. Questo può ridurre al minimo il consumo di computing di Google Cloud la resilienza necessaria per eseguire gradualmente la distribuzione o il failover Google Cloud quando necessario.

Svuotamento automatico della capacità

Quando un backend non è integro, di solito conviene escluderlo rapidamente possibili dalle decisioni di bilanciamento del carico. L'esclusione del backend impedisce le richieste non venga inviato al backend in stato non integro. Inoltre, il traffico viene bilanciato tra backend integri per evitare sovraccarichi e ottimizzare la latenza complessiva.

Questa opzione è simile all'impostazione del parametro capacityscalar a zero. Chiede a Cloud Service Mesh di fare automaticamente fare lo scale down della capacità di backend fino a zero quando un backend ha meno del 25% delle singole istanze o degli endpoint individuali. superando i controlli di integrità. Con questa opzione, i backend in stato non integro vengono rimossi con il bilanciamento del carico globale.

Quando i backend sottoposti a svuotamento automatico sono di nuovo in stato integro, non vengono scaricati 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, dello 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 MIG o un NEG backend e molti degli endpoint al suo interno sono non integro, questa impostazione protegge gli endpoint rimanenti nel gruppo di istanze gestite o nel NEG per lo spostamento del 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 considerazione. In stato stabile, Cloud Service Mesh invia il traffico ai backend selezionati in base agli algoritmi descritti in precedenza. L'elemento selezionato 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 possono ricevere traffico. Questi backend sono chiamati failover. Di solito sono backend vicini con una certa capacità rimanenti.

Quando un backend non è integro, Cloud Service Mesh cerca di evitare di inviare traffico a e distribuendo il traffico su backend integri.

La risorsa serviceLbPolicy include un campo, failoverHealthThreshold, la cui per controllare il comportamento di failover. Il valore di soglia che che imposti determina quando il traffico viene spostato dai backend primari al failover di backend.

Quando alcuni endpoint nel backend principale non sono integro, Cloud Service Mesh lo fa non spostano necessariamente il traffico immediatamente. Cloud Service Mesh potrebbe invece spostare il traffico verso endpoint integri nel backend principale, per cercare di stabilizzarsi per via del traffico.

Se troppi endpoint nel backend non sono integri, gli endpoint rimanenti vengono in grado di gestire traffico aggiuntivo. In questo caso, la soglia di errore è utilizzato per decidere se attivare o meno il failover. Cloud Service Mesh tollera stato non integro 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 che imposti determina quando Cloud Service Mesh indirizza il traffico ai backend di failover. Tu puoi impostare il valore su un numero intero compreso tra 1 e 99. Il valore predefinito per Cloud Service Mesh è pari a 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 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 come dei flussi di traffico verso i tuoi backend. Metriche aggiuntive di Cloud Service Mesh e rete può aiutarti a capire come vengono prese le decisioni relative al bilanciamento del carico. Questa sezione offre suggerimenti di mitigazione e risoluzione dei problemi generali.

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

Il traffico viene quindi assegnato in base all'algoritmo utilizzato. Ad esempio, con l'algoritmo di WATERFALL_BY_ZONE, Cloud Service Mesh cerca di mantenere il traffico alla zona più vicina. Se controlli le metriche di rete, vedrai 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 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 un MIG o NEG distanti. Se non vuoi che si verifichi questo comportamento, modifica i valori nella sezione 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é autoCapacityDrain è configurato. Con questa impostazione, MIG o NEG con molte gli endpoint in stato non integro verranno rimossi dalle decisioni di bilanciamento del carico e quindi da evitare. Se questo comportamento è indesiderato, puoi disattivare autoCapacityDrain dell'ambientazione. Tuttavia, tieni presente che questo significa che il traffico potrebbe essere inviato ai MIG o NEG con molte in stato non integro e di conseguenza le richieste potrebbero non riuscire con 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 non hanno ancora raggiunto la capacità massima.

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

Se preferisci che il traffico venga inviato altrove, puoi configurare il relativo servizio di backend senza backend preferiti o con capacità più conservativa per i MIG o 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 più ampia distribuzione dei tuoi per via del traffico. Ad esempio, le percentuali di successo della cache potrebbero essere ridotte man mano che i backend rilevano traffico. da una più ampia selezione di clienti. In questo caso, valuta la possibilità di utilizzare altre come la struttura a 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 valore comportamento degli utenti. Se vuoi che il traffico rimanga nei backend primari quando ci sono cambiamenti di stato temporanei, imposta failoverHealthThreshold su un valore più basso.

Gli endpoint in stato integro sono sovraccarichi quando alcuni endpoint non sono integri

Quando il valore di failoverHealthThreshold è impostato su un valore basso, questo è il valore previsto comportamento degli utenti. Quando alcuni endpoint sono in stato non integro, il traffico per questi endpoint 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 a un valore più alto.

Limitazioni e considerazioni

Di seguito sono riportate alcune limitazioni e considerazioni di cui devi essere a conoscenza quando configuri il bilanciamento del carico avanzato.

Cascata per zona

• In caso di eventi di manutenzione trasparenti, è possibile che il traffico venga equilibrato temporaneamente al di fuori della zona locale.

• Aspettati casi in cui alcuni MIG o NEG sono al completo, mentre altri MIG o I NEG nella stessa regione sono sottoutilizzati.

• Se la sorgente del traffico verso il tuo servizio si trova nella stessa zona del suo degli endpoint, si riduce il traffico tra zone.

• Una zona può 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 viene ottimizzata.

Spray verso una regione

• Se gli endpoint in un MIG o NEG smettono di funzionare, le conseguenze sono tipicamente distribuiti a un gruppo più ampio di clienti; in altre parole, un numero maggiore dei client mesh potrebbe essere interessato, ma in modo meno grave.

• Quando i client inviano richieste a tutti i MIG o NEG nella regione, in alcune casi, questo potrebbe aumentare la quantità di traffico tra zone.

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

Backend preferiti

• I MIG o NEG configurati come backend preferiti potrebbero essere lontani e potrebbe causare una latenza media più alta per i client. Ciò può accadere anche se ci sono altri MIG o NEG che potrebbero servire i clienti con minore latenza.

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

Scarico rapido automatico della capacità

• Il numero minimo di MIG che non vengono mai svuotati è diverso dal valore impostato se 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 sono mai svuotato è al 50%. In entrambe le configurazioni, un MIG o un NEG è contrassegnato come in stato non integro se meno del 25% delle istanze o degli endpoint nel gruppo di istanze gestite o nel NEG è integro.

• Affinché un MIG o NEG venga eliminato dopo uno svuotamento, almeno il 35% le istanze o gli endpoint devono essere integri. Questa operazione è necessaria per garantire che un MIG o il NEG non oscilla tra gli stati di scarico e non drenati.

• Le stesse restrizioni per lo scaler della capacità per i backend che non utilizzano un e la modalità di bilanciamento del carico.

Passaggi successivi

• Per le istruzioni di configurazione, vedi Configurare il bilanciamento del carico avanzato.