RAID: una rivisitazione

Ai tempi in cui ero un tecnico dell'assistenza alle prime armi e a malapena conoscevo qualcosa sull'amministrazione dei sistemi, uno dei pochi argomenti che ci si aspettava sempre che conoscessimo alla perfezione era il RAID – Redundant Array of Inexpensive Disks. Era la risposta a tutti i nostri problemi di archiviazione. Con il RAID potevamo ampliare i nostri filesystem, ottenere un throughput migliore e perfino aggiungere ridondanza, consentendoci di sopravvivere alla perdita di un disco, cosa che, soprattutto a quei tempi, accadeva piuttosto regolarmente. Con l'avvento delle appliance di archiviazione NAS e SAN, la competenza nello scendere fino al livello dell'archiviazione fisica e nel metterla a punto per soddisfare le esigenze del sistema in questione sta rapidamente scomparendo. Questa non è una buona cosa. Il fatto che stiamo delegando l'archiviazione a dispositivi esterni non cambia la realtà che dobbiamo comprendere a fondo la nostra archiviazione e configurarla in modo da soddisfare le esigenze specifiche dei nostri sistemi.

Un'idea errata che sembra essersi insinuata nel settore negli ultimi cinque-dieci anni è la convinzione che il RAID rappresenti in qualche modo un backup del sistema. Non è così. Il RAID è una forma di tolleranza ai guasti. Backup e tolleranza ai guasti sono concettualmente molto diversi. Il backup è concepito per consentirti di effettuare il ripristino dopo che si è verificato un disastro. La tolleranza ai guasti è concepita per ridurre, in primo luogo, la probabilità che il disastro si verifichi. Pensa alla tolleranza ai guasti come alla costruzione di una recinzione in cima a un dirupo e al backup come alla costruzione di un ospedale ai suoi piedi. Non vorrai mai davvero trovarti in una situazione priva sia di una recinzione sia di un ospedale, ma si tratta sicuramente di cose diverse.

Una volta che implementiamo il RAID per le nostre unità, siano esse collegate localmente o presenti su un'appliance remota come una SAN, disponiamo oggi di quattro soluzioni RAID fondamentali tra cui scegliere per l'azienda: RAID 1 (mirroring), RAID 5 (striping con parità), RAID 6 (striping con doppia parità) e RAID 10 (mirroring con striping). Ne esistono altre, come il RAID 0, che dovrebbero essere utilizzate solo in rare circostanze, quando si comprendono davvero le esigenze del proprio sottosistema di unità. Anche il RAID 50 e il 51 vengono utilizzati, ma molto meno comunemente, e non sono affatto altrettanto efficaci. Dieci anni fa il RAID 1 e il RAID 5 erano diffusi, ma oggi disponiamo di più opzioni.

Esaminiamo passo dopo passo le opzioni e discutiamo alcuni numeri di base. Nei nostri esempi useremo n per rappresentare il numero di unità nel nostro array e useremo s per rappresentare la dimensione di una singola unità. Utilizzando questi valori possiamo esprimere lo spazio di archiviazione utilizzabile di un array, rendendo facili i confronti in termini di capacità di archiviazione.

RAID 1: in questo tipo di RAID le unità vengono messe in mirror. Hai due unità che fanno tutto insieme nello stesso momento, da cui il termine “mirroring”. Il mirroring è estremamente stabile perché il processo è molto semplice, ma ti richiede di acquistare il doppio delle unità di cui avresti bisogno se non utilizzassi affatto il RAID, poiché la seconda unità è dedicata alla ridondanza. Il vantaggio è che hai la garanzia che ogni bit che scrivi su disco venga scritto due volte per la tua protezione. Quindi con il RAID 1 la nostra capacità si calcola come (n*s/2). Il RAID 1 soffre del fatto di fornire guadagni prestazionali minimi rispetto alle unità non RAID. Le velocità di scrittura sono equivalenti a quelle di un sistema non RAID, mentre le velocità di lettura sono quasi due volte più rapide nella maggior parte delle situazioni, poiché durante le operazioni di lettura le unità possono accedere in parallelo per aumentare il throughput. Il RAID 1 è limitato a set di due unità.

RAID 5: striping con parità singola; in questo tipo di RAID i dati vengono scritti in uno stripe complesso che attraversa tutte le unità dell'array, con un blocco di parità distribuito che esiste su tutte le unità. Così facendo, il RAID 5 è in grado di utilizzare un array di dimensioni arbitrarie composto da tre o più dischi e perde soltanto la capacità di archiviazione equivalente a un singolo disco a favore della parità, sebbene la parità sia distribuita e non risieda esclusivamente su un solo disco fisico. Il RAID 5 viene spesso utilizzato per la sua convenienza economica, dovuta alla scarsa perdita di capacità di archiviazione nei grandi array. A differenza del mirroring, lo striping con parità richiede che venga eseguito un calcolo per ogni stripe di scrittura attraverso i dischi, e questo genera un certo overhead. Pertanto il throughput non è sempre un calcolo immediato e dipende fortemente dalla potenza di calcolo del sistema che esegue il calcolo della parità. Calcolare la capacità del RAID 5 è piuttosto facile, poiché è semplicemente ((n-1)*s). Un array RAID 5 può sopravvivere alla perdita di un qualsiasi singolo disco dell'array.

