Dell EMC Ready-Lösung für HPC-PixStor-Speicher: Kapazitätserweiterung

Keine

Inhaltsverzeichnis

1. Einführung
   1. Lösungsarchitektur
   2. Lösungskomponenten
2. Performance-Charakterisierung
   1. Sequenzielle IOzone Performance N Clients zu N-Dateien
   2. Sequenzielle iOR-Performance N-Clients in einer Datei
   3. Zufällige kleine Blöcke IOzone Performance N Clients zu N-Dateien
   4. Metadatenperformance mit MDtest mit leeren Dateien
   5. Metadatenperformance mit MDtest mit 4 KiB-Dateien
3. Schlussfolgerungen und zukünftige Arbeiten

 

---

Einführung

Heutige HPC-Umgebungen haben die Anforderungen an sehr schnellen Speicher erhöht, der auch häufig eine hohe Kapazität und verteilten Zugriff über mehrere Standardprotokolle wie NFS, SMB und andere erfordert. Diese anspruchsvollen HPC-Anforderungen werden in der Regel von parallelen Dateisystemen abgedeckt, die gleichzeitigen Zugriff auf eine einzelne Datei oder einen Satz von Dateien von mehreren Nodes bieten, sehr effizient und sicher Daten auf mehrere LUNs über mehrere Server verteilen.

 

---

Lösungsarchitektur

Dieser Blog ist eine Fortsetzung der Parallel File System (PFS)-Lösung für HPC-Umgebungen, die DellEMC Ready Solution for HPC PixStor Storage, bei der PowerVault ME484 EBOD-Arrays verwendet werden, um die Kapazität der Lösung zu erhöhen. Abbildung 1 stellt die Referenzarchitektur dar, die die Sas-Erweiterungs-SAS-Erweiterungen der vorhandenen PowerVault ME4084-Speicherarrays darstellt.
Die PixStor-Lösung umfasst neben vielen anderen Arcastream-Softwarekomponenten wie erweiterten Analysen, vereinfachter Verwaltung und Überwachung, effizienter Dateisuche, erweiterten Gatewayfunktionen und vielen anderen das weit verbreitete allgemeine parallele Dateisystem, auch spectrum Scale als PFS-Komponente bezeichnet.


Abbildung 1: Referenzarchitektur.

 

---

Lösungskomponenten

Diese Lösung wird voraussichtlich mit den neuesten skalierbaren Intel Xeon Xeon CPUs der 2. Generation, auch Cascade Lake-CPUs bezeichnet, veröffentlicht und einige der Server verwenden den schnellsten verfügbaren RAM (2933 MT/s). Aufgrund der aktuellen Hardware, die für die Arbeit am Prototypen der Lösung zur Charakterisierung der Leistung verfügbar ist, sind Server mit skalierbaren Intel Xeon CPUs der 1. Generation auch als "K.a." bezeichnet. Skylake-Prozessoren und in einigen Fällen langsamerer RAM wurden verwendet, um dieses System zu charakterisieren. Da der Engpass der Lösung auf den SAS-Controllern der Dell EMC PowerVault ME40x4-Arrays liegt, wird keine erhebliche Leistungsabweichung erwartet, sobald die Skylake-CPUs und der RAM durch die vorgesehenen Cascade Lake-CPUs und schnelleren RAM ersetzt werden. Darüber hinaus wurde die Lösung auf die neueste Version von PixStor (5.1.1.4) aktualisiert, die RHEL 7.7 und OFED 4.7 für die Charakterisierung des Systems unterstützt.

Aufgrund der zuvor beschriebenen Situation enthält Tabelle 1 die Liste der Hauptkomponenten für die Lösung, aber wenn Abweichungen eingeführt wurden, enthält die erste Beschreibungsspalte Komponenten, die zum Zeitpunkt der Veröffentlichung verwendet werden und daher für Kunden verfügbar sind, und die letzte Spalte sind die Komponenten, die tatsächlich für die Beschreibung der Performance der Lösung verwendet werden. Die Laufwerke, die für Daten (12-TB-NLS) und Metadaten (960-Gbit-SSD) aufgeführt sind, werden für die Performance-Charakterisierung verwendet. Schnellere Laufwerke können bessere zufällige IOPS bereitstellen und die Erstellung/Entfernung von Metadaten verbessern.

