Quando l'assenza di ridondanza è più affidabile – Il mito della ridondanza

Il rischio è un concetto difficile e richiede molta formazione, riflessione e analisi per valutare correttamente determinati scenari. Spesso, poiché le valutazioni del rischio sono così difficili, sostituiamo l'analisi del rischio aggiungendo semplicemente una ridondanza di base e presumendo di aver mitigato adeguatamente il rischio. Ma molto spesso non è così. L'introduzione di complessità o di ulteriori modalità di guasto spesso accompagna l'aggiunta di ridondanza e queste nuove forme di guasto hanno il potenziale di aggiungere più rischio di quanto la ridondanza aggiunta ne rimuova. I sistemi di storage sono particolarmente soggetti a questi processi decisionali, il che è un peccato, dato che pochi sistemi, semmai, sono così suscettibili ai guasti e più importanti da proteggere.

Il RAID è un ottimo esempio di come la mancanza di un pensiero olistico sul rischio possa portare ad alcune decisioni strane. Se guardiamo a uno scenario non poco comune, vedremo dove l'obiettivo di proteggersi dal guasto di un'unità può effettivamente portare a un aumento del rischio anche quando viene applicata una ridondanza aggiuntiva. In questo scenario confronteremo un array di dodici unità composto da dodici dischi rigidi SATA da tre terabyte in un singolo array. Non è raro sentire di persone che scelgono il RAID 5 per questo scenario per ottenere “massima capacità e prestazioni” pur avendo una “protezione adeguata contro i guasti.”

L'idea qui è che il RAID 5 protegge contro la perdita di una singola unità che può essere sostituita e l'array si ricostruirà prima che una seconda unità si guasti. Questo è ottimo in teoria, ma i veri rischi di un array di queste dimensioni, trentasei terabyte di capacità di archiviazione, non derivano da guasti multipli delle unità, come generalmente si sospetta, ma dall'incapacità di ricostruire in modo affidabile l'array dopo il guasto di una singola unità o da un guasto dell'array stesso senza che nessuna singola unità si guasti. Il rischio che una seconda unità si guasti è basso, non inesistente, ma piuttosto basso. Le unità odierne sono altamente affidabili. Una volta che un'unità si guasta, aumenta effettivamente la probabilità che una seconda unità si guasti, il che è ben documentato, ma non voglio che questo rischio ci distolga dall'osservare i veri rischi – il rischio di un'operazione di resilvering fallita.

Ciò che ci spaventa durante un'operazione di resilver del RAID 5 è che può verificarsi un errore di lettura irrecuperabile (URE). Quando ciò accade, l'operazione di resilver si arresta e l'array rimane in uno stato inutilizzabile – tutti i dati sull'array sono persi. Sui comuni dischi SATA il tasso di URE è 10^14, ovvero una volta ogni dodici terabyte di operazioni di lettura. Ciò significa che un array da sei terabyte sottoposto a resilvering ha una probabilità di circa il cinquanta percento di incontrare un URE e fallire. Una probabilità di guasto del cinquanta percento è follemente alta. Immaginate se la vostra auto avesse una probabilità del cinquanta percento che le ruote si stacchino ogni volta che la guidate. Quindi con un piccolo (per gli standard odierni) array RAID 5 da sei terabyte che utilizza dischi SATA con URE di 10^14, se dovessimo perdere una singola unità, abbiamo solo una probabilità del cinquanta percento che l'array si ripristini, presumendo che l'unità venga sostituita immediatamente. Questo non include il rischio che una seconda unità si guasti, solo il rischio di un guasto da URE. Presuppone inoltre che l'unità sia completamente inattiva a parte l'operazione di resilver. Se le unità sono impegnate a essere utilizzate per altri compiti allo stesso tempo, allora le probabilità che accada qualcosa di brutto, sia un URE sia il guasto di una seconda unità, iniziano ad aumentare drasticamente.

Con un array da dodici terabyte le probabilità di perdita totale dei dati durante un'operazione di resilver iniziano ad avvicinarsi al cento percento – il che significa che il RAID 5 non ha alcuna funzionalità in quel caso. C'è sempre una possibilità di sopravvivenza, ma è molto bassa. A sei terabyte si può paragonare un'operazione di resilver a una partita di roulette russa con un proiettile e sei camere, e si deve premere il grilletto tre volte. Con dodici terabyte si deve premere sei volte! Non sono buone probabilità.

