Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
SQL Server
Ein SQL Server-Multisubnetz-Failovercluster ist eine Konfiguration, in der jeder Failoverclusterknoten mit einem anderen Subnetz bzw. 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 umfasst Node1 und Node2. Node1 ist mit Subnet1 verbunden. Node2 ist mit Subnet2 verbunden. SQL Server Setup erkennt diese Konfiguration als Multisubnetzcluster und setzt 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 erkennt diese Konfiguration als Multi-Subnetz-Cluster und legt die Abhängigkeit der IP-Adressressource auf
ORfest. 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 erkennt diese Konfiguration als einen Multisubnetzcluster und setzt 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 setzt die Ressourcenabhä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 OR festlegen. 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 in Clusterkonfigurationen mit mehreren Standorten eine Stretch-VLAN-Technologie verwendet, um für ein standortübergreifendes Failover eine einzelne IP-Adresse bereitzustellen. 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 in Betracht ziehen, wenn Sie die Abhängigkeit der IP-Adressressource auf OR festlegen:
Wenn eine der IP-Adressen auf dem Knoten ausfällt, dem derzeit die SQL Server-Clusterressourcengruppe gehört, wird ein Failover nicht automatisch ausgelöst, bis alle auf diesem Knoten gültigen IP-Adressen ausgefallen sind.
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 wird bei einem FCI mit mehreren Subnetzen die Clusterressource „RegisterAllProvidersIP“ für den Netzwerknamen aktiviert. 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.