William Durkin 16. Juni 2015

SQL Server AlwaysOn - Die Antwort auf Datenbank-Hochverfügbarkeit von Microsoft

Microsoft hat die gesamte Hochverfügbarkeitsreihe im SQL Server überarbeitet. © depositphotos.com / pisotskii — © depositphotos.com / pisotskii

Heutzutage erwarten wir mehr denn je, dass IT-Systeme performant, sicher und verfügbar sind. Genau diese drei Punkte in der Datenbankwelt ausreichend zu liefern ist nicht einfach. In der Vergangenheit lag Microsoft mit der Entwicklung von Hochverfügbarkeits- technologien (High Availability/ HA) im Datenbankbereich etwas hinter seinen Mitbewerbern zurück. Als SQL Server 2005 veröffentlicht und Datenbankspiegelung vorgestellt wurde, hörte man aus der Oracle-Ecke sehr schnell, dass Microsoft Features entwickele, die seit Jahren bei Oracle verfügbar seien. Die Aussagen hörten sich so oder ähnlich an: "Wenn man etwas mit Datenbanken machen will, solle man die "bunten Spielzeuge" aus Redmond in der Spielzeugkiste lassen und zu "richtigen Werkzeugen" greifen". Da hatten die Stimmen nicht ganz unrecht, besonders, wenn es um die Enterprise Hochverfügbarkeits- funktionalitäten ging (z. B. Oracle RAC [1]).

Microsoft nahm diese Kritikpunkte auf und machte sich an die Arbeit, um die gesamte Hochverfügbarkeitsreihe im SQL Server zu überarbeiten. Mit SQL Server 2012 präsentierte Microsoft zwei "New and Improved"-Funktionalitäten: "SQL Server AlwaysOn Failover Cluster Instances" und "SQL Server AlwaysOn Availability Groups". Diese zwei Features bilden das Rückgrat der Hochverfügbarkeit in SQL Server und ersetzen auf Dauer die anderen HA Features. Microsoft hat bei der Konzeption dieser zwei Features zwischen Instanzverfügbarkeit und Datenbankverfügbarkeit unterschieden und diese Ziele getrennt voneinander betrachtet und entwickelt.

SQL Server AlwaysOn Failover Cluster Instances

Abb.1: Einfache Darstellung der logischen Abhängigkeiten eines SQL Server Failover Clusters. © William Durkin

Failover Cluster Instances gibt es als Feature seit SQL Server 6.5 (1996) und es wurde bei jedem Release von SQL Server weiterentwickelt. Für SQL Server 2012 wurde der Begriff "AlwaysOn" geschaffen, um alle Hochverfügbarkeitstechnologien von Microsoft zusammenzuführen, sodass Failover Clustering in "SQL Server AlwaysOn Failover Cluster Instances" umgetauft wurde.

SQL Server AlwaysOn Failover Cluster Instances bauen auf die Windows Server Failover Clustering Technologien auf und sind für die Verfügbarkeit von ganzen SQL Server Instanzen zuständig. Im Gegensatz zum Ansatz von Oracle mit RAC, setzt Microsoft bei seinem Clustering auf eine Aktiv/Passiv-Architektur. Das heißt, egal ob man ein Zwei-Knoten- oder Acht-Knoten-Cluster für eine SQL Server-Instanz aufbaut, es wird immer nur ein Knoten aktiv benutzt, um Datenbankanfragen zu bearbeiten. Die Clustering-Technologien auf Windows-Ebene sorgen sich um alles: von der Betriebssystemebene bis hinunter zur Hardwareebene. Diese logische Einheit kümmert sich um die Ressourcen, die zu einem bestimmten Dienst gehören (Active Directory-Objekte, DNS-Einträge, Festplatten, Netzwerkverbindungen usw.). Eine Voraussetzung für Clustering generell ist eine redundante Auslegung der IT-Infrastruktur, damit alle Knoten eines Clusters über mehrere Ausfallarten abgesichert werden können (z. B. redundante Netzwerkkarten, Stromversorgung, Storage-Anbindungen usw.).

Der SQL Server wird auf diese logische Einheit installiert und kümmert sich lediglich um die Ausführung der SQL Server-Dienste. Es ist nicht direkt von außen erkennbar, ob eine SQL Server-Instanz als Failover Cluster installiert wurde oder ob es sich um eine Standalone-Instanz handelt. Die Clustertechnologien von Windows und SQL Server arbeiten dann zusammen, um den Betrieb des gesamten Servers sicherzustellen. Im Falle eines Ausfalls (egal ob Hardware, Netzwerk oder der SQL Server selbst), erkennt der Cluster den Ausfall und reagiert automatisch, um den ganzheitlichen Datenbankdienst online zu halten bzw. wieder online zu bringen.

