Praktiske RAID-valg til Spindeldrevbaserede Arrays

En sand mængde information florerer om RAID-lagersystemer og udforsker emner som risiko, ydeevne, kapacitet, tendenser, tilgange og meget mere. Selv om arbejdet med dette emne er nærmest overvældende, kan informationen destilleres til en håndfuld fælles, praktiske lagringstilgange, der vil dække næsten alle brugsscenarier. Mit mål her er at give en praktisk guide, der vil give en ikke-lagringsspecialist mulighed for at nærme sig RAID-beslutningstagning på en praktisk og, vigtigst af alt, sikker måde.

Til formålet med denne guide vil vi antage lagerprojekter på ikke mere end fem og tyve traditionelle drev (spindeldrev, korrekt kaldet Winchester-drev.) Disse drev kan typisk være SFF (2,5″) eller LFF (3,5″), SATA eller SAS, forbruger- eller enterprise-klasse. Vi vil ikke tackle solid state-drev, da disse har meget anderledes egenskaber og kræver deres egen vejledning. Lagersystemer med mere end ca. fem og tyve spindler bør ikke arbejde ud fra standardvejledning, men gå dybere ind i specifikke lagerbehov for at sikre korrekt planlægning.

Vejledningen her er skrevet til standardsystemer i 2015. I løbet af de seneste to årtier har de fælles tilgange til RAID-lagring ændret sig dramatisk, og selv om det ikke forventes, at de nøglefaktorer, der påvirker disse beslutninger, vil ændre sig nok i fremtiden til at ændre disse anbefalinger, er det meget muligt, at de vil. God RAID-design fra 1998 er meget dårlig RAID-design i dag. Forandringshastigheden i branchen er faldet betydeligt siden dengang, og disse anbefalinger vil sandsynligvis stå ved magt i meget lang tid, muligvis til spindeldrevlagring ikke længere er tilgængeligt eller i det mindste populært, men som med alt andet er forudsigelser underlagt store forandringer.

Generelt bruger vi det, der kaldes en “One Big Array”-tilgang. Det vil sige et enkelt RAID-array, hvori alle system- og datapartitioner oprettes. Behovet eller ønsket om at opdele vores lagring i flere fysiske arrays er stort set forsvundet i dag og bør kun gøres under ikke-generelle omstændigheder. Kun i situationer, hvor der foretages omhyggelig undersøgelse af lagringsbehovene og tung analyse, bør vi overveje array-opdeling. Array-opdeling er langt mere tilbøjelig til at forårsage skade end gavn. I tvivlstilfælde, undgå opdelte arrays. Målet med denne guide er generelle tommelfingerregler, der giver enhver IT-professionel mulighed for at bygge et sikkert og pålideligt lagersystem. Tommelfingerregler dækker ikke og kan ikke dække alle scenarier, undtagelser eksisterer altid. Men ideen her er at dække den store majoritet af tilfælde med velafprøvede tilgange, der er designet omkring moderne udstyr, brugsscenarier og behov, mens man er opmærksom på at fejle på siden af sikkerhed – når et valg er mindre end ideelt, er det stadig sikkert. Intet af disse valg er på nogen måde hensynsløst; i værste fald er de for konservative.

Det første scenarie, vi bør overveje, er, hvis dine data ikke er vigtige. Dette kan lyde som en mærkelig ting at overveje, men det er et meget vigtigt scenarie. Der er mange gange, hvor data gemt på disk betragtes som flygtige og ikke behøver at blive beskyttet. Dette er almindeligt for rekonstruerbare data såsom arbejdsplads til rendering, mellemliggende beregningsrum eller caches – situationer, hvor det er spild at bruge penge på at beskytte data, og det ville være acceptabelt blot at genskabe tabte data frem for at beskytte dem. Dette kan være et tilfælde, hvor nedetid ikke er et problem, og data er statiske eller næsten statiske, og frem for at bruge penge på at reducere nedetid bekymrer vi os kun om at beskytte data via sikkerhedskopiemekanismer, så hvis et array fejler, gendanner vi blot arrayet fuldstændigt. I disse tilfælde er det åbenlyse valg RAID 0. Det er meget hurtigt, meget simpelt og giver den mest omkostningseffektive kapacitet. Den eneste ulempe ved RAID 0 er, at det er skrøbeligt og ikke giver nogen beskyttelse mod datatab i tilfælde af drevfejl eller endda en URE (som ville forårsage datakorruption på samme måde som en stationær computer står over for.)

Det bør bemærkes, at en undtagelse til “One Big Array”-tilgangen, der ville være almindelig, er i systemer, der bruger RAID 0 til data. Der ville være et godt argument for et lille drevarray dedikeret til operativsystemet og applikationsdata, der ville være besværligt at geninstallere i tilfælde af arraytab, som holdes på RAID 1, og RAID 0-dataarray adskilt fra det. På denne måde kan gendannelse ske meget hurtigt frem for at skulle genopbygge hele systemet fra bunden frem for blot at genskabe dataene.

