Erreur de délai d'attente et vous ne pouvez pas vous connecter à un écouteur de groupe de disponibilité AlwaysOn de SQL Server 2012 dans un environnement à plusieurs sous-réseaux

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 2792139
Symptômes
Après avoir configuré l'écouteur du groupe de disponibilité pour un groupe de disponibilité AlwaysOn dans Microsoft SQL Server 2012, il se peut que vous ne puissiez pas ping l'écouteur ou de s'y connecter à partir d'une application.

Par exemple, lorsque vous essayez de vous connecter à un port d'écoute de SQL Server à l'aide de SQLCMD, la délai de connexion expire. En outre, vous recevez un message d'erreur semblable au suivant :
Sqlcmd : Erreur : Microsoft SQL Native Client : délai de connexion expiré.

Remarque Ces symptômes sont généralement intermittentes ou se rapportent à un 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'exécuter la commande ping l'écouteur pour la disponibilité de « aglisten ». La capture d'écran montre également une connexion à SQL Server à l'aide de la commande SQLCMD lorsque vous incluez le paramètre de basculement de plusieurs sous-réseaux -M.


Exemple de défaillance

Remarque Vous pouvez utiliser la commande SQLCMD avec le paramètre – M comme indiqué sur l'écran pour vous connecter à l'écouteur.
Cause
Ce problème se produit parce que votre application utilise un fournisseur de données héritées qui ne gère pas le nouveau paramètre MultiSubnetFailover , 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 qui est fourni avec le.NET Framework de la Microsoft 4 et versions ultérieures du.NET Framework et est porté précédent pour le.NET Framework de la Microsoft 3.5 SQLClient.

Remarque La commande PING est une outil qui ne prend pas en charge le nouveau paramètre de test une connectivité simple.
Résolution
Vous pouvez utiliser une des résolutions suivantes s'applique à votre cas :
  • Pour résoudre ce problème lorsque les fournisseurs de données prennent en charge le paramètre MultiSubNetFailover , ajoutez le paramètre MultiSubNetFailover à votre chaîne de connexion et la valeur true.
  • Pour résoudre ce problème lorsque vos clients hérités ne peuvent pas utiliser la propriété MultiSubnetFailover , vous pouvez modifier la valeur de RegisterAllProvidersIP de l'écouteur à 0. Pour ce faire, exécutez la commande suivante à partir de l'interface de ligne de commande de Windows PowerShell :
    Module d'importation FailoverClusters
    Get-ClusterResource, le nom de votre écouteur> | Set-ClusterParameter RegisterAllProvidersIP 0

    Démo
Remarque Après avoir défini la valeur de RegisterAllProvidersIP sur 0, l'adresse IP en ligne doit être désinscrit du serveur DNS et l'adresse IP en mode hors connexion doit être inscrit dans 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 port d'écoute est défini sur plusieurs sous-réseaux, l'opération peut échouer si le pilote client essaie de se connecter à l'aide d'une des adresses IP en mode hors connexion de l'écouteur.

Lors de la création d'un port d'écoute, une adresse IP est désignée pour chaque sous-réseau unique hébergé dans un réplica de groupe de disponibilité. Par exemple, si un écouteur est créé pour un groupe de disponibilité qui contient les réplicas qui existent dans les deux sous-réseaux, deux adresses IP sont définies dans le port d'écoute. 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.

Dans les coulisses, le récepteur crée un « Point d'accès Client » ressource de cluster de Windows. L'une de ses propriétés est RegisterAllProvidersIP. Lors de la création d'un port d'écoute, ce paramètre est défini sur 1, et les adresses IP de tous les l'écouteur sont enregistrés dans le serveur DNS. Cette configuration offre des 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 paramètre MultiSubnetFailoverpermet au pilote de client essayer de connexions en parallèle à des adresses IP de tous les l'écouteur. Sans le paramètre MultiSubnetFailover, le pilote client essaient de se connecter successivement à toutes les adresses IP pour l'écouteur. Connexions séquentielles peuvent provoquer une ouverture de session long les délais d'expiration de délai ou d'ouverture de session.

Remarque Le problème qui est mentionné dans cet article affecte également les environnements Microsoft SharePoint qui sont configurés pour utiliser le réplica d'un groupe de disponibilité AlwaysOn en lecture seule secondaire. Pour résoudre ce problème, procédez selon la valeur des actions suivantes s'applique à votre version de SharePoint :
  • Pour Microsoft SharePoint 2007 : This est classée comme une application héritée. Par conséquent, SharePoint 2007 ne peut pas être configuré pour utiliser le paramètre MultiSubnetFailover . Au lieu de cela, vous devez utiliser la commande Windows PowerShell qui est décrite dans la section « Résolution ».
  • Pour Microsoft SharePoint 2010 : Les packages de mise à jour Cumulative sont désormais disponibles qui ajoutent la prise en charge pour le paramètre MultiSubnetFailover . Pour plus d'informations sur les packages de mise à jour, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
    2654347 Une mise à jour prend en charge les fonctionnalités AlwaysOn de SQL Server 2012 pour le.NET Framework 3.5 SP1
    2687557 Description du package de correctifs pour SharePoint Foundation 2010 (Wss-x-none.msp): le 30 octobre 2012.
Pour plus d'informations sur les problèmes de délai d'expiration d'ouverture de session lorsque vous spécifiez le paramètreMultiSubnetFailover, accédez à l'article suivant de la Base de connaissances Microsoft :
2855417 Expiration de connexion lorsque vous utilisez un écouteur de groupe de disponibilité AlwaysOn avec paramètre de MultiSubnetFailover
Pour plus d'informations sur l'utilitaire SQLCMD, reportez-vous au site Web MSDN suivant :Pour plus d'informations sur le pilote SqlClient, accédez au site Web MSDN suivant :Pour plus d'informations sur une mise à jour introduit la prise en charge des fonctionnalités AlwaysOn de SQL Server 2012 pour le.NET Framework 3.5 SP1, cliquez sur le numéro ci-dessous pour afficher l'article dans l'article de la Base de connaissances Microsoft :
2654347 Une mise à jour prend en charge les fonctionnalités AlwaysOn de SQL Server 2012 pour le.NET Framework 3.5 SP1
Pour plus d'informations sur la prise en charge de pilote pour le basculement de plusieurs sous-réseaux, consultez le « 5.7.1 connectivité Client pour les groupes de disponibilité AlwaysOn "section du site Web MSDN suivant :Pour plus d'informations sur la façon de créer ou de configurer un écouteur de groupe de disponibilité, consultez le site Web Microsoft suivant :Pour plus d'informations sur une connexion secondaire lisible des erreurs lors de l'ouverture de session ID de sécurité (SID) sont différents ou absents, accédez au blog suivant de Microsoft :Pour plus d'informations sur les sous-réseaux multiples de SQL Server mise en clusters, consultez le site Web MSDN suivant :


Un billet de blog détaillées de toujours prise en charge de l'association à ce sujet et des questions connexes, veuillez consulter le lien suivant :

http://blogs.msdn.com/b/alwaysonpro/archive/2014/06/03/Connection-Timeouts-in-multi-Subnet-Availability-Group.aspx

Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés dans la section « S'applique à ».

Avertissement : cet article a été traduit automatiquement

Propriétés

ID d'article : 2792139 - Dernière mise à jour : 03/23/2016 00:27:00 - Révision : 8.0

Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Web, Microsoft SQL Server 2012 Enterprise Core

  • kbsurveynew kbtshoot kbexpertiseadvanced kbmt KB2792139 KbMtfr
Commentaires