Heute schnell, bereit für morgen: QSAN XN4226D Unified Storage

QSAN entwickelt seit 2004 Enterprise-Speicherlösungen, und diese Erfahrung spiegelt sich in der XN4-Reihe wider. Das XN4226D in unserem Labor ist ein 2HE-Array mit 26 Einschüben und reinem NVMe-Speicher mit zwei aktiven Controllern, das als einheitlicher Block- und Dateispeicher hohe Verfügbarkeit bietet. Die QSM 4-Software bietet die erwarteten Datendienste, darunter Snapshots, Replikationsoptionen, Datenreduzierung und eine unkomplizierte Verwaltung. Das XN4 ist für Teams konzipiert, die NVMe-Geschwindigkeit ohne Kompromisse bei der Multiprotokoll-Flexibilität suchen – und das zu einem sehr erschwinglichen Preis.

Wichtige Erkenntnisse

• Einheitlicher Block und Datei mit echtem HA. Duale aktive Controller und QSM 4 bieten hohe Verfügbarkeit mit einer Plattform für Block und Datei.
• NVMe-oF richtig gemacht. Vollständige Protokollverteilung mit NVMe-oF über TCP und RDMA neben iSCSI, Fibre Channel, NFS, SMB, FTP und WebDAV.
• Bewährter Durchsatz. Wir haben bis zu 21.21 GB/s bei großen sequentiellen Lesevorgängen mit TCP und 11.14 GB/s bei großen sequentiellen Schreibvorgängen mit RDMA gemessen.
• Gebaut für moderne Pipelines. 26 reine NVMe-Schächte in 2 HE, einfache Verwaltung und E/A-Optionen, die auf 100–200 GbE für Medien, Überwachungsanalysen, VDI, Datenbanken und KI-Inferenz skalierbar sind.

Die Plattform unterstützt NVMe-oF über TCP und RDMA sowie iSCSI, Fibre Channel, NFS, SMB, FTP und WebDAV. Wir haben außerdem eine gezielte NVMe-oF-Studie durchgeführt, in der wir das Verhalten und die Skalierung von TCP und RDMA verglichen haben. Bei unseren Tests haben wir das Gerät mit großen sequenziellen Lesevorgängen an seine Grenzen gebracht und einen beeindruckenden Durchsatz von 21.21 GB/s erreicht. Wo dieses System hinpasst, ist genauso wichtig wie die reinen Zahlen. Das XN4226D bedient gemischte Umgebungen, die VMware oder Proxmox für VMs, VDI und Datenbankebenen kombinieren, sowie kreative Dateidienste, KI-Inferenzknoten, die vorhersehbare NVMe-Pfade erfordern, Mediensicherungen und bandbreitenintensive Ingestion für Überwachungs- und Sensor-Workloads. Das QSAN XN4226D eignet sich für nahezu jede Arbeitslast.

QSAN verzeichnet ein deutliches Wachstum in der Medienproduktion, darunter Live-Übertragungen, Wiedergabeoptionen, KI-Videooptimierung und OTT/Edge-Caching, sowie in der Überwachungsvideoanalyse, beispielsweise für Smart-City-Videoüberwachung, Anomalieerkennung und Echtzeitwiedergabe. Diese Workloads werden optimal mit einem Durchsatz von 100–200 GbE unterstützt.

Der Nutzen ist klar: Sie erhalten einheitliche Hochverfügbarkeit, NVMe im gesamten Gehäuse und I/O-Optionen bis zu 100 GbE oder 32 Gb Fibre Channel bei steigendem Bedarf. Die Leistung entspricht der vieler Tier-1-Arrays, während die Lizenzierung weiterhin günstiger ist und die Protokollabdeckung mit NVMe-oF, iSCSI, Fibre Channel, SMB und NFS breit gefächert bleibt. Für Unternehmen, die InfiniBand ins Auge fassen, aber über ein begrenztes Budget verfügen, bietet der Ethernet-Ansatz von QSAN eine nahezu IB-Reaktionsfähigkeit auf Standardgeräten im Bereich von 100 bis 200 GbE.

Für Teams, die Wert auf reale Anwendungsergebnisse legen, machen die Langlebigkeit, die intuitive Software und das saubere Hardwaredesign von QSAN den XN4226D zu einem zuverlässigen All-Flash-Arbeitstier, auf dem man aufbauen kann.

QSAN XN4-Hardware

Die Speicher-Arrays der QSAN XN4-Serie sind in einem 26-Bay-, 2HE- und 19-Zoll-Rack-kompatiblen Servergehäuse erhältlich. Mit Einzel- oder Dual-Controller-Optionen und 4- oder 8-Core-Intel-Xeon-CPUs erfüllen sie die Redundanz- und Leistungsanforderungen kleinster und größter Unternehmen. Bei Belegung aller 26 Schächte kann ein einzelnes Gehäuse der XN4-Serie bis zu 798 Terabyte Daten auf 2.5-Zoll-U.2/U.3-NVMe-Solid-State-Laufwerken speichern. Bis zu 20 SAS-Erweiterungseinheiten können hinzugefügt werden, wodurch die Gesamtkapazität eines Arrays auf satte 16.773 Petabyte erhöht wird.

Jeder Controller verfügt über einen 2.5-Gbit/s-RJ45-Ethernet-Port, vier 10-Gbit/s-SFP+-Ports und zwei 12-Gbit/s-SAS-Wide-Ports. Es gibt außerdem Upgrade-Optionen für 10-Gbit/s-RJ45-, 25-Gbit/s-SFP28- und 100-Gbit/s-QSFP-Ports. Fibre-Channel-Unterstützung kann ebenfalls mit 16-Gbit/s-SFP+- und 32-Gbit/s-SFP28-Adaptern hinzugefügt werden.

Die folgende Tabelle vergleicht die Spezifikationen der Speichersysteme XN4226D-4C und XN4226S-4C. Es handelt sich um die 4C-Varianten, die je nach Modell entweder mit Dual-Active- oder Single-Upgrade-Controllern ausgestattet sind. Für Implementierungen, die mehr Rechenleistung erfordern, ist auch eine 8C-Version dieser Systeme erhältlich.

