Gli Storage sono delle cose belle e interessanti: personalmente sono sempre stato affascinato dagli hard disk e, in generale da tutti quei sistemi atti a conservare le informazioni.

Per uno che ha la fissa delle memorie di massa e dei file system lavorare con gli storage è come passare dalla giostra di paese a Gardaland. Tutto è grande, enfatizzato, complicato e tanto costoso. E tanto tanto nerd.

Allora iniziamo a parlare del perché gli storage sono necessari. I motivi sono svariati:

  • Crescita: un server può arrivare anche a 24 dischi ma oltre è necessario pensare ad altro. Non è pensabile di aggiungere poi un intero server ogni 24 dischi. E’ uno spreco di denaro, risorse, corrente elettrica e aria condizionata. Uno storage può scalare fino a decine, centinaia o migliaia di dischi, può servire centinaia di server e consuma una frazione di corrente rispetto a un cluster di server. Inoltre non richiede software specializzato per riuscire ad aggregare le memorie sparse su vari apparati. La crescita può avvenire verticalmente (aggiungendo dischi e shelf ad un singolo storage) o orizzontalmente (aggiungendo più storage ad una singola SAN)
  • Alta affidabilità: Uno storage, al contrario di un server, è costruito per non avere alcun single point of failure. Vi sono porte multiple di collegamento con la SAN, controller ridondati (attenzione quando si parla di controller non si intende le classiche schede da PC, quanto piuttosto di veri e propri computer embedded dedicati alla gestione dei dischi e dell’I/O su SAN), i collegamenti con gli shelf di espansione sono realizzati con fibre  o cavi multipli e infine i dischi possono essere configurati con livelli di RAID diversi in modo da privilegiare velocità e/o sicurezza.
  • Replicazione: due o più storage possono essere posti in replica così che ogni singola operazione possa essere eseguita in parallelo su più sistemi. Questo permette di avere, per esempio, due interi datacenter in replica tra loro sia per bilanciare il carico sia per avere un site di disaster recovery.
  • Alta disponibilità: se due o più server devono essere configurati in cluster avranno anche la necessità di attingere ad una risorsa comune i dati condivisi. Il problema potrebbe essere risolto con un file server di back end, ma poi ci si scontra con il problema della crescita e dell’alta disponibilità appena menzionati. Uno storage permette quindi di esportare una o più LUN verso diversi server. Tale LUN farà da back-end per l’intero pool di server.
Nel mondo degli storage ogni standard fa storia a se.

Al contrario di quanto avviene nel resto del mondo dell’informatica, dove gli standard permettono una interoperabilità quasi totale, nel mondo degli storage (se pur con qualche caso che fa eccezione) ognuno fa storia a se. E questo è un problema non da poco.

Cosa vuol dire questo? In pratica ogni linea di storage usa propria componentistica, propri sistemi operativi,  proprio sistema di gestione e proprie tecnologie. Tale frammentazione è così pervasiva che a spesso all’interno di una stesso vendor diverse linee di storage non sono interoperabili tra loro.

Ad esempio HP propone le linee MSA, EVA (a fine vita), StoreVirtual e 3PAR. Tutte diverse. Quando si arriva alla massima espansione di una linea e si deve passare alle successive occorre ricomprare (e reimparare) tutto da zero.

Stesso discorso vale per EMC2, dove VNXe, VNX, VMAX, Isilon e Atmos sono egualmente incompatibili tra loro.

Un’eccezione è Fujitsu. La società dispone di una serie di prodotti di fascia SMB, Media e Enterprise che però utilizzano la stessa componentistica, lo stesso sistema operativo e la stessa management console. Si può quindi scalare dal prodotto più economico, Eternus DX100, di fascia SMB a quello di classe enterprise, il DX 8700 S2, semplicemente aggiungendo componenti e sostituendo le controller quando queste arrivano al loro limite massimo. Non servono riconfigurazioni.

Anche per NetApp le linee FAS e E sono entrambe scalabili dai modelli base a quelli di fascia enterprise.

Anche se vi sono dei punti di contatto tra tutti i vari storage, inteso come tecnologie comuni che sono date per assodate, c’è da tenere in considerazione il fatto che le stesse possono essere implementate in maniera totalmente diversa tra un vendor e l’altro.

 

 

Famiglie di storage

