SQL Server – Always On – Was bedeutet das?

Seit dem SQL Server 2012 gibt es „ein neues“ Feature mit dem Namen „Always On“ oder sollte ich besser sagen mit dem Buzz-Word „Always On„…
Immer wieder erhalte ich Kunden-Anforderungen, „wir möchten gerne einen SQL Server mit Always On“, leider muss ich dann immer wieder nachfragen, was der Kunde denn unter Always On versteht bzw was er für Anforderungen an den SQL Server stellt. Nur aus diesen Anforderungen kann man dann ableiten oder schlussfolgern, was der Kunde sich wünscht. Daher möchte ich hier kurz auf die Unterschiede bzw Möglichkeiten von Always On eingehen bzw die neuesten Optimierungen in SQL Server 2016 eingehen.

Unterschiede zwischen beiden HA-Lösungen?

Beide Lösungen haben grundlegend andere Ansätze, welche in den folgenden Absätzen näher erläutern möchte. Gemeinsam haben beide zwar das Windows Server Betriebssystem, das .NET-Framework und das Cluster-Instance-Feature von Windows. Aber sie unterscheiden sich im Detail bzw in der Verwendung dieser „Basis“ und damit auch in der Installation und im Betrieb des SQL Servers. Durch diese Unterschiede muss man sich nun auch Gedanken zu anderen Desaster-Recovery (DR) Szenarien machen, da sich das Handling und die Automatismen ändern. Dazu weiter untern mehr 😉

Always On Failover Cluster Instanzen (AlwaysOn FCI)

Always On Failover Cluster Instanzen sind im Grunde genommen, ein herkömmliches Failover-Cluster, welches wir schon aus den vergangenen Versionen des SQL Servers kennen. Microsoft hat nun (bzw seit der Version 2012) einen anderen Namen für seine Hochverfügbarkeits-Lösungen gefunden und fasst diese neuen Lösungen unter dem Begriff Always On zusammen.

, heißt im Fehlerfall wird die komplette Instanz innerhalb des Windows-Clusters auf einen noch verfügbaren Ausfall-Knoten verschoben. Somit wird sichergestellt, dass der komplette SQL Server „immer“ verfügbar ist, eben „Always On“. Micrsoft setzt hier auf seine bewährte Aktiv/Passiv-Cluster-Technologien, bei der IP-Adresse, Servername und Storage zu einer logischen Einheit, der Cluster-Ressource verknüpft werden. So schwenken im Fehlerfall alle notwendigen Ressourcen komplett im Cluster, dieser Vorgang ist völlig automatisiert und unabhängig von der Anzahl der verfügbaren Clusterknoten.

Die Always On Failover Cluster-Instanzen sind aus meiner Sicht die einfachste und gängigste Methode um einen SQL Server hochverfügbar zu machen. Ab der SQLServer Version 2014 werden auch Cluster Shared Volumes unterstützt, was die Storage-Anbindung bzw -Aufbau vereinfachte.

Always On Availability Groups (AlwaysOn AG)

Auch wenn es das Feature AlwaysOn Availability Groups schon seit dem SQL Server 2012 gibt, so wurde in den zwei folgenden Versionen (2014, 2016) vieles optimiert, angepasst und sogar hinzugefügt. Damals wurden sie eingeführt, um die alten Mirroring-Technologien zu ersetzen und so eine robuste Lösung für Hochverfügbarkeit anzubeiten. AlwaysOn Availibility Groups ermöglichen einem DBA zwei SQL-Instanzen miteinander zu verbinden, um Repliken der Datenbanken zu hosten damit diese synchron gehalten werden. Diese Technologie hat sich mittlerweile zum Standard in Sachen businesskritischer SQL Server gewandelt.

Der SQL Server 2016 bringt einige wesentliche Verbesserungen für die Always On-Verfügbarkeitsgruppen mit, wie zB:

  • Round-Robin Loadbalancing auf lesbaren Replikaten
  • Erhöhte Anzahl von Auto-Failover-Zielen
  • Verbesserte Log-Replikation-Durchsatz und Redo-Geschwindigkeit
  • Unterstützung für Group-managed Service Accounts
  • Unterstützung für verteilte Transaktionen (DTC)
  • Direct-Seed von neuen Datenbankrepliken

Fazit zu beiden Always On Lösungen

Mit beiden Hochverfügbarkeitslösungen kann man hohe 99,x Verfügbarkeiten erreichen, es gibt für beide aber auch spezielle Anforderungen und Szenarien mit denen man sich vorher beschäftigen muss. Jede Solution hat ihre Vor- und Nachteile, sind aber grundsätzlich uneingeschränkt für einen normalen Betrieb einsetzbar… man kann sie aber auch miteinander kombinieren 😉 oder in der Cloud realisieren… Wenn es keine besonderen Anforderungen wie zum Beispiel „readable Secondary“ gibt, dann ist meine bevorzugte Lösung immer das Always On Failover Cluster, weil es „einfacher“ zu installieren und betreuen ist, günstiger ist es in der Regel auch.