PowerStore: Effektiva tekniker för att bedöma prestanda för lagringsdisksystem

Obs! Benchmarking är endast giltigt om allt är konfigurerat enligt bästa praxis för PowerStore och det inte finns några anslutnings- eller konfigurationsproblem. Annars ger testet sannolikt irrelevanta data.

• Testa med variabler som liknar vad den verkliga arbetsbelastningen/miljön kommer att vara. Kom ihåg att de flesta verktyg är simulatorer och aldrig uppnår 100 % av en simulerad produktionsarbetsbelastning.
• Om arbetsbelastningen varierar mycket bör du överväga att göra flera iterationer av läs-/skrivtester med olika blockstorlekar och åtkomstmönster.
• Använd flertrådade och asynkrona åtgärder eller tester för att säkerställa parallella eller samtidiga prestandafunktioner och se till att den övergripande aggregerade dataflödespotentialen utövas. 
• Överväg och granska branschstandardriktmärken för den utrustning som bedöms eftersom de är relaterade till företagets produktionsarbetsbelastning.
• Undvik att testa mot tomma filsystem eller volymer med låg utrymmesanvändning. Om du inte förallokerar utrymme på skrivarbetsbelastningar kan du se svarstider på grund av allokering av utrymme i farten under testet.
• Glöm inte att testa läs-I/O då detta brukar vara det dominerande av de två i de flesta miljöer. Tänk på paket-/bildruteförlust i nätverksinfrastrukturen under testningen.
• Kontrollera att du testar mot flera enheter för att simulera en typisk miljö med många värdar eller klienter. I PowerStore är till exempel ett bra tal 16 volymer. Antalet volymer matchar vanligtvis antalet värdar eller klienter som används (fysiska eller virtuella). Det är här samtidighet uppnås.

 

Benchmarkingverktyg och simulatorer
Tänk på att de flesta verktyg är simulatorer och sannolikt aldrig får 100 % av en verklig produktionsarbetsbelastning simulerad. Dessa benchmarkingverktyg används för att få en uppfattning om hur prestanda kan, bör eller skulle vara i vissa situationer. Dell äger inte verktygen och ansvarar inte för eventuella problem som kan uppstå i samband med dem.

I alla prestandatestsituationer bör du se till att verktyg med asynkron- och flertrådsfunktioner används. Exempel på dessa verktyg är:

• Flexibel I/O-testare (FIO)
• IO-mätare
• Vdbench (kräver ett Oracle-konto)
• NFSometer (Endast Fedora/NFS)
• Intels checklista för NAS-prestanda

 

Undvik följande typer av tester:

• Kopiera och klistra in
• Dra och släpp
• Säkerhetskopiering av ett filsystem till disk
• DD-tester
• Rlarge
• Wlarge
• Mkfile
• Packa upp, extrahera och komprimera

Det finns vissa saker att vara medveten om i de flesta scenarier för bänkmarkering. Det här avsnittet är inte en ersättning för att förstå arbetsbelastningens storlek och egenskaper. Men om du saknar tidigare data och behöver en grov uppskattning av programmets beteende för att bedöma PowerStore-funktionerna (inte specifik arbetsbelastningsprestanda) bör du överväga följande faktorer:

 

 

IODepth (ködjup)
Ett lågt IO-djup (eller inte tillräckligt högt) kan begränsa ditt potentiella dataflöde beroende på situationen. Kontrollera därför alltid att IOdepth är tillräckligt högt för att återspegla eller emulera samtidighetskraven för en arbetsbelastning. Ett IOdepth som är för lågt kanske inte använder enheten korrekt till sin fulla potential. Var också försiktig med för högt IO-djup, detta kan orsaka betydande köer på enheten och beroende på enhetens servicetid kan det bli längre svarstider som följd. Detta kan återspegla hur ett överbelastat system kan se ut.

För det här testet är siffrorna betydligt lägre när det finns ett IOdjup på ett jämfört med ett IOdjup på något mer verkligt, till exempel 64. Tänk på att detta är med en all-flash-array och därför ses detta koncept i sin extrema men allt vanligare, form."

IOdepth=1" är det cirka ~30 000 in- och utdataoperationer per sekund (IOPS) i genomsnitt för testet.

 

"IOdepth=64" är cirka ~107 000 IOPS i genomsnitt för testet.

 

 

"IOdepth=256" är cirka ~142 000 IOPS i genomsnitt för testet.

 

 

Som nämnts planar prestandan ut vid ett visst IO-djup i de flesta konfigurationer. Här finns ett ködjup på 512 och det finns bara en liten ökning av IOPS från ett IOdepth på 64.

" IOdepth=512" är det cirka ~146 000 IOPS i genomsnitt för testet.

 

 


