Projet : ADP - adp

<body bgcolor="#FFFFFF" text="#000000" link="#9944EE" vlink= "#0000FF" alink="#00FF00"> <h2><a name="SECTION00034000000000000000" id= "SECTION00034000000000000000">Les problèmes d'accord dans les systèmes répartis</a></h2> <a name="ADP_fondements_module-3-PASR" id= "ADP_fondements_module-3-PASR"></a> <p><strong>Mots clés :</strong> <i>algorithme réparti, tolérance aux défaillances, temps réel, communication de groupe, consensus .</i></p> <h3>Résumé :</h3> <div class="ABSTRACT"> <i>Dans un système réparti asynchrone, il est important de pouvoir concevoir des applications tolérant les défaillances tout en garantissant le respect de contraintes temps-réel. Le concept de groupe s'avère dans ce cas particulièrement intéressant. Développer les services offerts dans un groupe en utilisant comme brique de base une solution au problème du consensus est une approche novatrice présentant de nombreux avantages. En particulier, le résultat d'impossibilité de Fischer-Lynch-Paterson peut être circonscrit à ce niveau.</i> </div> <p>Considérer qu'un système réparti est asynchrone est une hypothèse attrayante (car plus générale et réaliste). Cependant, elle semble difficilement conciliable avec la prise en compte de critères de qualité de service tels que la tolérance aux défaillances et les contraintes temps-réel. Un des axes de recherche du projet <small>ADP</small> est consacré à la conception et au développement de services permettant de répondre efficacement à ces nouvelles exigences dans un environnement distribué asynchrone.</p> <p>La sûreté de fonctionnement ne peut être garantie que pour des types de défaillances préalablement identifiés. Dans le cadre de cette activité, nous considérons les défaillances de type panne franche (crash) : chaque processus peut, soit s'exécuter correctement, soit s'interrompre brutalement (et définitivement) suite à une panne (ou une agression extérieure). A condition de pouvoir coordonner efficacement l'activité des processus dupliqués, le concept de groupe se révèle être une excellente technologie <i>middleware</i> pour concevoir des mécanismes de tolérance aux défaillances. Pour mettre en oeuvre ce concept, il convient d'apporter des solutions efficaces à divers problèmes d'accord entre processus. En particulier, les processus appartenant à un même groupe doivent être unanimes en ce qui concerne l'identité des membres qui le composent (membership) et l'ordre dans lequel les messages qui leurs sont adressés seront délivrés (diffusion ordonnée).</p> <p>Des travaux récents ont mis en évidence le lien qui existe entre les problèmes nécessitant l'obtention d'un accord (élection, diffusion ordonnée, validation atomique non-bloquante, gestion des membres d'un groupe, etc.) et le problème abstrait du consensus. De fait, ce problème élémentaire est l'objet de nombreux travaux de recherche depuis quelques années. Le résultat le plus important est malheureusement négatif [<a href= "bibliographie_Toc.html#FLP85" target= "contents">FLP85</a>] : ce problème fondamental ne peut pas être résolu dans des systèmes asynchrones dès lors que les processus sont susceptibles de stopper prématurément leurs exécutions. Afin de surmonter ce résultat d'impossibilité, Chandra et Toueg [<a href= "bibliographie_Toc.html#CT96" target="contents">CT96</a>] ont augmenté le modèle asynchrone en introduisant la notion de détecteur de défaillances. Un détecteur est associé à chaque processus et est chargé de détecter les défaillances externes. La mise en oeuvre du mécanisme de détection se fait en définissant des délais de garde : un processus est suspecté s'il ne s'est pas manifesté avant l'expiration du délai de garde. Cela signifie que (1) la détection d'une défaillance réelle est généralement différée et que (2) un détecteur de défaillances peut commettre des erreurs en suspectant à tort un processus d'avoir stoppé son exécution. Chandra et Toueg définissent huit classes de détecteurs de défaillances en caractérisant chacune d'entre elles par une propriété de complétude et une propriété d'exactitude. Une propriété de complétude définit des contraintes concernant la détection des processus réellement arrêtés tandis que la propriété d'exactitude vise à limiter les suspicions erronées que peut commettre un détecteur de défaillances.</p> <p>Parmi ces classes, la classe dénotée  <span class="MATH"><img width="12" height="10" align="bottom" border="0" src="img1.png" alt="$ \Diamond$" /><img width="12" height="12" align="bottom" border="0" src="img2.png" alt= "$ \mathcal {S}$" /></span> est particulièrement intéressante puisqu'il s'agit de la classe la plus faible permettant de résoudre le consensus [<a href="bibliographie_Toc.html#CHT96" target="contents">CHT96</a>]. Cette classe est caractérisée par une propriété de complétude forte (tout processus défaillant finit par être suspecté de faÇon permanente par tout processus correct) et une propriété de exactitude faible inéluctable (il existe un instant à partir duquel un processus correct ne sera plus jamais suspecté par aucun processus correct). En s'appuyant sur des détecteurs de défaillances de cette classe et à condition que les canaux de communication soient fiables et qu'une majorité de processus ne subit pas de défaillances, des algorithmes déterministes permettent de résoudre le problème du consensus. Tous s'appuient sur le paradigme du coordinateur tournant mais diffèrent par leur complexité en temps et en nombre de messages. L'utilisation de tels algorithmes comme briques de base dans la résolution de problèmes d'accord, et par conséquent leur utilisation dans la gestion des groupes de processus dupliqués, est actuellement un axe de recherche important.</p> <p>Comme indiqué précédemment, nous souhaitons intégrer la notion de contrainte temps-réel dans les solutions que nous proposons aux problèmes d'accord ainsi que dans les services de duplication mis en oeuvre pour garantir la sûreté de fonctionnement. Prendre en compte des contraintes temps-réel nécessite ``à un niveau ou à un autre'' de considérer le temps physique. C'est pour cela que nous comptons remplacer le modèle ``totalement'' asynchrone par le modèle ``asynchrone temporisé''. Ce modèle réaliste est défini par la caractéristique suivante. Tout processus peut définir des délais maximaux sur les temps de transfert et de traitement. Mais comme le support est asynchrone, ces délais peuvent être violés : dans ce cas, l'application en est avertie (c'est la notion de <i>fail-awareness</i> décrite dans [<a href="bibliographie_Toc.html#FC96" target= "contents">FC96</a>]) et réagit par un traitement d'exception approprié.</p> <p>La définition de ``bons'' délais, dépend du support et de sa charge en ``régime de croisière''; les manquements à ces délais n'apparaissent qu'en périodes d'instabilité dues à des surcharges occasionnelles ou à l'occurrence de situations imprévisibles.</p> </body>