Zur Vollständigkeit wurde schließlich die Liste der möglichen Daten-HDDs und Metadaten-SSDs aufgenommen, die auf den unterstützten Laufwerken basiert, die in der DellEMC PowerVault ME4-Supportmatrix aufgeführt sind, die online verfügbar ist.

Tabelle 1 Komponenten, die zum Zeitpunkt der Veröffentlichung verwendet werden, und komponenten, die in der Testumgebung verwendet werden

Lösungskomponente		Bei Der Veröffentlichung	Testumgebung
Interne Konnektivität		Dell Networking S3048-ON Gigabit-Ethernet
Datenspeichersubsystem		1 x bis 4 x Dell EMC PowerVault ME4084 1 x bis 4 x Dell EMC PowerVault ME484 (eine pro ME4084) 80– 3,5"-NL-SAS3-FESTPLATTENlaufwerke mit 12 TB und 900 GB @15K, 1,2 TB @10K, 1,8 TB @10K, 2,4 TB @10K, 4 TB NLS, 8 TB NLS, 10 TB NLS, 12 TB NLS.     8 LUNs, linear 8+2 RAID 6, Blockgröße 512 KiB. 4 SAS3-SSDs mit 1,92 TB für Metadaten – 2 x RAID 1 (oder 4 globale HDD-Ersatzlaufwerke, wenn optionales High Demand Metadata Module verwendet wird)
Optionales High-Demand-Metadatenspeichersubsystem		1 x bis 2 x Dell EMC PowerVault ME4024 (4 x ME4024 bei Bedarf, nur große Konfiguration) 24 2,5"-960-GB-SSD-SAS3-Laufwerke (Optionen 480 GB, 960 GB, 1,92 TB) 12 LUNs, lineares RAID 1.
RAID-Speicher-Controller		12-Gbit/s-SAS
Kapazität wie konfiguriert		Raw: 8064 TB (7334 TiB oder 7,16 PiB) formatiert ~ 6144 GB (5588 TiB oder 5,46 PiB)
Prozessor	Gateway	2 x Intel Xeon Gold 6230 2.1G, 20C/40T, 10.4GT/s, 27.5M Cache, Turbo, HT (125 W) DDR4-2933	N. z.
	Metadaten mit hoher Nachfrage		2 x Intel Xeon Gold 6136 bei 3,0 GHz, 12 Cores
	Speicher-Node		2 x Intel Xeon Gold 6136 bei 3,0 GHz, 12 Cores
	Management-Node	2 x Intel Xeon Gold 5220 2,2 G, 18 Cores/36 T, 10,4 GT/s, 24,75 MB Cache, Turbo, HT (125 W) DDR4-2666	2 x Intel Xeon Gold 5118 bei 2,30 GHz, 12 Cores
Arbeitsspeicher	Gateway	12 RDIMMs mit 16 GiB und 2.933 MT/s (192 GiB)	N. z.
	Metadaten mit hoher Nachfrage		24 RDIMMs mit 16 GiB und 2.666 MT/s (384 GiB)
	Speicher-Node		24 RDIMMs mit 16 GiB und 2.666 MT/s (384 GiB)
	Management-Node	12 x 16-GB-DIMMs, 2.666 MT/s (192 GiB)	12 RDIMMs mit 8 GiB und 2.666 MT/s (96 GiB)
Betriebssystem		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
Kernel-Version		3.10.0-957.12.2.el7.x86_64	3.10.0-1062.9.1.el7.x86_64
PixStor-Software		5.1.0.0	5.1.1.4
Spectrum Scale (GPFS)		5.0.3	5.0.4-2
Leistungsfähige Netzwerkkonnektivität		Mellanox ConnectX-5 Dual-Port InfiniBand EDR/100 GbE und 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
Hochleistungs-Switch		2 x Mellanox SB7800 (HA – redundant)	1 x Mellanox SB7700
OFED-Version		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
Lokale Festplatten (BS und Analyse/Überwachung)		Alle Server außer Management-Node 3 x 480-GB-SSD SAS3 (RAID1 + HS) für Betriebssystem PERC H730P RAID-Controller Management-Node 3 x 480-GB-SSD SAS3 (RAID1 + HS) für Betriebssystem PERC H740P RAID-Controller	Alle Server außer Management-Node 2 x 300 GB 15.000 SAS3 (RAID 1) für BS PERC H330 RAID-Controller Management-Node 5 x 300 GB 15.000 SAS3 (RAID 5) für Betriebssystem und Analyse/Überwachung PERC H740P RAID-Controller
Systemverwaltung		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

