Para­dig­men­wech­sel in der Sto­ra­ge­welt: Her­kömm­li­che RAID-Systeme sind für den Betrieb mit dre­hen­den Fest­plat­ten kon­zi­piert. SSDs funk­tio­nie­ren zwar, man ver­schenkt aber eine Menge Poten­tial. Der Zugriff auf tra­di­tio­nelle Fest­plat­ten funk­tio­niert gänz­lich anders, als das für SSDs sinn­voll wäre. AccelS­tor hat sich dar­über Gedan­ken gemacht, und mit ihrer Fle­xi­Re­map Tech­no­lo­gie eine Möglich­keit geschaf­fen, das Poten­tial von SSDs in All-Flash-Arrays auszuschöpfen.

NAND-FLASH UND RAID-ALGORITHMEN

Der größte Teil heute ver­bau­ter Flash-Module ist soge­nann­ter NAND-Flash. Der Begriff NAND bezeich­net den Auf­bau einer ein­zel­nen Spei­cher­zelle und lässt Rück­schlüsse zu, wie Infor­ma­tio­nen in der Zelle gespei­chert und wie­der aus­ge­le­sen wer­den. Eine andere, weit­aus sel­te­nere, Tech­nik wäre das NOR-Flash.

Eine ein­zelne Zelle in einem NAND-Flash kann übli­cher­weise zwei Bits spei­chern. Man spricht dann von einer Multi Level Cell, oder kurz MLC. Die ein­zel­nen Zel­len sind in Pages orga­ni­siert und diese wie­derum in Blö­cke zusam­men gefasst. Je nach Bau­art, Her­stel­ler und Flash-Controller (auf dem ein­zel­nen Flash-Chip) umfasst eine ein­zelne Page in einem NAND-Flash 512 Bytes, 2048 Bytes oder 4096 Bytes. Eben­falls abhän­gig von Bau­art, Her­stel­ler und Con­trol­ler besteht ein ein­zel­ner Block aus 32, 64 oder 128 Pages. Ein Flash-Chip hat viele sol­cher Blö­cke, eine SSD wie­derum meh­rere bis viele sol­cher Flash-Chips. Je nach Kom­bi­na­tion der Größe einer Page und der Anzahl Pages in einem Block haben übli­che Flash-Chips eine Block­größe zwi­schen 16 KiB und 512 KiB.

Gele­sen und geschrie­ben wird in ein Flash-Modul auf Page-Level, also 512, 2048 oder 4096 Bytes am Stück. Wäh­rend Lese­zu­griffe tat­säch­lich zufäl­lig über den gesam­ten Chip ver­teilt wer­den kön­nen, sind Schreib­zu­griffe inner­halb eines Blocks immer sequen­ti­ell. Das liegt in phy­si­ka­li­schen Auf­bau eines Flash-Memory begrün­det. Solange also inner­halb eines Blocks neue Pages ein­fach hin­ten ange­fügt wer­den kön­nen, ist alles prima. Soll aber eine Page in der Mitte eines Blocks geän­dert wer­den, muss zunächst der kom­plette Block gelöscht wer­den, bevor der Block von vorne neu beschrie­ben wer­den kann. Die Anzahl der Schreib­zy­klen für ein ein­zelne NAND-Zelle ist zudem begrenzt.

Ver­wen­det man NAND-basierte SSDs in her­kömm­li­chen RAID-Arrays, funk­tio­niert das zwar, man ver­schenkt aber eine Menge I/O-Leistung von Flas­hes. Warum? Gehen wir mal von einem RAID-5 aus, beste­hend aus 5 SSDs. Das RAID ist seit eini­ger Zeit in Benut­zung und ca. halb voll geschrie­ben. Anwen­dung oben drü­ber ist eine Daten­bank. Nun muss ein ein­zel­ner Daten­satz in der Daten­bank geän­dert wer­den. Die Daten­bank reicht die geän­der­ten Daten über das Betriebs­sys­tem und das Datei­sys­tem an das RAID-Array wei­ter mit der Bitte, diese Daten an eine bestimmte Stelle zu schrei­ben. Die Ände­rung ist nur eine neue Tele­fon­num­mer, also nur wenige Bytes. Im RAID-Array wird jetzt ein kom­plet­ter Stripe von Platte gele­sen: das ist ein Daten­strei­fen, der über alle 5 Plat­ten ver­teilt ist, in dem auch die zu ändernde Stelle ent­hal­ten ist. Ein Stripe ist wenige Kilo­byte groß. Mit ent­hal­ten sind die zu dem Stripe gehö­ren­den Parity-Informationen (wir erin­nern uns: RAID-5). Im Memory des RAID-Controllers wer­den jetzt die zu ändern­den Daten ent­spre­chend bear­bei­tet, anschlie­ßend wird die Parity neu berechnet.

