Praktisk RAID-ydeevne

At vælge et RAID-niveau er en øvelse i at balancere mange faktorer, herunder omkostninger, pålidelighed, kapacitet og selvfølgelig ydeevne. RAID-ydeevne kan være svær at forstå, især fordi forskellige RAID-niveauer bruger forskellige teknikker og opfører sig temmelig forskelligt fra hinanden i nogle tilfælde. I denne artikel vil jeg udforske de almindelige RAID-niveauer RAID 0, 5, 6 og 10 for at se, hvordan ydeevnen varierer mellem dem.

Med henblik på denne artikel vil RAID 1 blive antaget at være en delmængde af RAID 10. Dette er ofte en praktisk måde at tænke på RAID 1 – som blot at være et RAID 10-array med kun et enkelt spejlet par. Da RAID 1 virkelig er et enkelt par RAID 10 og opfører sig som sådan, fungerer dette glimrende til at gøre RAID-ydeevne nem at forstå, da det simpelthen kortlægger ind i RAID 10-ydeevnekurven.

Der er to typer ydeevne at se på med al storage: læsning og skrivning. Hvad angår RAID er læsning ekstremt nem, og skrivning er temmelig kompleks. Læseydeevne er effektivt stabil på tværs af alle RAID-typer. Skrivning er det imidlertid ikke.

For at gøre det nemmere at diskutere ydeevne er vi nødt til at definere et par udtryk, da vi vil arbejde med nogle ligninger. I vores diskussioner vil vi bruge N til at repræsentere det samlede antal drev, ofte benævnt spindler, i vores array, og vi vil bruge X til at referere til ydeevnen for hvert drev individuelt. Dette giver os mulighed for at tale i form af relativ ydeevne som en faktor af drevets ydeevne, så vi kan abstrahere RAID-arrayet væk og ikke behøver at tænke i form af rå IOPS. Dette er vigtigt, da IOPS ofte er meget svære at definere, men vi kan sammenligne ydeevne på en meningsfuld måde ved at tale om det i forhold til de individuelle drev i arrayet.

Det er også vigtigt at huske, at vi kun taler om ydeevnen for selve RAID-arrayet, ikke et helt lagersystem. Artefakter som hukommelsescaches og solid state-caches vil gøre fantastiske ting for at ændre den overordnede ydeevne i et lagersystem, men ændrer ikke grundlæggende ydeevnen af selve RAID-arrayet under motorhjelmen. Der er ingen simpel formel til at bestemme, hvordan forskellige cache-muligheder vil påvirke den overordnede ydeevne, men det er tilstrækkeligt at sige, at det kan være meget dramatisk, men dette afhænger kraftigt ikke kun af selve cache-valgene, men også kraftigt af arbejdsbelastningen. Selv de største, hurtigste og mest robuste cache-muligheder kan ikke ændre den langsigtede, vedvarende ydeevne af et array.

RAID er komplekst, og mange faktorer påvirker den endelige ydeevne. En er implementeringen af selve RAID-systemet. En dårlig implementering kan forårsage latenstid eller kan undlade at udnytte de tilgængelige spindler (såsom at have et RAID 1-array, der kun læser fra en enkelt disk i stedet for fra begge samtidigt!). Der er ingen nem måde at redegøre for mangler i specifikke RAID-implementeringer, så vi må antage, at alle arbejder til grænserne for specifikationen, som enhver enterprise RAID-system faktisk vil gøre. Det er primært hobby- og forbruger-RAID-systemer, der undlader at gøre dette.

Nogle typer RAID har også dramatiske mængder af beregningsoverhead forbundet med dem, mens andre ikke har. Primært kræver paritetens RAID-niveauer tung behandling for at håndtere skriveoperationer, med forskellige niveauer, der har forskellige mængder beregning, der er nødvendig for hver operation. Dette introducerer latenstid, men begrænser ikke gennemstrømningen. Denne latenstid vil variere, dog baseret på implementeringen af RAID-niveauet samt på behandlingskapaciteten af det pågældende system. Hardware-RAID vil bruge noget som en generel CPU (ofte en Power eller ARM RISC-processor) eller en brugerdefineret ASIC til at håndtere dette, mens software-RAID afleverer dette til serverens egen CPU. Ofte er server-CPU'en faktisk hurtigere her, men forbruger systemressourcer. ASIC'er kan være meget hurtige, men er dyre at producere. Denne latenstid påvirker lagerydeevnen, men er meget svær at forudsige og kan variere fra nominel til dramatisk. Så jeg vil nævne den relative latenstidspåvirkning for hvert RAID-niveau, men vil ikke forsøge at måle den. I de fleste RAID-ydeevneberegninger ignoreres denne latenstid, men det er vigtigt at forstå, at den er til stede og, afhængigt af konfigurationen af arrayet, kan have en mærkbar indvirkning på en arbejdsbelastning.

