PowerEdge: Dell Ready Solutions für HPC-BeeGFS-High-Performance-Storage

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

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

Das Dell HPC-Team kündigt stolz die Veröffentlichung von "Dell EMC Ready Solutions for HPC BeeGFS Storage" an, der neuesten Ergänzung des HPC-Storage-Portfolios. Diese Lösung verwendet R740xd-Server mit jeweils 24 Intel P4600 1,6 TB NVMe, gemischt genutzten Express Flash-Festplatten und zwei Mellanox ConnectX-5 InfiniBand EDR-Adaptern. In dieser Konfiguration mit 24 NVMe-Laufwerken werden 12 NVMe-SSDs an einen PCIe-Switch angeschlossen und jeder Switch ist über eine x16-PCIe-Erweiterungskarte mit einer CPU verbunden. Darüber hinaus ist jede IB-Schnittstelle mit einer CPU verbunden. Eine derart ausgewogene Konfiguration, bei der jede CPU mit einem InfiniBand-Adapter verbunden ist und 12 NVMe-SSDs verarbeitet, bietet maximale Leistung, da sichergestellt wird, dass die Prozessoren gleichermaßen mit der Verarbeitung von I/O-Anforderungen zu und von den NVMe-Laufwerken belegt sind.

Der Schwerpunkt der Lösung liegt auf Hochleistungs-I/O, und sie wurde als Hochgeschwindigkeits-Scratch-Lösung entwickelt. Der Kern der Lösung ist die Verwendung von Hochgeschwindigkeits-NVMe-SSDs, die eine hohe Bandbreite und niedrige Latenz bieten, indem sie Scheduler- und Warteschlangenengpässe aus der Blockschicht entfernen. Das BeeGFS-Dateisystem unterstützt auch einen hohen aggregierten I/O-Durchsatz.

Lösungsreferenzarchitektur

Abbildung 1 zeigt die Referenzarchitektur der Lösung. Der Managementserver ist nur über Ethernet mit den Metadaten- und Speicherservern verbunden. Jeder Metadaten- und Speicherserver verfügt über zwei InfiniBand-Links und ist über Ethernet mit dem privaten Netzwerk verbunden. Die Clients verfügen über eine InfiniBand-Verbindung und sind über Ethernet mit der privaten Schnittstelle verbunden.

Abbildung 1:  Dell Ready Solutions für HPC BeeGFS-Storage – Referenzarchitektur

Hardware- und Softwarekonfiguration

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

Details zur Lösungskonfiguration

Die BeeGFS-Architektur besteht aus vier Hauptservices:

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

Mit Ausnahme des Clientservice, der ein Kernel-Modul ist, sind die Management-, Metadaten- und Storage-Services Nutzerspeicherprozesse. Abbildung 2 zeigt, wie die Referenzarchitektur von Dell EMC Ready Solutions for HPC BeeGFS Storage der allgemeinen Architektur des BeeGFS-Dateisystems zugeordnet ist.

Abbildung 2:  BeeGFS-Dateisystem auf PowerEdge R740xd mit NVMe-SSDs

Management-Service

Jedes BeeGFS-Dateisystem oder jeder Namespace verfügt nur über einen Managementservice. Der Managementservice ist der erste Service, der eingerichtet werden muss, denn wenn wir alle anderen Services konfigurieren, müssen sie sich beim Managementservice registrieren. Ein PowerEdge R640 wird als Managementserver verwendet. Neben dem Hosten des Managementservices (beegfs-mgmtd.service) wird auch der Monitoringservice (beegfs-mon.service) gehostet, der Statistiken vom System erfasst und NutzerInnen mithilfe der Zeitreihendatenbank InfluxDB bereitstellt. Zur Visualisierung von Daten bietet beegfs-mon vordefinierte Grafana-Bereiche, die sofort verwendet werden können. Der Managementserver verfügt über 6-mal 300-GB-HDDs, die in RAID 10 für das Betriebssystem und die InfluxDB konfiguriert sind.

Metadatenservice

