Dédicace: A Mes Grands-Parents Mongia Et Hamadi

Dédicace
“ Je dédie ce travail,
A mes grands-parents Mongia et Hamadi

Ils m’ont vu naître et auraient bien voulu applaudir cette
étape de ma vie, comme ils l’auraient souhaitée. Dans leur
silence éternel par la volonté de Dieu, qu’ils reposent en
paix !
A ma fille Roudaina
Pour leur patience, leurs encouragements et tout l’amour
qu’ils me donnent. Roudaina, j’espère que tu seras fière de
ton papa et que tu feras beaucoup mieux dans ta vie
A toute ma famille et à ma Belle Famille
Mes beaux-parents et toute la famille élargie pour leur
affection.
Veuillez trouver tous dans ce travail le témoignage de toute
ma reconnaissance et de toute ma gratitude pour votre
disponibilité sans faille, votre soutien toujours renouvelé et
l’affection permanente dont vous m’avez toujours entourée.
A vous tous je pèse mes caractères : M.E.R.C.I.
”
- HOSNI
I
Remerciements
Je tiens à manifester ma plus grande gratitude envers tous ceux qui de loin ou de près
ont accordé leur temps précieux à ce travail.
Toute ma reconnaissance à mon Encadreur de Master, Mr. Sofien Mhatli, qui n’a
épargné aucun effort pour m’orienter et guider mes pas. Ses précieux conseils et la rigueur
scientifique exigée dont il a profondément le souci, ont été pour beaucoup dans mes tra-
vaux.
Mes vifs remerciements vont également à Dr. Nejib Khalfaoui, pour le temps pré-
cieux qu’elle m’a consacré, durant ces années, pour l’élaboration de ce travail. Ses conseils
permanents et judicieux, ses encouragements incessants et constants, ses remarques per-
tinentes et enrichissantes ainsi que sa confiance sans faille ont été pour moi d’un recours
inestimable et d’un appui sans égal.
A Messieurs les membres du jury qui m’ont fait l’honneur d’évaluer ce travail et lui ont
accordé une attention critique dont j’apprécie la pertinence, la profondeur et la portée, je
leur exprime très respectueusement ma reconnaissance.
Je souhaite également remercier très chaleureusement mes collègues et amis et en

particulier pour leurs soutiens, leurs disponibilités et leurs encouragements.
II
Résumé
Mots clés : .
III
Abstract
Keywords : .
IV
Table des matières
Dédicace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV
Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Contexte général et spécification des besoins . . . . . . . . . . . . . . . . 3

1.1 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Présentation du CRDA Jendouba . . . . . . . . . . . . . . . . . . 4
1.1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . 4
1.1.3 Description du département informatique de la CRDA . . . . . . . 5
1.1.4 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.5 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Composantes du data Center CRDA . . . . . . . . . . . . . . . . . 7
1.2.2 Les solutions Applicatives . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3 Adressage IP sites distants . . . . . . . . . . . . . . . . . . . . . . 8
1.2.4 Design de la virtualisation . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 Configuration RAID . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.6 Design de la capacité et de la répartition des machines virtuelles . . 9
1.2.7 Paramètres IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.8 Spécification des besoins et études préliminaire . . . . . . . . . . . 10
1.2.9 Projet à réaliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.10 Recueil des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 La virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Mécanisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Réseau virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Concepts et définitions du Cloud Computing . . . . . . . . . . . . . . . . . 18
2.3.1 Définitions et généralités . . . . . . . . . . . . . . . . . . . . . . . 18
V
Table des matières
2.3.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.4 Les catégories des services . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Les modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Le Cloud public . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.2 Le Cloud privé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.3 Le Cloud hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Les avantages et les inconvénients du Cloud . . . . . . . . . . . . . . . . . 23
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Processus de développement Et méthodologie . . . . . . . . . . . . . . . 24

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Le modèle sashimi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Présentation IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 Etude comparative des solutions . . . . . . . . . . . . . . . . . . . 28
3.3.3 Etude comparatif des Hyper viseurs . . . . . . . . . . . . . . . . . 31
3.3.4 Choix de l’hyper viseur . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.5 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Conception de l’infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Environnement du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Choix technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Étapes de déploiement et de configuration de l’appliance vCenter
Server 5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.3 Migration du Data center vers le Cloud . . . . . . . . . . . . . . . . 43
4.2.4 Configuration de plateforme Amazon . . . . . . . . . . . . . . . . 44
4.3 Gestion de bucket sur Amazon S3 . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1 Définition de bucket . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.2 Création d’un Bucket . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.3 Copie d’objets dans le même compte Amazon S3 . . . . . . . . . . 47
4.4 La migration avec CLOUDENDURE . . . . . . . . . . . . . . . . . . . . . 48
4.4.1 Tester le lancement . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 Serveur de migration de Service . . . . . . . . . . . . . . . . . . . . . . . . 53
4.5.1 Installation du connecteur de migration de serveur . . . . . . . . . 53
4.5.2 Configuration du connecteur . . . . . . . . . . . . . . . . . . . . . 53
4.5.3 processus de migration lui-même et comment AWS SMS le gère . . 55
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Sécurité de la Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 Sécurité Data Center du CRDA . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.1 Comment garantir la sécurité d’un datacenter ? . . . . . . . . . . . 60
5.2.2 La Solution Firewall du CRDA Jendouba . . . . . . . . . . . . . . 60
VI
Table des matières
5.3 Configurer le pare-feu Sophos sur site . . . . . . . . . . . . . . . . . . . . . 61

5.4 WAF :web Application Filtring . . . . . . . . . . . . . . . . . . . . . . . . 64
5.5 Sécurité de l’infrastructure AWS avec data center . . . . . . . . . . . . . . 65
Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
VII
Table des figures
1.1 Organigramme globale de CRDA . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Architecture du Data Center de CRDA Jendouba . . . . . . . . . . . . . . 7
2.1 Comparaison entre architecture physique et virtualisée . . . . . . . . . . . 15

2.2 Hyper viseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Machine virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Infrastructure virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Concept du réseau virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Les services de Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Prestataires de Cloud selon les catégories des services . . . . . . . . . . . . 22
3.1 Modèle Sashim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Utilisation des solutions open source . . . . . . . . . . . . . . . . . . . . . 30
3.3 Architecture global du CRDA Jendouba . . . . . . . . . . . . . . . . . . . 32
3.4 Relations entre les couches de composants de VMware vSphere . . . . . . . 33
3.5 VMware ESXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Mware vSphere Web Client . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7 VMware vCenter Serve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8 vSphere vMotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9 VSphere Storage vMotion . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.10 vSphere High Availability (HA) . . . . . . . . . . . . . . . . . . . . . . . . 37
3.11 vSphere Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 VMware vCenter Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Paramétrage Vcenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Connexion Vmaware Vcenter . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4 Notre plateforme de virtualisation . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Assistant d’ajout d’un hôte . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6 Liste des serveurs ESXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7 Liste des Serveurs du data Center . . . . . . . . . . . . . . . . . . . . . . 44
4.8 Liste des Serveurs du data Center . . . . . . . . . . . . . . . . . . . . . . 44
4.9 Interface de connexion AWS . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.10 Les services d’Amazon Web Service . . . . . . . . . . . . . . . . . . . . . . 45
4.11 Les services d’Amazon Web Service . . . . . . . . . . . . . . . . . . . . . . 46
4.12 Chargement des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.13 Role Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.14 Trust Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.15 Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
VIII
Table des figures
4.16 Interface de connexion CloudEndure . . . . . . . . . . . . . . . . . . . . . 50

4.17 Paramètre de l’installation de l’agent sur les machines source . . . . . . . . 50
4.18 Script pour l’ajout d’une machine . . . . . . . . . . . . . . . . . . . . . . . 51
4.19 Installation de l’agent cloud endure . . . . . . . . . . . . . . . . . . . . . . 51
4.20 Machine déployer dans le cloud . . . . . . . . . . . . . . . . . . . . . . . . 51
4.21 Liste des instances déployer . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.22 Accès à distance machine aws . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.23 Configuration du connecteur sms aws . . . . . . . . . . . . . . . . . . . . 53
4.24 Configuration du connecteur . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.25 Paramétrage du serveur de migration de service . . . . . . . . . . . . . . . 54
4.26 Connexion vCenter à sms connecteur . . . . . . . . . . . . . . . . . . . . . 55
4.27 Processus de migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.28 Connecteur Serveur de migration de service . . . . . . . . . . . . . . . . . 56
4.29 catalogue des serveurs du data center . . . . . . . . . . . . . . . . . . . . 56
4.30 Tache de réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.31 Serveur Héberger dans le cloud . . . . . . . . . . . . . . . . . . . . . . . . 57
4.32 Accès à la machine dans le Cloud . . . . . . . . . . . . . . . . . . . . . . . 58
5.1 Interface de Connexion Sophos . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2 Connexion VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3 CRègles Filtrants CRDA AWS IPSEC . . . . . . . . . . . . . . . . . . . . 62
5.4 Haute disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5 Synchronisation deux Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.6 Sophos Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.7 Liste des firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.8 Web Filtring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.9 Architecture connexion VPN Aws et data Center . . . . . . . . . . . . . . 66
5.10 Autoriser l’accès à l’instance déployée . . . . . . . . . . . . . . . . . . . . 66
IX
Liste des tableaux
1.1 Adressage IP sites distants . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Paramètres UCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Les capacités requises pour héberger les machines virtuelles . . . . . . . . . 10
1.4 Adresses de management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Adresses des VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Les avantages et les inconvénients du Cloud Computing . . . . . . . . . . . 23
3.1 comparaison IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Comparatif des hyper viseurs . . . . . . . . . . . . . . . . . . . . . . . . . 31
X
Introduction générale
L’énorme croissance du commerce électronique, des médias sociaux et des divers ser-
vices Web 2.0 a considérablement accru la demande de ressources de calcul. Des entreprises
comme Google, Amazon et Microsoft ont rapidement réalisé que, financièrement, il est
plus aisé de construire de très grands centres de données pour leurs besoins que de nom-
breux petits. Il est beaucoup plus rentable d’acheter des ressources comme l’électricité,
la bande passante et le stockage en grandes quantités. Dans un grand centre de données,
il devient plus facile de maximiser la quantité de travail par rapport à un coût dépensé
(partager les composants d’une manière plus efficace, améliorer la densité physique et
virtuelle des serveurs,...).
Le cloud computing est donc un nouveau moyen adapté à livrer les prestations de
service. C’est aussi un pool de ressources. On peut y stocker de très grandes quantités de
données, y trouver autant de ressources logicielles et matérielles dont on a besoin. Il offre
toute une nouvelle série de caractéristiques qui le rend attrayant. Ce nouveau paradigme
suppose que chaque composant d’une application ou d’un logiciel devient un service ou
une partie d’un service. Il offre des services à la demande, de grande capacité de calcul et
de stockage...Néanmoins, il suscite encore beaucoup d’interrogations liées à l’interopéra-
bilité, à la sécurité et à la portabilité.
Le Cloud computing, un concept en plein essor, offre une agrégation de services Cloud
assurant l’interopérabilité, la portabilité et la haute disponibilité. Le défi réside essen-
tiellement dans le partage des rôles entre les différents acteurs (Cloud provider, Cloud
broker, Network Provider, utilisateur…) vis-à-vis de l’exécution des différentes étapes de
déploiement des services.
Le verrou principal étant le déploiement des « Virtual Appliance » composées d’un

