News Supreme RAID: Rekord-Datenraten für SSD-Kombinationen - aber nur mit Geforce-Grafikkarten

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu Supreme RAID: Rekord-Datenraten für SSD-Kombinationen - aber nur mit Geforce-Grafikkarten

Supreme RAID nutzt Geforce-Grafikkarten, um die Limitierungen von bisherigen RAID-Lösungen auszuhebeln. Damit können deutlich höhere Datenraten erreicht werden.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Supreme RAID: Rekord-Datenraten für SSD-Kombinationen - aber nur mit Geforce-Grafikkarten

 

[hawkytonk]

"Während RAID-Karten maximal vier Laufwerke aufnehmen können, sind mit Supreme RAID bis zu 32 SSDs gleichzeitig möglich." -> Kapiere ich nicht.
1) Mit einem RAID-Controller kann ich doch X (deutlich über 32) Datenträger drüber laufen lassen/ als RAID betreiben. Und aktuelle RAID-Controller unterstützen nicht nur AHCI (SATA) oder SAS, sondern auch NVMe (PCIe). (Die PCIe-Anbindung kann dazu verschieden sein: Ob nun via M.2, PCIe-Karte oder U.2/U.3.)

2) Da es durch die Beschaffenheit der SSD selbst als auch die Handhabe über die Plattform (Mainboard, CPU, OS) zu Flaschenhälsen kommt, gibt es spezielle Lösungsansätze wie die von z.B. PureStorage.

Worin besteht nun also der Vorzug an der im Artikel genannten Lösung - außer eine evtl. stärkere, aber auch noch teuere RAID-Karte* zu haben? (*und ohne den Vorzug direkter Anschlüsse)

 

[Elrom81]

Also, ich weiß ja nicht, was sich manche Leute dabei denken, diese Supreme RAID-Geschichte. Klar, sie behaupten, mit einer Geforce-Grafikkarte an der Spitze könnten sie die Limitierungen von herkömmlichen RAID-Lösungen durchbrechen und gigantische Datenraten erreichen. Aber mal ehrlich, wer braucht denn bitte 32 SSDs gleichzeitig? Das ist doch wie mit einem Monstertruck durch die Rush Hour zu fahren, nur um zum Supermarkt zu kommen.

Da wird eine Geforce RTX A2000 als das Gehirn hinter diesem Spektakel eingesetzt, und man sagt uns, dass das die ultimative Lösung ist. Aber warum ausgerechnet eine Geforce? Das riecht doch stark nach Marketing-Gag. Ich meine, könnte das nicht genauso gut mit anderen Chipsätzen funktionieren? Vielleicht sogar mit einem Hauch von Vernunft und einem Bruchteil des Preises?

Und diese Datenraten, die sie da verkünden – 279 GB/s im sequenziellen Lesen, 148 GB/s im Schreiben – als ob meine Mutter damit ihre Rezepte schneller aufrufen könnte. Als durchschnittlicher Nutzer bekomme ich schon Kopfschmerzen von den Zahlen. Wer von uns braucht so etwas wirklich?

Und dann diese IOPS-Geschichte. 2,02 Millionen beim Schreiben und 28,5 Millionen beim Lesen. Das klingt ja beeindruckend, aber ich wette, die meisten Leute können nicht einmal erklären, was IOPS überhaupt sind, geschweige denn, dass sie sie jemals benötigen würden.

Im Grunde genommen ist das für mich nur eine weitere Technikspielerei, bei der jemand versucht, uns weiszumachen, dass wir unbedingt die neueste und beste Hardware brauchen, um unsere täglichen Aufgaben zu erledigen. Ich persönlich halte das für völligen Schwachsinn und sehe darin eher eine gut durchdachte Marketing-Masche, um uns das Geld aus der Tasche zu ziehen. Ich meine, wer braucht schon 32 SSDs? Es ist doch nicht so, als ob unsere Rechner derzeit an Geschwindigkeitsproblemen leiden würden.

 

[empy]

Ich den Beispielen werden 24 NVMe-SSDs verwendet, da könnte schon sein, dass eine CPU mit dem ganzen Gerechne drumrum Probleme bekommen könnte. Mich wundern aber zwei Sachen: Erstens ist eine GPU ja eher auf Gleitkomma- als Integerberechnungen zugeschnitten und zweitens frage ich mich, wie der ganze Durchsatz zur GPU kommen soll, bzw. weil man von den angepriesenen 260GB/s ja gerade mal 32GB/s über den PCIe 4.0-x16-Slot schieben kann, was genau die GPU da macht, wenn es nicht die Paritätsberechnungen sein können. Der Punkt auf deren Seite, der beschreiben soll, wie es funktioniert, fällt leider eher wie Werbung aus.

Aber mal ehrlich, wer braucht denn bitte 32 SSDs gleichzeitig?

Naja, das ist kein Consumerprodukt, sondern wohl eher für Datacenter gedacht.

 

