Hochverfügbarkeit beim SQL Server – DBCC 2021 – Teil 1

Jeder meiner Kunden hat sich irgendwann mal die Frage gestellt oder zumindest sollte er sich diese Frage stellen, “brauche ich für meine SQL Server oder einen meiner SQL Server eine gewisse Hochverfügbarkeit”. Leider enden diese Überlegungen immer bei der Frage nach dem Budget… natürlich kosten solche HA-Lösungen mehr Geld, je nach Auswahl der Lösung und der Ausstattung der Umgebung müssen entsprechende Lizenzen zur Verfügung gestellt werden. Aber wenn man die im “worst-case” anfallenden Kosten während oder durch einen Ausfall dagegen rechnet, sollte man ganz klar zur Einsicht kommen, dass diese Kosten vertretbar sind.

Ich durfte heute auf der Data Blaster Community Conference 2021 einen Vortrag dazu halten (Vielen Dank liebe SQLPASS Deutschland), hier kommt eine kleine Zusammenfassung aus meinem Vortrag.

Ich habe direkt am Anfang dargestellt, wie hoch solche Kosten sein können, hierzu habe ich mit Hilfe eines Online-Rechners von Percona eine beispielhafte Rechnung aufgemacht. Der SQL Server fällt für 1-2 Stunden aus, 5 Mitarbeiter sind an dem Restore beschöftigt, jeder von ihnen verdient 100.000 pro Jahr, 100 weitere Mitarbeiter können nicht richtig arbeiten, diese verdienen durchschnittlich 50.000 pro Jahr. Im folgenden Screenshot könnt ihr die Zahlen lesen, die unter Umständen während des Ausfalls, bei der Behebung und deren Nachwirkungen entstehen können.

Warum SQLServer Hochverfuegbarkeit sich rechnet - Percona Calculator

Bei Gesamtkosten von rund 8.000.000 Euro für einen Ausfall eines SQL Servers von rund 2 Stunden, würde ich mir schon vorher überlegen, ob ich z.B. 250.000 Euro im Rahmen der Installation mehr ausgebe, um einen zweiten Server hinzustellen und mit den jeweiligen Lizenzen auszustatten. Aber wie können solche Hochverfügbarkeiten im SQL Server Umfeld aussehen, dazu komme ich in den nächsten Abschnitten, aber erst einmal sollten wir die Überschriften klären… 😉

Hochverfügbarkeit vs Desaster Recovery

Die Definition von Hochverfügbarkeit auf wikipedia.de lautet wie folgt :

Hochverfügbarkeit (englisch high availabilityHA) bezeichnet die Fähigkeit eines Systems, trotz Ausfalls einer seiner Komponenten mit einer hohen Wahrscheinlichkeit (oft 99,99 % oder besser) den Betrieb zu gewährleisten. In Abgrenzung zur Fehlertoleranz kann es bei dem Betrieb im Fehlerfall zu einer Unterbrechung kommen.

https://de.wikipedia.org/wiki/Hochverf%C3%BCgbarkeit

Im Vergleich dazu die Definition von Desaster Recovery

Der englische Begriff Disaster Recovery (im Deutschen auch Katastrophenwiederherstellung oder Notfallwiederherstellung genannt) bezeichnet Maßnahmen, die nach einem Ausfall von Komponenten in der Informationstechnik eingeleitet werden. Dazu zählt sowohl die Datenwiederherstellung als auch das Ersetzen nicht mehr benutzbarer InfrastrukturHardware und Organisation. Umfassender als Disaster Recovery ist der Begriff Business Continuity, der nicht die Wiederherstellung der IT-Dienste, sondern unterbrechungsfreie Geschäftsabläufe in den Vordergrund stellt.

https://de.wikipedia.org/wiki/Disaster_Recovery

Bei der Hochverfügbarkeit geht es eben mehr darum, die eintretende Zeit des Ausfalls, also die Downtime möglichst gering zu halten, so dass alle angeschlossenen Systeme möglichst ohne Datenverlust und manuellen Eingriff schnellstmöglich weiterlaufen. Hierzu sollte man sich vor der Installation natürlich Gedanken zur Prozessgestaltung, den zu erreichenden Zielen und der Notwendigkeit zu machen.

  • Was braucht das Business?
  • Was kostet es das Business wenn sie nicht mehr arbeiten können?
  • Gibt es ggfs einen Kompromiss zwischen Technik und Business? Müssen es wirklich die minimalsten Ausfallzeiten (< 10 Sekunden) sein oder reichen vielleicht auch maximale Ausfallzeiten von kleiner einer Minute?
  • Was kann die Technik überhaupt abbilden? Wissen, Prozesse u.ä.
  • Welceh rechtlichen Rahmen müssen ggfs eingehalten werden?

