Se un sistema RAID5 rileva un URE durante la ricostruzione, tutti i dati vengono persi?

23

Comprendo l'argomento riguardante la maggiore probabilità di unità URE di sperimentare un URE durante una ricostruzione, tuttavia non sono sicuro di quali siano le implicazioni effettive per questo. Questa risposta afferma che l'intera ricostruzione non riesce, ma ciò significa che tutti i dati sono inaccessibili? Perché dovrebbe essere? Sicuramente un singolo URE di un singolo settore sull'unità avrebbe un impatto sui dati relativi a pochi file, al massimo. L'array non sarebbe ancora ricostruito, solo con qualche piccola corruzione in pochi file?

(Sono particolarmente interessato all'implementazione di RAID5 di ZFS qui, ma la logica sembra la stessa per qualsiasi implementazione di RAID5.)

raid zfs zfsonlinux

— process91
fonte

1

In generale, quando "la probabilità di sperimentare un URE durante una ricostruzione " viene discussa nel contesto dei rischi RAID5, il presupposto implicito è che si è già verificata una corruzione precedente per rendere necessaria la ricostruzione. In altre parole, "URE durante la ricostruzione" è il secondo URE e in effetti TUTTI i dati andranno persi.

— Colt,

1

@Colt - Capisco che è l'implicazione, ma quello che non capisco è perché un singolo URE (che, nell'analisi del perché RAID5 non è raccomandato, sembra riferirsi a un settore danneggiato) significherebbe che tutti i dati sarebbero essere perso. In generale, se ho perso 1 unità di un array RAID5, ho ancora tutti i dati. Se perdo ulteriormente un singolo settore da una qualsiasi delle unità rimanenti, è possibile che io abbia perso i dati memorizzati in quel settore, ma se quel settore era (ad esempio) spazio libero, allora non mi interessa, e se quel settore c'erano dati su di esso, quindi potrebbe avere un impatto solo su alcuni file.

— process91,

@Colt - Sulla base delle risposte di seguito, sembra che non riuscire a ricostruire l'array in presenza di un singolo URE sia stata una scelta fatta dai produttori di hardware RAID. Secondo me, questa è stata la scelta sbagliata, ma per fortuna sembra che ZFS faccia diversamente.

— process91,

Vedi la risposta di @ shodanshok per il processo. Per quanto riguarda il motivo, RAID serve a fornire continuità di accesso a dati affidabili per altri processi, applicazioni, ecc. E non riguarda il backup. Il motivo per cui molti controller (la maggior parte?) Dell'hardware si interrompono una volta che l'URE si verifica durante la ricostruzione è che il RAID non può più fare ciò che dovrebbe fare . A questo punto, è necessario utilizzare i backup per disporre di dati affidabili. Un altro modo di utilizzare RAID è di non fare alcuna ricostruzione, ma semplicemente di utilizzare RAID per controllare i tempi di recupero dal backup. Inoltre, consente di eseguire il backup finale prima del ripristino.

— Colt,

Si noti che l'implementazione di "RAID5" di ZFS si chiama "raidz" o "zraid" ed è diversa dall'hardware RAID5. In genere otterrai risposte migliori su "ZFS RAID5" chiedendo "raidz"

— Josh,

24

Dipende molto dall'implementazione RAID specifica:

la maggior parte dell'hardware RAID interromperà la ricostruzione e alcuni contrassegneranno l'array come non riuscito , abbattendolo. La logica è che se si verifica un URE durante una ricostruzione RAID5 significa che alcuni dati vengono persi, quindi è meglio arrestare completamente l'array piuttosto che rischiare il danneggiamento silenzioso dei dati. Nota: alcuni RAID hardware (principalmente basati su LSI) forderanno invece l'array, consentendo la ricostruzione di procedere contrassegnando il settore interessato come illeggibile (simile a come si comporta RAID software Linux).
Il software RAID Linux può essere incaricato di a) interrompere la ricostruzione dell'array (l'unico comportamento delle build "antiche" di MDRAID / kernel) oppure b) continuare con il processo di ricostruzione contrassegnando alcuni LBA come cattivi / inaccessibili. La logica è che è meglio lasciare che l'utente faccia la sua scelta: dopotutto, un singolo URE può essere nello spazio libero, senza influire affatto sui dati (o interessare solo i file non importanti);
ZRAID mostrerà alcuni file come corrotti, ma continuerà con il processo di ricostruzione (vedi qui per un esempio). Ancora una volta, la logica è che è meglio continuare e riferire all'utente, consentendogli di fare una scelta informata.

