dimanche , 27 mai 2018
Templates by BIGtheme NET

VMware vSphere : Les reseaux

La gestion du réseau sous vSphere 5 est réalisée au travers d’une des deux technologies suivantes :

  • vSphere Standard Switch (appelé vSS ou vSwitch) est un switch virtuel simple à configurer dont la gestion se fait indépendamment sur chaque ESXi.

res1

  • vSphere Distributed Switch (ou vDS) est un switch distribué qui propose une gestion centralisée et uniforme sur un ensemble de serveurs ESXi (350 maximum par vDS). Cela permet de garantir une consistance au niveau de la configuration et de la sécurité lors de mobilité des VM entre serveurs.

res2

vSS est simple d’utilisation mais alourdit le travail des administrateurs pour des grands environnements car chaque modification de configuration doit être répliquée sur chaque ESXi, alors que vDS fournit une gestion centralisée sur un ensemble de serveurs, limitant ainsi les opérations. Un autre inconvénient de vSS concerne la migration d’une VM avec vMotion, car l’état du réseau de la VM est réinitialisé, ce qui rend complexes la supervision et les opérations de Troubleshooting.

D’autres solutions tierces existent comme par exemple le switch Cisco Nexus 1000v qui est également un Switch distribué mais en apportant des fonctionnalités évoluées et qui fournit une gestion unifiée Cisco pour l’environnement physique et virtuel. Intéressant pour les grands environnements.

Avec les switchs virtuels vSS ou vDS, l’équipe réseau n’a pas de visibilité directe sur la configuration interne des vSwitchs car ils sont gérés directement par le VMkernel et donc souvent par l’équipe dédiée VMware. Le Nexus 1000v permet aux équipes réseau de prendre le contrôle de toute la configuration réseau et de l’appliquer au niveau des VM.

À noter également le switch virtuel distribué d’IBM : System Networking Distributed Virtual Switch 5000V (IBM DVS5000v).

2. vSphere Standard Switch (vSS)

vSphere Standard Switch opère au niveau 2 (comme un switch réseau de niveau 2) au sein du VMkernel et permet de relier les composants physiques du réseau aux composants réseau virtuels.

Lorsque vous faites un design de l’architecture réseau, et si vous souhaitez utiliser les fonctionnalités telles que vMotion ou DRS, il est nécessaire de mettre les hôtes dans le même sous-réseau de niveau 2 car ESXi ne prend pas en charge la migration vMotion de machines virtuelles entre des hôtes qui sont dans différents domaines de diffusion.

Ce switch virtuel apporte une très grande souplesse d’utilisation en permettant de créer très facilement une architecture réseau évoluée telle qu’une DMZ, des VLAN (ESXi supporte 802.1Q VLAN Tagging, VLAN ID en 1 et 4095), des VM totalement isolées du réseau de l’entreprise ou connectées à des réseaux différents. Il est possible de faire cohabiter plusieurs réseaux au sein d’un même vSwitch ou de créer des vSwitchs séparés pour chaque réseau.

Le vSwitch peut avoir une ou plusieurs cartes réseau physiques associées (jusqu’à 32 cartes GbE et 8 cartes 10 GbE par ESXi). Dans le cas où plusieurs cartes réseau sont associées, il est possible de les regrouper en une seule carte logique afin de proposer de la redondance et de la répartition de charge (appelé NIC Teaming). Il est également possible d’avoir un vSwitch sans carte réseau physique associée et ainsi créer un réseau totalement isolé de l’extérieur.

res3

Schéma permettant de voir ce qu’il est possible ou impossible de faire avec des vSwitchs : lorsque deux machines virtuelles d’un serveur ESXi sont connectées au même vSwitch, le trafic réseau est routé localement et n’utilise pas de bande passante du réseau physique externe. Il est possible de connecter plusieurs cartes réseau sur un même vSwitch. Mais une carte réseau physique (uplink) ne peut pas être connectée à plusieurs vSwitchs différents. Il n’est pas possible de relier deux vSwitchs entre eux.

a. Communication des VM avec les éléments du réseau

En environnement virtuel, deux types de réseau existent : le réseau virtuel géré par VMkernel et le réseau physique.

res4

Représentation schématique des différents composants réseau en environnement VMware.

