Var tvungen att följa upp mitt påstående att RAID 5 fortfarande fungerar bra efter en artikel i Techworld (PDF) där testaren David Thorarinsson hävdar att den stora kapacitet är ett problem.
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 inlägg:
