Hochverfügbarkeit für Azure SQL Managed Instance

  • Artikel

Gilt für:Azure SQL Managed Instance

In diesem Artikel wird die Hochverfügbarkeit in Azure SQL Managed Instance beschrieben.

Wichtig

Zonenredundante Konfiguration befindet sich in der öffentlichen Vorschau für die Dienstebene „Universell“ und ist allgemein für die Dienstebene „Unternehmenskritisch“ verfügbar.

Übersicht

Das Ziel der Hochverfügbarkeitsarchitektur in Azure SQL Managed Instance ist es, die Auswirkungen auf die Kunden-Workloads durch vom Kunden initiierte Verwaltungsvorgänge zu minimieren, die zu einer kurzen Ausfallzeit, Service-Wartungsarbeiten und ungeplanten Ausfällen führen. Weitere Informationen zu bestimmten SLAs für verschiedene Dienstebenen finden Sie in der Vereinbarung zum Servicelevel für Azure SQL Managed Instance.

Hohe Verfügbarkeit schützt Sie vor Auswirkungen auf:

  • die Verfügbarkeitszone, die das Rechenzentrum bildet (im Fall einer Region mit mehreren Zonen)
  • das Rack, in dem die Knoten, die Ihren Dienst betreiben, laufen
  • den Knoten selbst
  • Anwendungsschicht

Um die Auswirkungen regionaler oder größerer Ausfälle zu minimieren, können Sie eine der verfügbaren Techniken verwenden, die wir in unserer Übersicht zur Geschäftskontinuität behandeln.

SQL Managed Instance wird in der neuesten stabilen Version der SQL Server-Datenbank-Engine unter dem Windows-Betriebssystem mit allen anwendbaren Patches ausgeführt. SQL Managed Instance verarbeitet automatisch wichtige Wartungsaufgaben, z. B. Patches, Sicherungen, Windows- und SQL-Engine-Upgrades, aber auch ungeplante Ereignisse wie Ausfälle der zugrunde liegenden Hardware oder Software oder Netzwerkfehler. Wenn eine Instanz gepatcht oder ein Failover dafür ausgeführt wird, hat die Downtime keine Auswirkungen, wenn Sie in Ihrer App Wiederholungslogik einsetzen. SQL Managed Instance ermöglicht auch unter den kritischsten Umständen eine schnelle Wiederherstellung und stellt sicher, dass Ihre Daten immer verfügbar sind. Die meisten Benutzer*innen bemerken nicht, dass kontinuierlich Upgrades durchgeführt werden.

Die Hochverfügbarkeitslösung soll sicherstellen, dass Daten, für die ein Commit ausgeführt wurde, nie aufgrund von Fehlern verloren gehen, dass sich Wartungsvorgänge nicht auf Ihre Workload auswirken und dass die Instanz keinen Single Point of Failure in der Softwarearchitektur darstellt.

Es gibt zwei verschiedene Hochverfügbarkeits-Architekturmodelle, die auf der Dienstebene basieren:

  • Das Remote-Storage-Modell basiert auf einer Trennung von Compute und Storage auf der Dienstebene Universell und Universell der nächsten Generation, die sich auf die hohe Verfügbarkeit und Zuverlässigkeit des Remote-Storage und die hohe Verfügbarkeit der von Azure Service Fabric verwalteten Compute-Cluster stützt. Dieses Hochverfügbarkeitsmodell zielt auf budgetorientierte Geschäftsanwendungen ab, die bei Wartungsarbeiten gewisse Leistungseinbußen tolerieren können.
  • Das lokale Speichermodell basiert auf einem Cluster von Datenbank-Engine-Prozessen, die sich auf ein Quorum von verfügbaren Datenbank-Engine-Knoten auf der Dienstebene Unternehmenskritisch stützen, die über lokalen Speicher verfügen. Dieses lokale Speichermodell zielt auf unternehmenskritische Anwendungen ab, die eine hohe Transaktionsrate haben und eine hohe EA-Leistung erfordern. Die Hochverfügbarkeits-Architektur garantiert minimale Auswirkungen auf die Leistung Ihres Workloads während der Wartungsarbeiten.

Lokal redundante Verfügbarkeit