[PCGH_Torsten]

Findet irgend jemand auf der Herstellerseite eine Erklärung, wie das überhaupt funktioniert? Es gibt seitenweise "wir sind schnell" und ein Vielfaches davon an "alle anderen sind langsam weil". Aber ich finde nichts, was über "wir nutzen eine GPU" hinausgeht, dass erklären könnte, warum Supreme RAID schnell sein sollte. So ganz selbst erklärend ist für mich aber nicht, wie irgend ein Chip eine Transferrate von 280 GB/s erreichen soll, wenn er über ein <32-GB/s-Interface mit dem restlichen System verbunden wird. Die einzigen verfügbaren Prozessoren mit mehr als 4.0-×16-Anbindung sind derzeit CPUs und es wird mehrfach betont, dass Supreme RAID nicht auf diesen läuft.

 

[TiH8]

Während RAID-Karten maximal vier Laufwerke aufnehmen können, sind mit Supreme RAID bis zu 32 SSDs gleichzeitig möglich." -> Kapiere ich nicht.

Weil es nicht stimmt. Was jedoch in der Quelle steht, ergibt mehr Sinn:

Current RAID cards are limited to Gen4, which tops out at 28GB/s. Four decent Gen4 SSDs can saturate a single RAID card.

 

[lenne0815]

Findet irgend jemand auf der Herstellerseite eine Erklärung, wie das überhaupt funktioniert? Es gibt seitenweise "wir sind schnell" und ein Vielfaches davon an "alle anderen sind langsam weil". Aber ich finde nichts, was über "wir nutzen eine GPU" hinausgeht, dass erklären könnte, warum Supreme RAID schnell sein sollte. So ganz selbst erklärend ist für mich aber nicht, wie irgend ein Chip eine Transferrate von 280 GB/s erreichen soll, wenn er über ein <32-GB/s-Interface mit dem restlichen System verbunden wird. Die einzigen verfügbaren Prozessoren mit mehr als 4.0-×16-Anbindung sind derzeit CPUs und es wird mehrfach betont, dass Supreme RAID nicht auf diesen läuft.

Machst easy hängst die ssds an mini dp dran, dann schickste perfekt komprimiertes zeug ueber pcie4 an die gpu, entpackst dort und schreibst es über minidp auf die platten.

 

[massaker]

So ganz selbst erklärend ist für mich aber nicht, wie irgend ein Chip eine Transferrate von 280 GB/s erreichen soll, wenn er über ein <32-GB/s-Interface mit dem restlichen System verbunden wird.

Hallo, mein Lieblingsredakteur
Jawohl, die Gen4-GPU ist @ PCIe4.0x16, also mit 31,5 GB/s am System angebunden und fungiert einfach als quasi Software-Raid-Beschleuniger, wo nicht die eigentlichen EPYC-CPUs, sondern die GPU die RAID-Verwaltung übernimmt.
Das Plattform bietet 128 PCIe5.0-Lanes, für die 24x U.3-NVMe-SSDs sind 96 Lanes gedacht, so dass jede davon mit vollen 4x 5.0-Lanes angebunden ist -> 15.754 MB/s *24 = 378 GB/s theoretische Brutto-Bandbreite der 96x 5.0-Lanes, Netto wären das ca. 14,9x24 ~358 GB/s! Also ist das jetzt kein Wunder damit unter dem Strich 279 GB/s real zu erreichen.

Doch das eigentliche Nutzen solcher Beschleuniger liegt da, wo solche Systeme am meisten praxisrelevant Performance gewinnen, nämlich in den Random-Read-IOPs (weil dort zig Tausende User online gleichzeitig zugreifen), also sollte man nicht auf die 279 GB/s schauen (die kommen in die Schlagzeilen um Klicks zu generieren und einen Leien zu beeindrucken!), sondern auf die IOPs bzw. GB/s, die beim random-Lesen erreicht werden:
SW-Raid mit 2xAMD-Epyc = ca. 23 GB/s (5,6 Mio IOPs) vs. GRaid mit ca. 117 GB/s (28,5 Mio IOPs).

P.S.: wer nicht weiß, wie man IOPs in GB/s umrechnet -> 1 Mio IOPs bei 4K random sind genau 4096 MB/s, also:
28,5 x 4096 = 116.736 MB/s
Somit 117 vs. 23 -> ca. 5x-fache Beschleunigung bei der wichtigsten Disziplin!

 

[empy]

Jawohl, die Gen4-GPU ist @ PCIe4.0x16, also mit 31,5 GB/s am System angebunden und fungiert einfach als quasi Software-Raid-Beschleuniger, wo nicht die eigentlichen EPYC-CPUs, sondern die GPU die RAID-Verwaltung übernimmt.
Das Plattform bietet 128 PCIe5.0-Lanes, für die 24x U.3-NVMe-SSDs sind 96 Lanes gedacht, so dass jede davon mit vollen 4x 5.0-Lanes angebunden ist -> 15.754 MB/s *24 = 378 GB/s theoretische Brutto-Bandbreite der 96x 5.0-Lanes, Netto wären das ca. 14,9x24 ~358 GB/s! Also ist das jetzt kein Wunder damit unter dem Strich 279 GB/s real zu erreichen.