graphe de service dans un environnement de Cloud. « Virtual Appliance », un service qui
offre des applications pré-packagées, préconfigurées et encapsulées dans des images de
machines virtuelles exécutées sur des plateformes de Virtualisation. Ce type de service
permet un déploiement flexible et rapide, tout en assurant l’interopérabilité, la réutilisa-
tion, la migration des services et la non-dépendance.
L’objet de ce projet consiste à la mise en place d’une solution cloud hybride au sein de
CRDA Jendouba, en fait, le CRDA est équipé actuellement d’un data center en remise
basée sur des serveurs de types ESXI. Les services offerts par ce data center sont le sui-
vant : Voip, … Due aux coupures de certains services. Nous allons opter dans ce projet à
1
Introduction générale
proposer une solution cloud comme extension et ou backup de la solution déjà déployer
dans le data center en prémisse. Dans le but d’achever cette proposition, nous allons étu-
dier dans le premier chapitre l’architecture existante déjà déployée ainsi que ses services
offerts.
Dans le deuxième chapitre, nous allons présenter les travaux existant dans la littérature
qui traitent le problème de ..
dans le troisième chapitre, nous allons étudier et déployer une solution cloud (AWS,
Azure.) qui peut être soit une extension ou backup de la solution déjà déployé, tout en
garantissant une connexion sécurisé entre le data center et le cloud.
L’objectif de notre travail consiste à fournir des outils pour la description des services
dans un environnement Cloud, des requêtes utilisateurs et des « Virtual Appliance » tout
en s’appuyant sur le standard OVF (Open Virtualization Format) de DMTF (Distributed
Management Task Force). L’utilisation de standard permet de palier aux problèmes de
vendor lock-in, de portabilité et d’interopérabilité entre Cloud. Il est aussi question dans
cette recherche de concevoir et développer une architecture de déploiement de services
« Virtual Appliance » dans un environnement de Cloud.
2
Chapitre 1
Contexte général et spécification des

besoins
3
Chapitre 1. Contexte général et spécification des besoins
1.1 Présentation du projet
1.1.1 Présentation du CRDA Jendouba

Ce chapitre comprend deux grands éléments, je vais d’abord présenter l’organisme
d’accueil en analysant l’activité de chaque arrondissement et leur rôle dans le domaine
agricole et la région, le second concernant la présentation du projet au sein de la cellule
informatique en précisant les tâches effectuées.
1.1.2 Présentation de l’organisme d’accueil

Le Commissariat Régional au Développement Agricole (CRDA) est un établissement
public à caractère administratif doté de la personnalité morale et de l’autonomie financière
.Il est crée par la loi n°89-44 du 8 mars 1989 portant création des Commissariats Régionaux
au Développement Agricole
Le Gouvernorat de Jendouba est situé au nord-ouest de la Tunisie, il couvre une superficie
de 310000 Ha (soit 2% de la superficie du pays), cette superficie étant classé comme suit :
• 23000 Ha de terre non agricole
• 144000 Ha de plaines
• 114500Ha réservés pour les cultures pluviales
• 30000 Ha de périmètres irrigués.
Grâce a l’importance de la superficie des terres agricoles par rapports à la superficie

totale du Gouvernorat de Jendouba on a besoin à la création du Commissariat Régional
au Développement Agricole de Jendouba (CRDA), pour bien gérer et exploiter la richesse
existante dans la région.
Organigramme : La figure 1.1 illustre l’organigramme général du CRDA qui contient

cinq divisions. Chaque division comprend des arrondissements tels que chaque arrondis-
sement contient ses propres activités.
4
Fig. 1.1 : Organigramme globale de CRDA
1.1.3 Description du département informatique de la CRDA
La Direction Informatique a le rôle d’étudier, mettre en place, et maintenir des sys-

tèmes informatiques fiables (matériel et logiciel) permettant d’autoriser les procédures ad-
ministratives et techniques, développer des applications de gestion permettant d’accroître
les rendements et d’aider à la prise de décision conformément aux besoins exprimés par
l’utilisateur et par les clients.
Formation
Elle détermine les thèmes de formation qui convient aux agents du CRDA, s’engage
à faire la consultation, dépouillement et le choix du formateur juge capable selon des
caractéristiques bien déterminés et celui qui présente l’offre la moins distante.
5
Maintenance et l’entretien du matériel informatique
Préparer le cahier de charges, lance l’appel d’offres, gère le dépouillement et choisit le

moins distant.
Suivit du matériel informatique
Elle suit les matériels informatiques au sein du CRDA sur tout le territoire du gou-
verneras, suit son inventaire et la classification selon les modèles, suit l’entretien préventif
annuel, entretien pour l’installation des logiciels, suit les applications crées par la cellule
informatique.
Acquisition
Elle adresse les fiches techniques selon les dernières nouveautés sur le matériel infor-
matique, lance la consultation, gérer le dépouillement et choisit le plus performant et le
moins disant. Outils utilisés :
• Le matériel informatique du CRDA varie du modèle 486au pentium4.
• Les logiciels utilisés sont : Ressources logiciels Durant mon projet j’ai utilisé une
panoplie d’outils informatiques à savoir (VmwareESXI, VMware vSphere Client,
VMware vCenter, Windows Server 2008R2 Windows 7 Pro, Ubuntu 20.04LTE, SQL
Server 2008, OpenStack, aws, cloudendure, serveur de migration de service).
1.1.4 Présentation du projet

Ce projet est réalisé dans le cadre de notre projet de fin d’étude, il nous permet
d’exploiter les avantages du Cloud ainsi ceux de la virtualisation. Dans ce projet, nous
allons mettre en place une infrastructure virtuelle et déployer un Cloud privé CRDA
Jendouba vers Cloud public.
1.1.5 Problématique
La solution proposée doit offrir tous les outils dont le commissariat régional de dévelop-
pement agricole a besoin pour assurer le bon déroulement des tâches et la communication
inter/intra départements avec la haute disponibilité des serveurs du data center.
1.2 Critique de l’existant

Nous avons étudié en premier lieu l’architecture déjà mis en place pour pouvoir iden-
tifier les lacunes du système ainsi que l’inventaire de l’existant qui pourra être utilisé par
la suite dans ce projet Le groupe CRDA a 14 sites Distants lié au siège. La communica-
tion entre les le siège est assurée par une liaison VPN. Les sites disposent d’un « Active
6
Directory », d’un« ERP » et d’un « WORKFLOW » qui leur sont propres. La figure 1.2
illustre l’architecture du Data Center de CRDA Jendouba.
Fig. 1.2 : Architecture du Data Center de CRDA Jendouba
1.2.1 Composantes du data Center CRDA

La solution UC est composée des éléments suivants
• Deux serveurs « Cisco Unified Communications Manager » (CUCM) qui gèrent l’en-
semble des postes téléphoniques.
• Deux serveurs Cisco Unity Connection pour la messagerie vocale et le routage in-
telligent des appels
• Deux serveurs Cisco IM Presence pour la messagerie instantanée et la présence
• Une Gateway voix 2921 pour la connexion au réseau téléphonique public (PSTN)
via un Trunk SIP au Siège CRDA.
• Une Gateway voix 2921 ayant comme fonction SRST pour la connexion au réseau
téléphonique public (PSTN) via une carte FXO à Annexe CRDA.
téléphonique public (PSTN) via une carte FXO au Direction Agriculture Ghardi-
maou.
7
téléphonique public (PSTN) via une carte FXO au Direction Agriculture Bousselem.
• Des postes téléphoniques IP Cisco 3905, 7861, 8831, 8845 et9971
1.2.2 Les solutions Applicatives

• Solution Endpoint Antivirus
• Active Directory
• Mail Server
• Ftp Server
• Baie de Stockage
• Intranet
1.2.3 Adressage IP sites distants

Pour les sites distants, on a choisi d’adopter le plan d‘adressage représenté par le
tableau 1.1.
Nom du Site Addresses
Ain Drahem Foret 192.168.198.0/24
Bousselem CTV 192.168.197.0/24
Bousselem Foret 192.168.197.0/24
Centre Betrav 192.168.157.0/24
Foret Ghardimaou 192.168.194.0/24
Direction Ghardimaou 192.168.196.0/24
Fernana CTV 192.168.20.0/24
Fernana Foret 192.168.20.0/24
Souk Essebt 192.168.151.0/24
Tabarka Foret 192.168.150.0/24
Tabarka Port 192.168.149.0/24
Tabarka CTV 192.168.199.0/24
Wed MLIZ 192.168.152.0/24
Tab. 1.1 : Adressage IP sites distants
1.2.4 Design de la virtualisation

Cette section sera dédiée au design détaillé de l’environnement virtuel basé sur le
serveur UCS C220 M4 et sur l’hyper viseur VMware ESXi 5.5 qui va héberger toutes les
applications UC de la solution. Le tableau 1.2 représente la liste des paramètres UCS
8
Information UCS1 UCS2

Server Model Cisco UCS C220 M4 Cisco UCS C220 M4
CIMC Login admin Admin
CIMC Password ***** *****
Host Name UCS-UC1 UCS-UC1
CIMC IP Address 192.168.14.10 192.168.14.12
CIMC IP Mask 255.255.255.0 255.255.255.0
CIMC Gateway Address 192.168.14.254 192.168.14.254
ESXi Version 5.5 5.5
ESXi Login root Root
ESXi Password ***** *****
ESXi IP Address 192.168.14.11 192.168.14.13
ESXi IP Mask 255.255.255.0 255.255.255.0
ESXi Gateway Address 192.168.14.254 192.168.14.254
Tab. 1.2 : Paramètres UCS
1.2.5 Configuration RAID

La configuration du RAID est nécessaire dans le genre de situation ou on fait appel
à la virtualisation. Elle est très importante pour la sauvegarde des données des machines
virtuelles.
Les six disques du serveur seront configurés en RAID 10 et seront réservés pour l’instal-
lation de l’hyper viseur ESXi ainsi que les différentes machines virtuelles.
La configuration en RAID 10 des six disques donnera une capacité totale de 900 Go et
une capacité utilisable de 838 Go.
1.2.6 Design de la capacité et de la répartition des machines

virtuelles
La création de machines virtuelles sur une plateforme UCS C220 M4 doit obéir impé-
rativement aux règles de dimensionnement Cisco. En effet, Cisco publie des Template de
machines virtuelles (OVA Template qui est un format open source pour le stockage des
VM) qui correspondent à des capacités bien déterminées en termes de nombre d’utilisa-
teurs. Les machines virtuelles suivantes seront créées :
1. Deux machines virtuelles pour CUCM avec une capacité de 1000 utilisateurs.
2. Deux machines virtuelles pour IM & Presence d’une capacité de 1000 utilisateurs.
3. Deux machines virtuelles pour CUC avec une capacité de 1000 utilisateurs.
4. Deux machines virtuelles Expressway C et E pour l’accès Jabber/VisioExter.
les capacités requises pour héberger ces machines sont représentées par le tableau 1.3
9
VM vCPU vRAM (GB) vDisk (GB)

