XenServer 7 software RAID with mail alert

Leggi questo articolo anche in italiano.

XenServer 7 is emerging as the reference implementation of the opensource hypervisor Xen, proving advanced features regarding storage, networking, HA and management; all packaged in a self-contained, enterprise-level bundle, often superior to VMware vSphere, HyperV and KVM, the other big players of the enterprise virtualization market.

It should also be noticed that Xen is the hypervisor of choice for the majority of public clouds (AWS and the others), is completely FLOSS  software and its XenServer declination is managed directly from the Linux Foundation (no CITRIX anymore), making it the de-facto standard solution for the bare metal opensource virtualization.

Powerful batteries included!

The software stack that surrounds the Xen kernel has made a giant leap thanks to the adoption of a modified CentOS 7 as the dom0 in XenServer 7.
The standard installation of XS already include every piece of software needed to completely skip an hardware RAID solution and adopt an enterprise-ready software RAID solution! As of today, MDADM is one of the few RAID solution that can manage NVMe RAID or other niche configurations; thanks to the modern CPU power, MDADM (especially with very big arrays) plays on the same ground of some ASICS-based controller.

Furthermore, software RAID enable the creation of array using non-branded disks, a strategic feature of XS7 in comparison to products like VMware, that at most permits the creation of a RAIN using paid add-ons like vSAN. If you have ever compared the price of branded HDD or SSD  (HP, IBM, Dell, ecc.) with the COTS ones, you know what I’m talking about.

Dive into MDADM

This is the to-do list you have to follow in order to build a software RAID that will warn you in the event of malfunction:

  • Creation on an MDADM array;
  • Configure SSMTP to send email warnings;
  • Test if email alerts are working;
  • Add the array as an SR to XS7.

MDADM is a very battle-tested piece of software; included in the Linux kernel since many years, has earned on the field its reputation of very stable and bug-free software; indeed it is used in big critical system (like the “big irons x86”) and in the majority of commercial NAS system (Synology, QNAP, Buffalo, ecc).

Because is already included in the standard installation on XS7, the creation of a RAID array is very simple, especially in the typical scenario in which you have installed the hypervisor in a USB drive that won’t be part of the array… as recommended by the best practices! I have spoke about that here (Warning, italian inside™! Let me know if you want to read it in english).

For instance, create a RAID 10 with the first four HDDs is as simple as

 mdadm --create /dev/md0 --run --level=10 --raid-devices=4 /dev/sd[a,b,c,d] 

To monitor the disk syncing, just do

 watch cat /proc/mdstat 

or the evergreen

 mdadm --detail /dev/md0

that will also give you various information about the status of the array.

Would you trust a system that does not warn you in the event of failure?

We are going to set the array monitoring; just to begin, copy the active array configuration in the config file of MDADM with

 mdadm --verbose --detail --scan >> /etc/mdadm.conf 

This will enable the array monitoring by the MDADM daemon.
Now, configure the SSMTP to send email warnings… just as an example, this configuration of /etc/ssmtp/ssmtp.conf is usable to send notification from a gmail address:

 
root=your_mail@gmail.com
mailhub=smtp.gmail.com:587
Hostname=your_hostname.yourdomain.sth
UseTLS=YES
TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt
UseSTARTTLS=YES
AuthUser=your_mail@gmail.com
AuthPass=your_password
FromLineOverride=YES

It’s important to set /etc/ssmtp/revaliases like that:

 root:your_mail@gmail.com:smtp.gmail.com:587 

Eventually, the MAILADDR and MAILFROM parameters from the last rows of /etc/mdadm.conf will need to be assigned to your sender and receiver addresses, so mdadm.conf will look like that:

 
ARRAY /dev/md0 level=raid10 num-devices=4 metadata=1.2 name=your_hostname:0 UUID=UUID_ARRAY
    devices=/dev/sda,/dev/sdb,/dev/sdc,/dev/sdd
MAILADDR destination_mail@provider.sth
MAILFROM your_mail@gmail.com

Don’t leave your chair without some testing!

Now that the configuration is completed, you need to do some checks; MDADM can send a test email with

 mdadm --monitor --scan --test --oneshot 

But, if you really want, you can put a disk in “failed” state (be aware of rebuilding times with big HDD) using

 mdadm --manage --set-faulty /dev/mdo /dev/sdb mdadm --manage /dev/md0 --add /dev/sdb 

