Comparaison avec d’autres travaux

Nous comparons ici notre approche avec différentes solutions existantes, d’abord par rapport aux solutions induites par messages en général, puis par rapport aux solutions capables de recouvrir une application depuis un état global incohérent.

4.1.8.1 Approches induites par message

Le protocole que nous proposons est inspiré des protocoles de points de re-prises induits par messages basés sur les index, introduits par Briatico et al. dans [BRI 84]. Cette approche ne met en jeu aucune synchronisation additionnelle que celle des messages de l’application pour la création des états globaux durant l’exé-cution. De plus, elle ne met pas en jeu un transfert d’information important entre les processus durant une exécution sans panne, puisque seul un nombre entier doit être ajouté sur les messages de l’application.

Ces propriétés permettent d’envisager un surcoût faible pendant une exécu-tion sans panne. Pourtant, dans [ALV 99], Alvisi et al. identifient les points néga-tifs des protocoles de type induit par messages, parmi lesquels :

− l’augmentation du nombre de points de reprise forcés avec la taille du sys-tème et selon les motifs de communication,

− l’indéterminisme des prises de points forcés qui complique la récupération de l’espace sur la mémoire stable occupé par des points de reprise inutiles, − et le besoin d’une persistance forte pour déclencher les points de reprise

forcés.

Les points de reprise forcés sont donc le talon d’Achille des protocoles in-duits par message, et de nombreux travaux ont proposé de réduire ce nombre. Par exemple, dans [BAL 99], Baldoni et al. proposent un protocole qui autorise les activités à augmenter l’index de point de reprise sans en prendre réellement en fonction d’une relation d’équivalence entre certains points de reprises locaux consécutifs. Hélary et al. dans [HéL 97a] se basent sur la prévention durant l’exé-cution de cycle “zigzag” sur points de reprise pour éviter les points de reprise for-cés inutiles ; les auteurs montrent expérimentalement que le nombre de points de reprise forcés n’excède pas 4% du nombre de point de reprise total. Les mêmes au-teurs introduisent dans [HéL 97b] la propriété de précédence virtuelle et prouvent l’équivalence entre cette propriété et la propriété d’absence de cycle “zigzag” dans une exécution. Cette propriété est utilisée par Baldoni et al. dans [BAL 98] pour proposer une classification des protocoles induits par message en fonction du fait qu’ils assurent ou non la propriété de précédence virtuelle, donc dans quelle me-sure ils évitent les points de reprise inutiles.

4.1 Protocole par point de reprise pour ASP 75

A la différence des protocoles classiques, notre protocole n’est pas sujet à l’ac-cumulation de points de reprise forcés ; aucun point de reprise n’est inutile. En effet, dans les protocoles classiques, ces points de reprise sont pris après un point régulier pour éviter l’incohérence de l’état global, et donc pour créer un état global recouvrable. Or, notre protocole permet de rendre recouvrable un état global non cohérent ; il n’y a donc jamais besoin de déclencher un point de reprise en plus du point régulier.

Cependant, dans notre cas, si les points de reprise sont limités aux seuls points réguliers, une activité doit accéder deux fois à la mémoire stable pour envoyer un point de reprise utilisable pour une reprise : d’abord envoyer le point de reprise lui-même puis envoyer l’historique et les journaux de messages. La différence avec les protocoles classiques est que le nombre d’accès à la mémoire stable est par contre déterministe. La récupération de l’espace sur la mémoire stable est donc simplifiée ; dès qu’un état global n est stable et que tous les historiques ont été reçus, toute autre information peut être effacée de la mémoire stable. On retrouve ici les qualités d’une approche par point de reprise synchrone.

Finalement, bien que basée sur une approche induite par message, notre so-lution ne souffre pas des défauts identifiés par Alvisi et al. dans [ALV 99] cités précédemment.

En cas de panne d’une seule activité dans le système, toutes les activités doivent redémarrer depuis la dernière ligne de recouvrement, c’est-à-dire depuis le dernier état global complété avec un historique clos. Plusieurs solutions ont été proposées pour éviter à toutes les activités de devoir reprendre à cause de la panne d’une seule d’entre elles. Nous ne nous penchons pas ici sur les solutions basées uniquement sur la journalisation des messages, qui permettent la reprise uniquement de l’activité fautive, mais sur les approches basées sur la construction d’état globaux.

Manivannan et al. proposent dans [MAN 02] un protocole par points de reprise induits par message qui permet à une activité de reprendre systématiquement de-puis son dernier point de reprise en cas de panne, indexé n. Toutes les activités ne sont alors pas forcées de reprendre après cette panne. Les activités qui n’ont pas encore pris le point de reprise n ne redémarrent pas ; elles déclenchent sim-plement le point de reprise n puis continuent leur exécution.

Cette solution intéressante n’est cependant pas applicable dans notre cas puis-qu’elle ne considère pas l’existence potentielle de messages orphelins dans les états globaux. Dans ce cas, une activité qui n’a pas encore pris le point de reprise n et qui ne redémarre pas contient peut être un message orphelin, qui sera donc réémis par une activité qui doit reprendre et donc reçu une nouvelle fois.

D’autres solutions se basent sur l’utilisation de vecteurs d’horloges pour dé-terminer les dépendances causales entre les activités. Ces informations sur les dépendances sont utilisées pour ne faire redémarrer que les activités qui ont été causalement liées à l’activité tombée en panne depuis le dernier point de reprise. Bien qu’applicable dans le cadre de notre protocole, nous n’avons pas ajouté ce

mécanisme. En effet, nous ne nous plaçons pas dans un contexte particulier en ce qui concerne le type d’application, puisque le modèle ASP et l’implémentation ProActive sont applicables à n’importe quel type d’applications distribuées. Or, nous pensons qu’un tel mécanisme ne peut se révéler utile que si l’on considère des applications avec un motif de communication donné. Par exemple, pour des applications de type maître-esclaves ou de type branch-and-bound, un tel méca-nisme peut éviter la reprise inutile d’un certain nombre d’éléments de l’applica-tion. Mais dans le cas général, et particulièrement dans le cadre d’applications de type SPMD (Single Program Mutliple Data) telles que celles que nous utili-sons pour évaluer notre protocole, une telle optimisation serait inutile. En effet, les relations de causalité entre les activités forment très rapidement un graphe complet, par communication de proche en proche. Dans ce cas, les activités sont rapidement toutes dépendantes les unes des autres, et la panne de l’une d’entre elle entraîne la reprise de tout le système.

4.1.8.2 Recouvrabilité d’états globaux non cohérents

Schulz et al. proposent dans [SCH 04] une solution à une problématique si-milaire à la nôtre. Il propose un mécanisme de tolérance aux pannes par point de reprise automatique dans le cadre de l’intergiciel de communication MPI, en basant la persistance des processus sur un compilateur spécialisé qui fournit une persistance faible ; les captures d’états sont possibles pendant les points de cap-tures potentiels définis par l’utilisateur dans le code source. Comme on l’a vu, la création automatique d’états globaux cohérents est impossible : la persistance utilisée est faible, et l’intergiciel de communication MPI ne suppose pas des com-munications purement asynchrones. Les auteurs proposent donc un protocole qui identifie et journalise les évènements qui causent l’incohérence durant la créa-tion des états globaux. En cas de reprise, la réexécucréa-tion est contrainte jusqu’à atteindre un état global cohérent à l’aide des journaux d’évènements.

La solution proposée par Schulz et al. est basée sur une approche synchrone : un processus central est élu et devient responsable de la coordination nécessaire à la création d’un état global. Un état global est créé en quatre phases, qui sont synchronisées par le processus central par envoi de messages non fonctionnels.

Le protocole que nous avons proposé ne nécessite pas de processus central, et ne repose pas sur des phases qui doivent être synchronisées de manière forte. De plus, un seul envoi de message non fonctionnel est nécessaire, le message qui signale la complétion de l’état global en cours. Mais à la différence de Schulz et al., la réception de ce message par toutes les activités n’est pas primordiale. En effet, la clôture d’historique déclenchée par la réception de ce message se pro-page ensuite par les messages applicatifs. On pourrait donc imaginer d’envoyer cet unique message non fonctionnel à un sous-ensemble seulement des activités du système, choisie selon le motif de communication de l’application de manière à assurer une propagation de la clôture des historiques.

Le protocole de Schulz et al. traite le problème des messages orphelins en les identifiant du coté de l’émetteur, et en annulant l’émission de ces messages en