SQL Server-Multisubnetzclustering (SQL Server)

Ein SQL Server -Multisubnetz-Failovercluster ist eine Konfiguration, in der jeder Failoverclusterknoten mit einem anderen Subnetz oder einer anderen Gruppe von Subnetzen verbunden ist. Diese Subnetze können am gleichen Standort oder an geografisch verteilten Standorten sein. Das Clustering von weit verstreuten Standorten wird mitunter auch als Stretched Cluster bezeichnet. Da kein freigegebener Speicher vorhanden ist, auf den alle Knoten zugreifen können, sollten die Daten zwischen den Datenspeichern in den verschiedenen Subnetzen repliziert werden. Infolge der Datenreplikation ist mehr als eine Kopie der Daten verfügbar. Multisubnetz-Failovercluster bieten somit neben Hochverfügbarkeit auch eine Lösung zur Wiederherstellung im Notfall.

SQL Server-Multisubnetz-Failovercluster (zwei Knoten, zwei Subnetze)

Die folgende Abbildung stellt eine Zwei-Knoten-Zwei-Subnetz-Failoverclusterinstanz (FCI) in SQL Server 2014 dar.

Konfigurationen einer Multisubnetz-Failoverclusterinstanz

Im Folgenden finden Sie einige Beispiele für SQL Server -FCIs mit mehreren Subnetzen:

• SQL Server -FCI SQLCLUST1 enthält Node1 und Node2. Node1 ist mit Subnet1 verbunden. Node2 ist mit Subnet2 verbunden. SQL Server -Setup betrachtet diese Konfiguration als Multisubnetzcluster und legt die IP-Adressressourcenabhängigkeit auf ORfest.

• SQL Server -FCI SQLCLUST1 enthält Node1, Node2 und Node3. Node1 und Node2 sind mit Subnet1 verbunden. Node3 ist mit Subnet2 verbunden. SQL Server -Setup betrachtet diese Konfiguration als Multisubnetzcluster und legt die IP-Adressressourcenabhängigkeit auf ORfest. Da sich Node1 und Node2 im gleichen Subnetz befinden, bietet diese Konfiguration zusätzlich lokale Hochverfügbarkeit.

• SQL Server -FCI SQLCLUST1 enthält Node1 und Node2. Node1 befindet sich in Subnet1. Node2 befindet sich in Subnet1 und Subnet2. SQL Server -Setup betrachtet diese Konfiguration als Multisubnetzcluster und legt die IP-Adressressourcenabhängigkeit auf ORfest.

• SQL Server -FCI SQLCLUST1 enthält Node1 und Node2. Node1 ist mit Subnet1 und Subnet2 verbunden. Node2 ist auch mit Subnet1 und Subnet2 verbunden. Die IP-Adressabhängigkeit wird vom Setup von auf AND SQL Server festgelegt.

  Hinweis

  Diese Konfiguration wird nicht als Multisubnetz-Failovercluster-Konfiguration betrachtet, da sich die gruppierten Knoten in der gleichen Subnetzgruppe befinden.

Überlegungen zu IP-Adressressourcen

Die IP-Adressen in einer Multisubnetz-Failoverclusterkonfiguration sind nicht im Besitz aller Knoten im Failovercluster und beim Start von SQL Server möglicherweise nicht alle online. Ab SQL Server 2012 können Sie die IP-Adressressourcenabhängigkeit auf OR festlegen. Dadurch kann SQL Server online sein, wenn mindestens eine gültige IP-Adresse vorhanden ist, mit der eine Bindung hergestellt werden kann.

Hinweis

In den SQL Server-Versionen vor SQL Server 2012 wurde eine Stretch-V-LAN-Technologie in Multi-Site-Cluster-Konfigurationen genutzt, um eine einzelne IP-Adresse für den Failover standortübergreifend verfügbar zu machen. Durch die neue Möglichkeit zur Gruppierung von Knoten in unterschiedlichen Subnetzen in SQL Server können Sie jetzt SQL Server -Failovercluster an mehreren Standorten ohne Stretch-V-LAN-Technologie konfigurieren.

Überlegungen zur IP-Adressabhängigkeit OR

Wenn Sie die IP-Adressabhängigkeit auf ORfestlegen, können Sie das folgende Failoververhalten in Betracht ziehen:

• Bei einem Fehler in einer IP-Adresse im Knoten, in dessen Besitz sich die SQL Server -Clusterressourcengruppe derzeit befindet, wird nicht automatisch ein Failover ausgelöst, solange nicht alle gültigen IP-Adressen in diesem Knoten ausgefallen sind.

