Le Nexus 1000v a été développé par l'équipe CISCO de Edouard Bugnion, celle-là même qui a développé les Nexus 5000 et 7000. Ed Bugnion est, je le rappelle, l'un des trois co-fondateurs de VMware qu'il a quitté en 2001 pour créer Nuova Systems, société rachetée elle-même par Cisco en avril 2008. La ligne de produits développée par Nuova a été reconduite sous le nom Nexus chez Cisco.La problématique :
Lorsque vous installez un serveur physique sur un commutateur physique, vous avez la possibilité de paramétrer finement la manière dont les ports réseaux vont être utilisés : la vitesse, le duplex, la QOS, le 802.1Q, le Numéro de VLAN, le traffic shapping, les compteurs Netflow (qui prennent en compte le type de flux, le protocole utilisé, les ports d'entrée/sortie du switch, les adresses MACs, les adresses IP source et destination). Tous ces paramètres peuvent être enregistrés dans un profil de port afin d'éviter le fastidieux travail de ressaisie.Vous pouvez bien entendu faire de la copie de traffic d'un port sur un autre dans un but d'audit ou d'analyse.
Lorsque nous avons virtualisé nos serveurs sur VMware Infrastructure, nous avons perdu toutes ces fonctions bien utiles pour nos machines virtuelles. Seul les ports réseaux du host, la machine qui supporte toutes les machines virtuelles, étaient pilotables.
Ainsi, que se passe-t-il au sein du host entre deux VMs ? Comment réagit le réseau lors d'un vMotion entre deux datacenters ? N'y aura-t-il pas de la reconfiguration à faire afin d'être dans le bon VLAN ? Comment analyser localement ou à distance le traffic ?
Lorsque vous installez un serveur physique sur un commutateur physique, vous avez la possibilité de paramétrer finement la manière dont les ports réseaux vont être utilisés : la vitesse, le duplex, la QOS, le 802.1Q, le Numéro de VLAN, le traffic shapping, les compteurs Netflow (qui prennent en compte le type de flux, le protocole utilisé, les ports d'entrée/sortie du switch, les adresses MACs, les adresses IP source et destination). Tous ces paramètres peuvent être enregistrés dans un profil de port afin d'éviter le fastidieux travail de ressaisie.Vous pouvez bien entendu faire de la copie de traffic d'un port sur un autre dans un but d'audit ou d'analyse.
Lorsque nous avons virtualisé nos serveurs sur VMware Infrastructure, nous avons perdu toutes ces fonctions bien utiles pour nos machines virtuelles. Seul les ports réseaux du host, la machine qui supporte toutes les machines virtuelles, étaient pilotables.
Ainsi, que se passe-t-il au sein du host entre deux VMs ? Comment réagit le réseau lors d'un vMotion entre deux datacenters ? N'y aura-t-il pas de la reconfiguration à faire afin d'être dans le bon VLAN ? Comment analyser localement ou à distance le traffic ?
L'objectif du Nexus 1000v :
le but du Nexus 1000v est de se subsituer au vSwitch distribué de niveau 2 non manageable déjà présent dans Infrastructure, afin d'offrir aux machines virtuelles, toutes les fonctionnalités qui répondent aux problèmes cités ci-dessus. Vous allez en quelque sorte élever les VMs d'un point de vue réseau, au même niveau fonctionnel que les machines physiques.
le but du Nexus 1000v est de se subsituer au vSwitch distribué de niveau 2 non manageable déjà présent dans Infrastructure, afin d'offrir aux machines virtuelles, toutes les fonctionnalités qui répondent aux problèmes cités ci-dessus. Vous allez en quelque sorte élever les VMs d'un point de vue réseau, au même niveau fonctionnel que les machines physiques.
Comment se présente le Nexus 1000v ?
Il se présente sous la forme de deux modules logiciels : le VSM et le VEM. Le Virtual Supervisor Module s'installe sur le vCenter et permet de gèrer les ports déclarés dans le Nexus 1000v. Les Virtual Ethernet Modules sont les ensemble de ports qui vont se substituer au traditionnel vSwitch que vous connaissez au sein des host. Oui, j'ai bien dit ensemble de ports.En effet, il faut considérer le Nexus 1000v comme un chassis modulaire ou chaque VEM remplaçant un vSwitch est vue comme une carte ligne de ports Ethernet dans ce même commutateur. Un VSM peut gérer jusqu'à 64 serveurs simultanément.
A noter que si le VSM venait à disparaitre suite à une panne du vCenter le supportant par exemple, le Nexus 1000v continuerait de fonctionner mais n'autoriserait pas de modifications de configuration.
Comment se configure-t-il ?
Il se configure au travers d'un Command Line Interface (CLI) très similaire à celui que l'on connait sur un commutateur physique Cisco. Son système d'exploitation NX-OS est très proche de l'Internetworking Operating System (IOS), le système d'exploitation Cisco bien connu. Le commutateur Nexus 1000v repond aux requêtes CDP. il est possible de le manager partiellement dans l'interface graphique du vCenter.
Il se configure au travers d'un Command Line Interface (CLI) très similaire à celui que l'on connait sur un commutateur physique Cisco. Son système d'exploitation NX-OS est très proche de l'Internetworking Operating System (IOS), le système d'exploitation Cisco bien connu. Le commutateur Nexus 1000v repond aux requêtes CDP. il est possible de le manager partiellement dans l'interface graphique du vCenter.
Quels plus ?
Il sera désormais possible aux équipes réseaux d'intervenir au sein de la configuration réseau virtuelle des hosts ESX comme elles le font déjà pour les machines physiques. Le sniffing à distance pourra être réalisé au travers de la fonction RSPAN (Remote Switch Port ANalyzer).Le Nexus 1000v supporte aussi le multicast et les requêtes IGMP.
Y'aura-t-il de l'overhead généré sur les hosts ?
Non, je n'en ai pas constaté sur la béta.
Non, le Nexus 1000v n'est pas un routeur. Cette fonction doit être réalisée par un routeur externe.
En conclusion :
Lorsque la nouvelle version du logiciel serveur ESX sera sortie et que vous voudrez en piloter finement les réseaux virtuels, ce sera LA SOLUTION.
Aucun commentaire:
Enregistrer un commentaire