CUCM Publisher 2 8 110
IM & Presence Publisher 4 8 80
CUC Publisher 1 4 160
CUCM Subscriber 2 8 110
IM & Presence Subscriber 4 8 80
CUC Publisher Subscriber 1 4 160
Tab. 1.3 : Les capacités requises pour héberger les machines virtuelles
1.2.7 Paramètres IP
Le VLAN pour le management des différents équipements Voice sera le VLAN 14 qui
desservira le réseau 192.168.14.0/24. Ainsi, les adresses définies pour le management du
serveur UCS sont représenté par le tableau 1.4
Serveur CIMC ESXi Passerelle

UCS1 192.168.14.10 /24 192.168.14.11 /24
UCS2 192.168.14.12 /24 192.168.14.13 /24
FTP 192.168.14.240/24 192.168.14.250/24
Antivirus Eset-Endpoint 192.168.14.40/24 192.168.14.30/24
Mail Server 192.168.14.21/24
Active Directory 192.168.14.38/24
Sophos 192.168.14.254/24
Switch Server Cisco 192.168.14.2/24 192.168.14.254
Switch Server Cisco 192.168.14.77/24
Switch Accée Cisco 192.168.14.3/24
Hydrasse 192.168.15.1/24 192.168.15.254
Tab. 1.4 : Adresses de management
Le VLAN des serveurs UC sera aussi le VLAN 12 (VLAN-UC) qui aura l’adressage
192.168.12.0/24. La répartition des adresses serveurs est détaillée dans le tableau 1.5.
1.2.8 Spécification des besoins et études préliminaire

L’étude préliminaire consiste à effectuer un premier repérage des besoins fonction-
nels et opérationnels, en utilisant principalement le texte. Elle prépare les activités plus
formelles de capture des besoins fonctionnels et techniques.
10
VM Nom de l’Hôte Adressage IP Passerelle

CUCM Publisher CUCM-PUB 192.168.12.11
CUCM Subscriber CUCM-SUB 192.168.12.21
IM & Presence Publisher CIMP-PUB 192.168.12.13
IM & Presence Subscriber CIMP-SUB 192.168.12.23
192.168.12.254
CUC Publisher CUC-PUB 192.168.12.12
CUC Subscriber CUC-SUB 192.168.12.22
Expressway C EXPRESSWAY-C 192.168.12.14
Expressway E EXPRESSWAY-E 192.168.12.24
Tab. 1.5 : Adresses des VM
1.2.9 Projet à réaliser

L’objectif initial de notre projet consiste à concevoir une plateforme virtuelle pour
migrer des serveurs physiques existants dans un environnement virtuel et permettant de
réaliser le déploiement de la plateforme Cloud Computing privée vers Cloud publique c’est
le Cloud hybride.
1.2.10 Recueil des besoins

On a effectué plusieurs recherches pour identifier les besoins de la solution et ceci
afin de répondre aux attentes des utilisateurs. Les besoins se divisent en deux grandes
catégories : les besoins fonctionnels et les besoins non fonctionnels.
Besoins fonctionnels
Pour réussir la tâche du recueil des besoins fonctionnels, nous avons commencé par
interviewer les différents employés de la société selon un questionnaire semi-directif. Ces
interviews nous ont permis d’identifier les besoins fonctionnels suivants :
• La migration vers une plateforme virtuelle pour optimiser les ressources et garantir
la fiabilité du système
• La migration des serveurs physiques vers des machines virtuelles L’évolutivité de

l’infrastructure
• La continuité de l’activité
• La gestion des sauvegardes des machines virtuelles déjà installées.
• Le déploiement d’une plateforme du Cloud Computing privée pour offrir des services
à tous les sites du CRDA.
• Suggérer la meilleure architecture pour le déploiement d’OpenStack
11
Besoins non fonctionnels
• Intégration d’un outil de supervision pour toute la plateforme de virtualisation

Développer et vendre des applications Cloud.
• La création d’un module de facturation pour les clients Cloud.
1.3 Conclusion
Dans ce premier chapitre, nous avons présenté l’entreprise d’accueil à savoir le CRDA
de Jendouba. Puis, nous avons présenté le système déjà mis en place et nous avons proposé
une solution. En fin nous avons distingué les différents besoins que notre application a
imposée. Ces besoins seront détaillés dans le chapitre de conception.
12
Chapitre 2
État de l’art
13
Chapitre 2. État de l’art
2.1 Introduction
Au niveau de ce chapitre, nous allons présenter les notions fondamentales de la vir-
tualisation et du Cloud Computing. Nous commencerons par expliquer son principe, les
différents services qu’il fournit, ses modèles de déploiement ainsi que ses avantages et
inconvénients. Par la suite, nous allons présenter les différentes solutions du Cloud Com-
puting existantes et nous allons choisir la solution que nous allons adopter.
2.2 La virtualisation
La virtualisation recouvre l’ensemble des techniques matérielles et ou logiciels qui
permettent de faire fonctionner sur une seule machine plusieurs systèmes d’exploitation,
plusieurs instances différentes et cloisonnées d’un même système ou plusieurs applications,
séparément les uns des autres, comme s’ils fonctionnaient sur des machines physiques
distinctes. Les intérêts de la virtualisation sont : l’utilisation optimale des ressources,
l’économie sur le matériel par mutualisation, l’allocation dynamique de la puissance de
calcul, la facilité d’installation, de déploiement et de migration des machines virtuelles.
La figue 2.1 représente une comparaison entre architecture physique et vertualisée.
2.2.1 Mécanisme
Un système d’exploitation principal appelé « système hôte » est installé sur un serveur
physique unique. Ce système sert d’accueil à d’autres systèmes d’exploitation.
Un logiciel de virtualisation appelé « hyper viseur » est installé sur le système d’exploita-
tion principal. Il permet la création d’environnements clos et indépendants sur lesquels
seront installés d’autres systèmes d’exploitation « systèmes invités ».Ces environnements
sont des « machines virtuelles ».
Un système invité est installé dans une machine virtuelle qui fonctionne indépendamment
des autres systèmes invités dans d’autres machines virtuelles. Chaque machine virtuelle
dispose d’un accès aux ressources du serveur physique (mémoire, espace disque…).
2.2.2 Avantages
La virtualisation des systèmes informatiques présente de nombreux avantages :
• Déploiement rapide des applications
• Niveaux de service supérieur et disponibilité accrue des applications
• Taux d’utilisation supérieur des investissements dans l’infrastructure
• Évolutivité rapide et flexible
• Réduction des coûts énergétiques, d’infrastructure et des installations
• Diminution des frais de gestion
14
• Accès aux applications et aux données des bureaux en tout lieu
• Sécurité informatique renforcée
Fig. 2.1 : Comparaison entre architecture physique et virtualisée
Virtual Machine Manager (VMM) /Hyper viseur
La mise en oeuvre d’une machine virtuelle (Virtual machine ou VM) nécessite l’ajout
d’une couche logicielle à la machine physique. Cette couche d’abstraction se place entre
le matériel et le système d’exploitation et s’appelle hyper viseur ou moniteur de machine
virtuelle (VMM), elle est représentée par la figure 2.2.
Fig. 2.2 : Hyper viseur
Virtual Machine(VM)
Une machine virtuelle est un environnement d’exécution virtuel créé à partir d’une
image présentant un modèle pour instancier cette machine. Le cycle de vie d’une machine
virtuelle comporte six phases : create, suspend, resume, save, migrate et destroy. Les
15
machines virtuelles représenté par la figure 2.3 et tournant sur un même noeud physique
sont gérées et contrôlées par le VMM.
Fig. 2.3 : Machine virtuelle
Virtual Infrastructure Manager(VIM)
Le Virtual Infrastructure Manager (VIM) est responsable de la gestion centralisée de

l’infrastructure virtuelle (machine virtuelle, réseaux virtuels et de stockage virtuel). Il
fournit les fonctionnalités basiques pour le déploiement, le contrôle et la supervision des
VMs tournants sur différents nœuds physiques.
16
Fig. 2.4 : Infrastructure virtuelle
La figure 2.5 décrit l’infrastructure virtuelle avec ces différentes entités nécessaires
pour le déploiement et la gestion des machines virtuelles. Elle est basée effectivement sur
la présence de l’hyper viseur et du gestionnaire de l’infrastructure.
2.2.3 Réseau virtuel

Dans un environnement virtualisé, des machines virtuelles peuvent être reliées les
unes aux autres sur un réseau virtuel implémenté au-dessus d’une infrastructure réseau
physique partagée.
Dans les hyper viseurs de base, une machine virtuelle possède une ou plusieurs cartes
d’interfaces réseau virtuelles. Le trafic réseau sur toute interface virtuelle est commuté par
l’hyper viseur vers l’interface réseau physique en utilisant une solution logicielle, matérielle
ou les deux ensembles. Un commutateur virtuel (bridge) comme présenté dans la figure 1.3
est un logiciel intégré à l’hyper viseur qui se comporte comme un commutateur matériel.
Ce logiciel permet aux machines virtuelles (VM) de s’intégrer au réseau avec d’avantage
de souplesse, notamment sans se soucier du nombre de cartes physiques.
17
Fig. 2.5 : Concept du réseau virtuel
2.3 Concepts et définitions du Cloud Computing
2.3.1 Définitions et généralités