Lokal redundante Verfügbarkeit basiert auf der Speicherung Ihrer Serverknoten und Daten innerhalb eines einzelnen Rechenzentrums in der primären Region und dem Schutz Ihre Daten bei lokalen Ausfällen, z. B. bei einem kleinen Netzwerk oder einem Stromausfall. Bei einem Notfall von großem Ausmaß in einer Region (Feuer, Überschwemmung usw.) gehen jedoch eventuell alle Replikate in einem Speicherkonto oder Daten auf Serverkonten verloren oder könnten nicht mehr wiederhergestellt werden. Um Ihre Daten bei Verwendung der Option für lokal redundante Verfügbarkeit zusätzlich zu schützen, sollten Sie daher eine resilientere Speicheroption für Ihre Datenbanksicherungen verwenden.

Universelle Dienstebene

Für die Dienstebene „Universell“ wird die Architektur für Remotespeicherverfügbarkeit verwendet. In der folgenden Abbildung werden vier Knoten mit getrennter Compute- und Speicherebene veranschaulicht.

Darstellung der Trennung von Compute und Speicher.

Das Modell für Remotespeicherverfügbarkeit umfasst zwei Ebenen:

  • Eine zustandslose Computeebene, auf der der Datenbank-Engine-Prozess ausgeführt wird und die nur vorübergehende und zwischengespeicherte Daten enthält, z. B. die Datenbanken tempdb und model auf der angefügten SSD, Plancache, Puffer- und Columnstore-Pool im Arbeitsspeicher. Dieser zustandslose Knoten wird vom Azure Service Fabric-Dienst gesteuert, der die Datenbank-Engine initialisiert, die Integrität des Knotens steuert und bei Bedarf ein Failover auf einen anderen Knoten durchführt.
  • Eine zustandsbehaftete Datenebene mit den Datenbankdateien (.mdf and .ldf), die in Azure Blob Storage gespeichert sind. Azure Blob Storage verfügt über integrierte Datenverfügbarkeits- und Redundanzfunktionen. Lokal redundante Verfügbarkeit basiert auf der Speicherung Ihrer Daten in lokal redundantem Speicher (LRS), der Ihre Daten dreimal innerhalb eines einzelnen Rechenzentrums in der primären Region kopiert. Dadurch wird sichergestellt, dass jeder Datensatz in der Protokolldatei bzw. jede Seite in der Datendatei erhalten bleibt, auch wenn der Datenbank-Engine-Prozess abstürzt.

Bei jedem Upgrade der Datenbank-Engine oder des Betriebssystems sowie beim Erkennen eines Fehlers wird der zustandslose Datenbank-Engine-Prozess in Azure Service Fabric zu einem anderen zustandslosen Computeknoten mit ausreichender freier Kapazität verschoben. Daten in Azure Blob Storage sind vom Verschiebevorgang nicht betroffen, und die Daten- und Protokolldateien werden an den neu initialisierten Datenbank-Engine-Prozess angefügt. Dieser Prozess garantiert Hochverfügbarkeit, bei umfangreichen Workloads ist jedoch möglicherweise eine gewisse Leistungsbeeinträchtigung während des Übergangs festzustellen, da der neue Datenbank-Engine-Prozess mit einem kalten Cache gestartet wird.

Dienstebene Universell der nächsten Generation

Hinweis

Das Upgrade auf die Dienstebene Universell der nächsten Generation befindet sich derzeit in der Vorschau.

Universell der nächsten Generation ist ein Architekturupgrade der vorhandenen Dienstebene Universell mit einer aktualisierten Remotespeicherebene, die Instanzdaten und Protokolldateien auf verwalteten Datenträgern statt auf Seitenblobs speichert.

Dienstebene „Unternehmenskritisch“

Die Dienstebene „Unternehmenskritisch“ nutzt das Modell für die Verfügbarkeit von lokalem Speicher, das eine Integration von Computeressourcen (Datenbank-Engine-Prozess) und Speicher (lokal angefügte SSD) auf einem einzigen Knoten bietet. Hochverfügbarkeit wird durch Replizieren von Compute- und Speicherressourcen auf weiteren Knoten erreicht.

Darstellung eines Clusters von Datenbank-Engine-Knoten.

