IBM doorbreekt één miljoen iops-grens met Quicksilver-flashopslag

Met een combinatie van solid state disks en virtualisatietechnieken, verenigd in het project Quicksilver, zijn onderzoekers van IBM erin geslaagd ruim één miljoen lees- en schrijfoperaties per seconde te realiseren.

Het Quicksilver-project van IBM zou niet alleen de performance met 250 procent verbeteren, maar ook de responstijden terugbrengen tot minder dan een milliseconde. Bovendien kon de apparatuur met slechts iets meer dan de helft van de energie en koeling toe dan de snelste concurrentie. Ten slotte gebruikte Quicksilver slechts eenvijfde van de rackspace die alternatieven nodig hebben.

IBM vergeleek zijn opstelling met die van concurrent Texas Memory Systems en zijn eigen DS4700: beide systemen behalen 400.000iops. De Ramsan-400-server van TMS, volgens het bedrijf 's werelds snelste opslagserver, gebruikt echter het snellere dram in plaats van het flashgeheugen dat IBM toepaste. Volgens IBM zou het Quicksilver-project van belang zijn in gevallen waarbij data snel moet worden verwerkt, zoals bij online reserveringen en bij financiële transacties.

Het project combineert IBM's virtualisatiesoftware San Volume Controller met ssd's om zo de opslag van data te versnellen. De software stuurde hiertoe een ssd-rack van 4,1TB aan met responstijden van minder dan 1ms en een datadoorvoer van meer dan één miljoen iops. De ssd-flashkaarten ter waarde van ongeveer 120.000 dollar die IBM inzette, waren afkomstig van Fusion io en werden op de pci-bus van System X-servers aangesloten. Het Quicksilver-project zou volgens marketingdirecteur IBM Storage Charlie Andrews over negen tot twaalf maanden tot commerciële producten moeten leiden. Al eerder, binnen drie tot zes maanden, zou IBM van plan zijn ssd's in zijn producten toe te passen.

Reacties (14)

[Eric Oud Ammerveld]

Een I/O operatie is een lees of een schrijfactie op de harde schijf.
Iets waarin de standaard schijven (vergeleken bij SSD's) slecht zijn
wat de reden is dat oplossingen als Controller Caching, Native Command Queueing
e.d. uitgevonden zijn.

Voor Database systemen die gebruikt worden bij OLTP systemen is het aantal I/O operaties per seconde van zeer groot belang omdat er vaak veel kleine acties plaatsvinden op één en dezelfde gegevensset (bijvoorbeeld een Tabel met ordergegevens).
Hierbij komt kijken dat het tegelijk op exact dezelfde data (bijv. het door twee medewerkers wijzigen van de klantgegevens van één de dezelfde klant) werken concurrency problemen geeft in een omgeving waarin transacties serieel afgehandeld worden; iets dat sterk verminderd wanneer het (database)systeem versneld kan worden.

Een praktijkvoorbeeld; ter indicatie een RAID-0 oplossing met 2 Gb Cache en 4 schijven die totaal 400 Mb/s doorvoer kunnen halen kan met 4.000 I/O ops van 2 Kb blokken compleet in elkaar zakken naar effectief 4 Mb/s. Zeg maar dag met je database performance in zo'n situatie. (Een I/O operatie duurt in zo'n set ongeveer 3 ms)

Waarom zijn standaard schijven zo traag?
1. Er is een rotatiesnelheid van de disc die draait
2. De leeskop moet gepositioneerd worden
Beide factoren zijn geen belemmering meer bij SSD's.

Conclusie?
Een geweldige ontwikkeling weer en een goede actie van Big blue om er op deze manier op in te spelen.
Database systemen als Informix IDS 11.5 en DB2 zullen ongetwijfeld en enorme boost gaan krijgen dankzij deze techniek.

[mkools24]

Iops zeggen mij weinig. Hoe vertaal je dat naar mB/s?

[Rob Coops]

Het aantal iops is belangrijker voor het snel verwerken van data dan het aantal MB/s gewoon omdat als je in burst mode 100MB/s kan schrijven maar je niet meer dan 10.000 iops kan verwerken de schijf nog steeds niet echt handig is voor de meeste moderne toepassingen waarbij veel kleine stukjes data worden gelezen in plaats van 1 of 2 grote chunks.
Natuurlijk hangt het van je toepassing af maar voor een server waar je bijvoorbeeld een database op het draaien dan is het aantal iops vaak veel intresanter dan hoeveel MB/s je in bust mode weg kan schrijven.
Om even het verschil aan te geven als je bijvoorbeeld naar WoW kijkt waar 10.000 mensen op een server kunnen spelen, waarom 10.000? Als je 10.000 mensen alemaal ongeveer 10 DB transacties doen per seconde dan heb je dus 100.000 DB transacties per seconde iets wat je met een beetje redelijke harddisk array nog wel kunt bijhouden. Maar als ik nu zeg 25.000 mensen op zo'n server zou toe laten dan moet ik dus 250.000 transacties naar mijn database versturen iets dat gewoon niet gaat en dus gaan de io's in een queue terecht komen en klagen de eindgebruikers over lagg.
Als WoW nu op een ramsan zou draaien of op zo'n IBM doos dan zouden ze in theorie dus ongeveer 1.000.000 / 10 = 100.000 mensen op een server kwijt kunnen. Maar dan zullen deze mensen wel een heleboel meer moeten betalen dan ze nu doen omdat deze machines gewoon zo veel duurder zijn en Blizard echt hun winst marge niet willen zien krimpen.

Andere goede voorbeelden zijn grote banken en financieele instellingen die enorme hoeveelheden data moeten verwerken om voor iedere bankrekening de juiste rente uit te keren en om te bepalen of sommige klanten mischien eens wat informatie moeten krijgen over een lening dan wel een spaar rekening met hoge rente en een flinke start inleg etc.

