Tout ce que vous devez savoir sur NLB

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

How to deploy a Secure Socket Tunneling Protocol (SSTP)-based VPN server that uses Network Load Balancing (NLB) in Windows Server 2008

An update enables multicast operations for ISA Server integrated NLB

Windows Server 2008 Hyper-V virtual machines generate a Stop error when NLB is configured or when the NLB cluster does not converge as expected

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

How NLB Hosts Converge When Connected to a Layer 2 Switch

Windows Server 2003-based NLB nodes in an NLB cluster cannot communicate with each other over an NLB network adapter

Servers in a Network Load Balancing (NLB) failover cluster cannot be used as print servers in Windows Server 2008

Network Load Balancing (NLB) clients cannot connect to the Windows Server 2008 NLB cluster by using the virtual IP address when NLB is running in multicast mode

The virtual IP address of a Windows Server 2008 NLB cluster is bound to the NetBIOS host name of a particular server or of multiple servers