Cette section répertorie certains problèmes courants que vous pouvez rencontrer lorsque vous utilisez des clusters d’équilibrage de la charge réseau (clusters NLB).

Quels sont les problèmes rencontrés ?

Après l’installation de l’équilibrage de la charge réseau et le redémarrage d’un hôte du cluster, un message s’affiche : « Le système a détecté un conflit d’adresse IP avec un autre système sur le réseau... »
  • Cause : La même adresse IP existe déjà sur le réseau.

  • Solution : Choisissez une nouvelle adresse IP ou supprimez l’adresse en double.

  • Cause : Vous avez configuré des modes d’opération du cluster différents (Monodiffusion ou Multidiffusion) sur les hôtes, ce qui crée deux adresses MAC différentes à mapper vers la même adresse IP.

  • Solution : Vérifiez que tous les hôtes sont configurés avec le même mode d’opération du cluster.

  • Cause : Vous avez configuré l’adresse IP du cluster avant de lier NLB à la carte réseau.

  • Solution : Supprimez l’adresse IP du cluster des propriétés TCP/IP, activez NLB sur la carte appropriée, puis configurez l’adresse IP du cluster.

  • Cause : Vous avez ajouté l’adresse IP du cluster à une carte réseau qui n’a pas été activée pour l’équilibrage de la charge réseau.

  • Solution : Supprimez l’adresse IP du cluster des propriétés TCP/IP de la carte inappropriée, activez NLB sur la carte appropriée, puis configurez l’adresse IP du cluster.

Pour plus d’informations sur l’activation de NLB, voir Installation de l’équilibrage de la charge réseau

Vous n’obtenez aucune réponse lorsque vous utilisez une commande ping pour accéder à l’adresse IP du cluster à partir d’un réseau externe.

Vérifiez que vous pouvez utiliser la commande ping pour accéder aux adresses IP dédiées des hôtes du cluster à partir d’un ordinateur situé à l’extérieur du routeur. Si ce test échoue, et que vous utilisez plusieurs cartes réseau, le problème n’est pas lié à NLB. Si vous utilisez une seule carte réseau pour les adresses IP dédiées et du cluster, examinez les causes suivantes :

  • Cause : Si vous utilisez la prise en charge de la multidiffusion, vous vous rendrez peut-être compte que votre routeur rencontre des difficultés à résoudre l’adresse IP principale en adresse de contrôle d’accès au média (MAC, Media Access Control) de multidiffusion à l’aide du protocole ARP (Address Resolution Protocol).

  • Solution : Vérifiez que vous pouvez utiliser la commande ping pour accéder au cluster à partir d’un client situé sur le sous-réseau du cluster et pour accéder aux adresses IP dédiées des hôtes du cluster à partir d’un ordinateur situé à l’extérieur du routeur. Si ces tests fonctionnent correctement, le routeur est probablement fautif. Vous devriez être en mesure d’ajouter une entrée ARP statique au routeur pour contourner le problème. Vous pouvez également désactiver la prise en charge de la multidiffusion NLB et utiliser une adresse réseau de monodiffusion sans concentrateur.

  • Cause : Lorsque vous utilisez NLB en mode de multidiffusion ou de monodiffusion, les routeurs doivent accepter des réponses ARP proxy (mappages d’adresses IP à réseau reçus avec une adresse source de réseau différente dans la trame Ethernet).

  • Solution : Vérifiez que la prise en charge ARP proxy est activée dans votre routeur. Vous pouvez également définir une entrée ARP statique pour laisser la prise en charge ARP proxy désactivée dans le routeur.

  • Cause : Le trafic ICMP (Internet Control Message Protocol) vers le cluster est bloqué par un routeur ou un pare-feu.

  • Solution : Autorisez le trafic ICMP via le routeur ou le pare-feu. Sachez que cette autorisation risque d’exposer votre système à un risque supplémentaire pour la sécurité.

