Gestire architetture multivendor garantendo la compatibilità di tutte le componenti, mantendo elevate le performance di queste, senza creare colli di bottiglia o single point of failure. La risposta a questo problema si chiama virtualizzazione. Il concetto è noto e si tratta, in sostanza, di rimappare dischi di tipo e di vendor diversi in un unico disco virtuale disponibile per le varie applicazioni. Il software di virtualizzazione può risiedere sui server (quando è un solo host o un gruppo di host ad accedere a più sistemi di memorizzazione); sull’array (quando più host si collegano a un singolo array); su un dispositivo mirato che gestisce il traffico dei dati. Nei primi due casi il rischio è di un “appesantimento” dei server e degli array, che si fanno “carico” dell’elaborazione dei processi di virtualizzazione, con conseguente “caduta” delle performance; nel secondo è la latenza di trasmissione perché obbliga i diversi server che necessitano di storage a far confluire le richieste sull’unità di virtualizzazione.
La tendenza che oggi sta emergendo è dunque quella di spostare queste funzionalità su quegli apparati che sono tipicamente destinati allo smistamento del traffico di rete, per questo si parla di trasferimento di “intelligenza” sugli apparati di rete, ossia switch e director. Ecco quindi che i principali vendor di storage networking hanno rilasciato, o stanno rilasciando, prodotti che implementano queste funzionalità.
“Sicuramente questo è un tema molto discusso. Il director è un apparato che per definizione deve essere trasparente; dato che sta in mezzo tra server e storage è quindi naturale la sua evoluzione verso l’integrazione di funzionalità finora svolte da server o sistemi storage, ma che attengono lo smistamento dei dati in un’ottica multivendor. Devo però trattarsi di una soluzione sicura, che non tenga strane repliche di dati (non deve memorizzare i dati, li deve smistare) e che si basi su un hardware adatto. McData ha quindi sviluppato un apparato, in collaborazione con una terza parte, che è in grado di trasferire intelligenza sulla rete, salvaguardando l’integrità dei dati e mantenendo le performance dei sistemi”, spiega Alberto Crivelli, technical account manager di McData. Il nuovo apparato è attualmente in fase di test e sarà disponibile sul mercato sicuramente entro la fine del 2005; per il momento si tratta di un modulo esterno perché “si tratta di una tecnologia nuova – precisa Crivelli – e non è possibile pensare di implementarla con moduli interni in director che magari hanno 2 o 3 anni; in questo modo, invece, nostri clienti possono aggiungere queste funzionalità ai director McData già in loro possesso; in futuro si penserà anche a dei moduli interni”.
È invece già sul mercato la UltraNet Replication Appliance di Cnt (la cui acquisizione da parte di McData è ormai cosa fatta). Si tratta di un apparato in grado di erogare servizi di storage e di replica dati su grandi distanze che integra la tecnologia e l’esperienza Cnt sull’estensione delle San su siti remoti. “Attualmente – dice Fulvia Nannini, Italy sales channel manager di Cnt – abbiamo a listino questa appliance inband, ma entro la fine dell’anno verrà rilasciata una scheda che consente di trasferire funzionalità ‘intelligenti’ sul director di quarta generazione, l’UltraNet Multiservice director, rilasciato lo scorso agosto”. Il nuovo director di Cnt prevede infatti l’integrazione di funzionalità di sicurezza, estensioni a Wan e Man, virtualizzazione, replica, gestione generale (diagnositica avanzata, nuove funzionalità di reporting) e la libertà di suddividere la banda passante come si preferisce.
Anche Brocade ha già rilasciato un’appliance esterna per la virtualizzazione della San: si tratta del Silkworm Multiprotocol Router che offre servizi di routing, consente di connettere le risorse e di condividere i dati tra San separate, localmente o a distanza. “La nostra intenzione è quella di sviluppare servizi su questa piattaforma separando le funzionalità di virtualizzazione da quelle di connettività. Il Multiprotocol Router 7420 consente la condivisione dei server e degli apparati di storage tra San,” dice Fabio Andreini, responsabile prevendita di Brocade. Entro la fine dell’anno, inoltre, l’azienda rilascerà una scheda, per i propri director, che implementa queste funzionalità.
Infine Cisco, che pur essendo l’“ultima arrivata” nel campo dello storage networking ha rapidamente bruciato le tappe: “È vero – dice Luciano Pomelli, Consulting Systems Engineer Storage Networking di Cisco Systems Italy – abbiamo infatti rilasciato una linea di prodotti di nuova generazione che già dal dicembre del 2003 dispone di schede ‘intelligenti’ ed è in grado di ospitare e processare applicazioni storage realizzate in partnership con Ibm e Veritas. Continueremo a promuovere partnership tecnologiche, realizzando hardware intelligente integrato negli switch/director San e Api per scrivere applicazioni secondo due modelli architetturali distinti: Network Hosted Application, in questo caso l’applicazione del partner risiede e ‘gira’ sul San switch/director; Network Assisted Application, dove l’applicazione risiede e ‘gira’ su un’appliance dedicata e interagisce con gli switch/director della San attraverso un protocollo intelligente che ne facilita l’integrazione in un contesto applicativo”. Ed è proprio di questi giorni l’annuncio del Cisco Mds 9000 Storage Services Module, che incorpora tutta la tecnologia necessaria per far girare le Intelligent Fabric Application. n
Storage su protocollo internet
L’esigenza di connettere risorse di storage con i server o isole San tra di loro a costi più contenuti di quanto non consenta l’utilizzo di Fibre Channel (protocollo di comunicazione “principe” per lo storage) e utilizzando l’infrastruttura di rete Ethernet, ha portato alla definizione di tre protocolli che permettono la trasmissione dei dati storage tramite Ip: Fcip, iFcp e iScsi. Mentre su iScsi, per la comunicazione tra device, il consenso è unanime, sugli altri due, che consentono l’interconnessione di San su Ip, si è sviluppata una lunga contesa. Senza entrare nei dettagli tecnici si può semplicemente dire che iFcp connette le due San mantenendole separate (e questo, secondo McData che di fatto è l’unico vendor ad avere realizzato soluzioni basate su questo protocollo, è uno degli elementi che ne fanno un protocollo intrinsecamente sicuro), mentre Fcip “estende” la San del primo sito verso quella del sito remoto. La questione non è tecnologica (tutti gli operatori concordano sul fatto che entrambi i protocolli sono validi), ma di semplicità di implementazione e ormai si è definitivamente affermato Fcip (non è un caso che McData abbia acquisito Cnt, azienda con consolidata esperienza nelle tecnologie di estensione delle San). In ogni caso, la scelta di far viaggiare i dati storage su Ip ha una validità solo per quelle aziende che non utilizzano questa modalità per fare disaster recovery dato che il livello di servizio del protocollo Internet non è certo paragonabile a quello garantito dal Fibre Channel che consente, appunto, una replica sincrona dei dati mentre Ip presenta sempre problemi di latenza. Tutte le aziende di storage networking forniscono quindi soluzioni che consentono la trasmissione dei dati storage over Ip, ma la scelta dell’utilizzo dello storage over Ip dipende sempre dalla tipologia di azienda che ne deve fare uso e dal livello di servizio che intende garantire. (P.F.)
