Répartition de charge dynamique dans un système distribuée

Transcription

1 Rapport de TER Répartition de charge dynamique dans un système distribuée Tuteur : Stephane Mancini Benjamin Petit Grenoble INP - Ensimag Mai 2010

2

3 Table des matières 1 Introduction Contexte pratique Contexte scientifique Mon travail La répartition de charge Quelques notions Clefs de la répartition Algorithmes de répartitions Répartition statique Répartition dynamique Problème de cohérence dans un modèle distribué Simulation But de la simulation Structure d une tâche Structure d un message Structure d un noeud L unité de calcul Liste de tâche en attente Le routeur Le gestionnaire de charge Résultats et limites Bilan 16 5 Références 17 2

4 Remerciements Je remercie Stephane Mancini et le laboratoire GISPA-lab pour m avoir accueilli durant ce TER. Je remercie égalemment le personnel enseignant de l Ensimag qui a permis de mettre en place ce module. 3

5 1 Introduction 1.1 Contexte pratique J ai effectué ce Travail d Études et de Recherche au sein du laboratoire Grenoble Images Parole Signal Automatique (GIPSA-lab). Le GIPSA-lab s investit dans la recherche fondamentale sur le traitement du signal, la commande et le diagnostic des systèmes, sur la parole et la cognition. J ai été affecté au le département Images et Signal et dans l équipe Géométrie, Perception, Images, Gestes sous la responsabilité de Stéphane Mancini. 1.2 Contexte scientifique Pour augmenter les performances des processeurs, dans un premier temps, les fondeurs ont sans cesse cherché à augmenter la fréquence de fonctionnement de leurs puces. Cependant, il semblerait qu aujourd hui nous soyons arrivé à des fréquence qu il va être difficile de dépasser. Pour augmenter les performances, les fabricants s efforcent désormais de produire des puces dotées de plusieurs unités de calcul. De nos jours, nous utilisons de plus en plus des machines de type multi-processeurs ou multicoeurs. Afin de répartir le travail de manière intelligente sur toutes ces unités disponibles, il est nécessaire d utiliser un système dit de répartition de charge ou load balancing en anglais. Beaucoup de ces systèmes multi-processeurs sont dit homogènes, c est à dire que les différentes unités de calcul sont les mêmes : elles tournent à la même fréquence et ont des capacités de calcul similaires. Ce modèle présente tout de même des limites : la production de processeur possédant des coeurs de plus en plus nombreux coûtent de plus en plus cher aux fondeurs, du fait de la complexité des architectures. Dans les systèmes actuels, c est le rôle du système d exploitation de répartir correctement la charge sur les différents processeurs disponibles. 1.3 Mon travail Ici je vais traiter des systèmes hétérogènes, c est à dire des systèmes qui possèdent des unités parfois très différentes les unes des autres ; on peut imaginer par exemple que le système possède des processeurs génériques ainsi que des accélérateurs matériels, très spécialisés, mais très performants pour une tâche donnée. De plus, je vais me concentrer essentiellement sur la répartition de charge dite distribuée, contrairement à la répartition de charge où la décision est centralisée en un point. 4

6 2 La répartition de charge 2.1 Quelques notions On suppose que le programme qui s exécute peut être découpé dans des tâches bien connues, sur un ensemble d unités de calculs aussi appelées noeuds. Un noeud exécute une tâche à la fois, et peut avoir une liste de tâches a exécuter dans une liste d attente. Figure 1 Grille de calcul 4x4 composée de 16 noeuds Les noeuds ne sont pas forcement interconnectés comme dans la figure 1 : on peut imaginer d autres topologies possible pour une grille de calcul. Chaque tâche peut, après avoir été calculée, démarrer d autres sous-tâches. On néglige ici les arguments et les retour de résultats des différentes sous-tâches. C est pour cela qu on étudie principalement la répartition de charge distribuée : chaque noeud choisira à qui envoyer sa ou ses sous-tâches. Chaque programme peut donc être représenté par un arbre comme celui-ci : Figure 2 Représentation d un programme en arbre de tâches Chacune des tâches nécessite une puissance de calcul qui peut être prédite à l avance. De même, pour chaque noeud, on connait leur capacité de traiter telle ou telle tâche. La figure 2 montre bien que plusieurs tâches peuvent être exécutées en parallèle ; et comme tous les noeuds n ont pas les mêmes capacités de calcul, il faut choisir soigneusement le noeud qui s occupera d une tâche donnée : l efficacité de l algorithme de répartition de charge est donc primordiale. 5