— shodanshok
fonte

@ process91 Solo per elaborare un po 'di più. Se l'implementazione RAID non ha le strutture dati aggiuntive necessarie per contrassegnare i singoli settori come non validi, deve fallire la ricostruzione o introdurre la corruzione silenziosa. Contrassegnare i singoli settori come negativi è meglio, ma potrebbe comunque mettere a rischio altri settori a causa di quelli che condividono un settore di parità con il settore cattivo.

— Kasperd,

@kasperd Certo, suppongo di aver supposto che la maggior parte delle implementazioni RAID avesse la capacità di avvisare l'utente di settori danneggiati. Capisco se esiste un settore danneggiato in un'unità che porterà a un settore errato nella nuova unità dopo una ricostruzione. Detto questo, anche se l'implementazione RAID non ha fatto altro che avvisare l'utente "Ho ricostruito l'unità nel miglior modo possibile, ma ho sperimentato 1 URE nel processo" e poi ho continuato a consentire tentativi di scrittura in quel settore che non vedere come altri settori potrebbero essere a rischio. Gli unici possibili settori errati sarebbero l'originale, il nuovo e la parità.

— process91,

Un chiarimento, basato sui commenti di @Colt sopra - nel caso di RAID hardware, quando contrassegna l'array come non riuscito , consente comunque l'accesso ai dati? Anche, diciamo, accesso di sola lettura ai fini del tentativo di recupero?

— process91,

@ process91 Consentire il danneggiamento di un settore non è considerato una buona idea, anche se tale fatto è stato registrato in un file di registro. Non avresti idea di quale file potrebbe essere danneggiato. Il RAID dovrebbe assicurarsi che leggendo quel file si verifichi un errore. Inoltre chiaramente non vuoi sovrascrivere solo il settore danneggiato, perché ciò significherebbe che hai perso l'ultima possibilità di recuperare i dati. Quindi hai un settore illeggibile su un disco e un settore sul nuovo disco in cui non sai cosa scrivere. Potrebbero essere due file diversi danneggiati.

— Kasperd,

1

@ process91 Ho aggiunto una nota sugli array basati su LSI. Dai un'occhiata.

— shodanshok,

8

Se si verifica un URE, si verificherà una certa corruzione dei dati nel blocco, che in genere ha una dimensione di 256 KB-1 MB, ma ciò non significa che TUTTI i dati sul volume andrebbero persi. La cosa non eccezionale di RAID5 è una cosa completamente diversa: ricostruire se stesso è stressante e ci sono alte probabilità che si verifichi un errore del secondo disco di seguito. In tal caso, tutti i dati andrebbero persi.

— BaronSamedi1958
fonte

2

In che modo una ricostruzione RAID5 è più stressante su una singola unità rispetto a una ricostruzione RAID1? Vedo che è più stressante sulla CPU, ma per qualsiasi unità specifica stiamo semplicemente leggendo tutti i dati da essa. Normalmente, il pericolo che le persone citano con unità più grandi è che probabilmente incontreranno un URE durante la ricostruzione, ma va bene per me se significa solo che un singolo settore sarà danneggiato.

— process91,

3

È teoria della probabilità. Con N (dove si trova il numero di unità), le probabilità che si verifichino guasti sono N volte maggiori.

— BaronSamedi1958,

1

Non è esattamente come funzionerebbe il calcolo, in realtà vorresti calcolare 1- probabilità di non avere un errore, ma capisco quella parte. Sembra che io abbia interpretato erroneamente la tua affermazione nel suggerire che l'atto di ricostruire un RAID5 è in qualche modo più stressante sul disco stesso (che ho letto altrove) che quindi aumenta le possibilità di un URE, ma se non è quello che sto dicendo quindi sono d'accordo.

