Commutation virtuelle

Transcription

1 Commutation virtuelle Best Practice Document Document rédigé par le groupe de travail «Commutation virtuelle» animé par le GIP RENATER (BPD R3.4) Auteurs: Cedric Foll - cedric.foll@univ-lille3.fr (Université Lille 3/GIP RENATER) Aurélien Méré - aurelien.mere@u-psud.fr (Université Paris Sud/GIP RENATER) Jean-Pierre Feuillerat - jean-pierre.feuillerat@dsi.cnrs.fr (DSI CNRS/GIP RENATER) V1-02/12/13

2 GIP RENATER 2013 TERENA All rights reserved. Document No: GN3plus-NA3-T2-R3.4 Version / date: V1-02/12/13 Original language : French Original title: Commutation virtuelle Original version / date: V1-02/12/13 Contact: cbp@listes.renater.fr RENATER bears responsibility for the content of this document. The work has been carried out by a RENATER led working group on virtual switching as part of a joint-venture project within the HE sector in France. Parts of the report may be freely copied, unaltered, provided that the original source is acknowledged and copyright preserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/ ) under grant agreement n , relating to the project 'Multi-Gigabit European Research and Education Network and Associated Services (GN3plus)'. 2

3 Table of Contents Executive Summary 4 1 Qu est-ce qu un commutateur virtuel? Historique Rôle et intérêt des commutateurs virtuels Problèmes induits par ce type de commutation Organisationnels Fonctionnels De sécurité De troubleshooting 7 2 Les différentes solutions Solutions logiques Les ponts gérés au niveau système Les Virtual Ethernet Bridges (VEB) Les Virtual Distributed Switches (VDS) Solutions mixtes (physique/logiques) Les Virtual Ethernet Ports Aggregators Les VN-Tag Les cartes réseau «Single Root I/O Virtualization» compatibles 13 3 Choisir sa solution 14 4 Retour expérience Le contexte L architecture L utilisation 17 Conclusion 18 Références 19 Glossaire 20 3

