‫الجمهورية الجزائرية الديمقراطية الشعبية‬

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 : RISR

Un mécanisme dynamique tolérant aux fautes

Des données dans le Cloud Computing

Présenté par :
Encadré par :
Mansouri Ahlem.
Mr D.Limam Said.
Tounsi Amel.

2016 - 2017
 Remerciements

Nous tenons tout d’abord à remercier Dieu le tout puissant Et miséricordieux, qui nous a
donné la force et la patience D’accomplir ce modeste travail ;

Nos remerciements s’étendent a nos formidables parents qui par Leur prières et leurs
encouragements, on a pu surmonter tous les obstacles ;

Nous tenons à remercier, bien sûr, en priorité, notre encadreur,

Mr LIMAM SAID. Comment, en effet, ne pas souligner, L’aide exceptionnelle qu’il

nous a apportée. Son conseil, sa disponibilité

Continuelle, son suivi minutieux de notre travail et son soutien,Nous ont permis de mener
à bien ce travail. Qu’il veuille bien Trouver ici témoignage de notre reconnaissance.

Enfin ; on remercie toutes les personnes qui ont participé De près ou de loin à la réalisation
de ce travail.

i
 Dédicace

Je dédie ce travail à :

A mon très cher père

A mon très cher mère

Affable, honorable,aimable :Tu représentes pour moi le symbole de la bonté par excellence,
la source de tendresse et l’exemple du dévouement qui n’a pas cessé de m’encourager et de
prier pour moi

Tu as fait plus qu’une mère puisse faire pour que ses enfants suivent le bon chemin dans
leur vie et leurs études.

Je te dédie ce travail en témoignage de mon profond amour Puisse Dieu,le tout puissant,te
préserver et t’accorder santé,longue vie et bonheur.

Je dédie ce travail aussi a

Mes chères soeurs, et mes frères pour leurs encouragements et Mon fiancé.Mes chers
amis,pour tous ce qu’on a partagés ensemble,Toutes les personnes proches que je n’ai pas
citées

Mansouri Ahlem

iii
 Dédicace

Merci Allah de m’avoir donné la force et la patience d’aller jusqu’au D’un objectif tant
recherché avec bonheurs et de lever les mains vers Le ciel et de dire " Ya Moujib ".

Je dédie ce travail à :

La vie et qui s’est sacrifiée pour mon éducation et ma réussite ! A ma Mère A mon père,
école de ma vie, qui m’a accompagné durant toutes Mes années d’études, à apporter son
soutien et sa protection.

Je dédie ce travail aussi a

Mes chères soeurs, et mes frères pour leurs encouragements et leur amour.Mes chers amis,
pour tous ce qu’on a partagés ensemble, Toutes les personnes Proches que je n’ai pas citées

TOUNSI AMEL

v
Table des matières

Table des sigles et acronymes xiii

Introduction Générale 1

1 Cloud Computing 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Déscription du cloud computing . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Les différents services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Modelés de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5 La différence entre le cloud prive et le cloud public . . . . . . . . . . . . . 12

1.6 Les Avantages et Inconvénients du cloud computing . . . . . . . . . . . . . 12

1.7 Sécurité dans les cloud computing . . . . . . . . . . . . . . . . . . . . . . . 13

1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Réplication 15

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 principe de réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Les techniques de réplication . . . . . . . . . . . . . . . . . . . . . . . . . 16

vii
 2.4 Avantages et Inconvénient de la réplication . . . . . . . . . . . . . . . . . . 18

2.5 protocole de la réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6 La cohérence des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.7 Protocole de cohérente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Tolérance aux pannes 25

3.1 Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Notion de surete de fonctionnement . . . . . . . . . . . . . . . . . . . . . . 26

3.3 méthode de tolérance aux pannes . . . . . . . . . . . . . . . . . . . . . . . 32

3.4 Techniques de tolérance aux pannes dans les systèmes repartis . . . . . . . 33

3.5 La tolerance aux pannes dans les cloud . . . . . . . . . . . . . . . . . . . 39

3.6 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 Description et modélisation De l’approche proposées 45

4.1 Partie I : Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Partie II : Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5 Implémentation 65

5.1 Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2 Langage de programmation Java : . . . . . . . . . . . . . . . . . . . . . . . 66

5.3 Interface principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Conclusion 75

viii
Table des figures

1.1 Cloud computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Les couches du cloud computing . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Répartition des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Avantages et Inconvénient des services . . . . . . . . . . . . . . . . . . . . 10

1.5 Modelés de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Environnement d’utilisation de la technique de réplication . . . . . . . . . 17

2.2 protocole de réplication active . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 protocole de réplication passive . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4 protocole de réplication semi active . . . . . . . . . . . . . . . . . . . . . . 22

2.5 Vue cohérente des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6 Accès aux données répliquées . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 La chaine fondamentale des entraves a la surete de fonctionnement . . . . . 28

3.2 L’arbre de la surete de fonctionnement . . . . . . . . . . . . . . . . . . . . 31

3.3 comparaison des différentes méthodes de tolérance aux pannes par reprise 39

3.4 Migration de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

xi
4.1 Composants du cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Placement de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3 Préparation des requêtes de l’utilisateur . . . . . . . . . . . . . . . . . . . 48

4.4 Algorithme Création des répliques . . . . . . . . . . . . . . . . . . . . . . . 49

4.5 Mécanisme de hearbeat et watchdog . . . . . . . . . . . . . . . . . . . . . . 51

4.6 Transitions d’états de la charge d’un Datacenter . . . . . . . . . . . . . . . 52

4.7 Algorithme de changement d’état . . . . . . . . . . . . . . . . . . . . . . . 53

4.8 Algorithme traitement de requête . . . . . . . . . . . . . . . . . . . . . . . 54

4.9 Diagramme d’utilisation du simulateur . . . . . . . . . . . . . . . . . . . . 55

4.10 Diagramme de classe de la conception de simulateur CloudSim . . . . . . . 56

4.11 Diagramme d’état de la stratégie proposée . . . . . . . . . . . . . . . . . . 57

4.12 Diagramme d’état de création des répliques . . . . . . . . . . . . . . . . . 58

4.13 diagramme de sequence « état normal » . . . . . . . . . . . . . . . . . . . 59

4.14 diagramme de sequence « état suspect » . . . . . . . . . . . . . . . . . . . 60

4.15 diagramme de sequence « état suspect » . . . . . . . . . . . . . . . . . . . 61

4.16 diagramme de sequence « état critique » . . . . . . . . . . . . . . . . . . . 62

5.1 Architecture de CloudSim . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2 Interface principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3 Configuration du DataCenter . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4 Fenêtre de Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.5 Configuration des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.6 Configuration des machines virtuelles . . . . . . . . . . . . . . . . . . . . . 70

5.7 Configuration des Cloudlet . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.8 Configuration de mécanisme de tolérance aux pannes . . . . . . . . . . . . 72

xii
5.9 Interfece de Lancement de la simulation et de la visualisation des résultats 72

xiii
Table des sigles et acronymes

DSI Direction des Systèmes d’Informations)

SaaS Software as a Service
IaaS Infrastructure as a Service
PaaS Platform as a Service
API Application Programming Interface
SDK S oftware Développement Kit
VNC V irtuel Network Computing
RDP Remote Descktop Protocol
SLA S ervice Level Agreement
IRS I ntegrated Replication and Scheduling
SRA S cheduling and Replication Algorithm
UML U nified Modeling Langage

xvii
Introduction Générale

année 2008 a vu l’émergence du terme « Cloud Computing » (ou L’informatique dans

L les nuages) dans les journaux spécialisés, et les annonces des nouvelles solutions
chez tous les grands acteurs de l’informatique : Microsoft, Google, Oracle,...
Dans l’effervescence qui accompagne toute grande nouveauté dans le monde de l’infor-
matique, le Cloud Computing est apparu pour certains comme une révolution et pour
d’autres comme un simple terme de Marketing qui ne fait que rassembler des services et
des technologies qui existent depuis longtemps. L’approche du Cloud computing s’appuie
principalement sur le concept de virtualisation. Ce concept est un ensemble de techniques
permettant de faire fonctionner sur une seule machine plusieurs systèmes d’exploitation
et/ou plusieurs applications, isolés les uns des autres. Un Cloudest constitué d’un ensemble
de Machines virtuelles qui utilisent la même infrastructure physique.
Notre contribution consiste à proposer une approche de tolérant aux fautes des données
dans Cloud computing.
Dans la première partie, nous avons abordé la réplication des données dans le Cloud Com-
puting, les données sont placées dans des hosts différents qui se trouvent dans le même
ou dans des autres Datacenter. L’approche proposée est basée sur la disponibilité exigée
par l’utilisateur. Cette approche permet d’améliorer la disponibilité et réduire le temps de
réponse. Dans la seconde partie nous avons proposé une approche qui permet de traiter
les pannes. La deuxième approche est basée sur la migration des données selon certains
critères.

Organisation du mémoire :
Le présent mémoire est structuré autour de cinq principaux chapitres qui se résument
comme suit :

- Dans le premier chapitre, Nous avons présenté un état de l’art sur le Cloud Computing

1
 - Le second chapitre présentera la réplication de données
- Le troisième chapitre aborde le concept, le concept de la tolérance aux fautes
- Le quatrième chapitre sera réservé à la description détaillée de la conception Des
deux stratégies ainsi que les servicesque nous avons proposés. Cette conception se
fera à l’aide de formules, d’algorithmes et de diagrammes UML
- Ce dernier chapitre présentera les étapes de l’implémentation de l’approche proposée.
Nous y détaillerons la réalisation de certaines fonctionnalités ainsi que l’étude
d’évaluation des deux stratégies proposées. Les résultats d’expérimentation seront
interprétés.

Enfin, Une synthèse et un ensemble de perspectives viendront pour clôturer notre travail.

2
Chapitre 1
Cloud Computing

Sommaire
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Déscription du cloud computing . . . . . . . . . . . . . . . . . . . 4
1.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Les différents services . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Infrastructure as a Service (IaaS) . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Platform as a Service (PaaS) . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3 Software as a Service (SaaS) . . . . . . . . . . . . . . . . . . . . . . 9
1.3.4 Avantages et Inconvenient des services . . . . . . . . . . . . . . . . . 10
1.4 Modelés de déploiement . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.1 Cloud public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.2 Cloud communautaire . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.3 Cloud hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.4 Cloud public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 La différence entre le cloud prive et le cloud public . . . . . . . 12
1.6 Les Avantages et Inconvénients du cloud computing . . . . . . . 12
1.6.1 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.2 Inconvénients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.7 Sécurité dans les cloud computing . . . . . . . . . . . . . . . . . . 13
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3
1.1 Introduction

e Cloud Computing souvent appelé Cloud (« le Nuage » en français) ou l’informatique

L en nuage désigne un accés aux ressources informatiques qui sont quelque part, á
travers internet.
Son accés est soit gratuit, comme c’est le cas avec le web mail soit sur abonnement, avec un
niveau de service garanti. Depuis longtemps, tout le monde utilise le Cloud Computing sans
même s’en rendre compte. Par exemple lorsque l’on utilise son web mail, Hotmail, Gmail
ou autre, nous faisons du Cloud. Les entreprises achétent ainsi des capacités qui sont par
la suite facturées un peu comme le sont l’eau, le gaz ou l’électricité. L’entreprise paye sa
consommation. Cette consommation est illimitée, un peu comme le courant électrique. Le
Cloud Computing représente la meilleure solution pour gérer une entreprise. Au lieu qu’une
structure exécute des applications elle-même, c’est une plate-forme multi-tenant partagée
qui s’en charge.
Le Cloud, il suffit simplement de s’y connecter, de le personnaliser et de l’utiliser. Son usage
á l’air si simple. . . Cependant de nombreuses questions se posent.

1.2 Déscription du cloud computing

1.2.1 Définition

Le « Cloud Computing » est un néologisme utilisé pour décrire l’association d’Internet

(« Cloud », le nuage) et l’utilisation de l’informatique (« Computing »). . C’est une maniére
d’utiliser l’informatique dans laquelle tout est dynamiquement couplé et évolutif et dans
laquelle les ressources sont fournies sous la forme de services au travers d’Internet. Les
utilisateurs n’ont ainsi besoin d’aucune connaissance ni expérience en rapport avec la
technologie derriére les services proposés. [01]
Le Cloud Computing est un paradigme émergeant dans le monde de l’informatique, né
de l’évolution des systémes distribués et des grilles informatiques. Cependant, bien qu’il
ait plusieurs similarités avec ces derniers, le Cloud Computing se différencie par certaines
caractéristiques et modéles de service et de déploiement. Ainsi, nous exposons d’abord
quelques définitions, puis décrivons les caractéristiques, modéles de service et de déploiement
spécifiques à ce paradigme. Nous présentons également quelques Nouvelles technologies
associées qui rendent possible le modéle Cloud. [03]
Le terme « Cloud » est utilisé comme métaphore pour « Internet ». Celle-ci est basée sur
la façon dont Internet est conventionnellement représenté sur les diagrammes réseau (un
nuage) afin de masquer la complexité de son architecture.

4
 Figure 1.1 – Cloud computing

1.2.2 Historique

Techniquement, le concept de Cloud Computing est loin d’être nouveau, il est même
présent depuis des décennies. On en trouve les premiéres traces dans les années 1960, quand
John McCarty1 affirmait que cette puissance de traitement informatique serait accessible au
public dans le futur. Le terme en lui-même est apparu plus couramment aux alentours de la
fin du XXe siécle et il semblerait que Amazon.com soit l’un des premiers á avoir assemblé
des data center et fournit des accés à des clients. Les entreprises comme IBM et Google
ainsi que plusieurs universités ont seulement commencé á s’y intéresser sérieusement aux
alentours de 2008, quand le Cloud Computing est devenu un concept " á la mode". [01]
Il est communément admis que le concept de Cloud Computing a été initié par le géant
Amazon en 2002. Le cybermarchand avait alors investi dans un parc informatique afin de
pallier les surcharges des serveurs dédiés au commerce en ligne constatées durant les fêtes
de fin d’année. A ce moment-lá, Internet comptait moins de 600 millions d’utilisateurs mais
la fréquentation de la toile et les achats en ligne étaient en pleine augmentation. En dépit de
cette augmentation, les ressources informatiques d’Amazon restaient peu utilisées une fois
que les fêtes de fin d’année étaient passées. Ce dernier a alors eu l’idée de louer ses capacités
informatiques le reste de l’année á des clients pour qu’ils stockent les données et qu’ils
utilisent les serveurs. Ces services étaient accessibles via Internet et avec une adaptation en
temps réel de la capacité de traitement, le tout facturé á la consommation.
Cependant, ce n’est qu’en 2006 qu’Amazon comprit qu’un nouveau mode de consommation
de l’informatique et d’internet faisait son apparition. [07]
Réalisant ce qu’ils pourraient faire de toute cette puissance, de nombreuses compagnies ont
ensuite commencé à montrer un certain intérêt á échanger leurs anciennes infrastructures
et applications internes contre ce que l’on appelle les " payer-use service " (services payés á

5
l’utilisation) [Laurie Sullivan 2006].
Auparavant, seuls les super ordinateurs permettaient de fournir cette puissance et étaient
principalement utilisés par des gouvernements, des militaires, des laboratoires et des univer-
sités pour réaliser des calculs aussi complexes que prédire le comportement d’un avion en
vol, les changements climatiques ou la simulation d’explosions nucléaires.
Désormais, des entreprises comme Google fournissent des applications qui exploitent le
même type de puissance et sont accessibles á tout moment, de n’importe oú et par tout un
chacun via Internet.
Actuellement les experts sont convaincu que bientôt, nous utiliserons le Cloud Computing
de la méme maniére que nous utilisons l’électricité, c’est à dire en payant uniquement ce
que nous consommons sans même nous soucier des aspects techniques nécessaires au bon
fonctionnement du systéme. Le principal facteur de développement restant le fait que toute
cette puissance est á tout moment partagée par plusieurs utilisateurs et évite ainsi de perdre
du " temps machine " à ne rien faire. Cela devrait également drastiquement réduire les
coûts de développement et donc les prix. [01]

1.2.3 Virtualisation

La virtualisation est une technologie permettant l’exécution de plusieurs systémes d’ex-

ploitation et/ou plusieurs applications sur le même ordinateur, ce qui accroît l’utilisation et
la flexibilité du matériel. Un même ordinateur peut ainsi permettre l’exécution de plusieurs
machines virtuelles contenant différents systémes d’exploitation et/ou différentes applica-
tions isolées les unes des autres.
La mise en œuvre d’une machine virtuelle (Virtual machine ou VM) nécessite l’ajout d’une
couche logicielle à la machine physique. L’emplacement de cette couche dépend du type
d’architecture de la machine virtuelle. Il existe deux types de technologies de machine :
les machines virtuelles applicatives (processus Virtual machines) et les machines virtuelles
systéme (system Virtual machines). [05]
La virtualisation repose sur trois éléments importants :

1. L’abstraction des ressources informatiques ;

2. La répartition des ressources par l’intermédiaire de différents outils, de maniére à ce

que celles-ci puissent être utilisées par plusieurs environnements virtuels ;

3. La création d’environnements virtuels. [06]

6
1.3 Les différents services

Le cloud computing peut être décomposé en trois couches :

1 Application (SaaS, Software as a Service)
2 Platform (PaaS, Platform as a Service)
3 Infrastructure (IaaS, Infrastructure as a Service)

7
 Figure 1.2 – Les couches du cloud computing

1.3.1 Infrastructure as a Service (IaaS)

Offre une base matérielle (" hardware ") aux plateformes en tant que service. Ces
infrastructures sont mises en place et gérées exclusivement par des architectes réseau, ce
qui permet de garder un bon niveau d’expertise et évite de mélanger les domaines de
compétence. Elle se compose d’équipements réseau et de serveurs la plupart du temps
complétement virtualités. [01]
L’IaaS offre une grande flexibilité, avec une administration à distance, et permet d’installer
tout type de logiciel. En revanche, cette solution nécessite la présence d’un administrateur
systéme au sein de l’entreprise, comme pour les solutions serveur classiques. Parmi les
prestataires d’IaaS, on peut citer : Amazon avec EC2 ou Orange Business Services avec
Flexible Computing. [8]

1.3.2 Platform as a Service (PaaS)

Le matériel (serveurs), l’hébergement et le Framework d’application (kit de composants

logiciels structurels) sont dématérialisés. L’utilisateur loue une plateforme sur laquelle il
peut développer, tester et exécuter ses applications. Le déploiement des solutions PaaS est
automatisé et évite à l’utilisateur d’avoir à acheter des logiciels ou d’avoir à réaliser des
installations supplémentaires, mais ne conviennent qu’aux applications Web. Les principaux
fournisseurs de PaaSsont : Microsoft avec AZURE, Google avec Google App Engine et
Orange Business Services. [07]

8
1.3.3 Software as a Service (SaaS)

Concept consistant á proposer un abonnement á un logiciel plutót que l’achat d’une

licence. On oublie donc le modéle client-serveur et aucune application n’est installée sur
l’ordinateur, elles sont directement utilisables via le navigateur Web. L’utilisation reste
transparente pour les utilisateurs, qui ne se soucient ni de la plateforme, ni du matériel, qui
sont mutualisés avec d’autres entreprises.
Le SaaS remplace l’ASP, aussi appelé fournisseur d’applications hébergées ou FAH, ou
application service provider en anglais ou ASP, qui est une entreprise qui fournit des
logiciels ou des services informatiques á ses clients au travers d’un réseau. Deux principales
différences avec l’ASP traditionnel sont qu’une simple interface web est utilisée côté client
dans tous les cas (pas de client lourd), et que le SaaS propose une seule instance de logiciel
qui évolue indépendamment des clients. Avec l’arrivé du Haut débit, les logiciel en mode
SaaS deviennent utilisables sans problémes. Les cibles sont les utilisateurs finaux. On
retrouvera des entreprises comme Sales Force ou Diva (projet lancé par une équipe de l’école
d’ingénieur EPITECH). [04]

Figure 1.3 – Répartition des charges

9
1.3.4 Avantages et Inconvenient des services

Figure 1.4 – Avantages et Inconvénient des services

1.4 Modelés de déploiement

D’aprés la définition donnée dans la Section précédente un nuage correspond á une

infrastructure distante, dont on ne connaˆt pas les détails architecturaux, et qui est connue
pour les services informatiques qu’elle offre. Aussi, il est courant d’utiliser le terme un
nuage pour désigner l’infrastructure gérée par un prestataire donné. On pourra alors parler
du nuage d’Amazon, de celui de Google, et ainsi de suite. On peut distinguer quatre
types principaux de modéles de déploiement pour ces nuages : le nuage privé, le nuage
communautaire, le nuage public et le nuage hybride [7]

10
 Figure 1.5 – Modelés de déploiement

1.4.1 Cloud public

Une seule et unique organisation loue ou posséde son Infrastructure, et la gére unique-
ment pour ses besoins. Elle ne la partage pas avec d’autres organisations.

1.4.2 Cloud communautaire

L’infrastructure est partagée par plusieurs organisations et concerne une communauté

spécifique qui partage des intérêts communs (une mission. des exigences de sécurité, des
obligations légales, etc.).

1.4.3 Cloud hybride

Composition de deux ou plusieurs nuages internes, communautaires ou publics. Cette

plate-forme constitue une entité unique. Les échanges qui s’y produisent s’effectuent grâce
à une technologie standard ou propriétaire qui permet la portabilité des données et des
applications.

11
1.4.4 Cloud public

Un fournisseur posséde une infrastructure dont il loue les services á plusieurs entreprises
ou groupes industriels.

1.5 La différence entre le cloud prive et le cloud public

Dans le cas du Cloud public, votre Cloud ne vous appartient pas entiérement. Un
grand nombre de ressources informatiques sont partagées avec de nombreuses entreprises
à travers l’ensemble du réseau Internet. Si ce modéle posséde de nombreux avantages en
termes de réduction des couts, de collaboration et d’agilité, pour certaines entreprises, en
revanche, il souléve, parfois á juste titre et parfois tort, certaines questions sur la sécurité
et la confidentialité des données.
De son côté, le Cloud privé propose des ressources informatiques dont l’usage est uniquement
réservé á votre entreprise. Vous pouvez héberger votre Cloud privé soit sur site, dans votre
centre de données (en utilisant une virtualisation et une automatisation á grande échelle),
soit hors site chez un fournisseur de services de Cloud. Le Cloud privé posséde la plupart des
avantages du Cloud public (options de libre-service, relative capacité de montée en charge et
facturation interne, par exemple) mais permet davantage de contrôle et de personnalisation
du fait que des ressources dédiées sont á votre disposition. Il peut offrir encore plus de
flexibilité, ce qui peut rendre son cout prohibitif et amoindrir les économies d’échelle pour
certaines entreprises. [02]

1.6 Les Avantages et Inconvénients du cloud compu-

ting

1.6.1 Avantages
• Un démarrage rapide : Le cloud computing permet de tester le business plan
rapidement, á coûts réduits et avec facilité.
• L’agilité pour l’entreprise : Résolution des problémes de gestion informatique
simplement sans avoir á vous engager á long terme.
• Un développement plus rapide des produits : Réduisons le temps de recherche
pour les développeurs sur le paramétrage de s’applications.

12
 • Pas de dépenses de capital : Plus besoin des locaux pour élargir vos infrastruc-
tures informatiques [04]

1.6.2 Inconvénients
• La bande passante peut faire exploser votre budget : La bande passante qui
serait nécessaire pour mettre cela dans le Cloud est gigantesque, et les coûts seraient
tellement importants qu’il est plus avantageux d’acheter le stockage nous-mêmes
plutôt que de payer quelqu’un d’autre pour s’en charger.
• Les performances des applications peuvent être amoindries : Un Cloud pu-
blic n’améliorera définitivement pas les performances des applications.
• La fiabilité du Cloud : Un grand risque lorsqu’on met une application qui donne
des avantages compétitifs ou qui contient des informations clients dans le Cloud,
• Taille de l’entreprise : Si votre entreprise est grande alors vos ressources sont
grandes, ce qui inclut une grande consommation du cloud.
Vous trouverez peut-être plus d’intérêt á mettre au point votre propre Cloud plutôt
que d’en utiliser un externalisé.
Les gains sont bien plus importants quand on passe d’une petite consommation de
ressources á une consommation plus importante. [04]

1.7 Sécurité dans les cloud computing

La sécurité et la conformité émergent systématiquement comme les principales Préoc-

cupations des responsables informatiques lorsqu’il est question de Cloud Computing, des
préoccupations encore plus accentuées lorsqu’il s’agit de Cloud public. La sécurité permet
de garantir la confidentialité, l’intégrité, l’authenticité et la disponibilité des informations.
La mise sur pied d’une solution de Cloud Computing comporte des problémes de sécurité
inhérents á la solution elle-même. Le fait de centraliser toutes les informations sur un site
pose un grand nombre de problémes. On peut citer comme probléme potentiel :

• Une possible interruption massive du service.

• Une cible de choix pour les hackers
• Interface et API non sécurisé
Ce point de vulnérabilité du Cloud Computing fait l’objet depuis quelques années l’objet
de recherches avancées. Il a été créé un organisme chargé de mettre sur pied des normes en
matiére de sécurité dans le Cloud Computing. Cet organisme s’appelle CSA (Cloud Security

13
Alliance). Du travail de cet organisme, il en est ressorti certaines techniques utilisées de
nos jours pour améliorer la sécurité du Cloud Computing. Parmi ces techniques on peut citer

• La multi-location : cette technique permet de créer des instances d’une même

donnée sur plusieurs sites différents. Elle permet une récupération facile en cas de
désastre.
• Le chiffrement : le chiffrement de l’accés à l’interface de contrôle, le chiffrement
des données dans le Cloud.
• L’isolation des machines virtuelles : La sécurité absolue n’existe pas, donc le
probléme de sécurité reste le plus souvent un probléme de confiance entre le fournisseur
de service et le consommateur de service. Cette confiance se traduit par la signature
d’un contrat nommé SLA (Service Levé Agreement). Ce contrat Précise les taux de
disponibilité du service. En régle générale, et pour la plupart des fournisseurs, ce
taux est supérieur á 99

