Praktisk RAID-ytelse

Å velge et RAID-nivå er en øvelse i å balansere mange faktorer, inkludert kostnad, pålitelighet, kapasitet og selvfølgelig ytelse. RAID-ytelse kan være vanskelig å forstå, spesielt ettersom forskjellige RAID-nivåer bruker forskjellige teknikker og oppfører seg ganske forskjellig fra hverandre i noen tilfeller. I denne artikkelen vil jeg utforske de vanlige RAID-nivåene RAID 0, 5, 6 og 10 for å se hvordan ytelsen varierer mellom dem.

For formålene med denne artikkelen vil RAID 1 bli antatt å være et undergruppe av RAID 10. Dette er ofte en praktisk måte å tenke på RAID 1 – som rett og slett et RAID 10-array med bare ett enkelt speilet par-medlem. Siden RAID 1 virkelig er et enkelt par RAID 10 og oppfører seg som sådan, fungerer dette utmerket for å gjøre RAID-ytelse lett å forstå, ettersom det rett og slett mapper inn i RAID 10-ytelses­kurven.

Det er to typer ytelse å se på med all lagring: lesing og skriving. Når det gjelder RAID er lesing ekstremt enkelt og skriving er ganske komplekst. Leseytelse er effektivt stabil på tvers av alle RAID-typer. Skriving er imidlertid ikke det.

For å gjøre det lettere å diskutere ytelse trenger vi å definere noen begreper, da vi vil jobbe med noen ligninger. I diskusjonene våre vil vi bruke N for å representere det totale antallet stasjoner, ofte referert til som spindler, i vårt array, og vi vil bruke X for å referere til ytelsen til hver stasjon individuelt. Dette lar oss snakke i termer av relativ ytelse som en faktor av stasjonsytelsen, noe som lar oss abstrahere bort RAID-arrayet og slippe å tenke i termer av rå IOPS. Dette er viktig ettersom IOPS ofte er svært vanskelig å definere, men vi kan sammenligne ytelse på en meningsfull måte ved å snakke om det i forhold til de individuelle stasjonene i arrayet.

Det er også viktig å huske at vi bare snakker om ytelsen til selve RAID-arrayet, ikke et helt lagringsundersystem. Artefakter som minnecacher og solid state-cacher vil gjøre fantastiske ting for å endre den totale ytelsen til et lagringsundersystem, men endrer ikke fundamentalt ytelsen til selve RAID-arrayet under panseret. Det finnes ingen enkel formel for å bestemme hvordan forskjellige cache-alternativer vil påvirke den totale ytelsen, men det er tilstrekkelig å si at det kan være svært dramatisk, men dette avhenger ikke bare sterkt av cache-valgene i seg selv, men også sterkt av arbeidsbelastningen. Selv de største, raskeste, mest robuste cache-alternativene kan ikke endre den langsiktige, vedvarende ytelsen til et array.

RAID er komplekst og mange faktorer påvirker den endelige ytelsen. En er implementeringen av selve RAID-systemet. En dårlig implementering kan forårsake latenstid eller kan mislykkes i å dra nytte av de tilgjengelige spindlene (for eksempel å ha et RAID 1-array som kun leser fra én disk i stedet for fra begge samtidig!). Det er ingen enkel måte å ta høyde for mangler i spesifikke RAID-implementeringer, så vi må anta at alle fungerer til grensene for spesifikasjonen slik enhver enterprise RAID-system vil gjøre. Det er primært hobby- og forbruker-RAID-systemer som ikke gjør dette.

Noen typer RAID har også dramatiske mengder beregningsoverhead knyttet til seg, mens andre ikke har det. Primært krever paritetsnivåer for RAID tung prosessering for å håndtere skriveoperasjoner, med forskjellige nivåer som har forskjellige mengder beregning nødvendig for hver operasjon. Dette introduserer latenstid, men hemmer ikke gjennomstrømming. Denne latenstiden vil imidlertid variere basert på implementeringen av RAID-nivået samt på prosesseringskapasiteten til det aktuelle systemet. Hardware-RAID vil bruke noe som en generell CPU (ofte en Power eller ARM RISC-prosessor) eller en tilpasset ASIC for å håndtere dette, mens software-RAID sender dette til serverens egen CPU. Ofte er server-CPU-en faktisk raskere her men forbruker systemressurser. ASICs kan være svært raske men er dyre å produsere. Denne latenstiden påvirker lagringsytelsen men er svært vanskelig å forutsi og kan variere fra nominell til dramatisk. Så jeg vil nevne den relative latenstidspåvirkningen med hvert RAID-nivå, men vil ikke forsøke å måle det. I de fleste RAID-ytelsesberegninger ignoreres denne latenstiden, men det er viktig å forstå at den er til stede og kan, avhengig av konfigurasjonen av arrayet, ha en merkbar innvirkning på en arbeidsbelastning.

