SQL Server – Always On – Was bedeutet das?
This post might contain affiliate links. We may earn a commission if you click and make a purchase. Your support is appreciated!
Seit dem SQL Server 2012
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.
This post might contain affiliate links. We may earn a commission if you click and make a purchase. Your support is appreciated!
Björn arbeitet auch weiterhin aus Mexiko als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.
Amazon.com Empfehlungen
Damit ich auch meine Kosten für den Blog ein wenig senken kann, verwende ich auf diese Seite das Amazon.com Affiliate Programm, so bekomme ich - falls ihr ein Produkt über meinen Link kauft, eine kleine Provision (ohne zusätzliche Kosten für euch!).
Auto Amazon Links: Keine Produkte gefunden.
Hallo Hr. Peters,
ich habe einen Kunden, der einen SQL-Cluster fährt aber ohne „Always on AG“. Macht das Sinn? Hat der SQL Cluster noch andere Vorteile gegenüber einer „normalen“ DB auch wenn man kein Always on macht? Bin kein SQL-Crack, daher die „naive“ Frage.
Gruß
S. Dreher
Hallo Herr Dreher,
es kommt darauf an, was man erreichen möchte und was man bereit ist für das gewünschte Lösungsziel auszugeben.
AlwaysOn AvailabilityGroups gibt es zwar auch schon in der Standard Edition, aber eben nur als Basic AOAG mit einer Datenbank pro AG, für einen Sharepoint mit seinen zahlreichen Datenbanken macht das zum Beispiel überhaupt keinen Sinn, da muss dann eine Enterprise Edition her, die dann entsprechend kostet.
Das „alt-bewährte“ Failover Cluster ist auch eben „nur“ ein SQL Server, der auf zwei Knoten ausfallsicher dargestellt wird, aber die jeweilige Instanz immer nur auf einer Seite aktiv ist… bei einer AOAG sind immer beide Seiten aktiv und können entsprechend auch (EE) eine Art Loadbalancing darstellen.
Rein technisch hat das normale FailoverCluster also weiterhin seine Gründe aka Darseins-Berechtigung, eine AOAG kann aber gewisse Vorteile bieten, wenn das Budget mitspielt. (Abwägung – Bedarf/Nutzen/Kosten)
Guten Tag Herr Peters,
ich bin auf Ihren Artikel gestoßen um die Unterschiede zwischen einer Always ON Verfügbarkeitsgruppe und einer Always On Failover Cluster herauszufinden. Allerdings scheitert es bei mir gerade bei dem Begriff SQL Instanz bei der AlwaysON AG. Ist es gleichzusetzen mit der Oracle Instanz? Und verstehe ich das richtig, dass im always on AG bei einem Ausfall auch auf einen anderen Knoten verschoben wird?
Danke im Voraus,
lg Jasmin
Hallo Jasmin,
eine MS SQL Server Instanz ist in etwa gleichzusetzen mit einer Oracle Datenbank. Beim SQL Server wird durch die Setup.exe eine Instanz erstellt in/unter der man dann Datenbanken betreibt.
Ja, richtig verstanden. Bei beiden Lösungen (Failover-Cluster und Avail. Groups) schwenken die aktiven Instanzen von einem Knoten auf den anderen, allerdings mit dem großen Unterschied, dass es beim Failover-Cluster einen gemeinsamen Storage gibt, der ebenfalls mitschwenkt. Bei einer AOAG hat man im Grunde zwei Standalone SQL Server, die sich zwar logisch über den Cluster-Service (Heartbeat/Health-Status) kennen, aber keinen wirklichen gemeinsamen Teil besitzen. Beide Seiten verfügen über eigenen Storage und können auch eigenständig arbeiten (es müssen nicht alle Datenbanken Teil der AG sein)… es gibt „nur“ den AG-Listener (aka DNS-Name/IP) der auf beiden Seiten bekannt ist und in den Applikationen als Connection angegeben werden muss. Nur dieser Listener schwenkt bei einer AG von einem Knoten auf den anderen, je nach Konfiguration schnell(er) oder langsam(er).
Ich kann gerne noch einmal einen Beitrag für dich machen, wenn du mir sagst welches Detail noch unklar ist. 😉
Oder frag mir einfach Löcher in den Bauch…
Gruß Björn
Hallo Herr Peters,
danke für die schnelle und ausführliche Antwort. Ich werde auf das Angebot mit dem Fragen selbstversändlich zurückgreifen 😉
ich glaube, so langsam kommt der AHA-Effekt. Ich habe mich jetzt seit einigen Tage mit der AG beschäftigt und mir war der Unterschied zwischen den beiden Verfahren nicht ganz deutlich. Wenn ich das richtig verstanden habe, liegt es an dem Storage im Failover Cluster: Das Storage wird von den beiden aktiven Instanzen gemeinsam verwendet. Bei einem Ausfall würde der Knoten auf einen anderen aktiven Knoten übergehen. Das Problem hierbei sehe ich, wenn auch das Storage einen Defekt erleiden würde, dann wäre die Option mit dem AG viel effizienter. Oder habe ich gerade einen Denkfehler?
Bei der AG verstehe ich noch nicht so ganz, weshalb in der Abbildung mehrere Failover Cluster eingezeichnet wurde mit vielen Datenbanken. Heißt es, dass bei einer AG, wenn eine Standalone ausfällt, dass der Listener dafür sorgt die Verbindung zu der anderen DB aufzubauen?
Sorry, für die vielen Fragen 🙂