Vi kan ta ett exempel. Säg att du har 3 hårddiskar om 500 GB i en RAID5. Du förlorar en hårddisk till redundansen och får ut 1 TB effektivt:

3 diskar i RAID5 på 0,5 TB = 1,0 TB effektivt (33% förlust)

Om du nu får slut på utrymme och vill utöka det. Vilket är det bästa alternativet. Att köpa 3 nya hårddiskar om 1 TB styck eller att utöka med fler 0,5 TB diskar. 3 hårddiskar om 1 TB ger dig 2 TB effektivt:

3 diskar i RAID5 på 1 TB = 2,0 TB effektivt (33% förlust)

Köper du istället till 2 stycken hårddiskar till på 0,5 TB får du också ut 2 TB effektiv:

5 diskar i RAID5 på 0,5 = 2,0 TB effektivt (20% förlust)

Prismässigt är det stor skillnad. 3 x 1 TB diskar á 865:- = 2595:- mot 2 x 0,5 TB diskar á 565:- = 1130:-

Dessutom klarar de flesta RAID-korten av att utöka en RAID5 medan den är i drift och utan att förlora någon data. Det går även med mjukvaru-RAID i både Linux och Windows. Problemet som uppstår är givetvis att man i många fall kan vara begränsad i hur många hårddiskar man får plats med.

RAID5 är ett bra alternativ om man har stora lagringsbehov utan att ha stora krav på skrivhastighet.

Liknande inlagg

1. Sudden death för min USB-Disk
2. Utöka Windows Media Center Live TV Buffert
3. Funkar Green Power och andra lågenergihårddiskar i RAID?

Har läst en del artiklar till i ämnet och alla verkar grunda sig på Robin Harris artikel hos ZDNet “Why RAID 5 stops working in 2009“. Ingen verkar reflektera över det faktum att det faktiskt går att läsa 12Tb data om och om igen utan att få problem.

Harddrive Recovery för i alla fall förklara att det här inte sker i verkligheten eftersom det inte står “A Dead RAID On Every Corner“. Förklaringen blandar in soft error rate och att dessa normalt repareras genom att läsa sektorn igen eller använda Error Correction Code (ECC) för att rätta till felet. Nu är det faktiskt BER / URE som Harris pratar om och som är de fel som faktiskt inte kan repareras. Harddrive Recovery är dock inne på att det faktiskt rör sig om sektorer och inte enskilda bitar vilket jag hävdar är förklaringen till att siffran 1 fel per 10^14 lästa bitar måste multipliceras med sektorstorleken för att får fram det faktiska antalet läsbara bytes mellan varje ej läsbar sektor.

Hos Enterprise Storage Forum har Henry Newman en liknande artikel om att RAID inte är tillförlitligt när hårddiskarna växer.  Newman kommer fram till helt andra siffror när det gäller hur mycket data som går att läsa mellan varje fel. Istället för 12,5 TB kan man enligt honom läsa 0,88 PB med en URE på 10^14. Det tog en stunds räknande innan jag insåg hur han nått dessa siffror.

Harris räknar att 10^14 = 100 000 000 000 000, han delar sedan med 1000 för att nå kilo, 1000 till för mega, sedan 1000 för giga och slutligen 1000 igen för terra. Det ger 100 Terrabitar. Det delas sedan med 8 för att få siffran 12,5 i terabyte.

Newman har å sin sida delat med 1024 vilket är korrekt när man hantera byte och inte bitar. Tyvärr gör han två andra fel. Dels gör han ett decimalfel. Det blir 0,88 Tb men borde bli 0,088. Dels missar han att dela med 8 för att gå från bitar till bytes. Vilket ger 0,011 TB.

När nu Newmans hårddiskar genom den felaktiga beräkningen blir väldigt mycket tillförlitligare än Harris måste Newman dessutom ta till ännu ett knep för att skrämma upp läsarna. Han ser till att det blir en väldigt stor mängd data som måste läsas och skrivas vid återskapande av en felande hårddisk i en RAID. Han väljer en RAID med tio hårddiskar om 1,5 TB och hävdar att alla dessa måste läsas och dessutom skrivas till vid återskapandet. Det är fel i två hänseenden, dels skrivs det bara till den hårddisken som ersatts till en ny. Varför skulle det skrivas till de andra där datat är redan ligger? Dels gäller URE problemet endast vid läsning av sektorer (unrecoverable READ error). Misslyckas en skrivning till hårddisken flyttas sektorn till en annan del av hårddisken. Slutligen missar Newman att RAID-6 har dubbel paritet och därför kan fixa ett URE på en hårddisk även om en annan håller på att repareras.