Forudsat at vi har elimineret tilfælde, hvor data ikke kræver beskyttelse, vil vi for alle resterende tilfælde antage, at data er ganske vigtige, og at vi ønsker at beskytte dem til en vis omkostning. Vi antager, at det er vigtigt at beskytte data, som de eksisterer på den aktive lagring, generelt fordi vi ønsker at undgå nedetid, eller fordi vi ønsker at sikre dataintegritet, fordi data på disk ikke er statiske, og et arrayfejl også ville udgøre datatab. Med denne antagelse vil vi fortsætte.

Hvis vi har et array med kun to drev, er svaret meget enkelt: vi vælger RAID 1. Der er ingen anden mulighed i denne størrelse, så der er ingen beslutning at træffe. I teorien bør vi planlægge vores arrays holistisk og ikke efter antallet af drev er bestemt; antallet af drev og typen af array bør bestemmes sammen, ikke drev købt og derefter brug bestemt baseret på det vilkårlige tal, men to-drev-chassis er så almindelige, at det er værd at nævne som et tilfælde.

Tilsvarende er det eneste reelle valg at overveje med et fire-drevarray RAID 10. Der er ikke behov for yderligere evaluering. Vælg blot RAID 10 og fortsæt.

Et akavet tilfælde er et tre-drevarray. Det er meget, meget sjældent, at vi er begrænset til tre drev, da det eneste almindelige chassis begrænset til tre drev var Apple Xserve, som har været ude af markedet i nogen tid, så behovet for at træffe beslutninger vedrørende tre-spindel-arrays bør være yderst usandsynligt. I tilfælde, hvor vi har tre drev, er det ofte bedst at søge vejledning, men de mest almindelige tilgange er at tilføje et fjerde drev og dermed vælge RAID 10 eller, hvis kapacitet på mere end et enkelt drevs størrelse ikke er nødvendig, at sætte alle tre drev i et enkelt tredobbelt-mirror RAID 1.

For alle andre tilfælde har vi derfor at gøre med fem til fem og tyve drev. Da vi har elimineret situationerne, hvor RAID 0 og RAID 1 ville gælde, er vi tilbage med alle fælles scenarier, der kommer ned til RAID 6 og RAID 10, og disse udgør den store majoritet af tilfælde. At vælge mellem RAID 6 og RAID 10 bliver den største udfordring, vi vil stå over for, da vi udelukkende skal se på vores “bløde” behov for pålidelighed, ydeevne og kapacitet.

At vælge mellem RAID 6 og RAID 10 bør ikke være utroligt svært. RAID 10 er ideelt til situationer, hvor ydeevne og sikkerhed er prioriteterne. RAID 10 har meget hurtigere skriveydeevne og er sikker uanset hvilken type drev der bruges (billige forbrugerdrev kan stadig være ekstremt sikre, selv i store arrays.) RAID 10 skalerer godt til ekstremt store størrelser, meget større end hvad der bør implementeres ved hjælp af tommelfingerregler! RAID 10 er det sikreste af alle valg, det er hurtigt og sikkert. De åbenlyse ulemper er, at RAID 10 har mindre lagerkapacitet fra de samme drev og er dyrere på basis af kapacitet. Det skal nævnes, at RAID 10 kun kan anvende et lige antal drev; drev tilføjes i par.

RAID 6 er generelt sikkert og hurtigt, men aldrig så sikkert eller hurtigt som RAID 10. RAID 6 lider specifikt af skriveydeevne, så det er meget dårligt egnet til arbejdsbyrder som databaser og stærkt blandede belastninger som i store virtualiseringssystemer. RAID 6 er omkostningseffektivt og lægger stor vægt på tilgængelig kapacitet sammenlignet med RAID 10. Når budgetter er stramme, eller kapacitetsbehov dominerer over ydeevne, er RAID 6 et ideelt valg. Sjældent er forskellen i sikkerhed mellem RAID 10 og RAID 6 en bekymring, undtagen i meget store systemer med forbrugerklass drev. RAID 6 er udsat for yderligere risiko med forbrugerdrev, som RAID 10 ikke er påvirket af, hvilket kan give anledning til en vis bekymring om pålidelighed i større RAID 6-systemer, såsom dem over ca. 40TB, når forbrugerdrev bruges.

I det lille erhvervssegment specielt vil de fleste systemer bruge RAID 10, simpelthen fordi arrays sjældent behøver at være større end fire drev. Når arrays er større, er RAID 6 det mere almindelige valg på grund af noget stramme budgetter og generelt lav bekymring om ydeevne. Både RAID 6 og RAID 10 er sikre og effektive løsninger til næsten alle brugsscenarier, med RAID 10 der dominerer, når ydeevne eller ekstrem pålidelighed er nøglen, og RAID 6 der dominerer, når omkostninger og kapacitet er nøglen. Og selvfølgelig, når lagringsbehov er meget unikke eller meget store, såsom større end fem og tyve spindler i et array, husk at kontakte en lagringskonsulent, da scenariet nemt kan blive meget komplekst. Lagring er et sted, hvor det betaler sig at være ekstra flittig, da så mange ting afhænger af det, fejl er så lette at lave, og fleksibiliteten til at ændre det bagefter er så lav.