même adresse IP (par exemple derrière un parefeu avec du NAT), ils seront tous dirigés vers le même serveur, annulant ainsi la répartition de charge.
● Le mode d’opération du cluster :
● Monodiffusion (même adresse MAC sur tous les nœuds).
● Multidiffusion (adresse MAC unique par nœud).
● Multidiffusion IGMP (adresse MAC unique par nœud et inscription d’adresse IGMP).
● Le mode de filtrage :
● Hôte multiple (répartition de charge).
● Hôte unique (actif/passif).
● Aucun (bloquer le trafic correspondant à la règle).
● Le mode d’affinité (hôte multiple uniquement) :
● Aucune (envoi sur un nœud aléatoire). MAC n’est pas possible. NLB mitige ce point en activant la clé « MaskSourceMAC ». Le paquet arrive avec comme adresse MAC de destination celle du cluster, mais le nœud répond avec la sienne. Le switch ne peut donc pas assigner l’adresse MAC au nœud qui répond et continue à envoyer les paquets sur tout le réseau (inondation). Ce comportement est « by design ». Si ce mode est impératif (il l’était avec Microsoft ISA au départ), plusieurs contournements existent. Il est possible de mettre un hub entre les serveurs du cluster et le switch. De cette façon, le switch ne voit l’adresse MAC du cluster que depuis un seul port (pas de
« MaskSourceMac »), ce qui arrête l’inondation. Cela ne fait cependant pas parti des « meilleures pratiques ».
L’utilisation d’un commutateur de niveau 3 (routeur) n’est pas possible car tous les nœuds partagent la même adresse IP et le routeur envoie les paquets en fonction de l’adresse IP. Les serveurs ne peuvent pas communiquer entre eux, car ils ont la même adresse MAC. Les paquets sont renvoyés au serveur sans même quitter la carte réseau.
enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA8Mjg5MzAyIC0gYWRhbW8gZGlhcnJhIC0gMjU4ZThlZWQtN2NjNS00YTU2LThlODQtZjYwZWVhYWMyOThlNOiQEvunzogLAA==-enidentnumber
● Le mode multidiffusion règle le problème de l’adresse MAC en ajoutant une adresse MAC de type multidiffusion et en empêchant les équipements réseaux de mémoriser l’adresse MAC du cluster. Le switch envoie les paquets à l’ensemble des ports, dont ceux des nœuds du cluster. On se trouve toujours avec une inondation une adresse IP IGMP de classe D (de 224.0.0.0 à 239.255.255.255). Cela impose que les équipements réseaux supportent la multidiffusion IGMP, mais permet de régler le plus élégamment possible les différents problèmes. Chaque nœud a sa propre adresse MAC, l’adresse IP de multidiffusion et seulement les nœuds reçoivent le trafic réseau du cluster. qui a le plus petit ID actif. Le mode de filtrage Aucun permet quant à lui de bloquer le trafic sur certains ports, notamment pour protéger les nœuds.
En mode hôte multiple, trois choix d’affinité sont possibles :
● Aucun: à chaque connexion TCP d’un même client, celuici sera dirigé vers le nœud ayant le moins de clients.
Ce mode assure la meilleure répartition possible, surtout lorsqu’il n’y a pas de spécificité cliente à maintenir (panier, session...).
● Unique: permet de maintenir un client (son adresse IP) sur le même nœud tant que la topologie de la ferme n’est pas modifiée (ajout/suppression de nœud). Chaque client doit avoir une adresse IP unique afin d’avoir une répartition efficace (pas de Nat, de proxy...).
● Réseau: se comporte comme le filtrage précédent, mais au lieu d’utiliser directement l’adresse IP du client, il calcule l’adresse du réseau. Si par exemple un client se connecte avec l’adresse IP 192.168.1.1, NLB le transformera en 192.168.1.0. Tous les clients appartenant à cette classe C iront sur le même nœud. Ce filtrage est pertinent lorsqu’il faut maintenir un ensemble de clients venant d’un même réseau sur un même nœud.
En complément, sur Windows Server 2008 R2, l’affinité unique peut survivre à un changement de topologie (convergence), contrairement aux versions précédentes où le client était redirigé sur un autre nœud. Si un client X est connecté sur un nœud A et qu’un nœud est ajouté ou supprimé du cluster, le cluster retiendra l’affinité et maintiendra cette affinité pendant X minutes. Le délai d’expiration, exprimé en minutes, commence dès que le client est inactif.
Si nécessaire, le cluster peut très bien avoir plusieurs adresses IP virtuelles. Cela est notamment nécessaire si vous hébergez plusieurs sites Web avec des certificats SSL. À moins d’avoir un certificat de type wildcards (*.masociete.local), chaque site devra avoir une IP dédiée pour les connexions SSL. Contrairement au protocole HTTP est fourni avec la version 2 de PowerShell, ce qui permet d’installer la fonctionnalité sur plusieurs nœuds en une commande :
enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA8Mjg5MzAyIC0gYWRhbW8gZGlhcnJhIC0gMjU4ZThlZWQtN2NjNS00YTU2LThlODQtZjYwZWVhYWMyOThlNOiQEvunzogLAA==-enidentnumber
Invoke-Command -computername noeudA,noeudB -ScriptBlock {import-module servermanager;Add-WindowsFeature NLB}
WinRM doit être configuré au préalable avec la commande winRM quickconfig sur chaque nœud.
Vous pouvez créer la ferme NLB de deux façons :
● Avec l’interface classique NLB.
● Avec PowerShell.
Windows Server 2008 R2 est la dernière version à proposer la console NLB telle qu’on la connaît. Suivant le schéma directeur de Microsoft, il faudra utiliser PowerShell dès la version suivante de Windows pour scripter la gestion de NLB et de la couche cluster. Comme pour d’autres produits (Exchange, SCVMM...), la console graphique servira juste à construire les commandes PowerShell à exécuter.
■ Pour configurer la ferme avec l’interface graphique, cliquez sur Démarrer, puis Outils d’administration, puis sur le Gestionnaire d’équilibrage de la charge réseau.
■ Cliquez ensuite sur Cluster et Nouveau.
■ Choisissez un premier nœud à configurer, ainsi qu’une interface. Définissez sa priorité, son interface de gestion et son statut par défaut.
■ Ajoutez ensuite au moins une adresse IP utilisée par la ferme.
■ Déterminez l’adresse IP principale du cluster ainsi que le nom du cluster.
■ Étape critique, choisissez le mode d’opération du cluster (monodiffusion, multidiffusion avec ou sans IGMP). Par défaut, tous les ports sont en équilibrage de charge, avec une affinité de type unique.
À ce stade, la ferme est créée avec un seul serveur comme membre. L’ajout du second nœud se fait depuis le menu Cluster Ajouter un hôte:
enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA8Mjg5MzAyIC0gYWRhbW8gZGlhcnJhIC0gMjU4ZThlZWQtN2NjNS00YTU2LThlODQtZjYwZWVhYWMyOThlNOiQEvunzogLAA==-enidentnumber
L’interface de gestion des règles permet de choisir l’adresse IP du cluster où elle s’applique, un port ou une plage de ports, la nature (TCP, UDP) et le mode de filtrage :
Voici l’équivalent en PowerShell :
#Création du cluster sur le premier noeud
New-NlbCluster -InterfaceName public -ClusterName cluster02 -ClusterPrimaryIP 192.168.4.15 -
SubnetMask 255.255.255.0
#Ajout du second noeud
Get-NlbCluster | Add-NlbClusterNode -NewNodeName noeudB -NewNodeInterface public
3. Exemple : ferme Web IIS
Une ferme de serveurs Web constitue l’usage type de NLB. IIS 7 a introduit la notion de configuration partagée, qui facilite la gestion de la ferme en centralisant la configuration IIS de tous les serveurs Web sur un partage de fichiers UNC. L’article TechNet suivant décrit sa mise en œuvre : http://technet.microsoft.com/enus/library/cc771871
enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA8Mjg5MzAyIC0gYWRhbW8gZGlhcnJhIC0gMjU4ZThlZWQtN2NjNS00YTU2LThlODQtZjYwZWVhYWMyOThlNOiQEvunzogLAA==-enidentnumber
(WS.10).aspx.
Les étapes sont les suivantes :
● Installer le rôle Serveur Web (WebServer).
● Créer au moins un cluster NLB avec deux nœuds.
● Modifier la règle par défaut, afin d’équilibrer uniquement les ports TCP 80 (HTTP) et 443 (HTTPS).
À ce stade, vous avez une ferme constituée de 2 serveurs Web avec une affinité unique. Vous savez déjà que NLB n’a pas conscience de l’état de l’application qui est répartie. En revanche, vous pouvez modifier le comportement de IIS afin qu’il prenne en compte NLB et modifie son comportement en cas de problème. Par défaut, IIS renvoie un code HTTP 503 en cas de défaillance du pool d’application. Dans le cas d’une ferme de serveurs, il est fort probable que seul ce serveur a ce problème. En indiquant au pool d’applications de faire une réponse de niveau TCP, il va fermer la connexion du client, qui sera alors redirigé vers un autre nœud de la ferme.
Pour modifier ce comportement, il faut aller dans les paramètres avancés du pool de l’application :
enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA8Mjg5MzAyIC0gYWRhbW8gZGlhcnJhIC0gMjU4ZThlZWQtN2NjNS00YTU2LThlODQtZjYwZWVhYWMyOThlNOiQEvunzogLAA==-enidentnumber