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 35042 RENNES Cedex - France
Téléphone : 02 99 84 71 00
Table des matières
Résumé . . . V Mots-Clés . . . V Abstract . . . V Keywords . . . V
Introduction 1
1 État de l'art 3
1.1 Terminologie . . . 3
1.1.1 Notion de tâche . . . 3
1.1.2 Les ressources . . . 3
1.1.3 L'ordonnancement . . . 4
1.2 Les grappes gérées par les systèmes à exécution par lots . . . 7
1.2.1 Ordonnancement de tâches : les systèmes à exécution par lots . . . . 7
1.2.2 Diérentes politiques d'ordonnancement . . . 8
1.3 Les grappes gérées avec les systèmes à image unique . . . 11
1.3.1 Introduction aux systèmes à image unique . . . 11
1.3.2 GLUnix . . . 13
1.3.3 BProc . . . 13
1.3.4 CPlant . . . 13
1.3.5 MOSIX . . . 14
1.3.6 Kerrighed . . . 14
1.4 Ordonnancement de tâches communicantes . . . 15
1.4.1 Le Gang-Scheduling . . . 15
1.4.2 Le Co-Scheduling . . . 16
1.4.3 Le co-ordonnancement faiblement couplé (loosely coordinated Co- Scheduling) . . . 17
1.4.4 Le co-ordonnacement exible (Flexible Coscheduling) . . . 17
1.5 Bilan . . . 18
2 Objectifs du stage 21 2.1 Présentation des problèmes à traiter . . . 21
2.1.1 Contexte . . . 21
2.1.2 Caractéristiques d'un ordonnanceur . . . 22
2.2 Objectifs . . . 22
2.3 Approche . . . 23
2.4 Contributions . . . 23
3 Conception d'un ordonnanceur global congurable 25 3.1 Infrastructure . . . 25
3.2 La politique globale d'ordonnancement . . . 25
3.3 Les collections . . . 27 I
3.3.1 La collection de ressources . . . 27
3.3.2 La collection de processus . . . 27
3.4 Agent de surveillance . . . 27
3.4.1 Surveillance des conditions d'utilisation des ressources . . . 27
3.4.2 Recherche d'actions correctrices . . . 28
3.5 Agent d'actions . . . 29
3.5.1 Action nécessitant une simulation . . . 29
3.5.2 Réalisation de l'action . . . 30
3.6 Modèle de priorité . . . 30
3.6.1 Exemple introductif. . . 31
3.6.2 Extension. . . 31
3.6.3 Bilan. . . 32
3.7 Présentation des algorithmes conçus . . . 32
3.7.1 Initialisation des centres de décision . . . 32
3.7.2 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 35 4.1 Démarrage des tâches avec priorité . . . 35
4.1.1 Politique . . . 35
4.1.2 Écriture de la politique . . . 35
4.2 Économie d'énergie . . . 38
4.2.1 Politique . . . 38
4.2.2 Écriture de la politique . . . 38
4.2.3 Filtre sur les processus . . . 39
4.3 Gestion dynamique d'applications parallèles à mémoire partagée . . . 39
4.3.1 Politique . . . 40
4.3.2 Écriture de la politique . . . 40
5 Mise en ÷uvre 43 5.1 Ordonnanceur modulaire . . . 43
5.2 Mise en ÷uvre de l'ordonnancement dans le cadre de Kerrighed . . . 43
5.2.1 Spécicités du système à image unique Kerrighed . . . 45
5.2.2 Mise en ÷uvre de l'ordonnanceur . . . 45
5.2.3 Gestion des unités . . . 49
5.3 Évaluations . . . 49
5.3.1 Conguration équilibrage mémoire . . . 50
5.3.2 Conguration équilibrage processeur . . . 51
5.3.3 Conguration avec priorité équilibrage de la charge processeur puis de la charge réseau . . . 52
Conclusion 57
Bibliographie V
TABLE DES MATIÈRES III
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
Introduction
De nos jours, aussi bien dans l'industrie que dans les laboratoires de recherche, la puis- sance 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 supercalcu- lateurs. 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 virtua- lisation 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'ordonnance- ment 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'infra- structure 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'admi- nistrateur 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'or- donnancement 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 ordonnan- ceur. Dans le cinquième chapitre, nous décrivons la mise en ÷uvre du système et présentons
1
quelques évaluations de notre prototype. Enn nous concluons et donnons quelques pers- pectives de travail.
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
1.1.1 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âche1 é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 commu- niquent 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.
1.1.2 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).
1Dans la littérature, on trouvera également la terminologie application ou encore application parallèle.
3
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 ac- cè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 traite- ment 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].
1.1.3 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'or- donnanceur 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 monoproces- seur. 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 or- donnancent 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
1.1. TERMINOLOGIE 5
Fig. 1.1 Représentation des interactions entre les tâches, les processeurs et l'ordonnan- ceur.
Fig. 1.2 Ordonnancement temporel (plusieurs processus pour un seul processeur).
de contexte2 (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 1.2.2.
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
2Soit 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].
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 che- vronné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'or- donnanceur 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.
1.2.1 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
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 : cer- taines 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.
1.2.2 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 stop- per 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'ordonnan- cement [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'avan- tage 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].
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. Lors- qu'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 (maximi- sation 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.
LOS - Lookahead Optimizing Scheduler [39]. LOS est un algorithme d'ordonnance- ment 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 dqui 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 ins- tant ttel 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 appli- cation 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.
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éri- table 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 calcu- lateurs 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
1.3.1 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 ps3 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 pro- cessus, mais également celle des ressources. Ainsi, ils fournissent à l'utilisateur l'impression
3La commande ps des systèmes Unix permet de lister l'ensemble des processus présent sur le système.
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 or- donnanceurs 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éemp- tif), 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 pro- cessus vers un autre n÷ud moins chargé (technique ecace pour une grappe qui est en moyenne faiblement chargée),
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.
1.3.2 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.
1.3.3 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 etnn÷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 contrai- rement à 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).
1.3.4 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 :
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 paral- lè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.
1.3.5 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.
1.3.6 Kerrighed
Kerrighed est un système d'exploitation à image unique qui cherche à orir perfor- mance, haute disponibilité et simplicité d'utilisation [31].
Kerrighed propose un ordonnancement global [46] constitué d'un contrôleur, d'analy- seurs 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 lo- cal 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
1.4. ORDONNANCEMENT DE TÂCHES COMMUNICANTES 15 dernier reçoit les informations de tous les analyseurs locaux et possède ainsi une vision glo- bale 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 pos- sible 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 proces- sus 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).
1.4.1 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 eux4.
Une méthode pour implémenter ce changement de contexte sur l'ensemble des proces- seurs 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
4Il 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é.
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 sous- ensembles 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.
1.4.2 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 entre- eux [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-
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.
1.4.3 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 synchronisa- tion 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 (spin- blocking) c'est à dire que le processeur attend l'arrivée d'un message ou une synchro- nisation 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.
1.4.4 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] :
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'ordon- nancer 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-
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éter- miné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.
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 multi- processeur. 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éplace- ment 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
2.1.1 Contexte
Comme vu en partie 1.1.3 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éa- tion de processus de manière diérée (fork_delay, la suspension/redémarrage des proces- sus). 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
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.
2.1.2 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 trai- ter les trois points décrit ci-dessus, il n'existe pas de politiques d'ordonnancement univer- selles 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 res- sources 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'ordonnan- cement 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 virtua- lisation 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 pro- cessus 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 sys- tè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 com- plé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égu- lation 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 proces- seur 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 1.3.1 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,
2.3. APPROCHE 23 équilibrer la charge entre les n÷uds en prenant en compte les spécicités de la poli-
tique 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 particu- liè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.
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'ordonnan- ceur. 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 pa- ragraphes 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
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 poli- tiques é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 de- vons 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
