Failoverclustering und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Artikel
08/27/2013

AlwaysOn-Verfügbarkeitsgruppen, die in SQL Server 2012 eingeführte Lösung für hohe Verfügbarkeit und Notfallwiederherstellung, erfordert WSFC (Windows Server-Failoverclustering). AlwaysOn-Verfügbarkeitsgruppen ist zwar nicht von SQL Server-Failoverclustering abhängig, Sie können aber dennoch eine FCI (Failoverclusterinstanz) verwenden, um ein Verfügbarkeitsreplikat für eine Verfügbarkeitsgruppe zu hosten. Es ist wichtig, dass Sie die Rolle jeder Clusteringtechnologie kennen, und wissen, welche Überlegungen Sie für den Entwurf Ihrer AlwaysOn-Verfügbarkeitsgruppen-Umgebung anstellen müssen.

Hinweis
Weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen-Konzepten finden Sie unter Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

In diesem Thema:

Windows Server-Failoverclustering
SQL Server-Failoverclustering
Einschränkungen bei Verwendung des WSFC-Failovercluster-Managers für Verfügbarkeitsgruppen

Windows Server Failover Clustering und Verfügbarkeitsgruppen

Für die Bereitstellung von AlwaysOn-Verfügbarkeitsgruppen ist ein WSFC-Cluster (Windows Server-Failoverclustering) erforderlich. Um für AlwaysOn-Verfügbarkeitsgruppen aktiviert werden zu können, muss eine Instanz von SQL Server in einem WSFC-Knoten befinden, und der WSFC-Cluster und -Knoten müssen online sein. Zudem muss sich jedes Verfügbarkeitsreplikat einer bestimmten Verfügbarkeitsgruppe in einem anderen Knoten desselben WSFC-Clusters befinden. Die einzige Ausnahme besteht darin, dass sich eine Verfügbarkeitsgruppe während der Migration zu einem anderen WSFC-Cluster vorübergehend auf zwei Cluster erstrecken kann.

AlwaysOn-Verfügbarkeitsgruppen basiert zur Überwachung und Verwaltung der aktuellen Rollen der Verfügbarkeitsreplikate, die zu einer gegebenen Verfügbarkeitsgruppe gehören, auf dem Windows-Failoverclustering (WSFC)-Cluster und bestimmt, wie sich ein Failoverereignis auf die Verfügbarkeitsreplikate auswirkt. Für jede erstellte Verfügbarkeitsgruppe wird eine WSFC-Ressourcengruppe erstellt. Der WSFC-Cluster überwacht diese Ressourcengruppe, um den Zustand des primären Replikats auszuwerten.

Das Quorum für AlwaysOn-Verfügbarkeitsgruppen basiert unabhängig davon, ob ein bestimmter Clusterknoten Verfügbarkeitsreplikate hostet, auf allen Knoten des WSFC-Clusters. Im Gegensatz zur Datenbankspiegelung ist in AlwaysOn-Verfügbarkeitsgruppen keine Zeugenrolle verfügbar.

Die allgemeine Integrität des WSFC-Clusters wird von den Abstimmungen eines Quorums der Clusterknoten bestimmt. Wird der WSFC-Cluster wegen eines nicht geplanten Notfalls oder aufgrund eines persistenten Hardware- oder Kommunikationsfehlers offline geschaltet, ist manueller Eingriff durch den Administrator erforderlich. Ein Windows Server- oder WSFC-Clusteradministrator muss ein Quorum erzwingen und dann die überdauernden Clusterknoten in einer nicht fehlertolerante Konfiguration wieder online schalten.

Wichtig
AlwaysOn-Verfügbarkeitsgruppen-Registrierungsschlüssel sind Unterschlüssel des WSFC-Clusters. Wenn Sie einen WSFC-Cluster löschen und neu erstellen, müssen Sie die Funktion AlwaysOn-Verfügbarkeitsgruppen für jede Instanz von SQL Server deaktivieren und erneut aktivieren, auf der auf dem ursprünglichen WSFC-Cluster ein Verfügbarkeitsreplikat gehostet wurde.