Performance-Charakterisierung

Um diese neue Ready Solution zu charakterisieren, haben wir die in der letzten Spalte von Tabelle 1 angegebene Hardware verwendet, einschließlich des optionalen High Demand Metadata Module. Zur Bewertung der Lösungsperformance wurden die folgenden Benchmarks verwendet:

• IOzone N zu N sequenziell
• IOR N zu 1 sequenziell
• IOzone zufällig
• MDtest

 Für alle oben aufgeführten Benchmarks verfügte die Testumgebung über die Clients, wie in Tabelle 2 unten beschrieben. Da die Anzahl der für tests verfügbaren Rechner-Nodes nur 16 betrug, wenn eine höhere Anzahl von Threads erforderlich war, waren diese Threads 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). Die Absicht bestand darin, eine höhere Anzahl gleichzeitiger Clients mit der begrenzten Anzahl von Rechner-Nodes zu simulieren. Da die Benchmarks eine hohe Anzahl von Threads unterstützen, wurde ein maximaler Wert von bis zu 1024 verwendet (für jeden Test angegeben), während übermäßiges Kontextwechsel und andere damit verbundene Nebeneffekte vermieden wurden, die sich auf die Performanceergebnisse auswirken.

Tabelle 2: Client-Testumgebung

Anzahl der Client-Nodes	16
Client-Node	C6320
Prozessoren pro Client-Node	2 x Intel(R) Xeon(R) Gold E5-2697v4, 18 Cores bei 2,30 GHz
Arbeitsspeicher pro Client-Node	12 RDIMMs mit 16 GiB und 2.400 MT/s
BIOS	2.8.0
Betriebssystem-Kernel	3.10.0-957.10.1
GPFS-Version	5.0.3

 

---

Sequenzielle IOzone Performance N Clients zu N-Dateien

Die Performance sequenzieller N-Clients zu N-Dateien wurde mit IOzone-Version 3.487 gemessen. Die ausgeführten Tests reichten von Single-Thread-Threads bis zu 1024 Threads und die Ergebnisse der kapazitätserweiterungsfähigen Lösung (4 x ME4084s + 4x ME484s) stehen im Gegensatz zur großformatigen Lösung (4 x ME4084s). Caching-Effekte wurden minimiert, indem der GPFS-Seitenpool auf 16 GiB eingestellt und Dateien verwendet wurden, die doppelt so groß sind. Es ist wichtig zu beachten, dass für GPFS, das getunt werden kann, die maximale Speichermenge für das Zwischenspeichern von Daten festlegt, unabhängig von der Menge des installierten und freien RAM. Außerdem ist zu beachten, dass in früheren Dell EMC HPC-Lösungen die Blockgröße für große sequenzielle Übertragungen 1 MiB beträgt, GPFS mit 8 MiB-Blöcken formatiert wurde und daher dieser Wert für eine optimale Performance auf dem Benchmark verwendet wird. Das mag zu groß aussehen und zu viel Speicherplatz verschwenden, aber GPFS verwendet Subblock-Zuweisung, um diese Situation zu verhindern. In der aktuellen Konfiguration wurde jeder Block in 256 Subblocks mit jeweils 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 war (1 bis 1024 erhöht in Zweierleistung) und threadlist die Datei war, die jeden Thread auf einem anderen Node zugewiesen hat, wobei Round Robin verwendet wurde, um sie homogen auf die 16 Compute-Nodes zu verteilen.

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

Abbildung 2:  N bis N Sequenzielle Leistung


Anhand der Ergebnisse können wir beobachten, dass die Performance mit der Anzahl der verwendeten Clients sehr schnell ansteigt und dann eine stabile Platte erreicht, bis die maximale Anzahl der Threads erreicht ist, die IOzone zulässt, und daher ist die sequenzielle Leistung großer Dateien selbst für 1024 gleichzeitige Clients stabil. Beachten Sie, dass die Lese- und Schreibleistung von der Verdopplung der Anzahl der Laufwerke profitierte. Die maximale Leseleistung wurde durch die Bandbreite der beiden IB-EDR-Links begrenzt, die auf den Speicher-Nodes ab 8 Threads verwendet werden, und ME4-Arrays verfügen möglicherweise über eine zusätzliche Leistung. Beachten Sie auch, dass die maximale Schreibleistung von maximal 16,7 auf 20,4 Gbit/s bei 64 und 128 Threads gestiegen ist und näher an den maximalen Spezifikationen der ME4-Arrays liegt (22 GB/s).