You have to wait a little for the fail detection, as far as ten minutes, because the daemon is correctly “lazy” at recognizing the fail, even if it is simulated.

Now that the array is tested and ready to be used, just add it to the XS7 SR:

 xe sr-create content-type=user device-config:device=/dev/md0  name-label="Local RAID10" shared=false type=lvm 

In XS7, the array is recognized even after a reboot without manual module insertion or other configurations; everything is just ready to go!

XenServer 7 software RAID con mail alert

You can also read this article in english.
XenServer 7 si sta imponendo come l’implementazione di riferimento dell’Hypervisor open source Xen, fornendo funzionalità avanzate di storage, networking e gestione (oltre che HA) pacchettizzate in una soluzione totalmente self-contained e di livello enterprise; il tutto, risultando spesso superiore a VMware vSphere e ad HyperV e KVM, gli altri big player del settore.

Giusto per ricordarlo, Xen è l’Hypervisor che funge da motore per la maggior parte dei cloud pubblici (da AWS in giù), è totalmente open source e la sua declinazione XenServer è ora gestita direttamente dalla Linux Foundation (non più da CITRIX),  risultando de facto la soluzione standard per la virtualizzazione bare-metal FLOSS.

Potenti batterie incluse!

Nella versione 7, l’adozione di una CentOS 7 modificata come dom0 ha fatto fare passi da gigante allo stack software che circonda il microkernel Xen… difatti, l’installazione standard di XS7 include già tutti gli elementi del puzzle necessari per poter saltare a piè pari una soluzione RAID hardware e tuffarci nelle meraviglie del software RAID! MDADM, ad oggi, è una delle pochissime alternative per creare array fra dischi NVMe o gestire altre configurazioni di nicchia e/o con un forte stress sulle performance; grazie alle CPU moderne, il software RAID (specie su grossi array, e naturalmente con diverse peculiarità) gioca spesso alla pari con gli ASICS dei più rinomati controllers.

Il RAID software consente inoltre di creare array utilizzando dischi di qualsiasi brand (anche non certificati per il vostro server), cosa che da un vantaggio strategico a XS rispetto a prodotti come VMware, che invece permettono al più di creare RAIN  tramite add-on a pagamento come vSAN. Se avete mai comparato i costi dei dischi branded (HP, IBM, Dell, ecc.) VS gli stessi modelli off-the-shelf (in special modo SSD), capirete bene quale possa essere il vantaggio economico.

Dive into MDADM

Il workflow da seguire per realizzare una soluzione RAID software di livello enterprise su XS7 che ci avviserà in automatico di eventuali malfunzionamenti, è molto semplice:

  • creazione di un array con MDADM;
  • configurazione di SSMTP per l’invio di notifiche;
  • test dell’invio notifiche e fault-rebuild dell’array;
  • aggiunta dell’array come SR.

MDADM è un software veramente battle-tested; incluso nel kernel linux da moltissimi anni, si è guadagnato sul campo la sua fama di stack molto stabile e privo di bugs importanti, tant’è che viene da anni utilizzato in grossi sistemi di produzione (degni di nota sopratutto i “big irons x86” dell’ultimo quinquennio), nonché nella maggior parte dei NAS commerciali (Synology, QNAP, Buffalo, ecc).

Risultando già incluso nella installazione standard di XS7, creare un array RAID risulta semplicissimo nel tipico scenario in cui avete installato l’Hypervisor su un drive USB che non farà parte dell’array… come da best practice! E voi seguite le best practices, no? Ne faccio cenno anche qui.

Ad esempio, nel caso in cui volessimo creare un array RAID 10 con i primi quattro HDD del sistema, basterà eseguire

 mdadm --create /dev/md0 --run --level=10 --raid-devices=4 /dev/sd[a,b,c,d] 

e, per monitorare la costruzione dell’array,

 watch cat /proc/mdstat 

oppure il sempreverde

 mdadm --detail /dev/md0

che, inoltre, ci fornisce varie informazioni sullo status del nostro array.

Ti fidi di un sistema che non ti avvisa se c’è un guasto?

Settiamo io monitoraggio dell’array; intanto, copiamo la configurazione attiva nel file di configurazione di MDADM

 mdadm --verbose --detail --scan >> /etc/mdadm.conf 

questo attiva il monitoring dell’array con le caratteristiche specificate. Quindi, configuriamo SSMTP per l’invio della posta ad un nostro indirizzo e-mail.

