Vous êtes sur la page 1sur 69

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE


Université Dr. Tahar Moulay -SAIDA-
Faculté : Technologie
Département : Informatique

MEMOIRE DE MASTER

Option :
Réseau informatique et système réparti
-RISR-

Une Stratégie de maintien de cohérence adaptative des


répliques dans l’environnement de Cloud Computing

Présentée par : Encadré par :

M.Benaoumeur Nahal M. Limam Saïd


1
Au nom de dieu le clément et le miséricordieux.

Je rends grâce à Dieu de m'avoir donné le courage et la


volonté ainsi que la conscience d'avoir pu terminer ma
mémoire de Master.
Louange à Dieu qui ma aidé, éclairé et ouverts les portes du
savoir durant mes années d’études.

C’est avec une grande joie je dédie ce mémoire :

A ma maman, à qui je dois tant et qui n’ont cessé de me


témoigner affection, soutien et encouragement durant les
longues années des études.

A mon encadreur limam.said

A toute ma famille et mes amis

A tous les étudiants de ma promotion.

Et à tous mes amis qui m’ont soutenu, encouragé durant


mes études.

2
NOUS remercions en premier lieu « Allah » de m’avoir
donnée le courage, la volonté, et la patience pour réaliser ce travail.

Nous remercions tout d’ abord M d’avoir proposé ce sujet qui


m’a permis d’enrichir mes connaissances et qui par ses conseils.

Nous s’exprime ma gratitude aux membres du jury, ainsi qu’à tous


les enseignants qui ont contribué à ma formation durant la période
universitaire.

Enfin, nous remercions tous qui contribué à la réalisation de ce travail,


de prés ou de loin.

3
Résumé

L’informatique en nuage fait référence à l’utilisation des capacités de calcul des ordinateurs
distants, où l’utilisateur dispose d’une puissance informatique considérable sans avoir à
posséder des unités puissantes. Par ailleurs, les applications utilisent et génèrent des quantités
toujours plus importantes de données souvent répliquées et partagées entre plusieurs
utilisateurs. La réplication permet d’augmenter la disponibilité des données, et réduire le
temps d’accès. Néanmoins la création de plusieurs répliques de la même donnée peut
engendrer des situations de divergence et d’incompatibilité, ce qui nécessite des mécanismes
de gestion de cohérence entre ces répliques distantes. La cohérence dépend fortement de la
politique de répartition et de partage des données dans le Cloud. Plusieurs techniques de
maintien de cohérence ont été proposées soit dans les systèmes distribués soit dans les grid
computing, ces techniques peuvent être classifié en deux familles : pessimiste ou optimiste.
Dans ce travail nous avons proposons une approche de gestion de cohérence des répliques de
l’environnement Cloud Computing. Ce dernier peut traiter le problème de cohérence et
permet d’améliorer la qualité des services offerts par l’approche optimiste et réduire le temps
de réponse obtenu par l’approche pessimiste.

Mot clés : Cloud computing, réplication, gestion de cohérence.

Abstract
Cloud computing refers to the use of the computing capacity of the remote computers, where
the user has considerable computing power without having to have powerful units. Moreover,
the applications use and generate increasingly large amounts of data often replicated and
shared between multiple users. Replication increases data availability, and reduce access time.
Nevertheless creating several replicas of the same data can lead to situations of conflict and
incompatibility, which requires management mechanisms consistency between remote
replicas. Coherence depends strongly on the distribution policy and data sharing in the cloud.
Several techniques for maintaining consistency have been proposed either in distributed or in
grid computing systems, these techniques can be classified into two families: pessimistic or
optimistic. In this work we propose an approach for consistency management of replicas of
the Cloud Computing environment. It can deal with the problem of consistency and improves
the quality of services offered by the optimistic approach and reduce the response time
obtained by the pessimisticapproach.
Keywords: Cloud computing, replication, consistency management.

4
Sommaire

5
Introduction générale…………………………………………………….………………………………………2

Chapitre I : cloud computing

I -1-Introduction………………………………………………………………………………..5
I -2-Historique……………………………………………………………………………………….5
I -3-Qu’est -ce que l’informatique en nuage ? ……………………………………...…………....6
I -3-1. Modèles de services en nuage………………………………………………………..6
I -3-2 - Avantages et Inconvénients des service……………………………………………..8
I -3-3-Caractéristiques du nuage…………………………………………………………….8
I -3-4- Modèles de déploiement du nuage ............................................................... ……….10
I -4-la nature et les avantages de l’informatique en nuage ...................................................... 12
I -5-Les risques et les inconvénients de l’informatique en nuage …………………….………13
I -6- La sécurité du cloud………………………………………………………………………......14
I -7-Le marché du cloud computing ......................................................................................... 15
I -7-1- les acteurs du cloud computing ................................................................................. 15
I -8-Conclusion ........................................................................................................................ 17

Chapitre II : réplication et cohérence de donnée


II -1-Introduction ...................................................................................................................... 19
II -2- la réplication ................................................................................................................... 20
II -2-1-définitions ................................................................................................................. 21
II -2-2-Avantages de la réplication ....................................................................................... 21
II-2-3-Inconvénients de la réplication .................................................................................. 22
II-2-4-Caractéristiques d'un protocole de réplication ........................................................... 22
II-2-5-Protocoles de réplication ............................................................................................ 23
II-2-6-Quelque exemples des problèmes de réplication des données ................................... 27
II-3- Gestion de la cohérence .................................................................................................... 28
II-3-1-définition de cohérence .............................................................................................. 28
II-3-2- Protocoles de cohérence ............................................................................................ 29
II-4-Conclusion ........................................................................................................................ 33

6
Chapitre III : modèle proposépour la gestion de cohérence

III-1-Introduction ........................................................................................................................ 35
III-2-Modèle proposé.......................................................................................................................... 36
III-3-description du modèle .......................................................................................................... 36
III-3-1-Service de gestion de cohérence locale ................................................................................. 37
III-3-2-Service de gestion de cohérence globale: ............................................................................. 37
III-4- Conception du modèle ........................................................................................................ 38
III-4-1-Diagramme de classes .......................................................................................................... 38
III-4-2-Diagramme de d'activité................................................................................................ 38
III-5-Algorithme de base du modèle proposée .............................................................................. 40
III-5-1- Notations ............................................................................................................................. 40
III-5-2- fonctionnement de l’algorithme ........................................................................................... 41
III-6-Métriques utilisées ...................................................................................................................... 43
III-6-1- Mesure de la performance ................................................................................................... 43
III-6-2-Mesures de la qualité de service ........................................................................................... 44
III-7-Conclusion .................................................................................................................................. 45

Chapitre IV : implémentation et simulation


IV-1-Introduction ................................................................................................................................. 47
IV-2-Langage et environnement de développement ............................................................................. 47
IV-2-1 -Pourquoi Java ? ................................................................................................................... 47
IV-2-2-Environnements de développement ...................................................................................... 48
IV-2-3-CloudSim ............................................................................................................................. 48
IV-3- Description du fonctionnement de notre application .................................................................. 50
IV-3-1- Diagramme d’utilisation ...................................................................................................... 51
IV-3-2-Diagramme de classes .......................................................................................................... 52
IV-4-Interface principale ...................................................................................................................... 53
IV-5-Exprémentations .......................................................................................................................... 55
IV-5-1-experience1 :impact le nombre des cloulets ......................................................................... 55
IV-5-2-experience2 :impact le type des cloulets………………………………...…..…………...…57

IV-5-3-experience3 :impact le nombre des réplique………………………..….……………………58

IV-6-Conclusion ................................................................................................................................... 58

Conclusion générale et perspectives…………………………………………..…………60

Bibliographie…………………………………………………………………………...…62
Lites des figures

7
Lites des figures
Fig. I.1- les défirent service des cloud .................................................................................................... 6
Fig. I.2 - les défirent service du Cloud ................................................................................................... 7
Fig. 1.3 -les défirent architecture des cloud .......................................................................................... 11
Fig. 1.4 –marché du cloud computing ................................................................................................. 15
Fig. 1.5 -les acteurs principaux du cloud .............................................................................................. 16
Fig.II.1 -Environnement d'utilisation de la technique de réplication .................................................... 20
Fig.II.2 - Exemple de protocole de réplication passive ......................................................................... 24
Fig.II.3 - Exemple de protocole de réplication active ........................................................................... 25
Fig.II.4 - Exemple de protocole de réplication semi-active .................................................................. 26
Fig.II.5 -problème de performance ....................................................................................................... 27
Fig. II.6- Vue cohérente des données ................................................................................................... 28
Fig. II.7 - Accès aux données répliqué ................................................................................................. 29
Fig.III.1 - Cohérence vs Disponibilité .................................................................................................. 35
Fig.III. 2-positionnement de notre approche ........................................................................................ 36
Fig.III. 3-exemple de notre modéle ...................................................................................................... 36
Fig.III. 4-principales fonctions d’un broker de répliques ..................................................................... 37
Fig.III. 5- Diagramme de classes du modèle de cohérence proposé ..................................................... 38
Fig.III. 6- Diagramme d’activité de notre modéle ................................................................................ 39
Fig. IV.1 .Architecture de CloudSim………………………………………………...….......................50

Fig.IV.2 .Diagramme d’utilisation du simulateur ................................................................................. 51


Fig. IV.3 .Diagramme de classe de la conception de simulateur Cloud Sim ........................................ 53
Fig. IV.4 configuration du datacenter ................................................................................................... 53
Fig. IV.5 configuration des machines virtuelle ..................................................................................... 54
Fig. IV.6 .configuration du cloudklet ................................................................................................... 54
Fig. IV.7 .gestion de cohérence…..……………………………………………..………………….….55

Fig. IV.8 .Variation temps de réponse moyen/nombre des cloudlets .................................................... 56


Fig. IV.9 .Variation temps de réponse moyen/type des cloudlets ......................................................... 57
Fig. IV.10 .Variation temps de réponse moyen/nombre des répliques ................................................. 58
lites des tableaux
Tab. I.1 .Les avantages et les inconvénients des différents services……………………………………8

Tab. II.1. Comparaison des protocoles (Pessimiste et Optimiste)....................................... …………..32


Tab.III.1 . Tableau de notations........................................................................................................... .40
Tab. IV.1. résultat de la variation de temps moyen de réponse /nombre cloudlet……………...……..56

Tab. IV.2.résultat de la variation de temps moyen de réponse /nombre réplique…………………….58

Tab. IV.2.résultat de la variation de temps moyen de réponse /nombre réplique…………………….58

8
Introduction
générale

9
La connexion à grande échelle entre des ordinateurs distribués a différent emplacement aux
réseaux de communication et les mécanismes qui permettent leur interopérabilité ont permis
la mise en œuvre des applications utilisant de très grandes masses de données. Les quantités
de données utilisées par ces applications d’échelonnements jusqu' à l'ordre du mille PetaOctet
en stockage par exemple:
- un million de machines stockant chacune 1 Go de fichiers multimédia
- un million de machines transférant chacune 1Mb/s de fichiers multimédia
Mais ce grand volume de masse de données crée plusieurs problèmes comme le stockage, la
sécurité…
A l'heure actuelle, les infrastructures logicielles utilisées pour stocker et traiter ces grandes
masses de données sont :
-l’informatique en nuages (cloud computing), les systèmes de grilles (GRID)…
Tous les grands projets scientifiques et industriels actuels essayent d'utiliser les
infrastructures de type cloud, pour tirer profit de leurs capacités en puissance de calcul et en
stockage de données. Ce type d'infrastructure constitue un environnement privilégié pour le
partage de ressources et de services. Les techniques de partage, utilisées par les cloud
computing, sont le plus souvent basées sur le principe de réplication pour assurer :
- une disponibilité très élevée des données
- Accélérer le temps d’accès aux données.
Dans ce contexte, un même objet (fichier, base de données, service, programme, etc.) peut
être répliqué en autant de copies que nécessaire. Chaque copie étant détenue et accédée par un
ou plusieurs utilisateurs, leur gestion pose un problème de nature complexe, à savoir le
maintien de leur cohérence.
La complexité de gestion de cette cohérence est due à plusieurs facteurs, parmi lesquels les
plus importants sont :
-le nombre très élevée de répliques ;
- l'espace de stockage des répliques qui est en général très largement distribue De plus,
l'utilisation de techniques de réplication pose des problèmes particuliers, comme :
-Trouver le bon placement des répliques ; Décider pour un objet donnée, du nombre minimal
(ou maximal) de répliques; Choisir une réplique lors d'une demande d'accès...)
Les approches existantes pour la gestion de la cohérence de répliques offrent un ensemble
limité de garanties d'un point de vue performance et qualité de service.

10
Deux familles d'approches sont actuellement utilisées pour maintenir la cohérence de
répliques : les approches pessimistes et les approches optimistes.
Le but principale de ce travail et de trouver une solution pour résoudre le problème de
cohérence des répliques dans les cloud computing, avec comme objectif la nécessité de
garantir les performances et la qualité des services comme : la disponibilité, le temps d’accès
Notre contribution consiste à proposer un modèle pour la gestion de la cohérence de répliques
dans les cloud computing, qui combine à la fois les approches pessimistes, qui favorisent la
qualité de service, et les approches optimistes qui se focalisent sur l'amélioration des
performances

Pour l’essentiel, notre mémoire est structuré autour en quatre chapitres avec une introduction
est conclusion générale.
Chapitre I:Initiation au terme de l’informatique en nuages ou cloud computing.
Le Cloud Computing fait référence à l’utilisation des capacités de calcul des ordinateurs
distants, où l’utilisateur dispose d’une puissance informatique considérable sans avoir à
posséder des unités puissantes. Par ailleurs, les applications utilisent et génèrent des quantités
toujours plus importantes de données souvent répliquées et partagées entre plusieurs
utilisateurs.
Chapitre II: Intitule Protocoles de réplication et de cohérence, ce chapitre rappelle les
fondements des protocoles de réplication de données et le problème de gestion de la
cohérence de données répliquées. Après une description des protocoles de gestion de la
cohérence.
Chapitre III:Dans ce chapitre, nous avons proposé un modèle pour la gestion de cohérence
des répliques dans les cloud computing. Ce modèle est composé en deux services :
-service de gestion de cohérence locale
-service de gestion de cohérence globale
Chapitre IV: Dans ce chapitre nous implémenté notre approche proposé dans le chapitre 3
ainsi que les résultats de simulation obtenus.

11
Chapitre I :
Cloud
computing

12
I-1-Introduction
L'informatique en nuage (cloud computing) peut se résumer au stockage, au traitement et à
l'utilisation de données contenues dans des ordinateurs distants et aux quelles on accède par
Internet.
Cela signifie que les utilisateurs peuvent mobiliser une puissance de calcul quasi illimitée à
la demande, qu'ils ne doivent pas faire de gros investissements financiers pour satisfaire leurs
besoins et qu'ils peuvent accéder à leurs données de partout à l'aide d'une connexion Internet.
L'informatique en nuage a le potentiel de réduire les dépenses informatiques et de
permettre le développement de nombreux services nouveaux. Grâce au nuage, même les plus
petites entreprises peuvent atteindre des marchés toujours plus vastes et les administrations
peuvent rendre leurs services plus attrayants et efficaces tout en maîtrisant les dépenses.
De même que le Web met l'information à la disposition de tous et partout, l'informatique en
nuage rend la puissance de calcul disponible à tout un chacun où qu'il se trouve. À l'instar du
Web, l'informatique en nuage représente une évolution technologique qui a débuté il y a
quelque temps et qui va se poursuivre. Cependant, à la différence du Web, le nuage
informatique n'en est encore qu'à un stade relativement précoce, ce qui laisse à l'Europe une
chance d'intervenir pour faire en sorte de se positionner à l'avant-garde de son développement
futur et en tirer bénéfice, du côté de la demande comme de l'offre, en généralisant l'utilisation
et la fourniture de services en nuage.[1]

I-2-Historique

Il n'y a pas de date-clé à laquelle nous puissions dire que le Cloud Computing est né !
La notion de Cloud fait référence à un nuage, tel que l'on a l'habitude de l'utiliser dans des
schémas techniques lorsque l’on veut représenter Internet. Un réseau comme Internet est
constitué d'une multitude de systèmes fournissant des services et des informations. Le Cloud
Computing est dans cette lignée : un ensemble de services et de données consommables .[2]

13
I-3-Qu’est -ce que l’informatique en nuage ?
Bien qu’il n’existe aucune définition officielle de l’informatique en nuage, celle du
National Institute of Standards and Technologie(NIST) est plus ou moins devenue la norme
de facto. Comme nous allons le voir plus en détail ci-après, cette définition traite des éléments
suivants :
1. Les modèles de services en nuage,
2. Les caractéristiques de l’informatique en nuage,
3. Les modèles de déploiement du nuage.

I-3-1. Modèles de services en nuage


Les modèles de services en nuage sont couramment qualifiés de «modèles SPI», car ils
reposent sur les services de base proposés par les fournisseurs de services en nuage (voir la
figure I.1)
-SaaS (Software as-a-Service, ou logiciel-service),
-PaaS (Platform-as-a-Service, ou plateforme-service)
- IaaS (Infrastructure asa- Service, ou infrastructure-service)

Fig. I.1- les défirent service des cloud

Que sont plus exactement ces trois couches, quels sont leurs modes de fonctionnements et
leurs périmètres ? (voir la figure I.2) le Cloud Computing fournissent un service complet de
les couches les plus basses jusqu’à l’utilisateur. [2]

14
Fig. I.2 - les défirent service du Cloud

a- L’infrastructure comme un service (IAAS)


L’infrastructure fournit des capacités de calcul et de stockage ainsi qu'une connectivité réseau.
Les serveurs, systèmes de stockage, commutateurs, routeurs et autres équipements, sont mis à
disposition pour gérer une charge de travail demandée par les applications.
L'infrastructure comme un service ou IaaS, permet de disposer d'une infrastructure à la
demande, pouvant héberger et exécuter des applications, des services ou encore stocker des
données.
Concrètement, cela se caractérise par une infrastructure physique souvent mise à disposition
par un fournisseur de services. On y trouvera une solution de virtualisation permettant la
création de « Datacenter virtuels ».

b –la plateforme comme un service (PAAS)


La plate-forme comme un service est la plate-forme d’exécution, de déploiement et de
développement des applications.
- Celui qui fournit une plate-forme intégrant le système d'exploitation (OS), la couche
middleware et celle applicative qui sont fournies ensuite au client comme un service.
- Un service métier encapsulé et présenté via une API. Le client interagit avec cette plate-
forme grâce à une API pour construire un service de plus haut niveau: la plate-forme se gère
et s'adapte elle-même pour fournir le niveau de service attendu.
Le PaaS met à disposition des environnements prêts à l’emploi, fonctionnels et performants.

15
c- le logiciel comme un service (SAAS)
La dernière couche du SaaS est celle applicative mettant à disposition des applications
complètes fournies à la demande. On y trouvera différents types d'application allant du CRM,
à la gestion des ressources humaines, comptabilité, outils collaboratifs, messagerie, BI et
d'autres applications métiers.
Il n’y a donc aucun pré requis sur le poste client si ce n'est d'avoir un accès réseau au
Cloud (en général Internet). Le déploiement, la maintenance, la supervision du bon
fonctionnement de l'application et la sauvegarde des données, sont alors de la responsabilité
du fournisseur de services.

I-3-2- Avantages et Inconvénients des services


Le tableau I.1 illustre les services de Cloud Computing qui ont été décrites dans la section
précédente tout en montrant les avantages et les inconvénients de chaque service [18].

Avantage inconvénient
Saas -pas d’installation -logiciel limité
-plus de licence -sécurité
-migration -dépendance des prestataires
PaaS -pasd’infrastructure nécessaire -limitation des langages
-pas d’installation -pas de personnalisation dans la
-environnement hétérogène configuration des machines virtuelles

IaaS -administration -besoin d’un administrateur système


-personnalisation -sécurité
-flexibilité d’utilisation

Tab. I.1 -Les avantages et les inconvénients des différents services

I-3-3. Caractéristiques du nuage

En plus de définir des modèles de nuage spécifiques, le NIST a identifié les caractéristiques
clés d’un nuage :
- Large accès au réseau : comme l’indique le terme «nuage», le traitement s’effectue chez le
fournisseur de services en nuage. L’utilisateur a donc la possibilité d’accéder à l’application
par l’intermédiaire d’un navigateur ou d’une autre «plateforme client légère ou lourde»
installée sur son bureau, son téléphone intelligent, sa tablette ou tout autre appareil
informatique.

16
-Élasticité rapide : et «libre-service à la demande» : l’informatique en nuage a la capacité de
s’étendre et de se réduire à la demande. Si la demande de l’entreprise en ressources
informatiques augmente, lefournisseur de services en nuage peut augmenter son
approvisionnement en ressources de façon entièrement automatisée, sans aucune intervention
manuelle de sa part.
-Service mesuré : et tarification à l’utilisation : le NIST souligne que les services doivent être
délivrés de façon transparente pour l’utilisateur.
Du point de vue de la tarification, cela signifie que les services en nuage sont vendus en
fonction de l’utilisation plutôt que de nécessiter un investissement initial important en termes
de matériel, de logiciel ou de quantité de ressources informatiques. Les nuages permettent au
client de payer uniquement pour les ressources qu’il utilise, tout comme pour les services
publics; c’est ce qu’on appelle l’«informatique à la demande».
L’unité de mesure de l’utilisation varie d’un fournisseur à l’autre. Par exemple,les services
AWS sont vendus à l’heure, alors que la tarification de
Google Apps est basée sur le nombre d’utilisateurs.
-Mise en commun des ressources : les vendeurs de services informatiques peuvent desservir
plusieurs clients avec des ressources informatiques mises en commun qui utilisent «un modèle
de service partagé dans lequel différentes ressources physiques et virtuelles sont affectées et
réaffectées dynamiquement en fonction de la demande du client».
Une des conséquences de ce modèle est que l’emplacement physique exact des ressources
informatiques peut ne pas être connu, mais peut se trouver à un niveau d’abstraction plus
élevé (par exemple un pays, un état ou un centre de traitement)».

I-3-4 - Modèles de déploiement du nuage

Comme nous l'avons vu, le Cloud Computing repose sur des ressources physiques. La
question est « où sont ces ressources physiques ? » (Serveurs, commutateurs, routeur,
solutions de stockage, etc.).
La réponse « dans le nuage » n'est pas vraiment acceptable. Du point de vue consommateur,
l'abstraction est telle qu'on ne peut déterminer sur quelles ressources physiques l’application
est hébergée. De par son côté dynamique, les ressources physiques hébergeant une application
et des données dans un Cloud ne sont jamais fixes et évoluent dans le temps.

