Il buon livello di maturità a cui sono giunte le piattaforme di virtualizzazione ha spinto negli ultimi anni VMware a rivolgere sempre più l'attenzione verso un arricchimento e un perfezionamento dei tools che lavorano sul Management Plane (l'altro filone di ricerca tecnologica è quello che sta portando a virtualizzare gran parte delle risorse che finora erano rimaste appannaggio dell'infrastruttura fisica, quali l'intelligenza di rete e di storage). Uno dei più importanti di questi tool è certamente quello che si rivolge alla gestione delle operazioni, ovvero all'ottimizzazione delle risorse sfruttate. Quest'ultimo punto è particolarmente sentito dall'utenza amministrativa in quanto se è vero che un primo livello di gestione di un datacenter complesso consiste nella sua corretta implementazione e nella sua amministrazione giornaliera, un secondo livello, spesso altrettanto importante, è quello che si pone il problema di calibrare bene le risorse disponibili ed ottimizzare così i servizi offerti.

Il monitoraggio dei componenti di un datacenter virtuale al fine di ottimizzare le risorse impiegate è certamente un problema molto complesso, ed è tanto più complesso quanto più è alto il numero dei componenti interdipendenti e quanto più questa loro interdipendenza non può essere trascurata. Si capisce subito come gli strumenti predefiniti messi a disposizione dagli host e dal vCenter, sebbene sempre molto utili, siano largamente insufficienti per questo scopo ambizioso. I Performance Charts del vCenter e il tool ESXTOP dell'host hanno il pregio di fornirci facilmente lo stato di lavoro del sistema quando questo può essere descritto in modo significativo da poche metriche prese su tempi brevi, ma la situazione non è sempre così semplice. Quello che purtroppo succede soprattutto in datacenter molto grandi è che per avere informazioni significative è necessario correlare molte metriche e monitorarle su tempi molto lunghi. Se ad esempio si sperimenta un generico degrado di performance di una macchina virtuale può essere molto difficile relazionarlo ad una causa precisa e le metriche utili per dare informazioni in merito possono essere tante. Ma si può anche rovesciare la questione e chiedersi quando e in che modo si può dedurre la presenza di un problema di performance a partire da certe misure di monitoraggio, cioè quando è che il monitoraggio ci evidenzia un problema reale oppure no.

La risposta generale a questo tipo di problemi è quello della costruzione e utilizzo di una baseline, cioè di una descrizione accurata, attraverso le metriche misurate, dell'andamento "fisiologico" del sistema. Più si conosce il comportamento "normale" del sistema e meglio si riusciranno a cogliere le eventuali anomalie di funzionamento che si possono presentare. Ma per far funzionare un approccio del genere, di tipo essenzialmente statistico, è chiaro che avrò bisogno di monitoraggi estremamente estesi nel tempo e nel numero di metriche. Un'impresa assolutamente impossibile senza uno strumento dedicato.

Lo strumento di cui abbiamo bisogno dovrà essere in grado innanzitutto di campionare un gran numero di variabili per tempi molto lunghi. Se il sistema da monitorare è un datacenter basato su vSphere allora il nostro strumento si dovrà collegare con il vCenter da cui riceverà tutte le metriche necessarie e dovrà disporre di un database di raccolta. Su questi dati grezzi andranno fatte delle analisi statistiche con l'intento di calcolare per ogni oggetto monitorato e per ogni variabile che lo descrive un valore aspettato (in genere variabile nel tempo) e un suo intorno di valori altamente probabili, cioè delle soglie dinamiche entro cui ci aspettiamo di avere la metrica (vedi figura 1). A questo punto il nostro strumento dovrà essere in grado di registrare tutte le eventuali anomalie nell'andamento di queste variabili, cioè tutti i discostamenti significativi dai valori probabili, ed utilizzarle (correlandole assieme) per produrre degli alert che notifichino all'amministratore possibili malfunzionamenti (vedi figura 2). Inoltre sarà utile registrare gli andamenti generali di molte metriche su lunghi intervalli di tempo al fine di fare delle estrapolazioni da utilizzare sia per segnalare potenziali malfunzionamenti futuri sia per suggerire possibili misure correttive allo scopo di ottenere miglioramenti di efficienza.

Tutto questo dovrà funzionare senza il minimo intervento dell'amministratore il cui compito dovrà essere semplicemente quello di controllare ed interpretare gli alert che vengono prodotti. Per metterlo in grado di far questo al meglio possibile sarà necessario avere un'interfaccia grafica "parlante", cioè piena di elementi grafici ben riconoscibili (scale graduate, mappe colorate, classificazioni, strutture ad albero per le dipendenze degli oggetti monitorati, ecc.). Infine sarà molto utile chiedere al nostro strumento la capacità di farci redigere nel modo più veloce possibile dei report sullo stato di funzionamento del sistema sotto monitoraggio al fine di poter presentare la situazione ai referenti dell'attività in modo immediatamente leggibile.