Chaque machine virtuelle possède une ou plusieurs cartes réseau virtuelles appelées vNIC possédant chacune une MAC Address, une adresse IP (IPv4 ou IPv6), un driver et répondant au protocole standard Ethernet.

VMware génère par défaut automatiquement une MAC Address par carte réseau virtuelle dans la VM. Cette valeur commence par 00:0C:29 puis 3 octets générés par le propre algorithme de VMware. Il est possible de définir une MAC Address manuellement dans la plage d’adresses 00:50:56:00:00:00 à 00:50:56:3F:FF:FF.

Les VM au travers de la carte virtuelle vNIC se connectent à un vSwitch qui possède 2 côtés : l’un virtuel et l’autre physique.

  • Côté réseau virtuel du vSwitch, il y a les Virtual Ports et les Port Groups. Les VM connectent leur vNIC à des Virtual Ports du vSwitch (pouvant être considérés comme un port RJ45 virtuel) associé à un Port Group (qui correspond généralement à un VLAN ou groupe de ports spécifique). Chaque vSwitch peut avoir 1016 virtuals ports actifs (plus 8 ports réservés par le VMkernel pour son propre usage).

    Deux types de connexion peuvent être utilisés pour la définition d’un Port Group : Virtual Machine ou VMkernel.

res5

La notion de Port Group n’existe que dans des environnements virtualisés. Cela permet d’appliquer une politique au niveau de la sécurité, de la segmentation du réseau, de la gestion du trafic, et sert également à améliorer la disponibilité et optimiser les performances.

Virtual Machine Port Group : utilisé par les machines virtuelles pour se connecter à l’environnement physique et pour communiquer entre elles. Dans le cas où aucune carte réseau n’est connectée, le réseau est totalement isolé de l’extérieur du serveur et la communication entre les VM se fera au niveau du VMkernel (interne à l’ESXi).

VMkernel Port : utilisé pour le réseau de management, le trafic vMotion, l’utilisation d’un réseau de stockage IP ou Fault Tolerance. Le VMkernel port requiert une adresse IP et au moins une carte réseau physique connectée. Ce type de port est également utilisé pour administrer le serveur ESXi pour communiquer avec une interface utilisateur, par exemple le vSphere client.

Le VMkernel port de management et le VMkernel du vMotion et de Fault Tolerance doivent être dans des sous-réseaux différents et des VLAN séparés.

  • Du coté réseau physique, il existe des cartes réseau physiques appelées uplinks (ou pnics : physicals nics). Les pnics sont les ports réseau physiques. Lorsqu’ils sont attachés à un vSwitch, ils deviennent des VMnics.

    Un lien VMnic peut être déclaré dans un vSwitch en 2 modes :

  • Adaptateur actif : les adaptateurs utilisés par le switch standard.

  • Adaptateur standby : adaptateur qui devient actif dès lors qu’un adaptateur actif est défaillant.

Le paramétrage des cartes réseau au niveau de la vitesse et du Duplexing doit être forcé jusqu’à 100 Mb. À partir de la norme Gb on laisse en Autonegociate côté switch et carte réseau. Lorsque l’on décide de forcer un port, il est très important de forcer des deux côtés et pas uniquement côté ESXi ou côté switch.

Conseil : les pnics, une fois assignés, portent des ID VMnics numérotées de 0 à n. Si on a 2 ports réseau intégrés sur la carte mère et 1 carte PCI dual ports, on peut anticiper leur numérotation avant même la mise en service du serveur physique pour fournir aux équipes d’intégration les plans de précâblage. Les vmnics sont numérotées par PCI id, ce qui signifie que le port 1 de la carte mère sera vmnic 0, le port 2 de la carte mère vmnic1, et ainsi de suite. Il est intéressant de regarder le schéma de la carte mère pour insérer les cartes réseau afin d’augmenter la redondance à l’intérieur du châssis et ainsi pallier la panne d’un riser ou d’un bus interne de la carte mère, éliminant ainsi un SPOF.

b. Configuration

Virtual Machine Port Group

res6

Lors de la création d’un Port Group Virtual Machine, il faut renseigner le nom du Port Group et en option le VLAN ID utilisé (entre 1 et 4095).

