Accueil > VMware > nouveauté vSphere5: amélioration réseau
Août/1150

Le réseau dans vSphere n’a pas été révolutionné mais il y a pas mal d’améliorations. Pour les administrateurs: au niveau visibilité,dépannage, surveillance, configuration et gestion automatisées du  réseau. Et coté utilisateurs: au niveau du SLA réseau avec notamment du contrôle de bande passante par regroupement de VM et de la Qualité de Service (QoS) de bout-en-bout.

Fonctions de surveillance et découverte du réseau

Depuis VI3.5, VMware supportait la découverte réseau avec le protocole propriétaire Cisco: CDP. Maintenant avec vSphere 5.0, on a également le LLDP (Link Layer Discover Protocol): un protocole de découverte standard non lié à un fournisseur (802.1AB). Les protocoles de découverte réseau (CDP ou LLDP) interviennent au niveau de la couche de liaisons de données (layer2) pour découvrir les capacités des périphériques réseaux et découvrir la configuration de l’infrastructure voisine.

Voici un exemple de découverte réseau avec LLDP:

Le NetFlow est un protocole réseau qui recueille et enregistre les informations sur le trafic IP (seulement les entêtes), puis les transmet à des collecteurs tiers tels que CA NetQoS, NetScout… Le collecteur est ensuite capable de fournir différentes informations: les flux principaux consommant actuellement le plus de bande passante, les flux d’aspect irrégulier et le nombre d’octets envoyés/reçus par un flux donné au cours des 24 heures écoulées.

NetFlow aide à surveiller les flux des applications et à mesurer les performances applicatives au fil du temps. Il facilitent également la planification de capacité et garantit que les différentes applications utilisent correctement les ressources E/S et réseau.

Dans vSphere, la fonctionnalité NetFlow offre la visibilité totale sur le trafic de infrastructure virtuelle. Que ce soit de type trafic Inter-VM (au sein du même Host), Intra-VM (entre  différents Hosts) trafic entre les VMs et l’infrastructure. Cette visibilité du trafic de l’infrastructure virtuelle afin de réaliser une analyse de sécurité et de conformité, créer des flux et de refacturation mais aussi de détecter les intrusions réseaux.

Le Port Mirroring est la capacité d’un commutateur réseau à envoyer une copie des paquets réseaux reçus sur un port de commutateur vers un périphérique de surveillance réseau connecté à un autre port de commutateur (la mise en miroir des ports). Cette fonctionnalité se nomme SPAN (Switched Port Analyzer) sur les commutateurs Cisco.

La mise en miroir des ports permet de dépasser les limites du mode écoute. En permettant un contrôle granulaire du trafic pouvant être surveillé comme le flux provenant de l’accès et/ou le flux provenant de la sortie. Cela facilite le dépannage réseau en fournissant un accès au trafic Inter-VM & Intra-VM. A la différence du NetFlow, ici c’est l’intégralité du trafic qui est copié vers une station Moniteur.
Voici un exemple de flux du trafic de Port Mirroring lorsque la destination est un port physique dédié : un Uplink avec autorisation des E/S normales désactivée:

Firewall de l’Hyperviseur

Dans l’hyperviseur ESXi 4.x le Firewall était vraiment basique, on pouvait simplement activer/désactiver des services. Maintenant en ESXi5.0, on a une meilleure interface utilisateur de configuration (comparable à celle en ESX classique). En ligne de commande la configuration se fait par esxcli network firewall (la commande esxcfg-firewall a été supprimé).
Le moteur du Firewall n’est plus basé sur IPtables. Il est orienté règle par type de service et c’est un Firewall stateless (sans état stocké). Les utilisateurs peuvent restreindre l’accès à un service en fonction d’une adresse IP ou d’une plage d’IP. Le Firewall est prise en charge par les Host Profiles et la montée de version d’ESX 4.X vers ESXi 5.0 conserve les règles du Firewall.
En passant par « Configuration > Security Profile » on peut observer les services ouverts en entrée/sortie, les ports ouverts et les IP autorisé pour chacun des services.
Dans Properties des Services, on peut configurer si un service est en démarrage automatique. Les services peuvent être arrêté à la volée.
Dans Properties du Firewall, on peut configurer les services dont l’accès est autorisé par le Firewall. en cliquant sur Firewall, on peut définir la page d’IP autorisées pour un service.

Network IO Control par groupe de VMs

Le contrôle des E/S réseau appelé « Network IO Control » (NetIOC) est une fonction déjà présente depuis vSphere 4.1 sur les vDS (en Enterprise Plus). Il s’agit d’une fonction des gestion du trafic réseau d’un vSphere Distributed Switch. Elle est très intéressante dans les infrastructures réseaux consolidées (10 Gb) car elle permet de partager et de limiter les différents types de trafic.
En vSphere 5, le NetIOC dispose d’un contrôle accru des E/S réseau. En effet, on peut maintenant définir le trafic par groupe de VMs (alors qu’avant c’était le trafic VM globale) pour assurer de la QoS par VM. On voit donc apparaitre des Pools de Ressource Réseau définit par l’utilisateur, de nouvelle règle pour le trafic de réplication Host et du marquage Qos (Qos tagging: 802.1p).
Comme dans le schéma ci-dessous l’administrateur peut définir pour chaque type de trafic et groupe de VMs des règles de partage (share), de limite et de priorité QoS. Au niveau du vDS des règles de regroupement sont appliqué et fonction de la charge pour l’équilibrage (Load-Based teaming). Ensuite le « Shaper » entre en jeux pour assurer les règles de limitation. Et enfin, avant d’atteindre le port physique, le « Scheduler » applique les partages (shares) du lien en cas de saturation.
Le balisage QoS (802.1p) est une norme IEEE qui fournit un mécanisme de priorisation QoS au niveau MAC. Le tagging 802.1p permet d’assurer de la QoS de bout-en-bout à condition que tous les commutateurs réseaux sachent gérer le trafic en fonction de la balise QoS. Les balises sont alors ajoutées en fonction de la priorité de l’application.L’infrastructure vSphere n’assure pas la QoS en fonction de ces balises. Les vDS balisent simplement les paquets d’après la configuration du pool de ressources réseaux. Le commutateur physique doit interpréter l’indicateur et agir en conséquence.

Améliorations des performances réseaux

Le trafic en multidiffusion (multi-cast) est mieux optimisé: Si plusieurs VMs sur un même serveur ESXi reçoivent du trafic en multidiffusion en provenance d’une même source, on constatera un meilleur débit et une réduction de la consommation CPU au niveau des Hosts ESXi.

Il y a une optimisation de la pile TCP/IP  au niveau de vmknics: avec la hausse du débit avec les petits messages et une meilleure adaptation des IOPS pour le trafic iSCSI.

Sources intéressantes:

  1. Pas encore de commentaire
  1. Pas encore de trackbacks