1.8 Conclusion

Le Cloud Computing est une récente innovation. Il accroît l’efficacité et la souplesse des
sociétés dans la mesure oú il permet de travailler à plusieurs sans contrainte (technique,
horaire, géographique. . . ), de gérer à la carte les logiciels et donc les fonctionnalités utilisées,
de ne plus s’occuper de tâches longues, compliquées et contraignantes liées á la technique,
de gagner du temps en limitant les ressaisies et surtout de faire des économies.
Le Cloud a pour objectif de décharger l’utilisateur des problématiques serveur et lui per-
mettre de disposer de ses données et de ses outils oú qu’il soit, dés qu’il a une connexion
Internet.
Le Cloud Computing est un phénoméne qui fait beaucoup parler de lui de par sa facilité
d’exploitation des données.

14
Chapitre 2
Réplication

Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 principe de réplication . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Les techniques de réplication . . . . . . . . . . . . . . . . . . . . . 16
2.4 Avantages et Inconvénient de la réplication . . . . . . . . . . . . . 18
2.4.1 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 Inconvénient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 protocole de la réplication . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.1 protocole de la réplication active . . . . . . . . . . . . . . . . . . . . 19
2.5.2 protocole de réplication passive . . . . . . . . . . . . . . . . . . . . . 20
2.5.3 protocole de réplication semi active . . . . . . . . . . . . . . . . . . . 21
2.6 La cohérence des données . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.1 Gestion de la cohérence . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7 Protocole de cohérente . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

15
2.1 Introduction

utilisation des techniques de réplication de données permet de mettre en place des

L solutions, avec plus ou moins d’efficacité, à des catégories de problèmes. Un com-

posant logiciel répliqué est défini comme un composant logiciel qui possède une
représentation sur deux ou plusieurs machines. Il existe deux types fondamentaux de proto-
coles de réplication :

1. le protocole actif où tous les réplicas effectuent les traitements de façon concurrente,
2. le protocole passif où un seul réplica poursuit son exécution et transmet périodique-
ment son état courant aux autres réplicas pour maintenir la cohérence de l’ensemble
du groupe

2.2 principe de réplication

La réplication de données consiste à stocker des données sur plusieurs nœuds géogra-
phiquement distribues (voir Figure 2.1). L’intérêt premier de cette réplication est que, si
une donnée n’est plus disponible, le système peut continuer à assurer ses fonctionnalités en
utilisant une donnée répliquée, ce qui permet d’augmenter la disponibilité des données et la
tolérance aux pannes. D’un autre côte, puisque la donnée est répliquée sur plusieurs nœuds,
deux contraintes doivent être satisfaites vis- à-vis de l’utilisateur :
une requête de lecture doit être en mesure de retourner une valeur qui soit correcte (valeur
de la dernière écriture) ; réduire le temps de réponse d’une requête en accédant au nœud qui
soit le plus proche possible de l’utilisateur, afin d’augmenter les performances du système
[10]

2.3 Les techniques de réplication

Ranganathan et Foster définissent les quatre questions auxquelles une stratégie de

création de répliques doit répondre : [09]
• Quand créer les répliques ? moment de la réplication.
• Quels fichiers doivent être répliqués ? choix de l’entité à répliquer.
• Où les répliques doivent-elles être placées ? placement des répliques.
• Comment une copie est-elle crée ? manière de répliquer une entité.

16
 Figure 2.1 – Environnement d’utilisation de la technique de réplication

1 Moment de la réplication : Pour répondre à la question quand ? deux

solutions ont possibles

• Réplication statique : Les répliques persistent jusqu’à ce qu’elles soient effacées

par l’utilisateur du nœud sur lequel elles sont hébergées ou que leurs durées de vie
respectives expirent. L’avantage de ce schéma est sa simplicité, son inconvénient est
sa non-adaptabilité aux changements de comportement des participants.
• Réplication dynamique : Contrairement à la réplication statique, la réplication
dynamique crée et supprime Automatiquement les copies selon l’évolution des de-
mandes des utilisateurs. L’avantage est la réduction des points d’engorgements et
l’équilibrage de la Charge. L’inconvénient observé est l’induction de coûts supplé-
mentaires causés par l’évaluation en temps-réel du trafic réseau pour prendre les
décisions de réplication. Selon le moment de la réplication, on distingue : Réplication
à la demande : la réplique est créée suite à la demande d’un client. Réplication
périodique : elle est indépendante des requêtes des clients. Son but est de permettre
la gestion automatique de répliques avec des stratégies adaptées aux comportements
des clients. Le processus de réplication est déclenché à chaque intervalle de temps
(période).

2 Choix de l’entité à répliquer : Pour répondre à la question quoi : les données

répliquées sont généralement de deux types : des fichiers ou des objets. Les objets
peuvent être composés d’un ensemble de fichiers distribués (on les appelle aussi
collection). Selon les stratégies de réplication, les données à répliquer, peuvent être
les plus populaires ou encore les plus fréquemment accédées.
3 Placement des répliques : Pour répondre à la question où : les stratégies dépla-
cement de répliques doivent tenir compte du fait que les sites potentiels :
ne possèdent pas déjà de réplique de la donnée ;

17
 possèdent l’espace de stockage suffisant ;
sont à une distance raisonnable en termes de temps de transfert.

4 Manière de répliquer une entité : Pour répondre à la question comment :

Le processus de création de copie dépend de la structure et de l’état de l’entité à
répliquer. La structure de l’entité peut être indivisible ou composée, alors que l’état
peut être constitué de données, de code et éventuellement d’un état d’exécution. Les
problèmes de coûts sont au centre des stratégies de réplication. Un enjeu majeur de
la réplication est la réduction de la latence d’accès ainsi que la consommation de
bande passante.

2.4 Avantages et Inconvénient de la réplication

2.4.1 Avantages

Augmenter la disponibilité des données : L’un des principaux avantages de la réplication

est que les données peuvent être disponibles localement et non plus par le biais de connexions
potentiellement onéreuses, souvent pas fiables et lentes. Si une copie tombe en panne, il est
toujours possible d’obtenir les données à partir d’autres copies, ce qui confère au système
une plus grande robustesse ;

• Améliorer la tolérance aux pannes : la réplication permet les accès aux don-
nées même en cas de défaillance d’un support puisque la donnée se trouve sur
plusieurs endroits ;
• Améliorer les performances : La réplication permet d’améliorer le temps de
réponse des requêtes et l’accès aux données pour deux raisons essentielles :
les requêtes sont traitées sur un serveur local sans accès à un réseau étendu qui
nécessite de la communication ;
le traitement local allège la charge globale des serveurs.

2.4.2 Inconvénient
• Placement des répliques : Ce problème consiste à choisir, en fonction des objec-
tifs 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

18
 • 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 ;

• Cohérence des répliques : les techniques de réplication n’assurent pas une co-
hérence des données de l’ensemble des répliques. Ainsi, il est possible d’avoir, à un
instant donné, des copies différentes d’un même ensemble de données sur différents
nœuds

2.5 protocole de la réplication

La réplication peut être utilisée dans plusieurs types, parmi lesquels, nous citons : [12]

2.5.1 protocole de la réplication active

Avec la réplication active, chaque copie joue un rôle identique à celui des autres. Le
principe de cette réplication peut être défini en trois phases : Réception des requêtes : toutes
les copies reçoivent la même séquence (ensemble totalement ordonné de requêtes).
Traitement des requêtes : toutes les copies traitent les requêtes de manière déterministe.
Emission des réponses : toutes les copies émettent la même séquence de réponses. [12]

Figure 2.2 – protocole de réplication active

19
2.5.2 protocole de réplication passive

Le principe de la réplication passive est défini comme suit :

• 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.
• Emission des réponses : la copie primaire est la seule à émettre les réponses.
Comme le montre La figure 2.3, Le client envoie la requête uniquement à la copie primaire
S1. Celle-ci traite la requête, construit un point de reprise et l’envoie à l’aide d’un multicast
fiable assurant l’ordre FIFO, aux copies secondaires S2 et S3 en précisant le Changement
de son état (message update). Après la mise à jour de leurs états, les copies secondaires
envoient un ack à la copie primaire.
La copie primaire envoie la réponse au client après réception des Ack de toutes les copies
secondaires. Le point de reprise permet désynchroniser l’état des copies secondaires avec
celui de la copie primaire puisque celle-ci est la seule qui communique avec le reste du
système [12]

20
 Figure 2.3 – protocole de réplication passive

2.5.3 protocole de réplication semi active

C’est un protocole hybride qui se situe entre les deux protocoles précédents, où toutes
les copies exécutent en même temps la requête du client, mais une seule copie (leader)
d’entre elles émet la réponse, les autres copies (suiveurs) mettent à jour leur état interne et
sont donc étroitement synchronisées avec le leader (voir Figure 2.4). [11]

21
 Figure 2.4 – protocole de réplication semi active

2.6 La cohérence des données

Les systèmes à mémoire répartie sont caractérisés par plusieurs niveaux de stockage
(Mémoire caches, Mémoire principale). La gestion efficace de ces différents niveaux de
stockage permet d’améliorer les performances du système.Les mémoires caches exploitent
la notion de localité en maintenant automatiquement des copies des données récemment
utilisées. Les prochains accès à ces données sont effectués directement dans les mémoires
caches et non pas dans la mémoire principale.De multiples copies d’une même donnée
peuvent être présentes sur les différents caches.Les cœurs en possession d’un copie d’une
donnée peuvent à tout moment modifier sa valeur localement ce qui génère le problème
d’incohérence. Les modèle de gestion de cache est responsable de transmettre les mises à
jours des données vers la mémoire principale. Un système de cache est donc dit cohérent
si pour chaque accès en lecture à une donnée la valeur retournée correspond à la dernière
modification apportée à cette donnée. [13]

2.6.1 Gestion de la cohérence

La gestion de la 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 [14].
Les protocoles de gestion de la cohérence offrent aux utilisateurs, la garantie d’une vue

22
cohérente des données dispersées [15]. (Voir la figure 2.5)

Figure 2.5 – Vue cohérente des données

2.7 Protocole de cohérente

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 terme de
propagationdes mises a‘ jour est ainsi n´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 garantira cohérence mutuelle d’un ensemble de répliques dans des délias
acceptables. Les diverses répliques d’un même objet doivent être cohérentes, c’est-à-dire,
apparaitre comme une copie unique vis-à-vis des utilisateurs (voir Figure 2.6).
La cohérence est une relation qui définit le degré de similitude entre les copies d’une entité
répliquée. Dans le cas idéal, cette relation caractérise des copies qui ont des comportements
identiques. Dans les cas réels, ou‘ les copies évoluent de manière différente, la cohérence
d´finit les limites de divergence autorisées entre copies. La relation de cohérence est assurée
par synchronisation entre copies .Le terme protocole de cohérence d´esbigne l’ensemble
des opérations nécessaires pour maintenir la cohérence entre copies. Dans un tel protocole,
le modèle de cohérence d écrit la manière dont la cohérence des différentes copies d’une
donnée est gérée. C’est en effet ce modèle qui va déterminer comment les mises à jour d’une
donnée par un processus seront visibles par les autres processus. Les modèles de cohérence
sont mis en œuvre par des protocoles de cohérence pour lesquelles deux orientations sont
possibles : [10]
Les protocoles de cohérence forte appel ´es aussi protocoles pessimistes et les protocoles de

23
 Figure 2.6 – Accès aux données répliquées

cohérence faible ou encore protocoles optimistes.

1. Cohérence forte : Une cohérence de répliques est dite forte lorsque toute in-
terrogation d’une copie quelconque reflète le résultat de toutes les modifications
antérieures ;
2. Cohérence faible : Une cohérence de répliques 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

2.8 Conclusion

Dans ce chapitre, nous avons présenté le principe et les techniques de réplication, et

nous avons défini la notion de réplication en spécifiant ses avantages et ses inconvénients
ainsi que ses différents Protocol. 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 œuvre et son efficacité du point de
vue des objectifs visés par sa mise en place.

24
Chapitre 3
Tolérance aux pannes

Sommaire
3.1 Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Notion de surete de fonctionnement . . . . . . . . . . . . . . . . . 26
3.2.1 Attributs de la surete de fonctionnement . . . . . . . . . . . . . . . . 26
3.2.2 Entraves la surete de fonctionnement . . . . . . . . . . . . . . . . . 28
3.2.3 Moyens d’assurer la surete de fonctionnement . . . . . . . . . . . . . 29
3.2.4 Classification des pannes . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.5 Détection des pannes . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 méthode de tolérance aux pannes . . . . . . . . . . . . . . . . . . . 32
3.4 Techniques de tolérance aux pannes dans les systèmes repartis 33
3.4.1 Tolérance aux panne par sauvegarde (checkpointing) . . . . . . . . 33
3.4.2 Tolérance aux pannes par journalisation . . . . . . . . . . . . . . . . 37
3.4.3 Comparaison de différents protocoles de tolérance aux pannes par
reprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 La tolerance aux pannes dans les cloud . . . . . . . . . . . . . . 39
3.6 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.1 Live migration, pourqoi ? . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

