Hot Spare o Hot Mess

Un approccio comune per aggiungere un livello di sicurezza al RAID consiste nel disporre di unità di scorta in modo da ridurre al minimo il tempo di sostituzione di un'unità guasta. La forma più estrema di questo approccio è quella che viene definita “hot spare” – un'unità di scorta effettivamente presente nell'array ma inutilizzata fino a quando l'array non rileva il guasto di un'unità, momento in cui il sistema disabilita automaticamente l'unità guasta e abilita la hot spare, esattamente come se un essere umano avesse appena estratto un'unità dall'array e inserito l'altra, consentendo l'avvio di un'operazione di resilvering (una ricostruzione dell'array) il prima possibile. Questo può ridurre il tempo necessario per sostituire un'unità da ore o giorni a secondi e, in teoria, può fornire un incremento estremo della sicurezza.

Innanzitutto, vorrei affrontare quello che personalmente ritengo essere un errore nelle convenzioni di denominazione. Ciò che chiamiamo hot spare dovrebbe, a mio avviso, essere in realtà chiamato warm spare, perché è lì pronto all'uso ma non contiene i dati necessari per essere utilizzato immediatamente. Un'unità di scorta conservata al di fuori dello chassis, che richiede l'intervento di un essere umano per scambiare manualmente le unità, sarebbe una cold spare. Per essere veramente una hot spare, un'unità dovrebbe essere piena di dati e, di conseguenza, sarebbe un membro partecipante dell'array RAID in qualche modo. Red Hat ha un buon articolo su come questa terminologia si applica ai siti di disaster recovery come riferimento. Questa distinzione è importante perché ciò che chiamiamo hot spare non contiene già dati e non subentra immediatamente per sostituire l'unità guasta, ma subentra invece per avviare immediatamente il processo di ripristino dell'unità persa – una distinzione fondamentale.

Per mantenere i concetti chiari, d'ora in poi mi riferirò a ciò che i fornitori chiamano hot spare come “warm spare.” Questo avrà presto un senso.

Ci sono due preoccupazioni principali con le warm spare. La prima è la natura inefficace della warm spare nella maggior parte dei casi d'uso e la seconda è il rischio di “distruzione automatizzata dell'array.”

La maggior parte delle persone affronta il concetto di warm spare come mezzo per mitigare l'elevato rischio di guasto di un'unità secondaria in un array RAID 5 con parità. Gli array RAID 5 proteggono solo contro il guasto di un singolo disco all'interno dell'array. Una volta che un singolo disco si è guastato, l'array rimane privo di qualsiasi forma di parità e qualsiasi ulteriore guasto di un'unità comporta la perdita totale dell'array. Il RAID 5 viene scelto perché ha un costo molto basso per la capacità offerta e sacrifica l'affidabilità per ottenere questa convenienza economica. Poiché il RAID 5 è quindi rischioso rispetto ad altre opzioni RAID, come il RAID 6 o il RAID 10, è comune implementare una warm spare per ridurre al minimo il tempo in cui l'array rimane in uno stato degradato, consentendogli di iniziare il resilvering il più rapidamente possibile.

Quindi la conclusione più rilevante qui è che le warm spare vengono generalmente utilizzate come tampone contro l'uso di tipi di array RAID meno affidabili come misura di risparmio sui costi. Le warm spare sono molto più comuni negli array RAID 5, seguiti dagli array RAID 6. Entrambi vengono scelti rispetto al RAID 10 a causa del costo per la capacità, non per l'affidabilità o le prestazioni. C'è un caso in cui l'idea della warm spare ha davvero senso per una maggiore affidabilità, ed è il RAID 10 con una warm spare, ma ci arriveremo. Al di fuori di questo scenario, ritengo che le warm spare abbiano poco senso nel mondo reale.

