Always On-Verfügbarkeitsgruppe für SQL Server auf Azure-VMs

Gilt für: SQL Server auf Azure-VMs

Dieser Artikel bietet eine Einführung in Always On-Verfügbarkeitsgruppen für SQL Server auf Azure Virtual Machines (VMs).

Informationen zu den ersten Schritten finden Sie im Tutorial zu Verfügbarkeitsgruppen.

Übersicht

Always On-Verfügbarkeitsgruppen in Azure Virtual Machines ähneln lokalen Always On-Verfügbarkeitsgruppen und basieren auf dem zugrunde liegenden Windows Server-Failovercluster. Da die virtuellen Computer jedoch in Azure gehostet werden, gibt es auch einige zusätzliche Überlegungen, wie z. B. VM-Redundanz und das Routing von Datenverkehr im Azure-Netzwerk.

Das folgende Diagramm veranschaulicht eine Verfügbarkeitsgruppe für SQL Server auf Azure-VMs:

VM-Redundanz

Zur Verbesserung der Redundanz und Verfügbarkeit sollten sich die virtuellen SQL Server-Computer entweder in der gleichen Verfügbarkeitsgruppe oder in unterschiedlichen Verfügbarkeitszonen befinden.

Die Platzierung mehrerer virtueller Computer in derselben Verfügbarkeitsgruppe dient zum Schutz vor Ausfällen in einem Rechenzentrum infolge von Hardwarefehlern, da virtuelle Computer in einer Verfügbarkeitsgruppe nicht dieselben Ressourcen verwenden, sowie vor Ausfällen infolge von Updates, da virtuelle Computer innerhalb einer Verfügbarkeitsgruppe nicht gleichzeitig aktualisiert werden.

Verfügbarkeitszonen schützen vor dem Ausfall eines gesamten Rechenzentrums. Die einzelnen Zonen stellen jeweils eine Gruppe von Rechenzentren innerhalb einer Region dar. Durch die Platzierung von Ressourcen in unterschiedlichen Verfügbarkeitszonen wird sichergestellt, dass durch einen Ausfall auf Rechenzentrumsebene nicht alle Ihre virtuellen Computer offline geschaltet werden.

Bei der VM-Erstellung müssen Sie sich entscheiden, ob Sie Verfügbarkeitsgruppen oder Verfügbarkeitszonen konfigurieren möchten. Ein virtueller Azure-Computer kann nicht mit beidem konfiguriert werden.

Obwohl Verfügbarkeitszonen gegenüber Verfügbarkeitsgruppen eine höhere Verfügbarkeit bieten können (99,99 % im Vergleich zu 99,95 %), sollte auch die Leistung berücksichtigt werden. Virtuelle Computer innerhalb einer Verfügbarkeitsgruppe können in einer Näherungsplatzierungsgruppe platziert werden, um sicherzustellen, dass sie nah beieinander liegen, wodurch die Netzwerklatenz zwischen ihnen minimiert wird. Zwischen virtuellen Computer in unterschiedlichen Verfügbarkeitszonen ist die Netzwerklatenz höher, sodass zum Synchronisieren von Daten zwischen den primären und sekundären Replikaten mehr Zeit erforderlich sein kann. Dies kann zu Verzögerungen auf dem primären Replikat führen und die Wahrscheinlichkeit eines Datenverlusts im Falle eines ungeplanten Failovers erhöhen. Es ist wichtig, die vorgeschlagene Lösung unter Last zu testen und sicherzustellen, dass sie die SLAs für Leistung und Verfügbarkeit erfüllt.

Konnektivität

Um die Verbindung mit Ihrem Verfügbarkeitsgruppenlistener wie in der lokalen Umgebung herzustellen, stellen Sie Ihre SQL Server-VMs in mehreren Subnetzen innerhalb desselben virtuellen Netzwerks bereit. Bei der Verwendung mehrerer Subnetze entfällt die Notwendigkeit einer zusätzlichen Abhängigkeit von einer Azure Load Balancer-Instanz oder von einem verteilten Netzwerknamen (Distributed Network Name, DNN), um Ihren Datenverkehr an Ihren Listener weiterzuleiten.