Vous n’obtenez aucune réponse lorsque vous utilisez une commande ping pour accéder aux adresses IP dédiées d’un hôte à partir d’un autre hôte du cluster.
  • Cause : Lorsque vous utilisez NLB en mode de multidiffusion ou de monodiffusion, les routeurs doivent accepter des réponses ARP proxy (mappages d’adresses IP à réseau reçus avec une adresse source de réseau différente dans la trame Ethernet).

  • Solution : Vérifiez que la prise en charge ARP proxy est activée dans votre routeur. Vous pouvez également définir une entrée ARP statique pour laisser la prise en charge ARP proxy désactivée dans le routeur.

  • Cause : Le trafic ICMP (Internet Control Message Protocol) vers le cluster est bloqué par un routeur ou un pare-feu.

  • Solution : Autorisez le trafic ICMP via le pare-feu ou le routeur. Sachez que cette autorisation risque d’exposer votre système à un risque supplémentaire pour la sécurité.

Lorsque vous essayez d’utiliser le Gestionnaire d’équilibrage de la charge réseau pour vous connecter à un hôte de votre cluster, vous recevez le message d’erreur « Hôte inaccessible ».
  • Cause : Le trafic ICMP (Internet Control Message Protocol) vers l’hôte est soit bloqué par un routeur ou un pare-feu, soit désactivé sur la carte réseau de l’hôte.

  • Solution : Activez le protocole ICMP sur la carte réseau de l’hôte ou autorisez le trafic ICMP via le pare-feu ou le routeur. Sachez que cette autorisation risque d’exposer votre système à un risque supplémentaire pour la sécurité. Vous pouvez également utiliser l’option /noping du Gestionnaire NLB.

Lorsque vous utilisez Telnet ou essayez de parcourir un ordinateur situé à l’extérieur du cluster à partir d’un hôte du cluster, vous n’obtenez aucune réponse.
Lorsque vous appelez des commandes de contrôle à distance de l’équilibrage de la charge réseau à partir d’un ordinateur situé à l’extérieur du cluster, vous n’obtenez aucune réponse d’un ou de plusieurs hôtes du cluster.
  • Cause : Les commandes de contrôle à distance ne sont pas envoyées à l’adresse IP du cluster.

  • Solution : Les commandes doivent être envoyées à l’adresse IP principale du cluster, qui a été attribuée dans la boîte de dialogue Propriétés de l’équilibrage de la charge réseau. Vérifiez que vous envoyez les commandes à distance à l’adresse IP correcte.

  • Cause : Le trafic de contrôle à distance est chiffré par IPSec (Internet Protocol Security). Les commandes de contrôle à distance NLB ne fonctionnent pas correctement si elles sont envoyées à partir d’un ordinateur sur lequel IPSec est configuré afin que le trafic de contrôle à distance soit chiffré par IPSec.

  • Solution : Désactivez IPSec.

    Pour plus d’informations, voir le contenu de l’aide d’IPSec (Internet Protocol Security).

  • Cause : Les ports de contrôle UDP de NLB sont protégés de manière incorrecte par un pare-feu. Par défaut, les commandes de contrôle à distance sont envoyées aux ports UDP 1717 et 2504 au niveau de l’adresse IP du cluster.

  • Solution : Vérifiez que ces ports n’ont pas été bloqués de manière incorrecte par un routeur ou un pare-feu. Vous pouvez également modifier le numéro de port en modifiant le paramètre NLB correspondant.

Vous n’obtenez aucune réponse lorsque vous utilisez l’adresse IP dédiée d’un hôte pour la spécifier en tant que cible d’une commande de contrôle à distance. En revanche, lorsque vous spécifiez l’hôte par sa priorité (son identificateur), cela fonctionne.
La connectivité au cluster est refusée à certains utilisateurs, mais pas à tous.
  • Cause : Une application dont la charge est en cours d’équilibrage ne répond pas.

  • Solution : Il s’agit d’un problème propre à l’application qui n’est pas lié à NLB. Reportez-vous à la documentation de votre application pour corriger ce problème. Vous devrez peut-être arrêter et redémarrer l’application.

  • Cause : Si votre cluster est configuré pour le mode de monodiffusion, un commutateur a peut-être appris l’adresse MAC de la carte réseau NLB.

  • Solution : Désactivez le port du commutateur vers le mappage d’adresse MAC.

  • Cause : L’adresse IP du cluster n’a pas été ajoutée à TCP/IP sur un ou plusieurs hôtes.

  • Solution : Si vous n’utilisez pas le Gestionnaire NLB pour configurer votre cluster, vous devez configurer manuellement TCP/IP avec l’adresse IP du cluster.

  • Cause : Un hôte quitte le cluster en raison d’une commande drainstop ou stop, mais la convergence ne s’est pas terminée correctement.

  • Solution : Patientez jusqu’à ce que la convergence soit terminée. Si elle ne se termine pas, reportez-vous au problème suivant décrit ultérieurement dans la présente rubrique de résolution des problèmes :

    À l’issue de leur démarrage, les hôtes du cluster commencent à converger, mais ils n’achèvent jamais la convergence.

