Échec de la transaction dissortingbuée avec Windows Server 2008

J'ai un problème avec une nouvelle configuration de server. Les transactions dissortingbuées lancées par le server d'applications sur le nouveau server échouent, mais elles fonctionnent bien avec un server de database existant. J'ai besoin d'aide pour déterminer la cause du problème.

Pour diverses raisons, le nouveau server n'utilise pas les dernières versions de Windows ou SQL Server.

Installer

SERVEUR D'APPLICATION

  • OS: Windows Server 2008 R2
  • Nom NetBIOS: WEB-02
  • Configuré pour parler à plusieurs servers de database, certains locaux, certains distants.
  • Ports DCOM restreints à une gamme de 5000 à 5020 pour parler par firewall à des servers distants.
  • Pare-feu Windows activé
  • properties DTC
    • Réseau Accès DTC vérifié
    • Autoriser les clients distants, autoriser l'administration à distance non contrôlée
    • Gestionnaire de transactions Communication
      • Autoriser Inbound, Allow Outbound checked
      • Aucune authentification requirejse
    • Activez XA Transactions non activé
    • Activer SNA LU 6.2 Transactions vérifiées

NOUVEAU SERVEUR DE BASE DE DONNÉES

  • OS: Windows Server 2008
  • Nom NetBIOS: DB-06
  • SQL Server 2005
  • Aucune ressortingction sur les ports DCOM
  • Pare-feu Windows désactivé
  • properties DTC
    • Réseau Accès DTC vérifié
    • Autoriser les clients distants non contrôlés,
    • Autoriser l'administration à distance vérifiée
    • Gestionnaire de transactions Communication
      • Autoriser Inbound, Allow Outbound checked
      • Aucune authentification requirejse
    • Activez XA Transactions non activé
    • "Activer SNA LU 6.2 Transactions" n'existe pas

SERVEUR DE BASE DE DONNÉES EXISTANTE

  • OS: Windows Server 2003 R2
  • Nom NetBIOS: DB-04
  • SQL Server 2005
  • Aucune ressortingction sur les ports DCOM
  • Pare-feu Windows désactivé
  • properties DTC
    • Réseau Accès DTC vérifié
    • Autoriser les clients distants non contrôlés,
    • Autoriser l'administration à distance vérifiée
    • Gestionnaire de transactions Communication
      • Autoriser Inbound, Allow Outbound checked
      • Aucune authentification requirejse
    • Activez XA Transactions non activé
    • "Activer SNA LU 6.2 Transactions" n'existe pas

Les trois servers font partie du même domaine et se trouvent sur le même sous-réseau. Seul un commutateur Ethernet est entre eux, aucun routeur, pare-feu matériel, ni périphérique de security.

Problème

Une application ASP.NET s'exécute sur le server d'applications et fonctionne correctement lors de l'exécution d'une transaction par rapport au server de database existant (DB-04). Lors de l'exécution des mêmes étapes par rapport au nouveau server de database (DB-06), il échoue et signale le message d'erreur: la Communication with the underlying transaction manager has failed.

Étapes de dépannage

Nous avons déjà vu cette erreur avec cette application, et cela signifie normalement que le Coordinateur des transactions dissortingbuées n'est pas configuré correctement ou qu'un pare-feu interfère. Dans le passé, j'ai utilisé DTCPing pour dépanner et corriger toutes les erreurs.

Cette fois-ci, cependant, bien que le DTCPing échoue, je ne peux pas déterminer la cause du problème, car les servers de database existants et les nouveaux servers semblent être configurés de la même manière, à l'exception de la version du operating system.

Ce qui suit provient du file journal DTCPing lors de l'exécution d'un test du server d'applications (WEB-02) au nouveau server de database (DB-06). Notez que j'ai changé les adresses IP et les noms DNS.

À partir du file journal sur le server d'applications

 10-14, 16:08:11.346-->Error(0x424) at clutil.cpp @256 10-14, 16:08:11.346-->-->OpenCluster 10-14, 16:08:11.346-->-->1060(The specified service does not exist as an installed service.) ++++++++++++++++++++++++++++++++++++++++++++++ DTCping 1.9 Report for WEB-02 ++++++++++++++++++++++++++++++++++++++++++++++ Firewall Port Settings: Port:5000-5020 RPC server is ready ++++++++++++Validating Remote Computer Name++++++++++++ 10-14, 16:08:22.796-->Start DTC connection test Name Resolution: DB-06-->1.1.1.6-->s6.mydomain.com 10-14, 16:08:22.812-->Start RPC test (WEB-02-->DB-06) RPC test failed 

