ZD-XL SQL Accelerator beschleunigt SQL Server

Datenbankabfragen profitieren von schnellen Speicheranbindungen und geringen Latenzzeiten. Daher liegt der Gedanke nahe, SQL-Datenbanken mittels aktueller Solid State Disk-Technologie (SSD) zu beschleunigen. Diesen bekannten Ansatz versucht der mittlerweile von Toshiba übernommene Hersteller OCZ Storage Solutions mit seiner Produktreihe „ZD-XL SQL Accelerator“ auf die Spitze zu treiben. Ein Modul der Generation 1.0 für den PCI-Express 8fach Steckplatz mit 800 GByte Speicherkapazität hat seinen Weg ins NT4ADMINS-Testlabor gefunden. Neben der Möglichkeit Cache- und Flash-Speicher für die Log-Dateien sowie die Datenbanken auf einem Modul zu Verfügung zu stellen, hebt der Hersteller auch seine Verwaltungsfunktionen hervor. Das Labteam stellt daher verschiedene Ansätze nach, um den Produktivbetrieb zu simulieren. Ob sich die versprochenen Performancegewinne in der Praxis nachvollziehen lassen, wird der folgende Beitrag zeigen.

Bei der Beschleunigung von Datenbankanfragen, wie sie beispielsweise bei Microsofts SQL-Server wünschenswert sind, können verschiedene Wege beschritten werden. Einen traditionellen Ansatz stellt das Splitten der einzelnen Datenbank-Dateien auf verschiedene Hard Disk Drives (HDD) dar. Dabei können die einzelnen Datenbank-Files auf jeweils eigene Festplatten, beziehungsweise Festplattenarrays, zugreifen und die Arbeitsauslastung so besser auf mehrere Spindeln verteilen.

Eine andere Möglichkeit stellt das Verfügbarmachen der Daten im Hauptspeicher der Systeme (In Memory Database) dar: Hier werden die Datenbankdateien, oder die wichtigsten Teile davon, im Hauptspeicher (RAM) vorgehalten, und die Anfragen oder Schreibzugriffe direkt im RAM ausgeführt. Folglich können diese Zugriffe, bedingt durch die hohe Geschwindigkeit des RAM-Speichers, enorm beschleunigt werden. Allerdings muss die Datenbank auch irgendwann wieder auf persistente Massenspeicher, beispielsweise in Form von Snapshots, geschrieben werden, da sich RAM-Bereich naturgemäß nur als Zwischenspeicher, und nicht für eine Langzeitarchivierung eignet.

Als dritte Variante kommen heute oftmals Flash-Speichersysteme anstelle von Massenspeicherarrays auf Festplattenbasis zum Einsatz. Da die Preise für Flash-Speicher allerdings noch um ein Vielfaches höher liegen als vergleichbare Speicherkapazitäten auf HDD-Basis, lohnt es sich meist nicht für Unternehmen, die kompletten Datenbankdateien in den schnellen Flash-Speicher auszulagern. Daher bietet sich es an, die Vorteile aus allen Welten zu nutzen: In den jeweiligen Datenbankservern kommt neben der klassischen Speicheranbindung noch eine PCI-Express Karte mit Flash-Speicher zum Zuge. Somit können bestimmte Anfragen direkt auf die bereits im Flash-Speicher vorgehaltenen Daten zugreifen, und Schreibvorgänge auf die Massenspeicher wie etwa per iSCSI oder lokal angeschlossene HDDs können so entzerrt werden. Folglich werden manche Operationen erst über den Hauptspeicher in den Flash-Speicher und später auf die jeweiligen Massenspeicher geschrieben. Die zeitkritische Komponente bestehend aus verfügbarer Bandbreite und hoher Latenzzeit von Festplattenspeichersystemen lässt sich so entschärfen.

Flash-Speicherkapazität je nach Datenbankgröße einplanen

