1. MINISTÈRE DE L’ENSEIGNEMENT
‫ﻭﺯﺍﺭﺓ ﺍﻝﺘﻌﻠﻴﻡ ﺍﻝﻌﺎﻝﻲ ﻭﺍﻝﺒﺤﺙ ﺍﻝﻌﻠﻤﻲ ﻭﺍﻝﺘﻜﻨﻭﻝﻭﺠﻴﺎ‬
SUPERIEUR ET DE LA RECHERCHE
SCIENTIFIQUE ET DE LA TECHNOLOGIE
CENTRE NATIONAL DES SCIENCES ‫ﺍﻝﻤﺭﻜﺯ ﺍﻝﻭﻁﻨﻲ ﻝﻠﻌﻠﻭﻡ ﻭ ﺍﻝﺘﻜﻨﻭﻝﻭﺠﻴﺎ ﺍﻝﻨﻭﻭﻴﺔ‬
ET TECHNOLOGIES NUCLÉAIRES
Rapport de stage
Mise en place d’une Grille de Calcul
Bengagi Wajdi
Réalisé par :
Encadré par : Mr. Moez Ben Hadj Hmida
Mr. Mohamed Mehdi Abbas
Etablissement d’origine : FSMPNT
Juillet-Aout 2008

2. Page |2
Sommaire
Le plan de ce Rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Liste des tableaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Table des figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Remerciements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 les grilles de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Définition d'une grille de calcul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Notion d'organisation virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Caractéristiques d'une grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Les objectifs de la grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 Partage de ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
2.4.2 Accès sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3 Utilisation de ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.4 Abolition de la distance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3. Page |3
2.4.5 Normes ouvertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Applications des grilles de calcul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.1 Supercalculateur réparti (Distributed Supercomputing) . . . . . . . . . 22
2.5.2 Calcul haut-débit (High-Throughput Computing) . . . . . . . . . . . . . . . . 22
2.5.3 Calcul sur demande (On-Demand Computing) . . . . . . . . . . . . . . . . . . . . 23
2.5.4 Calcul Collaboratif (Collaborative Computing) . . . . . . . . . . . . . . . . . . . . 23
2.5.5 Génération, traitement et stockage d'énormes quantités de
données (Data intensive Computing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Architecture générale d'une grille de calcul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Types de communication dans une grille de calcul. . . . . . . . . . . . . . . . . . . . 27
2.7.1 Architecture Client/serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.7.2 Architecture Pair à Pair (Peer to Peer) . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7.3 Architecture orientée services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.8 Différentes topologies de grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8.1 Intragrille (en analogie avec Intranet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8.2 Extragrille (en analogie avec Extranet) . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8.3 Intergrille (en analogie avec Internet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.9. Les intergiciels de grille de calcul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.9.1 Legion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4. Page |4
2.9.2 Globus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Globus
3 Globus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.But de l'intergiciel Globus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3. 2 Les voies de standardisation de Globus Toolkit. . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 OGSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
3.2.2 OGSI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Les services de Globus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 Gestion des ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2 Gestion de communications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.3 Service d'information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.4 Service de sécurité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4 Evolution et architecture de l'intergiciel Globus. . . . . . . . . . . . . . . 47
4 Schéma Générale du la grille
4.1 Réseaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Composant de la grille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.1 Machines esclaves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.2 Machines mètres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5. Page |5
5 Procédure d'installation
5.1. Préparation à l'installation de Globus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
5.1.1. Installation du système Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1.2 Configuration du réseau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.3 Création des comptes utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.4 Création des répertoires d'installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.5 Installation des outils nécessaires pour Globus Toolkit 4.0.1. 61
5.2 Installation de l'Autorité de Certification : SimpleCA. . . . . . . . . . . . . . . . 63
5.3 Configuration des services de grille de calcul . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.1 Configuration du service gridftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.2 Lancement des web containers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
5.3.3 Configuration du service RFT (Releable File Transfer) . . . . . . . . . 67
5.3.4 Configuration du service GRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4 Soumission des Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4.1 Description d'un job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4.2 Exemples de soumission de différents jobs. . . . . . . . . . . . . . . . . . . . . . 73
Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A Procédure d'installation d'une grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.1 Préparation à l'installation de Globus Toolkit 4.0.1 . . . . . . . . . . . . . . . . . . . . 79

6. Page |6
A.1.1 Création d'un utilisateur quot;Globusquot; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.1.2 Création d'un répertoire d'installation de Globus Toolkit 4.0.1. . . . . 80
A.1.3 Installation des outils nécessaires pour Globus Toolkit4.0.1 . . . . . . . . 80
A.2 Installation de Globus Toolkit 4.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.3 Installation de l'Autorité de Certification : AC . . . . . . . . . . . . . . . . . . . . . . .. . . . 84
A.3.1 Création des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 84
A.3.2 Exécution du script d'installation . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 85
A.3.3 Installation du service GSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.3.4 Demande de certificat pour un noeud hôte quot;Host Certificatesquot; . . . . 88
A.3.5 Signature du certificat du noeud hôte quot;Host Certificatesquot; . . . . . . . . . . 88
A.3.6 Signature du certificat de L'utilisateur quot;Globusquot; . . . . . . . . . . . . . . . . . . . . 89
A.3.7 Signature du certificat de l'utilisateur 'user1' . . . . . . . . . . . . . . . . . . . . . . . . 91
A.3.8 Création du certificat du 'container' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.3.9 Ajout des autorisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.3.10 Vérification du certificat de l'utilisateur 'Globus' . . . . . . . . . . . . . . . . . . . 93
A.3.11 Vérification du certificat de 'user1' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.4 Installation de certificat pour plusieurs machines . . . . . . . . . . . . . . . . . . . 94
A.5 Installation de postgresql-8.0.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.5.1 Configuration de postgresql : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.6 Installation du service 'gridFTP' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7. Page |7
A.6.1 Configuration : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
A.6.2 Lancement du proxy : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
A.6.3 Test du service gsiftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
A.6.4 Lancement du serveur 'gridftp' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
A.6.5 Erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 109
A.7 Lancement des Services Web . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 110
A.7.1 Création d'un exécutable pour le lancement des Services Web. . . . 110
A.8 Configuration de RFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 113
A.8.1 Création du fichier quot;pg_hba.confquot; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.8.2 Création d'un utilisateur de la base 'postgres' . . . . . . . . . . . . . . . .. . . . . . . . 114
A.8.3 Création de la base 'rftDatabase' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
A.8.4 Test du fonctionnement de RFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
A.9 Installation du service GRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
A.9.1 Edition du fichier 'sudoers' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
A.9.2 Edition du fichier 'globus_gram_fs_map_con_g.xml' . . . . . . . . . . . .. . 117
B Exécution de jobs sur la grille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
B.1 Syntaxe 'RSl' de description de jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
B.2 Tests de soumission d'un job existant sur la machine locale . . . . . . . . 120
B.2.1 Test 1 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
B.2.2 Test 2 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8. Page |8
Le plan de ce Rapport
Le rapport est composé de Cinq parties :
Chapitre 1
Dans ce chapitre en décrit le rôle de grilles de calcul ainsi que les
différentes raisons qui ont conduit à leur apparition.
Chapitre 2
Ce chapitre est dédié à la présentation de la notion de grille en présentant
un état de l'art sur ce domaine, qui renferme une définition des différents
types de grille ainsi que la présentation des parties qui constituent
l'architecture globale de la grille.
Chapitre 3
Le chapitre 3 décrit l'intergiciel Globus ainsi que ses étapes d'évolution,
son architecture et les services offerts par ce dernier.
Chapitre 4
Il décrit l'architecture réseau utilisée dans la grille ainsi que les
performances des ressources physiques fournies pour mettre en places
notre grille de calcul.
Chapitre 5
Présente une procédure d'installation de l'intergiciel Globus Toolkit
version 4.0.1 et les différents outils nécessaires à la mise en place d'une
grille de calcul.

9. Page |9
Liste des tableaux
2.1 Les principaux services de Globus. . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1 Tableau des adresses des nœuds de la grille de calcul. . . . . . . . . 59

10. P a g e | 10
Table des figures
1.1 Un scénario de grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2 Architecture d'une grille de calcul en couche. . . . . . . . . . . . . . . 25
2.1 Conception des services de Globus en trois pyramides [6]. . . . 39
2.2 Principe du sablier [6]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3 Associations entre source et destination dans Nexus [6] . . . . . 44
2.4 Modèle conceptuel de MDS [6]. . . . . . . . . . . . . . . .. . . . .. . . . . . . . 43
2.5 Protocoles de sécurité de GT4 [6]. . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.6 Evolution de Globus [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.7 Schéma de l'architecture GT4, Les boîtes partagées dénotent le
code GT4, les boîtes blanches représentant le code utilisateur [1]. 48
3 Schéma général d’une grille de calcul . . . . . . . . . . . . . . . . . . . . 52
4.1 Etape de soumission d'un job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2 Graphe de transition pour un job. . . . . . . . . . . . . . . . . . . . . . . . . . 72
B.1 Soumission de job en local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
B.2 Soumission d'un job sur un nœud distant. . . . . . . . . . . . . . . . . . 122

11. P a g e | 11
Remerciements
Remerciements
Nous avons une vive dette de gratitude envers tous ceux qui nous ont
aidés à rassembler les faits qui constituent l'indispensable fondation
de ce travail.
Je tiens à remercier Monsieur Moez Ben Hadj Hmida pour sa
disponibilité et ses prestigieux conseils qui ont été d'une grande aide
dans la réalisation du projet et la rédaction de ce document,
spécialement ses relectures critiques et multiples des différentes
versions du mémoire et les nombreuses suggestions constructives de
sa part.
Je tiens également à remercier Monsieur Mohamed Mehdi Abbas,
pour son aide, et ses idées constructives dans le développement de
cette mémoire.
Enfin, je tiens à remercier tout le personnel du Service informatique
et Réseau de centre national de sciences et technologies nucléaire qui
ont attribué de près ou de loin au bon déroulement de notre stage.

12. P a g e | 12
Chapitre
1
Introduction Générale
e nos jours, les applications de recherche scientifique utilisent
des données de grandes tailles et nécessitent une puissance de
calcul de plus en plus importante. Initialement ces données étaient
développées sur des infrastructures composées d'un ensemble de
superordinateurs centralisés. Cependant, les besoins scientifiques et
technologiques sont en croissance rapide ce qui requière des
capacités de calcul et de stockage encore plus importantes.
Pour satisfaire ces exigences on a fait recours à des plateformes
hétérogènes partageant des ressources de calcul et de stockage de
plusieurs ordinateurs interconnectés entre eux par un réseau
internet.

13. P a g e | 13
Ces plateformes utilisées comme ressource unique et unifiée mènent
au concept de quot;grillesquot; qui apparaît comme un service public
défendant la notion quot;d'informatique à la demandequot;.
La notion de grille de calcul s'inspire énormément de la grille
d'électricité construite au début du vingtième siècle. Le terme quot;The
Gridquot; ou quot;grille de calculquot;, a été introduit pour la première fois aux
Etats-Unis durant les années quatre vingt dix pour décrire une
infrastructure de calcul répartie utilisée dans des projets de
recherche scientifique et industrielle. Afin d'exploiter cette
infrastructure matérielle, il était nécessaire de concevoir une
plateforme permettant la résolution des problèmes scientifiques à
partir des composants logiciels répartis facilement intégrables tout en
cachant la complexité des données, des algorithmes et l'hétérogénéité
des composants matériels tel que l'intergiciel quot;Globusquot; fondé par 'Ian
Foster'.
C'est dans ce cadre que se situe mon stage de technicien au sein du
centre nationale d'activité nucléaire de Tunisie. Qui vise à mettre en
place. L’intergiciel quot;Globusquot;.

14. P a g e | 14
Chapitre
2
Les Grilles de Calcul
a notion de grille de calcul appelée aussi quot;Grid
Computingquot; est une passerelle pour un modèle
d'informatique répartie permettant d'exploiter pleinement les
ressources et les capacités offertes vue comme une conséquence
logique des progressions technologiques.
Dans un premier lieu, nous définissons le concept de grille,
présentons ses caractéristiques, ses objectifs ainsi que sa forme et son
architecture.

15. P a g e | 15
2.1 Définition d'une grille de calcul
Une grille de calcul est dénie comme : quot;Une infrastructure matérielle
et logicielle fournissant un accès able, cohérent, à taux de
pénétration élevé et bon marché à des capacités de traitement et de
calcul [5]quot;.
Ainsi cette définition a été raffinée dans l'article quot;The Anatomie of the
Gridquot; écrit par 'Ian Foster', 'C. Kesselman' et 'S. Tuecke' [6] où ils
déclarent la grille de calcul comme étant quot;une coordination de
ressources partagées, une résolution de problèmes d'organisations
virtuelles, dynamiques et multi-institutionnellesquot;. Le concept
principal se manifeste dans la capacité de négocier le partage des
ressources parmi un ensemble de participants tels que fournisseurs et
consommateurs.
En effet le partage concerné n'est pas principalement l'échange de
dossier mais plutôt l'accès direct aux ordinateurs, logiciels, données,
qui est recommandé dans la résolution des problèmes collaboratifs et
les stratégies d'équilibrage de ressources émergeant dans l'industrie,
la science et la technologie. Ce partage est nécessairement commandé
avec des fournisseurs de ressources et des consommateurs définissant
clairement et soigneusement ce qui est partagé, qui a le droit de
partager, et les conditions dans lesquelles le partage se produit [4].
2.2 Notion d'organisation virtuelle

16. P a g e | 16
Mettre en œuvre une grille de calcul, c'est vouloir partager des
ressources. Or les différents utilisateurs et les différentes
organisations n'ont ni les mêmes besoins, ni les mêmes
préoccupations ; ils n'utiliseront donc pas nécessairement l'outil de la
même façon. Les données des uns n'intéressent pas forcément les
autres. Chaque domaine a ses propres contraintes de sécurité et fait
appel à des ressources de différentes natures.
Dans la phase de conception d'une grille, chacun des participants
doit être libre de choisir les ressources qu'il souhaite partager et les
conditions qu'il donne à ce partage.
Ainsi, on définit des Organisations Virtuelles qui peuvent prendre la
forme d fournisseurs d'applications, de fournisseurs de données
stockées, mais également de consommateurs de ressources. La durée
de vie des Organisations Virtuelles peut être variable, tout comme
leur composition et les buts qu'elles poursuivent. Ces dernières sont
concrètement des groupes d'utilisateurs qui ont des besoins
communs, des chercheurs d'une même discipline par exemple, ou
des groupes de serveurs mettant à disposition des ressources.

17. P a g e | 17
2.3 Caractéristiques d'une grille de calcul
La grille de calcul ou 'Grid Computing' reprend les principes
élémentaires du clustering, qui peut être considéré comme l'un des
ancêtres de la grille d'ordinateurs. Mais il est préférable de faire la
distinction entre une grille et un cluster.
Un cluster au sens strict est une grappe de machines homogènes
reliées entre elles à travers un réseau local. A l'opposé, une grille
regroupe un ensemble de machines reliées en réseau, pouvant être
distantes de plusieurs mètres, voire de plusieurs kilomètres (voir FIG
1.1).

18. P a g e | 18
Une grille de calcul se caractérise par :
-L'hétérogénéité : Une des caractéristiques inhérentes aux grilles de
calcul selon plusieurs points de vue : matériel, logiciel, politiques de
sécurité, contraintes d'exploitation, profil des utilisateurs, etc. Toute
la complexité liée aux différences concernant ces aspects doit être
invisible à l'utilisateur final d'où la nécessité d'un grand effort de
coordination entre tous les sites participant à une grille. Les
contraintes d'exploitation et de qualité de service de chaque site ne
doivent pas être sacrées par leur intégration à une grille. En effet
chaque site doit conserver une totale autonomie concernant ses
politiques d'accès, d'exploitation et d'évolution aussi bien côté
matériel que logiciel, tout en gardant la compatibilité avec les
services offerts à travers la grille [1].
-L'ouverture : La globalisation de ressources suppose un certain
degré d'ouverture des sites vers le monde extérieur. Cette ouverture
peut poser des problèmes auxquels une solution doit être trouvée
sans compromettre la sécurité du site. Un exemple qui illustre bien
ce point concerne l'authentification des utilisateurs. Un des apports
du modèle de grille de calcul est l'accès transparent pour le
chercheur aux ressources informatiques dispersées. En d'autres
termes, il n'est pas tenu de se connecter à une machine appartenant à
un site quelconque pour utiliser les ressources de ce dernier. Une
connexion sur un des sites appartenant à la grille devrait sure pour
lui donner accès aux autres sites de la même grille [3].
-Passage à l'échelle (Scalabilité) : Le nombre des utilisateurs et des
ressources dans une organisation virtuelle est dynamique chose qui

19. P a g e | 19
requiert l'ajout ou la suppression d'un utilisateur ou d'une ressource
vue comme action habituelle dans le système de grille de calcul. Pour
cette raison, de nouvelles contraintes de sécurité sur les applications
et les algorithmes de gestion de ressources ont eu lieu tel que le
'mapping' des sujets globaux vers des sujets locaux, la centralisation
de l'autorité de certification, le grand nombre d'utilisateurs, etc.
-La tolérance aux pannes : L'ouverture dans une grille de calcul n'est
pas sans risques. Pour tirer partie des ressources disponibles dans
une telle grille, un système d'information de l'état et de la structure
de ces ressources est nécessaire [9]. Il permet la découverte de
ressources utilisables à un moment donné et des relations entre elles
ainsi que l'occurrence de pannes. La publication de ces informations
généralement sensibles d'un point de vue sécurité doit se faire sans
compromettre ni l'intégrité et la sécurité de chaque site ni celles de
l'ensemble des sites partenaires.
2.4 Les objectifs de la grille de calcul
2.4.1 Partage de ressources
Il permet l'accès à la grille pour l'utilisation des ressources distantes
ou pour profiter des logiciels existants. Cette capacité de partage
implique plus qu'un simple transfert de fichiers, il requiert un accès
direct aux logiciels, aux ordinateurs et aux données. Elle peut même
permettre un accès direct à des capteurs, à des télescopes et à d'autres
appareils distants et de les commander.

20. P a g e | 20
Les ressources sont la propriété de personnes différentes, ce qui
signifie qu'elles relèvent de domaines administratifs différents,
qu'elles exécutent des logiciels différents et qu'elles sont régies par
des politiques de sécurité et de contrôle d'accès, également différentes
[2].
2.4.2 Accès sécurisé
C'est une conséquence directe de la première idée. Le partage de
ressources se traduit par certains problèmes liés à la réalisation de la
grille telle que la politique concernant l'accès, l'authentification et
l'autorisation. En effet, la grille doit être extrêmement souple et
dispose d'un mécanisme de comptabilisation qui sera utilisé pour
décider d'une politique d'établissement des prix d'utilisation de la
grille [2].
2.4.3 Utilisation de ressources
C'est là que la grille commence réellement à être intéressante, même
pour les privilégiés qui disposent d'abondantes ressources
informatiques, car quelle que soit l'abondance de nos ressource, il
arrive toujours un moment où se crée une le d'attente d'utilisateurs
désireux d'en disposer. Un mécanisme d'affectation efficace et
automatique des jobs à différentes ressources permettra la réduction
des fils d'attente [2].

21. P a g e | 21
2.4.4 Abolition de la distance
Les connexions à haute vitesse entre ordinateurs rendent possible
une grille véritablement mondiale. Grâce à la généralisation de
l'utilisation des fibres optiques dans les systèmes de
télécommunications, doublent environ tous les neuf mois. Certains
grands réseaux fonctionnent maintenant à 155 mégabits par seconde
(Mb/s), alors qu'en 1985 les centres de supercalculateurs des États-
Unis étaient connectés à 56 kilobits par seconde (Kb/s) soit une
amélioration d'un facteur de 3000 en 15 ans. Bien sûr, la distance ne
sera jamais complètement abolie, parce que quelqu'un aura toujours
un problème à traiter sur la grille, pour lequel les connexions les plus
rapides sembleront lentes [2].
2.4.5 Normes ouvertes
Des normes spécifiques à la grille sont en cours d'élaboration par une
entité de normalisation du même genre, le Global Grid Forum.
Fédérant plus de 5000 chercheurs et praticiens individuels, cet
organe représente une force significative en matière d'édiction de
normes et d'élaboration d'éléments permettant le travail en commun.
Actuellement, une norme connue sous le nom OGSA (Architecture
ouverte de services de grille) est considérée comme une référence clé
pour les projets d'élaboration de grilles [2].

22. P a g e | 22
2.5 Applications des grilles de calcul
Les principales applications des grilles de calcul peuvent être classées
en cinq catégories:
2.5.1 Supercalculateur réparti (Distributed
Supercomputing)
Une grille de calcul pourra agréger une importante quantité de
ressources an de fournir la puissance de calcul nécessaire pour de
nombreuses applications et que même les supercalculateurs les plus
modernes ne peuvent pas fournir.
Selon la nature et l'étendue de la grille, les ressources agrégées
pourront être composés de stations de travail d'une université ou
même de supercalculateurs des organismes de recherche d'un pays.
2.5.2 Calcul haut-débit (High-Throughput Computing)
Une grille de calcul sera utilisée pour ordonnancer en parallèle une
importante quantité de tâches indépendantes les unes des autres.
Comme exemples d'applications nous pouvons citer la recherche de
clés cryptographiques, les simulations de molécules et l'analyse du
génome.

23. P a g e | 23
2.5.3 Calcul sur demande (On-Demand Computing)
Une grille de calcul pourra fournir les ressources pour satisfaire les
demandes à court terme d'une application que les ressources locales
ne sont pas en mesure d'y assurer (cycles processeur, stockage...). Le
dé principal pour les concepteurs de telles grilles est la nature
dynamique et aléatoire des demandes faites par les utilisateurs qui
peuvent constituer une large population.
2.5.4 Calcul Collaboratif (Collaborative Computing)
Cette classe d'applications inclut les applications d'interaction entre
humains dans des environnements de simulation en temps réel
(conception et interaction avec un nouveau moteur d'avion,
conception d'un plan urbain...).
2.5.5 Génération, traitement et stockage d'énormes quantités
de données (Data intensive Computing)
Dans de telles applications, une grille de calcul pourra absorber et
stocker d'importantes quantités d'information générées. Comme
exemple d'applications nous pouvons mentionner la production
d'une carte de l'univers, la prévision météorologique à long terme, les
simulations quantiques.

24. P a g e | 24
2.6 Architecture générale d'une grille de calcul
L'architecture de la grille est souvent décrite en termes de quot;couchesquot;,
dont chacune assure une fonction spécifique. D'une façon générale
les quot;couches hautesquot; sont axées sur l'utilisateur (quot;centréesquot; sur celui-
ci), tandis que les quot;couches bassesquot; sont plus orientées vers les
ordinateurs et les réseaux (quot;centréesquot; sur le matériel)(voir FIG 1.2).

25. P a g e | 25
Au niveau le plus bas, la couche réseau assure la connectabilité des
ressources sur la grille.
Au-dessus de celle-ci, la couche ressources, constituée des
ressources effectives faisant partie de la grille, telles que les
ordinateurs, les systèmes de mémoire, les catalogues de données
électroniques, et mêmes des capteurs, tels que des télescope ou
d'autres instruments qui peuvent être connectés directement au
réseau.
La couche intergicielle assure les fonctions permettant aux divers
éléments (serveurs, mémoires, réseaux, etc.) de participer à un
contexte de grille unifiée. Cette couche intergicielle peut être
considérée comme l'intelligence qui fédère les divers éléments le
quot;cerveauquot; de la grille. Parmi les fonctions requises, nous citons :
Ordonnancement : un ordonnanceur devra trouver la machine
•
la plus appropriée pour exécuter les tâches qui lui sont
soumises.
Les ordonnanceurs peuvent aller du plus simple (allocation de
•
type round-robin) au plus compliqué (ordonnancement à base
de priorités). Les ordonnanceurs réagissent à la charge de la
grille. Ils déterminent le taux de charge de chaque ressource
ande bien ordonnancer les prochaines tâches.
Ils peuvent être organisés en hiérarchie avec certains
•
interagissant directement avec les ressources, et d'autres (méta
ordonnanceurs) interagissant avec les ordonnanceurs
intermédiaires. Ils peuvent aussi superviser le déroulement

26. P a g e | 26
d'une tâche jusqu'à sa terminaison, la soumettre à nouveau si
elle est brusquement interrompue et la terminer
prématurément si elle se trouve dans une boucle infinie
d'exécution.
Réservation : Il est possible dans les grilles de calcul de réserver
•
les ressources à l'avance et ceci an de garantir une certaine
qualité de service et de respecter certaines échéances. Pour cela
l'intergiciel devra fournir un système de réservation permettant
aux utilisateurs d'exprimer leurs besoins en ressources et
d'effectuer la réservation.
Services d'information et d'annuaire : Une grille est un
•
environnement où le nombre et la charge des ressources sont
dynamiques. Un objectif lors de la conception d'une grille est de
rendre les ressources facilement accessibles à tous les processus.
Il est alors nécessaire de fournir des mécanismes permettant
d'enregistrer et de découvrir ces ressources et d'identifier leur
état tel que le Service de nom. Comme tout système réparti, une
grille devra permettre de référencer ses ressources d'une façon
standard et uniforme.
La couche située au niveau le plus élevé de la structure est la couche
application, qui comprend les diverses applications scientifiques,
techniques, de gestion, financières des utilisateurs, leurs portails,
ainsi que les boîtes à outils de génie logiciel de ces applications. C'est
la couche vue par les utilisateurs de la grille.
Il existe d'autres façons de décrire cette structure en couches. Par
exemple, des spécialistes aiment utiliser le terme quot; fabrique quot; pour

27. P a g e | 27
désigner l'ensemble de l'infrastructure physique de la grille, incluant
les ordinateurs et les réseaux de transmission (en anglais quot; fabrics quot;).
Par ailleurs, dans la couche intergiciel se scinder en une couche de
protocoles, de ressources et de connectabilité et, au-dessus de celle-
ci, une couche de services collectifs.
2.7 Types de communication dans une grille de
calcul
2.7.1 Architecture Client/Serveur
Dans les systèmes client/serveur où les données peuvent être
distribuées à travers les serveurs multiples ou centralisés, chacun
avec ses propres administrateurs, des services de sécurité sont
indispensables ainsi que des caches pour éviter la congestion du
réseau.
2.7.2 Architecture Pair à Pair (Peer to Peer)
Une infrastructure de type pair à pair dans une grille de calcul est
généralement constituée d'un ensemble de nœuds dont chacun se
comporte à la fois comme un client et un serveur an de satisfaire les
besoins tel que : partage de fichiers, utilisation du temps CPU

28. P a g e | 28
inutilisé, collaboration entre équipes, délocalisation des services
fournis par une telle organisation, calculs distribués...
2.7.3 Architecture orientée services
En définissant l'architecture d'une grille de calcul, les concepteurs
peuvent adopter deux approches différentes : se focaliser sur les
ressources ou bien sur les services qu'offrent ces ressources. Dans le
dernier cas l'architecture est dite orientée services. Dans OGSA on
s'intéresse à la notion de service : les ressources de calcul, de
stockage, de communication qui sont présentées comme des services
[6].
Dans une telle architecture, l'interopérabilité (caractéristique
fondamentale d'une grille de calcul) est assurée en standardisant les
interfaces des services de la grille et les protocoles permettant
d'invoquer les opérations de ces interfaces.
Ainsi plusieurs implémentations peuvent correspondre à une même
interface : c'est le principe de la quot;Virtualisationquot; des services. Pour
assurer cela, un langage standard est nécessaire pour décrire les
interfaces. Dans le cas d'OGSA le protocole WSDL (quot;Web Services
Description Langagequot;) est utilisé. WSDL permet de découpler la
définition de l'interface, de l'implémentation et de l'invocation du
service.

29. P a g e | 29
2.8 Différentes topologies de grilles
Nous répertorions les grilles d'un point de vue topologique en trois
types par ordre croissant d'étendue géographique et de complexité.
2.8.1 Intragrille (en analogie avec Intranet)
La plus simple, composée d'un ensemble relativement simple de
ressources et de services et appartenant à une organisation unique.
Les principales caractéristiques d'une telle grille sont la présence d'un
réseau d'interconnexion, d'un domaine de sécurité unique et d'un
ensemble relativement statique et homogène de ressources.
2.8.2 Extragrille (en analogie avec Extranet)
Une extragrille étend le modèle en agrégeant plusieurs intragrilles.
Les principales caractéristiques d'une telle grille sont la présence d'un
réseau d'interconnexion hétérogène haut et bas débit (LAN / WAN),
de plusieurs domaines de sécurité distincts, et d'un ensemble plus ou
moins dynamique de ressources.
2.8.3 Intergrille (en analogie avec Internet)
Une intergrille consiste à agréger les grilles de multiples
organisations, en une seule grille. Les principales caractéristiques

30. P a g e | 30
d'une telle grille sont la présence d'un réseau d'interconnexion
hétérogène, de plusieurs domaines de sécurité distincts et ayant
parfois des politiques de sécurité différentes, et d'un ensemble très
dynamique de ressources.
2.9. Les intergiciels de grille de calcul
La grille de calcul est un point focal de toutes ces activités, et permet
d'envisager des projets utilisant des ressources géographiquement
distribuées et partagées par des groupes d'utilisateurs. Parmi ces
projets qui ont acquis plus de maturité au niveau académique nous
citons :
2.9.1 Légion
C'est un système entier, résolument pair à pair, développé à
l'université de Virginie, aux Etats-Unis. Initié dès 1993, le projet a
donné lieu à une première version publique en 1997. Plus qu'un
simple système d'exploitation, Legion est considéré comme un
middleware, ou plus exactement un quot; méta système quot;. Le logiciel sert
d'interface entre le propre OS de l'utilisateur, et un nombre quasi
infini de ressources, distribuées partout sur le réseau, et hébergées
par les autres utilisateurs de Legion. Chaque utilisateur a donc
l'impression de ne quot;voirquot; que son propre ordinateur, mais fait en
réalité appel à de multiples quot;ressourcesquot; répartis sur le réseau. Legion
est un système orienté objet, et la notion de quot;ressourcesquot; partagées est

31. P a g e | 31
à comprendre au sens large (librairies, codes sources, fichiers
exécutables...), d'autant que les créateurs du système se flattant du fait
qu'il soit capable de gérer plusieurs milliers de milliards de
ressources, disponibles sur des plates-formes matérielles et logicielles
de toutes natures. Bien sûr, conformément aux principes mêmes du
pair-à-pair, chaque utilisateur peut décider ou non d'ouvrir les
propres ressources de son ordinateur aux autres utilisateurs, et ce de
façon particulièrement fine.
2.9.2 Globus
C'est un projet 'open source' visant à créer les logiciels et les outils
nécessaires pour la conception et la mise en œuvre de grilles de
calcul. Globus est principalement développé aux Etats-Unis dans
l'Argonne National Laboratory par l'équipe d’Ian Foster. Les travaux
sur Globus ont commencé en 1997 et le projet est toujours actif.
Le quot; Globus Toolkit quot; est formé d'un ensemble de composants. Son
architecture modulaire permet d'apporter les modifications et les
améliorations d'une manière rapide et efficace. Globus est devenu le
standard 'ipso facto' utilisé dans les projets de grilles de calcul. De
nombreuses entreprises ont ainsi adopté Globus pour servir comme
base de leurs produits commerciaux pour les grilles de calcul.
Dans le prochain chapitre, nous détaillerons les principales
fonctionnalités offertes par Globus à ses utilisateurs en termes de
sécurité, de services d'information, de gestion des communications,
de gestion des ressources et de traitement des données.

32. P a g e | 32
2.9.2 UNICORE
Il vise à développer des mécanismes permettant un accès sécurisé et
uniforme à des plateformes de calcul de haute performance et leurs
ressources associées [7]. UNICORE se base, sur des outils, des
standards et des mécanismes existants an de fournir les
fonctionnalités demandées. Les objectifs des concepteurs du système
visent à [8] :
Fournir à l'utilisateur une interface graphique intuitive et facile
•
à utiliser.
Fournir des mécanismes de sécurité suffisants.
•
Utiliser des technologies sous -jacentes déjà existantes et
•
approuvées.
Avoir une architecture basée sur le concept de tâches
•
génériques ou abstraites.
Avoir un impact minimal sur les ressources sous-jacentes.
•
UNICORE est conçu pour supporter une exécution non interactive de
tâches (batch jobs). Ainsi il supporte, à travers l'exploitation de la
nature parallèle des applications, le méta calcul asynchrone (en
contraste avec d'autres systèmes tels que Globus et Légion qui
supportent un modèle de méta calcul synchrone).

33. P a g e | 33
Conclusion
Les besoins en puissance de calcul pour la recherche scientifique
fondamentale dépassent souvent les possibilités qu'ore la technologie.
Il faut donc inventer constamment de nouvelles solutions pour
permettre à la recherche de disposer d'outils adaptés.
La grille de calcul reprend l'idée qu'une application lourde puisse
être découpée en petites tâches isolées, confiées à des ordinateurs
différents au travers d'un réseau et dont l'aspect économique est
particulièrement séduisant. Dans la suite, nous nous intéresserons à
expliciter un intergiciel de grille de calcul quot; Globus quot; an de mettre en
relief les mécanismes de grille ainsi que son objectif.

34. P a g e | 34
Chapitre
3
Globus
Ans ce Chapitre nous présentons le Projet Globus. C'est un
projet 'open source' visant à créer les logiciels et les outils
nécessaires pour la conception et la mise en œuvre d'une grille de
calcul. Globus est principalement développé aux Etat Unis, au sein de
l'quot;Argonne National Laboratoryquot; par l'équipe de 'Ian Foster'. Le projet
Globus a commencé en 1997 et il est toujours actif.
Dans une première partie nous présenterons son but et ses voies de
standardisation, dans la suite de ce chapitre nous allons présenter les
principales fonctionnalités offertes par Globus à ses utilisateurs en
termes de sécurité, de services d'information, de gestion des
communications, de gestion des ressources et de traitement des

35. P a g e | 35
données. Enfin une vision globale de son évolution et de son
architecture actuelle.
3.1 But de l'intergiciel Globus
Le quot;Globus Toolkitquot; est vu comme une boite à outils facilitant le
développement d'applications basée sur la notion de grille. En effet,
ses fondateurs implémentent une couche logicielle supplémentaire
qui fait abstraction à l'hétérogénéité de l'environnement ainsi qu'une
architecture modulaire permettant d'apporter des modifications et
des améliorations d'une manière rapide et efficace. Le programmeur
ne se préoccupe plus de l'hétérogénéité des nœuds aussi bien au
niveau de l'authentification qu'au niveau de la recherche des
ressources disponibles.
3.2 Les voies de standardisation de Globus Toolkit
Afin d'atteindre le but mentionné ci-dessus, les développeurs de
Globus cherchent à établir et respecter des normes dans le
déploiement des services. Ces normes se basent sur les travaux de
recherche du quot; Global Grid Forum quot; qui ont recensé les besoins des
Utilisateurs des grilles de calcul et de la manière d'implémentation.
Ces recherches ont abouti à la notion d'OGSA (Open Grid Services
Architecture) et d'OGSI (Open Grid Service Infrastructure).
3.2.1 OGSA
L'quot;Open Grid Service Architecturequot; (OGSA) permet de spécifier les
bases des grilles de calcul. En effet pour avoir un quot;frameworkquot;
largement adopté il faut respecter les définitions des interfaces, des

36. P a g e | 36
comportements, des modèles de ressource, etc. C'est ce qu'on appelle
la plate-forme OGSA qui repose sur :
-La spécification de l'ensemble des services importants tels que les
applications scientifiques et de commerce électronique.
-L'identification des services de base fondés sur des protocoles et
des langages standards et ouverts comme WSDL (Web Service
Description Langage), SOAP (Simple Object Access Protocol), et XML.
-La spécification à un niveau relativement élevé des
fonctionnalités requises par ces services et les interactions entre elles.
3.2.2 OGSI
En se basant à la fois sur les technologies de grille et les Services
Web, l’OGSI (Open Grid Services Infrastructure) définie les
mécanismes de création, de gestion et d'échange d'informations entre
les services de grille. Cet échange comprend la découverte des
services déjà créés et leur utilisation qui permet une gestion des
services sur le long terme tout en étant sécurisé et résistant aux
pannes.
3.3 Les services de Globus
Globus fournit les fonctionnalités et les services de base nécessaires à
la construction de grille de calcul tel que la sécurité, la gestion des
ressources, la communication. Il est composé d'un ensemble de
modules ayant chacun une interface permettant aux services de
niveau supérieur d'invoquer ses mécanismes.

37. P a g e | 37
-Localisation et allocation des ressources : ce composant permet aux
applications d'exprimer leurs besoins en fournissant les mécanismes
d'identification des ressources adéquates.
-Communication : ce composant permet aux différentes applications
de communiquer entre elles selon plusieurs modes : communication
par message, mémoire distribuée, appel de procédure à distance, etc.
-Information sur les ressources : permet d'obtenir des informations
sur l'état et la structure globale du système.
-Mécanismes de sécurité : ce composant fournit les mécanismes
d'authentification et d'autorisation des utilisateurs.
-Création et lancement des processus : permet de préparer
l'environnement de lancement et d'exécution d'un processus.
- Accès aux données : Accès performant et consistant aux données
stockées dans les fichiers et les bases de données.
La table ci-dessous (TAB 2.1) montre les différents services offerts
par Globus qui peuvent être organisés en trois pyramides construites
sur une base commune : le composant de sécurité (GSI), sur laquelle
reposent la gestion des ressources (GRAM), les mécanismes de
communication (Nexus) et les services d'information(MDS)(voir FIG
2.1).
Services nom Description
Gestion des ressources GRAM Allocation des ressources et gestion des processus.
Communication Nexus Services de communication unicast et multicast.
Sécurité GSI Authentification et autorisation.
Information MDS Information sur la structure et l'état de la grille.
Tab. 2.1 - Les principaux services de Globus.

38. P a g e | 38
Fig. 2.1 -Conception des services de Globus en trois pyramides [6].
Fig. 2.2 -Principe du sablier [6].
3.3.1 Gestion de ressources
Elle est assurée par le service GRAM quot;Globus Ressource Allocation
Managerquot; qui permet la gestion et la supervision des ressources.

39. P a g e | 39
Vue la multitude de services de bas niveau utilisés, le service GRAM
masque les différentes technologies de gestion de ressources de bas
niveau. Ainsi les différents services de haut niveau n'ont à se
préoccuper que de l'interfaçage avec GRAM.
Chaque entité GRAM est responsable d'un ensemble de ressources
opérant selon une politique commune et spécifique au site dans
lequel elles se trouvent. Cette dernière est souvent implémentée par
un ordonnanceur tel que 'Fork', 'Condor' ou 'LSF' quot;Load Sharing
Facility quot;. Le service GRAM s'interface ainsi avec ce système et traduit
les requêtes des services de haut niveau en requêtes compréhensibles
par le gestionnaire de bas niveau. De cette façon, les administrateurs
des ressources d'une grille de calcul peuvent choisir les outils de
gestion de bas niveau qui leur conviennent selon une API unifiée
(celle de GRAM). Avec l'API de GRAM, les besoins en ressources sont
exprimés en un langage appelé RSL quot;Ressource Spécification
Langagequot;. A partir de GRAM des politiques globales de gestion de
ressources (au niveau de la grille) peuvent être construites et
implémentées par des courtiers (quot;Resource Brokersquot;). Un exemple
d'architecture telle que définie dans la figure 2.2, sera détaillée dans
le chapitre IV.
3.3.2 Gestion de communications
Les services de communications entre processus dans Globus sont
assurés par la librairie de communication Nexus. Le choix de cette
librairie est adopté pour deux raisons :
-la première est que Nexus supporte plusieurs outils de
développement parallèles et de calcul distribués tel que MPI
(Message Parssing Interface) , le deuxième est qu'il est conçu pour

40. P a g e | 40
supporter des méthodes de communication co-existantes et de créer
des processus concurrents.
Le principe de l'architecture de Nexus est similaire à celui de GRAM :
fournir une API unifiée aux services de haut niveau (MPI, RPC,
CORBA...) tout en s'interfaçant avec une multitude de services de bas
niveau (TCP, UDP...). Les services de communication de Nexus sont
utilisés extensivement dans l'implémentation des autres services de
Globus. Les besoins des applications varient de la communication
fiable par messages à la communication multipoint non fiable. Les
protocoles IP et TCP ne sont pas en mesure de répondre à ces besoins.
Nexus est alors utilisé pour combler ce manque.
Les communications dans Nexus sont définies en employant deux
abstractions : les liens de communication (quot;Communication Linksquot;) et
les requêtes de service distant (quot;Remote Service Requestquot; ou RSR).
Un lien de communication est formé par l'association d'une source
(quot;startpointquot;) et d'une destination (quot;endpointquot;). Une opération de
communication est initiée en appliquant une requête de service
distant à une source.
Cet appel de procédure asynchrone permet de transférer des données
de la source vers toutes les destinations auxquelles elle est reliée.
Plusieurs sources peuvent être associées à une destination et vice
versa ce qui permet de construire des structures de communication
complexes illustrés par la figure ci-dessous (FIG 2.3).
Les liens de communication dans Nexus peuvent être transposés sur
différentes méthodes de communication sous-jacentes chacune ayant
ses propres caractéristiques : protocole utilisé, sécurité, qualité de
service. En associant un attribut à un lien de communication entre
une source et une destination, une application peut contrôler la

41. P a g e | 41
Fig. 2.3 - Associations entre source et destination dans Nexus [6].
Méthode de communication employée.
3.3.3 Service d'information
Globus offre le composant quot;Metacomputing Directory Servicequot; ou
MDS permettant l'accès aux informations telles que processeurs,
mémoires, bandes passantes, interface réseau. Il offre les composants,
les outils et les APIs nécessaires pour la découverte, la publication et
l'accès aux informations statiques ou dynamiques.
MDS utilise le standard LDAP quot;Lightweight Directory Access
Protocolquot; comme base pour la représentation et l'accès aux données.
Plus spécifiquement, il est constitué des modules suivants :
-quot;Grid Resource Information Servicequot;(GRIS) : Les serveurs GRIS
peuvent se trouver dans plusieurs endroits dans une grille et
contiennent toute information concernant les machines qui y sont
enregistrées. L'architecture de GRIS permet d'étendre facilement la
nature des informations qu'ils peuvent contenir. Un serveur GRIS ne
contient jamais les informations concernant toutes les machines
d'une grille pour ne pas charger le serveur.

42. P a g e | 42
-quot;Grid Index Information Servicequot;(GIIS) : Tous les serveurs GRIS
d'une grille sont enregistrés lors de leur démarrage avec un serveur
GIIS. Ce dernier contient des informations concernant la localisation
des serveurs GRIS et les noms des machines enregistrées. Ainsi un
utilisateur peut avoir des informations sur une machine particulière
en contactant le serveur GIIS.
Un seul serveur GIIS dans une grille constitue un point fragile. Pour
cela des serveurs secondaires sont mis en place pour assurer une
bonne tolérance aux pannes.
D'autre part les serveurs GIIS peuvent être organisés selon une
hiérarchie comme le système DNS.
-Fournisseur d'information (quot;Information Providerquot;) : Ce composant
assure la traduction des informations concernant les ressources selon
le schéma de MDS.
- Client MDS : Ce composant permet d'interroger MDS pour obtenir
des informations concernant une ressource.

