rapport de stage

Rapport de stage

Mise en place d’une Mise en place d’une Mise en place d’une Mise en place d’une Grille de CalculGrille de CalculGrille de CalculGrille de Calcul

Réalisé par : Bengagi Wajdi

Encadré par : Mr. Mr. Mr. Mr. Moez Ben Hadj Hmida

Mr. Mr. Mr. Mr. Mohamed Mehdi Abbas

Etablissement d’origine : FSMPNT

Juillet-Aout 2008

MINISTÈRE DE L’ENSEIGNEMENT

SUPERIEUR ET DE LA RECHERCHE

SCIENTIFIQUE ET DE LA TECHNOLOGIE

CENTRE NATIONAL DES SCIENCES

ET TECHNOLOGIES NUCLÉAIRES

وزارة التعليم العالي والبحث العلمي والتكنولوجيا

المركز الوطني للعلوم و التكنولوجيا النووية

P a g e | 2

Sommaire

Le plan de ce Rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Liste des tableaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Table des figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Remerciements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1 IntroductionIntroductionIntroductionIntroduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 les grilles de calcul 2 les grilles de calcul 2 les grilles de calcul 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

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

P a g e | 4

2.9.2 Globus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 Globu3 Globu3 Globu3 Globus s s s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 grille4 Schéma Générale du la grille4 Schéma Générale du la grille4 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

P a g e | 5

5 Procédure d'installation5 Procédure d'installation5 Procédure d'installation5 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éraleConclusion généraleConclusion généraleConclusion 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

P a g e | 6

A.1.1 Création d'un utilisateur "Globus" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 "Host Certificates" . . . . 88

A.3.5 Signature du certificat du noeud hôte "Host Certificates" . . . . . . . . . . 88

A.3.6 Signature du certificat de L'utilisateur "Globus" . . . . . . . . . . . . . . . . . . . . 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

P a g e | 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 "pg_hba.conf" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

P a g e | 8

Le plan de ce Rapport

Le rapport est composé de Cinq parties :

Chapitre 1Chapitre 1Chapitre 1Chapitre 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 Chapitre 2 Chapitre 2 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.

CCCChapitre 3hapitre 3hapitre 3hapitre 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 Chapitre 4 Chapitre 4 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 5Chapitre 5Chapitre 5Chapitre 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.

P a g e | 9

Liste des tableaux

2.1 Les principaux services de Globus. . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1 Tableau des adresses des nœuds de la grille de calcul. . . . . . . . . 59

P a g e | 10

Table des figures

1.1 Un scénario de grille de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.2 Architecture d'une grille de calcul en couche. . . . . . . . . . . . . . . 25

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

2.2 Principe du sablier [6]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

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

2.4 Modèle conceptuel de MDS [6]. . . . . . . . . . . . . . . .. . . . .. . . . . . . . 43

2.5 Protocoles de sécurité de GT4 [6]. . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.6 Evolution de Globus [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.7 Schéma de l'architecture GT4, Les boîtes partagées dénotent le

code GT4, les boîtes blanches représentant le code utilisateur [1]. 48

3 Schéma général d’une grille de calcul . . . . . . . . . . . . . . . . . . . . 52

4.1 Etape de soumission d'un job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.2 Graphe de transition pour un job. . . . . . . . . . . . . . . . . . . . . . . . . . 72

B.1 Soumission de job en local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120

B.2 Soumission d'un job sur un nœud distant. . . . . . . . . . . . . . . . . . 122

P a g e | 11

RemerciemeRemerciemeRemerciemeRemerciementsntsntsnts

Nous avons une vive dette de gratitude envers tous ceux qui nous ont

aidés à rassembler les faits qui constituent l'indispensable fondation

de ce travail.

Je tiens à remercier Monsieur Moez Ben Hadj Hmida pour sa

disponibilité et ses prestigieux conseils qui ont été d'une grande aide

dans la réalisation du projet et la rédaction de ce document,

spécialement ses relectures critiques et multiples des différentes

versions du mémoire et les nombreuses suggestions constructives de

sa part.

Je tiens également à remercier Monsieur Mohamed Mehdi Abbas,

pour son aide, et ses idées constructives dans le développement de

cette mémoire.

Enfin, je tiens à remercier tout le personnel du Service informatique

et Réseau de centre national de sciences et technologies nucléaire qui

ont attribué de près ou de loin au bon déroulement de notre stage.

P a g e | 12

ChapitreChapitreChapitreChapitre

1111

IntroductionIntroductionIntroductionIntroduction GénéraleGénéraleGénéraleGénérale

e nos jours, les applications de recherche scientifique utilisent

des données de grandes tailles et nécessitent une puissance de

calcul de plus en plus importante. Initialement ces données étaient

développées sur des infrastructures composées d'un ensemble de

superordinateurs centralisés. Cependant, les besoins scientifiques et

technologiques sont en croissance rapide ce qui requière des

capacités de calcul et de stockage encore plus importantes.

Pour satisfaire ces exigences on a fait recours à des plateformes

hétérogènes partageant des ressources de calcul et de stockage de

plusieurs ordinateurs interconnectés entre eux par un réseau

internet.

P a g e | 13

Ces plateformes utilisées comme ressource unique et unifiée mènent

au concept de "grilles" qui apparaît comme un service public

défendant la notion "d'informatique à la demande".

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 "The

Grid" ou "grille de calcul", 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 "Globus" 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 "Globus".

P a g e | 14


2222

LLLLeeees Grilles de Calculs Grilles de Calculs Grilles de Calculs Grilles de Calcul

a notion de grille de calcul appelée aussi "Grid

Computing" est une passerelle pour un modèle

d'informatique répartie permettant d'exploiter pleinement les

ressources et les capacités offertes vue comme une conséquence

logique des progressions technologiques.

Dans un premier lieu, nous définissons le concept de grille,

présentons ses caractéristiques, ses objectifs ainsi que sa forme et son

architecture.

P a g e | 15

2.1 Définition d'une grille de calcul

Une grille de calcul est dénie comme : "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]".

Ainsi cette définition a été raffinée dans l'article "The Anatomie of the

Grid" écrit par 'Ian Foster', 'C. Kesselman' et 'S. Tuecke' [6] où ils

déclarent la grille de calcul comme étant "une coordination de

ressources partagées, une résolution de problèmes d'organisations

virtuelles, dynamiques et multi-institutionnelles". Le concept

principal se manifeste dans la capacité de négocier le partage des

ressources parmi un ensemble de participants tels que fournisseurs et

consommateurs.

En effet le partage concerné n'est pas principalement l'échange de

dossier mais plutôt l'accès direct aux ordinateurs, logiciels, données,

qui est recommandé dans la résolution des problèmes collaboratifs et

les stratégies d'équilibrage de ressources émergeant dans l'industrie,

la science et la technologie. Ce partage est nécessairement commandé

avec des fournisseurs de ressources et des consommateurs définissant

clairement et soigneusement ce qui est partagé, qui a le droit de

partager, et les conditions dans lesquelles le partage se produit [4].

2.2 Notion d'organisation virtuelle

P a g e | 16

Mettre en œuvre une grille de calcul, c'est vouloir partager des

ressources. Or les différents utilisateurs et les différentes

organisations n'ont ni les mêmes besoins, ni les mêmes

préoccupations ; ils n'utiliseront donc pas nécessairement l'outil de la

même façon. Les données des uns n'intéressent pas forcément les

autres. Chaque domaine a ses propres contraintes de sécurité et fait

appel à des ressources de différentes natures.

Dans la phase de conception d'une grille, chacun des participants

doit être libre de choisir les ressources qu'il souhaite partager et les

conditions qu'il donne à ce partage.

Ainsi, on définit des Organisations Virtuelles qui peuvent prendre la

forme d fournisseurs d'applications, de fournisseurs de données

stockées, mais également de consommateurs de ressources. La durée

de vie des Organisations Virtuelles peut être variable, tout comme

leur composition et les buts qu'elles poursuivent. Ces dernières sont

concrètement des groupes d'utilisateurs qui ont des besoins

communs, des chercheurs d'une même discipline par exemple, ou

des groupes de serveurs mettant à disposition des ressources.

P a g e | 17

2.3 Caractéristiques d'une grille de calcul

La grille de calcul ou 'Grid Computing' reprend les principes

élémentaires du clustering, qui peut être considéré comme l'un des

ancêtres de la grille d'ordinateurs. Mais il est préférable de faire la

distinction entre une grille et un cluster.

Un cluster au sens strict est une grappe de machines homogènes

reliées entre elles à travers un réseau local. A l'opposé, une grille

regroupe un ensemble de machines reliées en réseau, pouvant être

distantes de plusieurs mètres, voire de plusieurs kilomètres (voir FIG

1.1).

P a g e | 18

Une grille de calcul se caractérise par :

-L'hétérogénéité : Une des caractéristiques inhérentes aux grilles de

calcul selon plusieurs points de vue : matériel, logiciel, politiques de

sécurité, contraintes d'exploitation, profil des utilisateurs, etc. Toute

la complexité liée aux différences concernant ces aspects doit être

invisible à l'utilisateur final d'où la nécessité d'un grand effort de

coordination entre tous les sites participant à une grille. Les

contraintes d'exploitation et de qualité de service de chaque site ne

doivent pas être sacrées par leur intégration à une grille. En effet

chaque site doit conserver une totale autonomie concernant ses

politiques d'accès, d'exploitation et d'évolution aussi bien côté

matériel que logiciel, tout en gardant la compatibilité avec les

services offerts à travers la grille [1].

-L'ouverture : La globalisation de ressources suppose un certain

degré d'ouverture des sites vers le monde extérieur. Cette ouverture

peut poser des problèmes auxquels une solution doit être trouvée

sans compromettre la sécurité du site. Un exemple qui illustre bien

ce point concerne l'authentification des utilisateurs. Un des apports

du modèle de grille de calcul est l'accès transparent pour le

chercheur aux ressources informatiques dispersées. En d'autres

termes, il n'est pas tenu de se connecter à une machine appartenant à

un site quelconque pour utiliser les ressources de ce dernier. Une

connexion sur un des sites appartenant à la grille devrait sure pour

lui donner accès aux autres sites de la même grille [3].

-Passage à l'échelle (Scalabilité) : Le nombre des utilisateurs et des

ressources dans une organisation virtuelle est dynamique chose qui

P a g e | 19

requiert l'ajout ou la suppression d'un utilisateur ou d'une ressource

vue comme action habituelle dans le système de grille de calcul. Pour

cette raison, de nouvelles contraintes de sécurité sur les applications

et les algorithmes de gestion de ressources ont eu lieu tel que le

'mapping' des sujets globaux vers des sujets locaux, la centralisation

de l'autorité de certification, le grand nombre d'utilisateurs, etc.

-La tolérance aux pannes : L'ouverture dans une grille de calcul n'est

pas sans risques. Pour tirer partie des ressources disponibles dans

une telle grille, un système d'information de l'état et de la structure

de ces ressources est nécessaire [9]. Il permet la découverte de

ressources utilisables à un moment donné et des relations entre elles

ainsi que l'occurrence de pannes. La publication de ces informations

généralement sensibles d'un point de vue sécurité doit se faire sans

compromettre ni l'intégrité et la sécurité de chaque site ni celles de

l'ensemble des sites partenaires.

2.4 Les objectifs de la grille de calcul

2.4.1 Partage de ressources

Il permet l'accès à la grille pour l'utilisation des ressources distantes

ou pour profiter des logiciels existants. Cette capacité de partage

implique plus qu'un simple transfert de fichiers, il requiert un accès

direct aux logiciels, aux ordinateurs et aux données. Elle peut même

permettre un accès direct à des capteurs, à des télescopes et à d'autres

appareils distants et de les commander.

P a g e | 20

Les ressources sont la propriété de personnes différentes, ce qui

signifie qu'elles relèvent de domaines administratifs différents,

qu'elles exécutent des logiciels différents et qu'elles sont régies par

des politiques de sécurité et de contrôle d'accès, également différentes

[2].

2.4.2 Accès sécurisé

C'est une conséquence directe de la première idée. Le partage de

ressources se traduit par certains problèmes liés à la réalisation de la

grille telle que la politique concernant l'accès, l'authentification et

l'autorisation. En effet, la grille doit être extrêmement souple et

dispose d'un mécanisme de comptabilisation qui sera utilisé pour

décider d'une politique d'établissement des prix d'utilisation de la

grille [2].

2.4.3 Utilisation de ressources

C'est là que la grille commence réellement à être intéressante, même

pour les privilégiés qui disposent d'abondantes ressources

informatiques, car quelle que soit l'abondance de nos ressource, il

arrive toujours un moment où se crée une le d'attente d'utilisateurs

désireux d'en disposer. Un mécanisme d'affectation efficace et

automatique des jobs à différentes ressources permettra la réduction

des fils d'attente [2].

P a g e | 21

2.4.4 Abolition de la distance

Les connexions à haute vitesse entre ordinateurs rendent possible

une grille véritablement mondiale. Grâce à la généralisation de

l'utilisation des fibres optiques dans les systèmes de

télécommunications, doublent environ tous les neuf mois. Certains

grands réseaux fonctionnent maintenant à 155 mégabits par seconde

(Mb/s), alors qu'en 1985 les centres de supercalculateurs des États-

Unis étaient connectés à 56 kilobits par seconde (Kb/s) soit une

amélioration d'un facteur de 3000 en 15 ans. Bien sûr, la distance ne

sera jamais complètement abolie, parce que quelqu'un aura toujours

un problème à traiter sur la grille, pour lequel les connexions les plus

rapides sembleront lentes [2].

2.4.5 Normes ouvertes

Des normes spécifiques à la grille sont en cours d'élaboration par une

entité de normalisation du même genre, le Global Grid Forum.

Fédérant plus de 5000 chercheurs et praticiens individuels, cet

organe représente une force significative en matière d'édiction de

normes et d'élaboration d'éléments permettant le travail en commun.

Actuellement, une norme connue sous le nom OGSA (Architecture

ouverte de services de grille) est considérée comme une référence clé

pour les projets d'élaboration de grilles [2].

P a g e | 22

2.5 Applications des grilles de calcul

Les principales applications des grilles de calcul peuvent être classées

en cinq catégories:

2.5.1 Supercalculateur réparti (Distributed

Supercomputing)

Une grille de calcul pourra agréger une importante quantité de

ressources an de fournir la puissance de calcul nécessaire pour de

nombreuses applications et que même les supercalculateurs les plus

modernes ne peuvent pas fournir.

Selon la nature et l'étendue de la grille, les ressources agrégées

pourront être composés de stations de travail d'une université ou

même de supercalculateurs des organismes de recherche d'un pays.

2.5.2 Calcul haut-débit (High-Throughput Computing)

Une grille de calcul sera utilisée pour ordonnancer en parallèle une

importante quantité de tâches indépendantes les unes des autres.

Comme exemples d'applications nous pouvons citer la recherche de

clés cryptographiques, les simulations de molécules et l'analyse du

génome.

P a g e | 23

2.5.3 Calcul sur demande (On-Demand Computing)

Une grille de calcul pourra fournir les ressources pour satisfaire les

demandes à court terme d'une application que les ressources locales

ne sont pas en mesure d'y assurer (cycles processeur, stockage...). Le

dé principal pour les concepteurs de telles grilles est la nature

dynamique et aléatoire des demandes faites par les utilisateurs qui

peuvent constituer une large population.

2.5.4 Calcul Collaboratif (Collaborative Computing)

Cette classe d'applications inclut les applications d'interaction entre

humains dans des environnements de simulation en temps réel

(conception et interaction avec un nouveau moteur d'avion,

conception d'un plan urbain...).

2.5.5 Génération, traitement et stockage d'énormes quantités

de données (Data intensive Computing)

Dans de telles applications, une grille de calcul pourra absorber et

stocker d'importantes quantités d'information générées. Comme

exemple d'applications nous pouvons mentionner la production

d'une carte de l'univers, la prévision météorologique à long terme, les

simulations quantiques.

P a g e | 24

2.6 Architecture générale d'une grille de calcul

L'architecture de la grille est souvent décrite en termes de "couches",

dont chacune assure une fonction spécifique. D'une façon générale

les "couches hautes" sont axées sur l'utilisateur ("centrées" sur celui-

ci), tandis que les "couches basses" sont plus orientées vers les

ordinateurs et les réseaux ("centrées" sur le matériel)(voir FIG 1.2).

P a g e | 25

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

ressources sur la grille.

Au-dessus de celle-ci, la couche ressources, constituée des

ressources effectives faisant partie de la grille, telles que les

ordinateurs, les systèmes de mémoire, les catalogues de données

électroniques, et mêmes des capteurs, tels que des télescope ou

d'autres instruments qui peuvent être connectés directement au

réseau.

La couche intergicielle assure les fonctions permettant aux divers

éléments (serveurs, mémoires, réseaux, etc.) de participer à un

contexte de grille unifiée. Cette couche intergicielle peut être

considérée comme l'intelligence qui fédère les divers éléments le

"cerveau" de la grille. Parmi les fonctions requises, nous citons :

• Ordonnancement : un ordonnanceur devra trouver la machine

la plus appropriée pour exécuter les tâches qui lui sont

soumises.

• Les ordonnanceurs peuvent aller du plus simple (allocation de

type round-robin) au plus compliqué (ordonnancement à base

de priorités). Les ordonnanceurs réagissent à la charge de la

grille. Ils déterminent le taux de charge de chaque ressource

ande bien ordonnancer les prochaines tâches.

• Ils peuvent être organisés en hiérarchie avec certains

interagissant directement avec les ressources, et d'autres (méta

ordonnanceurs) interagissant avec les ordonnanceurs

