Rapport Finale

MEMOIRE DU PROJET DE FIN D’ETUDES
Présenté
En vue d’obtention du titre d’:
INGENIEUR D’ETAT
Par
Khadija OULAD BEN TAIB
&
Oumayma MANSOURI
Département GENIE ELECTRIQUE

Option : Electronique & Télécommunications
Sujet :
Implémentation d’une solution clé en main du modèle IaaS (Infrastructure as a
Service) du Cloud Computing
Encadré par :
 M. Mohamed EL AROUSSI (EHTP)

 M. Wassil MERAD (CBI)
 M. Yassine MOUNIR (CBI)
Année Universitaire 2011 – 2012
Mémoire de fin d’études 2011-2012 Page 1

Dédicace
A l’issue de ce travail, je tiens à le dédier:

A la mémoire de mes grands parents. A la mémoire de tout être cher qui nous
a quitté, qu’Allah les prend sous sa miséricorde
A mes parents, pour leur soutien inconditionnel et leur volonté à toute
épreuve
A mes frères, pour leur ouverture d’esprit et leur bonne humeur
A tous les membres de ma famille
A tous mes chers professeurs, de la maternelle aux études supérieurs ; sachez
que chacun d’entre vous a laissé son empreinte en moi
A tous mes amis
A vous
Khadija OULAD BENTAIB

Dédicace
A ma mère, qui m’a entourée de toute son affection et tout son amour,
A mon père, qui n’a ménagé aucun effort en faveur de ma réussite,
A mes chers frères, Mouâd et Al Farouk, qui n’ont jamais cessé de
m’encourager,
A mes chères tantes et leurs maris pour leur soutien inconditionné,
A mes amies et amis, qui ont cru en moi,
A tous mes professeurs qui m’ont encadrée tout au long de mon parcours
scolaire,
A toutes les personnes que j’aime et respecte, qui font et ont fait partie de
ma vie,
Je dédie ce modeste travail.
Oumayma MANSOURI

Remerciements
Au préalable et comme témoignage de notre profonde reconnaissance, nous tenons à

remercier toutes les personnes qui nous ont aidées de près ou de loin à mener à bien
notre projet de fin d’études.
Nous tenons ainsi à exprimer notre gratitude à :
M. DINOURI pour nous avoir accueillies au sein de son département, et pour

avoir fait en sorte que notre stage puisse se dérouler dans d'excellentes
conditions.
M. Wassil MERAD, et M. Yassine MOUNIR, encadrants externes, pour nous

avoir intégrées rapidement au sein de la CBI, nous avoir accordé toute leur
confiance et pour le temps qu’ils nous ont consacré tout au long de cette
période de stage.
M. Abdelmajid JAAFAR, et M. Mohamed BOUATHMANI pour l’aide qu’ils

nous ont fournie tout au long de cette période de stage, sachant répondre à
toutes nos interrogations.
Nos remerciements s’adressent également à tous les membres du personnel de la CBI

pour leur aide et leur disponibilité permanente.
Nous saurons gré à M. Mohamed EL AROUSSI, professeur assistant LETI à l’EHTP,

de son encadrement, son aide et son soutien durant ce travail.
A ces remerciements nous souhaitons associer tout le corps professoral et

administratif de l’Ecole Hassania des Travaux Publics, tous nos collègues qui n’ont
pas hésité à nous aider pendant la réalisation de notre projet, et enfin nos familles
qui ont toujours témoigné d’un soutien sans pareil tout au long de notre cursus
scolaire.

Résumé
Le présent mémoire est le fruit de notre projet de fin d’études réalisé à la Compagnie Bureautique et
Informatique (CBI) à Casablanca, portant sur le Cloud Computing.
Durant ce stage, nous nous sommes familiarisées avec le monde professionnel, plus précisément
celui des Technologies de l’Information. Et dans cette même optique d’intégration, la CBI nous a
confié l’étude du modèle de service IaaS du Cloud Computing, qu’elle envisage de lancer sur le
marché dans un futur proche.
L’étude que nous avons réalisée dans ce cadre nous a permis de nous positionner du côté
fournisseur du Cloud. Plus précisément, c’est le volet de l’infrastructure du Cloud que nous avons
étudié et développé. Notre mémoire a pour problématique : « Implémentation d’une solution clés
en main du modèle IaaS (Infrastructure as a Service) du Cloud Computing »

Sommaire
Introduction générale ..........................................................................................................................13
Chapitre 1 : Généralités ......................................................................................................................14
I. Présentation de l’organisme d’accueil ........................................................................................15
1. Activités de la CBI .................................................................................................................15
2. Organigramme de la CBI .......................................................................................................16
3. Implantation géographique des agences CBI .........................................................................17
4. Ecosystème de la CBI ............................................................................................................18
5. Fiche signalétique de la CBI ..................................................................................................19
6. Métiers de la CBI ...................................................................................................................19
II. Contexte général du projet .........................................................................................................21
1. Introduction ............................................................................................................................21
2. Cloud Computing ...................................................................................................................21
2.1. Définition .........................................................................................................................21
2.2. Caractéristiques du Cloud Computing .............................................................................21
2.3. Modèles du service Cloud Computing .............................................................................22
2.4. Modèles de déploiement du service Cloud Computing ...................................................23
3. Objectifs et démarche du projet..............................................................................................24
Chapitre2 : Eléments du Cloud ..........................................................................................................26
I. Présentation du concept de la virtualisation ...............................................................................27
1. Virtualisation des applications ...............................................................................................27
2. Virtualisation des services réseau...........................................................................................28
3. Virtualisation du stockage ......................................................................................................29
4. Virtualisation des serveurs .....................................................................................................30
II. Virtualisation et Cloud Computing : ..........................................................................................31
1. Les différentes offres de virtualisation : .................................................................................32
1.1. Vue d’ensemble ...............................................................................................................32
1.2. Vue détaillée ....................................................................................................................32
1.3. Etude comparative des offres ...........................................................................................34
2. Choix d’une solution ..............................................................................................................37
Chapitre 3 : Conception, réalisation et gestion du Cloud ...................................................................38
I. VMware vSphere........................................................................................................................39
1. Présentation ............................................................................................................................39
2. Architecture de vSphere 5 ......................................................................................................39
3. Composants de vSphere 5 ......................................................................................................41
3.1. ESXi 5 ..............................................................................................................................41
3.2. Fonctionnalités clés de vSphere 5 ....................................................................................42
II. Mise en réseau dans le Cloud .....................................................................................................45
1. Considérations préliminaires ..................................................................................................45
2. Paramètres de sécurité du réseau virtuel ................................................................................46
3. Paramètres de surveillance du réseau virtuel .........................................................................47
4. Paramètres de QoS .................................................................................................................48
III. Stockage dans le Cloud ..........................................................................................................50
1. Eléments du stockage : ...........................................................................................................50
1.1. Architecture du stockage virtualisé ..................................................................................50
1.1. Types de stockage physique .............................................................................................51
2. Utilisation d’ESXi avec un SAN ............................................................................................53
2.1. Avantages .........................................................................................................................53
2.2. Prendre des décisions préalables au déploiement des machines virtuelles: .....................54
3. Utilisation des banques de données dans l’environnement vSphere ......................................56
3.1. Banque de données VMFS...............................................................................................56
3.2. Banque de données NFS ..................................................................................................57
4. Provisionnement dynamique de stockage (Thin provisioning) ..............................................57
4.1. Provisionnement dynamique du disque virtuel ................................................................58
4.2. Provisionnement dynamique des baies et banques de données VMFS ...........................58
IV. Sécurité du Cloud ...................................................................................................................60
1. Sécurité physique ...................................................................................................................60
1.1. Risques encourus .............................................................................................................60
1.2. Mesures envisageables .....................................................................................................60
2. Sécurité logique du Cloud ......................................................................................................60
2.1. Risques encourus .............................................................................................................60
2.2. Mesures envisageables .....................................................................................................61
3. Offres destinées à la sécurité du Cloud ..................................................................................62
3.1. Offre VMware & Cisco ...................................................................................................62

3.2. Offre VMware : gamme VMware vShield ......................................................................63
V. Réalisations effectuées ...............................................................................................................68
1. Manipulations effectuées : .....................................................................................................68
2. Formation à la CBI concernant les éléments du Cloud: .........................................................89
Chapitre 4 : Accès au Cloud ...............................................................................................................91
I. Réseau d’accès ...........................................................................................................................92
1. Les réseaux câblés ..................................................................................................................92
2. Les réseaux sans fil ................................................................................................................98
II. Interaction avec le Cloud ..........................................................................................................102
1. vCloud Director ....................................................................................................................102
2. Architecture de vCD .............................................................................................................103
3. Services offerts par vCD ......................................................................................................104
4. Mise en réseau vCloud Director ...........................................................................................105
4.1. Types de réseaux dans vCD ...........................................................................................105
4.2. Pools réseau ...................................................................................................................109
III. Orchestration dans le Cloud .................................................................................................111
IV. Facturation des services du Cloud ........................................................................................114
1. VMware vCenter Chargeback ..............................................................................................114
2. Calcul du coût.......................................................................................................................115
V. Cloud hybride ...........................................................................................................................117
VI. Etude de l’existant ................................................................................................................120
1. Clustering .............................................................................................................................120
2. Equipements choisis par l’équipe CBI .................................................................................120
3. Architecture du datacenter dédié au Cloud ..........................................................................124
VII. Architecture globale du Cloud .............................................................................................125
Chapitre 5: Commercialisation du Cloud .........................................................................................127
I. Méthode de la maison qualité QFD ..........................................................................................128
II. Impact écologique du Cloud Computing .................................................................................133
Conclusion générale .........................................................................................................................135
Annexe A : Commutation WAN-MPLS ..........................................................................................138
Annexe B : Commutateur Nexus1000V...........................................................................................147
Annexe C : EMC VNX 5300 ...........................................................................................................148

Bibliographie ....................................................................................................................................149
Webographie ....................................................................................................................................150

Liste des figures
Figure 1: Dates importantes pour la CBI ...........................................................................................15
Figure 2: Organigramme de la CBI ....................................................................................................16
Figure 3: Clients CBI .........................................................................................................................18
Figure 4: Fournisseurs CBI ................................................................................................................18
Figure 5: Fiche signalétique CBI .......................................................................................................19
Figure 6: Métiers CBI ........................................................................................................................19
Figure 7: Modèles du service Cloud Computing ...............................................................................23
Figure 8: Virtualisation des applications ............................................................................................27
Figure 9: Virtualisation de services réseau ........................................................................................28
Figure 10: Virtualisation du stockage ................................................................................................29
Figure 11: Virtualisation des serveurs ................................................................................................30
Figure 12: Hyperviseur de type 1 .......................................................................................................30
Figure 13: Hyperviseur de type 2 .......................................................................................................31
Figure 14: Cartographie basée sur une analyse de Gartner en juin 2011 ...........................................32
Figure 15: Temps d'installation d'Hyper-V et d'ESXi ........................................................................35
Figure 16: Architecture de vSphere 5 ................................................................................................39
Figure 17: Architecture de vCenter Server ........................................................................................40
Figure 18: Composants de vSphere 5 .................................................................................................41
Figure 19: Architecture d'ESXi ..........................................................................................................41
Figure 20: VMware vMotion .............................................................................................................42
Figure 21: VMware Storage vMotion ................................................................................................43
Figure 22: VMware DRS ...................................................................................................................43
Figure 23: VMware DPM ..................................................................................................................43
Figure 24: VMware High Availability ...............................................................................................44
Figure 25: VMware Fault Tolerance ..................................................................................................44
Figure 26: vSphere Standard Switch ..................................................................................................45
Figure 27: vSphere Distributed Switch ..............................................................................................45
Figure 28: Configuration de VLANs privés .......................................................................................47
Figure 29: Contrôle d'E/S réseau ........................................................................................................48
Figure 30: Network vMotion..............................................................................................................49
Figure 31: Architecture du stockage virtualisé ..................................................................................50
Figure 32: Partage d'une banque de données VMFS entre plusieurs hôtes ........................................56
Figure 33: Provisionnement dynamique du disque virtuel.................................................................58
Figure 34: Architecture du Nexus1000V ...........................................................................................62
Figure 35: Services vShield Edge ......................................................................................................63
Figure 36: Services vShield Endpoint ................................................................................................64
Figure 37: Services vShield App ........................................................................................................65
Figure 38: Architecture PON .............................................................................................................93
Figure 39: Architecture AON .............................................................................................................94
Figure 40: Topologies réseau avec PON ............................................................................................95

Figure 41: Topologies réseau avec AON ...........................................................................................95
Figure 42: Division du spectre dans l'ADSL ......................................................................................96
Figure 43: Pont LASER ...................................................................................................................100
Figure 44: Architecture du datacenter fournisseur ...........................................................................102
Figure 45: Architecture de l'environnement vCloud ........................................................................103
Figure 46: Réseau externe vCloud ...................................................................................................106
Figure 47: Réseaux d'organisation vCloud.......................................................................................107
Figure 48: Réseaux vApp vCloud ....................................................................................................108
Figure 49: Récapitulation des configurations des réseaux vCloud ..................................................109
Figure 50: vCenter Orchestrator .......................................................................................................111
Figure 51: Mise en cluster de serveurs Chargeback .........................................................................114
Figure 52: Exemple de Cloud hybride .............................................................................................117
Figure 53: Architecture vCloud Connector ......................................................................................117
Figure 54: Exemple de configuration de placement vCloud Connector ..........................................118
Figure 55: Cisco UCS B200-M2 Blade Servers...............................................................................121
Figure 56: Cisco UCS 6120XP Fabric Interconnect ........................................................................122
Figure 57: Catalyst 4000G Series Switch ........................................................................................122
Figure 58: EMC VNX 5300 .............................................................................................................123
Figure 59: Caractéristques techniques d'EMC VNX 5300...............................................................123
Figure 60: Architecture du datacenter dédié au Cloud .....................................................................124
Figure 61: Architecture globale du Cloud ........................................................................................125
Figure 62: Pièce 6 de la QFD ...........................................................................................................132
Figure 63: Maison qualité ................................................................................................................132
Figure 64: Cloud Computing et Green IT ........................................................................................134

Liste des tableaux
Tableau 1: Récapitulatif des options de configuration des trois solutions .........................................36
Tableau 2: Comparaison entre vSphere 4 et vSphere 5 .....................................................................39
Tableau 3: Types de réseaux d'accès ..................................................................................................92
Tableau 4: Les solutions xDSL ..........................................................................................................98
Tableau 5: Composants et pré-requis de vCloud Management Cluster ...........................................120
Tableau 6: Caractéristiques techniques d’une lame UCS B200M3 .................................................121
Tableau 7: Caractéristiques techniques d’un UCS 2104XP Fabric Extender ..................................121
Tableau 8: Caractéristiques techniques d’un UCS6120 Fabric Interconnect ...................................122
Tableau 9: Catalyst 4000G Series Switch ........................................................................................122
Tableau 10: Pièce 1 de la QFD .........................................................................................................128
Tableau 12:Pièce 3 de la QFD ..........................................................................................................131

Introduction générale
Depuis quelque temps, l'informatique dans le nuage « Cloud Computing » est un sujet qui attise
curiosités et papiers blancs chez différents cabinets de consulting et sociétés de services IT. Ce
nouveau paradigme - bien qu'il ne s'agisse pas d'une technologie révolutionnaire, mais d'un modèle
alternatif pour l'application de solutions IT - apparaît régulièrement comme la panacée pour tous les
problèmes IT, tels que la complexité croissante des systèmes, la consommation énergivore des
centres de données informatiques, l'espace occupé par les serveurs, le besoin perpétuel de diminuer
les coûts au sein du département informatique…etc. Quoi qu'il en soit, les avantages pour les
entreprises sont manifestes: la concentration de services et la portée virtualisée des solutions IT
indépendamment du lieu, sont à l'origine d'économies d'échelle et de forts catalyseurs de synergies.
Consciente de l’opportunité qu’offre cette nouvelle tendance, CBI a décidé de lancer le service IaaS
(Infrastructure as a Service), qui met à disposition des entreprises clientes des ressources « brutes »
d’informatique, à savoir serveurs, mémoire RAM, processeurs et espace de stockage, l’utilisation et
la facturation de ces ressources pouvant être effectuées à la demande, ce modèle présente des
avantages que nous pouvons résumer sous la phrase : bannir l’inclusivité des solutions et s’ouvrir
sur un modèle de pay-per-use.
La perspective du fournisseur comprend les différents aspects techniques de gestion, de

maintenance et de livraison d’infrastructure Cloud, allant du fournisseur au client, en passant par
une liaison réseau elle-même bien étudiée et dimensionnée.
De point de vue client, il est impératif de prendre connaissance des impacts de la solution Cloud
Computing sur la DSI et son écosystème, à savoir la relation DSI/métiers, DSI/départements ou
DSI/partenaires, avant d’opter ou non pour cette solution. Aussi le client devrait-il être soucieux de
l’impact de son activité et de ses choix pour le déploiement de son infrastructure sur
l’environnement, et manifester une implication dans les problématiques Green IT.

Chapitre 1 :
Généralités

Ce premier chapitre est une présentation générale du projet. Il débute par la présentation de
l’organisme d’accueil puis donne un aperçu sur le projet et enfin évoque les objectifs généraux du
projet et la démarche suivie.
I. Présentation de l’organisme d’accueil

1. Activités de la CBI
La Compagnie Bureautique et Informatique (CBI) est un distributeur qui opère au niveau du
secteur informatique tout en assurant des prestations d’intégration, de formation, de mise en place
et de service après-vente, liées aux solutions logicielles ou équipements qu’elle distribue : Elle est
de ce fait un revendeur à valeur ajoutée.
CBI se positionne sur les technologies de l’information qui permettent aux administrations et
entreprises d’accroitre leur productivité en leur offrant des équipements informatiques et
bureautiques. Ses pôles d’activité sont la bureautique, l’informatique, l’intégration de
systèmes, les télécommunications, la formation et le service après-vente.
Créée en 1970 sous le nom de Ruche Maroc, l’entreprise a ensuite été rebaptisée CBI. Elle se
positionnait au début sur le matériel informatique et bureautique uniquement. L’entreprise s’est
peu à peu diversifiée pour suivre les mutations du marché des technologies de l’information, et
s’est étendue aux activités de progiciels, télécommunications, intégration de systèmes et prestation
de services (exemple : CBI est distributeur exclusif de Toshiba).
Un certain nombre de dates clés jalonnent l’histoire de CBI :
Figure 1: Dates importantes pour la CBI

2. Organigramme de la CBI
Figure 2: Organigramme de la CBI

3. Implantation géographique des agences CBI
A travers ses agences et un réseau dynamique de revendeurs, CBI assure à toutes les entreprises
marocaines une proximité géographique qui permet de mieux réagir mais surtout de pouvoir
anticiper leurs besoins tout en préservant leur productivité.
6 agences nationales et 1 succursale en Afrique de l’ouest
SIEGE
29 / 30 Lot. Attaoufik • Imm. CBI • Sidi Maârouf
20190 Casablanca • Maroc
Tél. 05 22 43 71 71 • Fax 05 22 43 71 87
E-mail : cbi@cbi.ma
CBI RABAT
18, Av. de France • Agdal Rabat • Maroc
Tél. 05 37 77 50 17 / 45 • Fax 05 37 77 86 47
E-mail : agrabat@cbi.ma
CBI FES
33, Av. Roi Hussein de Jordanie • Fès • Maroc
Tél. 05 35 73 04 28 / 90 • Fax 05 35 73 04 55
E-mail : agfes@cbi.ma
CBI TANGER
45, Rue El Maârif • Rés. Juliana Angle Rue Al Antaki
Tanger • Maroc
Tél. 05 39 34 13 06 / 33 / 32 • Fax 05 39 34 13 07
E-mail : agtanger@cbi.ma
CBI AGADIR
Av. Kennedy • Agadir • Maroc
Tél. 05 28 82 64 68 • Fax 05 28 82 07 20 • E-mail : agagadir@cbi.ma
CBI MARRAKECH
Bd. Prince My Abdellah, Résidence Taiba, Magasin n°4 • Marrakech • Maroc
Tél. 05 24 31 27 58 • Fax 05 24 93 05 37 • E-mail : agmarrakech@cbi.ma
CBI SENEGAL
44, Rue Vincens • BP 11769 • Dakar • Sénégal
Tél. +221 821 01 01
Fax +221 821 02 00

4. Ecosystème de la CBI
CBI traite avec tous types d’entreprise, tous secteurs confondus. Elle a un carnet de clients
prestigieux tels que :
Figure 3: Clients CBI
Afin de concourir à la réalisation de ces objectifs, divers contrats lient CBI à ses partenaires
fournisseurs :
Figure 4: Fournisseurs CBI

5. Fiche signalétique de la CBI
Figure 5: Fiche signalétique CBI
6. Métiers de la CBI
Figure 6: Métiers CBI

 Informatique lourde : L’infrastructure informatique est essentiellement constituée de
matériel informatique (postes de travail et serveurs) et d’ensembles de stockage de données.
Certains systèmes sont capables d’assurer une continuité de service.
 Informatique mobile : CBI propose les solutions mobiles Toshiba aux administrations,
grandes entreprises et PME, aux professions libérales, aux particuliers ainsi qu’aux
étudiants. CBI est le distributeur exclusif d’ordinateurs portables Toshiba.
 Télécommunications : Cette activité est constituée essentiellement de systèmes de

communication essentiellement fondées sur la technologie IP. Ils ont l’avantage de
permettre une réduction des coûts de communication internes des entreprises avec des taux
pouvant aller jusqu’à 40% par rapport à un système de communication classique
(analogique). La technologie permet également de transporter de la voix et des données, ce
qui offre un large panel d’options.
 Bureautique (éditique) : L’activité « bureautique » propose des produits axés sur les
copieurs, ensembles de gestion documentaire multifonctions, options et consommables
(toner et papier). Selon les données de CBI, ses parts de marché sont égales à celles de
Xerox, son principal concurrent. Cette division gère les activités suivantes:
 Vente: l’offre peut inclure les consommables et le service après-vente ;
 Location à la durée: appelée à CBI « contrat de location », cette offre met à
disposition du client des ensembles de gestion documentaire multifonctions en plus
de leur maintenance. Ce « contrat de location » est facturé par un forfait mensuel en
plus d’un coût à la copie permettant de couvrir l’usure et la dégradation du matériel ;
 Location à la copie: la facturation de cette offre se fait sur la base du nombre de
copies réalisées ;
 Maintenance: les contrats de maintenance sont négociés et établis au cas par cas.
 Intégration systèmes: Les principaux pôles de cette activité sont:
 Consulting en architecture de systèmes d’information en intégration de solutions applicatives ;

 Gestion électronique des documents, gestion de la performance, gestion de la relation client ;
 Assistance et développement ;
 Maintenance logicielle ;
 Formation ;
 Support téléphonique.

II. Contexte général du projet
1. Introduction
Dans un contexte économique où la concurrence fait rage, les besoins des utilisateurs sont en
constante évolution. Plus qu'un lieu dans l'espace, le travail s'est mué en un concept omniprésent,
permanent et sans bornes. De fait, les entreprises veulent pouvoir accéder à leurs données et à leurs
applications en tous lieux et à tout moment, à partir de n'importe quel périphérique.
C’est dans cet état d’esprit que le Cloud Computing a vu le jour en 2008, défini comme étant un
modèle économique de l’informatique vue comme un service, et ceci à tous les niveaux.
CBI, ne pouvant rester indifférente face à cette nouvelle technologie, a décidé de se lancer dans
cette aventure qui va non seulement rendre service aux clients, mais aussi à la CBI elle-même vu
que sa stratégie consiste en premier lieu à migrer son centre de données traditionnel vers un autre
dédié au Cloud Computing et par la suite en faire profiter les entreprises.
Ce projet de fin d’études s’inscrit dans ce sens, et a comme problématique :
« Implémentation d’une solution clé en main du modèle IaaS (Infrastructure as a Service)

du Cloud Computing »
2. Cloud Computing
2.1.Définition
Le Cloud Computing est un concept qui fait référence à l’utilisation de la mémoire, des capacités de
calcul des ordinateurs et des serveurs répartis liés par un réseau tel Internet, sans pour autant se
soucier de l’emplacement de ces ressources. En effet les utilisateurs (le plus souvent des
entreprises) ne sont plus propriétaires de leur infrastructure informatique et peuvent en revanche
accéder de manière évolutive à de nombreux services en ligne sans avoir à gérer l'infrastructure
sous-jacente, souvent complexe.
Ainsi, les applications et les données ne se trouvent plus sur l'ordinateur local, mais –
métaphoriquement parlant – dans un nuage (Cloud) composé d'un certain nombre de serveurs
distants interconnectés. L'accès au service se fait par une application standard facilement disponible,
la plupart du temps un navigateur Internet.
Cette nouvelle technologie nous pousse à mener une réflexion sur ces différents aspects : D’abord
les éléments le constituant, ensuite son apport et sa valeur ajoutée dans les NTIC du futur, ses
différentes architectures, et finalement les limites de cette technologie en vogue.
2.2.Caractéristiques du Cloud Computing
Accès universel via le réseau
Un environnement de type Cloud Computing est accessible via le réseau quelque soit le
périphérique utilisé (PC, Tablette, Smartphone...).

Mise en commun des ressources
L’accès aux ressources se fait sans se soucier du nombre des serveurs, taille des disques, nombre
des processeurs ou bien la capacité totale du stockage.
Elasticité
Il est possible, grâce à cette nouvelle technologie, d’augmenter et de diminuer la taille des
ressources à la demande.
Libre service
L’utilisateur peut consommer les ressources qui lui sont allouées sans demander une intervention
auprès du fournisseur.
Service mesurable et facturable
Le fournisseur est capable de mesurer de façon précise la consommation des différentes ressources.
2.3.Modèles du service Cloud Computing

Le service Cloud Computing se décline sous trois modèles :
 IaaS (Infrastructre as a Service)
Il s’agit de la mise à disposition, à la demande du client, de ressources d’infrastructure dont la plus

grande partie est localisée dans des centres de données distants. La facturation dans ce cas est
établie en fonction de l’utilisation.
Cette infrastructure doit permettre au client de démarrer ou arrêter à la demande des serveurs
virtuels (Linux ou Windows), sans avoir à se soucier des machines physiques sous-jacentes, et des
coûts de gestion qui y sont liés (remplacement de matériel, climatisation, électricité, etc). L’offre
IaaS doit assurer également une transparence vis-à-vis de l’utilisateur dans le cas par exemple d’une
panne d’une ou plusieurs ressources.
 PaaS (Plateforme as a Service)
Il s’agit de la mise à disposition, à la demande du client, d’une plate-forme d’exécution, de

déploiement et de développement des applications, dont l'objectif consiste à proposer un
environnement modulaire capable de combiner plusieurs fonctions et processus métier, voire
plusieurs technologies en provenance de divers éditeurs. De plus, cette plateforme doit offrir une
grande flexibilité, permettant notamment de tester rapidement un prototype ou encore d'assurer un
service informatique sur une période de courte durée.

Les principaux acteurs sont ici SalesForce.com (Force.com), Google (Google App Engine),
Microsoft (Windows Azure), Facebook (Facebook Platform).
 SaaS (Software as a Service)
Il s’agit de la mise à disposition du client d’un logiciel non pas sous la forme d'un produit qu’il
installe en interne sur ses machines, mais en tant qu'application accessible à distance comme
service, par le biais d'Internet et du Web. Le client ne paie pas pour posséder le logiciel en lui-même
mais plutôt pour l’utiliser.
L’utilisation reste transparente pour les utilisateurs, qui ne se soucient ni de la plateforme, ni du

matériel qui sont mutualisés avec d’autres entreprises.
Les principales applications actuelles de ce modèle sont la gestion de relation client (CRM), la
vidéoconférence, la gestion des ressources humaines, les communications unifiées, le travail
collaboratif et les emails.
Figure 7: Modèles du service Cloud Computing
2.4.Modèles de déploiement du service Cloud Computing
1.1.1 Cloud privé

Le Cloud privé se définit comme la mise en place d’un centre de données dédié, fournissant des
services Cloud. Concrètement, les applications virtualisées « privées » sont soit administrées
directement par l'entreprise qui gère seule son infrastructure, dans ce cas le Cloud privé est interne,
soit déléguées, c’est-à-dire qu’un prestataire de confiance prend en charge une partie des services
externalisés, dans ce cas le Cloud privé est externe.

Le Cloud privé vise à améliorer la rentabilité d'une infrastructure virtuelle grâce à une plus grande
densité de la charge de travail et à une plus grande utilisation des ressources.
1.1.2 Cloud public

Dans ce cas, les ressources sont accessibles via Internet, partagées entre plusieurs clients et gérées
par un prestataire externe, propriétaire de ces ressources.
Amazon, Google et Microsoft proposent un Cloud public dans lequel n'importe quel particulier ou
n’importe quelle entreprise peut héberger ses applications, ses services ou ses données. Pour les
consommateurs, il n'y a donc aucun investissement initial fixe et à priori, aucune limite de capacité.
1.1.3 Cloud hybride ou mixte

Ce modèle de déploiement associe l’utilisation, pour un même client, d’un Cloud privé et un autre
public. Le client peut ainsi déporter ses applications qui consommeront des données stockées et
exposées dans un Cloud privé, vers un Cloud public, faire communiquer deux applications
hébergées dans deux Clouds privés distincts, ou encore consommer plusieurs services hébergés
dans des Cloud publics différents. Dans tous ces cas de figure, nous avons affaire à la notion de
Cloud hybride ou mixte.
3. Objectifs et démarche du projet

Objectifs du projet :
 Faire une étude générale portant sur le Cloud Computing afin de se familiariser avec ce
concept.
 Traiter le concept de la virtualisation qui est le point fort du Cloud Computing.
 Faire une étude comparative de différentes solutions de Cloud Computing.
 Etudier les offres de la solution retenue dans les domaines de la virtualisation, du stockage
et de la sécurité.
 Décider si le datacenter dédié au Cloud dans le local de la CBI est satisfaisant vis-à-vis des
pré-requis d’installation des différents composants du Cloud.
 Installer quelques composants indispensables à la mise en place d’une infrastructure
Cloud.
 Décider de la manière dont le client va pouvoir accéder à ses ressources via Internet.
 Tracer une architecture d’accès au Cloud, du client jusqu’à la CBI.
 Faire une étude commerciale pour aider la CBI à mieux cerner les exigences du client vis-
à-vis du Cloud Computing.
En marge des objectifs cités ci-dessus, le présent PFE se veut l’occasion de mettre la problématique
citée auparavant dans un contexte académique : apport de solutions pratiques, sur la base de
connaissances théoriques propres à une formation en Electronique et Télécommunication.
Démarche de réalisation du projet

Phase 1 : Faire une étude générale sur le sujet du Cloud Computing à travers des recherches visant
au début la compréhension du concept et la raison pour laquelle il est sujet à tant de débats.

Phase 2 : Aborder le sujet de la virtualisation d’une manière générale afin de comprendre sa
relation étroite avec le Cloud Computing, et comparer les différentes offres existantes dans ce sens.
Phase 3 : Choisir la solution la plus avantageuse à nos yeux ainsi qu’aux yeux de l’entreprise
d’incubation.
Phase 4 : Mener une étude plus approfondie sur la solution retenue, à travers des recherches qui ont
été sujettes à plusieurs présentations faites devant nos encadrants ainsi que différentes personnes qui
travaillent sur le projet.
Phase 5 : Elaborer une analyse des composants du centre de données dédié à ce nouveau service
pour répondre à la question : pourquoi avoir choisi tels composants ?
Phase 6 : Passer du théorique à la pratique en installant quelques éléments de virtualisation
nécessaires à la mise en place de l’infrastructure du Cloud, et assister à une formation d’une demi-
journée pour toucher au concret l’administration de ces éléments.
Phase 7 : Etudier les différents outils qui vont permettre au client d’accéder à ses ressources.
Phase 8 : Regrouper le travail dans un schéma représentatif de l’infrastructure globale du Cloud.
Phase 9 : Décider des critères qui vont aider la CBI à mieux cerner les attentes des Clients
intéressés par ce nouveau service.
Dates de début et de fin du projet
Date de début : 15 Février 2012.
Date de fin espérée : 31 Mai 2012.
Date de fin prévue : 31 Mai 2012.
Nombre de jours : 210.
Comité de pilotage :
Superviseur de l’Ecole Hassania des Travaux Publics : M. Mohamed EL AROUSSI.
Parrains de stage : M. Wassil MERAD & M. Yassine MOUNIR.
Livrables :
- Présentations au niveau de la CBI devant la DG
- Rapport fin d’étude
- Différents emails avec nos encadrants
Après avoir mis le point sur le concept du Cloud Computing, aborder le concept de la virtualisation
s’avère nécessaire, vu qu’elle joue un rôle de catalyseur pour le Cloud Computing. Dans le chapitre
qui suit, nous allons nous focaliser sur les différentes techniques de la virtualisation, les avantages
de cette approche, ainsi qu’une étude comparative des différentes solutions de virtualisation.

Chapitre2 : Eléments
du Cloud

Ce chapitre traite des différents domaines et services de virtualisation, les offres de virtualisation et
de solutions Cloud les plus remarquables dans le marché IT, et enfin du choix à adopter pour la CBI
dans son projet de fourniture des services Cloud.
I. Présentation du concept de la virtualisation

À l’origine, le matériel informatique dont nous disposons actuellement a été conçu pour n’exécuter
qu’un seul système d’exploitation et qu’une seule application. La virtualisation dépasse ces limites
en permettant d’exécuter simultanément plusieurs systèmes d’exploitation et plusieurs applications
sur le même ordinateur, ce qui accroît l’utilisation et la flexibilité du matériel, entre autres c’est une
technologie dont peut bénéficier toute personne qui utilise un ordinateur, qu’il s’agisse des
professionnels de l’informatique, des entreprises, des organismes publics et même des particuliers.
Initialement orientée vers les serveurs, la virtualisation couvre désormais plusieurs domaines de
l’infrastructure informatique d’une entreprise.
La virtualisation se décompose concrètement en quatre domaines:
 La virtualisation d’applications ;
 La virtualisation de services réseau ;
 La virtualisation de stockage ;
 La virtualisation de serveurs.
1. Virtualisation des applications

La virtualisation des applications est une technologie logicielle qui permet d’améliorer la portabilité
et la compatibilité des applications en les isolants
du système d’exploitation sur lequel elles sont
exécutées. Elle consiste à encapsuler
l’application et son contexte d’exécution système
dans un environnement cloisonné. La
virtualisation d’application va nécessiter l’ajout
d’une couche logicielle supplémentaire entre un
programme donné et le système d’exploitation ;
son but est d’intercepter toutes les opérations
d’accès ou de médication de fichiers ou de la
base de registre afin de les rediriger de manière Figure 8: Virtualisation des applications
totalement transparente vers une localisation
virtuelle (généralement un fichier). Puisque cette opération est transparente, l’application n’a pas
notion de son état virtuel. Le terme virtualisation d’application est trompeur puisqu’il ne s’agit pas
de virtualiser l’application mais plutôt le contexte au sein duquel elle s’exécute (registres du
processeur, système de fichiers,...).
La virtualisation des applications a de nombreux avantages : elle permet d’exécuter des applications
qui ont été développées pour d’autres environnements d’exécution, protège le système
d’exploitation hôte en s’assurant que l’application virtualisée ne viendra pas intéragir avec les

fichiers de configuration du système, évite de faire appel à une machine virtuelle qui consomme
plus de ressources.
2. Virtualisation des services réseau

La virtualisation des services réseaux consiste à partager une méme infrastructure physique au profit
de plusieurs réseaux virtuels isolées.
Figure 9: Virtualisation de services réseau
Un VLAN ( Virtual Local Area Network) est un réseau local regroupant un ensemble de machines
de façon logique et non physique. Puisqu’un VLAN est une entité logique, sa création et sa
configuration sont réalisées de maniére logicielle et non matérielle.
On distingue plusieurs types de reseaux virtuels :
 Les réseaux virtuels de niveau 1, appelés réseaux virtuels basés sur ports (port-based
VLAN): définissent un réseau virtuel en fonction des ports de raccordement sur le
commutateur. Ainsi, chaque port du commutateur est associé à un réseau virtuel,
indépendamment de la machine y étant physiquement raccordée. Le principal inconvénient
d’un VLAN de niveau 1 est sa rigidité : si une station se raccorde physiquement au réseau
par l’intermédiaire d’un autre port du commutateur, alors il est nécessaire de reconfigurer ce
commutateur afin de réintégrer la station dans le bon réseau virtuel ;
 Les réseaux virtuels de niveau 2, appelés réseaux virtuels basés sur adresses MAC ( MAC
address-based VLAN): consistent à définir un réseau virtuel sur la base des adresses MAC
des stations. Une adresse MAC est un identifiant unique implémentée dans chaque
adaptateur réseau. Ce type de VLAN est beaucoup plus souple que le précédent car il est
indépendant de la localisation de la machine ;
 Les réseaux virtuels de niveau 3. On distingue principalement deux types de VLAN de
niveau 3 ;
 Les réseaux virtuels basés sur adresse de sous-réseau (Network address-based
VLAN) : ils déterminent les réseaux virtuels sur base de l’adresse IP source des
segments. Ce type de reseau virtuel est très flexible puisque les commutateurs
adaptent automatiquement leur configuration lorsqu’une station est deplacée. En
revanche, une légère dégradation des performances peut se faire resentir puisque les
segments doivent être analysés plus minutieusement.
 Les reseaux virtuels basés sur protocole ( Protocol-based VLAN). Dans ce cas, les
réseaux virtuels sont créés sur la base des protocoles utilisées (TCP/IP, IPX,...) et les
stations sont regroupées en réseaux virtuels suivant le protocole qu’elles utilisent.
Les réseaux virtuels offrent plusieurs avantages, tels que la réduction du trafic de diffusion
(broadcast) puisque celui-ci est à présent contenu au sein de chaque réseau virtuel, une sécurité
accrue puisque l’information est encapsulée dans une couche supplémentaire, une meilleure
flexibilité puisqu’une modification de la structure des réseaux peut étre réalisée en modifiant la
configuration du commutateur.
3. Virtualisation du stockage
La virtualisation de stockage est un procédé qui va séparer la représentation logique et la réalité
physique de l’espace de stockage. Son but
est de faire abstraction des périphériques de
stockage utilisés et des interfaces qui leur
sont associées (SATA, SCSI,...) afin de
limiter l’impact des modifications
structurelles de l’architecture de stockage.
Ce type de virtualisation fait appel à une

application d’administration de volumes
logiques (Logical Volume Manager, LVM).
Il s’agit d’une couche logicielle qui va
permettre de regrouper dans un seul espace Figure 10: Virtualisation du stockage
plusieurs espaces de stockage, appelés
volumes physiques, pour ensuite découper
cet espace global suivant la demande en partitions virtuelles appelées volumes logiques. Ce
processus de virtualisation peut être vu comme une extension du modèle de partitionnement
classique des disques durs. La virtualisation de stockage permet :
 d’adjoindre un périphérique de stockage supplémentaire avec transparence à l’utilisateur;

 de regrouper des unités de disques durs de différentes vitesses, de différentes tailles et de
différents constructeurs ;
 de réallouer dynamiquement de l’espace de stockage. Ainsi, un serveur nécessitant un
espace de stockage supplémentaire pourra rechercher des ressources non allouées sur le
disque logique. Inversement, un serveur nécessitant moins d’espace de stockage pourra
libérer cet espace et le rendre disponible pour d’autres serveurs.

4. Virtualisation des serveurs
La virtualisation des serveurs consiste à masquer les ressources du serveur, c’est-à-dire le nombre
et les caractéristiques de chaque machine physique, de chaque processeur et
de chaque système d’exploitation pour les utilisateurs de ce serveur.
L’administrateur du serveur va utiliser un logiciel grâce auquel il va diviser
un serveur physique (constitué ou non de plusieurs machines distinctes) en
plusieurs environnements virtuels isolés les uns des autres.
La virtualisation des serveurs s’inscrit dans une tendance globale qui tend à
promouvoir la virtualisation au sein des entreprises en faisant notamment
appel à la virtualisation de stockage et à la virtualisation de réseau des
services réseau. Cette tendance est une composante dans le développement
de systèmes autonomes. Un système est dit autonome s’il est capable de
Figure 11: s’auto-gérer sur la base de l’activité qu’il perçoit, sans aucune intervention
Virtualisation des
externe, et en conservant les détails de son implémentation invisibles pour
serveurs
l’utilisateur.
La suite de ce chapitre cocerne plus particulièrement la virtualisation des serveurs.
Notion d’hyperviseur
Un hyperviseur est une fine couche logicielle située entre la couche matérielle d'une machine
physique et les machines virtuelles s’exécutant sur cette machine. C’est une plate-forme de
virtualisation permettant de fournir aux machines virtuelles de meilleures performances grâce à la
communication directe avec les ressources matérielles de la machine. Ainsi, chaque machine
virtuelle se verra allouer une quantité de disque dur, de mémoire ou encore de processeur logique en
fonction des ressources matérielles présentes sur la machine physique l’hébérgeant.
Par ailleurs, il est important de savoir qu'il existe 2 types d'hyperviseur, appelés plus communément
hyperviseur de type 1 (natif) et hyperviseur de type 2 (logiciel).
 Hyperviseurs de type 1 (Bare metal) :
Ce sont des logiciels s'installant et s'exécutant

directement sur la couche matérielle d'une machine
physique. L'interaction est donc immédiate,
garantissant ainsi de meilleures performances système
pour les machines virtuelles. De par son exécution
directe avec les ressources matérielles, l'hyperviseur de
type 1 est comparé à un noyau sur lequel il est alors Figure 12: Hyperviseur de type 1
possible d'installer un "autre" système d'exploitation.

 Hyperviseurs de type 2 :
Ce sont des logiciels s'installant et s'exécutant à

l'intérieur d'un système d'exploitation hôte.
Figure 13: Hyperviseur de type 2
La virtualisation des serveurs présente les avantages suivants :

 Une optimisation de l’infrastructure : la virtualisation permet de d’optimiser la charge de
travail des serveurs physiques
 Une réduction de l’infrastructure physique et des économies d’énergies : la virtualisation
permet de réduire le nombre de matériel informatique, Par conséquent, les entreprises font
des economies en terme d’espace mais aussi en terme de frais de ventilation et
d’alimentation.
 Une reprise automatique lors des incidents : La virtualisation permet d’améliorer la
prevention et la gestion des pannes ainsi que le plan de reprise de l’activité du systéme.
 Une optimisation de la securité des données : par la centralisation des ressources
applicatives au sein du centre de données, la virtualisation contribue à sécuriser l’accès et
l’usage des données de l’entreprise.
 Une facilité de migration : la virtualisation apporte la possiblité de migrer facilement un
environnement virtuel d’une machine physique vers une autre, facilitant ainsi la mise à jour
du centre de données ou le remplacement de matériel défectueux.
 Flexibilité et compatibilité : la virtualisation supprime toute dépendance entre une
application donnée et l’aspect matériel de la machine sur laquelle elle est exécutée.
 Un cloisonnement : le développement d’une application s’accompagne nécessairement de
phases de tests au cours desquelles le programmeur s’assure du bon fonctionnement et de
la stabilité de son logiciel. Néanmoins, il est parfois risqué d’exécuter une application
lorsque l’on n’est pas certain du résultat qui sera produit. Pour réduire les risques liés à des
applications peu fiables, la virtualisation peut étre utilisée pour créer des environnements
isolés et sécurisés qui vont servir de plateformes d’essai.
II. Virtualisation et Cloud Computing :

Le Cloud Computing est une technique qui est en passe de devenir un business. A l'image de la
puissance électrique il y a un siècle, la puissance de calcul et de stockage de l'information serait
proposée à la consommation par des compagnies spécialisées. De ce fait, les entreprises n'auraient
plus besoin de ressources propres, mais iraient les chercher chez une entreprise qui les leur
garantirait à la demande.
Ainsi, la virtualisation est considérée comme l’étape technique vers le concept du Cloud
Computing, en utilisant la technologie de l’hyperviseur qui permet de virtualiser les serveurs et

d’exécuter les applications dans des machines virtuelles en quelques minutes. Et c'est dans cette
optique que plusieurs entreprises qui travaillent sur la virtualisation des ressources se sont
mobilisées pour promouvoir leur image de marque en créant toujours de la nouveauté afin de mener
la migration vers cette nouvelle technologie à bon port.
1. Les différentes offres de virtualisation :
1.1. Vue d’ensemble

Gartner est une entreprise américaine de conseil et de recherche dans le domaine des techniques
avancées, et qui depuis 2010, fait des études pour déceler les entreprises les plus dominantes dans le
domaine de la virtualisation. La figure ci-dessous représente une analyse de Gartner faite en juin
2011, cette analyse permet de positionner une entreprise et son produit face à ses concurrents.
Figure 14: Cartographie basée sur une analyse de Gartner en juin 2011
Il est facile de remarquer que trois entreprises sortent du lot : VMware, Microsoft et Citrix Systems.
1.2. Vue détaillée

i. VMware
Présentation : VMware est une société informatique américaine fondée en 1998. Filiale d'EMC
Corporation depuis 2004, elle est considérée leader mondial dans le secteur de la virtualisation et
des infrastructures de Cloud. Les solutions de VMware sont pensées pour toutes les tailles
d’entreprises.
Solution Cloud de VMware : La solution Cloud VMware est basée sur la plateforme
d’hyperviseur vSphere. Dans le modèle de Cloud VMware, les clients créent des machines
virtuelles sur l’hyperviseur ESXi, ce machines incluent un système d'exploitation et une ou
plusieurs applications, et sont exécutées sur des serveurs VMware vCenter hébergés sur le
Datacenter du fournisseur Cloud.

VMware fournit par ailleurs un marché d'applications offrant des machines virtuelles
préconfigurées pouvant être téléchargées et utilisées sur une solution de Cloud Computing basée sur
VMware.
De nombreux éléments entrent dans la composition de la solution de Cloud Computing VMware,
nous citons dans ce sens :
 VMware vCompute : utilise l'hyperviseur ESXi pour virtualiser des ressources serveur et
regrouper ces ressources dans des pools logiques.
 VMware vStorage : extrait des ressources de stockage dans le matériel sous-jacent.
 VMware vNetwork : fournit des services de réseau pour les machines virtuelles en cloud.
 VMware vMotion : permet la migration de machines virtuelles en temps réel d'un hôte ESX
vers un autre.
 VMware Storage VMotion : permet la migration du stockage d'un emplacement vers un autre.
 VMware High Availability : utilisé pour surveiller les machines virtuelles et les redémarrer sur
un autre hôte si une défaillance est détectée.
 VMware Fault Tolerance: fournit une fonction de basculement sans temps d'arrêt pour les
machines virtuelles.
 VMware Data Recovery : crée des sauvegardes sur disque des machines virtuelles VMware.
 VMware vShield Zones : permet de surveiller, consigner et bloquer le trafic entre des machines
virtuelles.
 VMware VMSafe : une API par l'intermédiaire de laquelle des partenaires VMware peuvent
connecter un logiciel de sécurité au niveau de l'hyperviseur.
 VMware vCenter Orchestrator : permet de créer des flux de travail qui automatisent les tâches
opérationnelles.
 VMware vCenter Chargeback : est utilisé pour le suivi d'imputation des services de Cloud
Computing.
ii. Microsoft:
Présentation : Microsoft Corporation est une multinationale informatique américaine, fondée par
Bill Gates et Paul Allen. Son activité principale consiste à développer et vendre des systèmes
d’exploitation et des logiciels, elle offre en plus un ensemble complet de technologies pour la
création, le provisionnement, la gestion et la sécurité des environnements virtuels et physiques.
Microsoft dispose de toute une série d’applications pour l’expansion future du Cloud privé et
public, destinées tant aux consommateurs individuels qu’aux organisations de toutes tailles.
Solution Cloud de Microsoft : La solution de Microsoft concernant le modèle IaaS du Cloud

Computing est l’Hyper-V, c’est un module de virtualisation qui fournit une infrastructure logicielle
et des outils de gestion de base qui peuvent être utilisés pour créer et gérer un environnement
informatique virtualisé.

Hyper-V Cloud n’est pas un nouveau produit mais un ensemble d’outils, de concepts d’architecture,
de guides, de bonnes pratiques, permettant de transformer l’infrastructure traditionnelle en
infrastructure de services (IaaS) / Cloud privé. Pour cela, il s’appuie sur Windows Server 2008 R2,
Hyper-V et System Center. Hyper-V permet de créer un environnement informatique de serveurs
virtualisés à l’aide d’une technologie intégrée à Windows Server 2008 et Windows Server 2008 R2.
Ce type d’environnement est utile pour la création et la gestion d’ordinateurs virtuels, ce qui permet
d’exécuter plusieurs systèmes d’exploitation sur une même machine physique et de les isoler les uns
des autres.
iii. Citrix
Présentation : Citrix Systems est une entreprise multinationale américaine qui propose différentes
technologies de virtualisation, hébergées en mode SaaS, et des technologies Computing à plus de
230 000 entreprises dans le monde.
Citrix propose des solutions dynamiques de virtualisation et de Cloud Computing pour Clouds
privés, personnels et publics.
Solution Cloud de Citrix Systems : La solution de Citrix Systems concernant le modèle IaaS du
Cloud Computing est Xen. C’est un projet de virtualisation par hyperviseur géré par la société
XenSource. Le projet était à l’origine mené au sein de l’Université de Cambridge, sous le nom de
XenServer. Le but était d’héberger 100 systèmes invités sur une seule machine physique, avec les
meilleures performances possibles.
En 2003, les initiateurs du projet ont fondé la société XenSource et ont lancé le projet Xen en se
basant sur le code source de XenServer. Le rachat en août 2007 de la société XenSource par Citrix
n’a rien changé pour la communauté, la licence du produit libre restant inchangée. Toutefois, les
entreprises pourront être rassurées de voir que XenSource est maintenant soutenue par des moyens
financiers importants.
Citrix XenServer est une plate-forme de virtualisation 64 bits native offrant l'extensibilité exigée par
Microsoft Exchange Server, Microsoft SQL Server ou d'autres applications parmi les plus
stratégiques. Des interfaces en ligne de commande et de programmation ouvertes permettent en
outre l'intégration de XenServer aux processus et outils de gestion existants.
1.3. Etude comparative des offres
Plusieurs critères entrent en jeu pour effectuer cette étude :
i. Installation
Dans le cas de VMware et XenServer, l’hyperviseur est de type 1, par contre dans le cas de l’Hyper-
V, l’hyperviseur est de type 2 ; Hyper-V doit être installé sur un serveur Windows Server 2008.
Ceci revient à estimer un temps d’installation plus lent que celui de VMware ou Citrix.

La figure qui suit illustre une comparaison entre les temps d’installation de VMware ESXi et de
Microsoft Hyper-V.
Temps
d’installation
Figure 15: Temps d'installation d'Hyper-V et d'ESXi
ii. Configuration de l’hôte
Voici un tableau récapitulatif des configurations possibles des machines hôtes :
ESXi 5 Hyper-V XenServer

Nombre 32 16
maximal de processeurs processeurs 32 processeurs
processeur logiques logiques logiques
Mémoire
maximale
supportée 1 To 2 To 128 Go
SAN MPIO   X
Tolérance de
panne réseau (Via CLI)
  
Support des
VLANs   
Support les
disques SCSI
pour les VMs   
Support des
disques SAS
Support des
disques
IDE/SATA pour
les VMs   
Support NAS   

pour les VMs
Support des
disques ISCSI
Support des
disques Fibre (Via CLI)
Channel pour les
VMs   
Tableau 1: Récapitulatif des options de configuration des trois solutions
iii. Stockage en réseau
Côté stockage Fibre Channel, les solutions sont très différentes. Hyper-V et VMware sont les
produits les plus prometteurs sur ce point. Ils permettent d’assurer la tolérance aux pannes et la
répartition de charge.
Seuls Hyper-V et VMware Infrastructure intègrent le support de TOE (TCP/IP Offload Engine) qui
est une technologie utilisée dans les interfaces réseau, permettant de décharger la gestion de la pile
TCP/IP à cette interface. Cette technologie est proposée comme manière de réduction de la charge
associée à la gestion des protocoles de stockage IP iSCSI ou NFS.
En environnement Fibre Channel, la technologie NPIV (N-Port ID Virtualization) offre une

désolidarisation de l’adressage physique du stockage SAN, et ceci en partageant un port physique
en plusieurs ports virtuels (WWPN). Il est à noter que sur cette technologie aussi, Citrix est bridé.
iv. Stockage des disques virtuels
VMware utilise son propre format de disques virtuels, le format VMDK. Citrix utilise le format
VHD de Microsoft. Les spécifications de ces deux formats de disques virtuels sont ouvertes au
public. Il est possible d’utiliser des disques virtuels mais aussi des disques physiques en accès direct
(Raw Device Mapping, Passthrough Disk, etc). En fonction des choix effectués, l’ensemble ou
quelques parties des fonctionnalités apportées à la virtualisation ne seront plus disponibles
(redimensionnement, snapshot, disque de démarrage de la VM, etc).
Il est possible de stocker des machines virtuelles sur des baies SAN mais aussi sur des NAS et
utiliser l’espace au travers de systèmes de fichiers réseau de type CIFS (Microsoft) ou NFS (Citrix
et VMware).
v. Haute disponibilité
Côté sécurisation, Microsoft et VMware proposent toutes les deux des possibilités de mise en
cluster. En cas de dysfonctionnement d’un des nœuds, les nœuds restants ré-instancient les serveurs
virtuels affectés.

Microsoft utilise les fonctionnalités Windows 2008 Failover Clustering. Celui-ci est relativement
complexe à mettre en œuvre et requiert surtout de modifier de manière significative la configuration
et le design de l’environnement virtuel.
Le cluster VMware HA profite de l’utilisation de son système de fichier VMFS qui permet à
plusieurs serveurs VMware d’accéder simultanément à une partition. Le cluster VMware est donc
particulièrement simple à gérer et à mettre en œuvre. Par contre, l’expérience a démontré qu’il
manque encore un peu de robustesse.
Chez Citrix, cette fonctionnalité n’a pas encore été développée.
vi. Déplacement des machines virtuelles à chaud

VMotion chez VMware et XenMotion chez Citrix permettent de résoudre un problème majeur de
virtualisation, qui est la migration des machines virtuelles d’un serveur physique vers un autre de
manière transparente à ces machines. Malheureusement, Microsoft Quick Migration ne permet pas
cette transparence, ce qui limite fortement son adoption dans les centres de données d’entreprises.
De son côté, VMware prend à nouveau de l’avance en offrant aujourd’hui la possibilité de déplacer
l’exécution de la machine virtuelle, aussi bien que son stockage (avec Storage VMotion).
vii. Adoption
De manière plus générale, on peut aussi comparer le degré de maturité de chacune de ces trois
solutions. Autant dire qu’il n’y a aujourd’hui aucun recul sur les produits Microsoft. VMware est
sans conteste la solution la plus aboutie, talonnée par Citrix. Cependant, Hyper-V semble bien
mieux construit que l’hyperviseur Xen
. Il ne manque guère qu’un système de fichiers partagé pour que Microsoft puisse agrémenter son
offre de fonctionnalités lui permettant de répondre à des problématiques d’un centre de données de
taille importante.
2. Choix d’une solution

Stratégiquement, Microsoft semble s’intéresser à fournir des produits de qualité pour la gestion de
l’environnement virtuel, en attendant de disposer d’un hyperviseur plus mature qui pourra
concurrencer les leaders actuels de ce marché.
De nos jours, la solution VMware fait l’unanimité de choix chez de nombreuses entreprises. Facilité
d’installation, sécurité des données, haute disponibilité, migration facile, sont toutes des
fonctionnalités qui poussent le client à léguer ses données à une entreprise réputée de confiance tel
que la CBI, et qui offre des solutions VMware. Certes, c’est l’une des solutions les plus chères sur
le marché, mais la CBI tire avantage de son statut de partenaire Gold de VMware, ce qui revient à
estimer un coût des solutions très inférieur au coût initial.
Après avoir établi un choix concernant la solution Cloud à adopter (VMware), nous allons détailler
cette solution en se positionnant du côté du fournisseur (CBI) pour voir les possibilités qu’elle offre
en matière de virtualisation du centre de données, de son dimensionnement et de sa préparation à
l’hébergement d’infrastructures à la demande.
Chapitre 3 :
Conception, réalisation
et gestion du Cloud

Dans ce chapitre nous allons présenter l’offre VMware pour la gestion virtualisée du centre de
données du point de vue fournisseur du Cloud (CBI), le stockage dans le Cloud, la sécurité du
Cloud, et enfin présenter la réalisation effectuée concernant la virtualisation d’un serveur.
I. VMware vSphere
VMware vSphere est la première plate-forme de virtualisation pour la solution Cloud Computing
de VMware. Elle utilise la puissance de la virtualisation pour transformer les centres de données en
infrastructures de Cloud Computing beaucoup plus simples. Cette solution permet aux équipes
informatiques de fournir de nouveaux services souples et fiables à partir de ressources internes et
externes, de façon sécurisée et quasiment sans risques.
1. Présentation
VMware vSphere est la plate-forme de virtualisation leader pour la création d’infrastructures de
Cloud. Elle permet aux utilisateurs d’exécuter leurs applications métiers stratégiques en toute
sécurité et de répondre plus rapidement aux
besoins de l’activité.
Cependant, Il existe deux versions de

vSphere : vSphere 4 et vSphere 5.
vSphere 5 comporte plus de fonctionnalité

que vSphere 4 pour la gestion des Tableau 2: Comparaison entre vSphere 4 et vSphere 5
ressources, des centres de données et du
stockage. En outre, il supporte des versions de machines virtuelles plus performantes.
2. Architecture de vSphere 5
Figure 16: Architecture de vSphere 5
A partir de cette figure, on distingue les composants suivants :

 Serveur hôte ESXi : C’est la plate-forme de virtualisation qui permet à plusieurs machines
virtuelles, ayant chacune un système d’exploitation différent, de travailler sur un même
serveur physique.
 vSphere Client : Est une application de gestion centralisée qui représente l’interface
nécessaire pour créer, administrer et surveiller les machines virtuelles et les hôtes ESXi.
Il peut se connecter directement sur un serveur ESXi ou sur un vCenter server.
 vSphere Web Access : Il s’agit l’interface web qui permet de réaliser des actions basiques
d'administration et de configuration sur les machines virtuelles en se connectant directement
sur le serveur ESXi5 ou sur vCenter Server au travers d'un simple navigateur Internet.
 vCenter Server : C’est la plate-forme qui permet de gérer l’environnement VMware
vSphere. Elle offre une gestion unifiée de l’ensemble des hôtes et des machines virtuelles
d’un centre de données à partir d’une même console, et permet aux administrateurs de
renforcer le contrôle et de simplifier les tâches courantes.
Figure 17: Architecture de vCenter Server
Cette plate-forme est indispensable dans la mesure où elle débloque les fonctionnalités de vSphere
5. Elle peut s’installer sur une machine virtuelle comme elle peut s’installer sur un serveur physique
à part.
Il est possible d’avoir plusieurs instances parallèles de vCenter Server, comme il est possible, en se
connectant à l’une de ces instances, de gérer tout le datacenter virtuel VMware.
Pour garantir une protection de vCenter Server contre les pannes potentielles, la famille VMware a
créé la gamme vCenter Server Heartbeat qui développe et étend la disponibilité pour vCenter Server
en répliquant, en continu, les informations sur un serveur de secours passif. Cela permet une
récupération rapide à l’aide d’un canal réseau masqué.
 vCenter Server Database : c’est la base de données pour l'infrastructure virtuelle. L’état de
chaque VM, hôte, utilisateur... figure dans la base de données de vCenter Server. Cette base
de données installée et configurée lors de l'installation de vCenter Server peut être locale ou
distante à vCenter Server.
 Datastore (banque de données) : est une représentation virtuelle des ressources physiques
du stockage du centre de données. Une banque de données peut contenir les fichiers des

machines virtuelles (disques, métadonnées, …) ou encore des images ISO de disques (pour
l’installation d’OS par exemple).
3. Composants de vSphere 5
Figure 18: Composants de vSphere 5
VSphere 5 est constitué d’un service d’infrastructure et d’un service d’application. Dans ce qui
suit, nous allons décrire le rôle et l’architecture de l’ESXi 5 ainsi que les fonctionnalités clés de
vSphere 5.
3.1. ESXi 5
ESXi est un hyperviseur de type 1. Les machines virtuelles sont vues par l’ESXi comme un
ensemble de fichiers contenus dans un dossier appelé VM Folder. Chaque VM Folder contient
plusieurs fichiers comme le fichier de configuration, le fichier de disque virtuel, le fichier de
paramètres NVRAM (Non Volatile RAM) et le fichier de log.
i. Architecture d’ESXi
Figure 19: Architecture d'ESXi
 VMKernel est le cœur d’ESXi 5. Il permet la gestion des ressources physiques. Ainsi, il a
pour rôle de s’assurer que les machines virtuelles ont accès aux ressources dont elles ont
besoin. Il est responsable de la création des commutateurs virtuels et l’établissement des
services réseau au sein de l’hôte.

 VMM (Virtual Machine Monitor) est un régulateur entre la machine virtuelle et le
VMKernel. Il détermine, selon les requêtes CPU reçues, si une instruction peut être exécutée
directement sur la couche physique ou si le VMKernel doit être utilisé afin de lancer cette
dernière dans un contexte de protection CPU particulier. Il assure aussi la corrélation entre
la mémoire physique et la mémoire virtuelle. Il y a un VMM par machine virtuelle, et à
l’intérieur de chaque processus, un thread par vCPU.
ii. Pré-requis d’installation
 CPU 64 bits basé sur l’architecture x86 ;

 Minimum de 2 Go de mémoire ;
 Une ou plusieurs cartes réseau 1 Gb/s ou 10 Gb/s,
 Contrôleur et adaptateurs: HBA SCSI, HBA Fibre Channel, CNA, carte RAID.
3.2. Fonctionnalités clés de vSphere 5
i. vMotion
VMotion est un mécanisme qui
permet une migration à chaud des
machines virtuelles d’un serveur
physique vers un autre.
Les fichiers de configuration et de

données des machines virtuelles sont
présents sur le stockage partagé
accessible depuis les hôtes ESXi. La Figure 20: VMware vMotion
magie de vMotion réside dans le fait
où tout le contexte de la machine virtuelle est migré vers le second hôte ESXi (RAM, CPU et
charge réseau). Cette migration reste invisible pour le client ; la machine virtuelle est migrée sans
coupure de service. Le VMKernel joue un rôle dans cette transparence puisqu’il est capable de faire
croire à la machine virtuelle qu’elle est toujours située sur le même serveur. Ainsi la mémoire de la
machine virtuelle est «snapshotée » sur l’hôte source et envoyée vers l’hôte de destination, et ainsi
de suite jusqu’à ce que la mémoire totale soit transférée.
L’utilisation la plus fréquente de VMotion reste la maintenance des serveurs.
Pré-requis d’installation
 Un espace de stockage centralisé (NAS, SAN) où se trouveront les fichiers des machines
virtuelles.
 Chaque serveur source et destination doit être configuré avec un VMKernel Port Group
dédié pour vMotion, avec au moins une carte réseau Gigabit Ethernet connectée.
 Une compatibilité entre les processeurs des serveurs ESXi. Dans le cas contraire il faut
activer EVC qui permet de masquer certaines différences pour apporter une plus grande
compatibilité entre les serveurs.

Storage vMotion
Ce mécanisme offre la possibilité de migrer les

fichiers d’une machine virtuelle d’une baie de
stockage vers une autre.
La migration sans perturbation de ces fichiers de

disques vers d’autres emplacements de stockage
permet de gérer les disques des machines virtuelles
de façon économique, en appliquant une stratégie
Figure 21: VMware Storage vMotion de stockage hiérarchisée, fondée sur des règles
d’utilisation et de priorité. Storage vMotion peut
s’avérer utile dans le cas de maintenance des baies de stockage.
 Les machines virtuelles doivent être désactivées pour faire migrer simultanément l’hôte et la
banque de donnée ;
 Il ne faut pas avoir de snapshots en cours ;
 Il faut s’assurer qu’il y’a assez d’espace sur la VMFS destination.
ii. Distributed Resource Scheduler (DRS)

DRS a pour rôle d’effectuer une répartition de charge
entre les différentes machines virtuelles lors de leur
création, et surveille en continu les ressources
disponibles sur ces machines virtuelles ; dans le cas
d’une surcharge dans un serveur physique, il donne la
main à vMotion pour assurer une migration des
machines virtuelles vers un autre serveur physique.
DRS peut travailler d’une manière automatique ou

bien sur la base de règles d’utilisation qui lui sont Figure 22: VMware DRS
fournies définissant des privilèges pour des machines
à faire migrer et interdisant celles qui ne peuvent pas être déplacées de leurs hôtes ou encore celles
qui ne peuvent pas coexister sur un même hôte.
iii. Distributed Power Management (DPM)

DPM met automatiquement hors tension les serveurs
inutilisés afin de réduire la consommation énergétique
globale.
Lorsque les machines virtuelles d’un cluster DRS ont

besoin de moins de ressources (la nuit ou le week-end,
par exemple), DPM consolide les charges de travail sur
un nombre réduit de serveurs et met les autres serveurs
hors tension pour réduire la consommation d’énergie.
Figure 23: VMware DPM
Inversement, lorsque les machines virtuelles ont besoin de plus de ressources (par exemple le matin,
lorsque les utilisateurs se connectent aux applications), DPM remet les hôtes en ligne pour garantir
le niveau de service requis.
iv. High Availability (HA)

Cette fonctionnalité surveille les serveurs, et en cas de
panne de l’un d’eux, prend en charge le redémarrage
des machines virtuelles dans d’autres serveurs
physiques.
HA travaille en collaboration avec DRS qui détermine

le serveur adéquat pour le placement des machines
virtuelles, et nécessite vCenter Server.
Figure 24: VMware High Availability
 Toutes les machines virtuelles et leurs fichiers doivent être stockés sur un disque partagé.
 Les serveurs physiques doivent avoir une IP fixe associée à chaque carte réseau.
 Les serveurs physiques doivent avoir accès au réseau virtuel des machines virtuelles.
v. Fault Tolerance (FT)

FT garantit la disponibilité continue des applications,
en cas de panne des serveurs physiques, sans perte de
données.
Il vaut mieux utiliser cette technologie seulement

pour des serveurs hébergeant des machines critiques,
ces serveurs devant être disponibles en continu et
dont une mise hors tension pourrait mener à une
Figure 25: VMware Fault Tolerance possible perte de données.
Tout ce qui se passe sur la machine virtuelle appelée primaire est copié en miroir dans une machine
virtuelle appelée secondaire grâce à la technologie vLockstep, qui permet de capturer tous les
évènements de la machine primaire active : jeu d’instructions CPU, état mémoire, E/S pour les
envoyer vers la machine secondaire passive sur un autre serveur physique.
L’accès à cette machine secondaire se fait en mode lecture et elle consommera en parallèle les
mêmes ressources que celles de la machine primaire. C’est pour cela que l’administrateur doit faire
attention lors de l’attribution des ressources s’il veut utiliser cette technologie.
 1 vCPU ;
 Disques VMDK en configuration eager-zeroed thick.

II. Mise en réseau dans le Cloud
Une fois les machines virtuelles créées, celles-ci doivent communiquer entre elles comme avec le
réseau extérieur (physique). Dans le cas traditionnel, cette communication est assurée via des
commutateurs qui supportent certaines fonctionnalités et protocoles, nécessaires pour : assurer la
qualité de service, garantir la sécurité des échanges, effectuer la surveillance du trafic réseau, et
pratiquer le dépannage des machines virtuelles. Dans le monde virtuel, ce sont des commutateurs
virtuels qui prennent la relève. Plus précisément, le Standard Switch et depuis la version 4 de
vSphere, le Distributed Switch.
1. Considérations préliminaires
 Comparaison basique entre vSphere Standard Switch et vSphere Distributed Switch
Les figures qui suivent représentent la différence conceptuelle dans la configuration entre le
Standard Switch et le Distributed Switch.
Figure 26: vSphere Standard Switch
Figure 27: vSphere Distributed Switch
Alors que Standard Switch (vSS) représente un commutateur Ethernet permettant la mise en réseau
des machines virtuelles au niveau de chaque hôte, vSphere Distributed Switch (vDS) fait office de
commutateur Ethernet unique sur tous les hôtes associés dans un centre de données. Aussi, chaque
vSS requiert-il une configuration séparée à partir d’un panneau de configuration séparé, tandis que

vDS requiert un seul panneau de configuration. Ceci permet à l’administrateur système de ramener
la mise en réseau des machines virtuelles à un niveau de cluster centralisé. Dans tout ce qui suit,
c’est à ce dernier que nous nous intéresserons.
 Services réseau vDS
Un réseau virtuel fournit plusieurs services différents à l'hôte et aux machines virtuelles. Un
vSphere Distributed Switch (vDS) a pour fonction d’assurer:
 La connexion des machines virtuelles au réseau physique et entre elles ;

 La connexion des services VMkernel de ESXi (tels que NFS, iSCSI ou vMotion) au réseau
physique.
 Configuration réseau vDS
Chaque port distribué de vDS peut être configuré pour se comporter de certaines manières, selon
les besoins de la machine à laquelle il est connecté.
La configuration des ports distribués se fait à travers ce qu’on appelle les dvPort Groups. Ceux-ci
définissent la manière dont une machine virtuelle est connectée au réseau via vDS. Chaque dvPort
Group est identifié par une étiquette réseau qui est unique dans le centre de données actuel.
 Connexion avec le réseau physique
La liaison entre vDS et le réseau physique extérieur est assurée par des adaptateurs Ethernet
physiques, leur représentation virtuelle est appelée vmnic dans le monde de VMware.
vDS offre un panneau de configuration réseau se basant sur plusieurs paramètres. Nous citons ici les
plus importants.
2. Paramètres de sécurité du réseau virtuel

 VLAN et VLAN privé
L’un des paramètres de sécurité que l’on peut configurer dans vDS est la définition de VLANs
(Virtual LANs). Un VLAN est un réseau logique permettant une séparation logique entre des
machines connectées à un même vDS. Les machines appartenant au même VLAN ne peuvent
communiquer qu’entre elles. IEEE 802.1q est le standard fournissant le mécanisme d’encapsulation
des trames permettant de créer des VLANs.
Il existe un autre type de réseau virtuel VLAN privé. Ce dernier permet de gérer les
communications entre ports distribués (machines) appartenant au même VLAN, tel qu’ils ne
peuvent communiquer qu’avec des ports distribués (machines) spécifiques. La figure ci-dessous
illustre les trois configurations de VLANs privés possibles :

Figure 28: Configuration de VLANs privés
 Changement d’adresse MAC
Quand il est activé, il permet aux machines de recevoir le trafic avec une adresse MAC différente de
celle configurée dans le fichier *.vmx. La possibilité de désactiver cette option, et donc de
« verrouiller » l’adresse MAC d’une machine dans la configuration du fichier *.vmx, permet de
prévenir le MAC Spoofing et donc l’ARP Poisoning, et procure un niveau de sécurité qui n’existe
pas dans un environnement physique.
 Transmission forgée
La transmission forgée est similaire au changement d’adresse MAC, sauf que ce paramètre
concerne le trafic sortant de la machine virtuelle. Ce paramètre aussi augmente la sécurité des
échanges traversant vDS.
 Association de cartes réseau
Assurant une sécurité matérielle, le NIC teaming a lieu quand deux ou plusieurs cartes réseau
physiques sont agrégées pour constituer une seule liaison logique. Cette technique permet d’:
 Equilibrer la charge du trafic traversant le vDS en le répartissant sur les vmnics de

l’association ;
 Assurer la tolérance aux pannes, grâce au basculement d’une vmnic défectueuse à une
autre.
3. Paramètres de surveillance du réseau virtuel

La surveillance du réseau, ou le monitoring, est une activité de surveillance et de mesure d'un
réseau informatique. Elle permet de mesurer les performances du réseau (en termes de temps de
réponse par exemple), sa disponibilité ou l’intégrité des flux (sécurité).

 Mode promiscuité
Dans le monde VMware vSphere, le mode promiscuité équivaut au Port Mirroring, qui permet à
une vNIC placée en mode Promiscuous de recevoir tout le trafic destiné aux autres VMs du même
VLAN.
 Support de la fonction SPAN et du protocole Netflow
Alors que la fonction SPAN (Switch Port ANalyser) de Cisco permet de recopier sur un port
distribué donné le trafic destiné à un ou plusieurs autres ports distribués, Netflow exporte les
informations du trafic réseau qui traverse le vDS à un collecteur Netflow spécifique (une machine
virtuelle). Les deux techniques permettent une analyse et une visualisation du trafic, facilitant ainsi
de dépannage des machines virtuelles.
 Support des protocoles LLDP et CDP
LLDP (Link Layer Discovery Protocol) est un protocole réseau de niveau 2 permettant au vDS la
découverte des topologies réseau de proche en proche, mais il apporte aussi des mécanismes
d'échanges d'informations entre équipements réseaux, et utilisateurs finaux. CDP (Cisco Discovery
Protocol) étant la « version » propriétaire de ce protocole, il offre les mêmes fonctionnalités.
4. Paramètres de QoS
La notion de qualité de service (QoS) introduit la possibilité de partager le plus équitablement
possible une ressource devenant de plus en plus rare, car partagée par un grand nombre de flux
applicatifs qui peuvent interférer les uns avec les autres. Elle introduit également la possibilité
d’introduire différents niveaux de service en fonction de la nature de ce flux (visioconférence, un
transfert de fichiers…etc).
 Contrôle d’E/S réseau
Cette fonction permet de

configurer des règles
spécifiant le niveau de
priorité de chaque machine
virtuelle. Lorsqu’une
congestion est détectée,
elle alloue de façon
dynamique les ressources
d’E/S disponibles aux
différents types de trafic
réseau en fonction des
règles prédéfinies de parts
de la carte réseau (et donc
de la bande passante) Figure 29: Contrôle d'E/S réseau
disponibles pour chaque pool de ressources réseau.

Pools de ressource réseau
Lorsque le contrôle d'E/S réseau est activé, le trafic du commutateur distribué est divisé dans les
pools de ressources réseau prédéfinis suivants : Trafic de tolérance aux pannes, trafic iSCSI, trafic
vMotion, trafic de gestion, trafic vSphere Replication (VR), trafic NFS et trafic de machine
virtuelle. L'affectation d'une balise de priorité QoS à un pool de ressources réseau applique une
balise 802.1p à tous les paquets sortants associés au pool de ressources réseau.
 Lissage de trafic
Le lissage de trafic est le contrôle du volume des échanges sur un réseau informatique dans le but
d’optimiser ou de garantir les performances, une latence plus basse ou d’augmenter la bande
passante utilisable, il est utile aussi dans le cas où on veut limiter le trafic sortant ou entrant à un
groupe de VMs pour les protéger dans un réseau surchargé. Il existe trois paramètres pour le
configurer: le débit garanti (average bandwidth), le débit crête (peak bandwidth) et la taille du burst
(burst size).
 Support de Network vMotion
Concept nouveau introduit avec vSphere 4, cette fonctionnalité permet de transférer la configuration
du port associé à une machine virtuelle pendant sa migration d’un hôte à l’autre, et de maintenir son
état réseau durant la migration. Ceci rend la surveillance et le dépannage d’une machine virtuelle
indépendants de son emplacement sur vDS. La figure qui suit est une illustration de cette
fonctionnalité :
Figure 30: Network vMotion

III. Stockage dans le Cloud
Le stockage est l'une des plus importantes caractéristiques de la technologie informatique. La mise
en place d'une solution de stockage informatique n'étant plus une option mais une obligation pour
l'entreprise, il faut par conséquent envisager des outils de gestion de l’espace de stockage
d’entreprise pour garantir la sécurité, la disponibilité et la commodité, aux utilisateurs finaux
comme aux administrateurs système.
La virtualisation du stockage permet d’extraire logiquement la couche physique du stockage pour la

dissimuler de la machine virtuelle pour flexibilité et confort d’utilisation.
1. Eléments du stockage :
1.1. Architecture du stockage virtualisé

Dans le cas physique, le stockage se passe de cette manière : un serveur accède à un périphérique de
stockage (qui peut être contenu
dans une baie de stockage).
Différentes connexions
physiques sont possibles entre
les deux équipements, utilisant
différents protocoles. Aussi
dispose-t-on de plusieurs
variétés de technologies de
stockage, qui incluent
plusieurs types de
périphériques.
Dans le monde virtuel, le

serveur est remplacé par une
machine virtuelle, laquelle
utilise un disque virtuel pour
stocker son système Figure 31: Architecture du stockage virtualisé
d'exploitation, les fichiers de
programmes et d'autres données liées à ses activités. Un disque virtuel est un grand fichier
physique, ou un ensemble de fichiers, qui peut être copié, déplacé, archivé et sauvegardé aussi
facilement que n'importe quel autre fichier. Une machine virtuelle peut être configurée avec
plusieurs disques virtuels.
A partir de la figure précédente, nous allons décortiquer l’architecture du stockage virtualisé :
Baie de stockage : c’est un équipement qui comporte principalement : un ensemble

de disques regroupés par tiroir disque, un ou plusieurs contrôleurs composés de ports de liaisons
avec les serveurs d'application, d'un bus ou d'une matrice de commutation (Switch ou Crossbar
commuté) interne d'échange, de mémoire cache, de CPU de traitement et d’une suite logicielle de
gérance des composants et de fonctionnels embarqués, comme la création de prises d’image

(snapshots), de miroir (ou clone) local ou distant (réplication). La suite logicielle est basée sur un
système d'exploitation embarqué (Windows, Linux ou propriétaire).
HBA (Host Bus Adapter) ou contrôleur hôte de bus : c’est une carte d’extension permettant de
connecter un hôte à un bus externe en réseau de stockage.
Banque de données (Datastore): c’est un conteneur logique qui virtualise le périphérique de

stockage (ou une partition de ce périphérique) auquel accède la machine virtuelle, tout en masquant
les informations physiques le concernant, fournissant ainsi à celle-ci un modèle uniforme pour
stocker des fichiers. Cette action permet d’exécuter des systèmes d’exploitation non certifiés pour
un équipement de stockage spécifique.
Une banque de données contient un ou plusieurs disques virtuels ainsi que les images .ISO
présentés comme CD-ROM à la machine virtuelle.
SCSI (Small Computer System Interface): est un standard définissant un bus informatique
permettant de relier un ordinateur à des périphériques de stockage.
Périphériques de stockage
Il existe deux principaux types de périphériques de stockage :
 HDD (Hard Drive Disk) : c’est un disque de stockage électromécanique qui utilise un
plateau rigide en rotation couvert d’une bande magnétique où sont stockées les données, et
d’une tête magnétique de lecture/écriture ;
 SSD (Solid State Drive) : c’est un disque de stockage qui utilise des circuits intégrés à base
de semi-conducteurs comme mémoire de stockage des données, et ne comporte pas de pièce
mobile. Par conséquent, un disque SSD est plus silencieux et plus résilient. Il présente moins
de temps d’accès et de latence par rapport à un disque HDD, permettant ainsi un débit E/S
très élevé.
Accès de la machine virtuelle au stockage avec ESXi :
Lorsqu'une machine virtuelle communique avec son disque virtuel stocké sur une banque de
données, elle lance des commandes SCSI. Quel que soit le type de périphérique de stockage utilisé
par l’hôte, le disque virtuel apparaît toujours en tant que périphérique SCSI monté pour la machine
virtuelle, qui s’y connecte via des contrôleurs SCSI virtuels tels que BusLogic Parallel, LSI Logic
Parallel, LSI Logic SAS, et VMware Paravirtual.
Étant donné que les banques de données peuvent résider sur plusieurs types de périphériques de
stockage physique, ces commandes sont encapsulées dans d'autres formes, selon la technologie de
stockage adoptée.
1.1. Types de stockage physique

Il existe deux scénarios pour le stockage dans un système d’information :

i. Stockage local :
L’hôte utilise des disques durs internes ou des systèmes de stockage externes qui lui sont connectés
directement via des protocoles comme SAS (Serial Attached SCSI) ou SATA (Serial Advanced
Technology Attachment).
Le stockage local ne requiert pas de réseau de stockage pour la communication entre l’hôte et le
disque dur. Celle-ci est assurée par l’intermédiaire d’un câble connectant les deux équipements et, si
nécessaire, d'un HBA compatible dans l’hôte.
Dans cet exemple de topologie de stockage local, l'hôte emploie une connexion unique à un disque.
Sur ce disque, on peut créer une banque de données qui peut être utilisée pour stocker les fichiers de
disque de la machine virtuelle.
Les périphériques de stockage local ne prennent pas en charge le partage sur plusieurs hôtes, et par
conséquent, les connexions multiples ne sont pas non plus prises en charge : une banque de données
sur un périphérique de stockage local peut être accédée seulement par un seul hôte. Toutefois ils
prennent en charge un cluster de machines virtuelles sur un seul hôte. Pour ceci, un disque virtuel
partagé est requis.
Bien que cette configuration de stockage soit possible, cette topologie n'est pas recommandée.
L'utilisation de connexions uniques entre des baies de stockage et des hôtes crée des points uniques
de défaillance (SPOF) pouvant causer des interruptions lorsqu'une connexion devient instable ou
échoue.
ii. Stockage en réseau
L’hôte utilise des médias de stockage sur une baie qui lui est connectée via un réseau haut débit
dédié (ou non) au stockage. Les périphériques de stockage en réseau sont partagés. Les banques de
données sur des périphériques de stockage en réseau sont accessibles par plusieurs hôtes
simultanément. Parmi les technologies de stockage en réseau, on retrouve :
 Fiber Channel (FC) : c’est un protocole permettant d’acheminer le trafic SCSI entre un
hôte et le système de stockage lui étant connecté via un SAN (Storage Area Network), qui
est un réseau haut débit (de l’ordre du Gigabit par seconde) dédié au stockage par bloc.
Pour se connecter au FC SAN, l’hôte doit être équipé d’un HBA Fibre Channel, et à moins d'utiliser
un stockage de connexion directe Fibre Channel, des commutateurs Fibre Channel sont nécessaires
pour acheminer le trafic de stockage. Si l’hôte contient des adaptateurs FCoE (Fibre Channel over
Ethernet), la connexion aux périphériques Fibre Channel partagés peut être effectuée à l'aide d'un
réseau Ethernet.
 iSCSI (internet SCSI) : c’est un protocole d’encapsulation de la couche application

permettant de transporter le trafic SCSI via un réseau TCP/IP standard.
ESXi offre les types de connexion iSCSI suivants :

Matérielle : L’hôte se connecte au stockage via un CNA (Converged Network Adapter)
qui est une carte d’interface combinant les fonctions d’un HBA et d’une carte réseau
Ethernet standard ;
Logicielle : L’hôte utilise un initiateur iSCSI logiciel dans le VMkernel pour se connecter au
système de stockage. Avec ce type de connexion iSCSI, l’hôte ne requiert qu'un adaptateur
réseau Ethernet standard pour la connectivité réseau.
NAS (Network Attached Storage) : c’est un ensemble de serveurs de stockage de fichiers

connectés au réseau IP d’entreprise, servant de volume centralisé et accessible pour des clients
réseau hétérogènes (utilisant les protocoles CIFS ou NFS).
ESXi intègre un client NFS qui utilise le protocole NFS v3 pour communiquer avec les serveurs
NAS/NFS. Pour la connectivité réseau, l’hôte requiert un adaptateur réseau Ethernet standard.
2. Utilisation d’ESXi avec un SAN
2.1. Avantages
L'utilisation d'ESXi avec un SAN signifie plus de souplesse, plus d'efficacité et plus de fiabilité.
Elle prend également en charge la gestion centralisée et les technologies de basculement et
d'équilibrage de charge. On retrouve parmi les avantages de ce choix :
 Le stockage des données se fait de manière sécurisée en configurant plusieurs chemins vers
le périphérique de stockage afin d'éliminer tout risque de SPOF, la gestion de multivoie se
fait à l’aide d’API de stockage du VMkernel ;
 La reprise d’activité après sinistre est assurée : toutes les applications peuvent être
immédiatement redémarrées dans leur dernier état sur un autre hôte suite à la panne de
l’hôte d’origine, grâce à l’utilisation de VMware High Availability ;
 L’équilibrage de charge entre hôtes peut être effectué à l’aide de VMware Storage
Distributed Resource Scheduler par la migration de machines virtuelles d’un hôte à l’autre
sans interruption de service avec VMware vMotion ;
 La tolérance aux pannes est possible à l’aide de VMware Fault Tolerance qui permet de
faire une copie de machine virtuelle sur un autre hôte, celle-ci continuant à fonctionner sur
le second hôte après défaillance du premier sans interruption de service ;
 Les opérations de maintenance ou de mise à niveau d’un hôte ESXi peuvent être réalisées
de manière transparente aux machines virtuelles en service, avec le cluster VMware DRS
qui permet de les migrer d’un hôte à l’autre ;
 La migration de baies et la mise à niveau de stockage sont simplifiées avec l’utilisation de
Storage vMotion, celui-ci permet d’effectuer la migration automatisée en direct des fichiers
de disque d’un emplacement de stockage à un nouveau avec transparence aux machines
virtuelles.
La portabilité et l’encapsulation des machines virtuelles VMware sont un complément à la nature

partagée de ce stockage. Avec les possibilités présentées ci-dessus, la migration des ressources
informatiques est possible tout en maintenant un accès partagé cohérent.

2.2. Prendre des décisions préalables au déploiement des machines virtuelles:
i. Décider concernant les LUNs

La configuration du stockage des systèmes ESXi doit être planifiée avant de formater les LUN avec
les banques de données VMFS ou NFS. Plusieurs critères doivent être envisagés lors de la prise de
décision de LUN :
 Chaque LUN doit avoir le bon niveau RAID et des caractéristiques de stockage correctes
pour les applications s'exécutant dans les machines virtuelles utilisant la LUN ;
 Chaque LUN ne doit contenir qu'une banque de données VMFS ;
 Si plusieurs machines virtuelles ont accès au même VMFS, les partages de disque peuvent
être utilisés pour classer les machines virtuelles par ordre de priorité.
Moins de LUNs mais de plus grandes tailles peuvent être préférées pour les raisons suivantes :
 Plus de souplesse de création des machines virtuelles sans avoir à demander plus d'espace de
stockage à l'administrateur ;
 Plus de souplesse de redimensionnement des disques virtuels ou de prise d’image
(snapshot) ;
 Moins de banques de données à gérer.
Par contre, plus de LUNs mais de plus petite taille peuvent être préférées pour les raisons
suivantes :
 Gain d’espace ;
 Différentes applications pourraient nécessiter des caractéristiques RAID différentes ;
 Plus de souplesse grâce à la définition de la règle de gestion de multivoie et des partages de
disque par LUN ;
 L'utilisation du service de cluster de Microsoft (Microsoft Cluster Service) exige que chaque
ressource de disque en cluster soit dans sa LUN respective ;
 Meilleures performances car un volume unique subit moins de contention.
ii. Choisir l’emplacement des machines virtuelles

Si l’on souhaite augmenter les performances des machines virtuelles, l’emplacement du stockage
est un facteur important. Il existe toujours un compromis entre un système de stockage onéreux qui
offre des performances élevées et une grande disponibilité et un stockage moins onéreux mais
offrant moins de performances. Toutes les applications ne doivent pas nécessairement offrir les
performances les plus élevées ou un stockage à la plus grande disponibilité, tout du moins pas tout
au long de leur cycle de vie.
Le stockage peut être divisé en plusieurs niveaux, selon un certain nombre de facteurs:
 Niveau élevé : Offre de hautes performances et une grande disponibilité. Peut offrir des
snapshots intégrés pour faciliter les sauvegardes et les restaurations instantanées. Prend en

charge la réplication, la redondance SP complète et les lecteurs SAS. Utilise des axes de prix
élevé ;
 Niveau intermédiaire : Offre des performances de milieu de gamme, une disponibilité plus
faible, quelques redondances SP et des lecteurs SCSI ou SAS. Peut proposer des snapshots.
Utilise des axes de prix moyen ;
 Niveau inférieur : Offre des performances faibles, peu de redondance de stockage interne.
Utilise des pilotes SCSI ou SATA bas de gamme (axes de série peu onéreux).
iii. Considérations sur la sauvegarde de stockage SAN

Une stratégie de sauvegarde appropriée est l'un des aspects les plus importants de la gestion d'un
SAN. Dans un environnement SAN, les sauvegardes ont deux objectifs. Le premier objectif est
d'archiver des données en ligne sur des supports hors ligne. Ce processus est répété régulièrement
pour toutes les données en ligne, selon un calendrier. Le second objectif est de fournir un accès aux
données hors ligne pour une restauration en cas de problème. Par exemple, la restauration de bases
de données nécessite souvent la récupération des fichiers de journalisation qui ne sont pas en ligne à
ce moment. La programmation des sauvegardes dépend de plusieurs facteurs :
 L'identification des applications critiques nécessitant des cycles de sauvegarde plus

rapprochés dans une période donnée ;
 Les points de restauration et les objectifs de période restaurée. La définition de la précision
nécessaire des points de restauration, et la durée d'attente permise est essentielle ;
 Le taux de changement (RoC : Rate of Change) associé aux données. Par exemple, si une
réplication synchrone/asynchrone a lieu, le RoC affecte la quantité de bande passante
requise entre les périphériques de stockage primaires et secondaires ;
 L'impact global sur l'environnement SAN, les performances de stockage (lors de
sauvegarde), et les autres applications ;
 L'identification des horaires de pointe sur le SAN (les sauvegardes prévues pendant ces
heures de pointe peuvent ralentir les applications et le processus de sauvegarde) ;
 Le temps passé à programmer toutes les sauvegardes dans le centre de données ;
 Le temps passé à sauvegarder une application spécifique ;
 La disponibilité des ressources pour l'archivage des données, typiquement des supports hors
ligne.
Un objectif de temps de restauration doit être inclus pour chaque application lors de la conception
de la stratégie de sauvegarde. C'est-à-dire que le temps et les ressources nécessaires pour effectuer
une sauvegarde doivent être envisagés. Par exemple, si une sauvegarde programmée stocke tant de
données que leur restauration cause un délai considérable, la programmation des sauvegardes doit
être réexaminée. Des sauvegardes plus fréquentes peuvent être effectuées, ce qui résulte en une
diminution de la quantité de données envoyées à la fois, ainsi que le délai de restauration.
Si une application particulière nécessite une restauration dans un délai précis, le processus de
sauvegarde devra fournir un horaire et un traitement des données convenant à ce délai. Une
restauration rapide peut exiger l'utilisation des volumes de sauvegarde dans le stockage en ligne afin

de minimiser ou supprimer le besoin d'un accès à des données hors ligne lentes pour des
composants de données manquantes.
3. Utilisation des banques de données dans l’environnement vSphere

A l’aide de vSphere Client, il est possible d’accéder aux différents types de périphériques de
stockage que l’hôte ESXi découvre, et y déployer des banques de données.
Selon le type de stockage utilisé, les banques de données peuvent être sauvegardées aux formats de
système de fichiers suivants :
 Système de fichiers de la machine virtuelle VMFS (Virtual Machine File System) ;

 Système de fichiers de réseau NFS (Network File System).
Après avoir créé des banques de données, il est possible de les organiser de différentes manières.
Par exemple, les regrouper dans des dossiers en fonction des pratiques professionnelles permet
d'affecter simultanément les mêmes autorisations et alarmes sur les banques de données d'un
groupe.
Il est également possible d’ajouter des banques de données à des clusters de banques de données
avec une interface de gestion partagée. Lorsque le cluster de banques de données est créé, il est
possible d’utiliser Storage DRS pour gérer les ressources de stockage.
3.1. Banque de données VMFS

Les banques de données déployées sur les périphériques de stockage par blocs utilisent le format
vSphere VMFS.
A l’aide de vSphere Client, il est possible de configurer une banque de données VMFS à l'avance
sur un périphérique de stockage par blocs que détecte l’hôte ESXi. Celle-ci peut être étendue pour
englober plusieurs extensions de stockage physique, y compris les LUNs du SAN et le stockage
local.
L’augmentation de la capacité d'une banque de données pendant que les machines virtuelles
fonctionnent sur la banque de données est possible. Ainsi, l'espace des banques de données VMFS
peut être augmenté si la machine virtuelle en a besoin.
i. Partage de banque de données VMFS entre plusieurs hôtes

En tant que système de fichiers en cluster, VMFS est conçu pour un
accès simultané depuis plusieurs machines physiques et met en
place les contrôles d'accès sur les fichiers des machines virtuelles.
Il est possible de connecter jusqu’à 128 hôtes ESXi.
L’utilisation d’une banque de données VMFS partagée entre

plusieurs hôtes offre plusieurs avantages (cf. Utilisation d’ESXi
avec un SAN).
Figure 32: Partage d'une banque de données VMFS entre plusieurs

hôtes
ii. Mise à jour des métadonnées VMFS
Une banque de données VMFS contient, entre autres, les fichiers, les répertoires et les liens
symboliques. La banque de données maintient également une vue cohérente de toutes les
informations de mappage pour ces objets. Ces informations de mappage sont appelées
métadonnées.
Les métadonnées sont mises à jour chaque fois que des opérations de gestion de banque de données
ou de machine virtuelles sont réalisées. Exemples de ces opérations:
o Création, agrandissement ou verrouillage d’un fichier de la machine virtuelle ;

o Modification des attributs d’un fichier ;
o Démarrage ou arrêt d’une machine virtuelle ;
o Création ou suppression d’une banque de données VMFS ;
o Développement d’une banque de données VMFS ;
o Création d’un modèle ;
o Déploiement d’une machine virtuelle à partir d’un modèle ;
o Migration d’une machine virtuelle avec vMotion.
Lorsque des modifications sont apportées aux métadonnées dans un environnement de stockage
partagé, VMFS utilise des mécanismes de verrouillage spéciaux pour protéger ses données et
empêcher plusieurs hôtes d'écrire simultanément sur les métadonnées.
iii. Mécanismes de verrouillage VMFS

VMFS prend en charge deux types de réservation :
Réservations SCSI : VMFS les utilise sur les périphériques de stockage non SSD. Lors de la
réalisation d'une opération nécessitant une protection des métadonnées, les réservations
SCSI verrouillent l'intégralité d'un périphérique de stockage. Une fois l'opération terminée,
VMFS libère le périphérique et les autres opérations peuvent se poursuivre. Ce verrouillage
étant exclusif, les réservations SCSI excessives d'un hôte peuvent provoquer une
dégradation de la performance des autres hôtes accédant au même VMFS ;
ATS (Atomic Test and Set) : Pour les périphériques de stockage SSD, VMFS utilise
l'algorithme ATS, également connu sous le nom de verrouillage par assistance matérielle.
Contrairement aux réservations SCSI, ATS prend en charge un verrouillage discret par
secteur de disque.
3.2. Banque de données NFS

ESXi peut accéder à un volume NFS dédié, situé sur un serveur NAS, monter le volume et l'utiliser
pour des besoins de stockage. L’utilisation des volumes NFS pour stocker et démarrer des machines
virtuelles est possible et s’effectue de la même manière que l’utilisation des banques de données
VMFS.
4. Provisionnement dynamique de stockage (Thin provisioning)

Le provisionnement dynamique est une méthode qui optimise l'utilisation du stockage en allouant
un espace de stockage de manière flexible, à la demande. Il s'oppose au modèle traditionnel, appelé

provisionnement statique, avec lequel une quantité importante d'espace de stockage est prévue à
l'avance en prévision des futurs besoins de stockage. Toutefois, l'espace pourrait rester inutilisé et
entraîner une sous-utilisation de la capacité de stockage.
Avec ESXi, il est possible d’utiliser deux modèles de provisionnement dynamique, au niveau de la
baie et au niveau du disque virtuel.
4.1. Provisionnement dynamique du disque virtuel
Lorsqu’une machine virtuelle est créée, une certaine quantité d'espace de stockage sur une banque
de données est allouée aux fichiers du disque virtuel. Par défaut, ESXi offre une méthode de
provisionnement classique d'espace de stockage pour les
machines virtuelles. Cette méthode permet d'estimer la
quantité de stockage dont la machine virtuelle aura besoin
pour tout son cycle de vie. Une quantité fixe d'espace de
stockage est ensuite allouée à son disque virtuel à
l'avance, par exemple, 40 Go, et tout l'espace est alloué au
disque virtuel. Un disque virtuel qui occupe
immédiatement tout l'espace alloué est appelé un disque
statique.
ESXi prend en charge le provisionnement dynamique

Figure 33: Provisionnement dynamique du
pour les disques virtuels. La fonctionnalité de disque virtuel
provisionnement dynamique au niveau du disque permet
de créer des disques virtuels dans un format dynamique. Pour un disque virtuel dynamique,
ESXi alloue tout l'espace requis pour les activités actuelles et futures du disque, par exemple 40 Go.
Toutefois, le disque dynamique alloue uniquement l'espace de stockage nécessaire aux opérations
initiales du disque. Dans cet exemple, le disque à provisionnement dynamique occupe uniquement
20 Go de stockage. Alors que le disque a besoin de plus d'espace, il peut s'étendre et occuper son
espace alloué de 40 Go.
Lorsque le disque virtuel est alloué dynamiquement, il démarre avec une petite taille et grandit au
fur et à mesure que de l'espace disque est nécessaire.
4.2. Provisionnement dynamique des baies et banques de données VMFS

ESXi prend en charge les LUNs à allocation dynamique, mais ne prend pas en charge
l’activation/désactivation de l’allocation dynamique d’un périphérique de stockage, cette fonction
est assurée par le système d’exploitation du système de stockage.
L’hôte ESXi peut effectuer les tâches suivantes en utilisant l'intégration à allocation dynamique :
 Surveiller l'utilisation de l'espace sur les LUNs à allocation dynamique pour éviter à
l’administrateur de manquer d'espace physique. Au fur et à mesure que la banque de
données se développe ou si Storage vMotion est utilisé pour migrer des machines virtuelles

vers une LUN à allocation dynamique, l'hôte communique avec la LUN et signale à
l’administrateur des violations de l'espace physique et les conditions de manque d'espace ;
 Informer la baie sur l'espace de la banque de données qui est libéré lorsque des fichiers sont
supprimés ou retirés par Storage vMotion. La baie peut alors réclamer les blocs d'espace
libérés.

IV. Sécurité du Cloud
L'inventaire des menaces et une analyse des risques sont préalables à tout projet afin de mieux
appréhender le contexte d'utilisation du système d'information mis en œuvre.
Ainsi, les risques liés à l'utilisation du Cloud Computing doivent être pris en considération
comparativement aux risques encourus par les environnements « traditionnels ». La sécurité est
souvent citée comme le frein principal à l’adoption des services Cloud. L’accès aux données
hébergées dans le Cloud doit présenter un haut niveau de sécurité en raison de leur sensibilité.
1. Sécurité physique
1.1. Risques encourus

La sécurité physique est un point crucial de la sécurité du Cloud ; le client n’ayant aucune idée de
l’endroit où sont stockées ses données, il revient au fournisseur du Cloud d’assurer la sécurité
physique de ses locaux. Le risque majeur que courent les centres de données du fournisseur est la
destruction des locaux. Tout comme les environnements traditionnels, le Cloud est exposé à ce
risque dû aux catastrophes naturelles ou aux accidents de travail.
1.2. Mesures envisageables

L'architecture Cloud doit garantir un accès au service avec une très haute disponibilité. La seule
défaillance d'un équipement matériel peut engendrer une dégradation ou une coupure du service
voire une perte des données. Pour limiter ce risque, il est nécessaire d’avoir recours à la redondance.
Une réplication des configurations entre les équipements peut faciliter la bonne prise en charge de
la redondance et ainsi augmenter la haute disponibilité du service. La mise en œuvre d'une
redondance différentielle avec une sélection d'équipements de natures différentes (ex : différents
constructeurs, composants d'origines différentes ...), permet de se protéger d’un problème survenu à
un équipement donné.
Par ailleurs, une architecture de secours doit exister, sur un site géographiquement éloigné, avec des
équipements redondants et permettant de réaliser un PCA (plan de continuité d'activité) sans
interruption de service.
2. Sécurité logique du Cloud
2.1. Risques encourus

 Malveillance dans l’utilisation
Les architectures de type Cloud sont gérées et exploitées par des personnes disposant de privilèges
élevés et qui sont donc à risque élevé. Des dommages peuvent être causés par ces spécialistes
techniques. Les risques d’accès non-autorisés aux données ou d’utilisation abusive sont présents.
Les dommages causés par les personnes privilégiées dans le Cloud - même s’ils sont rares -
s’avèrent plus dévastateurs que dans un environnement informatique classique.
 Usurpation
Les risques d’usurpation d’identité sont de deux natures :
 L’usurpation du service offert par l’architecture Cloud : il peut s’agir de services
similaires, voire identiques, offerts par d’autres offreurs ou en d’autres points du Cloud

pour d’autres clients. A l’extrême, le client peut se retrouver confronté à des
problématiques telles que celle du phishing (hameçonnage) ;
 L’usurpation d'identité d’utilisateurs ou de clients des services du Cloud : il peut
s’agir d’attaques liées au vol de l’identité d’utilisateurs de services suite à des déficiences
dans les mécanismes d’authentification. De faux clients utiliseraient de façon indue des
ressources, voire accèderaient aux données des clients légitimes.
Dans les deux cas, la faiblesse de l’identification et de l’authentification laisserait la porte ouverte à
ces attaques.
 Défectuosité au niveau des APIs
Les fournisseurs de services du Cloud proposent un ensemble d’APIs dont les clients se servent
pour gérer leurs infrastructures dans le Cloud. Ainsi, la sécurité et la disponibilité des services du
Cloud dépendent de la sécurité de ces APIs et de la qualité de l’intégration. Etant sensible aux virus,
aux vers et autres logiciels malveillants, toute API implique un risque potentiel menaçant la sécurité
du Cloud. Un dysfonctionnement au niveau de ces interfaces conduirait à une perte totale ou
partielle de service pour le client.
 Absence d’étanchéité dans un environnement multi locataires
Les fournisseurs de Cloud hébergent sur une même architecture des serveurs et des données de
clients différents. Ainsi, le système doit s’assurer qu’il n’y ait aucune interférence entre les
différents systèmes d’information hébergés. Il serait donc possible de modifier les données par des
personnes non autorisées ou pire encore, d’accéder à des données sensibles entre clients différents.
2.2. Mesures envisageables

Suite aux différents risques présentés ci-dessus, le fournisseur du Cloud se doit d’assurer les points
suivants :
 Sécurité des machines virtuelles
L’utilisation d’antivirus au niveau du fournisseur est indispensable pour se prémunir des logiciels
malveillants. Aussi, la mise en place d'équipements de filtrage (pare-feu, proxy, sondes IPS/IDS...)
est-elle nécessaire afin de contrôler la légitimité des requêtes entrantes, une protection contre les
attaques de types déni de service et de spoofing peut être atteinte.
La seconde famille de bonnes pratiques concerne la notion d’isolation : isolation des flux réseaux,
isolation des machines virtuelles par niveau de sécurité, affectation de quotas d’usage des
ressources par les machines virtuelles.
La segmentation réseau des machines virtuelles est une autre mesure pour parer aux risques liés à
la colocation dans le cas d’un Cloud Public. Les machines étant virtuelles, il est plus facile dans ce
contexte de générer des conflits d’adressage.
Pour être efficace et rentable, l’infrastructure du Cloud doit mettre en place les solutions évoquées
précédemment en tenant compte de la virtualisation.

3. Offres destinées à la sécurité du Cloud
3.1. Offre VMware & Cisco

La complicité entre ces deux entreprises a permis de proposer des produits visant le renforcement
de la sécurité au sein des centres de données virtuels ; entre autres Nexus1000v, ASA1000V et
VSG.
Sachant qu’en matière de sécurité, le niveau 2 représente le maillon le plus faible, il faut donc
veiller à bien le configurer. Le rôle de fournisseur des services sécurité réseau attendus d’un
commutateur physique Cisco est joué par Nexus1000V, commutateur virtuel intégré à
l’hyperviseur. (Pour plus de détails, voir Annexe B)
i. Architecture
Figure 34: Architecture du Nexus1000V
Au delà des fondations offertes par le Nexus1000V il est indispensable de pouvoir contrôler le trafic
circulant entre les machines virtuelles afin de créer des zones de sécurité ou tout simplement de
filtrer au sein d'une zone. C’est dans ce sens que Cisco a développé Virtual Security Gateway
(VSG), un élément de filtrage logiciel, reposant sur le Nexus1000V.
VSG permet d’assurer la sécurité intra zone, c’est-à-dire entre les différentes machines virtuelles. Il
offre la possibilité de :
 Définir des règles : non pas simplement basées sur les adresses IP et ports TCP mais
également sur des attributs des machines virtuelles (nom, type d'OS,… etc). Ainsi, on peut
par exemple positionner toutes les machines virtuelles dont le nom comprend « web » dans
une zone « serveurs web », et limiter leur communication avec une autre zone ;
 Segmenter l’’administration : grâce à l'outil d'administration VNMC (le logiciel
d'administration spécialement créé pour VSG), les équipes sécurité gardent la main sur la

définition des règles, tout en faisant le lien avec la configuration des interfaces réseau du
Nexus1000V et en ayant accès aux caractéristiques des machines virtuelles en provenance
de vCenter ;
 Accélérer le traitement du trafic via vPath : les paquets initiaux devant être filtrés par l’ASA
sont acheminés vers le VSG et le reste du flux passe directement au vPath qui l’achemine
vers le Nexus1000V pour l’envoyer vers la machine virtuelle concernée.
Pour ce qui est de la sécurité interzones, il est souhaitable d’avoir des fonctions de sécurité plus
évoluées, au niveau du filtrage applicatif par exemple. Ainsi, ASA1000V offre une solution de
sécurité plus évoluée que celle de VSG en reprenant les caractéristiques attendues d’un firewall
actuel, adapté aux environnements virtuels. ASA1000V peut être piloté avec le même outil
d’administration (VNMC) que VSG, ou depuis ADSM (l'interface graphique traditionnelle d'ASA).
3.2. Offre VMware : gamme VMware vShield

Afin de répondre aux exigences de sécurité du Cloud précitées, VMware a créé la gamme VMware
vShield qui contient les produits suivants :
i. VMware vShield Manager:

C’est l’interface de gestion de l’ensemble des produits VMware vShield, il s’installe comme une
machine virtuelle à l’aide de VSphere Client et il permet aux utilisateurs d’installer, de configurer et
de gérer les composants vShield. Il peut s’exécuter sur un hôte ESXi différent de celui qui contient
les autres modules (vShield App, vShield Edge).
ii. VMware vShield Edge:
Figure 35: Services vShield Edge
Fonctionnalités clés :
Pare-feu
 Pare-feu de périmètre qui a pour fonction principale d'imposer une limite aux utilisateurs
externes non approuvés.
 Pare-feu d’inspection dynamique, avec des règles de contrôle des connexions entrantes et
sortantes basées sur les paramètres suivants :

– Adresse IP : adresse IP source/cible ;
– Ports : port source/cible ;
– Protocole : type de protocole (TCP ou UDP).
Traduction d’adresse réseau (NAT)

 Traduction des adresses IP vers et depuis l’environnement virtualisé ;
 Dissimulation des adresses IP du Datacenter virtuel pour les sites suspects.
Protocole DHCP (Dynamic Host Configuration Protocol)

 Provisionnement automatique des adresses IP pour les machines virtuelles des
environnements vSphere ;
 Paramètres définis par l’administrateur (exemple: pools d’adresses, périodes de location,
adresses IP dédiées).
VPN site à site

 Communication sécurisée entre centres de données virtuels ;
 VPN IPsec avec prise en charge de l’authentification par certificat et clé partagée reposant
sur le protocole IKE (Internet Key Exchange).
Equilibrage de charge Web

 Équilibrage de la charge entrante pour l’ensemble du trafic, notamment Web (HTTP) ;
 Algorithme d’ordonnancement RR (« round-robin ») ;
 Prise en charge des sessions de rappel.
ii. VMware vShield Endpoint
Figure 36: Services vShield Endpoint

Fonctionnalités clés:
Transfert des activités de protection contre les virus et les programmes malveillants
 vShield Endpoint améliore les performances en utilisant le module vShield Endpoint ESXi
pour transférer les activités d’analyse antivirus vers une appliance virtuelle sécurisée au sein
de laquelle l’analyse antivirus est exécutée.
 L’API EPSEC (Endpoint Security) de vShield Endpoint gère la communication entre les
machines virtuelles et l’appliance virtuelle sécurisée, à l’aide d’un processus d’introspection
au niveau de la couche hyperviseur.
 La mise à jour du moteur antivirus et des fichiers de signatures s’effectue exclusivement au
niveau de l’appliance virtuelle sécurisée, mais les règles peuvent être appliquées à
l’ensemble des machines virtuelles d’un hôte vSphere.
Actions correctives
 vShield Endpoint met en application les règles antivirus qui déterminent si un fichier
malveillant doit être supprimé, mis en quarantaine ou autre.
 Un agent léger gère les actions correctives sur les fichiers au sein de la machine virtuelle.
iii. VMware vShield App
Figure 37: Services vShield App
Pare-feu
Le pare-feu de niveau hyperviseur permet d’appliquer le contrôle des connexions entrantes et

sortantes au niveau des cartes réseau virtuelles via une inspection de l’hyperviseur, avec prise en
charge des machines virtuelles à hébergements multiples.

Le pare-feu de couche 2 (également appelé « pare-feu transparent ») prévient de nombreux types
d’attaques, telles que la détection (« sniffing ») de mot de passe, la surveillance de trafic DHCP,
l’espionnage du protocole de résolution d’adresse (ARP) ou les attaques par empoisonnement.
Il fournit également une isolation complète du trafic SNMP.
Cette protection peut être appliquée en fonction du réseau, du port d’application, du type de
protocole (TCP ou UDP) ou du type d’application.
Elle évolue de façon dynamique lors de la migration des machines virtuelles.
Le pare-feu dynamique basé sur IP et la passerelle de couche applicative prennent en charge un

grand nombre de protocoles dont Oracle, Sun Remote Procedure Call (RPC), Microsoft RPC,
LDAP et SMTP. La passerelle améliore la sécurité en ouvrant des sessions (ports) uniquement
lorsque cela est nécessaire.
Surveillance du flux
Les administrateurs peuvent observer l’activité réseau entre les machines virtuelles afin de définir
des règles de pare-feu et de les affiner, de détecter les botnets et de sécuriser les processus métiers
grâce à des rapports détaillés sur le trafic applicatif (applications, sessions, octets).
Groupes de sécurité
Les administrateurs peuvent définir des regroupements opérationnels de machines virtuelles en

fonction de leurs cartes réseau virtuelles.
iv. VMware vShield Zones

vShield Zones permet de protéger le trafic entre les machines virtuelles par un pare-feu, avec
filtrage et regroupement des connexions par 5-uplet – adresses IP source, adresses IP de destination,
port source, port de destination et protocole. Suivant la façon dont les services sont virtualisés, cela
peut suffire pour les règles de sécurité n'exigeant pas un niveau élevé de granularité. Par exemple,
vShield Zones peut suffire à sécuriser les services de messagerie électronique et Web au sein du
Datacenter virtuel, en n'autorisant que certaines machines virtuelles à héberger des serveurs de
messagerie électronique et Web.
Pare-feu de niveau hyperviseur

 Contrôle des connexions entrantes/sortantes mis en œuvre au niveau des cartes réseau
virtuelles par le biais de l'inspection de l'hyperviseur, avec prise en charge des machines
virtuelles multi-connectées ;
 Mise en œuvre basée sur le réseau, le port des applications, le type de protocole (TCP, UDP)
ou le type d'application ;
 Protection dynamique lors de la migration des machines virtuelles ;

 Pare-feu dynamique basé sur IP et passerelle de couche applicative pour un grand nombre de
protocoles dont FTP, Oracle, Sun Remote Procedure Call (RPC) et Microsoft RPC.

V. Réalisations effectuées
Lors de la réalisation de notre projet de fin d’étude, nous avons été amenées à installer ESXi 5 sur le
serveur UCS B200 M2 cité dans la partie « étude de l’existant ». Par la suite nous avons créé une
machine virtuelle, installé le système d’exploitation sur cette machine, et enfin installé vCenter
Server. Aussi avons-nous eu droit à une formation à propos de la manipulation des composantes de
gestion du Cloud.
1. Manipulations effectuées :
Les étapes suivantes décrivent en détail la démarche suivie pour la réalisation:
 Etape 1 : Installation d’ESXi 5
Une fois nous insérons le CD contenant ESXi 5, nous devons choisir soit un démarrage sur le
disque dur, ou bien un démarrage à partir du CD d’ESXi 5. Dans notre cas, nous avons gravé ESXi
5 sur un CD et nous l’avons inséré dans le lecteur CD du serveur.
Chargement des fichiers d’installation d’ESXi 5

La page qui apparait par la suite incite l’utilisateur à visiter le site (cadré en rouge) qui contient le
guide de compatibilité pour voir si les ressources du serveur sont compatibles avec les pré-requis
de la version ESXi 5.
Vient par la suite l’étape de la licence « End User License Agreement (EULA) », soit nous somme
d’accord et dans ce cas nous devons presser F11, soit nous ne somme pas d’accord et nous devons
presser la touche ESC.

L’étape qui suit concerne le scanne des ressources du serveur physique.
Finalisation de l’installation d’ESXi 5
Après nous devons choisir un login et un mot de passe pour sécuriser l’accès à l’hôte.
 Etape 2 : Installation de vSphere Client
Pour pouvoir récupérer le fichier d’installation exécutable de vSphere Client, nous avons tapé
l’adresse IP du serveur ESXi 5 dans le browser.

Une fois vSphere Client installé sur l’ordinateur, nous avons inscrit l’adresse IP, le login et le mot
de passe correspondant au serveur physique.
Une fois connecté au serveur, nous visualisons ses différentes caractéristiques :

 Processeur :
Le serveur contient deux processeurs avec 6 cœurs chacun. Nous avons donc 12 vCPU, et puisque
la technologie Hyperthreading est activée, nous obtenons dans ce cas le double de la vCPU initiale,
ce qui donne 24 vCPU (processeurs logiques).
 Mémoire :
Le serveur possède 49084,7 Mo de RAM, et utilise 241,7 Mo jusqu’à présent, ce qui nous donne
une taille de la mémoire virtuelle qui est de : vRAM= 49084,7-241,7= 48843,0 Mo

 Espace de stockage :
Cette fenêtre montre qu’ESXi est installé sur le deuxième datastore, sachant qu’il y’en a quatre.
La capacité totale du stockage disponible pour ESXi est de 135.50 Go, et sachant qu’ESXi nécessite
un espace de 8.49 Go, nous trouvons un espace libre pour le stockage des machines virtuelles qui
est de 135.50-8.49= 127,01 Go.
 Adaptateurs de stockage :
Dans cette fenêtre, nous pouvons voir les différents HBA qui sont détectés par ESXi, ainsi que les
différentes informations les concernant.

 Mise en réseau :
Cette fenêtre donne une vision sur le commutateur virtuel (vSphere Standard Switch dans cet
exemple), les cartes réseau lui étant connectées (vmnic0), les groupes de port et les VLAN ID qui
leurs sont associés, les différents pools de ressources réseau créés et les configurations d’adresse IP
spécifiques au groupe de port du VMkernel.
 Adaptateurs réseau
Cette fenêtre montre que le serveur possède quatre cartes réseau, dont une seule est mappée au
commutateur standard.
 Etape 3 : Création d’une machine virtuelle
Nous avons créé une machine virtuelle avec un clic droit sur l’hôte ESXi 5.

 Choix de la configuration pour la machine virtuelle :
Configuration :
La configuration personnalisée permet de configurer la machine virtuelle selon les besoins

d’utilisation, contrairement à la configuration typique qui ne donne pas la main à l’administrateur
pour créer la machine virtuelle selon les besoins souhaités.
Nom et emplacement :
VM1 est le nom de notre machine virtuelle.

Stockage:
Cette fenêtre montre les paramètres de stockage de la machine virtuelle.
Version de machine virtuelle :
Nous avons choisis la version 8 de machine virtuelle, car nous travaillons avec ESXi 5.
Système d’exploitation client :

Le système d’exploitation qui va tourner sur notre machine est Windows Server 2008 R2 (64 bits)
CPU :
La première case correspond au nombre de processeur virtuelle, et la deuxième case au nombre de

noyaux par processeur virtuelle.

Mémoire
Normalement à ce stade, nous devons suivre les recommandations du client.
Carte réseau :

Contrôleur SCSI :
Stockage
Nous pouvons créer un disque virtuel, utiliser un disque existant ou bien ne pas créer de
disque.

Disque virtuel
Nous avons choisi d’allouer à VM1 une taille de 40 Go, et nous avons coché le provisionnement
dynamique puisqu’il est recommandé.
Dans la case « Emplacement » nous avons coché « Stocker avec la machine virtuelle », en effet une
machine virtuelle contient deux types de fichier, un fichier de configuration et un autre de disque
(VMDK), on peut les séparer ou les ressembler comme dans notre cas.
Fin de la création de la machine virtuelle
 Etape 4 : Installation du système d’exploitation sur la machine virtuelle
Dans cette étape nous avons chargé et placé l’image ISO de Windows Server 2008 R2 dans le
Datastore.
 Avec un clic droit nous accédons au datastore pour importer l’image de l’OS.

 Une fois le système d’exploitation importé, son installation commence automatiquement
quand nous démarrons VM1.
 Une fois l’installation terminée, nous devons saisir un mot de passe pour l’accès à VM1.

 Etape5 : Installation de vCenter Server
L’installation de vCenter Server se fait soit sur un serveur physique à part ou bien sur une machine
virtuelle, dans notre cas nous avons opté pour la deuxième solution.
De la même manière que pour le cas du système d’exploitation, nous importons l’image ISO de
vSphere 5 sur le Datastore qui contient notre VM1.
Une fois l’importation terminée, nous partons vers le poste de travail de VM1 pour commencer le
téléchargement de vCenter Server.

 Par la suite, nous devons saisir le nom de l’organisation ainsi que la clé de licence, dans le
cas ou nous laissons la case de la clé de license vide, ça sous entend qu’on va utiliser cette
version pour une durée de 60 jours.
 Concernant la base de données, nous avons deux choix : soit nous allons utiliser une base de
données qui existe déjà, ou bien installer Microsoft SQL Server 2008 Express, c’est une
version gratuite de SQL Server, qui supporte 5 ESXi au maximum.

 Par la suite apparait l’image qui montre le compte sur lequel vCenter Server va tourner.
 Nous retrouvons par la suite les répertoires d’installation

 Nous disposons de l’option Linked Mode, dans notre cas, nous installer un seul vCenter
Server
 Nous devons par la suite entrer les ports qui doivent être ouverts par le pare-feu.

 Sachant que vCenter Server tourne sur une machine virtuelle, il a donc besoin d’une certaine
mémoire virtuelle, notre rôle est donc de lui attribuer la taille d’inventaire et lui il va faire la
correspondance avec la mémoire virtuelle.

 Par la suite une image de prêt à installer le programme apparait, nous allons laisser la case
vide car on a moins de 2000 machines virtuelles.

 L’installation se lance automatiquement
 Etape 6: Installation de vSphere Client sur la machine virtuelle

Pour se connecter à vCenter Server il faut installer vSphere Client, on va suivre la même
étape que pour le vCenter Server et l’OS de la VM1 pour l’importation de l’image ISO.
L’accès à vCenter Server s’effectue en saisissant l’adresse IP de VM1, le login et le mot de

passe du système d’exploitation.

2. Formation à la CBI concernant les éléments du Cloud:
Pendant que nous étions à la CBI, nous avons assisté à une formation animée par notre encadrant SI
ainsi que d’autres gens travaillant sur ce projet à propos des éléments du Cloud et leur
fonctionnement. Ainsi, nous avons pu concrétiser nos acquis théoriques concernant ces éléments.
Tout d’abord, nous avons assisté à l’accès au datacenter dédié au Cloud, à travers vSphere Client.
La vue d’inventaire du datacenter a été effectuée à partir de vCenter Server.
L’inventaire contient plusieurs serveurs, à savoir les huit lames du Cisco UCS B200-M2 blade
servers.
Les machines virtuelles contenant les différents éléments du Cloud sont toutes regroupées dans une
lame dédiée. Au total, il y avait : une machine pour vCenter Server et vSphere Client, deux pour les
cellules vCloud Director, une pour vCenter Chargeback, une pour vShield Manager, une faisant
office de serveur LDAP et une dernière faisant office de serveur de base de données, nécessaire à
vCenter Server, vCloud Director, et vCenter Chargeback Server.
Ces machines ont accès à une banque de données pour le stockage des différents fichiers de
systèmes d’exploitation et de configuration.
Les machines virtuelles sont interconnectées via Distributed Switch auquel sont mappées les cartes
réseau du serveur, et où sont configurés les dvPort Groups connectées aux machines. Différents
pools de ressources réseau y étaient ajoutés, à savoir : Trafic FT, trafic iSCSI, trafic vMotion, trafic
de gestion, trafic vSphere Replication (VR), trafic NFS et trafic de machines virtuelles.
Ensuite, nous avons assisté à la migration d’une machine virtuelle d’un hôte à l’autre avec vMotion,
après configuration de DRS.
Enfin nous avons pu voir les différentes caractéristiques du système de stockage, à savoir l’espace
disponible dans la baie VNX5300, les adaptateurs de stockage, le type de stockage, les

configurations de stockage des machines virtuelles et le type de provisionnement configuré dans
ESXi5.
Après avoir abordé tous les aspects Cloud du point de vue fournisseur, il est maintenant temps de se
positionner au niveau du client. Le chapitre suivant traite la partie accès au Cloud suivants deux
volets :
 Volet télécom : ce volet traite des différentes possibilités de configuration et d’adoption du

réseau d’accès, premier tronçon que parcourt l’information depuis le client vers CBI (et
vice-versa)
 Volet VMware : ce volet expose la manière dont le client accède de manière effective à son
infrastructure Cloud, via un navigateur Web, et les différentes possibilités de gestion et de
contrôle qui lui sont offertes par VMware

Chapitre 4 : Accès au
Cloud

Ce chapitre traite de la partie accès des clients à leurs ressources hébergées dans le Cloud. Dans un
premier lieu nous allons exposer les différentes offres de réseau d’accès proposées par les
fournisseurs d’accès et les opérateurs télécoms ainsi que l’outil permettant au client d’accéder et de
gérer son centre de données à distance avec tous les avantages que présente la solution Cloud.
I. Réseau d’accès
Le principe du Cloud Computing repose sur un accès permanent aux ressources, aux plateformes de
programmation ou encore aux applications à distance, de manière sécurisée et confortable. Dans
cette optique, le client aura besoin d’un lien d’accès bien dimensionné et étudié.
La solution Cloud que compte fournir la CBI inclut deux choix :
 Fournir l’infrastructure Cloud sans intervenir dans le dimensionnement des liens d’accès des
clients ;
 Fournir l’infrastructure Cloud avec une étude, un dimensionnement et un conseil concernant
les liens d’accès des clients faisant appel à son expertise et son expérience dans ce domaine.
Le choix entre ces deux aspects dépendra uniquement du client et de son équipe DSI/Réseau.
Définition : Le réseau d’accès forme la partie qui relie l’équipement terminal de l’utilisateur et le
réseau de l’opérateur. Cette partie est parfois désignée par l’expression « derniers kilomètres du
réseau ». Dans notre cas, c’est le premier tronçon de réseau que doivent parcourir les flux échangés
entre les entreprises clientes de la CBI et leurs centres de données distants, hébergés chez celle-ci.
Dans un premier temps, nous allons exposer tous les types de réseaux d’accès existants, pour
ensuite choisir lequel sera approprié et éligible pour un environnement Cloud.
Multiples moyens permettent de réaliser un réseau d’accès. Le tableau suivant récapitule ces types :
Réseaux câblés Réseaux sans fil
Cuivre Fibre Satellite

Wi-Max,
xDSL FTTx Wi-Fi,
Laser
Tableau 3: Types de réseaux d'accès
1. Les réseaux câblés

i. La fibre optique
Une première solution pour mettre en place une boucle locale puissante consiste à recâbler
complètement le réseau de distribution en fibre optique. Cette technique, dite FITL (Fiber In-The-
Loop), donne naissance à plusieurs techniques en fonction de l’emplacement de l’extrémité de la
fibre optique. Ainsi nous trouvons plusieurs solutions disponibles à la portée du client : FTTx (Fiber
To The) le x peut désigner le point que peut atteindre la fibre, il représente entre autres Home
(maison), Curb (Trottoir), Terminal (prise de l’utilisateur, à côté de son terminal), Exchange ou
encore Building. Le prix de revient augmentant fortement avec la proximité de l’utilisateur, la

tendance a longtemps été de câbler en fibre optique jusqu’à des points de desserte répartis dans le
quartier et à choisir d’autres solutions moins onéreuses pour aller jusqu’à l’utilisateur. Le câblage
métallique étant capable de prendre en charge des débits de quelques mégabits par seconde sur les
derniers kilomètres avec l’aide de modems xDSL, détaillés plus loin dans ce chapitre, il est possible
de câbler en fibre optique jusqu’à un point situé à 5 km au plus de l’utilisateur.
La boucle locale optique se décline sous deux variantes : AON (Active Optical Network) et PON
(Passive Optical Network).
Le réseau optique passif (PON) :
Figure 38: Architecture PON
PON est un réseau points à multipoints car plusieurs lignes optiques d’abonnés se rejoignent au
niveau du splitter pour former une seule ligne qui va vers le backbone.
Du point de vue cœur de réseau, le premier équipement réseau d’un PON est l’OLT (Optical Line
Termination), qui procure au backbone des interfaces Ethernet de n x 1Gbps et n x 10 Gbps et des
interfaces PON à l’abonné, ensuite vient le « splitter », qui est une sorte de multi-miroirs qui
dirigent le signal optique vers l’abonné et vers l’OLT, sans courant électrique (d’où vient la
qualification de passif). Et enfin l’ONT (Optical Network Termination) ou l’ONU (Optical Network
Unit), qui reçoivent le signal optique et le convertit en signal électrique et vice-versa. L’ONU est
installé chez l’abonné alors que l’ONT est en dehors de son bâtiment.
Les types de PON utilisés sont EPON (Ethernet-PON), GPON (Gigabit-PON) ou encore GEPON
(Gigabit-Ethernet-PON). Le standard GPON peut procurer au maximum de 2,4Gbps pour une
portée maximale de 10 km.

Le réseau optique actif (AON):
Figure 39: Architecture AON
AON est un réseau Point à Point (P2P), car chaque abonné possède sa propre ligne de fibre optique
qui se termine au niveau d’un concentrateur optique AN (Access Node). L’AN peut être un
commutateur Ethernet ou un Edge Router du backbone. L’OLT peut aussi être remplacé par un
routeur, commutateur Ethernet ou encore un DSLAM (DSL Access Multiplexer).
Topologies réseau avec PON et AON

PON et AON peuvent être utilisées pour implémenter les architectures FTTx. Les deux figures qui
suivent montrent les différents choix dont disposent les opérateurs pour le déploiement d’une
boucle locale optique :

Figure 40: Topologies réseau avec PON
Figure 41: Topologies réseau avec AON
Malgré les similitudes apparentes entre les deux technologies, il existe des différences qui affectent
les opérations, les coûts et la valeur qu’elles apportent aux clients et aux opérateurs. Puisque les
technologies AON et PON sont répandues, et que la migration de l’une vers l’autre peut s’avérer
très coûteuse, les opérateurs doivent être conscients des différents faits qui les caractérisent.
ii. Les paires cuivrées :
Les paires cuivrées sont le support physique le plus ancien et encore le plus utilisé en raison de ses
avantages de coût et de souplesse, même si les supports hertziens et en fibre optique se développent
énormément. Les sections qui suivent se penchent sur la boucle locale cuivrée; les accès xDSL et
les lignes louées.
Les accès xDSL :
Les lignes métalliques ont été utilisées pendant des décennies pour le transport de la parole
téléphonique avec une bande passante de 3200 Hz. On les utilise aujourd’hui pour transporter, en

même temps que le téléphone, des paquets de données à haut débit. En effet, Le haut débit à l’accès
est devenu une nécessité dans le monde actuel, où la quantité et la qualité des informations à
transporter augmentent sans discontinuer. Un débit de l’ordre de plusieurs mégabits par seconde
semble être une valeur minimale pour réaliser de tels accès, c’est pour cela qu’ils sont destinés
aujourd’hui aux PME.
Le sigle DSL (Data Subscriber Line) indique une ligne d’abonné pour les données. Le x devant
DSL précise le type de modem. Il existe différentes variantes : ADSL, SDSL, HDSL, RADSL ou
encore VDSL.
Celles-ci sont différenciées par la vitesse de transmission, distance maximale entre l'utilisateur et le
point d'accès de l’opérateur (POP), variation de débit entre le flux montant (uplink) et le flux
descendant (downlink).
L'idée de départ est de découper une gamme de fréquence en canaux. Chaque canal correspond à
une fréquence distincte. L'émetteur/récepteur utilise le FDM (Frequency Division Multiplexing)
pour envoyer et réceptionner les données sur les différents canaux. Une zone de fréquence est
dédiée à l'envoi et l'autre à la réception. Dans les technologies les plus courantes, la bande passante
est divisée en 3 zones: une pour la transmission de la voix (les basses fréquences jusque 4Khz), et
deux zones pour la transmission et l'émission. La figure qui suit illustre la division du spectre de
fréquences dans le cas de l’ADSL, mais le principe est le même pour toutes les connexions DSL.
Figure 42: Division du spectre dans l'ADSL
Famille xDSL : Les technologies xDSL sont divisées en deux familles, celles utilisant
une transmission symétrique et celle utilisant une connexion asymétrique.
 Solutions symétriques :
Une solution xDSL symétrique a la même vitesse de transfert en download qu'en upload. Ceci est
primordial pour les applications P2P comme la visioconférence ou la VoIP. Les connexions
symétriques sont surtout utilisées pour remplacer les lignes louées trop chères. Il en existe plusieurs
variantes : HDSL (High data rate DSL), HDSL2, SDSL (Symmetric DSL) ou encore SHDSL

(Single-pair High Speed DSL). Ces solutions diffèrent au niveau du débit et de la portée, mais ne
permettent pas l'utilisation simultanée de la connexion Internet avec un appel téléphonique.
 Solutions asymétriques:
La vitesse de transfert en download dans une solution xDSL symétrique est nettement plus élevée
qu'en upload. Ce type de connexion n’est pas recommandé lors de l’hébergement d’un site au sein
de l’entreprise. Parmi ces solutions on trouve ADSL (Asymmetric DSL), ADSL2, ADSL2+,
RADSL (Rate Adaptative DSL), ReADSL (Reach Extended ADSL), différenciées par le débit et
le type de modulation. Par ailleurs celles-ci permettent l’utilisation simultanée de l’Internet et du
téléphone.
 Solutions hybrides VDSL (Very high data DSL) et VDSL2:
Ces technologies peuvent travailler en mode asymétrique ou symétrique (jusque 34Mbps à une
distance maximale de 300 mètres). Dans le mode asymétrique, la vitesse de transfert peut atteindre
52Mbps en download et jusqu'à 16Mbps en upload. Seule la version asymétrique est réellement
utilisée. C'est la plus rapide des liaisons DSL.
Le tableau qui suit récapitule les solutions xDSL déjà citées :
Sigle Définition Mode Débit Débit Distance Nombre de

Downlink Uplink maximale paires
HDSL High data 1.544 Mb/s 1.544 Mb/s 3,6 km 2 ou 3

rate DSL 2.048 Mb/s 2.048 Mb/s suivant le
débit
souhaité
HDSL 2 High data -1.544 Mb/s -1.544 Mb/s 1

Symétrique
rate DSL 2 (USA) (USA)

2,5 km
- 2 Mb/s -2 Mb/s
(Eur) (Eur)
SDSL Symmetric 128 Kb/s à 768 Kb/s 3,6 km 1

DSL 2 Mb
Single-Pair - 192 Kb/s à - 192 Kb/s à

High-Speed 2,3 Mb/s 2,3 Mb/s
SHDSL DSL (une paire),
(1 paire) - 384 Kb/s 1 ou 2
to 4.6 Mb/s suivant le
(deux 5 km débit
- 384 Kb/s paires) souhaité
to 4.6 Mb/s
(2 paires)
ADSL Asymmetric 128 Kb/s à 5,4 km (6,5

DSL 8 Mb/s 16 à 640 en réduisant
Kb/s la vitesse)
ADSL 2 128 à 12 1
Mb/s
Asymétrique
ADSL 2+ 128 à 24 16 Kb/s à 1 5,4 Km
Mb/s Mb/s
Rate 0.6- 8 Mb/s 128 kb/s-1 5,4 km 1

Adaptive Mb/s
RADSL DSL
VDSL Very high 15-53 Mb/s 1.544-2.3 1,3 km 1

data DSL Mb/s
ReADSL Reach 512kb/s 128 kb/s 8 km 1

Extended
ADSL
Tableau 4: Les solutions xDSL
iii. Les lignes louées (MIC):

Les lignes louées constituent un moyen de transfert rapide mais avec plus de paires.
Le débit offert par une E1/T1 est un multiple de 64kbits/s, cette unité correspond à un canal dans un
lien E1 à 2,048Mbits/s (32 canaux à 64kbits/s) ou T1 (Trunk-carrier, level 1 multiplexing) à
1,544Mbits/s (24 canaux de 64Kbits/s + 8Kbits/s de signalisation).
Pour un utilisateur, une LS consiste en une liaison point à point entre deux sites. Pour l’opérateur,
ce n’est qu’un réseau d’accès à son réseau : la liaison cuivre qui part du site client abouti à un
multiplexeur qui concentre d’autres LS (issues d’autres clients) sur des liaisons haut débit en fibre
optique, où la bande passante est dédiée à chaque client.
Difficile à mettre en œuvre, encombrante et très chère lorsqu’on augmente en débit et/ou en
distance, les lignes louées sont devenues obsolètes de nos jours et remplacées par les services VPN
qui offrent les mêmes fonctionnalités de sécurité et de disponibilité à des coûts moins élevés. Cette
solution ne sera pas retenue dans notre cas.
2. Les réseaux sans fil

La BLR, ou boucle locale radio, permet de connecter des utilisateurs sur une antenne distante d’un
opérateur de télécommunications, via des ondes radio. Cette technique est un type de boucle
locale qui permet de compléter la desserte filaire traditionnelle. La BLR est moins onéreuse que le
câble puisqu’il n’y a pas besoin d’effectuer de travaux de génie civil pour la mettre en place.
Plusieurs technologies permettent la mise en place d’une BLR.
i. Le Wifi :
Wifi (Wireless Fidelity) est un ensemble de protocoles de communication sans fil régis par les
normes du groupe IEEE 802.11 décrivant les caractéristiques d’un réseau local sans fil WLAN. Les
normes Wi-Fi permettent de mettre en place plusieurs configurations de réseaux :

 Le mode infrastructure : permettant à plusieurs ordinateurs équipés d’une carte Wi-Fi de
se connecter au réseau extérieur à l’aide de points d’accès (PA) qui agissent comme des
concentrateurs réseau.
 Le mode « ad hoc » : permettant de connecter directement les ordinateurs équipés d’une
carte Wi-Fi, sans utiliser un matériel tiers tel qu’un point d’accès.
 Le mode pont « bridge » : servant à connecter un ou plusieurs points d'accès entre eux
pour étendre un réseau filaire, par exemple entre deux bâtiments. La connexion se fait au
niveau de la couche 2. Ce mode permet de faire un pont tout en accueillant des clients
comme le mode infrastructure. Dans le cadre de l’accès haut débit, nous nous intéressons ici
aux normes 802.11n et 802.11ac. Alors que la première prétend pouvoir atteindre
les 300Mbps (débit réel de 100Mbps dans un rayon de 100 mètres) grâce aux technologies
MIMO et OFDM, la deuxième permettra dans un futur proche d’atteindre les 500Mbps
grâce à MIMO, MU-MIMO, beam forming et 256 QAM.
Les adaptateurs 802.11n peuvent utiliser les fréquences 2.4Ghz ou 5Ghz (simple bande) ou
les deux à la fois (double radio), tandis que les adaptateurs 802.11ac travaillent seulement
dans la bande des 5Ghz.
Avec des applications gourmandes en bande passante telles que la vidéoconférence ou la gestion de
CRM migrée du poste de travail aux smartphones et tablettes, le réseau Wi-Fi deviendra un élément
d’infrastructure essentiel pour les réseaux d’accès au Cloud.
ii. Le WiMax :
WiMAX (Worldwide Interoperability for Microwave Acces) est un standard de communication
sans fil.
Dans le cadre des réseaux d’accès haut débit, nous nous intéressons ici à IEEE 802.16m, qui est le
standard contenant les spécifications pour la mise en œuvre du Gigabit WiMAX concernant les
systèmes d'accès par liaison sans fil fixe et mobile à large bande de fréquences.
IEEE 802.16m doit permettre la transmission de données par liaison sans fil fixe ou nomade
stationnaire jusqu'à un débit de 1Gbps et 100Mbps par liaison sans fil mobile à grande vitesse. Cette
technologie ouvre la voie du haut débit pour la téléphonie sur IP et la connexion Internet.
Certaines contraintes techniques, inhérentes aux technologies radio, limitent cependant les usages
possibles. La portée, les débits, et surtout la nécessité ou non d'être en ligne de vue de l'antenne
émettrice, dépendent de la bande de fréquence utilisée. Dans la bande 10-66GHz, les connexions se
font en ligne de vue (LOS, Line Of Sight), alors que sur la partie 2-11GHz, le NLOS (Non LOS) est
possible notamment grâce à l'utilisation de la modulation OFDM (Orthogonal Frequency
Division Multiplexing), et la technologie MIMO (Multiple-Input Multiple-Output).
Sécurisé, flexible, le WiMAX, peut mettre en place une QoS pour les applications temps réel ou les
flux transactionnels nécessitant une large bande passante.
Ici aussi, on peut réaliser des liaisons point à point entre le local de CBI et celui d’une entreprise
cliente (distant de quelques kilomètres) en utilisant des antennes directionnelles pour créer un pont
entre les deux bâtiments.

iii. Le LASER (Light Amplification by Simulated Emission of Radiation):
Figure 43: Pont LASER
Profitant des progrès réalisés, tel le multiplexage optique (DWDM), la solution LASER permet de
créer une liaison sans fil à très haut débit (100Mbps, 1Gbps et jusqu’à 100Gbps) sur des distances
de plusieurs kilomètres. Cette liaison est sécurisée et cryptée, et se compose de deux boîtiers
fonctionnant impérativement en vision directe (LOS) et généralement en transmission
bidirectionnelle, dite Full duplex. Le système optoélectronique travaille avec des longueurs d'onde
(785 ou 850 nm) voisines de celles des fibres optiques (850, 1 310 ou 1 550 nm). Il peut être doublé
pour assurer une sécurisation parfaite des transmissions. Les équipements de communication
peuvent être télé gérés depuis un PC.
Ce type de solution fournit une alternative aux ponts WIFI ou WIMAX, ou à la mise en place de
liaisons filaires (MIC) de par la facilité de sa mise en œuvre et son prix deux fois moins cher.
Enfin, avantage déterminant : le laser optique n'est soumis à aucune autorisation de l'ANRT. En
plus de son entière transparence pour les protocoles réseaux et la gestion supportée de toutes les
configurations. Les constructeurs proposent des produits d'interface correspondant aux standards du
marché (10 à 100Mbps sur paire torsadée ou fibre optique), Token Ring (4 ou 16Mbps), FDDI (sur
paire torsadée ou fibre optique), ATM 155Mbps (sur paire torsadée ou fibre optique), Fibre
Channel, et liaisons à canaux multiples de 2 Mbps. Ces solutions offrent l'interconnexion de réseaux
locaux informatiques, autrement appelée LANtoLAN, et prouvent aussi leur utilité pour relier le
backbone de l'opérateur au destinataire final. Les principaux constructeurs d'équipements de
communication laser présentent des appareils modulaires qui autorisent une évolution en termes de
débit et de nombre de canaux, ce qui rend cette technologie appropriée aux applications
multimédias temps réel, ou celles nécessitant un débit élevé (transfert de fichiers lourds,
établissement d’une session client serveur… etc).
Les distances de liaisons sont d'environ 2 000 m au maximum dans les zones tempérées, 5 000 m et
plus dans les zones sèches. S’il arrive qu’une grue soit placée entre l’émetteur et le récepteur, dans
notre cas le bâtiment de l’entreprise cliente et la CBI, la coupure de liaison peut durer des mois, ce
qui peut causer un arrêt complet des échanges entre les deux entités. C’est pourquoi il faut effectuer

un travail d’ingénierie, car l’environnement doit être étudié avec soin, avant d’opter (ou non) pour
cette solution au coût très encourageant.
iv. Internet par satellite:

Internet par satellite est à la fois une méthode d'accès et un mode de large diffusion au
réseau Internet via une transmission satellitaire à destination des entreprises.
En envoi, la vitesse varie de 128kbps à 1024kb/s pour 512kb/s à 8Mb/s en réception (avec une
limite théorique de 155Mbps). Pourtant, le système utilise des satellites géostationnaires, soit à une
distance de 35.786 km de la terre. Lors de l'émission (ou de la réception), le signal parcourt d'abord
cette distance vers le satellite puis est renvoyé vers la base de réception (soit un petit déplacement
de plus de 70.000 kilomètres). Ceci provoque des temps de latence conséquents. En général, le ping
moyen d'une connexion satellite se situe aux alentours de 650 ms (40 ms pour l'ADSL). Ce qui
exclut d’office les applications temps réel ou dont dépend l’activité de l’entreprise cliente.
Après avoir traversé le premier tronçon du réseau, les flux échangés entre la CBI et ses clients
traverseront, dans la majorité des cas, un réseau étendu (WAN). Ce réseau doit aussi répondre aux
exigences du Cloud, en assurant une continuité de qualité du support de transmission. Le traitement
de la partie du réseau étendu est effectué dans l’Annexe A.

II. Interaction avec le Cloud
1. vCloud Director
Le client dispose d’une connexion Internet, ou d’une liaison point-à-point avec la CBI. Maintenant
il doit pouvoir accéder à ses ressources pour effectuer plusieurs opérations de personnalisation et de
maintenance. L’outil qui lui permettra ceci, bien qu’il soit une instance pouvant être installée et
gérée par l’administrateur vCenter, est vCloud Director.
vCloud Director (vCD) est une solution d’IaaS qui rassemble les ressources vSphere dans le centre
de données et les livre dans un catalogue au client final, à travers un portail Web, tout en masquant
la complexité de l’infrastructure derrière. C’est un outil élastique qui procure une facturation basée
sur la consommation. vCD peut être considéré comme une couche supplémentaire s’ajoutant à la
couche vSphere pour offrir au client des ressources avec transparence, comme l’illustre la figure
suivante :
Figure 44: Architecture du datacenter fournisseur
De bas en haut, les composants vSphere offrent une abstraction des ressources physiques en les
virtualisant, et maintenant vCD offre un autre niveau d’abstraction de ces ressources en les rendant
plus « spécifiques » ou « propres » à chaque client.
Avant d’entrer dans la matière, prenons du recul pour réfléchir à la philosophie de vCD. La notion
même de Cloud Computing s’articule autour du niveau sans précédent de flexibilité qui peut être
offert aux clients, leur permettant d’effectuer des opérations qui étaient disponibles seulement pour
les administrateurs vCenter. Dans cette perspective, nous pouvons considérer vCD comme une
interface (ou proxy) à l’infrastructure virtuelle. Ceci permet aux administrateurs vCenter de donner
aux clients beaucoup plus de flexibilité, mais en même temps de garder un contrôle total des
opérations qu’ils peuvent effectuer.
2. Architecture de vCD
Figure 45: Architecture de l'environnement vCloud
A partir de cette image, nous allons détailler chaque composant de l’architecture de

l’environnement de travail vCD:
 VMware vCloud Director Server: aussi appelée cellule, c’est une entité vCD qui est
installée sur une machine RedHat Enterprise Linux. La cellule gère la connectivité à vCD et
offre une API (vCloud API) et une interface web pour l’utilisateur.
Plusieurs cellules peuvent être installées et mises en pool pour procurer l’équilibrage de charge.
N’importe quel équilibreur de charge qui supporte des connexions SSL persistantes à travers une
connectivité à Internet ou aux services réseau internes peut effectuer l’équilibrage de charge entre
cellules vCD. Un équilibreur de charge partage la charge des sessions entre les différentes cellules
du pool, surveille l’état de santé de ces cellules et ajoute/retire des cellules du pool. Ceci offre aux
clients et administrateurs disponibilité et évolutivité.

 VMware vCloud Director Database : c’est une base de données Oracle où sont stockées
toutes les informations relatives à vCD. Cette base de données doit être configurée avec
redondance et haute disponibilité.
 VMware vShield Manager : utilisé pour gérer tous les services vShield comme vShield
Edge qui sera créé à chaque fois qu’une connexion NAT/Routée est configurée dans
l’environnement vCD.
 Composants de VMware vSphere : vCD procure une couche supplémentaire à celle de
vSphere et travaille avec vCenter Server, vCenter Server Database et les hôtes ESXi pour
procurer des ressources pour cloud privé et public.
3. Services offerts par vCD

Centres de données virtuels
Les centres de données virtuels (virtual Data Centers) sont des entités logiques qui présentent des
capacités de traitement, de stockage et de mise en réseau disponibles pour les clients. Ces capacités
sont attribuées à l’organisation par l’administrateur système. Une organisation peut posséder
plusieurs vDCs.
Un centre de données virtuel permet aux administrateurs vCenter de :
 Définir les options de sécurité d’accès pour l’ensemble de l’architecture (quotas/baux pour
machines virtuelles en marche et/ou stockées, limites d’opérations dévoreuses de ressources
pour prévenir l’affectation des autres utilisateurs d’une organisation et protéger l’ensemble
du vDC d’attaques de déni de service DoS) ;
 Augmenter la vitesse de déploiement : possibilité d’ajout de ressources au vDC à la
demande du client ;
 Procurer une haute disponibilité aux clients via un réseau IP haute performance.
Aussi, un vDC permet au client final de :
 Accéder à une infrastructure disponible 24/7/365 via un contrat SLA (Service Level
Agreement) ;
 Confier les systèmes critiques à des experts qui supervisent bande passante, ressources
matérielles, capacités énergétiques en 24/7/365 afin d’anticiper tout incident ;
 Profiter du Cloud Computing et ses différentes solutions SaaS et IaaS.
Catalogues de services d'infrastructure
Les organisations utilisent des catalogues pour stocker des modèles de vApps et des fichiers de
support. Les membres d'une organisation disposant d'un accès à un catalogue peuvent utiliser les
modèles de vApp préconfigurés du catalogue et les fichiers de support afin de créer leurs propres
vApps.
vCloud Director propose deux types de catalogues : les catalogues d'organisation et les catalogues
publics. Les catalogues d'organisation incluent des modèles de vApp et des fichiers de support
partagés avec les autres utilisateurs de l'organisation. Si un administrateur système autorise une
organisation à publier un catalogue, celui-ci devient public.

Il existe deux façons d'ajouter des modèles de vApp à un catalogue. Vous pouvez transférer un
package OVF (Open Virtualization Format) directement vers un catalogue ou enregistrer un vApp
en tant que modèle de vApp.
Les administrateurs d'organisation figurant peuvent afficher les modèles de vApps et les fichiers de
support d'un catalogue public et copier ces fichiers vers un catalogue de leur organisation afin de les
mettre à disposition des membres.
Environnement multi-locataires
Les administrateurs peuvent regrouper les clients en entités pouvant être associées à n'importe quel
ensemble de règles. Chaque entité dispose de ressources virtuelles isolées, d'une procédure
d'authentification LDAP indépendante, de contrôles de règles spécifiques et de catalogues exclusifs.
Ces caractéristiques permettent à un environnement multi-locataires abritant plusieurs clients de
partager la même infrastructure matérielle.
Portail en libre service
Les utilisateurs de vCloud peuvent accéder aux ressources et les gérer à partir de deux outils :
Console Web : les utilisateurs peuvent accéder directement à leurs centres de données et à leurs
catalogues via un navigateur web après authentification.
vCloud API : procure une autre interface de communication avec les ressources vCD, c’est la
pierre angulaire à la fédération et le support de l’écosystème. Tous les outils actuels de la fédération
parlent à l'environnement vCloud par le biais de l'API vCloud. Par exemple, VMware Service
Manager communique avec vCloud Director utilisant l'API vCloud.
4. Mise en réseau vCloud Director

La réalisation du niveau de flexibilité requis par les clients du Cloud dans le département réseau est
une tâche pas du tout triviale. Pensons un peu à la difficulté d’implémenter un produit qui permet à
un client de créer, en mode self-service, des segments de réseaux de niveau 2 séparés, définir des
options IP personnalisées de niveau 3, configurer des services tels que DHCP, NAT ou firewall…
Tout ceci sans avoir à demander les administrateurs vSphere/Cloud de le faire pour lui, sans gâcher
la configuration de tout le Cloud, sans créer de conflits avec d’autres locataires dans le Cloud.
Nous allons expliquer le déroulement de la mise en réseau dans vCD en suivant une certaine
approche : commencer par la perspective de l’administrateur vSphere, décrire le fonctionnement de
la mise en réseau à partir de la couche vSphere allant jusqu’au client final et la manière dont il
effectue la mise en réseau de ses machines virtuelles.
4.1. Types de réseaux dans vCD

L’environnement vCD offre trois types de réseaux, à savoir les réseaux d’Organisation, les réseaux
de vApps et les réseaux externes. De point de vue vSphere, ces réseaux sont des pools réseau
(Network pools) : segments de niveau 2 créés par l’administrateur à l’aide des commutateurs
virtuels Standard, Distribué ou Nexus1000V.

i. Réseaux externes
Un réseau externe est toujours créé par l’administrateur vCenter (fournisseur Cloud) et procure la
connectivité externe à vCD, autrement dit, c’est la fenêtre des machines virtuelles sur le monde
extérieur. Un réseau externe peut être un réseau de stockage, Internet ou autre. Chaque organisation
dispose de son propre réseau externe auquel elle peut se connecter. Ce type de réseau est créé par le
biais de commutateur standard, distribué ou Nexus1000V.
Pendant la création d’un réseau externe, l’administrateur doit fournir à vCD des paramètres de
configuration niveau 3 : masque sous réseau, passerelle par défaut, adresse DNS et une plage
d’adresses IP. En remplissant ces champs d’information, l’administrateur « enregistre » le réseau
externe dans vCD, pour que celui-ci utilise ces paramètres lorsque les machines virtuelles seront
connectées à ce réseau directement.
Figure 46: Réseau externe vCloud
ii. Réseaux d’organisation
L’organisation est une construction logique qui décrit un locataire (client). Le fournisseur crée
l’organisation, lui affecte des ressources et fournit au client l’URL permettant la connexion à vCD
via la console Web. Chaque organisation compte un ou plusieurs administrateurs qui finalisent la
configuration de l'organisation en ajoutant des membres et en définissant des politiques et des
préférences. Une fois l'organisation configurée, les utilisateurs non-administrateurs peuvent se
connecter pour créer, utiliser et gérer des machines virtuelles et des vApps.
Une organisation peut contenir un nombre arbitraire d'utilisateurs et de groupes. Des utilisateurs
peuvent être créés localement par l'administrateur d'organisation ou importés à partir d'un service
d'annuaire, tel que LDAP. Les groupes doivent être importés à partir du service d'annuaire. Les
autorisations au sein d'une organisation sont contrôlées via l'affectation de droits et de rôles à des
utilisateurs et des groupes.
Un réseau d'organisation se trouve dans une organisation vCD et il est disponible pour l'ensemble
des vApps dans l'organisation. Un réseau d'organisation permet aux vApps au sein d'une
organisation de communiquer entre eux. Seuls les administrateurs système peuvent créer des
réseaux d'organisation, mais les administrateurs d'organisation peuvent gérer des réseaux
d'organisation, y compris les services réseau qu'ils fournissent. Ce type de réseau est créé par le
biais de commutateur standard, distribué ou Nexus1000V.
Figure 47: Réseaux d'organisation vCloud
Il existe trois possibilités de configuration de la connexion entre un réseau d’organisation et un

réseau externe:
 Connectivité directe : les vApps connectés au réseau d’organisation sont directement

connectés au réseau externe. Du point de vue vSphere, la (les) machine(s) virtuelle(s) de ces
vApps se connecte(nt) au groupe de port du réseau externe.
Exemple d’utilisation : les vApps ayant besoin de se connecter aux services réseau (Stockage SAN)
à travers un réseau externe sécurisé peuvent se connecter directement au réseau externe.
 Connectivité NAT/Routée : les vApps connectés au réseau d’organisation sont connectés

au réseau externe via un mécanisme de routage assuré par une appliance vShield Edge
déployée par le vShield Manager. Du point de vue vSphere, un groupe de port est créé à la
volée et est associé à un pool réseau préalablement créé et déclaré comme « disponible »,
les vApps connectés se connectent à ce groupe de port.
Exemple d’utilisation : les vApps ayant besoin de se connecter à un réseau externe non sécurisé
(Internet).
 Connectivité isolée ou interne : les vApps connectés au réseau d’organisation ne peuvent

communiquer qu’entre eux, pas avec le monde extérieur. Du point de vue vSphere, le même
scénario de la connectivité NAT/Routée se répète, mais le déploiement de l’appliance
vShield Edge est une option dans le cas où l’administrateur désire activer le service DHCP
sur ce réseau.
Exemple d’utilisation : les vApps n’ayant pas besoin de connectivité externe.
iii. Réseaux vApp
Un vApp est constitué d’une ou plusieurs appliances virtuelles, qui sont des machines virtuelles
contenant des applications tournant sur des systèmes d’exploitation. Exemple de vApp : pour

déployer une solution CRM (Costumer Relationship Management), la vApp contient une machine
virtuelle serveur de base de données, machine virtuelle serveur d’application et une machine
virtuelle serveur web.
Figure 48: Réseaux vApp vCloud
Un réseau vApp réside dans un vApp et permet aux machines virtuelles contenues dans le vApp de
communiquer entre elles. Il est créé par le client et peut être connecté à un réseau d'organisation
pour autoriser les vApp à communiquer entre eux dans l'organisation, ou en dehors de celle-ci, si le
réseau d'organisation est connecté à un réseau externe. Ce type de réseau est créé par le biais de
commutateur standard, distribué ou Nexus1000V.
Il existe trois possibilités de configuration de la connexion entre un réseau vApp et un réseau

d’organisation:
 Connectivité directe : les machines virtuelles connectées au réseau vApp sont directement
connectées au réseau d’organisation. Du point de vue vSphere, les machines virtuelles se
connectent au groupe de port du réseau d’organisation.
Exemple d’utilisation : des machines virtuelles appartenant à des vApps différents, ayant besoin de
communiquer entre elles avec les mêmes exigences de sécurité.
 Connectivité NAT/Routée : les machines virtuelles connectées au réseau vApp sont

connectées au réseau d’organisation via un mécanisme de routage assuré par une appliance
vShield Edge déployée par le vShield Manager. Du point de vue vSphere, un groupe de port
est créé à la volée et est associé à un pool réseau préalablement créé et déclaré comme
« disponible », les machines virtuelles du réseau vApp se connectent à ce groupe de port.
Exemple d’utilisation : les machines virtuelles appartenant à des vApps différents, ayant besoin de
communiquer mais avec des exigences de sécurité différentes (machines virtuelles de DMZ avec
des machines virtuelles de production).
 Connectivité isolée ou interne : les machines virtuelles connectées au réseau vApp ne

peuvent communiquer qu’entre elles, pas avec le réseau d’organisation. Du point de vue
vSphere, le même scénario de la connectivité NAT/Routée se répète, mais le déploiement

de l’appliance vShield Edge est une option dans le cas où l’administrateur désire activer le
service DHCP sur ce réseau.
Exemple d’utilisation : les machines virtuelles dans un même vApp n’ayant besoin de communiquer
entre elles qu’en interne pour le déploiement d’une application n-niveaux en toute sécurité.
La figure suivante récapitule les configurations possibles des différents types de réseaux vCloud :
Figure 49: Récapitulation des configurations des réseaux vCloud
4.2. Pools réseau

Les pools réseau doivent être créés avant la création et le déploiement de réseaux d’organisation ou
de vApps. Il y a trois types de pools réseau différents qui peuvent être créés:
i. Pools réseau basés sur VLAN : l’administrateur vCenter crée un pool réseau, lui fournit une
plage de VLAN IDs, et doit mettre en place des trunks VLANs sur tous les hôtes ESXi et les
switchs physiques externes. A chaque fois que vCD a besoin d’un pool réseau, vCenter crée
un groupe de port à la volée et lui associe un VLAN ID disponible, et si un réseau est détruit,
son VLAN ID redevient disponible pour réutilisation. L’isolation entre différents pools réseau
se fait suivant la norme IEEE 802.1Q avec format standard de trame. Ce type de pool réseau
peut être utile dans le cas où il n’y a pas besoin d’un grand nombre de VLANs ou de services
VPN/MPLS.
Avantages
Ce type de pool réseau procure les réseaux isolés les plus sécurisés ;
Pas besoin d’intervention manuelle puisque les groupes de port sont créés à la volée ;
Pas de surcharge de performance (MTU standard).
Inconvénients
La configuration et la maintenance de VLANs doit se faire au niveau de tous les

commutateurs physique et de tous les hôtes ESXi.

Demande une large plage de VLANs selon le nombre de réseaux vApps et d’organisation
et peut ne pas satisfaire à la demande.
ii. Pools réseau basés sur groupes de port : l’administrateur vCenter crée des groupes de ports
pré-provisionnés, importés dans vCD. A chaque fois que vCD a besoin d’un pool réseau, il n’a
qu’à en saisir un depuis la liste disponible. L’isolation entre différents pools réseau se fait
suivant la norme IEEE 802.1Q avec format standard de trame. Ce type de pool réseau peut être
utilisé dans le cas où il n’y a pas besoin pour les réseaux routés (la sécurisation des réseaux
vApp ou d’organisation n’est pas très critique), le nombre de VLANs disponible est limité ou
la gestion de VLAN est problématique.
Avantages
Meilleur contrôle de surveillance et de visibilité des groupes de port ;
Pas de surcharge de performance (MTU standard).
Inconvénients
Tous les groupes de port doivent être créés manuellement ou a travers orchestration avant
d’être mappés au pool réseau.
iii. Pools réseau basés sur l’isolation réseau vCD : dans ce cas, l’isolation entre les segments
réseau de niveau 2 se fait suivant la technique Mac-in-Mac. Cette technique repose sur l’ajout
de 24 octets à trame Ethernet pour l’encapsuler, ce qui augmente la taille de la trame à 1524
octets. L’encapsulation contient l’adresse MAC source et destination des hôtes ESXi et celui-
ci se charge de la décapsulation de la trame pour acheminer le trafic correctement. Lors de la
création de ce type de pool réseau, l’administrateur doit fournir le nombre de segments qui
doivent exister et c’est fini. A chaque fois que vCD a besoin d’un pool réseau, vCenter crée un
groupe de port à la volée et l’associe à l’un des pools réseau disponible avec un NI-ID.
Avantages
Pas besoin de VLAN Tagging pour l’isolation, seulement le nombre de réseaux dont le
client a besoin est suffisant ;
Pas besoin d’intervention manuelle puisque les P_G sont créés à la volée, tant que les NI-
IDs sont encore disponibles.
Inconvénients
Cette solution n’offre pas le même niveau de sécurité que les VLANs, c’est pourquoi il y a
besoin d’un « VLAN de transport » isolé ;
Surcharge administrative et surcharge de performances réseau due à l’encapsulation Mac-in-

Mac ;
Ce type de pool réseau ne peut pas supporter les réseaux routés.

III. Orchestration dans le Cloud
L'environnement Cloud est composé de plusieurs composants qui exposent des services Web. Une
plate-forme d’orchestration vCloud offre la possibilité de rassembler les services dans un flux de
travail (workflow) logique. VMware a créé des applications différentes de gestion qui supportent la
définition et l’exécution du processus de flux de travail. vCenter Orchestrator comprend les
applications suivantes:
 VMware vCenter Orchestrator est une partie de la plateforme vCenter qui crée une
orchestration technique permettant aux utilisateurs d’automatiser les tâches répétitives en
créant des flux de travail, permettant ainsi une vaste intégration avec des composants
vCloud tiers.
 VMware Service Manager est une plateforme ITIL configurable qui dispose d’un « service
desk », d’une configuration et gestion de changement automatisées et de la gestion d’actifs
IT.
vCenter Orchestrator
vCenter Orchestrator (vCO) est un système de rassemblement des flux de travail opérationnels. Le
bénéfice principal de vCO est la possibilité de coordination de plusieurs systèmes pour
l’accomplissement d’une opération composite qui aurait autrement demandé plusieurs opérations
individuelles sur différents systèmes. En général, si une opération utilise un seul système sous-
jacent, vCD permet de fournir un accès direct à ce système pour une grande efficacité et une
réduction de la complexité. Dans un environnement vCloud, vCO permet d'automatiser des tâches
très répétitives afin d'éviter le travail manuel et les erreurs potentielles.
Figure 50: vCenter Orchestrator
vCO comprend les applications suivantes :
 vCenter Orchestrator Client permet au développeur de flux de travail de créer, rassembler,

tester, packager des flux de travail, actions, politiques, ressources et configurations ;

 vCenter Orchestrator Server Web configuration est une application indépendante qui
fonctionne côte-à-côte avec une interface web qui permet aux administrateurs de configurer
le vCenter Orchestrator Server et ses plug-ins, et effectue des opérations de maintenance.
 vCenter Orchestrator Server est le service d’exécution d’orchestration, y compris ses
interfaces et ses adaptateurs enfichables.
vCO possède un plug-in framework et des plug-ins disponibles pour vCenter Server, vCloud
Director et vCenter Chargeback. Ceci permet à vCO d’orchestrer des flux de travail au niveau des
APIs Chargeback et vCloud.
Il existe trois principales catégories de cas d’utilisation de l’orchestration :
 Opérations d’administration vCloud :
Exemple : un fournisseur souhaite ajouter un nouveau client. Les étapes essentielles sont l’ajout
d’une organisation, des utilisateurs (possibilité de le faire à partir de LDAP), réseaux, centres de
données virtuels et catalogues. Le fournisseur pourrait aussi souhaiter programmer un rapport
Chargeback récurrent pour facturation et envoyer un email de notification au nouveau locataire
l’informant que son environnement vCloud est prêt.
Un autre exemple : quand un client demande une capacité additionnelle du réseau externe. Le
fournisseur voudra créer une automatisation de la création du réseau, qui comprend la
génération d’un nom, l’identification, allocation d’un VLAN et d’une plage d’adresse IP, la
configuration du commutateur réseau et du pare-feu du périmètre vCloud, création d’un réseau
externe au niveau de vCenter et enfin allocation du réseau externe à l’organisation du locataire.
 Opérations d’administration d’organisation : en général, ces tâches concernent la gestion du

cycle de vie du vApp, telles que la création, la configuration, la maintenance, et le
déclassement.
Exemple : les cas où un administrateur d’organisation veut gérer des mises à jour récurrentes
d’un progiciel ou d’un élément de configuration, à travers multiples machines virtuelles en
effectuant une seule opération. Un flux de travail peut admettre une liste de systèmes en tant que
paramètres, une source pour le logiciel ou la configuration, puis effectuer la mise à jour sur
chaque système.
 Opérations d’organisation effectuées par les clients : ce sont des tâches que l’administrateur
d’organisation désire décharger en tant qu’opération self-service. L’exécution de l’opération
en tant que flux de travail vCenter Orchetsrator procure une manière facile d’exposer
l’opération à l’utilisateur via le portail intégré ou un portail personnalisé s’appuyant sur
l’API des services web. Plusieurs opérations dans cette catégorie peuvent être satisfaites
directement via la console web vCloud Director. Cependant, quelques opérations affectent
des systèmes multiples et peuvent être mieux adaptées au portail client (vCenter
Orchestrator Client). Les clients vCloud ne possèdent pas de visibilité concernant les
composants d’orchestration, d’où vient la difficulté ; le fournisseur vCloud doit initier le

flux de travail à travers vCenter Orchestrator Client où bien fournir un portail à vCenter
Orchestrator.
Exemples : reconfiguration des mots de passe de comptes utilisateur sur machines virtuelles,
mise en place de services d’équilibrage de charge en mode maintenance (arrêter le service, le
retirer du pool d’équilibrage de charge, désactiver les moniteurs), chargement de certificats dans
des machines virtuelles et déploiement d’instances d’applications personnalisées à partir d’un
catalogue d’organisation.
Ayant abordé les différents outils permettant aussi bien aux administrateurs du Cloud que les
clients d’interagir et de manipuler les différentes composantes du Cloud, il est temps de faire un
inventaire des équipements nécessaires à l’établissement de cette solution, et d’en proposer une
architecture globale.

IV. Facturation des services du Cloud
Pour l’environnement vCloud, la mesure des ressources est essentielle pour évaluer avec précision
l’usage du consommateur et concrétiser le comportement des clients. L’outil VMware vCenter
Chargeback procure la capacité de mesure permettant ainsi transparence et responsabilité vis-à-vis
du coût.
1. VMware vCenter Chargeback

VMware vCenter Chargeback procure le contrôle logiciel pour la mesure, l’analyse, le reporting et
la facturation de la consommation des clients vis-à-vis des ressources utilisées dans les
environnements de Cloud public ou privé. Les fournisseurs du Cloud peuvent configurer et associer
différents modèles de coût aux entités vCloud Director.
vCenter Chargeback fournit transparence et responsabilité du coût pour aligner le comportement du

client avec les ressources qu’il a consommées.
i. Serveur Chargeback
Le serveur Chargeback est un serveur Apache Tomcat physique ou virtuel et possède les
spécifications recommandées suivantes :
 2.0Ghz ou plus de CPU Intel/AMD x86

 Minimum de 4Go de RAM
 3Go ou plus d’espace de stockage
 Adaptateur Ethernet 1Gbits/s
Les serveurs Chargeback peuvent être mis en cluster (jusqu’à trois serveurs) pour une meilleure
performance et disponibilité pour l’interface utilisateur. Une configuration en cluster s’appuie sur
l’équilibreur de charge Apache, livré avec le logiciel Chargeback.
L’équilibrage de charge est actif-actif. Chaque requête que l’utilisateur envoie, à partir de
l’interface ou de l’API, est routée à travers l’équilibreur de charge, celui-ci l’expédie à une instance
Chargeback en se basant sur le nombre de requêtes
servies par chacune des instances à ce moment là.
La charge du reporting est aussi équilibrée en
s’appuyant sur l’ordonnanceur Quartz interne.
Comme pour chaque cluster, les instances de

Chargeback se connectent à la même base de
données vCenter Chargeback Database, où sont
stockées des informations d’hiérarchie
d’organisation, de plans de coût/tarif et des données Figure 51: Mise en cluster de serveurs Chargeback
globales de configuration Chargeback. C’est une
base de données Microsoft SQL Express, Microsoft SQL Server ou Oracle.

ii. Collecteurs de données
L’intégration de vCenter Chargeback avec vCloud Director est manœuvrée à travers les collecteurs
de données (Data Collectors):
 Chargeback Data Collector : se connecte à vCenter Server pour recueillir des mesures de
machines virtuelles, ajoute tous les vCenter Servers importés dans vCloud Director à
Chargeback pour voir des détails au niveau des machines virtuelles. Les machines virtuelles
sont absentes dans les hiérarchies vCloud jusqu’à ce que leurs vCenter Servers respectifs
soient enregistrés dans vCenter Chargeback.
 vCloud Data Collector : se connecte à la base de données vCloud Director et surveille tous
les évènements de vCD relatifs à Chargeback. Il peuple la base de données Chargeback avec
des informations d’hiérarchies vCloud et d’unité d’allocation.
 vShield Manager Data Collector : se connecte aux vShield Managers associés à vCloud
pour collecter des statistiques de réseau inclus dans l’hiérarchie vCloud.
Multiples collecteurs de données peuvent travailler en mode actif-passif pour augmenter la

disponibilité. Un environnement Chargeback peut posséder plusieurs collecteurs de données
vCloud, mais ne peut se connecter qu’à une seule instance vCloud.
iii. Rôles d’utilisateurs

Chaque utilisateur Chargeback peut avoir un rôle spécifique défini selon une hiérarchie, allant de
super utilisateur à utilisateur, en passant par administrateur. Pour ceci, un serveur LDAP peut être
utilisé.
2. Calcul du coût
i. Modèles de coût
L’installation des collecteurs de données vShield Manager et vCloud crée par défaut des modèles de
coût et des politiques de facturation qui s’intègrent avec vShield Manager et vCloud Director. Les
politiques de facturation contrôlent les coûts évalués à partir des ressources utilisées. Les politiques
de facturation par défaut de vCloud sont établies sur la base d’allocation de vCPU, mémoire et
stockage. Les intervalles de temps vont de l’heure à l’année.
Les facteurs de taux (Rate factors) permettent l’évolution des coûts de base pour une entité
spécifique. Par exemple :
o Taux promotionnel : un fournisseur de service offre à un client une remise de 10%. Au lieu
de modifier le taux de base dans le modèle de coût, il applique un facteur de taux de 0.9
pour réduire les coûts de base du client de 10%.
o Taux spécifique à une configuration unique : un fournisseur de service décide de facturer
les clients pour des configurations d’infrastructure spéciale en utilisant des facteurs de taux
pour faire évoluer les coûts.
Le mode de facturation de VM instance associe un seul coût à un package de vCPU et mémoire.

Les matrices de VM instance sont liées avec un modèle de coût et comprennent : les critères de

sélection VDC, une table de coût fixée et un coût fixé par défaut. Les options des critères de
sélection comportent la correspondance du modèle de nom, la correspondance de l’attribut
personnalisé, ou ne comprend pas de critères. VM instance utilise une fonction de saut : s’il n’y
a pas de valeur d’entrée pour une taille particulière de machine virtuelle, la facturation est basée
sur la plus grande taille suivante de l’instance. Ce mode est disponible seulement dans le
modèle d’allocation Pay-As-You-Go, et est utile quand le fournisseur désire créer une matrice
de coûts fixes pour différents packages de machines virtuelles.
ii. Reporting
Chargeback peut générer des rapports de coût, d’utilisation et de comparaison pour les hiérarchies
et les entités. Une correspondance entre l’entité ou l’hiérarchie et le modèle de coût approprié doit
être effectuée lors de la génération de rapports.
Chargeback API permet de d’exporter les rapports en format XML. Les développeurs peuvent
utiliser XSLT pour transformer le XML brut dans un format pris en charge par le système de
facturation du client. Les rapports exécutés dans l'interface utilisateur Chargeback sont disponibles
en format PDF et XLS. La création des comptes de services en lecture seule doit avoir lieu pour
exécuter des rapports dans l'interface d’utilisateur ou Chargeback API.

V. Cloud hybride
Un environnement vCloud hybride incorpore une combinaison d’instances vCloud et peut
comporter des ressources sur site (Cloud privé) ou hors site (Cloud public), et par conséquent, les
applications peuvent être sur site ou hors site. Les fournisseurs peuvent fournir et gérer des
ressources publiques ou privées vCloud d’une manière sécurisée et évolutive. La connectivité qui
permet la portabilité des données et applications entre différentes instances vCloud présente une
solution hybride vCloud.
Figure 52: Exemple de Cloud hybride
vCloud Connector
i. Architecture
vCloud Connector (vCC) est une appliance virtuelle livrée en tant que plug-in vSphere permettant
aux utilisateurs de se connecter à des instances vCloud basées sur vCloud Directory ou vSphere et
de les gérer à partir d’une seule interface. Via un seul panneau vCloud Connector, les utilisateurs
peuvent voir, copier et manœuvrer des charges de travail à travers des centres de données internes
et des instances vCloud publiques ou privées. VCloud Connector est installé par l’administrateur
vCloud mais peut être accessible par des clients aussi bien que l’administrateur pour voir et gérer
les charges de travail.
Figure 53: Architecture vCloud Connector

L’architecture du vCloud Connector se compose de deux éléments :
 vCloud Connector Server qui permet de gérer et de contrôler le vCC, il est ainsi connecté
à plusieurs nœuds et au portail.
 vCloud Connector Node qui est hébergé dans différents Clouds et connecté au vSphere
pour faire le test, les différentes migrations se font à ce niveau.
Pour ce qui est de la sécurité, le vCloud server Connector et le vCloud Connector Node
communiquent via le protocole SSL.
ii. Emplacement de vCloud Connector
Figure 54: Exemple de configuration de placement vCloud Connector
 L’accès à vCC se fait uniquement à travers vSphere Client. C’est pour ceci que vCC doit
être déployé dans vCenter Server accessible par ce Client en ayant à l’esprit l’attribution
appropriée des rôles vCenter aux utilisateurs de vCC.
 Les opérations de transfert de charges de travail utilisent vCC comme intermédiaire, donc
une évaluation de la bande passante et la latence du réseau entre les instances vCloud doit
être effectuée. Dans certains cas d’utilisation, il peut être préférable d’utiliser plusieurs
instances de vCC à travers plusieurs serveurs vCenter pour éviter des malaises de
manipulation.
iii. Cas d’usage

vCC peut supporter bon nombre de cas de migration de charges de travail comprenant machines
virtuelles, modèles de machines virtuelles, vApps et modèles de vApps. Les migrations sont
possibles entre :
 vSphere<--> vCloud
 vSphere<--> vSphere
 vCloud<--> vCloud

iv. Limitations
o Le trafic vers et à partir de vCC n'est pas optimisé pour le WAN. Par conséquent, la
migration de charge de travail à travers des liaisons WAN n'est pas idéale, même si la bande
passante suffisante existe. On peut éviter ceci en installant les appliances vCC dans des
emplacements optimaux.
o Tous les transferts de charge de travail sont des migrations à froid. Les vApps et les
machines virtuelles doivent être éteints avant la migration. En outre, la configuration du
réseau vApp doit être modifiée avant d'allumer les machines virtuelles.
o vCC peut gérer jusqu’à dix transferts simultanés, les requêtes subséquentes sont mise en
queue. Le nombre maximum de connexions cloud pour un seul vCC est cinq (vSphere ou
vCD).

VI. Etude de l’existant
Avant d’équiper son centre de données dédié au Cloud, le fournisseur doit tout d’abord faire une
étude afin de pouvoir satisfaire les exigences des composants indispensables à sa mise en œuvre.
1. Clustering
Le Clustering est une technique efficace pour assurer une disponibilité élevée. Elle est encore plus
efficace, plus souple et plus rentable lorsqu'il est combiné avec la technologie de virtualisation.
Les clusters virtuels regroupent des machines virtuelles installés sur des serveurs distribués sur un
ou plusieurs clusters physiques. Ces différentes machines virtuelles sont interconnectées
logiquement par un réseau virtuel à travers plusieurs réseaux physiques.
Pour déployer une infrastructure Cloud, un cluster virtuel vCloud (vCloud Management Cluster)
est indispensable. Néanmoins, les machines virtuelles qui le constituent doivent être placées sur un
serveur physique dédié.
Le tableau ci-dessous représente les pré-requis pour les composants du vCloud Management
Cluster :
Composants vCPU RAM Stockage Networking

vCenter Server 2 4 GB 20 GB 1 GigE
Database Server 4 16 GB 100 GB 1 GigE
vCloud Director cell 1 2 4 GB 30 GB 1 GigE
vCloud Director cell 2 2 4 GB 30 GB 1 GigE
vCenter Chargeback 2 4 GB 30 GB 1 GigE
vShield Manager 1 4 GB 8 GB 100 GigE
Total 13 36 GB 218 GB 4 GigE
Tableau 5: Composants et pré-requis de vCloud Management Cluster
Il est à noter que vCloud Management Cluster doit contenir au minimum deux cellules vCloud
Director, c'est-à-dire deux vCloud Director Server.
Le défi est donc de trouver un cluster dont les spécifications répondent aux pré-requis cités
précédemment.
2. Equipements choisis par l’équipe CBI

Toute en respectant les pré-requis des composants vCloud, l’équipe CBI a décidé de se procurer les
équipements suivants :
Cisco UCS B200-M2 Blade Server:
C’est un serveur lames contenant au total 8 serveurs UCS B200-M2, dont chaque 4 serveurs sont
reliés à un Cisco UCS 2104 XP Fabric Interconnect.

Figure 55: Cisco UCS B200-M2 Blade Servers
Les deux UCS 2104XP Fabric Extenders sont intégrés dans chacun des châssis pour amener la
connectivité réseau aux lames.
Caractéristiques techniques d’une lame UCS B200M3
RAM 48 Go
CPU 2/6 core chacun
Disque dur 2 (164/164) Go
Ports virtuels 256
Tableau 6: Caractéristiques techniques d’une lame UCS B200M3
Chaque lame dans le châssis possède 48 Go de RAM, valeur supérieure à 36 Go du total des
recommandations pour les composants du vCloud Management Cluster.
En outre, la lame possède 2 CPU, chacun avec 6coeurs, ce qui permet de calculer le nombre de
vCPU disponibles, qui est de : 2*6=12 vCPU/ lame, et si on active l’Hyperthreading qui permet de
doubler le nombre de vCPU, on aura au final 2*12= 24 vCPU/ lame > 13 vCPU/ lame.
On conclut donc que le serveur UCS B200 M3, répond aux exigences des composants de vCloud
Management Cluster concernant la mémoire et le nombre de processeur.
Caractéristiques techniques d’un UCS 2104XP Fabric Extender
Ports 20
Nombre de serveurs supportés 160
Tableau 7: Caractéristiques techniques d’un UCS 2104XP Fabric Extender
Les lames sont équipées de cartes CNA de type UCS M71KR-Q. Ces dernières offrent une
connectivité 10Gbits vers chacun des Fabric Extenders présents dans le châssis. La carte CNA
permet d’interconnecter les lames avec les environnements Ethernet et Fibre Channel. Nous
remarquons alors que pour le networking, le seuil 4GigE est largement dépassé.

Cisco UCS 6120XP Fabric Interconnect:
Le centre de données est composé de deux

UCS 6120XP Fabric Interconnects pour
interconnecter le châssis UCS B200-M2 Blade
Server avec le LAN et le SAN. Figure 56: Cisco UCS 6120XP Fabric Interconnect
Ces « Fabric Interconnects » sont des commutateurs avec des caractéristiques « sans perte », une
très faible latence et une connectivité unifiée 10Gb DCB/FCoE sur l’ensemble du cluster.
Ces deux Fabric Interconnects permettent non-seulement d’avoir une isolation physique entre les
réseaux publics et privés dans le cluster (avec l’utilisation de VLANs privés), mais aussi de gérer
les deux types de réseaux dans le cas peu probable d’une panne.
Caractéristiques techniques d’un UCS6120 Fabric Interconnect
Ports 20
Nombre de serveurs supportés 160
Tableau 8: Caractéristiques techniques d’un UCS6120 Fabric Interconnect
Catalyst 4000G Series Switch :
Le centre de données contient deux commutateurs

Catalyst 4000G Series, pour assurer une redondance
matérielle au cas où l’un des deux tomberait en
panne. Figure 57: Catalyst 4000G Series Switch
Caractéristiques techniques :
nombre de ports 48
Consommation électrique 400 Watts
Taux de transfert de
100 Mbit/s
données
Duplex intégral Oui
Protocole de commutation Ethernet
Mémoire interne 64 Mo
Tableau 9: Catalyst 4000G Series Switch
EMC VNX 5300
VNX a une plate-forme robuste de consolidation du stockage par blocs, du stockage d’applications
à connexion directe et des serveurs de fichiers. La gamme EMC VNX 5300 contient 4 disques.
(Pour plus de détails, voir Annexe C).

Figure 58: EMC VNX 5300
Caractéristiques techniques
Disques min/max 4/125
CPU/Mémoire par baie Intel Xeon-5600/ 16Go

Capacité brut
360 To
maximale
Options Raid 0/1/10/3/5/6
Type de stockage
Bloc, Fichier, Objet
supporté
Bus SAS (4 voies par
2
bus)
NFS(SMB), CIFS, pNFS, MPNFS (stockage fichier)
Protocoles supportés iSCSI, FC, FCoE (stockage bloc)
REST, SOAP, XAM (stockage objet)

Unisphere pour l’accès de type Bloc, Unisphere pour l’accès
Gestion
de type Fichier, Unisphere pour l’accès unifié
Figure 59: Caractéristques techniques d'EMC VNX 5300
En effet, on dispose de 4 blocs, dont chacun contient 360 To d’espace de stockage, ce qui satisfait
pleinement aux caractéristiques de stockage des composants vCloud et aux besoins imminents en
stockage des premiers clients.

3. Architecture du datacenter dédié au Cloud
Fabric Interconnect
1
Catalyst 4000G
Series Switch
Cisco UCS B200-M2 blade

servers EMC VNX 5300
Figure 60: Architecture du datacenter dédié au Cloud

VII. Architecture globale du Cloud
Après avoir abordé en détail tous les éléments du Cloud, il est opportun d’en proposer une
architecture générale, pour disposer d’une vue d’ensemble claire.
Figure 61: Architecture globale du Cloud
La figure ci-dessus illustre l’architecture globale du Cloud. Nous allons la détailler allant du
fournisseur vers le client :
Les composantes vCenter :

 vCenter Server et vSphere Client: permettent à l’administrateur d’accéder à l’inventaire
des ressources du Cloud dont il dispose, les gérer et les configurer.
 vCenter Orchetsrator : permet à l’administrateur comme au client d’automatiser les tâches
répétitives et de les rassembler dans des processus prédéfinis et faciles à exécuter.
 vCloud Director : permet à l’administrateur comme au client de créer des vDCs, des
réseaux, des vApps et des catalogues, selon le champ d’action et les rôles prédéfinis de
chacun.
 vShield Manager : permet de déployer des instances assurant la sécurité des différents
éléments du Cloud.
 vCenter Chargeback : offre des outils pour surveiller la consommation des ressources du
Cloud et établir les factures sur cette base.
 vCloud Connector : cet outil est utile pour faire interagir Cloud Public et Cloud Privé dans
le cas où le client dispose des deux et souhaite migrer des éléments de l’un vers l’autre.
 Réseau point à point ou MPLS : assure le transport des flux entre les locaux des
entreprises et celui de la CBI.
 Navigateur Internet : permet à l’administrateur et surtout au client d’accéder à ses
ressources pour effectuer différentes opérations de gestion et de configuration.

Pour que la solution Cloud parvienne à rencontrer le succès commercial auprès des clients,
l’entreprise a tout intérêt à cerner, dès la phase de conception de la solution, les attentes du client.
Ces attentes sont multiples et sont relatives à plusieurs aspects comme celui du prix ou de la
sécurité. Et pour mettre la cerise sur le gâteau, une mesure de l’impact environnemental de la
solution Cloud ne peut qu’être utile dans la mesure où cette problématique fait l’objet de plusieurs
débats et recommandations de la part de plusieurs organisations à l’échelle internationale, ce qui
empêche les entreprises d’être indifférentes à cet égard.

Chapitre 5:
Commercialisation du
Cloud

Le présent chapitre traite de la démarche qui doit être suivie pour commercialiser le service Cloud.
Nous allons tout d’abord introduire la notion de méthode de maison.qualité (QFD), ensuite nous
allons expliquer ses différentes facettes et démarches, et enfin conclure avec une mesure de l’impact
environnemental de la solution Cloud Computing et sa contribution dans le Green IT.
I. Méthode de la maison qualité QFD

De nos jours, de plus en plus d’organismes appelés à développer de nouveaux produits font appel au
déploiement de la fonction qualité :
Le déploiement de la fonction qualité (QFD) est une méthode crée par les japonais dans les années
1970. La finalité de cette méthode étant de clairement identifier les besoins et attentes des clients.
La méthode repose sur une représentation graphique, nommée maison de la qualité.
Les pièces de cette maison qualité sont :
La pièce 1 : Enumère les besoins et les attentes des clients.

La pièce 2 : Accorde de l’importance aux attributs.
La pièce 3 : Traduit les attributs en caractéristiques techniques.
La pièce 4 : Etablit les relations entre les attributs clients et les spécifications techniques.
La pièce 5 : Calcule le poids de chaque spécification technique.
La pièce 6 (le toit) : Etablit comment une spécification technique affecte une autre.
Application de la QFD
Notre travail consistait donc à élaborer les pièces de cette maison qui sont comme suit :
Pièce 1 :
Nous avons énuméré les besoins et les exigences de l'entreprise cliente.
Ci-dessous les exigences de l’entreprise cliente que nous avons pu déterminer grâce à une enquête
faite sur 110 décideurs ouverts au Cloud Computing.
Gestion des engagements de services (SLAs)

Maitrise des enjeux sécuritaires
Abordabilité au niveau du prix
Mise en place de normes
Définition des règles de gouvernance
Gestion des risques juridiques
Interopérabilité
Green IT
Délais d'approvisionnement
Qualité de service
Tableau 10: Pièce 1 de la QFD

Explication de ces exigences :
Gestion des engagements de services (SLAs): Un document qui définit contractuellement la

qualité du service à attendre (disponibilité, pérennité des données, périmètre de responsabilité).
Maitrise des enjeux sécuritaires: Les plus importants portent sur le contrôle des accès et la gestion
des identités. Il s'agit de mettre en place des contrôles précis afin de filtrer efficacement les
utilisateurs autorisés à utiliser les applications de l'entreprise portées dans le cloud.
Abordabilité au niveau du prix: Le Cloud Computing repose sur un mode de paiement à la carte :
l'entreprise paie uniquement les ressources informatiques qu'elle consomme ce qui revient à un coût
mensuel optimisé et plus faible.
Mise en place de normes: Plusieurs normes sont déjà très utilisées dans le monde du Cloud
Computing. Les normes ISO 27001, SAS 70, SOX, ISO 20000 sont les principales. Elles permettent
avant tout de certifier une organisation sur un périmètre bien précis et de cette manière garantir aux
clients la conformité de l’entreprise par rapport aux normes.
De plus, les normes sont un tremplin et une guise de qualité pour certaines entreprises puisqu’elles
permettent d’être reconnues internationalement et de pouvoir mettre en avant des services validés
par une organisation tierce.
Définition de règles de gouvernance : L’entreprise peut surveiller l’environnement informatique,

appliquer des règles, procédures et contrôles de gestion. Les règles de gouvernance permettent
également à l’entreprise de définir les responsabilités et droits décisionnels des personnes qui
utilisent et gèrent les ressources informatiques.
Gestion des risques juridiques: Sur le plan juridique, on se rapproche du cas dans lequel une
entreprise déciderait d’externaliser tout ou une partie de son système d’information. Une démarche
prudente consiste à bien appréhender les risques et à prendre les mesures nécessaires pour garantir
la continuité du service, la sécurité des données, la qualité du service, et la réversibilité.
Interopérabilité : La problématique de l’interopérabilité se pose dans le cas où une entité

utilisatrice de l’infrastructure Cloud souhaite changer d’hébergeur. Il y a plusieurs niveaux de
réponse à cette question. Nous pouvons envisager une situation dans laquelle il lui est juste possible
de récupérer les données applicatives ce qui impliquerait de devoir reconstruire la quasi totalité de
l’infrastructure applicative. Nous pouvons également envisager une situation où il est possible de
récupérer une version « packagée » des machines virtuelles ou, à l’opposé, une situation où rien
n’est prévu pour être compatible avec d’autres plateformes.
Green IT : Le Cloud Computing présente un modèle favorisant les réductions d'émissions de

carbone des entreprises, car :
 Moins de serveurs sont utilisés en interne;

 Les centres de calculs sont construits aujourd'hui sur des architectures utilisant des matériaux et
des mécanismes adaptés d'air conditionné, de refroidissement, d'éclairage qui s'inscrivent dans une

politique de développement durable. Au final, mettre en place une informatique plus écologique
permet aux centres de calculs de baisser leur facture énergétique (comme l'électricité).
Délais d’approvisionnement : Il s’agit dans le cas classique du délai que prend une entreprise afin
de s'approvisionner auprès du fournisseurs/revendeurs de matériel informatique ou des intégrateurs
de services. Ce délai varie de trois à quatre semaines.
Dans le cas virtuel: un serveur est créé en moins d’une heure et le fournisseur y installe ce dont le
client a besoin. Ce serveur devient opérationnel à partir du moment de la création.
Qualité de service : C’est l’aptitude d'un service à répondre adéquatement à des exigences,
explicites ou implicites, qui visent à satisfaire ses usagers. Ces exigences peuvent être liées à
plusieurs aspects d'un service : son accessibilité, sa continuité, sa disponibilité, ou sa fiabilité.
Pièce 2 :
Nous avons octroyé à chacune de ces exigences un poids révélant son importance :
- 1 pour faible importance ;
- 2 pour importance moyenne ;
- 3 pour forte importance.
Ces degrés d’importance ont été attribués suite à la lecture de nombreux articles et livres discutant
de la vision du client vis-à-vis le Cloud Computing.
Importance
3
3
1
2
1
1
2
1
3
3

Pièce 3 :
Nous avons traduit les attentes des clients citées en amont en spécifications techniques. Ces
spécifications sont les suivantes:
Disponibilité
Temps de réponse
Sécurité de l'information
RAM, CPU, espace stockage à la demande
Coût d’exploitation
Efficience énergétique
Tableau 12:Pièce 3 de la QFD
Pièce 4 :
La pièce 4 établit la relation entre les exigences du client (pièce 2) et les spécifications techniques
(pièce 3), cette relation est quantifiée par 3 chiffres:
- 1 pour une faible relation ;

- 2 pour une relation de moyenne importance ;
- 3 pour une forte relation.
3 2 3
2 3
3 1
1 3
1
3
3
1 3
3
2 3
Pièce 5 :
Nous avons calculé par la suite le poids (algébrique) de chaque spécification technique, en
multipliant la relation (pièce 3) par l'importance (pièce 1) de chaque exigence. Le facteur
d’importance désigne la somme retenue pour chaque spécification.
Facteur d’importance algébrique 23 15 34 10 3 4


Pièce 6 :
La pièce indique comment une spécification technique influence une autre:

 - pour une influence positive ;
 + Pour une influence négative.
Figure 62: Pièce 6 de la QFD
Les différentes pièces combinées donnent naissance à la maison qualité.
Figure 63: Maison qualité
En conclusion, nous remarquons que la sécurité de l’information, la disponibilité ainsi que le temps
de réponse restent les éléments les plus sollicités par les entreprises clientes. Du coup, une attention
particulière doit être prêtée, dans le marketing de la solution Cloud, à ces deux aspects.

Dans ce sens, ce sont les deux équipes sécurité et réseaux qui seront responsables de la qualité de la
politique marketing du Cloud en fournissant tous les éléments de réponse aux clients.
Un éléments et pas des moindres permet de mieux positionner le Cloud Computing, comme étant un
modèle à attitude écologiquement responsable, bénéfique à plus d’un sens.
La multiplication des serveurs et des données stockées quotidiennement mettent les serveurs en
challenge. La moindre donnée implique un espace de stockage supplémentaire et donc une ample
utilisation énergétique pour l’écriture, l’enregistrement, la gestion et le refroidissement.
Pour toute entreprise responsable, le Cloud permet selon plusieurs analystes l’optimisation
opérationnelle et énergétique. Choses qui impactent positivement les émissions à effet de serre.
C’est ainsi que, et depuis moins de 5ans, les professionnels du secteur IT ont commencé à penser
Green IT.
Suivront quelques lignes explicatives de l’impact écologique du Cloud Computing.
II. Impact écologique du Cloud Computing
Le Cloud Computing peut générer d’importantes économies d’énergie et de gaz à effet de serre
(GES) partout dans le monde. Il n’est plus à prouver que les différentes offres et services
disponibles suivant le modèle Cloud permettent d’économiser les coûts, d’améliorer l’efficacité et
d’augmenter la flexibilité du business process tout en réduisant les émissions de carbones liées aux
activités informatiques.
Prenant l’exemple des Etats-Unis, les entreprises passant au 100% Cloud pourraient économiser à
hauteur de 12.3 milliards de dollars, l’équivalent de 9 milliards d’euros et réduire de manière
considérable leurs émissions de CO2.
D’après le Carbon Disclosure Project, organisation à but non lucratif de laquelle émane nombre de
rapport sur la responsabilité environnementale des entreprises, cette diminution des dépenses
correspond à l’équivalent de 200 millions de barils de pétrole, soit l’alimentation en essence de 6
millions de véhicules par an!
Son double impact tant sur l’efficacité et la performance des entreprises ainsi que sur
l’environnement, font du Cloud Computing la priorité n°1 en matière d’investissements IT, d’après
Gartner, et deviendra très certainement une part importante de la démarche RSE des entreprises,
PME comme multinationales. Si ces entreprises ne l’ont pas encore adopté, aux vues de la demande
énergétique croissante, des préoccupations environnementales, ne tarderont pas à passer à l’acte.

Figure 64: Cloud Computing et Green IT
Cette infographie fournit quelques explications sur les mécanismes par lesquels le Cloud
Computing participe à l’écologie et au développement durable.
Si le caractère « green » du Cloud Computing n’est pas le premier facteur de succès de ce marché, il
n’en demeure pas moins intéressant de savoir qu’en adoptant ces technologies, chacun participe à la
[lente] évolution des usages vers des modes de consommation plus écologiques.
Bien que le Cloud Computing n’ait pas été pensé dans un but écologique - il est avant tout là pour
favoriser une réduction des coûts -, ce nouveau modèle de services a déjà fait ses preuves en matière
d’écologie, et c’est le partage des ressources qui est à l’origine de son image éco-friendly. En effet,
en évitant d’utiliser des serveurs qui leur seraient propres, les entreprises peuvent réduire leurs
dépenses en énergie électrique et ainsi contribuer la réduction de consommation énergétique
globale. Le Cloud Computing semble donc limiter l’impact écologique des entreprises, qualifiées
alors de « citoyennes ».

Conclusion générale
Pour conclure, nous pouvons dire que nous avons pu répondre aux exigences citées dans le cahier
des charges sur lequel on s’est mis d’accord avec les encadrants externes, et ce dans les délais
souhaités. En effet, nous avons opté, en concordance avec les objectifs de l’entreprise d’incubation
(CBI), pour une étude ayant pour objet le Cloud Computing. Cela nous a amené à considérer des
aspects purement théoriques comme d’autres spécifiquement pratiques.
Pendant cette période de stage, nous avons démarré notre travail par des recherches poussées sur un
domaine qui n’est qu’à ses débuts en opérant une étude théorique sur le Cloud Computing. De fil en
aiguille, et d’articles à rapports, nous avons pu nous forger une idée sérieuse sur les différentes
offres qui existent sur le marché grâce à un benchmark des solutions de Cloud Computing.
Ceci étant fait, il a fallu à un certain moment voir comment concordaient nos recherches avec les
réalités de l’entreprise d’incubation et de son écosystème. Nous avons ainsi, en collaboration avec
nos encadrants d’entreprise, pu déterminer un bilan de l’existant dénommé « étude de l’existant ».
Suite à quoi, nous avons pu tracer une cartographie et faire le lien avec l’offre du marché et l’offre
de la CBI qui sont corrélées positivement. L’étude du modèle de service Cloud choisi nous a permis
d’approfondir nos connaissances comme de délimiter le champ de notre search desk.
Une fois le choix arrêté, nous avons démarré le traitement de la partie stockage vu la sensibilité que
cela comporte pour tout organisme optant pour le Cloud Computing. Une deuxième question non
négligée a fait surface et est relative à la maitrise des enjeux sécuritaires. Ce deuxième aspect est
l’un des plus sensibles vu qu’un malentendu de sécurité peut mettre en péril la totalité de
l’innovation comprise dans ce nouveau mode de gouvernance de l’information.
Ces deux aspects étant bien cernés, nous avons enchaîné avec la discussion dans la partie réseau des
différents types de liens pour lier les clients au système Cloud. Autant l’approche est nouvelle,
autant les recommandations sont différentes selon les applications. Mais ce challenge ne nous a pas
privées de l’installation des modules de virtualisation sur des serveurs, dans le total respect des
normes de sécurité et de confiance numérique de la CBI.
Ces différents aspects cités ci-haut nous ont permis de tracer une architecture complète de
l’infrastructure du Cloud Computing.
Gardant le meilleur pour la fin, et en vue de joindre l’efficacité opérationnelle à l’efficience

rationnelle et responsable, nous avons fait des recherches et débattu le phénomène du Green IT. En
effet, un des résultats immédiats de l’adoption du Cloud Computing est la minimalisation de la
consommation électrique et donc la diminution de l’émission des éléments carbones dans l’air. Le
Cloud Computing est imaginé dans son idéal comme voute de secours à notre planète qui pâtit des
effets de serre et du réchauffement climatique.

Enfin, nous pouvons dire que les efforts du corps professoral et enseignant de l’école Hassania
visant à inculquer l’esprit d’initiative, de polyvalence et de travail en équipe aux élèves ingénieurs
n’ont pas été vains et les personnes que nous sommes devenues aujourd’hui en est la preuve.

Annexe A : Commutation WAN-MPLS
L’échange de flux entre le réseau local d’entreprise (ou l’un de ses sites multiples) et son centre de
données nécessite un passage par le réseau étendu de l’opérateur en plus du réseau d’accès, en
raison de la distance les séparant. MPLS s’avérant la solution ultime pour offrir des services de
VPN ou encore de QoS, devenus indispensables aux applications d’entreprises multi-sites (VoIP,
visioconférence, vidéosurveillance et applications transactionnelles), la majorité des opérateurs ont
migré leurs cœurs de réseau vers MPLS, il y a quelques années.
1. Définition
MPLS (Multi Protocol Label Switching) est un mécanisme proposé par l’IETF (Internet
Engineering Task Force) dans la RFC 3031. L’idée de l’IETF a été de proposer une norme
commune pour transporter des paquets IP sur des sous-réseaux travaillant en mode commuté. Les
nœuds sont des routeurs-commutateurs capables de remonter soit au niveau IP pour effectuer un
routage, soit au niveau trame pour effectuer une commutation.
Comme son acronyme l'indique, ses caractéristiques sont :
 multiprotocol (multi-protocoles) : il est capable de supporter les différents protocoles de
niveau inférieur, au sens OSI (PPP, ATM, Ethernet, Frame Relay...).
 label switching (commutation par étiquettes) : il se base sur une étiquette (en anglais : label)
pour la commutation des paquets.
1. La commutation de niveau trame
L’objectif d’une commutation de niveau trame est d’améliorer les performances de la commutation
de niveau paquet, en diminuant le nombre de niveaux de l’architecture à traverser à chaque nœud du
réseau de transport. En plaçant la commutation au niveau trame de l’architecture, la trame ne doit
pas obligatoirement être décapsulée pour retrouver le paquet.
En effet, dans les réseaux IP traditionnels, le routage des paquets s'effectue en fonction de l'adresse
de destination contenue dans l'entête de niveau 3. Chaque routeur attend de recevoir correctement
une trame, avec des retransmissions potentielles, et pour déterminer le prochain saut (next-hop),
décapsule la trame, consulte sa table de routage et détermine l'interface de sortie vers laquelle
envoyer le paquet. Le mécanisme de recherche dans la table de routage est consommateur de temps
CPU, et avec la croissance de la taille des réseaux ces dernières années, les tables de routage des
routeurs ont constamment augmenté. Il était donc nécessaire de trouver une méthode plus efficace
pour le routage des paquets.
2. Objectifs et missions de MPLS :
Le but de MPLS était à l'origine de donner aux routeurs IP une plus grande puissance de
commutation, en basant la décision de routage sur une information de label (ou tag) inséré entre les
entêtes de niveau 2 (couche liaison de données) et de niveau 3 (couche réseau), d’où sa qualification
de protocole de couche 2,5. La transmission des paquets est ainsi réalisée en commutant les paquets
en fonction du label, sans avoir à consulter l'entête de niveau 3 et la table de routage.
Toutefois, avec le développement de techniques de commutation comme CEF (Cisco Express
Forwarding) et la mise au point de nouveaux ASIC (Application Specific Integrated Circuits), les
routeurs IP ont vu leurs performances améliorées sans le recours à MPLS. Depuis, l'aspect
"fonctionnalité" a largement pris le dessus sur l'aspect "performance", avec notamment les
motivations suivantes :

 Intégration IP/ATM
 Routage multicast
 Flexibilité : MPLS n'étant pas lié à une technique de niveau 2 particulière, il peut être
déployé sur des infrastructures hétérogènes (Ethernet, ATM, SDH, etc.)
 Traffic Engineering : l’orientation du trafic en fonction de l’état du réseau.
 QoS : Qualité de service
MPLS peut donc être considéré comme une interface apportant à IP le mode connecté et qui utilise
les services de niveau 2.
3. Fonctionnement de MPLS :
La transmission des données s’effectue sur des chemins nommés LSPs (Label Switched Paths). Un
LSP est une suite de références partant du nœud à l’entrée du nuage MPLS, et allant jusqu’au nœud
de sortie du nuage.
A la frontière d’un domaine MPLS, le paquet IP est pris en charge par un routeur (LER-Label Edge
Router) à qui il ajoute (en entrée) ou retire (en sortie) un label. Les paquets sont ensuite commutés
par des routeurs MPLS (LSR-Label Switch Router) qui ont la possibilité de modifier les labels.
Fonctionnement de MPLS
 Emplacement du label
Un label a une signification locale entre 2 LSRs adjacents et mappe le flux de trafic entre le LSR
amont et la LSR aval. A chaque bond le long du LSP, un label est utilisé pour chercher les
informations de routage (next hop, lien de sortie, encapsulation, queueing et scheduling) et les
actions à réaliser sur le label : insérer, changer ou retirer. La figure ci dessous, décrit la mise en
œuvre des labels dans les différentes technologies ATM, Frame Relay, PPP, Ethernet et HDLC.
Pour les réseaux Ethernet, un champ appelé shim a été introduit entre la couche 2 et la couche 3.
Sur 32 bits, il a une signification d'identificateur local d'une FEC. 20 bits contiennent le label, un
champ de 3 bits appelé Classe of Service (CoS) sert actuellement pour la QoS, un bit S pour
indiquer s'il y a empilement de labels et un dernier champ, le TTL sur 8 bits (même signification
que pour IP). L'empilement des labels permet en particulier d'associer plusieurs contrats de service à
un flux au cours de sa traversée du réseau MPLS.

Format du label MPLS
Label: Numéro/valeur du label.

Exp (experimental): correspond au champ CoS (Class of Service) sert actuellement pour la QoS.
S (stack): indique s’il y a empilement de labels.
TTL (Time To Live): est décrémenté de 1 par les LSRs afin d’éviter les boucles infinies. En entrée
d’un LSP, le LER copie de TTL du paquet IP et inversement en sortie.
 FEC (Forwarding Equivalency Classes)
Dans MPLS, le routage s’effectue par l’intermédiaire de classes d’équivalence, appelées FEC. Une
FEC représente un flot ou un ensemble de flots ayant les mêmes propriétés.
Toutes les trames d’une FEC sont traitées de la même manière dans les nœuds du réseau MPLS. Les
trames sont introduites dans une FEC au nœud d’entrée et ne peuvent plus être distinguées des
autres flots à l’intérieur de la classe.
Une FEC peut être bâtie de différentes façons. Elle peut avoir une adresse de destination bien
déterminée, un même préfixe d’adresse IP, une même classe de service, etc. Chaque LSR possède
une table de commutation qui indique les références associées aux FEC. Toutes les trames d’une
même FEC sont transmises sur la même interface de sortie. Cette table de commutation, constituée
par LDP, est appelée LIB (Label Information Base).
Une fois le paquet classifié dans une FEC, une référence est assignée à la trame qui va le
transporter.
Dans le cas des trames classiques, comme LAP-F du relais de trames ou ATM, la référence est
positionnée dans le DLCI ou dans le VPI/VCI.
La signalisation nécessaire pour déposer la valeur des références le long du chemin déterminé pour
une FEC peut être gérée soit à chaque flot (data driven), soit par un environnement de contrôle
indépendant des flots utilisateur (control driven). Cette dernière solution est préférable dans le cas
de grands réseaux du fait de ses capacités de passage à l’échelle.
4. Architecture MPLS :
Architecture MPLS
MPLS normalise plusieurs méthodes pour réaliser la distribution des références. La distribution
indique que chaque nœud possède ses propres références et qu’il doit les mettre en correspondance
avec les références de ses voisins.
Deux sortes de protocoles sont utilisées à cette fin : un protocole de routage et un autre de
signalisation.
 Protocoles de routage :
Le protocole de routage dissémine les informations relatives à la topologie du réseau pour que la
route d’un LSP puisse être calculée automatiquement. L’IGP utilisé normalement est OSPF ou IS-
IS, quand le nuage MPLS appartient au même AS.
Cependant, ces protocoles de routage ne font que distribuer les informations de topologie du réseau.
Quand on a besoin d’effectuer de l’ingénierie de trafic pour l’établissement de LSPs avec des
caractéristiques de QoS garanties, des extensions de ces protocoles sont utilisés. On retrouve le
OSPF-TE ainsi que le IS-IS-TE.
 Protocoles de signalisation :
Le protocole de signalisation informe les commutateurs au long de la route des labels et liens à
utiliser pour chaque LSP. Cette information est utilisée pour programmer la matrice de
commutation.
Dans MPLS et selon l’application, l’un des trois protocoles suivants est utilisé :
 LDP (Label Distribution Protocol) quand l’ingénierie de trafic n’est pas requise ;
 RSVP-TE ou CR-LDP quand l’ingénierie de trafic est requise ;
 MP-BGP (MPLS Border Gateway Protocol) et ses deux variantes : MP-eBGP et MP-iBGP
dans le cas des VPN/MPLS.

5. Aspects avancés et applications
 Traffic engineering :
Définition : C’est une des applications les plus immédiates de MPLS. Par "Traffic Engineering
MPLS", il faut comprendre, établissement de connexions à la demande, gestion de trafic, gestion
des routes, gestion des ressources, gestion de l'écoulement de flux de trafic à travers un réseau IP.
C’est la possibilité de faire suivre à des paquets IP un chemin à travers le réseau ne correspondant
pas forcément au chemin que ces mêmes paquets auraient suivi s'ils avaient été routés au niveau 3
(c'est à dire à partir des informations issues du protocole de routage interne du réseau, i.e. RIP,
OSPF, IS-IS …etc). Ceci afin de mieux gérer les ressources du réseau.
Pour un opérateur, c’est une fonction cruciale qui lui permet de mieux rentabiliser son
investissement. En effet, la plupart des gros réseaux IP disposent de liens de secours en cas de
panne. Toutefois, il est assez difficile d'obtenir une répartition du trafic sur ces liens qui ne sont
traditionnellement pas utilisés, car n'étant pas sélectionnés comme chemins optimaux par l'IGP.
Le Traffic Engineering permet un meilleur emploi des liaisons, puisqu'il permet aux administrateurs
réseau d'établir des tunnels LSP à travers le backbone MPLS, grâce au routage explicite et
indépendamment de l'IGP, afin de garantir la QoS définie pour chaque FEC. Un certain nombre
d’outils sont proposés pour établir des chemins explicitement routés: CR-LDP et RSVP-TE.
En plus des contraintes de topologie utilisées par les algorithmes de routage classiques, l’algorithme
CR (Constraint Based) calcule les routes en fonction de contraintes de bande passante ou
administratives. Les chemins calculés par le protocole CR ne sont pas forcément les plus courts. De
la sorte, le trafic est distribué de manière plus uniforme sur le réseau.
Les attributs récapitulés dans tableau suivant permettent de contrôler les ressources attribuées à ces
chemins associés au LSP.
Attribut Description
Bande passante Besoins minimaux de bande passante à réserver sur le chemin du LSP
Attribut de Indique si le chemin du LSP doit être spécifié manuellement ou dynamiquement
chemin par l’algorithme CR (Constraint-Based Routing)
Priorité de Le LSP le plus prioritaire se voit allouer une ressource demandée par plusieurs
démarrage LSP.
Priorité de Indique si une ressource d’un LSP peut lui être retirée pour être attribuée à un
préemption autre LSP plus prioritaire.
Affinité ou Exprime des spécifications administratives.
couleur
Adaptabilité Indique si le chemin d’un LSP doit être modifié pour avoir un chemin optimal.
Flexibilité Indique si le LSP doit être re-routé en cas de panne sur le chemin du LSP.
Attributs des chemins LSP dans un réseau MPLS
 Qualité de service dans MPLS :
Définition : La qualité de service (QoS) est la capacité d’un réseau à véhiculer dans de bonnes
conditions un type de trafic donné, en termes de disponibilité, débit, délais de transmission, gigue,
taux de perte de paquets… Elle permet de garantir de bonnes performances aux applications
critiques pour l'organisation et d’offrir aux utilisateurs des débits et des temps de réponse
différenciés par applications suivant les protocoles mis en œuvre au niveau de la structure.

Elle permet ainsi aux fournisseurs de services (départements réseaux des entreprises, opérateurs…)
de s’engager formellement auprès de leurs clients sur les caractéristiques de transport des données
applicatives sur leurs infrastructures IP, selon des SLAs (Service Level Agreement), qui ne sont
autres que des contrats effectués entre les clients et les opérateurs, exprimant les obligations et
définissant les obligations de chacune des deux parties, et écrit dans un langage business
compréhensible ces derniers.
Ainsi, et dans une politique d’évaluation et de contrôle, l’ANRT mène régulièrement sur la base
d’échantillons significatifs, des campagnes de mesures et de relevés d’indicateurs de QoS. Ces
indicateurs visent principalement à garantir l’accessibilité du service, sa continuité, sa disponibilité
et sa fiabilité. Ils portent aussi bien sur la voix (taux d’échec, taux de coupure, taux de réussite…)
que sur les transmissions de données (taux de réception, débit de transmission, taux d’erreurs de
données…) et visent à garantir un niveau satisfaisant de la QoS aux usagers.
Dans le contexte du Cloud Computing, le backbone reliant les entreprises clientes à l’entreprise
prestataire du service, la CBI dans notre cas, la QoS est chose indispensable pour les applications
critiques à l’activité de l’organisation cliente, et sa disponibilité (ou non) est facteur déterminant
dans la migration d’un datacenter traditionnel au cloud public
Architecture pour la QoS : Contrairement à ce que l’on peut souvent lire dans la presse
spécialisée, MPLS n’est pas à proprement parler une solution pour la qualité de service dans les
réseaux IP. Par contre, il offre un certain nombre d’outils favorisant la mise en place d’une offre de
qualité de service dans un cœur de réseau IP.
L’IETF a défini deux types d'architectures pour la QoS IP :
 Integrated Services (IntServ) : suppose que pour chaque flux demandant de la QoS, les
ressources nécessaires sont réservées à chaque bond entre l'émetteur et le récepteur, via
RSVP. Intserv garantit donc de la QoS de bout en bout, mais ne convient que pour des
réseaux de taille petite/moyenne puisque le montant des informations d'état qui doivent être
stockées et traitées pour chaque flux de l’application deviendrait ingérable pour les grands
réseaux / backbones, et pour cette raison, est plutôt destiné à être implémenté à l'accès. Ce
chapitre traitant du WAN, le mode de fonctionnement du mode Intserv ne sera pas détaillé
dans ce qui suit.
Une solution plus évolutive a été proposée pour combler les limitations du mode Intserv,
elle est connue sous le nom de Diffserv.
 Differential Services (DiffServ) : est davantage destiné à être appliqué en cœur de réseau
opérateur. Les différents flux, classifiés selon des règles prédéfinies, sont agrégés selon un
nombre limité de classes de services, ce qui permet de minimiser la signalisation.
DiffServ utilse les 6 premiers bits du champ TOS de l'entête IP afin de classifier le trafic
dans des classes ou contrats au niveau de l'Ingress-LSR. Ce champ s'appellera DS-Field
dans DiffServ (Voir figures ci-dessus). Au niveau des LSRs, DiffServ définit des PHBs (Per
Hop Behaviors) afin de construire ces LSPs. Ainsi au niveau des Edge LSRs, DiffServ
utilise le champ DS-Field, et à l'intérieur du corps MPLS, il invoque les PHBs.

Diffser dans le paquet IP
Ayant discuté de MPLS et de Diffserv, il est facile d’identifier les similarités que présentent les
deux approches :
 Les deux approches poussent la complexité à l’extrémité du réseau. Concernant Diffserv, la

classification et le conditionnement sont effectués à l’extrémité pendant que les nœuds du
backbone s’occupent de la transmission. Idem pour MPLS, la classification des FECs est
réalisée à l’extrémité. Une fois le label assigné, les nœuds du backbone transmettent les
paquets en se basant sur les labels. Ce comportement procure évolutivité et rend
l’architecture appropriée aux réseaux de backbones.
 Les deux technologies utilisent des labels à granularité faible et fixée; MPLS utilise les
étiquettes pour le transfert et l’implémentation des opérations de l’ingénierie de trafic, alors
que Diffserv utilise DSCP pour fournir de la QoS.
 Bénéfices de Diffserv au dessus de MPLS
MPLS et Diffserv sont deux technologies orthogonales et complémentaires. Le mariage de ces deux
derniers peut aboutir à plusieurs avantages tels que :
 Les flux pouvant être isolés à l’aide des LSPs/MPLS, ceci peut compléter la QoS procurée
par les mécanismes de Diffserv QoS.
 La protection dans MPLS renforce les garanties de QoS, ce qui permet aux Fournisseurs
d’Accès Internet de facturer lourdement des frais supplémentaires.
 La préemption dans MPLS peut être utilisée de façon similaire pour donner une haute
priorité aux clients les plus payants ou encore au trafic critique.
 D’autre part, la protection et la préemption ajoutent une granularité plus fine de QoS à
Diffserv.
 Fonctionnement de Diffserv au dessus de MPLS :

Le label de Diffserv, i.e le DSCP, est inclus dans le champ TOS de l’entête IP. Par ailleurs, le label
de MPLS est contenu dans le champ shim ou encapsulé dans l’entête de niveau 2. Et puisque le
LSR n’examine pas l’entête IP pendant la transmission des paquets, un mécanisme qui détermine le
PHB à partir du label MPLS est nécessaire. Deux sortes de LSPs sont définies pour résoudre ce
problème:
 E-LSP, pour lesquels les différentes qualités de service sont différenciées en fonction du
champ expérimental (EXP) de l’entête MPLS (shim).
 L-LSP, pour lesquels la différenciation est faite en fonction du label.
Il n’y a pas de protocole de signalisation spécifique pour la qualité de service. Les informations
nécessaires peuvent être transportées par CR-LDP et RSVP-TE, et éventuellement par LDP, si
l’établissement de LSP spécifique pour chaque classe de service DiffServ est automatique. Ces
protocoles qui signalent les informations de qualité de service au moment de l’établissement des
chemins travailleront en collaboration avec les protocoles chargés de transporter les paramètres de
configuration des équipements (COPS : Common Open Policy Service), par exemple la
signification des huit valeurs possibles du champ EXP. De toute manière, quel que soit le type
d’architecture de qualité de service utilisé dans le nuage MPLS, il va de soi que des protocoles
différents peuvent travailler conjointement sans que cela ne complique le fonctionnement de MPLS,
le seul problème étant alors d’arbitrer entre les protocoles l’accès aux ressources des équipements.
En particulier, il n’y a aucune contre-indication à utiliser LDP et BGP4 pour la distribution
automatique et RSVP-TE pour les chemins spécifiques.
 VPN (Virtual Private Network)

Actuellement, il est très courant qu'une entreprise soit constituée de plusieurs sites géographiques
(parfois très éloignés) et dont elle souhaite interconnecter les réseaux informatiques, à travers un
WAN (Wide Area Network), ces sites devant à leur tour se connecter au centre de données de
l’entreprise, lui-même pouvant en être très éloigné.
Les fournisseurs d'accès Internet disposent de backbones étendus, et couvrant la plupart du temps
une large portion de territoire. Il est donc plus simple pour une entreprise de relier ses sites aux
points de présence (POP) de l'opérateur et mettre en place une solution VPN (Virtual Private
Networks).
MPLS/VPN fournit une méthode de raccordement de sites appartenant à un ou plusieurs VPNs,
avec possibilité de recouvrement des plans d'adressage IP pour des VPN différents. En effet,
l'adressage IP privé est très employé aujourd'hui, et rien ne s'oppose à ce que plusieurs entreprises
utilisent les mêmes plages d'adresses (par exemple 172.16.1.0/24). MPLS/VPN permet d'isoler le
trafic entre sites n'appartenant pas au même VPN, et en étant totalement transparent pour ces sites
entre eux. Cette solution sera adaptée pour permettre à deux ou plusieurs entreprises clientes l’accès
à leurs centres de données distants avec étanchéité et sécurité.
 Routeurs virtuels (VRFs) :
La notion même de VPN implique l'isolation du trafic entre sites clients n'appartenant pas aux
mêmes VPNs. Pour réaliser cette séparation, les LERs ont la capacité de gérer plusieurs tables de
routage grâce à la notion de VRF (VPN Routing and Forwarding). Une VRF est constituée d'une
table de routage, d'une FIB (Forwarding Information Base) et d'une table CEF (Cisco Express
Forwarding) spécifiques, indépendantes des autres VRFs et de la table de routage globale. Chaque

VRF est désignée par un nom (par ex. RED, GREEN, etc.) sur les routeurs PE. Les noms sont
affectés localement, et n'ont aucune signification vis-à-vis des autres routeurs. Chaque interface de
PE reliée à un site client est rattachée à une VRF particulière. Lors de la réception de paquets IP sur
une interface client, le LER procède à un examen de la table de routage de la VRF à laquelle est
rattachée l'interface, et donc ne consulte pas sa table de routage globale. Cette possibilité d'utiliser
plusieurs tables de routage indépendantes permet de gérer un plan d'adressage par sites, même en
cas de recouvrement d'adresses entre VPNs différents.
Les informations de routage à l'intérieur d'un VPN sont distribuées de la manière suivante :
 du site client vers le VBG (VPN Border Gateway) source : via RIP, OSPF ou en routage
statique
 au niveau du VBG source : exportation vers BGP
 entre VBG source et VBG destination : via BGP
 au niveau du VBG destination : importation à partir de BGP
 du VBG destination vers le site client : via RIP, OSPF ou en routage statique
Routage VPN/MPLS
Le VBG source applique 2 labels au paquet de data lorsqu'un VPN est utilisé :
o le premier label (extérieur) identifie le chemin vers le VBG destination, et change à chaque
bond
o le second label (intérieur) spécifie le VPN-ID attribué au VPN et n'est pas modifié entre le
VBG source et le VBG destination
Cette paire de labels permet d'implémenter aisément les mécanismes des VPNs dans MPLS:

Annexe B : Commutateur Nexus1000V
Cisco propose la solution Cisco Nexus1000V, c’est une appliance réseau virtuelle qui s’intègre au
sein du Datacenter virtuel.
Le schéma ci-dessus illustre le principe de fonctionnement du Nexus1000V.
En effet il se compose de :
 VSM (Virtual Supervisor Module)

 VEM (Virtual Ethernet Module)
Ces deux composants fonctionnent de manière complémentaire ;VEM qui est intégré dans les
différents hôtes ESX/ESXi représente l’ensemble des ports virtuels, et le VSM qui est installé sur le
vCenter permet de gérer ces ports. Il peut gérer jusqu’à 64 VEM, et le tout peut être administré via
une interface en ligne de commande (CLI).
En cas de panne du vCenter par exemple, le Switch Nexus1000V continuera de fonctionner mais
n’autorisera pas de modifications de configuration.
 Possibilité de déléguer l'administration réseau aux équipes dédiées ;

 L'ajout de fonctionnalités réseau évoluées d'analyse et de sécurité telles que l'Encapsulated
Remote SPAN (ERSPAN) permettant l'analyse et le monitoring du trafic réseau, ou encore
NetFlow Analyser qui est un outil Web de surveillance de la bande passante, d'analyse
scientifique du réseau et d'analyse du trafic réseau ;
 Il simplifie la gestion en étant reconnu comme un Switch réseau au même titre qu’un Switch
physique ;
 Filtrage par liste d'accès permettant de lister les adresses et ports autorisés ou interdits ;
 Qualité de service (QoS) basée sur le type de service(ToS).

Annexe C : EMC VNX 5300
La famille EMC propose La gamme VNX qui comprend une plateforme robuste de consolidation
du stockage par blocs, du stockage d’applications à connexion directe et des serveurs de fichiers, les
entreprises peuvent ainsi développer, partager et gérer à moindre coût l’accès au stockage en mode
bloc et les systèmes de fichiers multi-protocoles.
Il est compatible avec les connectivités iSCSI, FC et FCoE. Ces connectivités sont conçues pour les
applications de type bloc consommatrices de bande Passante ou ne tolérant pas les temps de latence.
Aussi l’environnement d’exploitation VNX permet-il aux clients Microsoft Windows et

Linux/UNIX de partager des fichiers dans des systèmes multi-protocoles (NFS, CIFS) :
 NFS (Network File System) est un protocole qui permet à un ordinateur d'accéder à des
fichiers via un réseau. Il fait partie de la couche application du modèle OSI et il est
compatible avec IPv6.
 CIFS (Common Internet File System) communément appelé SMB (Server Message Block),
c’est un protocole permettant le partage de ressources (fichiers et imprimantes) sur des réseaux
locaux avec des PC sous Windows.
La gamme VNX prend en charge le stockage basé sur les objets (REST, SOAP, XAM) et permet
aux utilisateurs de gérer leurs applications Web via EMC Unisphere.
 REST (Representational State Transfer) est un style d'architecture qui permet de concevoir
des applications ou des services Web, utilisant les standards URL pour adresser les
ressources, HTTP pour fournir toutes les opérations nécessaires et des liens hypermédia
(HTML et XML) pour représenter le contenu des informations.
 SOAP (Simple Object Access Protocol) est un protocole de transmission de messages.
 XAM (eXtensible Access Method) qui vise à garantir la pérennité d’une donnée en la
rendant indépendante du matériel sur lequel elle s’appuie.

Bibliographie
Les réseaux, Guy PUJOLLE, Eyrolles édition 2011
Réseaux d’entreprise par la pratique, Jean-Luc MONTAGNIER,Eyrolles édition
Guide d’installation et de configuration de vCloud Director
Guide de l’utilisateur vCloud Director
Architecting VMware vCloud

Webographie
www.cbi.ma/
www.vmware.com
www.citrix.fr
www.cisco.com
www.emc.com
social.technet.microsoft.com/Forums/fr-FR/howtoforumfr/thread/a4343172-f3e2-4530-a591-
89f7f97f3b09
www.vitualyzation.com
www.01net.com
www.wikipedia.com
www.youtube.com
www.slideshare.net
www.definelthecloud.net
www.cloudmagazine.fr
www.cloudconsulting.fr
www.codekf.org/img/pdf/codekf-confere-2007.pdf
www.journaldunet.com/solutions/expert/24009/la-virtualisation---huit-approches-passees-au-
crible.shtml
www.wygwam.com/documents/cloud-computing.pdf
www.mplstutorial.com
www.frameip.com
www.networktechnologies.metaswitch.com

Rapport Finale

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Finale

Transféré par

Droits d'auteur :

Formats disponibles

MEMOIRE DU PROJET DE FIN D’ETUDES

Département GENIE ELECTRIQUE

 M. Mohamed EL AROUSSI (EHTP)

Année Universitaire 2011 – 2012

Mémoire de fin d’études 2011-2012 Page 1

A l’issue de ce travail, je tiens à le dédier:

Khadija OULAD BENTAIB

Mémoire de fin d’études 2011-2012 Page 2

Mémoire de fin d’études 2011-2012 Page 3

Au préalable et comme témoignage de notre profonde reconnaissance, nous tenons à

Nous tenons ainsi à exprimer notre gratitude à :

M. DINOURI pour nous avoir accueillies au sein de son département, et pour

M. Wassil MERAD, et M. Yassine MOUNIR, encadrants externes, pour nous

M. Abdelmajid JAAFAR, et M. Mohamed BOUATHMANI pour l’aide qu’ils

Nos remerciements s’adressent également à tous les membres du personnel de la CBI

Nous saurons gré à M. Mohamed EL AROUSSI, professeur assistant LETI à l’EHTP,

A ces remerciements nous souhaitons associer tout le corps professoral et

Mémoire de fin d’études 2011-2012 Page 4

Mémoire de fin d’études 2011-2012 Page 5

Mémoire de fin d’études 2011-2012 Page 7

Mémoire de fin d’études 2011-2012 Page 8

Mémoire de fin d’études 2011-2012 Page 9

Mémoire de fin d’études 2011-2012 Page 10

Mémoire de fin d’études 2011-2012 Page 11

Mémoire de fin d’études 2011-2012 Page 12

La perspective du fournisseur comprend les différents aspects techniques de gestion, de

Mémoire de fin d’études 2011-2012 Page 13

Mémoire de fin d’études 2011-2012 Page 14

I. Présentation de l’organisme d’accueil

Un certain nombre de dates clés jalonnent l’histoire de CBI :

Figure 1: Dates importantes pour la CBI

Mémoire de fin d’études 2011-2012 Page 15

Figure 2: Organigramme de la CBI

Mémoire de fin d’études 2011-2012 Page 16

6 agences nationales et 1 succursale en Afrique de l’ouest

Mémoire de fin d’études 2011-2012 Page 17

Figure 3: Clients CBI

Figure 4: Fournisseurs CBI

Mémoire de fin d’études 2011-2012 Page 18

Figure 5: Fiche signalétique CBI

Figure 6: Métiers CBI

Mémoire de fin d’études 2011-2012 Page 19

 Télécommunications : Cette activité est constituée essentiellement de systèmes de

 Intégration systèmes: Les principaux pôles de cette activité sont:

 Consulting en architecture de systèmes d’information en intégration de solutions applicatives ;

Mémoire de fin d’études 2011-2012 Page 20

Ce projet de fin d’études s’inscrit dans ce sens, et a comme problématique :

« Implémentation d’une solution clé en main du modèle IaaS (Infrastructure as a Service)

2.2.Caractéristiques du Cloud Computing

Accès universel via le réseau

Mémoire de fin d’études 2011-2012 Page 21

Service mesurable et facturable

2.3.Modèles du service Cloud Computing

 IaaS (Infrastructre as a Service)

Il s’agit de la mise à disposition, à la demande du client, de ressources d’infrastructure dont la plus

 PaaS (Plateforme as a Service)

Il s’agit de la mise à disposition, à la demande du client, d’une plate-forme d’exécution, de

Mémoire de fin d’études 2011-2012 Page 22

 SaaS (Software as a Service)

L’utilisation reste transparente pour les utilisateurs, qui ne se soucient ni de la plateforme, ni du

Figure 7: Modèles du service Cloud Computing

2.4.Modèles de déploiement du service Cloud Computing

1.1.1 Cloud privé

Mémoire de fin d’études 2011-2012 Page 23