Failoverclustering und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Artikel
06/13/2017

Always On Verfügbarkeitsgruppen, die in SQL Server 2014 eingeführte Lösung für Hochverfügbarkeit und Notfallwiederherstellung, erfordert Windows Server Failover Clustering (WSFC). Auch wenn Always On Verfügbarkeitsgruppen nicht von SQL Server Failoverclustering abhängig sind, können Sie ein Failoverclustering instance (FCI) verwenden, um ein Verfügbarkeitsreplikat für eine Verfügbarkeitsgruppe zu hosten. Es ist wichtig, die Rolle der einzelnen Clustertechnologien zu kennen und zu wissen, welche Überlegungen beim Entwerfen Ihrer Always On Verfügbarkeitsgruppenumgebung erforderlich sind.

Hinweis

Informationen zu Always On Konzepten von Verfügbarkeitsgruppen finden Sie unter Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Windows Server Failover Clustering und Verfügbarkeitsgruppen

Für die Bereitstellung Always On Verfügbarkeitsgruppen ist ein WSFC-Cluster (Windows Server Failover Clustering) erforderlich. Um für Always On Verfügbarkeitsgruppen aktiviert zu werden, muss sich ein instance von SQL Server auf 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.

Always On Verfügbarkeitsgruppen sind vom WSFC-Cluster (Windows Failover Clustering) abhängig, 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 Zustand 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 keine Zeugenrolle in Always On Verfügbarkeitsgruppen.

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

Always On Verfügbarkeitsgruppenregistrierungsschlüssel sind Unterschlüssel des WSFC-Clusters. Wenn Sie einen WSFC-Cluster löschen und neu erstellen, müssen Sie das Feature Always On Verfügbarkeitsgruppen auf jedem instance von SQL Server deaktivieren und erneut aktivieren, der ein Verfügbarkeitsreplikat im ursprünglichen WSFC-Cluster gehostet hat.

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

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

Ab SQL Server 2012 SP1 unterstützt Always On Verfügbarkeitsgruppen die clusterübergreifende Migration von Verfügbarkeitsgruppen für Bereitstellungen zu 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 Kreuzclustermigration 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 für AlwaysOn auf dem WSFC-Zielcluster installiert und aktiviert sein. Der Erfolg einer Kreuzclustermigration 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 eine zweite Failoverebene auf server-instance Ebene 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 Verfügbarkeitsgruppen sind nicht von einer Form von freigegebenem Speicher abhängig. 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" unter 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 freigegeben Beachten Sie Folgendes: Obwohl 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.
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 Supported by the Editions of SQL Server 2012 (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).

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 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 fciInstance1ist.
Auf NODE02installiert Marcel eine andere Instanz von SQL Server, Instance3, die eine eigenständige Instanz ist.
Auf NODE01aktiviert Marcel fciInstance1 für Always On Verfügbarkeitsgruppen. Auf NODE02aktiviert Instance3 er 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.
An einen bestimmten Punkt ist fciInstance1 auf NODE01nicht mehr verfügbar, und der WSFC-Cluster verursacht einen Failover von fciInstance1 auf NODE02. Nach dem Failover fciInstance1 ist eine Always On Verfügbarkeitsgruppen-aktivierte instance, die unter der primären Rolle auf NODE02ausgeführt wird. Instance3 befindet sich jetzt jedoch auf demselben WSFC-Knoten wie fciInstance1. Dies verstößt gegen die Always On-Verfügbarkeitsgruppeneinschrä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 NODE02befinden.

Weitere Informationen zum SQL Server Failoverclustering finden Sie unter AlwaysOn-Failoverclusterinstanzen (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.

Weitere Informationen

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

Freigeben über