Failoverclustering- und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

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). 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 Always On-Verfügbarkeitsgruppenkonzepten finden Sie unter Was ist eine AlwaysOn-Verfügbarkeitsgruppe?

Windows Server-Failoverclustering- 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. Anders als bei der 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 und zum WSFC-Quorum finden Sie unter Windows Server-Failoverclustering 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. Entweder eine eigenständige Instanz von SQL Server oder eine FCI-Instanz kann ein Verfügbarkeitsreplikat hosten. 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ängen nicht von einer Form des freigegebenen 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 Voraussetzungen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für Always On-Verfügbarkeitsgruppen (SQL Server).For more information about additional prerequisites, see Prerequisites, restrictions, and recommendations for Always On availability groups (SQL Server)

Vergleich von 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 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 immer auf ihren jeweiligen SQL Server-Instanzen ausgeführt werden, haben sekundäre Knoten in einer FCI tatsächlich ihre jeweiligen SQL Server-Instanzen 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 wird.

Überlegungen zum Hosten eines Verfügbarkeitsreplikats in einem FCI

Wichtig

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 Always On-Verfügbarkeitsgruppen (SQL Server).

SQL Server-Failoverclusterinstanzen (FCIs) unterstützen kein automatisches Failover durch Verfügbarkeitsgruppen, sodass jedes Verfügbarkeitsreplikat, das ein FCI-Hosts nur für manuelles Failover konfiguriert werden kann.

Möglicherweise müssen Sie einen WSFC so konfigurieren, dass freigegebene Datenträger enthalten sind, die nicht auf allen Knoten verfügbar sind. Denken Sie beispielsweise an ein WSFC über zwei Rechenzentren mit drei Knoten. Zwei der Knoten hosten einen SQL Server-FCI im primären Rechenzentrum und haben Zugriff auf dieselben gemeinsam genutzten Datenträger. Der dritte Knoten hostet eine eigenständige Instanz von SQL Server in einem anderen Rechenzentrum und hat keinen Zugriff auf die freigegebenen Datenträger aus dem 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.

Stellen Sie beim Auswählen eines FCI zum Hosten eines Verfügbarkeitsreplikats für eine bestimmte Verfügbarkeitsgruppe sicher, dass ein FCI-Failover einen einzelnen WSFC-Knoten nicht dazu führen konnte, zwei Verfügbarkeitsreplikate für dieselbe Verfügbarkeitsgruppe zu hosten.

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

• Sie konfigurieren einen WSFC mit zwei Knoten, NODE01 und NODE02.
• Sie installieren eine SQL Server-Failoverclusterinstanz, fciInstance1, sowohl für NODE01 als auch für NODE02, wobei NODE01 der aktuelle Besitzer für fciInstance1ist.
• Auf NODE02, installieren Sie eine andere Instanz von SQL Server, Instance3die eine eigenständige Instanz ist.
• Bei NODE01 aktivieren Sie fciInstance1 für Always On-Verfügbarkeitsgruppen. Bei NODE02 aktivieren Sie Instance3 für Always On-Verfügbarkeitsgruppen. Anschließend richten Sie eine Verfügbarkeitsgruppe ein, für die fciInstance1 das primäre Replikat hostet, und Instance3 das sekundäre Replikat hostet.
• Irgendwann fciInstance1 wird die Funktion nicht mehr verfügbarNODE01, und der WSFC verursacht ein Failover von fciInstance1 .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 zu beheben, das dieses Szenario darstellt, muss sich die eigenständige Instanz Instance3auf einem anderen Knoten in demselben WSFC befinden wie NODE01 und NODE02.

Weitere Informationen zu SQL Server FCIs finden Sie unter Always On-Failoverclusterinstanzen (SQL Server).

Einschränkungen bei der Verwendung des WSFC-Managers mit Verfügbarkeitsgruppen

Verwenden Sie den Failovercluster-Manager nicht, um Verfügbarkeitsgruppen zu bearbeiten. Beispiel:

• Fügen Sie keine Ressourcen im gruppierten Dienst (Ressourcengruppe) für die Verfügbarkeitsgruppe hinzu oder entfernen Sie sie.

• Ändern Sie keine Verfügbarkeitsgruppeneigenschaften, z. B. die möglichen Besitzer und bevorzugten Besitzer. Diese Eigenschaften werden automatisch von der Verfügbarkeitsgruppe festgelegt.

• Verwenden Sie den Failovercluster-Manager nicht, um Verfügbarkeitsgruppen auf verschiedene Knoten zu verschieben oder verfügbarkeitsgruppen fehlzuschlagen. Der Failovercluster-Manager kennt nicht den Synchronisierungsstatus der Verfügbarkeitsreplikate, und dies kann zu erweiterten Ausfallzeiten führen. 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 hosten, auf einen Knoten, der bereits ein Replikat derselben Verfügbarkeitsgruppe hosten, kann dazu führen, dass das Verfügbarkeitsgruppenreplikat verloren geht, wodurch verhindert wird, dass sie auf dem Zielknoten online geschaltet wird. Ein einzelner Knoten eines Failoverclusters kann nicht mehr als ein Replikat für dieselbe Verfügbarkeitsgruppe hosten. Weitere Informationen dazu, wie dies auftritt und wie sie wiederhergestellt werden, finden Sie im Blogreplikat, das unerwartet in der Verfügbarkeitsgruppe verworfen wurde.

Verwandte Inhalte

• Was ist eine Always On-Verfügbarkeitsgruppe?
• Aktivieren oder Deaktivieren der Funktion "Always On-Verfügbarkeitsgruppe"
• Überwachen von Verfügbarkeitsgruppen (Transact-SQL)
• AlwaysOn-Failoverclusterinstanzen (SQL Server)
• Konfigurieren von Windows-Failoverclustering für SQL Server (Verfügbarkeitsgruppe oder Failoverclusterinstanz) mit beschränkter Sicherheit
• SQL Server Always On Team Blogs: The official SQL Server Always On Team Blog (SQL Server Always On-Teamblogs: Der offizielle SQL Server Always On-Teamblog)
• CSS SQL Server-Technikblogs
• Always On Architecture Guide: Erstellen einer Hochverfügbarkeits- und Notfallwiederherstellungslösung mithilfe von Failoverclusterinstanzen und Verfügbarkeitsgruppen
• Microsoft SQL Server Always On Solutions Guide für hohe Verfügbarkeit und Notfallwiederherstellung