PowerStore: Effektive teknikker for å vurdere ytelsen til lagringsarrayet

Merk: Ytelsestesting er bare gyldig hvis alt er konfigurert i henhold til anbefalte fremgangsmåter for PowerStore og det ikke er noen tilkoblings- eller konfigurasjonsproblemer. Ellers produserer testen sannsynligvis irrelevante data.

• Test ved hjelp av variabler som ligner på hva den virkelige arbeidsbelastningen/miljøet skal være. Husk at de fleste verktøy er simulatorer og aldri oppnår 100% av en ekte produksjonsarbeidsmengde simulert.
• Hvis arbeidsbelastningen varierer mye, kan du vurdere å utføre flere gjentakelser av lese-/skrivetester med varierende blokkstørrelser og tilgangsmønstre.
• Bruk flertrådige og asynkrone operasjoner eller tester for å sikre parallelle eller samtidige ytelsesfunksjoner og sikre at det samlede samlede gjennomstrømmingspotensialet utøves. 
• Vurder og gjennomgå bransjestandard benchmarks for utstyret som vurderes som de er relatert til bedriftens produksjonsbelastning.
• Unngå å teste mot tomt eller lite plassbrukende filsystem og/eller volumer. Hvis du ikke forhåndstildeler plass på skrive-arbeidsbelastninger, kan du se ventetid på grunn av allokering av plass under testen.
• Ikke glem å teste Read I/O, da dette vanligvis er den dominerende av de to i de fleste miljøer. Vær oppmerksom på pakke-/rammetap i nettverksinfrastrukturen under testingen.
• Kontroller at du tester mot flere enheter for å simulere et typisk miljø med mange verter eller klienter. På PowerStore er for eksempel et godt tall 16 volumer. Antall volumer samsvarer vanligvis med antallet verter eller klienter som brukes (fysisk eller virtuelt). Det er her samtidighet oppnås.

 

Verktøy og simulatorer
for benchmarkingHusk at de fleste verktøy er simulatorer og sannsynligvis aldri får 100% av en ekte produksjonsarbeidsmengde simulert. Disse benchmarking-verktøyene brukes til å få en ide om hvordan ytelsen kunne, burde eller ville være i visse situasjoner. Dell eier ikke disse verktøyene og er ikke ansvarlig for eventuelle problemer eller problemer som kan være forbundet med dem.

I alle ytelsestestsituasjoner må du sørge for at verktøy med asynkron- og flertrådsfunksjoner brukes. Eksempler på disse verktøyene er:

• Fleksibel I/O-tester (FIO)
• IOmeter
• Vdbenk (krever en Oracle-konto)
• NFSometer (Kun Fedora/NFS)
• Intels sjekkliste for NAS-ytelse

 

Unngå følgende typer tester:

• Kopier og lim inn
• Dra og slipp
• Sikkerhetskopiering av enkelt filsystem til disk
• DD-tester
• Større
• Stort
• Mkfile
• Pakke ut, pakke ut og komprimere

Det er visse ting å være oppmerksom på i de fleste ytelsestestingsscenarier. Denne delen er ikke en erstatning for å forstå størrelsen og egenskapene for workloader. Hvis du imidlertid mangler tidligere data og trenger et grovt estimat av programmets virkemåte for å kunne måle PowerStore-funksjonene (ikke spesifikk workloadytelse), bør du vurdere følgende faktorer:

 

 

IODepth (kødybde)
En lav IOdepth (eller ikke høy nok) kan begrense din potensielle gjennomstrømning avhengig av situasjonen. Kontroller derfor alltid at IOdepth er høy nok til å gjenspeile eller emulere samtidighetskravene til en arbeidsbelastning. En IOdepth som er for lav, bruker kanskje ikke enheten til sitt fulle potensial på riktig måte. Vær også forsiktig med for høy IOdybde, dette kan føre til betydelig kø på enheten, og avhengig av enhetens servicetid kan det være større responstider som et resultat. Dette kan reflektere hvordan et overbelastet system kan se ut.

For denne testen er tallene betydelig lavere når det er en IOdybde på en sammenligning med en IOdybde av noe mer virkelig, som 64. Husk at dette er med en all-flash-array, og dermed blir dette konseptet sett i sin ekstreme, men stadig mer vanlige, form.

IOdepth=1" det er rundt ~30,000 Input and Output Operations Per Second (IOPS) gjennomsnittlig for testen.

 

"IOdepth=64" er rundt ~107 000 IOPS snitt for testen.

 

 

"IOdepth=256" er rundt ~142 000 IOPS gjennomsnittlig for testen.

 

 

Som nevnt jevner ytelsen seg ut ved en viss IOdepth i de fleste konfigurasjoner. Her er det en kødybde på 512 og det er bare en liten økning i IOPS fra en IOdybde på 64.

IOdepth=512" er det rundt ~146 000 IOPS gj.sn. for testen.

 

 