Gli storage di rete si distinguono in tre grandi famiglie.

 

NAS

In primis vi sono i Network Attached Storage (NAS). In pratica sono dei file server alla massima potenza. Permettono di avere tutte le caratteristiche di espansione e affidabilità degli storage pur essendo a tutti gli effetti dei file server, e come tali sono visti dai client.

Il 99% dei NAS lavora con i due protocolli standard di mercato ovvero, CIFS per il mondo Microsoft e NFS per il mondo Linux.

Molti possono fare anche da authentication server permettendo loro di gestire un dominio Microsoft o un albero LDAP oppure possono integrarsi in un sistema Active Directory oppure, nel mondo Linux, usare dei server LDAP e/o kerberos esterni.

L’unità su cui lavora il NAS è quindi il file. Lo storage ragiona in termini di file, che viene esportato verso verso i server attraverso una share. Tutte le operazioni relative a snapshot e backup sono quindi orientate ai file.

Il vantaggi dei NAS sono molteplici:

  • Semplicità: è un file server. Quando ha una connessione alla LAN è contento. Non c’è da impazzire con la gestione delle LUN, non ci sono protocolli subdoli come iSCSI e Fibre Channel, basta qualche indirizzo IP, si integra con la propria parte di authentication (o se ne crea una nuova tramite le funzioni del NAS), si definiscono le share e via.
  • Niente cluster file system con cui impazzire: Se si vogliono condividere dei dati tra più macchine non serve essere dei sistemisti esperti. Si definisce una Share ed è fatta. Tutta la parte di concorrenza e locking è gestita nativamente dal protocollo di rete.
  • Coesistenza: Se si dispongono di macchine Windows e *BSD/Linux/Unix non serve impazzire con NFS per Windows o Samba per Unix. La stessa share può essere esportata con entrambi i protocolli così da garantire l’interoperabilità.
  • Funzioni accessorie: tutti i NAS sono, come già detto, dei file server. Questo significa che dispngono di un proprio sistema operativo (solitamente di derivazione *BSD o Linux). Molti vendor permettono di installare direttamente sul NAS una marea di applicativi, dai server Web a vari RDBMS Open Source, GIT ed altri magari più consumer come DLNA server.

 

Ovviamente non sono tutte rose e vi sono degli svantaggi:

  • Velocità: Nonostante l’efficienza di NFS, in particolare, un NAS sarà comunque più lento di un block storage e permetterà un numero di operazioni per secondo inferiore, il tutto dovuto alla maggiore latenza dei protocolli di sharing.
  • Alta Affidabilità: Tranne alcune soluzioni di fascia elevata (in primis NetApp e Fujitsu), quasi tutti i NAS dispongono di una sola motherboard e quindi, se si vuole disporre di un sistema completamente ridondato, sarà necessario ricorrere a soluzioni cluster NAS. Questo vuol dire che lo spazio dovrà essere raddoppiato a tutto svantaggio dell’economicità.
  • Sicurezza: gestire la sicurezza in embienti enterprise dove siano presenti molti NAS con entrambi i protocolli attivi, può diventare un incubo.

 

Block Storage

Questa è la famiglia di storage più tradizionale. Tutti i dischi collegati allo storage sono aggregati in RAID Group i quali sono divisi in LUN che sono esportate, attraverso un protocollo specifico come iSCSI/Fibre Channel/FCoE, verso uno o più server.

Le LUN sono viste dal sistema operativo del server come fossero, a tutti gli effetti, dei dischi locali. Come tali dovranno essere formattati con un filesystem riconosciuto.

Se quindi nel NAS l’unità di lavoro è il file, nello storage block è o la LUN o il singolo blocco, a seconda delle operazioni.