intermédiaires. Ils peuvent aussi superviser le déroulement

P a g e | 26

d'une tâche jusqu'à sa terminaison, la soumettre à nouveau si

elle est brusquement interrompue et la terminer

prématurément si elle se trouve dans une boucle infinie

d'exécution.

• Réservation : Il est possible dans les grilles de calcul de réserver

les ressources à l'avance et ceci an de garantir une certaine

qualité de service et de respecter certaines échéances. Pour cela

l'intergiciel devra fournir un système de réservation permettant

aux utilisateurs d'exprimer leurs besoins en ressources et

d'effectuer la réservation.

• Services d'information et d'annuaire : Une grille est un

environnement où le nombre et la charge des ressources sont

dynamiques. Un objectif lors de la conception d'une grille est de

rendre les ressources facilement accessibles à tous les processus.

Il est alors nécessaire de fournir des mécanismes permettant

d'enregistrer et de découvrir ces ressources et d'identifier leur

état tel que le Service de nom. Comme tout système réparti, une

grille devra permettre de référencer ses ressources d'une façon

standard et uniforme.

La couche située au niveau le plus élevé de la structure est la couche

application, qui comprend les diverses applications scientifiques,

techniques, de gestion, financières des utilisateurs, leurs portails,

ainsi que les boîtes à outils de génie logiciel de ces applications. C'est

la couche vue par les utilisateurs de la grille.

Il existe d'autres façons de décrire cette structure en couches. Par

exemple, des spécialistes aiment utiliser le terme " fabrique " pour

P a g e | 27

désigner l'ensemble de l'infrastructure physique de la grille, incluant

les ordinateurs et les réseaux de transmission (en anglais " fabrics ").

Par ailleurs, dans la couche intergiciel se scinder en une couche de

protocoles, de ressources et de connectabilité et, au-dessus de celle-

ci, une couche de services collectifs.

2.7 Types de communication dans une grille de

calcul

2.7.1 Architecture Client/Serveur

Dans les systèmes client/serveur où les données peuvent être

distribuées à travers les serveurs multiples ou centralisés, chacun

avec ses propres administrateurs, des services de sécurité sont

indispensables ainsi que des caches pour éviter la congestion du

réseau.

2.7.2 Architecture Pair à Pair (Peer to Peer)

Une infrastructure de type pair à pair dans une grille de calcul est

généralement constituée d'un ensemble de nœuds dont chacun se

comporte à la fois comme un client et un serveur an de satisfaire les

besoins tel que : partage de fichiers, utilisation du temps CPU

P a g e | 28

inutilisé, collaboration entre équipes, délocalisation des services

fournis par une telle organisation, calculs distribués...

2.7.3 Architecture orientée services

En définissant l'architecture d'une grille de calcul, les concepteurs

peuvent adopter deux approches différentes : se focaliser sur les

ressources ou bien sur les services qu'offrent ces ressources. Dans le

dernier cas l'architecture est dite orientée services. Dans OGSA on

s'intéresse à la notion de service : les ressources de calcul, de

stockage, de communication qui sont présentées comme des services

[6].

Dans une telle architecture, l'interopérabilité (caractéristique

fondamentale d'une grille de calcul) est assurée en standardisant les

interfaces des services de la grille et les protocoles permettant

d'invoquer les opérations de ces interfaces.

Ainsi plusieurs implémentations peuvent correspondre à une même

interface : c'est le principe de la "Virtualisation" des services. Pour

assurer cela, un langage standard est nécessaire pour décrire les

interfaces. Dans le cas d'OGSA le protocole WSDL ("Web Services

Description Langage") est utilisé. WSDL permet de découpler la

définition de l'interface, de l'implémentation et de l'invocation du

service.

P a g e | 29

2.8 Différentes topologies de grilles

Nous répertorions les grilles d'un point de vue topologique en trois

types par ordre croissant d'étendue géographique et de complexité.

2.8.1 Intragrille (en analogie avec Intranet)

La plus simple, composée d'un ensemble relativement simple de

ressources et de services et appartenant à une organisation unique.

Les principales caractéristiques d'une telle grille sont la présence d'un

réseau d'interconnexion, d'un domaine de sécurité unique et d'un

ensemble relativement statique et homogène de ressources.

2.8.2 Extragrille (en analogie avec Extranet)

Une extragrille étend le modèle en agrégeant plusieurs intragrilles.

Les principales caractéristiques d'une telle grille sont la présence d'un

réseau d'interconnexion hétérogène haut et bas débit (LAN / WAN),

de plusieurs domaines de sécurité distincts, et d'un ensemble plus ou

moins dynamique de ressources.

2.8.3 Intergrille (en analogie avec Internet)

Une intergrille consiste à agréger les grilles de multiples

organisations, en une seule grille. Les principales caractéristiques

P a g e | 30

d'une telle grille sont la présence d'un réseau d'interconnexion

hétérogène, de plusieurs domaines de sécurité distincts et ayant

parfois des politiques de sécurité différentes, et d'un ensemble très

dynamique de ressources.

2.9. Les intergiciels de grille de calcul

La grille de calcul est un point focal de toutes ces activités, et permet

d'envisager des projets utilisant des ressources géographiquement

distribuées et partagées par des groupes d'utilisateurs. Parmi ces

