En plus des probl´ematiques classiques d’interop´erabilit´e des ressources et de gestion de la s´ecurit´e, les probl´ematiques li´ees `a la r´epartition des ressources prennent ici une place cruciale. Effectivement, de telles fusions auraient un impact profond sur le couple infrastructure mat´erielle / superstructure logicielle. Ils se trouveraient subitement modifi´es tant dans les faits : extension de la plateforme physique, augmentation du nombre de ressources logiques ; que dans leur finalit´es : multiplication des objectifs, modification des probl´ematiques principales, introduction de compromis.
On peut remarquer que, dans une certaine mesure, le monde de l’informatique n’´echappe pas aux lois de l’´evolution ´edict´ees par Darwin : les environnements apparaissent et disparaissent au gr´e des besoins et des contraintes des contextes. Le maˆıtre-mot dans le Darwinisme est l’adaptation. C’est pourquoi il est d’une importance majeure de concevoir des outils de gestion qui soient tout `a la fois g´en´eriques, adaptables et adaptatifs, et ce avec un minimum d’intervention utilisateur. Ces outils, loin d’uniquement simplifier la vie des acteurs des grilles, peuvent en r´ealit´e permettre d’assurer la p´erennit´e des environnements. Bien que les solutions trop sp´ecifiques remplissent pleinement leur rˆole et ce de fa¸con (potentiellement) tr`es optimale, elles ne survivent g´en´eralement pas `a un changement de contexte ou de probl´ematique, ou alors au prix d’incommensurables efforts manuels d’´evolution. Les solutions g´en´eriques en revanche sont caract´eris´ees par une tr`es grande adaptabilit´e, ne demandant pas (ou peu) d’effort lors des ´evolutions. On peut prendre l’exemple d’Internet qui perdure depuis plusieurs d´ecennies malgr´e une ´evolution constante des technologies et de son utilisation. Compte tenu de la vitesse `a laquelle le monde informatique est d´evelopp´e, ces ´evolutions ne rel`event mˆeme plus d’un pari mais d’un ´etat de fait, devant d´esormais ˆetre pris en compte dans la conception des plateformes.
1.6 Synth`ese
Dans ce chapitre, nous avons pr´esent´e le contexte dans lequel se situe notre th`ese. Les grilles informatiques sont caract´eris´ees par de grandes dynamicit´es et h´et´erog´en´eit´es qui se retrouvent tant au niveau de l’infrastructure mat´erielle, qu’`a ceux de la superstructure logicielle, des utilisateurs et des usages, et ce dans l’optique de s’acquitter de tˆaches tr`es intensives. De plus, on trouve au cœur de la notion de grille, la notion d’organisation virtuelle qui encadre les collaborations inter-organisations, permettant l’exploitation des grilles dans des contextes tant scientifiques qu’industriels.
Nous avons ensuite pr´esent´e trois environnements d´eriv´es des grilles et montr´e leurs besoins en terme de probl´ematiques li´ees `a la r´epartition des ressources :
– les grilles et architectures orient´ees services au travers du projet GGM.
– les grilles pervasives au travers d’un sc´enario de r´eponse `a une situation d’urgence. – les organisations virtuelles inter-grilles au travers d’un sc´enario m´edical.
Leurs caract´eristiques et objectifs communs impliquent qu’ils puissent ˆetre amen´es `a fusionner, et ce de fa¸con potentiellement transparente. De telles fusions engendrent des ´evolutions dramatiques des environnements.
Des solutions de gestion g´en´eriques des probl´ematiques li´ees `a la r´epartition des ressources doivent donc ˆetre d´evelopp´ees afin de supporter ces ´evolutions et d’assurer la p´erennit´e des plateformes.
Dans le chapitre suivant, nous ´etudions en d´etail les diff´erents probl`emes de r´epartition des res-sources qui se rencontrent dans les grilles.
2
Les probl´ematiques de la gestion de distribution
Dans ce chapitre, nous nous int´eressons aux diff´erents probl`emes de r´epartition des ressources. Ceux-si se retrouvent dans chacun des environnements de grille pr´esent´es. Nous utilisons cette pr´ esen-tation pour identifier les probl´ematiques connexes `a la r´esolution de ces probl`emes, ainsi les contraintes et caract´eristiques des syst`emes de r´esolution. Nous montrons ´egalement le caract`ere critique de ces probl`emes, d’un cˆot´e pour les performances de la plateforme et d’un autre pour le travail des d´ eve-loppeur et les retours sur investissement.
On peut identifier trois probl`emes classiques et quotidiens : le d´eploiement de ressources, pr´esent´e Section 2.1 ; la s´election de ressource, ´etudi´e Section 2.2 ; et la composition de ressources, d´evelopp´ee 2.3. En plus de ces cas classiques, la r´epartition des ressources peut intervenir de fa¸con sp´ecifique dans des contextes bien particuliers. Il est impossible de pr´esenter ces cas qui d´ependent enti`erement du contexte applicatif, mais nous traiterons Section 2.4 de l’agr´egation dans un entrepˆot de donn´ees distribu´e, qui est un cas embl´ematique rencontr´e dans le projet GGM.
2.1 Probl`eme g´en´erique du d´eploiement de ressources
Cette gestion incombe soit aux administrateurs des ressources, soit aux services en charge de la gestion de certaines ressources. Le probl`eme du d´eploiement de ressources n’est pas ici de d´eployer `
a proprement parler les ressources en les mettant physiquement `a disposition sur des hˆotes donn´es, mais plutˆot de d´ecider o`u ces ressources doivent ˆetre d´eploy´ees afin d’optimiser un aspect donn´e.
2.1.1 Pr´esentation du point de vue de l’infrastructure
La Figure 2.1 montre un exemple d’une telle situation : client1.athome.com dispose d’une res-source R (une donn´ee, un service ou autre) qu’il peut d´eployer sur trois hˆotes mis `a sa disposition dans le domaine grid.com afin de permettre `a certains clients du domaine athome.com d’y acc´eder. Il faut noter ici que la dichotomie client/hˆote n’est montr´ee que pour illustration. En r´ealit´e, les clients peuvent (et le font probablement) tr`es bien appartenir `a la grille, voire ˆetre confondus avec des h´ebergeurs potentiels.
Fig. 2.1 – Le probl`eme du d´eploiement vu depuis l’infrastructure
2.1.2 Pr´esentation du point de vue de la superstructure GGM
Fig. 2.2 – Le probl`eme du d´eploiement vu depuis la superstructure GGM
La Figure 2.2 illustre le probl`eme du d´eploiement d’un fichier vu depuis la superstructure GGM : (1) un client, qui peut ˆetre un utilisateur ou un autre composant logiciel de la superstructure, ´emet une demande de stockage d’un fichier et en fournit une description au service de caches collaboratifs ; (2) ce dernier ´evalue les diff´erentes solutions de stockage en fonction de crit`eres fournis par l’utilisateur et d’informations disponibles dans le fichier ou dans les informations de surveillance du cache ; (3) le fichier est stock´e sur le ou les hˆotes s´electionn´es.
2.1 Probl`eme g´en´erique du d´eploiement de ressources 21
2.1.3 Analyse
On peut identifier deux probl´ematiques li´ees `a ce d´eploiement : d’abord la r´eplication et ensuite
le placement.
La r´eplication consiste `a d´ecider du nombre d’instances, ou r´eplicas, d’une mˆeme ressource devant ˆ
etre d´eploy´ee sur le r´eseau. Dans notre illustration, il s’agit de d´ecider si une, deux ou trois instances doivent ˆetre d´eploy´ees. R´epliquer une ressource permet :
• d’am´eliorer sa disponibilit´e, par exemple en cas de panne de l’hˆote d’une instance, une autre
est imm´ediatement disponible.
• de r´eduire ses temps d’acc`es, en permettant de couvrir tout le r´eseau afin que tout client aie
une instance `a proximit´e.
• d’´equilibrer les charges r´eseau et de calcul, en permettant `a plusieurs hˆotes de fournir la mˆeme
ressource simultan´ement.
En contrepartie, la r´eplication implique certains aspects n´egatifs. En effet augmenter le nombre d’instances implique :
• une augmentation des charges disque, qui sont de pures pertes lorsque les ressources ne sont
pas utilis´ees.
• une perte de contrˆole sur les ressources, impliquant, entre autre, plus de travail afin d’assurer
leur consistance, leur s´ecurit´e et leur administration.
Identifier le nombre d’instances optimal pour une ressource donn´ee est donc un probl`eme de balance entre besoins et contraintes, gains et perte, qui peut s’av´erer extrˆemement sensible selon les caract´eristiques de la ressource. En effet, pour un contenu web de faible taille et n´ecessitant peu de contrˆole, par exemple une simple image non commerciale, une r´eplication massive sur de nombreux serveurs est tout `a fait envisageable. En revanche, pour un contenu vid´eo prot´eg´e, de grande taille et accessible en flux ce probl`eme devient critique : trop peu d’instances risquent de l´eser le client final qui n’est pas prˆet `a accepter une perte de qualit´e de service pour un contenu payant, alors que de trop nombreuses instances impliquent une utilisation inutile des disques et surtout un risque pour le propri´etaire qui ne veut pas que le contenu ´echappe `a son contrˆole. Ce probl`eme est d’autant plus difficile qu’il est intimement li´e aux demandes utilisateur et revˆet donc, dans bien des cas, un caract`ere dynamique.
Le deuxi`eme probl`eme consiste, une fois que le nombre d’instances est d´efini, `a d´ecider des hˆotes o`u doivent ˆetre d´eploy´ees ces instances. Alors que de bonnes d´ecisions permettent non seulement d’assurer la qualit´e de service des utilisateurs finaux, mais aussi l’´equilibrage des diff´erentes charges, de mauvaises d´ecisions peuvent s’av´erer catastrophiques en tous points de vue. Dans notre illustration, il s’agit de d´ecider quels hˆotes du domaine grid.com sont les plus `a mˆeme d’h´eberger les instances.
Ces deux probl`emes d´ependent de plusieurs aspects : – l’emplacement des clients et le nombre de leurs requˆetes
– les caract´eristiques de la ressource (taille, type d’acc`es, sensibilit´e, etc.)
– les performances de la portion d’infrastructure mat´erielle concern´ee (stockage, calcul, commu-nication, etc.)
– le ou les aspects `a optimiser (disponibilit´e, temps d’ex´ecution, ´equilibrage des charges, coˆuts de maintenance, coˆuts financiers, et.)
La prise en compte de ces diff´erents aspects et leur diversit´e (non exhaustive puisque tout utilisateur doit pouvoir consid´erer ses propres objectifs et besoins) rendent ce probl`eme particuli`erement difficile face `a la contrainte de g´en´ericit´e.