Hier ist es wichtig, daran zu denken, dass der bevorzugte GPFS-Betriebsmodus verstreut ist und die Lösung für die Verwendung dieses Modus formatiert wurde. In diesem Modus werden Blöcke von Anfang an auf pseudo-zufällige Weise zugewiesen, wodurch Daten auf die gesamte Oberfläche jeder HDD verteilt werden. Der offensichtliche Nachteil liegt in einer kleineren anfänglichen maximalen Performance, diese Performance bleibt jedoch relativ konstant, unabhängig davon, wie viel Speicherplatz auf dem Dateisystem verwendet wird. Im Gegensatz zu anderen parallelen Dateisystemen, die anfänglich die äußeren Tracks verwenden, die mehr Daten (Sektoren) pro Laufwerksrevolution enthalten können und daher die höchstmögliche Leistung bieten, die die HDDs bieten können, aber da das System mehr Speicherplatz verwendet, werden innere Tracks mit weniger Daten pro Revolution verwendet, mit der daraus resultierenden Leistungsreduzierung.

 

---

Sequenzielle iOR-Performance N-Clients in einer Datei

Die Performance sequenzieller N-Clients zu einer einzigen gemeinsam genutzten Datei wurde mit IOR-Version 3.3.0 gemessen, unterstützt durch OpenMPI v4.0.1, um den Benchmark über die 16 Compute-Nodes auszuführen. Die ausgeführten Tests reichten von einem Thread bis zu 512 Threads (da nicht genügend Cores für 1024 Threads vorhanden waren) und die Ergebnisse werden der Lösung ohne Kapazitätserweiterung gegenübergesetzt.
Caching-Effekte wurden minimiert, indem der GPFS-Seitenpool auf 16 GiB eingestellt und Dateien verwendet wurden, die doppelt so groß sind. In diesen Benchmarktests wurden 8 MiB-Blöcke für eine optimale Performance verwendet. Im vorherigen Abschnitt "Performancetest" finden Sie eine umfassendere Erklärung zu diesen Wichtigen.

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 war (1 bis 1024 erhöht in Zweierleistung) und my_hosts.$Threads die entsprechende Datei ist, die jeden Thread auf einem anderen Node zugewiesen hat, wobei Round Robin verwendet wurde, um sie homogen 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 128G 

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 128G

Abbildung 3: N bis 1 Sequenzielle Leistung

Aus den Ergebnissen können wir erneut beobachten, dass die zusätzlichen Laufwerke von der Lese- und Schreibleistung profitieren. Die Performance steigt mit der Anzahl der verwendeten Clients wieder sehr schnell an und erreicht dann eine Platte, die für Lese- und Schreibvorgänge bis hin zur maximalen Anzahl von Threads, die in diesem Test verwendet werden, relativ stabil ist. Beachten Sie, dass die maximale Leseleistung 24,8 Gbit/s bei 16 Threads betrug und der Engpass die InfiniBand EDR-Schnittstelle war, wobei für ME4-Arrays immer noch eine zusätzliche Leistung verfügbar war. Ab diesem Zeitpunkt verringerte sich die Leseleistung von diesem Wert bis zum Erreichen des Ports bei etwa 23,8 GB/s. Beachten Sie auf ähnliche Weise, dass die maximale Schreibleistung von 19,3 bei 8 Threads erreicht wurde und eine Platte erreicht wurde.
 

---

Zufällige kleine Blöcke IOzone Performance N Clients zu N-Dateien

Die Performance zufälliger N-Clients zu N-Dateien wurde mit FIO-Version 3.7 anstelle der herkömmlichen Iozone gemessen. Die im vorherigen Blog aufgeführte Absicht bestand darin, die Vorteile einer größeren Warteschlangentiefe zu nutzen, um die maximal mögliche Leistung zu untersuchen, die ME4084-Arrays liefern können (frühere Tests für verschiedene ME4-Lösungen zeigten, dass die ME4084-Arrays mehr E/A-Druck benötigen, den iozone bereitstellen kann, um ihre zufälligen I/O-Grenzwerte zu erreichen).

