documentfd

Rapport de fin de stage

Ecoulement de la charge sur le syste`me a` image unique Kerrighed :application au domaine de la biologie.

par

Jerome Gallard

Equipe daccueil : PARISEncadrement : Christine Morin - Pascal Gallard

Septembre 2006

Contact :IRISA / INRIA Rennes

Campus universitaire de BeaulieuAvenue du General Leclerc

35042 RENNES Cedex - FranceTelephone : 02 99 84 71 00

Remerciements

Je souhaite remercier toute lequipe PARIS qui ma suivi et encadre tout au longde mon stage et particulie`rement Christine Morin mon encadrant qui ma toujours etede bon conseil, ma toujours laisse libre court dans la gestion de mon travail et qui abien voulu lire et relire ce rapport un nombre incalculable de fois ! Je tiens egalementa` remercier mon fre`re Pascal Gallard qui ma aussi encadre (aussi bien sur le plan desconcepts que sur celui de la technique), soutenu et eclaire sur differents points tout aulong de cette annee !

Jaimerais egalement remercier tout le personnel de lENSSAT (enseignant, person-nel administratif, direction des etudes, ...) qui ma guide durant ces trois annees sur lechemin du metier dingenieur !

Enfin, jadresse aussi mes remerciements les plus chaleureux a` ma famille (mes pa-rents, mes grand-parents, mon fide`le cousin, ...) et a` mes amis (ma tite Elvire, monbinome, Estelle, Fred, ...) qui ont toujours ete la` pour moi au cours de ces trois annees.

TABLE DES MATIE`RES I

Table des matie`res

Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VMots-Cles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VKeywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V

Introduction 1

1 Presentation 31.1 Le cadre de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 LIRISA : une unite de recherche . . . . . . . . . . . . . . . . . . 31.1.2 Lequipe PARIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.3 Lactivite de recherche (( Kerrighed )) . . . . . . . . . . . . . . . . 4

1.2 Contexte de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.2 Linformatique au service de la biologie . . . . . . . . . . . . . . 51.2.3 Les besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.4 Lapplication MrBayes . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Letat de lart 72.1 Les grappes de calculateurs . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Gestion des travaux sur grappes de calculateurs . . . . . . . . . . . . . . 8

2.2.1 Introduction aux syste`mes a` execution par lots . . . . . . . . . . 82.2.2 Les principaux crite`res devaluation . . . . . . . . . . . . . . . . 92.2.3 Les fonctionnalites des syste`mes a` execution par lots . . . . . . . 10

2.3 Les syste`mes a` image unique . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Les fonctionnalites quoffrent les syste`mes a` image unique . . . . 122.3.3 Differents syste`mes a` image unique . . . . . . . . . . . . . . . . . 132.3.4 Kerrighed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Synthe`se . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Execution differee de processus dans Kerrighed 173.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 La gestion des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

II TABLE DES MATIE`RES

3.2.1 La gestion des processus dans un syste`me Linux standard . . . . 193.2.2 La gestion des processus avec Kerrighed . . . . . . . . . . . . . . 20

3.3 Les principes de conception . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.1 Vue densemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.2 Gestion des processus differes . . . . . . . . . . . . . . . . . . . . 22

4 Mise en uvre dans Kerrighed 254.1 Mise en liste dattente dun processus differe . . . . . . . . . . . . . . . . 25

4.1.1 Introduction a` la fonction fork() . . . . . . . . . . . . . . . . . . 254.1.2 A` quel moment devons nous bloquer la creation du processus? . 254.1.3 La capacite FORK DELAY . . . . . . . . . . . . . . . . . . . . . 264.1.4 Instrumentation du do fork() . . . . . . . . . . . . . . . . . . . . 274.1.5 Instrumentation de la structure task struct . . . . . . . . . . . . 274.1.6 Gestion de la liste des processus differes . . . . . . . . . . . . . . 27

4.2 Gestion du reveil des processus . . . . . . . . . . . . . . . . . . . . . . . 284.2.1 Presentation des differentes strategies possibles . . . . . . . . . . 284.2.2 Definition de linterface (API ) . . . . . . . . . . . . . . . . . . . 304.2.3 Reveil a` linitiative dun nud dans un anneau a` jeton . . . . . . 314.2.4 Reveil a` linitiative de chaque nud . . . . . . . . . . . . . . . . 334.2.5 Comparaison qualitative des deux strategies implementees . . . . 36

4.3 Ordonnancement des processus geres en mode differe . . . . . . . . . . . 364.3.1 Preambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3.2 Ordonnanceur de Kerrighed : la fonctionmigration manager thread() 364.3.3 Quand arreter un processus differe . . . . . . . . . . . . . . . . . 374.3.4 Detection dun processus a` arreter . . . . . . . . . . . . . . . . . 374.3.5 Arret dun processus differe . . . . . . . . . . . . . . . . . . . . . 374.3.6 Synthe`se . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4 La charge virtuelle : vload . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4.1 Le principe de la charge virtuelle (vload) . . . . . . . . . . . . . . 394.4.2 Instrumentation du do exit() . . . . . . . . . . . . . . . . . . . . 40

5 Evaluation 415.1 Description du plan de tests . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.1 Le materiel utilise . . . . . . . . . . . . . . . . . . . . . . . . . . 415.1.2 Notre application de simulation . . . . . . . . . . . . . . . . . . . 41

5.2 Etude comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.1 Etude theorique . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.2 Les resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 Etude des performances sans la capacite de migration . . . . . . . . . . 435.3.1 Processus longs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3.2 Processus courts . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4 Etude des performances avec la capacite de migration . . . . . . . . . . 465.5 Synthe`se . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

TABLE DES MATIE`RES III

5.6 Ordonnancement des applications . . . . . . . . . . . . . . . . . . . . . . 48

Conclusion 51

Bibliographie IX

Glossaire XI

A Annexe XIIIA.1 Le champs fd status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII

A.1.1 int check and block(struct task struct *tsk) . . . . . . . . . . . . XIIIA.1.2 int check and unblock(struct task struct *tsk) . . . . . . . . . . . XIIIA.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 differes . . . . . . . . . . . . . . . XIVA.3 Reveil a` linitiative dun nud sur un anneau a` jeton . . . . . . . . . . . XIV

A.3.1 La fonction handle admin(); . . . . . . . . . . . . . . . . . . . . . XIVA.3.2 La fonction handle jeton(); . . . . . . . . . . . . . . . . . . . . . XV

A.4 Pseudo-algorithme de notre application de simulation . . . . . . . . . . XVI

IV TABLE DES MATIE`RES

Resume

Le travail presente dans le rapport a ete effectue dans le cadre dun stage de findetude a` lIRISA de Rennes. LIRISA est une unite de recherche dont lune des activitesest le calcul a` haute performance qui peut etre obtenue par lutilisation de grappesde calculateurs. Cependant lutilisation de ressources distribuees au sein dune grappenest pas simple. Kerrighed est un syste`me dexploitation a` image unique permettantde virtualiser un ensemble de ressources distribuees. Ainsi, lutilisateur a limpressionque sa grappe de calculateurs est comme une seule machine multiprocesseur avec unememoire partagee entre lensemble des ordinateurs.

Nous voulons etudier le comportement de Kerrighed avec des applications de typebio-informatique demandant beaucoup dheures de calcul et pouvant saturer tout syste`meinformatique. Les syste`mes a` execution par lots permettent de gerer cette classe dap-plication. Nous etudions de quelle manie`re il serait possible dintegrer a` Kerrighed lesfonctionnalites des syste`mes a` execution par lots afin quil puisse gerer (( au mieux ))lexecution de ce genre dapplication.

Mots-Cles : Kerrighed, Linux, syste`me dexploitation, grappe, syste`me distribue, sys-te`me a` execution 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 ofits research activities is about high performance computing. Nowadays, industries needhigh performance computing to perform simulations. High performance computing canbe reached with clusters. Clusters are not easy to use as their resources are distributedin different nodes. Kerrighed is a Single System Image Operating System and it easescluster use by providing the illusion of a single virtual multiprocessor to users. Thisvirtual computer provides the resources (CPU, memory, hard disk...) of the whole clusterthat appears as a single machine.

We want to study the behavior of Kerrighed with bioinformatics applications. Forthat, we took contacts with a laboratory of biology in Wales. They proposed to us thestudy of a class of application requiring hours of computation and being able to saturateany information processing system. There are systems making it possible to manage thisclass of application. They are called systems of batch scheduling. We study how it wouldbe possible to integrate into Kerrighed the functionalities of a batch scheduling systemso that it can manage (( as well as possible )) the execution of this kind of application.

Keywords : Kerrighed, Linux, operating system, cluster, distributed system, batchscheduling, process scheduling, Fork Delay, bioinformatics, LiveCD, Knoppix.

V

VI RESUME

Introduction

De nos jours, la puissance de calcul est de plus en plus desiree. Cela est du au faitque de plus en plus de taches sont informatisees et traitees de manie`re automatique.Cependant, cette puissance de calcul est une ressource limitee (meme dans des centresde calcul dedies). Elle doit donc etre geree au mieux afin den tirer un profit maximum.

Prenons par exemple le cas dune equipe de biologistes. Ils disposent dapplicationsinformatiques dont le temps de calcul peut depasser aisement la centaine dheures.Dans la plupart des cas, les laboratoires de biologie ne posse`dent pas dordinateurs decalcul dedies et les biologistes ne sont pas des specialistes en informatique. Ils veulentcependant gerer au mieux les ressources (les ordinateurs) dont ils disposent afin dobtenirdans les meilleurs delais leurs resultats et cela de manie`re simple et efficace. Kerrighed estun syste`me dexploitation a` image unique developpe par lequipe PARIS de lIRISA. Iloffre des fonctionnalites permettant de gerer des grappes de calcultateurs. Nous voulonsetudier le comportement de Kerrighed ainsi que les ameliorations que lon pourrait luiapporter sur une classe dapplication dans le domaine de la bio-informatique.

Nous avons decompose notre travail en plusieurs etapes. Dans une premie`re partie(stage dete 2005 et debut du tutorat jusquau mois doctobre), nous nous sommesconcentres sur le proble`me de la simplicite dutilisation de Kerrighed et nous avonsobtenu une solution : le Kerrighed-LiveCD [13, 11]. Ce cederom qui est a` lorigine dedemonstration, est destine a` etre repris et adapte pour une utilisation intensive parles laboratoires de biologie. Puis, comme exemple dapplication bio-informatique, nousavons etudie MrBayes, et son comportement sur le syste`me Kerrighed. MrBayes estune application permettant de construire des arbres phylogeniques pour donner uneprobabilite de liens devolution entre deux espe`ces danimaux. Cette premie`re etapenous a permis didentifier de nouvelles fonctionnalites a` mettre en uvre dans Kerrighedpour une gestion efficace des ressources. La fonctionnalite majeure que nous retenonsest la gestion des ressources au sein de la grappe par execution differee des processus.Cest ce que nous avons concu et mis en uvre a` partir du mois davril.

Dans une premie`re partie, nous presentons notre cadre de travail. Puis, nous expo-sons letat de lart relatif aux grappes, aux syste`mes a` image unique et aux syste`mesa` execution par lots. Dans une troisie`me partie, nous indiquons larchitecture mise enplace pour la gestion des processus differes. La partie suivante precise la mise en uvrede cette architecture. Puis, avant de conclure, nous presentons les resultats des testseffectues.

2 INTRODUCTION

3Chapitre 1

Presentation

1.1 Le cadre de travail

Cest a` lIRISA (Institut de Recherche en Informatique et Syste`mes Aleatoires) a`Rennes que ce tutorat est effectue. Les activites de lIRISA vont du developpementde composants materiels a` la conception de syste`mes avances. Une trentaine dequipesde recherche travaillent au quotidien sur differents the`mes de recherche. Les travauxpresentes ici seffectuent dans le cadre dun tutorat ENSSAT realise au sein de lequipede recherche PARIS (Programmation des syste`mes paralle`les et distribues pour la si-mulation numerique a` grande echelle). Cette equipe sinteresse a` la conception et a` lamise en uvre de syste`mes dexploitation ainsi que de mode`les de programmation pourgrappes de PC et dintergiciels pour les grilles de calcul et de donnees.

1.1.1 LIRISA : une unite de recherche

LIRISA est une unite de recherche qui regroupe 4 partenaires : lINRIA (Institut National de Recherche en Informatique et en Automatique), le CNRS (Centre National de la Recherche Scientifique), lUniversite de Rennes I, lINSA (Institut National des Sciences Appliquees).

LIRISA regroupe environ 540 pesonnes. Pre`s de la moitie sont des chercheurs ou en-seignants chercheurs. Il y a egalement plus de 180 doctorants et 90 ingenieurs. Lesprincipaux axes des activites de recherche sont :

les reseaux et syste`mes informatiques, la modelisation du vivant (imagerie medicale, bio-informatique), la realite virtuelle, la robotique, les langages de programmation et la conception logicielle, le traitement de donnees Signal-Texte-Son-Images et des connaissances,

4 CHAPITRE 1. PRESENTATION

la modelisation, la simulation et loptimisation de syste`mes complexes.

Dun point de vue structurel, les chercheurs de lIRISA travaillent au sein dequipes derecherche dont la taille varie de 10 a` 40 personnes focalisees sur un the`me de recherchespecifique. Chaque equipe comporte un responsable scientifique. De plus, lIRISA, dirigepar Claude Labit [16] entoure de son equipe de direction, comporte plusieurs servicesadministratifs. 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 tra-vailler au quotidien !).

1.1.2 Lequipe PARIS

Les entreprises ont de plus en plus besoin de puissance de calcul pour effectuerdes simulations. Lactivite de recherche de lequipe PARIS [29] concerne les grilles,les grappes et les fondements des syste`mes pair-a`-pair. Le projet concoit de nouveauxmecanismes dont le but est de masquer la complexite de programmation des infrastruc-tures paralle`les et distribuees. La contribution dans ce champ dinvestigation peut etresynthetisee ainsi : combiner des syste`mes paralle`les et distribues tout en preservant latransparence vis-a`-vis de lutilisateur et des performances maximales.

1.1.3 Lactivite de recherche (( Kerrighed ))

Un des axes de recherche de lequipe PARIS est la conception dun syste`me dex-ploitation pour le calcul a` haute performance sur grappe. Cest lactivite de rechercheKerrighed [25]. Kerrighed est un syste`me a` image unique (dont une description plusdetaillee est donnee dans la section 2.3.4) pour grappe dont le but est doffrir une hauteperformance ainsi quune haute disponibilite a` lexecution dapplications scientifiques(sequentielles et paralle`les communiquant par message et par partage de memoire).

Lobjectif de cette activite de recherche est dapporter une solution permettant degerer au mieux les ressources (CPU, memoires, disque durs...) disponibles dans la grappepour executer des applications de simulation et de faciliter lutilisation et la program-mation des grappes.

1.2 Contexte de travail

1.2.1 Introduction

Dans le but dexecuter des applications de plus en plus complexes et couteuses enressources informatiques, il devient indispensable de disposer de syste`mes permettantde les gerer de manie`re efficace afin de reduire au maximum leur temps dexecution. Au

1.2. CONTEXTE DE TRAVAIL 5

sein des laboratoires de biologie, il nest pas rare de vouloir executer des applicationsdont le temps de calcul depasse la centaine dheures.

Dans le cadre de nos travaux, nous avons pris contact avec les chercheurs du la-boratoire de biologie du Molecular Ecology Group a` luniversite de Bangor au Pays deGalles. Cette equipe travaille, entre autres, sur letude des liens evolutifs existant entredifferentes populations de lezards. Un des logiciels que cette equipe est amenee a` utiliserde manie`re regulie`re est lapplication MrBayes que nous detaillons en section 1.2.4.

1.2.2 Linformatique au service de la biologie

Le terme de bio-informatique regroupe toutes les applications informatiques ap-pliquees a` la biologie [31]. Il existe differents types dapplication. Cela va de lanalysedu genome a` la modelisation de levolution dune population animale dans un environ-nement donne en passant par la reconstruction darbres phylogenetiques. Ces applica-tions sont tre`s couteuses en temps de calcul. Lequipe de biologistes avec laquelle noustravaillons sinteresse a` la reconstruction darbres phylogenetiques. Ces biologistes nedisposent pas de machines dediees au calcul. Cependant, ils veulent obtenir les resultatsde leurs simulations rapidement. Enfin, ce ne sont pas des specialistes en informatique.

1.2.3 Les besoins

Concre`tement, quelque soit la puissance de calcul disponible, selon les donnees a`traiter, il y aura toujours possibilite de saturer un syste`me informatique donne.

Apre`s etude de lenvironnement de travail des biologistes du Molecular EcologyGroup, nous avons pu degager quils veulent un syste`me simple dutilisation qui ge`reefficacement leurs ressources informatiques peu abondantes.

1.2.4 Lapplication MrBayes

MrBayes [12] est une application bio-informatique de phylogenie. Cette applicationcherche sil existe des liens evolutifs entre differentes sequences genetiques qui lui sontdonnees en entree. En sortie, il donne un arbre qui decrit ces liens avec une certaineprobabilite. Il existe plusieurs methodes pour faire ces calculs. MrBayes en utilise uneparticulie`re qui consiste a` calculer la vraisemblance de chaque arbre et a` choisir celuipresentant la plus forte vraisemblance. En pratique cela nest pas realisable (tempsde calcul beaucoup trop long). De ce fait, lapplication utilise un algorithme MCMC(Markov Chain Monte Carlo) pour obtenir un echantillon de la distribution de cesarbres.

En effet, meme si au depart nous disposons dune tre`s grande puissance de calculpouvant donner un resultat de lapplication MrBayes en moins dune heure pour unjeu de donnees, il est tout a` fait possible, en rajoutant dautres sequences en entree,daugmenter de manie`re considerable le temps de calcul.

Or, les utilisateurs biologistes ne posse`dent generalement pas dordinateurs specifiquesdedies aux calculs (ils utilisent dans la majorite des cas leur ordinateur de bureau) etils ne sont pas forcement specialistes des syste`mes informatiques.

6 CHAPITRE 1. PRESENTATION

Il nous faut donc trouver une solution permettant dutiliser au mieux plusieursordinateurs physiquement independants en vue de la realisation dune meme tache.

7Chapitre 2

Letat de lart

Une grappe de calculateurs est un ensemble dordinateurs (que lon appelle egalementnud) interconnectes et vus de lutilisateur comme une meme unite de traitement. Lessyste`mes a` image unique sont des syste`mes dexploitation qui permettent de masquer lacomplexite des syste`mes distribues et donc celle des grappes. En employant un syste`mea` image unique sur une grappe, lusager a alors limpression de nutiliser quun seulordinateur alors quil en utilise plusieurs interconnectes par un reseau rapide.

De plus, il existe dautres syste`mes informatiques permettant de reguler une chargede travail sur un ensemble dordinateurs disponibles. Ce sont les syste`me a` executionpar lots. Ils permettent une gestion efficace des differentes ressources (vu de la grappe,chaque nud est une ressource car il contient de la memoire, des processeurs. . . ) ausein de la grappe.

Nous etudions dans les sections suivantes la bibliographie relative a` ces differentssyste`mes.

2.1 Les grappes de calculateurs

Une grappe de calculateurs est un ensemble de machines independantes intercon-nectees le plus souvent par un reseau rapide (dans le domaine de la haute performance)et vu comme une seule unite de traitement par lutilisateur [17, 14]. Ces architecturessont generalement beaucoup moins che`res que des calculateurs paralle`les a` puissanceequivalente.

Cependant, bien quelles puissent etre une bonne alternative aux supercalculateurs,les grappes restent des architectures distribuees dont la programmation est complexe.Une solution consiste a` utiliser un syste`me a` image unique (Single System Image - SSI)dont le but est de masquer la distribution (et donc la complexite) des ressources auxutilisateurs.

Les grappes sont tre`s utilisees pour faire des calculs en paralle`le. La charge dusyste`me (nombre doperations que le syste`me est en train executer, voir la section 2.2.1)augmente considerablement si sur une meme grappe, des centaines dutilisateurs lancentsimultanement des centaines de calculs. Plus la charge augmente, et plus le risque que la

8 CHAPITRE 2. LETAT DE LART

grappe devienne indisponible augmente. Afin de pouvoir gerer des ressources partageesentre de multiples utilisateurs, des syste`mes a` execution par lots ont ete mis en place.

2.2 Gestion des travaux sur grappes de calculateurs

2.2.1 Introduction aux syste`mes a` execution par lots

Definitions

La charge moyenne dun processeur (load average). La charge dun syste`me [32,10] represente la quantite de travail quil est en train de traiter. La charge moyenne dunsyste`me represente ainsi la charge du syste`me sur un temps donne. Conventionnellement,cette charge est donnee selon trois valeurs decrivant la charge moyenne du syste`me surla dernie`re minute, les cinq dernie`res minutes, et les quinze dernie`res minutes 1.

Les syste`mes a` execution par lots. En informatique une execution par lots [33, 30]est un enchanement automatique de commandes sans intervention dun operateur. Lestravaux lances par ce type de syste`me sont non-interactifs. Voici quels sont leurs interets :

partage des ressources informatiques heteroge`nes entre plusieurs utilisateurs (ges-tion de la concurrence dacce`s aux ressources),

gestion efficace de la charge moyenne du syste`me selon la disponibilite des differentsnuds (au sein dune meme grappe, certains nuds peuvent executer une appli-cation alors que dautres nuds executent une autre application).

Presentation

De plus en plus, les architectures distribuees simposent dans le monde du calcula` haute performance [1]. Cependant, lutilisation de ces syste`mes est complexe. Pourles simplifier, il a ete mis au point des mecanismes permettant de gerer lexecution destravaux sur un certain nombre de ressources disponibles, cela dans le but de les gererau mieux.

Du point de vue du syste`me, il est important dutiliser en continu toutes les res-sources disponibles. Cela a pour effet daugmenter la charge du syste`me. Du point devue de lutilisateur, linteractivite du syste`me est primordiale cest a` dire que le tempsde reponse du syste`me doit etre le plus faible possible (il faut donc, que le syste`me aitune faible charge).

Pour executer un travail sur un syste`me a` execution par lots, lutilisateur doitgeneralement ecrire un fichier de description des ressources [3]. Ce fichier est un simplefichier texte contenant des mots-cles permettant dindiquer le nom du travail, le typede plate-forme desiree, le temps maximum dutilisation.

Le travail ainsi que sa description sont envoyes a` lordonnanceur global du syste`mea` execution par lots. Ce dernier posse`de une connaissance globale de letat de toutes

1. Sur un syste`me Linux standard, la commande top fournit la charge moyenne du syste`me.

2.2. GESTION DES TRAVAUX SUR GRAPPES DE CALCULATEURS 9

les ressources du syste`me, et cest lui qui distribue les travaux en liste dattente sur lesdifferents nuds.

La figure 2.1 montre une representation simplifiee dun syste`me a` execution parlots. Le nud-matre recoit toutes les soumissions des utilisateurs. Il a une parfaiteconnaissance de letat de ses ressources. Il attribue donc au mieux les taches (du pointde vue de ladministration) a` executer sur les ressources disponibles en essayant davoirune charge plutot elevee.

Fig. 2.1 Representation simplifiee dun syste`me a` execution par lots

2.2.2 Les principaux crite`res devaluation

Un syste`me a` execution par lots doit repondre a` trois grandes fonctionnalites [3] :

Est-il simple dutilisation ? Quelles sont les manipulations que lutilisateur doitfaire afin dexecuter ses applications? Peut-il utiliser une interface de soumission stan-dard au syste`me Unix ou doit-il utiliser un syste`me specifique au gestionnaire dexecutionpar lots utilises? Est-il robuste et tolerant aux fautes?

Est-il simple dadministration? Que doit configurer ladministrateur pour que lesyste`me fonctionne? Combien de temps doit-il consacrer au syste`me pour le maintenira` jour?

Est-il compatible avec les applications existantes? Les applications existantesfonctionnent-elles sans modification avec le syste`me a` execution par lots ? Faut-il lesrecompiler?


Ces crite`res sont a` garder en memoire, car ils vont nous guider tout au long de notretravail.

2.2.3 Les fonctionnalites des syste`mes a` execution par lots

Il existe beaucoup de syste`mes realisant des executions par lots [6, 5, 1, 3, 24, 22,2, 8, 7]. Nous enumerons ici leurs principales fonctionnalites. Tout dabord, un syste`mea` execution par lots est capable de differer lexecution de processus. Cest-a`-dire quelorsque lutilisateur execute son application, le syste`me peut decider de ne lexecuterque plus tard si les ressources necessaires pour lexecution de lapplication ne sont pasdisponibles par exemple.

Le nud coordinateur : les syste`mes a` execution par lots sont capables de gererdes ressources heteroge`nes. Ils disposent pour la plupart dun nud coordinateur (ounud-matre, vu sur la figure 2.1) qui centralise toutes les requetes des utilisateurs etqui a une vision globale de letat (actif / inactif) de lensemble des ressources dontil dispose. Ces ressources sont generalement hereroge`nes (ces ressources peuvent etrepour certaines sous syste`me Unix, dautres sous SunOS. . . ). Le nud coordinateur doitalors etre capable de gerer lheterogeneite des ressources. Ce nud coordinateur executeune politique dordonnancement parametree par ladministrateur du syste`me ou bienpar lutilisateur lui meme sil en a les droits. Le proble`me de lutilisation dun nudcoordinateur est que si celui-ci devient defaillant, alors lensemble des travaux de lagrappe peut etre perdu.

La migration de processus : selon les syste`mes, ce coordinateur peut, si besoin,deplacer des applications dune ressource a` une autre. Cette capacite de migration dunprocessus permet par exemple a` un processus detre deplace dun nudA a` un nudB sile nud A devient defaillant 2 . Cela evite au processus de se faire arreter prematurementet de perdre ainsi tout le travail quil a pu faire depuis sa creation.

La gestion des points de reprise dapplications : le nud coordinateur peutdecider darreter les applications en cours dexecution ou de les redemarrer. Les mecanismesde sauvegarde et restauration de points de reprise permettent, par exemple, a` lordon-nanceur de stopper lexecution dun processus dans le cas ou` un processus de prioritesuperieure viendrait a` requisitionner cette meme ressource. Puis, lors de la terminaisondu processus de forte priorite, lorsque la ressource redevient libre, lordonnanceur peutredemarrer le processus prealablement arrete.

Gestion dynamique des applications : nous appelons gestion dynamique dappli-cation le fait de changer la politique dordonnancement vis-a`-vis dune application encours dexecution de celle-ci. Dune manie`re generale les syste`mes a` execution par lots

2. Il existe des mecanismes permettant de detecter une defaillance imminente dun nud (exemple,augmentation brutale de la temperature).

2.3. LES SYSTE`MES A` IMAGE UNIQUE 11

ne sont pas capable de gerer des applications dynamiques. En effet prenons lexempledune application necessitant une ressource processeur. Si au cours de son executioncette application evolue et a besoin dune seconde ressource processeur la plupart dessyste`mes a` execution par lots ne chercheront pas a` replacer correctement lapplicationsur deux ressources processeur, mais vont la laisser sur une seule ressource processeur,qui est celle de depart.

La tolerance aux fautes : certains syste`mes sont tolerants aux fautes. Cela signifiequen cours dexecution de lapplication, si un nud vient a` defaillir, alors le syste`mepeut redemarrer lapplication qui etait executee sur ce nud.

Nous comparons maintenant trois syste`mes a` executions par lots qui sont LoadLeveler,Condor et Torque (le tableau 2.3 synthetise la comparaison de ces trois syste`mes) :

LoadLeveler [8] est un syste`me commercialise par IBM Corp. depuis plus de 15ans. Sa stabilite nest plus a` demontrer. Lutilisateur soumet ses travaux par lin-termediaire de scripts en ligne de commande ou par interface graphique. Les tra-vaux restent en liste dattente tant que les ressources ne sont pas disponibles. Cesyste`me permet la migration de processus a` condition que ceux-ci aient ete liesavec les librairies de LoadLeveler. Enfin, la tolerance aux fautes de ce syste`me estlimitee car si une defaillance intervient sur une application, alors le syste`me tentede relancer lapplication depuis le debut de son execution (le syste`me perd tout letravail effectue par le processus depuis sa creation).

Condor [24] est un syste`me a` execution par lots qui utilise les ressources desstations de travail des utilisateurs lorsquelles sont inutilisees. Il est necessairedexecuter des applications qui sont liees avec les librairies Condor (donc refaireune edition de liens de lapplication). Ce gestionnaire existe depuis 1994 et est tre`sutilise dans le milieu academique. Il est robuste et fiable. De nombreuses exten-sions ont par ailleurs ete developpees afin de le rendre plus fonctionnel. Condordispose des meme fonctionnalites que LoadLeveler en proposant a` lutilisateur unemeilleure tolerance aux fautes (en cas de defaillance, il redemarre lapplication de-puis le dernier point de reprise realise et non depuis le debut de lexecution).

Torque [7] anciennement connu sous le nom de Portable Batch System (PBS)est tre`s utilise dans le milieu industriel. Il dispose de nombreuses fonctionnalitespermettant de gerer avec une grande precision lordonnancement des travaux surles ressources.

2.3 Les syste`mes a` image unique

2.3.1 Presentation

Un syste`me a` image unique a pour but de donner lillusion quun ensemble de res-sources distribuees ne forme quune seule ressource partagee (cest-a`-dire quun ensemble


dordinateurs independants forme un ordinateur virtuel multiprocesseur). Un syste`mea` image unique ideal doit fournir quatre proprietes :

La transparence a` la distribution : il nest pas necessaire de nommer un nud pouracceder a` ses ressources,

La transparence a` lutilisation : une application doit fonctionner avec la memesimplicite sur un syste`me a` image unique que sur un syste`me standard,

La surete de fonctionnement : si lon conside`re une grappe comme une machinevirtuelle unique composee de plusieurs machines reelles, la defaillance de lunedentre-elles ne doit pas entraner la defaillance de toute la grappe,

Lextensibilite : lajout de ressources a` la grappe doit etre pris en compte automa-tiquement par le syste`me.

2.3.2 Les fonctionnalites quoffrent les syste`mes a` image unique

Afin de gerer de manie`re transparente lexecution dapplications au sein de la grappe,les syste`mes a` image unique disposent comme les syste`mes a` execution par lots demecanismes leur permettant de gerer de differentes manie`res les processus et les res-sources de la grappe. Nous allons reprendre les fonctionnalites decrites pour les syste`mesa` execution par lots en section 2.2.3 afin de montrer les differences avec les syste`mes a`image unique.

Le nud coordinateur : par definition, un syste`me a` image unique ne peut disposerdun nud coordinateur. En effet, cela serait contraire aux principes de transparence, desurete de fonctionnement et dextensibilite enonces en section 2.3.1. De plus, un syste`mea` image unique ge`re des ressources homoge`nes. Il nest pas possible davoir des syste`mesUnix, SunOS. . . geres par un meme syste`me a` image unique.

La migration de processus : Les syste`mes a` image unique peuvent generalementdeplacer des processus (comme les syste`mes a` execution par lots). Par exemple, si nouslancons plusieurs calculs sur une grappe, il est possible que certains nuds finissentleurs calculs avant dautres, alors le syste`me dexploitation va deplacer des processusafin dequilibrer la charge de la grappe.

La gestion des points de reprise dapplications : dans le cas dexecution dap-plications de longue duree, la probabilite quune defaillance materielle se produise estgrande (comme dans les syste`mes a` execution par lots). De plus, il est egalement pos-sible, si lutilisateur ne dispose pas de ressources dediees au calcul quil ne veuille pastout executer dune seule traite, mais plutot, en plusieurs morceaux (exemple, du calculpendant la nuit et du travail bureautique la journee).

Gestion dynamique des applications : les syste`mes a` image unique sont capablesdequilibrer le placement des processus dune application sur la grappe en cours dexecutionde lapplication. Par exemple, si au depart une application cree un processus qui necessite

2.4. SYNTHE`SE 13

comme ressource un processeur et quau cours de son execution elle cree un autre pro-cessus, le syste`me a` image unique essaye dequilibrer la charge induite par ce nouveauprocessus en cours dexecution de lapplication.

La tolerance aux fautes : elle est identique a` celle des syste`mes a` execution par lots.

2.3.3 Differents syste`mes a` image unique

Il existe differents syste`mes a` image unique tel que OpenMOSIX, OpenSSI, Kerri-ghed [26, 27, 25]. Tous ont pour but de rendre les grappes de calculateurs fiables, simplesdutilisation et performantes [18]. Nous presentons dans le tableau 2.3 une comparai-son des fonctionnalites entre les syste`mes OpenMOSIX et Kerrighed. Lanalyse de cettecomparaison montre que ces deux syste`mes offrent des fonctionnalites similaires si cenest que OpenMOSIX est plus tolerant aux fautes et plus stable que Kerrighed. Cepen-dant Kerrighed offre la fonctionnalite de sauvegarde de points de reprise dapplicationque OpenMOSIX ne permet pas.

2.3.4 Kerrighed

Kerrighed est un syste`me a` image unique qui virtualise les ressources disponiblesdans la grappe par extension du noyau Linux. Vu de lutilisateur, lutilisation dunegrappe Kerrighed devient alors tre`s semblable a` celle dun unique PC Linux multi-processeur.

Concre`tement, si lon dispose de 6 ordinateurs equipes chacun separement dun pro-cesseur, de 512Mo de memoire et de 2Go de disque dur, avec le syste`me Kerrighed,lutilisateur aura (( limpression )) de travailler sur une machine multi-processeur (SMP)disposant de 6 processeurs avec 512 6 = 3072Mo de memoire, et 2 6 = 12Go dedisque dur. La figure 2.2 represente cet exemple dans le cadre dune architecture multi-processeur et dune architecture de grappes.

2.4 Synthe`se

Il existe des syste`mes permettant de reguler la charge de travail sur une grappede calculateurs. Ces syste`mes sont appeles syste`mes a` execution par lots. Ils sont non-interactifs. Les utilisateurs soumettent leurs travaux et veulent obtenir un resultat fi-nal sans interaction avec lapplication pendant son execution. Ces syste`mes sont bienadaptes a` un environnement compose de ressources heteroge`nes et permettent de gererefficacement la concurrence dacce`s a` ces ressources.

Il existe egalement des syste`mes permettant de donner lillusion a` lutilisateur detravailler sur une machine multi-processeur alors quune grappe est constituee en realitede plusieurs machines interconnectees par un reseau. Ces syste`mes sont appeles syste`mesa` image unique. Les utilisateurs peuvent utiliser ces syste`mes comme sil sagissait dunemachine virtuelle multiprocesseur. Lutilisateur peut ainsi lancer des travaux interactifset interagir avec lapplication pendant son execution.


Fig. 2.2 Architecture SMP vs grappe

Nous voulons etudier en quoi, il serait possible dintegrer un syste`me a` executionpar lots directement dans un syste`me a` image unique. Le tableau 2.3 synthetise les fonc-tionnalites definies precedemment en section 2.2.3 pour differents syste`mes a` executionpar lots et en section 2.3.2 pour differents syste`mes a` image unique.

En bilan de ce tableau nous pouvons dire que la fonctionnalite principale, afin degerer lacce`s conccurrent a` des ressources distribuees, est lexecution differee des pro-cessus. Un syste`me permettant lexecution differee dune application soumise par unutilisateur peut alors gerer les ressources dont il dispose selon une politique dordonnan-cement definie par ladministrateur. De plus, dautres fonctionnalites peuvent ameliorerlefficacite des syste`mes a` execution par lots, a` savoir : la migration de processus, lasauvegarde de points de reprise et la tolerance aux fautes. Or ces fonctionnalites sontpresentes en partie dans les syste`mes a` image unique cites.

Nous allons maintenant etudier sil serait possible et utile dintroduire une fonction-nalite dexecution differee des processus dans Kerrighed.

2.4. SYNTHE`SE 15

Syste`me Load-Leveler

Condor Torque Open-MOSIX

Kerrighed

Stabilite Stable Stable Stable Stable InstableRemarques, domainedutilisation

Versioncommer-ciale,industrie

Acade-mique

Recher-che,industrie

Endevelop-pement

Endevelop-pement

Heterogeneite dessyste`mes

4 4 4 8 8

Absence dun nud co-ordinateur

8 8 8 4 4

Migration de processus 4 4 8 4 4Gestion des points dereprise dapplications

4 4 8 8 4

Gestion dynamiquedapplications

8 8 8 4 4

Execution differee dap-plications

4 4 4 8 8

Ordonnanceur global 4 4 4 4 4Tolerances aux fautes Limite 4 Limite 4 8

Fig. 2.3 Comparaison entre differents syste`mes de traitement a` execution par lots

17

Chapitre 3

Execution differee de processusdans Kerrighed

MrBayes [12] est une application de construction darbres phylogenetiques. Cesarbres permettent detudier les liens devolution existant entre differentes populationsdanimaux. Lequipe de biologistes, avec laquelle nous sommes en contact, utilise Mr-Bayes pour etablir les liens existant entre differentes populations de lezard.

MrBayes est un programme probabiliste. Cest-a`-dire que pour obtenir un resultat,il est necessaire dexecuter plusieurs fois le meme calcul afin de voir si tous convergent.De plus MrBayes est une application de longue duree. Il est courant davoir des tempsde calcul superieurs a` la centaine dheures !

MrBayes est donc une application de longue duree quil faut executer plusieursfois afin dobtenir des resultats fiables. MrBayes est representatif dune classe dapplica-tion bio-informatique : execution de multiples processus de longue duree simultanement.Nous voulons donc concevoir un syste`me permettant de repartir au mieux lexecution deces applications sur la grappe afin davantager au maximum lensemble des utilisateurs.

3.1 Motivation

En conclusion des tests realises avec MrBayes sur Kerrighed, il sest avere quilpourrait etre interessant dimplementer au sein meme de Kerrighed une fonctionnalitede creation de processus differee. Cela nous permettrait de concilier la soumission in-teractive dapplication (a` travers le syste`me a` image unique a` la manie`re dun syste`meLinux standard) et sa gestion differee comme le fait un syste`me a` execution par lots(cette fois-ci de manie`re non interactive).

Prenons le cas dun laboratoire de biologie compose de six personnes et ne disposantque de trois ordinateurs. Pour leurs travaux, ils ont besoin dexecuter regulie`rement descalculs tre`s longs (superieurs a` la centaine dheures). Dans letat actuel du developpementde Kerrighed, si les six personnes du laboratoire lancent chacune un calcul de 100heures sur la grappe, les six calculs vont sexecuter en concurrence. Chaque nud vaexecuter deux calculs simultanement. Vu de lutilisateur, les resultats des calculs ne

18CHAPITRE 3. EXECUTION DIFFEREE DE PROCESSUS DANS KERRIGHED

seront obtenus quau bout de 200 heures. Dans ce cas dutilisation, les 6 utilisateurssont (( penalises )) par le calcul des autres.

Afin de remedier a` cela, une possibilite serait de retarder lexecution dun processuslors de sa creation (explique en section 4.1.1) : si les ressources sont jugees suffisantespar Kerrighed, alors, le processus est execute, sinon il est mis en file dattente.

Reetudions lexemple precedent : lorsque les six utilisateurs lancent leur calcul, seule-ment trois dentre-eux sont executes immediatement. Les trois autres calculs sont misen file dattente et sont executes lorsque les premiers calculs sont termines. De ce fait,trois utilisateurs obtiennent leurs resultats au bout de 100 heures de calculs, et trois uti-lisateurs ont leurs resultats au bout de 200 heures de calculs (comme pour le cas decritprecedemment). Grace a` cette methode, 50% des utilisateurs benificient dun temps decalcul minimum et les autres nobtiennent pas leurs resultats avec des delais superieursa` ceux quils auraient eus dans le premier cas.

De plus, nous pouvons pousser plus loin notre raisonnement. En effet, dans le cadredune gestion de travaux de type syste`me a` execution par lots, le syste`me doit regulerlensemble des travaux en attente en fonction de ses ressources disponibles. Prenonsle cas ou`, dans lexemple precedent, une ressource venait a` disparatre (defaillancematerielle, ou tout simplement lexecution dun processus dune forte priorite sur la res-source en question). Cela risque dentraner une augmentation de la charge. Le syste`medoit donc etre capable de la reduire au mieux en cherchant a` faire des migrations, etle cas echeant en arretant les processus differes en cours dexecution. Lorsque les res-sources sont de nouveau disponibles (exemple : la fin dexecution du calcul de plus fortepriorite), le syste`me reprend lexecution des processus differes la` ou` il lavait arretee.

Bilan. Une charge excessive sur une grappe peut entraner leffondrement de celle-ci. Il faut donc au maximum, reguler lexecution des taches lourdes et couteuses enressources. Cette administration des taches doit se faire de la manie`re la plus simplepossible.

De plus Kerrighed dispose nativement de fonctionnalites utilisees par les syste`mes a`execution par lots comme la migration, la gestion des points de reprise, lordonnanceurglobal.

Nous avons donc a` concilier soumission interactive et execution differee de travail di-rectement au sein du syste`me dexploitation Kerrighed sans passer par des intermediairesde type syste`me a` execution par lots en rajoutant dans Kerrighed la fonctionnalite degestion de processus differes.

3.2 La gestion des processus

Le concept de processus [4] est fondamental dans tous les syste`mes dexploitationmultitache. Typiquement, un processus designe une instance dun programme en coursdexecution.

Un processus est cree (generalement par appel a` la fonction fork() de lespace uti-lisateur), il dispose dune duree de vie plus ou moins longue, il peut avoir des fils, et

3.2. LA GESTION DES PROCESSUS 19

meurt par la suite.Du point de vue du noyau, un processus est une entite qui cherche a` allouer des

ressources (du temps CPU, de la memoire. . . ).

3.2.1 La gestion des processus dans un syste`me Linux standard

Description dun processus.

Un processus est decrit par une structure contenant toutes les informations rela-tives a` celui-ci (task struct). Cette structure est creee et initialisee a` chaque creationdun nouveau processus (par exemple, la fonction fork() de lespace utilisateur faitsyste`matiquement appel a` la fonction syste`me do fork() de lespace noyau). Lors decette creation, le processus recoit un identifiant unique (Process IDentifiant - PID).

Les differents etats dun processus.

Un processus peut avoir plusieurs etats au cours de son execution. Il peut etre encours dexecution (elu), ou en attente dexecution (eligible) dans la file des eligibles. Ilpeut egalement etre interrompu lorsquil attend une ressource non disponible, ou stoppe,lorsquil recoit par exemple un signal SIGSTOP provenant de lutilisateur (nous donnonsplus dinformations sur le concept de signaux dans les paragraphes suivants). Il peutetre dans letat zombie, cest-a`-dire que lexecution du processus est terminee mais quele pe`re du processus na pas encore ete averti. Il peut etre mort, cest le dernier etatpossible quun processus peut prendre pendant quil est en train detre retire du syste`me(exit). Un autre etat particulier est celui trace, cest lorsque le processus a ete stoppepar un debogueur par exemple.

La file des eligibles.

Lorsque le noyau veut executer un processus, il en prend un dans la file des eligibles[9]. Si le processus se fait interrompre, il est retire de la file des eligibles. Le noyauprend alors un autre processus a` traiter dans la file des eligibles. Lorsque le processusinterrompu se fait reveiller par exemple par un signal lui indiquant que la ressourcequil attendait est maintenant libre, alors, ce processus repart dans la file des eligibleset lorsque le noyau le decidera, il sera de nouveau execute. La figure 3.1 representeschematiquement le deroulement de lexecution dun processus.

Les signaux

Les signaux sont des messages qui sont envoyes 1 a` des groupes de processus. Ces mes-sages sont en realite des nombres identifies par un nom dont le prefixe est SIG. Il existeune trentaine de signaux Linux/i386 dont les plus connus sont : SIGINT (interruption,du par exemple a` la suite dune frappe au clavier : Ctrl-C), SIGKILL (arret immediat duprocessus), SIGTERM (signal de terminaison, demande darret dun processus). Ainsi,

1. La commande kill permet sur un syste`me Linux standard denvoyer un signal a` un processus.


Fig. 3.1 Representation simplifiee du deroulement de lexecution dun processus

un signal agit comme une (( sonnerie )) qui avertit un processus dun eve`nement syn-chrone (dans le cas dun signal attendu par programmation) ou asynchrone (dans le casdun signal venant de lexterieur du programme).

Ordonnancement des processus

Pour donner limpression a` lutilisateur dune execution simultanee de plusieurs pro-cessus sur une meme unite de traitement, il a ete mis en place un mecanisme dordon-nancement permettant au noyau de passer de lexecution dun processus a` un autreen un laps de temps tre`s court. Ainsi, vu de lutilisateur, tous les processus qui sonteligibles progressent simultanement.

3.2.2 La gestion des processus avec Kerrighed

Kerrighed reprend tous les concepts definis precedemment pour tout ce qui concernela gestion des processus, a` quelques exceptions pre`s du fait des specifites liees a` Kerri-ghed.

Identifiant de processus

Dans le cadre dun syste`me a` image unique, il est necessaire a` des fins de transparencequun processus ait un identifiant unique sur toute la grappe. Ainsi, lattribution de cetidentifiant est globale a` la grappe et non locale a` un nud.

Les capacites

Kerrighed offre a` lutilisateur la possibilite de donner des capacites aux processus.Une capacite est un attribut donne a` un processus qui lui permet davoir des fonctionna-lites en plus. Par exemple, nous pouvons donner a` un processus la capacite de migration.Dans ce cas, le processus peut etre deplace dun nud a` un autre. Les capacites peuvent

3.2. LA GESTION DES PROCESSUS 21

sappliquer au processus courant, aux processus fils ou aux deux. On peut alors definirune notion dheritage des capacites.

La migration. Cest une capacite qui une fois donnee a` un processus lui permetdetre deplace dun nud a` un autre. Cette migration peut etre faite sur demandede lordonnanceur de la grappe, ou sur demande de lutilisateur. Prenons un exemplesimple : nous dispons de deux nuds. Sur le nud numero 0 nous lancons 2 processusayant la capacite de migration. Lordonnanceur va alors decider de migrer un des deuxprocessus crees du nud 0 vers le nud 1. Cest ce que lon appelle faire de lequilibragede charge.

La creation de processus a` distance. Cette capacite permet a` un processus decreer ses fils directement a` distance sur dautres nuds. Cela est utile par exemple dansle cas de processus tre`s courts pour lesquels le temps de migration entranerait unesurcharge considerable, compare au temps dexecution du processus lui-meme. Dans cesconditions, il vaut mieux directement creer le processus sur le nud distant.

Les points de reprise dapplications. La capacite de point de reprise permet desauvegarder letat dune application a` un instant t. Ses usages sont multiples :

Un utilisateur realise un long calcul. Cependant, pour une raison quelquonque, ildoit eteindre sa grappe. Il peut donc sauvegarder letat de son application, puislorsque sa grappe sera de nouveau operationnelle, il pourra reprendre lexecutionde son calcul la` ou` il lavait arrete.

Dans le cadre des calculs a` haute performance, si un nud vient a` defaillir, il estpossible de ne pas reprendre depuis le debut tous les calculs executes sur ce nudmais les reprendre seulement depuis la dernie`re sauvegarde de lapplication.

Lordonnanceur global a` la grappe

Son principe est le meme que pour un ordonnanceur Linux standard a` la differenceque cet ordonnanceur a la connaissance de toute les ressources disponibles sur la grappeentie`re, et peut prendre des decisions dordonnancement en consequence. Lordonnan-ceur Linux ge`re les processus au sein dun nud alors que lordonnanceur global deKerrighed ge`re les processus au sein de la grappe.

Les signaux Kerrighed

Kerrighed permet de definir des signaux a` envoyer au processus. Ces signaux sontpersonnalisables. Pour envoyer un signal Kerrighed a` un processus, il faut lui specifierune action (cela se fait en remplissant un champ de la task struct du processus), puisenvoyer le signal par lintermediaire dune fonction que nous etudions en section 4.3.5.


3.3 Les principes de conception

3.3.1 Vue densemble

Nous cherchons a` mettre en uvre au sein de Kerrighed une fonctionnalite per-mettant de gerer selon les ressources disponibles de la grappe la creation de nouveauxprocessus. Le but est de pouvoir lancer des processus en mode interactif tout en don-nant au syste`me la possibilite den differer lexecution si la charge courante est tropimportante. Cela est effectue dans le but dallier la simplicite dutilisation dun syste`mea` image unique a` lexecution differee de processus permettant une meilleure gestion desressources comme le font les syste`mes a` execution par lots. Nous appelons un processusdiffere, un processus qui a la capacite de ne pas etre execute immediatement lors de sacreation et dont lexecution peut etre suspendue et reprise sur ordre de lordonnanceurglobal du syste`me afin de reguler la charge de la grappe.

Les objectifs a` atteindre sont les suivants : lancer lexecution de processus uniquement lorsque les ressources de la grappe lepermettent,

arreter des processus differes en cours dexecution si la charge venait a` selever demanie`re importante,

cest-a`-dire, conserver la gestion des processus standard et y adjoindre un nouveau typede processus dont lexecution nest pas immediate et peut etre suspendue a` tout moment.

Nous venons de definir implicitement deux espaces de processus : les processus stan-dard geres par le noyau Linux, et ceux differes geres par le module Kerrighed. Nousverrons en section 4.1.3 comment nous differencions ces deux espaces de processus.

3.3.2 Gestion des processus differes

Presentation

Voici comment fonctionne la gestion des processus differes : Si un utilisateur specifie au syste`me dutiliser la gestion de processus differe pourune de ses applications, cela signifie que tout appel a` la fonction fork() de sonapplication va entraner la creation dun processus differe qui est alors directementmis dans la liste dattente des processus differes.

Lordonnanceur de la grappe reveille les processus differes en attente selon ladisponibilite des ressources.

Lordonnanceur de la grappe deplace ou stoppe des processus differes en coursdexecution si la charge augmente de manie`re importante.

Description detaillee

Nous pouvons maintenant decrire le fonctionnement de la gestion des processusdifferes en differentes parties independantes :

Un processus differe est directement mis en liste dattente (voir section 4.1).

3.3. LES PRINCIPES DE CONCEPTION 23

Les processus de cette liste dattente sont reveilles par ordre de lordonnanceurselon une politique definie par ladministrateur (voir section 4.2).

Les processus differes en cours dexecution peuvent etre deplaces, ou stoppes demanie`re totalement transparente (voir section 4.3).

La politique dordonnancement de notre syste`me est fondee sur la charge dunnud a` un instant donne. Kerrighed dispose de sondes (reelles) donnant la chargedes nuds. Or la valeur donnee par une sonde (reelle) peut mettre deux a` troissecondes avant detre actualisee. Nous avons du definir une nouvelle sonde (vir-tuelle) permettant de corriger la valeur donnee par la sonde reelle (voir section4.4).

La figure 3.2 resume la gestion des processus differes en presentant lordon-nanceur global a` Kerrighed qui ge`re le placement des processus differes entre lesdifferents nuds de la grappe. On y voit aussi les ordonnanceurs locaux standardde chaque nud gerer de manie`re standard lensemble des processus locaux a`chaque nud.


Fig. 3.2 Architecture generale de la gestion des processus differes au sein dune grappeKerrighed

25

Chapitre 4

Mise en uvre dans Kerrighed

Nous implementons dans Kerrighed un mode de gestion particulier des processusque nous appelons mode differe. Ce mode permet a` un processus de netre execute quelorsque la charge du syste`me le permet.

Dans une premie`re partie nous voyons comment se passe la creation dun processusdiffere. Puis nous etudions les algorithmes permettant le reveil des processus qui ont etemis en liste dattente des processus differes. La section suivante explique la manie`re dontsont ordonnances les processus differes. Enfin, nous terminons cette partie en mettanten uvre une optimisation permettant dobtenir de meilleures performances dans lagestion des processus differes : la charge virtuelle.

4.1 Mise en liste dattente dun processus differe

4.1.1 Introduction a` la fonction fork()

Dans un syste`me Linux, la fonction fork() [4, 21, 20] permet de dupliquer un pro-cessus. A` lappel de la fonction, le processus pe`re est clone. La fonction fork() renvoie0 au processus fils et renvoie lidentifiant du processus (PID) fils au pe`re.

La fonction fork() execute un appel a` la fonction syste`me do fork(). Cette fonctionclone le processus pe`re en differentes etapes importantes :

allocation de lidentifiant de processus pour le processus fils : pid = alloc pidmap(); clonage du processus pe`re : p = copy process(pid); premier reveil du processus fils : wake up new task(p); retour de lidentifiant du fils au pe`re : return pid;

4.1.2 A` quel moment devons nous bloquer la creation du processus?

Dans le cadre dune execution differee des processus, nous devons bloquer la creationdun processus differe a` un moment donne. Lanalyse du fonctionnement du do fork()nous me`ne vers trois possibilites :

bloquer la creation du processus fils avant dexecuter le do fork(),

26 CHAPITRE 4. MISE EN UVRE DANS KERRIGHED

bloquer la creation du processus fils dans le do fork(), stopper le processus fils une fois sa creation terminee apre`s le do fork().

Avant le do fork()

En bloquant la creation du processus fils avant le do fork() : le pe`re se retrouve bloque (il ne peut pas changer detat car sinon, le copy process()ne serait pas valide),

il ny a pas de retour de lidentifiant du fils au pe`re (deduction de la remarqueprecedente).

Pendant le do fork()

En bloquant la creation du processus fils pendant le do fork() nous avons deuxpossibilites :

1. soit la creation du processus fils est bloquee juste avant le copy process(), il enresulte que le processus pe`re se retrouve bloque (meme proble`me que precedement),

2. soit cela est fait au moment du wake up new task(), le do fork() rend la main auprocessus pe`re (qui nest donc pas bloque et peut continuer a` etre execute) : celasemble etre une bonne idee.

Apre`s le do fork()

En bloquant la creation du processus fils apre`s le do fork() : le processus fils est cree et est en cours dexecution, puis il est stoppe. Cetteapproche semble etre fonctionnelle mais est assez couteuse car le processus fils estcomple`tement reveille, puis sauvegarde, et enfin stoppe.

Conclusion

Il semble que la solution consistant a` bloquer le processus fils dans le do fork() a`letape du wake up new task() soit la plus judicieuse.

Cest elle que nous implementons.

4.1.3 La capacite FORK DELAY

Pour differencier les deux espaces de processus decrits en section 3.3.1, a` savoir lesprocessus standard et les processus devant etre geres en mode differe, nous utilisonsles capacites (vues en section 3.2.2). Nous mettons en place une nouvelle capacite dansle syste`me Kerrighed : la capacite FORK DELAY. Un processus ayant cette capacitedesigne un processus dont les fils doivent etre geres en mode differe et font parti delensemble des processus differes. Et un processus nayant pas cette capacite designe unprocessus dont les fils font parti de lensemble des processus standard. Cest lutilisateurqui decide de mettre, ou non, la capacite FORK DELAY a` ses processus 1.

1. Cela se fait par lintermediaire de la commande krg capset.

4.1. MISE EN LISTE DATTENTE DUN PROCESSUS DIFFERE 27

4.1.4 Instrumentation du do fork()

Le do fork() se deroule normalement jusquau moment du wake up new task(). A`ce moment la` nous realisons un test : est-ce que le processus en train de faire le fork()posse`de la capacite FORK DELAY?

Si oui, cela signifie que tous les processus fils de ce processus sont des processusdifferes mis en file dattente. Le wake up new task() ne se fait pas. Il se fera plustard, sur decision du syste`me.

Si non, cela signifie que tous les processus fils doivent etre executes immediatement,sans tenir compte de la charge de la machine (gestion des processus standard deLinux).

4.1.5 Instrumentation de la structure task struct

Comme nous lavons vu en section 3.2.1, toutes les informations concernant un pro-cessus sont reunies dans une structure associee a` chaque processus : la task struct. Nouslavons donc instrumentee afin dajouter un champ specifique appele fd flag permettanta` lordonnanceur de savoir si un processus doit etre gere en mode differe. Ce champpeut prendre les valeurs suivantes :

NOT A PFD : ce processus ne doit pas etre gere comme un processus differe.Les processus dans cet etat sont traites dans le syste`me comme des processusstandard a` Linux sans gestion differee (cest le cas par defaut lors de la creationdun processus).

PFD NOT ALREADY WU : ce processus est un processus qui a ete cree par unprocessus ayant la capacite FORK DELAY et il na jamais ete reveille depuis sacreation (il se trouve dans la liste des processus differes).

PFD ALREADY WU : ce processus est un processus qui a ete cree par un pro-cessus ayant la capacite FORK DELAY et il a deja` ete reveille, mais par ordre delordonnanceur il a ete arrete et remis dans la file des processus differes.

4.1.6 Gestion de la liste des processus differes

Nous expliquons dans les paragraphes suivants comment nous gerons une liste desprocessus differes globale a` la grappe qui est implementee localement sur chaque nud.

Declaration de la liste des processus differes

Chaque nud contient localement sa propre liste des processus differes. Ainsi, lors-quun processus differe est cree, il est insere dans la file locale du nud sur lequel il aete cree. Nous avons implemente cette file dattente des processus differes par une listechanee contenant tous les processus locaux a` un nud en attente de reveil.

Un element de cette liste contient : un pointeur sur la task struct du processus differe p, un entier clone flags contenant les parame`tres necessaires au wake up new task(),


un champ fd status contenant letat du processus. Ce champ a ete cree dans lebut dune future interoperabilite entre la sauvegarde de points de reprise dappli-cation et la gestion des processus differes. Pour plus dinformation, nous invitonsle lecteur a` se reporter a` lannexe A.1.

De plus, nous avons defini une variable globale nb process delayed contenant lenombre de processus en attente dans la file locale dun nud.

Les differents elements de la liste des processus differes

Les processus dans la liste des processus differes peuvent etre : des processus qui nont jamais ete reveilles : ils sont places en fin de liste (premierarrive, permier servi),

des processus ayant deja` ete reveilles, mais ayant ete arretes par ordre de lordon-nanceur : ils sont places en debut de liste (dernier arrive, premier servi).

4.2 Gestion du reveil des processus

Concernant la gestion du reveil des processus differes au sein de la grappe, differentespossibilites sont a` envisager :

Approche centralisee : reveil a` linitiative dun nud fixe. Un nud central re-groupe toutes les informations concernant letat de chaque nud, letat de leurfile dattente et distribue lui meme les taches sur les differents nuds.

Approche semi-centralisee : reveil a` linitiative dun nud sur un anneau a` jeton.Nous definissons un anneau compose de nuds ayant du travail en attente. Surcet anneau, nous creons un jeton. Le nud qui a le jeton recherche sur la grappeun nud disponible afin de lui attribuer du travail et passe le jeton a` un autrenud de la grappe.

Approche distribuee : reveil a` linitiative de chaque nud. Chaque nud scrute sapropre charge et previent les autres nuds lorsquil na rien a` faire pour que cesderniers reveillent des processus differes.

Nous representons ces differentes strategies sur la figure 4.1.

4.2.1 Presentation des differentes strategies possibles

Reveil a` linitiative dun nud fixe

Un nud centralise toutes les demandes de reveil de processus. Il dispose dunevision de chaque file des processus differes de tous les nuds de la grappe. Il scrute lacharge de la grappe. Il decide alors ou` et quand un processus doit se reveiller.

Reveil a` linitiative dun nud sur un anneau a` jeton

Chaque nud posse`de sa propre file. On cree un anneau parmi tous les nuds dispo-sant de travaux dans leur file. Un jeton circule sur cet anneau. Le jeton nest consomme

4.2. GESTION DU REVEIL DES PROCESSUS 29

Fig. 4.1 Representation graphique des differentes approches presentees

par un participant de lanneau, quapre`s avoir execute de sa file un processus differe.Lorsque le jeton est consomme, le participant le passe a` son voisin 2. Pour consommerle jeton, le participant scrute la charge de lensemble des nuds de la grappe. Si elle estjugee suffisament faible par le participant, alors il consomme son jeton. Sinon, il gardele jeton jusqua` ce que la charge dun nud de la grappe devienne suffisamment faiblepour quil puisse le consommer. Le jeton peut donc rester sur un nud aussi longtempsque la grappe est chargee.

Reveil a` linitiative de chaque nud de la grappe

Chaque nud posse`de sa propre file des processus differes et scrute sa charge. Deplus chaque nud posse`de une table des etats permettant de savoir a` tout moment letatdes autres nuds. Cet etat peut-etre : nud actif ou nud inactif. Si un nud juge quilest inactif et que sa file des processus differes est vide, alors il envoie un message a` son

2. Dans un second temps, lorsque Kerrighed surpportera a` chaud lajout et le retrait de nuds, ilfaudra prevoir des mecanismes de gestion du jeton plus elabores permettant de ne pas perdre le jeton.


voisin 3 pour lui faire part de son manque dactivite afin que celui-ci mette a` jour satable des etats. Si son voisin dispose de processus a` reveiller, alors il en reveille un quilconfie au nud signalant son inactivite et ne retransmet pas le message. Sinon, le voisinfait passer le message a` son voisin egalement. Le fonctionnement est le meme dans le casou` un nud juge quil est actif, il passe alors un message a` son voisin pour que celui-cimette a` jour sa table des etats. Puis, le voisin passera ce message a` son voisin et ainside suite pour que toute la grappe puisse se mettre a` jour. Si un nud recoit un messageenvoye par lui-meme (cest-a`-dire que le message a fait le tour de la grappe), alors il ledetruit.

Conclusion

Nous laissons de cote le reveil a` linitiative dun nud fixe. En effet, travaillant ausein dun syste`me distribue, il ne semble pas judicieux de mettre en place une archi-tecture centralisee de gestion de processus. Concernant les deux autres methodes, unedifference notable est que dans la version du reveil des processus differes a` linitiativedun nud appartenant a` un anneau avec jeton, un seul nud (celui qui a le jeton) peutexecuter un processus differe de sa file des processus differes alors que dans la versiondu reveil a` linitiative de chaque nud, il est possible que plusieurs nuds puissentsimultanement executer des processus differes en attente. Dans une premie`re approchenous developpons le reveil a` linitiative dun nud dans un anneau avec jeton, puis lereveil a` linitiative de chaque nud (distribue) (voir annexe A.2 pour le passage de lun a`lautre). Nous les comparons pour montrer quune approche comple`tement distribuee estplus performante quune approche semi-centralisee. De plus, cela nous permet de definirune interface de programmation commune a` ces deux politiques de gestion (API ).

4.2.2 Definition de linterface (API )

Comme nous lavons vu, il peut y avoir plusieurs politiques dordonnancement desprocessus differes. Cependant, les actions a` realiser vis-a`-vis dun processus sont toujoursles memes :

obtenir la charge dun nud, reveiller un processus, envoyer un message a` un autre nud.

Obtenir la charge dun nud : int get load of node(int node id)

Cette fonction retourne la charge du nud node id. Cette charge est en fait la chargevirtuelle additionnee a` la charge reelle (voir le chapitre 4.4 pour plus dinformations surles principes des charges reelle et virtuelle ainsi que sur les principes de fonctionnementde la sonde MOSIX) du nud node id.

3. Definition du voisin dun nud : le nud didentifiant n a pour voisin le nud didentifiant n+ 1modulo le nombre de nuds dans la grappe.


Reveiller un processus : int wake up pfd(int node to fork)

Cette fonction reveille un processus de la liste des processus differes sur le nudnode to fork. Le mecanisme est le suivant :

reveiller un processus, le deplacer sur le nud disponible.

Le reveil des processus differes. La recherche des processus disponibles seffectuedans la liste des processus parmi ceux qui sont non bloques (fd status vu en section4.1.6). Le reveil dun processus peut seffectuer de deux manie`res selon letat consignedans le champ fd flag (vu en section 4.1.5) :

soit le processus na jamais ete reveille (etat == PFD NOT ALREADY WU, dansce cas il convient de faire un wake up new task() pour son premier reveil.

soit le processus a deja` ete execute mais a ete stoppe (etat == PFD ALREADY WU ),dans ce cas il faut envoyer au processus un signal de reprise.

Une fois que le processus est reveille, alors, il faut lenlever de la file des processusdifferes, et mettre a` jour la charge du syste`me (voir la section 4.4).

Envoyer un message : void send a message to the local node(int msg, int type)

Cette fonction a pour effet denvoyer un message msg de type type synchrone aunud local.

Envoyer un message : void send a message to the next node(int msg, int type)

Cette fonction a pour effet denvoyer un message msg de type type synchrone aunud voisin (nud dont lidentifiant est identifiant+ 1 modulo le nombre de nudsdans la grappe).

Ces deux dernie`res fonctions utilisent les mecanismes denvoi de message offerts parKerrighed. Kerrighed offre des mecanismes permettant denvoyer des messages dunnud a` un autre, de manie`re synchrone ou asynchrone. Ces mecanismes se nomment lesservices RPC (Remote Procedure Call) [14, 19, 23] et nous les utilisons pour implementernos politiques de gestion du reveil des processus differes.

Le principe est le suivant : un processus leger du noyau (( ecoute )) en permanencesur un canal predefini. Lorsquil recoit des messages, il les traite.

4.2.3 Reveil a` linitiative dun nud dans un anneau a` jeton

Dans une premie`re approche, nous formulons lhypothe`se que le jeton ne peut seperdre (il ne peut y avoir de retrait de nuds a` chaud) et qua` tout instant lanneaucomporte au plus un jeton.


Les differents types de message

Pour la gestion des processus differes, nous avons cree un canal FD CHAN qui estutilise pour tous les messages echanges entre les differents nuds. De plus, nous avonsdefini deux types de message :

ADMIN : messages dadministration de lanneau. Ce type de message est utiliselorsquun nud veut sintegrer a` lanneau car il a des processus differes en attente,ou bien quun nud faisant parti de lanneau veut le quitter.

JETON : messages de circulation du jeton. Nous symbolisons le jeton par un mes-sage. Lorsquun nud recoit un message de type JETON, il recoit donc le jeton.

Nous disposons donc de deux processus du noyau servant a` traiter ces messages : handle admin : ge`re les messages dadministration de lanneau, handle jeton : ge`re la reception du jeton.Pour plus dinformation sur les details dimplementation, le lecteur peut se reporter

a` lannexe A.3.

Le processus delection

En mettant de cote la possibilite que le jeton puisse etre perdu, il existe un cas ou` ilpeut ne plus avoir de jeton dans lanneau : cest le cas degenere ou` lanneau ne contientaucun nud (typiquement lorsquaucun nud na de processus differes en attente).Lorsquun nud recoit du travail (cest-a`-dire quil a la creation dau moins un processusdiffere) il doit donc creer un jeton pour pouvoir le consommer. Or il se pourrait queplusieurs nuds veuillent creer un jeton en meme temps (exemple : creation simultaneede processus differes sur des nuds distincts). Ainsi, afin de sassurer quil ny a au plusquun jeton sur lanneau, nous procedons a` une election : le nud possedant le plus fortkerrighed node id a le droit de creer le jeton (les autres nuds doivent attendre que lejeton leur parvienne avant de pouvoir executer des processus differes en attente).

Algorithme

La fonction handle jeton() est appelee lorsque le nud recoit le jeton. Celle-ci faitappel a` la fonction fd management() qui contient le corps de notre algorithme decrit ci-apre`s. En effet, la fonction fd management() est appelee lorsque le nud recoit le jetonou lorsquun processus differe est cree et mis en file dattente des processus differes dunud. Cette fonction essaye de consommer le jeton si la file dattente des processusdifferes du nud nest pas vide (cest-a`-dire quil y a du travail en attente) et passe lejeton au nud voisin.

Pseudo-algorithme :SI du_travail_en_attente() == VRAI ALORS//travail en attenteSI jeton_dans_anneau() == FAUX ALORSdemande_creation_jeton();


SINON//est-ce que le noeud possede le jeton ?SI presence_jeton() == VRAI ALORSconsommer_jeton(); //reveiller un processus et transmettre le jeton

SINON//attendre que le jeton arrive !rien_a_faire();

FINSIFINSI

FINSI

4.2.4 Reveil a` linitiative de chaque nud

Dans la strategie du reveil a` linitiative de chaque nud, chacun scrute uniquementsa charge et previent les autres nuds sil subit un changement detat. Nous avons definideux etats : actif et inactif. Un nud inactif va donc prevenir les autres nuds de sonchangement detat sil devient actif et reciproquement pour un nud actif qui devientinactif. Tous les nuds posse`dent une table des etats contenant letat des autres nudsqui est mise a` jour au fur et a` mesure. Le nud didentifiant n a pour voisin le nudsdidentifiant n+ 1 modulo le nombre de nuds dans la grappe.

Le principe est le suivant : un processus du noyau (fd v2 manager thread()) scrute regulie`rement 4 la chargedu syste`me (local). A` chaque changement detat (le nud devient actif ou inactif)ce processus envoie un message a` son voisin lui indiquant son nouvel etat (actifou inactif). Le voisin met a` jour sa table des etats et se charge, selon les cas quenous voyons par la suite, de retransmettre le message a` son propre voisin ou non.

deux autres processus du noyau (handle ready() et handle not ready()) recoiventces messages de changement detat de la part des autres nuds et mettent a` jourleur table.

A` linitialisation nous considerons tous les nuds inactifs. Si un nud a son etatqui change, alors il senvoie un message pour mettre a` jour sa table des etats et relancerlalgorithme afin de voir sil nest pas possible dexecuter un processus differe de la filedattente locale. Sil cela est possible, alors il le fait. Sinon, il envoie un message a` sonvoisin pour quil se mette a` jour. Le voisin met a` jour sa table des etats et regarde silna pas de processus en attente a` reveiller sur le nud a` lorigine du message. Si oui, ille fait, si non, il passe le message egalement a` son voisin et ainsi de suite.

Algorithme : Lorsquun nud change detat, il senvoie un message dinformation(pour se mettre a` jour) et envoie un message a` son voisin (pour que toute la grappe semette a` jour).

Lorsquun nud recoit un message de mise a` jour (celui-ci pouvant provenir de lui-meme ou bien dun autre nud) et que ce message na pas fait une boucle, alors il met

4. Cette periodicite peut-etre definie sur un nud dans /proc/sys/fork delay.


a` jour sa table des etats. Selon les cas, il peut decider de lancer un processus en attenteou bien il passe le message au nud suivant.

Le processus gerant la charge : int fd v2 manager thread()

Le pseudo-algorithme est le suivant :

BOUCLE_SUR :load = charge_du_noeud_local();SI load == idle ET last_load == idle ALORS

SI du_travail_en_attente ALORSexecuter_travail_en_attente();

SINONne_rien_faire();

FINSISI load == idle ET last_load == not_idle ALORS

SI du_travail_en_attente ALORSexecuter_travail_en_attente();

SINONpropager_changement_etat();

FINSISI load == not_idle ET last_load == not_idle ALORS

SI du_travail_en_attente ALORSSI rechercher_un_noeud_disponible() == vrai ALORS

executer_travail_en_attente_sur_noeud_disponible();FINSI

FINSIFINSISI load == not_idle ET last_load == idle ALORS

propager_changement_etat();SI du_travail_en_attente ALORS

SI rechercher_un_noeud_disponible() == vrai ALORSexecuter_travail_en_attente_sur_noeud_disponible();

FINSIFINSI

FINSIFINBOUCLE_SUR

Les processus gerant la mise a` jour de letat des nuds

Nous utilisons deux processus du noyau afin de gerer letat des nuds : un pourtraiter les messages de type READY concernant letat inactif et lautre pour traiter lesmessages de type NOT READY concernant letat actif.


handle ready(); Tout message recu par cette fonction contient comme valeur liden-tifiant du nud dont letat est disponible (IDLE ).

Lorsquun message est recu, alors, le nud recevant le message verifie que le messagenest pas en train de boucler. Si tel est le cas, il detruit le message. Puis, sil dispose detravaux en attente, alors il reveille un processus sur le nud se declarant disponible etdetruit le message. Sinon, il met a` jour sa table des etats et transmet le message a` sonvoisin.

Algorithme :

entier msg = reception_message();//msg contient lid dun noeud dont letat est passe a IDLE

SI (emetteur(msg) != self ET valeur(msg) == self) ALORS//le message a fait une boucleretourner(-1);

FINSI;SI (du_travail_en_attente() == TRUE) ALORS

//je dispose de travail en attente, et le noeud valeur(msg) est disponible :wake_up_pfd(valeur(msg)); //je reveille un processus differeretourner(1);

FINSI;mettre_a_jour_la_table_des_etats(msg);transmettre_le_message_au_voisin(msg);

handle not ready(); Tout message recu contient comme valeur lidentifiant du nuddont letat est indisponible (NOT IDLE ). Lorsquun message est recu sur ce canal, alorsle nud recevant le message verifie que le message nest pas en train de boucler. Si telest le cas, il detruit le message. Sinon, il met a` jour sa table et fait passer le message a`son voisin.

Algorithme :

entier msg = reception_message();//msg contient lid dun noeud dont letat est passe a NOT_IDLE

SI (emetteur(msg) != self ET valeur(msg) == self) ALORS//le message a fait une boucleretourner(-1);

FINSI;mettre_a_jour_la_table_des_etats(msg);transmettre_le_message_au_voisin(msg);


4.2.5 Comparaison qualitative des deux strategies implementees

Intuitivement, nous pouvons penser que la strategie du reveil a` linitiative de chaquenud est plus performante que celle a` linitiative dun nud appartenant a` un anneauavec jeton. En effet, dans la solution comple`tement distribuee, il est tout a` fait possibleque sur une meme grappe, deux nuds disponibles puissent simultanement recevoir dutravail de la part dautres nuds. Cela nest pas possible dans la solution a` linitiativedun nud appartenant a` un anneau avec jeton, le jeton centralisant toutes les actions.De plus, dans cette dernie`re solution, chaque nud scrute la charge de tous les autresnuds par lintermediaire de la fonction get dynamic node info(node id); 5. Cette fonc-tion fait appel a` des mecanismes entranant une communication reseau importante alorsque, par opposition, la solution distribuee ne fait que scruter la charge locale du nud(et donc, il ny a pas dacce`s au reseau).

Enfin, prenons le cas dune grappe chargee. Avec la version a` linitiative dun nudappartenant a` un anneau avec jeton, le nud possedant le jeton, va continuellementchercher un nud libre pour essayer de consommer son jeton au plus vite. Cela entraneegalement une petite surcharge inutile. Alors quavec la version du reveil a` linitiativede chaque nud, que la grappe soit chargee ou non, comme chaque nud ne fait quescruter sa propre charge et ne previent les autres nuds que lorsque celle-ci varie signi-ficativement, le gain en communication reseau est important.

Nous conjecturons donc que la version a` linitiative de chaque nud est plus perfor-mante que celle a` linitiative dun nud appartenant a` un anneau avec jeton.

4.3 Ordonnancement des processus geres en mode differe

4.3.1 Preambule

Un processus differe occupe des ressources qui peuvent etre a` tout moment requisi-tionnees par dautres processus non differes. Pour que la charge de la grappe naugmentepas de manie`re trop importante, il est necessaire de stopper les processus differes encours dexecution afin quils liberent les ressources quils utilisent si ces ressources sontrequisitionnees.

Pour decider de larret dun processus, nous avons trois aspects a` etudier : comment detecter que nous devons arreter un processus differe, quel processus est a` arreter, et comment larreter.Pour ce faire, nous allons etudier lordonnanceur de Kerrighed et principalement la

fonction migration manager thread() ainsi que les procedes darret dun processus.

4.3.2 Ordonnanceur de Kerrighed : la fonctionmigration manager thread()

La fonction de lordonnanceur de Kerrighed migration manager thread() est appeleea` chaque fois que la charge sur un nud devient trop importante. Son fonctionnement

5. Fonction interne a` Kerrighed.

4.3. ORDONNANCEMENT DES PROCESSUS GERES EN MODE DIFFERE 37

est le suivant :Boucle sur : est reveille lorsque la charge du nud est trop importante : sleep on task (current); cherche un processus a` migrer : tsk = find a process to migrate (); cherche un nud pour effectuer la migration :nodeid = find a node according to the scheduling policy(tsk);

realise la migration : do migrate process(tsk, nodeid);

4.3.3 Quand arreter un processus differe

La fonction migration manager thread() est reveillee a` chaque fois que la charge dunud est trop importante. Cest donc a` ce moment la` que doit intervenir la gestion desprocessus differes. Nous decidons darreter un processus differe si la charge du nudcourant est trop importante, et quil ny a pas de processus ayant la capacite de mi-gration en cours dexecution ou quil ny a pas dautres nuds disponibles. Au final,nous decidons darreter un processus si la condition suivante est respectee : (la chargedu nud local est trop importante) ET (il ny a pas de processus pouvant etre deplaceOU il ny a pas de nud disponible dans la grappe).

4.3.4 Detection dun processus a` arreter

Pour arreter un processus differe, nous parcourons la file des processus eligibles (parappel a` la fonction find a process delayed running()) et nous recherchons les processusdont letat (fd flag) est marque comme etant un processus differe.

4.3.5 Arret dun processus differe

Pour arreter un processus nous disposons de plusieurs methodes. En espace utili-sateur, il est possible denvoyer un signal (voir section 3.2.1) au processus. Dans unepremie`re approche, nous nous interessons plus particulie`rement aux signaux :

SIGSTOP, SIGCONT.Ces signaux permettent de stopper (SIGSTOP) un processus et de le reprendre

(SIGCONT ) a` lendroit ou` il sest arrete.

Proble`me : ces signaux sont recus par un processus lorsquun eve`nement exterieurintervient (exemple, lutilisateur ou lordonnanceur envoie explicitement un signal) et apour effet dexecuter un code specifique au processus. Par defaut, un signal SIGSTOPmet le processus concerne dans letat TASK STOP. Le processus qui recoit un SIGSTOPa (( conscience )) quil recoit un signal, et a (( conscience )) quil sarrete 6. Dans le cadre dudeveloppement dun syste`me transparent a` lutilisation, nous remarquons que le procede

6. La commande ps permet de voir tous les processus stoppes


precedemment cite ne convient pas. Le processus doit pouvoir etre arrete, redemarre,deplace en toute transparence.

Il nous a donc fallu trouver une autre methode : mettre les processus differes dansletat UNINTERRUPTIBLE (etat qui bloque lexecution dun processus en lenlevantde la file des eligibles).

Les operations de gestion des processus

Comme vu precedemment, Kerrighed ge`re la migration de processus, la sauvegardede points de reprise. Pour ce faire, il existe dans la task struct un champ aragorn actionpermettant de positionner laction a` realiser avec le processus lors de lenvoi dun signalKerrighed (vu en section 3.2.2). Par exemple, si lon realise :tsk->krg_task->aragorn->aragorn_action = TO_MIGRATE;

et que lon envoie un signal Kerrighed sur ce processussend_kerrighed_signal(tsk);

alors la prochaine action realisee sur le processus (quand lordonnanceur le decide)est une migration. Nous procedons de la meme manie`re en definissant une operationFORK DELAY STOP PROCESS. Ainsi, lorsque lordonnanceur decide de stopper unprocessus differe en cours dexecution, il lui met comme operation a` realiser :tsk->krg_task->aragorn->aragorn_action = FORK_DELAY_STOP_PROCESS;

et lui envoie un signal Kerrighed. Cela a pour effet de mettre le processus en etatUNITERRUPTIBLE, de lenlever de la file des processus eligibles et de le mettre dansla liste des processus differes (en debut de liste).

4.3.6 Synthe`se

A` partir de la description faite en 4.3.2, nous voyons que lorsque la fonction mi-gration manager thread() se reveille cest quelle cherche a` effectuer une migration pourequilibrer la charge de la grappe. Or, il est possible quelle ny arrive pas dans deux cas :

si elle ne trouve pas de processus a` migrer, si elle ne trouve pas de nud pouvant recevoir le processus a` migrer.

Cest la` que doit intervenir la gestion des processus differes.Voici le principe de notre algorithme : verifier la charge courante du nud :

si elle est faible : ne rien faire. sinon, si des processus differes sont en cours dexecution, alors il faut enstopper.

chercher un processus differe en cours dexecution a` stopper :tsk = find a process delayed running();

mettre laction FORK DELAY STOP PROCESS dans aragorn action, lui envoyer le signal darret : send kerrighed signal(tsk); le rajouter en debut de la liste des processus differes dans un etat non-bloque.

4.4. LA CHARGE VIRTUELLE : VLOAD 39

Ainsi le processus est stoppe et est mis en debut de liste des processus differes, preta` etre reveille de nouveau.

4.4 La charge virtuelle : vload

Lorsquun processus est en cours dexecution, il consomme de la ressource processeur.De ce fait, la charge du nud ainsi que celle de la grappe augmente. Kerrighed utilisela sonde MOSIX [28, 19, 26] afin de donner une evaluation de la charge du processeur.Cette charge est calculee (moyenne ponderee) en fonction de la charge passee et de lacharge instantanee selon la formule :

charge(t) = ponderation(charge(t 1), charge instantanee)

Cependant, cette charge peut mettre jusqua` deux secondes av

documentfd

Documents

gestion des processus

gestion de la liste

processus differes274

gestion des travaux

differents syste

image unique kerrighed

recherche kerrighed

linitiative dun nud