Die Aktiv/Passiv-Beziehung bei den Failover Cluster-Instanzen bringt gegenüber einer Aktiv/Aktiv-Architektur Vor- und Nachteile mit sich:

Vorteile:

Wartungsarbeiten stören den Produktivbetrieb des Clusters viel weniger: Es wird ein Sicherheitsupdate entweder für das Betriebssystem oder Datenbanksystem veröffentlicht. Sie installieren bei SQL Server die Updates auf den Passivknoten und können mittels eines geplanten Failovers den Betrieb in wenigen Sekunden auf den frisch gepatchten Knoten verschieben. So halten Sie ihre Systemausfälle für Wartungen sehr kurz und bei richtigem Applikationsaufbau merken die Benutzer die Failover oft gar nicht
Ungeplante Hardware-/ Infrastrukturausfälle stören viel weniger: Da die SQL Server-Instanz von dem Clusteringsystem gesteuert und überwacht wird, reagiert das System viel schneller auf Ausfälle als Sie es mit einer Standalone-Instanz machen könnten. Bei einem Hardware-Ausfall in einem Knoten wird der Betrieb auf einem "heilen" Knoten aufgenommen, sodass der Dienstausfall ebenfalls nur wenige Sekunden andauert.
Software/ Applikationen müssen nicht angepasst werden: Ihre Applikation muss nicht angepasst werden, um mit einem Cluster arbeiten zu können. Nach außen hin sieht eine Failover Cluster-Instanz genauso aus wie eine gewöhnliche Standalone-Instanz. Wenn Sie sicher gehen wollen, dass Ihre Applikation mit einem Failover besser umgehen kann, müssen Sie lediglich bei Datenbankzugriffen einen "Retry-"Mechanismus einbauen. So muss die Applikation einer Anfrage einfach erneut gestartet werden, falls der Datenbankdienst gerade von einem zum anderen Knoten verschoben wird.
Beim ersten Passivknoten muss keine Lizenz bezahlt werden: Microsoft hat nicht nur mit den Funktionalitäten gegenüber Oracle nachgezogen, auch der Preis hat sich nach oben angepasst. Bei einem 2-Knoten-SQL Server-Cluster müssen Sie den zweiten Knoten lediglich mit einer Windows-Server-Lizenz ausstatten, die SQL Server-Lizenz gibt es "gratis" dazu.

Nachteile:

Hardware steht nutzlos herum: Der Passivknoten kostet nichts in der Lizenzierung, dafür darf er aber keine SQL Server-Tätigkeiten als Passivknoten ausführen. Viele mögen diese Tatsache als "totes Kapital" ansehen, da der Server läuft und Strom nutzt, aber keinen offensichtlichen Dienst erfüllt. Das erledigt sich jedoch, sobald der erste große Ausfall durch den Passivknoten in Sekunden anstatt Stunden bereinigt wird.
Mehr Komplexität in der IT: Je höher die Komplexität eines Systems, umso anfälliger wird es. Das lässt sich bei Hochverfügbarkeitssystemen nicht vermeiden; sie sind von Natur aus komplex, brauchen jedoch diese Komplexität, um hochverfügbar zu sein.
Das Betriebssystem eines Windows Clusters lässt sich (derzeit) nicht aktualisieren: Das ist derzeit das größte Problem bei Windows Clustering und wird bei der nächsten Windows-Server-Version angegangen. Die Technical Preview von Windows-Server vNext hat diese Funktionalität eingebaut und so lässt es hoffen, dass Betriebssystem-Upgrades keine Probleme mehr darstellen.
Die gesamte Instanz wird behandelt: Der Name ist hier Programm. Failover Cluster-Instanzen sind für eine gesamte SQL Server-Instanz zuständig. Sollten Sie jedoch nur eine Datenbank von Hunderten auf einer Instanz hochverfügbar halten wollen, wird Ihnen mit AlwaysOn Failover Cluster Instances nicht unbedingt geholfen, denn hier werden alle Datenbanken gleichgestellt und alle werden nur auf einem Knoten gehostet.

SQL Server AlwaysOn Availability Groups

