Blog

IOPS zeggen niet alles

Precies 3 jaar geleden heb ik een blog geschreven over “Scaling out storage performance”. Inmiddels zijn we dus enige tijd verder en is er veel veranderd in storage land. Niet voor wat betreft de storage laag zelf: we gebruiken nog steeds EMC ScaleIO als software defined storage oplossing. Wel zijn we inmiddels afgestapt van PCIe flash kaarten als flash tier en gebruiken we nu standaard SSD disken in de nieuwste genereratie van onze cloud platformen.

Waar ik het in deze blog over wil hebben zijn IOPS. Er wordt vaak geschermd met termen als: “deze storage oplossing doet 100.000 IOPS”. Dat klinkt als veel, maar zegt niet alles. De hoeveelheid IOPs die een (synthetische) benchmark laat zien, is niets anders dan het aantal IO operaties er in een seconde passen. Hoeveel erin passen heeft voornamelijk met 2 factoren te maken:

  • Hoe lang duurt één IO operatie (latency);
  • Hoeveel doen we er tegelijk (threads en queue depth);

Wij zijn van mening dat het totaal aantal IOPS niet zo veel zegt. Latency is veel belangrijker. En dit is waar SSD vele malen beter scoort dan traditionele draaiden schijven. Het is simpele natuurkunde: een traditionele disk werkt met bewegende onderdelen. De zogenaamd “platters” draaien rond en er wordt met een bewegende kop razendsnel gezocht naar de juiste plek om data op te halen. Althans, razendsnel; het gaat wel snel, maar het gaat vele malen langzamer dan bij een SSD of flash oplossing, zonder bewegende delen. Een traditionele disk die 10.000 rondjes per minuut draait heeft vaak een gemiddelde latency van laten we zeggen 5 ms. Dat betekent dat zo’n disk gemiddeld 200 IOPS kan leveren (1000ms. gedeeld door 5 is immers 200). Een SSD schijf (bijvoorbeeld een 1,92TB enterprise SSD van Samsung) heeft een latency van 35 micro secondes. Dat zijn 0,035 milisecondes. Oftewel een theoretisch maximum qua IOPS van 28571. Dat zijn andere getallen.

De afgelopen tijd zijn we wel eens geconfronteerd met klanten die een performance benchmark willen doen alvorens ze klant willen worden. We krijgen dan een performance resultaat opgestuurd van een concurrent waaruit blijkt dat een VM bijvoorbeeld 16000 IOPS kan doen. Ik wil dan altijd weten wat voor test er is gedaan. Want een test waarbij 4 threads, met een queue depth van 32 wordt uitgevoerd, betekent dat er 128 IO operaties parallel worden uitgevoerd. 16000 delen door 128 leert een getal van 125 operaties per seconde bij een single thread, zonder queue depth en leert mij vervolgens dat we waarschijnlijk naar een storage oplossing kijken met weliswaar veel disken, maar wel met 10k SAS schijven en geen SSD’s.

Waarom is dit belangrijk? Er zijn nog talloze applicaties die niet geoptimaliseerd zijn voor multi threaded IO en afhankelijk zijn van hoe snel een enkele IO afgehandeld kan worden. Mijn wedervraag is dan ook altijd om een benchmark te draaien met een queue depth van 1 en 1 thread.

Dit kun je onder Linux makkelijk doen met een tool als fio:

Deze cloud server doet 2658 IOPS met 1 thread en een queue depth van 1. Als we 1000 delen door 2658 komt daar een gemiddelde latency uit van 0.376 milisecondes. Dat is veel meer dan de 35 micro secondes van de SSD zelf en dat komt door het SAN. Omdat er een netwerk en storage logica (in de vorm van ScaleIO) zit tussen de (in dit geval) VMware nodes en de disken, is er latency.

De latency van de SSD is bijna te verwaarlozen, dus de latency wordt hier voornamelijk veroorzaakt door het netwerk en de storage oplossing. Dit is de reden dat we bijvoorbeeld bij high performance database omgevingen nog voor een dedicated server met local SSD storage kiezen, omdat de latency dan lager is. Daar zal ik een andere blog aan wijden.

Als we nu toch de concurrency en queue depth opschroeven, dan zie je dat het cluster netjes doorschaalt:

128.000 read IOPS

Of 73.000 write IOPS.

Het cluster kan meer IOPS leveren, maar om te zorgen dat 1 VM niet alle IOPS verbruikt, worden er op cluster niveau verschillende limieten gehanteerd. De praktijk leert echter dat we nooit klanten tegenkomen die meer dan bovenstaande hoeveelheid IOPS nodig hebben.

De bottom line van deze blog: staar je niet blind op het totaal aantal IOPS dat een server of storage omgeving kan leveren, maar verdiep je ook in de single thread performance. We hebben nu al een aantal keer meegemaakt dat een klant hier veel meer aan had dan aan het totale aantal.


About Ruben van der Zwan

Ruben van der Zwan is de CTO bij Amsio en verantwoordelijk voor de technologiekeuzes van de organisatie en de productontwikkeling. De vertaling van complexe vraagstukken naar totaaloplossingen voor klanten en partners is hier onderdeel van. Ruben van der Zwan heeft meer dan 10 jaar ervaring in de hosting industrie en heeft een technische achtergrond.