-
Commutation virtuelle
Best Practice Document
Document rdig par le groupe de travail Commutation virtuelle anim par le GIP RENATER
(BPD R3.4)
Auteurs:
Cedric Foll - [email protected] (Universit Lille 3/GIP RENATER) Aurlien Mr - [email protected] (Universit Paris Sud/GIP RENATER)
Jean-Pierre Feuillerat - [email protected] (DSI CNRS/GIP RENATER)
V1 - 02/12/13
-
2
GIP RENATER 2013 TERENA 2013. 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: [email protected] 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/2007-2013) under grant agreement n 605243, relating to the project 'Multi-Gigabit European Research and Education Network and Associated Services (GN3plus)'.
-
3
Table of Contents
Executive Summary 4
1 Quest-ce quun commutateur virtuel ? 5
1.1 Historique 5
1.2 Rle et intrt des commutateurs virtuels. 5
1.3 Problmes induits par ce type de commutation 6
1.3.1 Organisationnels 6
1.3.2 Fonctionnels 6
1.3.3 De scurit 7
1.3.4 De troubleshooting 7
2 Les diffrentes solutions 8
2.1 Solutions logiques 8
2.1.1 Les ponts grs au niveau systme 8
2.1.2 Les Virtual Ethernet Bridges (VEB) 8
2.1.3 Les Virtual Distributed Switches (VDS) 11
2.2 Solutions mixtes (physique/Logiques) 11
2.2.1 Les Virtual Ethernet Ports Aggregators 12
2.2.2 Les VN-Tag 12
2.2.3 Les cartes rseau Single Root I/O Virtualization compatibles 13
3 Choisir sa solution 14
4 Retour exprience 15
4.1 Le contexte 15
4.2 Larchitecture 16
4.3 Lutilisation 17
Conclusion 18
Rfrences 19
Glossaire 20
-
4
Executive Summary
L'accroissement de l'utilisation des machines virtuelles dans nos campus a ncessit que le rseau
s'adapte. Il doit rpondre aux mmes exigences pour laccs aux machines virtuelles que celles
demandes pour laccs au serveur physiques : scurit, fiabilit, performances.
La commutation virtuelle a volu pour proposer aujourd'hui un panel trs vari de solutions
rpondant aux besoins des administrateurs systme et rseau. Elle va mme au-del de ce que
nous propose le physique (dplacement chaud d'un port avec toutes ses politiques de scurit,
densit de ports importante et volutive).
Ce document prsente les problmatiques du passage de la commutation physique la
commutation virtuelle tant en termes techniques quorganisationnels. Il fournit un panel des solutions
disponibles et les avantages / inconvnients de celles-ci.
Une solution d'implmentation est galement prsente.
-
5
1 Quest-ce quun commutateur virtuel ?
1.1 Historique
La virtualisation sest impose progressivement depuis le dbut des annes 2000 en commenant
par le poste de travail, puis dans les infrastructures de dveloppement avant de se gnraliser dans
beaucoup de campus pour la production.
De quelques machines tournant sur un serveur physique dans le mme plan dadressage IP nous
sommes passs des dizaines voire des centaines de machines virtuelles appartenant de
multiples VLAN, et ayant des contraintes en terme de scurit et de qualit de service quivalentes
aux machines physiques.
1.2 Rle et intrt des commutateurs virtuels.
Lobjectif des commutateurs virtuels est dassurer une connectivit de niveau 2 entre les diffrentes
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 sagir dans ce cas, du
besoin de raliser une opration de routage ou bien de lutilisation des normes 802.1Qbg ou
802.1Qbh comme voqu dans la suite du document.
Techniquement, un agrgat de VLAN est connect aux serveurs hbergeant les hyperviseurs et les
quipes techniques en charge de linfrastructure de virtualisation crent des commutateurs virtuels
associs aux diffrents VLAN avant de leur attacher les machines virtuelles.
La virtualisation offre une souplesse et une simplicit trs importante pour la ralisation de certaines
tches qui incombent aux quipes rseaux tels que la migration de serveurs et les taches de
brassages associes.
Elle permet des rductions de cot en limitant le nombre de commutateurs physiques. Cette
limitation simplifie galement les architectures rseau rendant leur administration plus simple.
-
6
On comprend donc le dveloppement de cette commutation virtuelle. Nanmoins cela ne va pas
sans entraner dautres problmes.
1.3 Problmes induits par ce type de commutation
1.3.1 Organisationnels
La gestion de linfrastructure de commutation virtuelle est souvent, au dpart, ralise par les
quipes systmes qui ont la matrise de lhyperviseur. Cela peut poser de nombreux problmes si
lorganisation na pas t pense au pralable.
En effet :
Lquipe rseau perd de la visibilit et de ses prrogatives sur une partie du rseau.
Lquipe rseau ne peut plus auditer et vrifier la cohrence de tous les lments actifs de
larchitecture.
Une partie de la gestion de la scurit du rseau est transfre lquipe systme qui nen a
pas forcment lexprience.
Lquipe rseau peut se sentir dpossde dune partie de son travail. Ceci pouvant
engendrer des conflits. Ce problme nest pas ngliger car outre la mauvaise ambiance
gnre, il peut engendrer une dissolution des responsabilits et terme, des difficults
rsoudre une panne.
1.3.2 Fonctionnels
Les quipements actifs disposent de beaucoup de fonctionnalits qui peuvent ne pas tre retrouves
dans ce que proposent par dfaut les infrastructures de virtualisation:
Supervision :
En gnral, les fonctionnalits de type sFlow/NetFlow ou SNMP ne sont pas disponibles sur
les switchs virtuels fournis par dfaut avec les hyperviseurs. Cela rend la supervision globale
de l'infrastructure de commutation impossible. Une partie de la charge rseau chappe ainsi
totalement la surveillance des quipes en charge de la supervision.
Analyse des flux :
Les fonctionnalits de type RSPAN qui permettent danalyser la totalit des flux transitant sur
un port ou un VLAN sont galement souvent absentes rendant par exemple lutilisation dun
IDS complexe pour analyser le trafic entre les machines virtuelles.
QoS :
Les fonctionnalits de qualit de service ne sont gnralement pas implmentes sur les
switchs virtuels standards ce qui peut poser dimportants problmes pour lhbergement
virtualis de certains services tels que ceux lis la ToIP ou la visioconfrence.
Fonctions de scurit :
Des mcanismes de protection contre les attaques de type ARP Cache poisoning ou DHCP
Snooping couramment implants sur les commutateurs ne sont pas toujours prsents sur les
architectures virtualises. Cest galement le cas des Private VLAN qui permettent dinterdire
-
7
les flux entre machines au sein dun mme VLAN ou encore des Access-list qui ne sont
souvent pas disponibles sur les commutateurs virtuels basiques.
1.3.3 De scurit
Les problmes de scurit induits par la commutation virtuelle dcoulent des deux points prcdents.
Ceux lis lorganisationnel :
La sparation des tches entre les quipes, si elle na pas t anticipe peut savrer dlicate
dans le cadre de la virtualisation avec des effets de bord concernant la scurit (erreur de
manipulation de lquipe systme engendrent un problme ct quipe rseau, quipe non forme
au rseau devant grer des lments actifs, ...).
Parmi les principaux risques induits nous pouvons citer la cration dune machine virtuelle
connecte par erreur plusieurs VLAN et permettant de contourner la politique de scurit ou
encore un dni de service au niveau rseau rendant inoprante linfrastructure de virtualisation suite
au mauvais paramtrage, ou encore labsence de rgles de QoS, de filtrage. Ce type derreurs de
configuration nest pas propre aux environnements virtualiss mais le risque est accru si lquipe se
chargeant de la configuration des switch virtuels nest forme qu ladministration systme.
Ceux lis au Fonctionnel :
Comme nous venons de le voir, beaucoup de fonctionnalits de scurit sont absentes dans les
switchs basiques proposs par les infrastructures de virtualisation.
Par consquence un attaquant pourra raliser des attaques plus facilement et avec plus dimpact
que sil avait pris la main sur une machine physique.
Il est toutefois noter que ladhrence entre machines virtuelles et switchs virtuels tant
particulirement forte, certaines fonctionnalits de scurit ne sont possibles que dans le monde
virtuel. Il sagit en particulier de pouvoir interdire le passage des cartes rseaux en mode
promiscuous ou des fonctionnalits lies au partage et la limitation des I/O rseaux entre
machines virtuelles. Ces manques peuvent, comme nous le verrons par la suite tre combls en
souscrivant une licence additionnelle. En particulier, des fonctionnalits de QoS et de protection
face aux attaques rseau.
1.3.4 De troubleshooting
Certaines fonctionnalits tant gnralement absentes (supervision, analyse de flux), la dtection
et lanalyse des problmes sur le rseau peuvent se montrer particulirement difficile. Dautant que
les machines virtuelles et les commutateurs partageant souvent le mme matriel (celui de
lhyperviseur), lanalyse et la rsolution de problmes de performances se trouvent complexifies.
Cest tout particulirement le cas pour isoler ce qui est inhrent des problmes lis au systme et
des problmes lis au rseau. Et mme pire, une charge systme importante peut dgrader les
performances rseau ou linverse.
-
8
2 Les diffrentes solutions
2.1 Solutions logiques
2.1.1 Les ponts grs au niveau systme
Pour permettre aux machines virtuelles daccder au rseau en utilisant leur propre IP, la solution
qui tait habituellement choisie en premier lieu tait lutilisation de la fonction pont rseau
intgre au systme. Cest en effet le mode de fonctionnement le plus simple et rapide mettre en
place.
Lorsque lhyperviseur est un serveur linux, cela ncessite lutilisation dun package spcifique
(dans le cas de Debian, bridge-utils ). Il va permettre de crer une interface bridge brX liant
une interface physique ethx avec une interface logique tapX sur laquelle sera connecte une
machine virtuelle.
Les premires versions de Xen utilisaient ce mcanisme et il est encore utilis par KVM. Ce mode
de fonctionnement permet dobtenir une connectivit de niveau 2 entre une ou plusieurs machines
virtuelles et un rseau physique et reste tout fait appropri pour une utilisation limite quelques
machines ou une architecture de test. Lutilisation dans une architecture plus tendue (grosse
quantit de VM, de VLAN) nest pas conseille car le management et la supervision de nombreux
bridges est complexe.
2.1.2 Les Virtual Ethernet Bridges (VEB)
Ils prennent la forme dune brique logicielle lie lhyperviseur (sans surcot) offrant les
fonctionnalits dun commutateur physique dentre de gamme. Il ne sagit donc plus dutiliser les
mcanismes de commutation systme du serveur hte comme dans le cas prcdent, mais de
proposer une gestion de la commutation au niveau de lhyperviseur.
Si des machines virtuelles lies un VEB doivent communiquer entre elles, cet change restera
interne au VEB de lhyperviseur. Si la destination est externe, lchange passera alors par linterface
physique du serveur.
Bien que plus volus que les ponts systmes, ils nintgrent pas toutes les fonctions attendues
par un commutateur notamment en termes de management, de monitoring, de gestion de la qualit
de service ou de scurit. Ils ncessitent des modes de gestion qui leurs sont propres et sont
souvent limits une utilisation avec un seul type dhyperviseur.
Ladministration de ce type de commutateur est dailleurs souvent ralise par lquipe en charge
de lhyperviseur et donc plutt des profils systmes. Ceci entranant une perte de visibilit par
lquipe rseau.
Cette solution est sans doute la bonne dans le cas o le nombre de machines virtuelles est limit
et ncessite peu de fonctions volues de niveau 2. Elle permettra des changes rapides entre
machines dun mme VEB.
Ce type de solution sera nanmoins difficile mettre en place dans des architectures avec un
grand nombre de serveurs physiques qui ncessiteront plutt un mode distribu. En effet, la
configuration des port-groups devra tre rplique manuellement sur chaque commutateur virtuel
-
9
afin quune VM lors de son dplacement dun serveur un autre puisse retrouver sa configuration de
port virtuel.
Exemple avec VMWare vsphere
Dans le cas dun achat de licence standard vsphere. Lutilisateur disposera dun VEB nomm
Vswitch qui propose un ensemble de fonctionnalits basiques (L2 forwarding, vlans..).
Raccordement des machines virtuelles aux vSwitch, un vSwitch tant cr par VLAN.
-
10
Options disponibles pour chacun des vSwitch.
Nous voyons quil sagit doptions trs basiques, plutt ce qui est attendu comme fonctionnalits
sur des commutateurs daccs bas de gamme pour postes de travail que pour des quipements mis
en place pour laccs des serveurs dans un Data Center.
-
11
2.1.3 Les Virtual Distributed Switches (VDS)
Les Virtual Distributed Switches (VDS) reprennent le concept des Virtual Ethernet Bridge,
savoir quil sagit dune commutation logicielle ralise par lhyperviseur, mais en en tendant
considrablement les fonctionnalits.
La principale diffrence avec les VEB est la possibilit de dployer des configurations rseau
complexes sur de multiples serveurs physiques.
En effet, lensemble des switches virtuels distribus sont regroups dans un seul chssis virtuel
pilot par un superviseur, o chaque module correspond en ralit un serveur hte.
Ds lors, toute la configuration est centralise en un seul point, permettant lquipe rseau de
simplement dfinir des profils de ports, qui seront automatiquement pousss sur tous les switches
virtuels et mis disposition de lquipe systme qui pourra les affecter aux machines virtuelles.
Cette sparation entre la gestion rseau et systme est aussi un avantage de certains
VDS. Ladministrateur rseau va pouvoir grer le commutateur comme sil sagissait d'un
commutateur physique de niveau 2 classique alors que ladministrateur systme va simplement
affecter une machine virtuelle un profil dutilisation dfini par lquipe rseau.
Celle-ci va retrouver les fonctionnalits dun commutateur physique de niveau 2 classique
(monitoring de port, qualit de service, scurit -- Private VLAN, DHCP Snooping, ARP Inspection...),
aussi bien pour les interfaces rseaux des machines virtuelles que les interfaces physiques des
serveurs htes, et va pouvoir crer des profils de ports adapts chaque type de machine virtuelle.
Un avantage supplmentaire est que tout dplacement de VM vers un autre serveur hte sera
entirement transparent au niveau rseau.
Ce modle sera donc idal dans les cas o les quipes rseau et systme sont diffrentes et
souhaitent conserver chacune leur primtre propre, o les problmatiques de contrle ou de
scurit sont importants, et partir du moment o il y a plusieurs serveurs htes desservant chacun
un nombre important de machines virtuelles.
Exemple avec VMWare vsphere
Dans le cas de vSphere, il faut acqurir la licence vSphere la plus chre, cest dire Entreprise Plus
pour disposer des fonctionnalits de commutation avances. Le prix public de cette licence est prs
de 2,5 fois plus cher que celui de la version standard. (http://www.vmware.com/products/datacenter-
virtualization/vsphere/pricing.html).
Cette licence ouvre galement la possibilit dutiliser des commutateurs logiciels tiers (Cisco Nexus
1000v, IBM 5000v, ...) ou les commutateurs avancs de vmware appels Ditributed Switch et
disposant des fonctionnalits 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 dlments physiques est de plus en
plus mise en avant par les constructeurs. Ils argumentent sur le fait que ce type de solution libre le
-
12
serveur du traitement processeurs lis au fonctionnement du switch virtuel, quaucun commutateur
virtuel ne possde lensemble des fonctionnalits dun commutateur physique, quil est plus simple
dintgrer dautres quipements (IPS, firewalls).
Nous navons nanmoins pas trouv de retours dexprience dans la communaut enseignement /
recherche sur ce type de solution, ni pu les tester.
2.2.1 Les Virtual Ethernet Ports Aggregators
Les Virtual Ethernet Ports Aggregators (VEPA) reprennent la norme 802.1 Qbg (Edge Virtual
Bridging) et sont en particulier proposs par les infrastructures HP.
Lobjectif de ces connecteurs est de se rapprocher au plus prs du fonctionnement habituel du
rseau physique. Dans ce mode, les machines virtuelles sont gres comme des serveurs
physiques. La commutation des paquets entre deux serveurs virtuels est ralise par des
commutateurs physiques. Par consquent le module VEPA oblige le trafic provenant des VM sortir
de linterface physique du serveur hbergeant lhyperviseur vers le commutateur physique.
On voit bien les avantages que ce mode de fonctionnement possde :
La mise en place de machines virtuelles ne change rien au travail de lquipe rseau.
Loutillage de supervision et dadministration est le mme.
Lorganisation na pas tre modifie tant donn que les limites entre les quipes systmes
et rseau ne changent pas.
La CPU du serveur nest plus utilise pour commuter le trafic et appliquer les rgles sur les flux
(ACL, QoS, ...)
Lutilisation de VEPA peut donc sembler tre la solution pour les infrastructures existantes bases
sur HP. Elle va nanmoins ncessiter que les quipements physiques supportent ce mode de
fonctionnement, ils doivent pour cela accepter de renvoyer le trafic provenant dun port physique vers
ce mme port (norme 802.1br). Cela nimplique souvent quune mise jour systme.
Si lon veut en plus sparer les flux provenant de chaque VM, il faut que les commutateurs et les
cartes rseaux acceptent le QinQ. (802.1ad).
Ils devront galement tre puissants et rapides pour avoir des performances en termes de dbit et de
latence quivalentes celles que pourraient raliser un VEB entre des machines virtuelles
hberges sur un mme serveur.
Une implmentation possible de ce type de solution est dutiliser un switch virtuel compatible VEPA
comme le HP5900v en lintgrant un hyperviseur VSphere de la mme manire quun switch
distribu.
2.2.2 Les VN-Tag
Les solutions VN Tag se basent sur la norme 802.1Qbh et sont proposes par Cisco.
Lobjectif et le mme que pour les VEPA : faire remonter le trafic vers des commutateurs physiques.
Un tag est ajout au flux provenant de chaque VM afin quil puisse tre identifies par le
commutateur. On pourra ainsi configurer les ports de celui-ci comme si la machine virtuelle tait
directement connecte dessus.
-
13
La problmatique, est que cette solution, bien qutant potentiellement une future norme,
ncessite la fois des switches Nexus de Cisco mais aussi une infrastructure serveur Cisco UCS.
2.2.3 Les cartes rseau Single Root I/O Virtualization compatibles
Une autre solution est lutilisation de cartes compatibles SR-IOV. Ces cartes physiques se prsentent
au niveau systme ou de lhyperviseur comme une ensemble dinstances diffrentes de cette mme
carte (le nombre dpendant de la carte).
Ce type de solution permet de dporter la charge processeur dun VEB sur un quipement hardware
ddi.
SR-IOV peut par exemple tre utilis avec Vsphere 5.1. Ce mode dimplmentation ne permettra
nanmoins pas dutiliser de nombreuses fonctions avances (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 :
http://www.intel.com/support/fr/network/adapter/pro100/sb/CS-031492.htm
-
14
3 Choisir sa solution
Nombre de serveurs
ESX 3
Maintenance Sous traite.
Nexus 1010v
Nexus 1000v
Volont de rester sur de la
commutation physique et
budget important
ouinon
VEPA/VN-TAG
Disponibilit du switch pour
lHyperviseur utilis, fonctionnalits ncessaires
VMWare, Hyper-V
Equipes rseau/systme
distinctes et importantes
Besoin de fonctionnalits
Scurit/management
non prsentes
Openvswitch
vDSwitch
Xen,KVM,VBox
VMware
-
15
4 Retour exprience
4.1 Le contexte
La solution prsente a t mise en place la DSI du CNRS pour rpondre plusieurs besoins.
Tout dabord une quantit accrue de projets ncessitant toujours plus de serveurs et donc de budget
(achat, hbergement), ensuite un manque de personnels ne permettant pas ladministration et la
supervision dautant dquipements.
Lutilisation de la virtualisation nous est apparue comme la meilleure solution pour rpondre
cette problmatique. Durant quelques mois, notre utilisation de la virtualisation a t limite
quelques dizaines de machines virtuelles.
Nous utilisions lhyperviseur VMware qui tait administr par lquipe systme. Ils avaient mis en
place le VEB intgr la solution (vswitch). Un lien 802.1q tait configur sur le switch physique afin
que lquipe systme puisse attribuer aux machines virtuelles le VLAN de leur choix.
Ce mode de fonctionnement a atteint ses limites avec laugmentation exponentielle du nombre de
machines virtuelles. En particulier, il est devenu ncessaire de faire transiter les rgles de scurit
affectes une machine virtuelle lors dun dplacement de celle-ci (sans coupure des flux
utilisateurs).
Une solution aurait pu tre de partir vers le Virtual Distributed Switch de VMWare mais lquipe
rseau avait dj une comptence Cisco et des outils dadministration maitriss pour ce fabricant. La
possibilit de mettre des ACL sur les commutateurs virtuels Cisco et certaines fonctionnalits de
QoS ont aussi t des raisons de ce choix.
-
16
4.2 Larchitecture
Larchitecture mise en place utilise donc un commutateur virtuel distribu. Sur chaque ESX est
install un programme li lhyperviseur 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 contrler tous ces VEM rpartis sur les diffrents serveurs ESX.
Cest le superviseur (VSM - Virtual Supervisor Module). Cest ce module qui hberge la configuration
de lensemble.
Le terme nexus 1000v dsigne donc la somme de ce (ou de ces) VSM et de tous les modules
VEM rpartis sur chaque serveurs ESX.
Une mise jour de celui-ci ncessitera donc une mise jour la fois du VSM (quivalente une
mise jour dun quipement rseau) et une mise jour des VEM sur chaque ESX qui correspond
plus un ajout de module dans un systeme VMWARE.
Le superviseur VSM qui contrle toutes les VEM peut soit tourner dans une machine virtuelle
(infrastructure entirement virtualise), soit tre dport sur une ou deux appliances physiques (en
actif/passif) : les Nexus 1010 ou 1110. Celles-ci peuvent galement prendre en charge dautres
applications directement lies au Nexus 1000V (analyse du rseau, firewall logiciel distribu etc).
Une option en appliance physique prviendra notamment tout impact sur le switch distribu en cas
de perturbation ou dincident sur le serveur hbergeant la VSM.
-
17
Dans la solution prsente, nous navons pas de ce type dquipement. Les deux superviseurs en
actif /passif sont donc prsents sous la forme de deux machines virtuelles rparties sur deux ESX.
Sachant que nous disposions de quatre cartes rseau physiques sur chaque ESX, nous avons
dcid den ddier une pour laccs au VSM. En effet, en utilisant ce mode hybride (VEB, VDS) nous
voulions viter de placer les VSM derrire les VEM quils grent, une mauvaise configuration sur
ceux-ci pouvant les rendre inaccessibles. Le risque est limit car une perte des VSM nentraine pas
forcment une coupure des flux passant par les VEM, mais nous trouvions ce mode de
fonctionnement plus propre.
4.3 Lutilisation
Lutilisation dun commutateur virtuel de type nexus est quivalent lutilisation dun switch classique.
La configuration des interfaces se fait au travers de port-profiles.
Chaque port profile regroupe un ensemble dinformations communes lensemble des ports qui le
constitue. Ces informations peuvent tre des vlans, pvlans, de la QoS, des ACL
Ainsi, une fois ce port profile dfini par lquipe rseau dans le VSM, il sera disponible pour lquipe
systme dans linterface de vSphere afin de laffecter une machine donne. On voit bien ainsi la
sparation des tches entre quipes.
Dans notre port-profile correspondant aux uplink (vers les switch physiques) nous avons utilis la
technologie mac-pinning pour letherchannel. Ce mode de fonctionnement lavantage dtre
utilisable avec nimporte quel type de switch physique. (Affectation de la mac adresse dune VM
une interface physique du serveur en round robin).
Dans le nexus 1000v, on voit les VM comme si elles taient connectes sur les ports dun switch
Cisco physique.
-
18
Conclusion
Les solutions proposes pour mettre en rseau nos machines virtuelles sont nombreuses et varies.
Cette varit est la fois un atout et une difficult. Il est en effet difficile dtre sr que notre choix
sera le plus efficace et le plus prenne. Les technologies sont souvent rcentes et peu prouves.
De nouvelles solutions apparaissent sans cesse remplaant celles qui, il y a peu, avaient le vent en
poupe. Elles dpendent souvent de votre hyperviseur, de vos serveurs, de vos commutateurs
physiques, de votre organisation. Dans le panel de solutions que nous vous avons prsent, vous
trouverez sans doute la plus adapte si vous avez bien dfini au pralable toutes vos contraintes.
-
19
Rfrences
1 Cisco Nexus 1000V Series Switch Deployment Guide with Cisco Unified Computing System
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/guide_c07-704280.html
2 VMware Virtual Networking Concepts
http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf
3 PCI-SIG SR-IOV Primer: An Introduction to SR-IOV Technology
http://www.intel.com/content/www/us/en/pci-express/pci-sig-sr-iov-primer-sr-iov-technology-paper.html
-
20
Glossaire
NETFLOW Protocole Rseau permettant de collecter des informations sur le trafic chang.
SNMP Simple network management Protocol. Cest un protocole permettant de superviser des quipements
rseau.
RSPAN Remote switched port analyser. Fonctionnalit permettant de copier les donnes transitant sur un port
vers un autre port.
ACL Access Control List. Liste dadresses IP autorises ou non transiter au travers dun quipement
Rseau
IDS Intrusion Detection System. Mcanisme permettant de dtecter un trafic suspect circulant sur le rseau.
QOS Quality Of Service Mcanisme permettant de grer les ressources rseau attribues telle ou telle
application.
VEB Virtual ethetnet bridge Commutateur virtuel basique permettant de relier des machines virtuelles entre
elles et vers un Rseau physique.
VDS Virtual distributed switches Commutateur virtuel volu permettant entre autre de grer plusieurs
switchs virtuels rpartis sur des serveurs diffrents.
VEPA Virtual Ethernet port aggregators Mcanisme permettant de faire remonter le trafic des machines
virtuelles vers un switch physique.
SR-IOV Single root I/O Virtualization. Spcification permettant une carte Rseau dapparaitre comme un
ensemble de carte physique. Celles-ci pouvant tre ensuite attribues aux machines virtuelles.
VSM Virtual supervisor module Logiciel permettant de contrler les VEM. Cest le cur des nexus 1000v
VEM Virtual Ethernet module Cest le module des nexus 1000v qui, intgr dans les serveurs, effectue la
commutation des machines virtuelles.