Informationen zum Ausführen von SQL Server auf Windows Server-Failoverclustering (WSFC)-Knoten sowie zum WSFC-Quorum finden Sie unter Windows Server-Failoverclustering (WSFC) mit SQL Server.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Clusterübergreifende Migration von AlwaysOn-Verfügbarkeitsgruppen für Betriebssystemupgrade

Ab SQL Server 2012 SP1 unterstützt AlwaysOn-Verfügbarkeitsgruppen die clusterübergreifende Migration von Verfügbarkeitsgruppen für Bereitstellungen in einem neuen WSFC-Cluster (Windows Server Failover Clustering). Über die clusterübergreifende Migration wird eine Verfügbarkeitsgruppe oder ein Batch von Verfügbarkeitsgruppen bei minimaler Downtime in das neue Ziel-WSFC-Cluster verschoben. Durch das Verfahren der clusterübergreifenden Migration können Sie beim Aktualisieren auf einen Windows Server 2012-Cluster Ihre Vereinbarungen zum Servicelevel (SLAs) einhalten. SQL Server 2012 SP1 (oder eine höhere Version) muss auf dem Ziel-WSFC-Cluster installiert und für AlwaysOn aktiviert sein. Der Erfolg einer clusterübergreifenden Migration hängt von gründlicher Planung und Vorbereitung des Ziel-WSFC-Clusters ab.

Weitere Informationen finden Sie unter Clusterübergreifende Migration von AlwaysOn-Verfügbarkeitsgruppen für Betriebssystemupgrade.

SQL Server-Failoverclusterinstanzen (FCIs) und -Verfügbarkeitsgruppen

Sie können auf Serverinstanzebene eine zweite Failoverebene einrichten, indem Sie das SQL Server-Failoverclustering zusammen mit dem WSFC-Cluster implementieren. Ein Verfügbarkeitsreplikat kann von einer eigenständigen Instanz von SQL Server oder einer FCI-Instanz gehostet werden. Ein Replikat für eine Verfügbarkeitsgruppe kann jeweils nur von einem FCI-Partner gehostet werden. Bei Ausführung eines Verfügbarkeitsreplikats in einer FCI enthält die Liste möglicher Besitzer für die Verfügbarkeitsgruppe nur den aktiven FCI-Knoten.

AlwaysOn-Verfügbarkeitsgruppen hängt von keiner Form eines gemeinsam verwendeten Speichers ab. Falls Sie jedoch eine SQL Server-Failoverclusterinstanz (FCI) zum Hosten von mindestens einem Verfügbarkeitsreplikats verwenden, ist für all diese FCIs der standardmäßigen Installation der SQL Server-Failoverclusterinstanz entsprechend gemeinsam verwendeter Speicher erforderlich.

Weitere Informationen zu zusätzlichen erforderlichen Komponenten finden Sie im Abschnitt "Voraussetzungen und Einschränkungen zum Hosten eines Verfügbarkeitsreplikats mithilfe einer SQL Server-Failoverclusterinstanz (FCI)" von Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Vergleich der Failoverclusterinstanzen und Verfügbarkeitsgruppen

Unabhängig von der Anzahl der Knoten in der FCI hostet eine ganze FCI ein einzelnes Replikat innerhalb einer Verfügbarkeitsgruppe. In der folgenden Tabelle werden die Unterschiede der Konzepte zwischen Knoten in einer FCI und Replikaten in einer Verfügbarkeitsgruppe beschrieben.

	Knoten in einer FCI	Replikate in einer Verfügbarkeitsgruppe