Asynkron jämfört med synkron
Det finns två stora distinkta motorer som används. De mest populära och överlägset mest effektiva när det gäller prestanda är "asynkron I/O". Den mindre effektiva och mindre högpresterande typen av motor är synkron I/O och används normalt med program som har strikta krav på dataintegritet och säkerhet. Synkron I/O finns också i replikeringstekniker som är nära noll Recovery Point Objective (RPO). I prestandatestning och benchmarking, ur ett värdperspektiv, innebär asynkron att en bekräftelse inte behövs för en enda I/O för att begära nästa I/O. I synkrona arbetsbelastningar krävs en bekräftelse för en I/O innan nästa utfärdas och en bekräftelse (ACK) för varje efterföljande I/O som begärs. Därför har synkron I/O vanligtvis en kö på 1 eller mindre och använder aldrig resursen fullt ut. Att koppla synkrona åtgärder med ett lågt eller enkelt trådantal kan avsevärt begränsa prestandapotentialen, så kontrollera alltid att du gör asynkron testning, och om du använder synkron testning måste du använda flera trådar om inte programmiljön uttryckligen påpekar att du inte ska göra det.

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



(synkron I/O):  

 

 

Antal trådar
Trådar är viktiga. Testning bör alltid göras med flera trådar, särskilt i synkrona tester/arbetsbelastningar. Detta är för att försöka simulera flera iterationer av ett jobb/test baserat på beteendet för ett företagsprograms process. Det är i flera trådar tillsammans med samtidig aktivitet som aggregerat dataflöde för ett system uppnås. De flesta asynkrona motorer använder flera trådar, så du behöver inte bekymra dig om antalet trådar lika mycket. Utan att ha tillräckligt med trådar under synkrona arbetsbelastningar kan du avsevärt begränsa det totala potentiella dataflödet för ett belastningstest mot ett system."

"Flertrådad" betyder att flera trådar arbetar parallellt. Om du till exempel har en enda enhet som kan hantera 1000 IOPS i en synkron arbetsbelastning kommer detta ut till enheten som har 1 ms svarstid utan kö (så utan kö bör tjänsttid och svarstid vara synonyma). Enheter med svarstider på 1 ms kan naturligtvis utföra mycket mer arbete än 1 000 IOPS, och detta uppnås genom att stapla flera trådar eller parallella strömmar av samma arbetsbelastning. Så om du ökar trådarna (eller "saker som gör det här specifika jobbet") till 10 har du nu 10 enskilda trådar som gör I/O till en enhet på 1 ms. Varje enskild arbetsbelastningstråd får fortfarande 1 ms, vilket innebär att varje tråd fortfarande bara uppnår 1000 IOPS, men nu får hela "processen" eller "jobbet" som körs av dessa flera trådar 10 000 IOPS.

Det finns verktyg och arbetsbelastningar som kan nå en enhets gränser med en enda tråd, och vissa behöver mer. Sammanfattningsvis vill du ha så många trådar/arbetare/strömmar som möjligt när du simulerar en synkron belastning utan att påverka den totala svarstiden. Det finns en punkt där en ökning av trådantalet slutar ha en positiv effekt (när enheten blir 100 % upptagen). Med asynkrona arbetsbelastningar tas trådantalet vanligtvis om hand som standard. Nedan kan du till exempel fortfarande se en skillnad mellan 1 tråd och 10 för en asynkron arbetsbelastning, även om den inte är betydande. Sensmoralen i historien är att med asynkrona arbetsbelastningar ska du inte behöva oroa dig för trådar lika mycket. 

En enda tråd här kan uppnå 68 000 IOPS med hjälp av "libaio"-motorn (asynkron). 

 

Om du ökar trådarna (numjobs) till 10 kan du fortfarande se en ökning av IOPS.

 

När det gäller synkrona arbetsbelastningar, även om detta är ett extremfall, kan du ha två huvudfaktorer som gör detta till ett dåligt presterande test, nämligen den synkrona naturen. 

skicka I/O-1, vänta på ACK, skicka I/O-2, vänta på ACK så vidare

 Och att inte kunna stapla flera trådar för samma ändamål. 

job1=skicka I/O-1 - job2=skicka I/O-1 - job3=skicka I/O-1..... job1=get ack, send I/O-2 - job2=get ack, send I/O-2 - job3= get ack, send I/O-2 so on

Direkt flagga