projets qui ont acquis plus de maturité au niveau académique nous

citons :

2.9.1 Légion

C'est un système entier, résolument pair à pair, développé à

l'université de Virginie, aux Etats-Unis. Initié dès 1993, le projet a

donné lieu à une première version publique en 1997. Plus qu'un

simple système d'exploitation, Legion est considéré comme un

middleware, ou plus exactement un " méta système ". 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 "voir" que son propre ordinateur, mais fait en

réalité appel à de multiples "ressources" répartis sur le réseau. Legion

est un système orienté objet, et la notion de "ressources" partagées est

P a g e | 31

à comprendre au sens large (librairies, codes sources, fichiers

exécutables...), d'autant que les créateurs du système se flattant du fait

qu'il soit capable de gérer plusieurs milliers de milliards de

ressources, disponibles sur des plates-formes matérielles et logicielles

de toutes natures. Bien sûr, conformément aux principes mêmes du

pair-à-pair, chaque utilisateur peut décider ou non d'ouvrir les

propres ressources de son ordinateur aux autres utilisateurs, et ce de

façon particulièrement fine.

2.9.2 Globus

C'est un projet 'open source' visant à créer les logiciels et les outils

nécessaires pour la conception et la mise en œuvre de grilles de

calcul. Globus est principalement développé aux Etats-Unis dans

l'Argonne National Laboratory par l'équipe d’Ian Foster. Les travaux

sur Globus ont commencé en 1997 et le projet est toujours actif.

Le " Globus Toolkit " est formé d'un ensemble de composants. Son

architecture modulaire permet d'apporter les modifications et les

améliorations d'une manière rapide et efficace. Globus est devenu le

standard 'ipso facto' utilisé dans les projets de grilles de calcul. De

nombreuses entreprises ont ainsi adopté Globus pour servir comme

base de leurs produits commerciaux pour les grilles de calcul.

Dans le prochain chapitre, nous détaillerons les principales

fonctionnalités offertes par Globus à ses utilisateurs en termes de

sécurité, de services d'information, de gestion des communications,

de gestion des ressources et de traitement des données.

P a g e | 32

2.9.2 UNICORE

Il vise à développer des mécanismes permettant un accès sécurisé et

uniforme à des plateformes de calcul de haute performance et leurs

ressources associées [7]. UNICORE se base, sur des outils, des

standards et des mécanismes existants an de fournir les

fonctionnalités demandées. Les objectifs des concepteurs du système

visent à [8] :

• Fournir à l'utilisateur une interface graphique intuitive et facile

à utiliser.

• Fournir des mécanismes de sécurité suffisants.

• Utiliser des technologies sous -jacentes déjà existantes et

approuvées.

• Avoir une architecture basée sur le concept de tâches

génériques ou abstraites.

• Avoir un impact minimal sur les ressources sous-jacentes.

UNICORE est conçu pour supporter une exécution non interactive de

tâches (batch jobs). Ainsi il supporte, à travers l'exploitation de la

nature parallèle des applications, le méta calcul asynchrone (en

contraste avec d'autres systèmes tels que Globus et Légion qui

supportent un modèle de méta calcul synchrone).

P a g e | 33

Conclusion

Les besoins en puissance de calcul pour la recherche scientifique

fondamentale dépassent souvent les possibilités qu'ore la technologie.

Il faut donc inventer constamment de nouvelles solutions pour

permettre à la recherche de disposer d'outils adaptés.

La grille de calcul reprend l'idée qu'une application lourde puisse

être découpée en petites tâches isolées, confiées à des ordinateurs

différents au travers d'un réseau et dont l'aspect économique est

particulièrement séduisant. Dans la suite, nous nous intéresserons à

expliciter un intergiciel de grille de calcul " Globus " an de mettre en

relief les mécanismes de grille ainsi que son objectif.

P a g e | 34


3333

GlobusGlobusGlobusGlobus

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'"Argonne National Laboratory" par l'équipe de 'Ian Foster'. Le projet

Globus a commencé en 1997 et il est toujours actif.

Dans une première partie nous présenterons son but et ses voies de

standardisation, dans la suite de ce chapitre nous allons présenter les

principales fonctionnalités offertes par Globus à ses utilisateurs en

termes de sécurité, de services d'information, de gestion des

communications, de gestion des ressources et de traitement des

P a g e | 35

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

architecture actuelle.

3.1 But de l'intergiciel Globus

Le "Globus Toolkit" 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 " Global Grid Forum " 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'"Open Grid Service Architecture" (OGSA) permet de spécifier les

bases des grilles de calcul. En effet pour avoir un "framework"

largement adopté il faut respecter les définitions des interfaces, des

P a g e | 36

comportements, des modèles de ressource, etc. C'est ce qu'on appelle

la plate-forme OGSA qui repose sur :

-La spécification de l'ensemble des services importants tels que les

applications scientifiques et de commerce électronique.

-L'identification des services de base fondés sur des protocoles et

des langages standards et ouverts comme WSDL (Web Service

Description Langage), SOAP (Simple Object Access Protocol), et XML.

-La spécification à un niveau relativement élevé des

fonctionnalités requises par ces services et les interactions entre elles.

3.2.2 OGSI

En se basant à la fois sur les technologies de grille et les Services

Web, l’OGSI (Open Grid Services Infrastructure) définie les

mécanismes de création, de gestion et d'échange d'informations entre

les services de grille. Cet échange comprend la découverte des

services déjà créés et leur utilisation qui permet une gestion des

services sur le long terme tout en étant sécurisé et résistant aux

pannes.

3.3 Les services de Globus

Globus fournit les fonctionnalités et les services de base nécessaires à

la construction de grille de calcul tel que la sécurité, la gestion des

ressources, la communication. Il est composé d'un ensemble de

modules ayant chacun une interface permettant aux services de

niveau supérieur d'invoquer ses mécanismes.

P a g e | 37

-Localisation et allocation des ressources : ce composant permet aux

applications d'exprimer leurs besoins en fournissant les mécanismes

d'identification des ressources adéquates.

-Communication : ce composant permet aux différentes applications

de communiquer entre elles selon plusieurs modes : communication

par message, mémoire distribuée, appel de procédure à distance, etc.

-Information sur les ressources : permet d'obtenir des informations

sur l'état et la structure globale du système.

-Mécanismes de sécurité : ce composant fournit les mécanismes

d'authentification et d'autorisation des utilisateurs.

-Création et lancement des processus : permet de préparer

l'environnement de lancement et d'exécution d'un processus.

- Accès aux données : Accès performant et consistant aux données

stockées dans les fichiers et les bases de données.

La table ci-dessous (TAB 2.1) montre les différents services offerts

par Globus qui peuvent être organisés en trois pyramides construites

sur une base commune : le composant de sécurité (GSI), sur laquelle

reposent la gestion des ressources (GRAM), les mécanismes de

communication (Nexus) et les services d'information(MDS)(voir FIG

2.1).

Services nom Description

Gestion des ressources GRAM Allocation des ressources et gestion des processus.

Communication Nexus Services de communication unicast et multicast.

Sécurité GSI Authentification et autorisation.

Information MDS Information sur la structure et l'état de la grille.

Tab. 2.1 - Les principaux services de Globus.

P a g e | 38

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

Fig. 2.2 -Principe du sablier [6].

3.3.1 Gestion de ressources

Elle est assurée par le service GRAM "Globus Ressource Allocation

Manager" qui permet la gestion et la supervision des ressources.

P a g e | 39

Vue la multitude de services de bas niveau utilisés, le service GRAM

masque les différentes technologies de gestion de ressources de bas

niveau. Ainsi les différents services de haut niveau n'ont à se

préoccuper que de l'interfaçage avec GRAM.

Chaque entité GRAM est responsable d'un ensemble de ressources

opérant selon une politique commune et spécifique au site dans

lequel elles se trouvent. Cette dernière est souvent implémentée par

un ordonnanceur tel que 'Fork', 'Condor' ou 'LSF' "Load Sharing

Facility ". 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 "Ressource Spécification

Langage". 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 ("Resource Brokers"). Un exemple

d'architecture telle que définie dans la figure 2.2, sera détaillée dans

le chapitre IV.

3.3.2 Gestion de communications Les services de communications entre processus dans Globus sont

assurés par la librairie de communication Nexus. Le choix de cette

librairie est adopté pour deux raisons :

-la première est que Nexus supporte plusieurs outils de

développement parallèles et de calcul distribués tel que MPI

(Message Parssing Interface) , le deuxième est qu'il est conçu pour

P a g e | 40

supporter des méthodes de communication co-existantes et de créer

des processus concurrents.

Le principe de l'architecture de Nexus est similaire à celui de GRAM :

fournir une API unifiée aux services de haut niveau (MPI, RPC,

CORBA...) tout en s'interfaçant avec une multitude de services de bas

niveau (TCP, UDP...). Les services de communication de Nexus sont

utilisés extensivement dans l'implémentation des autres services de

Globus. Les besoins des applications varient de la communication

fiable par messages à la communication multipoint non fiable. Les

protocoles IP et TCP ne sont pas en mesure de répondre à ces besoins.

Nexus est alors utilisé pour combler ce manque.

Les communications dans Nexus sont définies en employant deux

abstractions : les liens de communication ("Communication Links") et

les requêtes de service distant ("Remote Service Request" ou RSR).

Un lien de communication est formé par l'association d'une source

("startpoint") et d'une destination ("endpoint"). Une opération de

communication est initiée en appliquant une requête de service

distant à une source.

Cet appel de procédure asynchrone permet de transférer des données

de la source vers toutes les destinations auxquelles elle est reliée.

Plusieurs sources peuvent être associées à une destination et vice

versa ce qui permet de construire des structures de communication

complexes illustrés par la figure ci-dessous (FIG 2.3).

Les liens de communication dans Nexus peuvent être transposés sur

différentes méthodes de communication sous-jacentes chacune ayant

ses propres caractéristiques : protocole utilisé, sécurité, qualité de

service. En associant un attribut à un lien de communication entre

une source et une destination, une application peut contrôler la

P a g e | 41

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

Méthode de communication employée.

3.3.3 Service d'information

Globus offre le composant "Metacomputing Directory Service" 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 "Lightweight Directory Access

Protocol" comme base pour la représentation et l'accès aux données.

Plus spécifiquement, il est constitué des modules suivants :

-"Grid Resource Information Service"(GRIS) : Les serveurs GRIS

peuvent se trouver dans plusieurs endroits dans une grille et

contiennent toute information concernant les machines qui y sont

enregistrées. L'architecture de GRIS permet d'étendre facilement la

nature des informations qu'ils peuvent contenir. Un serveur GRIS ne

contient jamais les informations concernant toutes les machines

d'une grille pour ne pas charger le serveur.

P a g e | 42

