Nachdem wir die Leistung des VMware VSAN-Clusters mit einer herkömmlichen Sysbench OLTP- Workload untersucht hatten, wollten wir herausfinden, wie die Plattform auf eine höhere Workload für anspruchsvollere Anwendungsfälle reagiert. Die anfängliche Bereitstellung umfasste vier Sysbench-VMs (eine pro Knoten). Diese Workload führte jedoch nicht zu einer ausreichend hohen Festplatten-E/A, um eine vollständige Ressourcenauslastung zu gewährleisten. Dies ist vergleichbar mit einem Kunden, der einen Proof of Concept (POC) mit einer Teilmenge seiner aktuellen Workload testet, aber nicht misst, wie gut die Plattform auf wachsende Workloads oder die Migration weiterer Anwendungsdaten reagiert. Um das Verhalten dieses VSAN-Clusters unter stetig steigenden MySQL-Workloads besser zu verstehen, skalierten wir den Benchmark mit vier Sysbench-VMs (eine pro Knoten) auf acht bzw. zwölf VMs.
Dell PowerEdge R730xd VMware VSAN-Spezifikationen
- Dell PowerEdge R730xd Server (x4)
- CPUs: Acht Intel Xeon E5-2697 v3 2.6 GHz (14C/28T)
- Speicher: 64 x 16 GB DDR4 RDIMM
- SSD: 16 x 800 GB Solid State Drive SAS Mix Verwenden Sie MLC 12 Gbit/s
- Festplatte: 80 x 1.2 TB 10 U/min SAS 6 Gbit/s
- Netzwerk: 4 x Intel X520 DP 10 Gbit DA/SFP+, + I350 DP 1 Gbit Ethernet
- Speicherkapazität: 86.46TB
Sysbench-Leistung
Jede Sysbench-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 (400 GB). Aus Sicht der Systemressourcen haben wir jede VM mit 16 vCPUs und 64 GB DRAM konfiguriert und den LSI Logic SAS SCSI-Controller genutzt.
Bei einer Auslastung von 8 VMs haben wir gesehen, dass Sysbench-VMs jeweils zwischen 5,200 und 6,300 MHz verbrauchen, wobei die gesamten Hostressourcen darauf hinweisen, dass etwa 18,000 MHz genutzt wurden. Dadurch blieben viele CPU-Ressourcen übrig, wobei nur 22 % pro Host genutzt wurden, obwohl wir bei einer Arbeitslast von 8 Sysbench-VMs fast den gesamten verfügbaren SSD-Cache nutzten. Aus Gründen der Speicherauswirkungen haben wir 16 Sysbench-VMs geladen, um den Gesamtspeicherbedarf zu vergrößern und etwa 14 TB der gesamten VSAN-Speicherkapazität von 86.46 TB zu verbrauchen. Zum Zeitpunkt der 8-VM-Arbeitslast waren jedoch nur 7 TB dieser 14 TB aktiv. Dies steht im Vergleich zu 3.5 TB bei der 4-VM-Workload.
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: 12 Stunden
- 6 Stunden Vorkonditionierung von 32 Threads
- 1 Stunde 32 Threads
- 1 Stunde 16 Threads
- 1 Stunde 8 Threads
- 1 Stunde 4 Threads
- 1 Stunde 2 Threads
Als wir die Sysbench-OLTP-Arbeitslast skalierten, haben wir eine Leistungssteigerung von insgesamt 2,830 TPS mit 4 VMs auf 4,259 TPS mit 8 VMs gemessen. Dies führt zu einem Leistungssprung von 50 % und einer Verdoppelung des Workload-Footprints.
Mit der erhöhten Gesamttransaktionsleistung haben wir einen durchschnittlichen Anstieg der Latenz von 45 ms auf 60 ms pro VM gemessen. Dies entspricht einem Anstieg von etwa 33 % gegenüber der kleineren Arbeitslast.
Mit steigenden I/O-Anforderungen stieg auch die durchschnittliche Latenz im 99. Perzentil von 94 ms auf 131 ms.
Während der Benchmark ausgeführt wurde, haben wir CPU-, Festplatten- und Netzwerkstatistiken von vCenter erfasst. Während des 8-VM-Tests sahen wir eine VM-CPU-Spreizung von 5,275 MHz bis 6,393 MHz über die VMs hinweg.
Bei zwei aktiven VMs pro Knoten konnten wir nach Beginn der Arbeitslast eine gemischte Festplattenaktivität von insgesamt 2 MB/s feststellen. Die größeren Spitzen wurden gemessen, während sich die vorgefertigte Datenbank zu Beginn des Tests selbst in jede VM kopierte.
Der Netzwerkverkehr von einem Host betrug während des 8-VM-Sysbench-Tests gemischte 391 MB/s, nachdem der Test nachgelassen hatte.
Da der Zweck dieses Tests darin besteht, zu zeigen, wie VSAN auf eine ständig steigende Arbeitslast reagiert, haben wir die Plattform nach dem 12-VM-Lauf auf insgesamt 8 VMs erhöht. Dies war der Bruchpunkt, an dem ein Teil der Arbeitslast aus dem SSD-Cache verschoben wurde. Wir haben diese Leistung nicht aufgezeichnet, da die meisten Arbeitslasten nicht abgeschlossen wurden oder nicht die richtigen Ergebnisse erzielten. Bei den VMs, die tatsächlich abgeschlossen wurden, hätten wir im gesamten Cluster eine Gesamttransaktionsleistung von nur 1000–1500 TPS gesehen. Der von uns gemessene Leistungsabfall kann natürlich durch größere Flash-Geräte wie 1.6-TB-SSDs anstelle von 800 GB oder den Wechsel zu einem All-Flash-VSAN-Modell abgemildert werden, bei dem die Belastung Ihrer Leseebene nicht so groß ist I/O-Drop. Dies unterstreicht die Notwendigkeit, die Flash-Komponente der VSAN-Umgebung richtig zu dimensionieren. Administratoren oder ihre Reseller-Partner sollten über gute Kenntnisse des Arbeitsdatensatzes verfügen. Dies ist eine der Hauptstärken der VSAN-Plattform. So können Kunden Konfigurationen so anpassen, dass sie den Anforderungen aktueller und zukünftiger Arbeitslasten optimal entsprechen, oder SSDs bei Bedarf kostengünstig austauschen/hinzufügen.
Es ist sehr wichtig zu wissen, wo die Bruchstellen Ihrer Plattform liegen. Die anfänglich bereitgestellten Arbeitslasten werden im Laufe der Zeit normalerweise wachsen, sowohl in Bezug auf die Anzahl der VMs als auch in Bezug auf die Speicherkapazität. Jede Speicherplattform hat einen Engpass (sogar All-Flash-Arrays), was uns dazu führt, wie dieser VSAN-Cluster mit vier Knoten aufgebaut ist. Derzeit hatten wir nur eine Speicherplattform, auf der 12 und 16 Sysbench-VMs erfolgreich ausgeführt wurden, und zwar ein All-Flash-Array mit einem UVP von 575,000 US-Dollar. Zukünftige Tests dieses VSAN-Clusters werden jedoch All-Flash-Konfigurationen umfassen, um zu versuchen, ähnliche Leistungsziele zu erreichen.
Überprüfung von VMware Virtual SAN: Übersicht und Konfiguration
Überprüfung von VMware Virtual SAN: VMmark-Leistung
Überprüfung von VMware Virtual SAN: Sysbench OLTP-Leistung
Überprüfung von VMware Virtual SAN: SQL Server-Leistung
Überprüfung von VMware Virtual SAN: Skalierte Sysbench-OLTP-Leistung
Überprüfung von VMware Virtual SAN: Synthetische Leistung von HCIbench
Amazon