News zu Microsoft SQL Server
In diesem Tipp werden Überlegungen zum Betrieb von einem hochverfügbaren Microsoft SQL Server auf einer VMware vSphere Plattform beschrieben.
VMware vSphere ist in vielen Unternehmen der Standard für die Betriebssystem-Virtualisierung. Bei der Konfiguration einer virtuellen Maschine für einen Microsoft SQL Server gibt es allerdings ein paar Dinge zu beachten. Und nicht jede Hochverfügbarkeitslösung vom SQL Server ist auch für VMware vSphere geeignet oder sinnvoll.
Zunächst sollte man die Architektur des aktuellen VMware Clusters und der gewünschten Verfügbarkeit des SQL Servers betrachten.
Was soll mit einer hoch verfügbaren Lösung erreicht werden?
eine maximal Ausfallzeit von 15 Minuten?
ein Patchen der Windows oder Linux Betriebssysteme ohne Ausfall der Instanzen oder Wartungsfenster für die Anwendungen?
Sollen bestimmte Workloads auf weitere, nur lesbare Instanzen ausgelagert werden?
Benötigt man, aus Compliance Gründen, eine Möglichkeit zum Betrieb der Instanz in einem anderen Brandabschnitt oder Rechenzentrum?
Wenn man sich diese Fragen am Anfang stellt, sollte die Entscheidung, welche Lösung am Ende in Frage kommt, leichter zu beantworten sein.
Wiederherstellungszeit: ca. 5 – 10 Minuten
Installations- und Wartungsaufwand: gering
Wer einen VMware Cluster aus mehreren ESXi Knoten mit einem zentralen SAN oder vSAN betreibt, erhält damit schon eine Verfügbarkeit der virtuellen Maschinen im Falle eines Hardwareausfalls. Falls also einer der Hardware ESXi Knoten ausfällt, wird die virtuelle Maschine auf einem anderen Knoten neu gestartet. Das bedeutet wiederum, dass das komplette Windows System wie nach einem Power Off neu gestartet wird und die Datenbank anschließend auf Integrität vom SQL Server Dienst geprüft wird. Falls zum Zeitpunkt des Ausfalls gerade eine Transaktion ausgeführt wurde, ist diese nicht in der Datenbank. Die Datenbankdateien an sich könnten auch Schaden genommen haben. Eine vernünftige Backup Strategie ist in diesem Fall unabdingbar. Alle Benutzerdatenbanken sollten im vollständigen Wiederherstellungsmodus betrieben werden und Transaktionslog Backups alle 10 – 15 Minuten auf ein externes Laufwerk erfolgen.
Wiederherstellungszeit: ca. 1 – 5 Minuten
Installations- und Wartungsaufwand: Mittel bis Hoch (Je nach Anzahl der Instanzen)
Eine der ältesten Hochverfügbarkeitstechniken für den Microsoft SQL Server ist der Failover Cluster. Hierbei wird die Datenbankinstanz auf einem zentralen, gemeinsamen Speicher (SAN) betrieben und 2 oder mehr Knoten, stehen dem Cluster zur Verfügung. Dabei ist die Instanz immer auf einem der Knoten gestartet. Fällt einer der Knoten aus, startet der SQL Server Dienst automatisch auf einem anderen, im Cluster verfügbaren Knoten. Da hierbei der Neustart des gesamten Windows Systems entfällt und nur der SQL Server Dienst gestartet werden muss, verringert sich die Wiederherstellungszeit.
Durch die Konfiguration des Failover Clusters erhöht sich allerdings die Komplexität des Setups. Aus VMware Sicht muss vermieden werden, dass die zum Cluster gehörenden Knoten auf dem gleichen ESXi Host betrieben werden. Weiterhin muss ein SAN Speicher an die virtuellen Maschinen angebunden werden, was laut Supportrichtlinien entweder über ein RAW Device oder über einen iSCSI Device im Betriebssystem realisiert werden muss.
Wiederherstellungszeit: ca. 1 – 30 Sekunden
Installations- und Wartungsaufwand: Mittel bis Hoch (je nach Anzahl der Instanzen und Availability Groups)
Eine neuere Verfügbarkeitstechnik (seit dem SQL Server 2012) sind die AlwaysOn Availability Groups. Hierbei werden die Datenbanken zwischen einer oder mehreren Instanzen gespiegelt. d.h. hier wird auf mehreren Servern der Speicherplatz für die Datenbank benötigt, da der jeweils lokale Speicher benutzt wird.
Da die Datenbankkopien jederzeit synchron gehalten werden, ist der Failover innerhalb weniger Sekunden erledigt. Zu Grunde liegt hier ebenfalls ein Windows Server Failover Cluster, der allerdings nur die IP Adresse für den Datenbanklistener zwischen den Knoten verschiebt.
Durch die Synchronisierung entsteht allerdings zusätzlicher Netzwerktraffic und der Speicher für die doppelte Datenhaltung.
Wer eine nur moderate Verfügbarkeit benötigt, sollte auf die zusätzliche Komplexität mit einem Failover Cluster oder Availability Groups verzichten und die Verfügbarkeit durch den VMware Cluster bereitstellen.
Share this article