Le système d’information et l’allocation des ressources dans le système Vigne 

Télécharger le fichier pdf d’un mémoire de fin d’études

Les fédérations de grappes

Les fédérations de grappes sont un regroupement de grappes au sein d’une institution. Comme le montre la figure 2.2, le réseau à l’intérieur d’une grappe est de type SAN et le réseau reliant les différentes grappes est de type LAN. L’échelle d’une fédération de grappes peut aller de quelques centaines à quelques milliers de nœuds. Les nœuds d’une fédération de grappes sont plus stables que des stations de travail. L’instabilité est dans ce cas uniquement dûe aux pannes ou aux opérations de maintenance.

Le calcul pair-à-pair

Le calcul pair-à-pair est né avec les premiers projets de recherche d’extra-terrestres dans l’univers où une quantité astronomique de données obtenues grâce à un radio-télescope devait être analysée [42]. Dans le calcul pair-à-pair, les ressources sont majoritairement des ordinateurs personnels connectés à Internet. L’échelle considérée est très grande, de l’ordre du million de nœuds. Les principales caractéristiques sont une très grande volatilité des nœuds et un nombre non négligeable de participants frauduleux.

Les grilles hétérogènes

Un dernier modèle de grille, qui est la combinaison des trois autres, concerne les architectures hétérogènes. Comme le montre la figure 2.4, une telle grille peut être constituée de super-calculateurs, de fédérations de grappes, de réseaux de stations de travail ou encore d’ordinateurs personnels. Ces ressources sont connectées par des réseaux SAN ou LAN au sein d’une même institution et via un WAN entre deux institutions. L’échelle considérée peut être très grande, certaines ressources peuvent être très stables et d’autres très volatiles.

Des exemples de grilles existantes

Nous présentons ici quelques exemples de grilles qui ont été déployées à grande échelle1. TeraGrid [33] est un projet financé par la NSF (National Science Foundation) dont l’objectif est de fournir la plus puissante grille de calcul scientifique au monde. Le projet est réparti sur 9 sites du territoire des États-Unis qui sont reliés par un réseau optique de 30 à 40 Gb/s. TeraGrid possède une capacité de calcul 102 Tflops et une capacité de stockage de 15 Pb. Les ressources de TeraGrid sont très hétérogènes en termes de calculateurs (PC multi-processeurs d’architecture Intel, SGI, PowerPC, …), en termes de système d’exploitation (Linux, Unix propriétaires) et en termes de SAN. Les nœuds de TeraGrid forment une grille hétérogène multi-site.
EGEE (Enabling Grids for E-sciencE) [53] est un projet financé par la Commission Européenne dont l’objectif est la création d’une grille de production pour les scientifiques européens. EGEE compte plus de 20000 processeurs et une capacité de stockage de l’ordre de 5 Pb. EGEE utilise le réseau GÉANT2 (Gigabit European Academic Network) à 10 Gb/s. Les nœuds d’EGEE forment une grille hétérogène multi-site.
PlanetLab [27] est un projet atypique de grille dont l’objectif est de créer une grille planétaire. Actuellement, PlanetLab compte 753 nœuds répartis sur 363 sites. PlanetLab est une cible de choix pour l’expérimentation de technologies de type pair-à-pair ou de type stockage distribué. Les nœuds de PlanetLab forment une grille de type calcul pair-à-pair.
Grid’5000 [9, 57] est un projet national né d’une Action Concertée Incitative du ministère de la Recherche dont l’objectif est de créer une plate-forme expérimentale pour la recherche sur les grilles de calcul. La plate-forme Grid’5000 est actuellement composée de 9 sites ré- partis sur le territoire français. L’architecture de Grid’5000 est de type fédération de grappes. Actuellement, la plate-forme compte un peu plus de 2500 processeurs qui sont majoritairement d’architecture x86-64 (AMD Opteron) ou EMT64 (Intel Xeon). Grid’5000 s’appuie sur le réseau RENATER [30] qui permet de relier les différents sites à 1 ou 10 Gb/s. De plus, il est possible de reconfigurer entièrement le système présent sur les machines en déployant un nouveau système d’exploitation.
ApGrid (Asia Pacific Grid) [2]. C’est une grille d’expérimentation qui comporte des ressources (environ 1600 processeurs) réparties sur les continents asiatique, océanique et américain. Même si les nœuds interconnectés sont des grappes, l’échelle de cette grille et la qualité du réseau d’interconnexion font que sa structure est plutôt un cas particulier de grille hétérogène multi-site qu’une fédération de grappes.

