Dell EMC Ready-Lösungen für HPC-BeeGFS-Speicher mit hoher Kapazität

Dieser Artikel wurde geschrieben von Nirmala Sundararajan, HPC and AI Innovation Lab, April 2020

Inhaltsverzeichnis:

1. Einführung
2. Lösungs Referenzarchitektur
3. Hardware-und Software Konfiguration
4. Details zur Lösungskonfiguration
   • Überwachungsdienst
   • Metadaten-Service
   • Management Service
   • Speicher Service
   • Client Dienst
5. Performance-Bewertung
   • Sequenzielle Lese-und Schreibvorgänge N-n
   • Zufällige Lese-und Schreibvorgänge n-n
   • Verwendete Tuning-Parameter
6. Fazit und zukünftige arbeiten

Einführung

Die Dell EMC Ready-Lösungen für HPC BeeGFS-Speicher mit hoher Kapazität ist eine vollständig unterstützte, parallele Dateisystem Speicherlösung mit hohem Durchsatz. In diesem Blog werden die Lösungsarchitektur, die optimierte HPC Leistung und die I/O-Performance mit sequenziellen und zufälligen IOZone-Benchmarks beschrieben. Eine BeeGFS-leistungsstarke Speicherlösung, die auf NVMe-Geräten basiert, wurde in diesem Blog beschrieben, das während des Nov 2019 veröffentlichtwurde. Die Architektur hat die Performance hervorgehoben, und die hier beschriebene Lösung ist eine Speicherlösung mit hoher Kapazität.  Diese beiden Lösungen für BeeGFS unterscheiden sich hinsichtlich ihrer Design Ziele und Anwendungsbeispiele.  Die leistungsfähige Lösung ist als eine Scratch-Speicherlösung konzipiert, eine Staging-Basis für transiente Datasets, die in der Regel nicht über die Lebensdauer des Jobs hinweg aufbewahrt werden. Die Lösung für hohe Kapazität verwendet 4X Dell EMC PowerVault ME4084-Arrays, die vollständig mit 336 Laufwerken bestückt sind, und bietet eine RAW-Kapazität von 4PB, wenn Sie mit 12-TB-SAS-Laufwerken ausgestattet sind. 

Zurück zum Anfang

Lösungs Referenzarchitektur

Die Dell EMC Ready-Lösung für HPC BeeGFS-Speicher mit hoher Kapazität besteht aus einem Verwaltungsserver, einem Paar von Metadaten-Servern, einem Paar von Speicher Servern und den zugehörigen Speicher-Arrays. Die Lösung stellt Speicher zur Verfügung, der einen einzigen Namespace verwendet, der leicht von den Rechner-Nodes des Clusters aus zugänglich ist. Die folgende Abbildung zeigt die Referenzarchitektur der Lösung mit diesen primären Komponenten:

• Management Server
• Metadaten-Server Paar mit PowerVault ME4024 als Back-End-Speicher
• Speicher Server Paar mit PowerVault ME4084 als Back-End-Speicher

Abbildung 1 zeigt die Referenzarchitektur der Lösung.

Abbildung 1: Dell EMC Ready-Lösung für HPC BeeGFS-Speicher