I vantaggi del block storage sono:

  • Velocità: Se volete spremere fino all’ultimo la potenza del vostro database server abbinatelo ad un block storage. La bassa latenza dei protocolli di block storage permettono di massimizzare il numero di operazioni per secondo che il sistema è in grado di compiere. Anche in termini di banda passante, le SAN basate su Fibre Channel e FCoE non risentono dell’overhead dei protocolli della suite TCP/IP e permettono quindi di sfruttare quasi totalmente quanto messo a disposizione dal media trasmissivo.
  • Crescita: Con l’eccezione di NetApp, non esiste alcun NAS in grado di arrivare a gestire dati nell’ordine di qualche PB. Inoltre uno storage block diventa immensamente più efficiente di un NAS quando i file iniziano a raggiungere dimensioni nell’ordine delle centinaia di TB. Nel caso servano filesystem di dimensioni di qualche Exabyte, più block storage possono essere raggrupati logicamente e le operazioni possono essere parallelizzate su tutti loro attraverso specifici Volume Manager e Filesystem (Stornext e GPFS sono due esempi)
  • Replicazione: Nel caso sia necessario replicare i dati su diversi site un block storage è tendenzialmente più efficiente. Inoltre è praticamente impossibile (sempre con l’eccezione di NetApp) trovare un NAS che sia in grado di lavorare con repliche sincrone, specialmente con file di notevoli dimensioni.
  • Gestione della sicurezza: Nonostante gli storage siano oggetti piuttosto complessi, lavorando con oggetti delle dimensioni di una LUN la gestione di un block storage è tendenzialmente più semplice. Per esempio tutta la parte relativa alla sicurezza dei dati contenuti all’interno di una LUN è demandata interamente ai server ad essa sottesi e quindi è semplicemente fuori dalle mansioni dello storage admin. Inoltre un block storage, tranne per la parte di fine tuning, è totalmente agnostico rispetto al sistema operativo installato sui server.
  • Tecnologie: i block storage dispongono solitamente di un più ampio e aggiornato ventaglio di tecnologie rispetto ai NAS.

Svantaggi:

  • Complessità: Un block storage è intrinsecamente più complesso di un NAS. Va gestita la parte di HA dei vari controller, l’interfacciamento con una SAN, l’applicazione di tutte le tecnologie di cui dispone lo storage, replicazione, snapshot, RAID group, espansione di questi ultimi, rimappaggio delle LUN oltre ad una marea di parametri di fine tuning.
  • Maggiore complessità di gestione lato server: Nonostante lo storage sia agnostico rispetto all’uso che il server farà delle LUN, è vero che per un server admin, lavorare con configurazioni complesse  in un ambiente block storage richiede un notevole impegno e un carico di lavoro non indifferente. Si pensi ad esempio ad una configurazione con due server in cluster. Se il backend è un NAS con NFS, sarà solamente necessario mappare la share (  o le share) su entrambi i server e il gioco è fatto. Con uno storage block, si dovrà esportare la stessa LUN su entrambi i server e poi sarà necessario trovare e configurare un cluster filesystem che permetta ad entrambi i nodi di scrivere sullo stesso disco fisico senza che si sovrascrivano i metadati a vicenda.

 

Unified Storage

Si tratta della fusione tra NAS e Block Storage. Premesso, non esistono dei veri Unified Storage, nel senso che qualunque prodotto, dai più consumer ai più blasonati, tradisce la sua natura iniziale. NetApp è considerato il precursore degli Unified Storage.

Per quanto faccia il suo lavoro ben più che egregiamente, in realtà però non c’è alcun dubbio sul fatto che le sue radici siano intrisecamente NAS e lo si vede anche nel lavoro di tutti i giorni in quanto è certamente la modalità con cui questo prodotto lavora meglio.

Di contro un linea come gli Eternus DX di Fujitsu, da sempre degli ottimi block storage, sono recentemente diventati Unified e questo lo si nota lavorandoci pochi minuti. Le funzioni di Block sono predominanti sulla parte NAS che invece è piuttosto abbozzata ancora.

In altri sistemi lo si nota ancora di più. HDS ha una linea di Unified Storage, così come EMC2 con VNX, ma in entrambi i casi, non prendiamoci in giro, si devono aggiungere delle appliance, collegate alla parte block storage via Fibre Channel, e queste altro non sono che dei file server basati su Linux.

Il discorso non cambia  per tutti quei NAS che arrivano da un mercato consumer e che ora stanno aggredendo quello delle PMI. QNAP e Synology, due dei nomi più noti nel settore sono degli ottimi NAS che hanno aggiunto il supporto Block tramite l’implementazione del protocollo iSCSI. Il connubio funziona, e anche piuttosto bene, ma la vera natura di questi oggetti non stenta a rivelarsi. Lo stesso dicasi per VNXe di EMC2.