-"Grid Index Information Service"(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 ("Information Provider") : Ce composant

assure la traduction des informations concernant les ressources selon

le schéma de MDS.

- Client MDS : Ce composant permet d'interroger MDS pour obtenir

des informations concernant une ressource.

P a g e | 43

La figure ci-dessous montre le modèle conceptuel de MDS (voir FIG

2.4).

Fig. 2.4 -Modèle conceptuel de MDS [6].

3.3.4 Service de sécurité

Notion de sécuritéNotion de sécuritéNotion de sécuritéNotion de sécurité

P a g e | 44

Elle est assurée par une architecture de sécurité complexe pour un

bon fonctionnement de grille appelée GSI (Grid Security

Infrastructure) qui permet de garantir les trois propriétés nécessaires

pour sécuriser un système d'information notant : la confidentialité,

l'intégrité et la disponibilité de l'information.

En effet, Globus repose sur la cryptographie à clé publique. Ainsi

pour utiliser les mécanismes de sécurité de GSI, il faut créer une

paire de clés (publique/privé) et demander la délivrance d'un

certificat numérique (certificat X.509) d'une autorité de certification

(AC) pour chaque nœud de la grille. A la fin, pour chaque nœud on a

trois fichiers contenant respectivement la clé publique de l'AC, la clé

privée du nœud et le certificat numérique du nœud.

Le fichier contenant la clé privée du nœud est particulièrement

sécurisé et ne disposant que de droit de lecture par son propriétaire

pour ne pas y permettre un accès illicite par des utilisateurs non

autorisés. De plus la clé privée n'est fonctionnelle qu'avec

l'introduction d'un mot de passe par l'utilisateur, cela permet

d'introduire une couche de sécurité supplémentaire.

Authentification et autorisationAuthentification et autorisationAuthentification et autorisationAuthentification et autorisation

A cause de l'environnement hétérogène et géographique étendu des

grilles de calcul, l’authentification des machines et des utilisateurs est

un point important. En effet, il faut établir une relation de confiance

entre les différents nœuds de la grille malgré les politiques de

sécurité qui peuvent varier entre les organisations.

Pour cela GSI offre un mécanisme d'authentification mutuelle et

d'autorisation qui utilise les protocoles SSL/TLS comme base.

P a g e | 45

Principe d'échange des cléPrincipe d'échange des cléPrincipe d'échange des cléPrincipe d'échange des clés dans Globuss dans Globuss dans Globuss dans Globus : Globus assure la procédure

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.

Délégation et Single SignDélégation et Single SignDélégation et Single SignDélégation et Single Sign----OnOnOnOn

Si chaque lancement d'une tâche nécessite le mot de passe utilisateur,

alors un nombre important de tâches ou un appel récursif de ces

dernières rend la demande de mots de passe impraticable. La création

d'un Proxy est une solution offerte par le GSI comme mécanisme de

délégation permettant de diminuer au maximum le nombre de fois

ou l'utilisateur fournit son mot de passe. Ce mécanisme de délégation

P a g e | 46

est une extension des mécanismes de SSL. Ainsi un utilisateur

authentifié par un nœud peut créer un Proxy, ce dernier lui délègue

son autorité. Un Proxy consiste en un nouveau certificat numérique

avec une nouvelle paire de clés publique/privée. Il contient l'identité

de l'utilisateur légèrement modifiée.

Fig. 2.5 - protocoles de sécurité de GT4 [6].

Ce certificat est signé par l'utilisateur lui-même et non pas par

l'Autorité de Certification. De plus un Proxy a une durée de vie

limitée. Il est alors utilisé pour assurer la procédure

d'authentification mutuelle et d'autorisation sans avoir à impliquer à

l'utilisateur.

La figure 2.5 ci-dessus présente l'architecture de service de sécurité

et résume les différents protocoles offerts par Globus, exemple

Globus Toolkit 4 (GT4).

Communications chiffréesCommunications chiffréesCommunications chiffréesCommunications chiffrées

Le service GSI ne prévoit pas une procédure de chiffrement

prédéfinie entre les nœuds pour ne pas surcharger les échanges.

Mais puisque il utilise SSL comme système sous-jacent, la procédure

P a g e | 47

de création d'une clé secrète commune entre deux nœuds est

possible. Cette clé sera utilisée par un algorithme de chiffrement tel

que DES pour chiffrer les échanges. D'autre coté GSI assure par

défaut L'intégrité des données.

3.4 Evolution et architecture de l'intergiciel Globus

Comme tout projet open source, toujours actif, Globus a subit

plusieurs stades d'évolution. Ces étapes sont les résultats de la

migration de certains composants d'une

Fig. 2.6 - Evolution de Globus [1].

version à une autre et de l'ajout de nouveaux composants.

La convergence vers la notion de Services Web dans la grille de

calcul est l'ambitieux objectif que se donne Globus. Ainsi le schéma

ci-dessus (FIG 2.6) explique cette évolution en fonction de l'échelle

de temps.

La version1 de Globus Toolkit était juste une définition ou métaphase

de services GRAM et MDS. Globus Toolkit2 est venu avec l'ajout du

P a g e | 48

service GridFTP, RFT et l'intégration des paquetages de kits "Grid

Packaging Toolkit" (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 "Web Services

Resource FrameWork" (WSRF) qui sont des services web incluant les

services de grilles. Des nouveaux composants sont aussi ajoutés

comme exemple "C WS-Core", ainsi les codes sources des

bibliothèques des Services Web sont écrit en C et C++ bien qu'elles

étaient uniquement en java dans la version Globus Toolkit3.

Voici une présentation de l'architecture générale de Globus Toolkit

dans sa dernière version et illustrant ses différents composants :

Fig. 2.7 -Schéma de l'architecture GT4, Les boîtes partagées dénotent

le code GT4, les boîtes blanches représentent le code utilisateur [1].

P a g e | 49

En effet cette figure (FIG 2.7) comprend :

-Un ensemble de service d'implémentation (la moitié inférieure de la

figure) mettant en évidence des services d'infrastructure utiles qui

adressent la gestion d'exécution (GRAM), les données d'accès et de

transfert (GridFTP, RFT, etc).

- Trois "containers" peuvent être utilisés pour accueillir des services

utilisateur écrits en Java, Python, et C, respectivement. Ces

"containers" fournissent l'implémentation de sécurité, gestion d'état et

d'autres mécanismes fréquemment requis en établissant des services.

Ils étendent les services open sources avec le soutien d'une gamme de

Services Web(WS), y compris WSRF, WS-Notification et le WS-

Security.

- Un ensemble de bibliothèques qui chargent les programmes

d'utilisateurs en java, C.... Par exemple, dans le cas de GridFTP, il y a

non seulement un client simple (globus-URL-copie) mais également

la bibliothèque de XIO qui est chargée de l'intégration des transports

alternatifs.

- Une infrastructure commune de sécurité et de transmission de

messages permetl'interopérabilité entre différentes applications et

services.

Conclusion

Dans ce chapitre nous avons présenté l'intergiciel Globus, qui est

toujours un projet en constante évolution permettant aux

communautés académiques et industrielles, tel que IBM et Platform

Computing, de créer des produits libres ou commerciaux. Il offre une

P a g e | 50

multitude de services et d'outils de haut niveau comme GridFTP,

RFT... qui seront détaillés dans le chapitre qui suit ou nous allons

mettre en place une grille de calcul utilisant le middleware Globus

Toolkit4 comme interface de communication entre les différents

nœuds.

P a g e | 51


4444

Schéma Général dSchéma Général dSchéma Général dSchéma Général deeee la la la la

grillegrillegrillegrille

P a g e | 52

4.1 4.1 4.1 4.1 RéseauxRéseauxRéseauxRé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 4.2 4.2 4.2 ComposantesComposantesComposantesComposantes de la grillede la grillede la grillede la grille

Notre grille comporte deux types de machines :

• 8 machines esclaves.

• 4 machines maîtres.

4.2.1 Machines esclaves

Les machines admettent les caractéristiques techniques suivantes:

P a g e | 53

• Processeurs: Processeurs: Processeurs: Processeurs:

-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émoireMémoireMémoireMé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: Carte Mère: Carte Mère: Carte Mère:

-Bios en mémoire flash;

-bus Système : 1066 MHz;

-ports :

P a g e | 54

o 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);

• Disque dur:Disque dur:Disque dur:Disque dur:

-type : SATA 2;

-capacité 250Gbytes;

• Carte GraphiqueCarte GraphiqueCarte GraphiqueCarte Graphique

-Mémoire vidéo installée ; 256 Mo;

• Carte SonCarte SonCarte SonCarte Son

-son stéréo 16 bits;

• Cartes Réseaux :Cartes Réseaux :Cartes Réseaux :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: Processeurs: Processeurs: Processeurs:


P a g e | 55


-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émoireMémoireMémoireMé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: Carte Mère: Carte Mère: Carte Mère:

-Bios en mémoire flash;

-bus Système : 1066 MHz;

-ports :

o un (01) port parallèle;

o deux (02) ports série (clavier & souris)

o un (01) port COM;

P a g e | 56

o huit (08) port USB;

o un (01) port SCSI;

o un (01) slot PCI-X libre (64-bits & 133MHz);

• Disque dur:Disque dur:Disque dur:Disque dur:

-type : SATA 2;

-capacité 250Gbytes;

• Carte GraphiqueCarte GraphiqueCarte GraphiqueCarte Graphique

-Mémoire vidéo installée ; 128 Mo;

• Carte SonCarte SonCarte SonCarte Son

-son stéréo 16 bits;

• Cartes Réseaux :Cartes Réseaux :Cartes Réseaux :Cartes Réseaux :

-Carte réseau intégrée Ethernet 10/100/100Mbps;

P a g e | 57


5555

Procédure d'installationProcédure d'installationProcédure d'installationProcédure d'installation

de l'intergiciel Globus de l'intergiciel Globus de l'intergiciel Globus de l'intergiciel Globus

Toolkit 4.0.1Toolkit 4.0.1Toolkit 4.0.1Toolkit 4.0.1

Ce chapitre couvre l'installation de base de l'intergiciel Globus

Toolkit dans sa version 4.0.1 dont le but est d'obtenir un groupe de

stations qui peuvent servir de nœuds pour une grille de calcul en

utilisant un réseau LAN (Local Area Network) et de mettre en relief

l'utilisation pratique des services de cet intergiciel.

P a g e | 58

Cette procédure permet aussi d'avoir un nœud qui peut servir

comme autorité de certification ainsi que des Services Web et des

outils qui permettent à des machines extérieures d'accéder aux

ressources après authentification comme utilisateurs autorisés.

Pour chaque étape, des tests sont effectués, tests nécessaires à la

validation de l'installation.

5.1 Préparation à l'installation de l'intergiciel Globus

Toolkit 4.0.1

L'installation de cette plate-forme nécessite l'installation du système

d’exploitation (Linux dans notre cas), du logiciel Globus 4.0.1, et

d'autres logiciels utiles au déploiement et à la réalisation,

principalement "Java JDK", "Apache Ant" et "PostgresSQL".

L'installation de Globus a posé beaucoup de problèmes, et plusieurs

tentatives d'installation ont dû être faites. Ce logiciel n'est pas une

version commerciale, et il reste à l'usage des universitaires et des

centres de recherche.

La version de Linux utilisée est Scientifique Linux version 5.1 et

version 4 préconisée pour l'installation de Globus.

L'installation de Scientifique Linux fût facile notamment grâce à

l'interface graphique d'installation simple et détaillée et à l'aide en

ligne utilisée par la version 3.

5.1.1 Configuration du réseau

P a g e | 59

Lors de l'installation du système Linux, nous avons dû attribuer un

nom et une adresse IP à chaque nœud de la grille pour servir par la

suite à la configuration de l'intergiciel Globus Toolkit 4.0.1.

Remarque : Les noms des différents hôtes doivent avoir tous la forme

suivante : "nom_machine.nom_domaine" 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 machineNom de la machineNom de la machineNom de la machine Adresse IPAdresse IPAdresse IPAdresse IP DescriptionDescriptionDescriptionDescription

poste1.grid.cnstn 192.168.12.1 Machine client/serveur.




