Après avoir innové en lançant le Nexus 1000V, un commutateur virtuel distribué pour les environnements vSphere, Cisco dévoile le Nexus 1010, une appliance matérielle destinée à piloter le composant de commutation du Nexus 1000V et à soulager les inquiétudes de certaines entreprises quant à la consommation de ressources du Nexus 1000V sur les serveurs virtualisés.

Les administrateurs réseau ont désormais la possibilité de rendre un peu moins virtuel le commutateur virtuel pour vSphere Nexus 1000V de Cisco. L’appliance virtuelle Nexus 1010 (Nexus 1010 Virtual Servirces Appliance) fournit une plate-forme matérielle pour le plan de contrôle du commutateur virtuel Cisco. Cela améliore la fiabilité du commutateur virtuel, mais donne aussi plus de contrôle sur la technologie aux administrateurs réseau. De quoi leur permettre de reprendre un peu plus de contrôle sur une technologie, jusqu’alors largement entre les mains des administrateurs systèmes.

Le commutateur virtuel Nexus 1000V remplace le vSwitch incorporé dans la version «Entreprise Plus» de vSphere, l’hyperviseur de VMware. Son objectif est de donner aux administrateurs réseau un plus grand contrôle et une meilleure visibilité sur les opérations réseau entre machines virtuelles. Jusqu’alors, le Nexus 1000V n’existait que sous la forme d’une machine virtuelle, un format pas forcément au goût de certains administrateurs réseau plus habitués aux équipements physiques.

Redonner le contrôle du réseau virtuel aux administrateurs réseau
“Je pense que beaucoup d’administrateurs réseau hésitent à utiliser le [Nexus 1000V] au sein d’une machine virtuelle, parce que c’est un objet qui est hors de leur domaine de contrôle”, explique Eric Siebert, le responsable de l’administration système de la chaine de restaurant Boston Market. «Traditionnellement, les administrateurs système ont le contrôle sur [l’ensemble des machines virtuelles fonctionnant sur un serveur hôte]. … Je crois que le Nexus 1010 leur permet de retrouver ce niveau de contrôle dans un châssis physique.”

Depuis les premiers jours de l’entrée de la virtualisation dans les datacenters d’entreprise, les administrateurs réseau mènent une bataille contre les commutateurs virtuels incorporés dans les hyperviseurs des vendeurs tels que VMware, Microsoft ou plus récemment Citrix. Pour faire simple, le principal reproche que font les administrateurs réseau est que ces commutateurs agissent comme des boites noires sur lesquelles il n’ont aucun contrôle, ce qui a des implications en matière de sécurité et d’administration.

«Les systèmes de sécurité, comme les IDS (détection d’intruson) et IPS (prévention d’intrusion), ne peuvent pas travailler à l’intérieur d’un hôte virtuel car il ne peut pas voir une large partie du trafic”, explique Siebert. “Je pense que beaucoup d’administrateurs réseau ne font pas confiance aux environnements virtuels. Parfois, c’est un manque de compréhension. Ils préfèrent leur propre [monde physique], et ils ne veulent pas perdre le contrôle sur ce réseau en le voyant absorbé au sein d’un hôte virtuel. ”

Le Nexus 1000v : restaurer la transparence du commutateur virtuel
Lancé à la mi-2009, le Nexus 1000V de Cisco se compose de deux composants logiciels : le module Ethernet Virtuel (ou Virtual Ethernet Module – VEM) et le module de supervision virtuel (Virtual Supervisor Module – VSM). L’architecture est similaire à un commutateur de réseau physique, indique Omar Sultan, le directeur senior de Cisco en charge des solutions pour datacenters. Le VSM est semblable à un module de supervision dans un commutateur en châssis, et les VEMs jouent le rôle des cartes Ethernet physiques.

Ce que propose le Nexus 1010 Virtual Services Appliance – une appliance au format rack 1U -, c’est un équipement physique capable d’héberger les VSM. Chaque Nexus 1010 peut accueillir 4 VSM, chacun capable de gérer 256 VEM (à raison d’un VEM par serveur hôte physique).

Une appliance dédiée au pilotage de commutateurs virtuels

Même si le nouvel élément physique peut être un plus pour les administrateurs réseau, qui retrouvent ainsi un élément physique plus familier,  le Nexus 1010 a été créé parce que certains clients étaient préoccupés par le fait que le VSM consomme trop de cycles CPU sur les serveurs hôtes, explique Sultan. Avec une machine dédiée, les administrateurs réseau ont aussi l’assurance d’une meilleure disponibilité du composant VSM, un point précieux pour administrer les centaines de VEM embarqués sur les serveurs de leurs centres de données.

Le Nexus 1010 sera également en mesure d’exécuter des modules de service virtuels à l’instar de ce que font les commutateurs physiques en châssis avec leurs modules de services. Le premier sur le marché sera le «Network Analysis Module», un composant logiciel conçu pour améliorer le diagnostic du trafic réseau au sein des datacenters virtuels.

Des alternatives en cours de développement chez les concurrents

 
Cisco n’est pas le seul fournisseur à tenter de redonner le contrôle des réseaux d’infrastructures virtualisées aux administrateurs réseau. En août dernier, Arista Networks -ex Arastra, une société co-fondée par Andy Bechtolsheim, l’employé n°1 de Sun, ex-patron de la division Catalyst de Cisco, puis premier financier de Google – a publié vEOS, une image logicielle de son système d’exploitation pour commutateurs qui s’intègre avec les commutateurs virtuels VMware, au lieu de les remplacer comme le Nexus 1000V.

HP ProCurve a aussi proposé au groupe de travail IEEE 802.1 la normalisation de sa technologie VEPA (Virtual Ethernet Port Aggregation), qui permet aux commutateurs physiques d’attribuer un ensemble prédéfini de profils de ports – incluant des paramètres de sécurité et de politique de trafic – aux machines virtuelles sur un serveur hôte. Le commutateur peut alors piloter le commutateur virtuel pour appliquer et faire respecter ces paramètres, ou il peut remplacer intégralement le commutateur virtuel. Extreme Networks a déjà déclaré que si VEPA est normalisé, il mettra à jour le système d’exploitation XOS sur ses commutateurs pour supporter la technologie. D’autres acteurs comme Juniper, Brocade et Blade Networks devraient faire de même.

Adapté de l’article en anglais de Shamus McGillicuddy, Searchnetworking.com