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 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 der folgenden Abbildung wird eine Failoverclusterinstanz (FCI) in SQL Server 2016 mit zwei Knoten dargestellt.

Multisubnetzarchitektur mit MultiSubnetFailover

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 OR fest.

  • 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 OR fest. Da sich Node1 und Node2 im gleichen Subnetz befinden, bietet diese Konfiguration zusätzlich eine hohe lokale Verfü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 OR fest.

  • 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.

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 2012kö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 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-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 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 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.

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 Server 2016 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 und sqlcmd ist 15 Sekunden.

InhaltsbeschreibungThema
Installieren eines SQL Server-FailoverclustersErstellen eines neuen SQL Server-Failoverclusters (Setup)
Direktes Upgrade des vorhandenen SQL Server-FailoverclustersAktualisieren einer SQL Server-Failoverclusterinstanz (Setup)
Beibehalten des vorhandenen SQL Server-FailoverclustersHinzufügen oder Entfernen von Knoten in einem SQL Server-Failovercluster (Setup)
Windows Failover ClusteringWindows 2008 R2 Failover Multisite Clustering
Verwenden des Failovercluster-Verwaltungs-Snap-ins zum Anzeigen von WSFC-Ereignissen und -ProtokollenAnzeigen 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-FailoverclusterGet-ClusterLog-Failovercluster-Cmdlet

Community-Beiträge

HINZUFÜGEN
Anzeigen: