¶ Introduction
Précédemment nous avons vu la théorie concernant les différentes règles de "NIC Teaming and Failover" ainsi que leur fonctionnement concernant le "loadbalancing" du trafic réseau à travers les adaptateurs physiques des hôtes. Dans cette partie nous allons découvrir comment les configurer.
Pour cela sélectionner un Port Group, faire un clique droit dessus puis cliquer sur "Modifier les paramètres".
Cliquer ensuite sur "Association et basculement"
¶ Equilibrage de la charge
Dans la partie "Equilibrage de la charge", nous allons retrouver quelques-unes des différentes méthodes de NIC Teaming dont nous avons parlé précédemment.
-
Route basée sur le port virtuel d'origine : Pour rappel chacune des VMs possède son propre port virtuel et selon ce port virtuel un certain port physique de l'hôte sera utilisé pour acheminer le trafic de cette VM.
-
Route basée sur hachage MAC source : Pour rappel cette option est assez similaire à la précédente puis que selon l'adresse MAC d'une VM un certain port physique de l'hôte sera utilisé pour acheminer le trafic de cette VM.
-
Route basée sur hachage IP : Pour rappel, lorsque qu'une VM va envoyer du trafic réseau vers une destination précise possédént une adresse IP unique, ce trafic peut passer par n'importe quels ports physiques. Celui utilisé sera alors sélectionnée en fonction non seulement de l'adresse IP source mais également sur l'adresse IP de destination. Attention cependant si cette option est activée, il faudra obligatoirement activer du "LACP" ou du "Port Channel" sur le switch physique.
-
Route basée sur la charge NIC physique" : Pour rappel cette option n'est disponible QUE sur les vSphere Distributed Switches. Ici l'idée c'est que si un des ports physiques d'un ESXi commence à saturer en bande passante, les VMs qui lui sont affectées seront automatiquement basculées vers un autre port physique dont la bande passante serait moins surchargée. Donc pour résumer, chacune des VMs verra son trafic lié à un seul port physique mais si celui-ci commence à saturer alors le VDS migrera le trafic de chacune des VMs vers un autre port physique.
¶ Détection de panne réseau
Dans la partie "Détection de panne réseau", nous avons deux options.
-
Etat de lien seulement (Link Status Only) : Pour rappel, le VDS va monitorer la connexion physique. Par exemple, si l'on coupe un câble réseau, s'il est débranché ou si un port physique tombe en panne alors le VDS détectera la panne et déplacera le trafic des VMs vers un autre port physique de l'ESXi.
-
Sondage balise (Beacon Probing) : Pour rappel, chacun des ports physiques d'un ESXi va envoyer aux autres ports des packets à travers le réseau physique. De cette manière chacun des ports s'assure qu'il peut communiquer avec les autres ports au travers du réseau physique permettant ainsi de déterminer si un lien est up ou down. C'est une approche un peu plus "intelligente et précise" que le "Link Status Only".
¶ Notifier les commutateurs
Pour comprendre cette option, prenons l'exemple d'une VM dont le trafic réseau passe par systématiquement par un seul port réseau physique de l'ESXi, par exemple l'Uplink 1.
Imaginons maintenant qu'un problème survienne et que ce lien n'est plus disponible.
Notre VM va alors être migrée sur un autre port physique de l'ESXi pour que son trafic réseau puisse continuer de fonctionner, par exemple l'Uplink 2.
Dans ce cas, il serait peut-être pertinant que le VDS envoi une notification d'échec au switch physique pour qu'il puisse mettre à jour sa table d'adresses MAC.
C'est exactement ce à quoi sert cette option.
Le VDS va prévenir le switch physique qu'une panne est survenue pour qu'il puisse mette à jour sa table d'adresses MAC, permettant ainsi un basculement plus rapide et une amélioration des performances.
Il est donc logique dans la plupart des cas de laisser cette option positionnée sur oui
¶ Restauration automatique
Supposons qu'un port physique de notre ESXi tombe en panne puis qu'il soit de nouveau opérationnel, comme par exemple quelqu'un qui débranche le câble réseau puis le remettre en place.
Ce port réseau de notre ESXi devrait-il être remis en service et être utilisé par nos VMs ou non ?
Par défaut la configuration est positionnée sur oui. Il sera remis en service et pourra de nouveau être utilisé pour le trafic de nos VMs.
Cependant si nous avons du "flapping" sur ce port, c'est à dire s'il devient down puis up puis down puis up etc. Que devons nous faire ?
Si un port physique tombe en panne encore et encore, nous ne souhaiterions peut-être pas activer la restauration automatique.
Dans ce cas nous préfèrerions probablement définir l'option sur Non.
Cette option va donc permettre de définir ce qu'il adviendra d'un port physique d'un ESXi en cas de panne.
Elle permettra de définir automatiquement s'il sera à nouveau utilisé pour le trafic de nos VMs ou au contraire s'il sera ignoré et ne plus être utilisé pour le trafic de nos VMs.
¶ Ordre de basculement
Cette partie va nous permettre de définir les Uplinks (ports physiques) actifs, en veille ou inutilisés.
- Actifs : Il s'agit d'Uplinks qui seront utilisés pour le trafic des VMs.
- En veille : Il s'agit d'Uplinks qui peuvent potentiellement être utilisés pour le trafic des VMs de ce Port Group mais qui ne le sont pas. Ils sont mis de côté pour être utilisés automatiquement et uniquement en cas de panne d'un Uplink actif.
- Inutilisés : Il s'agit comme le nom l'indique d'Uplinks qui ne seront pas utilisés pour le trafic des Vms associées à ce Port Group
Prenons un exemple. Dans la capture d'écran ci-dessus nous avons 4 Uplinks (4 ports physiques) qui sont tous positionnés sur actifs.
Imaginons que ce Port Group soit destiné à des VMs critiques comme celles des ressources humaines et que le trafic de ces VMs doit être isolé sur son propre réseau physique à travers les Uplinks 1 et 2.
Dans ce cas si nous voulons que seuls les Uplinks 1 et 2 soient utilisés il suffira de positionner les Uplinks 3 et 4 comme étant inutilisés.
En cas de pannes le trafic des VMs ne basculera pas sur les Uplinks 3 et 4.
Ce n'est cependant pas forcément une très bonne idée puisqu'il s'agit de VMs critiques.
Nous pourrions alors décider de laisser actifs les Uplinks 1 et 2 mais de se dire qu'en cas de pannes nous pourrions potentiellement utiliser les Uplinks 3 et 4.
Dans ce cas il suffira de s'assurer que le réseau physique des Uplinks 3 et 4 soit techniquement capable d'acheminer correctement le trafic réseau des VMs (ex: vlan) et de positionner les Uplinks 3 et 4 comme étant en veille.
Avec cette configuration en cas de panne d'un Uplink actif, le trafic des VMs basculera sur un des Uplinks 3 et 4.
Chapitre précédent : 8 - vSphere 7 Distributed Switch Security Policies - démonstration - Chapitre suivant : 10 - Traffic Shaping