Windows Server-Failovercluster mit SQL Server

Gilt für:SQL Server

Dieser Artikel bietet eine Übersicht über die Nutzung eines Windows Server-Failoverclusters (WSFC) mit SQL Server zwecks Hochverfügbarkeit und Notfallwiederherstellung. Beim Windows Server-Failovercluster (WSFC) handelt es sich um eine Gruppe unabhängiger Server, die zur Steigerung der Verfügbarkeit von Anwendungen und Diensten zusammenarbeiten. SQL Server nutzt WSFC-Dienste und -Funktionen, um Always On-Verfügbarkeitsgruppen und SQL Server-Failoverclusterinstanzen zu unterstützen.

Begriffe und Definitionen

Beim Windows Server-Failovercluster (WSFC) handelt es sich um eine Gruppe unabhängiger Server, die zur Steigerung der Verfügbarkeit von Anwendungen und Diensten zusammenarbeiten.

Node
Ein Server, der an einem WSFC teilnimmt.

Cluster-Ressource
Eine physische oder logische Entität, die im Besitz eines Knotens sein, online und offline geschaltet, zwischen Knoten verschoben und als Clusterobjekt verwaltet werden kann. Eine Clusterressource kann jeweils nur im Besitz eines einzelnen Knotens sein.

Rolle
Eine Sammlung von Clusterressourcen, die als einzelnes Clusterobjekt verwaltet werden, um besondere Funktionen bereitzustellen. Bei SQL Server ist eine Rolle entweder eine Always On-Verfügbarkeitsgruppe (AG) oder eine Always On-Failoverclusterinstanz (FCI). Eine Rolle enthält sämtliche Clusterressourcen, die für AG und FCI benötigt werden. Failover und Failback erfolgen immer im Kontext von Rollen. Für eine FCI enthält die Rolle eine IP-Adressressource, eine Netzwerknamensressource und die SQL Server-Ressourcen. Eine AG-Rolle enthält die AG-Ressource und, falls ein Listener konfiguriert ist, einen Netzwerknamen und eine IP-Ressource.

Netzwerknamenressource
Ein logischer Servername, der als Clusterressource verwaltet wird. Eine Netzwerknamenressource muss mit einer IP-Adressressource verwendet werden. Für diese Einträge sind möglicherweise Objekte in Active Directory Domain Services und/oder DNS erforderlich.

Ressourcenabhängigkeit
Eine Ressource, von der eine andere Ressource abhängt. Wenn Ressource A von Ressource B abhängig ist, stellt B eine Abhängigkeit von A dar, und Ressource A kann nicht ohne Ressource B gestartet werden.

Bevorzugter Besitzer
Ein Knoten, auf dem eine Ressourcengruppe bevorzugt ausgeführt wird. Jede Ressourcengruppe ist einer Liste von bevorzugten Besitzern zugeordnet, die nach Präferenz sortiert ist. Bei einem automatischen Failover wird die Ressourcengruppe auf den nächsten bevorzugten Knoten in der Liste der bevorzugten Besitzer verschoben.

Möglicher Besitzer
Ein sekundärer Knoten, auf dem eine Ressource ausgeführt werden kann. Jede Ressourcengruppe ist einer Liste von möglichen Besitzern zugeordnet. Rollen können nur ein Failover zu Knoten ausführen, die als mögliche Besitzer aufgeführt sind.

Quorum-Modus
Die Quorumkonfiguration in einem Failovercluster, die die Anzahl von Knotenfehlern bestimmt, die der Cluster tolerieren kann.

Quorum erzwingen
Der Prozess zum Starten des Clusters, auch wenn nur eine Minderheit der für ein Quorum erforderlichen Elemente kommuniziert.

Übersicht über Windows Server-Failoverclustering

Windows Server-Failoverclustering stellt Infrastrukturfunktionen bereit, die Szenarien mit hoher Verfügbarkeit und Notfallwiederherstellung für gehostete Serveranwendungen, z. B. Microsoft SQL Server und Microsoft Exchange, unterstützen. Wenn ein Clusterknoten oder -dienst fehlschlägt, können die auf diesem Knoten gehosteten Dienste automatisch oder manuell auf einen anderen verfügbaren Knoten übertragen werden. Dieser Prozess wird als Failoverbezeichnet.