Und erst wenn man diese Fragen vorher geklärt hat, kann man sich Gedanken über die eigentliche Hochverfügbarkeitslösung machen und wie diese implementiert werden kann/soll.

Das AlwaysOn Failover-Cluster (FCI)

Hochverfuegbarkeit - SQLServer - AlwaysOn Failover Cluster

Kommen wir zu einer der möglichen Lösungen zur Realisierung der Hochverfügbarkeit des SQL Servers innerhalb des eigenen Rechenzentrums, das Windows Failover Cluster (im Grunde identisch zu einem Linux Failover Cluster, hier sollte man sich an die Angaben/Dokumentation der jeweiligen Distribution und eingesetzten Cluster-Software halten).

Initial erstellt man aus zwei Windows Servern mit dem zusätzlich installierten Failover-Cluster Feature ein Windows Failover Cluster, grob gesagt, man verbindet beide Server logisch (und im AD) miteinander. Beide kennen sich und wissen nun, dass sie zusammengehören und tauschen mehrere entsprechenden Health-Status Informationen untereinander aus. Dieses Windows Failover Cluster erhält eine eigene IP und einen eigenen DNS Namen, sowie ein Cluster-Named-Object im AD, dieses CNO “steuert” später das Cluster im AD.

Zu den notwendigen Storage-Requirements kann ich hier wenig sagen, da dies von den jeweiligen Umgebungen abhängt… SAN, NAS, NFS, HCI oder ähnliches, auf jeden Fall muss es sich um einen Storage handeln, der in der Lage ist beiden Servern Zugriff zu gewähren. Microsoft schreibt dazu folgendes:

Storage

Im Gegensatz zur Verfügbarkeitsgruppe muss eine FCI freigegebenen Speicher zwischen allen Knoten der FCI für Datenbank und Protokolle verwenden. Der freigegebene Speicher kann die Form von WSFC-Clusterdatenträgern, direkten Speicherplätzen (Storage Spaces Direct, S2D), Datenträgern auf einem SAN oder Dateifreigaben auf einem SMB aufweisen. Auf diese Weise verfügen alle Knoten in der FCI immer dann über die gleiche Sicht der Instanzdaten, wenn ein Failover auftritt. Dies bedeutet jedoch, dass der freigegebene Speicher das Potenzial hat, die einzelne Fehlerquelle zu sein. Die FCI hängt zudem von der zugrunde liegenden Speicherlösung ab, um Datenschutz sicherzustellen.

https://docs.microsoft.com/de-de/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?view=sql-server-ver15&WT.mc_id=DP-MVP-5002576#Recommendations

Nun kann man mit der eigentlichen Installation des SQL Servers beginnen, auf dem Node 1 wird die Basis-Installation für das SQL Server Failover Cluster geschaffen “Erstellung eines Failover-Clusters”, während auf dem Node 2 “nur” ein Knoten zu einem bestehenden SQL Server Cluster hinzugefügt wird.

Je nach Ausgestaltung dieses Cluster – nur eine Instanz oder mehrere Instanzen – müssen SQL Server Lizenzen beschafft werden. Hierbei kann man zwischen zwei Betriebsmodis unterscheiden, aktiv/passiv oder aktiv/aktiv. Bei aktiv/passiv dürfen die SQL Server Instanzen immer nur auf einem Knoten des Clusters laufen, im Fehlerfall für einen begrenzten Zeitraum auch auf beiden Knoten. Bei aaktiv/aktiv können beide Knoten gleichermaßen und zeitlich unbegrenzt voll genutzt werden, was gerade bei mehreren Instanzen unter Umständen Sinn machen kann, da man so eine gewisse Last-Aufteilung vornehmen kann.

Sollte nun ein Knoten im Cluster ausfallen, so kann der zweite Knoten vereinfacht gesagt nicht mehr der anderen Seite kommunizieren und versucht schnellstmöglich die ausgefallenen Services auf seine Seite zu holen und dort zu starten.

Ein hybrides Szenario ist hierbei leider nicht möglich, da es keine Möglichkeit der gesharten Ressourcen zwischen on-premise und Cloud gibt. Aber man kann alternativ auch ein Failover-Cluster in der Azure Cloud aufbauen. Hierzu benötigt man eine Proximity Placement Group, entsprechende Managed Disks mit aktiviertem “Shared Storage” Feature und die beschriebenen zwei virtuellen Maschinen, die eigentliche Installation und Betrieb ist im Grunde identisch.

Hochverfügbarkeit Azure SQLServer Failover Cluster - DBCC2021

Mehr zu Hochverfügbarkeiten des SQL Servers kommt demnächst in einem zweiten Beitrag.

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.