Die ausgeführten Tests reichten von einem einzigen Thread bis zu 512 Threads, da nicht genügend Client-Cores für 1024 Threads vorhanden waren. Jeder Thread verwendet eine andere Datei und den Threads wurde Round Robin auf den Client-Nodes zugewiesen. In diesen Benchmarktests wurden 4 KiB-Blöcke verwendet, um Datenverkehr mit kleinen Blöcken zu simulieren und eine Warteschlangentiefe von 16 zu verwenden. Die Ergebnisse der Großlösung und der Kapazitätserweiterung werden verglichen.

Caching-Effekte wurden erneut minimiert, indem der GPFS-Seitenpool auf 16 GiB eingestellt und Dateien doppelt so groß verwendet wurden. Der erste Abschnitt "Performancetest" enthält eine umfassendere Erklärung dazu, warum dies auf GPFS wirksam ist.

 
Abbildung 4:  N bis N Zufällige Performance

Aus den Ergebnissen können wir beobachten, dass die Schreibleistung mit einem hohen Wert von 29,1.100 IOps beginnt und stetig auf bis zu 64 Threads ansteigt, wobei es scheint, dass sie einen Schwellenwert von etwa 40.000 IOps erreicht. Die Leseleistung beginnt dagegen bei 1,4.000 IOps und steigert die Performance nahezu linear mit der Anzahl der verwendeten Clients (denken Sie daran, dass die Anzahl der Threads für jeden Datenpunkt verdoppelt wird) und erreicht die maximale Performance von 25,6.000 IOPS bei 64 Threads, wobei die Maximale Performance nahe an der Schranke zu sein scheint. Die Verwendung von mehr Threads erfordert mehr als die 16 Compute-Nodes, um einen Ressourcenmangel und eine geringere offensichtliche Performance zu vermeiden, bei der die Arrays tatsächlich die Performance aufrechterhalten könnten.

 

---

Metadatenperformance mit MDtest mit leeren Dateien

Die Metadatenperformance wurde mit MDtest-Version 3.3.0 gemessen, unterstützt durch OpenMPI v4.0.1, um den 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 Verzeichnisse-Metadaten) verwendet, wobei die Anzahl der Erstellungen, Statistiken, Lese- und Entfernungen ermittelt wurde, die die Lösung verarbeiten kann, und die Ergebnisse wurden mit der Großformatlösung kontrastiert.

Um die Lösung im Vergleich zu anderen DellEMC HPC-Speicherlösungen und den vorherigen Blogergebnissen ordnungsgemäß zu bewerten, wurde das optionale High Demand Metadata Module verwendet, aber bei einem einzigen ME4024-Array wurde sogar die große Konfiguration, die in dieser Arbeit getestet wurde, auf zwei ME4024s festgelegt. Dieses High-Demand-Metadatenmodul kann bis zu vier ME4024-Arrays unterstützen. Es wird empfohlen, die Anzahl der ME4024-Arrays auf 4 zu erhöhen, bevor Ein weiteres Metadatenmodul hinzugefügt wird. Es wird erwartet, dass zusätzliche ME4024-Arrays die Metadatenperformance linear mit jedem zusätzlichen Array erhöhen, mit Ausnahme von Stat-Vorgängen (und Lesevorgängen für leere Dateien), da die Zahlen sehr hoch sind. Irgendwann werden die CPUs zu einem Engpass und die Performance wird nicht weiter linear steigen.

Der folgende Befehl wurde verwendet, um den Benchmark auszuführen, wobei Threads die Variable mit der Anzahl der verwendeten Threads war (1 bis 512 erhöht in Zweierleistung) und my_hosts.$Threads die entsprechende Datei ist, die jeden Thread auf einem anderen Node zugewiesen hat, wobei Round Robin verwendet wurde, um sie homogen auf die 16 Compute-Nodes zu verteilen. Ähnlich wie beim Benchmark für zufällige I/O war die maximale Anzahl der Threads auf 512 begrenzt, da nicht genügend Cores für 1024 Threads vorhanden sind und sich Kontext-Switching auf die Ergebnisse auswirken würde und eine Zahl meldet, die niedriger als die tatsächliche Performance der Lösung ist.

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

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-Dateien (2^21 = 2097152), die Anzahl der Dateien pro Verzeichnis, die bei 1024 festgelegt wurde, und die Anzahl der Verzeichnisse zu ändern, je nachdem, wie in Tabelle 3 gezeigt, geändert wurde.