Umsichtige Datenbankbetreuer planen in bestehende Systeme oftmals eine Cache- und Volumen-Zwischenspeicherlösung auf Flash-Basis ein. Bei dieser Vorgehensweise kommt es neben der korrekten Konfiguration im SQL-Server und der umsichtigen Planung der einzusetzenden Flash-Speichergrößen auch auf Details in der Speicherkonfiguration selbst an: Neben dem Einsatz von Cache für die Applikation selbst ist es notwendig, auf den Flash-Karten ein gesondertes Volume, quasi als normalen Datenträger anzulegen.

Die Flash-Karten von OCZ sind in der Lage, auf einer Speicherkarte sowohl eine Bereich als Cache als auch Teil als Volume anzulegen. Dies kann über das Webinterface konfiguriert und gesteuert werden. Somit sind im Vorfeld Überlegungen zu treffen, in welchem Umfang sich der benötigte Zwischenspeicher und die benötigte Speichermenge für das Flashlaufwerk addieren.

Die ZD-XL-Flash-Speicherkarten sind momentan in drei verschiedenen Speichergrößen verfügbar: 600 GByte, 800 GByte und 1600 GByte. Dies erhöht die Flexibilität, um je nach Größe der zu beschleunigen SQL-Datenbank entsprechende Flashkapazitäten zur Verfügung zu stellen. In unserem Testaufbau kommt die Variante mit insgesamt 800 GByte Kapazität (siehe Bild 1) zum Einsatz.

Einbau und Installation des ZD-XL

In unserem Vergleichstest findet ein System mit dem Betriebssystem Windows Server 2012 und der Anwendung SQL Server 2012 Einsatz. Hier ist eine I7-CPU mit 3,4 GHz (Bezeichnung CPU E-3770) und 4 physikalischen Kernen, 32 GByte RAM und SSD-Laufwerk für das Betriebssystem, sowie zwei HDD-Laufwerke für die Daten verbaut. Zusätzlich wird noch eine NAS mit sechs Festplatten im RAID-0-Verbund vom Hersteller Promise (NS6700) per iSCSI angebunden. Somit bewegen wir uns im Konfigurationsumfeld eines kleinen bis mittelständigen Unternehmens.

Die ZD-XL Einsteckkarte wird im Vorfeld der Testläufe in den verfügbaren PCI-Express Grafikkartenslot (PCI-E) verbaut wie in Bild 2 ersichtlich. Ein eigener Stromanschluss für die Steckkarte ist nicht nötig, die benötigte Versorgung übernimmt der PCI-Express-Slot. Die maximal zur Verfügung gestellte Leistung ist somit auf 25 Watt (PCI-E x1 bis x8) beziehungsweise 75 Watt begrenzt (PCI-E Slot x8 bis x16 für Grafikkarten).

Die Spezifikation von OCZ beziffert die Leistungsaufnahme unseres Testgeräts auf 23 Watt im Leerlauf und auf 26 Watt unter Volllast. Daher haben wir die Erweiterungskarte im Grafikkartensteckplatz eingebaut. Die maximale Transfergeschwindigkeit in unserem Testsystem liegt bei 4000 MByte pro Sekunde (PCI-E x8 Version 2.0), vermutlich wird der Flaschenhals unseres Testsystems nach Aktivierung des Flash-Speichers wohl bei der Intel I7-CPU zu finden sein.

Nach dem Einbau wird das System gestartet und die mitgelieferten Treiber sowie die entsprechende Software installiert. Es folgt ein obligatorischer Neustart, nun kann der Flash-Speicher über ein Webinterface angesprochen werden. Im ersten Schritt definiert der Systembetreuer noch ein Login Passwort, und konfiguriert als nächstes das Verhältnis von Cache-Speicher und Flash-Laufwerk. In unserem Testlauf verwendet das Labteam 150 GByte als Laufwerk, und die restlichen 595 GByte werden als Cache für die Beschleunigung unserer Festplattenarrays definiert. Dies ist in Bild 3 deutlich gemacht. Um den ersten Testlauf zu starten sind allerdings noch weitere Schritte nötig.