Du file journal sur le nouveau server de database

 10-14, 16:07:46.128-->Error(0x424) at clutil.cpp @256 10-14, 16:07:46.128-->-->OpenCluster 10-14, 16:07:46.129-->-->1060(The specified service does not exist as an installed service.) ++++++++++++++++++++++++++++++++++++++++++++++ DTCping 1.9 Report for DB-06 ++++++++++++++++++++++++++++++++++++++++++++++ RPC server is ready 10-14, 16:08:22.785-->RPC server:DB-06 received following information: Network Name: DB-06 Source Port: 56535 Partner LOG: WEB-022872.log Partner CID: 1ACD8780-9446-4E94-869D-6F1BDF787BBF 

Après avoir cliqué sur PING sur le server de database, ce qui suit est ajouté au file journal. Dans la window de sortie, il y a une pause entre l'appel de la méthode RPC et l'échec, donc il échoue après un timeout d'attente.

 ++++++++++++Validating Remote Computer Name++++++++++++ 10-14, 16:13:18.924-->Start DTC connection test Name Resolution: Web-02-->1.1.1.2-->web-02.mydomain.com 10-14, 16:13:18.933-->Start RPC test (DB-06-->Web-02) Problem:fail to invoke remote RPC method Error(0x6D9) at dtcping.cpp @303 -->RPC pinging exception -->1753(There are no more endpoints available from the endpoint mapper.) RPC test failed 

Comme expliqué dans Dépannage des problèmes MSDTC avec l'outil DTCPing sous la section "ERREUR MESSAGE 4 – Il n'y a plus de points d'extrémité du mappeur de point final", il existe en fait plus de points d'extrémité pour le mappeur. J'ai exécuté netstat -an sur le server d'application (celui avec des ports restreints) et il utilise uniquement 10 des 20 ports disponibles.

Après avoir impliqué Microsoft et de nombreuses traces réseau ont été analysées, nous avons finalement analysé le problème. Le server d'application faisait partie d'un cluster d'équilibrage de charge réseau et il y a un problème dans la façon dont l'implémentation IPv6 sur Windows Server 2008 R2 interagit avec le composant Network Load Balancing.

Étant donné que les servers avaient des adresses IPv4 publiquement routables, la stack IPv6 a automatiquement créé une adresse "6to4". Il s'agit d'une adresse IPv6 spéciale qui correspond à l'adresse IPv4 roulante publiable de la machine. Il l'a fait pour l'adresse de la machine aussi bien que pour l'adresse du cluster partagé. Le défaut est qu'il enregistre les deux adresses 6to4 dans DNS sous son propre nom. Ceci est différent de la façon dont la stack IPv4 fonctionne sur la même machine. Avec IPv4, l'adresse IP du cluster n'est pas enregistrée dans DNS.

Il en résulte que lorsque le server d'applications connecté au nouveau server de database et au server de database a tenté de faire le lien inverse avec le server d'application, il verrait qu'il y avait des adresses IPv6 pour le server d'applications et tenté de se connecter à l'aide de l'une de ces adresses . Mais comme il utilisait l'adresse 6to4 correspondant à l'adresse IP du cluster , un autre server du cluster recevrait la connection et, comme DTC sur ce server ne s'attendait pas à une binding inverse, il a échoué.

Le server de database existant, étant Windows Server 2003 R2, n'a pas utilisé IPv6 et n'a donc pas rencontré le problème.

La solution était de désactiver la génération automatique de l'adresse 6to4. Vous pouvez le faire via une stratégie de groupe ou en utilisant la command line suivante:

 netsh interface 6to4 set state disabled 

Pour le réactiver, vous devez exécuter la command suivante:

 netsh interface 6to4 set state default 

Pour voir les parameters actuels, exécutez la command suivante. Sur Windows 2008 R2 / Windows 7 et versions ultérieures, il indiquera également si le paramètre actuel est dû à une stratégie de groupe.

 netsh interface 6to4 show state