Failover-Clustering und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Always On Availability Groups, die in SQL Server 2014 eingeführte Lösung für hohe Verfügbarkeit und Notfallwiederherstellung, erfordert Windows Server-Failoverclustering (WSFC). Auch wenn AlwaysOn-Verfügbarkeitsgruppen nicht von SQL Server-Failoverclustering abhängig sind, können Sie eine Failoverclusteringinstanz (FCI) verwenden, um ein Verfügbarkeitsreplikat für eine Verfügbarkeitsgruppe zu hosten. Es ist wichtig, die Rolle jeder Clusteringtechnologie zu kennen und zu wissen, welche Überlegungen erforderlich sind, wenn Sie Ihre AlwaysOn-Verfügbarkeitsgruppenumgebung entwerfen.

Hinweis

Informationen zu AlwaysOn-Verfügbarkeitsgruppen-Konzepten finden Sie in der Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Windows Server Failover Clustering und Verfügbarkeitsgruppen

Für die Bereitstellung von AlwaysOn-Verfügbarkeitsgruppen ist ein Windows Server-Failoverclustering (WSFC)-Cluster erforderlich. Um für Always On-Verfügbarkeitsgruppen aktiviert zu werden, muss sich eine Sql Server-Instanz auf einem WSFC-Knoten befinden, und der WSFC-Cluster und -Knoten müssen online sein. Darüber hinaus muss sich jedes Verfügbarkeitsreplikat einer bestimmten Verfügbarkeitsgruppe auf 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.

Always On Availability Groups basiert auf dem Windows Failover Clustering (WSFC)-Cluster, um die aktuellen Rollen der Verfügbarkeitsreplikate zu überwachen und zu verwalten, die zu einer bestimmten Verfügbarkeitsgruppe gehören, und um zu bestimmen, 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 Status des primären Replikats auszuwerten.

Das Quorum für Always On-Verfügbarkeitsgruppen basiert auf allen Knoten im WSFC-Cluster, unabhängig davon, ob ein bestimmter Clusterknoten Verfügbarkeitsreplikate hostet. Im Gegensatz zur Datenbankspiegelung gibt es in AlwaysOn-Verfügbarkeitsgruppen keine Zeugenrolle.

Der Gesamtzustand eines WSFC-Clusters wird durch die Stimmen des Quorums der Knoten im Cluster bestimmt. Wenn der WSFC-Cluster aufgrund eines ungeplanten Notfalls oder aufgrund eines dauerhaften Hardware- oder Kommunikationsfehlers offline wird, ist ein manueller Administratoreingriff erforderlich. Ein Windows Server- oder WSFC-Clusteradministrator muss ein Quorum erzwingen und dann die überlebenden Clusterknoten in einer nicht fehlertoleranten Konfiguration wieder online schalten.

Von Bedeutung

Registrierungsschlüssel für Always On Availability Groups sind Unterschlüssel des WSFC-Clusters. Wenn Sie einen WSFC-Cluster löschen und erneut erstellen, müssen Sie das Feature "AlwaysOn-Verfügbarkeitsgruppen" für jede Instanz von SQL Server deaktivieren und erneut aktivieren, die ein Verfügbarkeitsreplikat im ursprünglichen WSFC-Cluster gehostet hat.

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

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

Ab SQL Server 2012 SP1 unterstützt AlwaysOn-Verfügbarkeitsgruppen die clusterübergreifende Migration von Verfügbarkeitsgruppen für Bereitstellungen zu einem neuen Windows Server-Failoverclustering(WSFC)-Cluster. Eine clusterübergreifende Migration verschiebt eine Verfügbarkeitsgruppe oder eine Reihe von Verfügbarkeitsgruppen in den neuen WSFC-Zielcluster mit minimalen Ausfallzeiten. Mit dem clusterübergreifenden Migrationsprozess können Sie beim Upgrade auf einen Windows Server 2012-Cluster Ihre Service Level Agreements (SLAs) einhalten. SQL Server 2012 SP1 (oder eine höhere Version) muss für AlwaysOn auf dem WSFC-Zielcluster installiert und aktiviert werden. Der Erfolg einer clusterübergreifenden Migration hängt von der gründlichen Planung und Vorbereitung des Ziel-WSFC-Clusters ab.

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

