Le Grid Computing
Le Globus Toolkit
Les composants du Globus Toolkit
Le Globus Toolkit est composé de 5 modules, assurant des fonctionnalités essentielles dans la technologie du Grid Computing. Le premier module assure la sécurité. Cette fonctionnalité est la plus importante d'une architecture de Grid Computing. En effet, pour le bon fonctionnement d'une grille, il est primordial de pouvoir identifier les utilisateurs qui "entrent" sur la grille, afin d'éviter toutes personnes indésirable(inconnus, hacker, saboteurs). De plus, ce module assure la confidentialité des données qui transitent entre chaque noeud, étant donné que le plus souvent les grilles utilisent les interconnexions qu'offrent Internet. Il est donc vital que ces données soient cryptées. Le second module permet d'assurer une fonctionnnalité indispensable: les échanges de données entre chaque noeud. Le module "Execution Management" est le module qui va permettre de soumettre l'exécution d'une tâche à une machine distante enregistrée sur la grille. Le module "Information Services" permet de surveiller et d'obtenir des informations sur la grille. Et enfin le module "Common Runtime" permet de développer des applications s'appuyant sur les 4 modules précédents.
Le module de Sécurité Grid Security Infrastructure (GSI)
Le module de sécurité a pour rôle:
Le Grid Security Infrastructure s'appuie sur une architecture PKI, avec une autorité de certification qui va signer les certificats de chaque utilisateur de la grille et donc attester de l'identité de chaque utilisateur. Il est possible de créer sa propre autorité de certification pour mettre en place sa grille, ou alors envoyer ces certificats à une autorité de certification (service payant). Le GSI s'appuie donc sur un algorithme asymétrique basé sur des clés publiques et privés (protégées par une passphrase). À chaque fois qu'un membre de la grille tente d'accéder à une ressource, le mécanisme d'authentification mutuelle se met en place.
Mécanisme d'authentification mutuelle
phase 1: le user1 demande l'accès au user2
phase 2: le user2 envoie son certificat qui contient la clé publique du user2
phase 3: le user1 vérifie l'authenticité du certificat du user2. Plus précisément, il vérifie la signature de l'autorité de certification aposée sur le certificat du user2 à l'aide de la clé publique de l'autorité de certification. À cet instant, le user1 est sûr de l'authenticité du certificat du user2
phase 2: le user2 envoie son certificat qui contient la clé publique du user2
phase 3: le user1 vérifie l'authenticité du certificat du user2. Plus précisément, il vérifie la signature de l'autorité de certification aposée sur le certificat du user2 à l'aide de la clé publique de l'autorité de certification. À cet instant, le user1 est sûr de l'authenticité du certificat du user2
phase 4, 5:
même chose que pour la phase 2 et 3 mais dans l'autre sens.
À cet instant, le user2 est sûr de l'authenticité du
certificat du user1
phase 6: le user2 envoie un message non crypté généré aléatoirement au user1
phase 7: le user1 crypte ce message à l'aide de sa clé privé et le renvoie au user2
phase 8: le user2 décrypte le message à l'aide de la clé publique du user1 à cet instant le user2 est sûr de l'identité du user1
phase 9,10 et 11: même chose que pour la phase 6, 7 et 8 mais dans l'autre sens. À cet instant, le user1 est sûr de l'identité du user2
phase 12: les échanges entre le user1 et le user2 peuvent commencer sans crainte
Le seul inconvénient de ce mécanisme est qu'à chaque fois qu'un utilisateur utilise sa clé privée, il doit entrer sa passphrase. Donc à chaque fois qu'un membre de la grille voudra accéder à une ressource sur la grille, il devra entrer sa passphrase. Ce qui pose de réels problèmes, et ne facilite pas son utilisation. Pour pallier ce problème, il suffit de mettre en place un Proxy Certificat (extension de SSL). L'utilisateur crée un Proxy Certificat, qui va agir en son nom. Le Proxy Certificat possède sa propre paire de clé privé et publique(certificat). Contrairement au certificat de l'utilisateur, le certificat du proxy est signé par l'utilisateur et pas par l'autorité de certification. Ainsi, le mécanisme d'authenfication mutuelle requiert une étape suplémentaire.
phase 6: le user2 envoie un message non crypté généré aléatoirement au user1
phase 7: le user1 crypte ce message à l'aide de sa clé privé et le renvoie au user2
phase 8: le user2 décrypte le message à l'aide de la clé publique du user1 à cet instant le user2 est sûr de l'identité du user1
phase 9,10 et 11: même chose que pour la phase 6, 7 et 8 mais dans l'autre sens. À cet instant, le user1 est sûr de l'identité du user2
phase 12: les échanges entre le user1 et le user2 peuvent commencer sans crainte
Le seul inconvénient de ce mécanisme est qu'à chaque fois qu'un utilisateur utilise sa clé privée, il doit entrer sa passphrase. Donc à chaque fois qu'un membre de la grille voudra accéder à une ressource sur la grille, il devra entrer sa passphrase. Ce qui pose de réels problèmes, et ne facilite pas son utilisation. Pour pallier ce problème, il suffit de mettre en place un Proxy Certificat (extension de SSL). L'utilisateur crée un Proxy Certificat, qui va agir en son nom. Le Proxy Certificat possède sa propre paire de clé privé et publique(certificat). Contrairement au certificat de l'utilisateur, le certificat du proxy est signé par l'utilisateur et pas par l'autorité de certification. Ainsi, le mécanisme d'authenfication mutuelle requiert une étape suplémentaire.
Le proxy certificat envoie en plus
son certificat et celui du user1. Le user2 authentifie le certificat du
user1 toujours avec le certificat de l'autorité de certification.
Une fois authentifié, le user2 authentifie le certificat de
proxy avec le certificat du user1.
Le module de transfert de Données
Dans ce module, on note la
présence deux outils essentiels, le Grid FTP et le RFT(Reliable
File Transfert). Le Grid FTP est un protocole normalisé, qui
respectent les RFC 959, 2228, 2389
Le module d'Information Service
Ce module est composé deux
modules important: Le MDS (Monitoring and Discovery Service) et WebMDS.
Le MDS est le module de surveillance et de découverte des ressources
sur la grille. Il consiste en un processus, l'aggregator, qui tourne
sans arrêt et qui interroge chaque noeud de la grille pour
obtenir des informations sur les ressources diponibles. Toutes les
informations récoltées sont stockées dans un fichier
XML qui est mise à la diposition de tous les membres de la
grille. Le WebMDS est un client graphique web permettant d'interroger et de
regarder les informations du fichier XML. Grâce à ce
module il est possible d'utiliser les ressources de la grille plus
efficacement.
Le module de gestion d'exécution
Le module de gestion
d'exécution est principalement représenté par
l'outil GRAM (Grid Ressources Allocation Manager). Il permet de
contrôler, localiser (lister), exécuter et annuler une
tâche sur une machine distante sur la grille. Il est aussi
prévu pour gérer des problèmes liés aux
tâches ou au lancement de n'importe quel programme (les
opérations fiables, la surveillance des états, la gestion
des informations de sécurité).
Le module common runtime component
Ce module fournit des outils (API,
Bibliothèques de fonctions etc.) pour permettre de développer des
applications basées sur le Grid Computing, en utilisant et en
communiquant avec les autres modules vus précédemment.
Ces APIs sont basés sur des Web Services (en ce qui concerne les
échanges). On note la possibilité de faire des
développement dans 3 langages de programmation:
- en C avec le C WS CORE
- en Python avec le Python WS CORE
- et en Java avec le Java WS CORE
Pour le langage Java, on note en plus
la présence d'un outil: le Java Commodity Grid Kit. Le CoG
Kit est un outil Java qui fournit un niveau d'abstraction à
l'API de Globus toolkit pour un usage plus facile. Il permet aux
utilisateurs de grid, aux développeurs d'applications, aux
administrateurs de grid d'utiliser, de programmer et d'administrer les
grilles à l'aide d'un framework de plus haut niveau. Ces kits
permettent un développement rapide d'application des grilles.
Ils encouragent le travail collaboratif et la réutilisation de
codes pour éviter la duplication des efforts concentrés
sur les environnement de recherche, les portails de science, le
middleware Grid.
Mise en oeuvre
Après avoir test้ plusieurs tutoriaux sur le Web, et pour une première approche en ce qui concerne la mise en oeuvre du Globus Toolkit, il est conseillé de suivre celui-ci. Il vous permettra de créer une architecture de grille avec plusieurs machines et vous fera découvrir des commandes simples (en ligne de commande) des différents modules du Globus Tolkit:- La création d'un proxy
- Le transfert de fichier avec le Grid FTP et RFT
- L'exécution d'une tâches sur machine distante enregistrée sur la grille
- L'interrogation des noeuds de la grille (Informations sur les ressources)