TechNet
Exportieren (0) Drucken
Alle erweitern

SQL Server-Multisubnetzclustering (SQL Server)

 

Betrifft: SQL Server 2016

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 diesem Thema:

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

Multisubnetzarchitektur mit MultiSubnetFailover

Bookmark link 'Top' is broken in topic '{"project_id":"7d6ffa79-2ddc-4606-b774-a6a5d46784cd","entity_id":"cd909612-99cc-4962-a8fb-e9a5b918e221","entity_type":"Article","locale":"de-DE"}'. Rebuilding the topic '{"project_id":"7d6ffa79-2ddc-4606-b774-a6a5d46784cd","entity_id":"cd909612-99cc-4962-a8fb-e9a5b918e221","entity_type":"Article","locale":"de-DE"}' may solve the problem.

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.

    System_CAPS_ICON_note.jpg 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 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.

System_CAPS_ICON_note.jpg 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.

Bookmark link 'Top' is broken in topic '{"project_id":"7d6ffa79-2ddc-4606-b774-a6a5d46784cd","entity_id":"cd909612-99cc-4962-a8fb-e9a5b918e221","entity_type":"Article","locale":"de-DE"}'. Rebuilding the topic '{"project_id":"7d6ffa79-2ddc-4606-b774-a6a5d46784cd","entity_id":"cd909612-99cc-4962-a8fb-e9a5b918e221","entity_type":"Article","locale":"de-DE"}' may solve the problem.

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 Entity with relative path '../Topic/AlwaysOn%20Client%20Connectivity%20(SQL%20Server).md' can not be found, for source topic '{"project_id":"7d6ffa79-2ddc-4606-b774-a6a5d46784cd","entity_id":"cd909612-99cc-4962-a8fb-e9a5b918e221","entity_type":"Article","locale":"de-DE"}'. 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.

Bookmark link 'Top' is broken in topic '{"project_id":"7d6ffa79-2ddc-4606-b774-a6a5d46784cd","entity_id":"cd909612-99cc-4962-a8fb-e9a5b918e221","entity_type":"Article","locale":"de-DE"}'. Rebuilding the topic '{"project_id":"7d6ffa79-2ddc-4606-b774-a6a5d46784cd","entity_id":"cd909612-99cc-4962-a8fb-e9a5b918e221","entity_type":"Article","locale":"de-DE"}' may solve the problem.

InhaltsbeschreibungThema
Installieren eines SQL Server-FailoverclustersErstellen eines neuen SQL Server-Failoverclusters (Setup)
Direktes Upgrade des vorhandenen SQL Server-FailoverclustersUpgrade a SQL Server Failover Cluster Instance (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

Bookmark link 'Top' is broken in topic '{"project_id":"7d6ffa79-2ddc-4606-b774-a6a5d46784cd","entity_id":"cd909612-99cc-4962-a8fb-e9a5b918e221","entity_type":"Article","locale":"de-DE"}'. Rebuilding the topic '{"project_id":"7d6ffa79-2ddc-4606-b774-a6a5d46784cd","entity_id":"cd909612-99cc-4962-a8fb-e9a5b918e221","entity_type":"Article","locale":"de-DE"}' may solve the problem.

Community-Beiträge

Anzeigen:
© 2016 Microsoft