Die Knoten in einem WSFC arbeiten zusammen, um diese Arten von Funktionen bereitzustellen:

  • Verteilte Metadaten und Benachrichtigungen. Metadaten des WSFC-Diensts und gehosteter Anwendungen sind in jedem Knoten im Cluster enthalten. Diese Metadaten enthalten WSFC-Konfiguration und -Status sowie Einstellungen der gehosteten Anwendung. Änderungen an den Metadaten oder am Status eines Knotens werden automatisch an die anderen Knoten im WSFC weitergegeben.

  • Ressourcenverwaltung. Einzelne Knoten im WSFC stellen möglicherweise physische Ressourcen bereit, z. B. direkt angeschlossenen Speicher, Netzwerkschnittstellen und Zugriff auf gemeinsam genutzten Festplattenspeicher. Gehostete Anwendungen registrieren sich selbst als Clusterressource und können Start- und Zustandsabhängigkeiten gegenüber anderen Ressourcen konfigurieren.

  • Zustandsüberwachung. Die Zustandsüberwachung der Knoten untereinander und des primären Knotens erfolgt durch eine Kombination aus Heartbeat-Netzwerkkommunikation und Ressourcenüberwachung. Der Gesamtzustand des WSFC wird durch die Stimmen eines Knotenquorums im WSFC bestimmt.

  • Koordination des Failovers. Jede Ressource wird zum Hosten auf einem primären Knoten konfiguriert und kann automatisch oder manuell an mindestens einen sekundären Knoten übertragen werden. Eine zustandsbasierte Failoverrichtlinie steuert die automatische Übertragung des Besitzes von Ressourcen zwischen Knoten. Knoten und gehostete Anwendungen werden benachrichtigt, wenn ein Failover erfolgt, damit sie entsprechend reagieren können.

Weitere Informationen finden Sie unter Failoverclustering: Übersicht – Windows Server.

SQL Server Always On-Technologien und WSFC

SQL Server Always On ist eine Lösung für Hochverfügbarkeit und Notfallwiederherstellung, die WSFC nutzt. Always On-Komponenten stellen eine integrierte, flexible Lösung bereit, die die Anwendungsverfügbarkeit erhöht, einen höheren Ertrag bei Hardwareinvestitionen bietet und die Bereitstellung und Verwaltung von Hochverfügbarkeit vereinfacht.

Sowohl Always On-Verfügbarkeitsgruppen als auch Always On-Failoverclusterinstanzen nutzen WSFC als Plattformtechnologie und registrieren Komponenten als WSFC-Clusterressourcen. Verwandte Ressourcen werden in einer Rolle kombiniert, für die Abhängigkeiten von anderen WSFC-Clusterressourcen festgelegt werden können. Der WSFC-Clusterdienst kann dann die Notwendigkeit eines Neustarts der SQL Server-Instanz ermitteln und signalisieren oder automatisch ein Failover zu einem anderen Serverknoten im WSFC-Cluster ausführen.

Wichtig

Um die SQL Server Always On-Technologien voll ausnützen zu können, sollten Sie verschiedene WSFC-bezogene Voraussetzungen erfüllen.

Weitere Informationen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für Always On-Verfügbarkeitsgruppen.

Hohe Verfügbarkeit auf Instanzebene mit Always On-Failoverclusterinstanzen

Eine Always On-Failoverclusterinstanz (FCI) ist eine SQL Server-Instanz, die über Knoten in einem WSFC hinweg installiert ist. Dieser Typ der Instanz hängt von Ressourcen für Speicher und für den virtuellen Netzwerknamen ab. Der Speicher kann Fibre Channel, iSCSI, FCoE oder SAS für gemeinsam genutzten Datenträgerspeicher verwenden oder lokal angebundenen Speicher mit Direkte Speicherplätze (S2D) nutzen. Die Ressource des virtuellen Netzwerknamens hängt von mindestens einer virtuellen IP-Adresse in jeweils unterschiedlichen Subnetzen ab. Der SQL Server-Dienst und der SQL Server-Agent-Dienst sind ebenfalls Ressourcen und von den Ressourcen des Speichers und des virtuellen Netzwerknamens abhängig.

