In Abbiamo parlato dei tentativi di utilizzare Watcher e presentato un rapporto sui test. Effettuiamo periodicamente tali test per il bilanciamento e altre funzioni critiche di un grande cloud aziendale o operativo.
L'alta complessità del compito da svolgere potrebbe richiedere diversi articoli per descrivere il nostro progetto. Oggi pubblicheremo il secondo articolo della serie, dedicato al bilanciamento delle macchine virtuali nel cloud.
Un po' di terminologia
L'azienda VmWare ha introdotto l'utilità DRS (Distributed Resource Scheduler) per il bilanciamento del carico nella loro piattaforma di virtualizzazione.
Come scrive
«VMware DRS (Pianificatore delle risorse distribuite) è un'utilità che bilancia i carichi di lavoro computazionali con le risorse disponibili in un ambiente virtuale. L'utilità fa parte di un pacchetto di virtualizzazione chiamato VMware Infrastructure.
Con VMware DRS, gli utenti definiscono le regole per la distribuzione delle risorse fisiche tra le macchine virtuali (VM). L'utilità può essere configurata per gestire manualmente o automaticamente. I pool di risorse VMware possono essere facilmente aggiunti, rimossi o riorganizzati. Se desiderato, 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 tra i server fisici. Se il carico di lavoro complessivo diminuisce, alcuni server fisici possono essere temporaneamente spenti e il carico di lavoro consolidato.»
Perché è necessario il bilanciamento?
A nostro avviso, DRS è una funzione imprescindibile per il cloud, anche se questo 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 per le metodologie di bilanciamento. Potrebbero esserci situazioni in cui il bilanciamento non sia affatto necessario. O addirittura dannoso.
Per comprendere meglio dove e per quali clienti sia necessario DRS, consideriamo i loro obiettivi e le loro esigenze. I cloud possono essere suddivisi in pubblici e privati. Ecco le principali differenze tra questi cloud e gli obiettivi dei clienti.
Cloud privati / Grandi clienti aziendali
Cloud pubblici / Piccole e medie imprese, persone
Criterio principale e obiettivo dell'operatore
Fornire un servizio o un prodotto affidabile
Riduzione dei costi dei servizi nella lotta sul mercato competitivo
Requisiti per il servizio
Affidabilità a tutti i livelli e in tutti gli elementi del sistema
Prestazioni garantite
Prioritizzazione delle macchine virtuali in diverse categorie
Sicurezza informatica e fisica dei dati
SLA e supporto 24 ore su 24
Massima semplicità nell'ottenere il servizio
Servizi relativamente semplici
La responsabilità dei dati ricade sul cliente
Non è richiesta la prioritizzazione delle VM
Sicurezza informatica a livello di servizi standard, responsabilità a carico del cliente
Possono verificarsi interruzioni
Nessun SLA, qualità non garantita
Supporto via email
Backup non obbligatorio
Caratteristiche del cliente
Un'ampia gamma di applicazioni.
Applicazioni legacy, ereditate dall'azienda.
Architetture complesse personalizzate per ogni cliente.
Regole di affinità.
Funzionamento del software senza interruzioni in modalità 7x24.
Strumenti di backup "on-the-fly".
Carico ciclico prevedibile del cliente.
Applicazioni standard - bilanciamento del carico, Apache, WEB, VPN, SQL
È possibile interrompere l'applicazione per un certo periodo
È consentita una distribuzione arbitraria delle VM nel cloud
Backup a cura del cliente
Carico statisticamente medio prevedibile con un gran numero di clienti.
Consequenze per l'architettura
Geoclustering
Storage centralizzato o distribuito
SRK riservabile
Memorizzazione locale dei dati sui nodi di calcolo
Obiettivi del bilanciamento
Distribuzione uniforme del carico
Massima reattività delle applicazioni
Minimo tempo di latenza nel bilanciamento
Bilanciamento solo in caso di necessità esplicita
Messa in manutenzione preventiva di parte dell'hardware
Riduzione dei costi del servizio e delle spese operative
Disattivazione di parte delle risorse in caso di bassa domanda
Risparmio energetico
Riduzione dei costi del personale
Facciamo le seguenti conclusioni:
Per i cloud privati, forniti a grandi committenti aziendali, DRS può essere applicato tenendo conto dei seguenti vincoli:
- sicurezza informatica e considerazione delle regole di affinità durante il bilanciamento;
- disponibilità di una riserva adeguata di risorse in caso di emergenza;
- i dati delle macchine virtuali si trovano su storage centralizzato o distribuito;
- distribuzione nel tempo delle procedure di amministrazione, backup e bilanciamento;
- bilanciamento solo all'interno dell'aggregato degli host del cliente;
- bilanciamento solo in caso di forte sbilanciamento, le migrazioni delle VM più efficaci e sicure (poiché la migrazione può terminare con esito negativo);
- bilanciamento relativo a macchine virtuali "tranquille" (la migrazione di macchine virtuali "rumorose" può richiedere molto tempo);
- bilanciamento tenendo conto del "costo" — carico sugli storage di rete e sul network (per architetture personalizzate per grandi clienti);
- bilanciamento considerando le specifiche caratteristiche del comportamento di ogni VM;
- bilanciamento preferibilmente in orario non lavorativo (notte, fine settimana, festività).
Per i cloud pubblici, che forniscono servizi a piccoli clienti, il DRS può essere applicato molto più frequentemente, con funzionalità estese:
- assenza di restrizioni sulla sicurezza informatica e sulle regole di affinità;
- bilanciamento all'interno del cloud;
- bilanciamento in qualunque momento ragionevole;
- bilanciamento di qualsiasi VM;
- bilanciamento delle macchine virtuali "rumorose" (per non disturbare le altre);
- i dati delle macchine virtuali si trovano spesso su dischi locali;
- considerazione della performance media di storage e rete (architettura cloud unificata);
- bilanciamento secondo regole generali e statistiche sul comportamento dei datacenter.
La complessità del problema
La complessità del bilanciamento sta nel fatto che il DRS deve operare con un gran numero di fattori incerti:
- comportamento degli utenti di ciascuno dei sistemi informatici dei clienti;
- algoritmi di funzionamento dei server dei sistemi informatici;
- comportamento dei server del DBMS;
- carico sulle risorse computazionali, storage, rete;
- interazione tra server nella lotta per le risorse del cloud.
Il carico di un gran numero di server virtuali di applicazioni e basi dati sulle risorse del cloud si manifesta nel tempo, le conseguenze possono emergere e sovrapporsi l'una all'altra con effetti imprevedibili attraverso tempi imprevedibili. Anche per la gestione di processi relativamente semplici (ad esempio, per la gestione di un motore, di un sistema di riscaldamento a acqua domestico), i sistemi di regolazione automatica devono utilizzare complessi con retroazione.
Il nostro compito è di gran lunga più complesso e c'è il rischio che il sistema non riesca a effettuare un bilanciamento del carico verso valori stabiliti in un tempo ragionevole, anche se non ci saranno interferenze esterne da parte degli utenti.
Storia dei nostri sviluppi
Per risolvere questo problema, abbiamo deciso di non partire da zero, ma di basarci sulle esperienze esistenti e di interagire con specialisti già esperti in questo campo. Fortunatamente, la nostra comprensione della problematica era perfettamente allineata.
Fase 1
Abbiamo utilizzato un sistema basato su tecnologia di reti neurali e abbiamo cercato di ottimizzare le nostre risorse su di esso.
L'interesse di questa fase consisteva nella sperimentazione di una nuova tecnologia, e la sua importanza risiedeva nell'applicazione di un approccio non convenzionale alla risoluzione del problema, dove, a parità di condizioni, gli approcci standard erano praticamente esauriti.
Abbiamo lanciato il sistema e abbiamo davvero ottenuto un bilanciamento. La scala del nostro cloud non ci ha permesso di ottenere risultati ottimistici come dichiarato dagli sviluppatori, ma era evidente che il bilanciamento funzionava.
Tuttavia, avevamo limitazioni abbastanza serie:
- Per addestrare la rete neurale, è necessario che le macchine virtuali funzionino senza sostanziali cambiamenti per settimane o mesi.
- L'algoritmo è progettato per l'ottimizzazione basata sull'analisi di dati «storici» precedenti.
- Per addestrare la rete neurale è necessario un volume di dati e risorse computazionali sufficientemente grande.
- L'ottimizzazione e il bilanciamento possono essere effettuati relativamente di rado – ogni poche ore, il che è chiaramente insufficiente.
Fase 2
Poiché la situazione attuale non ci soddisfaceva, abbiamo deciso di modificare il sistema e per farlo rispondere a la domanda principale – per chi lo facciamo?
Inizialmente – per clienti aziendali. Questo significa che abbiamo bisogno di un sistema che funzioni in modo operativo, con quelle limitazioni aziendali che semplificano solo l'implementazione.
Secondo quesito – cosa intendiamo per «operativo»? A seguito di brevi dibattiti, abbiamo deciso che possiamo basarci su un tempo di risposta di 5 – 10 minuti, affinché brevi picchi non portino il sistema in risonanza.
Terza domanda – quale dimensione del numero di server bilanciati scegliere?
Questa questione si è risolta da sola. Di norma, i clienti non rendono gli aggregati dei server molto grandi, e questo è in linea con le raccomandazioni dell'articolo di limitare gli aggregati a 30-40 server.
Inoltre, segmentando il pool di server, semplifichiamo il compito per l'algoritmo di bilanciamento.
Quarto quesito – quanto è adatta per noi una rete neurale con il suo lungo processo di apprendimento e i rari bilanciamenti? Abbiamo deciso di rinunciare ad essa a favore di algoritmi operativi più semplici, in modo da ottenere risultati in pochi secondi.
Con la descrizione del sistema che utilizza tali algoritmi e le sue carenze è possibile documentarsi
Abbiamo implementato e avviato questo sistema ed ottenuto risultati promettenti – ora analizza regolarmente il carico del cloud e fornisce raccomandazioni per lo spostamento delle macchine virtuali, che sono in gran parte corrette. Anche ora è evidente che possiamo ottenere un rilascio del 10-15% di risorse per nuove macchine virtuali con un miglioramento della qualità del lavoro delle esistenti.
Quando viene rilevato uno squilibrio nella RAM o nella CPU, il sistema invia comandi al pianificatore TioniX per eseguire la migrazione live delle macchine virtuali necessarie. Come si evince dal sistema di monitoraggio, la macchina virtuale è stata spostata da un host (superiore) a un altro (inferiore) e ha liberato memoria sull'host superiore (evidenziato nei cerchi gialli), occupandola rispettivamente su quello inferiore (evidenziato nei cerchi bianchi).
Attualmente stiamo cercando di valutare più accuratamente l'efficacia dell'algoritmo attuale e stiamo cercando possibili errori.
Fase 3
A prima vista, si potrebbe pensare di fermarsi qui, aspettare un’efficacia comprovata e chiudere l'argomento.
Ma ci spingono a intraprendere una nuova fase le seguenti evidenti possibilità di ottimizzazione
- La statistica, ad esempio, e mostra che i sistemi a due e quattro processori hanno prestazioni significativamente inferiori a quelle dei sistemi a singolo processore. Ciò significa che tutti gli utenti ottengono un ritorno notevolmente inferiore dai CPU, RAM, SSD, LAN, FC acquistati nei sistemi multiprocessore rispetto ai singoli processori.
- I pianificatori di risorse stessi possono lavorare con errori seri, su questo tema.
- Le tecnologie proposte dalle aziende 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 disturbino le macchine virtuali "tranquille".
- Espansione dell'insieme di parametri (rete, storage, priorità della macchina virtuale, costo della migrazione, prontezza alla migrazione).
Totale
Il risultato del nostro lavoro volto a migliorare gli algoritmi di bilanciamento è stata una conclusione inequivocabile: grazie agli algoritmi moderni è possibile ottenere un'importante ottimizzazione delle risorse (25-30%) nei data center e allo stesso tempo migliorare la qualità del servizio ai clienti.
L'algoritmo basato su reti neurali è indubbiamente interessante, ma necessita di ulteriore sviluppo e, a causa delle limitazioni esistenti, non è adatto per affrontare questo tipo di problemi su volumi tipici dei cloud privati. Tuttavia, in cloud pubblici di dimensioni significative, l'algoritmo ha mostrato buoni risultati.
Parleremo più dettagliatamente delle capacità dei processori, degli scheduler e del bilanciamento di alto livello nei prossimi articoli.
Fonte: habr.com
