gethostbyname() ne retourne pas façon cohérente les adresses IP virtuelles de cluster

Traductions disponibles Traductions disponibles
Numéro d'article: 257577 - Voir les produits auxquels s'applique cet article
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Agrandir tout | Réduire tout

Symptômes

Si votre programme utilise la fonction gethostbyname, la liste d'adresses IP retournée ne comprend pas les adresses IP virtuelles créés par le service de cluster, ou il peut répertorier les adresses IP qui ne sont pas actuellement détenus par ce n?ud.

Cause

Lorsque le service de cluster ajoute ou supprime une adresse IP virtuelle, il est possible que le protocole TCP/IP ne met pas à jour le cache à partir de laquelle il retourne les adresses IP.

Résolution

Pour résoudre ce problème, procurez-vous le dernier service pack pour Windows 2000. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la base de connaissances Microsoft :
260910Comment faire pour obtenir le dernier Service Pack de Windows 2000
La version anglaise de ce correctif doit avoir les attributs de fichier suivants ou ceux d'une version ultérieure :
Nom de fichier : Q257577_w2k_sp2_x86_en.exe
Version : 1.10.101.0
Ce paquet inclut les versions mises à jour de :
Clusres.dll
Dnsapi.dll

Statut

Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés au début de cet article. Ce problème a été corrigé dans Windows 2000 Service Pack 2.

Plus d'informations

Dans Windows NT 4.0, gethostbyname(local node name) retourné une liste contenant toutes les adresses IP instanciés sur le serveur, y compris les adresses IP virtuelles de cluster. Dans Windows 2000, la même opération retourne généralement uniquement les adresses IP sont définitivement affectés au serveur ; toutefois, il peut parfois renvoyer l'ensemble de la liste tout comme Windows NT 4.

Le changement de comportement est un effet secondaire de la mise en oeuvre du service de résolution DNS. Le programme de résolution met en cache la liste d'adresses IP locales au démarrage. Lorsqu'il doit résoudre le nom de n?ud local, elle renvoie la liste à partir de sa mémoire cache au lieu de consulter un serveur DNS. Le problème est que le programme de résolution n'écoute pas pour les notifications de modifications d'adresse PNP à partir de la pile TCP, mais elle reçoit ces notifications à partir du client DHCP. Lorsque le programme de résolution reçoit une notification de modification du serveur DHCP, il met à jour sa liste en cache des adresses IP locales en interrogeant la pile TCP. Le résultat est que lorsque clustering instancie une nouvelle adresse, le résolveur de ne pas en savoir plus sur elle, sauf si / tant qu'une modification ultérieure de l'adresse DHCP ne se produit. Cela vaut aussi pour les adresses de cluster sont supprimées. Dans la mesure où les modifications d'adresses DHCP sont rares, gethostbyname exclut généralement adresses IP du cluster lors de la résolution du nom de n?ud local.

Dans Windows 2000, MSMQ est parvenu à varient selon le nouveau comportement dans son scénario actif/actif dans un cluster et est rompue, par conséquent, avec le comportement du correctif. MSMQ utilise RPC pour les communications client/serveur. Au démarrage dans le processus du serveur, RPC utilise gethostbyname pour déterminer la liste des adresses IP à écouter sur. Dans sa configuration actif/actif, un processus de serveur MSMQ est associé au nom du n?ud local, alors qu'un autre est associé à un serveur virtuel de cluster. Si gethostbyname renvoie le serveur virtuel d'adresse IP au processus associé au nom de n?ud local, puis les deux processus seront à l'écoute de cette adresse. Il en résulte que les clients tentant de se connecter au processus du serveur virtuel peuvent être connectés par erreur au processus du n?ud local. Par conséquent, MSMQ dépend du fait que les adresses IP du cluster virtuels habituellement ne sont pas retournés par gethostbyname lors de la résolution le nom du n?ud local.

Propriétés

Numéro d'article: 257577 - Dernière mise à jour: samedi 1 février 2014 - Version: 2.4
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
Mots-clés : 
kbnosurvey kbarchive kbmt kbhotfixserver kbqfe kbbug kbfix KB257577 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 257577
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com