Le Cloud Computing, ou informatique dans les nuages, est une manière de fournir et
d’utiliser les aptitudes des systèmes informatiques, basée sur les nuages (Cloud en anglais).
Ce dernier est un parc de machines, d’équipements réseau et de logiciels maintenus par
un fournisseur, que les consommateurs peuvent utiliser en libre-service via un réseau
informatique, le plus souvent Internet.
Le « National Institute of Standards and Technology » a donné une définition succincte qui
détermine les principes de base du Cloud computing : « L’informatique dans les nuages est
un modèle permettant d’établir l’accès via un réseau de télécommunication à un réservoir
partagé de ressources informatiques standards configurables (réseau, serveurs, stockage,
applications et services) qui peuvent être rapidement mobilisées et mises à disposition en
minimisant les efforts de gestion ou les contacts avec le fournisseur de service.»
En effet, le Cloud Computing est un concept qui consiste à la mise à disposition des
ressources des technologies de l’information sous forme de services à la demande. De cette
façon, les applications et les données ne se trouvent plus sur des serveurs locaux ou sur
le poste de l’utilisateur, mais dans le Cloud composé d’un certain nombre de serveurs
distants, interconnectés au moyen d’une large bande passante. Les utilisateurs peuvent
déployer des machines virtuelles dans ce nuage, ce qui leur permet d’utiliser un certain
nombre de ressources (espace disque, mémoire vive, ou encore du CPU processeur) et de
bénéficier de multiples services accessibles à partir d’un ordinateur, d’un téléphone, d’une
tablette ou tout autre. La figure 2.6 illustre le concept du Cloud Computing.
18
Fig. 2.6 : Cloud Computing
2.3.2 Historique
Le Cloud computing est un concept assez récent. Sa première énonciation date de
1960 (John McCarthy), mais sa réelle mise en application a commencé au début des
années 2000. Salesforce.com fut le premier hébergeur de Cloud en 1999, suivi en 2002 par
Amazon.
Le Cloud Computing met en oeuvre l’idée de l’informatique utilitaire du type service
public, proposée par John McCarthy en 1961 qui suggère que la technologie informatique
partagée pourrait construire un bel avenir dans lequel la puissance de calcul et même les
applications spécifiques pourraient être vendues comme un service public.
L’apparition du Cloud Computing vient d’une évolution de certaines technologies telles
que la virtualisation du matériel informatique, les services web, ou l’architecture orientée
services SOA (Service OrientedArchitecture).
La virtualisation a été la première pierre de l’ère du Cloud Computing. En effet, cette
notion permet d’optimiser les ressources matérielles en les partageant entre plusieurs
environnements dans le but de pouvoir exécuter plusieurs systèmes « virtuels » sur une
seule ressource physique et fournir une couche supplémentaire d’abstraction du matériel.
Le Cloud computing est donc la juxtaposition de ces technologies pour passer à la vitesse
supérieure sur l’exploitation de données à travers Internet.
2.3.3 Caractéristiques
Le Cloud computing s’appuie sur une architecture client-serveur, il possède des carac-
téristiques qui le distinguent des autres technologies :
• Les ressources et les services fournis aux clients sont souvent virtuels et partagés
par plusieurs utilisateurs.
• Les serveurs qui forment le Cloud sont hébergés dans des data ‘‘centers’’ externes.
19
• La plupart de ces centres comportent des dizaines de milliers de serveurs et des

moyens de stockage pour permettre des montées en charge rapides.
• Les services sont fournis selon le modèle “pay-per-use” où la facturation est calculée
en fonction de la durée et de la quantité de ressources utilisées.
• Ces spécificités font de la technologie Cloud Computing une nouvelle option qui offre
à ses utilisateurs la possibilité d’accès à des logiciels et à des ressources informatiques
avec la flexibilité et la modularité souhaitées et à moindre coûts.
2.3.4 Les catégories des services

Le Cloud computing peut être décomposé en trois catégories de services :
• Infrastructure en tant que service (IaaS, Infrastructure as a Service).
• Plateforme en tant que service (PaaS, Platform as a Service).
• Application en tant que service (SaaS, Software as a Service). La figure 2.7 illustre
les différentes catégories de services d’un Cloud computig
Fig. 2.7 : Les services de Cloud Computing
Infrastructure en tant que service(IaaS)
C’est le service de plus bas niveau du Cloud computing. Il permet de disposer d’une
infrastructure à la demande, pouvant héberger et exécuter des applications, des services
ou encore stocker des données.
20
L’IaaS offre une grande flexibilité, avec une administration à distance, et permet d’installer
tous types de logiciels. En revanche, cette solution nécessite la présence d’un administra-
teur système au sein de l’entreprise, comme pour les solutions classiques.
Parmi les prestataires d’IaaS, on peut citer : Amazon avec EC2 ou Orange Business Ser-
vices avec Flexible Computing.
Plateforme en tant que service(PaaS)
La plate-forme en tant que service, située juste au-dessus de l’IAAS, est la plate-forme
d’exécution, de déploiement et de développement des applications. C’est une solution
complète sans téléchargement ou installation de logiciels destinés aux développeurs, res-
ponsables informatiques ou utilisateurs finaux disponible immédiatement via Internet.
PaaS se distingue des hébergeurs classiques par une grande abstraction de la plate-forme.
Le système d’exploitation et les outils d’infrastructure sont sous la responsabilité du four-
nisseur tandis que le consommateur a le contrôle des applications et peut ajouter ses
propres outils.
C’est une architecture à très haute disponibilité basée sur des centres de données répartis
dans le monde entier, et garantissant une grande résistance aux sinistres (inondations,
incendies,etc…).
2.4 Les modèles de déploiement

Chacun de ces services peut être déployé de trois manières différentes. La figure model
décrit les trois modèles de déploiement d’un Cloud.
21
Fig. 2.8 : Prestataires de Cloud selon les catégories des services
2.4.1 Le Cloud public

Ce type de Cloud est créé par un organisme spécialisé qui met à disposition ses infra-
structures, ses ressources pour des entreprises. Ainsi, ces entreprises consommatrices de
services utilisent et payent à la demande des services dont elles ont besoin.
2.4.2 Le Cloud privé

Les offres de Cloud privé, contrairement à celles du Cloud public, se distinguent par
leur aspect dédié, c’est à dire destinés à satisfaire les besoins propres d’une seule entreprise.
On distingue deux types de Cloud privé : interne et externe.
Les Cloud privés internes
Les serveurs hébergeant les services sont localisés dans les bâtiments de l’entreprise.
Ces serveurs sont accessibles à travers un réseau sécurisé, interne et fermé
Les Cloud privés externes
L’infrastructure est exploitée par l’entreprise mais les ressources physiques sont hé-
bergées chez un prestataire. Dans ce cas, l’infrastructure est accessible via des réseaux
sécurisés de typeVPN.
22
2.4.3 Le Cloud hybride

C’est le résultat d’une combinaison de deux ou plusieurs nuages (public ou privé). Ces
nuages communiquent donc ainsi, et forment un Cloud hybride. Les différents nuages qui
le composent restent des entités indépendantes à part entière, mais sont reliés par des
standards ou par des technologies propriétaires qui permettent la portabilité des données
et des applications déployées sur les différents nuages.
2.5 Les avantages et les inconvénients du Cloud

Le tableau 2.1 résume les principaux avantages et inconvénients du Cloud Computing.
- Aucun investissement préalable.
- Service d’une grande disponibilité.
- Facturation à la consommation.
Advantages
- Version toujours à jour et identique pour tous les utilisateurs (cas du SaaS).
- Architecture sur mesure adaptable selon les besoins.
- Accès simplifié utilisant des navigateurs web.
- Budget élevé : les besoins senban de passante peuvent faire explorer le budget.
- Cadre légal : Absence de localization précise des données.

Inconvenient
- Gouvernance et administration.
- Manque de confidentialité et sécurité des données.
Tab. 2.1 : Les avantages et les inconvénients du Cloud Computing
2.6 Conclusion
Au niveau de ce chapitre nous avons clarifié le concept de la virtualisation et du Cloud
Computing en mettant en relief l’utilisation, les avantages et les inconvénients. Cela nous a
conduits à déterminer notre besoin pour mettre en place une plateforme de virtualisation
et du Cloud.
23
Chapitre 3
Processus de développement Et
méthodologie
24
Chapitre 3. Processus de développement Et méthodologie
3.1 Introduction
Comme bonne pratique, il est fortement recommandé de choisir une méthode d’orga-
nisation des phases de développement du projet pour assurer un maximum d’efficacité.
Pour ce projet, nous avons choisi de suivre le modèle sashimi qui est une évolution du
modèle en cascade. Dans ce qui suit, nous allons expliquer en quoi consiste ce modèle.
3.2 Le modèle sashimi

Le modèle sashimi (ainsi appelé car il présente des phases imbriquées, comme l’imbri-
quèrent du poisson dans la préparation japonaise sashimi) a été créé par Peter De Grace,
aussi appelé « le modèle en cascade avec boucle de retour » ou encore « le modèle en cas-
cade avec évaluation ». Un avantage de ce modèle est qu’il permet de détecter rapidement
les erreurs aidant ainsi à améliorer la qualité du produit final tout en réduisant la charge
de travail.
La phase de conception du projet permet de détecter des problèmes d’implémentation

avant de commencer la phase de production. Inversement, comme la phase d’implémen-
tation commence avant la finalisation de la conception, on peut découvrir des erreurs de
conception non détectables dans la phase de conception. La méthode itérative introduite
avec le modèle sashimi a été créée pour réduire les couts associés au modèle en cascade
classique.
Une des plus importantes tâches pour le travail avec la méthode sashimi, est l’extraction
et la définition des besoins du projet. Selon le cadre et le type du projet, nous utiliserons
les phases adéquates à utiliser. Pour notre projet, nous allons utiliser quatre phases ty-
piques de ce modèle qui adhèrent à la nature de notre projet vu que notre architecture
peut s’agrandir et évoluer avec les tests d’implémentation.
Nous avons identifié quelques critères qui nous ont menés à cette méthodologie :
• Le projet est voué à une utilisation massive (les employer de tout le groupe) des
tests qui pourraient amener à la modification de l’architecture.
• Le projet est dans le contexte du Cloud Computing, la solution devra tirer avantage
de l’environnement Cloud.
• Les scenarios de test devraient être revus à chaque fois où les phases du processus
d’implémentation seront changées.
Dans la figure 3.1 nous présentons un aperçu sur les quatre étapes de notre méthode.
25
Fig. 3.1 : Modèle Sashim
1. Spécification des besoins : l’extraction et l’analyse des attentes d’un projet est la
partie la plus importante du modèle en cascade. Pour reconnaitre les buts d’un pro-
jet, il faut avoir une communication avec le client et analyser les risques qu’implique
le projet
2. Conception et Architecture : après avoir identifié les besoins du projet, nous

devons concevoir une solution qui assure ces besoins. Ceci implique un nombre
d’éléments comme la sécurité et l’administration du système.
3. Implémentation : parmi les raisons pour les quelles cette phase de ce modèle
est si importante, est que cette partie est celle qui consume le plus de temps et
la plus couteuse dans la vie du projet. Une erreur à ce niveau va impliquer une
des deux résultats suivants : retravailler cette partie ou un client mécontent. Même
si elle aboutit, elle peut conduire à un retard. Comme nous utilisons le modèle
sashimi, la phase d’implémentation est imbriquée avec les phases de spécification
des besoins et la conception jusqu’à ce que cette phase réponde aux exigences des
étapes précédentes.
4. Test : après avoir terminé l’implémentation de la solution selon la conception, les

tests sont réalisés pour vérifier que le produit ne contient pas d’erreurs. Ainsi, pour
assurer que le produit ou service sont conformes aux exigences du client.
Durant le projet, le chef de projet doit planifier, suivre et contrôler les activités de chaque
étape. Ceci rend cette méthode plus systématique utilisée pour gérer un projet.
26
3.3 Spécification des besoins

Ce projet est le premier de son genre pour le CRDA Jendouba. Nous avons donc
besoin de faire une bonne étude pour savoir quel IaaS choisir pour correspondre au besoin
du groupe. Le CRDA Jendouba est en constante croissance ce qui impliquera que l’IaaS
choisi devra assurer une bonne scalabilité et une évolution rapide pour suivre la croissance
du groupe.
L’IaaS mise en place devra être modulable et personnalisable pour correspondre au besoin
du groupe. Dans ce qui suit nous allons procéder au choix de l’IaaS et de l’hyper viseur
à utiliser.
3.3.1 Présentation IaaS