17
En théorie, le Cloud Computing n'impose aucune dépense en immobilisation. Comme c'est le
cas avec la solution de messagerie décrite, on exploite généralement les ressources physiques
d'un fournisseur de Cloud.
Cependant cette technologie de Cloud Computing peut très bien se retrouver sur
l’infrastructure physique d'une entreprise : n’étant plus mutualisé, le Cloud reste privé : on
parlera alors de Cloud public, de Cloud privé et de Cloud hybride. [2] (voir la figure I.3)

a-le cloud privé

Ces ressources physiques peuvent être hébergées dans une infrastructure propre à l'entreprise
et étant sous son contrôle, à sa charge donc de contrôler le déploiement des applications.
Nous reviendrons sur cette notion de Cloud privé, mais nous pouvons d'ores et déjà nous
demander si « un Cloud privé est réellement un Cloud ? ». En effet, dans le sens où, comme
nous l'avons dit plus haut, un Cloud ne doit pas imposer de dépenses en immobilisations,
l'infrastructure physique dans un Cloud privé est à la charge de l'entreprise.
Le Cloud privé peut aussi désigner un Cloud déployé sur une infrastructure physique dédiée et
mise à disposition d'un fournisseur de services.

b-le cloud public


Un Cloud public est un service IaaS, PaaS ou SaaS proposé et hébergé par un tiers. Amazon,
Google et Microsoft propose un Cloud public dans lequel n'importe quel particulier ou
n’importe quelle entreprise peut y héberger ses applications, ses services ou ses données. Pour
les consommateurs, il n'y a donc aucun investissement initial fixe et aucune limite de capacité.

c-le cloud hybride

Un Cloud Hybride est l’utilisation de plusieurs Clouds, publics ou privés.


On peut ainsi déporter nos applications vers un Cloud public qui consommera des données
stockées et exposées dans un Cloud privé, ou bien faire communiquer deux applications
hébergées dans deux Clouds privés distincts, ou encore consommer plusieurs services
hébergés dans des Cloud publics différents.

18
Fig.I.3 -les défirent architecture des cloud

I-4-la nature et les avantages de l’informatique en nuage


L'informatique en nuage présente une série de caractéristiques définitoires (qui ne permettent
pas d'en établir aisément une définition générale), à savoir:[3]
- le matériel (ordinateurs, dispositifs de stockage) est détenu par le fournisseur de service
informatique en nuage et non par l'utilisateur qui interagit avec lui par l'intermédiaire
d'Internet;
-l'utilisation du matériel est optimisée de façon dynamique à travers un réseau d'ordinateurs si
bien que la localisation exacte des données ou des processus ainsi que l'information relative à
l'élément de matériel qui sert effectivement à un utilisateur particulier à un moment donné ne
doivent pas, en principe, concerner l'utilisateur même si cela peut avoir une incidence majeure
sur le cadre juridique applicable;
- les fournisseurs de services en nuage font souvent circuler les charges de travail de leurs
utilisateurs (par ex. d'un ordinateur à l'autre ou d'un centre de calcul à l'autre) afin d'optimiser
l'utilisation du matériel disponible;
- le matériel distant stocke et traite les données et les met à disposition à l'aide d'applications
par exemple (de sorte qu'une entreprise pourrait recourir à ses ressources informatiques en

19
nuage de la même façon que les particuliers utilisent aujourd'hui leurs comptes de messagerie
électronique);