Testdaten für den Leistungsvergleich

Für den Vergleichstest kommen zwei vom Hersteller zu Verfügung gestellte Datenbanken zum Einsatz. Die Dateien werden im Vorfeld auf die lokalen HDDs beziehungsweise auf die per iSCSI angebundene NAS übertragen. Für den Benchmark mit den lokalen Festplatten kommen, neben der SSD mit dem Betriebssystem und der Auslagerungsdatei, noch zwei Festplatten mit jeweils 1 TByte und 7200 Umdrehungen pro Minute (rpm) zum Einsatz.

Im NAS-System von Promise sind 6 Festplatten mit jeweils 1 TByte zu einem RAID-0 zusammengefasst und per Gigabit-Ethernet angebunden. Sowohl die lokalen HDDs als auch das iSCSI-Laufwerk wurden mit dem NTFS-Dateisystem und 64 KByte Blockgröße formatiert. Das entspricht der Microsoft-Vorgabe für den Betrieb von SQL-Datenbanken.

Nun kopiert das Labteam die zwei Testdatenbanken nach den Spezifikationen des Transaction Processing Performance Council (TPC) auf die lokalen Datenträger (TPC-H Datenbank) beziehungsweise auf das iSCSI-Drive (TPC-C Datenbank). Die Dateigröße bei TPC-C beträgt knapp 500 GByte und bei TPC-H etwa 800 GByte. Diese von TPC standardisierten Testdatenbanken ermöglichen es, bei gleicher Dateigröße einen direkten Leistungsvergleich auch auf verschiedenen Systemen durchzuführen. Daher sind sie ideal für unseren Benchmark geeignet, da im Ablauf zwar der Cache unseres Flashlaufwerks zugeschaltet werden kann, die Datenbankgröße insgesamt allerdings gleich bleibt.

Konfiguration der SQL-Datenbanken für die Ausgangswerte

In unserem Testaufbau verwenden wir SQL-Server 2012 inklusive Service Pack 1 (Build 11.0.3128.0; der SQL Server wird ohne Virtualisierungsschicht betrieben) zusammen mit dem Betriebssystem Windows Server 2012 Standard. Nach der Installation verändert das LAB-Team noch einige Einstellungen im SQL-Server und fügt die erste Datenbank (TPC-C) hinzu. Im SQL-Server lässt sich die Ausnutzung des Hauptspeichers noch konkretisieren. Um gleiche Voraussetzungen zu schaffen definiert der Datenbank Administrator die maximale Hauptspeicherauslastung.

Hier gilt bei SQL die Faustregel, dass 25 Prozent des Hauptspeichers für das Betriebssystem verwendet, und 75 Prozent für die SQL-Instanzen verfügbar gemacht wird. Nachdem im Server 32 GByte Hauptspeicher verbaut sind, legt das Labteam die für SQL verfügbare Speichermenge auf maximal 24 GByte fest.

Die Wachstumsrate der Datenbank sowie der zugehörigen Logdatei wird vom SQL-Administrator auf 10 Prozent festgelegt. Falls also testbedingt die beiden Dateien vergrößert werden müssen (wegen Schreibzugriffe und Logdateieinträgen), hebt SQL die Dateigrößen gleich um 10 Prozent an. Standardmäßig sind hier schrittweise Vergrößerungen um 1 MByte definiert. Die Veränderung soll verhindern, dass sich Ungenauigkeiten durch eine Vielzahl von Vergrößerungsschritten im laufenden Test einschleichen.

Um diesen Faktor bei den Log-Dateien zusätzlich zu unterbinden wird hier gleich eine relativ große Logdatei mit einer Dimension von 30 GByte festgelegt. In Bild 4 ist die Transferrate beim Erstellen dieser Logdatei (auf den iSCSI-Datenträger mit der Bezeichnung „Z“) sichtbar. Im Falle der TPC-H Datenbank wird noch die temporäre Datenbank (tempdb) einen wichtigen Faktor darstellen. Hier werden alle zwischenschritte der Datenbank Operationen ausgeführt, bevor diese in die eigentliche Datenbank geschrieben werden. Daher sind die beiden Dateien „tempdev“ sowie „templog“ für die Gesamtperformance von hoher Bedeutung, und werden daher auf einem eigenen lokalen Laufwerk untergebracht.