Il existe deux catégories de solutions Cloud Computing privé, les solutions propriétaires
et les solutions libres et gratuites. Dans le monde du Cloud, le logiciel libre est de plus
en plus sollicité par les fournisseurs pour offrir des services dédiés. Deux arguments sont
souvent mis en avant pour le choix du libre, la gratuité et le développement plus rapide et
agile. C’est pour cela, nous nous intéressons dans ce qui suit aux solutions open source.
Eucalyptus
Eucalyptus [6] est un outil permettant de construire des infrastructures de Cloud

computing sur la base de serveurs en cluster. Il est issu d’un projet de recherche de
l’université de Californie. Il permet de créer des Cloud IaaS de type privé ou hybride. Les
moteurs de virtualisation supportés sont Xen, KVM pour la version open source. Il existe
également une version propriétaire commercialisée par la société Eucalyptus Systems. Il
apporte des fonctionnalités supplémentaires comme le support de VMware.
OpenNebula
OpenNebula, purement open source permet de déployer des Cloud privés, hybrides
et publics. Ecrite en C++, Ruby et Shell, elle supporte les plateformes de virtualisation
Xen, KVM et VMware ainsi que le service “on-demand” d’Amazon EC2. Le projet est
publié sous licence Apache 2.0. Parmi ses fonctionnalités : gestion centralisée des machines
virtuelles et des ressources physiques, répartition des charges, extension des capacités par
ajout de serveurs physiques. Beaucoup de ces solutions sont avant tout des solutions
d’infrastructure permettant une gestion simplifiée d’architectures matérielles complexes.
CloudStack
CloudStack, issu du rachat de Cloud.com par Citrix, a été conçu pour permettre le
déploiement et la gestion d’importants réseaux de machines virtuelles. Il supporte les prin-
cipaux moteurs de virtualisation à savoir : vSphere, Oracle VM, KVM, Xen, mais aussi
les services de Cloud d’Amazon.
27
Les caractéristiques principales de CloudStack sont les suivantes :
• Réseau virtuel (support VLAN).

• Piscine de ressources (permet aux administrateurs de limiter les ressources vir-
tuelles).
• Routeurs virtuels, un pare-feu, et un équilibreur de charge.
• Migration en direct avec le maintien d’accueil.
OpenStack
OpenStack est un logiciel libre qui permet la construction de Cloud privé et public.
Il est aussi une communauté et un projet en plus d’un logiciel qui a pour but d’aider les
organisations à mettre en œuvre un système de serveur et de stockage virtuel. Il s’installe
sur un système d’exploitation libre comme Ubuntu ou Debian et se configure entièrement
en ligne de commande. C’est un système robuste et qui a fait ses preuves auprès des
professionnels du domaine. En comparaison avec les autres produits, OpenStack semble
avoir la plus grande et la plus active communauté. Les membres de la communauté sont
toujours prêts à aider les autres à trouver des solutions aux problèmes qui se posent
3.3.2 Etude comparative des solutions

Afin de caractériser chaque solution open source et assurer le choix adéquat pour la
construction d’un Cloud, nous avons réalisé une étude comparative des quatre solutions
libres en se basant sur différents critères de classification. Le tableau 3.1 résume les prin-
cipales caractéristiques de chaque solution
Choix de l’IaaS
Dans les sections précédentes, nous avons présenté une liste des solutions permettant
la création d’un Cloud. Il est à présent question de faire le choix de celui qui nous convient
le mieux. Notre choix s’est fixé sur la solution OpenStack pour les raisons suivantes :
• La solution est arrivée à un niveau de maturité suffisant : une nouvelle version tous
les six mois.
• Actuellement, elle est à sa neuvième version.
• La conception modulaire d’OpenStack permet une évolutivité souple.
• Il est ainsi possible d’ajouter des ressources ou des composants pour adapter la
plate-forme aux évolutions des besoins en conservant une interface uniforme pour
l’utilisateur final.
C’est la solution open source la plus utilisée. La figure 3.2 illustre le pourcentage d’utilisa-
tion des solutions open source pour la mise en place d’un environnement Cloud et montre
que la plus grande part de marché utilise la solution OpenStack
28
Eucalyptus OpenStack OpenNebula CloudStack
Date de sortie Mai 2008 Octobre 2010 Mars 2008 Mai 2010
Licence Propriétaire , GP L v3 Licence Apache Licence Apache Licence Apache
Langage de C++,C, Ruby,
Java, C et Python Python, JavaScript, XML Java, C
programmation Java, Shell script
Xen, KVM, VMware KVM, Xen, ESXi
Hyperviseur Xen, KVM Xen, KVM, VMware
et Hyper- V et BareMetal
Systèmes
d’exploitation Linux Linux, Windows Linux Linux
supportés
Modèle de
Cloud public et privé Cloud public et privé Cloud privé Cloud privé et public
déploiement
Difficile à installer
Facile à installer
Dépend de l’environnement plusieurs composants Manuelle, installation facile sur
Installation avec les paramètres
réseau et matériel et plusieurs fichiers les distributions supportées
par défaut
de configuration
Aboutie, produit complet avec Niveau de maturité
Avancée, deuxième version stables
Maturité une interface de gestion web avancé avec sa neuvième Manque de maturité
Solutions supportée Par Debian
fonctionnelle. version
Tab. 3.1 : comparaison IaaS

Excellente, La documentation ne
Complète, documentation
Correcte, complète mais pas une documentation traite pas des questions
Documentation références de tous les fichiers
toujours à jour. officielle disponible complexes dans leur
de configuration.
et très détaillée. intégralité.
29
Fig. 3.2 : Utilisation des solutions open source
Présentation de l’Hyper viseur
Après avoir choisi OpenStack comme IaaS, il nous reste le choix du l’hyper viseur qui
se fera parmi ceux compatible à savoir Xen, KVM, vSphere, Hyper-V. Quelques hyper
viseurs Xen : Xen est un hyper viseur de type 1 (BareMetal) qui a débuté comme un pro-
jet de recherche dans l’université du Cambridge au Royaume-Uni. La société XenSource
a été créée et en a poursuivi le développement. Il est intégré Partiellement dans la partie
principale du noyau linux depuis la version 3.0.
A- KVM :
KVM (Kernel-based Virtual Machine) est un hyper viseur libre de type 1 (BareMetal)
pour Linux développé par Red hat. KVM et est intégré dans le noyau Linux depuis la
version 2.6.201.
B- vSphere/ESXI :
VMware vSphere est un logiciel d’infrastructure de Cloud computing de l’éditeur VM-
ware, c’est un hyper viseur de type 1 (BareMetal).
C- Hyper-V :
Hyper-V, également connu sous le nom de Windows Server Virtualization, est un système
de virtualisation basé sur un hyper viseur 64 bits de la version de Windows Server 2008.
30
3.3.3 Etude comparatif des Hyper viseurs

Le tableau 3.2 résume les principales caractéristiques de chaque hyper viseur.
HYPERVISEUR XEN KVM VSPHERE HYPER-V

Société XenSource RedHat VMware Microsoft
Personnel Petite/ Personnel Petite/
Developer pour enterprise entreprise
Moyenne entreprise Moyenne entreprise
Maturité Très bonne Très bonne Très bonne Bonne
Max CPU haute 160 160 480 320
Max RAM haute 1To 4To 12To 4To
16(win)/ 64(win)/
Max vCPU/VM 160 128
32 (linu x) 32 (linux)
Max RAM/VM 192Go 4To 4To 1TO
500(win)/
VM/haute Pas de limite 1000 1024
650 (linux)
Tab. 3.2 : Comparatif des hyper viseurs
3.3.4 Choix de l’hyper viseur

Nous avons choisi d’utiliser vSphere comme hyper viseur car il est globalement plus
performant que les autres hyper viseurs. En plus, CRDA est en cour d’établir un par-
tenariat avec VMware ce qui a guideé notre choix vu qu’on pourra avoir une assistance
technique et des conseillers si le besoin se fait ressentir. Après avoir procéder au choix du
IaaS et de l’hyper viseur à implémenter, nous allons procéder à la conception générale du
projet.
3.3.5 Conception
Nous allons commencer par la conception de l’architecture réseau globale qui présente
la mise en place et qui assure la communication entre les sites. Architecture global du
CRDA Jendouba est representé par la figure 3.3.
3.4 Conception de l’infrastructure

Le marché des solutions de virtualisation est un marché extrêmement concurrentiel.
Parmi les principaux acteurs composant ce marché, nous détaillerons les offres des trois
principaux éditeurs, à savoir VMware, Citrix et Microsoft.
VMwarevSphere :
VMware vSphere gère de grandes collections d’infrastructure (par exemple des proces-
seurs, le stockage et la gestion de réseau) sous la forme d’un environnement d’exploitation
transparent et dynamique, ainsi que la complexité d’un centre de données. La pile logicielle
31
Fig. 3.3 : Architecture global du CRDA Jendouba
VMware vSphere représenté par la figure 3.4 est constituée des couches de virtualisation,
de gestion et d’interfaces.
Relations entre les couches de composants de VMware vSphere :
• Couche de virtualisation :
La couche de virtualisation de VMware vSphere inclut des services d’infrastructure
et d’application. L’infrastructure fournit, entre autres, les services de traitement
et de stockage et les services réseau extraient, agrègent et allouent les ressources
matérielles ou d’infrastructure. Les services d’infrastructure comprennent les types
suivants :
• Services de traitement :
Inclut les fonctions VMware qui permettent de ne pas tenir compte des ressources
serveur hétérogènes sous-jacentes. Les services de traitement agrègent ces ressources
sur un grand nombre de serveurs discrets les affectent aux applications.
• Services de stockage :
Il s’agit de l’ensemble de technologies qui permettent d’utiliser et de gérer efficace-
ment le stockage dans les environnements virtuels.
32
Fig. 3.4 : Relations entre les couches de composants de VMware vSphere
• Services de réseau :
Il s’agit de l’ensemble de technologies qui simplifient et améliorent la gestion de
réseau dans les environnements virtuels.
• Couche de gestion :
VMware vCenter Server est le point central de la configuration, du provisionnement
et de la gestion des environnements informatiques virtualisé.
• Couche d’interfaces :
Les utilisateurs peuvent accéder au centre de données VMware vSphere via des
clients à interface graphique, tels que vSphere Client ou vSphere Web Client. En
outre, ils peuvent accéder au centre de données via des machines clientes qui utilisent
des interfaces de ligne de commande et des kits SDK pour la gestion automatique.
Composants et fonctions VMware vSphere : Une présentation des composants et fonc-

tions de VMware vSphere explique les composants et leurs interactions. VMware vSphere
inclut les composants et fonctions suivants :
• VMware ESXi voir figure 3.5) :

Une couche de virtualisation fonctionne sur des serveurs physiques qui analysent
33
le processeur, la mémoire, le stockage et les ressources dans les machines virtuelles

multiples.
Fig. 3.5 : VMware ESXI
• VMware vSphere Client :

