Für alle oben aufgeführten Benchmarks wurden in der Testumgebung die in Tabelle 2 beschriebenen Clients verwendet. Da die Anzahl der für die Tests verfügbaren Compute-Nodes nur 16 betrug, wurden die Threads, wenn eine höhere Anzahl an Threads erforderlich war, gleichmäßig auf die Compute-Nodes verteilt (d. h. 32 Threads = 2 Threads pro Node, 64 Threads = 4 Threads pro Node, 128 Threads = 8 Threads pro Node, 256 Threads = 16 Threads pro Node, 512 Threads = 32 Threads pro Node, 1024 Threads = 64 Threads pro Node). Der Zweck bestand darin, mit der begrenzten Anzahl an verfügbaren Compute-Nodes eine höhere Anzahl gleichzeitiger Clients zu simulieren. Da die Benchmarks eine hohe Anzahl an Threads unterstützen, wurde ein maximaler Wert von 1024 verwendet (für jeden Test festgelegt), während übermäßige Kontextwechsel und andere damit verbundene Nebeneffekte vermieden wurden, um die Performanceergebnisse nicht zu beeinflussen.

Tabelle 2 Client-Testumgebung

Sequenzielle IOzone-Performance n Clients zu n Dateien

Die sequenziellerPerformance bei n Clients zu n Dateien wurde mit der IOzone-Version 3.487 gemessen. Die durchgeführten Tests variierten von einzelnen Threads bis zu 1024 Threads in Schritten von Zweierpotenzen.

Die Caching-Effekte auf den Servern wurden minimiert, indem der GPFS-Seitenpool auf 16 GiB festgelegt und Dateien verwendet wurden, die mehr als doppelt so groß waren. Es ist wichtig zu beachten, dass für GPFS diese Einstellung auf die maximale Speichermenge für das Zwischenspeichern von Daten festgelegt ist, unabhängig von der Menge des installierten und freien RAM. Außerdem ist zu beachten, dass bei früheren Dell EMC HPC-Lösungen die Blockgröße für große sequenzielle Übertragungen 1 MiB betrug, GPFS aber mit 8-MiB-Blöcken formatiert wurde und daher dieser Wert für eine optimale Performance in der Benchmark verwendet wird. Das mag zu groß erscheinen und zu viel Speicherplatz verschwenden, GPFS verwendet jedoch Unterblock-Zuweisung, um diese Situation zu vermeiden. In der aktuellen Konfiguration war jeder Block in 256 Subblöcke mit je 32 KiB unterteilt.

Die folgenden Befehle wurden verwendet, um den Benchmark für Schreib- und Lesevorgänge auszuführen, wobei $Threads die Variable mit der Anzahl der verwendeten Threads (1 bis 1024, in Zweierpotenzen erhöht) und threadlist die Datei war, die jeden Thread einem anderen Node zuwies, wobei das Rundlaufverfahren verwendet wurde, um sie gleichmäßig auf die 16 Compute-Nodes zu verteilen.

Um mögliche Auswirkungen des Daten-Caching durch die Clients zu vermeiden, war die Gesamtdatengröße der Dateien doppelt so groß wie die Gesamtmenge des RAM auf den verwendeten Clients. Das heißt, da jeder Client über 128 GiB RAM verfügt, betrug die Dateigröße für eine Thread-Anzahl von 16 oder mehr 4096 GiB geteilt durch die Anzahl der Threads (die Variable $Size unten wurde verwendet, um diesen Wert zu verwalten). In Fällen mit weniger als 16 Threads (was bedeutet, dass jeder Thread auf einem anderen Client ausgeführt wurde) wurde die Dateigröße auf die doppelte Menge an Speicher pro Client oder 256 GiB festgelegt.

iozone -i0 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist
iozone -i1 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist

Abbildung 2 N zu N Sequenzielle Leistung