43. P a g e | 43
La figure ci-dessous montre le modèle conceptuel de MDS (voir FIG
2.4).
Fig. 2.4 -Modèle conceptuel de MDS [6].
3.3.4 Service de sécurité
Notion de sécurité

44. P a g e | 44
Elle est assurée par une architecture de sécurité complexe pour un
bon fonctionnement de grille appelée GSI (Grid Security
Infrastructure) qui permet de garantir les trois propriétés nécessaires
pour sécuriser un système d'information notant : la confidentialité,
l'intégrité et la disponibilité de l'information.
En effet, Globus repose sur la cryptographie à clé publique. Ainsi
pour utiliser les mécanismes de sécurité de GSI, il faut créer une
paire de clés (publique/privé) et demander la délivrance d'un
certificat numérique (certificat X.509) d'une autorité de certification
(AC) pour chaque nœud de la grille. A la fin, pour chaque nœud on a
trois fichiers contenant respectivement la clé publique de l'AC, la clé
privée du nœud et le certificat numérique du nœud.
Le fichier contenant la clé privée du nœud est particulièrement
sécurisé et ne disposant que de droit de lecture par son propriétaire
pour ne pas y permettre un accès illicite par des utilisateurs non
autorisés. De plus la clé privée n'est fonctionnelle qu'avec
l'introduction d'un mot de passe par l'utilisateur, cela permet
d'introduire une couche de sécurité supplémentaire.
Authentification et autorisation
A cause de l'environnement hétérogène et géographique étendu des
grilles de calcul, l’authentification des machines et des utilisateurs est
un point important. En effet, il faut établir une relation de confiance
entre les différents nœuds de la grille malgré les politiques de
sécurité qui peuvent varier entre les organisations.
Pour cela GSI offre un mécanisme d'authentification mutuelle et
d'autorisation qui utilise les protocoles SSL/TLS comme base.

45. P a g e | 45
Principe d'échange des clés dans Globus : Globus assure la procédure
clés
suivante pour chaque requête d'exécution de tâche :
1. Le nœud A envoie son certificat au nœud B.
2. B s'assure que le certificat est valide et extrait l'identité et la clé
publique de A du certificat.
3. B génère un nombre aléatoire et l'envoie à A.
4. Lors de la réception de ce nombre, A le chiffre avec sa clé privée
en demandant à l'utilisateur d'entrer son mot de passe et l'envoie à B.
5. Lors de la réception du nombre chiffré, B le chiffre avec la clé
publique de A et s'assure qu'il est le même. A est alors authentifié par
B.
6. La procédure est répétée dans le sens inverse pour que A
authentifie B.
7. B transporte le nom de l'utilisateur se trouvant dans le certificat
en un nom d'utilisateur local au nœud. Pour cela un fichier appelé
grid-mapfile est utilisé. Il contient une entrée pour chaque utilisateur
de la grille :'/O=Grid/O=Globus/OU=grid.cnstn/CN=gridcnstn' Globus.
Cette ligne permet de transporter le nom de domaine (DN) de
l'utilisateur gridcnstn appartenant à la grille en un nom d'utilisateur
local Globus. C'est la phase d'autorisation.
Sign-
Délégation et Single Sign-On
Si chaque lancement d'une tâche nécessite le mot de passe utilisateur,
alors un nombre important de tâches ou un appel récursif de ces
dernières rend la demande de mots de passe impraticable. La création
d'un Proxy est une solution offerte par le GSI comme mécanisme de
délégation permettant de diminuer au maximum le nombre de fois
ou l'utilisateur fournit son mot de passe. Ce mécanisme de délégation

46. P a g e | 46
est une extension des mécanismes de SSL. Ainsi un utilisateur
authentifié par un nœud peut créer un Proxy, ce dernier lui délègue
son autorité. Un Proxy consiste en un nouveau certificat numérique
avec une nouvelle paire de clés publique/privée. Il contient l'identité
de l'utilisateur légèrement modifiée.
Fig. 2.5 - protocoles de sécurité de GT4 [6].
Ce certificat est signé par l'utilisateur lui-même et non pas par
l'Autorité de Certification. De plus un Proxy a une durée de vie
limitée. Il est alors utilisé pour assurer la procédure
d'authentification mutuelle et d'autorisation sans avoir à impliquer à
l'utilisateur.
La figure 2.5 ci-dessus présente l'architecture de service de sécurité
et résume les différents protocoles offerts par Globus, exemple
Globus Toolkit 4 (GT4).
Communications chiffrées
Le service GSI ne prévoit pas une procédure de chiffrement
prédéfinie entre les nœuds pour ne pas surcharger les échanges.
Mais puisque il utilise SSL comme système sous-jacent, la procédure

47. P a g e | 47
de création d'une clé secrète commune entre deux nœuds est
possible. Cette clé sera utilisée par un algorithme de chiffrement tel
que DES pour chiffrer les échanges. D'autre coté GSI assure par
défaut L'intégrité des données.
3.4 Evolution et architecture de l'intergiciel Globus
Comme tout projet open source, toujours actif, Globus a subit
plusieurs stades d'évolution. Ces étapes sont les résultats de la
migration de certains composants d'une
Fig. 2.6 - Evolution de Globus [1].
version à une autre et de l'ajout de nouveaux composants.
La convergence vers la notion de Services Web dans la grille de
calcul est l'ambitieux objectif que se donne Globus. Ainsi le schéma
ci-dessus (FIG 2.6) explique cette évolution en fonction de l'échelle
de temps.
La version1 de Globus Toolkit était juste une définition ou métaphase
de services GRAM et MDS. Globus Toolkit2 est venu avec l'ajout du

