QSAN XCubeSAN XS5226D Testbericht

Letztes Jahr haben wir die QSAN XCubeSAN XS1200-Serie getestet und festgestellt, dass sie eine gute Leistung, gute Fähigkeiten und einen guten Preis für die SMB- und ROBO-Märkte bietet, auf die sie abzielt. Für diesen Test betrachten wir dasselbe Gerät mit dem High-End-Controller XS5226. Da Design, Aufbau und Verwaltung identisch sind (wir verwenden das gleiche Gehäuse), können die Leser darauf zurückgreifen vorherige Bewertung.

Innerhalb der XS5200-Familie (ähnlich der XS1200-Familie) bietet QSAN mehrere Formfaktoren und entweder einen einzelnen oder zwei Controller – wiederum mit einem S für Single oder D für Dual. Der XS5226D ist ein Dual-Controller, der aktiv/aktiv ist und auf eine höhere Leistung für geschäftskritische Umgebungen ausgerichtet ist. Die idealen Anwendungsfälle sind HPC, Virtualisierungsintegration und M&E. Das Unternehmen gibt eine Leistung von bis zu 12 GB/s sequentiellem Lesen und 8 GB/s sequentiellem Schreiben mit über 1.5 Millionen IOPS an.

Da wir, wie bereits erwähnt, das gleiche Chassis verwenden, gibt es einige Überschneidungen zwischen den beiden Testberichten und werden daher hier übersprungen. Wir werden uns jedoch mit den wichtigsten Spezifikationsunterschieden befassen, da diese sich direkt auf die Leistung auswirken.

QSAN XCubeSAN XS5226D-Spezifikationen

Raid-Controller	Dual-aktiv
CPU	Intel Xeon D-1500 Quad-Core
Memory	bis zu 128 GB DDR4 ECC
Antriebsart
2.5″ SAS, NL-SAS, SED-Festplatte
2.5-Zoll-SAS, SATA-SSD (6-GB-MUX-Karte für 2.5-Zoll-SATA-Laufwerke im Dual-Controller-System erforderlich)
Erweiterungsmöglichkeiten	2U 26-Bay, SFF
Maximal unterstützte Laufwerke	286

Kennzahlen

Analyse der Anwendungsauslastung

Die Anwendungs-Workload-Benchmarks für den QSAN XCubeSAN XS5226D bestehen aus der MySQL OLTP-Leistung über SysBench und der Microsoft SQL Server OLTP-Leistung mit einer simulierten TPC-C-Workload. In jedem Szenario hatten wir das Array mit 26 Toshiba PX04SV SAS 3.0 SSDs konfiguriert, die in zwei RAID12-Festplattengruppen mit 10 Laufwerken konfiguriert waren, eine an jeden Controller angeschlossen. Somit blieben zwei SSDs als Ersatz übrig. Anschließend wurden zwei 2-TB-Volumes erstellt, eines pro Festplattengruppe. In unserer Testumgebung führte dies zu einer ausgeglichenen Last für unsere SQL- und Sysbench-Workloads.

SQL Server-Leistung

Jede SQL Server-VM ist mit zwei vDisks konfiguriert: einem 100-GB-Volume für den Start und einem 500-GB-Volume für die Datenbank und Protokolldateien. Aus Sicht der Systemressourcen haben wir jede VM mit 16 vCPUs und 64 GB DRAM konfiguriert und den LSI Logic SAS SCSI-Controller genutzt. Während unsere zuvor getesteten Sysbench-Workloads die Plattform sowohl in Bezug auf Speicher-I/O als auch in Bezug auf die Kapazität ausgelastet haben, wird beim SQL-Test nach der Latenzleistung gesucht.

Dieser Test verwendet SQL Server 2014, das auf Windows Server 2012 R2-Gast-VMs ausgeführt wird, und wird durch Quests Benchmark Factory für Datenbanken belastet. Während wir diesen Benchmark traditionell zum Testen großer Datenbanken mit einer Größe von 3,000 auf lokalem oder gemeinsam genutztem Speicher verwenden, konzentrieren wir uns in dieser Iteration darauf, vier Datenbanken mit einer Größe von 1,500 gleichmäßig über den QSAN XS5200 zu verteilen (zwei VMs pro Controller).