Im Falle eines Failovers überträgt der WSFC-Dienst die Besitzrechte an den Ressourcen der Instanz auf einen festgelegten Failoverknoten. Die SQL Server-Instanz wird dann auf dem Failoverknoten neu gestartet, und Datenbanken werden wie gewohnt wiederhergestellt. Nur jeweils ein einzelner Knoten im Cluster kann die FCI und zugrunde liegende Ressourcen hosten.

Hinweis

Eine Always On-Failoverclusterinstanz erfordert symmetrischen gemeinsam genutzten Datenträgerspeicher, z. B. ein Storage Area Network (SAN) oder eine SMB-Dateifreigabe. Die freigegebenen Festplattenspeichervolumes müssen für alle potenziellen Failoverknoten im WSFC-Cluster verfügbar sein.

Weitere Informationen finden Sie unter Always On-Failoverclusterinstanzen.

Hohe Verfügbarkeit auf Datenbankebene mit Always On-Verfügbarkeitsgruppen

Eine Always On-Verfügbarkeitsgruppe (AG) besteht aus einer oder mehreren Benutzerdatenbanken, deren Failover gemeinsam erfolgt. Eine Verfügbarkeitsgruppe besteht aus einem primären Verfügbarkeitsreplikat und einem bis vier sekundären Replikaten, die mittels protokollbasierter SQL Server-Datenverschiebung verwaltet werden, um den Datenschutz ohne freigegebenen Speicher zu gewährleisten. Jedes Replikat wird von einer Instanz von SQL Server auf einem anderen Knoten des WSFC gehostet. Die Verfügbarkeitsgruppe und ein entsprechender virtueller Netzwerkname werden als Ressourcen im WSFC-Cluster registriert.

Ein Verfügbarkeitsgruppenlistener im Knoten des primären Replikats reagiert auf eingehende Clientanforderungen zum Herstellen einer Verbindung mit dem virtuellen Netzwerknamen. Auf Grundlage von Attributen in der Verbindungszeichenfolge wird jede Anforderung an die entsprechende SQL Server -Instanz umgeleitet.

Statt im Fall eines Failovers den Besitz von freigegebenen physischen Ressourcen an einen anderen Knoten zu übertragen, wird WSFC dazu genutzt, ein sekundäres Replikat auf einer anderen SQL Server-Instanz neu zu konfigurieren, sodass es zum primären Replikat der Verfügbarkeitsgruppe wird. Die virtuelle Netzwerknamenressource der Verfügbarkeitsgruppe wird dann auf diese Instanz übertragen.

Nur eine einzelne SQL Server-Instanz kann jeweils das primäre Replikat der Datenbanken einer Verfügbarkeitsgruppe hosten. Alle zugeordneten sekundären Replikate müssen sich jeweils auf separaten Instanzen und die einzelnen Instanzen auf unterschiedlichen physischen Knoten befinden.

Hinweis

Always On-Verfügbarkeitsgruppen erfordern weder die Bereitstellung einer Failovercluster-Instanz noch die Verwendung von symmetrischem gemeinsam genutztem Speicher (SAN oder SMB).

Eine Failoverclusterinstanz (FCI) kann zusammen mit einer Verfügbarkeitsgruppe verwendet werden, um die Verfügbarkeit eines Verfügbarkeitsreplikats zu verbessern. Jedoch wird zur Vermeidung potenzieller Race Conditions im WSFC-Cluster das automatische Failover der Verfügbarkeitsgruppe zu oder von einem Verfügbarkeitsreplikat, das auf einer FCI gehostet wird, nicht unterstützt.