SQL Server Failoverclusterinstanzen (FCIs) und Verfügbarkeitsgruppen

Sie können eine zweite Failoverebene auf Serverinstanzebene einrichten, indem Sie 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.

Always On Availability Groups sind unabhängig von jeder Form von gemeinsam genutztem Speicher. 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 Voraussetzungen finden Sie im Abschnitt "Voraussetzungen und Einschränkungen für die Verwendung einer SQL Server-Failoverclusterinstanz (FCI) zum Hosten eines Verfügbarkeitsreplikats" in den Abschnitten "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	Beispiel	Datenbank
Speichertyp	Geteilt	Nicht freigegeben Beachten Sie, dass während die Replikate in einer Verfügbarkeitsgruppe keinen Speicher gemeinsam nutzen, verwendet ein Replikat, das von einer FCI gehostet wird, eine freigegebene Speicherlösung, die von diesem FCI benötigt wird. Die Speicherlösung wird nur von Knoten in dieser FCI verwendet und nicht zwischen den Replikaten der Verfügbarkeitsgruppe.
Speicherlösungen	Direkt angefügt, SAN, Einbindungspunkte, SMB	Hängt von Knotentyp ab
Lesbare sekundäre Replikate	Nein*	Ja
Anwendbare Failoverrichtlinieneinstellungen	WSFC-Quorum FCI-spezifisch Verfügbarkeitsgruppeneinstellungen**	WSFC-Quorum Einstellungen der Verfügbarkeitsgruppe
Failoverressourcen	Server, Instanz und Datenbank	Nur Datenbank

*Wä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.

**Failoverrichtlinieneinstellungen 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 von Failoverclustering- und AlwaysOn-Verfügbarkeitsgruppen für verschiedene Editionen von SQL Server finden Sie unter Features, die von den Editionen von SQL Server 2012 (https://go.microsoft.com/fwlink/?linkid=232473) unterstützt werden.

Überlegungen zum Hosten eines Verfügbarkeitsreplikats auf einer FCI

Von Bedeutung

Wenn Sie beabsichtigen, ein Verfügbarkeitsreplikat auf einer SQL Server-Failoverclusterinstanz (FCI) zu hosten, stellen Sie sicher, dass die Windows Server 2008-Hostknoten die AlwaysOn-Voraussetzungen und -Einschränkungen für Failoverclusterinstanzen (FCIs) erfüllen. 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 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 müssen Sie einen Windows Server Failover Clustering (WSFC)-Cluster so konfigurieren, dass er freigegebene Datenträger umfasst, die nicht auf allen Knoten verfügbar sind. Betrachten Sie beispielsweise einen WSFC-Cluster über zwei Rechenzentren mit drei Knoten. Zwei der Knoten hosten eine SQL Server-Failoverclustering-Instanz (FCI) im primären Rechenzentrum und haben Zugriff auf dieselben gemeinsam genutzten Festplatten. 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 zwei 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 fciInstance1ist.
Auf NODE02installiert Marcel eine andere Instanz von SQL Server, Instance3, die eine eigenständige Instanz ist.
On NODE01, Marcel aktiviert fciInstance1 für Always On-Verfügbarkeitsgruppen. Am NODE02 aktiviert er Instance3 für Always On-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.
Irgendwann wird fciInstance1 auf NODE01 nicht mehr verfügbar, und der WSFC-Cluster verursacht ein Failover von fciInstance1 zu NODE02. Nach dem Failover ist fciInstance1 eine Always On-Verfügbarkeitsgruppen aktivierte 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 Anforderung "Always On Availability Groups".
Um das Problem, das dieses Szenario darstellt, zu beheben, muss die eigenständige Instanz Instance3 sich wie NODE01 und NODE02 auf einem anderen Knoten im selben WSFC-Cluster befinden.

Weitere Informationen zum SQL-Server-Failover-Clustering finden Sie unter AlwaysOn-Failover-Clusterinstanzen (SQL Server).

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.

Siehe auch

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)Aktivieren und Deaktivieren von AlwaysOn-Verfügbarkeitsgruppen (SQL Server)Überwachen von Verfügbarkeitsgruppen (Transact-SQL)
AlwaysOn-Failover-Clusterinstanzen (SQL Server)

Last updated on 2017-06-13

Freigeben über