In Abbildung 1 ist der Verwaltungsserver, auf dem der BeeGFS-Überwachungs-Daemon ausgeführt wird, ein PowerEdge R640.   Die beiden Metadata Server (MDS) sind PowerEdge R740-Server in einer aktiv-aktiv-Konfiguration mit hoher Verfügbarkeit.  Das MDS-Paar ist mit dem 2U-PowerVault ME4024-Array mit 12-Gbit/s-SAS Links verbunden. Das ME4024-Speicherarray hostet die Metadaten-Ziele (MDTs). Ein weiteres Paar PowerEdge R740-Server, auch in aktiv-aktiv-Konfiguration mit hoher Verfügbarkeit, werden als Speicherserver (SS) verwendet.  Dieses SS-Paar ist mit vier vollständig bestückten PowerVault ME4084-Speicherarrays mit 12-Gbit/s-SAS Links verbunden. Die ME4084-Arrays unterstützen eine Auswahl von 4-TB-, 8-TB-, 10-TB-oder 12-TB-nl-SAS 7,2 K rpm-Festplattenlaufwerken (HDDs und Host der Speicherziele (STS) für das BeeGFS-Dateisystem. Diese Lösung verwendet Mellanox Infiniband-HDR100 für das Datennetzwerk. Die Clients und Server sind mit dem 1U Mellanox Quantum HDR Edge Switch QM8790 verbunden, der bis zu 80 Ports von HDR100 mithilfe von HDR-Splitter-Kabeln unterstützt.

Zurück zum Anfang

Hardware-und Software Konfiguration

In der folgenden Tabelle werden die für die Lösung validierten Hardware-speficiations und Softwareversionen beschrieben.

Tabelle 1: Testumgebungskonfiguration

Hinweis: Zum Zweck der Performance Charakterisierung wurde die BeeGFS-Version 7,2 beta2 verwendet.

Zurück zum Anfang

Details zur Lösungskonfiguration

Die BeeGFS-Architektur besteht aus vier Hauptservices:

1. Management Service
2. Metadaten-Service
3. Speicher Service
4. Client Dienst

Es gibt auch einen optionalen BeeGFS-Überwachungs Service.

Außer dem Client Dienst, der ein Kernelmodul ist, sind die Management-, Metadaten-und Speicherservices Benutzerspeicher Platz Prozesse. Es ist möglich, eine beliebige Kombination von BeeGFS-Services (Client-und Server Komponenten) zusammen auf denselben Computern auszuführen. Es ist auch möglich, mehrere Instanzen eines BeeGFS-Services auf demselben Computer auszuführen. In der Dell EMC Konfiguration mit hoher Kapazität von BeeGFS wird der Überwachungsservice auf dem Verwaltungsserver ausgeführt, mehrere Instanzen des Metadatendienst werden auf den Metadaten-Servern ausgeführt und eine einzige Instanz des Speicher Diensts wird auf Speicher Servern ausgeführt. Der Management-Service wird auf den Metadaten-Servern installiert.  

Überwachungsdienst

Der BeeGFS-Überwachungsdienst (BeeGFS-Mon. Service) erfasst BeeGFS-Statistiken und stellt Sie dem Benutzer mithilfe der Time Series-Datenbank InfluxDBzur Verfügung.   Zur Visualisierung von Daten stellt beegfs-Mon-grafana vordefinierte grafana -Dashboards zur Verfügung, die in der Box verwendet werden können. Abbildung 2 bietet eine allgemeine Übersicht über den BeeGFS-Cluster, in dem die Anzahl der Speicherservices und metadatenleistungen im Setup angezeigt wird (als Nodes im Dashboard bezeichnet). Es listet außerdem die anderen verfügbaren Dashboard-Ansichten auf und bietet einen Überblick über die Speicherziele.

Abbildung 2 Grafana-Dashboard – Übersicht über BeeGFS

Zurück zum Anfang

Metadaten-Service

Das ME4024-Speicherarray, das für den Metadaten-Speicher verwendet wird, ist vollständig mit 24x 960GB-SSDs bestückt. Diese Laufwerke werden in 12X linearen RAID-Laufwerksgruppen mit jeweils 2 Laufwerken konfiguriert (siehe Abbildung 3). Jede RAID-Gruppe ist ein Metadaten-Ziel.

Abbildung 3 vollständig bestücktes ME4024-Array mit 12 MDTs

In BeeGFS wird für jeden Metadaten-Service nur eine einzige MDT. Da 12 MDTs vorhanden sind, müssen 12 Instanzen des Metadaten-Service vorhanden sein. Auf jedem der beiden Metadatenserver werden sechs Instanzen des Metadaten-Services ausgeführt. Die Metadaten-Ziele sind mit einem Ext4-Dateisystem formatiert (ext4-Dateisysteme werden mit kleinen Dateien und kleinen Dateivorgängen gut durchgeführt). Außerdem speichert BeeGFS Informationen in erweiterten Attributen und direkt auf den Inodes des Dateisystems, um die Performance zu optimieren, die beide mit dem Ext4-Dateisystem gut funktionieren.

Zurück nach oben

Management Service

Der beegfs-mgmtd- Service wird auf beiden Metadaten-Servern eingerichtet. Der beegfs-mgmtd-Speicher wird in dem Verzeichnis, das auf Metadaten-Ziel 1 wie unten dargestellt ist, initialisiert:

/Opt/beegfs/sbin/beegfs-Setup-mgmtd-p/beegfs/metaA-numa0-1/mgmtd-s beegfs-Mgmt

Der Management-Service wird auf dem metaa-Server gestartet.
 

Zurück zum Anfang

Speicher Service

In dieser BeeGFS-Lösung mit hoher Kapazität liegt der Datenspeicher über vier PowerVault ME4084-Speicherarrays. Lineare RAID-6-Festplattengruppen mit 10 Laufwerken (8 + 2) werden jeweils auf jedem Array erstellt. Für jede Laufwerksgruppe wird ein einzelnes Volume mit dem gesamten Speicherplatz erstellt. Dies führt zu 8 Festplattengruppen/Volumes pro Array. Jedes Array verfügt über 84-Laufwerke und die Erstellung von 8 x RAID-6-Festplattengruppen hinterlässt 4 Laufwerke, die über die Array-Volumes als globale Hot Spares konfiguriert werden können.

Mit dem oben beschriebenen Layout sind insgesamt 32 x RAID-6-Volumes über 4 x ME4084 in einer Basiskonfiguration in Abbildung 1 dargestellt. Jedes dieser RAID-6-Volumes ist als Storage Target (St) für das BeeGFS-Dateisystem konfiguriert, was insgesamt 32 STS im gesamten Dateisystem zur Folge hat.

Jedes ME4084-Array hat 84-Laufwerke, wobei die Laufwerke 0-41 in der oberen Schublade und die nummerierten 42-84 in der unteren Schublade nummeriert sind.  In Abbildung 5 repräsentiert jede Gruppe von 10 Laufwerken, die 1 bis 8 markiert sind, die 8xRAID6-Gruppe. Ein Volume wird aus jeder RAID6-Gruppe erstellt. Die Festplatten mit der Bezeichnung "S" stehen für die globalen Spares. Abbildung 5 zeigt die Vorderansicht des Arrays nach der Konfiguration von 8 Volumes und 4 globalen Ersatz Laufwerken.

Abbildung 4 RAID 6 (8 + 2) Festplattengruppen Layout auf einem ME4084 

Zurück zum Anfang

Client Dienst

Das BeeGFS-Client Modul wird auf allen Hosts geladen, die Zugriff auf das BeeGFS-Dateisystem benötigt. Wenn das BeeGFS-Modul geladen und der BeeGFS-Client-Service gestartet wird, mountet der Service die Dateisysteme, die in der Datei/etc/BeeGFS/beegfs-Mounts. conf definiert sind, anstelle des üblichen Ansatzes basierend auf /etc/fstab.  Mit diesem Ansatz beginnt der beegfs-Client wie jeder andere Linux Service über das Startskript des Dienstes und aktiviert die automatische Neukompilierung des beegfs-Client Moduls nach Systemaktualisierungen.

Zurück zum Anfang

Performance-Bewertung

In diesem Abschnitt werden die Performancemerkmale der Dell EMC Ready Solutions für HPC BeeGFS-Speicherlösung mit hoher Kapazität unter Verwendung der IOzone sequenziellen und zufälligen Benchmarks dargestellt.  Für weitere Performance-Charakterisierung mithilfe von IOR und MDtest sowie Details bezüglich der Konfiguration von hoher Verfügbarkeit suchen Sie nach einem Whitepaper, das später veröffentlicht wird.

Die Speicherperformance wurde unter Verwendung des IOzone-Benchmarks (v 3.487) ausgewertet. Es wurden die sequenziellen Lese-und Schreib-Durchsatzdaten und die zufälligen Lese-und Schreib IOPS gemessen. Tabelle 2 beschreibt die Konfiguration der PowerEdge R840-Server, die für diese Leistungsstudien als BeeGFS-Clients verwendet werden.

Tabelle 2 Client Konfiguration

Die-Server und-Clients sind über ein HDR100-Netzwerk und die in Tabelle 3 angegebenen Netzwerkdetails verbunden:  

Tabelle 3: Netzwerkbetrieb
 

Sequenzielle Lese-und Schreibvorgänge N-n

Die sequenziellen Lese-und Schreibvorgänge wurden mit dem sequenziellen Lese-und Schreibmodus von IOzone gemessen. Diese Tests wurden mit verschiedenen Threadanzahlen durchgeführt, beginnend mit einem Thread und Erhöhungen um die Potenzen von 2, bis zu 512 Threads. Bei jeder Threadanzahl wurde eine entsprechende Anzahl von Dateien generiert, da dieser Test auf eine Datei pro Thread oder den N-N-Fall ausgelegt ist. Die Prozesse wurden in Roundrobin-Form auf 8 physische Client-Nodes verteilt, sodass die Anforderungen gleichmäßig mit Lastenausgleich verteilt wurden.

Bei Thread-Anzahl 16 und höher wurde eine aggregierte Dateigröße von 8 TB ausgewählt, um die Auswirkungen von Caching auf die Server und BeeGFS-Clients zu minimieren. Für die Threadanzahl unter 16 beträgt die Dateigröße 768 GB pro Thread (d. h. 1,5 TB für 2 Threads, 3TB für 4 Threads und 6 TB für 8 Threads). Innerhalb eines bestimmten Tests wurde die verwendete aggregierte Dateigröße gleichmäßig auf die Anzahl der Threads aufgeteilt. Für alle Ausführungen wurde eine Datensatzgröße von 1MiB verwendet. Der Befehl, der für sequenzielle N-n-Tests verwendet wird, ist unten angegeben:

Sequenzielle Schreibvorgänge und Lesevorgänge: IOzone-i $Test-c-e-w-r 1M-s $size-t $Thread-+ n-+ m/path/to/threadlist

BS-Caches wurden auf den Servern zwischen den Iterationen sowie zwischen Schreib-und Lese Tests durch Ausführen des Befehls verworfen:

# Sync & & Echo 3 >/proc/sys/VM/drop_caches

Das Dateisystem wurde unmountet und auf den Clients zwischen den Iterationen und zwischen Schreib-und Lese Tests erneut bereitgestellt, um den Cache zu löschen.

Abbildung 5 n-N sequenzielle Performance

Zurück zum Anfang

Zufällige Lese-und Schreibvorgänge n-n

IOzone wurde im zufälligen Modus verwendet, um die zufällige IO-Leistung zu bewerten.  Es wurden Tests für die Threadanzahl von 16 bis 512 Threads durchgeführt.  Die direkte IO-Option (-I) wurde zum Ausführen von IOzone verwendet, sodass alle Vorgänge den Puffercache umgehen und direkt zur Festplatte wechseln. BeeGFS-Stripe-Zählwert von 1 und Blockgröße von 1 MB wurde verwendet. Die Größe der Anforderung wurde auf 4KiB festgelegt. Die Performance wurde in den I/O-Vorgängen pro Sekunde (IOPS) gemessen. Die BS-Caches wurden zwischen den Ausführungen auf den BeeGFS-Servern abgelegt. Das Dateisystem wurde unmountet und auf Clients zwischen Iterationen des Tests erneut bereitgestellt. Der Befehl für zufällige Lese-und Schreibtests lautet wie folgt:

IOzone-i 2-w-c-O-i-r 4K-s $size-t $Thread-+ n-+ m/path/to/threadlist

Abbildung 6n-N zufällige Leistung

Abbildung 6 zeigt, dass die Schreib Performance um 31K IOPS erreicht und von 32-Threads zu 512-Threads stabil bleibt. Im Gegensatz dazu nimmt die Leseperformance mit der Erhöhung der Anzahl der IO-Anforderungen mit einer maximalen Performance von rund 47K IOPS bei 512-Threads zu, was die maximale Anzahl der für die Lösung getesteten Threads ist. ME4 erfordert eine höhere Warteschlangentiefe, um die maximale Leseleistung zu erreichen, und das Diagramm weist darauf hin, dass wir eine höhere Leistung erzielen können, wenn wir die gleichzeitigen 1024-Threads ausführen. Da die Tests jedoch nur mit 8 Clients ausgeführt wurden, hatten wir nicht genügend Kerne, um die 1024-Thread-Anzahl auszuführen.


Zurück nach oben

Verwendete Tuning-Parameter

Die folgenden Optimierungsparameter waren bei der Durchführung der Performance Charakterisierung der Lösung vorhanden.

Die standardmäßige Stripe-Anzahl für BeeGFS ist 4. Allerdings können die Blockgröße und die Anzahl der Ziele pro Datei (Stipe-Anzahl) für jedes Verzeichnis oder jede Datei konfiguriert werden. Für alle diese Tests wurde die BeeGFS-Stripe-Größe auf 1 MB und die Stripe-Anzahl auf 1 festgelegt, wie unten dargestellt:

$beegfs-CTL--getentryinfo--mount =/mnt/beegfs//mnt/beegfs/Benchmark/--Verbose
Eintragstyp: Verzeichnis Eingabename
: 1-5E72FAD3-1
Parent
-ID: root Metadata Node: metaa-numa0-1 [ID: 1]
Stripe musterdetails:
+ Type: RAID-0
+ ChunkSize: 1M
+ Anzahl der Speicherziele: erwünscht: 1
+ Speicher Pool: 1 (Standard)
Inode-Hash-Pfad: 61/4C/1 – 5E72FAD3-1

Die transparenten Riesen Seiten wurden deaktiviert und die folgenden Einstellungen für virtuellen Speicher wurden auf den Metadaten und Speicher Servern konfiguriert:

• VM.dirty_background_ratio = 5
• VM.dirty_ratio = 20
• VM.min_free_kbytes = 262144
• VM.vfs_cache_pressure = 50

Die folgenden Optimierungsoptionen wurden für die Speicherblock Geräte auf den Speicher Servern verwendet.

• IO Scheduler Deadline: Deadline
• Anzahl der planbare-Anforderungen: 2048:
• Maximale Anzahl der voraus gelesenen Daten: 4096

Zusätzlich zu den oben genannten sind die folgenden BeeGFS-spezifischen Tuning-Optionen verwendet worden:
 
beegfs-Meta. conf

connMaxInternodeNum = 64
tuneNumWorkers = 12
tuneUsePerUserMsgQueues = true # optionale
tuneTargetChooser = Roundrobin (Benchmarking)

beegfs-Storage. conf

connMaxInternodeNum = 64
tuneNumWorkers = 12
tuneUsePerTargetWorkers = true
tuneUsePerUserMsgQueues = true # optional
tuneBindToNumaZone = 0
tuneFileReadAheadSize = 2M

beegfs-Client. conf

connMaxInternodeNum = 24
connBufSize = 720896

Zurück zum Anfang

Fazit und zukünftige arbeiten

In diesem Blog wird die Veröffentlichung von Dell EMC BeeGFS-Speicherlösung mit hoher Kapazität angekündigt und ihre Performancemerkmale hervorgehoben. Diese Lösung bietet eine Spitzenperformance von 23,7 Gbit/s für Lesevorgänge und 22,1 GB/s für Schreibvorgänge mit sequenziellen IOzone-Benchmarks. Wir sehen außerdem die RANDOM Writes Peak bei 31.3 k IOPS und zufällige Lesevorgänge bei 47,5 k IOPS.

Im Rahmen der nächsten Schritte werden wir die metadatenleistung und n-Threads in einer einzigen Datei (n bis 1) IOR-Leistung dieser Lösung evaluieren. Ein Whitepaper mit einer Beschreibung der Metadaten und der IOR-Performance der Lösung mit zusätzlichen Details bezüglich der Entwurfsüberlegungen für diese Lösung mit hoher Kapazität mit hoher Verfügbarkeit wird voraussichtlich nach Abschluss des Validierungs-und Evaluierungsprozesses veröffentlicht.

Zurück zum Anfang