PowerStore: Effectieve technieken voor het beoordelen van de prestaties van storage-arrays

Opmerking: Benchmarking is alleen geldig als alles is ingesteld volgens de best practices van PowerStore en er geen connectiviteits- of configuratieproblemen zijn. Anders levert de test waarschijnlijk irrelevante gegevens op.

• Test met behulp van variabelen die lijken op wat de echte workload/omgeving zal zijn. Vergeet niet dat de meeste tools simulatoren zijn en nooit 100% van een echte gesimuleerde productieworkload bereiken.
• Als de workload sterk is, overweeg dan om meerdere iteraties van lees-/schrijftests uit te voeren met verschillende blokgroottes en toegangspatronen.
• Gebruik multithreaded en asynchrone bewerkingen of tests om parallelle of gelijktijdige prestatiemogelijkheden te garanderen en ervoor te zorgen dat het algehele totale doorvoerpotentieel wordt benut. 
• Overweeg en beoordeel industriestandaard benchmarks voor de apparatuur die wordt beoordeeld met betrekking tot de productieworkload van uw bedrijf.
• Test niet op een leeg of laag ruimteverbruikend bestandssysteem en/of volume. Als u vooraf geen ruimte toewijst op schrijfworkloads, kunt u latentie zien als gevolg van on-the-fly-toewijzing van ruimte tijdens de test.
• Vergeet niet om de Read I/O te testen, aangezien dit in de meeste omgevingen meestal de dominante van de twee is. Houd tijdens het testen rekening met pakket- en frameverlies in de netwerkinfrastructuur.
• Controleer of u op meerdere apparaten test om een typische omgeving met veel hosts of clients te simuleren. Op PowerStore is een goed aantal bijvoorbeeld 16 volumes. Het aantal volumes komt meestal overeen met het aantal gebruikte hosts of clients (fysiek of virtueel); Dit is waar gelijktijdigheid wordt bereikt.

 

Benchmarkingtools en simulatoren
Houd er rekening mee dat de meeste tools simulatoren zijn en waarschijnlijk nooit 100% van een echte productieworkload gesimuleerd krijgen. Deze benchmarkingtools worden gebruikt om een idee te krijgen van hoe de prestaties in bepaalde situaties zouden kunnen, moeten of zouden zijn. Dell is niet de eigenaar van deze tools en is niet verantwoordelijk voor eventuele problemen of problemen die ermee kunnen worden geconfronteerd.

Zorg er bij elke prestatietestsituatie voor dat tools met asynchrone en multithreading-mogelijkheden worden gebruikt. Voorbeelden van deze tools zijn:

• Flexibele I/O-tester (FIO)
• IOmeter
• Vdbench (vereist een Oracle-account)
• NFSometer (alleen Fedora/NFS)
• Prestatiechecklist voor NAS van Intel

 

Vermijd de volgende soorten tests:

• Kopiëren en plakken
• Slepen en neerzetten
• Back-up van één bestandssysteem naar schijf
• DD Tests
• Rlarge
• Wlarge
• Mkfile
• Uitpakken, uitpakken en comprimeren

Er zijn bepaalde dingen waar u op moet letten in de meeste bench-marking scenario's. Dit gedeelte is geen vervanging voor het begrijpen van de omvang en kenmerken van de workload. Als u echter geen data uit het verleden hebt en een ruwe schatting van het gedrag van uw applicatie nodig hebt om de mogelijkheden van PowerStore te benchmarken (niet de specifieke workloadprestaties), overweeg dan de volgende factoren:

 

 

IODepth (wachtrijdiepte)
Een lage IO-diepte (of niet hoog genoeg) kan, afhankelijk van de situatie, uw potentiële doorvoer beperken. Controleer daarom altijd of IOdepth hoog genoeg is om de gelijktijdigheidsvereisten van een workload weer te geven of na te bootsen. Een IO-diepte die te laag is, maakt mogelijk niet optimaal gebruik van het volledige potentieel van het apparaat. Wees ook op uw hoede voor een te hoge IO-diepte. Dit kan aanzienlijke wachtrijen op het apparaat veroorzaken en afhankelijk van de onderhoudstijd van het apparaat kunnen er langere responstijden optreden. Dit kan een afspiegeling zijn van hoe een overbelast systeem eruit zou kunnen zien.