Poste5.grid.cnstn 192.168.12.5 Machine client/serveur.




Metre1.grid.cnstn 192.168.12.81 Machine serveur de certificat, client.




Tab. 3.1 -Tableau des adresses des nœuds de la grille de calcul.

P a g e | 60

5.1.2 Installation du système Linux

Il faut suivre la procédure d'installation normale de 'Scientifique

Linux' en faisant attention aux points suivants :

-Type d'installation Poste de Travail (WorkStation).

- Sécurité Pas de pare-feu (Pour ne pas gêner le fonctionnement de

Globus).

- Mot de passe 'root'.

- Personnalisation du jeu de paquetages s'il y a des pilotes

particuliers pour la machine, il faut ajouter les paquetages du noyau.

- Date et Heure doivent être réglées. Ce point est très important, car

si les dates systèmes ne sont pas synchronisées, des problèmes auront

lieu au niveau de la validité des certificats.

5.1.3 Création des comptes utilisateurs

Nous avons besoin de certains utilisateurs : un utilisateur "user",

comme utilisateur simple, un utilisateur "root" comme administrateur

et "Globus" 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 "adduser" (voir Annexe A.I.1.b).

5.1.4 Création des répertoires d'installation

Pour l'installation de l'intergiciel Globus Toolkit et ses outils

nécessaires, nous devons créer deux répertoires sur chaque nœud de

la grille sous le répertoire '/usr/local', un pour les outils et un pour

Globus, puis ajouter les variables d'environnements correspondantes

au fichier '/etc/profile' tel que la variable d'environnement

'$GLOBUS_LOCATION' afin de faciliter le traitement ci après.

P a g e | 61

L'utilisateur est libre de choisir le répertoire d'installation à condition

que ce répertoire appartienne à l'utilisateur 'globus'. Une description

détaillée des répertoires est présentée dans l'annexe A.I.2.

5.1.5 Installation des outils nécessaires pour Globus Toolkit

4.0.1

Après l'installation de chaque outil qui se fait à partir d'un répertoire

NFS ou à partir d'un CD ROM, nous devons rajouter les modifications

nécessaires aux fichier '/etc/profile' (voir Annexe A.I.3.c).

---- Installation de Apache Ant :Installation de Apache Ant :Installation de Apache Ant :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 :Installation de Java JDK :Installation de Java JDK :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 :Installation de PostgresSQL :Installation de PostgresSQL :Installation de PostgresSQL :

C'est un SGBDR (système de gestion de base de données

relationnelles)qui fonctionne sur des systèmes de type UNIX (par

exemple Linux, FreeBSD, AIX, HP-UX, IRIX, Solaris, ...). C'est un

logiciel libre qui possède de nombreuses caractéristiques faisant de

lui un SGBDR robuste et puissant digne des SGBD :

- de nombreuses interfaces graphiques pour gérer les tables.

-des bibliothèques pour de nombreux langages (appelés frontaux)

afin d'accéder aux enregistrements à partir de programmes écrits en :

Java (JDBC),C/C++ et Perl.

P a g e | 62

- une API ODBC permettant à n'importe quelle application

supportant ce type d'interface d'accéder à des bases de données de

type PostgreSQL.

PostgreSQL fonctionne selon une architecture client/serveur, il est

ainsi constitué : d'une partie serveur, c'est-à-dire une application

fonctionnant sur la machine hébergeant la base de données (le

serveur de bases de données) capable de traiter les requêtes des

clients. Il s'agit dans ce cas d'un programme résident en mémoire

appelé « postmaster » et d'une partie client devant être installée sur

les postes clients (un client peut éventuellement fonctionner sur le

serveur lui-même).

Les clients peuvent interroger le serveur de bases de données à l'aide

de requêtes SQL. Une démonstration plus détaillée sur les étapes

d'installation et sur la création des utilisateurs ainsi que leur

communication avec le serveur se trouve dans l'annexe A,

paragraphe V.

---- Installation du Globus TooInstallation du Globus TooInstallation du Globus TooInstallation du Globus Toolkit 4.0.1 :lkit 4.0.1 :lkit 4.0.1 :lkit 4.0.1 :

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 " i18n",

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 :

-binbinbinbin : contient les commandes nécessaires pour la communication

dans la grille.

- sbinsbinsbinsbin : Contient les exécutables, utilisés ci-après.

- shareshareshareshare : Contient des informations " partageables " sur le GSI et GIS

de Globus.

- etcetcetcetc : contient des fichiers de configuration.

5.2 Installation de l'Autorité de Certification : SimpleCA

SimpleCA est un paquetage qui fournit une autorité simplifiée de

certification afin de publier des qualifications aux utilisateurs et aux

services Globus Toolkit4, il englobe les fonctionnalités de OpenSSL

CA. Pour l'installer, il faut lancer le script « setupsimpleca » (voir

Annexe A.III.2) qui demande d'entrer le mot de passe général du

certificat. C'est ce dernier qui sera utilisé pour signer tous les

certificats dépendant de cette Autorité de certification et il est le plus

important.

Ce script se charge de créer la structure des répertoires qui

contiennent tous les certificats de l'Autorité de Certification et ses clés

publiques et privées (/home/globus/.globus/simpleCA). Puis il faut

P a g e | 64

installer le service GSI qui représente l'infrastructure du service de

sécurité pour Globus Toolkit.

A travers la commande « grid-cert-request –host » (voir Annexe

A.III.3) nous avons obtenu, également avec un mot de passe choisi

par celui qui fait l'installation, une clé privée pour le nœud hôte et

une clé de signature qui servira à signer toutes les clés générées par

l'Autorité de Certification des utilisateurs locaux du nœud en

question (voir Annexe A.III.5 et A.III.6) et des autres nœuds de la

grille.

Maintenant toutes les commandes de « Globus toolkit » sont

utilisables. Cela va per mettre de finir la création des certificats sur

les autres nœuds. Cette étape se fait par l'installation du paquetage

« globus_simple_ca_a2fbda04_setup-0.18.tar.gz » (voir Annexe

A.IV).

Cela génère un script « globus_simple_ca_a2fbda04_setup » qui va

créer un certificat pour les utilisateurs de chaque nœud (voir annexe

A.IV). Après génération des clés propres à chaque nœud, ces

dernières doivent être signées par le nœud ou nous avons installé

l'Autorité de Certification (voir Annexe A.III.5 et A.III.6) par la

commande « grid-ca-sign ».

Après signature des clés privées et publiques générées par l'Autorité

de Certification, nous devons modifier le fichier « grid-mapfile » à

travers la commande « grid-mapfile-addentry », pour tous les

utilisateurs de différents nœuds sur chaque hôte de la grille. Ce

fichier est vu comme un fichier d'autorisation des utilisateurs de la

grille pour accéder aux données sur les nœuds. Notons que les

utilisateurs de chaque nœud doivent s'identifier sur un autre nœud

P a g e | 65

par un nom d'utilisateur local du nœud en question (voir annexe

A.III.8).

Pour tester que notre procédure d'authentification et d'autorisation

est bien achevée, nous devons générer un proxy à l'aide de la

commande « grid-proxy-init -debug –verify ».

Cette commande produit une nouvelle paire de clés à partir de

l'identité de l'utilisateur afin d'assurer la procédure d'authentification

et d'autorisation (Voir annexe A.III.9).

Globus est aussi un ensemble de service qui peut être utilisé via

Internet toutefois il y a certaines contraintes à respecter. Tout d'abord

l'authentification des machines réalisée par GSI impose certaines

contraintes :

-Les adresses IP ainsi que les noms des machines doivent être

statiques.

- Les machines doivent communiquer directement, il est impossible

d'utiliser des machines situées sur un réseau privé et qui

communiquent avec d'autres machines.

5.3 Configuration des services de grille de calcul

5.3.1 Configuration du service gridftp

GridFTP est un protocole à rendement élevé, sécurisé, fiable,

permettant le transfert transparent de données. Il est optimisé pour

les réseaux étendus. Le protocole GridFTP est construit au dessus du

protocole FTP standard auquel sont ajoutées d'autres fonctions. Il

utilise le service GSI pour l'identification des utilisateurs.

Ce protocole est déjà installé et il ne nous reste plus qu'à le

configurer. Il faut donc éditer le fichier « /etc/services » et rajouter le

P a g e | 66

nom de service, le port et le protocole (voir annexe A.IV.1). Ensuite,

ajouter sous « /etc/inetd.d», le fichier « gridftp » (voir annexe A.IV.1),

puis relancer « init.d » avec la commande « /etc/init.d/xinetd reload ».

La commande 'netstat' sert à tester le bon fonctionnement du service

ainsi que la commande « telnet » (voir annexe A.IV.4).

Enfin pour s'assurer qu'il y a réellement un transfert, après avoir

lancé le proxy et « le serveur gridftp-server » (voir annexe A.IV.),

nous devons tester la commande « globusurlcopy gsiftp » qui

remplace la commande « put » dans le protocole « ftp » (voir annexe

A.IV.4).

5.3.2 Lancement des web containers

Pour administrer les web containers, Java WS englobe deux actions :

une pour le lancement (globus-start-container) et une pour l'arrêt

(globus-stop-container).

Afin de faciliter leur utilisation, nous avons recourt à créer un

exécutable « start-stop » sous « $GLOBUS_LOCATION » (voir Annexe

A.V.1) qui contient plusieurs options utiles telles que :

- « GLOBUS_OPTIONS="-Xms256M -Xmx512M » appelée

« maximum heap size » qui sert à augmenter la mémoire virtuelle

(JVM).

-Le lancement du script « globus-user-env.sh » sous

« $GLOBUS_LOCAT- ION /etc ».

Nous pouvons aussi créer un script « /etc/init.d/globus4.0.1 » qui se

charge de lancer l'exécutable « start-stop ». Notons que les web

containers nécessite une configuration globale spécifiée dans les

fichiers « server-config.wsdd » et « client-serverconfig.wsdd » sous

« $GLOBUS_LOCATION/etc/globus_wsrf_core/ ». Elle consiste à

P a g e | 67

ajouter dans la balise « <parameter> » de « <globalConfiguration> »

le nom du hôte et l'adresse IP correspondante.

5.3.3 Configuration du service RFT (Releable File Transfer)

Ce service fournit des interfaces pour contrôler les transferts entre

serveurs GridFTP. Il s'agit d'une réadaptation de l'utilitaire « globus-

url-copy ». Il nécessite le lancement du serveur « postmaster » du

SGBD « Postgresql » en plus du service GridFTP.

Sa configuration consiste à utiliser le processus d'authentification par

lequel le serveur de bases de données établit l'identité du client et

détermine si l'application cliente (ou l'utilisateur sous le nom de

laquelle elle tourne) est autorisée à se connecter sous le nom

d'utilisateur demandé.

Les noms d'utilisateurs PostgreSQL sont séparés de façon logique des

noms d'utilisateurs du système d'exploitation sur lequel tourne le

serveur. Si tous les utilisateurs d'un serveur donné ont aussi des

comptes sur la machine serveur, il peut être pertinent d'attribuer des

noms d'utilisateurs de la base de données qui correspondent aux

noms d'utilisateurs du système d'exploitation. Cependant, un serveur

qui accepte les connexions distantes peut avoir plusieurs utilisateurs

de base de données dépourvus de compte correspondant sur le

système d'exploitation, dans de tels cas il n'y a pas besoin de

correspondance entre noms d'utilisateurs de bases de données et

noms d'utilisateurs du système d'exploitation.