Un VLAN (Virtual LAN) permet de partager un réseau physique et de le segmenter de façon logique afin de réduire le nombre d’équipements réseau (tels que les switchs, les cartes réseau…). Cela réduit également l’utilisation de multiples sous-réseaux logiques. De plus, les VLAN offrent une meilleure gestion du trafic, une séparation des flux et une isolation entre les VLAN. L’interconnexion entre deux switchs physiques se fait au travers de Trunk permettant de préserver l’appartenance aux VLAN de chaque trame pour conserver le numéro de VLAN ID.

Un fois le vSwitch créé, il faut configurer la politique du Port Group.

Les paramètres à configurer pour les vSwitchs sont les suivants :

General

General permet de configurer le nombre de ports disponibles au sein du vSwitch (de 8 ports à 4088 ports) et le MTU (de 1280 à 9000).

res7

Security

res8

  • Promiscuous Mode : ce mode (par défaut sur Reject) interdit à une carte réseau virtuelle d’une VM d’observer le trafic réseau du vSwitch sur lequel il est connecté. Pour des raisons de sécurité, il n’est pas recommandé d’activer ce mode. Cependant, des VM peuvent être dédiées à la surveillance du réseau pour la détection d’intrusion par exemple ; dans ce cas, il est alors utile d’activer cette fonctionnalité.

  • MAC Address Changes et Forged Transmits : permet d’autoriser ou d’interdire une différence entre la MAC Address dans le fichier de configuration vmx et la MAC Address dans le Guest OS.

Afin de bien comprendre, expliquons en détail : lorsqu’une VM est créée sous VMware, 2 adresses MAC existent : une initiale et une effective.

La MAC Address initiale est celle générée par VMware dans la plage 00:50:56:00:00:00 à 00:50:56:3F:FF:FF (ou 00:0C:29 qui est modifiable dans le fichier vmx). Le Guest OS n’a aucun contrôle sur cette MAC Address.

La MAC Address effective est celle qui est utilisée pour communiquer avec les autres éléments du réseau. Par défaut, ces 2 adresses sont identiques. Cependant, il est possible de forcer et de mettre manuellement une autre MAC Address dans le Guest OS (il faut aller dans les paramètres avancés de la carte réseau). Il est possible d’autoriser ou d’interdire une différence entre la MAC Address dans le fichier de configuration vmx et la MAC Address dans le Guest OS grâce au paramètre MAC Address Changes et Forged Transmits. MAC Address Changes est relatif au trafic entrant alors que Forged Transmits est pour le trafic sortant.

Exemple

Si MAC Address Changes est mis sur Reject et si les 2 adresses MAC ne sont pas identiques, alors tout trafic entrant est interdit.

Pour un niveau de sécurité élevé, VMware recommande de mettre les 2 paramètres en Reject (par défaut). Cependant, il arrive parfois pour certaines machines converties de physique à virtuel de forcer la VM à reprendre l’adresse MAC de l’ancienne machine physique car l’éditeur n’existe plus ou le software utilisé dans la machine virtuelle n’est plus maintenu. Auquel cas, si la licence qui fait tourner ce logiciel est attachée à la MAC Address, il faudra récupérer un MAC non VMware. Il faut dans ce cas mettre l’option en Accept.

Forged Transmits doit être mis en Accept dans un environnement Microsoft NLB en mode Unicast. Se référer à l’article de la KB de VMware : Microsoft NLB not working properly in Unicast Mode.

Traffic Shaping

Traffic Shaping permet de limiter la bande passante au niveau du switch (Bandwidth) pour le trafic sortant en Kbits/s. Il est désactivé par défaut. Dans le cas de vDS, Traffic Shaping se fait pour le trafic sortant et entrant.

res9

Les valeurs paramétrables sont Average Bandwidth en Kbits/s, Peak Bandwidth en Kbits/s et Burst Size en Kbytes.

NIC Teaming

NIC Teaming est le regroupement de plusieurs cartes réseau physiques associées à un vSwitch. Ce regroupement permet de répartir la charge de travail (Load Balancing) entre les différentes cartes réseau physiques et fournit de la tolérance de panne dans le cas où une carte tombe en panne.

res10

