PowerStore: Effektive teknikker til vurdering af storagesystemets ydeevne

Bemærk: Benchmarking er kun gyldig, hvis alt er konfigureret i henhold til bedste praksis for PowerStore, og der ikke er forbindelses- eller konfigurationsproblemer. Ellers producerer testen sandsynligvis irrelevante data.

• Test ved hjælp af variabler, der ligner det, den reelle arbejdsbyrde/det reelle miljø vil være. Husk, at de fleste værktøjer er simulatorer og aldrig opnår 100% af en ægte produktionsbelastning simuleret.
• Hvis arbejdsbelastningen spænder bredt, kan du overveje at udføre flere gentagelser af læse-/skrivetest med forskellige blokstørrelser og adgangsmønstre.
• Brug flertrådede og asynkrone handlinger eller tests for at sikre parallelle eller samtidige ydeevneegenskaber og sikre, at det samlede samlede gennemløbspotentiale udnyttes. 
• Overvej og gennemgå branchestandardbenchmarks for det udstyr, der vurderes, i forhold til din virksomheds produktionsbelastning.
• Undgå at teste mod tom eller lav pladsforbrug filsystem og/eller diskenheder. Hvis du ikke forhåndsallokerer plads på skriveworkloads, kan du se ventetid på grund af on-the-fly-allokering af plads under testen.
• Glem ikke at teste Read I/O, da dette normalt er den dominerende af de to i de fleste miljøer. Vær opmærksom på pakke-/rammetab i netværksinfrastrukturen under testen.
• Bekræft, at du tester mod flere enheder for at simulere et typisk miljø med mange værter eller klienter. På PowerStore er et godt tal f.eks. 16 diskenheder. Antal enheder svarer typisk til antallet af værter eller klienter, der bruges (fysiske eller virtuelle). Det er her samtidighed opnås.

 

Benchmarkingværktøjer og simulatorer
Husk, at de fleste værktøjer er simulatorer og sandsynligvis aldrig får 100% af en ægte produktionsbelastning simuleret. Disse benchmarkingværktøjer bruges til at få en idé om, hvordan ydeevne kunne, burde eller ville være i visse situationer. Dell ejer ikke disse værktøjer og er ikke ansvarlig for eventuelle problemer eller problemer, der kan være forbundet med dem.

Ved enhver præstationstestsituation skal du sikre dig, at der anvendes værktøjer med asynkrone funktioner og multithreading-funktioner. Eksempler på disse værktøjer er:

• Fleksibel I/O-tester (FIO)
• IOmeter
• Vdbench (kræver en Oracle-konto)
• NFSometer (Kun Fedora/NFS)
• Intels tjekliste til NAS-ydeevne

 

Undgå følgende typer tests:

• Kopiér og indsæt
• Træk og slip
• Sikkerhedskopiering af enkelt filsystem til disk
• DD-tests
• Rlarge
• Wlarge
• Mkfile
• Udpakning, udpakning og komprimering

Der er visse ting at være opmærksom på i de fleste bænkmarkeringsscenarier. Dette afsnit er ikke en erstatning for en forståelse af workloadens størrelse og karakteristika. Men hvis du mangler tidligere data og har brug for et groft skøn over dit programs funktionsmåde for at kunne benchmarke PowerStores funktioner (ikke specifik workloadydeevne), skal du overveje følgende faktorer:

 

 

IODepth (kødybde)
En lav IOdepth (eller ikke høj nok) kan begrænse din potentielle gennemstrømning afhængigt af situationen. Kontroller derfor altid, at IO-dybden er høj nok til at afspejle eller emulere samtidighedskravene for en arbejdsbelastning. En IOdepth, der er for lav, bruger muligvis ikke enheden korrekt til sit fulde potentiale. Vær også forsigtig med for høj IO-dybde, dette kan forårsage en betydelig kø på enheden, og afhængigt af enhedens servicetid kan der være større responstider som følge heraf. Dette kan afspejle, hvordan et overbelastet system kan se ud.

Til denne test er tallene betydeligt lavere, når der er en IOdepth på en sammenligning med en IOdepth på noget mere virkeligt, som 64. Husk, at dette er med et all-flash-array, og derfor ses dette koncept i sin ekstreme, men stadig mere almindelige form.

IOdepth=1" det er omkring ~30.000 Input and Output Operations Per Second (IOPS) gns. for testen.

 

"IOdepth=64" er omkring ~107.000 IOPS gns. for testen.

 

 

"IOdepth=256" er omkring ~142.000 IOPS gns. for testen.

 

 

Som nævnt udjævnes ydeevnen ved en bestemt IO-dybde i de fleste konfigurationer. Her er der en kødybde på 512, og der er kun en lille stigning i IOPS fra en IOdepth på 64."

IOdepth=512" det er omkring ~146.000 IOPS gns. til testen.

 

 


