Rapport de fin de stage

Transcription

1 Rapport de fin de stage Écoulement de la charge sur le système à image unique Kerrighed : application au domaine de la biologie. par Jérôme Gallard Équipe d accueil : PARIS Encadrement : Christine Morin - Pascal Gallard Septembre 2006 Contact : IRISA / INRIA Rennes Campus universitaire de Beaulieu Avenue du Général Leclerc RENNES Cedex - France Téléphone :

2

3 Remerciements Je souhaite remercier toute l équipe PARIS qui m a suivi et encadré tout au long de mon stage et particulièrement Christine Morin mon encadrant qui m a toujours été de bon conseil, m a toujours laissé libre court dans la gestion de mon travail et qui a bien voulu lire et relire ce rapport un nombre incalculable de fois! Je tiens également à remercier mon frère Pascal Gallard qui m a aussi encadré (aussi bien sur le plan des concepts que sur celui de la technique), soutenu et éclairé sur différents points tout au long de cette année! J aimerais également remercier tout le personnel de l ENSSAT (enseignant, personnel administratif, direction des études,...) qui m a guidé durant ces trois années sur le chemin du métier d ingénieur! Enfin, j adresse aussi mes remerciements les plus chaleureux à ma famille (mes parents, mes grand-parents, mon fidèle cousin,...) et à mes amis (ma tite Elvire, mon binome, Estelle, Fred,...) qui ont toujours été là pour moi au cours de ces trois années.

4

5 TABLE DES MATIÈRES I Table des matières Résumé V Mots-Clés V Abstract V Keywords V Introduction 1 1 Présentation Le cadre de travail L IRISA : une unité de recherche L équipe PARIS L activité de recherche Kerrighed Contexte de travail Introduction L informatique au service de la biologie Les besoins L application MrBayes L état de l art Les grappes de calculateurs Gestion des travaux sur grappes de calculateurs Introduction aux systèmes à exécution par lots Les principaux critères d évaluation Les fonctionnalités des systèmes à exécution par lots Les systèmes à image unique Présentation Les fonctionnalités qu offrent les systèmes à image unique Différents systèmes à image unique Kerrighed Synthèse Exécution différée de processus dans Kerrighed Motivation La gestion des processus

6 II TABLE DES MATIÈRES La gestion des processus dans un système Linux standard La gestion des processus avec Kerrighed Les principes de conception Vue d ensemble Gestion des processus différés Mise en œuvre dans Kerrighed Mise en liste d attente d un processus différé Introduction à la fonction fork() À quel moment devons nous bloquer la création du processus? La capacité FORK DELAY Instrumentation du do fork() Instrumentation de la structure task struct Gestion de la liste des processus différés Gestion du réveil des processus Présentation des différentes stratégies possibles Définition de l interface (API ) Réveil à l initiative d un nœud dans un anneau à jeton Réveil à l initiative de chaque nœud Comparaison qualitative des deux stratégies implémentées Ordonnancement des processus gérés en mode différé Préambule Ordonnanceur de Kerrighed : la fonction migration manager thread() Quand arrêter un processus différé Détection d un processus à arrêter Arrêt d un processus différé Synthèse La charge virtuelle : vload Le principe de la charge virtuelle (vload) Instrumentation du do exit() Évaluation Description du plan de tests Le matériel utilisé Notre application de simulation Étude comparative Étude théorique Les résultats Conclusion Étude des performances sans la capacité de migration Processus longs Processus courts Étude des performances avec la capacité de migration Synthèse

7 TABLE DES MATIÈRES III 5.6 Ordonnancement des applications Conclusion 51 Bibliographie Glossaire IX XI A Annexe XIII A.1 Le champs fd status XIII A.1.1 int check and block(struct task struct *tsk) XIII A.1.2 int check and unblock(struct task struct *tsk) XIII A.1.3 void add a pfd at the end of the list(struct task struct *tsk).. XIII A.2 Activation de la gestion des processus différés XIV A.3 Réveil à l initiative d un nœud sur un anneau à jeton XIV A.3.1 La fonction handle admin(); XIV A.3.2 La fonction handle jeton(); XV A.4 Pseudo-algorithme de notre application de simulation XVI

8 IV TABLE DES MATIÈRES

9 Résumé Le travail présenté dans le rapport a été effectué dans le cadre d un stage de fin d étude à l IRISA de Rennes. L IRISA est une unité de recherche dont l une des activités est le calcul à haute performance qui peut être obtenue par l utilisation de grappes de calculateurs. Cependant l utilisation de ressources distribuées au sein d une grappe n est pas simple. Kerrighed est un système d exploitation à image unique permettant de virtualiser un ensemble de ressources distribuées. Ainsi, l utilisateur a l impression que sa grappe de calculateurs est comme une seule machine multiprocesseur avec une mémoire partagée entre l ensemble des ordinateurs. Nous voulons étudier le comportement de Kerrighed avec des applications de type bio-informatique demandant beaucoup d heures de calcul et pouvant saturer tout système informatique. Les systèmes à exécution par lots permettent de gérer cette classe d application. Nous étudions de quelle manière il serait possible d intégrer à Kerrighed les fonctionnalités des systèmes à exécution par lots afin qu il puisse gérer au mieux l exécution de ce genre d application. Mots-Clés : Kerrighed, Linux, système d exploitation, grappe, système distribué, système à exécution par lots, ordonnancement de processus, Fork Delay, bio-informatique, LiveCD, Knoppix. Abstract We carried out our training period at IRISA, Rennes. IRISA is a research unit. One of its research activities is about high performance computing. Nowadays, industries need high performance computing to perform simulations. High performance computing can be reached with clusters. Clusters are not easy to use as their resources are distributed in different nodes. Kerrighed is a Single System Image Operating System and it eases cluster use by providing the illusion of a single virtual multiprocessor to users. This virtual computer provides the resources (CPU, memory, hard disk...) of the whole cluster that appears as a single machine. We want to study the behavior of Kerrighed with bioinformatics applications. For that, we took contacts with a laboratory of biology in Wales. They proposed to us the study of a class of application requiring hours of computation and being able to saturate any information processing system. There are systems making it possible to manage this class of application. They are called systems of batch scheduling. We study how it would be possible to integrate into Kerrighed the functionalities of a batch scheduling system so that it can manage as well as possible the execution of this kind of application. Keywords : Kerrighed, Linux, operating system, cluster, distributed system, batch scheduling, process scheduling, Fork Delay, bioinformatics, LiveCD, Knoppix. V

10 VI RÉSUMÉ

11 Introduction De nos jours, la puissance de calcul est de plus en plus désirée. Cela est dû au fait que de plus en plus de tâches sont informatisées et traitées de manière automatique. Cependant, cette puissance de calcul est une ressource limitée (même dans des centres de calcul dédiés). Elle doit donc être gérée au mieux afin d en tirer un profit maximum. Prenons par exemple le cas d une équipe de biologistes. Ils disposent d applications informatiques dont le temps de calcul peut dépasser aisément la centaine d heures. Dans la plupart des cas, les laboratoires de biologie ne possèdent pas d ordinateurs de calcul dédiés et les biologistes ne sont pas des spécialistes en informatique. Ils veulent cependant gérer au mieux les ressources (les ordinateurs) dont ils disposent afin d obtenir dans les meilleurs délais leurs résultats et cela de manière simple et efficace. Kerrighed est un système d exploitation à image unique développé par l équipe PARIS de l IRISA. Il offre des fonctionnalités permettant de gérer des grappes de calcultateurs. Nous voulons étudier le comportement de Kerrighed ainsi que les améliorations que l on pourrait lui apporter sur une classe d application dans le domaine de la bio-informatique. Nous avons décomposé notre travail en plusieurs étapes. Dans une première partie (stage d été 2005 et début du tutorat jusqu au mois d octobre), nous nous sommes concentrés sur le problème de la simplicité d utilisation de Kerrighed et nous avons obtenu une solution : le Kerrighed-LiveCD [13, 11]. Ce cédérom qui est à l origine de démonstration, est destiné à être repris et adapté pour une utilisation intensive par les laboratoires de biologie. Puis, comme exemple d application bio-informatique, nous avons étudié MrBayes, et son comportement sur le système Kerrighed. MrBayes est une application permettant de construire des arbres phylogéniques pour donner une probabilité de liens d évolution entre deux espèces d animaux. Cette première étape nous a permis d identifier de nouvelles fonctionnalités à mettre en œuvre dans Kerrighed pour une gestion efficace des ressources. La fonctionnalité majeure que nous retenons est la gestion des ressources au sein de la grappe par exécution différée des processus. C est ce que nous avons conçu et mis en œuvre à partir du mois d avril. Dans une première partie, nous présentons notre cadre de travail. Puis, nous exposons l état de l art relatif aux grappes, aux systèmes à image unique et aux systèmes à exécution par lots. Dans une troisième partie, nous indiquons l architecture mise en place pour la gestion des processus différés. La partie suivante précise la mise en œuvre de cette architecture. Puis, avant de conclure, nous présentons les résultats des tests effectués.

12 2 INTRODUCTION

13 3 Chapitre 1 Présentation 1.1 Le cadre de travail C est à l IRISA (Institut de Recherche en Informatique et Systèmes Aléatoires) à Rennes que ce tutorat est effectué. Les activités de l IRISA vont du développement de composants matériels à la conception de systèmes avancés. Une trentaine d équipes de recherche travaillent au quotidien sur différents thèmes de recherche. Les travaux présentés ici s effectuent dans le cadre d un tutorat ENSSAT réalisé au sein de l équipe de recherche PARIS (Programmation des systèmes parallèles et distribués pour la simulation numérique à grande échelle). Cette équipe s intéresse à la conception et à la mise en œuvre de systèmes d exploitation ainsi que de modèles de programmation pour grappes de PC et d intergiciels pour les grilles de calcul et de données L IRISA : une unité de recherche L IRISA est une unité de recherche qui regroupe 4 partenaires : l INRIA (Institut National de Recherche en Informatique et en Automatique), le CNRS (Centre National de la Recherche Scientifique), l Université de Rennes I, l INSA (Institut National des Sciences Appliquées). L IRISA regroupe environ 540 pesonnes. Près de la moitié sont des chercheurs ou enseignants chercheurs. Il y a également plus de 180 doctorants et 90 ingénieurs. Les principaux axes des activités de recherche sont : les réseaux et systèmes informatiques, la modélisation du vivant (imagerie médicale, bio-informatique), la réalité virtuelle, la robotique, les langages de programmation et la conception logicielle, le traitement de données Signal-Texte-Son-Images et des connaissances,

14 4 CHAPITRE 1. PRÉSENTATION la modélisation, la simulation et l optimisation de systèmes complexes. D un point de vue structurel, les chercheurs de l IRISA travaillent au sein d équipes de recherche dont la taille varie de 10 à 40 personnes focalisées sur un thème de recherche spécifique. Chaque équipe comporte un responsable scientifique. De plus, l IRISA, dirigé par Claude Labit [16] entouré de son équipe de direction, comporte plusieurs services administratifs. En voici les principaux : le service des ressources humaines, le service financier, le service juridique, le service des moyens informatiques (sans lequel il ne serait pas possible de travailler au quotidien!) L équipe PARIS Les entreprises ont de plus en plus besoin de puissance de calcul pour effectuer des simulations. L activité de recherche de l équipe PARIS [29] concerne les grilles, les grappes et les fondements des systèmes pair-à-pair. Le projet conçoit de nouveaux mécanismes dont le but est de masquer la complexité de programmation des infrastructures parallèles et distribuées. La contribution dans ce champ d investigation peut être synthétisée ainsi : combiner des systèmes parallèles et distribués tout en préservant la transparence vis-à-vis de l utilisateur et des performances maximales L activité de recherche Kerrighed Un des axes de recherche de l équipe PARIS est la conception d un système d exploitation pour le calcul à haute performance sur grappe. C est l activité de recherche Kerrighed [25]. Kerrighed est un système à image unique (dont une description plus détaillée est donnée dans la section 2.3.4) pour grappe dont le but est d offrir une haute performance ainsi qu une haute disponibilité à l exécution d applications scientifiques (séquentielles et parallèles communiquant par message et par partage de mémoire). L objectif de cette activité de recherche est d apporter une solution permettant de gérer au mieux les ressources (CPU, mémoires, disque durs...) disponibles dans la grappe pour exécuter des applications de simulation et de faciliter l utilisation et la programmation des grappes. 1.2 Contexte de travail Introduction Dans le but d exécuter des applications de plus en plus complexes et coûteuses en ressources informatiques, il devient indispensable de disposer de systèmes permettant de les gérer de manière efficace afin de réduire au maximum leur temps d exécution. Au

15 1.2. CONTEXTE DE TRAVAIL 5 sein des laboratoires de biologie, il n est pas rare de vouloir exécuter des applications dont le temps de calcul dépasse la centaine d heures. Dans le cadre de nos travaux, nous avons pris contact avec les chercheurs du laboratoire de biologie du Molecular Ecology Group à l université de Bangor au Pays de Galles. Cette équipe travaille, entre autres, sur l étude des liens évolutifs existant entre différentes populations de lézards. Un des logiciels que cette équipe est amenée à utiliser de manière régulière est l application MrBayes que nous détaillons en section L informatique au service de la biologie Le terme de bio-informatique regroupe toutes les applications informatiques appliquées à la biologie [31]. Il existe différents types d application. Cela va de l analyse du génôme à la modélisation de l évolution d une population animale dans un environnement donné en passant par la reconstruction d arbres phylogénétiques. Ces applications sont très coûteuses en temps de calcul. L équipe de biologistes avec laquelle nous travaillons s intéresse à la reconstruction d arbres phylogénétiques. Ces biologistes ne disposent pas de machines dédiées au calcul. Cependant, ils veulent obtenir les résultats de leurs simulations rapidement. Enfin, ce ne sont pas des spécialistes en informatique Les besoins Concrètement, quelque soit la puissance de calcul disponible, selon les données à traiter, il y aura toujours possibilité de saturer un système informatique donné. Après étude de l environnement de travail des biologistes du Molecular Ecology Group, nous avons pu dégager qu ils veulent un système simple d utilisation qui gère efficacement leurs ressources informatiques peu abondantes L application MrBayes MrBayes [12] est une application bio-informatique de phylogénie. Cette application cherche s il existe des liens évolutifs entre différentes séquences génétiques qui lui sont données en entrée. En sortie, il donne un arbre qui décrit ces liens avec une certaine probabilité. Il existe plusieurs méthodes pour faire ces calculs. MrBayes en utilise une particulière qui consiste à calculer la vraisemblance de chaque arbre et à choisir celui présentant la plus forte vraisemblance. En pratique cela n est pas réalisable (temps de calcul beaucoup trop long). De ce fait, l application utilise un algorithme MCMC (Markov Chain Monte Carlo) pour obtenir un échantillon de la distribution de ces arbres. En effet, même si au départ nous disposons d une très grande puissance de calcul pouvant donner un résultat de l application MrBayes en moins d une heure pour un jeu de données, il est tout à fait possible, en rajoutant d autres séquences en entrée, d augmenter de manière considérable le temps de calcul. Or, les utilisateurs biologistes ne possèdent généralement pas d ordinateurs spécifiques dédiés aux calculs (ils utilisent dans la majorité des cas leur ordinateur de bureau) et ils ne sont pas forcément spécialistes des systèmes informatiques.

16 6 CHAPITRE 1. PRÉSENTATION Il nous faut donc trouver une solution permettant d utiliser au mieux plusieurs ordinateurs physiquement indépendants en vue de la réalisation d une même tâche.

17 7 Chapitre 2 L état de l art Une grappe de calculateurs est un ensemble d ordinateurs (que l on appelle également nœud) interconnectés et vus de l utilisateur comme une même unité de traitement. Les systèmes à image unique sont des systèmes d exploitation qui permettent de masquer la complexité des systèmes distribués et donc celle des grappes. En employant un système à image unique sur une grappe, l usager a alors l impression de n utiliser qu un seul ordinateur alors qu il en utilise plusieurs interconnectés par un réseau rapide. De plus, il existe d autres systèmes informatiques permettant de réguler une charge de travail sur un ensemble d ordinateurs disponibles. Ce sont les système à exécution par lots. Ils permettent une gestion efficace des différentes ressources (vu de la grappe, chaque nœud est une ressource car il contient de la mémoire, des processeurs... ) au sein de la grappe. Nous étudions dans les sections suivantes la bibliographie relative à ces différents systèmes. 2.1 Les grappes de calculateurs Une grappe de calculateurs est un ensemble de machines indépendantes interconnectées le plus souvent par un réseau rapide (dans le domaine de la haute performance) et vu comme une seule unité de traitement par l utilisateur [17, 14]. Ces architectures sont généralement beaucoup moins chères que des calculateurs parallèles à puissance équivalente. Cependant, bien qu elles puissent être une bonne alternative aux supercalculateurs, les grappes restent des architectures distribuées dont la programmation est complexe. Une solution consiste à utiliser un système à image unique (Single System Image - SSI) dont le but est de masquer la distribution (et donc la complexité) des ressources aux utilisateurs. Les grappes sont très utilisées pour faire des calculs en parallèle. La charge du système (nombre d opérations que le système est en train exécuter, voir la section 2.2.1) augmente considérablement si sur une même grappe, des centaines d utilisateurs lancent simultanément des centaines de calculs. Plus la charge augmente, et plus le risque que la

18 8 CHAPITRE 2. L ÉTAT DE L ART grappe devienne indisponible augmente. Afin de pouvoir gérer des ressources partagées entre de multiples utilisateurs, des systèmes à exécution par lots ont été mis en place. 2.2 Gestion des travaux sur grappes de calculateurs Introduction aux systèmes à exécution par lots Définitions La charge moyenne d un processeur (load average). La charge d un système [32, 10] représente la quantité de travail qu il est en train de traiter. La charge moyenne d un système représente ainsi la charge du système sur un temps donné. Conventionnellement, cette charge est donnée selon trois valeurs décrivant la charge moyenne du système sur la dernière minute, les cinq dernières minutes, et les quinze dernières minutes 1. Les systèmes à exécution par lots. En informatique une exécution par lots [33, 30] est un enchaînement automatique de commandes sans intervention d un opérateur. Les travaux lancés par ce type de système sont non-interactifs. Voici quels sont leurs intérêts : partage des ressources informatiques hétérogènes entre plusieurs utilisateurs (gestion de la concurrence d accès aux ressources), gestion efficace de la charge moyenne du système selon la disponibilité des différents nœuds (au sein d une même grappe, certains nœuds peuvent exécuter une application alors que d autres nœuds exécutent une autre application). Présentation De plus en plus, les architectures distribuées s imposent dans le monde du calcul à haute performance [1]. Cependant, l utilisation de ces systèmes est complexe. Pour les simplifier, il a été mis au point des mécanismes permettant de gérer l exécution des travaux sur un certain nombre de ressources disponibles, cela dans le but de les gérer au mieux. Du point de vue du système, il est important d utiliser en continu toutes les ressources disponibles. Cela a pour effet d augmenter la charge du système. Du point de vue de l utilisateur, l interactivité du système est primordiale c est à dire que le temps de réponse du système doit être le plus faible possible (il faut donc, que le système ait une faible charge). Pour exécuter un travail sur un système à exécution par lots, l utilisateur doit généralement écrire un fichier de description des ressources [3]. Ce fichier est un simple fichier texte contenant des mots-clés permettant d indiquer le nom du travail, le type de plate-forme désirée, le temps maximum d utilisation. Le travail ainsi que sa description sont envoyés à l ordonnanceur global du système à exécution par lots. Ce dernier possède une connaissance globale de l état de toutes 1. Sur un système Linux standard, la commande top fournit la charge moyenne du système.

19 2.2. GESTION DES TRAVAUX SUR GRAPPES DE CALCULATEURS 9 les ressources du système, et c est lui qui distribue les travaux en liste d attente sur les différents nœuds. La figure 2.1 montre une représentation simplifiée d un système à exécution par lots. Le nœud-maître reçoit toutes les soumissions des utilisateurs. Il a une parfaite connaissance de l état de ses ressources. Il attribue donc au mieux les tâches (du point de vue de l administration) à exécuter sur les ressources disponibles en essayant d avoir une charge plutôt élevée. Fig. 2.1 Représentation simplifiée d un système à exécution par lots Les principaux critères d évaluation Un système à exécution par lots doit répondre à trois grandes fonctionnalités [3] : Est-il simple d utilisation? Quelles sont les manipulations que l utilisateur doit faire afin d exécuter ses applications? Peut-il utiliser une interface de soumission standard au système Unix ou doit-il utiliser un système spécifique au gestionnaire d exécution par lots utilisés? Est-il robuste et tolérant aux fautes? Est-il simple d administration? Que doit configurer l administrateur pour que le système fonctionne? Combien de temps doit-il consacrer au système pour le maintenir à jour? Est-il compatible avec les applications existantes? Les applications existantes fonctionnent-elles sans modification avec le système à exécution par lots? Faut-il les recompiler?

20 10 CHAPITRE 2. L ÉTAT DE L ART Ces critères sont à garder en mémoire, car ils vont nous guider tout au long de notre travail Les fonctionnalités des systèmes à exécution par lots Il existe beaucoup de systèmes réalisant des exécutions par lots [6, 5, 1, 3, 24, 22, 2, 8, 7]. Nous énumérons ici leurs principales fonctionnalités. Tout d abord, un système à exécution par lots est capable de différer l exécution de processus. C est-à-dire que lorsque l utilisateur exécute son application, le système peut décider de ne l exécuter que plus tard si les ressources nécessaires pour l exécution de l application ne sont pas disponibles par exemple. Le nœud coordinateur : les systèmes à exécution par lots sont capables de gérer des ressources hétérogènes. Ils disposent pour la plupart d un nœud coordinateur (ou nœud-maître, vu sur la figure 2.1) qui centralise toutes les requêtes des utilisateurs et qui a une vision globale de l état (actif / inactif) de l ensemble des ressources dont il dispose. Ces ressources sont généralement hérérogènes (ces ressources peuvent être pour certaines sous système Unix, d autres sous SunOS... ). Le nœud coordinateur doit alors être capable de gérer l hétérogénéité des ressources. Ce nœud coordinateur exécute une politique d ordonnancement paramétrée par l administrateur du système ou bien par l utilisateur lui même s il en a les droits. Le problème de l utilisation d un nœud coordinateur est que si celui-ci devient défaillant, alors l ensemble des travaux de la grappe peut être perdu. La migration de processus : selon les systèmes, ce coordinateur peut, si besoin, déplacer des applications d une ressource à une autre. Cette capacité de migration d un processus permet par exemple à un processus d être déplacé d un nœud A à un nœud B si le nœud A devient défaillant 2. Cela évite au processus de se faire arrêter prématurément et de perdre ainsi tout le travail qu il a pu faire depuis sa création. La gestion des points de reprise d applications : le nœud coordinateur peut décider d arrêter les applications en cours d exécution ou de les redémarrer. Les mécanismes de sauvegarde et restauration de points de reprise permettent, par exemple, à l ordonnanceur de stopper l exécution d un processus dans le cas où un processus de priorité supérieure viendrait à réquisitionner cette même ressource. Puis, lors de la terminaison du processus de forte priorité, lorsque la ressource redevient libre, l ordonnanceur peut redémarrer le processus préalablement arrêté. Gestion dynamique des applications : nous appelons gestion dynamique d application le fait de changer la politique d ordonnancement vis-à-vis d une application en cours d exécution de celle-ci. D une manière générale les systèmes à exécution par lots 2. Il existe des mécanismes permettant de détecter une défaillance imminente d un nœud (exemple, augmentation brutale de la température).

21 2.3. LES SYSTÈMES À IMAGE UNIQUE 11 ne sont pas capable de gérer des applications dynamiques. En effet prenons l exemple d une application nécessitant une ressource processeur. Si au cours de son exécution cette application évolue et a besoin d une seconde ressource processeur la plupart des systèmes à exécution par lots ne chercheront pas à replacer correctement l application sur deux ressources processeur, mais vont la laisser sur une seule ressource processeur, qui est celle de départ. La tolérance aux fautes : certains systèmes sont tolérants aux fautes. Cela signifie qu en cours d exécution de l application, si un nœud vient à défaillir, alors le système peut redémarrer l application qui était exécutée sur ce nœud. Nous comparons maintenant trois systèmes à exécutions par lots qui sont LoadLeveler, Condor et Torque (le tableau 2.3 synthétise la comparaison de ces trois systèmes) : LoadLeveler [8] est un système commercialisé par IBM Corp. depuis plus de 15 ans. Sa stabilité n est plus à démontrer. L utilisateur soumet ses travaux par l intermédiaire de scripts en ligne de commande ou par interface graphique. Les travaux restent en liste d attente tant que les ressources ne sont pas disponibles. Ce système permet la migration de processus à condition que ceux-ci aient été liés avec les librairies de LoadLeveler. Enfin, la tolérance aux fautes de ce système est limitée car si une défaillance intervient sur une application, alors le système tente de relancer l application depuis le début de son exécution (le système perd tout le travail effectué par le processus depuis sa création). Condor [24] est un système à exécution par lots qui utilise les ressources des stations de travail des utilisateurs lorsqu elles sont inutilisées. Il est nécessaire d exécuter des applications qui sont liées avec les librairies Condor (donc refaire une édition de liens de l application). Ce gestionnaire existe depuis 1994 et est très utilisé dans le milieu académique. Il est robuste et fiable. De nombreuses extensions ont par ailleurs été développées afin de le rendre plus fonctionnel. Condor dispose des même fonctionnalités que LoadLeveler en proposant à l utilisateur une meilleure tolérance aux fautes (en cas de défaillance, il redémarre l application depuis le dernier point de reprise réalisé et non depuis le début de l exécution). Torque [7] anciennement connu sous le nom de Portable Batch System (PBS) est très utilisé dans le milieu industriel. Il dispose de nombreuses fonctionnalités permettant de gérer avec une grande précision l ordonnancement des travaux sur les ressources. 2.3 Les systèmes à image unique Présentation Un système à image unique a pour but de donner l illusion qu un ensemble de ressources distribuées ne forme qu une seule ressource partagée (c est-à-dire qu un ensemble