Wenn Sie Ihre SQL Server-VMs in einem einzelnen Subnetz bereitstellen, können Sie einen virtuellen Netzwerknamen (VNN) und eine Azure Load Balancer-Instanz oder einen verteilten Netzwerknamen (Distributed Network Name, DNN) konfigurieren, um Datenverkehr an Ihren Verfügbarkeitsgruppenlistener weiterzuleiten. Überprüfen Sie die Unterschiede zwischen den beiden, und stellen Sie dann entweder einen Namen eines verteilten Netzwerks (Distributed Network Name, DNN) oder einen Namen eines virtuellen Netzwerks (Virtual Network Name, VNN) für Ihre Verfügbarkeitsgruppe bereit.

Bei Verwendung des DNN funktionieren die meisten SQL Server-Features transparent mit Verfügbarkeitsgruppen. Es gibt jedoch bestimmte Features, die ggf. besondere Aufmerksamkeit erfordern. Weitere Informationen finden Sie unter Interoperabilität zwischen Verfügbarkeitsgruppe und DNN.

Darüber hinaus gibt es einige Verhaltensunterschiede zwischen der Funktionalität des VNN-Listeners und des DNN-Listeners, die zu beachten sind:

• Failoverzeit: Die Failoverzeit ist bei Verwendung eines DNN-Listeners schneller, da nicht gewartet werden muss, bis der Netzwerklastenausgleich das Fehlerereignis erkennt und das Routing ändert.
• Vorhandene Verbindungen: Verbindungen, die mit einer bestimmten Datenbank innerhalb einer Verfügbarkeitsgruppe hergestellt werden, für die ein Failover ausgeführt wird, werden geschlossen, aber andere Verbindungen mit dem primären Replikat bleiben geöffnet, da der DNN während des Failoverprozesses online bleibt. Dies ist anders als in einer herkömmlichen VNN-Umgebung, in der alle Verbindungen mit dem primären Replikat normalerweise geschlossen werden, wenn für die Verfügbarkeitsgruppe ein Failover ausgeführt wird, der Listener offline geht und das primäre Replikat in die sekundäre Rolle übergeht. Wenn Sie einen DNN-Listener verwenden, müssen Sie möglicherweise Anwendungsverbindungszeichenfolgen anpassen, um sicherzustellen, dass Verbindungen beim Failover an das neue primäre Replikat umgeleitet werden.
• Offene Transaktionen: Offene Transaktionen für eine Datenbank in einer Verfügbarkeitsgruppe, für die ein Failover ausgeführt wird, werden geschlossen und es wird ein Rollback durchgeführt. Zudem müssen Sie die Verbindung manuell wiederherstellen. Schließen Sie z. B. in SQL Server Management Studio das Abfragefenster, und öffnen Sie ein neues.

Zum Einrichten eines VNN-Listeners in Azure ist ein Lastenausgleich erforderlich. Es gibt zwei Hauptoptionen für einen Lastenausgleich in Azure: extern (öffentlich) oder intern. Der externe (öffentliche) Lastenausgleich verfügt über Internetzugriff und ist einer öffentlichen virtuellen IP-Adresse zugeordnet, auf die über das Internet zugegriffen werden kann. Ein interner Lastenausgleich unterstützt nur Clients innerhalb desselben virtuellen Netzwerks. Für beide Lastenausgleichstypen müssen Sie Direct Server Return aktivieren.

Sie können weiterhin separate Verbindungen mit den einzelnen Verfügbarkeitsreplikaten herstellen, indem Sie eine direkte Verbindung mit der Serverinstanz herstellen. Da Verfügbarkeitsgruppen abwärtskompatibel mit Clients für die Datenbankspiegelung sind, können Sie außerdem Verbindungen mit Verfügbarkeitsreplikaten wie Datenbankspiegelungspartnern herstellen, sofern die Replikate ähnlich wie die Datenbankspiegelung konfiguriert sind:

• Es gibt ein primäres Replikat und ein sekundäres Replikat.
• Das sekundäre Replikat ist als nicht lesbar konfiguriert (Option Lesbare sekundäre Rolle ist auf Nein festgelegt).

Im Anschluss sehen Sie ein Beispiel für eine Clientverbindungszeichenfolge für eine einer Datenbankspiegelung ähnlichen Konfiguration mithilfe von ADO.NET oder SQL Server Native Client:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Weitere Informationen zur Clientkonnektivität finden Sie unter:

• Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client
• Verbinden von Clients mit einer Datenbank-Spiegelungssitzung (SQL Server)
• Connecting to Availability Group Listener in Hybrid IT (in englischer Sprache)
• Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server)
• Verwenden von Verbindungszeichenfolgen für die Datenbankspiegelung mit Verfügbarkeitsgruppen

Ein einzelnes Subnetz erfordert einen Lastenausgleich

Wenn Sie einen Verfügbarkeitsgruppenlistener in einem herkömmlichen lokalen Windows Server-Failovercluster (WSFC) erstellen, wird ein DNS-Eintrag für den Listener mit der von Ihnen angegebenen IP-Adresse erstellt, und diese IP-Adresse wird der MAC-Adresse des aktuellen primären Replikats in den ARP-Tabellen von Switches und Routern im lokalen Netzwerk zugeordnet. Zu diesem Zweck verwendet der Cluster GARP (Gratuitous ARP), um die neueste IP-MAC-Adressenzuordnung an das Netzwerk zu senden, wenn nach dem Failover ein neues primäres Replikat ausgewählt wird. In diesem Fall ist die IP-Adresse für den Listener, und MAC ist das aktuelle primäre Replikat. GARP erzwingt eine Aktualisierung der ARP-Tabelleneinträge für die Switches und Router, und alle Benutzer, die eine Verbindung mit der Listener-IP-Adresse herstellen, werden nahtlos an das aktuelle primäre Replikat weitergeleitet.

Aus Sicherheitsgründen ist das Senden in einer öffentlichen Cloud (Azure, Google, AWS) nicht zulässig, sodass die Verwendung von ARPs und GARPs in Azure nicht unterstützt wird. Um diesen Unterschied in Netzwerkumgebungen zu überwinden, sind SQL Server-VMs in einer einzelnen Subnetzverfügbarkeitsgruppe von Lastenausgleichsmodulen abhängig, um Datenverkehr an die entsprechenden IP-Adressen weiterzuleiten. Lastenausgleichsmodule werden mit einer Front-End-IP-Adresse konfiguriert, die dem Listener entspricht, und ein Testport wird zugewiesen, sodass der Azure Load Balancer regelmäßig die Status der Replikate in der Verfügbarkeitsgruppe abruft. Da nur die SQL Server-VM des primären Replikats auf den TCP-Test reagiert, wird eingehender Datenverkehr dann an die VM weitergeleitet, die erfolgreich auf den Test reagiert. Darüber hinaus wird der entsprechende Testport als WSFC-Cluster-IP konfiguriert, um sicherzustellen, dass das primäre Replikat auf den TCP-Test reagiert.

Verfügbarkeitsgruppen, die in einem einzelnen Subnetz konfiguriert sind, müssen entweder einen Lastenausgleich oder einen verteilten Netzwerknamen (Distributed Network Name, DNN) verwenden, um Datenverkehr an das entsprechende Replikat weiterzuleiten. Um diese Abhängigkeiten zu vermeiden, konfigurieren Sie Ihre Verfügbarkeitsgruppe in mehreren Subnetzen, sodass der Verfügbarkeitsgruppenlistener mit einer IP-Adresse für ein Replikat in jedem Subnetz konfiguriert ist und Datenverkehr entsprechend weiterleiten kann.

Wenn Sie Ihre Verfügbarkeitsgruppe bereits in einem einzelnen Subnetz erstellt haben, können Sie sie in eine Umgebung mit mehreren Subnetzen migrieren.

Leasemechanismus

Bei SQL Server bestimmt die Ressourcen-DLL der Verfügbarkeitsgruppe den Zustand der Gruppe auf Grundlage des jeweiligen Leasemechanismus und der Always On-Integritätserkennung. Die Ressourcen-DLL der Verfügbarkeitsgruppe stellt die Ressourcenintegrität über den Vorgang IsAlive bereit. Der Ressourcenmonitor ruft „IsAlive“ im Heartbeatintervall des Clusters ab, das über die clusterweiten Werte CrossSubnetDelay und SameSubnetDelay festgelegt wird. Auf einem primären Knoten initiiert der Clusterdienst immer dann ein Failover, wenn der IsAlive-Aufruf an die Ressourcen-DLL zurückgibt, dass die Verfügbarkeitsgruppe nicht fehlerfrei ist.

