Einleitung
Für viele Unternehmen hat die Verfügbarkeit ihrer Datenbanken oberste Priorität. Was passiert, wenn eine Datenbank plötzlich nicht mehr verbunden ist? Sind die Daten verloren?
Diesbezüglich müssen Sie sich bei Azure SQL-Datenbanken keine Sorgen machen. Mit einer sogenannten Hochverfügbarkeitslösung garantiert Azure, dass Ihre Datenbank zu 99,99 % der Zeit ausgeführt wird. Azure verarbeitet automatisch wichtige Wartungsaufgaben, z.B. Patches, Sicherungen, Windows- und SQL-Upgrades, aber auch ungeplante Ereignisse wie Ausfälle der zugrunde liegenden Hardware oder Software oder Netzwerkfehler.
Die Hochverfügbarkeitslösung soll sicherstellen, dass Daten, für die ein Commit, also der Abschluss einer Daten-Transaktion, ausgeführt wurde, nie aufgrund von Fehlern verloren gehen, dass sich Wartungsvorgänge nicht auf Ihre Workload auswirken und dass die Datenbank keinen Single Point of Failure in der Softwarearchitektur darstellt. Es gibt keine Wartungsfenster oder Ausfallzeiten, aufgrund derer Sie die Workload während der Aktualisierung oder Wartung der Datenbank beenden müssen.
Wie funktioniert das Ganze?
In Azure SQL-Datenbanken werden zwei Hochverfügbarkeitsmodelle verwendet:
Das Standardverfügbarkeitsmodell, das auf der Trennung der Compute- und Speicherebene basiert.
Das Standardverfügbarkeitsmodell umfasst zwei Ebenen:
- Die relationale Engine: Eine Compute-Ebene, auf der der Prozess sqlservr.exe ausgeführt wird, also Abfragen wie Select-Statements. Diese läuft auf einer primären Virtuellen Maschine (VM). Außerdem werden die erzeugten vorübergehenden und zwischengespeicherten Daten, also der Cache, auf einem SSD-Speicher gesammelt.
- Die Storage-Engine: Eine zustandsbehaftete Datenebene mit den eigentlichen Datenbankdateien, die in dem Cloudspeicher Azure Blob Storage gespeichert sind. Azure Blob Storage verfügt über integrierte Datenverfügbarkeits- und Redundanzfunktionen. Dadurch wird sichergestellt, dass jeder Datensatz in der Protokolldatei bzw. jede Seite in der Datendatei erhalten bleibt, auch wenn der SQL Server-Prozess abstürzt.
Der Knoten auf der Compute-Ebene, bestehend aus VM und Cache, wird von Azure Service Fabric verwaltet. Azure Service Fabric ist eine Plattform für verteilte Systeme, die das Packen, Bereitstellen und Verwalten skalierbarer und zuverlässiger Microservices und Container vereinfacht. Sie steuert die Integrität des Knotens und führt bei Bedarf ein sogenanntes Failover zu einem anderen Knoten durch.
Im Falle eines Failovers wird eine der sekundären VMs gestartet und als neue primäre mit dem Azure Blob Storage verbunden. Der Azure Blob Storage ist vom Verschiebevorgang nicht betroffen.
Bei starker Auslastung kann es hierbei zu einer gewissen Leistungseinbuße kommen, da die neue SQL-Instanz mit einem kalten Cache gestartet wird. Das heißt, die temporären Dateien aus dem SSD-Speicher werden nicht übergeben und müssen erst wieder neu erzeugt werden. Trotzdem, solange das Datencenter aktiv ist, garantiert dieser Prozess bereits eine Verfügbarkeit von 99,99 %!
Das Premium-Verfügbarkeitsmodell, welches auf einem Cluster von Datenbank-Engine-Prozessen basiert.
Das Modell bietet eine Integration von Computeressourcen (SQL Server-Datenbank-Engine-Prozess) und Speicher auf einem einzigen Knoten. Die Computeressourcen laufen wieder über eine VM, während die eigentlichen Datenbankdateien auf einem angefügten SSD-Speicher platziert werden. Dies erzielt eine noch niedrigere Latenz für Eingabe/Ausgabe als im Standardmodell.
Hochverfügbarkeit wird durch das Replizieren von Compute- und Speicherressourcen auf weitere Knoten erreicht, wodurch ein Cluster mit drei bis vier Knoten erstellt wird.
Der primäre Knoten überträgt ständig Änderungen der Reihe nach auf die sekundären Knoten und stellt sicher, dass die Daten vor dem Ausführen eines Commits für jede Transaktion mit mindestens einem sekundären Replikat synchronisiert werden. Durch diesen Prozess wird sichergestellt, dass bei einem Ausfall des primären Knotens stets ein vollständig synchronisierter Knoten vorhanden ist, auf den ein Failover ausgeführt werden kann.
Das Failover wird von der Azure Service Fabric initiiert. Sobald das sekundäre Replikat zum neuen primären Knoten wird, wird ein weiteres sekundäres Replikat erstellt, um sicherzustellen, dass das Cluster über eine ausreichende Anzahl von Knoten verfügt. Nach Abschluss des Failovers werden die SQL-Verbindungen automatisch an den neuen primären Knoten umgeleitet.
Zusätzlich wird ein Backup der Datenbankdateien im Azure Standard Storage gespeichert.
Die Hochverfügbarkeitslösungen sind bereits integriert!
Das Standardmodell wird für die Dienstebenen „Basic“, „Standard“ und „Universell“ genutzt, während das Premium-Modell in den Dienstebenen „Premium“ und „Unternehmenskritisch“ enthalten ist. Für Sie entstehen dabei keine Mehrkosten.
Neben der geringeren Latenzzeit im Premium-Verfügbarkeitsmodell haben die Datenbanktypen Premium und Unternehmenskritisch noch weitere Vorteile, auf die wir aber nicht weiter eingehen müssen. Natürlich kommt der Premium-Service auch mit einem deutlich höheren Preis.
Generell lässt sich aber sagen, dass dem Normalverbraucher in den meisten Fällen eine Azure SQL-Datenbank der Dienstebene „Standard“ völlig ausreicht.
Das klingt doch schon mal ziemlich gut! Aber was passiert, sollte tatsächlich einmal ein komplettes Rechenzentrum ausfallen?
Das erfahren Sie demnächst in TEIL 2