Coût des pannes

Pour des raisons techniques, l’évaluation précise du coût d’une panne lors d’une exécution est difficile. Il est difficile d’isoler dans ce surcoût les parties dues

Nombre de points de reprise 0 5 10 15 20 25 0 30 60 90 120 150 TTC (s) # p o in ts d e r e p ri se

Jacobi 7000, 16 nœuds Jacobi 7000, 36 nœuds

Jacobi 7000, 64 nœuds CG-C, 8 nœuds

CG-C, 16 nœuds

FIG. 4.28 – Nombre de points de reprise en fonction du TTC

au temps de détection de la panne, à la redistribution des données nécessaires pour le recouvrement, à la période de resynchronisation des activités et enfin au temps de calcul perdu. En particulier, le temps de calcul perdu causé par une panne dépend totalement du moment auquel cette panne a lieu. Par exemple, une panne qui a lieu quelques secondes après la création d’une ligne de recouvrement ne cause la perte que de quelques secondes de temps de calcul. Si au contraire cette panne a lieu quelques secondes avant la création d’une ligne de recouvre-ment, le temps de calcul perdu peut être important.

Pour tenter d’extraire le surcoût induit par une panne de manière générale, nous déclenchons une panne durant toutes les exécutions 10 secondes après la création d’une ligne de recouvrement. Plus précisément, la machine virtuelle de la dernière activité à avoir envoyé un point de reprise sur la mémoire stable est stoppée au bout de 10 secondes par un signalkill. On peut donc approximer ici le temps de calcul perdu à 10 secondes, bien que cette mesure ne puisse être stricte. Au moment de stopper l’activité, le service de détection de panne est réveillé et découvre immédiatement l’activité stoppée ; le temps de détection de la panne peut donc être négligé dans cette expérience.

Nous évaluons donc le surcoût causé par une panne durant une exécution du noyau CG en classe B et C présenté dans la figure 4.29, et de l’application Jacobi avec des matrices de dimension 5000 et 7000 dans la figure 4.30. Dans chacun des graphiques, une ligne en pointillés noirs indique le temps de calcul perdu, puisque la panne est déclenchée 10 secondes après le dernier point de reprise.

Pour toutes ces expérimentations, nous présentons les temps de reprise avec et sans la conservation d’une copie du point de reprise en local, comme présenté dans la section 4.2.3, de manière à évaluer le gain apporté par cette optimisation. Le temps de recouvrement augmente avec le nombre de nœuds, mais la vitesse de cette augmentation diminue avec le nombre de nœuds dans le cas de CG : les courbes sont croissantes concaves. Dans le cas de Jacobi, le temps de

recouvre-4.3 Expérimentations 99

Surcoût d'une panne - CG-B

5 10 15 20 25 30 35 40 0 5 10 15 20 25 30 35 # noeuds T e m p s (s)

Sans copie locale Avec copie locale

Surcoût d'une panne - CG-C

5 10 15 20 25 30 35 40 45 0 5 10 15 20 25 30 35 # noeuds T e m p s (s)

Sans copie locale Avec copie locale

FIG. 4.29 – Surcoût causé par une panne pour le noyau CG

Surcoût d'une panne - Jacobi 5000

5 7 9 11 13 15 17 19 21 23 0 10 20 30 40 50 60 70 # noeuds T e m p s (s)

Sans copie locale Avec copie locale

Surcoût d'une panne - Jacobi 7000

5 10 15 20 25 30 0 10 20 30 40 50 60 70 # noeuds T e m p s (s)

Sans copie locale Avec copie locale

FIG. 4.30 – Surcoût causé par une panne pour l’application Jacobi

ment semble même se stabiliser à une valeur maximum d’environ 20 secondes dans le cas d’une matrice de dimension 5000 et de 25 secondes dans le cas d’une matrice 7000.

Ce ralentissement de l’augmentation du surcoût induit par une panne, ou la quasi-stabilisation dans le cas de Jacobi, s’explique par le fait que la récupération des points de reprise sur la mémoire stable s’effectue en parallèle. De manière sy-métrique à ce qu’on a vu dans le cas de la figure 4.26 (capture et envoi de 1 Go de donnée), même si la contention augmente, le temps moyen et maximum diminue car le processus de sérialisation sur la mémoire stable tire parti de la parallélisa-tion. Il est en effet plus rapide de sérialiser 64 objets de 12 Mo en parallèle sur une même machine que 16 objets de 48 Mo : il est donc plus rapide pour 64 activités de récupérer en parallèle 12 Mo de données chacune sur la mémoire stable, que pour 16 activités de récupérer 48 Mo chacune.

Cette quasi-stabilisation du temps de recouvrement est aussi une conséquence du caractère asynchrone du la mécanisme de reprise dans le protocole proposé : il n’y a pas de phase de synchronisation stricte qui augmenterait de façon

régu-lière le temps de recouvrement avec le nombre de nœuds. La resynchronisation des activités se fait sans blocage global grâce aux promesses de requêtes, qui ne synchronisent l’activité que si nécessaire, et uniquement localement.

Enfin, on observe que dans toutes les expérimentations, le gain obtenu grâce à la copie locale du dernier point de reprise reste quasiment constant jusqu’à 49 nœuds. Dans le cas de CG, le gain obtenu sur le temps de recouvrement est de l’ordre de 4 secondes en classe B et de l’ordre de 7 secondes en classe C. Pour Jacobi, on observe un gain de 2,5 secondes pour la matrice 5000 et 4 secondes pour la matrice 7000.

4.4 Conclusion

Nous avons présenté dans ce chapitre le protocole que nous avons développé durant cette thèse pour le modèle ASP. Ce protocole tient compte mais aussi tire parti des spécificités de ce modèle et de son implémentation ProActive, avec en particulier la possibilité de reprendre depuis des états globaux incohérents, et la capacité à éviter les réceptions de réponse en avance.

Cette solution se base essentiellement sur l’utilisation de promesses de ré-ception de requête. Elles permettent tout d’abord d’assurer de façon uniquement locale la synchronisation nécessaire pour éviter les réceptions de réponses en avance. De plus, elles sont utilisées pour réordonner les réceptions de requêtes durant la réexécution, et ainsi assurer l’équivalence de la réexécution avec l’exé-cution de référence.

Nous avons aussi décrit dans ce chapitre l’implémentation de ce protocole dans l’intergiciel ProActive, ainsi qu’un mécanisme de configuration simple d’utilisa-tion à travers les descripteurs de déploiement. Cette implémentad’utilisa-tion fait actuel-lement partie de la version téléchargeable de ProActive, et est disponible avec une documentation et des exemples d’utilisation. Elle constitue aussi une base pour l’intégration d’autres protocoles de tolérance aux pannes : nous avons par exemple implémenté sur cette base un protocole simple de journalisation pessi-miste par le récepteur. Ce protocole simple est un premier élément de l’extension pour le contexte des grilles de calcul présentée dans le chapitre 6.

Enfin, cette implémentation nous a permis d’évaluer les performances du pro-tocole dans un contexte d’utilisation réel. Nous avons constaté dans le cadre d’ap-plications communicantes de type SPMD un surcoût global sur le temps d’exécu-tion variant de 10% à 45% pour le noyau CG et de 4% à 12% pour l’applicad’exécu-tion Jacobi, selon le nombre de nœuds et la valeur du T T C.

A titre de comparaison, le protocole proposé par Schulz et al. dans [SCH 04], qui possède des propriétés similaires au nôtre dans le contexte de l’intergiciel MPI, induit un surcoût du même ordre de grandeur. Pour une application de trai-tement de matrice type SPMD sur 16 nœuds, le surcoût global reste inférieur à 50% ; dans des conditions de taille de point de reprise et de valeur du T T C si-milaire, notre protocole induit un surcoût de 9% à 45,4%. On notera que cette

4.4 Conclusion 101

comparaison n’a de sens qu’en termes d’ordre de grandeur, puisque les contextes de développement et d’expérimentation sont différents.

Chapitre 5

Formalisation et preuves :

cohérence promise

Nous proposons dans ce chapitre de formaliser les concepts introduits par le protocole développé pour ASP. Ce travail a été réalisé en collaboration avec Lu-dovic Henrio de l’équipe OASIS [CAR 04a, CAR 06d]. Cette formalisation a pour but premier de prouver la correction du protocole proposé ; nous montrons que les états globaux formés, bien que non cohérents, sont toujours recouvrables.

Le second objectif de cette modélisation est d’identifier précisément les hypo-thèses requises par notre approche : nous allons montrer que la capacité de recou-vrement depuis un état global incohérent n’est pas dépendante des particularités du modèle ASP. De manière plus générale, le formalisme proposé ici peut s’appli-quer dans d’autres systèmes, toujours dans le cadre de protocole de tolérance aux pannes par recouvrement arrière depuis un état global non cohérent.

Après avoir introduit le formalisme élémentaire nécessaire, nous généralisons le concept de promesse de requête introduit dans le chapitre 4 en promesse d’évè-nement. Nous supposons dans un premier temps qu’une promesse d’évènement est capable de synchroniser de manière globale l’exécution, sans tenir compte de la possibilité de créer en pratique un tel outil. Sur la base des promesses d’évè-nement, nous présentons la cohérence promise, ou P-cohérence. La P-cohérence est un outil qui va permettre de prouver la recouvrabilité d’états globaux non cohérents contenant des promesses d’évènement ; à travers la définition d’une ré-duction d’un état P-cohérent nous prouvons que la réexécution depuis un état P-cohérent est toujours possible, ne peut pas bloquer et dirige toujours l’exécu-tion vers un état global cohérent de l’exécul’exécu-tion de référence. Cette réducl’exécu-tion re-pose sur la définition théorique des promesses d’évènement, c’est-à-dire capables de synchronisation globale sur l’exécution.

L’objectif est ensuite de montrer que cette réduction d’un état P-cohérent peut être respectée en pratique en ne contrôlant l’exécution que de manière locale sur chaque activité, et en particulier sans supposer que les promesses d’évènement synchronisent l’exécution de manière globale. Pour cela, nous définissons la ré-duction locale, c’est-à-dire une réré-duction qui ne tient compte que de l’état local d’une activité et qui ne suppose pas de synchronisation particulière entre les

tivités ; on ne voit plus l’exécution comme une suite de réduction de l’état global mais comme des suites de réduction d’états locaux en parallèle.

Nous montrons ensuite que cette réduction est réaliste, c’est-à-dire que le contrôle sur l’exécution d’une activité nécessaire pour respecter cette réduction est réalisable dans la plupart des systèmes.

Enfin, nous identifions les trois hypothèses qui doivent être respectées par un état global P-cohérent et par le système considéré pour que la réduction locale soit équivalente à la réduction globale, et donc que, dans le cadre d’un contrôle uniquement local de l’exécution, cet état global soit recouvrable.

Les preuves des propriétés et des théorèmes présentés dans cette section sont disponibles dans l’annexe A.

5.1 Formalisme élémentaire

Cette section présente d’abord formellement la notion d’équivalence d’exécu-tion, puis revient sur le concept de causalité potentielle introduit dans la sec-tion 2.7. Nous considérons par la suite que toute variable libre est universelle-ment quantifiée à gauche de l’équation. Par exemple, f(x) ⇒ g(y) est équivalent à ∀x, y, f(x) ⇒ g(y).