Il risultato è uno solo. Per quanto sia possibile creare dei prodotti ibridi, nessuno, neanche NetApp, sa davvero fare bene entrambe le cose. Una delle due “anime” sarà sempre sacrificata rispetto all’altra.

Ma il marketing e la moda del momento lo vogliono e quindi…

 

 

Tecnologie

Chi ha a che fare per la prima volta con gli storage rimane certamente stupito dal numero di sigle e tecnologie che ci ruotano attorno. sembrano solo degli agglomerati di dischi, in realtà è un mondo molto complesso.

Come poi già detto diversi produttori gestiscono tali tecnologie con implementazioni molto differenti, quindi capita talvolta che ci si trovi di fronte a comportamenti molto diversi anche su feature comuni.

 

Dischi

Quasi tutti gli storage permettono di utilizzare dischi di diversa tecnologia. Tali tecnlogie possono essere sia relative al tipo di interconnessione tra il disco e lo storage, sia relative all’implementazione interna del disco.

Per quanto riguarda i bus, al momento la fanno da padrone SATA e SAS. La prima, nata per il mercato consumer, si sta facendo strada nel mondo delle PMI aggiungendo via via sempre più feature. La seconda oramai è da considerarsi la base di tutti gli storage moderni.

SAS ha, in pochissimo tempo, reso obsoleti tutti gli altri bus. Ha tutte le feature avanzate di SATA e SCSI e ha praticamente rimpiazzato in toto Fibre Channel (inteso come sistema di comunicazione sia tra disco e controller, sia tra shelf e controller, non come protocollo SAN dove ancora la fa da padrone) come bus di comunicazione INTERNO agli storage.