Aus den Ergebnissen lässt sich ableiten, dass die Schreibleistung mit der Anzahl der verwendeten Threads steigt und dann ein Plateau bei etwa 64 Threads für Schreibvorgänge und 128 Threads für Lesevorgänge erreicht. Dann steigt auch die Leseleistung schnell mit der Anzahl der Threads an und bleibt stabil, bis die maximale Anzahl von Threads erreicht ist, die IOzone zulässt, und daher ist die sequenzielle Leistung großer Dateien auch für 1.024 gleichzeitige Clients stabil. Die Schreibleistung sinkt bei 1024 Threads um etwa 10 %. Da der Client-Cluster jedoch über weniger als diese Anzahl von Cores verfügt, ist es nicht sicher, ob der Leistungsabfall auf Swapping und ähnlichen Overhead zurückzuführen ist, der bei rotierenden Medien nicht beobachtet wird (da die NVMe-Latenz im Vergleich zu rotierenden Medien sehr niedrig ist), oder ob die RAID 10-Datensynchronisation zu einem Engpass wird. Weitere Clients werden benötigt, um diesen Punkt zu klären. Bei 64 Threads wurde eine Anomalie bei den Lesevorgängen beobachtet, bei denen die Performance nicht mit der für vorherige Datenpunkte beobachteten Geschwindigkeit skaliert wurde und sich dann beim nächsten Datenpunkt auf einen Wert bewegte, der der dauerhaften Leistung sehr nahe kam. Weitere Tests sind erforderlich, um den Grund für eine solche Anomalie zu finden, gehen aber über den Rahmen dieses Blogs hinaus.

Die maximale Leseleistung für Lesevorgänge lag unter der theoretischen Leistung der NVMe-Geräte (~102 GB/s) oder der Leistung von EDR-Links, selbst wenn man davon ausging, dass eine Verbindung hauptsächlich für NVMe-over-Fabric-Datenverkehr verwendet wurde (4x EDR BW ~96 GB/s).
Dies ist jedoch keine Überraschung, da die Hardwarekonfiguration in Bezug auf die NVMe-Geräte und IB-HCAs unter jedem CPU-Sockel nicht ausgeglichen ist. Ein CX6-Adapter befindet sich unter CPU1, während die CPU2 alle NVMe-Geräte und den zweiten CX6-Adapter enthält. Der gesamte Storage-Datenverkehr, der die erste HCA verwendet, muss die UPIs verwenden, um auf die NVMe-Geräte zuzugreifen. Darüber hinaus muss jeder Core in CPU1, der verwendet wird, auf Geräte oder Speicher zugreifen, die CPU2 zugewiesen sind, sodass die Datenlokalität leidet und UPI-Links verwendet werden. Das kann die Reduzierung der maximalen Leistung im Vergleich zur maximalen Leistung der NVMe-Geräte oder der Leitungsgeschwindigkeit für CX6-HCAs erklären. Die Alternative zur Behebung dieser Einschränkung ist eine ausgewogene Hardwarekonfiguration, was bedeutet, dass die Dichte auf die Hälfte reduziert werden muss, indem ein R740 mit vier x16-Steckplätzen und zwei x16-PCIe-Erweiterungen verwendet wird, um NVMe-Geräte gleichmäßig auf zwei CPUs zu verteilen, und eine CX6-HCA unter jeder CPU vorhanden ist.

Sequenzielle IOR-Performance n Clients zu einer Datei

Die sequenzielle Performance bei n Clients zu einer einzigen freigegebenen Datei wurde mit der IOR-Version 3.3.0 gemessen, unterstützt durch OpenMPI v4.0.1, um die Benchmark über die 16 Compute-Nodes auszuführen. Die durchgeführten Tests reichten von einem Thread bis zu 512 Threads, da nicht genügend Kerne für 1024 oder mehr Threads vorhanden waren. In diesen Benchmarktests wurden 8-MiB-Blöcke für eine optimale Performance verwendet. Im vorherigen Abschnitt „Leistungstest“ finden Sie eine ausführlichere Erklärung, warum dies wichtig ist.

Die Auswirkungen des Daten-Caching wurden minimiert, indem der auf 16 GiB einstellbare GPFS-Seitenpool festgelegt wurde und die Gesamtdateigröße doppelt so groß war wie die Gesamtmenge an RAM in den verwendeten Clients. Da jeder Client über 128 GiB RAM verfügt, betrug die Dateigröße für eine Thread-Anzahl von 16 oder mehr 4096 GiB, und ein gleicher Betrag dieser Gesamtzahl wurde durch die Anzahl der Threads geteilt (die Variable $Size unten wurde verwendet, um diesen Wert zu verwalten). In Fällen mit weniger als 16 Threads (was bedeutet, dass jeder Thread auf einem anderen Client ausgeführt wurde) war die Dateigröße doppelt so groß wie die Menge an Speicher pro verwendetem Client multipliziert mit der Anzahl der Threads, oder mit anderen Worten, jeder Thread wurde aufgefordert, 256 GiB zu verwenden.