25
3.1 Introduction :

a capacité d’un système à fonctionner malgré une défaillance d’une de ses composantes

L est appelée tolérance aux pannes (parfois nommée tolérance aux fautes, en anglais
fault tolérance).
Puisqu’il est impossible d’empêcher totalement les pannes, une solution consiste à mettre
en place des mécanismes de redondance, en dupliquant les ressources critiques, ou des
techniques de sauvegarde et de retour en arrière. Lorsqu’une des ressources tombe en panne,
les autres ressources prennent le relais a afin de laisser le temps aux administrateurs du
système de remédier à l’avarie. Idéalement, dans le cas d’une panne matérielle, les éléments
matériels fautifs devront pouvoir être « extractibles à chaud » (en anglais « hot swappa blé
») c’est-à-dire pouvoir être extraits puis remplacés, sans interruption de service.[26]
Néanmoins, la mise en place d’une architecture redondante ne permet que de s’assurer de la
disponibilité des données d’un système mais ne permet pas de protéger les données contre
les erreurs de manipulation des utilisateurs ou contre des catastrophes naturelles telles
qu’un incendie, une inondation ou encore un tremblement de terre. Il est donc nécessaire
de prévoir des mécanismes de sauvegarde (en anglais backup), idéalement sur des sites
distants, afin de garantir la pérennité des données. Par ailleurs, un mécanisme de sauvegarde
permet d’assurer une fonction d’archivage, c’est-à-dire de conserver les données dans un
état correspondant à une date donnée. [26]

3.2 Notion de surete de fonctionnement

La sureté de fonctionnement d’un système (éventuellement distribué) offre une vision

plus générale à la problématique de sécurité abordée dans ce travail. Elle intègre également
les problèmes de fiabilité et de maintenabilité. Plus spécifiquement, une défaillance du
système surviendra lorsque le service délivré diffère du service spécifié, soit par valeur, soit
parce qu’il n’a pas été dispensé dans l’intervalle de temps demandé. Elle est causée par une
faute qui, elle-même, génère une erreur. La sureté de fonctionnement peut-être présentée
autour de trois notions : ses attributs, ses entraves et ses moyens. [27]

3.2.1 Attributs de la surete de fonctionnement

Les attributs de la sureté de fonctionnement d’un système mettent plus ou moins l’accent
sur les propriétés que doivent vérifier la sureté de fonctionnement du système.

26
Ces attributs permettent d’évaluer la qualité du service fourni par un système. Dans six
attributs de la sureté de fonctionnement sont définis : [28]

Disponibilité : c’est la propriété requise par la plupart des systèmes surs de fonctionne-
ment. Il s’agit de la fraction de temps durant laquelle le système est disponible pour des
fins utiles (en excluant les temps de défaillance et de réparation). C’est la probabilité que le
système soit opérationnel à l’instant.

Fiabilité : cet attribut évalue la continuité du service, c’est à dire. Le taux en temps
de fonctionnement pendant lequel le système ne subit aucune faute. C’est la probabilité
conditionnelle qu’un système fonctionne sans défaillance pendant l’intervalle de temps [0, t]
sachant qu’il était opérationnel à l’instant 0 ;

Sécurité-innocuité : Evalue la continuité du service avant l’arrivée d’une défaillance

catastrophique. Elle utilise donc la même expression mathématique que la fiabilité appliquée
uniquement aux défaillances catastrophiques ;

Confidentialité : cet attribut évalue la capacité du système à fonctionner en dépit de

fautes intentionnelles et d’intrusions illégales ;

Intégrité : l’intégrité d’un système définit son aptitude à assurer des altérations approu-
vées des données ;

Maintenabilité : cette propriété d’écrit la souplesse du système vis-à-vis des modifica-

tions apportées en vue de sa maintenance. C’est le temps d’interruption de fonctionnement
due à des opérations de maintenance préventive (avant qu’une défaillance ne survienne),
corrective (à la suite d’une défaillance), et perfective (pour faire évoluer le système). L’im-
portance des attributs de la sureté de fonctionnement présentés ci-dessus est principalement
liée aux applications et à leurs besoins. Par exemple, pour les applications critiques comme
le pilotage de fusées, une grande importance doit être donnée à tous les attributs de la sureté

27
de fonctionnement. Les applications parallèles à longue durée d’exécution font prévaloir la
maintenabilité et la fiabilité.

3.2.2 Entraves la surete de fonctionnement

Les entraves à la sureté de fonctionnement sont de trois types[27] : les fautes, les erreurs
et les défaillances. Fautes, erreurs et défaillances sont liées par des relations de causalité
illustrées sur la Figure 3.1.

Figure 3.1 – La chaine fondamentale des entraves a la surete de fonctionnement

Fautes : Une faute ou panne est caractérisée par sa nature, son origine et son étendue
temporelle [28]. La nature d’une faute donne le caractère intentionnel ou accidentel d’une
faute, les fautes intentionnelles sont créées délibérément dans le dessein de nuire tandis que
les fautes accidentelles apparaissent de manière fortuite.
La durée d’une faute exprime la dépendance vis-à-vis de conditions ponctuelles, Une faute
temporaire est présentée pendant une durée limitée et disparait si telle ou telle condition
interne ou externe ne peut l’éliminer.
L’origine d’une faute est la source d’une faute. Une faute est due à des phénomènes soit
physiques soit humains. Elle est provoquée soit par une partie de l’état du système soit par
l’environnement. Elle appartient soit à la phase de conception soit à la phase d’exploitation
du système. L’étendue d’une faute précise la portion du système affectée. Une faute locale
affecte une partie du système alors qu’une faute globale en affecte plusieurs.

Erreurs : Une erreur est une partie fausse de l’état du système. Tant que le service
n’utilise pas la partie fausse, l’erreur est dite latente. Activée ; l’erreur est dite effective est
une défaillance apparait si le service rendu n’est plus correcte. Une erreur est la conséquence
d’une faute. Une défaillance survient dès que le système utilise un état erroné [29].Powell
propose une classification des erreurs selon leurs types (valeur ou temps). Premièrement, le
service ne correspond pas en valeur à celui spécifié. Si la valeur rendue n’est pas interprétable
alors l’erreur est dite non-codée, sinon elle est dite arbitraire. Deuxièmement, le service n’est

28
pas délivré dans l’intervalle de temps spécifié. L’auteur distingue six catégories. Le service
rendu est toujours en avance ou toujours en retard ou encore arbitrairement en avance ou
en retard. Le fait que le système omette de rendre le service est considère également comme
un type d’erreur. Un arrêt (crash) est défini par le fait que le système omet définitivement
de délivrer des services.

Défaillances : une défaillance dénote l’incapacité d’un élément du système à assurer

le service spécifié par l’utilisateur. La défaillance est caractérisée par son domaine, sa
perception par les utilisateurs et ses conséquences sur l’environnement [28]. Le domaine de
défaillance est le domaine des erreurs actives.
Une défaillance est cohérente si tous les utilisateurs en ont la même perception. Sinon, c’est
une défaillance incohérente ou byzantine.
Les conséquences sur l’environnement sont appréciées de mineures ou bénignes à majeures
ou catastrophiques suivant les dommages subis.

3.2.3 Moyens d’assurer la surete de fonctionnement

Il existe toute une panoplie de moyens pour assurer ou évaluer la sureté de fonctionne-
ment d’un système. Ces moyens sont définis par les méthodes et les approches utilisées pour
assurer cette propriété. Une classification usuelle de ces moyens conduit à quatre catégories
[31] :

La prévention des fautes : vise à empêcher l’apparition ou l’introduction des fautes

dans le système. Elle repose sur des règles de développement (modularisation, utilisation
de langage fortement typé, preuve formelle, etc.). Ce sont généralement les approches de
vérification des modèles conceptuels ;

L’élimination des fautes : qui se focalise sur les techniques permettant de réduire la
présence de fautes ou leurs impacts. L’élimination de faute se fait pendant les phases de
validation ou lors des premières utilisations du système. Cela est réalisé par des méthodes
statiques de preuve de la validité du système (simulation, preuves analytiques, tests, ...) ;

29
 La prévision des fautes : anticipe ces dernières pour ensuite pouvoir appliquer des
moyens de l’élimination ou de la tolérance aux fautes. Il s’agit d’une estimation et évaluation
de la présence des fautes (temps, nombre, impact) et de leurs conséquences. Ceci est réalisé
généralement par des méthodes d’injection de fautes afin de valider le système relativement
à ces fautes ;

La tolérance aux pannes ou aux fautes : qui essaye de fonctionner en dépit des
fautes. Le degré de tolérance aux pannes se mesure par la capacité du système à continuer
à délivrer son service en présence de fautes. La Figure 3.2 résume les notions associées à la
sureté de fonctionnement présentées ci-dessus.

3.2.4 Classification des pannes

La capacité d’identification du modèle de pannes joue un rôle très important si l’on veut
réaliser la tolérance aux pannes. En effet, les conséquences et le traitement d’une panne
diffèrent selon son modèle. Les pannes peuvent être classées selon leur degré de gravité, leur
degré de permanence et leur nature. Une première classification des pannes selon le degré
de gravité des défaillances est proposée [32] et permet de différencier :

Les pannes franches (crash faults) : soit le système fonctionne normalement (les
résultats sont corrects), soit il ne fait rien. Il s’agit du modèle de panne le plus simple
auquel on essaie de se ramener aussi souvent que possible

Les pannes par omission : le système perd des messages entrant ou sortant d’un
processus. On retrouve généralement ce modèle de pannes dans les réseaux

Les pannes de temporisation : les déviations par rapport aux spécifications

concernent uniquement le temps (typiquement le temps de réaction à un évènement) ;

30
 Figure 3.2 – L’arbre de la surete de fonctionnement

Les pannes par valeurs : les résultats produits par un composant défaillant sont
incorrects. Ce type de panne est typiquement détecté par les mécanismes de certification
des résultats proposés ;

Les pannes byzantines : le système peut faire n’importe quoi, y compris avoir un
comportement malveillant. [28] Une seconde classification des pannes selon leur degré
de permanence est également possible. On distingue ainsi les pannes transitoires qui se
produisent de manière isolée, les pannes intermittentes qui se déclenchent aléatoirement
plusieurs fois et les pannes permanentes qui persistent dès qu’elles apparaissent jusqu’à
réparation.
Il existe un troisième classement qui distingue la nature des pannes selon qu’elles soient
accidentelles ou intentionnelles.

3.2.5 Détection des pannes

Le problème de la détection des pannes est résolu différemment selon le modèle de com-
munication du système. Considérons d’abord le cas des modèles synchrones, dans lesquels le
temps de transmission d’un message est borné. Supposons qu’un envoi de message provoque
la mise en attente de l’émetteur d’une confirmation de réception de la part du récepteur.
La détection des pannes franches et de temporisation peut alors être réalisée à l’aide de
délais de garde "Watch dog" lors des communications : lorsqu’un processus communique
avec un autre et ne reçoit pas de confirmation après ce délai de garde, il peut considérer

31
que le processus cible est défaillant.
Le problème devient plus complexe dans le cas des modèles asynchrones : le temps de
transmission d’un message n’est pas borné. Les communications entre les nœuds ne peuvent
donc plus être utilisées pour détecter les pannes car il est impossible de prédire le moment
ou le message est effectivement reçu par le récepteur. On a alors recours à un détecteur (ou
suspecter) de pannes [33], qui informe les processus sur l’état du système. Ces détecteurs
utilisent eux aussi des délais de garde. On distingue deux modèles différents :

• Le modèle push, dans lequel chaque processus du système doit régulièrement informer
les détecteurs de pannes de son état. Si ce détecteur n’a pas reçu de message de type
"je suis vivant" de la part d’un processus depuis un temps donné, ce processus est
suspecté d’être défaillant.
• Le modèle pull, dans lequel ce sont les détecteurs de pannes qui envoient régulièrement
des requêtes de type "es-tu vivant ?" aux processus du système. Un processus qui ne
répond pas dans un temps donné est suspecté d’être défaillant.
• On note que l’on parle de soupçons parce que le processus incriminé n’est pas
forcement en panne : le message peut être encore en transit dans le système à la fin
du délai. Chandra et al. ont défini dans [33] les notions de justesse, qui indique si un
détecteur de pannes peut considérer comme défaillant un processus correct, et de
complétude, qui indique s’il est possible qu’un processus en panne ne soit jamais
détecté.

3.3 méthode de tolérance aux pannes