Die Ressourcen-DLL der Verfügbarkeitsgruppe überwacht den Status interner SQL Server-Komponenten. „Sp_server_diagnostics“ meldet die Integrität dieser Komponenten in einem Intervall an SQL Server, das von HealthCheckTimeout gesteuert wird.

Im Gegensatz zu anderen Failovermechanismen spielt die SQL Server-Instanz beim Leasemechanismus eine aktive Rolle. Der Leasemechanismus wird als LooksAlive-Validierung zwischen dem Clusterressourcenhost und dem SQL Server-Prozess verwendet. Der Mechanismus dient der Sicherstellung, dass die beiden Seiten (Cluster- und SQL Server-Dienst) in häufigem Kontakt stehen, den Zustand des jeweils anderen überprüfen und schließlich ein Split-Brain-Szenario verhindern.

Beim Konfigurieren einer Verfügbarkeitsgruppe in Azure-VMs müssen diese Schwellenwerte häufig anders konfiguriert werden als in einer lokalen Umgebung. Informationen zum Konfigurieren von Schwellenwerteinstellungen gemäß bewährten Methoden für Azure-VMs finden Sie unter Bewährte Methoden für Cluster.

Netzwerkkonfiguration

Stellen Sie Ihre SQL Server-VMs nach Möglichkeit in mehreren Subnetzen bereit, um die Abhängigkeit von einer Azure Load Balancer-Instanz oder von einem verteilten Netzwerknamen (Distributed Network Name, DNN) zum Routen von Datenverkehr an Ihren Verfügbarkeitsgruppenlistener zu vermeiden.

In einem Azure-VM-Failovercluster wird ein einzelner Netzwerkadapter pro Server (Clusterknoten) empfohlen. Azure-Netzwerktechnologie bietet physische Redundanz, die zusätzliche Netzwerkadapter in einem Azure-VM-Failovercluster überflüssig macht. Obwohl im Clusterprüfbericht die Warnung ausgegeben wird, dass die Knoten nur in einem einzigen Netzwerk erreichbar sind, kann diese Warnung für Azure-VM-Failovercluster einfach ignoriert werden.

Basis-Verfügbarkeitsgruppe

Da die Basis-Verfügbarkeitsgruppe nicht mehr als ein sekundäres Replikat zulässt und kein Lesezugriff auf das sekundäre Replikat besteht, können Sie die Verbindungszeichenfolgen für die Datenbankspiegelung für Basis-Verfügbarkeitsgruppen verwenden. Durch die Verwendung der Verbindungszeichenfolge sind keine Listener erforderlich. Das Entfernen der Listenerabhängigkeit ist für Verfügbarkeitsgruppen auf Azure-VMs hilfreich, da es die Notwendigkeit eines Lastenausgleichs oder das Hinzufügen zusätzlicher IP-Adressen zum Lastenausgleich eliminiert, wenn Sie über mehrere Listener für zusätzliche Datenbanken verfügen.

Wenn Sie z. B. explizit über TCP/IP eine Verbindung mit der Verfügbarkeitsgruppendatenbank „AdventureWorks“ auf „Replica_A“ oder „Replica_B“ einer Basis-Verfügbarkeitsgruppe (oder einer Verfügbarkeitsdatenbank, die nur über ein sekundäres Replikat verfügt und der Lesezugriff im sekundären Replikat nicht zulässig ist) herstellen möchten, kann eine Clientanwendung die folgende Verbindungszeichenfolge für die Datenbankspiegelung angeben, um erfolgreich eine Verbindung mit der Verfügbarkeitsgruppe herzustellen.

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

Bereitstellungsoptionen

Es gibt mehrere Optionen für die Bereitstellung einer Verfügbarkeitsgruppe für SQL Server auf Azure-VMS. Dabei verfügen einige über einen höheren Automatisierungsgrad als andere.

Die folgende Tabelle bietet einen Vergleich der verfügbaren Optionen:

Nächste Schritte

Arbeiten Sie zuerst die bewährten HADR-Methoden durch, und stellen Sie dann Ihre Verfügbarkeitsgruppe wie im Tutorial zu Verfügbarkeitsgruppen beschrieben bereit.

Weitere Informationen finden Sie unter:

• Windows Server-Failovercluster mit SQL Server auf Azure-VMs
• Übersicht über Always On-Verfügbarkeitsgruppen