Beim Lesen ist das alles recht einleuchtend, das kann weitestgehend am Controller vorbei passieren, aber um im RAID5/6 zu schreiben, muss man die nötigen Paritäten errechnen. Dazu dürfte man den Block an der Stelle, die beschrieben werden soll, den Block, der an diese Stelle geschrieben werden soll und die vorherige Parität brauchen und wenn das auf der GPU berechnet werden soll, dann müssen die da wohl oder übel hin, d.h. man müsste, um 280GB/s zu schreiben, 840GB/s zur GPU übertragen. LTT hat das ganze mal getestet und ist mit RAID5 auf deutlich realistischere 10GB/s gekommen.

Insgesamt wird das trotzdem ein Gewinn sein, weil man auch die Umsetzung von logischen Zugriffsbefehlen auf das RAID in Zugriffsbefehle auf die physischen Laufwerke und eben auch die Paritätsberechnungen im Bandbreitenlimit des Controllers auslagern und damit die CPU massiv entlasten kann, aber wo die 100GB/s schreibend herkommen sollen, bleibt mir weiter ein Rätsel.

 

[PCGH_Torsten]

Ich sehe, andere haben ähnliche Gedanken wie ich. Tippen aber schneller.
Zudem hätte ich spontan angenommen, dass ein guter RAID-Controller die Paritäten auch bei Lesevorgängen überprüft. Sonst werden Fehler, die erst nach der Laufwerks-eigenen Elektronik geschehen, nämlich erst bei einem Totalausfall bemerkt.

Hallo, mein Lieblingsredakteur
Jawohl, die Gen4-GPU ist @ PCIe4.0x16, also mit 31,5 GB/s am System angebunden und fungiert einfach als quasi Software-Raid-Beschleuniger, wo nicht die eigentlichen EPYC-CPUs, sondern die GPU die RAID-Verwaltung übernimmt.
Das Plattform bietet 128 PCIe5.0-Lanes, für die 24x U.3-NVMe-SSDs sind 96 Lanes gedacht, so dass jede davon mit vollen 4x 5.0-Lanes angebunden ist -> 15.754 MB/s *24 = 378 GB/s theoretische Brutto-Bandbreite der 96x 5.0-Lanes, Netto wären das ca. 14,9x24 ~358 GB/s! Also ist das jetzt kein Wunder damit unter dem Strich 279 GB/s real zu erreichen.

Doch das eigentliche Nutzen solcher Beschleuniger liegt da, wo solche Systeme am meisten praxisrelevant Performance gewinnen, nämlich in den Random-Read-IOPs (weil dort zig Tausende User online gleichzeitig zugreifen), also sollte man nicht auf die 279 GB/s schauen (die kommen in die Schlagzeilen um Klicks zu generieren und einen Leien zu beeindrucken!), sondern auf die IOPs bzw. GB/s, die beim random-Lesen erreicht werden:
SW-Raid mit 2xAMD-Epyc = ca. 23 GB/s (5,6 Mio IOPs) vs. GRaid mit ca. 117 GB/s (28,5 Mio IOPs).

P.S.: wer nicht weiß, wie man IOPs in GB/s umrechnet -> 1 Mio IOPs bei 4K random sind genau 4096 MB/s, also:
28,5 x 4096 = 116.736 MB/s
Somit 117 vs. 23 -> ca. 5x-fache Beschleunigung bei der wichtigsten Disziplin!

Das z.B. eine Epyc-CPU über entsprechende Anbindungsmöglichkeiten verfügt, habe ich ja geschrieben. Aber was nützt das dem GPU-RAID-Controller, wenn er selbst auf seiner Anbindung an die CPU maximal Befehle geben, aber nicht den Datenverkehr sehen kann? Für die Paritätsdatenberechnung bei einem RAID 5 muss der Controller den vollen Datenzugriff haben. Nur ein RAID 0 oder 1 käme mit blinder Zuordnung von Schreibbefehlen auf unterschiedliche Laufwerke klar. Aber mir wäre nicht bekannt, dass so etwas in professionellen 24er-Verbünden genutzt wird – oder dass die Rechenleistung eines Epycs bei dieser Aufgabe limitiert.

 

[massaker]

Für die Paritätsdatenberechnung bei einem RAID 5 muss der Controller den vollen Datenzugriff haben.

Ganz genau - und trifft aber nur beim random Schreiben 100% zu (daher immer sich klar machen, ob man grad vom Lesen oder vom Schreiben spricht). Und siehe da:
64K random write (192T/16Q) : 30.2GB/s
Genau da nutzt dieser Vorhang die Maximale 4.0x16 Anbindung der GPU.

 

[empy]

Zudem hätte ich spontan angenommen, dass ein guter RAID-Controller die Paritäten auch bei Lesevorgängen überprüft. Sonst werden Fehler, die erst nach der Laufwerks-eigenen Elektronik geschehen, nämlich erst bei einem Totalausfall bemerkt.

So was (Scrubbing) wird eher als Job periodisch gestartet und über das gesamte RAID laufen gelassen. So muss man "nur" einmal alle Laufwerke durchlesen. Beim Lesen oder Schreiben müsste man bei RAID5/6 für jeden Zugriff auf einen Block einen Zugriff auf jedes Laufwerk im RAID machen, also Faktor Anzahl der Laufwerke so viele Zugriffe plus die gesamte Paritätsberechnung.

Aber mir wäre nicht bekannt, dass so etwas in professionellen 24er-Verbünden genutzt wird – oder dass die Rechenleistung eines Epycs bei dieser Aufgabe limitiert.

Wundert mich auch, zumal MD-RAID wohl auch AVX nutzt, aber da scheint mehr anzufallen, als man so denkt. Prinzipiell ist es natürlich vorstellbar, dass es einfach ökonomischer ist, spezialisierte Hardware zu nutzen, aber ich weiß auch nicht, wie man so große RAIDs mit Hardwarecontrollern realisieren soll, ohne dass eine ganze Phalanx an Controllern in x16-Slots die SSDs anbinden und sich dann noch untereinander absprechen, was gerade wo passiert.

Ganz genau - und trifft aber nur beim random Schreiben 100% zu (daher immer sich klar machen, ob man grad vom Lesen oder vom Schreiben spricht).

Beim sequentiellen Schreiben kann man höchstens in Stripes bündeln, so dass man immer so viele Blöcke am Stück schreibt, wie zu einer Parität gehören, so dass man die Parität nicht lesen und nur einmal aus allen zusammengehörenden Blöcken neu berechnen muss. Dafür muss aber trotzdem der volle Durchsatz durch die GPU und somit durch das PCIe-Interface gehen. Also weiterhin keine Ahnung, wie da mehr als 30GB/s gehen sollen. Das wäre auch höchstens eine gute Idee, wenn man eine USV hat, weil der Stripe während des Schreibvorgangs in der Luft hängt.

 

[PCGH_Torsten]

So sehe ich das auch. Random steigert zwar der Verwaltungsaufwand immens und eine GPU ist bei sehr vielen, sehr primitiven Aufgaben (wozu auch die Paritätsberechnung selbst zählt) performancetechnisch eigentlich immer im Vorteil. Aber all das zählt eben nur für <30 GB/s Nutzdaten.

Selbst bei den Lesevorgängen würde ich irgendwo ein Transferratenlimit erwarten, auch wenn die eigentlichen Nutzdaten an der Karte vorbeigeschleust werden. Die Peak-Werte entsprechen gerade einmal 1.000 Byte Controller-Daten pro 10-kB-effektiv-IOP und davon dürften allein die Addressen und Byte-Masks für 23 physische Reads 160 bis 200 Byte beanspruchen, ohne die eigentlichen Befehle drum herum. Wie aus den Stripe-Abschnitten dann wieder eine logische Informationseinheit werden soll, ohne entweder den Controller oder die CPU bemühen, kann ich mir überhaupt nicht erklären – aber je einfacher eine "Bauanleitung" zu verarbeiten soll, desto umfangreicher wird sie in der Regel.

 

[empy]

Aber all das zählt eben nur für <30 GB/s Nutzdaten.

Wie gesagt, beim Schreiben muss die dreifache Menge an Daten zum Controller hin, von daher passt das schon ganz gut mit den von LTT ermittelten ~10GB/s zusammen. Weg muss die doppelte Menge, aber da PCIe in beide Richtungen gleichzeitig übertragen kann, sollte das irrelevant sein.

Selbst bei den Lesevorgängen würde ich irgendwo ein Transferratenlimit erwarten, auch wenn die eigentlichen Nutzdaten an der Karte vorbeigeschleust werden. Die Peak-Werte entsprechen gerade einmal 1.000 Byte Controller-Daten pro 10-kB-effektiv-IOP und davon dürften allein die Addressen und Byte-Masks für 23 physische Reads 160 bis 200 Byte beanspruchen, ohne die eigentlichen Befehle drum herum.

Ist halt die Frage, ob beim Lesen überhaupt irgendwas über die GPU läuft. Prinzipiell müssen nur die logischen Adressen vom RAID in physische Adressen auf einem Laufwerk übersetzt werden, was nicht soo aufwendig ist, aber gut, da scheint man sich bei Software-RAID-Management gerne zu verschätzen. Ansonsten werden wohl 48 Bit Adresse plus etwas Overhead pro Lesezugriff auf 512 Byte fällig, d.h. da wäre ein theoretisch maximaler Faktor von ~85 (512/(48/8)) und mit 30GB/s entsprechend bis zu 2,5TB/s möglich, also deutlich mehr, als die Laufwerke gemeinsam schaffen sollten, selbst wenn man einen großzügigen Verlust durch Overhead abzieht.

Wie aus den Stripe-Abschnitten dann wieder eine logische Informationseinheit werden soll, ohne entweder den Controller oder die CPU bemühen, kann ich mir überhaupt nicht erklären – aber je einfacher eine "Bauanleitung" zu verarbeiten soll, desto umfangreicher wird sie in der Regel.

Das dürfte kein Problem sein. Die Daten liegen in Blöcken (in dem Fall Chunks genannt) vor, die man einzeln unabhängig voneinander lesen kann. Es heißt zwar, dass wenn bei einem RAID0 ein Laufwerk ausfällt, alle Daten weg sind, das stimmt aber nicht ganz. Das Dateisystem dürfte zwar hinüber sein und größeren Dateien fehlen halt Teile, aber Dateien, die weniger oder genau groß wie die Chunks sind oder zufällig (durch kleine Größe oder auch Fragmentation, Wahrscheinlichkeit nimmt mit steigender Größe natürlich rasant ab) nur auf noch funktionstüchtigen Laufwerken liegen, sind prinzipiell noch komplett da. In der Praxis dürfte das aber nur ein kleiner Trost sein, schon weil es sicher keinen Spaß macht, das Trümmerfeld zu durchforsten, von daher gilt so ein Ausfall als Komplettverlust.

 

[PCGH_Torsten]

Die Chunks sind aber nicht automatisch mit Dateistrukturen allignend und sie setzen sich nicht selbst zusammen. Hier wurde von einem RAID mit 24 Laufwerken gesprochen, abzüglich Parität hat man also 23 Fragmente einer Datei und bei so vielen Zugriffen (wie gesagt: Erzielter Datendurchsatz durch IOPS ergibt im Durchschnitt 10 Kilobyte pro RAID-Zugriff, also nicht einmal 500 Byte je Laufwerkszugriff) dürften die physischen Reads eine erhebliche Amplification mit sich herumschleppen. Man muss also in den gelesenen Chunks erstmal nach den eigentlich angeforderten Datenfragmenten suchen und immer wieder wird auch mal eine Datei im Ende des einen Chunks beginnen und am Anfang des nächsten enden. Wer macht das, wenn es weder der Controller noch die CPU tut? Wie macht er das, ohne zusätzliche Bandbreite für Infos vom Controller zu benötigen?

Bezüglich Datenmenge beim Schreiben: Bei einem Schreib-Benchmark gehe ich erstmal vom einfachsten Fall, also von einem leeren Ziel aus. Somit müssen keine bestehenden Daten und Paritäten berücksichtigt werden. Da der Controller strengenommen nur alle Daten lesen und nur die Paritätsinformationen schreiben muss, entspricht der maximale Nutzdatenstrom also der realen PCI-E-Leistung nach Overhead-Abzug. Wenn bestehende Blöcke geändert werden müssen, wird die Angelegenheit natürlich komplizierter, aber es wird auch kein sauberer Faktor 3 drei sein. Was immer bei Lesevorgängen Sub-Chunks ausspuckt, könnte (je nach Aufbau des Algorithmus) auch nicht für den betrachteten Paritätsabschnitt relevante Block-Inhalte ausfiltern, bei mehreren Zugriffen in die gleichen Blöcke würden Caches eine große Rolle spielen, bei größeren Zugriffen könnten erneut ganze Blöcke clean überschrieben werden und ein (ach-so-)schlauer Controller schreibt gegebenfalls auch erst in leere Bereiche und konsolidiert die erhaltenswerten Reste in nur teilweise veralteten Blöcken später.

 

[empy]

Die Chunks sind aber nicht automatisch mit Dateistrukturen allignend und sie setzen sich nicht selbst zusammen. Hier wurde von einem RAID mit 24 Laufwerken gesprochen, abzüglich Parität hat man also 23 Fragmente einer Datei

Man hat immer nur Fragmente einer Datei. Hier werden die einzelnen Fragmente nur von mehreren Laufwerken gelesen, wenn die Datei groß genug ist. Man kann aus der logischen Adresse eines Blocks, der Anzahl an Laufwerken, der Block- und Chunkgröße und dem RAID-Level das Laufwerk und die Adresse auf diesem Laufwerk errechnen und greift dann einfach darauf zu. Auf einem normalen Laufwerk stehen einfach alle Blöcke hintereinander, bei einem RAID werden sie verteilt, dennoch ist jeder Block genau so beschaffen, wie beim Einzellaufwerk und das Dateisystem kann darauf genau so aufsetzen und damit genau so umgehen. Das RAID ist vor dem Dateisystem komplett abstrahiert.

