Soutenance mémoire
L’EXAMEN raisonné et méthodique du monde et de ses nécessités a largement profité du développement de l’informatique. Cette science formelle, dédiée à l’automatisation du traitement de l’information, livre des outils, toujours plus puissants, particulièrement adaptés à la validation et au raffinement de modèles scientifiques abstraits. Par exemple, la simulation informatique permet d’étudier des phénomènes physiques complexes comme la propagation d’ondes radio en milieu urbain ou la résistance d’une plate-forme pétrolière soumise à l’influence de la houle. Un autre exemple est l’automatisation du traitement de grandes masses de données en vue de leur analyse. C’est notamment le cas pour le projet LHC (grand collisionneur de hadrons), mis en opération le 10 septembre 2008 au CERN. Lors des expérimentations effectuées sur cet accélérateur de particules, les capteurs des six détecteurs pourront générer jusqu’à 15 péta-octets de données par an. Dans ce contexte, la qualité des résultats dépend en grande partie de la puissance de traitement des ressources informatiques : elles conditionnent le nombre d’itérations effectuées en un temps donné pour affiner le résultat de l’expérience.
Face à ces besoins non bornés en puissance de calcul et de stockage, les grilles informatiques semblent offrir une réponse des plus adaptées. Le principe est de mutualiser les ressources informatiques de plusieurs universités, instituts ou entreprises, pour profiter de l’agrégation des puissances de calcul et des espaces de stockage. Ces infrastructures souffrent cependant d’un problème majeur : leur utilisation s’avère être des plus compliquée, même pour les spécialistes du domaine. Ceci est dû en partie à l’échelle des grilles, composées de plusieurs milliers de ressources hétérogènes et réparties au sein de sites géographiquement distants. Ces sites font partie de multiples organisations, empêchant toute gestion des ressources à l’échelle globale. Déployer des applications distribuées sur de telles architectures requiert beaucoup d’efforts de la part des utilisateurs pourdécouvrir et sélectionner les ressources, installer et configurer les programmes, transférer les données, lancer les calculs, surveiller l’exécution puis, enfin, récupérer les résultats.
Des applications pour le calcul scientifique et des grilles de calculateurs
Les applications scientifiques sont réputées pour leurs besoins importants en puissance de calcul et en espace de stockage. Par exemple, la précision des résultats d’une simulation météorologique dépend directement du nombre d’itérations effectuées et de la finesse des mailles du domaine. Ainsi, l’objectif est d’effectuer le maximum d’itérations dans un temps imparti pour obtenir la prévision la plus précise possible. Dans cette section, nous définissons ce qu’est une application et plus précisément ce qu’est une application distribuée. Nous présentons ensuite les grilles de calculateurs, architectures naturelles pour l’exécution d’un certain nombre d’applications scientifiques.
Applications distribuées
Le programme informatique est une suite d’opérations compréhensibles par un humain et écrite par un développeur d’applications. Ce programme est compilé en un exécutable , une suite d’instructions dépendantes de la ressource informatique cible . L’exécutable est lancé sur une ressource avec un ensemble de paramètres. Le résultat est un processus. Il est défini par l’ensemble des instructions à exécuter ainsi qu’un espace mémoire pour stocker les données de travail. Plusieurs processus peuvent cohabiter sur une même ressource physique. Nous définissons notre vision d’une application.
Définition : application — Une application est définie comme un ensemble de programmes qui, une fois instanciés en processus, participent à un but commun, comme par exemple la résolution d’un problème ou la mise en place d’un service.
Lors de l’exécution d’une application, plusieurs processus peuvent interagir entre eux. Ceci est possible selon deux méthodes principales.
1. Les flots d’exécution attachés à un processus se partagent le même espace d’adressage en mémoire physique. Il est donc possible d’écrire et lire, de manière concurrente, les données en mémoire .
2. Les flots d’exécution peuvent s’échanger des données en communiquant de diverses manières, par exemple en s’envoyant des messages ou encore en faisant appel à des procédures distantes .
Définition : application distribuée — Une application distribuée est une application dont les processus communiquent entre eux sans partager le même espace d’adressage en mémoire physique.
Généralités
La conception d’une application parallèle ou distribuée est motivée par deux principales raisons.
Performance. Exécuter une application sous forme de plusieurs flots d’exécution concurrents permet de tirer parti de la puissance d’un ensemble de ressources physiques. L’une des approches consiste à adapter les applications pour s’exécuter sur des infrastructures distribuées. Certains problèmes comme le traitement de grandes matrices peuvent être résolus par des applications massivement distribuées : la matrice est découpée en sous-matrices, chacune prise en charge par un processus exécuté sur une ressource physique différente. Le gain de performance n’est cependant pas garanti : il faut s’assurer que le coût des synchronisations ne dégrade pas trop les performances du calcul global.
Disponibilité. Distribuer des processus sur différentes ressources physiques permet de faire face à des défaillances : si l’un des processus est sujet à une défaillance, les autres peuvent prendre le relais, sans risquer la perte du calcul global. Dans le cas d’un service rendu à des utilisateurs, la multiplication des processus pouvant assurer ce service permet de distribuer les requêtes entre plusieurs ressources. Cela permet aussi de choisir la ressource susceptible de répondre au mieux aux attentes de l’utilisateur.
Différents modèles de programmation distribuée
L’une des caractéristiques offertes par la programmation d’applications distribuées est la possibilité de faire communiquer les différents flots d’exécution entre eux. Ceci se traduit, dans les programmes, par l’utilisation de primitives dédiées à la gestion des communications, de la synchronisation des flots d’exécution ou encore du traitement des messages.
Afin de faciliter la conception de telles applications, différents modèles de communication ont été proposés et ce, dès la fin des années 70 .
Passage de messages. Le modèle du passage de messages est l’un des plus répandus en programmation distribuée. Il consiste à faire communiquer les différents flots d’exécution sur le principe des communications synchrones. Parmi les langages et protocoles de communication permettant de faciliter l’envoi et la réception de messages, nous pouvons citer MPI [54] (Message Passing Interface) et PVM [113] (Parallel Virtual Machine).
Appel de procédure à distance. Le modèle basé sur l’appel de procédure à distance (Remote Procedure Call en anglais) permet d’exécuter des instructions sur une ressource distante. Le nom de la procédure à exécuter ainsi que les paramètres associés sont envoyés à un serveur, qui effectue le traitement et retourne le résultat au client. Les canevas JavaRMI [128] et GridRPC [111] aident au développement d’applications basées sur l’appel de procédure à distance.
Composants distribués. Les modèles de composants permettent de représenter les programmes sous forme d’un assemblage de boîtes noires. Le développeur ne peut accéder qu’aux entrées et sorties de ces boîtes. Ces modèles se prêtent bien à la conception d’applications distribuées : le principe est de lancer l’exécution de différentes instances des composants sur des ressources géographiquement distribuées. Parmi ces modèles nous pouvons citer CORBA [101] et Fractal .
Ces différents modèles de communication peuvent être mis en œuvre au sein de deux principales architectures réseau.
Client-serveur. Cette architecture distingue deux rôles : le serveur est un processus passif qui écoute et attend les requêtes des clients. Ces requêtes sont traitées et le résultat est produit en retour. Un serveur peut souvent traiter plusieurs requêtes de clients différents en même temps. Le client est un processus actif, à l’initiative de toute communication. Un exemple d’architecture client-serveur est le terminal X [110], dans lequel le terminal utilisateur envoie à un serveur des commandes pour exécuter ses applications à distance. Les programmes et les données sont stockées sur le serveur. Ce modèle a pour avantage de centraliser les données sur le serveur et donc d’en faciliter la gestion. La centralisation en fait aussi son plus gros inconvénient : lorsque le nombre de clients devient trop important, le serveur ne peut traiter les requêtes dans un temps raisonnable, ce qui se traduit par des délais supplémentaires pour les utilisateurs. Si le serveur tombe en panne, l’architecture complète est paralysée.
Pair-à-pair. L’architecture pair-à-pair (Peer-to-Peer – P2P – en anglais) s’oppose au modèle client-serveur dans le sens où chaque processus est client et serveur à la fois. L’intérêt est ici de pallier les défaillances de processus en s’appuyant sur les autres instances. Cette architecture a démontré sa capacité à passer à l’échelle. Aujourd’hui, de nombreux systèmes pair-à-pair sont déployés sur Internet et permettent à des millions d’internautes de s’échanger des fichiers. Parmi les systèmes pair-à-pair nous pouvons citer Kazaa [147] et eDonkey .
|
Table des matières
1 Introduction
2 Contexte d’étude
2.1 Des applications pour le calcul scientifique et des grilles de calculateurs
2.1.1 Applications distribuées
2.1.2 Grilles de calculateurs
2.2 Une gestion transparente et autonome des applications
2.2.1 Externaliser la réalisation des calculs
2.2.2 L’informatique autonome
2.2.3 Conclusion
2.3 Concilier la dynamicité des applications avec les services de la grille
2.3.1 Interactions avec la plate-forme d’exécution
2.3.2 Outils de déploiement
2.4 Conclusion
3 Le déploiement d’applications sur GRID’5000
3.1 L’approche du déploiement sur la grille GRID’5000
3.1.1 Présentation de la plate-forme GRID’5000
3.1.2 Réserver des nœuds avec OAR
3.1.3 Déployer une application avec ADAGE
3.2 Étude de cas : un service de partage de données pour la grille
3.2.1 Architecture de JUXMEM
3.2.2 Héritage pair-à-pair avec la plate-forme JXTA
3.2.3 Déploiement de JUXMEM avec ADAGE
3.3 Conclusion
4 Contribution : CORDAGE, un service de co-déploiement et redéploiement
4.1 Vers une gestion plus transparente des interactions entre l’application et les ressources
4.1.1 Un scénario de déploiement additionnel
4.1.2 Un scénario de co-déploiement
4.1.3 La généricité
4.2 La vision CORDAGE
4.2.1 Phase 1 : description de l’application
4.2.2 Phase 2 : configuration de l’application
4.2.3 Phase 3 : construction de la représentation logique de l’application
4.2.4 Phase 4 : construction de la représentation des ressources physiques
4.2.5 Phase 5 : projection de l’arbre logique sur l’arbre physique
4.3 Fonctionnement du modèle
4.3.1 Expansion et rétraction
4.3.2 Co-déploiement
4.4 Conclusion
5 Architecture détaillée de CORDAGE
6 Conclusion
