Data Interactive Engineering Toolbox (DIET) [29, 5] est un intergiciel de grille reposant sur le paradigme d’appels `a distance Grid-RPC. Il propose une interface de cr´eation de pro-grammes client/serveur adapt´e `a la grille en rendant transparent la complexit´e de celle-ci. Il permet toutefois aux utilisateurs de d´efinir des politiques d’ordonnancement avanc´ees grˆace `a un syst`eme de plugins d’ordonnancement, au niveau du serveur, ou mˆeme au niveau de l’intergiciel depuis sa derni`ere version.
2.8.1 Architecture de DIET
Une architecture DIET est compos´ee de trois ´el´ements principaux :
– Les clients : Ce sont des applications qui font l’interface entre un utilisateur d´esirant effectuer un appel de service sur la grille et l’intergiciel.
– Les “Server Daemons”(SeD) : Ce sont les serveurs qui fournissent les services `a la grille. Un SeD encapsule un serveur de calcul. Il peut ˆetre par exemple plac´e sur le point d’entr´ee d’une machine parall`ele (super-calculateur, cluster etc.) ou simplement sur une machine individuelle du r´eseau. Un SeD stocke la liste des services qu’il offre aux utilisateurs, mais aussi des informations sur sa charge et ses capacit´e mat´erielles (nombre de processeurs, charges des processeurs, quantit´e de m´emoire install´ee etc.) – Les agents : Ce sont les ´el´ements de DIET qui effectuent la s´election du ou des serveurs
utilis´es pour l’ex´ecution d’un service. Ils sont interconnect´es suivant une topologie d’arbre dont le sommet est un “agent maˆıtre” (Master Agent ou MA) qui sera seul contact´e par les applications clientes.
La figure 2.16 pr´esente l’architecture globale d’un d´eploiement de DIET. Il est `a noter que plusieurs architectures DIET peuvent ˆetre reli´ees par des liaisons pair-`a-pair r´ealis´ees entre plusieurs MA. Cette architecture permet de distribuer la charge des diff´erentes tˆaches de l’intergiciel sur plusieurs machines, assurant ainsi le passage `a l’´echelle de la grille des applications d´evelopp´ees avec DIET.
La soumission d’une requˆete dans DIET se d´eroule en plusieurs ´etapes :
L’´etape “requˆete” : Le client soumet une requˆete pour un service au Master Agent. Un
service dans DIET est identifi´e par une chaˆıne de caract`ere (par exemple ”addition”), mais aussi par le type et le nombre de ses param`etre (par exemple [”int”, ”int”, ”int”]). Ainsi, plusieurs services de mˆeme nom, mais prenant des param`etres diff´erents peuvent cohabiter dans une mˆeme hi´erarchie. Par exemple, les services (”addition”, integer, integer, integer) et
(”addition”, float, float, float) permettront d’effectuer l’addition de deux entiers ou de deux
flottants, sans qu’il y ait confusion au moment de la requˆete.
L’´etape de recherche du service : Le Master Agent fait suivre la requˆete `a l’ensemble des
Local Agents et/ou SeDs dont il a la charge. Lorsqu’un Local Agent rec¸oit une requˆete, il interroge `a son tour les SeDs et agents auxquels il est connect´e. Lorsqu’un SeD rec¸oit une requˆete, deux cas de figure se pr´esentent :
MA
MA MA MA
MA MA
LA LA LA
LA
SeD SeD SeD SeD SeD SeD SeD
Plusieurs MA peuvent interagir pour trouver un SeD proposant un service.
À chaque niveau de la hiérarchie plusieurs SeDs et/ou plusieurs agents peuvent se connecter à celle-ci.
Les SeDs déclarent un ou plusieurs services auprès d'un agent. Le client adresse une requête au Master Agent Le MA retourne une liste ordonnée de SeDs offrant le service demandé Le client envoie
alors directement les paramètres de son
problème au SeD
FIG. 2.16 – Architecture de DIET
– Le SeD ne propose pas le service demand´e : Il retourne une r´eponse n´egative `a l’agent qui l’a interrog´e.
– Le SeD propose le service demand´e : Il retourne une r´eponse positive accompagn´ee d’un certain nombre de caract´eristiques qui le concerne afin de permettre `a l’agent d’effectuer la s´election du “meilleur” serveur pouvant traiter la requˆete.
L’´etape d’ordonnancement : Les agents rec¸oivent les liste des r´eponses positives `a la
requˆete obtenues depuis le niveau inf´erieur de la hi´erarchie. Il proc`ede alors `a la s´election des “meilleurs” serveurs parmis tous ceux pr´esent dans une de ces listes. Ils renvoient alors cette nouvelle s´election au niveau sup´erieur de la hi´erarchie. Cette ´etape est d´etaill´ee dans la section 2.8.2 consacr´ee aux diff´erents modes d’ordonnancement propos´es par DIET.
L’´etape de r´esolution : Lorsque le Master Agent rec¸oit les listes des serveurs s´electionn´es
pour la r´esolution du probl`eme, il effectue une derni`ere s´election parmi elles et retourne la liste obtenue au client qui a soumis la requˆete. Le client peut alors s’adresser directement au meilleur SeD s´electionn´e pour lui soumettre les param`etres du probl`eme `a r´esoudre. Le SeD proc`ede alors `a l’ex´ecution du service en utilisant ces param`etres et transmet le r´esultat au client. Cette derni`ere ´etape peut ˆetre r´ealis´ee de mani`ere asynchrone. Ainsi, pendant la dur´ee d’ex´ecution de la tˆache soumise au SeD, le client peut contacter d’autres serveurs pour la r´esolution d’autres probl`emes ou du mˆeme probl`eme avec d’autres param`etres.
2.8.2 L’ordonnancement dans DIET
Dans DIET, ce sont les agents qui g`erent les tˆaches d’ordonnancement. Plusieurs ´etapes se d´eroulent depuis la soumission d’une requˆete jusqu’`a l’ex´ecution de la tˆache. La figure 2.17 illustre le fonctionnement de ces diff´erentes ´etapes.
– Le client soumet une requˆete pour un service aupr`es du Master Agent. (´etape 1) – Le Master Agent fait suivre la requˆete `a l’ensemble des Local Agents auxquels il est
reli´e. Chacun d’entre eux, proc`ede de la mˆeme mani`ere avec les agents auxquels il est reli´e jusqu’`a atteindre un Server Daemon. (´etape 2)
– Les Servers Daemons qui offrent le service demand´e par la requˆete collectent alors des informations sur leur ´etat actuel (charge processeur, m´emoire etc.) en fonction du type d’ordonnancement choisi. Ils retournent alors un vecteur de valeurs `a l’agent appelant. Suivant les services choisis lors de la compilation de DIET, des estimations de perfor-mances peuvent ´egalement ˆetre transmises par l’interm´ediaire de ce vecteur. (´etape 3)
– En fonction du type d’ordonnancement d´efini par le SeD ou par l’agent, les r´eponses obtenus sont aggr´eg´ees en une liste de r´eponse ordonn´ee et de taille limit´ee. La liste ainsi construite ne contient alors que les “meilleurs” serveurs choisis en fonction de la m´etrique d’ordonnancement choisie. Cette liste est alors renvoy´ee `a l’agent de niveau sup´erieur dans la hierarchie DIET qui proc´edera `a la mˆeme s´election des serveurs. (´etape 4)
– Lorsque la liste des serveurs atteint le Master Agent, celui-ci proc`ede `a la derni`ere aggr´egation/s´election des serveurs et retourne celle-ci au client ayant soumis la requˆete. (´etape 5)
– Le client s´electionne alors un ou plusieurs serveurs parmi la liste obtenue et soumet directement les tˆaches `a ceux-ci. (´etape 6)
1 MA LA requête 2 MA LA LA requête requête 3 SeD SeD SeD LA LA
réponse réponse réponse
4
LA
réponse 1 réponse 2 réponse 3
cpu mem time cpu mem time cpu mem time
cpu3 > cpu1 > cpu2
cpu mem time réponse 3
cpu mem time réponse 1
cpu mem time réponse 2
5 cpu m time cpu m time cpu m time MA réponses réponses réponses cpu m time cpu m time cpu m time cpu m time cpu m time cpu m time cpu mem time
cpu mem time cpu mem time
6
cpu mem time cpu mem time cpu mem time cpu mem time cpu mem time
Liste ordonnée de SeDs
FIG. 2.17 – ´Etapes de soumission d’une tˆache dans DIET
Le m´ecanisme d’ordonnancement ainsi effectu´e diff`ere suivant le type d’ordonnance-ment choisi. En effet, DIET dispose de politiques d’ordonnanced’ordonnance-ment par d´efaut utilis´ees lorsque le d´eveloppeur du SeD n’a pas d´efini de politique sp´ecifique `a son service et que les agents n’ont pas ´et´e configur´es pour utiliser un module d’ordonnancement externe. Dans le deuxi`eme cas, le SeD adresse aux agents des priorit´es quant au classement des r´eponses. Par exemple, on peut choisir de classer celles-ci en fonction de la puissance du proces-seur par ordre d´ecroissant de valeur puis en fonction de la charge actuelle du syst`eme par ordre d´ecroissant de valeur. Pour ce faire, DIET propose par l’interm´ediaire de l’extension CoRI (Collectors of Resource Information) [27] toute une liste de caract´eristiques utilisables
comme m´etrique pour l’ordonnancement : – Le pourcentage d’occupation processeur. – La quantit´e de m´emoire disponible.
– Le nombre de processeurs install´es sur la machine.
– La fr´equence de fonctionnement de chacun des processeurs de la machine. – La quantit´e de m´emoire install´ee sur la machine.
– Le pourcentage moyen d’occupation des processeurs.
– La “puissance” de chacun des processeurs exprim´ee en BogoMips. – La taille de la m´emoire cache de chaque processeur.
– La taille totale du disque de la machine. – La quantit´e d’espace disque libre.
– Les temps d’acc`es au disque en lecture et en ´ecriture.
Enfin, DIET offre la possibilit´e d’´ecrire des modules externes red´efinissant compl`etement la m´ethode d’aggregation des agents. Ces modules, seront alors charg´es dynamiquement `a l’ex´ecution de l’agent si le SeD en fait la demande. Ce dernier m´ecanisme permet alors de classer les r´eponses en fonction d’autres param`etres que ceux fournis par les SeDs (nombre d’ex´ecutions sur un cluster, param`etres externes ne pouvant pas ˆetre obtenus au niveau du SeD etc). L’organisation des diff´erents ordonnanceurs dans le code de DIET est donn´ee dans la figure 2.18.
aggregate(corba_response_t* aggrResp, size_t max_srv, const size_t nb_responses,
const corba_response_t* responses) ... GlobalScheduler aggregate(...) ... RandScheduler aggregate(...) ... FastScheduler aggregate(...) ... MaxScheduler aggregate(...) ... RRScheduler aggregate(...) ... MinScheduler aggregate(...) ... NWSScheduler aggregate(...) ... Scheduler DIET_AGG_PRIORITY ou DIET_AGG_DEFAULT DIET_AGG_DEFAULT sans estimations FAST/NWS DIET_AGG_DEFAULT sans FAST/NWS et sans timestamp DIET_AGG_DEFAULT avec estimations de performances FAST/NWS DIET_AGG_PRIORITY avec une métrique choisie
par l'utilisateur
DIET_AGG_USER
Chargement d'un module externe pour l'instanciation de l'ordonnanceur.
aggregate(...) ... NewScheduler aggregate(...) ... UserScheduler NewScheduler.cc NewScheduler.hh NewScheduler.so
FIG. 2.18 – Organisation des classes d’ordonnancement dans DIET.
Par ailleurs, ce m´ecanisme permet de d´efinir des politiques d’ordonnancement diff´erentes pour chaque agent. Il sera ainsi possible de choisir un ordonnancement Round-Robin pour chaque cluster g´er´e par un agent et de choisir une autre politique quant au choix
Cluster 2 Cluster 1 MA LA SeD SeD SeD 1 2 3 L'agent effectue un Round-Robin sur les
SeDs LA SeD SeD SeD 1 2 3 L'agent effectue un Round-Robin sur les
SeDs L'agent a chargé le module d'ordonnancement
Round-Robin
L'agent a chargé le module d'ordonnancement Round-Robin
Cluster 1 : 40% des requêtes Cluster 2 : 60% des requêtes
L'agent a chargé le module d'ordonnancement par proportions
1.1 1.2 1.3 2.1 2.2 2.3 SeD 1.1 SeD 1.2 SeD 1.3 SeD 1.1 SeD 1.2 SeD 1.3 SeD 1.1 SeD 1.2 SeD 1.3 SeD 1.1 SeD 2.1 SeD 2.2 SeD 2.3 SeD 2.1 SeD 2.2 SeD 2.3 SeD 2.1 SeD 2.2 SeD 2.3 SeD 2.1 SeD 1.1 SeD 1.2 SeD 1.3 SeD 1.1 SeD 2.2 SeD 2.3 SeD 2.1 SeD 2.2 SeD 2.3 SeD 2.1
FIG. 2.19 – Politiques d’ordonnancement au niveau des agents.
du cluster au niveau du master agent. La figure 2.19 pr´esente un tel cas de figure.