Failoverclustering und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Artikel
04/26/2023

Gilt für: SQL Server – nur Windows

Always On-Verfügbarkeitsgruppen, die in SQL Server 2012 (11.x) eingeführte Lösung für Hochverfügbarkeit und Notfallwiederherstellung, erfordert WSFC (Windows Server-Failoverclustering). Always On-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 Always On-Verfügbarkeitsgruppen -Umgebung anstellen müssen.

Hinweis

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

Windows Server Failover Clustering und Verfügbarkeitsgruppen

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

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

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

Die allgemeine Integrität des WSFC wird von den Abstimmungen eines Quorums der Clusterknoten bestimmt. Wird der WSFC 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-Administrator muss ein Quorum erzwingen und dann die überdauernden Clusterknoten in einer nicht fehlertoleranten Konfiguration wieder online schalten.

Wichtig

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

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

SQL Server Failoverclusterinstanzen (FCIs) und Verfügbarkeitsgruppen

Sie können auf Serverinstanzebene eine zweite Failoverebene einrichten, indem Sie SQL Server und FCI zusammen mit dem WSFC 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 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)“ des Artikels Voraussetzungen, Einschränkungen und Empfehlungen für Always On-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	Ja	Ja
Schutzebene	Instanz	Datenbank
Speichertyp	Shared	Nicht freigegeben 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 FCIs sowie zu Always On-Verfügbarkeitsgruppen für verschiedene SQL Server-Editionen finden Sie unter Von den SQL Server 2012-Editionen unterstützte Features (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 Always On-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 WSFC so konfiguriert werden, dass er freigegebene Datenträger enthält, die nicht auf allen Knoten verfügbar sind. Denken Sie beispielsweise an ein WSFC über zwei Rechenzentren mit drei Knoten. Zwei der Knoten hosten im primären Rechenzentrum eine SQL Server-Failoverclusterinstanz (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-Konfiguration 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 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 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.
An einen bestimmten Punkt ist fciInstance1 auf NODE01nicht mehr verfügbar, und der WSFC verursacht einen Failover von fciInstance1 auf NODE02. Nach dem Failover ist fciInstance1 eine Always On-Verfügbarkeitsgruppen-fähige Instanz, 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ü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 wie NODE01 und NODE02befinden.

Weitere Informationen zu SQL Server-FCIs finden Sie unter Always On-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.

Warnung

Die Verwendung des Failovercluster-Managers zum Verschieben einer Failoverclusterinstanz, die eine Verfügbarkeitsgruppe hostet, auf einen Knoten, der bereits ein Replikat derselben Verfügbarkeitsgruppe hostet, kann zum Verlust des Verfügbarkeitsgruppenreplikats führen, sodass dieses auf dem Zielknoten nicht online geschaltet werden kann. Ein einzelner Knoten eines Failoverclusters kann nicht mehr als ein Replikat für dieselbe Verfügbarkeitsgruppe hosten. Weitere Informationen dazu, wie eine solche Situation eintritt und wie sie gelöst werden kann, finden Sie im Blog Replikat in Verfügbarkeitsgruppe unerwartet gelöscht.

Weitere Informationen

Übersicht über Always On-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