48. P a g e | 48
service GridFTP, RFT et l'intégration des paquetages de kits quot;Grid
Packaging Toolkitquot; (GPT), ensuite Globus toolkit3 est conforme à la
norme OGSA, qui vise à combiner la technologie des Services Web à
celle du Grid Computing. D'ailleurs cette version regroupe un certain
nombre d'outils standards en open source (XML, SOAP). Enfin avec
Globus Toolkit4 les protocoles ont migré vers les quot;Web Services
Resource FrameWorkquot; (WSRF) qui sont des services web incluant les
services de grilles. Des nouveaux composants sont aussi ajoutés
comme exemple quot;C WS-Corequot;, ainsi les codes sources des
bibliothèques des Services Web sont écrit en C et C++ bien qu'elles
étaient uniquement en java dans la version Globus Toolkit3.
Voici une présentation de l'architecture générale de Globus Toolkit
dans sa dernière version et illustrant ses différents composants :
Fig. 2.7 -Schéma de l'architecture GT4, Les boîtes partagées dénotent
le code GT4, les boîtes blanches représentent le code utilisateur [1].

49. P a g e | 49
En effet cette figure (FIG 2.7) comprend :
-Un ensemble de service d'implémentation (la moitié inférieure de la
figure) mettant en évidence des services d'infrastructure utiles qui
adressent la gestion d'exécution (GRAM), les données d'accès et de
transfert (GridFTP, RFT, etc).
- Trois quot;containersquot; peuvent être utilisés pour accueillir des services
utilisateur écrits en Java, Python, et C, respectivement. Ces
quot;containersquot; fournissent l'implémentation de sécurité, gestion d'état et
d'autres mécanismes fréquemment requis en établissant des services.
Ils étendent les services open sources avec le soutien d'une gamme de
Services Web(WS), y compris WSRF, WS-Notification et le WS-
Security.
- Un ensemble de bibliothèques qui chargent les programmes
d'utilisateurs en java, C.... Par exemple, dans le cas de GridFTP, il y a
non seulement un client simple (globus-URL-copie) mais également
la bibliothèque de XIO qui est chargée de l'intégration des transports
alternatifs.
- Une infrastructure commune de sécurité et de transmission de
messages permetl'interopérabilité entre différentes applications et
services.
Conclusion
Dans ce chapitre nous avons présenté l'intergiciel Globus, qui est
toujours un projet en constante évolution permettant aux
communautés académiques et industrielles, tel que IBM et Platform
Computing, de créer des produits libres ou commerciaux. Il offre une

50. P a g e | 50
multitude de services et d'outils de haut niveau comme GridFTP,
RFT... qui seront détaillés dans le chapitre qui suit ou nous allons
mettre en place une grille de calcul utilisant le middleware Globus
Toolkit4 comme interface de communication entre les différents
nœuds.

51. P a g e | 51
Chapitre
4
de
Schéma Général de la
grille

52. P a g e | 52
4.1 Réseaux
Au début et comme un premier schéma nous avons utilisé 4
machines qu’on a nommé esclaves puisqu’ils sont des simples PC, et
deux machines maîtres avec la performance décrite au modules
« 4.2 », et voici un schéma qui décrit ce Réseaux:
Fig. 3- Schéma Général d’une Grille de Calcul
4.2 Composantes de la grille
Notre grille comporte deux types de machines :
8 machines esclaves.
•
4 machines maîtres.
•
4.2.1 Machines esclaves
Les machines admettent les caractéristiques techniques suivantes:

53. P a g e | 53
Processeurs:
•
-nombre de processeurs supportés par la carte mère : deux (2).
-nombre de processeurs supportés par la carte mère : deux (2).
-type de processeurs : dual-core 64-bits;
-bus système : 1066 MHz;
-Vitesse d'horloges des processeurs: 2.5 GHz;
-mémoire cache
-level : L1 & L2;
-capacité : 2Mo L2 pour chaque core;
Mémoire :
•
-type de memoire: SDRAM fully buffered DIMM.
-vitesse : 667 MHz;
-capacité mémoire maximale : 16 Gbytes;
-capacité mémoire installée : 16 Gbytes;
Carte Mère:
•
-Bios en mémoire flash;
-bus Système : 1066 MHz;
-ports :

54. P a g e | 54
un (01) port parallèle;
o
deux (02) ports série (clavier & souris)
o
un (01) port COM;
o
huit (08) port USB;
o
un (01) port SCSI;
o
un (01) slot PCI-X libre (64-bits & 133MHz);
o
Disque dur:
•
-type : SATA 2;
-capacité 250Gbytes;
Carte Graphique
•
-Mémoire vidéo installée ; 256 Mo;
Carte Son
•
-son stéréo 16 bits;
Cartes Réseaux :
•
-Carte réseau intégré Ethernet 10/100/100Mbps;
4.2.2 Machines maitres
Les machines admettent les caractéristiques techniques suivantes:
Processeurs:
•
-nombre de processeurs supportés par la carte mère : deux (2).

55. P a g e | 55
-nombre de processeurs supportés par la carte mère : deux (2).
-type de processeurs : Quad-core 64-bits;
-bus système : 1066 MHz;
-Vitesse d'horloges des processeurs: 2.33 GHz;
-mémoire cache
-level : L1 & L2;
-capacité : 2Mo L2 pour chaque core;
Mémoire :
•
-type de memoire: SDRAM fully buffered DIMM.
-vitesse : 667 MHz;
-capacité mémoire maximale : 32 Gbytes;
-capacité mémoire installée : 16 Gbytes;
Carte Mère:
•
-Bios en mémoire flash;
-bus Système : 1066 MHz;
-ports :
un (01) port parallèle;
o
deux (02) ports série (clavier & souris)
o
un (01) port COM;
o

56. P a g e | 56
huit (08) port USB;
o
un (01) port SCSI;
o
un (01) slot PCI-X libre (64-bits & 133MHz);
o
Disque dur:
•
-type : SATA 2;
-capacité 250Gbytes;
Carte Graphique
•
-Mémoire vidéo installée ; 128 Mo;
Carte Son
•
-son stéréo 16 bits;
Cartes Réseaux :
•
-Carte réseau intégrée Ethernet 10/100/100Mbps;

57. P a g e | 57
Chapitre
5
Procédure d'installation
de l'intergiciel Globus
Toolkit 4.0.1
Ce chapitre couvre l'installation de base de l'intergiciel Globus
Toolkit dans sa version 4.0.1 dont le but est d'obtenir un groupe de
stations qui peuvent servir de nœuds pour une grille de calcul en
utilisant un réseau LAN (Local Area Network) et de mettre en relief
l'utilisation pratique des services de cet intergiciel.

58. P a g e | 58
Cette procédure permet aussi d'avoir un nœud qui peut servir
comme autorité de certification ainsi que des Services Web et des
outils qui permettent à des machines extérieures d'accéder aux
ressources après authentification comme utilisateurs autorisés.
Pour chaque étape, des tests sont effectués, tests nécessaires à la
validation de l'installation.
5.1 Préparation à l'installation de l'intergiciel Globus
Toolkit 4.0.1
L'installation de cette plate-forme nécessite l'installation du système
d’exploitation (Linux dans notre cas), du logiciel Globus 4.0.1, et
d'autres logiciels utiles au déploiement et à la réalisation,
principalement quot;Java JDKquot;, quot;Apache Antquot; et quot;PostgresSQLquot;.
L'installation de Globus a posé beaucoup de problèmes, et plusieurs
tentatives d'installation ont dû être faites. Ce logiciel n'est pas une
version commerciale, et il reste à l'usage des universitaires et des
centres de recherche.
La version de Linux utilisée est Scientifique Linux version 5.1 et
version 4 préconisée pour l'installation de Globus.
L'installation de Scientifique Linux fût facile notamment grâce à
l'interface graphique d'installation simple et détaillée et à l'aide en
ligne utilisée par la version 3.
5.1.1 Configuration du réseau

59. P a g e | 59
Lors de l'installation du système Linux, nous avons dû attribuer un
nom et une adresse IP à chaque nœud de la grille pour servir par la
suite à la configuration de l'intergiciel Globus Toolkit 4.0.1.
Remarque : Les noms des différents hôtes doivent avoir tous la forme
suivante : quot;nom_machine.nom_domainequot; qui est une exigence de
l'intergiciel Globus Toolkit.
Dans notre cas, notre grille est configurée de la manière suivante :
Nom de la machine Adresse IP Description
poste1.grid.cnstn 192.168.12.1 Machine client/serveur.
poste2.grid.cnstn 192.168.12.2 Machine client/serveur.
poste3.grid.cnstn 192.168.12.3 Machine client/serveur.
poste4.grid.cnstn 192.168.12.4 Machine client/serveur.
Poste5.grid.cnstn 192.168.12.5 Machine client/serveur.
Poste6.grid.cnstn 192.168.12.6 Machine client/serveur.
Poste7.grid.cnstn 192.168.12.7 Machine client/serveur.
Poste8.grid.cnstn 192.168.12.8 Machine client/serveur.
Metre1.grid.cnstn 192.168.12.81 Machine serveur de certificat, client.
Metre2.grid.cnstn 192.168.12.82 Machine serveur de certificat, client.
Metre3.grid.cnstn 192.168.12.83 Machine serveur de certificat, client.
Machine serveur de certificat, client.
Metre4.grid.cnstn 192.168.12.84
Tab. 3.1 -Tableau des adresses des nœuds de la grille de calcul.