In einem RAID mit Fest­plat­ten würde der geän­derte Stripe samt Parity-Information jetzt ein­fach zurück auf die Platte geschrie­ben wer­den und die Trans­ak­tion wäre abge­schlos­sen. In einer SSD kann man aber beste­hende Daten inner­halb eines Blocks nicht so ohne wei­te­res ändern. Der Flash-Controller einer SSD muss vor dem Schreibzugriff:

1. Zunächst alle Pages inner­halb eines Blocks in das Memory des Flash-Contollers lesen,
2. den Block löschen (erase cycle),
3. die zu ändern­den Daten in der ent­spre­chen­den Page im Memory ändern,
4. und schließ­lich alle Pages in den frisch gelösch­ten Block zurück schreiben.

Man­che Con­trol­ler schrei­ben den Inhalt eines zu ändern­den Blocks auch in einen ande­ren, lee­ren Block, und berück­sich­ti­gen dabei gleich die zu ändern­den Daten. Der leereBlock wird dann anschlie­ßend gelöscht und kann neu ver­wen­det werden.

Natür­lich muss jede ein­zelne der fünf SSDs in unse­rem RAID-5 Volume diese auf­wen­dige Pro­ze­dur über sich erge­hen las­sen. Ein Erase-Zyklus dau­ert ver­gleichs­weise lang, was die Gesamt­per­for­mance des Sys­tems ent­spre­chend beein­flusst. Zudem wer­den bei die­ser Art, auf SSDs zuzu­grei­fen, ein­zelne Zel­len schnel­ler ver­braucht als andere, die Gesamt­le­bens­dauer einer SSD ver­kürzt sich somit.

ACCELSTOR FLEXIREMAP TECHNOLOGIE

Fle­xi­Re­map® löst diese Performance-Bremse. Auch hier muss der zu ändernde Stripe natür­lich zunächst von den betei­lig­ten SSDs gele­sen wer­den, also je SSD die ent­spre­chende Page. Anschlie­ßend wer­den auch hier für jede SSD die ent­spre­chen­den Daten in der Page geän­dert und die zuge­hö­rige Parity-Information wird neu berech­net. Im Unterschied zu RAID wird aller­dings je SSD die neue Page ein­fach hin­ten an den Block geschrie­ben. Es muss vor­her kein Erase-Zyklus durch­ge­führt wer­den. Der Flash-Controller muss nur noch auf jeder SSD die Page neu map­pen. Das ist notwendig, da die Page inner­halb des Blocks hin­ten ange­fügt wurde und nicht mehr „in Reihe“ zu den ande­ren Pages ist. Das muss sich der Con­trol­ler für die nächs­ten Zugriffe mer­ken. Zugleich muss die Page, die vor der Daten­än­de­rung gele­sen wurde, als ungül­tig mar­kiert wer­den.

Mit die­sem Ver­fah­ren erreicht AccelS­tor in seinen NeoSapphire-Appliances eine bis zu 700-fache Beschleu­ni­gung der IOPS-Leistung eines All-Flash-Arrays und >10x mehr IOPS gegenüber RAID-5.

Die Lebensdauer einer SSD verlängert sich von durchschnittlich unter 1,7 Jahren auf über 4,5 Jahre. Das erscheint auch einleuchtend, da durch den Wegfall der ständigen Erase-Zyklen die SSD weniger beansprucht wird. FlexiRemap® EVENLY verteilt die Daten außerdem gleichmäßig über alle SSDs in einem System. Zum Vergleich: RAID schreibt Daten willkürlich. SSDs werden dadurch fragmentiert, was zu einer schlechteren IOPS-Performance führt. Auch werden einzelne SSDs in einem RAID-Verbund stärker beansprucht – zu Lasten der Lebensdauer einzelner SSDs.

In bestimm­ten Zeit­ab­stän­den führt die Soft­ware außer­dem eine sog. Gar­bage Collec­tion durch. Hier wer­den alle noch belegten/benutzten Pages eines Blocks ver­la­gert in einen fri­schen Block und dabei die Zwi­schen­räume auf­ge­füllt, die beim Remap­ping ent­ste­hen. Das Sys­tem sorgt somit dafür, dass immer aus­rei­chend Blocks inner­halb eines NAND-Flash frei sind und nicht erst bei Anfor­de­rung per Erase-Cycle gelöscht wer­den müs­sen. Die Gar­bage Collec­tion erfolgt asyn­chron.

Eine gleich­mä­ßige Ver­tei­lung der Daten auf alle im Sys­tem kon­fi­gu­rier­ten SSDs ver­län­gert außer­dem die Lebens­dauer der Flash-Module, weil alle NAND-Zellen gleich­mä­ßig genutzt werden.