В abbiamo parlato dei nostri tentativi di utilizzare Watcher e abbiamo fornito un rapporto di prova. Conduciamo periodicamente tali test per il bilanciamento e altre funzioni critiche di una grande azienda o di un operatore cloud.
L’elevata complessità del problema da risolvere potrebbe richiedere diversi articoli per descrivere il nostro progetto. Oggi pubblichiamo il secondo articolo della serie, dedicato al bilanciamento delle macchine virtuali nel cloud.
Un po' di terminologia
La società VmWare ha introdotto l'utilità DRS (Distributed Resource Scheduler) per bilanciare il carico dell'ambiente di virtualizzazione sviluppato e offerto.
scrive
“VMware DRS (Distributed Resource Scheduler) è un'utilità che bilancia i carichi di elaborazione con le risorse disponibili in un ambiente virtuale. L'utilità fa parte di una suite di virtualizzazione chiamata VMware Infrastructure.
Con VMware DRS, gli utenti definiscono le regole per la distribuzione delle risorse fisiche tra macchine virtuali (VM). L'utilità può essere configurata per il controllo manuale o automatico. I pool di risorse VMware possono essere facilmente aggiunti, rimossi o riorganizzati. Se lo si desidera, i pool di risorse possono essere isolati tra diverse unità aziendali. Se il carico di lavoro su una o più macchine virtuali cambia drasticamente, VMware DRS ridistribuisce le macchine virtuali sui server fisici. Se il carico di lavoro complessivo diminuisce, alcuni server fisici potrebbero essere temporaneamente messi offline e il carico di lavoro consolidato."
Perché è necessario il bilanciamento?
A nostro avviso, DRS è una funzionalità cloud indispensabile, anche se ciò non significa che DRS debba essere utilizzato sempre e ovunque. A seconda dello scopo e delle esigenze del cloud, potrebbero esserci requisiti diversi per DRS e metodi di bilanciamento. Potrebbero esserci situazioni in cui il bilanciamento non è affatto necessario. O addirittura dannoso.
Per capire meglio dove e per quali clienti è necessario il DRS, consideriamo i loro scopi e obiettivi. I cloud possono essere suddivisi in pubblici e privati. Ecco le principali differenze tra questi cloud e gli obiettivi dei clienti.
Cloud privati/clienti aziendali di grandi dimensioni
Cloud pubblici / Medie e piccole imprese, persone
Il criterio principale e gli obiettivi dell'operatore
Fornire un servizio o un prodotto affidabile
Ridurre il costo dei servizi nella lotta in un mercato competitivo
Requisiti del servizio
Affidabilità a tutti i livelli e in tutti gli elementi del sistema
Prestazioni garantite
Assegna la priorità alle macchine virtuali in diverse categorie
Sicurezza delle informazioni e dei dati fisici
SLA e supporto XNUMX ore su XNUMX, XNUMX giorni su XNUMX
Massima facilità nel ricevere il servizio
Servizi relativamente semplici
La responsabilità dei dati è del cliente
Non è richiesta la definizione delle priorità delle VM
Sicurezza delle informazioni a livello di servizi standard, responsabilità del cliente
Potrebbero esserci dei problemi
Nessuno SLA, qualità non garantita
Supporto via e-mail
Il backup non è necessario
Caratteristiche del cliente
Gamma di applicazioni molto ampia.
Applicazioni legacy ereditate in azienda.
Architetture complesse personalizzate per ogni cliente.
Regole di affinità.
Il software funziona senza interruzioni in modalità 7x24.
Strumenti di backup al volo.
Carico clienti ciclico prevedibile.
Applicazioni tipiche: bilanciamento della rete, Apache, WEB, VPN, SQL
L'applicazione potrebbe interrompersi per un po'
Consente la distribuzione arbitraria delle VM nel cloud
Backup del cliente
Carico medio statistico prevedibile con un numero elevato di client.
Implicazioni per l'architettura
Geoclustering
Archiviazione centralizzata o distribuita
IBS riservato
Archiviazione dei dati locali sui nodi di calcolo
Obiettivi di bilanciamento
Distribuzione uniforme del carico
Massima reattività dell'applicazione
Tempo minimo di ritardo per il bilanciamento
Bilanciamento solo quando chiaramente necessario
Portare fuori alcune attrezzature per la manutenzione preventiva
Riduzione dei costi di servizio e dei costi degli operatori
Disabilitare alcune risorse in caso di carico basso
Risparmio energetico
Ridurre i costi del personale
Traiamo le seguenti conclusioni per noi stessi:
Per cloud privatifornito ai grandi clienti aziendali, DRS può essere utilizzato con le seguenti restrizioni:
- sicurezza delle informazioni e considerazione delle regole di affinità durante il bilanciamento;
- disponibilità di sufficienti risorse di riserva in caso di incidente;
- i dati della macchina virtuale si trovano su un sistema di archiviazione centralizzato o distribuito;
- separazione temporale delle procedure amministrative, di backup e di bilanciamento;
- bilanciamento solo all'interno di un aggregato di host client;
- bilanciare solo quando c'è un forte squilibrio, le migrazioni delle VM più efficaci e sicure (dopo tutto, la migrazione può fallire);
- bilanciamento di macchine virtuali relativamente “silenziosi” (la migrazione di macchine virtuali “rumorose” può richiedere molto tempo);
- bilanciamento tenendo conto del “costo” - carico del sistema di storage e della rete (con architetture personalizzate per grandi clienti);
- bilanciamento tenendo conto delle caratteristiche comportamentali individuali di ciascuna VM;
- Il bilanciamento viene preferibilmente effettuato durante le ore non lavorative (notti, fine settimana, festivi).
Per i cloud pubblicifornendo servizi ai piccoli clienti, DRS può essere utilizzato molto più spesso, con funzionalità avanzate:
- assenza di restrizioni sulla sicurezza delle informazioni e regole di affinità;
- bilanciamento all'interno del cloud;
- bilanciamento in qualsiasi momento ragionevole;
- bilanciare qualsiasi VM;
- bilanciamento delle macchine virtuali “rumorose” (per non disturbare gli altri);
- i dati della macchina virtuale si trovano spesso su dischi locali;
- tenendo conto delle prestazioni medie dei sistemi e delle reti di storage (l'architettura cloud è unificata);
- bilanciamento in base alle regole generali e alle statistiche disponibili sul comportamento del data center.
Complessità del problema
La difficoltà del bilanciamento è che DRS deve funzionare con un gran numero di fattori incerti:
- comportamento degli utenti di ciascuno dei sistemi informativi dei clienti;
- algoritmi per il funzionamento dei server dei sistemi informativi;
- comportamento dei server DBMS;
- carico su risorse informatiche, sistemi di archiviazione, rete;
- interazione dei server tra loro nella lotta per le risorse cloud.
Il carico di un gran numero di server applicativi e database virtuali sulle risorse cloud avviene nel tempo, le conseguenze possono manifestarsi e sovrapporsi a vicenda con un effetto imprevedibile in un tempo imprevedibile. Anche per controllare processi relativamente semplici (ad esempio, per controllare un motore, un sistema di riscaldamento dell'acqua in casa), i sistemi di controllo automatico devono utilizzare complessi algoritmi con feedback.
Il nostro compito è molto più complesso di molti ordini di grandezza e c'è il rischio che il sistema non riesca a bilanciare il carico sui valori stabiliti in un tempo ragionevole, anche se non ci sono influenze esterne da parte degli utenti.
Storia dei nostri sviluppi
Per risolvere questo problema, abbiamo deciso di non iniziare da zero, ma di basarci sull'esperienza esistente e abbiamo iniziato a interagire con specialisti con esperienza in questo campo. Fortunatamente, la nostra comprensione del problema coincideva completamente.
fase 1
Abbiamo utilizzato un sistema basato sulla tecnologia della rete neurale e abbiamo cercato di ottimizzare le nostre risorse in base ad essa.
L'interesse di questa fase stava nel testare una nuova tecnologia, e la sua importanza stava nell'applicare un approccio non standard per risolvere un problema dove, a parità di altre condizioni, gli approcci standard si erano praticamente esauriti.
Abbiamo lanciato il sistema e abbiamo davvero iniziato a bilanciare. Le dimensioni del nostro cloud non ci hanno permesso di ottenere i risultati ottimistici dichiarati dagli sviluppatori, ma era chiaro che il bilanciamento funzionava.
Allo stesso tempo, avevamo limitazioni piuttosto gravi:
- Per addestrare una rete neurale, le macchine virtuali devono funzionare senza modifiche significative per settimane o mesi.
- L'algoritmo è progettato per l'ottimizzazione basata sull'analisi di dati “storici” precedenti.
- L'addestramento di una rete neurale richiede una quantità piuttosto elevata di dati e risorse informatiche.
- L'ottimizzazione e il bilanciamento possono essere eseguiti relativamente raramente, una volta ogni poche ore, il che chiaramente non è sufficiente.
fase 2
Poiché non eravamo soddisfatti della situazione, abbiamo deciso di modificare il sistema e, per fare ciò, rispondere domanda principale – per chi lo stiamo preparando?
Primo: per i clienti aziendali. Ciò significa che abbiamo bisogno di un sistema che funzioni rapidamente, con quei vincoli aziendali che semplificano solo l’implementazione.
La seconda questione – cosa intendi con la parola “prontamente”? Dopo un breve dibattito abbiamo deciso che avremmo potuto iniziare con un tempo di risposta di 5-10 minuti, in modo che picchi a breve termine non mettessero il sistema in risonanza.
Terza domanda – quale dimensione del numero bilanciato di server scegliere?
Questo problema si è risolto da solo. In genere, i client non effettuano aggregazioni di server molto grandi e ciò è coerente con i consigli dell'articolo di limitare le aggregazioni a 30-40 server.
Inoltre, segmentando il pool di server, semplifichiamo il compito dell'algoritmo di bilanciamento.
Quarta domanda – quanto è adatta per noi una rete neurale con il suo lungo processo di apprendimento e il suo raro bilanciamento? Abbiamo deciso di abbandonarlo a favore di algoritmi operativi più semplici per ottenere risultati in pochi secondi.
È possibile trovare una descrizione di un sistema che utilizza tali algoritmi e dei suoi svantaggi
Abbiamo implementato e lanciato questo sistema e abbiamo ottenuto risultati incoraggianti: ora analizza regolarmente il carico del cloud e fornisce consigli per lo spostamento delle macchine virtuali, che sono in gran parte corretti. Anche adesso è chiaro che possiamo ottenere il 10-15% di rilascio di risorse per le nuove macchine virtuali migliorando al tempo stesso la qualità del lavoro di quelle esistenti.
Quando viene rilevato uno squilibrio nella RAM o nella CPU, il sistema invia comandi allo scheduler Tionix per eseguire la migrazione in tempo reale delle macchine virtuali richieste. Come si può vedere dal sistema di monitoraggio, la macchina virtuale si è spostata da un host (superiore) a un altro (inferiore) e ha liberato memoria sull'host superiore (evidenziato in cerchi gialli), rispettivamente occupandola su quello inferiore (evidenziato in bianco) cerchi).
Ora stiamo cercando di valutare in modo più accurato l'efficacia dell'attuale algoritmo e stiamo cercando di trovare possibili errori in esso.
fase 3
Sembrerebbe che ci si possa calmare, attendere la provata efficacia e chiudere l'argomento.
Ma siamo spinti a realizzare una nuova fase dalle seguenti ovvie opportunità di ottimizzazione
- Le statistiche, ad esempio, и mostra che i sistemi a due e quattro processori hanno prestazioni significativamente inferiori rispetto ai sistemi a processore singolo. Ciò significa che tutti gli utenti ricevono un output significativamente inferiore da CPU, RAM, SSD, LAN, FC acquistati nei sistemi multiprocessore rispetto ai sistemi a processore singolo.
- Gli stessi pianificatori delle risorse potrebbero avere errori gravi, su questo argomento.
- Le tecnologie offerte da Intel e AMD per il monitoraggio della RAM e della cache consentono di studiare il comportamento delle macchine virtuali e di posizionarle in modo tale che i vicini "rumorosi" non interferiscano con le macchine virtuali "silenziosi".
- Ampliamento del set di parametri (rete, sistema di storage, priorità della macchina virtuale, costo della migrazione, sua disponibilità alla migrazione).
In totale
Il risultato del nostro lavoro per migliorare gli algoritmi di bilanciamento è stata la chiara conclusione che utilizzando algoritmi moderni è possibile ottenere un'ottimizzazione significativa delle risorse del data center (25-30%) e allo stesso tempo migliorare la qualità del servizio clienti.
Un algoritmo basato su reti neurali è sicuramente una soluzione interessante, ma che necessita di ulteriore sviluppo e, a causa delle limitazioni esistenti, non è adatto a risolvere questo tipo di problemi sui volumi tipici dei cloud privati. Allo stesso tempo, l’algoritmo ha mostrato buoni risultati nei cloud pubblici di dimensioni significative.
Nei seguenti articoli ti diremo di più sulle capacità di processori, scheduler e bilanciamento di alto livello.
Fonte: habr.com