- structures et particuliers peuvent accéder à leur contenu et utiliser leurs logiciels où et quand
ils en ont besoin, par exemple sur un ordinateur de bureau, un ordinateur portable, une tablette
ou un téléphone intelligent;
- les utilisateurs payent en principe selon leur consommation, ce qui évite les coûts initiaux et
fixes importants qu'il faut supporter pour configurer et exploiter un équipement informatique
sophistiqué;
-en même temps, les utilisateurs peuvent très aisément faire varier le volume de matériel dont
ils ont besoin (par. exemple. se procurer en quelques secondes, à l'aide d'un clic de souris, une
capacité supplémentaire de stockage en ligne.

I-5-Les risques et les inconvénients de l’informatique en nuage


La délocalisation de données est toujours risquée. à cet égard, l’informatique en nuage pose
entre autres les problèmes énumérés ci-dessous. [4]
- Perte de contrôle sur les données. L’interconnexion mondiale et l’utilisation de la mémoire
virtuelle font qu’il est souvent impossible de localiser les données, notamment lorsqu’on a
recours à des nuages publics. Le maître des données ne sait donc pas où les données qu’il a
déposées dans le nuage sont enregistrées et traitées alors qu’il répond de leur utilisation
- Manque de séparation et d’isolation des données. L’informatique en nuage implique que
les données de plusieurs utilisateurs qui n’ont aucun lien entre eux soient traitées dans le
même nuage et par le même système (architecture partagée). Cela augmente le risque qu’une
attaque contre un des utilisateurs affecte également les autres. À la suite d’une attaque de
hackers ou de déni de service, les données peuvent être indisponibles voire volées.

- Non-respect des dispositions légales. Dans l’informatique en nuage, il peut arriver que
certaines parties d’un ensemble de données soient enregistrées dans plusieurs centres situés
dans le monde entier. Cette dissémination peut poser des problèmes non seulement du point
de vue de la protection et de la sécurité des données, mais aussi pour le respect d’autres
obligations légales (conservation des données et des preuves, sauvegarde du secret, etc.).

- Accès d’autorités étrangères aux données. Dans de nombreux cas, les données destinées à
être traitées dans le nuage sont communiquées à l’étranger. Elles sont alors souvent

20
enregistrées ou traitées dans des pays qui ne leur assurent pas une protection suffisante. Les
prestataires de services en nuage peuvent se voir ordonner par des autorités ou des tribunaux
étrangers de donner accès aux données enregistrées dans le nuage, même si ces données ne
sont pas traitées ou enregistrées dans le pays en question.

- Perte de données. Les données en nuage peuvent être volées, effacées, écrasées par erreur
ou subir d’autres modifications entraînant leur perte. L’entreprise qui recourt à un service sans
système de sauvegarde des données originales court donc d’énormes risques juridiques, qui
peuvent menacer son existence lorsque la perte des données porte sur son savoir-faire
technique, d’autres secrets d’entreprise (liste de clients, bases de calcul des prix de revient) ou
la comptabilité.

- Pannes de système et de réseau et non-disponibilité des ressources et des services. Des


pannes dans le nuage peuvent entraîner des pertes de données ou impliquer l’accès de
personnes non autorisées aux données (la confidentialité, la sécurité et l’intégrité des données
ne sont alors plus garanties). Ces pannes peuvent en outre paralyser le fonctionnement d’une
entreprise ou d’une autorité: un tel scénario entraînerait non seulement des pertes financières,
mais aussi de graves conséquences pour la réputation de l’organisation concernée.

I-6- La sécurité du cloud


La sécurité permet de garantir la confidentialité, l'intégrité, l’authenticité. [2]
1- La confidentialité
La confidentialité assure que les données d'un client ne soient accessibles que par les entités
autorisées. Les différentes solutions de Cloud Computing comportent des mécanismes de
confidentialité comme la gestion des identités et des accès, l’isolation ou le cryptage.
2- L’intégrité
Les clients qui cherchent à externaliser leurs données peuvent évidemment s'attendre à être
protégés contre les modifications non autorisées. Les systèmes dans les nuages fournissent un
certain nombre de mécanismes de protection de l'intégrité des données.
3- La sécurité de l’exploitation et la sécurité physique
Les personnes et les processus qui opèrent dans la gestion d’un Cloud sont les caractéristiques
de sécurité les plus importants d'une plate-forme dans les nuages.
Les développeurs et administrateurs d’une plateforme de Cloud ont, de par leur conception,
des privilèges suffisants pour remplir leurs fonctions assignées pour exploiter et faire évoluer

21
le service. Les fournisseurs de services déploient des combinaisons de contrôle préventif,
détective et réactif :
-accès sécurisé aux données sensibles
-combinaison de contrôle en qui améliore grandement la détection d'activités malveillantes
-plusieurs niveaux de surveillance (monitoring), d'enregistrement (logging) et de rapports
(reporting) .

I-7-Le marché du cloud computing


Comme le prédisait le cabinet Gartner, l'année 2010 fut celle du Cloud Computing et la
tendance n'est pas prête de s'inverser. Avec une croissance d'environ 25 %, le marché du
Cloud Computing représentait plus de 68 milliards de dollars en 2010 d'après leur étude «
Forecast: Public Cloud Services, Worldwide and Regions, Industry Sectors, 2009-2014 », une
tendance qui va se poursuivre jusqu'en 2014 où le marché atteindra près de 149 milliards de
dollars. [2] (voir la figure I.4 )

2020
2015 270 milliard
2012 40% de dollar
30%
2009
25%

Fig. 1.4.marché du Cloud Computing

I-7-1- les acteurs du cloud computing


Ce marché est partagé entre plusieurs acteurs : les éditeurs, les fournisseurs et les « pures
players ». (la figure. 1.5.)
D'après l'étude de Markless International « Approches d’hébergement avec le Cloud
Computing & la virtualisation- Référentiel de pratiques », les entreprises interrogées
mentionnent avoir recours à plus de 60 prestataires. De plus en plus d'éditeurs portent leurs
produits en mode SaaS et les éditeurs SaaS entrent comme « Pure Player ».
a-les éditeurs
On retrouve ici des éditeurs proposant des solutions Cloud. Un éditeur n'est pas forcément un
fournisseur de services, autrement dit son périmètre n'est pas de fournir un service Cloud,

22
mais plutôt de fournir une technologie capable d'héberger une solution Cloud. Cependant la
frontière est mince car bon nombre d'éditeurs sont fournisseurs de leurs propres produits.
VMware est un éditeur de produits de virtualisation. Comme beaucoup d’autres éditeurs,
VMware s’est lancé depuis 2008 à la conquête du Cloud Computing. Aujourd'hui, il édite des
produits pour la couche IaaS comme « vSphere » et « vCloud Director », « vFabric » pour la
couche PaaS ou encore Zimbra racheté cette année pour développer ses produits SaaS.
b- les fournisseurs
Les fournisseurs de services de Cloud Computing sont des hébergeurs tels que l'on a
l'habitude de les retrouver depuis plusieurs années sur Internet. Ils mettent à disposition des
infrastructures physiques proposant une plate-forme de Cloud.
On peut citer Microsoft avec sa plate-forme d’IaaS, de PaaS et de SaaS au travers de «
Windows Azure » et « Office 365 », Google avec son service SaaS « Google App » et son
PaaS « Google App Engine ».
On retrouve aussi le géant Amazon avec ses services de IaaS et PaaS comme « Elastic
Compute Cloud (EC2) », « Elastic MapReduce » ou encore « Simple Storage Service (S3) ».
c –pures Player
Enfin les Pures Player, en français les « purs joueurs », qui jouent d'emblée la carte du service
en ligne. C'est le cas par exemple de Salesforces créé en 1999 par Marc Benioff qui est
considéré comme l'un des pionniers du modèle SaaS.
d -open source
On retrouve aussi l'initiative open source dans le Cloud Computing. C'est notamment le cas
avec Ubuntu qui propose sa distribution « Ubuntu Entreprise Cloud » mettant à disposition un
IaaS pouvant être déployé sur ses propres infrastructures. Il y aussi des acteurs tels que
Novell, Sun, Eucalyptus ou encore avec AppScale.

Fig. 1.5.Les acteurs principaux du Cloud

23
I-8-Conclusion
De l'informatique utilitaire des années 60, au service bureau des années 70, tout en passant par
l'émergence d'Internet et des avancées de virtualisation, le Cloud Computing comme les
chiffres nous le confirme, est promis à un bel avenir.
Il reste encore beaucoup à faire notamment concernant la sécurité ou l'interopérabilité, mais
aussi la mise en place de normes et de standards, qui permettront, comme c'était le cas lors du
développement d’Internet, de constituer un ensemble de systèmes hétérogènes.
Comme pour toute nouveauté technologique, il faut attendre les réelles expériences des
entreprises pour pouvoir mesurer le retour sur investissement de ces solutions et rassurer les
plus réfractaires aux innovations et par là même les pousser à y adhérer.
L'informatique dans le nuage est un concept jeune et en constante évolution. Une des
évolutions les plus prometteuses d.après la communauté scienti.que est le déploiement
d'applications distribuées sur une fédération de nuages. En effet, ce mode de déploiement
permet, entre autres, d.atténuer le risque de verrouillage propriétaire, de stimuler la
concurrence des déférents fournisseurs d'infrastructure dans le nuage, et de contrôler une
partie de la confidentialité des données utilisées par les applications.
Déployées dans le nuage. Néanmoins, la gestion des ressources informatiques provenant de
plusieurs nuages est un dé technologique et scientifique d'actualité. En effet, la grande taille
des fédérations de nuages et l'hétérogénéité des ressources qui les composent sont des aspects
difficilement pris en compte par les solutions de l'informatique dans le nuage d'aujourd'hui.

24
Chapitre II :
Réplication et
cohérence des
données

25
II -1-Introduction

La réplication des données sur plusieurs nœuds est une solution efficace pour obtenir de
bonnes performances et une meilleure disponibilité des données. Le traitement en parallèle
des demandes d'accès améliore les performances en termes de temps de réponse et de Charge
acceptable par le système.

De plus, une donnée ne devient indisponible que si tous les nœuds qui en possèdent une copie
tombent en panne simultanément, d'offre une meilleure disponibilité des données.
En fin, la réplication permet de repartir la charge entre les nœuds. Le problème général lie à
la réplication est celui de la cohérence des données, qui consiste à mesurer le degré de
similitude entre ces répliques.
Du point de vue des demandes d'accès, la gestion de la concurrence locale se préoccupe de
leur isolation, c'est-a-dire de les exécuter en parallèle en évitant qu'une mise à jour soit visible
par d'autres demandes d'accès tant qu'elle n'a pas été validée. Du point de vue des données, la
gestion des copies doit assurer leur cohérence mutuelle, c'est-à-dire que toutes les copies d'une
donnée soient identiques. Sans contrôle, l'exécution simultanée des demandes d'accès peut
conduire à des phénomènes indésirables. Néanmoins, accepter de vivre avec certaines
imperfections peut améliorer la performance du système en améliorantla concurrence.

26
II-2- la réplication
La réplication de données (la duplication de données sur plusieurs nouds), comme il est
montre dans la Figure(II.1) est une solution efficace pour obtenir de bonnes performances et
une meilleure disponibilité de données. L'objectif principal de la réplication est, de faciliter
l'accès aux données, tout en augmentant la disponibilité, soit parce que les données sont
copiées sur différents sites permettant de repartir les requêtes, soit parce qu'un site peut
prendre la relève lorsque le serveur principal s'écroule.

Le traitement parallèle des demandes d'accès améliore les performances en laissant les
utilisateurs accéder aux données dans un nœud voisin pour éviter l'accès aux données dans un
site distant. La réplication fournit également une meilleure résistance aux pannes et un
meilleur temps de réponse [5].

Fig.II.1 -Environnement d'utilisation de la technique de réplication

Ce processus peut prendre plusieurs formes [6]


Aucune réplication : les données ne sont pas dupliquées entre les sources du système,
Centralisation du système.
Réplication partielle : des données sont répliquées sur quelques sources du système.
Réplication totale : des données sont répliquées sur toutes les sources du système.
Il faut bien distinguer entre la réplication et autre type de partage de données [7]:
Répliquer Vs Sauvegarder : les données sauvegardées ne changent pas dans le temps,
reflétant un état fixe des données, tandis que les données répliquées évoluent sans cesse à
mesure que les données sources changent.
Répliquer Vs Copier : à la différence de copier, la réplication gère la cohérence des
répliques, donc une réplique est plus qu’une copie.
La réplication implique plusieurs sites interconnectés, ça nous mène à penser directement sur
des systèmes distribués tels que les bases de données réparties, les grilles …

27
II-2-1-définitions
Définition : la réplication permet de faire une ou plusieurs copies parfaites d’un objet
physique ou logique [8]

Deux opérations sont importantes pour définir la réplication : [8]

*opération de création *opération de placement

Création : crée signifier reproduire la structure et l’état de l’objet à réplique , mais quel est le
type de copié à reproduire et sur quoi est basé basée la réplication pour sélectionner les
copies à répliquer ?

Le type de copies est généralement choisi en fonction des domaines d’application des
protocoles, cependant le critère de sélection est appliqué par les protocoles de réplication
pour décider de la nécessité de dupliquer une copie ou non et cela dépend des objectifs de
performance des protocoles.

Placement : il est nécessaire de savoir ou faut-il placer les répliques dans le but d’améliorer
les performances d’accès .cela est possible en prenant en compte les caractéristiques des
enivrement d’exécution des utilisateurs.

II-2-2-Avantages de la réplication
Parmi les avantages de la réplication on a : [6]
a. Une amélioration de la fiabilité ou bien une sûreté de fonctionnement :
1. Si une copie tombe en panne, il est toujours possible d’obtenir les données à partir
d’une autre copie.
2. La redondance permet une meilleure protection contre la corruption de fichiers.
b. Amélioration des performances :
1. Diviser la charge de travail entre plusieurs serveurs ;
2. Extensibilité géographique en rapprochant les serveurs des clients.

c. Une disponibilité de données :


Les données sont disponibles localement et non plus par le biais de connexions des réseaux,
elles sont accessibles localement, même en l’absence de toute connexion à un serveur
central,de sorte que l’utilisateur n’est pas coupé de ses données en cas de défaillance d’une
connexion réseau longue distance.

28
d. Temps de réponse :
La réplication améliore les temps de réponse des requêtes d’interrogation pour deux raisons :
- Les requêtes sont traitées sur un serveur local sans accès à un réseau étendu, ce qui
accélère le débit.
- Par ailleurs, le traitement local allège la charge du serveur de bases de données central, ce
qui permet de moins solliciter le processeur.

II-2-3-Inconvénients de la réplication
Malgré tous les avantages qu'elle procure, la technique de réplication soulève un certain
nombre de problèmes que nous allons aborder succinctement dans ce qui suit : [9]
1- Placement des répliques : Ce problème consiste à choisir, en fonction des objectifs des
applications et de la réplication, des localisations physiques pour les répliques, qui réduisent
les coûts de stockage et d'accès aux données.
2-Choix d'une réplique : Il s'agit ici de sélectionner, parmi toutes les répliques d'une donnée,
celle qui est la meilleure du point de vue de la consistance ;
3- Degré de réplication : Ce problème concerne la recherche du nombre minimal de
répliques qu'il faut créer pour une donnée, sans réduire les performances des applications. Ce
degré peut être déterminé d'une manière prédictive ou adaptative.
4-Cohérence des répliques : Parmi les problèmes liés à la réplication, le problème de la
cohérence est sans doute celui qui est le plus complexe.

II-2-4-Caractéristiques d'un protocole de réplication


Dans un système distribué, dés lors qu'un objet O est répliqué, il est nécessaire de définir
l'algorithme utilisé pour gérer les différentes copies ou répliques de cet objet. Dans la
littérature, cet algorithme est désigne par protocole de réplication (ou politique de réplication).
Un protocole de réplication doit permettre de décrire les éléments suivants : [9]

- Les interactions internes à O, c'est-à-dire les interactions entre les différentes copies de O.
- Les interactions externes à O, c'est-à-dire les interactions entre les copies de O et les autres
composants du système.
Pour le bon fonctionnement d'un protocole de réplication, quatre questions fondamentales se
posent et auxquelles doit répondre un protocole de réplication
1-Stratégie du Quoi : Quelles sont les entités à répliquer ? Quel est leur type ?
2. Stratégie du Comment : Comment une copie est-elle créée ? Quelles sont les informations
répliquées ?

29
3-. Stratégie du Quand : Quand une copie est-elle créée ? Est-elle créée statiquement avant
l'exécution, ou dynamiquement en cours d'exécution ?
4. Stratégie du Ou : Ou une copie s'exécute-t-elle ? Comment le placement répond- il aux
objectifs de mise à l'échelle, de performances et de tolérance aux pannes ?

Les principales caractéristiques d'un protocole de réplication se définissent comme suit :


a- le nombre de copies concernées par une lecture ou une écriture.
b- les droits d'accès.
c- l'instant de synchronisation des répliques.
d- l'initiative de la mise _a jour des répliques.
e- la nature des mises à jour.
g- le cheminement (ou la topographie) des mises à jour.
h- la capture des mises à jour.
i -la gestion des conflits.
j- le type de protocole de communication.
k- la gestion de la concurrence.

II-2-5-Protocoles de réplication
Plusieurs protocoles de réplication ont été proposées pour la gestion des répliqués dans les
systèmes distribuées. Les trois principaux protocoles utilisés, sont : [9]

1) le protocole de réplication passive


2) le protocole de réplication active
3) le protocole de réplication semi-active

a- Protocole de réplication passive


Dans un protocole de réplication passive, seule une copie reçoit une requête d'un client et
l'exécute. Cette copie est désignée sous le nom de copie primaire (primary copy). Les autres
copies sont appelles copies secondaires (secondary copies). La copie primaire est la seule à
effectuer tous les traitements, alors que les copies secondaires ne font aucune action (voir la
Figure II.2).

