THÈSE. Contribution à l'ordonnancement de lots de graphes de tâches sur une plate-forme hétérogène. Année présentée à

Transcription

1 Année 2010 THÈSE présentée à L'U.F.R. DES SCIENCES ET TECHNIQUES DE L'UNIVERSITÉ DE FRANCHE-COMTÉ pour obtenir LE GRADE DE DOCTEUR DE L'UNIVERSITÉ DE FRANCHE-COMTÉ Spécialité : Informatique Contribution à l'ordonnancement de lots de graphes de tâches sur une plate-forme hétérogène par Sékou Diakité Soutenue le 15 décembre 2010 devant la Commission d'examen : Rapporteurs Olivier Beaumont Directeur de Recherche INRIA, Laboratoire Bordelais de Recherche en Informatique (LaBRI), Talence Bruno Gaujal Directeur de Recherche INRIA, Laboratoire d'informatique de Grenoble (LIG), Montbonnot Examinateurs Jacques Bahi Professeur, Laboratoire d'informatique de Franche-Comté (LIFC), Belfort Philippe Lutz Professeur, Institut FEMTO-ST (dept AS2M), Besançon Loris Marchal Chargé de Recherche CNRS, Laboratoire de l'informatique du Parallélisme (LIP), Lyon Jean-Marc Nicod Maître de conférences HDR, Laboratoire d'informatique de Franche-Comté (LIFC), Besançon Laurent Philippe Professeur, Laboratoire d'informatique de Franche-Comté (LIFC), Besançon Stéphane Vialle Professeur, Supélec, Metz

2 ii

3 Tout d'abord, je tiens à exprimer mes remerciements aux membres du jury, qui ont accepté d'évaluer mon travail de thèse. Merci à M. Olivier Beaumont et à M. Bruno Gaujal d'avoir accepté d'être les rapporteurs de ce manuscrit. Merci à M. Loris Marchal, dont l'aide sur le plan théorique et les grandes qualités humaines se sont avérées déterminantes pour mener à terme ce travail. Merci à M. Philippe Lutz et M. Dominique Gendreau pour m'avoir patiemment aidé à construire mon modèle de micro-usine. Merci à M. Stéphane Vialle pour sa bonne humeur lors des réunions Réseau Grand Est. Merci également à M. Jacques Bahi pour avoir accepté d'examiner mon mémoire et de faire partie de mon jury de thèse. Merci à M. Jean-Christophe Lapayre, responsable du laboratoire d'informatique de Franche- Comté, de m'avoir accueilli au sein de son équipe. Mes plus grands remerciements à Laurent Philippe et Jean-Marc Nicod, pour avoir accepté de diriger (resp. co-diriger) cette thèse, et sans qui rien n'aurait été possible. Je tiens également à les remercier pour leurs blagues salaces qui permettent à mon vocabulaire de paraître châtié. Merci à toute l'équipe du laboratoire d'informatique de Franche-Comté, l'atmosphère chaleureuse a été d'un grand secours lors des moments plus diciles. Merci aux thésards de ce même laboratoire pour l'ambiance studieuse qui règne en salle de convivialité. Merci à eux d'avoir enn accepté qu'il n'y a rien d'autre que le logiciel libre. Je les remercie enn pour m'avoir fait découvrir que boire toujours plus était une n en soi. Je tiens à adresser un big-up à mes amis qui ne m'ont aidé en rien dans mon travail de thèse. Merci à Mme Floriane Diakité Bosch-Cano sans qui la vie serait beaucoup plus triste. Enn un grand merci à ma famille et plus particulièrement à mes parents, mes frères qui me supportent depuis 30 ans déjà. iii

4 iv

5 Résumé Les travaux présentés dans cette thèse portent sur l'ordonnancement de lots bornés sur des plates-formes hétérogènes. Un lot est représenté par un ensemble de graphes acycliques orientés particuliers : les anti-arbres. Cet ensemble est constitué de quelques dizaines à plusieurs centaines d'anti-arbres identiques. Les plates-formes hétérogènes, qu'elles soient grilles de calcul ou micro-usines, sont constituées d'unités capables de prendre en charge une sous-partie des tâches nécessaires au traitement d'un anti-arbre en entier. Du fait de l'hétérogénéité, les temps de traitements entre les diérentes unités sont non-reliés. Dans ce contexte, l'objectif est de minimiser le temps de traitement du lot en entier. Trois algorithmes sont étudiés dans ce contexte : un algorithme classique de liste, un algorithme génétique et un algorithme en régime permanent. Les contributions de cette thèse portent à la fois sur l'étude expérimentale de ces algorithmes et sur leur adaptation au contexte déni. Lorsque les temps de communication sont négligeables, l'algorithme génétique donne les meilleurs résultats quelle que soit la taille du lot ; les deux autres algorithmes sont départagés par la taille du lot. L'algorithme du régime permanent est le meilleur pour les lots de taille importante ; pour les petits lots, l'algorithme de liste est plus performant. Par contre, lorsque les temps de communication ne sont plus négligeables, le régime permanent est le plus performant quelle que soit la taille du lot. Mots clés : Ordonnancement, lots de graphes de tâches, hétérogène. Abstract In this study, we schedule bounded batches of identical graphs on a heterogeneous platform. A batch is represented by a set of particular acyclic graphs: intrees. The number of intrees in a batch goes from a few dozen to several thousands. Considered heterogeneous platforms, whether they are computing grids or micro-factories, are composed of nodes able to process a subset of the intree. The time needed to process a single task on each node of the platform is unrelated. In this context, three algorithms are studied to solve the targeted scheduling problem: a list-based scheduling algorithm, a genetic algorithm and a steady-state algorithm. The contributions of this dissertation are both the experimental study of theses algorithms and their adaptation to better t our context. When the communication times are neglected, the genetic algorithm gives the better schelule whatever the number of intrees in a batch; the performance of the two other algorithms depends on the batch sizes. The steady-state algorithm is well suited for scheduling batches of medium to large size while the list-based scheduler is better for small to medium batches. However, when the communication times are no longer negligible, the steady-state algorithm performs best whatever the number of intrees in a batch. Keywords: Scheduling, task graph batches, heterogeneous.

6 vi

7 Table des matières 1 Contexte 5 1 Grilles de calculs Historique Caractéristiques Exploitation des grilles de calculs Applications et grilles de calculs La micro-usine modulaire La micro-usine du MEL La micro-usine industrielle Vers une micro-usine modulaire La micro-usine modulaire du futur? Vision de la grille et de la micro-usine pour l'ordonnancement Synthèse Modèle 23 1 Un modèle de micro-usine modulaire pour l'ordonnancement Description du modèle Modèle de plate-forme Modèle de production Modèle de plate-forme de calcul Modèle d'application Similitude des modèles Synthèse Ordonnancement 31 1 Généralités Dénition d'un ordonnancement Ordonnancement, tâches et graphes de tâches vii

8 viii TABLE DES MATIÈRES 1.3 Ordonnancement en ligne vs hors ligne Ordonnancement et plate-forme Critères d'optimisation Ordonnancement et complexité Classications des problèmes d'ordonnancement Classication du problème d'ordonnancement étudié Quel ordonnancement pour R batch of intrees C max? Algorithme de liste Genetic Algorithm for Task Scheduling Régime permanent Synthèse Les algorithmes 51 1 Algorithme de liste Algorithme initial Amélioration de l'algorithme initial Genetic Algorithm for Task Scheduling Prise en compte de la notion de fonction Prise en compte de lots d'applications Régime permanent Réduction de la taille de la période Synthèse Régime permanent pour les lots bornés 63 1 Rappels sur les principes du régime permanent Principes Limites du régime permanent Réduction des dépendances inter-périodes Formalisation du problème Complexité du problème Approche gloutonne Approche optimale utilisant un programme linéaire mixte Dégradation du débit pour améliorer le makespan Principes et algorithme Limites Synthèse

9 TABLE DES MATIÈRES ix 6 Résultats expérimentaux 77 1 Validation par l'expérience Implémentation des algorithmes Evaluation des performances Prise en compte des communications Le simulateur Architecture Algorithme principaux La génération des plates-formes et des applications Métriques d'évaluation des performances Protocole de simulation Communications négligeables Adaptations des algorithmes Plates-formes homogènes Plates-formes hétérogènes Synthèse Temps de calcul Communications non-négligeables Jeux d'expérimentations Optimisation du régime permanent Comparaison des trois algorithmes Ecacité des diérents algorithmes Nombre d'instances en cours Coûts CPU des diérents algorithmes Communications préemptives Synthèse Conclusion Bilan Travaux futurs Annexes Le problème de la minimisation du nombre de dépendances inter-périodes est NPcomplet Bibliographie 115

10 x TABLE DES MATIÈRES

11 Introduction Le domaine d'étude de ce travail est celui de l'ordonnancement de tâches en milieu distribué hétérogène. D'un point de vue formel, ce contexte de travail engendre des problèmes d'ordonnancement parmi les plus diciles car même les problèmes relativement simples, qui trouvent une solution acceptable dans les environnements homogènes, deviennent complexes lorsque leur exécution est envisagée dans un environnement hétérogène. Ce domaine a néanmoins connu, ces dernières années, une activité importante. Parmi les raisons qui ont poussé les chercheurs à se pencher sur ce problème, il y a la diculté d'exploitation ecace des grilles de calcul. Or ce domaine, les grilles de calcul, a lui-même connu une explosion au cours de la décennie passée car il prégure ce que pourrait devenir l'informatique du futur : omniprésente et capable de traiter des problèmes de grande taille sans avoir les ressources concentrées en un seul point. Les grilles de calcul sont, par essence, hétérogènes et leur exploitation, du point de vue de l'ef- cacité de calcul, est dicile. Il apparaît donc important de fournir aux utilisateurs des grilles des moyens adaptés qui tirent parti des ressources mises à leur disposition, d'où les travaux sur l'ordonnancement hétérogène. Le problème général de l'exécution optimale de tâches sur la grille est un problème dicile. Il convient donc de le décomposer pour proposer des solutions adaptées aux cas spéciques. Ainsi, après avoir constaté qu'une classe de problèmes sur la grille ne s'intéressait pas seulement à l'exécution d'un ensemble d'instances indépendantes mais plutôt à un ensemble de tâches ayant des dépendances entre elles, des travaux ont tenté d'apporter des solutions d'ordonnancement pour résoudre ce problème. Dans ce cas, l'intérêt de l'utilisateur est d'avoir un programme qui termine au plus tôt. C'est donc le temps de terminaison de la dernière des tâches qui semble le critère à optimiser le plus pertinent. Malheureusement, le problème dans cette formulation est NP-Complet et nous devons donc nous contenter d'heuristiques, bien souvent sans garantie. Les solutions à base de méta-heuristiques orent cependant des solutions qui peuvent être de qualité. C'est, par exemple, ce qu'ont montré dans leur travaux Daoud et Kharma en proposant l'algorithme du GATS. Cet algorithme code les caractéristiques d'exécution d'un graphe de tâches dans un chromosome an d'en évaluer l'adaptation à une plate-forme hétérogène. Certaines instances de problèmes en milieu hétérogène peuvent néanmoins présenter des solutions optimales. C'est le cas de problèmes de ux de workows dont la structure est identique, c'est-à-dire de ux de travaux (jobs) ayant tous les mêmes caractéristiques en terme de tâches (poids ou type) et de dépendances entre ces tâches. Le traitement de données vidéo est un exemple de problème où, si plusieurs tâches doivent être appliquées dans un ordre xe sur la suite des données, nous disposons d'un ux de workows. Le domaine a été d'abord défriché par Bertinas et Gamarnik avant d'être complété par Beaumont, Legrand, Marchal et Robert qui proposent un algorithme d'ordonnancement périodique permettant de trouver l'aectation optimale des tâches aux processeurs tout en tenant compte des coûts de communication. Si le 1

12 2 TABLE DES MATIÈRES nombre de jobs est grand, il y a de fortes chances que, en utilisant cet algorithme, la solution soit ecace même pour résoudre le problème de minimisation du temps de terminaison (makespan). Notre travail a été réalisé dans le cadre d'une coopération entre le laboratoire d'informatique et le département Automatique et Systèmes Micro-Mécatroniques (AS2M) du laboratoire de l'institut FEMTO-ST (Franche-Comté Electronique Mécanique Thermique et Optique - Sciences et Technologies) de l'université de Franche-Comté. A l'origine l'équipe CARTOON du laboratoire d'informatique, à laquelle j'appartiens, possède une expertise en ordonnancement des systèmes hétérogènes de type grille, expertise renforcée par sa participation au projet INRIA GRAAL. L'équipe Systèmes Automatisés de Micromanipulation et Micro-assemblage (SAMMI) du département AS2M est, elle, spécialisée dans la micro-robotique et s'interroge sur l'utilisation de son savoir pour mettre en uvre des micro-usines. Les échanges entre les deux équipes ont permis de mettre en évidence des convergences entre leurs problématiques et l'optimisation, en particulier, l'ordonnancement. A l'origine de ce travail il y a donc des échanges en vue de résoudre les problèmes d'optimisation spéciques aux micro-usines. Les micro-usines ont des propriétés qui les diérencient des usines traditionnelles, par exemple leurs possibilités de reconguration et de moindres contraintes géographiques. Ces spécicités les font ressembler par bien des points aux grilles de calcul, comme nous le montrerons au chapitre 1. Le lien entre la production de pièces à partir d'une gamme de production, schéma qui donne l'organisation des tâches à eectuer pour obtenir un produit, et la notion de workow est mis en évidence. Le problème de l'ordonnancement est alors similaire puisque nous avons dans les deux cas des lots de tâches, hétérogènes, à exécuter sur une plate-forme, elle aussi hétérogène. Dans le cas des micro-usines, comme dans celui des grilles de calcul, le critère d'optimisation décide alors de l'approche à retenir pour obtenir un ordonnancement ecace. En eet, s'il est envisageable pour un ux vidéo de tendre vers l'inni dans la mesure où celui-ci est traité en continu pendant un temps susamment long, il est plus dicile d'envisager une production tendant vers l'inni. D'autant plus que, en raison de leur exibilité, les productions envisagées sur les micro-usines sont plutôt de l'ordre du millier de sorties. Il convient alors d'évaluer la portée des diérentes approches et de proposer des adaptations pour mieux connaître la portée des solutions que nous avons évoquées précédemment. Plus précisément, le travail que nous avons eectué concerne l'optimisation de l'exécution d'un lot de jobs dont la structure, en terme de tâches, dépendances et caractéristiques, est identique sur des plates-formes hétérogènes. Notre contribution montre la portée des algorithmes étudiés, principalement en fonction de la taille du lot, et comprend les améliorations apportées aux diérents algorithmes, et plus particulièrement à l'algorithme d'ordonnancement en régime permanent an d'en permettre une utilisation en pratique (taille des lots bornés). L'ensemble du travail a été validé par simulation et les résultats obtenus complètent notre connaissance de l'ecacité de l'ordonnancement dans ce contexte. Le présent document est organisé en 6 chapitres. Nous donnons d'abord le contexte avant de dénir de manière plus formelle le modèle d'applications et le modèle de plates-formes auxquelles nous nous intéressons. Puis, nous évaluons diérents algorithmes. Les deux premiers chapitres sont consacrés à la dénition du contexte et du positionnement de notre travail. Ainsi, dans le chapitre 1 nous nous intéressons aux grilles de calcul, aux microusines et aux applications qui en tirent parti. En ce qui concerne les grilles, nous brossons un historique avant de décrire les diérentes catégories de grilles matérielles, ce qui nous permet d'en tirer quelques propriétés qui nous ont paru plus signicatives dans notre contexte. La

13 TABLE DES MATIÈRES 3 description des diérentes applications qui utilisent les grilles est ensuite l'occasion de mieux détailler les applications visées et le vocabulaire utilisé par la suite. Une approche similaire est utilisée pour la description des micro-usines. Nous terminons ce chapitre par une étude des similitudes des deux contextes. La première la contribution de notre travail est donnée au chapitre 2. Nous y dénissons successivement, à partir des caractéristiques des plates-formes, les modèles de micro-usine et de grilles de calcul sur lesquels nous avons travaillé. La cohérence des deux modèles est soulignée, ce qui fait que les travaux que nous présentons par la suite peuvent s'appliquer aux deux contextes. Certaines diérences existent cependant, ce qui montre la limite des similitudes et leurs conséquences sur notre étude. Le chapitre 3 est consacré à un état de l'art sur les techniques d'ordonnancement existantes. Nous nous concentrons rapidement sur le cas qui nous intéresse ici, celui de l'optimisation du temps d'exécution de lots de jobs multi-tâches sur des plates-formes hétérogènes. Nous donnons une description détaillée des deux algorithmes que nous nous avons principalement étudiés, le GATS et le régime permanent. Nous présentons au chapitre 4 les trois algorithmes que nous avons plus particulièrement étudiés et optimisés pour notre contexte. Un algorithme de liste de type HEFT (Heterogeneous Earliest Finish Time) nous sert de référence pour comparer les comportements des autres algorithmes à un algorithme classique. L'algorithme du GATS, qui applique une méta-heuristique génétique à une solution initiale de type liste, nous permet d'établir les améliorations possibles depuis la solution heuristique initiale. Enn, l'algorithme d'ordonnancement en régime permanent nous permet de comparer les solutions données par des algorithmes conçus pour optimiser le makespan à cette approche qui optimise le ux. Chacun de ces algorithmes a nécessité une adaptation pour mieux répondre aux spécicités de l'ordonnancement de lots de workows identiques. Les premières modications, celles présentées dans ce chapitre, visent un modèle où les communications peuvent être négligées. Le chapitre 5 traite du cas où les communications doivent être prises en compte pour avoir un ordonnancement réaliste. Après en avoir montré les limites, nous nous concentrons sur les deux améliorations que nous proposons pour l'algorithme d'ordonnancement en régime permanent. La première vise à réduire le nombre de dépendances entre les périodes pour limiter le nombre d'instances en cours de traitement. La seconde amélioration repose sur une dégradation du ux donné par la solution optimale an de réduire la taille de la période et ainsi limiter l'impact des seules phases sous-optimales de cette approche, les phases d'initialisation et de terminaison. L'évaluation des algorithmes et de leurs améliorations est donnée dans le dernier chapitre, le chapitre 6. Dans la mesure où une part des algorithmes a un comportement dynamique, nous avons développé un simulateur pour réaliser cette étude. Nous présentons donc d'abord le simulateur utilisé pour réaliser l'évaluation. Nous détaillons ensuite le protocole de simulation et la métrique mise en place pour obtenir des résultats signicatifs. Les résultats sont donnés en deux parties, d'abord pour des plates-formes où nous ne tenons pas compte des communications, ensuite avec des communications non négligeables. Nous terminons notre document par une conclusion qui synthétise notre contribution et donne les perspectives de recherche pour la suite de ce travail.

14 4 TABLE DES MATIÈRES

15 Chapitre 1 Contexte Dans ce chapitre nous présentons le contexte qui motive notre travail. Ce contexte repose sur deux cas d'application, apparemment complètement dissociés, mais qui présentent pour notre étude des similitudes permettant d'envisager l'utilisation de résultats sur l'ordonnancement dans ces deux cas. Nous nous attachons à montrer dans ce chapitre la proximité des deux contextes. La première partie du chapitre donne un aperçu sur les grilles de calcul, les raisons qui ont motivé leur développement, les modèles couramment utilisés et les applications qui les utilisent. Nous développons, à la n de cette partie, le cas particulier des applications multi-tâches et plus particulièrement des applications de type workow. La seconde partie est consacrée aux microusines : leur évolution, l'état actuel des réalisations et les modèles pressentis pour les micro-usines du futur. Nous terminons ce chapitre en soulignant les convergences et les divergences entre les deux types de plates-formes étudiées. 1 Grilles de calculs Le terme grille de calcul (computing grid) vient d'une analogie avec le réseau électrique (power grid). En eet, la révolution de l'électricité ne vient pas des innovations dans les équipements électriques, mais de la distribution simple et universelle de la puissance électrique. Pour Foster et al. [42], la révolution en termes de calcul ne vient pas simplement d'ordinateurs de plus en plus performants, mais de l'interconnexion de nombreuses ressources de calcul, ce qui permet une distribution simple et universelle de la puissance de calcul. Cette mutualisation des ressources permet un accès économique à une forte puissance de calcul. 1.1 Historique L'émergence des grilles de calcul repose sur quelques faits historiques que nous présentons ici, concernant le calcul haute performance, les réseaux de communication et l'interconnexion des super-calculateurs. 5

16 6 Chapitre 1. Contexte Le calcul haute performance Le besoin en performance d'applications utilisant une forte puissance de calcul comme les prévisions météorologiques, l'étude du climat, la modélisation moléculaire, les simulations physiques (par exemple, l'aérodynamique, la résistance des matériaux, les réactions nucléaires) a poussé les industriels à créer des super-ordinateurs. C'est dans les années 1960 qu'apparaissent les premiers super-ordinateurs qui rencontrent un succès industriel. Par exemple, le Control Data 6600 construit par Seymour Cray [95]. Ce dernier crée plus tard sa propre société qui produira par la suite la série des super-ordinateurs Cray, dont la première version, Cray-1 (lire Cray-one), est mise en production en 1976 [84]. À l'origine, ces machines étaient extrêmement spécialisées. Dans les années 1970, le marché était occupé par des super-ordinateurs utilisant un processeur vectoriel, processeur qui applique une seule instruction à un grand nombre de données. Puis, des architectures dotées d'un grand nombre d'unités de calcul a vu le jour sous la forme des machines massivement parallèles. Au cours de la décennie 80 ces super-ordinateurs ont d'abord été composés de milliers de processeurs de petites tailles, par exemple la CM-1 ou encore la MP-1. La CM-1 est la première machine de la série des Connection-Machines [97] de l'entreprise Thinking-Machine, la CM-1 est dotée de processeurs 4-bit organisés en hypercube. La MP-1 [71] développée par la société MasPar peut contenir jusqu'à processeurs 4-bit. Ces deux machines, la CM-1 et la MP-1 obéissent au paradigme du traitement vectoriel SIMD, Single Instruction/Multiple Data, qui permet d'eectuer en parallèle la même instruction sur un grand nombre de données. Ces architectures ont ensuite utilisé des processeurs plus puissants. Par exemple la Connection- Machines CM-5 qui utilise des processeurs SPARC, ou son évolution, la CM-5e qui utilise des SuperSPARC. Ces nouvelles architectures abandonnent le paradigme SIMD au prot du paradigme MIMD, Multiple Instruction/Multiple Data, dans ce paradigme il est possible de réaliser en parallèle diérentes instructions sur diérentes données. Les processeurs présents dans les super-ordinateurs actuels sont principalement des processeurs grand public interconnectés par des réseaux hautes performances. Par exemple, dans le TOP-500 de juin 2009, la première machine est le Roadrunner [6] constitué de coeurs IBM PowerXCell 8i 1 et de coeurs AMD Opteron. Dans le TOP-500 de juin 20 0ce classement, les processeurs grand public (Intel, AMD et IBM) représentent 98 2 % des processeurs utilisé dans les 500 machines les plus puissantes, contre 13 6 % en juin Aujourd'hui, avec l'arrivée du GPGPU, General-Purpose Processing on Graphics Processing Units, le traitement vectoriel est à nouveau présent sur le marché Les réseaux de communication En parallèle au développement du calcul haute performance, se sont développés les réseaux de communication. Les réseaux étaient d'abord internes, puis, au milieu des années 1960, est né le projet de création d'un réseau informatique délocalisé : Arpanet. Ce projet, initié par le DARPA (Defense Advanced Research Projects Agency, l'agence américaine pour les projets de recherche avancée de défense), permet à la n des années 1960 l'interconnexion des quatre premiers réseaux : l'université de Californie à Los Angeles, l'institut de recherche de Stanford, l'université de Californie à Santa Barbara et l'université d'utah [83]. 1 Le PowerXCell 8i est une variante du processeur Cell utilisé dans la console de jeu PlayStation 3

17 1 Grilles de calculs 7 Arpanet a continué à croître dans les années 1970, pour atteindre 23 n uds en 1971, 111 en 1977 et plus de 4 millions en À l'initiative du DARPA, Jonathan Postel édite en 1981 les RFC (Requests For Comments : système ouvert de normalisation d'internet), qui vont standardiser les protocoles réseaux et permettre Internet tel qu'il est connu aujourd'hui [78, 79]. Dans les années 1990, tous les éléments sont présents pour l'interconnexion des super-ordinateurs ; les technologies réseaux et les technologies de calcul haute performance sont matures Interconnexion des super-ordinateurs Les super-ordinateurs ont un coût important à l'achat et à l'exploitation avec l'utilisation d'électricité et l'entretien. Lorsque les ressources de calcul ne susent plus, il faut investir dans du nouveau matériel. De plus, lorsque ces ordinateurs n'eectuent aucun calcul, le coût d'exploitation reste le même alors que les processeurs sont inactifs. Avec l'avènement des réseaux de communication, la mutualisation des ressources de calcul est devenue possible. Ainsi, lorsqu'un super-ordinateur n'est pas utilisé, d'autres utilisateurs peuvent y eectuer des calculs à distance. Ce désir de relier ensemble des super-ordinateurs est né dans les années 1990 aux États-Unis. Larry Smarr, alors directeur du National Center for Supercomputing Applications (NCSA), inventa le terme de metacomputing pour désigner la construction d'un super-ordinateur virtuel qui regroupe des super-ordinateurs à travers des réseaux à haute vitesse [91]. Dans les années 1995, le projet I-WAY, Information Wide Area Year [30], vise à relier les super-ordinateurs à travers les réseaux existants. En 1997, Ian Foster et Carl Kesselman proposent le projet Globus [41] : il s'agit d'un ensemble d'outils pour le metacomputing. Leur première implémentation utilise l'infrastructure réseaux de I-WAY. C'est la naissance de la grille de calcul telle qu'elle est connue aujourd'hui. Cette grille est un ensemble d'outils permettant de s'abstraire de l'architecture réseaux pour orir un accès à des ressources distribuées. 1.2 Caractéristiques Le terme de grille ne caractérise pas clairement une infrastructure ; c'est pourquoi, en 2001, Foster et al. proposent une première dénition informelle de la grille [43]. Ils dénissent le terme de VO (virtual organization, organisation virtuelle). Ces VO régissent les règles de partages intersites. Ainsi, un site peut appartenir à plusieurs VO et dénir des règles diérentes d'accès aux ressources pour chaque VO, par exemple quels programmes peuvent être exécutés et quand?, ou encore quelles quantités de données peuvent être stockées?. Dans leurs travaux, Foster et al. séparent leur architecture en diérentes couches. À la base, la couche Fabric représente les ressources partageables comme les processeurs ou les espaces de stockage. Au sommet des couches, se trouve l'application distribuée. Au milieu se trouvent trois couches permettant à l'application d'accéder à la couche Fabric : l'authentication, la représentation d'une ressource et la représentation globale des ressources. Foster et al. établissent, dans cette architecture, une dénition de protocoles entre ces diérentes ressources pour permettre un accès universel. En 2003, Németh et Sunderam proposent une dénition formelle de la grille [70]. Ils modélisent la grille comme un système multi-agent déni par une Abstract State Machine [49]. Ils établissent que la diérence principale entre une grille et un système distribué traditionnel

18 8 Chapitre 1. Contexte est la nécessité dans la grille d'associer ressources et utilisateurs. Dans un système distribué, l'utilisateur choisit directement les ressources utilisées. Cette distinction est nécessaire, d'une part, à cause de la diérence du nombre de ressources considérées, et d'autre part, à cause de l'aspect dynamique de la présence des ressources dans la grille. Foster et al. proposent une catégorisation des diérents usages de la grille [42], en isolant cinq types d'applications : le calcul haute performance distribué, dont le but est d'obtenir assez de ressources pour eectuer des calculs fortement dépendants les uns des autres ; le calcul haut débit, où, à la diérence du calcul haute performance, un grand nombre de calculs indépendants doivent être résolus ; le calcul à la demande, qui répond à un besoin sporadique de ressources de calcul ou de stockage ; le calcul orienté données, pour lequel l'analyse de données distribuées géographiquement permet la synthèse de nouvelles données ; le calcul collaboratif, qui propose à des utilisateurs distribués géographiquement un environnement de stockage et de calcul permettant une collaboration. 1.3 Exploitation des grilles de calculs Dans un super-ordinateur ou une grappe de calculs, la totalité des n uds accessibles à un utilisateur est connue à l'avance. L'utilisateur connaît leur nombre et leur performance, il peut donc, à l'aide d'outils comme MPI, Interface de Passage de Messages, ou PVM, Machine Virtuelle Parallèle, programmer et exécuter son application sur ces ressources. Dans la grille de calcul, ces données ne sont pas forcément disponibles, il faut donc inventer des outils logiciels pour exploiter cette plate-forme hétérogène. Ces outils ont des rôles de déploiement d'applications, de sécurisation des exécutions, de gestion des données ou encore d'ordonnancement de tâches sur les diérentes ressources. Suivant le mode d'exploitation des ressources, diérentes catégories de grilles sont identiées dans la littérature. Ce mode d'exploitation sous-entend des modes d'utilisation diérents en programmation et en exécution. Les trois grandes catégories de grilles classiquement identiées sont les suivantes : Les grilles pair-à-pair (peer-to-peer grids ou desktop grids). Ces grilles agrègent des ressources de petite taille, en général des ordinateurs personnels mis à disposition par des particuliers. Chacune des ressources est alors utilisée pour exécuter une instance de programme qui concourt à la résolution d'un problème sur un ensemble de données. Dans la suite, nous illustrons cette approche avec le projet XtremWeb. Les grilles de ressources qui visent à regrouper des ensembles plus importants de capacités de calcul tels que des clusters pour former des ensembles virtuels de grande taille. Ce type de grille est illustré par le Globus Toolkit. Les grilles de service (ou d'applications) proposent à des utilisateurs d'accéder directement aux applications hautes performances qui sont déployées sur la grille. L'idée est ici plutôt

19 1 Grilles de calculs 9 d'exploiter des ressources logicielles, par exemple celles qui sont déployées sur les grilles de ressources, pour permettre une utilisation aisée de la grille à des scientiques non experts. Ce type d'approche est représentée par le logiciel DIET XtremWeb L'idée d'utiliser les cycles inutilisés de machines (idle time) naît dans les années 1980, Shoch et Hupp présente dans [90] un ver informatique capable de se répliquer et de se diuser à d'autres machines de façon autonome. Ce ver utilise les cycles inutilisés des machines pour eectuer des calculs. En 1988 Litzkow et al. propose la plate-forme centralisée Condor [63] qui ordonnance des calculs sur les machines libres à l'intérieur d'une organisation. C'est la naissance des desktop grids, plates-formes de distribution de calculs indépendants pour récupérer les cycles inutilisés de machines. Dans un desktop grids, un utilisateur qui propose des cycles de sa machine a le droit de soumettre lui même des calculs, si l'administrateur du système lui en donne le droit. Les Systèmes de Calcul Volontaire, Volunteer Computing system, sont une forme diérente de desktop grids. Dans un tel système, l'utilisateur qui propose sa machine ne peut pas soumettre de calcul, il choisit simplement de contribuer à un projet en lui orant des cycles de sa machines. BOINC [3] est l'exemple le plus important de tel systèmes, issu de l'équipe qui a développé le projet SETI@home [4], il représente aujourd'hui une plate-forme générique pour toutes les applications de C'est à dire une plate-forme fortement résistante aux fautes, permettant une participation à grande échelle d'ordinateurs hétérogènes, à la fois des ordinateurs personnels et des super-ordinateurs, à des calculs faiblement couplés. XtremWeb [20] réunit les deux approches, c'est-à-dire à la fois une participation à grande échelle, et la possibilité, pour chaque participant, de soumettre à son tour des calculs. Cependant, comme dans les deux modèles précédents, cette plate-forme est limitée à l'exécution de calcul faiblement couplés, il n'est pas possible d'exprimer des dépendances entre chaque calcul pendant leur exécution. La gestion des dépendances doit se faire a posteriori : ou l'application qui a soumis les calculs reçoit les résultats et réalise que le travail est ni, ou elle soumet à nouveau les traitements dépendants de ceux-ci. Certaines plates-formes proposent d'utiliser des cycles disponibles des machines personnelles tout en permettant une communication entre les tâches exécutées. Leur modèle se rapproche alors de celui des grilles de calcul que nous voyons au paragraphe suivant. Les diérences portent, par rapport aux grilles de ressources les plus répandues, plus sur les caractéristiques de performance des ressources : bande passante plus faible, moins grand couplage, etc Globus Toolkit Foster et al. [41] partent, pour caractériser la grille de calcul, du constat que cette grille présente un certain nombre de dés par rapport aux super-ordinateurs : passage à l'échelle : le nombre de n uds disponibles dans une grille de calcul varie constamment et, idéalement, l'écriture d'une application distribuée ne devrait se faire qu'une seule fois, celle-ci passerait à l'échelle automatiquement ; forte hétérogénéité : dans la grille, l'hétérogénéité est partout : au niveau des processeurs, des liens de communications ou encore au niveau des logiciels et bibliothèques présents

20 10 Chapitre 1. Contexte sur chaque n ud. Ceci a un impact fort sur les performances d'exécution ; structure non prédictible : à chaque exécution d'une application distribuée sur la grille, les n uds participant au calcul sont diérents, ce qui impose de prendre en compte dynamiquement les caractéristiques de ressources ; comportement non prédictible : les ressources participant à l'exécution d'une application distribuée (liens de communications, processeurs) sont partagées par d'autres applications ; administration des ressources : les ressources présentes dans une grille appartiennent à de nombreuses entités, il n'y a pas d'administration centralisée des ressources. C'est pourquoi, en 1997, Foster et al. créent Globus Toolkit. Ce dernier propose un certain nombre d'outils permettant une abstraction des dicultés particulières de la grille. Il permet l'abstraction de la recherche des moyens nécessaires à une application et à la réservation de ceux-ci, une abstraction des communications, de l'authentication des utilisateurs et des ressources, de la gestion de données distribuées et une abstraction de la création et de l'exécution de processus sur une ressource. Avec ces diérents outils, Foster et al. posent des bases pour l'implémentation de services simpliant la création d'applications distribuées. Aujourd'hui, sous la version 4, Globus continue son évolution et implémente un certain nombre de services simpliant le développement d'applications distribuées simples [40]. Les grilles de ressources sont conçues pour l'exécution de grandes applications parallèles avec des possibilités d'adaptation à des contextes d'exécution diérents. Leur utilisation est généralement réservée aux personnes qui possèdent déjà une connaissance de la programmation parallèle et des environnements d'exécution hétérogènes. Elles exigent une expertise du domaine DIET DIET [21], Distributed Interactive Engineering Toolbox, est un intergiciel, middleware, permettant le développement d'applications distribuées sur la base de la notion de service. Il propose une architecture permettant de rechercher les serveurs distants qui rendent accessibles à distance les services demandés. Du point de vue de l'application, elle soumet la liste des services nécessaires à son exécution à DIET, qui retourne une liste d'objets distants CORBA répondant aux exigences. CORBA [99] est un standard dénissant un protocole d'appels de procédure distante, Remote Procedure Call (RPC). L'application, peut alors utiliser ces objets distants pour réaliser des exécutions transparentes sur des serveurs distants. L'architecture DIET, comme celle des grilles d'applications, repose donc sur la soumission de requêtes de calcul et vise au choix d'un serveur adapté à l'exécution de chacune des requêtes. L'utilisation la plus simple de ces grilles consiste donc à soumettre des requêtes unitaires. Il est cependant courant soit que les données qui sont utilisées en entrée du calcul proviennent elles-mêmes d'un autre calcul, soit que les données calculées par la requête servent d'entrée à un autre calcul. L'enchaînement de requêtes a déjà été prévu dans DIET à travers l'architecture de gestion des données DTM [31] et celle de gestion des workows MA DAG [2]. Ces fonctionnalités ne permettent cependant que de réaliser un ordonnancement en ligne de type liste car aucune prédiction n'est prise en compte avant qu'une tâche soit libre de l'ensemble de ses dépendances. La normalisation de ce type d'environnements de grilles, à travers des normes telles que

21 1 Grilles de calculs 11 celles du Grid-RPC 2, permet d'envisager une diusion de cette approche qui favoriserait une utilisation de la grille à gros grain : celui des applications. L'approche proposée permet un accès aux grilles plus simple que le niveau des grilles de ressources car les utilisateurs qui ne connaissent pas la programmation parallèle, peuvent accéder à la puissance de la grille avec un investissement limité en utilisant directement les applications parallèles déployées, comme s'ils utilisaient des bibliothèques. Ainsi leur travail ne consiste plus qu'à dénir les paramètres d'entrée des applications et l'enchaînement des exécutions entre applications comme il le ferait sur un outils de calcul numérique de type scilab. La place grandissante des architectures orientées service, ou Software as a Service (Saas), auxquelles peut s'apparenter l'approche Grid-ASP permet de supposer que l'approche grilles d'applications ira grandissante dans les années à venir du fait de la simplication de l'utilisation qu'elle apporte. Dans le cloud computing [22], les applications, et les données, sont distribuées sur le réseau, le nuage. Elles se trouvent alors dans des contextes hétérogènes tant du point de vue du déploiement, toutes les applications ne sont pas disponibles sur tous les n uds, des performances d'exécution et des performances du réseau. La mise en uvre ecace devient alors complexe et une assistance est indispensable pour aider l'utilisateur dans les choix qui s'orent à lui : quelles instances d'application utiliser? comme ordonnancer les exécutions? etc. La caractéristique commune que nous pouvons dégager de l'ensemble des modèles de grilles que nous venons de voir est leur hétérogénéité. Cette hétérogénéité se retrouve à plusieurs niveaux des grilles : les topologies et les débits réseau, les performances et architectures des ordinateurs. Elle induit, pour les applications, une diculté supplémentaire pour l'exécution dans les environnements de grille. Nous voyons donc dans la partie suivante les propriétés des applications concernées. 1.4 Applications et grilles de calculs Diérents types d'applications peuvent tirer parti d'une exécution sur une grille de calcul, qu'elle soit orientée ressources ou d'applications. Notons d'ailleurs qu'il est possible de faire un parallèle, à un niveau de granularité près, entre les exécutions sur ces deux types de grilles. En eet, l'exécution d'un processus sur une grille de ressources peut être considérée de la même manière, c'est à dire comme une exécution unitaire, que l'exécution d'une application sur une grille d'applications, même si cette application est parallèle. De la même manière l'exécution d'une application parallèle sur une grille de ressources soulève des problématiques proches de celles de l'exécution coordonnée d'un ensemble d'applications sur une grille d'applications. Il est important de souligner ici que, dans ce second cas, les tâches elles-mêmes peuvent être des composants parallèles, comme dans un cas d'utilisation d'une plate-forme comme DIET, ou non. A ce niveau, il est nécessaire de faire une première distinction entre une application monotâche, qui s'exécute sur une seule machine ou un seul cluster, et une application multi-tâches, qui utilise un ensemble de machines voire une grille car les problématiques induites en terme d'ordonnancement sont diérentes. Les applications que nous visons pour la grille de calcul sont les applications multi-tâches. Dans la suite de cette partie nous précisons les diérents types d'applications multi-tâches. 2

22 12 Chapitre 1. Contexte Applications multi-tâches Lorsque le nombre de processus ou d'applications composant une exécution augmente nous sommes confrontés à une classe d'applications que nous appelons ici applications multi-tâches. Dans ce cas, le modèle applicatif revient à une application composée de tâches avec dépendances. Ces tâches sont souvent contraintes entre elles par une relation d'ordre partielle [28, 19, 67, 107] qui est généralement représentée par les arcs d'un DAG, ou graphe d'application. Dans ce DAG, chaque noeud représente une des tâches nécessaire à l'exécution de l'application et chacune des arrêtes représente une dépendance. Ce modèle s'applique aussi bien dans le contexte des grilles de ressources, nous avons évoqué le cas des applications parallèles, que de grilles d'applications. En eet, comme nous l'avons vu avec DIET, les grilles peuvent servir de support à la mise en uvre de couplage de code. Le couplage de code est une pratique fréquente dans le cadre de problèmes complets qui consiste à utiliser la sortie d'une application comme entrée d'une autre, la combinaison des deux applications permettant un traitement plus complet du modèle ou plusieurs aspects d'un même problème comme dans le couplage multi-physique. Par exemple les résultats d'un écoulement calculés par un code de mécanique des uides peuvent être utilisés pour calculer la vibration induite par cet écoulement par un code de propagation d'onde. Dans la littérature, les appellations sur ce type d'application n'utilisent pas toutes le même vocabulaire et n'associe pas toutes la même signication au terme workow. Dans [58] ou [102], le workow correspond à un DAG d'exécution pour une application parallèle. Ce DAG est lié à l'application. Il peut être réutilisé mais la plate-forme ne considère qu'une seule instance d'exécution de cette application à la fois. Dans [100] et [13], les travaux réalisés considèrent un workow comme un modèle d'exécution pour un lot, voire un ux, de données à traiter. Globalement nous retiendrons, comme la dénition donnée dans [104], que la notion de work- ow permet de dénir une structure d'exécution répétable appliquée à des jeux de données diérents [59, 77]. Les caractéristiques de la répétition interviennent alors dans la manière dont pourra être traité le workow. En particulier, nous diérencions les répétitions régulières, où le même DAG est répété un grand nombre de fois sur des données similaires donc avec des propriétés identiques et nous parlerons alors de lots de jobs ou de lots de workows, des répétitions irrégulières, plus sporadiques, où un même workow est appliqué de temps en temps sur une donnée ou même sur des données de tailles variables donc avec des propriétés diérentes. Dans la suite, nous ne conservons cependant le terme de workow que pour le cas répété et régulier. Nous désignons par modèle d'exécution, ou application multi-tâches si la répétition n'est pas envisagée, le cas où les exécutions sont réalisées en ne considérant qu'une seule instance. A partir des architectures de grille que nous venons de voir et plus particulièrement celles des grilles d'applications, il est envisageable d'optimiser l'exécution de ces workows. La mise en uvre peut reposer sur une première phase d'interrogation de la plate-forme de manière à collecter des informations sur les performances des applications déployées, qui est faite en utilisant les services du middleware de grille d'application. Un logiciel tel que DIET est en eet capable de fournir une liste de serveurs disponibles et les performances attendues en fonction des caractéristiques de la demande. Cette phase permet ainsi de savoir, quels sont les serveurs disponibles et plus particulièrement ceux qui fournissent les diérentes applications utilisées par le job ainsi que les performances de ces serveurs pour l'exécution de ces applications. Puisque nous disposons de ces informations, il est alors possible de calculer un ordonnancement optimisant

23 1 Grilles de calculs 13 l'utilisation des serveurs et des applications Workows et grilles de calculs Les approches permettant l'exécution de lots d'applications sur la grille sont basées sur la notion de workow régulier vue précédemment. Dans ce contexte, les applications du workow sont identiques et ne dièrent que par les données. Comme nous l'avons dit, si les données dièrent, elles engendrent malgré tout des temps d'exécution équivalents ce qui fait que les propriétés de cette exécution, telles que les consommations processeur ou réseau restent constantes sur le lot. En eet, si cela n'est pas le cas nous revenons à un cas irrégulier. De nombreux exemples pratiques de workows sont décrits dans la littérature. Dans [29], les caractéristiques d'une application visant à la prédiction de tremblements de terre sont décrites dans un workow constitué d'une première phase globale de calcul parallèle suivie de deux phases constituées de tâches indépendantes avant un regroupement des résultats pour constituer la courbe nale des résultats. Ce workow est appliqué à un grand nombre de localisations dans le but d'établir une carte prédictive. Dans [69] ce sont des workows destinés à traiter des images médicales : ils permettent l'analyse ou l'extraction d'informations qui sont décrits. D'une manière générale, le traitement de suites d'images est souvent confronté à ces traitements en série avec l'application de ltres pour la recherche d'éléments spéciques. La structure de la gure 1.1 pourrait ainsi être utilisée pour reconstituer une animation 3D à partir d'images issues d'une vue stéréoscopique auxquelles sont appliquées un ltre permettant de lisser les enchaînements. A 2 B 1 C 2 4 D A Figure 1.1 Application Le cas auquel nous nous intéressons, l'exécution de workows, peut être traité d'une manière équivalente à celle des applications multi-tâches, à condition de disposer d'un algorithme d'ordonnancement adapté, capable de prendre en charge ce cas particulier et de fournir de bonnes performances. La gure 1.1 montre un exemple d'application à ordonnancer qui nécessite les services A, B, C et D. En soumettant cette liste de services à un outil de recherche de services dans la grille, tel que celui proposé par DIET, le résultat est une matrice des performances attendues pour chaque service pour chacun des déploiements accessibles. L'outil donne également un graphe des bandes passantes entre les diérents serveurs disponibles. Le traitement de ce type de lots suppose la soumission de l'ensemble des jobs en une seule fois et son exécution de manière à proter au maximum des ressources. Un certain nombre de propriétés diérencient alors ce type de soumissions d'une soumission irrégulière. Tout d'abord la régularité des temps d'exécution des diérentes tâches composant un job laisse supposer la possibilité d'un traitement diérent de celui appliqué dans le cas d'exécutions irrégulière, justement en exploitant cette régularité. D'autre part, chacun des jobs du lot étant non connexe avec les autres, donc sans dépendance, nous pouvons espérer dans la planication de l'exécution