Ma non stiamo parlando di un array da dodici terabyte. Stiamo parlando di un array da trentasei terabyte – che suona grande, ma è una dimensione che oggi qualcuno potrebbe tranquillamente avere a casa, per non parlare di un'azienda. Ogni grande produttore di server, così come quasi tutti i fornitori di storage a basso costo, realizzano oggi sistemi di storage sotto i 10.000 dollari in questa fascia di capacità. Il resilvering di un array RAID 5 con il guasto di una singola unità su un array da trentasei terabyte è come giocare alla roulette russa, un proiettile, sei camere, e premere il grilletto diciotto volte! I vostri dati non hanno molte possibilità. Aggiungete a questo l'incredibile quantità di tempo necessaria per il resilvering di un array di quelle dimensioni e il rischio che un secondo disco si guasti durante quella finestra di resilver inizia a diventare una minaccia piuttosto significativa. Ho visto stime di tempi di resilver che arrivano a settimane o mesi su alcuni sistemi. È un lungo periodo per funzionare senza poter perdere un'altra unità. Quando parliamo di ore o giorni i rischi sono piuttosto bassi, ma comunque presenti. Quando parliamo di settimane o mesi di sollecitazione continua, dato che le operazioni di resilver sono estremamente intensive per le unità, i tassi di guasto aumentano drasticamente.

Con un array di queste dimensioni possiamo effettivamente presumere che la perdita di una singola unità significhi la perdita dell'intero array, lasciandoci senza alcuna protezione contro il guasto delle unità. Ora, se consideriamo un'unità di prestazioni uguali o migliori con capacità uguale o migliore in RAID 0, che anch'esso non ha protezione contro la perdita di unità, dobbiamo utilizzare solo undici delle stesse unità di cui ne avevamo bisogno di dodici per il nostro array RAID 5. Ciò significa che invece di dodici dischi rigidi, ciascuno dei quali ha una probabilità di circa il tre percento di guasto annuale, ne abbiamo solo undici. Questo da solo rende il nostro array RAID 0 più affidabile, dato che ci sono meno unità che possono guastarsi. Non solo abbiamo meno unità, ma non c'è bisogno di scrivere il blocco di parità né di saltare i blocchi di parità durante la lettura, riducendo, anche se in modo lievissimo, l'usura meccanica dell'array RAID 0 a parità di utilizzo, conferendogli un piccolissimo vantaggio aggiuntivo in termini di affidabilità. L'array RAID 0 di undici unità sarà identico in capacità all'array RAID 5 di dodici unità, ma avrà un throughput e una latenza leggermente migliori. Una vittoria su tutta la linea. In più il risparmio sui costi di non aver bisogno di un'unità aggiuntiva.

Quindi quello che vediamo qui è che negli array di grandi dimensioni (grandi in capacità, non in numero di spindle) il RAID 0 supera effettivamente il RAID 5 in determinati scenari. Quando si utilizzano i comuni dischi SATA, questo accade a capacità riscontrate anche dai power user a casa e da molte piccole aziende. Se passiamo a dischi SATA enterprise o a dischi SAS, allora il valore di capacità al quale ciò si verifica diventa molto alto e non è una preoccupazione oggi, ma lo sarà tra qualche anno, quando le capacità delle unità diventeranno ancora più grandi. Ma questo evidenzia quanto sia pericoloso il RAID 5 nelle dimensioni che vediamo oggi. Tutti comprendono gli incredibili rischi del RAID 0, ma può essere difficile mettere in prospettiva che i problemi del RAID 5 sono così estremi da poter effettivamente renderlo meno affidabile del RAID 0.

Il fatto che il RAID 5 possa essere meno affidabile del RAID 0 in un array di queste dimensioni sulla base delle sole operazioni di resilver è solo l'inizio. In un array massiccio come questo, il tempo di resilver può richiedere così tanto tempo ed esigere un tale tributo dalle unità che anche il guasto di una seconda unità inizia a diventare un rischio misurabile. E poi ci sono ulteriori rischi causati da errori del controller dell'array che possono utilizzare gli algoritmi di resilver per distruggere un intero array anche quando non si è verificato alcun guasto di un'unità. Poiché il RAID 0 (o il RAID 1 o il RAID 10) non hanno algoritmi di resilver, non soffrono di questo rischio aggiuntivo. Questi sono rischi difficili da quantificare, ma ciò che è importante è che si tratta di rischi aggiuntivi che si accumulano quando si utilizza un sistema più complesso, laddove un sistema più semplice, senza la ridondanza, era più affidabile fin dall'inizio.