Bezüglich Datenmenge beim Schreiben: Bei einem Schreib-Benchmark gehe ich erstmal vom einfachsten Fall, also von einem leeren Ziel aus. Somit müssen keine bestehenden Daten und Paritäten berücksichtigt werden.

Ich glaube nicht, dass das so funktioniert, leere Daten sind auch Daten, das Dateisystem weiß nichts von dem RAID und umgekehrt. Normalerweise ist die erste Amtshandlung eines RAIDs, dass es einen sauberen Zustand herstellt. Verschiedene Operationen aus Basis der Länge eines Schreibbefehls und in Abhängigkeit zum Alignment mit den Stripes gibt es meines Wissens nach nicht, Operationen sollten weiterhin blockweise geschehen.

Da der Controller strengenommen nur alle Daten lesen und nur die Paritätsinformationen schreiben muss, entspricht der maximale Nutzdatenstrom also der realen PCI-E-Leistung nach Overhead-Abzug.

Theoretisch möglich, aber aus den oben genannten Gründen wohl nicht praxistauglich.

Wenn bestehende Blöcke geändert werden müssen, wird die Angelegenheit natürlich komplizierter, aber es wird auch kein sauberer Faktor 3 drei sein. Was immer bei Lesevorgängen Sub-Chunks ausspuckt, könnte (je nach Aufbau des Algorithmus) auch nicht für den betrachteten Paritätsabschnitt relevante Block-Inhalte ausfiltern, bei mehreren Zugriffen in die gleichen Blöcke würden Caches eine große Rolle spielen, bei größeren Zugriffen könnten erneut ganze Blöcke clean überschrieben werden und ein (ach-so-)schlauer Controller schreibt gegebenfalls auch erst in leere Bereiche und konsolidiert die erhaltenswerten Reste in nur teilweise veralteten Blöcken später.

Normalerweise ist es ein Faktor vier. Man benötigt zwei Lese- (alter Blockinhalt und alte Parität) und zwei Schreibzugriffe (neuer Blockinhalt und neue Parität) verteilt auf zwei Laufwerke pro Schreibzugriff auf das RAID. Das wäre durch die Bidirektionalität von PCIe in dem Fall ein Faktor zwei, weil empfangen und senden parallel geschehen kann. Allerdings braucht die GPU im Gegensatz zur CPU zusätzlich noch Datenrate für den neuen Blockinhalt, wodurch sich meiner Meinung nach ein Faktor drei ergibt. Mit Caching ergibt sich im Idealfall ein Szenario, in dem die GPU nur den neuen Blockinhalt empfangen und den zusammen mit der neuen Parität senden muss. In dem Fall könnte man die Nutzdaten parallel noch mal an der GPU vorbei direkt an die Laufwerke übertragen, so dass die nicht von der GPU gesendet werden müssen. Das würde dann wohl ungefähr dem von dir oben beschriebenen Szenario entsprechen: Die GPU empfängt nur die Nutzdaten und sendet nur die Parität und man hätte einen Faktor 1.

 

[PCGH_Torsten]

Bin mit modernen Software-RAIDs nicht vertraut, aber früher/bei Hardware-Lösungen wurde/wird meinem wissen nach die logische Struktur eines Laufwerks nachgebildet. Dass heißt das Dateisystem sieht in dem RAID eine fortlaufende Sturktur kontinuierlicher Blöcke und kann beispielsweise eine Datei, die in Block 5 beginnt und in Block 8 endet, durch einen kontinuierlichen Lesezugriff von 5 bis 8 aufrufen. Aber in der Realität führt hierfür der RAID-Controller mehrere Laufwerkszugriffe durch und lädt zumindest vier einzelne Blöcke von beispielsweise vier unterschiedlichen Laufwerken, die er dann in der korrekten Reihenfolge ausgibt, so als wären sie am Stück gelesen worden.

Bei einem so extremen RAID wie hier hätte ich eine weitere Komplexitätsebene erwarten, habe selbst aber keine Erfahrung: Früher hatte man 500er Sektoren auf den Laufwerken und 4k logische Blöcke, dass heißt selbst bei achtfacher Parallelität konnte ein logischer Block aus ganzen Sektoren zusammengesetzt werden. Aber bei 24 4k-Laufwerken hat man entweder eine viel gröbere Granularität. Da muss man entweder auf 96k logische Blöcke aus Sicht des Dateisystems hoch, wovon ich aber noch nie etwas gehört hätte. Oder aber man hat bei kleineren Zugriffen, wie sie im Beispiel erfolgen, gar keine Parallelität mehr, sondern ein JBOD, dass die Zugriffe gemäß der physischen Blöcke abarbeitet, aber nicht die versprochene Leistung bieten kann. Meine Erwartung war daher, das gerade so ein super-intelligentes System die logischen Blöcke aus Fragmenten der physischen Sektoren zusammensetzt. Ein 48k-Zugriff des Dateisystems auf 12 logische Blöcke bestünde dann beispielsweise aus 24 Laufwerksoperationen, es wird aber jeweils nur die erste Hälfte der 24 gelesenen physischen 4k-Sektoren verwendet. Die hinteren Hälften, die für das Dateisystem erst die folgenden 12 logischen Blöcke bilden würden, müssten vom Controller als Mittelsmann zwischen logischer und physischer Ebene herausgeschnitten werden. ("Physisch" in dem Fall gleichbedeutend mit "auf Laufwerksebene". Dass die Laufwerke ihrerseits die gesamte Struktur nur simulieren und transparent und in Echtzeit zwischen ihrem tatsächlichen physischen Aufbau und dieser eigentlich-auch-nur-logischen Simulation übersetzen, spielt für den Controller ja keine Rolle. Obwohl es in Zeiten von PCI-E-Verschaltungen eigentlich eine coole Idee wäre, beide Ebenen zu verknüpfen und so die ohnehin vorhandene Laufwerkseletronik in einem dezentralen RAID-Controller zu verwandeln, zumindest für 0 und 1.)

 

