Certaines fonctionnalités que nous allons découvrir sont disponibles à la fois depuis des "Standard Vitrual Switch" et depuis des "vSphere Distributed Switch".
Cependant je ferai de mon mieux pour péciser si les fonctionniltés présentées ne sont disponible que depuis un "vSphere Distributed Switch".>
Pour accéder aux "vSphere Distributed Switches" qui ont été créés il faudra se rendre dans la section Networking de vCenter.
Commençons par consulter la configuration générale de notre "vSphere Distributed Switch (VDS)".
Cliquer sur le VDS souhaité puis sur "Configurer" et en fin sur "Propriétés"
Dans partie, nous allons retrouver de nombreuses informations importantes concernant la configuration du VDS telles que :
Le protocole de découverte va permettre au VDS de récolter des informations à propos des switches physiques. Par exemple sur quel port le vmnic lié au VDS est branché, quel type de switch est utilisé, la version de son firmware, etc.
Evidemment sagissant du protocole CDP (Cisco Discovery Protocol), cela ne fonctionne QU'AVEC des switch physique de marque Cisco.
Par défaut CDP est activé sur les "Standard Vitrual Switches" et sur les "vSphere Distributed Switches".
Cependant si l'on utilise des VDS, il sera possible de modifier ce protocol.
Pour cela il faudra cliquer sur "Modifier" en haut à droite puis se rendre dans l'onglet "Avancé"
Nous aurons le choix entre CDP et LLDP (Link Layer Discovery Protocol).
Le protocol LLDP fera la même chose que le protocol CDP mais ne sera pas spécifique aux switches Cisco. Tous les switches pourront être pris en charge.
C'est un standard réseau qui ne fonctionne pas QU'AVEC des switches Cisco.
Toujours dans les paramètres de configuration du VDS, cliquer maintenant sur "Topologie"
Dans la partie de droite, nous pouvons voir les Uplinks ainsi que les adaptateurs physiques liés au VDS.
Si je regarde bien je vois que seul l'Uplink 1 possède des adaptateurs physiques. En cliquant sur la flèche je vais pouvoir dérouler le menu et consulter les adaptateurs physiques qui y sont liés. Un vmnic pour le premier ESXi du Lab et un vmnic pour le second ESXi.
Donc pour chacun des hôtes sur lesquels est poussé ce VDS, nous pourrions avoir jusqu'à 4 VMNICs répartis dans différents Uplinks.
La mise en place de VLANs Privés (Private VLANs) n'est possible que si l'on utilise des "vSphere Distributed Switches".
Les "Private VLANs" permettent de créer des VLANs dans d'autres VLANs.
Par défaut aucun "Private VLANs" n'est configuré.
Pour paramètrer des "Private VLANs", il faudra dans un premier temps cliquer sur "VLANs Privés" puis sur "Modifier".
Dans la partie de gauche, cliquer sur "Ajouter" pour définir un VLAN principal puis dans la partie de droite cliquer sur "Ajouter" pour définir un ou plusieurs VLANs secondaires.
Il sera possible de créer autant de VLANs principals ou secondaires que l'on souhaite.
Notez toutefois que par défaut lorsque l'on créé un VLAN principal, un VLAN secondaire de type "Promiscuous" est automatiquement créé et qu'il ne sera pas possible de le supprimer.
Rappel :
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".
Private VLANs : Community
Il s'agit d'un VLAN permettant d'isoler les VMs. Cependnat toutes les VMs de ce VLAN pourront communiquer entre elles. Elles ne pourront pas communiquer avec des VMs d'un autre VLAN de type "Community" mais elles pourront communiquer avec les VMs d'un VLAN de type "Promiscuous".
Private VLANs : Isolated
Il s'agit d'un VLAN permettant d'isoler les VMs y compris entre VMs d'un même VLAN.
Les Seules VMs avec lesquelles elles pourront communiquer seront celles se trouvant dans un "Secondary VLAN" de type "Promiscuous".
Dans l'exemple ci-dessus, ce que nous avons fait faisons consiste à créer des limites directement au sein du VLAN 100.
Par exemple, nous pourrions avoir une VM sur un Port Group connecté au VLAN "principal" 100 ET au VLAN secondaire 100 "Promiscuous".
Cela implique que toute VM connecté sur le VLAN principal 100 pourra communiquer avec les VMs du VLAN secondaire 100 et donc avec notre VM ( et inversement).
De la même manière, si nous ajoutons une seconde VM mais cette fois dans le VLAN secondaire 101 "Community", cette VM pourra communiquer avec n'importe quelle autre VM du VLAN secondaire 100 mais également du VLAN secondaire 101.
Attention, si nous avons plusieurs VLANs secondaires de type "Community", les VMs qui leur sont associées ne pourront communiquer qu'avec leur propre VLAN secondaire.
Il ne sera pas possible pour une VM du VLAN secondaire 101 de communiquer avec les VMs d'un VLAN secondaire 103 par exemple même si ce VLAN secondaire est de type "Community".
Ajoutons maintenant une troisième VM dans le VLAN secondaire 102 "Isolated".
Comme son nom l'indique ce VLAN créé une isolation. Cela signifie que aucune des VMs associées à ce VLAn secondaire ne pourra communiquer avec les autres VMs de ce VLAN secondaire.
Elles pourront cependant communiquer avec les VMS se trouvant dans un "Secondary VLAN" de type "Promiscuous".
Nous venons d'ajouter des Private VLANs sur notre VDS.
Voyons maintenant comment les utiliser. Pour cela rien de compliquer, il suffit de les associer à un Port Group pour que toutes les VMs connectées à ce Port Group soient directement affectées au VLAN Principal et au VLAN secondaire définis.
Cliquer sur le Port Group sur lequel on souhaite ajouter des Private VLANs puis cliquer sur "configurer" et en suite sur "Modifier".
Cliquer sur la partie "VLAN" puis sélectionner "Private VLANs"
Sélectionner le type de VLAN secondaire qui serai associé au Port Group puis valider par OK.
Pour mieux illustrer cette démonstration nous allons créer un deuxième Port Group sur ce VDS et lui associer un autre VLAN secondaire. Par exemple le VLAN 102 : Isolated.
Si l'on regarde à présent notre VDS, nous pourrons constater qu'il dispose des deux Ports Groups et permet à la fois d'associer des VMs soit dans un second VLAN de type "Promiscuous" soit dans un VLAN secondaire de type "Isolated"
Pour associer une VM à l'un ou l'autre des VLANs secondaires il suffira de configurer son Network avec le Port Group correspondant au VLAN secondaire à utiliser.
Les VLANs Privés possèdent donc de réels interêts selon la configuration réseau que l'on souhaite mettre en place.
Si l'on prend l'exemple d'un hôtel, on pourrait parfaitement imaginer que chacune des chambres soit associées à un Private VLAN secondaire de type Isolated ce qui les empêcherait de communiquer ensemble tout en autorisant à communiquer avec le VLAN de type Promiscuous qui lui pourrai très bien contenir un routeur.
NetFlow est un outil permettant d'analyser le trafic réseau des machines virtuelles connectées à un VDS. Il permettra d'envoyer des données de flux réseau agrégées à un collecteur tiers (une appliance ou un serveur, selon la configuration).
NetFlow n'est disponible que si l'on utilise des VDS et doit être configuré sur chaque VDS pour lequel on souhaite analyser le trafic réseau.
Pour configurer NetFlow il faudra cliquer sur un VDS, cliquer sur "configurer" puis sur "Netflow" et en fin sur "Modifier"
Une fois NetFlow configuré le VDS va envoyer des résumés du trafic réseau sur le collecteur, comme par exemple l'IP de provenance du trafic et l'IP de destination, quels ports sont utilisés, etc.
Le collecteur va quand à lui simplement récupérer ces informations pour qu'elles soient analysées.
Il faudra configurer les éléments suivants:
Netflow est un très bon outil de troubleshooting et permettra par exemple de définir si le trafic réseau est surchargé en cas de latences ou de perturbations sur le réseau y compris à des heures bien précises.
L'option "Port Mirroring" permet de cibler l'intégralité du trafic réseau destiné à un port précis pour en envoyer une copie complète sur un autre port.
Cette option n'est possible que lors de l'utilisation de VDS.
Dans quel but pourrions nous effectuer une copie complète du trafic réseau d'un port vers un autre port ?
Nous pourrions par exemple utiliser un sniffer sur une machine virtuelle et lui transférer tout le trafic d'un port pour observer et analyser ce qu'il se passe sur le réseau.
C'est un bon exemple d'utilisation du "Port Mirroring".
Plusieurs possibilités de configurations seront possibles :
Mise en miroir de port distribué
Mettre en miroir le trafic réseau d'un groupe de ports distribués vers d'autres ports distribués.
Source de mise en miroir distante
Mettre en miroir le trafic réseau d'un groupe de ports distribués vers des ports de liaison montante.
Destination de mise en miroir distante
Mettre en miroir le trafic réseau d'un groupe de VLAN vers des ports distribués.
Source de mise en miroir distante (L3) encapsulée
Mettre en miroir le trafic réseau d'un groupe de ports distribués vers des adresses IP d'agents distants.
Prenons par exemple "Mise en miroir de port distribué".
Cocher la case puis cliquer sur "Suivant".
Il faudra alors configurer les paramètres suivants :
Cliquer sur "Suivant" pour en suite définir le port source.
Cliquer sur "Suivant" pour sélectioner le port de destination.
Vérifier la configuration puis valider en cliquant sur "Terminer".
Le Port Mirroring sera alors créé
"Health Check" permet d'identifier et de résoudre les erreurs de configuration que l'on pourrait trouver dans les "vSphere Distributed Switches" et les switches physique de notre environement.
L'intervalle par défaut entre deux vérifications de l'état est de 1 minute.
Cette option n'est également possible que lors de l'utilisation de VDS.
Attention par défaut Health Check est désactivé. Il est plus que recommandé d'Utiliser "Health Check" pour identifier et résoudre des problèmes de réseau puis de le désactiver lorsque les problèmes sont résolus. Laisser activer "Health Check" en permanance n'est pas une bonne idée et ne correspond pas aux Best Practices recommandées car cela pourrai s'apparenter à une faille de sécurité.
pour activer "Health Check", il faudra cliquer sur un VDS puis sur "Configurer" puis sur "Contrôle de santé" (ou Health Check en anglais) et pour finir cliquer sur "Modifier".
"Health Check" permettra de vérifier la configuration des MTU et VLANs ainsi que les Nic Teaming et Failover de notre environnement afin de vérifier si ça match avec la configuration des switches physiques.
Cette partie va nous permettre de configurer les différentes options du "Network I/O Control".
"Network I/O Control (NIOC)" est une fonctionnalité permettant de mettre en place de la "QOS (Quality Of Service)" selon nos différents types de trafics réseau afin définir des priorités d'utilisation de la bande passante.
En effet, il existe différents type de trafics réseau distincts tels que ceux utilisés par le système hôte (vMotion, Fault Tolerence, vSAN, etc.) ou tel que le trafic des VMs.
L'objectif principal de "Network I/O Control (NIOC)" est donc de s'assurer que l'on dispose de suffisamment de bande passante et de ressources pour les VMs tout en préservant suffisamment de ressources pour le trafic système.
Les différentes configurations faites dans "NIOC" vont s'appliquer pour tous les types de trafics réseau parcourant le même adaptateur physique de l'hôte (vmnic).
Mais avant de commencer, nous allons vérifier que "Network I/O Control" est bien activé dans les paramètres de notre VDS.
Si ce n'est pas le cas il faudra alors l'activer
Allons maintenant dans la partie "Allocation de ressources" puis dans "System Traffic".
Nous trouverons ici les différents types de trafics réseau pour lesquels on va pouvoir configurer la QOS :
Par défaut, tous les types de trafics réseau sont positionnés à "normales" (excépté celui qui concerne les VMs qui est positionné sur "haute") et il n'y a pas non plus de réservations ou de limitations.
Ils ont donc tous la même priorité d'exploitation de la bande passante excépté celui de nos VMs (ce qui est assez logique).
Imaginons que nous voulions configurer le trafic pour le vMotion afin d'en augmenter la priorité. Pour cela il faudra cliquer sur "trafic vMotion" puis cliquer sur "Modifier".
Dans cette partie nous allons pouvoir définir les éléments suivants :
Il s'agit d'une valeur comprise entre 1 et 100, où 100 représente le maximum.
Elle correspond à la priorité d'un type de trafic par rapport aux autres types de trafic actifs sur le même adaptateur physique.
Il est important de garder à l'esprit que la valeur définie pour ces "parts" n'est utilisée qu'en cas de "contention (conflit)" de la bande passante. Dans des circonstances normales, ces valeurs ne sont pas appliquées.
Donc s'il y a un manque de bande passante sur les adaptateurs physiques d'un hôte c'est à ce moment là que les "shares" entreront en jeu pour définir la priorité d'utilisation.
Il est possible de choisir entre plusieurs valeurs : "Basses", "Normales", "Hautes" ou "Personnalisées".
C'est la bande passante garantie sur un adaptateur physique (vmnic). La bande passante minimale est en Mbps.
Définit la bande passante maximale autorisée, en Mbps ou Gbps, que le type de trafic peut consommer sur un seul adaptateur physique (vmnic).
Cette partie permet de créer des réservations de bande passante et de les associer directement à certains "Ports Groups" de nos VDS.
Pour créer un Pool de ressources réseau, il faudra au préalable avoir défini une réservation de bande passante pour le trafic réseau des VMs.
Cliquer sur "Trafic système" puis sur "Trafic de machine virtuelle" puis sur "Modifier".
Définir une réservation puis valider en cliquant sur "OK"
Cliquer sur "Pool de Ressources Réseau" puis sur "Ajouter" pour créer un "Pool"
Le pool sera visible dans la liste
Pour attribuer un "Pool de Ressources Réseau" sur un "Port Group", il faudra cliquer sur le "Port Group" puis sur "Configurer", sur "Proriété" et en fin sur "Modifier"
Dans l'onglet général sélectionner le "Pool" qui devra être associé puis cliquer sur "OK" pour valider.
Si l'on retourne à présent dans les options sur VDS, section "Pool de Ressources Réseau" et que l'on clique sur le "Pool" que l'on a créé, nous pourrons voir le "Port Group" associé à la réservation.
Chapitre précédent : 6 - vSphere 7 et NSX-T 3.0 - Chapitre suivant : 8 - vSphere 7 Distributed Switch Security Policies - démonstration