Voor deze test zijn de getallen beduidend lager wanneer er een IOdiepte van één vergelijking is met een IOdiepte van iets meer reëel, zoals 64. Houd er rekening mee dat dit met een all-flash-array is en dat dit concept dus in zijn extreme maar steeds vaker voorkomende vorm wordt gezien."

IOdepth=1" is het ongeveer ~30.000 invoer- en uitvoerbewerkingen per seconde (IOPS) gemiddeld voor de test.

 

"IOdepth=64" is ongeveer ~107.000 IOPS gemiddeld voor de test.

 

 

"IOdepth=256" is ongeveer ~142.000 IOPS gemiddeld voor de test.

 

 

Zoals gezegd vlakken de prestaties in de meeste configuraties af op een bepaalde IO-diepte. Hier is er een wachtrijdiepte van 512 en er is slechts een kleine toename van IOP's vanaf een IOdiepte van 64."

IOdepth=512" is het ongeveer ~146.000 IOPS gemiddeld voor de test.

 

 


Asynchroon versus synchronisatie
Er zijn twee belangrijke, verschillende motoren die worden gebruikt. De meest populaire en verreweg de meest efficiënte in termen van prestaties zijn asynchrone I/O. Het minder efficiënte en minder presterende type engine is Synchrone I/O en wordt normaal gesproken gebruikt voor applicaties met strikte vereisten voor data-integriteit en -zekerheid. Synchrone I/O is ook te vinden in RPO-replicatietechnologieën (Recovery Point Objective) die bijna nul zijn. Bij prestatietests en benchmarking betekent asynchroon vanuit het perspectief van de host dat er geen bevestiging nodig is voor een enkele I/O om de volgende I/O aan te vragen. In synchrone workloads is een bevestiging nodig voor een I/O voordat de volgende wordt uitgegeven en een bevestiging (ACK) voor elke volgende I/O die wordt aangevraagd. Daarom heeft synchrone I/O meestal een wachtrij van 1 of minder en wordt de resource nooit volledig optimaal benut. Het koppelen van synchrone bewerkingen met een laag aantal of enkele threads kan het prestatiepotentieel ernstig beperken, dus controleer altijd of u asynchrone tests uitvoert en als u synchrone tests gebruikt, zorg er dan voor dat u meerdere threads gebruikt, tenzij de applicatieomgeving expliciet aangeeft dat dit niet het geval is.

Asynchroon (Libaio - Linux native async) = 1 thread



Sync (synchrone I/O):  

 

 

Aantal threads
Draden zijn belangrijk. Testen moet altijd worden uitgevoerd met behulp van meerdere threads, vooral bij synchrone tests/workloads. Dit is om te proberen meerdere iteraties van een taak/test te simuleren op basis van het gedrag van het proces van een bedrijfsapplicatie. Meerdere threads in combinatie met gelijktijdige activiteit zijn de plaats waar de totale doorvoer van een systeem wordt bereikt. De meeste asynchrone engines maken gebruik van meerdere threads, zodat u zich minder zorgen hoeft te maken over het aantal threads. Zonder voldoende threads tijdens synchrone workloads kunt u de totale potentiële doorvoer van een belastingstest tegen een systeem ernstig beperken."

"Multithreaded" betekent meerdere threads die parallel werken. Als u bijvoorbeeld één apparaat hebt dat 1000 IOPS kan onderhouden in een synchrone workload, komt dit erop neer dat het apparaat een responstijd van 1 ms heeft zonder wachtrij (dus zonder wachtrij moeten servicetijd en responstijd synoniem zijn). Het is duidelijk dat apparaten met een responstijd van 1 ms veel meer werk kunnen verzetten dan 1000 IOPS, en dit wordt bereikt door meerdere threads of parallelle streams van dezelfde workload te stapelen. Dus als je de threads (of "dingen die deze specifieke taak doen") verhoogt tot 10, heb je nu 10 individuele threads die I/O doen naar een apparaat met 1 ms. Elke afzonderlijke workloadthread krijgt nog steeds 1 ms, wat betekent dat elke thread nog steeds slechts 1000 IOPS bereikt, maar nu krijgt het hele "proces" of de "job" die door deze meerdere threads wordt uitgevoerd 10.000 IOPS.

Er zijn tools en workloads die de limieten van een apparaat adequaat kunnen bereiken met een enkele thread, en sommige hebben meer nodig. Samengevat, wanneer u een synchrone belasting simuleert, wilt u zoveel mogelijk threads/workers/streams hebben zonder de totale responstijd te beïnvloeden. Er is een punt waarop het verhogen van het aantal threads geen positief effect meer heeft (wanneer het apparaat 100% bezet wordt). Over het algemeen wordt bij asynchrone workloads standaard voor het aantal threads gezorgd. Hieronder zie je bijvoorbeeld nog steeds een verschil tussen 1 thread en 10 voor een asynchrone workload, zij het niet significant. Moraal van het verhaal is dat u zich met asynchrone workloads minder zorgen hoeft te maken over threads. 

Een enkele thread hier kan 68.000 IOPS bereiken met behulp van de "libaio" (async) engine. 

 

Als u het aantal threads (numjobs) verhoogt naar 10, ziet u nog steeds een toename in de IOP's.

 

Als het gaat om synchrone workloads, hoewel dit een extreem geval is, kunnen er twee belangrijke factoren zijn die dit een slecht presterende test maken, namelijk de synchrone aard. 

stuur I/O-1, wacht op ACK, verzend I/O-2, wacht op ACK enzovoort

 En het niet kunnen stapelen van meerdere threads voor hetzelfde doel. 

job1=stuur I/O-1 - job2=stuur I/O-1 - job3=stuur I/O-1..... job1=krijg ack, stuur I/O-2 - job2=krijg ack, stuur I/O-2 - job3= krijg ack, stuur I/O-2 enzovoort

Directe vlag

Bij sommige tools, met name *op nix gebaseerde tools/besturingssystemen, ziet u mogelijk een optie voor "Direct I/O". Dit kan worden gebruikt met "asynchrone" engines en moet niet worden verward met "synchrone" I/O. In sommige hulpprogramma's waarvoor deze markering niet is opgegeven, schrijft u mogelijk naar de servercache en niet rechtstreeks naar de schijf. Wat de host wil doen, is zijn eigen cache omzeilen en rechtstreeks naar de schijf schrijven. Dit is een essentiële factor bij het testen van storage. Als je de vlag "direct" hebt ingesteld, schrijf je technisch gezien naar schijf, hoewel "schijf" in dit geval echt opslagcache is. Dit is nog steeds acceptabel voor testdoeleinden, omdat u zelfs met de juiste workload nog steeds simuleert en nauwkeurig nabootst hoe deze workload zich gedraagt in een echte omgeving, aangezien de productiebelasting ook in de cache wordt opgeslagen voordat de bevestiging wordt teruggestuurd. (Voel je niet bedrogen alleen omdat je prestatienummers van cache krijgt en niet alleen de backend-spindels.)

 

Bandbreedte (MB/s) versus doorvoer (IOPS)

Er zijn twee belangrijke perspectieven waarop u kunt testen. Doorvoer in de netwerk- en prestatiewereld verwijst meestal naar dataoverdracht, maar in een SAN/blokomgeving is het gebruikelijk om "throughput" te gebruiken om IOPS weer te geven. Daarom moet u eerst de workloadkenmerken begrijpen waarop u test.

