Questo è il secondo post sulle nuove funzionalità facenti parte dell'annuncio della nuova piattaforma Cloud che VMware ha fatto la scorsa settimana (il primo post sul licensing lo trovate qui), non voglio discutere tecnicamente il nuovo materiale, in quanto ci sono già un sacco di post sulle nuove feature, cercherò invece di aggiungere il mio commento ed il mio punto di vista a proposito di come migliorerà (o ostacolerà) la vita degli amministratori dell'infrastruttura.

Partiamo con una feature che è stata aggiornata: Storage I/O Control (aka SIOC) è una funzione che dà la possibilità di effettuare automaticamente il throttling dei 'noisy neighbors' (vicini rumorosi) della vostra infrastruttura sul versante I/O e di poter quindi prioritizzare i carichi di lavoro per IO con un meccanismo pressoché identico alle share che già si utilizzano normalmente nei resource pool.

SIOC è apparso in vSphere 4.1 supportando solo datastore a livello di blocco (VMFS) ed è stata una caratteristica molto ben accolta in ambienti di medie e grandi imprese, soprattutto dove non c'è una separazione fisica tra gli ambienti di storage e le risorse sono condivise, ora con vSphere 5 tutti questi miglioramenti sono resi disponibili anche per coloro che utilizzano datastore NAS (NFS).

Poi abbiamo lo Storage Dynamic Resource Sharing (a.k.a. Storage DRS o SDRS) che è un nuova tecnologia vSphere 5 che porta il famoso Dynamic Resource Sharing di VMware applicandolo ai datastore all'interno di un ambiente virtuale.

Storage DRS lavora su due aspetti diversi di storage con un obiettivo comune, che è quello di collocare e mantenere la vostra VM o VMDK nel Datastore giusto al momento giusto, sia per le prestazioni (garantendo basse latenze) sia per disponibilità (che garantisce spazio sufficiente per ospitare la VM senza incorrere in una condizione di out-of-space).

Storage DRS utilizza i dati statistici dello spazio disponibile e le metriche di latenza provenienti dal kernel ESX (vmkernel), e se mai avete aperto il cofano di ESX utilizzando esxtop sapete già che ci sono un sacco di metriche di storage disponibili.

Ora, se il vostro compito è quello di occuparvi tutti i giorni, anche con solo di una modica quantità di storage, posso capire il vostro entusiasmo 🙂

Ma c'è una grande questione lato storage in tutto questo.

Come ho già detto, queste nuove funzioni sono tutte belle e buone, ma cercano di capire e prevedere i comportamenti che da anni i fornitori di storage hanno provato a modificare, migliorare e rendere più intelligenti, senza ricorrere a tecniche lato host, sto parlando per lo più di wide striping e automated sub-lun tiering.

Ad esempio: se si attiva SIOC su un datastore che risiede su un pool di dischi che è condiviso tra carichi di lavoro ESX e non-ESX (piuttosto comune in un ambiente wide-striping) SIOC inizierà lamentarsi di un carico di lavoro esterno (external workload) che va ad "inquinare" le sue statistiche e calcoli, e questo comportamento può portare ad una situazione in cui dovrete scegliere se utilizzare uno o l'altro ma non entrambi, senza contare che molte persone hanno anche riferito che anche solo alcuni meccanismi di replica lato storage possono innescare l'errore. VMware ha un flowchart su come trattare con questo tipo di problematiche sul SIOC che puo' essere visionato qui: KB 1020651.

Dall'altra parte, Storage DRS non lavora bene con le metriche di latenza provenienti da un (vero) storage con automated sub-lun tiering, come probabilmente già sapete, in uno storage ATS un singolo datastore (o volume o LUN) puo' avere blocchi che risiedono su diversi livelli di storage, questo è ovviamente del tutto imprevedibile per l'host che vede solamente che una specifica IO è stata servita con una latenza (a volte anche drasticamente) diversa. Questo rovina completamente qualsiasi previsione o analisi di costo-rischio-beneficio che Storage DRS potrebbe fare su di esso, anche se c'è una nuova funzionalità denominata VASA che migliora il dialogo tra ESX e il controller dello storage non esiste una cosa come la comunicazione in tempo reale di dove risiede un singolo blocco, il sovraccarico di metadati sarebbe troppo grande. Invece gli algoritmi di posizionamento basati sullo spazio su disco funzionano bene comunque.

Queste caratteristiche, insieme, danno gli amministratori VMware qualcosa che molti hanno solo sognato in passato, ma queste caratteristiche spingeranno i vendor di storage a fornire delle scatole "stupide" di dischi? Una mossa che subito mi è venuta in mente è stata l'acquisizione di Engenio fatta da NetApp, la nuova linea è stata presentata come 'Big-data only', 'Hadoop-friendly' e 'solo per il mercato Media e Broadcast' ma la mia opinione è che diventeranno sempre più popolari in futuro se questo modello di avere l'intelligenza storage e QoS lato host persisterà con le nuove versioni di vSphere e magari verranno incluse in futuro in altri hypervisor.