[empy]

Bin mit modernen Software-RAIDs nicht vertraut, aber früher/bei Hardware-Lösungen wurde/wird meinem wissen nach die logische Struktur eines Laufwerks nachgebildet. Dass heißt das Dateisystem sieht in dem RAID eine fortlaufende Sturktur kontinuierlicher Blöcke und kann beispielsweise eine Datei, die in Block 5 beginnt und in Block 8 endet, durch einen kontinuierlichen Lesezugriff von 5 bis 8 aufrufen. Aber in der Realität führt hierfür der RAID-Controller mehrere Laufwerkszugriffe durch und lädt zumindest vier einzelne Blöcke von beispielsweise vier unterschiedlichen Laufwerken, die er dann in der korrekten Reihenfolge ausgibt, so als wären sie am Stück gelesen worden.

Prinzipiell ist es genau so, nur dass nicht festgelegt ist, dass immer nur ein Block am Stück auf einem Laufwerk liegt, sondern eben eine Reihe Blöcke als Chunk. Das ist wohl einfach Performancetuning und was da die optimale Anzahl ist, hängt von den verwendeten Laufwerken, dem Anwendungsszenario und dem RAID-Level ab. Ich denke mal, man hat Chunks eingeführt, um die Vorteile von sequentiellen Zugriffen bei Festplatten besser nutzen zu können. Ansonsten denke ich, dass Zugriffe auch parallel abgesetzt werden und so auch parallel von den Laufwerken bearbeitet werden können. Ich denke, dass auch NCQ hauptsächlich dazu eingeführt wurde, dass man bei Festplatten nicht mehr auf Programmseite darauf achten muss, dass man Daten in der richtigen Reihenfolge abfragt, weil man sonst den Durchsatz minimiert.

Bei einem so extremen RAID wie hier hätte ich eine weitere Komplexitätsebene erwarten, habe selbst aber keine Erfahrung:

Ich denke RAID ist RAID. Große RAIDs gibt es ja schon länger, die Laufwerke waren halt langsamer, so dass geringere Performanceanforderungen an die Ansteuerung gestellt waren, die Funktionsweise hat sich aber nicht geändert.

Früher hatte man 500er Sektoren auf den Laufwerken und 4k logische Blöcke, dass heißt selbst bei achtfacher Parallelität konnte ein logischer Block aus ganzen Sektoren zusammengesetzt werden.

Es ist wohl so, dass Laufwerke physisch 4K-Blöcke haben, darauf aber 512B-Blöcke emulieren.

Aber bei 24 4k-Laufwerken hat man entweder eine viel gröbere Granularität. Da muss man entweder auf 96k logische Blöcke aus Sicht des Dateisystems hoch, wovon ich aber noch nie etwas gehört hätte. Oder aber man hat bei kleineren Zugriffen, wie sie im Beispiel erfolgen, gar keine Parallelität mehr, sondern ein JBOD, dass die Zugriffe gemäß der physischen Blöcke abarbeitet, aber nicht die versprochene Leistung bieten kann.

Wie gesagt, die Blöcke bleiben gleich groß. Die Granularität ist so, dass beim Lesen einer Datei einfach nur Dateigröße/Chunksize Laufwerke diesen Vorgang bedienen. Wenn eine Datei also komplett innerhalb eines Chunks liegt, hat man tatsächlich keine Parallelität. Bei SSDs empfehlen sich auch kleinere Chunksizes, weil man viel weniger als bei Festplatten einen Trade-Off hat. Bei Festplatten ist die optimale Chunksize genau Dateigröße/Laufwerke, so dass jedes Laufwerk die von ihm zu liefernden Daten sequentiell lesen kann. Wählt man sie kleiner müssen mehrere Suchläufe durchgeführt werden, wählt man sie größer opfert man Parallelität, da sind SSDs flexibler.