Inizieremo esaminando il RAID 1 con una warm spare. Il RAID 1 consiste in due o più unità in mirroring. Aggiungere una warm spare è positivo perché, se una delle coppie in mirroring si guasta, la warm spare inizierà immediatamente a eseguire il mirroring dell'unità rimanente e sarai nuovamente protetto in breve tempo. Questo è meraviglioso. Tranne per un piccolo difetto: invece di utilizzare una warm spare, quella stessa unità avrebbe potuto essere aggiunta fin dall'inizio all'array RAID 1, dove sarebbe stata un mirror terziario. In questa funzione di mirror terziario, l'unità avrebbe contribuito alle prestazioni complessive dell'array, offrendo un incremento delle prestazioni di lettura di quasi il cinquanta percento, mantenendo invariate le prestazioni di scrittura e fornendo una protezione istantanea in caso di guasto di un'unità anziché una protezione “non appena viene rieseguito il mirroring.” In sostanza, sarebbe stata una vera “hot spare” anziché una warm spare. Quindi, senza spendere un centesimo in più, il sistema avrebbe avuto migliori prestazioni dell'array di unità e una migliore affidabilità semplicemente avendo l'unità aggiuntiva in una funzione attiva “nell'array” anziché ferma e inattiva in attesa che si verificasse il disastro.

Con il RAID 5 vediamo un avvertimento ancora più evidente contro il concetto di warm spare, proprio qui dove è più comune che altrove. Il RAID 5 è un RAID a parità singola con la capacità di ricostruire, utilizzando la parità, qualsiasi unità dell'array che si guasta. È qui che iniziano i veri problemi. A differenza del RAID 1, dove un'operazione di rimirroring potrebbe essere piuttosto rapida, un resilver (ricostruzione) del RAID 5 ha il potenziale di richiedere molto tempo. La warm spare non aiuterà a proteggere l'array fino al completamento con successo di questo processo di resilver – che richiede comunemente molte ore e facilmente giorni e possibilmente settimane o mesi, a seconda delle dimensioni dell'array e di quanto sia impegnato. Se prendessimo quella stessa unità warm spare e la assegnassimo invece a essere un membro dell'array con una stripe di parità aggiuntiva, otterremmo il RAID 6. Lo stesso insieme di unità che abbiamo per il RAID 5 più la warm spare creerebbe un array RAID 6 della stessa identica capacità. Anche in questo caso, come nell'esempio del RAID 1 sopra, questo sarebbe molto simile ad avere una hot spare, dove l'unità partecipa all'array con dati attivi anziché rimanere inattiva in attesa che un'altra unità si guasti prima di entrare in azione per iniziare il processo di subentro. In questa funzione, l'array si degrada all'equivalente di un RAID 5 in caso di guasto ma senza alcun tempo di ricostruzione, quindi l'unità aggiuntiva è utile immediatamente anziché solo dopo un processo di resilver possibilmente molto lungo. Quindi, a parità di spesa e di capacità, la scelta di configurare le unità in RAID 6 anziché in RAID 5 più warm spare è una vittoria completa.

Possiamo continuare questo esempio con il RAID 6 più warm spare. Questo è un po' meno facile da definire perché nella maggior parte dei sistemi RAID, ad eccezione del piuttosto raro RAIDZ3 di ZFS, non esiste un sistema a tripla parità disponibile un gradino sopra il RAID 6 (immaginate se ci fosse un RAID 7, per esempio). Se esistesse, l'esatto argomento esposto per il RAID 5 più warm spare si applicherebbe al RAID 6 più warm spare. Nella maggior parte dei casi, il RAID 6 con una warm spare deve giustificarsi rispetto a un array RAID 10. Il RAID 10 è più performante e di gran lunga più affidabile di un array RAID 6, ma il RAID 6 viene generalmente scelto per risparmiare denaro rispetto al RAID 10. Ma per compensare la fragilità del RAID 6 vengono talvolta impiegate le warm spare. In alcuni casi, come un piccolo array RAID 6 a cinque dischi con una warm spare, questo è dollaro per dollaro equivalente a un array RAID 10 a sei dischi senza warm spare. Negli array più grandi il vantaggio in termini di costi del RAID 6 diventa evidente, ma maggiore è il risparmio sui costi, maggiore è il differenziale di rischio, poiché i sistemi RAID a parità aumentano il rischio con le dimensioni dell'array molto più rapidamente rispetto ai sistemi RAID basati sul mirroring come il RAID 10. Qualsiasi denaro risparmiato oggi viene fatto a rischio di interruzione o perdita di dati domani.

