L’invito a rivedere la dicotomia San-Nas con un’ottica più serena e improntata alla coesistenza delle architetture è venuto inizialmente da Emc. Diamo la parola ai protagonisti italiani per scoprire che la visione è condivisa da tutti e che l’integrazione avviene nel nome della Rete.
Anche lo storage ha vissuto, come ogni altro segmento dell’It, la propria battaglia di religione. Del resto, quando si parla di affermazione di standard (e nell’It lo si fa quotidianamente) è normale che si creino due (o più) blocchi che si contrappongono per affermare le proprie ragioni di scelta tecnologica. Per fortuna, nel comparto dello storage la diatriba non è durata molto. Anzi, è finita ancora prima di cominciare seriamente. Prima ancora, cioè, che per massa critica lo storage arrivasse a pesare quello che analisti e vendor gli avevano prospettato. Stiamo parlando della dicotomia fra San e Nas e del valore che le attività di gestione della memorizzazione stanno assumendo per le aziende. Che lo storage sia uno dei capitoli di spesa che maggiormente incideranno nei budget It dei prossimi anni è ormai chiaro a tutti. E prima che si entrasse nel vivo, quindi, i produttori hanno pensato bene di cancellare le contrapposizioni ideologiche sui due modelli (San e Nas) con i quali tutto il comparto si appresta a trasformare le strutture di storage Das. Praticamente per tutti i vendor (e noi lo abbiamo verificato sul campo) sono concordi nel superare la dicotomia San-Nas e nell’inquadrare il problema dello storage aziendale nell’ottica del problem-solving. E quando si deve trovare una soluzione le "guerre di religione" servono a poco. Serve di più, invece, un approccio pragmatico.
Secondo Emc, per esempio, società che da sempre rappresenta lo stato dell’arte dello storage, è sbagliato il tentativo di condizionare il mercato verso i Nas o le San. Le aziende devono utilizzare la soluzione che ritengono essere più opportuna, nel rispetto del lavoro multipiattaforma e multitecnologia. Oggi siamo in una dimensione di mercato in cui la capacità non determina l’importanza di una soluzione. Chi propugna solo Nas, per esempio farebbe dell’auto-downsizing. Bisogna, invece, creare un ambiente di storage che sia, per sua natura, il pù possibile svincolato da quello di comunicazione e da quello di elaborazione. A questo motivo funzionale se ne aggiunge uno speculare: all’aumentare della quantità di informazioni, aumentano i volumi dei dati da spostare (il che complica le cose in ambito di backup).
Dal punto di vista del target applicativo le San sono l’evoluzione del Das, che è stato il pezzo forte dei mainframe, caratterizzati da canali ad alta velocità e sofisticate unità di controllo. Nel mondo delle applicazioni client-server le San unificano lo strato storage attraverso canali a larga banda, con la tencologia in fibra, e utilizzano switch specializzati per ottimizzare il grande flusso di traffico interconnettendosi con lo strato dei server. Il passaggio da connessioni Scsi a Fc corrisponde all’evoluzione da una connessione uno-a-uno a una molti-a-molti. I vantaggi delle San sono dati dal disaccoppiamento tra server e storage, che permette di accrescere in modo flessibile gli uni e gli altri senza vincoli di reciprocità. Un unico ambiente di gestione governa tutto lo storage e l’intero sistema consente di trasferire grandi quantità di dati.
Il Nas, per Emc, nasce dal basso, come evoluzione del concetto di file server, essendo un server specializzato nella gestione dello storage di documenti. Sono sistemi dedicati a singole applicazioni e condivisi fra più utenti che partecipano allo stesso tipo di processi aziendali (l’anima workgroup, quindi, è forte).
Il punto di forza dell’approccio Nas è dato dalla flessibilità. Dove le San sono orientate a una connessione (e quindi alla gestione dell’I/O) basata sul concetto di blocco, il Nas utilizza l’approccio dell’Ip e dialoga con gli host. Nel file server sono contenuti i protocolli e il file system e questo approccio permette a una pluralità di utenti e di host di attivare richieste simultanee per l’accesso ai file. Sotto questo profilo il Nas risulta indicato per applicazioni in cui lo stesso file deve essere condiviso fra più utenti.
Se una San, quindi, è indicata per applicazioni che richiedono tempi di risposta ridotti, come nel caso delle applicazioni transazionali o per le interrogazioni dei database, un Nas è indicato per applicazioni multimediali, publishing, gestione documenti d’ufficio, consultazione di pagine Web, posta elettronica, sviluppo software. Dato che, allora, l’infrastruttura informativa è unica, la flessibilità multiaccesso dei Nas e le prestazioni veloci della San non sono più dicotomiche. Ciò vale di più se si individua lo storage come una dimensione di interesse generalizzato. E giusto per essere coerenti, oggi le piaffatorme di storage di Emc, come le Emc Celerra o Symmetrix, possono essere orientate all’una o all’altra soluzione.
Hewlett-Packard, dal canto proprio, posiziona lo storage nell’infrastruttura Internet. Lo scopo più evidente, quindi è quello di evitare downtime non programmati. Per Hp una volta lo storage era un "di cui" del server. Oggi la potenza del server può anche diventare una commodity, mentre conta l’investimento sul trattamento del dato. In tal modo, secondo quanto illustrato da Susanna Fallupo, Hp sales storage manager, quando il dato non deve essere sempre "always on", si può optare per un Nas. Quando, invece, deve essere sempre "always on" la soluzione univoca è la San.
Per Terasystem, un system integrator che distribuisce le soluzioni di mass storage di Hp, ma che sviluppa e produce, anche, soluzioni proprie (come le librerie a nastro Datastore, il server magneto ottico per reti eterogenee, Optiserver, il sottosistema disco Openraid), il mercato fino a ora ha visto una rete processore o server centrica, con tape library attaccate al server Lan. I limiti di questa struttura, secondo il direttore commerciale di Terasystem, Maurizio Disperati, sono dati dal fatto che nel processo di storage e backup sono coinvolti più server e più interfacce: la transazione tipica è quella che va dal sottosistema Raid al server al tape.
L’architettura San, invece, fa cambiare il concetto di "storage captive", quello, cioè, "embedded" o strettamente collegato con il server. Il modello storage centrico, che è un tipo di San, vede a monte una Lan, con più server collegati, che passano da uno switch in Fc che distribuisce dati a disk array o a tape library. I vantaggi di questa struttura sono dati dall’incremento della banda passante, dallo sfruttamento delle lunghe distanze, da scalabilità, crescita, disponibilità, fault-tolerance, manageability e distaster recovery dei dati, e anche dalla storage consolidation.
La versione storage Nas-centrica, invece, vede sempre a monte una Lan, che tramite protocolli come Nfs, Http, Ipx, dialoga con un Nas (ora Scsi over Ip) che può attingere e dare dati a server Unix e Windows 2000. Il Nas, quindi, differisce dalle San o dal Das per il fatto che è basato su un sistema operativo leggero, veloce (microkernel) pensato per la gestione del protocollo di rete. E il vantaggio dei Nas, per il system integrator italiano, è dato dal fatto che accedono a client e server alla stessa maniera e che condividono i dati fra sistemi operativi diversi. Nella San, invece, si condividono i dati fra storage diversi.
Lo Scsi over Ip
In questo senso, per Terasystem, lo Scsi over Ip presuppone l’esistenza di uno iScsi server che accede a tape e disk array, da un lato, e alla Lan (quindi, sia client, sia server) dall’altro e, come nella San, condivide lo storage fra piattaforme diverse e non direttamente i dati. Ecco perché, secondo Disperati, le attività di storage management devono tener conto, a livello di policy, della regola base dell’archiviazione dati: quelli più consultati sono solo il 20% dei dati aziendali e l’80% potrebbe essere portato su supporti secondari o meno costosi.
Anche Ibm ha superato la dicotomia San-Nas. Ne è una dimostrazione il rilascio, nello scorso febbraio, di un dispositivo, il Nas gateway, che fa vedere agli utenti Ip i servizi che risiedono su San. In tal modo, con iScsi, si superano i limiti di una rete Ip in relazione ai servizi di storage. È così che in Ibm i termini San e Nas sono ormai superati. Ora si parla di storage networking, come conferma il marketing manager dell’area network storage, Sergio Resch.
Un Nas gateway, poi, valorizza i sistemi disk array di taglio enterprise, come lo Shark, perché li mette a disposizione di utenti Web, via Gigabit Ethernet. Peraltro, a livello di scelta d’orientamento la differenza fra San e Nas può ancora esistere. Dipende tutto dall’azienda: se ha già una San in Fc la può far crescere espandendo le possibilità dello storage al protocollo Ip con lo Scsi over Ip.
Il Nas, per Ibm, va bene per le attività di collaboration (e iScsi nasce proprio per far lavorare un database su Ip): in tal modo diventa una valida alternativa anche per le Pmi. Se, invece, si ha un database mission critical, è meglio una San.
Da Ibm, poi, arriva anche un monito a non trascurare il problema del layout dello storage. In sé e per sé il consolidamento dello storage è un atto semplice: ne va smitizzata la complessità. Nel caso l’azienda stia ripensando l’infrastruttura tecnologica, allora si crea un progetto di storage e si possono pensare soluzioni di sdoppiamento della base fisica su cui si conservano i dati.
A ciò va aggiunto che i costi di tutte queste strutture sono comunemente al ribasso. Anche i costi di connessione sono scesi. L’unica barriera esistente sono gli skill tecnici.
Storage skill shortage
Anche per Giuliano Bettineschi, amministratore di Hitachi Data Systems, società che in sei mesi ha installato in Italia una ventina di sistemi 9900, per più di 100 Tb complessivi, è finita la dicotomia fra San e Nas. E anche per lui persistono, invece, le differenze in materia di skill, che sono più difficili da recuperare quando c’è da implementare una San.
Pure per Hds, quindi, la San, è ideale per le operazioni mission critical (tipicamente su database) il Nas va bene per operazioni di consolidamento. Ma non va dimenticato il remote copy. Hds, per esempio, ha una soluzione, chiamata Nano copy, per la gestione geografica del backup (copie pont in time su distanze geografiche, ideali per banche e commercio elettronico).
E in merito all’iScsi, in casa Hds c’è attendismo. Il concetto, secondo Bettineschi, potrebbe funzionare, ma c’è la complicanza della pesantezza del protocollo Scsi. Piuttosto, sarebbe meglio muoversi in direzione della virtualizzazione del dato (con una visione molto simile a quella di StorageTek). L’elemento critico da rispettare pienamente, comunque, in una struttura condivisa in rete è l’assoluta intolleranza all’errore.
E a proposito di reti, l’emblema dello storage che si fonde con la rete è dato dal forte interesse che ha maturato Cisco nei confronti di queste strutture.
Le idee del big delle reti
Per Giuseppe Zanolini, manager system engineering di Cisco, i mondi dello storage e del networking non hanno mai avuto sinergie. Ma ora qualcosa si sta muovendo sul piano dell’integrazione. E Cisco è in questo mercato perché il Tco aumenta, in virtù del volume dei dati circolante su Web. Anche se il costo per Gb scende, aumenta la mole di dati, per cui il Tco cresce. Per abbattere i costi, quindi, si punta sull’adozione degli standard e di soluzioni aperte (come Ip, Gigabit Ethernet, Fc, Optical).
Le problematiche vive, per Cisco, sono la storage consolidation, la business continuance (disaster recovery) e lo storage outsourcing. Le soluzioni tecnologiche che abilitano questi indirizzi sono il metro optical (con storage over Mp, Dense Wave Division Multiplexing), lo Storage over Wan (con Fc encapsulation, Fc over Ip), l’Ip Access to storage (iScsi, Gigabit Ethernet, 10Ge, iScsi to Fc), il Nas (file oriented Ip Access, Gigabit Ethernet, 10 Ge). Il conforto a queste soluzioni viene dagli standard Ieft (Internet Engineering Task Force) elaborati e approvati dallo Ip Storage working group e dalla Snia (Storage Networking Industry Association), tramite lo Snia Ip storage forum, nella fattispecie, iScsi e Fc over Ip.
Cisco inserisce lo storage, networking nel framework Avvid, per l’integrazione della voce, video e dati su Internet. La visione di iScsi si concretizza con il router Sn5420, che via Ge va su rete Ip per connettersi ai dispositivi remoti di storage e che, internamente, colloquia con un sistema storage FIbre Channel o Scsi. Il tutto è un’emulazione di un bus Scsi. Ma il router iScsi può anche accedere, via switch a una San. In questo modo, viene garantito l’accesso sia in modalità blocco alla San, sia in modalità filer ai Nas. Il concetto di Fc over Ip, ancora in via di concretizzazione, sfrutta un protocollo sviluppato da Brocade per far parlare due dischi remoti su rete geografica Ip.