4 Executive Summary L'accroissement de l'utilisation des machines virtuelles dans nos campus a nécessité que le réseau s'adapte. Il doit répondre aux mêmes exigences pour l accès aux machines virtuelles que celles demandées pour l accès au serveur physiques : sécurité, fiabilité, performances. La commutation virtuelle a évolué pour proposer aujourd'hui un panel très varié de solutions répondant aux besoins des administrateurs système et réseau. Elle va même au-delà de ce que nous propose le physique (déplacement à chaud d'un port avec toutes ses politiques de sécurité, densité de ports importante et évolutive ). Ce document présente les problématiques du passage de la commutation physique à la commutation virtuelle tant en termes techniques qu organisationnels. Il fournit un panel des solutions disponibles et les avantages / inconvénients de celles-ci. Une solution d'implémentation est également présentée. 4

5 1 Qu est-ce qu un commutateur virtuel? 1.1 Historique La virtualisation s est imposée progressivement depuis le début des années 2000 en commençant par le poste de travail, puis dans les infrastructures de développement avant de se généraliser dans beaucoup de campus pour la production. De quelques machines tournant sur un serveur physique dans le même plan d adressage IP nous sommes passés à des dizaines voire des centaines de machines virtuelles appartenant à de multiples VLAN, et ayant des contraintes en terme de sécurité et de qualité de service équivalentes aux machines physiques. 1.2 Rôle et intérêt des commutateurs virtuels. L objectif des commutateurs virtuels est d assurer une connectivité de niveau 2 entre les différentes machines virtuelles. Ils peuvent se limiter à des échanges de flux au sein de l'infrastructure virtuelle. Dans ce cas, l'infrastructure de commutation physique ne traite pas les flux et ceux-ci lui sont totalement invisibles. Ils peuvent aussi faire remonter les flux vers l'infrastructure physique. Il peut s agir dans ce cas, du besoin de réaliser une opération de routage ou bien de l utilisation des normes 802.1Qbg ou 802.1Qbh comme évoqué dans la suite du document. Techniquement, un agrégat de VLAN est connecté aux serveurs hébergeant les hyperviseurs et les équipes techniques en charge de l infrastructure de virtualisation créent des commutateurs virtuels associés aux différents VLAN avant de leur attacher les machines virtuelles. La virtualisation offre une souplesse et une simplicité très importante pour la réalisation de certaines tâches qui incombent aux équipes réseaux tels que la migration de serveurs et les taches de brassages associées. Elle permet des réductions de coût en limitant le nombre de commutateurs physiques. Cette limitation simplifie également les architectures réseau rendant leur administration plus simple. 5

6 On comprend donc le développement de cette commutation virtuelle. Néanmoins cela ne va pas sans entraîner d autres problèmes. 1.3 Problèmes induits par ce type de commutation Organisationnels La gestion de l infrastructure de commutation virtuelle est souvent, au départ, réalisée par les équipes systèmes qui ont la maîtrise de l hyperviseur. Cela peut poser de nombreux problèmes si l organisation n a pas été pensée au préalable. En effet : L équipe réseau perd de la visibilité et de ses prérogatives sur une partie du réseau. L équipe réseau ne peut plus auditer et vérifier la cohérence de tous les éléments actifs de l architecture. Une partie de la gestion de la sécurité du réseau est transférée à l équipe système qui n en a pas forcément l expérience. L équipe réseau peut se sentir dépossédée d une partie de son travail. Ceci pouvant engendrer des conflits. Ce problème n est pas à négliger car outre la mauvaise ambiance générée, il peut engendrer une dissolution des responsabilités et à terme, des difficultés à résoudre une panne Fonctionnels Les équipements actifs disposent de beaucoup de fonctionnalités qui peuvent ne pas être retrouvées dans ce que proposent par défaut les infrastructures de virtualisation: Supervision : En général, les fonctionnalités de type sflow/netflow ou SNMP ne sont pas disponibles sur les switchs virtuels fournis par défaut avec les hyperviseurs. Cela rend la supervision globale de l'infrastructure de commutation impossible. Une partie de la charge réseau échappe ainsi totalement à la surveillance des équipes en charge de la supervision. Analyse des flux : Les fonctionnalités de type RSPAN qui permettent d analyser la totalité des flux transitant sur un port ou un VLAN sont également souvent absentes rendant par exemple l utilisation d un IDS complexe pour analyser le trafic entre les machines virtuelles. QoS : Les fonctionnalités de qualité de service ne sont généralement pas implémentées sur les switchs virtuels standards ce qui peut poser d importants problèmes pour l hébergement virtualisé de certains services tels que ceux liés à la ToIP ou la visioconférence. Fonctions de sécurité : Des mécanismes de protection contre les attaques de type ARP Cache poisoning ou DHCP Snooping couramment implantés sur les commutateurs ne sont pas toujours présents sur les architectures virtualisées. C est également le cas des Private VLAN qui permettent d interdire 6

7 les flux entre machines au sein d un même VLAN ou encore des Access-list qui ne sont souvent pas disponibles sur les commutateurs virtuels basiques De sécurité Les problèmes de sécurité induits par la commutation virtuelle découlent des deux points précédents. Ceux liés à l organisationnel : La séparation des tâches entre les équipes, si elle n a pas été anticipée peut s avérer délicate dans le cadre de la virtualisation avec des effets de bord concernant la sécurité (erreur de manipulation de l équipe système engendrent un problème côté équipe réseau, équipe non formée au réseau devant gérer des éléments actifs,...). Parmi les principaux risques induits nous pouvons citer la création d une machine virtuelle connectée par erreur à plusieurs VLAN et permettant de contourner la politique de sécurité ou encore un déni de service au niveau réseau rendant inopérante l infrastructure de virtualisation suite au mauvais paramétrage, ou encore l absence de règles de QoS, de filtrage. Ce type d erreurs de configuration n est pas propre aux environnements virtualisés mais le risque est accru si l équipe se chargeant de la configuration des switch virtuels n est formée qu à l administration système. Ceux liés au Fonctionnel : Comme nous venons de le voir, beaucoup de fonctionnalités de sécurité sont absentes dans les switchs basiques proposés par les infrastructures de virtualisation. Par conséquence un attaquant pourra réaliser des attaques plus facilement et avec plus d impact que s il avait pris la main sur une machine physique. Il est toutefois à noter que l adhérence entre machines virtuelles et switchs virtuels étant particulièrement forte, certaines fonctionnalités de sécurité ne sont possibles que dans le monde virtuel. Il s agit en particulier de pouvoir interdire le passage des cartes réseaux en mode promiscuous ou des fonctionnalités liées au partage et à la limitation des I/O réseaux entre machines virtuelles. Ces manques peuvent, comme nous le verrons par la suite être comblés en souscrivant à une licence additionnelle. En particulier, des fonctionnalités de QoS et de protection face aux attaques réseau De troubleshooting Certaines fonctionnalités étant généralement absentes (supervision, analyse de flux), la détection et l analyse des problèmes sur le réseau peuvent se montrer particulièrement difficile. D autant que les machines virtuelles et les commutateurs partageant souvent le même matériel (celui de l hyperviseur), l analyse et la résolution de problèmes de performances se trouvent complexifiées. C est tout particulièrement le cas pour isoler ce qui est inhérent à des problèmes liés au système et des problèmes liés au réseau. Et même pire, une charge système importante peut dégrader les performances réseau ou l inverse. 7

8 2 Les différentes solutions 2.1 Solutions logiques Les ponts gérés au niveau système Pour permettre aux machines virtuelles d accéder au réseau en utilisant leur propre IP, la solution qui était habituellement choisie en premier lieu était l utilisation de la fonction «pont réseau» intégrée au système. C est en effet le mode de fonctionnement le plus simple et rapide à mettre en place. Lorsque l hyperviseur est un serveur linux, cela nécessite l utilisation d un package spécifique (dans le cas de Debian, «bridge-utils»). Il va permettre de créer une interface bridge «brx» liant une interface physique «ethx» avec une interface logique «tapx» sur laquelle sera connectée une machine virtuelle. Les premières versions de Xen utilisaient ce mécanisme et il est encore utilisé par KVM. Ce mode de fonctionnement permet d obtenir une connectivité de niveau 2 entre une ou plusieurs machines virtuelles et un réseau physique et reste tout à fait approprié pour une utilisation limitée à quelques machines ou à une architecture de test. L utilisation dans une architecture plus étendue (grosse quantité de VM, de VLAN ) n est pas conseillée car le management et la supervision de nombreux bridges est complexe Les Virtual Ethernet Bridges (VEB) Ils prennent la forme d une brique logicielle liée à l hyperviseur (sans surcoût) offrant les fonctionnalités d un commutateur physique d entrée de gamme. Il ne s agit donc plus d utiliser les mécanismes de commutation système du serveur hôte comme dans le cas précédent, mais de proposer une gestion de la commutation au niveau de l hyperviseur. Si des machines virtuelles liées à un VEB doivent communiquer entre elles, cet échange restera interne au VEB de l hyperviseur. Si la destination est externe, l échange passera alors par l interface physique du serveur. Bien que plus évolués que les ponts systèmes, ils n intègrent pas toutes les fonctions attendues par un commutateur notamment en termes de management, de monitoring, de gestion de la qualité de service ou de sécurité. Ils nécessitent des modes de gestion qui leurs sont propres et sont souvent limités à une utilisation avec un seul type d hyperviseur. L administration de ce type de commutateur est d ailleurs souvent réalisée par l équipe en charge de l hyperviseur et donc plutôt des profils systèmes. Ceci entraînant une perte de visibilité par l équipe réseau. Cette solution est sans doute la bonne dans le cas où le nombre de machines virtuelles est limité et nécessite peu de fonctions évoluées de niveau 2. Elle permettra des échanges rapides entre machines d un même VEB. Ce type de solution sera néanmoins difficile à mettre en place dans des architectures avec un grand nombre de serveurs physiques qui nécessiteront plutôt un mode distribué. En effet, la configuration des port-groups devra être répliquée manuellement sur chaque commutateur virtuel 8

9 afin qu une VM lors de son déplacement d un serveur à un autre puisse retrouver sa configuration de port virtuel. Exemple avec VMWare vsphere Dans le cas d un achat de licence standard vsphere. L utilisateur disposera d un VEB nommé Vswitch qui propose un ensemble de fonctionnalités basiques (L2 forwarding, vlans..). Raccordement des machines virtuelles aux vswitch, un vswitch étant créé par VLAN. 9

10 Options disponibles pour chacun des vswitch. Nous voyons qu il s agit d options très basiques, plutôt ce qui est attendu comme fonctionnalités sur des commutateurs d accès bas de gamme pour postes de travail que pour des équipements mis en place pour l accès des serveurs dans un Data Center. 10

11 2.1.3 Les Virtual Distributed Switches (VDS) Les Virtual Distributed Switches (VDS) reprennent le concept des Virtual Ethernet Bridge, à savoir qu il s agit d une commutation logicielle réalisée par l hyperviseur, mais en en étendant considérablement les fonctionnalités. La principale différence avec les VEB est la possibilité de déployer des configurations réseau complexes sur de multiples serveurs physiques. En effet, l ensemble des switches virtuels distribués sont regroupés dans un seul châssis virtuel piloté par un superviseur, où chaque module correspond en réalité à un serveur hôte. Dès lors, toute la configuration est centralisée en un seul point, permettant à l équipe réseau de simplement définir des profils de ports, qui seront automatiquement poussés sur tous les switches virtuels et mis à disposition de l équipe système qui pourra les affecter aux machines virtuelles. Cette séparation entre la gestion «réseau» et «système» est aussi un avantage de certains VDS. L administrateur réseau va pouvoir gérer le commutateur comme s il s agissait d'un commutateur physique de niveau 2 classique alors que l administrateur système va simplement affecter à une machine virtuelle un profil d utilisation défini par l équipe réseau. Celle-ci va retrouver les fonctionnalités d un commutateur physique de niveau 2 classique (monitoring de port, qualité de service, sécurité -- Private VLAN, DHCP Snooping, ARP Inspection...), aussi bien pour les interfaces réseaux des machines virtuelles que les interfaces physiques des serveurs hôtes, et va pouvoir créer des profils de ports adaptés à chaque type de machine virtuelle. Un avantage supplémentaire est que tout déplacement de VM vers un autre serveur hôte sera entièrement transparent au niveau réseau. Ce modèle sera donc idéal dans les cas où les équipes réseau et système sont différentes et souhaitent conserver chacune leur périmètre propre, où les problématiques de contrôle ou de sécurité sont importants, et à partir du moment où il y a plusieurs serveurs hôtes desservant chacun un nombre important de machines virtuelles. Exemple avec VMWare vsphere Dans le cas de vsphere, il faut acquérir la licence vsphere la plus chère, c est à dire Entreprise Plus pour disposer des fonctionnalités de commutation avancées. Le prix public de cette licence est près de 2,5 fois plus cher que celui de la version standard. ( Cette licence ouvre également la possibilité d utiliser des commutateurs logiciels tiers (Cisco Nexus 1000v, IBM 5000v,...) ou les commutateurs avancés de vmware appelés Ditributed Switch et disposant des fonctionnalités suivantes: Supervision (SNMPv3 et NetFlow) Analyse des flux avec RSPAN Isolation des machines virtuelles avec PVLAN. 2.2 Solutions mixtes (physique/logiques) La solution qui consiste à faire communiquer les VM au travers d éléments physiques est de plus en plus mise en avant par les constructeurs. Ils argumentent sur le fait que ce type de solution libère le 11

12 serveur du traitement processeurs liés au fonctionnement du switch virtuel, qu aucun commutateur virtuel ne possède l ensemble des fonctionnalités d un commutateur physique, qu il est plus simple d intégrer d autres équipements (IPS, firewalls). Nous n avons néanmoins pas trouvé de retours d expérience dans la communauté enseignement / recherche sur ce type de solution, ni pu les tester Les Virtual Ethernet Ports Aggregators Les Virtual Ethernet Ports Aggregators (VEPA) reprennent la norme Qbg (Edge Virtual Bridging) et sont en particulier proposés par les infrastructures HP. L objectif de ces connecteurs est de se rapprocher au plus près du fonctionnement habituel du réseau physique. Dans ce mode, les machines virtuelles sont gérées comme des serveurs physiques. La commutation des paquets entre deux serveurs virtuels est réalisée par des commutateurs physiques. Par conséquent le module VEPA oblige le trafic provenant des VM à sortir de l interface physique du serveur hébergeant l hyperviseur vers le commutateur physique. On voit bien les avantages que ce mode de fonctionnement possède : La mise en place de machines virtuelles ne change rien au travail de l équipe réseau. L outillage de supervision et d administration est le même. L organisation n a pas à être modifiée étant donné que les limites entre les équipes systèmes et réseau ne changent pas. La CPU du serveur n est plus utilisée pour commuter le trafic et appliquer les règles sur les flux (ACL, QoS,...) L utilisation de VEPA peut donc sembler être la solution pour les infrastructures existantes basées sur HP. Elle va néanmoins nécessiter que les équipements physiques supportent ce mode de fonctionnement, ils doivent pour cela accepter de renvoyer le trafic provenant d un port physique vers ce même port (norme 802.1br). Cela n implique souvent qu une mise à jour système. Si l on veut en plus séparer les flux provenant de chaque VM, il faut que les commutateurs et les cartes réseaux acceptent le QinQ. (802.1ad). Ils devront également être puissants et rapides pour avoir des performances en termes de débit et de latence équivalentes à celles que pourraient réaliser un VEB entre des machines virtuelles hébergées sur un même serveur. Une implémentation possible de ce type de solution est d utiliser un switch virtuel compatible VEPA comme le HP5900v en l intégrant à un hyperviseur VSphere de la même manière qu un switch distribué Les VN-Tag Les solutions VN Tag se basent sur la norme 802.1Qbh et sont proposées par Cisco. L objectif et le même que pour les VEPA : faire remonter le trafic vers des commutateurs physiques. Un tag est ajouté au flux provenant de chaque VM afin qu il puisse être identifiées par le commutateur. On pourra ainsi configurer les ports de celui-ci comme si la machine virtuelle était directement connectée dessus. 12

13 La problématique, est que cette solution, bien qu étant potentiellement une future norme, nécessite à la fois des switches Nexus de Cisco mais aussi une infrastructure serveur Cisco UCS Les cartes réseau «Single Root I/O Virtualization» compatibles Une autre solution est l utilisation de cartes compatibles SR-IOV. Ces cartes physiques se présentent au niveau système ou de l hyperviseur comme une ensemble d instances différentes de cette même carte (le nombre dépendant de la carte). Ce type de solution permet de déporter la charge processeur d un VEB sur un équipement hardware dédié. SR-IOV peut par exemple être utilisé avec Vsphere 5.1. Ce mode d implémentation ne permettra néanmoins pas d utiliser de nombreuses fonctions avancées (vmotion, vshield, netflow ) Il est également mis en avant par Microsoft pour Hyper-V sous Windows server 2012 et peut être utilisé avec XEN et KVM. Exemples de cartes compatibles SR-IOV : 13

14 3 Choisir sa solution >3 Nombre de serveurs ESX <3 Volonté de rester sur de la commutation physique et budget important oui VEPA/VN-TAG non Virtual Distributed switch Ex: Cisco 1000v, vmware VDSwitch,OpenVswitch Equipes réseau/système distinctes et importantes Besoin de fonctionnalités Sécurité/management non présentes Virtual Ethernet Bridge Ex : Vmare or HyperV Vswitch Optimisation des performance avec carte SR-IOV Disponibilité du switch pour l Hyperviseur utilisé, fonctionnalités nécessaires VMWare, Hyper-V VMware Xen,KVM,VBox Nexus 1000v vdswitch Maintenance Sous traitée. Openvswitch Nexus 1010v 14

15 4 Retour expérience 4.1 Le contexte La solution présentée a été mise en place à la DSI du CNRS pour répondre à plusieurs besoins. Tout d abord une quantité accrue de projets nécessitant toujours plus de serveurs et donc de budget (achat, hébergement), ensuite un manque de personnels ne permettant pas l administration et la supervision d autant d équipements. L utilisation de la virtualisation nous est apparue comme la meilleure solution pour répondre à cette problématique. Durant quelques mois, notre utilisation de la virtualisation a été limitée à quelques dizaines de machines virtuelles. Nous utilisions l hyperviseur VMware qui était administré par l équipe système. Ils avaient mis en place le VEB intégré à la solution (vswitch). Un lien 802.1q était configuré sur le switch physique afin que l équipe système puisse attribuer aux machines virtuelles le VLAN de leur choix. Ce mode de fonctionnement a atteint ses limites avec l augmentation exponentielle du nombre de machines virtuelles. En particulier, il est devenu nécessaire de faire transiter les règles de sécurité affectées à une machine virtuelle lors d un déplacement de celle-ci (sans coupure des flux utilisateurs). Une solution aurait pu être de partir vers le Virtual Distributed Switch de VMWare mais l équipe réseau avait déjà une compétence Cisco et des outils d administration maitrisés pour ce fabricant. La possibilité de mettre des ACL sur les commutateurs virtuels Cisco et certaines fonctionnalités de QoS ont aussi été des raisons de ce choix. 15

16 4.2 L architecture L architecture mise en place utilise donc un commutateur virtuel distribué. Sur chaque ESX est installé un programme lié à l hyperviseur et qui permet de faire communiquer les interfaces des machines virtuelles avec les interfaces physiques du serveur. Ce programme est appelé VEM (virtual Ethernet module). Un autre programme permet de contrôler tous ces VEM répartis sur les différents serveurs ESX. C est le superviseur (VSM - Virtual Supervisor Module). C est ce module qui héberge la configuration de l ensemble. Le terme «nexus 1000v» désigne donc la somme de ce (ou de ces) VSM et de tous les modules VEM répartis sur chaque serveurs ESX. Une mise à jour de celui-ci nécessitera donc une mise à jour à la fois du VSM (équivalente à une mise à jour d un équipement réseau) et une mise à jour des VEM sur chaque ESX qui correspond plus à un ajout de module dans un systeme VMWARE. Le superviseur VSM qui contrôle toutes les VEM peut soit tourner dans une machine virtuelle (infrastructure entièrement virtualisée), soit être déporté sur une ou deux appliances physiques (en actif/passif) : les Nexus 1010 ou Celles-ci peuvent également prendre en charge d autres applications directement liées au Nexus 1000V (analyse du réseau, firewall logiciel distribué etc). Une option en appliance physique préviendra notamment tout impact sur le switch distribué en cas de perturbation ou d incident sur le serveur hébergeant la VSM. 16

17 Dans la solution présentée, nous n avons pas de ce type d équipement. Les deux superviseurs en actif /passif sont donc présents sous la forme de deux machines virtuelles réparties sur deux ESX. Sachant que nous disposions de quatre cartes réseau physiques sur chaque ESX, nous avons décidé d en dédier une pour l accès au VSM. En effet, en utilisant ce mode hybride (VEB, VDS) nous voulions éviter de placer les VSM derrière les VEM qu ils gèrent, une mauvaise configuration sur ceux-ci pouvant les rendre inaccessibles. Le risque est limité car une perte des VSM n entraine pas forcément une coupure des flux passant par les VEM, mais nous trouvions ce mode de fonctionnement plus propre. 4.3 L utilisation L utilisation d un commutateur virtuel de type nexus est équivalent à l utilisation d un switch classique. La configuration des interfaces se fait au travers de port-profiles. Chaque port profile regroupe un ensemble d informations communes à l ensemble des ports qui le constitue. Ces informations peuvent être des vlans, pvlans, de la QoS, des ACL Ainsi, une fois ce port profile défini par l équipe réseau dans le VSM, il sera disponible pour l équipe système dans l interface de vsphere afin de l affecter à une machine donnée. On voit bien ainsi la séparation des tâches entre équipes. Dans notre port-profile correspondant aux uplink (vers les switch physiques) nous avons utilisé la technologie mac-pinning pour l etherchannel. Ce mode de fonctionnement à l avantage d être utilisable avec n importe quel type de switch physique. (Affectation de la mac adresse d une VM à une interface physique du serveur en round robin). Dans le nexus 1000v, on voit les VM comme si elles étaient connectées sur les ports d un switch Cisco physique. 17

18 Conclusion Les solutions proposées pour mettre en réseau nos machines virtuelles sont nombreuses et variées. Cette variété est à la fois un atout et une difficulté. Il est en effet difficile d être sûr que notre choix sera le plus efficace et le plus pérenne. Les technologies sont souvent récentes et peu éprouvées. De nouvelles solutions apparaissent sans cesse remplaçant celles qui, il y a peu, avaient le vent en poupe. Elles dépendent souvent de votre hyperviseur, de vos serveurs, de vos commutateurs physiques, de votre organisation. Dans le panel de solutions que nous vous avons présenté, vous trouverez sans doute la plus adaptée si vous avez bien défini au préalable toutes vos contraintes. 18

19 Références 1 Cisco Nexus 1000V Series Switch Deployment Guide with Cisco Unified Computing System 2 VMware Virtual Networking Concepts 3 PCI-SIG SR-IOV Primer: An Introduction to SR-IOV Technology 19

20 Glossaire NETFLOW SNMP RSPAN ACL IDS QOS VEB VDS VEPA SR-IOV VSM VEM Protocole Réseau permettant de collecter des informations sur le trafic échangé. Simple network management Protocol. C est un protocole permettant de superviser des équipements réseau. Remote switched port analyser. Fonctionnalité permettant de copier les données transitant sur un port vers un autre port. Access Control List. Liste d adresses IP autorisées ou non à transiter au travers d un équipement Réseau Intrusion Detection System. Mécanisme permettant de détecter un trafic suspect circulant sur le réseau. Quality Of Service Mécanisme permettant de gérer les ressources réseau attribuées à telle ou telle application. Virtual ethetnet bridge Commutateur virtuel basique permettant de relier des machines virtuelles entre elles et vers un Réseau physique. Virtual distributed switches Commutateur virtuel évolué permettant entre autre de gérer plusieurs switchs virtuels répartis sur des serveurs différents. Virtual Ethernet port aggregators Mécanisme permettant de faire remonter le trafic des machines virtuelles vers un switch physique. Single root I/O Virtualization. Spécification permettant à une carte Réseau d apparaitre comme un ensemble de carte physique. Celles-ci pouvant être ensuite attribuées aux machines virtuelles. Virtual supervisor module Logiciel permettant de contrôler les VEM. C est le cœur des nexus 1000v Virtual Ethernet module C est le module des nexus 1000v qui, intégré dans les serveurs, effectue la commutation des machines virtuelles. 20