Test: Violin 6000 All Flash Array

Wer einen hohen Bedarf an IOPS, niedrigen Latenzen und/oder Performance im Bereich Netzwerkspeicher hat, kommt um ein System mit flashbasiertem Speicher kaum herum. Es gibt unterschiedliche Ansätze, wie die benötigte Leistung erbracht werden kann. In diesem Test geht es um ein System der Firma Violin Memory, die mit der Violin 6000 All Flash Arrays ein Speichersystem anbietet, welches ausschließlich auf Flash-Speicher basierend und mit zu einer Million IOPS bei einer äußerst geringen Latenz eine High-End Lösung bereit stellt. Welche Performance dieses System im Bereich der Virtualisierung mit Hyper-V bietet schauen wir uns in diesem Artikel an.

Dieser Artikel ist im November 2014 bereits im IT-Administrator Magazin erschienen.

6100, 6200 oder 6600?

Innerhalb der Violin 6000 Serie gibt es mehrere Varianten, die sich in der Art des Flash Speichers, der Größe, der maximalen Performance und natürlich dem Preis unterscheiden.

*) Dieses Modell gibt es nicht als Windows Flash Array, sondern nur mit dem Violin-eigenen Betriebssystem vMOS.

**) die Nutzkapazität ist abhängig von der Formatierung. Die Werte beziehen sich auf ein Formatierungslevel von 84%.

Das in diesem Test genutzte Modell trägt die Bezeichnung Violin 6264 und bietet eine Brutto-Speicherkapazität von 70 TB, wovon 44 TB nutzbar sind. Die Anzahl der IOPS, die mit diesem Modell erreicht werden können, liegen laut Datenblatt des Herstellers bei 750.000.

Der technische Aufbau

Neben dem reinen Flash-Speicher enthält das Gerät unter anderen noch zwei Server (vom Hersteller als Memory Gateways, abgekürzt MG, bezeichnet), die mit Windows Server 2012 R2 in der Storage Edition betrieben werden. Die Lizenzen für diese Server sind bereits enthalten, auf jedem der beiden Server-Einheiten befindet sich ein Lizenzaufkleber. Beide Server sind intern mehrfach redundant an den Flash-Speicher angebunden, dies wird über vier aktiv/aktiv RAID-Controller (vRAID Control Modules, abgekürzt VCM) erreicht. Von diesen vier VCMs könnten bis zu drei ausfallen, der Betrieb würde (wenn auch verständlicherweise mit Leistungseinbußen) weiterhin funktionieren. Der Speicher in dem Testgerät besteht aus einzelnen Modulen mit einer Größe von jeweils 1 TB, diese werden als Violin Intelligent Memory Modules bezeichnet (im weiteren Verlauf mit VIMM abgekürzt). Fünf dieser VIMMs werden jeweils zu einem Verbund (vom Hersteller wird dieser Verbund als VIMM Protection Group bezeichnet) zusammengefasst. Eingehende Daten werden grundsätzlich in 4KB großen Blöcken abgespeichert. In jedes VIMM einer VIMM Protection Group werden 1 KB geschrieben, in das fünfte VIMM werden zusätzlich 1KB Paritätsinformationen geschrieben. Vorweg geschaltete Array Control Module (ACM) sorgen dafür, dass eingehende Daten nur in Speicher geschrieben werden, der gerade nicht durch einen anderen Prozess beeinflusst wird. Diese Technik umgeht Performance-Einbrüche durch anstehende oder gerade aktive Lösch-Aktionen oder durch eine aktive Garbage Collection und sorgt für eine durchgehend hohe Performance.

Für den Ausfall eines VIMMs stehen insgesamt vier Hot Spare-VIMMs zur Verfügung. Sollte es zu einem Ausfall kommen, können alle Komponenten (VIMMs, VCMs, Netzteile, …) im Betrieb getauscht werden.

Eine Anbindung der Server per Netzwerk nach „außen“ wird je nach Konfiguration über Fibre Channel (acht Ports mit je 4 oder 8 Gb/s), Ethernet (acht Ports mit je 10 Gb/s) oder Infiniband (vier Ports mit je 40 Gb/s) erreicht, wobei die Fibre Channel-Variante ausschließlich bei dem vMOS-System zum Einsatz kommt. Bei den Windows Flash Array-Modellen haben Sie „nur“ die Wahl zwischen Ethernet oder Infiniband. Das uns zur Verfügung stehende Gerät besitzt die bereits erwähnte Anbindung per Ethernet, d.h. es stehen insgesamt 80 Gb/s zur Verfügung. Verbaut sind vier Karten der Firma Chelsio mit jeweils zwei Interfaces (Chelsio T-520CR Dual-Port 10 Gigabit Ethernet Adapter). Jeder der beiden Server bekommt zwei dieser Karten zugewiesen und kommt somit auf eine Bandbreite von 40 Gb/s. Die Karten unterstützen Remote Direct Memory Access (RDMA), auf diese Funktionalität gehen wir später erneut ein und schauen uns die Vorteile dieser Technik an.