A titolo di esempio, la seguente configurazione del file /etc/ssmtp/ssmtp.conf è utilizzabile per l’invio delle notifiche da un indirizzo gmail:

 
root=vostra_mail@gmail.com
mailhub=smtp.gmail.com:587
Hostname=vostro_hostname.vostrodominio.sth
UseTLS=YES
TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt
UseSTARTTLS=YES
AuthUser=vostra_mail@gmail.com
AuthPass=vostra_password
FromLineOverride=YES

È importante non dimenticare di configurare anche il file /etc/ssmtp/revaliases con una riga come la seguente:

 root:vostra_mail@gmail.com:smtp.gmail.com:587 

Infine, è necessario aggiungere i parametri MAILADDR e MAILFROM nelle ultime righe di /etc/mdadm.conf, in modo che il file risultante sia assimilabile a questo modello:

 
ARRAY /dev/md0 level=raid10 num-devices=4 metadata=1.2 name=vostro_hostname:0 UUID=UUID_ARRAY
    devices=/dev/sda,/dev/sdb,/dev/sdc,/dev/sdd
MAILADDR mail_di_destinazione@provider.sth
MAILFROM vostra_mail@gmail.com

Che setup sarebbe, senza nute… senza testing?

Ora che la configurazione è completata, possiamo testarla; MDADM può eseguire l’invio di una mail di test del sottosistema di notifiche con

 mdadm --monitor --scan --test --oneshot 

; in generale, il test è affidabile, ma se volete potete anche mettere in status “failed” uno dei dischi (attenzione ai tempi di rebuild) con

 mdadm --manage --set-faulty /dev/mdo /dev/sdb mdadm --manage /dev/md0 --add /dev/sdb 

Raccomando di attendere la notifica via mail per una decina di minuti, il demone è giustamente un po “lazy” nel riconoscere il fail, anche quando simulato.

Ora che l’array è testato e pronto all’uso, basta aggiungerlo agli SR utilizzabili da XenServer con un semplice

 xe sr-create content-type=user device-config:device=/dev/md0  name-label="Local RAID10" shared=false type=lvm 

In XS7 l’array viene riconosciuto al reboot senza dover forzare il caricamento di moduli o altre configurazioni particolari, tutto è semplicemente pronto all’uso.

 

Boota o non boota, qvesto è il problema

Se avete acquistato di recente una memoria SSD PCIe NVMe, nel leggere documentazione e forum vari vi sarete sicuramente imbattuti nell’interrogativo categorico riguardo questi dispositivi: boota o non boota?

Fuori dall’eden del plug-and-play

Non più nel comodo orticello SATA, molti utenti enthusiast si sono accorti di come i nuovi dispositivi mal supportino, sulla maggior parte delle schede madri, l’avvio diretto del sistema operativo, rendendoli di fatto molto meno appetibili agli appassionati (e non) che non possiedono schede madri dell’ultima generazione e un SSD compatibile.

Ebbene, questo è un problema che riguarda solamente gli utenti Windows. Vi siete mai chiesti perché Linux consigli di utilizzare una partizione segregata per /boot? Un retaggio dei vecchi UNIX, che torna sempre comodo…

Quasi tutte le architetture non-intel difatti, NON supportano (o non supportavano) il boot del sistema operativo dai dispositivi di storage “di lavoro”; il software necessario ai primi stages d’avvio viene invece caricato in speciali partizioni hardware (a mo’ di firmware) e copiato in RAM direttamente dal BIOS o suoi sostituti. Una implementazione di questa idea si può ad esempio trovare nell’Initial Program Load (IPL) delle macchine POWER IBM.

La multiforme bootabilità del pinguino

Torniamo alle nostre macchine x86 con NVMe: partiamo dal presupposto che non appena venga bootato il kernel Linux, il resto del sistema possa stare su qualunque, e dico QUALUNQUE cosa venga riconosciuta dal kernel, fosse anche una cassettina a nastro collegata via rete da una località remota… attualmente, credo proprio che tutte le schede NVMe presenti sul mercato siano supportate dal kernel 3.10 in poi.

Come caricare il kernel (ricordiamolo, sta nella partizione /boot) in memoria allora? Manca solamente un dispositivo che venga riconosciuto come boot device standard e che sia

  • economico: abbiamo già speso i soldi per la nostra NVMe;
  • affidabile: niente riutilizzo di vecchi dischi meccanici!
  • non troppo grande: la partizione di /boot può benissimo essere <1Gb.