Vous ne pouvez pas afficher ou modifier les propriétés de l’équilibrage de la charge réseau à l’aide de net config et de WMI (Windows Management Instrumentation).
  • Cause : Pour afficher ou modifier les Propriétés de l’équilibrage de la charge réseau, vous devez être membre du groupe Administrateurs.

  • Solution : Ouvrez une session en tant qu’utilisateur appartenant au groupe Administrateurs local de l’ordinateur qui exécute NLB.

Un nombre inhabituel de connexions TCP à l’adresse IP du cluster est réinitialisé par le serveur ou le client.
  • Cause : Les valeurs persistantes HTTP sont activées sur les hôtes NLB et des clients activés pour les valeurs persistantes se connectent au cluster.

  • Solution : Désactivez les valeurs persistantes HTTP. Pour plus d’informations sur les valeurs persistantes HTTP et IIS (Internet Information Services), voir l’ensemble de la documentation IIS.

    Pour afficher l’ensemble de documentation IIS à partir de votre Bureau, installez IIS, puis cliquez sur Démarrer, cliquez sur Exécuter, puis tapez la commande suivante dans la zone de texte Ouvrir :

    %windir%\help\iisrv.chm

  • Cause : Des ressources système faibles sur le serveur provoquent le rejet des connexions par TCP.

  • Solution : Libérez des ressources système, par exemple, en ajoutant de la mémoire système supplémentaire ou en fermant les applications inutiles.

  • Cause : Le cluster a divergé en deux clusters convergés séparément, si bien que plusieurs nœuds revendiquent la propriété de chaque connexion.

  • Solution : Supprimez les deux clusters, puis recréez un seul cluster.

Les appels de réseau privé virtuel (VPN) échouent lorsque vous apportez une modification qui provoque une convergence (telle que l’ajout d’un hôte, la suppression d’un hôte ou le drainage d’un hôte).
  • Cause : Lorsque vous utilisez l’équilibrage de la charge réseau pour équilibrer la charge d’un trafic VPN, vous devez configurer les règles de port qui régissent les ports qui traitent le trafic VPN (port TCP 1723 pour PPTP/GRE et port UDP 500 pour IPSEC/L2TP) afin d’utiliser soit l’affinité Unique, soit l’affinité Réseau.

  • Solution : Configurez les règles de port qui régissent les ports 500 et 1723 afin d’utiliser une affinité Unique ou Réseau. Pour plus d’informations, voir Propriétés du Gestionnaire d’équilibrage de la charge réseau.

