SQL Server: So helfen AlwaysOn Availability Groups bei Ausfallzeiten

Ein häufiges Problem bei der Administration von SQL Servern sind Ausfallzeiten. Das hat oft nicht zu unterschätzende Folgen für die Produktivität des betroffenen Unternehmens. So können eine Vielzahl von Anwendungen, deren Datenbanken nicht erreichbar sind, nicht mehr genutzt werden. AlwaysOn Availability Groups sollen Abhilfe schaffen. Wir erklären, was die neu mit SQL Server 2016 eingeführten Basic Availability Groups leisten können und wo deren Grenzen liegen.

SQL-Server-Ausfälle können unterschiedliche Ursachen haben. Sie entstehen unter Umständen durch Reboots, beispielsweise bei der Installation von Patches, oder aber auch durch Hardware-Ausfälle. Um weitreichende Folgen zu minimieren, ist es empfehlenswert, sich bereits bei der Infrastrukturplanung Gedanken zum Thema Hochverfügbarkeit zu machen. Dies muss nicht zwangsläufig mit hohen Kosten verbunden sein.

Unter AlwaysOn Availability Groups, oder deutsch Verfügbarkeitsgruppen, versteht man eine Technologie, die den SQL Server vor geplanten oder ungeplanten Ausfällen schützt und Downtimes minimiert. Einfach ausgedrückt handelt es sich dabei um eine Kombination der bereits bekannten Funktionen Datenbankspiegelung und Failover Cluster Instanzen. AlwaysOn Availability Groups wurden mit SQL Server 2012 eingeführt und waren bisher nur in der Enterprise Edition nutzbar.

Jeder Server speichert eine eigene Kopie der Datenbanken, so dass im Gegensatz zum SQL Server Cluster kein Shared Storage benötigt wird, der seinerseits gegen Ausfall geschützt werden muss. Diese Datenbankkopien werden ständig synchronisiert. Der Listener, ein virtuelles Computerkonto mit eigener IP-Adresse und eigenem DNS-Namen, leitet die Kommunikation zum gerade aktiven SQL Server weiter. Kommt es zum Ausfall dieses Servers, so wird der andere Server aktiv. Alle Abfragen werden dann automatisch dahin umgeleitet. Systemdatenbanken können allerdings nicht Teil einer Verfügbarkeitsgruppe sein, so dass sämtliche Aufträge des SQL Server Agents sowie Logins und weitere in den Systemdatenbanken gespeicherte Objekte auf jedem Server einzeln angelegt und ggf. im weiteren Verlauf angepasst (z.B. Passwortänderungen bei SQL Server Logins) werden müssen.

Neu in SQL Server 2016 sind die Basic Availability Groups. Dabei handelt es sich um eine im Funktionsumfang reduzierte Variante der oben beschriebenen Enterprise-Verfügbarkeitsgruppen, welche in der Standard Edition zur Verfügung steht. Damit stellen die Basic Availability Groups eine kostengünstige Variante dar, die Verfügbarkeit von Datenbanken zu steigern. Gegenüber den vollwertigen Verfügbarkeitsgruppen der Enterprise Edition gibt es jedoch einige Einschränkungen:

• Beschränkung auf zwei Replikate: Im Gegensatz zur vollwertigen Version ist es hier nicht möglich, mehr als zwei Server an einer Verfügbarkeitsgruppe zu beteiligen.
• Lesen und Backup auf sekundären Replikaten nicht möglich: Eine Besonderheit der vollwertigen Variante ist die Möglichkeit, lesend auf passive Replikate zuzugreifen und diese zur Erstellung von Sicherungen zu verwenden. Das ist bei Basic Availability Groups nicht möglich.
• Kein nachträgliches Hinzufügen oder Entfernen von Replikaten: Server können nicht zu einer bestehenden Basic Availability Group hinzugefügt oder aus dieser entfernt werden. Es muss immer die komplette Gruppe gelöscht und anschließend neu erstellt werden.
• Beschränkung auf eine Datenbank pro AG: Im Falle der Basic Availability Groups ist es nicht möglich, mehr als eine Datenbank einer Verfügbarkeitsgruppe zuzuordnen. Entsprechend müssen mehrere Verfügbarkeitsgruppen angelegt werden, wenn mehrere Datenbanken gegen Ausfall geschützt werden sollen.

Bei der Bereitstellung und Konfiguration von Basic Availability Groups gibt es (abgesehen von diesen Einschränkungen) keine wesentlichen Unterschiede zum Vorgehen beim Pendant in der Enterprise Edition.