Les modèles d’applications pour la grille

Les applications dites réparties permettent de tirer profit des ressources d’une grille. Nous présentons dans cette partie différents modèles d’applications réparties.

Sac de tâches indépendantes

Certaines applications scientifiques comme les applications paramétriques, sont composées d’un grand nombre de tâches indépendantes. Typiquement, pour les applications paramétriques, le même programme est exécuté plusieurs fois avec un jeu de données différent.

Maître/travailleurs

Les applications de type maître/travailleurs permettent d’ordonnancer un grand nombre de tâches sur un nombre limité de ressources. Ce modèle est aussi adapté aux applications paramétriques où dans ce cas, le maître distribue les jeux de données aux travailleurs qui exécutent tous le même code. Ce modèle permet plus de finesse que le précédent. Il permet notamment de distribuer des tâches tant que le calcul n’a pas atteint un point de convergence. Le nombre de tâches à exécuter n’est dans ce cas pas connu à l’avance.

Applications distribuées

Les applications distribuées ont des contraintes moins fortes en ce qui concerne le réseau que les applications parallèles. Elles sont souvent fondées sur le paradigme d’invocation de méthodes distantes et utilisent des environnements comme CORBA [128] ou Java RMI [17]. Le paradigme composant, d’un niveau d’abstraction encore plus élevé, simplifie la programmation. Les environnements tels que CCA [46] ou encore CCM [127] permettent de créer des applications suivant le paradigme composant.

Couplage de codes

Certains problèmes scientifiques font intervenir plusieurs disciplines. C’est par exemple le cas lorsque l’on veut comprendre l’origine de perturbations climatiques telles que le phé- nomène El Niño. Il faut en effet modéliser plusieurs phénomènes comme l’océan et l’atmosphère [154]. Dans ce cas, des applications existantes et spécialisées pour chaque discipline sont couplées pour effectuer une simulation globale prenant en compte plusieurs physiques et garantissant une meilleure modélisation de phénomène étudié. Typiquement les codes couplés sont des applications parallèles qui requièrent un réseau sous-jacent rapide. Selon le niveau de couplage, les codes couplés peuvent communiquer intensément, et peuvent parfois nécessiter l’utilisation d’un réseau rapide pour ne pas dégrader les performances globales.

Composition de modèles

Finalement, tous ces modèles peuvent être combinés dans une méta-application appelée workflow [93]. Un workflow est l’enchaînement de plusieurs tâches (ou groupes de tâches) qui peuvent s’échanger des données. Ainsi, une tâche (ou un groupe de tâches) d’un workflow peut devoir attendre le résultat d’autres tâches (ou groupes de tâches) pour démarrer.

Couches logicielles sur les nœuds de la grille