Normen	XN4226D-4C	XN4226S-4C
Modell	XN4226D-4C	XN4226S-4C
Architektur	Dual-Active-Controller	Einzeln aufrüstbarer Controller
CPU	Intel® Xeon® 4-Core × 2	Intel® Xeon® 4-Core
Memory
Speichermodul vorinstalliert	32 GB DDR4 RDIMM	16 GB DDR4 RDIMM
Gesamtzahl der Speichersteckplätze	16	8
Speicher erweiterbar auf bis zu	2,048GB	1,024GB
Lagerung
Laufwerkseinschübe	2.5″ Steckplatz × 26	2.5″ Steckplatz × 26
Maximale Laufwerksschächte mit Erweiterungseinheit	546	546
Kompatibler Laufwerkstyp	2.5″ Dual-Port U.2 / U.3 NVMe SSD 2.5″ SAS SSD (für Erweiterungseinheiten) 3.5″ SAS HDD (für Erweiterungseinheiten)	2.5″ Single-Port U.2 / U.3 NVMe SSD 2.5″ SAS SSD (für Erweiterungseinheiten) 3.5″ SAS HDD (für Erweiterungseinheiten)
Antriebsschnittstelle	U.2 NVMe (PCIe Gen 4) SAS 12 Gb/s (für Erweiterungseinheiten)	U.2 NVMe (PCIe Gen 4) SAS 12 Gb/s (für Erweiterungseinheiten)
Maximale interne Rohkapazität	798TB	798TB
Maximale Rohkapazität mit Erweiterung	16,773TB	16,773TB
Hot-Swap-fähiges Laufwerk	Ja	Ja
Konnektivitätsport
PCIe-Erweiterung	(Gen 4×8-Steckplatz) × 4	(Gen 4×8-Steckplatz) × 2
2.5 GbE RJ45 LAN-Anschluss	2 (an Bord)	1 (an Bord)
10 GbE SFP+ LAN-Port	8 (integriert) / 16 (Option)	4 (integriert) / 8 (Option)
10 GbE RJ45 LAN-Anschluss	16 (Option)	8 (Option)
25 GbE SFP28 LAN-Port	16 (Option)	8 (Option)
100 GbE QSFP-LAN-Port	8 (Option)	4 (Option)
16 Gb SFP+ Fibre Channel	16 (Option)	8 (Option)
32 Gb SFP28 Fibre Channel	16 (Option)	8 (Option)
Erweiterung und externer Port
12 Gb/s SAS Wide Port	4 (an Bord)	2 (an Bord)
USB-Anschluss	1 (vorne) / 2 (hinten)	1 (vorne) / 1 (hinten)
Sonstiges	Konsolenport × 2, Serviceport × 2	Konsolenport × 1, Serviceport × 1
Software-Spezifikation
Speicherbetriebssystem	QSM 4	QSM 4
RAID-Typ	0 / 1 / 5 / 6 / 10 / 50 / 60 / 5EE / 6EE / 50EE / 60EE
Speichereffizienz	Thin Provisioning / Komprimierung und Deduplizierung (Option)
Softwarebeschleunigung	SSD-Cache / Auto-Tiering / RDMA
Datenschutz	Snapshot / Asynchron / Synchron (Option)
Sicherungsdienst	Rsync / S3-Backup / Cloud-Backup / XMirror* / Microsoft 365-E-Mail-Backup
Sicherheit	SSL / SSH / iSCSI CHAP / ISE & SED / WORM / RBAC / Windows ACL / Antivirus
Unterstützungsprotokolle	CIFS / NFS / FTP / WebDAV / iSCSI / FCP / NVMe-oF
Verwaltung	Web-UI / Windows AD / LDAP / RESTful API / SES / LCM
Aussehen
Abmessungen (H × B × T)	88 × 438 × 573mm	88 × 438 × 573mm
Nettogewicht	19.6 kg	16.5 kg
Bruttogewicht	28.6 kg	25.5 kg
Sonstiges
Speicherschutz	Cache-to-Flash-Modul (integriert)
Systemlüfter	8	4
Netzteil	850 W × 2 (80 Plus Platin)
Strom	100 - 240 VAC, 50/60 Hz
Energieverbrauch	812 W / 2,770 BTU
Zertifizierungsanforderungen	CE / FCC / BSMI
Standard-Garantie	System: 5 Jahre | Cache-to-Flash-Modul: 1 Jahr

QSAN XN4-Funktionen

XN4-Arrays sind standardmäßig mit den neuesten Verbindungsprotokollen ausgestattet, die für die Unterstützung von Hochleistungsrechnern und datenintensiven KI-Modellen erforderlich sind, einschließlich NVMe over Fabrics (NVMe-oF), bereitgestellt über TCP und RDMA. Verbindungen über iSCSI, NFS, FCP, CIFS/SMB, FTP und WebDAV sind ebenfalls möglich. Dadurch erfüllt das Array die Anforderungen von Rechenzentren mit einer Mischung aus Legacy- und hochmodernen Systemen an Block- und Dateispeicher.

Die Vorteile von NVMe-oF

Während Protokolle wie iSCSI, NFS und FCP in Enterprise-Speicheranwendungen noch weit verbreitet sind, bietet NVMe-oF deutliche Verbesserungen bei der Latenz. NVMe-Standards wurden von Grund auf für Solid-State-Laufwerke entwickelt, die direkt an den PCIe-Bus eines Systems angeschlossen werden. Ältere Protokolle wie iSCSI und NFS hingegen wurden aufgrund der Einschränkungen und langsameren Zugriffszeiten herkömmlicher Festplatten entwickelt. NVMe-oF-Technologien übertreffen ältere Verbindungsprotokolle in fast allen Fällen durch höhere Bandbreite und schnellere Zugriffszeiten. NVMe-oF kann zudem Netzwerkschnittstellen mit RDMA-Funktionen (Remote Direct Memory Access) nutzen, sodass Daten ohne CPU-Belastung direkt in den Speicher eines Zielcomputers übertragen werden können.

Funktionen zur Datenreduzierung und -optimierung

