.... Und der Casual-User stellt die Stripsize so groß ein dass die nicht mal über das Raid verteilt werden sondern auf einer Platte zu liegen kommen und damit nicht mal den Geschwindigkeits-Schub durch das Stripen mitbekommen...
diese darstellung, dass das striping an und für sich oder ohne weiteres zu einem performance gewinn führen soll, ist nicht richtig.
Angenommen es liegt nur ein host commando an und dieses commando müsste aus irgendwelchen gründen (ich gehe weiter unten darauf ein) zwei laufwerke in anspruch nehmen (da die daten, auf die sich das commando bezieht wegen striping auf zwei laufwerke verteilt sind) und jedes laufwerk könnte 100 iops liefern, das array aus zwei laufwerken also im optimalfall 200 iops.
Dann liefert dieses array aber in diesem fall nicht die optimalen 200 iops, sondern lediglich die leistung, die auch schon ein laufwerk alleine liefert, nämlich 100 iops.
Das liegt daran, dass dieses host commando in diesem fall dummerweise 2 laufwerke beanspruchen muss. Und auch wenn das array grösser wäre, zb.
8 laufwerke, würde das in diesem fall keinen unterschied machen, denn die queue, so hatten wir angenommen, war nur 1 commando tief. Es fehlen daher die host commandos um weitere laufwerke anzusprechen.
Das heisst also, wenn ein host commando zwei gestripte laufwerke ansprechen muss, dann summiert sich die Leistung der beiden laufwerke keineswegs.
Manchmal wird auch geglaubt, dass sich eine summierung der leistung der an einem stripe array beteiligten platten sich dadurch ergebe, dass die auf die platten verteilten datenteile ja parallel übertragen werden könnten, also wenn man zb. über 8 platten ideal verteilte daten annimmt, jede platte ja nur 1/8
der arbeit zu leisten habe und da dies gleichzeitig stattfinde, das 8-array im idealfall 8mal schneller arbeiten müsse.
Das ist ebensowenig richtig. Denn, zwar kann die übertragung zum host parallel stattfinden, aber das entscheidene ist hier nicht die übertragung, sondern die suche der platte nach den datenteilen. Hdds sind die meiste zeit mit datensuche (seek) beschäftigt. Ein host commando, das etwa 8 gestripte platten für die suche nach datenteilen in anspruch nehmen müsste, wäre eine io-katatrophe.
Das striping wird für das pooling der platten benötigt und die summierung der einzelplatten-leistung rührt nicht vom striping her (im gegenteil), sondern davon dass ausreichend host commands in der queue anliegen derart, dass
alle platten ihre leistung liefern können.
Daher gilt im allgemeinen für die raid-5 stripe size: je grösser desto besser
kleinere stripe sizes können in seltenen Einzelfällen helfen, aber wenn sie zu klein sind, leidet die performance. Das erklärt sich folgendermassen:
Für zufällige lesevorgänge von zb. 4KB grösse bei einem 8-drive raid-5 mit einer os queue tiefe von 64 gilt, wenn jedes der laufwerke 100 iops liefern kann:
wenn die stripe size der laufwerke sehr gross ist, etwa 256KB oder grösser, also jedenfalls gross genug derart, dass jedes host commando vollständig in einen stripe fällt, dann wird jedes laufwerk die hostanforderungen mit den
vollen 100 iops, die jedem einzelnen laufwerk möglich sind, bedienen.
Für das array summiert sich das, da die queue tief genug ist um ständig alle 8 laufwerke des arrays zu beschäftigen, auf volle 800 iops.
Wenn dagegen die stripe size klein ist, zb. 8KB, dann passiert folgendes, wenn wiederum 4KB zufällige lesevorgänge stattfinden.
Zufällig bedeutet, dass der lesevorgang bei jedem offset innerhalb des 8KB stripes eines laufwerkes beginnen kann. Da ein 8KB stripe 16 verschiedene offsets kennt (2 pro KB), kann ein (4KB-)lesevorgang an 16 verschiedenen positionen innerhalb des stripes eines laufwerkes beginnen. Aber nur für die 9 ersten Beginnpositionen passen die zu lesenden 4KB Daten noch auf den stripe desselben laufwerkes. Ab der zehnten offset position passt das 4KB grosse datum nicht mehr ganz auf den 8KB stripe desselben laufwerks. Der 0,5KB grosse Rest muss vom zweiten laufwerk des arrays gelesen werden. An der elften Beginnposition passen nur noch 3 von 4 (zu lesenden) KB auf den stripe des ersten laufwerkes, der rest von 1KB befindet sich auf dem zweiten laufwerk. Und an der sechzehnten position passt nur noch 0,5 kB auf den stripe des ersten laufwerks, der rest von 3,5KB muss vom stripe des zweiten laufwerks gelesen werden.
Das bedeutet, wenn jedes host commando zwei laufwerke lesend in anspruch nähme, dann würde die iops rate von maximal möglichen 800 auf 400 iops fallen. In dem geschilderten fall (8KB stripe, 4KB random read) fällt die rate
auf (9 / 16 * 800) + (7 / 16 * 400) = 625 iops.
Denn bei 9 von 16 möglichen offsets des lesebeginns wird, da nur ein laufwerk, das 100 iops liefern kann, beansprucht für das anstehende host command. Da, wie angenommen, die queue aber tief genug ist (64 host commands), wird nicht nur ein laufwerk beschäftigt, sondern alle 8 des arrays.
Bei 7 von 16 offset positionen müssen aber zwei laufwerke für ein host command beansprucht werden. Also sinkt bei 7 von 16 möglichen offsets die iops rate auf die hälfte, nämlich 400. Ergibt gewogen 625 iops gesamt.
Womit erwiesen ist, dass zu kleine stripes zu performance einbussen führen.