7 2.2 Clefs de la répartition Dans un système homogène, il est relativement aisé de distribuer les tâches de manière efficace ; comme tous les noeuds de calculs ont les même capacités, il suffit de donner du travail aux noeuds les moins chargés. Dans un système hétérogène, c est plus complexe. Tous les noeuds n ayant pas les mêmes capacités de calcul il faut choisir soigneusement quel noeud on va utiliser pour telle tâche. On ne prend pas forcement le noeud le plus rapide, car il est peut-être déjà très chargé, tout comme on n utilise pas forcement le noeud le moins occupé parce que trop lent pour la tâche. Prenons par exemple une grille de calcul, dont l état est le suivant : Noeud Disponible dans Capacités Tâche A 10ms 1 5ms Tâche B 8ms Tâche C 20ms 2 11ms Tâche A 6ms Tâche B 8ms 3 8ms Tâche C 5ms Si la prochaine tâche à traiter est une tâche de type A : Noeud 1 : fin estimée de la tâche A : 5ms + 10ms = 15ms Noeud 2 : fin estimée de la tâche A : 11ms + 6ms = 17ms Noeud 3 : impossible d effectuer cette tâche Dans cette exemple, si on a une tâche A a traité, il vaut mieux l envoyer sur le noeud 1, même si il est moins rapide que le noeud 2 pour cette tâche. On voit aussi ici que l algorithme de répartition de charge doit être très rapide : plus la prise de décision est longue, plus la décision pourra être fausse. Bien sûr dans cette exemple, on estime que le coût de la transmission de charge est gratuite, c est à dire que la transmission de messages entre les noeuds est instantanée et que le lien ne peut être saturé. Cependant, dans le cas des Network On Chip (NoC), ce facteur peut être très limitant. D autres facteurs peuvent rentrer en compte : la topologie du réseau, la fragmentation des noeuds exécutés, des impératifs de consommations... Pour prendre des décisions efficaces dans un système hétérogène, il faut donc connaître la charge des différents modules, ainsi que de leurs capacités de calcul respectives. Mais comment garantir une cohérence de la vision de la charge des noeuds dans le système entier? 6

8 2.3 Algorithmes de répartitions Il existe deux grands types d algorithmes de répartitions : les algorithmes de répartitions de charges dit statiques, que l on peut définir à la compilation, et les algorithmes dit dynamiques, calculé pendant l exécution du programme. Les algorithmes dit statiques sont certainement les plus efficaces, mais ne peuvent être mis en place que si le programme n est pas interactif. De même, pour un programme distribué en binaire, il n est pas forcement possible de savoir sur quel type d architecture va être exécuté le programme. Dans tous ces cas il faut utiliser des algorithmes dynamiques. Cependant, même en utilisant un algorithme dynamique, il peut être intéressant d utiliser un algorithme pseudo-statique pour le mappage initial des tâches, comme nous allons le voir dans le point suivant Répartition statique La répartition statique peut être calculé au moment de la compilation ; si le programme n est pas interactif, c est avec cette méthode qu on obtiendra les meilleurs temps de calculs, du fait qu il n y aura pas d algorithme à exécuter pour choisir le noeud qui exécutera une tâche donnée. Mais comme soulevé dans [1], même dans le cas de programme dynamique, il est utile de faire appel à une stratégie de placement statique. Voyons un exemple dans une grille de calcul 4x4. Figure 3 Mauvais placement Figure 4 Bon placement Dans la figure 3, la tâche initiale est située sur le noeud le plus foncé. On voit que si elle se divise en deux sous-tâches, les communications avec les autres noeuds seront plus compliqués, du fait que pour transmettre d autres tâches ou des résultats, les chemins seront plus longs et nécessiteront des sauts. Au contraire, la situation dans la figure 4 est meilleure ; le noeud contenant la tâche initiale a moins de chance d être isolé. On voit donc bien que même dans le cadre d algorithme dynamique, le mappage initial des tâches (et donc par extension, la mise en place d une grille de calcul) est très important. Cette stratégie de mappage initiale doit être implémentée dans la grille de calcul elle-même, non pas à la compilation si l on veut que le code soit portable. 7

9 2.3.2 Répartition dynamique Pour palier au manque des algorithmes de répartitions statiques, des chercheurs ont expérimentés plusieurs types de répartitions dynamique. Le choix du meilleur noeud étant plus ou moins facile suivant les données qui influenceront la prise de décision (cf la partie 2.2), la plupart des travaux se concentrent sur l optimisation des communications entre noeuds, notemment éviter la congestion réseau. Ces algorithmes visent à choisir entre deux noeuds qui pourraient accueillir une même tâche, dans des délais équivalents. Bien que dans mon travail, je n ai pas traité de la partie pénalité dûe au réseau, je pense qu il est important d en citer quelques un. Les trois algorithmes suivant sous tirés de [1]. On y trouve aussi d autres stratégies, mais j en ai retenues trois : 1. First Fee (FF) Cette algorithme est le plus simple ; il n est jamais utilisé en pratique, mais on l utilise pour comparer plusieurs méthodes différents. Il consiste simplement à prendre le premier noeud disponible le plus proche, en parcourant le réseau colonne à colonne. Cette algorithme n a pas de coût d évaluation. 2. Nearest Neighbor (NN) Cette algorithme ressemble à la stratégie précédente ; elle n a pas de coût d évaluation. Cette stratégie consiste à chercher le noeud le plus proche en testant tous les voisins à une distance n, n variant de 1 au nombre de noeuds disponible dans la grille. 3. Path Load (PL) Le troisième algorithme est le plus compliqué. Les algorithmes précédent ne tiennent pas compte de la bande passante disponible entre les noeuds de la grille : cette dernière stratégie tente de diminuer la congestion réseau en prenant compte de cette donnée. Cet algorithme calcul le coût des transmissions entre chaque noeud à l aide de l équation suivante : cost k = rate c(i,j) + rate c(i,j) Où rate c(i,j) et rate c(j,i) correspondent à la vitesse de transmission entre deux noeuds, du sens i j et du sens j i (les communications ne sont pas nécessairement symétriques) La stratégie PL est certainement la plus complète. Cependant, les expériences [1] ont montré que les résultats obtenus avec cette méthode sont très proches de ceux obtenus avec la stratégie NN. Celà est sans doute dû au calcul qui est nécessaire pour la stratégie PL. Bien que l on peut difficilement dire quel est l algorithme le meilleur (cela dépend essentiellement de la nature de la grille de calcul ainsi que du programme à faire tourner), cette expérience montre bien que l algorithme de répartition de charge, pour être efficace, doit être très rapide et simple à exécuter. 8

10 2.3.3 Problème de cohérence dans un modèle distribué Dans un système classique centralisée, les décisions de délégation de tâches dont prises en un point. Ce point maître connait avec exactitude l état des noeuds de calcul, car lui et lui seul envoie des tâches. Dans un système distribuée, les décisions sont prises par chacun des noeuds : or, comment garantir que l état des noeuds est correct en chacun des points de la grille? On appelera état réel l état dans lequel le noeud est à l instant t, et état supposé l état d un noeud vu par un autre noeud à l instant t. Noeud Disponible dans États supposés des autres noeuds 1 5ms Noeud 2 2ms Noeud 3 8ms 2 11ms Noeud 1 10ms Noeud 3 8ms 3 8ms Noeud 1 5ms Noeud 2 11ms Figure 5 États réels des noeuds et états supposés Dans la figure 5, on voit un exemple d incohérence : l état supposé du noeud 2 par le noeud 1 est fausse (2ns contre 11ms en réalité). Le challenge majeur pour une répartition dynamique est donc de réduire au maximum l écart entre état réel et état supposé. Pour cela, plusieurs solutions sont possibles : Avertir tous les noeuds qu une tâche a été affecté En théorie, probablement une des stratégies les meilleures. Cependant, son application en pratique pose d évident problème de communication dans la grille de calcul : si des milliers de tâches sont exécutées sur une grille, le réseau va très vite être saturé. Envoyer aux autres noeuds son état de manière régulière Cette stratégie consiste à envoyer toutes les période t son état aux autres noeuds. Pour éviter une congestion du réseau, il vaut mieux éviter que plusieurs broadcast de l état de noeuds aient lieu en même temps. Cette valeur peut être différente selon chaque noeud. De plus, elle dépend énormément de la durée du traitement des tâches, et de la nature de la grille de calcul, et doit être déterminée au cas par cas. Avertir les autres noeuds que son état a changé de manière significative Cela rejoint un peu l idée précédente : on envoie à tous les autres noeuds son état actuel, lorsque qu il a changé de manière significative. Le problème est de quantifier le delta qui déterminera quand envoyer une mise à jour d état. Ici aussi le paramètre de cette stratégie est très dépendent de la durée des calculs et de la nature de la grille de calcul. Avertir les autres noeuds qu une décision en lui convient pas Cette fois ci, un noeud enverra son nouveau statut lorsqu une tâche lui aura été envoyé, alors que, selon lui, cette tâche devrait être exécutée sous un autre noeud. Bien sûr, on peut le combiner avec la stratégie précédente, ce qui veut dire qu il tolèrera une certaine marge d erreur. 9

11 Noeud si exécution sur noeud courant) si exécution sur autre noeud 1 14ms Noeud 2 2ms Noeud 3 19ms Figure 6 Décision litigieuse La figure 6 montre que le noeud 1 a reçu une tâche, qu il aura finie de calculer dans 14ms. Or, il lui semble, selon sa vision de la grille, qu il serait plus judicieux de l envoyer sur le noeud 2. Il prend quand même la tâche qui lui a été envoyée, mais il envoie son statut à jour aux autres noeuds. Cette dernière stratégie semble celle qui a le moins d inconvénients, par rapport aux autres. Cependant, elle n est pas parfaite, et des erreurs de décisions peuvent être prises. On peut ainsi compléter cette solution avec une boucle d auto-correction comme cela est proposé dans [2] Le principe de cette boucle est simple : à intervalle régulier, on recalcule la politique de répartition de charge pour chacune des tâches présentes dans la file d attente du noeud. Mais le problème est de bien choisir la durée de ces intervalles. 10

12 3 Simulation Dans cette partie je vais parler du petit simulateur en C que j ai développé afin de tester divers algorithmes de répartition de charge. 3.1 But de la simulation Le simulateur doit donc simuler le fonctionnement d une grille de calcul, dans laquelle se trouve des noeuds de calculs. On devra exécuter des programmes comme celui de la figure 2. On néglige la question de passage de paramètre ou de gestion de résultat. Nous ne prenons pas en compte la topologie de la grille et les performances du réseau ; pour simplifier, on estime que tous les noeuds sont reliés ensemble et qu il n y a aucun problème de communication dans le réseau. Enfin, le code doit être le plus modulaire possible afin de pouvoir changer des modules, que je détaille par la suite, afin de pouvoir changer le comportement de ces derniers, afin d améliorer le simulateur. 3.2 Structure d une tâche Initialement, chaque tâche devait exécuter des fonctions C, compilées avec des options différentes selon les noeuds, afin de simuler une différence de rapidité de traitements entre ces derniers. Par manque de temps, une tâche ne contient qu un temps incompressible de calcul. On peut facilement changer le contenu de cette structure (via le fichier task.h ainsi que le traitement de celle-ci dans la fonction traite task (dans node.c). 3.3 Structure d un message Divers messages peuvent être échangé dans la grille de calcul entre noeuds. Ces messages peuvent être du type : STATUS : un noeud envoie un message de ce type afin d envoyer son état réel aux autres noeuds du système. TASK : un noeud envoie une tâche à un autre grâce à ce message. TASK IN : utilisé pour l envoie d une tâche en interne (dans le cadre d une création d une sous-tâche - voir le point sur l unité de calcul). On pourrait imaginer d autres types de messages : des messages d erreur, pour signaler qu un noeud est H.S., des messages de recalibration, pour mettre à jour les capacités de chaque noeud... On peut ajouter des types de messages différents dans le fichier msg.h 11

13 3.4 Structure d un noeud Chaque noeud de la grille est lancé par un thread qui lui est propre, pour simuler l exécution parallèle de plusieurs noeuds. Figure 7 Composition d un noeud Pour cette simulation, on considère qu un noeud (voir figure 7) est composé de : une unité de calcul une liste de tâches en attente un gestionnaire de charge un routeur L unité de calcul Figure 8 Traitements réalisés dans l unité de calcul L unité de calcul simule le calcul, en attendant le temps spécifié par la tâche qu il doit traiter. En plus de ce temps, il ajoute une pénalité, qui dépend de sa capacité à traiter la tâche : ceci permet de simuler des différences de performances dans le traitement des tâches. Si une des tâches qu il traite nécessite de lancer une ou plusieurs sous-tâche, il les envoie au gestionnaire de charge. 12

14 Lorsque la tâche courante a fini d être calculée (c est à dire que le délai d attente est écoulé), elle va chercher la première tâche située dans la liste de tâche en attente. L unité de calcul s exécute dans un thread qui lui ai propre Liste de tâche en attente La liste des tâches en attente est tout simplement une liste FIFO qui contient la liste des tâches à passer à l unité de calcul. Dans le simulateur elle est implémenté avec un pipe entre le gestionnaire de charge et l unité de calcul Le routeur Le routeur se charge des communications entre les différents noeuds de la grille. C est lui qui forgera les paquets à envoyer aux autres noeuds selon la nature du message. C est également lui qui traitera les paquets reçus et qui les enverra ensuite au gestionnaire de charge. Dans le simulateur, les liaisons entre les noeuds sont implémenté avec des pipe. On peut facilement changer l implémentation du routeur sans toucher au reste du code, par exemple pour simuler plus précisément les problèmes de communications qui peuvent avoir lieu. Tout comme l unité de calcul, le routeur s exécute dans un thread à part Le gestionnaire de charge Le gestionnaire de charge est l élément central de la simulation. C est lui qui intègre l algorithme de répartition de charge ainsi que la boucle correctrice, exécutée à intervalle régulier. Lorsque le gestionnaire de charge reçoit une tâche provenant du module réseau, il regarde d abord dans un premier temps si selon lui, il est acceptable d exécuter cette tâche. Si oui, il l envoie directement à la liste des tâches à traiter. Sinon il demande au module réseau d envoyer un message de mise à jour de son statut réel aux autres noeuds. Pour éviter une partie de ping-pong entre plusieurs noeuds, on accepte de prendre la tâche, même si le noeud courant est très chargé. C est le rôle de la boucle de correction de palier à ce problème : évaluée à un bon intervalle, elle doit limiter le nombre d erreurs. Le gestionnaire de charge reçoit également des tâches provenant du module de calcul, lorsque ce dernier demande à exécuter une ou plusieurs sous-tâches. Il choisit alors où cette ou ces dernières doivent s exécuter, soit localement, soit sur un autre noeud. Il est a noter que lors d un envoie de tâche à un autre noeud, il met à jour l état supposé de celui-ci, afin d éviter de le surcharger en lui envoyant une dizaine de tâche dans un délai court. Les fonctions utilisées par le gestionnaire doivent être très efficace, pour que la prise de décision soit rapide. Ainsi, les erreurs de jugement sont limités. Tout comme l unité de calcul et le module réseau, pour la simulation, le gestionnaire de charge s exécute dans un thread à part. 13

15 Figure 9 Traitements réalisés dans le gestionnaire de charge Le nombre de threads pour simuler un noeud est donc de trois. Malheureusement, les machines utilisées pour faire tourner le simulateur ne dispose pas d un nombre de processeur illimité. Pour limiter le nombre de thread, on fait tourner le module réseau et le gestionnaire de charge dans le même thread. Cela a théoriquement peu d impact dans la simulation actuelle, du fait de la grande rapidité des méthodes utilisées dans le gestionnaire de charge et que le module réseau n a aucun traitement complexe à réaliser. 14

16 3.5 Résultats et limites Dans les expérimentations, les résultats obtenus avec le simulateur se sont révélés très proches des meilleurs résultats possibles. Mais j ai utilisé des stubs assez grossier pour simuler les temps de calcul (l unité de calcul se contentait de faire des sleep de quelques secondes). L utilisation de la boucle de correction n a eu que très peu d impact sur le résultat. Cependant, en augmentant les niveaux de tolérance qui régissent l envoi d une mise à jour de statut, afin de réduire les échanges au sein de la grille, cette boucle permet de limiter les erreurs de répartition. De même, en augmentant de manière artificielle le temps d exécution de l algorithme de répartition de charge, on note une très forte augmentation d erreurs de choix de répartitions, ce qui souligne l importance d avoir des algorithmes simple si les tâches a exécuter sont rapides. Pour simuler d une manière plus exhaustive une grille de calcul, il faudrait prendre en compte le réseau qui relie tous les noeuds, ainsi que la transmission des arguments et des résultats produits par les tâches. 15

17 4 Bilan J ai effectué mon stage de fin de DUT dans le laboratoire LIMSI, Laboratoire d Informatique pour la Mécanique et les Sciences de l Ingénieur, à Orsay (Paris XI). J avais donc déjà une petite idée de la recherche publique. Cependant, j ai eu surtout un rôle de développeur pendant ce stage. C est pour cela que j ai eu envie de faire un TER. Celui-ci m a permis de m initier réellement à la recherche. J ai appris à chercher des articles sur des sites spécialisées ainsi qu à lire de long documents universitaires. Ce fût une expérience enrichissante, qui en plus de m avoir fait découvrir le monde de la recherche, m a permis de travailler sur un domaine que je n aurai probablement pas eu l occasion de traiter dans les cours classiques, la répartition de charge distribuée. 16

18 5 Références [1] Carvalho, E. ; Calazabs, M. ; Moraes,F. ; Heuristic for Dynamic Task Mapping in Noc-based Heterogenous MPSoCs. [2] Mancini S. ; Architecture materielle pour la synthèse d image par lancer de rayon [3] Bertozzi S. ; Acquaviva A. ; Bertozzi D. ; Poggiali A. ; Supporting Task Migration in Muli- Processor Systems-on-chip : A Feasibility Study 17