Una penna, una penna, il mio regno per una penna!

La soluzione ci giunge da una pratica comune a parecchi setup raid software: bootare da una penna USB! Più precisamente, all’installazione del sistema basterà scegliere di installare MBR e partizione /boot sul succitato pendrive. Pensate che la penna USB sia un SPOF? E allora fate un’immagine della USB e la copiate su un’altro dispositivo, che potreste ad esempio tenere offline.

La stessa immagine potete tenerla da qualche altra parte per poterne sempre fare copie addizionali; dovrete solamente ricordare di aggiornare le copie dopo un aggiornamento del kernel (la cosa avviene abbastanza di rado) per evitare ogni problema di incompatibilità, ma in generale il vostro sistema dovrebbe avviarsi ugualmente anche con una /boot outdated se non cambiate i dispositivi di storage, o se vi riferite ad essi tramite UUID.

Questo disaccoppiamento dello storage potrà sembrarvi curioso, ma è una best practice consolidata nel mondo della virtualizzazione: questa modalità di avvio è comunissima e consigliata con tutti gli hypervisor embedded come ESXi o XenServer (molti server hanno appositi slot USB o SD interni), e comincia ad affermarsi anche per il deployment di container-OS immutabili.

Il trucco sta proprio nella natura principalmente read-only della partizione /boot: viene letta solamente all’avvio e scritta molto sporadicamente (solo per gli aggiornamenti), ed è noto come la vita delle memorie flash sia legata a doppio filo al numero di scritture sul dispositivo, più che alle letture.

Una scelta industry-standard

Come indicazione generale, comprate una chiavetta di buona qualità: trovate buoni devices delle principali marche per una decina di euro. Esistono anche dispositivi certificati per i vari hypervisor, che sono testati ed hanno una endurance pazzesca se utilizzati in sola lettura, ma difficilmente arriverete mai a percepire benefici sull’affidabilità.

Non siete ancora convinti? Continua a sembrarvi un setup molto strano? Beh è lo stesso (molto affidabile) setup di tutti i NAS consumer: il firmware (di solito una distro Linux) è scritto su una memoria a stato solido, generalmente una SD (ecco perché il firmware è aggiornabile!). Non pensavate mica che un NAS da 100€ avesse avanzati sistemi di mirroring delle ROM o chissà quale altra trovata magica, giusto?

È affidabile? Abbastanza. Se facciamo le copie della /boot altrove? Parecchio. Parecchio più dei NAS consumer ai quali affidate i vostri dati ogni giorno.

The birth and death of RAID

Le prime notizie relative al RAID risalgono alla fine degli anni ’70, quando le macchine UNIX midrange iniziarono a dotarsi di quello che oggi chiameremmo “RAID Software”; prima c’erano solo sistemi per la correzione di errori in memoria, ma di tipo offline.

Pubblicità progresso

Fa sempre bene ricordare come il RAID non sia una soluzione che riguarda la sicurezza dei dati: il RAID è una soluzione che riguarda la continuità del servizio. Ovvero, un array RAID permette di continuare a lavorare durante un guasto, ma è implicito che ci si debba immediatamente prodigare per sostituire il componente guasto e non si possa fare a meno di un sistema di backup.

Il RAID non sostituisce il backup, mai: sono due sistemi concettualmente ed operativamente diversi; se il RAID è online (cioè utilizzato per l’accesso ai dati di lavoro), e garantisce la continuità del servizio, il backup è invece offline, off-site e fornisce archiviazione, conservazione e sicurezza dei dati. Il backup in genere è una soluzione di disaster recovery, il RAID è risk mitigation.

SCSI Golden Age

L’utente medio ricorderà probabilmente i controller entry level Adaptec o LSI dei primi anni ’90, nati principalmente per supplire allo scadente RAID software integrato in Windows… ancora oggi parecchio deficitario rispetto all’esemplare implementazione di md su Linux. Le tipiche configurazioni prevedevano RAID 5, tre-cinque dischi (rigorosamente dispari, per agevolare il calcolo della parità)… fino all’inizio degli anni 2000, i dischi costavano parecchio e non c’erano alternative in quella fascia di prezzo.