À l’issue de leur démarrage, les hôtes du cluster commencent à converger, mais ils n’achèvent jamais la convergence.
  • Cause : Vous avez entré un nombre différent de règles de port ou des règles de port incompatibles sur différents hôtes de cluster. Cela a pour effet d’empêcher la convergence.

  • Solution : Ouvrez la boîte de dialogue Propriétés de l’équilibrage de la charge réseau sur chaque hôte du cluster et vérifiez que tous les hôtes ont des règles de port identiques.

  • Cause : Votre carte réseau ou votre câble sont défectueux.

  • Solution : Utilisez la commande ping pour tester la connectivité. Entrez le nom de domaine pleinement qualifié de l’hôte. Vous pouvez également en savoir plus sur ce problème en utilisant la commande ping pour faire une recherche dans votre contrôleur de domaine par adresse IP et sur d’autres serveurs réseau par nom et adresse IP.

  • Cause : Des paramètres de duplex définis sur un commutateur ou concentrateur sont incompatibles.

  • Solution : Vérifiez que les paramètres de duplex définis sur chacun de vos commutateurs et concentrateurs sont configurés de manière appropriée.

  • Cause : L’adresse IP dédiée que vous avez utilisée pour l’un des hôtes existe déjà sur le réseau.

  • Solution : Choisissez une nouvelle adresse IP ou supprimez l’adresse en double.

  • Cause : Votre cluster contient des hôtes qui exécutent Windows 2000.

  • Solution : Votre cluster doit exécuter Windows Server 2008 sur tous les hôtes. Un environnement en clusters NLB qui contient des hôtes avec Windows Server 2003 et Windows Server 2008 est pris en charge uniquement lorsque vous effectuez une mise à niveau propagée vers Windows Server 2008. L’association de Windows Server 2003 et Windows Server 2008 dans le même cluster n’est pas prise en charge pendant de longues périodes.

  • Cause : Vous avez configuré des modes d’opération du cluster différents (monodiffusion et multidiffusion) sur les hôtes.

  • Solution : Utilisez le Gestionnaire NLB pour vérifier que tous les hôtes sont configurés avec le même mode d’opération du cluster.

Remarques

Vous pouvez également afficher les journaux des événements de Windows pour rechercher des erreurs et des avertissements. Pour plus d’informations, voir Installation de l’équilibrage de la charge réseau.

Le cluster adopte et quitte un état convergé.
  • Cause : Des pulsations sont manquées en raison d’une connectivité réseau intermittente engendrée par une carte réseau ou un câble défectueux ou par d’autres problèmes réseau.

  • Solution : Utilisez la commande ping pour tester la connectivité. Entrez le nom de domaine complet de l’hôte. Vous pouvez également en savoir plus sur ce problème en utilisant la commande ping pour faire une recherche dans votre contrôleur de domaine par adresse IP et sur d’autres serveurs réseau par nom et adresse IP.

À l’issue du démarrage des hôtes du cluster, l’équilibrage de la charge réseau indique que la convergence est terminée, mais plusieurs hôtes correspondent à l’hôte par défaut.
  • Cause : Les hôtes du cluster sont devenus membres de différents sous-réseaux ; par conséquent, tous les hôtes ne sont pas accessibles sur le même réseau.

  • Solution : Vérifiez que toutes les hôtes du cluster peuvent communiquer entre eux.

  • Cause : Un commutateur de couche 3 est utilisé.

  • Solution : Placez un commutateur de couche 2 entre les hôtes et le commutateur de couche 3.

  • Cause : Une coupure dans un commutateur redondant a engendré la séparation du cluster en deux clusters, ce qui a créé deux hôtes par défaut.

  • Solution : Supprimez les deux clusters, puis créez un seul cluster.

  • Cause : Votre commutateur est configuré afin de rejeter les paquets de diffusion.

  • Solution : Configurez votre commutateur afin qu’il accepte les paquets de diffusion (sachez qu’une telle configuration risque d’engendrer certains risques pour la sécurité) ou configurez votre cluster NLB afin qu’il utilise le mode de multidiffusion.

  • Cause : Un hôte est incapable d’envoyer ou de recevoir des pulsations.

  • Solution : Utilisez la commande ping pour tester la connectivité avec chacun des hôtes. Entrez le nom de domaine pleinement qualifié des hôtes.

  • Cause : Un hôte est branché sur un mauvais port sur le commutateur.

  • Solution : Utilisez le port adéquat sur le commutateur.

