RAID genbesøgt

Dengang jeg var en novice servicetekniker og næsten ikke vidste noget om systemadministration, var et af de få emner, som vi altid forventedes at kende til fulde, RAID – Redundant Array of Inexpensive Disks. Det var svaret på alle vores lagringsbesvær. Med RAID kunne vi skalere vores filsystemer større, få bedre gennemstrømning og endda tilføje redundans, der gav os mulighed for at overleve tabet af en disk, som i særdeleshed i de dage skete ganske regelmæssigt. Med fremkomsten af NAS- og SAN-lagringsapparater er de kompetencer, der kræves for at gå ned til det fysiske lagringsniveau og tilpasse det til systemets behov, hastigt ved at forsvinde. Det er ikke en god ting. Bare fordi vi aflaster lagring til eksterne enheder, ændrer det ikke det faktum, at vi grundlæggende skal forstå vores lagring og konfigurere den til at opfylde de specifikke behov i vores systemer.

En misforståelse, der ser ud til at have indfundet sig i branchen i løbet af de seneste fem til ti år, er troen på, at RAID på en eller anden måde repræsenterer en systembackup. Det gør det ikke. RAID er en form for fejltolerance. Backup og fejltolerance er begrebsmæssigt meget forskellige. Backup er designet til at give dig mulighed for at komme dig efter en katastrofe, der er opstået. Fejltolerance er designet til at mindske chancen for en katastrofe i første omgang. Tænk på fejltolerance som at bygge et hegn øverst på en klippe og backup som at bygge et hospital i bunden af den. Du ønsker aldrig virkelig at befinde dig i en situation uden både et hegn og et hospital, men de er bestemt forskellige ting.

Når vi implementerer RAID til vores drev, hvad enten det er lokalt tilsluttet eller på et fjernapparat som SAN, har vi fire vigtige RAID-løsninger at vælge imellem i dag til forretningsbrug: RAID 1 (spejling), RAID 5 (striping med paritet), RAID 6 (striping med dobbelt paritet) og RAID 10 (spejling med striping). Der er andre, som RAID 0, der kun bør bruges i sjældne tilfælde, når man virkelig forstår sit drev-undersystemets behov. RAID 50 og 51 bruges også, men langt sjældnere og er ikke næsten så effektive. For ti år siden var RAID 1 og RAID 5 almindelige, men i dag har vi flere muligheder.

Lad os gennemgå mulighederne og diskutere nogle grundlæggende tal. I vores eksempler vil vi bruge n til at repræsentere antallet af drev i vores array, og vi vil bruge s til at repræsentere størrelsen af et enkelt drev. Ved hjælp af disse kan vi udtrykke den brugbare lagerkapacitet for et array og gøre sammenligninger nemme med hensyn til lagerkapacitet.

RAID 1: I denne RAID-type spejles drevene. Du har to drev, og de gør alt sammen på samme tid, deraf "spejling". Spejling er ekstremt stabilt, da processen er så simpel, men det kræver, at du køber dobbelt så mange drev, som du ville have brug for, hvis du slet ikke brugte RAID, da dit andet drev er dedikeret til redundans. Fordelen er, at du har sikkerhed for, at hvert bit, du skriver til disk, skrives to gange for din beskyttelse. Så med RAID 1 beregnes kapaciteten som (n*s/2). RAID 1 lider under at give minimale ydelsesforbedringer i forhold til ikke-RAID-drev. Skrivehastigheder svarer til et ikke-RAID-system, mens læsehastigheder er næsten dobbelt så hurtige i de fleste situationer, da drevene under læseoperationer kan tilgå parallelt for at øge gennemstrømningen. RAID 1 er begrænset til to-drev-sæt.

RAID 5: Striping med enkelt paritet. I denne RAID-type skrives data i en kompleks stripe på tværs af alle drev i arrayet med en distribueret paritetsblok, der eksisterer på tværs af alle drevene. Ved at gøre dette er RAID 5 i stand til at bruge et vilkårligt stort array med tre eller flere diske og mister kun den lagerkapacitet, der svarer til en enkelt disk, til paritet, selv om pariteten er distribueret og ikke udelukkende eksisterer på en enkelt fysisk disk. RAID 5 bruges ofte på grund af sin omkostningseffektivitet som følge af dets mangel på tab af lagerkapacitet i store arrays. I modsætning til spejling kræver striping med paritet, at der udføres en beregning for hver skrivesstripe på tværs af diskene, og dette skaber noget overhead. Derfor er gennemstrømningen ikke altid en åbenlys beregning og er stærkt afhængig af den beregningsmæssige kraft i det system, der udfører paritetsberegningen. Beregning af RAID 5-kapacitet er ganske enkel, da den blot er ((n-1)*s). Et RAID 5-array kan overleve tabet af en enkelt disk i arrayet.