Inoltre, le CPU x86 erano ancora pressapoco dei giocattoli, che mal sopportavano l’overhead dei livelli RAID con parità. I SO avevano ancora una gestione delle code di I/O abbastanza primitiva; l’offloading del calcolo all’ASIC del controller era una manna dal cielo. Da metà degli anni ’90 il RAID hardware in qualsiasi macchina server viene considerato praticamente obbligatorio, e in una decade diventa commodity.

Ogni array che si rispetti ha i suoi dischi SCSI da 73Gb a 10kRPM, il RAID 5 regge perché il fallimento dovuto ad URE è abbastanza improbabile date le dimensioni degli HDD. Da segnalare anche la diffusione nelle motherboard consumer dei cosidetti “FakeRAID“, implementazioni puramente software e supportate quasi unicamente da Windows. Sono generalmente non troppo prestazionali o affidabili, e poco impiegate in ambito enterprise.

Per dipingere una parete grande, ci vuole un pennello grande

Saltiamo avanti di due decenni, siamo negli anni 2010 (chissà che convenzione tireranno fuori riguardo queste decadi, al momento lo scrivo per esteso): i dischi raggiungono capacità di svariati Tb, il costo dello storage è in caduta libera, il fallimento per URE mette fuori dai giochi i livelli RAID con singola parità.

Il RAID 10 viene universalmente adottato in ambito enterprise, affiancato dal RAID 6 o livelli proprietari (aventi comunque almeno doppia parità) per l’archiviazione massiva. Assistiamo inoltre ad una ulteriore evoluzione del RAID software: le prestazioni delle CPU rendono md più che adeguato per la maggior parte degli array-use_case; inoltre, con la comparsa di ZFS l’utente può usufruire di un filesystem che fa anche RAID (con tripla parità!) e volume management avanzato… permette anche di impostare dispositivi per il caching! Ciononostante, il RAID hardware viene ancora preferito in sistemi di produzione per alcune caratteristiche avanzate:

  • possibilità di fare caching con analisi euristica dei blocchi più utilizzati su cache molto grandi (anche decine di Gb);
  • blind swap, ovvero sostituzione dei dischi a caldo e ricostruzione dell’array senza nessun altro intervento da parte dell’operatore (spostando la gestione dell’array dal system admin all’operatore hardware);
  • batterie interne, che anche in caso di totale failure dell’alimentazione permettono al controller di terminare le scritture o almeno memorizzarle su dispositivi a stato solido fino al successivo recovery;
  • replica remota su altri controller con latenze molto basse;
  • OS-agnosticità, tanto da poter essere montati su dispositivi come SAN, NAS, DAS ecc.

Il RAID è una pratica ormai assolutamente standardizzata e implicita in ogni installazione di un certo livello.

…and thanks for all the bits

E allora, perché nel titolo parlo di morte del RAID? La domanda da porsi è se il concetto di unità di storage in RAID (per come lo intendiamo oggi, assistito da un controller hardware in particolare) abbia ancora senso con l’avvento degli SSD di nuova generazione, per i seguenti motivi:

Prestazioni del bus

Sfruttando le connessioni PCI-E (o, ultimamente, gli slot della RAM), gli SSD permettono prestazioni teoricamente equivalenti alle massime ottenibili da un controller RAID, poiché sfruttano lo stesso bus di sistema per comunicare con la cpu.

Parallelismo/Prestazioni

Le maggiori prestazioni ottenuti dai controllers compiendo I/O in parallelo su dischi rotazionali, oggi sono replicabili leggendo o scrivendo in contemporanea (striping) da un numero praticamente arbitrario di NAND, solamente “limitato dal controller”; questa volta, quello dell’SSD.

Da qui la crescita esplosiva nelle prestazioni degli ultimi SSD messi in commercio, che arrivano a picchi di quasi 4Gb/s (GigaBYTE, non Bit) R/W, con latenze bassissime. E se ci sono ancora obiezioni sulla capacità, basta guardare agli ultimi ritrovati.

Parallelismo/Affidabilità

La maggior affidabilità del RAID di dischi rotazionali (RAID 10, ovviamente) è data dal poter eseguire letture e scritture in parallelo (stavolta, cloning) su “pezzi di hardware” distinti, e grazie ad uno strato software di recuperare eventuali fallimenti… esattamente ciò che viene fatto NAND per NAND dagli attuali SSD enterprise, che spesso espongono una capacità effettiva minore (anche del 30%) per potere, grazie alla logica del controller, tenere alcuni settori spare che generalmente vengono utilizzati come settori di parità a la RAID con parità (multipla!).