SQL Server-Testkonfiguration (pro VM)

Windows Server 2012 R2
Speicherbedarf: 600 GB zugewiesen, 500 GB genutzt
SQL Server 2014
- Datenbankgröße: Maßstab 1,500
- Virtuelle Client-Auslastung: 15,000
- RAM-Puffer: 48 GB
Testdauer: 3 Stunden
- 2.5 Stunden Vorkonditionierung
- 30-minütiger Probezeitraum

SQL Server OLTP Benchmark Factory LoadGen-Ausrüstung

Dell EMC PowerEdge R740xd Virtualisierter SQL-Cluster mit 4 Knoten
- 8 Intel Xeon Gold 6130 CPU für 269 GHz im Cluster (zwei pro Knoten, 2.1 GHz, 16 Kerne, 22 MB Cache)
- 1 TB RAM (256 GB pro Knoten, 16 GB x 16 DDR4, 128 GB pro CPU)
- 4 x Emulex 16 GB Dual-Port-FC-HBA
- 4 x Mellanox ConnectX-4 rNDC 25GbE Dual-Port-NIC
- VMware ESXi vSphere 6.5 / Enterprise Plus 8-CPU

Für unsere Tests vergleichen wir den neuen Controller mit dem zuvor getesteten. Dabei geht es weniger um die Frage „Welches ist besser“ als vielmehr um die Frage, welche Leistung man je nach Bedarf erhält.

Bei SQL Server hatte der Unterschied bei den Controllern eigentlich keinen großen Unterschied in der Gesamtleistung. Der XS1226 mit 4 VMs erreichte 12,634.3 TPS und der XS5226 mit 4 VMs erreichte 12,634.7 TPS.

Bei der durchschnittlichen SQL-Latenz sahen wir mehr davon. Der XS1226 hatte eine Latenz von 5.8 ms und der XS5226 hatte eine Latenz von 5.0 ms.

Sysbench-Leistung

. Systembankben Die VM ist mit drei vDisks konfiguriert, eine für den Start (~92 GB), eine mit der vorgefertigten Datenbank (~447 GB) und die dritte für die zu testende Datenbank (270 GB). Aus Sicht der Systemressourcen haben wir jede VM mit 16 vCPUs und 60 GB DRAM konfiguriert und den LSI Logic SAS SCSI-Controller genutzt. Lastgenerierungssysteme sind Dell R740xd-Server.

Dell PowerEdge R740xd Virtualisierter MySQL-Cluster mit 4 Knoten

8 Intel Xeon Gold 6130 CPU für 269 GHz im Cluster (zwei pro Knoten, 2.1 GHz, 16 Kerne, 22 MB Cache)
1 TB RAM (256 GB pro Knoten, 16 GB x 16 DDR4, 128 GB pro CPU)
4 x Emulex 16 GB Dual-Port-FC-HBA
4 x Mellanox ConnectX-4 rNDC 25GbE Dual-Port-NIC
VMware ESXi vSphere 6.5 / Enterprise Plus 8-CPU

Sysbench-Testkonfiguration (pro VM)

CentOS 6.3 64-Bit
Speicherbedarf: 1 TB, 800 GB genutzt
Percona XtraDB 5.5.30-rel30.1
- Datenbanktabellen: 100
- Datenbankgröße: 10,000,000
- Datenbankthreads: 32
- RAM-Puffer: 24 GB
Testdauer: 3 Stunden
- 2 Stunden Vorkonditionierung von 32 Threads
- 1 Stunde 32 Threads

In unserem Sysbench-Benchmark haben wir mehrere Sätze von 4VMs, 8VMs, 16VMs und 32VMs getestet. Bei der Transaktionsleistung zeigte der XS5226D eine starke Leistung mit 6,889 TPS für 4 VMs, 13,023 TPS für 8 VMs, 21,645 TPS für 16 VMs und 26,810 TPS für 32 VMs.

Bei der durchschnittlichen Latenz schnitt der 4VM XS1226 mit 5226 ms bis 18.1 ms etwas besser ab als der XS18.6D, aber der XS5226D übertraf den früheren Controller in den anderen VM-Konfigurationen mit 19.7 ms für 8VM, 23.9 ms für 16VM und 41 ms für 32VM.

