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 sich am gleichen Standort oder an weit verstreuten Standorten befinden. Das Clustering von weit verstreuten Standorten wird mitunter auch als Stretchcluster 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 hoher Verfügbarkeit auch eine Lösung zur Wiederherstellung im Notfall.

In diesem Thema:

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

• Überlegungen zu IP-Adressressourcen

• Clientwiederherstellungs-Latenzzeit während der Failover

• Verwandte Inhalte

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

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

[Nach oben]

Konfigurationen einer Multisubnetz-Failoverclusterinstanz

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

• Der SQL Server-FCI SQLCLUST1 enthält Node1 und Node2. Node1 ist mit Subnet1 verbunden. Node2 ist mit Subnet2 verbunden. Vom Setup von SQL Server wird diese Konfiguration als Multisubnetzcluster angesehen, und die IP-Adressabhängigkeit wird auf OR festgelegt.

• Der SQL Server-FCI SQLCLUST1 enthält Node1, Node2 und Node3. Node1 und Node2 sind mit Subnet1 verbunden. Node3 ist mit Subnet2 verbunden. Vom Setup von SQL Server wird diese Konfiguration als Multisubnetzcluster angesehen, und die IP-Adressabhängigkeit wird auf OR festgelegt. Da sich Node1 und Node2 im gleichen Subnetz befinden, bietet diese Konfiguration zusätzlich eine hohe lokale Verfügbarkeit.

• Der SQL Server-FCI SQLCLUST1 enthält Node1 und Node2. Node1 befindet sich in Subnet1. Node2 befindet sich in Subnet1 und Subnet2. Vom Setup von SQL Server wird diese Konfiguration als Multisubnetzcluster angesehen, und die IP-Adressabhängigkeit wird auf OR festgelegt.

• Der 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 SQL Server auf AND 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-Adressabhä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 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 OR festlegen, 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.

[Nach oben]

Wenn eine SQL Server-FCI und eine eigenständige SQL Server Database Engine (Datenbankmodul)-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 Database Engine (Datenbankmodul)-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 Database Engine (Datenbankmodul) 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 AlwaysOn-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 Server 2012 interagiert. 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 and sqlcmd beträgt 15 Sekunden.

[Nach oben]

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 Clustering	Windows 2008 R2 Failover Multisite Clustering
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

[Nach oben]