Testlauf ohne Beschleunigung

Nachdem die Vorbereitungen abgeschlossen wurden, startet der Datenbankadministrator den ersten Test mit der TPC-H Datenbank, die wie oben erwähnt auf der per iSCSI angebundenen Netzwerkfestplatte bereit liegt. Um Datenbankanfragen zu generieren setzt der das NT4ADMINS-Datenbankteam hier die Freeware „HammerDB“ in der Version 2.15 ein. Es wird ein Testskript erstellt, das 15 Minuten lang Anfragen an die Datenbank erzeugt, wie Bild 5 zeigt. Die Anzahl der virtuellen Datenbankbenutzer wir auf 100 festgesetzt. Die Ausgabe der Testwerte in „transactions per minute“ (TPM) sowie „new operation per minute“ (NOPM) ermöglicht einen direkten Vergleich mit späteren Benchmarks. Im Durchschnitt erzeugt das Basis-Setup 49127 TPM und 10624 NOPM.

Für den zweiten Testlauf mit der TPC-C Datenbank wird ein anderer Weg beschritten. Hier kommt ein Script des Herstellers zum Einsatz, das in 22 verschiedenen Abfragen die Datenbank belastet. Genauere Informationen bezüglich der Testdatenbanken können auf der Webseite des Transaction Processing Performance Council eingeholt werden.

Das Script gibt in einem Logfile die Zeit in Sekunden an, in der die Abfragen beantwortet werden konnten. Somit ist auch ein direkter Vergleich der erzeugten Werte mit den späterer Testläufe gegeben. Hier benötigt die Batchdatei etwa sechs Stunden und 30 Minuten für einen kompletten Durchlauf.

Beschleunigtes Setup

Nach dem Abschluss der Ausgangswertermittlung werden die Ausgangsparameter verändert, und der Flash-Speicher kommt ins Spiel. Die ressourcenhungrigen Dateien wie tempdev, templog und die Datenbank-Logfiles werden im SQL-Verwaltungstool auf den Datenträger mit der Bezeichnung „F“ verschoben. Wie schon oben angesprochen handelt es sich dabei um eine Partition auf der OCZ Flash-Speicherkarte. Die Datenbank an sich wird jetzt noch nicht auf den Flash-Speicher verschoben. Um diese Files zu cachen werden die jeweiligen Datenträger im Webinterface des ZD-XL Accelerators entsprechend markiert. Dies ist in Bild 6 deutlich gemacht. Allerdings ist so nur die Grundvoraussetzung für den Einsatz des Caches definiert.

Um den Vorgang zu starten sind nun verschiedene Möglichkeiten gegeben. Zum einen kann die Software nach einer gewissen Anlernzeit die häufig benötigten Daten eigenständig identifizieren. Der ZD-XL soll somit die oft benötigten Daten Sätze automatisch anhand vorangegangener Abfragen erkennen und im Cache prophylaktisch bereithalten. Diese oft verwendeten Teile der Datenbank werden als „Hot Data“ bezeichnet. Zum anderen kann die Datenbank, falls der Speicherplatz ausreicht, komplett in den Cache geladen werden. Das Laborteam von NT4ADMINS entscheidet sich aus Gründen der Vergleichbarkeit bezüglich der Testergebnisse und der Dateigröße der Testdatenbanken für die zweite Variante.

Warmup der benötigten Daten