Verwendet WSFC-Cluster	Ja	Ja
Schutzebene	Instanz	Datenbank
Speichertyp	Shared	Nicht freigegeben1
Speicherlösungen	Direkt angefügt, SAN, Einbindungspunkte, SMB	Hängt von Knotentyp ab
Lesbare sekundäre	Nein2	Ja
Anwendbare Failoverrichtlinieneinstellungen	WSFC-Quorum FCI-spezifisch Verfügbarkeitsgruppeneinstellungen3	WSFC-Quorum Verfügbarkeitsgruppeneinstellungen
Failoverressourcen	Server, Instanz und Datenbank	Nur Datenbank

1Obwohl die Replikate in einer Verfügbarkeitsgruppe keinen Speicher gemeinsam verwenden, verwendet ein Replikat, das von einer FCI gehostet wird, gemäß der Anforderung dieser FCI eine gemeinsame Speicherlösung. Die Speicherlösung wird nur von Knoten in dieser FCI verwendet und nicht zwischen den Replikaten der Verfügbarkeitsgruppe.

2Während synchrone sekundäre Replikate in einer Verfügbarkeitsgruppe stets in ihren jeweiligen SQL Server-Instanzen ausgeführt werden, haben Sekundärknoten in einer FCI ihre jeweiligen SQL Server-Instanzen tatsächlich nicht gestartet und sind daher nicht lesbar. In einer FCI startet ein sekundärer Knoten seine SQL Server-Instanz nur, wenn der Ressourcengruppenbesitz während eines FCI-Failovers an ihn übergeben wird. Wenn jedoch auf dem aktiven FCI-Knoten eine FCI-gehostete Datenbank zu einer Verfügbarkeitsgruppe gehört, ist die Datenbank lesbar, wenn das lokale Verfügbarkeitsreplikat als lesbares sekundäres Replikat ausgeführt wird.

3Failoverrichtlinieneinstellungen für die Verfügbarkeitsgruppe gelten für alle Replikate, unabhängig davon, ob sie in einer eigenständigen Instanz oder einer FCI-Instanz gehostet werden.