60. P a g e | 60
5.1.2 Installation du système Linux
Il faut suivre la procédure d'installation normale de 'Scientifique
Linux' en faisant attention aux points suivants :
-Type d'installation Poste de Travail (WorkStation).
- Sécurité Pas de pare-feu (Pour ne pas gêner le fonctionnement de
Globus).
- Mot de passe 'root'.
- Personnalisation du jeu de paquetages s'il y a des pilotes
particuliers pour la machine, il faut ajouter les paquetages du noyau.
- Date et Heure doivent être réglées. Ce point est très important, car
si les dates systèmes ne sont pas synchronisées, des problèmes auront
lieu au niveau de la validité des certificats.
5.1.3 Création des comptes utilisateurs
Nous avons besoin de certains utilisateurs : un utilisateur quot;userquot;,
comme utilisateur simple, un utilisateur quot;rootquot; comme administrateur
et quot;Globusquot; qui sera obligatoire sur chaque nœud de la grille et
servira à l'installation de l'intergiciel Globus Toolkit 4.0.1. La création
des utilisateurs se fait lors de l'installation du système Linux ou à
l'aide de commande système quot;adduserquot; (voir Annexe A.I.1.b).
5.1.4 Création des répertoires d'installation
Pour l'installation de l'intergiciel Globus Toolkit et ses outils
nécessaires, nous devons créer deux répertoires sur chaque nœud de
la grille sous le répertoire '/usr/local', un pour les outils et un pour
Globus, puis ajouter les variables d'environnements correspondantes
au fichier '/etc/profile' tel que la variable d'environnement
'$GLOBUS_LOCATION' afin de faciliter le traitement ci après.

61. P a g e | 61
L'utilisateur est libre de choisir le répertoire d'installation à condition
que ce répertoire appartienne à l'utilisateur 'globus'. Une description
détaillée des répertoires est présentée dans l'annexe A.I.2.
5.1.5 Installation des outils nécessaires pour Globus Toolkit
4.0.1
Après l'installation de chaque outil qui se fait à partir d'un répertoire
NFS ou à partir d'un CD ROM, nous devons rajouter les modifications
nécessaires aux fichier '/etc/profile' (voir Annexe A.I.3.c).
- Installation de Apache Ant :
C'est un exécuteur de tâches permettant de compiler et déployer un
programme Java. Il est nécessaire lors du déploiement des services de
grille (voir Annexe A.I.3.a).
-Installation de Java JDK :
C'est un kit de développement nécessaire lors de la compilation du
code de Globus Toolkit 4.0.1 dont une grande partie est écrite en Java
(voir Annexe A.I.3.b).
- Installation de PostgresSQL :
C'est un SGBDR (système de gestion de base de données
relationnelles)qui fonctionne sur des systèmes de type UNIX (par
exemple Linux, FreeBSD, AIX, HP-UX, IRIX, Solaris, ...). C'est un
logiciel libre qui possède de nombreuses caractéristiques faisant de
lui un SGBDR robuste et puissant digne des SGBD :
- de nombreuses interfaces graphiques pour gérer les tables.
-des bibliothèques pour de nombreux langages (appelés frontaux)
afin d'accéder aux enregistrements à partir de programmes écrits en :
Java (JDBC),C/C++ et Perl.

62. P a g e | 62
- une API ODBC permettant à n'importe quelle application
supportant ce type d'interface d'accéder à des bases de données de
type PostgreSQL.
PostgreSQL fonctionne selon une architecture client/serveur, il est
ainsi constitué : d'une partie serveur, c'est-à-dire une application
fonctionnant sur la machine hébergeant la base de données (le
serveur de bases de données) capable de traiter les requêtes des
clients. Il s'agit dans ce cas d'un programme résident en mémoire
appelé « postmaster » et d'une partie client devant être installée sur
les postes clients (un client peut éventuellement fonctionner sur le
serveur lui-même).
Les clients peuvent interroger le serveur de bases de données à l'aide
de requêtes SQL. Une démonstration plus détaillée sur les étapes
d'installation et sur la création des utilisateurs ainsi que leur
communication avec le serveur se trouve dans l'annexe A,
paragraphe V.
- Installation du Globus Toolkit 4.0.1 :
Toolkit
Le code source de Globus est de 82Mo, son installation nécessite 312
Mo, et son déploiement 20 Mo. Le déploiement consiste à garder,
suivant la configuration de la machine (système d'exploitation et type
de processeur), les fichiers qui seront réellement utiles pour faire du
calcul distribué. Il peut supporter les ordonnanceurs suivants : Fork
(utilisé par défaut dans Globus), poe, condor, easymcs, nqe, prun,
loadleveler, lsf, glunix, pexec, et pbs.
L'installation se fait grâce à la commande «./configure » qui permet
de configurer tous les logiciels fournis dans le paquetage Globus,
pour un type d'architecture. Ici, l'architecture est de type quot; i18nquot;,

63. P a g e | 63
pour un PC sous Linux. Le type d'architecture est détecté
automatiquement par Globus (Voir annexe A.II.4).
L'option « -enable-prewsmds » est utilisée pour activer les services
web MDS préexistants dans le paquetage « Globus Toolkit4.0.1 »,
également pour l'option « -enable-drs » qui permet d'activer les
services de réplications de données (Data Replication Service).
Pour la compilation et l'installation, on utilise les commandes 'make'
et « make install ». Suite à ces commandes, l'installation est faite en
respectant l'architecture des répertoires suivants :
-bin : contient les commandes nécessaires pour la communication
bin
dans la grille.
- sbin : Contient les exécutables, utilisés ci-après.
- share : Contient des informations quot; partageables quot; sur le GSI et GIS
de Globus.
- etc : contient des fichiers de configuration.
5.2 Installation de l'Autorité de Certification : SimpleCA
SimpleCA est un paquetage qui fournit une autorité simplifiée de
certification afin de publier des qualifications aux utilisateurs et aux
services Globus Toolkit4, il englobe les fonctionnalités de OpenSSL
CA. Pour l'installer, il faut lancer le script « setupsimpleca » (voir
Annexe A.III.2) qui demande d'entrer le mot de passe général du
certificat. C'est ce dernier qui sera utilisé pour signer tous les
certificats dépendant de cette Autorité de certification et il est le plus
important.
Ce script se charge de créer la structure des répertoires qui
contiennent tous les certificats de l'Autorité de Certification et ses clés
publiques et privées (/home/globus/.globus/simpleCA). Puis il faut

64. P a g e | 64
installer le service GSI qui représente l'infrastructure du service de
sécurité pour Globus Toolkit.
A travers la commande « grid-cert-request –host » (voir Annexe
A.III.3) nous avons obtenu, également avec un mot de passe choisi
par celui qui fait l'installation, une clé privée pour le nœud hôte et
une clé de signature qui servira à signer toutes les clés générées par
l'Autorité de Certification des utilisateurs locaux du nœud en
question (voir Annexe A.III.5 et A.III.6) et des autres nœuds de la
grille.
Maintenant toutes les commandes de « Globus toolkit » sont
utilisables. Cela va per mettre de finir la création des certificats sur
les autres nœuds. Cette étape se fait par l'installation du paquetage
« globus_simple_ca_a2fbda04_setup-0.18.tar.gz » (voir Annexe
A.IV).
Cela génère un script « globus_simple_ca_a2fbda04_setup » qui va
créer un certificat pour les utilisateurs de chaque nœud (voir annexe
A.IV). Après génération des clés propres à chaque nœud, ces
dernières doivent être signées par le nœud ou nous avons installé
l'Autorité de Certification (voir Annexe A.III.5 et A.III.6) par la
commande « grid-ca-sign ».
Après signature des clés privées et publiques générées par l'Autorité
de Certification, nous devons modifier le fichier « grid-mapfile » à
travers la commande « grid-mapfile-addentry », pour tous les
utilisateurs de différents nœuds sur chaque hôte de la grille. Ce
fichier est vu comme un fichier d'autorisation des utilisateurs de la
grille pour accéder aux données sur les nœuds. Notons que les
utilisateurs de chaque nœud doivent s'identifier sur un autre nœud

65. P a g e | 65
par un nom d'utilisateur local du nœud en question (voir annexe
A.III.8).
Pour tester que notre procédure d'authentification et d'autorisation
est bien achevée, nous devons générer un proxy à l'aide de la
commande « grid-proxy-init -debug –verify ».
Cette commande produit une nouvelle paire de clés à partir de
l'identité de l'utilisateur afin d'assurer la procédure d'authentification
et d'autorisation (Voir annexe A.III.9).
Globus est aussi un ensemble de service qui peut être utilisé via
Internet toutefois il y a certaines contraintes à respecter. Tout d'abord
l'authentification des machines réalisée par GSI impose certaines
contraintes :
-Les adresses IP ainsi que les noms des machines doivent être
statiques.
- Les machines doivent communiquer directement, il est impossible
d'utiliser des machines situées sur un réseau privé et qui
communiquent avec d'autres machines.
5.3 Configuration des services de grille de calcul
5.3.1 Configuration du service gridftp
GridFTP est un protocole à rendement élevé, sécurisé, fiable,
permettant le transfert transparent de données. Il est optimisé pour
les réseaux étendus. Le protocole GridFTP est construit au dessus du
protocole FTP standard auquel sont ajoutées d'autres fonctions. Il
utilise le service GSI pour l'identification des utilisateurs.
Ce protocole est déjà installé et il ne nous reste plus qu'à le
configurer. Il faut donc éditer le fichier « /etc/services » et rajouter le

66. P a g e | 66
nom de service, le port et le protocole (voir annexe A.IV.1). Ensuite,
ajouter sous « /etc/inetd.d», le fichier « gridftp » (voir annexe A.IV.1),
puis relancer « init.d » avec la commande « /etc/init.d/xinetd reload ».
La commande 'netstat' sert à tester le bon fonctionnement du service
ainsi que la commande « telnet » (voir annexe A.IV.4).
Enfin pour s'assurer qu'il y a réellement un transfert, après avoir
lancé le proxy et « le serveur gridftp-server » (voir annexe A.IV.),
nous devons tester la commande « globusurlcopy gsiftp » qui
remplace la commande « put » dans le protocole « ftp » (voir annexe
A.IV.4).
5.3.2 Lancement des web containers
Pour administrer les web containers, Java WS englobe deux actions :
une pour le lancement (globus-start-container) et une pour l'arrêt
(globus-stop-container).
Afin de faciliter leur utilisation, nous avons recourt à créer un
exécutable « start-stop » sous « $GLOBUS_LOCATION » (voir Annexe
A.V.1) qui contient plusieurs options utiles telles que :
- « GLOBUS_OPTIONS=quot;-Xms256M -Xmx512M » appelée
« maximum heap size » qui sert à augmenter la mémoire virtuelle
(JVM).
-Le lancement du script « globus-user-env.sh » sous
« $GLOBUS_LOCAT- ION /etc ».
Nous pouvons aussi créer un script « /etc/init.d/globus4.0.1 » qui se
charge de lancer l'exécutable « start-stop ». Notons que les web
containers nécessite une configuration globale spécifiée dans les
fichiers « server-config.wsdd » et « client-serverconfig.wsdd » sous
« $GLOBUS_LOCATION/etc/globus_wsrf_core/ ». Elle consiste à