L'authentification du client est contrôlée par le fichier

« pg_hba.conf » situé dans le répertoire data, sous le chemin

« /var/lib/pgsql/data/ pg_hba.conf ».

P a g e | 68

Un fichier « pg_hba.conf » par défaut est installé lorsque le répertoire

data est initialisé par la commande « initdb ».

Le format général du fichier « pg_hba.conf » est un ensemble

d'enregitrements, un par ligne. Un enregistrement est constitué d'un

certain nombre de champs séparés par des espaces et/ou des

tabulations. Les champs peuvent contenir des espaces si la va leur du

champ est mise entre guillemets. Chaque enregistrement détermine

un type de connexion, une plage d'adresses IP (si appropriée au type

de connexion), un nom de base de données, un nom d'utilisateur et la

méthode d'authentification à utiliser pour les connexions corresp-

ondants à ces paramètres. Pour la configuration, l'enregistrement

A le format suivant: “host database user IP-adress/IP-mask

authentication-methode[authentication-method]”.

La signification des champs est la suivante :

- host : Cet enregistrement intercepte les tentatives de connexion

utilisant les réseaux TCP/IP qui sont désactivées sauf si le serveur

« postmaster » est lancé avec l'option « -i » ou si le paramètre de

configuration « tcpip_socket » est activé.

- database : Indique quelles bases de données l'enregistrement

concerne.

- user : Indique à quels utilisateurs PostgreSQL cet enregistrement

correspond.

- IP-address/IP-mask : Ces deux champs contiennent les adresses IP