La tolérance aux fautes est une des méthodes permettant le développement de systèmes
surs de fonctionnement. Elle vise à éviter les défaillances et est mise en œuvre par la
détection des erreurs et le rétablissement du système. La détection permet d’identifier la
présence d’une erreur. Elle peut être effectuée soit pendant l’exécution normale du service,
soit pendant une suspension du service (ce qui permet de révéler l’éventuelle présence
d’erreurs latentes ou de fautes dormantes). Le rétablissement du système vise à transformer
l’état erroné en un état exempt d’erreur et de faute. Le traitement de fautes fait appel
à des techniques de diagnostic, de passivation, de reconfiguration ou de réinitialisation.
Le traitement de l’erreur peut se faire par trois techniques : la reprise, la poursuite et la
compensation [27].

Reprise : est la technique la plus couramment utilisée. L’état du système est sauvegardé
régulièrement. Le système est ramené dans un état sauvegardé (point de reprise) survenu

32
avant l’occurrence d’erreur.

Poursuite : consiste à rechercher un nouvel état exempt d’erreur. Ceci peut par
exemple être réalisé en associant un traitement exceptionnel lorsqu’une erreur est détectée.
Le système est amené dans un nouvel état exempt d’erreur.

Compensation : nécessite que l’état du système comporte suffi samment de redondance

pour permettre sa transformation en un état exempt d’erreur. Elle est transparente vis-à-vis
de l’application car elle ne nécessite pas de ré-exécuter une partie de l’application (reprise),
ni d’exécuter une procédure dédiée (poursuite)[34]. Reprise et poursuite sont invoquées
à la demande, après qu’une ou plusieurs erreurs aient été détectées. Contrairement à la
reprise, la poursuite ne garantit pas que le service soit fournie (exemple : saut d’un pas de
calcul sans résultat). La compensation peut, quant à elle, être appliquée à la demande ou
systématiquement, indépendamment de la présence ou de l’absence d’erreur. Le traitement
d’erreur est, si besoin est, suivi du traitement de faute.
Ils constituent le rétablissement du système, d’où le qualificatif de la stratégie de tolérance
aux fautes correspondante : détection et rétablissement. Le masquage de fautes résulte de
l’application systématique de la compensation. Un tel masquage pouvant entrainer une
diminution non perçue des redondances disponibles, sa mise en œuvre pratique comporte
généralement une détection d’erreur, conduisant au masquage et détection[35].

3.4 Techniques de tolérance aux pannes dans les sys-

tèmes repartis

La tolérance aux pannes dans les systèmes répartis et parallèles est le plus souvent
réalisée par l’emploi d’un mécanisme de redondance.

3.4.1 Tolérance aux panne par sauvegarde (checkpointing)

Le checkpointing est considère comme étant une technique qui consiste à sauvegarder
dans un support de stockage stable l’état d’un processus durant son exécution. En cas de
panne, le processus est redémarré depuis son dernier checkpoint [36].

33
Dans ce contexte, plusieurs actions de checkpoint sont envisagées. En effet, nous pouvons
varier les instants et les méthodes de checkpoint. En premier lieu, il se peut que l’action de
reconfiguration ne recoure à aucun checkpoint. En second lieu, nous pouvons définir un
mécanisme de checkpoint comme étant périodique, dans ce cas les différents checkpoints
sont réalisés d’une façon périodique. Comme les positions de ces checkpoints sont figées et
préalablement déterminées, nous exposons en troisième lieu un autre type de checkpoint
que nous notons un checkpoint adaptatif. Ce mécanisme offre une meilleure audibilité en
particulier au niveau du choix à propos de l’instant de checkpoint. En dernier lieu, nous
pouvons recourir à réaliser un checkpoint instantané, ceci dépend du besoin de migrer à
un instant donné en supposant qu’il est possible d’ajouter un checkpoint à cet instant de
mobilité. Il est à noter que les checkpoints peuvent avoir lieu aux barrières naturelles d’un
processus d’orchestration (c’est-à-dire au début ou à la fin d’un bloc « Flow », ou encore
dans un bloc élémentaire au début d’une structure séquentielle), sinon les checkpoints seront
qualifiés de forcés [36] .
Les protocoles de tolérance aux pannes par point de reprise se basent sur la création d’états
directement recouvrables. Ce type de protocole crée pendant l’exécution ou recherche après
une panne des états globaux cohérents qui sont utilisés pour redémarrer l’exécution. Un
état global est alors appelé ligne de recouvrement. Il existe différentes.
Approches pour assurer la cohérence de la ligne de recouvrement.

3.4.1.1 Sauvegarde synchronisée (coordonnée)

Les points de reprises sont réalisés de manière coordonnée sur tous les processus de
l’exécution, de façon à assurer que l’état global résultant soit cohérent. Le principal incon-
vénient de cette technique est le surcout introduit par la coordination de tous les processus
participants. Aussi, afin d’améliorer les performances de la sauvegarde coordonnée, plusieurs
techniques ont été proposées :

• bloquante : les protocoles de points de reprise bloquants arrêtent leur exécution

pendant la prise du point de reprise et ne la reprennent que lorsque tous les processus
l’ont fait. Ainsi il est impossible qu’un message ne traverse la vague de points de
reprise ;
• non bloquante : ce protocole évite de bloquer le processus durant la phase de
sauvegarde en créant un processus clone chargé de la sauvegarde ; la cohérence est
assurée par des messages "balais", qui vident les canaux de communication afin
d’éviter les messages orphelins.
• avec horloge synchronisée : les horloges de chaque machine sont synchronisées,
et les processus déclenchent les points de reprise en fonction de leur horloge locale.

34
 Ce protocole évite la phase de synchronisation par envois de messages, en utilisant
une horloge synchronisée ; Dans les deux premiers cas, ce type de protocole nécessite
l’utilisation de messages additionnels. L’approche synchronisée permet d’éviter l’effet
domino puisque tous les états globaux crées sont forcément cohérents. Une approche
synchronisée est souvent choisie en pratique à cause de sa simplicité d’implémentation
et d’intégration à un système existant.

3.4.1.2 sauvegardes indépendantes

Cette méthode consiste à faire prendre aux différents processus du système des points
de reprise de manière totalement indépendante. La cohérence des états globaux formés
n’est donc pas assurée et c’est en cas de panne que le protocole recherche une ligne de
recouvrement parmi tous les états globaux formés. Cette recherche s’effectue généralement
par la création d’un graphe de dépendance entres les points de reprise locaux.
L’inconvénient principal de cette approche est le risque d’effet domino qui peut causer une
perte importante du travail réalisé avant la panne et la sauvegarde inutile de points de
reprise, ceux-ci ne faisant jamais partie d’un état global cohérent. Ces points de reprise
augmentent le cout de l’exécution normale (i.e. en l’absence de panne) et ne servent pas
à la reprise après une panne [38]. De plus, la sauvegarde non coordonnée oblige chaque
processus à maintenir plusieurs points de reprise.
Afin de déterminer un état global cohérent (ligne de recouvrement), chaque processus dispose
d’un journal en mémoire stable dans lequel il enregistre tout ou partie des messages échangés
ainsi que leurs historiques. Lorsqu’une défaillance survient, l’algorithme de reprise utilise
les points de reprise locaux et les journaux afin de déterminer une ligne de recouvrement.

3.4.1.3 sauvegardes induites par les communications (par message)

La sauvegarde induite par les communications (Communication-Indue Checkpointing ou

CIC) [40] est un compromis entre la sauvegarde coordonnée et la sauvegarde non coordonnée.
Ce protocole utilise deux types de points de sauvegarde : les sauvegardes locales et les
sauvegardes forcées. Les sauvegardes locales sont des sauvegardes que le processus décide
d’effectuer indépendamment. Les sauvegardes forcées sont des sauvegardes qui doivent être
effectuées pour empêcher l’effet domino en cas de reprise [34]. On distingue deux familles
de protocoles :

• Les protocoles model-base : les communications et les prises de points de reprise

doivent respecter un certain motif. Par exemple, si tout envoi et toute réception de
message est précède d’un point de reprise, alors tous les points appartiennent au

35
 moins à un état global cohérent, et le dernier point pris fait toujours partie de la
ligne de recouvrement. Ces protocoles sont généralement basés sur les notions de
chemins et de cycles pour déterminer les états globaux cohérents.
• Les protocoles index-based : les points de reprise sont indexés, chaque message
porte l’index du dernier point de l’émetteur. Sur réception d’un message indiquant
un index supérieur au sien, le récepteur doit prendre un point de reprise avant la
prise en compte du message : l’incohérence est évitée "au dernier moment". Ce type
de protocole utilise donc une méthode basée sur la suppression des dépendances
causales entre les points de reprise des processus qui ont des communications directes.

3.4.1.4 Analyse comparative des différentes méthodes de point de reprise

Nous allons comparer ici les approches présentées dans la partie précédente. Nous ne
considèrerons que les approches synchronisées et induites par messages ; en effet,l’approche
indépendante n’implique pas réellement l’utilisation d’un protocole : la recherche d’un état
global cohérent est faite après une panne, au moment de la reprise.Nous comparerons sur
les points suivants :
Le surcout pendant l’exécution, en termes de CPU et de réseau,
Le nombre de retours arrière moyen,
Le surcout de stockage, et la facilité du ramassage sur la mémoire stable des points de
reprise devenus inutiles.

• Surcout pendant l’exécution : Les protocoles synchronisés bloquant ont en gé-

néral un surcout élevé durant l’exécution à cause de la phase de synchronisation qui
stoppe l’exécution. De plus, le temps de blocage de l’exécution étant proportionnel
au nombre de processus, ce type de protocole passe difficilement à l’échelle. Dans
certains cas particuliers, l’approche bloquante peut cependant être intéressante :
Coti et al. Ont montré dans [41] que l’approche bloquante était plus efficace que
l’approche non bloquante dans le cas des petits systèmes avec des liens réseaux haute
performance.
Par rapport à une approche synchronisée, l’approche induite par messages ne rajoute
pas de message additionnel durant l’exécution : le surcout principal est dû aux points
de reprise additionnels qui ont été forcés par le protocole durant l’exécution. Il y a
aussi un surcout dû à la taille des messages qui peut être très diffèrent d’un protocole
à l’autre, allant de sans surcout pour les approches model-basedà un vecteur d’entiers
de la taille du nombre de processus dans le système.
• Nombre moyen de retours arrière : Les protocoles synchronisés ont ici un avan-
tage certain : tous les points de reprise sont utiles, et lorsqu’un processus prend un
point de reprise, il est assuré de ne pas devoir retourner plus loin quece point en cas

36
 de panne.
Dans le cas des protocoles induits par messages, on trouve deux types de solution.
La première est d’assurer que tous les points de reprise sont utiles, c’est à dire
qu’ils font partie d’un état global cohérent. Ces protocoles sont basés sur l’approche
modelbased, et ont été classifiés par Manivannan dans [42], selon qu’ils assurent
l’absence de chemin "zigzag" (Strictly Z-Path Free (SZPF), Z-Path Free (ZPF)),
ou l’absence de cycle "zigzag" (Z-Cycle Free, ZCF). La deuxième solution est de
maximiser la probabilité que tous les points soient utiles, sans pour autant l’assurer.
C’est le cas des protocoles index-based.
Cependant, avec ces deux solutions, le dernier point de reprise d’un processus ne
fait pas toujours partie de la dernière ligne de recouvrement. Il est donc possible que
le processus doive reprendre depuis un point de reprise plus ancien. A la différence
d’une approche synchronisée, le travail potentiellement perdu par un processus en
cas de panne n’est donc pas borné.
• Surcout de stockage et ramassage : Sur ce point aussi, les protocoles synchro-
nisés sont avantageux : puisque tout état global nouvellement créé est forcément
un état cohérent, alors l’état global précèdent peut être effacé de la mémoire. Le
surcout est donc minimal puisqu’il n’est nécessaire de conserver qu’un seul état
global (plus bien sur celui en construction), et le ramassage des états devenus inutiles
deviennent trivial. Le ramassage des points de reprise dans le cas des protocoles
induits par messages est dépendant de la politique choisie, et nécessite le plus souvent
un mécanisme complexe pour déterminer les points devenus inutiles.

3.4.2 Tolérance aux pannes par journalisation

Le principe de la tolérance aux pannes par journalisation est de sauvegarder l’histoire

de l’application. Les protocoles par journalisation utilisent à la fois la sauvegarde locale
de l’état des processus et la journalisation des événements déterministes pour permettre
la reprise de l’application. Il est alors possible de reprendre l’exécution des processus dé-
faillants (et uniquement des processus défaillants) à partir de leur dernière sauvegarde en
rejouant les événements non déterministes sauvegardés. Pour cela, les protocoles basés sur
la journalisation reposent sur l’hypothèse PWD (PieceWiseDeterministicassumption) [34].
Chaque processus crée un journal des évènements non déterministes qu’il observe pendant
l’exécution normale (sans panne). En cas de panne, le processus défaillant est capable de
reconstruire son état d’avant la panne en partant de son état initial et en rejouant les
évènements non déterministes inscrits dans son journal. L’hypothèse PWD garantit que
cette reconstruction aboutira au même état.
De plus, pour éviter la reconstruction à partir de l’état initial, le processus peut effectuer
des sauvegardes périodiques de son état. Il faut également remarquer que ces informations