Det er, bør det nevnes, en liten ytelsespåvirkning på leseoperasjoner på grunn av effektivitet i layouten av data på selve disken. Paritetens RAID krever at det er data på diskene som er ubrukelig under en sunn leseoperasjon men ikke kan brukes til å fremskynde den. Dette resulterer faktisk i at det er litt tregere. Men denne påvirkningen er latterlig liten og måles normalt ikke og kan derfor ignoreres.

Faktorer som stripestørrelse påvirker selvfølgelig også ytelsen, men siden det er konfigurerbart og ikke et iboende artefakt i noe RAID-nivå, vil jeg ignorere det her. Det er ikke en faktor ved valg av et RAID-nivå i seg selv, men bare ved konfigurering av ett etter at det er valgt.

Den siste faktoren jeg vil nevne er lese-til-skrive-forholdet for lagringsoperasjoner. Noen RAID-arrays vil brukes nesten utelukkende til leseoperasjoner, noen nesten utelukkende til skriveoperasjoner, men de fleste bruker en blanding av de to – sannsynligvis noe som åtti prosent lesing og tjue prosent skriving. Dette forholdet er svært viktig for å forstå ytelsen du vil få fra ditt spesifikke RAID-array og for å forstå hvordan hvert RAID-nivå vil påvirke deg. Jeg refererer til dette som lese/skrive-blandingen.

Vi måler lagringsytelse primært i IOPS. IOPS står for Input/Output Operations Per Second (ja, jeg vet at bokstavene ikke stemmer godt – det er slik det er). Jeg bruker videre begrepene RIOPS for lese-IOPS, WIOPS for skrive-IOPS og BIOPS for blandede IOPS som vil ha et forhold 80/20 eller hva som helst. Mange snakker om lagringsytelse med ett enkelt IOPS-tall. Når dette gjøres mener de normalt blandede IOPS ved 50/50. Men sjelden kjører noen arbeidsbelastning ved 50/50, så det tallet kan være ekstremt misvisende. To tall – RIOPS og WIOPS – er det som trengs for å forstå ytelse, og disse to sammen kan brukes til å finne enhver IOPS-blanding som er nødvendig. For eksempel er en 50/50-blanding like enkelt som (RIOPS * .5) + (WIOPS * .5). Den mer vanlige 80/20-blandingen ville være (RIOPS * .8) + (WIOPS * .2).

Nå som vi har etablert noen kriterier og bakgrunnsforståelse, vil vi dykke ned i RAID-nivåene våre og se hvordan ytelsen varierer på tvers av dem.

For alle RAID-nivåer beregnes lese-IOPS-tallet ved å bruke NX. Dette adresserer ikke de nominale overhead-tallene jeg nevner ovenfor, selvfølgelig. Dette er et «best case»-tall, men det virkelige tall er så nært at det er svært praktisk å bare bruke denne formelen. Ta antall spindler (N) og multipliser med IOPS-ytelsen til en individuell stasjon (X). Husk at stasjoner ofte har forskjellig lese- og skriveytelse, så sørg for å bruke stasjonens lese-IOPS-vurdering eller testede hastighet for lese-IOPS-beregningen og skrive-IOPS-raten eller testede hastighet for skrive-IOPS-beregningen.

RAID 0

RAID 0 er det enkleste RAID-nivået å forstå fordi det effektivt ikke er noen overhead å bekymre seg om, ingen ressurser forbrukt for å drive det, og både lesing og skriving får full fordel av hver spindel hele tiden. Så for RAID 0 er formelen for skriveytelse svært enkel: NX. RAID 0 er alltid det mest ytelsesdyktige RAID-nivået.

