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 Failover Cluster on Azure

ich bin heute “gezwungen” gewesen mir “schnell” ein SQL Server 2019 Failover Cluster zu erstellen um etwas zu testen, da der Kunde nur eine produktive Umgebung hat und ich erst einen funktionierenden Fahrplan für die Umsetzung benötige… also schnell eine Anleitung rausgesucht, ich wusste was grobes aber musste mich natürlich erst einmal in die Details einlesen…

Ich habe schon mehrfach gehört, dass Microsoft seit einiger Zeit auch “Shared Disks” für eben Failover Cluster anbietet, aber wie man diese nun deployed und zusätzlich noch richtig in Windows bzw dem Cluster Manager einbindet, diese Informationen fehl(t)en mir. Also Google gefragt, dieser mich auf eine Beitrag in den Microsoft Docs verwiesen und ich einfach mal drauflos gelegt.

Erstellen Sie eine FCI mit gemeinsam genutzten Azure-Festplatten

in diesem Beitrag steht unter Voraussetzungen folgendes:

Bevor Sie die in diesem Artikel aufgeführten Anweisungen ausführen, sollten Sie über Folgendes verfügen:
 - Ein Azure-Abonnement
 - Zwei oder mehr virtuelle Windows Azure-Computer. Verfügbarkeitsgruppen und Näherungsplatzierungsgruppe werden bei SSD Premium und Verfügbarkeitszonen werden   bei für Ultra Disks unterstützt. Wenn Sie eine PPG verwenden, müssen alle Knoten in derselben Gruppe vorhanden sein.
 - Ein Konto mit Berechtigungen zum Erstellen von Objekten auf virtuellen Azure-Computern und in Active Directory
 - Die neueste Version von PowerShell.

Meine Überlegungen dazu… Azure Subscription habe ich, zwei virtuelle Maschinen kann ich schnell deployen, AvailabilityGroups oder ProximityGroups habe ich auch bzw brauche ich hier nicht und eine Domäne mit entsprechendem DomainAdmin-User habe ich auch… also schnell zwei virtuelle Maschinen “SQL Server 2019 Developer auf Windows 2019” deployed und die Anleitung genau befolgt.

  • SharedDiskConfig.json angelegt und gemäß Doku befüllt
  • ResourceGroupDeployment mit SharedDiskConfig.json ausgeführt, also die SharedDisk angelegt
  • SharedDisk der ersten virtuellen Maschine hinzugefügt
  • SharedDisk der zweiten virtuellen Maschine hinzugefügt… HALT STOP, eine Fehlermeldung…
Cannot change network spine of shared disk myDataDisk while it is attached to running VM(s)

die Fehlersuche beginnt…

Da dies meine ersten Versuche mit Shared Disks sind/waren, habe ich natürlich erst einmal alles genauer untersucht bzw versucht, zumal die Shared Disk trotz Fehlermeldung an der zweiten Maschine (zumindest im Portal) zu sehen war. Restart der virtuellen Maschine ging nicht, wegen dem komischen Deployment-Zustand, Abhängen der Platte im ersten Moment auch nicht, als Owner der Platte konnte ich die erste VM ausmachen, aber wie kann ich jetzt die zweite VM zum Owner machen… alles sehr strange…

Aber es gab etwas was mich doch ein wenig irritierte… sowohl in der Anleitung als in den Powershell Snippets gibt es den Hinweis auf die Verwendung von Proximity Placement Groups. Beim Googeln nach der Fehlermeldung stieß ich dann auch einen Beitrag auf Stackoverflow, wo jemand denselben Fehler hatte und die Lösung eben in diesen Proximity Placement Gruppen gefunden hatte. Aber wieso wird in der Dokumentation nicht wirklich daraufhin gewiesen… Na gut, erst einmal selber ausprobieren, ob das dann funktioniert.

Anlegen einer PPG und Maschinen hinzufügen

Ok, also habe ich versucht den kürzesten und einfachsten Weg zu nehmen… Anlegen einer Proximity-Placement-Group und die beiden bereits vorhandenen virtuellen Maschinen dieser hinzufügen. Die Anlage der PPG über das Azure Portal war schnell und einfach (Ressourcengruppe => neue Ressource => PPG suchen und auswählen => Region und Namen eintragen und erstellen), das Hinzufügen der VMs habe ich dann ebenfalls über das Portal gemacht, dazu müssen die Maschinen erst einmal gestoppt werden und die Ressourcen deallokiert werden.

Danach habe ich vorsichtshalber noch einmal die Shared-Disk gelöscht und neu erstellt und konnte diese dann erfolgreich an beide SQL Server VMs anbinden.

$dataDiskConfig = New-AzDiskConfig -Location 'eastus2' -DiskSizeGB 1024 -AccountType Premium_LRS -CreateOption Empty -MaxSharesCount 2

New-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName 'myClusterDisk' -Disk $dataDiskConfig


$vm = Get-AzVm -ResourceGroupName 'RG-SQLServer' -Name "winsqlcl01"
$dataDisk = Get-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName "myClusterDisk"
$vm = Add-AzVMDataDisk -VM $vm -Name "myClusterDisk" -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 2
update-AzVm -VM $vm -ResourceGroupName 'RG-SQLServer'


$vm = Get-AzVm -ResourceGroupName 'RG-SQLServer' -Name "winsqlcl02"
$dataDisk = Get-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName "myClusterDisk"
$vm = Add-AzVMDataDisk -VM $vm -Name "myClusterDisk" -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 2
update-AzVm -VM $vm -ResourceGroupName 'RG-SQLServer'

Im Nachgang konnte ich auf beiden Servern problemlos erst das Windows Failover Cluster validieren und erstellen, um dann die SQL Server Knoten zu installieren bzw hinzuzufügen.

Ich werde also zeitnah die Beschreibung bei Microsoft anpassen (lassen). Ich hoffe dieser Blogpost hilft euch bei Zeiten weiter, damit ihr nicht so lange braucht 😉