¶ Importance
Quand vous configurez correctement le networking ESXi, les virtual machines (VMs) peuvent communiquer avec d’autres machines, qu’elles soient virtuelles ou physiques.
De plus, un réseau ESXi bien configuré permet au VMkernel d’assurer la gestion des hôtes à distance, et le stockage basé sur IP de manière efficace.
Les vSphere Standard Switches (vSS) fournissent un réseau simple et efficace pour les petits environnements.
À mesure que votre environnement vSphere s’agrandit, les vSphere Distributed Switches (vDS), avec leurs fonctionnalités avancées, vous aident à mieux gérer le networking dans de grands environnements.
¶ Leçons du module
- vSphere Standard Switches
- Configuring Virtual Switch Policies
- vSphere Distributed Switches
¶ Leçon 1 : vSphere Standard Switches
¶ Objectifs d’apprentissage
- Identifier les types de connexion des virtual switches
- Configurer et afficher les configurations des standard switches
¶ À propos des Virtual Switches
Les virtual switches connectent les VMs au réseau physique.
Ils assurent la connectivité entre les VMs sur le même ESXi host ou sur des ESXi hosts différents.
Ils prennent également en charge les services VMkernel, tels que vSphere vMotion (migration), iSCSI, NFS, et l'accès au management network.
¶ Types de Virtual Switches
Un réseau virtuel prend en charge les standard switches et les distributed switches.
Les deux types de switches sont élastiques : les ports sont créés et supprimés automatiquement.
-
Standard switch :
— Virtual switch configuré pour un seul host. -
Distributed switch :
— Virtual switch configuré pour l’ensemble d’un data center.
— Jusqu’à 2 000 hosts peuvent être connectés au même distributed switch.
— La configuration est cohérente sur tous les hosts connectés.
— Les hosts doivent soit disposer d’une licence Enterprise Plus, soit appartenir à un vSAN cluster.
¶ Types de Connexions des Virtual Switches
Un virtual switch possède des types de connexion spécifiques :
- VM ports
- VMkernel ports
— IP storage, vSphere vMotion (migration), vSphere Fault Tolerance, vSAN, vSphere Replication, et le ESXi management network - Uplink ports
Les VM ports et les VMkernel ports existent dans des port groups.
Le ESXi management network port est un VMkernel port qui se connecte à des services réseau ou à distance, y compris vpxd sur vCenter et VMware Host Client.
Chaque ESXi management network port, ainsi que tous les autres VMkernel ports, doivent être configurés avec leur propre adresse IP, masque de sous-réseau (netmask) et passerelle (gateway).
Pour configurer les virtual switches, vous créez des port groups.
Un port group est un modèle qui stocke les informations de configuration permettant de créer des ports de virtual switch sur un virtual switch.
Les port groups peuvent contenir des VM ports, qui connectent les VMs entre elles avec des propriétés réseau communes.
Les port groups peuvent également contenir des VMkernel ports.
Les VM ports et les VMkernel ports se connectent au monde extérieur via les adaptateurs Ethernet physiques qui sont connectés aux uplink ports du virtual switch.
¶ Exemples de Connexions de Virtual Switches
Les réseaux (port groups) peuvent coexister sur le même virtual switch ou sur des virtual switches distincts.
Lorsque vous concevez votre environnement réseau, vous pouvez regrouper tous vos réseaux sur un seul virtual switch.
Alternativement, vous pouvez opter pour plusieurs virtual switches, chacun avec un réseau séparé.
Cette décision dépend en partie de la configuration de vos réseaux physiques.
Par exemple, vous pourriez ne pas disposer d’assez d’adaptateurs réseau pour créer un virtual switch distinct pour chaque réseau.
Dans ce cas, vous pouvez placer vos adaptateurs réseau sur un seul virtual switch et isoler les réseaux en utilisant des VLANs.
Comme les NICs physiques sont assignés au niveau du virtual switch, tous les ports et port groups définis pour un switch particulier partagent le même matériel.
¶ À propos des VLANs et du Virtual Switch Tagging
ESXi prend en charge les VLANs en assignant un VLAN ID à un port group.
ESXi supporte le 802.1Q VLAN tagging.
Le virtual switch tagging fait partie des règles de marquage prises en charge :
- Les trames provenant d’une VM sont taguées lorsqu’elles sortent du virtual switch.
- Les trames taguées arrivant sur un virtual switch sont détaguées avant d’être envoyées à la VM destinataire.
- L’impact sur les performances est minimal.
Les ports du physical switch doivent être configurés en tant que trunk ports.
Les VLANs permettent des regroupements logiques de ports de switch.
Toutes les machines virtuelles ou ports d’un VLAN communiquent comme s’ils étaient sur le même segment LAN physique.
Un VLAN est un domaine de broadcast configuré par logiciel.
L’utilisation d’un VLAN offre les avantages suivants :
- Création de réseaux logiques indépendants de la topologie physique
- Amélioration des performances en confinant le trafic broadcast à un sous-ensemble de ports sur un switch
- Réduction des coûts en partitionnant le réseau sans la complexité de déployer de nouveaux routeurs
Les VLANs sont configurés au niveau du port group.
L’ESXi host prend en charge les VLANs via le virtual switch tagging, qui consiste à attribuer un VLAN ID à un port group. Par défaut, le VLAN ID est 0.
Le VMkernel gère tout le marquage (tagging) et le démarquage (untagging) des paquets lorsqu’ils traversent le virtual switch.
Le port sur un physical switch auquel un ESXi host est connecté doit être défini comme un static trunk port.
Un trunk port est un port d’un switch Ethernet physique configuré pour envoyer et recevoir des paquets tagués avec un VLAN ID.
Aucune configuration VLAN n’est requise dans la VM. En fait, la VM ne sait même pas qu’elle est connectée à un VLAN.
Pour plus d’informations sur la mise en œuvre des VLANs, consultez l’article de la base de connaissances VMware 1003806 à l’adresse : http://kb.vmware.com/kb/1003806
¶ Visualisation des Standard Switches
Dans le vSphere Client, vous pouvez consulter la configuration des standard switches d’un host en sélectionnant Virtual Switches dans l’onglet Configure.
La diapositive montre le standard switch, vSwitch0, sur l’ESXi host sa-esxi-01.vclass.local.
Par défaut, l’installation d’ESXi crée un virtual machine port group nommé VM Network ainsi qu’un port group nommé Management Network qui contient un VMkernel port pour le trafic de gestion.
Vous pouvez créer des port groups supplémentaires pour les VMs et les VMkernel ports.
Par exemple, vous pouvez créer un IP Storage port group qui contient un VMkernel port pour accéder au stockage iSCSI.
Pour des raisons de performance et de sécurité, vous devriez supprimer le virtual machine port group VM Network et garder les réseaux VM et de gestion séparés sur des réseaux physiques ou des VLANs différents.
¶ Ajout de Standard Switches
Vous pouvez ajouter de nouveaux standard switches à un ESXi host ou configurer ceux existants en utilisant le vSphere Client ou le VMware Host Client.
¶ Propriétés du VMkernel Adapter
Le panneau VMkernel adapters affiche les détails concernant les interfaces VMkernel, tels que leur nom, le switch sur lequel elles sont situées, l’adresse IP, ainsi que les services activés.
¶ VMkernel Adapter Properties: Enabled Services
Vous pouvez activer des services pour le VMkernel adapter.
Sélectionnez parmi les services disponibles :
- vMotion : Permet au VMkernel adapter de s’annoncer à un autre host comme la connexion réseau où le trafic vSphere vMotion est envoyé.
- Provisioning : Gère les données transférées pour la cold migration d’une virtual machine, le clonage et la migration de snapshots.
- Fault Tolerance logging : Active le Fault Tolerance logging sur le host.
- Management : Active le management traffic pour le host et vCenter.
- vSphere Replication : Gère les données de réplication sortantes envoyées depuis le source ESXi host vers le vSphere Replication server.
- vSphere Replication NFC : Gère les données de réplication entrantes sur le target replication site.
- vSAN : Active le trafic vSAN sur le host.
- vSphere Backup NFC : Définit le paramétrage du VMkernel port pour le trafic dédié de backup NFC.
- NVMe over TCP : Paramétrage du VMkernel port pour le trafic de stockage dédié NVMe over TCP. Le trafic de stockage NVMe over TCP passe par le VMkernel Adapter lorsque l’NVMe over TCP adapter est activé.
- NVMe over RDMA : Paramétrage du VMkernel port pour le trafic de stockage dédié NVMe over RDMA. Le trafic de stockage NVMe over RDMA passe par le VMkernel Adapter lorsque l’NVMe over RDMA adapter est activé.
¶ Physical Adapter Properties
Le panneau Physical adapters affiche les détails de l’adapter tels que la speed, le duplex et les networks.
Bien que les paramètres de speed et de duplex soient configurables, la bonne pratique consiste à laisser les paramètres en auto negotiation.
Vous pouvez modifier la connection speed et le duplex d’un physical adapter afin de transférer des données en conformité avec le taux de trafic.
¶ Lab 7 : Création de Standard Switches
Créez un standard switch et un port group pour les virtual machines :
- Afficher la Standard Switch Configuration
- Créer un Standard Switch avec un Virtual Machine Port Group
- Attacher des Virtual Machines au Virtual Machine Port Group
Retrouvez le lien du Lab en cliquant ici : Lab 7 : Création de Standard Switches
¶ Revue des objectifs d’apprentissage
- Identifier les types de connexion du virtual switch
- Configurer et afficher les standard switch configurations
¶ Leçon 2 : Politiques de Virtual Switch Networking
¶ Objectifs d’apprentissage
- Expliquer comment définir des security policies pour un virtual switch
- Expliquer comment définir des traffic shaping policies pour un virtual switch
- Expliquer comment définir des NIC teaming et failover policies pour un virtual switch
¶ À propos des Networking Policies
En tant qu’administrateur, vous définissez des networking policies sur les virtual switches afin de configurer les propriétés du virtual network, telles que la sécurité, la performance et la disponibilité.
Selon le type de virtual switch, les networking policies peuvent être appliquées à différents niveaux du virtual switch.
| Virtual Switch Type | Set Default Policy At | Override Default Policy At |
|---|---|---|
| vSphere Standard Switch | Standard switch level | Port group level |
| vSphere Distributed Switch | Distributed port group level | Individual port level |
La networking security policy fournit une protection contre l’usurpation d’adresse MAC et les tentatives de port scanning non désirées.
La traffic shaping policy est utile lorsque vous souhaitez limiter la quantité de trafic vers une VM ou un groupe de VMs.
Utilisez la teaming and failover policy pour déterminer les informations suivantes :
- Comment le trafic réseau des VMs et des VMkernel adapters connectés au switch est distribué entre les physical adapters.
- Comment le trafic doit être redirigé si un adapter tombe en panne.
¶ Configuration des Security Policies
En tant qu’administrateur, vous pouvez définir des security policies à la fois au niveau du standard switch et au niveau du port group :
- Promiscuous mode : Autoriser ou refuser que tout le trafic soit transmis, quelle que soit la destination.
- MAC address changes : Accepter ou rejeter le trafic entrant lorsque l’adresse MAC est modifiée par le guest.
- Forged transmits : Accepter ou rejeter le trafic sortant lorsque l’adresse MAC est modifiée par le guest.
Dans la plupart des cas, le paramètre recommandé pour toutes les policies est Reject.
La network security policy contient les exceptions suivantes :
- Promiscuous mode : Le Promiscuous mode permet à un virtual switch ou à un port group de transmettre tout le trafic, quelle que soit la destination. La valeur par défaut est Reject.
- MAC address changes : Si cette option est définie sur Reject et que le guest tente de modifier l’adresse MAC assignée à la virtual NIC, il cesse de recevoir des trames. La valeur par défaut est Reject. Conservez le paramètre par défaut pour aider à vous protéger contre les attaques lancées par un rogue guest operating system.
- Forged transmits : Le champ d’adresse source d’une trame peut être modifié par le guest et contenir une adresse MAC autre que l’adresse MAC assignée à la virtual NIC. Vous pouvez définir le paramètre Forged Transmits pour accepter ou rejeter de telles trames. La valeur par défaut est Reject. Conservez le paramètre par défaut pour aider à vous protéger contre les attaques lancées par un rogue guest operating system.
En général, ces policies vous donnent la possibilité d’interdire certains comportements susceptibles de compromettre la sécurité.
Par exemple, un hacker peut utiliser un périphérique en promiscuous mode pour capturer le trafic réseau à des fins malveillantes. Ou encore, quelqu’un peut usurper l’identité d’un nœud et obtenir un accès non autorisé en usurpant son adresse MAC.
Modifiez le paramètre sur Accept uniquement pour des cas d’utilisation spécialisés. Exemples :
- Définissez Promiscuous mode sur Accept pour utiliser une application dans une VM qui analyse ou capture des paquets, comme un network-based intrusion detection system.
- Définissez MAC address changes et Forged transmits sur Accept si vos applications modifient l’adresse MAC associée, comme le font certains guest operating system-based firewalls.
¶ Traffic-Shaping Policies
Le network traffic shaping est un mécanisme permettant de limiter la consommation de bande passante réseau disponible par une virtual machine.
Les paramètres average rate, peak rate et burst size sont configurables.
Le network traffic shaping est désactivé par défaut.
L’ESXi host régule le trafic en définissant des paramètres pour les caractéristiques suivantes :
- Average bandwidth (Kbps) : Définit le nombre de kilobits par seconde autorisés à travers un port, en moyenne dans le temps. L’average bandwidth correspond à la charge moyenne autorisée.
- Peak bandwidth (Kbps) : Définit le nombre maximal de kilobits par seconde autorisés à travers un port lorsqu’il envoie un burst de trafic. Cette valeur limite la bande passante utilisée par un port lorsqu’il exploite le burst bonus configuré par le paramètre Burst size.
- Burst size (KB) : Définit le nombre maximal de kilooctets autorisés dans un burst. Si ce paramètre est défini, un port peut obtenir un burst bonus s’il n’utilise pas toute la bande passante qui lui est allouée. Chaque fois que le port a besoin de plus de bande passante que l’average bandwidth, il peut être autorisé à transmettre temporairement des données à une vitesse plus élevée si un burst bonus est disponible. Ce paramètre limite le nombre de kilooctets accumulés dans le burst bonus et permet ainsi des transferts plus rapides.
¶ Configuration du Outbound Traffic Shaping
Une traffic-shaping policy est définie par l’average bandwidth, le peak bandwidth et le burst size.
Les paramètres s’appliquent à chaque virtual NIC dans le standard switch.
Sur un standard switch, le traffic shaping contrôle uniquement le outbound traffic.
Le outbound traffic circule des VMs vers le virtual switch, puis sort vers le physical network.
La bande passante réseau d’une virtual machine peut être contrôlée en activant le network traffic shaper.
La diapositive montre l’activation du traffic shaping sur un standard switch.
Le network traffic shaper, lorsqu’il est utilisé sur un standard switch, façonne uniquement le outbound network traffic.
Pour contrôler le inbound traffic, utilisez un load-balancing system ou activez les fonctionnalités de rate-limiting sur votre physical router.
¶ Configuration du NIC Teaming et du Failover
Avec le NIC teaming, vous pouvez augmenter la capacité réseau d’un port group en incluant deux ou plusieurs physical NICs dans une team.
Ajoutez les physical NICs (ou uplinks) au groupe Active uplinks.
Le trafic des VMs est réparti (load balanced) entre les Active uplinks en utilisant l’option de Load balancing sélectionnée.
Le NIC teaming augmente la bande passante réseau du switch et fournit de la redondance. Pour déterminer comment le trafic est redirigé lorsqu’un adapter tombe en panne, vous incluez des physical NICs dans un ordre de failover.
La load-balancing policy détermine comment le trafic réseau est distribué entre les network adapters dans une NIC team.
Selon les besoins et les capacités de votre environnement, sélectionnez des load-balancing algorithms afin que le virtual switch distribue le trafic réseau entre les physical NICs d’une team.
Les virtual switches effectuent uniquement le load balancing du trafic sortant (outgoing traffic).
Le trafic entrant (incoming traffic) est contrôlé par la load-balancing policy sur le physical switch.
Un failover order détermine quels liens sont actifs durant le fonctionnement normal et quels liens deviennent actifs en cas de failover.
Vous pouvez personnaliser les adapters suivants dans une liste de failover order :
- Active : Utilise les NICs de ce groupe tant que la connectivité des NICs est opérationnelle et active.
- Standby : Utilise une NIC de ce groupe si l’une des NICs tombe en panne.
- Unused : N’utilise pas cette NIC. Les NICs sont placées dans ce groupe pour être réservées en cas d’urgence. Elles peuvent être déplacées dans le groupe Active si nécessaire.
¶ Load Balancing Method : Originating Virtual Port ID
Avec la méthode de load balancing basée sur l’originating virtual port ID, le outbound traffic d’une virtual machine est associé à une physical NIC spécifique.
La méthode de load balancing qui utilise l’originating virtual port ID est simple et rapide et ne nécessite pas que le VMkernel examine la trame pour obtenir les informations nécessaires. La NIC est déterminée par l’ID du virtual port auquel la VM est connectée. Avec cette méthode, aucune single-NIC VM n’obtient plus de bande passante que ce qui peut être fourni par un seul physical adapter.
Avantages de cette méthode :
- Le trafic est réparti de manière équilibrée si le nombre de virtual NICs est supérieur au nombre de physical NICs dans la team.
- La surcharge de l’algorithme est faible car, dans la plupart des cas, le virtual switch calcule les uplinks pour la VM une seule fois.
- Aucune modification du physical switch n’est nécessaire.
Inconvénients de cette méthode :
- Le virtual switch ne prend pas en compte la charge de trafic sur les uplinks. Il ne fait donc pas de load balancing vers les uplinks les moins utilisés.
- La bande passante disponible pour une VM est limitée à la vitesse de l’uplink associé à l’ID du port correspondant, sauf si la VM dispose de plusieurs virtual NICs.
¶ Load Balancing Method : Source MAC Hash
Le outbound traffic d’une virtual machine, lorsqu’il est soumis au load balancing avec la méthode Source MAC hash, est associé à une physical NIC spécifique en fonction de l’adresse MAC de la virtual NIC.
La méthode de load balancing basée sur le Source MAC hash a une faible surcharge (low overhead) et est compatible avec tous les switches, mais elle peut ne pas répartir le trafic de manière équilibrée sur toutes les physical NICs.
De plus, aucune single-NIC virtual machine n’obtient plus de bande passante que ce qu’un seul physical adapter peut fournir.
Avantages de cette méthode :
- Les VMs utilisent le même uplink car l’adresse MAC est statique. Le fait d’allumer ou d’éteindre une VM ne change pas l’uplink qu’elle utilise.
- Aucune modification du physical switch n’est requise.
Inconvénients de cette méthode :
- La bande passante disponible pour une VM est limitée à la vitesse de l’uplink associé à l’ID du port correspondant, sauf si la VM utilise plusieurs adresses MAC sources.
- La surcharge de l’algorithme est plus élevée que pour une méthode basée sur l’originating virtual port, car le virtual switch calcule un uplink pour chaque paquet.
- Le virtual switch n’a pas conscience de la charge des uplinks, ce qui peut entraîner une surcharge de certains d’entre eux.
¶ Load Balancing Method : Source and Destination IP Hash
Avec la méthode de load balancing basée sur les adresses IP, une NIC est sélectionnée pour chaque outbound packet en fonction de ses adresses IP source et destination.
La méthode basée sur les adresses IP nécessite la prise en charge de l’802.3ad link aggregation ou un EtherChannel sur le switch. Le Link Aggregation Control Protocol (LACP) est une méthode permettant de contrôler l’agrégation de plusieurs ports physiques afin de former un seul canal logique. Le LACP fait partie de la spécification IEEE 802.3ad.
EtherChannel est une technologie de port trunking utilisée principalement sur les switches Cisco. Avec cette technologie, vous pouvez regrouper plusieurs liens Ethernet physiques pour créer un seul lien Ethernet logique, offrant ainsi une tolérance aux pannes (fault tolerance) et des connexions haut débit entre switches, routers et servers.
Avec cette méthode, une single-NIC virtual machine peut utiliser la bande passante de plusieurs physical adapters.
La méthode de IP-based load balancing affecte uniquement le outbound traffic. Par exemple, une VM peut sélectionner une NIC particulière pour communiquer avec une VM de destination particulière. Le return traffic peut ne pas être traité sur la même NIC que le outbound traffic, mais par une autre NIC dans le même NIC team.
Avantages de cette méthode :
- La charge est plus équitablement répartie par rapport à la méthode basée sur l’originating virtual port et celle basée sur le source MAC hash, car le virtual switch calcule l’uplink pour chaque paquet.
- Les VMs qui communiquent avec plusieurs adresses IP bénéficient d’un débit potentiellement plus élevé.
Inconvénients de cette méthode :
- La surcharge de l’algorithme (algorithm overhead) est la plus élevée comparée aux autres algorithmes de load balancing.
- Le virtual switch n’a pas conscience de la charge réelle des uplinks.
- Des modifications sur le physical network sont nécessaires.
- La méthode est complexe à dépanner (troubleshoot).
¶ Detecting and Handling Network Failure
Les pannes réseau (network failures) sont surveillées et détectées par le VMkernel. Le VMkernel surveille l’état du lien (link state) et exécute un beacon probing (si sélectionné) à des intervalles d’une seconde pour garantir la disponibilité du réseau (network uptime).
Si le VMkernel détecte une panne réseau, il notifie les physical switches des changements de l’emplacement physique d’une adresse MAC.
Le failover est implémenté par le VMkernel sur la base de paramètres configurables :
- Failback : définit comment l’physical adapter est remis en service après récupération d’une panne.
- Load-balancing option : utilise un ordre de explicit failover. Utilise toujours l’vmnic uplink situé en haut de la liste des active adapters.
La surveillance de l’état du lien (link status) fourni par l’network adapter permet de détecter des pannes telles que des déconnexions de câble (cable pulls) ou des pannes d’alimentation d’un physical switch. Cette surveillance ne permet pas de détecter des erreurs de configuration, telles qu’un port de physical switch bloqué par le Spanning Tree Protocol (STP) ou une appartenance VLAN mal configurée. Cette méthode ne peut pas détecter les pannes en amont (upstream), non physiquement connectées au switch ou au câble.
Le beacon probing introduit une charge de paquets de 62 octets environ toutes les secondes par physical NIC. Lorsqu’il est activé, le VMkernel envoie et écoute des paquets de sonde (probe packets).
Sur toutes les NICs configurées comme faisant partie du team, cette technique peut détecter des pannes que la simple surveillance de l’link status ne peut pas identifier. Une topologie réseau spécifique est requise pour que le beacon probing fonctionne. Consultez le fabricant de votre switch pour vérifier la compatibilité du beacon probing dans votre environnement.
Pour plus d’informations sur le beacon probing, voir l’article de la base de connaissances VMware 1005577 : http://kb.vmware.com/kb/1005577.
Un physical switch peut être notifié par le VMkernel chaque fois qu’une virtual NIC est connectée à un virtual switch. Un physical switch peut également être notifié lorsqu’un événement de failover entraîne le routage du trafic d’une virtual NIC via une autre physical NIC. La notification est envoyée sur le réseau afin de mettre à jour les tables de correspondance (lookup tables) des physical switches.
Dans la plupart des cas, ce processus de notification est bénéfique car, sans lui, les VMs subissent une plus grande latence après des failovers et des opérations de vSphere vMotion.
Ne définissez pas cette option lorsque les VMs connectées au port group exécutent Microsoft Network Load Balancing (NLB) en mode unicast. Le NLB en mode multicast n’est pas affecté.
Pour plus d’informations concernant ce problème lié au NLB, voir l’article de la base de connaissances VMware 1556 : http://kb.vmware.com/kb/1556.
Lors de l’utilisation de l’explicit failover order, utilisez toujours l’uplink le plus haut dans la liste des active adapters qui satisfait aux critères de détection de failover.
L’option Failback détermine comment un physical adapter est remis en service après récupération d’une panne :
- Si Failback est défini sur Yes, l’adapter en panne est immédiatement remis en service dès sa récupération, remplaçant l’standby adapter qui avait pris sa place au moment de la panne.
- Si Failback est défini sur No, un adapter défaillant reste inactif même après sa récupération, jusqu’à ce qu’un autre active adapter tombe en panne et nécessite son remplacement.
¶ Physical Network Considerations
Votre environnement de virtual networking repose sur l’infrastructure du physical network. En tant qu’administrateur vSphere, vous devez discuter de vos besoins en vSphere networking avec votre équipe d’administration réseau.
Les points suivants sont des sujets de discussion :
- Nombre de physical switches
- Bande passante réseau (network bandwidth) requise
- Compatibilité de configuration du physical switch avec 802.1Q pour le VLAN tagging
- Compatibilité de configuration du physical switch avec le NIC teaming : 802.3ad, Link Aggregation Control Protocol (LACP) ou EtherChannel
- Sécurité des ports réseau (network port security)
- Link Layer Discovery Protocol (LLDP) et Cisco Discovery Protocol (CDP) et leurs modes de fonctionnement : listen, broadcast, listen and broadcast, et disabled
¶ Activity : Networking Security Policy
Laquelle des affirmations décrit avec précision le Promiscuous mode lorsqu’il est défini sur Accept ? (Choisissez une réponse.)
- L’ESXi host est autorisé à rejeter les paquets réseau qui semblent suspects.
- Un administrateur fournit une sécurité renforcée au virtual switch.
- Un administrateur peut utiliser un network-based intrusion detection system dans une VM.
- Le guest OS reçoit l’autorisation de modifier l’adresse MAC de la VM.
Laquelle des affirmations décrit avec précision le Promiscuous mode lorsqu’il est défini sur Accept ? (Choisissez une réponse.)
- L’ESXi host est autorisé à rejeter les paquets réseau qui semblent suspects.
- Un administrateur fournit une sécurité renforcée au virtual switch.
- Un administrateur peut utiliser un network-based intrusion detection system dans une VM.
- Le guest OS reçoit l’autorisation de modifier l’adresse MAC de la VM.
Lorsque le Promiscuous mode est défini sur Accept, un administrateur peut exécuter des logiciels légitimes tels qu’un network-based intrusion detection system. Cependant, lorsque ce mode est activé, le virtual switch devient vulnérable aux failles de sécurité.
¶ Activity : Traffic Shaping Policy
Laquelle des affirmations décrit avec précision la configuration de la traffic shaping policy ? (Choisissez une réponse.)
- La traffic shaping est activée sur l’ensemble du standard switch.
- La traffic shaping policy pour le TestDev port group remplace la politique définie sur le standard switch.
- La bande passante utilisée en fonctionnement normal par les VMs sur le TestDev port group est de 100 Mbps.
- Le Accounting port group est soumis à la traffic shaping, avec une bande passante moyenne de 1 Gbps.
Laquelle des affirmations décrit avec précision la configuration de la traffic shaping policy ? (Choisissez une réponse.)
- La traffic shaping est activée sur l’ensemble du standard switch.
- La traffic shaping policy pour le TestDev port group remplace la politique définie sur le standard switch.
- La bande passante utilisée en fonctionnement normal par les VMs sur le TestDev port group est de 100 Mbps.
- Le Accounting port group est soumis à la traffic shaping, avec une bande passante moyenne de 1 Gbps.
¶ NIC Teaming and Failover Policy
La méthode de load balancing appelée Originating Virtual Port ID est disponible uniquement sur les distributed switches.
- Vrai
- Faux
La méthode de load balancing basée sur l’originating virtual port ID est disponible uniquement sur les distributed switches.
- Vrai
- Faux
La méthode de load balancing basée sur la charge des physical NIC (Route based on physical NIC load) est la seule méthode prise en charge sur les distributed switches.
Cette méthode garantit que la capacité des physical NIC dans un NIC team est optimisée.
¶ Revue des Objectifs d’Apprentissage
- Expliquer comment définir des security policies pour un virtual switch
- Expliquer comment définir des traffic shaping policies pour un virtual switch
- Expliquer comment définir des politiques de NIC teaming et de failover pour un virtual switch
¶ Leçon 3 : vSphere Distributed Switches
¶ Objectifs d’Apprentissage
- Reconnaître la différence entre les standard switches et les distributed switches
- Identifier les avantages et fonctionnalités des distributed switches
- Créer un distributed switch
¶ À propos des Distributed Switches
Un distributed switch fonctionne comme un seul virtual switch à travers tous les hosts associés. Les distributed switches présentent plusieurs avantages par rapport aux standard switches :
- Les distributed switches centralisent l’administration du virtual network et simplifient l’administration du data center.
- Les distributed switch ports sont assignés de manière statique par vCenter et offrent un contrôle plus granulaire sur les statistiques et politiques réseau (network statistics and policies).
Les standard switches sont configurés au niveau de l’host. Les distributed switches sont configurés au niveau du data center, ce qui leur donne les avantages suivants :
- La configuration et l’administration du data center sont simplifiées grâce à cette configuration réseau centralisée. Par exemple, ajouter un host à un cluster et le rendre compatible avec vSphere vMotion est beaucoup plus simple qu’avec un standard switch.
- Les distributed ports migrent avec leurs VMs. Par exemple, lorsque vous migrez une VM avec vSphere vMotion, les statistiques et politiques du distributed port migrent également avec la VM, ce qui simplifie le debugging et le troubleshooting.
¶ Architecture des Distributed Switches
Géré par vCenter, un distributed switch est une entité logique que vous pouvez utiliser pour créer et maintenir une configuration de virtual networking cohérente sur l’ensemble de vos ESXi hosts.
Un distributed switch déplace les composants de gestion réseau au niveau du data center.
L’architecture d’un distributed switch se compose de deux plans : le plan de contrôle (control plane) et le plan d’E/S (I/O plane).
-
Le control plane réside dans vCenter.
Il configure les distributed switches, les distributed port groups, les distributed ports, les uplinks, le NIC teaming, etc.
Il coordonne également la migration des ports et est responsable de la configuration du switch. -
Le I/O plane est implémenté sous la forme d’un hidden virtual switch dans le VMkernel de chaque ESXi host.
Il gère le matériel d’E/S de l’hôte et est chargé du packet forwarding.
vCenter supervise la création de ces switches virtuels cachés.
Chaque distributed switch inclut des distributed ports.
Vous pouvez connecter n’importe quelle entité réseau (comme une VM ou une VMkernel interface) à un distributed port.
vCenter stocke l’état des distributed ports dans sa base de données.
Avec un distributed port group, vous pouvez regrouper logiquement des distributed ports pour simplifier la configuration.
Un distributed port group définit les options de configuration des ports pour chaque port membre d’un distributed switch.
Les ports peuvent également avoir leur propre configuration unique.
Les uplinks sont des abstractions des vmnics provenant de plusieurs hôtes, reliées à un seul distributed switch.
Un uplink dans un distributed switch joue le même rôle qu’un vmnic dans un standard switch.
Deux VMs sur des hôtes différents ne peuvent communiquer entre elles que si leurs uplinks se trouvent dans le même broadcast domain.
¶ Standard et Distributed Switches : Fonctionnalités partagées
Les standard et distributed switches partagent certaines fonctionnalités.
| Feature | Standard Switch | Distributed Switch |
|---|---|---|
| Layer 2 switch | ✓ | ✓ |
| VLAN segmentation | ✓ | ✓ |
| 802.1Q tagging | ✓ | ✓ |
| IPv4 and IPv6 support | ✓ | ✓ |
| NIC teaming | ✓ | ✓ |
| Outbound traffic shaping | ✓ | ✓ |
¶ Fonctionnalités des Distributed Switches
Les distributed switches ont plusieurs fonctionnalités que les standard switches n’ont pas.
| Feature | Standard Switch | Distributed Switch |
|---|---|---|
| Inbound traffic shaping | ✓ | |
| Configuration backup and restore | ✓ | |
| Private VLANs | ✓ | |
| Link Aggregation Control Protocol | ✓ | |
| Data center level management | ✓ | |
| vSphere vMotion migration of network state | ✓ | |
| Network I/O Control | ✓ | |
| Per-port policy settings | ✓ | |
| Port state monitoring | ✓ | |
| NetFlow | ✓ | |
| Port mirroring | ✓ | |
| Support for NSX | ✓ |
Pendant une migration vSphere vMotion, un distributed switch suit l’état du réseau virtuel (par exemple, les compteurs et les statistiques de port) des VMs qui se déplacent entre les hôtes.
Ce suivi fournit une vue cohérente d’une interface réseau virtuelle, indépendamment de l’emplacement de la VM ou de l’historique des migrations vSphere vMotion.
Le suivi simplifie les activités de supervision et de dépannage réseau lors de la migration de VMs entre hôtes utilisant vSphere vMotion.
¶ Visualisation des Distributed Switches
Dans le vSphere Client, vous pouvez afficher la configuration du distributed switch en utilisant le panneau Topology dans l’onglet Configure.
¶ Discovery Protocols
Les switch discovery protocols aident les administrateurs réseau à recueillir des informations de configuration et de connexion concernant les physical ou virtual switches.
vSphere prend en charge les protocoles de découverte suivants :
- Cisco Discovery Protocol (CDP) : pour les vSphere standard switches et distributed switches connectés à des Cisco physical switches.
- Link Layer Discovery Protocol (LLDP) : un protocole neutre vis-à-vis des fournisseurs, uniquement pour les distributed switches.
Les standard switches peuvent être configurés pour utiliser CDP.
Les distributed switches peuvent utiliser CDP ou LLDP.
Les switch discovery protocols aident les administrateurs réseau à déterminer les capacités d’un périphérique réseau. Ces informations peuvent être utiles pour le dépannage de problèmes réseau.
Le Cisco Discovery Protocol (CDP) a été développé par Cisco Systems pour diffuser des informations sur les périphériques connectés au niveau 2 du réseau. CDP est pris en charge dans vSphere depuis la version 4.0.
Le Link Layer Discovery Protocol (LLDP) prend en charge le protocole de découverte standardisé IEEE 802.1AB et n’est disponible que sur les distributed switches.
Les périphériques réseau utilisent CDP ou LLDP pour annoncer leur identité, leurs capacités et leurs voisins sur un réseau.
¶ Configuration de CDP ou LLDP
Avec CDP ou LLDP activé, vous pouvez configurer un virtual switch pour différents modes de fonctionnement :
- Listen : les informations sont reçues des physical switches.
- Advertise : les informations sont envoyées aux physical switches.
- Both : les informations sont à la fois envoyées et reçues des physical switches.
Avec CDP et LLDP, le vSphere Client peut identifier les propriétés d’un physical switch, telles que le nom du switch, le numéro de port, et la vitesse ou les paramètres duplex du port.
Vous pouvez également configurer CDP ou LLDP afin que les informations concernant les physical adapters et les noms d’hôtes ESXi soient transmises aux switches compatibles CDP ou LLDP.
Vous pouvez configurer le discovery protocol pour utiliser l’un des modes de fonctionnement suivants :
- Listen (default) : L’hôte ESXi détecte et affiche des informations sur le port du physical switch associé, mais les informations concernant le virtual switch ne sont pas disponibles pour l’administrateur du physical switch.
- Advertise : L’hôte ESXi fournit des informations sur le virtual switch à l’administrateur du physical switch, mais ne détecte ni n’affiche d’informations sur le physical switch.
- Both : L’hôte ESXi détecte et affiche des informations sur le physical switch associé et fournit des informations sur le virtual switch à l’administrateur du physical switch.
Vous pouvez utiliser la commande esxcli pour activer CDP sur un standard switch.
¶ À propos du Port Binding
Le port binding détermine quand et comment une VM virtual NIC est attribuée à un port de virtual switch.
Le port binding est configuré au niveau du distributed port group, et les options de binding incluent :
- Static binding (default) : vCenter attribue un port permanent pour la VM ou l’interface VMkernel.
- Ephemeral : ESXi (et non vCenter) attribue le port à la VM. Le port attribué change lorsque la VM redémarre.
Options d’allocation de port pour le static binding :
- Elastic (default) : lorsque tous les ports sont attribués, un nouvel ensemble de huit ports est créé.
- Fixed : aucun port supplémentaire n’est créé lorsque tous les ports sont attribués.
Lorsque vous connectez une VM à un port group configuré avec un static binding, un port est immédiatement attribué et réservé à la VM, garantissant la connectivité à tout moment.
Le port est déconnecté uniquement lorsque la VM est supprimée du port group. Le static binding est recommandé pour une utilisation générale.
Si vous sélectionnez le static binding, le nombre par défaut de ports est fixé à huit. Elastic est le paramètre d’allocation de port par défaut.
Avec le ephemeral binding, un port est créé et attribué à une VM lorsque la VM est mise sous tension et que sa NIC est en état connecté.
Le port est supprimé lorsque la VM est éteinte ou que la VM NIC est déconnectée.
Vous pouvez effectuer des attributions de ports ephemeral via l’ESXi host et vCenter, ce qui offre de la flexibilité pour gérer les connexions réseau des VM directement depuis l’hôte lorsque vCenter est hors service.
Seul un ephemeral binding permet de modifier les connexions réseau des VM lorsque vCenter est indisponible. Cependant, le trafic réseau n’est pas affecté par une panne de vCenter, quel que soit le type de port binding.
Utilisez les ephemeral port groups uniquement à des fins de récupération, lorsque vous souhaitez provisionner des ports directement sur un ESXi host, en contournant vCenter, et pas dans d’autres cas.
¶ Configuration du Inbound Traffic Shaping
Les Distributed Switches prennent en charge le traffic shaping entrant et le traffic shaping sortant.
Alors que le traffic shaping sortant (ou egress) est pris en charge à la fois par les standard switches et les distributed switches, le traffic shaping entrant (ou ingress) n’est pris en charge que par les distributed switches.
Le trafic entrant correspond au trafic circulant depuis le réseau physique vers le virtual switch puis vers les VMs.
¶ Méthode d’équilibrage de charge : Physical NIC Load
Cette méthode est prise en charge uniquement sur les distributed switches et constitue la politique recommandée pour les distributed port groups.
L’équilibrage de charge basé sur la charge physique des NICs garantit que la capacité des cartes réseau physiques dans une équipe de NICs est optimisée.
Cette fonctionnalité fonctionne de la manière suivante :
- Elle déplace les flux d’E/S (I/O flows) entre les uplinks.
- Un flux est déplacé uniquement lorsque l’utilisation moyenne en émission ou en réception d’un uplink dépasse 75 % de sa capacité sur une période de 30 secondes.
Pour utiliser cette méthode, modifiez les paramètres du distributed port group, puis sélectionnez Route based on physical NIC load.
Cette méthode de NIC teaming vérifie la charge réelle des uplinks et réduit la charge sur ceux qui sont surchargés. Aucun changement sur le switch physique n’est nécessaire.
Le distributed switch calcule les uplinks pour les VMs en vérifiant l’ID de port de la VM ainsi que le nombre d’uplinks dans le NIC team.
Le distributed switch teste les uplinks toutes les 30 secondes.
Si la charge d’un uplink dépasse 75 % d’utilisation, l’ID de port de la VM ayant l’I/O le plus élevé est déplacé vers un autre uplink.
La méthode "Route based on physical NIC load" n’est pas la stratégie de regroupement (teaming policy) par défaut. Vous devez configurer la stratégie pour l’utiliser sur un distributed switch.
Cette méthode présente des avantages :
- Faible surcharge de l’algorithme, car le distributed switch calcule les uplinks pour les machines virtuelles une seule fois et la vérification des uplinks a un impact minimal.
- Le distributed switch est conscient de la charge des uplinks et veille à la réduire si nécessaire.
- Aucun changement n’est requis sur le physical switch.
Cette méthode présente des inconvénients :
- La bande passante disponible pour les machines virtuelles est limitée aux uplinks qui sont connectés au distributed switch.
¶ Lab 8 : Configuration des vSphere Distributed Switches
Créer et configurer un distributed switch :
- Créer un Distributed Switch
- Ajouter des hôtes ESXi au Distributed Switch
- Vérifier la configuration de votre Distributed Switch
Retrouvez le lien du Lab en cliquant ici : Lab 8 : Configuration des vSphere Distributed Switches
¶ Revue des objectifs d’apprentissage
• Reconnaitre la différence entre standard switches et distributed switches
• Identifier les avantages et les fonctionnalités des distributed switches
• Créer un distributed switch
¶ Points clés
• Les virtual switches peuvent avoir les types de connexion suivants : ports VM, port VMkernel et liaisons physiques (uplinks).
• Un standard switch est une configuration de switch virtuel pour un seul hôte.
• Un distributed switch fournit des fonctions similaires à un standard switch, mais il définit une configuration unique, gérée par vCenter et partagée entre tous les hôtes associés.
• Vous définissez des politiques réseau sur les virtual switches pour configurer des propriétés liées à la sécurité, la performance et la disponibilité.
• Les politiques réseau définies au niveau d’un standard switch peuvent être remplacées au niveau du port group. Les politiques réseau définies au niveau d’un distributed switch port group peuvent être remplacées au niveau du port individuel.
Chapitre précédent : 4 - Déploiement et configuration de vCenter - Chapitre suivant : 6 - Configuration du stockage vSphere