Der Metadatenservice ist ein Scale-out-Service, was bedeutet, dass es viele Metadatenservices in einem BeeGFS-Dateisystem geben kann. Allerdings verfügt jeder Metadatenservice über genau ein Metadatenziel zum Speichern von Metadaten. Auf dem Metadatenziel erstellt BeeGFS eine Metadatendatei pro vom Nutzer erstellter Datei. BeeGFS-Metadaten werden pro Verzeichnis verteilt. Der Metadatenservice stellt die Daten-Striping-Informationen für die Clients bereit und ist nicht am Datenzugriff zwischen Öffnen/Schließen der Datei beteiligt.

Ein PowerEdge R740xd mit 24 Laufwerken vom Typ Intel P4600 1,6 TB NVMe wird als Metadaten-Storage verwendet. Da die Speicherkapazitätsanforderungen für BeeGFS-Metadaten sehr gering sind, wurden anstelle eines dedizierten Metadatenservers nur die 12 Laufwerkein NUMA-Zone 0 zum Hosten der Metadaten-T-Argets (MDTs) und die verbleibenden 12 Laufwerke auf Host-S-torage-T-Argets (STs) in der NUMA-Zone verwendet.

Abbildung 3 zeigt den Metadatenserver. Die 12 Laufwerke im gelben Rechteck sind die MDTs in der NUMA-Zone 0, während die 12 Laufwerke im grünen Rechteck die STs in der NUMA-Zone 1 sind. Diese Konfiguration vermeidet nicht nur NUMA-Probleme, sondern bietet auch genügend Metadaten-Storage, um die Skalierung der Kapazität und Performance nach Bedarf zu erleichtern.

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.

Abbildung 4:  Konfiguration von Laufwerken im Metadatenserver

Die 12 für Metadaten verwendeten Laufwerke werden als 6x RAID 1-Laufwerksgruppe mit jeweils zwei Laufwerken konfiguriert, die jeweils als MDT dienen. Es werden sechs Metadatenservices ausgeführt, von denen jeder ein MDT verarbeitet. Die verbleibenden 12 Speicherlaufwerke werden in 3x RAID 0-Laufwerksgruppen mit jeweils vier Laufwerken konfiguriert. Es werden drei Storage-Services in der NUMA-Zone 1 ausgeführt, ein Service für jedes ST. Der Server, der die Metadaten und Storage Targets gemeinsam hostet, verfügt über 6 MDTs und 3 STs. Außerdem werden sechs Metadatendienste und drei Speicherdienste ausgeführt. Jedes MDT ist ein ext4-Dateisystem, das auf einer RAID-1-Konfiguration basiert. Die STs basieren auf einem in RAID 0 konfigurierten XFS-Dateisystem.
 

Storage-Service

Wie der Metadatenservice ist auch der Storage-Service ein Scale-out-Service. Es können viele Instanzen des Storage-Services in einem BeeGFS-Dateisystem vorhanden sein. Im Gegensatz zum Metadatenservice können jedoch mehrere Storage Targets pro Storage-Service vorhanden sein. Der Storage-Service speichert die Nutzerdateiinhalte in Striping-Dateien, die auch als Datenblockdateien bezeichnet werden.

Abbildung 5 zeigt die 5 PowerEdge R740xd-Server, die als Speicherserver verwendet werden.

Abbildung 5:  Dedizierte Speicherserver

Jeder Speicherserver ist mit 6 RAID 0-Gruppen mit jeweils vier Laufwerken konfiguriert und beherbergt somit 6 STs pro Server (3 pro NUMA-Zone), wie in Abbildung 6 unten dargestellt:

Abbildung 6:  Konfiguration von Laufwerken in den Speicherservern

Insgesamt hostet die Basiskonfiguration der Referenzarchitektur 6 MDTs und 33 STs. Fünf dedizierte Storage-Server bieten eine Rohkapazität von 211 TB und eine nutzbare Kapazität von 190 TiB. Die geschätzte nutzbare Kapazität in TiB = Anzahl der Laufwerke x Kapazität pro Laufwerk in TB x 0,99 (Dateisystemoverhead) x (10^12/2^40). Dies wäre ideal als Midrange-Scratch-Lösung mit genügend Metadaten-Storage, um das Hinzufügen von mehr Storage-Servern zu erleichtern, wenn die Kapazitätsanforderungen steigen.