Weitere Informationen finden Sie unter Übersicht über Always On-Verfügbarkeitsgruppen.

WSFC-Systemüberwachung und -Failover

Die Hochverfügbarkeit für eine Always On-Lösung wird durch die proaktive Integritätsüberwachung physischer und logischer WSFC-Clusterressourcen sowie durch automatisches Failover auf redundante Hardware und deren Neukonfiguration erreicht. Ein Systemadministrator kann außerdem ein manuelles Failover einer Verfügbarkeitsgruppe oder SQL Server -Instanz von einem Knoten zum anderen initiieren.

Failoverrichtlinien für Knoten, Failoverclusterinstanzen und Verfügbarkeitsgruppen

Eine Failoverrichtlinie wird auf Ebene des WSFC-Knotens, der SQL Server-Failoverclusterinstanz (FCI) und der Verfügbarkeitsgruppe konfiguriert. Diese Richtlinien können auf Grundlage des Schweregrads, der Dauer und Häufigkeit eines fehlerhaften Clusterressourcenstatus und eines fehlerhaften Knotenreaktionsverhaltens einen Dienstneustart oder ein automatisches Failover von Clusterressourcen von einem Knoten zum anderen auslösen. Außerdem kann die Verschiebung eines primären Verfügbarkeitsgruppenreplikats von einer SQL Server -Instanz zu einer anderen ausgelöst werden.

Das Failover eines Verfügbarkeitsgruppenreplikats wirkt sich nicht auf die zugrunde liegende SQL Server-Instanz aus. Bei einem Failover einer FCI werden die gehosteten Verfügbarkeitsgruppenreplikate mit der Instanz verschoben.

Weitere Informationen finden Sie unter Failoverrichtlinie für Failoverclusterinstanzen.

Erkennung des WSFC-Ressourcenzustands

Jede Ressource in einem WSFC kann regelmäßig oder bei Bedarf ihren Status und Zustand melden. Verschiedene Umstände deuten möglicherweise auf Ressourcenfehler hin, zum Beispiel Stromausfall, Datenträger- oder Arbeitsspeicherfehler, Netzwerkkommunikationsfehler oder nicht reagierende Dienste.

WSFC-Ressourcen wie Netzwerke, Speicher oder Dienste können so konfiguriert werden, dass sie voneinander abhängig sind. Der Gesamtzustand einer Ressource wird bestimmt, indem ihr Zustand schrittweise mit dem Zustand jeder ihrer Ressourcenabhängigkeiten aggregiert wird.

WSFC-Interknoten-Zustandserkennung und Quorumabstimmung

Jeder Knoten in einem WSFC nimmt an regelmäßiger Heartbeat-Kommunikation teil, um den Zustand des Knotens mit den anderen Knoten zu teilen. Bei nicht reagierenden Knoten wird der Status als fehlerhaft betrachtet.

Bei einem Quorum handelt es sich um einen Mechanismus, mit dessen Hilfe gewährleistet werden soll, dass der WSFC funktioniert, indem es sicherstellt, dass im WSFC genügend Ressourcen online sind. Wenn der WSFC über genügend Stimmen verfügt, ist er funktionsfähig und kann Fehlertoleranz auf Knotenebene bieten.

Der Quorummodus wird im WSFC konfiguriert, der die Methodik für die Quorumabstimmung vorgibt und bestimmt, wann ein automatisches Failover ausgeführt oder der Cluster offline geschaltet wird.

Tipp

Es ist eine Best Practice, immer über eine ungerade Anzahl an Quorumstimmen in einem WSFC zu verfügen. Für den Zweck der Quorumabstimmung muss SQL Server nicht auf allen Knoten im Cluster installiert sein. Ein zusätzlicher Server kann als Quorumelement dienen. Alternativ kann das WSFC-Quorummodell zur Verwendung einer Remotedateifreigabe als Tiebreaker konfiguriert werden.

Weitere Informationen finden Sie unter : WSFC Quorum-Modi und Abstimmungskonfiguration.

Notfallwiederherstellung durch Erzwingen des Quorums

