Lokale TempDb im SQL Server Cluster

29. August 2013

Eines meiner Lieblingsfeatures im SQL Server 2012 ist die offizielle Unterstützung der TempDb auf lokalen Laufwerken im Clusterbetrieb (AlwaysOn Failover Cluster).

Dadurch lässt sich selbst bei moderater TempDb-Belastung ein schneller und preiswerter Performancegewinn erzielen.

Clusterlaufwerke

Im Enterprisebereich kommen oft SQL Server Failovercluster zum Einsatz, um hohe Verfügbarkeit und bei Geoclustern auch K-Fall Sicherheit zu erreichen. SQL Server Cluster setzen allerdings bisher geclusterte Laufwerke voraus, also Datenspeicher, die entweder von allen Clusternodes gemeinsam genutzt oder für das Betriebssystem transparent synchron repliziert werden.

Der Grund hierfür ist, dass bei einem Schwenk einer SQL Server Instanz von einem Clusternode auf einen anderen diese neue Instanz dort exakt denselben Zustand ihrer Datenbankdateien vorfinden muss wie vor dem Schwenk. Sonst kann der Erhalt der Datenbankkonsistenz bei einem Schwenk nicht gewährleistet werden.

TempDb

Die Ausnahme von dieser Regel war schon immer die TempDb. Diese wird grundsätzlich bei jedem Instanzstart (also auch bei Clusterschwenks) neu initialisiert und braucht daher nicht persistiert werden. Da diese Datenbank oft auch stark belastet wird (z.B. durch Sortier-, Hash- und Spool-Operationen oder durch eingeschalteten Version-Store), haben findige DBAs Wege gefunden, die TempDb auf lokale Laufwerke auszulagern. Der große Haken an diesem Vorgehen war, dass dieses Vorgehen von Microsoft nicht supported wurde. Das hat nun mit SQL Server 2012 ein Ende.

Die TempDb braucht bestmögliche Performance und ist meist nicht besonders groß. Das sind ideale Voraussetzungen für den Einsatz von Solid-State-Disks (SSD). Selbst über einen lokalen SATA-Port angebunden bringen diese Laufwerke aufgrund der hohen IOPS Zahlen bereits einen beträchtlichen Performanceschub. Dieser kann durch den Einsatz von PCI-Express-Lösungen bei Bedarf noch einmal um eine Größenordnung gesteigert werden.

Eine lokale Anbindung der TempDb entlastet weiterhin auch den jeweiligen HBA zum Clusterlaufwerk, sodass mehr Bandbreite für die Logs und Datenbankdateien zur Verfügung steht.

Einrichtung

In SQL Server 2012 kann man bei der Einrichtung des ersten Clusternodes die Pfade zu den Basisdatenbanken angeben. Der Installer prüft, ob es sich dabei um Clusterlaufwerke handelt. Falls das TempDb-Laufwerk kein Clusterlaufwerk ist, wird jetzt nur eine Warnung ausgegeben. Diese besagt, dass auf den anderen Nodes der hier angegebene lokale Pfad ebenfalls existieren muss (und das der SQL Server Service dort Read/Write Rechte hat). Ansonsten würde ein Clusterschwenk fehlschlagen.

2817_localtempdb4[1]

Bei der Konfiguration mit dem lokalen Laufwerk kann man sich sogar überlegen, ob man auf RAID-Redundanz verzichtet. Persistente Daten werden dort nicht gespeichert und eine Redundanz ist durch das zusätzliche lokale Laufwerk auf den anderen Clusternodes gegeben. Wenn hardwareseitig nichts dagegen spricht, kann aber auch das lokale Laufwerk per RAID-1 Mirror gegen Ausfall abgesichert werden. Im Falle von SSDs ist dann allerdings auf ausreichende Performance des RAID-Controllers zu achten. Ältere Controller sind mit der hohen Performance einer SSD oft schlicht überfordert und bremsen diese aus oder produzieren schlimmstenfalls sogar Fehler. Und selbst aktuell erhältliche Controller garantieren kein optimales Ergebnis zumal auch die SSD-Performance rapide weiter wächst.

Fazit

Die Möglichkeit, die TempDb auf lokalen Laufwerken zu betreiben, ist ein sehr sinnvolles Feature, das nach Möglichkeit ausgenutzt werden sollte. Selbst wenn die TempDb aktuell kaum belastet wird, kann sich das beim nächsten Queryplan schon ändern. Wann immer möglich sollte dafür eine dedizierte SSD zum Einsatz kommen.