Den enda lärdomen vi kan dra ur Newmans beräkningar är att Harris inte delat med 1024 som han borde gjort när vi pratar om bytes och inte bitar. Stämmer Harris förutsägelse sitter vi alltså ändå mer med skägget i brevlådan. Nu är det inte fallet eftersom vi inte ser problemet i varje hörn. Vi tar t.ex. flera terrabyte med data i backup varje vecka på jobbet. Detta läses från RAID5 lagring och det görs sedan en verify på att data skrivits korrekt till backupdiskarna som även de är i RAID5. Vi har inte haft några läsfel trots att det inte görs någon kontroll mot pariteten vid normal läsning.

Trots att jag fortfarande hävdar att man kan sova gott med stora RAID5 diskar har det fått mig att fundera över om upplägget med snabba diskar för primär lagring, mindre snabba backupdiskar och sedan band för längre lagring verkligen är ett bra koncept. Totalt tror jag varje bit lagras minst 10 gånger på olika ställen, primär disk med paritet, backupdisk med paritet och sedan flera generationer med backuper. Det kostar pengar. Det är dags att titta på snapshots, distribuerad lagring, deduplicering och arkivering istället.

Liknande inlagg

1. RAID-5 fungerar fortfarande
2. Funkar Green Power och andra lågenergihårddiskar i RAID?
3. Utöka en RAID5 disk

Artikelförfattaren Robin Harris grundar sitt påstående på ett värde på Unrecoverable Read Error Rate (URE) som ligger någonstans på 1 fel per 10^14 bitar vilket motsvarar 12 Terrabytes. Problemet blir därför enligt Harris att om en disk går sönder i en RAID-5 array med t.ex. 7 stycken 2Tb diskar måste det läsas från 6 diskar x 2 TB = 12 TB data för att återskapa den felande disken. Under det återskapandet skulle det alltså normalt uppstå ett URE och därmed skulle hela RAID arrayen vara förlorad.

Jag har hela tiden tyckt det här verkar konstigt för skulle det uppstå ett oreparerbart fel i snitt en gång per 12 TB skulle vi se det hela tiden. Jag har till exempel en 1 TB disk hemma som jag tar backup på varje helg. Den skulle alltså normal fela var 12:e vecka men det har inte hänt en enda gång. Varför?

Jag har läst förklaringar att det beror på att URE uppstår mer sällan på nyare hårddiskar, vilket stämmer till viss del, men även om det ökat tio eller hundrafalt borde man märka problemet på massor av ställen där man tar flera TB data i backup varje natt.

Andra har hävdat att det beror på att ECC – Error Correction Code, som lagras på disken, rättar felet, eller att det bara är att läsa datat igen så funkar det. Det är fel eftersom U-et i URE står för Unrecoverable och innebär att ECC redan använts tillsammans med flera läsförsök utan att datat kunnat läsas.

Svaret ligger i att man inte får ett URE på 1 bit av 12 TB lästa utan URE gäller per sektor. Detta eftersom värdet är efter att ECC applicerats på en sektor och sektorn försökt läsas flera gånger. Det är aldrig bara en byte som är oläsbar utan en hel sektor. En sektor är normalt på 512 bytes och därmed uppstår felet extremt sällan. Det blir alltså som värst en gång per 512 byte * 10^14 = 51 PB (Petabytes dvs 51000 TB)

Men säger någon. Enheten för URE är per bitar och inte i sektorer. Det stämmer men när väl en sektor inte går att läsa innebär det att 512 bytes är oläsbara. Om felet uppstår en gång per 51 PB är det 512 bytes som går förlorade och vi får därför dela med 512 bytes för att få ut värdet i bitar. Det blir 10^14 precis som förväntat och att ange i sektorer vore konstigt eftersom de kan variera i storlek. Citerar kommentaren på slashdot:

“It is still true that one in 10^14 bits read independently (!) would be unrecoverable, but the independence is not there, as you either get a complete sector or nothing.”

Det är alltså ingen fara att använda RAID-5 även med stora hårddiskar. Konstigt att det skulle ta en hel del research för att hitta en ganska uppenbar förklaring. Det var först när jag grävde i kommentarerna på Slashdot jag hittade svaret. Kanske är det därför artikel skapat ett rykte att RAID-5 inte längre fungerar…

Liknande inlagg

1. Mer om problem med stora hårddiskar och RAID
2. Funkar Green Power och andra lågenergihårddiskar i RAID?
3. Utöka en RAID5 disk