In unserem Worst-Case-Szenario-Latenz-Benchmark sehen wir das Gleiche wie bei der durchschnittlichen Latenz: besser in 4VM für die XS1200-Serie und besser im Rest mit der XS5200-Serie. Beim XS5226D haben wir eine Latenz von 32.7 ms für 4 VM, 34.8 ms für 8 VM, 47 ms für 16 VM und 76.9 ms für 32 VM festgestellt.

VDBench-Workload-Analyse

Wenn es um das Benchmarking von Speicher-Arrays geht, sind Anwendungstests am besten und synthetische Tests stehen an zweiter Stelle. Obwohl sie keine perfekte Darstellung der tatsächlichen Arbeitslasten darstellen, helfen synthetische Tests dabei, Speichergeräte mit einem Wiederholbarkeitsfaktor zu vergleichen, der es einfach macht, Konkurrenzlösungen direkt miteinander zu vergleichen. Diese Workloads bieten eine Reihe unterschiedlicher Testprofile, die von „Vier-Ecken“-Tests über allgemeine Tests der Datenbankübertragungsgröße bis hin zu Trace-Erfassungen aus verschiedenen VDI-Umgebungen reichen. Alle diese Tests nutzen den gemeinsamen vdBench-Workload-Generator mit einer Skript-Engine, um Ergebnisse über einen großen Computing-Testcluster zu automatisieren und zu erfassen. Dadurch können wir dieselben Arbeitslasten auf einer Vielzahl von Speichergeräten wiederholen, einschließlich Flash-Arrays und einzelnen Speichergeräten. Auf der Array-Seite nutzen wir unseren Cluster aus Dell PowerEdge R740xd-Servern:

Profile:

4K Random Read: 100 % Read, 128 Threads, 0-120 % Iorate
4K Random Write: 100 % Schreiben, 64 Threads, 0-120 % Iorate
64K sequentielles Lesen: 100 % Lesen, 16 Threads, 0-120 % Leserate
64K Sequentielles Schreiben: 100 % Schreiben, 8 Threads, 0-120 % Iorate
Synthetische Datenbank: SQL und Oracle
VDI-Vollklon- und Linked-Clone-Traces

Bei der 4K-Spitzenleseleistung erreichte der XS5226D eine Latenzleistung von unter einer Millisekunde bis knapp 400 IOPS, mit einer Spitzenleistung von 442,075 IOPS bei einer Latenz von 8.03 ms. Dies übertraf den XS1200, der mit 284 IOPS und einer Latenz von 13.82 ms seinen Höhepunkt erreichte, um Längen.

Mit einer Spitzenschreibleistung von 4K erreichte der neue Controller eine Latenzleistung von unter einer Millisekunde bis zu etwa 270 IOPS mit einem Spitzenwert von 294,255 IOPS und einer Latenz von 6.27 ms. Zum Vergleich: Der alte Controller hatte eine Spitzenleistung von etwa 246 KB bei einer Latenz von 7.9 ms.

Bei der Umstellung auf sequentielle Leistung erreichte der XS64D bei der 5226K-Lesegeschwindigkeit knapp 1 ms bis etwa 38 IOPS oder 2.3 GB/s und erreichte einen Spitzenwert von 95,762 IOPS oder 5.99 GB/s mit einer Latenz von 5.34 ms. Der XS1200 hatte nicht einmal eine Leistung unter einer Millisekunde.

Bei sequenziellen Spitzenschreibvorgängen mit 64 KB erreichte die Leistung des XS5226D weniger als 1 ms, bis etwa 63 KB IOPS oder 3.9 GB/s erreicht waren. Der Spitzenwert lag bei etwa 80 IOPS oder 4.95 GB/s bei einer Latenz von 2.68 ms.

Bei unserem SQL-Workload übertraf der neue Controller sein Gegenstück deutlich. Der XS5226D hatte eine Latenzleistung von unter einer Millisekunde bis etwa 380 IOPS und erreichte einen Spitzenwert von 425,327 IOPS mit einer Latenz von 2.27 ms. Der XS5226D-Controller hatte also etwa 200 mehr IOPS bei einer um 1 ms geringeren Latenz.