Ora che abbiamo stabilito che il RAID 5 può essere meno affidabile del RAID 0, sottolineerò gli ovvi pericoli del RAID 0. Il RAID in generale viene utilizzato per mitigare il rischio che un singolo, solitario disco rigido si guasti. Tutti temiamo che un singolo disco si guasti semplicemente e che tutti i dati vadano persi. Il RAID 0, essendo un grande stripe di unità senza alcuna forma di ridondanza, prende il rischio di perdita di dati di un singolo disco che si guasta e lo moltiplica su un certo numero di unità, dove il guasto di una qualsiasi unità causa la perdita totale dei dati di tutte le unità. Quindi nel nostro esempio di undici dischi sopra, se uno qualsiasi degli undici dischi si guasta, tutto è perso. È chiaro vedere quanto questo sia drasticamente più pericoloso del semplice utilizzo di una singola unità, da sola.

Ciò che sto cercando di sottolineare qui è che la ridondanza non significa affidabilità. Solo perché qualcosa è ridondante, come il RAID 5, non fornisce alcuna garanzia che sarà sempre più affidabile di qualcosa che non è ridondante.

La mia analogia preferita qui è quella di guardare alle case durante un tornado. In uno scenario costruiamo una casa di mattoni e malta. Nel secondo scenario costruiamo due case ridondanti, fatte di paglia (i nostri costruttori sono maiali, a quanto pare). Quando arriva il tornado (o il lupo cattivo), quale è più probabile che ci lasci con una casa in piedi? Chiaramente una casa di mattoni e malta ha alcuni significativi vantaggi di affidabilità rispetto a case di paglia ridondanti. La ridondanza non contava, alla fine contava l'affidabilità.

La ridondanza è spesso fuorviante perché è facile da quantificare ma difficile da qualificare. La ridondanza è una domanda in bianco e nero: è ridondante? Sì o no. Semplice. L'affidabilità non è così semplice. L'affidabilità riguarda i tassi di guasto e le probabilità. Riguarda le statistiche e l'analisi. Poiché è difficile quantificare l'affidabilità in modo significativo, specialmente quando si vende un progetto ai responsabili aziendali, la ridondanza diventa spesso un semplice sostituto di questo concetto complesso.

Il concetto di utilizzare la ridondanza per deviare le questioni di affidabilità finisce anche per applicarsi ai sottosistemi in modi molto contorti. Invece di rendere ridondante un “sistema”, è diventato comune rendere ridondante un sottosistema altamente affidabile e a basso costo e trattare la ridondanza del sottosistema come se si applicasse all'intero sistema. L'esempio più comune di questo sono i controller RAID nei prodotti SAN. Anziché avere una SAN ridondante (cioè due SAN), i produttori spesso rendono ridondante quell'unico componente non spesso ridondante nei server normali e poi chiamano la SAN ridondante – intendendo una SAN che contiene ridondanza, il che non è affatto la stessa cosa.

Una buona analogia qui sarebbe confrontare l'avere automobili ridondanti, cioè due automobili complete e funzionanti, con l'avere una singola automobile con una pompa dell'acqua di scorta nel bagagliaio nel caso quella principale si guasti. Chiaramente, una pompa dell'acqua di scorta non è una cosa negativa. Ma è anche una protezione banale contro il guasto dell'automobile rispetto all'avere una seconda automobile pronta a partire. In un caso l'intero sistema è ridondante, incluso il telaio. Nell'altro stiamo rendendo ridondante un solo componente, altamente affidabile, all'interno del telaio. Non è nemmeno alla pari con l'avere una ruota di scorta che, almeno, è un componente dell'auto con una maggiore probabilità di guasto.

Proprio come il mito dell'affidabilità del RAID 5 e dell'affidabilità del sistema/sottosistema, le tecnologie di storage condiviso come le SAN e i NAS vengono spesso trattate allo stesso modo, specialmente per quanto riguarda la virtualizzazione. C'è uno scenario comune in cui viene intrapreso un progetto di virtualizzazione e le persone si fanno prendere istintivamente dal panico perché un singolo host di virtualizzazione rappresenta un singolo punto di guasto in cui, se si guasta, molti sistemi si guasteranno tutti contemporaneamente.

L'uso del termine “singolo punto di guasto” provoca una sensazione di panico ed è un ottimo mezzo per orientare una conversazione. Ma un SPOF, come ci piace chiamarlo, pur essendo qualcosa che ci piace rimuovere quando possibile, potrebbe non essere la fine del mondo. Pensate alla nostra casa di mattoni. È un SPOF. Le nostre due case di paglia non lo sono. Eppure una singola brezza abbatte le nostre soluzioni ridondanti più rapidamente del nostro affidabile SPOF. Cercare gli SPOF è un ottimo modo per trovare i punti di fragilità in un sistema, ma non pensate che ogni SPOF debba essere reso ridondante in ogni scenario. La maggior parte delle aziende troverà il suo miglior valore avendo molti SPOF in atto. Il nostro vero obiettivo è l'affidabilità a un costo appropriato; la ridondanza, come abbiamo visto, non è un sostituto dell'affidabilità, è semplicemente uno strumento che possiamo usare per raggiungere l'affidabilità.