Der leistungsstarke Hardware-Stack des XN4-Speicherarrays wird durch zahlreiche Softwarefunktionen erweitert, die bei Speicheradministratoren bekannt und geschätzt sind. Thin Provisioning, Komprimierung und Deduplizierung ermöglichen Unternehmen die Maximierung ihrer SAN-Kapazität, während SSD-Caching und automatisches Storage Tiering die Zugriffszeiten für häufig verwendete Dateien und Objekte beschleunigen. Das QSM 4-Betriebssystem der Appliance erleichtert zudem das Testen und Zurücksetzen von Änderungen mit integrierten Snapshot-Tools.

Sicherheits- und Verwaltungsfunktionen

QSAN berücksichtigt mit der XN4-Reihe die steigenden Sicherheits- und Verwaltungsanforderungen seiner Kunden. Die XN4-Reihe ist kompatibel mit Instant Secure Erase (ISE) und Self-Encrypting Drives (SED) sowie Sicherheitsprotokollen wie SSL/TLS, Authentifizierung über rollenbasierte Zugriffskontrolle (RBAC) und Unterstützung für Active Directory/LDAP-Server. Das Array kann über eine HTTPS-Web-UI oder eine RESTful-API verwaltet werden und ermöglicht die Automatisierung durch eine Vielzahl von Tools wie Ansible oder Terraform.

QSM 4 Management

QSM 4, das Betriebssystem der QSAN XN4-Serie, vereinfacht die Einrichtung und Verwaltung des Speicher-Arrays für Speicheradministratoren aller Erfahrungsstufen. Die Out-of-Box-Bereitstellung ist einfach: schnelle Pool-Erstellung, intuitive Host-Zuweisung und einfache Verwaltung über Web-UI und REST-APIs – alles konzipiert für kleinere IT-Teams ohne umfassende Speicherkenntnisse.

Der Dashboard-Bildschirm zeigt Systemstatusinformationen und aktuelle vom Server protokollierte Ereignisse an.

Nach der Anmeldung wird dem Benutzer das Dashboard angezeigt, das einen schnellen Überblick über den Zustand des SAN bietet. Von hier aus können Sie in jedes Untermenü der Liste im linken Bereich springen.

Über das Speichermenü können Administratoren Laufwerkspools und die zugehörigen Volumes erstellen und verwalten.

Die Datenträgergruppen, aus denen die einzelnen Pools bestehen, können auf der Registerkarte „Datenträgergruppen“ verwaltet werden. Diese Funktion unterstützt verschiedene RAID-Level, darunter 0, 1, 5, 6, 10, 50, 60, 5EE, 6EE, 50EE und 60EE, abhängig von der Anzahl der bereits zugewiesenen Laufwerke.

Auf den Pools können dann Volumes für Block- und Dateispeicherbedarf erstellt werden. Mithilfe des Assistenten können die Kapazität und Blockgröße jedes Volumes an die Anforderungen der verbundenen Clients angepasst werden.

Wenn Sie in der Liste nach unten scrollen, können Sie über das Menü „Freigaben“ ein Freigabeobjekt auf einem Dateivolume erstellen. Zu den unterstützten Freigabeprotokollen gehören CIFS (SMB), FTP, NFS und WebDAV.

Beim Erstellen einer neuen Freigabe bietet QSM 4 zwei Optionen: eine Standardnetzwerkfreigabe zum Hosten von Dateien, auf die mehrere Benutzer zugreifen, und eine Userhome-Freigabe, die für die Aufnahme von Home-Ordnern für Benutzer vorgesehen ist, auf die nur einzeln zugegriffen werden kann.

Sobald ein Block- oder Datei-Volume und eine Freigabe erstellt wurden, muss es im Menü „Hosts“ einer IP-Adresse oder einem Hostnamen zugewiesen werden. Hosts werden danach organisiert, ob sie Block- oder Dateispeicher (Freigabe) entsprechen, wie in den folgenden Screenshots gezeigt.

Hosts für Blockspeicher können iSCSI, FCP oder NVMe-oF über TCP für ein Volume nutzen. Hosts für Dateispeicher (Share) hingegen können mehrere Protokolle gleichzeitig unterstützen und bieten so wichtige Flexibilität für Rechenzentren mit unterschiedlichen Anforderungen an die Dateifreigabe.

QSM 4 bietet außerdem grundlegende Überwachungsfunktionen im Menü „Monitor“ und zeigt den Status verschiedener Hardwaremodule und Laufwerke innerhalb des Arrays sowie Statistiken zur Laufwerk-, Speicherpool-, CPU- und Speichernutzung an.

Die QSM 4-Weboberfläche bietet im Menü „Konten“ außerdem die Möglichkeit zur Benutzer-, Gruppen- und Domänenverwaltung. Darüber hinaus stehen im Menü „System“ verschiedene SAN-weite Konfigurationsoptionen zur Verfügung. Protokollierungs- und Warnfunktionen sind über das Menü „Benachrichtigungen“ zugänglich. Die Symbole für den QSAN-Dateimanager, die Sprachunterstützung und die Abmeldung/Energieverwaltung finden Sie in der oberen rechten Ecke der Menüleiste.

Einfache Proxmox-Integration

Proxmox unterstützt nativ NVMe over Fabrics (NVMe-oF) und ermöglicht so die einfache Integration leistungsstarker Speicher-Arrays in einen Cluster. Der Prozess beginnt mit der Bereitstellung von NVMe-oF-Zielen auf Ihrem Speichersystem. Anschließend ermitteln und verbinden Sie diese Ziele über den Proxmox-Host. Nach der Verbindung müssen Sie das System so konfigurieren, dass diese Verbindungen auch nach einem Neustart bestehen bleiben.

In unserem Beispiel wird die Erkennung mithilfe von Shell-Befehlen durchgeführt, die die IP-Adresse und den Service-Port des Arrays angeben.

nvme discover -t tcp -a 172.16.16.100 -s 4420
nvme discover -t tcp -a 172.13.13.100 -s 4420

Stellen Sie als Nächstes eine Verbindung zu den bereitgestellten Namespaces her, indem Sie auf deren NQNs verweisen.