Abhängig vom Betriebsverfahren und von der WSFC-Konfiguration können Sie sowohl automatische als auch manuelle Failovers auslösen und dennoch eine stabile, fehlertolerante SQL Server-Always On-Lösung betreiben. Wenn jedoch ein Quorum der stimmberechtigten Knoten im WSFC nicht miteinander kommunizieren kann oder der WSFC-Cluster die Integritätsprüfung aus einem anderen Grund nicht besteht, könnte der WSFC offline gehen.

Wird der WSFC wegen eines nicht geplanten Notfalls oder aufgrund eines persistenten Hardware- oder Kommunikationsfehlers offline geschaltet, ist manueller Eingriff durch den Administrator erforderlich, um ein Quorum zu erzwingen und die überdauernden Clusterknoten in einer nicht fehlertoleranten Konfiguration wieder online zu schalten.

Danach müssen außerdem einige Schritte ausgeführt werden, um den WSFC neu zu konfigurieren, die betroffenen Datenbankreplikate wiederherzustellen und ein neues Quorum einzurichten.

Weitere Informationen finden Sie unter : WSFC Disaster Recovery durch erzwungenes Quorum.

Beziehung der Always On-Komponenten in SQL Server mit WSFC

Zwischen den Funktionen und Komponenten von SQL Server Always On und WSFC liegen verschiedene Beziehungsstufen vor.

Always On-Verfügbarkeitsgruppen werden auf SQL Server -Instanzen gehostet.
Eine Clientanforderung, in der zum Herstellen einer Verbindung mit einer primären oder sekundären Datenbank ein logischer Netzwerkname für einen Verfügbarkeitsgruppenlistener angegeben wird, wird an den entsprechenden Netzwerknamen der zugrunde liegenden SQL Server-Instanz oder SQL Server-FCI umgeleitet.

SQL Server-Instanzen werden aktiv in einem einzelnen Knoten gehostet.
Eine eigenständige SQL Server -Instanz (sofern vorhanden) befindet sich immer in einem einzelnen Knoten mit einem statischen Instanznetzwerknamen. Eine SQL Server -Failoverclusterinstanz (sofern vorhanden) ist für einen von mindestens zwei möglichen Failoverknoten mit einem virtuellen Instanznetzwerknamen aktiv.

Knoten sind Mitglieder eines WSFC-Clusters.
Metadaten und Status der WSFC-Konfiguration für alle Knoten werden in jedem Knoten gespeichert. Jeder Server kann asymmetrischen Speicher oder freigegebene Speichervolumes (SAN) für Benutzer- oder Systemdatenbanken bereitstellen. Jeder Server besitzt mindestens eine physische Netzwerkschnittstelle in mindestens einem IP-Subnetz.

Der WSFC überwacht die Integrität und verwaltet die Konfiguration für mehrere Server.
Die WSFC-Mechanismen geben Änderungen an den WSFC-Konfigurationsmetadaten und am Status an alle Knoten im WSFC weiter. Wenn ein Witnessdatenträger verwendet wird, werden die Metadaten ebenfalls dort gespeichert. Standardmäßig erhält jeder Knoten des WSFC eine Stimme für das Quorum, und ein Witnesselement wird falls erforderlich verwendet, sofern es konfiguriert ist.

Registrierungsschlüssel für Always On-Verfügbarkeitsgruppen sind Unterschlüssel des WSFC-Clusters.

Wenn Sie einen WSFC löschen und anschließend neu erstellen, müssen Sie die Funktion Always On-Verfügbarkeitsgruppen auf jeder Serverinstanz, die auf dem ursprünglichen WSFC für Always On-Verfügbarkeitsgruppen aktiviert war, deaktivieren und erneut aktivieren. Weitere Informationen finden Sie unter "Aktivieren und Deaktivieren von AlwaysOn-Verfügbarkeitsgruppen".

Screenshot des Windows Server-Failoverclusters.

Zugehörige Aufgaben

Zugehöriger Inhalt

  • Last updated on