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

In diesem zweiten Teil zu meiner Übersicht zu den Möglichkeiten zur Realisierung von Hochverfügbarkeit mit dem SQL Servers, in diesem Teil geht es um die Always On Availability Groups oder zu deutsch: Always On Verfügbarkeitsgruppen. Was sind diese, wofür eignen sie sich und was muss oder sollte man in der Planung oder dem Betrieb beachten. Nachdem ich in Teil 1 über das Failover Cluster geschrieben habe, möchte ich nun wie versprochen zur zweiten Möglichkeit kommen mit der man einen SQL Server bzw seine Applikations-Datenbank hochverfügbar realisieren kann.

Der größte Unterschied ist definitiv die Infrastruktur, dazu aber im folgenden mehr. Technisch sichert ein Failover-Cluster die komplette Instanz ab, im Fehlerfall fällt beispielsweise der komplette Knoten aus, die Dienste werden gestoppt, der Storage freigegeben und auf den zweiten Knoten geschwenkt, dort werden die Dienste wieder gestartet und der SQL Server steht nach dem Crash-Recovery wieder zur Verfügung.

Bei einer Availability Group wird nur die (eine oder mehrere) Datenbanken abgesichert, nicht die Instanz! Microsoft beschreibt es in seiner Dokumentation wie folgt und weist auf einen großen Vorteil von Availability Groups hin – die Readable Secondaries:

Eine Verfügbarkeitsgruppe unterstützt eine replizierte Umgebung für einen diskreten Satz von Benutzerdatenbanken (als Verfügbarkeitsdatenbanken bezeichnet). Sie können eine Verfügbarkeitsgruppe zur Hochverfügbarkeit (HA) oder Leseskalierung einrichten.

https://docs.microsoft.com/de-de/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver15

Die Always On Availability Group

Wer den SQL Server schon etwas länger kennt, der kennt noch die – eigentlich lange als depricated bezeichnete Lösung – Mirroring, also Spiegelung von Datenbanken von einem Server zum anderen. In den Anfangszeiten wurden die Availability Gruppen auch gerne als „Mirroring on Steoroids“ bezeichnet, da es im Grunde nichts anderes ist als eine Spiegelung von Datenbanken mit dem großen Management-Vorteil, dass hier – im Vergleich zum alten Mirroring – viele Dinge vereinfacht und automatisiert wurden.

Aber kommen wir doch mal zur eigentlichen Technologie bzw Lösung und somit zum ersten Punkt, dem wichtigsten Unterschied im Bereich Infrastruktur zum Failover-Cluster. Für ein Failover-Cluster benötigt man immer einen gemeinsamen Storage, ob dieser nun als ISCI-Device, als Shared Storage aus einem SAN/NAS oder aus lokalem Storage mit Cluster-Shared-Volumes verbunden, immer ist dieser Storage die gemeinsame Ebene auf die alle beteiligten Knoten des Clusters zugreifen können müssen. Beim Failover-Cluster hat immer nur ein Knoten auf eben diesen gemeinsamen Storage exklusiven Schreib-Zugriff, alle anderen Knoten können ggfs auf den Storage „connecten“, aber erhalten kein Lock/Lease. Je nach Ausbau des Clusters können auch mehrere Instanzen auf dem Cluster installiert sein, jede SQL Server Instanz benötigt dann ihren eigenen Storage-Bereich, der getrennt von den anderen Instanzen zwischen den Knoten schwenken kann. Aber auch hier liegt einer der großen technischen Vorteile dieser Lösung, wir benötigen nur einen Storage => 100GB Daten sind 100GB Platte.

Im Vergleich dazu und damit wären wir beim einfachen Aufbau eines AOAG-Clusters und dem Storage… beide Knoten im AOAG-Cluster müssen identisch aufgebaut sein, denn im normalen Ausbau mit mindestens zwei Knoten, werden diese zwei Knoten wie Standalone-Server installiert, also einzelne Server mit eigenem Storage! (100GB Daten sind 2x 100GB Platten). Beide Knoten werden also ressourcentechnisch identisch aufgebaut mit identischem lokalen Storage, keine gemeinsamen Komponenten, nur auf Windows Ebene kennen sich beide Knoten durch den Windows Failover Cluster Service, über den sie Status-Informationen austauschen.

Wichtig bei der Planung zu berücksichtigen und einzukalkulieren, es gibt mehrere Editionen des SQL Servers, Availability Groups gibt es nur in Standard und Enterprise… in der Standard-Edition gibt es beim SQL Server 2019 die Basic-Avail.Groups und in der Enterprise-Edition den vollen Funktionsumfang.

5 Bei der Enterprise Edition werden bis zu acht sekundäre Replikate unterstützt, einschließlich fünf synchronen sekundären Replikaten.

6 Bei der Standard Edition werden Basis-Verfügbarkeitsgruppen unterstützt. Eine Basis-Verfügbarkeitsgruppe unterstützt zwei Replikate mit einer Datenbank. Weitere Informationen über Basis-Verfügbarkeitsgruppen finden Sie unter Basis-Verfügbarkeitsgruppen.

https://docs.microsoft.com/de-de/sql/sql-server/editions-and-components-of-sql-server-version-15?view=sql-server-ver15#rdbms-high-availability

Details zur Einrichtung von Availability Gruppen

Eine Availability Group ist erst einmal eine logische Gruppierung von Datenbanken, die über einen gemeinsamen Listener (DNS/IP) angesprochen werden können, die Availability Gruppe besteht aus mindestens zwei Knoten. Nach dem Erstellen der AOAG, werden die relevanten Datenbanken der Gruppe hinzugefügt, hierzu ist ein FULL- und mindestens ein erstes TransactionLog-Backup notwendig. Für die erste Bereitstellung der Datenbanken auf dem zweiten Knoten gibt es mehrere Optionen, wie Automatic-Seeding oder Backup/Restore (man auch auf die initiale Bereitstellung verzichten oder nur „joinen“).