This post is also available in: Inglese

Lo storage è sicuramente una delle parti più importanti di una infrastruttura virtuale, ma rispetto alla parte relativa ai server (gli host di virtualizzazione che forniscono la capacità “computazionale”) le differenze tra i diversi vendor sono numerose e non sempre è facile confrontare i diversi prodotti; se non altro perché non sono sempre omogenei o perché alcuni aspetti non sono semplici da confrontare e/o comprendere. Ovviamente le motivazioni sono diverse e in parte legato al diverso posizionamento dei prodotti, ma la differenza a volte è sostanziale e spesso su alcuni aspetti poco noti o “nascosti”. Premetto che non è mia intenzione fare una dissertazione sugli storage (ve ne sono già numerose e spesso ben fatte, ad esempio c’è questa serie di articoli sugli storage di prossima generazione).

Quello che tutti sicuramente sono in grado discriminare è la differenza tra storage locale (DAS) e quello condiviso (SAN o NAS, ma in alcuni casi anche varianti del DAS), ma soprattutto il perché lo storage condiviso è così importante: non è per una questione di prestazioni, ma prevalementemente perché è un requisito infrastrutturale! In un’infrastrutturare per la virtualizzazione sistema (e non importa che sia VMware vSphere, Microsoft Hyper-V, Citrix XenServer o KVM o altro) lo storage condiviso è richiesto per implementare una serie di funzionalità base (come l’HA o la migrazione a caldo delle VM). In verità questo requisito (tipico anche di molte altre architetture a cluster potrebbe cambiare in futuro a favore di architetture “shared-nothing” (ad esempio usando Marathon everRun VM e replicando tra due nodi sia lo stato della VM che quello dello storage), ma al momento rimane un requisito fondamentale; ma anche un possibile punto di forza, visto che può fornire diversi vantaggi.

Benché in ambienti di virtualizzazione di sistema, lo storage condiviso è prevalente, in casi specifici è possibile usare anche lo storage locale, ad esempio in ambienti VDI (come già descritto in un post precedente). Ma vi sono anche altri casi, dove ad esempio la ridondanza, la replica, la gestione di failover e failback, … sono gestiti ad un livello applicativo (pensiamo, ad esempio, ad un’architettura basata su Exchange DAG).

Un’altra differenza è nei differenti protocolli e/o interfacce supportate nella parte di front-end (la parte verso gli host):

• SAN utilizza iSCSI o FC (FC, FCoE, …) con interfacce Ethernet o FC (e media in rame o fibra)
• NAS utilizza NFS o CIFS/SMB

Benché vi siano delle differenze rilevanti tra l’accesso in modalità blocchi offerto dalle SAN rispetto a quello in modalità file fornito dai NAS (sarà un argomento di un prossimo post), in realtà la differenza tra i diversi procolli non è poi così rilevante (soprattutto se operiamo dei confronti omogenei di velocità, come ad esempio iSCSI 10Gbps vs FC 8Gbps) e in molti casi sono più dei miti o dei retaggi storici (che con il tempo si sono evoluti e modificati).

Il numero delle porte di front-end può essere ben più rilevante, ma va comunque rapportato al diversi aspetti, inclusi la modalità di funzionamento dei controller dello storage (active/active, active/passive, active/standy) ed il tipo di multi-path che può essere utilizzato.

Dal lato del back-end (verso i dischi) il numero di dischi, il loro tipo, il tipo di RAID, il tipo e la modalità della cache, possono risultare importanti per definire le prestazioni dello storage… Ma bisogna nuovamente considerare tutti gli altri aspetti, inclusa la possibilità che il front-end diventi il vero collo di bottiglia (specie con dischi molto veloci o con cache particolarmente grosse). Il come lo storage risponde ai requisiti di scalabilità può rispondere a questo possibile problema, ma solo in un tipo di scalabilità.

Gli storage condivisi possono “scalare” in due modalità differenti (in modo molto simile a come può scalare un cluster di virtualizzazione per le risorse computazioni):

• Scale-in (vertical scaling): lo storage viene espanso aggiungendo nuovi “box” di dischi, ma la parte di front-end rimane invariata e quindi non può scalare.
• Scale-out (horizontal scaling): lo storage viene espando con nuovi storage, lavorando in un’unico “cluster” (o gruppo di storage). In questo modo anche la parte di front-end continua ad incrementare.

Per maggiori informazioni (in inglese), rimando a questo post: Scale-out vs. scale-up: the basics. Naturalmente non tutte le architetture di tipo scale-out sono equivalenti: tipicamente la scalabilità rimane simile e comparabile, ma altre funzioni, come ad esempio l’alta disponibilità, possono essere molto diverse (in un successivo post saranno forniti maggiori approfondimenti su questi aspetti).

Un approccio alternativo al possibile problema del collo di bottiglia della parte di front-end è quello di lavorare per ridurre il “gap” tra gli host di virtualizzazione e lo storage accorciandone la distanza in due possibili diversi modi:

• Portando parte dello storage all’interno di ogni host e quindi vicino alle VM: ad esempio parte della sua cache.
• Portando le VM direttamente sullo storage array: quindi usare la potenza di calcolo dello storage processor per eseguire le VM.

Queste soluzioni sono decisamente interessanti, soprattutto per gli aspetti di scalabilità e massimizzazione delle prestazioni. Diviene interessate notare come il modello di local storage e shared-nothing possono andare esattamente verso il secondo approccio, dove di fatto la potenza di calcolo e la capacità di storage diventano un singolo “blocco”. Tra l’altro alcune VSA (Virtual Storage Appliance) già vanno proprio in questa direzione.

Per concludere ho solo descritto alcuni aspetti, ma in generele ve ne sono molti altri, come ad esempio il tipo filesystem usato nello storage (vedere a tale proposito il post relativo a ZFS), il supporto al multi-tiering dei dischi, le funzionalità relative alla data protection, i costi, il livello di maturità ed adozione, le matrici di compatibilità, se è di tipo “open” o no (aspetto interessante sullo storage, visto che è nella maggioranza dei casi implementato a livello software e quindi potrebbe diventare svincolato dall’hardware), …

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.