Asynkron vs. synkronisering
Der er to store forskellige motorer, der bruges. De mest populære og langt de mest effektive med hensyn til ydeevne er "asynkron I / O." Den mindre effektive og mindre effektive motortype er Synchronous I/O og bruges normalt med applikationer, der har strenge krav til dataintegritet og sikkerhed. Synkron I/O findes også i RPO-replikeringsteknologier (near-zero Recovery Point Objective). I test af ydeevne og benchmarking betyder asynkron fra et værtsperspektiv, at der ikke kræves en bekræftelse for en enkelt I/O for at anmode om den næste I/O. I synkrone arbejdsbelastninger kræves der en bekræftelse for en I/O, før den næste udstedes, og en bekræftelse (ACK) for hver efterfølgende I/O, der anmodes om. Derfor har synkron I/O normalt en kø på 1 eller mindre og udnytter aldrig ressourcen fuldt ud. Kobling af synkrone operationer med et lavt eller enkelt trådantal kan alvorligt begrænse ydeevnepotentialet, så kontroller altid, at du udfører asynkron test, og hvis du bruger synkron test, skal du sørge for at anvende flere tråde, medmindre applikationsmiljøet udtrykkeligt påpeger, at du ikke skal.

Async (Libaio - Linux native async) = 1 trådsynkronisering



(synkron I/O):  

 

 

Antal
threadsTråde er vigtige. Test bør altid udføres ved hjælp af flere tråde, især i synkrone tests/arbejdsbelastninger. Dette er for at forsøge at simulere flere iterationer af et job / en test baseret på funktionsmåden for en virksomhedsapplikationsproces. Flere tråde kombineret med samtidig aktivitet er hvor samlet gennemstrømning af et system opnås. De fleste asynkrone motorer anvender flere tråde, så du behøver ikke bekymre dig så meget om trådantal. Uden at have nok tråde under synkrone arbejdsbelastninger kan du alvorligt begrænse den samlede potentielle gennemstrømning af en belastningstest mod et system.

" Multithreaded" betyder flere tråde, der arbejder parallelt. For eksempel, hvis du har en enkelt enhed, der kan servicere 1000 IOPS i en synkron arbejdsbelastning, kommer dette ud til, at enheden har 1 ms responstid uden kø (så uden kø skal servicetid og responstid være synonyme). Det er klart, at enheder med 1 ms responstider kan udføre meget mere arbejde end 1000 IOPS, og dette opnås ved at stable flere tråde eller parallelle strømme af den samme arbejdsbelastning. Så hvis du øger trådene (eller "ting, der udfører dette specifikke job") til 10, har du nu 10 individuelle tråde, der udfører I / O til en enhed ved 1 ms. Hver enkelt workloadtråd får stadig 1 ms, hvilket betyder, at hver tråd stadig kun opnår 1000 IOPS, men nu får hele "processen" eller "jobbet", der køres af disse flere tråde, 10.000 IOPS.

Der er værktøjer og arbejdsbelastninger, der tilstrækkeligt kan ramme en enheds grænser med en enkelt tråd, og nogle har brug for mere. Kort sagt, når du simulerer en synkron belastning, vil du have så mange tråde / arbejdere / streams som muligt uden at påvirke den samlede responstid. Der er et punkt, hvor forøgelse af trådtællingen holder op med at have en positiv effekt (når enheden bliver 100% optaget). Generelt med asynkrone arbejdsbelastninger tages trådtælling som standard. Nedenfor kan du f.eks. stadig se en forskel mellem 1 tråd og 10 for en asynkron arbejdsbelastning, omend ikke signifikant. Historiens moral er, at med asynkrone arbejdsbelastninger skal du ikke bekymre dig så meget om tråde. 

En enkelt tråd her kan opnå 68.000 IOPS ved hjælp af "libaio" (async) motor. 

 

Hvis du øger trådene (numjobs) til 10, kan du stadig se en stigning op i IOPS.

 

Når det kommer til synkrone arbejdsbelastninger, selvom dette er et ekstremt tilfælde, kan du have to hovedfaktorer, der gør dette til en test med dårlig ydeevne, idet det er den synkrone karakter. 

send I/O-1, vent på ACK, send I/O-2, vent på ACK osv

 Og ikke at kunne stable flere tråde til samme formål. 

job1=send I/O-1 - job2=send I/O-1 - job3=send I/O-1..... job1=get ack, send I/O-2 - job2=get ack, send I/O-2 - job3= get ack, send I/O-2 så videre

Direkte flag