Um für unsere folgenden Benchmarks immer gleiche Grundvoraussetzungen zu schaffen, setzt das NT4ADMINS-Team vor jedem Testlauf mit Flashbeschleunigung das OCZ Warmup Utility wie in Bild 7 sichtbar ein. Diese Software sorgt dafür, dass alle benötigten Datenbankdateien im Vorfeld von unseren Festplatten in den Cache geladen werden. Hier spricht man von einem sogenannten „Aufwärmen“ beziehungsweise vom „Warmup“ des Caches. Dieser Vorgang dauert je nach Datenmenge in unserem Aufbau zwischen ein und drei Stunden.

Ermittlung der Performance mit zugeschaltetem Flash-Speicher

Nach dem abgeschlossenen Warmup des Flash-Speichers startet der Administrator nochmals den gleichen Vorgang, allerdings nur für einige Minuten. Das hat den Hintergrund, dass im Webinterface des ZD-XL Accelerator die Trefferchance der Cacheanfragen ermittelt werden kann. Diese „Hitratio“ zeigt den prozentualen Wert der Trefferwahrscheinlichkeit an. Je näher dieser Wert im Test an der idealen Marke von 100 Prozent liegt, desto besser. So kann der Erfolg des Warmups vor dem Start des Testlaufs nochmals verifiziert werden, da naturgemäß beim Warmup der gleichen Daten dieser bei 100 liegen muss. Nachdem dies geprüft wurde, startet der Datenbankadministrator den Benchmark mittels HammerDB.

So wie beim vorangegangen Testlauf der TPC-H Datenbank werden 100 virtuelle User verwendet, die 15 Minuten lang Anfragen an die Datenbank stellen. Hier liegen die ermittelten Werte bei 631513 TPM und 136232 NOPM. Die Hitratio schwankt bei diesem Test zwischen 96 und 99 Prozent. Diese Werte stellen in unserem Testsystem das Ende der Fahnenstange dar, die verwendete I7-CPU erreicht mit diesen Werten bereits eine 100 prozentige Auslastung auf allen Kernen.

Für den letzten Benchmark wird, wie schon beim vorangegangenen Test der TPC-C Datenbank, das Script des Herstellers eingesetzt. Die 22 verschiedenen Abfragen brauchen mit der Unterstützung des Flash-Speichers nur einen Bruchteil der Zeit, so dass die Aufgaben nach etwas über 26 Minuten abgeschlossen sind. Bei diesem Lauf bewegt sich die Hitratio zwischen 95 und 100 Prozent. Auch hier stoßen wir auf unser Limit, die CPU ist bei diesen Aufgaben ebenfalls komplett ausgelastet.

Fazit

Der Einbau und die Installation des Testgeräts stellt Systembetreuer vor keine allzu großen Hürden, einzig das Augenmerk auf die passende Ansteuerung  mittel PCI-E x8 Schnittstelle sollte besonders geachtet werden, da manche Mainboard-Hersteller für manche mechanisch passende Steckplätze nur einen PCI-E x4 Support verwenden, und damit quasi die Hälfte der Bandbreite ungenutzt bleibt. Etwas kniffliger gestalten sich die Konfiguration des Flash-Speichers und die Einstellung der SQL-Parameter. Erfahrene Datenbankadministratoren können allerdings dieselben Grundregeln wie etwa die Optimierung der TempDB-Dateien und der Logfiles anwenden.

Mit dem Produkt von OCZ Storage Solutions erreichen wir in unserem Testaufbau deutlich höhere SQL-Performance als ohne Beschleunigung. Hier kommt etwa der Faktor 13 (bei TPC-C) beziehungsweise 15 (bei TPC-H) an Performancegewinn zum Tragen. Den vom Hersteller angegebenen Faktor 25 konnten wir in unserem Testaufbau nicht nachvollziehen. Das liegt allerdings wie schon angesprochen an der eingesetzten CPU. Schließlich stützt sich die NT4ADMINS-Testumgebung nur auf eine Single-CPU. In den Testläufen war die Limitierung durch die CPU klar ersichtlich, die Auslastung lag in den beschleunigten Benchmarks bei 100 Prozent. Hier ist also noch Luft nach oben, vor allem in Multi-CPU-Umgebungen. In allen Jobs werden die zugewiesenen 24 GByte an Hauptspeicher nach jeweils circa 1 Minute voll genutzt, die CPU limitiert bei den beschleunigten Testläufen die Gesamtperformance.