nvme connect -t tcp -n nqn.2024-11.com.qsan:dev4 -a 172.16.16.100 -s 4420
nvme connect -t tcp -n nqn.2024-11.com.qsan:dev6 -a 172.13.13.100 -s 4420

Um sicherzustellen, dass die Konfiguration auch nach Neustarts erhalten bleibt, können die Erkennungsadressen an die NVMe-Erkennungskonfigurationsdatei angehängt werden.

echo "discover -t tcp -a 172.16.16.100 -s 4420" | tee -a /etc/nvme/discovery.conf
echo "discover -t tcp -a 172.13.13.100 -s 4420" | tee -a /etc/nvme/discovery.conf

Aktivieren Sie abschließend den Auto-Connect-Dienst, damit Proxmox die NVMe-Sitzungen beim Start automatisch wiederherstellt.

systemctl enable nvmf-autoconnect.service

Proxmox kann nahtlos in QSAN-Speicher integriert werden und bietet die geringe Latenz und hohe Bandbreite von NVMe sowie die Flexibilität vernetzter Fabrics.

Nachdem wir unser QSAN angeschlossen haben, können wir den Befehl „nvme list“ aus der Proxmox-Shell ausführen, um alle NVMe-Geräte anzuzeigen, wobei die neu hinzugefügten QSAN-Volumes als /dev/nvme6n1 und /dev/nvme7n1 mit jeweils 11 TB Speicher angezeigt werden.

Sobald der QSAN-Speicher in der Proxmox-GUI sichtbar ist, können wir eine neue LVM-Volume-Gruppe erstellen: pve > Disks > LVM, die beiden 11-TB-Geräte (/dev/nvme6n1 und /dev/nvme7n1) werden angezeigt und können als separate Volume-Gruppen (z. B. qsan-1 und qsan-2) zur Verwendung mit VMs und Containern initialisiert werden.

Wenn Sie im Speicherbereich auf einen unserer neuen LVM-Pools (qsan-1) klicken, wird angezeigt, dass dieser online, aktiviert und zur Verwendung verfügbar ist, über die volle Kapazität von 11 TB verfügt und für die Bereitstellung von VMs und Containern bereit ist.

Performance Testing

Wir haben den QSAN XN4226D in zwei Umgebungen auf unterschiedlichen Testplattformen getestet. Unsere erste Umgebung basierte auf einem Dell PowerEdge R750, ausgestattet mit vier NVIDIA ConnectX-5 Dual-Port 25G-Netzwerkkarten. Wir haben den QSAN XN4226D über acht DAC-Kabel direkt an diesen Server angeschlossen. Dieses Setup nutzte alle verfügbaren Netzwerkports des QSAN und ermöglichte uns, seine höchste Spitzenleistung zu demonstrieren.

Für den FIO-Test nutzten wir zwei RAID6-Speicherpools und erstellten acht Blockvolumes, die gleichmäßig auf beide Controller verteilt waren. Jedes Volume wurde einem eindeutigen Ziel zugewiesen, wobei jedem Volume eine eigene IP-Adresse zugewiesen wurde. Wir haben auf dieser Plattform sowohl NVMe-oF RDMA als auch TCP gemessen.

Die zweite Umgebung für GDSIO nutzte einen Dell PowerEdge R7715, ausgestattet mit zwei NVIDIA H100 GPUs und einer Quad-Port Broadcom 25G NIC. In dieser Umgebung behielten wir das gleiche QSAN-Volume-Layout bei, reduzierten jedoch die Anzahl der Volumes von acht auf vier. Mit einer Quad-Port NIC nutzten wir vier 25G-Verbindungen, um den Server direkt an das Speicher-Array anzuschließen.

FIO-Leistungsbenchmark

Um die Speicherleistung des QSAN XN4226D zu messen, haben wir gängige Branchenkennzahlen und das FIO-Tool verwendet. Jedes Speichergerät durchläuft denselben Testprozess. Dieser umfasst einen Vorkonditionierungsschritt mit zwei vollständigen Laufwerksfüllungen mit sequenzieller Schreiblast, gefolgt von der Messung der stationären Leistung. Bei Änderungen der gemessenen Lastart führen wir eine weitere Vorkonditionierungsfüllung mit der neuen Übertragungsgröße durch.

In diesem Abschnitt konzentrieren wir uns auf die folgenden FIO-Benchmarks:

• 1M sequentiell
•  64K zufällig
• 16K zufällig
• 4K zufällig

1M sequentielle Schreibbandbreite

Im 1M Sequential Write-Test lieferte NVMe über RDMA im Vergleich zu NVMe über TCP über nahezu alle Warteschlangentiefen und Jobanzahlen hinweg durchweg eine höhere Bandbreite. In der Spitze erreichte RDMA 11.14 GB/s, während TCP maximal 8.83 GB/s erreichte – ein Unterschied von rund 26 % zugunsten von RDMA. Selbst bei geringeren Warteschlangentiefen behielt RDMA seinen Vorsprung. Beim QD1/1-Job erreichte es beispielsweise 6.30 GB/s und übertraf damit die 4.77 GB/s von TCP um rund 32 %.

Der Leistungsunterschied zwischen den beiden Protokollen verringerte sich mit zunehmender Arbeitslast etwas, RDMA zeigte jedoch durchweg einen klaren Vorteil. TCP bewegte sich über mehrere Testpunkte hinweg konstant im Bereich von 8.5 bis 8.8 GB/s, während RDMA häufig die 10.5 GB/s-Marke überschritt und in Spitzen knapp über 11 GB/s lag.

1M sequentielle Schreiblatenz

Im Latenztest für 1M sequentielles Schreiben behielt RDMA über die meisten Warteschlangentiefen und Jobzahlen hinweg erneut einen klaren Effizienzvorteil gegenüber TCP. Bei geringerer Arbeitslast lagen die beiden Protokolle eng beieinander und zeigten beide Latenzen unter 5 ms. Mit zunehmender Parallelität wurden die Unterschiede jedoch deutlicher. Beispielsweise maß RDMA bei QD16/16-Jobs 368.48 ms, während TCP 455.95 ms erreichte – eine Verbesserung von 19 % für RDMA.

