MINISTÈRE DE L’ENSEIGNEMENT
                                                            ‫ﻭﺯﺍﺭﺓ ﺍﻝﺘﻌﻠﻴﻡ ﺍﻝﻌﺎﻝﻲ ﻭﺍﻝﺒﺤﺙ ﺍﻝﻌﻠﻤ...
Page |2




  Sommaire

Le plan de ce Rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8...
Page |3


       2.4.5 Normes ouvertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                  . . . . ...
Page |4


      2.9.2 Globus. . . . . . . . . . . . . . . . . . . . . . . . . . . . .        . . . . . . . . . . . . . . ....
Page |5


5 Procédure d'installation

   5.1. Préparation à l'installation de Globus. . . . . . . . . . . . . . . . . . . ...
Page |6


A.1.1 Création d'un utilisateur quot;Globusquot; . . . . . . . . . . . . . . . . . . .                          ...
Page |7


A.6.1 Configuration : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .         ...
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 d...
Page |9



Liste des tableaux

2.1 Les principaux services de Globus. . . . . . . . . . . . . . . . . . . . . . . . . . 37...
P a g e | 10



Table des figures
1.1 Un scénario de grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . ...
P a g e | 11




Remerciements
Remerciements

Nous avons une vive dette de gratitude envers tous ceux qui nous ont
aidés à...
P a g e | 12




                                                       Chapitre



                                      ...
P a g e | 13


Ces plateformes utilisées comme ressource unique et unifiée mènent
au concept de quot;grillesquot; qui appa...
P a g e | 14




                                                        Chapitre




                                    ...
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é...
P a g e | 16


Mettre en œuvre une grille de calcul, c'est vouloir partager des
ressources.     Or   les   différents   ut...
P a g e | 17




2.3 Caractéristiques d'une grille de calcul

La grille de calcul ou 'Grid Computing' reprend les principe...
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 grill...
P a g e | 19


requiert l'ajout ou la suppression d'un utilisateur ou d'une ressource
vue comme action habituelle dans le ...
P a g e | 20


Les ressources sont la propriété de personnes différentes, ce qui
signifie qu'elles relèvent de domaines ad...
P a g e | 21



2.4.4 Abolition de la distance

Les connexions à haute vitesse entre ordinateurs rendent possible
une gril...
P a g e | 22



2.5 Applications des grilles de calcul

Les principales applications des grilles de calcul peuvent être cl...
P a g e | 23




2.5.3 Calcul sur demande (On-Demand Computing)

Une grille de calcul pourra fournir les ressources pour s...
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 term...
P a g e | 25


Au niveau le plus bas, la couche réseau assure la connectabilité des

ressources sur la grille.


Au-dessus...
P a g e | 26


      d'une tâche jusqu'à sa terminaison, la soumettre à nouveau si
      elle   est     brusquement     in...
P a g e | 27


désigner l'ensemble de l'infrastructure physique de la grille, incluant
les ordinateurs et les réseaux de t...
P a g e | 28


inutilisé, collaboration entre équipes, délocalisation des services
fournis par une telle organisation, cal...
P a g e | 29



2.8 Différentes topologies de grilles

Nous répertorions les grilles d'un point de vue topologique en troi...
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écur...
P a g e | 31


à comprendre au sens large (librairies, codes sources, fichiers
exécutables...), d'autant que les créateurs...
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 platefo...
P a g e | 33



Conclusion
Les besoins en puissance de calcul pour la recherche scientifique
fondamentale dépassent souven...
P a g e | 34




                                                       Chapitre



                                      ...
P a g e | 35


données. Enfin une vision globale de son évolution et de son
architecture actuelle.

3.1 But de l'intergici...
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 :
 ...
P a g e | 37


       -Localisation et allocation des ressources : ce composant permet aux
      applications d'exprimer l...
P a g e | 38




 Fig. 2.1 -Conception des services de Globus en trois pyramides [6].




                  Fig. 2.2 -Prin...
P a g e | 39


Vue la multitude de services de bas niveau utilisés, le service GRAM
masque les différentes technologies de...
P a g e | 40


supporter des méthodes de communication co-existantes et de créer
des processus concurrents.
Le principe de...
P a g e | 41




  Fig. 2.3 - Associations entre source et destination dans Nexus [6].

Méthode de communication employée....
P a g e | 42


-quot;Grid Index Information Servicequot;(GIIS) : Tous les serveurs GRIS
d'une grille sont enregistrés lors...
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 c...
P a g e | 44


Elle est assurée par une architecture de sécurité complexe pour un
bon   fonctionnement       de   grille  ...
P a g e | 45


Principe d'échange des clés dans Globus : Globus assure la procédure
                       clés
suivante p...
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, ...
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 algorit...
P a g e | 48


service GridFTP, RFT et l'intégration des paquetages de kits quot;Grid
Packaging Toolkitquot; (GPT), ensuit...
P a g e | 49


En effet cette figure (FIG 2.7) comprend :
-Un ensemble de service d'implémentation (la moitié inférieure d...
P a g e | 50


multitude de services et d'outils de haut niveau comme GridFTP,
RFT... qui seront détaillés dans le chapitr...
P a g e | 51




               Chapitre




                   4
               de
Schéma Général de la
               gr...
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 puisq...
P a g e | 53


       Processeurs:
   •


-nombre de processeurs supportés par la carte mère : deux (2).

-nombre de proce...
P a g e | 54


            un (01) port parallèle;
        o

            deux (02) ports série (clavier & souris)
       ...
P a g e | 55


-nombre de processeurs supportés par la carte mère : deux (2).

-type de processeurs : Quad-core 64-bits;

...
P a g e | 56


            huit (08) port USB;
        o

            un (01) port SCSI;
        o

            un (01) sl...
P a g e | 57




                                                          Chapitre




                                  ...
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 ...
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 ...
P a g e | 60



5.1.2 Installation du système Linux

Il faut suivre la procédure d'installation normale de 'Scientifique
L...
P a g e | 61


L'utilisateur est libre de choisir le répertoire d'installation à condition
que ce répertoire appartienne à...
P a g e | 62


- une API ODBC permettant à n'importe quelle application
supportant ce type d'interface d'accéder à des bas...
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).
...
P a g e | 64


installer le service GSI qui représente l'infrastructure du service de
sécurité pour Globus Toolkit.
A trav...
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...
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 fic...
P a g e | 67


ajouter dans la balise « <parameter> » de « <globalConfiguration> »
le nom du hôte et l'adresse IP correspo...
P a g e | 68


Un fichier « pg_hba.conf » par défaut est installé lorsque le répertoire
data est initialisé par la command...
P a g e | 69


- authentication-method : Détermine la méthode d'authentification à
utiliser lors d'une connexion via cet e...
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éc...
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...
P a g e | 72




              Fig. 4.2 -Graphe de transition pour un job.


C’est-à-dire proches des données requises et ...
P a g e | 73


-Unsubmitted : Le job n'est pas encore soumis.
- StageIn : Le job attend que les fichiers exécutables ou d'...
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.
Prochain SlideShare
Chargement dans…5
×

rapport de stage.

4 675 vues

Publié le

Publié dans : Formation, Technologie, Business
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
4 675
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
186
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

rapport de stage.

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 51. P a g e | 51 Chapitre 4 de Schéma Général de la grille
  52. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

×