37
(le journal et les sauvegardes périodiques) doivent être stockées sur une mémoire stable.
Les protocoles de journalisation doivent assurer la condition de « non orphelinitè » [34]

3.4.2.1 journalisations pessimistes

Le protocole de reprise par journalisation pessimiste [43] repose sur l’hypothèse (pes-
simiste) qu’une défaillance peut se produire immédiatement après un événement non
déterministe. Le principe de ce protocole est donc de ne pas permettre à un processus
de dépendre d’un événement non déterministe tant que celui-ci n’a pas été stocké sur
un support stable. Concrètement, si on considère que les événements non déterministes
sont uniquement les réceptions de messages, ce protocole impose aux processus [44] de
sauvegarder tous les messages reçus avant d’émettre un message à un autre processus. Les
sauvegardes effectuées doivent donc être réalisées de manière synchrone. On trouve cette
technique dans MPI-FT et CHARM [45].
L’avantage de ce protocole est qu’il ne crée jamais de processus orphelin. Cependant, la
sauvegarde synchrone induit un surcout conséquent lors d’une exécution sans panne, en
particulier pour les applications effectuant beaucoup de communications.

3.4.2.2 journalisations optimistes

La journalisation optimiste veut améliorer les performances en faisant l’hypothèse (opti-

miste) qu’une panne ne se produira pas avant la sauvegarde de l’événement non déterministe.
Ainsi, la contrainte est Rel ‘Chée et les sauvegardes peuvent être réalisées de manière asyn-
chrone. Cependant, le désavantage de cette méthode est qu’elle ne garantit pas strictement
la «condition de non-orphelinat ». Ainsi les processus qui n’ont pas encore sauvegardé
leurs événements non déterministes sont des processus orphelins. Pour obtenir un état
global cohérent, ces processus devront revenir en arrière au dernier état ou ils n’étaient pas
orphelins. Il faut remarquer que ce calcul pour obtenir l’état global cohérent à la reprise
peut avoir un cout important [34].

3.4.2.3 journalisations causales

La journalisation causale [46][47] combine les avantages de la journalisation pessimiste

pour la reprise et les avantages de la journalisation optimiste en ce qui concerne le surcout
à l’exécution. L’inconvénient est sa complexité.

38
Le principe est de conserver en mémoire locale les informations permettant de rejouer un
événement non déterministe mais également les informations de précédence (au sens de la
relation de précédence causale de Lamport) avec les autres événements non déterministes
[28].Ces informations (appelées également le déterminant) sont aussi ajoutées à tous les
messages émis vers les autres processus. Ces informations sont retirées de la mémoire locale
des processus une fois qu’elles ont été enregistrées sur un support stable.
Ainsi, à tout moment, un processus connait l’historique des événements qui ont produit
son état et celui des autres processus. Ces informations le protègent des défaillances des
autres processus et permettent de garantir la condition de «non or-phelinitè ». Parmi les
implémentations de journalisation causale nous citions le système MANETHO [48].

3.4.3 Comparaison de différents protocoles de tolérance aux pannes

par reprise

La figure propose une comparaison des avantages et des inconvénients de différentes

techniques de tolérance aux pannes par reprise.

Figure 3.3 – comparaison des différentes méthodes de tolérance aux pannes par reprise

3.5 La tolerance aux pannes dans les cloud

Le Cloud Computing et la Virtualisation ont ouvert une nouvelle fenêtre dans la gestion
des pannes. La mise en pause, la reprise, et la migration des machines virtuelles (VMs)
sont des mécanismes puissants pour gérer les défaillances dans un tel environnement. Une
machine virtuelle peut être facilement migrée vers un autre nœud lorsqu’une panne est
inspectée ou détectée. Bien que la migration soit une bonne solution afin de traiter les

39
pannes, elle a deux problèmes principaux. Premièrement, elle a des surcoûts considérables,
particulièrement si les images de VMs entières doivent être émigrées. Deuxièmement, la
prévision et la détection à l’avance des pannes est un problème majeur. Nous ne pouvons
pas commencer la migration d’une VM si le nœud dont lequel elle s’exécute est défaillant.
Jing Deng et al. [49] Proposent des techniques pour améliorer la tolérance aux pannes et la
fiabilité d’un calcul scientifique assez général : multiplication matricielle. La multiplication
de matrices sert comme une base pour la résolution et l’optimisation de nombreux problèmes
complexes.
Ils étudient une stratégie de sélection de Cloud pour décomposer le problème de multiplica-
tion de matrice en plusieurs taches qui seront soumises à différents Cloud et ils montrent que
la tolérance aux pannes et la fiabilité par rapport à la défaillance dans le Cloud Computing
peuvent être réalisés.Dans les Cloud de stockage, Bonvin et al. [50]
Proposent une Clé-Valeur autogérée (self-managed Key-value) qui alloue dynamiquement les
ressources d’un Cloud de données pour plusieurs applications dans une manière efficace et
équitable. L’approche proposée offre et maintient dynamiquement des garanties différenciées
multiples de disponibilité pour chaque application différente en présence des pannes. Les
auteurs utilisent une économie virtuelle, ou chaque partition de données (c’est à dire une
gamme clé dans un espace cohérent de hachage) agit comme un optimiseur individuel
et choisit s’il faut migrer, répliquer ou de se supprimer, basée sur la maximisation des
bénéfices nets concernant l’utilité offerte par la partition et son stockage et les couts de
maintenance. Zibin Zheng et al.[51] Proposent FTCloud qui est un framwork à base de
classement de composants pour construire des applications de Cloud tolérantes aux pannes.
FTCloud utilise les structures d’invocation de composants et les fréquences d’invocation
pour identifier les éléments importants dans une application de Cloud. Un algorithme est
proposé afin de déterminer automatiquement la stratégie optimale de tolérance aux pannes
pour ces composants significatifs.

3.6 Migration

La migration de processus est le déplacement d’un processus en cours d’exécution d’une

machine source vers une machine destination, ces deux machines étant reliées par un réseau
de communication et n’utilisant pas de mémoire partagée.
La migration de processus d’une machine source vers une machine destination consiste à
interrompre le processus qui s’exécute sur la machine source pour extraire son contexte
d’exécution, à transférer ce contexte vers la machine destination, à créer, sur la machine
destination, un nouveau processus auquel on affectera le contexte d’exécution transfère et à
mettre à jour les liens de communication avec les autres processus. Une fois ceci fait, le
processus sur la machine source doit être détruit tandis que le processus sur la machine

40
destination est lancé et représente le processus déplacé. La Figure 3.3 illustre brièvement le
mécanisme de migration de processus.
Il existe différentes stratégies de migration de processus. Cette différence est due principale-
ment au contexte d’exécution considère et transfère lors de la migration. En effet, le contenu
du contexte d’exécution transfère diffère d’un mécanisme à l’autre ou, plus exactement,
d’un degré de migration à un autre.
Les techniques de virtualisation permettent notamment la migration de machines virtuelles
d’un nœud physique à un autre.
La première approche repose sur une bascule de la ressource de cluster ‘’Machine virtuelle”
d’un nœud à un autre en passant par la fonctionnalité de sauvegarde d’état :
Quick Migration. Ce mode de fonctionnement implique de réaliser un dump de la mémoire

Figure 3.4 – Migration de processus

de la machine virtuelle dans un fichier pour pouvoir arrêter la machine virtuelle (Saved
state), basculer la ressource disque sur un autre nœud du cluster et redémarrer la machine
virtuelle à l’aide du dump. Tout cela implique une interruption de l’activité de la machine
virtuelle. Le temps d’interruption dépend principalement du temps nécessaire à réaliser le
dump de la mémoire sur disque.
L’inconvénient introduit par l’opération de Quick Migration était cependant important
puisqu’il introduisait une perte du service égale à la somme des périodes de temps nécessaires
à l’opération de mise en sommeil, puis au temps de basculement et enfin au temps de réveil
de la machine virtuelle sur le nœud de destination.
Le temps de bascule avec Quick Migration pouvait être compris entre quelques secondes
et plusieurs minutes. Ce temps varie en fonction de la quantité de mémoire RAM de la
machine virtuelle, du débit disponible et aussi de la charge des machines hôtes.
La migration à chaud permet de déplacer une machine virtuelle d’un nœud physique à
un autre sans interruption de service, ce qui rend le processus totalement transparent. La
migration à chaud permet à un administrateur de débrancher une machine virtuelle d’une
infrastructure physique donnée qui nécessite une maintenance sans soumettre les utilisateurs
du système à un temps d’arrêt. Un autre avantage de la migration est qu’elle permet
d’améliorer la tolérance aux fautes. Si une défaillance imminente est suspectée, le problème

41
peut être résolu avant l’interruption du service. La migration à chaud peut également être
utilisée pour l’équilibrage de charge, afin d’optimiser l’utilisation des ressources CPU et
de mieux gérer et économiser l’énergie. Les six étapes ci-dessous détaillent le processus de
migration dans son ensemble [52] :

Etape 1 : Initialisation d’une "live Migration" Un ordre de migration est initié.

Le host source crée une liaison TCP avec le host de destination. Cette connexion est
utilisée pour transférer les données de configuration de la VM à migrer (profile Hard-
ware : processeurs, RAM, etc.). Le profile Hardware permet de construire un squelette
de VM sur l’hôte de destination et d’allouer la mémoire en suffisance à la VM de destination.

Etape 2 : Transfert des pages mémoires Les pages mémoires De la machine

virtuelle source sont copiées par le réseau sur le host de destination par page généralement
de 4ko directement dans la mémoire allouée à la machine virtuelle. Toute modification
ultérieure de la mémoire est consignée. Les pages mémoires modifiées pendant le processus
de copie sont copiées à leur tour par itérations successives. Après que la totalité de la
mémoire utilisée est copiée sur l’hôte de destination, l’étape suivant commence

Etape 3 : Copie dureliquat des pages mémoires La machine virtuelle source est
mise en "pause" (il faut bien arrêter les comptes à un moment donné) afin de permettre une
ultime copie du reliquat des pages mémoires modifiées. Le Host source procède au transfert
des registres processeurs ainsi que l’état des périphériques à la machine de destination. Une
fois cette copie terminée, la machine cible est la parfaite copie de la machine source. La
durée de cette étape dépend de la bande passante disponible et de la quantité de mémoire
restant à copier (dépend de l’activité sur la machine virtuelle)...

Etape 4 : Redirection du Stockage Pendant cette 4ième étape, le contrôle de l’es-

pace de stockage associé à la VM est transfère à l’hôte de destination. L’emplacement qui
contient la machine virtuelle est rendu accessible au host Cible.

Etape 5 : Relance de la machine virtuelle A ce stade, en plus d’avoir un contenu

mémoire identique à celui de l’hôte source, l’hôte destination possède à présent les accès

42
nécessaires aux espaces de stockage utilisés par la machine virtuelle (VM). A ce moment, la
VM démarre sur l’hôte destination. Contrairement à la Quick Migration, une restauration de
l’état du système n’est pas nécessaire, puisque la copie s’est effectuée de mémoire à mémoire.

Etape 6 : Nettoyage du Réseau A ce moment, la VM migrée est déjà exécutée sur

l’hôte destination. Un message est envoyé au Switch physique pour mettre à jour la table
ARP (les paquets à destination de la machine virtuelle ne passent plus par le même port
physique). Bien que les différents Hosts d’un cluster disposent d’un Pool d’adresse MAC
diffèrent, la machine virtuelle conserve son adresse MAC tant que le système d’exploitation
n’est pas redémarré [52].

3.6.1 Live migration, pourqoi ?

Bien que la live migration augmente la flexibilité pour beaucoup d’application, elle peut
s’avérer intéressante lors de cas pratiques de la « vraie vie ».

Maintenance des hôtes physiques La live migration apporte deux bénéfices princi-
paux à la maintenance d’hôte physique. La capacité de migrer une machine virtuelle d’un
hôte physique à un autre sans aucun arrêt, permettant de copier l’ensemble des machines
virtuelles vers un autre serveur, et de les recopier lorsque la maintenance est terminée
sur leur serveur initial, sans que les services effectués par les machines virtuelles ne soient
interrompus.

Data Center Dynamiques Avec la live migration, il est possible de mettre en place
des environnements IT dynamiques. Ces environnements dynamiques rendent plus facile la
gestion des ressources du serveur hôte.
Prenons par exemple le cas de l’utilisation d’un site Web comprenant de nombreux accès
simultanés. Lorsque ces accès augmentent, sa charge continue d’augmenter. Au fur et à me-
sure que la charge varie, les machines virtuelles peuvent être transférées entre les différents
hôtes afin de garder le meilleur ratio d’utilisation possible. Les hôtes non utilisés sont «
parqués » (rendus inactifs), réduisant par la même occasion la consommation électrique et
le refroidissement nécessaire [53].

43
3.7 Conclusion

Dans ce chapitre nous avons présenté un aperçu de la tolérance aux pannes pour les
systèmes distribués et les Cloud Computing. En premier lieu, nous avons abordé d’un point
de vue très général la sureté de fonctionnement et le vocabulaire associé au domaine de la
tolérance aux fautes. Il apparait que la tolérance aux fautes n’est qu’une des approches qui
permettent d’assurer la sureté de fonctionnement.
Les méthodes de tolérance basées sur une mémoire stable semblent plus adaptées. Parmi
les méthodes basées sur une mémoire stable, nous distinguons les approches utilisant la
journalisation des événements non déterministes et les approches réalisant une sauvegarde de
l’état des processus. Notre but dans ce travail est de garantir la tolérance aux pannes dans les
Cloud Computing. Pour cela nous proposons dans le prochain chapitre une architecture de
tolérance aux pannes qui permet de garantir la continuité des services du Cloud Computing
d’une façon transparent et efficace en cas de pannes.

44
Chapitre 4
Description et modélisation De l’approche
proposées

Sommaire
4.1 Partie I : Description . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.1 Objectif du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.2 Description de la premier approche : réplication de données . . . . . 46
4.1.3 Phase D’initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.4 Phase de traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.5 La stratégie de replication de données . . . . . . . . . . . . . . . . . 49
4.1.6 Description de la 2 éme approche : (migration de données) . . . . . 50
4.1.7 Les différentes phases . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.8 Phase de traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Partie II : Conception . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1 Diagramme d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.3 Diagramme d’état . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.4 Diagramme de sequence . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

45
Introduction :

e chapitre présente nos contributions à la tolérant aux fautes Nous allons présenter

C deux approches : la première approche pour gérer la réplication des données dans
les Cloud Computing et la deuxième approche pour gérer la tolérance aux pannes
dans le cloud.
La modélisation est une étape préliminaire pour la description du fonctionnement de toute
approche proposée, elle tient compte les principales caractéristiques et les relations entre
les différents composants. Nous présentons dans ce chapitre les étapes de conception des
deux approches proposées et la modélisation de leurs services.

4.1 Partie I : Description

4.1.1 Objectif du travail

L’objectif de notre travail est de proposer un mécanisme dynamique tolérant aux fautes
des données dans le Cloud Computing. Nous avons proposé deux approches, dans la première
approche, nous avons géré la réplication de données, et cela dans le but d’améliorer les
performances du système en augmentant la disponibilité des donnée et en réduisant le temps
de réponse moyenne des requêtes des utilisateur, ainsi d’augmenter le profit des fournisseur
grâce à l’optimisation des ressource alloué.
Dans la deuxième approche, nous avons utilisé la migration de données. L’avantage de la
migration est qu’elle permet d’améliorer la tolérance aux fautes.

4.1.2 Description de la premier approche : réplication de données

Cette section décrit l’architecture proposée et la mise en oeuvre pour supporter la

tolérant aux fautes dans le Cloud Computing. Dans ce travail nous proposons une stratégie
de réplication de données pour résoudre cette problématique. La démarche principale de
notre proposition de tolérant aux fautes est focalisée sur deux phases : phase d’initialisation
et phase de traitement.

46
4.1.3 Phase D’initialisation

Concernant cette phase d’initialisation, basé sur 3 principales étapes, chaque étape
décrit une partie de notre approche proposée.

1. Étape de configuration : cette étape est caractérisée par la définition des différents
composants du Cloud (les nombres des Datacenter, nombres des VMs), comme c’est
illustré dans la Figure 4.1

Figure 4.1 – Composants du cloud

2. Étape de préparation et de placement des données : cette étape est basée

sur les données elle-même (voir Figure4.2), ceci nécessite la réponse sur la question
suivante :où nous devons placer ces données ? dans quel host ? dans quel Datacenter ?

47
 Figure 4.2 – Placement de données

3. Étape de préparation des requêtes de l’utilisateur : la dernière étape consiste

à définir les différents points sélectionnés par les utilisateurs tel que le budget, et le
de type de la requête qui soit de lecture ou écriture. Comme c’est illustré dans la
Figure 4.3.

Figure 4.3 – Préparation des requêtes de l’utilisateur

4.1.4 Phase de traitement

Cette partie décrit La stratégie de réplication de données que nous avons proposées.
Dans un premier temps nous allons présenter l’algorithme de création de réplique et puis
nous présentons certaines métriques que nous avons utilisées dans notre approche et qui
ont pour but d’établir et d’évaluer le comportement de celle-ci.

48
4.1.5 La stratégie de replication de données

4.1.5.1 Algorithme Création des répliques

L’idée générale est de créer de nouvelles répliques selon une certaine disponibilité exigée
par l’utilisateur. Cette création vérifie certaine condition comme le budget, le coût de
réplication.

Figure 4.4 – Algorithme Création des répliques

1. Calcul du temps de réponse moyenne : requêtes envoyées par l’utilisateur sont

exécutées par les machines virtuelles, ces requêtes ont besoins des données pour
terminer leurs exécutions. Le temps de réponse de chaque requête est estimé par la
formule suivante :
Temps de réponse = T1 + T2 + T3 Où :
T1 : est le temps d’exécution.
T2 : est le temps d’accès.
T3 : est le temps d’attente.

a) Estimer le temps d’exécution d’une requête dans une machine vir-

49
 tuelle, nous utilisons cette formule :

tailledecloudlet
tempsd0 execution = (4.1)
lavitesse
Où la taille de cloudlet représente le nombre d’instruction de la requête Et vitesse,
c’est la vitesse d’exécution de la machine virtuelle donnée par MIPS.
b) Calcul du temps d’attente de la cloudlet : Pour déterminé le temps d’at-
tente moyenne de la requête req, nous devons déterminer en premier temps le
nombre des requêtes qui sont dans la liste d’attentes. Puis nous devons calculer
le temps restant pour libérer les ressources, c’est-à-dire le temps nécessaire pour
terminer les requêtes (temps d’accès à la donnée) qui sont en cours d’exécution.
Il faut aussi déterminer le nombre de répliques de la donnée dans ce Datacenter.
Le temps d’attente moyenne est la somme de ces deux temps ;

c) le temps d’accès : Le temps d’accès est le temps nécessaire pour accéder à la

donnée
2. Calcul SLA : Les exigences de la qualité de service sont extrêmement importantes
pour le Cloud Computing.Elles sont généralement formalisées sous forme de SLA
3. Comparaison temp de réponse et SLA : Si le temps de réponse est inférieur
au SLA c’est à dire la qualité de service est vérifiée avec les ressources actuelles, la
requête peut accéder à la réplique. Par contre si le temps de réponse de la requête
dépasse le SLA, dans ce cas la qualité de service n’est pas assurée avec le nombre
des répliques actuelles.

Budget local = B1 + B2 + B3.....

Cette étape consiste à comparer le budget local avec le coût de création de nouvelle
réplique. si le budget dépasse le coût de création, dans ce cas le fournisseur garantie
une marge de bénéfice. Donc le Datacenter peut créer des nouvelles répliques pour
augmenter la disponibilité des données et de garantir la qualité de service. Dans le cas
où le budget est inférieur au coût de création de nouvelle réplique. Le Datacenter in-
forme les utilisateurs que leur requête ne peut pas être exécutée avec la qualité exigée.

4.1.6 Description de la 2 éme approche : (migration de don-

nées)
Pour faire face aux défaillances des différents composants, nous proposons une straté-
gie de réplication de données permettant l’accès facile aux données. Les composants

50
du système continuent à fournir aux utilisateurs des réponses même si une ou plu-
sieurs entités sont défaillantes. La réplication de données a pour but de proposer
une haute disponibilité qui est exigée par l’utilisateur. Mais la réplication toute
seule n’est pas suffisante pour faire face aux défaillances. Nous avons ajouté la stra-
tégie de migration pour Le but de la migration est d’améliorer la tolérance aux pannes.

4.1.7 Les différentes phases

4.1.7.1 Phase de surveillance

Cette phase correspond à la supervision de l’application. La détection des pannes par

l’approche proposée est réalisée par l’envoi des messages de vie (heartbeat) et watch-
dog. Dans chaque Datacenter, on configure un agent responsable de la surveillance.Un
noeud envoie régulièrement des messages de vie à L’agent surveillant.L’agent sur-
veillant attends les messages de vie de chaque noeud j. Si le message de vie d’un
noeud i n’arrive pas après un certain temps, le noeud i sera déclaré en panne et
ajouter à la liste des noeuds en pannes. La détection des pannes se fait en deux
parties (voir Figure 4.5).
La première partie consiste à envoyer des messages de vie et la deuxième partie
consiste à attendre les messages de vie des noeuds.

Figure 4.5 – Mécanisme de hearbeat et watchdog

4.1.7.2 Phase d’analyse

Dans cette phase, le Datacenter identifie son état après détections des nouvelles
pannes. Nous avons défini trois états pour un Datacenter.

51
 - État normal : le nombre de noeuds en pannes est inférieur au seuil T min
- État suspect : le nombre de noeuds en pannes entre T min et T max
- État critique : quand le nombre de noeuds en pannes dépasse T max
Deux paramètres système sont utilisés : les seuils de panne T min et T max, ces
paramètres fixent la marge de chacun des trois états comme le montre la Figure 4.6

Figure 4.6 – Transitions d’états de la charge d’un Datacenter

52
 Figure 4.7 – Algorithme de changement d’état

4.1.8 Phase de traitement

Pour augmenter la tolérance au panne et pour réduire la probabilité d’échec d’exécu-
tion d’une requête, nous avons proposé l’algorithme suivant qui permet de sélectionner
les VMs qui vont exécuter les requêtes des utilisateurs selon l’état du Datacenter qui
héberge ces VMs.Le Broker sélectionne une VM, puis il identifie le Datacenter qui
héberge cette VM. Ensuite le Broker va vérifier l’état du Datacenter sélectionné, Si
son état est normal, le Broker peut envoyer les nouvelles requêtes pour être exécutées.
Par contre si son état est suspect, alors le Broker va demander au Datacenter s’il a
les données demandées par ces requêtes, si la réponse est oui alors le Broker peut
envoyer les requêtes à ce Datacenter ; Dans le cas où les données n’existent pas, alors
le broker pour ne pas aggraver l’état du Datacenter du à des nouveaux changements.
Il évite de lancer le processus de création des nouvelles répliques dans ce Datacenter.
Donc les requêtes ne peuvent pas être envoyé à ce Datacenter, il doit les envoyer
vers d’autres Datacenter qui ont un état normal. Dans le troisième cas où l’état du
Datacenter est critique, le Broker envoi ces requêtes vers d’autres Datacenter et en
même temps lance le processus de migration.

53
 Figure 4.8 – Algorithme traitement de requête

4.2 Partie II : Conception

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 concepts orienté
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é.
Dans ce chapitre, nous présentons la conception des différents éléments du système.
Nous utilisons pour cela :
- Diagramme de cas d’utilisation
- Diagramme de séquence
- Diagramme d’activité
- Diagramme de classe
* Pacestar UML Diagramme comme outil pour établir les diagramme UML

54
4.2.1 Diagramme d’utilisation
Nous présentons maintenant une vue globale de notre simulateur qui permet de
détailler les différentes étapes effectuées pour réaliser une simulation. La Figure 4.9
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 d’interactions
avec le système. Les cas d’utilisation décrivent les fonctions du système selon le point
de vue des utilisateurs. Le cas d’utilisation spécifie une séquence d’actions tel que la
configuration de la Cloud et afficher le résultat.

Un acteur :est une entité externe au système, dans notre cas c’est l’utilisateur
(user) qui joue un rôle importants, On a un type d’acteur .

User : l’acteur qui configure le Cloud et lance la simulation.

DC : Datacenter.

Figure 4.9 – Diagramme d’utilisation du simulateur

55
 4.2.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 CloudSim est composé de plusieurs
classes que nous pouvons classer en deux catégories : les classes que nous avons
modifiées sont montrées en bleu dans la Figure 4.10 comme la classe Datacenter,
Datacenter Broker, . . . et les classes que nous avons ajoutées sont présentées en
rouge dans la même Figure.

Figure 4.10 – Diagramme de classe de la conception de simulateur CloudSim

56
4.2.3 Diagramme d’état
* Diagramme d’état de la stratégie proposée

Figure 4.11 – Diagramme d’état de la stratégie proposée

57
* Diagramme d’état création des répliques :L’idée générale est de créer de
nouvelles répliques cette création vérifie certaine condition comme le budget, le
coût de réplique et garantit d’ajouter des répliques

Figure 4.12 – Diagramme d’état de création des répliques

58
4.2.4 Diagramme de sequence

Figure 4.13 – diagramme de sequence « état normal »

Le diagramme de séquence est l’un des vues dynamiques les plus importantes
d’UML.Nous allons présenter les diagrammes de séquence de l’approche basée sur la
migration de données.
Le diagramme illustré dans la figure 4.13 représente le flux de communication entre
les principaux acteurs de CloudSim. La présence d’une panne, le Datacenter met à
jour son état, si l’état d’un Datacenter est en état normale, le Broker peut envoyer
des requêtes à ce Datacenter pour être exécuté.

59
 Figure 4.14 – diagramme de sequence « état suspect »

Si une ou plusieurs pannes sont détectées et que ces pannes modifient l’état du
Datacenter en état Suspect, alors le Broker peut envoyer des requêtes à ce Datacenter
à condition qu’il hébergé les données demandées par ces requêtes.