Tabelle 3:  MDtest-Verteilung von Dateien in Verzeichnissen

Anzahl der Threads	Anzahl der Verzeichnisse pro Thread	Gesamtzahl der Dateien
1	2048	2,097,152
2	1024	2,097,152
4	512	2,097,152
8	256	2,097,152
16	128	2,097,152
32	64	2,097,152
64	32	2,097,152
128	16	2,097,152
256	8	2,097,152
512	4	2,097,152
1024	2	2,097,152

Abbildung 5: Metadatenperformance – leere Dateien

Beachten Sie zunächst, dass die ausgewählte Skala logarithmisch mit Basis 10 war, um den Vergleich von Vorgängen zu ermöglichen, die Unterschiede in mehreren Größenordnungen aufweisen. andernfalls würden einige der Vorgänge in einem normalen Diagramm wie eine flache Linie nahe 0 aussehen. Ein Protokolldiagramm mit Basis 2 könnte besser geeignet sein, da die Anzahl der Threads in den Kräften von 2 erhöht wird, aber das Diagramm würde sehr ähnlich aussehen und die Leute neigen dazu, bessere Zahlen basierend auf den Kräften von 10 zu verarbeiten und sich daran zu erinnern.
Das System erzielt sehr gute Ergebnisse mit Stat- und Lesevorgängen, die ihren Spitzenwert bei 64 Threads mit fast 11 Mio. Vorgängen bzw. 4,7 Mio. Vorgängen erreichen. Entfernungsvorgänge erreichten das Maximum von 170.600 Vorgängen bei 16 Threads und Erstellungsvorgänge erreichten ihren Spitzenwert bei 32 Threads mit 222.100 Vorgängen. Statistik- und Lesevorgänge weisen mehr Variabilität auf, aber sobald sie ihren Spitzenwert erreichen, sinkt die Leistung nicht unter 3 Mio. Vorgänge für Statistiken und 2 Mio. Vorgänge für Lesevorgänge. Erstellen und Entfernen sind stabiler, sobald sie einen Schlitten erreichen, und bleiben über 140.000 Op/s für das Entfernen und 120.000 Op/s für Create. Beachten Sie, dass sich die zusätzlichen Laufwerke nicht wie erwartet auf die meisten Metadatenvorgänge auf leeren Dateien auswirken.
 

---

Metadatenperformance mit MDtest mit 4 KiB-Dateien

Dieser Test ist fast identisch mit dem vorherigen, mit der Ausnahme, dass anstelle von leeren Dateien kleine Dateien mit 4 KiB verwendet wurden. 
Der folgende Befehl wurde verwendet, um den Benchmark auszuführen, wobei Threads die Variable mit der Anzahl der verwendeten Threads war (1 bis 512 erhöht in Zweierleistung) und my_hosts.$Threads die entsprechende Datei ist, die jeden Thread auf einem anderen Node zugewiesen hat, wobei Round Robin verwendet wurde, um sie homogen auf die 16 Compute-Nodes zu verteilen.

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

Abbildung 6:  Metadatenperformance – kleine Dateien (4K)

Das System erzielt sehr gute Ergebnisse für Statistik- und Entfernungsvorgänge, die ihren Spitzenwert bei 256 Threads mit jeweils 8,2 Mio. Vorgängen bzw. 400.000 Vorgängen erreichen. Lesevorgänge erreichten das Maximum von 44,8.000 Op/s und Erstellungsvorgänge erreichten ihren Spitzenwert mit 68.100 Vorgängen, beide bei 512 Threads. Statistik- und Entfernungsvorgänge weisen mehr Variabilität auf, aber sobald sie ihren Spitzenwert erreichen, sinkt die Leistung nicht unter 3 Mio. Vorgänge für Statistiken und 280.000 Vorgänge für das Entfernen. Erstellen und Lesen weisen weniger Variabilität auf und nehmen mit zunehmender Anzahl von Threads weiter zu. Wie zu beobachten ist, bieten die zusätzlichen Laufwerke der Kapazitätserweiterungen nur marginale Änderungen an der Metadatenperformance.
Da diese Zahlen für ein Metadatenmodul mit einem einzigen ME4024 gelten, steigt die Leistung für jedes zusätzliche ME4024-Array. Wir können jedoch nicht von einer linearen Steigerung für jeden Vorgang ausgehen. Wenn die gesamte Datei nicht in den Inode für eine solche Datei passt, werden Datenziele auf den ME4084s verwendet, um die 4K-Dateien zu speichern, wodurch die Performance bis zu einem gewissen Grad eingeschränkt wird. Da die Inode-Größe 4 KiB beträgt und weiterhin Metadaten gespeichert werden müssen, passen nur Dateien mit ca. 3 KiB in das System und jede Datei, die größer ist, verwendet Datenziele.
 