Et eksempel ville være et åtte-spindlers RAID 0-array. Hvis en individuell stasjon i arrayet leverer 125 IOPS, ville beregningen vår være fra N = 8 og X = 125, altså 8 * 125 som gir 1 000 IOPS. Siden både lese- og skrive-IOPS er de samme her, er det ekstremt enkelt da vi får 1K RIOPS, 1K WIOPS og 1K med enhver blanding av disse. Svært enkelt. Hvis vi ikke visste de absolutte IOPS-ene til en individuell spindel, kunne vi referere til et åtte-spindlers RAID 0 som å levere 8X blandede IOPS.

RAID 10

RAID 10 har det nest enkleste RAID-nivået å beregne. Fordi RAID 10 er en RAID 0-stripe av speillsett, har vi ingen overhead å bekymre oss om fra stripen, men hvert speil må skrive de samme dataene to ganger for å opprette speilingen. Dette halverer skriveytelsen vår sammenlignet med et RAID 0-array med samme antall stasjoner. Dette gir oss en skriveytelsesformel på ganske enkelt: NX/2 eller .5NX.

Det bør bemerkes at ved samme kapasitet, snarere enn samme antall spindler, har RAID 10 den samme skriveytelsen som RAID 0 men dobbel leseytelse – rett og slett fordi det krever dobbelt så mange spindler for å matche samme kapasitet.

Så et åtte-spindlers RAID 10-array ville være N = 8 og X = 125, og den resulterende beregningen blir (8 * 125)/2 som er 500 WIOPS eller 4X WIOPS. En 50/50-blanding ville resultere i 750 blandede IOPS (1 000 lese-IOPS og 500 skrive-IOPS).

Denne formelen gjelder for RAID 1, RAID 10, RAID 100 og RAID 01 likt.

Uvanlige alternativer som tredobbelt speiling i RAID 10 ville endre denne skrivestraffen. RAID 10 med tredobbelt speiling ville for eksempel være NX/3.

RAID 5

Selv om RAID 5 er avviklet og aldri bør brukes i nye arrays, inkluderer jeg det her fordi det er et kjent og mye brukt RAID-nivå og ytelsen trenger å forstås. RAID 5 er det mest grunnleggende av de moderne paritetsnivåene for RAID. RAID 2, 3 og 4 finnes ikke lenger i produksjonssystemer, og vi vil derfor ikke se på ytelsen deres her. RAID 5, selv om det ikke anbefales for bruk i dag, er grunnlaget for andre moderne paritets-RAID-nivåer og er viktig å forstå.

Paritets-RAID legger til et noe komplisert behov for å verifisere og omskrive paritet med hver skriving som går til disk. Dette betyr at et RAID 5-array må lese dataene, lese pariteten, skrive dataene og til slutt skrive pariteten. Fire operasjoner for hver effektive én. Dette gir oss en skrivestraff på RAID 5 på fire. Så formelen for RAID 5 skriveytelse er NX/4.

Så etter åtte-spindler-eksempelet der skrive-IOPS for en individuell spindel er 125, ville vi få følgende beregning: (8 * 125)/4 eller 2X skrive-IOPS som kommer til 250 WIOPS. I en 50/50-blanding ville dette resultere i 625 blandede IOPS.

RAID 6

RAID 6 er etter RAID 10 sannsynligvis det mest vanlige og nyttige RAID-nivået i bruk i dag. RAID 6 er imidlertid basert på RAID 5 og har et annet nivå av paritet. Dette gjør det dramatisk sikrere enn RAID 5, noe som er svært viktig, men pålegger også en dramatisk skrivestraff ettersom hver skriveoperasjon krever at diskene leser dataene, leser den første pariteten, leser den andre pariteten, skriver dataene, skriver den første pariteten og til slutt skriver den andre pariteten. Dette blir en seks ganger skrivestraff, som er ganske dramatisk. Så formelen vår er NX/6.

Fortsetter vi med eksempelet vårt får vi (8 * 125)/6 som kommer ut til ~167 skrive-IOPS eller 1,33X. I vårt 50/50-blandingseksempel er dette en ytelse på 583,5 blandede IOPS. Som du kan se, forårsaker paritetsskrivinger en svært rask nedgang i skriveytelse og en merkbar nedgang i blandet ytelse.

RAID 7 (også kjent som RAID 5.3 eller RAID 7.3)

