News zu Microsoft SQL Server

Microsoft SQL Server on VMware – Verfügbarkeit

In diesem Tipp werden Überlegungen zum Betrieb von einem hochver­füg­baren 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 virtu­ellen Maschine für einen Microsoft SQL Server gibt es aller­dings ein paar Dinge zu beachten. Und nicht jede Hochverfügbarkeitslösung vom SQL Server ist auch für VMware vSphere geeignet oder sinnvoll.

Anfangsüberlegungen

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üg­baren 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 ausge­lagert 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 beant­worten sein.

VMware Verfügbarkeit vs. SQL Server Verfügbarkeit

Verfügbarkeit durch VMware Cluster

  • 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 virtu­ellen 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 ausge­fü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än­digen Wiederherstellungsmodus betrieben werden und Transaktionslog Backups alle 10 – 15 Minuten auf ein externes Laufwerk erfolgen.

Verfügbarkeit durch SQL Server AlwaysOn Failover Cluster

  • 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, gemein­samen 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 automa­tisch auf einem anderen, im Cluster verfüg­baren 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 aller­dings 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 virtu­ellen Maschinen angebunden werden, was laut Supportrichtlinien entweder über ein RAW Device oder über einen iSCSI Device im Betriebssystem reali­siert werden muss.

Verfügbarkeit durch SQL Server AlwaysOn Availability Groups

  • 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 aller­dings nur die IP Adresse für den Datenbanklistener zwischen den Knoten verschiebt. 

Durch die Synchronisierung entsteht aller­dings zusätz­licher Netzwerktraffic und der Speicher für die doppelte Datenhaltung.

Fazit

Wer eine nur moderate Verfügbarkeit benötigt, sollte auf die zusätz­liche Komplexität mit einem Failover Cluster oder Availability Groups verzichten und die Verfügbarkeit durch den VMware Cluster bereitstellen.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email