— process91,

2

Lo spiegherei al contrario;

Se il controller RAID non si ferma su URE, cosa potrebbe succedere?

L'ho vissuto su un server, il RAID non ha mai notato l'URE e dopo la ricostruzione ha iniziato a svilupparsi un danneggiamento sull'intero volume RAID.

Il disco ha iniziato a diventare un settore più danneggiato dopo la ricostruzione e i dati hanno iniziato a essere danneggiati.

Il disco non è mai stato avviato dal volume RAID, il controller non è in grado di proteggere l'integrità dei dati.

Quell'esempio è scritto per farti pensare che un controller non può assolutamente spingere un volume con URE, è per l'integrità dei dati, poiché il volume non è pensato per essere un backup ma una risposta a un guasto del disco

— yagmoth555 - GoFundMe Monica
fonte

1

Vedo che i nuovi moderatori controllano costantemente il sito, alla ricerca di cose da fare ...

— Ward - Reinstate Monica

1

Perché un singolo URE dovrebbe generare corruzione nell'intero volume RAID?

— process91,

2

Scusa, ho riletto la tua risposta. Sembra che tu abbia avuto un singolo URE cattivo durante la ricostruzione, ma questo non era il problema. Il problema era che i settori continuavano a peggiorare dopo la ricostruzione e l'unità non lo ha mai segnalato. Questo sembra un problema separato, tuttavia, dal fatto che il controller RAID noti o meno un URE durante una ricostruzione. Il controller RAID potrebbe notare l'URRE durante la ricostruzione e avvisarti, ma continua comunque a terminare la ricostruzione. Alcuni dati sarebbero sempre meglio di nessun dato.

— process91,

2

Mi interessa solo analizzare perché RAID5 è stato considerato "morto" nel 2009, il che si basa sulla probabilità di un singolo URE. La mia comprensione ora è che questa analisi era sia matematicamente errata che non si applica allo stesso modo, ad esempio, a ZFS.

— process91,

1

@RobMoir Immagino che la tua ultima affermazione sia dove non sono d'accordo. Ottenere quasi tutti i miei dati dall'array potrebbe essere utile, anche se avessi un altro backup. Forse quel file non era importante o (nel caso dell'hardware RAID) l'errore si è verificato in un'area di spazio libero. Penso che la decisione giusta, per l'hardware RAID (dove non sa esattamente quali file sono stati interessati) sarebbe quella di avvisare l'utente, completare la ricostruzione e portare l'array in modalità di sola lettura. Non vedo alcun aspetto negativo di questo. (Ovviamente, filesystem come ZFS possono anche fare di meglio, dal momento che possono segnalare i file interessati.)

— process91,

1

Suggerirei di leggere questa domanda e le risposte per ulteriori informazioni. Quindi vai a rileggere la domanda a cui ti sei collegato di nuovo.

Quando qualcuno dice di questa situazione che "il RAID non è riuscito", significa che hai perso il vantaggio del RAID: hai perso l'accesso continuo ai dati che è stato il motivo per cui hai impostato l'array RAID in primo luogo.

Non hai perso tutti i dati, ma il modo più comune per recuperare da un'unità morta più (alcuni) URE su (alcune) delle unità rimanenti sarebbe ricostruire completamente l'array da zero, il che significa ripristinare tutti i tuoi dati dal backup.

— Ward: ripristina Monica
fonte

1

In genere, si utilizza RAID quando l'obiettivo è ridurre al minimo i tempi di inattività. Far sì che l'array continui con corruzione sconosciuta e non riparata è in genere contrario a tale obiettivo.

— David Schwartz,

1

Grazie, quella prima domanda a cui hai collegato è stata molto istruttiva. Perché avrei perso l'accesso continuo ai dati? L'array sarebbe ancora attivo durante la ricostruzione, e se incontra un URE durante la ricostruzione, mi aspetterei che continui a funzionare, anche se con questo settore di dati ora corrotto. Non è così?

— process91,