Freigeben über

Timeout beim Herstellen einer Verbindung mit einem Always On-Listener in einer Umgebung mit mehreren Subnetzen

  • Artikel

Dieser Artikel hilft Ihnen, das Problem zu beheben, das auftritt, wenn Sie eine Verbindung mit einem SQL Server AlwaysOn-Verfügbarkeitsgruppenlistener in einer Multi-Subnetzumgebung herstellen.

Originalproduktversion: SQL Server 2012 Developer, SQL Server 2012 Enterprise, SQL Server 2012 Express, SQL Server 2012 Standard, SQL Server 2012 Web, SQL Server 2012 Enterprise Core
Ursprüngliche KB-Nummer: 2792139

Problembeschreibung

Nachdem Sie den Verfügbarkeitsgruppenlistener für eine AlwaysOn-Verfügbarkeitsgruppe in Microsoft SQL Server 2012 konfiguriert haben, können Sie den Listener möglicherweise nicht pingen oder über eine Anwendung eine Verbindung damit herstellen.

Wenn Sie beispielsweise versuchen, mithilfe von SQL Server eine Verbindung mit einem Listener von SQL Server SQLCMDherzustellen, wird ein Zeitüberschreitung der Verbindung ausgeführt. Darüber hinaus erhalten Sie eine Fehlermeldung, die etwa wie folgt aussieht:

Sqlcmd: Fehler: Microsoft SQL Native Client: Anmeldetimeout abgelaufen.

Notiz

Diese Symptome sind in der Regel zeitweise oder im Zusammenhang mit einem Failover der Verfügbarkeitsgruppenressource.

Der folgende Screenshot zeigt ein Beispiel dafür, was auftritt, wenn Sie versuchen, den Listener für die Verfügbarkeit aglistenzu pingen. Der Screenshot zeigt auch eine erfolgreiche Verbindung mit SQL Server mithilfe des SQLCMD Befehls, wenn Sie den Parameter für das Failover -Mmit mehreren Subnetzen einschließen.

Screenshot des Eingabeaufforderungsfensters, wenn Sie den Listener für die Verfügbarkeit von Aglisten pingen.

Notiz

Sie können den SQLCMD Befehl zusammen mit dem -M Parameter verwenden, wie im Screenshot gezeigt, um eine Verbindung mit dem Listener herzustellen.

Ursache

Dieses Problem tritt auf, da Ihre Anwendung entweder einen Legacydatenanbieter verwendet, der den neuen MultiSubnetFailover Parameter nicht unterstützt oder nicht für die Verwendung dieses Parameters konfiguriert ist.

Dieser Parameter wird in neueren Versionen des SQLClient-Treibers unterstützt, der im Lieferumfang von .NET Framework 4 enthalten ist, und mit höheren Versionen von .NET Framework und wird wieder zu .NET Framework 3.5 portiert.

Notiz

Der PING Befehl ist ein einfaches Verbindungstesttool, das den neuen Parameter nicht unterstützt.

Lösung

Sie können eine der folgenden Entschließungen für Ihren Fall verwenden:

  • Um diese Situation zu beheben, wenn die Datenanbieter den MultiSubNetFailover Parameter unterstützen, fügen Sie den MultiSubNetFailover Parameter zu Ihrem Verbindungszeichenfolge hinzu, und legen Sie ihn auf "true" fest.

  • Um diese Situation zu beheben, wenn Ihre Legacyclients die MultiSubnetFailover Eigenschaft nicht verwenden können, können Sie den Listenerwert RegisterAllProvidersIP auf 0 ändern. Führen Sie dazu den folgenden Befehl über die Windows PowerShell-Befehlszeilenschnittstelle aus:

    Import-Module FailoverClusters
Get-ClusterResource <*Your listener name*>|Set-ClusterParameter RegisterAllProvidersIP 0

    Der Screenshot zeigt die Ausgabe eines Beispiels für den Befehl in Windows PowerShell.

Notiz

Nachdem Sie den RegisterAllProvidersIP Wert auf 0 festgelegt haben, muss die aktuelle Online-IP-Adresse vom DNS-Server nicht registriert werden, und die Offline-IP-Adresse muss beim Auftreten eines Failovers auf dem DNS-Server registriert werden. Dies kann zu einer Verbindungsverzögerung für das nächste Failover führen.

Weitere Informationen

Wenn Sie versuchen, eine Verbindung mit einem Listener herzustellen, der in mehr als einem Subnetz definiert ist, schlägt der Vorgang möglicherweise fehl, wenn der Clienttreiber versucht, eine Verbindung mithilfe einer der Offline-IP-Adressen des Listeners herzustellen.

Wenn ein Listener erstellt wird, wird für jedes eindeutige Subnetz, in dem ein Verfügbarkeitsgruppenreplikat gehostet wird, eine IP-Adresse festgelegt. Wenn beispielsweise ein Listener für eine Verfügbarkeitsgruppe mit Replikaten erstellt wird, die in zwei Subnetzen vorhanden sind, werden zwei IP-Adressen im Listener definiert. Eine Adresse wird von einer Anwendung verwendet, die eine Verbindung mit einer Instanz von SQL Server in Subnetz 1 herstellen kann, und die andere Adresse wird verwendet, wenn eine Anwendung eine Verbindung mit einer Instanz von SQL Server in Subnetz 2 herstellt.

Hinter den Kulissen erstellt der Listener eine Windows-Clusterclientzugriffspunkt-Ressource. Eine seiner Eigenschaften ist RegisterAllProvidersIP. Wenn ein Listener erstellt wird, wird dies auf 1 festgelegt, und alle IP-Adressen des Listeners werden auf dem DNS-Server registriert. Diese Konfiguration bietet eine reduzierte Erneute Verbindung für Clients.

Da der DNS-Eintrag alle IP-Adressen enthält, muss ein Client, der versucht, eine Verbindung mit dem Listener herzustellen, wissen, wie diese Situation behandelt wird. Der MultiSubnetFailover Parameter ermöglicht es dem Clienttreiber, Parallele zu allen IP-Adressen des Listeners herzustellen. Ohne den MultiSubnetFailover Parameter versucht der Clienttreiber, eine sequenzielle Verbindung mit allen IP-Adressen für den Listener herzustellen. Sequenzielle Verbindungen können zu langen Anmeldezeit- oder Anmeldetimeouts führen.

Notiz

Das Problem, das in diesem Artikel erwähnt wird, wirkt sich auch auf SharePoint-Umgebungen aus, die für die Verwendung des sekundären schreibgeschützten Replikats einer Always On-Verfügbarkeitsgruppe konfiguriert sind. Führen Sie zum Beheben dieses Problems die folgenden Aktionen für Ihre SharePoint-Version aus:

References