Zusätzlich zur Anbindung über 40 Gb/s besitzt jeder Server noch einen Intel 82579LM- sowie zwei Intel I350-Adapter mit einer Bandbreite von jeweils 1 Gb/s.

Beide Server verfügen über 24 GB RAM (die Anzahl an RAM könnte bei Bedarf auf bis zu 48 GB erhöht werden) sowie zwei Intel Xeon E5-2448L CPUs mit jeweils 20 MB L3 Cache. Jede CPU besitzt acht Cores, dank Hyperthreading käme jeder Server somit auf 32 logische Prozessoren.

Die Speicherbereitstellung

Die beiden in dem Storage verbauten Server werden nicht direkt zur Virtualisierung genutzt, sondern stellen den Flash-Speicher über SMB 3 im Netzwerk zur Verfügung. Die beiden Systeme werden zu einem Failover Cluster konfiguriert, innerhalb dieses Clusters wird eine hochverfügbare Dateiserver-Rolle betrieben. Diese Art von Dateiserver wird als Scale-Out File Server bezeichnet. Sollte einer der beiden Server ausfallen, übernimmt der zweite Server den kompletten Betrieb alleine. Dieser Vorgang ist vollständig transparent, es kommt zu keiner Kommunikationsunterbrechung zwischen dem Dateiserver und den angeschlossenen Hyper-V Hosts. Voraussetzung für die Nutzung dieser Technik auf Seiten der Virtualisierungs-Hosts ist mindestens ein Windows Server 2012, absolut empfohlen ist allerdings die Nutzung von Windows Server 2012 R2, da hier einige Änderungen und Verbesserungen in das Produkt eingeflossen sind.

Die Installation der beiden Server wird über einen kleinen Wizard gestartet, hier werden grundsätzliche Informationen wie Name, Kennwort und IP-Adresse abgefragt. Nach der Installation sind beide Systeme per Remote Desktop zu erreichen und können entweder manuell oder über den im Betriebssystem enthaltenen Assistenten administriert werden.

Der Storage kann über das Violin Control Utility administriert werden. Das Programm selbst hat wenig Konfigurationsmöglichkeiten, Sie können lediglich vorhandene LUNs löschen oder neue anlegen. Sichtbar sind noch weitere Informationen über die Controller und die Art von Speicher, hier können aber keine Änderungen vorgenommen werden. Alle erstellten LUNs sind immer beiden Servern zugewiesen, nach dem Anlegen können Sie die Datenträger in der Datenträgerverwaltung sehen und verwalten. Negativ fällt auf, dass keine Möglichkeit zur Größenänderung der LUNs vorhanden ist.

Einen generellen Überblick über das gesamte System erhalten Sie über die Weboberfläche. Diese ist über einen Webbrowser erreichbar und zeigt einige Informationen über das System an.

Zusätzlich können über den Bereich Administration noch weitere Aufgaben ausgeführt werden, z.B. ein Neustart des Systems, eine Anpassung von IP-Adressen oder die Anzeige der Logdatei.

Die Konsole macht einen sehr aufgeräumten Eindruck und zeigt sehr schnell einige Informationen über den aktuellen Betriebsstatus an.

SMB Direct

Die in dem Testsystem verbauten 10 GbE-Karten sind RDMA-fähig. Dies bedeutet, dass bei einer Kommunikation zwischen dem SMB-Server (in diesem Fall einer der beiden Scale-Out File Server Knoten) und einem SMB-Client (Verwechseln Sie Client nicht mit einem „normalen“ Client, in diesem Fall ist mit SMB-Client ein Hyper-V Host gemeint) eine sehr hohe Bandbreite bei einer sehr geringen Latenz erreicht werden kann. Dies liegt daran, dass ein SMB-Client die Daten auf dem Datei-Server direkt in seinen Arbeitsspeicher liest. Da bei dieser Aktion weder die CPU des Datei-Servers noch die CPU des SMB-Clients (in diesem Fall des Hyper-V Hosts) genutzt werden muss, stehen beiden Systemen diese Ressourcen für andere Aufgaben zur Verfügung. Auf Seiten des Dateiservers ist dies z.B die Bearbeitung von Nicht-RDMA-Traffic, auf Seiten des Hypervisor führt dies unter anderem zu einer Erhöhung der VM-Anzahl, die Sie auf diesem System betreiben können.