Bandbreedte (MB/s) - Bandbreedte is de hoeveelheid data die u in één keer (of binnen een interval van X, meestal 'per seconde') op een pijp of systeem kunt plaatsen. Dit betekent dat het meet hoeveel gegevens u over een bepaalde periode hebt overgedragen. Hoewel bandbreedte en IOP's elkaar niet uitsluiten, kunt u hogere of lagere bandbreedtegetallen hebben met hetzelfde aantal IOP's, dit hangt allemaal af van de blokgrootte. Onthoud dat u snelheid niet meet met bandbreedte, de snelheid is iets heel anders, en hoewel het van invloed is op de bandbreedte, is het meestal iets dat u niet kunt controleren met workloads met zware bandbreedte. Gebruik daarom bij het testen op bandbreedte altijd grotere blokken (binnen redelijke grenzen), zodat uw data per I/O groter is dan wanneer u op IOP's zou testen, omdat het natuurlijk langer duurt om grotere blokken te onderhouden. Als u bijvoorbeeld 1 MB/s wilt bereiken, maar u gebruikt blokgroottes van 8 KB, dan moet u hiervoor ongeveer 125 IOPS pushen. Als u echter blokken van 512 KB gebruikt, zijn er slechts twee (2) IOP's nodig.
(Als je de 125 IOPS zou behouden en toch de blokgrootte zou vergroten van 8 KB naar 512 KB, dan ben je nu 64 MB/s aan het pushen!)

Omdat er echter meer data binnen één I/O zitten, duurt het meestal langer om die I/O te "verpakken" (vinden, aan elkaar rijgen enzovoort). Daarom kunnen de servicetijden natuurlijk langer zijn. Soms heb je een kleinere wachtrij, dus je reactietijden, hoewel van nature hoger, zouden vrij dicht bij elkaar moeten liggen. Houd er rekening mee dat hoewel responstijd een rol speelt bij de hoeveelheid bandbreedte die u kunt bereiken, de toename van de hoeveelheid data per I/O meestal opweegt tegen een lichte toename van de responstijd (RT) per dat type I/O. Aangezien de reactietijden langer zijn, wilt u niet dat workloads met grote blokken willekeurig moeten zijn. Bandbreedteworkloads zijn dus meestal sequentieel. Wanneer u een willekeurige aard introduceert in een grote blokworkload, wordt uw constante dataoverdrachtssnelheid consequent onderbroken en begint u de effecten van de iets hogere responstijden per I/O te voelen.

Doorvoer (IOPS): doorvoer/IOPS is het meest voorkomende perspectief bij workloads met kleine blokken, vooral naarmate ze willekeuriger worden. Alles boven de 32 KB-64 KB kan als een groot blok worden beschouwd. Bij doorvoer zijn de bovengenoemde factoren het belangrijkst (zaken als aantal threads, synchroon of asynchroon, wachtrijdiepte enzovoort). Hier probeert u niet te meten hoeveel totale gegevens u kunt overdragen tijdens een X-interval, maar hoeveel afzonderlijke pakketten (I/O-verzoeken) met die gegevens u probeert te onderhouden (elk x-interval). Omgevingen zoals OLTP (bankieren) geven er weinig om hoeveel data ze kunnen overdragen, omdat hun datavoetafdruk meestal klein is. Deze kleine datasets kunnen echter bezet zijn, en zijn normaal gesproken druk. Deze datasets hebben een hoge scheeftrekking (er wordt verwezen naar een kleine hoeveelheid ruimte, maar deze variëren agressief en consistent). De kleine datapakketten bevatten meestal alleen verzoeken om blokken met numerieke of kleinere tekenreekswaarden te wijzigen/bij te werken, en daarom zijn grote I/O-pakketten niet nodig. Vanwege de aard van de transacties en omdat het er zoveel zijn, willen we echter verifiëren dat we aan elke individuele vraag kunnen voldoen. Hoe kleiner de blokgrootte, hoe meer IOPS u kunt bereiken in een bepaald scenario, en hoewel workloads met kleine blokken meestal worden geassocieerd met willekeurige toegang, kunt u nog meer doorvoer bereiken met sequentiële workloads met kleine blokken. De sequentiële workloads van kleine blokken zijn echter specifiek en komen niet zo vaak voor, dus test deze scenario's alleen als uw omgeving dit vereist.