Dass sich die Hitratio immer knapp unter 100 Prozent bewegt ist dem Umstand zuzuschreiben, dass die kompletten Datenbankdateien Platz auf dem Flash-Speicher finden. Sollte die Datenbank wesentlich größer als die Speichergröße des SD-XL sein, so wird dieser Wert und damit die Gesamtperformance erfahrungsgemäß weiter absinken. Hier entscheidet dann die Vorhersage bezüglich der „Hot Data“ und damit die Vorhaltung der benötigten Dateien im Flash-Speicher, während unbenutzte Teile der Datenbank aus dem Speicher aus Kapazitätsgründen entfernt werden.

Systembetreuer sollten ihr Augenmerk besonders auf die Flash-Speichermodule von OCZ legen, wenn technisch nur der Einbau einer einzigen Karte in Frage kommt. Schließlich können auf einem Modul sowohl für Windows sichtbare Volumens als auch der Cache für die Datenbankbeschleunigung angelegt werden. Auch einen Blick sollten diejenigen Datenbankadministratoren riskieren, wie ihre Dateien auf iSCSI beziehungsweise SAN (Storage Area Network) lagern, und somit an die Limitierungen der Netzwerkverbindungen stoßen. So lassen sich beispielsweise die Warmup-Jobs vor Arbeitsbeginn im Unternehmen legen, und die Anwender können sofort von den Performancegewinnen profitieren.

Preise und Support-Upgrades

Die Preise für die ZD-XL-Karten liegen zwischen 7700 Dollar (etwa 5700 Euro) für das Einstiegsmodell mit halber Bauhöhe, und 15.200 Dollar (etwa 11.250 Euro) für das Modell mit der 1600 GByte Ausstattungsvariante (volle Bauhöhe). Das eingesetzte Testgerät mit 800 GByte Speicherkapazität geht für 9700 Dollar (knapp 7200 Euro) über die Ladentheke. Die Preise verstehen sich ohne Mehrwertsteuer und mit einem Einjahres-Support (9 Stunden Supportverfügbarkeit bei 5 Tagen die Woche). Es besteht die Möglichkeit diese Supportzeiten kostenpflichtig zu verlängern, beispielsweise kostet ein Upgrade auf drei Jahre Support (mit 24 Stunden bei 7 Tagen Verfügbarkeit) für unser Testgerät laut Hersteller 2200 Dollar, also etwa 1630 Euro (Nettopreis ohne Mehrwertsteuer).

Florian Huttenloher

Sonderaktion des Herstellers

Mit der Vorstellung der 300 GByte Kapazität des ZD-XL SQL Accelerator, startet OCZ ein Einführungsangebot bis Ende März 2014. Enthalten sind die neue 300 GByte HH-Kapazität sowie die bereits eingeführte 800 GByte FH-Kapazität der ZD-XL SQL Accelerator-Lösung.

Für Bestellungen im Zeitraum des Einführungsangebots, fallen für die Hard- und Software-Kombination ZD-XL SQL-Accelerator im Vergleich zu einer reinen Hardware-Lösung PCIe Z-Drives R4 PCIe-SSD der gleichen Kapazität keine Mehrkosten an:

• ZDXLSQL-HH-300G hat den gleichen Preis wie das ZD4RM84-HH-300G ($ 3,140)
• ZDXLSQL-FH-800G hat den gleichen Preis wie das ZD4RM88-FH-800G ($ 6,626 statt $ 9.700)

Der Preis beinhaltet zudem drei Jahre Garantie und einen Support für drei Jahre (bei 9 Stunden und 5 Tage die Woche).

Die 600 GByte und 1,6 TByte-Modelle sind nicht im Einführungsangebot enthalten.

Axel Böhme, OEM Sales Manager Enterprise, OCZ Storage Solutions