Per quello che riguarda le tecnologie costruttive vi sono sostanzialmente tre filoni. Il primo è quello degli SSD. Arrivati recentemente nel mondo storage sono usati per unamarea di scopi, sia come tier con elevato numero di IOPS (numero di operazioni per secondo) sia come cache di elevata capacità per layer più lenti. Sono disponibili sia con interfaccia SATA (mondo consumer/PMI) sia coninterfaccia SAS. Sono inoltre disponibili sia con costruzione MLC (più lenti, meno affidabili, ma più economici e capienti) sia SLC (più veloci e affidabili ma molto meno capienti e decisamente costosi.

Il secondo filone è quello dei dischi lenti e ad elevata capacità. Si tratta di dischi mutuati da quelli del mondo consumer, che arrivano fino a 4 TB l’uno (7 in arrivo) e con velocità di rotazione che non supera i 7200 giri per secondo. Sono dischi con un numero molto basso di IOPS e vengono usati principalmente per tier lenti da usarsi come archivio e repository. Sono disponibli con interfaccia SATA e SAS. In quest’ultimo caso molti produttori li identificano come NL-SAS (Nearline-SAS).

Il terzo è quello dei dischi veloci. Hanno capacità ridotta (non superiore al TB in questo momento), velocità di rotazione compresa tra i 10.000 e i 15.000 giri, elevato numero di IOPS (ma comunque notevolmente inferiore agli SSD), molto spesso interfaccia SAS nativa (e per questo sono spesso definiti genericamente come “dischi SAS), e, più raramente, interfaccia SATA (pochi esempi tra cui il velociraptor della WD).

 

RAID

Qualunque storage che si rispetti permette l’utilizzo di più sistemi RAID. E questa è una feature basilare. In base al tipo utilizzo che si vorrà fare e alle richieste di velocità (intesa sia come banda passante sia come IOPS), si sceglierà anche il RAID level più corretto.

I RAID più comuni sono:

  • Raid 0: i dati sono scritti contemporaneamente frammentandoli su tutti i dischi a disposizione. Nessun tipo di faul tolerance. Se si rompe un disco si perdono i dati di tutto il pool. Molto veloce
  • Raid 1 (mirror): i dati sono scritti su due dischi. Non aggiunge velocità rispetto ad un unico disco ma si ha una ridondanza completa. Dispendioso in quanto richiede il doppio dello spazio necessario.
  • Raid 4: I dischi in un pool si dividono tra dischi dati e uno di parità. I dati sono scritti contemporaneamente su tutti i dischi dati, aumentando la velocità, e sul disco di parità è genrato un codice di parità mediante XOR. In caso di perdita di uno dei dischi del pool i dati mancanti saranno ricostruiti in base a quelli presenti e la parità. Poco usato in quanto la meccanica del disco di parità viene notevolmente stressata rispetto ai dischi dati.
  • Raid 5: Come il RAID 4 ma con il concetto di parità distribuita. Tutti i dischi sono contemporaneamente sia dischi dati sia dischi di parità. E’ il RAID più usato in quanto coniuga un certo livello di fault tolerance con velocità e economicità (si perde circa un 20% dello spazio per ogni pool per la gestione della parità ed è resistente alla perdita di un disco per pool)
  • Raid 6: Come il RAID 5 ma con parità doppia. Perde un ulteriore 10% di spazio per pool ma permette di resistere alla rottura di due dischi per pool.

 

Vi sono poi livelli di RAID multipli:

  • Raid 10: Un RAID 0 di due mirror. Coniuga massima velocità a replica totale dei dati
  • Raid 50: Un RAID 0 di RAID 5. Aumenta le performance rispetto ad un RAID 5 senza dover necessariamente duplicare lo spazio come nel RAID 10
  • Raid 60: Un RAID 0 di RAID 6.

Vari produttori hanno poi RAID proprietari:

  • Synology Hybrid RAID: è un livello di RAID proprietario con dati e parità distribuito, che permette di gestire la perdita di un disco nel pool, e che può essere fatto con dischi di grandezza differente
  • Raid DP: Proprietario NeApp è un RAID 4 con doppio disco di parità

Come regola generale i RAID dovrebbero essere sempre fatti con dischi identici o, quantomeno, basati sulla stessa tecnologia e di grandezza identica.

L’introduzione di un disco diverso in un RAID non è consigliato e porta tutto il RAID al livello delle caratteristiche del disco minore (ovvero un disco NL-SAS in un RAID SAS abbasserà la velocità di tutto l’array, l’introduzione di un disco da 2 TB in un RAID di dischi da 1 TB farà si che solo il 50% dello spazio di quest’ultimo disco sia effettivamente usato)

 

RAID Group

Tutti i dischi di uno storage sono inizialmente assegnati a dei RAID Group, ovvero sono organizzati in pool di dischi identici che condividono lo stesso livello di RAID.

La quasi totalità degli storage permette di gestire più livelli di RAID all’interno, scegliendoli in maniera più opportuna in base ai tipi di dati che vi andranno salvati.

 

Tier

Un tier è un insieme di RAID group coerenti, ovvero dello stesso livello e formati da dischi con la stessa tecnologia. Si parla di Tier veloci (tipicamente SSD in RAID 10), Tier mediamente veloci (dischi SAS in RAID 10 o RAID 6) o Tier lenti (dischi NL-SAS/SATA in RAID 5 o 6).

 

Cache

Qui davvero si apre un mondo. Ogni produttore gestisce la cache a modo suo. NetApp usa part della memoria del controller come cache e, alla bisogna, integra nuova cache con schede propietarie PCIe chiamate PAM e che possono arrivare fino a oltre 1 TB.

Fujitsu usa la memoria dei controller come cache, tenendola in RAID 1 per configurazioni a doppio controller e in RAID 5 per le configurazioni a controller multipli. È inoltre integrabile, per i sistemi di fascia media e enterprise, con un ulteriore strato di cache basata su dischi SSD.

EMC2 ha fatto parte della sua fortuna sul concetto di FAST Cache della serie VNX, dove dischi SSD possono essere utilizzati sia come cache sia come tier veloce.

Synology con il sistema operativo DSM 5.0 ha introdotto per tutti i suoi NAS con un numero sufficiente di dischi, la possibilità di usare di SSD (in RAID 1 e con il supporto alle funzioni di trim) come cache attiva per i dischi magnetici.

Come si vede i concetti e le implementazioni variano a tal punto che non è possibile confrontare ne’ la quantità ne’ il tipo di cache di produttori diversi. Semplicemente diverse implementazioni avranno impatti molto diversi sul risultato finale.

 

Autotier

E’ una funzione che permette di spostare i dati (intesi come singoli blocchi o come intere LUN, dipende dai produttori) da un tier all’altro automaticamente in base alle richieste degli utenti. Un tablespace di un RDBMS sarà progressivamente spostato su tier sempre più veloci, documenti di archivio su tier sempre più lenti.

Il re dell’autotier è sicuramente Compellent di DELL, ma ottime implementazioni si trovano anche in EMC2 VNX e nei nuovi Eternus DX S3.

 

Thin Provisioning

Una manna dal cielo per tutti gli storage admin. Permette non solo di sfruttare in maniera efficacissima tutto lo spazio a disposizione ma anche di gestire delle politiche doi overprovisioning nei casi in cui non si ha un’idea ben precisa di quanto sarà lo spazio effettivamente usato dagli utenti (GMail è il caso principe).

In uno storage tradizionale se si creano 5 LUN da 100 GB e di queste viene sfruttato olo il 20%, lo spazio allocato fisicamente sarà di 500 GB ma quello utilizzato solo di 100 GB, con uno spreco di 400 GB.

Con il thin provisioning si creerà un thin pool e da questo saranno ricavate le LUN. Lo storage allocherà solamente lo spazio utilizzato progressivamente dagli utenti evitando di sprecare spazio che rimanga come free space sui dischi degli utenti.

Si può andare anche in overprovisioning, dando agli utenti molto più spazio di quello che è fisicamente disponibile. Si imposteranno delle soglie di alerting in modo che lo storage admin potrà acquistare nuovi dischi nel momento in cui lo spazio fisicament disponibile sia in via di esaurimento. In questo modo è possibile diluire l’investimento nel corso del tempo e solo facendo fronte a reali necessità.

 

Snapshot

Funzione vitale per ogni storage moderno, permette di prendere delle fotografie della situazione di file/LUN/RAID group (dipende dalle implementaioni) in un dato momento. Lo snapshot può essere salvato nello stesso storage o copiato su uno storage remoto.

Uno snapshot può essere trasformato a sua volta in una LUN o si può fare un revert per far tornare il dato al momento dello snapshot.

Hanno un milione di possibili utilizzi. Possono essere dei backup giornalieri che vengono lasciati inline a disposizione degli utenti, possono essere usati per ridurre le finestre di backup in sistemi che non possono essere fermati (si prende lo snapshot, operazione che dura pochi secondi, e poi si fa il backup di questo piuttosto della LUN che continua a cambiare nel corso del tempo), si possono usare come replica asincrona in un datacenter remoto, come punto di ripristino in caso di installazioni di nuove versioni di software, per duplicare ambienti di produzione, per creae ambienti di test…

Il principe degl snapshot è certamente NetApp, grazie al fatto che è interamente basato su un filesystem ad oggetti chiamato WAFL e per il quale prendere uno snapshot vuol dire duplicare un banale tabella di puntatori. Altri produttori hanno implementazioni totalmente diverse che richiedono uno spazio apposito all’interno del RAID Group da cui è esportata la LUN, oppure una zona specifica dello storage, o altro.

Dato che lo snapshot è una operazione svolta a livello di storage, per alcune applicazioni che potrebbero richiedere un livello di coerenza dei dati a livello applicativo (leggi molto RDBMS come Oracle/SQL Server/DB/2 ecc, oppure Exchage o Domino) molti produttori creano degli specifici driver che permettono un dialogo tra storage e applicativo/sistema operativo del server in modo da garantire uno snapshot che sia anche coerente con lo stato delle applicazioni installate.

 

VAAI e ODX

Dato che spesso molte funzioni degli storage sono richieste anche dagli Hypervisor, VMware e Microsoft hanno pubblicato una serie di API, rispettivamente VAAI e ODX, per interagire con gli storage senza richiedere device driver specifici. Se uno storage implementa tali API esso effettuerà in hardware una serie di funzioni specifiche accelerando notevolmente le operazioni compiute dall’hypervisor.

In particolare via hardware saranno effettuate le funzioni di snapshot (virtual shadow copy di Microsoft), copia di file e inizailizzazione di virtual container (thick zeroes).

 

Replica

Esistono decine di diverse tipi di replica. Le repliche si distinguono sostanzialmente in due tipi e due modalità:

  • Asincrone: sono copie che avvengono solitamente ad intervalli regolari. Le due copie non sono mai allineate perfettamente ma i vantaggi sostanziali di questo tipo di repliche è che possono essere programmate in momenti in cui vi è maggiore disponibilità di risorse e che non hanno impatto sulla latenza delle operazioni.
  • Sincrone: queste copie sono di tipo transazionale. L’operazione di scrittura viene commissionata a uno dei  storage il quale provvederà a spedire la differenza in tempo reale anche al secondo. Solo quando l’operazione andrà a buon fine sul secondo storage il primo darà l’OK al server che l’ha commissionata. Nel caso che l’operazione non vada a buon fine verrà dato un errore e si effettuerà un rollback anche sul primario. Pur aumentando la latenza per ogni operazione le copie sincrone permettono di avere due LUN perfettamente allieate in ogni momento.

I tipi di copie possono essere:

  • Inter storage: la copia, sincrona o asincrona che sia, avviene tra due diverse LUN all’interno di uno stesso storage.
  • Tra datacenter: la copia avviene tra due diversi storage posti anche a notevole distanza l’uno dall’altro.

 

 

Connettività

Gli storage moderni, da questo punto di vista sono notevolmente migliorati. Fino a poco tempo fa si era costretti a scegliere il tipo di connettività al momento dell’acquisto in quanto vi erano controller specifici per ogni tipo di SAN.

Al momento attuale quasi tutti gli storage moderni (fatta eccezione per alcuni che sono costruiti specificamente attorno al protocollo iSCSI nonché ad alcuni NAS che hanno successivamente)  permettono un certo grado di indipendenza tra controller e parte di connettività.

Per esempio la linea Eternus DX S3 di Fujitsu permette di montare, per le linee low e middle, fino a due Channel Adapter per ogni singolo controller. Ogni CA implementa una differente tecnologie di interconnessione a scelta tra:

Block (ovvero collegamento ad una SAN):

  1. FC: disponibile con 2 porte e velocità di 8 e 16 Gb/s con connessione in fibra tramite SFP
  2. iSCSI: disponibile con 4 porte da 1 Gb/s in rame o 2 porte 10 Gbit/s in fibra tramite SFP
  3. FCoE: disponibile con connessioni a 10 Gbit/s in fibra tramite SFP

Unified (ovvero network con CIFS e NFS):

  1. Ethernet: disponibile con 4 porte in rame da 1 Gb/s o 2 porte 10 Gbit/s in fibra tramite SFP

Sono permesse tutte le combinazioni di CA purché siano uguali tra i due controller.

Spesso in caso di utilizzo di repliche remote, si predilige l’uso di iSCSI per le repliche (dato che TCP/IP è non solo  facilmente instradabile ma vi sono anche connessioni basate su IP ad alta velocità, come per esempio MPLS), e magari FC per la connessione locale.

NetApp è, per certi versi ancora più flessibile. I controller NetApp sono a tutti gli effetti dei server dedicati e quindi possono essere espansi utilizzando schede PCIe invece che hardware dedicato.

 

Cosa scegliere?

Non sempre è facile dare una risposta univoca. Tendenzialmente Fibre Channel è un protocollo sicuro, certificato nella quasi totalità degli ambienti, e super collaudato.

Inoltre se vi sono già presenti delle SAN permette di poter integrare vecchi e nuovi apparati senza troppa difficoltà. Inoltre Fibre Channel è la scelta quasi obbligata nel caso si vogliano integrare in una SAN sistemi di memorizzazione come tape library e juke box ottici.

Partendo da zero con un nuovo datacenter iSCSI può essere un’ottima scelta. Permette di risparmiare non poco denaro rispetto a FC. Non solo perché si risparmia l’acquisto dele due fabric ma anche perché molti server moderni integrano schede di rete CNA a 10 Gbit/s direttamente onboard al contrario di FC che richiede una o più schede aggiuntive.

A livello di performance, usando degli switch veloci, abilitando i jumbo frame, usando schede accelerate in hardware e facendo un po’ di tuning si rischia di avere le stesse performance di FC pur con una soluzione più economica.

Non mi sento di consigliare FCoE al momento. Come già detto nessun fornitore, tra quelli che lo supportano, sembra essere seriamente intenzionato a creare degli use case su questo protocollo. L’idea rimane buona ma semplicemente non trovo implementazioni e success stories che possano essere convincenti.

 

 

Datacenter for Dummies – Questo articolo è parte di una serie:

  1. Datacenter for Dummies: Le SAN
  2. Datacenter for Dummies: Gli Storage
  3. Datacenter for Dummies: Networking