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

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

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

Lösungsarchitektur

Lösungskomponenten

Performance-Charakterisierung

•     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

  
  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

  
  
  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

  
  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

  
  
  
  
  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

  
  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

   

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

  ---