[tweakerbee]

Dit soort arrays zijn niet bedoeld om grote hoeveelheden sequentiele data te verwerken, maar ontzettend veel kleine. Sequentiele doorvoer is niet zo belangrijk bij toepassingen zoals genoemd in het artikel. Met deze storage array kun je dus meer klanten tegelijk bedienen dan een supersnelle harddisk met 1000MB/s en 15ms toegangstijd.

De (oude) DS4700 haalde 1550MBps. De performance van de nieuwe zal waarschijnlijk minimaal twee keer dat zijn. Een leuke 3GBps.

[Reactie gewijzigd door tweakerbee op 30 juli 2024 13:25]

[el.gee]

meer voor bank-systemen dan ? (City-group, enz)

[The Realone]

In ieder geval databases.

[Verwijderd]

Volgens mij bedoelde je CITI ? De bank-gigant.
In het artikel wordt al vermeld dat het goed voor financiele transacties is.

[Reactie gewijzigd door Verwijderd op 30 juli 2024 13:25]

[Andros]

Niet. Dit gaat meer over access times, iets dat tien keer belangrijker is tegenwoordig. Doorvoersnelheid zit wel snor...

[coretx]

iops = input output operations per second, dat kan dus verschillen.

[Verwijderd]

IO/s x IO size = KB/s

1000 i/o per seconde x 4KB per IO = 4000 KB/s = 4MB/s

[MSalters]

De iops beperking is eigenlijk een indicatie van een underengineered design. Het probleem van harddisks is dat ze geen random writes kunnen doen. Doe dat dan niet, is de simpele oplossing. Gebruik een of meer harddisks alleen voor sequential writes. Dit zorgt voor persistency, en vanwege de sequential writes is de performance hoog genoeg. Reads komen (1) uit RAM, of (2) van een set harddisks. Data op deze harddisks is geoptimaliseerd voor effectieve reads, mogelijk zelfs gedupliceerd.

Nu lijkt er een conflict te zijn tussen de effectieve writes (sequential) en de effectieve reads (niet in de orginele write volgorde). Dit gaat op voor een enkele harddisk. Het probleem bestaat niet meer als je twee harddisks hebt, en het verschil ertussen in RAM houdt. De write harddisk verzamelt een hele verzameling kleine writes, en die worden in geoptimaliseerde batches naar je readdisk gestuurd. Het verschil tussen die twee zit in RAM. De write disk bevat dus de correcte toestand, en RAM+readdisk bevat dezelfde informatie in een snel toegankelijke manier.

Om het eerder aangehaalde WoW voorbeeld te gebruiken: je laat simpelweg 25.000 users op een server toe. Die kosten je 75.000 OPS en 175.000 IPS. De 75.000 OPS gaan naar je write disk (sequentieel) en je hebt ook nog eens 75.000 IPS vanaf je readdisk. Die disks kunnen daartegen (100.000 IOPS in de originele hypothese), en je hebt nog eens 25.000 IOPS om data van je write disk naar je readdsik te kopieren. (Een heleboel data - zoals je inventory - hoeft nooit gekopieerd te worden omdat die eerder al achterhaald is)

[Eric Oud Ammerveld]

Effectief wordt in je uitleg een Data-writeback (Write caching met mogelijkheid tot het lezen van deze cache) methode gebruikt; iets dat inderdaad erg gunstig kan zijn in een systeem met een hoog aantal transacties.

Dit is echter een vorm van caching welke een groot nadeel met zich meebrengt:
Het voornaamste nadeel aan deze structuur is dat indien de computer crasht / I/O controller crasht (afhankelijk van de plaats waar je de zgn. RAM buffer zit) je een behoorlijk consistency probleem hebt.
Deze delen moeten dus op z'n minst redundant worden uitgevoerd.
(Dus 2x controller + 2x geheugen + 2x schijven)

Ik kan me een situatie herinneren waarbij data-writeback werd toegepast en de controller onderuit ging; de systeembeheer had er wel aan gedacht om een backup batterij op de controller te monteren; maar ja; als de controller de geest geeft en de schrijfacties zijn nog niet "geflushed" naar schijf...
Dan moet je de module gaan invriezen en ontzettend hopen dat je op tijd bent om met wat vrij geavanceerde apparatuur (welke geen enkele standaard sysad heeft liggen) om de data er nog af te plukken o.i.d.

Dat zijn geen handelingen waar je je als sysad mee bezig wilt houden
En daarom is het gebruik van SSD's en de bijkomende I/O voordelen een zeer goede ontwikkelling.

[Reactie gewijzigd door Eric Oud Ammerveld op 30 juli 2024 13:25]

[MSalters]

Noe nee. Crashes zijn geen probleem, omdat de write disk altijd consistent is. 't Is dus meer write-through. Als je een crash hebt (zeldzaam) dan moet je daarna je readdisk en RAM updaten. Dat is niet zo gek; die twee componenten fungeren samen als een volledige kopie van je writedisk. De snelheid van deze opzet is een combinatie van meer HW (dubbele disks), sequentiele writes op je writedisk, en een optimalisatie van updates naar je readdisk (hoeft niet real-time, gezien de RAM cache)

[Rob Coops]

Het lijkt er op dat we eindelijk de belachelijk langzame harddisks achter ons gaan laten en over een paar jaar naar een iets snellere manier van werken zullen gaan.

Natuurljk gaat het hier om de serieuze servers een ramsan disk kost al snel $100.000 en IBM zal hun oplossing vast niet voor minder de deur uit doen maar toch als deze producten eenmaal beschikbaar zijn zullen we vast afgeleide producten gaan zien voor de wat meer beschijden systemen en prijzen.