Lo storage di prossima generazione – parte 7

Questo articolo fa parte di una serie (qui il primo della serie e qui uno sullo storage tradizionale) che ha l’obiettivo di informare il lettore su come sta evolvendo lo storage enterprise e cosa si deve aspettare per la sua futura infrastruttura. Questa è l’ultima parte e presto sarà possibile scaricare un PDF con l’intera serie più qualche contenuto extra.

Converged e unified

Negli ultimi anni si è sentito spesso utilizzare i termini converged e unified, in alcuni casi vengono anche scambiati fra di loro erroneamente. E‘ sempre più chiaro comunque che, anche in ottica di semplificazione, il mercato sta sempre di più puntando su una convergenza dei mezzi fisici su cui i dati viaggiano. Ethernet sta conquistando sempre più quote di mercato relegando FC in una nicchia sempre più piccola. I motivi sono semplici e, oltre alla semplificazione, c’è una questione di economicità e di semplicità nella realizzazione di soluzioni (topologie di rete) complesse. FC è comunque un protocollo che rimarrà per tantissimi anni ma che avrà uno sviluppo sempre più lento e sarà sempre più relegato ad ambienti enterprise (solitamente più lenti a reagire a cambiamenti di questo tipo).
Al contrario, dal lato dei protocolli di comunicazione, la convergenza su ethernet risolve un problema pratico (quello di dover gestire diverse tipologie di porte per il collegamento) e quindi è relativamente più facile creare storage multi protocollo. Infatti, quasi tutti i produttori stanno proponendo sempre di più sistemi di storage che possono offrire più protocolli sullo stesso media, in alcuni casi sia protocolli a blocchi (FCoE, iSCSI) che a file (NFS, CIFS). Non tutto è converged e unified ovviamente e non tutto su ethernet, ad esempio, è abbastanza evidente che alcuni storage di fascia alta si stanno indirizzando verso infiniband per questioni di prestazioni.

Integrazione

L’integrazione con tutto il mondo sovrastante (hypervisor, sistemi operativi e applicazioni) permette di fare un salto di qualità notevole e di passare oltre alla gestione dello storage iniziando attivamente a operare con i dati che ci sono contenuti dentro! Se l’applicativo sa esattamente con che storage sta parlando (e viceversa) è possibile attivare dei meccanismi per cui è possibile clonare, in maniera consistente, DB di grandi dimensioni in pochi click (e minuti) o, con lo stesso principio, creare copie di ambienti ERP in produzione da dare ai team di sviluppo! Questo tipo di integrazioni hanno il grosso vantaggio di accelerare i tempi di risposta dell’IT semplificando l’operato d i tutti gli altri team dell’azienda con risultati importanti in termini di efficienza e produttività. I produttori stanno tutti lavorando con i software vendor per creare le migliori integrazioni, ovviamente la parte di integrazione sta diventando uno dei fattori decisivi più importanti nella scelta di uno storage. Più il sistema di storage è integrato con gli strati superiori più sarà semplice amministrarlo e gestirlo, in alcuni casi diventa quasi trasparente dando anche a sistemisti non esperti una infrastruttura molto più facile da gestire.

Federazione

L’obiettivo della “Federazione dello storage” è quello di poter accorpare in un pool unico diversi sistemi esterni di storage (array diversi) e di usarli come una sola entità. In pratica i diversi array possono agire all’unisono per ottenere più scalabilità (orizzontale) e una distribuzione del carico di lavoro ottimale.
Se dovessi fare un parallelo con quello che normalmente vediamo nel mondo della virtualizzazione, potrei indicare un cluster di server con Vmware come il pool risorse che menzionavo sopra e meccanismi come vMotion e DRS come gli strumenti per attuare l’operatività e l’automatismo necessario.
Non esiste uno standard ma ogni produttore sta operando nel modo che gli conviene di più. Al momento esistono due scuole di pensiero: l’appliance e la funzionalità software. Nel caso di Appliance si tratta di un vero e proprio virtualizzatore che si inserisce fra gli host e lo storage. L’appliance permette quindi di aggiungere questa, e altre, funzionalità a sistemi di storage eterogenei ma, purtroppo, proprio per la diversità dei sottosistemi gestiti si perdono molte delle funzionalità avanzate che questi oggetti forniscono abitualmente (es. snapshot). Nel caso opposto, quello della funzionalità software, si parla di una caratteristica del sistema di storage e l’unico limite è dato dal fatto che non si possono federare sistemi di storage di produttori diversi (che, comunque, ammetto essere un  potenziale grande limite in utenti finali di grandi dimensioni con diversi fornitori di storage). I vantaggi di questo approccio sono molteplici e vanno dall’economicità alla semplicità d’uso, passando per il fatto che, se ben implementato, non vengono introdotte limitazioni rispetto ad altre funzionalità software. In ogni caso, lo scopo finale è quello di virtualizzare l’accesso a LUN/Volumi di dati per poter fare una serie di operazioni che risultino trasparenti agli host sovrastanti: sempre per tornare all’esempio di VMware, una LUN è equiparabile ad una VM che si sposta, seguendo determinate regole, da un host fisico all’altro in funzione delle necessità o perché viene richiesto dall’amministratore. Gli esempi pratici più semplici ed eloquenti possono essere riassunti in bilanciamento di carico automatico/manuale, migrazioni di dati, upgrade di sistemi più sicuri e indolori sia in termini hardware che software, tiering fra diversi sistemi. Se ho due o più sistemi di storage federabili tra loro possono posso pensare di ottenere un uptime dell’intera infrastruttura sensibilmente più alto rispetto al singolo sistema, minimizzare i costi delle migrazioni e razionalizzare l’uso delle risorse disponibili per farle rendere al massimo. La federazione dello storage quindi dovrebbe avere alcune caratteristiche imprescindibili quali: trasparenza, semplicità d’uso, un sistema di management efficace e meccanismi di automazione efficaci.