RAID 6: Redundant striping med dobbelt paritet. RAID 6 er praktisk talt identisk med RAID 5, men bruger to paritetsblokke pr. stripe frem for én for at give yderligere beskyttelse mod diskfejl. RAID 6 er et nyere medlem af RAID-familien, der blev tilføjet flere år efter, at de andre niveauer var blevet standardiseret. RAID 6 er særlig derved, at det tillader fejl på to drev i et array uden at lide datatab. Men for at imødekomme det ekstra redundansniveau mister et RAID 6-array lagerkapaciteten svarende til to drev i arrayet og kræver minimum fire drev. Vi kan beregne kapaciteten af et RAID 6-array med ((n-2)*s).

RAID 10: Spejling plus striping. Teknisk set er RAID 10 en hybrid RAID-type, der omfatter et sæt RAID 1-spejle, der eksisterer i en stripe uden paritet (RAID 0). Mange leverandører bruger betegnelsen RAID 10 (eller RAID 1+0), når de taler om kun to drev i et array, men teknisk set er det RAID 1, da striping ikke kan forekomme, før der er minimum fire drev i arrayet. Med RAID 10 skal drev tilføjes parvis, så kun et lige antal drev kan eksistere i et array. RAID 10 kan overleve tabet af op til halvdelen af det samlede drev-sæt, men maksimalt ét fra hvert par. RAID 10 involverer ikke en paritetsberegning, hvilket giver det en ydelsefordel i forhold til RAID 5 eller RAID 6 og kræver mindre beregningsmæssig kraft til at drive arrayet. RAID 10 leverer den største læseydelse af alle almindelige RAID-typer, da alle drev i arrayet kan bruges simultant i læseoperationer, selv om dets skriveydelse er meget lavere. RAID 10's kapacitetsberegning er identisk med RAID 1's, (n*s/2).

I nutidens enterprise er det sjældent, at en IT-afdeling har et seriøst behov for at overveje nogen drevkonfiguration uden for de fire her nævnte, uanset om software- eller hardware-RAID implementeres. Traditionelt var den største bekymring i en RAID-array-beslutning baseret på brugbar kapacitet. Det skyldtes, at drev var dyre og små. I dag er drev så store, at lagerkapacitet sjældent er et problem, i det mindste ikke som det var for blot nogle få år siden, og omkostningerne er faldet til et niveau, hvor køb af yderligere drev, der er nødvendige for bedre drevredundans, generelt er af mindre betydning. Når kapaciteten er knap, er RAID 5 et populært valg, fordi det mister mindst lagerkapacitet sammenlignet med andre array-typer, og i store arrays er lagringstabet nominelt.

I dag har vi generelt andre bekymringer, primært datasikkerhed og ydeevne. At bruge lidt ekstra for at sikre databeskyttelse bør være et oplagt valg. RAID 5 lider under kun at kunne miste et enkelt drev. I et array med bare tre medlemmer er dette kun lidt farligere end den beskyttelse, som RAID 1 tilbyder. Vi kunne overleve tabet af et ud af tre drev. Ikke så skræmmende sammenlignet med at miste et af to drev. Men hvad med et stort array, sig seksten drev? At kunne miste sikkert kun ét ud af seksten drev burde få os til at stille spørgsmålstegn ved vores pålidelighed lidt mere grundigt.

Det er her, RAID 6 trådte ind for at udfylde hullet. RAID 6, når det bruges i et stort array, introducerer et meget lille tab af lagerkapacitet og ydeevne, mens det giver sikkerhed for at kunne miste to drev. Tilhængere af striping med paritet vil ofte citere disse tal for at berolige ledelsen om, at RAID 5/6 kan give tilstrækkelig "valuta for pengene" i lagringsundersystemer, men der er andre faktorer i spil.

Næsten fuldstændigt overset i diskussioner om RAID-pålidelighed – et alt for sjældent diskuteret emne som det er – er spørgsmålet om paritetsberegningspålidelighed. Med RAID 1 eller RAID 10 er der ingen "beregning" foretaget for at skabe en stripe med paritet. Data skrives simpelthen på en stabil måde. Når et drev fejler, tager dets partner over, og drevydelsen er let forringet, indtil partneren er erstattet. Der er ingen genopbygningsproces, der påvirker eksisterende drevmedlemmer. Ikke sådan med paritetsstriper.

