Un protocole de tolérance aux pannes pour objets actifs non préemptifs

Transcription

1 Un protocole de tolérance aux pannes pour objets actfs non préemptfs Françose Baude Dens Caromel Chrstan Delbé Ludovc Henro Equpe Oass, INRIA - CNRS - I3S 2004, route des Lucoles F Sopha Antpols {francose.baude,dens.caromel,chrstan.delbe,ludovc.henro}@nra.fr RÉSUMÉ. Les protocoles de ponts de reprses nduts par messages semblent être l approche la plus adaptée aux applcatons s exécutant sur des systèmes hétérogènes avec un fable taux de panne. Mas ces protocoles supposent qu l sot toujours possble de prendre un pont de reprse de manère préemptve, avant la prse en compte d un message.nous proposons donc, dans le cadre d un modèle à objets actfs, un protocole de tolérance aux pannes par ponts de reprse nduts par messages adapté à la non-préemptvté des processus. A la dfférence de nombreux protocoles exstants, ce protocole assure la cohérence forte des lgnes de recouvrement formées, et permet une reprse complètement asynchrone du système répart en cas de panne. ABSTRACT. Communcaton nduced checkpontng protocols seem to be the most adapted approach for applcatons runnng on heterogenenous systems wth low falure rate. However, these protocols make the assumpton that t s always possble to preemptvely trgger a checkpont before delverng a message.we offer, wthn the framework of an actve objects model, a communcaton nduced checkpontng protocol, adapted to the non-preemptblty of processes. Unlke many protocols, ths one ensures strong consstency of recovery lnes, and enables a fully asynchronous recovery of the dstrbuted system after a falure. MOTS-CLÉS : tolérance aux pannes, ponts de reprse, journalsaton de messages, objets actfs. KEYWORDS: fault tolerance, checkpontng, message loggng, actve objects. RTSI - TSI. Volume 24 n o 10/2005, pages 1199 à 1226

2 1200 RTSI - TSI. Volume 24 n o 10/ Introducton La tolérance aux pannes dans les systèmes réparts est un domane qu a été largement étudé depus une trentane d années (Conan et al., 1998; Elnozahy et al., 1999). Ces études ont donné leu à un nombre mportant de protocoles. Pourtant, on trouve encore à ce jour très peu d ntergcels de communcaton ntégrant de la tolérance aux pannes par recouvrement arrère 1. Ce manque peut s explquer par la chute de performance qu entraînent certans protocoles de tolérance aux pannes, mas auss par la complexté de mse en œuvre dans des condtons réelles des protocoles proposés : ls sont le plus souvent théorques, et requèrent pour fonctonner des hypothèses qu ne sont pas compatbles avec les systèmes concrets. Nous nous ntéressons aux applcatons s exécutant sur des systèmes hétérogènes avec un fable taux de panne. Les protocoles de ponts de reprses nduts par messages semblent être l approche la plus adaptée à ce contexte. Ces protocoles supposent qu l sot toujours possble de prendre un pont de reprse avant la prse en compte d un message. Cette hypothèse mplque donc la préemptvté des processus : l actvté dot pouvor être stoppée à tout nstant durant l exécuton. Dans le cas de l ntergcel ProActve (Caromel et al., 1998), un ntergcel de communcaton 100% Java, les actvtés communquantes ne peuvent pas être nterrompues de manère préemptve car elles sont composées en parte d un thread Java. Cependant, l exste des états appelés états stables dans lesquelles un pont de reprse est possble. Dans cet artcle, nous adaptons un protocole de tolérance aux pannes par ponts de reprse nduts par messages pour la bblothèque ProActve : les ponts de reprses déclenchés par la récepton d un message peuvent être repoussés jusqu au prochan état stable. De plus, le protocole dot mantenr l ordre FIFO pont-à-pont des messages qu est une caractérstque nhérente du modèle ProActve. Tolérance aux pannes dans les systèmes réparts On dstngue prncpalement deux famlles de protocoles utlsant les ponts de reprse : elles se dfférencent sur la façon de synchronser les ponts entre eux afn de former des états globaux cohérents, ou lgne de recouvrement. La premère approche synchronse de manère explcte les prses de ponts à l ade de messages spécfques. L artcle fondateur (Chandy et al., 1985) propose un tel algorthme, basé sur l utlsaton de messages «marqueurs». La deuxème approche utlse les messages de l applcaton pour coordonner les ponts de reprse de manère à former des états globaux cohérents. On parle de ponts de reprse nduts par messages (Bratco et al., 1984; La et al., 1987). 1. On parle de tolérance aux pannes par recouvrement arrère pour la dstnguer de la tolérance aux pannes par réplcaton (Cooper, 1985).

3 Tolérance aux pannes pour objets actfs 1201 D autre part, la tolérance aux pannes peut être obtenue par journalsaton des messages : tous les messages qu crculent sont enregstrés pour pouvor être rejoués en cas de panne. Il exste tros types de journalsaton : pessmste (Bouteller et al., 2003), optmste (Strom et al., 1985) et causale (Alvs et al., 1998). Ces approches se dstnguent par le type d nformaton enregstré sur support stable et la fréquence de ces enregstrements. Ben que la journalsaton de message sot ntrnsèquement adaptée au cas des processus non-préemptfs, les proprétés des protocoles par ponts reprses nduts par messages les rendent plus adaptés à nos besons. Le protocole proposé par Chandy et Lamport (Chandy et al., 1985) est adapté aux processus non-préemptfs mas mplque un surcoût trop mportant en communcatons. Les ponts de reprse forcés dans les protocoles de La et Yang (La et al., 1987) ou de Bratco (Bratco et al., 1984) mplquent une préemptvté sur les processus. Dans le contexte de processus nonpréemptfs, pour mplémenter une prse de vue cohérente du système, l suffrat que le processus recevant un message déclenchant un pont de reprse forcé repousse la prse en compte de ce message au prochan état stable. Mas ce décalage ntrodut des problèmes de cohérence des états globaux formés et peut affecter l ordre des messages, en partculer dans le cadre de communcatons FIFO. Nous proposons donc une adaptaton du protocole de Bratco aux processus nonpréemptfs : un protocole ndut par messages hybrde utlsant un mécansme de journalsaton optmste pour rendre cohérent les états globaux formés par des ponts de reprse retardés. 2. Objets actfs en Java : ProActve Notre traval se place dans le cadre de la bblothèque ProActve. Nous proposons c une rapde présentaton de cette bblothèque, et une analyse des dfférentes caractérstques qu auront un mpact fort dans la concepton d un protocole de tolérance aux pannes adapté Présentaton ProActve est une bblothèque Java qu permet la programmaton d applcatons parallèles et dstrbuées. Elle repose sur un modèle MIMD (Mutlple Instructons, Multple Data) et sur la noton d objet actf (Caromel, 1993), c est-à-dre un objet qu possède une actvté propre. Elle fournt en partculer : des appels de méthodes asynchrones avec futurs transparents, c est-à-dre une communcaton par messages (requête et réponse), de la moblté fable, c est-à-dre non préemptve, des communcatons de groupe.