Asynkron vs synkronisering
Det er to store forskjellige motorer som brukes. De mest populære og desidert mest effektive når det gjelder ytelse er "asynkron I / O." Den mindre effektive og mindre ytende motortypen er synkron I/O og brukes vanligvis med applikasjoner som har strenge krav til dataintegritet og forsikring. Synkron I/O finnes også i replikeringsteknologier nær null for gjenopprettingspunktmål (RPO). I ytelsestesting og ytelsestesting, fra et vertsperspektiv, betyr Asynchronous at en bekreftelse ikke er nødvendig for en enkelt I / O for å be om neste I / O. I synkrone workloader kreves det en bekreftelse for en I/O før den neste utstedes, og en bekreftelse (ACK) for hver påfølgende I/O som forespørres. Derfor har synkron I/O vanligvis en kø på 1 eller mindre og utnytter aldri ressursen fullt ut til sitt fulle potensial. Kobling av synkrone operasjoner med lavt eller enkelt antall tråder kan begrense ytelsespotensialet kraftig, så kontroller alltid at du utfører asynkron testing, og hvis du bruker synkron testing, må du sørge for å bruke flere tråder med mindre applikasjonsmiljøet eksplisitt påpeker at du ikke skal gjøre det.

Async (Libaio – opprinnelig Linux-asynkronisering) = 1 trådsynkronisering



(synkron I/O):  

 

 

Antall tråder
Tråder er viktige. Testing bør alltid gjøres ved hjelp av flere tråder, spesielt i synkrone tester / arbeidsbelastninger. Dette er for å forsøke å simulere flere gjentakelser av en jobb/test basert på virkemåten til en bedriftsapplikasjonsprosess. Flere tråder kombinert med samtidig aktivitet er der samlet gjennomstrømning av et system oppnås. De fleste asynkronmotorer bruker flere tråder, så du trenger ikke å bekymre deg for antall gjenger så mye. Uten å ha nok tråder under synkrone arbeidsbelastninger, kan du sterkt begrense den totale potensielle gjennomstrømningen til en belastningstest mot et system."

Multithreaded" betyr flere tråder som gjør arbeid parallelt. Hvis du for eksempel har en enkelt enhet som kan betjene 1000 IOPS i en synkron arbeidsbelastning, kommer dette ut til at enheten har 1 ms responstid uten kø (så uten kø bør servicetid og responstid være synonymt). Åpenbart kan enheter med 1 ms responstid gjøre mye mer arbeid enn 1000 IOPS, og dette oppnås ved å stable flere tråder eller parallelle strømmer av samme arbeidsbelastning. Så hvis du øker trådene (eller "ting som gjør denne spesifikke jobben") til 10, har du nå 10 individuelle tråder som gjør I / O til en enhet på 1 ms. Hver enkelt workloadtråd får fortsatt 1 ms, noe som betyr at hver tråd fortsatt bare oppnår 1000 IOPS, men nå får hele "prosessen" eller "jobben" som kjøres av disse flere trådene, 10 000 IOPS.

Det finnes verktøy og arbeidsbelastninger som kan treffe en enhets grenser tilstrekkelig med en enkelt tråd, og noen trenger mer. Oppsummert, når du simulerer en synkron belastning, vil du ha så mange tråder / arbeidere / strømmer som mulig uten å påvirke den totale responstiden. Det er et punkt der økning av trådantallet slutter å ha en positiv effekt (når enheten blir 100% opptatt). Vanligvis med asynkrone workloader blir antall tråder behandlet som standard. Nedenfor kan du for eksempel fremdeles se en forskjell mellom 1 tråd og 10 for en asynkron arbeidsbelastning, om enn ikke signifikant. Moralen i historien er at med asynkrone arbeidsbelastninger skal du ikke trenge å bekymre deg for tråder så mye. 

En enkelt tråd her kan oppnå 68 000 IOPS ved hjelp av "libaio" (asynkron) motor. 

 

Hvis du øker trådene (numjobs) til 10, kan du fortsatt se en økning opp i IOPS.

 

Når det gjelder synkrone arbeidsbelastninger, selv om dette er et ekstremt tilfelle, kan du ha to hovedfaktorer som gjør dette til en dårlig test, siden den synkrone naturen er synkron. 

sende I/O-1, vente på ACK, sende I/O-2, vente på ACK så videre

 Og ikke å kunne stable flere tråder for samme formål. 

jobb1=send I/O-1 - jobb2=send I/O-1 - jobb3=send I/O-1..... jobb1=få ack, send I/O-2 - jobb2=få ack, send I/O-2 - jobb3= få ack, send I/O-2 så videre

Direkte flagg

