Zu den Hauptinhalten
  • Bestellungen schnell und einfach aufgeben
  • Bestellungen anzeigen und den Versandstatus verfolgen
  • Profitieren Sie von exklusiven Prämien und Rabatten für Mitglieder
  • Erstellen Sie eine Liste Ihrer Produkte, auf die Sie jederzeit zugreifen können.

Dell EMC Ready-Lösung für HPC-PixStor-Speicher

Zusammenfassung: Referenzarchitektur für die Lösung zusammen mit anfänglicher Leistungsbewertung

Dieser Artikel gilt für Dieser Artikel gilt nicht für Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden. In diesem Artikel werden nicht alle Produktversionen aufgeführt.

Symptome

Artikel von Mario Gallegos vom HPC and AI Innovation Lab im Oktober 2019

Ursache

.

Lösung

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 zu einer Datei
    3. IOzone-Performance zufälliger kleiner Blöcke n Clients zu n Dateien
    4. Metadaten-Performance mit MDtest mithilfe leerer Dateien
    5. Metadaten-Performance mit MDtest mithilfe von 4-KiB-Dateien
    6. Metadatenperformance mit MDtest mit 3-KB-Dateien
  3. Erweiterte Analysen
  4. Schlussfolgerungen und zukünftige Arbeiten


 


Einführung

Heutige HPC-Umgebungen haben einen steigenden Bedarf für sehr schnellen Storage, der häufig auch 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 gedeckt, die gleichzeitigen Zugriff auf eine einzelne Datei oder einen Satz von Dateien auf mehreren Nodes bieten und Daten äußerst effizient und sicher auf mehrere LUNs über mehrere Server verteilen.

 

Lösungsarchitektur

In diesem Blog stellen wir Dell EMC die neueste Ergänzung der PFS-Lösungen (Parallel File System) für HPC-Umgebungen vor: die Dell EMC Ready Solution für HPC PixStor-Storage. Abbildung 1 zeigt die Referenzarchitektur, die Dell EMC PowerEdge R740-Server und die PowerVault ME4084- und ME4024-Storage-Arrays mit der PixStor-Software unseres Partnerunternehmens Arcastream nutzt.
PixStor umfasst das weit verbreitete General Parallel File System, auch bekannt als Spectrum Scale, als PFS-Komponente sowie Arcastream-Softwarekomponenten wie erweiterte Analysen, vereinfachte Verwaltung und Überwachung, effiziente Dateisuche, erweiterte Gateway-Funktionen und viele andere.

SLN318841_en_US__1image(11979)
Abbildung 1: Referenzarchitektur

 

Lösungskomponenten

Diese Lösung wird voraussichtlich mit den neuesten skalierbaren Intel Xeon CPUs der 2. Generation, bekannt als Cascade Lake CPUs, veröffentlicht. Einige der Server verwenden zudem den schnellsten für sie verfügbaren RAM (2933 MT/s). Aufgrund der verfügbaren Hardware für die Prototypenerstellung der Lösung und die Charakterisierung ihrer Leistung sind Server mit skalierbaren Intel Xeon CPUs der 1. Generation, auch bekannt als Zum Einsatz kamen Skylake-Prozessoren und langsamerer Arbeitsspeicher. Da der Engpass der Lösung bei den SAS-Controllern der Dell EMC PowerVault ME40x4-Arrays liegt, ist kein signifikanter Leistungsunterschied zu erwarten, sobald die Skylake-CPUs und der RAM durch die geplanten Cascade Lake-CPUs und schnelleren RAM ersetzt werden. Obwohl zum Zeitpunkt der Konfiguration des Systems die neueste Version von PixStor verfügbar war, die RHEL 7.6 unterstützte, entschied man sich, den QA-Prozess fortzusetzen und Red Hat® Enterprise Linux® 7.5 und die vorherige Nebenversion von PixStor zur Charakterisierung des Systems zu verwenden. Sobald das System auf Cascade Lake CPUs aktualisiert wurde, wird auch die PixStor-Software auf die neueste Version aktualisiert und es werden einige Leistungsstichproben durchgeführt, um sicherzustellen, dass die Leistung nicht den in diesem Dokument angegebenen Zahlen entspricht.

