¶ Importance
À mesure que vous développez votre environnement vSphere, les fonctionnalités et capacités du vSphere Distributed Switch (vDS) peuvent vous aider à gérer efficacement la mise en réseau.
¶ Leçons du module
- Gestion des vSphere Distributed Switches
- Utilisation du contrôle d’E/S réseau (Network I/O Control) dans les Distributed Switches
- NetFlow et miroir de port (Port Mirroring) dans les Distributed Switches
- vSphere Distributed Services Engine
¶ Leçon 1 : Gestion des vSphere Distributed Switches
¶ Objectifs d’apprentissage
- Gérer le trafic réseau à l’aide de la politique de filtrage et de marquage du trafic
- Identifier les Distributed Switches NSX dans le client vSphere
- Effectuer une vérification de l’état d’un Distributed Switches
- Sauvegarder et restaurer la configuration d’un Distributed Switches
- Décrire le rétablissement automatique (rollback) et la récupération des configurations réseau
¶ À propos des Distributed Switches
Un distributed switch fonctionne comme un switch virtuel unique à travers tous les hôtes associés.
Les distributed switches présentent plusieurs avantages par rapport aux switches standards :
- Les distributed switches centralisent l’administration du réseau virtuel et simplifient la gestion du centre de données.
- Les ports des distributed switches sont attribués de manière statique par vCenter et offrent un contrôle plus granulaire sur les statistiques et les politiques réseau.
Avoir la configuration réseau au niveau du centre de données (vSphere Distributed Switch), et non au niveau de l’hôte (switch standard), offre 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 hôte à un cluster et le rendre compatible avec vSphere vMotion est beaucoup plus simple qu’avec un switch standard.
- Les ports distribués migrent lorsque les machines virtuelles (VM) sont migrées. Par exemple, lorsque vous migrez une VM avec vSphere vMotion, les statistiques et politiques du port distribué se déplacent avec la VM, ce qui simplifie le débogage et le dépannage.
Voici la traduction en français de cette page, en respectant tes règles :
(ne pas traduire Traffic filtering, marking Policy, vSphere Distributed Switches, ni Data Center)
¶ À propos de la Traffic Filtering et Marking Policy
Avec la Traffic filtering et marking Policy pour les vSphere Distributed Switches, vous pouvez protéger votre réseau virtuel contre le trafic indésirable et les attaques de sécurité, et gérer le trafic réseau afin de respecter les objectifs définis dans les accords de niveau de service (SLA).
La Traffic filtering et marking Policy possède les caractéristiques suivantes :
- Elle peut autoriser ou refuser certains types de trafic.
- Elle peut appliquer une balise QoS (Quality of Service) pour marquer un certain type de trafic.
- Elle est équivalente à la fonctionnalité Access Control List (ACL) disponible sur les Switches physiques.
La Traffic filtering and marking Policy se compose d’une ou plusieurs règles de trafic réseau, définies au niveau du Distributed Port Group ou du Uplink Port Group.
Utilisez la Traffic filtering et marking Policy pour créer un ensemble de règles de sécurité et de marquage QoS (Quality of Service) des paquets circulant à travers les ports d’un Distributed Switch.
Le Distributed Switch applique des règles sur le trafic à différents endroits du flux de données. Il peut appliquer des règles de trafic réseau sur le chemin de données entre l’adaptateur réseau de la VM et le port distribué. Il peut également appliquer des règles de trafic réseau entre le port uplink et l’adaptateur réseau physique.
La Traffic filtering et marking Policy est prise en charge uniquement sur les Distributed Switches.
¶ Création de "Network Traffic Rules"
Vous pouvez définir des Network Traffic Rules pour le traitement du trafic lié aux machines virtuelles (VM) ou aux adaptateurs physiques.
En général, une Network Traffic Rule se compose d’un qualificateur pour le trafic et d’une action permettant de restreindre ou de prioriser le trafic correspondant.
Dans une Network Traffic Rule, l’action Allow permet au trafic de passer à travers le port du Distributed Switch ou le port uplink, tandis que l’action Drop bloque le trafic.
L’action Tag marque (ou étiquette) le trafic passant par le port du Distributed Switch ou le port uplink.
Du point de vue du Distributed Switch :
- Ingress signifie entrant depuis la VM, le port vmkernel, ou depuis un uplink.
- Egress signifie sortant vers la VM, vers le port vmkernel, ou vers un uplink.
Un qualificateur représente un ensemble de critères de correspondance liés à une couche réseau.
Vous pouvez faire correspondre le trafic selon le type de trafic système, les propriétés de trafic de la couche 2 ou de la couche 3.
Vous pouvez utiliser le qualificateur pour une couche réseau spécifique, ou combiner plusieurs qualificateurs pour identifier les paquets plus précisément.
¶ Network Traffic Rule : Exemple 1
Cette règle autorise le trafic entrant provenant des systèmes sur le VLAN 32 ayant une adresse MAC commençant par 00:50:56, et rejette tout autre trafic.
Utilisez un qualificateur de trafic MAC pour définir les critères de correspondance relatifs aux propriétés de la couche 2 (couche de liaison de données) des paquets.
Ces propriétés incluent l’adresse MAC, l’identifiant VLAN (VLAN ID) et un protocole qui consomme la charge utile de la trame (IPv4, IPv6 ou Address Resolution Protocol).
La localisation du trafic avec un VLAN ID sur un groupe de ports distribués fonctionne avec Virtual Guest Tagging.
Pour faire correspondre le trafic au VLAN ID lorsque Virtual Switch Tagging est actif, utilisez une règle sur un groupe de ports uplink ou un port uplink.
¶ Network Traffic Rule : Exemple 2
Cette règle autorise le trafic entrant et sortant des machines virtuelles (VM), appelé Ingress/Egress.
Utilisez le qualificateur de trafic système pour faire correspondre les paquets au type de données d’infrastructure virtuelle qui transitent par les ports du groupe de ports distribués.
Dans cet exemple, la règle impose que le trafic passant par le groupe de ports pg-SA Production soit du trafic de machine virtuelle (VM).
Le Distributed Switch rejette tout autre type de trafic envoyé à ce groupe de ports.
Vous pouvez sélectionner le type de trafic transitant par les ports du groupe transportant les données système, telles que le trafic de gestion provenant de vCenter, du stockage iSCSI ou de vSphere vMotion.
Lorsque vous utilisez des qualificateurs pour le type de données système, les attributs des paquets des couches 2 et 3 définissent les propriétés que les paquets doivent respecter pour correspondre à la règle.
Ingress – Trafic sortant d’une interface physique.
Egress – Trafic entrant dans une interface physique.
¶ Marking Network Traffic
Vous pouvez attribuer des balises de priorité au trafic ayant des exigences réseau plus élevées en termes de bande passante, de faible latence, etc.
Vous pouvez marquer le trafic avec une balise Class of Service (CoS) dans la couche 2 ou une balise Differentiated Serviced Code Point (DSCP) dans la couche 3.
Le marquage du trafic présente les avantages suivants :
- Vous pouvez marquer le trafic important afin que le réseau physique ne laisse pas tomber ces paquets en cas de congestion.
- Vous pouvez assurer une Quality of Service (QoS) de bout en bout et répondre aux exigences des accords de niveau de service (SLA).
Le marquage, ou priority tagging, est une méthode pour indiquer qu’un trafic nécessite une QoS (Quality of Service) plus élevée. Grâce à cette balise de priorité, le réseau peut reconnaître différentes classes de trafic. Les équipements réseau peuvent alors traiter le trafic de chaque classe en fonction de sa priorité et de ses besoins.
Tout comme pour le traffic filtering, le marquage nécessite d’abord de classifier le trafic selon les qualificateurs suivants : system, MAC, et IP. Après avoir défini ces qualificateurs, vous pouvez décider de la manière dont vous souhaitez marquer le trafic.
Vous pouvez prioriser le trafic en utilisant une balise de priorité Class of Service (CoS), une balise Differentiated Serviced Code Point (DSCP), ou les deux.
Vous pouvez marquer le trafic avec une balise de priorité CoS dans l’en-tête de paquet de la couche 2. Les valeurs acceptées vont de 0 à 7.
Vous pouvez marquer le trafic avec une balise DSCP dans l’en-tête de paquet de la couche 3. Les valeurs acceptées vont de 0 à 63.
Vous pouvez attribuer des balises de priorité à des types de trafic tels que VoIP ou la vidéo en streaming, qui nécessitent des exigences réseau plus élevées en termes de bande passante, de faible latence, etc.
Cette règle marque les paquets SIP UDP entrants provenant du sous-réseau 192.168.2.0/24.
Cet exemple marque le trafic VoIP.
Les flux VoIP ont des exigences particulières en matière de QoS (Quality of Service), notamment en ce qui concerne la faible perte de paquets et la latence.
Le trafic lié au Session Initiation Protocol (SIP) pour la VoIP possède généralement une balise DSCP égale à 26.
¶ Accès au NSX Virtual Distributed Switch
vSphere 7 et les versions ultérieures prennent en charge à la fois les VDS et le NSX Virtual Distributed Switch (N-VDS).
- Les Switches logiques NSX peuvent être présentés dans vCenter sous la forme de groupes de ports virtuels.
- vSphere 7 et VMware NSX 3.0 doivent être configurés avec les versions minimales suivantes :
— vCenter 7.0
— ESXi 7.0 - vSphere 8 et VMware NSX 4.0 doivent être configurés avec les versions minimales suivantes :
— vCenter 8.0
— ESXi 7.0 - vCenter doit être enregistré auprès du NSX Manager en tant que compute manager.
- Pour que les Switches logiques soient visibles dans le vSphere Client, vous devez configurer le VDS avec le groupe de ports NSX provenant de la zone de transport.
VMware prend désormais en charge l’accélération basée sur DPU pour NSX dans VMware NSX 4.0.1.1.
NSX Manager fournit un accès complet pour la gestion des objets du NSX-T Data Center :
- Gérer la configuration du VDS
- Gérer la configuration des Switches logiques (NSX port groups)
- Gérer la configuration des ports NSX
vCenter fournit un accès limité aux objets du NSX-T Data Center :
-
Gérer la configuration du VDS
-
Accès limité aux NSX port groups et aux ports NSX :
- Vous pouvez consulter certaines données de configuration NSX.
- Vous pouvez attribuer des adaptateurs réseau de VM ou des vNICs aux NSX port groups.
- Vous pouvez utiliser vSphere vMotion pour migrer une VM vers ou depuis des NSX port groups.
- Vous pouvez ajouter des adaptateurs VMkernel aux NSX port groups.
À partir de vSphere 7, les NSX port groups se comportent comme des groupes de ports distribués réguliers, de sorte que les adaptateurs VMkernel peuvent être ajoutés aux NSX port groups depuis le vSphere Client.
Le vSphere Client ne prend pas en charge les actions suivantes sur les NSX port groups :
- Suppression
- Modification des paramètres
- Utilisation dans une session de mirroring de port
- Inclusion de la configuration dans les exportations VDS
¶ À propos de Health Check pour les Distributed Switch
Avec la fonction Health Check, vous pouvez identifier et dépanner les erreurs de configuration ou les incohérences entre les configurations des Switches virtuels et physiques dans un vSphere Distributed Switch.
En examinant régulièrement les paramètres des Distributed Switch et physiques, Health Check identifie les erreurs de configuration courantes suivantes :
- Trunks VLAN non correspondants entre le Distributed Switch et le Switch physique
- Paramètres MTU non correspondants entre le Distributed Switch, l’adaptateur physique et les ports du Switch physique
- Politiques d’association (teaming policies) du Switch virtuel non correspondantes pour les paramètres de canal de port (port-channel) du Switch physique
Health Check est une fonctionnalité qui détecte certaines incohérences entre les réseaux physiques et virtuels. Les paramètres clés, tels que les balises VLAN, les MTU et la configuration de l’association des NICs, doivent être configurés de manière cohérente sur les Switches physiques et virtuels. Une configuration incohérente peut entraîner des problèmes de connectivité réseau.
Health Check recherche les incohérences de configuration et les signale à l’administrateur.
L’intervalle de vérification par défaut est d’une minute.
Par exemple, une petite modification dans les paramètres d’un portgroup sur un VDS peut affecter les VMs et les ports VMkernel sur jusqu’à 2000 hôtes.
Comme bonne pratique, activez Health Check uniquement pendant de courtes périodes, car cette fonction crée de nombreuses adresses MAC et peut affecter le trafic de production.
¶ Exemple de Health Check
Deux hôtes ESXi utilisent un Distributed Switch avec deux port groups distribués, chacun connecté à deux Switches physiques.
En plus du Distributed Switch, deux Switches physiques avec leurs configurations de ports sont représentés.
Comparez le port group virtuel vert (VLAN 10) avec les paramètres du Switches physique 2.
Les paramètres VLAN ID et MTU sont identiques. Le port group virtuel est configuré avec la sélection d’équipe Port ID.
Mais comme cette configuration est interne au Switch virtuel et ne nécessite aucune configuration sur le Switch physique, les paramètres virtuels et physiques sont cohérents et ne devraient pas entraîner de problèmes de connectivité.
Comparez maintenant le port group virtuel orange (VLAN 20) avec les paramètres du Switch physique 1.
Les VLAN IDs et les MTU sont différents. Le paramètre d’équipe du port group virtuel est défini sur IP hash.
Pour que IP hash fonctionne correctement, EtherChannel ou Link Aggregation Control Protocol (LACP) doit être configuré sur le Switch physique.
Health Check peut détecter et signaler les différences de configuration entre le port group et la configuration du port du Switch en utilisant des paquets Ethernet de couche 2.
À des intervalles d’une minute (par défaut), des paquets de demande et d’accusé de réception sont échangés entre l’interface virtuelle et le Switch.
Lorsque des paquets sont perdus, un avertissement de configuration apparaît dans le vSphere Client.
¶ Activation du Health Check
Le Health Check peut être effectué sur les composants réseau suivants :
- VLAN et MTU
- Teaming et basculement
Le Health Check présente les exigences suivantes :
- Pour les vérifications de VLAN et MTU, au moins deux uplinks physiques doivent être connectés au Distributed Switch virtuel.
- Pour la vérification de la stratégie de Teaming, au moins deux uplinks actifs doivent faire partie du groupe, et au moins deux hôtes ESXi doivent être connectés au Distributed Switch virtuel.
Voir vSphere Networking à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-vcenter-80-networking-guide.pdf
¶ Surveillance des résultats du Health Check
Après avoir exécuté le Health Check pendant quelques minutes, vous pouvez surveiller les résultats dans le Distributed Switch > Monitor > Health du client vSphere.
Les détails de l’état de santé sont organisés en trois catégories : VLAN, MTU, et Teaming et basculement.
¶ Sauvegarde et restauration des configurations
Vous pouvez sauvegarder et restaurer la configuration de votre Distributed Switch, des groupes de ports distribués et du groupe de ports uplink pour des besoins de déploiement, de restauration ou de partage.
Les opérations suivantes sont prises en charge :
- Sauvegarder la configuration dans un fichier.
- Restaurer la configuration du Switch et du groupe de ports à partir d’une sauvegarde.
- Créer un Switch ou un groupe de ports à partir d’une sauvegarde.
- Revenir à une configuration précédente d’un groupe de ports après des modifications.
Vous effectuez ces opérations à l’aide des fonctions d’exportation, d’importation et de restauration disponibles pour les Distributed Switches.
D’autres options de restauration sont disponibles si la configuration d’un Switch est perdue, par exemple en cas de corruption de la base de données vCenter ou si le Switch virtuel ou les groupes de ports sont mal configurés.
D’autres méthodes pour restaurer le Switch virtuel incluent la restauration complète de la base de données ou la reconstruction du Switch. Bien que ces deux méthodes permettent de restaurer le Switch, elles peuvent être longues à exécuter.
¶ Exportation des configurations de Distributed Switch
Vous pouvez exporter les configurations du Distributed Switch et des groupes de ports distribués vers un fichier.
Lors de l’exportation, vous pouvez effectuer les tâches suivantes :
- Créer une sauvegarde de la configuration de votre Distributed Switch.
- Créer un modèle de configuration de Distributed Switch.
- Créer un système de contrôle de version pour votre configuration de Distributed Switch.
Vous exportez la configuration du Distributed Switch et du groupe de ports distribués vers un fichier sur le système exécutant le vSphere Client.
Le fichier conserve les configurations réseau valides, qui peuvent ensuite être distribuées vers d’autres déploiements.
Vous pouvez utiliser le fichier de sauvegarde créé par la fonction d’exportation comme modèle pour créer des configurations de Distributed Switch similaires sur d’autres vCenters.
Vous pouvez conserver des révisions en enregistrant la configuration du Distributed Switch après chaque modification. En conservant ces révisions, vous pouvez restaurer la configuration actuelle vers une version antérieure si nécessaire.
Vous pouvez automatiser cette tâche à l’aide des cmdlets PowerCLI suivantes :
Export-VDSwitch: Exporte la configuration d’un vSphere Distributed Switch spécifié vers un fichier ZIP.Export-VDPortGroup: Exporte la configuration d’un groupe de ports distribués spécifié vers un fichier ZIP.
¶ Restauration et importation des configurations de Distributed Switch
Après avoir exporté une configuration de Distributed Switch, vous pouvez restaurer ou importer une configuration :
- La restauration réinitialise la configuration d’un Distributed Switch existant à partir d’un fichier de configuration exporté.
- L’importation crée un Distributed Switch à partir d’un fichier de configuration exporté.
Vous pouvez utiliser la fonction de restauration pour réinitialiser une configuration de Distributed Switch qui est devenue corrompue.
Vous pouvez utiliser la fonction d’importation pour créer un Distributed Switch, par exemple, sur un autre système vCenter.
Avec les fonctions de restauration et d’importation, vous pouvez recréer une configuration de Distributed Switch.
La restauration d’une configuration de Distributed Switch écrase les paramètres actuels du Distributed Switch et de ses groupes de ports. La pleine fonctionnalité est rétablie si les paramètres réseau échouent ou si la base de données vCenter est corrompue.
La fonction de restauration ne supprime pas les groupes de ports qui ne font pas partie du fichier de configuration.
Lorsque vous importez une configuration de Distributed Switch, un nouveau Distributed Switch est créé, ce qui vous permet de générer plusieurs copies d’un déploiement existant.
¶ Rollback et Recovery du réseau de Management de l’hôte
Le rollback empêche toute mauvaise configuration accidentelle et toute perte de connectivité de l’hôte à vCenter en revenant à la configuration réseau de gestion valide précédente.
Le rollback offre les options suivantes pour récupérer après une mauvaise configuration du réseau de gestion :
- Rollback automatique si une mauvaise configuration est détectée.
- Interface utilisateur de la console directe (DCUI) pour récupérer manuellement le réseau de gestion lorsque le rollback automatique est désactivé.
Le rollback et la récupération automatiques constituent une fonctionnalité de vSphere qui aide à prévenir les pannes du réseau de gestion. Vous protégez le réseau de gestion des manières suivantes :
-
La fonctionnalité de rollback automatique détecte toute modification de configuration sur le réseau de gestion.
Si l’hôte ne peut pas atteindre vCenter, les modifications ne sont pas appliquées. -
Vous pouvez également reconfigurer le réseau de gestion sur le Distributed Switch virtuel en utilisant l’interface utilisateur de la console directe (DCUI).
En utilisant la DCUI pour modifier les paramètres réseau du Switch, ces paramètres sont appliqués à tous les hôtes connectés à ce Switch.
¶ Détails du Rollback
En annulant les changements de configuration, vSphere protège les hôtes contre la perte de connexion à vCenter due à une mauvaise configuration du réseau de gestion.
Les mises à jour qui déclenchent un rollback sont les suivantes :
-
Rollback au niveau de l’hôte : déclenché par une modification dans les configurations réseau de l’hôte, comme un changement de vitesse de la carte réseau physique (NIC), un changement de configuration MTU ou une modification des paramètres IP.
-
Rollback au niveau du Distributed Switch : se produit après qu’un utilisateur met à jour des objets liés au Distributed Switch, tels qu’un port group ou des ports distribués.
Si vous effectuez une modification via le vSphere Client, vCenter peut déclencher un rollback sur un vDS.
Si vous effectuez une modification via le CLI ou le host client, alors c’est l’hôte lui-même qui déclenche le rollback.
Le rollback est activé par défaut.
Les types de mises à jour suivants peuvent également déclencher un rollback :
-
Si une modification dans la configuration réseau de l’hôte provoque des problèmes de connectivité entre l’hôte et le système vCenter, un rollback se produit.
Des exemples de mauvaises configurations incluent : une incompatibilité dans la vitesse ou le duplex de la carte réseau physique (NIC), une incompatibilité dans la configuration du jumbo frame ou une mauvaise configuration des paramètres IP du réseau de gestion. -
Si une mauvaise configuration du Distributed Switch virtuel provoque des problèmes de connectivité entre les hôtes et le système vCenter, un rollback peut se produire.
Les mauvaises configurations de port group et de ports virtuels distribués peuvent entraîner des interruptions de réseau causées par des pannes du réseau de gestion des hôtes.
¶ Récupération via la DCUI
Si le rollback est désactivé, une méthode alternative de récupération consiste à utiliser la DCUI.
Cela permet à l’utilisateur de se connecter directement à l’hôte et de corriger les propriétés du Distributed Switch.
La récupération via la DCUI doit être effectuée pour chaque hôte individuellement.
Pour restaurer manuellement la configuration depuis la DCUI, suivez ces étapes :
- Dans la DCUI, appuyez sur la touche F2.
- Lorsque vous y êtes invité, connectez-vous à la DCUI avec les identifiants appropriés.
- Utilisez la flèche vers le bas pour faire défiler jusqu’à Network Restore Options, puis appuyez sur Entrée.
- Sous Network Restore Options, sélectionnez Restore vDS pour restaurer les paramètres réseau distribués.
Vous pouvez soit restaurer les paramètres de l’hôte à la configuration par défaut bloquée,
soit restaurer la politique d’association (teaming policy) par défaut de l’hôte. - Sélectionnez l’option appropriée et appuyez sur Entrée.
¶ Lab 7 : Configuration des vSphere Distributed Switches
Créez et configurez un Distributed Switch :
- Créer un Distributed Switch
- Ajouter des hôtes ESXi au Distributed Switch
- Examiner la configuration de votre Distributed Switch
- Migrer des machines virtuelles (VM) vers un autre Distributed Switch Port Group
Retrouvez le lien du Lab en cliquant ici : Lab 7 : Accéder à l'environnement de lab
¶ Lab 8 : Gestion des vSphere Distributed Switches
Utilisez le vSphere Client pour créer et gérer un vSphere Distributed Switch (VDS) au niveau du centre de données :
- Ajouter un nouveau Port Group au VDS
- Activer la vérification d’intégrité (Health Check) du VDS
- Examiner l’état de la vérification d’intégrité du VDS
- Corriger les problèmes du VDS
- Désactiver le service de vérification d’intégrité du VDS
- Sauvegarder la configuration du VDS
- Vérification des connaissances (Knowledge Check)
Retrouvez le lien du Lab en cliquant ici : Lab 8 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Gérer le trafic réseau à l’aide de la politique de filtrage et de marquage du trafic
- Reconnaître les NSX virtual distributed switches dans le vSphere Client
- Effectuer une vérification d’intégrité (health check) d’un distributed switch
- Sauvegarder et restaurer la configuration d’un distributed switch
- Décrire le rollback automatique et la récupération des configurations réseau
¶ Leçon 2 : Utilisation de Network I/O Control dans les Distributed Switches
¶ Objectifs d’apprentissage
- Décrire comment Network I/O Control améliore les performances
- Décrire comment utiliser Network I/O Control pour allouer la bande passante à différents types de trafic système
- Décrire comment utiliser Network I/O Control pour allouer la bande passante aux machines virtuelles (VMs)
¶ À propos de Network I/O Control
Vous pouvez utiliser Network I/O Control pour allouer la bande passante réseau aux applications critiques pour l’entreprise et pour résoudre les situations où la bande passante réseau est insuffisante pour répondre aux besoins de plusieurs types de trafic.
Network I/O Control alloue la bande passante réseau sur les Distributed Switches en utilisant des pools de ressources réseau (Network Resource Pools) pour le trafic des machines virtuelles (VM) et le trafic système.
vSphere 6.x a ajouté la prise en charge de Network I/O Control 3.0, qui inclut les fonctionnalités suivantes :
-
Vous pouvez réserver de la bande passante pour le trafic système et le trafic des machines virtuelles (VM) en fonction de la capacité des adaptateurs physiques sur un hôte.
-
Vous pouvez définir des limites pour spécifier la bande passante maximale qu’un certain type de trafic peut consommer sur un adaptateur. Si personne d’autre n’utilise la bande passante supplémentaire, le type de trafic ayant une limite définie ne peut pas non plus l’utiliser.
-
Vous disposez d’un contrôle détaillé des ressources au niveau de l’adaptateur réseau de la VM.
Cette fonctionnalité est similaire au modèle utilisé pour l’allocation des ressources CPU et mémoire. Vous utilisez des shares, des reservations et des limits pour contrôler la bande passante.
¶ À propos du modèle d’allocation de bande passante pour le trafic système
Network I/O Control permet de configurer des Shares, Limits et Reservations afin de contrôler la manière dont la bande passante est allouée à la fois au trafic système (comme le management, iSCSI, vSAN, etc.) et au trafic des machines virtuelles (VM).
| Paramètre de bande passante | Description |
|---|---|
| Shares | La priorité relative d’un type de trafic système par rapport aux autres types de trafic système actifs sur le même adaptateur physique. Utilisez les valeurs suivantes pour définir le nombre de shares :
|
| Reservations | La bande passante minimale, en Mbps, qui doit être garantie sur un seul adaptateur physique. |
| Limits | La bande passante maximale, en Mbps ou Gbps, qu’un type de trafic système peut consommer sur un seul adaptateur physique. |
Le System Traffic correspond à la gestion de tous les types de trafic utilisant les adaptateurs réseau physiques.
Le VM Traffic correspond à la gestion du trafic d’une machine virtuelle spécifique via sa carte réseau virtuelle (vNIC), selon le paramètre de trafic système défini pour le trafic VM.
La quantité de bande passante disponible pour un type de trafic système est déterminée par ses shares relatives et la quantité de données que les autres fonctionnalités système transmettent.
La bande passante réservée mais non utilisée devient disponible pour d’autres types de trafic système. Cependant, Network I/O Control ne redistribue pas la capacité de trafic système inutilisée vers le placement des VM.
Par exemple, vous configurez une reservation de 2 Gbps pour iSCSI. Comme iSCSI utilise un seul chemin, le Distributed Switch peut ne jamais appliquer cette réservation sur un adaptateur physique. La bande passante non utilisée n’est donc pas allouée au trafic VM.
Network I/O Control ne peut pas toujours répondre à un besoin potentiel de bande passante pour le trafic système. L’incapacité à réaffecter la bande passante réservée inutilisée au trafic système des VM est particulièrement critique dans le cas d’un nouveau chemin iSCSI où vous devez fournir de la bande passante à un nouvel adaptateur VMkernel.
¶ Configuration de l’allocation de bande passante pour le trafic système
Pour utiliser Network I/O Control, vous pouvez configurer les shares, les réservations de bande passante (bandwidth reservations) et les limites (limits) pour chaque type de trafic système.
Vous pouvez utiliser Network I/O Control pour configurer l’allocation de bande passante pour le trafic associé aux principales fonctionnalités de vSphere :
- VMs
- Management
- vSphere vMotion
- NFS
- vSphere Fault Tolerance
- iSCSI
- vSphere Replication
- vSAN
- vSphere Data Protection
¶ Réservation de bande passante pour le trafic système
Network I/O Control alloue la bande passante demandée sur chaque adaptateur réseau physique.
Vous ne pouvez pas réserver plus de 75 % de la bande passante d’un adaptateur réseau physique.
Vous pouvez garantir une bande passante minimale à une fonction système afin d’assurer un fonctionnement optimal, selon la capacité des adaptateurs physiques.
Pour un Distributed Switch connecté à des hôtes ESXi équipés d’adaptateurs réseau 10 GbE, vous pouvez configurer une réservation afin de garantir 1 Gbps pour le trafic vSphere vMotion, 1 Gbps pour vSphere Fault Tolerance, 0,5 Gbps pour le trafic des VMs et ainsi de suite.
Vous pouvez laisser une partie de la capacité non réservée afin que l’hôte puisse allouer dynamiquement la bande passante en fonction des shares, des limits et de l’utilisation, et ne réserver que la bande passante nécessaire au bon fonctionnement d’une fonction système.
Vous pouvez réserver jusqu’à 75 % de la bande passante d’un adaptateur réseau physique.
Par exemple, si votre hôte ESXi utilise un adaptateur réseau de 40 GbE, alors 30 Gbps (0,75 × 40) peuvent être réservés.
Le vSphere Client affiche les informations sur l’utilisation de la bande passante ainsi que les valeurs de shares, de réservation et de limite pour chaque type de trafic.
¶ Agrégation de bande passante pour les pools de ressources réseau
Un pool de ressources réseau représente une partie de la bande passante agrégée réservée pour le trafic système des machines virtuelles sur tous les adaptateurs physiques connectés au Distributed Switch.
Par défaut, les Distributed Port Groups sont attribués au pool de ressources réseau nommé default, dans lequel aucun quota n’est configuré.
Network I/O Control alloue la bande passante pour les machines virtuelles (VM) sur l’ensemble du Distributed Switch et sur l’adaptateur physique transportant le trafic des VM.
Pour utiliser Network I/O Control afin d’activer l’allocation de bande passante pour le trafic des VM, configure le trafic système des VM.
La réservation de bande passante pour le trafic des VM est également utilisée dans le contrôle d’admission (admission control).
Lors du démarrage d’une VM, le contrôle d’admission vérifie qu’une bande passante suffisante est disponible.
¶ Création de Network Resource Pools
Une fois qu’une réservation a été configurée pour le type de trafic des VM, tu peux créer un pool de ressources réseau pour réserver de la bande passante pour un ensemble de VM.
Par exemple, si le trafic système des VM a 0,5 Gbps réservé pour chaque uplink de 10 GbE sur un Distributed Switch possédant 10 uplinks, la bande passante agrégée totale disponible pour la réservation de trafic VM est de 5 Gbps.
Chaque pool de ressources réseau peut réserver un quota à partir de cette capacité de 5 Gbps.
La réservation de bande passante dédiée à un pool de ressources réseau est partagée entre les Distributed Port Groups associés à ce pool.
Une VM reçoit la bande passante du pool via le Distributed Port Group auquel elle est connectée.
¶ Allocation de bande passante pour le trafic des machines virtuelles (VM)
La bande passante est allouée individuellement aux VM en fonction des parts, réservations et limites configurées pour les adaptateurs réseau des VM.
| Paramètre de bande passante | Description |
|---|---|
| Shares (Parts) | Définit la priorité relative du type de trafic à travers l’adaptateur réseau de la VM, par rapport à la capacité de l’adaptateur physique qui transporte le trafic de la VM vers le réseau. Utilise les valeurs suivantes pour définir le nombre de parts :
|
| Reservations (Réservations) | La bande passante minimale, en Mbps, que l’adaptateur réseau de la VM doit recevoir sur l’adaptateur physique. |
| Limits (Limites) | La bande passante maximale sur l’adaptateur réseau de la VM pour le trafic vers d’autres VM situées sur le même hôte ou sur un autre hôte. |
Un pool de ressources réseau fournit un quota de réservation aux VM.
Ce quota représente une partie de la bande passante réservée pour le trafic système des VM sur les adaptateurs physiques connectés au Distributed Switch.
Il est possible d’allouer une portion de cette bande passante réservée aux VM associées au pool.
La somme des réservations de bande passante des adaptateurs réseau des VM sous tension associées au pool ne doit pas dépasser le quota de ce pool.
¶ Allocation de bande passante pour les machines virtuelles individuelles
La réservation totale de bande passante des machines virtuelles (VMs) sur un hôte ne peut pas dépasser la bande passante réservée configurée pour le trafic système des VM.
Pour garantir la bande passante, Network I/O Control met en œuvre un moteur de placement du trafic qui devient actif lorsqu’une VM a une réservation de bande passante configurée. Le Distributed Switch tente alors de diriger le trafic d’un adaptateur réseau de VM vers un adaptateur physique capable de fournir la bande passante requise et conforme à la politique d’association (teaming) active.
La limite réelle et la réservation dépendent également de la politique de modelage du trafic (traffic shaping) sur le groupe de ports distribués auquel l’adaptateur est connecté.
Par exemple, si un adaptateur réseau de VM demande une limite de 200 Mbps et que la bande passante moyenne configurée dans la politique de modelage est de 100 Mbps, la limite effective devient 100 Mbps.
¶ Contrôle d’admission de la bande passante dans vSphere DRS
Le contrôle d’admission de la bande passante vérifie que la réservation de bande passante de la machine virtuelle (VM) peut être respectée.
Lorsqu’une VM est mise sous tension dans un cluster avec DRS activé, vSphere DRS place la VM sur un hôte ayant la capacité de garantir la bande passante réservée pour cette VM.
Si vous mettez sous tension une VM qui appartient à un cluster, vSphere DRS place cette VM sur un hôte disposant de la capacité nécessaire pour garantir la bande passante qui lui est réservée, conformément à la politique d’association (teaming) active.
Pour utiliser le contrôle d’admission dans vSphere DRS, vous devez effectuer les tâches suivantes :
- Configurer l’allocation de bande passante pour le trafic système des VM sur le Distributed Switch.
- Configurer les besoins en bande passante d’une VM connectée au Distributed Switch.
Si une réservation de bande passante ne peut pas être respectée, la VM n’est pas mise sous tension.
vSphere DRS migre une VM vers un autre hôte pour satisfaire la réservation de bande passante d’une VM dans les cas suivants :
- La réservation est modifiée vers une valeur que l’hôte actuel ne peut plus satisfaire.
- L’adaptateur physique transportant le trafic de la VM devient hors ligne.
Dans cet exemple, Host1 perd un lien montant (uplink), ne conservant qu’un seul lien fonctionnel.
Comme les liens montants de Host2 fonctionnent toujours, vSphere DRS migre VM1 ou VM2 vers Host2 afin de répondre à l’exigence de réservation de bande passante de la VM.
¶ Contrôle d’admission de la bande passante dans vSphere HA
Lorsqu’un hôte tombe en panne, vSphere HA remet sous tension les machines virtuelles défaillantes sur un autre hôte du cluster, capable de satisfaire la réservation de bande passante et la politique d’association (teaming policy).
Le contrôle d’admission de la bande passante empêche une VM de démarrer si la réservation de bande passante définie pour cette VM ne peut pas être respectée.
Pour utiliser le contrôle d’admission dans vSphere HA, vous devez effectuer les tâches suivantes :
- Allouer la bande passante pour le trafic système des VM.
- Configurer les besoins en bande passante d’une VM connectée au "Distributed Switch".
¶ Activité : Network I/O Control
Vous souhaitez garantir que les VMs connectées à un groupe de ports distribués appelé Prod 1 puissent accéder à 25 % de la bande passante réservée disponible pour le trafic des VM.
Utilisez les informations de réservation de bande passante de l’exemple ci-dessous pour répondre à la question suivante :
Que devez-vous configurer pour fournir la bande passante appropriée aux VMs sur Prod 1 ?
Le montant total agrégé de la bande passante réservée pour le trafic des machines virtuelles est de 48 Gbps.
Vingt-cinq pour cent de ce montant agrégé représentent 12 Gbps.
Par conséquent, vous devez configurer un pool de ressources réseau avec une réservation de 12 Gbps pour Prod 1.
¶ Revue des objectifs d’apprentissage
- Décrire comment Network I/O Control améliore les performances.
- Expliquer comment utiliser Network I/O Control pour allouer la bande passante aux différents types de trafic système.
- Expliquer comment utiliser Network I/O Control pour allouer la bande passante aux machines virtuelles.
¶ Leçon 3 : NetFlow et Port Mirroring dans les Distributed Switches
¶ Objectifs d’apprentissage
- Décrire comment utiliser NetFlow pour surveiller la sécurité et les performances du réseau.
- Configurer le Port Mirroring sur un Distributed Switch.
¶ À propos de NetFlow
NetFlow est un outil d’analyse réseau permettant de surveiller le réseau et d’observer le trafic des machines virtuelles transitant par un Distributed Switch.
Vous pouvez utiliser NetFlow pour le profilage du réseau, la détection et la prévention d’intrusions, l’analyse médico-légale du trafic réseau et la conformité réglementaire.
Les Distributed Switches de vSphere prennent en charge IPFIX (NetFlow version 10).
NetFlow est un protocole développé par Cisco Systems pour analyser le trafic réseau.
C’est une spécification standard de l’industrie pour la collecte de données réseau destinées à la surveillance et aux rapports.
Les sources de données sont les périphériques réseau, tels que les switches et les routeurs.
Pour les déploiements ESXi, NetFlow permet une surveillance détaillée et une analyse du trafic réseau des machines virtuelles.
Les Standard Switches ne prennent pas en charge NetFlow.
Les collecteurs NetFlow sont disponibles auprès de fournisseurs tiers.
¶ À propos des Network Flows
Un network flow (flux réseau) est une séquence unidirectionnelle de paquets.
Chaque paquet partage un ensemble commun de propriétés.
NetFlow capture les types de flux suivants :
- Internal flow : représente le trafic intra-hôte entre les VMs d’un même hôte.
- External flow : représente le trafic inter-hôtes entre VMs sur des hôtes différents, ainsi que le trafic entre machines physiques et VMs.
Les enregistrements de flux sont envoyés à un collecteur NetFlow pour analyse.
Les network flows offrent une vision complète du trafic des VMs, qui peut être collectée pour des analyses historiques et utilisée à de multiples fins.
Les internal flows proviennent du trafic entre VMs sur le même hôte.
Les external flows proviennent du trafic entre VMs sur des hôtes différents ou sur des Distributed Switches distincts. Ils incluent également le trafic entre machines physiques et VMs.
Un flow est une séquence de paquets partageant les mêmes propriétés — telles que les adresses IP source et destination, les ports source et destination, les identifiants d’interfaces d’entrée et de sortie, et le protocole utilisé.
Un flow est unidirectionnel. Les flows sont traités et stockés sous forme d’enregistrements par les périphériques réseau compatibles (comme un Distributed Switch).
Ces enregistrements sont ensuite envoyés à un collecteur NetFlow pour analyse complémentaire.
Bien que le traitement des flows soit une méthode efficace, NetFlow peut solliciter fortement le Distributed Switch. En effet, NetFlow nécessite un traitement et un stockage supplémentaires sur l’hôte pour pouvoir traiter et exporter les enregistrements de flux.
¶ Analyse des flux réseau
Les données de flux réseau sont envoyées à un collecteur NetFlow tiers, qui accepte et stocke les enregistrements de flux réseau.
NetFlow envoie les données agrégées de flux réseau à un collecteur NetFlow. Des fournisseurs tiers proposent leurs propres produits de collecteurs NetFlow.
Un collecteur NetFlow accepte et stocke les enregistrements complets de flux réseau.
Les fonctionnalités des collecteurs NetFlow peuvent varier selon le fournisseur.
Un collecteur NetFlow offre généralement les fonctionnalités suivantes :
- Un logiciel d’analyse permettant d’extraire, d’agréger et de générer des rapports à partir des données collectées.
- Un système de stockage à long terme pour archiver les données de flux réseau.
- Une interface utilisateur personnalisée, souvent basée sur un navigateur web.
Le collecteur NetFlow peut produire des rapports sur différents types d’informations réseau, notamment :
- Les principaux flux réseau consommant le plus de bande passante sur un Switch (virtuel) donné.
- Les adresses IP présentant un comportement anormal.
- Le nombre d’octets envoyés et reçus par une VM donnée au cours des 24 dernières heures.
Un collecteur NetFlow stocke les données basées sur les flux et analyse les données collectées :
-
Inclut une base de données pour stocker les données collectées :
- Vous pouvez identifier et isoler une utilisation excessive de la bande passante réseau, des goulots d’étranglement et un trafic applicatif inattendu.
- Vous pouvez consulter des enregistrements historiques afin de diagnostiquer la cause des pannes ou des violations.
-
Extrait, agrège et génère des rapports à partir des données collectées :
- Vous pouvez analyser le trafic réseau selon le taux, le volume et l’utilisation.
- Vous pouvez analyser les tendances du trafic des VM et des hôtes.
Grâce aux données NetFlow, vous pouvez identifier les causes d’une utilisation excessive de la bande passante, de goulots d’étranglement et de trafic applicatif inattendu.
Les enregistrements historiques que vous stockez à long terme peuvent vous aider à diagnostiquer la cause de ces pannes ou anomalies.
Comme NetFlow recueille ses données depuis des dispositifs réseau compatibles, aucune sonde réseau supplémentaire n’est nécessaire pour collecter les données basées sur les flux.
Les collecteurs et analyseurs NetFlow peuvent fournir un ensemble de données détaillé sur la performance du réseau.
Avec un espace de stockage suffisant sur le collecteur NetFlow, les données de flux peuvent être archivées pendant une longue période, offrant ainsi un historique à long terme du comportement réseau.
¶ Configuration de NetFlow sur les Distributed Switches
Vous configurez les paramètres NetFlow sur un Distributed Switch.
Pour configurer NetFlow sur un Distributed Switch, spécifiez les paramètres suivants :
- Adresse IP du collecteur et port du collecteur
- ID de domaine d’observation (Observation Domain ID)
- Adresse IP du switch
Pour configurer NetFlow sur un Distributed Switch, spécifiez les paramètres NetFlow suivants :
-
Collector IP address et Collector port : L’adresse IP et le numéro de port utilisés pour communiquer avec le système collecteur NetFlow. Ces valeurs sont attribuées par le collecteur.
-
Observation Domain ID : Une valeur qui identifie les informations liées au switch lors de la configuration des paramètres NetFlow Settings d’un vSphere Distributed Switch.
-
Switch IP address : Une adresse IP optionnelle utilisée pour identifier la source du flux réseau vers le collecteur NetFlow. L’adresse IP n’est pas associée à un port réseau, et elle n’a pas besoin d’être joignable par ping.
Cette adresse IP est utilisée pour remplir le champ d’adresse IP source dans les paquets NetFlow.
Grâce à cette adresse, le collecteur NetFlow peut interagir avec le Distributed Switch comme un seul switch,
plutôt que comme un switch distinct et non relié pour chaque hôte associé.
Si cette adresse IP n’est pas configurée, l’adresse IP de gestion de l’hôte est utilisée à la place.
Pour une description des paramètres avancés de NetFlow, consultez vSphere Networking à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-vcenter-80-networking-guide.pdf
¶ Activation de NetFlow sur un Distributed Port Group
Après avoir configuré NetFlow sur le Distributed Switch, vous pouvez activer ou désactiver NetFlow sur un Distributed Port Group, un port spécifique ou sur l’uplink.
¶ À propos du Port Mirroring
Le Port Mirroring duplique les paquets réseau d’une source vers une destination.
Il a les utilisations suivantes :
- Aide au dépannage
- Fournit des données d’entrée pour les outils d’analyse réseau
De nombreux fournisseurs de Switch réseau intègrent la fonction de port mirroring dans leurs produits.
Le vSphere Port Mirroring prend en charge les fonctionnalités suivantes :
- Switched Port Analyzer (SPAN)
- Remote SPAN (RSPAN)
- Encapsulated RSPAN (ERSPAN)
Avec RSPAN, le trafic dupliqué peut être envoyé vers un moniteur distant.
La session RSPAN peut s’étendre sur plusieurs sauts de Switches au sein d’un réseau.
Avec ERSPAN, la session peut s’étendre sur un réseau IP.
Sur les Switches physiques, les administrateurs doivent souvent dupliquer le trafic (mirror traffic) vers des ports spécifiques lorsqu’ils dépannent des problèmes liés au réseau.
Le Port Mirroring est couramment utilisé pour les appliances réseau qui nécessitent une surveillance du trafic, comme les systèmes de détection d’intrusion.
De nombreux fournisseurs de Switches réseau intègrent le port mirroring dans leurs produits.
Par exemple, sur un Switch Cisco Systems, cette fonctionnalité est appelée Switched Port Analyzer (SPAN).
Avec le port mirroring, vous n’avez pas besoin d’activer le mode promiscuité (promiscuous mode) sur un Distributed Switch pour dépanner des problèmes réseau.
Si vous activez le mode promiscuité sur un port distribué, ce port voit tout le trafic réseau qui passe par le Distributed Switch.
Vous ne pouvez pas sélectionner le port ou le port group qu’un port en mode promiscuité est autorisé à voir : le port promiscuité voit tout le trafic du domaine de broadcast.
Le port mirroring prend en charge :
- Cisco Remote Switch Port Analyzer (RSPAN)
- Encapsulated Remote Switch Port Analyzer (ERSPAN)
¶ Types de sessions de Port Mirroring
Vous créez une session de port mirroring pour dupliquer le trafic d’un Distributed Switch vers des ports, des uplinks ou des adresses IP distantes.
Vous devez sélectionner un type de session de port mirroring.
Vous pouvez choisir parmi les options de session de port mirroring suivantes :
-
Distributed Port Mirroring :
Le port mirroring entre des ports distribués ne peut être que local.
Si les ports source et destination se trouvent sur des hôtes différents (en raison d’une migration vSphere vMotion), la duplication du trafic entre eux ne fonctionne pas.
Cependant, si les ports source et destination se déplacent vers le même hôte, le port mirroring fonctionne. -
Remote Mirroring Source :
Lorsqu’un port distribué source est déplacé de l’hôte A vers l’hôte B, le chemin de duplication d’origine (du port source au port de destination de l’uplink de A) est supprimé sur l’hôte A.
Un nouveau chemin de duplication du port source vers le port de destination sur B est créé.
L’uplink utilisé est déterminé par le nom d’uplink spécifié dans la session. -
Remote Mirroring Destination :
Lorsqu’un port distribué de destination est déplacé de l’hôte A vers l’hôte B, tous les chemins de duplication d’origine depuis les VLAN sources vers le port de destination sont transférés de A vers B. -
Encapsulated Remote Mirroring (L3) Source :
Lorsqu’un port distribué source est déplacé de l’hôte A vers l’hôte B, tous les chemins de duplication d’origine du port source vers les adresses IP de destination sont transférés de A vers B.
Correspondance entre les types de sessions et les protocoles :
- Distributed Port Mirroring : RSPAN
- Remote Mirroring Source : RSPAN
- Remote Mirroring Destination : RSPAN
- Encapsulated Remote Mirroring (L3) Source : ERSPAN
¶ Propriétés d’une session de Port Mirroring
Vous pouvez configurer une ou plusieurs propriétés avancées selon le type de session de port mirroring que vous sélectionnez.
Une session de type Distributed Port Mirroring peut avoir les propriétés suivantes :
- Type de pile TCP/IP (par défaut ou miroir)
- Entrées/Sorties normales (I/O) sur les ports de destination (peuvent être autorisées ou interdites)
- Longueur des paquets dupliqués (en octets)
- Taux d’échantillonnage des paquets
- Description
Chaque session de port mirroring est identifiée de manière unique par son nom.
Une session peut également avoir une description.
Pour une description détaillée des propriétés de session avancées, consultez la documentation vSphere Networking à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-vcenter-80-networking-guide.pdf
¶ Source et destination dans une session de Port Mirroring
Une session de port mirroring nécessite des informations sur la source et la destination.
Les détails de la source comprennent :
- La direction du trafic
- Un ou plusieurs identifiants de port (port IDs)
Les détails de la destination comprennent :
- Un ou plusieurs identifiants de port (port IDs)
- Un ou plusieurs uplinks
- Une adresse IP
Lorsque vous créez une session de port mirroring, vous devez configurer la source et la destination. Lors de la configuration de la source, vous devez spécifier la direction du trafic.
La direction du trafic est classée comme ingress ou egress. Le trafic ingress correspond au trafic circulant de la machine virtuelle source (VM) vers le Distributed Switch. Le trafic egress correspond au trafic circulant du Distributed Switch vers la machine virtuelle source (VM).
Pour éviter la saturation du réseau avec le trafic dupliqué, le port mirroring comporte les restrictions suivantes :
- Dans une session, un port ne peut pas être à la fois une source et une destination.
- Un port ne peut pas être la destination de plus d’une session.
- Un port en mode promiscuité ne peut pas être une source ou une destination egress.
- Une source egress ne peut pas être une destination pour des sessions, afin d’éviter les boucles de duplication de trafic.
¶ Lab 9 : Utiliser le Port Mirroring
Configurez le port mirroring et capturez le trafic réseau sur un Distributed Switch :
- Préparer la capture du trafic réseau dupliqué
- Configurer le Port Mirroring sur le Distributed Switch
- Vérifier que le Port Mirroring capture bien le trafic
- Restaurer la configuration du Distributed Switch
Retrouvez le lien du Lab en cliquant ici : Lab 9 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Décrire comment utiliser NetFlow pour surveiller la sécurité et les performances du réseau
- Configurer le Port Mirroring sur un Distributed Switch
¶ Leçon 4 : vSphere Distributed Services Engine
¶ Objectifs d’apprentissage
- Définir vSphere Distributed Services Engine
- Décrire les cas d’usage et les avantages de vSphere Distributed Services Engine
- Expliquer les composants architecturaux de vSphere Distributed Services Engine
¶ SmartNICs
Une SmartNIC est une carte réseau (NIC) dotée d’un processeur généraliste, d’une gestion out-of-band et de fonctionnalités de périphériques virtualisés.
-
General-purpose CPU : Disposer d’un processeur généraliste permet d’exécuter du code et des applications directement sur la NIC, comme les services réseau et de stockage, ce qui améliore les performances (grâce à un accès rapide au chemin d’E/S réseau) et permet d’économiser des cycles CPU.
-
Out-of-band management : Le complexe CPU présent sur la SmartNIC peut être géré indépendamment du processeur principal du serveur.
-
Virtualized device functionality : Les SmartNICs peuvent exposer des périphériques “virtuels” sur le bus PCI qui apparaissent pour le système d’exploitation et les applications du processeur central comme de véritables périphériques matériels.
Les SmartNICs sont également appelées Data Processing Units (DPU).
¶ Les challanges des Infrastructures Traditionnelles
Certains des challanges rencontrés dans les environnements actuels sont les suivants :
- Répondre aux nouvelles exigences des applications modernes
- Partage des ressources CPU de l’Hypervisor entre les applications et l’infrastructure (réseau, stockage et tâches de gestion de l’Hypervisor)
- Impact des performances des services réseau et de sécurité sur les applications
- Isolation insuffisante entre le fournisseur et le locataire dans les environnements multi-locataires basés sur des bare metal clouds
- Les applications modernes exigent : rapidité de déploiement, haute disponibilité, sécurité des applications et de meilleures performances.
- Les ressources CPU de l’Hypervisor ne sont pas dédiées aux applications modernes, ce qui crée des goulots d’étranglement au niveau du CPU et des entrées/sorties (I/O).
- Les bare metal clouds suscitent un intérêt croissant parmi les clients ayant des charges de travail à haute performance, un accès direct au matériel et des environnements multi-locataires personnalisés. Cependant, ils manquent d’isolation entre le réseau du fournisseur et celui du locataire, contrairement aux environnements SDDC typiques.
¶ À propos de vSphere Distributed Services Engine
Dans vSphere 8, vSphere Distributed Services Engine exploite la puissance des SmartNICs / Data Processing Units (DPUs) pour le traitement matériel accéléré des données, afin d’améliorer les performances de l’infrastructure.
vSphere Distributed Services Engine utilise les SmartNICs / DPUs pour :
- Booster les performances de l’infrastructure
- Renforcer la sécurité de l’infrastructure grâce à un modèle zero-trust amélioré
- Simplifier la gestion de l’infrastructure et des charges de travail
¶ Infrastructure de nouvelle génération avec vSphere Distributed Services Engine
Les SmartNICs offrent les avantages suivants :
- Ressources CPU dédiées et accélération matérielle (HW acceleration).
- Déchargement complet du datapath pour atteindre un débit très élevé et une latence très faible.
- Les services de sécurité peuvent être activés directement sur la SmartNIC / DPU sans impact sur les performances.
- Capacités avancées d’observabilité et d’exploitation pour la surveillance, le dépannage, la journalisation et la conformité.
- Isolation entre le locataire (tenant) et le fournisseur (provider), à la fois sur ESXi et sur les plateformes bare metal (disponible dans les prochaines versions).
l’architecture de nouvelle génération exécute les services NSX directement sur la SmartNIC)
¶ Avantages de vSphere Distributed Services Engine
Voici les principaux cas d’utilisation de vSphere Distributed Services Engine :
- Applications nécessitant une bande passante réseau élevée
- Déchargement des services de sécurité pour de meilleures performances
- Exigences accrues d’observabilité
- Déchargement réseau pour les applications nécessitant une bande passante élevée, comme les applications de diffusion vidéo
- Déchargement des services de sécurité pour améliorer les performances des applications ayant des exigences élevées en matière de sécurité ou de chiffrement
¶ Écosystème de vSphere Distributed Services Engine
Les principaux constructeurs de systèmes (OEM) tels que Dell Technologies, HPE ou Lenovo intègrent vSphere Distributed Services Engine dans leurs plateformes.
¶ Changements d’architecture avec vSphere Distributed Services Engine
Les principaux changements apportés par l’architecture vSphere Distributed Services Engine sont :
- Les services NSX et les services d’infrastructure tels que storage et I/O control s’exécutent sur le processeur de vSphere Distributed Services Engine.
- De nouveaux modules sont requis pour exécuter les fonctionnalités ESXi et NSX sur la nouvelle architecture vSphere Distributed Services Engine :
— ESXiO
— NSXiO
La nouvelle architecture exécute les services d’infrastructure sur le SmartNIC, fournissant la séparation nécessaire entre les charges de travail applicatives s’exécutant sur la plateforme de calcul x86 et les services d’infrastructure.
Le matériel SmartNIC est indépendant du kernel et dispose d’un pipeline programmable avec des CPUs dédiés. Cela permet d’exécuter directement la virtualisation réseau et stockage sur la NIC, économisant ainsi des cycles CPU x86 et améliorant les performances grâce à l’offload.
Ces modules sont requis pour exécuter les fonctionnalités ESXi et NSX dans la nouvelle architecture utilisant des SmartNICs :
- ESXiO : composant ESXi léger fonctionnant sur le processeur ARM dans une SmartNIC
- NSXiO : composants NSX (composants de transport node) s’exécutant sur la SmartNIC
¶ Composants matériels de vSphere Distributed Services Engine
Composants de vSphere Distributed Services Engine :
- Flash memory pour stocker l’image de démarrage et le local storage
- Port Ethernet pour la gestion
- Deux ports SFP ou plus pour le High Speed Ethernet
- Programmable hardware accelerator pour le traitement des paquets et le datapath offloading
- Processeurs ARM embarqués avec leur propre mémoire, permettant d’économiser les cycles CPU x86 du serveur et d’améliorer les performances réseau
- Virtualized Device Functions pour exposer les fonctions de périphériques virtuels à l’hôte ESXi.
Un grand nombre de périphériques physiques et virtuels sont inclus (NVMe, VMXNET3, PCIe).
¶ Revue des objectifs d’apprentissage
- Définir vSphere Distributed Services Engine
- Décrire les cas d’utilisation et les avantages de vSphere Distributed Services Engine
- Expliquer les composants architecturaux de vSphere Distributed Services Engine
¶ Points clés
- Un Distributed Switch fournit des fonctions similaires à celles d’un Switch standard. Cependant, le Distributed Switch définit une configuration unique partagée entre tous les hôtes associés.
- Network I/O Control attribue la bande passante à chaque type de trafic système en utilisant des partages, réservations et limites.
- Les configurations du Distributed Switch et du Distributed Port Group peuvent être sauvegardées et restaurées.
- Les Distributed Switches prennent en charge l’utilisation d’outils d’analyse et de dépannage réseau, notamment NetFlow et Port Mirroring.
- vSphere Distributed Services Engine exploite la puissance des SmartNICs/Data Processing Units (DPUs) pour accélérer le traitement matériel des données et améliorer les performances de l’infrastructure.
Chapitre précédent : 3 - Opérations du cluster vSphere - Chapitre suivant : 5 - Opérations de stockage