Med noen verktøy, spesielt * nix-baserte verktøy / OS kan du se et alternativ for "Direct I / O." Dette kan brukes med "asynkrone" motorer, og må ikke forveksles med "synkron" I/O. I noen verktøy uten dette flagget spesifisert kan du skrive til server cache og ikke direkte til disk. Det verten vil gjøre er å omgå sin egen cache og skrive direkte til disken. Dette er en viktig faktor når du tester lagring. Når du har det "direkte" flagget, skriver du teknisk til disk, selv om "disk" i dette tilfellet egentlig er lagringsbuffer. Dette er fortsatt akseptabelt for testformål, fordi selv med riktig arbeidsbelastning simulerer og etterligner du nøyaktig hvordan denne arbeidsbelastningen oppfører seg i et virkelig miljø, ettersom produksjonsbelastningen også vil treffe hurtigbufferen før du sender tilbake bekreftelsen. (Ikke føl deg lurt bare fordi du får ytelsestall for cache involvert og ikke bare backend-spindlene.)

 

Båndbredde (MB/s) kontra gjennomstrømning (IOPS)

Det er to hovedperspektiver du kan teste for. Gjennomstrømning i nettverks- og ytelsesverdenen refererer vanligvis til dataoverføring, men i SAN/blokkmiljø er det vanlig å bruke "gjennomstrømning" for å representere IOPS. Derfor må du først forstå arbeidsbelastningsegenskapene du tester for.

Båndbredde (MB/s) - Båndbredde er målet på data som du får plass til samtidig (eller innenfor X-intervall, vanligvis "per sekund") på et rør eller system. Dette betyr at den måler hvor mye data du har overført over en periode. Selv om båndbredde og IOPS ikke utelukker hverandre, kan du ha høyere eller lavere båndbreddetall med samme mengde IOPS, alt avhenger av blokkstørrelsen. Husk at du ikke måler hastighet med båndbredde, hastigheten er noe helt annet, og selv om det påvirker båndbredden, er det vanligvis noe du ikke kan kontrollere med workloader med tung båndbredde. Derfor, hvis du tester for båndbredde, bruk alltid større blokker (innen grunn) slik at dataene dine per I / O er større enn om du vil teste for IOPS, siden større blokker naturlig vil ta lengre tid å betjene. Hvis du for eksempel ønsker å oppnå 1 MB/s, men du bruker 8 KB blokkstørrelser, må du skyve rundt 125 IOPS for å oppnå dette. Men hvis du brukte 512 KB-blokker, ville det bare ta to (2) IOPS.
(Hvis du skulle beholde 125 IOPS og fortsatt øke blokkstørrelsen fra 8 KB til 512 KB, skyver du nå 64 MB / s!)

Men fordi det er mer data i en enkelt I / O, tar det vanligvis lengre tid å "pakke" som I / O (finne, streng sammen og så videre). Derfor kan servicetidene naturligvis være høyere. Noen ganger har du en mindre kø, så responstidene dine, selv om de naturlig er høyere, bør være ganske nærme. Husk at mens responstid spiller en rolle i hvor mye båndbredde du kan oppnå, oppveier økningen i hvor mye data det er per I / O vanligvis en liten økning i responstid (RT) per den typen I / O. Siden responstidene er høyere, vil du ikke at workloader med store blokker skal være tilfeldige. Så båndbredde-workloader har en tendens til å være sekvensielle. Når du introduserer en stor blokkarbeidsbelastning av tilfeldig karakter, blir den stabile dataoverføringshastigheten konsekvent avbrutt, og du begynner å føle effekten av de litt høyere responstidene per I/O.

Gjennomstrømning (IOPS) – Gjennomstrømning/IOPS er det vanligste perspektivet med småblokk-workloader, spesielt ettersom de blir mer tilfeldige. Alt over 32 KB-64 KB kan betraktes som en stor blokk. Med gjennomstrømning er de ovennevnte faktorene viktigst (ting som antall tråder, synkronisering eller asynkronisering, kødybde og så videre). Her prøver du å måle ikke hvor mye samlet data du kan overføre i løpet av X-intervallet, men heller hvor mange individuelle pakker (I / O-forespørsler) som bærer dataene du prøver å betjene (hvert x intervall). Miljøer som OLTP (bank) bryr seg lite om hvor mye data de kan overføre fordi deres datafotavtrykk vanligvis er lite. Imidlertid kan disse små datasettene være, og er vanligvis opptatt. Disse datasettene har en høy skjevhet (en liten mengde plass refereres, men varierer aggressivt og konsekvent). De små pakkene med data inneholder vanligvis bare forespørsler om å endre/oppdatere blokker med numeriske eller mindre strengverdier, og derfor er det ikke nødvendig med store I/O-pakker. Men på grunn av transaksjonens natur og fordi det er så mange av dem, ønsker vi å verifisere at vi kan holde tritt med hver enkelt etterspørsel. Jo mindre blokkstørrelsen er, desto mer IOPS kan du vanligvis oppnå i et gitt scenario, og selv om arbeidsbelastninger med små blokker for det meste er forbundet med tilfeldig tilgang, kan du oppnå enda mer gjennomstrømming med sekvensielle workloader med små blokker. Sekvensielle workloader med små blokker er imidlertid spesifikke og ikke like vanlige, så test disse scenariene bare hvis miljøet krever det.