Beregn IOPS i en lagringsgruppe

Når det gjelder å måle et lagringssystemets samlede ytelse, er InOP / Output Operations Per Second (IOPS) fremdeles den vanligste metrikken i bruk. Det er en rekke faktorer som går ut på å beregne IOPS-evnen til et individuelt lagringssystem.

I denne artikkelen gir jeg introduksjonsinformasjon som går inn i beregninger som vil hjelpe deg å finne ut hva systemet ditt kan gjøre. Spesifikt forklarer jeg hvordan individuelle lagringskomponenter påvirker den totale IOPS-evnen. Jeg går ikke inn på alvorlig innviklede matematiske formler, men jeg gir deg praktisk veiledning og noen formler som kan hjelpe deg i planleggingen. Her er tre notater du må huske på når du leser artikkelen:

  • Publiserte IOPS-beregninger er ikke slutten på alle lagringsegenskaper. Selgere måler ofte IOPS under bare de beste forhold, så det er opp til deg å verifisere informasjonen og sørge for at løsningen tilfredsstiller dine miljøbehov.
  • IOPS-beregninger varierer vilt basert på typen arbeidsmengde som håndteres. Generelt er det tre ytelseskategorier relatert til IOPS: tilfeldig ytelse, sekvensiell ytelse og en kombinasjon av de to, som måles når du vurderer tilfeldig og sekvensiell ytelse på samme tid.
  • Informasjonen som presenteres her er ment å være veldig generell og fokuserer først og fremst på tilfeldige arbeidsmengder.

IOPS beregninger

Hver disk i lagringssystemet ditt har en maksimal teoretisk IOPS-verdi som er basert på en formel. Diskytelse - og IOPS - er basert på tre viktige faktorer:

  • Rotasjonshastighet (aka spindelhastighet). Målt i omdreininger per minutt (RPM) roterer de fleste diskene du vil vurdere for lagring av bedriften med hastigheter på 7.200, 10.000 eller 15.000 o / min, og de to sistnevnte er de vanligste. En høyere rotasjonshastighet er assosiert med en disk med høyere ytelse. Denne verdien brukes ikke direkte i beregninger, men den er svært viktig. De tre andre verdiene avhenger sterkt av rotasjonshastigheten, så jeg har inkludert den for fullstendighet.
  • Gjennomsnittlig latenstid. Tiden det tar for sektoren på disken som blir tilgang til å rotere på plass under et lese / skrivehode.
  • Gjennomsnittlig søker tid. Tiden (i ms) det tar for harddiskens lese- / skrivehode å plassere seg over sporet som blir lest eller skrevet. Det er både lese- og skrivesøk-tider; ta gjennomsnittet av de to verdiene.