Die folgenden Befehle wurden verwendet, um den Benchmark für Schreib- und Lesevorgänge auszuführen, wobei $Threads die Variable mit der Anzahl der verwendeten Threads (1 bis 1024, in Zweierpotenzen erhöht) und my_hosts.$Threads die entsprechende Datei war, die jeden Thread einem anderen Node zuwies, wobei das Rundlaufverfahren verwendet wurde, um sie gleichmäßig auf die 16 Compute-Nodes zu verteilen.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b $ G

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b $ G

Abbildung 3: N zu 1 Sequenzielle Leistung

Anhand der Ergebnisse können wir beobachten, dass die Lese- und Schreibleistung unabhängig von der impliziten Notwendigkeit von Sperrmechanismen hoch ist, da alle Threads auf dieselbe Datei zugreifen. Die Performance steigt mit der Anzahl der verwendeten Threads wieder sehr schnell an und erreicht dann ein Plateau, das für die Lese- und Schreibvorgänge bis zur maximalen Anzahl der Threads, die in diesem Test verwendet wurden, relativ stabil bleibt. Beachten Sie, dass die maximale Leseleistung 51,6 GB/s bei 512 Threads betrug, aber das Plateau bei der Leistung bei etwa 64 Threads erreicht wird. Beachten Sie außerdem, dass die maximale Schreibleistung von 34,5 GB/s bei 16 Threads erreicht wurde und ein Plateau erreicht hat, das bis zur maximalen Anzahl der verwendeten Threads beobachtet werden kann.

IOzone-Performance zufälliger kleiner Blöcke n Clients zu n Dateien

Die sequenzielle Performance bei N Clients zu N Dateien wurde mit der IOzone-Version 3.487 gemessen. Die durchgeführten Tests variierten von einzelnen Threads bis zu 1024 Threads in Schritten von Zweierpotenzen.

Die durchgeführten Tests reichten von einzelnen Threads bis zu 512 Threads, da nicht genügend Client-Cores für 1024 Threads vorhanden waren. Jeder Thread verwendete eine andere Datei und die Threads wurden im Rundlaufverfahren den Client-Nodes zugewiesen. In diesen Benchmarktests wurden 4-KiB-Blöcke verwendet, um den Datenverkehr mit kleinen Blöcken zu simulieren, und eine Warteschlangentiefe von 16. Die Ergebnisse der großen Lösung und der Kapazitätserweiterung werden verglichen.

Die Caching-Effekte wurden erneut minimiert, indem der GPFS-Seitenpool auf 16 GiB eingestellt wurde, und um mögliche Daten-Caching-Effekte von den Clients zu vermeiden, betrug die Gesamtdatengröße der Dateien das Doppelte der Gesamtmenge an RAM in den verwendeten Clients. Das heißt, da jeder Client über 128 GiB RAM verfügt, betrug die Dateigröße für eine Thread-Anzahl von 16 oder mehr 4096 GiB geteilt durch die Anzahl der Threads (die Variable $Size unten wurde verwendet, um diesen Wert zu verwalten). In Fällen mit weniger als 16 Threads (was bedeutet, dass jeder Thread auf einem anderen Client ausgeführt wurde) wurde die Dateigröße auf die doppelte Menge an Speicher pro Client oder 256 GiB festgelegt.

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist                                     <= Create the files sequentially
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist                                      <= Zufälliger Lese- und Schreibvorgänge ausführen.

Abbildung 4: N zu N zufällige Performance

Anhand der Ergebnisse können wir feststellen, dass die Schreibleistung bei einem hohen Wert von 6.000 IOps beginnt und stetig bis zu 1024 Threads ansteigt, wobei ein Plateau mit über 5 Mio. IOPS erreicht zu sein scheint, wenn mehr Threads verwendet werden könnten. Die Leseperformance beginnt dagegen bei 5000 IOPS und steigt stetig mit der Anzahl der verwendeten Threads an (denken Sie daran, dass die Anzahl der Threads für jeden Datenpunkt verdoppelt wird) und erreicht eine maximale Performance von 7,3 Mio. IOPS bei 1024 Threads, wobei hier ein Plateau erreicht zu sein scheint. Die Verwendung von mehr Threads erfordert mehr als die 16 Compute-Nodes, um einen Ressourcenmangel und exzessives Swapping zu vermeiden, die zu einer scheinbar geringeren Performance führen können, wobei die NVME-Nodes die Performance aber tatsächlich aufrechterhalten könnten.