Microsoft entwickelte eine Reihe von Technologien, um Datenbankspiegelung in SQL Server 2005 zu ermöglichen und machte SQL Server für die gesamten Verfügbarkeitsaufgaben verantwortlich. Diese Entscheidung machte es für das SQL Server-Entwicklungsteam schwierig, alle Bereiche abzudecken, die zu einer hochverfügbaren Datenbank gehören. Ähnlich wie bei Windows Clustering musste SQL Server sich auf einmal um Netzwerkverfügbarkeit und systemübergreifende Ressourcenverteilung kümmern – alles Aufgaben, für die ein Datenbanksystem im Grunde nie gebaut wurde.

SQL Server AlwaysOn Availability Groups ist eine Neuentwicklung der zuvor erwähnten Datenbankspiegelung, allerdings wurden die Aufgaben neu verteilt und Windows Server Failover Clustering wurde wieder mit den Betriebssystem- und Infrastrukturaufgaben beauftragt. So kümmert sich SQL Server seit SQL Server 2012 wieder um die reinen Datenbankkernaufgaben und lässt die Hochverfügbarkeitsaufgaben da, wo sie hingehören.

Diese Entlastung innerhalb von SQL Server erlaubt nun eine Erweiterung der Möglichkeiten, die mit Datenbankspiegelung angefangen wurden. Mit AlwaysOn Availability Groups ist es möglich, eine Datenbank (oder mehrere Datenbanken) auf mindestens zwei Datenbankservern zu hosten. Mittels Windows Failover Clustering werden hierfür mehrere SQL Server-Instanzen (Standalone- oder Failover Cluster-Instanzen) zu einer Gruppe zusammengeführt. Diese Gruppe bildet eine Einheit, die über SQL Server-Instanzen hinweg die gewählten Datenbanken online hält und Datenbankanfragen entgegennimmt und bearbeitet. Der Unterschied zu Failover Cluster-Instanzen ist, dass man hier einzelne Datenbanken auswählt anstatt einer gesamten Instanz.

Eine weitere Fähigkeit der AlwaysOn Availability Groups, die bei Failover Cluster-Instanzen und Datenbankspiegelung nicht vorhanden ist, ist die Möglichkeit, die Datenbanken auf den verteilten Instanzen gleichzeitig zu lesen. Das heißt, alle (die Anzahl der Instanzen und deren Verwendung ändern sich je nach SQL Server-Version) Instanzen (bei AlwaysOn Availability Groups bekannt als Replikate) können für die lesenden Zugriffe verwendet werden und somit kann eine Erhöhung des Nutzungsgrades der einzelnen Instanzen erzielt werden. Es werden derzeit ausschließlich lesende Zugriffe verteilt; Schreibzugriffe sind immer nur auf das primäre Replikat erlaubt.

Abb.2: Availability Group über zwei Standorte inkl. Failover Cluster-Instanz. © William Durkin

Abbildung 2 zeigt eine Availability Group über zwei Standorte inkl. Failover Cluster-Instanz. So sehen Sie, wie AlwaysOn Availability Groups eine weitere logische Schicht zwischen Applikation und Datenbank aufbaut. Diese logische Schicht ist verantwortlich für die Lenkung der Datenbankanfragen, um zu entscheiden, ob eine Schreib- oder Leseoperation durchgeführt und wo diese Anfrage hingeleitet werden soll.

Wie in der Abbildung zu sehen, ist es möglich, eine AlwaysOn Availability Group über mehrere Standorte hinweg aufzubauen. Das soll auch verdeutlichen, dass es bei AlwaysOn Availability Groups keine geteilten Ressourcen gibt, so wie bei einer Failover Cluster-Instanz, denn die Storage und Netzwerkressourcen sind komplett von der AlwaysOn Availability Group entkoppelt. Diese Entkoppelung erlaubt eine weitere Erhöhung der Sicherheit im Hinblick auf Standortausfälle (z. B. Brand oder Naturkatastrophen), bringt aber andere Herausforderungen mit sich (z. B. Netzwerk-Latenzen).

AlwaysOn Availability Groups bietet über die Synchronisationsmodi zwei Optionen an, genau diesen Latenzen entgegenzuwirken:

Synchron: Schreiboperationen werden erst abgeschlossen, wenn die Datenänderungen auf allen synchronen Replikaten erfolgreich übernommen wurden. Das garantiert, dass alle Replikate immer genau den gleichen Stand haben und so automatisch den primären Betrieb übernehmen können. Da alle Replikate diese Änderungen bestätigen müssen, sind Netzwerk-Latenzen kritisch zu betrachten. Jede Millisekunde die hier verloren geht, wird in jeder Schreiboperation widergespiegelt. Dadurch, dass alle Daten auf allen Replikaten synchron gehalten werden, bietet AlwaysOn Availability Groups die Möglichkeit eines automatischen Failovers. So kann wie bei den Failover Cluster-Instanzen eine fast sofortige Übernahme des Betriebs von einem Replikat zum anderen stattfinden.

Asynchron: Hier werden Applikationen über den Erfolg einer Schreiboperation informiert, sobald diese Änderung auf das primäre Replikat abgeschlossen ist; die Synchronisierung zwischen primärem Replikat und anderen Replikaten geschieht asynchron. Dadurch können Datenänderungen auf das primäre Replikat stattgefunden haben, die durch Systemausfälle niemals die anderen Replikate erreichen. Asynchrone Synchronisierungsmodi schließen somit einen automatischen Failover aus. Da die Synchronisierung asynchron abläuft, sind Netzwerk-Latenzen hier weniger problematisch.

Für eine ausführliche Beschreibung der Failover-Modi besuchen Sie die Microsoft-Books-Online-Dokumentation [2].

AlwaysOn Availability Groups bringen ebenfalls Vor- und Nachteile mit sich:

Vorteile:

Endlich können die anderen Knoten benutzt werden! Es wird in den meisten Datenbanken mehr gelesen als geschrieben und somit ist die Möglichkeit, diese Leselast zu verteilen, ein wahres Wunder.

Auslagern von Wartungsaufgaben: Sie können mit AlwaysOn Availability Groups die oft ressourcenlastige Sicherung von ihrem Primären Schreibknoten auslagern und müssen dabei nicht mehr den normalen Betrieb ausbremsen.
Automatische Datenreparatur: AlwaysOn Availability Groups ist in der Lage, korrupte Datenseiten (durch Hardwarefehler) innerhalb einer Datenbank zu erkennen und kopiert daraufhin eine nicht korrupte Version von einem sekundären Knoten.
Sie können anstelle einer ganzen Instanz bestimmte Datenbanken auswählen: Oft werden mehrere Datenbanken auf einer Instanz betrieben, nur wenige davon sind aber "kritisch". Bei AlwaysOn Availability Groups können Sie die kritischen Datenbanken gruppieren und gesondert behandeln, während die anderen Datenbanken gewöhnlich weiterarbeiten.

Nachteile:

Nur ein Knoten ist schreibbar: Wenn Sie schreiben wollen, können Sie nur auf dem Primären Knoten schreiben. Falls Sie schreiblastig sind, bringt AlwaysOn Availability Groups keine Vorteile, um das Schreiben zu beschleunigen.
Alle Knoten müssen lizenziert sein: Sobald Sie den Sekundären Knoten aktiv benutzen (Lesezugriffe, Backups usw.), müssen Sie alle Knoten lizenzieren. AlwaysOn Availability Groups ist zudem nur bei der teuersten Edition, der SQL Server Enterprise Edition, verfügbar.
Applikationen müssen angepasst werden: Um alle Funktionen bei AlwaysOn Availability Groups nutzen zu können, müssen Applikationen angepasst werden, um dem Server mitzuteilen, ob gerade nur gelesen oder auch geschrieben werden soll. Falls Sie diese Option nicht nutzen wollen, bleibt AlwaysOn Availability Groups genauso transparent wie AlwaysOn Failover Cluster Instances.

Zusammenfassung

Microsoft hat sich in den vergangenen zehn Jahren mächtig ins Zeug gelegt, um Enterprise Hochverfügbarkeit anbieten zu können. Die Weiterentwicklung diese Technologien wurde letztens bei den Konferenzen Build 2015 und Ignite angesprochen und lässt einen weiteren Auf- und Ausbau erahnen.

Wenn Sie SQL Server in einer Hochverfügbarkeitsumgebung betreiben wollen, kommen Sie an den beiden Technologien SQL Server AlwaysOn Failover Cluster Instances und SQL Server AlwaysOn Availability Groups nicht herum. Als Beweis, dass diese Technologien tatsächlich einsatzbereit und verlässlich sind, gehören sie zu den Kernkomponenten der Microsoft Cloud "Azure". Wenn Sie "Microsoft Azure SQL Database" benutzen, nutzen Sie die AlwaysOn Availability Groups, ohne es direkt zu wissen oder zu sehen.