Partager via

Une erreur de délai d’expiration se produit lorsque vous vous connectez à un écouteur Always On dans un environnement comportant 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é Always On SQL Server dans un environnement multi-sous-réseau.

Version de 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 base de connaissances d’origine : 2792139

Symptômes

Après avoir configuré l’écouteur du 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 semblable à ce qui suit :

Sqlcmd : Erreur : Microsoft SQL Native Client : expiration du délai d’expiration de la connexion.

Note

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 multi-sous-réseau.

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

Note

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 .NET Framework 4 et avec les versions ultérieures du .NET Framework, et est de retour vers .NET Framework 3.5.

Note

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 résolutions suivantes en fonction de votre cas :

  • Pour résoudre cette situation lorsque les fournisseurs de données prennent en charge le MultiSubNetFailover paramètre, ajoutez-le MultiSubNetFailover à 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 remplacer la valeur de RegisterAllProvidersIP l’écouteur par 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.

Note

Après avoir défini la RegisterAllProvidersIP valeur 0, l’adresse IP en ligne actuelle doit être non inscrite à partir du serveur DNS et l’adresse IP hors connexion doit être inscrite sur le serveur DNS lorsqu’un basculement se produit. Cela peut entraîner un délai 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 réplica de groupe de disponibilité 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 à une instance de SQL Server dans le sous-réseau 1, et l’autre adresse est utilisée lorsqu’une application se connecte à une instance de SQL Server dans le sous-réseau 2.

En arrière-plan, l’écouteur crée une ressource de 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 dans le serveur DNS. Cette configuration fournit un temps de reconnexion réduit pour les clients.

É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 de manière séquentielle à toutes les adresses IP de l’écouteur. Les connexions séquentielles peuvent entraîner une longue ouverture de session ou des délais d’ouverture de session.

Note

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

References