Der er, det bør nævnes, en lille ydeevnepåvirkning på læseoperationer på grund af effektiviteter i layoutet af data på selve disken. Paritets-RAID kræver, at der er data på diskene, der er ubrugelige under en sund læseoperation, men ikke kan bruges til at fremskynde den. Dette resulterer faktisk i, at det er en anelse langsommere. Men denne påvirkning er latterligt lille og måles normalt ikke, og kan derfor ignoreres.

Faktorer som stripestørrelse påvirker selvfølgelig også ydeevnen, men da dette er konfigurerbart og ikke et iboende artefakt i noget RAID-niveau, vil jeg ignorere det her. Det er ikke en faktor ved valg af et RAID-niveau i sig selv, men kun ved konfigurering af et, når det er valgt.

Den endelige faktor, jeg vil nævne, er læse-til-skrive-forholdet for lageroperationer. Nogle RAID-arrays vil blive brugt næsten rent til læseoperationer, nogle næsten udelukkende til skriveoperationer, men de fleste bruger en blanding af de to, sandsynligvis noget som firs procent læsning og tyve procent skrivning. Dette forhold er meget vigtigt for at forstå den ydeevne, du vil få fra dit specifikke RAID-array, og for at forstå, hvordan hvert RAID-niveau vil påvirke dig. Jeg refererer til dette som læse/skrive-blandingen.

Vi måler lagerydeevne primært i IOPS. IOPS står for Input/Output Operations Per Second (ja, jeg ved, at bogstaverne ikke stemmer godt overens – det er, hvad det er.) Jeg bruger yderligere udtrykkene RIOPS for Read IOPS, WIOPS for Write IOPS og BIOPS for Blended IOPS, som ville komme med et forhold på 80/20 eller hvad som helst. Mange mennesker taler om lagerydeevne med et enkelt IOPS-tal. Når dette gøres, mener de normalt Blended IOPS ved 50/50. Sjældent kører nogen arbejdsbelastning dog ved 50/50, så det tal kan være ekstremt vildledende. To tal, RIOPS og WIOPS, er det, der er nødvendigt for at forstå ydeevne, og disse to tilsammen kan bruges til at finde enhver IOPS-blanding, der er nødvendig. For eksempel er en 50/50-blanding så enkel som (RIOPS * 0,5) + (WIOPS * 0,5). Den mere almindelige 80/20-blanding ville være (RIOPS * 0,8) + (WIOPS * 0,2).

Nu hvor vi har etableret nogle kriterier og baggrundsviden, vil vi dykke ned i vores RAID-niveauer og se, hvordan ydeevnen varierer på tværs af dem.

For alle RAID-niveauer beregnes Read IOPS-tallet ved hjælp af NX. Dette adresserer selvfølgelig ikke de nominelle overhead-tal, jeg nævner ovenfor. Dette er et "bedste tilfælde"-tal, men det virkelige tal er så tæt på, at det er meget praktisk blot at bruge denne formel. Tag antallet af spindler (N) og multiplicer med IOPS-ydeevnen for et individuelt drev (X). Husk, at drev ofte har forskellig læse- og skriveydeevne, så sørg for at bruge drevets Read IOPS-vurdering eller testede hastighed til Read IOPS-beregningen og Write IOPS-hastigheden eller testede hastighed til Write IOPS-beregningen.

RAID 0

RAID 0 er det nemmeste RAID-niveau at forstå, fordi der effektivt ikke er nogen overhead at bekymre sig om, ingen ressourcer forbrugt til at drive det, og både læsning og skrivning får den fulde fordel af hver spindel, hele tiden. Så for RAID 0 er vores formel for skriveydeevne meget enkel: NX. RAID 0 er altid det mest yderige RAID-niveau.

Et eksempel ville være et otte-spindel RAID 0-array. Hvis et individuelt drev i arrayet leverer 125 IOPS, ville vores beregning være fra N = 8 og X = 125, så 8 * 125 giver 1.000 IOPS. Da både læse- og skrive-IOPS er de samme her, er det ekstremt enkelt, da vi får 1K RIOPS, 1K WIOPS og 1K med enhver blanding deraf. Meget enkelt. Hvis vi ikke kendte de absolutte IOPS for en individuel spindel, kunne vi referere til et otte-spindel RAID 0 som leverende 8X Blended IOPS.

RAID 10

RAID 10 har det næstenkleste RAID-niveau at beregne. Fordi RAID 10 er et RAID 0-stripe af spejlsæt, har vi ingen overhead at bekymre os om fra stribningen, men hvert spejl skal skrive de samme data to gange for at skabe spejlingen. Dette halverer vores skriveydeevne sammenlignet med et RAID 0-array med det samme antal drev. Det giver os en skriveydeevneformel på blot: NX/2 eller 0,5NX.

Det bør bemærkes, at ved samme kapacitet, frem for det samme antal spindler, har RAID 10 den samme skriveydeevne som RAID 0, men dobbelt læseydeevne – simpelthen fordi det kræver dobbelt så mange spindler for at matche den samme kapacitet.

Så et otte-spindel RAID 10-array ville være N = 8 og X = 125, og vores resulterende beregning kommer ud til at være (8 * 125)/2, hvilket er 500 WIOPS eller 4X WIOPS. En 50/50-blanding ville resultere i 750 Blended IOPS (1.000 Read IOPS og 500 Write IOPS.)

Denne formel gælder ligeledes for RAID 1, RAID 10, RAID 100 og RAID 01.

Ualmindelige muligheder såsom triple-spejling i RAID 10 ville ændre denne skrivepenalty. RAID 10 med triple-spejling ville for eksempel være NX/3.

RAID 5

Selvom RAID 5 er forældet og aldrig bør bruges i nye arrays, medtager jeg det her, fordi det er et velkendt og almindeligt brugt RAID-niveau, og dets ydeevne skal forstås. RAID 5 er det mest grundlæggende af de moderne paritetens RAID-niveauer. RAID 2, 3 og 4 findes ikke længere i produktionssystemer, og vi vil derfor ikke se nærmere på deres ydeevne her. RAID 5, selv om det ikke anbefales til brug i dag, er fundamentet for andre moderne paritetens RAID-niveauer, og er derfor vigtigt at forstå.

Paritets-RAID tilføjer et noget kompliceret behov for at verificere og genopskrive paritet med hver skrivning, der går til disk. Det betyder, at et RAID 5-array skal læse dataene, læse pariteten, skrive dataene og til sidst skrive pariteten. Fire operationer for hver effektiv en. Dette giver os en skrivepenalty på RAID 5 på fire. Så formlen for RAID 5-skriveydeevne er NX/4.

Så i henhold til otte-spindel-eksemplet, hvor IOPS for skrivning for en individuel spindel er 125, ville vi få følgende beregning: (8 * 125)/4 eller 2X Write IOPS, hvilket svarer til 250 WIOPS. I en 50/50-blanding ville dette resultere i 625 Blended IOPS.

RAID 6

RAID 6 er efter RAID 10 sandsynligvis det mest almindelige og nyttige RAID-niveau i brug i dag. RAID 6 er dog baseret på RAID 5 og har endnu et niveau af paritet. Dette gør det dramatisk sikrere end RAID 5, hvilket er meget vigtigt, men pålægger også en dramatisk skrivepenalty, da hver skriveoperation kræver, at diskene læser dataene, læser den første paritet, læser den anden paritet, skriver dataene, skriver den første paritet og derefter til sidst skriver den anden paritet. Dette svarer til en seks gange skrivepenalty, hvilket er temmelig dramatisk. Så vores formel er NX/6.

Fortsat vores eksempel får vi (8 * 125)/6, hvilket svarer til ~167 Write IOPS eller 1,33X. I vores 50/50-blandingseksempel er dette en ydeevne på 583,5 Blended IOPS. Som du kan se, forårsager paritetsskrivninger et meget hurtigt fald i skriveydeevnen og et mærkbart fald i blandet ydeevne.

RAID 7 (aka RAID 5.3 eller RAID 7.3)

RAID 7 er et noget ikke-standard RAID-niveau med tredobbelt paritet baseret på den eksisterende enkeltparitet af RAID 5 og den eksisterende dobbeltparitet af RAID 6. Den eneste nuværende implementering af RAID 7 er ZFS' RAIDZ3. Fordi RAID 7 indeholder al overhead fra både RAID 5 og RAID 6 plus den yderligere overhead fra den tredje paritetskomponent, har vi en skrivepenalty på svimlende otte gange. Så vores formel til at finde RAID 7-skriveydeevne er NX/8.

I vores eksempel ville dette betyde, at (8 * 125)/8 svarer til 125 Write IOPS eller 1X. Så med otte drev i vores array ville vi kun få skriveydeevnen for et enkelt, selvstændigt drev. Det er betydelig overhead. Vores blandede 50/50 IOPS ville svare til kun 562,5.

Komplekst RAID

Komplekse RAID-niveauer eller indlejrede RAID-niveauer såsom RAID 50, 60, 61, 16 osv. kan findes ved hjælp af oplysningerne ovenfor og ved at opdele RAID i dets komponenter og anvende hver ved hjælp af formlerne angivet ovenfor. Der er ingen simpel formel for disse niveauer, fordi de har varierende konfigurationer. Det er nødvendigt at opdele dem i deres komponenter og anvende formlerne flere gange.

RAID 60 med tolv drev, to sæt af seks drev, hvor hvert drev er 150 IOPS, ville blive udført med to RAID 6-arrays. Det ville være NX for RAID 0, hvor N er to (for to RAID 6-arrays), og X er den resulterende ydeevne for hvert RAID 6. Hvert RAID 6-sæt ville være (6 * 150)/6. Så det fulde array ville være 2((6 * 150)/6), hvilket resulterer i 300 Write IOPS.

Det samme eksempel som ovenfor, men konfigureret som RAID 61, et spejlet par af RAID 6-arrays, ville have den samme ydeevne per RAID 6-array, men anvendt på RAID 1-formlen, som er NX/2 (hvor X er den resulterende ydeevne for hvert RAID-array.) Så den endelige formel ville være 2((6 * 150)/6)/2, hvilket svarer til 150 Write IOPS fra tolv drev.

Ydeevne som en faktor af kapacitet

Når vi producerer RAID-ydeevneformler, tænker vi på disse i form af antallet af spindler, hvilket er utroligt fornuftigt. Dette er meget nyttigt til at bestemme ydeevnen af et foreslået array eller endda et eksisterende, hvor måling ikke er mulig, og giver os mulighed for at sammenligne den relative ydeevne mellem forskellige foreslåede muligheder. Det er i disse termer, at vi universelt tænker på RAID-ydeevne.

Dette er dog ikke altid en god tilgang, fordi vi typisk ser på RAID som en faktor af kapacitet snarere end af ydeevne eller spindelantal. Det ville være meget sjældent, men bestemt muligt, at nogen ville overveje et otte-drev RAID 6-array versus et otte-drev RAID 10-array. En gang i mellem vil dette forekomme på grund af en chassisbegrænsning eller en anden lignende årsag. Men typisk ses RAID-arrays fra synspunktet om samlet arraykapacitet (fx brugbar kapacitet) frem for spindelantal, ydeevne eller nogen anden faktor. Det er mærkeligt, at vi derefter skifter til at se RAID-ydeevne som en funktion af spindelantal.

Hvis vi ændrer vores synspunkt og drejer om kapacitet som den fælles faktor, mens vi stadig antager, at individuel drevkapacitet og ydeevne (X) forbliver konstant mellem sammenligninger, ankommer vi til et fuldstændig anderledes ydeevnelandskab. Ved at gøre dette ser vi for eksempel, at RAID 0 ikke længere er det mest yderige RAID-niveau, og at læseydeevnen varierer dramatisk i stedet for at være konstant.

Kapacitet er en ustabil ting, men vi kan destillere det ned til antallet af spindler, der er nødvendige for at nå den ønskede kapacitet. Dette gør denne diskussion langt nemmere. Så vores første skridt er at bestemme vores spindelantal nødvendigt for rå kapacitet. Hvis vi har brug for en kapacitet på 10 TB og bruger 1 TB-drev, ville vi have brug for ti spindler, for eksempel. Eller hvis vi har brug for 3,2 TB og bruger 600 GB-drev, ville vi have brug for seks spindler. Vi vil, anderledes end før, referere til vores spindelantal som R. Som før repræsenteres ydeevnen for det individuelle drev som X. (R bruges her for at betegne, at dette er rå kapacitetantal, frem for det samlede antal spindler.)

