M2 TIIR ( ) Bilel Derbel

Transcription

1 M2 TIIR ( ) Bilel Derbel Notre but est de concevoir une application générique sur grid5000 qui permet de déployer des calculs parallèles de façon transparente Plus précisément, nous nous plaçons dans le cadre d'une application qui génère des tâches indépendantes qu'il s'agit d'exécuter de façon parallèle en utilisant une grille de calcul Nous allons mettre en place une architecture distribuée qui permet à une application de soumettre l'ensemble de ses tâches à notre architecture et de récupérer le résultat de l'exécution des différentes tâches Nous supposons que le résultat final attendu par l'application est une agrégation sur l'ensemble des résultats partiels de l'exécution de chaque tâche Nous supposons pour la simplicité que le résultat final est obtenu en appliquant une loi associative sur l'ensemble des résultats partiels; par exemple: le résultat final est la somme des résultats obtenus pour chaque tâche Pour cela, nous proposons par exemple modéliser l'ensemble des tâches à l'aide des classes suivantes (vous n'êtes pas cependant tenus de suivre cette modélisation!) SetOfTasks - int taille; - Task gettask(int index); - Iterator<Task> iterator(); Task - Result execute(); Result AggregationResults - void add(result r) - Result getfinalresult() Partie I : modèle maître esclave en mode Push Dans une première étape nous allons réaliser une architecture simple selon le paradigme maître esclave dans un contexte non volatile (les ressources de calculs ne tombent pas en pannes) Plus précisément, l'application soumet l'ensemble des tâches qu'elle souhaite réaliser au maître Ce dernier se charge de les répartir sur les esclaves et de fournir le résultat final à l'application Le schéma général de l'architecture que l'on souhaite mettre en place est donné par la figure suivante : Application 1 4 Résultat final 3 Récupération/aggrégation des résultats Slave 1 Application 2 Application M 1 Soumisson tâches Master 2 Parralélisation et Exécution Slave 2 Slave N Dans les parties I et II, on va traiter uniquement le cas où le maître gère une seule application à la fois L'architecture que l'on souhaite mettre en place nécessite de faire communiquer

2 l'application, le maître et les esclaves entre eux Pour cela, nous allons utiliser l'appel de méthodes distantes avec RMI pour la mise en oeuvre Le but des quatre questions suivantes est de vous amener à réfléchir et à identifier les différents problèmes à traiter, avant de commencer l'implémentation à proprement dit Application Maître : Nous allons étudier les échanges entre l'application et le maître D'un point de vue de l'application, ce qui nous intéresse est de soumettre un ensemble de tâches au maître et de récupérer les résultats Autrement dit, l'application ignore la façon avec laquelle les tâches sont exécutées par le maître Q1 Écrire le pseudo-code des différents échanges entre l'application et le maître Q2 Donner les interfaces RMI que doit implémenter l'application et le maître Maître Escalves : mode push Nous allons maintenant nous concentrer sur le fonctionnement du maître et des esclaves (On suppose donc le maître dispose déjà d'un ensemble de taches à exécuter et fournit au préalable par l'application) Pour exécuter les tâches, le maître décide de les partager 'équitablement' entre les esclaves; ensuite il contacte chaque esclave et lui soumet le sous ensemble de taches qu'il lui a affecté Q3 Écrire le pseudo-code des différents échanges et étapes de calcul/communication entre les esclaves et le maître Q4 Donner les interfaces RMI que doit satisfaire le maître et les esclaves Initialisation/Configuration/Implémentation : Pour initialiser notre architecture, nous supposons que le Maître et les Esclaves sont démarrées avant le lancement de l'application Le premier composant à être démarré est le Maître Les Esclaves sont ensuite démarrés un par un À chaque fois qu'un esclave est démarré, ce dernier s'enregistre au près du maître en appelant une méthode distante de ce dernier Une fois l'ensemble démarré, on peut alors lancer une Application (Pour faire nos tests et expérimentations, nous déploierons par exemple une image sur grid5000 avec kadeploy) Vous utiliserez une machine pour l'application, une machine pour le maître et les autres pour les esclaves Q5 Réaliser complètement les différentes classes nécessaires à votre architecture Ne pas oublier les interface des classes qui modélisent le travail à effectuer Q6 Réaliser un script de démarrage pour votre architecture Maître-Esclave Exemples de tâches/validation : Remarque : Dans un premier temps, vous pouvez tester vos programmes en utilisant un exemple de tâches vides (eg La méthode execute() fait un simple sleep(10), etc) Nous allons réaliser la parallélisation du calcul d'intégrale par la méthode de Monte-Carlo Cette méthode est souvent utilisée pour calculer une estimation de façon heuristique lorsqu'un calcul direct est soit trop coûteux, soit trop complexe Dans cette méthode on procède à un grand nombre de tirages aléatoires On évalue une fonction pour chacun de ces points

3 aléatoires, et l'on suppose que l'échantillon ainsi évalué est représentatif Dans le calcul de l'intégrale d'une fonction f sur un domaine [a,b] : On tire un grand nombre n de tirages x dans [a,b] Pour chacun de ces tirages on additionne f(x) à un accumulateur acc Une fois tous les tirages fini, l'intégrale de f sur [a,b] vaut (b-a)acc/n On cherche à faire de même pour la fonction f(x,y)=cos(x*y) sur intervalle [0,5] 2 La méthode est la même, et l'on a alors comme résultat 5 2 * acc/n Q7 Réaliser les différentes classes nécessaires à la parallélisation de cette application Q8 Étudier le comportement de votre architecture en fonction du nombre de tirage n et du nombre d esclaves utilisés Q9 Pour tester le passage à l'échelle de votre architecture (ne pouvant utiliser qu'un nombre limitée de machines dans grid5000!), démarrer plusieurs esclaves par machine déployée dans grid5000 (eg, un par coeur de calcul) Q10 Étudier le comportement de votre architecture en fonction des sites géographiques de grid5000 que vous utilisez lors de vos expérimentations Partie II : Modèle Maître-Esclave en mode pull Dans la première partie, le maître décide comment partager le travail entre les esclaves de façon statique et contacte lui même les esclaves pour leur transmettre des tâches Ceci a l'inconvénient de rendre notre architecture statique et de ne pas prendre en compte le fait que les esclaves ont souvent des puissances de calcul variables L'équilibrage de charge peut ainsi se voir dégradé Pour palier à cet inconvénient, nous allons étendre notre architecture et la rendre plus dynamique Pour cela, le maître ne distribue plus le travail lui même aux esclaves, il se contente simplement de définir la granularité du travail à affecter, c'est à dire la taille des sous ensembles de tâches à distribuer aux esclaves Chaque esclave contacte quant à lui continuellement le maître pour lui demander du travail Si, le maître dispose encore de sous ensembles de tâches non encore exécutées, il en délivre à l'esclave Ce protocole est répété par le maître jusqu'à épuisement total des tâches Q11 Effectuer les différentes modifications nécessaires à la réalisation de ce nouveau mode

4 Q12 En fonction de la granularité des sous tâches décidée par le maître, évaluer les performances de votre architecture en considérant l'exemple du calcul d'intégrale Partie III : Injection de fautes Jusqu'à maintenant, nous n'avons pas pris en compte le fait que les esclaves peuvent éventuellement tomber en panne Ceci est un aspect très important des calcul parallèles à grande échelle en particulier dans le contexte des grilles de calcul Nous nous interressons notamment à trois types de pannes : Les pannes franches : un esclave tombe en panne et sort des calculs définitivement (crash de l'esclave) Les pannes transitoires : un esclave met longtemps à répondre au maître Les pannes byzantines : le comportement d'un esclave est suspect, par exemple, un esclave demande du travail mais ne répond jamais de façon délibérée, ou encore le résultat que fournit l esclave est délibérément erronée! Q13 Votre architecture (en mode push/pull) est-elle tolérante aux pannes? Q14 Sinon, quelles sont les modifications que vous pouvez apporter pour rendre votre architecture tolérante aux fautes? Mettre en place ses modification et tester votre application! Pour tester le comportement de votre (ou vos) solutions, nous allons adopter les cas de simulation suivants : Au démarrage de l'application, nous désignons un nombre préfixé d'esclaves qui ralentiront de façon contrôlée l'exécution des tâches qu'ils obtiennent du maître Ceci permettra de simuler l'impact du temps de latence et des pannes transitoires Au démarrage de l'application, nous injecterons des nouveaux esclaves qui viennent se rajouter aux esclaves déjà lancés Ces nouveaux esclaves simuleront des pannes franches de la façon suivante Une fois qu'un nouveau esclave obtient du travail, il s'arrête immédiatement et délibérément de s'exécuter Les nouveaux esclaves injectés se comportent en fait comme des attaquants qui essayent de faire tomber notre architecture Q15 Tester le comportement de votre architecture en jouant sur les différents paramètres : eg, nombre d esclaves saints et fautifs, délais de réponse, fréquence d'injection de fautes Partie IV : Bonus Remarque : Il n'est pas obligatoire d'implémenter les réponses aux questions de cette partie Mais, votre rapport final doit aborder les problèmes soulevées ainsi qu'une ébauche de solution Jusqu'à maintenant, nous avons considéré uniquement le cas où le maître gère une seule application à la fois En pratique, plusieurs applications peuvent soumettre des tâches au maître C'est le but des questions suivantes Q16 Quelles modifications faut-il apporter à notre architecture? Q17 Quels problèmes d'équilibrage de charge sont soulevés? Comment pouvez vous les traiter?

5