SQL Server-Multi-Subnetzclustering

Gilt für:SQL Server

Ein MULTI-Subnetz-Failovercluster von SQL Server 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. Cluster in geografisch verteilten Standorten werden manchmal als Stretchcluster bezeichnet. Da es keinen freigegebenen Speicher gibt, auf den alle Knoten zugreifen können, sollten Daten zwischen dem Datenspeicher in den mehreren Subnetzen repliziert werden. Wenn Sie Daten replizieren, gibt es mehr als eine Kopie der verfügbaren Daten. Multisubnetz-Failovercluster bieten somit neben Hochverfügbarkeit auch eine Lösung zur Wiederherstellung im Notfall.

SQL Server-Failovercluster mit mehreren Subnetzen (zwei Knoten, zwei Subnetze)

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

Konfigurationen für Mehrere Subnetz-Failoverclusterinstanzen

Im Folgenden sind einige Beispiele für SQL Server FCIs aufgeführt, die mehrere Subnetze verwenden:

• SQL Server -FCI SQLCLUST1 enthält Node1 und Node2. Node1 ist mit Subnet1 verbunden. Node2 ist mit Subnet2 verbunden. SQL Server Setup sieht diese Konfiguration als Multisubnetzcluster und legt die ABHÄNGIGKEIT der IP-Adressressource auf OR.

• SQL Server FCI SQLCLUST2 umfasst Node1, Node2 und Node3. Node1 und Node2 sind mit Subnet1 verbunden. Node3 ist mit Subnet2 verbunden. SQL Server Setup sieht diese Konfiguration als Multisubnetzcluster und legt die ABHÄNGIGKEIT der IP-Adressressource auf OR. Da sich Node1 und Node2 im gleichen Subnetz befinden, bietet diese Konfiguration zusätzlich lokale Hochverfügbarkeit.

• SQL Server FCI-SQLCLUST3 umfasst Node1 und Node2. Node1 befindet sich in Subnet1. Node2 befindet sich in Subnet1 und Subnet2. SQL Server Setup sieht diese Konfiguration als Multisubnetzcluster und legt die ABHÄNGIGKEIT der IP-Adressressource auf OR.

• SQL Server FCI-SQLCLUST4 umfasst Node1 und Node2. Node1 ist mit Subnet1 und Subnet2 verbunden. Node2 ist auch mit Subnet1 und Subnet2 verbunden. SQL Server Setup legt die Abhängigkeit der IP-Adressressource auf AND.

  Hinweis

  Diese Konfiguration gilt nicht als Multisubnetz-Failoverclusterkonfiguration, da sich die gruppierten Knoten in derselben Gruppe von Subnetzen befinden.

Überlegungen zur IP-Adressressource

Bei einer Konfiguration eines Failoverclusters mit mehreren Subnetzen befinden sich die IP-Adressen nicht im Besitz aller Knoten im Failovercluster, und sie sind möglicherweise nicht alle während des SQL Server-Starts online. Ab SQL Server 2012 (11.x) können Sie die ABHÄNGIGKEIT der IP-Adressressource auf festlegen OR. Dadurch kann SQL Server online sein, wenn mindestens eine gültige IP-Adresse vorhanden ist, an die eine Bindung hergestellt werden kann.

Hinweis

In SQL Server-Versionen vor SQL Server 2012 (11.x) wurde eine Stretch-V-LAN-Technologie in Multi-Site-Clusterkonfigurationen verwendet, um eine einzelne IP-Adresse für failoverübergreifende Standorte verfügbar zu machen. Da SQL Server Knoten in verschiedenen Subnetzen clustern kann, können Sie SQL Server-Failovercluster an mehreren Standorten konfigurieren, ohne die Stretch-V-LAN-Technologie zu implementieren.

Überlegungen zur IP-Adressressource ODER -Abhängigkeit

Sie sollten das folgende Failoververhalten berücksichtigen, wenn Sie die Abhängigkeit der IP-Adressressource auf ORFolgendes festlegen:

• Wenn ein Fehler einer der IP-Adressen auf dem Knoten auftritt, der derzeit die SQL Server-Clusterressourcengruppe besitzt, wird ein Failover erst automatisch ausgelöst, wenn alle für diesen Knoten gültigen IP-Adressen fehlschlagen.