Le Load Balancing est une répartition de charge basée sur le nombre de connexions et non pas sur le trafic réseau. Il n’est géré que pour le trafic sortant et se base sur 3 politiques différentes :

  • Route based on the originating virtual port ID :

Dans cette configuration, la répartition de charge est basée sur le nombre de cartes réseau physiques et le nombre de virtual ports utilisés. Avec cette politique de configuration, une carte réseau virtuelle connectée à un port du vSwitch utilisera toujours la même carte réseau physique (VMnic). Dans le cas où une carte réseau physique tombe en panne, la carte réseau virtuelle est redirigée vers une autre carte réseau physique.

Exemple

Si 10 VM sont connectées à un vSwitch avec 5 cartes réseau physiques, avec NIC Teaming la répartition est alors la suivante : sur chaque carte réseau physique, 2 VM seront connectées.

Autre exemple

Si 5 VM sont connectées sur un vSwitch avec 6 cartes réseau physiques, alors les 5 VM seront connectées à 5 cartes réseau physiques différentes et une carte réseau physique ne sera utilisée qu’en cas de défaillance d’une des 5 cartes. Il est important de noter que l’affectation à un port ne se fait qu’à l’allumage de la VM ou lors d’un Failover. La répartition se fait par le taux d’occupation d’un port au moment de l’allumage de la VM.

  • Route based on source MAC hash

C’est le même principe que précédemment, mais cela se base sur le nombre d’adresses MAC.

  • Route based on ip hash

La limitation des 2 précédentes politiques est que les réseaux virtuels utilisent toujours la même carte réseau physique. IP hash based load balancing utilise la source et la destination de l’adresse IP pour déterminer quelle sera la carte réseau physique à utiliser. Grâce à cet algorithme, une machine virtuelle peut communiquer avec plusieurs cartes réseau physiques différentes en fonction de sa destination. Cette option impose la configuration des ports du switch physique en Etherchannel.

Network Failover Detection : tolerance de panne. Il est possible de choisir entre Link status only ou Beacon Probing.

  • Link status only permet de détecter des pannes liées aux câbles ou au switch du réseau physique. Mais attention, les problèmes de configuration ne sont pas détectés.

  • La méthode Beacon Probing permet de détecter des pannes non détectées par Link status only en envoyant des trames Ethernet Broadcast au travers de toutes les cartes réseau. Ces trames réseau autorisent le vSwitch à détecter les mauvaises configurations et forcent le Failover si des ports sont bloqués. Au regard des meilleures pratiques VMware, il est recommandé d’avoir au moins 3 cartes pour activer cette fonctionnalité.

VMkernel Port

res11

VMkernel Port se configure de la même façon que le Virtual Machine Port Group avec en plus la configuration de l’adressage IP et le choix entre vMotionFault Tolerance Logging, Management Traffic et iSCSI port Binding.

3. vSphere Distributed Switch (vDS)

vSphere 5 propose un switch distribué appelé vSphere Distributed Switch (vDS) à partir de la version Enterprise Plus.

res12

Alors qu’un vSwitch Standard gère le réseau pour un seul serveur hôte, vSphere Distributed Switch est géré par vCenter Server et est distribué pour tous les serveurs hôtes ESXi associés. vDS garantit une configuration réseau consistante lorsque les VM migrent d’un serveur ESXi à un autre avec vMotion. Cela permet de gérer le réseau de façon unifiée en adressant les serveurs ESXi du Datacenter de façon homogène. vDS possède un ou plusieurs dvPortgroups permettant ainsi d’appliquer une politique pour le réseau. Les Distributed Port groups sont créés en un point unique : le vCenter, et les ESXi héritent ainsi tous de la configuration.

Lorsqu’on migre une VM avec vMotion, les statistiques des ports distribués et leur politique associée sont maintenues, simplifiant les opérations de debugging et Troubleshooting.

Avec vDS, il est possible de mettre en place de la qualité de service au travers de NIOC (Network IO Control).

Les dvUplinks fournissent un niveau d’abstraction pour les cartes réseau physiques (VMnics) de chaque hôte. La politique appliquée sur vDS et dvPortgroup est appliquée sur le dvUplinks et non plus sur chaque carte réseau de chaque hôte. Chaque carte réseau est ainsi associée à un dvUplink.