---

Schlussfolgerungen und zukünftige Arbeiten

Die Lösung mit erweiterter Kapazität konnte die Performance verbessern, nicht nur für zufällige Zugriffe, sondern auch für sequenzielle Performance. Dies wurde erwartet, da sich der verstreute Modus als randomisierte Zugriffe verhält und mehr Festplatten die Verbesserung ermöglichen. Es wird erwartet, dass diese Performance, die in Tabelle 4 angezeigt werden kann, von einem leeren Dateisystem stabil ist, bis sie fast voll ist. Darüber hinaus wird die Lösung linear skaliert, wenn mehr Speicher-Nodes-Module hinzugefügt werden, und eine ähnliche Leistungssteigerung ist vom optionalen High-Demand-Metadatenmodul zu erwarten. Diese Lösung bietet HPC-Kunden ein sehr zuverlässiges paralleles Dateisystem, das von vielen Top-500-HPC-Clustern verwendet wird. Darüber hinaus bietet es außergewöhnliche Suchfunktionen, erweitertes Monitoring und Management und das Hinzufügen optionaler Gateways ermöglichen die Dateifreigabe über allgegenwärtige Standardprotokolle wie NFS, SMB und andere für so viele Clients wie nötig.

Tabelle 4  Spitzenleistung und kontinuierliche Performance

	Spitzenleistung		Kontinuierliche Performance
	Schreiben	Read	Schreiben	Read
Große sequenzielle N-Clients zu N-Dateien	20,4 GB/s	24,2 GB/s	20,3 GB/s	24 GB/s
Große sequenzielle N-Clients in einer einzigen gemeinsam genutzten Datei	19,3 GB/s	24,8 GB/s	19,3 GB/s	23,8 GB/s
Zufällige kleine Blöcke von N Clients in N-Dateien	40 KIOps	25,6 KIOps	40,0 KIOps	19.3KIOps
Metadaten Leere Dateien erstellen	169,4.400 IOps		123.500 IOps
Metadatenstatistik leere Dateien	11 Mio. IOps		3,2 Mio. IOps
Metadaten Leere Dateien lesen	4,7 Mio. IOps		2,4 Mio. IOps
Metadaten Leere Dateien entfernen	170.600 IOps		156.500 IOps
Metadaten Erstellen von 4KiB-Dateien	68.100 IOps		68.100 IOps
Metadatenstatistik 4KiB-Dateien	8,2 Mio. IOps		3 Mio. IOps
Metadaten Lesen von 4KiB-Dateien	44.800 IOps		44.800 IOps
Metadaten Entfernen von 4KiB-Dateien	400.000 IOps		280.000 IOps

Da die Lösung mit Cascade Lake CPUs und schnellerem RAM veröffentlicht werden soll, werden einige Performance-Spot-Prüfungen durchgeführt, sobald das System die endgültige Konfiguration hat. Testen Sie außerdem das optionale High Demand Metadata Module mit mindestens 2 ME4024s- und 4KiB-Dateien, um besser zu dokumentieren, wie sich die Metadatenperformance bei Dereinsetzung von Datenzielen skalieren lässt. Darüber hinaus wird die Performance für die Gateway-Nodes gemessen und zusammen mit allen relevanten Ergebnissen aus den Punktprüfungen in einem neuen Blog oder einem Whitepaper gemeldet. Schließlich sind weitere Lösungskomponenten geplant, die getestet und freigegeben werden sollen, um noch mehr Funktionen bereitzustellen.