Le délai d’expiration se produit lorsque vous vous connectez à un écouteur Always On dans un environnement à plusieurs sous-réseaux

  • Article

Cet article vous aide à résoudre le problème qui se produit lorsque vous vous connectez à un écouteur de groupe de disponibilité SQL Server Always On dans un environnement à plusieurs sous-réseaux.

Version du produit d’origine : 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
Numéro de la base de connaissances d’origine : 2792139

Symptômes

Après avoir configuré l’écouteur de groupe de disponibilité pour un groupe de disponibilité Always On dans Microsoft SQL Server 2012, vous ne pourrez peut-être pas effectuer un test ping sur l’écouteur ou vous y connecter à partir d’une application.

Par exemple, lorsque vous essayez de vous connecter à un écouteur de SQL Server à l’aide SQLCMDde , la connexion expire. En outre, vous recevez un message d’erreur qui ressemble au suivant :

Sqlcmd : Erreur : Microsoft SQL Native Client : Le délai de connexion a expiré.

Remarque

Ces symptômes sont généralement intermittents ou liés au basculement de la ressource de groupe de disponibilité.

La capture d’écran suivante montre un exemple de ce qui se produit lorsque vous essayez d’effectuer un test ping sur l’écouteur pour la disponibilité de aglisten. La capture d’écran montre également une connexion réussie à SQL Server à l’aide de la SQLCMD commande lorsque vous incluez le paramètre -Mde basculement à plusieurs sous-réseaux .

Capture d’écran de la fenêtre d’invite de commandes lorsque vous effectuez un test ping sur l’écouteur pour connaître la disponibilité d’aglisten.

Remarque

Vous pouvez utiliser la SQLCMD commande avec le -M paramètre comme indiqué dans la capture d’écran pour vous connecter à l’écouteur.

Cause

Ce problème se produit parce que votre application utilise un fournisseur de données hérité qui ne prend pas en charge le nouveau MultiSubnetFailover paramètre ou n’est pas configuré pour utiliser ce paramètre.

Ce paramètre est pris en charge dans les versions plus récentes du pilote SQLClient inclus avec le .NET Framework 4 et les versions ultérieures du .NET Framework, et est de nouveau porté vers .NET Framework 3.5.

Remarque

La PING commande est un outil de test de connectivité simple qui ne prend pas en charge le nouveau paramètre.

Résolution

Vous pouvez utiliser l’une des solutions suivantes en fonction de votre cas :

  • Pour résoudre ce problème lorsque les fournisseurs de données prennent en charge le MultiSubNetFailover paramètre, ajoutez le MultiSubNetFailover paramètre à votre chaîne de connexion et définissez-le sur true.

  • Pour résoudre ce problème lorsque vos clients hérités ne peuvent pas utiliser la MultiSubnetFailover propriété , vous pouvez modifier la valeur de RegisterAllProvidersIP l’écouteur sur 0. Pour ce faire, exécutez la commande suivante à partir de l’interface de ligne de commande Windows PowerShell :

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

    Capture d’écran montrant la sortie d’un exemple de commande dans Windows PowerShell.

Remarque

Après avoir défini la RegisterAllProvidersIP valeur sur 0, l’adresse IP en ligne actuelle doit être désinscrit du serveur DNS et l’adresse IP hors connexion doit être inscrite auprès du serveur DNS lorsqu’un basculement se produit. Cela peut entraîner un retard de connexion pour le basculement suivant.

Plus d’informations

Lorsque vous essayez de vous connecter à un écouteur défini sur plusieurs sous-réseaux, l’opération peut échouer si le pilote client tente de se connecter à l’aide de l’une des adresses IP hors connexion de l’écouteur.

Lorsqu’un écouteur est créé, une adresse IP est désignée pour chaque sous-réseau unique dans lequel un groupe de disponibilité réplica est hébergé. Par exemple, si un écouteur est créé pour un groupe de disponibilité qui a des réplicas qui existent dans deux sous-réseaux, deux adresses IP sont définies dans l’écouteur. Une adresse est utilisée par une application qui peut se connecter à un instance de SQL Server dans le sous-réseau 1, et l’autre adresse est utilisée lorsqu’une application se connecte à un instance de SQL Server dans le sous-réseau 2.

En arrière-plan, l’écouteur crée une ressource point d’accès client de cluster Windows. L’une de ses propriétés est RegisterAllProvidersIP. Lorsqu’un écouteur est créé, il est défini sur 1, et toutes les adresses IP de l’écouteur sont inscrites sur le serveur DNS. Cette configuration permet aux clients de réduire le temps de reconnexion.

Étant donné que l’enregistrement DNS contient toutes les adresses IP, un client qui tente de se connecter à l’écouteur doit savoir comment gérer cette situation. Le MultiSubnetFailover paramètre permet au pilote client d’essayer des connexions en parallèle à toutes les adresses IP de l’écouteur. Sans le MultiSubnetFailover paramètre , le pilote client tente de se connecter séquentiellement à toutes les adresses IP de l’écouteur. Les connexions séquentielles peuvent entraîner une ouverture de session longue ou des délais d’ouverture de session.

Remarque

Le problème mentionné dans cet article affecte également les environnements SharePoint configurés pour utiliser un réplica secondaire en lecture seule d’un groupe de disponibilité Always On. Pour résoudre ce problème, effectuez les actions suivantes qui s’appliquent à votre version de SharePoint :

References