RAID 0 forbliver enkelt – ydeevnen er stadig RX, da der ikke er yderligere drev. Både læse- og skrive-IOPS er simpelthen NX.

RAID 10 har RX Write IOPS, men 2RX Read IOPS. Dette er dramatisk. Pludselig, når vi ser ydeevne som en faktor af stabil kapacitet, finder vi, at RAID 10 har dobbelt læseydeevne over RAID 0!

RAID 5 bliver en smule mere komplekst. Write IOPS ville udtrykkes som ((R + 1) * X)/4. Read IOPS udtrykkes som ((R + 1) * X).

RAID 6 følger som forventet det mønster, RAID 5 projicerer. Write IOPS for RAID 6 er ((R + 2) * X)/6. Og Read IOPS udtrykkes som ((R + 2) * X).

RAID 7 falder lige ind i linjen. RAID 7 Write IOPS ville være ((R + 3) * X)/8. Og Read IOPS er ((R + 3) * X).

Dette synspunkt ændrer den måde, vi tænker på ydeevne, og, når vi ser rent på læseydeevne, bliver RAID 0 det langsomste RAID-niveau frem for det hurtigste, og RAID 10 bliver det hurtigste for både læsning og skrivning, uanset hvad værdierne er for R og X!

Hvis vi tager et virkeligt eksempel med 10 2 TB-drev for at opnå 20 TB brugbar kapacitet, hvor hvert drev har 100 IOPS ydeevne og antager en 50/50-blanding, ville de resulterende IOPS være: RAID 0 med 1.000 Blended IOPS, RAID 10 med 1.500 Blended IOPS (2.000 RIOPS / 1.000 WIOPS), RAID 5 med 687,5 Blended IOPS (1.100 RIOPS / 275 WIOPS), RAID 6 med 700 Blended IOPS (1.200 RIOPS / 200 WIOPS) og endelig RAID 7 med 731,25 Blended IOPS (1.300 RIOPS / 162,5 WIOPS.) RAID 10 er en dramatisk vinder her.

Latenstid og systempåvirkning med software-RAID

Som jeg har angivet tidligere, har RAID 0 og RAID 10 effektivt ingen systemoverhead at overveje. Spejlingsoperationen kræver i det væsentlige ingen beregningsindsats og er for alle praktiske formål umåleligt lille. Paritets-RAID har beregningsoverhead, og dette resulterer i latenstid på lagerlaget og systemressourcer, der forbruges. Selvfølgelig, hvis vi bruger hardware-RAID, er disse ressourcer dedikeret til RAID-arrayet og har ingen funktion ud over at blive forbrugt i denne rolle. Hvis vi bruger software-RAID, er disse imidlertid generelle systemressourcer (primært CPU), der forbruges til formålene med RAID-arraybehandlingen.

Påvirkningen på selv et meget lille system med en stor mængde RAID er stadig meget lille, men den kan måles og bør overvejes, om end let. Latenstid og systempåvirkning er direkte relateret til hinanden.

Der er ingen simpel måde at angive latenstid og systempåvirkning for forskellige RAID-niveauer undtagen på denne måde: RAID 0 og RAID 10 har effektivt ingen latenstid eller påvirkning, RAID 5 har nogen latenstid og påvirkning, RAID 6 har ca. dobbelt så meget beregningslatenstid og -påvirkning som RAID 5, og RAID 7 har ca. tredobbelt beregningslatenstid og -påvirkning sammenlignet med RAID 5.

I mange tilfælde vil denne latenstid og systempåvirkning være så lille, at de ikke kan måles med standardsystemværktøjer, og efterhånden som moderne processorer bliver stadig kraftigere, vil latenstiden og systempåvirkningen fortsætte med at falde. Påvirkning er betragtet som ubetydelig for RAID 5- og RAID 6-systemer på selv lavklasse, commodity-hardware siden ca. 2001. Men det er muligt på stærkt belastede systemer med en stor mængde paritets-RAID-aktivitet, at der kan opstå konflikter mellem RAID-subsystemet og andre processer, der kræver systemressourcer.

Reference: The IT Hollow – Understanding the RAID Penalty

Artikel oprindeligt udgivet på StorageCraft Blog – RAID Performance.