Aufgrund der zuvor beschriebenen Situation enthält Tabelle 1 die Liste der Hauptkomponenten für die Lösung. Die mittlere Spalte enthält die geplanten Komponenten, die zum Zeitpunkt der Veröffentlichung verwendet werden sollen und daher für Kunden verfügbar sind. Die letzte Spalte enthält die Komponentenliste, die tatsächlich zur Charakterisierung der Performance der Lösung verwendet wird. Die aufgeführten Laufwerke oder Daten (12 TB NLS) und Metadaten (960 GB SSD) werden für die Leistungscharakterisierung verwendet. Schnellere Laufwerke können bessere zufällige IOPS bieten und Vorgänge zum Erstellen/Entfernen von Metadaten verbessern.

Schließlich wurde der Vollständigkeit halber die Liste der möglichen Daten-HDDs und Metadaten-SSDs hinzugefügt, die auf den unterstützten Laufwerken gemäß der Dell EMC PowerVault ME4-Supportmatrix angegeben ist, die online verfügbar ist.

Tabelle 1 Komponenten, die zum Zeitpunkt der Freigabe verwendet werden sollen, und Komponenten, die in der Testumgebung verwendet werden

SLN318841_en_US__2image(12041)
 

Performance-Charakterisierung

Zur Charakterisierung dieser neuen Ready Solution haben wir die in der letzten Spalte von Tabelle 1 angegebene Hardware verwendet, einschließlich des optionalen High-Demand-Metadatenmoduls. 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 in Tabelle 2 unten beschriebenen Clients. Da die Anzahl der für Tests verfügbaren Rechenknoten 16 betrug, wenn eine höhere Anzahl von Threads erforderlich war, wurden diese Threads gleichmäßig auf die Rechenknoten verteilt (d. h. 32 Threads = 2 Threads pro Knoten, 64 Threads = 4 Threads pro Knoten, 128 Threads = 8 Threads pro Knoten, 256 Threads = 16 Threads pro Knoten, 512 Threads = 32 Threads pro Knoten, 1024 Threads = 64 Threads pro Node). Der Zweck bestand darin, mit der begrenzten Anzahl an Compute-Nodes eine höhere Anzahl gleichzeitiger Clients zu simulieren. Da die Benchmarks eine große Anzahl von Threads unterstützen, wurde ein maximaler Wert von bis zu 1024 verwendet (für jeden Test angegeben), wobei ein übermäßiger Kontextwechsel und andere damit verbundene Nebeneffekte vermieden wurden, die sich auf die Leistungsergebnisse auswirken.

    Tabelle 2: Clienttest-Bed

    Anzahl der Client-Nodes

    16

    Client-Node

    C6320

    Prozessoren pro Client-Node

    2 x Intel(R) Xeon(R) Gold E5-2697v4 mit 18 Cores bei 2,30 GHz

    Arbeitsspeicher pro Client-Node

    12 x RDIMMs mit 16 GiB und 2400 MT/s

    BIOS

    2.8.0

    BS-Kernel

    3.10.0-957.10.1

    GPFS-Version

    5.0.3

     

    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 reichten von einem einzelnen Thread bis zu 1024 Threads. 
    Die Caching-Effekte wurden minimiert, indem der GPFS-Seitenpool auf 16 GiB festgelegt und Dateien verwendet wurden, die doppelt so groß waren. Es ist wichtig zu beachten, dass diese Optimierung für GPFS die maximale Menge an Speicher festlegt, die für das Zwischenspeichern von Daten verwendet wird, unabhängig davon, wie viel RAM installiert und frei ist. 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 jedoch mit 8 MiB-Blöcken formatiert wurde. Daher wird dieser Wert für die Benchmark für eine optimale Performance verwendet. 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 war (1 bis 1024 in Zweierpotenzen) und "threadlist" die Datei war, die jeden Thread einem anderen Node zugewiesen hat, wobei sie im Rundlaufverfahren homogen über die 16 Compute-Nodes verteilt wurden.

    ./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

    SLN318841_en_US__3image(11984)
    Abbildung 2:  N bis N sequenzielle Leistung


    Aus den Ergebnissen können wir beobachten, dass die Leistung mit der Anzahl der verwendeten Clients sehr schnell ansteigt und dann ein Plateau erreicht, das stabil ist, bis die maximale Anzahl von Threads erreicht ist, die IOzone zulässt, und daher ist die sequenzielle Leistung großer Dateien auch für 1024 gleichzeitige Clients stabil. Beachten Sie, dass die maximale Leseleistung bei 32 Threads bei 23 GB/s lag und der Engpass sehr wahrscheinlich die InfiniBand EDR-Schnittstelle war, während ME4-Arrays noch etwas zusätzliche Leistung zur Verfügung hatten. Beachten Sie, dass die maximale Schreibleistung von 16,7 bei 16 Threads etwas früher erreicht wurde und im Vergleich zu den Spezifikationen der ME4-Arrays anscheinend niedrig ist.
    Hier ist es wichtig, sich daran zu erinnern, dass der bevorzugte Betriebsmodus von GPFS verstreut ist und die Lösung so formatiert wurde, dass sie ihn verwendet. In diesem Modus werden Blöcke von Anfang an pseudozufällig zugewiesen, wobei die Daten über die gesamte Oberfläche jeder HDD verteilt werden. Der offensichtliche Nachteil liegt in einer kleineren anfänglichen Maximalperformance, diese Performance bleibt jedoch relativ konstant, unabhängig davon, wie viel Speicherplatz auf dem Dateisystem verwendet wird. Dies steht im Kontrast zu anderen parallelen Dateisystemen, die anfänglich die äußeren Tracks verwenden, die mehr Daten (Sektoren) pro Festplattenumdrehung enthalten können und daher die höchstmögliche Leistung bieten, die HDDs bieten können. Wenn das System aber mehr Speicherplatz verwendet, werden die inneren Tracks mit weniger Daten pro Umdrehung verwendet, mit der daraus resultierenden Performancereduzierung. 

     

    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 Einzelgewinde bis zu 1024 Gewinden.
    Die Caching-Effekte wurden minimiert, indem der GPFS-Seitenpool auf 16 GiB festgelegt und Dateien verwendet wurden, die doppelt so groß waren. In diesen Benchmarktests wurden 8-MiB-Blöcke für eine optimale Performance verwendet. Im vorherigen Abschnitt zum Leistungstest finden Sie eine ausführlichere Erläuterung dieser Aspekte. 
    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 in Zweierpotenzen) und my_hosts.$Threads die entsprechende Datei war, die jeden Thread auf einem anderen Node zuwies und sie im Rundlaufverfahren homogen über die 16 Compute-Nodes verteilte.

    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

    SLN318841_en_US__4image(11985)

    Abbildung 3: N zu 1 Sequenzielle Leistung

    Aus den Ergebnissen lässt sich ableiten, dass die Performance mit der Anzahl der verwendeten Clients sehr schnell wieder ansteigt und dann ein Plateau erreicht, das bei Lesevorgängen halbwegs stabil und bei Schreibvorgängen sehr stabil ist, bis hin zur maximalen Anzahl von Threads, die bei diesem Test verwendet werden. Aus diesem Grund ist die sequenzielle Leistung einer großen einzelnen freigegebenen Datei auch bei 1.024 gleichzeitigen Clients stabil. Beachten Sie, dass die maximale Leseperformance bei 16 Threads bei 23,7 GB/s lag und der Engpass sehr wahrscheinlich die InfiniBand EDR-Schnittstelle war, während ME4-Arrays noch etwas zusätzliche Leistung zur Verfügung hatten. Darüber hinaus sank die Leseleistung von diesem Wert, bis sie bei etwa 20,5 GB/s das Plateau erreichte, mit einem kurzzeitigen Rückgang auf 18,5 GB/s bei 128 Threads. Beachten Sie, dass die maximale Schreibleistung von 16,5 bei 16 Threads erreicht wurde und im Vergleich zu den Spezifikationen der ME4-Arrays anscheinend niedrig ist.
     

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

    Die Performance von zufälligen N Clients zu N Dateien wurde mit IOzone Version 3.487 gemessen. Die durchgeführten Tests reichten von Einzelgewinde bis zu 1024 Gewinden. Bei diesem Benchmarktest wurden 4-KiB-Blöcke verwendet, um den Datenverkehr mit kleinen Blöcken zu emulieren.
    Caching-Effekte wurden minimiert, indem der GPFS-Seitenpool, der auf 16 GiB optimiert werden kann, und Dateien verwendet wurden, die doppelt so groß sind. Der erste Performancetest-Abschnitt enthält eine umfassendere Erklärung dazu, warum dies bei GPFS effektiv ist. 
    Der folgende Befehl wurde verwendet, um die Benchmark im zufälligen IO-Modus für Schreib- und Lesevorgänge auszuführen, wobei "Threads" die Variable mit der Anzahl der verwendeten Threads war (1 bis 1024 in Zweierpotenzen) und "threadlist" die Datei war, die jeden Thread auf einem anderen Node zuwies und sie mittels Round-Robin homogen über die 16 Compute-Nodes verteilte.

    ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

    SLN318841_en_US__5image(11987)
    Abbildung 4:  N bis N zufällige Leistung

    Aus den Ergebnissen können wir beobachten, dass die Schreibleistung bei einem hohen Wert von fast 8,2 KB IOPS beginnt und stetig bis zu 128 Threads ansteigt, wo sie ein Plateau erreicht und in der Nähe des Maximalwerts von 16,2 KB IOPS bleibt. Die Leseleistung hingegen beginnt sehr klein bei über 200 IOPS und steigt fast linear mit der Anzahl der verwendeten Clients an (denken Sie daran, dass die Anzahl der Threads für jeden Datenpunkt verdoppelt wird) und erreicht die maximale Leistung von 20,4 KB IOPS bei 512 Threads, ohne Anzeichen dafür, dass das Maximum erreicht wird. Die Verwendung von mehr Threads auf den aktuellen 16 Rechenknoten mit je zwei CPUs und jeder CPU hat 18 Kerne, hat jedoch die Einschränkung, dass nicht genügend Kerne vorhanden sind, um die maximale Anzahl von IOzone-Threads (1024) ohne Kontextwechsel auszuführen (16 x 2 x 18 = 576 Kerne), was die Leistung erheblich einschränkt. In einem zukünftigen Test mit mehr Computeknoten könnte überprüft werden, welche zufällige Leseleistung mit 1.024 Threads mit IOzone erreicht werden kann, oder IOR könnte verwendet werden, um das Verhalten mit mehr als 1.024 Threads zu untersuchen.

     

    Metadaten-Performance mit MDtest mithilfe leerer 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 Erstellungen, Statistiken, Lesevorgänge und Entfernungen zu erhalten, die die Lösung verarbeiten kann.
    Um die Lösung im Vergleich zu anderen HPC-Storage-Lösungen von Dell EMC richtig zu bewerten, wurde das optionale High-Demand-Metadatenmodul verwendet, aber bei einem einzigen ME4024-Array, selbst wenn die große Konfiguration und die in dieser Arbeit getesteten Arrays zwei ME4024 aufweisen. 
    Das High Demand Metadata Module 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 Metadatenleistung linear mit jedem zusätzlichen Array erhöhen, außer vielleicht für Stat-Vorgänge (und Lesevorgänge für leere Dateien), da die Zahlen sehr hoch sind, werden die CPUs irgendwann zu einem Engpass und die Performance wird nicht weiter linear steigen.
    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


    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 Gesamtzahl der Dateien auf 2 MiB-Dateien (2^21 = 2097152) zu beschränken, die Anzahl der Dateien pro Verzeichnis auf 1024 festzulegen und die Anzahl der Verzeichnisse zu variieren, wenn sich die Anzahl der Threads änderte, wie in Tabelle 3 gezeigt.

    Tabelle 3:  MDtest-Verteilung von Dateien in Verzeichnissen

    Anzahl der Threads

    Anzahl der Verzeichnisse pro Thread

    Gesamtzahl der Dateien

    1

    2048

    2097152

    2

    1024

    2097152

    4

    512

    2097152

    8

    256

    2097152

    16

    128

    2097152

    32

    64

    2097152

    64

    32

    2097152

    128

    16

    2097152

    256

    8

    2097152

    512

    4

    2097152

    1024

    2

    2097152




    SLN318841_en_US__6image(11988)
    Abbildung 5: Metadatenperformance – leere Dateien

    Beachten Sie zunächst, dass die gewählte Skala logarithmisch zur Basis 10 war, um den Vergleich von Operationen zu ermöglichen, die Unterschiede um mehrere Größenordnungen aufweisen. Andernfalls würden einige der Vorgänge in einem normalen 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 wird, aber der Graph würde ziemlich ähnlich aussehen, und die Leute neigen dazu, mit Zahlen umzugehen und sich besser daran zu erinnern, die auf Potenzen von 10 basieren.


    Das System erzielt sehr gute Ergebnisse mit Statistik- und Lesevorgängen, die ihren Spitzenwert bei 64 Threads mit 11,2 Mio. OP/s bzw. 4,8 Mio. OP/s erreichen. Entfernungsvorgänge erreichten das Maximum von 169,4 K OP/s bei 16 Threads und Erstellungsvorgänge erreichten ihren Spitzenwert bei 512 Threads mit 194,2 K OP/s. Statistik- und Lesevorgänge weisen mehr Schwankungen auf, aber sobald sie ihren Spitzenwert erreicht haben, sinkt die Performance nicht unter 3 Mio. Vorgänge pro Sekunde für Statistiken und 2 Mio. Vorgänge pro Sekunde für Lesevorgänge. Erstellen und Entfernen sind stabiler, sobald sie ein Plateau erreicht haben, und bleiben über 140.000 OP/s für Entfernen und 120.000 OP/s für Create.
     

    Metadaten-Performance mit MDtest mithilfe von 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 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.

    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

    SLN318841_en_US__7image(11989)
    Abbildung 6:  Metadatenperformance – kleine Dateien (4K)

    Das System erzielt sehr gute Ergebnisse bei Stat- und Removal-Vorgängen und erreicht seinen Spitzenwert bei 128 Threads mit 7,7 Mio. OP/s bzw. 1 Mio. OP/s. Entfernungsvorgänge erreichten das Maximum von 37,3K op/s und Erstellungsvorgänge erreichten ihren Spitzenwert mit 55,5 K op/s, beide bei 512 Threads. Stat- und Entfernungsvorgänge weisen eine größere Variabilität auf, aber sobald sie ihren Spitzenwert erreicht haben, sinkt die Leistung nicht unter 4 Mio. OP/s für Stats und 200.000 OP/s für Removal. Erstellungs- und Lesevorgängen weisen weniger Schwankungen auf und die Performance steigt mit zunehmender Anzahl der Threads an.
    Da sich diese Zahlen auf ein Metadatenmodul mit einem einzigen ME4024 beziehen, steigt die Performance für jedes zusätzliche ME4024-Array, wir können jedoch nicht einfach von einer linearen Steigerung für jeden Vorgang ausgehen. Wenn die gesamte Datei nicht auf 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 auf den Inode und jede Datei, die größer ist, verwendet Datenziele.
     


    Metadatenperformance mit MDtest mit 3-KB-Dateien

    Dieser Test ist fast identisch mit den vorherigen, außer dass kleine Dateien von 3 KiB verwendet wurden. Der Hauptunterschied besteht darin, dass diese Dateien vollständig in den Inode passen. Aus diesem Grund werden die Speicher-Nodes und ihre ME4084s nicht verwendet. Die Gesamtgeschwindigkeit wird verbessert, da nur SSD-Medien als Speicher verwendet werden und weniger Netzwerkzugriffe erforderlich sind. 
    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.

    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 3K -e 3K

     

    SLN318841_en_US__8image(11990)
    Abbildung 7: Metadatenperformance – kleine Dateien (3K)

    Das System erzielt sehr gute Ergebnisse bei Statistik- und Lesevorgängen und erreicht seinen Spitzenwert bei 256 Threads mit 8,29 Mio. OP/s bzw. 5,06 Mio. OP/s. Entfernungsvorgänge erreichten das Maximum von 609.000 OP/s bei 128 Threads und Erstellungsvorgänge erreichten ihren Spitzenwert mit 78.000 OP/s bei 512 Threads. Statistik- und Lesevorgänge weisen eine größere Variabilität auf als Erstellen und Entfernen. Beim Entfernen ist ein leichter Leistungsabfall bei den beiden höheren Threads zu verzeichnen, was darauf hindeutet, dass die anhaltende Leistung nach 128 Threads etwas über 400.000 OP/s liegt. Die Anzahl der erstellten Threads wurde auf bis zu 512 erhöht, scheint aber ein Plateau zu erreichen, sodass die maximale Leistung möglicherweise immer noch unter 100.000 OP/s liegt.
    Da solche kleinen Dateien vollständig auf dem SSD-basierten Metadatenmodul gespeichert werden, können Anwendungen, die eine überragende Leistung für kleine Dateien benötigen, ein oder mehrere optionale High-Demand-Metadatenmodule verwenden, um die Leistung kleiner Dateien zu steigern. Die Dateien, die in den Inode passen, sind jedoch nach aktuellen Standards winzig. Da die Metadatenziele RAID1s mit relativ kleinen SSDs verwenden (maximale Größe ist 19,2 TB), ist die Kapazität im Vergleich zu den Storage Nodes begrenzt. Daher muss darauf geachtet werden, dass Metadatenziele nicht gefüllt werden, da dies zu unnötigen Ausfällen und anderen Problemen führen kann.
     


    Erweiterte Analysen

    Unter den Funktionen von PixStor kann das Monitoring des Dateisystems über erweiterte Analysen unerlässlich sein, um die Verwaltung erheblich zu vereinfachen und proaktiv oder reaktiv Probleme oder potenzielle Probleme zu finden. Als Nächstes werden wir einige dieser Funktionen kurz durchgehen.
    Abbildung 8 zeigt nützliche Informationen basierend auf der Dateisystemkapazität. Auf der linken Seite wird der insgesamt belegte Dateisystemspeicherplatz und die zehn wichtigsten Nutzer basierend auf der genutzten Dateisystemkapazität angezeigt. Auf der rechten Seite sehen Sie eine Verlaufsansicht mit der über viele Jahre genutzten Kapazität, dann die zehn am häufigsten verwendeten Dateitypen und die zehn wichtigsten Dateisätze, beide basierend auf der genutzten Kapazität, in einem Format, das Pareto-Diagrammen ähnelt (ohne die Linien für die kumulierten Gesamtsummen). Mit diesen Informationen können Sie leicht herausfinden, ob Nutzer mehr als ihren angemessenen Anteil am Dateisystem erhalten, Trends der Kapazitätsauslastung als Entscheidungshilfe für zukünftiges Kapazitätswachstum und welche Dateien den größten Speicherplatz belegen oder welche Projekte den größten Teil der Kapazität beanspruchen.

    SLN318841_en_US__9image(11993)
    Abbildung 8:  PixStor Analytics – Ansicht

    "Kapazität" Abbildung 9 zeigt eine Ansicht der Dateianzahl mit zwei sehr nützlichen Möglichkeiten, Probleme zu finden. In der ersten Hälfte des Bildschirms sind die zehn größten Nutzer in einem Kreisdiagramm und die zehn wichtigsten Dateitypen und die zehn wichtigsten Dateisätze (z. B. Projekte) in einem Format ähnlich wie Pareto-Diagramme (ohne die Linien für die kumulierten Summen) dargestellt, die alle auf der Anzahl der Dateien basieren. Diese Informationen können verwendet werden, um einige wichtige Fragen zu beantworten. Zum Beispiel, welche Nutzer das Dateisystem monopolisieren, indem sie zu viele Dateien erstellen, welcher Dateityp einen Metadaten-Albtraum verursacht oder welche Projekte die meisten Ressourcen verwenden.
    Die untere Hälfte hat ein Histogramm mit der Anzahl der Dateien (Häufigkeit) für Dateigrößen mit 5 Kategorien für verschiedene Dateigrößen. Dies kann verwendet werden, um eine Vorstellung von den Dateigrößen zu erhalten, die im Dateisystem verwendet werden, die auf die Dateitypen abgestimmt sind, um zu entscheiden, ob eine Komprimierung vorteilhaft ist.

    SLN318841_en_US__10image(11994)
    Abbildung 9:  PixStor Analytics – Ansicht der Dateianzahl



     


    Schlussfolgerungen und zukünftige Arbeiten

    Die aktuelle Lösung war in der Lage, eine recht gute Leistung zu liefern, die unabhängig vom verwendeten Speicherplatz (da das System im Streumodus formatiert wurde) stabil sein dürfte, wie in Tabelle 4 zu sehen ist. Darüber hinaus skaliert die Kapazität und Performance der Lösung linear, wenn mehr Storage Nodes hinzugefügt werden. Eine ähnliche Performancesteigerung ist vom optionalen High Demand Metadata Module zu erwarten. 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 es außergewöhnliche Suchfunktionen, erweitertes Monitoring und Management, und das Hinzufügen optionaler Gateways ermöglicht die Dateifreigabe über allgegenwärtige Standardprotokolle wie NFS, SMB und andere für so viele Clients wie nötig.

    Tabelle 4  Spitzenleistung und anhaltende Leistung

     

     

    Spitzenleistung

    Kontinuierliche Performance

    Schreiben

    Read

    Schreiben

    Read

    Große sequenzielle Vorgänge n Clients zu n Dateien

    16,7 Gbit/s

    23 Gbit/s

    16,5 Gbit/s

    20,5 Gbit/s

    Große sequenzielle Vorgänge n Clients zu einer einzigen freigegebenen Datei

    16,5 Gbit/s

    23,8 GB/s

    16,2 Gbit/s

    20,5 Gbit/s

    Zufällige kleine Blöcke von n Clients zu n Dateien

    15,8 KIOps

    20,4 KIOps

    15,7 KIOps

    20,4 KIOps

    Metadaten, Leere Dateien erstellen

    169.400 IOPS

    127.200 IOps

    Metadaten, Statistik leere Dateien

    11,2 Mio. IOps

    3,3 Mio. IOps

    Metadaten, Leere Dateien lesen

    4,8 Mio. IOps

    2,4 Mio. IOPS

    Metadaten, Leere Dateien entfernen

    194,2K IOps

    144,8K IOps

    Metadaten, Erstellen von 4-KiB-Dateien

    55.400 IOps

    55.400 IOps

    Metadaten, Statistik 4-KiB-Dateien

    6,4 Mio. IOps

    4 Mio. IOps

    Metadaten, Lesen von 4-KiB-Dateien

    37,3K IOps

    37,3K IOps

    Metadaten, Entfernen von 4-KiB-Dateien

    1 Mio. IOps

    219,5K IOps



    Da die Lösung mit Cascade Lake CPUs und schnellerem RAM veröffentlicht werden soll, werden einige Performance-Stichprobenprüfungen durchgeführt, sobald das System über die endgültige Konfiguration verfügt. Außerdem muss das optionale High Demand Metadata Module mit mindestens 2 ME4024s und 4-KiB-Dateien getestet werden, um besser zu dokumentieren, wie sich die Metadaten-Performance bei Verwendung von Datenzielen skalieren lässt. Darüber hinaus wird die Performance der Gateway-Nodes gemessen und zusammen mit allen relevanten Ergebnissen aus den Stichprobenprüfungen in einem neuen Blog oder einem Whitepaper veröffentlicht. Abschließend sind weitere Lösungskomponenten geplant, die getestet und veröffentlicht werden, um noch mehr Funktionen bereitzustellen.


     

Betroffene Produkte

High Performance Computing Solution Resources, Dell EMC PowerVault ME4012, Dell EMC PowerVault ME4024, Dell EMC PowerVault ME4084
Artikeleigenschaften
Artikelnummer: 000130962
Artikeltyp: Solution
Zuletzt geändert: 23 Sept. 2024
Version:  6
Antworten auf Ihre Fragen erhalten Sie von anderen Dell NutzerInnen
Support Services
Prüfen Sie, ob Ihr Gerät durch Support Services abgedeckt ist.