et les masques en notation pointée standard (Les adresses IP ne

peuvent être spécifiées que sous forme numérique, pas sous forme de

noms de domaines ou d'hôtes). Pris séparément, ils spécifient les

adresses IP des machines clientes que cet enregistrement intercepte.

P a g e | 69

- authentication-method : Détermine la méthode d'authentification à

utiliser lors d'une connexion via cet enregistrement. Dans notre cas,

c'est la méthode 'MD5' qui demande au client de fournir un mot de

passe crypté MD5 pour son authentification (Voir l'Annexe A.VI).

Pour achever l'installation, nous devons créer un utilisateur de base

« globus » ainsi qu'une base « rftdatabase » pour cet utilisateur. De

plus, le fichier « jndi-con_g.xml » se trouvant sous la direction

« $GLOBUS_LOCATION/etc/globus_wsrf_rft/ » doit contenir le nom

d'utilisateur et le mot de passe. Ainsi une description détaillée se

trouve dans l'annexe A.VI en plus des tests de validation de la

configuration.

5.3.4 Configuration du service GRAM

Comme il permet de lancer des programmes sur des ressources

distantes, sans tenir compte de l'hétérogénéité locale (système

d'exploitation, ordonnanceur), la configuration du service GRAM

consiste en l'édition du fichier « gram_fs_map_con_g.xml » et l'ajout

de deux lignes d'adaptateur local dans le fichier « /etc/sudoers » qui

sont utiles lors de l'exécution des jobs sur différents hôtes et pour que

le programme « globusgridmap-and-execute » s'exécute à travers les

utilisateurs qui se trouvent dans le fichier « grid-mapfile ».

5.4 Soumission des Jobs

Un job est considéré comme une unité simple de travail qui est

typiquement soumis pour l'exécution sur la grille. Il nécessite des

données, produit des sorties, et des conditions d'exécution afin

P a g e | 70

d'accomplir sa tâche. Un job simple peut lancer un ou plusieurs

processus sur un nœud indiqué. Il peut exécuter des calculs

complexes sur des grandes quantités de données comme il peut être

relativement simple. Les utilisateurs désirant utiliser la Grille,

doivent, après avoir récupéré un certificat, initier un proxy. Lors

d'une requête de type « job », plusieurs éléments de Globus rentrent

en jeu, comme GRAM et GSI.

5.4.1 Description d'un job

Scénario d'exécution d'un jobScénario d'exécution d'un jobScénario d'exécution d'un jobScénario d'exécution d'un job

La soumission d'un job se fait depuis une interface utilisateur (UI), en

envoyant au courtier de ressources (Ressource Broker RB) un script

JDL (Job Description Langage) ou un script XML avec la version

Globus Toolkit 4 décrivant les caractéristiques du job et ses prés

requis sous forme d'attributs. Ces attributs décrivent les ressources

requises (CPU, mémoire, logiciels..), et les fichiers nécessaires.

Avec ces informations, le courtier de ressources déterminera

l'élément de calcul le plus optimal pour l'exécution (voir FIG 3.1).

Fig. 4.1 -Etape de soumission d'un job.

P a g e | 71

Le choix du nœud d'exécution se fera de manière différente suivant

le cas :

1. Soumission directe1. Soumission directe1. Soumission directe1. 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 Grille2. Soumission sans demande d'accès à des fichiers de la Grille2. Soumission sans demande d'accès à des fichiers de la Grille2. 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 3. Soumission avec demande d'accès à des fichiers préalablement 3. Soumission avec demande d'accès à des fichiers préalablement 3. Soumission avec demande d'accès à des fichiers préalablement

stockésstockésstockésstockés sur la Grillesur la Grillesur la Grillesur la Grille : Dans ce cas, le courtier des ressources doit

d'abord interroger le catalogue de l'Organisation Virtuelle de

l'utilisateur pour savoir où est stockée une copie des fichiers requis

par le job, et établir une liste des nœuds éligibles,

P a g e | 72

Fig. 4.2 -Graphe de transition pour un job.

C’est-à-dire proches des données requises et sur lesquels l'utilisateur

est autorisé à exécuter .Une fois le nœud d'exécution choisi, le

courtier des ressources lui soumet le job avec l'information récupérée

et prévient le service de Logging & Bookkeeping (LB). Ce service peut

être interrogé à tout moment par l'utilisateur, pour savoir où est le

job soumis. Lorsque l'exécution commence, les fichiers "locaux" 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 jobEtats et cycle de vie d'un jobEtats et cycle de vie d'un jobEtats et cycle de vie d'un job

Au cours de son cycle de vie, Un job passe par plusieurs états qui sont

(voir FIG 4.2):

P a g e | 73

-Unsubmitted : Le job n'est pas encore soumis.

- StageIn : Le job attend que les fichiers exécutables ou d'entrée soit

accomplit.

- Pending : Le job attend son lancement par le scheduler local.

- Active : Le job est en cours d'exécution.

- Suspended : L'exécution de job a été suspendue.

- StageOut : L'exécution de job a accompli ; les sorties sont entrain de

soumission.

- CleanUp : Le job et les sorties ont accompli ; nettoyez des tâches

sont en cours.

- Done : Le job a accompli avec succès.

- Failed : Le job a échoué.

Ainsi un graphe de transition de ces différents états illustre le cycle

de vie d'un job : Un job a unique ID (identificateur) qui peut être

employé dans le service GRAM pour la fiabilité en cas d'erreurs,

c'est-à-dire pour empêcher la duplication accidentelle des

jobs dans des circonstances rares par les nouvelles tentatives de

client. En plus chaque job est détruit juste après sa terminaison

normale, ou après un temps de terminaison (Termination time) qui

est fixé par défaut en cas d'erreur d'exécution.

5.4.2 Exemples de soumission de différents jobs

Globus Toolkit4 supporte le langage XML comme langage de

description du script de job. Les paramètres de ce script ainsi que les

différents exemples de jobs soumis sur notre grille sont bien détaillés

dans l'annexe B. Dans ce qui suit, nous citons juste ces différents

tests.

P a g e | 74

1. Soumission d'un job simple : Le premier test consiste à vérifier si

le service GRAM est bien installé, la commande « globusrun-

ws » est ainsi utilisée une première fois avec l'option -c pour

exécuter la commande shell « /bin/touch » et une deuxième fois

en ajoutant l'option « -F » pour exécuter le même script sur une

machine distante (voir annexe B.II.test1 et annexe B.II.test2).

D'autres tests sont aussi faits comme les jobs à plusieurs

arguments et les jobs permettant de récupérer les résultats dans

des fichiers de sorties (voir annexe B.II.test4 et annexe

B.II.test5).

2. Soumission des jobs sur des nœuds distants : Ces tests sont basés

sur le service de transfert de fichiers (gsiftp) que ce soient le

fichier exécutable, les fichiers d'entrer ou les fichiers de

récupération de données ainsi différents scénarios sont alors

faits (voir annexe B.III., annexe B.IV.1).

3. Soumission des jobs multiples : le multi job consiste à lancer des

différents jobs en même temps sur le même site ou sur des sites

distants (voir annexe B.III.2 et annexe B.IV.5 et annexe B.IV.6).

L'exemple 7 dans l'annexe B.IV illustre un flux de données entre

divers sites, le fichier de sortie de l'un est argument d'entrée

pour l'autre, tout en gardant une exécution parallèle de ces

jobs.

Conclusion

Une grille de calcul est ainsi installée convenablement pour

permettre aux utilisateurs d'exploiter les ressources de Globus Toolkit

4.0.1. A travers les différents tests de soumission de jobs, nous avons

P a g e | 75

réussit à mettre en relief les objectifs en question ainsi que le

déploiement de la grille en utilisant ses services.

P a g e | 76

Conclusion GénéraleConclusion GénéraleConclusion GénéraleConclusion Générale A partir d'un cadre de calcul distribué et à travers les concepts et

principes théoriques des grilles de calculs, ce travail avait pour

objectif de faire une évaluation théorique des notions et concepts du

domaine. Suite à cette évaluation, l'environnement Globus Toolkit

4.0.1 a été choisi, pour des tests pratiques.

En effet, avec son architecture en couche et son adaptation à

l'infrastructure OGSI pour la définition des services de grille

composant l'architecture « Open Grid Service Architecture (OGSA) »,

le middleware Globus était le mieux adapté aux contraintes posées.

Afin de permettre le développement et l'exécution des services de

grille, GT4 propose des solutions tel que l'utilisation des mécanismes

comme WSDL qui intègre les possibilités de composition de services

exploitées par la spécification OGSI ainsi que les mécanismes de

sécurité de la couche application basé sur le standard XML et les

services Web.

Cependant, une fois initié à ses concepts et ses API, GT4 permet un

gain de temps considérable pour le développement d'un service de

grille, ainsi que pour le développement des outils clients permettant

de l'utiliser grâce à la standardisation d'une partie des interfaces et

des comportements des services.

La plupart des facilités offertes par cette infrastructure aux services

respectant cet ensemble de conventions ont également un intérêt

certain en dehors d'un contexte de grille et permettent de construire

assez facilement tout un groupe de Services Web avec des

P a g e | 77

fonctionnalités évoluées de notification, de sécurité, de gestion du

cycle de vie, etc.

Dans cette mémoire, nous avons présenté un retour d'expérience sur

la mise en place d'une grille de calcul et le développement de

Services de grille illustré par la résolution des difficultés rencontrées.

Malgré le temps nécessaire pour être opérationnel sur l'utilisation de

cette technologie, lié à son immaturité, nous sommes convaincues du

rôle fondamental d’OGSI dans la construction des infrastructures

informatiques autour des grilles.

A travers ce projet nous avons senti les responsabilités que devait

avoir un ingénieur face à des défis problématiques liés aux diverses

technologies adoptées. Ce sujet n'était pas simple au départ, car il fait

appel à de nombreuses technologies récentes en informatique.

Ce mémoire a été une expérience très intéressante et valorisante dans

le domaine des grilles de calcul qui ont un avenir prometteur.

Perspectives :Perspectives :Perspectives :Perspectives : Notre projet est une suite logique du développement de l'Internet, et

du WEB d'où :

-La nécessité des tentatives d'interopérabilité de middleware de

Grille.

- La volonté d'étendre l'accès aux grilles à travers des terminaux

mobiles.

- Le besoin d'étendre (encore) les middlewares de Grille.

- Le besoin d'une adoption industrielle plus large telle que la

tolérance aux pannes et le respect des contraintes de temps.

P a g e | 78

Bibliographie [1] http :// www.globus.org.

[2] http :// www.gridcafe.org.

[3] Sophie NICOUD Fabio HERNANDEZ, Nicolas JACQ. Datagrid.

[4] Ian Foster. What is the grid ? ? a three point checklist. GRIDSTART

Technical Newsletter, March 2003.

[5] C. Kesselman I. Foster and S. Tuecke. The grid : Blueprint for a future

computing infrastructure. San Francisco, 1999.

[6] C. Kesselman I. Foster and S. Tuecke. The anatomy of the grid : Enabling

Scalable virtual rganizations. Int.l J. Supercomputer Applications, 2001.

[7] D. Snelling J. Almond. Unicore : secure and uniform access to distributed

resources via the www, October 1998.

[8] M. Romberg. The unicore architecture-seamless access to distributed

resources.

In Proceedings of the Eight IEEE International Symposium on High

performance Computing, pages 287-293, Redondo Beach, CA, USA, August

1999.

[9] C. Kesselman G. von Laszewski W. Smith S. Tuecke S. Fitzgerald, I. Foster. A

directory service for con_guring high-performance distributed

computations. In Proc. 6th IEEE Symp. On High-Performance Distributed

Computing, pages 365-375, 1997.

P a g e | 79

Annexe AAnnexe AAnnexe AAnnexe A

Procédure d'installation d'une Procédure d'installation d'une Procédure d'installation d'une Procédure d'installation d'une

grille de calculgrille de calculgrille de calculgrille de calcul

A.1 Préparation à l'installation de A.1 Préparation à l'installation de A.1 Préparation à l'installation de A.1 Préparation à l'installation de GlobusGlobusGlobusGlobus ToolkitToolkitToolkitToolkit

4.0.14.0.14.0.14.0.1

A.1.1 Création d'un utilisateur "Globus"

Description de l'utilisateur "Description de l'utilisateur "Description de l'utilisateur "Description de l'utilisateur "GlobusGlobusGlobusGlobus" :" :" :" :

C'est un utilisateur non privilégié qui est utile à l'administration de la

grille tel que le lancement et l'arrêt du "container", le déploiement des

services, etc.

Procédure :Procédure :Procédure :Procédure :

La création de l'utilisateur se fait soit :

- Automatiquement lors de l'installation du système Linux (dans

notre cas c'est le système Scientific Linux 5.1).

- En créant notre utilisateur en mode texte avec la commande

adduser.

Comme "root" :Comme "root" :Comme "root" :Comme "root" :

P a g e | 80

- En mode graphique, en choisissant dans le menu :

A.1.2 Création d'un répertoire d'installation de Globus

Toolkit 4.0.1 : Pour le faire, nous choisissons le chemin d'installation désiré (dans

notre cas c'est : '/usr/local') puis comme root, on exécute :

A.1.3 Installation des outils nécessaires pour Globus

Toolkit4.0.1 :

Installation d’Apache-ant :

C'est un exécuteur de tâches permettant de compiler et déployer un

programme. En effet, Ant, comme une solution libre basée sur XML, a

P a g e | 81

l'avantage de reposer sur un fichier XML comme descripteur de

tâches et d'avoir Java comme garant de la portabilité. Il suffit de

télécharger la version adéquate d’apache-ant et la placer dans un

répertoire au choix.

Dans notre cas, nous avons installé « apache-ant-1.6.5.bin » dans

« /usr/local ». L'installation consiste à exécuté le script apache-ant-

1.6.5.bin qui est nous avons déjà copié dans le répertoire

d’installation.

Exemple : En tant que En tant que En tant que En tant que """"root"root"root"root" faire :faire :faire :faire :

Installation de JDK : -Présentation : Le Java Development Kit, communément appelé JDK,

est le kit de développement de base que propose gratuitement la

firme Sun Microsystem. Le Kit de développement comprend plusieurs

outils, parmi lesquels :

- javac : le compilateur Java.

- java : un interpréteur d'applications (machine virtuelle).

- applet viewer : un interpréteur d'applets.

- jdb : un débogueur.

- javap : un décompilateur, pour revenir du bytecode au code

source.

- javadoc : un générateur de documentation.

- jar : un archive de classes Java.

- Installation : De même, on télécharge la dernière version de jdk qui

est « jdk1_5_06.bin » et on la place sous le répertoire où on veut

l'installer (dans notre cas c'est '/usr/local') puis on exécute la

commande d'installation.

P a g e | 82

Exemple : Comme root, on faitComme root, on faitComme root, on faitComme root, on fait ::::

La licence s'affiche, après validation nous obtenons les fichiers JDK

dans le répertoire « jdk1_5_0_06» sous « /usr/local ».

Configuration du fichier 'profile' sous '/etc' :Configuration du fichier 'profile' sous '/etc' :Configuration du fichier 'profile' sous '/etc' :Configuration du fichier 'profile' sous '/etc' :

Il s'agit d'ajouter à la variable "path" le chemin de jdk et ant puis

exporter les variables d'environnement dans '/etc/profile'.

Exemple : Comme root, on fait :Comme root, on fait :Comme root, on fait :Comme root, on fait :

Remarque : Avant l'installation de Globus Toolkit, il faut s'assurer que

le fichier exécutable du compilateur « javac » sous « /usr/bin »

n'existe pas, sinon le compilateur java utilisé sera celui sous

« /usr/bin » et non le compilateur de la version « 1.5.0.06 ».

A.2 Installation de Globus toolkit 4.0.1 : L'installation de Globus Toolkit 4.0.1 doit être faite en tant

qu'utilisateur Globus, pour cela il faut changer de session ou

directement par la commande schell suivante :

P a g e | 83

Ensuite, après téléchargement du fichier 'gt4.0.1-x86_fc_3-binary-

installer.tar.gz' et son placement dans l'endroit désiré (dans notre cas

c'est : /Installation/Outils), nous commencons l'installation de globus

toolkit qui consiste à :

1. Extraire les fichiers compressés dans le fichier

'gt4.0.1-x86_fc_3-binary-installer.tar.gz' avec la commande:

2. Copier le fichier décompressé dans le répertoire d'installation

de globus toolkit4.0.1 comme suit :

4. Se placer sous le répertoire d'installation :

5. Lancer l'installation :

Le résultat obtenu est :

Puis :

P a g e | 84

Enfin :

A.3 Installation de l'Autorité de Certification : AC

A.3.1 Création des utilisateurs

Il faut s'assurer que la machine contient les deux comptes utilisateurs

suivants : Un compte utilisateur pour l'exécution des programmes

clients et un compte Globus utilisé comme administrateur, il est

nécessaire pour le démarrage et l'arrêt du "container", le déploiement

des Web Services ainsi que la gestion de l'AC. Nous allons créer notre

propre AC par l'outil fourni par GT4 qui est "Simple CA".

RemarRemarRemarRemarque :que :que :que :

Il faut s'assurer que l'utilisateur Globus a les droits d'écriture et de

lecture dans le répertoire '$GLOBUS_LOCATION'.

P a g e | 85

A.3.2 Exécution du script d'installation :

Ce script est placé lors de l'installation de Globus Toulkit4.0.1 pour

l'exécution de « SimpleCA » qui est installée uniquement dans une

seule machine pour une même grille.

RemarqueRemarqueRemarqueRemarque ::::

- L'installation doit se faire par l'utilisateur « globus », sinon on aura

notre « simpleCA » installé sous « /root » : « /root/.globus/simpleCA ».

- Avant de lancer l'installation, il faut s'assurer que le nom de la

machine est bien écrit dans le fichier « /etc/hosts » avec l'adresse IP

correspondante.

Exemple : Exemple : Exemple : Exemple : Voici le contenu du fichier "hosts" d'une machine de notre

grille :

Comme globus, nous créons le répertoire « /etc/grid-security » puis

on lance les commandes suivantes :

Le résultat est :

P a g e | 86

Puis si notre sujet de l'AC est bien conforme au nom de hôte, nous

pouvons confirmer l'exécution en tapant " y " devant le message qui

s'affiche :

Puis nous entrons l'email de l'administrateur de l'AC :

Ensuite le nombre de jours de validité de notre certificat, par défaut si

nous tapons "entrer " la durée sera de 5 ans.

Puis la phrase de passe du certificat, qui sera utilisée par la suite

comme clé cryptographique générée par l'algorithme RSA.

P a g e | 87

A.3.3 Installation du service GSI :

Nous Lançons la commande suivante :

Comme Comme Comme Comme «««« rootrootrootroot »»»» ::::

P a g e | 88

Nous obtenons comme résultat :

A.3.4 Demande de certificat pour un nœud hôte "Host

Certificates" :

Il suffit de lancer la commande suivante :

Suite à cette commande, il y aura génération de trois fichiers :

hostkey.pem qui contient la clé du nœud hôte, hostcert_request.pem

qui contient la clé de signature et un fichier vide (empty)

hostcert.pem qui va contenir la signature du nœud hôte.

A.3.5 Signature du certificat du noeud hôte "Host

Certificates":

Remarque :Remarque :Remarque :Remarque :

La commande doit être lancé sous « /home/globus/.globus », sinon

elle génère l'erreur suivante car le fichier se trouve sous

« /home/globus /.globus ».

Donc sous « /home/globus/.globus », nous exécutons la commande

suivante:

P a g e | 89


Le fichier hostsigned.pem est inexistant mais il sera créé lors du

lancement de la commande et contiendra la signature de l’hôte.


Après l'écriture de la clé, le résultat sera :

Puis nous plaçons le fichier signé dans le fichier sous le nom

hostcert.pem :

A.3.6 Signature du certificat de l'utilisateur "globus" :

Avec la commande suivante :


P a g e | 90

Après génération du fichier 'usercert_request.pem ' nous devons le

signer :


P a g e | 91

A.3.7 Signature du certificat de l'utilisateur 'user1':

Pour cela puisque le fichier « usercert_request » est propriétaire a

« user1 » alors en va le copier dans le fichier « /tmp » puis en change

le propriétaire de ce fichier en mode « root » en tapant :

Puis en signe le fichier 'usercert_request.pem ' par l’utilisateur

« globus» en tapant :


Puis, nous plaçons le fichier signé en mode « root » dans le fichier

usercert.pem qui est vide puis en change le propriétaire de ce fichier

à l’utilisateur « user1 » :

P a g e | 92

A.3.8 Création du certificat du 'container' :

Il est utile pour le lancement des Services Web :

Le résultat final est :

A.3.9 Ajout des autorisations :

L'ajout des autorisations se fait par la création du fichier « grid-

mapfile » qui garantie la communication sécurisée entre les

différents nœuds de la grille :

P a g e | 93

Ajout du « sujet globus » dans le fichier « grid-mapfile » :

Le résultat souhaité est :

Ajout du « sujet user1» dans le fichier « grid-mapfile » :

Le résultat est :

A.3.10 Vérification du certificat de l'utilisateur « globus» :


Il faut entrer le mot de passe utilisé lors de la signature de

l'utilisateur « globus ».


P a g e | 94

A.3.11 Vérification du certificat de « user1 » :


Il faut entrer le mot de passe utilisé lors de la signature de

l'utilisateur 'user.


A.4 Installation de certificat pour plusieurs machines :

Pour chaque machine autre que celle où nous avons installé le

certificat, nous procédons de la manière suivante :

Nous copions le fichier « globus_simple_ca_a2fbda04_setup-

0.18.tar.gz » qui se trouve sous : « /home/globus/.globus/simpleCA/ »

dans la deuxième machine sous « /home/globus/ » puis nous lançons

la commande suivante :

Nous obtenons :

P a g e | 95

Puis:

P a g e | 96

P a g e | 97


Cet avertissement (warning) s'affiche car nous n'avons pas encore

installé le service "GRAM". Ensuite, nous installons le service « setup-

gsi » :

Nous obtenons le résultat suivant :


Avant de lancer la commande suivante, il faut mettre à jours le

fichier « /etc/hosts » en ajoutant ces trois lignes :

Puis, nous lançons la commande d'authentification de l’hôte :

Exemple :Exemple :Exemple :Exemple :

P a g e | 98


Si l'installation est réussite, nous obtenons les fichiers suivants :

Puis en passe a l’étape de signature de ce clé

P a g e | 99

Dans cette étape nous faisant la même opération faite pour la 1ère

machine, alors en va copier le fichier « hostcert_request » dans la

machine nommé « poste4 » puis nous faisant la signature de cette clé

par l’utilisateur « globus ». (Voir paragraphe A.3.5).

Puis, nous lançons la commande d'authentification de l'utilisateur

dont le nom est « name » :


1) L'ajout d'un utilisateur d'une machine sur une autre distante est

traduit par une nouvelle entrée dans le fichier « gridmap-file » de la

machine distante avec le 'sujet' de la machine utilisateur et le

nom d'un utilisateur de la machine distante, sinon son accès

sera refusé.

2) après la génération de clé de l’utilisateur dont le nom est « name »

en doit signé cette clé par l’utilisateur « globus » de la

machine « poste4 » pour cela en va copier cette clé dans cette

machine puis ne répétons les opérations réalisé dans le paragraphe

« A.3.7 jusqu'à A.3.9 »

A.5 Installation de postgresql-8.3.3.2

P a g e | 100

Après téléchargement du paquetage « postgresql-8.3.3.2.bin » sous

« /home/user/local », nous commençons l'installation :

Comme Comme Comme Comme «««« rootrootrootroot »»»» ::::

A.5.1 Configuration de postgresql :

Ensuite, en définie le port de l’application :

P a g e | 101

Et puis le langage procédural utilisé :

En définie le moteur de stockage par default :

P a g e | 102

Ensuite, nous ajoutons un utilisateur « postgres » et nous créons les

répertoires « pgsql/data »:

Puis en se lance la confirmation :

P a g e | 103

Enfin :

Et enfin nous lançons le serveur de base de données.

Nous créons une base de données pour vérifier si la base est bien

installée :

P a g e | 104

Si toute marche bien, nous aurons :

A.6 Installation du service « gridFTP » :

A.6.1 Configuration :

-Configuration du service « gridftp » sous « xinetd/inetd » :

-le résultat de cette commande sera :

P a g e | 105

Remarque :Remarque :Remarque :Remarque : « inetd » et « xinetd » sont équivalents.

-Chargement du service « xinetd »:

- Mise à jour du fichier 'services' :

-Voir l'état du service « gsiftp » avec la commande « netstat » :

P a g e | 106

- Création du fichier « gridftp.conf » sous « /etc/grid-security » :

- copie du fichier « gridftp.conf » sous « $GLOBUS_LOCATION/etc »:

A.6.2 Lancement du proxy :

P a g e | 107

A.6.3 Test du service « gsiftp »

-Le premier test se fait avec la commande « telnet »:

Remarque :Remarque :Remarque :Remarque : Le numéro 220 indique que le service « gsiftp » est bien

configuré, sinon il faut s'assurer de l'existence du fichier

« gridftp.conf » sous « /etc/grid-security » et sous

« $GLOBUS_LOCATION/etc ».

-Si le paquetage « globus_ftp_client_test » est bien installé,

l'exécution du script « TEST.pl » vérifie le bon fonctionnement de

notre plateforme.

P a g e | 108

A.6.4 Lancement du serveur 'gridftp'

- Coté serveur (front end)

-Coté client (data-node)

-Exemple :

-Transfert de données :

La "machine A" est la machine source : c'est la machine sur laquelle le

serveur « gridftp » est installé (front end), cette machine doit contenir

le certificat.

---- ExemplesExemplesExemplesExemples

Exemple1 : Copie sur la même machine.

Il s'agit de copier le fichier « /etc/group » du nœud

« poste4.grid.cnstn » dans le fichier « /tmp/globus.test.copy » qui se

trouve sur le nœud « poste4.grid.cnstn ». La commande « diff » nous

permet de comparer le contenu des deux fichiers.

P a g e | 109

Exemple 2 :

Un transfert du fichier « /etc/group » du nœud distant

« poste3.grid.cnstn » vers un fichier « /tmp/globus » sur le nœud

« poste4.grid.cnstn ».

A.6.5 Erreurs

- L'option -c oblige le serveur « gridftp » de prendre les variables du

fichier « gridftp.conf » comme paramètre de configuration alors il

faut bien s'assurer que le numéro de port entré n'est pas déjà utilisé

par un autre service.

- Cette même erreur peut aussi apparaître comme résultat de la

commande :

P a g e | 110

Dans notre cas, le port 2811 est configuré pour le service « gsiftp »

(voir le script du fichier services) et c'est normal d'avoir l'erreur

« Address already in use ».

A.7 Lancement des Services Web

A.7.1 Création d'un exécutable pour le lancement des Services

Web

Nous créons un fichier contenant le script suivant :

Ensuite, nous rajoutons le droit d'exécution du fichier :

P a g e | 111

Comme « root », nous créons sous « /etc/init.d » un script qui exécute

le programme « start-stop » :

De même, nous autorisons l'exécution du fichier :

Puis nous lançons le Web Container :

Pour voir s'il y a erreur dans le lancement du web container, nous

pouvons consulter le fichier « container.log » :

P a g e | 112

P a g e | 113


- Le message d'erreur affiché est du à une configuration manquante

de la base de donnée relative au service « RFT ».

-Dans certains cas tels que la mauvaise configuration du fichier

« /etc/hosts », les Services Web peuvent être lancés avec l'adresse de

boucle locale « 127.0.0.0 » et non par l’adresse IP du nœud. Pour

régler ce problème, nous modifions les fichiers suivants :

Puis nous ajoutons la ligne suivante dans la balise

<globalConfiguration>.

Et aussi le fichier client :

Puis de la même façon, on ajoute :

A.8 Configuration de RFT :

A.8.1 Création du fichier "pg_hba.conf" :

P a g e | 114

Comme « root », nous créons les répertoires suivants :

Puis :

Ensuite, nous insérons la ligne suivante :

A.8.2 Création d'un utilisateur de la base 'postgres' :

Après lancement du serveur du SGBD « postgres », nous créons une

base de données « test » :

Maintenant, nous créons notre utilisateur « globus » :

Le résultat est :

P a g e | 115

A.8.3 Création de la base « rftDatabase » :

Comme utilisateur « globus », nous créons la base de données :

Puis nous produisons le schéma de la base qui permet de créer les

tables nécessaires de la base ainsi que leurs index :

Le résultat est :

A.8.4 Test du fonctionnement de RFT :

- Test1 :

Le résultat est :

P a g e | 116

-Test2:

Le résultat est :

P a g e | 117

A.9 Installation du service GRAM

A.9.1 Edition du fichier « sudoers » :

-Le fichier « sudoers » détermine la liste des utilisateurs que

l'utilisateur globus peut affecter pour être, ainsi ces derniers

prennent les droits du super utilisateur. Par exemple si nous voulons

courir des applications de client au-dessous de trois utilisateurs, nous

ajouterons tous au dossier de « sudoers ». Dans notre cas « griduser »

et « testuser » sont deux utilisateurs locaux de « poste4.grid.cnstn » :

P a g e | 118

A.9.2 Edition du fichier 'globus_gram_fs_map_con_g.xml'

-Le fichier« $GLOBUS_LOCATION/etc/gramservice/globus_gram_

fs_map_con_g.xml » contient l'information d'association des direct-

eurs de ressource locaux aux serveurs de « GridFTP ». Le service

« GRAM » utilise le serveur « GridFTP » (par l'intermédiaire de RFT)

pour exécuter toutes les directives du fichier.

P a g e | 119

P a g e | 120

Annexe BAnnexe BAnnexe BAnnexe B

Exécutions de jobs sur la grilleExécutions de jobs sur la grilleExécutions de jobs sur la grilleExécutions de jobs sur la grille

B.1 Syntaxe 'RSl' de description de jobs - <executableexecutableexecutableexecutable> : l'exécutable concerné par le job.

- <direcdirecdirecdirectorytorytorytory> : répertoire de l'exécutable.

- <argumentargumentargumentargument> : sous forme de mot, nombre ou phrase, il est

facultatif dans le code

du job et dépend de la nature de l'exécutable.

-<environementenvironementenvironementenvironement> : permet de définir des couples <name> +<value>

correspondant

à la définition d'une variable d'environnement.

- <stdoutstdoutstdoutstdout> : chemin du fichier résultat.

- <stdinstdinstdinstdin> : chemin du fichier source.

- <stderrstderrstderrstderr> : sortie d'erreur.

-<countcountcountcount> : nombre d'exécutions successives du programme.

- <fileStageInfileStageInfileStageInfileStageIn> : transfert de l'exécutable d'un nœud à un autre.

- <fileStageOutfileStageOutfileStageOutfileStageOut> : transfert du fichier résultat d'un nœud à un autre.

- <fileCleanUpfileCleanUpfileCleanUpfileCleanUp> : effacé les fichiers relatifs au job après son

exécution.

P a g e | 121

B.2 Tests de soumission d'un job existant sur la

machine locale. Ce sont des tests pour vérifier le bon fonctionnement de notre grille

déjà installée. Ils sont soumis par la commande 'globusrun-ws' qui :

-Soumet plusieurs requêtes simultanément.

- Organise les exécutables.

- Attend la terminaison.

- Redirige vers stdout/stderrstdout/stderrstdout/stderrstdout/stderr .

B.2.1 Test 1 :

Il s'agit d'un simple test de job sans nécessité d'écrire un programme

descriptif de job (FIG B.1).

Dans cet exemple, nous lançons l'exécutable « /bin/touch » sur le

nœud local (poste4).

L'option « -c » prend comme premier argument une commande, dans

notre cas c'est « /bin/touch » et le deuxième argument le fichier

résultat alors que l'option « -submit » est nécessaire pour la

soumission de job. Le résultat obtenu est :

P a g e | 122

Le résultat réside normalement sous le répertoire où le job est

exécutée, dans notre cas c'est « /home/globus ».

B.2.2 Test 2 :

Il consiste à exécuter le job précédent sur un nœud distant. Pour

utiliser les ressources distantes nous devons appeler son container

qui se traduit par l'option « -F » lors du lancement de job. L'option « -

c » est présente parce qu'il s'agit d'une commande « /bin/touch » (voir

FIG B.2).

P a g e | 123

Le résultat est :

Education

rapport de stage