Bei extremen Skalierungen wurde die Divergenz noch deutlicher. Beim QD256/1-Job wurde RDMA nach 1,389.16 ms abgeschlossen, während TCP auf 1,987.39 ms stieg, was einer Latenzreduzierung von 43 % zugunsten von RDMA entspricht. Dieser Trend unterstreicht die Fähigkeit von RDMA, einen höheren Durchsatz aufrechtzuerhalten und gleichzeitig die Latenz unter Kontrolle zu halten, insbesondere in stark ausgelasteten Szenarien.

1M sequentielle Lesebandbreite

Im 1M Sequential Read-Test verschob sich die Leistungsdynamik: TCP übertraf RDMA auf ganzer Linie deutlich. TCP erreichte einen Spitzenwert von 21.21 GB/s, während RDMA bei 15.96 GB/s lag – ein Unterschied von rund 33 % zugunsten von TCP. Selbst bei geringeren Warteschlangentiefen konnte TCP schnell die Nase vorn behalten. Beispielsweise lieferte TCP bei QD1/4-Jobs 18.91 GB/s, verglichen mit 15.05 GB/s bei RDMA – ein Unterschied von über 25 %.

Der Vorteil von TCP war über nahezu alle Workload-Skalen hinweg konstant. Nach Erreichen der Sättigung hielt TCP die Ergebnisse im Bereich von 20–21 GB/s, während RDMA näher an 15 GB/s abflachte. Dies deutet darauf hin, dass RDMA zwar bei schreibintensiven und latenzempfindlichen Vorgängen hervorragend abschneidet, TCP jedoch mit der getesteten RAID6-NVMe-Konfiguration eine höhere Effizienz der sequentiellen Lesebandbreite aufweist.

1M sequentielle Leselatenz

Im 1M-Latenztest für sequentielles Lesen lagen die Ergebnisse der beiden Protokolle näher beieinander, obwohl RDMA bei höheren Warteschlangenlängen generell einen leichten Vorteil hatte. Bei geringerer Arbeitslast waren die Latenzprofile nahezu identisch und blieben beide unter 5 ms, bis die Parallelität zunahm. Beispielsweise erreichte TCP bei QD8/64-Jobs 234.09 ms, während RDMA mit 194.54 ms niedriger lag, was einer Reduzierung um 17 % entspricht.

Dieser Trend setzte sich bei höherer Belastung fort. Bei QD32/64-Jobs maß RDMA 847.59 ms im Vergleich zu 881.31 ms bei TCP. Dies entspricht einer geringfügigen Verbesserung von 3.8 %, entspricht aber immer noch dem geringeren Stack-Overhead von RDMA. Allerdings skalierten beide Protokolle nach einem ähnlichen Muster, wobei die Latenz mit zunehmender Arbeitslast erwartungsgemäß anstieg.

64 zufällige Schreib-IOPS

 

Im 64K Random Write-Test lieferte RDMA durchweg höhere IOPS als TCP, was seine Effizienz bei der Verarbeitung parallelisierter Zufallsoperationen unterstreicht. In der Spitze erreichte RDMA 58.89K IOPS, während TCP mit 48.57K IOPS zurückblieb, was einem Leistungsvorteil von 21 % entspricht.

Die Lücke zwischen den beiden Protokollen blieb während des gesamten Tests bestehen. Beispielsweise erreichte RDMA bei QD1/16-Jobs 54.13 IOPS, während TCP 45.30 IOPS erreichte – ein Unterschied von fast 16 %. Bei weiterer Skalierung der Arbeitslast hielt RDMA die Ergebnisse im Bereich von 53 bis 55 IOPS, während TCP einen Bereich von 42 bis 46 IOPS beibehielt.

64K zufällige Schreiblatenz

Im 64K Random Write-Latenztest zeigte RDMA erneut kürzere Reaktionszeiten als TCP, insbesondere bei steigender Warteschlangentiefe und Jobanzahl. Bei geringerer Last zeigten beide Protokolle nahezu identische Ergebnisse und blieben unter 1 ms. Beispielsweise erreichte TCP beim QD1/1-Job 0.26 ms, während RDMA mit 0.25 ms nahezu gleich blieb.

Mit zunehmender Arbeitslast behielt RDMA jedoch seinen Effizienzvorteil. Bei QD16/64-Jobs erreichte RDMA 74.09 ms, TCP 95.64 ms – ein Unterschied von rund 23 %. Unter maximaler Belastung beim QD256/1-Job vergrößerte sich die Lücke noch weiter: RDMA erreichte 291.13 ms, während TCP auf 398.56 ms stieg – fast 37 % mehr.

64K Random Read IOPS

Im 64K Random Read-Test lieferten TCP und RDMA insgesamt eine sehr ähnliche Leistung, wobei die Führung je nach Arbeitslast leicht zwischen den beiden Protokollen wechselte. TCP erreichte einen Spitzenwert von 176.33K IOPS, während RDMA mit 175.40K IOPS dicht dahinter lag und nur einen Unterschied von 0.5 % aufwies.

In mittleren Tiefen blieben die Ergebnisse eng beieinander. Beispielsweise erreichte TCP bei QD4/16-Jobs 168.60 IOPS, während RDMA mit 163.94 IOPS folgte – ein Unterschied von weniger als 2.8 %. In anderen Punkten lag RDMA leicht höher, beispielsweise bei QD8/1-Jobs, wo es 171.71 IOPS erreichte, verglichen mit TCPs 171.15 IOPS – praktisch ein Gleichstand.

64K zufällige Leselatenz

Im 64K Random Read-Latenztest lagen die beiden Protokolle sehr nah beieinander, wobei RDMA unter höherer Last einen leichten Vorteil zeigte. Bei geringer Auslastung lieferten sowohl TCP als auch RDMA Latenzen unter 1 ms, die praktisch nicht zu unterscheiden waren. Beispielsweise betrug die Latenzzeit beim QD1/1-Job für TCP 0.43 ms im Vergleich zu 0.38 ms bei RDMA.

Mit zunehmender Parallelität wurde der Unterschied deutlicher. Bei QD16/64-Jobs erreichte RDMA 23.28 ms, während TCP 26.19 ms erreichte – eine Verbesserung um 12 %. Unter maximaler Belastung vergrößerte sich die Spanne: RDMA erreichte 98.08 ms gegenüber 129.02 ms bei TCP – eine Verbesserung um 24 %.