Les nœuds d’une grille peuvent posséder différentes couches logicielles, et cela indépendamment de l’architecture de la grille. Cela est déterminé par leur mode d’exploitation hors de la grille.
Le mode d’exploitation le plus simple est celui fourni par un système d’exploitation de type Linux, Unix ou Windows. Dans ce cas les ressources sont utilisées en mode interactif. Les ressources utilisant ce mode d’exploitation sont les ordinateurs personnels, les stations de travail ou les grappes dites beowulf [3].
Lorsque les ressources sont des grappes, il est possible qu’elles possèdent un mode d’exploitation plus performant que le mode beowulf. Deux approches existent pour cela : les gestionnaires de traitement par lots et les systèmes à image unique.
Les gestionnaires de traitement par lots permettent de gérer la concurrence d’accès aux ressources en utilisant des files d’attente, éventuellement dotées de priorités. L’exécution de certaines tâches est ainsi différée en attendant la libération des ressources nécessaires. Il existe un grand nombre de gestionnaires de traitement par lots ayant chacun différentes fonctionnalités d’ordonnancement comme le backfilling [155], le gang-scheduling [78] ou encore le co-scheduling [88]. Les systèmes propriétaires les plus utilisés en milieu industriel sont PBS Pro [1], Platform LSF [28] ou encore Sun Grid Engine [32]. Parmis les systèmes non proprié- taires nous pouvons citer Torque [35] ou OAR [62].
Les systèmes à image unique [25, 49, 95, 124] donnent l’illusion que la grappe est un multi-processeur. Des systèmes comme MOSIX [49] mettent en œuvre un ordonnancement global des processus qui permet à la charge d’être répartie sur toute la grappe. D’autres systèmes comme Kerrighed [124] proposent en plus des fonctions avancées comme une mémoire virtuellement partagée qui permet une programmation simplifiée des applications, des flux de communication efficaces ou encore un mécanisme de points de reprise.

Les différentes approches logicielles pour exploiter une grille

De par leur nature, les grilles de calcul sont plus complexes à utiliser qu’une station de travail ou qu’une grappe. Cela est dû à la distribution des nœuds qui peuvent être situés dans des domaines d’administration différents. De plus, de l’échelle des grilles découlent deux caracté- ristiques principales des nœuds qui sont la volatilité et l’hétérogénéité. De nombreux projets se sont intéressés à la gestion des ressources d’une grille et ont proposé des systèmes, appelés intergiciels, pour en simplifier l’utilisation.
Dans cette partie, nous présentons différents types d’intergiciels, classés par rapport aux fonctionnalités qu’ils offrent.

Intergiciels de communication

Les intergiciels de communication visent à simplifier l’accès à des ressources réparties sur une grille en fournissant un moyen aux ressources de communiquer entre elles.
JXTA [18] de Sun Microsystems est un ensemble de protocoles pair-à-pair génériques qui permettent à n’importe quel nœud connecté au réseau de communiquer et de collaborer.
NaradaBrokering [130] a pour objectif de fournir un environnement de communication unifié pour différents paradigmes de programmation tels que les services Internet (web services), les services de grille (grid services) et les modèles pair-à-pair. NaradaBrokering offre deux méthodes de communication qui sont l’échange de messages et la publication/souscription.
PadicoTM [71] est un environnement de communication à hautes performances qui permet de multiplexer l’accès au réseau depuis plusieurs intergiciels. PadicoTM optimise les communications lorsque cela est possible en profitant d’un accès direct aux cartes de réseaux rapides et en ajustant les paramètres de la couche de transport. De plus, PadicoTM permet l’exécution d’applications réparties de part et d’autre de coupe-feu ou de réseaux isolés accessibles uniquement via un nœud frontal.

Intergiciels de gestion globale des ressources

Dans cette partie, nous présentons les approches logicielles pour gérer de façon globale les ressources d’une grille. Au minimum, ces intergiciels fournissent des mécanismes permettant de soumettre une application sur la grille, de trouver des ressources, de déployer une application et de récupérer les résultats produits.

Table des matières

