Projet : ADP - adp

<body bgcolor="#FFFFFF" text="#000000" link="#9944EE" vlink= "#0000FF" alink="#00FF00"> <h2><a name="SECTION00064000000000000000" id= "SECTION00064000000000000000">Les problèmes d'accord dans les systèmes répartis</a></h2> <a name="ADP_resultats_module-6-PASR" id= "ADP_resultats_module-6-PASR"></a> <p><br /> <br /> <span class="textbf">Participants :</span> Emmanuelle Anceaume, Francisco Brasileiro, Udo Fritzke, Fabiola Greve, Jean-Michel Hélary, Michel Hurfin, Philippe Ingels, Jean-Pierre Le Narzul, Achour Mostéfaoui, Michel Raynal, Frédéric Tronel, Yun Wang.<br /> <br /></p> <p><strong>Mots clés :</strong> <i>algorithme réparti, résistance aux défaillances, duplication, communication de groupe, temps réel, consensus .</i></p> <h3>Résumé :</h3> <div class="ABSTRACT"> <i>Les travaux réalisés au cours de l'année 2000 sur les problèmes d'accord ont porté sur trois aspects. Le premier concerne la solvabilité du consensus (nouvelles familles de détecteurs de défaillances, introduction des probabilités et enfin utilisation de conditions sur l'ensemble des valeurs proposées). Le second aspect concerne l'utilisation du problème du consensus comme brique de base pour résoudre des problèmes d'accord. Enfin, le troisième aspect concerne l'élargissement du champ d'application de nos résultats en considérant les fautes byzantines et les contraintes temporelles. Les différents résultats obtenus ont, en partie, été intégrés à la plate-forme E<small>DEN</small> que nous développons.</i> </div> <p>Si aucune hypothèse supplémentaire n'est adoptée, il est prouvé que le problème d'accord élémentaire n'admet pas de solution déterministe dans un système réparti asynchrone dès lors qu'un processus au moins est susceptible de connaître une défaillance de type panne franche. Notre axe de recherche principal est donc naturellement consacré à l'étude des solutions permettant de contourner ce résultat d'impossibilité principalement les solutions déterministes fondées sur les détecteurs de défaillances.</p> <ul> <li> <b>Solvabilité du consensus</b> <p>Afin de contourner le résultat d'impossibilité nous avons suivi trois directions. Le première direction, initiée par Chandra et Toueg, consiste à enrichir le système sous-jacent par des détecteurs de défaillances. Dans [<a href="bibliographie_Toc.html#RT00" target= "contents">16</a>], nous nous intéressons à de nouvelles classes de détecteurs de défaillances dont la portée est restreinte. Plus précisément, on suppose que les propriétés de complétude (respectivement, d'exactitude) telles que définies classiquement par Chandra, Hadzilacos et Toueg ne portent pas sur l'ensemble des processus corrects mais seulement sur <span class= "MATH"><i>k</i></span> (respectivement, <span class= "MATH"><i>k'</i></span>) processus corrects parmi eux. On donne les conditions sous lesquelles ces détecteurs restreints sont équivalents à leurs homologues de portée maximale. Dans [<a href= "bibliographie_Toc.html#MR00b" target="contents">28</a>], les restrictions ne portent plus seulement sur les processus corrects mais sur tout processus. Les détecteurs de défaillance sont donc encore plus simples à mettre en oeuvre. [<a href="bibliographie_Toc.html#R00c" target="contents">46</a>] présente une introduction à des détecteurs de défaillances pour résoudre le problème de la diffusion fiable (plus simple à résoudre que le consensus). Ces derniers peuvent être mis en oeuvre moyennant une majorité de processus corrects.</p> <p>Une autre faÇon de contourner le résultat d'impossibilité consiste à affaiblir le problème (la terminaison est seulement probabiliste). Ben-Or a été le premier à trouver une solution probabiliste au problème du consensus binaire. Tout comme Aguilera et Toueg, nous avons exploré dans [<a href= "bibliographie_Toc.html#MRT00b" target="contents">26</a>] une approche hybride pour résoudre le problème du consensus. La solution proposée combine dans la même structure algorithmique deux sources possibles de terminaison. La première, déterministe, est fondée sur des détecteurs de défaillances. La seconde, probabiliste, est fondée sur le tirage aléatoire. A cause de sa composante probabiliste, le protocole hybride ne résout que le consensus binaire. Nous avons donc proposé un protocole simple qui résout le consensus multi-valué en utilisant un protocole de consensus binaire comme brique de base [<a href="bibliographie_Toc.html#MRT00a" target= "contents">14</a>]. Afin d'éviter cet empilement protocolaire, nous avons proposé un protocole de consensus multi-valué purement probabiliste [<a href= "bibliographie_Toc.html#EMR00" target= "contents">38</a>].</p> <p>Nous avons introduit une nouvelle approche dans la résolution du problème du consensus dans les systèmes répartis asynchrones [<a href= "bibliographie_Toc.html#MRR00" target="contents">43</a>]. Un vecteur d'entrée au problème du consensus est le vecteur constitué des <span class="MATH"><i>n</i></span> valeurs proposées par les <span class= "MATH"><i>n</i></span> processus. Si <span class= "MATH"><i>V</i></span> est l'ensemble des valeurs qui peuvent être proposées alors il existe <span class= "MATH">| <i>V</i>|<sup>n</sup></span> vecteurs d'entrée possibles au consensus. Une manière de circonvenir le résultat d'impossibilité consiste à n'autoriser qu'un sous-ensemble <span class="MATH"><i>S</i></span> de ces vecteurs. Le premier résultat que nous proposons est un protocole de consensus générique, paramétré par <span class="MATH"><i>S</i></span>, pour le modèle à mémoire partagée. Ce protocole garantit la propriété d'accord du consensus quel que soit le vecteur d'entrée. La propriété de terminaison est satisfaite soit en l'absence de défaillances soit lorsque le vecteur d'entrée appartient au sous-ensemble <span class= "MATH"><i>S</i></span>. Nous avons donné une condition nécessaire et suffisante que doit vérifier un sous-emsemble de vecteurs d'entrée pour résoudre le problème du consensus. Ces travaux effectués pour le modèle à mémoire partagée ont été étendus au modèle de communication par messages.</p> <p>Les pannes franches ne constituent qu'un cas particulier de comportement défaillant. Aussi, concevoir des protocoles répartis capables de résister à un comportement erroné arbitraire des processus constitue un réel défi, compte-tenu de la possibilité d'attaques malveillantes ou d'erreurs logicielles imprévues. Par conséquent, être capable de construire un protocole masquant les défaillances arbitraires au-dessus de protocoles tolérant les pannes franches constituerait une avancée majeure dans le domaine de l'ingénierie logicielle. Nous avons exploré une approche méthodologique générale permettant de telles constructions [<a href="bibliographie_Toc.html#BHR00a" target="contents">20</a>]. Elle s'applique au cas des protocoles dont tous les processus ont le même programme et échangent régulièrement des messages. Cette approche, modulaire, est basée sur l'encapsulation de la détection de défaillances de tout type dans des modules spécifiques. Elle peut constituer un point de départ pour la conception d'outils de transformation automatique. Cette méthodologie a été appliquée au problème du consensus [<a href="bibliographie_Toc.html#BHRT00" target="contents">19</a>].</p> </li> <li> <b>Solutions au problème du consensus</b> <p>Nous nous sommes principalement intéressés aux solutions déterministes s'appuyant sur des détecteurs de défaillances appartenant aux classes  <span class="MATH"><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span> et  <span class="MATH"><img width="8" height="10" align= "bottom" border="0" src="img3.png" alt= "$ \diamond$" /><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span>. La classe des détecteurs de défaillances forts (dénotée  <span class="MATH"><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span>) regroupe tous les détecteurs de défaillances qui ont pour propriétés de suspecter les processus défaillants (propriété de complétude) mais de ne pas suspecter au moins un des processus non défaillants (propriété d'exactitude). La classe des détecteurs de défaillances faibles (dénotée  <span class="MATH"><img width="8" height="10" align= "bottom" border="0" src="img3.png" alt= "$ \diamond$" /><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span>) regroupe quant à elle tous les détecteurs de défaillances qui vérifient la même propriété de complétude mais ne satisfont la propriété d'exactitude qu'après un laps de temps indéterminé. De fait, les détecteurs de défaillances appartenant à ces deux classes sont intrinsèquement non fiables puisqu'ils peuvent suspecter arbitrairement des processus corrects. Bien que faibles, les propriétés d'exactitude caractérisant ces deux classes sont suffisantes pour permettre de résoudre le problème du consensus si au moins un processus est correct (classe  <span class="MATH"><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span>) ou si au moins une majorité de processus est correcte (classe  <span class="MATH"><img width="8" height="10" align= "bottom" border="0" src="img3.png" alt= "$ \diamond$" /><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span>).</p> <p>Plusieurs protocoles de consensus fondés sur la classe  <span class="MATH"><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span> ont été conÇus par le passé, dont un très simple que nous avons proposé récemment [<a href="bibliographie_Toc.html#MR00a" target= "contents">27</a>] . Certains d'entre-eux requièrent systématiquement <span class="MATH"><i>n</i></span> étapes de calcul (<span class="MATH"><i>n</i></span> étant le nombre de processus), chaque étape nécessitant l'émission de <span class="MATH"><i>n</i></span> ou <span class="MATH"><i>n</i><sup>2</sup></span> messages. D'autres protocoles permettent une prise de décision au plus tÔt (dans ce cas, le nombre d'étapes de calcul dépend du nombre de défaillances détectées) mais requièrent <span class="MATH"><i>n</i><sup>2</sup></span> messages à chaque étape de calcul. Une de nos contributions [<a href= "bibliographie_Toc.html#GHMR00" target= "contents">21</a>,<a href="bibliographie_ct.html#GHMR00b" target="contents">22</a>] a consisté à définir un protocole de consensus fondé sur la classe  <span class="MATH"><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span> qui permet des décisions au plus tÔt. Chaque étape de calcul nécessite <span class= "MATH">3(<i>n</i> - 1)</span> messages. De fait, le protocole que nous proposons est particulièrement efficace en temps et en nombre de messages. Ce protocole a été adapté aux détecteurs de défaillances de la classe  <span class="MATH"><img width="8" height="10" align= "bottom" border="0" src="img3.png" alt= "$ \diamond$" /><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span> et généralisé afin de permettre, lorsque cela est nécessaire, une nouvelle réduction du nombre d'étapes de calcul au prix bien évidemment d'un accroissement du nombre de messages échangés par étape. Le compromis qui résulte du choix d'un schéma d'échange de messages peut être modifié à chaque pas d'itération. Ainsi le nombre de messages échangés par pas de communication peut varier de O(<span class="MATH"><i>n</i></span>) (schéma centralisé) à O(<span class="MATH"><i>n</i><sup>2</sup></span>) (schéma totalement décentralisé) [<a href= "bibliographie_Toc.html#HMMR00" target= "contents">41</a>].</p> <p>En plus de ce premier degré de liberté, nous proposons dans [<a href="bibliographie_Toc.html#HMR00" target= "contents">42</a>], un protocole générique qui peut s'adapter aisément aux deux classes de détecteurs de défaillances  <span class="MATH"><img width="8" height="10" align= "bottom" border="0" src="img3.png" alt= "$ \diamond$" /><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span> et  <span class="MATH"><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span>. Différentes instantiations du protocole général permettent de retrouver des protocoles existants (par exemple, celui de Chandra et Toueg) ainsi que de nouveaux protocoles. Cette approche, également intéressante par son aspect méthodologique, permet de comprendre les fondements conceptuels de cette famille de protocoles. Ceci est rendu possible par la caractérisation de deux ensembles de processus qui, pour un pas d'itération donné, assurent respectivement les propriétés de vivacité et de sûreté. Cette approche permet également de montrer que, contrairement a une idée admise, les estampilles utilisées dans le protocole de Chandra et Toueg peuvent être bornées.</p> <p>Un des défauts des protocoles fondés sur la classe  <span class="MATH"><img width="8" height="10" align= "bottom" border="0" src="img3.png" alt= "$ \diamond$" /><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span> réside dans le fait qu'à une étape donnée seule la valeur du coordonnateur peut être décidée. Si nous considérons le cas favorable où tous les processus proposent la même valeur, il est malgré tout possible de ne pas décider avant longtemps si la propriété d'exactitude met du temps à se vérifier. Nous avons donc défini un protocole [<a href= "bibliographie_Toc.html#BGMR00" target="contents">36</a>] qui permet aux processus de décider en une étape de communication dans des circonstances favorables. Celles-ci apparaissent lorsque (<span class= "MATH"><i>n</i> - <i>f</i> )</span> processus proposent la même valeur (où <span class="MATH"><i>f</i></span> est le nombre maximal défaillances). Le protocole requiert la condition <span class="MATH"><i>f</i> < <i>n</i>/3</span>. Il est montré que, dans le cas général, cette condition est nécessaire. Cette condition peut être affaiblie à <span class="MATH"><i>f</i> < <i>n</i>/2</span> au prix d'une étape de communication supplémentaire.</p> </li> <li> <b>Autres problèmes d'accord</b> <p>Le consensus est un problème d'accord élémentaire dont la définition simple est unanimement reconnue par tous. Il s'agit d'un problème purement théorique qui permet d'abstraire différents problèmes d'accord. La simplicité de ce problème permet, lors de son étude, de se focaliser uniquement sur le résultat d'impossibilité qui est associé à tout problème d'accord. En pratique, ceci ne signifie pas pour autant qu'un service de consensus est le dénominateur commun idéal à partir duquel on peut toujours dériver des solutions efficaces à des problèmes d'accord plus complexes. Diverses variantes au problème du consensus ont donc été explorées. Le but poursuivi est de concevoir une brique de base parfaitement adaptée au problème d'accord que l'on désire résoudre.</p> <p>Parmi les variantes possibles au problème du consensus, nous avons étudié le problème du calcul d'une donnée globale cohérente (un vecteur comportant une entrée par processus). L'importance du problème nous a conduit à rechercher un protocole spécifique, efficace en temps, utilisable uniquement si on dispose de détecteurs de défaillances parfaits [<a href= "bibliographie_Toc.html#HHMRT00b" target= "contents">12</a>,<a href="bibliographie_ct.html#HHMRT00" target="contents">23</a>]. Ce protocole permet des décisions au plus tÔt. Soit <span class= "MATH"><i>t</i></span> le nombre maximal de pannes pouvant se produire et soit <span class= "MATH"><i>f</i></span> le nombre de pannes effectives (<span class="MATH"><i>f</i> < <i>t</i></span>). Dans le pire des cas, le protocole termine après  <span class="MATH"><i>min</i>(2<i>f</i> + 2, <i>t</i> + 1)</span> tentatives. De plus, ce protocole ne nécessite pas d'échange d'information sur la perception locale des pannes. Ce travail présenté à la conférence ICDCS'00 (International conférence on Distributed Computing Systems) s'est vu attribué le "Best Paper Award".</p> <p>Le problème du "<span class="MATH"><i>k</i></span>-Set Agreement" généralise le problème du consensus en ce sens qu'il ne limite pas l'ensemble des valeurs de décision à une seule mais à <span class="MATH"><i>k</i></span> valeurs, il est de ce fait moins dur à résoudre. Dans un système asynchrone composé de <span class= "MATH"><i>n</i></span> processus et où au plus <span class="MATH"><i>f</i></span> d'entre eux peuvent être défaillants, le problème du "<span class= "MATH"><i>k</i></span>-Set Agreement" peut être facilement résolu si <span class="MATH"><i>f</i> < <i>k</i></span>. Il a par ailleurs été démontré qu'aucune solution déterministe n'existe lorsque <span class= "MATH"><i>f</i> <img width="13" height="22" align= "middle" border="0" src="img4.png" alt="$ \geq$" /> <i>k</i></span>.</p> <p>Nous avons montré dans [<a href= "bibliographie_Toc.html#MR00b" target="contents">28</a>] que les détecteurs de défaillances de Chandra et Toueg ne sont pas minimaux pour résoudre le ``<span class= "MATH"><i>k</i></span>-Set Agreement'' nous avons donc étudié une approche fondée sur les détecteurs de défaillances à portée réduite. Dans [<a href= "bibliographie_Toc.html#MR00d" target="contents">45</a>] nous présentons une approche probabiliste pour résoudre ce problème. Le protocole proposé ne nécessite pas la connaissance <span class="textit">a priori</span> de l'ensemble des valeurs proposables. Dans les deux cas, nous avons mis en évidence un aspect contre-intuitif du problème : plus ``k'' augmente moins on tolère de défaillances. Cependant, on gagne sur l'aspect impossibilité puisque dans la solution déterministe on a besoin de détecteurs de défaillances plus faibles. Tout comme dans le cas du consensus, on a présenté dans [<a href="bibliographie_Toc.html#MR00c" target= "contents">44</a>] un protocole fondé sur une restriction sur la composition de l'ensemble des valeurs proposées qui permet de résoudre ce problème quel que soit <span class="MATH"><i>f</i></span>. En l'occurrence, nous avons montré que s'il existe parmi toutes les valeurs proposées un sous-ensemble de <span class= "MATH"><i>k</i></span> valeurs proposées par plus de  <span class="MATH">(<i>kn</i> + <i>f</i> )/(<i>k</i> + 1)</span> processus alors le problème du "<span class= "MATH"><i>k</i></span>-Set Agreement" a une solution.</p> </li> <li> <b>Prise en compte des contraintes temporelles</b> <p>Notre objectif est de maîtriser la terminaison des protocoles exécutés en permettant de gérer au mieux une durée maximale d'exécution.</p> <p>Un protocole fondé sur l'ordre causal garantit que si deux messages sont causalement liés et ont les mêmes destinataires, alors ces messages sont remis (à l'application) selon leur ordre d'émission. Cette garantie permet de simplifier sensiblement le développement d'applications distribuées. Pour empêcher la violation de l'ordre causal, deux techniques existent : soit on force un message à attendre les messages ``(en retard'') dont il dépend, soit les messages ``en retard'' sont annulés. Il est clair que pour un système temps réel, la première approche n'est pas satisfaisante. En effet dès qu'un message dépasse son échéance, tous les messages qui en dépendent vont forcément dépasser leur échéance. Nous proposons dans [<a href="bibliographie_Toc.html#RBAR00" target="contents">31</a>] une abstraction originale de l'ordre causal fondé sur les échéances des messages. Deux implémentations sont proposées dans le contexte des communications de groupe (diffusion générale et diffusion sélective).</p> </li> <li> <b>Gestion de la composition d'un groupe</b> <p>Le concept de groupe est de plus en plus utilisé pour concevoir des couches logicielles permettant de supporter l'exécution d'applications réparties fiables. Ce paradigme recouvre deux services de base, à savoir, un service de gestion de la composition du groupe et un service de communication de groupe. Un groupe est un ensemble de processus coopérant à la réalisation d'une tâche commune. Étant donné que de nouveaux processus peuvent souhaiter rejoindre le groupe, que des membres du groupe peuvent souhaiter le quitter ou connaître des défaillances de type panne franche, la composition du groupe doit pouvoir évoluer de faÇon dynamique. L'ensemble des processus qui constituent le groupe à un instant donné est appelé la vue courante du groupe.</p> <p>Dans [<a href="bibliographie_Toc.html#GHRT00" target="contents">40</a>], nous nous intéressons aux problèmes de la spécification et du développement d'un service de gestion de la composition du groupe ne tolérant qu'une partition primaire (une seule vue à un instant donné). Nous proposons tout d'abord une spécification du problème. Ensuite, nous présentons un protocole qui satisfait cette spécification dans un système réparti asynchrone équipé de détecteurs de défaillances. Le service de gestion de la composition du groupe via une partition primaire est obtenu en spécialisant de manière appropriée un protocole d'accord générique. Pour cela, nous avons défini un cadre général dans lequel la définition d'un problème d'accord particulier est fixée par le biais de 6 paramètres. Le protocole proposé par Chandra et Toueg pour résoudre le problème du consensus à l'aide de détecteurs de défaillance appartenant à la classe  <span class="MATH"><img width="8" height="10" align= "bottom" border="0" src="img3.png" alt= "$ \diamond$" /><img width="12" height="12" align= "bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span> constitue l'ossature du protocole générique proposé. Les extensions offertes par ce nouveau service d'accord permettent notamment aux membres d'un groupe de processus de décider unanimement sur une collection de valeurs proposées (plutÔt que sur une seule des valeurs proposées) tout en autorisant les processus à effectuer de multiples propositions (plutÔt qu'une seule au démarrage du protocole d'accord).</p> </li> </ul> </body>