Microsofts SQL Server ist schon seit vielen Jahren ein sehr bewährtes Produkt am Markt und wird von vielen Unternehmen aufgrund seines guten Preis-/Leistungsverhältnisses gerne eingesetzt.
Wir als Microsoft Partner setzen den SQL Server als Produkt bei einer Vielzahl unserer Kunden ein und betreuen diese SQL Umgebungen auch.
In den letzten Jahren hat sich jedoch gezeigt, dass das Thema „Hochverfügbarkeit“ bzw. Ausfallssicherheit immer stärker in den Fokus rückt. Auch dafür bietet Microsoft für den SQL Server eine simple Lösung: Ein SQL Cluster bestehend aus zwei oder mehr Knoten.
Ein solches Cluster gibt es in zwei unterschiedlichen Ausführungen, wobei das sogenannte Active / Passive Cluster den deutlich höheren Verbreitungsgrad, bei den von uns betreuten Kundensystemen, hat.
Wo liegen nun die Unterschiede?
Schauen wir uns hierzu zunächst einmal den „Klassiker“, das Active / Passive Cluster an
Bei dieser Methode ist, wie der Name schon andeutet, einer der beiden Clusterknoten der aktive, während der andere passiv agiert. Beide greifen hierbei auf einen geteilten Speicher (shared storage) zu. Auf diesem liegen die eigentlichen Datenbanken, während die Knoten für die Ausführung der Dienste, bzw. im Clusterumfeld „Rollen“ verantwortlich sind. Sie sind also für die Verfügbarkeit einer SQL Cluster Instanz zuständig.
Auf beiden Knoten ist in diesem Fall eine SQL Clusterinstanz installiert, jedoch wird der Instanzdienst immer nur auf dem aktiven Knoten ausgeführt. Im Fehlerfall wird nun die Clusterrolle (SQL Dienst) auf einen anderen, verfügbaren Knoten verschoben. Dies entscheidet bei zwei oder mehr Knoten ein dafür vorgesehenes Quorum. Der eigentliche Schwenk und somit das Wiederherstellen der Verfügbarkeit dauert nur wenige Sekunden.
Dem gegenüber steht das Active / Active Cluster
Diese Methode wird auch als SQL „Always On“-Cluster bezeichnet. Anders als es die Bezeichnung eventuell erwarten lässt, wird hier mitnichten ein und dieselbe SQL Instanz mit gleichen Datenbanken auf zwei unterschiedlichen Clusterknoten gleichzeitig „aktiv“ betrieben. Mit der SQL Always-On Clustering ist aber zumindest ein lesender Zugang der zweiten, aktiven Instanz möglich. Vorstellbar wäre somit eine Lastverteilung bei sehr leseintensivem Datenbankzugriffen.
Mit der Funktion der SQL Always-On Availability Groups ist zusätzlich auch das Betreiben von Replikas, also Kopien einer SQL Instanz über zwei Clusterknoten möglich. Somit werden Änderungen aus der Instanz des Clusterknotens 1 in die Instanz des Clusterknotens 2 synchronisiert.
Welche Methode ist zu bevorzugen?
Diese Frage ist immer mit einem klassischen „kommt drauf an!“ zu beantworten. Unserer Erfahrung nach und auch den Kundensystemen, welche wir eingerichtet haben und betreuen, ist die erste Methode, also Active / Passive, die Regel.
Für ein Active / Active Cluster müssen im Vorfeld mehr Eventualitäten in Betracht gezogen werden und die Einrichtung ist deutlich aufwändiger. Der Vorteil liegt jedoch auf der Hand: Eine bessere Lastenverteilung bei hohen Zugriffszahlen.
Ein Active / Passive Cluster hingegen ist, gegenüber dem Active / Active Cluster, relativ schnell eingerichtet und konfiguriert. Mit genügend Erfahrung müssen im Vorfeld auch nicht allzu viele Punkte beachtet werden, denn im Grunde verhält sich die Instanz, auch im Cluster, zunächst wie eine „normale“ SQL Installation. Ein Nachteil der hierdurch entsteht ist die kurze „Downtime“ während des Clusterschwenks, sprich wenn wegen eines Fehlers der aktive Knoten gewechselt werden muss. Dieser bewegt sich jedoch, in der Regel, im einstelligen Sekundenbereich.
Letztlich ist also der Einsatzzweck maßgeblich entscheidend bei der Wahl der richtigen SQL Cluster Methode. Beide Methoden haben jedoch den entscheidenden Vorteil: Sie sind hochverfügbar!
Wie sieht eine klassische Kundenumgebung aus?
Doch genug von der grauen Theorie! Schauen wir uns einmal gemeinsam an, wie eine SQL Cluster Umgebung in der Regel bei unseren Kunden aussieht
Auf den ersten Blick fällt auf: Gar nicht mal so groß dieses Cluster!
Generell besteht eine klassische SQL Cluster Umgebung bei unseren Kunden aus zwei Knoten, welche beide mit einem aktuellen Windows Server Betriebssystem betrieben werden. Auf diesen wird, neben einigen weiteren Features, das Windows eigene Failover-Clustering eingerichtet.
Dieses bildet für das darauf aufsetzende SQL Cluster die Grundlage. Für jede benötige SQL Instanz wird diese jeweils pro Knoten installiert und konfiguriert. Anschließend wird entschieden, welcher Knoten der aktive und welcher der passive für die entsprechende SQL Instanz ist.
Auch ein paralleler Betrieb, sprich auf beiden Knoten laufen aktiv unterschiedliche Instanzen, ist bei unseren Kunden häufig der Fall. Es muss nur vorgebeugt werden, dass entsprechende Leistung (CPU & Arbeitsspeicher) für einen Fehlerfall vorhanden ist. Denn dann muss ein Knoten die gesamte Last tragen, also alle Instanzen aktiv bereitstellen.
Neben den Windows Servern für die SQL Instanzen wird natürlich auch ein Virtualisierungshost benötigt. Dieser wird in der Regel über eine ESX-Farm, bestehend aus mehreren Hosts, bereitgestellt. Damit werden dann, VMware typisch, die eigentlichen Cluster Knoten als virtuelle Maschinen bereitgestellt. Zusätzlich werden über ein angebundenes SAN RAW-Devices als gemeinsamer Speicher für die Knoten des Clusters definiert.
Unter Windows wird dieser Speicher dann entsprechend als Clusterspeicher eingerichtet und konfiguriert.
VMWare vSphere HA (Hochverfügbarkeit) sollte für SQL Server-Workloads aktiviert werden, so unsere als auch die Hersteller-Empfehlung.
In welcher Art und Weise und mit welchen VMWare Features gearbeitet wird, muss im Vorhinein geklärt werden, da Ihr SQL Server Lizenzmodell in Konflikt geraten könnte.
Gerne unterstützen wir Sie dabei, durch die Bereitstellung eines hochverfügbaren SQL Clusters einem zukünftigen Ausfall vorzubeugen.
Auch unsere Kunden haben bereits hinsichtlich Verfügbarkeit und Ausfallsicherheit positive Erfahrung sammeln können. Ein Cluster kann bei einem Systemausfall dazu beitragen, dass die Produktion und Arbeit trotzdem fortgesetzt werden kann.
Falls Sie noch mehr über die Möglichkeiten zum SQL Clustering erfahren möchten oder vielleicht auf den Geschmack gekommen sind, können Sie uns hierzu gerne jederzeit kontaktieren.
Gerne bieten wir Ihnen auch eine Analyse Ihrer bisherigen Infrastruktur mit einer Migrationsempfehlung an.