Il caso in cui una warm spare entra in gioco efficacemente è in un array RAID 10, dove la ricostruzione di una warm spare è una ricostruzione di mirror, come nel RAID 1, che non comporta rischi di parità, e dove non esiste un'estensione logica del sistema RAID al di sopra del RAID 10 dal quale stiamo cercando di risparmiare denaro optando per un sistema più fragile. Qui aggiungere una warm spare può avere senso per array critici, perché non esiste un modo più conveniente per ottenere la stessa affidabilità aggiuntiva. Tuttavia, il RAID 10 è così affidabile anche senza una warm spare che qualsiasi azienda che stia considerando il RAID 5 o il RAID 6 con una warm spare si fermerebbe logicamente al semplice RAID 10, avendo già superato l'affidabilità per la quale si stava accontentando in precedenza. Quindi solo le aziende che non stanno considerando quei sistemi più fragili e che cercano l'opzione più robusta possibile guarderebbero logicamente al RAID 10 più warm spare come loro soluzione.

Solo per accuratezza tecnica, il RAID 10 può essere espanso per ottenere migliori prestazioni di lettura e un drastico miglioramento dell'affidabilità (ma con un aumento dei costi del cinquanta percento) passando a mirror RAID 1 a tre dischi nella sua stripe RAID 0 anziché ai mirror RAID 1 standard a due dischi, proprio come abbiamo mostrato nel nostro esempio del RAID 1. Questo è un livello di affidabilità raramente ricercato nel mondo reale, ma può esistere ed è un'opzione. Normalmente questo è limitato dalle restrizioni sul numero di unità negli chassis fisici degli array, oltre a competere male con la costruzione di un array RAID 10 secondario completamente separato in un diverso chassis e il successivo mirroring di questi a un livello superiore, creando di fatto il RAID 101 – che è il risultato effettivo dei comuni cluster di array di storage di fascia alta odierni.

La nostra seconda preoccupazione è quella della “distruzione automatizzata dell'array.” Questo si applica solo agli scenari di RAID a parità di RAID 5 e RAID 6 (o ai rari RAID 2, RAID 3, RAID 4 e RAIDZ3). Con il concetto di warm spare, l'idea è che quando un'unità si guasta, la warm spare viene scambiata automaticamente e istantaneamente dal controller dell'array e il processo di resilvering dell'array inizia immediatamente. Se il resilvering fosse un processo completamente affidabile, questo sarebbe ovviamente molto gradito. La realtà è, purtroppo, ben diversa.

Durante un processo di resilver, un array RAID a parità è a rischio del manifestarsi di errori di lettura irrecuperabili (URE). Se un URE si verifica durante un resilver di un RAID a parità singola (cioè RAID 2 – 5), allora il processo di resilvering fallisce e l'array viene perso completamente. Questo è fondamentale da capire perché nessun'unità aggiuntiva si è guastata. Quindi, se la warm spare non fosse stata presente, il resilvering non sarebbe iniziato e i dati sarebbero ancora intatti e disponibili – solo non così rapidamente come al solito e con il piccolo rischio di un guasto di un'unità secondaria. I tassi di URE sono molto elevati con i grandi dischi odierni e con i grandi array i rischi possono diventare così alti da passare da “possibile” a “previsto” durante una normale operazione di resilvering.

Quindi in molti casi la warm spare stessa potrebbe in realtà essere l'innesco della perdita di dati anziché il salvatore dei dati come ci si aspetta. Un array che sarebbe sopravvissuto potrebbe essere distrutto dal processo di resilvering prima ancora che l'essere umano che lo gestisce venga avvisato del guasto della prima unità. Se un essere umano fosse stato coinvolto, avrebbe potuto, come minimo, compiere il passo di effettuare un nuovo backup dell'array prima di avviare il resilver, sapendo che la copia più recente dei dati sarebbe stata disponibile nel caso in cui il processo di resilver non avesse avuto successo. Avrebbe inoltre permesso all'essere umano di pianificare quando avviare il resilver, magari aspettando la fine dell'orario lavorativo o l'inizio del fine settimana, quando è meno probabile che l'array subisca un carico pesante.