Med nogle værktøjer, især *nix-baserede værktøjer/operativsystemer, kan du muligvis se en mulighed for "Direkte I/O". Dette kan bruges med "async" motorer, og bør ikke forveksles med "synkron" I / O. I nogle værktøjer uden dette flag angivet kan du skrive til serverens cache og ikke direkte til disken. Hvad værten ønsker at gøre er at omgå sin egen cache og skrive direkte til disken. Dette er en vigtig faktor, når du tester opbevaring. Når du har "direkte" flag indstillet, skriver du teknisk til disk, selvom "disk" i dette tilfælde virkelig er lagercache. Dette er stadig acceptabelt til testformål, fordi selv med den korrekte arbejdsbelastning simulerer du stadig og efterligner nøjagtigt, hvordan denne arbejdsbelastning opfører sig i et virkeligt miljø, da produktionsbelastningen også vil ramme cachen, før du sender kvitteringen tilbage. (Føl dig ikke snydt, bare fordi du får præstationsnumre af cache involveret og ikke kun backend-spindlerne.)

 

Båndbredde (MB/s) vs. overførselshastighed (IOPS)

Der er to store perspektiver, som du kan teste for. Overførselshastighed i netværks- og ydeevneverdenen refererer normalt til dataoverførsel, men i SAN / blokmiljø er det almindeligt at bruge "gennemstrømning" til at repræsentere IOPS. Derfor skal du først forstå de arbejdsbelastningsegenskaber, du tester for.

Båndbredde (MB / s) - Båndbredde er målet for data, som du kan passe på én gang (eller inden for X-interval, normalt "pr. Sekund") på et rør eller system. Det betyder, at det måler, hvor meget data du har overført over en periode. Selvom båndbredde og IOPS ikke udelukker hinanden, kan du have højere eller lavere båndbreddetal med samme antal IOPS, alt afhænger af blokstørrelsen. Husk, at du ikke måler hastighed med båndbredde, hastigheden er noget helt andet, og selvom det påvirker båndbredden, er det normalt noget, du ikke kan kontrollere med tunge båndbreddearbejdsbelastninger. Hvis du tester for båndbredde, skal du derfor altid bruge større blokke (inden for rimelighedens grænser), så dine data pr. I/O er større, end hvis du ville teste for IOPS, da større blokke naturligvis vil tage længere tid at servicere. Hvis du for eksempel vil opnå 1 MB / s, men du bruger 8 KB blokstørrelser, skal du skubbe omkring 125 IOPS for at opnå dette. Men hvis du brugte 512 KB-blokke, ville det kun tage to (2) IOPS.
(Hvis du skulle beholde de 125 IOPS og stadig øge blokstørrelsen fra 8 KB til 512 KB, skubber du nu 64 MB / s!)

Men da der er flere data i en enkelt I/O, tager det normalt længere tid at "pakke" den I/O (finde, sammenkæde osv.). Derfor kan servicetiderne naturligvis være højere. Nogle gange har du en mindre kø, så dine svartider, selvom de naturligvis er højere, bør være ret tætte. Husk, at selvom svartiden spiller en rolle for, hvor meget båndbredde du kan opnå, opvejer stigningen i, hvor mange data der er pr. I/O, normalt enhver lille stigning i responstid (RT) pr. type I/O. Da svartiderne er højere, ønsker du ikke, at arbejdsbelastninger i store blokke skal være tilfældige. Så båndbreddearbejdsbelastninger har tendens til at være sekventielle. Når du introducerer en tilfældig karakter til en stor blokarbejdsbelastning, afbrydes din stabile dataoverførselshastighed konsekvent, og du begynder at mærke virkningerne af de lidt højere svartider pr. I/O.

Gennemløb (IOPS) – Overførselshastighed/IOPS er det mest almindelige perspektiv med workloads med små blokke, især når de bliver mere tilfældige. Alt over 32 KB-64 KB kan betragtes som en stor blok. Med gennemløb er de ovennævnte faktorer vigtigst (ting som trådantal, synkronisering eller asynkron, kødybde osv.). Her forsøger du ikke at måle, hvor meget samlet data du kan overføre i X-intervallet, men snarere hvor mange individuelle pakker (I / O-anmodninger), der bærer disse data, du forsøger at servicere (hvert x interval). Miljøer som OLTP (bankvirksomhed) bekymrer sig lidt om, hvor meget data de kan overføre, fordi deres datafodaftryk normalt er lille. Disse små datasæt kan dog være og er normalt optaget. Disse datasæt har en høj skævhed (der refereres til en lille mængde plads, men varierer aggressivt og konsekvent). De små pakker med data indeholder normalt kun anmodninger om at ændre/opdatere blokke med numeriske eller mindre strengværdier, og derfor er store I/O-pakker ikke nødvendige. Men på grund af transaktionernes art, og fordi der er så mange af dem, ønsker vi at kontrollere, at vi kan følge med i hver enkelt efterspørgsel. Jo mindre blokstørrelsen er, desto mere IOPS kan du normalt opnå i et givet scenarie, og selvom arbejdsbelastninger for små blokke for det meste er forbundet med tilfældig adgang, kan du opnå endnu mere overførselshastighed med sekventielle workloads i små blokke. Sekventielle workloads i små blokke er dog specifikke og ikke så almindelige, så test kun disse scenarier, hvis dit miljø kræver det.