Questo perché VMWare è stata ed è tuttora, senz’alcun ombra di dubbio, la piattaforma di virtualizzazione dominante del mercato in quanto l’unica ad avere le funzionalità di tipo Enterprise richieste dai clienti e necessarie all’erogazione dei servizi IT nel Private Cloud.
Sotto la spinta del movimento Open Source I trend di mercato stanno modificando questo scenario e Cloud-OS nuovi/alternativi stanno emergendo e crescendo in termini di maturità tecnologica.
Lo studio di Wikibon ,sintetizzato nella slide sottostante, illustra quantitativamente questo trend che coinvolge con differenti motivazioni e strategie il 51% dei clienti intervistati rappresentati da coloro che per vari motivi (economici o al fine di perseguire strategie dual/multi vendor anti lock-in) mostrano interesse nell’avere due piattaforme di virtualizzazione all’interno del loro DC.
Questi “Nuovi/Alternativi” Cloud-OS, pur non avendo raggiunto il livello maturità di VMWare, iniziano ad affermarsi in determinati ambienti IT, essenzialmente quelli non critici, come valide alternative all’erogazione di servizi IT nel Private Cloud.
Nel momento in cui questi nuovi Cloud-OS vengono affiancati ai Cloud-OS esistenti i clienti finiscono per avere in casa un ambiente Multi-Hypervisor la cui integrazione con il resto dell’infrastruttura deve essere attentamente valutata in termini di efficienza, costi e semplicità di gestione.
In questo post considereremo un ambiente Multi-Cloud OS / Multi-Hypervisor costituito dalle due piattaforme di virtualizzazione di riferimento del mercato per la parte proprietaria e Open Source rappresentate rispettivamente da VMWare e Open Stack nel contesto della soluzione di “Software Defined Storage” di EMC denominata ViPR.
Nel nostro percorso inizieremo considerando dapprima i livelli di integrazione delle due piattaforme di Cloud-OS e successivamente ne analizzeremo i punti di integrazione con il layer di virtualizzazione storage “Software Defined” sottostante.
OpenStack è la piattaforma di Cloud OS Open Source più adottata grazie all’ampio supporto fornitole dai maggiori Provider del mercato IT i cui Gold Members sono mostrati nella figura sottostante.
Non sarà sfuggito ai più attenti che tra i Gold Members c’è anche VMWare la cui “Dichiarazione di Supporto” per OpenStack si può trovare qui e la cui Comunità di supporto si può trovare qui !
Come è possibile che VMWare contribuisca allo sviluppo di una piattaforma di un competitor Open Source, quindi col vantaggio di essere del tutto gratuita, come OpenStack ?
Per rispondere a questa domanda occorre capire gli effettivi ambiti di sovrapposizione/competizione tra VMWare e OpenStack (nel seguito faremo riferimento all’ultima release di OpenStack con nome in codice “Havana”).
Partiamo dall’architettura logica di OpenStack evidenziandone la separazione in moduli funzionali ciascuno dedicato a un servizio (la descrizione sintetica dei servizi erogati da ogni modulo, e descritti nella figura sottostante, si trova qui) e prendiamo in considerazione Nova che è il modulo dedicato alla fornitura di servizi di Computing.
Le tre componenti base di Nova sono:
- Nova API – accetta/risponde alle chiamate degli end-user fatte via API ed è responsabile delle attività di orchestrazione e settaggio delle Policy delle VMs
- Nova Compute – Crea/Termina istanze di VMs attraverso le API degli Hypervisor supportati
- Nova Scheduler – è responsabile del primo provisioning (e solo di questo) su un determinato host della farm basato su policy di “filtering” e di “peso” impostate sul Nova Controller.
Dalla figura sottostante si evidenzia come Nova Compute si pone logicamente come strato software residente “al di sopra” dell’hypervisor qualunque questo sia tra quelli supportati.
In questo senso Nova compete più con vCloud Director / vCloud Automation Center piuttosto che con vSphere che rappresenta lo “strato basso” dell’architettura di virtualizzazione.
OpenStack supporta Hypervisor differenti sulla base del vincolo architetturale che vi sia un compute node dedicato per ciascun Hypervisor.
Questi hypervisor sono supportati o tramite interfacciamento diretto col compute node di Nova o in modalità indiretta tramite libvirt .
In particolare si vede dalla figura come OpenStack Nova supporti VMWare ESXi !
Ecco trovato quindi il punto di contatto/coopetition tra VMWare e OpenStack ovvero il punto dove viene definito e confinato l’ambito di collaborazione tra le due piattaforme: l’Hypervisor.
Il supporto di Nova per ESXi è condizionato al fatto che il compute node di Nova (basato su Linux OS) risieda su un host differente dall’ host sul quale risiede l’ hypervisor ESXi (con altre tecnologie di virtualizzazione come ad es. KVM i due possono coincidere) ed è di due tipologie:
- Diretto, dove il nodo Nova Compute comunica direttamente con l’ host ESXi by-passando il vCenter
- Indiretto dove il nodo Nova Compute comunica con il vCenter che gestisce a valle i clusters ESXi (nella release Havana un solo vCenter può gestire più cluster).
La differenza tra le due modalità non è trascurabile.
Infatti nella modalità diretta, non passando per vCenter, OpenStack “perde” tutte le proprietà a valore aggiunto della piattaforma vSphere quali vMotion, HA e DRS. Inoltre ogni Nova compute node supporta un solo ESXi host.
Nella modalità indiretta si mantengono le caratteristiche di cui sopra ma poiché vCenter agisce come “punto di astrazione” rispetto a tutte le risorse da esso gestite rispetto al nodo di Nova Compute quest’ultimo vedrà solo l’aggregato delle risorse disponibili di ciascun cluster.
Senza addentrarci nei dettagli diciamo che questa circostanza pone delle sfide importanti specialmente nell'ambito della gestione delle risorse delle VMs sia nell’ambito del primo deployment che nelle successive eventuali redistribuzioni delle risorse (ad es. se devo fare il provisioning di una VM che necessita di 128GB di RAM vi è la possibilità di vedere un aggregato di RAM superiore nel Cluster ma ogni singolo nodo potrebbe avere una quantità di RAM inferiore a quella necessaria alla VM…).
Dalle limitazioni esposte si evince come il full stack VMWare rappresenti ancora oggi una soluzione decisamente più affidabile ed “Enterprise” rispetto ad OpenStack ed è questo il motivo per cui la quasi totalità dei clienti ha adottato, con soddisfazione, la soluzione di virtualizzazione di VMWare.
Un paragone sintetico e puntuale tra le due piattaforme di virtualizzazione ci viene fornito da Mirantis ed è mostrato nella figura sottostante.
Riconosciuti i limiti dell’attuale framework OpenStack rispetto a VMWare (Gartner ha avvertito i clienti circa la necessità di non farsi travolgere dall’ “hype di OpenStack” … ) la tendenza di mercato nell’ambito delle architetture Private Multi-Cloud OS / Multi-Hypervisor è quella di dedicare OpenStack agli ambienti di test e sviluppo mentre quella VMWare alla produzione.
Appurato che ad oggi, con vincoli e limitazioni, è comunque possibile implementare “lato compute” architetture Multi-Cloud OS come deve essere architettato il layer storage a supporto di queste ?
Quali sono le caratteristiche che il layer storage deve avere per integrarsi in maniera flessibile, automatica ed efficiente con le piattaforme Cloud OS di VMWare e OpenStack possibilmente fornendo a queste anche un valore aggiunto in termini di Servizi sui Dati gestiti ?
Essendo VMWare e OpenStack entrambe piattaforme di virtualizzazione software va da se che la soluzione ideale di integrazione è rappresentata da una piattaforma storage anch’essa “Software Defined” ed il cui piano di controllo si integri tramite API aperte con il piano di controllo delle piattaforme di virtualizzazione cui vengono forniti i “Servizi Dati”.
Nel caso specifico VMWare/OpenStack la piattaforma di storage software defined dovrà essere nativamente integrata con entrambe le piattaforme creando un ambiente storage che sia:
- Semplice in termini di implementazione e gestione soprattutto in considerazione delle crescite Scale-Out che tali ambienti devono garantire ad ogni layer (Compute, Storage).
- Open e Multivendor al fine di evitare ogni tipo di vendor lock-in.
- Estensibile in termini di funzionalità inerenti i “Servizi Dati” fornite ai layer di computing dei vari Cloud-OS e quindi alle applicazioni.
- Il piano di Controllo che astrae l’hardware fisico e presenta un Service Catalog di array virtuali gestiti centralmente “By Policy”
- il piano Dati che fornisce le risorse necessarie al piano di Controllo in maniera efficiente salvaguardando le caratteristiche di intelligenza degli array su cui i dati risiedono
Anche EMC, come VMWare, fa parte dei provider IT a supporto di OpenStack in qualità di “Corporate Sponsor”.
Il piano di controllo di ViPR (che determina tra gli altri le policy di provisioning e gli SLA degli storage) si integra tramite API sia con VMWare che con OpenStack.
L’integrazione del controller di ViPR con VMWare avviene in due punti della suite di virtualizzazione VMWare (vCops e vCAC) lasciando al cliente la flessibilità circa dove integrarsi mentre il livello relativo ai Data Services di ViPR si integra con lo strato basso della suite di virtualizzazione rappresentato da vSphere (VASA).
Il risultato finale di questa integrazione è rappresentato dalla visibilità end-to-end di tutta la catena compresa tra gli endpoint rappresentati dalla VM e dal suo storage andando a costituire un percorso di gestione all’interno del Data Center completamente “Software Defined”.
La demo che descrive l’integrazione tra le piattaforme ViPR e VMWare si trova al seguente link.
Come mostrato nella demo ed evidenziato nella figura sottostante, ViPR supporta il provisioning di volumi/datastore OpenStack tramite Cinder (accesso a blocchi) e Swift (accesso ad oggetti).
Infatti ViPR si comporta come “Cinder Provider” rispetto ad OpenStack fornendo la possibilità di provisionare volumi a blocchi sugli array virtualizzati sottostanti.
Tramite l’integrazione ViPR/Cinder è possibile:
- Creare/Cancellare un volume
- Creare/Cancellare una snapshot
- Creare un volume da una snapshot
- Creare un clone
- Ottenere le “statistiche” di utilizzo di un volume
- Supportare tramite un unico plugin Cinder array storage multipli
- Deploy OpenStack Cinder with EMC ViPR Part 1
- Deploy OpenStack Cinder with EMC ViPR Part 2
- Deploy OpenStack Cinder with EMC ViPR Part 3
Ad oggi sono disponibili quelli iscsi e FC per VNX e VMAX e quelli iscsi per Isilon.
Inoltre ViPR è in grado di implementare un “Data Service” a oggetti fornendo a OpenStack un volume Swift compliant.
Tramite l’integrazione ViPR/Swift è possibile:
- Fornire volumi Swift e quindi ad oggetti tramite ViPR.
- Fornire i servizi dati a valore aggiunto messi a disposizione da ViPR quale ad esempio la cosiddetta “unified semantic view” dei dati ovvero la possibilità di accedere ad uno stesso dato utilizzando modalità di accesso differenti (File / Oggetti).
Conclusione
I tre principali attributi di ViPR sono la Semplicità ed il fatto di essere una piattaforma Aperta ed Estensibile (si veda a tal proposito la figura di presentazione della piattaforma mostrata precedentemente in questo post).
Nel contesto di un ambiente Private Multi-Cloud OS / Multi-Hypervisor gli attributi di estensibilità e di piattaforma storage aperta assumono un’importanza fondamentale.
Il fatto di essere “Aperti” garantisce il cliente circa il supporto presente e futuro di un ambiente Multi-Cloud OS/Multi-Hypervisor senza incorrere in alcun pericolo di lock-in.
L’estensibilità garantisce che i livelli di integrazione e le features supportate sui differenti framework di virtualizzazione (Cloud-OS) saranno sempre maggiori con l’aumentare della maturità della piattaforma di virtualizzazione nel tempo oltre alla possibilità per il cliente stesso di estendere la piattaforma creando i propri “Servizi Dati” utilizzando le API messe a disposizione.
EMC ViPR rappresenta la migliore scelta possibile per quei clienti che vogliano iniziare ad abbracciare la tematica del Software Defined Storage inserita nel contesto di un Software Defined Data Center Multi-Cloud OS / Multi-Hypervisor in quanto rappresenta il punto finale di integrazione ed aggregazione di IaaS gestite da Cloud-OS differenti consentendo l’eliminazione di qualsiasi silos infrastrutturale e, di conseguenza, applicativo.
Massimo Biondi (Twitter: @maxbio70 )
Ottimo articolo, mi ha chiarito alcuni punti che mi interessano direttamente. Grazie mille!
RispondiElimina