Angesichts der folgenden Faktoren wurde eine RAID-0-Konfiguration für Speicherziele statt einer RAID-10-Konfiguration ausgewählt.

1. Die Schreibleistung wurde mithilfe des dd-Befehls gemessen, indem eine 10-GB-Datei mit einer Blockgröße von 1 MB und direkter I/O für Daten erstellt wurde. Bei RAID 0-Geräten lag der Durchschnitt bei etwa 5,1 GB/s pro Gerät, während der Durchschnitt bei RAID 10-Geräten bei 3,4 GB/s für jedes Gerät lag.
2. Benchmarktests von StorageBench zeigten, dass der maximale Durchsatz bei der RAID 0-Konfiguration bei 5,5 GB/s lag, während er bei einer RAID 10-Konfiguration bei 3,4 GB/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 Geschwindigkeitssteigerungen, die am besten in einer RAID 0-Konfiguration verwendet werden

Client-Service

Das BeeGFS-Clientmodul muss auf alle Hosts geladen werden, die auf das BeeGFSs-Dateisystem zugreifen müssen. Wenn der beegfs-Client geladen wird, mountet er die Dateisysteme, die in der Datei/etc/beegfs/beegfs-mounts.conf definiert sind, anstelle des üblichen Ansatzes, der auf /etc/fstab basiert. Durch die Einführung dieses Ansatzes wird der beegfs-client wie jeder andere Linux-Service über das Servicestartskript gestartet. Dies ermöglicht auch die automatische Neukompilierung des BeeGFS-Clientmoduls nach Systemupdates. 

Wenn das Clientmodul geladen wird, mountet es die Dateisysteme, die in beegfs-mounts.conf definiert sind. Es ist möglich, mehrere Beegfs-Instanzen auf demselben Client einzuhängen, wie unten gezeigt:

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

Das obige Beispiel zeigt zwei verschiedene Dateisysteme, die auf demselben Client eingehängt sind. Für diese Tests wurden 32 C6420-Nodes als Clients verwendet.

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

In der Konfiguration mit 24 NVMe des PowerEdge R740xd-Servers gibt es zwei x16-NVMe-Bridge-Karten, die den PCIe-Switch auf der Rückwandplatine versorgen, der eine Verbindung zur Vorderseite hat und die Laufwerke (es sind 4 Laufwerke) dort speist, wie in Abbildung 7 unten dargestellt:


Abbildung 7:  R740xd, 24 NVMe – Details zur CPU-Zuordnung

In NUMA (Non-Uniform Memory Access) wird der Systemspeicher in Zonen unterteilt, die als Nodes bezeichnet werden und CPUs oder Sockeln zugewiesen sind. Der Zugriff auf den lokalen Arbeitsspeicher einer CPU ist schneller als der Arbeitsspeicher, der mit Remote-CPUs auf dem System verbunden ist. Eine Thread-Anwendung ist in der Regel am besten geeignet, wenn die Threads auf den Arbeitsspeicher auf demselben NUMA-Node zugreifen. Die Auswirkungen von NUMA-Fehlern auf die Performance sind erheblich, in der Regel beginnend mit Leistungseinbußen von 10 % oder mehr. Um die Performance zu verbessern, sind die Services so konfiguriert, dass sie bestimmte NUMA-Zonen verwenden, um eine unnötige Verwendung von UPI-übergreifenden Verbindungen zu vermeiden, wodurch die Latenz verringert wird. Jede NUMA-Zone verarbeitet 12 Laufwerke und verwendet eine der beiden InfiniBand-EDR-Schnittstellen auf den Servern. Diese NUMA-Trennung wird durch die manuelle Konfiguration des NUMA-Load-Balancings durch Erstellen von benutzerdefinierten systemd-Einheitsdateien und durch die Konfiguration von Multihoming erreicht. Daher ist der automatische NUMA-Ausgleich deaktiviert, wie unten dargestellt:

# cat /proc/sys/kernel/numa_balancing
0

Abbildung 8 zeigt die Testumgebung, in der die InfiniBand-Verbindungen zur NUMA-Zone hervorgehoben sind. Jeder Server verfügt über zwei IP-Links, und der Datenverkehr über die NUMA 0-Zone wird über die Schnittstelle IB0 weitergeleitet, während der Datenverkehr über die NUMA 1-Zone über die Schnittstelle IB1 verarbeitet wird.

Abbildung 8:  Testumgebungskonfiguration
 

Performance-Charakterisierung

In diesem Abschnitt wird die Leistungsbewertung vorgestellt, die zur Charakterisierung der Dell EMC Ready Solution für HPC BeeGFS High-performance Storage Solution beiträgt. Weitere Details und Updates finden Sie in einem Whitepaper, das später veröffentlicht wird. Die Systemperformance wurde mithilfe des IOzone-Benchmarks bewertet. Die Lösung wird auf sequenziellen Lese- und Schreibdurchsatz und zufällige Lese- und Schreib-IOPS getestet. Tabelle 4 beschreibt die Konfiguration der C6420-Server, die als BeeGFS-Clients für die Performancestudien in diesem Blog verwendet wurden.
 

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 für mehrere Threads durchgeführt, beginnend bei einem Thread und über Potenzen von 2 bis hin 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 Zwischenspeicherns von den Servern und 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 für jeden Durchlauf eine Datensatzgröße von 1 MB 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 Clientknoten zwischen Iterationen und zwischen Schreib- und Lesetests gelöscht oder bereinigt, indem der folgende 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 Size auf 2 MB und die Stripe-Anzahl auf 3 festgelegt, 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 pattern details:
+ Type: 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: 

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

Abbildung 9:  Sequenzielle aggregierte IOzone-Dateigröße von 8 TB.

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 Speicherserver im Setup. 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 bis zu acht Threads haben wir acht Clients, die acht Dateien über 24 Ziele schreiben, was bedeutet, dass nicht alle Storage-Ziele vollständig genutzt werden. Wir haben 33 Storage-Ziele im System und daher sind mindestens 11 Threads erforderlich, um alle Server vollständig zu nutzen. Die Leseleistung registriert einen stetigen linearen Anstieg mit der Zunahme der Anzahl gleichzeitiger Threads, und wir beobachten eine fast ähnliche Leistung 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 an 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 Leseanforderung ausgegeben wird, und der Zeit, die der Completer benötigt, um die Daten zurückzugeben, ab. 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 Betriebssystemcaches wurden zwischen den Ausführungen auf den BeeGFS-Servern und BeeGFS-Clients gelöscht. Der Befehl, der für die Durchfü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:  Performance bei zufälligen Lese- und Schreibvorgängen mit IOzone mit einer aggregierten Dateigröße

von 8 TB.Die zufälligen Schreibvorgänge erreichten einen Spitzenwert von ~3,6 Millionen IOPS bei 512 Threads und die zufälligen Lesevorgänge einen Spitzenwert von ~3,5 Millionen IOPS bei 1024 Threads, wie in Abbildung 10 dargestellt. 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, weshalb wir IOPS von über 3 Millionen beobachten.

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 erläutert und die Verwendung von "StorageBench", der Benchmark für integrierte Storage-Ziele von BeeGFS, hervorgehoben.

Im Rahmen der nächsten Schritte werden wir später ein Whitepaper veröffentlichen, in dem die Metadatenleistung und die IOR-Leistung von N Threads für eine Datei sowie zusätzliche Details zu Designüberlegungen, Tuning und Konfiguration aufgeführt sind.

Referenzen

[1] BeeGFS-Dokumentation:  https://www.beegfs.io/wiki/
[2] So verbinden Sie zwei Schnittstellen mit demselben Subnetz:  https://access.redhat.com/solutions/30564