La technologie NLB (Network Load Balacing) de Microsoft a l’avantage d’être intégrée directement avec le système d’exploitation. Comme son nom l’indique, est permet de répartir la charge sur plusieurs noeuds, qui sont membre de la ferme (cluster). La mise en route est très simple en apparence, mais il y a cependant plusieurs points à ne pas négliger, sous peine d’avoir l’impression que tout va bien sans que ca soit le cas…
Impact sur le réseau
NLB peut fonctionner dans deux modes:
- Unicast
- Multicast (avec ou sans IGMP)
Lequel choisir ? Ca dépend! Les variables à prendre en compte pour faire son choix:
- Quelle application sera accédée via la ferme? Est-ce qu’elle supporte les deux modes ? Par exemple, ISA 2006 avant le Service Pack 1 ne supportait que Unicast (un hotfix était aussi possible mais plus confidentiel)
- Combien de cartes réseaux ont les membres de la ferme ? Unicast va exiger 2 cartes réseaux minimum pour être à l’état de l’art
- Est-ce que les noeuds doivent pouvoir communiquer entre eux ?
- Est-ce que l’IGMP multicast est actif sur les switchs ? il permet de ne pas flooder le réseau inutilement
- Certains switchs (Cisco par exemple) n’apprécie pas du tout de voir la même adresse mac depuis chaque membre de la ferme. Il faut alors transformer le switch en hub, en envoyant tous les paquets réseaux à destination de l’adresse mac virtuelle à l’ensemble des noeuds.
Supervision et disponibilité
Il est vrai que si un noeud disparait du réseau, les autres prennent la relève. Mais on entend par là une coupure franche. Si vous avez 2 serveurs dans la ferme, et que vous arrêtez votre application métier sur un noeud, il continuera à recevoir autant de requête que l’autre, et il y aura donc la moitié des utilisateurs « dans le vent ». NLB travaille au niveau 3 (IP), et n’a pas conscience de ce qui ce passe plus haut, au niveau applicatif. Même si le port TCP n’est plus écouté, il n’en aura pas conscience. C’est le grand point faible de NLB. Microsoft incluait sentinel dans le resource kit. Il permettait de tester une page web sur chaque noeud et de le sortir de la ferme en cas de problème. ISA 2006 gère le NLB est peut sortir de la ferme en cas de problème dans ISA. Pour le reste, c’est à vous de combler le manque. S’il s’agit d’un site Web sous IIS, vous pouvez modifierLoadBalancerCapabilities dans la metabase de IIS afin de remplacer un 503 par un reset TCP. Le client va ainsi recommencer la requête et aller sur un autre serveur.
Pour combler le manque, vous pouvez utiliser votre solution de supervision (ou un script en boucle sur chaque nœud). L’idée est de tester chaque noeud d’un point de vue applicatif, et de le sortir de la ferme en cas d’erreur. Cela implique plusieurs éléments à étudier:
- Il faut vérifier très régulièrement chaque nœud sans générer de surcharge. L’idéal est d’avoir la supervision prévue dans l’application, par exemple en appelant une page web spécialement prévue à cet effet, qui test les composants applicatif et renvoi directement un code.
- La supervision devient active (elle va agir directement sur la production)
La solution SCOM prends alors de l’intérêt, notamment via l’implémentation de trigger sur évènement (eventlog, fichier de log…)
NLB versus MSCS ?
Un cluster MSCS est prévu pour être actif/passif. A un instant T, les ressources sont sur un seul serveur, qui doit donc pouvoir supporter toute la charge. Il a l’avantage de pouvoir gérer des données partagées (espaces disques), et de pouvoir superviser des ressources (état de services Windows). Là aussi, cela ne couvre pas l’application dont le service Windows est bien démarré, mais qui ne fonctionne plus (perte de l’accès à la base de données..).
Autre solution ?
- J’ai déjà mis en place du Safekit de Evidian sur Windows. Cette solution est pas trop mal, mais les vérifications applicatifs sont là aussi complètement à votre charge.
- Répartiteur de charge sous forme d’appliance (F5, Alteon…): ils peuvent faire des vérifications applicatives, mais surtout appeler une page Web pour savoir si le nœud est opérationnel ou non.
- Rester avec un seul nœud ?
KB/Articles:
IIS Responses to Load-Balanced Application Pool Behaviors
NLB Operations Affect All Network Adapters on the Server
Unicast NLB nodes cannot communicate over an NLB-enabled network adaptor in Windows Server 2003
The « NLB troubleshooting overview for Windows Server 2003 » article is available
An update enables multicast operations for ISA Server integrated NLB
Terminal Services Client Cannot Connect to NLB Cluster TCP/IP Address
The NLB WMI Provider Generates a Lot of Error Entries in the Wbemcore.log File