Il RAID a doppia e tripla parità (rispettivamente RAID 6 e RAIDZ3) condividono anch'essi i rischi di URE, dato che anch'essi si basano sulla parità. Mitigano questo rischio attraverso i livelli aggiuntivi di parità e lo fanno con successo per la maggior parte. Il rischio esiste ancora, specialmente in array RAID 6 molto grandi, ma per i prossimi diversi anni i rischi rimangono generalmente piuttosto bassi per la maggior parte degli array di storage, finché non saranno disponibili sul mercato supporti di archiviazione basati su spindle di dimensioni molto maggiori.

Il problema più grande del RAID a parità e del rischio di URE è che il fattore che spinge verso il RAID a parità (la disponibilità ad affrontare ulteriori rischi per l'integrità dei dati al fine di ridurre i costi) è lo stesso fattore che introduce un rischio di URE accresciuto (l'acquisto di dischi rigidi SATA a basso costo, non enterprise). Le aziende che si trovano ad affrontare il RAID a parità generalmente lo fanno con dischi SATA grandi e a basso costo, riunendo due fattori molto pericolosi in una combinazione esplosiva. L'utilizzo di RAID 1 o RAID 10 non a parità eliminerà completamente il problema, e l'utilizzo di dischi SAS enterprise altamente affidabili ridurrà drasticamente il fattore di rischio di un ordine di grandezza (non è un modo di dire, si tratta effettivamente di un cambiamento di un ordine di grandezza).

Inoltre, durante le operazioni di resilver è possibile che le prestazioni si degradino sui sistemi a parità in modo così drastico da equivalere a un'interruzione a lungo termine. Il processo di resilver, specialmente su array di grandi dimensioni, può essere così intensivo che gli utenti finali non riescono a distinguere tra un array completamente guasto e un array in fase di resilvering. In effetti, il resilvering nei casi estremi può richiedere così tanto tempo ed essere così disruptivo che il costo per l'azienda può essere superiore a quello che si avrebbe se l'array si fosse semplicemente guastato completamente e si fosse invece effettuato un ripristino dal backup. Questo problema di resilver non riguarda il RAID 1 e il RAID 10, ancora una volta, perché sono sistemi RAID in mirroring, non a parità, e il loro processo di resilver è banale e il degrado delle prestazioni del sistema è minimo e di breve durata. Nel suo caso più estremo, un resilver a parità potrebbe richiedere settimane o mesi, durante i quali i sistemi si comportano come se fossero offline – e in qualsiasi momento durante questo processo c'è il potenziale per il manifestarsi degli errori URE menzionati sopra, che porrebbero fine al resilver e costringerebbero comunque al ripristino dal backup. (I resilver tipici non richiedono settimane, ma richiedono molte ore e che richiedano giorni non è affatto raro.)

La nostra panoramica finale può essere riassunta come segue (con il termine convenzionale “hot spare” usato di nuovo): Il RAID 10 senza una “hot spare” è quasi sempre una scelta migliore del RAID 6 con una “hot spare.” Il RAID 6 senza una “hot spare” è sempre migliore del RAID 5 con una “hot spare.” Il RAID 1 con un membro mirror aggiuntivo è sempre migliore del RAID 1 con una “hot spare.” Quindi, qualunque sia il livello RAID con una hot spare che decidete di adottare, salite semplicemente di un livello di affidabilità RAID ed eliminate la “hot spare” per massimizzare sia le prestazioni che l'affidabilità a un costo uguale o quasi uguale.

Le warm spare, come il RAID a parità, hanno avuto il loro momento di gloria. In effetti, è stato quando il RAID a parità aveva ancora senso per un uso diffuso – quando gli errori URE erano improbabili e i costi dei dischi erano elevati – che anche le unità warm spare avevano senso. Erano ben abbinate: quando una aveva senso, spesso lo aveva anche l'altra. Ciò che viene spesso trascurato è che, man mano che il RAID a parità, specialmente il RAID 5, ha perso efficacia, ha trascinato con sé la warm spare in modi inaspettati.