Metadaten-Performance mit MDtest mithilfe von 4-KiB-Dateien

Die Metadaten-Performance wurde mit der MDtest-Version 3.3.0 gemessen, unterstützt durch OpenMPI v4.0.1, um die Benchmark über die 16 Compute-Nodes auszuführen. Die ausgeführten Tests reichten von einem einzigen Thread bis zu 512 Threads. Der Benchmark wurde nur für Dateien (keine Verzeichnismetadaten) verwendet, um die Anzahl der Erstellungs-, Statistik-, Lese- und Entfernungsvorgänge zu erhalten, die die Lösung verarbeiten kann, und die Ergebnisse wurden mit der großen Lösung verglichen.

Das optionale High-Demand-Metadatenmodul wurde verwendet, aber bei einem einzelnen ME4024-Array war selbst die große Konfiguration und die in dieser Arbeit getesteten Arrays mit zwei ME4024 ausgestattet. Der Grund für die Verwendung dieses Metadatenmoduls ist, dass diese NVMe-Nodes derzeit nur als Speicherziele für Daten verwendet werden. Die Nodes könnten jedoch zum Speichern von Daten und Metadaten oder sogar als Flash-Alternative für das stark nachgefragte Metadatenmodul verwendet werden, wenn extreme Metadatenanforderungen dies erfordern. Diese Konfigurationen wurden im Rahmen dieser Arbeit nicht getestet.

Da dasselbe High-Demand-Metadatenmodul für früheres Benchmarking der DellEMC Ready Solution for HPC PixStor-Storage-Lösung verwendet wurde, sind die Metadatenergebnisse im Vergleich zu früheren Blogergebnissen sehr ähnlich. Aus diesem Grund wurde die Studie mit leeren Dateien nicht durchgeführt, sondern stattdessen wurden 4 KiB-Dateien verwendet. Da 4-KiB-Dateien nicht zusammen mit den Metadateninformationen in einen Inode passen, werden NVMe-Nodes verwendet, um Daten für jede Datei zu speichern. Aus diesem Grund kann MDtest eine ungefähre Vorstellung von der Leistung kleiner Dateien für Lesevorgänge und den Rest der Metadatenvorgänge vermitteln.

Der folgende Befehl wurde verwendet, um die Benchmark auszuführen, wobei „$Threads“ die Variable mit der Anzahl der verwendeten Threads darstellt (1 bis 512, erhöht in Zweierpotenzen) und my_hosts.$Threads die entsprechende Datei ist, die jeden Thread einem anderen Node zugewiesen hat, wobei das Rundlaufverfahren verwendet wurde, um die Threads gleichmäßig auf die 16 Compute-Nodes zu verteilen. Ähnlich wie bei der Benchmark für die zufälligen I/O war die maximale Anzahl der Threads auf 512 begrenzt, da nicht genügend Cores für 1024 Threads vorhanden waren und sich Kontextwechsel auf die Ergebnisse auswirken würden, sodass eine geringere Performance gemeldet werden würde, als die Lösung tatsächlich bietet.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

Da die Performanceergebnisse von der Gesamtzahl der IOPS, der Anzahl der Dateien pro Verzeichnis und der Anzahl der Threads beeinflusst werden können, wurde beschlossen, die Gesamtanzahl der Dateien auf 2 MiB (2^21 = 2097152) und die Anzahl der Dateien pro Verzeichnis auf 1024 festzulegen, wobei die Anzahl der Verzeichnisse anhand der Anzahl der Threads verändert wurde, wie in Tabelle 3 gezeigt.

Tabelle 3 MDtest-Verteilung von Dateien in Verzeichnissen

Abbildung 5: Metadatenperformance – 4-KiB-Dateien

Beachten Sie zunächst, dass eine logarithmische Skala mit der Basis 10 ausgewählt wurde, um einen Vergleich von Vorgängen zu ermöglichen, die Unterschiede in mehreren Größenordnungen aufweisen. Andernfalls würden einige der Vorgänge in einem linearen Diagramm wie eine flache Linie nahe 0 aussehen. Ein logarithmisches Diagramm mit Basis 2 könnte besser geeignet sein, da die Anzahl der Threads in Potenzen von 2 erhöht ist, aber das Diagramm würde sehr ähnlich aussehen und die Leute neigen dazu, Zahlen besser auf der Grundlage von Potenzen von 10 zu handhaben und sich daran zu erinnern.