La teoria che molte persone seguono quando virtualizzano è quella di prendere il loro host di virtualizzazione e dire “Questo host è un SPOF, quindi ne devo avere due e usare le funzionalità di High Availability per consentire un failover trasparente!” Questo è stimolato dal principale fornitore di virtualizzazione che guadagna in primo luogo vendendo costosi prodotti aggiuntivi di HA e in secondo luogo essendo di proprietà di un grande fornitore di storage – quindi vendere storage condiviso aggiuntivo, non necessario o persino pericoloso, è una grande vittoria monetaria per loro e potrebbe facilmente essere il motivo per cui hanno promosso lo spazio della virtualizzazione fin dall'inizio. Host di virtualizzazione ridondanti con storage condiviso suona benissimo, ma può essere estremamente fuorviante per diverse ragioni.

La prima ragione è che la rimozione dello SPOF iniziale, l'host di virtualizzazione, viene sostituita con un nuovo SPOF, lo storage condiviso. Questo non ottiene nulla. Presumendo che stiamo utilizzando server e storage condiviso di qualità comparabile, tutto ciò che abbiamo fatto è spostare dove si trova il rischio, non cambiare quanto sia grande. La probabilità che il sistema di storage si guasti è all'incirca uguale alla probabilità che il server originale si guasti. Ma oltre a spostare lo SPOF qua e là come in un gioco delle tre carte, abbiamo anche fatto qualcosa di molto, molto peggiore – abbiamo introdotto dipendenze di guasto concatenate o a cascata.

Nel nostro scenario originale avevamo un singolo server. Se il server continuava a funzionare eravamo a posto, se si guastava non lo eravamo. Semplice. Ora abbiamo due host di virtualizzazione, un singolo server di storage (SAN, NAS, qualunque cosa) e una rete che li collega insieme. Abbiamo già stabilito che il rischio che lo storage condiviso si guasti è approssimativamente uguale al nostro rischio totale del sistema nello scenario originale. Ma ora abbiamo le dipendenze aggiuntive della rete e dei due nodi di virtualizzazione front end. Ciascuno di questi componenti è più affidabile del fragile storage condiviso (qualsiasi cosa con unità meccaniche sarà fragile), ma che siano a rischio inferiore non è il problema; il problema è che i rischi sono combinatori.

Se uno qualsiasi di questi tre componenti (storage, rete o i nodi front end) si guasta, allora tutto si guasta. La soluzione a questo è rendere lo storage condiviso ridondante per conto proprio e rendere la rete ridondante per conto proprio. Con sufficiente lavoro possiamo superare la fragilità e il rischio che abbiamo introdotto aggiungendo lo storage condiviso, ma lo storage condiviso di per sé non è una forma di mitigazione del rischio, bensì è esso stesso un rischio che deve essere mitigato. La spirale della complessità inizia e il costo associato al portare questo nuovo sistema a un livello pari all'affidabilità del sistema originale a server singolo può essere astronomico.

Ora che abbiamo tutta questa ridondanza, abbiamo un altro rischio di cui preoccuparci. Gestire tutta questa ridondanza, tutte queste parti in movimento, richiede molta più conoscenza, abilità e preparazione rispetto alla gestione di un semplice server singolo. Siamo passati da una soluzione semplice a una molto complessa. Nella mia esperienza aneddotica, i veri pericoli di soluzioni come questa non derivano dal guasto dell'hardware ma dall'errore umano. Non solo è stato fatto poco per evitare che l'errore umano causi il guasto di questo nuovo sistema, ma abbiamo aggiunto innumerevoli punti in cui un essere umano potrebbe accidentalmente far crollare l'intero sistema, ridondanza e tutto il resto. L'ho visto di prima mano; ho sentito le storie dell'orrore. Più complesso è il sistema, più è probabile che un essere umano rompa accidentalmente tutto.

È fondamentale che, come professionisti IT, facciamo un passo indietro e guardiamo ai sistemi completi e consideriamo l'affidabilità e il rischio, e pensiamo alla ridondanza semplicemente come a uno strumento da utilizzare nel perseguimento dell'affidabilità. La ridondanza di per sé non è una panacea. Né lo è la semplicità. L'affidabilità è un problema complesso da affrontare. Evitare le sostituzioni semplicistiche è un primo passo importante per passare dal nascondere i problemi di affidabilità all'affrontarli e risolverli.