Im SQL 90-10 blieb der XS5226D bis zu etwa 1 IOPS unter 350 ms und erreichte einen Spitzenwert von 407,661 IOPS mit einer Latenz von 2.36 ms. Auch hier übertraf er den anderen Controller, dessen Leistung sich über 1 ms erstreckte.

Der SQL 80-20 zeigte den XS5226D mit einer Latenzleistung von unter einer Millisekunde bis etwa 340 IOPS und einer Spitzenleistung von 387,085 IOPS bei einer Latenz von 2.4 ms. Auch hier war es ein ziemlicher Leistungssprung auf dem XS1200, der eine Spitzenleistung von etwa 247 IOPS bei einer Latenz von 3.26 ms erreichte.

Mit dem Oracle Workload schaffte es der XS5226D bis zu fast 310 IOPS, bevor er 1 ms durchbrach und mit 381,444 ms einen Spitzenwert von 3.1 IOPS erreichte. Der XS1200 erreichte einen Spitzenwert von 246,186 IOPS mit einer Latenz von 4.2 ms.

Mit dem Oracle 90-10 blieb der XS5226D bis zu etwa 1 IOPS unter 360 ms und erreichte einen Spitzenwert von 407,763 IOPS mit einer Latenz von 1.56 ms. Zum Vergleich: Der XS1200 erreichte seinen Spitzenwert bei 248,759 IOPS mit einer Latenz von 2.2 ms und fiel während des gesamten Betriebs nie unter 1 ms.

Beim Oracle 80-20-Lauf erreichte der XS5226D knapp 350 IOPS, bevor er 1 ms durchbrach und mit einer Latenz von 386,844 ms einen Spitzenwert von 1.66 IOPS erreichte. Der XS1200 lag durchgehend über 1 ms mit einem Spitzenwert von 242,000 IOPS und einer Latenz von 4.16 ms.

Als nächstes wechselten wir zu unserem VDI-Klontest „Full and Linked“. Beim VDI-Full-Clone-Boot überschritt der XS5226D eine Zeit lang die Grenze von 1 ms, bevor er bei etwa 225 IOPS abfiel und bei 367,665 IOPS mit einer Latenz von 2.78 ms seinen Höhepunkt erreichte. Ein beeindruckender Leistungssprung im Vergleich zu den 1200 IOPS und der Latenz von 218 ms des XS4.26.

Bei der VCI FC-Erstanmeldung hatte der XS5226D eine Latenzleistung von unter einer Millisekunde bis etwa 200 IOPS und erreichte einen Spitzenwert von etwa 260 IOPS mit einer Latenz von 3 ms. Der XS1200 erreichte im selben Test einen Spitzenwert von 185,787 IOPS bei einer Latenz von 3.91 ms.

Beim VDI Full Clone Monday Login erreichte der XS5226D etwa 163 IOPS unter 1 ms und erreichte einen Spitzenwert von 269,724 IOPS mit einer Latenz von 1.86 ms. Der vorherige Controller konnte einen Spitzenwert von 182,376 IOPS bei einer Latenz von 2.55 ms erreichen.

Bei der Umstellung auf VDI Linked Clone zeigte der Boot-Test, dass der XS5226D es mit einer Latenzleistung von unter einer Millisekunde bis zu etwa 110 KB schaffte und einen Spitzenwert von 216,579 IOPS mit einer Latenz von 2.36 ms erreichte. Der XS1200 erreichte einen Spitzenwert von 149,488 IOPS mit einer Latenz von 3.39 ms.

Bei der ersten VDI-Linked-Clone-Anmeldung schaffte es der XS5226D auch bis zu etwa 110 mit einer Latenzleistung von unter einer Millisekunde und erreichte dann mit einer Latenz von 182,425 ms einen Spitzenwert von 1.39 IOPS. Vergleichen Sie dies mit dem XS1200, der eine Spitzenleistung von 147,423 IOPS bei einer Latenz von 1.71 ms hatte.

Schließlich erreichte der XS5226D beim VDI Linked Clone Monday Login erneut etwa 110 IOPS mit einer Latenzleistung von unter einer Millisekunde und erreichte dann mit einer Latenz von 220 ms einen Spitzenwert von etwa 2.3 IOPS. Der XS1200 erreichte einen Spitzenwert von 148,738 IOPS mit einer Latenz von 3.2 ms.