RAID-arrays med paritet har operationer, der involverer beregning af, hvad der er og hvad der bør være på drevene. Selv om denne beregning er meget simpel, giver den en mulighed for, at ting kan gå galt. En array-controller, der fejler med RAID 1 eller RAID 10, kan i teorien skrive dårlige data over indholdet af drevene, men der er ingen proces, hvorved controlleren foretager drevændringer på egen hånd, så dette er ekstremt usandsynligt nogensinde at forekomme, da der aldrig er en "genopbygnings"-proces undtagen ved oprettelse af en spejling.

Når arrays med paritet udfører en genopbygningsoperation, udfører de en kompleks proces, hvorved de gennemgår hele arrayets indhold og skriver manglende data tilbage til det erstattede drev. I sig selv er dette relativt simpelt og bør ikke give anledning til bekymring. Det, jeg og andre har set med egne øjne, er et lidt andet scenarie, der involverer diske, der har mistet forbindelsen på grund af løse stik til arrayet. Drev kan almindeligvis "ryste sig løs" over tid, efterhånden som de sidder i en server, især efter flere års service i et altid-tændt system.

I ekstreme scenarier kan god data på drev overskrives af dårlige paritetsdata, når en array-controller mener, at et eller flere drev er fejlet successivt og bragt online igen til genopbygning. I dette tilfælde har drevene selv ikke fejlet, og der er intet datatab. Alt, hvad der kræves, er, at drevene isættes igen, i teorien. På hot swap-systemer er håndteringen af drevgenopbygning ofte automatisk baseret på fjernelse og udskiftning af et defekt drev. Så denne proces med at miste og erstatte et drev kan forekomme uden menneskelig indgriben – og en genopbygningsproces kan begynde. Under denne proces er dreve-systemet i fare, og skulle den samme hændelse forekomme igen, kan drev-arrayet, baseret på drevenes status, begynde at stripe dårlige data på tværs af drevene og overskrive det gode filsystem. Det er et af de mest deprimerende syn for en serveradministrator at se, når et system uden defekte drev mister et helt array på grund af en unødvendig genopbygningsoperation.

I teorien bør denne type situation ikke forekomme, og sikkerhedsforanstaltninger er på plads for at beskytte mod den, men bestemmelsen fra en low-level drev-controller om status for et drev aktuelt og tidligere og kvaliteten af de data, der er på det drev, er ikke så simpel, som det kan virke, og det er muligt for fejl at forekomme. Selv om denne situation er usandsynlig, sker den, og den tilføjer en næsten umulig at beregne risiko til RAID 5- og RAID 6-systemer. Vi skal overveje risikoen for paritetssvigt ud over den traditionelle risiko beregnet ud fra antallet af drevtab, som et array kan overleve fra en pulje. Efterhånden som drev bliver mere pålidelige, bliver betydningen af risikohændelsen for paritetssvigt større.

Derudover introducerer RAID 5- og RAID 6-paritet system-overhead på grund af paritetsberegning, som ofte håndteres ved hjælp af dedikeret RAID-hardware. Denne beregning introducerer latens i drev-undersystemet, der varierer dramatisk afhængigt af implementeringen, både i hardware og i software, hvilket gør det umuligt at angive ydelsesal for RAID-niveauer over for hinanden, da hver implementering vil være unik.

Muligvis det største problem med RAID-valg i dag er, at lethed, hvormed målinger for lagereffektivitet og drevtabs-overlevelsesevne kan opnås, maskerer det store billede af pålidelighed og ydeevne, da disse statistikker er næsten fuldstændigt utilgængelige. En af farerne ved metrics er, at folk vil fokusere på faktorer, der nemt kan måles, og ignorere dem, der ikke nemt kan måles, uanset deres potentielle indvirkning.

Mens alle moderne RAID-niveauer har deres plads, er det afgørende, at de overvejes i kontekst og med en forståelse af hele risikorammen. Vi bør arbejde hårdt for at flytte vores branche fra en standard på RAID 5 til en standard på RAID 10. Drev er billige, og datatab er dyrt.

[Redaktion: I de år, der er gået siden dette oprindeligt blev skrevet, har stigningen i URE (Unrecoverable Read Errors)-risici under en genopbygningsoperation forskudt de primære risici fra dem, der er angivet, til URE-relaterede risici for paritetsarrays.]