Les vDS permettent aussi de gérer l’attachement des VM à des ports de trois façons :

  • Liaison statique : pour affecter un port à une machine virtuelle quand la machine virtuelle se connecte au dvPortgroup.

  • Liaison dynamique : pour affecter un port à une machine virtuelle à la première mise sous tension de la machine virtuelle une fois connecté au Distributed port. Cette liaison est obsolète sous ESXi5.0.

  • Ephémère : pour aucune liaison de port.

vDS permet également l’utilisation de Private VLAN (PVLAN). Les PVLAN permettent d’isoler le trafic entre VM dans le même VLAN, fournissant ainsi de la sécurité additionnelle entre les VM sur le même sous-réseau. PVLAN est très utile sur des DMZ lorsque les serveurs ont besoin d’être accessibles de l’extérieur et de l’intérieur de l’entreprise.

À noter que le vDS est obligatoire pour l’utilisation de vCloud Director.

À la différence de VSS qui supporte le Traffic Shaping uniquement pour le trafic sortant (egress), vDS supporte le Traffic Shaping pour le trafic entrant et sortant (Ingress et egress).

vSphere 5 supporte Netflow avec vDS. Netflow permet de collecter des informations sur le trafic de flux entre la source et la destination. Cela donne la possibilité aux administrateurs de visualiser les communications réseau entre les VM afin d’aider à la détection des intrusions, profiling ou toute autre procédure malveillante. Toutes les informations sont envoyées sur un Netflow collector.

a. Architecture vDS

res13

Au sein d’un vDS, il y a le Control Plane et l’I/O Plane. Ces 2 éléments sont séparés. vCenter Server gère le Control Plane qui est en charge de la configuration de vDS, des ports distribués, uplinks et NIC Teaming et coordonne la migration des ports. I/O Plane est caché et il est implémenté comme un vSwitch standard au sein du VMkernel sur chacun des hôtes ESXi. Son rôle est de gérer les flux. Sur chaque hôte tourne un agent IO Plane (process VMkernel) qui est responsable de la communication entre Control Plane et I/O Plane.

b. Network IO Control (NIOC)

Au même titre que SIOC pour le stockage, NIOC permet de mettre de la Qualité de service (QoS) pour le réseau et fournit une gestion du trafic réseau et un contrôle des I/O réseau avec des switchs distribués vDS. L’administrateur peut ainsi définir pour chaque type de trafic et groupe de VM des règles de partage (share), de limite et de priorité QoS pour les différents types de trafic au niveau :

  • des VM

  • du réseau de management

  • iSCSI

  • NFS

  • Fault Tolerance

  • vMotion

  • User-defined

  • vSphere replication

NIOC est très intéressant dans les infrastructures réseau consolidées 10 GbE car cela permet de partager et de limiter les différents types de trafic.

4. Cisco NEXUS 1000v

a. Qu’est-ce que le Nexus 1000v ?

Cisco Nexus 1000v est une appliance réseau virtuelle s’intégrant au sein du Datacenter virtuel VMware. Cette appliance permet d’étendre à l’ensemble des machines virtuelles d’un serveur la politique réseau définie pour le Datacenter au niveau VLAN, sécurité, filtrage… Il fournit une interface unique pour provisionner, superviser et administrer aussi bien le réseau physique que virtuel en utilisant les outils classiques de management des équipements Cisco.

Cette appliance comporte deux composants : le VSM (Virtual Supervisor Module) et le VEM (Virtual Ethernet Module).

b. Architecture

res14

Le vSwitch distribué Cisco Nexus 1000v est composé de deux éléments :

Le VSM : c’est le module (déployé sous forme d’appliance virtuelle) permettant de configurer le switch virtuel en ligne de commande. Il peut être doublé pour assurer de la haute disponibilité. Chaque VSM supporte jusqu’à 64 VEM.

Le VEM : c’est le composant qui s’intègre entre la carte réseau physique et la carte réseau virtuelle dans la VM. Il remplace les vSwitchs VMware et est responsable de l’envoi des paquets au bon endroit. Il est installé sur chaque ESXi et est configuré via le VSM. Un agent DPA (Data Plane Agent) reçoit les informations depuis le vCenter.