16K Random Write IOPS

Im 16K Random Write-Test war der Leistungsunterschied zwischen den beiden Protokollen erheblich, wobei RDMA in den meisten Fällen mehr als die doppelte IOPS-Leistung von TCP lieferte. RDMA erreichte einen Spitzenwert von 111.13K IOPS, während TCP bei 68.95K IOPS lag, was einem Vorteil von 61 % für RDMA entspricht.

Bei geringeren Warteschlangentiefen war der Unterschied deutlich. Beispielsweise maß RDMA bei QD1/16-Jobs 104.86 K IOPS, verglichen mit 41.78 K IOPS bei TCP, was einer Steigerung von 151 % zugunsten von RDMA entspricht. Über den gesamten Workload-Bereich hinweg erreichte RDMA konstant Ergebnisse im Bereich von 100 K bis 111 K IOPS, während TCP im Allgemeinen im Bereich von 40 K bis 50 K IOPS blieb, abgesehen von einem späten Anstieg bei maximaler Tiefe.

16K zufällige Schreiblatenz

Im 16K Random Write-Latenztest behielt RDMA bei steigender Arbeitslast erneut einen klaren Vorteil gegenüber TCP. Bei geringerer Last waren beide Protokolle nahezu identisch, wobei die Reaktionszeiten unter 2 ms blieben. Beispielsweise betrug die Reaktionszeit beim QD1/1-Job für TCP 0.40 ms, während RDMA 0.41 ms erreichte.

Mit zunehmender Parallelität begann sich RDMA zu trennen. Bei QD16/64-Jobs erreichte RDMA 21.15 ms, während TCP 77.12 ms benötigte – eine deutliche Reduzierung um 72 %. Dieser Vorteil blieb auch in den höchsten Tiefen bestehen. Bei QD32/64-Jobs wurde RDMA nach 161.13 ms abgeschlossen, TCP hingegen nach 235.17 ms, was einer Verbesserung um 31 % entspricht.

16K Random Read IOPS

Im 16K Random Read-Test übertraf RDMA TCP über den gesamten Workload-Bereich hinweg deutlich. RDMA erreichte einen Spitzenwert von 388.44K IOPS, während TCP nur 16.42K IOPS erreichte, was einen mehr als 23-fachen Vorteil für RDMA bedeutet.

Die Diskrepanz war von Anfang an sichtbar. Beim QD1/1-Job lieferte RDMA 29.27 IOPS, während TCP nur 8.10 IOPS schaffte. Mit zunehmender Parallelität skalierte RDMA schnell in den Bereich von 300 bis 380 IOPS, während TCP selbst bei höheren Warteschlangentiefen bei etwa 15 bis 16 IOPS stagnierte.

16K zufällige Leselatenz

Im 16K Random Read-Latenztest war der Unterschied zwischen RDMA und TCP dramatisch und spiegelte die IOPS-Ergebnisse wider. Bei geringer Arbeitslast waren die beiden Protokolle nahezu identisch, mit Latenzen zwischen 1 und 10 ms.

Mit zunehmender Auslastung hielt RDMA die Latenz gut unter Kontrolle, während TCP deutlich nachließ. Bei Q8/64-Jobs maß RDMA 13.65 ms, verglichen mit 260.90 ms bei TCP – eine fast 19-fache Verbesserung. QD32/64-Jobs schlossen RDMA in 63.28 ms ab, während TCP 2,366.99 ms benötigte – fast 37-mal länger.

4K Random Write IOPS

Im 4K Random Write-Test übertraf RDMA TCP durchweg, auch wenn der Unterschied im Vergleich zu den Workloads mit größeren Blöcken geringer war. RDMA erreichte einen Spitzenwert von 125.73 K IOPS, während TCP 115.89 K IOPS erreichte, was einem Vorteil von etwa 8.5 % für RDMA entspricht.

Bei geringeren Warteschlangentiefen hinkte TCP etwas hinter RDMA zurück, lieferte aber dennoch eine konkurrenzfähige Leistung. Beispielsweise erreichte RDMA bei QD1/16-Jobs 122.82 K IOPS im Vergleich zu TCP mit 111.91 K IOPS – eine Verbesserung um fast 10 %. Über die meisten Testpunkte hinweg bewegte sich RDMA im Bereich von 120 K bis 125 K IOPS, während TCP Ergebnisse zwischen 110 K und 116 K IOPS erzielte, mit einem späten Rückgang bei QD32/64-Jobs auf 92.21 K IOPS.

4K zufällige Schreiblatenz

Im 4K Random Write-Latenztest zeigte RDMA durchweg kürzere Reaktionszeiten als TCP, wobei die Unterschiede im Vergleich zu den größeren Blocklasten geringer waren. Bei geringerer Last waren beide Protokolle nahezu identisch und blieben jeweils unter 1 ms. Beispielsweise erreichte TCP bei QD1/1 0.16 ms, während RDMA 0.21 ms erreichte.

Mit zunehmender Parallelität wurden die Unterschiede deutlicher. Bei QD16/64-Jobs erreichte RDMA 19.36 ms, verglichen mit 36.20 ms bei TCP. Dies führte zu einer Latenzreduzierung von 46 %. Bei maximaler Tiefe wurde RDMA nach 145.61 ms abgeschlossen, während TCP auf 177.62 ms stieg – eine Verbesserung von 22 % für RDMA.

4K Random Read IOPS

Im 4K Random Read-Test lieferten beide Protokolle eine starke Leistung, wobei RDMA gegenüber TCP stets einen leichten Vorsprung hatte. RDMA erreichte einen Spitzenwert von 404.64 K IOPS, während TCP bei 382.96 K IOPS lag, was RDMA einen Vorsprung von 5.7 % verschaffte.

Bei geringeren Tiefen sprachen die Ergebnisse bereits für RDMA. Beispielsweise erreichte RDMA bei QD1/16-Jobs 353.57 IOPS im Vergleich zu 329.10 IOPS von TCP – ein Unterschied von etwa 7.5 %. Bei steigenden Workloads behielt RDMA seinen Vorsprung und arbeitete typischerweise im Bereich von 360 bis 400 IOPS, während TCP eher bei 330 bis 380 IOPS blieb.

