Dell EMC Ready-Lösungen für HPC-BeeGFS Storage mit hoher Leistung

Artikel geschrieben von Nirmala Sundararajan vom Dell EMC HPC and AI Innovation Lab im November 2019

Dell EMC Ready-Lösungen für HPC-BeeGFS Storage mit hoher Leistung

Inhaltsverzeichnis

1. Einführung
2. Lösungsreferenzarchitektur
3. Hardware- und Softwarekonfiguration
4. Details zur Lösungskonfiguration
   • Management-Service
   • Metadatenservice
   • Storage-Service
   • Client-Service
5. R740xd, 24x NVMe-Laufwerke, Details zur CPU-Zuordnung
6. Performance-Charakterisierung
   • Sequenzielle Lese- und Schreibvorgänge N-N
   • Zufällige Lese- und Schreibvorgänge N-N
7. Schlussfolgerungen und zukünftige Arbeiten
    

Einführung

Lösungsreferenzarchitektur

Hardware- und Softwarekonfiguration

Tabelle 1 und 2 beschreiben die Hardwarespezifikationen des Managementservers bzw. des Metadaten-/Storage-Servers. Tabelle 3 beschreibt die für die Lösung verwendeten Softwareversionen.

Details zur Lösungskonfiguration

• Management-Service
• Metadatenservice
• Storage-Service
• Client-Service

Management-Service

Metadatenservice

Abbildung 3:  Metadatenserver

Abbildung 4 zeigt die RAID-Konfiguration des Metadatenservers. Dadurch wird deutlich, wie auf dem Metadatenserver die Laufwerke in der NUMA-Zone 0 die MDTs hosten und die Laufwerke in NUMA-Zone 1 die Storage-Daten hosten, während die Storage-Server die STs in beiden NUMA-Zonen hosten.

Storage-Service

1. Die Schreibleistung wurde mit dd-Befehlen gemessen, indem eine 10-GiB-Datei mit einer Blockgröße von 1 MiB und direktem E/A-Vorgang für die Daten erstellt wurde. Bei RAID-0-Geräten lag der Durchschnitt bei 5,1 GB/s für jedes Gerät, während für RAID 10-Geräte der Durchschnitt bei 3,4 GB/s für jedes Gerät lag.
2. StorageBench-Benchmarktests zeigten einen maximalen Durchsatz von 5,5 Gbit/s für die RAID-0-Konfiguration, wohingegen dieser bei einer RAID-10-Konfiguration bei 3,4 Gbit/s lag. Diese Ergebnisse entsprechen dem, was mit dd-Befehlen erzielt wurde.
3. RAID 10 bietet 50 % Auslastung der Festplattenkapazität und eine ähnliche Reduzierung der Schreibleistung um 50 %. Die Verwendung von RAID 10 ist eine teure Möglichkeit für Storage-Redundanz.
4. NVMe-Laufwerke sind teuer und bieten Geschwindigkeiten, die am besten in einer RAID-0-Konfiguration zur Geltung kommen.

Client-Service

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

R740xd, 24x NVMe-Laufwerke, Details zur CPU-Zuordnung

# cat /proc/sys/kernel/numa_balancing
0

Performance-Charakterisierung

Sequenzielle Schreib- und Lesevorgänge N-N

Zur Auswertung sequenzieller Lese- und Schreibvorgänge wurde der Benchmarktest IOzone im sequenziellen Lese- und Schreibmodus verwendet. Diese Tests wurden mit verschiedenen Threadanzahlen durchgeführt, beginnend mit einem Thread und Erhöhungen um die Potenzen von 2, bis zu 1024 Threads. Bei jeder Threadanzahl wurde eine entsprechende Anzahl von Dateien generiert, da dieser Test auf eine Datei pro Thread oder den N-N-Fall (n Clients zu n Dateien) ausgelegt ist. Die Prozesse wurden auf 32 physische Client-Nodes in umlaufender oder zyklischer Weise aufgeteilt, sodass die Anforderungen gleichmäßig verteilt sind und ein Load-Balancing erfolgt. Es wurde eine aggregierte Dateigröße von 8 TB ausgewählt, die gleichmäßig auf die Anzahl der Threads innerhalb eines bestimmten Tests aufgeteilt wurde. Die aggregierte Dateigröße wurde groß genug gewählt, um die Auswirkungen des Caching von den Servern sowie von BeeGFS-Clients zu minimieren. IOzone wurde in einem kombinierten Modus aus Schreiben und anschließendem Lesen ausgeführt (-i 0, -i 1), damit die Grenzen zwischen den Vorgängen koordiniert werden können. Für diese Tests und Ergebnisse haben wir eine Datensatzgröße von 1 MiB für jede Ausführung verwendet. Die Befehle, die für sequenzielle N-N-Tests verwendet werden, sind unten angegeben:

Sequenzielle Schreib- und Lesevorgänge: iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

BS-Caches wurden auch auf den Client-Nodes zwischen Iterationen sowie zwischen Schreib- und Lesetests gelöscht oder bereinigt, indem dieser Befehl ausgeführt wurde:

# sync & echo 3 > /proc/sys/vm/drop_caches

Die Standard-Stripe-Anzahl für Beegfs ist 4. Die Blockgröße und die Anzahl der Ziele pro Datei können jedoch auf Verzeichnisbasis konfiguriert werden. Für alle diese Tests wurde die BeeGFS-Stripe-Größe als 2 MB und die Stripe-Anzahl als 3 ausgewählt, da wir drei Ziele pro NUMA-Zone haben, wie unten dargestellt:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe-Musterdetails:
+ Typ: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

Die transparenten riesigen Seiten wurden deaktiviert und die folgenden Tuningoptionen auf den Metadaten- und Storage-Servern festgelegt:

• vm.dirty_background_ratio = 5 
• vm.dirty_ratio = 20 
• vm.min_free_kbytes = 262144 
• vm.vfs_cache_pressure = 50
• vm.zone_reclaim_mode = 2 
• kernel.numa_balancing = 0

Zusätzlich zu den oben genannten Optionen wurden die folgenden BeeGFS-Tuningoptionen verwendet: 

• Der Parameter tuneTargetChooser wurde in der Metadatenkonfigurationsdatei auf roundpoolin festgelegt. 
• Der Parameter tuneNumWorkers wurde für Metadaten auf 24 und für Storage auf 32 festgelegt. 
• Der Parameter connMaxInternodeNum wurde für Metadaten auf 32 und für Speicher auf 12 und für Clients auf 24 festgelegt.

In Abbildung 9 sehen wir, dass die Spitzenleistung beim Lesevorgang bei 1024 Threads 132 GBit/s und bei 256 Threads 121 Gbit/s beträgt. Jedes Laufwerk bietet eine Spitzenleseleistung von 3,2 GB/s und eine Spitzenschreibleistung von 1,3 GB/s, was eine theoretische Spitzenleistung von 422 GB/s für Lesevorgänge und 172 GB/s für Schreibvorgänge ermöglicht. Hier ist jedoch das Netzwerk der einschränkende Faktor. Wir haben insgesamt 11 InfiniBand EDR-Links für die Storage-Server im Set-up. Jeder Link kann eine theoretische Spitzenleistung von 12,4 Gbit/s bereitstellen, was eine theoretische Spitzenleistung von 136,4 Gbit/s ermöglicht. Die erzielte Spitzenleistung bei Lese- und Schreibvorgängen beträgt 97 % bzw. 89 % der theoretischen Spitzenleistung.

Die Single-Thread-Schreibleistung liegt bei ca. 3 Gbit/s und beim Lesevorgang ebenfalls bei ca. 3 Gbit/s. Die Schreibleistung skaliert linear, mit einem Spitzenwert bei 256 Threads und dann abnehmend. Bei niedrigeren Threadanzahlen ist die Lese- und Schreibleistung identisch. Denn bei bis zu 8 Threads schreiben 8 Clients 8 Dateien auf 24 Ziele, was bedeutet, dass nicht alle Speicherziele vollständig ausgelastet sind. Wir haben 33 Speicherziele im Computer und daher sind mindestens 11 Threads erforderlich, um alle Server vollständig zu nutzen. Die Leseleistung weist eine stetige lineare Steigerung mit der Zunahme der Anzahl gleichzeitiger Threads auf und zeigt eine nahezu ähnliche Performance bei 512 und 1024 Threads.

Die Leseleistung ist außerdem niedriger als die Schreibleistung bei Thread-Anzahlen von 16 bis 128, danach beginnt die Leseleistung zu skalieren. Dies liegt daran, dass ein PCIe-Lesevorgang zwar ein „Non-Posted“ Vorgang ist, aber sowohl eine Anfrage als auch einen Abschluss erfordert, während ein PCIe-Schreibvorgang ein Fire-and-Forget-Vorgang ist. Sobald das TLP (Transaction Layer Packet) an den DLL (Data Link Layer) übergeben wurde, wird der Vorgang abgeschlossen. Ein Schreibvorgang ist ein „Posted“ Vorgang, der nur aus einer Anfrage besteht.

Der Lesedurchsatz ist in der Regel niedriger als der Schreibdurchsatz, da Lesevorgänge zwei Transaktionen anstelle eines einzigen Schreibvorgangs für dieselbe Datenmenge erfordern. PCI Express verwendet ein Split-Transaktionsmodell für Lesevorgänge. Die Lesetransaktion sollte folgende Schritte umfassen:

• Der Requester sendet ein MRR (Memory Read Request).
• Der Completer sendet die Bestätigung auf den MRR.
• Der Completer gibt eine Completion mit den Daten zurück.

Der Lesedurchsatz hängt von der Verzögerung zwischen dem Zeitpunkt, zu dem die Leseanfrage ausgegeben wird, und dem Zeitpunkt ab, an dem der Completer die Daten zurückgegeben hat. Wenn die Anwendung jedoch genügend Leseanfragen stellt, um diese Verzögerung abzudecken, wird der Durchsatz maximiert. Das ist der Grund dafür, dass die Leseleistung von 16 bis 128 Threads zwar geringer ist als die Schreibleistung, wir aber einen höheren Durchsatz messen, wenn die Anzahl der Anfragen steigt.  Ein niedrigerer Durchsatz wird gemessen, wenn der Requester auf den Abschluss wartet, bevor nachfolgende Anfragen gestellt werden. Ein höherer Durchsatz wird registriert, wenn mehrere Anfragen ausgegeben werden, um die Verzögerung nach der Rückgabe der ersten Daten zu amortisieren.

Zufällige Schreib-und Lesevorgänge N-N

Um die Leistung bei zufälligen E/A-Vorgängen zu evaluieren, wurde IOzone Version 3.487 im Random-Modus verwendet. Tests wurden für Threadanzahlen von 4 Threads bis zu 1.024 Threads durchgeführt. Die Option für Direct IO (-I) wurde verwendet, um IOzone auszuführen, sodass alle Vorgänge den Puffercache umgehen und direkt an die Festplatte gehen. Eine BeeGFS-Stripe-Anzahl von 3 und Blockgröße von 2 MB wurde verwendet. In IOzone wird eine Anfragegröße von 4 KiB verwendet. Die Performance wird in E/A-Vorgängen pro Sekunde (IOPS) gemessen. Die BS-Caches wurden zwischen den Ausführungen auf den BeeGFS-Servern sowie den BeeGFS-Clients gelöscht. Der Befehl, der für die Ausführung der zufälligen Schreib- und Lesevorgänge verwendet wird, ist unten angegeben:

Zufällige Lese- und Schreibvorgänge: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Abbildung 10:  Zufällige Lese- und Schreibleistung mit 8 TB aggregierter IOzone-Dateigröße

Der Spitzenwert für zufällige Schreibvorgänge liegt bei ~3,6 Millionen IOPS bei 512 Threads und der Spitzenwert für zufällige Lesevorgänge bei ~3,5 Millionen IOPS bei 1024 Threads, wie in Abbildung 10 gezeigt. Sowohl die Schreib- als auch die Leseleistung zeigen eine höhere Performance, wenn eine höhere Anzahl von E/A-Anforderungen vorhanden ist. Der Grund dafür ist, dass der NVMe-Standard bis zu 64.000 E/A-Warteschlangen und bis zu 64.000 Befehle pro Warteschlange unterstützt. Dieser große Pool von NVMe-Warteschlangen bietet ein höheres Maß an I/O-Parallelität und daher steigen die IOPS auf mehr als 3 Millionen.

Schlussfolgerungen und zukünftige Arbeiten

In diesem Blogbeitrag wird die Veröffentlichung der Dell EMC High Performance BeeGFS Storage-Lösung angekündigt und seine Leistungsmerkmale hervorgehoben. Die Lösung bietet einer Spitzenleistung bei sequenziellen Lese- und Schreibvorgängen von ~132 GB/s bzw. ~121 GB/s und einer Spitzenleistung bei zufälligen Schreibvorgängen von ~3,6 Millionen IOPS und zufälligen Lesevorgängen bei ~3,5 Millionen IOPS.

Dieser Blogbeitrag ist Teil Eins der „BeeGFS Storage Solution“, die mit Schwerpunkt auf Scratch-Speicher mit hoher Performance entwickelt wurde. Freuen Sie sich auf Teil 2 der Blogserie, in dem beschrieben wird, wie die Lösung durch eine höhere Anzahl Server skaliert werden kann, um Performance und Kapazität zu steigern. In Teil 3 der Blogserie werden zusätzliche Funktionen von BeeGFS besprochen und die Verwendung von StorageBench, dem Benchmark für integrierte Storage Targets von BeeGFS, hervorgehoben.

Als einer der nächsten Schritte veröffentlichen wir ein Whitepaper mit der Metadatenperformance und der IOR-Performance von n Threads zu 1 Datei und zusätzlichen Details zu Designüberlegungen, Tuning und Konfiguration.

Referenzen