Store diske tager livet af RAID 5: Tid til at se på RAID 6
FRANKFURT. RAID 5 har længe været tilstrækkeligt til at opnå et godt kompromis mellem driftsstabilitet, ydelse og økonomi, men den tid er snart ovre.
»Vi ser, at det tager længere tid at genopbygge et system, hvis en disk går i stykker. Det giver dårligere ydelse, og du risikerer, at endnu en disk står af, mens du stadig er ved at genopbygge,« siger chefanalytiker Josh Krischner fra Krischner & Associates.
På Storage Networking World Europe 2011 talte han om de teknologier, man som storage-ansvarlig skal være opmærksom på i det næste årti, og én af teknologierne var RAID 6 som erstatning for RAID 5.
De to varianter af RAID indeholder begge flere kopier af dataene, men RAID 5 kan kun tåle, at en enkelt disk går i stykker. Derefter skal man skifte disken, hvorefter storagesystemet kan begynde at skabe en ny kopi.
Jo større disk, jo længere tid tager det at genopbygge disken, og mens den proces står på, er systemet sårbart, for vis endnu en disk går i stykker, risikerer man, at man har mistet data, så systemet ikke kan genopbygges.
Samtidig er genopbygning en proces, som kan belaste systemet med mange ekstra diskoperationer, og det kan mærkes på ydelsen.
RAID 6 kan tåle, at to diske står af samtidig, og derfor forventer Josh Krischner, at RAID 6 vil erstatte RAID 5 i mange systemer i de næste år. Det er dog ikke alle systemer, som understøtter RAID 6.
Ifølge Josh Krischner kan man ud over at bruge RAID 6 også løse det samme problem ved at bruge software til at lave ekstra kopier på systemet, selvom det kræver ekstra plads.
»En løsning er pre-emptive copying. Kopiering tager kun en brøkdel af den tid, det tager at genopbygge,« siger Josh Krischner.
Mens udviklingen i antal diskoperationer pr. sekund for konventionelle harddiske ikke ser ud til at blive kraftigt forøget de næste år, så vil kapaciteten fortsætte med at stige. I 2020 vil en 2,5 tommer disk til et professionelt storagesystem formentligt kunne rumme 12 terabyte, vurderer Josh Krischner.
SNIA har betalt Version2's rejse- og opholdsudgifter i forbindelse med dækningen af SNW Europe 2011.
Kommentarer (9)
Ved genopbygningen af et RAID-5 er sandsynligheden efterhånden - med de store diske - ret stor for, at man møder en sektor-fejl, der ikke kan udbedres. Ifølge alle artiklerne om dét emne, bevirker sådan en fejl under genopbygningen, at hele RAID'et fejler og man mister alle sine data.
Siden jeg første gang læste om det, har det været en af de største gåder for mig, hvordan hulen i luften en enkelt sektor kan ødelægge et helt RAID!
Kan nogen svare mig på, hvorfor det ikke bare er data i eller omkring den sektor, der går tabt?
Hvorfor kan man ikke bare udfylde de manglende 512 kB med nuller og så fortsætte med at redde sine måske 6 TB med vigtige data??
Selv salige Jim Gray skrev under kort inden han forsvandt på mystisk vis :-). Da jeg og James mødtes med ham i kælderen i et lille art gallery i London spurgte han ud i rummet, om nogen kunne forklare ham, hvordan i Alverden det kunne være, at så mange kastede sig over RAID-5, når man nu VIDSTE, at det var noget lort? James og jeg kiggede på hinanden og fortalte ham, at det faktisk var årsdagen for vores stiftelse af BAARF, og så bad han mig om at sende ham linket :-).
Nå, men så er vi klar til RAID-6, som er endnu mere fjollet. Bedst som man tror det ikke kan blive mere åndssvagt, så rykker de for alvor :-).
Mvh Mogens
Ifølge Josh Krischner kan man ud over at bruge RAID 6 også løse det samme problem ved at bruge software til at lave ekstra kopier på systemet, selvom det kræver ekstra plads.
Jeg håber han mener at køre software mirror på 2 eller flere raid5 enheder, og ikke bare det ækvivalente til at tage 1 disk, dele den i 2 partitioner og så duplikere data på dem begge.
På RAID-6 benytter man som regel flere fysiske diske, så genopbygning vil oven i købet tage længere tid (på sammenlignelig/ens hardware). Jeg kan ikke se, hvordan RAID-6 skulle kunne belaste mindre - tværtimod.
Kan nogen svare mig på, hvorfor det ikke bare er data i eller omkring den sektor, der går tabt? Hvorfor kan man ikke bare udfylde de manglende 512 kB med nuller og så fortsætte med at redde sine måske 6 TB med vigtige data??
Det handler vel om at når et raid system får en fejl på en disk, så smider den disken ud af raidet? Det er okay med den første disk, så mister du bare din redundans, du indsætter en ny disk, eller den bruger din hotspare disk, og går i gang med genopbygningen. Men under genopbygningen så fejler disk nummer 2, som så bliver smidt ud af raidet, og har du lige pludselig ikke længere noget raid.
Jeg er ikke stødt på et hardware raid hvor man har kunnet tage en samling diske, skabe et raid, med specifikke diske på specifikke pladser og så sige til raid systemet: "det er okay, jeg ved godt hvad jeg gør, du skal IKKE initialisere raidet, men bare samle diskene så jeg kan (prøve) at læse data fra det."
Ovenstående har jeg dog gjort med Linux software raid, netop fordi en 2. disk fejlede midt i en rebuild af 1. disk. Kunden blev ret glad, og siden da er de vidst skiftet over til at køre raid10.
Hvorfor er det at vi stadig kører raid på block level? Hvis vi gjorde det på fil niveau, så kunne vi have forskellige raid niveauer pr. fil, således at de vigtige lå gemt mange gange, og de mindre vigtige kun en gang? eller med raid0 over flere diske? Et sådant filsystem kunne måske også have forskellige typer af underliggende diske, således at filer som kræver hurtig random access ligger på SSD diske, hvorimod store filer hvor man skal have sekventiel adgang ligger på harddiske?
ZFS, btrfs, og mange andre filsystemer har checksumming af metadata og data, således man kun skal rejecte selve fejlen, og har mulighed for a) korrigere den b) påpege hvad der er ramt hvis det ikke kan korrigeres, og dette for en block data, eller en block metadata.
Man korigerer således kun defekt data, frem for op til 3 TB tomme sektorer, hvorimens man er (mere) sårbar.
Det at synce en 3 TB disk op mellem 14 andre ved 20% idle prio på en controller tager laaang tid. Ikke kønt.
RAID er det fedeste nye shizzle fra starten af 90'erne, og det holder sig på samme plan.
Uanset om man regner med at køre f.eks. ZFS, så kan den her PDF oplyse om manglerne ved at køre RAID: http://www.eecis.udel.edu/~bmiller/DE-OSUG/ECECIS-ZFS.pdf
Disclaimer: Jeg kan godt lide ZFS :-)
Jeg er ikke stødt på et hardware raid hvor man har kunnet tage en samling diske, skabe et raid, med specifikke diske på specifikke pladser og så sige til raid systemet: "det er okay, jeg ved godt hvad jeg gør, du skal IKKE initialisere raidet, men bare samle diskene så jeg kan (prøve) at læse data fra det."
Det virker bare HELT oplagt, at forsøge at redde så meget data som muligt, når controlleren jo kan se, at der ikke er mere redundans tilbage! Og efter hvad jeg kan læse, er det en temmelig svær opgave at samle store raids manuelt (tillykke med at det er lykkedes for dig)!
Ja, ZFS er helt klart fremtiden - absolut en af de teknologier, det ville give allerflest positive konsekvenser at få udbredt! Min Thecus-NAS understøtter det desværre kun som filsystem, ikke som RAID-Z :(