• Wenn ein Failover auftritt, wird SQL Server online geschaltet, wenn eine Bindung zu mindestens einer gültigen IP-Adresse im aktuellen Knoten hergestellt werden kann. Die IP-Adressen, für die beim Start von SQL Server keine Bindung hergestellt werden konnte, werden im Fehlerprotokoll aufgeführt.

Wenn eine SQL Server -FCI und eine eigenständige SQL Server-Datenbank-Engine-Instanz parallel installiert sind, achten Sie darauf, dass Konflikte mit TCP-Portnummern für die IP-Adressen vermieden werden. Konflikte treten in der Regel auf, wenn in zwei Datenbank-Engine -Instanzen die Verwendung des TCP-Standartports (1433) konfiguriert wurde. Um Konflikte zu vermeiden, konfigurieren Sie in einer Instanz die Verwendung eines nicht standardmäßigen festen Ports. Die Konfiguration eines festen Ports kann in der Regel in der eigenständigen Instanz am einfachsten vorgenommen werden. Wenn Datenbank-Engine für die Verwendung anderer Ports konfiguriert wird, wird verhindert, dass ein unerwarteter IP-Adressen-/TCP-Port-Konflikt auftritt, der den Start einer Instanz blockiert, wenn eine SQL Server -FCI ein Failover zu dem Standbyknoten ausführt.

Clientwiederherstellungs-Latenzzeit während der Failover

Die RegisterAllProvidersIP-Clusterressource wird von einer Multisubnetz-FCI für den Netzwerknamen standardmäßig aktiviert. In einer Multisubnetzkonfiguration werden die Online- und Offline-IP-Adressen des Netzwerknamens beim DNS-Server registriert. Die Clientanwendung ruft dann alle registrierten IP-Adressen vom DNS-Server ab und versucht, entweder geordnet oder parallel eine Verbindung mit den Adressen herzustellen. Demnach hängt die Clientwiederherstellungszeit in Multisubnetz-Failovern nicht länger von DNS-Aktualisierungs-Wartezeiten ab. Standardmäßig versucht der Client die IP-Adressen geordnet abzurufen. Wenn der Client den neuen optionalen MultiSubnetFailover=True Parameter in seiner Verbindungszeichenfolge verwendet, wird er stattdessen die IP-Adressen gleichzeitig ausprobieren und eine Verbindung mit dem ersten Server herstellen, der antwortet. Dadurch kann die Clientwiederherstellungs-Latenzzeit minimiert werden, wenn Failover auftreten. Weitere Informationen finden Sie unter AlwaysOn Client Connectivity (SQL Server) und Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server).For more information, see AlwaysOn Client Connectivity (SQL Server) and Create or Configure an Availability Group Listener (SQL Server).

Bei älteren Clientbibliotheken oder Drittanbieterdatenanbietern können Sie den MultiSubnetFailover Parameter nicht in Ihrer Verbindungszeichenfolge verwenden. Um sicherzustellen, dass Ihre Clientanwendung optimal mit Multi-Subnetz-FCI in SQL Server 2014 funktioniert, versuchen Sie, das Verbindungstimeout in der Clientverbindungszeichenfolge für jede zusätzliche IP-Adresse um 21 Sekunden anzupassen. Dadurch wird sichergestellt, dass der Wiederverbindungsversuch des Clients nicht zu einem Timeout führt, bevor es in der Lage ist, alle IP-Adressen in der Multisubnetz-FCI durchzugehen.

Der standardmäßige Timeoutzeitraum für Clientverbindungen von SQL Server Management Studio und sqlcmd ist 15 Sekunden.

Verwandte Inhalte

Inhaltsbeschreibung	Thema
Installieren eines SQL Server-Failoverclusters	Erstellen eines neuen SQL Server-Failoverclusters (Setup)
Direktes Upgrade des vorhandenen SQL Server-Failoverclusters	Aktualisieren einer SQL Server-Failoverclusterinstanz (Setup)
Beibehalten des vorhandenen SQL Server-Failoverclusters	Hinzufügen oder Entfernen von Knoten in einem SQL Server-Failovercluster (Setup)
Windows-Failover-Cluster	Bewährte Methoden für den Microsoft Windows Multi-Site-Failover-Cluster
Verwenden des Failovercluster-Verwaltungs-Snap-ins zum Anzeigen von WSFC-Ereignissen und -Protokollen	Anzeigen von Ereignissen und Protokollen für einen Failovercluster
Verwenden von Windows PowerShell zum Erstellen einer Protokolldatei für alle Knoten (oder einen bestimmten Knoten) in einem WSFC-Failovercluster	Get-ClusterLog-Failovercluster-Cmdlet