Meine Erwartung war daher, das gerade so ein super-intelligentes System die logischen Blöcke aus Fragmenten der physischen Sektoren zusammensetzt. Ein 48k-Zugriff des Dateisystems auf 12 logische Blöcke bestünde dann beispielsweise aus 24 Laufwerksoperationen, es wird aber jeweils nur die erste Hälfte der 24 gelesenen physischen 4k-Sektoren verwendet.

Das klingt erst mal intuitiv sinnvoll, um maximale Parallelität zu erreichen, führt aber zu jeder Menge Overhead. Es ist aber eigentlich gar nicht notwendig so eine feingranulare Parallelität zu erreichen. Der Durchsatz skaliert mit der Dateigröße immer noch sehr schnell auf das Maximum (ich lese im Zusammenhang mit SSDs oft was von einer empfohlenen Chunksize von 64K, bei 24 Laufwerken im RAID5 also ab einer Dateigröße von ~1,5MB), alles andere ist auch schnell übertragen (würde mich nicht wundern, wenn da die Zugriffszeit selbst bei SSDs noch den Löwenanteil der Zeit verschlingt) und so ein System nutzt man vermutlich da, wo schon insgesamt genug Zugriffe zusammenkommen, um die Laufwerke zu beschäftigen.

Obwohl es in Zeiten von PCI-E-Verschaltungen eigentlich eine coole Idee wäre, beide Ebenen zu verknüpfen und so die ohnehin vorhandene Laufwerkseletronik in einem dezentralen RAID-Controller zu verwandeln, zumindest für 0 und 1.)

Naja, gibt ja durchaus Mainboards mit RAID-Funktion, Hardware-RAIDs haben aber nach meinem letzten Stand auch einen entscheidenden Nachteil: Sie sind nicht zwingend frei portierbar. Man braucht also einen zum bisher genutzten Controller kompatiblen Ersatz, um das RAID weiternutzen zu können. Wenn man jetzt viele Maschinen und eine entsprechende Ersatzteilinfrastruktur hat, ist das eine Sache, wenn man aber nur sein Mainboard hat, wäre es blöd, wenn man da drauf achten müsste, wenn man es ersetzen will oder muss.

 

[PCGH_Torsten]

Wenn das RAID deiner Meinung nach erst bei 1.500 kB die volle Leistung ausfahren und unterhalb eins 24tels davon, also unter 64 kB gar nichts davon bringen kann, was sagt das über sensationelle RAID-Performance-Ergebnisse bei Zugriffen von im Schnitt 10 kB? Reine Parallelität auf Zugriffsebene, die ein JBOD genauso schnell abgearbeitet hätte?

Bezüglich meiner low-Level-Spinnerei: Mainboard-Hardware-Assisted-RAIDs machen nichts weiter als die RAID-Organisation auf Firmware- statt Treiber-Ebene durchzuführen, arbeiten aber letztlich wie (alte/primitive) Software-RAIDs. Hat(te) den Vorteil, dass man Betriebssystem-transparent war und somit den RAID-Verbund als Systemlaufwerk nutzen konnte und kein Datenverlust durch Software-Fehler oder -Manipulation möglich ist und den Nachteil, dass die Firmware zum RAID-Setup kompatibel bleiben muss. Wobei ich da Hersteller-intern gute Erfahrungen gemacht habe und schon zweimal mit bestehendem RAID-Verbund das Mainboard gewechselt habe. Beide Male wurden dabei fünf Generationen übersprungen und es gab exakt null Probleme. Ich schlage aber einen noch tiefer gehenden, Mainboard-unabhängigen Ansatz vor, bei dem die NVME-Laufwerke selbst auf PCI-E-Package-Ebene zumindest die Lese-Parallelität organisieren und dabei direkt von logischem RAID- auf internen Flash-Block gehen können. (Schreibend bräuchte es einen korrespondierenden Treiber, der auch Paritätsberechnungen über die CPU laufen lassen könnte.)

 

[empy]

Wenn das RAID deiner Meinung nach erst bei 1.500 kB die volle Leistung ausfahren und unterhalb eins 24tels davon, also unter 64 kB gar nichts davon bringen kann, was sagt das über sensationelle RAID-Performance-Ergebnisse bei Zugriffen von im Schnitt 10 kB? Reine Parallelität auf Zugriffsebene, die ein JBOD genauso schnell abgearbeitet hätte?

Wenn sich die Zugriffe gleichmäßig über alle Laufwerke verteilen, ist ein JBOD sogar schneller, weil keine Parität existiert. Das ist aber typischerweise weniger Wahrscheinlich, schon weil doch recht oft der Fokus auf einzelnen Dateien liegt und Dateisysteme versuchen, die Dateien möglichst am Stück zu halten und so alle Zugriffe auf eine Datei in einem JBOD immer nur von einem Laufwerk bedient werden können. In so einem Szenario gewinnt Striping und mit genug Laufwerken im RAID auch mit Parität.