SQL Server-Multisubnetzclustering (SQL Server)

Gilt für: 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)

In der folgenden Abbildung wird eine Failoverclusterinstanz (FCI) in SQL Servermit zwei Knoten dargestellt.

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 (11.x)können Sie die IP-Adressabhängigkeit auf ORfestlegen. 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 (11.x)wurde eine Stretch-V-LAN-Technologie in Clusterkonfigurationen mit mehreren Standorten verwendet, um eine einzelne IP-Adresse für standortübergreifende Failover 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, versucht er stattdessen gleichzeitig die IP-Adressen abzurufen und stellt eine Verbindung mit dem ersten antwortenden Server her. Dadurch kann die Clientwiederherstellungs-Latenzzeit minimiert werden, wenn Failover auftreten. Weitere Informationen finden Sie unter Always On-Clientkonnektivität (SQL Server) und Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server).

Bei Legacyclientbibliotheken oder Drittanbieterdatenanbietern können Sie den MultiSubnetFailover -Parameter in der Verbindungszeichenfolge nicht verwenden. Versuchen Sie, den Verbindungstimeout in der Clientverbindungszeichenfolge um 21 Sekunden für jede zusätzliche IP-Adresse anzupassen, damit sichergestellt wird, dass Ihre Clientanwendung optimal mit dem Multisubnetz-FCI in SQL Serverinteragiert. 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.

Hinweis

• Wenn Sie mehrere Subnetze verwenden und über ein statisches DNS verfügen, benötigen Sie einen Prozess, um den dem Listener zugeordneten DNS-Eintrag zu aktualisieren, bevor Sie einen Failover durchführen, da sonst der Netzwerkname nicht online geht.

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)
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