Die zugrunde liegenden Datenbankdateien (MDF- und LDF-Dateien) werden auf dem angefügten SSD-Speicher platziert, um eine E/A mit äußerst niedriger Latenz für Ihre Workload zu erzielen. Hochverfügbarkeit wird anhand einer ähnlichen Technologie wie AlwaysOn-Verfügbarkeitsgruppen in SQL Server implementiert. Der Cluster umfasst ein einzelnes primäres Replikat, der für Lese-/Schreib-Workloads der Kunden zugänglich ist, sowie bis zu drei sekundäre Replikate (Compute und Speicher) mit Kopien der Daten. Das primäre Replikat überträgt ständig Änderungen an die sekundären Replikate, um sicherzustellen, dass die Daten auf einer ausreichenden Anzahl sekundärer Replikate gespeichert sind, bevor jede Transaktion übertragen wird. Dieser Prozess garantiert, dass für den Fall, dass das primäre Replikat oder ein lesbares sekundäres Replikat aus irgendeinem Grund nicht mehr verfügbar ist, immer ein vollständig synchronisiertes Replikat zur Verfügung steht, auf dem das Failover ausgeführt werden kann. Das Failover wird von der Azure Service Fabric initiiert. Sobald ein sekundäres Replikat zum neuen primären Replikat wird, wird ein weiteres sekundäres Replikat erstellt, um sicherzustellen, dass der Cluster über eine ausreichende Anzahl von Replikaten verfügt, um ein Quorum beizubehalten. Sobald das Failover abgeschlossen ist, werden Azure SQL-Verbindungen automatisch an das neue primäre Replikat (oder das lesbare sekundäre Replikat basierend auf der Verbindungszeichenfolge) weitergeleitet.

Als weiteren Vorteil bietet das Modell für die Verfügbarkeit von lokalem Speicher die Möglichkeit, Azure SQL-Verbindungen mit Schreibschutz auf eines der sekundären Replikate umzuleiten. Dieses Feature wird als horizontale Leseskalierung bezeichnet. Es bietet 100 % zusätzliche Computekapazität ohne anfallende Zusatzkosten, sodass Schreibschutzvorgänge wie analytische Workloads vom primären Replikat ausgelagert werden können.

Zonenredundante Verfügbarkeit

Die zonenredundante Verfügbarkeit basiert auf der Platzierung von Serverknoten und Speicherreplikaten in drei Azure-Verfügbarkeitszonen in der primären Region. Jede Verfügbarkeitszone ist ein getrennter physischer Standort mit unabhängigen Stromversorgungs-, Kühlungs- und Netzwerkgeräten.

In der Standardeinstellung wird der Cluster von Knoten für das Modell für die Verfügbarkeit von lokalem Speicher im selben Rechenzentrum erstellt. Mit der Einführung von Azure-Verfügbarkeitszonen kann SQL Managed Instance nun verschiedene Replikate von einer Instanz des Typs „Unternehmenskritisch“ in unterschiedlichen Verfügbarkeitszonen in derselben Region platzieren. Auf die gleiche Weise werden die zustandslosen Computeknoten einer Dienstebene „Universell“ in einer anderen Verfügbarkeitszone platziert, während der zustandsbehaftete Speicher die Konfiguration zonenredundanten Speicher (ZRS) verwendet.

Um einen Single Point of Failure auszuschließen, wird der Steuerring zudem in mehreren Zonen als drei Gatewayringe (GW) kopiert. Die Weiterleitung an einen bestimmten Gatewayring wird durch Azure Traffic Manager (ATM) gesteuert. Durch die Auswahl einer zonenredundanten Konfiguration können Sie Ihre Instanzen der Dienstebene „Unternehmenskritisch“ oder „Universell“ für deutlich mehr Ausfallszenarien resistent machen (z. B. für schwerwiegende Ausfälle von Rechenzentren), ohne Änderungen an der Anwendungslogik vornehmen zu müssen. Sie können zudem alle vorhandenen Instanzen der Dienstebene „Unternehmenskritisch“ oder „Universell“ in die zonenredundante Konfiguration konvertieren.

Da die zonenredundanten Instanzen über Replikate in verschiedenen Rechenzentren mit einiger Entfernung dazwischen verfügen, könnte sich durch die erhöhte Netzwerklatenz die Commitzeit für Transaktionen erhöhen und dadurch die Leistung einiger OLTP-Workloads beeinträchtigt werden. Sie können jederzeit zur Einzelzonenkonfiguration zurückkehren, indem Sie die zonenredundante Einstellung deaktivieren. Dieser Prozess ist ein Onlinevorgang und ähnelt dem regulären Upgrade des Dienstebenenziels. Am Ende des Prozesses wird die Instanz aus einem zonenredundanten Ring zum Ring einer einzelnen Zone migriert (oder umgekehrt).

Die zonenredundante Version der Hochverfügbarkeitsarchitektur wird im folgenden Diagramm veranschaulicht:

Abbildung der Architektur mit zonenredundanter Hochverfügbarkeit