Die hier genutzten Karten nutzen die iWARP-Technik. Vorteil dieser RDMA-Variante (z.B. gegenüber der RoCE-Variante) ist, dass auf Seiten der Switches keine weitere Konfiguration vorgenommen werden muss. Bei der Einrichtung ist darauf zu achten, dass für die 10 GbE-Karten kein Team konfiguriert werden darf. Sobald ein Adapter Mitglied in einem Team ist, steht die RDMA-Funktionalität nicht mehr zur Verfügung. Da in den Hyper-V Hosts jeweils nur zwei Ports mit iWARP-Technik zur Verfügung stehen, werden im Dateiserver-Failover Cluster ebenfalls nur zwei der vier möglichen Ports pro Server genutzt.

Das System unter Last

Um die Performance des Systems unter Last zu sehen, wurde ein Scale-Out File Server mit insgesamt fünf Datenträgern angelegt. Drei der Datenträger spielen bei der Betrachtung der Leistung keine Rolle, da einer dieser Datenträger ausschließlich als Datenträgerzeuge im Quorum verwendet wurde und die anderen beiden nicht benötigt werden (Anmerkung: Zwei jeweils 10 TB große Datenträger reichen aus, um pro Datenträger über 1200 Instanzen der Benchmark-VM zu speichern). Die anderen beiden Datenträger wurden als Cluster Shared Volume konfiguriert, jeder dieser Datenträger bietet ebenfalls eine Speicherkapazität von 10 TB.

Auf Seite der Hyper-V Hosts wurden acht Systeme ohne RDMA-Karten sowie zwei Systeme mit RDMA-Karten genutzt, um Last auf dem Storage zu erzeugen. Pro Host laufen VMs, in denen das SQLIO-Programm von Microsoft für eine Belastung sorgt. Zeitweise sorgen insgesamt 440 dieser VMs für eine Belastung von Netzwerk und Storage. Die Nicht-RDMA-Systeme sind Schulungsrechner mit einem Intel Core i5-2400S bzw. einem Intel Core i7-3770, 24 bzw. 32 GB RAM, zwei 1 Gb/s Karten sowie einer Intel X540-T2 Karte mit zwei 10 Gb/s-Ports. Bei den RDMA-Systemen handelt es sich um Cisco Server mit zwei Intel E5-2650 CPUs, 128 GB RAM, vier 1 Gb/s Ports sowie einer Chelsio T420-BT Karte mit zwei 10 Gb/s-Ports.

In jeder VM wird nach dem Start automatisiert eine SQLIO-Instanz gestartet, die von einer zentralen Freigabe eine Konfigurations-Datei herunterlädt und mit den konfigurierten Werten startet. Pro Durchlauf werden jeweils 60 Sekunden lang die Tests Random Read, Random Write, Sequential Read und Sequential Write durchgeführt. Jeder Durchlauf beinhaltet zwei Schleifen. Nach diesem Durchlauf wartet das Programm eine beliebige Zeit zwischen 0 und 60 Sekunden, bevor der nächste Durchlauf startet. Vor jedem Durchlauf wird die Konfiguration erneut von der zentralen Freigabe heruntergeladen, falls in dieser Zeit Änderungen vorgenommen wurden (z.B. eine Änderung der Block-Größe) werden diese nun angewandt. In dem folgenden Screenshot sehen Sie eine VM, in der ein Test mit einer Blockgröße von 8KB durchgeführt wird.

Laufen alle VMs einige Zeit, verschieben sich durch die Zufalls-Wartezeiten zwischen den einzelnen Durchläufen die Tests so, dass die Belastung nicht immer parallel anliegt, sondern variiert und so eine möglichst reale Umgebung versucht nachzustellen. Durch die Messung einiger aussagekräftiger Leistungsindikatoren in der Windows Leistungsüberwachung über einen gewissen Zeitraum lassen sich so einige Werte ermitteln, die die Performance des Geräts zeigen.