30
En cas de défaillance de la copie primaire, une copie secondaire devient (par un protocole
d'élection) la nouvelle copie primaire. Pour assurer la cohérence, la copie primaire diffuse
régulièrement son nouvel état à toutes les copies secondaires.

Fig.II.2 - Exemple de protocole de réplication passive

Principe
La réplication passive est définie ainsi:
– réception des requêtes : la copie primaire est la seule à recevoir les requêtes ;
– traitement des requêtes : la copie primaire est la seule à traiter les requêtes ;
– émission des réponses : la copie primaire est la seule à émettre les réponses ;
Tolérance aux fautes : La tolérance aux fautes est réalisée par détection et compensation
d’erreur. Quand une copie secondaire passe dans un état de défaillance, aucun traitement
Particulier n'est nécessaire. Le seul effet de cette défaillance est la diminution du degré de
réplication (une réplique en moins). Par contre, quand une copie primaire devient défaillante,
un protocole d'élection sera déclenche pour designer la nouvelle copie primaire parmi les
copies secondaires. Si la copie primaire fait défaut lors d'une invocation par un client, alors
celui-ci n'obtient aucune réponse à sa requête. Il doit réémettre sa requête en l'adressant à la
nouvelle copie primaire.
Coût du protocole passive : Dans un protocole passive, la sauvegarde de l état est un
mécanisme coûteux, ce qui peut dégrader le temps de réponse. De plus, la réplication passive
n'améliore pas les performances par le fait que la copie primaire peut, dans certains cas, être
surchargée.

31
b- Protocole de réplication active
Dans un protocole de réplication active, chaque copie joue un rôle identique à celui des autres
copies. Toutes les copies reçoivent la même séquence, totalement ordonnée, des requêtes des
clients, les exécutent puis renvoient la même séquence, totalement ordonnée, des réponses
(voir Figure II.3).

Fig.II.3 - Exemple de protocole de réplication active

Principe
La réplication active est définie ainsi :
– réception des requêtes : toutes les copies reçoivent la même séquence
– traitement des requêtes : toutes les copies traitent les requêtes de manière déterministe
– émission des réponses : toutes les copies émettent la même séquence de réponses.

Tolérance aux fautes : Dans le protocole de réplication active, quand une copie devient
défaillante, aucun mécanisme supplémentaire n'est à mettre en ouvre. La défaillance d'une
copie est masquée par le comportement des copies non défaillantes. Ainsi, la tolérance aux
fautes est réalisée par le mécanisme de masquage d’erreur. L'exécution des requêtes doit être
déterministe, sinon des mécanismes de vote sont nécessaires, après la collecte des réponses de
toutes les différentes copies, pour décider de la réponse à restituer au client.

Coût du protocole actif : L'exécution d'une requête se faisant sur toutes les copies, le coût
processeur global est donc proportionnel au nombre de copies. Le protocole actif est utilisé
pour améliorer les performances, puisqu'un client peut obtenir une réponse à partir du
processeur qui aura terminée en premier l'exécution de sa requête.

32
c- Protocole de réplication semi-active
Le protocole de réplication semi-active : est une hybridation des réplications active et passive.
Il s'apparente à la réplication active dans le sens où chaque copie exécute la requête, sauf que
toutes les sources d'indéterminisme sont résolues par le choix d'une copie maitre qui renvoie
le résultat au client (voir Figure II.4). En l'absence de fautes, les autres copies (les suiveuses)
mettent à jour leurs états internes en exécutant les requêtes provenant du client

Fig.II.4 - Exemple de protocole de réplication semi-active

Principe
La réplication semi-active est défini ainsi [WPS+00a]
– réception des requêtes : toutes les copies reçoivent le même ensemble de requêtes.
– traitement des requêtes : toutes les copies traitent toutes les requêtes. La copie primaire
traite une requête dès qu’elle la reçoit. Par contre, une copie secondaire doit attendre une
notification de la copie primaire pour pourvoir traiter une requête ;3Les requêtes ne sont pas
totalement ordonnés.
– émission des réponses : la copie primaire est la seule à émettre les réponses.
Tolérance aux fautes : Dans la réplication semi-active, quand une réplique suiveuse fait
défaut aucun traitement particulier n'est nécessaire. Son seul effet est de diminuer le degré de
réplication. Puisque toutes les copies reçoivent la requête, le client n'a pas besoin de réémettre
sa requête lorsque la copie maitre devient défaillante. La nouvelle copie ma être envoie
automatiquement la réponse au client.
Coût du protocole semi-actif : Le protocole semi-actif est déterministe par rapport au
protocole actif. L'exécution d'une requête se faisant sur toutes les copies, le coût processeur
global est donc proportionnel au nombre de copies.

33
II-2-6-Quelque exemples des problèmes posé par la réplication des données

a- problème de la concurrence
Considérons le cas d’un compte :
un homme H et une femme F partagent un compte commun C, muni d’un somme S(C),et et
décidant de faire chacun retrait (RH et RF)dans deux distributeurs de billets distincts .
Supposant que ses deux retrait particulier sont tel que : [10]
- RH<S(C) ,RF<S(C),RH<>RF,RH+RF>S(C)
Supposant que la banque assigne à l’application qui pilote la délivrance de billet, la contrainte
de ne pas délivré plus d’argent que le compte n’en sur sont comptesur une requête de retrait
d’un distributeurs de billets ,une tell application implante la séquence suivante :
1. lecture de l’état d’un compte (L)
2. vérification de l’état d’un compte (V)
3. mise à jour d’un compte (M)
4. autorisation de retrait (A)
*considérons la séquence d’opération suivante :
LH(C)*LF(C)*VH*VF*MH(C)*MF(C)*AH*AF
La banque autorisé le retrait mais la valeur de compte commun et erroné
b- problème de performances
- Réplication des données
- Equilibrage de charge
-Répartition des transactions sur les nœuds de la grappe
-Minimiser les délais d’attente des transactions [11]

Fig. II.5 -problème de performance

34
II-3- Gestion de la cohérence
Les avantages de l'utilisation de la technique de réplication sont contraints par le problème de
cohérence mutuelle des copies, car les diverses répliques d'un objet doivent Apparaitre
comme une seule copie [12].
Les protocoles de gestion de cohérence offrent aux utilisateurs, la garantie d'une vue
cohérente des données dispersées [14](voir la Figure II.6).
La gestion de cohérence est donc définie comme étant le contrôle des accès, en vue de fournir
une vision qui fait abstraction de la réplication, de la distribution et de la concurrence des
accès aux données partagées. Les garanties de cohérence offertes aux utilisateurs, constituent
les critères de cohérence assures par des protocoles. Ces critères ne sont pas définis de façon
unique [13].

Réplique 1
Gestion de
Client Réplique 1
Cohérence

o Réplique n

Fig. II.6- Vue cohérente des donnée

II-3-1-définition de cohérence
-définition 1 : La cohérence est la relation entre les copies de même origine [8]
- définition 2:La cohérence est le degré de similitude entre les copies de même
origine [9].

35
II-3-2- Protocoles de cohérence

Les avantages de l'utilisation de la technique de réplication sont contraints par un problème


majeur de cohérence mutuelle des copies. La gestion des copies en termes de propagation des
mises à jour est ainsi nécessaire. La charge induite par cette cohérence peut avoir un impact
significatif sur le système notamment du point de vue performance. Il s'agira donc de garantir
la cohérence mutuelle d'un ensemble de répliques dans des délais acceptables.
Les diverses répliques d'un même objet doivent être cohérentes, c'est-à-dire, apparaître
comme une copie unique vis-à-vis des utilisateurs (voir la figure II.7).
La cohérence est une relation qui définit le degré de similitude entre les copies d'une entité
répliquée.[9]

1. Cohérence forte : Une cohérence de répliques est dite forte lorsque toute interrogation
d'une copie quelconque reflète le résultat de toutes les modifications antérieures.

2. Cohérence faible : Une cohérence de répliqués est dite faible, si on tolère qu'une
interrogation ne reflète pas toutes les modifications antérieures, avec la garantie que celles-ci
seront toutes répercutées au bout d'un temps fini.

Fig. II.7 - Accès aux données répliqué

36
Parmi les approches de cohérence, nous pouvons citer [15] :

a - Protocoles pessimiste :

Son but est de faire l'illusion qu'il n'existe qu'une réplique. Cette approche assure
une cohérence forte, c'est à dire, il n'y a pas de divergence entre les répliques.
La réplication pessimiste [16] ne supporte pas la mobilité et le passage à
l'échelle.
Les protocoles les plus connus sont bases sur le principe ROWA et Quorum.
ROWA (Read One White All): [15]
Les lectures peuvent être faites sur n'Importe quelle copie, tandis qu'une écriture
doit être appliquée sur toutes les Copies. Appliquer un changement sur un
nombre très important de copies et Cela de manière atomique, n'est pas réaliste
sur un réseau P2P.
ROWA-A (Read One, white all available): [16]
Les sites en pannes doivent recouvrer l'état courant d'un autre site avant de
redevenir disponible. ROWA-
A tolère n - 1 pannes, ne supporte pas les partitions réseaux et les pannes de
communication.
Quorum : [12] Ce protocole met µa jour les copies de manière synchrone
seulement sur un sous-ensemble des copies, qui forme le Quorum. Dans ce type
De protocole, une requête d'écriture n'est validée que lorsque ((N=2) +1) Copies
sont mises µa jour. Lors d'une requête de lecture, il est alors nécessaire de
Consulter (N=2) copies, ou N est le nombre de répliques dans le système.
Inconvénients majeurs de ce type d'approche : [23]
1. Elle est très mal adaptée à des environnements incertains ou instables, tels que
les systèmes mobiles ou les grilles à fort taux de changement ;
2. Elle ne peut supporter le coût de mise à jour quand le degré de réplication est
très élevée ;

37
3. Elle est inadaptée à des environnements qui exigent un partage de données
tels que les environnements collaboratifs.

b- Protocoles optimistes
A la différence de l'approche pessimiste, les protocoles de l'approche optimiste autorisent
l'accès à n'importe quelle réplique et ce à tout instant. Dans ce cas, les copies peuvent diverger
et un utilisateur peut donc observer des copies d'un même objet avec des valeurs
différentes.[9]
De cette manière, il est alors possible d'accéder à une réplique qui n'est pas nécessairement
cohérente, ce qui fait que cette approche tolère une certaine divergence entre répliqués.
Par contre, quand le système est en phase de repos pour une donnée, c'est-à-dire quand toutes
les opérations auront été propagées à toutes les copies, alors toutes les copies devront être
identiques. En présence de divergence, ce type d'approche nécessite une phase de détection de
divergence entre répliqués puis une phase de correction de cette divergence, pour ramener les
répliqués vers un état cohérent. Bien qu'elle ne garantisse pas une cohérence forte comme
dans le cas pessimiste, l'approche optimiste possède néanmoins un certain nombre d'avantages
que nous pouvons résumer comme suit :

1- Disponibilité :
Les protocoles optimistes fonctionnent bien dans les réseaux lents et incertains, parce qu'ils
peuvent propager des mises à jour sans bloquer les accès à toutes les répliqués ;
2- Flexibilité de gestion du réseau :
Les protocoles optimistes fonctionnent également bien dans les réseaux dynamiques. Une
telle propriété est essentielle dans les environnements mobiles, dans lesquels les dispositifs
peuvent être synchronisées seulement de temps en temps ;
3- Scalabilité :
Les protocoles optimistes peuvent soutenir un plus grand nombre de répliqué,
Parce que la propagation des mises à jour exige moins de coordination entre les copies.

La réplication optimiste est utilisée dans plusieurs domaines d'application, y compris la


gestion de données à large échelle, les systèmes d'informations et les environnements
collaboratifs

38
c-Comparaison des protocoles de cohérence
Le tableau suivant est une comparaison entre les protocoles pessimistes et les protocoles
optimistes [17] :

Caractéristiques Protocole Pessimiste Protocole Optimiste


Synchronisation Immédiate Retardée
Cohérence Forte Faible

Disponibilité Faible Forte

Temps d'accès Important Réduit


Performance (temps de Faible Bonne
réponse)
Taille des applications Petite Grande échelle

Blocage des utilisateurs Oui non

Tab. II.1- Comparaison des protocoles (Pessimiste et Optimiste)

39
II-4-Conclusion
Que les données soient répliquées ou non, garantir leur cohérence est un problème
fondamental dans la gestion des données et ce quelque soit leur nature (données, code,
services, etc.). Chaque fois que des accès concurrents sont autorises sur des données
partagées, il y a un risque d'incohérence qu'il faudra soit éviter totalement soit contrôler.
Lorsque ce partage de données est accompagne de techniques de réplication, le problème de
gestion des répliques et des accès concurrents devient donc plus complexe. Ainsi, la mise en
place d'une technique de réplication doit ^être évaluée en amont afin de mesurer son coût de
mise en ouvre et son efficacité du point de vue des objectifs visés par sa mise en place. Dans
ce processus de mise en place d'une technique de réplication, le problème de la gestion de la
cohérence est un problème fondamental qui nécessite une étude assez fine afin de trouver le
meilleur protocole de gestion de la cohérence en fonction des objets à répliquer et des
bénéfices qu'on veut en tirer. A travers ce chapitre, nousavons vu qu'il existe deux classes de
protocoles de gestion de la cohérence : la classe des protocoles optimistes et la classe des
protocoles pessimistes. Après une étude de ces deux classes, nous avons mis en évidence leurs
avantages et leurs inconvénients qui pourraient servir de critères dechoix de l'une ou de l'autre
classe dans le cadre des systèmes à large échelle.

40
Chapitre III :
Modèle proposé
pour la gestion
de cohérence

41
III-1-Introduction
L’utilisation des techniques de réplication permet d'améliorer le degré de disponibilité des
données ainsi que les performances d'accès à ces données. Mais, plus le degré de réplication
augmente plus le taux de divergence entre les répliques a également tendance à augmenter et
provoque des problèmes des mises à jour des réplique. Pour éviter une telle situation, il est
donc indispensable d'assurer, ou plus exactement de maintenir, la cohérence des répliques
d'un même ensemble de données. Cette maintenance de la cohérence sera d'autant plus
compliquée lorsque les opérations de mise à jour seront fréquentes.

Nous avons étudié, dans le chapitre précédent, deux approches de gestion de la cohérence de
répliques, à savoir les approches pessimistes et optimistes.
Ces deux approches représentent les cas extrêmes du rapport qui existe entre la cohérence et
la disponibilité (voir la figure III.1)

Disponibilité L’approche pessimiste cohérence

--- +++
Cohérence L’approche optimiste Disponibilité

Fig.III.1 - Cohérence vs Disponibilité

42
III-2-Modèle proposé
Les approches de cohérence pessimiste et optimiste possèdent des limites soit par rapport à la
disponibilité soit par rapport aux performances. partant de ces deux limites extrêmes,
Notre objectif est de définir une approche qui puisse traiter le problème de la cohérence de
répliques dans l’enivrement de cloud computing, mais qui puisse également tirer profit des
avantages combiné des approches pessimistes et optimistes. (Voir la figure III.2),

Approche Pessimiste Notre approche approche optimiste


+++ Qualité des services performance +++
Fig.III. 2-positionnement de notre approche
III-3-description du modèle
Pour améliorer la qualité des services et augmenter le temps de réponse, nous avons défini un
modèle intermédiaire entre les deux protocoles précédent. Ce modèle est composé en de deux
services (voir la figure III.3), Ces deux services sont complémentaires et ont pour objectif
principal de faire converger l'ensemble des répliques vers une réplique de référence globale.

Service Service BR
BR Service R1.1
Cohérence Cohérence 1 Cohérence
2
R2.1
Locale Globale Locale
R1.2
R2.2 R2.p BR k
R1.n
Service
Data center 2 Data center 1
Cohérence
Rk.1
Locale
Rk.m
Fig.III .3 - exemple de notre modèle

III-3-1-Service de gestion de cohérence locale:


Le but essentiel de la gestion de la cohérence locale est de converger les répliques d’un objet,
stocké dans un même data center vers une réplique de référence locale.

43
Le processus de gestion de cohérence locale est composé des tâches suivantes :
-Traitement de requêtes : Cette tâche a pour rôle d'exécuter une requête soumise par un
client ;
-Propagation interne : la tâche de propagation interne consiste à faire un transfert des mises
à jour entre les répliques de même data center, Cette propagation assure, qu'au bout d'un
temps fini, les répliques convergeront vers une réplique de référence locale ;

III-3-2-Service de gestion de cohérence globale:


L'objectif de ce service est d'obtenir une cohérence globale, qui consiste à faire converger les
répliques d'un fichier, des différents datacenter du cloud, vers une réplique de référence
globale.
Les deux services réalisés par un gestionnaire des répliques
Un broker des réplique: est un processus responsable à l’assurance de cohérence local au
niveau de chaque data center et collaborer avec les autres brokers des répliques pour
déterminer une cohérence globale au niveau globale du cloud la figure suivante explique le
fonctionnement d’un broker des réplique(voir Figure III.4)
collaboration

1..*
Broker des 1 gérer par 1
Data center
répliques
1 1
1

Contrôle de la
Cohérence locale

1..*

Host 1 1..*
Réplique

Fig.III .4-Principales fonctions d'un broker de répliques

44
III-4- Conception du modèle
Pour mieux connaitre les différentes étapes de conception de notre modèle de gestion de
cohérence, nous avons utilisée le langage UML

III-4-1-Diagramme de classes
Un diagramme des classes décrit le type des objets ou données du système ainsi que les
différentes formes de relation statiques qui les relient entre eux.

Modèle

1 1

1 1

Service global Lié à Service local


1 1

1 1

1..* 1..*
Broker des Gérer par Data center
1 réplique 1

1..*
Host
1 1..* Réplique

Fig.III.5- Diagramme de classes du modèle de cohérence proposé

III- 4-2-Diagramme d'activité


Un diagramme d'activité est utilisé pour modéliser un processus et en tant que fournit une vue
précieuse sur les flux d'information qui sont échangés entre les acteurs

45
46
III-5-Algorithme de base du modèle proposée

III-5-1- Notations
La table suivante liste un ensemble de notations qui seront utilisées par l’algorithme suivant.

Notation description
DC i Data center i
H i,j Le host j du data center i
VM i, j, p La machine virtuelle p dans le host j dans le data center i
BR i Gestionnaire de répliques du data center i
VBRi La version du gestionnaire des répliques
Ok Objet ou fichier k
R kp Réplique p de l’objet k
R kp(i) Réplique p de l’objet k dans le data center i
Rkp (i, j) Réplique p de l’objet k stockée dans le host j du data center i
VRkp (i, j) La version du réplique p de l’objet k stockée dans le host j du data
center i
Clet id Cloud let i relative au fichier k
Clet id(k)t Cloud let i relative au fichier k de type t
seuil Le seuil est un critère fixe à l’avance par apport le type d’application

Tab.III.1 - Tableau de notations

47
III- 5-2- fonctionnement de l’algorithme
L’algorithme suivant expliquer le fonctionnement de notre modèle de gestion de cohérence
Le fonctionnement de cet algorithme peut se résumer en trois phases suivant:

a-réception des cloudlets :

La réception des cloudlets se compose en quatre tâches principales


-l’arrivée d’une cloudlet (Clet id (k) t) : une cloudlets est composée d'un identifiant (id)
d’une Cloud let, d'un type d'accès (t), et concerne à un objet(k) particulier.
-la sélection d’un data center (DC i) : le choix du data center se faire par plusieurs critère (la
fiabilité du data center, l’emplacement géographiquement, la disponibilité …)
-le calcul la différence(D): calculer la différence entre la version de broker des reliques du
data center sélectionné et les versions des réplique de ce data center
-La détermination de type d’accès d’une Cloudlet:après la réception du Cloud let, le broker
des répliques déterminé le type d’accès de cette Cloud let (lecture/écriture)

b- traitement du Cloud let :

Le traitement des Cloudlet se fait selon le type d’accès de ce Cloud let


- Cloud let de type lecture : vérifier la déférence avec un seuil prédéfini,
- Si la condition est vérifiée, on sélectionne tous les hosts qui contiennent le fichier relatif puis
on exécute la Cloudlet sur le host le plus rapide et la réponse sera envoyée au client.
Sinon, on va orienter la Cloudlet vers un autre Datacenter qui vérifie la condition précédente.
- Cloud let de type écriture :
Les taches d'écriture modifient le contenu des répliques ce qui crée le problème d’incohérence
entre les répliques.
Alors dans le cas du Cloud let de type d’écriture, ont fait les mêmes étapes du Cloud let de
type lecture sauf que l’exécution se fait sur (n/2) +1 des réplique, et l’incrémentation des
versions des brokers et les réplique concerne

c-propagation des mises à jour


La tache de propagation consiste à transférer les opérations de mises à jour, relatives à un
fichier, vers ses répliques qui ne sont pas encore à jour. Cette propagation peut être
déclenchée de manière périodique,

48
1-réception des cloudlets

-arrive d’une Clet id (k)t


-sélectionner un DC i
- calcul la différence(D) entre VBR i et VRk(i)
-sélectionner tous les répliquesdisponibles (P)
- déterminer letype du Clet(t)

2- traitement des Cloud lets


- Si t = Read //cloudlet de type lecture
Si D <= seuil
-exécuter la Clet sur la plus performant Hj
-envoi la réponse au client

Si non
- orienté le Clet t vers un autre DC i tel que D <= seuil
fin si
-si non //cloudlet de type écriture

- Si la P =n/2+1
- Si la D =0
-exécuter la Clet sur (n/2)/+1 plus rapide Hjs
- incrémenter les versions de (n/2)+1 des répliques
- incrémenter la version de tous les brokers
- envoi la réponse au client
Si non
-Propager la MAJ et exécuter la cloudlet sur (n/2)/+1 des plus rapide hosts
- incrémenter les versions de (n/2)+1 des réplique
- incrémenter la version de tous les brokers
- envoi la réponse au client
Fin si

Si non
- orienté le Clet t vers un autre DC i tel que P =n/2+1
Fin si
Fin si
3-propagation des mises à jour
Si temps >= période
-Propager la mise à jour sur les répliques disponible
-fin

49
III-6-Métriques utilisées
Dans le but d'analyser et d'étudier cette approche, nous avons utilisé des métriques,
Que nous pouvons diviser en deux catégories : La première catégorie pour mesurer Les
performances de l'approche proposée, la deuxième permet de mesurer l'aspect de qualité de
service

III-6-1- Mesure de la performance


L'étude des performances d'un système est mesurée généralement par sa rapidité à envoyé une
réponse à un utilisateur.
Le plus souvent, cette rapidité est calculée à l'aide de temps de réponse effectue pour satisfaire
une cloudlet d'un client.

a-Temps de réponse
Le temps de réponse d'une cloudlet représente le temps pendant lequel cette requête a été
exécutée, c'est-à-dire, le temps d'attente plus le temps d'exécution.
La métrique temps de réponse représente la somme de temps de réponse de chaque requête
pendant une période donnée.

Temps de réponse =∑temps de réponse de chaque cloudlets

b- Moyenne de temps de réponse :


Cette métrique représente la moyenne de temps de réponse par une cloudlet.

Moyenne Temps de réponse =temps de réponse /le nombre des cloudlets

c-Le temps de propagation


Le temps de propagation est le temps nécessaire pour qu'une mise à jour devienne visible par
toutes les répliques. Cette valeur dépend de beaucoup de facteurs dans la conception d'un
système de réplication. Il est légèrement plus facile de mesurer le temps de propagation dans
un système réparti parce qu'il n'y a aucun besoin de l'horloge globale.

50
III-6-2-Mesure de qualité de service

La qualité du service (QoS) dans les systèmes de répliques par rapport aux mises à jour est le
degré auquel le système présente une illusion de la connectivite à une copie à jour de tous les
objets pour tous les utilisateurs.
Plusieurs métriques peuvent être employées pour mesurer la qualité du service dans le
système de répliques.
Divergence
Le compte de divergence est la mesure la plus populaire du QoS des systèmes de répliques.
Cette mesure consiste à connaitre le niveau de divergence du système.
La divergence est liée au nombre de mise à jour. Elle est égale à la différence entre le nombre
de mises à jour maximal et celui minimale.

Divergence = (La version récente de mises à jour) - (L'ancienne version)

Moyenne de divergences :
La moyenne de divergence est la divergence par rapport au nombre des data centres.

Moyenne de divergences = Divergence / Nombre des data centres

51
III-7-Conclusion
Dans ce chapitre, nous avons présente les différentes étapes de notre approche de gestion de
cohérence de répliques dans le cadre des cloud computing
L'approche proposée combine l'approche optimiste et l'approche pessimiste.

L'avantage majeur de notre modèle


-améliorer la qualité des services offerts par l’approche optimiste
-réduire le temps de réponse obtenu par l’approche pessimiste
Le prochain chapitre sera consacré à la partie d'implémentation et simulation de nos
propositions.

52
Chapitre IV
Implémentation
et simulation

53
IV-1-Introduction

L'objectif de toute conception est de produire un outil logiciel pour prouver et confirmer nos
déclarations théoriques. Cette partie nous permet de concrétiser cette conception en présentant
les différents aspects techniques ainsi que quelques résultats expérimentaux.
IV-2-Langage et environnement de développement
Nous avons développé le simulateur sur une machine avec un processeur Intel(R) Core(TM) 2
i3-380M , doté d’une capacité mémoire de4GB, sous Windows 7 64 bits. Nous avons utilisé
l'environnement de développement eclipse.

IV-2-1 -Pourquoi Java ?


Java est un langage de programmation à usage général, évolue et orientée objet dont la
syntaxe est proche du C++. Il a été mis au point en 1991 par la firme Sun Microsystems [19].
Il s'agissait de concevoir un langage bien adapte aux environnements de travail en réseau et
capable de gérer des informations de nature variées (données numériques, informations
sonores et graphiques).
Java est devenue aujourd'hui un phénomène incontournable dans le monde des
programmations, parmi les différentes caractéristiques qui sont attribuées à son succès :
- L'indépendance de toute plate-forme : le code reste indépendant de la machine sur laquelle il
s'exécute. Il est possible d'exécuter des programmes Java sur tous les environnements qui
possèdent une Java Virtual Machine.
-Java est également portable, permettant à la simulation d'être distribuée facilement sans
avoir à recompilé le code pour les différents systèmes.
-Le code est structuré dans plusieurs classes, dont chacune traite une partie différente de la
simulation.
-Il assure la gestion de la mémoire.
-Java est multitâche : il permet l'utilisation de threads qui sont des unités d'exécution isolées.
Aussi, une des principales raisons de ce choix est que le simulateur CloudSim est développé
avec ce langage.

54
IV-2-2-Environnements de développement
Eclipse [20] est un environnement de développement intégré, libre, extensible, universel et
polyvalent, permettant de créer des projets de développement mettant en ouvre n’importe quel
langage de programmation. Eclipse IDE est principalement écrit en Java (à l'aide de la
bibliothèque graphique SWT, d.IBM), grâce à des bibliothèques spécifiques, ce langage est
également utilisé pour écrire des extensions.
La spécificité d'Eclipse IDE vient du fait de son architecture totalement développée autour de
la notion de Plug-in (en conformité avec la norme OSGi) : toutes les fonctionnalités de cet
atelier logiciel sont développées en tant que Plug-in. Plusieurs logiciels commerciaux sont
basés sur ce logiciel libre, comme par exemple IBM LotusNotes 8, IBM Symphony
ouWebSphere Studio Application Developer, etc.

Nous avons utilisé pour la réalisation de notre travail la version du simulateurCloudSim 3.

IV-2-3-Cloud Sim
Cloud Sim est une nouvelle structure de simulation généralisée et extensiblequi permet la
modélisation des environnements hétérogènes, la simulationet l'expérimentation de Cloud
émergent des infrastructures de calcul et des services d'application. [21]
Le Toolkit CloudSim couvre la plupart des fonctionnalités ayant lieu dansun centre de
traitement des données en détail. Ceci inclut :
-Simulation de la définition de matériel de centre de traitement des données (Datacenter) en
termes de machines physiques composées de processeurs, de dispositifs de stockage, de
mémoire et de largeur de bande interne.
-Simulation des spécifications, de la création et de la destruction de machine virtuelle.
-Gestion des machines virtuelles, allocation des ressources physiques de matériel pour le
fonctionnement des machines virtuelles basees sur différentes politiques (par exemple en
temps partage et espace partage).
- Simulation de l'exécution des programmes de l'utilisateur ou des demandes (Cloudlet) sur les
machines virtuelles.

IV-2-3-1-Caractéristiques de CloudSim
CloudSim appuie la recherche et le développement dans le domaine émergent du Cloud
Computing et offre les fonctionnalités suivantes : [21]

55
1- Support pour la modélisation et la simulation à grande échelle d'infrastructure de Cloud
Computing, y compris des centres de données sur un seul nœud physique ;
2- Une plateforme indépendante pour la modélisation des Datacenter,Des Brokers, de
l'ordonnancement et des politiques d'allocation des ressources.
Parmi les principales caractéristiques de CloudSim, nous pouvons citer :
1- La disponibilité de moteur de vitalisation, ce qui facilite la création et la gestion de services
vitalises multiples, indépendants et héberges sur un noud du Datacenter.
2- La flexibilité pour commuter entre l'allocation en espace partage et en temps partage des
cœurs de traitement aux services virtualisés.

IV-2-3-2-Architecture de CloudSim
La structure logicielle de CloudSim et ses composants est représentée par une architecture en
couches comme il est montré par la figure IV.1. La première version de CloudSim utilise Sim
Java, un moteur de simulation d'événement discret qui met en œuvre les principales
fonctionnalités requises pour des structures de simulation de haut niveau comme la formation
d.une .le d'attente et le traitement d'événements, la création de composants système (les
services, les machines (Host), le centre de données (Datacenter), le courtier (Broker), les
machines virtuelles), la communication entre les composants et la gestion de l'horloge de
simulation. Cependant, dans la version actuelle, la couche Sim Java a été supprimée afin de
permettre à certaines opérations avancées qui ne sont pas pris en charge par celle-ci

56
Fig. IV.1 .Architecture de CloudSim

IV-3- Description du fonctionnement de notre application


Pour décrire les différentes étapes d'optimisation dans notre travail, nous avons opté pour le
langage UML pour plusieurs raisons :
_ Langage servant à décrire des modèles d'un système (réel ou logiciel) basé sur des concepts
orienté-objets.
_ Système de notations pour modéliser les systèmes en utilisant des conceptsorienté-objets.
_ Représente un standard de modélisation, une notation : il s'agit donc d'un outil et non d’une
méthode ; chacun peut utiliser la méthode la plus appropriée à ses besoins.
_ Il permet de représenter l'aspect traitement du système aussi bien que l'aspect donné.
Parmi les diagrammes d’UML que nous avons jugé intéressants pour notre conception, nous
citons le diagramme d’utilisation, de classes, et de séquence.

57
IV-3-1- Diagramme d’utilisation
Nous présentons maintenant une vue globale de notre simulateur qui permet de détailler les
différentes étapes exécutées pour réaliser une simulation.
Représente les fonctionnalités d'utilisation nécessaires à l'application.
Le diagramme des cas d’utilisation, est une modélisation d.une fonctionnalité du système, il
se détermine en observant et en précisant acteur par acteur les séquences d4interactions avec
le système. Les cas d’utilisation décrivent les fonctions du système selon le point de vue des
utilisateursSelon ce diagramme, l’utilisateur commence la simulation par la création de
l’enivrement ensuite la sélection du protocole de gestion de cohérence et le choix de seuil et
en fin lancer la simulation,
Création de
l’enivrement

Sélectionner le protocole
de gestion de cohérence

Entrée le seuil et fixé le


période de mise à jour

Lancer la simulation

Fig. IV.2 .Diagramme d’utilisation du simulateur

58
IV-3-2-Diagramme de classes
Le diagramme de classes permet de représenter la structure du système comme un ensemble
de relations entre classes. Le simulateur Cloud Sim est composé de plusieurs classes que nous
pouvons classer en deux catégories : les classes que nous avons modifiées comme la classe
Datacenter, Datacenter Broker, . . . et nous avons ajoutées la classe data (voir la figure IV.3)
Parmi les classes fondamentales qui forment les blocs constitutifs du simulateur Cloud Sim,
nous pouvons citer :

-data center : centre de données est utilisée pour modéliser les services de base au niveau
d'une infrastructure de nuage de système. Il se compose d'un ensemble d'hôtes qui gèrent un
ensemble de machines virtuelles dont les tâches sont de gérer le traitement "de bas niveau", et
au moins un centre de données doit être créé pour lancer la simulation.

- Datacenter broker: la responsabilité d'un courtier est à méditer entre les utilisateurs et les
fournisseurs de services, en fonction de l'exigence de qualité de service que l'utilisateur
spécifie. En d'autres termes, le courtier identifier quel fournisseur de service est adapté à
l'utilisateur, selon les informations dont il dispose au Service d'information Cloud, et négocie
avec les fournisseurs sur les ressources qui répondent à l'exigence de l'utilisateur. L'utilisateur
du CloudSim doit étendre cette classe afin de préciser exigence dans leurs expériences.

-Hôte : ce composant est utilisé pour attribuer des capacités de traitement (qui est spécifié
dans le million d'instruction par seconde que le processeur peut exécuter), de la mémoire et
une politique d'ordonnancement permet d'allouer des cœurs de traitement sur plusieurs
machines virtuelles qui est dans la liste des machines virtuelles gérés par l'hôte.

-Machine virtuelle : ce composant gère la répartition des différentes machines virtuelles


différentes hosts afin que les cœurs de traitement peut être prévu (par l'hôte) aux machines
virtuelles. Cette configuration dépend de l'application particulière, et la politique par défaut de
l'allocation des machines virtuelles est "premier arrivé, premier servi".

-Cloudlet : cette composante représente le service d'application dont la complexité est


modélisé dans Cloud Sim en termes de besoins en calcul .

59
data
Data

Fig. IV.3 .Diagramme de classe de la conception de simulateur Cloud Sim

IV-4-Interface principale
Dès le lancement de notre logiciel, apparaît en premier aux utilisateurs, elle est constituée à
un ensemble d’onglets suivants :
Datacenter, Machine virtuelle, Cloudlet et gestion de cohérence ces onglets utilisé pour la
configuration des paramètres de simulation la simulation passe par quatre étape essentiel
Datacenter
Cette étape consiste à faire entrer les paramètres nécessaires propres à la topologiedu réseau
(Figure IV.4) comme : le nombre de Datacenter, d’hôtes, et le nombre des répliques de
chaque donnée.

Fig. IV.4.Configuration du Datacenter

60
Virtual Machine (VM)
L’onglet Virtual Machine permet de configurer les machines virtuelles (Figure IV.5)par
exemples : spécification du nombre de VM, de CPU dans une VM, la taille de la mémoire, la
taille du disque dur et la bande passante.

Fig. IV.5 .Configuration des machines virtuelles

Cloudlet
Permet de configurer les propriétés de la Cloudlet (voir la Figure IV.6)
Nombre cloudlet:le nombre des Cloudlet à crée.
Type d’accès : le pourcentage des cloudlets de lecture ainsi d’écriture
Temps d’accès : le temps d’accès c’est l’instant que la cloudlet à accéder à une donnée

Fig. IV.6.Configuration des Cloudlets

61
Gestion de cohérence : L’onglet gestion de cohérence permet à l’utilisateur de sélectionner
un protocole de gestion de cohérence par met les protocoles suivant pessimiste, optimiste et
hybride de gestion de cohérence. Dans le cas de protocole hybride l’utilisateur il faut définie
un période de mise à jour et un seuil.la Figure .IV.

Fig. IV.7.gestion de cohérence

IV-5-Expérimentations
Afin de valider et d’évaluer nos approches de gestion de cohérence, nous avons effectué une
série d’expérimentations dont les résultats et les interprétations font l’objet de cette section.
Notre simulation à classifié en trois catégories d'expériences.

IV-5-1- Expérience 1 : Impact du nombre de cloudlet


Dans cette première série de simulations, nous avons mesurée l'impact du nombre de cloudlet
sur les différentes métriques définies dans le chapitre 3.
Ces simulations ont été réalisées avec les paramètres de simulations suivants : 25Datacenter,
50host, une donnée répliquée 10 fois à chaque Datacenter, et nous avons varié le nombre de
cloudlet entre 50 à 200 cloudlet les résultats sont montres par (la Figure IV.8)

62
Effets sur le temps de réponse
Nous remarquons que dans le graphe de la Figure. IV.8, quelque soit le nombre et le type de
Cloudlets exécutées, le temps de réponse de notre approche (hybride) est inferieur par rapport
l’approches pessimistes(ROWA), Par contre ; si le type d’accès est 100 % lecture alors elles
donnent donne le même temps de réponse puisque les deux approches exécute les cloudlets de
type lecture à une seul réplique.

Taux écriture/lecture Protocole de Nombres des cloudlets


cohérence
50 100 150 200
50 % écriture Hybride 555 900 1200 1623
50 % lecture
Pessimiste 650 2038 2345 2738
0 % lecture Hybride 823 1540 1893 2050
100 % écriture Pessimiste 2236 2651 2949 3238
100 % lecture Hybride 510 510 510 510
0 % écriture
Pessimiste 510 510 510 510

Tab. IV.1.résultat de la variation de temps de réponse moyen/nombre Cloudlet

Hybride Pessimiste

50% (écriture –lecture) 100 % écriture 100 % lecture


3500
3000 600
3000
2500 500
2500
2000 400
2000
1500 300
1500
1000 200
1000
500 100
500
0 0
0
50 100 150 200 50 100 150 200
50 100 150 200

Nombre cloudlets

Fig. IV.8.Variation de temps de réponse moyen/nombre Cloudle

63
IV-5-2-Expérience 2 : Impact de type de cloudlet

Dans cette deuxième série de simulations, nous avons voulu tester l'impact du type de
cloudlet en considérant les paramètres suivants : 20Datacenter, 50host, une donnée répliquée
10 fois dans chaque Datacenter et 100 cloudlets dont nous avons varié le type (cloudlet
d'écriture et de lecture) selon les taux d'écriture par rapport à la lecture, les résultats de ces
simulations sont montres par la Figure Fig. IV.9
Effets sur le temps de réponse

L'analyse des résultats de la Figure. IV.9montre que lorsque le nombre d'écritures augmente
par rapport au nombre de lectures, le temps de réponse augmente dans les deux approches,
cela veut direque l'écriture est beaucoup plus gourmande en temps de réponse moyen, mais
toujours notre approche donne un meilleur temps de réponse par apport l’approches
pessimiste

2500

2000

1500

Hybride
1000
Pessimiste

500

0
0% 25% 50% 75% 100%

Taux écriture/lecture

Fig. IV.9.Variation de temps de réponse moyen/type Cloudlet

64
IV-5--3- Expérience 3 : Impact de type de nombre des répliques

Pour cette troisième série de simulations, nous avons fixe les paramètres comme suit :
4dataceneter, 10host, et 100 cloudlets (50cloudlet d'écriture et 50 de lecture) dont nous avons
varié le nombre des répliques de 10 à 100

Effets sur le temps de réponse


L’analyse de la figure. IV.10 montre que la moyenne de temps de réponse ne change pas par
la variation de nombre des répliques (comme le résultatdans le tableau suivant)puisque les
cloudlets sont accéder à la donnée aux même temps, mais notre approche (hybride) donne un
meilleur temps de réponse par apport l’approche pessimiste

Taux Protocole de Nombres des répliques


écriture/lecture cohérence 10 25 50 100
50 % écriture Hybride 522 522 522 522
50 % lecture Pessimiste 2038 2038 2038 2038
0 % lecture Hybride 554 554 554 554
100 % écriture Pessimiste 2236 2236 2236 2236
100 % lecture Hybride 510 510 510 510
0 % écriture Pessimiste 510 510 510 510
Tab. IV.2.résultat de la variation de temps de réponse moyen/nombre réplique

2500
2000
1500 Hybride
1000 Pessimiste
500
0
100%Lecture 50%Lecture 0%Lecture

Fig. IV.10.Variation de temps de réponse moyen/nombre réplique

IV-5-conclusion
Dans ce chapitre, nous avons présente et analysée un certain nombre d'expérimentations pour
mettre en évidence la fiabilité, les avantages de notre approche, et comparer ses qualités
(performance en temps de réponse) avec les autres approches, telles que les approches
pessimistes ROWA.
À partir les différentes expérimentations nous remarquons que notre approche donne un
meilleur temps de réponse par apport l’approches pessimiste.
65
Conclusion
générale

66
Le Cloud Computing fait référence à l’utilisation des capacités de calcul des
ordinateurs distants, où l’utilisateur dispose d’une puissance informatique considérable sans
avoir à posséder des unités puissantes.

Ce mémoire a pour objectif l’étude du problème de cohérence des répliques dans


l’enivrement du Cloud computing, Pour cette étude, nous avons consacré une partie de notre
travail à donner un bref aperçu sur les cloud computinget étudier les techniques de réplication
dans l’enivrement du cloud computing.
La réplication permet d’augmenter la disponibilité des données, et réduire le temps
d’accès. Néanmoins la création de plusieurs répliques de la même donnée peut engendrer des
situations de divergence et d’incompatibilité, ce qui nécessite des mécanismes de gestion de
cohérence entre ces répliques distantes, nous avons étudié des protocoles de gestion de
cohérence des répliques ces techniques peuvent être classifié en deux familles : pessimiste ou
optimiste.
Mais les deux protocoles de gestion de cohérence pessimiste et optimiste possèdent des
limites soit par rapport à la disponibilité soit par rapport aux performances. Partant de ces
deux limites extrêmes, nous avons proposé un modèle intermédiaire entre ces deux
protocoles. Le but de l’approche que nous avons proposé et de réduire le temps de réponse
obtenu par l’approche pessimiste, et d’améliorer la qualité des services offerts par l’approche
optimiste. En fin nous avons implémenté notre approche sur l’enivrement de cloudSim pour
confirmé nos résultats théoriques.
Pour une continuation de notre travail, plusieurs perspectives peuvent être envisagées :
 nous utilisons un seuil adaptatif selon le type d’application au lieu d’utilisation d’un
seuil statique.
 Validation de notre proposition sur une plateforme de Cloud Computing, telleque :
Eucalyptus, Nebula.

67
Bibliographie

68
[1] :Information and Communication Technologies and Productivity Growth: A Survey of
the Literature,Kretschmer, T. (2012), documents sur l'économie numérique, n°195,publication
de l'OCDE.
http://dx.doi.org/10.1787/5k9bh3jllgs7-en
[2] : [Wygwam] : laboratoire de Recherche
[3] : [ NIST] : National Institute for Standards and Technology) des États-Unis
[4] : https://cloudsecurityalliance.org/csaguide.pdf
[5] : L. MOINE.« La gestion et la sécurité dans une architecture de ressources de calcul
distribuées sur l'Internet. » Mémoire d'ingénieur en informatique, Grenoble Cedex 9, France
[6] : Mr. DJEBBARA MOHAMED REDHA « Gestion de répliques dans les grilles de
données »Mémoire de Magister UNIVERSITE IBN KHALDOUN – TIARET
[7] :P. Molli, G. Oster, « Réplication des données », LORIA, INRIA Lorraine,ECOO Project,
Novembre 2005.
[8]:Z. Benotmane, K. Benhallou« Un modèle Bicouches Intelligent pour la cohérence des
répliques dans une grille de données »Mémoire d’Ingénieur, Université d’Oran,
[9] :G. Belalem. « Contribution à la gestion de la cohérence de répliques de fichiers dans les
systèmes à large échelle. »Thèse de doctorat, Université d'Oran, Algérie
[10] :georges brun-cottan « Cohérence de données répliquées partages par un groupe de
processus copérant à distance » Thèse de doctorat, université PARIS VI
[11] :Stéphane Gançarski « Réplication et bases de données » LIP6 Université Paris 6
[12] N. Belayachi and R. Behidji.« Influence de l'équilibrage de charge sur lacohérence des
répliques dans les grilles de données. »
Mémoire d'ingénieur d'état en informatique, Université d'Oran,
[13] L. Allal and C. Dad.« Gestion de la cohérence des répliques de données orientée QoS
dans les Wireless Grid. » Mémoire d'ingénieur d'état en informatique, Université d'Oran,
Algérie (Juin 2009).
[14] A. Jebali. « Contrôle de divergence dans des environnements faiblementsconnectes. »
Thèse de doctorat, Université de Versailles Saint Quentin-EnYvelines, France (Novembre
2003).
[15] :G. Oster, P. Urso, P. Molli, H. Molli, and A. Imine. Optimistic Replication for Massive
Collaborative Editing (HAL – CCSd - CNRS, 2005).
URL http ://hal.inria.fr/inria-00071218/en/ ;
http ://hal.ccsd.cnrs.fr/docs/00/07/12/18/PDF/RR-5719.pdf.
[16] :Y. Saito and M. Shapiro. Optimistic replication. ACM Comput. Surv 37(1), 42 (2005).
[17]: G. Belalem and Y. Slimani. A hybrid approach to replica management in data grids.
International Journal of Web and Grid Services (IJWGS) 3(1)
[18] : Lefort A. : Cloud Computing. Projet tutoré en licence professionnelle ASRALL, 2010.
[19]: http: //java.sun.com/docs/books/tutorial/index.html
[20]: http: //fr.wikipedia.org/wiki/Eclipse
[21] : BOUAMAMA Samah « La gestion économique des ressources Cloud »
Mémoire de Magister UNIVERSITE D’ORAN

69