Une interface permettant aux utilisateurs de se connecter à distance vCenter Server
ou ESXi depuis n’importe quel PC Windows.
• VMware vSphere Web Client (voir figure 3.6) :

Une interface Web permet aux utilisateurs de se connecter à distance à vCenter
Server depuis divers navigateurs Web et systèmes d’exploitation.
Fig. 3.6 : Mware vSphere Web Client
• VMware vCenter Server (voir figure 3.7) :

Le point central pour configurer, approvisionner et gérer des environnements infor-
matiques virtualités. Il fournit les services essentiels du centre de données : contrôle
d’accès, surveillance des performances et gestion des alarmes.
34
Fig. 3.7 : VMware vCenter Serve
• vSphere vMotion (voir figure 3.8) :

Permet de migrer des machines virtuelles sous tension depuis un serveur physique
vers un autre sans interruption avec une disponibilité de service continue et une
intégrité de transaction complète.
• vSphere Storage vMotion (voir figure 3.9) :

Permet de migrer des fichiers de machine virtuelle d’une banque de données vers
une autre sans interruption de service. On a placez la machine virtuelle et tous
ses disques dans un seul emplacement ou sélectionnez des emplacements distincts
pour le fichier de configuration de la machine virtuelle et chaque disque virtuel. La
machine virtuelle reste sur le même hôte pendant Storage vMotion. La migration
avec Storage vMotion permet de transférer les disques virtuels ou le fichier de confi-
guration d’une machine virtuelle vers une nouvelle banque de données alors que la
machine virtuelle s’exécute.
• vSphere High Availability (HA)(voir figure 3.10) :

Fonction qui offre une haute disponibilité pour les machines virtuelles. En cas de
panne d’un serveur, les machines virtuelles affectées sont redémarrées sur d’autres
serveurs disponibles ayant une capacité disponible.
• vSphere Fault Tolerance (voir figure3.11) :

Assure la disponibilité permanente en protégeant une machine virtuelle avec une
copie. Lorsque cette fonction est activée pour une machine virtuelle, une seconde
copie de la machine d’origine (ou principale) est créée. Toutes les actions effectuées
sur la machine virtuelle primaire sont également effectuées sur la seconde machine
virtuelle. Si la machine virtuelle principale devient indisponible, la seconde machine
devient active immédiatement.
35
Fig. 3.8 : vSphere vMotion
3.5 Conclusion
36
Fig. 3.9 : VSphere Storage vMotion
Fig. 3.10 : vSphere High Availability (HA)
37
Fig. 3.11 : vSphere Fault Tolerance
38
Chapitre 4
Implémentation
4.1 Introduction
Les chapitres précédents, ont abordés une étude théorique et conceptuelle d’un cloud
computing. D Le présent chapitre donne les étapes de mettre en œuvre la solution proposée
et la configuration pratique de plateforme choisi. Premièrement, on a parlé comment faire
pour s’inscrire dans la plateforme de cloud d’Amazon Web Service. On a fait une fait une
explication détaillée de configuration et l’exploitation de plateforme dans notre solution,
tel que la gestion de bucket, stockage, contrôle et récupération de données.
4.2 Environnement du travail
4.2.1 Choix technique

L’implémentation est effectuée dans un PC HP de caractéristiques suivantes :
• Processeur : intel core™ i7 4,20 ghz
• Taille de disque dur : 500 Go ssd
• Taille de la mémoire vive (RAM) : 8Go
• Le système d’exploitation : Windows 10, 64bit
Le PC joues le rôle d’un Superviseur pour l’application et d’un client pour le plateforme
Amazon.
4.2.2 Étapes de déploiement et de configuration de l’appliance

vCenter Server 5.5
À l’aide de l’vSphere Web Client, déployez l’. Le fichier OVULEs ou. Fichiers OVF et
VMDK en tant que modèle de OVF.
39
Chapitre 4. Implémentation
1. Accédez à File > Deploy OVF template.
2. Naviguez jusqu’à l’emplacement de l’appliance vCenter Server téléchargée. ovules

ou le fichier. ovf, puis cliquez sur Ouvrir.
3. Sur la page Détails du modèle d’OVF, cliquez sur suivant.
4. Dans le champ nom et emplacement, saisissez le nom de votre appliance vCenter

Server, puis cliquez sur suivant.
5. Sélectionnez un ordinateur, puis cliquez sur Suivant.
6. Sélectionnez un format de disque, puis cliquez sur suivant.
7. Cliquez sur Terminer.
8. Mettez l’appliance vCenter Server sous tension.
9. Ouvrez une vue console.
10. Suivez les instructions qui s’affichent dans l’écran d’accueil pour ouvrir une fenêtre
de navigateur -dans l’URL illustrée.
11. on connecte à l’appliance vCenter Server et acceptez le contrat de licence. (Utilisa-

teur root avec le mot de passe VMware).
12. Lorsque on a connectez, à l’Assistant de configuration de vCenter Server démarre.
13. Sélectionnez l’option de configuration de votre installation
Fig. 4.1 : VMware vCenter Server
40
1. Configurez avec les paramètres par défaut : Configure la base de données

intégrée vCenter Server dans l’appliance vCenter Server et configure les paramètres
par défaut de la base de données et d’Active Directory.
2. Télécharger le fichier de configuration : Pour configurer l’appliance vCenter

Server à partir d’un fichier de configuration préparé.
3. Définir la configuration personnalisée : Permet de personnaliser la configura-

tion de l’appliance vCenter Server. L’Assistant Configuration affiche des panneaux
distincts pour nous connecter à l’appliance à la base de données vCenter Server in-
tégrée ou externe, et pour configurer les paramètres Active Directory personnalisés.
Fig. 4.2 : Paramétrage Vcenter
VMware vCenter Server 5 : Création d’un Datacenter CRDA Jendouba

Pour créer un Datacenter dans vCenter Server 5, ouvrir une console vSphere Client puis
se connecter sur le vCenter. Se positionner au niveau du vCenter dans l’inventaire puis
effectuer un clic droit et cliquer sur Créer un centre de données.
Ajouter un hôte au Datacenter :
41
Fig. 4.3 : Connexion Vmaware Vcenter
• Un hôte est un ordinateur physique installé avec le logiciel de virtualisation ”ESXi”.

L’ajout d’un hôte à l’inventaire de vCenter permet de le contrôler via l’interface
d’administration de vCenter Server.
• Cliquez du bouton droit de la souris sur le serveur ”VCENTER” puis sélectionnez

l’option ”Ajouter hôte ...”. Le raccourci clavier correspondant est : [CTRL+H]. on
cliquer sur le lien ”Ajouter un hôte” sur l’écran de central.
42
Fig. 4.4 : Notre plateforme de virtualisation
Fig. 4.5 : Assistant d’ajout d’un hôte
• Tapez le nom de domaine complet de l’hôte ”ESXi” (recommandé) ou son adresse

IP. Tapez ensuite le nom d’utilisateur par défaut ”root” et le mot de passe. Cliquez
sur le bouton ”Suivant”.
4.2.3 Migration du Data center vers le Cloud

La migration vers le Cloud est le processus qui consiste à déplacer les opérations
commerciales, techniques et applicatives vers le Cloud. La migration vers le Cloud est un
peu comme un déménagement physique, sauf qu’elle implique le déplacement de données,
d’applications et de processus informatiques de certains centres de données vers d’autres
centres de données, au lieu d’emballer et de déplacer des biens physiques .
43
Fig. 4.6 : Liste des serveurs ESXI
Fig. 4.7 : Liste des Serveurs du data Center
Fig. 4.8 : Liste des Serveurs du data Center
4.2.4 Configuration de plateforme Amazon

Inscription :
Après la création de compte Amazon sur le site www.aws.amazon.com, on peut s’inscrire
comme ce dessous. Les services Fournie par aws
• Amazon Elastic Compute Cloud (EC2)
• Elastic Container Service (ECS)
• Amazon Lambda.
44
Fig. 4.9 : Interface de connexion AWS
• Simple Cloud Storage Service (S3)
• Amazon Kinesis pour l’analyse de données.
• Amazon Elastic Container Service pour Kubernetes.
• Le Cloud de VMWare sur AWS. ...
La figure 4.10 représente les services de aws.
Fig. 4.10 : Les services d’Amazon Web Service
45
4.3 Gestion de bucket sur Amazon S3
4.3.1 Définition de bucket

Un bucket est une unité logique de stockage dans Amazon Web Services (AWS) Service
de stockage d’objets, Simple Storage Solution S3. Les buckets sont utilisés pour stocker
des objets, qui se composent de données et de métadonnées qui décrit les données.
4.3.2 Création d’un Bucket

Avant de pouvoir télécharger des données dans Amazon S3, nous devons créer un bu-
cket pour stocker les données dans. buckets ont des propriétés de configuration, y compris
leur région géographique, qui a accès aux objets dans le bucket, et d’autres métadonnées,
telles que la classe de stockage de les objets dans le bucket. La console nous permet d’uti-
liser les dossiers, que nous pouvons stocker des objets dans. Dossiers, comme des objets,
doivent résider dans un bucket. Pour créer un bucket sur le plateforme, procéder comme
se suit :
1. connexion à la console de gestion AWS et ouvrez la console Amazon S3 à https ://console.aws.amazo
2. Cliquez sur Créer un bucket.
3. Dans la boîte de dialogue Créer bucket, dans la zone Nom bucket, tapez un nom
pour votre bucket.
Fig. 4.11 : Les services d’Amazon Web Service
4. Sélectionner le nom et la région :
• Le nom que nous choisissez doit être unique parmi tous les noms buckets
existants dans Amazon S3. Une façon d’aider à assurer l’unicité est de préfixer
vos noms buckets avec le nom de votre organisation.
• Le nom du bucket est visible dans l’URL qui pointe vers les objets que nous
allons Mettre dans votre bucket. Pour cette raison, bucket choisir un nom de
compartiment qui reflète les objets dans le bucket.
46
• Pour assurer une approche unique, des règles de nommage pour les buckets
AmazonS3 entre les régions et d’assurer noms buckets sont conformes aux
conventions de nommage DNS, les noms de buckets doivent se conformer aux
exigences suivantes.
-Peut contenir des lettres minuscules, des chiffres(.), et traits d’union(-).
-Doit commencé par un chiffre ou une lettre.
-Doit être comprise entre 3 et 63 caractères.
-Ne doit pas être formatée comme une adresse IP (par exemple, 192.168.5.4).
-Ne doit pas contenir de soulignement (_ ).
-Ne doit pas se terminer par un trait d’union.
-Ne peut pas contenir deux, périodes adjacentes.
-Ne peut pas contenir des tirets à côté de périodes (par exemple, my-.bucket.com
et my.-bucket sont invalides).
• Dans la boîte de Région, cliquez sur la région où le bucket de résider. on choisir

une région proche de nous pour optimiser la latence, Minimiser les coûts, ou
pour répondre aux exigences réglementaires. Objets Stockés dans une région
ne quittent jamais cette région, sauf si on a les transférer explicitement à une
autre région
Fig. 4.12 : Chargement des objets
4.3.3 Copie d’objets dans le même compte Amazon S3

