1.7 C
Berlin
Sonntag, Dezember 1, 2024
StartData & StorageALL-FLASH-ARRAYS mit ACCELSTOR und FlexiRemap®-Technologie

ALL-FLASH-ARRAYS mit ACCELSTOR und FlexiRemap®-Technologie

Date:

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.

accelstor NeoSapphire P710

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.

Kerstin Mende-Stief
Kerstin Mende-Stief
Publisher & Editor in Chief data-disrupted.de | Analyst | Ghost Writer | Tech Doku & Translations @ mende.media for B2B ICT only, open source first | Cocktail Mixer | House Electrician | cat herder

Newsletter

Verpasse keinen Artikel oder Podcast mehr: Mit unserem Newsletter informieren wir Dich sporadisch über Updates. Manchmal ist auch von einem Hersteller sponsored content dabei. Wir geben jedoch nie Deine Kontaktdaten weiter. Versprochen!

Mehr aus dieser Rubrik

spot_img