For å beregne IOPS-området bruker du denne formelen: Gjennomsnittlig IOPS: Del 1 med summen av gjennomsnittlig latenstid i ms og den gjennomsnittlige søketiden i ms (1 / (gjennomsnittlig latenstid i ms + gjennomsnittlig søketid i ms).

Eksempelstasjon:

  • Modell: Western Digital VelociRaptor 2, 5 "SATA-harddisk
  • Rotasjonshastighet: 10 000 o / min
  • Gjennomsnittlig latenstid: 3 ms (0.003 sekunder)
  • Gjennomsnittlig søketid: 4, 2 (r) /4, 7 (w) = 4, 45 ms (0, 0045 sekunder)
  • Beregnet IOPS for denne disken: 1 / (0, 003 + 0, 0045) = omtrent 133 IOPS

Så denne eksempeldrevet kan støtte rundt 133 IOPS. Sammenlign dette med diagrammet nedenfor, og du vil se at verdien på 133 faller innenfor den observerte virkelige ytelsen som vises på 10 K RPM-stasjoner.

I stedet for å jobbe gjennom en formel for dine individuelle disker, er det imidlertid et antall ressurser tilgjengelig som skisserer gjennomsnittlige observerte IOPS-verdier for en rekke forskjellige typer disker. For enkel beregning kan du bruke disse verdiene med mindre du tror at dine egne disker vil variere veldig av en eller annen grunn.

Nedenfor viser jeg noen av verdiene jeg har sett og brukt i mitt eget miljø til grove planleggingsformål. Som du ser, endres ikke verdiene for hver type stasjon radikalt fra kilde til kilde.

kilder:

  • http://blog.aarondelp.com/2009/10/its-now-all-about-iops.html
  • http://www.yellow-bricks.com/2009/12/23/iops/
  • http://www.tomshardware.com/forum/251893-32-raid-raid
Merk: Stasjonstypen går ikke inn i ligningen i det hele tatt. Visst, SAS-disker vil prestere bedre enn de fleste SATA-disker, men det er bare fordi SAS-disker vanligvis brukes til bedriftsapplikasjoner på grunn av deres ofte større pålitelighet, slik det er bevist gjennom deres mellomtid mellom feil (MTBF) -verdier. Hvis en leverandør bestemte seg for å gi ut en 15K RPM SATA-disk med lav latenstid og søke tidsverdier, ville den også ha en høy IOPS-verdi.

Multidisk-matriser

Foretak installerer ikke en enkelt disk om gangen, så beregningene ovenfor er ganske meningsløse med mindre de kan oversettes til multidisk-sett. Heldigvis er det enkelt å oversette rå IOPS-verdier fra enkeltdisk til flere diskimplementeringer; det er en enkel multiplikasjonsoperasjon. Hvis du for eksempel har ti 15 K RPM-plater, hver med 175 IOPS-kapasitet, har disksystemet en prestasjonsevne på 1 750 IOPS. Men dette er bare hvis du valgte en RAID-0 eller bare en haug med disks (JBOD) implementering. I den virkelige verden brukes sjelden RAID 0 fordi tapet av en enkelt disk i matrisen vil føre til tap av alle data i matrisen.

La oss utforske hva som skjer når du begynner å se på andre RAID-nivåer.

IOPS RAID-straff

Den kanskje viktigste IOPS-beregningskomponenten for å forstå ligger i riket til skrivestraff assosiert med en rekke RAID-konfigurasjoner. Med unntak av RAID 0, som ganske enkelt er en rekke disker som er sammensveiset for å skape et større lagringsbasseng, er RAID-konfigurasjoner avhengige av det faktum at skriveoperasjoner faktisk resulterer i flere skrivinger til matrisen. Denne egenskapen er grunnen til at forskjellige RAID-konfigurasjoner er egnet for forskjellige oppgaver.

For hver forespørsel om tilfeldig skriving krever RAID 5 for eksempel mange diskoperasjoner, noe som har en betydelig innvirkning på rå IOPS-beregninger. For generelle formål, godta at RAID 5-skriver krever 4 IOPS per skriveoperasjon. RAID 6s høyere beskyttelse dobbel feiltoleranse er enda verre i denne forbindelse, noe som resulterer i en "IO-straff" på 6 operasjoner; planlegger med andre ord 6 IOPS for hver tilfeldig skriveoperasjon. For leseoperasjoner under RAID 5 og RAID 6, er en IOPS en IOPS; det er ingen negativ ytelse eller IOPS-innvirkning på leseoperasjoner. Vær også oppmerksom på at RAID 1 pålegger en straff på 2 til 1 IO.

Diagrammet nedenfor oppsummerer lese og skrive RAID-straffer for de vanligste RAID-nivåene.

Paritetsbaserte RAID-systemer introduserer også annen tilleggsbehandling som følger av behovet for å beregne paritetsinformasjon. Jo mer paritetsbeskyttelse du legger til et system, desto mer behandlingsoverhead pådras deg. Som du kanskje forventer, er den totale pålagte straffen veldig avhengig av balansen mellom lese- og skrivebelastning.

En god startformel er nedenfor. Denne formelen bruker ikke IOPS-matrisen; den bruker en arbeidsmengde IOPS-verdi du kan hente på egen hånd eller ved å bruke et slags beregningsverktøy, for eksempel Exchange Server-kalkulatoren.

(Total arbeidsmengde IOPS * Prosent av arbeidsmengden som er leseoperasjoner) + (Total arbeidsmengde IOPS * Prosentandel av arbeidsmengden som er leseoperasjoner * RAID IO Straff)

Kilde: http://www.yellow-bricks.com/2009/12/23/iops/

La oss som et eksempel anta følgende:

  • Totalt IOPS-behov: 250 IOPS
  • Les arbeidsmengde: 50%
  • Skriv arbeidsmengde: 50%
  • RAID-nivå: 6 (IO-straff på 6)

Resultat: Du trenger en matrise som kan støtte 875 IOPS for å støtte en 250 IOPS RAID 6-basert arbeidsmengde som er 50% skriver.

Dette kan være en ubehagelig overraskelse for noen organisasjoner, da det indikerer at antall disker kan være viktigere enn størrelsen (dvs. at du trenger tolv 7.200 RPM, syv 10 K RPM eller fem 15 K RPM plater for å støtte dette IOPS-behovet ).

Transportvalget

Det er også viktig å forstå hva som ikke er inkludert i rånumrene: transportvalget - iSCSI eller Fiber Channel. Selv om transportvalget er en viktig faktor for mange organisasjoner, påvirker det ikke direkte IOPS-beregningene. (Ingen av formlene vurderer transporten som brukes.)

Hvis du vil ha mer bevis på at valget av iSCSI / Fiber Channel ikke nødvendigvis direkte påvirker IOPS-beregningene dine, kan du lese denne artikkelen på NetApps nettsted.

Transportvalget er viktig, men det er ikke det viktigste valget som mange vil gjøre det for å være. For større organisasjoner som har betydelige transportbehov (dvs. mellom serverne og lagring), er Fiber Channel et godt valg, men dette valget driver ikke IOPS-vogna.

Sammendrag

For å forstå IOPS-behovene dine intrikat, må du vite mye, inkludert spesifikke disktekniske forhold, arbeidsmengdens fordeling som en funksjon av lese kontra skriving, og RAID-nivået du har tenkt å bruke. Når du implementerer løsningen din, kan du bruke verktøy som er skreddersydd til IOPS-analyse, for eksempel Iometer, for å få spesifikke ytelsesverdier i sanntid. Dette forutsetter at du har en løsning på plass som du kan måle.

Hvis du fremdeles er i planleggingsfasen eller et dypt analysenivå ganske enkelt ikke er nødvendig for dine behov, vil generalitetene som presenteres i denne artikkelen hjelpe deg med å finne ut av dine behov.

Vil du følge med på Scott Lowes innlegg på TechRepublic?

  • Registrer deg automatisk på nyhetsbrevet Servere og lagring
  • Abonner på RSS-feed for servere og lagring
  • Følg Scott Lowe på Twitter

© Copyright 2020 | mobilegn.com