Architectures intergicielles pour la tolérance aux fautes et le consensus

HAL Id: pastel-00004308

https://pastel.archives-ouvertes.fr/pastel-00004308

Submitted on 9 Jan 2009

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

Architectures intergicielles pour la tolérance aux fautes

et le consensus

Khaled Barbaria

To cite this version:

Khaled Barbaria.

Architectures intergicielles pour la tolérance aux fautes et le consensus.

do-main_other. Télécom ParisTech, 2008. English. �pastel-00004308�

´

Ecole doctorale d’Informatique, T´

el´

ecommunications et ´

Electronique de Paris

Architectures intergicielles pour la

tol´

erance aux fautes et le consensus

Th`

ese

pr´esent´ee et soutenue publiquement le 15 septembre 2008

pour l’obtention du grade de

Docteur de l’´

Ecole Nationale Sup´

erieure des T´

el´

ecommunications

sp´

ecialit´

e : informatique et r´

eseaux

par

Khaled Barbaria

Composition du jury

Pr´

esident :

Elie Najm, Professeur `

a l’´

Ecole Nationale Sup´erieure des T´el´ecommunications

Rapporteurs :

Yvon Kermarrec, Professeur `

a l’´

Ecole Nationale Sup´erieure

des T´el´ecommunications de Bretagne

Lionel Seinturier, Professeur `

a l’Universit´e des Sciences et Technologies de Lille

Examinateurs :

Olivier Marin, Maˆıtre de conf´erences `a l’Universit´e Pierre et Marie Curie (Paris VI)

Frank Singhoff, Maˆıtre de conf´erences `a L’universit´e de Bretagne Occidentale

Directeur de th`

ese :

Laurent Pautet, Professeur `

a l’´

Ecole Nationale Sup´erieure

des T´el´ecommunications

À l'âmede mon père À toutema famille

Tout d'abord, jerends grâ e àdieupour m'avoir permisd'arriver au bout de e travail. Je tiens à remer ier tous les membres de ma famille pour m'avoir supporté et aidé tout au longdes années de ette thèse. Mer i à ma mère Alia, mafemme Ines, ma grand mère Habiba (Bellia),masoeur Wiemet monfrèreSami.Mer i àmes on leset tantes: AbelAziz,Mondher, MohamedSalah(Hammadi), Chokri,Salwa,Basma, Sonia, Boutheina, Beya,Jamila, Assia.

Un grand mer ià ToukDenDalipour sesnombreux et pré ieux onseils.

Mer i àLaurent Pautet pour avoir en adré ette thèse. Sonexperien eet ses onseils m'ont beau oupaidé.

Mer i aux diérents enseignants her heurs qui m'ont honoré en faisant partie du Jury de ettethèse.Mer iàYvonKermarre etàLionel Seinturierpour avoira eptéd'être rapporteurs de e travail.Mer i à Olivier Marin et à Frank Singho pour avoir a epté d'être exminateurs de ette thèse.Mer i àElie Najmpour avoir a epté d'être président de monjuryde thèse.

Je tiens à remer ier les diérents ollègues de l'ENST ave qui j'ai partagé une expérien e enri hissante tant sur le plan s ientique et te hnique que sur le plan humain : Raja Chiky, AhmedFadhlallah,BilelGuenni,IrfanHamid,JéromeHugues,ZakiaKazi-Aoul,IsabellePerseil, ThomasVergnaudet Be hirZalila.

Je n'oublie pas les les joyeux moments que j'ai pu partager ave plusieurs amis. Mer i à Akram Aidani, Houssemeddine Bedoui, Mohamed Habib Ben Abid, Taha Dridi, Walid Dridi, Haythem Gada ha, MohamedChedly Ghediraet Mohamed Khelij.

Le su ès des intergi iels dans le adre du développement de systèmes d'information géné-ralistes ommeles appli ationsWeb, en ourageleur utilisation pour ledéveloppement d'autres appli ationsplusspé iques, omme lesappli ations temps réelou même ertaines appli ations ritiques.

Cesappli ationsprésententdes ontraintesetdesexigen esenqualitédeservi egénéralement di ilesàsatisfaire.Par onséquent,ellesprésentent degranddésàreleverparleste hnologies intergi iellesqui doivent satisfaire simultanément à plusieurs exigen eset ontraintes.

Nous partons d'une ar hite ture intergi ielle dite s hizophrène ayant des propriétés de gé-néri ité et de onguration. Cettear hite ture est renfor ée pour supporter deux atégories de servi es pour latoléran e auxfautes et le onsensus. La onservation des propriétés de l'ar hi-te ture debase ainsiquele respe tdes ontraintes posées par les appli ations ritiqueset sûres defon tionnement sont les prin ipauxobje tifs denospropositions.

Les prin ipes et les propriétés de l'ar hite ture s hizophrène sont détaillés. Ensuite, nous menons des études approfondies de la théorie de la toléran e aux fautes et du onsensus ainsi quede lanorme FT CORBA.Ces études nouspermettent de généraliser lesdiérents on epts et d'isolerles diérentes abstra tions utiles an de proposer deuxar hite tures pour unservi e de toléran e auxfautes ompatible ave la norme FT CORBA et pour un servi egénérique de onsensus.Nous montrons quela on eptionde esservi es maximise leur ongurabilité.

Après les propositions d'ar hite tures, nous dé rivons la réalisation ee tive de es deux servi es. Nous nousbasons sur PolyORB, un integri iel développé à l'ENST servant à l'expéri-mentationdespropositionsautourdel'ar hite ture des hizophrène.Dess énariosde testetdes mesuresde performan es omplètent notre étudeet valident nosdiérentespropositions. Mots- lés: Ada,Consensus, Intergi iels, Temps réel,Toléran e auxfautes

Middlewarete hnologieshavebeenwidelyadoptedtodesignanddevelopgeneral purpose distributedappli ations. Thee ien y of these te hnologiesen ourages tostudy their ompati-bilitywiththestringent requirementsofsomedomain-spe i realtime and riti alappli ations. Theserequirementsarehardtoa hieveandmaybein ompatiblewith theobje tivesof reusabil-ityand ost redu tion.

We enhan e a middleware ar hite ture said s hizophreni , that enables for generi ity and extreme reusabilitywith servi esfor onsensusandfaulttoleran e. The integrationof these ser-vi esfollowstwoprin iples.Ononehand,we onserve thepropertiesoftheoriginalar hite ture. Ontheotherhand,we aptureandrespe tthe the onstraintsandrequirementsthat omewith riti aland dependableappli ations.

First,the prin iplesand properties of the s hizophreni ar hite ture aredetailed. Then, the theory of fault toleran e and of onsensus as well as the FT CORBA standard are presented. These theoreti al studies allowed us to isolate the useful abstra tions and on epts to design servi esforfaulttoleran eand onsensus.Finally,wepresenttherealisationoftheseservi es.Our proposalisbasedonPolyORBamiddlewaredevelopedatENST.Tests enariosandperforman e measures omplete our studyand validateour propositions.

Introdu tion 1

1 Positiondu problème . . . 1

2 Obje tifset démar he . . . 2

3 Plan . . . 3

Partie I État de l'art 5 1 Cadre général, notions de base et problématique 7 1.1 Cadre général. . . 8

1.2 Intergi iels . . . 9

1.2.1 Dénition et généralités . . . 9

1.2.2 Ar hite ture de l'intergi iel . . . 10

1.2.3 Apports desintergi iels . . . 10

1.3 Toléran eauxfautes . . . 11

1.3.1 Dénitions etnotions de base. . . 11

1.3.2 Besoins en toléran eaux fautes. . . 13

1.3.2.1 Attributs delatoléran e auxfautes . . . 13

1.3.2.2 Domaines d'appli ations . . . 14

1.3.3 Prin ipes delatoléran e auxfautes . . . 15

1.3.3.1 Redondan e : basede latoléran eauxfautes . . . 15

1.3.3.2 Répli ation . . . 16 1.3.4 Con lusion . . . 18 1.4 Consensus . . . 18 1.4.1 Dénition . . . 18 1.4.2 Besoins . . . 19 1.4.2.1 Utilisationexpli ite . . . 19 1.4.2.2 Utilisationimpli ite . . . 19

1.4.3 Résultats théoriques . . . 20

1.4.3.1 Modèles de défaillan es . . . 20

1.4.3.2 Modèles de al ul et Syn hronisme . . . 21

1.4.3.3 Problèmedu onsensusdansles systèmesasyn hrones . . . . 22

1.4.3.4 Déte tiondes défaillan esdansles systèmesasyn hrones . . 22

1.4.4 Con lusion . . . 23

1.5 Produ tion d'appli ations ritiquesdistribuées . . . 23

1.5.1 Ar hite ture . . . 24

1.5.2 Utilisationdeslangagesde programmation dehaut niveau . . . 25

1.5.3 Validation . . . 26

1.5.4 Con lusion . . . 27

1.6 Obje tifset axes de re her he . . . 28

1.6.1 Obje tifs . . . 28

1.6.2 Propositions et ontributions . . . 29

2 Intergi iels, toléran e aux fautes et onsensus 31 2.1 Introdu tion . . . 31

2.2 Intergi iels . . . 32

2.2.1 Modèles de distribution . . . 32

2.2.1.1 Intergi iels orientés messages . . . 32

2.2.1.2 Appels de pro édures distants . . . 33

2.2.1.3 Objetsdistribués . . . 34

2.2.1.4 Con lusion . . . 36

2.2.2 Propriétés desintergi iels . . . 37

2.2.2.1 Adaptation et rédu tion des oûts . . . 37

2.2.2.2 Propriétés Comportementales . . . 39

2.2.3 Synthèse . . . 41

2.3 Toléran eaux fautesdansles systèmesdistribués . . . 41

2.3.1 Ar hite tures et intergi iels tolérants auxfautes . . . 41

2.3.1.1 Intergi iels propriétaires . . . 42

2.3.1.2 Ar hite tures génériques . . . 43

2.3.1.3 Intergi iels standards . . . 45

2.3.1.4 Synthèse . . . 46

2.3.2 Toléran e auxfauteset répli ation dansCORBA . . . 47

2.3.2.1 Ar hite tures . . . 47

2.3.2.2 Comportement temporel . . . 48

2.4 Supportde l'abstra tion du onsensus par lesintergi iels . . . 50

2.4.1 Consensus, déte tionde défaillan es: de lathéorieà lapratique . . . 51

2.4.1.1 Consensus . . . 51

2.4.1.2 Déte tion de défaillan es . . . 52

2.4.1.3 Con lusion . . . 53

2.4.2 Patrons et ar hite tures pourle onsensus. . . 53

2.4.2.1 MAFTIA . . . 53 2.4.2.2 Thema . . . 53 2.4.2.3 Bast . . . 54 2.4.2.4 OGS . . . 54 2.4.2.5 CORE/SONiC . . . 54 2.4.2.6 Aspe tIX. . . 55 2.4.3 Con lusion . . . 55 2.5 Synthèse . . . 56 2.5.1 Te hnologies intergi ielles . . . 56

2.5.2 Toléran eauxfautes . . . 56

2.5.3 Consensus . . . 56

Partie II Con eption 57 3 Con eption et intégration d'un servi e de toléran e aux fautes dans une ar hite ture s hizophrène 59 3.1 Introdu tion . . . 59

3.2 Ar hite ture s hizophrène . . . 60

3.2.1 Dénitions, obje tifset prin ipes . . . 60

3.2.2 Personnalités appli ativeset proto olaires . . . 61

3.2.2.1 Personnalités appli atives. . . 61

3.2.2.2 Personnalités proto olaires . . . 61

3.2.3 Cou he neutreet servi es anoniques dedistribution . . . 62

3.2.4 Avantages de l'ar hite ture . . . 64

3.2.4.1 Généri ité . . . 64

3.2.4.2 Congurabilité desservi es . . . 64

3.2.4.3 Servi esfondamentaux . . . 65

3.2.4.4 Véri ation omportementale . . . 65

3.3 Con eption et intégration d'un servi e de toléran e aux fautes dans

l'ar hi-te ture s hizophrène . . . 66

3.3.1 Problématique . . . 66

3.3.1.1 Ar hite ture deFT CORBA . . . 66

3.3.1.2 Besoinsvisà visdel'intergi iel . . . 68

3.3.1.3 Con lusion . . . 69

3.3.2 Mé anismesd'inter eption dansCORBA . . . 70

3.3.3 Miseen oeuvrede larépli ation àl'aide desinter epteurs . . . 72

3.3.3.1 Ar hite ture . . . 72

3.3.3.2 Inter epteurs oté lient . . . 73

3.3.3.3 Inter epteurs oté serveur . . . 73

3.3.3.4 Respe tdesprin ipesde l'ar hite ture s hizophrène . . . 74

3.3.3.5 Con lusion . . . 75

3.3.4 Déte tion et noti ation desdéfaillan es. . . 75

3.3.4.1 Déte tiondes défaillan es. . . 76

3.3.4.2 Noti ation desdéfaillan es . . . 77

3.3.4.3 Con lusion . . . 77

3.3.5 Avantagesde l'ar hite ture . . . 78

3.3.5.1 Indépendan e despersonnalités proto olaires . . . 78

3.3.5.2 Supportde lavéri ation formelle . . . 78

3.3.5.3 Congurabilité dela toléran eauxfautes . . . 79

3.4 Con lusion . . . 79

4 Ar hite ture d'unservi e générique de onsensus 81 4.1 Con eption d'un servi egénérique de onsensus. . . 82

4.1.1 Ar hite ture générale . . . 82

4.1.1.1 Choixdesmodèles de al ul et de défaillan es . . . 83

4.1.1.2 Ar hite ture générale . . . 83

4.1.1.3 Servi esintergi iels de base. . . 84

4.1.1.4 Con lusion . . . 85

4.1.2 Servi edu onsensus. . . 86

4.1.2.1 Patrons de on eptionPont et Stratégie . . . 86

4.1.2.2 Consensus . . . 88

4.1.2.3 Déte tiondes défaillan es. . . 89

4.1.2.4 É hanges desmessages . . . 90

4.1.2.5 Con lusion . . . 91

4.1.3.2 Ar hite tures orientées évènements . . . 94

4.1.3.3 Appli ation de l'ar hite ture orientée évènements . . . 96

4.1.3.4 Con lusion . . . 98

4.2 Intégrationdansl'ar hite tures hizophrène et asd'appli ations . . . 98

4.2.1 Groupe de parti ipants . . . 98

4.2.2 Intégration dansl'ar hite tures hizophrène . . . 100

4.2.2.1 Partitions et groupesde parti ipants . . . 101

4.2.2.2 É hangesdesmessages . . . 101

4.2.3 Conguration de l'intergi iel . . . 102

4.2.4 Appli ation à lapersonnalitéCORBA . . . 104

4.3 Con lusion . . . 105

Partie III Réalisation et expérimentation 107 5 Composants et servi es pourla toléran e aux fautes et le onsensus 109 5.1 Introdu tion . . . 109

5.2 Ada et PolyORB . . . 110

5.2.1 Le langage Ada . . . 110

5.2.2 Ar hite ture de PolyORB . . . 112

5.2.2.1 Présentation de PolyORB . . . 112

5.2.2.2 Vue globale del'ar hite ture . . . 112

5.2.2.3 Mise enoeuvre dela ou he neutre . . . 112

5.2.2.4 Servi esutilitaires . . . 113

5.3 Réalisation d'un servi edetoléran e auxfautes . . . 114

5.3.1 Impa t surl'ar hite ture de PolyORB. . . 114

5.3.2 Gestion desgroupes d'objets . . . 115

5.3.3 Fon tionnalités avan ées de GIOP . . . 117

5.3.4 Gestion de larépli ationet déte tiondesdéfaillan es . . . 119

5.3.4.1 Repli ationManager . . . 119

5.3.4.2 Déte tion et noti ation desdéfaillan es . . . 119

5.3.5 Stylesde répli ation . . . 121

5.3.5.1 Dénition desinter epteurs. . . 121

5.3.5.2 Mise enoeuvre desstylesde répli ation . . . 123

5.3.6 Constru tion d'appli ations basées surFT CORBA . . . 124

5.3.6.1 Conguration desservi es dansPolyORB . . . 124

5.3.6.3 Limiteset perspe tives . . . 126

5.3.7 Con lusion . . . 126

5.4 Réalisationd'un servi egénérique de onsensus . . . 127

5.4.1 Composantsdu servi edu onsensus . . . 127

5.4.1.1 Proje tion surAda. . . 127

5.4.1.2 Composantsde onsensuset de déte tionde défaillan es . . 129

5.4.1.3 Gestiondes messages . . . 130

5.4.2 Gestion desévènements . . . 132

5.4.2.1 Produ tion . . . 132

5.4.2.2 Consommation. . . 133

5.4.2.3 Con lusion . . . 133

5.4.3 Constru tion d'appli ations baséessur le onsensus . . . 133

5.4.3.1 Transport dedonnées . . . 134

5.4.3.2 Congurationslo ale et globale d'unepartition . . . 134

5.4.3.3 Assemblagedu servi edu onsensus . . . 136

5.4.3.4 Exemple1 : Appli ation embarquée . . . 136

5.4.3.5 Exemple2 : Intégration dansl'ar hite ture s hizophrène . . 136

5.4.4 Con lusion . . . 138

5.5 Con lusion . . . 139

6 Validation et mesures 141 6.1 Introdu tion . . . 141

6.2 Évaluation dela miseenoeuvre deFT CORBA . . . 142

6.2.1 Gestion desgroupesde répliques . . . 142

6.2.1.1 Gestiondes référen essurles groupesd'objets . . . 142

6.2.1.2 Miseen oeuvre desstylesderépli ation de FT CORBA . . . . 143

6.2.2 Comportement temporel desstyles derépli ation . . . 143

6.2.2.1 Distribution deslaten es . . . 144

6.2.2.2 Leslaten esen fon tion dudegré derépli ation . . . 145

6.2.3 Déte tion et noti ation desdéfaillan es. . . 146

6.2.4 Con lusion . . . 148

6.3 Évaluation duservi egénérique de onsensus . . . 149

6.3.1 Analysedu odesour e . . . 149

6.3.2 Mesuresde performan es . . . 149

6.3.2.1 Conguration debase . . . 150

6.3.2.2 Compatibilité ave l'ar hite ture s hizophrène . . . 152

6.4 Con lusion . . . 156 7 Con lusions et perspe tives 157 7.1 Contributions . . . 157 7.2 Perspe tives . . . 160

Table des gures 163

Liste des tableaux 165

Leste hniques de toléran e auxfautes permettent de onstruire dessystèmes robustes pou-vant ontinuer à fon tionner malgréla possible o urren ed'inattendus. En général,même s'ils sont primordiaux pour le produit nal, les besoins en toléran e aux fautes sont orthogonaux auxaspe tsmétiers desappli ations. Pour des raisonsd'e a ité etde rédu tion des oûts,il est fortement souhaitable de pouvoir on evoir et utiliser des solutions de toléran e aux fautes indépendamment desservi es fon tionnels quedoivent fournir esappli ations.

Le su ès des intergi iels dans le adre du développement de systèmes d'information géné-ralistes omme les appli ationsWeb,en ourage leur utilisation pour d'autresappli ations plus spé iques, omme les appli ationstemps réel ou même ertaines appli ations ritiques. Le dé-veloppement et le déploiement de es appli ations se base de plus en plus sur la réutilisation de omposants (matériels et logi iels). On parle alors de omposants pris sur étagère (COTS). Ces appli ations présentent des ontraintes et des exigen es en qualité de servi e plus di iles àsatisfaire. L'intergi ieldoit maintenant répondreàde nouveaux déset on ilier de nouveaux besoins.

1 Position du problème

La sûreté de fon tionnement et la distribution sont deux domaines étroitement liés. D'une part,ladistributionpermetd'assurerlarépli ationd'entitéssurplusieursnoeudsphysiques (ma- hines) oulogiques(partitions),etainsitolérerladéfaillan e de ertainesde esentités. D'autre part,ladistributionné essitedesressour esmatérielleset logi iellesadditionnelles, augmentant laprobabilitédedéfaillan esetdon lebesoind'appliquerdeste hniquesdetoléran eauxfautes appropriées.Grâ eà elien étroitentrelatoléran eauxfauteset ladistribution, l'intergi ielest defa to l'un des meilleurs endroitspouvant héberger ertaines fon tionnalités de toléran e aux fautes omme lagestiondelarépli ation. Enoutre, la onsolidationde ertainesfon tionnalités de l'intergi iel permet d'améliorer la sûreté de fon tionnement des appli ations développées et déployéesà l'aidede etintergi iel.

L'ar hite ture s hizophrène[100℄ donne àl'intergi iel des apa ités de onguration, d'adap-tationetd'interopérabilitétrèsintéressantes,voireprimordialesdans ertains as.Cette ar hite -tureamontrésone a itémêmepour ertaines appli ationsprésentantplusieurs ontraintesen termesde onsommationderessour esoudedéterminisme.Lemanquedesupportdemé anismes générauxde toléran e aux fautes et de onsensus onstitue un obsta le et limite le hamps des appli ationspouvant utiliserl'intergi iel. Nousnousproposonsd'étudierlapossibilitéd'ajout de servi edetoléran e auxfauteset de onsensusà l'ar hite ture s hizophrène sans ompromettre sespropriétés.

Le problème du onsensus peut se dénir (informellement) sur un ensemble de pro esseurs omme suit: initialement, haquepro esseurproposeune valeur et touslespro esseurs orre ts

(par exemple eux qui ne sont pas en panne) se mettent d'a ord sur une valeur ommune. Malgré sa formulation simple, le onsensus est un problème fondamental sur lequel se base la majorité des algorithmes d'a ord [114 ℄. C'est le as du multi ast atomique (atomi multi ast), de l'appartenan e à un groupe (group membership), et . La rédu tion des algorithmes d'a ord au onsensusa étésujet de plusieurs travaux de re her he. Par exemple [53 ℄ introduit lanotion de ltresde onsensus onsensus ltersquipermettent de résoudreplusieurs problèmes d'a ord enadaptantunalgorithmede onsensus.L'abstra tiondu onsensuspeutégalement êtreutilisée d'une manière expli ite par ertaines appli ations. Par exemple, la ré on iliation des valeurs renvoyées parplusieurs apteurs.

Pour êtrevraiment e a es,lesalgorithmes de onsensusdoivent garantirun omportement temporelprévisible etfournirdesgaranties plusfortesquele ritèredeterminaison lassique.En eet,Ce ritèrepostuleque haque algorithmede onsensusdoit onverger, sansdonnerau une indi ation surletemps de onvergen e.Or,en pratique,letemps de onvergen eestune donnée primordiale pour la on eption et la mise en oeuvre des appli ations. Pour estimer les temps de onvergen e,deste hniquestelles quelasimulation ou lamodélisation formelle peuvent être utilisés.

La diversité des appli ations et la variabilité des environnements dans lesquels les appli a-tions (ou ertainesbriques logi ielles)évoluentmotiventla on eptiond'unservi ede onsensus générique qui se base sur l'intergi iel à la fois omme support fon tionnel et omme garantie des hypothèses sur les modèles de al uls et eux de défaillan es. La généri ité du servi e de onsensus que nous proposons dépasse le adre de la simple onguration aux hoix transpa-rents de l'algorithme de onsensus souhaité par l'appli ation. Ce i augmente la portabilité des appli ations et l'e a ité de l'intergi iel fournissant ette abstra tion. L'intergi iel, en général, et les omposants fournissant le servi e du onsensus peuvent alors être onsidérés omme de vrais omposantspouvant être prissur étagère (COTS).

2 Obje tifs et démar he

Dans ettethèse,nousnousintéressonsàdeuxproblèmes.D'abord,nousétudionslesréponses oertes et les ontraintes posées par l'ar hite ture s hizophrène lors du support de mé anismes généraux de toléran e aux fautes. Ensuite, nous nous intéressons à l'abstra tion du onsensus qui onstitue unebasefondamentale deplusieurs servi estolérantsauxfautes,et proposonsune méthode de onstru tion d'appli ations sûres de fon tionnement se basant sur l'ensemble des omposants quenousavonsdéni.

Le standard FT CORBA propose plusieurs mé anismes généraux de toléran e aux fautes (re-dondan estemporellesetspatiales,supportdeplusieursstylesderépli ation lassiques,et .).En outre, il propose d'enri hir CORBA,un standard ri he,répandu et ayant étéutilisé dansle adre d'appli ations ritiquesettempsréel.L'étudede estandardnouspermettrad'évaluerl'e a ité desréponsesqu'orel'ar hite tures hizophrèneetdeproposerlesaméliorationsné essairespour supporterlesmé anismesdetoléran eauxfauteslesplusgénéraux.L'a ent seramisd'unepart sur la déte tion et la noti ation des défaillan es et d'autre part, sur le support des diérents styles derépli ation proposéspar lanorme.

Le se ond axe de notre travail onsiste à étudier et à réaliser un servi e de onsensus qui se veut le plus générique possible an de se plier aux besoins du plus grand nombre d'appli a-tions. Nous nousbasons sur l'expérien e a quise lors de l'étude de FT CORBA, en parti ulier la gestion desgroupes de répliqueset ladéte tion de défaillan es pour proposer unservi e et une méthodologiede on eptiond'appli ationsdistribuéesné essitantl'abstra tion du onsensus.La

on eptionduservi edu onsensuspermettradeproterpleinementdesavantagesde l'ar hite -tures hizophrène etde seplieràplusieurs ontraintesimposéespar essystèmes(déterminisme, performan es, exigen esdemodélisation omportementale, exigen esde erti ationet .).

Pendant notreétude de esdeux problématiques, nousdénissons le rlede l'intergi iel, les avantages de son ar hite ture pour supporter les mé anismes de toléran e auxfautes.Plusieurs besoinset ontraintes imposéespar les systèmes ritiques seront pris en ompte tant surleplan ar hite tural qu'au niveau de l'implantation. Des évaluations qualitatives et quantitatives se basant surdess énarios de testsminutieusement onçus ompléteront notreétude.

3 Plan

Le do ument eststru turé en troisparties: état del'art, on eption, et réalisation. État de l'art

Danslapremière partie,nousmettonsl'a entsurlesprin ipesgénérauxde latoléran eaux fautesainsiquelaproblématique du onsensus.Nousnousintéressonségalementàlaprodu tion dessystèmes distribués ritiques et aux propriétés permettant aux intergi iels de supporter les besoinsde essystèmes.

Dansunse ond hapitre,nousprésentonslestravauxsurlesquelsrepose ettethèseainsique leslimitationsdetravauxdere her heexistants.Cetteétudemetenvaleurles ontributions que nousproposonsdansledomainedesintergi ielsdédiésauxappli ationssûresdefon tionnement. Con eption

La se onde partie se dé ompose en deux hapitres. Dans le hapitre 3, nous présentons les prin ipes de l'ar hite ture intergi ielle s hizophrène ainsi que es avantages. Nous nous inté-ressons ensuite au standard FT CORBA. Nous étudions ensuite les mé anismes les plus e a es permettant d'implanter estandard en protant et en onservantles propriétés et les avantages del'ar hite ture s hizophrène.

Dans le hapitre 4, nous on evonsun ensemble de omposants fournissant l'abstra tion du onsensus. Nousdégageons l'ensembledesabstra tions quedoit fournir l'intergi iel aux ompo-santsdu onsensus.Ensebasantsurlesétudesthéoriquesautourduproblèmedu onsensusainsi quesur ertainspartonsde on eption; nousproposonsunservi ede onsensusdontnous maxi-misonsdansunse ondtempslespossibilitésde onguration.Outreles asd'utilisationbasiques, noustraitons l'intégration de e servi e au sein de l'ar hite ture s hizophrène et présentons les avantages de ette intégration.

Réalisation

Dans la troisième partie, nous expliquons les hoix et les méthodes que nous avons utilisés pour réaliserles diérents servi es et omposants quenous avons dé ritsdans ladeuxième par-tie. Pour notre implémentation et nos mesures, nousnous baserons sur une implémentation de l'ar hite ture s hizophrène : PolyORB

1 .

Le hapitre 5 fournit une des ription détaillée desbriques logi ielles que nousavons onçus pour implanter FT CORBA. Dans le hapitre 6 nous détaillons l'implantation et l'ensemble des omposants qui onstituent le servi e du onsensus que nous avons onçu. An de valider nos

1

propositions, nousavons mis en pla edess énarios de test et ee tué plusieurs mesuresan de monter l'e a ité des ar hite tures que nous avons proposées et des hoix d'implantation que nous avons faits. Nous en dis utons les résultats et, quand 'est possible, nous omparons es résultats ave les travaux similaires. Le dernier hapitre on lut e mémoire en rappelant les ontributions essentielleset les perspe tivesouvertes par notretravail.

Cadre général, notions de base et problématique Contents 1.1 Cadre général . . . 8 1.2 Intergi iels . . . 9 1.2.1 Dénitionet généralités. . . 9 1.2.2 Ar hite turedel'intergi iel. . . 10 1.2.3 Apportsdesintergi iels . . . 10 1.3 Toléran e auxfautes . . . 11 1.3.1 Dénitionset notionsdebase . . . 11 1.3.2 Besoinsentoléran eauxfautes . . . 13 1.3.3 Prin ipesdelatoléran eauxfautes . . . 15 1.3.4 Con lusion . . . 18 1.4 Consensus . . . 18 1.4.1 Dénition . . . 18 1.4.2 Besoins . . . 19 1.4.3 Résultatsthéoriques . . . 20 1.4.4 Con lusion . . . 23 1.5 Produ tiond'appli ations ritiques distribuées . . . 23 1.5.1 Ar hite ture . . . 24 1.5.2 Utilisationdeslangagesdeprogrammationdehautniveau . . . 25 1.5.3 Validation . . . 26 1.5.4 Con lusion . . . 27 1.6 Obje tifs etaxes de re her he . . . 28 1.6.1 Obje tifs . . . 28 1.6.2 Propositionset ontributions. . . 29 Les problèmes de toléran e aux fautes et de onsensus sont posés par un nombre de plus en plus important d'appli ations. L'omniprésen e de l'informatique dans la vie moderne et les diverses onséquen esdesdéfaillan esmotiventl'emploideste hniquesassurantla ontinuitédes servi es même en as de défaillan es. Certaines te hniques de toléran e auxfautes né essitent, selon le as, plusieurs types d'a ord dans un environnemt distribué. Ces a ords peuvent par

exemple on erner les membres nonfautifsd'un groupe,l'étatglobal dusystème,letemps (syn- hronisationdeshorloges),l'éle tiond'unleader,et .Le onsensusestdon unproblèmegénéral, trouvant plusieurs appli ations dansplusieurs domaines, y omprislatoléran e auxfautes.

Leste hnologies intergi ielles réduisent les eorts de on eption et de développement d'ap-pli ationsdistribuées.Lesu èsde este hnologiesdansle adredelaprodu tiond'appli ations généralistes motive leur utilisation pour d'autres appli ations plus exigeantes. L'étude de es te hnologies et deleurs apports lors delaprodu tiond'appli ations devantprésenterdes garan-tiespar rapportàleursûretédefon tionnementestégalementmotivéepar lespressionsexer ées surles délaiset les oûtsde lamisesurle mar hé de esappli ations.

Cette thèse s'intéresse au niveau de support que peuvent ou doivent orir les intergi iels à la toléran e aux fautes et au onsensus dans le adre de la produ tion d'appli ations sûres de fon tionnement.

Cepremier hapitre introdu tif présente lesdénitions et les on epts générauxrelatifs aux intergi iels, àlatoléran e aux fauteset au onsensus. Nous nousintéressonsensuiteà ertaines pratiques de développement d'appli ations ritiques. Ces appli ations présentent généralement des exigen es fortes en sûreté de fon tionnement et utilisent souvent des servi es de toléran e auxfautes et/oude onsensus. Nousnousinspirons de espratiquesetessayonsde satisfaireau mieuxles diérentes exigen esde es appli ations, même sile hampsde notreétude omprend également des appli ations moins exigeantes. La dernière se tion de e hapitre présente les obje tifsde notrethèse, lesdiérents hoix quenous avonsee tué ainsiquenos ontributions.

1.1 Cadre général

Dénition 1 (Système ritique) Un système ritique est un système dont le dysfon tionne-mentpeut auser desperteshumainesoudes blessures graves,provoquer despertesoudes dégâts matériels ou en ore porter atteinte à l'environnement.

Lessystèmes informatiques deviennent de plusen plus omplexes. Cette omplexité se ma-nifestepar latailledesappli ations (nombre defon tionnalités, nombre de lignesde ode,et .). Ellepeutaussisemanifesterparledéploiementsousformedeplusieurs noeudsdisposant ha un d'un espa e d'adressage propre (distribution). Cette omplexité peut également se manifester par l'utilisation deplusieurs lsd'exé ution( on urren e). Cette omplexité augmente lerisque de défaillan es des appli ations et invite à prendre les dispositions né essaires pour garantir la ontinuité desservi es..

L'utilisationdel'informatiquene essedeserépandre,àunpointousaprésen edansplusieurs systèmes ne seremarque plus. La qualité desappli ations est alors un obje tif important et les onséquen esdesdysfon tionnementspeuventêtredans ertains asdramatiques.Parallèlement, laréalitédumar héet on urren eengendrentdespressionssurles oûtsetlesdélaisdemisesur lemar hé et invitentà optimiserlesméthodesdeprodu tionde esappli ations. L'amélioration delarentabilitédelaprodu tionsansrelaxerlesobje tifsdequalitéestundédontlarésolution intéresse plusieurs industriels.

Les te hnologies intergi ielles fournissent plusieurs moyens permettant l'optimisation de la produ tion.Ceste hnologiesfavorisenteneetlaportabilité,l'interopérabilitéetlaréutilisation et réduisent don les oûtsdu développementdessystèmes distribués.D'autrepart,latoléran e aux fautes, le onsensus et la distribution sont étroitement liés ( omme le montre 1.3.3). Le supportde latoléran e auxfautes et du onsensusau niveau del'intergi iel onstitue alors une ontribution intéressante à larésolution de e dé.

Le supportde latoléran e auxfautes et du onsensus par lesintergi iels ne sut pasà leur utilisation dans le adre du développement d'appli ations sûres de fon tionnement, la qualité et l'e a ité des mises en oeuvre doivent également être garanties. Nous étudierons plusieurs aspe ts de la produ tion de es appli ations an d'améliorer nos propositions et nos mises en oeuvre.

Les intergi iels ont également un autre rle aussiimportant que lesupport de servi es per-mettant ouaméliorant lasûretédefon tionnement.Leniveau dequalitédeservi erequisparles appli ations ritiqueset lavariationdesexigen esetdes ontraintesentrelesdiérentes appli a-tions ibles exige des apa ités d'adaptation importantes au niveau de l'intergi iel. En général, ilfaut réussir le ompromisentrelatoléran e auxfautes,le temps et lesfon tionnalités tout en respe tantles ara téristiquesdel'environnementdanslequelévoluelesystème.Nousétudierons lespropriétés desintergi iels permettant larésolution de es ompromis.

Les pro haines se tions présenteront les notions importantes et les dénitions relatives aux domainesdesintergi iels,delatoléran eauxfautesetdu onsensus.Nousprésentonsensuiteles pratiquesdedéveloppementdesappli ations ritiquesainsiquenospropositionset ontributions aux support de la toléran e aux fautes et du onsensus par les intergi iels dans le adre du développement d'appli ations sûres defon tionnement.

1.2 Intergi iels

Cettese tion présente une vuegénérale desintergi iels et de leurs prin ipesar hite turaux. Ellemontre également les avantages del'utilisation de este hnologies.

1.2.1 Dénition et généralités

Les dénitions du terme intergi iel sont très nombreuses. Généralement, un intergi iel (en anglaismiddleware) estunlogi ielservantd'intermédiaire de ommuni ationentreplusieurs ap-pli ations,généralement omplexesoudistribuéessurunréseauinformatique

2

.Pour emémoire, nousproposonset utilisons ladénitionsuivante :

Dénition 2 (Intergi iel) L'intergi iel estuntermedésignantunensembledeservi eset d'in-terfa esrésidantentrel'appli ationetlesystèmeopératoire.Ilpermetl'intera tionentreplusieurs entitésdéployées surune ouplusieurs ma hinesetpouvanté hangerdes données grâ e à un sys-tème de ommuni ations tel qu'un réseau.

L'intergi ieldoitsonnomàsapositionentrelesentitésappli ativesetlesystèmeopératoire. Grâ eàl'intergi iel,l'appli ation estdé ouplée dusystèmeopératoiresousja ent, equipermet auxdéveloppeurset aux intégrateurs de faire abstra tion de plusieurs détails debasniveau liés àladistribution et aux ara téristiquesdes systèmesopératoires.

Leste hnologies intergi iellessont maintenant re onnues omme très bénéquesvoire indis-pensables à la on eption et la réalisation de plusieurs appli ations distribuées. La prin ipale fon tionnalitéoertepar unintergi iel esten eetd'assurer oude fa iliterlesé hanges données entre entités physiquement oulogiquement séparées. Lesintergi iels sebasent sur desprin ipes ar hite turaux intéressants tels que la séparation des préo upations. Le paragraphe suivant fournitune vision généralesurl'ar hite ture d'un intergi iel.

2

Fig. 1.1 Appli ation distribuée baséesur unintergi iel

1.2.2 Ar hite ture de l'intergi iel

L'intergi iel est une ou he logi ielle fournissant un ensemble d'abstra tions utiles pour la distribution et/ou pour laportabilité desappli ations. L'intergi iel fournit un ensemble de ser-vi es généralement a essibles à travers une interfa e de programmation (en anglais, API pour Appli ation Programming Interfa e). Ces servi es sont soit lo aux, soit distribués. Les servi es lo aux permettent d'abstraire les fon tionsd'un OS. Il permettent d'assurer d'autres fon tion-nalités omme lajournalisation etlamiseen pla ede a hes.Lesservi es distribuéspermettent d'assurer des fon tionnalités élémentaires omme les é hangesde données entre les noeuds. Les servi esdistribuéslesplusévoluéspeuventsebasersurdesproto oles omplexespermettant par exemple larésolution desnoms et lagestiondestransa tions.

La dénition des API par les intergi iels permet don d'abstraire les fon tionnalités de dis-tribution et elles d'un OS. Elles présentent aux développeurs une vue uniforme des diérents servi es lo auxet distribués. Lesdéveloppeurspeuvent alors se on entrer surla logiquemétier des appli ations en faisant abstra tion de plusieurs propriétés (non fon tionnelles) du produit nal omme les paramètres dedéploiement.La omplexité liée à esparamètres de déploiement doitmaintenant être géréeau niveau del'intergi iel.

Lesintergi iels sont eux mêmes di iles à on evoir et à réaliser. Leurmise en oeuvre doit en eet tenir ompte des propriétés desenvironnements de déploiement des appli ations ibles mais aussi des exigen es et ontraintes imposées par es appli ations. Les intergi iels doivent alorsêtre soigneusement onçuset rigoureusement misenoeuvre.L'ar hite ture logi ielleestun aspe t fondamental de l'intergi iel et des appli ations réparties. Les propriétés des intergi iels sont souvent dérivées de leurs ar hite tures. Ces ar hite tures permettent également de faire plusieurs ompromisan demieuxsatisfairelesbesoinsdesappli ations ibles:intéropérabilité, portabilité,e a ité,fa ilitéd'utilisation,adaptabilité,performan es,et .Lase tion2.2fournira d'amples informations sur les ar hite tures, et les propriétés des intergi iels. L'ar hite ture de l'intergi iel doit don être dénie ave un maximum de rigueur et miseen oeuvre ave une très grandeattention.

1.2.3 Apports des intergi iels

La position de l'intergi iel lui permet de dé oupler les entités appli atives du système opé-ratoire et des systèmes de ommuni ation. Cette position permet de faire abstra tion de la

distribution, desdétails demise enoeuvre et de l'hétérogénéitédeslangages de programmation et dessystèmesopératoires.

L'intergi ielfournitunensembleuniformeet généralement standardiséd'interfa esaux déve-loppeurset aux intégrateurs d'appli ations distribuées. Ces appli ationspeuvent alors être por-tées,réutiliséeset omposées.Ilfournitégalement unensembled'interfa es, deservi eset d'abs-tra tions permettant de résoudre ertains problèmes ré urrents indépendamment des appli a-tions. Ces diérentes fon tionnalités réduisent dans plusieurs as le besoin de développer des élémentsspé iques et en ouragent laréutilisation.

Les te hnologies intergi ielles permettent don de réduire les oûts et les temps de produ -tion des appli ations distribuées. Leur utilisation a été très bénéque dans le adre d'un très grandnombre d'appli ationsetsurtout pourlessystèmesd'informations généralistes ommepar exempleles servi esWeb.

Lessu èsdeste hnologies intergi iellesfavorisent l'expansionde leurutilisation. Des appli- ations de plus en plus exigeantes font partie d'ensemble des ibles de l'intergi iel. Ce dernier doit don ré on ilier des besoins de plus en plus ontradi toires et présenter des garanties de plusen plus fortes quant à ses servi eset son omportement. La pro hainese tion s'intéresse à latoléran e aux fautes, l'une des te hniques les plus importantes pour la sûreté de fon tionne-ment.La relation entre latoléran e auxfautes et ladistribution etl'obje tif de l'utilisation des intergi iels lors du développement d'appli ations sûres de fon tionnement motivent le support delatoléran e auxfautes auniveau del'intergi iel.

1.3 Toléran e aux fautes

La toléran e aux fautes se présente omme une te hnique omplémentaire auxa tions per-mettant d'éviter les fautes (fault avoidan e), de les prévoir (fault fore asting) et de les éliminer (faultremoval).L'a tion d'éviterlesfautes onsisteàréduire autant quepossibleleur nombre en sebasant par exemplesurunpro essusdedéveloppement rigoureux.L'éliminationdesfautesse faitpendant la phasede validationou lors de l'utilisation du système(phasesde maintenan e). Laprévisiondes fautesanti ipe esdernières ande les éliminerou de ontourner leur eets.

L'importan e des te hniques de toléran e aux fautes réside surtout dans la possibilité de réagir, pendant l'exé ution de l'appli ation, à des situations imprévues. Cette se tion propose uneintrodu tion rapideà e domaine.Nousmontronsl'importan edelatoléran eauxfauteset nousdétaillonsles prin ipalesavant d'enprésenterles prin ipesles plusimportants.

1.3.1 Dénitions et notions de base

Dans e paragraphe, nous présentons les on epts et les dénitions relatives au domaine de la toléran e aux fautes sur lesquels nous nous baserons pour la suite de e do ument. Nous reprenonsprin ipalement les dénitions de[74 ℄.

Dénition 3 (Faute) Une faute est dénie omme une modi ation stru turelle non voulue d'un produit. Cette modi ation entraîne lepassagedu système dans un état in orre t.

Les fautes sont généralement invisibles depuis l'extérieur du système. Pour avoir des onsé-quen essurlefon tionnement orre tdessystèmes,les fautes doivent setransformeren erreurs (A tivation). Dans les systèmes d'information, les fautes peuvent être lassées selon plusieurs ritères omme leur a tivité (a tives ou latentes), leur nature (transitoires ou permanentes) ou leurs auses auses (aléatoiresougénériques). Généralement,lesfautesmatériellesseproduisent

d'unemanièreisoléeetsontgénéralement duesàl'environnementdusystème.Ellessonttrès sou-venta identellesettransitoires.Lesfauteslesplusfréquentesdanslemondedulogi ielsontdes fautesde on eption.La omplexité roissantedeslogi ielsfavorisel'apparitiondefautesdansles logi iels.Mêmesiplusieurste hniquesdevalidationpermettent l'éliminationd'ungrandnombre de fautes,ilest di ile

Leste hniquesde validationne permettent généralement l'élimination de toutes les fautes. Dénition 4 (Erreur) L'erreurestlapartiedel'étatinternedusystèmequi auseladéfaillan e de l'unou de plusieurs servi es proposés.

Danslamajoritédessystèmes,ilestimportantdedéte terl'o urren ed'erreursetdeprendre desdé isionspermettantd'assurerlebonfon tionnementdessystèmes.Cependant,laréparation desfautesàl'originede eserreurs, bienquetrèsre her hée,n'estpasné essairementessentielle pour assurer unfon tionnement orre tdessystèmes [103 ℄.

Dénition 5 (Défaillan e) La défaillan e est l'évènement qui a lieu quand le servi e délivré n'est plus onforme aux spé i ations. C'est la panne proprement dite.

Siun omposantdépendd'unautre,ladéfaillan edupremierestunefautequipeutàsontour provoquerune erreur interne puisune défaillan e duse ond, 'estlemé anismede propagation. Dans e as,ilesttrèsdi iled'identierlesvraies ausesdeladéfaillan e.Lapropagationpeut en eet on erner plusieurs omposants selonles héma:

faute

→

→

→

→

→

→

Dénition 6 (Toléran e aux fautes et Sûreté de fon tionnement) Latoléran eauxfautes désigne la apa ité d'un système à ontinuer à fournir un servi e a eptable malgré la présen e dequelquesfautes. Latoléran e auxfautes s'intègredansundomaineplusgénéral qu'estla sûreté defon tionnement(dependability).Cettedernière est unepropriété(non fon tionnelle)d'un sys-tème informatique permettant à ses utilisateurs de pla er une onan e justiée dans le servi e qu'il délivre.

Latoléran eauxfautes intègre plusieursattributs (abilité,disponibilité, sé urité,intégrité, fa ilité de lamaintenan e) [74 ℄. Nous donnons i i les dénitions des attributs qui serviront par lasuite, notamment,pour exprimerles besoinsen toléran e auxfautes.

Dénition 7 (Fiabilité) Laabilité (Reliability)est la propriétéexprimant l'aptituded'un sys-tème à fournir ses servi es onformément aux spé i ations pendant une ertaine période. Gé-néralement, on mesure la abilitéd'un servi e par la probabilité defon tionnent orre t sur une période donnée.

Dénition 8 (Disponibilité) La disponibilité (Availability) est la propriété exprimant que le système est en état de rendre son servi e à un instant donné. Généralement, la disponibilité d'unsystème semesure enpour entage detempspendant lequellesystème est apable defournir ( orre tement) ses servi es.

Dénition 9 (Sé urité (ou sûreté)) La sé urité (Safety) exprime qu'un dysfon tionnement du systèmen'a d'in iden e atastrophique ni sur sonenvironnement, nisur l'utilisateur.

La sé urité (au sens se urity) exprime la apa ité d'un système à empê her tout a ès non autoriséaux données.

Les propriétés de abilité et de disponibilité ne sont pas équivalentes. Informellement, la première détermine lenombre de défaillan es pendant une ertaine durée, alors que lase onde détermine letemps total pendant lequelle systèmeestopérationnel.

1.3.2 Besoins en toléran e aux fautes

Lesbesoinsentoléran e auxfautesne essent d'augmenterdu faitde l'utilisation roissante del'informatique en général et de essystèmes enparti ulier.

De nos jours, l'o urren e de fautes dansles systèmes informatique est inappré iable, dan-gereuse, ou même atastrophique : ertains se rappellent en ore de la hute d'Ariane 5 ou de l'é he desmissilespatriots lorsdelapremièreguerreduGolf.Cependant,à ausedeplusieurs fa teurs, omme la omplexité des logi iels, la dégradation physique des omposants ou tout simplement par e quelerisque existe

3

il estimpossible d'évitertoutes les fautes,on tente alors deréduire leurs probabilités d'o urren e etd'a tivation.

Latoléran eauxfautesestd'importan eplusoumoins ritiqueselonlesappli ations.Dansle asd'appli ationsavioniquesouaéronautiques,iln'estsupportéqu'unarrêtmomentané(dedurée très ourte) desservi es ritiques. Lesexigen essont d'autant plus fortes quepour ertaines de esappli ations, ilestimpossiblede pro éderàdesopérationsderéparationoudemaintenan e. Enoutre, leserreursdevaleursnesontgénéralement pasa eptables, arellespeuvent avoirdes onséquen es atastrophiques. Nous donnons i i deux as d'é he de missions ritiques à ause de l'absen e ou de l'insusan e de la toléran e aux fautes. Le premier est elui des missiles patriots en 1991 : à ause d'une faute passée inaperçue lors des tests, es missiles n'ont pas réussi à inter epter les premiers missiles ennemis. Le as d'Ariane 5 est plus intéressant : il motivel'utilisation deste hniquesdetoléran eauxfauteslogi iellesetilmontre, d'unepartque la réutilisation doit se faire ave une très grande attention et d'autre part, que l'exigen e en toléran eauxfautes dépasse lasimplemiseen oeuvred'une redondan e.Laredondan e doit en eet être appliquée d'unefaçon adéquate, en parti ulier, il faut queles omposants redondants netombent pasen panneà ause d'unemême faute.

L'introdu tiondelatoléran eauxfautesdansunsystèmen'estpassans oût( arelleimplique l'introdu tion d'une ertaine redondan e dans le système [51 ℄). Ce oût est souvent loin d'être négligeable.Laproblématiqueestalorsdedéterminerledegrédelatoléran eauxfautesadéquatà unsystèmeouuneappli ation:ilfautfaireun ompromisentrele oûtetlerisque[62 ℄.Certaines te hniquesdetoléran eauxfautespeuventdiminuer lesperforman esglobalesdessystèmes.Par onséquent, ette ontrainte doit être prise en ompte lors de la spé i ation des besoins de ertainesappli ationsquiprésentent detellesexigen es,parexemple lesappli ationstempsréel. Cristianparle alors d'un équilibreglobal entre oût, performan es, et sûreté de fon tionnement [29℄.

1.3.2.1 Attributs de la toléran e aux fautes

Lesbesoinsentoléran eauxfautesdépendentnon seulement delanaturede l'appli ationet desexigen esdesutilisateurs,maisaussides onditionsd'utilisation,des ontraintesimposéespar l'environnement,desparamètresdequalitédeservi erequisetmêmelesméthodesde on eption. Ces besoins peuvent s'exprimer en fon tion de ertains attributs de la toléran e aux fautes : abilité,disponibilité et sé urité.

3

LaloideMurphyestunprin ipeempiriqueénonçantques'ilexisteunepossibilitédemauvaisemanipulation d'unproduitoud'uneméthode, ettemauvaisemanipulationnitparavoirlieu

Laabilitépeut êtreutiliséepour ara tériserlesbesoinsdessystèmesdont laréparationest très oûteuse voireimpossible (parexemple les al ulateursembarquéssurunsatellite). Généra-lement,ilesttrèsappré iabled'utiliserdessystèmesablesmêmesi,pour ertainesappli ations, ona epte ertainesdéfaillan es.Laabilitépermetparexemplede ara tériser ertainsbesoins d'appli ations spatiales. Par exemple, on peut trouver dans un ahier de harge qu'une station spatiale doit pouvoir fon tionner dans un mode parti ulier sans interruption pendant 30 jours ave une abilitéde 80%.

Ladisponibilitéestun ritère signi atiflors desspé i ationsdesbesoins.Certainesétudes omme [84℄ évaluent le oûthoraire moyen de l'indisponibilité des servi es de ertains se teurs de l'industrie améri aine. Ces oûts s'évaluent à

2 500 000 $

6 500 000 $

La sé urité est peut être la propriété la plus importante attendue d'un système ritique. En eet, ette propriété implique que le système ne présente pas d'in iden e  atastrophique sur son environnement. Par exemple un mauvais fon tionnement du logi iel qui ontrle la températureau oeurd'une entrale nu léairene doitenau un asentraîner uneexplosion. Les exemples illustrant l'importan e de la sé urité sont très nombreux ( ontrle du tra aérien, guidage demissiles, et .).

1.3.2.2 Domaines d'appli ations

L'expressiondesbesoinsentoléran eauxfautesenfon tiondesesattributsprésenteplusieurs in onvénients. D'une part, elle peut sourir d'impré isions, ar les attributs de la sûreté de fon tionnement dépendent de plusieurs paramètres omme l'environnement et les omposants logi iels et matériels de l'appli ation. D'autre part, es attributs ne donnent pas d'indi ations surles méthodeset lesalgorithmes qui doivent être utilisés.

Danslalittérature, noustrouvonsd'autres méthodes plus pré ises pour l'expression des be-soins. La première [118 ℄ propose une lassi ation basée sur la oordination entre les apports des diérentes te hniques de la toléran e aux fautes d'une part et les besoins des appli ations d'uneautrepart.Cette lassi ationneprendpasen omptelesfautesmatérielles.Lase onde[9 ℄, plus simple, lasse les besoins selon la nature de l'appli ation. Pour des raisons de larté nous nouslimitonsàlase onde lassi ation.Cette lassi ationdénitquatre lasses (oudomaines) d'appli ations : appli ations ritiques, appli ations à longue durée de vie, appli ations à haute disponibilité et appli ations ommer iales.

Les appli ations ritiques doivent justier de plusieurs garanties au niveau de la sûreté et de l'e a ité des servi es qu'elles proposent. Ce besoin dé oule de la né essité de protéger du matérielextrêmement her oude préserver desvieshumaines.Le hoixde modèles représentant le aspireestgénéralementappré ié lorsdelaphasedel'expressiondesbesoins.Ilfauttoutefois faireun hoixjudi ieuxde esmodèles.Eneet,le hoixsystématique desmodèles représentant lespires asrésultegénéralement enunsystèmetrèsdi ile voireimpossibleàmettreenoeuvre. Lesautres typesd'appli ations présentent moinsd'exigen espar rapportàlasûretéde fon -tionnement.Lesappli ationsàlongueduréedevie( ommelessatellitesoulesrobotsré emment envoyés surMars)doivent pouvoir ontinuer àfon tionner sansmaintenan e durant desannées, ilfautalorsanti iper lesdégradationsmatériellesetles hangementsd'environnement.Landes missions est généralement atteinte grâ e à un usage intensifde laredondan e. Les deux autres domainesd'appli ations présententdes ontraintes moinsforteset sontmoinsexigeantesqueles

deuxpremières.Ellestolèrent les interruptions deservi ede ourte duréepour elles présentant desexigen esendisponibilité. Lesappli ations ommer iales sont en ore moinsexigeantes.

L'expression des besoins en sûreté de fon tionnement est ru iale, elle doit être pré ise et omplète. L'impré ision ou l'omission de ertains besoins peuvent en eet auser des erreurs durant tout le y le du développement. Le danger de la mauvaise expression des besoins est lié au fait que les problèmes qu'elle engendrent sont très di ilement déte tables et qu'ils se ne manifestent dans la plupart des as qu'à travers les défaillan es. Ce paragraphe a montré l'importan edelatoléran eauxfautes.Nousnoussommesintéresséauxbesoinsentoléran eaux fautes, présenté quelque méthodes permettant l'expression des besoins et montré l'importan e de ette phase. Les paragraphes suivants présentent des éléments de la théorie de la toléran e auxfautes.Nousnousattarderons surles te hniques et résultatsquinousserviront pendant les pro hains hapitres.

1.3.3 Prin ipes de la toléran e aux fautes

La toléran e aux fautes et les systèmes distribués sont étroitement liés. D'une part, la to-léran e aux fautes motive la distribution des données et des tâ hes par e qu'elle né essite une ertaineredondan e.D'autrepart,dansunenvironnementdistribué,lamultipli itédesressour es logi ielles et matérielles augmente signi ativement les sour es de fautes et les probabilités de dysfon tionnement. D'où lebesoin d'a order uneattention parti ulière àlasûreté de fon tion-nement dusystème et demettre enoeuvre lessolutions de toléran e auxfautes appropriées.

Cette se tion s'organise omme suit : d'abord, nous présentons les on epts de base de la toléran eauxfautes.Ensuite,nousprésentonslarépli ationetdonnonslesraisonspourlesquelles larépli ationestlasolutionlaplusutiliséepourlatoléran eauxfautesdanslesenvironnements distribués.

1.3.3.1 Redondan e : base de la toléran e aux fautes

Dénition 10 (Redondan e) La redondan e désignela multipli ité etla répétition.C'est une pratique ouramment utilisée lors de la on eption de systèmes ritiques et/ou tolérants aux fautes.

On distingue trois forme de redondan e [117 ℄, la répli ation, la redondan e fon tionnelle et la redondan e analytique. Si la répli ation permet d'exé uter exa tement les mêmes traitements, laredondan e fon tionnelle permet l'obtention des résultats maisen exé utant des traitements diérentset laredondan e analytique a eptedes résultatsdiérentss'ils restent ohérents.

Toute solution tolérante aux fautes se doit de mettre en oeuvre au moins une forme de redondan e[51 ℄.Laredondan eestune onditionné essairemaispassusante.Lesystèmedoit enplusimplémenterunmé anismededéte tiond'erreurs(quipeut,lui-même,avoirbesoind'une ertaineformederedondan e).Nousdé rivons idessousles troisformesderedondan e lesplus onnues : redondan e d'information, redondan e temporelle et redondan e spatiale.

Redondan ed'information Laredondan ed'informationdupliquelesdonnées.Elleest géné-ralementutiliséepour maintenirl'intégrité desdonnéesdansunsystème.Les odesdeHamming illustrent e type de redondan e en dénissant des bits additionnelsdansune donnée pour per-mettre de la re onstituer en as d'altération. La redondan e d'information a plusieurs appli a-tions omme lesliensde ommuni ation lassiquesetlessupportsdesto kage(disques ompa ts, mémoire vive (RAM),et .).

Redondan e temporelle La redondan e temporellepermet latoléran e au fautes en dupli-quant les al uls et les traitements. Cette forme de redondan e implique des oûts en temps pour orriger l'erreur,typiquement en relançant l'opération qui aproduit l'erreur.Par exemple, un ontrleur de disqueréessaye l'opération de le turelorsqu'ildéte te une erreur de parité.La redondan e temporelle est très utile en as de défaillan es transitoires, mais sans utilité pour tolérer desdéfaillan espermanentes.

Redondan e spatiale Laredondan espatialedupliquedes omposantsmatérielsoulogi iels. Comme exemples se basant sur la redondan e matérielle, nous trouvons, les disques RAID, les serveurs de ba kup. La redondan e logi ielle n'est digne de e nom que si on met en oeuvre la diversitédes on eptions (design diversity).Par exemple,le NVP(pour N Version Programming). Le hoix de la redondan e spatiale est déterminé par la nature des fautes et par le oût de la dupli ationdes omposants. Les oûtsde laredondan edes omposantsdièrent selonlanature de logi ielle oumatérielle des omposantsen question.

 Redondan ematérielle:lesdéfaillan esmatériellessontdanslaplupartdes astransitoires, laredondan ematérielle peut alors s'appliqueren utilisantdes opies identiques dumême matériel.

 Redondan e logi ielle : la dupli ation des mêmes unités logi ielles ne permettent pas de tolérer les fautes de on eption et d'implémentation. La redondan e logi ielle ne doit pas sefairepar simple opie. Les oûts delaredondan e logi ielle sont très élevés.Ce typede redondan e n'est généralement utilisé quepour les appli ationsextrêmement ritiques. L'appli ation de ladiversitédes on eptions estun mé anismetrès dépendant de l'aspe t fon -tionnel desappli ations e qui rend lagénéralisation et laréutilisation impossibles. En plus, le oûtdelaredondan ematérielleétantplusfaibleque eluidelaredondan elogi ielle,onpréfère généralement déployer les mêmes unités logi ielles sur plusieurs unités matérielles pour mettre en oeuvre laredondan e spatiale,on parle dans e asde répli ation.

1.3.3.2 Répli ation

Dénition 11 (Répli ation) La répli ation d'une entité est le pro essus permettant de réer une opie de ette entité. Dans e manus rit, il s'agit de la dupli ation ohérente des mêmes unités matérielles et/ou logi ielles sur plusieurs noeuds physiques ou logiques pour mettre en oeuvre unaspe t dela sûreté de fon tionnement.

Larépli ation, ommeformeparti ulièrede laredondan espatiale,permet lemasquageet le re ouvrement desdéfaillan es et évite les points uniquesde défaillan es (single point of failure). Si un noeud est ina essible, soit par e qu'il est en panne, soit par e que les autres noeuds du groupel'ontisolé,l'unede esrépliquespermetd'assurerla ontinuitéduservi e.Poursupporter les défaillan es les plus graves (en parti ulier, les pannes byzantines), une redondan e massive est généralement utilisée. Dans le as où les pannes sont moins graves (pannes en omission ou pannes fran hes) une ou deux répliques peuvent sure. Les styles de répli ation dénissent le omportement de l'ensemble des répliques en as de fon tionnement normal et en as de défaillan es. Plusieurs stylesde répli ationexistent. Nousdé rivonsi i les répli ations a tive et passive.

Répli ation a tive La répli ationa tive(gure1.2) onsiste àmettre enoeuvre unensemble de répliques jouant le même rle. Dans un modèle lient/serveur, on réplique les serveurs qui reçoivent tous les requêtes, les traitent (en mettant à jour, si né essaire, leurs états internes)

et envoient une réponseau lient. Ce dernier hoisit une de es réponses. Dans ertaines as, il est possible d'améliorer e proto ole en lui rajoutant un mé anisme de vote. On parle alors de répli ation a tive ave vote. Notons que les mé anismes de vote peuvent être mis en oeuvre de plusieurs manières selon les besoins. Les mé anismes de vote peuvent également être répliqués omme pour les s hémas NMR 1.4.2.3.

serveur1

Serveur2

Serveur3

Client

traitement

reponse

Fig. 1.2 Répli ation a tive

Répli ationpassive Commelemontrelagure1.3,larépli ationpassivedésigneunélément dugrouped'objets ommeprimaire,lesautressontappelésserveursse ondaires.Dansunmodèle lient/serveur, le lient envoie sarequête uniquement au serveur primaire qui exé ute le traite-ment. Une fois le al ul ni, le serveur primaire met à jour les se ondaireset envoie la réponse au lient. Si le serveur primaire n'est plus fon tionnel alors l'un des se ondaires est promu et devient primaire.

serveur1

Serveur2

Serveur3

Client

traitement

Reponse

mise jour

ack

Fig. 1.3Répli ation passive

Dans un groupe de serveurs, le onsensus a une importan e apitale. Par exemple, pour s'assurerquetouslespro essussemettentd'a ordsurla ompositionde egroupe,un onsensus doitêtre établi.

Choixdu stylederépli ation Le hoixd'un stylederépli ationestguidépar lesbesoinsde l'appli ation,par lesressour esdisponibleset par lanaturedel'environnement de l'appli ation. La répli ation a tive est en général plus rapide en terme de temps de réponse. Le lient peut en eet se ontenter de la première réponse qu'il reçoit. En même temps, il faut supposer que tous les serveurs ont ee tué le même al ul et qu'ils ont des états internes équivalents. C'est l'hypothèse du déterminisme. Malheureusement, ette hypothèse n'est pas toujours vériée. La répli ationpassive ne né essitepasl'hypothèse du déterminismemais elle estplus exigeante en termedu nombre demessagesenvoyés. Unautrein onvénient de e style estletemps né essaire

au re ouvrement en as de défaillan e. Notons que pour e style, il est possible de dénir une syn hronisation périodique des états des répliques et d'optimiser la période de syn hronisation pour faire lemeilleur ompromisentre la onsommation desressour eset la ohéren e desétats desrépliques. Cesdeuxstyles nerépondentpasà touslesbesoinsen répli ation. D'autresstyles intermédiairesexistent omme par exemple larépli ationsemi-a tive [31 ℄ et larépli ation semi-passive[37℄.

1.3.4 Con lusion

Pour maximiser la sûreté de fon tionnement, les diérents types de redondan e peuvent êtreappliqués simultanément.L'expression desbesoinsentoléran eauxfautesestgénéralement di ile,même si ertaines méthodespeuvent avoiruneet positif.Con ernant les prin ipesdes misesen oeuvre,larépli ation estgénéralement préférée auxautreste hniques detoléran e aux fautes.Le hoixdelarépli ationestgénéralement argumenté parson oûtrelativementfaible et par les résultatsqu'elleore.

La toléran e aux faute a une relation très forte ave la distribution. La répli ation est un bon exemple qui montre ette relation. Cette forterelation et l'apport desintergi iels lors de la gestiondesproblèmes de distribution motivent l'emploide es te hnologies.

Le onsensus a une relation très étroite ave la toléran e aux fautes et ave la répli ation. Cependant,les appli ationsdu onsensusdépassentle adredelatoléran eauxfautesàla réso-lutiondeproblèmes générauxdesyn hronisationet d'a orddanslesenvironnementsdistribués. La pro haine se tiontraite eproblème fondamental.

1.4 Consensus

L'abstra tiondu onsensusestunebasefondamentalepermettantlarésolutiondelamajorité des problèmes d'a ord dans les environnements distribués. Nous ommençons par fournir une dénitionpré isede e problème.Ensuite,nousmontronsl'intérêt de etteabstra tion ainsique sa relation ave plusieurs te hniques de toléran e aux fautes. Enn, nous reprenons quelques résultatsthéoriquesliés à e problème et utilespourla suitedu manus rit.

1.4.1 Dénition

Soitunensemble depro essus

Π = {p

1

, p

2

, . . . , p

n

}

p

i

v

i

p

i

d

i

 Validité: toute valeurdé idée estl'une desvaleursproposées

 Terminaison : si au moinsun pro essus orre t lan e le onsensus, tout pro essus orre t dé ideau boutd'un temps ni

 A ord :la valeur dé idée estlamême pour tousles pro essus orre ts

Unpro essusestdit orre t s'iln'est pasenpanne.Dans ettedénition, le ritère d'a ord ne on erne que les pro essus orre ts. Dans un système réel, e ritère est insusant ar les pro essusin orre tssontautorisésàprendredesdé isionsmêmefaussesetàexé uterdesa tions pouvant être irréversibles au risque de  ontaminer le reste du système. On dénit alors le onsensus uniforme.

1.4.2 Besoins

Malgré sa formulation simple, le onsensus est un problème fondamental qui abstrait la majoritédesproblèmesd'a ordmêmeenlaprésen ededéfaillan es.L'abstra tiondu onsensus peut êtreutiliséed'unemanièreexpli itementou impli itement pard'autresproto olesd'a ord tolérants aux fautes. Le onsensus est aussi très utile pour la toléran e aux fautes dans les systèmesdistribuésen supportantla répli ation.

1.4.2.1 Utilisation expli ite

Le onsensus peut êtreutilisé par les entités appli atives devant onstruire une vision ohé-rente de l'état dusystème. Par exemple, unservi e de onsensusest requis par servi erépliqué ee tuant des opérations de le ture de apteurs. Ce besoin est toujours valable même si les diérentes entités utilisent le même apteur puisque les valeurs de sortie qu'il mesure peuvent varier ave le temps. Le onsensus peut également être utilisé expli itement pour syn hroniser lesrésultatsde al ulsdistribuésetpourprendredesdé isions ommunes omme l'éle tiond'un leader oul'ex lusionun pro essusdéfaillant.

1.4.2.2 Utilisation impli ite

L'abstra tion du onsensus peut être utilisée impli itement lors de la mise en oeuvre de plusieurs algorithmes d'a ord.C'est le asave leproblème de hoix de leader (leader ele tion) où un ensemble de pro essus doivent s'a order sur l'identité d'un leader. La relation entre le onsensuset ertainsproblèmesd'a ord ommel'appartenan eàungroupe(groupmembership) et la diusion atomique (atomi broad ast) a fait le sujet de plusieurs études théoriques. Par exemple [53℄ introduit la notion de ltres de onsensus ( onsensus lter)qui résolvent plusieurs problèmesd'a ord enadaptant un algorithmede onsensus.

1.4.2.3 Support de la toléran e aux fautes

Ceparagraphe illustrel'importan e du onsensus pour latoléran eauxfautes.Commenous l'avons pré isé i dessus, le onsensus est la base de plusieurs proto oles d'a ords tolérants aux fautes. Nous illustrons dans e paragraphe la relation entre le onsensus d'une part et les diérentsstyles derépli ation et laNMR(pour N ModularRedundan y) d'autre part.

Pourlarépli ationa tive,etdansunmodèle lient/serveur,ilestné essairepourlesrépliques dere evoir les invo ationsdansle même ordre. Les primitives de ommuni ations doivent alors avoir despropriétés d'ordre total. Il s'agit duproblème du multi ast atomique. Or e problème est onnu ommeéquivalentauproblèmedu onsensus[22℄.Larelationentrelarépli ationa tive et le onsensusest don très forte. La relation entre la répli ation passive et le onsensus a été également étudiée. Par exemple [37 ℄ larie ette relation à travers le on ept de la répli ation semipassive.Less hémasde typeNMRsont des asparti uliers deredondan e spatialeillustrant l'importan e du onsensus. Uneinstallation possible ettrès utiliséeduNMR estprésentéedansla gure1.4.En haut,le s hémanon répliqué utilise troisentités A,Bet C. Lesrésultats de al ul deAet deBsontles donnéesd'entréepour Bet C(respe tivement). Sil'un des omposantsest défaillant, lerésultat destroistraitements estpresquesûrement faux.Le s héma Triple Modular Redundan y réplique A, B et C et introduit une phase de vote à la n de haque étape des traitements. Les mé anismes de vote doivent également être répliqués ar eux aussi peuvent sourir de défaillan es. Cette étape de syn hronisation des entrées et des résultats au niveau

Fig.1.4 TripleModularRedundan y

de haque étape orrespondau onsensus. Lesar hite tures NMR sonttrès résistanteset peuvent tolérer touslestypesde défaillan es.

Ceparagraphe montre l'importan e du onsensus à travers quelques exemples d'utilisation. Nous nous sommes également intéressés à la relation entre le onsensus et la toléran e aux fautes,larépli ation et les hémaNMR sont les meilleurs exemplesillustrant e lien.Le pro hain paragraphe présente plusieurs élémentsde lathéoriedu onsensus.

1.4.3 Résultats théoriques

Lanaturedusystèmedénipar l'ensemble despro essuset eluides anaux de ommuni a-tionsestd'uneimportan e apitalelors delarésolutiondu onsensus. Par exemple,enl'absen e de défaillan es, le problème du onsensusadmet des solutions simple. Si on supposeun modèle de défaillan esmoinstrivial (pannefran he,et .) le problèmedevient plus ompliqué.

Danslesdeuxparagraphessuivants,nousnousintéressonsauxmodèlesdedéfaillan esetaux modèles de al ul.Cesmodèlesservent àexprimerlespropriétés vériéesparlesunités de al ul et liens de ommuni ations et permettent l'établissement de théorèmes et de preuvesautour de esalgorithmes.

1.4.3.1 Modèles de défaillan es

Dans les systèmes réels omme dans les modèles abstraits, les algorithmes distribués dé-pendent de la nature des anaux de ommuni ations. Il est par exemple utile de savoir si un message envoyé par un pro essus orre tsera reçu par le pro essus orre t destinataire ( ritère d'absen edepertes).Il estégalementutile depouvoirfairedeshypothèsesd'absen ede réation et de dupli ation(un message reçupar unpro essusa étéenvoyé par unautre et nerésulte pas d'undysfon tionnementdu anal).Généralementonutiliselesmodèlesde anauxQuasiFiables, vériant les hypothèsesd'absen e de pertes, de dupli ation et de réation. Ce modèle dé rit un omportement pro he de elui du proto ole TCP.Il existe également d'autresmodèles omme le modèle de anaux àpertes autorisant lapertedes messagesmaispasleur réation.

Con ernant le omportement des pro essus, on trouve dansla littérature plusieurs modèles quenousdétaillons dansleparagraphe suivant. Cesmodèles sonttrès importants enparti ulier pourdénir lafor ede l'adversaire.

Arrêt sur défaillan es A l'o urren e d'une défaillan e, le pro essus arrête son a tivité et prévient lesautres pro essus desonétat.

Pannes fran hes Ce modèle suppose que les fautes ont lieu lorsqu'un pro essus perd son étatinterneets'arrête. Engénéralilesttrès utilede seramenerau asoù le omposants'arrête immédiatementaprèsladéte tiond'uneerreur,eneetplusletempsentreapparitiondel'erreur etladéfaillan e(délaidelaten e)estlong, pluslare her hedesfautesetdeserreursestdi ile. Pannesparomission Dansle asd'unsystèmemodéliséparuneboîtenoireave desmessages entrants et sortants, la seule déviation par rapport aux spé i ations est la perte de messages entrants (omission enré eption) ou sortants (omissionen émission).

Pannesdetemporisation Unepannedetemporisationsemanifestelorsquel'exé utiond'une tâ hea lieu en dehorsde lafenêtre dutemps qui luiest dédiée.

Pannesbyzantines Danslemodèledepannesbyzantines, lesystèmepeutavoirtoutessortes de omportements (y ompris les omportements malveillants). Du point de vue théorique, e modèle est très intéressant : il représente le as pire, 'est dire les hypothèsesles plus défavo-rables.Engénéral, e modèleestutile pour lessystèmes ritiquespla és dansunenvironnement hostile(parexemple les fusées,les réa teurs nu léaires, et .).

1.4.3.2 Modèles de al ul et Syn hronisme

Lemodèlede al ul onsiste enunensembled'hypothèsessurle omportementtemporeldes pro essuset des anaux de ommuni ations qui les relient. On s'intéresse généralement à deux propriétés prin ipales:

 Rapidité relative despro essus.

 Tempsde transmissions des messages entre lespro essus.

Enutilisant esdeux propriétés ondénit lessystèmes syn hrones etasyn hrones.

Dénition 12 (Système syn hrone) Dans un système syn hrone, il existe une borne supé-rieure sur les délais detransmission des messageset sur les vitesses des pro essus.

Dénition 13 (Système asyn hrone) Dans un système asyn hrone, il n'y a pas d'hypothèse sur les vitessesrelatives des pro essus ni sur les délais de transmissions des messages.

La mise en oeuvre d'un syn hronisme total dans un système est très di ile. La résolution du problème de onsensus dans un système totalement asyn hrone est généralement di ile et n'est pas systématiquement possible. Dans la littérature, nous trouvons plusieurs modèles intermédiaires omme le modèle asyn hrone temporisé(Timed Asyn hronous) [46℄,et le modèle partiellement syn hrone (partiallysyn hronous) [36 ℄.

Malgrél'existen ede essystèmes,larésolutionduproblèmedu onsensusdanslessystèmes asyn hrones reste très intéressante de points de vues théorique et pratique. En eet, le modèle asyn hroneestsusammentgénériquepourpouvoirmodéliserplusieurssystèmesy ompris eux ayantdes ontraintestempsréel.Lemodèleasyn hronepeuteneetêtreadaptéàlamodélisation de e genre desystèmes[76℄.