• Wenn ein Failover auftritt, wird SQL Server online, wenn es eine Bindung an mindestens eine IP-Adresse herstellen kann, die auf dem aktuellen Knoten gültig ist. Die IP-Adressen, die beim Start nicht an SQL Server gebunden wurden, werden im Fehlerprotokoll aufgeführt.

Wenn eine SQL Server-FCI parallel mit einer eigenständigen Instanz des SQL Server-Datenbankmoduls installiert wird, sollten Sie darauf achten, TCP-Portnummernkonflikte bei den IP-Adressen zu vermeiden. Konflikte treten in der Regel auf, wenn zwei Instanzen des Datenbankmoduls für die Verwendung des standardmäßigen TCP-Ports (1433) konfiguriert sind. Um Konflikte zu vermeiden, konfigurieren Sie eine Instanz für die Verwendung eines nicht standardmäßigen festen Ports. Das Konfigurieren eines festen Ports ist in der Regel für die eigenständige Instanz einfacher. Das Konfigurieren des Datenbankmoduls für die Verwendung verschiedener Ports verhindert einen unerwarteten IP-Adresse/TCP-Portkonflikt, der den Start einer Instanz blockiert, wenn ein SQL Server-FCI nicht zum Standbyknoten wechselt.

Clientwiederherstellungslatenz während des Failovers

Standardmäßig aktiviert ein Multisubnetz-FCI die RegisterAllProvidersIP-Clusterressource für den Netzwerknamen. In einer Konfiguration mit mehreren Subnetzen werden die Online- und Offline-IP-Adressen des Netzwerknamens beide auf dem DNS-Server registriert. Die Clientanwendung ruft dann alle registrierten IP-Adressen vom DNS-Server ab und versucht, eine Verbindung mit den Adressen herzustellen, entweder in der Reihenfolge oder parallel. Dies bedeutet, dass die Clientwiederherstellungszeit in Multisubnetzfailovern nicht mehr von DNS-Updatelatenzen abhängt. Standardmäßig versucht der Client die IP-Adressen geordnet abzurufen. Wenn der Client den optionalen MultiSubnetFailover=True Parameter in seiner Verbindungszeichenfolge verwendet, versucht er stattdessen die IP-Adressen gleichzeitig und stellt eine Verbindung mit dem ersten Server bereit, der antwortet. Diese Konfiguration kann dazu beitragen, die Clientwiederherstellungslatenz beim Auftreten von Failovern zu minimieren. Weitere Informationen finden Sie unter Always On Client Connectivity (SQL Server) und Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server).For more information, see Always On client connectivity (SQL Server) and Create or configure an availability group listener (SQL Server).

Bei älteren Clientbibliotheken oder Nicht-Microsoft-Datenanbietern können Sie den MultiSubnetFailover-Parameter nicht in Ihrer Verbindungszeichenfolge 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. Diese Konfiguration stellt sicher, dass der Erneutverbindungsversuch des Clients nicht zu einem Timeout führt, bevor alle IP-Adressen in Ihrem Multi-Subnetz-FCI durchlaufen werden können.

Der Standardmäßige Timeoutzeitraum für Clientverbindung für SQL Server Management Studio und sqlcmd beträgt 15 Sekunden.

Hinweis

Wenn Sie mehrere Subnetze verwenden und über ein statisches DNS verfügen, müssen Sie über einen Prozess verfügen, um den dem Listener zugeordneten DNS-Eintrag zu aktualisieren, bevor Sie ein Failover ausführen. Andernfalls kommt der Netzwerkname nicht online.

Verwandte Inhalte

Description	Artikel
Installieren eines SQL Server-Failoverclusters	Erstellen eines neuen SQL Server-Failoverclusters (Setup)
Direktes Upgrade Ihres vorhandenen SQL Server-Failoverclusters	Upgrade einer SQL Server-Failoverclusterinstanz (Setup)
Verwalten des SQL Server-Failoverclusters	Hinzufügen oder Entfernen von Knoten in einem SQL Server-Failovercluster (Setup)
Verwenden des Failoverclusterverwaltungs-Snap-Ins zum Anzeigen von Windows Server-Failoverclusterereignissen 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 Windows Server-Failovercluster	Get-ClusterLog Failovercluster-Cmdlet