För vissa verktyg, särskilt *nix-baserade verktyg/OS, kan du se ett alternativ för "Direct I/O". Detta kan användas med "asynkrona" motorer och ska inte förväxlas med "synkron" I/O. I vissa verktyg utan den här flaggan angiven kan du skriva till serverns cache och inte direkt till disken. Vad värden vill göra är att kringgå sin egen cache och skriva direkt till disken. Detta är en viktig faktor när du testar lagring. När du har flaggan "direct" inställd skriver du tekniskt sett till disk, även om "disk" i det här fallet egentligen är lagringscache. Detta är fortfarande acceptabelt i testsyfte eftersom du även med rätt arbetsbelastning fortfarande simulerar och korrekt efterliknar hur den här arbetsbelastningen beter sig i en verklig miljö, eftersom produktionsbelastningen också kommer att träffa cacheminnet innan du skickar tillbaka bekräftelsen. (Känn dig inte lurad bara för att du får prestandasiffror för cache inblandade och inte bara backend-spindlarna.)

 

Bandbredd (MB/s) jämfört med genomströmning (IOPS)

Det finns två stora perspektiv som du kan testa för. Dataflöde i nätverks- och prestandavärlden avser vanligtvis dataöverföring, men i SAN-/blockmiljöer är det vanligt att använda "genomströmning" för att representera IOPS. Därför måste du först förstå de arbetsbelastningsegenskaper som du testar för.

Bandbredd (MB/s) – Bandbredd är måttet på data som du kan få plats med samtidigt (eller inom X-intervallet, vanligtvis "per sekund") på ett rör eller system. Det innebär att den mäter hur mycket data du har överfört under en tidsperiod. Även om bandbredd och IOPS inte utesluter varandra kan du ha högre eller lägre bandbreddsnummer med samma mängd IOPS, allt beror på blockstorleken. Kom ihåg att du inte mäter hastighet med bandbredd, hastigheten är något helt annat och även om det påverkar bandbredden är det vanligtvis något du inte kan kontrollera med arbetsbelastningar med tung bandbredd. Om du testar för bandbredd bör du därför alltid använda större block (inom rimliga gränser) så att dina data per I/O är större än om du skulle testa för IOPS, eftersom större block naturligtvis tar längre tid att hantera. Om du till exempel vill uppnå 1 MB/s men använder 8 KB-blockstorlekar måste du trycka på cirka 125 IOPS för att uppnå detta. Men om du använde 512 KB-block skulle det bara ta två (2) IOPS.
(Om du skulle behålla 125 IOPS och ändå öka blockstorleken från 8 kB till 512 kB trycker du nu på 64 MB/s!)

Men eftersom det finns mer data i en enda I/O tar det vanligtvis längre tid att "paketera" den I/O (hitta, stränga ihop och så vidare). Därför kan servicetiderna naturligtvis vara högre. Ibland har du en mindre kö, så dina svarstider bör vara ganska nära, även om de naturligtvis är högre. Tänk på att även om svarstiden spelar en roll för hur mycket bandbredd du kan uppnå, uppväger ökningen av mängden data som finns per I/O vanligtvis en liten ökning av svarstiden (RT) per den typen av I/O. Eftersom svarstiderna är högre vill du inte att arbetsbelastningar med stora block ska behöva vara slumpmässiga. Arbetsbelastningar för bandbredd tenderar därför att vara sekventiella. När du introducerar en slumpmässig natur för en stor blockarbetsbelastning avbryts din stadiga dataöverföringshastighet konsekvent och du börjar känna av effekterna av de något högre svarstiderna per I/O.

Dataflöde (IOPS) – Dataflöde/IOPS är det vanligaste perspektivet med arbetsbelastningar med små block, särskilt när de blir mer slumpmässiga. Allt över 32 KB-64 KB kan betraktas som ett stort block. Med dataflöde är de ovan nämnda faktorerna viktigast (saker som antal trådar, synkronisering eller asynkron, ködjup och så vidare). Här försöker du inte mäta hur mycket övergripande data du kan överföra under X-intervallet, utan snarare hur många enskilda paket (I/O-begäranden) som innehåller de data du försöker hantera (varje x-intervall). Miljöer som OLTP (bankverksamhet) bryr sig lite om hur mycket data de kan överföra eftersom deras datafotavtryck vanligtvis är litet. Dessa små datauppsättningar kan dock vara och är normalt upptagna. Dessa datauppsättningar har en hög skevhet (en liten mängd utrymme refereras till men varierar aggressivt och konsekvent). De små datapaketen innehåller vanligtvis bara förfrågningar om att ändra/uppdatera block med numeriska eller mindre strängvärden, och därför krävs inga stora I/O-paket. Men på grund av transaktionernas karaktär och eftersom det finns så många av dem vill vi verifiera att vi kan hålla jämna steg med varje enskild efterfrågan. Vanligtvis är det så att ju mindre blockstorlek desto mer IOPS kan du uppnå i ett visst scenario, och även om arbetsbelastningar för små block främst är associerade med slumpmässig åtkomst kan du uppnå ännu mer dataflöde med sekventiella arbetsbelastningar för små block. Sekventiella arbetsbelastningar för små block är dock specifika och inte lika vanliga, så testa bara dessa scenarier om din miljö kräver det.