• Aucun résultat trouvé

La répartition de charge (Cluster NLB)

même  adresse  IP  (par  exemple  derrière  un  pare­feu  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, celui­ci 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/en­us/library/cc771871

enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA8Mjg5MzAyIC0gYWRhbW8gZGlhcnJhIC0gMjU4ZThlZWQtN2NjNS00YTU2LThlODQtZjYwZWVhYWMyOThlNOiQEvunzogLAA==-enidentnumber

(WS.10).aspx. 

Les étapes sont les suivantes : 

Installer le rôle Serveur Web (Web­Server). 

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