Il vRealize Operation Manager è un'appliance che può essere distribuita come singolo nodo o come cluster per high availability (vedi figura 3). Il singolo nodo può essere installato in quattro differenti dimensioni (Extra Small, Small, Medium, Large) a seconda della grandezza dell'ambiente in cui deve operare. I passaggi generali dell'installazione sono quelli soliti di un'appliance: download del template OVF, deploy con il vSphere Web Client, accensione e collegamento via HTTPS all'appliance, scelta del tipo di installazione (nodo unico o cluster), primo login e collegamento al vCenter.

L'architettura a singolo nodo prevede la distribuzione di una sola appliance che si fa carico di tutte le attività; in alternativa l'architettura a nodi multipli (cluster), più adatta ad un ambiente scalabile, si può articolare in più appliances con ruoli diversi: il Master (primo nodo, gestisce tutte le operazioni), il Master replica (nodo completamente sincronizzato con il master), il Data (essenzialmente come una replica ma con alcune funzionalità in meno), il Remote controller (nodo che invia semplicemente i dati al master, senza archiviarli). La figura 4 illustra i quattro ruoli e le relative risorse gestite (i colori possono essere interpretati confrontandoli con la figura 5).

Il singolo nodo (o il master in un multinodo) è costituito fondamentalmente dai seguenti componenti: una User Interface costituita da un web application server, un Collector che comunica con gli adapters (componenti che connettono un sistema esterno da monitorare, ad esempio il vCenter) per ottenere le metriche dal sistema monitorato, un Controller che riceve le metriche dal collector e alimenta i database di raccolta, e un motore di analisi (Analytics) che elabora le metriche, le soglie dinamiche, processa gli alerts e i symptoms, archivia e recupera dati statistici e di relazione dai databases. Il caching e le scritture su DB vengono gestite dal componente Persistence (vedi figura 5).

L'Analytics, vero cuore del prodotto, usa lo storico di ciascuna metrica per costruire la baseline, ovvero il range di valori entro cui la metrica è considerata "normale". Ovviamente per validare le soglie dinamiche calcolate l'analytics ha bisogno di uno storico di diverse settimane. La metrica che esce dalla baseline (cioè esce dalle soglie che definiscono il suo comportamento "normale") produce delle anomalie (vedi figura 1). Queste sono il principale contributo alla generazione di sintomi che concorrono alla produzione finale di un alert (vedi figura 2).

Ogni alert viene classificato con un tipo di impatto e un livello di criticità. Il tipo di impatto viene rappresentato da un indicatore visivo chiamato Badge, mentre il livello di criticità ovvero lo stato del badge, viene rappresentato da un colore (verde, giallo, arancio, rosso). Poichè in un certo istante ad un badge possono essere associati più alert il colore del badge viene determinato dallo stato di criticità più alto tra tutti gli alert attivi. Va sottolineato che ogni oggetto del vCenter sotto monitoraggio viene trattato e rappresentato nel modo appena descritto e ovviamente il vRealize Operation Manager è in grado di rappresentare anche graficamente in modo efficacie le dipendenze tra i vari oggetti nella struttura ad albero. Questo consente all'amministratore di correlare più facilmente il malfunzionamento di un oggetto agli altri da cui dipende.

I tre badges principali sono: Health, Risk, Efficiency. Di seguito una loro breve descrizione.

Health: E’ il badge che segnala problemi in atto. Ad esso sono collegati tre badges secondari chiamati Workloads, Anomalies e Faults. Il primo registra la quantità di risorse consumate dall’oggetto (in termini di CPU, memoria, rete, disco), il secondo registra la quantità di anomalie rilevate, il terzo traccia la quantità di malfunzionamenti e la loro gravità. Attraverso questo badge il sistema ci mette in grado di rilevare i problemi che vanno presi in carico immediatamente al fine di evitare drastici peggioramenti.

Risk: E’ il badge che segnala problemi potenziali. Anch’esso ha tre badges secondari associati che concorrono al resource capacity risk, e sono il Capacity remaining, il Time remaining e lo Stress. Il primo misura la capacità di risorse ancora disponibile, il secondo misura il tempo rimanente prima che le risorse chieste da un oggetto si esauriscano (è una previsione basata sul Capacity remaining attuale e il tasso di crescita delle risorse chieste), il terzo misura l’area di Workload al di sopra di una certa soglia stabilita (il default è il 70%) su un periodo fissato (il default è 6 settimane). Attraverso questo badge il sistema cerca di avvisarci per tempo di possibili problemi futuri indicandocene la gravità e stimandone i tempi.

