SlideShare une entreprise Scribd logo
1  sur  123
Télécharger pour lire hors ligne
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.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.
rapport de stage.

Contenu connexe

Tendances

La gestion prévisionnelle de l’entreprise : Outil d’aide à la décision
La gestion prévisionnelle de l’entreprise : Outil d’aide à la décisionLa gestion prévisionnelle de l’entreprise : Outil d’aide à la décision
La gestion prévisionnelle de l’entreprise : Outil d’aide à la décisionJadroun Sofiane
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Yasmine Lachheb
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatiqueHicham Ben
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"étudesMohamed Boubaya
 
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIR
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIRRapport du Projet de Fin d'année Génie informatique ENSA AGADIR
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIRAHMEDAKHACHKHOUCH
 
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...Arnold Stellio
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEOussama Djerba
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCGhodbane Heni
 
Création d'une plate-forme ouverte à l'enseignement à distance
Création d'une plate-forme ouverte à l'enseignement à distanceCréation d'une plate-forme ouverte à l'enseignement à distance
Création d'une plate-forme ouverte à l'enseignement à distanceBanville Julien
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etudesihem-med
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaIlef Ben Slima
 
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRaef Ghribi
 
Rapport PFE faten_chalbi
Rapport PFE faten_chalbiRapport PFE faten_chalbi
Rapport PFE faten_chalbiFaten Chalbi
 
Rapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueRapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueEric Maxime
 
Rapport de stage d'été
Rapport de stage d'étéRapport de stage d'été
Rapport de stage d'étéJinenAbdelhak
 
Rapport de stage développement informatique
Rapport de stage développement informatique Rapport de stage développement informatique
Rapport de stage développement informatique MehdiOuqas
 

Tendances (20)

La gestion prévisionnelle de l’entreprise : Outil d’aide à la décision
La gestion prévisionnelle de l’entreprise : Outil d’aide à la décisionLa gestion prévisionnelle de l’entreprise : Outil d’aide à la décision
La gestion prévisionnelle de l’entreprise : Outil d’aide à la décision
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
 
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIR
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIRRapport du Projet de Fin d'année Génie informatique ENSA AGADIR
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIR
 
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
 
Front office back office caisse
Front office back office caisseFront office back office caisse
Front office back office caisse
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 
Création d'une plate-forme ouverte à l'enseignement à distance
Création d'une plate-forme ouverte à l'enseignement à distanceCréation d'une plate-forme ouverte à l'enseignement à distance
Création d'une plate-forme ouverte à l'enseignement à distance
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etude
 
Rapport PFE
Rapport PFERapport PFE
Rapport PFE
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
 
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
 
Rapport PFE faten_chalbi
Rapport PFE faten_chalbiRapport PFE faten_chalbi
Rapport PFE faten_chalbi
 
Rapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueRapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc Informatique
 
Rapport de stage d'été
Rapport de stage d'étéRapport de stage d'été
Rapport de stage d'été
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
Rapport de stage développement informatique
Rapport de stage développement informatique Rapport de stage développement informatique
Rapport de stage développement informatique
 

En vedette

Rapport de stage originale
Rapport de stage originaleRapport de stage originale
Rapport de stage originalesalma jarid
 
Conception et mise en place d'un Workflow du département VAS
Conception et mise en place d'un Workflow du département VASConception et mise en place d'un Workflow du département VAS
Conception et mise en place d'un Workflow du département VASAhmed MAALEJ
 
Ce qu'il faut savoir sur la BPM - Business Process Management
Ce qu'il faut savoir sur la BPM - Business Process ManagementCe qu'il faut savoir sur la BPM - Business Process Management
Ce qu'il faut savoir sur la BPM - Business Process ManagementSanae BEKKAR
 
Introduction à BPMN 2.0 - Business Process Modeling Notation
Introduction à BPMN 2.0 - Business Process Modeling NotationIntroduction à BPMN 2.0 - Business Process Modeling Notation
Introduction à BPMN 2.0 - Business Process Modeling NotationSanae BEKKAR
 
Rapport de stage bts finances comptabilite et gestion d entreprises
Rapport de stage  bts finances comptabilite et gestion  d entreprises Rapport de stage  bts finances comptabilite et gestion  d entreprises
Rapport de stage bts finances comptabilite et gestion d entreprises Constant Mousso
 
Le BPM facile avec Bonita Open Solution
Le BPM facile avec Bonita Open SolutionLe BPM facile avec Bonita Open Solution
Le BPM facile avec Bonita Open SolutionBonitasoft
 
Soutenance (thèse de doctorat de Aymen BAOUAB)
Soutenance (thèse de doctorat de Aymen BAOUAB) Soutenance (thèse de doctorat de Aymen BAOUAB)
Soutenance (thèse de doctorat de Aymen BAOUAB) baouab
 
rapport-de-stage-marjane-meknes
rapport-de-stage-marjane-meknesrapport-de-stage-marjane-meknes
rapport-de-stage-marjane-mekneshibahiba91
 

En vedette (17)

Workflow
WorkflowWorkflow
Workflow
 
Workflow3
Workflow3Workflow3
Workflow3
 
ModéLisation De Workflow En Uml
ModéLisation De Workflow En UmlModéLisation De Workflow En Uml
ModéLisation De Workflow En Uml
 
Rapport de stage originale
Rapport de stage originaleRapport de stage originale
Rapport de stage originale
 
Workflow
WorkflowWorkflow
Workflow
 
BPM & Workflow
BPM & WorkflowBPM & Workflow
BPM & Workflow
 
Conception et mise en place d'un Workflow du département VAS
Conception et mise en place d'un Workflow du département VASConception et mise en place d'un Workflow du département VAS
Conception et mise en place d'un Workflow du département VAS
 
Processus métier
Processus métierProcessus métier
Processus métier
 
Ce qu'il faut savoir sur la BPM - Business Process Management
Ce qu'il faut savoir sur la BPM - Business Process ManagementCe qu'il faut savoir sur la BPM - Business Process Management
Ce qu'il faut savoir sur la BPM - Business Process Management
 
Introduction à BPMN 2.0 - Business Process Modeling Notation
Introduction à BPMN 2.0 - Business Process Modeling NotationIntroduction à BPMN 2.0 - Business Process Modeling Notation
Introduction à BPMN 2.0 - Business Process Modeling Notation
 
Cartographie Métier : méthodologie
Cartographie Métier : méthodologieCartographie Métier : méthodologie
Cartographie Métier : méthodologie
 
Rapport de stage bts finances comptabilite et gestion d entreprises
Rapport de stage  bts finances comptabilite et gestion  d entreprises Rapport de stage  bts finances comptabilite et gestion  d entreprises
Rapport de stage bts finances comptabilite et gestion d entreprises
 
Le BPM facile avec Bonita Open Solution
Le BPM facile avec Bonita Open SolutionLe BPM facile avec Bonita Open Solution
Le BPM facile avec Bonita Open Solution
 
Soutenance (thèse de doctorat de Aymen BAOUAB)
Soutenance (thèse de doctorat de Aymen BAOUAB) Soutenance (thèse de doctorat de Aymen BAOUAB)
Soutenance (thèse de doctorat de Aymen BAOUAB)
 
rapport-de-stage-marjane-meknes
rapport-de-stage-marjane-meknesrapport-de-stage-marjane-meknes
rapport-de-stage-marjane-meknes
 
Work flow
Work flowWork flow
Work flow
 
Presentation these
Presentation thesePresentation these
Presentation these
 

Similaire à rapport de stage.

Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Codendi
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMohamed Arar
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfnesrine haloui
 
Performances d’un système virtualisé avec v mware esxi
Performances d’un système virtualisé avec v mware esxiPerformances d’un système virtualisé avec v mware esxi
Performances d’un système virtualisé avec v mware esxiprivateperso
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifsSafaAballagh
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...mouafekmazia
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Houssem Eddine Jebri
 
Manuel du module additionnel RF-LAMINATE pour RFEM
Manuel du module additionnel RF-LAMINATE pour RFEMManuel du module additionnel RF-LAMINATE pour RFEM
Manuel du module additionnel RF-LAMINATE pour RFEMGrégoire Dupont
 
Vers une mesure plus pertinente de l'efficacité publicitaire des campagnes Di...
Vers une mesure plus pertinente de l'efficacité publicitaire des campagnes Di...Vers une mesure plus pertinente de l'efficacité publicitaire des campagnes Di...
Vers une mesure plus pertinente de l'efficacité publicitaire des campagnes Di...Helene_Gloux
 
Cours base données
Cours base donnéesCours base données
Cours base donnéeskerosina
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Mohamed Aziz Chetoui
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientTaieb Kristou
 
LatexPourLeProfDeMaths.pdf
LatexPourLeProfDeMaths.pdfLatexPourLeProfDeMaths.pdf
LatexPourLeProfDeMaths.pdfWafaa Ibrihich
 
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)CLES-FACIL
 