RAID 7 er et noe ikke-standard RAID-nivå med tredobbelt paritet basert på den eksisterende enkeltpariteten til RAID 5 og den eksisterende dobbeltpariteten til RAID 6. Den eneste nåværende implementeringen av RAID 7 er ZFS' RAIDZ3. Fordi RAID 7 inneholder all overhead fra både RAID 5 og RAID 6 pluss den ekstra overheaden til den tredje paritetskomponenten, har vi en skrivestraff på svimlende åtte ganger. Så formelen vår for å finne RAID 7 skriveytelse er NX/8.

I eksempelet vårt ville dette bety at (8 * 125)/8 ville komme til 125 skrive-IOPS eller 1X. Så med åtte stasjoner i arrayet vårt ville vi bare få skriveytelsen til en enkelt, frittstående stasjon. Det er betydelig overhead. Våre blandede 50/50-IOPS ville komme ut til kun 562,5.

Komplekse RAID-nivåer

Komplekse RAID-nivåer eller nestede RAID-nivåer som RAID 50, 60, 61, 16 osv. kan finnes ved å bruke informasjonen ovenfor og bryte RAID ned i komponentene og anvende hver ved å bruke formlene gitt ovenfor. Det finnes ingen enkel formel for disse nivåene fordi de har varierende konfigurasjoner. Det er nødvendig å bryte dem ned i komponentene og anvende formlene flere ganger.

RAID 60 med tolv stasjoner, to sett med seks stasjoner, der hver stasjon er 150 IOPS, ville gjøres med to RAID 6-er. Det ville være NX av RAID 0 der N er to (for to RAID 6-arrays) og X er den resulterende ytelsen til hver RAID 6. Hvert RAID 6-sett ville være (6 * 150)/6. Så hele arrayet ville være 2((6 * 150)/6). Noe som gir 300 skrive-IOPS.

Det samme eksempelet som ovenfor men konfigurert som RAID 61, et speilet par av RAID 6-arrays, ville ha samme ytelse per RAID 6-array, men anvendt på RAID 1-formelen som er NX/2 (der X er den resulterende ytelsen til hvert RAID-array). Så den endelige formelen ville være 2((6 * 150)/6)/2 som kommer til 150 skrive-IOPS fra tolv stasjoner.

Ytelse som en faktor av kapasitet

Når vi produserer RAID-ytelsesformler tenker vi på disse i termer av antall spindler, noe som er utrolig fornuftig. Dette er svært nyttig for å bestemme ytelsen til et foreslått array eller til og med et eksisterende der måling ikke er mulig, og gjør det mulig å sammenligne den relative ytelsen mellom forskjellige foreslåtte alternativer. Det er i disse termer at vi universelt tenker på RAID-ytelse.

Dette er ikke alltid en god tilnærming, derimot, fordi vi typisk ser på RAID som en faktor av kapasitet snarere enn ytelse eller spindeltall. Det ville være svært sjeldent, men absolutt mulig, at noen ville vurdere et åtte-stasjoners RAID 6-array versus et åtte-stasjoners RAID 10-array. Av og til vil dette forekomme på grunn av en chassisbegrensning eller en annen lignende grunn. Men typisk ses RAID-arrays fra standpunktet til total array-kapasitet (dvs. brukbar kapasitet) snarere enn spindeltall, ytelse eller annen faktor. Det er merkelig, derfor, at vi deretter bør bytte til å se RAID-ytelse som en funksjon av spindeltall.

Hvis vi endrer synspunktet og dreier rundt kapasitet som den felles faktoren, mens vi fortsatt antar at individuell stasjonskap­asitet og ytelse (X) forblir konstant mellom komparatorer, kommer vi frem til et helt annerledes ytelseslandskap. Ved å gjøre dette ser vi for eksempel at RAID 0 ikke lenger er det mest ytelsesdyktige RAID-nivået og at leseytelse varierer dramatisk i stedet for å være en konstant.

Kapasitet er en lunefull ting, men vi kan destillere det ned til antall spindler som er nødvendig for å nå ønsket kapasitet. Dette gjør denne diskusjonen langt enklere. Så vårt første steg er å bestemme spindeltallet som trengs for råkapasitet. Hvis vi trenger en kapasitet på 10TB og bruker 1TB-stasjoner, ville vi trenge ti spindler, for eksempel. Eller hvis vi trenger 3,2TB og bruker 600GB-stasjoner, ville vi trenge seks spindler. Vi vil, annerledes enn før, referere til spindeltallet vårt som R. Som før er ytelsen til den individuelle stasjonen representert som X. (R brukes her for å angi at dette er råkapasitetstellingen, snarere enn det totale antallet spindler.)

