Architecture 47 – la création et le redémarrage d’un point de reprise d’une tâche ;
– la surveillance des processus d’une tâche.
Bien entendu, les interfaces spécialisées ne possèdent pas forcément une implémentation de toutes les fonctions de l’interface générique. C’est par exemple le cas pour les fonctions liées aux points de reprise qui sont supportées par un système comme Kerrighed [124] ou par un système GNU/Linux doté de BLCR [4], mais pas par le système GNU/Linux standard.
Transfert de fichiers Afin d’assurer la vision SIU dans le système Vigne, nous avons conçu un service de transfert de fichiers qui prend en charge tous les transferts de fichiers néces-saires pour l’exécution d’applications distribuées sur une grille. Sans proposer un système de fichiers distribué comme LegionFS [170] ou GFarm [163] puisque l’utilisateur doit spécifier les fichiers associés à une tâche, Vigne offre plus de transparence que Globus où l’utilisateur doit explicitement effectuer les déplacements de fichiers avec GridFTP [39].
Système d’information Le système d’information de Vigne permet de localiser des res-sources dans le système qui correspondent aux critères requis par les applications des utili-sateurs. Comme nous l’avons vu dans la partie 3.2.1.1, le système d’information de Vigne est fondé sur un réseau pair-à-pair non structuré. Ainsi, ce service est tolérant aux défaillances multiples et adapté à la grande échelle d’une grille. Le système d’information de Vigne est détaillé dans le chapitre 4.
Allocation de ressources Le service d’allocation de ressources est chargé d’allouer des res-sources à une application. Les objectifs de l’allocation de resres-sources sont la répartition au mieux des applications sur les nœuds pour éviter les exécutions concurrentes. De plus, le ser-vice d’allocation de ressources permet aussi l’allocation de nœuds ayant une interconnexion réseau permettant l’exécution efficace d’applications composées de tâches communicantes.
L’allocation de ressources est détaillée dans le chapitre 4.
Gestion d’application Le service de gestion d’application est chargé de gérer le cycle de vie complet d’une application et de traiter les défaillances que peut subir une application. Le service de gestion d’application est un point critique dans le système. Ainsi, ce service est distribué et ne repose sur aucune entité fiable. Grâce au réseau pair-à-pair structuré et aux travaux de Louis Rilling [144], ce service peut être rendu hautement disponible. La gestion d’application est détaillée dans le chapitre 5.
Interface avec les utilisateurs et les moteurs externes Le système Vigne fournit des inter-faces avec le monde extérieur. Ces interinter-faces permettent d’exploiter le système pour effectuer par exemple une soumission d’application ou pour obtenir des informations sur une exécution.
Pour renforcer la vision SIU, l’interface externe de Vigne est accessible depuis n’importe quel nœud de la grille et de façon asynchrone. Par exemple, une application peut être soumise sur un nœud et le suivi de son exécution ou la récupération des résultats peuvent être effectués depuis un autre nœud.
48 Conception d’un système pour l’exploitation des ressources d’une grille de grande taille Il existe deux types d’interfaces externes. Tout d’abord, les utilisateurs peuvent soumettre leurs applications directement au système. Dans ce cas les utilisateurs fournissent une descrip-tion des ressources nécessaires au foncdescrip-tionnement de l’applicadescrip-tion (architecture processeur, quantité de mémoire vive nécessaire, système d’exploitation, etc) ainsi qu’une description de l’application (fichiers binaires, dépendances de synchronisation entre tâches, dépendances spa-tiales entre tâches, dépendances de précédence entre tâches, etc).
Il est aussi possible d’utiliser le système depuis un moteur externe qui est capable de gérer finement une application complexe où par exemple l’exécution de certaines tâches est condi-tionnée par le résultat d’autres tâches. Dans ce cas, un ensemble de fonctionnalités sont offertes, en plus de celles offertes à l’utilisateur, pour gérer par exemple le déplacement de fichiers de fa-çon transparente entre les nœuds utilisés par les tâches ou encore pour synchroniser des tâches entre elles. Nous avons illustré cette fonctionnalité dans le chapitre 7 où nous avons utilisé la plate-forme SALOME comme un moteur externe.
3.4 Synthèse
L’exploitation des ressources d’une grille pour l’exécution d’applications distribuées est d’autant plus complexe que la taille de la grille est grande, que les ressources sont volatiles et que le nombre d’utilisateurs est grand.
Afin de fédérer les ressources réparties sur une grille de très grande taille, nous proposons tout d’abord de concevoir un intergiciel dont les services sont complètement distribués pour éliminer les risques de surcharge de certaines entités du réseau, de goulet d’étranglement et de point critique sensible aux défaillances. Notre approche repose sur l’utilisation de réseaux pair-à-pair qui possèdent des propriétés d’auto-réparation et d’auto-organisation pour supporter la volatilité des nœuds d’une grille. Ainsi, la défaillance d’un nœud quelconque dans la grille peut être tolérée sans empêcher le système de fonctionner correctement. Nous proposons éga-lement d’utiliser un ordonnanceur complètement distribué fondé sur l’idée d’utiliser un agent d’ordonnancement par application.
Nous proposons un intergiciel capable d’utiliser des ressources aussi volatiles que les res-sources d’une grille de typecalcul pair-à-pair et capable d’utiliser des ressources exploitées de façon interactive ou à l’aide d’un gestionnaire de traitement par lots. Par conséquent, notre proposition peut s’appliquer à la fédération des ressources de n’importe quel type de grille.
Nous proposons un support transparent à l’exécution des applications distribuées composées de tâches communicantes et composées de tâches nécessitant le résultat d’autres tâches pour démarrer. Sans imposer la modification des applications, notre proposition permet d’exécuter une large gamme d’applications utilisées pour réaliser des simulations numériques, y compris lesworkflowsgérés par un moteur externe.
Finalement, nous proposons des concepts permettant d’exécuter des applications distri-buées de façon simple, efficace et fiable. La simplicité d’exécution est atteinte en offrant une vue de type SIU des nœuds qui masque leur distribution et leur volatilité. De plus, les opéra-tions liées à l’exécution d’une application sur une grille sont complètement automatisées grâce à un gestionnaire de cycle de vie intégré au système. Nous proposons un service d’allocation de ressources dont l’objectif est de répartir l’ensemble des applications qui sont soumises sur
Synthèse 49 l’ensemble des ressources de la grille en tentant d’éviter les exécutions concurrentes pour une exécution efficace. De plus, nous proposons un mécanisme de co-allocation de ressources dont l’objectif est d’allouer des ressources situées sur des nœuds possédant une interconnexion ré-seau permettant d’exécuter efficacement les applications composées de tâches communicantes.
Nous proposons un service de gestion d’application doté de mécanismes de supervision de nœuds et de tâches qui garanti que l’exécution d’une application puisse atteindre son terme en dépit des défaillances de nœuds ou des défaillances liées au contexte d’exécution qui ont une incidence sur le déroulement de l’exécution de l’application.
Nos contributions sont détaillées dans les chapitres 4, 5 et 7. À des fins d’évaluation, nous avons réalisé un prototype mettant en œuvre l’ensemble de nos propositions. Ce prototype ainsi que les résultats d’évaluation sont présentés dans les chapitres 6 et 7.
Chapitre 4
Le système d’information et
l’allocation des ressources dans le système Vigne
Nous présentons dans ce chapitre deux services du système Vigne qui sont le système d’information et le service d’allocation de ressources. Dans un premier temps, nous étudions les objectifs et la complémentarité de ces deux services. Ensuite, nous détaillons chacun des deux services en présentant nos contributions.
4.1 Système d’information et allocation des ressources, deux ser-vices étroitement couplés
4.1.1 Objectifs du système d’information
Nous avons vu que dans une grille les nœuds peuvent être nombreux, hétérogènes et vola-tils. Le système ou les utilisateurs doivent avoir accès à une entité qui recense ces ressources pour les utiliser. Cette entité est appelée système d’information. Le système d’information d’une grille doit être capable de répondre à une requête de demande de ressources. Les requêtes sont habituellement constituées d’un ensemble de critères qui définissent les pré-requis pour l’exécution d’une application. Ces critères peuvent concerner des aspects matériels comme une architecture processeur, une quantité de mémoire requise ou encore une topologie réseau mais aussi des aspects logiciels comme un système d’exploitation ou encore la présence d’une librairie donnée.
Dans le cas d’un système d’information supportant la réservation des ressources, une re-quête de demande de ressources peut contenir des informations comme la durée prévue pour l’application soumise. Cela permet au système d’ordonnancer plus finement les applications.
De plus, dans le cas d’un système d’information fondé sur un modèle économique comme ce-lui de Nimrod/G [60], une requête de demande de ressources peut en plus contenir des critères comme l’heure souhaitée pour récupérer les résultats ou le prix maximal que l’utilisateur est prêt à payer. Toutefois les systèmes d’information utilisant des mécanismes de réservation de
51
52 Le système d’information et l’allocation des ressources dans le système Vigne
<?xml version="1.0" encoding="UTF-8"?>
<jsdl:JobDefinition xmlns="http://www.example.org/"
xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl"
xmlns:jsdl-posix="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<jsdl:JobDescription>
<jsdl:Resources>
<jsdl:ProcessorArchitecture>
<jsdl:Exact>x86_64</jsdl:Exact>
</jsdl:ProcessorArchitecture>
<jsdl:OperatingSystem>
<jsdl:Exact>FreeBSD</jsdl:Exact>
</jsdl:OperatingSystem>
<jsdl:IndividualPhysicalMemory>
<jsdl:LowerBoundedRange>2097152.0</jsdl:LowerBoundedRange>
</jsdl:IndividualPhysicalMemory>
<jsdl:TotalCPUCount>
<jsdl:Exact>1.0</jsdl:Exact>
</jsdl:TotalCPUCount>
</jsdl:Resources>
</jsdl:JobDescription>
</jsdl:JobDefinition>
FIG. 4.1 – Exemple de requête de découverte de ressources au format JSDL