4K zufällige Leselatenz

Im 4K Random Read-Latenztest zeigte RDMA einen deutlichen Effizienzvorteil gegenüber TCP, insbesondere bei zunehmender Arbeitslast. Bei geringer Warteschlangentiefe waren die beiden Protokolle nahezu identisch. Beispielsweise erreichte TCP beim QD1/1-Job 0.24 ms, während RDMA mit 0.27 ms knapp dahinter lag.

Mit zunehmender Parallelität setzte sich RDMA durch. Bei QD16/64-Jobs maß RDMA 23.92 ms, während TCP 26.81 ms erreichte – eine Verbesserung um 10.8 %. Bei der höchsten Auslastung von QD32/64-Jobs wurde RDMA nach 54.61 ms abgeschlossen, während TCP auf 70.12 ms anstieg – eine Latenzreduzierung von 22 % für RDMA.

GPUDirect-Speicherleistung

Einer der Tests, die wir auf diesem Prüfstand durchgeführt haben, war der Magnum IO GPUDirect Storage (GDS)-Test. GDS ist eine von NVIDIA entwickelte Funktion, die es GPUs ermöglicht, die CPU beim Zugriff auf Daten auf NVMe-Laufwerken oder anderen Hochgeschwindigkeitsspeichern zu umgehen. Anstatt Daten über die CPU und den Systemspeicher zu leiten, ermöglicht GDS die direkte Kommunikation zwischen GPU und Speichergerät, was die Latenz deutlich reduziert und den Datendurchsatz verbessert.

So funktioniert GPUDirect-Speicher

Wenn eine GPU Daten verarbeitet, die auf einem NVMe-Laufwerk gespeichert sind, müssen diese traditionell zunächst die CPU und den Systemspeicher durchlaufen, bevor sie die GPU erreichen. Dieser Prozess führt zu Engpässen, da die CPU zum Zwischenhändler wird, was zu zusätzlichen Latenzen führt und wertvolle Systemressourcen verbraucht. GPUDirect Storage beseitigt diese Ineffizienz, indem die GPU über den PCIe-Bus direkt auf die Daten des Speichergeräts zugreifen kann. Dieser direkte Pfad reduziert den mit der Datenübertragung verbundenen Aufwand und ermöglicht schnellere und effizientere Datenübertragungen.

KI-Workloads, insbesondere solche mit Deep Learning, sind äußerst datenintensiv. Das Training großer neuronaler Netzwerke erfordert die Verarbeitung von Terabytes an Daten, und jede Verzögerung bei der Datenübertragung kann zu einer Unterauslastung der GPUs und längeren Trainingszeiten führen. GPUDirect Storage bewältigt diese Herausforderung, indem es sicherstellt, dass die Daten so schnell wie möglich an die GPU übermittelt werden, wodurch Leerlaufzeiten minimiert und die Recheneffizienz maximiert werden.

Darüber hinaus ist GDS besonders vorteilhaft für Workloads, die das Streamen großer Datensätze beinhalten, wie etwa Videoverarbeitung, Verarbeitung natürlicher Sprache oder Echtzeit-Inferenz. Durch die Reduzierung der Abhängigkeit von der CPU beschleunigt GDS die Datenbewegung und gibt CPU-Ressourcen für andere Aufgaben frei, was die Gesamtsystemleistung weiter verbessert.

Neben der reinen Bandbreite bietet GPUDirect mit NVMe-oF (TCP/RDMA) auch I/O mit extrem niedriger Latenz. Dadurch wird sichergestellt, dass den GPUs nie die Daten ausgehen, was das System ideal für KI-Inferenzen in Echtzeit, Analyse-Pipelines und Videowiedergabe macht.

Für viele praktische Bereitstellungen bedeutet dies einen nutzbaren Durchsatz von 100–200 GbE, der sich perfekt für Workloads wie KI-Inferenz (2–4 GPUs), Medienproduktion (Broadcast-Wiedergabe, OTT-Edge-Caching), Überwachungsvideoanalyse und HPC-Checkpointing eignet.

Lesedurchsatz

Beim sequentiellen GDSIO-Lesevorgang skalierte der Durchsatz stetig mit Blockgröße und Threadanzahl und erreichte an mehreren Testpunkten ein Maximum von 11.0 GiB/s. Die höchsten Ergebnisse wurden bei Blockgrößen von 512 KB und mehr erzielt, wobei sich der Durchsatz unabhängig von der Threadanzahl konstant zwischen 10.9 und 11.0 GiB/s stabilisierte.

Bei kleineren Blockgrößen war die Leistung zunächst deutlich geringer. Beispielsweise lag der Durchsatz bei 4K-Blöcken mit einem einzelnen Thread zunächst bei nur 0.3 GiB/s und pendelte sich selbst bei 256 Threads bei 1.5 GiB/s ein. Im Vergleich dazu ermöglichte eine Erhöhung der Blockgröße auf 64K eine Skalierung des Systems auf bis zu 10.9 GiB/s, wodurch der Durchsatz bei höheren Thread-Zahlen nahezu ausgeschöpft war.

Der optimale Bereich lag bei etwa 128 bis 256 Blöcken, wo der Durchsatz mit 32 oder mehr Threads über 10 GiB/s lag und über die größten getesteten Blockgrößen hinweg konstant blieb. Dies zeigt, dass die Plattform die volle Bandbreitensättigung erreicht, sobald die Blockgrößen ausreichend groß sind, wobei über 256 nur noch schrittweise Zuwächse zu verzeichnen sind.

Latenz lesen

Bei den Latenzergebnissen für sequentielles Lesen von GDSIO skalierten die Reaktionszeiten vorhersehbar mit Blockgröße und Threadanzahl. Selbst bei kleinsten Arbeitslasten blieb die Latenz extrem niedrig. Beispielsweise betrug sie bei 4K-Blöcken in einem einzelnen Thread nur 50 µs und blieb bei bis zu 32K-Blockgrößen und minimaler Parallelität unter 200 µs.