Fazit

Das QSAN XCubeSAN XS5226D ist ein Dual-Aktiv-Aktiv-SAN, das mehr Leistung verspricht als das für KMU gedachte XS1226D. Für diesen Test haben wir dasselbe Gehäuse mit einem verbesserten Controller genutzt. Davon abgesehen waren Design, Aufbau und Management gleich und können in unserem nachgelesen werden Original-Bewertung. Der XS5226D ist auf geschäftskritischere Arbeitslasten ausgerichtet und verfügt über höhere Zielanwendungsfälle als der XS1226D, beispielsweise HPC, M&E und Virtualisierung. Die Verwendung des gleichen Gehäuses bedeutet, dass alle Konnektivitäts- und Hochverfügbarkeitsvorteile gleich sind.

Was die Leistung anbelangt, so führten die Unterschiede bei den Controllern in unserer Anwendungs-Workload-Analyse nicht wirklich zu einem großen Unterschied in der Leistung unserer SQL Server-Benchmarks, obwohl wir in anderen Bereichen massive Zuwächse verzeichneten. Der TPS für den XS1226 betrug 12,634.3 und für den XS5226 war der Wert mit 0.4 nur 12,634.7 TPS höher. Wir haben eine ähnliche Aktion mit durchschnittlicher Latenz gesehen, wobei der kleinere Controller 5.8 ms und der größere 5.0 ms erreichte. Mit Sysbench sahen wir eine viel bessere Leistung des XS1226 in 4-VM-Konfigurationen, aber der XS5226 hatte eine bessere Leistung mit mehr VMs mit einer 32-VM-Leistung von 26,810.4 TPS, einer durchschnittlichen Latenz von 41 ms und einem Worst-Case-Szenario von 76.9 ms.

Bei unseren VDBench-Workloads gab es in fast allen unserer Tests einen enormen Unterschied, wobei der XS5226D deutlich mehr Leistung lieferte. In unserem 4K-Test haben wir gesehen, dass die XS5226D-Controller Werte von über 442 IOPS beim Lesen und 294 IOPS beim Schreiben erreichten, mit einer Latenz von nur 8.03 ms bzw. 6.27 ms. Die 64K-Leistung zeigte, dass der Controller fast 6 GB/s beim Lesen und fast 5 GB/s beim Schreiben erreichte. Mit unserer SQL-Workload erzielte der Controller eine Spitzenleistung von über 425 IOPS, 407 IOPS für 90–10 und 387 IOPS für 80–20. Auch die Oracle-Workload zeigte einige wirklich gute Zahlen mit einer Spitzenleistung von über 381 IOPS, 407 IOPS für 90–10 und 386 IOPS für 80–20 mit Latenzen zwischen 1.56 ms und 3.1 ms. Für unseren VDI-Vollklon und den Linked-Klon haben wir uns mit Boot, Erstanmeldung und Montagsanmeldung befasst. Bei der Boot-Leistung erreichte der XS5226D über 367 IOPS im FC und über 216 IOPS im LC. Bei der ersten Anmeldung wurden etwa 260 IOPS für die Spitzenleistung von FC und über 182 IOPS für LC angezeigt. Und Monday Login hatte den XS5226D-Controller mit über 269 IOPS FC und 220 IOPS LC.

Insgesamt schnitt das XS5200 recht gut ab und nutzte die Vorteile der von uns installierten Toshiba PX04 SAS3 SSDs voll aus. Die Gesamtleistung ist sehr beeindruckend, da 6 GB/s Lese- und 5 GB/s Schreibgeschwindigkeit (64 KB sequenziell) aus einem SMB-SAN sehr gut sind. Natürlich gibt es einen gewissen Kompromiss; Der Funktionsumfang, die Schnittstelle und die Softwareintegrationen mit beliebten Paketen wie VMware lassen ein wenig zu wünschen übrig, wenn Sie anspruchsvollere Unternehmensanforderungen bevorzugen. Wie dem auch sei, der XS5200 bietet ein fantastisches Leistungs-/Kostenprofil, mit dem er seine Arbeit für einen Großteil der Zielgruppe gut erledigen wird.