4 1202 RTSI - TSI. Volume 24 n o 10/2005 ProActve utlse un protocole à méta-objet pour réfer les objets et les appels de méthodes entre objets actfs (Caromel et al., 2001). On appellera «objet réfé» l objet Java standard rendu actf par l ajout de méta-objets, et «objet actf» l ensemble composé de l objet réfé et des méta-objets. La réfcaton des communcatons permet d avor des communcatons asynchrones : lorsqu un objet actf appelle une méthode sur un autre objet actf, cet appel est réfé en une requête qu est envoyée au récepteur pour y être stockée dans sa queue de requêtes et qu sera serve ultéreurement. Lors de cette émsson, s la requête nécesste le retour d un résultat, l objet émetteur reçot un futur pour lu permettre de contnuer son exécuton. Ce futur correspond à une promesse de réponse, qu sera mse à jour de façon transparente lorsque le résultat sera dsponble. Cependant, s un objet tente d utlser un futur avant qu l sot ms à jour, alors l entre dans un état d attente par nécessté, c est-à-dre que son fl d exécuton est suspendu jusqu à ce que le futur sot ms à jour. S la réfcaton des communcatons permet d avor des appels de méthodes asynchrones, un rendez-vous est conservé : lors de l appel d une méthode d un objet vers un autre, l émetteur ne peut contnuer son exécuton que lorsque la requête créée est effectvement déposée dans la queue de requêtes du récepteur. De même, lors du retour d un résultat, l émetteur de ce résultat ne peut contnuer son exécuton que lorsque le futur attendant ce résultat a ben été ms à jour. On notera dans la sute : Q,j une requête de vers j R j, une réponse de j vers M,j un message de vers j, ndfféremment une requête ou une réponse Q rcv la queue des requêtes en attente de servce dans l objet actf Proprétés Changements d état ProActve réfe les communcatons en objets de type requête ou réponse, et utlse des futurs du côté appelant, et une queue de requêtes du côté appelé. Cette matéralsaton des appels va permettre au protocole de faclement les manpuler. Par exemple, nous pourrons enregstrer certanes communcatons qu devraent être rejouées en cas de panne du système, ou encore modfer la queue de requêtes d un objet pour nfluer sur l ordre de récepton des requêtes et ans conserver l ordre global en cas de rejeu. La récepton d une requête ou d une réponse par un objet actf n a pas le même mpact au nveau des objets eux-mêmes : la récepton d une requête n a d effet sur les objets qu au nveau méta (seule la queue de requêtes va être modfée). La récepton d une réponse modfe en plus les objets au nveau de l applcaton (mse à jour d un futur). Cette mse à jour va très certanement modfer l état de l objet

5 Tolérance aux pannes pour objets actfs 1203 au nveau applcatf, comme par exemple mettre à jour une varable d nstance de cet objet. On note qu une réponse reçue correspond forcément à un futur chez le récepteur et, s ce n état pas le cas, cette réponse serat gnorée par ce récepteur. On note que s l ordre des réceptons de requêtes est ben sûr détermnant pour l état de l objet actf pusqu l peut ndure un ordre de servce, une étude formelle du modèle de ProActve (Caromel et al., 2004) a montré que l ordre de récepton des réponses n a absolument aucune nfluence sur l état d un objet actf Exstence d états stables ProActve est entèrement écrt en Java : un objet actf est en fat un ensemble d objets Java standards. Nous allons donc pouvor utlser la séralsaton (SunMcrosystems, 1997) proposée par Java pour avor une représentaton des objets qu pusse être stockée et récupérée en cas de reprse du système. Lorsqu on va voulor réalser un enregstrement d un objet, on va le séralser, mas l objet Thread représentant le fl d exécuton de l actvté ne peut pas fare parte de l enregstrement. La conséquence est que les prses de ponts de reprse ne seront possbles qu à certans moments de l exécuton, moments que l on appellera états stables. Ces moments sont ceux pendant lesquels l objet actf n est pas en tran de servr une requête, comme par exemple entre deux servces consécutfs. On notera stablestate() un prédcat, vra s l objet actf est dans un état stable, c est-à-dre dans un état dans lequel un pont de reprse peut être réalsé Rendez-vous et Communcatons FIFO Les communcatons (requêtes et réponses) dans ProActve sont asynchrones avec rendez-vous. La prncpale conséquence est que les communcatons entre objets actfs sont systématquement FIFO pont à pont. De plus, ce rendez-vous étant réalsé à l ade d un message d acquttement, l est possble de renvoyer à l émetteur à la fn de ce rendez-vous une nformaton sur l état du récepteur au moment de la récepton du message Promesses de requêtes Nous ntrodusons dans ProActve un nouveau mécansme : les promesses de requête. Ces promesses sont en fat des requêtes «vdes», qu dovent être remples avec une requête normale provenant d un émetteur donné ; une promesse de requête content donc smplement l dentfcateur de l émetteur attendu. On notera Q awated,j une promesse de requête de l émetteur qu se trouve dans la queue de requêtes de j. Le servce d une promesse de requête Q awated,j peut déclencher une attente par nécessté. S j tente de servr cette requête, alors l est mmédatement bloqué. Lorsqu une requête Q,j arrve de, sot j est en attente sur une Q awated,j Q,j ; : j est alors débloqué et sert la requête

6 1204 RTSI - TSI. Volume 24 n o 10/2005 sot j n est pas en attente mas l exste dans sa queue de requête des Q awated,j : la premère rencontrée dans l ordre de la queue de requêtes est remplacée par Q,j ; sot j n est pas en attente et l n exste pas de Q awated,j dans la queue de requêtes de j : Q,j est placée normalement en fn de queue de requêtes. L utlsaton de promesses de requête permet de forcer de façon paresseuse et asynchrone l ordre de récepton des requêtes en cas de reprse du système Hypothèses Types de défallance Les pannes tolérées sont les pannes franches ; les objets actfs sont de types falstop (Schlchtng et al., 1983), c est-à-dre que toute défallance se tradut par un arrêt complet de l actvté de l objet. Cet arrêt est supposé être détecté au bout d un temps fn arbtrarement long par un détecteur de défallance de type (Chandra et al., 1996). Enfn, nous supposerons qu l exste toujours une machne hôte dsponble sur laquelle redémarrer un objet actf défallant Support de stockage Il dot exster un support de stockage stable accessble par tous les objets actfs du système. Ce support stocke les ponts de reprse et d autres nformatons. Il peut cependant être dstrbué : pour évter une trop grande contenton, l peut exster pluseurs supports stables Processus de reprse Il dot exster un processus partculer appelé «processus de reprse» qu a accès au support de stockage stable ans qu à l ensemble des objets actfs formant le système Serveur de localsaton Le système utlse un serveur de localsaton pour rétablr les connexons entre les objets qu sont tombés en panne (et qu ont donc été replacés dans le système) et les autres. Le comportement de ce serveur est smple. Il est nformé : à chaque nouveau placement par le processus de reprse d un objet tombé en panne de la nouvelle localsaton de ce derner, sous forme d un couple (dentfant unque de l objet actf, nouvelle localsaton) à chaque reprse après panne d un objet actf de la reprse de l actvté de cet objet. De cette manère, le serveur de localsaton pourra détermner s un objet est naccessble parce qu l est en panne, ou parce qu l est en cours de reprse. Lorsqu un objet tente de communquer avec un autre et que cette communcaton échoue, l ne va pas tout de sute déclencher une procédure de reprse. Il envoe

7 Tolérance aux pannes pour objets actfs 1205 d abord une requête de relocalsaton au serveur contenant l dentfant de l objet recherché. Son appel est bloqué par le serveur tant que l objet recherché est en cours de reprse. S le serveur renvoe une nouvelle localsaton, l objet tente à nouveau de communquer. S la localsaton renvoyée est la même que celle connue de l objet, ou s aucune localsaton n est renvoyée, alors une procédure de reprse est lancée. Le processus de reprse ans que le serveur de localsaton dovent être protégés contre les fautes, par exemple en étant réplqués, pusqu ls ont un comportement smple Notatons Nous décrvons c comment nous allons schématser ces proprétés dans la représentaton temporelle d une exécuton réparte avec ProActve. X(Q A ) Q A R A j Fgure 1. Objets actfs communquants On a sur la fgure 1 deux objets actfs et j qu communquent. L objet actf j appelle une méthode sur l objet : une requête (Q A ) est émse de j vers, pus cette requête est serve sur l objet (X(Q A ), exécuton de la requête Q A ), et enfn une réponse (R A ), résultat du servce de la requête, est envoyée de vers j. Les rectangles pontllés représentent des moments où l objet est en servce de requête, et n est donc pas dans un état stable : les états stables sont les moments où l exécuton n est représentée que par une smple lgne. On notera que les servces de requêtes peuvent être annotés ou non avec la requête serve (c, X(Q A ) sur ). On vot que la récepton d une requête (c, Q A ) «n entre pas» dans le rectangle : la récepton de requête n a pas d mpact sur l état de l objet au nveau applcatf. À l nverse, la récepton d une réponse (R A ) entre dans le rectangle pour sgnfer la modfcaton potentelle de l objet au nveau applcatf. Nous rajoutons dans cette notaton le pont de reprse (fgure 2). Sa représentaton nclut son numéro (n), l état de la queue de requêtes de l objet actf en ndce ([Q A, Q C, Q D ]), ans qu une autre queue de messages en exposant (]Q B, R E [). Cette autre queue sera ajoutée à chaque objet actf pour les besons du protocole. Elle contendra (cf ) tous les messages applcatfs qu devront être rééms avant le

8 1206 RTSI - TSI. Volume 24 n o 10/2005 Q A Q D C n ]QB,RE[ [QA,QC,QD] Q B Q C R E Fgure 2. Objet actf prenant un pont de reprse redémarrage de l actvté de l objet en cas de reprse depus ce pont de reprse n. S l une de ces queues est vde, on la note [ ] ou ] [. 3. Prncpes Avant de donner une vue formelle du protocole que nous avons développé, nous présentons les prncpaux ponts qu justfent son comportement. Le prncpe est le suvant : le protocole fat régulèrement prendre à chaque objet actf des ponts de reprse, à l expraton d un compte à rebours temporel, réntalsé ensute. Chaque pont de reprse prs est numéroté (dans un ordre strctement crossant), et un objet actf annote tous les messages qu l émet avec l ndex du derner pont prs. Cependant, l est possble qu un objet sot forcé de prendre un pont de reprse «mprévu», par exemple sur récepton d un message : s le message porte un numéro n supéreur au derner pont du récepteur, celu c dot alors prendre un (ou pluseurs) pont de reprse ndexé par ce numéro avant la prse en compte du message, de façon à ne pas rendre ncohérent l état formé par les deux ponts ndexés n sur les deux objets. De cette façon, le protocole assure l absence de dépendance causale entre les ponts de reprse portant le même numéro, et assure donc la cohérence d un état global formé de ponts portant tous le même ndex. Cette proprété permet de détermner la lgne de recouvrement en cas de panne. On notera par la sute : C n le n-ème pont de reprse de l objet actf. N current le numéro du pont de reprse courant de l objet actf, c est-à-dre le numéro du derner pont prs par. T T C le compte à rebours de pont de reprse de l objet actf (Tme To Checkpont). N M,j le numéro de pont de reprse courant de l objet actf porté par un message de vers j.

9 Tolérance aux pannes pour objets actfs 1207 N M,j le numéro de pont de reprse courant de j porté par l acquttement de j vers. A la dfférence de (Manvannan et al., 1996) et (Bratco et al., 1984), lorsqu un objet actf prend un pont de reprse forcé, son compte à rebours déclenchant la prochane prse de pont est réntalsé. Cette modfcaton permet de rédure consdérablement le nombre total de ponts de reprse prs durant une exécuton, et donc de rédure le surcoût du protocole Messages orphelns et en transt Cohérence fable On a vu dans la secton que les objets actfs dans ProActve ne peuvent pas prendre de pont de reprse de façon préemptve : dans ce cas, un objet qu reçot un message ne peut pas réagr tout de sute s l est en tran de servr une requête. Nous allons donc utlser une stratége de réacton a posteror : comme nous ne pouvons pas placer les ponts de reprse, nous allons vrtuellement déplacer les messages, lorsque cela est possble. Nous traterons dfféremment le cas des requêtes et des réponses : s le message reçu est une requête, alors cette requête sera exclue de la queue de requêtes de l objet actf au moment de la prse du prochan pont de reprse ; ans, comme on le vot sur la fgure 3, on smule la récepton du message après la prse du pont. Ben sûr, cette modfcaton de la queue de requête a leu unquement sur l mage de l objet actf utlsée pour le pont de reprse : lorsque l objet contnue son exécuton après la prse du pont, sa queue de requêtes est toujours la même qu avant la prse de ce pont. Nous verrons dans la secton que, dans certans cas, l ordre de récepton des requêtes dot être conservé. C est pour cette rason qu au leu d être défntvement exclue de la queue de requête, cette requête sera en réalté remplacée par une promesse de requête, de manère à pouvor être rénsérée à la même poston après une reprse (cf ). C n+1] [ [ ] Q A Q A C n ] [ [ ] C n+1] [ [ ] j Fgure 3. Q A est exclue de la queue de requêtes lors de la prse du pont n + 1 sur j

10 1208 RTSI - TSI. Volume 24 n o 10/2005 s le message reçu est une réponse, on ne peut pas «annuler l effet» de la réponse comme on le fat pour une requête. En partculer, s l objet récepteur est bloqué dans un état d attente par nécessté sur cette réponse, l ne peut pas passer dans un état stable avant d avor prs en compte cette réponse. Elle fera alors parte de l état de l objet lors de la prse du prochan pont. En cas de reprse depus ce pont, le récepteur recevra donc une nouvelle fos cette réponse lors de la deuxème exécuton pusque l émetteur reprendra lu auss depus ce pont. Le mécansme des futurs permet à l objet récepteur d automatquement gnorer cette deuxème occurrence de la même réponse, pusqu l n exstera plus de futur assocé à cette réponse. Il faudra alors assurer que la deuxème occurrence sot strctement la même que la premère, pusque le récepteur n en tendra pas compte. En effet, s les servces de requête qu ont précédés l envo de cette réponse ne sont pas réexécutés dans le même ordre, la valeur de la deuxème occurrence peut alors être dfférente de la premère. Ces deux tratements spécfques des messages nous permettent de contourner le problème de la non préemptvté des objets actfs afn d obtenr l absence de message orpheln. Nous applquons dans le cas de processus non-préemptfs, et en partculer dans le cas de ProActve, une méthode de ponts de reprse nduts par messages et basé sur les ndex Cohérence forte Nous allons vor que le rendez-vous des communcatons de ProActve va nous permettre d assurer la cohérence forte des lgnes de recouvrement. Selon Hélary, Netzer et Raynal (Hélary et al., 1999), s on applque un protocole assurant l absence de message orpheln en nversant les récepteurs et les émetteurs des messages, ce protocole assure alors l absence de message en transt. En d autres termes, s on applque à la fos un protocole assurant la cohérence des lgnes de recouvrement et son dual, alors on assure la cohérence forte des lgnes de recouvrement. Or, on peut vor le rendez-vous comme un message d acquttement, c est à dre un message qu est envoyé du récepteur à l émetteur d un message applcatf. Nous pouvons donc, dans le cadre de ProActve, applquer le protocole assurant l absence de message orpheln en utlsant les messages applcatfs, et le dual de ce protocole en utlsant les messages d acquttement : lors de la récepton d un message applcatf, le récepteur se synchronse sur l émetteur grâce au numéro porté par ce message. Grâce au message d acquttement, le récepteur renvoe le numéro de son derner pont de reprse à l émetteur, de telle sorte que celu-c pusse également se synchronser. Ans, les deux objets se synchronsent au cours d une seule communcaton, et assurent une cohérence forte entre eux. Supposons que envoe une requête Q,j (ou une réponse, le tratement dans ce cas est équvalent), et qu l reçove en retour N M,j = n + 1 supéreur à son derner pont de reprse numéroté n. L objet devrat alors, pour conserver la cohérence forte

11 Tolérance aux pannes pour objets actfs 1209 C n ] [ [ ] C n+1]qa[ [ ] Q A Q A C n+1] [ [ ] j Fgure 4. Q A est enregstrée pour réémsson dans le pont de reprse n + 1 de de la lgne n+1, prendre un pont de reprse 2 avant l émsson de ce message. Cec est mpossble pusque l objet émetteur est en tran de servr une requête, et n est donc pas dans un état stable. Pour résoudre ce problème, l faut enregstrer l émsson de cette requête dans le prochan pont de reprse, de manère à ce qu elle ne sot pas perdue en cas de rejeu. Comme on peut le vor sur la fgure 4, on smule avec l enregstrement pour réémsson de Q A dans le pont de reprse n + 1 (]Q A [) l envo de Q A après la prse du pont de reprse n + 1. On notera M resend (n) la lste des messages à enregstrer dans le pont de reprse n pour qu ls soent rééms. Cependant, s les ponts suvants (n + 1, n + 2,...) sont réalsés successvement, cette lste leur sera auss ajoutée (cf ) Ponts de reprse multples et ponts de reprse mpossbles Le protocole est basé sur le fat qu un objet actf, lorsqu l le peut, va «rattraper» les autres, en terme de numéro de ponts de reprse. Il peut donc arrver qu un objet actf sot en retard de plus d un pont sur les autres. C est le cas de j sur la fgure 5 : lorsqu l arrve à un état stable, l dot prendre deux ponts de reprse pour rattraper l état global en cours de constructon. C est pour cette rason que les objets peuvent avor à mantenr des nformatons sur pluseurs ponts de reprse en même temps : on vot c que l ensemble des requêtes à réémettre est dfférent pour les deux ponts n + 1 et n + 2 sur j. On notera que, dans la pratque, lorsqu un objet actf dot prendre pluseurs ponts de reprse successfs, l n en prend en fat qu un seul. En effet, seules les nformatons assocées aux ponts changent lors de prses consécutves : l état de l objet actf n est enregstré qu une seule fos. Avec la poltque de servce par défaut de ProActve, un objet actf est dans un état stable avant chaque servce de requête. Il peut donc toujours prendre un ou pluseurs ponts de reprse avant un servce de requête. Cependant, l utlsateur peut modfer cette poltque (OASIS, 2003) et réalser, par exemple, des servces mbrqués : l est alors possble qu un objet actf dove servr une requête, sans pouvor prendre de pont 2. vore pluseurs (cf 3.1.3).

12 1210 RTSI - TSI. Volume 24 n o 10/2005 C n+2] [ [ ] C n ] [ [ ] Q B C n+1]q A,Q B [ [ ] C n+2]q B[ [ ] j Q A C n+1] [ [ ] C n+2] [ [Q A ] k Fgure 5. L objet actf j dot fare deux ponts de reprse d afflé de reprse avant ce servce : cec a pour effet de rendre mpossble la prse d un pont avant certans servces de requêtes. Nous supposons c que cette stuaton est assez rare pour évter un effet domno. Cette hypothèse est réalste car une modfcaton de la poltque de servce, par défaut FIFO, peut être généralement évtée. De plus, la modfcaton de la poltque n mplque pas forcément l utlsaton de requêtes mbrquées. C n+1] [ [ ] Q A C n ] [ [ ] X(Q x ) X(Q A ) C n+2] [ [ ] j Fgure 6. L objet actf j ne peut pas prendre le pont n + 1 Prenons le cas de la fgure 6 : la requête Q A ndque à j qu l dot prendre dès que possble le pont de reprse n + 1. Mas, avant de parvenr à un état stable, j dot servr Q A : l ne peut donc pas prendre de pont avant ce servce. Une fos dans un état stable (après le servce de Q x ), j ne peut plus prendre le pont n + 1, snon Q A serat orpheln par rapport à l état global n + 1, qu ne serat donc plus cohérent. En effet, on ne peux plus annuler la récepton de Q A (cf ), pusque Q A est déjà serve et n est donc plus dans la queue de requêtes de j. Dans ce cas, j prend drectement le pont n + 2, et la lgne n + 1 ne pourra donc pas être complétée ; c est le seul cas dans

13 Tolérance aux pannes pour objets actfs 1211 lequel des ponts de reprse (c, les ponts n + 1 sur les autres processus) devennent nutlsables, c est-à-dre qu ls ne peuvent pas être utlsés pour la reprse du système. Pour pouvor prendre en compte les ponts de reprses multples et mpossbles, nous ntrodusons les valeurs suvantes : N max le numéro maxmum du prochan pont de reprse de l objet actf. N mn le numéro mnmum du prochan pont de reprse de l objet actf. [N mn, N max ] est donc l ensemble des ponts de reprse à réalser dès que possble, c est-à-dre lorsque stablestate() est vra Manten de la causalté et équvalence Par la sute, nous entendrons par message rééms un message qu a été enregstré dans un pont de reprse pour réémsson et qu est envoyé lors de la reprse du système, et message rejoué un message qu est envoyé par un processus lors de sa rééxecuton après une reprse, mas qu avat déjà été joué lors de l exécuton précédente. Le protocole se base donc sur la réémsson de certans messages en cas de reprse du système. Nous allons vor dans cette secton que ces réémssons peuvent poser des problèmes : au nveau des dépendances causales entre les messages rééms et rejoués ; au nveau des réponses rejouées, qu pourraent être dfférentes Equvalence des exécutons L enregstrement de messages dans les ponts de reprse et la possblté de recevor deux fos la même réponse mplquent que deux exécutons partant du même état dovent être équvalentes, au mons jusqu à un certan pont dans le temps. D abord, regardons le cas de la fgure 7. En cas de reprse depus la lgne n + 1, l objet actf k devra réémettre la requête Q B et recevra une deuxème fos la réponse R B, réponse qu l gnorera. Imagnons alors que la requête Q A arrve, pendant la deuxème exécuton, après Q B : j servrat alors les requêtes dans un ordre dfférent, ce qu pourrat rendre la deuxème occurrence de la réponse R B dfférente de la premère. Il faut donc que la deuxème exécuton de j sot équvalente à la premère (Condton ) jusqu au moment où, dans la premère exécuton, on pouvat être sûr qu une réponse envoyée par j après le pont n + 1 ne serat pas reçue avant le pont n + 1 du récepteur. La deuxème rason qu oblge à avor des exécutons équvalentes est due au rejeu de certanes émssons de messages lors d une reprse : les relatons de causalté entre les réceptons dovent être conservées. Consdérons le cas de la fgure 8 : lors de l exécuton ntale, j recevra forcément Q A avant Q C car la récepton de Q C par j est probablement une conséquence de l émsson de Q B par k, émsson qu se passe après l émsson de Q A. Cet ordre de récepton est garant grâce au rendez-vous des communcatons de ProActve.

14 1212 RTSI - TSI. Volume 24 n o 10/2005 C n+1] [ [ ] Q A C n+1] [ [ ] X(Q A ) X(Q B ) j C n ] [ [ ] Q B R B C n+1]qb[ [ ] k Fgure 7. Un changement de l ordre relatf de Q A et Q B pourrat changer R B En cas de reprse depus la lgne de recouvrement n + 1, l faut assurer que j recevra encore une fos Q A avant Q C, ce qu n est pas forcément le cas : comme Q A a été enregstrée pour être réémse dans le pont de reprse n + 1 sur k, Q A n a plus de relaton de causalté avec Q C. Cette fos encore, l faut s assurer que la deuxème exécuton depus le pont n + 1 sot équvalente à la premère (Condton ) jusqu au moment où, dans la premère exécuton, on pouvat être sûr qu l n y aurat plus par la sute de requête à l ntenton de j qu sot enregstrée pour réémsson dans un pont de reprse n + 1 sur d autres objets actfs. C n ] [ C n+1] [ [ ] [ ] X(Q B ) Q C C n+1] [ [ ] j Q B C n ] [ [ ] Q A C n+1]qa[ [ ] k Fgure 8. La récepton sur j de Q C dot précéder celle de Q A La conjoncton des condtons () et () données c-dessus revent à dre qu en cas de reprse depus un pont n, l faut que la réexécuton sot strctement équvalente à la premère jusqu au moment où, dans la premère exécuton, l état global n avat été termné : le moment où tous les objets du système avaent prs le pont de reprse n. Cette nécessté d équvalence mplque deux choses :

15 Tolérance aux pannes pour objets actfs 1213 Les processus consttuant l applcaton dovent être détermnstes par morceaux (Strom et al., 1985), c est-à-dre qu à partr d un état précs et d une hstore de messages, toute exécuton d un processus est équvalente. En effet, les exécutons devant être dans certanes condtons équvalentes, l faut qu un objet recevant deux fos les mêmes messages dans le même ordre at strctement le même comportement à chaque fos. Il faut assurer que durant deux exécutons dfférentes à partr du même état, les mêmes messages arrvent dans le même ordre pour tous les objets actfs pendant une pérode donnée : cet ordre sera garant par un hstorque de récepton. Notons que ces mplcatons se retrouvent habtuellement dans les protocoles de tolérance aux pannes par journalsaton des messages : on vot que le protocole proposé comporte, du fat de la contrante de non préemptvté, un caractère hybrde entre les ponts de reprse nduts par messages et la journalsaton des messages sur le récepteur. Nous revendrons sur cet aspect lors de la concluson Hstorque Nous allons assocer à tout pont de reprse un hstorque de récepton, c est-àdre une lste chronologque des messages reçus. On notera H (n) l hstorque assocé au pont de reprse n de l objet actf : un hstorque sera ouvert à chaque prse de pont de reprse. Il est mportant de noter qu l peut donc y avor pluseurs hstorques ouverts au même moment sur un objet actf. Les caractérstques du modèle à objet actf consdéré permettent à cet hstorque d avor les proprétés suvantes : Il est consttué unquement des réceptons de requêtes. En effet, Caromel, Henro et Serpette ont montré formellement dans (Caromel et al., 2004) que l ordre de récepton des réponses n a pas d mpact sur le comportement d un objet actf. Cette proprété est due prncpalement à l utlsaton de futurs et au mécansme d attente par nécessté. Chaque récepton de requête est dentfée dans l hstorque smplement par l dentfcateur unque de son émetteur (sans aucun dentfant de requête, n aucun paramètre effectf). Grâce aux proprétés de communcaton FIFO pont-à-pont et de détermnsme par morceaux des objets actfs, cette nformaton est suffsante pour fxer complètement l ordre des réceptons (Caromel et al., 2004). Prenons l exemple de la fgure 9 : l hstorque n de l objet actf au moment noté est de la forme {j, j, k}, où j et k sont des dentfants unques d objets actfs. Le premer j ndque la récepton de la requête Q B émse par j. Le deuxème j ndque la récepton de la requête Q D émse par j. L enter k représente la récepton de la requête Q E émse par k. En cas de reprse depus le pont n, bloquera le servce de la prochane requête tant qu l ne s agt pas d une requête de la part de j, même s une requête de la part de k est déjà arrvée. S reçot deux requêtes consécutves de j, la proprété FIFO pont-à-pont nous assure que la premère arrvée correspond à la premère occurrence de l dentfant j dans l hstorque de. Il n y a pas dans l hstorque de trace de la récepton de la réponse R C.

16 1214 RTSI - TSI. Volume 24 n o 10/2005 En pratque, cet hstorque est une lste de promesse de requête. Le mécansme d attente par nécessté lé au servce de ce type de requête permet d assurer le même ordre de servce de requête lors de la réexécuton Clôture des hstorques Chaque hstorque est fn dans le temps ; le protocole dot donc détermner le moment à partr duquel l hstorque H (n) est suffsant. À ce moment, tous les objets actfs dovent avor prs le pont ndexé n, c est-à-dre que l état global n dot être formé. En effet, l ne peut plus, dans ce cas, y avor de nouveaux messages à réémettre enregstrés dans un pont de reprse n : la sute de l exécuton n a plus beson d être strctement équvalente en cas de reprse depus le pont n (en partculer, les ordres relatfs de récepton ne sont plus forcément dentques). À partr de cet nstant, l hstorque peut être clos, ce qu sgnfe qu l n est plus nécessare de mémorser les émetteurs des requêtes entrantes. Une fos clos, cet hstorque est enregstré sur un support stable et le pont de reprse qu lu est assocé (.e. celu portant le même numéro) devent alors valde pour être utlsé dans une lgne de recouvrement. En pratque, la clôture des hstorques peut-être décenchée de deux manères dfférentes. D abord, le processus de reprse est capable d dentfer à tout moment la lgne de recouvrement, et peut donc, à chaque formaton d un état global, dffuser un message ndquant la fn de la constructon de cet état. Cette méthode nous permet de clore les hstorques au plus tôt, et donc de mnmser la talle des hstorques. On notera Mn globalstate le message ndquant que l état global n est formé. Ce message ndque au récepteur que les hstorques des ponts de reprse ndexés k tel que k n peuvent être clos. Cependant, cette premère méthode ajoute dans l exécuton autant de communcatons multponts addtonnelles qu l y aura d états globaux formés. Le surcoût engendré peut-être prohbtf. On peut alors utlser une stratége de «pullng» : l nformaton du numéro du derner état global formé peut-être obtenue au moment où l objet actf réalse un pont de reprse, et engage donc une communcaton pour stocker ce pont sur un support stable. Les hstorques sur un objet actf seraent alors clos au moment des prses de ponts ; ls auraent donc une talle plus mportante, mas les dffusons de messages seraent évtées. Enfn, on peut magner utlser une méthode hybrde des deux précédentes : la dffuson pourrat alors être non-fable, donc mons coûteuse, ou alors ne concerner qu un sous-groupe du système. En effet, la clôture d hstorque se propageant par envo de messages applcatfs, s les objets actfs centraux (en terme de mallage de l applcaton) déclenchent une clôture d hstorque, cette clôture peut rapdement se propager, et donc mnmser la talle d un grand nombre d hstorques. Le mécansme de «pullng» devra cependant être conservé pour assurer la clôture des objets communquant très peu. Cependant, tous les objets actfs ne vont pas clore de manère synchronsée leur hstorque ; l peut donc survenr des problèmes de cohérence. Prenons le cas de la

17 Tolérance aux pannes pour objets actfs 1215 C n ] [ [ ] R C Q G C n ] [ [ ] Q B Q D j Q E Q A C n ] [ [ ] Q F k Fgure 9. Les clôtures d hstorque ( ) sur j et k ne sont pas cohérentes entre elles fgure 9. Les objets ont clos leur hstorque n, mas ces hstorques ne sont pas cohérents : la requête Q F a été reçue avant la clôture de l hstorque n sur j, mas a été émse après la fermeture de l hstorque n sur k. En cas de reprse depus le pont n, l est possble que la réexécuton de k sot dfférente (s k reçot des messages dans un ordre dfférent de la premère exécuton après la fn de l hstorque). Alors Q F pourrat ne jamas être envoyée en cas de reprse depus la lgne n : j restera bloqué en attente ndéfnment. Il aurat fallu que l hstorque sur j sot clos avant la récepton de Q F, comme ndqué en pontllé sur la fgure 9. On notera cependant que la requête Q G ne pose pas de problème de cohérence entre les clôtures sur et j, pusqu elle est en transt par rapport aux clôtures d hstorque. On vot ben c que le message Q F est un message orpheln par rapport aux ponts de clôture d hstorque : ces ponts dovent donc être cohérents entre eux, au sens de (Chandy et al., 1985). On va donc utlser un protocole ndut par messages assurant la cohérence fable smlare à (Bratco et al., 1984) pour les coordonner : chaque message porte le numéro du derner hstorque clos sur l émetteur, noté H M,j. à la récepton, s le message porte un numéro n supéreur au numéro du derner hstorque clos sur le récepteur, celu-c dot alors fermer l (es) hstorque(s) de numéro nféreur ou égal à n avant la prse en compte du message. Ce protocole peut être applqué drectement, pusque la clôture d hstorque peut être faîte à tout nstant. Dans la fgure 9, on dot clore l hstorque n sur j avant que j ne prenne en compte Q F (en pontllé) Reprse L hstorque de récepton va être utlsé au moment de la reprse. Le système ne peut repartr depus une lgne de recouvrement n que s tous les ponts de reprse ndexés n ont clos leur hstorque. Dans ce cas, chaque pont de reprse est assocé à son hstorque. Lorsque l objet actf reprend depus un pont de reprse n, l concatène l hstorque n à sa queue de requête. La nouvelle queue de requêtes est donc formée de

18 1216 RTSI - TSI. Volume 24 n o 10/2005 la queue de requête enregstrée au moment de la prse du pont (pouvant contenr des promesses de requête qu représentent les requêtes exclues - cf ), suve d une queue de promesse de requête (l hstorque lu même). Ans, on force de manère paresseuse l ordre de récepton des requêtes, de façon à ce qu l sot dentque à celu de l exécuton précédente. On notera que lorsqu un objet reprend depus un pont de reprse, l n a plus d hstorque en cours d enregstrement. Un hstorque sera réouvert au prochan pont de reprse prs par l objet. Avant la reprse depus un pont n, l objet actf dot réémettre toutes les requêtes ou réponses qu auraent été enregstrées dans M resend (n). La réémsson des requêtes devra se fare dans l ordre dans lequel celles-c ont été émses lors de la premère exécuton. En effet, l ordre pont à pont dot être conservé : s deux de ces requêtes sont attendues par des promesses de requête 3 chez un unque récepteur, ce récepteur ne pourrat pas les réordonner à leur arrvée, pusqu une promesse de requête ne content que l dentfant de l émetteur. Ans, l attente des objets actfs se fat de façon ndépendante lors d une reprse : la reprse du système peut donc être totalement asynchrone. La procédure de reprse va être déclenché par le processus de reprse après détecton d une panne, en émettant vers tous les objets du système un message de reprse. On notera M rec n,k le message ndquant au récepteur la k ème reprse du système, à fare à partr du pont de reprse n. La reprse du système étant asynchrone, l va être possble à un nstant donné que deux objets actfs ne soent pas dans la même occurrence d exécuton : l un pourrat avor effectuer sa reprse, tands que l autre ne saurat pas qu l faut reprendre. S ces deux objets s envoent un message, l faut alors être capable de détecter cette ncohérence et d y reméder. C est pour cela que l on va utlser un numéro d ncarnaton noté I (Strom et al., 1985; Manvannan et al., 1996), qu va représenter le nombre de reprses effectuées par l objet actf depus le lancement du système. Chaque message de vers j porte le numéro d ncarnaton de son émetteur, noté I M,j, ans que le numéro du pont de reprse de la dernère reprse, noté R M,j. De cette façon, le récepteur pourra savor s l objet qu lu envoe un message est dans la même occurrence d exécuton que lu. Le numéro d ncarnaton I M,j peut être : nféreur au numéro local I j, et ce message peut être gnoré. Le récepteur j nforme l émetteur de la dernère reprse. supéreur au numéro local I j, et dans ce cas le récepteur j dot reprendre. L objet émetteur est bloqué sur l émsson du message jusqu à ce que j at termné sa reprse. égal au numéro local I j, et le message sera traté normalement. Le processus de reprse connaît à tout nstant le nombre de reprses effectuées par le système depus la premère exécuton noté I global. 3. Ces requêtes réémses sont toujours attendues par des promesses de requête chez leurs destnatares : ce sont des requêtes qu ont été émses alors que l état global en formaton n état pas termné (par exemple Q B dans la fgure 7) et qu ont donc été enregstrées dans les hstorques des récepteurs.

19 Tolérance aux pannes pour objets actfs Récaptulatf Le fonctonnement du protocole est donc basé prncpalement sur l échange d nformatons au moment des communcatons applcatves entre objets actfs. Nous proposons un tableau synthétque (Tab. 1) des actons à effectuer en foncton des événements qu vont survenr dans la ve d un objet actf. 4. Spécfcaton algorthmque Cette secton présente de façon formelle le protocole de constructon de ponts de reprse et le protocole de reprse. On notera enfn les actons suvantes sur les messages et les ensembles : M,j M resend (n) M resend (n) s l émsson du message M,j dot être ajoutée à la lste M resend (k) C n s la lste des messages à réémettre M resend (k) est ajouté au pont de reprse C n Q awated,j H j (n) s une promesse de requête de l émetteur dot être ajoutée dans l hstorque H (n). Q,j Q awated,j requêtes de j. s on remplace la requête Q,j par Q awated,j dans la queue de 4.1. Protocoles Constructon des ponts de reprse Nous décrvons de façon formelle dans la fgure 10 le déroulement du protocole durant une exécuton sans panne. Pour cela, nous dstnguons les dfférents événements survenant dans la ve d un objet actf (émsson, récepton, servce...), et nous donnons les actons assocées. On notera que : La procédure Intalsaton est appelée à la créaton d un objet actf. La procédure Tentatve de checkpont est appelée automatquement quand stablestate est vra Reprse du système Nous décrvons dans la fgure 11 le déroulement du protocole de reprse, sute à la panne d un nœud du système.

20 1218 RTSI - TSI. Volume 24 n o 10/2005 ÉVÈNEMENT Emsson d un message ACTIONS S l ndex n du derner pont prs par le récepteur est plus grand que l ndex m, celu du derner prs localement Programmer la prse des ponts m+1 à n dès que possble et enregstrer le message pour réémsson dans ces ponts. Récepton message d un S le numéro d ncarnaton de l émetteur est plus pett que le numéro local Ignorer le message et nformer l émetteur de la reprse. S le numéro d ncarnaton de l émetteur est plus grand que le numéro local Reprendre depus le même pont. S le numéro n du derner hstorque clos sur l émetteur est plus grand que le numéro local du derner hstorque clos m Clore les hstorques de m à n. S l ndex n du derner pont prs par l émetteur est plus grand que m, celu du derner prs localement Programmer la prse des ponts m + 1 à n dès que possble. S le message est une requête et s l exste des hstorques ouverts ajouter l dentfant de l émetteur à ces hstorques. Etat global n formé Etat stable Prse d un pont de reprse n Clore les hstorques ouverts jusqu au nème. Prendre tous les ponts de reprse programmés. Prendre une mage de l état de l objet. Remplacer dans la queue de requêtes de cette mage les requêtes qu ont été émses après un pont dont l ndex est supéreur ou égal à n par des promesses de requête. Ouvrr l hstorque n. Reprse depus un pont n Récupérer l mage d état n et l hstorque n. Concaténer l hstorque à la queue de requêtes. Emettre dans l ordre tous les messages à réémettre enregstrés dans le pont n. Redémarrer l actvté. Tableau 1. Synthèse

21 Tolérance aux pannes pour objets actfs ) Intalsaton I = 0, R = 0, N current T T C = T T C_INIT Tentatve de checkpont s N M,j = 0, N mn 2) Emsson de M,j (depus ) > N current alors N max 3) Récepton de M,j (sur j) == I j alors s I M,j = 0, N max = 1 = max(n max, N k s H (k) non-clos et k < H M,j alors clôture H (k) s M,j est une Q,j alors H (k) non-clos,q awated,j s N M,j > N current j alors N max j retourne Nj current snon s I M,j > I j alors bloquer sur l émsson de M,j I j = I M,j Reprse de j sur R M,j (fgure 11) snon envoyer M rec R j,i j à gnorer M,j = max(n max j 4) Récepton de M globalstate n k s H (k) non-clos et k < n alors clôture H (k) N current M,j ) et M,j M resend H (k), N M,j ) 5) Tentatve de checkpont (appelée s stablestate est vra) = max(n mn 1, N current ) s N max > N current alors tant que N max > N current snon fare Réalsaton du checkpont C Ncurrent +1 s T T C == 0 alors Réalsaton du checkpont C Ncurrent +1 6) Réalsaton du checkpont C n Q j, Q rcv M resend effacer M resend = n N current, s N Q j, n alors Q,j Q awated,j (m) t.q. m n, M resend (m) C n (n) ouvrr H (n) T T C = T T C_INIT 7) Servce d une requête Q,j s N Q,j > N current alors s stablestate alors N max = N Q,j et Tentatve de checkpont snon N mn = max(n mn, N Q,j + 1) Fgure 10. Protocole de ponts de reprse (N M,j )

22 1220 RTSI - TSI. Volume 24 n o 10/2005 1) Panne de l objet actf par le processus de reprse placement de I global = I global + 1 Reprse de sur n dffuse M rec n,i global 2) Récepton de M rec n,k par l objet actf s I < k alors I = k Reprse de sur n snon gnorer M rec n,k 3) Reprse de sur n arrêt de l actvté récupère C n et H (n) restaure l état à partr de C n concatène H (n) à Q rcv envoe tous les messages de M resend (n) reprse de l actvté Fgure 11. Protocole de reprse 5. Expérmentatons et valdaton Nous avons suv un plan de valdaton du protocole en tros étapes. Dans un premer temps, une applcaton de test a été réalsée de manère à évaluer le surcoût moyen ndut par le protocole et à vérfer le comportement dans un cas smple. Cette évaluaton est présentée dans cette secton. Nous ne détallons pas c la preuve de la correcton du protocole. Celle-c est détallée dans (Baude et al., 2004). Cette preuve est basée sur la noton de consstance suffsante, présentée dans (Delbé, 2004). Nous avons montré que la coupe cohérente formée par la clôture des hstorques n est forcément une coupe de la réexecuton depus la lgne de recouvrement n. Les prochanes expérmentatons seront réalsées avec des applcatons plus réalstes et à plus large échelle, en partculer à partr de l applcaton Jem3D, développée avec ProActve (Baduel et al., 2004) Implémentaton et évaluaton des performances Nous avons réalsé une mplémentaton prototype dans la bblothèque ProActve, qu nous a perms de vérfer le comportement du protocole et d obtenr les premères évaluatons de performance.

23 Tolérance aux pannes pour objets actfs Chox d mplémentaton Nous avons d abord chos d utlser un serveur de pont de reprse unque pour cette premère mplémentaton : tous les objets connassent l adresse de ce serveur, et y stockent les enregstrements prs au cours de leur exécuton. Nous avons auss opté pour l approche pullng en ce qu concerne la clôture des hstorques, c est-à-dre que le serveur renvoe à chaque récepton de pont de reprse le numéro du derner état global formé (cf ). Nous n avons pas mplémenté de protocole de détecton de panne, n de protocole de relocalsaton des objets après panne, le but étant c de vérfer le bon comportement du protocole. Les tests du protocole de reprse ont donc été réalsé en relançant les applcatons volontarement, à partr du serveur de ponts de reprse Applcaton testée Les évaluatons du surcoût pendant l exécuton ont été réalsées sur une applcaton de recherche du nème nombre premer par le crble d Eratosthène avec une archtecture de type «maître-esclaves». Le maître reçot une requête de recherche du nème nombre premer. Il va alors tester tout les nombres jusqu à n, en envoyant chaque nombre à tous ses esclaves. Chaque esclave possède son propre ensemble de nombres premers, et teste le nombre reçu par rapport à cet ensemble. S tous les esclaves répondent que le nombre est premer, alors ce nombre est envoyé par le maître à l un d eux pour être ajouté à son ensemble de nombres premers. Cette procédure est rétérée jusqu à ce que le nème nombre premer sot trouvé. On note que le maître, après avor envoyé le nombre à tester à tous ses esclaves, attend toutes les réponses. Ben que smple, cette applcaton permet de tester les performances dans le pre des cas. En effet, l a été montré dans (Alvs et al., 1999) que les protocoles de ponts de reprse nduts par messages déclenchent un grand nombre de ponts de reprses forcés lorsque les communcatons sont nombreuses et régulères. Le surcoût mesuré c est donc une valeur pessmste. Les tests ont été réalsés sur un cluster de seze machnes b-pentum III 1Ghz avec 512MB (SDRAM) connectées par Ethernet 100 Mb/s, avec le protocole de geston de ressources LSF. Les machnes vrtuelles utlsées sont des JVM Pour toutes les expérmentatons, un objet actf ProActve est déployé sur chaque machne, que ce sot le maître et les esclaves Résultats Nous présentons d abord deux graphques (fgure 13) qu donnent la dfférence entre une exécuton de l applcaton avec ProActve standard, et une autre avec l ajout du protocole de tolérance aux pannes. Ces tests ont été réalsés avec 4 machnes es-