Die Tests in Zahlen

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 4KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Die ermittelten Werte zeigen, dass in Summe durchschnittlich fast 180.000 IOPS realisiert werden konnten. Die maximalen Werte liegen sogar noch deutlich höher, hier konnten über 250.000 IOPS gemessen werden. Die gemessenen Größen pro Anfrage zeigen sehr deutlich, dass das SQLIO-Tool wie gewünscht 4KB große Blöcke erzeugt und verarbeitet hat. Die durchschnittliche Zeit pro Anfrage liegt laut Anzeige durchschnittlich bei 1 ms, was bei der großen Anzahl an IOPS und der großen Menge an Anfragen sehr gut ist. Die Höhe des Datendurchsatzes spielt hier eher weniger eine Rolle, trotzdem sind die Daten auch in der Tabelle zu finden.

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 8KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Bei einer Erhöhung der Blockgröße des SQLIO-Tests auf 8KB zeigt sich, dass die IOPS nur leicht steigen gegenüber den Tests mit 4KB großen Blöcken. Bei diesem und allen anderen Werten (außer den 4K-Werten) muss allerdings zusätzlich beachtet werden, dass die Messung auf den Dateiserver-Knoten in 8KB IOPS durchgeführt werden. Auf dem Violin-System selbst werden die IOPS durchgehend in 4KB gemessen und angezeigt, da hier ausschließlich 4KB große Blöcke verarbeitet werden. Auf Seiten des Storage müssen die hier aufgeführten Werte verdoppelt werden, um einen direkten Vergleich gegenüber dem vorherigen Benchmark mit 4KB zu haben.

Die erreichten Transferraten steigen ebenfalls um knapp das doppelte, hier kann logischerweise mit einer größeren Blockgröße und einer fast gleichen IOPS-Anzahl auch ein höherer Durchsatz erreicht werden. Die Verarbeitungszeit der Daten bleibt weiterhin konstant bei (gerundet) 1ms.

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 64KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Durch die Erhöhung der Blockgrößen auf 64 KB zeigt sich eine weitere Verringerung der IOPS auf durchschnittlich knapp 45.000, aber auch eine deutliche Steigerung der Transferraten. Durchschnittlich konnten über beide Freigaben kontinuierlich 2 Gigabyte pro Sekunde verarbeitet werden (sowohl schreibend als auch lesend), zu Spitzenzeiten stieg die Bandbreite auf knapp 3 Gigabyte. Da die Verarbeitung von solch großen Blöcken seine Zeit braucht, stieg die durchschnittliche Bearbeitungszeit pro Paket auf durchschnittlich 15 ms.

Probleme bei der Erzeugung von Last und Grenzen der Testumgebung

Bei der Erzeugung einer möglichst hohen Belastung auf dem Flash-Storage sind wir bei der Menge der VMs (trotz Nutzung von RDMA) an Grenzen gestoßen. Die Nicht-RDMA-fähigen Hyper-V Hosts waren bei der Ausführung von jeweils 20 VMs fast an der Grenze ihrer CPU-Leistung, diese lag durchschnittlich zwischen 80 und 95%. Insgesamt acht Hosts konnten so insgesamt 160 VMs betreiben.

Auf Seiten der Cisco Server mit den verbauten Chelsio T420-BT Karten mussten wir feststellen, dass 50 VMs den Server zu knapp 50% auslasten und je nach Blockgröße für eine Bandbreite zwischen 16 und 18 Gb/s pro Hyper-V Host sorgen. Zwei dieser Systeme konnten so mit 100 VMs Tests auf dem Violin Storage durchführen. Weitere Hyper-V Hosts mit RDMA-fähigen Netzwerkkarten hätten so noch mehr VMs betreiben können, bei denen die Messwerte wahrscheinlich noch weiter gestiegen wären. Hierbei wäre dann allerdings zu beachten, dass die beiden NICs in den Memory Gateways um weitere Karten erweitert werden müssen, da sonst die Anbindung mit 20 Gb/s der Flaschenhals in dem Aufbau ist. Da die Karten logisch in jeweils einem eigenen Subnetz liegen müssen (SMB Multi Channel in einem Failover Cluster funktioniert nur, wenn die Karten logisch getrennt sind), werden auf Seiten der Hyper-V Hosts ebenfalls weitere Karten benötigt. Dies ist einer der vielen Dinge, die während der Planungsphase berücksichtigt werden muss, damit es im späteren Betrieb nicht an „nur“ 20 Gb/s hängt.

Während der Tests hat sich gezeigt, dass ein Betrieb von VMs mit dynamisch erweiterbarer Festplatte die Performance sehr stark (negativ) beeinflusst. VMs sollten ausschließlich mit VHDX-Dateien in einer festen Größe betrieben werden, um hier von vorn herein mögliche Engpässe auszuschließen. Zum Zeitpunkt der Erstellung dieses Tests arbeitet der Hersteller gemeinsam mit Microsoft bereits an einer Best Practise-Beschreibung, die unter anderem diesen Punkt beinhaltet. Weiterhin werden einige weitere Empfehlungen ausgesprochen, die einen Betrieb mit Hyper-V möglichst optimal vorbereiten.