Wie bereits berichtet, erzielt das System sehr gute Ergebnisse, wobei die Stat-Vorgänge den Spitzenwert bei 64 Threads mit fast 6,9 Mio. OP/s erreichen und dann durch Reduzierung für höhere Thread-Zahlen ein Plateau erreichen. Erstellungsvorgänge erreichen das Maximum von 113.000 OP/s bei 512 Threads. Es wird also erwartet, dass sie weiter zunehmen werden, wenn mehr Client-Nodes (und Cores) verwendet werden. Lese- und Entfernungsvorgänge erreichten bei 128 Threads ihr Maximum und erreichten ihren Höhepunkt bei fast 705.000 OP/s für Lesevorgänge und 370.000 OP/s für Entfernungsvorgänge, bevor sie ein Plateau erreichten. Statistikvorgänge weisen mehr Schwankungen auf, aber sobald sie ihren Spitzenwert erreicht haben, sinkt die Performance nicht unter 3,2 Mio. Vorgänge pro Sekunde für Stat-Vorgänge. Erstellungs- und Entfernungsvorgänge sind stabiler, sobald sie ihr Plateau erreicht haben, und bleiben bei über 265.000 Vorgängen pro Sekunde für Entfernungen und bei 113.000 Vorgängen pro Sekunde für Erstellungen. Schließlich erreichen Lesevorgänge ein Plateau mit einer Performance von über 265.000 OP/s.

Schlussfolgerungen und zukünftige Arbeiten

Die NVMe-Nodes sind eine wichtige Ergänzung der HPC-Storage-Lösung zur Bereitstellung eines sehr hohen Performance-Tier mit guter Dichte, sehr hoher Performance bei zufälligen Zugriffen und sehr hoher sequenzieller Performance. Darüber hinaus lässt sich Kapazität und Leistung der Lösung linear skalieren, wenn weitere NVMe-Node-Module hinzugefügt werden. Die Performance der NVMe-Nodes ist in Tabelle 4 in der Übersicht dargestellt und wird als stabil erwartet. Diese Werte können verwendet werden, um die Performance für eine andere Anzahl von NVMe-Nodes zu schätzen.
Beachten Sie jedoch, dass jedes NVMe-Node-Paar die Hälfte der in Tabelle 4 gezeigten Anzahl bereitstellt.
Diese Lösung bietet HPC-KundInnen ein äußerst zuverlässiges paralleles Dateisystem, das von vielen Top-500-HPC-Clustern verwendet wird. Darüber hinaus bietet sie außergewöhnliche Suchfunktionen, erweitertes Monitoring und Management und durch das Hinzufügen optionaler Gateways können Dateien über allgegenwärtige Standardprotokolle wie NFS, SMB und andere für so viele Clients wie nötig freigegeben werden.

Tabelle 4: Spitzen- und Dauerleistung für 2 NVMe-Node-Paare

Da NVMe-Nodes nur für Daten verwendet wurden, können sie in Zukunft möglicherweise für Daten und Metadaten verwendet werden und aufgrund der höheren Bandbreite und niedrigeren Latenz von NVMe-Geräten im Vergleich zu SAS3-SSDs hinter RAID-Controllern einen eigenständigen Flash-basierten Tier mit besserer Metadatenperformance aufweisen. Wenn ein Kunde extrem hohe Anforderungen an Metadaten hat und eine Lösung mit höherer Dichte benötigt als das, was das Modul mit hohem Bedarf an Metadaten bereitstellen kann, können einige oder alle verteilten RAID 10-Geräte für Metadaten auf die gleiche Weise verwendet werden, wie es jetzt bei den RAID 1-Geräten auf den ME4024s der Fall ist.
Ein weiterer Blogbeitrag, der demnächst veröffentlicht wird, wird die PixStor Gateway-Nodes beschreiben, die es ermöglichen, die PixStor-Lösung über NFS- oder SMB-Protokolle mit anderen Netzwerken zu verbinden und die Leistung zu skalieren. Außerdem wird die Lösung sehr bald auf HDR100 aktualisiert, und es wird erwartet, dass ein anderer Blogbeitrag über diese Arbeit sprechen wird.