¶ Les Concepts du vSphere Distributed Switch
L'utilisation des "vSphere Distributed Switches" n'est possible que si l'on possède une licence "Enterprise Plus" installée sur un ESXi.
Par exemple si vous avez 4 ESXi, il faudra alors obligatoirement une licence Enterprise Plus sur chacun d'entre eux.
Si vous n'en avez pas il ne sera pas possible de configurer et d'utiliser des "vSphere Distributed Switches".
Cependant l'utilisation d'un "vSphere Distributed Switch" présente de nombreux avantages et de nombreuses différences par rapport a l'utilisation d'un "Standard Vitrual Switch".
Nous allons voir ici quelques exemples.
¶ Scalability
Le premier bénéfice que l'on aura lorsque l'on utilise un "vSphere Distributed Switch" est la Scalability" (évolutivité).
Pour expliquer l'évolutivité que permet un "vSphere Distributed Switch" nous allons par comparer avec un vSphere Stanard Switch.
Prenons l'exemple d'un cluster de 4 ESXi.
Pour commencer lors de la configuration nous allons créer sur un ESXi un vSwitch possédant un ou plusieurs Port Group.
Puis pour avoir une configuration conforme et identique sur l'ensemble du cluster, nous allons devoir reproduire ce processus manuellement sur chacun des ESXi du cluster y compris pour les ESXi qui pourraient être ajoutés au cluster par la suite.
Il nous faudra également créé sur chacun des hôtes les ports VMKernel, leur associer les VMNICs, etc.
Ce processus peut être chronophage et peut entrainer des erreurs d'inatention selon le nombre d'ESXi a configurer.
Le but d'un "vSphere Distributed Switch" est justement d'automatiser et de centraliser toute cette configuration.
Le "vSphere Distributed Switch" est créé dans un seul endroit puis une copie de ce switch est ensuite déployée sur nos ESXi.
L'endroit unique où l'on créé le "vSphere Distributed Switch" est vCenter.
vCenter est donc la console de management du "vSphere Distributed Switch" et il nous donne l'impression de n'avoir qu'un seul vSwitch à configurer.
Bien que vCenter soit la console de management des "vSphere Distributed Switches, aucun trafic réseau ne passe par vCenter.
De cette manière, si vCenter cesse de fonctionner nos VMs ne perdent aucune connectivité et le trafic réseau continuera de fonctionner à travers la copie cachée du "vSphere Distributed Switch" qui se trouve sur chacun de nos ESXi.
A présent que nous avons créé un "vSphere Distributed Switch, nous pouvons créé depuis vCenter un "Distributed Port Group" qui sera déployé sur l'ensemble de nos switches cachés sur les ESXi.
De la même façon que pour un Santard Virtual Switch, lorsque nous créons un Distributed Port Group sur un "vSphere Distributed Switches, nous pourrons mettre en place certains settings tels que des VLANs, le Traffic Shaping, de la sécurité, etc.
De plus, nous n'aurons à faire cette configuration qu'une seule fois puisqu'elle sera déployée automatiquement sur les switches cachés se trouvant sur nos ESXi.
Ainsi, toutes les VMS connectées sur ce Distributed Port Group se verrons appliquer les paramètres que l'on a configuré depuis vCenter pour ce Distributed Port Group.
Il n'y a pas vraiment de différence concernant les ports VMKernel entre l'utilisation d'un Santard Virtual Switch et d'un "vSphere Distributed Switch. Les ports VMKernel sont toujours gérés par les ESXi et nous devons tout de même créer des ports VMKernel sur chaque hôte ESXi avec leur propre adresse IP unique, etc.
¶ Private VLANs
Nous allons parler ici d'une fonction très intéressante qui n'est disponible que sur un "vSphere Distributed Switch" et qui s'appelle "Private VLANs"
Cette fonction va permettre de mettre en place des VLANs privés dans des VLANs pour isoler le trafic réseau de certaines VMs du trafic réseau d'autres VMs.
Pour bien comprendre le fonctionnement, prenons comme exemple le schéma suivant.
Dans ce schéma, nous avons un "vSphere Distributed Switch**" sur lequel nous avons configuré un "Primary VLAN" dont l'ID est 10.
Dans ce même "Primary VLAN", nous avons créé des "Secondary VLAN" avec différents VLAN ID et différents types.
Sur la gauche nous pouvons voir un "Secondary VLAN" qui a pour ID 110 et dont le type est "Isolated".
Au milieu, nous pouvons voir deux "Secondary VLANs" qui ont pour ID 111 et 112 et dont le type est "Community".
A droite nous pouvons voir un "Secondary VLAN" avec comme ID 10 et dont le type est "Promiscuous"
Pour finir dans la partie du dessous, nous pouvons voir des adresses IP représantant des VMs.
Il est important de noter que toutes ces IP sont dans la même plage d'adresses et que chacune des VMs fait partie du "Primary VLAN"
Ce que nous souhtons mettre en place ici en utilisant des "Privates VLANs" c'est de créer une sorte de contrôle et déterminer quelles VMs dans ce VLAN 10 peuvent en réalité communiquer entre elles.
Imaginons par exemple que certaines de ces VMs font parties de différents services comme DEV, PROD, etc et que nous avons besoin de créer une sorte d'isolation entre elles tout en gardant une cohérence dans leur adressage IP.
¶ Private VLANs : Isolated
Reprenons notre schéma et plus précisément les VMs qui se trouvent à gauche.
Nous avons deux VMs qui se trouvent dans un Secondary VLAN de type Isolated.
Cela signifie que toutes les VMs qui se trouvent dans ce VLAN seront incapable de communiquer entre elles et avec des VMs se trouvant dans d'autres VLANs.
Il s'agit donc d'un VLAN permettant d'isoler les VMs.
Les Seules VMs avec lesquelles elles pourront communiquer seront celles se trouvent dans un "Secondary VLAN" de type "Promiscuous".
¶ Private VLANs : Community
Dans la partie du milieu de notre schéma, nous avons deux "Secondary VLANs" identifiés par les ID 111 et 112 qui comptent deux VMs dont les IP sont rescpectivement 10.1.1.12 / 10.1.1.13 pour la partie de gauche et 10.1.1.15 / 10.1.1.16 pour la partie de droite.
Contrairement à l'exemple précédant, les VMS qui se trouvent dans le même "Secondary VLAN" de type "Community" peuvent communiquer entre elles.
Toutefois, si une VM dans un "Secondary VLAN" de type "Community" tente de communiquer avec une VM se trouvant dans un autre "Secondary VLAN" de type "Community" cela ne fonctionnera pas. La communication n'est pas autorisée.
A nouveau la seule exception à la règle concerne les VMs se trouvant dans un "Secondary VLAN" de type "Promiscuous".
Les Vms dans un "Secondary VLAN" de type "Community" pourront toujours communiquer avec les VMs se trouvant dans "Secondary VLAN" de type "Promiscuous".
¶ Private VLANs : Promiscuous
Un "Secondary VLAN" de type "Promiscuous" peut être vue comme une passerelle par défaut qui sera autorisé à communiquer avec n'importe quelle VM depuis n'importe quel "Secondary VLAN".
¶ Route Based on Physical NIC Load
Une autre fonctionnalité importante d'un "vSphere Distributed Switch" est ce qu'on appelle "Route Based on Physical NIC Load" aussi appelé parfois "load based teaming".
Dans la partie concernant les "vSphere Standard Switches" nous avons parlé des méthodes pour mettre en place du NIC Teaming telles que "Originating Port ID", "Source MAC Hash" et "IP Hash". Toutes ces méthodes pour faire du "NIC Teaming" ont un point commun.
Elles ne sont pas très intélligentes, dans le sens où aucune d'entre elles ne permet de détécter si une carte réseau physique est surchargée afin de s'adapter en conséquence.
"load based teaming" ou "Route Based on Physical NIC Load" possède un fonctionnement un peu plus complexe que les méthodes présentées précédemment.
Dans le schéma suivant nous avons 3 VMs qui sont toutes liée à une carte réseau physique.
La VM1 utilise le vmnic se trouvant en haut tandis que les VM2 et VM3 utilisent le même vmnic se trouvant en bas du schéma.
Imaginons maintenant que VM2 et VM3 génèrent énormément de trafic réseau, impliquant que le second vmnic deviennt grandement solicité, du moins beaucoup plus que le premier.
Si ce second vmnic dépasse 75% de ses capacités de bande passante, ce qui se passera alors c'est que les VMs vont être migrées vers un vmnic moins solicité dans le but de réduire la charge de travail sur le vmnic se trouvant trop solicité.
Pour que ce cas de figure fonctionne, il faudra que les VMs ne soient associées qu'à un seul vmnic mais également que le switch physique ne soit surtout PAS configurer avec du "Port Channel" ou du "LACP".
¶ LACP (Link Aggregation Control Protocol)
Cette fonction n'est disponible que sur les "vSphere Distributed Switches".
Je ne vais pas rentrer dans les détails ici mais pour les inités aux switches de CISCO, LACP est un équivanlant de EtherChannel.
Il s'agit d'un moyen de lier plusieurs ports physiques pour les faire agir comme un seul gros port logique. On parle également d’agrégation de ports.
Dans le schéma suivant, nous avons deux VMNICs connectés à un switch physique.
Pour configurer le LACP nous allons devoir configurer dans un premier temps le LAG (Link Aggregation Group), visible dans le prochain schéma en gris et appelé "LAG1".
Le LAG est un moyen d'identifier les ports qui participeront au LACP et il est très important que la configuration correspondent des deux côtés (switch physique et ESXi).
Lorsque la configuration est faite, les de VMNICs peuvent être utilisés comme un seul gros vmnic visible ici en bleu.
la configuration de LACP va également permettre de mettre en place un très grand nombre de méthodes supplémentaites afin faire du "NIC Teaming" :
- Destination IP Address
- Destination IP Address and TCP/UDP Port
- Destination IP Address and VLAN
- Destination IP Address, TCP/UDP port and VLAN
- Destination MAC Address
- Destination TCP/UDP Port
- Source IP Address
- Source IP Address and TCP/UDP Port
- Source IP Address and VLAN
- Source IP Address,TCP/UDP port and VLAN
- Source MAC Address
- Source TCP/UDP Port
- Source and Destination IP address
- Source and Destination IP and TCP/UDP Port
- Source and Destination IP and VLAN
- Source and Destination IP, TCP/UDP and VLAN
- Source and Destination MAC Address
- Source and Destination TCP/UDP Port
- Source port ID
- VLAN
LACP est un standard qui est supporté par un très grand nombre de fabriquants
¶ Points importants
- vSphere Distributed Switch est géré de manière centralisée à l'aide de vCenter
- Des "switches cachés" sont poussés sur les hôtes ESXi et fournissent les configurations réseau
- Distributed Port Group peuvent couvrir de nombreux hôtes et assurer des configurations identiques telles que le Traffic Shaping, la sécurité, etc
- Les VMKernel ports et les Uplinks sont toujours à configurer en local sur les ESXi car ils s'agit d'objets propres à chacun des hôtes
- Les Private VLANs permettent d'effetuer de la segmentation dans une même plage IP et dans des VLANs
- Route Based on Physical NIC Load est une méthode de NIC Teaming permettant d'effectuer de manière intélligente des migrations de VMs d'un vmnic vers un autre.
- LACP peut être uilisé pour effectuer de l'aggrégation de ports et mettre en place un grand nombre de méthodes de Load balancing
Chapitre précédent : 2 -vSphere Standard Switches - Chapitre suivant : 4 - vSphere Distributed Switch : démonstration