Introduction
1 Définitions 
2 La gestion des ressources dans les grilles 
2.1 Introduction aux grilles
2.1.1 Les architectures de grille
2.1.2 Des exemples de grilles existantes
2.1.3 Les modèles d’applications pour la grille
2.1.4 Couches logicielles sur les nœuds de la grille
2.2 Les différentes approches logicielles pour exploiter une grille
2.2.1 Intergiciels de communication
2.2.2 Intergiciels de gestion globale des ressources
2.2.3 Systèmes d’exploitation pour grille
2.2.4 Ordonnanceurs
2.2.5 Intergiciels pour la programmation d’applications de grilles
2.2.6 Bilan sur les différentes approches
2.3 Caractérisation des intergiciels pour grilles
2.3.1 Système d’information
2.3.2 Type d’ordonnancement
2.3.3 Support pour l’exécution d’applications sur la grille
2.3.4 Exécution fiable des applications
2.3.5 Tolérance du système aux défaillances
2.3.6 Protection des ressources mises à disposition dans la grille
2.3.7 Interface d’utilisation
2.3.8 Récapitulatif
2.4 Conclusion
3 Conception d’un système pour l’exploitation des ressources d’une grille de grande taille 
3.1 Objectifs
3.1.1 Grande échelle
3.1.2 Simplicité
3.1.3 Support d’une large variété d’applications
3.1.4 Exécution fiable des applications
3.1.5 Exécution efficace des applications
3.1.6 Sécurité
3.2 Approche
3.2.1 Système complètement distribué pour les grilles de grande taille
3.2.2 Large applicabilité du système
3.2.3 Exécution simple, efficace et fiable des applications sur la grille
3.3 Architecture
3.4 Synthèse
4 Le système d’information et l’allocation des ressources dans le système Vigne 
4.1 Système d’information et allocation des ressources, deux services étroitement couplés
4.1.1 Objectifs du système d’information
4.1.2 Objectifs de l’allocation de ressources
4.1.3 Influence de la découverte des ressources sur l’allocation des ressources
4.2 Le système d’information de Vigne
4.2.1 Utilisation de réseaux logiques non structurés
4.2.2 Optimisation des marches aléatoires pour l’allocation des ressources
4.2.3 Trouver des ressources rares dans le système d’information
4.2.4 Réflexion sur la pertinence de l’utilisation des réseaux logiques non structurés dans un système de grille
4.3 Le service d’allocation de ressources
4.3.1 Architecture du service d’allocation de ressources
4.3.2 Politiques d’allocation de ressources
4.3.3 Allocation de plusieurs ressources pour l’exécution d’applications communicantes
4.4 Conclusion
5 Exécution simple, efficace et fiable d’applications sur la grille 
5.1 La gestion des applications
5.1.1 Architecture du service de gestion d’application
5.1.2 La gestion du cycle de vie d’une application mono-tâche
5.1.3 La gestion du cycle de vie d’une application multi-tâche
5.2 Superviser les applications pour fiabiliser leur exécution
5.2.1 Architecture du superviseur d’application
5.2.2 Superviseur de tâches
5.2.3 Superviseur d’application
5.2.4 Réaction à une défaillance de tâche
5.3 Conclusion
6 Éléments de mise en œuvre et évaluation du système Vigne 
6.1 Quelques éléments de mise en œuvre
6.1.1 Prototype
6.1.2 Détails de mise en œuvre
6.2 Évaluation
6.2.1 Plate-forme pour les exécutions réelles et protocole expérimental
6.2.2 Passage à l’échelle de l’infrastructure
6.2.3 Comparaison de différents protocoles de découverte de ressources
6.2.4 Efficacité de l’allocation de ressources dans Vigne
6.2.5 Efficacité de la co-allocation de ressources dans Vigne
6.2.6 Fiabilité de l’exécution
6.3 Conclusion
7 Connexion de la plate-forme de simulation numérique SALOME au système Vigne
7.1 Description de la plate-forme SALOME
7.1.1 Vue d’ensemble de la plate-forme SALOME
7.1.2 Architecture
7.2 Objectifs de la connexion
7.2.1 Permettre à SALOME de profiter simplement de la puissance d’une grille
7.2.2 Simplifier le déploiement des applications
7.2.3 Exécuter les applications de façon fiable
7.3 Architecture modulaire de SALOME pour la connexion à un gestionnaire de ressources
7.4 Spécialisation du gestionnaire de ressources de SALOME pour la connexion à Vigne
7.4.1 Chargement d’un composant dans un nouveau conteneur
7.4.2 Chargement d’un composant dans un conteneur existant
7.4.3 Synthèse des fonctionnalités ajoutées à Vigne
7.4.4 Interactions entre SALOME et Vigne à l’aide d’une exemple simple
7.5 Évaluation avec une application industrielle
7.5.1 Architecture de l’application Saturne/Syrthes
7.5.2 Fonctionnalités sollicitées de Vigne
7.5.3 Expérimentation
7.6 Conclusion
Conclusion et perspectives

Télécharger le rapport complet