• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
rapport de stage.
 

rapport de stage.

on

  • 3,651 views

 

Statistics

Views

Total Views
3,651
Views on SlideShare
3,651
Embed Views
0

Actions

Likes
3
Downloads
161
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    rapport de stage. rapport de stage. Document Transcript

    • MINISTÈRE DE L’ENSEIGNEMENT ‫ﻭﺯﺍﺭﺓ ﺍﻝﺘﻌﻠﻴﻡ ﺍﻝﻌﺎﻝﻲ ﻭﺍﻝﺒﺤﺙ ﺍﻝﻌﻠﻤﻲ ﻭﺍﻝﺘﻜﻨﻭﻝﻭﺠﻴﺎ‬ SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE ET DE LA TECHNOLOGIE CENTRE NATIONAL DES SCIENCES ‫ﺍﻝﻤﺭﻜﺯ ﺍﻝﻭﻁﻨﻲ ﻝﻠﻌﻠﻭﻡ ﻭ ﺍﻝﺘﻜﻨﻭﻝﻭﺠﻴﺎ ﺍﻝﻨﻭﻭﻴﺔ‬ ET TECHNOLOGIES NUCLÉAIRES Rapport de stage Mise en place d’une Grille de Calcul Bengagi Wajdi Réalisé par : Encadré par : Mr. Moez Ben Hadj Hmida Mr. Mohamed Mehdi Abbas Etablissement d’origine : FSMPNT Juillet-Aout 2008
    • Page |2 Sommaire Le plan de ce Rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Liste des tableaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Table des figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Remerciements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2 les grilles de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1 Définition d'une grille de calcul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2 Notion d'organisation virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Caractéristiques d'une grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Les objectifs de la grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.1 Partage de ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 2.4.2 Accès sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.3 Utilisation de ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.4 Abolition de la distance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
    • Page |3 2.4.5 Normes ouvertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5 Applications des grilles de calcul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.1 Supercalculateur réparti (Distributed Supercomputing) . . . . . . . . . 22 2.5.2 Calcul haut-débit (High-Throughput Computing) . . . . . . . . . . . . . . . . 22 2.5.3 Calcul sur demande (On-Demand Computing) . . . . . . . . . . . . . . . . . . . . 23 2.5.4 Calcul Collaboratif (Collaborative Computing) . . . . . . . . . . . . . . . . . . . . 23 2.5.5 Génération, traitement et stockage d'énormes quantités de données (Data intensive Computing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6 Architecture générale d'une grille de calcul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.7 Types de communication dans une grille de calcul. . . . . . . . . . . . . . . . . . . . 27 2.7.1 Architecture Client/serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.7.2 Architecture Pair à Pair (Peer to Peer) . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.7.3 Architecture orientée services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.8 Différentes topologies de grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.8.1 Intragrille (en analogie avec Intranet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.8.2 Extragrille (en analogie avec Extranet) . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.8.3 Intergrille (en analogie avec Internet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.9. Les intergiciels de grille de calcul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.9.1 Legion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
    • Page |4 2.9.2 Globus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Globus 3 Globus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.But de l'intergiciel Globus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3. 2 Les voies de standardisation de Globus Toolkit. . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 OGSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 3.2.2 OGSI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3 Les services de Globus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.1 Gestion des ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3.2 Gestion de communications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3.3 Service d'information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3.4 Service de sécurité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.4 Evolution et architecture de l'intergiciel Globus. . . . . . . . . . . . . . . 47 4 Schéma Générale du la grille 4.1 Réseaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2 Composant de la grille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.1 Machines esclaves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.2 Machines mètres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
    • Page |5 5 Procédure d'installation 5.1. Préparation à l'installation de Globus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 5.1.1. Installation du système Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.1.2 Configuration du réseau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.1.3 Création des comptes utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.1.4 Création des répertoires d'installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.1.5 Installation des outils nécessaires pour Globus Toolkit 4.0.1. 61 5.2 Installation de l'Autorité de Certification : SimpleCA. . . . . . . . . . . . . . . . 63 5.3 Configuration des services de grille de calcul . . . . . . . . . . . . . . . . . . . . . . . 65 5.3.1 Configuration du service gridftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.3.2 Lancement des web containers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 5.3.3 Configuration du service RFT (Releable File Transfer) . . . . . . . . . 67 5.3.4 Configuration du service GRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.4 Soumission des Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.4.1 Description d'un job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4.2 Exemples de soumission de différents jobs. . . . . . . . . . . . . . . . . . . . . . 73 Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 A Procédure d'installation d'une grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 A.1 Préparation à l'installation de Globus Toolkit 4.0.1 . . . . . . . . . . . . . . . . . . . . 79
    • Page |6 A.1.1 Création d'un utilisateur quot;Globusquot; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 A.1.2 Création d'un répertoire d'installation de Globus Toolkit 4.0.1. . . . . 80 A.1.3 Installation des outils nécessaires pour Globus Toolkit4.0.1 . . . . . . . . 80 A.2 Installation de Globus Toolkit 4.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 A.3 Installation de l'Autorité de Certification : AC . . . . . . . . . . . . . . . . . . . . . . .. . . . 84 A.3.1 Création des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 84 A.3.2 Exécution du script d'installation . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 85 A.3.3 Installation du service GSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 A.3.4 Demande de certificat pour un noeud hôte quot;Host Certificatesquot; . . . . 88 A.3.5 Signature du certificat du noeud hôte quot;Host Certificatesquot; . . . . . . . . . . 88 A.3.6 Signature du certificat de L'utilisateur quot;Globusquot; . . . . . . . . . . . . . . . . . . . . 89 A.3.7 Signature du certificat de l'utilisateur 'user1' . . . . . . . . . . . . . . . . . . . . . . . . 91 A.3.8 Création du certificat du 'container' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.3.9 Ajout des autorisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.3.10 Vérification du certificat de l'utilisateur 'Globus' . . . . . . . . . . . . . . . . . . . 93 A.3.11 Vérification du certificat de 'user1' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 A.4 Installation de certificat pour plusieurs machines . . . . . . . . . . . . . . . . . . . 94 A.5 Installation de postgresql-8.0.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 A.5.1 Configuration de postgresql : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 A.6 Installation du service 'gridFTP' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
    • Page |7 A.6.1 Configuration : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 A.6.2 Lancement du proxy : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.6.3 Test du service gsiftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.6.4 Lancement du serveur 'gridftp' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 A.6.5 Erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 109 A.7 Lancement des Services Web . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 110 A.7.1 Création d'un exécutable pour le lancement des Services Web. . . . 110 A.8 Configuration de RFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 113 A.8.1 Création du fichier quot;pg_hba.confquot; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.8.2 Création d'un utilisateur de la base 'postgres' . . . . . . . . . . . . . . . .. . . . . . . . 114 A.8.3 Création de la base 'rftDatabase' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 A.8.4 Test du fonctionnement de RFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 A.9 Installation du service GRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 A.9.1 Edition du fichier 'sudoers' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 A.9.2 Edition du fichier 'globus_gram_fs_map_con_g.xml' . . . . . . . . . . . .. . 117 B Exécution de jobs sur la grille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 B.1 Syntaxe 'RSl' de description de jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 B.2 Tests de soumission d'un job existant sur la machine locale . . . . . . . . 120 B.2.1 Test 1 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 B.2.2 Test 2 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
    • Page |8 Le plan de ce Rapport Le rapport est composé de Cinq parties : Chapitre 1 Dans ce chapitre en décrit le rôle de grilles de calcul ainsi que les différentes raisons qui ont conduit à leur apparition. Chapitre 2 Ce chapitre est dédié à la présentation de la notion de grille en présentant un état de l'art sur ce domaine, qui renferme une définition des différents types de grille ainsi que la présentation des parties qui constituent l'architecture globale de la grille. Chapitre 3 Le chapitre 3 décrit l'intergiciel Globus ainsi que ses étapes d'évolution, son architecture et les services offerts par ce dernier. Chapitre 4 Il décrit l'architecture réseau utilisée dans la grille ainsi que les performances des ressources physiques fournies pour mettre en places notre grille de calcul. Chapitre 5 Présente une procédure d'installation de l'intergiciel Globus Toolkit version 4.0.1 et les différents outils nécessaires à la mise en place d'une grille de calcul.
    • Page |9 Liste des tableaux 2.1 Les principaux services de Globus. . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.1 Tableau des adresses des nœuds de la grille de calcul. . . . . . . . . 59
    • P a g e | 10 Table des figures 1.1 Un scénario de grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2 Architecture d'une grille de calcul en couche. . . . . . . . . . . . . . . 25 2.1 Conception des services de Globus en trois pyramides [6]. . . . 39 2.2 Principe du sablier [6]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.3 Associations entre source et destination dans Nexus [6] . . . . . 44 2.4 Modèle conceptuel de MDS [6]. . . . . . . . . . . . . . . .. . . . .. . . . . . . . 43 2.5 Protocoles de sécurité de GT4 [6]. . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.6 Evolution de Globus [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.7 Schéma de l'architecture GT4, Les boîtes partagées dénotent le code GT4, les boîtes blanches représentant le code utilisateur [1]. 48 3 Schéma général d’une grille de calcul . . . . . . . . . . . . . . . . . . . . 52 4.1 Etape de soumission d'un job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.2 Graphe de transition pour un job. . . . . . . . . . . . . . . . . . . . . . . . . . 72 B.1 Soumission de job en local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 B.2 Soumission d'un job sur un nœud distant. . . . . . . . . . . . . . . . . . 122
    • P a g e | 11 Remerciements Remerciements Nous avons une vive dette de gratitude envers tous ceux qui nous ont aidés à rassembler les faits qui constituent l'indispensable fondation de ce travail. Je tiens à remercier Monsieur Moez Ben Hadj Hmida pour sa disponibilité et ses prestigieux conseils qui ont été d'une grande aide dans la réalisation du projet et la rédaction de ce document, spécialement ses relectures critiques et multiples des différentes versions du mémoire et les nombreuses suggestions constructives de sa part. Je tiens également à remercier Monsieur Mohamed Mehdi Abbas, pour son aide, et ses idées constructives dans le développement de cette mémoire. Enfin, je tiens à remercier tout le personnel du Service informatique et Réseau de centre national de sciences et technologies nucléaire qui ont attribué de près ou de loin au bon déroulement de notre stage.
    • P a g e | 12 Chapitre 1 Introduction Générale e nos jours, les applications de recherche scientifique utilisent des données de grandes tailles et nécessitent une puissance de calcul de plus en plus importante. Initialement ces données étaient développées sur des infrastructures composées d'un ensemble de superordinateurs centralisés. Cependant, les besoins scientifiques et technologiques sont en croissance rapide ce qui requière des capacités de calcul et de stockage encore plus importantes. Pour satisfaire ces exigences on a fait recours à des plateformes hétérogènes partageant des ressources de calcul et de stockage de plusieurs ordinateurs interconnectés entre eux par un réseau internet.
    • P a g e | 13 Ces plateformes utilisées comme ressource unique et unifiée mènent au concept de quot;grillesquot; qui apparaît comme un service public défendant la notion quot;d'informatique à la demandequot;. La notion de grille de calcul s'inspire énormément de la grille d'électricité construite au début du vingtième siècle. Le terme quot;The Gridquot; ou quot;grille de calculquot;, a été introduit pour la première fois aux Etats-Unis durant les années quatre vingt dix pour décrire une infrastructure de calcul répartie utilisée dans des projets de recherche scientifique et industrielle. Afin d'exploiter cette infrastructure matérielle, il était nécessaire de concevoir une plateforme permettant la résolution des problèmes scientifiques à partir des composants logiciels répartis facilement intégrables tout en cachant la complexité des données, des algorithmes et l'hétérogénéité des composants matériels tel que l'intergiciel quot;Globusquot; fondé par 'Ian Foster'. C'est dans ce cadre que se situe mon stage de technicien au sein du centre nationale d'activité nucléaire de Tunisie. Qui vise à mettre en place. L’intergiciel quot;Globusquot;.
    • P a g e | 14 Chapitre 2 Les Grilles de Calcul a notion de grille de calcul appelée aussi quot;Grid Computingquot; est une passerelle pour un modèle d'informatique répartie permettant d'exploiter pleinement les ressources et les capacités offertes vue comme une conséquence logique des progressions technologiques. Dans un premier lieu, nous définissons le concept de grille, présentons ses caractéristiques, ses objectifs ainsi que sa forme et son architecture.
    • P a g e | 15 2.1 Définition d'une grille de calcul Une grille de calcul est dénie comme : quot;Une infrastructure matérielle et logicielle fournissant un accès able, cohérent, à taux de pénétration élevé et bon marché à des capacités de traitement et de calcul [5]quot;. Ainsi cette définition a été raffinée dans l'article quot;The Anatomie of the Gridquot; écrit par 'Ian Foster', 'C. Kesselman' et 'S. Tuecke' [6] où ils déclarent la grille de calcul comme étant quot;une coordination de ressources partagées, une résolution de problèmes d'organisations virtuelles, dynamiques et multi-institutionnellesquot;. Le concept principal se manifeste dans la capacité de négocier le partage des ressources parmi un ensemble de participants tels que fournisseurs et consommateurs. En effet le partage concerné n'est pas principalement l'échange de dossier mais plutôt l'accès direct aux ordinateurs, logiciels, données, qui est recommandé dans la résolution des problèmes collaboratifs et les stratégies d'équilibrage de ressources émergeant dans l'industrie, la science et la technologie. Ce partage est nécessairement commandé avec des fournisseurs de ressources et des consommateurs définissant clairement et soigneusement ce qui est partagé, qui a le droit de partager, et les conditions dans lesquelles le partage se produit [4]. 2.2 Notion d'organisation virtuelle
    • P a g e | 16 Mettre en œuvre une grille de calcul, c'est vouloir partager des ressources. Or les différents utilisateurs et les différentes organisations n'ont ni les mêmes besoins, ni les mêmes préoccupations ; ils n'utiliseront donc pas nécessairement l'outil de la même façon. Les données des uns n'intéressent pas forcément les autres. Chaque domaine a ses propres contraintes de sécurité et fait appel à des ressources de différentes natures. Dans la phase de conception d'une grille, chacun des participants doit être libre de choisir les ressources qu'il souhaite partager et les conditions qu'il donne à ce partage. Ainsi, on définit des Organisations Virtuelles qui peuvent prendre la forme d fournisseurs d'applications, de fournisseurs de données stockées, mais également de consommateurs de ressources. La durée de vie des Organisations Virtuelles peut être variable, tout comme leur composition et les buts qu'elles poursuivent. Ces dernières sont concrètement des groupes d'utilisateurs qui ont des besoins communs, des chercheurs d'une même discipline par exemple, ou des groupes de serveurs mettant à disposition des ressources.
    • P a g e | 17 2.3 Caractéristiques d'une grille de calcul La grille de calcul ou 'Grid Computing' reprend les principes élémentaires du clustering, qui peut être considéré comme l'un des ancêtres de la grille d'ordinateurs. Mais il est préférable de faire la distinction entre une grille et un cluster. Un cluster au sens strict est une grappe de machines homogènes reliées entre elles à travers un réseau local. A l'opposé, une grille regroupe un ensemble de machines reliées en réseau, pouvant être distantes de plusieurs mètres, voire de plusieurs kilomètres (voir FIG 1.1).
    • P a g e | 18 Une grille de calcul se caractérise par : -L'hétérogénéité : Une des caractéristiques inhérentes aux grilles de calcul selon plusieurs points de vue : matériel, logiciel, politiques de sécurité, contraintes d'exploitation, profil des utilisateurs, etc. Toute la complexité liée aux différences concernant ces aspects doit être invisible à l'utilisateur final d'où la nécessité d'un grand effort de coordination entre tous les sites participant à une grille. Les contraintes d'exploitation et de qualité de service de chaque site ne doivent pas être sacrées par leur intégration à une grille. En effet chaque site doit conserver une totale autonomie concernant ses politiques d'accès, d'exploitation et d'évolution aussi bien côté matériel que logiciel, tout en gardant la compatibilité avec les services offerts à travers la grille [1]. -L'ouverture : La globalisation de ressources suppose un certain degré d'ouverture des sites vers le monde extérieur. Cette ouverture peut poser des problèmes auxquels une solution doit être trouvée sans compromettre la sécurité du site. Un exemple qui illustre bien ce point concerne l'authentification des utilisateurs. Un des apports du modèle de grille de calcul est l'accès transparent pour le chercheur aux ressources informatiques dispersées. En d'autres termes, il n'est pas tenu de se connecter à une machine appartenant à un site quelconque pour utiliser les ressources de ce dernier. Une connexion sur un des sites appartenant à la grille devrait sure pour lui donner accès aux autres sites de la même grille [3]. -Passage à l'échelle (Scalabilité) : Le nombre des utilisateurs et des ressources dans une organisation virtuelle est dynamique chose qui
    • P a g e | 19 requiert l'ajout ou la suppression d'un utilisateur ou d'une ressource vue comme action habituelle dans le système de grille de calcul. Pour cette raison, de nouvelles contraintes de sécurité sur les applications et les algorithmes de gestion de ressources ont eu lieu tel que le 'mapping' des sujets globaux vers des sujets locaux, la centralisation de l'autorité de certification, le grand nombre d'utilisateurs, etc. -La tolérance aux pannes : L'ouverture dans une grille de calcul n'est pas sans risques. Pour tirer partie des ressources disponibles dans une telle grille, un système d'information de l'état et de la structure de ces ressources est nécessaire [9]. Il permet la découverte de ressources utilisables à un moment donné et des relations entre elles ainsi que l'occurrence de pannes. La publication de ces informations généralement sensibles d'un point de vue sécurité doit se faire sans compromettre ni l'intégrité et la sécurité de chaque site ni celles de l'ensemble des sites partenaires. 2.4 Les objectifs de la grille de calcul 2.4.1 Partage de ressources Il permet l'accès à la grille pour l'utilisation des ressources distantes ou pour profiter des logiciels existants. Cette capacité de partage implique plus qu'un simple transfert de fichiers, il requiert un accès direct aux logiciels, aux ordinateurs et aux données. Elle peut même permettre un accès direct à des capteurs, à des télescopes et à d'autres appareils distants et de les commander.
    • P a g e | 20 Les ressources sont la propriété de personnes différentes, ce qui signifie qu'elles relèvent de domaines administratifs différents, qu'elles exécutent des logiciels différents et qu'elles sont régies par des politiques de sécurité et de contrôle d'accès, également différentes [2]. 2.4.2 Accès sécurisé C'est une conséquence directe de la première idée. Le partage de ressources se traduit par certains problèmes liés à la réalisation de la grille telle que la politique concernant l'accès, l'authentification et l'autorisation. En effet, la grille doit être extrêmement souple et dispose d'un mécanisme de comptabilisation qui sera utilisé pour décider d'une politique d'établissement des prix d'utilisation de la grille [2]. 2.4.3 Utilisation de ressources C'est là que la grille commence réellement à être intéressante, même pour les privilégiés qui disposent d'abondantes ressources informatiques, car quelle que soit l'abondance de nos ressource, il arrive toujours un moment où se crée une le d'attente d'utilisateurs désireux d'en disposer. Un mécanisme d'affectation efficace et automatique des jobs à différentes ressources permettra la réduction des fils d'attente [2].
    • P a g e | 21 2.4.4 Abolition de la distance Les connexions à haute vitesse entre ordinateurs rendent possible une grille véritablement mondiale. Grâce à la généralisation de l'utilisation des fibres optiques dans les systèmes de télécommunications, doublent environ tous les neuf mois. Certains grands réseaux fonctionnent maintenant à 155 mégabits par seconde (Mb/s), alors qu'en 1985 les centres de supercalculateurs des États- Unis étaient connectés à 56 kilobits par seconde (Kb/s) soit une amélioration d'un facteur de 3000 en 15 ans. Bien sûr, la distance ne sera jamais complètement abolie, parce que quelqu'un aura toujours un problème à traiter sur la grille, pour lequel les connexions les plus rapides sembleront lentes [2]. 2.4.5 Normes ouvertes Des normes spécifiques à la grille sont en cours d'élaboration par une entité de normalisation du même genre, le Global Grid Forum. Fédérant plus de 5000 chercheurs et praticiens individuels, cet organe représente une force significative en matière d'édiction de normes et d'élaboration d'éléments permettant le travail en commun. Actuellement, une norme connue sous le nom OGSA (Architecture ouverte de services de grille) est considérée comme une référence clé pour les projets d'élaboration de grilles [2].
    • P a g e | 22 2.5 Applications des grilles de calcul Les principales applications des grilles de calcul peuvent être classées en cinq catégories: 2.5.1 Supercalculateur réparti (Distributed Supercomputing) Une grille de calcul pourra agréger une importante quantité de ressources an de fournir la puissance de calcul nécessaire pour de nombreuses applications et que même les supercalculateurs les plus modernes ne peuvent pas fournir. Selon la nature et l'étendue de la grille, les ressources agrégées pourront être composés de stations de travail d'une université ou même de supercalculateurs des organismes de recherche d'un pays. 2.5.2 Calcul haut-débit (High-Throughput Computing) Une grille de calcul sera utilisée pour ordonnancer en parallèle une importante quantité de tâches indépendantes les unes des autres. Comme exemples d'applications nous pouvons citer la recherche de clés cryptographiques, les simulations de molécules et l'analyse du génome.
    • P a g e | 23 2.5.3 Calcul sur demande (On-Demand Computing) Une grille de calcul pourra fournir les ressources pour satisfaire les demandes à court terme d'une application que les ressources locales ne sont pas en mesure d'y assurer (cycles processeur, stockage...). Le dé principal pour les concepteurs de telles grilles est la nature dynamique et aléatoire des demandes faites par les utilisateurs qui peuvent constituer une large population. 2.5.4 Calcul Collaboratif (Collaborative Computing) Cette classe d'applications inclut les applications d'interaction entre humains dans des environnements de simulation en temps réel (conception et interaction avec un nouveau moteur d'avion, conception d'un plan urbain...). 2.5.5 Génération, traitement et stockage d'énormes quantités de données (Data intensive Computing) Dans de telles applications, une grille de calcul pourra absorber et stocker d'importantes quantités d'information générées. Comme exemple d'applications nous pouvons mentionner la production d'une carte de l'univers, la prévision météorologique à long terme, les simulations quantiques.
    • P a g e | 24 2.6 Architecture générale d'une grille de calcul L'architecture de la grille est souvent décrite en termes de quot;couchesquot;, dont chacune assure une fonction spécifique. D'une façon générale les quot;couches hautesquot; sont axées sur l'utilisateur (quot;centréesquot; sur celui- ci), tandis que les quot;couches bassesquot; sont plus orientées vers les ordinateurs et les réseaux (quot;centréesquot; sur le matériel)(voir FIG 1.2).
    • P a g e | 25 Au niveau le plus bas, la couche réseau assure la connectabilité des ressources sur la grille. Au-dessus de celle-ci, la couche ressources, constituée des ressources effectives faisant partie de la grille, telles que les ordinateurs, les systèmes de mémoire, les catalogues de données électroniques, et mêmes des capteurs, tels que des télescope ou d'autres instruments qui peuvent être connectés directement au réseau. La couche intergicielle assure les fonctions permettant aux divers éléments (serveurs, mémoires, réseaux, etc.) de participer à un contexte de grille unifiée. Cette couche intergicielle peut être considérée comme l'intelligence qui fédère les divers éléments le quot;cerveauquot; de la grille. Parmi les fonctions requises, nous citons : Ordonnancement : un ordonnanceur devra trouver la machine • la plus appropriée pour exécuter les tâches qui lui sont soumises. Les ordonnanceurs peuvent aller du plus simple (allocation de • type round-robin) au plus compliqué (ordonnancement à base de priorités). Les ordonnanceurs réagissent à la charge de la grille. Ils déterminent le taux de charge de chaque ressource ande bien ordonnancer les prochaines tâches. Ils peuvent être organisés en hiérarchie avec certains • interagissant directement avec les ressources, et d'autres (méta ordonnanceurs) interagissant avec les ordonnanceurs intermédiaires. Ils peuvent aussi superviser le déroulement
    • P a g e | 26 d'une tâche jusqu'à sa terminaison, la soumettre à nouveau si elle est brusquement interrompue et la terminer prématurément si elle se trouve dans une boucle infinie d'exécution. Réservation : Il est possible dans les grilles de calcul de réserver • les ressources à l'avance et ceci an de garantir une certaine qualité de service et de respecter certaines échéances. Pour cela l'intergiciel devra fournir un système de réservation permettant aux utilisateurs d'exprimer leurs besoins en ressources et d'effectuer la réservation. Services d'information et d'annuaire : Une grille est un • environnement où le nombre et la charge des ressources sont dynamiques. Un objectif lors de la conception d'une grille est de rendre les ressources facilement accessibles à tous les processus. Il est alors nécessaire de fournir des mécanismes permettant d'enregistrer et de découvrir ces ressources et d'identifier leur état tel que le Service de nom. Comme tout système réparti, une grille devra permettre de référencer ses ressources d'une façon standard et uniforme. La couche située au niveau le plus élevé de la structure est la couche application, qui comprend les diverses applications scientifiques, techniques, de gestion, financières des utilisateurs, leurs portails, ainsi que les boîtes à outils de génie logiciel de ces applications. C'est la couche vue par les utilisateurs de la grille. Il existe d'autres façons de décrire cette structure en couches. Par exemple, des spécialistes aiment utiliser le terme quot; fabrique quot; pour
    • P a g e | 27 désigner l'ensemble de l'infrastructure physique de la grille, incluant les ordinateurs et les réseaux de transmission (en anglais quot; fabrics quot;). Par ailleurs, dans la couche intergiciel se scinder en une couche de protocoles, de ressources et de connectabilité et, au-dessus de celle- ci, une couche de services collectifs. 2.7 Types de communication dans une grille de calcul 2.7.1 Architecture Client/Serveur Dans les systèmes client/serveur où les données peuvent être distribuées à travers les serveurs multiples ou centralisés, chacun avec ses propres administrateurs, des services de sécurité sont indispensables ainsi que des caches pour éviter la congestion du réseau. 2.7.2 Architecture Pair à Pair (Peer to Peer) Une infrastructure de type pair à pair dans une grille de calcul est généralement constituée d'un ensemble de nœuds dont chacun se comporte à la fois comme un client et un serveur an de satisfaire les besoins tel que : partage de fichiers, utilisation du temps CPU
    • P a g e | 28 inutilisé, collaboration entre équipes, délocalisation des services fournis par une telle organisation, calculs distribués... 2.7.3 Architecture orientée services En définissant l'architecture d'une grille de calcul, les concepteurs peuvent adopter deux approches différentes : se focaliser sur les ressources ou bien sur les services qu'offrent ces ressources. Dans le dernier cas l'architecture est dite orientée services. Dans OGSA on s'intéresse à la notion de service : les ressources de calcul, de stockage, de communication qui sont présentées comme des services [6]. Dans une telle architecture, l'interopérabilité (caractéristique fondamentale d'une grille de calcul) est assurée en standardisant les interfaces des services de la grille et les protocoles permettant d'invoquer les opérations de ces interfaces. Ainsi plusieurs implémentations peuvent correspondre à une même interface : c'est le principe de la quot;Virtualisationquot; des services. Pour assurer cela, un langage standard est nécessaire pour décrire les interfaces. Dans le cas d'OGSA le protocole WSDL (quot;Web Services Description Langagequot;) est utilisé. WSDL permet de découpler la définition de l'interface, de l'implémentation et de l'invocation du service.
    • P a g e | 29 2.8 Différentes topologies de grilles Nous répertorions les grilles d'un point de vue topologique en trois types par ordre croissant d'étendue géographique et de complexité. 2.8.1 Intragrille (en analogie avec Intranet) La plus simple, composée d'un ensemble relativement simple de ressources et de services et appartenant à une organisation unique. Les principales caractéristiques d'une telle grille sont la présence d'un réseau d'interconnexion, d'un domaine de sécurité unique et d'un ensemble relativement statique et homogène de ressources. 2.8.2 Extragrille (en analogie avec Extranet) Une extragrille étend le modèle en agrégeant plusieurs intragrilles. Les principales caractéristiques d'une telle grille sont la présence d'un réseau d'interconnexion hétérogène haut et bas débit (LAN / WAN), de plusieurs domaines de sécurité distincts, et d'un ensemble plus ou moins dynamique de ressources. 2.8.3 Intergrille (en analogie avec Internet) Une intergrille consiste à agréger les grilles de multiples organisations, en une seule grille. Les principales caractéristiques
    • P a g e | 30 d'une telle grille sont la présence d'un réseau d'interconnexion hétérogène, de plusieurs domaines de sécurité distincts et ayant parfois des politiques de sécurité différentes, et d'un ensemble très dynamique de ressources. 2.9. Les intergiciels de grille de calcul La grille de calcul est un point focal de toutes ces activités, et permet d'envisager des projets utilisant des ressources géographiquement distribuées et partagées par des groupes d'utilisateurs. Parmi ces projets qui ont acquis plus de maturité au niveau académique nous citons : 2.9.1 Légion C'est un système entier, résolument pair à pair, développé à l'université de Virginie, aux Etats-Unis. Initié dès 1993, le projet a donné lieu à une première version publique en 1997. Plus qu'un simple système d'exploitation, Legion est considéré comme un middleware, ou plus exactement un quot; méta système quot;. Le logiciel sert d'interface entre le propre OS de l'utilisateur, et un nombre quasi infini de ressources, distribuées partout sur le réseau, et hébergées par les autres utilisateurs de Legion. Chaque utilisateur a donc l'impression de ne quot;voirquot; que son propre ordinateur, mais fait en réalité appel à de multiples quot;ressourcesquot; répartis sur le réseau. Legion est un système orienté objet, et la notion de quot;ressourcesquot; partagées est
    • P a g e | 31 à comprendre au sens large (librairies, codes sources, fichiers exécutables...), d'autant que les créateurs du système se flattant du fait qu'il soit capable de gérer plusieurs milliers de milliards de ressources, disponibles sur des plates-formes matérielles et logicielles de toutes natures. Bien sûr, conformément aux principes mêmes du pair-à-pair, chaque utilisateur peut décider ou non d'ouvrir les propres ressources de son ordinateur aux autres utilisateurs, et ce de façon particulièrement fine. 2.9.2 Globus C'est un projet 'open source' visant à créer les logiciels et les outils nécessaires pour la conception et la mise en œuvre de grilles de calcul. Globus est principalement développé aux Etats-Unis dans l'Argonne National Laboratory par l'équipe d’Ian Foster. Les travaux sur Globus ont commencé en 1997 et le projet est toujours actif. Le quot; Globus Toolkit quot; est formé d'un ensemble de composants. Son architecture modulaire permet d'apporter les modifications et les améliorations d'une manière rapide et efficace. Globus est devenu le standard 'ipso facto' utilisé dans les projets de grilles de calcul. De nombreuses entreprises ont ainsi adopté Globus pour servir comme base de leurs produits commerciaux pour les grilles de calcul. Dans le prochain chapitre, nous détaillerons les principales fonctionnalités offertes par Globus à ses utilisateurs en termes de sécurité, de services d'information, de gestion des communications, de gestion des ressources et de traitement des données.
    • P a g e | 32 2.9.2 UNICORE Il vise à développer des mécanismes permettant un accès sécurisé et uniforme à des plateformes de calcul de haute performance et leurs ressources associées [7]. UNICORE se base, sur des outils, des standards et des mécanismes existants an de fournir les fonctionnalités demandées. Les objectifs des concepteurs du système visent à [8] : Fournir à l'utilisateur une interface graphique intuitive et facile • à utiliser. Fournir des mécanismes de sécurité suffisants. • Utiliser des technologies sous -jacentes déjà existantes et • approuvées. Avoir une architecture basée sur le concept de tâches • génériques ou abstraites. Avoir un impact minimal sur les ressources sous-jacentes. • UNICORE est conçu pour supporter une exécution non interactive de tâches (batch jobs). Ainsi il supporte, à travers l'exploitation de la nature parallèle des applications, le méta calcul asynchrone (en contraste avec d'autres systèmes tels que Globus et Légion qui supportent un modèle de méta calcul synchrone).
    • P a g e | 33 Conclusion Les besoins en puissance de calcul pour la recherche scientifique fondamentale dépassent souvent les possibilités qu'ore la technologie. Il faut donc inventer constamment de nouvelles solutions pour permettre à la recherche de disposer d'outils adaptés. La grille de calcul reprend l'idée qu'une application lourde puisse être découpée en petites tâches isolées, confiées à des ordinateurs différents au travers d'un réseau et dont l'aspect économique est particulièrement séduisant. Dans la suite, nous nous intéresserons à expliciter un intergiciel de grille de calcul quot; Globus quot; an de mettre en relief les mécanismes de grille ainsi que son objectif.
    • P a g e | 34 Chapitre 3 Globus Ans ce Chapitre nous présentons le Projet Globus. C'est un projet 'open source' visant à créer les logiciels et les outils nécessaires pour la conception et la mise en œuvre d'une grille de calcul. Globus est principalement développé aux Etat Unis, au sein de l'quot;Argonne National Laboratoryquot; par l'équipe de 'Ian Foster'. Le projet Globus a commencé en 1997 et il est toujours actif. Dans une première partie nous présenterons son but et ses voies de standardisation, dans la suite de ce chapitre nous allons présenter les principales fonctionnalités offertes par Globus à ses utilisateurs en termes de sécurité, de services d'information, de gestion des communications, de gestion des ressources et de traitement des
    • P a g e | 35 données. Enfin une vision globale de son évolution et de son architecture actuelle. 3.1 But de l'intergiciel Globus Le quot;Globus Toolkitquot; est vu comme une boite à outils facilitant le développement d'applications basée sur la notion de grille. En effet, ses fondateurs implémentent une couche logicielle supplémentaire qui fait abstraction à l'hétérogénéité de l'environnement ainsi qu'une architecture modulaire permettant d'apporter des modifications et des améliorations d'une manière rapide et efficace. Le programmeur ne se préoccupe plus de l'hétérogénéité des nœuds aussi bien au niveau de l'authentification qu'au niveau de la recherche des ressources disponibles. 3.2 Les voies de standardisation de Globus Toolkit Afin d'atteindre le but mentionné ci-dessus, les développeurs de Globus cherchent à établir et respecter des normes dans le déploiement des services. Ces normes se basent sur les travaux de recherche du quot; Global Grid Forum quot; qui ont recensé les besoins des Utilisateurs des grilles de calcul et de la manière d'implémentation. Ces recherches ont abouti à la notion d'OGSA (Open Grid Services Architecture) et d'OGSI (Open Grid Service Infrastructure). 3.2.1 OGSA L'quot;Open Grid Service Architecturequot; (OGSA) permet de spécifier les bases des grilles de calcul. En effet pour avoir un quot;frameworkquot; largement adopté il faut respecter les définitions des interfaces, des
    • P a g e | 36 comportements, des modèles de ressource, etc. C'est ce qu'on appelle la plate-forme OGSA qui repose sur : -La spécification de l'ensemble des services importants tels que les applications scientifiques et de commerce électronique. -L'identification des services de base fondés sur des protocoles et des langages standards et ouverts comme WSDL (Web Service Description Langage), SOAP (Simple Object Access Protocol), et XML. -La spécification à un niveau relativement élevé des fonctionnalités requises par ces services et les interactions entre elles. 3.2.2 OGSI En se basant à la fois sur les technologies de grille et les Services Web, l’OGSI (Open Grid Services Infrastructure) définie les mécanismes de création, de gestion et d'échange d'informations entre les services de grille. Cet échange comprend la découverte des services déjà créés et leur utilisation qui permet une gestion des services sur le long terme tout en étant sécurisé et résistant aux pannes. 3.3 Les services de Globus Globus fournit les fonctionnalités et les services de base nécessaires à la construction de grille de calcul tel que la sécurité, la gestion des ressources, la communication. Il est composé d'un ensemble de modules ayant chacun une interface permettant aux services de niveau supérieur d'invoquer ses mécanismes.
    • P a g e | 37 -Localisation et allocation des ressources : ce composant permet aux applications d'exprimer leurs besoins en fournissant les mécanismes d'identification des ressources adéquates. -Communication : ce composant permet aux différentes applications de communiquer entre elles selon plusieurs modes : communication par message, mémoire distribuée, appel de procédure à distance, etc. -Information sur les ressources : permet d'obtenir des informations sur l'état et la structure globale du système. -Mécanismes de sécurité : ce composant fournit les mécanismes d'authentification et d'autorisation des utilisateurs. -Création et lancement des processus : permet de préparer l'environnement de lancement et d'exécution d'un processus. - Accès aux données : Accès performant et consistant aux données stockées dans les fichiers et les bases de données. La table ci-dessous (TAB 2.1) montre les différents services offerts par Globus qui peuvent être organisés en trois pyramides construites sur une base commune : le composant de sécurité (GSI), sur laquelle reposent la gestion des ressources (GRAM), les mécanismes de communication (Nexus) et les services d'information(MDS)(voir FIG 2.1). Services nom Description Gestion des ressources GRAM Allocation des ressources et gestion des processus. Communication Nexus Services de communication unicast et multicast. Sécurité GSI Authentification et autorisation. Information MDS Information sur la structure et l'état de la grille. Tab. 2.1 - Les principaux services de Globus.
    • P a g e | 38 Fig. 2.1 -Conception des services de Globus en trois pyramides [6]. Fig. 2.2 -Principe du sablier [6]. 3.3.1 Gestion de ressources Elle est assurée par le service GRAM quot;Globus Ressource Allocation Managerquot; qui permet la gestion et la supervision des ressources.
    • P a g e | 39 Vue la multitude de services de bas niveau utilisés, le service GRAM masque les différentes technologies de gestion de ressources de bas niveau. Ainsi les différents services de haut niveau n'ont à se préoccuper que de l'interfaçage avec GRAM. Chaque entité GRAM est responsable d'un ensemble de ressources opérant selon une politique commune et spécifique au site dans lequel elles se trouvent. Cette dernière est souvent implémentée par un ordonnanceur tel que 'Fork', 'Condor' ou 'LSF' quot;Load Sharing Facility quot;. Le service GRAM s'interface ainsi avec ce système et traduit les requêtes des services de haut niveau en requêtes compréhensibles par le gestionnaire de bas niveau. De cette façon, les administrateurs des ressources d'une grille de calcul peuvent choisir les outils de gestion de bas niveau qui leur conviennent selon une API unifiée (celle de GRAM). Avec l'API de GRAM, les besoins en ressources sont exprimés en un langage appelé RSL quot;Ressource Spécification Langagequot;. A partir de GRAM des politiques globales de gestion de ressources (au niveau de la grille) peuvent être construites et implémentées par des courtiers (quot;Resource Brokersquot;). Un exemple d'architecture telle que définie dans la figure 2.2, sera détaillée dans le chapitre IV. 3.3.2 Gestion de communications Les services de communications entre processus dans Globus sont assurés par la librairie de communication Nexus. Le choix de cette librairie est adopté pour deux raisons : -la première est que Nexus supporte plusieurs outils de développement parallèles et de calcul distribués tel que MPI (Message Parssing Interface) , le deuxième est qu'il est conçu pour
    • P a g e | 40 supporter des méthodes de communication co-existantes et de créer des processus concurrents. Le principe de l'architecture de Nexus est similaire à celui de GRAM : fournir une API unifiée aux services de haut niveau (MPI, RPC, CORBA...) tout en s'interfaçant avec une multitude de services de bas niveau (TCP, UDP...). Les services de communication de Nexus sont utilisés extensivement dans l'implémentation des autres services de Globus. Les besoins des applications varient de la communication fiable par messages à la communication multipoint non fiable. Les protocoles IP et TCP ne sont pas en mesure de répondre à ces besoins. Nexus est alors utilisé pour combler ce manque. Les communications dans Nexus sont définies en employant deux abstractions : les liens de communication (quot;Communication Linksquot;) et les requêtes de service distant (quot;Remote Service Requestquot; ou RSR). Un lien de communication est formé par l'association d'une source (quot;startpointquot;) et d'une destination (quot;endpointquot;). Une opération de communication est initiée en appliquant une requête de service distant à une source. Cet appel de procédure asynchrone permet de transférer des données de la source vers toutes les destinations auxquelles elle est reliée. Plusieurs sources peuvent être associées à une destination et vice versa ce qui permet de construire des structures de communication complexes illustrés par la figure ci-dessous (FIG 2.3). Les liens de communication dans Nexus peuvent être transposés sur différentes méthodes de communication sous-jacentes chacune ayant ses propres caractéristiques : protocole utilisé, sécurité, qualité de service. En associant un attribut à un lien de communication entre une source et une destination, une application peut contrôler la
    • P a g e | 41 Fig. 2.3 - Associations entre source et destination dans Nexus [6]. Méthode de communication employée. 3.3.3 Service d'information Globus offre le composant quot;Metacomputing Directory Servicequot; ou MDS permettant l'accès aux informations telles que processeurs, mémoires, bandes passantes, interface réseau. Il offre les composants, les outils et les APIs nécessaires pour la découverte, la publication et l'accès aux informations statiques ou dynamiques. MDS utilise le standard LDAP quot;Lightweight Directory Access Protocolquot; comme base pour la représentation et l'accès aux données. Plus spécifiquement, il est constitué des modules suivants : -quot;Grid Resource Information Servicequot;(GRIS) : Les serveurs GRIS peuvent se trouver dans plusieurs endroits dans une grille et contiennent toute information concernant les machines qui y sont enregistrées. L'architecture de GRIS permet d'étendre facilement la nature des informations qu'ils peuvent contenir. Un serveur GRIS ne contient jamais les informations concernant toutes les machines d'une grille pour ne pas charger le serveur.
    • P a g e | 42 -quot;Grid Index Information Servicequot;(GIIS) : Tous les serveurs GRIS d'une grille sont enregistrés lors de leur démarrage avec un serveur GIIS. Ce dernier contient des informations concernant la localisation des serveurs GRIS et les noms des machines enregistrées. Ainsi un utilisateur peut avoir des informations sur une machine particulière en contactant le serveur GIIS. Un seul serveur GIIS dans une grille constitue un point fragile. Pour cela des serveurs secondaires sont mis en place pour assurer une bonne tolérance aux pannes. D'autre part les serveurs GIIS peuvent être organisés selon une hiérarchie comme le système DNS. -Fournisseur d'information (quot;Information Providerquot;) : Ce composant assure la traduction des informations concernant les ressources selon le schéma de MDS. - Client MDS : Ce composant permet d'interroger MDS pour obtenir des informations concernant une ressource.
    • P a g e | 43 La figure ci-dessous montre le modèle conceptuel de MDS (voir FIG 2.4). Fig. 2.4 -Modèle conceptuel de MDS [6]. 3.3.4 Service de sécurité Notion de sécurité
    • P a g e | 44 Elle est assurée par une architecture de sécurité complexe pour un bon fonctionnement de grille appelée GSI (Grid Security Infrastructure) qui permet de garantir les trois propriétés nécessaires pour sécuriser un système d'information notant : la confidentialité, l'intégrité et la disponibilité de l'information. En effet, Globus repose sur la cryptographie à clé publique. Ainsi pour utiliser les mécanismes de sécurité de GSI, il faut créer une paire de clés (publique/privé) et demander la délivrance d'un certificat numérique (certificat X.509) d'une autorité de certification (AC) pour chaque nœud de la grille. A la fin, pour chaque nœud on a trois fichiers contenant respectivement la clé publique de l'AC, la clé privée du nœud et le certificat numérique du nœud. Le fichier contenant la clé privée du nœud est particulièrement sécurisé et ne disposant que de droit de lecture par son propriétaire pour ne pas y permettre un accès illicite par des utilisateurs non autorisés. De plus la clé privée n'est fonctionnelle qu'avec l'introduction d'un mot de passe par l'utilisateur, cela permet d'introduire une couche de sécurité supplémentaire. Authentification et autorisation A cause de l'environnement hétérogène et géographique étendu des grilles de calcul, l’authentification des machines et des utilisateurs est un point important. En effet, il faut établir une relation de confiance entre les différents nœuds de la grille malgré les politiques de sécurité qui peuvent varier entre les organisations. Pour cela GSI offre un mécanisme d'authentification mutuelle et d'autorisation qui utilise les protocoles SSL/TLS comme base.
    • P a g e | 45 Principe d'échange des clés dans Globus : Globus assure la procédure clés suivante pour chaque requête d'exécution de tâche : 1. Le nœud A envoie son certificat au nœud B. 2. B s'assure que le certificat est valide et extrait l'identité et la clé publique de A du certificat. 3. B génère un nombre aléatoire et l'envoie à A. 4. Lors de la réception de ce nombre, A le chiffre avec sa clé privée en demandant à l'utilisateur d'entrer son mot de passe et l'envoie à B. 5. Lors de la réception du nombre chiffré, B le chiffre avec la clé publique de A et s'assure qu'il est le même. A est alors authentifié par B. 6. La procédure est répétée dans le sens inverse pour que A authentifie B. 7. B transporte le nom de l'utilisateur se trouvant dans le certificat en un nom d'utilisateur local au nœud. Pour cela un fichier appelé grid-mapfile est utilisé. Il contient une entrée pour chaque utilisateur de la grille :'/O=Grid/O=Globus/OU=grid.cnstn/CN=gridcnstn' Globus. Cette ligne permet de transporter le nom de domaine (DN) de l'utilisateur gridcnstn appartenant à la grille en un nom d'utilisateur local Globus. C'est la phase d'autorisation. Sign- Délégation et Single Sign-On Si chaque lancement d'une tâche nécessite le mot de passe utilisateur, alors un nombre important de tâches ou un appel récursif de ces dernières rend la demande de mots de passe impraticable. La création d'un Proxy est une solution offerte par le GSI comme mécanisme de délégation permettant de diminuer au maximum le nombre de fois ou l'utilisateur fournit son mot de passe. Ce mécanisme de délégation
    • P a g e | 46 est une extension des mécanismes de SSL. Ainsi un utilisateur authentifié par un nœud peut créer un Proxy, ce dernier lui délègue son autorité. Un Proxy consiste en un nouveau certificat numérique avec une nouvelle paire de clés publique/privée. Il contient l'identité de l'utilisateur légèrement modifiée. Fig. 2.5 - protocoles de sécurité de GT4 [6]. Ce certificat est signé par l'utilisateur lui-même et non pas par l'Autorité de Certification. De plus un Proxy a une durée de vie limitée. Il est alors utilisé pour assurer la procédure d'authentification mutuelle et d'autorisation sans avoir à impliquer à l'utilisateur. La figure 2.5 ci-dessus présente l'architecture de service de sécurité et résume les différents protocoles offerts par Globus, exemple Globus Toolkit 4 (GT4). Communications chiffrées Le service GSI ne prévoit pas une procédure de chiffrement prédéfinie entre les nœuds pour ne pas surcharger les échanges. Mais puisque il utilise SSL comme système sous-jacent, la procédure
    • P a g e | 47 de création d'une clé secrète commune entre deux nœuds est possible. Cette clé sera utilisée par un algorithme de chiffrement tel que DES pour chiffrer les échanges. D'autre coté GSI assure par défaut L'intégrité des données. 3.4 Evolution et architecture de l'intergiciel Globus Comme tout projet open source, toujours actif, Globus a subit plusieurs stades d'évolution. Ces étapes sont les résultats de la migration de certains composants d'une Fig. 2.6 - Evolution de Globus [1]. version à une autre et de l'ajout de nouveaux composants. La convergence vers la notion de Services Web dans la grille de calcul est l'ambitieux objectif que se donne Globus. Ainsi le schéma ci-dessus (FIG 2.6) explique cette évolution en fonction de l'échelle de temps. La version1 de Globus Toolkit était juste une définition ou métaphase de services GRAM et MDS. Globus Toolkit2 est venu avec l'ajout du
    • P a g e | 48 service GridFTP, RFT et l'intégration des paquetages de kits quot;Grid Packaging Toolkitquot; (GPT), ensuite Globus toolkit3 est conforme à la norme OGSA, qui vise à combiner la technologie des Services Web à celle du Grid Computing. D'ailleurs cette version regroupe un certain nombre d'outils standards en open source (XML, SOAP). Enfin avec Globus Toolkit4 les protocoles ont migré vers les quot;Web Services Resource FrameWorkquot; (WSRF) qui sont des services web incluant les services de grilles. Des nouveaux composants sont aussi ajoutés comme exemple quot;C WS-Corequot;, ainsi les codes sources des bibliothèques des Services Web sont écrit en C et C++ bien qu'elles étaient uniquement en java dans la version Globus Toolkit3. Voici une présentation de l'architecture générale de Globus Toolkit dans sa dernière version et illustrant ses différents composants : Fig. 2.7 -Schéma de l'architecture GT4, Les boîtes partagées dénotent le code GT4, les boîtes blanches représentent le code utilisateur [1].
    • P a g e | 49 En effet cette figure (FIG 2.7) comprend : -Un ensemble de service d'implémentation (la moitié inférieure de la figure) mettant en évidence des services d'infrastructure utiles qui adressent la gestion d'exécution (GRAM), les données d'accès et de transfert (GridFTP, RFT, etc). - Trois quot;containersquot; peuvent être utilisés pour accueillir des services utilisateur écrits en Java, Python, et C, respectivement. Ces quot;containersquot; fournissent l'implémentation de sécurité, gestion d'état et d'autres mécanismes fréquemment requis en établissant des services. Ils étendent les services open sources avec le soutien d'une gamme de Services Web(WS), y compris WSRF, WS-Notification et le WS- Security. - Un ensemble de bibliothèques qui chargent les programmes d'utilisateurs en java, C.... Par exemple, dans le cas de GridFTP, il y a non seulement un client simple (globus-URL-copie) mais également la bibliothèque de XIO qui est chargée de l'intégration des transports alternatifs. - Une infrastructure commune de sécurité et de transmission de messages permetl'interopérabilité entre différentes applications et services. Conclusion Dans ce chapitre nous avons présenté l'intergiciel Globus, qui est toujours un projet en constante évolution permettant aux communautés académiques et industrielles, tel que IBM et Platform Computing, de créer des produits libres ou commerciaux. Il offre une
    • P a g e | 50 multitude de services et d'outils de haut niveau comme GridFTP, RFT... qui seront détaillés dans le chapitre qui suit ou nous allons mettre en place une grille de calcul utilisant le middleware Globus Toolkit4 comme interface de communication entre les différents nœuds.
    • P a g e | 51 Chapitre 4 de Schéma Général de la grille
    • P a g e | 52 4.1 Réseaux Au début et comme un premier schéma nous avons utilisé 4 machines qu’on a nommé esclaves puisqu’ils sont des simples PC, et deux machines maîtres avec la performance décrite au modules « 4.2 », et voici un schéma qui décrit ce Réseaux: Fig. 3- Schéma Général d’une Grille de Calcul 4.2 Composantes de la grille Notre grille comporte deux types de machines : 8 machines esclaves. • 4 machines maîtres. • 4.2.1 Machines esclaves Les machines admettent les caractéristiques techniques suivantes:
    • P a g e | 53 Processeurs: • -nombre de processeurs supportés par la carte mère : deux (2). -nombre de processeurs supportés par la carte mère : deux (2). -type de processeurs : dual-core 64-bits; -bus système : 1066 MHz; -Vitesse d'horloges des processeurs: 2.5 GHz; -mémoire cache -level : L1 & L2; -capacité : 2Mo L2 pour chaque core; Mémoire : • -type de memoire: SDRAM fully buffered DIMM. -vitesse : 667 MHz; -capacité mémoire maximale : 16 Gbytes; -capacité mémoire installée : 16 Gbytes; Carte Mère: • -Bios en mémoire flash; -bus Système : 1066 MHz; -ports :
    • P a g e | 54 un (01) port parallèle; o deux (02) ports série (clavier & souris) o un (01) port COM; o huit (08) port USB; o un (01) port SCSI; o un (01) slot PCI-X libre (64-bits & 133MHz); o Disque dur: • -type : SATA 2; -capacité 250Gbytes; Carte Graphique • -Mémoire vidéo installée ; 256 Mo; Carte Son • -son stéréo 16 bits; Cartes Réseaux : • -Carte réseau intégré Ethernet 10/100/100Mbps; 4.2.2 Machines maitres Les machines admettent les caractéristiques techniques suivantes: Processeurs: • -nombre de processeurs supportés par la carte mère : deux (2).
    • P a g e | 55 -nombre de processeurs supportés par la carte mère : deux (2). -type de processeurs : Quad-core 64-bits; -bus système : 1066 MHz; -Vitesse d'horloges des processeurs: 2.33 GHz; -mémoire cache -level : L1 & L2; -capacité : 2Mo L2 pour chaque core; Mémoire : • -type de memoire: SDRAM fully buffered DIMM. -vitesse : 667 MHz; -capacité mémoire maximale : 32 Gbytes; -capacité mémoire installée : 16 Gbytes; Carte Mère: • -Bios en mémoire flash; -bus Système : 1066 MHz; -ports : un (01) port parallèle; o deux (02) ports série (clavier & souris) o un (01) port COM; o
    • P a g e | 56 huit (08) port USB; o un (01) port SCSI; o un (01) slot PCI-X libre (64-bits & 133MHz); o Disque dur: • -type : SATA 2; -capacité 250Gbytes; Carte Graphique • -Mémoire vidéo installée ; 128 Mo; Carte Son • -son stéréo 16 bits; Cartes Réseaux : • -Carte réseau intégrée Ethernet 10/100/100Mbps;
    • P a g e | 57 Chapitre 5 Procédure d'installation de l'intergiciel Globus Toolkit 4.0.1 Ce chapitre couvre l'installation de base de l'intergiciel Globus Toolkit dans sa version 4.0.1 dont le but est d'obtenir un groupe de stations qui peuvent servir de nœuds pour une grille de calcul en utilisant un réseau LAN (Local Area Network) et de mettre en relief l'utilisation pratique des services de cet intergiciel.
    • P a g e | 58 Cette procédure permet aussi d'avoir un nœud qui peut servir comme autorité de certification ainsi que des Services Web et des outils qui permettent à des machines extérieures d'accéder aux ressources après authentification comme utilisateurs autorisés. Pour chaque étape, des tests sont effectués, tests nécessaires à la validation de l'installation. 5.1 Préparation à l'installation de l'intergiciel Globus Toolkit 4.0.1 L'installation de cette plate-forme nécessite l'installation du système d’exploitation (Linux dans notre cas), du logiciel Globus 4.0.1, et d'autres logiciels utiles au déploiement et à la réalisation, principalement quot;Java JDKquot;, quot;Apache Antquot; et quot;PostgresSQLquot;. L'installation de Globus a posé beaucoup de problèmes, et plusieurs tentatives d'installation ont dû être faites. Ce logiciel n'est pas une version commerciale, et il reste à l'usage des universitaires et des centres de recherche. La version de Linux utilisée est Scientifique Linux version 5.1 et version 4 préconisée pour l'installation de Globus. L'installation de Scientifique Linux fût facile notamment grâce à l'interface graphique d'installation simple et détaillée et à l'aide en ligne utilisée par la version 3. 5.1.1 Configuration du réseau
    • P a g e | 59 Lors de l'installation du système Linux, nous avons dû attribuer un nom et une adresse IP à chaque nœud de la grille pour servir par la suite à la configuration de l'intergiciel Globus Toolkit 4.0.1. Remarque : Les noms des différents hôtes doivent avoir tous la forme suivante : quot;nom_machine.nom_domainequot; qui est une exigence de l'intergiciel Globus Toolkit. Dans notre cas, notre grille est configurée de la manière suivante : Nom de la machine Adresse IP Description poste1.grid.cnstn 192.168.12.1 Machine client/serveur. poste2.grid.cnstn 192.168.12.2 Machine client/serveur. poste3.grid.cnstn 192.168.12.3 Machine client/serveur. poste4.grid.cnstn 192.168.12.4 Machine client/serveur. Poste5.grid.cnstn 192.168.12.5 Machine client/serveur. Poste6.grid.cnstn 192.168.12.6 Machine client/serveur. Poste7.grid.cnstn 192.168.12.7 Machine client/serveur. Poste8.grid.cnstn 192.168.12.8 Machine client/serveur. Metre1.grid.cnstn 192.168.12.81 Machine serveur de certificat, client. Metre2.grid.cnstn 192.168.12.82 Machine serveur de certificat, client. Metre3.grid.cnstn 192.168.12.83 Machine serveur de certificat, client. Machine serveur de certificat, client. Metre4.grid.cnstn 192.168.12.84 Tab. 3.1 -Tableau des adresses des nœuds de la grille de calcul.
    • P a g e | 60 5.1.2 Installation du système Linux Il faut suivre la procédure d'installation normale de 'Scientifique Linux' en faisant attention aux points suivants : -Type d'installation Poste de Travail (WorkStation). - Sécurité Pas de pare-feu (Pour ne pas gêner le fonctionnement de Globus). - Mot de passe 'root'. - Personnalisation du jeu de paquetages s'il y a des pilotes particuliers pour la machine, il faut ajouter les paquetages du noyau. - Date et Heure doivent être réglées. Ce point est très important, car si les dates systèmes ne sont pas synchronisées, des problèmes auront lieu au niveau de la validité des certificats. 5.1.3 Création des comptes utilisateurs Nous avons besoin de certains utilisateurs : un utilisateur quot;userquot;, comme utilisateur simple, un utilisateur quot;rootquot; comme administrateur et quot;Globusquot; qui sera obligatoire sur chaque nœud de la grille et servira à l'installation de l'intergiciel Globus Toolkit 4.0.1. La création des utilisateurs se fait lors de l'installation du système Linux ou à l'aide de commande système quot;adduserquot; (voir Annexe A.I.1.b). 5.1.4 Création des répertoires d'installation Pour l'installation de l'intergiciel Globus Toolkit et ses outils nécessaires, nous devons créer deux répertoires sur chaque nœud de la grille sous le répertoire '/usr/local', un pour les outils et un pour Globus, puis ajouter les variables d'environnements correspondantes au fichier '/etc/profile' tel que la variable d'environnement '$GLOBUS_LOCATION' afin de faciliter le traitement ci après.
    • P a g e | 61 L'utilisateur est libre de choisir le répertoire d'installation à condition que ce répertoire appartienne à l'utilisateur 'globus'. Une description détaillée des répertoires est présentée dans l'annexe A.I.2. 5.1.5 Installation des outils nécessaires pour Globus Toolkit 4.0.1 Après l'installation de chaque outil qui se fait à partir d'un répertoire NFS ou à partir d'un CD ROM, nous devons rajouter les modifications nécessaires aux fichier '/etc/profile' (voir Annexe A.I.3.c). - Installation de Apache Ant : C'est un exécuteur de tâches permettant de compiler et déployer un programme Java. Il est nécessaire lors du déploiement des services de grille (voir Annexe A.I.3.a). -Installation de Java JDK : C'est un kit de développement nécessaire lors de la compilation du code de Globus Toolkit 4.0.1 dont une grande partie est écrite en Java (voir Annexe A.I.3.b). - Installation de PostgresSQL : C'est un SGBDR (système de gestion de base de données relationnelles)qui fonctionne sur des systèmes de type UNIX (par exemple Linux, FreeBSD, AIX, HP-UX, IRIX, Solaris, ...). C'est un logiciel libre qui possède de nombreuses caractéristiques faisant de lui un SGBDR robuste et puissant digne des SGBD : - de nombreuses interfaces graphiques pour gérer les tables. -des bibliothèques pour de nombreux langages (appelés frontaux) afin d'accéder aux enregistrements à partir de programmes écrits en : Java (JDBC),C/C++ et Perl.
    • P a g e | 62 - une API ODBC permettant à n'importe quelle application supportant ce type d'interface d'accéder à des bases de données de type PostgreSQL. PostgreSQL fonctionne selon une architecture client/serveur, il est ainsi constitué : d'une partie serveur, c'est-à-dire une application fonctionnant sur la machine hébergeant la base de données (le serveur de bases de données) capable de traiter les requêtes des clients. Il s'agit dans ce cas d'un programme résident en mémoire appelé « postmaster » et d'une partie client devant être installée sur les postes clients (un client peut éventuellement fonctionner sur le serveur lui-même). Les clients peuvent interroger le serveur de bases de données à l'aide de requêtes SQL. Une démonstration plus détaillée sur les étapes d'installation et sur la création des utilisateurs ainsi que leur communication avec le serveur se trouve dans l'annexe A, paragraphe V. - Installation du Globus Toolkit 4.0.1 : Toolkit Le code source de Globus est de 82Mo, son installation nécessite 312 Mo, et son déploiement 20 Mo. Le déploiement consiste à garder, suivant la configuration de la machine (système d'exploitation et type de processeur), les fichiers qui seront réellement utiles pour faire du calcul distribué. Il peut supporter les ordonnanceurs suivants : Fork (utilisé par défaut dans Globus), poe, condor, easymcs, nqe, prun, loadleveler, lsf, glunix, pexec, et pbs. L'installation se fait grâce à la commande «./configure » qui permet de configurer tous les logiciels fournis dans le paquetage Globus, pour un type d'architecture. Ici, l'architecture est de type quot; i18nquot;,
    • P a g e | 63 pour un PC sous Linux. Le type d'architecture est détecté automatiquement par Globus (Voir annexe A.II.4). L'option « -enable-prewsmds » est utilisée pour activer les services web MDS préexistants dans le paquetage « Globus Toolkit4.0.1 », également pour l'option « -enable-drs » qui permet d'activer les services de réplications de données (Data Replication Service). Pour la compilation et l'installation, on utilise les commandes 'make' et « make install ». Suite à ces commandes, l'installation est faite en respectant l'architecture des répertoires suivants : -bin : contient les commandes nécessaires pour la communication bin dans la grille. - sbin : Contient les exécutables, utilisés ci-après. - share : Contient des informations quot; partageables quot; sur le GSI et GIS de Globus. - etc : contient des fichiers de configuration. 5.2 Installation de l'Autorité de Certification : SimpleCA SimpleCA est un paquetage qui fournit une autorité simplifiée de certification afin de publier des qualifications aux utilisateurs et aux services Globus Toolkit4, il englobe les fonctionnalités de OpenSSL CA. Pour l'installer, il faut lancer le script « setupsimpleca » (voir Annexe A.III.2) qui demande d'entrer le mot de passe général du certificat. C'est ce dernier qui sera utilisé pour signer tous les certificats dépendant de cette Autorité de certification et il est le plus important. Ce script se charge de créer la structure des répertoires qui contiennent tous les certificats de l'Autorité de Certification et ses clés publiques et privées (/home/globus/.globus/simpleCA). Puis il faut
    • P a g e | 64 installer le service GSI qui représente l'infrastructure du service de sécurité pour Globus Toolkit. A travers la commande « grid-cert-request –host » (voir Annexe A.III.3) nous avons obtenu, également avec un mot de passe choisi par celui qui fait l'installation, une clé privée pour le nœud hôte et une clé de signature qui servira à signer toutes les clés générées par l'Autorité de Certification des utilisateurs locaux du nœud en question (voir Annexe A.III.5 et A.III.6) et des autres nœuds de la grille. Maintenant toutes les commandes de « Globus toolkit » sont utilisables. Cela va per mettre de finir la création des certificats sur les autres nœuds. Cette étape se fait par l'installation du paquetage « globus_simple_ca_a2fbda04_setup-0.18.tar.gz » (voir Annexe A.IV). Cela génère un script « globus_simple_ca_a2fbda04_setup » qui va créer un certificat pour les utilisateurs de chaque nœud (voir annexe A.IV). Après génération des clés propres à chaque nœud, ces dernières doivent être signées par le nœud ou nous avons installé l'Autorité de Certification (voir Annexe A.III.5 et A.III.6) par la commande « grid-ca-sign ». Après signature des clés privées et publiques générées par l'Autorité de Certification, nous devons modifier le fichier « grid-mapfile » à travers la commande « grid-mapfile-addentry », pour tous les utilisateurs de différents nœuds sur chaque hôte de la grille. Ce fichier est vu comme un fichier d'autorisation des utilisateurs de la grille pour accéder aux données sur les nœuds. Notons que les utilisateurs de chaque nœud doivent s'identifier sur un autre nœud
    • P a g e | 65 par un nom d'utilisateur local du nœud en question (voir annexe A.III.8). Pour tester que notre procédure d'authentification et d'autorisation est bien achevée, nous devons générer un proxy à l'aide de la commande « grid-proxy-init -debug –verify ». Cette commande produit une nouvelle paire de clés à partir de l'identité de l'utilisateur afin d'assurer la procédure d'authentification et d'autorisation (Voir annexe A.III.9). Globus est aussi un ensemble de service qui peut être utilisé via Internet toutefois il y a certaines contraintes à respecter. Tout d'abord l'authentification des machines réalisée par GSI impose certaines contraintes : -Les adresses IP ainsi que les noms des machines doivent être statiques. - Les machines doivent communiquer directement, il est impossible d'utiliser des machines situées sur un réseau privé et qui communiquent avec d'autres machines. 5.3 Configuration des services de grille de calcul 5.3.1 Configuration du service gridftp GridFTP est un protocole à rendement élevé, sécurisé, fiable, permettant le transfert transparent de données. Il est optimisé pour les réseaux étendus. Le protocole GridFTP est construit au dessus du protocole FTP standard auquel sont ajoutées d'autres fonctions. Il utilise le service GSI pour l'identification des utilisateurs. Ce protocole est déjà installé et il ne nous reste plus qu'à le configurer. Il faut donc éditer le fichier « /etc/services » et rajouter le
    • P a g e | 66 nom de service, le port et le protocole (voir annexe A.IV.1). Ensuite, ajouter sous « /etc/inetd.d», le fichier « gridftp » (voir annexe A.IV.1), puis relancer « init.d » avec la commande « /etc/init.d/xinetd reload ». La commande 'netstat' sert à tester le bon fonctionnement du service ainsi que la commande « telnet » (voir annexe A.IV.4). Enfin pour s'assurer qu'il y a réellement un transfert, après avoir lancé le proxy et « le serveur gridftp-server » (voir annexe A.IV.), nous devons tester la commande « globusurlcopy gsiftp » qui remplace la commande « put » dans le protocole « ftp » (voir annexe A.IV.4). 5.3.2 Lancement des web containers Pour administrer les web containers, Java WS englobe deux actions : une pour le lancement (globus-start-container) et une pour l'arrêt (globus-stop-container). Afin de faciliter leur utilisation, nous avons recourt à créer un exécutable « start-stop » sous « $GLOBUS_LOCATION » (voir Annexe A.V.1) qui contient plusieurs options utiles telles que : - « GLOBUS_OPTIONS=quot;-Xms256M -Xmx512M » appelée « maximum heap size » qui sert à augmenter la mémoire virtuelle (JVM). -Le lancement du script « globus-user-env.sh » sous « $GLOBUS_LOCAT- ION /etc ». Nous pouvons aussi créer un script « /etc/init.d/globus4.0.1 » qui se charge de lancer l'exécutable « start-stop ». Notons que les web containers nécessite une configuration globale spécifiée dans les fichiers « server-config.wsdd » et « client-serverconfig.wsdd » sous « $GLOBUS_LOCATION/etc/globus_wsrf_core/ ». Elle consiste à
    • P a g e | 67 ajouter dans la balise « <parameter> » de « <globalConfiguration> » le nom du hôte et l'adresse IP correspondante. 5.3.3 Configuration du service RFT (Releable File Transfer) Ce service fournit des interfaces pour contrôler les transferts entre serveurs GridFTP. Il s'agit d'une réadaptation de l'utilitaire « globus- url-copy ». Il nécessite le lancement du serveur « postmaster » du SGBD « Postgresql » en plus du service GridFTP. Sa configuration consiste à utiliser le processus d'authentification par lequel le serveur de bases de données établit l'identité du client et détermine si l'application cliente (ou l'utilisateur sous le nom de laquelle elle tourne) est autorisée à se connecter sous le nom d'utilisateur demandé. Les noms d'utilisateurs PostgreSQL sont séparés de façon logique des noms d'utilisateurs du système d'exploitation sur lequel tourne le serveur. Si tous les utilisateurs d'un serveur donné ont aussi des comptes sur la machine serveur, il peut être pertinent d'attribuer des noms d'utilisateurs de la base de données qui correspondent aux noms d'utilisateurs du système d'exploitation. Cependant, un serveur qui accepte les connexions distantes peut avoir plusieurs utilisateurs de base de données dépourvus de compte correspondant sur le système d'exploitation, dans de tels cas il n'y a pas besoin de correspondance entre noms d'utilisateurs de bases de données et noms d'utilisateurs du système d'exploitation. L'authentification du client est contrôlée par le fichier « pg_hba.conf » situé dans le répertoire data, sous le chemin « /var/lib/pgsql/data/ pg_hba.conf ».
    • P a g e | 68 Un fichier « pg_hba.conf » par défaut est installé lorsque le répertoire data est initialisé par la commande « initdb ». Le format général du fichier « pg_hba.conf » est un ensemble d'enregitrements, un par ligne. Un enregistrement est constitué d'un certain nombre de champs séparés par des espaces et/ou des tabulations. Les champs peuvent contenir des espaces si la va leur du champ est mise entre guillemets. Chaque enregistrement détermine un type de connexion, une plage d'adresses IP (si appropriée au type de connexion), un nom de base de données, un nom d'utilisateur et la méthode d'authentification à utiliser pour les connexions corresp- ondants à ces paramètres. Pour la configuration, l'enregistrement A le format suivant: “host database user IP-adress/IP-mask authentication-methode[authentication-method]”. La signification des champs est la suivante : - host : Cet enregistrement intercepte les tentatives de connexion utilisant les réseaux TCP/IP qui sont désactivées sauf si le serveur « postmaster » est lancé avec l'option « -i » ou si le paramètre de configuration « tcpip_socket » est activé. - database : Indique quelles bases de données l'enregistrement concerne. - user : Indique à quels utilisateurs PostgreSQL cet enregistrement correspond. - IP-address/IP-mask : Ces deux champs contiennent les adresses IP et les masques en notation pointée standard (Les adresses IP ne peuvent être spécifiées que sous forme numérique, pas sous forme de noms de domaines ou d'hôtes). Pris séparément, ils spécifient les adresses IP des machines clientes que cet enregistrement intercepte.
    • P a g e | 69 - authentication-method : Détermine la méthode d'authentification à utiliser lors d'une connexion via cet enregistrement. Dans notre cas, c'est la méthode 'MD5' qui demande au client de fournir un mot de passe crypté MD5 pour son authentification (Voir l'Annexe A.VI). Pour achever l'installation, nous devons créer un utilisateur de base « globus » ainsi qu'une base « rftdatabase » pour cet utilisateur. De plus, le fichier « jndi-con_g.xml » se trouvant sous la direction « $GLOBUS_LOCATION/etc/globus_wsrf_rft/ » doit contenir le nom d'utilisateur et le mot de passe. Ainsi une description détaillée se trouve dans l'annexe A.VI en plus des tests de validation de la configuration. 5.3.4 Configuration du service GRAM Comme il permet de lancer des programmes sur des ressources distantes, sans tenir compte de l'hétérogénéité locale (système d'exploitation, ordonnanceur), la configuration du service GRAM consiste en l'édition du fichier « gram_fs_map_con_g.xml » et l'ajout de deux lignes d'adaptateur local dans le fichier « /etc/sudoers » qui sont utiles lors de l'exécution des jobs sur différents hôtes et pour que le programme « globusgridmap-and-execute » s'exécute à travers les utilisateurs qui se trouvent dans le fichier « grid-mapfile ». 5.4 Soumission des Jobs Un job est considéré comme une unité simple de travail qui est typiquement soumis pour l'exécution sur la grille. Il nécessite des données, produit des sorties, et des conditions d'exécution afin
    • P a g e | 70 d'accomplir sa tâche. Un job simple peut lancer un ou plusieurs processus sur un nœud indiqué. Il peut exécuter des calculs complexes sur des grandes quantités de données comme il peut être relativement simple. Les utilisateurs désirant utiliser la Grille, doivent, après avoir récupéré un certificat, initier un proxy. Lors d'une requête de type « job », plusieurs éléments de Globus rentrent en jeu, comme GRAM et GSI. 5.4.1 Description d'un job Scénario d'exécution d'un job La soumission d'un job se fait depuis une interface utilisateur (UI), en envoyant au courtier de ressources (Ressource Broker RB) un script JDL (Job Description Langage) ou un script XML avec la version Globus Toolkit 4 décrivant les caractéristiques du job et ses prés requis sous forme d'attributs. Ces attributs décrivent les ressources requises (CPU, mémoire, logiciels..), et les fichiers nécessaires. Avec ces informations, le courtier de ressources déterminera l'élément de calcul le plus optimal pour l'exécution (voir FIG 3.1). Fig. 4.1 -Etape de soumission d'un job.
    • P a g e | 71 Le choix du nœud d'exécution se fera de manière différente suivant le cas : 1. Soumission directe : Il est possible de spécifier, dans le script JDL (également le script XML), sur quel nœud doit s'exécuter le job, auquel cas le courtier des ressources sert seulement à vérifier la syntaxe du JDL soumis. 2. Soumission sans demande d'accès à des fichiers de la Grille : Dans ce cas, le courtier des ressources contacte le système d'information et récupère une liste de nœuds disposant des ressources de calcul demandées (CPU, mémoire, logiciels), et sur lesquels l'utilisateur a le droit d'exécuter (informations statiques).Ensuite, il interroge chacun des nœuds de cette liste pour déterminer le meilleur candidat, selon, le nombre de CPU et la mémoire libre (informations dynamiques). 3. Soumission avec demande d'accès à des fichiers préalablement stockés sur la Grille : Dans ce cas, le courtier des ressources doit d'abord interroger le catalogue de l'Organisation Virtuelle de l'utilisateur pour savoir où est stockée une copie des fichiers requis par le job, et établir une liste des nœuds éligibles,
    • P a g e | 72 Fig. 4.2 -Graphe de transition pour un job. C’est-à-dire proches des données requises et sur lesquels l'utilisateur est autorisé à exécuter .Une fois le nœud d'exécution choisi, le courtier des ressources lui soumet le job avec l'information récupérée et prévient le service de Logging & Bookkeeping (LB). Ce service peut être interrogé à tout moment par l'utilisateur, pour savoir où est le job soumis. Lorsque l'exécution commence, les fichiers quot;locauxquot; sont envoyés avec l'exécutable, et lorsque le LB annonce que le job est terminé, le nœud renvoie les fichiers de sorties éventuels au courtier des ressources, qui peuvent être récupérés par l'utilisateur. Etats et cycle de vie d'un job Au cours de son cycle de vie, Un job passe par plusieurs états qui sont (voir FIG 4.2):
    • P a g e | 73 -Unsubmitted : Le job n'est pas encore soumis. - StageIn : Le job attend que les fichiers exécutables ou d'entrée soit accomplit. - Pending : Le job attend son lancement par le scheduler local. - Active : Le job est en cours d'exécution. - Suspended : L'exécution de job a été suspendue. - StageOut : L'exécution de job a accompli ; les sorties sont entrain de soumission. - CleanUp : Le job et les sorties ont accompli ; nettoyez des tâches sont en cours. - Done : Le job a accompli avec succès. - Failed : Le job a échoué. Ainsi un graphe de transition de ces différents états illustre le cycle de vie d'un job : Un job a unique ID (identificateur) qui peut être employé dans le service GRAM pour la fiabilité en cas d'erreurs, c'est-à-dire pour empêcher la duplication accidentelle des jobs dans des circonstances rares par les nouvelles tentatives de client. En plus chaque job est détruit juste après sa terminaison normale, ou après un temps de terminaison (Termination time) qui est fixé par défaut en cas d'erreur d'exécution. 5.4.2 Exemples de soumission de différents jobs Globus Toolkit4 supporte le langage XML comme langage de description du script de job. Les paramètres de ce script ainsi que les différents exemples de jobs soumis sur notre grille sont bien détaillés dans l'annexe B. Dans ce qui suit, nous citons juste ces différents tests.
    • P a g e | 74 1. Soumission d'un job simple : Le premier test consiste à vérifier si le service GRAM est bien installé, la commande « globusrun- ws » est ainsi utilisée une première fois avec l'option -c pour exécuter la commande shell « /bin/touch » et une deuxième fois en ajoutant l'option « -F » pour exécuter le même script sur une machine distante (voir annexe B.II.test1 et annexe B.II.test2). D'autres tests sont aussi faits comme les jobs à plusieurs arguments et les jobs permettant de récupérer les résultats dans des fichiers de sorties (voir annexe B.II.test4 et annexe B.II.test5). 2. Soumission des jobs sur des nœuds distants : Ces tests sont basés sur le service de transfert de fichiers (gsiftp) que ce soient le fichier exécutable, les fichiers d'entrer ou les fichiers de récupération de données ainsi différents scénarios sont alors faits (voir annexe B.III., annexe B.IV.1). 3. Soumission des jobs multiples : le multi job consiste à lancer des différents jobs en même temps sur le même site ou sur des sites distants (voir annexe B.III.2 et annexe B.IV.5 et annexe B.IV.6). L'exemple 7 dans l'annexe B.IV illustre un flux de données entre divers sites, le fichier de sortie de l'un est argument d'entrée pour l'autre, tout en gardant une exécution parallèle de ces jobs. Conclusion Une grille de calcul est ainsi installée convenablement pour permettre aux utilisateurs d'exploiter les ressources de Globus Toolkit 4.0.1. A travers les différents tests de soumission de jobs, nous avons
    • P a g e | 75 réussit à mettre en relief les objectifs en question ainsi que le déploiement de la grille en utilisant ses services.
    • P a g e | 76 Conclusion Générale A partir d'un cadre de calcul distribué et à travers les concepts et principes théoriques des grilles de calculs, ce travail avait pour objectif de faire une évaluation théorique des notions et concepts du domaine. Suite à cette évaluation, l'environnement Globus Toolkit 4.0.1 a été choisi, pour des tests pratiques. En effet, avec son architecture en couche et son adaptation à l'infrastructure OGSI pour la définition des services de grille composant l'architecture « Open Grid Service Architecture (OGSA) », le middleware Globus était le mieux adapté aux contraintes posées. Afin de permettre le développement et l'exécution des services de grille, GT4 propose des solutions tel que l'utilisation des mécanismes comme WSDL qui intègre les possibilités de composition de services exploitées par la spécification OGSI ainsi que les mécanismes de sécurité de la couche application basé sur le standard XML et les services Web. Cependant, une fois initié à ses concepts et ses API, GT4 permet un gain de temps considérable pour le développement d'un service de grille, ainsi que pour le développement des outils clients permettant de l'utiliser grâce à la standardisation d'une partie des interfaces et des comportements des services. La plupart des facilités offertes par cette infrastructure aux services respectant cet ensemble de conventions ont également un intérêt certain en dehors d'un contexte de grille et permettent de construire assez facilement tout un groupe de Services Web avec des
    • P a g e | 77 fonctionnalités évoluées de notification, de sécurité, de gestion du cycle de vie, etc. Dans cette mémoire, nous avons présenté un retour d'expérience sur la mise en place d'une grille de calcul et le développement de Services de grille illustré par la résolution des difficultés rencontrées. Malgré le temps nécessaire pour être opérationnel sur l'utilisation de cette technologie, lié à son immaturité, nous sommes convaincues du rôle fondamental d’OGSI dans la construction des infrastructures informatiques autour des grilles. A travers ce projet nous avons senti les responsabilités que devait avoir un ingénieur face à des défis problématiques liés aux diverses technologies adoptées. Ce sujet n'était pas simple au départ, car il fait appel à de nombreuses technologies récentes en informatique. Ce mémoire a été une expérience très intéressante et valorisante dans le domaine des grilles de calcul qui ont un avenir prometteur. Perspectives : Notre projet est une suite logique du développement de l'Internet, et du WEB d'où : -La nécessité des tentatives d'interopérabilité de middleware de Grille. - La volonté d'étendre l'accès aux grilles à travers des terminaux mobiles. - Le besoin d'étendre (encore) les middlewares de Grille. - Le besoin d'une adoption industrielle plus large telle que la tolérance aux pannes et le respect des contraintes de temps.
    • P a g e | 78 Bibliographie [1] http :// www.globus.org. [2] http :// www.gridcafe.org. [3] Sophie NICOUD Fabio HERNANDEZ, Nicolas JACQ. Datagrid. [4] Ian Foster. What is the grid ? ? a three point checklist. GRIDSTART Technical Newsletter, March 2003. [5] C. Kesselman I. Foster and S. Tuecke. The grid : Blueprint for a future computing infrastructure. San Francisco, 1999. [6] C. Kesselman I. Foster and S. Tuecke. The anatomy of the grid : Enabling Scalable virtual rganizations. Int.l J. Supercomputer Applications, 2001. [7] D. Snelling J. Almond. Unicore : secure and uniform access to distributed resources via the www, October 1998. [8] M. Romberg. The unicore architecture-seamless access to distributed resources. In Proceedings of the Eight IEEE International Symposium on High performance Computing, pages 287-293, Redondo Beach, CA, USA, August 1999. [9] C. Kesselman G. von Laszewski W. Smith S. Tuecke S. Fitzgerald, I. Foster. A directory service for con_guring high-performance distributed computations. In Proc. 6th IEEE Symp. On High-Performance Distributed Computing, pages 365-375, 1997.
    • P a g e | 79 Annexe A Procédure d'installation d'une grille de calcul A.1 Préparation à l'installation de Globus Toolkit 4.0.1 A.1.1 Création d'un utilisateur quot;Globusquot; quot;Globus Globusquot; Description de l'utilisateur quot;Globusquot; : C'est un utilisateur non privilégié qui est utile à l'administration de la grille tel que le lancement et l'arrêt du quot;containerquot;, le déploiement des services, etc. Procédure : La création de l'utilisateur se fait soit : - Automatiquement lors de l'installation du système Linux (dans notre cas c'est le système Scientific Linux 5.1). - En créant notre utilisateur en mode texte avec la commande adduser. Comme quot;rootquot; :
    • P a g e | 80 - En mode graphique, en choisissant dans le menu : A.1.2 Création d'un répertoire d'installation de Globus Toolkit 4.0.1 : Pour le faire, nous choisissons le chemin d'installation désiré (dans notre cas c'est : '/usr/local') puis comme root, on exécute : A.1.3 Installation des outils nécessaires pour Globus Toolkit4.0.1 : Installation d’Apache-ant : C'est un exécuteur de tâches permettant de compiler et déployer un programme. En effet, Ant, comme une solution libre basée sur XML, a
    • P a g e | 81 l'avantage de reposer sur un fichier XML comme descripteur de tâches et d'avoir Java comme garant de la portabilité. Il suffit de télécharger la version adéquate d’apache-ant et la placer dans un répertoire au choix. Dans notre cas, nous avons installé « apache-ant-1.6.5.bin » dans « /usr/local ». L'installation consiste à exécuté le script apache-ant- 1.6.5.bin qui est nous avons déjà copié dans le répertoire d’installation. Exemple : En tant que quot;rootquot; faire : Installation de JDK : -Présentation : Le Java Development Kit, communément appelé JDK, est le kit de développement de base que propose gratuitement la firme Sun Microsystem. Le Kit de développement comprend plusieurs outils, parmi lesquels : - javac : le compilateur Java. - java : un interpréteur d'applications (machine virtuelle). - applet viewer : un interpréteur d'applets. - jdb : un débogueur. - javap : un décompilateur, pour revenir du bytecode au code source. - javadoc : un générateur de documentation. - jar : un archive de classes Java. - Installation : De même, on télécharge la dernière version de jdk qui est « jdk1_5_06.bin » et on la place sous le répertoire où on veut l'installer (dans notre cas c'est '/usr/local') puis on exécute la commande d'installation.
    • P a g e | 82 Exemple : Comme root, on fait : La licence s'affiche, après validation nous obtenons les fichiers JDK dans le répertoire « jdk1_5_0_06» sous « /usr/local ». Configuration du fichier 'profile' sous '/etc' : Il s'agit d'ajouter à la variable quot;pathquot; le chemin de jdk et ant puis exporter les variables d'environnement dans '/etc/profile'. Exemple : Comme root, on fait : Remarque : Avant l'installation de Globus Toolkit, il faut s'assurer que le fichier exécutable du compilateur « javac » sous « /usr/bin » n'existe pas, sinon le compilateur java utilisé sera celui sous « /usr/bin » et non le compilateur de la version « 1.5.0.06 ». A.2 Installation de Globus toolkit 4.0.1 : L'installation de Globus Toolkit 4.0.1 doit être faite en tant qu'utilisateur Globus, pour cela il faut changer de session ou directement par la commande schell suivante :
    • P a g e | 83 Ensuite, après téléchargement du fichier 'gt4.0.1-x86_fc_3-binary- installer.tar.gz' et son placement dans l'endroit désiré (dans notre cas c'est : /Installation/Outils), nous commencons l'installation de globus toolkit qui consiste à : 1. Extraire les fichiers compressés dans le fichier 'gt4.0.1-x86_fc_3-binary-installer.tar.gz' avec la commande: 2. Copier le fichier décompressé dans le répertoire d'installation de globus toolkit4.0.1 comme suit : 4. Se placer sous le répertoire d'installation : 5. Lancer l'installation : Le résultat obtenu est : Puis :
    • P a g e | 84 Enfin : A.3 Installation de l'Autorité de Certification : AC A.3.1 Création des utilisateurs Il faut s'assurer que la machine contient les deux comptes utilisateurs suivants : Un compte utilisateur pour l'exécution des programmes clients et un compte Globus utilisé comme administrateur, il est nécessaire pour le démarrage et l'arrêt du quot;containerquot;, le déploiement des Web Services ainsi que la gestion de l'AC. Nous allons créer notre propre AC par l'outil fourni par GT4 qui est quot;Simple CAquot;. Remarque Remarque : Il faut s'assurer que l'utilisateur Globus a les droits d'écriture et de lecture dans le répertoire '$GLOBUS_LOCATION'.
    • P a g e | 85 A.3.2 Exécution du script d'installation : Ce script est placé lors de l'installation de Globus Toulkit4.0.1 pour l'exécution de « SimpleCA » qui est installée uniquement dans une seule machine pour une même grille. Remarque : - L'installation doit se faire par l'utilisateur « globus », sinon on aura notre « simpleCA » installé sous « /root » : « /root/.globus/simpleCA ». - Avant de lancer l'installation, il faut s'assurer que le nom de la machine est bien écrit dans le fichier « /etc/hosts » avec l'adresse IP correspondante. Exemple : Voici le contenu du fichier quot;hostsquot; d'une machine de notre grille : Comme globus, nous créons le répertoire « /etc/grid-security » puis on lance les commandes suivantes : Le résultat est :
    • P a g e | 86 Puis si notre sujet de l'AC est bien conforme au nom de hôte, nous pouvons confirmer l'exécution en tapant quot; y quot; devant le message qui s'affiche : Puis nous entrons l'email de l'administrateur de l'AC : Ensuite le nombre de jours de validité de notre certificat, par défaut si nous tapons quot;entrer quot; la durée sera de 5 ans. Puis la phrase de passe du certificat, qui sera utilisée par la suite comme clé cryptographique générée par l'algorithme RSA.
    • P a g e | 87 A.3.3 Installation du service GSI : Nous Lançons la commande suivante : Comme « root » :
    • P a g e | 88 Nous obtenons comme résultat : A.3.4 Demande de certificat pour un nœud hôte quot;Host Certificatesquot; : Il suffit de lancer la commande suivante : Suite à cette commande, il y aura génération de trois fichiers : hostkey.pem qui contient la clé du nœud hôte, hostcert_request.pem qui contient la clé de signature et un fichier vide (empty) hostcert.pem qui va contenir la signature du nœud hôte. A.3.5 Signature du certificat du noeud hôte quot;Host Certificatesquot;: Remarque : La commande doit être lancé sous « /home/globus/.globus », sinon elle génère l'erreur suivante car le fichier se trouve sous « /home/globus /.globus ». Donc sous « /home/globus/.globus », nous exécutons la commande suivante:
    • P a g e | 89 Remarque : Le fichier hostsigned.pem est inexistant mais il sera créé lors du lancement de la commande et contiendra la signature de l’hôte. Le résultat obtenu est : Après l'écriture de la clé, le résultat sera : Puis nous plaçons le fichier signé dans le fichier sous le nom hostcert.pem : A.3.6 Signature du certificat de l'utilisateur quot;globusquot; : Avec la commande suivante : Le résultat obtenu est :
    • P a g e | 90 Après génération du fichier 'usercert_request.pem ' nous devons le signer : Le résultat obtenu est :
    • P a g e | 91 A.3.7 Signature du certificat de l'utilisateur 'user1': Pour cela puisque le fichier « usercert_request » est propriétaire a « user1 » alors en va le copier dans le fichier « /tmp » puis en change le propriétaire de ce fichier en mode « root » en tapant : Puis en signe le fichier 'usercert_request.pem ' par l’utilisateur « globus» en tapant : Le résultat obtenu est : Puis, nous plaçons le fichier signé en mode « root » dans le fichier usercert.pem qui est vide puis en change le propriétaire de ce fichier à l’utilisateur « user1 » :
    • P a g e | 92 A.3.8 Création du certificat du 'container' : Il est utile pour le lancement des Services Web : Le résultat final est : A.3.9 Ajout des autorisations : L'ajout des autorisations se fait par la création du fichier « grid- mapfile » qui garantie la communication sécurisée entre les différents nœuds de la grille :
    • P a g e | 93 Ajout du « sujet globus » dans le fichier « grid-mapfile » : Le résultat souhaité est : Ajout du « sujet user1» dans le fichier « grid-mapfile » : Le résultat est : A.3.10 Vérification du certificat de l'utilisateur « globus» : Remarque : Il faut entrer le mot de passe utilisé lors de la signature de l'utilisateur « globus ». Avec la commande suivante :
    • P a g e | 94 A.3.11 Vérification du certificat de « user1 » : Remarque : Il faut entrer le mot de passe utilisé lors de la signature de l'utilisateur 'user. Avec la commande suivante : A.4 Installation de certificat pour plusieurs machines : Pour chaque machine autre que celle où nous avons installé le certificat, nous procédons de la manière suivante : Nous copions le fichier « globus_simple_ca_a2fbda04_setup- 0.18.tar.gz » qui se trouve sous : « /home/globus/.globus/simpleCA/ » dans la deuxième machine sous « /home/globus/ » puis nous lançons la commande suivante : Nous obtenons :
    • P a g e | 95 Puis:
    • P a g e | 96
    • P a g e | 97 Remarque : Cet avertissement (warning) s'affiche car nous n'avons pas encore installé le service quot;GRAMquot;. Ensuite, nous installons le service « setup- gsi » : Nous obtenons le résultat suivant : Remarque : Avant de lancer la commande suivante, il faut mettre à jours le fichier « /etc/hosts » en ajoutant ces trois lignes : Puis, nous lançons la commande d'authentification de l’hôte : Exemple :
    • P a g e | 98 Le résultat obtenu est : Si l'installation est réussite, nous obtenons les fichiers suivants : Puis en passe a l’étape de signature de ce clé
    • P a g e | 99 Dans cette étape nous faisant la même opération faite pour la 1ère machine, alors en va copier le fichier « hostcert_request » dans la machine nommé « poste4 » puis nous faisant la signature de cette clé par l’utilisateur « globus ». (Voir paragraphe A.3.5). Puis, nous lançons la commande d'authentification de l'utilisateur dont le nom est « name » : Remarque : 1) L'ajout d'un utilisateur d'une machine sur une autre distante est traduit par une nouvelle entrée dans le fichier « gridmap-file » de la machine distante avec le 'sujet' de la machine utilisateur et le nom d'un utilisateur de la machine distante, sinon son accès sera refusé. 2) après la génération de clé de l’utilisateur dont le nom est « name » en doit signé cette clé par l’utilisateur « globus » de la machine « poste4 » pour cela en va copier cette clé dans cette machine puis ne répétons les opérations réalisé dans le paragraphe « A.3.7 jusqu'à A.3.9 » A.5 Installation de postgresql-8.3.3.2
    • P a g e | 100 Après téléchargement du paquetage « postgresql-8.3.3.2.bin » sous « /home/user/local », nous commençons l'installation : Comme « root » : A.5.1 Configuration de postgresql : Ensuite, en définie le port de l’application :
    • P a g e | 101 Et puis le langage procédural utilisé : En définie le moteur de stockage par default :
    • P a g e | 102 Ensuite, nous ajoutons un utilisateur « postgres » et nous créons les répertoires « pgsql/data »: Puis en se lance la confirmation :
    • P a g e | 103 Enfin : Et enfin nous lançons le serveur de base de données. Nous créons une base de données pour vérifier si la base est bien installée :
    • P a g e | 104 Si toute marche bien, nous aurons : A.6 Installation du service « gridFTP » : A.6.1 Configuration : -Configuration du service « gridftp » sous « xinetd/inetd » : -le résultat de cette commande sera :
    • P a g e | 105 Remarque : « inetd » et « xinetd » sont équivalents. -Chargement du service « xinetd »: - Mise à jour du fichier 'services' : -Voir l'état du service « gsiftp » avec la commande « netstat » :
    • P a g e | 106 - Création du fichier « gridftp.conf » sous « /etc/grid-security » : - copie du fichier « gridftp.conf » sous « $GLOBUS_LOCATION/etc »: A.6.2 Lancement du proxy :
    • P a g e | 107 A.6.3 Test du service « gsiftp » -Le premier test se fait avec la commande « telnet »: Remarque : Le numéro 220 indique que le service « gsiftp » est bien configuré, sinon il faut s'assurer de l'existence du fichier « gridftp.conf » sous « /etc/grid-security » et sous « $GLOBUS_LOCATION/etc ». -Si le paquetage « globus_ftp_client_test » est bien installé, l'exécution du script « TEST.pl » vérifie le bon fonctionnement de notre plateforme.
    • P a g e | 108 A.6.4 Lancement du serveur 'gridftp' - Coté serveur (front end) -Coté client (data-node) -Exemple : -Transfert de données : La quot;machine Aquot; est la machine source : c'est la machine sur laquelle le serveur « gridftp » est installé (front end), cette machine doit contenir le certificat. - Exemples Exemple1 : Copie sur la même machine. Il s'agit de copier le fichier « /etc/group » du nœud « poste4.grid.cnstn » dans le fichier « /tmp/globus.test.copy » qui se trouve sur le nœud « poste4.grid.cnstn ». La commande « diff » nous permet de comparer le contenu des deux fichiers.
    • P a g e | 109 Exemple 2 : Un transfert du fichier « /etc/group » du nœud distant « poste3.grid.cnstn » vers un fichier « /tmp/globus » sur le nœud « poste4.grid.cnstn ». A.6.5 Erreurs - L'option -c oblige le serveur « gridftp » de prendre les variables du fichier « gridftp.conf » comme paramètre de configuration alors il faut bien s'assurer que le numéro de port entré n'est pas déjà utilisé par un autre service. - Cette même erreur peut aussi apparaître comme résultat de la commande :
    • P a g e | 110 Dans notre cas, le port 2811 est configuré pour le service « gsiftp » (voir le script du fichier services) et c'est normal d'avoir l'erreur « Address already in use ». A.7 Lancement des Services Web A.7.1 Création d'un exécutable pour le lancement des Services Web Nous créons un fichier contenant le script suivant : Ensuite, nous rajoutons le droit d'exécution du fichier :
    • P a g e | 111 Comme « root », nous créons sous « /etc/init.d » un script qui exécute le programme « start-stop » : De même, nous autorisons l'exécution du fichier : Puis nous lançons le Web Container : Pour voir s'il y a erreur dans le lancement du web container, nous pouvons consulter le fichier « container.log » :
    • P a g e | 112
    • P a g e | 113 Remarque : - Le message d'erreur affiché est du à une configuration manquante de la base de donnée relative au service « RFT ». -Dans certains cas tels que la mauvaise configuration du fichier « /etc/hosts », les Services Web peuvent être lancés avec l'adresse de boucle locale « 127.0.0.0 » et non par l’adresse IP du nœud. Pour régler ce problème, nous modifions les fichiers suivants : Puis nous ajoutons la ligne suivante dans la balise <globalConfiguration>. Et aussi le fichier client : Puis de la même façon, on ajoute : A.8 Configuration de RFT : A.8.1 Création du fichier quot;pg_hba.confquot; :
    • P a g e | 114 Comme « root », nous créons les répertoires suivants : Puis : Ensuite, nous insérons la ligne suivante : A.8.2 Création d'un utilisateur de la base 'postgres' : Après lancement du serveur du SGBD « postgres », nous créons une base de données « test » : Maintenant, nous créons notre utilisateur « globus » : Le résultat est :
    • P a g e | 115 A.8.3 Création de la base « rftDatabase » : Comme utilisateur « globus », nous créons la base de données : Puis nous produisons le schéma de la base qui permet de créer les tables nécessaires de la base ainsi que leurs index : Le résultat est : A.8.4 Test du fonctionnement de RFT : - Test1 : Le résultat est :
    • P a g e | 116 -Test2: Le résultat est :
    • P a g e | 117 A.9 Installation du service GRAM A.9.1 Edition du fichier « sudoers » : -Le fichier « sudoers » détermine la liste des utilisateurs que l'utilisateur globus peut affecter pour être, ainsi ces derniers prennent les droits du super utilisateur. Par exemple si nous voulons courir des applications de client au-dessous de trois utilisateurs, nous ajouterons tous au dossier de « sudoers ». Dans notre cas « griduser » et « testuser » sont deux utilisateurs locaux de « poste4.grid.cnstn » :
    • P a g e | 118 A.9.2 Edition du fichier 'globus_gram_fs_map_con_g.xml' -Le fichier« $GLOBUS_LOCATION/etc/gramservice/globus_gram_ fs_map_con_g.xml » contient l'information d'association des direct- eurs de ressource locaux aux serveurs de « GridFTP ». Le service « GRAM » utilise le serveur « GridFTP » (par l'intermédiaire de RFT) pour exécuter toutes les directives du fichier.
    • P a g e | 119
    • P a g e | 120 Annexe B Exécutions de jobs sur la grille B.1 Syntaxe 'RSl' de description de jobs - <executable : l'exécutable concerné par le job. executable> executable - <directory : répertoire de l'exécutable. directory directory> - <argument : sous forme de mot, nombre ou phrase, il est argument> argument facultatif dans le code du job et dépend de la nature de l'exécutable. -<environement : permet de définir des couples <name> +<value> environement> environement correspondant à la définition d'une variable d'environnement. - <stdout : chemin du fichier résultat. stdout> stdout - <stdin : chemin du fichier source. stdin> stdin - <stderr : sortie d'erreur. stderr> stderr -<count : nombre d'exécutions successives du programme. count> count - <fileStageIn : transfert de l'exécutable d'un nœud à un autre. fileStageIn> fileStageIn - <fileStageOut : transfert du fichier résultat d'un nœud à un autre. fileStageOut> fileStageOut - <fileCleanUp : effacé les fichiers relatifs au job après son fileCleanUp> fileCleanUp exécution.
    • P a g e | 121 B.2 Tests de soumission d'un job existant sur la machine locale. Ce sont des tests pour vérifier le bon fonctionnement de notre grille déjà installée. Ils sont soumis par la commande 'globusrun-ws' qui : -Soumet plusieurs requêtes simultanément. - Organise les exécutables. - Attend la terminaison. - Redirige vers stdout/stderr . B.2.1 Test 1 : Il s'agit d'un simple test de job sans nécessité d'écrire un programme descriptif de job (FIG B.1). Dans cet exemple, nous lançons l'exécutable « /bin/touch » sur le nœud local (poste4). L'option « -c » prend comme premier argument une commande, dans notre cas c'est « /bin/touch » et le deuxième argument le fichier résultat alors que l'option « -submit » est nécessaire pour la soumission de job. Le résultat obtenu est :
    • P a g e | 122 Le résultat réside normalement sous le répertoire où le job est exécutée, dans notre cas c'est « /home/globus ». B.2.2 Test 2 : Il consiste à exécuter le job précédent sur un nœud distant. Pour utiliser les ressources distantes nous devons appeler son container qui se traduit par l'option « -F » lors du lancement de job. L'option « - c » est présente parce qu'il s'agit d'une commande « /bin/touch » (voir FIG B.2).
    • P a g e | 123 Le résultat est :