News
DBA-Tipp: Microsoft SQL Server - Hochverfügbarkeit mit AlwaysOn Failover Cluster

Die Information ist ein schnelllebiges Gut. Jeden Tag werden wir mit hunderten Informationen zugemüllt. Deshalb sind wir bestrebt uns auf das Wesentliche zu konzentrieren und nur substantiell nachhaltige Informationen bereitzustellen.

Icon Unternehmen

Die schon in der Standard Lizenz enthaltene Funktion des AlwaysOn Failover Clusters bietet einen günstigen Einstieg in den Bereich der Microsoft SQL Server Hochverfügbarkeit.

Die auf dem Windows Server Failover Cluster (WSFC) aufsetzende Lösung “SQL Server AlwaysOn Failover Cluster” bietet eine erprobte und stabile Hochverfügbarkeitslösung für eine oder mehrere SQL Server Datenbanken. Bis zu zwei Knoten können mit der Standard Lizenz betrieben werden. Für mehr Knoten ist die Enterprise Edition nötig.

Zu beachten ist, dass der AlwaysOn Failover Cluster und die neuen AlwaysOn Availability Groups zwei verschiedene Hochverfügbarkeitslösungen sind und auch jeweils eigenständig installiert und konfiguriert werden müssen.
Vom Prinzip her ist der AlwaysOn Failover Cluster der altbekannte SQL Server Failover Cluster mit dem Windows Server Failover Cluster als Unterbau.

Wie andere Clusterlösungen auch, fasst der AlwaysOn Failover Cluster zwei oder mehr logische Knoten zu einer Einheit zusammen, sodass bei einem Ausfall eines Knotens die Verfügbarkeit weiterhin gewährleistet ist.

Wichtig beim Failover Cluster ist es, dass die Datenbank zwingend auf einem gemeinsamen Shared Storage liegen muss, auf das jeder Knoten Zugriff hat. Das ist auch der größte Unterschied zu den AlwaysOn Availability Groups, die keinen gemeinsamen Speicher benötigen.

Voraussetzungen und Kosten


Mit der Standard Edition der SQL Server Versionen 2012, 2014 und 2016 können maximal zwei Knoten in einem AlwaysOn Failover Cluster betrieben werden. Mit der Enterprise Edition ist das Betriebssystem-Maximum möglich. Das sind bei Windows Server 2012 R2 maximal 64 Knoten.

Des Weiteren müssen folgende Voraussetzungen erfüllt sein:

  • Die Windows Systeme sind als Windows Server Failover Cluster Knoten konfiguriert (WSFC).
  • Alle Systeme haben Zugriff auf einen zentralen Datespeicher (SAN mit FC oder iSCSI, oder ein SMB3 Share)
    • zum einen für das Quorum
    • zum anderen für die Datenbankdateien
  • Der Windows Server ist mindestens Version 2008R2 (Enterprise oder Datacenter) oder Version 2012 / 2012R2 (alle Editionen).
  • Alle Windows Server müssen sich in der selben Active Directory Domäne befinden.
  • Die Windows Server dürfen nicht als Domaincontroller konfiguriert sein.
     

Weitere Möglichkeiten und Alternativen


Der klassische, hier beschriebene, AlwaysOn Failover Cluster eignet sich vor allem für lokale Umgebungen und kann den Ausfall eines Datenbankservers abzufangen.
Nicht geeignet ist der Failover Cluster für standortübergreifende Szenarien oder wenn bestimmte Leseoperationen (Für Reports etc.) auf eine Read Only Datenbank ausgelagert werden sollen.
Dafür eignen sich die AlwaysOn Availability Groups, die bis zu acht Knoten bedienen können, davon zwei synchron. Asynchrone Replikas können schreibgeschützt gelesen und somit für die Reporterstellung benutzt werden.
Eine weitere Technik, die schon seit dem SQL Server 2000 implementiert ist, ist das SQL Server LogShipping. Hierbei werden Transaktionslog Backups von einem Server zu einem anderen kopiert und auf dem Backupserver automatisch eingespielt. So kann eine Wiederherstellung bis zum Zeitpunkt des letzten übertragenen Transaktionslog Backups erfolgen. Die Intervalle können durchaus (je nach Größe der Datenbank und Geschwindigkeit der Netzwerkverbindung) auf 5 Minuten heruntergebrochen werden.

Aufbau und Architektur

Das folgende Schaubild stellt die grundsätzliche Funktionsweise eines typischen AlwaysOn Failover Cluster dar.

Schaubild Microsoft SQL Server AlwaysOn Failover Cluster

Fazit


Sofern wenigstens zwei vergleichbare Datenbankserver in der Infrastruktur betrieben werden, spricht nichts dagegen, diese Server zu einem Cluster zu verbinden und die Datenbanken dort hochverfügbar in einem AlwaysOn Failover Cluster zu betreiben. Abgesehen vom Einrichtungsaufwand entstehen dafür keine nennenswerten Mehrkosten. Im Gegenzug profitieren die Datenbanken und damit letztlich die Endanwender und das Unternehmen von einer höheren Gesamtverfügbarkeit, besserer Hardwareauslastung und gesteigerter Flexibilität.