L’équilibrage de la charge réseau n’équilibre pas la charge des applications et l’hôte par défaut traite tout le trafic réseau.
  • Cause : Il manque une règle de port. Par défaut, NLB dirige tout le trafic réseau entrant qui n’est pas régi par des règles de port vers l’hôte par défaut. De cette manière, les applications dont vous ne souhaitez pas équilibrer la charge se comportent correctement.

  • Solution : Pour équilibrer la charge d’une application à l’échelle de tout le cluster, créez une règle de port sur chaque hôte du cluster pour les ports TCP/IP desservis par l’application.

  • Cause : Vous avez ajouté un second hôte à un cluster à hôte unique, mais ce second hôte n’est pas configuré correctement. Le cluster ne converge jamais et l’hôte d’origine continue de traiter tout le trafic.

  • Solution : Vérifiez attentivement (et corrigez, si nécessaire) chacun des paramètres du second hôte, par exemple l’adresse IP du cluster, l’adresse IP dédiée et les règles de port.

  • Cause : Si votre cluster est configuré pour le mode de monodiffusion, un commutateur a peut-être appris l’adresse MAC de la carte réseau NLB.

  • Solution : Désactivez le port du commutateur vers le mappage d’adresse MAC.

  • Cause : Un serveur proxy envoie toutes les connexions qui utilisent une seule adresse IP à votre cluster en mode d’affinité unique.

  • Solution : Configurez votre serveur proxy afin qu’il utilise plusieurs adresses IP.

Le trafic alterne de manière inopinée entre les hôtes du cluster et il interrompt des connexions TCP.
  • Cause : Des adresses réseau de monodiffusion engendrent des problèmes avec le concentrateur à commutation. Si vous utilisez un concentrateur à commutation pour interconnecter les hôtes du cluster, vous devez utiliser la prise en charge de la multidiffusion NLB. Sinon, le commutateur peut se comporter de manière erratique lorsque le même réseau de monodiffusion est utilisé sur plusieurs ports commutés.

  • Solution : Vérifiez que vous avez sélectionné la prise en charge de la multidiffusion dans la boîte de dialogue Propriétés de l’équilibrage de la charge réseau. Si vous ne souhaitez pas l’utiliser, vous pouvez interconnecter les hôtes du cluster à l’aide d’un concentrateur ou d’un câble coaxial, plutôt qu’avec un commutateur.

Le trafic réseau ne semble pas équilibrer la charge de manière uniforme entre les hôtes du cluster.
  • Cause : Le trafic réseau provient d’un nombre limité d’adresses IP, vraisemblablement en raison d’un paramètre sur un serveur proxy.

  • Solution : Configurez votre serveur proxy afin qu’il utilise plusieurs adresses IP.

Lorsque vous utilisez l’équilibrage de la charge réseau avec Microsoft ISA (Internet Security and Acceleration) Server, un hôte du cluster enregistre les paquets bloqués qui sont dirigés vers l’adresse IP (Internet Protocol) dédiée d’un autre hôte.
Vous ne parvenez pas à créer un cluster d’équilibrage de la charge réseau dans un environnement de version 64 bits.
  • Cause : Vous n’exécutez peut-être pas la version de NLB appropriée à votre environnement. NLB ne peut pas former un cluster lorsque vous utilisez la version 32 bits sur un ordinateur de version 64 bits. Ce problème risque de ne pas avoir été détecté car les composants NLB 32 bits (nlb.exe, wlbs.exe et nlbmgr.exe) semblent s’exécuter correctement dans l’environnement de la version 64 bits.

  • Solution : Si vous envisagez d’utiliser un environnement version 64 bits, vous devez utiliser la version 64 bits de NLB.

Remarque
  •    Les rubriques suivantes décrivent plusieurs problèmes courants que vous risquez de rencontrer lorsque vous installez et commencez à utiliser NLB. Ces rubriques décrivent les raisons probables de chaque problème, puis suggèrent une ou plusieurs solutions. Elles supposent que votre système et vos applications respectent la configuration minimale requise pour NLB. Pour plus d’informations, voir : Vue d’ensemble de l’équilibrage de la charge réseau et Installation de l’équilibrage de la charge réseau.
  • Vous devez tester votre réseau et toutes les cartes réseau afin de vérifier leur bon fonctionnement avant d’installer NLB. Veillez à suivre les étapes d’installation, puis vérifiez que les paramètres de cluster et les règles de port sont définis de manière identique pour tous les hôtes du cluster. En cas de problème, recherchez toujours, dans le journal des événements de Windows, un message provenant du pilote NLB. Pour plus d’informations, voir les sections relatives aux paramètres de cluster, aux paramètres de l’hôte et aux règles de port dans Propriétés du Gestionnaire d’équilibrage de la charge réseau.

Table des matières