Mit zunehmender Thread-Anzahl stieg auch die Latenz deutlicher an. Bei 64K-Blöcken und 64 Threads erreichte die Latenz 1.5 ms, verdoppelte sich bei 128 Threads auf 2.9 ms und stieg bei 256 Threads auf 5.7 ms. Im Gegensatz dazu erreichten kleinere Blockgrößen wie 4K und 8K selbst bei maximal 256 Threads nur Werte zwischen 2.7 und 2.8 ms, was auf eine bessere Kontrolle bei feinerer Granularität hindeutet.

Größere Blockgrößen führten zu dramatischeren Sprüngen. Bei 1-Millionen-Blöcken und 256 Threads erreichte die Latenz 96.1 ms, während sie bei 10-Millionen-Blöcken und 256 Threads auf 4.3 s anstieg. Dies verdeutlichte deutlich die Skalierungsgrenzen des Systems unter extremen Bedingungen.

Schreibdurchsatz

Bei der sequentiellen GDSIO-Schreibarbeitslast skalierte der Durchsatz sowohl mit der Blockgröße als auch mit der Threadanzahl, blieb jedoch deutlich unter der Obergrenze der Leseleistung. Das System erreichte einen Spitzenwert von 7.2 GiB/s bei Verwendung größerer Blockgrößen wie 5M und 10M bei 128 Threads.

Bei den kleinsten Blockgrößen war der Durchsatz bescheiden. Bei 4K-Blöcken begann die Leistung bei 0.3 GiB/s mit einem einzelnen Thread und skalierte auf 1.0 GiB/s mit 32 Threads, bevor sie sich dann stabilisierte. Durch die Erhöhung der Blockgröße auf 64K wurde mehr Bandbreite freigeschaltet, die mit acht Threads 5.6 GiB/s erreichte und bei höherer Parallelität leicht abnahm.

Die beste Balance wurde bei Blöcken zwischen 512 KB und 1 MB erreicht. Hier lag der Durchsatz bei unterschiedlichen Thread-Anzahlen zwischen 6.7 und 7.1 GiB/s. Dies deutet darauf hin, dass das System in diesem Bereich die Sättigung erreicht hatte. Darüber hinaus brachten zusätzliche Threads keine nennenswerten Verbesserungen mehr, und in einigen Fällen sank die Leistung aufgrund des erhöhten Overheads sogar leicht.

Schreibe Latenz

Bei den Latenzergebnissen für sequentielles Schreiben von GDSIO skalierten die Antwortzeiten bei niedrigeren Blockgrößen gleichmäßig, stiegen jedoch stark an, sobald sowohl die Blockgröße als auch die Threadanzahl zunahmen.

Bei kleinsten Workloads war die Latenz minimal. Bei 4K-Blöcken und einem einzelnen Thread betrug die durchschnittliche Latenz nur 58 µs und blieb bei 16K-Blöcken mit bis zu vier Threads unter 200 µs. Selbst bei 32K-Blöcken und moderater Parallelität blieb die Latenz unter 1 ms.

Mit der Umstellung auf größere Blockgrößen wurden die Verzögerungen deutlicher. Bei 128K-Blöcken und 64 Threads erreichte die Latenz 5.3 ms und verdoppelte sich bei 128 Threads noch einmal auf 10.7 ms. Bei 512K-Blöcken stiegen die Ergebnisse noch weiter und erreichten bei 256 Threads 73.4 ms.

In den schwersten Fällen, 5-Mio.- und 10-Mio.-Blöcken bei 256 Threads, kam es zu einem dramatischen Anstieg der Latenz auf 709 ms bzw. 4.8 Sekunden, was die Obergrenzen der sequenziellen Schreibskalierung aufzeigte.

Fazit

QSANs XN4226D ist genau das, was viele IT-Teams brauchen. Es handelt sich um eine einheitliche NVMe-Plattform mit zwei Controllern, die sowohl moderne als auch ältere Protokolle unterstützt, ohne dass Architekturänderungen erforderlich sind. In unseren Tests führte TCP mit 21.21 GB/s bei großen sequentiellen Lesevorgängen, während RDMA mit 11.14 GB/s die stärksten großen sequentiellen Schreibvorgänge lieferte und die Latenz bei steigender Parallelität niedrig hielt. Bei kleineren Blockgrößen verbesserte RDMA die Effizienz beim zufälligen Schreiben kontinuierlich und hielt das Tail-Verhalten unter Kontrolle. Die Schlussfolgerung ist einfach: Nutzen Sie NVMe-oF TCP für breite Kompatibilität und hohe Lesebandbreite und greifen Sie zu RDMA, wenn Schreiblatenz und Konsistenz am wichtigsten sind.

Der Hardware-Footprint ist praktisch. Sie erhalten 26 Frontschächte für U.2- oder U.3-NVMe-Laufwerke in einem 2HE-Gehäuse mit aktiver Hochverfügbarkeit und unkomplizierter Erweiterung auf SAS-Shells, wenn Kapazität Vorrang vor reiner NVMe-Geschwindigkeit hat. QSM 4 bietet die erwarteten Datendienste und eine übersichtliche Benutzeroberfläche sowie eine REST-API, die eine nahtlose Integration in bestehende Automatisierung ermöglicht. Kleine IT-Teams sollten QSM 4 als einfach zu konfigurieren und zu verwalten empfinden. Um dies zu bestätigen, haben wir unseren Proxmox-Cluster problemlos integriert und diesen VMs Zugriff auf Hochgeschwindigkeitsspeicher gewährt. Für anspruchsvollere Workloads ist QSAN bestens gerüstet, um die KI-Anforderungen kleiner und mittlerer Unternehmen zu erfüllen.

Für Unternehmen, die Wert auf zuverlässige Leistung, saubere Verwaltung und Multiprotokoll-Reichweite legen, ist der XN4226D eine klare Empfehlung. Er bietet echten NVMe-Durchsatz, hohe Schreiblatenz mit RDMA und eine Software, die Sie nicht ausbremst. Dank des günstigen Preises eignet sich diese QSAN-Plattform problemlos für gemischte Umgebungen.

QSAN-Produktseite