60
 Figure 4.15 – diagramme de sequence « état suspect »

Si le Datacenter sélectionné pour traiter la requête est en état suspect, et après

vérification des données demandées par cette requête, le Datacenter informe le broker
que les données demandées n’existent pas. Alors le Broker choisi un autre Datacenter
en état normal pour exécuter cette requête

61
 Figure 4.16 – diagramme de sequence « état critique »

Si l’état d’un Datacenter est en état critique, le Broker n’envoi aucune nouvelle
requête à ce Datacenter et lance le processus de migration.

62
4.3 Conclusion
Dans ce chapitre, nous avons présenté la description et la conception des deux
approches proposées ; la première approche est basée sur la réplication pour faire
face aux panne, la réplication permet aussi d’augmenter la disponibilité ; la deuxième
approche est une combinaison de la réplication et de la migration des données ; le
but d’utiliser la migration est d’augmenter la tolérance aux panne et de réduire les
échecs d’exécution dû aux panne.
Dans ce chapitre nous somme se concentrer sur la démarche description et conception
des approches proposées. Nous avons présenté les différents algorithmes proposés
pour décrire le fonctionnement de nos deux approches. Ainsi quelques diagrammes
qui ont été formalisées à l’aide du langage UML pour décrire les différentes étapes
de conception.
Le prochain chapitre sera consacré à la partie d’implémentation et évaluation de nos
propositions de tolérance aux pannes. Nous mettrons en évidence l’importance et
l’efficacité des approches proposées.

63
Chapitre 5
Implémentation

Sommaire
5.1 Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 Langage de programmation Java : . . . . . . . . . . . . . . 66
5.2.1 Avantages de la java . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.2 Environnements de développement : . . . . . . . . . . . . . . 67
5.2.3 Architecture de CloudSim . . . . . . . . . . . . . . . . . . . . 67
5.3 Interface principale . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.1 Configuration du DataCenter . . . . . . . . . . . . . . . . . . 68
5.3.2 Configuration des données . . . . . . . . . . . . . . . . . . . . 70
5.3.3 Configuration des machines virtuelles . . . . . . . . . . . . . 70
5.3.4 Configuration des Cloudlet . . . . . . . . . . . . . . . . . . . 71
5.3.5 Configuration de mécanisme de tolérance aux pannes . . . . . 72
5.3.6 Lancement de la simulation . . . . . . . . . . . . . . . . . . . 72
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

65
 5.1 Introduction :
e Chapitre est consacré à la réalisation et la concrétisation de nos approches

C proposées, qui consiste à répliquer les données et tolérer les pannes dans
les environnements de Cloud Computing.
Dans un premier temps, nous présentons l’environnement de notre travail, puis nous
définissons les différents services de simulateur CloudSim, ensuite nous décrivons
quelques interfaces graphiques, et finalement nous présentons une série de simulations
et leurs interprétations pour mettre en évidence nos propositions.

5.2 Langage de programmation Java :

Nous nous sommes orientés sur le langage JAVA qui présentait néanmoins
beaucoup d’avantages. Ce langage est apparu vers la fin de 1995 et obtient
rapidement un énorme succès. Il s’agit d’un langage de conception très
performant qui a été adopté par la majorité des fournisseurs. Ses caractéristiques
intégrées de sécurité offrent un sentiment de confiance aux programmeurs comme
aux utilisateurs des applications. De plus, Java incorpore des fonctionnalités qui
facilitent grandement certaines tâches de programmation avancées comme la gestion
des réseaux, la connectivité des bases de données ou le développement d’applications
multitâches, etc.

5.2.1 Avantages de la java

L’un des avantages évidents de ce langage est une bibliothèque d’exécution
qui se veut indépendante de la plateforme : en théorie, il vous est possible
d’utiliser le même code pour Windows 95/98/NT, Solaris UNIX, Macin-
tosh, etc. Cette propriété est indispensable pour une programmation sur Internet,
cependant, par rapport à la disponibilité sur Windows et Solaris, les implémentations
sur d’autres plates-formes ont toujours un léger décalage.
Un autre avantage de ce langage de programmation réside dans le fait que la syntaxe
de Java est analogue à celle de C++ ce qui le rend économique et professionnel. Le
fait de créer une autre version d’un langage C++ n’est cependant pas suffisant. Le
point clé est le suivant : il est beaucoup plus facile d’obtenir du code sans erreur à
l’aide de Java qu’avec C++. Pourquoi ? Les concepteurs de Java ont beaucoup réfléchi
à la raison pour laquelle le code C++ contenait autant d’erreurs. Cette réflexion les
a amené à ajouter dans Java des fonctions destinées à éliminer la possibilité de créer
du code contenant les types d’erreurs les plus courants (selon certaines estimations,

66
le code C++ contient au moins une erreur toutes les cinquante lignes)

5.2.2 Environnements de développement :

Eclipse est un environnement de développement intégré, libre, extensible,
universel et polyvalent, permettant de créer des projets de développement
mettant en œuvre n’importe quel langage de programmation. Eclipse IDE
est principalement Ecrit en Java (à l’aide de la bibliothèque graphique SWT, d’IBM),
grâce à des bibliothèques septiques, ce langage est Egalement utilisé pour Ecrire des
extensions.
La spéciosité d’éclipse 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
Lotus Notes 8, IBM Symphonie ou WebSphere Studio Application Développer, etc.
CloudSim Objectif principal de simulateur CloudSim est de fournir un cadre de
Simulation généralisé et extensible qui permet la modélisation, la simulation et
l’expérimentation des nouvelles infrastructures du Cloud Computing et les services
d’application, permettant aux utilisateurs de se concentrer sur des questions de
conception du système qu’ils veulent Etudier, sans être préoccupé aux détails relatifs
au service set infrastructures Cloud.
Nous avons utilisé pour la réalisation de notre travail la version du simulateur
CloudSim 3.0.3.

5.2.3 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 5.1. La première
version de CloudSimutiliseSim Java, un moteur de simulation d’évènement
discret qui meten œuvre les principales fonctionnalités requises pour des structures
de simulation de haut niveau comme la formation d’une file 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 entreles 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.

67
 Figure 5.1 – Architecture de CloudSim

5.3 Interface principale

Au lancement de notre application l’interface qui s’ache est montré dans la
Figure 5.2 cette interface contient bouton pour lancer la configuration

Figure 5.2 – Interface principale

5.3.1 Configuration du DataCenter

En démarrant le simulateur CloudSim, une fenêtre apparait en premier
(figure 5.3) ; dans cette fenêtre l’utilisateur peut faire la configuration de
l’environnement du Cloud et les paramètres de simulation. Elle contient 5
parties principales :

68
 DataCenter, Données, Virtuel Machine, Cloudlet, Fault Tolérant
Cette étape consiste à faire entrer les paramètres nécessaires Pour configurer
la topologie du Cloud (Figure 5.3) comme : le nombre de Data Center,
d’hôtes, de CPU, la vitesse de chaque CPU, le coût de Réplique, la taille de la
mémoire, le coût de la mémoire, la taille du disque dur, le coût de stockage et la
bande passante ainsi que son coût.

Figure 5.3 – Configuration du DataCenter

FIGURE 5.4 : Pour créer des nouveau Datacenter, on click sur le bouton
ADD, les Datacenter crées s’affiche dans la liste Datacenter List. Pour
ajouter des Host à un Datacenter. On doit sélectionner le Datacenter en
premier puis on click sur Add Host. Une fenêtre apparait pour configurer l’hôte.

Figure 5.4 – Fenêtre de Host

69
 5.3.2 Configuration des données
La Figure 5.5 représente l’étape de création des données. Pour ajouter une
donnée, on doit configurer les paramètres suivants : le nom de la donnée, sa
taille, le Datacenter qui héberge cette donnée et l’id de l’hôte où se trouve
cette donnée.

Figure 5.5 – Configuration des données

5.3.3 Configuration des machines virtuelles

L’onglet Virtual Machine permet de configurer les machines virtuelles (Fi-
gure5.6) 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.

Figure 5.6 – Configuration des machines virtuelles

70
5.3.4 Configuration des Cloudlet
La figure 5.7 représente l’onglet qui permet de configurer les propriétés de
la Cloudlets, parmi ces propriétés on trouve :

The cloudletlength : la taille de la Cloudlet à exécuter dans un Cloud

Resource.

The cloudlet file size : la taille du fichier d’entrée de la Cloudlet avant

l’exécution (la taille du programme + les données en entrée).

Figure 5.7 – Configuration des Cloudlet

71
 5.3.5 Configuration de mécanisme de tolérance aux
pannes
L’onglet Fault Tolérant permet à l’utilisateur d’injecter les pannes et de
sélectionner le mécanisme de tolérance aux pannes. Si l’utilisateur choisi
l’option

Réplication, alors le système gère la création des répliques seulement

selon la stratégie que nous avons proposée. Si l’option migration est choisi,
alors le système utilise les deux approches, réplication et migration.

Figure 5.8 – Configuration de mécanisme de tolérance aux pannes

5.3.6 Lancement de la simulation

Après avoir personnaliser les paramètres de simulation, l’utilisateur peut
lancer la simulation en cliquant sur le bouton Start Simulation ou bien à
partir du menu Simulation en choisissant l’item qui correspond à son choix
(voir Figure5.9).
Après la création du Cloud et le lancement de la simulation, l’utilisateur peut
visualiser les résultats et l’état de traitement de Cloudlets. Les résultats obtenus
après la simulation, ils sont accessibles en cliquant sur le bouton Result

Figure 5.9 – Interfece de Lancement de la simulation et de la visualisation des résultats

72
 5.4 Conclusion
Dans ce chapitre, nous avons présenté l’implémentation de notre application
ainsi que les résultats obtenus. Nous avons réalisé plusieurs simulations en
jouant sur différents paramètres comme : le nombre de cloudlets, le nombre
de pannes.

73
 Conclusion Générale

e Cloud computing est en pleine expansion et tend à s’imposer comme des

L paradigmes dominants dans l’univers informatique. Les infrastructures pro-

posant des services de Cloud computing deviennent donc de plus en plus
nombreuses, et de plus en plus complexes pour répondre à cette demande croissante
de services décentralisés. Aujourd’hui on n’a pas un problème de stockage mais on a
un problème de gestion et de récupération de l’information avec le minimum temps.
Il faut donc concevoir des techniques et outils afin de répondre à ces nouveaux
besoins de gestion.
Dans un tel contexte, la sûreté de fonctionnement des applications est un élément
de première importance, le taux de pannes dans des tels systèmes croit avec la
taille du système lui-même, c’est pourquoi un mécanisme de tolérance aux pannes
devient nécessaire pour en assurer certains aspects. Les pannes sont inévitables ; une
application échouera, quel que soit son environnement.
En plus quand un système informatique devient plus complexe, la sensibilité du
Système aux défaillances augmente. Au cours de ce mémoire, nous avons développé
une architecture de tolérance aux fautes dans les Cloud Computing. Nous avons pro-
posé deux approches, la première approche se base essentiellement sur le mécanisme
de réplication de données. La réplication est une technique est une technique qui
permet de régler en général certains problèmes dans le Cloud tels que les problèmes
de la disponibilité des données à chaque instant.
La stratégie proposée consiste à répliquer les données dans les nœuds selon une
disponibilité exigée par l’utilisateur dont le but d’améliorer la disponibilité et réduire
le temps de réponse selon certains critères.
La deuxième approche de migration qui permet de garantir la continuité des services
du Cloud Computing d’une faon transparent et efficace en cas des pannes. Montrent
que les deux approches proposées présentent de bonnes performances, elles induisent
en particulier un surcot faible sur le temps d’exécution et elles minimisent le temps
perdu causé par des pannes.

75
 Résumé — Le cloud computing ou informatique dans les nuages pour-
rait bien révolutionner l’informatique des entreprises.Ce concept,apparu
récemment et qui permet désormais d’externaliser l’utilisation de la mémoire
ainsi que les capacités de calcul d’ordinateurs et de serveurs répartis dans le monde
entier,permet en et aux entreprises de disposer d’une formidable puissance informa-
tique s’adaptant de surcroît ‘a la demande. Mais si le cloud computing présente de
nombreux avantages,comme toute nouvelle avancée technologique,celle-ci comporte
également un certain nombre de risques dont il convient de se prémunir dans le
cadre d’un contrat adapté. C’est pourquoi au cours de ce travail,nous nous sommes
intéressés à tolérant aux fautes Des données dans le Cloud Computing,ou nous avons
présenté deux s’approche "réplication et Migration".

Abstract — Cloud computing or cloud computing ? could well revolutio-

nize business computing. This recently developed concept, which now allows
for the outsourcing of memory usage and the computing capabilities of computers
and servers around the world, enables enterprises to have tremendous computing
power ’Adapting to the demand. But if cloud computing has many advantages, like
any new technological breakthrough, it also involves a number of risks that need to
be protected by a suitable contract.This is why during this work we were interested
in fault tolerant data in the Cloud Computing, where we presented two approaches
"Replication and Migration".