Questa architettura sembra funzionare molto bene per via dell’enorme numero di nodi per stripes e il grande “dominio di parità”; il controller riesce a tenere conto con discreta precisione dello stato di salute delle singole componenti, e generalmente rimpiazza le NAND che si avvicinano a fine vita con quelle precedentemente tenute a riposo prima che ci possa essere un sostanziale degradamento di prestazioni o affidabilità. Un esempio di queste funzionalità viene molto chiaramente descritto qui.

So what?

A mio parere, ci avviciniamo ad un cambio di paradigma nel quale il supporto di memorizzazione a stato solido sarà affidabile e prestazionale quanto un controller RAID, rendendone di fatto superfluo l’utilizzo, limitatamente almeno allo storage locale. La battaglia si sta già svolgendo, specialmente fra gli algoritmi per il wear-leveling e livelli di RAID-ridondanza “interni”; ne parlano molto gli ultimi papers di IBM sui loro nuovi storage all-flash e altri di Intel e FusionIO.

Costano troppo? Space-wise, ancora per qualche anno. IOPS-wise, c’è già stato il sorpasso. Per fare gli IOPS di un SSD enterprise ci vogliono una batteria di dischi SAS più un controller RAID con una cache mica da ridere… e se non li puoi hostare dentro la macchina singola, ti serve anche una SAN, che presa da sola peggiora l’affidabilità del sistema. Altrimenti ne servono due, con due switches FC, HBA ridondanti, ecc; ed ecco che la soluzione con storage locale torna ad essere concorrenziale sia sul prezzo che nella semplicità di gestione, magari assistita da una replica block-level.

Naturalmente, lo use-case che immagino è quello di workload mission-critical; non certo di quello di consolidamento dello storage nel quale latenza, prestazioni pure e semplicità dell’infrastruttura passano in secondo piano.

Sulla mistica dello storage enterprise

Quello dello storage non-consumer è sicuramente uno dei settori dell’IT più floridi per quanto riguarda la nascita di miti e leggende: cosa favorita, oltre dal marketing dei big players, dall’oggettiva complessità di alcuni concetti in gioco e dalla diffusa ignoranza degli uomini-IT in merito.

Vediamo di semplificare un po’, dando delle descrizioni “operative”.

DAS

Né più né meno dello storage interno del vostro server, ma ospitato in una enclosure esterna; da vedere come una “unità di espansione dischi” o “moltiplicatore di porte SAS esterno”. Generalmente il collegamento alle macchine avviene tramite cavi SAS (gli stessi che collegano i dischi locali), lo storage viene visto esattamente come uno o più dischi interni alla macchina.·

Come un qualsiasi controller SAS interno, sono muniti di funzionalità RAID e permettono di esporre partizioni, “array” dell’aggregato di dischi fisici, presentati alla macchina come normalissimi dispositivi a blocchi AKA dischi interni.

SAN

È qui che si concentrano la maggior parte degli equivoci, quindi diciamolo subito: la SAN non è altro che un DAS esposto ai servers tramite un protocollo di rete (iSCSI, FC, FCoE). Fine. Più precisamente la Storage Area Network è un insieme di dispositivi, composta oltre dalla parte al quale viene generalmente attribuito il nome SAN, anche dagli switch e dagli HBA presenti sui servers; è giustappunto un network, non un singolo dispositivo.

È quindi possibile fare switching e routing del flusso di dati riguardanti lo storage, oltre a poter utilizzare il tutto in direct-attach similmente al DAS. Cosa? Routing dello storage? Pazienza Iago, pazienza.

NAS

Questo lo conosciamo bene tutti; un NAS è un fileserver che permette la condivisione dello storage a livello del filesystem, ovvero incorpora tutto lo stack necessario a presentare ai servers files e cartelle. Questo è l’unico dispositivo fra quelli presi in esame a permettere l’accesso allo storage a livello di files e non di blocchi; cioè, non è permesso accedere direttamente all’array di dischi fisici per partizionarlo, formattarlo ecc. Inoltre è l’unico, e sottolineo l’unico, ad incorporare la logica necessaria a gestire l’utilizzo in concorrenza di più macchine ad uno stesso pezzo di storage.

E allora?