Dimensionnement d'un Tour (IGH) R+17 sous Eurocodes
Dimensionnement d'un Tour (IGH)  R+17 sous Eurocodes Dimensionnement d'un Tour (IGH)  R+17 sous Eurocodes
Dimensionnement d'un Tour (IGH) R+17 sous Eurocodes Souhail Bouzidi
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développementGlei Hadji
 

Similaire à rapport de stage. (20)

Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
Performances d’un système virtualisé avec v mware esxi
Performances d’un système virtualisé avec v mware esxiPerformances d’un système virtualisé avec v mware esxi
Performances d’un système virtualisé avec v mware esxi
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
Manuel du module additionnel RF-LAMINATE pour RFEM
Manuel du module additionnel RF-LAMINATE pour RFEMManuel du module additionnel RF-LAMINATE pour RFEM
Manuel du module additionnel RF-LAMINATE pour RFEM
 
Vers une mesure plus pertinente de l'efficacité publicitaire des campagnes Di...
Vers une mesure plus pertinente de l'efficacité publicitaire des campagnes Di...Vers une mesure plus pertinente de l'efficacité publicitaire des campagnes Di...
Vers une mesure plus pertinente de l'efficacité publicitaire des campagnes Di...
 
Cours base données
Cours base donnéesCours base données
Cours base données
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 
SDTAN du Doubs
SDTAN du DoubsSDTAN du Doubs
SDTAN du Doubs
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
 
LatexPourLeProfDeMaths.pdf
LatexPourLeProfDeMaths.pdfLatexPourLeProfDeMaths.pdf
LatexPourLeProfDeMaths.pdf
 
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
Fusex: 2009-2010 SAT'LAUNCH (CLES-FACIL, INSA de LYON)
 
Dimensionnement d'un Tour (IGH) R+17 sous Eurocodes
Dimensionnement d'un Tour (IGH)  R+17 sous Eurocodes Dimensionnement d'un Tour (IGH)  R+17 sous Eurocodes
Dimensionnement d'un Tour (IGH) R+17 sous Eurocodes
 
rapport_stage_TBLB.pdf
rapport_stage_TBLB.pdfrapport_stage_TBLB.pdf
rapport_stage_TBLB.pdf
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
 

Dernier

Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneTxaruka
 
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 37
 
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 37
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film françaisTxaruka
 
PIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfPIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfRiDaHAziz
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxJCAC
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film françaisTxaruka
 
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 37
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Gabriel Gay-Para
 
PIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfPIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfRiDaHAziz
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 37
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursStagiaireLearningmat
 
Bernard Réquichot.pptx Peintre français
Bernard Réquichot.pptx   Peintre françaisBernard Réquichot.pptx   Peintre français
Bernard Réquichot.pptx Peintre françaisTxaruka
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxMartin M Flynn
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfSylvianeBachy
 
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfbdp12
 
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24BenotGeorges3
 

Dernier (18)

Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienne
 
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
 
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film français
 
PIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfPIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdf
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film français
 
Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024
 
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)
 
PIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfPIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdf
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceurs
 
Bernard Réquichot.pptx Peintre français
Bernard Réquichot.pptx   Peintre françaisBernard Réquichot.pptx   Peintre français
Bernard Réquichot.pptx Peintre français
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
 
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
 
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
 

rapport de stage.

  • 1. 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
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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.
  • 9. 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
  • 10. 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
  • 11. 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.
  • 12. 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.
  • 13. 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;.
  • 14. 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.
  • 15. 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
  • 16. 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.
  • 17. 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).
  • 18. 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
  • 19. 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.
  • 20. 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].
  • 21. 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].
  • 22. 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.
  • 23. 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.
  • 24. 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).
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. 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.
  • 29. 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
  • 30. 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
  • 31. 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.
  • 32. 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).
  • 33. 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.
  • 34. 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
  • 35. 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
  • 36. 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.
  • 37. 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.
  • 38. 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.
  • 39. 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
  • 40. 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
  • 41. 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.
  • 42. 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.
  • 43. 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é
  • 44. 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.
  • 45. 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
  • 46. 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
  • 47. 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
  • 48. 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].
  • 49. 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
  • 50. 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.
  • 51. P a g e | 51 Chapitre 4 de Schéma Général de la grille
  • 52. 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:
  • 53. 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 :
  • 54. 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).
  • 55. 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
  • 56. 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;
  • 57. 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.
  • 58. 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
  • 59. 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.
  • 60. 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.
  • 61. 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.
  • 62. 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;,
  • 63. 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
  • 64. 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
  • 65. 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
  • 66. 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 à
  • 67. 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 ».
  • 68. 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.
  • 69. 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
  • 70. 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.
  • 71. 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,
  • 72. 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):
  • 73. 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.