Seit Erscheinen des SQL Server 2012 ist die Datenbankspiegelung abgekündigt und wird in einer der kommenden Versionen nicht mehr zur Verfügung stehen. Ersatz stellen die Verfügbarkeitsgruppen und für die Standard Edition im Speziellen die Basic Availability Groups dar. Neben den offensichtlichen Gemeinsamkeiten der beiden Technologien bieten die Basic Availability Groups den Vorteil, dass auf Grund des Listeners Verbindungen auf einen DNS Namen bzw. eine IP-Adresse erfolgen können und direkt zum aktiven Server weitergeleitet werden. Dadurch ist gewährleistet, dass immer mit dem richtigen Server kommuniziert wird, egal welcher gerade aktiv ist. Bei der Datenbankspiegelung muss der Connection String umständlich mit „Failover Partner=<Spiegelservername>;“ angegeben werden, um den gleichen Effekt zu erzielen. Für viele Anwendungen ist das, je nach Typ der Verbindung, auch gar nicht möglich. Damit sind Basic Availability Groups auch in Szenarien einsetzbar, in denen die Spiegelung bisher keine Alternative dargestellt hat.

Natürlich gibt es auch in der Standard Edition weitere Möglichkeiten, Datenbanken gegen Ausfall zu sichern. Die rudimentärste Variante ist dabei das Log Shipping. Kommt es zum Ausfall des primären SQL Servers, ist jedoch immer ein manuelles Eingreifen des Administrators nötig, da Log Shipping keine Möglichkeit eines automatischen Failovers bietet. Deshalb kommt diese Technologie verhältnismäßig selten zum Einsatz.

In der Praxis häufiger vertreten sind die SQL Server Failover Cluster Instanzen, die mit einer Beschränkung auf maximal zwei Clusterknoten ebenfalls in der Standard Edition zur Verfügung stehen. Dabei muss aber ein SAN System zur Verfügung stehen, auf das beide Clusterknoten (also die Server, die am Cluster beteiligt sind) Zugriff haben. Weil im Falle der Failover Cluster Instanzen die Datenbanken nicht redundant gespeichert sind, muss dieser Shared Storage seinerseits vor Ausfall geschützt werden. Je nach Rahmenbedingungen kann das eine hohe Komplexität nach sich ziehen. Gegenüber den Verfügbarkeitsgruppen (sowohl Enterprise als auch Standard Edition) haben die Failover Cluster Instanzen aber den Vorteil, dass die komplette Instanz vor Ausfall geschützt wird. Dadurch sind einerseits alle Datenbanken (inklusive Systemdatenbanken) der Instanz abgesichert und andererseits wird das Einrichten von automatisierten Wartungsaufgaben (Backup, Datenbankintegritätscheck, Indexpflege etc.) vereinfacht.

Weil für die Basic Availability Groups kein Shared Storage benötigt wird, ist diese Variante vor allem dann interessant, wenn entweder kein SAN (Storage-Area-Network) im Unternehmen vorhanden ist oder die Verwendung von Shared Storage aus anderen Gründen Probleme bereitet. Zu bedenken ist, dass durch die Beschränkung von einer Datenbank pro Verfügbarkeitsgruppe schnell ein hoher Aufwand beim Konfigurieren und Verwalten der Verfügbarkeitsgruppen entsteht, wenn sehr viele Datenbanken vor Ausfall geschützt werden sollen. Dann ist gegebenenfalls die Bereitstellung von Failover Cluster Instanzen die bessere Alternative. Kommt das aus oben genannten Gründen nicht in Frage, so sollte in Erwägung gezogen werden, ob die vollen Verfügbarkeitsgruppen der Enterprise Edition vorzuziehen sind, auch wenn damit höhere Lizenzkosten verbunden sind.

Zu empfehlen ist die Verwendung von Basic Availability Groups insbesondere dann, wenn nur wenige Datenbanken ausfallsicher bereitgestellt werden sollen und/oder wenn aktuell die Datenbankspiegelung zur Minimierung von Ausfallzeiten verwendet wird. Hier ergeben sich echte Vorteile durch die Möglichkeit des Datenbankzugriffs über den Listener. Außerdem wird die Datenbankspiegelung als abgekündigtes Feature mittelfristig nicht mehr zur Verfügung stehen. Die Umstellung auf Basic Availability Groups stellt damit also ein Upgrade auf den aktuellen Stand der Technik dar.