RAID 0 forblir enkelt – ytelsen er fortsatt RX ettersom det ikke er noen ekstra stasjoner. Både lese- og skrive-IOPS er rett og slett NX.

RAID 10 har RX skrive-IOPS men 2RX lese-IOPS. Dette er dramatisk. Plutselig, når vi ser ytelsen som en faktor av stabil kapasitet, finner vi at RAID 10 har dobbel leseytelse over RAID 0!

RAID 5 blir litt mer komplisert. Skrive-IOPS ville uttrykkes som ((R + 1) * X)/4. Lese-IOPS uttrykkes som ((R + 1) * X).

RAID 6 følger, som vi forventer, mønsteret som RAID 5 projiserer. Skrive-IOPS for RAID 6 er ((R + 2) * X)/6. Og lese-IOPS uttrykkes som ((R + 2) * X).

RAID 7 faller rett i linje. RAID 7 skrive-IOPS ville være ((R + 3) * X)/8. Og lese-IOPS er ((R + 3) * X).

Dette perspektivet endrer måten vi tenker om ytelse på, og når vi bare ser på leseytelse, blir RAID 0 det tregeste RAID-nivået snarere enn det raskeste, og RAID 10 blir det raskeste for både lesing og skriving uavhengig av hva verdiene er for R og X!

Hvis vi tar et virkelig eksempel på 10 2TB-stasjoner for å oppnå 20TB brukbar kapasitet med hver stasjon som har 100 IOPS ytelse og antar en 50/50-blanding, ville de resulterende IOPS være: RAID 0 med 1 000 blandede IOPS, RAID 10 med 1 500 blandede IOPS (2 000 RIOPS / 1 000 WIOPS), RAID 5 med 687,5 blandede IOPS (1 100 RIOPS / 275 WIOPS), RAID 6 med 700 blandede IOPS (1 200 RIOPS / 200 WIOPS) og til slutt RAID 7 med 731,25 blandede IOPS (1 300 RIOPS / 162,5 WIOPS). RAID 10 er en dramatisk vinner her.

Latenstid og systeminnvirkning med software-RAID

Som jeg har uttalt tidligere, har RAID 0 og RAID 10 effektivt ingen systemoverhead å vurdere. Speilingsoperasjonen krever i det vesentlige ingen beregningsinnsats og er, for alle praktiske formål, umålbart liten. Paritetens RAID har beregningsoverhead, og dette resulterer i latenstid på lagringslaget og systemressurser som forbrukes. Selvfølgelig, hvis vi bruker hardware-RAID, er disse ressursene dedikert til RAID-arrayet og har ingen funksjon annet enn å forbrukes i denne rollen. Hvis vi bruker software-RAID, er imidlertid disse generelle systemressurser (primært CPU) som forbrukes for formålene til RAID-array-prosessering.

Innvirkningen på selv et svært lite system med en stor mengde RAID er fortsatt svært liten, men den kan måles og bør vurderes, om enn lett. Latenstid og systeminnvirkning er direkte relatert til hverandre.

Det finnes ingen enkel måte å angi latenstid og systeminnvirkning for forskjellige RAID-nivåer annet enn på denne måten: RAID 0 og RAID 10 har effektivt ingen latenstid eller innvirkning, RAID 5 har noe latenstid og innvirkning, RAID 6 har omtrent dobbelt så mye beregningslatenstid og innvirkning som RAID 5, og RAID 7 har omtrent tre ganger så mye beregningslatenstid og innvirkning som RAID 5.

I mange tilfeller vil denne latenstiden og systeminnvirkningen være så liten at den ikke kan måles med standard systemverktøy, og etter hvert som moderne prosessorer blir stadig kraftigere, vil latenstiden og systeminnvirkningen fortsette å avta. Innvirkning har blitt ansett som neglisjerbar for RAID 5 og RAID 6-systemer på selv lavend-maskinvare siden omtrent 2001. Men det er mulig på sterkt belastede systemer med en stor mengde paritets-RAID-aktivitet at det kan være konkurranse mellom RAID-undersystemet og andre prosesser som krever systemressurser.

Referanse: The IT Hollow – Forstå RAID-straffen

Artikkelen ble opprinnelig publisert på StorageCraft-bloggen – RAID-ytelse.