67. P a g e | 67
ajouter dans la balise « <parameter> » de « <globalConfiguration> »
le nom du hôte et l'adresse IP correspondante.
5.3.3 Configuration du service RFT (Releable File Transfer)
Ce service fournit des interfaces pour contrôler les transferts entre
serveurs GridFTP. Il s'agit d'une réadaptation de l'utilitaire « globus-
url-copy ». Il nécessite le lancement du serveur « postmaster » du
SGBD « Postgresql » en plus du service GridFTP.
Sa configuration consiste à utiliser le processus d'authentification par
lequel le serveur de bases de données établit l'identité du client et
détermine si l'application cliente (ou l'utilisateur sous le nom de
laquelle elle tourne) est autorisée à se connecter sous le nom
d'utilisateur demandé.
Les noms d'utilisateurs PostgreSQL sont séparés de façon logique des
noms d'utilisateurs du système d'exploitation sur lequel tourne le
serveur. Si tous les utilisateurs d'un serveur donné ont aussi des
comptes sur la machine serveur, il peut être pertinent d'attribuer des
noms d'utilisateurs de la base de données qui correspondent aux
noms d'utilisateurs du système d'exploitation. Cependant, un serveur
qui accepte les connexions distantes peut avoir plusieurs utilisateurs
de base de données dépourvus de compte correspondant sur le
système d'exploitation, dans de tels cas il n'y a pas besoin de
correspondance entre noms d'utilisateurs de bases de données et
noms d'utilisateurs du système d'exploitation.
L'authentification du client est contrôlée par le fichier
« pg_hba.conf » situé dans le répertoire data, sous le chemin
« /var/lib/pgsql/data/ pg_hba.conf ».

68. P a g e | 68
Un fichier « pg_hba.conf » par défaut est installé lorsque le répertoire
data est initialisé par la commande « initdb ».
Le format général du fichier « pg_hba.conf » est un ensemble
d'enregitrements, un par ligne. Un enregistrement est constitué d'un
certain nombre de champs séparés par des espaces et/ou des
tabulations. Les champs peuvent contenir des espaces si la va leur du
champ est mise entre guillemets. Chaque enregistrement détermine
un type de connexion, une plage d'adresses IP (si appropriée au type
de connexion), un nom de base de données, un nom d'utilisateur et la
méthode d'authentification à utiliser pour les connexions corresp-
ondants à ces paramètres. Pour la configuration, l'enregistrement
A le format suivant: “host database user IP-adress/IP-mask
authentication-methode[authentication-method]”.
La signification des champs est la suivante :
- host : Cet enregistrement intercepte les tentatives de connexion
utilisant les réseaux TCP/IP qui sont désactivées sauf si le serveur
« postmaster » est lancé avec l'option « -i » ou si le paramètre de
configuration « tcpip_socket » est activé.
- database : Indique quelles bases de données l'enregistrement
concerne.
- user : Indique à quels utilisateurs PostgreSQL cet enregistrement
correspond.
- IP-address/IP-mask : Ces deux champs contiennent les adresses IP
et les masques en notation pointée standard (Les adresses IP ne
peuvent être spécifiées que sous forme numérique, pas sous forme de
noms de domaines ou d'hôtes). Pris séparément, ils spécifient les
adresses IP des machines clientes que cet enregistrement intercepte.

69. P a g e | 69
- authentication-method : Détermine la méthode d'authentification à
utiliser lors d'une connexion via cet enregistrement. Dans notre cas,
c'est la méthode 'MD5' qui demande au client de fournir un mot de
passe crypté MD5 pour son authentification (Voir l'Annexe A.VI).
Pour achever l'installation, nous devons créer un utilisateur de base
« globus » ainsi qu'une base « rftdatabase » pour cet utilisateur. De
plus, le fichier « jndi-con_g.xml » se trouvant sous la direction
« $GLOBUS_LOCATION/etc/globus_wsrf_rft/ » doit contenir le nom
d'utilisateur et le mot de passe. Ainsi une description détaillée se
trouve dans l'annexe A.VI en plus des tests de validation de la
configuration.
5.3.4 Configuration du service GRAM
Comme il permet de lancer des programmes sur des ressources
distantes, sans tenir compte de l'hétérogénéité locale (système
d'exploitation, ordonnanceur), la configuration du service GRAM
consiste en l'édition du fichier « gram_fs_map_con_g.xml » et l'ajout
de deux lignes d'adaptateur local dans le fichier « /etc/sudoers » qui
sont utiles lors de l'exécution des jobs sur différents hôtes et pour que
le programme « globusgridmap-and-execute » s'exécute à travers les
utilisateurs qui se trouvent dans le fichier « grid-mapfile ».
5.4 Soumission des Jobs
Un job est considéré comme une unité simple de travail qui est
typiquement soumis pour l'exécution sur la grille. Il nécessite des
données, produit des sorties, et des conditions d'exécution afin

70. P a g e | 70
d'accomplir sa tâche. Un job simple peut lancer un ou plusieurs
processus sur un nœud indiqué. Il peut exécuter des calculs
complexes sur des grandes quantités de données comme il peut être
relativement simple. Les utilisateurs désirant utiliser la Grille,
doivent, après avoir récupéré un certificat, initier un proxy. Lors
d'une requête de type « job », plusieurs éléments de Globus rentrent
en jeu, comme GRAM et GSI.
5.4.1 Description d'un job
Scénario d'exécution d'un job
La soumission d'un job se fait depuis une interface utilisateur (UI), en
envoyant au courtier de ressources (Ressource Broker RB) un script
JDL (Job Description Langage) ou un script XML avec la version
Globus Toolkit 4 décrivant les caractéristiques du job et ses prés
requis sous forme d'attributs. Ces attributs décrivent les ressources
requises (CPU, mémoire, logiciels..), et les fichiers nécessaires.
Avec ces informations, le courtier de ressources déterminera
l'élément de calcul le plus optimal pour l'exécution (voir FIG 3.1).
Fig. 4.1 -Etape de soumission d'un job.

71. P a g e | 71
Le choix du nœud d'exécution se fera de manière différente suivant
le cas :
1. Soumission directe : Il est possible de spécifier, dans le script JDL
(également le script XML), sur quel nœud doit s'exécuter le job,
auquel cas le courtier des ressources sert seulement à vérifier la
syntaxe du JDL soumis.
2. Soumission sans demande d'accès à des fichiers de la Grille : Dans
ce cas, le courtier des ressources contacte le système d'information et
récupère une liste de nœuds disposant des ressources de calcul
demandées (CPU, mémoire, logiciels), et sur lesquels l'utilisateur a le
droit d'exécuter (informations statiques).Ensuite, il interroge chacun
des nœuds de cette liste pour déterminer le meilleur candidat, selon,
le nombre de CPU et la mémoire libre (informations dynamiques).
3. Soumission avec demande d'accès à des fichiers préalablement
stockés sur la Grille : Dans ce cas, le courtier des ressources doit
d'abord interroger le catalogue de l'Organisation Virtuelle de
l'utilisateur pour savoir où est stockée une copie des fichiers requis
par le job, et établir une liste des nœuds éligibles,

72. P a g e | 72
Fig. 4.2 -Graphe de transition pour un job.
C’est-à-dire proches des données requises et sur lesquels l'utilisateur
est autorisé à exécuter .Une fois le nœud d'exécution choisi, le
courtier des ressources lui soumet le job avec l'information récupérée
et prévient le service de Logging & Bookkeeping (LB). Ce service peut
être interrogé à tout moment par l'utilisateur, pour savoir où est le
job soumis. Lorsque l'exécution commence, les fichiers quot;locauxquot; sont
envoyés avec l'exécutable, et lorsque le LB annonce que le job est
terminé, le nœud renvoie les fichiers de sorties éventuels au courtier
des ressources, qui peuvent être récupérés par l'utilisateur.
Etats et cycle de vie d'un job
Au cours de son cycle de vie, Un job passe par plusieurs états qui sont
(voir FIG 4.2):

73. P a g e | 73
-Unsubmitted : Le job n'est pas encore soumis.
- StageIn : Le job attend que les fichiers exécutables ou d'entrée soit
accomplit.
- Pending : Le job attend son lancement par le scheduler local.
- Active : Le job est en cours d'exécution.
- Suspended : L'exécution de job a été suspendue.
- StageOut : L'exécution de job a accompli ; les sorties sont entrain de
soumission.
- CleanUp : Le job et les sorties ont accompli ; nettoyez des tâches
sont en cours.
- Done : Le job a accompli avec succès.
- Failed : Le job a échoué.
Ainsi un graphe de transition de ces différents états illustre le cycle
de vie d'un job : Un job a unique ID (identificateur) qui peut être
employé dans le service GRAM pour la fiabilité en cas d'erreurs,
c'est-à-dire pour empêcher la duplication accidentelle des
jobs dans des circonstances rares par les nouvelles tentatives de
client. En plus chaque job est détruit juste après sa terminaison
normale, ou après un temps de terminaison (Termination time) qui
est fixé par défaut en cas d'erreur d'exécution.
5.4.2 Exemples de soumission de différents jobs
Globus Toolkit4 supporte le langage XML comme langage de
description du script de job. Les paramètres de ce script ainsi que les
différents exemples de jobs soumis sur notre grille sont bien détaillés
dans l'annexe B. Dans ce qui suit, nous citons juste ces différents
tests.