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.
Aktuelle PCIe-SSDs bieten bereits Datenraten, die die Ansprüche des Durchschnittsnutzers mehr als abdecken. Für manche Anwendungen kann der Datentransfer aber gar nicht schnell genug gehen - und dann müssen Sonderlösungen her. Eine solche gibt es in Form von Supreme RAID, einer RAID-Alternative von Graid Technology, die bisherige Limitierungen der Technik aushebeln soll.
Gewaltige Datenraten
Der grundsätzliche Gedankengang ist dabei derselbe: Es werden mehrere Laufwerke kombiniert und gemeinsam angesteuert. Supreme RAID nutzt dabei aber eine Geforce-GPU für die Steuerung und will so deutlich höhere Datenraten erreichen. Zum Vergleich: Während RAID-Karten maximal vier Laufwerke aufnehmen können, sind mit Supreme RAID bis zu 32 SSDs gleichzeitig möglich.
Die Website Storage Review hat ein ebensolches System aufgebaut und dafür die Graid SR-1010 genutzt. Dahinter steckt eigentlich eine Geforce RTX A2000, die mit der entsprechenden Software betrieben wird. Offenbar kann die Software aber auf nahezu allen Geforce-Karten ausgeführt werden, zumal sie keine hohen Leistungsansprüche stellt.
Zusammen mit der besagten Grafikkarten wurden anschließend 24 SSDs vom Typ Kioxia CM7-R verbaut, die 3.84 TB über ein Gen5-Interface anbinden. In der RAID5-Konfiguration konnte Supreme RAID damit im sequenziellen Lesen stolze 279 GB/s übertragen, und im Schreiben wurden 148 GB/s erreicht. Zum Vergleich: Die besten Konfigurationen auf Basis von Software-RAID, mit dem man so viele Laufwerke ebenso ansteuern kann, kamen nur auf 235 GB/s im Lesen und sogar nur 3,51 GB/s im Schreiben. Zudem liegt die GPU-Lösung auch bei den IOPS deutlich vorne. Schreibend gibt es hier 2,02M IOPS vergleichen mit maximal 205k IOPS, und im Lesen kommt das Gespann auf 28,5M IOPS im Vergleich zu 5,6M IOPS.
Ebenso spannend: PCI Express 5.0: SSD-Controller von Silicon Motion effizienter und schneller als Phisons?
Mit Blick auf Datenraten und Zugriffsgeschwindigkeit kann das System bisherige RAID-Lösungen damit offenbar deutlich übertreffen, indem die GPU statt der CPU genutzt wird. Für private Nutzer sind derartige Konstruktionen aber natürlich kaum relevant, schließlich sind die SSD-Datenraten dort nur selten ein Problem. Für Experimente und Benchmarks wäre eine breitere Verfügbarkeit der Lösung dennoch spannend, zumal offenbar nicht allzu viel GPU-Leistung benötigt wird. Zum Vergleich: Die genutzte RTX A2000 ist etwas langsamer als eine Geforce RTX 3060.
Quelle: Storage Review via Techradar
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.)
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.)