Neben den reinen Messwerten gibt es ja immer auf Seiten des Administrators (bzw. in meinem Fall des Testers) ein Gefühl für den Betrieb, die „gefühlte Geschwindigkeit“. Bei der Arbeit mit dem Violin System habe ich zu keinem Zeitpunkt auf Seiten der Hyper-V Hosts oder der VMs ein Problem in Bezug auf die Performance gehabt. Selbst während einer Belastung des Storage mit 260 VMs, in denen alle die SQLIO-Tests liefen, gab es keine Hänger bei der Arbeit mit einer VM. Alle durchgeführten Aktionen waren gewohnt schnell, z.B. der Start von Programmen, einer Auflistung aller Dateien auf dem Laufwerk C: oder dem Kopieren von Dateien auf ein Netzlaufwerk oder von einem Netzlaufwerk in die entsprechende VM.

Die Nutzung des CSV Block Cache

Ab dem Windows Server 2012 gibt es die Funktion des CSV Block Cache. Bei dieser Technik kann bei der Nutzung von CSV-Datenträgern in einem Failover Cluster ein gewisser Teil des RAMs als Lese-Cache genutzt werden. Unter Windows Server 2012 mussten zur Aktivierung dieser Funktion die Datenträger offline und wieder online genommen wurden. Dies bedeutet, dass die Funktion entweder direkt bei der Installation eingeschaltet werden musste oder im späteren Betrieb eine Downtime geplant werden musste, damit die Funktion nachträglich aktiviert werden konnte. Nach der Aktivierung kann bis zu 20% des verfügbaren Speichers genutzt werden. Die Empfehlung von Microsoft lautet bei Hyper-V Hosts, die Größen allerdings sehr moderat zu setzen und gibt hier Größen von 512MB bis maximal 2GB vor. Bei Scale-Out File Server-Systemen kann eine größere Menge an RAM genutzt werden, hier können problemlos 4GB oder mehr genutzt werden. (Quelle: http://blogs.msdn.com/b/clustering/archive/2013/07/19/10286676.aspx)

Unter Windows Server 2012 R2 hat sich die Aktivierung und Nutzung dieser Funktion verbessert, dies liegt unter anderem daran, dass die Funktion schon direkt bei der Installation und Einrichtung aktiviert ist, die Größe des zu nutzenden Speichers allerdings bei 0MB liegt. Sie müssen hier nur noch die Größe des Speichers anpassen, ein offline und wieder online schalten und somit ein Ausfall der Systeme auf diesem Volume muss nicht mehr berücksichtigt werden. Bei einem hochverfügbaren Dateiserver unter Windows Server 2012 R2 müssen Sie allerdings beachten, dass die gleichzeitige Nutzung von Tiering und einem CSV Block Cache nicht möglich ist. Sie können diese Funktion zwar aktivieren, es wird allerdings kein RAM als Lesecache genutzt.

Warum erzähle ich Ihnen all diese Informationen? Ganz einfach, in unserem Fall setzen wir mit der Violin einen Scale-Out File Server ein, der nur über eine Art von Speicher verfügt und somit kein Tiering (im deutschen als Speicherebenen bezeichnet) nutzt. Die verbauten VIMMs sind zwar schon unglaublich schnell und haben eine sehr geringe Latenz, allerdings dürfte der in den beiden Servern verbaute RAM noch deutlich schneller sein. Wir aktivieren nun in beiden Systemen jeweils 8GB RAM, starten die Systeme durch und schauen uns an, welche Veränderungen der Benchmark zeigt.

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 4KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 8KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Fazit zur Nutzung des CSV Block Cache

Nach der Aktivierung des CSV Block Cache zeigte sich ein interessantes Verhalten: Bei Blockgrößen von 4KB und 8KB sanken die Daten fast komplett ein, nahezu alle Messwerte waren mit aktiviertem CSV Block Cache deutlich schlechter als ohne. Bei einer Blockgröße von 64KB waren die Unterschiede nicht mehr messbar, beide Tests zeigten annährend gleiche Werte. Interessant sind auch die Zugriffszeiten mit und ohne aktivierten CSV Block Cache: Während bei deaktiviertem Cache die Zugriffszeiten (bei 4KB und 8KB) konstant bei 1ms liegen, variieren diese mit aktiviertem Cache bei zwischen 0ms (bzw. nicht messbar durch den Performance Monitor) und 8ms.

Der Vergleich der jeweiligen Benchmarks zeigt direkt eine absolute Empfehlung: Schalten Sie den CSV Block Cache nicht ein. Die Aktivierung verschlechtert die Leistung signifikant.