Über unser PMXX-Projekt haben wir schon zweimal berichtet: Nach einem Einführungsartikel sind wir zuletzt genauer auf den Gigabyte-Server eingegangen. Jetzt geht es hinsichtlich der Storage-Architektur des Servers ans Eingemachte: In den vergangenen Wochen testeten wir ausgiebig verschiedene RAID-Level und Optionen mit den Kingston DC3000ME und einer besonderen RAID-Lösung von GRAID Technology. Denn letztlich soll der neue Server hauptsächlich eines machen: die Daten von Hardwareluxx solide und sicher verwahren – und sie schnell bereitstellen.
Bereits eine einzelne NVME-SSD hat heutzutage eine brachiale Leistung. Unser aktuelles Storage-System baut noch auf SATA-SSDs – die mit knapp 550 MB/s Lese- und Schreibrate insbesondere bei kleinen Dateien und Datenbankzugriffen bereits schneller waren als Festplatten. Eine Kingston DC3000ME mit 3,84 TB, wie wir sie einsetzen, kann dank PCIe-5.0-Interface aber mit 14.000 MB/s lesen und 5.800 MB/s schreiben – also mit einer 25-fachen Lese- und immerhin knapp 10-fachen Schreibgeschwindigkeit.
Nun setzen wir im PMXX nicht nur eine DC3000ME ein – sondern füllen den Gigabyte-Server mit seinen 12 Fronteinschüben gleich komplett auf. Wichtig dabei: Gigabytes R284-S93-AAL1 bietet auch tatsächlich genügend PCIe-Lanes für die SSDs. Kingstons U.2-Laufwerke sind mit einer PCIe-Gen5-x4-Schnittstelle ausgestattet, Gigabytes Server liefert tatsächlich über sechs MCIO 8i x8-Stecker insgesamt 12 PCIe-Gen5-x4-Anschlüsse. Insgesamt vier Drives kommunizieren dabei über eine PCIe-5.0-x16-Schnittstelle des CPU0, die restlichen acht Drives sind über zwei PCIe-5.0-x16-Schnittstellen über die CPU1 angebunden.
Kingstons DC3000ME alleine haben schon eine beeindruckende Performance. Das PCIe-Gen5-x4-Laufwerk kann dabei 14.000 MB/s lesend und 5.800 MB/s schreibend liefern – die größeren 7,68-TB- und 15,36-TB-Varianten sind sogar noch schneller. Effektiv handelt es sich um eine für den Server-Betrieb optimierte SSD mit etwas anderer Charakteristik als das, was im Desktop-Bereich als Renegade-SSD zum Einsatz kommt. Sichtbar ist das nicht nur anhand des Vorhandenseins von Power Caps zum Wegschreiben von gecachten Daten bei Stromausfall, sondern auch anhand der großen MTBF und den hohen DWPD-Werten. Kingston garantiert ein einmaliges tägliches (!) komplettes Vollschreiben der SSD über 5 Jahre.
Ganz neu ist das 30,72 TB-Modell der SSD, auf das man im Laufe der fünfjährigen Garantie insgesamt 56.064 TB, also 56 Petabyte, schreiben darf und sich das Laufwerk dann immer noch innerhalb der Spezifikation bewegt.
Die technischen Daten der DC3000ME
DC3000ME Gehäuse U.2, 2,5 Zoll x 15 mm
100,5 x 69,8 x 14,8 mm Interface PCIe NVMe Gen5 x4 Kapazität 3,84 TB, 7,68 TB, 15,36 TB, 30,72 TB NAND-Typ 3D eTLC Sequentielle Lese/Schreibrate 3,84 TB: 14.000 / 5.800 MB/s
7,68 TB: 14.000 / 10.000 MB/s
15,36 TB: 14.000 / 9.700 MB/s
30,72 TB: 14.000 / 9700 MB/s zufälliges Lesen/Schreiben (4K, IOPS) 3,84 TB: 2.700.000 / 300.000
7,68 TB: 2.800.000 / 500.000
15,36 TB: 2.700.000 / 400.000
30,72 TB: 2.700.000 / 400.000 Latenzqualität (QoS) 99 % – Read/Write: <10 µs / < 70 µs Power Loss Protection (Power Caps) Ja Endurance (TBW/DWPD)
3,84 TB: 7.008 TB, 1DWPD (5 Jahre)
7,68 TB: 14.016 TB, 1DWPD (5 Jahre)
15,36 TB: 28.032 TB, 1DWPD (5 Jahre)
30,72 TB: 56.064 TB, 1DWPD (5 Jahre)
MTBF 2 Millionen Stunden Leistungsaufnahme Idle: 8 W (30,72 TB: 9W)
maximal lesend: 8,2 W (30,72 TB: 9,5 W)
maximal schreibend: 24 W Betriebstemperatur 0 bis 70 °C Verschlüsselung TCG Opal 2.0, AES 256 Bit Namespace-Management 128 Namespaces unterstützt Garantie limitierte Herstellergarantie über 5 Jahre GRAID Technology SupremeRAID Core
Nicht nur die Anbindung ist für eine gute Leistung der NVME-SSDs wichtig. Je nach Betriebssystem und Anwendung müssen die Prozessoren normalerweise die Daten entsprechend bereitstellen – und das wird je nach RAID-Einstellung oftmals zum Flaschenhals. Während ein einfaches RAID0 oder RAID1 aus zwei oder vier NVME-Drives noch von einem Software-RAID zu schaffen ist, wird der Management-Overhead bei mehr NVME-Drives oder komplizierteren RAID‑Leveln zum Problem.
Früher setzte man bei SATA-Drives dann auf RAID-Controller, die zum einen auch die Bandbreite und Anschlüsse zur Verfügung stellten, aber insbesondere auch die Paritäts-Informationen berechneten und auf die Drives schrieben. Das hatte zwei Vorteile: Durch die spezialisierten Controller ging die Kalkulation schneller, als auf einer normalen CPU – und die CPUs selber hatten Zeit für andere Aufgaben. Da die RAID-Controller meistens eine eigene Anbindung für die Drives mitbrachten, entfiel auch größtenteils die Notwendigkeit für spezielle Controller und Bandbreite auf den Motherboards.
Mit NVME-Drives ist dies nun etwas anders: Damit diese effizient und schnell arbeiten können, sind sie direkt an die CPU angebunden. Controller, um mehr NVME-Anschlüsse zu bekommen, kämpfen immer mit der Anbindung an die CPU. Aber wie lässt sich ein Software-RAID aus NVMe-Drives jetzt beschleunigen?
Die Antwort kommt von GRAID Technology: Die SupremeRAID-Controller der Firma sind im Endeffekt NVIDIA-Grafikkarten. Man nutzt die professionellen Versionen, also beispielsweise eine NVIDIA RTX A1000, und lagert RAID-Operationen auf diese Karten aus. Dabei werden nicht die kompletten Daten über die GPU geroutet – sondern nur die entsprechenden Rechenoperationen, die notwendig sind, um die Daten zu schreiben und zu lesen. Auch hier entstehen dadurch wieder zwei Effekte: Manche Dinge kann die GPU einfach schneller und paralleler erledigen als die CPU, weshalb z. B. Paritätsberechnungen superschnell auf der GPU ausgeführt werden können. Und natürlich bleibt die CPU auch von der I/O-Last befreit, die Prozessoren können sich also um andere Rechenaufgaben kümmern.
GRAID Technology bietet dabei unterschiedliche Optionen an, wobei für unseren Anwendungsfall eine der kleinsten Lösungen infrage kommt. Wir nutzen SupremeRAID Core, also eine kleine NVIDIA RTX A1000-Lösung mit PCIe-x8-Anbindung, die GRAID Technology für 12 Drives vorsieht. Da zwölf Drives unsere Höchstbestückung sind, ist es für uns wichtiger, möglichst wenig Strom zu verbrauchen, als eine größere Lösung zu nutzen. Die NVIDIA-Karte schlägt am Ende mit einem Verbrauch von knapp 70-80 W zu Buche, insofern sollte man hier nicht zu groß dimensionieren.
Beim Stromverbrauch ist hinzuzufügen, dass der GRAID-Treiber die NVIDIA-Karte in eine Art Bereitschaftsmodus versetzt. Selbst wenn kein Datentransfer stattfindet, zeigt die NVIDIA RTX A1000 100% Last an – der GPU-Treiber reserviert die Performance sofort, wenn eine Drive Group angelegt wurde. Insofern steigt der Verbrauch nicht linear mit der Last auf dem Array an, sondern ist sofort zu 100 % da, wenn die GRAID-Lösung aktiv ist. Der Hintergedanke hinter dieser Implementierung ist, dass der Datentransfer absolute Priorität hat.
Während die GPU von NVIDIA stammt, ist die Leistung von GRAID Technology der entsprechende Treiber dazu. Dieser wird anstelle des üblichen im Betriebssystem integrierten SATA- oder NVME-Driver verwendet. Anschließend wird über eine Weboberfläche oder Shell auf den Treiber zugegriffen – und die verschiedenen RAID-Einstellungen können direkt dort vorgenommen werden. Die Software ermöglicht es, einzelne Drives mit dem GRAID-Technology-Driver anzusprechen, dann in eine Drive-Group zusammenzuführen, und je nach GRAID-Lösung sind dabei dann unterschiedliche RAID-Level auswählbar (z.B. RAID 0,1,5,6 in unserem Fall). Im Anschluss lassen sich virtuelle Drives darauf legen – und dann vom Betriebssystem zugängig machen, als wäre es ein einzelnes Drive.
Der Leistungsvergleich
Wir haben in unserem Leistungsvergleich also im Endeffekt verschiedene Möglichkeiten:
Zunächst einmal können wir die in den meisten Betriebssystemen verwendete Software-RAID-Lösung mit der GRAID Technology SupremeRAID Core-Lösung vergleichen. Weiterhin bietet sich uns aber auch die Möglichkeit, etwas mit der Anzahl der Drives und der verwendeten RAID-Lösung zu spielen. Nun wird niemand bei einem Server zwölf Laufwerke in einem RAID0 kombinieren – testweise können wir dies hier natürlich machen.
Interessant sollte aber vorwiegend der Vergleich mit RAID5 oder RAID6 werden, weil hier die CPU die Paritäten berechnen muss – und gerade hier die GRAID-Technology-Lösung im Vorteil sein sollte. Mit zwölf Drives wäre theoretisch ein RAID6 möglich, das die Kapazität von zehn Drives mitbringt (in unserem Fall 10x 3,84 TB), und zwei Drives für die Parität nutzt. Im finalen Einsatz könnte man für zukünftige Ausfallsicherheit auch noch an ein bis zwei Drives in einem Hot-Spare-Betrieb denken.
Entscheidend sind am Ende aber nicht nur die reinen übertragenen GB/s, sondern auch Dinge wie die erreichten IOPS und die Latenz, mit der auf das Array zugegriffen werden kann. Für unsere Anwendungszwecke sind die letztgenannten Werte sogar wichtiger, weil wir keine großen Datenmengen bewegen, sondern schnellen Zugriff auf unsere Datenbanken ermöglichen wollen.
Die Benchmarks haben wir zunächst – auch zur Visualisierung – unter Windows Server 2025 erstellt. Dabei sind zwei Dinge zu beachten: Der neue GRAID-Technology-Treiber in der Version 2.x für Linux hat bereits eine höhere Performance, als der Windows-Treiber. Und weiterhin sind auch bei Windows einige Performance-Limitierungen festzustellen, weshalb wir unten auch noch weitere Benchmarks in der finalen Variante unter Linux hinzugezogen haben.
Sequenzielle Read Performance SEQ1M Q8T64 – in MB/s
MB/s
mehr ist besser
In unserem ersten Leistungsvergleich geht es um die reinen Übertagungsraten. Wir haben Konfigurationen mit 12, 4 und einem einzelnen Drive durch die Benchmarks geschickt, dabei mit RAID0, RAID5 und RAID6, jeweils im Software-RAID und als GRAID-Technologys-Setup.
Zwei Besonderheiten können wir hier schon sehen: Selbst beim Lesen gibt es große Performanceunterschiede, wobei diese mit bis zu vier Drives noch nicht sehr auffällig sind. Sowohl die GRAID-Lösung wie auch das Software-RAID liegen hier mit vier Drives noch nahe zusammen.
Dies ändert sich aber mit 12 Drives: Hier scheint es bereits einen Overhead beim Software-RAID zu geben, der so groß ist, dass wir mit zwölf Kingston DC3000ME nur knapp über 60.000 MB/s Leserate erreichen. Interessant ist dabei, dass es quasi keinen Unterscheid zwischen RAID5 und RAID0 gibt. Erst die GRAID-Lösung schaltet den Turbo frei, selbst im RAID6 erreichen wir fast die 100 GB/s. Der Rekord liegt beim Betrieb im RAID0 mit knapp über 113 GB/s Bandbreite im sequenziellen Lesen.
Sequenzielle Write Performance SEQ1M Q8T64 – in MB/s
MB/s
mehr ist besser
Beim sequenziellen Schreiben liegen die zwölf Kingston-Drives im RAID0 bei der GRAID-Lösung bei knapp 60 GB/s – das Software-RAID ist nur unwesentlich langsamer. Auch die RAID0-Lösung aus vier Laufwerken ist hier schnell unterwegs – die RAID5 und RAID6-Lösungen fallen dann allerdings aufgrund der notwendigen Paritätsberechnungen erwartungsgemäß ab.
GRAID Technology kann hier aber mit zwölf Drives eine mehr als doppelt so hohe Leistung erzielen als die Software-Lösung. Auch der Leistungsunterschied zwischen RAID5 und RAID6 ist bei 12 Drives nicht wirklich messbar. Bei vier SSDs stehen dann allerdings zu wenige Laufwerke zur Verfügung, um noch gute Performance zu erreichen. Wer ein RAID6 verwenden will, sollte also an eine möglichst hohe Anzahl von Laufwerken denken.
RND4K Write Latenzin µs
µs
mehr ist besser
Bevor wir auf die IOPS und andere Werte eingehen, macht es Sinn, auf den obigen Latenz-Benchmark einzugehen. Hier zeigen wir die Write-Zugriffe für Random 4k. Während die Werte bei GRAID im Bereich weniger µs liegen, egal welchen RAID-Level man verwendet, liegt das Software-RAID nur im Einzelbetrieb oder im RAID0 in einem akzeptablen Bereich. Mit RAID5 steigt die Latenz – weil die Parität entsprechend berechnet werden muss. Das kann die NVIDIA-GPU in Windeseile – weshalb die GRAID-Lösung genau dann im Vorteil sein sollte, wenn viele kleine Dateien geschrieben werden müssen – auf ein Array, das entsprechend ein RAID5 oder RAID6 ist.
Interessant: Beim Lesen zeigt sich dieser Faktor übrigens nicht, hier ist die Software-Version schneller. Anzunehmen ist, dass der Driver-Stack des Betriebssystems hier einfach effizienter arbeitet als der GRAID-Technology-Driver, der ja als Extra-Treiber noch ein wenig Latenz mit sich bringt.
RND4K Write Performance(in IOPS)
IOPS
mehr ist besser
Die Latenz wirkt sich dann natürlich auch massiv auf die möglichen IOPS aus – und je nach Lese- oder Schreibzugriffe unterschiedlich stark auf die Unterschiede zwischen GRAID-Lösung und Software-RAID. Beim Random-4K-Write-Benchmark mit Queue Depth von 32 (viel Multitasking) und 64 Threads (hohe Parallelität) ist dies hervorragend zu sehen: Während die GRAID-Benchmarks alle recht nahe zusammenliegen und selbst RAID6-Lösungen nicht abfallen, bricht die Performance im Software-RAID5 massiv ein. Die CPU kommt hier bei den Berechnungen nicht mehr hinterher.
RND4K Read Performance(RND4K Q1T64 in MB/s)
MB/s
mehr ist besser
Umgekehrt gibt es aber natürlich auch Benchmarkbereiche, wo man das Software-RAID besser aussehen lassen kann als die GRAID-Lösung: Im Lesen von Random-4K-Werten mit nur einem Auftrag nach dem anderen (T1) kann die GRAID-Lösung ihre Trümpfe nicht ausspielen und würde somit langsamer sein als eine Software-Lösung. Im Server-Umfeld existiert dieser Fall aber nicht und wäre eher etwas für den Heimarbeits-/Desktopbereich.
Finales Setup unter Proxmox 9.1
Nach diesen eher theoretischen Benchmarks haben wir uns an die Planung gemacht, wie für uns das Setup ideal aussehen könnte. Neben reinen Performanceargumenten gibt es dabei auch andere Dinge zu betrachten:
Über allem steht ohne Frage die Datensicherheit. Wenn wir Hardwareluxx auf ein Array packen, dann soll die zugrunde liegende Storage-Umgebung auch im Worst Case noch funktionieren. Zwar gibt es immer Backups, aber eine Downtime von mehreren Stunden kostet Geld, und eine Menge Admin-Nerven. Insofern scheiden für uns natürlich Dinge wie RAID0 aus. Aufgrund der doch recht geringen Performanceunterschiede bei RAID5 und RAID6 für ein Array auf der GRAID-Lösung haben wir uns für RAID6 entschieden.
Auch hier macht es aber Sinn, nicht den kompletten Storage-Platz des Servers unter ein großes GRAID-Volume zu packen. Unsere Proxmoxx-Umgebung liegt zwar auf zwei separaten, internen Kingston-NVME-Drives (ZFS RAID1), aber auch für einige Daten bietet es sich an, sie nicht nur auf dem GRAID-Volume liegen zu haben. Der Grund: Wenn die NVIDIA GPU ausfällt, muss eine neue Grafikkarte als Ersatz eingebaut werden, und anschließend benötigt man von GRAID Technology eine neue Lizenznummer für den Treiber. Jeder Treiber ist auf die Seriennummer der GPU abgestimmt, entsprechend kann es etwas dauern, bis nach einem GPU-Tausch wieder auf die Daten zugegriffen werden können.
Wir haben uns also für folgendes Setup entschieden:
8x Kingston DC3000ME (Drives 4-11, angebunden an CPU1) über GRAID Technology SupremeRAID als RAID62x Kingston DC3000ME (Drives 0,1, angebunden an CPU0) über Software RAID als RAID12x Kingston DC3000ME als Hot Spare Drives (Drives 2,3)
In dieser Konfiguration erreichen wir auch für das RAID6 die höchste Performance, da sich die CPUs nicht untereinander stören und sich nicht untereinander über den UPI-Link austauschen müssen.
Die folgenden letzten Benchmarks stammen deshalb vom Produktivsystem mit Proxmox VE 9.1 und dem GRAID Technology 2.0.0 Update 93.
Read/Write-Performance Proxmox 9.1(1M QD64T32) in GB/s
GB/s
mehr ist besser
Read/Write-Performance Proxmox 9.1(4K QD64T32 in IOPS)
IOPS
mehr ist besser
Interessant: Die Performance erscheint hier noch einmal höher als beim vorangegangenen Windows-Test, zum einen sicherlich durch den schnelleren GRAID-Treiber, aber auch durch weniger Betriebssystem-Overhead. Mit 80,2 GB/s beim sequenziellen Lesen und 26,6 GB/s beim sequenziellen Schreiben sollten uns keine Performanceengpässe erwarten, ebenso sind die erreichten IOPS beeindruckend.
Fazit
Eine beeindruckende Performance, die das Gespann aus den zwölf Kingston DC3000ME und dem GRAID Technology SupremeRAID Core liefert. Wie immer ist es aber sinnvoll, die Ergebnisse etwas differenzierter zu betrachten.
Die GRAID-Technology-Lösung dominiert insbesondere bei Writes und unter Dauerlast. Die Latenzen bleiben niedrig und stabil, auch bei einem RAID5 und RAID6, aus diesem Grund sind die Random Write IOPS um Größenordnungen höher als bei einer Softwarelösung. Auch die Sequential Writes sind auf hervorragendem Niveau. Ein GRAID Technology SupremeRAID ist also ganz klar dann eine gute Wahl, wenn man den Server für write-intensive, latenzkritische Workloads optimiert.
Ein Software-RAID ist hingegen stark bei Reads. Bei Writes – gerade bei RAID5 – limitiert die CPU, dadurch ergeben sich nur niedrige IOPS und hohe Latenzen. Bei Sequential Reads hingegen, lese-intensiven Workloads oder niedrigen Queue-Tiefen (Q1T1), also eher in Desktop-Umgebung, ist ein Software-RAID durchaus in Ordnung und performant.
In vielen Benchmarks ist zudem auch zu sehen, dass selbst ein einzelnes NVME-Laufwerk oftmals erstaunlich effizient ist und eine ausreichende Leistung bieten wird. Gerade bei Anwendungsfällen, die in die Richtung Desktop gehen, kann ein einzelnes, schnelles NVME-Laufwerk wie in unserem Fall die DC3000ME besser sein als ein komplexes RAID-Setup – und das ohne die Kosten zu betrachten.
In unserem Fall ist der Anwendungszweck Datenbanken und Virtualisierung von mehreren Systemen, also werden wir am Ende viele parallele und kleine Zugriffe auf unser Storage-Subsystem haben. Insofern profitieren wir eher von einer GRAID-Lösung. Allerdings muss man dabei auch festhalten, dass unser bisheriger Server eben noch nicht mit schnellem NVME-Storage wie einer Kingston DC3000ME lief – so haben wir wohl Leistungsreserven, die weit über das Maß hinausgehen, das wir geplant haben.
Für den Desktop-Bereich ist die GRAID-Lösung eher nicht interessant. Wer seinen Desktop-PC zum Fliegen bringen will, setzt lieber auf eine einzelne NVME-SSD oder bastelt sich ein kleines Software-RAID aus zweien.
GRAID Technology SupremeRaid Core
Pro Extreme Performance bei WritesNiedrige Latenz/hohe IOPSHohe Performance selbst bei RAID5/6Offload der RAID-Berechnungen von den CPUs zur NVIDIA GPU Kontra Zusätzlicher Stromverbrauch durch NVIDIA-GPULizenz ist an GPU gebunden, bei GPU-Ausfall kann nicht auf Daten zugegriffen werden