Modèle de coût algorithmique intégrant des mécanismes de tolérance aux pannes Samir Jafar, Thierry Gautier, Jean Louis Roch Laboratoire ID-IMAG Equipe.

Présentation au sujet: "Modèle de coût algorithmique intégrant des mécanismes de tolérance aux pannes Samir Jafar, Thierry Gautier, Jean Louis Roch Laboratoire ID-IMAG Equipe."— Transcription de la présentation:

1 Modèle de coût algorithmique intégrant des mécanismes de tolérance aux pannes Samir Jafar, Thierry Gautier, Jean Louis Roch Laboratoire ID-IMAG Equipe MOAIS RENPAR16, Le Croisic, 5 au 8 avril 2005

2 RENPAR'162/18 Motivations Contexte technologique : Calcul sur grille Problème de défaillance : MTBF = 2000 jours (~ 6 ans), λ = 1/MTBF, R = Runtime ( jours ), n processeurs Probabilité de défaillance (application) = 1 - ( 1- λ R ) n grid5000 : ~ 1400 processeurs 0,5 1 heure 1/2 jour 1 jour 10 jours 30 jours

3 RENPAR'163/18 Tolérance aux pannes Contexte technologique Hétérogénéité des ressources SMP Multithreading Dynamicité : ajout / retrait de ressources Pannes considérées pannes franches Tolérance aux pannes Détection des pannes Traitement des pannes peu de systèmes parallèles supportent à la fois : Hétérogénéité, Dynamicité et Multithreading

4 RENPAR'164/18 Méthodes 1.Duplication : Tolère seulement un nombre fixe de pannes Non adaptée pour les applications parallèles. Ex. Menta,... 2.Journalisation des messages : Optimiste, Pessimiste, Causale La réception dun message est le seul événement non déterministe Ex. : Mpich-v, FTL-Charm++,... 3.Sauvegarde / Reprise : état global cohérent Coordonnée : synchronisation globale, un point de reprise par processus, reprise simple, pas deffet domino [Charm++, Mpich-CL, Cocheck, …] Non coordonnée : pas de synchronisation globale, plusieurs points de reprise par processus, reprise compliquée, risque deffet domino Induit par les communications ( compromis entre 1 et 2) : un point de reprise par processus, pas de synchronisation globale, pas deffet domino [ProActive, …]

5 RENPAR'165/18 Objectifs Exploitation fiable et efficace des architectures de grande taille Grappe, Grille, P2P Problèmes liés à la tolérance aux pannes : Hétérogénéité Description portable de létat de lexécution SMP Programme multithreadé Dynamicité Ajout & retrait des ressources hétérogènes Notre approche : un état de lapplication un graphe de flot de données indépendant des ressources ordonnancement non-preemptif (work stealing) efficace dans un cadre hétérogène et dynamique [Brender & Rabin 04] efficacité à lexécution

6 RENPAR'166/18 Plan Macro-dataflow et ordonnancement : modèle dexécution Notations + modèle de coût Exemple: KAAPI ( http://moais.imag.fr ) Tolérance aux pannes : analyse de coût de deux proocoles: SEL (journalisation) TIC (sauvegarde induit par les communications) Expérimentations de SEL et TIC sur cluster 160 procs. Conclusions & Perspectives

7 RENPAR'167/18 Macro-dataflow et ordonnancement Modèle dexécution : KAAPI Kernel for Adaptative and Asynchronous Parallel Interface Graphe de flot de données dynamique et distribué Mesures de coût : T 1 = temps sur 1 proc. ; = #noeuds T = temps sur proc. ; = profondeur T p = temps sur p proc incluant coût dordonnancement Ordonnancement : vol de travail sur inactivité (WorkStealing) Modèle de coût : Si processeurs homogènes T p c 1 T s / p + c T [Cilk,Athapascan] Si processeurs hétérogènes : T p c 1 T s / p * + c T [Bender&Rabin] Classe des programmes considérés : T << T 1

8 RENPAR'168/18 Comment réaliser la tolérance aux pannes ? Méthode 1 : par journalisation du graphe dataflow : SEL : Systematic Event Logging Journalisation sur support stable tous les événements de construction du graphe de flot de donneés (créations nœuds, … : changements détat) Reprise : interprétation des événements du journal pour reconstruire le graphe de flot de données de toutes les tâches qui ne sont pas terminées Coût de reprise locale après 1 panne : T reprise = O( max i=1,...,p i ) #Calculs « perdus » suite à une panne 1 tâche T

9 RENPAR'169/18 Analyse du coût de SEL Surcoût systématique à chaque événement Création de tâche, … Analyse du surcoût : = la taille du graphe T p SEL T p + F SEL ( ) Comment diminuer le surcoût Augmentation du grain : mais … perte de parallélisme car T p augmente Idée : WorkFirst Principle [Cilk] Reporter le surcoût au moment du vol Justification : T petit + WorkStealing très peu de vol

10 RENPAR'1610/18 Méthode 2 : induit par les vols TIC : Theft-Induced Checkpointing Sauvegarde du graphe local (périodiquement) + forcée sur une opération de vol (inspirée de « Communication-Induced Checkpointing ») Reprise : reconstruction du graphe à partir du fichier de sauvegarde Coût de reprise locale après 1 panne : T reprise = O( ) #Calculs perdus suite à une panne période + 1 tâche Analyse du coût : T p TIC T p + F TIC ( )

11 RENPAR'1611/18 Bilan: comparaison SEL / TIC T p T p + T surcoût + T reprise + T perdu + T détection SEL : T surcoût lié à la taille du graphe Diminution augmentation du grain du programme et donc perte de parallélisme Nécessite de changer lalgorithme TIC : T surcoût lié au nombre de vol ( T ) et période Diminution augmentation de la période et donc augmentation de T perdu Indépendant de lalgorithme

12 RENPAR'1612/18 Expérimentations Application : ACI DOCG (Prism/Moais/LIFL) Optimisation combinatoire, algorithme Branch & Bound QAP : Quadratic Assignment Problem (V.D. Cung) Plate-forme : iCluster2 104 noeuds Itanium2, Bi-processeurs, 900 MHz Réseau FastEthernet 100 Mbit/s Les points de reprise sont stockés sur NFS Objectif : valider lanalyse théorique du surcoût Comparer expérimentalement SEL / TIC

13 RENPAR'1613/18 SEL sur 25 processeurs théorique SEL référence parallèle gros graingrain fin

14 RENPAR'1614/18 Comparaison SEL et TIC gros grain grain fin SEL référence parallèle TIC (1s)

15 RENPAR'1615/18 Passage à léchelle ? Passage à léchelle à gros grain pour SEL Surcoût faible... mais perte de parallélisme Problème à grain fin NFS devient défaillant ! Serveur distribué de checkpoint

16 RENPAR'1616/18 Passage à léchelle ? 17.6% 23.5% 18.7%

17 RENPAR'1617/18 Coût dexécution avec pannes Exécution sur 60 processeurs 1s

18 RENPAR'1618/18 Conclusions Deux protocoles de tolérance aux pannes Pour les applications parallèles très récursives T << T 1 Supportent lhétérogénéité et le multithreading Analyse des surcoûts théoriques Validations expérimentales sur QAP Challenge : Temps de calcul ~ 1 semaine sur 1400 processeurs Applications Implantation de la résilience et migration Retrait de ressources Certification des calculs

19 FIN