Efficiency: E’ il badge che segnala l’opportunità di ottimizzare le risorse. Ad esso sono associati due badges secondari chiamati Reclaimable capacity e Density. Il primo esprime la quantità di risorse che possono essere recuperate da un oggetto e messe a disposizione di altri oggetti dell’ambiente (è la differenza tra Usable capacity ed Effective demand), il secondo misura la bontà del rapporto di consolidamento tra risorse virtuali e risorse fisiche raggiunto nell’ambiente. Attraverso questo badge il sistema ci mette in condizioni di poter migliorare le prestazioni generali del datacenter ed eventualmente di fare attività di capacity planning e di stimare correttamente l’impatto di nuovi progetti (what if scenarios).

L’ultima versione del vRealize Operation Manager, la 6.3, è stata rilasciata alla fine di agosto, anche se sembrerebbe che il prossimo aggiornamento di vSphere (6.5) ne integrerà una ulteriore versione (6.4). Come le precedenti anche questa è disponibile come parte del vRealize Suite, parte del vCloud Suite, parte del vSphere with Operation Management e infine come prodotto singolo.

Di seguito i più importanti miglioramenti introdotti in questa versione, negli ambiti di stabilità del prodotto, delle sue performances e della sua usability.

Una risistemazione degli elementi grafici nella home dashboard l’ha resa estremamente più semplice ed efficacie. Da essa si può pensare di risolvere direttamente molti problemi senza cercarli nelle varie finestre di dettaglio. In particolare la presenza della lista degli alert con informazioni dettagliate consente numerosi interventi diretti, eseguibili dal link posizionato in seconda colonna subito dopo l’icona del livello di criticità (vedi figura 7). E’ possibile passare facilmente alle visualizzazioni degli alert relativi ai tre badge principali di cui si è discusso nel paragrafo precedente e altrettanto facilmente è possibile selezionare le informazioni del badge relativamente ad una categoria precisa di oggetti: vCenter, Cluster, Host, Virtual Machine. Lo status summary chart fornisce un sintetico report complessivo del badge su tutti gli oggetti del tipo selezionato. A fianco è presente anche una tabella che riporta la lista degli oggetti (sempre del tipo selezionato) più problematici con i relativi alert (top problem objects).

Questa dashboard è stata inserita per fornire un punto centralizzato dove poter avere velocemente le informazioni più importanti che riguardano tutti i cluster DRS del datacenter. In essa sono inclusi il livello di automatismo e il livello di migrazione del DRS, inoltre vengono visualizzati anche i carichi di lavoro per la CPU e per la memoria espressi in percentuale (figura 8, in alto). Se si seleziona un particolare cluster viene visualizzato anche il carico di ciascuno dei suoi host, anche questo sia per la CPU che per la memoria, sempre in percentuale (figura 8, in basso).

La nuova visualizzazione dei carichi di lavoro può aiutare a vedere situazioni di superutilizzo e contesa delle risorse (CPU e memoria) nelle varie dimensioni (Datacenter, Cluster, Host singoli). In tal modo fornisce all’amministratore un modo per bilanciare i carichi anche attraverso i vari cluster, mentre all’interno di ciascuno di essi continuerà ad esserci un bilanciamento automatico fornito dal DRS (se configurato). La figura 9 mostra come la grafica ci dica chiaramente che gli stessi due cluster risultano bilanciati dal punto di vista della CPU ma sbilanciati dal punto di vista della memoria (uno dei due è nella regione di “Overutilized”).

Il vRealize Operation Manager 6.3 introduce una nuova funzione automatica di analisi di sicurezza dell’infrastruttura vSphere basata sulla vSphere Hardening Guide. Precentemente questo tipo di analisi doveva essere fatta manualmente. Ovviamente la funzione di check automatico aumenta considerevolmente la sicurezza, come sempre succede. Una volta abilitata questa funzionalità il vRealize Operation Manager sarà in grado di emettere degli alert quando gli Hosts e/o le singole Virtual Machines violano le linee guida della vSphere Hardening Guide. I dettagli dell’alert conterranno chiaramente il riferimento alla policy violata della Hardening Guide e cosa fare per rimediare. Con la versione 6.3 sono anche aumentati i check di sicurezza sui vari oggetti del vCenter (gli host, le VMs, il vCenter stesso e i Distributed Switch).

A conclusione vanno almeno citate alcune novità di secondo piano (in quanto utili solo in particolari ambienti e in particolari circostanze di utilizzo) prese direttamente dalle Realease Notes del prodotto: