HAL Id: tel-00134949
https://tel.archives-ouvertes.fr/tel-00134949
Submitted on 6 Mar 2007
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of
sci-entific research documents, whether they are
pub-lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
grappes
Samuel Richard
To cite this version:
Samuel Richard. Simulation et conception de services déportés sur grappes. Automatique / Robotique.
INSA de Toulouse, 2006. Français. �tel-00134949�
Préparée au
Laboratoire d'Analyse et d'Ar hite ture des Systèmes du
CNRS
Envuede l'obtention du
Do torat de l'Institut National des S ien es Appliquées de Toulouse Spé ialitéSystèmes Informatiques
par
Samuel Ri hard
Titre de lathèse :
Simulation et on eption de servi es déportés sur grappes.
Soutenue le9Juin 2006 devant lejury:
M. : Germain GARCIA Président
MM. : Van-Dat Cung Rapporteurs
Mi hel Daydé
MM. : Bertrand PEREZ Examinateurs
MM. : Jean-Marie GARCIA Dire teurs dethèse
Les travaux présentés dans e manus rit sont l'aboutissement de trois années et demi d'études réalisées au Laboratoire d'Analyse et d'Ar hite ture des Systèmes (LAAS-CNRS) dansle groupe Réseauxet Systèmesde Télé ommuni ations (RST).
Je tiens à exprimer toute ma re onnaissan e à Messieurs Jean-Claude Laprie et Malik Ghallab, su essivement dire teurs du laboratoire, pour m'avoir a ueilli au LAAS et avoir mis à madispositionles moyensné essaires àla réalisationde mes travaux.
Je remer ie Messieurs Jean-Marie Gar iaet ThierryMonteil pour m'avoir oert la possi-bilité de dé ouvrir lemondede lare her he et avoir en adrémes travaux.
Jesuistrèsre onnaissantenversMessieursVan-DatCungetMi helDaydéd'avoira epté d'être lesrapporteursde ette thèse.Je les remer ie toutparti ulièrement.
Je remer ie MessieursGermain Gar ia, et BertrandPerezd'avoira epter de fairepartie de monjury dethèse.
Je tiens à remer iertout parti ulièrement Olivier Brunpour sa ompéten e sonavis tou-joursé lairéetDavidGau hardpourses ompéten este hniquesetsadisponibilité.Leuraide m'a étéd'un grand soutien.
Je n'oublie pas les bons moments passés au sein du groupe RST et en remer ie tous les membres. Je remer ie tout parti ulièrement les thésards et les stagiaires pour leur bonne humeur :Bernard, Cédri , Charles,Cyril,Eri , Erika,Fran k,François,Hassan,Mi kael, Pa-tri ia, Philippe...
Mer iaussiàtouslesamisquim'ontsoutenudurant esannées,soitdire tementauLAAS (Ni olas, Vin ent...)soit àl'extérieurdulaboratoire: Magali,Sophie,Fran k, Ni olas,Cyril, Hervé, Christine, Estelle,Stéphane, Mathieu...
En n, mes derniers remer ieront vont à mes pro hes qui m'ont toujours a ompagné et soutenu danslesbonsmoments, omme danslespériodesdi iles.
1 Introdu tion. 1
1.1 La gestiondesressour es . . . 1
1.2 Les appli ations on ernées . . . 2
1.3 Plan delathèse . . . 3
2 Les on epts de grappes et de grilles. 5 2.1 Introdu tion . . . 5
2.2 Grappeset Grilles . . . 6
2.2.1 Dé nitions . . . 6
2.2.2 Diérentes visionsd'uneGrille . . . 7
2.3 Les grillesde al ul . . . 8
2.3.1 Obje tifsdu "grid omputing" . . . 8
2.3.2 Problèmes inhérentsà lagestiond'une grillede al ul . . . 9
2.3.3 Ar hite turetype d'unegrille de al ul . . . 11
2.4 Domaines d'appli ation et exemples. . . 12
2.5 Con lusion. . . 13
3 Les outils existants. 15 3.1 Introdu tion . . . 15
3.2 Outils d'observations . . . 16
3.2.1 Ganglia . . . 16
3.2.2 NetworkWeather Servi e . . . 17
3.3 Gestionnaires de Grilles . . . 17
3.3.1 Globus . . . 17
3.3.2 OGSAet lesGridServi es . . . 22
3.3.3 Sun GridEngine. . . 24
3.3.4 Legion . . . 26
3.4 Environnements lient/serveur pour lesGrilles. . . 27
3.4.1 Ninf : . . . 28
3.4.2 NetSolve : . . . 29
3.4.3 DIET . . . 30
3.5 Con lusion. . . 32
4 La gestion de ressour es dans Aroma. 33 4.1 Introdu tion . . . 33
4.3 Ar hite ture générale dugestionnaire deressour es . . . 36
4.3.1 Les diérentsniveauxhiérar hiques . . . 36
4.3.2 Ar hite turelogi ielle . . . 36
4.3.3 Exemple d'ar hite ture. . . 38
4.4 Système de ommuni ation . . . 38
4.4.1 Prin ipes debase deJini . . . 38
4.4.2 Le servi eJini Aroma . . . 41
4.4.3 Communi ations entre Resour e Unit . . . 42
4.5 Les diérentesmodules d'Aroma . . . 43
4.5.1 Le module olle teur (wat her) . . . 44
4.5.2 Représentation de l'étatde lagrille : lemodule ar hite ture. . . 45
4.5.3 Le module ordonnan eur. . . 47
4.5.4 Le module lan eur. . . 47
4.6 Chargement dynamiquede apteursde harge. . . 47
4.6.1 Prin ipe utilisé . . . 48
4.6.2 L'observateurde ressour es . . . 49
4.6.3 Le module destatistiques . . . 49
4.7 Toléran e auxpannes :utilisation de répli as . . . 49
4.7.1 Les diérentstypesde pannespossibles. . . 49
4.7.2 Impa t des défaillan es sur le omportement du gestionnaire de res-sour es Aroma. . . 50
4.7.3 Les stratégiesmises enpla e. . . 51
4.7.4 Communi ationentre servi ea tif et servi erépli a. . . 56
4.8 Con lusion. . . 57
5 Spé i ités de la mise en ASP d'Aroma 59 5.1 Introdu tion . . . 59
5.2 La notion de ontrat . . . 60
5.2.1 Groupe d'utilisateurs . . . 60
5.2.2 Informations asso iéesau ontrat . . . 61
5.2.3 Traitement des informationsdu ontrat . . . 61
5.3 La sé urité . . . 62
5.3.1 Authenti ation desutilisateurs. . . 62
5.3.2 Chirement des ommuni ations . . . 63
5.3.3 Prote tion desdonnées et du ode. . . 64
5.4 Intera tions entreun lient et le gestionnairede servi es . . . 65
5.4.1 Le lient Aroma : problématique et avantages . . . 65
5.4.2 Véri ation des droitsvial'API . . . 65
5.4.3 Véri ation des droitsvial'interfa e graphique . . . 65
5.4.4 Chargement dynamiquedesplugins. . . 68
5.5 Portage d'uneappli ation existante en modeASP. . . 69
5.5.1 Con ept général . . . 70
5.5.2 Authenti ation du lient. . . 70
5.5.3 Cal ul distant . . . 71
5.5.4 Gestion du ontrat . . . 71
6 Évaluation de performan es d'appli ations distribuées. 73
6.1 Introdu tion . . . 74
6.2 L'évaluationde performan e d'appli ations. . . 74
6.2.1 Les ben hmarks. . . 74 6.2.2 La simulation . . . 75 6.2.3 Méthodesanalytiques . . . 77 6.3 Le simulateur DHS.. . . 79 6.3.1 La simulation événementielle . . . 79 6.3.2 Les événements . . . 79 6.3.3 Le paquet . . . 79
6.3.4 Les n÷uds,les uxet les owstates . . . 80
6.3.5 Le routage. . . 81
6.3.6 Les sour esde tra TCP . . . 81
6.4 Système modélisé . . . 81
6.4.1 Comportement des lients . . . 83
6.4.2 Cara téristiques desappli ations . . . 84
6.4.3 Les proto oles appli atifs . . . 87
6.4.4 Cara téristiques desma hines . . . 90
6.4.5 Comportement du systèmed'exploitation . . . 93
6.4.6 Le n÷udOrdonnan ement . . . 96
6.5 Intégrationau sein dusimulateur DHS . . . 96
6.5.1 La ou he réseau . . . 96
6.5.2 Les lients . . . 96
6.5.3 L'appli ation séquentielle . . . 96
6.5.4 Les appli ationsparallèles . . . 98
6.5.5 Le n÷udserveur . . . 99 6.5.6 Le n÷udordonnan eur . . . 100 6.5.7 Le systèmeglobal . . . 100 6.5.8 Indi ateurs de performan e . . . 101 6.6 Con lusion. . . 101 7 Validation. 103 7.1 Introdu tion . . . 103
7.2 Performan es de serveursWeb. . . 104
7.2.1 Serveur unique et un seultype d'appli ation . . . 104
7.2.2 Serveur unique, lients diéren iés . . . 109
7.2.3 Partage de hargesur plusieurs ma hines . . . 112
7.3 Appli ations parallèles . . . 114
7.3.1 Cara téristiques matérielles et logi iellesde lagrappe utilisée . . . 114
7.3.2 L'appli ation de test . . . 115
7.3.3 Proto olede test . . . 116
7.3.4 Résultats obtenus . . . 117
8 Con lusion. 123
8.1 Gestion de ressour esen mode ASP. . . 123
8.2 Évaluationde performan es d'appli ations . . . 123
8.3 Perspe tives . . . 124
A Fi hiers de on guration des apteurs de harge 125 A.1 Listedes apteurs de harge . . . 125
A.2 Con guration des apteurs de harge . . . 126
B Rappel des prin ipes de base de TCP 131 B.1 Con epts de base . . . 131
B.2 Contr le dudébit d'émission. . . 132
B.2.1 Obje tif . . . 132
B.2.2 Fenêtreglissante . . . 132
B.2.3 Fenêtrede ongestion . . . 133
2.1 Les diérentesgrappes . . . 6
2.2 Répartition desressour es d'unegrille entre diérentsdomaines . . . 10
2.3 Ar hite ture en ou hesd'une grille. . . 11
3.1 Ar hite ture de ganglia. . . 16
3.2 La stru ture duNetworkWeatherServi e . . . 17
3.3 La GlobusToolkit . . . 18
3.4 Ar hite ture du servi ed'information . . . 20
3.5 Modesde transfertdu proto ole GridFTP . . . 21
3.6 Prin ipe de l'invo ation d'un Web Servi e . . . 24
3.7 Composants deSun GridEngineet intera tion ave un lient . . . 26
3.8 Modèlede Legion . . . 27
3.9 Ar hite ture de DIET . . . 31
4.1 S hémad'utilisation d'Aroma . . . 35
4.2 Serveur générique . . . 37
4.3 Gestion de l'information . . . 38
4.4 Exemple d'ar hite ture . . . 39
4.5 Jini et Aroma . . . 42
4.6 Données d'état sto kées au niveau d'un domaine . . . 46
4.7 Exemple d'ar hite ture ave lamiseen pla e dusystèmede toléran e auxfautes 52 4.8 Exemple d'arbre dé rivant unear hite ture Aroma possible . . . 53
4.9 Arbre dé rivant l'exemple d'ar hite ture Aroma après l'arrêt du servi e CRU répli a . . . 54
4.10 Arbre dé rivant l'exemple d'ar hite ture Aroma après l'arrêt du servi e CRU a tif . . . 56
5.1 Utilisationd'Aroma enmodeASP . . . 60
5.2 Modèlerelationnel desutilisateursd'Aroma . . . 62
5.3 Dialogue ave labasede donnéeslors d'unesoumission de tâ hes . . . 63
5.4 Ar hite ture d'authenti ation de JAAS . . . 64
5.5 Véri ation des droitslors d'une onnexionvia l'API . . . 66
5.6 Interfa e graphique liente . . . 67
5.7 Prin ipe de fon tionnement dutélé hargement de plugins graphiques . . . 68
5.8 Chargement desplugins graphiques au seindes serveurs . . . 69
6.1 L'outil PACE . . . 76
6.2 Exemple de LQN . . . 78
6.3 Sour e detra TCP . . . 82
6.4 Système modélisé . . . 82
6.5 Comportement des lients d'appli ations de al ul au ours dutemps . . . 83
6.6 Comportement des lients d'appli ations intera tivesau oursdu temps . . . . 84
6.7 Tra e d'exé utiond'une appli ation . . . 85
6.8 Appli ation parallèle représentable sousforme degraphe . . . 86
6.9 Appli ation maître/es laves . . . 87
6.10 Les proto oles de ommuni ation de LAM/MPI . . . 89
6.11 Les zonestamponde TCP . . . 90
6.12 Ar hite ture type d'un serveur . . . 91
6.13 Modèleserveur . . . 92
6.14 L'ordonnan eur de Linux2.6 . . . 93
6.15 ModèleOSI . . . 94
6.16 Ar hite ture en ou he de Linux . . . 95
6.17 Le n÷ud lient . . . 97
6.18 En haînement desdiérentes phases detraitement d'uneappli ation séquentielle 98 6.19 n÷ud serveur . . . 99
6.20 Système global . . . 100
7.1 Simulation d'un unique serveur Web . . . 104
7.2 Réseau de les d'attentes d'un serveur Web . . . 105
7.3 Évolution dusystèmeau ours dutemps, àdiérentes harges . . . 107
7.4 Évolution dusystèmesaturé . . . 108
7.5 Comparaison entrerésultatssimulés et résultatsanalytiques . . . 108
7.6 In uen e dutemps de ré exion . . . 109
7.7 Charge du systèmeave diérentes populations de lients . . . 111
7.8 Comparaison entrerésultatssimulés et résultatsanalytiques . . . 111
7.9 Réponsedu systèmeave plusieurs ma hines . . . 113
7.10 Comparaison entrerésultatssimulés et résultatsanalytiques . . . 114
7.11 Appli ation gros grain, es laveslents . . . 118
7.12 Appli ation gros grain, maître lent . . . 118
7.13 Appli ation moyen grain, es laveslents . . . 119
7.14 Appli ation moyen grain, maîtrelent . . . 119
7.15 Appli ation grain n, es laveslents . . . 120
7.16 Appli ation grain n, maître lent . . . 120
7.17 Durée de lasimulation . . . 121
B.1 Con ept de fenêtre glissante . . . 133
Introdu tion.
Ladémo ratisation ré ente del'Internet,et plusgénéralement desréseauxde ommuni a-tion hautdébit àmoindre oût,permet ledéveloppement denouvelles formesd'utilisation de l'informatique.
L'utilisation de l'outilsinformatique, sousforme de servi esdéportés, sedémo ratise peu à peu,et unpanel deplus enplus diversi édeservi es onnaissent un su èsgrandissant.
Le luster ougrappede ma hineest,à l'heurea tuelle, lesupportleplusapteàrendre e servi e grâ e à ses qualités en terme d'extensibilité, de modularité, d'évolutivité et de oût. Néanmoins, la mise en pla e de e type de support d'exé ution fait apparaître de nouvelles problématiques, ouné essitel'adaptation de problématique existantes.
L'obje tif de ette thèse est d'étudier les problématiques liées à la fois à la on eption d'intergi iels
1
permettant lamiseenpla edeservi esdéportéessurdesgrappesdema hines, et d'étudier les performan es de e type d'ar hite ture.
1.1 La gestion des ressour es
L'utilisation de grappesde ma hines a tout d'abord vule jour dansledomaine du al ul hauteperforman e.Lesma hines parallèles,auxar hite tures propriétaires, èdent peuàpeu leurpla eàdesgrappesetgrillesde al ul.L'intérêtde esupportrésideprin ipalementdans son rapport prix/performan e. Limitées dans un premier temps à quelques ma hines homo-gènes,lesar hite turesa tuellesévoluentverslamiseen ommund'unnombreplusimportant de ma hines,pouvant avoir desar hite tures hétérogènes.Ce type d'ar hite ture umuledes avantages en termes de oût d'a quisition (utilisation ou réutilisation d'ar hite tures maté-rielles grand publi ) et d'évolutivité (le nombre de ma hines d'une grappe peut être étendu de manière illimitée).
La mise en pla e de servi es déportés sur des grappes de ma hines né essite la mise en pla e d'intergi iels spé i quesa ndegérerlesressour espourassurerunehautedisponibilité et une qualité de servi e apte à séduire les utilisateurs. L'utilisation de ressour es distantes peutégalementdonnerlieuàunefa turationduservi e.Ilestdans e asjudi ieuxdedé nir plusieurs lassesd'utilisateurspourdiéren ier euxquisontprêtsàpayerpluspourunservi e
1
Un intergi iel (middleware) estune lassedelogi iels qui assurel'intermédiaire entreles appli ationset lessystèmesd'exploitationprésentssurlesma hinesdelagrappe.
orant unmeilleurtemps deréponse(parallo ation d'unplusgrand nombre deressour esou par une priorité supérieureauxautres utilisateurs, par exemple).
Lesproblématiques adressées par es intergi iels sont :
l'authenti ation : seuls les utilisateurs autorisés peuvent avoir a ès à la ma hine; la lasse de servi e maximale de l'utilisateur peut être déduite de l'identi ation de l'utilisateur,
la on dentialité: lesdonnéesdestravauxd'unutilisateur nedoiventpasêtreobservées lors de leurtransit surleréseau, nilors de leur exé ution,
lahautedisponibilitépour assurerla abilité desopérationset desrésultatsobtenus, la gestion des ressour es: ette problématique on erne à la fois l'observation des
res-sour esetlaséle tion desressour esutiliséesaumoyende politiquesd'ordonnan ement spé i ques.
1.2 Les appli ations on ernées
De nombreuses appli ations sont on ernées par l'utilisation en mode déportée. Dans le domaine industriel, denombreuses appli ationsportéessurdesgrappesde ma hines peuvent utiliser e modèle d'exé ution dans des domaines aussi variés que la physique nu léaire, la bio-informatique, la santé, l'é ologie, les s ien e de l'univers [49 ℄ ou les télé ommuni ations. Ces outils :
sont souventde gros logi iels, sont souventonéreux,
né essitent un ensemblede bibliothèques annexes(Plugins),
né essitent une assistan esuivant les périodes, suivant les problèmestraités,
né essitent parfois desma hines puissantes (en pro esseur, en mémoire ou en apa ité de sto kage),
l'utilisation peut être saisonnière ou pon tuelle et don oûteuse en terme d'a hat de li en e annuelle.
Suivant les as, et pour diérentes raisons ( nan ières, ressour es humaines disponibles, omplexité de mise en pla e) l'utilisateur potentiel de tels produits, peut être en di ulté pour une utilisation e a e de es appli atifs sur la ma hine de son bureau. D'autre part, il doit très souvent faire fa e à des problèmes ontraints par un délai de réa tion très ourt. Dans e as,l'utilisationdemoyensetdeservi esdéportésausenslarge,vontpermettreà et utilisateur de résoudresonproblème àmoindre oûtet dansuntemps minimal.
Lesappli ationsde al ul s ienti ques nesontpaslesseulesàpouvoirtirerpro tde l'uti-lisation de grappes de ma hines. Que e soit dans le adre des servi es publi s (dé laration d'imp ts, télé hargement de formulaires administratifs...), du servi e ban aire (gestion de ompte, a hats enbourse...), del'assuran e(dé larationde sinistres,réalisationdedevis...), du divertissement (a hat de musique en ligne, logos de téléphones portables, vidéo à la de-mande...),denombreuxservi es, toujoursplus omplexes, onnaissentunsu èsgrandissant. Ces appli ationsren ontrent les mêmesbesoinsenterme dehautedisponibilité, degestionde ressour es et parfoisd'authenti ation que lesappli ations s ienti ques.
De e fait, une même grappe de ma hines peut à lafois hébergerdesservi es multimédia (serveur Web de l'entreprise, servi e de télé-formation...) et des appli ations s ienti ques utilisées en mode déporté. Les performan es de es diérentes lasses d'appli ation doivent
être prises en ompte a n d'être apable de dimensionner les grappes de ma hines à utiliser pour orirun niveau de qualité deservi es enadéquation ave lesattentesdes utilisateurs.
1.3 Plan de la thèse
L'obje tif de ette thèse est de proposer un intergi iel permettant l'exé ution déportée d'appli ations s ienti ques surdes grappes de ma hines, et d'étudier les performan es de e système a nde pouvoirledimensionner.
Le premier hapitre positionne la problématique de la thèse au sein de la nébuleuse des grappeset desgrilles informatiques. Ces deux on epts ysont dé nis et les diérentes vision de lagrille informatique ysont présentées.
Le deuxième hapitre présente les diérents outils existantsadressant les problématiques liéesàl'exé ution distanted'appli ations s ienti quessurdesgrappesdema hines.Lesoutils d'observation des ressour es, et diérents intergi iels pour les grilles informatiques y sont étudiés.
Les deux hapitres suivants détaillent le fon tionnement du gestionnaire de ressour e Aroma (s Alable Resour e Observer and wAt her) réalisé durant ette thèse. Les problé-matiques d'observationdesressour es, dehautedisponibilitéet lesspé i itésdel'utilisation déportée ysont notamment expli itées.
Le inquième hapitretraitedudimensionnementdegrappesdema hinesdevanthéberger à la foisdes appli ationsde al ul s ienti que et des ontenus intera tifs. Le fon tionnement desdiérents omposantsayant unein uen esurles performan es d'unegrappe dema hines y estétudié,et les modèles onçusdansle butde simuler lefon tionnement d'un telsystème y sontprésentés.
En n, le dernier hapitre présente les résultats obtenus lors de la simulation du fon -tionnement de grappes de ma hines. Ces résultats sont omparés à des modèle analytiques simples dans le as d'appli ations de présentation de ontenus multimédia, et à des mesures d'exé utions réelles dansle as d'appli ations de al ul s ienti que.
Les on epts de grappes et de grilles.
Sommaire
2.1 Introdu tion . . . 5
2.2 Grappes etGrilles . . . 6
2.2.1 Dé nitions . . . 6
2.2.2 Diérentes visionsd'uneGrille . . . 7
2.3 Lesgrilles de al ul . . . 8
2.3.1 Obje tifsdu"grid omputing" . . . 8
2.3.2 Problèmesinhérentsàlagestiond'unegrillede al ul . . . 9
2.3.3 Ar hite turetyped'unegrillede al ul. . . 11
2.4 Domainesd'appli ationet exemples . . . 12
2.5 Con lusion . . . 13
2.1 Introdu tion
L'augmentation onstante des besoins en termes de puissan e de al ul informatique a toujours étéun dé auquel la ommunauté s ienti ques'est onfrontée. Le al ul s ienti que ou nan ier, lamodélisationou bien laréalité virtuelle sont autant d'exemples pour lesquels il estné essaire dedisposerd'une grandepuissan ede al ul.
Même siles évolutions te hnologiques permettent d'aboutir à la réation de ma hines de plus enplus puissantes, une seulema hinene fournittoujours passu samment de puissan e pour ee tuer des al uls d'une omplexité tropélevée, ou traitant un tropgrand nombre de données.
Jusqu'à la dernière dé ennie, la seule solution viable pour résoudre es problèmes om-plexes étaient lesma hines parallèles. Cesdernièrespermettent d'intégrerdansunmême bâti plusieurs pro esseurs reliés entre euxpar desbusde ommuni ationtrès rapideset disposant d'une grandequantité demémoire. Bienquetrès e a es, esma hines présentent l'in onvé-nientd'être dessolutionsspé i ques,propriétairesets'avèrent de efaittrès oûteusesetpeu évolutives. Elles obligent également leportage des odes de al ul et souvent leur réé riture a n de béné ier aumieux desperforman es oertes par haque ar hite ture.
La démo ratisation des ordinateurs personnels, l'augmentation onstante de leurs perfor-man es et la démo ratisation des réseaux de ommuni ation haut débit, orent aujourd'hui des alternatives sérieuses à es solutions onéreuses. Ces systèmes appelés grappes et grilles
de al uls reposent sur la mise en ommun d'un nombre important de ma hines "standard" reliées entreelles par desréseauxhaut débit.
Bien qu'apportant une réponse aux problèmes de oût, d'évolutivité et de portage du ode, es solutions soulèvent d'autres problèmes en termes de mise à l'é helle, de abilité, d'hétérogénéité, de sé uritéet de gestiondes ressour es.
Dans unpremier temps, une dé nition des on epts de grappeset de grilles sera donnée. Les obje tifsdesgrillesde al ul ainsiqueles problèmessoulevéspar lagestionderessour es dans de tels environnements seront ensuite introduits. Finalement, les prin ipaux domaines d'appli ation desgrillesde al ul seront présentés.
2.2 Grappes et Grilles
2.2.1 Dé nitions
Une grappe de ma hine (Cluster en Anglais) désigne un ensemble d'ordinateurs, appe-lés n÷uds, tous inter- onne tés, dans le but de partager des ressour es informatiques. Une grappepeut être onstituée d'ordinateursde bureaux ( gure 2.1(a)), de"ra ks"de ma hines onstituées de omposants standards ( gure 2.1(b)) ou de "lames" ( gure 2.1( )) également onstituéesde omposantsstandardsa nd'optimiser l'espa ephysique.Unegrappe est géné-ralement omposée de ma hines homogènes en termes d'ar hite ture et de système d'exploi-tation. Elle ne regroupe que des ma hines appartenant au même domaine d'administration réseau et lesn÷uds ommuniquent entre euxenutilisant unréseau de ommuni ation rapide (100Mbou Gb).Lesdiérentsn÷uds d'unegrappepossèdentsouventune on guration logi- ielle semblable. Une pratique ourante, utilisée par laplupart deslogi iels d'administration de grappes (Ro ks Cluster Distribution[63℄, IBM CSM[30 ℄, SUN Cluster[73 ℄) est d'installer les logi iels surunn÷udmaître, puis dedéployer une image dusystèmesur haque n÷udde la grappe.Ce pro édépermet de maintenir une ertaine ohéren e entreles diérents n÷uds tout enlimitant les opérationsd'installation auseul n÷udmaître.
(a)GrappedePC (b)Ra k de ma hines
( ) Lames de ma- hines
Fig.2.1 Lesdiérentes grappes
Le terme grille quant à lui, désigne un ensemble beau oup plus important de ma hines, hétérogènes, réparties sur diérentsdomaines d'administration réseau. Lesdiérentes entités omposant une grille peuvent être réparties sur l'ensemble de la planète et ommuniquent
entreellesenutilisant unegrandediversitéderéseauxallant del'Internetàdesréseauxprivés très haut débit.
Le on ept de grille informatique puise soninspiration dans le développement desgrilles d'éle tri ité (power grids) au début du XXème siè le [46 ℄. A ette époque, la révolution ne résidait pas en l'éle tri ité elle-même, mais plut t en la onstitution d'un réseau éle trique fournissant aux individus un a ès able et peu onéreux à l'éle tri ité, au travers d'une in-terfa e standard : la prise de ourant [28 ℄. Les omposants formant le réseau éle trique sont hétérogènes, et la omplexité induite est totalement masquée à l'utilisateur nal. Ainsi, une grille informatique possède les mêmes propriétés d'hétérogénéité desressour esque le réseau éle trique,ledé s ienti queestd'oriràl'utilisateurde lagrillelamême transparen e d'uti-lisation qu'orelaprise éle trique à l'utilisateur duréseau éle trique.
Une grille informatique est une infrastru ture matérielle et logi ielle qui fournit un a ès onsistant et peu onéreux à des ressour esinformatiques [28 ℄.Le but est ainside fédérer des ressour es provenant de diverses organisations désirant ollaborer en vue de faire béné ier auxutilisateurs d'une apa itéde al ul et desto kage qu'uneseule ma hinene peut fournir. Cependant, tout système informatique distribué ne peut posséder l'appellation de grille de al ul [25 ℄.Eneet,unegrilleestunsystèmequi oordonnedesressour esnonsoumisesàun ontr le entralisé,quiutilisedesproto olesetinterfa esstandardsdanslebutdedélivrerune ertaine qualité deservi e(en termes de temps deréponse oubiende abilité par exemple).
Plusieurs types de grilles peuvent être dis ernées selon le type de ressour es utilisées et l'utilisation re her hée. La se tion suivante propose une lassi ation des diérents types de grilles.
2.2.2 Diérentes visions d'une Grille
Classi ation par type de ressour e partagée
Les diérents projets de re her he ayant vu le jour à l'heure a tuelle autour des grilles informatiques permettent de mettre en éviden e une première lassi ation des grilles par type de ressour espartagées:
Grille d'information : la ressour e partagée est la onnaissan e. L'Internet en est le meilleur exemple : un grand nombre de ma hines hétérogènes réparties sur toute la surfa e du globeautorisant una ès transparent à l'information.
Grilledesto kage : l'obje tifde esgrillesestdemettreàdispositionun grandnombre de ressour es de sto kage d'information a n de réaliser l'équivalent d'un "super disque dur" deplusieurs PetaBytes.Le projetDataGrid oules réseauxKaazaou gnutellasont un bon exemple degrille de sto kage.
Grille de al ul : l'obje tif de es grilles est lairement d'agréger la puissan e de trai-tement de haque n÷ud de lagrille a n d'orir une puissan e de al ul laplus grande possible.
Diérentes visions des grilles de al ul
Lesgrillesde al ulpeuventelles-mêmesêtre lassi éesensous- atégoriesselonl'utilisation re her hée :
VirtualSuper omputing: etermedésigneuneasso iationdeplusieurssuper al ulateurs géographiquement répartis. Chaque n÷ud est une ma hine parallèle ontr lée par un gestionnaire de tâ hes réalisant du pla ement par lots. Ce type d'environnements est
destiné àdesappli ations grosgrain, ou àdes appli ationsorant plusieurs niveaux de parallélisme : un premier niveau exploitable par une ma hine parallèle et un deuxième exploitable par unsystème distribué.
Internet omputing: ettevision desgrillesde al ul se ara térise parlamiseen om-mun d'un très grand nombre d'ordinateurs personnels. Le but re her hé est d'utiliser les périodesdurant lesquelles l'ordinateurest inutilisé. Cetype d'utilisation estdestiné à desappli ations augrain npour lesquellesun traitement peut être fa ilement inter-rompuou re-exé uté.Ilpermettoutefois dedisposer d'uneimmense puissan ede al ul potentielle àmoindre oût.
Meta omputing: etermedésignelamiseen ommundeplusieursma hinesougroupes dema hines, haquema hinedonnanta èsàunlogi ielparti ulier.L'intérêtde etype de grillesestde partager des oûtimportantsde logi ielsentrediérentes organisations oudepermettrel'a èsàdeslogi ielsné essitantdumatérielspé i queàmoindre oût.
2.3 Les grilles de al ul
2.3.1 Obje tifs du "grid omputing"
Le al ul surgrille possède plusieurs obje tifs[79 ℄ :
Exploiter les ressour essous-utilisées :Danslaplupartdesorganisations,ilexiste une quantité très importante de ressour es sous-utilisées. Des études montrent que le taux d'utilisation d'un ordinateur de bureau n'atteint pas les 5 % de moyenne. Ainsi, il est intéressant de pouvoir utiliser es ressour es librespour exé uter une appli ation lorsquelesma hinesquiluisontnormalementdédiéesnepeuventlefairedansdebonnes onditions,en asdepi sd'utilisationparexemple.Bienentendu,lan eruneappli ation surunordinateur ina tifsupposeque elui- i possèdeles équipementsmatérielset logi- ielsné essairesaubonfon tionnement del'appli ation.Ilestànoterquelesressour es que l'on traitei i peuvent aussibienêtre des y les de pro esseurque des apa ités de sto kage (mémoires vivesou mémoirespermanentes).
Fournir une importante apa ité de al ul parallèle : Le prin ipal intérêt d'une grilleestdepermettrel'exé utiondeplusieurstâ hesenparallèle.Ainsi,uneappli ation pouvant être dé oupée enplusieurs tâ hes, pourraêtre exé utéesurplusieurs ma hines de lagrille,réduisant ainsiletempsde réponsedu al ul àee tuer. Cependant,toutes les appli ations ne pourront pas s'exé uter en parallèle. C'est le as lorsque les tâ hes qui la omposent sont trop dépendantes lesunes desautres.
A éder à des ressour es additionnelles : Outre les pro esseurs et les apa ités de sto kage, l'utilisation d'une grille peut s'avérer utile pour a éder à d'autres types de ressour es,tels quedeséquipementsspé iaux,deslogi iels,etbiend'autresservi es. Certaines ma hines peuvent, par exemple, héberger des logi iels ayant des oûts de li en e très élevés. Ainsi, l'utilisation d'une grille de al ul permet de béné ier de es logi iels à des oûts moindres. De la même manière, si une ma hine est reliée à des
équipements spé i ques, elle pourra être utilisée par les autres ma hines de la grille pour permettre lepartage de eséquipements.
Mieux répartir l'utilisation des ressour es : Puisqu'une grille de al ul permet d'exé uterdesappli ationssurdesma hinesina tives,ilestpossiblederépartirdespi s d'utilisation inattendusde ertaines ma hines vers d'autresqui sontmoins solli itées.
Gérerdesappli ationsave deadline pro he:Siuneappli ationdoitêtreexé utée ave une ontrainte de date butoir très pro he, l'utilisation d'une grille peut s'avérer utile.Eneet,sil'appli ation peutêtredé oupéeenunnombresu santde tâ hes,etsi une quantité adéquatederessour espeut luiêtre dédiée,l'appli ationbéné ierad'une apa itéde al ul su sante pour être exé utéetouten respe tant une deadline pro he.
Assurer une toléran e aux fautes pour un oût moindre : Dans les systèmes onventionnels, la toléran e aux fautes est réalisée grâ e à la redondan e du matériel sensible.Cettesolutionpossèdel'in onvénient d'avoir un oûtassezélevé.Lesgrillesde al ul, depar leurnature, orent une solutionalternative pouree tuerde latoléran e auxfautes.Eneet,siunedéfaillan eapparaîtàunendroitdelagrille,lesautresparties delagrilleneserontpasfor émentae tées.Ainsi,desdonnéespeuventêtredupliquées surplusieursma hinesdelagrillepourprévenirleurperteen asdedéfaillan e.Deplus, pour desappli ations temps réel ritiques, ilpeut s'avérer utile d'en exé uterplusieurs instan es simultanément sur diérentes ma hines, voire même de véri er les résultats qu'elles fournissent pour plusde abilité.
2.3.2 Problèmes inhérents à la gestion d'une grille de al ul
Le grid omputing onsiste don àfédérer desressour es de al ul et de sto kage géogra-phiquement réparties,en vuede permettre leurutilisation demanière transparente pour tout lient de la grille. Les spé i ités desgrilles de al ul rendant leur gestion déli ate [47 ℄ vont maintenant être présentées.
Hétérogénéité
La première ara téristique des ressour es onstituant une grille est sans nul doute leur hétérogénéité. Qu'elles soient matérielles ou bien logi ielles, les ressour es sont souvent très diérenteslesunesdesautres.Cettehétérogénéitéimposedes ontraintes deportagede ode, d'utilisation de langages multi-plateformes et d'utilisation de proto oles de ommuni ation standardisés. L'utilisateur doit de plus pouvoir utiliser la grille de manières transparente et homogène quelle que soit l'ar hite ture de sapropre ma hine et l'ar hite ture de la ma hine à laquelleil se onne te.
Multipli ité des domaines d'administration
Lesressour es sontgéographiquement distribuées et appartiennent à diérentes organisa-tionsindépendantes.Ellesappartiennentdon àplusieursdomainesd'administrationdistin ts, ayant ha un saproprepolitiquedegestionet de sé urité( gure 2.2)en terme d'a èsau ré-seau, d'a èsauxdonnées,d'authenti ationouen orede on dentialité. Ainsi,lespersonnes hargées d'administrer la grille n'auront pas for ément de privilèges parti uliers sur les ma- hines desdiérentsdomaines d'administration.Il est don indispensable de mettreau point des méthodes d'administration parti ulières ne né essitant au un privilège sur les ma hines ibles. Il est également indispensable que haque administrateur lo al onserve ses propres privilèges sur lesma hinesqui lui appartiennent.
Fig. 2.2 Répartition desressour esd'unegrille entrediérentsdomaines
Aspe t dynamique
Dufaitdugrandnombrederessour es onsidérées,ladéfaillan ed'uneressour e(ma hine ou réseau) est unévénement ourant qui ne doit pasmettre en péril lefon tionnement de la grille. Le gestionnaire de ressour es tout omme les appli ations doivent tenir ompte de et aspe tetêtre apablesderéagirrapidementàlaperteouàl'ajoutd'unema hine.Delamême manière, l'ajout de fon tionnalités àun gestionnaire de ressour esdoit pouvoir sefaire,dans la mesure du possible, sans qu'il soit né essaire de réinstaller le gestionnaire sur l'ensemble des n÷udsde lagrille.
Gestion des ressour es
La apa itéde miseàl'é helle d'unegrille est également une ara téristique àprendre en ompte.Eneet,unegrillepourraêtre onstituéed'unedizainederessour es, tout omme de
plusieursmilliersderessour es.Ceproblèmededimensionnementposedenouvelles ontraintes sur les appli ations et les algorithmes de gestion desressour es. L'observation desressour es notamment, ne doit pas induire une sur- onsommation de ressour es trop importante et e quelque soit lenombre de n÷uds delagrille.
2.3.3 Ar hite ture type d'une grille de al ul
L'ar hite ture d'une grille peut être vue de plusieurs façons. Nous hoisirons i i de la représenterselon une ar hite ture en ou hes [46 ℄( gure 2.3).
Applications
Applications scientifiques, commerciales, médicales, portails Internet, ...
Outils et environnements de programmation
API, compilateurs, bibliothèques, outils de conception, ...
Intergiciels de niveau utilisateur
Gestion des ressources, ordonnancement de tâches, ...
Intergiciels pour le noyau de la grille
Soumission de tâches, accès aux unités de stockage, service d’information, ...
Sécurité
Ressources
Authentifications, communications sécurisées, ...
Ordinateurs, stations de travail, bases de données, logiciels, ...
Fig. 2.3 Ar hite ture en ou hes d'unegrille
La ou he de plus bas niveau orrespond aux ressour es elles-mêmes, gérées par des ges-tionnaires lo aux, et inter- onne tées au travers de réseaux lo aux et grande distan e. Cette ou he ontient ainsitoutel'infrastru turematérielle delagrille(ordinateurspersonnels, sta-tions de travail,unités de sto kage, bases de données, et .). Lesordonnan eurs présents à e niveau peuvent être de deux types, soit l'ordonnan eur lo al d'une ma hine unique, soit un ordonnan eur d'une grappe de ma hine tel que Condor [45 ℄[77℄[78 ℄, LSF [84℄ ou bien PBS [4℄[23 ℄.
La se onde ou he fournit tous les mé anismes né essaires à la sé urité de la grille. Des pro édures d'identi ation et d'authenti ation sont ainsimises en pla e a n de pouvoir a - éder auxressour es onstituant lagrille.Ledegrédesé urisation d'uneressour e peut varier
selonsonimportan eousa riti ité.Ainsi,ilpeutexisterdesressour espourlesquellesau une authenti ationn'est né essairepour les utiliser.
La troisième ou he fournit les intergi iels né essaires au noyau de la grille. Elle ore des outils permettant lasoumission de tâ hes, l'a ès auxunités de sto kage et desservi es d'in-formation répertoriant dynamiquement les ressour esdisponibleset leurétat.
Laquatrième ou heregroupedesintergi iels de niveau utilisateur.Elle on erne lesoutils de gestion des ressour es et les servi es d'ordonnan ement. Ces ordonnan eurs auront pour r le de pla er les tâ hesqui leurs sont on ées surdesma hines appartenant à desdomaines réseaux distin ts.
Desoutilsetenvironnementsdeprogrammationpourledéveloppementd'appli ations desti-néesauxgrillesde al ulsontfournisparla inquième ou he.Onytrouveainsidesinterfa es de programmation (API), des ompilateurs, des bibliothèques ou bien en ore des outils de on eption d'appli ations parallèlesadaptées aux grilles.
La sixième et dernière ou he regroupe en n les appli ations elles-mêmes. Il peut s'agir d'appli ations s ienti ques tout omme d'appli ations ommer iales, médi ales ou bien des portails Internet.
2.4 Domaines d'appli ation et exemples
Lesgrillesde al ul,mêmesielles onstituentunenouvellete hnologieen oursde dévelop-pement, ont plusieurs exemples on rets d'utilisationàleur a tif[43 ℄. Cesexemples d'utilisa-tionpermettent defaireapparaître inq grandstypesdedomainesd'appli ationpourlesquels les grillesde al ul peuventêtre utilisées [28 ℄:
Le al ul intensif distribué: Il s'agit d'utiliser les grillesde al ul en vue d'agréger uneimportantequantitéderessour esné essairesà ertainesappli ations.Unetelle puis-san e de al ul ne peut être obtenue qu'en additionnant les apa ités de plusieurs ma- hines.Dessimulations intera tivesdansledomaine militaire,ledomaine de la on ep-tionaéronautique,del'analysederisquesoubiendessimulationsdepro essusphysiques omplexes sont desexemplesd'appli ation du al ul intensifdistribué.
Le al ul à haut débit:Dans e ontexte,lagrillepermetd'ordonnan erenparallèle un grand nombre de tâ hes peu ouplées, voire totalement indépendantes, dans le but d'utiliser les y les pro esseurs inutilisés des ma hines ina tives. Parmi les diérentes appli ations,nouspouvons itertouteslesrésolutionsdeproblèmes ryptographiqueset l'analyse du génome.La ZetaGrid est le premier exemple de e type de grille. Elle est onstituéedeplusdetroismillema hinesvolontairesreliéesparInternetenvued'essayer devéri er l'hypothèseformuléeen1859parRiemann,etquiresteà ejourl'undesplus importants problèmes mathématiques. Ainsi, pour parti iper à ette grille, il su t de télé harger librement un lient,dont ler le estd'exé uterdestâ hessurlama hinedès quel'é onomiseurd'é ran de elle- idevient a tif.Le projetSETIhome estégalement
undesprojetsde al ulhautdébitlespluspopulaires.Ceprojetapourbutdere her her une éventuelletra ed'intelligen eextraterrestreàpartir d'observations réaliséespar un radio-téles ope.Une grille, onstituéede inq entmille ordinateurs,aainsiétémiseen pla e. Il s'agit à e jour de laplusvastegrille jamaisdéployée aumonde.
Le al ul à la demande : Ce domaine on erne les appli ations pour lesquelles les grilles de al ul sont un moyen de disposer temporairement de ressour es dont l'utili-sation permanente ne serait pasrentable. En outre, parmi es appli ations gurent les appli ations s ienti quesné essitant l'utilisation de matériels spé i quesonéreux.
Le traitement intensif de données : Ler ledesgrillesde al ul est, dans e as, de produiredenouvellesinformationsàpartirdedonnéesgéographiquementdistribuées.La grillesera alorsen hargedesto ker lamassed'information ainsigénérée.Desexemples d'appli ations sont la produ tiond'une arte del'univers, ou bienen ore les prévisions météorologiques.LesprojetCERNopenlab estleprojetpharede e typed'appli ation, sonbut estde pouvoirtraiter jusqu'àun Pétao tet de données.
Le al ul ollaboratif :Lesappli ations ollaborativesontpourobje tifdepermettre les intera tions entre humains a n d'autoriser l'utilisation partagée de ressour es telles quedes basesde données oubiendessimulations.
2.5 Con lusion
Le on eptdegrilledema hines estun on eptnaissantenpleine évolution.Lebutinitial des grillesestde permettre d'a éder auxressour esinformatiquesaussisimplement que l'on a ède auréseauéle trique.Apartirde e on eptsont apparuesunemultitude d'utilisations permettant de résoudre diérentes lasses de problèmes : a ès transparent à des masses importantes de données, meilleure utilisation des ressour es existantes, a ès transparent à une grande puissan ede al ul,travail ollaboratif...
Notre étude s'intéresse au asparti ulier des grilles de al ul dont le but est fournir une puissan e de al ul "in nie" a nde résoudre desproblèmes de plusen plus omplexes. Dans e aspré isd'utilisation,lesgrillesde al ulrempla entpeuàpeulesma hinesmassivement parallèles traditionnellement utilisées.Bien que permettant de gommer ertaines limites des ma hines parallèles, es nouveaux environnements soulèvent de nouveaux problèmes du fait de leur hétérogénéité, deleur dispersion géographique etde leur aspe tdynamique.
Lesprin ipauxintergi ielsexistantspermettantdegérerlesressour esd'unegrillede al ul vont maintenant êtreprésentés.
Les outils existants.
Sommaire
3.1 Introdu tion . . . 15 3.2 Outilsd'observations . . . 16 3.2.1 Ganglia . . . 16 3.2.2 NetworkWeatherServi e . . . 17 3.3 Gestionnairesde Grilles . . . 17 3.3.1 Globus. . . 17 3.3.2 OGSAetlesGridServi es. . . 22 3.3.3 SunGridEngine . . . 24 3.3.4 Legion . . . 26 3.4 Environnements lient/serveur pour lesGrilles . . . 27 3.4.1 Ninf: . . . 28 3.4.2 NetSolve: . . . 29 3.4.3 DIET . . . 30 3.5 Con lusion . . . 32
3.1 Introdu tion
La gestion de grappeset de grillesde ma hines soulève plusieurs problèmes pouvant être solutionnés pardiérents typesd'outils : observationderessour es, pla ement detâ he, om-muni ation entre ma hines, sé urité... De plus, omme nous l'avons montré dans la se tion pré édente,ilexisteplusieursvisionsdesgrilleset de efait,diversenvironnementsdegestion degrillesontvulejour esdernièresannées.Chaqueenvironnementpermetd'adresserles pro-blèmes spé i ques liés à sapropre vision desgrilles, en reposant soit sur des outilsexistants soit surdessolutionsnouvelles.Le domainedesgrillesétantundomainejeune enpleine rois-san e, de nouvelle solutionsou denouvellesversionsd'outils existantsvoient régulièrement le jour et es versions orrespondent parfoisà des hangements signi atifs d'ar hite ture.
Pour toutes les raisons énon ées pré édemment, il est assez di ile de répertorier l'en-semble des outils permettant de gérer des ressour es sur des grappes ou grilles de ma hines et il estégalement di ile de lassi er esdiérentsoutilsselon les fon tionnalitésou letype d'utilisation qu'ilsproposent. Lesse tions suivantes ont pour but de présenter les prin ipaux a teurs de la gestion de ressour es pour grappes et grilles. Cette présentation s'arti ule au-tour dequatretyped'a teurs : lesoutilsd'observation deressour es(ma hines etréseau), les
environnementsdegestionde ressour esdistribuées, lesgestionnaires degrilleset les environ-nements lient-serveur surgrilles.
3.2 Outils d'observations
3.2.1 Ganglia
Ganglia[48 ℄ estunoutilsd'observationpourenvironnementsde al ul hauteperforman e telsquelesgrappesetlesgrillesde al ul.Ilutiliseunereprésentationhiérar hiquedesgrappes en grille a nde favoriserlepassage àl'é helle ( gure 3.1).
gmond
Noeud
gmond
Noeud
gmond
Noeud
gmond
Noeud
gmond
Noeud
gmond
Noeud
gmetad
gmetad
gmetad
client
connexion
données
Interrogation
Interrogation
Interrogation
défaillance
Interrogation
Grappe
Grappe
XDR sur UDP
XML sur TCP
défaillance
Fig. 3.1 Ar hite ture deganglia
Ganglia repose sur l'utilisation de proto oles de ommuni ations multi asts et sur l'uti-lisation d'une stru ture hiérar hique de onnexions point à point entre ertain n÷uds de la grappe a n de relier les grappes entre elles et d'agréger leurs informations d'état. Il utilise des te hnologies a tuelles telles que XML pour la représentation de données, XDR pour la ommuni ation dedonnées et RRDtoolpour lesto kageet lavisualisation de données. L'im-plémentation deganglia repose prin ipalement surdeux daemons : gmondet gmetad.
gmond : les daemons gmond ont pour but de olle ter les informations on ernant une unique grappe.Undaemon estprésentsur haquen÷uddelagrappe,et ommuniqueave les autres n÷uds de la grappe en utilisant plusieurs proto oles multi asts. Ces ommuni ations multi astspermettentde:publier l'ajoutd'unnouveaun÷ud,envoyersesinformationsd'état aux autres n÷uds de la grappe ou déte ter la défaillan e d'un n÷ud. Tous les n÷uds de la grappe ommuniquent entre eux, de e faitils ont touslamême vision del'état delagrappe.
gmetad : les daemons gmetad permettent de onstruire une représentation hiérar hique d'un ensemble de grappes. Chaque daemon olle te les informations on ernant l'état de ses n÷uds ls et en onstruit une représentation agrégée. Les n÷uds ls peuvent être, soit les ma hinesd'unegrappe(auquel asl'informationagrégéeestl'étatdelagrappe),soitd'autres
daemons gmetad(au quel asl'information agrégée estl'état d'unensemble degrappes). Les daemons gmetad ommuniquent entre euxen utilisant des ommuni ations point àpoint.
3.2.2 Network Weather Servi e
NWSestunoutild'observationfournissantlaprédi tiondeperforman ederessour es dy-namiques dans desenvironnements distribués. NWS prédit laperforman e réseau (laten eet bande passante)[82 ℄[14 ℄, lepour entagedeCPU disponiblesur haquema hinequ'il ontr le [83 ℄etlaperforman edelamémoire.NWSee tuedesmesurespériodiquessurlaperforman e délivrabledesressour es,utilisel'historiquedesmesuresetdeste hniquesstatistiques pourla prédi tion.Il ommuniqueensuitelesrésultatsdelaprédi tionauxs hedulers.Il ya trois a-tégories deméthodesde prédi tion: méthodesbasées surlamoyenne utilisantune estimation de la moyenne omme prédi tion, méthodes basées sur la médiane et les méthodes autore-gressives.NWS hoisitlameilleureprédi tionpour uneressour e en omparantles erreursde prédi tion ave les mesures.Ondistinguetrois modulesdansNWS : sensorysubsystem qui olle te lesinformationssurlaperforman edesressour es, fore astingsubsystem qui prédit la performan e et donne l'information à un reporting subsystem. La gure 3.2 présente la stru ture de NWS.
0
0
1
1
0
0
0
1
1
1
0
0
1
1
00
00
00
11
11
11
00
00
11
11
0
0
1
1
0
0
0
1
1
1
0
0
0
1
1
1
machine
machine
machine
capteur de lien réseau
capteur CPU
capteur mémoire
système de capteur
données
prévision
interface
méthode 1
méthode 2
méthode 3
méthodes de prédiction
Fig. 3.2 Lastru ture duNetwork Weather Servi e
Unserveur NWSdoit s'exé utersur haquema hinequ'il supervise.Chaqueserveur aun apteur deperforman eréseauet un apteur CPU.Touslesserveurs onnaissentlesma hines superviséeset lenumérode portTCP auquel haque serveur est relié.
3.3 Gestionnaires de Grilles
3.3.1 Globus
La Globus Toolkit est un ensemble d'outils et de logi iels open-sour es permettant de on evoiretdemettreen÷uvredesgrillesde al uletlesappli ationsquileursontdestinées. L'obje tif prin ipal de laGlobus Toolkit est de fournir auxdiérentsutilisateurs d'une grille uneAPIleurpermettantd'a éderdefaçontransparente auxressour esquileursontoertes.
Les outilsainsimis àdisposition desutilisateursont pour but d'adresserplusieurs problèmes auxquelsest souvent onfronté legrid omputing.Parmi eux- i gurent [26℄:
lalo alisation et l'allo ationde ressour es, les ommuni ations,
ladé ouverte d'informations surles ressour es, lasé urité,
lagestion et l'a èsauxdonnées.
De manière générale, la omposition de la Globus Toolkit peut être représentée par les trois piliers de la gure 3.3(a). Ainsi, trois omposants essentiels de la Globus Toolkit sont à distinguer :
Le Resour e Management fait allusion au servi e d'allo ation de ressour es. Il est prin ipalement omposé du GRAM (Grid Resour e Allo ation Manager) et du GASS (Globus A ess to Se ondary Storage).
Le pilier Information Servi es fait référen e au servi e d'information de la Globus Toolkit, 'est-à-dire au MDS-2(Meta Dire tory Servi e) dont ler le est de olle ter les informations on ernant l'étatde lagrilleau sein d'unebasede données.
Le servi ede gestion des données présentes sur une grille est représenté par le pilier DataManagement.DesoutilstelsqueGridFTPoubienRFT(Reliable FileTransfer) orent auxutilisateurslapossibilitéd'a éderà esdonnées et deles modi er.
Les trois piliers de la Globus Toolkit reposent sur un servi e de sé urité, né essaire à la viabilitédelagrilleetdesressour esqu'ellehéberge.Cettesé uritéestassuréeparleGSI(Grid Se urityInfrastru ture)quiorelesmé anismesné essairesàlaréalisationd'authenti ations et de ommuni ations sé uriséesau travers d'un réseau étendu.
(a)LestroispiliersdelaGlobusToolkit
Gestionnaires de
ressources
Courtiers
GRAM
(b) Le GRAM au ÷ur d'une ar hi-te tureensablier
3.3.1.1 Le gestionnaire de ressour es
La gestion des ressour es au sein de la Globus Toolkit est assurée par deux entités : le GRAM, hargéde l'allo ation desressour es,etleGASS,dont ler leestdegérerletransfert des hiers utilisés par uneappli ation.
Le GRAM
Le GRAM(Grid Resour e Allo ation Manager) estleservi ede gestionde l'allo ationdes ressour es de la Globus Toolkit. Il s'agit d'une API dont le r le est de mettre à disposition des utilisateurs les outils né essaires à l'exé ution d'appli ations à distan e, et de gérer les ressour es quileur sont asso iées.
La gure3.3(b) montrelapla eduGRAMauseinde l'ar hite tureen ou hesdeGlobus [27 ℄.AuniveauduGRAM,unrétré issementseforme(onparlealorsd'ar hite tureensablier). Ce i traduit le fait que le GRAM possède une API simple et bien dé nie, fournissant un a ès uniformeauxdiversesimplémentations desservi esde basniveau.Des servi esdehaut niveau peuvent alors être dé nis en s'appuyant sur ette interfa e, sans se préo uper de la onstitution de la ou he debasniveau.
Surunegrille,plusieursGRAMsontgénéralementdéployés, ha unétantresponsabled'un ensemble de ressour es soumises à une même politique de gestion qui est spé i que au site danslequel ellessetrouvent.ChaqueGRAMs'appuiesurungestionnairede ressour eslo al, tel que Condor, LSF (Load Sharing Fa ility), ou bien PBS (Portable Bat h System), hargé d'appliquer ette politique. Ainsi,pour haque site,les administrateurs peuvent béné ierde l'API duGRAMtoutenétant libresde hoisirlegestionnairede ressour esqu'ilsveulent.De e fait, au un gestionnaire lo alde ressour esn'est fournit ave laGlobusToolkit.
Lorsque le GRAM devra allouer des ressour es pour une appli ation, il fera appel au gestionnairelo alquise hargerad'ordonnan erlesdiérentestâ hesquila omposentsurles ressour es dont il est responsable. Notons que des ourtiers (Resour e Brokers) peuvent être pla és au dessus des diérents GRAM a n d'appliquer des politiques globales de gestion de ressour es. Lorsqu'une appli ation devra être exé utée, le ourtier identi era unensemble de ressour es, et don un ensemblede GRAM,sus eptibles de satisfairelademande.
Le GASS
Le GASS (Globus A ess to Se ondary Storage) entre lui aussi en jeu lors de l'exé ution d'une appli ation sur la grille.Son r le est de transférer les hiers né essaires à l'exé ution d'une tâ he de l'appli ation, d'unema hine distante vers lama hine surlaquelle latâ he est pla ée [62 ℄. Toutes les ressour esadditionnelles requises par une tâ he sont répertoriéesdans la requête de pla ement de la tâ he. En re evant ette requête, le GRAM détermine si es ressour es manquent sur lama hine ae tée à la tâ he. Si 'estla as, un serveur GASS est réé sur ettema hinedansle but deré upérerles ressour es manquantes. Le serveur GASS autorise également lesutilisateursàpla erdes hierseux-mêmes dansun a he mis enpla e par elui- i.Cetteopérationné essitedesmé anismesdesé uritépermettantl'authenti ation des utilisateurs.
3.3.1.2 Le servi e d'information
Leservi ed'informationdelaGlobusToolkit estmieux onnusouslenomdeMeta Dire -tory Servi e (MDS). Sonr leest de olle ter lesinformations on ernant l'étatde lagrille au
sein d'une base de données, et de les mettre à disposition des utilisateurs sur demande. Ces informations peuvent êtrede plusieurs natures :
on guration des ressour es, 'est-à-dire les informations statiques les on ernant (par exemple : fréquen edu pro esseur, nombre de pro esseurs, quantité de mémoire,et .), état instantané des ressour es, 'est-à-dire les informations dynamiques les on ernant
(parexemple: hargedupro esseur,nombredepro esseursutilisés,quantitédemémoire utilisée, et .),
informations sur les appli ations (par exemple : besoins en termes de pro esseur, de mémoire, et .).
Ainsi, le MDS permet de gérer l'aspe t dynamique d'une grille de al ul, en permettant aux omposantsde laGlobusToolkit,auxoutilsde programmation,et auxappli ationsd'être apablesd'adapterleur omportementaux hangementsdelastru tureoudel'étatdusystème [27 ℄.
Ce servi eest essentiellement omposé de deux entités : le GRISqui répertorie les infor-mationssurlesma hinesquiysontenregistrées,etleGIIS hargéd'indexerlesserveursGRIS [62 ℄ ( gure 3.4). Ces deux omposantsvontêtre su essivement dé rits.
GRIS
GRIS
GRIS
GIIS
Fig. 3.4 Ar hite ture duservi ed'information
Le GRIS
Le GRIS (Grid Resour e Information Servi e) permet la sauvegarde d'informations, sta-tiques ou dynamiques, provenant des ressour es qui y sont enregistrées. Un seul et même serveur GRISne ontient jamais lesinformations on ernant toutes les ma hines de lagrille. Ce ipermetd'unepartunemeilleuretoléran eauxfautes,etd'autrepartdemoinssur harger leGRIS(etdon d'avoirdestempsderéponsemoinsélevés).Ainsi,ilexisteplusieursserveurs GRISsur unemême grille.
Dès lors, un utilisateur quel onque, re her hant des informations sur une ma hine parti- ulière, devrafor émentsavoiràquelGRISs'adresserpourlesré upérer.Globusfournitpour ela unse ond outil, leGIIS.
Le GIIS
LeGIIS(GridIndex InformationServi e) permet d'indexerles serveursGRISd'unegrille. Chaque GRIS s'enregistre, dès son démarrage, auprès d'un serveur GIIS. Celui- i ontient des informations on ernant la lo alisation des GRIS dans la grille, ainsi que les noms des ma hines enregistrées auprès de haque GRIS. Il peut également ontenir des informations
normalement enregistrées au niveau des GRIS. Le GIISfournit ainsi une image ohérente de laglobalité delagrille.
Il est à noter quela présen ed'un seul serveur GIISsur une grille onstituerait un point fragile. A e propos, des serveurs se ondaires sont mis en pla e a n d'assurer une meilleure toléran e auxfautes.
3.3.1.3 Le gestionnaire de données
Le servi ede gestiondesdonnées estprin ipalement en hargede leurs transferts au sein de la grille. C'est dans e but que le GridFTP a été mis en pla e [43℄. Il est à noter que le terme de GridFTPdésigne àlafois leproto ole, leserveurainsiquel'ensembledesoutils permettant d'ee tuer des transferts de données ables entre les diérentes ma hines de la grille.
Leproto oleGridFTPestuneextensionduproto oleFTPstandard,quipermetde s'adap-terauxgrillesde al ul,etnotammentauxmé anismesdesé uritérequis.Ilexistedeuxtypes de transfert ( gure3.5) :
le transfertde hiers standard : des hiers sont transférés entre le lient et leserveur GridFTP.
letransfertimpliquant une troisièmeentité: le lientpeutdemander qu'un transfertde hiers soit ee tuéentredeuxserveursde lagrille.
Client
Serveur
Transfert
Requête
(a) Mode FTP stan-dard
Serveur
Transfert
Client
Serveur
Requête
Requête
(b)ModeFTP étenduFig. 3.5 Modesde transfert duproto oleGridFTP
3.3.1.4 Le servi e de sé urité
Dans une grille de al ul, l'aspe t lié à la sé urité du système est fondamental pour la viabilité de lagrille à long terme. En eet, il est né essaire de ontr ler un tel système a n d'éviter touteintrusion pouvantmettre en péril l'intégrité desressour esde lagrille.
Dans la Globus Toolkit, le servi e gérant la sé urité de la grille est le GSI (Grid Servi e Infrastru ture).
Cryptage des données
ma hines delagrille,unmé anisme de ryptagedesdonnées aétémis enpla e. Ilreposesur le ryptageà lépublique. Chaqueentité de lagrille possède deux lés : une lépublique qui permettra àtouteautre entité de rypterlesdonnées quiluisont destinées,et une léprivée, qu'elle seulepossède,lui permettant de dé rypter es données.
Ainsi, grâ e à e mé anisme, il est garanti que seul le destinataire d'un message pourra lire e message. Toute personne désirant détourner des données ne pourra pasles dé rypter, puisqu'elle n'estpas senséedétenir la léprivée du destinataire.
Le ryptagedesdonnéespeut également êtreee tuéde manièreinversée : lemessageest odé àl'aide d'une léprivée.Dans e as, ilne peut être dé odéquepar la lé publique or-respondante.Ce ipermet des'assurernonpasdel'identitédudestinataire, maisau ontraire de ellede l'émetteur.
Certi ats X.509
Un erti atX.509estun erti atnumériquepermettantd'identi erunutilisateuroubien une ma hinede lagrille. Pour une personne, il ontient desinformations telles que sonnom, son identi ant ou bien l'organisation à laquelle elle appartient. Il ontient également la lé publique quilui estasso iée.
Ilestévident quen'importequipeut réerun erti at et prétendreappartenirà lagrille. Pour éviter e i, une autoritéde erti ation doit examiner tout erti at nouvellement réé et le signer,a n qu'il soitvalide.
Authenti ation et autorisation
Grâ e aux mé anismes de ryptage et aux erti ats X.509, il est possible d'authenti er formellement toute entité de la grille. Le erti at, s'il est signé, nous permet d'être sûr que l'entité se présentant sous e erti at appartient à la grille.Avant de ommuniquer, un mé anisme d'authenti ation mutuelle basé sur l'é hange d'informations ryptées, estutilisé a n de garantir l'identité desentités ommuni antes.
Par la suite, même si une personne peut utiliser la grille, il n'est pas dit qu'elle puisse utiliser la totalité desma hines disponibles. Ainsi, lorsqu'un utilisateur quel onque désirese servird'unema hine,etaprèssu èsdelaphased'authenti ation, ilestné essairedevéri er s'il estautorisé àutiliser lama hine.
Pour ela, haque ma hine possède un hier, appelé grid-map, qui ontient la liste des utilisateurs pouvant l'utiliser(le erti at de ha undes utilisateurspossèdeune entréedans e hier). Ainsi, l'utilisateur fournira son erti at à la ma hine qu'il désire utiliser. Un proto oled'authenti ation seraétabli.Sil'opérationestunsu ès,onvéri eraqu'uneentrée orrespondant au erti at fourniexistedansle hiergrid-map. Si 'estle as,larequêtede l'utilisateur peut êtretransmise àla ma hine.
3.3.2 OGSA et les Grid Servi es
3.3.2.1 La normeOGSA
OGSA (Open-Grid Servi e Ar hite ture) est une norme mise en pla e dans la troisième versionde laGlobus Toolkit. Elle spé i e prin ipalement [29℄ quetoute entité d'une grille de al ul (ressour es de al ul et de sto kage, réseaux, programmes, bases de données, et .) est vue omme un servi e de grille (Grid Servi e). Il s'agit ainsi d'orir une vue su samment
abstraite sur ha un des onstituants de lagrille pour que sonutilisation puisse êtreréalisée de manière transparente.
L'enjeuprin ipalde ette normeestainsidedé nir e qu'estunGridServi e,quellessont ses interfa es, et quel est son omportement. Elle peut don être vue omme un modèle de servi e. La normeOGSA seproposeainside :
dé nirdesmé anismespourla réationetladé ouverted'instan estemporairesdeGrid Servi es,
permettreun ertaindegrédetransparen e surlalo alisationdesinstan esdeservi es, dé nir les mé anismes né essaires à la réation de systèmes distribués sophistiqués, et notamment les mé anismes de noti ation ainsi quela gestion du y lede vie des ser-vi es.
En résumé, OGSA dé nit la manière dont un servi e est réé, omment il est nommé, omment sa durée de vie est déterminée, ou bien en ore omment ommuniquer ave lui. Cependant,OGSAne dé nit enau un as lanaturedu servi erendu,ni omment e servi e est réalisé.
3.3.2.2 Les Grid Servi es
Le terme de Grid Servi e désigne, de manière générale, un servi e disponible dans un environnementdegrille[75℄.Dansle adredelaGlobusToolkit,ildésigneplusparti ulièrement les servi esquirespe tent lesspé i ationsimposées parlanormeOGSI (OpenGridServi es Infrastru ture) [65℄,et qui s'exposent surlagrille grâ e àune interfa e enWSDL.
Cesservi es, surlesquelslaversiona tuelle delaGlobusToolkit estbasée,sont largement inspirés desWeb Servi es
1
.Une grille étant unensembledema hinesinter onne tées pardes réseaux tels que l'Internet, ette te hnologie d'invo ation de servi es à distan e, ore deux avantages majeurs:
ElleutilisedeslangagesXMLstandards.Lesservi essontainsitotalementindépendants de laplate-forme sur laquelle ils s'exé utent ainsique des langages utilisés pour é rire lientset serveurs.
Les messages transmis par es servi es utilisent le proto ole HTTP, parti ulièrement adapté aumonde del'Internet.
LesWeb Servi es reposent sur troisstandards:
SOAP (Simple Obje t A ess Proto ol) : fournit les moyens né essaires à l'é hange de messages entre un fournisseur de servi es et ses lients. SOAP dé nit des onventions pour lesinvo ationsde servi esà distan eet pour lesmessagesalors é hangés.
WSDL (Web Servi es Des ription Language) : langage basé sur XML permettant de dé rire lesWeb Servi es.
WS-Inspe tion : permet delo aliserlesdes riptions desservi espubliéspar un fournis-seur deservi es.
Les diérentes étapesréalisées lors de l'invo ation d'un servi e à distan esimple [7 ℄ sont les suivantes :
1. Le lient lan e une requête UDDI (Universal Des ription, Dis overy and Integration) vers unUDDI Registry pour lo aliser les serveursfournissant leservi edésiré.
1
LesWebServi essontdesservi esquipeuventêtreinvoquésparl'intermédiaired'Internet.Un lientpeut lan er unerequêtedeservi e àdestination d'unserveurdistantvia leWeb,etré upérer uneréponse parle mêmeintermédiaire.
2. L'UDDI Registry répond et indiqueau lient où trouver es serveurs.
3. Le lientsaitoùtrouver leserveur,maisilnesaitpas omment l'invoquer.Illan e don une requête dedes riptionau serveur. Cetterequête estee tuéeen WSDL.
4. Le serveur répond, etindique au lient omment invoquer sesservi es.
5. Le lient peut maintenant invoquer le servi e.Il lan e ainsiune requête SOAP à desti-nation du serveur.
6. Le serveur reçoit etterequête, latraite, et renvoie au lient une réponseSOAP.
Toutes es étapessont résumées par les héma dela gure 3.6.
1. Où puis-je trouver
un serveur effectuant
l’opération X ?
(UDDI)
2. Le serveur A est
capable d’effectuer
l’opération X.
(UDDI)
3. Comment dois-je
exactement vous
invoquer ?
4. Voici comment
invoquer mes
services. (WSDL)
5. Requête pour
l’opération X. (SOAP)
6. Réponse de
l’opération X. (SOAP)
UDDI
Registry
Client
Serveur A
Fig. 3.6 Prin ipe del'invo ation d'un Web Servi e
Les Grid Servi es dérivant des Web Servi es, ils possèdent tous es mé anismes permet-tant d'obtenir lades riptiond'un servi e, ou biend'invoquer un servi eàdistan e. Quelques fon tionnalités supplémentaires, né essairesà la onstru tion d'appli ations omplexes desti-nées aux grilles de al ul, leur ont été rajoutées. Parmi elles- i gurent la gestion du y le de vieduservi eetlesystèmedenoti ation permettant àune entité delagrilled'être tenue informée des hangements d'état d'un servi e.
Cependant, la diéren e majeure qui oppose les Grid Servi es aux Web Servi es vient du fait queles Web Servi es sont desservi espersistants, qui survivent à leurs lients. Ils ne possèdentpasd'état, 'est-à-direqu'ilssontin apablesdesesouvenirdeleursintera tionsave les diérents lients. Les Grid Servi es doivent, quant à eux, pouvoir être temporaires : un lientpeutdemanderla réationd'unservi e,puis,lorsqu'iln'enaplusbesoin,sadestru tion. De plus, les Grid Servi es possèdent des états qui leur permettent de se souvenir de leurs intera tions ave les lients, e quipeut s'avérer extrêmement utile pour es derniers.
3.3.3 Sun GridEngine
3.3.3.1 Fon tionnalités prin ipales
SunGridEngine[66℄,danssadernièreversion(N1GridEngine6)[74 ℄permetdegérer e - a ement unensembledegrappesdema hinesappartenantàunemêmeorganisation( on ept appelé ampus grids).Sun GridEngine permetlasoumission detâ hesintera tives, detâ hes
parallèleset detâ hesenmodetraitementparlot. Lesystèmeordonnan e lestâ hessoumises de manièreàtenir ompte des ontraintesliéesà haquetâ he(mémoire,datebutoir,...),des prioritésdonnéesà haque lientetdelapolitiquedegestiondesressour esdé niesur haque site de lagrille.
Chaqueadministrateurd'unegrappe omposantlagrillepeutdé nirlapolitiquedegestion de ressour esqu'il souhaite voirappliquer sur sagrappe. Quatre politiques sont dé nies par le système:
Urgen y : le systèmeattribue une priorité de manièreautomatique à haque tâ he. La valeur de ette priorité est al ulée en fon tion des besoins en ressour es de la tâ he (bibliothèques spé i ques, quantité mémoire...), de la date butoir de la tâ he et de la durée depuislaquelle latâ he esten attente d'exé ution.
Fun tional : les prioritésentreles tâ hessont dé nies enfon tion de l'appartenan e du lient à ungroupe d'utilisateurs ouà unprojetspé i que.
Share-based : haquetâ he adroitàun ertainpour entagederessour es.Des pour en-tages peuvent être dé nis entre groupesd'utilisateurs,entre type d'appli ations... Override : e mode permet à l'administrateur de la grappe d'intervenir manuellement
surlapriorité de haquetâ he.
Lors de la soumission d'une tâ he, un pro l de ette tâ he est onstitué à partir de ontraintes fournies par le lient et de l'identité du lient (appartenan e à un groupe d'utili-sateurs ou à un projet). Le système hoisit ensuite la le d'exé ution la plus adéquate pour ette tâ he,en tenant ompte dupro l delatâ he,despolitiquesde gestionde ressour esde haquesite et de l'étatdesressour esde haque site.Une foislatâ he exé utée, unetra e de sonexé ution est onservée.
3.3.3.2 Ar hite ture
Grid Engine fait la distin tion entre quatre types de n÷uds ( gure 3.7) : master host, exe ution host,administrative host et submit host.
Adminstrative Host : es n÷uds permettent d'administrer lagrille (dé nition de droits d'utilisateurs,de priorités...)
Submit host : esn÷uds permettent àun utilisateurde soumettre et de ontr ler l'exé- ution de tâ hesuniquement enmodetraitement par lots. L'utilisateurse onne te sur unn÷udsubmit hostetpeutsoumettredire tementunetâ heenutilisantla ommande qsub ousuivre l'état d'unetâ he en oursde traitement grâ eà la ommandeqstat. Master host : 'est le n÷ud entral de l'a tivité d'une grappe. Ce n÷ud héberge deux
types de daemons : sge_qmaster et sge_s hed qui ontr lent l'ensemble des ompo-sants de lagrille. Le daemon sge_qmaster gère desinformations d'état on ernant les ma hines, les les d'exé ution, les tâ hes, la harge du système et les permissions des utilisateurs. Ilreçoitdes dé isionsde pla ement dudaemon sge_s hedd et transmet les requêtes desoumissions orrespondantes auxdaemons sge_exe d desn÷uds on ernés. Le daemon sge_s hedd utilise la onnaissan e que luifournit le sge_qmaster surl'état d'une grappe a n deprendre des dé isions d'ordonnan ement. Deuxtypes dedé isions peuvent être prises : le pla ement d'une tâ he sur un n÷ud ou la réorganisation et le hangement de priorité de tâ hes déjà pla ées a n de satisfaire les ontraintes de la nouvelle tâ he.
Par défaut, un n÷udMaster host joue également les r lesde administrative host et de submit host.