Come, la SAN non serviva per “condividere lo storage” fra più macchine? NO. La SAN nasce principalmente per semplificare e rendere più efficiente la gestione dello spazio su disco di installazioni molto dense con parecchi servers, poiché è parecchio più semplice assegnare una LUN ad un server piuttosto versus spostare fisicamente (con ricostruzione array e quant’altro) dischi fra più macchine. In questo modo, è possibile assegnare dinamicamente “dischi” di dimensione variabile al server, senza interventi fisici e interruzioni dell’operatività: il punto che si possa fare su più macchine contemporaneamente, condividendo i dischi fisici, è la ragion d’essere della SAN.·

In realtà, anche il DAS può fornire funzionalità di questo tipo se le macchine sono poche e abbastanza vicine allo storage, collegando direttamente i servers allo storage. Nella caso della SAN, sia essa FC, FCoE o iSCSI, è addirittura possibile collegare lo storage e i servers a degli switch e persino a dei router in configurazioni simili a quelle di una tradizionale LAN, che permettono ad esempio di realizzare configurazioni che hanno particolari caratteristiche di resistenza ai guasti (utilizzando più SAN in replica, ad esempio).

Andiamo oltre adesso; collegate due macchine fisiche alla stessa LUN di una SAN (con dei dati all’interno, magari): vi ritroverete con un filesystem irrimediabilmente corrotto dopo qualche secondo, e la totale distruzione dei dati sarebbe cosa inevitabile dopo pochi tentativi di scrittura. Perché? Perché collegare una SAN a due macchine, è come collegare un ideale hard disk fisico con due cavi SAS a diversi computers: alla prima operazione contemporanea, vi ritrovate con un ammasso di bit insignificanti. C’è un solo modo per gestire un hard disk condiviso fra due macchine: un filesystem distribuito, detto anche clusterizzato.

SAN != File Sharing

L’errata considerazione della SAN come “storage di files condiviso” a mio parere nasce dalla grande facilità d’uso di VMFS di VMware, che permette l’uso “trasparente” della SAN, presentando gli array agli utenti proprio come farebbe un NAS, cioè come spazio formattato nel quale è possibile effettuare operazioni in concorrenza sui files. Ma attenzione: come nel caso del NAS, è il filesystem che si occupa di gestire la concorrenza, questo nulla ha a che vedere con le caratteristiche della SAN. Provate a configurare un filesystem clustered come GPFS o GFS, se volete capire profondamente come funzioni la cosa; è sempre bene sporcarsi un po’ le mani per arrivare ad una comprensione piena di certi meccanismi.

Performance

La tipologia di storage più performante in assoluto continua ad essere quello interno ai servers, ancor di più con il recente affermarsi di ssd PCI-E e memory-channel. Lo storage di rete, sia esso SAN o NAS (e in una certa misura anche il DAS) è comunque limitato dall’overhead del protocollo di rete e dalla sua larghezza di banda. L’ultima versione del FC quota 16Gbit/s, appena uscito e dai prezzi folli… Il PCI-E 3.0 16x fa circa 126Gbit/s, oggi, per slot, e sono già uscite le specifiche del 4.0 che avrà esattamente il doppio di banda; cambia poco negli ordini di grandezza se consideriamo iSCSI. Il DAS ha generalmente poco overhead, scala in termini di multipli interi di porte SAS a 12Gbit/s.

Keep it simple, stupid!

Tutto questo può essere letto come un invito a semplificare il più possibile la topologia dello storage: si guadagna in prestazioni, si risparmia, si ottiene un’affidabilità maggiore; la crescita di complessità può essere giustificata solamente quando non è assolutamente possibile soddisfare i requisiti progettuali senza aggiungere componenti o layer di astrazione.

In generale, lo storage locale è sempre da preferire a tutte le altre alternative; la “catena cinematica” è la più corta, ciò porta a meno connettori/interfacce che possono guastarsi (o fare contatto intermittente, che è una delle cause più comuni del fail nei raid con parità), minore latenza e prestazioni massime, oltre che semplicità di gestione. La crescita di dimensioni dello storage può urtare i limiti fisici del singolo server, ed ecco che abbiamo bisogno di un DAS per la scalabilità. Gli ambiti dove è opportuno utilizzare NAS e SAN enterprise dopo l’avvento dei meccanismi di replica software block-level e file-level, sono sempre più ristretti; in particolare, nel caso della SAN è necessario avere del personale iniziato ai misteri della condivisione block-level ed una infrastruttura abbastanza ridondante, cosa che spesso si traduce in esborsi non indifferenti e difficilmente giustificabili nel mondo delle PMI.