Berücksichtigen Sie bei der Verwendung von Zonenredundanz Folgendes:

  • Zonenredundanz ist für die Dienstebene Universell der nächsten Generation nicht verfügbar.
  • Aktuelle Informationen zu den Regionen, die zonenredundante Konfigurationen unterstützen, finden Sie unter Unterstützung der Dienste nach Region.
  • Für zonenredundante Verfügbarkeit ist die Auswahl eines anderen Wartungsfensters als des Standards derzeit in ausgewählten Regionen verfügbar.

Unterstützte Regionen für Unternehmenskritische Instanzen

Die Zonenredundanz für SQL Managed Instance der Dienstebene „Unternehmenskritisch“ wird in den folgenden Regionen unterstützt:

Amerika Europa Naher Osten Afrika Asien-Pazifik
Brasilien Süd Frankreich, Mitte Katar, Mitte Südafrika, Norden Australien (Osten)
Kanada, Mitte Italien, Norden Israel, Mitte Indien, Mitte
USA (Mitte) Deutschland, Westen-Mitte Japan, Osten
East US Norwegen, Osten Korea, Mitte
USA (Ost) 2 Nordeuropa Asien, Südosten
USA Süd Mitte UK, Süden Asien, Osten
USA, Westen 2 Schweden, Mitte
USA, Westen 3 Schweiz, Norden
Polen, Mitte

Unterstützte Regionen für Universelle Instanzen

Hinweis

Zonenredundante Konfiguration ist in der öffentlichen Vorschauversion für die Dienstebene „Universell“.

Amerika Europa Naher Osten Afrika Asien-Pazifik
Brasilien Süd Frankreich, Mitte Katar, Mitte Südafrika, Norden Australien (Osten)
East US Italien, Norden Israel, Mitte Indien, Mitte
USA (Ost) 2 Deutschland, Westen-Mitte Japan, Osten
USA Süd Mitte Norwegen, Osten Korea, Mitte
USA, Westen 2 Nordeuropa Asien, Südosten
USA, Westen 3 UK, Süden Asien, Osten
Schweden, Mitte
Schweiz, Norden
Polen, Mitte

Testen der Resilienz von Anwendungsfehlern

Hochverfügbarkeit ist ein wesentlicher Bestandteil der SQL Managed Instance-Plattform und transparent für Ihre Datenbankanwendungen. Es ist uns jedoch bewusst, dass Sie möglicherweise testen möchten, wie sich die bei geplanten oder ungeplanten Ereignissen eingeleiteten automatischen Failover-Vorgänge ggf. auf eine Anwendung auswirken, ehe Sie sie in der Produktionsumgebung einsetzen. Sie können ein Failover manuell auslösen, indem Sie eine spezielle API zum Neustarten einer verwalteten Instanz aufrufen. Bei einer zonenredundanten Instanz führt der API-Aufruf dazu, dass Clientverbindungen von der Verfügbarkeitszone der alten primären Datenbank zur neuen primären Datenbank in einer anderen Verfügbarkeitszone umgeleitet werden. Zusätzlich zu den Tests, wie sich das Failover auf bestehende Datenbanksitzungen auswirkt, können Sie also auch prüfen, ob sich aufgrund von Änderungen an der Netzwerklatenz auch die Gesamtleistung ändert. Da Neustartvorgänge aufwendig sind und eine große Anzahl von ihnen die Plattform belasten könnte, ist für jede verwaltete Datenbank nur alle 15 Minuten ein Failoveraufruf erlaubt.

Ein Failover kann mithilfe von PowerShell, der Rest-API oder Azure CLI initiiert werden:

PowerShell REST-API Azure CLI
Invoke-AzSqlInstanceFailover SQL Managed Instance: Failover az sql mi failover kann für einen REST-API-Aufruf über die Azure-Befehlszeilenschnittstelle verwendet werden.

Schlussbemerkung

Azure SQL Managed Instance verfügt über eine integrierte Hochverfügbarkeitslösung, die tief in die Azure-Plattform integriert ist. Der Dienst hängt von Service Fabric ab, um Ausfälle zu erkennen und wiederherzustellen, von Azure Blob Storage, um Daten zu schützen, und von Verfügbarkeitszonen für höhere Fehlertoleranz. Und für die unternehmenskritische Dienstebene verwendet SQL Managed Instance die SQL Server Always On-Verfügbarkeitsgruppen-Technologie für Datenbank-Replikation und Failover. Dank der Kombination dieser Technologien können Anwendungen die Vorteile eines gemischten Speichermodells voll ausschöpfen und sehr anspruchsvolle SLAs unterstützen.

Nächste Schritte