Connectez à AWS Management Console, accédez à la page DataSync, sélectionnez
Tâches dans la barre de menus de gauche, puis choisissez Créer une tâche. Pour l’em-
47
placement source, sélectionnez Créer un nouvel emplacement et, dans la liste déroulante
Type d’emplacement, sélectionnez Amazon S3.
Dans les étapes suivantes, nous avons exécuter une commande via l’AWS CLI pour créer
l’emplacement du compartiment S3 source pour DataSync (la configuration d’un em-
placement entre comptes n’est actuellement pas prise en charge dans la console AWS
DataSync).
Notez l’ARN de l’utilisateur ou du rôle IAM que nous avons utilisé pour créer l’emplace-
ment DataSync à partir de l’AWS CLI et entrez-le dans la stratégie de compartiment S3
source suivante. Copiez l’ARN du rôle IAM que nous avons créé pour l’emplacement du
compartiment S3 source.
Maintenant, connecté au compte source. Ouvrez la stratégie de compartiment S3 source et
appliquez la stratégie suivante pour accorder des autorisations au rôle IAM pour accéder
aux objets.
Maintenant, on va lancez l’AWS CLI et utilisez la même identité IAM que celle que nous
avons spécifiée dans la stratégie de compartiment S3 source créée à l’étape précédente.
Par exemple, si j’utilise un ID de clé d’accès et une clé d’accès secrète avec l’AWS CLI,
cela renvoie à un utilisateur IAM. À partir de l’AWS CLI, saisissez la commande suivante
pour obtenir l’ARN de l’identité utilisée :
4.4 La migration avec CLOUDENDURE

Pour commencer, nous allons besoin de configurer CloudEndure avec notre AWS cre-
dentials pour accéder notre compte AWS et la localisation de la Destination de réplication
(subnet) dans le compte AWS cible pour le serveur de réplication CloudEndure.
• Exécutez la commande copiée à partir de How to Add Machines pour télécharger

et installer l’agent.
• Si l’installation est réalisée correctement, nous recevons un message indiquant « Installation

finished successfully ».
48
Fig. 4.13 : Role Policy
Fig. 4.14 : Trust Policy
4.4.1 Tester le lancement

L’étape suivante consistait à s’assurer que la migration du serveur serait réussie. J’ai
donc fait un test de lancement avant la migration finale. Ceci est lancé avec le bouton
Launch Target Machines
49
Fig. 4.15 : Containers
Fig. 4.16 : Interface de connexion CloudEndure
Fig. 4.17 : Paramètre de l’installation de l’agent sur les machines source
Ce processus crée la nouvelle instance EC2 avec le volume migré. Cela a été fait en 7
minutes. Et j’ai trouvé la nouvelle instance EC2 dans la console AWS. C’était très rapide.
J’ai remarqué qu’il y avait une instance dans l’état Terminé. C’est normal. C’est l’instance
de convertisseur temporaire. Le temps de conversion était inférieur à 2 minutes. Et cette
instance de conversion a été arrêtée par la suite.
50
Fig. 4.18 : Script pour l’ajout d’une machine
Fig. 4.19 : Installation de l’agent cloud endure
Fig. 4.20 : Machine déployer dans le cloud
J’ai noté l’adresse IP publique de la nouvelle instance qui vient d’être lancée dans la région
de paris. Et j’ai pu me connecter à l’instance sans aucun problème. Cela signifie que le
test de migration a réussi.
51
Fig. 4.21 : Liste des instances déployer
Notez que l’instance de réplication était toujours active. Il était encore utilisé pour
synchroniser la machine source.
Fig. 4.22 : Accès à distance machine aws
J’ai noté l’adresse IP publique de la nouvelle instance qui vient d’être lancée dans la région
de Paris. Et j’ai pu me connecter à l’instance sans aucun problème. Cela signifie que le
test de migration a réussi.
Ce processus m’a permis de soulever et déplacer le serveur. Le lift-and-shift est toujours la
première étape du parcours vers le cloud. Et cet outil a permis de le compléter efficacement.
Je tiens à mentionner que le processus présentait de nombreux avantages. Par exemple, j’ai
52
utilisé le même outil pour télécharger les données dans le cloud et orchestrer la migration.
J’ai également pu tester le processus avant le basculement. C’est très important car cela
élimine les éventuelles erreurs de migration. La période d’indisponibilité a été très courte.
De plus, je n’ai pas eu à adapter le disque pour démarrer dans le cloud, car cela était géré
par l’outil. Et ce processus me permet d’automatiser la migration de plusieurs serveurs à
la fois.
De l’autre côté, j’ai eu quelques problèmes avec l’agent. Et l’ensemble du processus de
migration comporte de nombreuses étapes. Mais c’est devenu ma motivation pour écrire
et partager cet article. J’espère que cela nous aider à migrer vos serveurs de manière
prévisible. En fin de compte, la migration vers le cloud ne devrait pas être un problème.
4.5 Serveur de migration de Service

AWS Server Migration Service (AWS SMS) automatise la migration des machines vir-
tuelles VMware vSphere, Microsoft Hyper-V/SCVMM et Azure sur site vers le cloud AWS.
AWS SMS réplique de manière incrémentielle les machines virtuelles de votre serveur en
tant qu’Amazon Machine Images (AMI) hébergées dans le cloud prêtes à être déployées
sur Amazon EC2. En travaillant avec des AMI, donc facilement tester et mettre à jour
vos images basées sur le cloud avant de les déployer en production.
4.5.1 Installation du connecteur de migration de serveur

Le connecteur de migration de serveur est une machine virtuelle FreeBSD que installez
dans votre environnement de virtualisation sur site. Les plateformes prises en charge sont
VMware vSphere, Microsoft Hyper-V/SCVMM et Microsoft Azure.
4.5.2 Configuration du connecteur
1. Déployez le connecteur OVA téléchargé dans la procédure précédente dans votre

environnement VMware à l’aide de vSphere Client.
2. Ouvrez la console de la machine virtuelle du connecteur et connecter en tant qu’uti-

lisateur ec2 avec le mot de passe ec2pass. Fournissez un nouveau mot de passe.
Fig. 4.23 : Configuration du connecteur sms aws
53
3. Obtenez l’adresse IP du connecteur comme suit :
• Exécutez la commande sudo setup.rb. Cela affiche un menu de configuration
Fig. 4.24 : Configuration du connecteur
• Dans un navigateur Web, accédez à la machine virtuelle du connecteur à son