Hinweis
Weitere Informationen zur Anzahl der Knoten innerhalb des Failoverclusterings sowie zu AlwaysOn-Verfügbarkeitsgruppen für verschiedene SQL Server-Editionen finden Sie unter Von den SQL Server 2012-Editionen unterstützte Funktionen (https://go.microsoft.com/fwlink/?linkid=232473).

Überlegungen zum Hosten eines Verfügbarkeitsreplikats auf einer FCI

Wichtig
Wenn Sie planen, in einer SQL Server-Failoverclusterinstanz (FCI) ein Verfügbarkeitsreplikat zu hosten, stellen Sie sicher, dass die Windows Server 2008-Hostknoten die AlwaysOn-Voraussetzungen und -Einschränkungen für Failoverclusterinstanzen (FCIs) erreichen. Weitere Informationen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Wenn Sie planen, in einer SQL Server-Failoverclusterinstanz (FCI) ein Verfügbarkeitsreplikat zu hosten, stellen Sie sicher, dass die Windows Server 2008-Hostknoten die AlwaysOn-Voraussetzungen und -Einschränkungen für Failoverclusterinstanzen (FCIs) erreichen. Weitere Informationen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

SQL Server-Failoverclusterinstanzen (FCIs) unterstützen kein automatisches AlwaysOn-Failover durch Verfügbarkeitsgruppen. Daher können die Verfügbarkeitsreplikate, die von einer FCI gehostet werden, nur für manuelles Failover konfiguriert werden.

Möglicherweise muss ein Windows Server Failover Clustering (WSFC)-Cluster so konfiguriert werden, dass er freigegebene Datenträger enthält, die nicht auf allen Knoten verfügbar sind. Denken Sie beispielsweise an ein WSFC-Cluster über zwei Datenzentren mit drei Knoten. Zwei der Knoten hosten im primären Rechenzentrum eine SQL Server-Failoverclusteringinstanz (FCI) und haben Zugriff auf dieselben freigegebenen Datenträger. Der dritte Knoten hostet eine eigenständige Instanz von SQL Server in einem anderen Rechenzentrum und verfügt nicht über Zugriff auf die freigegebenen Datenträger vom primären Rechenzentrum. Diese WSFC-Clusterkonfiguration unterstützt die Bereitstellung einer Verfügbarkeitsgruppe, wenn die FCI das primäre Replikat hostet und die eigenständige Instanz das sekundäre Replikat hostet.

Bei Auswahl einer FCI zum Hosten eines Verfügbarkeitsreplikats für eine angegebene Verfügbarkeitsgruppe muss gewährleistet sein, dass ein FCI-Failover nicht möglicherweise bewirkt, dass ein einzelner WSFC-Knoten versucht, zwei Verfügbarkeitsreplikate für dieselbe Verfügbarkeitsgruppe zu hosten.

Im folgenden Beispielszenario wird veranschaulicht, wie diese Konfiguration zu Problemen führen könnte:

Marcel konfiguriert einen WSFC-Cluster mit zwei Knoten, NODE01 und NODE02. Er installiert eine SQL Server-Failoverclusterinstanz, fciInstance1, auf NODE01 und NODE02, wobei NODE01 der aktuelle Besitzer für fciInstance1 ist.
Auf NODE02 installiert Marcel eine andere Instanz von SQL Server, Instance3, die eine eigenständige Instanz ist.
Auf NODE01 aktiviert Marcel fciInstance1 für AlwaysOn-Verfügbarkeitsgruppen. Auf NODE02 aktiviert er Instance3 für AlwaysOn-Verfügbarkeitsgruppen. Dann richtet er eine Verfügbarkeitsgruppe ein, für die fciInstance1 das primäre Replikat hostet, und Instance3 hostet das sekundäre Replikat.
An einen bestimmten Punkt ist fciInstance1 auf NODE01 nicht mehr verfügbar, und der WSFC-Cluster verursacht einen Failover von fciInstance1 auf NODE02. Nach dem Failover ist fciInstance1 eine AlwaysOn-Verfügbarkeitsgruppen-fähige Instanz, die unter der primären Rolle auf NODE02 ausgeführt wird. Instance3 befindet sich jetzt jedoch auf demselben WSFC-Knoten wie fciInstance1. Dies verstößt gegen die AlwaysOn-Verfügbarkeitsgruppen-Einschränkung.

Um das Problem in diesem Szenario zu beheben, muss sich die eigenständige Instanz, Instance3, auf einem anderen Knoten im selben WSFC-Cluster wie NODE01 und NODE02 befinden.

Weitere Informationen zum SQL Server-Failoverclustering finden Sie unter AlwaysOn-Failoverclusterinstanzen (SQL Server).

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Einschränkungen bei Verwendung des WSFC-Failovercluster-Managers für Verfügbarkeitsgruppen

Verwenden Sie den Failovercluster-Manager nicht zum Bearbeiten von Verfügbarkeitsgruppen, beispielsweise:

Fügen Sie im Clusterdienst (Ressourcengruppe) keine Ressourcen für die Verfügbarkeitsgruppe hinzu, bzw. entfernen Sie keine Ressourcen.
Ändern Sie keine Verfügbarkeitsgruppeneigenschaften, z. B. die möglichen und bevorzugten Besitzer. Diese Eigenschaften werden automatisch von der Verfügbarkeitsgruppe festgelegt.
Verwenden Sie den Failovercluster-Manager nicht zum Verschieben von Verfügbarkeitsgruppen auf verschiedene Knoten oder zum Ausführen eines Failovers für Verfügbarkeitsgruppen. Der Synchronisierungsstatus der Verfügbarkeitsreplikate ist dem Failovercluster-Manager nicht bekannt, sodass ein solcher Vorgang die Downtime verlängern kann. Sie müssen Transact-SQL oder SQL Server Management Studio verwenden.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]