RAID 6: striping ridondante con doppia parità. Il RAID 6 è praticamente identico al RAID 5, ma utilizza due blocchi di parità per stripe anziché uno, per consentire una protezione aggiuntiva contro il guasto dei dischi. Il RAID 6 è un membro più recente della famiglia RAID, essendo stato aggiunto diversi anni dopo che gli altri livelli erano stati standardizzati. Il RAID 6 è particolare in quanto consente il guasto di due unità qualsiasi all'interno di un array senza subire perdite di dati. Ma per garantire il livello aggiuntivo di ridondanza, un array RAID 6 perde la capacità di archiviazione equivalente a due unità dell'array e richiede un minimo di quattro unità. Possiamo calcolare la capacità di un array RAID 6 con ((n-2)*s).

RAID 10: mirroring più striping. Tecnicamente il RAID 10 è un tipo di RAID ibrido che comprende un insieme di mirror RAID 1 inseriti in uno stripe senza parità (RAID 0). Molti fornitori utilizzano il termine RAID 10 (o RAID 1+0) quando parlano di sole due unità in un array, ma tecnicamente quello è RAID 1, poiché lo striping non può avvenire finché non vi sono almeno quattro unità nell'array. Con il RAID 10 le unità devono essere aggiunte in coppie, perciò in un array può esistere solo un numero pari di unità. Il RAID 10 può sopravvivere alla perdita di un massimo della metà del set totale di unità, ma con una perdita massima di una unità per ciascuna coppia. Il RAID 10 non comporta un calcolo di parità, il che gli conferisce un vantaggio prestazionale rispetto al RAID 5 o al RAID 6 e richiede una minore potenza di calcolo per gestire l'array. Il RAID 10 offre le migliori prestazioni in lettura tra tutti i comuni tipi di RAID, poiché tutte le unità dell'array possono essere utilizzate simultaneamente nelle operazioni di lettura, sebbene le sue prestazioni in scrittura siano molto inferiori. Il calcolo della capacità del RAID 10 è identico a quello del RAID 1, (n*s/2).

Nell'azienda di oggi è raro che un reparto IT abbia una reale necessità di prendere in considerazione una configurazione di unità diversa dalle quattro qui menzionate, indipendentemente dal fatto che si stia implementando un RAID software o hardware. Tradizionalmente la principale preoccupazione nella scelta di un array RAID riguardava la capacità utilizzabile. Questo perché le unità erano costose e di piccole dimensioni. Oggi le unità sono così grandi che la capacità di archiviazione è raramente un problema, almeno non come lo era solo pochi anni fa, e i costi sono scesi a tal punto che l'acquisto delle unità aggiuntive necessarie per una migliore ridondanza è generalmente una preoccupazione minore. Quando la capacità è un bene prezioso, il RAID 5 è una scelta popolare perché perde la minima capacità di archiviazione rispetto agli altri tipi di array e, nei grandi array, la perdita di archiviazione è irrisoria.

Oggi abbiamo in genere altre preoccupazioni, principalmente la sicurezza dei dati e le prestazioni. Spendere un po' di più per garantire la protezione dei dati dovrebbe essere una scelta ovvia. Il RAID 5 soffre del fatto di poter perdere una sola unità. In un array di soli tre membri, questo è solo leggermente più rischioso della protezione offerta dal RAID 1. Potremmo sopravvivere alla perdita di una qualsiasi unità su tre. Niente di troppo preoccupante rispetto a perdere una delle due unità. Ma che dire di un grande array, diciamo di sedici unità? Poter perdere in sicurezza solo una unità su sedici dovrebbe farci interrogare un po' più a fondo sulla nostra affidabilità.

È qui che il RAID 6 è intervenuto per colmare la lacuna. Il RAID 6, quando utilizzato in un grande array, introduce una perdita molto contenuta di capacità di archiviazione e di prestazioni, fornendo al contempo la garanzia di poter perdere due unità qualsiasi. I sostenitori della corrente dello striping con parità citano spesso questi numeri per rassicurare la dirigenza sul fatto che il RAID 5/6 può offrire un adeguato “rapporto qualità-prezzo” nei sottosistemi di archiviazione, ma vi sono altri fattori in gioco.

Quasi del tutto trascurata nelle discussioni sull'affidabilità del RAID, argomento già di per sé discusso fin troppo di rado, è la questione dell'affidabilità del calcolo della parità. Con il RAID 1 o il RAID 10 non viene eseguito alcun “calcolo” per creare uno stripe con parità. I dati vengono semplicemente scritti in modo stabile. Quando un'unità si guasta, la sua partner si fa carico del lavoro e le prestazioni dell'unità risultano leggermente degradate finché la partner non viene sostituita. Non vi è alcun processo di ricostruzione che incida sui membri esistenti dell'unità. Non così con gli stripe di parità.

