In Abbiamo discusso i tentativi di utilizzare Watcher e presentato il rapporto sui test. Questi test vengono eseguiti periodicamente per l'equilibrio e altre funzioni critiche nel grande cloud aziendale o di operatore.
L'elevata complessità del problema da risolvere potrebbe richiedere diversi articoli per descrivere il nostro progetto. Oggi pubblichiamo il secondo articolo del ciclo, dedicato all'equilibratura delle macchine virtuali nel cloud.
Un po' di terminologia
La società VmWare ha introdotto lo strumento DRS (Distributed Resource Scheduler) per bilanciare il carico nell'ambiente di virtualizzazione da loro sviluppato e offerto.
Come scrive
«VMware DRS (Pianificatore delle risorse distribuite) è uno strumento che bilancia i carichi di lavoro informatici con le risorse disponibili in un ambiente virtuale. Lo strumento fa parte del 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'utility può essere configurata per la gestione manuale o automatica. I pool di risorse VMware possono essere facilmente aggiunti, rimossi o riorganizzati. Se necessario, 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 riconfigura le macchine virtuali tra i server fisici. Se il carico di lavoro complessivo diminuisce, alcuni server fisici possono essere temporaneamente spenti, consolidando il carico di lavoro.
Perché è necessaria la bilanciatura?
A nostro avviso, DRS è una funzione indispensabile nel cloud, anche se ciò non significa che DRS debba essere sempre e ovunque utilizzato. A seconda dello scopo e delle necessità del cloud, possono esserci requisiti diversi per DRS e per i metodi di bilanciamento. Potrebbero esserci situazioni in cui la bilanciatura non è affatto necessaria. O addirittura dannosa.
Per comprendere meglio dove e per quali clienti è necessaria DRS, esaminiamo i loro obiettivi e compiti. Le nuvole possono essere suddivise in pubbliche e private. Ecco le principali differenze tra queste nuvole e gli obiettivi dei clienti.
Nuvole private / Grandi clienti aziendali
Nuvole pubbliche / Piccole e medie imprese, privati
Criteri e obiettivi principali dell'operatore
Fornire un servizio o prodotto affidabile
Ridurre i 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 su più categorie
Sicurezza fisica e informativa dei dati
SLA e supporto 24 ore su 24
Massima semplicità nell'ottenere il servizio
Servizi relativamente semplici
La responsabilità dei dati è del cliente
Non è necessaria la prioritizzazione delle VM
Sicurezza informatica a livello di servizi standard, responsabilità del cliente
Possono verificarsi interruzioni
Nessun SLA, qualità non garantita
Supporto via email
Backup non obbligatorio
Caratteristiche del cliente
Vasta gamma di applicazioni.
Applicazioni legacy ereditate nell'azienda.
Architetture personalizzate complesse per ogni cliente.
Regole di affinità.
Funzionamento del software senza interruzioni in modalità 7x24.
Strumenti di backup "in tempo reale".
Carico ciclico prevedibile del cliente.
Applicazioni standard – bilanciamento del carico, Apache, WEB, VPN, SQL.
Possibile fermo dell'applicazione per un certo periodo.
Distribuzione arbitraria delle VM nel cloud consentita.
Backup gestito dal cliente.
Carico statisticamente medio prevedibile con un gran numero di clienti.
Implicazioni per l'architettura.
Geoclustering.
Storage centralized o distribuito.
SRK riservabile.
Storage locale dei dati sui nodi computazionali.
Obiettivi di bilanciamento.
Distribuzione uniforme del carico.
Massima reattività delle applicazioni.
Minimo tempo di latenza per il bilanciamento.
Bilanciamento solo in caso di necessità esplicita.
Messa fuori servizio di parte dell'hardware per manutenzione preventiva.
Riduzione del costo del servizio e delle spese operative.
Disattivazione di parte delle risorse in caso di bassa carico.
Risparmio energetico.
Riduzione dei costi del personale
Facciamo le seguenti considerazioni:
Per le nuvole private, fornite a grandi clienti aziendali, il DRS può essere applicato tenendo conto delle limitazioni:
- sicurezza informatica e rispetto delle regole di affinità durante il bilanciamento;
- disponibilità di una riserva sufficiente di risorse in caso di emergenza;
- i dati delle macchine virtuali si trovano su uno storage centralizzato o distribuito;
- scaglionamento temporale delle procedure di amministrazione, backup e bilanciamento;
- bilanciamento solo all'interno dell'aggregato di host del cliente;
- bilanciamento solo in caso di forte sbilanciamento, le migrazioni delle VM più efficaci e sicure (poiché la migrazione potrebbe non riuscire);
- bilanciamento rispetto a macchine virtuali 'tranquille' (la migrazione di macchine virtuali 'rumorose' può richiedere molto tempo);
- bilanciamento tenendo conto del 'costo' - il carico su storage e rete (in architetture personalizzate per grandi clienti);
- bilanciamento tenendo conto delle peculiarità di comportamento di ogni VM;
- il bilanciamento dovrebbe idealmente avvenire durante il tempo non lavorativo (notte, fine settimana, festività).
Per le nuvole pubbliche, fornendo servizi a piccoli clienti, DRS può essere applicato molto più frequentemente, con funzionalità ampliate:
- assenza di restrizioni sulla sicurezza informatica e regole di affinità;
- bilanciamento all'interno del cloud;
- bilanciamento in qualsiasi momento ragionevole;
- bilanciamento di qualsiasi VM;
- bilanciamento di macchine virtuali "rumorose" (per non disturbare le altre);
- i dati delle macchine virtuali si trovano spesso su dischi locali;
- considerazione delle prestazioni medie di storage e rete (l'architettura del cloud è unitaria);
- bilanciamento secondo regole generalizzate e statistiche comportamentali esistenti del data center.
La difficoltà del problema
La difficoltà del bilanciamento risiede nel fatto che DRS deve funzionare con un gran numero di fattori incerti:
- il comportamento degli utenti di ciascun sistema informativo dei clienti;
- gli algoritmi di funzionamento dei server dei sistemi informativi;
- il comportamento dei server DBMS;
- il carico sulle risorse di calcolo, storage, rete;
- l'interazione tra i server nella lotta per le risorse del cloud.
Il carico di un grande numero di server virtuali per applicazioni e database sulle risorse cloud si manifesta nel tempo, e le conseguenze possono sovrapporsi l'una sull'altra con effetti imprevedibili in un intervallo temporale incerto. Anche per gestire processi relativamente semplici (come controllare un motore o un sistema di riscaldamento a acqua domestico), i sistemi di regolazione automatica necessitano di utilizzare complessi con retroazione.
Il nostro compito è molte volte più complesso, e c'è il rischio che il sistema non riesca a bilanciare il carico verso valori stabili in un periodo di tempo ragionevole, anche in assenza di influenze esterne da parte degli utenti.
La storia dei nostri sviluppi
Per affrontare questo problema, abbiamo deciso di non partire da zero, ma di basarci sull'esperienza esistente, collaborando con esperti che hanno competenze in questo campo. Per fortuna, la nostra comprensione della problematica era completamente allineata.
Fase 1
Abbiamo utilizzato un sistema basato sulla tecnologia delle reti neurali e abbiamo cercato di ottimizzare le nostre risorse su questa base.
L'interesse di questa fase consisteva nel testare una nuova tecnologia, mentre la sua importanza risiede nell'applicazione di un approccio non convenzionale per affrontare il problema, dove, a parità di condizioni, gli approcci standard hanno praticamente esaurito le loro possibilità.
Abbiamo avviato il sistema e la bilanciatura ha effettivamente iniziato a funzionare. La scala del nostro cloud non ci ha permesso di ottenere risultati ottimisti, come dichiarato dagli sviluppatori, ma era evidente che la bilanciatura stava operando.
Tuttavia, avevamo delle limitazioni piuttosto significative:
- Per addestrare la rete neurale, è necessario che le macchine virtuali funzionino senza cambiamenti significativi per settimane o mesi.
- L'algoritmo è progettato per ottimizzare in base all'analisi di dati 'storici' precedenti.
- Per addestrare la rete neurale è richiesto un volume piuttosto grande di dati e risorse computazionali.
- L'ottimizzazione e la bilanciatura possono essere eseguite relativamente di rado - ogni poche ore, il che è chiaramente insufficiente.
Fase 2
Poiché non eravamo soddisfatti della situazione, abbiamo deciso di modificare il sistema e per questo rispondere a la domanda principale – per chi la stiamo realizzando?
Inizialmente – per i clienti aziendali. Significa che abbiamo bisogno di un sistema che funzioni in modo rapido, con quelle limitazioni aziendali che semplificano solo l'implementazione.
La seconda domanda – cosa intendiamo con il termine «rapido»? Dopo brevi dibattiti, abbiamo deciso di basarci su un tempo di risposta di 5-10 minuti, in modo che brevi picchi non mettano il sistema in risonanza.
La terza domanda – che dimensione del numero bilanciato di server scegliere?
Questa domanda si è risolta da sola. In genere, i clienti non costruiscono aggregati di server molto grandi, e questo corrisponde alle raccomandazioni dell'articolo di limitare gli aggregati a 30-40 server.
Inoltre, segmentando il pool di server, semplifichiamo il compito dell'algoritmo di bilanciamento.
La quarta domanda – quanto ci si addice una rete neurale con il suo lungo processo di apprendimento e rari bilanciamenti? Abbiamo deciso di rinunciare a essa a favore di algoritmi operativi più semplici, per ottenere risultati in pochi secondi.
È possibile consultare una descrizione del sistema che utilizza tali algoritmi e le sue carenze.
Abbiamo implementato e avviato questo sistema, ottenendo risultati promettenti: attualmente analizza regolarmente il carico del cloud e fornisce raccomandazioni per lo spostamento delle macchine virtuali, che sono in gran parte corrette. Anche adesso, è evidente che possiamo ottenere un recupero delle risorse del 10-15% per nuove macchine virtuali, migliorando al contempo la qualità del lavoro delle esistenti.
Quando viene rilevato uno sbilanciamento tra RAM o CPU, il sistema invia comandi al pianificatore Tionix per eseguire la migrazione in tempo reale delle macchine virtuali richieste. Come visibile nel sistema di monitoraggio, la macchina virtuale è stata trasferita da un host (superiore) a un altro (inferiore) liberando memoria sull'host superiore (evidenziato nei cerchi gialli) e occupando spazio sull'host inferiore (evidenziato nei cerchi bianchi).
Attualmente ci stiamo sforzando di valutare più precisamente l'efficacia dell'algoritmo in uso e stiamo cercando possibili errori al suo interno.
Fase 3
A questo punto, sembrerebbe che si possa sospendere e attendere l'efficacia comprovata, chiudendo così il tema.
Ma ci spingono a intraprendere una nuova fase grazie alle seguenti evidenti opportunità di ottimizzazione.
- Le statistiche, ad esempio, e dimostrano che i sistemi a due e quattro processori hanno prestazioni significativamente inferiori a quelle dei sistemi a singolo processore. Quindi, tutti gli utenti ottengono da quelli acquistati in sistemi multiprocessore CPU, RAM, SSD, LAN, FC un rendimento notevolmente inferiore rispetto ai sistemi a singolo processore.
- I pianificatori delle risorse stesse possono operare con errori significativi, su questo argomento.
- Le tecnologie proposte da Intel e AMD per il monitoraggio di RAM e 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 del set di parametri (rete, storage, priorità della macchina virtuale, costo della migrazione, prontezza alla migrazione).
Totale
Il risultato del nostro lavoro di miglioramento degli algoritmi di bilanciamento è stata una conclusione chiara: grazie agli algoritmi moderni è possibile ottenere un'ottimizzazione significativa delle risorse (25-30%) nei data center e al contempo migliorare la qualità del servizio ai clienti.
L'algoritmo basato su reti neurali è sicuramente interessante, ma necessita di ulteriore sviluppo e, a causa delle attuali limitazioni, non è adatto a risolvere compiti di questo tipo con volumi tipici delle nuvole private. Tuttavia, nelle nuvole pubbliche di grandi dimensioni, l'algoritmo ha mostrato buoni risultati.
Nelle prossime articoli parleremo delle funzionalità dei processori, dei pianificatori e dell'equilibratura di alto livello.
Fonte: habr.com