Le composant VEM communique avec le VSM via 3 canaux distincts :

Management : canal utilisé par les serveurs ESXi et le serveur vCenter. Le VSM utilise ce canal pour dialoguer avec le vCenter et pour rendre visible les ports groups afin que les VM puissent s’y connecter. Le canal de management envoie les données de configuration depuis le vCenter vers les VEM lors de l’installation, sous un format appelé opaque data.

Control : c’est le canal de communication entre VSM et VEM qui permet la découverte des modules VEM, la configuration et également la synchronisation de la seconde VSM. Des paquets Heartbeat sont envoyés entre les 2 VSM (par défaut toutes les 2 secondes avec un timeout de 6 secondes). Les flux Netflow depuis les VEM vers les VSM sont également envoyés.

Packet : le canal permet de remonter les informations depuis le réseau vers le VSM pour analyse.

5. Les cartes réseau virtuelles

Les cartes réseau virtuelles vNIC pouvant être configurées au sein de la VM sont les suivantes :

  • vlance : émulation d’une carte PCNet32. Cette carte offre la plus grande compatibilité pour les Guest OS en 32 bits.

  • E1000 : émulation d’une carte Intel 82545EM Gigabit Ethernet compatible avec les Guest OS les plus récents tels que Windows Server 2008.

  • E1000e : évolution de la carte E1000 disponible avec un Virtual Hardware en version 8.

  • vmxnet, vmxnet2 et vmxnet3 : ces cartes offrent les meilleures performances et supportent les jumbo frames notamment. Ces cartes virtuelles ne sont disponibles que lorsque les VMware Tools sont installés.

Pour en savoir plus, se référer à KB 1001805.

6. Dimensionnement et bonnes pratiques

  • Le réseau peut être le goulot d’étranglement dans une architecture virtuelle. Il est fortement conseillé de mettre le maximum de cartes réseau, leur coût étant aujourd’hui très faible au regard du service que cela apporte. La perte de tout élément physique sera ainsi automatiquement gérée par l’infrastructure virtuelle sans incident de production.

  • Il faut privilégier d’avoir des multiples cartes réseau quad port et les répartir sur des ports PCI et risers différents s’il y a assez de slots PCI disponibles. Une configuration standard simple utilise au minimum 2 ports pour le management, 2 ports pour vMotion, 2 ports pour un stockage IP et 2 ports (ou idéalement 4 ports) pour les VM.

Conseil : lors de la mise en place d’un projet de virtualisation, il est nécessaire d’avertir les équipes réseau du nombre de ports qui seront nécessaires à l’intégration des ESXi dans le Datacenter. Cette architecture virtualisée est consommatrice de ports dans un premier temps (le temps de décomissionner les anciennes machines physiques). Il faut parfois prévoir de commencer avec seulement une partie des serveurs (2 minimum pour la redondance), le temps de libérer des ports de machines qui migreront sous forme de VM. Il existe des délais pour commander et intégrer des nouveaux switchs, il faut donc anticiper ce point pouvant impacter fortement l’avancement du projet.

  • Il faut créer des vSwitchs séparés entre le réseau de management et le trafic réseau des VM pour des raisons de sécurité.

  • Le management port : peut être configuré avec 1 vSwitch dédié et 2 cartes réseau physiques ou 2 vSwitchs dédiés avec 1 carte réseau par switch mais dans ce cas cela nécessite 2 adresses IP.

  • Virtual machine port group : mettre le maximum de cartes réseau. Un minimum de 2 cartes réseau Gigabit semble indispensable.

    Le trafic et la bande passante moyenne d’une VM sont de 7 Mo/s, ce qui permet en général de mettre 8 à 10 VM/carte Gigabit. Ceci est bien entendu une valeur moyenne et dépend de la charge de travail ainsi que de l’application elle-même.

  • VMkernel port : 1 ou 2 cartes réseau pour vMotion. Pour le iSCSI ou NFS il faut mettre un minimum de 2 cartes réseau.

  • Configurer le réseau de façon consistante entre les serveurs ESXi d’un même cluster.

About sebihiy

Check Also

cert

VMware Certification

VMware certification établit la norme pour les professionnels de l’IT et valide les organisations de ...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>