Gli array RAID con parità prevedono operazioni che comportano il calcolo di ciò che è e di ciò che dovrebbe trovarsi sulle unità. Sebbene questo calcolo sia molto semplice, esso offre l'occasione perché qualcosa vada storto. Un controllo dell'array che si guasta con il RAID 1 o il RAID 10 potrebbe, in teoria, scrivere dati errati sopra il contenuto delle unità, ma non esiste alcun processo mediante il quale il controller apporti modifiche alle unità di propria iniziativa, perciò è estremamente improbabile che ciò accada, dal momento che non vi è mai un processo di “ricostruzione” se non nella creazione di un mirror.

Quando gli array con parità eseguono un'operazione di ricostruzione, mettono in atto un processo complesso mediante il quale scorrono l'intero contenuto dell'array e riscrivono i dati mancanti sull'unità sostituita. Di per sé questo è relativamente semplice e non dovrebbe destare alcuna preoccupazione. Ciò che io e altri abbiamo constatato in prima persona è uno scenario leggermente diverso, che coinvolge dischi che hanno perso la connettività a causa di connettori allentati verso l'array. Le unità possono comunemente “allentarsi” con il tempo mentre risiedono in un server, soprattutto dopo diversi anni di servizio in un sistema sempre acceso.

Ciò che può accadere, in scenari estremi, è che i dati validi sulle unità vengano sovrascritti da dati di parità errati quando un controller dell'array ritiene che una o più unità si siano guastate in successione e siano state riportate online per la ricostruzione. In questo caso le unità stesse non si sono guastate e non vi è alcuna perdita di dati. Tutto ciò che è richiesto è che le unità vengano reinserite, in teoria. Sui sistemi hot swap la gestione della ricostruzione delle unità è spesso automatica, basata sulla rimozione e sostituzione di un'unità guasta. Pertanto questo processo di perdita e sostituzione di un'unità può avvenire senza alcun intervento umano – e può avere inizio un processo di ricostruzione. Durante questo processo il sistema di unità è a rischio e, qualora questo stesso evento dovesse verificarsi di nuovo, l'array di unità potrebbe, in base allo stato delle unità, iniziare a effettuare lo striping di dati errati attraverso le unità, sovrascrivendo il filesystem valido. È una delle visioni più sconfortanti per un amministratore di server: vedere un sistema senza alcuna unità guasta perdere un intero array a causa di un'inutile operazione di ricostruzione.

In teoria questo tipo di situazione non dovrebbe verificarsi e sono presenti delle salvaguardie per proteggere da essa, ma la determinazione da parte di un controller di unità di basso livello dello stato di un'unità, attuale e precedente, e della qualità dei dati che risiedono su tale unità non è così semplice come può sembrare, ed è possibile che si verifichino errori. Sebbene questa situazione sia improbabile, essa accade e aggiunge un rischio pressoché impossibile da calcolare ai sistemi RAID 5 e RAID 6. Dobbiamo considerare il rischio di guasto della parità in aggiunta al rischio tradizionale calcolato a partire dal numero di perdite di unità a cui un array può sopravvivere all'interno di un pool. Man mano che le unità diventano più affidabili, la rilevanza dell'evento di rischio di guasto della parità diventa maggiore.

Inoltre, la parità del RAID 5 e del RAID 6 introduce un overhead di sistema dovuto al calcolo della parità, che viene spesso gestito tramite hardware RAID dedicato. Questo calcolo introduce una latenza nel sottosistema delle unità che varia notevolmente a seconda dell'implementazione, sia hardware sia software, rendendo impossibile dichiarare i numeri prestazionali dei livelli RAID l'uno rispetto all'altro, poiché ogni implementazione sarà unica.

Probabilmente il problema più grande nella scelta del RAID oggi è che la facilità con cui si possono ottenere le metriche relative all'efficienza di archiviazione e alla sopravvivenza alla perdita delle unità maschera il quadro generale dell'affidabilità e delle prestazioni, dal momento che quelle statistiche sono quasi del tutto indisponibili. Uno dei pericoli delle metriche è che le persone si concentrano sui fattori che possono essere facilmente misurati e ignorano quelli che non possono essere facilmente misurati, indipendentemente dal loro potenziale impatto.

Sebbene tutti i moderni livelli RAID abbiano la loro collocazione, è fondamentale che vengano considerati nel loro contesto e con la consapevolezza dell'intera portata dei rischi. Dovremmo impegnarci a fondo per spostare il nostro settore da un'impostazione predefinita basata sul RAID 5 a una basata sul RAID 10. Le unità costano poco e la perdita di dati costa cara.

[Nota: negli anni trascorsi da quando questo articolo è stato scritto inizialmente, l'aumento dei rischi legati agli URE (Unrecoverable Read Errors) durante un'operazione di ricostruzione ha spostato i rischi principali da quelli elencati a quelli legati agli URE per gli array con parità.]