Freigeben über

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

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.

Ursprüngliche Produktversion: SQL Server 2012 und höhere Versionen
Ursprüngliche KB-Nummer: 2792139

Problembeschreibung

Nachdem Sie den Verfügbarkeitsgruppenlistener für eine Always On-Verfügbarkeitsgruppe in Microsoft SQL Server konfiguriert haben, können Sie den Listener möglicherweise nicht pingen oder von einer Anwendung aus keine Verbindung mit ihm herstellen.

Wenn Sie z. B. versuchen, mit einem Listener von SQL Server eine Verbindung über SQLCMD herzustellen, tritt ein Verbindungs-Timeout auf. Darüber hinaus erhalten Sie eine Fehlermeldung, die der folgenden ähnelt:

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

Notiz

Diese Symptome treten zeitweise auf oder stehen 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, weil 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 in .NET Framework 4 und höheren Versionen von .NET Framework enthalten ist, und wird zurück auf .NET Framework 3.5 portiert.

Notiz

Bei dem PING Befehl handelt es sich um ein einfaches Tool zum Testen der Konnektivität, 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.

  • Wenn Ihre Legacyclients die MultiSubnetFailover Eigenschaft nicht verwenden können, beheben Sie das Problem, indem Sie den RegisterAllProvidersIP Wert des Listeners in 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 Registrierung der aktuellen Online-IP-Adresse beim DNS-Server aufgehoben werden, und die Offline-IP-Adresse muss beim DNS-Server registriert werden, wenn ein Failover auftritt. 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 diese Eigenschaft 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 einer langen Anmeldezeit oder zu 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:

Verweise