adresse IP (https ://192.168.15.64/) pour ouvrir l’assistant de configuration,
puis choisissez Démarrer maintenant.
Fig. 4.25 : Paramétrage du serveur de migration de service
54
Fig. 4.26 : Connexion vCenter à sms connecteur
4.5.3 processus de migration lui-même et comment AWS

SMS le gère
Le processus de migration passe par quatre étapes, comme illustré dans les schémas
suivants.
Fig. 4.27 : Processus de migration
Les processus de migration se déroule en quatre étapes :
(1) Planifier une tache

(2) Téléchargement (prendre un instantané, exportation VM vers OVF Template)
(3) Convertir vmdk en compartiment s3
(4) Création de l’instance
55
Fig. 4.28 : Connecteur Serveur de migration de service
Une fois qu’un connecteur est installé et correctement enregistré, accédez à la console
AWS SMS et choisissez Connecteurs, Importer le catalogue de serveurs pour rassembler
votre liste complète de serveurs. Cela peut prendre un certain temps pour que votre ca-
talogue de serveurs soit entièrement rempli et affiché dans le tableau.
Fig. 4.29 : catalogue des serveurs du data center
Sélectionnez le type de licence pour les AMI qui seront créées à partir de la tâche de
réplication. Les serveurs Linux ne peuvent utiliser que BYOL (Bring Your Own License),
et les serveurs Windows peuvent utiliser soit des licences fournies par AWS, soit BYOL.
Lorsque nous terminé, choisissez Suivant.
Configurez les paramètres de la tâche de réplication, puis choisissez Suivant. On va faire
en sorte que les exécutions de réplication démarrent immédiatement ou les programment
pour qu’elles démarrent à une date et une heure ultérieure, jusqu’à 30 jours à compter de
l’heure actuelle.
Une fois la conversion terminée, le processus de migration passe à la dernière étape pour
créer une AMI pour la copie ponctuelle de cette exécution de réplication
Test avant le basculement réel
56
Fig. 4.30 : Tache de réplication
On a la possibilité de tester notre application avant de mettre hors service l’application

sur site. En fonction de la fréquence de réplication, nous avons tester de nombreuses ré-
pliques ponctuelles, puis planifier la dernière tâche de réplication pour les deltas.
Pour lancer une instance, ouvrez l’historique d’exécution comme indiqué à l’étape précé-
dente, sélectionnez la tâche de réplication et choisissez Lancer l’instance pour l’instance
que je souhaite tester. Suivez l’assistant pour choisir le type d’instance, configurer l’ins-
tance, ajouter du stockage, baliser l’instance et configurer le groupe de sécurité.
Fig. 4.31 : Serveur Héberger dans le cloud
57
Fig. 4.32 : Accès à la machine dans le Cloud
4.6 Conclusion
Nous avons présenté dans le présent chapitre, les différents modules implémentés dans
notre projet, enrichi par des captures écran, afin d’éclairci les explications aux lecteurs.
Le cloud computing joue un rôle très important dans web service parce qu’il est l’élément
responsable de créer les softwares et hardwares virtuel. Comme tout travail de développe-
ment, nous n’allons jamais satisfaire par notre travail, nous cherchons toujours les lacunes
pour améliorer et pour donner mieux
58
Chapitre 5
Sécurité de la Solution
59
Chapitre 5. Sécurité de la Solution
5.1 Introduction
Amazon Web Services (AWS) propose une plate-forme de cloud computing évolutive,
conçue avec un haut niveau de disponibilité et de sécurité de fonctionnement, offrant
les outils que je me permettent d’exécuter une vaste gamme d’applications. Garantir la
confidentialité, l’intégrité et la disponibilité des systèmes et données est une priorité pour
AWS, tout comme le maintien de la confiance et de côté crda le data center comporte
d’une solution Firewall UTM Sophos avec la haute disponibilité.
5.2 Sécurité Data Center du CRDA
5.2.1 Comment garantir la sécurité d’un datacenter ?

Dans la plupart des entreprises, la plus grande menace pour les données provient des
attaquants virtuels qui trouvent des failles dans les logiciels ou l’infrastructure réseau. Les
datacenters doivent non seulement se protéger contre ces types de menaces, mais ils ont
également la responsabilité de protéger physiquement l’infrastructure. Les fournisseurs
possèdent leurs propres normes de conformité à respecter pour rester certifiés, mais ces
normes sont auditées pour s’assurer que les procédures garantissent la prise en charge des
pratiques avancées de cybersécurité.
5.2.2 La Solution Firewall du CRDA Jendouba

Sophos UTM est la solution ultime de sécurité réseau du CRDA comprenant tout ce
dont nous avons besoin dans une Appliance modulaire unique. Bénéficiez d’une sécurité
informatique simplifiée et éliminez la complexité des solutions multipoints. L’interface
intuitive à créer rapidement des politiques de sécurité.
Sophos Firewall ne prend actuellement en charge que le VPN basé sur des stratégies et
il existe une limitation d’une association de sécurité (SA) pour les appareils VPN basés
sur des stratégies sur la passerelle de réseau virtuel AWS. C’est l’une des raisons pour
lesquelles on a recommander d’utiliser une solution d’entreprise telle que Sophos UTM
comme point de terminaison VPN dans AWS.
60
Fig. 5.1 : Interface de Connexion Sophos
5.3 Configurer le pare-feu Sophos sur site

Accédez à VPN > Politiques IPsec et cliquez sur Ajouter.les paramètres ci-dessous
correspondent aux paramètres dans AWS.
Fig. 5.2 : Connexion VPN
61
Fig. 5.3 : CRègles Filtrants CRDA AWS IPSEC
Haut disponibilité Firewall HA
Un besoin de forte disponibilité pour les services réseaux offerts par l’architecture
de sécurité, et notamment les services Web accessibles depuis Internet peut également
conduire à la mise en place d’architectures dites de « haute disponibilité » impliquant
deux équipements firewall. Toutefois, dans ce cas, il s’agit d’équipements de même type,
et généralement dotés d’un logiciel et de connexions réseau spécifiques, dédiées à la ges-
tion de la redondance.
Fig. 5.4 : Haute disponibilité
62
Fig. 5.5 : Synchronisation deux Firewall
Pour répondre au besoin de disponibilité, les deux firewalls fonctionnent généralement

en mode de redondance passive (ou secours chaud, ou primary/backup). A un instant
donné, l’un des deux équipements assure les fonctions de filtrage tandis que l’autre se
tient prêt à prendre le relais en cas de défaillance du premier. Pour cela, l’équipement de
secours doit disposer d’une version à jour de la liste des règles de filtrage, ainsi qu’une
version des tables d’états gérées dynamiquement par le firewall pour le suivi des connexions
en cours. Les deux équipements doivent également disposer d’un moyen de se surveiller
mutuellement.
Sécurité Endpoint
Plus les menaces se complexifient, plus la pression pour mettre en place une solution
Endpoint adaptée augmente. Cependant, avec un marché de la sécurité saturé de solutions
multiples et variées, chacune prétendant être la meilleure, il est devenu difficile de prendre
une décision éclairée. les technologies clés de la sécurité Endpoint pour la mettre en place
une protection adaptée à notre besoins. les résultats de test indépendants à faire les bons
choix parmi les différents éditeurs du marché.
63
Fig. 5.6 : Sophos Central
Sophos Central est un multiplicateur de force pour notre équipe. La solution nous per-
met de gérer notre pare-feu, les postes, les serveurs, les mobiles et d’autres produits Sophos
à partir d’une seule console tout en profitant de l’intégration de la Sécurité Synchronisée.
Fig. 5.7 : Liste des firewalls
5.4 WAF :web Application Filtring

Les Sophos Web Appliance sont des solutions sécurisées pour passerelles web assu-
rant une protection intégrée contre les malwares et le contenu Internet indésirable. Elles
s’articulent autour d’une plate-forme matérielle robuste qui assure une sécurité haute ca-
pacité, haute disponibilité avec une simplicité et un contrôle inégalé. Toujours en avance
par rapport à l’évolution rapide des menaces, les appliances garantissent une utilisation
d’Internet sans risque, grâce à une protection complète sur plusieurs niveaux : Protec-
tion contre les virus, les spywares, les malwares et le phishing Protection contre les sites
légitimes ayant été piratés Optimisation de la productivité et application des politiques
64
d’utilisation d’Internet Blocage des proxies anonymes Analyse du trafic chiffré HTTPS
Economie de la bande passante Prévention de la perte de donnée
Fig. 5.8 : Web Filtring
5.5 Sécurité de l’infrastructure AWS avec data center

L’infrastructure AWS a été pensée de telle sorte qu’elle constitue l’un des environne-
ments de cloud computing les plus flexibles et sécurisés disponibles à ce jour. Il est conçu
pour fournir une plate-forme extrêmement évolutive et hautement fiable qui permet aux
clients de déployer des applications et des données de manière rapide et sécurisée.
65
Fig. 5.9 : Architecture connexion VPN Aws et data Center
Cette infrastructure est conçue et gérée en suivant les bonnes pratiques et les normes
de sécurité, mais également avec les besoins spécifiques du cloud à l’esprit. AWS utilise des
contrôles redondants et multicouches, la validation et le test en continu, et une grande
part d’automatisation afin de garantir que l’infrastructure sous-jacente est protégée et
surveillés Sécurité de la Solution
Fig. 5.10 : Autoriser l’accès à l’instance déployée
66
Conclusion générale
Face au phénomène médiatique que représente le Cloud Computing actuellement, nous

avons ici effectué une définition pragmatique de cette technologie à partir de la littérature
d’experts en Cloud. Cette technologie en plein essor permet aux entreprises de disposer
d’infrastructures et de progiciels directement en ligne sur Internet. On a distingué les
différents types de Cloud possibles avec l’IAAS pour les infrastructures techniques, le
PAAS pour les infrastructures habillées avec des outils de middleware comme les bases
de données par exemple et le SAAS pour les services logiciels. Ces trois types peuvent se
déployer sous quatre formes de topologies différentes : le Cloud public pour du déporté en
ligne, le Cloud privé pour l’utilisation des concepts du Cloud en interne à l’organisation,
le Cloud hybride pour l’utilisation commune du public et du privé. Aussi, on a présenté
les plateformes les plus connus. Les plateformes actuelles tel que (OpenStack, OpenNe-
bula, MS Azure, AWS…) sont les plus connus pour faire une cloud computing efficace. De
notre part, on a choisi Amazon Web Service pour plusieurs raisons, y compris : Simplicité
d’utilisation, Flexibilité, Rentabilité, Fiabilité, Evolutivité et hautes performances, Sécu-
rité, AWS est une plateforme très puissante qui offre plusieurs services, comme exemple
(EC2, Lambda, S3…). Et comme nous ne pouvons pas exploiter tous ces services, nous
avons choisi le service de stockage dans le cloud.
S3 est le meilleur choix pour l’exploiter. Protection des données, durabilité et fiabilité
des données et suppression authentification multi-facteurs, ces derniers et autres sont les
points forts de notre choix. Le travail présenté dans ce mémoire essaye de se bénéficier au
maximum des notions de cloud computing, et plus précisément, sur la réalisation d’une
solution numérique pour le CRDA Jendouba sur le cloud, en profitons des avantage de
service de stockage de données distant et la gestion de métadonnées.
Pour atteindre ce but, la réalisation de l’application a était divisée en deux objectifs :

• Choisir une plateforme, selon une étude comparative des solutions existantes.
• Implémentation et configuration de la solution choisie et les services à exploiter.
• En perspectives de nos études peuvent apporter plus de performance et d’efficacité

à l’outil de cloud computing, ces perspectives sont :
• Profiter le maximum des services présenter par AWS
67
Conclusion générale
• Transfert les serveurs du CRDA vers le cloud. Développer plusieurs services et ap-
plications sur le cloud
• Connecter et partager les ressources de cloud avec d’autre solution cloud des autres
CRDA.
68

Dédicace: A Mes Grands-Parents Mongia Et Hamadi

Transféré par

Informations du document

Titre original

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

Dédicace: A Mes Grands-Parents Mongia Et Hamadi

Transféré par

Droits d'auteur :

Formats disponibles

Dédicace

A mes grands-parents Mongia et Hamadi

Je souhaite également remercier très chaleureusement mes collègues et amis et en

1 Contexte général et spécification des besoins . . . . . . . . . . . . . . . . 3

3 Processus de développement Et méthodologie . . . . . . . . . . . . . . . 24

5.3 Configurer le pare-feu Sophos sur site . . . . . . . . . . . . . . . . . . . . . 61

1.1 Organigramme globale de CRDA . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Comparaison entre architecture physique et virtualisée . . . . . . . . . . . 15

3.1 Modèle Sashim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 VMware vCenter Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.16 Interface de connexion CloudEndure . . . . . . . . . . . . . . . . . . . . . 50

5.1 Interface de Connexion Sophos . . . . . . . . . . . . . . . . . . . . . . . . 61

1.1 Adressage IP sites distants . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Les avantages et les inconvénients du Cloud Computing . . . . . . . . . . . 23

3.1 comparaison IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Le verrou principal étant le déploiement des « Virtual Appliance » composées d’un

Contexte général et spécification des

1.1 Présentation du projet

1.1.1 Présentation du CRDA Jendouba

1.1.2 Présentation de l’organisme d’accueil

• 23000 Ha de terre non agricole

• 114500Ha réservés pour les cultures pluviales

• 30000 Ha de périmètres irrigués.

Grâce a l’importance de la superficie des terres agricoles par rapports à la superficie

Organigramme : La figure 1.1 illustre l’organigramme général du CRDA qui contient

Fig. 1.1 : Organigramme globale de CRDA

1.1.3 Description du département informatique de la CRDA

La Direction Informatique a le rôle d’étudier, mettre en place, et maintenir des sys-

Maintenance et l’entretien du matériel informatique

Préparer le cahier de charges, lance l’appel d’offres, gère le dépouillement et choisit le

Suivit du matériel informatique

• Le matériel informatique du CRDA varie du modèle 486au pentium4.

1.1.4 Présentation du projet

1.2 Critique de l’existant

Fig. 1.2 : Architecture du Data Center de CRDA Jendouba

1.2.1 Composantes du data Center CRDA

• Deux serveurs Cisco IM Presence pour la messagerie instantanée et la présence

1.2.2 Les solutions Applicatives

1.2.3 Adressage IP sites distants

Tab. 1.1 : Adressage IP sites distants

1.2.4 Design de la virtualisation

Information UCS1 UCS2

Tab. 1.2 : Paramètres UCS

1.2.5 Configuration RAID

1.2.6 Design de la capacité et de la répartition des machines

4. Deux machines virtuelles Expressway C et E pour l’accès Jabber/VisioExter.

VM vCPU vRAM (GB) vDisk (GB)

Serveur CIMC ESXi Passerelle

Tab. 1.4 : Adresses de management

1.2.8 Spécification des besoins et études préliminaire

VM Nom de l’Hôte Adressage IP Passerelle

Tab. 1.5 : Adresses des VM

1.2.9 Projet à réaliser

1.2.10 Recueil des besoins

• La migration des serveurs physiques vers des machines virtuelles L’évolutivité de

• La gestion des sauvegardes des machines virtuelles déjà installées.

• Suggérer la meilleure architecture pour le déploiement d’OpenStack

Besoins non fonctionnels

• Intégration d’un outil de supervision pour toute la plateforme de virtualisation

• La création d’un module de facturation pour les clients Cloud.

• Déploiement rapide des applications

• Niveaux de service supérieur et disponibilité accrue des applications

• Taux d’utilisation supérieur des investissements dans l’infrastructure