Rapport de stage en Master Recherche Informatique

Transcription

1 Rapport de stage en Master Recherche Informatique Ordonnancement de tâches dans des grappes de calculateurs par Jérôme Gallard Équipe d'accueil : PARIS Encadrement : Christine Morin, Emmanuel Jeanvoine Juin 2007 Contact : IRISA / INRIA Rennes Campus universitaire de Beaulieu Avenue du Général Leclerc RENNES Cedex - France Téléphone :

2

3 Table des matières Résumé Mots-Clés Abstract Keywords Introduction 1 1 État de l'art Terminologie Notion de tâche Les ressources L'ordonnancement Les grappes gérées par les systèmes à exécution par lots Ordonnancement de tâches : les systèmes à exécution par lots Diérentes politiques d'ordonnancement Les grappes gérées avec les systèmes à image unique Introduction aux systèmes à image unique GLUnix BProc CPlant MOSIX Kerrighed Ordonnancement de tâches communicantes Le Gang-Scheduling Le Co-Scheduling Le co-ordonnancement faiblement couplé (loosely coordinated Co- Scheduling) Le co-ordonnacement exible (Flexible Coscheduling) Bilan Objectifs du stage Présentation des problèmes à traiter Contexte Caractéristiques d'un ordonnanceur Objectifs Approche Contributions Conception d'un ordonnanceur global congurable Infrastructure La politique globale d'ordonnancement Les collections I V V V V

4 II TABLE DES MATIÈRES La collection de ressources La collection de processus Agent de surveillance Surveillance des conditions d'utilisation des ressources Recherche d'actions correctrices Agent d'actions Action nécessitant une simulation Réalisation de l'action Modèle de priorité Exemple introductif Extension Bilan Présentation des algorithmes conçus Initialisation des centres de décision Fonctionnement des centres de décision pour une politique élémentaire 33 4 Application de notre approche à quelques politiques de l'état de l'art Démarrage des tâches avec priorité Politique Écriture de la politique Économie d'énergie Politique Écriture de la politique Filtre sur les processus Gestion dynamique d'applications parallèles à mémoire partagée Politique Écriture de la politique Mise en uvre Ordonnanceur modulaire Mise en uvre de l'ordonnancement dans le cadre de Kerrighed Spécicités du système à image unique Kerrighed Mise en uvre de l'ordonnanceur Gestion des unités Évaluations Conguration équilibrage mémoire Conguration équilibrage processeur Conguration avec priorité équilibrage de la charge processeur puis de la charge réseau Conclusion 57 Bibliographie V

5 TABLE DES MATIÈRES III

6 IV TABLE DES MATIÈRES

7 Résumé Le calcul à haute performance (HPC) est de plus en plus utilisé dans les laboratoires de recherche et l'industrie. Le but est d'exécuter des tâches (ou applications) sur des supercalculateurs, ou des grappes de calculateurs et cela de la manière la plus ecace possible. Le problème de l'ordonnancement des tâches dans les supercalculateurs est connu et de nombreux travaux ont déjà été eectués sur ce sujet. L'avènement des grappes de calculateurs ainsi que les contraintes spéciques qui leur sont liées amènent de nouveaux problèmes du point de vue de l'ordonnancement de ces tâches. De nouvelles contraintes liées aux grappes sont à prendre en compte. Par exemple, dans les grappes, un calcultateur peut avoir à adresser la mémoire d'un autre calculateur. Ceci peut entraîner une baisse des performances de l'ensemble du système si les tâches sont ordonnancées d'une quelconque manière. Ce document traite dans une première partie de ce qui a pu être réalisé concernant la gestion de tâches sur grappes de calculateurs. Puis, il propose une architecture générique d'ordonnanceur qui se veut simple, ecace et évolutif. Mots-Clés : Grappes de calculateurs, ordonnancement, applications parallèles. Abstract Nowadays, HPC (High Performance Computing) is very used for running simulations. The user has an application and a pool of ressources. He wants to run his application on this pool of ressources with a maximum of eciency. To do this, he needs a system able to manage the pool of ressources. We call this system a scheduler. To schedule an application on a supercomputer is now a well known topic. But, the happening of the clusters brings problems about application scheduling. For example, in a cluster, a node can acess to the memory of a distant node and, in certain cases can decrease the performances of the wall system. In this report, we will discuss about this several kinds of problem and we will give a design for a generic scheduler. Keywords : Clusters, scheduling, application. V

8 VI RÉSUMÉ

9 Introduction De nos jours, aussi bien dans l'industrie que dans les laboratoires de recherche, la puissance de calcul est de plus en plus recherchée pour l'exécution d'applications de plus en plus gourmandes en ressources. Par exemple dans l'industrie cinématographique la puissance de calcul est employée pour du calcul d'image. Dans des laboratoires de biologie, elle peut être employée pour des calculs d'anité génétique entre diérentes familles d'animaux. Dans tous les cas, l'objectif est d'exécuter les applications le plus rapidement possible, c'est-àdire réduire le temps entre la soumission de l'application et l'obtention des résultats. C'est cela qu'on appelle le calcul à haute performance (HPC - High Performance Computing). Autrefois, le calcul à haute performance était principalement réalisé sur des supercalculateurs. Avec l'évolution des technologies, une nouvelle architecture est apparue, c'est celle des grappes de calculateurs. Une grappe de calculateurs est l'interconnexion de calculateurs par un réseau rapide. Les grappes sont beaucoup plus évolutives que les supercalculateurs et cela aussi bien du point de vue du matériel que du logiciel. De plus, avec l'évolution du prix du matériel [7], les grappes de calculateurs s'implantent de plus en plus dans le monde du calcul intensif. An d'utiliser ecacement une grappe de calculateurs, il est nécessaire de faire de l'ordonnancement. L'ordonnancement consiste à exécuter un ensemble de tâches sur un ensemble de ressources selon une politique dénie. Les travaux présentés dans ce document ont été eectués au cours d'un stage de Master Recherche, qui s'est déroulé à l'irisa, au sein de l'équipe PARIS, et plus particulièrement dans le contexte de l'activité de recherche Kerrighed. Cette activité de recherche a pour but de concevoir et mettre en uvre un système d'exploitation nommé Kerrighed pour grappe de calculateurs. Kerrighed est un système à image unique qui permet une virtualisation des ressources. Son but est de fournir à l'utilisateur l'impression d'utiliser une machine multiprocesseur virtuelle an de faciliter l'utilisation de la grappe. Cependant, malgré cette facilité d'utilisation, l'on se rend compte que dans beaucoup de cas, la gestion des applications sur ces grappes n'est pas optimum, et les grappes sont sous-exploitées. Par exemple, prenons le cas d'une application constituée de plusieurs processus communicants. L'exécution de cette application sur une grappe peut perdre en ecacité si l'ordonnancement des processus se fait de manière quelconque. Cela est dû au fait qu'il est plus ecace d'ordonnancer des processus communicants simultanément. L'objectif de ce stage est de concevoir un ordonnanceur pour grappe de calculateur qui soit simple d'utilisation. Son but est d'être transparent par rapport à l'utilisateur. L'infrastructure que nous concevons doit permettre la régulation d'une charge de travail au cours du temps sur la grappe, c'est-à-dire ne pas exécuter plus de travail que la grappe n'est capable d'en exécuter pendant une unité de temps. De plus, elle doit faire de l'équilibrage de la charge entre les diérentes ressources de celle-ci, c'est-à-dire, homogénéiser au mieux le travail à eectuer sur toutes les ressources disponibles de la grappe. Ainsi, le placement et le déplacement des processus sur la grappe doit se faire cours du temps en fonction de la disponibilité des ressources. De plus, nous voulons que cet ordonnanceur soit congurable dynamiquement et évolutif, c'est-à-dire adaptable à diérente situation dénie par l'administrateur de la grappe. Enn, nous voulons une infrastructure générique qui ne soit pas contraint à un type d'action préréglé pour la gestion de ressources prédéterminées. Pour faire cela, dans le premier chapitre nous présentons l'état de l'art relatif à l'ordonnancement des tâches sur les grappes cela nous permet de faire un bilan et de dénir nos objectifs par rapport à l'existant. Puis, dans le second chapitre nous précisons le sujet de stage et les objectifs à atteindre. Le chapitre trois, expose les principes de conception de notre ordonnanceur. Dans un quatrième chapitre, nous présentons quelques politiques d'ordonnancement existantes que nous décrivons et que nous appliquons à notre ordonnanceur. Dans le cinquième chapitre, nous décrivons la mise en uvre du système et présentons 1

10 2 INTRODUCTION quelques évaluations de notre prototype. Enn nous concluons et donnons quelques perspectives de travail.

11 Chapitre 1 État de l'art Dans ce chapitre nous présentons l'état de l'art relatif à l'ordonnancement dans les grappes de calculateurs. Dans un premier temps, nous dénissons ce qu'est une tâche, une ressource et ce qu'est l'ordonnancement. Puis nous présentons les systèmes à exécution par lots ainsi que diérentes politiques d'ordonnacement de tâches qui permettent de gérer les n uds sur les grappes. Nous décrivons ensuite une autre méthode de gestion des n uds de la grappe avec les systèmes à image unique. Enn, nous introduisons la problématique des tâches communicantes. 1.1 Terminologie Notion de tâche La liaison entre les ressources dont dispose un ordinateur et les programmes que veut exécuter l'utilisateur est assurée par un système d'exploitation. Soit un processus [14] une succession d'instructions exécutées par un processeur et manipulées par l'ordonnanceur du système d'exploitation. On peut considérer un processus comme une instance d'un programme. Soit une tâche 1 éventuellement constituée de plusieurs processus coopérants. Elle peut être séquentielle ou parallèle. Une tâche composée de plusieurs processus peut donc s'exécuter sur une architecture de type multiprocesseur an que les processus de la tâche puisse s'exécuter sur des processeurs distincts. Certaines tâches ont des processus qui communiquent entre eux par échange de messages (MPI [4], PVM [5]). D'autres utilisent la mémoire partagée oerte par l'architecture ou le système d'exploitation [3]. Il existe des tâches qui peuvent être modiées en cours de fonctionnement, on les nomme tâches malléables. Ces tâches sont capables de s'adapter dynamiquement aux ressources disponibles sans avoir besoin d'être arrêtées et redémarrées Les ressources Dans les calculateurs Les ressources utilisées par un processus sont principalement : le processeur, la mémoire vive et les disques durs. Un processeur exécute les instructions des processus. La mémoire vive est un espace de stockage temporaire dont le temps d'accès (par le processeur) est très faible (de l'ordre de la centaine voire de la dizaine de nanosecondes). Les disques durs sont les unités de stockage permanent (temps d'accès très long de l'ordre de la dizaine de millisecondes). 1 Dans la littérature, on trouvera également la terminologie application ou encore application parallèle. 3

12 4 CHAPITRE 1. ÉTAT DE L'ART Les architectures multiprocesseurs (disposant de plusieurs processeurs et d'une mémoire qui peut être partagée ou non entre tous les processeurs) sont très utilisées dans le domaine du calcul à haute performance. Par exemple, nous pouvons citer les architectures de type SMP (Symmetric Multi Processor) pour lesquelles tous les processeurs ont un accès uniforme à la mémoire partagée. Un seul système d'exploitation gère l'ensemble des processeurs. Dans les grappes de calculateurs Une grappe de calculateurs est l'interconnexion de diérents calculateurs (appelés n uds). Une grappe est vue de l'extérieur comme une seule et même unité de traitement dans le cas où elle est gérée par un système à exécution par lots ou par un système à image unique (plus de détails sont donnés en section 1.2 et 1.3). L'interconnexion de ces diérents n uds est réalisée par l'intermédiaire d'un réseau à haute performance (GigaBit Ethernet [47], Myrinet [13], InniBand [35]). Chaque n ud dispose de son propre système d'exploitation. Une particularité des grappes est que le nombre et la disponibilité des ressources sont uctuants. En eet, un n ud peut être arrêté ou être défaillant sans aecter les autres n uds. De plus, dans une grappe, un processeur peut avoir à adresser la mémoire d'un n ud distant. Cela se fait par l'intermédiaire d'accès au réseau, ce qui augmente les temps de latence et peut entraîner une baisse signicative des performances [15] L'ordonnancement Dans les systèmes disposant de multiples ressources dont l'accès est possible simultanément par de multiples utilisateurs, il est nécessaire de mettre en adéquation les ressources disponibles avec les tâches à exécuter. C'est l'ordonnanceur qui est chargé de l'allocation des processeurs aux tâches. Il organise au mieux l'exécution des diérentes tâches qui lui sont soumises pour qu'elles soient toutes exécutées correctement. Pour ce faire, il gère le partage des processeurs entre diérentes tâches (qui elles même peuvent avoir plusieurs processus) s'exécutant concurremment. Selon le contexte, l'exécution correcte d'une tâche peut avoir diérentes signications. Par exemple, dans les systèmes temps réels, chaque tâche doit être exécutée et terminée dans un intervalle de temps donné. Dans le calcul à haute performance, le but de l'ordonnanceur est de maximiser l'utilisation des ressources pour diminuer le temps de séjour d'une tâche dans le système. Cela nécessite un environnement multiprogrammé, c'est-à-dire que diérentes tâches peuvent s'exécuter en même temps [37]. La gure 1.1 représente les diérentes interactions existant au sein d'un multiprocesseur (qui peut être un supercalculateur ou une grappe) entre les tâches, les processeurs et l'ordonnanceur : l'ordonnanceur sélectionne selon des critères d'administration des tâches à attribuer aux diérents processeurs. Ordonnancement en temps partagé L'ordonnancement en temps partagé consiste à allouer aux tâches s'exécutant sur le système des tranches de temps (time slice) pour l'accès aux ressources. C'est cela qui donne l'illusion que plusieurs processus s'exécutent simultanément sur un système monoprocesseur. La gure 1.2 représente un exemple d'ordonnancement en temps partagé : plusieurs tâches s'exécutent en concurrence sur un unique processeur. Les systèmes d'exploitation traditionnels (tel que Linux [14]) sont multi-tâches et ordonnancent les processus en temps partagé. C'est le système d'exploitation qui permet à un processus d'être exécuté pendant une certaine durée (time slice), puis le stoppe, change

13 1.1. TERMINOLOGIE 5 Fig. 1.1 Représentation des interactions entre les tâches, les processeurs et l'ordonnanceur. Fig. 1.2 Ordonnancement temporel (plusieurs processus pour un seul processeur).

14 6 CHAPITRE 1. ÉTAT DE L'ART de contexte 2 (opération coûteuse, pendant le temps du changement de contexte, aucune exécution de processus ne peut être réalisée) et en exécute un autre et ainsi de suite. L'ordonnancement temporel est fondamental pour tous les systèmes de gestion de tâches. De plus, il permet une bonne utilisation des ressources. En eet, si une seule tâche s'exécute à la fois dans le système, il est fort probable que des ressources restent inutilisées. Ainsi, le temps d'exécution de plusieurs tâches simultanément peut être inférieur à celui de l'exécution de ces mêmes tâches les unes après les autres. Ceci s'explique par le fait que pendant qu'une tâche est en attente d'une entrée/sortie, une autre tâche peut eectuer des calculs. Si les phases d'attente des tâches sont opposées, alors on obtient des performances supérieures à celle de leur exécution en séquence. Prenons l'exemple d'une tâche réalisant de longues lectures sur le disque dur. Le disque dur étant un périphérique d'entrée/sortie avec un fort temps de latence, il est alors intéressant d'ordonnancer au plus tôt l'exécution de cette tâche, an que, pendant le temps d'exécution d'une autre tâche, la lecture sur le disque se fasse. Ainsi, lorsque la première tâche reprend la main sur le processeur, ses données sont chargées et son exécution peut se poursuivre. De cette manière, le temps d'utilisation du processeur a été optimisé (il n'a pas passé de temps à attendre, mais au contraire, il a procédé à l'exécution d'un autre processus pendant ce temps d'attente). Ordonnancement spatial Un ordonnanceur spatial place des tâches sur diérents processeurs. L'ordonnancement spatial est utilisé lorsque les ressources sont distribuées (par exemple dans le cas des grappes de calculateurs). À chaque tâche est attribué un sous-ensemble distinct de processeurs : cela permet de répartir les tâches sur l'ensemble des processeurs disponibles an de les utiliser en parallèle. La gure 1.3 représente un exemple d'ordonnancement spatial. On y voit que les tâches sont exécutées sur diérents processeurs en même temps (parallélisme d'exécution). Quelques caractéristiques des ordonnanceurs Il existe diérentes politiques d'ordonnancement. Un ordonnanceur peut-être capable de gérer des applications temps réel, c'est-à-dire des applications nécessitant une date xe de n d'exécution. Il peut également être adapté à d'autres types d'applications. Par exemple, l'ordonnancement d'un ordinateur de bureau va privilégier tous les accès interactifs au détriment d'une compilation qui se déroule en arrière plan. En revanche, un serveur va optimiser au mieux l'utilisation de toutes ses ressources au détriment de l'interactivité (ce qui est encore plus vrai dans le cas de serveurs de calcul à haute performance). Nous dénissons ci-après quatre critères d'ordonnancement. Ces critères nous permettrons par la suite de discuter des ordonnanceurs présentés en section Ecacité : l'ordonnanceur doit utiliser de manière maximale l'ensemble des ressources. Interactivité : l'ordonnanceur doit faire la diérence entre une tâche interactive exigeant une réponse immédiate et une tâche non-interactive (compilation, calcul d'images...). Équité : les processus ne peuvent pas intervenir auprès de l'ordonnanceur pour bénécier de plus de temps d'exécution. Prévention contre la famine : l'ordonnanceur doit s'assurer que tous les processus sont lancés en temps borné. Prenons le cas de deux tâches : l'une réalisant un calcul intensif (forte utilisation du processeur) et l'autre orientée entrées/sorties (exemple, un traitement de texte qui attend 2 Soit deux processus P1 et P2. P1 est en cours d'exécution. L'opération de changement de contexte de P1 à P2 consiste principalement à sauvegarder les registres du processeur (P1) et restaurer le nouvel état du processeur (P2)[6].

15 1.2. LES GRAPPES GÉRÉES PAR LES SYSTÈMES À EXÉCUTION PAR LOTS 7 Fig. 1.3 Ordonnancement spatial (plusieurs processus pour plusieurs processeurs). la frappe au clavier de l'utilisateur). Il est évident que même les utilisateurs les plus chevronnés, ne taperont pas aussi vite qu'une tâche est capable d'utiliser le processeur. Le but de l'ordonnanceur est donc d'allouer le plus possible le processeur au processus réalisant un calcul intensif tout en ne dégradant pas l'interactivité entre la frappe au clavier de l'utilisateur et l'achage du caractère à l'écran. 1.2 Les grappes gérées par les systèmes à exécution par lots Les grappes sont traditionnellement gérées par un système à exécution par lots (batch [9]) dans le domaine du calcul à haute performance. On distingue dans les grappes un n ud maître et des n uds de calcul. Le n ud maître est le point d'accès au système à exécution par lots et c'est lui qui accède aux ressources de la grappe. La gure 1.4 représente une architecture de grappe gérée par un système à exécution par lots avec N0 le n ud maître et N1-N6 les diérents n uds de calcul. Il existe diérents types d'ordonnanceur : les ordonnanceurs statiques (que nous détaillons dans cette section) et les ordonnanceurs dynamiques (vus en section 1.3). Les ordonnanceurs statiques attribuent une tâche sur un n ud à sa création. Ce type d'ordonnanceur est utilisé dans certains systèmes à exécution par lots (PBS/TORQUE [27] en est un exemple) ou par les implémentations des librairies telles que MPICH [2] ou LAM- MPI [1] pour MPI [4] ou PVM [5]. Ces ordonnanceurs ne peuvent réagir si la charge se déséquilibre entre les diérents n uds au cours du temps Ordonnancement de tâches : les systèmes à exécution par lots Les systèmes à exécution par lots font de l'ordonnancement spatial. Ils sont capables d'écouler une charge de travail sur une période de temps et de manière distribuée sur un ensemble de ressources distribuées. PBS/TORQUE [27], IBM LoadLeveler [19], OAR [18], Condor [44] sont des systèmes à exécution par lots. Ces systèmes disposent de la capacité d'exécuter de manière diérée les tâches qui leur sont soumises. Ces tâches sont alors mises en le d'attente en attendant leur exécution. Généralement, une tâche est exécutée lorsqu'une autre se termine. Les diérents processus d'une tâche parallèle s'exécutent sur

16 8 CHAPITRE 1. ÉTAT DE L'ART Fig. 1.4 Architecture Beowulf. diérents processeurs. L'ordonnanceur alloue à chaque tâche le nombre de processeurs dont elle a besoin. Idéalement une tâche devrait bénécier de toutes les ressources du système pour elle seule. Cependant, cela entraînerait une sous-utilisation des ressources de la grappe : certaines ressources resteraient inutilisées, ce qui créerait une fragmentation des ressources de la grappe et donc une sous-utilisation des ressources disponibles. An d'exploiter au mieux les ressources disponibles, des politiques d'ordonnancement ont été créés. Elles sont spéci- ques à certaines classes d'applications. Nous en décrivons les principales dans la section suivante Diérentes politiques d'ordonnancement L'ordonnancement pose des problèmes d'équité. Par exemple, une longue tâche lancée depuis 3 jours, doit-elle garder la main sur tous les processeurs, alors que d'autres petites tâches sont prêtes à être exécutées et ont un temps d'exécution plus court? Faut-il stopper l'application longue? Faut-il poursuivre son exécution et diérer les applications plus courtes? Toutes ces questions ne sont pas triviales et il n'y a sans doute pas de réponse générale convenant à toutes les situations. Cependant, diérentes techniques d'ordonnancement [41] répondant chacune à une catégorie de problèmes ont été proposées, c'est ce que nous voyons dans les paragraphes suivants. Sans retard La séquence d'exécution des tâches est la même que celle de soumission (l'arrivée d'une tâche dans la le ne peut décaler l'heure de démarrage d'une tâche arrivée plus tôt). L'avantage de cette technique est qu'elle est simple à implémenter. De plus, elle est équitable et assure qu'il n'y a pas de risque de famine. Cependant, elle ne gère pas la diérence entre les tâches interactives et celles qui ne le sont pas. Nous présentons dans les paragraphes suivants une implémentation de cette technique ainsi que diérentes optimisations qui permettent d'améliorer son ecacité [37].

17 1.2. LES GRAPPES GÉRÉES PAR LES SYSTÈMES À EXÉCUTION PAR LOTS 9 FCFS. Il existe diérentes politiques pour décider de l'allocation des processeurs aux tâches en attente. La politique la plus simple est celle appelée FCFS (First Come, First Served). Elle est fondée sur une politique sans retard avec une seule le d'attente. Lorsqu'une tâche arrive, elle est automatiquement mise dans cette le et n'est servie que lorsque celles qui sont arrivées avant elle dans la le ont été exécutées. Cette méthode ne permet pas une utilisation ecace des ressources [28] (en moyenne, seulement 25% des ressources sont utilisées sur la machine IBM/SP2 avec le système à exécution par lots LoadLeveler). En eet, cette politique ne prend pas en compte la fragmentation de l'espace (seule une tâche peut être exécuté à la fois ce qui peut entraîner une sous-exploitation de certaines ressources). Déclinaison. Une déclinaison de cette politique en politique gloutonne consiste à vider la le d'attente des tâches en attribuant à chaque fois le nombre minimal de ressources requises et de recommencer immédiatement avec la prochaine tâche en le d'attente (si la prochaine tâche en le d'attente exige plus de ressources qu'il y en a de disponible, alors l'algorithme se bloque en attendant une libération des ressources). Cependant, cette politique n'est pas très ecace non plus. En eet, si plusieurs grosses tâches se suivent dans la le d'attente, elles ne peuvent pas s'exécuter en même temps parce qu'elles demandent trop de ressources. FCFS-FF. Une autre politique pour remédier à ce problème est le FCFS-FF (First Come, First Served, First Fit). Cette politique permet de mettre les tâches dans diérentes les (dépendant par exemple du temps d'exécution de la tâche). Et ensuite, par exemple, selon les horaires (travaux de nuit : travaux ayant un long temps d'exécution, travaux de jour : travaux ayant un court temps d'exécution), l'ordonnanceur vide les diérentes les (selon une politique FCFS). La première tâche trouvée dans les les qui correspond à la politique en cours est exécutée. Bien qu'elle soit plus performante, cette technique n'est pas non plus la plus ecace [28] (40% à 60% des ressources sont utilisées). Backlling [39]. La technique du backlling permet d'exécuter des tâches de courte durée qui sont à la n de la le d'attente avant des tâches de longue durée qui sont placées devant dans la le. Pour réaliser cela il faut soit que l'utilisateur spécie une durée approximative de temps d'exécution de sa tâche, soit que l'ordonnanceur est capable de trouver ces informations à partir des analyses de compilation. En pratique, dans la plupart des cas, il est demandé à l'utilisateur de fournir une durée approximative du temps d'exécution de sa tâche. Soit une tâche A de longue durée en cours d'exécution sur diérents n uds. Supposons qu'il reste des n uds non utilisés par A. Le backlling permet d'exécuter des tâches sur les n uds restants disponibles à condition que ceux-ci ne se terminent pas après la tâche A (cela dans le but de ne pas décaler le démarrage de la tâche B qui est encore en le d'attente mais qui n'a pu être démarrée, faute de ressources disponibles en quantité susante). Cette technique permet une utilisation des ressources d'environ 80% [28]. Priorités Une priorité est attribuée à chaque tâche. Cette priorité dépend de l'importance de la tâche ou bien de son temps d'exécution. L'avantage de cette méthode est qu'elle permet de traiter des travaux de courte durée rapidement. Ainsi cette méthode est ecace (maximisation de l'utilisation des ressources), et est d'une certaine manière interactive (les tâches plus courtes peuvent être exécutées avant les plus longues). L'inconvénient est qu'il peut y avoir un risque de famine.

18 10 CHAPITRE 1. ÉTAT DE L'ART LOS - Lookahead Optimizing Scheduler [39]. LOS est un algorithme d'ordonnancement qui ne parcourt pas uniquement la le à la recherche de la première tâche qui pourrait être exécutée pour boucher les trous, mais qui recherche dans la le l'ensemble des tâches à exécuter en même temps an de maximiser le taux d'utilisation des ressources. Cependant, en cas de forte charge les performances de cet ordonnanceur peuvent diminuer (l'algorithme perd en performance s'il y a un grand nombre de tâches en le d'attente). Pour y remédier, il a été introduit un nouveau paramètre qui correspond à la taille de la fenêtre de la le dans laquelle l'ordonnanceur cherche le meilleur agencement possible entre les tâches (la taille de la fenêtre est bien entendu inférieure à celle de la longueur totale de la le d'attente). Retard limite La méthode du retard limite assigne à chaque tâche un temps limite de retard à l'exécution en relachant ainsi les contraintes liées à l'ordre de soumission des tâches. Lors de la soumission à chaque tâche est assigné un délai d qui va dénir le temps maximum que la tâche peut attendre avant d'être lancée (la tâche peut donc être lancée pour tout instant t tel que t d). Ce type d'ordonnancement est ecace. Cependant, le coût de calcul de l'ordonnanceur est lui très important. De plus, le risque de famine est évité et cette technique permet d'une certaine manière de gérer les applications intéractives (une application courte, interactive, à de fortes chances d'être exécutée avant une application longue, non-interactive). IBM SP Scheduler [42]. L'IBM SP Scheduler allie la méthode de priorité et celle de retard limite. À chaque tâche est associée une priorité et un retard limite. Chaque fois qu'une nouvelle tâche est insérée dans la le, toutes les priorités et retards limites sont recalculés. Puis, l'ordonnanceur choisit d'exécuter les meilleures tâches. Par exemple, si une tâche A est soumise avec un temps d'exécution estimé à 15 minutes et que dans la le d'attente, il y a une tache B (de même priorité que A) dont le délai maximum de lancement est xé à 60 minutes, alors l'ordonnanceur va pouvoir lancer la tâche A, en sachant que lorsqu'elle se nira, la tâche B, n'aura pas dépassé son heure limite de lancement. Les techniques employées dans l'ordonnanceur IBM SP Scheduler apporte un gain d'environ 10% par rapport au backlling. Heure de n Cette méthode impose à une tâche une heure de n d'exécution. Elle est très utilisée dans les systèmes qui sont à temps réel. Le problème majeur de cette méthode est que dans certains cas il n'est pas possible de trouver une adéquation entre les travaux à exécuter et les diérentes heures de n à respecter. Ces algorithmes sont très contraignants car ils doivent gérer les applications intractives tout en étant ecace et en assurant qu'il ne puisse y avoir un risque de famine. EDF - Earliest Deadline First [29]. EDF est un algorithme d'ordonnancement préemptif utilisé dans les systèmes temps réel. Il attribue une priorité à chaque tâche en fonction de la date d'échéance de cette dernière. Au plus vite une tâche doit être réalisée, au plus tôt elle aura de chances d'être exécutée. Un défaut de cet algorithme est qu'il ne sait pas gérer les tâches lorsque le système est surchargé. Dans ces conditions l'utilisation d'un tel algorithme peut devenir hasardeux.

19 1.3. LES GRAPPES GÉRÉES AVEC LES SYSTÈMES À IMAGE UNIQUE 11 RED - Robust Earliest Deadline [17]. RED est un ordonnanceur plus robuste que EDF car il donne des garanties que EDF n'a pas dans le cas où le système devient surchargé. RED est fondé sur un service minimum garanti. Deux types de tâches sont dénis, les tâches critiques et les autres. Les tâches critiques sont assurées de se terminer dans tous les cas dans le temps imparti. Les tâches non critiques peuvent subir un léger retard en cas de surcharge du système. Économique / coût L'énergie et la consommation électrique des équipements informatiques devient un véritable enjeu dans les centres de calculateurs (ce qui est particulièrement vrai avec les grappes dont le nombre de n uds tend à augmenter). En eet, avec plusieurs centaines de calculateurs en fonctionnement simultané, les coût engendré pour le refroidissement des salles informatiques ainsi que celui d'alimentation de tous les calculateurs est très important (sans parler des problèmes environnementaux liés à cette forte consommation d'énergie) [12]. Par exemple, un calculateur équipé d'une alimentation de 300 Watt coûtera 338$US par an en electricité (et cela sans prendre en compte les coûts liés à la climatisation). Pour remédier à cela des techniques d'ordonnancement ont été mis en place. Ils ne sont pas des plus ecaces mais permettent d'économiser de l'énergie. LC - Load Concentration [12]. L'ordonnanceur de concentration de charge (LC) tente de charger certains n uds de la grappe au maximum an de pouvoir mettre en mode veille à des ns d'économie d'énergie les n uds non utilisés. Dans le cas où la charge augmente, les n uds éteints se réactivent an de ne pas créer de dégradation des performances. Bilan Nous venons de voir diérentes catégories d'ordonnancement répondant à certains types de tâche. Bien entendu les catégories dénies précedemment ne sont pas indépendantes. Il est tout à fait possible d'avoir des ordonnanceurs intégrant plusieurs de ces diérentes techniques en même temps. Par exemple, d'une certaine manière, la technique du backlling est fondée sur la méthode sans retard (les tâches arrivées plus tôt dans la le ne sont pas retardées) et sur celle de priorité (les tâches de petit temps d'exécution ont une plus forte priorité que les longues). 1.3 Les grappes gérées avec les systèmes à image unique Introduction aux systèmes à image unique Les architectures de systèmes à image unique (SSI - Single System Image) permettent une gestion globale des processus s'exécutant sur une grappe. Certains systèmes à image unique disposent de n uds maitres comme GLUnix [24], BProc [25], CPlant [36]. Pour accéder à la grappe, l'utilisateur doit passer par le n ud maître (un peu comme les grappes gérées par les systèmes à exécution par lots, vus en section 1.2.1). La diérence avec les systèmes à exécution par lots est qu'à partir du n ud maître, les processus de la grappe sont manipulables comme s'ils étaient locaux au n ud maître (l'utilisateur peut par exemple, exécuter un ps 3 et la liste de l'ensemble des processus exécutés sur l'ensemble des n uds de calcul est retournée à l'utilisateur). Les ordonnanceurs de ce type de système sont centralisés sur le n ud maître comme pour les systèmes à exécution par lots. D'autres systèmes à image unique fournissent non seulement la gestion globale des processus, mais également celle des ressources. Ainsi, ils fournissent à l'utilisateur l'impression 3 La commande ps des systèmes Unix permet de lister l'ensemble des processus présent sur le système.

20 12 CHAPITRE 1. ÉTAT DE L'ART Fig. 1.5 Architecture de type SSI. d'utiliser la grappe comme une machine multiprocesseur virtuelle. MOSIX [11], Kerrighed [31] que nous détaillons dans les sections suivantes sont des exemples de systèmes à image unique dans lesquels il n'y a pas de n uds maîtres (c'est-à-dire que tous les n uds sont équivalents). Les tâches peuvent être soumises à partir de n'importe quel n ud. Dans ce cas, l'ordonnanceur est distribué sur l'ensemble des n uds. La gure 1.5 représente une architecture de type système à image unique sans n ud maître. Les ordonnanceurs prenant en compte l'état des n uds en temps réel sont appelés ordonnanceurs dynamiques. Dans la catégorie des ordonnanceurs dynamiques, il y a ceux qui sont capables de déplacer des tâches au cours du temps (ordonnanceur dynamique préemptif), et ceux qui ne le sont pas (ordonnanceur dynamique non préemptif). Pour pouvoir faire de l'équilibrage de charge, il faut que le système ait un ordonnanceur dynamique préemptif. C'est ce qu'ont la plupart des systèmes à image unique. Une politique d'équilibrage de charge dans les grappes consiste à répartir la charge entre les diérentes ressources de manière équivalente, le but étant d'exploiter au mieux, l'ensemble des ressources disponibles sur le système [45, 37]. Les diérents types de charge pouvant être pris en compte sont principalement, le taux d'utilisation du processeur, le taux d'occupation de la mémoire. An d'être ecace, la politique d'équilibrage de charge doit prendre en compte l'état des ressources en temps-réel pour y eectuer des ajustements dans le placement des processus. C'est l'ordonnanceur global (de part la connaissance qu'il a de l'état des ressources du système) qui détecte les déséquilibres de la charge et agit en conséquence. Un inconvénient de l'équilibrage de charge est le surcoût engendré par l'audit des n uds an de détecter un déséquilibre de la charge et le surcoût engendré par le calcul des décisions à prendre an de ré-équilibrer au mieux cette charge. Le calcul des décisions consiste à chercher quels processus sont à déplacer d'un n ud (chargé) vers un autre (moins chargé). Pour pouvoir faire de l'équilibrage de charge, le système doit disposer donc d'un mécanisme spécique : la migration de processus [30]. Ce mécanisme permet à un processus en cours d'exécution d'être déplacé d'un n ud à un autre. Dans le cas d'un ordonnaceur centralisé, en cas d'un déséquilibre de la charge dans la grappe, le ré-équilibrage de celle-ci est à l'initiative du n ud maître. Dans le cas d'un ordonnanceur distribué, lorsqu'il y a un déséquilibre de la charge dans la grappe, le ré-équilibrage de celle-ci peut être à l'initiative de : l'expéditeur : le n ud qui se considère surchargé essaye de déplacer l'un de ses processus vers un autre n ud moins chargé (technique ecace pour une grappe qui est en moyenne faiblement chargée),

21 1.3. LES GRAPPES GÉRÉES AVEC LES SYSTÈMES À IMAGE UNIQUE 13 du récepteur : les n uds disponibles se font connaître pour recevoir des processus de la part d'autres n uds plus chargés (technique ecace pour une grappe qui est en moyenne fortement chargée), politique symétrique : mélange des politiques à l'initiative de l'expéditeur et du récepteur (technique ecace pour une grappe qui est en moyenne moyennement chargée), politique aléatoire : les n uds utilisés pour l'ordonnancement des processus sont choisis aléatoirement. Nous présentons dans les sections suivantes diérents systèmes à image unique ainsi que leurs spécicités par rapport à l'ordonnancement GLUnix GLUnix (Global Layer Unix) [24] est un système à image unique car il ore une gestion globale des processus. Il est implémenté dans l'espace utilisateur. Son but est de rendre transparent l'ensemble des ressources distribuées à l'utilisateur par l'intermédiaire d'un n ud maître. GLUnix fait de l'équilibrage de charge et du Co-Scheduling (voir la section 1.4.2). En eet, GLUnix dispose d'un système à exécution par lots intégré. Les décisions d'ordonnancement sont centralisées. Chaque n ud de calcul notie au n ud maître un changement de sa charge. La gestion des processus se fait par l'intermédiaire des signaux Unix standard, avec par exemple l'utilisation de SIGSTOP, SIGCONT pour arrêter et redémarrer un processus BProc BProc (Beowulf Distributed Process Space) [25] est un système à image unique (lui aussi au sens de la globalisation des processus) qui nécessite un n ud maître. Avec BProc, tous les n uds ne sont pas équivalents, il y a un n ud maître et n n uds de calcul. On accède aux n uds de calcul par l'intermédiaire du n ud maître. BProc dispose de mécanismes tel que la migration de processus qui simplie la distribution des tâches sur l'ensemble des n uds de calcul. Tous les processus peuvent être manipulés depuis le n ud maître. BJS (Bproc Job Scheduler) [34] est un système à exécution par lots tolérant aux fautes pour BProc. BJS n'a pas de démon exécuté en permanence sur les n uds de calcul contrairement à la plupart des systèmes à exécution par lots. En eet, il utilise uniquement les informations fournies par BProc sur le n ud maître. BJS dispose d'un espace d'attente. Un processus soumis est mis dans cet espace avec une certaine priorité. Les processus ne sont retirés de cet espace d'attente que s'ils répondent à certaines propriétés. Les priorités sont recalculées en temps réel en fonction du temps passé dans l'espace d'attente, du type de tâche, du temps passé en cours d'exécution. Par exemple, une tâche qui dépasserait sa date de n d'exécution ne va pas être stoppée, mais va se voir attribuer une priorité très faible (ce qui permet de ne pas l'arrêter complètement, car son exécution pourra reprendre lorsqu'il n'y aura plus de processus de priorité supérieure dans l'espace d'attente). L'avantage de BJS est que l'ordonnanceur n'a pas de démon déployé sur l'ensemble des n uds de calcul et peut contrôler l'ensemble des n uds sans communication avec ceux-ci (c'est BProc qui se charge de cela). Enn, BJS est notié par BProc en cas d'ajout/retrait de n uds (ce n'est pas lui qui fait directement des tests de communication avec les n uds de calcul) CPlant CPlant (Computational Plan) [36] est initialement conçu pour gérer simplement et ecacement les grandes grappes de calculateurs (un millier de processeurs). CPlant est fondé sur un système Linux. Il dénit des partitions entre ses diérents n uds :

22 14 CHAPITRE 1. ÉTAT DE L'ART les n uds de service (n uds d'interfaces avec l'utilisateur), les n uds de calcul (réalisent les calculs), les n uds d'entrée/sortie (principalement les n uds de stockage). Elle est composée de 4 modules : un contrôleur qui contrôle les ressources de chaque n ud (PCT - Process Control Thread), un allocateur qui assigne les travaux sur les n uds (Bebopd), un lanceur qui déploie les applications (typiquement dans le cas d'application parallèle, Yod), un ordonnanceur responsable d'appliquer les politiques d'ordonnancement (ici, PBS). Le PCT est exécuté sur tous les n uds de calcul. C'est lui qui communique (donne l'état du n ud et exécute les tâches qui lui sont conées) avec les n uds de service (c'est l'allocateur qui se trouve sur les n uds de service qui reçoit les informations des PCT). L'allocateur dispose donc d'une connaissance globale de l'état de la grappe. En ce qui concerne l'ordonnanceur [16], chaque noeud dans la partition de service dispose d'un serveur PBS. PBS a été modié an qu'il puisse intéragir avec le lanceur (Yod) et l'allocateur (Bebopd). L'allocateur qui possède une connaissance globale des n uds de calculs met à jour le serveur PBS dans le cas d'ajout/retrait de n ud MOSIX MOSIX [11], est un système d'exploitation à image unique. C'est une extension du noyau Linux qui permet d'orir une vision globale de la grappe. L'ordonnancement global dans MOSIX est fondé sur une politique probabiliste qui s'appuie sur une vision partielle des processeurs de la grappe. Il est implémenté de manière distribuée sur l'ensemble des n uds de la grappe. Chaque n ud ne dispose que d'une connaissance partielle de l'état des autres n uds de la grappe (avoir une connaissance totale serait beaucoup trop coûteuse, et ne passerait pas à l'échelle), et c'est à partir de ces connaissances que les n uds prennent leurs décisions d'ordonnancement. Pour ce faire, ils regardent la longueur de la le des prêts par rapport au temps qu'il faut pour déplacer un processus : si le temps qui s'écoule entre deux tranches de temps concernant l'exécution d'un processus est plus long que le temps nécessaire pour le déplacer sur un n ud libre, alors il vaut mieux le déplacer an d'équilibrer la charge. Cependant, si un processus commence à faire de la pagination sur disque (c'est-à-dire qu'il n'a plus assez de mémoire vive et qu'il commence à transférer des données stockées en mémoire sur le disque dur), alors, il se fait déplacer sur un autre n ud disposant de plus de mémoire disponible même si alors, l'équilibre de la grappe s'en trouve faussé [10]. Dans le cas de la migration de processus, lorsqu'un processus est déplacé d'un n ud à un autre, toutes les communications qui sont établies avec ce processus passent par le n ud d'origine pour être redirigées vers le nouveau n ud. Cela crée un coût qui baisse les performances Kerrighed Kerrighed est un système d'exploitation à image unique qui cherche à orir performance, haute disponibilité et simplicité d'utilisation [31]. Kerrighed propose un ordonnancement global [46] constitué d'un contrôleur, d'analyseurs locaux et de sondes qui obtiennent l'état des n uds. Les sondes envoient des mesures par exemple de la température du processeur, de la charge du processeur, de l'occupation de la mémoire. Une sonde envoie ces informations à un analyseur local. L'analyseur local reçoit les informations des sondes. Un analyseur local peut être lié à une ou plusieurs sondes. Si un problème est détecté, l'analyseur local envoie une requête au contrôleur. Ce

23 1.4. ORDONNANCEMENT DE TÂCHES COMMUNICANTES 15 dernier reçoit les informations de tous les analyseurs locaux et possède ainsi une vision globale des ressources du n ud. Un contrôleur est implémenté sur chaque n ud. Ils peuvent communiquer entre-eux, et c'est cela qui forme l'ordonnanceur global. Lorsqu'un contrôleur détecte un problème d'équilibrage de charge par exemple, alors, en accord avec la politique en cours, il peut décider de déplacer un processus vers un autre n ud. Dans l'état actuel du développement de Kerrighed les processus ne sont déplacés qu'en cas de répartition non homogène de la charge des processeurs. De plus, il est possible de changer à chaud de politique d'ordonnancement. Enn, dans le cas de la migration de processus, un processus devient complètement indépendant de son n ud d'origine. 1.4 Ordonnancement de tâches communicantes Soit deux processus A et B s'exécutant sur deux processeurs distincts. Alors, il est possible que l'un d'entre eux (supposons A) se mettent en attente de réception d'un message alors que l'autre (B) n'est pas exécuté et n'a donc pas envoyé son message. Ainsi, le processus A perd du temps (il attend un message qui n'arrivera pas) et fait perdre du temps aux autres processus présents en le d'attente. Pour y remédier Ousterhout a proposé que des processus qui communiquent soient exécutés sur des processeurs distincts simultanément [33]. Cette technique (Gang-Scheduling) revient à faire comme si on exécutait une tâche parallèle sur une grappe dont elle serait la seule bénéciaire (ce qui est le cas idéal, mais est très rarement réalisable en pratique) Le Gang-Scheduling Le Gang-Scheduling consiste à exécuter tous les processus d'une même tâche simultanément sur l'ensemble des processeurs [20]. Cela implique donc, un changement de contexte simultané sur chacun d'entre eux 4. Une méthode pour implémenter ce changement de contexte sur l'ensemble des processeurs de la grappe est décrite dans [26]. Elle est fondé sur un échange de messages entre tous les processeurs pour rester synchronisé. On peut représenter cela par un tableau dont chaque ligne serait une tranche de temps, et chaque colonne serait un processeur. Le tableau est rempli de telle manière que sur une ligne, l'ensemble des processus d'une même tâche est exécuté. À chaque tranche de temps, l'ensemble des processeurs passe à la ligne suivante du tableau. Si pour une certaine tranche de temps, un processeur n'est pas attribué à un processus spécique, alors, soit il ne fait rien, soit il exécute un processus indépendant de l'application en cours d'exécution sur les autres processeurs. La gure 1.6 représente le tableau décrit précédemment. T1, T2 et T3 sont trois tâches diérentes et indépendantes. Un problème de cette technique, est qu'à chaque tranche de temps, il est nécessaire d'eectuer un changement de contexte sur l'ensemble des processeurs simultanément. Cette opération est très coûteuse. Cependant elle est nécessaire car sinon, beaucoup de temps est perdu [8]. La technique du Gang-Scheduling est fondée sur les relations qui existent entre les processus. Or comme cette technique attribue une tâche à la fois sur l'ensemble de la grappe, il est alors facile de savoir quelles sont les relations entre les diérents processus 4 Il est important de bien faire la diérence entre le changement de contexte dû à l'ordonnanceur temporel lié au système d'exploitation qui alloue des tranches de temps (time slice) aux processus et le changement de contexte du Gang-Scheduling qui alloue des tranches de temps aux tâches. Les tranches de temps de temps de l'ordonnanceur local sont plus petites que celles du Gang-Scheduling. Le contexte permet au lecteur de savoir lequel des deux est mentioné.

24 16 CHAPITRE 1. ÉTAT DE L'ART Fig. 1.6 Gang-Scheduling. Fig. 1.7 Co-Scheduling. [41]. Cependant cette technique pose comme inconvénient de sous-exploiter les ressources de la grappe (cela est bien mis en évidence sur la gure). Pour y remédier, il existe une autre technique qui permet d'exécuter plusieurs sousensembles d'une application ou plusieurs applications sur la même grappe. Pour ce faire, il faut donc que les processus puissent être capables eux-mêmes de signaler à l'ordonnanceur avec quels autres processus ils sont en relation. Une autre méthode consiste à laisser au système le soin de déterminer les dépendances entre les diérents processus an de les ordonnancer en même temps. Cette technique est appelée Co-Scheduling Le Co-Scheduling Le Co-Scheduling cherche à établir une relation de dépendance entre les diérents processus. Généralement, cette relation est fondée sur le taux de communications entreeux [40, 21]. De ce fait, la politique de Co-Scheduling est plus souple que celle de Gang-Scheduling. Elle permet à un sous-ensemble de processus d'une application de s'exécuter pendant qu'une autre partie de la grappe traite l'exécution d'autres applications. Grâce à cette technique le taux d'utilisation des ressources de la grappe se voit amélioré. La gure 1.7 représente le tableau décrit précédemment avec la technique du Co- Scheduling. On considère que la tâche T1 a besoin de beaucoup de synchronisations et que les tâches T2 et T3 n'ont pas besoin de synchronisation. On remarque qu'avec le Co-

25 1.4. ORDONNANCEMENT DE TÂCHES COMMUNICANTES 17 Fig. 1.8 Loosely Co-Scheduling. Scheduling les tâches T2 et T3 utilisent des temps de processus non-utilisés ce qui implique une meilleure utilisation des ressources Le co-ordonnancement faiblement couplé (loosely coordinated Co- Scheduling) Cette technique d'ordonnancement (loosely coordinated Co-Scheduling) est un peu comme celle du Co-Scheduling, sauf qu'elle est plus ne dans la gestion des processus [41]. Elle permet au processeur de relacher (avant la n de sa tranche de temps) un processus pour en prendre un autre, si celui-ci se bloque en attente d'un message. Le but de cette technique est de réduire encore plus que dans les autres techniques les temps d'inactivité du processeur. D'après la gure 1.8 et en reprenant les exemples développés précédemment, si on considère que les processus P2, P5 et P7 de la tâche T1 ont un problème de synchronisation et attendent des messages qui n'arriveront pas durant la tranche de temps t1, alors ces processus se font préempter, et d'autres processus indépendants sont exécutés (ici un processus de la tâche T1, et deux de la tâche T2). Diérentes approches de co-ordonnancement faiblement couplé ont été proposées : le co-ordonnancement implicite (implicit Co-Scheduling), le co-ordonnancement dynamique (dynamic Co-Scheduling), co-ordonnancement à poussée périodique (Periodic Boost). Implicit Coscheduling : cette méthode est fondée sur le blocage en boucle (spinblocking) c'est à dire que le processeur attend l'arrivée d'un message ou une synchronisation pendant un certain temps. Passé ce délai, le processus relâche le processeur. Dynamic Coscheduling : cette méthode surveille l'état des processus locaux (lesquels sont en cours d'exécution ou viennent d'etre exécutés) et regarde les communications entrantes. Si un processus receveur d'un message n'est pas en cours d'exécution (et qu'on respecte les règles d'équité en l'ordonnançant), alors on l'ordonnance (cette approche est 20% plus performante que celle à co-ordonnancement implicite). Periodic Boost [32] : cette méthode augmente la priorité d'un processus qui a des messages non consommés qui lui sont destinés. Les processus ayant des messages à consommer voient leur priorité augmenter. Dans le cas contraire, si aucun processus n'a de messages à consommer, alors aucun d'eux ne voit sa priorité augmenter Le co-ordonnacement exible (Flexible Coscheduling) Le Flexible Coscheduling [22] permet de faire du Co-Scheduling en classant les processus en catégorie selon des critères de communication [37] :

26 18 CHAPITRE 1. ÉTAT DE L'ART les processus (Co-Scheduling : CS) ayant un fort besoin de synchronisation (besoin d'ordonnancement de groupe), les processus (Frustrated : F) qui ont un fort besoin de synchronisation mais qui pour cause de problème d'équilibrage de charge n'utilisent pas tout le temps qui leur est attribué. les processus (don't care : DC) n'ayant besoin que de très peu de synchronisation. C'est à la n de chaque tranche de temps que les processus sont classés dans ces diérentes catégories. S'ils ont eu peu de communication, alors, ils sont mis dans la catégorie DC. Sinon, l'ordonnanceur calcule la proportion de temps qu'a passé le processus à attendre des messages. Si cette proportion est faible, alors le processus est classé en CS, sinon en F. Les processus ayant un fort besoin de synchronisation (CS) sont exécutés de manière coordonnée (politique de Co-Scheduling sans préemption). Les processus (F) se font préempter pour laisser la place à d'autres processus. Enn, les processus disposant de très peu de synchronisation (DC) sont ordonnancés de manière indépendante sans contrainte particulière. 1.5 Bilan L'ordonnanceur assure la liaison entre les tâches et les ressources. Dans ce premier chapitre nous avons présenté diérents types d'ordonnancement existants. Dans le cas des grappes cet ordonnancement est complexe car chaque calculateur dispose de son propre système d'exploitation. Il existe deux grandes classes de politiques d'ordonnancement, celles du temps partagé et celles du partage d'espace. De plus l'ordonnancement se situe à deux niveaux : ordonnancement des tâches sur la grappe et ordonnancement des processus par le système d'exploitation sur un n ud. Diérentes techniques d'ordonnancement des tâches ont été développées, chacune répondant à des besoins particuliers (sans retard, priorité...). Dans le cadre de l'ordonnancement des processus d'une tâche sur grappe, nous avons vu qu'il pouvait y avoir des problèmes d'ecacité si l'ordonnancement des processus de cette tâche se fait de manière quelconque. Cela est dû au fait qu'il est plus ecace d'ordonnancer simultanément des processus communicants. Des techniques de Gang-Scheduling, de Co-Scheduling et des variantes ont été mises en place an de résoudre ces problèmes en augmentant considérablement le taux d'utilisation des ressources. Pour pouvoir faire un ordonnancement ecace, le système doit faire de l'équilibrage de charge entre les ressources et faire de la régulation de charge au cours du temps. Les systèmes à exécution par lots sont orientés vers un ordonnancement des tâches dans l'espace : ils sont capables d'écouler un ensemble de tâches au cours du temps et de manière distribuée sur un ensemble de ressources distribuées. Par contre, les systèmes à exécution par lots ne gèrent pas l'équilibrage de charge entre les n uds. Si par exemple l'utilisateur a spécié qu'il voulait déployer une tâche sur 5 n uds alors que un sixième n ud est disponible, le système à exécution par lots n'en tiendra pas compte même si, nalement, la tâche de l'utilisateur aurait pu être déployé sur 6 n uds. Les systèmes à image unique fournissent au minimum une vision globale des processus. Certains d'entre eux sont capables de fournir à l'utilisateur une virtualisation des ressources comme Kerrighed par exemple. Les systèmes à image unique sont plutôt orientés vers l'équilibrage de charge entre les n uds, en agissant sur les processus, et ne sont pas capables nativement d'écouler une charge de travail au cours du temps. Pour faire cela, il faut installer un système à exécution par lots sur le système à image unique ce qui fait perdre l'intérêt d'utiliser un système à image unique pour gérer sa grappe. Dans les chapitres suivants, nous présentons une infrastructure d'ordonnancement qui allie la régulation d'une charge de travail au cours du temps ainsi que l'équilibrage du taux d'utilisation des ressources au cours du temps. Cette infrastructure doit permettre un or-

27 1.5. BILAN 19 donnancement multi-critères, c'est-à-dire, être capable de gérer les tâches sur les ressources selon diérents critères comme celui de la mémoire disponible, de la charge des processeurs, de la bande passante du réseau utilisée. De plus, nous voulons une infrastructure générique qui ne soit pas contraint à un type d'action préréglé pour la gestion de ressources prédéterminées. Elle doit permettre à l'administrateur de la grappe de pouvoir dénir des politiques d'administration simples et ecaces. Enn, elle doit être recongurable dynamiquement, sans que le redémarrage du système d'exploitation soit nécessaire.

28 20 CHAPITRE 1. ÉTAT DE L'ART

29 Chapitre 2 Objectifs du stage Du fait de l'évolution technologique, le nombre de ressources processeurs, la quantité de mémoire ainsi que l'espace de stockage sont en constante augmentation dans les grappes de calculateurs. Dans le monde du calcul à haute performance, ces diérentes ressources sont utilisées de manière concurrente par les utilisateurs qui veulent obtenir des résultats sûrs et ceci, dans les délais les plus brefs. Cela implique une minimisation du temps entre la soumission de la tâche et son exécution ainsi qu'une exécution ecace de la dite tâche. Or, dans bien des cas, ces ressources sont sous-exploitées. Le but de ce travail de recherche est de concevoir un ordonnanceur global capable de placer, déplacer, démarrer et arrêter des processus sur grappe de PCs au cours du temps. L'exécution de ces diérentes actions doit se faire en liaison avec la politique globale d'ordonnacement de la grappe dénie par l'administrateur. Nous nous plaçons dans le cadre des grappes gérées par des systèmes à image unique qui donne à l'utilisateur de la grappe l'illusion de disposer d'une unique machine multiprocesseur. Cette machine virtuelle dispose d'un seul système d'exploitation réparti sur l'ensemble des n uds. L'utilisateur soumet ses tâches de manière interactive comme sur une station de travail. C'est au système de gérer dynamiquement l'équilibrage ainsi que de la régulation de charge entre les n uds. L'équilibrage de charge se fait par des déplacement de processus. La régulation de charge se fait en mettant en attente des tâches qui ne peuvent être exécutées immédiatement faute de ressources disponibles. 2.1 Présentation des problèmes à traiter Contexte Comme vu en partie nous disposons d'un ensemble de tâches et de ressources. L'ordonnanceur que nous réalisons doit placer les tâches sur les n uds selon la politique dénie par l'administrateur. Pour cela le système doit disposer de mécanismes permettant de mesurer la charge de ces diérentes ressources. Ce sont les valeurs mesurées qui sont utilisées comme paramètres pour le choix du placement des tâches. De plus, nous disposons d'un ensemble d'actions. Typiquement, Kerrighed, le système à image unique avec lequel nous travaillons (vu au paragraphe 1.3.6), fournit des actions comme : la migration de processus, la sauvegarde/restauration de points de reprise, la création de processus de manière diérée (fork_delay, la suspension/redémarrage des processus). Ces actions sont exécutées selon les diérents critères spéciés par l'administrateur dans sa politique globale d'ordonnancement. La politique globale d'ordonnancement est écrite par l'administrateur de la grappe. Elle sert à décrire comment les ressources doivent être utilisées selon le travail à eectuer. Nous voulons réaliser une infrastructure d'ordonnanceur global mettant en relation la 21

30 22 CHAPITRE 2. OBJECTIFS DU STAGE politique globale d'ordonnancement de l'administrateur, la charge des ressources, les tâches et les actions à prendre. Le paragraphe suivant présente des caractéristiques générales d'un ordonnanceur Caractéristiques d'un ordonnanceur Le contrôle d'admission est un mécanisme permettant d'ordonnancer des tâches de manière ecace dans une grappe. Il gère la charge de l'ensemble des ressources en écoulant une charge de travail au cours du temps. Ce contrôle d'adminission va de pair avec d'autres mécanismes permettant de suspendre/reprendre l'exécution d'une tâche. De plus, l'ordonnancement des tâches peut faire de l'équilibrage de charge entre les n uds. Ceci à pour but d'avoir une utilisation homogène des ressources. Enn, l'ordonnancement peut prendre en compte les applications parallèles avec les techniques de Gang-Scheduling/Co-Scheduling. Cependant, en imaginant même que nous disposons d'un ordonnanceur capable de traiter les trois points décrit ci-dessus, il n'existe pas de politiques d'ordonnancement universelles permettant de maximiser l'utilisation de toutes les ressources simultanément. Dans ces conditions, il est intéressant de pouvoir dénir des priorités entre les diérentes ressources an par exemple de privilégier la ressource mémoire libre par rapport à la ressource charge processeur. L'administrateur a besoin de congurer ses politiques dynamiquement et de manière simple, cela dans le but de tenir compte du contexte d'utilisation de la grappe. En eet, il pourrait être possible que l'administrateur dénisse une politique d'ordonnancement de jour, qui exécute principalement les tâches de courte durée, et une politique d'ordonnancement de nuit, qui exécute les longs calculs. 2.2 Objectifs Dans l'état actuel du développement des systèmes à image unique orant une virtualisation complète des processus et des ressources, il n'existe pas d'ordonnanceur intégré prenant en compte tous les critères énoncés dans le paragraphe précédent. En prenant par exemple le cas du système à image unique Kerrighed, des travaux concernant le contrôle d'admission des tâches ont déjà été eectués. Cela concerne la possibilité de créer des processus de manière diérée. De plus, il est possible de suspendre à tout moment ces processus pendant leur exécution pour les redémarrer ultérieurement. Ces mécanismes sont une première approche pour permettre une régulation de la charge du travail sur le système d'exploitation. (fork_delay [23]). Cependant, ce système est assez rigide. Il n'est pas possible de changer de politique d'ordonnancement dynamiquement. De plus, il est complétement lié au système d'exploitation, étant donné qu'il a été développé dans le noyau. Enn, il n'est pas générique car il a été conçu pour des actions prédéterminées et la régulation de la charge n'est eectué qu'en analysant la charge des processeurs. Il n'est donc pas possible actuellement de faire de la régulation de charge en fonction de la ressource mémoire, par exemple. De plus, d'autres travaux concernant l'équilibrage de la charge sur la ressource processeur ont déjà été eectués et implémentés dans Kerrighed [45]. Nous souhaitons étendre ces mécanismes et dénir un ordonnanceur global de tâches qui soit simple, générique et ecace et évolutif. Cet ordonnanceur se doit d'être dynamique et préemptif (voir le paragraphe pour plus d'informations). Enn, il doit pouvoir : réguler la charge globale de la grappe pour ne pas exécuter plus de travaux que la grappe n'est capable d'en traiter pendant une unité de temps,

31 2.3. APPROCHE 23 équilibrer la charge entre les n uds en prenant en compte les spécicités de la politique globale dénie par l'administrateur, être recongurable dynamiquement. 2.3 Approche Notre travail s'inscrit dans le contexte des systèmes à image unique, et plus particulièrement Kerrighed. Nous voulons concevoir un ordonnanceur pour grappe combinant la soumission interactive, la régulation globale de la charge et l'équilibrage de charge entre les n uds. La soumission interactive se fait en ayant l'avantage des systèmes à image unique, c'est-à-dire la simplicité pour l'utilisateur. Les tâches sont lancées par l'utilisateur dans un langage naturel via le shell, sans modication et recompilation de celles-ci. De plus, nous analysons l'aspect gestion globale de la charge par un contrôle d'admission, comme les systèmes à exécution par lots. Enn, nous étudions le mécanisme d'équilibrage de charge entre les n uds selon la politique dénie par l'administrateur Cette politique peut-être changée dynamiquement, ce qui implique une exibilité de l'ordonnanceur. 2.4 Contributions Dans la suite de ce document, nous concevons un ordonnanceur global capable de gérer des ressources selon diérentes priorités. Cet ordonnanceur peut réaliser de la régulation de charge de travail ainsi que de l'équilibrage de charge des ressources. De plus, nous donnons les éléments clés de la mise en uvre de notre ordonnanceur. Nous présentons également des exemples de politiques de l'état de l'art mises en uvre dans le cadre de notre ordonnanceur. Enn, nous présentons les évaluations de celui-ci an de valider notre prototype. Dans la suite de ce document, nous ne parlons plus de tâches, c'est-à-dire plusieurs processus coopérant entre-eux (vu en section 1.1.1), mais uniquement de processus. En eet, dans les systèmes de type Unix, il existe des objets qui sont manipulés par le système (processus, socket...) mais la notion de tâches n'existe pas. Nous avons donc conçu notre système pour la gestion des processus. Cependant, nous voyons en conclusion sur l'exemple du Gang-Scheduling une extension de notre modèle à la notion de tâches.

32 24 CHAPITRE 2. OBJECTIFS DU STAGE

33 Chapitre 3 Conception d'un ordonnanceur global congurable Nous voulons concevoir un système simple et générique et évolutif. L'ordonnanceur global est conçu de façon distribuée, chaque n ud exécutant une instance de l'ordonnanceur. De plus, nous avons opté pour que chaque instance de l'ordonnanceur soit modulaire, chaque module étant indépendant les uns des autres. Dans les paragraphes suivants nous décrivons les principes de conception de notre ordonnanceur. Tout d'abord, nous présentons son infrastructure, puis nous décrivons le modèle de priorité mis en place entre les diérentes ressources. Enn nous présentons les algorithmes que nous avons conçu an de mettre en relation les diérents modules. 3.1 Infrastructure Dans ce paragraphe, nous présentons l'infrastructure de l'ordonnanceur global (voir gure 3.1). La politique globale d'ordonnancement est décrite par l'administrateur de la grappe et est lue par l'ordonnanceur global an de l'appliquer. L'ordonnanceur global est constitué de deux agents. Un agent de surveillance, qui détecte les anomalies de ressources qui ne sont pas gérés comme la politique l'indique. Un agent d'actions, qui réalise des simulations d'action et exécute les actions. L'ordonnanceur global, par l'intermédiaire de son agent d'actions agit sur une collection de processus présent sur le système. Les processus inuent sur l'état des ressources. Enn, l'état des ressources est contrôlé par l'agent de surveillance de l'ordonnanceur global. Cette infrastructure permet à l'administrateur d'écrire de grandes variétés de politiques globales d'ordonnancement et cela de manière simple comme nous le voyons dans les paragraphes suivants. De plus, elle ore une souplesse à la conguration. Le changement de politique peut se faire simplement sans nécessiter de recompiler l'infrastructure. Enn, l'administrateur peut écrire des politiques capables d'équilibrer la charge entre les n uds et de réguler la charge globale de la grappe au cours du temps. Cependant, ces politiques doivent être écrites en fonction des actions permises par le système. Notre travail repose sur Kerrighed qui ore un mécanisme permettant d'eectuer de l'équilibrage de charge avec la migration de processus ainsi que des mécanismes permettant la régulation de la charge avec arrêt/suspension/redémarrage de processus. 3.2 La politique globale d'ordonnancement La gure 3.2 montre une politique globale d'ordonnancement. Elle est dénie par une succession de politiques élémentaires constituées de règles. La politique globale d'ordon- 25

34 26CHAPITRE 3. CONCEPTION D'UN ORDONNANCEUR GLOBAL CONFIGURABLE Fig. 3.1 Présentation schématique de l'ordonnanceur global. Fig. 3.2 Description de la politique globale d'ordonnancement qui est constitué de politiques élémentaires de priorités diérentes elles-mêmes constituées de règles. nancement est dénie pour la grappe entière. Chaque politique élémentaire concerne une ressource du n ud (par exemple, la mémoire, la charge des processeurs...). Ainsi, nous devons disposer d'autant de politiques élémentaires que de ressources que l'on veut surveiller. Les politiques élémentaires sont décrites par l'administrateur pour une grappe sous forme de règles. Une règle est décrite par une condition et une action. Si la condition est vériée, l'action est réalisée. La condition peut être une comparaison entre une valeur seuil spéciée dans la règle et une mesure d'une valeur physique retournée par le système. L'action peut être, dans le cas d'un équilibrage de charge, une migration de processus, ou bien, dans le cas d'une régulation de charge, un arrêt/redémarrage de processus. Il est possible d'imaginer d'autres types d'actions comme éteindre_n uds. Une grappe est constituée de diérentes ressources. Comme nous l'avons dit au début de ce paragraphe, une ressource est gérée par une politique élémentaire et naturellement, plusieurs ressources sont gérées par plusieurs politiques élémentaires. Or, au sein d'une grappe, il n'est pas possible de maximiser les critères d'utilisation de toutes les ressources simultanément. Pour y remédier, nous instaurons la notion de priorité entre les diérentes ressources, et donc entre les diérentes politiques élémentaires. Ainsi, s'il n'est pas possible de maximiser simultanément l'utilisation des ressources A et B, alors, l'ordonnanceur va

35 3.3. LES COLLECTIONS 27 d'abord maximiser l'utilisation de la ressource de plus forte priorité puis essayera dans la mesure du possible de maximiser l'utilisation de l'autre ressource à condition que cela ne perturbe pas la ressource de plus forte priotité. 3.3 Les collections La collection de ressources Une collection de ressources contient un ensemble de ressources qui sont des réprésentations logicelles des ressources physiques de la grappe. Dans la suite de ce document, nous appelerons ressource, aussi bien, une ressource physique liée à la grappe, qu'une représentation logicielle d'une ressource, cela dans le but de clarier le discours. Une ressource de la collection est une unité physique, comme la mémoire libre, ou logique, comme le nombre d'utilisateurs connectés, que l'administrateur cherche à contrôler. Une ressource est caractérisée par : une information système, par exemple, la mémoire disponible ou le nombre d'utilisateurs connectés, une information d'un objet du système qui utilise la ressource considérée, par exemple, la taille que prend un processus en mémoire, la connexion sur un terminal d'un utilisateur, une information de simulation qui indique si une action peut être réalisée ou non par rapport à la ressource considérée. Par exemple, est-ce que le processus P qui occupe x Mo en mémoire sur le n ud A peut être exécuté sur le n ud B disposant de y Mo de mémoire libre?, est-ce que le système peut accepter une nouvelle connexion de la part d'un utilisateur? La collection de processus Cette collection est la liste de tous les processus présents sur le système. Ces processus peuvent se trouver dans un état quelconque. Par exemple, ils peuvent être en cours d'exécution ou en attente d'une entrée/sortie. 3.4 Agent de surveillance L'agent de surveillance contrôle l'état des ressources de la grappe et interagit avec l'agent d'actions an de réaliser des actions. L'agent de surveillance est constitué d'un détecteur d'anomalie qui contrôle en continu que chaque ressource de la collection de ressources vérie bien les règles spéciées dans la politique globale d'ordonnancement. En cas de détection d'anomalie, le détecteur de ressources libres ainsi que le détecteur de processus pouvant résoudre le problème sont activés. Le détecteur de ressources libres fait une recherche dans la collection de ressources an de trouver des ressources disponibles. Le détecteur de processus fait une recherche dans la collection de processus an de trouver des processus pouvant résoudre le problème Surveillance des conditions d'utilisation des ressources Le détecteur d'anomalie surveille les conditions d'utilisation des ressources. Il vérie que toutes les règles de toutes les politiques élémentaires sont respectées. En cas de problème, il informe le détecteur de ressources libres ainsi que le détecteur de processus.

36 28CHAPITRE 3. CONCEPTION D'UN ORDONNANCEUR GLOBAL CONFIGURABLE Recherche d'actions correctrices Lorsqu'un problème est détecté, l'ordonnanceur recherche des ressources disponibles ainsi que des processus sur lesquels agir. Cette recherche se fait en fonction de l'action à exécuter. Puis, l'agent de surveillance ltre et trie les ressources découvertes. Le ltre permet de sélectionner les ressources sur un critère indépendant de l'action. Le tri permet de ranger les ressources découvertes selon un ordre d'intérêt. Les processus découverts sont également ltrés et triés. Nous revenons plus en détail sur les fonctions de ltre et de tri dans les deux paragraphes suivants. La recherche des ressources disponibles ainsi que celle des processus sur lesquels agir dépendent de l'action à réaliser. À l'inverse, l'application du ltre ainsi que le tri des ressources/processus découverts ne dépendent pas de l'action à réaliser. Détecteur de ressources libres Le module de détection des ressources libres crée une liste de n uds en fonction de la disponibilité de leurs ressources pour pouvoir exécuter une action résolvant le problème. Les actions sont spéciées dans les règles dénies par l'administrateur. Cette recherche se fait en relation avec l'action que l'on veut exécuter : par exemple, si l'on cherche à faire une sauvegarde de point de reprise sur disque, les n uds sélectionnés sont uniquement ceux disposant d'un disque dur. De plus, nous dénissons un ltre sur l'ensemble des ressources que l'on vient d'obtenir, appellé ltre des n uds. Ce ltre permet de sélectionner les n uds sur des critères qui ne dépendent pas de l'action : par exemple, si nous voulons faire une migration sur des n uds qui ont au minimum 2Go de mémoire vive, nous le spécions dans ce ltre. En eet, le fait d'avoir 2Go de mémoire vive ne dépend pas de l'action de migration. Enn, les n uds sont triés selon un ordre déni par la politique de l'administrateur. L'exemple le plus simple est de classer ces n uds par ordre décroissant d'intérêt. Ainsi, le n ud le plus intéressant se trouve en début de liste. Cependant, pour une utilisation plus ne, l'administrateur pourrait écrire sa propre fonction de tri qui classerait, par exemple, en tête de liste les n uds les plus récents de la grappe et en n de liste les autres n uds. Détecteur de processus pouvant débloquer une situation Le détecteur de processus fournit une liste de processus pouvant débloquer la situation pour le problème détecté par rapport à l'action demandée. La recherche des processus se fait selon l'action à réaliser dans la collection de processus présente sur le système au moment de la recherche. Par exemple, si l'action est une migration de processus, alors le processus doit posséder la capacité de migration. Une capacité est un attribut donné à un processus qui permet de diérencier des processus selon certains critères. Par exemple, il est possible de diérencier les processus qui peuvent être déplacés sur un autre n ud, et ceux qui ne le peuvent pas grâce à sa capacité. Ensuite, comme pour le détecteur de ressources, un ltre nommé ltre des processus, sélectionne les processus selon des critères d'ordre général ne dépendant pas de l'action à réaliser. Par exemple, le ltre des processus peut sélectionner tous les processus du groupe d'utilisateur STAFF). Enn les processus sont triés selon leur pourcentage d'occupation sur la ressource considérée. Par défaut les processus sont triés par ordre décroissant, par exemple, du plus gros au plus petit processus consommant de la mémoire.

37 3.5. AGENT D'ACTIONS Agent d'actions Lorsque les ressources et les processus sont trouvés, alors l'agent d'actions intervient. Son rôle est de réaliser une simulation de l'action à eectuer et à réaliser l'action en cas de simulation positive. Cependant, il est possible d'avoir des actions ne nécessitant pas simulation, par exemple, stopper_processus_en_mémoire. Lorsque l'ordonnanceur décide d'exécuter une action, soit cette action nécessite une simulation, soit elle peut-être exécutée directement. Dans le cas d'une action nécessitant une simulation, le simulateur récupère une liste de n uds provenant du détecteur de ressources ainsi qu'une liste de processus provenant du détecteur de processus. À partir de ces listes, le simulateur réalise des simulation entre les n uds et les processus. En cas de simulation réussie le n ud ainsi que l'identiant du processus sélectionnés par le simulateur sont envoyés au module d'action qui réalise l'action. Dans le cas d'une action ne nécessitant pas de simulation, le premier n ud ainsi que le premier processus des listes retournées par le détecteur de n uds et le détecteur de processus sont envoyés directement au module d'action. Les paragraphes suivants détaillent successivement le module de simulation, qui correspond uniquement aux actions nécessitant une simulation, et le module d'action, qui correspond à toutes les actions Action nécessitant une simulation La réalisation d'une simulation avant d'eectuer une action a pour but de mesurer les eets d'une action a priori cela dans le but d'éviter la réalisation d'action indésirable comme la surcharge d'un n ud ou l'eet ping-pong. Eet ping-pong L'eet ping-pong est une forme d'instabilité du système. D'une manière générale, il y a un eet ping-pong, lorsque, en étant dans un état E 0 une décision est prise pour réaliser une action. On arrive dans un état E 1 avec l'action réalisée. Le résultat de cette action entraine de nouveau une prise de décision pour réaliser l'action inverse à celle qui vient d'être faite et ramène en l'état en E 0 et ainsi de suite. Chaque centre de décision étant indépendant des autres centres de décision, il est possible que des centres de décision fassent des choix d'action contradictoires. Un exemple simple est celui d'une grappe constituée de deux n uds homogènes. On considère que les deux n uds (A et B) sont chargés en mémoire à 50%. On écrit une politique élémentaire qui déplace le plus gros processus lorsque le n ud dépasse 60% de mémoire occupée. On exécute un processus qui fait passer la charge mémoire du n ud A de 50% à 80% d'utilisation. Si l'on n'introduit pas de mécanismes complémentaires, l'ordonnanceur va déplacer le processus mis en cause sur le n ud B et celui-ci va également passer de 50% à 80% de mémoire occupée. Il va donc chercher à déplacer ce processus vers son n ud d'origine A et ainsi de suite. Pour remédier à ce problème nous avons mis en place un mécanisme de simulation. Avant de réaliser l'action de migration, le centre de décision du n ud A s'assure en intéragissant avec celui du n ud B qu'en déplaçant le processus mis en cause, celui-ci ne va pas perturber la politique élémentaire en cours d'exécution sur le n ud B. Dans le cas où la simulation indique qu'après la migration, l'état du n ud de destination veriera plus sa politique élémentaire, l'action n'a pas lieu.

38 30CHAPITRE 3. CONCEPTION D'UN ORDONNANCEUR GLOBAL CONFIGURABLE Principe de la simulation La simulation est réalisée par rapport à la ressource. La simulation reçoit une liste de n uds du détecteur de ressources disponibles ainsi qu'une liste de processus du détecteur de processus. Elle prend le premier n ud de la liste ainsi que le premier processus et évalue l'incidence de l'action. Si le résultat est satisfaisant, alors l'action est réalisée. Dans le cas contraire, la simulation prend le second n ud de la liste, en gardant toujours l'identiant du premier processus sélectionné et continue ainsi pour tous les n uds de la liste. Lorsqu'il n'y a plus de n uds dans la liste, le simulateur revient en début de liste des n uds et passe au second processus de la liste et ainsi de suite (voir algorithme 1). Algorithme 1 : Algorithme des essais successifs de simulation. pour tous les processus de la liste faire pour tous les n uds de la liste faire simulation(n ud, processus); n n La simulation est réalisée sur le n ud qui reçoit les résultats de l'action. Par exemple, lors d'une migration de processus, la simulation est eectuée sur le n ud distant, alors que lors d'un réveil local de processus, la simulation est eectuée sur le n ud local. Prévention d'actions concurrentes En cas de simulation réussie, le n ud doit interdire toute nouvelle action tant que l'action liée à la simulation réussie n'est pas eectuée. Ceci a pour but d'éviter des phénomènes de surcharge. En eet, imaginons que nous disposions de trois n uds A, B et C. Les n uds A et B ont des processus en attente. Le n ud C se libère. Alors, les n uds A et B vont simultanément vouloir transmettre certains de leurs processus au n ud C. Le n ud C va alors se trouver surchargé et il devra stopper des processus. En bloquant la réalisation de nouvelles actions tant que l'action liée à la simulation n'est pas faite, alors il n'est plus possible que A et B décident simultanément de transmettre un de leur processus à C. En eet, si A réalise une simulation sur C et que le résultat de cette simulation est positif, alors B ne pourra pas faire de simulation sur C tant que A n'aura pas terminé son action, ce qui évite que B fasse une migration de processus inutile. Action ne nécessitant pas de simulation Enn, certaines actions ne nécessitent pas la réalisation de simulation. Dans ce cas, il est possible d'exécuter directement l'action. Par exemple, il n'est pas nécessaire de réaliser une simulation sur la charge processeur pour l'action suspendre un processus. En eet, le fait de suspendre ce processus va libérer la ressource processeur, la simulation est donc inutile Réalisation de l'action Le module de réalisation des actions eectue l'action soit directement s'il n'y a pas eu de simulation, soit après la simulation si elle donne un résultat positif. Nous avons déjà vu dans les paragraphes précédents diérents types d'actions que nous pourrions utiliser. 3.6 Modèle de priorité Dans un système composé de multiples ressources, il n'est pas possible de maximiser l'utilisation de chacune d'elles simultanément.

39 3.6. MODÈLE DE PRIORITÉ 31 Fig. 3.3 Autre exemple d'arbre de priorité Exemple introductif. Nous utilisons cet exemple comme celui de référence pour les parties suivantes. Prenons un cas simple : nous voulons décrire une politique qui minimise l'utilisation de la partition d'échange (SWAP) et équilibre au mieux la charge des processeurs. Nous dénissons deux politiques élémentaires : une concernant la gestion de la mémoire de priorité maximum, priorité = 1, et une autre concernant la gestion de la charge processeur, priorité = 2. La gure 3.3 représente l'arbre de priorité de l'exemple considéré. An de ne pas compliquer inutilement cet exemple introductif, nous considérons une grappe homogène de machines monoprocesseurs. Ainsi, l'équilibrage de charge entre les processeurs, revient à faire de l'équilibrage de charge entre les n uds, mais le principe serait le même avec des machines multiprocesseur. Tout d'abord le centre de décision traite la politique élémentaire de priorité 1. Si la partition d'échange du n ud est utilisée, le centre de décision désactive l'application des politiques de priorité inférieure à celle de la politique 1 et essaye de stopper des processus. Lorsqu'une politique élémentaire est désactivée, cela signie qu'elle arrête de surveiller la ressource concernée en attendant qu'elle soit de nouveau réactivée. Si la partition d'échange du n ud n'est pas utilisée, la condition de la politique élémentaire numéro 2 est testée, pour savoir si la charge entre les processeurs est bien équilibrée. Si elle l'est, le système essaye de réveiller des processus en liste d'attente. Le réveil des processus est soumis à une simulation, ainsi, un réveil ne pourra être eectué que si il n'y a pas de risque de déséquilibrer les politiques élementaires numéro 1 et 2. Si elle ne l'est pas, le système essaye, au contraire, d'en stopper Extension. L'arbre décrit dans l'exemple précédent impose que chaque politique ne dispose que d'une condition et d'une action par condition, par exemple, est-ce que la mémoire occupée est supérieure à 50% de la mémoire totale, si oui, alors faire l'action stopper_un_processus.

40 32CHAPITRE 3. CONCEPTION D'UN ORDONNANCEUR GLOBAL CONFIGURABLE Fig. 3.4 Autre exemple d'arbre de priorité avec plusieurs conditions. Cependant, dans certains cas, nous voudrions disposer de plusieurs conditions pour pouvoir eectuer diérentes actions (par exemple, si la mémoire occupée est supérieure à 50%, alors faire l'action migrer_processus, si la mémoire occupée est supérieure à 80%, alors faire l'action stopper_processus). Nous étendons la condition liée à une politique élémentaire à un ensemble de conditions comme le montre la gure 3.4 qui est munie d'un cas par défaut Bilan. Le modèle de priorité que nous avons déni permet de mettre une relation d'ordre entre les politiques élémentaires. Ainsi, tant qu'une ressource de forte priorité n'a pas sa politique élémentaire qui est vérifée, alors les ressources de priorités inférieures sont désactivées. De plus, lors de la réalisation d'une action nécessitant une simulation, celle-ci doit pour la politique élémentaire voulant réaliser l'action, mais également, pour toutes les politiques élémentaires de priorité supérieures. Ainsi, une action ne peut être eectuée que si elle ne perturbe pas les politiques élémentaires de priorité supérieure. 3.7 Présentation des algorithmes conçus Dans cette partie nous décrivons les diérents algorithmes que nous avons conçus an de créer notre ordonnanceur global. Les algorithmes sont décrits selon des niveaux de détail diérents. Nous présentons d'abord les algorithmes avec un faible niveau de détail et nous les approfondissons au fur et à mesure Initialisation des centres de décision Cette partie présente l'initialisation de l'ordonnanceur global (voir l'algorithme 2). Le démarrage de l'ordonnanceur global entraîne le démarrage de la surveillance des diérentes

41 3.7. PRÉSENTATION DES ALGORITHMES CONÇUS 33 politiques élémentaires. Algorithme 2 : Initialisation des centres de décision. 1. Lecture de la politique globale. 2. Création des diérents modules de priorité (chacune gérant une politique élémentaire). 3. Démarrage de l'ordonnanceur global sur tous les noeuds Fonctionnement des centres de décision pour une politique élémentaire Version simple de l'algorithme Lors de la détection d'un problème sur la grappe, l'ordonnanceur recherche des n uds disponibles ainsi que des processus pouvant remédier au problème. Une fois cela fait, le centre de décision réalise une simulation de l'action (par rapport au processus et au n ud trouvés). Si le résultat de la simulation est positif, l'action est réalisée. L'algorithme 3 présente l'algorithme de surveillance d'une politique élémentaire. Algorithme 3 : Algorithme général pour l'application d'une politique élémentaire pour toujours faire 1. Détection d'un problème pour une politique élémentaire considérée. 2. Recherche d'une liste de noeuds disponibles (ltrer, trier). 3. Recherche d'une liste de processus disponibles (ltrer, trier). 4. Simulation de l'exécution de l'action du processus trouvé sur le noeud trouvé (si la simulation est nécessaire). 5. Exécution de l'action en cas de simulation favorable, sinon, passer au noeud suivant ou au processus suivant ou à l'action suivante. n En continu, le centre de décision vérie s'il y a un problème pour la politique élémentaire considérée. Lorsqu'un problème est détecté, le centre de décision recherche une liste de n uds disponible pour l'action considérée. Puis cette liste est ltrée et triée selon la politique élémentaire. Le centre de décision recherche également une liste de processus pour l'action considérée. Cette liste est également ltrée et triée selon la politique élémentaire. Ensuite, le centre de décision réalise une simulation en réalisant des combinaisons entre les n uds trouvés et les processus trouvés (voir algorithme 1). Si aucune combinaison n'est possible, alors l'algorithme passe à l'action suivante de la politique élémentaire. Et, dans le cas ou il n'y a plus d'action à faire, alors c'est que le problème ne peut être résolu dans l'immédiat il faudra attendre le changement d'état des ressources, par exemple par la n de l'exécution d'un processus, pour remédier au problème.

42 34CHAPITRE 3. CONCEPTION D'UN ORDONNANCEUR GLOBAL CONFIGURABLE Version détaillée de l'algorithme L'algorithme 4 détaille celui du paragraphe précédent (voir l'algorithme 3). Algorithme 4 : Algorithme détaillé pour l'application d'une politique élémentaire 1 Détection d'un problème dans la grappe. 2 si pas de problème alors 3 retourner en 1. 4 sinon 5 Récupérer une liste de n uds susceptibles de résoudre le problème selon l'action dénie par la règle de la politique élémentaire considérée. 6 Filtrer cette liste de n uds. 7 Trier cette liste de n uds. 8 Récupérer une liste de processus susceptibles de résoudre le problème selon l'action dénie par la règle de la politique élémentaire considérée. 9 Filtrer cette liste de processus. 10 Trier cette liste de processus. 11 Prendre le premier n ud de la liste. 12 Prendre le premier processus de la liste. 13 Réaliser une simulation d'action : simulation(n ud, processus). 14 si simulation OK alors 15 réalisation de l'action. 16 sinon 17 sélectionner le prochain n ud de la liste. 18 si tous les n uds de la liste ont été testés alors 19 reprendre le premier n ud de la liste. 20 prendre le prochain processus de la liste. 21 si tous les processus de la liste ont été testés alors /* un problème est détecté sur la grappe, mais aucune combinaison de n uds et de processus ne peut résoudre le problème */ 22 retourner en sinon 24 retourner en n 26 sinon 27 retourner en n 29 n 30 n Notons que le groupe d'actions 5, 6 et 7 ainsi que 8, 9, 10, peut être réalisé en parallèle. De plus 6 (respectivement 7) sont des opérations de ltrage sur les n uds (respectivement sur les processus) indépendant de l'action. La partie de l'algorithme allant de la ligne 14 à 28 est le même algorithme, en plus détaillé, que celui présenté avec l'algorithme 1, c'està-dire qu'il essaye les meilleurs combinaisons possible pour une action donnée entre les n uds et les processus.

43 Chapitre 4 Application de notre approche à quelques politiques de l'état de l'art Dans cette partie, nous reprenons des politiques présentées dans le chapitre 1 et nous décrivons ce qu'il faudrait mettre en uvre pour les appliquer à notre système. Dans un premier temps, nous décrivons une politique de démarrage de tâches avec priorité, cela nous permettra d'analyser la gestion de les d'attente de processus. Puis, nous présentons une politique d'économie d'énergie qui montre une gestion d'actions pouvant opérer sur d'autres objets que des processus. Enn, nous discutons d'une politique de gestion dynamique d'applications parallèles à mémoire partagée. Nous pourrons étudier une gestion d'applications utilisant pleinement la mémoire partagée des systèmes à image unique. 4.1 Démarrage des tâches avec priorité Cet exemple a pour but de montrer qu'il est possible de gérer des les d'attentes de processus comportant une priorité avec notre système. Considérons l'exemple suivant : l'administrateur de la grappe veut attribuer des priorités aux processus des utilisateurs selon les groupes auxquels ils appartiennent (par exemple, les processus du groupe ADMIN ont une priorité plus forte que ceux du groupe TEST). Lorsqu'un processus est créé, son numéro de priorité est initialisé Politique L'objectif de cette politique est de faire de la régulation de charge avec une admission des tâches dans le système par ordre de priorité. De plus, un équilibrage de charge est réalisé entre les processeurs. Le démarrage des tâches avec priorité met en uvre plusieurs les d'attente de processus. Chaque le d'attente dispose d'une certaine priorité. Cette politique entraîne un risque de famine, c'est-à-dire qu'un processus reste dans une le d'attente indéniment parce que d'utres processus de priorité supérieur arrive devant lui dans les autres les de priorité supérieur. Pour y remédier, au cours du temps, la priorité des processus augmente. Ainsi, un processus qui se trouve dans la le de plus faible priorité ne pourra y rester éternellement même si des processus de plus forte priorité arrivent dans les les de priorité plus élevée Écriture de la politique Pour écrire une telle politique, nous devons créer deux politiques élémentaires. La première gère une ressource logique temps. La seconde consiste à équilibrer la charge entre les processeurs. 35

44 36 CHAPITRE 4. APPLICATION DE NOTRE APPROCHE Gestion du temps Cette politique de priorité maximum gère une ressource logique temps qui permet périodiquement d'augmenter la priorité des processus pour éviter les risques de famine. La ressource temps surveillée par cette politique élémentaire possède une date de dernière mise à jour des priorités. Ainsi, lorsque le temps maximum spécié dans la politique élémentaire entre deux mises à jour est dépassé, alors une nouvelle mise à jour est faite. La ressource temps qui est dénie par : le temps restant avant la prochaine mise à jour des priorités, la priorité d'un processus considéré, Actions. Nous utilisons une action mise_à_jour_priorité qui, comme son nom l'indique, permet de mettre à jour la priorité des processus. À chaque appel de cette action, la mise à jour des priorités de tous les processus en le d'attente est eectuée. Cette action est dénie par : un ensemble des n uds éligibles, c'est-à-dire, l'ensemble des n uds de la grappe (le réveil des processus peut être eectué sur le n ud local, ou sur un n ud distant), un ensemble des processus éligibles, c'est-à-dire, l'ensemble des processus dans les diérentes les d'attente, Fonction de simulation. Cette ressource logique ne nécessite pas de fonction de simulation. Lorsque le temps imparti est écoulé, la mise à jour des priorités doit être faite dans tous les cas. Équilibrage de la charge entre les processeurs Cette politique gère une ressource physique qui est l'équilibrage de la charge entre les processeurs. Pour cette politique nous dénissons arbitrairement que la charge entre les processeurs est équilibrée si chaque processeur exécute au plus 1 processus an de réserver un processus d'une tâche par processeur. La ressource équilibrage de charge entre les processeurs est dénie par : la charge d'un processeur considéré, le taux d'utilisation d'un processeur par un processus considéré. Actions. Nous dénissons deux actions qui sont le réveil et le déplacement des processus. Réveil des processus. Dans le cas ou l'équilibrage de charge entre les processeurs est correct, le système essaye de réveiller de nouveaux processus. Cette action est dénie par : un ensemble des n uds éligibles, c'est-à-dire, le n ud local, un ensemble des processus éligibles, c'est-à-dire, l'ensemble des processus en attente de réveil. Déplacement des processus. Le déplacement des processus permet d'équilibrer la charge de la grappe en continu. Cette action est dénie par : un ensemble des n uds éligibles, c'est-à-dire, l'ensemble des n uds de la grappe, un ensemble des processus éligibles, c'est-à-dire, l'ensemble des processus du n ud voulant exécuter l'action, Fonction de simulation. La fonction de simulation associée à cette ressource physique est : si l'on ajoute un processus sur ce processeur, est-ce que la charge de la grappe est toujours homogène à un maximum de 1 processus en cours d'exécution par n uds?.

45 4.1. DÉMARRAGE DES TÂCHES AVEC PRIORITÉ 37 Fig. 4.1 Exemple d'arbre de priorité pour la gestion du démarrage de tâches avec priorité. Arbre de priorité La gure 4.1 nous montre l'arbre des priorités. Lorsque la ressource temps indique que le temps est écoulé depuis la dernière mise à jour des priorités, alors, elle déclenche l'action mise_à_jour_priorité. La ressource charge processeur équilibré s'assure que la charge entre les processeurs de la grappe est équilibrée. Si c'est le cas, elle essaye de réveiller un processus, sinon, elle essaye d'en déplacer. Filtre sur les processus Ce paragraphe présente comment gérer des les de processus avec priorité en mode FIFO (First In, First Out) avec notre système. Comme nous l'avons vu dans le paragraphe précédent, l'action réveiller_un_processus retourne l'ensemble des processus disponibles sur le n ud pouvant être réveillé. Cette liste est composée de processus ayant diérentes priorités et avec diérentes heures d'entrée dans la le. C'est le ltre des processus qui sélectionne le processus devant être sorti de la le pour que la le soit eectivement gérée en mode FIFO (voir la gure 4.2). Pour ce faire, à partir de la liste des processus obtenue par l'action réveiller_un_processus, le ltre fait une recherche pour sélectionner le processus le plus ancien dans la liste avec la plus forte priorité. Bien entendu, il faut également tenir à jour une table des processus qui indique depuis combien de temps un processus est dans une le donnée. Cependant, nous n'irons pas plus loin dans l'explication de cette table qui contient les informations relatives à la priorité ainsi que l'heure d'arrivée du processus dans la le, car cela relève plus de la mise en uvre que d'un problème de conception.

46 38 CHAPITRE 4. APPLICATION DE NOTRE APPROCHE 4.2 Économie d'énergie Fig. 4.2 Gestion de la le en mode FIFO. Cet exemple montre que nous pouvons dénir des actions n'intervenant pas sur des processus. La consommation électrique des équipements informatiques devient un véritable enjeu économique d'autant plus que la taille des grappes à tendance à augmenter. Pour y remédier, certains algorithmes (comme l'algorithme LC - Load Concentration vu en 1.2.2) tentent de charger au maximum certain n uds de la grappe an de pouvoir permettre aux autres de fonctionner en mode basse consommation Politique L'objectif de cette politique est d'adapter le nombre de n uds actifs à la charge globale courante de la grappe. Cette politique agit en déplaçant des processus et en allumant et éteignant des n uds. La priorité est donnée à la concentration des processus par n uds. Comme nous l'avons vu en partie 1.1.3, une charge de deux processus par n ud ne dégrade pas nécessairement les performances. L'ordonnanceur charge au maximum certains n uds, en s'accordant une tolérance dénie par l'administrateur, an d'en décharger d'autres et de pouvoir les mettre en mode basse consommation Écriture de la politique Nous dénissons une politique élémentaire qui consiste à charger les n uds au maximum selon un critère. Pour plus de simplicité, étant donné que nous en avons déjà parlé, nous prendrons le critère d'équilibrage de charge processeur). Èquilibrage de charge des processeurs La politique élémentaire de l'équilibrage de charge entre les processeurs est la même que celle dénie dans le paragraphe La diérence est que dans le cas présent, nous tenons à avoir un recouvrement de l'exécution des processus sur un même processeur. Nous xons à 2 le nombre maximum de processus pouvant être exécuté simultanément sur un même processeur. Actions. Nous dénissons 4 actions. Deux d'entres-elles ont déjà été vues dans le paragraphe : réveiller un processus et déplacer un processus.

47 4.3. GESTION DYNAMIQUE D'APPLICATIONS PARALLÈLES À MÉMOIRE PARTAGÉE39 Nous voyons maintenant deux nouvelles actions qui n'agissent pas sur des processus mais sur des n uds. Ce sont les actions réveiller un n ud et éteindre un n ud qui allument ou éteignent les n uds. Ces actions sont dénies par : un ensemble de n uds éligibles, c'est à dire, l'ensemble des n uds de la grappe, un ensemble de processus éligible, c'est à dire, l'ensemble vide. En eet, ces actions n'agissent pas sur des processus. Fonction de simulation. La fonction de simulation associée à cette ressource physique est : si l'on ajoute un processus sur ce processeur, est-ce que la charge de la grappe est toujours homogène avec un maximum de 2 processus en cours d'exécution par n uds?. Arbre de priorité Cette politique globale d'ordonnancement étant composée d'une seule politique élémentaire, il ne nous a pas parut pertinent de présenter un arbre de priorité réduit à une une seule politique élémentaire avec 4 actions. Nous préférons présenter l'algorithme qui est selon nous plus intéressant (voir algorithme 5). Algorithme 5 : Algorithme d'équilibrage de charge selon la politique d'économie d'énergie. 1. si (charge_processeur > 200%) ET (du_travail_en_attente) ET (pas_de_noeuds_disponibles) ET (des_noeuds_éteind) alors essayer de réveiller un noeud. n 2. si (charge_processeur > 200%) ET (du_travail_en_attente) ET (des_noeuds_sont_disponibles) alors essayer de réveiller des processus sur des noeuds distants. n 3. si charge_processeur == 100% alors essayer de déplacer sur un noeud ayant aussi 100% de charge processeur. n 4. si charge_processeur < 100% alors (essayer de réveiller des processus sur des noeuds (local ou distants) ayant 100% de charge processeur) OU (éteindre le noeud). n Cette algorithme contient quatre cas particuliers permettant d'équilibrer la charge des processeurs avec une densité de deux processus par n uds. Les n uds inactifs sont éteind. En cas d'arrivé en liste d'attente d'une nouvelle tâche et que des n uds disponibles sont nécessaires, l'algorithme prend en charge le réveil des n uds Filtre sur les processus Cette politique n'implémente pas de ltre sur les processus. 4.3 Gestion dynamique d'applications parallèles à mémoire partagée Étienne Rivière a proposé dans [38] un ordonnanceur adapté aux applications parallèles fondées sur une mémoire partagée. Il a développé un ordonnanceur sur le système Kerrighed qui ore une mémoire partagée entre l'ensemble des n uds de la grappe. L'ordonnanceur réalise de l'équilibrage de charge en fonction de la ressource processeur. Les processus sont

48 40 CHAPITRE 4. APPLICATION DE NOTRE APPROCHE placés sur les n uds à leur création et peuvent être déplacés en cours d'exécution. Dans le cas d'un déplacement en cours d'exécution, l'initiative revient au n ud chargé. Lors d'une migration d'un processus, seul les éléments de contexte et l'état du processus sont envoyés au n ud de destination. L'ensemble des données manipulées par le processus (mémoire, chier...) est envoyé ensuite de manière paresseuse du n ud d'origine vers le n ud de destination Politique L'objectif de la politique est d'assuré un équilibrage de charge entre les diérents processeurs de la grappe. Pour ce faire, l'ordonnanceur du système déplace des processus au cours du temps. Cependant, si l'ordonnanceur à le choix entre diérents processus, alors il pourrait être intéressant de déplacer celui qui ferait le moins de défauts de pages sur le n ud de destination. Pour ce faire, il faut introduire un indicateur de coût d'utilisation de la mémoire virtuelle partagée distribuée (MVPD) qui est le rapport entre le temps passé à exécuter le code de l'application et le temps passé à exécuter le code de mise en uvre de la mémoire partagée Écriture de la politique Pour mettre en place une telle politique, il nous faut créer deux politiques élémentaires. La première consiste à équilibrer la charge entre les processeurs. La seconde consiste à placer les processus de manière optimisée sur les n uds. Équilibrage de la charge entre les processeurs L'équilibrage de la charge entre les processeurs est la même que celle dénie dans le paragraphe La diérence est que dans le cas présent, cette politiqué élémentaire est de priorité maximum an de garantir avant tout une utilisation homogène de la grappe. De plus, an de permettre un regroupement de processus par anité, il faut permettre à un n ud monoprocesseur ou multiprocesseur d'exécuter plus que un processus simultanément. Ainsi, tous les processus exécuté sur un même n ud monoprocesseur ou multiprocesseur bénécient de la mémoire partagée de ce n ud. Nous dénissons un seuil qui est de 3 processus d'une même application pour un processeur. Ainsi, la politique d'équilibrage de la charge des processeurs s'assure qu'en continu, au maximum 3 processus sont en cours d'exécution par processeurs. Ce seuil est arbitraire et peut surement être optimisé par une étude plus approfondie qui dépasse le cadre de ce document. Actions. Nous utilisons une action qui est celle de déplacement d'un processus. Cette action a déjà été expliquée dans le paragraphe Fonction de simulation. La fonction de simulation associée à cette ressource physique est : si l'on ajoute un processus sur ce processeur, est-ce que la charge de la grappe est toujours homogène avec un maximum de 3 processus en cours d'exécution par n uds?. Placement ecace des processus Cette politique gère une ressource logique qui est le placement ecace des processus. En eet, en imaginant que la charge processeur soit vérié, il est peut-être possible que les processus utilisant des mêmes pages mémoire ne soient pas placée de manière cohérente sur la grappe. Cette politique élémentaire doit à partir de l'indicateur d'anité entre les processus conçu par [38], rechercher des processus partageant de nombreuses pages mémoires, mais ne partageant pas la même mémoire physique.

49 4.3. GESTION DYNAMIQUE D'APPLICATIONS PARALLÈLES À MÉMOIRE PARTAGÉE41 Fig. 4.3 Exemple d'arbre de priorité pour la gestion dynamique d'applications communiquant par mémoire partagée. La ressource placement ecace des processus qui est dénie par : le taux d'anité des processus présent sur même n ud, le taux d'anité d'un processus par rapport à un n ud. Actions. Nous utilisons deux actions. Dans le cas ou un mauvais placement de processus est détecté, la politique élémentaire essaye de déplacer les processus mis en cause en veillant à ne pas rompre la politique d'équilibrage de charge, à savoir un maximum de trois processus par processeur. Cette action est dénie de la même manière qu'au paragraphe De plus, nous utilisons une action qui est celle du réveil des processus. Cette action a déjà été expliquée dans le paragraphe Fonction de simulation. La fonction de simulation associée à cette ressource logique est : si l'on déplace le processus P sur le n ud N, est-ce que son anité mémoire sera meilleure avec les processus du n ud N?. Arbre de priorité L'arbre des priorités de cette politique est représenté sur la gure 4.3. La première politique que nous décrivons est celle de la gestion de l'équilibrage de charge entre les processeurs. La seconde politique de priorité inférieure est celle du placement optimisé des processus sur les processeurs. Concrètement, l'équilibrage de la charge entre les processeurs est assuré en premier lieu. Pour ce faire, l'ordonnanceur peut être amené à déplacer des processus. Lorsque la politique d'équilibrage de charge entre les processeurs est vériée, le système tente de placer les processus de manière optimale.

50 42 CHAPITRE 4. APPLICATION DE NOTRE APPROCHE Notons que sur cet arbre de priorité il n'y a pas d'action ne_rien_faire, cela est dû au fonction de simulation. En eet, chaque action étant simulée avant sa réalisation, le cas ou toutes les simulations échouent revient implicitement à réaliser l'action ne_rien_faire. Filtre sur les processus Cette politique n'a pas besoin d'appliquer un ltre général sur les processus.

51 Chapitre 5 Mise en uvre Nous avons développé un prototype dans le contexte du système à image unique Kerrighed. Ce prototype composé de diérents modules indépendants. Une telle modularité rend le système évolutif et plus générique. Dans ce chapitre nous présentons notre ordonnaceur modulaire. Puis, nous précisons notre mise en uvre dans le cadre du système à image unique Kerrighed. Enn, nous eectuons des évaluations an de valider notre prototype. 5.1 Ordonnanceur modulaire L'ordonnanceur global est réparti sur l'ensemble des n uds de la grappe. Chaque n ud exécute un centre de décision. L'ensemble des centres de décision forment l'ordonnanceur global. Les centres de décision peuvent communiquer entre-eux grâce à des socket TCP/IP. Un centre de décision lit la politique de l'administrateur et selon celle-ci, surveille les ressources an d'exécuter les bonnes actions. An de rendre notre système le plus générique possible, nous avons organisé son infrastructure en diérents modules indépendants les uns des autres. La gure 5.1 représente l'architecture de notre mise en uvre. C'est le centre de décision qui met en liaison ces diérents modules. De plus, le système est conçu pour que diérentes personnes puissent interagir. Par exemple, les actions peuvent être écrites par les développeurs du système d'exploitation. Les ressources peuvent être écrite par des constructeurs de matériels. Au nal, l'administrateur de sa grappe, n'a besoin de spécier uniquement sa politique s'il dispose de tous les modules nécessaires. La politique de l'administrateur est un chier texte. De plus, l'infrastructure du système est constituée de ressources et d'actions qui sont dénies par des fonctions que nous étudions dans les paragraphes suivants. Enn, nous disposons d'autres outils comme les ltres pour les n uds et pour les processus, les comparateurs, et les fonctions de tri. Nous étudions chacun de ces modules dans les paragraphes suivants. Chacun de ces modules est compilé en tant que librairie ce qui permet par exemple de rajouter une action, sans avoir à recompiler l'ensemble du système. Enn, nous avons développé notre prototype en langage C. 5.2 Mise en uvre de l'ordonnancement dans le cadre de Kerrighed Les travaux que nous avons eectués se place dans le contexte du système à image unique Kerrighed. 43

52 44 CHAPITRE 5. MISE EN UVRE Fig. 5.1 Architecture de l'ordonnanceur global.

53 5.2. MISE EN UVRE DE L'ORDONNANCEMENT DANS LE CADRE DE KERRIGHED Spécicités du système à image unique Kerrighed Kerrighed est un système à image unique pour grappe de PCs (voir la partie 1.3.6). C'est une extension du noyau Linux développé sous forme de modules. Nous avons étendu Kerrighed avec un appel système get_infos(int type, int noeud) qui renvoie l'information de type type du n ud noeud. Cet appel système sert principalement à obtenir les capacités des processus. En eet, cet appel système peut retourner par exemple, l'ensemble des processus ayant la capacité de migration. On dénit une capacité comme étant un attribut d'un processus. Un processus peut avoir plusieurs capacités. Par exemple, pour qu'un processus puisse être déplacé par une action de migration, alors il doit disposer de la capacité de migration : CAP_CAN_MIGRATE. Pour ce faire, nous utilisons la fonction get_infos(get_list_pid_cap_can_migrate, local_node) qui renvoie la liste des processus du n ud local_node ayant la capacité de migration. Kerrighed ore nativement un ordonnanceur capable de faire de l'équilibrage de charge sur la ressource processeur Mise en uvre de l'ordonnanceur Dans un but de généricité par rapport au système d'exploitation sous-jacent, nous avons mis en uvre notre ordonnanceur en espace utilisateur. De plus, cela facilite le développement du prototype. En eet, l'impact d'une erreur dans l'écriture du code dans un programme exécuté en espace utilisateur n'est pas la même qu'en espace noyau. Dans le premier cas, le programme se termine généralemet en erreur de segmentation, mais le système d'exploitation reste opérationnel. Dans le second cas, le noyau du système d'exploitation part en erreur. Il faut alors généralement redémarrer toute la grappe. Ainsi, nos modications par rapport au système Kerrighed sont assez légères. L'algorithme d'un centre de décision est une itération qui applique en continu la politique d'ordonnancement globale de l'administrateur. Cela consiste pour chaque politique simple à comparer la valeur courante de la ressource avec la valeur seuil que l'utilisateur a fournie dans sa politique élémentaire. Dans les paragraphes suivants, nous présentons les diérents modules utilisés par les centres de décision. Les ressources Une ressource est caractérisée par : une fonction retournant une valeur physique du système ou une valeur logique dans le cas d'une ressource logique (int get_infos_node()), une fonction permettant de retourner la contribution d'un processus sur le taux d'utilisation de la ressource (int get_infos_process(int pid)), une fonction de simulation (int simulate(int threshold, int val_proc)) qui prend en paramètre un seuil limite toléré par le système pour la ressource et la contribution d'un processus sur cette ressource. Cette fonction renvoie un booléen donnant le résultat de la simulation). Les actions Une action est développée en lien avec le système d'exploitation. Par exemple, pour utiliser l'action migration, il faut qu'elle soit supportée par le système. Une action est caractérisée par : un ensemble de n uds, pouvant supporter les conséquences de l'action considérée, renvoyé par la fonction int *get_eligible_node(), un ensemble de processus, pouvant subir l'action considérée, renvoyé par la fonction int *get_eligible_process(),

54 46 CHAPITRE 5. MISE EN UVRE l'action à réaliser, exécutée par la fonction int action(int node, int pid) qui renvoie 0 ou 1 selon que la réalisation de l'action ait échouée ou réussie. Une action n'agit pas forcément sur un processus (comme nous l'avons vu en partie 4.2). En eet, on pourrait vouloir dénir une action éteindre_noeud. Dans ce cas, l'ensemble des processus renvoyé par cette action est un ensemble NULL. De plus, nous avons déni une action null qui est une action n'eectuant rien, et qui retourne toujours une liste de n uds ainsi qu'une liste de processus vide. De plus, cette action se termine toujours par un succès. Pour récupérer des informations sur les processus, nous utilisons deux méthodes. La première est celle décrite dans le paragraphe 5.2.1, c'est à dire que nous utilisons un appel système qui renvoie les informations demandées. La seconde méthode consiste a lier notre prototype à la librairie libproc (fournie par exemple avec la distribution Debian standard [43]) qui permet de faciliter la lecture du /proc en espace utilisateur. Grâce à cela, il est possible d'obtenir pratiquement toutes les informations nécessaires comme la taille du processus en mémoire, le taux d'utilisation du processeur ou le nombre de chiers ouverts, du processus, et cela, sans passer par un appel système lié au noyau. La politique La politique d'ordonnancement global est dénie par l'administrateur de la grappe. Elle se présente sous la forme d'un chier texte. L'administrateur y dénit les diérentes règles constituant les politiques. Nous présentons sur la gure 5.2 un exemple de politique globale d'ordonnancement. Cette politique globale d'ordonnancement comporte deux politiques élémentaires. La première politique élémentaire s'assure que le n ud n'utilise pas sa partition d'échange. Pour ce faire, dès que la mémoire occupée d'un n ud dépasse 50% d'utilisation alors, l'ordonnanceur essaye déplacer des processus. La seconde politique, de priorité inférieure, s'assure que la charge entre les processeur est bien assuré. Dès que la charge d'un processeur dépasse 180% de charge alors, l'ordonnanceur essaye de stopper des processus. Si cette charge dépasse 150%, l'ordonnanceur essaye de déplacer des processus. Dans les deux autres cas, l'ordonnanceur essaye de réveiller des processus soit sur le n ud local, soit sur des n uds distants. Les points d'exclamations délimitent les politiques élémentaires. Nous reconnaissons ici deux politiques élémentaires. Dans une politique élémentaire, on délimite une section entête ainsi qu'une section règles que l'on dénit dans les paragraphes suivants. Dans la politique élémentaire numéro 1, la section entête va de la ligne 1 à la ligne 7 et la section règles va de la ligne 8 à la ligne 10. Section entête : le champ name : indique le nom de la politique élémentaire. Ce nom correspond au nom de la librairie de la ressource que l'on veut utiliser. le champ p : est le numéro de priorité de la politique élémentaire. le champ sort_node : est la manière dont l'on veut trier les n uds. La valeur que prend ce champ correspond au nom de la fonction à exécuter dans la librairie fonction de tri. le champ sort_process : est la manière dont l'on veut trier les processus. La valeur que prend ce champ correspond au nom de la fonction à exécuter dans la librairie fonction de tri. le champ eligible_general_node : est le ltre que l'on applique sur l'ensemble des n uds. Ce ltre est indépendant de l'action à exécuter. La valeur que prend ce champ correspond au nom de la fonction à exécuter dans la librairie ltre des n uds.

55 5.2. MISE EN UVRE DE L'ORDONNANCEMENT DANS LE CADRE DE KERRIGHED47 1.! name=mem_no_swap p=1 sort_node=ascending_order 5. sort_process=descending_order eligible_general_node=all eligible_general_process=all superior 50:try_to_migrate KO simulation 50 superior -1:null OK no_simulation 10.!!name=CPU_load_balancing p=2 sort_node=ascending_order 15.sort_process=descending_order eligible_general_node=all eligible_general_process=all superior 180:try_to_stop_on_mem KO no_simulation superior 150:try_to_migrate KO simulation superior 95:try_to_wake_up_distant OK simulation 100 superior -1:try_to_wake_up_local OK simulation 100! Fig. 5.2 Exemple d'une politique globale comprenant deux politiques élémentaires pour la gestion de la mémoire et l'équilibrage de charge processeur. le champ eligible_general_process : est le ltre que l'on applique sur l'ensemble des processus. Ce ltre est indépendant de l'action à exécuter. La valeur que prend ce champ correspond au nom de la fonction à exécuter dans la librairie ltre des processus. Section règles : elle est constituée d'une succession de ligne dont le gabarit est le suivant : comparateur value:action status simulation value_simulation Ci-dessous nous indiquons la signication des diérents mots-clés : le mot-clé comparateur : est le module de comparaison que l'on veut instancier (par exemple : superieur, inferieur, mais on peut également dénir des fonctions plus complexes comme : égal_à_plus_ou_moins_3...) Le nom de la fonction de comparaison correspond au nom de la fonction écrite dans le module comparateur. le mot-clé value : est la valeur seuil qui déclenche l'éxécution de l'action. le mot-clé action : est l'action à exécuter si la condition est vériée. le mot-clé status : indique si la règle correspondante est eectuée dans le cadre d'une correction de problème (KO) ou non (OK). Ce mot-clé est un artice de mise en uvre qui devrait être enlevé dans les prochaines versions du prototype et qui n'intervient pas dans la conception. le mot-clé simulation : indique si l'action considérée doit eectuer une simulation (simulation ; exemple : réveil d'un processus) ou non (no_simulation ; exemple : arrêt d'un processus). le mot-clé value_simulation : est la valeur à laquelle doit être comparé le résultat de la simulation dans le cas où une simulation est nécessaire.

56 48 CHAPITRE 5. MISE EN UVRE Lecture d'une règle par l'exemple. Ce paragraphe décrit la syntaxe d'une règle en langage naturel. Pour une règle d'une politique élémentaire, si la comparaison (comparateur) de la valeur value à la valeur retournée par la fonction get_infos_node() de la ressource est vraie, alors il y a 2 cas. Soit la règle spécie qu'il n'y a pas de simulation à réaliser (no_simulation), alors, l'action action est exécutée directement, soit il faut réaliser une simulation (simulation), alors une simulation doit être eectuée avant d'exécuter l'action. En revanche, si la comparaison est fausse, le système passe à la règle suivante. Les comparateurs Ce sont les comparateurs qui permettent de vérier que les conditions décrites dans la politique globale sont vériées. Ainsi, nous avons déni un module de comparateurs qui permet de garder ce principe de généricité. L'utilisateur peut donc créer sa propre fonction de comparaison (superieur, inferieur, environ_egal...). La signature de la fonction est la suivante : int ma_fonction_de_comparaison(int valeur1, int valeur2); Cette fonction doit renvoyer 1 en cas de succès dans la comparaison de valeur1 et valeur2 et 0 sinon. Les fonctions de tri L'ensemble des n uds et l'ensemble des processus sont triés selon une fonction de tri décrite par l'utilisateur. On peut bien entendu avoir des fonctions de tri classiques comme croissant, décroissant, mais également des fonctions plus spéciques comme croissant pour les n uds pairs en début de liste, et décroissant pour les autres en n de liste. La signature de la fonction est la suivante : int ma_fonction_de_tri(infos_t *infos); infos_t est une structure contenant deux entiers : un identiant (par exemple, l'identiant du n ud ou du processus), et une valeur (par exemple, la charge processeur du n ud, ou le taux d'utilisation du processeur par le processus). Cette fonction doit renvoyer la structure inf os triée. Filtre des n uds Le but de cette fonction est de retourner un tableau de n uds dont les critères sont indépendants de l'action. Par exemple, ce ltre peut choisir l'ensemble des n uds supportant Myrinet ou l'ensemble des n uds avec plus de 2Go de mémoire... La signature de la fonction est la suivante : int *ma_fonction_de_eligible_noeud(); C'est le centre de décision qui fait la sélection entre les n uds rendus éligibles par l'action (liste numéro 1) et les n uds rendus éligibles par cette fonction (liste numéro 2). Le centre de décision fait l'intersection des deux listes an d'obtenir une liste de n uds valides en rapport avec l'action et avec des contraintes spéciées par l'administrateur indépendante de l'action.

57 5.3. ÉVALUATIONS 49 Fig. 5.3 Principe du module de conversion. Filtre des processus Le principe de fonctionnement du ltre des processus est le même que celui des n uds. Par exemple, il est possible de sélectionner l'ensemble des processus appartenant au groupe ADMIN ou les processus en cours d'exécution depuis plus de deux heures... La signature de la fonction est la suivante : int *ma_fonction_de_eligible_processus(); Cette fonction retourne une liste de processus indépentante de l'action Gestion des unités Une diculté rencontrée dans la mise en uvre des politiques d'ordonnancement est la gestion des unités entre les valeurs données par l'utilisateur (exemple : 50% de mémoire disponible) et les valeurs récupérées par le système (exemple, 660Mo de mémoire disponible). Il faut donc convertir la donnée spéciée par l'utilisateur. De plus, comme nous eectuons les simulations sur les n uds distants, en considérant des n uds non homogènes, l'on conçoit aisément que si un processus utilise 50% de la mémoire sur le n ud A, cela ne signie pas qu'il en occupera autant sur le n ud B. Pour résoudre ces diérents problèmes, nous avons mis en place un système de conversion. La gure 5.3 présente le module de conversion. Le centre de décision récupère les informations dont il a besoin à partir du module de pourcentage, dans le cadre des comparaisons avec la politique, ou à partir du module de valeur brute, dans le cas d'une simulation avec l'intervention de d'autres centres de décision. Cependant, si pour une raison particulière un administrateur veut spécier dans sa politique des valeurs brutes et non des taux d'utilisation, il faut réécrire le module get_infos_percentage de la ressource considérée an qu'elle retourne la même valeur que le module get_infos. 5.3 Évaluations Nous utilisons une grappe de calculateurs composée de 3 n uds cadencés à 1,7GHz et équipés de 768Mo de mémoire vive. Ces trois n uds sont interconnectés par un réseau Ethernet à 100Mbits/s. Dans les diérentes expériences des paragraphes suivants, nous cherchons à valider la capacité de notre système à réguler une charge de travail et équilibrer la charge entre les ressources. Pour ce faire, nous réalisons des comparaisons entre

58 50 CHAPITRE 5. MISE EN UVRE le temps d'écoulement de la charge de travail pour un placement calculé, le temps obtenu avec Kerrighed et son ordonnanceur intégré, le temps obtenu par les politiques mise en uvre dans le cadre de notre infrastructure. Dans les paragraphes suivants nous réalisons 3 expériences. La première utilise une politique élémentaire gérant la ressource mémoire. La seconde utilise une politique élémentaire gérant la ressource processeur. La troisième expérience utilise deux politiques élémentaires gérant la ressource réseau ainsi que la ressource processeur. Notons tout de même que dans la version de Kerrighed, certains mécanismes ne sont pas susament stable an de réaliser toutes les expèriences que nous aurions voulu. Par exemple, Kerrighed ne supporte pas les partitions d'échange. De plus, Kerrighed n'est pas capable de déplacer d'un n ud à un autre des processus occupant plus de 15Mo de mémoire vive. Enn, Kerrighed ne peut pas déplacer des processus communiquants d'un n ud à un autre. Cela nous a contraint d'adapter nos expériences à certains types de tâches que nous avons nous même créé. Nous détaillons cela dans les paragraphes suivants Conguration équilibrage mémoire Cette expérience a pour objectif de réguler la charge mémoire des n uds. La gure 5.4 présente la politique utilisée pour notre expérience. Cette politique réveil des processus! name=mem_no_swap p=1 eligible_node=all eligible_process=all sort_node=ascending_order sort_process=descending_order superior 50:try_to_migrate KO simulation 50 superior -1:try_to_wake_up_local OK simulation 50! Fig. 5.4 Politique de gestion de la mémoire. en attente tant que le taux d'occupation mémoire du n ud local est en dessous de 50% d'utilisation. Dans le cas ou le taux d'occupation de la mémoire dépasse 50% d'utilisation, alors l'ordonnanceur essaye de déplacer des processus. Pour notre expérience, nous avons créé un programme (fd_mem_wait) qui, lors de son exécution, crée n ls. Chacun de ces ls écrit en mémoire un tableau d'entier. Ce programme attend ensuite la n d'exécution de tous les ls pour rendre la main. Les temps que nous mesurons sont ceux du temps d'exécution du programme père (nous utilisons la commande time). Le calcul de la référence théorique a été fait selon le procédé suivant : nous mesurons le temps d'exécution d'un programme père en lui passant en paramètre un nombre de ls égal à 1 (et en gardant les autres paramètres égaux à ceux de l'expérience). Ainsi, pour une expérience à n ls, nous divisons n par le nombre de n uds dans la grappe (ici, 3) et nous multiplions ce résultat par le temps d'exécution d'un seul ls. Si le reste de la division n'est pas nul, nous ajoutons 1 fois le temps d'exécution d'un seul ls. La gure 5.5 présente sur l'axe des ordonnées le temps de n d'exécution des programmes pères selon le nombre de ls créés. OG présente les temps de n d'exécution avec notre prototype (sans l'ordonnanceur de Kerrighed actif). K présente les temps de n d'exécution avec l'ordonnanceur de Kerrighed. On remarque que notre système obtient des résultats très proches de ceux du temps de référence. De plus, ils sont toujours inférieurs à ceux de Kerrighed sans notre ordonnanceur.

59 5.3. ÉVALUATIONS 51 Fig. 5.5 Exécution de fd_mem_wait avec comme paramètres : n ls, size = 100Mo en mémoire, 10 itérations et 10 secondes entre chaque itérations. De plus, dès que l'on dépasse la capacité totale de mémoire vive de la grappe ( = 2500Mo > = 2295Mo) la régulation de charge qu'ore notre ordonnanceur permet l'exécution de l'ensemble des processus, alors qu'avec le système classique sans régulation de charge, l'application n'arrive pas à terminer son calcul (ce qui paraît pleinement logique étant donné qu'on demande au système sans régulation de charge d'exécuter simultanément des processus qui utilisent plus de ressources qu'il y en a de disponible). Nous validons donc ici la capacité qu'à notre ordonnanceur à réguler et équilibrer la charge mémoire sur la grappe Conguration équilibrage processeur Nous réalisons une validation sur la régulation du travail en fonction de la charge du processeur. La gure 5.6 décrit la politique que nous utilisons.! name=cpu_load_balancing p=1 eligible_node=all eligible_process=all sort_node=ascending_order sort_process=descending_order superior 95:try_to_wake_up_distant OK simulation 100 superior -1:try_to_wake_up_local OK simulation 100! Fig. 5.6 Politique de gestion de la charge processeur. Cette politique réveil des processus en attente localement tant que la charge processeur est en dessous de 95%. Si ce seuil est dépassé alors, l'ordonnanceur essaye de réveiller des processus sur les n uds distants.

60 52 CHAPITRE 5. MISE EN UVRE Fig. 5.7 Exécution de fd_bi avec en paramètre n processus ls, et 10 et 1000 comme nombres d'itération. Nous utilisons le même type de programme test que celui décrit dans le paragraphe précédent à la diérence que, cette fois-ci les processus ls réalisent du calcul intensif uniquement (pas d'accès à la mémoire). Notre programme (fd_bi) prend en paramètre un nombre de ls, et deux nombres d'itérations. Chaque ls exécute une addition dans deux boucles imbriquées (d'où, les deux nombres d'itérations demandés en paramètre). Nous remarquons que plus le nombre de processus augmente, et moins notre ordonnanceur est performant. Cela est principalement dû au fait que plus le nombre de processus est grand, plus le temps de parcours du répertoire /proc pour sélectionner les processus est important. De plus, un autre problème est le temps de mise à jour de l'indicateur de charge processeur. En eet, lors du réveil ou de l'arrêt d'un processus, cet indicateur peut prendre jusqu'à 3 secondes avant de se mettre à jour. Ainsi, avant de prendre une décision d'action valide, le centre de décision doit entre chaque action attendre 3 secondes an que l'indicateur soit mis à jour. Une perspective pourrait-être d'implémenter une charge virtuelle qui lors d'un réveil ou d'un arrêt de processus augmenterait, ou diminuerait articiellement la charge pendant un laps de temps. Des travaux ont été réalisé à ce sujet dans Kerrighed [23], il pourrait être intéressant de reprendre les concepts pour les implémenter dans l'espace utilisateur Conguration avec priorité équilibrage de la charge processeur puis de la charge réseau Nous montrons dans cette expérience une politique globale d'ordonnancement à deux politiques élémentaires (voir la politique 5.8). La première politique élémentaire consiste à optimiser la charge du réseau. La seconde politique consiste à faire de l'équilibrage de charge entre les processeurs. La gure 5.9 présente la conguration de cette expérience. Nous disposons d'un serveur en dehors de notre grappe. Nous limitons la bande passante du n ud numéro 2 à 5Mbits/s. Les autres n uds peuvent communiquer entre-eux et avec le serveur à 100Mbits/s. Á partir du n ud 0, nous lançons 2 processus communiquant intensivement avec le serveur se trouvant à l'extérieur de notre grappe. Nous lançons également un troisième processus

61 5.3. ÉVALUATIONS 53! name=net p=1 eligible_node=all eligible_process=net_app sort_node=ascending_order sort_process=descending_order egal 0:try_to_migrate KO no_simulation egal 1:null OK no_simulation!! name=cpu_load_balancing p=2 eligible_node=all eligible_process=all sort_node=ascending_order sort_process=descending_order superior 200:try_to_migrate KO simulation 100 superior 95:try_to_wake_up_distant OK simulation 100 superior -1:try_to_wake_up_local OK simulation 100! Fig. 5.8 Politique de gestion à deux critères, gestion de la ressource réseau et gestion de la ressource processeur. qui réalise uniquement du calcul intensif. Nous étudions le temps de n de l'ensemble des 3 processus. Normalement, avec l'ordonnanceur de Kerrighed, comme l'équilibrage de charge se fait selon la ressource processeur, les processus pourront être déplacer de n'importe quelle manière sur la grappe avec, a priori, un processus par n ud au nal. Deux cas sont possibles, la situation d'ordonnancement pour ces processus est non-déterministe. Le cas favorable est que les deux processus communicants soient placés sur les n uds 0 et 1, n uds disposant d'un lien réseau important, et le processus de calcul intensif placé sur le n ud 2. Le cas défavorable est que l'un des deux processus communicants se fasse déplacer vers le n ud 2, disposant d'un débit réseau moindre, alors que le processus de calcul intensif reste sur un n ud disposant d'un débit réseau important. La situation avec notre ordonnanceur doit être diérente. Dans un premier temps, la charge réseau est équilibrée. Puis, c'est la charge processeur qui l'est. Ainsi, les processus communicants sont placés sur les n uds disposant d'un lien réseau rapide, c'est-à-dire, les n uds 0 et 1. Le processus de calcul intensif est lui placé sur le n ud 2, disposant d'un lien réseau moins rapide. Avec notre prototype, la situation d'ordonnancement pour ces processus est déterministe. La gure 5.10 présente les résultats de cette expérience. On nomme OG notre prototype. Ce graphique représente en absisse les diérents cas de gure : placement des processus avec Kerrighed dans le cas défavorable, placement des processus avec Kerrighed dans le cas défavorable et enn placement des processus avec notre prototype. En ordonnée, nous présentons le temps de n d'exécution de l'ensemble des 3 processus. Enn, nous présentons également sur ce graphique le temps de référence dans le cas d'un placement favorable pour l'ensemble des 3 processus. On remarque alors que le cas favorable pour Kerrighed équivaut à celui de notre prototype. Cela correspond au temps de référence. En revanche, le cas défavorable de Kerrighed est moins performante de plus de 20% en temps de n d'exécution.

62 54 CHAPITRE 5. MISE EN UVRE Fig. 5.9 Conguration de l'expérience à 2 politiques élémentaires. Fig Résultat de l'expérience à deux politiques élémentaires.

63 5.3. ÉVALUATIONS 55 De plus, au moment des expérimentations, nous avons pu vérier que dans 100% des cas de test que nous avons eectués avec notre prototype, la situation d'ordonnancement est déterministe et tombe dans le cas favorable systèmatiquement. Pour Kerrighed, cela n'est pas le cas, le cas favorable n'est atteint que dans 50% des tests. En conclusion, cette expérience nous a permis de valider une politique globale d'ordonnancement à deux critères, réalisant de l'équilibrage de charge, fondée sur la ressource réseau et la ressource processeur.

64 56 CHAPITRE 5. MISE EN UVRE

65 Conclusion Traditionnellement, la gestion des ressources dans les grappes est eectuée par des systèmes à exécution par lots à l'image de l'exploitation des machines parallèles. Ces systèmes régulent la charge globale de la grappe par un contrôle d'admission des tâches. L'équilibrage de la charge entre les n uds est eectué lors du placement des tâches. En outre, les n uds sont généralement réservés exclusivement à l'exécution d'une tâche. Les systèmes à image unique, dont les premiers prototypes datent de cette décennie, permettent d'utiliser une grappe comme une station de travail très puissante. Ces systèmes intègrent un ordonnancement des processus qui équilibre la charge entre les les n uds. Les systèmes à image unique n'orent pas de manière native des mécanismes de régulation de charge. Au cours de notre stage de Master, nous nous sommes intéressés à la conception d'un ordonnanceur global de processus dans le cadre d'un système à image unique. Notre objectif a été de concevoir une infrastructure d'ordonnancement global permettant de concilier des politiques de régulation de la charge globale d'une grappe et d'équilibrage de la charge entre les n uds. Nous avons cherché à concevoir un ordonnanceur hautement congurable pour, adapter le système à image unique à diérents types d'utilisation, et permettre aux administrateurs de grappe d'exprimer simplement des politiques de gestion des ressources à mettre en uvre. Nous avons conçu un ordonnanceur capable de faire de la régulation de tâches au cours du temps. Cet ordonnanceur est simple, congurable par un simple chier texte, et générique, il n'est pas limité à un nombre de ressources ou à un nombre d'actions prédéterminées. Enn il est évolutif. De plus, il est capable de faire de l'équilibrage de charge et cela selon diérents critères spéciés par l'administrateur de la grappe. Pour ce faire, nous avons mis en place une notion de priorité entre les diérentes ressources que l'on veut surveiller. Ainsi, notre ordonnanceur est capable de maximiser l'utilisation des ressources selon diérents critères, et en cas d'incompatibilité entre les actions de diérents critères, la gestion de la ressource de plus forte priorité est eectuée avant les autres. Notre prototype, développé dans l'espace utilisateur, a été expérimenté avec 3 politiques diérentes. La première met en uvre une politique élementaire de régulation et d'équilibrage de charge mémoire. La seconde met une politique élementaire de régulation et d'équilibrage de charge processeur. La troisième met en uvre deux politiques élémentaires d'équilibrage et de régulation sur les ressources processeur et réseau. Nous avons pu ainsi valider le système sur la régulation et l'équilibrage de charge mémoire. Les diérentes expériences réalisées valident la capacité qu'a notre prototype à réguler et équilibrer une charge de travail au cours du temps sur les ressources de la grappe. De plus, de part son aspect multi-critères, notre ordonnanceur est plus performant et réalise une meilleure utilisation des ressources. Les évaluations ont principalement été limitées par le manque d'indicateur dans le système d'exploitation. De plus, Kerrighed ne supporte pas la partition d'échange sur disque et le déplacement de processus communicant ou occupant plus de 15Mo en mémoire. Ainsi, les expérimentations concernant la politique élémentaire de gestion de la ressource 57

66 IV CONCLUSION mémoire sont moins marquantes. Notons aussi que le temps de mise à jour de l'indicateur de charge processeur fait perdre en réactivité notre prototype. Un système de charge virtuelle pourrait être conçu an de remédier à ce problème. Du point de vue de la mise en uvre, le système est opérationnel. Cependant, il mériterait d'être plus protégé, c'est-à-dire qu'en l'état actuel du prototype, aucune vérication n'est faite sur la syntaxe de la politique, ou sur les fonctions qui sont écrites dans les diérentes librairies. Comme l'ordonnanceur doit être exécuté avec des droits de superutilisateur, cela crée des failles évidentes de sécurité. De plus, des optimisations sont à faire, an de le rendre plus performant et plus robuste. Enn, il faut également étendre les expériences à des applications existantes comme par exemple des applications de calcul d'algèbre linéaire. Enn, il pourrait être intéressant de faire prendre en compte à notre ordonnanceur la notion d'application. Cela permettrait d'appliquer à la grappe des politiques de Gang- Scheduling, par exemple. Nous pourrions dénir une application comme un ensemble d'objets du système : des processus, des sockets, de la mémoire... Notre détecteur de processus serait à étendre en détecteur d'application. Ainsi, notre ordonnanceur serait capable de gérer des applications. Ce travail peut-être considéré comme une première étape pour une gestion complète d'applications dans les grappes de calculateurs.

67 Bibliographie [1] Lam/mpi Parallel Computing. Available at 7 [2] Mpich Home Page. Available at index.htm. 7 [3] Stanford Parallel Applications for Shared Memory (SPLASH). Available at http: //www-flash.stanford.edu/apps/splash/. 3 [4] Message Passing Interface. Available at 3, 7 [5] PVM : Parallel Virtual Machine. Available at 3, 7 [6] Josh Aas. Understanding the Linux CPU Scheduler. Technical report, Silicon Graphics, Inc. (SGI), [7] Thomas E. Anderson, David E. Culler, David A. Patterson, and The NOW Team. A case for NOW (Networks of Workstations). In Micro, IEEE, volume 15, pages February [8] Remzi H. Arpaci, Andrea C. Dusseau, Amin M. Vahdat, Lok T. Liu, Thomas E. Anderson, and David A. Patterson. The Interaction of Parallel and Sequential Workloads on a Network of Workstations. In Proceedings of ACM SIGME- TRICS'95/PERFORMANCE'95 Joint International Conference on Measurement and Modeling of Computer Systems, pages , May [9] M. Baker, G. Fox, and H. Yau. Cluster Computing Review, Available at http ://citeseer.ist.psu.edu/article/baker95cluster.html. 7 [10] A. Barak and A. Braverman. Memory ushering in a scalable computing cluster. In Algorithms and Architectures for Parallel Processing, pages , [11] Amnon Barak and Oren La'adan. The MOSIX multicomputer operating system for high performance cluster computing. Future Gener. Comput. Syst., Volume 13 (Number 4-5) : pages , , 14 [12] Ricardo Bianchini and Ram Rajamony. Power and energy management for server systems. Computer, Volume 37 (Number 11) : pages 6874, [13] Nanette J. Boden, Danny Cohen, Robert E. Felderman, Alan E. Kulawik, Charles L. Seitz, Jakov N. Seizovic, and Wen-King Su. Myrinet : A Gigabit-per-Second Local Area Network. IEEE Micro, Volume 15 (1) : pages 2936, [14] Daniel P. Bovet and Marco Cesati. Understanding the Linux Kernel. O'Reilly, 3rd edition, November , 4 [15] Timothy Brecht. On The Importance of Parallel Application Placement in NUMA Multiprocessors. In Symposium on Experiences with Distributed and Multiprocessors Systems, pages 118, [16] Ron Brightwell and Lee Ann Fisk. Scalable parallel application launch on Cplant TM. In Supercomputing '01 : Proceedings of the 2001 ACM/IEEE conference on Supercomputing (CDROM), pages 4040, New York, NY, USA, ACM Press. 14 V

68 VI BIBLIOGRAPHIE [17] G. C. Buttazzo and J. A. Stankovic. RED : Robust Earliest Deadline scheduling. Technical report, Amherst, MA, USA, [18] N. Capit, G. Da Costa, Y. Georgiou, G. Huard, C. Martin, G. Mounie, P. Neyron, and O. Richard. A batch scheduler with high level components. In CCGRID '05 : Proceedings of the Fifth IEEE International Symposium on Cluster Computing and the Grid (CCGrid'05) - Volume 2, pages , Washington, DC, USA, IEEE Computer Society. 7 [19] IBM Corp. Tivoli Workload Scheduler Loadleveler home page. Available at http: //www-03.ibm.com/systems/clusters/software/loadleveler.html. 7 [20] Dror G. Feitelson. Job scheduling in multiprogrammed parallel systems. IBM Research Report RC (87657), aug [21] Dror G. Feitelson and Larry Rudolph. Coscheduling based on runtime identication of activity working sets. Int. J. Parallel Program., 23(2) :135160, [22] Eitan Frachtenberg, Dror G. Feitelson, Fabrizio Petrini, and Juan Fernandez. Flexible coscheduling : Mitigating load imbalance and improving utilization of heterogeneous resources. In IPDPS '03 : Proceedings of the 17th International Symposium on Parallel and Distributed Processing, page 85.2, Washington, DC, USA, IEEE Computer Society. 17 [23] Jérôme Gallard. écoulement de la charge sur le système à image unique Kerrighed : application au domaine de la biologie. Master's thesis, ENSSAT - Université de Rennes 1, Septembre , 52 [24] Douglas P. Ghormley, David Petrou, Steven H. Rodrigues, Amin M. Vahdat, and Thomas E. Anderson. GLUnix : A Global Layer Unix for a network of workstations. Software Practice and Experience, Volume 28 (Number 9) : pages , , 13 [25] Erik Hendriks. BProc : the Beowulf Distributed Process Space. In ICS '02 : Proceedings of the 16th international conference on Supercomputing, pages , New York, NY, USA, ACM Press. 11, 13 [26] Atsushi Hori, Hiroshi Tezuka, Yutaka Ishikawa, Noriyuki Soda, Hiroki Konaka, and Munenori Maeda. Implementation of Gang-Scheduling on Workstation Cluster. In Dror G. Feitelson and Larry Rudolph, editors, Job Scheduling Strategies for Parallel Processing, pages Springer-Verlag, [27] Cluster Resources Inc. Torque Resource Manager home page. Available as http: // 7 [28] James Patton Jones and Bill Nitzberg. Scheduling for parallel supercomputing : A historical perspective of achievable utilization. In IPPS/SPDP '99/JSSPP '99 : Proceedings of the Job Scheduling Strategies for Parallel Processing, pages 116, London, UK, Springer-Verlag. 9 [29] C. L. Liu and James W. Layland. Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment. Journal of the ACM, Volume 20 (Number 1) : pages 4661, [30] Dejan S. Milojicic;, Fred Douglis, Yves Paindaveine, Richard Wheeler, and Songnian Zhou. Process migration. ACM Comput. Surv., 32(3) :241299, [31] Christine Morin, Renaud Lottiaux, Georoy Vallée, Pascal Gallard, Gaël Utard, R. Badrinath, and Louis Rilling. Kerrighed : A single system image cluster operating system for high performance computing. In Euro-Par 2003, pages , , 14

69 BIBLIOGRAPHIE VII [32] Shailabh Nagar, Ajit Banerjee, Anand Sivasubramaniam, and Chita R. Das. A closer look at coscheduling approaches for a network of workstations. In SPAA '99 : Proceedings of the eleventh annual ACM symposium on Parallel algorithms and architectures, pages 96105, New York, NY, USA, ACM Press. 17 [33] John K. Ousterhout. Scheduling techniques for concurrent systems. IEEE Distributed Compter Systems, Available at http :// parashar/classes/ece572-papers/05/ps-ousterhout.pdf. 15 [34] Sung-Eun Choi Paul Ruth and Erik A. Hendriks. BJS : A Scalable, Fault-Tolerant Job Scheduler for Cluster Systems. Cluster 2002 Posters, [35] Gregory F. Pster. An introduction to the InniBand TM Architecture. In High Performance Mass Storage and Parallel I/O, pages pages [36] Rolf Riesen, Ron Brightwell, Lee Ann Fisk, Tramm Hudson, Jim Otto, and Arthur B. Maccabe. Cplant. In Proceedings of the Second Extreme Linux workshop at the 1999 USENIX Annual Technical Conference. 11, 13 [37] Louis Rilling. Ordonnancement global de processus dans les grappes de calculateurs, mise en oeuvre dans le système Gobelins. Rapport de stage de DEA, IFSIC, Université de Rennes 1, France, June , 8, 12, 17 [38] Étienne Rivière. Gestion dynamique d'applications parallèles à mémoire partagée au sein du système d'exploitation pour grappes Kerrighed. Rapport de stage de DEA, IFSIC, Université de Rennes 1, France, June , 40 [39] Edi Shmueli and Dror G. Feitelson. Backlling with lookahead to optimize the performance of parallel job scheduling. In Job Scheduling Strategies for Parallel Processing, pages , , 10 [40] Patrick Sobalvarro, Scott Pakin, William E. Weihl, and Andrew A. Chien. Dynamic coscheduling on workstation clusters. In IPPS/SPDP '98 : Proceedings of the Workshop on Job Scheduling Strategies for Parallel Processing, pages , London, UK, Springer-Verlag. 16 [41] A. C. Sodan. Loosely coordinated coscheduling in the context of other approaches for dynamic job scheduling : a survey : Research articles. Concurrent Computing : Practice Experience, Volume 17 (Number 15) : pages , , 16, 17 [42] David Talby and Dror G. Feitelson. Supporting priorities and improving utilization of the IBM SP scheduler using slack-based backlling. In IPPS '99/SPDP '99 : Proceedings of the 13th International Symposium on Parallel Processing and the 10th Symposium on Parallel and Distributed Processing, page 513, Washington, DC, USA, IEEE Computer Society. 10 [43] Debian Team. Debian le système d'exploitation universel. Available at debian.org. 46 [44] Douglas Thain, Todd Tannenbaum, and Miron Livny. Distributed computing in practice : the condor experience : Research articles. Concurrent Computing : Practice Experience, Volume 17 (Number 2-4) : pages , [45] Georoy Vallée. Conception d'un ordonnanceur de processus adaptable pour la gestion globale des ressources dans les grappes de calculateurs : mise en oeuvre dans le système d'exploitation Kerrighed. PhD thesis, IFSIC, Université de Rennes 1, France, March , 22 [46] Georoy Vallée, Christine Morin, Jean-Yves Berthou, and Louis Rilling. A new approach to congurable dynamic scheduling in clusters based on single system image

70 VIII BIBLIOGRAPHIE technologies. In IPDPS '03 : Proceedings of the 17th International Symposium on Parallel and Distributed Processing, page 91, Washington, DC, USA, IEEE Computer Society. 14 [47] Wikipedia. Gigabit ethernet. Available at Gigabit_Ethernet. 4