Faculté des Sciences Département d Informatique. Déploiement et configuration des intergiciels européens de grilles de calcul

Transcription

1 Faculté des Sciences Département d Informatique Déploiement et configuration des intergiciels européens de grilles de calcul Guillaume DESMOTTES Mémoire présenté sous la direction du Prof. Joël GOOSSENS en vue de l obtention du grade de Licencié(e) en Informatique Année académique

2 Remerciements Je tiens à remercier mon directeur de mémoire, le Professeur Joël Goossens, ainsi que Monsieur Othmane Bouhali pour m avoir guidé tout au long de ce travail et pour leurs nombreux conseils et avis. J exprime également toute ma gratitude aux autres membres de mon jury les Professeurs Raymond Devillers, Pascal Vanlaer et Esteban Zimanyi pour leurs relectures et conseils ainsi que pour le temps qu ils passeront à lire ce travail. Je remercie également ma maman et ma cousine Alexandra pour avoir relu et corrigé l orthographe de ce document. Enfin, je remercie chaleureusement Stijn De Weirdt et Shkelzen Rugovac avec qui j ai eu le plaisir de travailler durant ces quelques mois à l IIHE et sans qui ce travail n aurait pas été possible. ii

3 Table des matières 1 Introduction Contexte Objectifs Organisation du document Fermes de calcul Présentation Définition Points forts des fermes de calcul Architecture d une ferme de calcul Le réseau Asynchronous Transfer Mode (ATM) Scalable Coherent Interface (SCI) Myrinet Les machines de la ferme Single System Image Introduction Buts de la SSI Couches et niveaux du SSI Conclusion Les applications utilisateurs Grilles de calcul Introduction Présentation Origine du terme grille La Grille : le rêve et la réalité Définition Cadres d utilisation du Grid Calcul distribué High-Throughput Computing iii

4 TABLE DES MATIÈRES iv Calcul à la demande Traitement massif de données Informatique collaborative Architecture d une grille Couche Fabrique Couche Connectivité Couche Ressource Couche Collectif Couche Application Globus Présentation Les services Web Architecture du toolkit Les grilles en pratique Les grilles de calcul en Belgique Les grilles de calcul en Europe Quattor : installation et gestion de profils Introduction La gestion de fermes de calcul Installation du système d exploitation Programmes additionnels Configuration Stockage des configurations Transfert des configurations Gestion des profils Présentation de Quattor Configuration Management Le langage PAN Configuration Database Configuration Cache Manager Node and Cluster Management Gestionnaire d installation cdispd et le Node Configuration Deployer Configuration Components Développement futur et améliorations SCDB Configuration centralisée BEgrid Conclusion

5 TABLE DES MATIÈRES v 5 Les intergiciels Introduction L intergiciel LCG L interface utilisateur Computing Element Worker Node Storage Element Gestion de catalogues Accès aux fichiers Service d information Workload Management System Logging and Bookkeeping Sécurité Installation et configuration L intergiciel glite Computing Element Storage Element Gestion de catalogues Accès aux fichiers Service d information Workload Management System Logging and Bookkeeping Job Provenance Sécurité Conclusion Déploiement d un testbed glite Introduction Machines virtuelles Introduction Xen Utilisation de Xen avec Quattor Conclusion Intégration de glite dans Quattor Introduction Plate-forme de test Déploiement manuel de glite Utilisation de Quattor avec glite Problèmes d intégration de glite dans Quattor

6 TABLE DES MATIÈRES vi Conclusion Conclusion Conclusion 86 Bibliographie 88 Webographie 90 Glossaire 94 A Configuration des VOs 98 A.1 schema.tpl A.2 vo instance defaults.tpl A.3 config.tpl A.4 ncm-glite-vo.patch A.5 Exemple de configuration d un VO B Rapports de bugs 102 B.1 Problem with return value of glite-security-utils-config.py when called with start B.2 glite-ui-config does not accept the configure argument B.3 Bug in CE default template B.4 Missing dependency in pro software glite amga client.tpl B.5 Missing dependencies in pro software glite io client.tpl B.6 Missing dependency in pro software glite dpm disk server.tpl B.7 Missing dependencies in pro software glite lfc *.tpl B.8 Missing dependencies in pro software glite amga server.tpl B.9 Missing dependency in pro software glite ui.tpl B.10 Missing dependencies in glite-file-transfer-agents tpl file B.11 Missing dependency in glite-io-server tpl file B.12 bug in pro software glite dgas server.tpl with MySQL-shared-standard dependency B.13 glite-wn : unrecoverable - [ERROR] The./glite-lfc-client-config-config.py script cannot be found B.14 Error in glite-torque-server-config.py if no value assigned to rgma.servicetool.- activate B.15 glite-security-utils-config.py doesn t take care of some default params B.16 GPT LOCATION environment variable not exported in LFC client s configure script B.17 Error in gliteinstallerlib.py at the siteuri variable

7 TABLE DES MATIÈRES vii B.18 In glite-voms-server-config.py v password values should be between quotes

8 Table des figures 2.1 Architecture d une ferme de calcul [35] Les différents modules du middleware. [12] Transfert de données à travers une Memory Channel [8] Les différentes couches d une grille [22] Globus Toolkit version 4 [77] Échange entre le client et le service web : de la découverte du service à son invocation [43] WS-Ressource [43] Vue Client/Serveur de l architecture de Globus 4 [20] Architecture du GSI [21] Architecture de Quattor [31] Node Configuration Management Configuration Quattor centralisée Architecture de RLS [41] Architecture de LFC [41] Différentes niveaux de collecte d information du MDS [41] Fonctionnement de R-GMA [28] Différents composants de R-GMA [3] WMS de glite [1] Topologie du testbed glite viii

9 Chapitre 1 Introduction 1.1 Contexte Dès les débuts de l informatique, les scientifiques furent les plus gros consommateurs de puissance de calcul. Depuis, malgré les améliorations sans cesse croissantes des performances des ordinateurs modernes, ceux-ci n ont jamais réussi à satisfaire pleinement les exigences de la communauté scientifique, tant leurs simulations et modèles gagnaient en complexité. La dernière décennie a également vu l avènement des réseaux et d Internet. Ainsi, il ne suffit plus de travailler efficacement mais il faut également pouvoir le faire ensemble. De plus en plus de projets de recherche impliquent de multiples partenaires pouvant être répartis aux quatre coins du globe. Il devient alors nécessaire de disposer d une infrastructure commune, facilitant les partages d informations mais aussi de ressources. C est dans ce contexte, mêlant hautes performances et travail collaboratif, qu est né le concept de Grille de Calcul. Parmi les différentes disciplines avides de ressources informatiques, la physique des particules joue, sous l impulsion du CERN (European Organization for Nuclear Research) [55], un rôle majeur dans le développement du grid computing en Europe. Ainsi, le LHC (Large Hadron Collider) [89], le nouvel accélérateur de particules en construction au CERN, générera dès sa mise en service, prévue pour 2007, de l ordre de 10 peta-bytes de données par an! Outre les énormes capacités de stockage nécessaires à la collecte de ces informations, leur traitement devrait monopoliser environ des processeurs les plus modernes actuellement. Le développement d une grille de calcul performante et répartie sur l ensemble de l Europe se révèle dès lors indispensable pour pouvoir relever les multiples défis lancés par les différentes expériences du LHC. Notre travail fut réalisé en étroite collaboration avec l Interuniversity Institute for High Energies (ULB-VUB) [81]. L IIHE a joué un rôle majeur dans le développement du grid computing en Belgique et participe activement, en collaboration avec le CERN, à différents projets relatifs aux technologies grid. Il contribue également à l expérience CMS (Compact Muon Solenoid) [58] du LHC visant à mettre en évidence le boson de Higgs ainsi que différentes particules supersymétriques. Il est donc impératif que la Belgique dispose, lors du début de l expérience, d une infrastructure grid suffisamment performante et robuste, afin de nous permettre de participer à l effort mondial de traitement et d analyse de ces résultats. 1

10 CHAPITRE 1. INTRODUCTION Objectifs Le but principal de ce travail était d établir un premier contact avec glite, le futur intergiciel européen de grilles de calcul. Celui-ci est toujours en phase de développement et promet de nombreuses améliorations en terme de fonctionnalités, performance et standardisation, par rapport à l intergiciel actuel LCG 2. Notre objectif était de tester quelques services clés afin de déceler un maximum de problèmes avant la sortie d une première version stable de glite. L accent a particulièrement été mis sur son intégration avec notre système de gestion des installations et configurations : Quattor. L une des difficultés à laquelle on peut avoir à faire face lorsque l on découvre le monde du grid computing, est la multitude de concepts théoriques, de projets et de technologies auxquels on est confronté. L imposant glossaire et webographie en fin de cet ouvrage suffit pour en témoigner. Nous avons donc également essayé à travers ce travail de centraliser et donner une vision relativement globale, bien que non exhaustive, des différents acteurs et composants de l architecture d une grille de calcul en Europe. 1.3 Organisation du document Les grilles étant étroitement liées aux fermes de calcul, nous commencerons dans un premier temps par présenter ce type d infrastructure. Nous verrons ensuite les principaux concepts et bases théoriques relatifs aux grilles ainsi qu un bref aperçu de la manière dont ils se retrouvent implémentés en pratique. Nous aborderons alors des sujets plus spécifiques sur lesquels travaille l IIHE. Nous étudierons les problèmes relatifs à la gestion et l administration d un site composé d un grand nombre de machines. Nous introduirons ainsi le logiciel Quattor qui fournit une solution élégante à ces différents problèmes et qui a joué un rôle central dans le cadre de ce travail. Sera ensuite abordée la question des intergiciels de grilles de calcul. Nous nous concentrerons sur LCG 2 qui est actuellement utilisé dans la majorité des sites européens. Nous présenterons ensuite bien évidemment l intergiciel glite, pierre angulaire de ce travail, destiné à remplacer LCG 2. Nous insisterons sur les principales différences entre ces deux suites de programmes ainsi que sur les améliorations qu apporte glite. Enfin, nous présenterons concrètement le travail que nous avons effectué ces derniers mois à l IIHE ainsi que les principaux résultats qui en ont découlé. Comme nous l avons dit, notre objectif était de tester le nouvel intergiciel glite, de relever les principaux problèmes de celui-ci et d étudier son intégration dans Quattor. Nous nous sommes également intéressés à l utilisation conjointe de Quattor et Xen, qui permet de faire fonctionner plusieurs machines virtuelles sur une même machine physique. Le dernier chapitre de ce document regroupera donc une présentation de notre travail sur ces différentes technologies, des problèmes que nous avons rencontrés ainsi que des solutions permettant de les contourner, voire, dans le meilleur des cas, de les résoudre.

11 Chapitre 2 Fermes de calcul 2.1 Présentation Définition On retrouve de nombreuses définitions des fermes de calcul dans la littérature. Nous nous baserons sur les définitions présentées dans [6] pour définir une ferme de calcul comme un ensemble d ordinateurs autonomes inter-connectés en réseau travaillant conjointement comme une ressource de calcul simple et intégrée, au travers de l utilisation d un système logiciel additionnel de gestion. Discutons maintenant des différents aspects de cette définition. Une ferme est donc constituée de plusieurs ordinateurs appelés nœuds. Ainsi une machine, un mainframe ou n importe quel super-calculateur, aussi puissant soit-il et même disposant d un nombre important d unités de calcul, ne peut être considéré comme une ferme de calcul. Les différents nœuds constituant une ferme sont généralement relativement homogènes, tant du point de vue de leur matériel que de leur configuration logicielle ; bien que cela ne soit pas une règle stricte. Ces ordinateurs sont autonomes. On suppose donc qu ils disposent de leur propre processeur, mémoire et système d exploitation. La présence d un disque n est pas rigoureusement indispensable, l ordinateur étant connecté à un réseau, mais de nos jours, la plupart des nœuds de la majorité des fermes en sont équipés vu le faible prix des disques actuels. La définition nous apprend également que les ordinateurs sont inter-connectés par un réseau. Celui-ci sera le plus souvent local et à haut débit afin de ne pas dégrader les performances mais, ici encore, cela tient plutôt des règles de bonnes pratiques que de la condition stricte. Les fermes n étant destinées qu à du calcul, le réseau est bien souvent le seul point d interaction avec les nœuds, ceux-ci étant dépourvus de périphériques d entrées/sorties tels que écrans, claviers, souris... La dernière partie de la définition est certainement la plus intéressante car c est cette caractéristique qui distingue une ferme d un traditionnel réseau d ordinateurs. Une ferme de calcul doit paraitre depuis son ou ses points d accès comme étant une machine unique. Ainsi, les clients soumettent des jobs à la ferme sans se soucier de la (voire des) machine(s) qui va (vont) l exécuter. Cette virtualisation des ressources est réalisée à l aide d une couche logicielle comme nous l expliquerons plus en détail à la section Nous verrons également que dans certains cas, cette virtualisation peut être en partie matérielle. 3

12 CHAPITRE 2. FERMES DE CALCUL 4 Bien que cela ne soit pas explicite dans notre définition, nous exclurons de la définition les Grilles de calcul qui, comme nous le verrons dans le chapitre 3, diffèrent en de nombreux points des fermes. Notons que les termes grappe de serveurs et cluster sont également employés pour désigner les fermes de calcul. Dans la suite, nous utiliserons indistinctement ces différents termes Points forts des fermes de calcul Les différentes caractéristiques que nous avons énoncées font des fermes de calcul une solution particulièrement bien adaptée aux traitements de tâches nécessitant de grandes puissances de calcul et pouvant être exécutées en parallèle. Elles sont de plus en plus préférées à des solutions monolithiques telles que les super-calculateurs comportant beaucoup de processeurs qui se révèlent beaucoup plus coûteux, moins souples et plus sensibles aux pannes. Voyons maintenant quelques-uns des critères pouvant expliquer l utilisation sans cesse croissante des clusters. Les ordinateurs classiques bon marché ont vu leur puissance de calcul exploser ces dernières années. Selon la bien connue Loi de Moore, le nombre de transistors des microprocesseurs, et donc la puissance de ces derniers, double tous les 18 à 24 mois. Même si l on commence à s approcher de certaines barrières physiques dues aux technologies utilisées, la puissance de calcul continue à augmenter grâce, entre autres, aux améliorations des architectures des microprocesseurs et au développement des machines multiprocesseurs grand public. De par sa topologie distribuée, une ferme de calcul se révèle extrêmement souple et robuste. Ainsi, on peut aisément augmenter la puissance de calcul d une ferme en lui ajoutant des nœuds ou en améliorant la puissance de ceux-ci. De même, si un nœud vient à défaillir, seules les performances de la ferme s en verront affectées et non son fonctionnement dans son ensemble, du moins si le logiciel de gestion de la ferme est conçu à en conséquence, ce qui est généralement le cas. Du point de vue financier, une ferme de calcul se révèle être dans de très nombreux cas, une solution beaucoup plus avantageuse qu un super-calculateur ; les différents nœuds étant composés de matériels très bon marché. La bande passante des réseaux reliant les machines d une ferme a également considérablement augmenté et la latence diminué de par le développement et l implémentation de nouvelles technologies (voir section suivante) et de nouveaux protocoles pour les LAN. Les clusters sont généralement plus faciles à intégrer au sein d un système existant qu un super-ordinateur spécialisé pour le traitement de tâches parallèles. En effet, les fermes utilisent généralement des systèmes d exploitation très répendus (typiquement Linux) alors que les super-calculateurs sont généralement livrés avec un système propre au fabricant. Les postes de travail des utilisateurs sont généralement sous-employés la majorité du temps. On peut envisager de les utiliser comme nœuds afin de récupérer les temps de calcul non utilisés. Certains auteurs nomment ce type de cluster des Networks of Workstations (NOWs) ou encore fermes non dédiées. La plupart des gros calculateurs disposent de leurs propres outils de configura-

13 CHAPITRE 2. FERMES DE CALCUL 5 tion et de développement. Ces derniers sont malheureusement non standards et propriétaires. Au contraire, la communauté Libre et Open-Source dispose de nombreux logiciels tout à fait adaptés pour être utilisés dans le cadre de fermes de calcul. Dès lors, les fermes se révèlent un outil indispensable aussi bien pour la recherche scientifique que dans le monde de l industrie : calcul challenge 1, rendu de films en images de synthèse, modélisation de voitures ou d avions, traitement d images satellites Architecture d une ferme de calcul Voyons maintenant comment s articule une ferme de calcul. La figure 2.1 reprend une architecture classique d une ferme. Les sections suivantes détailleront les différentes couches représentées sur ce schéma. FIG. 2.1 Architecture d une ferme de calcul [35] 2.2 Le réseau Le réseau inter-connectant les différentes machines du cluster est un élément crucial et intervient à différents niveaux dans celui-ci. Lorsqu un utilisateur soumet un job à la ferme, le ou les nœuds en charge de son exécution doivent récupérer le code du programme à exécuter ainsi que ses données. Celles-ci pouvant être très importantes, il est donc essentiel que le réseau dispose d une bande passante suffisante afin que les nœuds n attendent pas trop longtemps avant de pouvoir commencer leur travail. À l inverse, une fois les calculs effectués et le job terminé, l utilisateur doit pouvoir récupérer ses résultats dans un temps raisonnable. Ici encore, ceux-ci peuvent être très conséquents. Des programmes parallélisables s exécutant simultanément sur plusieurs nœuds peuvent avoir besoin de s échanger des données ou des informations de synchronisation. 1 défi lancé à la communauté scientifique pour, par exemple, tenter de casser un cryptage afin de tester sa robustesse

14 CHAPITRE 2. FERMES DE CALCUL 6 Les machines peuvent s échanger des informations telles que leur état de charge afin de pouvoir orienter les nouveaux jobs. La majorité des fermes utilisent le traditionnel Ethernet, offrant de bonnes performances (Fast Ethernet et Gigabit Ethernet) et étant extrêmement répandu et peu onéreux. Signalons toutefois quelques alternatives qui peuvent se révéler intéressantes dans certains cas Asynchronous Transfer Mode (ATM) ATM [50] est un protocole qui transfère les données par cellules de taille fixe et non par paquets de longueur variable comme Ethernet. Il se base sur une technologie à circuits virtuels commutés à l instar de ce que l on trouve dans les réseaux de téléphone. Contrairement à d autres types de réseaux, ATM a pour but d être utilisable aussi bien pour les WAN (Wide Area Network) que pour les LAN, mais force est de constater qu il n a pas réussi à s imposer pour ces derniers. ATM est toutefois assez répandu dans les sociétés de télécommunication Scalable Coherent Interface (SCI) SCI [116] est un standard IEEE fournissant un système de mémoire partagée à faible latence au travers d un cluster. SCI permet d utiliser une mémoire s étendant à l ensemble du cluster, débarrassant ainsi le programmeur de cette gestion complexe. On peut voir cela comme une sorte de BUS d entrées/sorties processeur-mémoire via un LAN. Les facilités de programmation qu il offre et le fait que SCI soit un standard de l IEEE en ont fait un choix assez populaire pour l interconnexion des machines dans les clusters à hautes performances Myrinet Myrinet est un réseau full-duplex haute performance propriétaire créé par la firme Myricom [96]. Il a été conçu et optimisé dans le but d interconnecter les machines d un même cluster. Myrinet offre des avantages notables par rapport à Ethernet tels que de très faibles latences, un excellent débit et des interfaces réseaux possédant un microprocesseur embarqué programmable permettant une plus grande flexibilité. Malheureusement, le principal défaut de Myrinet par rapport à Ethernet reste son prix assez conséquent. De plus, le nombre de ports des switchs est assez limité, nécessitant le chainage de ceux-ci pour la mise en place de réseaux de taille importante. 2.3 Les machines de la ferme Le niveau central de la figure 2.1 représente les différentes machines composant la ferme. Initialement, celles-ci étaient des machines monoprocesseur. Cependant, la tendance actuelle est de leur préférer des architectures multiprocesseurs, de par la démocratisation récente de ces technologies. Cela permet ainsi des gains substantiels de place, en réduisant l encombrement tout en maintenant le même nombre de processeurs de la ferme.

15 CHAPITRE 2. FERMES DE CALCUL 7 Les performances du système peuvent également se voir fortement augmentées. Si les jobs sont tels qu ils comportent plusieurs processus devant communiquer entre eux, cette communication sera beaucoup plus rapide entre processus tournant sur la même machine physique que s ils doivent passer par le réseau reliant les nœuds de la ferme pour ce faire. Notons toutefois que la répartition des jobs sur la ferme devra peut-être être adaptée pour tenir compte de cette spécificité. Les fermes dont les machines sont de type multiprocesseurs sont parfois appelées CLUMP (CLUster of MultiProcessors). 2.4 Single System Image Introduction Une Single System Image (SSI) est la partie d un système qui cache des ressources hétérogènes et distribuées afin de les présenter à l utilisateur et aux applications comme une seule et même ressource unifiée. La SSI peut être définie comme étant l illusion, réalisée par matériel ou logiciel, qui présente une série de ressources comme une ressource unique et plus puissante. [6] Cela signifie que, grâce à la SSI, les utilisateurs auront une vue globale des ressources disponibles et ce quel que soit le nœud auquel ces ressources sont associées. De plus, la SSI peut permettre à un système de continuer à fonctionner après un dysfonctionnement (haute disponibilité) ou encore à s assurer que le système est équitablement chargé et les ressources bien utilisées (gestion des ressources et ordonnancement). Une SSI peut être implémentée à différents niveaux allant du matériel spécialisé jusqu aux applications comme nous le verrons à la section Buts de la SSI Parmi les principaux services que fournit la SSI au cluster, citons : Point d entrée unique Un utilisateur peut se connecter au cluster à travers un hôte virtuel alors que le cluster dispose de plusieurs nœuds destinés à traiter les sessions. Le système va alors automatiquement distribuer les requêtes de connexions des utilisateurs aux différents hôtes physiques afin d assurer une bonne répartition de la charge. Ainsi lorsque l on se connecte en telnet sur aster.ulb.ac.be, la session est ouverte sur l une de ses 3 machines (aster2.ulb.ac.be par exemple). Espace de processus unifié Tous les processus utilisateurs ont un identifiant unique pour toute la ferme, et ce indépendamment du nœud qui l héberge. Un processus de n importe quel nœud peut créer des processus fils, via les fork UNIX, sur la même machine comme sur un autre nœud. Un processus doit également être capable de pouvoir communiquer, à travers des signaux et des pipes, avec n importe quel autre processus situé sur un nœud distant.

16 CHAPITRE 2. FERMES DE CALCUL 8 Enfin, le cluster doit permettre la gestion et le contrôle globalisé des processus comme s ils étaient exécutés sur une machine locale. Espace mémoire unifié Les utilisateurs doivent avoir l illusion qu il n y a qu une seule grosse mémoire centralisée alors qu elle est en réalité éparpillée sur la mémoire physique des différents nœuds. Pour ce faire, on peut utiliser un système de DSM (Distributed Shared Memory) logiciel ou matériel (voir section 2.4.3). Une autre solution est d utiliser un compilateur permettant de distribuer les structures de données de l application sur les différents nœuds. Il est loin d être trivial de développer un système de mémoire unique qui soit à la fois efficace, indépendant de la plate-forme et capable de supporter des codes purement séquentiels. Espace d I/O unifié Chaque nœud doit pouvoir effectuer des opérations d entrées/sorties, que le périphérique ou le disque soit local ou sur une autre machine de la ferme. Hiérarchie de fichiers unifiée L utilisateur ne doit voir qu une seule et unique hiérarchie de fichiers et de répertoires. Celle-ci doit intégrer de façon totalement transparente les systèmes de fichiers locaux et ceux distants. Parmi de tels systèmes de fichiers, citons : NFS [99], AFS [48], XFS [140] ou encore Solaris MC Proxy [122]. Réseau virtuel unifié N importe quel nœud doit pouvoir accéder à n importe quelle connexion réseau à travers le domaine de la ferme même si le réseau n est pas physiquement connecté à tous les nœuds du cluster. Système de gestion des jobs unifié Un job utilisateur peut être soumis de n importe quelle machine de la ferme et peut demander autant de nœuds qu il le désire pour son exécution (dans les limites des ressources de la ferme évidemment). Les jobs peuvent être de nature batch, interactive ou parallèle. GLUnix [79], LSF [91] et Condor [59] sont des exemples de système de gestion de jobs pour les clusters. Interface de contrôle unique L entièreté du cluster ainsi que chaque nœud individuellement doit pouvoir être configuré, monitoré, testé et contrôlé à l aide d une interface unique.

17 CHAPITRE 2. FERMES DE CALCUL 9 Point de reprise Il n est pas rare que la durée de vie d un processus soit particulièrement longue. Dès lors, la probabilité qu une défaillance matérielle survienne lors de l exécution d un job peut devenir non négligeable et il serait dommage, voire critique, de perdre des jours ou même des semaines de calcul. Le checkpointing, ou point de reprise, est un mécanisme logiciel permettant de lutter contre ce problème. L idée est de sauvegarder périodiquement une image du processus ainsi que son contexte d exécution. Dès lors, si un problème survient, on pourra restaurer le processus et le redémarrer dans l état où il se trouvait lors de la dernière sauvegarde. On ne perdra ainsi que les calculs ayant été effectués depuis la dernière sauvegarde. Migration de processus Lorsqu un job s exécute sur une machine non dédiée (utilisée également comme station de travail par exemple), il se peut que durant son exécution le propriétaire de la machine désire en reprendre le contrôle. Afin de le gêner le moins possible et de continuer à assurer de bonnes performances pour l exécution du job, il est alors nécessaire de migrer le job vers un autre nœud de la ferme. Le système va alors checkpointer le processus (voir point précédent) et le transférer vers une autre machine qui va reprendre son exécution. D autres raisons peuvent également amener à vouloir migrer un processus : Une machine est lourdement chargée alors qu une autre est devenue libre. Deux processus situés sur des machines distinctes communiquent intensivement ; il peut alors être intéressant de les migrer vers une machine multiprocesseurs afin de maximiser les performances. Certains signes semblent indiquer qu un dysfonctionnement matériel est proche (par exemple un disque en fin de vie).... La figure 2.2 représente ces différents services et leurs interactions. Comme on le voit, ils se trouvent dans une couche située entre les applications utilisateurs et le système d exploitation. Voilà pourquoi on parle parfois de middleware ou encore intergiciel. FIG. 2.2 Les différents modules du middleware. [12]

18 CHAPITRE 2. FERMES DE CALCUL Couches et niveaux du SSI La Single System Image peut être implémentée à différents niveaux. On la retrouve ainsi dans un ou, plus généralement, une combinaison des niveaux suivants : matériel, système d exploitation (underware), middleware, applications. Une bonne SSI est généralement obtenue en faisant collaborer ces différents niveaux ; un niveau plus bas pouvant faciliter l implémentation des niveaux qui lui sont supérieurs. Détaillons maintenant chacun des niveaux et quelques technologies qui leur sont associées. Hardware Les systèmes à Digital Memory Channel et le hardware de type DSM (Distributed Shared Memory) offrent des fonctionnalités SSI au niveau matériel et permet à l utilisateur de voir le cluster comme un système de mémoire partagée. Ce type d infrastructure fournit une mémoire virtuelle partagée à travers les nœuds via un espace d adressage mappé inter-nœuds. Une infrastructure de type Memory Channel est composée d interfaces PCI et d un ou plusieurs hubs. Afin de rendre les communications possibles à travers la Memory Channel, les pages de mapping mémoire des applications sont marquées soit en lecture seule, soit en écriture seule dans leur espace d adressage virtuel. L interface de chaque machine contient deux tables de contrôles des pages (PCT - Page Control Table), l une pour les mappings en lecture et l autre pour les mappings en écriture. Pour chaque page en lecture seule, on lui associe une page de la mémoire physique locale. Différents attributs peuvent être définis pour ces pages telles que : réception en cours, interruption lors d une réception, lecture distante... Si une page est mappée en écriture seule, on lui crée une entrée dans la table des pages de l espace d adressage de l interface PCI. Lors d une écriture, on diffuse l information sur le réseau. Les nœuds qui ont mappé l adresse de la page dans leur zone de lecture vont stocker les données dans leur mémoire physique à l endroit associé à la page. Les autres nœuds vont, quant à eux, simplement ignorer l information. Ainsi, une fois les différentes régions de mémoire correctement mappées et configurées, les transferts de données entre nœuds s effectuent sans intervention de l OS. Ce mécanisme de transfert est illustré sur la figure 2.3. FIG. 2.3 Transfert de données à travers une Memory Channel [8]

19 CHAPITRE 2. FERMES DE CALCUL 11 Au-delà de ce transfert simple de données, Memory Channel dispose d un système d accusés de réception et de verrous. Afin d éviter des situations incohérentes, il définit également un ordre strict pour l acheminement des paquets de données à écrire. Memory Channel réduit à leur minimum les communications entre les nœuds. De plus, les temps de latence sont très faibles. Pour plus d informations sur le Memory Channel et d autres technologies similaires, le lecteur intéressé consultera [8]. Système d exploitation Certains systèmes d exploitation offrent au niveau de leur noyau des fonctionnalités orientées cluster ; on parle alors parfois d underware en référence à la couche cachée située entre l interface utilisateur et le noyau. L objectif d un cluster est de mutualiser des ressources afin d offrir de meilleures performances. Pour ce faire, le système d exploitation doit permettre l ordonnancement groupé de programmes parallèles, identifier les ressources non utilisées (processeurs, mémoires, disques) et offrir un accès unifié à ces dernières. Idéalement, il doit également supporter la migration de processus, afin de permettre la répartition dynamique de la charge, et fournir un système de communication rapide entre les processus. Les systèmes d exploitation axés cluster offrent ces fonctionnalités à l utilisateur sans devoir rajouter des appels systèmes ou d autres commandes. Parmi les noyaux supportant une SSI, citons SCO UnixWare [118], MOSIX [93] ou encore Sun Solaris-MC [122]. Un support complet du SSI permet à toutes les ressources, physiques et noyaux, d être visibles et utilisables de n importe quelle machine du système. Une implémentation au niveau de l OS fera que les noyaux de chaque nœud vont coopérer afin d offrir une vue unifiée de toutes leurs interfaces respectives. Ce support complet du SSI au niveau noyau est très intéressant car il peut permettre d économiser beaucoup de temps et d argent. En effet, les applications existantes n ont pas à être réécrites ou adaptées pour pouvoir fonctionner dans le nouvel environnement. Ainsi, ces programmes pourront être exécutés sur n importe quel nœud sans configuration supplémentaire, les processus pourront être migrés afin de mieux répartir la charge ou encore d être plus robustes aux problèmes matériels (point de reprise...). La plupart des systèmes d exploitation supportant SSI ont rajouté une couche audessus d un système d exploitation existant et implémenté une allocation globale des ressources. Cela permet de rendre le système facilement portable et réduit drastiquement son temps de développement. C est le cas par exemple de Berkley GLUnix [79] conçu comme une couche rajoutée audessus d un système existant. Il a ainsi prouvé qu il est possible de construire rapidement un nouveau système en basant ses services sur les couches inférieures du système original (Solaris [122]). Middelware Dans beaucoup de clusters, il est courant de trouver l implémentation de la SSI dans une couche située entre le système d exploitation et les applications, appelée Middelware. Cela comprend entre autres :

20 CHAPITRE 2. FERMES DE CALCUL 12 Des environnements de développements comme PVM (Parallel Virtual Machine) [107] permettant d unifier des systèmes tournant sous Unix et/ou Windows. Pour ce faire, l utilisateur lance un démon sur chaque machine du système. Ces démons s inter-connectent entre eux créant ainsi l infrastructure de la machine parallèle. Lorsqu un processus veut communiquer avec un autre, il se connecte à son démon local. C est ce dernier qui se chargera de transmettre les messages au démon tournant sur la machine du processus destinataire. Toutes les communications entre les deux processus se feront donc par l intermédiaire de leur démon respectif. Des systèmes de gestion et d ordonnancement des jobs comme Condor [59]. La plate-forme JESSICA (Java-Enabled Single-System Image Computing Architecture) [83] permettant l exécution d applications Java utilisant des threads en les répartissant sur le cluster et ce, sans aucune modification de cette dernière. Niveau applicatif La SSI peut également se retrouver au niveau des applications. L applicatif de la SSI est le niveau le plus haut et probablement un des plus importants car c est celui avec lequel l utilisateur va directement interagir. À ce niveau, les différents composants et sous-systèmes coopérant ensemble sont présentés à l utilisateur comme une seule et même application. Ainsi, un outil d administration de ferme peut permettre de gérer et administrer les différents services offerts par la SSI. L utilisateur pourrait dès lors à l aide d une interface graphique monitorer et contrôler un nœud spécifique, l ensemble du cluster ou un soussystème de celui-ci. Comme exemple d un tel outil, citons PARMON [11] qui permet de visualiser et contrôler les différents services et ressources de la ferme via une seule fenêtre. Avantages et inconvénients des différents niveaux Chaque niveau de la SSI possède ses propres avantages et inconvénients. Le matériel dédié offre la plus grande transparence mais son architecture rigide laisse peu de place aux extensions et améliorations. Le niveau noyau permet d offrir les fonctionnalités de la SSI à tous les utilisateurs : les développeurs d applications comme les utilisateurs finaux. Cependant l implémentation au niveau du noyau n est pas triviale et souvent coûteuse en temps de développement ou de maintenance. L implémentation dans les applications permet un développement partiel des fonctionnalités de la SSI mais requiert que chaque programme les développe séparément. Par contre, cette approche permet un développement par étape en rajoutant des fonctionnalités de la SSI au fur et à mesure. Au contraire, l approche au niveau du noyau nécessite bien souvent que tous les composants supportent la SSI avant qu elle puisse être utilisée et mise sur le marché. Cela rend dès lors l approche niveau noyau risquée et plus difficilement viable économiquement. Le middleware est souvent un bon compromis. Ainsi, avec PVM, chaque application doit être implémentée en utilisant une API spécifique. Cela entraine donc un coût de développement supplémentaire pour pouvoir bénéficier de la ferme mais il sera moins important que dans l approche purement applicative car on pourra réutiliser ici les facilités offertes par le framework.

21 CHAPITRE 2. FERMES DE CALCUL Conclusion La SSI augmente grandement les performances et la facilité d utilisation de la ferme en masquant les différentes machines qui la composent et en les présentant comme une ressource unique et unifiée. Elle joue donc un rôle clé dans tout cluster. La SSI peut être réalisée par matériel ou diverses techniques logicielles ayant chacune leurs inconvénients et avantages en terme de fonctionnalités, souplesse ou facilité de déploiement. L approche middleware est généralement un bon choix mais il faut garder à l esprit qu elle n offre pas toujours un support complet de la SSI, comme peut le faire une implémentation au niveau du noyau. Dès lors, le terme middleware est parfois utilisé pour désigner la SSI et ses différents services, indifféremment de la façon dont ceux-ci sont réellement implémentés dans le système. Enfin, il est important de toujours considérer la transparence de la SSI comme un critère primordial dans le design du cluster à l instar de l amélioration des performances et de la disponibilité. 2.5 Les applications utilisateurs La finalité d une ferme est d exécuter les applications que lui soumettent ses utilisateurs afin de résoudre des problèmes. Pour profiter pleinement des ressources de la ferme, il est crucial de paralléliser au maximum le problème considéré. On distingue deux grands types de parallélisme. Parallélisme des données : Ce type de parallélisme est utilisé lorsque l on désire appliquer un même traitement sur une grande quantité de données. On va alors découper le jeu de données en portions distinctes et les distribuer sur les différents nœuds de la ferme. Chacun va alors exécuter le même programme de traitement sur les données qui lui ont été assignées. Une fois la découpe des données effectuée, les différents nœuds de traitement n utilisent pas de ressources communes et n ont pas besoin de communiquer entre eux pour effectuer leur travail. Ce type de parallélisme est généralement des plus efficaces car les différents processus de la grille ne doivent pas s attendre lors de leur exécution. De plus, vu qu ils ne partagent aucune ressource commune, il n y a aucun risque d inter-blocage (deadlock) ou de famine. Parallélisme fonctionnel : Les processus vont effectuer des tâches différentes et peuvent avoir besoin de communiquer entre eux lors de leur exécution. Notre application est donc subdivisée en différents blocs fonctionnels qui seront exécutés en parallèle. Par exemple, on pourrait modéliser une simulation d écosystème où chaque processus gérerait un niveau de la chaine alimentaire (plantes, herbivores, carnivores, nécrophages...). Le type de parallélisme que l on va utiliser dépend bien évidemment du problème considéré. Tous les problèmes ne permettent pas une découpe de leurs données ou de leur code en différents blocs fonctionnels. Ils sont alors, malheureusement, non parallélisables. La parallélisation au niveau des données est relativement simple à utiliser sur une ferme. Il suffit de découper le jeu de données, de lancer les différentes exécutions sur les nœuds puis de regrouper les résultats une fois le travail terminé.

22 CHAPITRE 2. FERMES DE CALCUL 14 Par contre, la parallélisation fonctionnelle nécessite que les différents nœuds puissent communiquer entre eux. Ainsi, un job ne peut avancer que jusqu à un certain point avant d avoir besoin de données fournies par un autre job, et réciproquement. Comme nous l avons vu précédemment (voir section 2.4.3), selon le niveau d implémentation de la SSI, il peut être nécessaire d adapter les applications utilisateurs afin qu elles puissent bénéficier de l infrastructure de la ferme. On utilise alors des bibliothèques de transfert de messages (Messages Passing Systems) telles que MPI (Message Passing Interface) [94] ou PVM [107] que nous avons déjà évoqués.

23 Chapitre 3 Grilles de calcul 3.1 Introduction Les fermes de calcul marquèrent une première étape importante dans l informatique distribuée. La seconde est sans aucun doute les grilles de calcul, qui risquent bien de révolutionner à de nombreux égards non seulement cette discipline mais également la majorité des domaines de recherches scientifiques voire même la façon dont nous abordons l informatique actuellement! Ce chapitre présentera dans un premier temps le concept de grille ainsi que quelques bases théoriques qui l entourent. Nous verrons ensuite comment ces principes sont en partie implémentés dans Globus [77]. Enfin, nous terminerons par présenter brièvement quelques exemples de grilles existantes Présentation À l instar d Internet, le concept de grille est apparu dans le milieu scientifique. Internet a été développé à l origine pour permettre aux différents laboratoires et universités de disposer d un médium de communication commun utilisable à très large échelle. De même, la grille a pour but de mutualiser des ressources informatiques (puissance de calcul et espace de stockage) à l échelle mondiale. Ce besoin s est fait sentir lorsque la complexité des modèles développés par les chercheurs, ainsi que les expériences et analyses qui en découlaient, devenaient tellement complexes qu aucun institut ne disposait des infrastructures (en terme de calcul ou de stockage) nécessaires pour les traiter. Même si l on peut en théorie toujours ajouter des nœuds à une ferme, il est évident qu on est toujours confronté à un moment ou un autre à une barrière pratique que ce soit pour des raisons logistiques ou financières. De plus, actuellement un grand nombre de projets de recherche sont internationaux et impliquent de nombreux instituts. Pour des raisons politiques, il n est pas envisageable qu un seul des partenaires du projet dispose de l intégralité et de l exclusivité de la puissance de calcul ainsi que des données et résultats des différentes expériences. Alors que les fermes de calcul avaient pour but de mettre en commun des ressources disponibles localement, les grilles se trouvent un cran au-dessus et mutualisent des ressources distribuées géographiquement. On peut voir une grille de calcul comme une sorte de cluster de clusters de même que l on considère parfois Internet comme le réseau des 15

24 CHAPITRE 3. GRILLES DE CALCUL 16 réseaux. Signalons enfin que le développement des grilles de calcul doit beaucoup à l essor d Internet. En effet, il était inconcevable d interconnecter des sites dispersés géographiquement sans le développement des réseaux globaux. Internet a favorisé la popularisation de ce type de réseau tout en permettant d atteindre de bonnes performances en terme de bande passante, indispensable pour les grilles de calcul Origine du terme grille Le terme grille de calcul est la traduction de grid computing. Ce dernier vient de l analogie avec le réseau de distribution d électricité appelé electrical power grid en Anglais. En effet, on peut rapprocher la puissance de calcul actuelle avec ce qu était l électricité au début du XX e siècle. On maitrisait l électricité et disposait de matériel pour l exploiter mais chaque personne devait produire sa propre électricité et la consommer sur place. Ce n est qu avec le développement du réseau de distribution électrique que la vraie révolution a pu s opérer en offrant, au plus grand nombre, la possibilité de recevoir et utiliser de l électricité sans se soucier de la façon ou de l endroit où elle a été produite. Actuellement, chaque ordinateur ou ferme de calcul utilise la puissance de calcul qu elle a généré localement. L idée du grid computing est de mettre à disposition ses ressources en échange d un accès aux ressources des autres utilisateurs La Grille : le rêve et la réalité Comme nous venons de le voir, une grille de calcul est un type d infrastructure informatique comme le sont les fermes. On retrouve régulièrement dans la littérature l expression The Grid ( La Grille ). Ce terme fait référence à une super grille mondiale reliant toutes les infrastructures existantes pour former une sorte de méta-grille. Tout un chacun pourrait alors facilement s y connecter afin de bénéficier de ses ressources et de sa puissance. La Grille serait ainsi au partage de puissance de calcul ce qu est le Web au partage de données. Cette énorme Grille mondiale est ce que l on appelle parfois le rêve du grid computing. Actuellement la réalité est, comme bien souvent, assez éloignée de cet idéal. On retrouve ainsi une série de grilles de taille plus ou moins importante à l échelle nationale. Certaines de ces grilles nationales s inter-connectent entre elles afin d étendre leur échelle sur plusieurs pays mais, actuellement, nous ne disposons pas encore d une infrastructure mondiale et unique comme l est Internet par exemple. Dans la section 3.6, nous présenterons quelques exemples réels de grilles actuelles. Les différents concepts et principes que nous aborderons par la suite ne se rapportent pas, sauf mention contraire, à une grille en particulier. On peut donc lire les termes grille ou grid comme se référant à un type d infrastructure ou encore au projet de Grille mondiale. 3.2 Définition Le concept de grille de calcul étant encore relativement récent, on peut en trouver de nombreuses définitions que ce soit dans la littérature scientifique ou sur Internet. Nous

25 CHAPITRE 3. GRILLES DE CALCUL 17 reprendrons ici la définition donnée dans [30] et discuterons brièvement des différentes notions abordées dans celle-ci. Une grille de calcul est une infrastructure matérielle et logicielle qui fournit un accès fiable, uniformisé, répandu et bon marché à des ressources informatiques hautes performances. Nous parlons d une infrastructure car une grille de calcul vise à mutualiser un grand nombre de ressources (cycles CPU, données, espace de stockage). Pour ce faire, il est nécessaire de disposer d une architecture matérielle permettant l interconnexion de ces ressources, mais aussi d une architecture logicielle afin de pouvoir faire cohabiter, surveiller et contrôler cet ensemble. Dans la suite de ce chapitre, nous décrirons quelques caractéristiques de cette infrastructure. Une grille implique un grand nombre d instituts et de personnes. Dès lors, l aspect politique et humain n est pas à négliger lorsque l on déploie ce type d infrastructure. La nécessité d un service fiable est fondamentale. Les utilisateurs doivent avoir l assurance qu ils auront accès à un service prévisible, constant et de haute performance de la part des différents composants qui constituent la grille. Selon le type de programme exécuté sur la grille, la signification que l on donne à cette performance peut être de différentes natures telles que la bande passante du réseau, le temps de latence, la puissance de calcul brute, les services logiciels disponibles ou encore la sécurité. Avoir un service uniformisé est le second objectif de la grille. Comme pour l électricité, il est important d avoir des services standardisés accessibles via des interfaces standards. Sans de telles normes, le développement d applications ainsi que le déploiement de la grille sont fortement compromis voire impossibles. Un des grands défis du Grid est d arriver à concevoir de tels standards devant gérer des matériels et logiciels très hétérogènes (alors que les fermes sont plutôt homogènes) tout en conservant de hautes performances. Un accès répandu garantit de pouvoir retrouver les différents services quel que soit l environnement vers lequel on pourrait migrer. Cela ne signifie pas que les ressources sont accessibles de n importe où universellement. De même qu une nouvelle maison n a accès à l électricité qu une fois le cablage installé et après avoir souscrit chez un fournisseur, l accès à la grille aura une circonscription et un contrôle d accès similaire. On pourra toutefois compter sur un accès suffisamment universel pour pouvoir être utilisé quel que soit l environnement d exécution. Enfin, l accès à cette infrastructure doit être relativement bon marché au regard des bénéfices qu elle peut apporter. Les industriels dépensent des dizaines de millions pour construire des centrales électriques car cet investissement leur est rentable. D autre part, l investissement financier pour pouvoir bénéficier du réseau électrique est, bien heureusement, infiniment plus restreint. Idéalement, la Grille de calcul devrait jouir des mêmes attraits économiques. En plus des exigences abordées dans cette définition, nous pouvons également rajouter : La confidentialité et la sécurité. Mettre de telles ressources à disposition de différentes communautés d utilisateurs ne peut évidemment se faire qu avec une politique stricte de sécurité. N importe qui ne doit pas pouvoir utiliser n importe quelle ressource ou accéder aux données d autres utilisateurs, et encore moins les modifier. La grille doit donc disposer d outils souples et fiables pour gérer l identification des utilisateurs ainsi que les droits qui leur sont associés. On peut imaginer vouloir utiliser des applications interactives sur la grille avec lesquelles un utilisateur voire même un groupe d utilisateurs pourraient interagir

26 CHAPITRE 3. GRILLES DE CALCUL 18 directement. La grille doit permettre un niveau de performances tel qu elle sera à même de satisfaire les contraintes temps réel inhérentes à ce type d applications. 3.3 Cadres d utilisation du Grid La Grille de calcul offre un éventail infini de possibilités tant les domaines pouvant bénéficier d une telle puissance et infrastructure sont nombreux. Dans cette section, nous présenterons brièvement cinq grandes classes d applications pour lesquelles la Grille pourrait révolutionner la façon dont elles abordent et résolvent les problèmes Calcul distribué Les applications de calcul distribué sont évidemment d excellentes candidates pour être utilisées sur une grille. Elles bénéficient ainsi d un nombre beaucoup plus important de ressources de calcul leur permettant de résoudre des problèmes qui leur étaient auparavant inaccessibles. Ainsi par exemple, les expériences du LHC nécessiteront de l ordre de processeurs pour traiter la masse d informations générées par le collisionneur. Il est évidemment illusoire d espérer disposer d une telle puissance de calcul sur un seul et même site. L utilisation d une grille se révèle dès lors indispensable. Parmi les principaux défis que doit relever l architecture de la grille pour de telles applications, citons : l ordonnancement à grande échelle des processus, la souplesse des algorithmes et protocoles qui doivent être capables de gérer un nombre de nœuds pouvant aller de la dizaine à des centaines voire des milliers de fermes de machines, la tolérance des algorithmes aux temps de latence inhérents à la taille de la grille, atteindre et maintenir un haut niveau de performances dans un système très hétérogène High-Throughput Computing Le but ici n est pas de rechercher la performance pure comme dans le cas précédent mais de rentabiliser au maximum des ressources en récupérant les cycles processeurs non utilisés quand celui-ci est oisif (idle). On pense bien entendu aux stations de travail qui sont généralement très largement sous utilisées, ne serait-ce qu en dehors des heures de bureau. À titre d exemple, le système Condor [59] de l Université du Wisconsin est utilisé pour gérer des groupes de centaines de machines dans des universités et laboratoires aux quatre coins du monde. Ces ressources sont utilisées pour des études aussi diverses et variées que la simulation moléculaire, le traitement de signal ou l attaque de systèmes cryptographiques. Un autre projet bien connu du grand public, SETI@home [119], même s il ne constitue pas vraiment une grille de calcul au sens où nous l entendons, est basé sur un principe similaire. Tout un chacun peut installer un logiciel permettant d effectuer automatiquement, lorsque l ordinateur est oisif, des calculs de traitement de signaux dans l espoir de détecter des signes d une intelligence extraterrestre.

27 CHAPITRE 3. GRILLES DE CALCUL Calcul à la demande Ce type d applications utilise la grille afin de satisfaire des besoins à court terme en ressources, tels qu ils ne peuvent être satisfaits en local pour des raisons pratiques ou de rentabilité. Ces ressources peuvent être du temps de calcul, des logiciels, des données, des capteurs spécialisés... Contrairement au calcul distribué, le but recherché ici est plutôt la rentabilité que les performances pures. Pour rendre cette nouvelle forme d utilisation des ressources possible, il est primordial de développer des systèmes performants et sécurisés de facturation (établir le montant à imputer à l utilisateur en fonction des différentes ressources qu il a employées sur la grille) et de paiement Traitement massif de données Dans ce type d applications, le but est d extraire de nouvelles informations à partir de grandes bases de données distribuées géographiquement. Généralement, ces types de traitement sont également de grands consommateurs de puissance de calcul et de bande passante. Les systèmes de prévisions météorologiques modernes utilisent énormément de données récoltées aux quatre coins du globe (comme des observations satellites par exemple). Le processus complet implique des transferts et des traitements de plusieurs dizaines de giga de données. Les expériences du LHC sont sans doute le meilleur exemple pour illustrer ce type de problème. On considère en effet qu une fois le collisionneur entré en service (prévu pour 2007), il devrait générer de l ordre de 15 petaoctets (15 millions de Gigaoctets) de données par an. Pour donner un ordre d idée, cela équivaut à 20 millions de CD s, soit une pile de 20 kilomètres de haut! La distribution géographique de ces données est ici indispensable. Les principaux problèmes à résoudre pour ce type d application sont l acheminement et la configuration de flux de données très importants à travers différents niveaux de hiérarchie Informatique collaborative Le but des applications collaboratives est de permettre et favoriser les interactions entre les personnes. Elles sont souvent structurées sous forme d espaces virtuels partagés entre les utilisateurs. La plupart de ces applications permettent de partager des ressources comme par exemple des données ou des simulations. Elles partagent alors bien souvent des caractéristiques avec les autres grands types d applications décrites précédemment. Les expériences du LHC sont ici encore une bonne illustration de ce type d applications. En effet, ce ne sont pas moins de quelque 5000 chercheurs répartis dans plus de 500 universités et instituts qui devront pouvoir accéder aux résultats des différentes expériences. L infrastructure de la grille se révèle être un excellent vecteur pour ce type d applications.

28 CHAPITRE 3. GRILLES DE CALCUL Architecture d une grille Comme pour les fermes, nous présenterons l architecture d une grille comme un empilement de différentes couches (figure 3.1). Application Collectif Ressource Connectivité Fabrique FIG. 3.1 Les différentes couches d une grille [22] La couche au sommet de l architecture est celle des Applications qui seront exécutées sur la grille. Si celles-ci ont été prévues ou adaptées pour tirer parti des ressources ou spécificités de la grille, on parle parfois d applications grid-aware. La couche Collectif est chargée de la coordination des ressources. Cela inclut les services d annuaires, la gestion des requêtes, la surveillance des différents services (monitoring) ou encore la réplication des données. La couche Ressource est en charge du partage des ressources. Elle doit gérer leur mise à disposition ainsi qu une éventuelle facturation après utilisation. La couche Connectivité définit les protocoles pour l authentification et les communications à travers la grille. Enfin, la couche la plus basse du modèle, la couche Fabrique représente le niveau le plus proche des ressources physiques. On y trouve par exemples les serveurs, les disques de stockage ou encore le réseau. Remontons maintenant les différentes couches de ce modèle afin de les détailler quelque peu Couche Fabrique La couche Fabrique, la plus basse du modèle, est en charge de fournir les ressources qui seront partagées via la grille. Celles-ci peuvent être : physiques : des processeurs, des disques, des bases de données (de résultats expérimentaux par exemple), le réseau ou encore des capteurs spécialisés (pour relever une température, une pression...) ; logiques : un système de fichiers distribué, une ferme de calcul. Dans le cas des ressources logiques, il est courant qu elles disposent de leurs propres protocoles internes (comme NFS [99] pour un système de fichiers) mais ceux-ci ne concernent pas directement l architecture de la grille.

29 CHAPITRE 3. GRILLES DE CALCUL 21 Lorsqu une couche supérieure fait une requête afin d accéder à une ressource, ce sont les composants de la couche fabrique qui sont en charge d implémenter les opérations spécifiques à cette ressource nécessaire à son partage. La couche fabrique dépend donc fortement des opérations de partage qui doivent pouvoir être effectuées dans les couches supérieures. En pratique, la plupart des ressources doivent fournir des mécanismes permettant de les interroger (afin de connaitre leur structure, état, fonctionnalité...) et de les contrôler. Citons quelques fonctionnalités que doivent implémenter certains grands types de ressources. Ressources de calcul : Il faut évidemment pouvoir démarrer des programmes et récupérer leurs résultats. Pouvoir contrôler les ressources allouées aux processus peut également être intéressant. On doit pouvoir récupérer les caractéristiques du matériel, la charge du système ou encore l état des files d attente. Ressources de stockage : Il doit être possible de déposer et récupérer des fichiers. Pouvoir gérer les ressources allouées lors des transferts de données (bande passante des disques et du réseau, processeur utilisé) peut se révéler utile. Les ressources doivent pouvoir fournir des informations sur leur pourcentage d occupation ou la bande passante utilisée pour les transferts. Ressources réseaux : On doit pouvoir récupérer les caractéristiques du réseau et sa charge. Dépôts de code : Ce type de stockage est spécialisé dans la gestion de programmes et de versions ; par exemples CVS [61] ou Subversion [121]. Catalogues : Cette autre forme de stockage nécessite de pouvoir soumettre des requêtes et effectuer des opérations de mise à jour ; typiquement une base de donnée relationnelle Couche Connectivité La couche Connectivité implémente les principaux protocoles de communication et d authentification nécessaires aux différentes transactions s effectuant à travers la grille. Ces protocoles de communication permettent l échange des données à travers les ressources du niveau fabrique. Les protocoles d authentification s appuient sur les services de communication pour fournir des mécanismes sécurisés de vérification de l identité des utilisateurs et des ressources. Les protocoles de communication réutilisent principalement ceux d Internet : IP pour le réseau, TCP/UDP pour le transport, DNS dans les applications... En dehors des aspects communication, la couche Connectivité a en charge une grande partie de la sécurité du système. Ici encore, l accent a été mis autant que possible sur la réutilisation de protocoles existants. Un autre souci notable est de ne pas rendre la politique sécuritaire de la grille trop contraignante pour les utilisateurs. Parmi les exigences en matière de sécurité, on peut relever quatre points essentiels. Single sign on : les utilisateurs ne doivent s identifier qu une seule fois avant de pouvoir accéder aux différentes ressources de la grille, sans avoir à répéter cette opération par la suite. Délégation : un système doit permettre à un programme de disposer des permissions de l utilisateur qui l a lancé pour pouvoir accéder aux ressources nécessaires, et le cas échéant, que ces permissions soient transmises aux divers composants

30 CHAPITRE 3. GRILLES DE CALCUL 22 appelés par le programme principal. Intégration : la sécurité doit être intégrée aux diverses solutions mises en œuvre sur chaque site distant. Chaque site ou fournisseur de ressources dispose de ses propres outils de sécurité. La sécurité au niveau de la grille doit prendre en compte chacune de ces spécificités et pouvoir s adapter aux contextes locaux. Réseaux de confiance : si un utilisateur fait appel à deux ressources situées sur des sites différents et s il n est accrédité qu auprès d un seul site, le second doit pouvoir l accepter s il fait confiance à la politique de sécurité du premier. Une notion essentielle dans les techniques de sécurité des grilles de calcul est celle d organisation virtuelle. Organisation virtuelle Les ressources d une grille peuvent potentiellement être utilisées par une très large communauté d utilisateurs. Il est donc nécessaire d avoir une politique claire pour la gestion des droits associés aux ressources et à ceux qui peuvent les utiliser. Pour ce faire, on regroupe les utilisateurs en organisations virtuelles (Virtual Organization (VO)). Toutes les personnes appartenant à un même VO ont généralement des droits et besoins communs, typiquement parce qu elles travaillent dans une même discipline. La durée de vie de ces organisations virtuelles peut être variable, ainsi que les buts qu elles poursuivent. Par exemple l organisation becms regroupe les chercheurs belges prenant part à l expérience CMS du CERN. Ainsi, un utilisateur désireux de bénéficier des ressources de la grille doit obtenir un certificat d une autorité de confiance puis le faire enregistrer auprès d un ou plusieurs VO. Ceci fait, il peut alors accéder aux ressources et infrastructures allouées aux organisations dont il est membre : processeurs, espace disque, données et résultats d expériences Couche Ressource La couche Ressource utilise les services des deux couches précédentes (fabrique et connectivité) pour collecter des informations sur les caractéristiques des ressources, les surveiller, les contrôler et gérer une éventuelle facturation quant à leur utilisation. Pour ce faire, elle utilise la couche fabrique qui lui fournit les fonctions nécessaires au contrôle et à la collecte d informations. Les différentes fonctionnalités que nous avons présentées dans la section constituent donc les opérations qui doivent pouvoir être effectuées à partir de la couche Ressource. Les protocoles définis dans la couche Ressource ne concernent les ressources que d un point de vue individuel. Elle ne s intéressera donc qu aux caractéristiques intrinsèques des ressources et à la façon dont celles-ci se comportent. Les tâches relatives à leur partage proprement dit incombent à la couche Collectif, présentée dans la section suivante. On distingue généralement deux grandes classes de protocoles dans la couche Ressource : Les protocoles d informations utilisés pour collecter des données relatives aux ressources. Celles-ci peuvent être statiques (structure et état de la ressource, sa configuration, sa politique de sécurité, son coût éventuel) ou dynamiques comme sa charge à un moment donné. Les protocoles de gestion utilisés pour négocier l accès aux ressources partagées.

31 CHAPITRE 3. GRILLES DE CALCUL 23 On peut ainsi spécifier des conditions d accès aux ressources et exiger par exemple que soient annoncées à l avance les opérations qui seront effectuées : le nombre de processus créés, les différentes données auxquelles on aura besoin d accéder... Ce sont donc ces protocoles qui ont en charge de s assurer que l usage des ressources est en accord avec la politique de partage de son propriétaire. Elle a également en charge le monitoring qui consiste à surveiller certains points sensibles et à faire remonter les alarmes aux couches de niveaux supérieurs qui souhaiteraient être informées d éventuels problèmes Couche Collectif Comme nous l avons vu, la couche Ressource s occupe des ressources d un point de vue individuel. Pour coordonner l ensemble de celles-ci, une vue de plus haut niveau est nécessaire. C est le travail de la couche Collectif. Les services et protocoles décrits dans cette couche ne sont plus associés à une ressource spécifique mais ont une vision globale de celles-ci et se chargent des interactions entre elles. C est donc cette couche qui est responsable de l ordonnancement et de la co-allocation des ressources lorsqu un utilisateur fait appel à plusieurs ressources simultanément. Elle s occupe également de la réplication des données. Enfin, c est également ici que les alarmes de monitoring déclenchées dans la couche Ressource doivent être récupérées et gérées. Une des tâches primordiales effectuées par cette couche est son rôle d annuaire. Il consiste en une base de données répertoriant les différentes ressources ainsi que leurs caractéristiques (fournies par la couche Ressource). Ainsi, lorsqu une application désire utiliser une ressource, le Ressource Broker (parfois traduit par courtier de ressource ) va chercher dans ces annuaires celle qui correspond le mieux aux exigences requises par la tâche. Les annuaires permettent également aux membres d une organisation virtuelle de découvrir les différentes ressources qui sont à leur disposition ou de faire des recherches sur celles-ci selon certaines contraintes. Les critères qui vont influencer le choix des ressources nécessaires à la réalisation d un traitement peuvent être de plusieurs types. L utilisateur qui soumet un job peut définir des contraintes qu il veut voir respecter lors du choix des ressources utilisées pour son travail. Celles-ci peuvent être de nature matérielle (nombre de processeurs disponibles, taille de la mémoire, type d architecture...) ou logicielle (système d exploitation, programme spécifique qui doit être installé). L attribution des ressources doit respecter la politique d utilisation qui leur a été définie par son propriétaire. Ainsi, on peut définir par exemple que seules certaines organisations virtuelles ont le droit de les utiliser ou qu on désire ne mettre à disposition de la grille qu un certain pourcentage de son infrastructure (le reste étant ainsi toujours disponible pour les tâches propres au site). Enfin, l ordonnancement des jobs et l allocation des ressources seront faits, évidemment, dans un souci de maximisation des performances. On essayera donc de choisir un site qui n est pas trop chargé ou qui, par exemple, contient déjà une copie des données nécessaires au traitement, évitant ainsi de devoir les transférer avant de pouvoir commencer les calculs. Notons enfin qu alors que les services des précédentes couches étaient largement déployés sur chaque site, ceux de la couche Collectif, de par le rôle central qu ils jouent, le sont nettement moins. Typiquement, on pourrait disposer d un Ressource Broker par

32 CHAPITRE 3. GRILLES DE CALCUL 24 organisation virtuelle, par domaine de recherche, voire par grille si cette dernière est de taille modeste Couche Application Enfin au sommet du modèle, on retrouve les applications qui seront exécutées sur la grille afin d y récupérer des données ou effectuer des calculs. Les différentes couches seront alors sollicitées. Les couches Collectif et Ressource seront en charge de la recherche des ressources pouvant héberger l exécution de l application. Une fois celles-ci trouvées, la couche Connectivité sera utilisée pour s authentifier et, enfin, la couche Fabrique sera en charge de l accès à proprement parler aux ressources. Comme pour les fermes, on distinguera les applications traditionnelles de celles qui ont été spécialement adaptées ou conçues pour tirer parti des possibilités de la grille. Ainsi ces dernières, parfois appelées grid aware, pourront utiliser des bibliothèques permettant par exemple de récupérer des informations sur les différents catalogues de données disponibles sur la grille et d interagir directement avec elles. Voyons maintenant comment les services que nous venons de décrire dans les différentes couches de notre modèle, se retrouvent implémentés dans le toolkit Globus. 3.5 Globus Malheureusement, il n existe pas à ce jour de standardisation complète au niveau mondial pour les grilles de calcul. Les différents concepts présentés jusqu ici sont suffisamment généraux pour être applicables à la majorité des grilles. Il faut toutefois garder à l esprit que de nombreux aspects, tant du point de vue architectural que de la nomenclature utilisée, peuvent varier selon la grille considérée. Après avoir présenté une modélisation du concept de grille sous forme d un empilement de couches, nous allons nous attarder sur les implémentations existantes des différents concepts que nous avons introduits. Nous tenterons, dans un premier temps, de rester le plus général possible en présentant le toolkit Globus qui est certainement le plus grand dénominateur commun à la majorité des grilles existantes. Nous nous attarderons ensuite dans les chapitres suivants sur les projets de grilles européennes (DataGrid, EGEE...) qui nous concernent plus directement, à travers les intergiciels LCG 2 et, surtout, glite Présentation Le toolkit Globus [77] regroupe une série de briques de bases offrant des solutions à bon nombre de problèmes auxquels on est confronté lors du développement de services pour des grilles de calcul. Les développeurs peuvent ainsi facilement récupérer les services, protocoles et bibliothèques qui les intéressent, leur épargnant ainsi de toujours devoir réinventer la roue et facilitant grandement l interopérabilité entre les grilles. De plus, tout le code de Globus étant sous licence libre et open-source, il peut être facilement réutilisé et adapté selon les besoins de la grille que l on désire déployer. Le développement de ce toolkit s intègre dans le cadre plus large de la Globus Alliance visant à rassembler une communauté de développeurs et utilisateurs des grilles afin de

33 CHAPITRE 3. GRILLES DE CALCUL 25 développer, en plus des différents logiciels et de leur documentation, la recherche autour des technologies grid. L alliance est également un des membres principaux du Global Grid Forum [76] visant à standardiser les différentes technologies impliquées dans les grilles de calcul. Le développement du toolkit a débuté fin des années 90 et en est à ce jour à sa version La principale innovation de cette branche 4.0 est l intégration des services Web. Nous commencerons donc cette section par une présentation succincte de cette technologie. Nous détaillerons ensuite quelques-uns des principaux services qu offre le toolkit Globus. La figure 3.2 reprend une vue synthétique des différents composants de Globus rangés selon les quatre grandes classes de services que fournit le toolkit : sécurité, gestion des données, gestion des jobs, information : découverte des services et ressources. FIG. 3.2 Globus Toolkit version 4 [77]

34 CHAPITRE 3. GRILLES DE CALCUL Les services Web Avec sa version 4.0, Globus est rentré dans l ère des services Web. Cette technologie, en pleine expansion, offre une méthode simple, souple et portable d échanges d informations entre des applications au travers d un réseau. À l instar de Corba [60] ou RMI 1 [113], les services Web permettent l invocation de méthodes ou fonctions situées sur une autre machine que celle qui effectue l appel. La principale différence avec ces deux autres technologies est que les services Web utilisent principalement le protocole HTTP pour les transferts réseaux (ils se révèlent donc être particulièrement adaptés pour être utilisés à travers Internet) et se veulent entièrement indépendants de tout langage et de toute plate-forme. Ainsi on peut imaginer qu un client écrit en Python [109] et tournant sous Microsoft Windows interroge un serveur de services Web en Java sous GNU/Linux. Web Services Protocol Stack Les services web utilisent une collection de standards regroupés sous le nom de Web Services Protocol Stack. On y retrouve entre autres : XML [142] : utilisé pour encoder les différentes informations échangées entre le serveur et les clients. XML-RPC [143] ou SOAP (Simple Object Access Protocol) [120] (le plus populaire) : pour transformer les appels de fonctions et leurs résultats en XML. HTTP, FTP, SMTP, XMPP 2 [144] pour faire transiter les informations sur le réseau. WSDL (Web Services Description Language) [136] : ce format permet de décrire en XML l interface publique du service Web. Cela permet ainsi au client de découvrir quelles sont les méthodes qu il peut utiliser et comment il doit les appeler. UDDI (Universal Description Discovery and Integration) pour découvrir et rechercher des services Web. Un annuaire UDDI contient une description XML des différents services Web disponibles sur le réseau. On peut alors l interroger pour retrouver un service précis ou effectuer une recherche selon certains critères. WS-Security pour s assurer de la confidentialité et de l intégrité des transferts. Illustration Afin de fixer les idées, considérons un exemple simple d un client désireux de trouver et interroger un service web de prédiction météorologique [43]. La figure 3.3 schématise les différents échanges entre le client et les serveurs. 1. Le client ne connait pas l adresse du service Web de météorologie. Il va donc interroger un annuaire (qui est lui-même un service Web) pour lui demander s il possède un service de météo dans sa base de données. 2. Le serveur lui répond en lui indiquant que le serveur B possède un tel service. Cette transaction s est effectuée en utilisant le protocole UDDI. 3. Le client n a aucune idée de la façon d interagir avec le serveur pour profiter du service qu il offre (une prévision météorologique dans notre exemple). Il va donc l interroger à ce sujet. 1 interface Java permettant l appel de méthodes sur des objets distants 2 protocole de messagerie instantanée basé sur XML

35 CHAPITRE 3. GRILLES DE CALCUL 27 FIG. 3.3 Échange entre le client et le service web : de la découverte du service à son invocation [43] 4. Le serveur répond en WSDL en lui spécifiant le prototype de la méthode : string getweatherinfo (int citypostalcode). 5. Le programmeur sait maintenant comment invoquer le service. Le client envoie donc une requête SOAP pour ce faire. 6. Le serveur répond, toujours en SOAP, en renvoyant le résultat de la méthode. Parmi les avantages des services Web, citons : Ils sont basés sur des protocoles ouverts et standardisés (ou en passe de l être) au W3C [135]. Comme nous l avons vu dans l exemple ci-dessus, les services Web sont capables de se décrire eux-mêmes (self-describing). Ainsi une fois un service localisé, on peut lui demander de se décrire afin de récupérer les différentes opérations possibles et la manière dont on peut les invoquer. La grande majorité des services utilisent HTTP pour les transferts (même si d autres protocoles peuvent être utilisés). Cela s avère très pratique pour leur déploiement à travers Internet, la majorité des pare-feu laissant passer le port HTTP (80) ; au contraire de CORBA 3 qui peut éprouver des difficultés à ce niveau. Les services Web assurent l interopérabilité entre des systèmes pouvant fonctionner sur des environnement très hétérogènes. 3 architecture logicielle permettant la création de composants pouvant communiquer tout en étant exécutés sur des machines distinctes

36 CHAPITRE 3. GRILLES DE CALCUL Architecture du toolkit Comme nous l avons vu, les services Web sont particulièrement bien adaptés à une utilisation sur Internet. Il reste toutefois un problème de taille à régler avant de pouvoir les utiliser dans le cadre des grilles : la persistance des données. En effet, les services Web ne permettent pas de conserver un contexte d exécution entre deux invocations successives d une méthode. Si cela ne pose pas de problème dans le cadre de service simple comme celui présenté en exemple, cela devient beaucoup plus problématique si l on désire construire une application pour une grille. En effet, imaginons que l on soumet un job pour exécution via un service Web. Il serait légitime d espérer pouvoir interroger le serveur afin de connaitre l évolution du job au fil du temps. Pour ce faire, le service Web doit pouvoir conserver des informations au fil des appels successifs du client. Pour remédier à ce problème, Globus a développé le Web Services Resource Framework (WSRF) [137]. Il introduit la notion de Ressource, à ne pas confondre avec les ressources physiques ou logiques de la grille que nous avons vues jusqu ici, qui stockent un contexte d exécution. Celui-ci, se présente sous la forme d un ensemble de variables, possède un identifiant unique et est préservé entre les appels. Ainsi, lors de l invocation d une méthode, il suffit de passer au service Web l identifiant de la ressource que l on désire utiliser et celui-ci pourra retrouver les valeurs des variables qu elle contient. L association d un service Web avec une ressource est appelée une WS-Ressource. Le WSRF définit une série de spécifications permettant la manipulation aisée des WS- Ressource évitant d avoir à gérer manuellement l identifiant de la ressource avec laquelle on travaille. La figure 3.4 illustre un service possédant trois ressources de type fichier, chaque fichier possédant trois propriétés (appelées WS-ResourceProperties). FIG. 3.4 WS-Ressource [43] En plus des différents services que nous allons présenter dans la suite, le toolkit Globus offre, comme l illustre la figure 3.5, des conteneurs permettant aux développeurs d implémenter aisément leurs propres services en langage C, Java ou Python. Ils peuvent ainsi bénéficier des facilités offertes par Globus en matière de sécurité, persistance de données (via les WS-Ressources) ou découverte de services. Globus fournit également un ensemble de bibliothèques permettant aux clients d invoquer facilement, toujours en C,

37 CHAPITRE 3. GRILLES DE CALCUL 29 Java ou Python, les fonctionnalités des services que ce soient ceux fournis avec Globus ou ceux développés par l utilisateur. Enfin, le toolkit dispose d une série d interfaces en lignes de commande permettant d interagir directement avec les différents services. FIG. 3.5 Vue Client/Serveur de l architecture de Globus 4 [20] Voyons maintenant les quatre grandes classes de services offerts par le toolkit Globus. Sécurité Globus a développé un ensemble de protocoles nommés Grid Security Infrastructure (GSI) basés sur une architecture à chiffrement asymétrique (paire clé publique/ clé privée). Ils sont utilisés pour l authentification, la confidentialité des communications ainsi que pour l identification. GSI répond à la majorité des contraintes décrites en telles que l identification unique (single sign on), la délégation de permissions, l intégration avec divers outils de sécurité locaux (tels que Kerberos 4 [84] par exemple)... Les utilisateurs et machines sont identifiés à l aide d un certificat au format X.509 [138]. Ce dernier contient : des informations sur le propriétaire du certificat : nom, institut... la clé publique associée au certificat, l autorité de confiance qui assure que le propriétaire du certificat est bien celui qu il dit être, la signature de l autorité de confiance en question. Une clé privée, protégée par un mot de passe, est également associée au certificat. Pour répondre aux problèmes de délégation de droits et d identification unique, on utilise la notion de proxy d authentification. Un proxy est très similaire à un certificat X.509 à quelques différences près. Il est associé à une nouvelle paire de clés (privée et publique). L identité du propriétaire est quelque peu modifée pour indiquer que le certificat est un proxy et non un certificat classique. Ce nouveau certificat est signé par l utilisateur lui-même et non plus par l autorité de certification. 4 protocole d authentification à chiffrement asymétrique développé au MIT

38 CHAPITRE 3. GRILLES DE CALCUL 30 FIG. 3.6 Architecture du GSI [21] Il a une durée de validité assez courte, typiquement de l ordre d une dizaine d heures. La clé privée du proxy ne doit être connue que par les deux entités se l échangeant mais, de par la durée de vie limitée de celui-ci, elle est moins sensible que celle du certificat et n est donc pas protégée par mot de passe. Imaginons maintenant qu Alice veuille s identifier auprès de Bob afin de, par exemple, lui demander d effectuer une tâche. Alice va alors générer un proxy associé à son certificat ; pour ce faire, elle aura besoin d entrer son mot de passe afin de débloquer la clé privée de son certificat. La paire de clés associées à ce proxy sera choisie d un commun accord entre Bob et Alice. Ceci fait, Alice envoie à Bob son certificat ainsi que son proxy fraichement créé. Afin de s assurer qu Alice est bien celle qu elle prétend être, Bob va d abord vérifier, à l aide de la clé publique du certificat d Alice, que le proxy a bien été signé par cette dernière. Ensuite, il vérifie que la signature du certificat a bien été effectuée par l autorité de confiance (Alice et Bob s étant mis d accord au préalable sur une autorité de confiance, ils possèdent tous les deux la clé publique de cette autorité). Imaginons maintenant que la tâche que Bob est en train d effectuer pour Alice est telle qu il aimerait déléguer une sous-tâche de celle-ci à Charles. Charles ne connait pas Bob et n a donc aucune envie de travailler pour lui mais est, en revanche, un bon ami d Alice et est prêt à l aider avec plaisir. Bob doit donc prouver à Charles que la tâche qu il lui demande d exécuter est faite pour le compte d Alice. Pour ce faire, il suffit que Bob transfère le proxy à Charles. Celui-ci étant signé par Alice et, Bob possédant la clé privée associée au proxy, Charles est assuré qu Alice a bien autorisé Bob à travailler pour son compte. Parmi les inconvénients de cette méthode, signalons le fait que Bob peut potentiellement abuser du proxy et l utiliser à d autres fins que celles de servir Alice. Pour limiter ce problème, on peut restreindre le champ d action du proxy en spécifiant par exemple le type de ressource pour lequel il peut être utilisé. De plus, le proxy ayant une durée de validité relativement réduite, Bob ne pourra pas en abuser bien longtemps. Sans proxy, l utilisateur devrait s identifier auprès de chaque ressource utilisée alors

39 CHAPITRE 3. GRILLES DE CALCUL 31 qu ici il suffit de le faire une fois lors de la génération du proxy. Signalons enfin que le proxy ayant une durée de validité limitée, les conséquences au niveau sécurité sont moins problématiques si celui-ci est compromis que si l on utilisait directement le certificat de l utilisateur, qui possède généralement une durée de vie beaucoup plus longue (typiquement un an). La GSI de Globus fournit également une interface de contrôle nommée Generic Authorization and Access (GAA) permettant au propriétaire d une ressource de définir sa politique de sécurité locale. Gestion des données On y retrouve des services pour la localisation, le transfert et la gestion de données distribuées. Pour le transfert de données, Globus a développé une extension du bien connu File Transfer Protocol (FTP) nommée GridFTP. Elle y ajoute entre autres des fonctionnalités de la couche connectivité en terme de sécurité (authentification via la GSI) ou encore la gestion de transferts en parallèles sur plusieurs canaux pour accélérer les débits. La gestion des données distribuées est assurée, entre autres, par le Replica Location Service (RLS) qui enregistre dans un catalogue, les différentes localisations d un fichier afin d en retrouver les réplicas. Le RLS peut être distribué sur plusieurs serveurs distants afin d augmenter sa capacité et, surtout, d éviter d avoir un seul serveur centralisé qui mettrait à mal la gestion des données de la grille en cas de dysfonctionnement. Enfin, il est important de noter que les fichiers stockés sur la grille suivent le principe du write once, read many. Ce qui signifie qu une fois créé, un fichier est accédé uniquement en lecture et plus en écriture. Cela évite ainsi d avoir à gérer la synchronisation d un fichier avec ses différents réplicas et évite des problèmes en cas d accès simultané à un même fichier. En pratique, cette limitation n est pas aussi contraignante que ce que l on pourrait être tenté de croire au premier abord. En effet, la majorité des données stockées sur une grille sont typiquement des relevés physiques ou des résultats expérimentaux (comme dans le cas du LHC par exemple). Dès lors, modifier ces données expérimentales n a finalement pas beaucoup de sens. Gestion des jobs Lorsque l on désire effectuer une tâche sur un ordinateur, il est nécessaire d acquérir un accès à ce dernier, de le configurer pour qu il puisse satisfaire nos besoins, d y installer un exécutable, de démarrer et surveiller son exécution et, enfin, de récupérer les résultats. Le service Grid Ressource Allocation and Management de Globus (GRAM) fournit une interface au travers de services Web pour effectuer ces étapes sur des ordinateurs distants. Cette interface permet au client de spécifier des contraintes telles que les ressources désirées, le programme à exécuter ainsi que ses arguments... Elle permet également de recevoir des notifications lors des changements de statuts du processus. GRAM peut s interfacer avec plusieurs systèmes de gestion de processus allant des simples fork UNIX à des ordonnanceurs de jobs tels que LSF [91], PBS [104], Condor [59]. Ainsi, il faut bien comprendre que GRAM n est pas un ordonnanceur de job mais bien une couche d abstraction permettant de communiquer avec une série d ordonnanceurs

40 CHAPITRE 3. GRILLES DE CALCUL 32 existants. Le cas du fork Unix est un peu particulier, le job étant alors simplement exécuté en créant un processus sur la machine où il a été soumis. Comme pour les fermes, les processus d une grille peuvent être amenés à devoir communiquer entre eux lors de leur exécution (dans le cas de parallélisme fonctionnel, voir chapitre 2.5). Si ceux-ci sont exécutés sur un même cluster, il n y a, a priori, pas de problème, les processus pouvant réutiliser les fonctionnalités de la ferme pour ce faire. Cela devient toutefois beaucoup plus complexe lorsqu une même tâche possède des processus répartis sur différents sites de la grille. Bien que ce type d applications est encore peu courant, il est indispensable de rendre, à terme, la communication entre ces processus possible si l on désire pouvoir faire face à la complexité croissante des problèmes et profiter de toute la puissance de la grille pour les résoudre. Le projet MPICH-G2 [95] est une implémentation du standard MPI intégrant le support des grilles. Il utilise différents services de Globus et permet d exécuter des applications MPI en convertissant automatiquement les communications entre processus en transferts TCP pour les communications inter-site ou en utilisant l implémentation MPI de la ferme, s il y en a une disponible, pour les communications intra-site. Toutefois, si les processus sont situés sur des sites distincts, les temps de latences lors des communications sont bien évidemment relativement conséquents par rapport à une exécution sur une même ferme. Il peut alors devenir important d en tenir compte lorsqu on conçoit ses algorithmes ou applications afin de ne pas subir une trop grande dégradation des performances. Découverte de services et ressources La dernière grande catégorie de fonctionnalités que fournit le toolkit concerne la surveillance ainsi que la découverte des services et ressources. Leur but est de pouvoir récupérer, distribuer et collecter des informations relatives aux différents services et ressources disponibles sur la grille. La finalité de cette collecte d informations peut être soit la découverte des infrastructures qui sont à notre disposition, soit la surveillance de ces dernières. Le composant Globus en charge de ces tâches est nommé Monitoring and Discovery System (MDS). C est, par exemple, ce service qui sera utilisé par GRAM, que nous avons présenté à la section précédente, pour trouver les ressources pouvant satisfaire les contraintes d un job. Que ce soit la surveillance ou la recherche de ressources, ces deux tâches nécessitent la collecte d informations pouvant émaner de multiples sources. Pour ce faire, MDS dispose de services d agrégation en charge de la collecte de données auprès des différentes ressources enregistrées. Ils fournissent également des interfaces et outils en ligne de commande permettant à l utilisateur d accéder et d effectuer des recherches parmi ces informations. 3.6 Les grilles en pratique Enfin, pour terminer ce chapitre d introduction aux grilles de calcul, voyons maintenant quelques exemples de grilles existantes.

41 CHAPITRE 3. GRILLES DE CALCUL Les grilles de calcul en Belgique BEgrid BEgrid [51] est la principale grille en Belgique. Elle est née en février 2003 sous l impulsion de BELNET [53], le réseau national belge de la recherche. Ses buts sont de promouvoir les technologies des grilles de calcul au sein de la communauté scientifique belge et d offrir les services de base permettant l émergence d une infrastructure grid en Belgique. BELNET fait partie de EUGridPMA (European Policy Management Authority for Grid Authentication in e-science), faisant ainsi de BELNET l autorité de certification belge reconnue au niveau des projets de grille de calcul européen. BEgrid possède actuellement 3 teraoctets de stockage et 330 processeurs répartis entre les différents partenaires du projet : BELNET [53], le Cetic [57], la Faculté Polytechnique de Mons [73], la KULeuven [85] (34 CPUs), l Universiteit Antwerpen [126] (77 CPUs), UGent [127] (93 CPUs), Vliz [133] (4 CPUs) et enfin l IIHE [81] (115 CPUS). L IIHE possède environ 1,2 des 3 teraoctets de stockage, le reste se trouvant principalement à la Vlaams instituut voor de zee (Vliz). La FPMS et le Cetic étant toujours en phase de test, leurs ressources ne sont pas encore comptabilisées. L infrastructure de BEgrid est utilisée dans de nombreux domaines de recherche tels que la physique quantique, la physique des hautes énergies, l analyse numérique, la mécanique des fluides, la conception de processeurs... Enfin, BEgrid a établi des connections avec d autres grilles telles que la DutchGrid [64] ou la grille européenne du projet EGEE que nous présenterons plus en détail dans la section Belgrid Citons également Belgrid [52] la seconde grille belge, indépendante de BEgrid. Les parternaires académiques du projet sont la Faculté Universitaire des Sciences Agronomiques de Gembloux [71], les Facultés Universitaires Notre-Dame de la Paix [72], l Université Catholique de Louvain [128], l Université Libre de Bruxelles [131] (via l IIHE), l Université de Liège [129] et l Université de Mons-Hainaut [130]. Signalons en outre que Belgrid bénéficie également de partenaires privés. Malheureusement, le projet semble à l abandon depuis maintenant un an Les grilles de calcul en Europe L Union Européenne a financé une série de projets visant à développer une architecture grid haute performance au sein de l Union Européenne. Nous présenterons ici les principaux projets qui ont joué un rôle déterminant dans le développement des grilles de calcul chez nous, en Europe et ailleurs. European DataGrid Le premier de ces projets, nommé European DataGrid (EDG) [70] et ayant bénéficié d un financement de 9,8 millions d euros, a démarré en 2001 pour s achever en mars Ce projet, mené par le CERN, avait pour but le développement d outils et technologies permettant le déploiement d une grille de calcul à l échelle européenne.

42 CHAPITRE 3. GRILLES DE CALCUL 34 Cette grille avait pour but de répondre aux besoins sans cesse croissants de trois domaines scientifiques excessivement demandeurs de puissance et de stockage que sont la physique des particules, la biomédecine (qui reprend la biologie moléculaire et l imagerie médicale) et l observation terrestre. Le projet EDG a permis le développement de nouveaux outils, basés sur la version 2 du toolkit Globus, regroupés sous le nom de middleware ou intergiciel LCG. Nous présenterons plus en détail LCG 2 dans le chapitre 5. En mars 2004, le projet EDG a été clôturé pour laisser la place à un nouveau projet encore plus ambitieux : EGEE. EGEE Le projet EGEE (Enabling Grids for E-sciencE) [67] a pour but de poursuivre le travail effectué avec EDG tout en étendant son ampleur géographique et scientifique. Ainsi, bien qu il soit financé à raison de 30 millions d euros par la Commission Européenne, il s étend maintenant sur plus de 30 pays, et reçoit d importantes contributions de la part de la Russie, des États-Unis ainsi que d autres partenaires hors Union Européenne. EGEE est donc bien un projet à l échelle mondiale. La grille EGEE contient actuellement quelque processeurs et 5 petaoctets d espace disque. Un des objectifs de EGEE est d ouvrir les infrastructures de la grille à la majorité des disciplines scientifiques. Il étend ainsi le champ des applications possibles de la grille à des domaines allant de la géologie à la chimie. Pour des raisons pratiques, deux domaines pilotes ont été sélectionnés afin de guider et tester l infrastructure en cours de développement. Il s agit de la physique des particules dans le cadre des expériences du LHC et les applications biomédicales comme par exemples le regroupement, l indexation et le traitement de données provenant de divers hôpitaux. Le projet EGEE utilise toujours actuellement LCG 2 mais développe parallèlement son successeur : glite. La majorité de ce travail portant sur ce nouvel intergiciel, il en sera évidemment abondamment question dans les prochains chapitres.

43 Chapitre 4 Quattor : installation et gestion de profils 4.1 Introduction Les fermes de calcul sont souvent amenées à utiliser un grand nombre de machines. Ainsi, il n est pas rare de trouver sur un même site plusieurs centaines, voire plusieurs milliers de nœuds qui diffèrent tant du point de vue de leur configuration matérielle que dans les fonctionnalités qu ils assurent au sein de la grille. Très vite s est posé le problème de l installation et la maintenance d une telle infrastructure. En effet, si on peut envisager d installer et configurer chaque nœud individuellement si l on ne possède que quelques machines, cela devient très vite ingérable dès que leur nombre augmente, ce qui est indispensable si on veut faire rentrer le site en production et l intégrer à une grille. Dans ce chapitre, nous décrirons brièvement les différents problèmes auxquels on est confronté lorsque l on désire gérer une ferme de calcul. Nous présenterons ensuite le logiciel Quattor qui fournit une solution élégante pour les problèmes d installations, maintenance et configurations des logiciels. Enfin, nous terminerons en introduisant brièvement des améliorations et utilisations de Quattor sur lesquelles travaille l IIHE. 4.2 La gestion de fermes de calcul Quelle que soit la tâche de la ferme de calcul, on retrouve une série de besoins communs à la grande majorité des sites. Installation Installation du système de base (OS). Installation des logiciels additionnels et gestion des mises à jour. Configuration : paramétrages des logiciels, applications à installer, etc. Monitoring : surveiller les différents nœuds de la ferme. Inventaire : regrouper des informations diverses sur les différents éléments qui composent la ferme. Détaillons maintenant quelques-uns de ces points. 35

44 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS Installation du système d exploitation L installation du système d exploitation est une opération très importante dans une ferme de calcul. Ces installations peuvent être assez fréquentes si l on rajoute régulièrement de nouveaux nœuds (pour cause d agrandissement de la ferme ou de remplacement de machines défectueuses), si les nœuds sont susceptibles de changer régulièrement de fonction ou si l on effectue une réinstallation pour procéder à une mise à jour du système. La plupart des systèmes d exploitation fournissent des outils et procédures afin de minimiser autant que possible l intervention de l administrateur lors de l installation du système. Cela offre donc une bonne base pour un système d installation automatisée. Le démarrage de l installation peut être amorcé par un mécanisme de boot réseau (PXE [108], etherboot [68]), évitant ainsi l utilisation d une disquette ou CD de démarrage et permettant une installation complète sans que l administrateur n ait à avoir de contact physique avec la machine Programmes additionnels L installation des applications suit celle de l OS. La majorité de ces logiciels sont chargés d effectuer les tâches propres au nœud. Contrairement à l installation du système, cette phase est en évolution constante. Il est en effet nécessaire de s assurer que les mises à jour apportant des corrections de bugs et, surtout, de sécurité soient appliquées aussi rapidement que possible. Ici aussi la plupart des systèmes d exploitation nous fournissent des outils pour faciliter l installation et la mise à jour des logiciels : le packaging. Le packaging fournit une interface simple permettant de distribuer des programmes sous leur forme binaire, ainsi que de les installer, de les supprimer et d effectuer leurs mises à jour aisément. Un package, ou paquet, fournit, en plus de ses fichiers, une multitude d informations fonctionnelles (instructions d installation, dépendances...) et administratives (auteurs, descriptions, versions...) sur le logiciel. Le gestionnaire de paquets tient également un registre, côté client, sur les différents logiciels installés, leurs versions, etc. Les paquets sont généralement stockés côté serveur dans un dépôt de logiciels (softwares repository). Ce dépôt organise les paquets selon une structure et une logique propre à la distribution afin de permettre aux divers outils d interagir avec lui. Parmi les systèmes de paquets les plus connus, citons RPM (RedHat Package Manager) [112] ou encore les fichiersdeb de Debian [63]. Tous ces avantages font du packaging, un outil indispensable pour les installations automatisées Configuration Les informations relatives à la configuration du système interviennent à différents niveaux. L installeur de l OS a besoin de toute une série d informations sur le système qu il doit installer. Bien que la plupart de celles-ci soient détectées automatiquement (principalement la configuration matérielle), certaines informations doivent normalement être rentrées par l utilisateur lors de l installation (langue, configuration du clavier, paramètres régionaux...). Notre but étant de minimiser autant que pos-

45 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS 37 sible les interactions physiques avec la machine, le framework doit être capable de récupérer ces informations automatiquement. Une fois la base du système d exploitation installée, on peut passer à la mise en place des applications (souvent distribuées sous forme de paquets). Les applications à installer dépendent de la fonction que l on veut assigner au nœud au sein de la ferme. Pour chaque type de configuration, l administrateur crée une liste de paquets à installer. Ce système permet une grande souplesse et une gestion aisée des programmes installés sur les nœuds de la ferme. Si une différence est détectée entre la liste et les paquets effectivement installés sur le système, celui-ci se resynchronise automatiquement sur la liste en ajoutant ou supprimant les paquets nécessaires. L installation d un nouveau paquet sur une catégorie de nœuds peut donc se faire en l ajoutant simplement dans la liste associée à cette catégorie. De même, cela nous protège contre l installation de paquets non désirés sur les machines. Les applications, une fois installées, nécessitent une configuration propre, dépendant du site dans lequel elles sont déployées (adresses des différents serveurs...) L outil de gestion et d installation doit permettre de spécifier ces paramètres Stockage des configurations La manière dont sont stockées les informations de configuration est une caractéristique fondamentale des outils de gestion automatique de fermes de calcul. La solution la plus classique consiste à stocker les paramètres de configuration de façon centralisée. Les nœuds vont alors chercher ces informations lors de l installation et plus tard lorsqu ils en ont besoin pour la configuration d une application. Une solution simple est de stocker tous les fichiers de configuration dans un répertoire accessible par tous les nœuds. Cependant, beaucoup de ces fichiers de configuration contiennent des informations spécifiques à chaque nœud (MAC, IP, etc). Il faut donc dupliquer ces fichiers de configuration de sorte d en avoir un par nœud de la ferme. Cette solution offre un manque évident de souplesse, tous les fichiers devant être modifiés manuellement dès que l on désire modifier un paramètre commun à tous les nœuds. Il est donc nécessaire de trouver une solution plus adaptée à la gestion des fermes de taille plus importante. Les fichiers de configuration des applications ayant des formats différents, une syntaxe unifiée doit être définie afin de pouvoir associer des paires clévaleurs aux différentes options de configuration des applications. Ces paires permettent de créer des structures plus complexes et de décrire les fichiers de configuration des applications. Dans la majorité des cas, une base de données de type SQL est utilisée pour ce faire. On peut également trouver des dépôts spécifiques développés dans ce but comme nous le verrons plus tard lors de l étude de Quattor (voir section 4.3) Transfert des configurations Une fois les configurations stockées, il faut définir la façon dont celles-ci seront transférées vers les nœuds. Une solution simple est de mettre les fichiers de configuration à disposition des nœuds via un partage NFS (Network File System) [99]. Les clients peuvent alors directement utiliser ces fichiers via le réseau. Cette solution facile à mettre en place souffre cependant de plusieurs défauts tels que son peu de tolérance aux problèmes réseaux ou le fait qu elle

46 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS 38 se révèle être particulièrement inadaptée si beaucoup de clients doivent se connecter au serveur (surcharge du réseau). Une autre solution, très populaire actuellement, est l utilisation du format XML [142] pour les transferts de configuration. Ce format se révèle en effet particulièrement bien adapté pour l encapsulation de données. De plus, l abondance de bibliothèques XML disponibles, rendent sa manipulation très aisée pour le programmeur. Un autre avantage de XML est qu il est très facile de le transférer par le protocole HTTP. Ainsi, aucun outil spécifique ne doit être développé pour permettre l accès web aux configurations ; il suffit de posséder un serveur HTTP. Cela permet également d utiliser les facilités offertes par le protocole HTTPS (contrôle d accès, certificats, etc) si l on désire sécuriser les transferts de configuration. En résumé, les informations sont stockées sur le serveur (base de données, format de fichier dédié, etc), transformées en XML et envoyées vers le client qui les utilisera pour générer les différents fichiers de configuration des applications Gestion des profils Les différents nœuds d un site ont souvent de nombreuses similitudes qu elles soient matérielles (architecture de la machine, type de carte réseau, taille de la mémoire, etc) ou logicielles (même système d exploitation, même rôle du nœud au sein du site, etc) mais aussi des caractéristiques qui leur sont propres (adresse mac, nom de la machine, etc). Les profils fournissent une méthode élégante et efficace pour gérer ces similitudes et différences. Un profil regroupe des caractéristiques communes à plusieurs nœuds. Ainsi, par exemple, on pourrait avoir un profil par type de machine. Dès lors, toute la configuration et les caractéristiques d un nœud se retrouvent dans son profil lui-même composé de différents profils génériques ainsi que des paramètres spécifiques au nœud. On peut voir cela comme une forme d héritage à l instar de celle utilisée dans le paradigme objet en programmation. 4.3 Présentation de Quattor Quattor (QUattor is an Administration ToolkiT for Optimizing Resources) est un toolkit d administration système permettant l installation, la configuration et la gestion des applications pour des clusters et fermes de calcul tournant sous des dérivés d UNIX tels que Linux et Solaris. Le développement de Quattor est coordonné par le CERN en collaboration avec d autres instituts dans le cadre du projet ELFms (Extremely Large Fabric management system) [66] visant à fournir des outils de qualité professionnelle pour la gestion de parcs informatiques pouvant contenir un nombre très important de nœuds aux matériels et fonctionnalités hétérogènes (serveurs de disques, nœuds de calcul, etc). ELFms est composé des 3 sous-sytèmes suivants : le framework de monitoring Lemon [88], le toolkit d installation et configuration Quattor [110], le gestionnaire de matériel et d état Leaf [87]. Quattor, ainsi que les autres logiciels de la suite ELFms, est distribué gratuitement selon les termes de la licence open-source EU DataGrid software license [69].

47 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS 39 Le framework Quattor s occupe de deux grandes tâches que sont le Configuration Management et le Node and Cluster Management. La première comprend l accès, la gestion et les interactions avec la Configuration Database (CDB) et les templates qui y sont stockés. Elle englobe également le système de cache des configurations du côté des clients. Le Node and Cluster Management comprend la façon dont les informations sont transmises et déployées sur les nœuds. On y retrouve également la gestion des applications installées. Du côté client, cela comprend les Configuration components chargés de s assurer que les configurations soient bien mises à jour après chaque modification. Ils font partie du sous-système Node Configuration Management (NCM) en charge de tous les aspects de la gestion des configurations. Le Software Package Management Agent (SPMA) s occupe d ajuster les paquets installés sur un nœud selon sa liste de paquets. Pour ce faire, il interagit avec le Software repository. Les sections suivantes exploreront plus en détail les différents sous-systèmes composant l architecture de Quattor. La figure 4.1 reprend une vue d ensemble de cette architecture. Server side Client side CONFIGURATION SERVER CDB XML profiles HTTP NODE NCM download profile Configuration cdispd INSTALL SERVER CCM Vendor System Installer Install Manager AII NFS HTTP DHCP PXE Base OS CCM NCD Software Installation/Update SPMA Component Component SPM Component SPMA.cfg SOFTWARE SERVER download RPM, PKG packages SWRep FIG. 4.1 Architecture de Quattor [31]

48 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS Configuration Management Quattor est basé sur la différence entre l état de configuration désiré et l état de configuration actuel d un nœud. L état désiré est stocké dans la Configuration Database (CDB). Un langage dédié à la description et la validation des configurations, appelé PAN, est utilisé pour ce faire. Les configurations sont composées de blocs réutilisables agencés de façon hiérarchique nommés templates. Un fois validées, les configurations sont compilées en profils XML et envoyées au Configuration Cache Manager (CCM) des clients qui en gardent une copie locale en cache. Voyons maintenant plus en détail les différents composants du Configuration Management Le langage PAN Un des principaux atouts de Quattor est son langage PAN permettant une grande souplesse dans les descriptions des configurations tout en restant clair et facilement compréhensible. Pan est un High Level Definition Language (HLDL). Il permet la déclaration de templates de configuration, de profils et de variables et fournit un Data Manipulation Language permettant d effectuer des modifications sur les données stockées. Les définitions de templates en PAN seront compilées pour être transformées en profils XML. Les différentes caractéristiques sont représentées syntaxiquement sous forme de variables de configuration se présentant sous une forme arborescente. À un niveau supérieur, nous trouvons les templates et les profiles. Les profiles contiennent la configuration d une certaine ressource en suivant une définition formelle décrite dans les templates. L utilisation des templates et profiles permet de regrouper un maximum d informations et donc d éviter les redondances dans les descriptions des configurations du site. Afin de fixer les idées, considérons quelques exemples. Les variables de configuration sont défines sous forme de chemins tels que : "/hardware/devices/eth0/hwaddr" = "00:09:3D:10:D7:23"; Cette représentation nous permet donc de grouper des informations selon une hiérarchie bien définie, à l instar de celle qu on trouve pour les systèmes de fichiers. Le langage PAN dispose de types de bases (booléen, long, string, etc) chacun disposant d opérateurs et de fonctions de test. Ainsi les types des données sont vérifiés à la compilation afin d éviter des assignations illégales ou autres problèmes de ce type. Cela nous assure une protection contre la corruption de la Configuration Database avec des templates incohérents. Le langage fournit également des types tels que les enregistrements, les tableaux ou encore les listes. À l aide de ces briques de base, on peut aisément définir des types plus complexes tels que, par exemple, un enregistrement d un CPU : define type cpu_type = { "vendor": string

49 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS 41 "model": string "speed": double } On utilise souvent les listes pour faciliter la déclaration de plusieurs ressources similaires : structure template pro_hardware_cpu_amd_opteron_1600; "vendor"="amd"; "model" = "AMD Opteron(TM) CPU 1.6 GHz"; "speed" = 1600; structure template pro_hardware_machine_200_48_ibm_09; "location" = "200_48_ibm_09"; "serialnumber" = "kdnwa3z"; "/hardware/cpu" = list( create("pro_hardware_cpu_amd_opteron_1600"), create("pro_hardware_cpu_amd_opteron_1600")); [...] Cela nous donnera comme résultat après compilation : "/hardware/cpu/0/vendor" = "AMD"; "/hardware/cpu/0/model" = "AMD Opteron(TM) CPU 1.6 GHz"; "/hardware/cpu/0/speed" = 1600; "/hardware/cpu/1/vendor" = "AMD"; "/hardware/cpu/1/model" = "AMD Opteron(TM) CPU 1.6 GHz"; "/hardware/cpu/1/speed" = 1600; Pour plus d informations sur Pan, consultez [17] et [36] Configuration Database Les différents templates et profiles Pan sont stockés dans la Configuration Database (CDB). Contrairement à ce que l on pourrait croire, ce n est pas une base de données classique mais un dérivé de CVS [61] pour stocker les différents fichiers Pan. Les informations stockées dans CDB sont nombreuses et variées. Citons : les paramètres matériels (CPU, carte réseau, mémoire, etc) utilisés pour la configuration de l installeur (KickStart). Notons que cela peut également s avérer utile si l on désire établir un inventaire des différentes ressources informatiques disponibles sur le site ; des paramètres additionnels pour l installeur tels que la table des partitions, la configuration réseau, les paramètres régionaux, etc ; les différents logiciels à installer sur les machines et leurs configurations ; la topologie du site ainsi que les rôles joués par les différentes machines du réseau. Comme expliqué précédemment, la syntaxe des fichiers sources Pan est vérifiée lors de la compilation. Cette vérification a lieu lors de l upload vers CDB mais, à ce moment, le

50 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS 42 contenu du fichier ne fait pas encore vraiment partie des informations stockées. Ce n est que lorsque l utilisateur aura ordonné le commit que le fichier sera effectivement intégré. Un profil XML est généré lors de la compilation de son template ainsi que les différents fichiers qu il inclut. Tous les templates sont vérifiés afin de détecter d éventuelles incohérences et, après cette vérification syntaxique, les nouveaux profils XML sont générés. Lorsqu un changement de profil est commité sur la CDB, une notification est envoyée au client afin de l informer du changement du profil. Il pourra ainsi prendre les mesures nécessaires afin de se conformer au nouveau profil (voir plus loin). CDB étant basé sur CVS, il offre les mêmes services que ce dernier en matière de gestion de versions, de branches et de retour à des versions antérieures Configuration Cache Manager Le Configuration Cache Manager (CCM) a pour mission de stocker en local le dernier profil XML de la machine. Le CCM joue un rôle important car il permet de réduire drastiquement la dépendance au réseau de sorte que toutes les opérations relatives au profil restent des actions locales. Chaque fois qu un composant de configuration est exécuté, il lui suffit de consulter un fichier sur la machine, évitant ainsi de toujours devoir contacter le serveur distant. Cela permet d accélérer leurs exécutions, offre une plus grande fiabilité en cas de problèmes réseaux (ils peuvent être exécutés offline) et réduit la charge sur le réseau. Comme nous l avons vu au paragraphe précédent, lorsque son profil est modifié sur la CDB, le CCM reçoit une notification afin de récupérer la dernière version du profil et effectuer les modifications nécessaires. De plus, le CCM effectue des contrôles réguliers afin de s assurer qu il possède toujours la dernière version du profil ; une notification ayant pu être perdue lors de son transfert. L administrateur système peut également forcer manuellement cette opération. 4.5 Node and Cluster Management Voyons maintenant comment Quattor gère les changements de configuration ainsi que les installations et mises à jour de logiciels sur les nœuds. La gestion des configurations locales de chaque nœud est gérée par des services locaux (démons, agent, etc) et des configuration components. Comme nous l avons vu, le Configuration Cache Manager (CCM) stocke la dernière version du profil XML du nœud. Le démon cdispd vérifie régulièrement que le profil est à jour et lance le composant adéquat via le Node Configuration Deployer (NCD) chaque fois qu un changement est détecté. Un composant spécial, le Software Package Manager (SPM) fournit au Software Package Management Agent (SPMA) les informations nécessaires afin de garder les logiciels installés sur le nœud en concordance avec sa liste de programmes. Lorsque que le SPMA doit installer ou mettre à jour un logiciel, il contacte le Software Repository qui stocke de façon structurée les différents paquets des programmes. Côté serveur, le dépôt de logiciels (SWRep) vérifie l identité et les droits du nœud avant de permettre au SPMA de télécharger et déployer les paquets désirés. Un autre sous-système nommé Automated Installation Infrastructure (AII) est en charge

51 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS 43 de l installation du système initial sur les nœuds en générant par exemple les tables DHCP ou les fichiers de configuration de l installeur du système. Un effort particulier a été fait pour utiliser des protocoles, formats de fichiers et outils standards (HTTP, XML, etc). De plus, dans un souci de portabilité, le langage PERL [105] est utilisé pour les composants de configuration afin d assurer une indépendance maximale vis-à-vis de la plate-forme d exécution Gestionnaire d installation L Automated Installation Infrastructure (AII), est exécuté sur le serveur d installation et est responsable de l installation du système d exploitation sur les nœuds. Pour ce faire, on utilise les outils d installation automatisée fournis par les distributions 1. Les fichiers nécessaires à ces programmes sont générés en utilisant les paramètres disponibles dans la CDB pour chaque nœud. AII se charge également de la configuration du serveur DHCP et du boot réseau afin de permettre une prise en charge automatique de l installation dès le démarrage des clients. À l instar des clients, le serveur utilise CCM pour accéder aux informations de la CDB cdispd et le Node Configuration Deployer Comme nous l avons vu, lorsqu un nœud acquiert un nouveau profil, il se doit d ajuster ses paramètres de configuration conformément à leurs nouvelles valeurs. Ceci est fait par le travail conjoint du démon cdispd et du Node Configuration Deployer (NCD). cdispd interroge fréquemment le Configuration Cache Manager pour déterminer si un nouveau profil doit être téléchargé. Quand un changement est détecté, il détermine quels sont les composants qui sont affectés par les changements de valeurs dans les configurations. Une fois ces composants connus, il invoque le NCD en lui fournissant en paramètre la liste des composants. NCD peut être vu comme une interface pour exécuter les différents composants ; il peut également être lancé manuellement via ligne de commande. cdisp Component Component NCD SPM Component download profiles CCM FIG. 4.2 Node Configuration Management 1 À ce jour, les systèmes supportés sont KickStart de RedHat et JumpStart de Solaris

52 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS Configuration Components Les Configuration Components constituent les plugins que l on greffe à Quattor afin d effectuer des tâches de configuration du côté des clients. Les composants fournissent un format général et une interface pour chaque élément de configuration d un service ou d une application. Aucune action n est effectuée sur le serveur, tout est réalisé en local après la récupération du profil du nœud. On trouve dans l arbre de configuration de PAN, une branche nommée /software/- components, structurée selon les noms des différents composants. Ainsi, chaque composant peut disposer de ses variables propres et les arranger de manière à former des structures complexes. Ainsi, toute variable du composant de la forme /software/components/<component_name>/<variable_name> doit être déclarée dans le template PAN du composant. Chaque composant doit posséder un declaration template dans la CDB qui doit inclure le type component type (on peut voir cela comme une forme d héritage). Cela nous assure que chaque composant possédera une variable booléenne indiquant si le composant est actif dans le contexte actuel. Les composants sont en grande partie des modules PERL [105] incluant quelques bibliothèques et classes dont ils doivent hériter. Ils doivent posséder au moins une fonction Configure contenant les différentes actions de configuration. C est cette fonction qui sera exécutée par le NCD. L accès à l arbre de configuration se fait via l API Node View Access (NVA). Les fonctions définies dans cette bibliothèque permettent d interroger le CCM afin d y récupérer des variables de configuration du nœud. Le reste du code des composants est du PERL standard. On peut ainsi profiter des diverses facilités offertes par ce langage telles que le redémarrage de services, la modification de fichiers, etc. Bien qu il n y ait aucune restriction sur ce qu effectuent les composants, il existe quelques recommandations qu il est intéressant de suivre lorsque l on développe ses composants afin d éviter par exemple de rendre celui-ci trop complexe ou pas assez générique. Pour plus d informations, consultez [14]. Les composants sont déployés via des paquets de la même façon que les autres logiciels et sont donc stockés dans le Software Repository. Il y a cependant quelques contraintes supplémentaires à satisfaire en plus des informations requises par le système de packaging. Ainsi, le paquet RPM doit contenir un fichier README, un fichier de documentation PERL et le template PAN déclarant le composant dans CDB. Un outil d aide à la création de composants permet de créer des exemples pour ces fichiers obligatoires. Le développeur n a alors plus qu à modifier certaines valeurs selon ses besoins.

53 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS Développement futur et améliorations SCDB Dans cette section, nous présenterons, une alternative à la Configuration Database (CDB) de Quattor, nommée SCDB. C est cette solution qui a été retenue et que nous utilisons à l IIHE. Comme nous l avons vu précédemment, CDB est basé sur CVS et dispose de sa propre interface régissant les interactions entre CVS et l utilisateur. SCDB propose d utiliser un serveur Subversion [121] tout à fait classique ainsi qu un build script Ant [49] pour les différentes tâches de configuration. Fonctionnement de SCDB Toutes les informations de configuration du site sont stockées dans un module subversion standard possédant une structure bien définie et un post-commit hook script 2 personnalisé. Subversion n est donc chargé que du stockage des configurations ainsi que de la gestion de l historique des changements. Lorsque l on désire modifier les configurations, on télécharge ces dernières du serveur (checkout), on les modifie et teste localement puis on renvoie la version modifiée au serveur (commit). Les checkout et commits sont réalisés via les commandes subversion standard, l édition des fichiers se fait avec l éditeur de son choix ; la compilation et le test des configurations sont effectués via un script Ant. Les changements commités sur le serveur ne sont pas automatiquement déployés sur les machines clientes. Cela permet d effectuer des changements importants dans les configurations par tests et commits incrémentaux. On évite ainsi d avoir à gérer d importants conflits de versions qui sont souvent difficiles à résoudre. Le déploiement des configurations vers les clients se fait à l aide du script Ant. Celuici va copier les configurations actuelles vers la branche deploy du module et la tagger avec les date et heure courantes. Les configurations dans le sous-répertoire deploy et taggées selon le bon format, vont déclencher le script subversion de post-commit qui va les déployer sur les clients. Ce script va : 1. Mettre à jour l espace de travail sur le serveur avec la version taggée. 2. Compiler les différents profils. 3. Copier les profils dans un répertoire accessible aux clients (par http(s)) et les informer que de nouveaux profils sont disponibles. 4. Envoyer un courriel à l administrateur, l informant du succès ou de l échec du déploiement. Avantages de SCDB On bénéficie des nombreux avantages qu offre Subversion par rapport à CVS : commit atomique, meilleur système de tags et de branches, gestion des répertoires, intégration au serveur web Apache, etc. Délègue toute la gestion de version à subversion : merge, gestion des conflits, etc. 2 script exécuté automatiquement après chaque commit de modification sur le serveur

54 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS 46 Permet de tester localement des modifications avant de les envoyer sur le serveur. Permet de grouper les templates dans des répertoires différents afin de faciliter leur gestion. Très bonne intégration avec des outils de développement comme Eclipse 3 qui fournit une excellente interface graphique pour la manipulation et le déploiement des profils Pan. Facilités pour gérer plusieurs sites (voir 4.6.2). Notons toutefois que SCDB n est pas supporté officiellement par Quattor mais l est par d autres développeurs. Pour plus d informations sur SCDB et sa mise en place, consultez [26] et [47] Configuration centralisée BEgrid Actuellement, chaque site désirant utiliser Quattor pour administrer ses machines doit déployer l intégralité de l architecture et des configurations. Or une grande partie de celles-ci sont communes à tous les sites et il en résulte que chaque administrateur perd beaucoup de temps à refaire du travail déjà effectué dans d autres sites. Pour pallier ce problème, la mise en place d un serveur de configurations centralisées au niveau de BEgrid [51] est à l étude à l IIHE. Une telle infrastructure présenterait de nombreux avantages tels que : gain de temps pour les administrateurs : si une configuration fonctionne et a été éprouvée dans plusieurs sites, il y a de bonnes chances que cela reste le cas pour d autres sites ; meilleure qualité des configurations car plus de gens peuvent y avoir accès et corriger les éventuels problèmes ; spécialisation des parties spécifiques à chaque site ; facilité accrue d ajout de nouveaux sites à BEgrid, qui n ont plus à partir de zéro pour leurs configurations. Voyons maintenant comment s articulerait un tel système. Nous disposerions d un serveur central qui stockerait le dépôt de logiciels (SWRep) ainsi que les configurations (SCDB). L accès à ces dernières se ferait via HTTPS avec une gestion de certificats et ACL assurant la sécurité. Chaque site aurait un serveur qui ferait office de cache HTTP sur le dépôt de logiciels (afin de ne pas surcharger le serveur principal) et de serveur AII pour l installation des nœuds. La compilation des profils ainsi que leur envoi vers les clients seraient également gérés par chaque site afin de laisser à l administrateur du site la décision de déployer ou non les profils modifiés. Subversion (voir 4.6.1), par son système de tag de version, permet de gérer cela aisément. La figure 4.3 donne un aperçu schématique d une telle infrastructure. 3 utilisé à l IIHE

55 CHAPITRE 4. QUATTOR : INSTALLATION ET GESTION DE PROFILS 47 Admins UI Serveur central SWRep SCDB Chaque site copie SWRep AII panc Noeuds FIG. 4.3 Configuration Quattor centralisée 4.7 Conclusion Comme nous l avons vu, la gestion d une ferme de calcul entraine une série de tâches qu il est primordial d automatiser et simplifier au maximum pour les administrateurs réseaux. Quattor, de par son architecture et sa souplesse, se révèle être un outil de choix particulièrement adapté pour l installation et la configuration des grandes fermes (plus de 2400 nœuds au CERN par exemple). Bien que Quattor puisse tout à fait être utilisé sur un petit nombre de machines, il est bon de s assurer que les facilités qu il offre justifient la complexité de son déploiement et de sa configuration (gestion des profils, etc). Citons également d autres logiciels de gestions de fermes tels que OSCAR [103], Rocks [114] ou LCFG [86]. Le lecteur intéressé consultera [31] pour un aperçu de ces logiciels et de leurs architectures.

56 Chapitre 5 Les intergiciels 5.1 Introduction À l instar des fermes, les grilles de calcul nécessitent une couche logicielle responsable de la gestion, de la coordination et de l accès aux différentes ressources. Les grilles réutilisent le terme middleware ou intergiciel pour désigner cette infrastructure. Comme nous l avons vu dans le chapitre 3, Globus fournit un ensemble de briques de base aidant à l implémentation d applications de gestion de grilles et non une solution complète fournie clé en main. Les intergiciels de grilles tentent de répondre à ce besoin en fournissant un packaging complet de logiciels que l utilisateur n a plus qu à installer et configurer sur son site pour l intégrer à une grille existante (voire même pour déployer sa propre grille). Dans ce chapitre, nous décrirons dans un premier temps l intergiciel LCG 2 actuellement utilisé à l IIHE ainsi que dans l ensemble des sites intégrés à la grille européenne. Nous présenterons ensuite son successeur glite qui constitue l avenir du grid computing en Europe mais aussi dans le monde. 5.2 L intergiciel LCG-2 L intergiciel LCG 2 est composé d un ensemble de logiciels dont les principaux composants sont : La version 2 du toolkit Globus. Le système Condor [59] de l Université du Wisconsin. Globus ainsi que Condor sont distribués à travers le Virtual Data Toolkit (VDT) [132], également de l Université du Wisconsin. Il fournit un ensemble de scripts facilitant l installation, la configuration et le déploiement des outils de base nécessaires à l intergiciel. Des outils spécifiques développés dans le cadre du projet EDG (cf. chapitre 3). Même si le projet est maintenant terminé, ces applications continuent d être maintenues. Notons que, pour quelques programmes, des patchs propres à LCG 2 sont appliqués afin de modifier certains aspects de leur code. Les versions de ces applications peuvent donc être différentes de celles en amont. 48

57 CHAPITRE 5. LES INTERGICIELS 49 Des paquets RPM s pour Scientific Linux sont disponibles afin d installer aisément les différents composants de l intergiciel sur cette distribution. Voyons à présent comment s agence une grille de calcul utilisant les applications fournies par LCG 2 et quels sont les services qu elles offrent L interface utilisateur Afin de pouvoir accéder aux ressources de la grille, l utilisateur doit se connecter à une User Interface (UI). Chaque site dispose généralement de son UI sur laquelle les personnes du site autorisées à utiliser la grille possèdent un compte (un simple accès SSH suffit). Chaque utilisateur a pris soin de copier son certificat d authentification dans son répertoire personnel. L utilisateur peut alors accéder aux ressources de la grille en utilisant les programmes installés sur l interface utilisateur. Parmi les tâches qu il peut effectuer à partir de cette UI citons : S identifier afin de créer un proxy et pouvoir utiliser les ressources de la grille (cf. chapitre 3.5.3). Soumettre un job pour exécution. Répertorier toutes les ressources satisfaisant une série de contraintes. Gérer ses jobs en cours d exécution : consulter leur état, les annuler... Récupérer les résultats de jobs terminés. Récupérer des copies de données disponibles sur la grille. Notons également que quelques interfaces graphiques rudimentaires existent et peuvent être utilisées pour effectuer certaines de ces tâches Computing Element Un Computing Element (CE) représente une ressource de calcul du point de vue de la grille ; plus exactement une ressource de calcul pour chaque file(s) de jobs définie(s) sur le CE. Typiquement, on crée différentes files selon les profils des jobs qu elles vont accueillir. Par exemple, une file pour les jobs ne demandant pas plus de 10 heures d utilisation processeur et une deuxième file pour les autres. Cela permet l utilisation de techniques de type tourniquet à étage [44] pour l ordonnancement des jobs sur la ferme si nécessaire. On peut également décider de créer une file par organisation virtuelle pouvant utiliser le CE. Une ressource de calcul est définie par l adresse (et le port) d un CE, ainsi que par une file. Par exemple :gridce.iihe.ac.be:2119/jobmanager-lcgpbs-long Un Computing Element est donc une machine servant généralement de point d accès à une ferme pour la grille. C est donc sur cette même machine qu est installé le serveur du système de gestion de jobs de la ferme. LCG 2 supporte différents systèmes de gestion de jobs tels que PBS [104], LSF [91] ou encore Condor [59]. L interaction avec ces différents systèmes est assurée par GRAM du toolkit Globus que nous avons présenté au chapitre 3. Le CE peut également être le point d accès à un super-calculateur, voire même à une simple machine classique. Généralement, chaque site intégré à une grille LCG 2 possède son CE. Les sites de très grande envergure pouvant bien sûr en déployer plusieurs s ils possèdent de nombreuses ressources.

58 CHAPITRE 5. LES INTERGICIELS Worker Node Les Worker Nodes (WN) sont les différents nœuds qui composent la ferme. Ce sont eux qui exécutent les jobs qui leur ont été transmis par leur Computing Element. Le client du système de gestion de jobs utilisé sur la ferme est donc installé sur ces machines. Notons que les WN ne doivent pas nécessairement être accessibles de l extérieur du site, seul le CE doit l être car c est lui qui reçoit les jobs de la grille. Les worker nodes peuvent donc se trouver derrière un NAT 1 afin de ne pas les exposer directement à Internet et économiser des adresses IP Storage Element De même que le Computing Element fournit un accès unifié aux ressources de calcul, le Storage Element (SE) fournit un accès unifié aux ressources de stockage. Chaque SE doit posséder un serveur GSIFTP ; GSIFTP étant un sous-ensemble du GRIDFTP de Globus, et est utilisé pour les transferts de fichiers dans LCG 2. Un SE peut s interfacer avec plusieurs types de stockage tels que : De simples disques installés sur la machine faisant office de SE. Des systèmes de stockage de masse ; typiquement ils se présentent sous forme d une batterie de disques au-dessus d une collection de bandes magnétiques. Les migrations de fichiers entre les disques et les bandes sont effectuées par un logiciel spécialisé pour gérer ce type d infrastructure. Dans le cadre de LCG 2, on utilise généralement CASTOR (CERN Advanced Storage Manager) [54] qui, comme son nom l indique, est développé au CERN. Des pools de serveurs de disques, gérés par dcache [62] par exemple. Ce type de système consiste en un serveur faisant office de point d accès pour le SE et d un ensemble de nœuds de stockage. De l extérieur, l ensemble de l infrastructure n est vue que comme un seul système de fichier unifié. Signalons également le projet DPM (Disk Pool Manager) de LCG, implémentant une alternative allégée de dcache pour les sites de petite taille. Pour les deux derniers cas, le SE peut utiliser un Storage Ressource Manager (SRM) pour accéder aux données. SRM consiste en une interface commune aux différents systèmes de stockage permettant de masquer les opérations complexes de gestion de disques, de pools ou de bandes propres à chaque système Gestion de catalogues Comme nous l avons déjà abordé, les données peuvent être répliquées et donc se trouver à différents endroits simultanément. La plupart du temps, les utilisateurs et applications ne se soucient pas de la localisation des données et veulent juste pouvoir les utiliser le plus aisément possible. C est alors au service de gestion de données de localiser ces fichiers et d en permettre l accès. En pratique, plusieurs méthodes permettent de référencer les fichiers d une grille. Leur identifiant unique, le Grid Unique IDentifier (GUID). Tous les répliquas d un même fichier possèdent donc le même GUID. 1 Mécanisme permettant à des machines possédant des adresses non routables (un réseau local) d accéder à des machines d un autre réseau utilisant des adresses routables (typiquement Internet)

59 CHAPITRE 5. LES INTERGICIELS 51 Un identifiant alphanumérique n étant pas des plus pratiques à manipuler pour les utilisateurs, les LFN (Logicial File Name) servent d alias afin de désigner plus facilement un fichier. Notons qu un même fichier peut très bien posséder plusieurs LFN. Alors que les GUID et LFN se réfèrent aux fichiers indépendamment de leur localisation ou réplicas, les Storage URL (SURL) indiquent une localisation physique précise d un fichier. Une SURL, se compose de l adresse d un SE et du chemin permettant d accéder au fichier sur ce dernier. Enfin, les Transport URL (TURL) contiennent, en plus des informations des SURL, un protocole et un port permettant aux applications d accéder au fichier. Le service de catalogue de fichiers est responsable de l association entre les noms logiques et les noms physiques des fichiers stockés sur les SE. Le catalogue de fichiers originel de LCG 2 était le Replica Location Service (RLS) de Globus. Celui-ci souffrant de problèmes de performance et de fonctionnalités, il a été remplacé dans les dernières versions de LCG 2 par le LCG File Catalog (LFC). Voyons maintenant les différences principales entre ces deux systèmes. RLS RLS est en fait constitué de deux catalogues : le Local Replica Catalog (LRC) et le Replica Metadata Catalog (RMC). Comme l illustre la figure 5.1, le LRC fait l association entre les GUID et les SURL alors que le RMC le fait entre les GUID et les LFN. Le principal défaut de RLS est cette découpe en deux catalogues, ralentissant sensiblement les recherches. Ce problème, mis en évidence lors d un data challenge 2, couplé à différents manquements de sécurité ont justifié l abandon de RLS. FIG. 5.1 Architecture de RLS [41] LFC Pour remédier aux problèmes de performances de RLS, a été développé un nouveau catalogue de fichiers nommé LCG File Catalog (LFC). La principale cause de lenteur de RLS venait de sa séparation des LFN et SURL en deux sous-catalogues. LFC bénéficie donc d une nouvelle architecture centrée sur les LFN 2 Test grandeur nature de l infrastructure de la grille à partir de données simulées afin de détecter ses défauts et dysfonctionnements avant la mise en production du LHC

60 CHAPITRE 5. LES INTERGICIELS 52 comme l illustre la figure 5.2, et où les LFN et SURL sont stockés dans la même base de données. Remarquons également la possibilité d associer des informations sur un fichier via les user metadata (ce qui était également possible avec RLS). FIG. 5.2 Architecture de LFC [41] LFC bénéficie également de nouvelles fonctionnalités telles que : un espace de noms hiérarchisé (à l instar des systèmes de fichiers classiques), le support de l authentification et autorisation via GSI (cf. chapitre 3.5.3), les sessions, une gestion des permissions similaire à celle de UNIX et des ACL POSIX (Access Control List). Le catalogue expose alors une interface nommée File Authorization Service. les sommes de contrôle d intégrité (checksum). Enfin, LFC peut utiliser MySQL ou Oracle comme backend de stockage et est parfaitement intégré à l API GFAL (voir point suivant) et aux autres outils de LCG. Dès lors, LFC a fait son apparition dans les dernières versions de LCG 2 et est maintenant massivement utilisé dans la majorité des sites en production Accès aux fichiers Une fois les fichiers localisés sur un SE à l aide du catalogue de fichiers, l utilisateur ou les applications exécutées sur la grille doivent pouvoir y accéder. Rappelons que les accès aux fichiers se font selon le principe du write once, read many ce qui implique qu une fois écrit, les fichiers ne sont plus modifiés (cf. section 3.5.3). On distingue deux grands types d opérations sur les fichiers : le transfert de fichiers : d un SE vers un WN afin qu il puisse les traiter, d un SE vers un autre SE pour créer un repliqua, la suppression d un repliqua... l accès distant : typiquement une application voulant accéder en lecture à un fichier, sans forcément vouloir le rapatrier sur sa machine. Il faut aussi permettre aux applications de créer de nouveaux fichiers sur les SE. Comme nous l avons signalé, chaque Storage Element possède un serveur GSIFTP, c est donc naturellement ce protocole qui est utilisé pour les transferts. Les opérations d entrées/sorties sur fichiers non locaux sont assurées par deux protocoles selon le type de stockage utilisé sur le SE :

61 CHAPITRE 5. LES INTERGICIELS 53 RFIO (Remote File Input/Output) pour les SE utilisant de simples disques, DPM ou CASTOR. gsidcap (GSI dcache Access Protocol), une version sécurisée (via GSI) du protocole d accès de dcache, si le SE utilise ce dernier pour le stockage des fichiers. Le SE publie au service d information le ou les protocoles qu il supporte. Les applications utilisateurs passent par la Grid File Access Library (GFAL) qui fournit une interface d accès au fichier similaire à celle de POSIX. Elles n ont alors qu à appeler les équivalents de fonctions telles que : open, read, write, close... sans se soucier de l accès au catalogue de fichiers et au SE Service d information Ce service, abrégé habituellement en IS pour Information Service, a pour importante tâche de collecter, stocker et fournir des informations concernant les diverses ressources de la grille. Ces informations sont utilisées pour assurer le bon fonctionnement des différents services (ordonnancement de job par exemple) mais aussi éventuellement à des fins statistiques ou de facturation. Les informations publiées dans le IS sont organisées selon le schéma GLUE (Grid Laboratory Uniform Environment) [78] visant à définir un modèle de données standard pour la description des ressources d une grille. L IS utilisé par LCG 2 est basé sur le Monitoring and Discovery Service (MDS) de Globus. Cependant, R-GMA, un nouveau type de service d information a récemment fait son apparition dans LCG 2. Toutefois, celui-ci étant principalement issu du développement de glite et MDS restant le système d information principal de LCG 2, nous le présenterons ultérieurement. Le service MDS implémente le schéma GLUE à l aide d OpenLDAP [100], une implémentation libre du Lightweight Directory Access Protocol (LDAP). LDAP permet de créer des bases de données hiérarchiques optimisées pour la lecture et la recherche d informations. Voyons maintenant comment sont collectées et stockées ces informations. Chaque ressource de calcul ou de stockage (CE et SE) possède un composant nommé Information Provider en charge de la récolte d informations. Pour ce faire, il agrège des informations statiques comme les différentes configurations et des dynamiques comme l espace restant sur les disques ou la charge système. Ces informations sont publiées via les Grid Resource Information Servers (GRIS). Chaque site dispose d un Grid Index Information Server (GIIS) responsable de la collecte de ces informations parmi les ressources dont il a la charge. Notons que, pour des raisons de performance et de fiabilité, LCG 2 recommande dorénavant d utiliser plutôt un serveur BDII (Berkeley Database Information Index) pour ce faire. Enfin, au sommet de la hiérachie de la grille se trouve un autre serveur BDII par VO chargé de récupérer régulièrement les informations stockées dans les différents BDII locaux. En résumé, on est donc face à une collecte d informations s opérant à trois niveaux comme l illustre la figure 5.3. Au niveau des ressources, les informations sont collectées et publiées par le GRIS. Ces informations sont stockées dans un GIIS ou un BDII de site. Un BDII global à toute la grille va régulièrement interroger les différents sites et garder une copie de leurs informations.

62 CHAPITRE 5. LES INTERGICIELS 54 FIG. 5.3 Différentes niveaux de collecte d information du MDS [41] Workload Management System Les jobs soumis par les utilisateurs (à l aide de leur UI) arrivent au Workload Management System (WMS) qui a pour mission de déterminer le CE qui sera en charge de les accueillir pour exécution. Comme nous l avons déjà vu, cette sélection se base sur plusieurs critères tels que les contraintes définies par l utilisateur et l état des différentes ressources au moment de la soumission du job. Pour ce faire, il récupère des informations sur les différentes ressources via le BDII global. Les services du WMS sont découpés en plusieurs grands composants : Le Ressource Broker (RB) en charge de la sélection des ressources pouvant satisfaire le job. Le Network Server (NS) qui reçoit les jobs des interfaces utilisateurs. Le Job Control Service (JCS) qui s occupe de la soumission du job sur le CE sélectionné ; c est aussi lui qui gérera l annulation du job à la demande de l utilisateur. Comme nous l avons déjà indiqué, le proxy d authentification d un utilisateur a une durée de vie limitée. Or il peut arriver qu un job nécessite tellement de calcul que le proxy expire avant la fin de son exécution. Dès lors, le job se verra refuser l accès aux ressources car il ne sera plus identifié. Pour éviter cela, un composant du WMS, le Proxy Server (PS) également connu sous le nom de MyProxy va gérer automatiquement le renouvellement du proxy pour les longs jobs. Il est évident qu il est impératif de faire confiance à la machine hébergeant MyProxy avant de lui déléguer le droit de renouvellement Logging and Bookkeeping Habituellement installé sur la même machine que le WMS, le service de Logging and Bookkeeping (LB) va collecter et stocker tous les événements relatifs à la gestion des jobs. Il pourra ainsi informer l utilisateur sur l évolution de son job en lui fournissant l étape par laquelle il est en train de transiter : en cours de soumission, transfert vers le CE, en cours d exécution, terminé... Ce sont les CE et WMS qui contactent leur serveur de Logging and Bookkeeping afin de l informer de ces différents événements.

63 CHAPITRE 5. LES INTERGICIELS Sécurité LCG 2 étant basé sur le toolkit Globus, il utilise naturellement les services fournis par la GSI (Grid Security Infrastructure). Les utilisateurs sont regroupés en différentes organisations virtuelles comme nous l avons déjà évoqué. Un serveur de VO contient la liste des personnes affiliées aux VOs dont il a la charge. Les services devant autoriser (ou non) l accès à des ressources interrogent régulièrement les serveurs de VO afin de récupérer la liste des utilisateurs inscrits dans les différentes organisations virtuelles. Ces informations sont stockées dans un fichier local nommé grid-mapfile qui servira à faire l association entre un utilisateur de la grille et un utilisateur de la machine possédant la ressource. Ainsi, imaginons qu un utilisateur membre du VO becms et identifié par : /C=BE/O=BEGRID/OU=ULB/OU=Departement Informatique/CN=Guillaume Desmottes soumette un job pour exécution. Le Computing Element va alors parcourir son grid-mapfile jusqu à trouver l entrée : "/C=BE/O=BEGRID/OU=ULB/OU=Departement Informatique/CN=Guillaume Desmottes".becms Le job pourra alors être exécuté sur le CE (ou un de ses WN) sous l identité d un des utilisateurs locaux associé à ce VO (becms007 par exemple). Ces utisateurs sont créés sur la machine lors de la configuration du service. Typiquement, il est conseillé d en créer 200 par organisation virtuelle que la ressource doit desservir. Ce système de grid-mapfile souffre de nombreux défauts. Par exemple, un utilisateur venant d être ajouté à une organisation virtuelle devra attendre la prochaine mise à jour du fichier grid-mapfile des ressources qu il désire utiliser sous peine de s en voir refuser l accès. Ou encore, si un utilisateur est inscrit dans plusieurs organisations virtuelles, il sera toujours associé au même VO à l exécution. Pour pallier ces problèmes, un nouveau système fut ajouté très récemment dans LCG 2. Cependant, celui-ci ayant été principalement développé dans le cadre de glite, nous le présenterons dans la section dédiée à ce dernier Installation et configuration Deux systèmes sont utilisés par la majorité des sites pour installer et configurer les différents services de LCG 2. Le premier, et sans doute le plus utilisé, est basé sur Yaim, une série de scripts shell chargés de l installation des paquets RPM s et de la configuration des services. L autre solution est d utiliser Quattor qui permet, comme nous l avons vu au chapitre 4, de prendre en charge l installation et la configuration complète des machines d un site. Yaim Toute la configuration du site est faite dans un unique fichier. Celui-ci contient donc les options de configurations de tous les services que l on désire déployer sur le site. Notons que certains services utilisent également un autre fichier comme, par exemple, le CE qui dispose des adresses de ses différents WN. Ces fichiers sont de simples fichiers shell contenant une série d associations clé-valeur. Sur chaque machine que l on veut utiliser pour déployer un service de LCG 2, on

64 CHAPITRE 5. LES INTERGICIELS 56 installe le RPM de Yaim et copie le fichier de configuration du site (ainsi qu éventuellement quelques fichiers annexes selon le service). Il suffit alors d invoquer Yaim en précisant le type de service que l on désire installer pour que celui-ci se charge de la récupération et l installation des RPM s ainsi que de sa configuration. Le principal avantage de Yaim est qu il est largement répandu et facile à utiliser. Cette facilité d utilisation a toutefois un prix. Ainsi, Yaim ne gère nullement l installation du système d exploitation, ni des autres logiciels. Il faut donc utiliser une autre technique si l on désire automatiser cette étape (voir chapitre 4). Le fait d avoir la configuration de tous les services dans un seul et même fichier n est pas forcément des plus souples, ni des plus élégants. On peut en effet se demander s il est vraiment pertinent qu une machine faisant office d interface utilisateur dispose des détails de configuration du Computing Element par exemple. De plus, si l on désire modifier certains paramètres dans les configurations des services, il faudra le faire dans le fichier de chaque machine. On peut toutefois contourner ce problème en mettant ce fichier sur un partage NFS par exemple. Enfin, la syntaxe du fichier de configuration basée de simples paires clés/ valeurs n est pas nécessairement des plus pratiques. Une certaine forme de structure dans la gestion des configurations peut se révéler appréciable. Quattor Une autre possibilité beaucoup plus souple et puissante, mais aussi plus complexe à mettre en place, est d utiliser Quattor, l outil d installation et de configuration que nous avons présenté au chapitre 4. Le Quattor Working Group (QWG) [111] fournit les outils nécessaires pour pouvoir installer, configurer et maintenir un site LCG 2 à l aide de Quattor. Il met ainsi à disposition les différents templates PAN et composants NCM pour ce faire. À ce jour, la majorité des services utilisés sur la plupart des sites sont supportés : UI, CE, SE, RB... Notons toutefois que les serveurs de gestion d organisations virtuelles ainsi que de catalogues de réplicas ne sont pas encore gérés. De plus, la configuration manuelle de certains outils extérieurs à LCG 2 est toujours nécessaire. Les templates de configuration sont conçus de façon à minimiser les changements nécessaires pour les adapter à son propre site. Ils fournissent également une extension aux types de base de Quattor regroupant des types d informations récurrentes dans les configurations de services LCG 2 : URI, , adresses IPv4 et IPv6, hostname, numéro de port... Un type est ainsi défini pour chaque option de configuration permettant une vérification stricte lors de la compilation des profils et évitant ainsi d entrer des valeurs incohérentes. Les composants NCM seront chargés, côté client, de récupérer les informations stockées dans le profil et de configurer les différents services (voir la section pour une explication détaillée du fonctionnement des composants NCM). Chaque service LCG 2 supporté possède son propre composant chargé de sa configuration. On retrouve également une série de composants responsables par exemple de Globus ou encore du grid-mapfile. Enfin, épinglons également un composant ncm-yaim permettant d utiliser les scripts Yaim pour la configuration. Cela résulte d une volonté commune des développeurs de Quattor et de Yaim de faire évoluer en parallèle les deux systèmes et de pouvoir les faire cohabiter.

65 CHAPITRE 5. LES INTERGICIELS L intergiciel glite glite est un intergiciel orienté service Web développé dans le cadre du projet EGEE (Enabling Grids for E-sciencE) en parallèle de LCG 2 et destiné, à terme, à le remplacer. Un des objectifs essentiels de glite est l interopérabilité. Pour ce faire, l intergiciel utilise un maximum de protocoles et interfaces standardisés ou en passe de l être. Comme nous l avons déjà mis en avant au chapitre 3, les services Web sont un excellent moyen pour faciliter cette interopérabilité. Les différents services que doit assurer le middleware sont décrits par les interfaces qu ils doivent exposer vis-à-vis de l extérieur. Cela devrait permettre à terme de pouvoir faire interagir différents intergiciels sans qu ils ne doivent implémenter les services de la même façon. glite se veut également le plus modulaire et souple possible. La granularité des services et sous-services est telle qu on peut aisément choisir ceux que l on désire faire cohabiter sur une même machine et ceux qui seront déployés sur des machines distinctes. On peut ainsi adapter le nombre de machines dédiées au déploiement de l intergiciel selon les besoins et les moyens de chaque site. Le développement de glite étant inscrit dans le cadre du projet EGEE, il a également pour objectif majeur d ouvrir les portes du grid computing à la majorité des domaines de recherche scientifique. Pour ce faire, glite développe de nouveaux services et améliore les existants afin de pouvoir satisfaire toutes les exigences liées à ces différentes disciplines. Nous allons maintenant présenter quelques-unes des différences et améliorations notables de glite par rapport à LCG 2. Il faut garder à l esprit que la frontière entre ces deux intergiciels n est pas toujours très nettement marquée. Ainsi, différentes améliorations développées dans le cadre de glite se sont retrouvées dans les dernières versions de LCG 2. De plus, glite étant destiné à remplacer LCG 2, les deux systèmes vont devoir cohabiter pendant encore un certain temps afin d effectuer la migration en douceur. Il n est en effet évidemment pas envisageable de demander à tous les sites de la grille de migrer du jour au lendemain toute leur infrastructure vers glite. La meilleure preuve de cette cohabitation est sans doute glite 3.0, dernière version en date sortie début mai 2006, qui est en fait un hybride entre LCG 2 et glite. Cette version marque la première étape dans la transition vers glite et contient des composants venant de LCG et glite 1.5. Certains services tels que le CE ou le WMS sont même proposés dans les deux versions Computing Element Le gestionnaire de ressources conseillé par glite est Torque (Tera-scale Open-source Resource and QUEue manager) [124]. Celui-ci est basé sur PBS et offre des avancées significatives en terme de fiabilité et fonctionnalités. Le CE de glite peut toutefois, à l instar de celui de LCG 2, toujours utiliser d autres systèmes tels que PBS, LFS ou CONDOR si nécessaire. Parmi les améliorations, citons la faculté pour le CE d informer le WMS qu il est prêt à recevoir des jobs ou encore la possibilité laissée aux organisations virtuelles de définir leur propre politique d ordonnancement.

66 CHAPITRE 5. LES INTERGICIELS Storage Element De même qu avec LCG 2, le SE de glite doit disposer d un serveur GSIFTP pour permettre les transferts. Les SE de type classique ne sont plus autorisés, il faut donc impérativement utiliser un système de gestion des ressources disposant d une interface SRM. Comme pour LCG 2, les principaux SRM sont dcache, CASTOR et DPM. Enfin, le SE doit également être pourvu d un serveur glite I/O afin de permettre l accès distant aux fichiers (voir section 5.3.4) Gestion de catalogues En marge de LFC, glite a développé un autre catalogue de données, nommé FireMan (FIle and REplica MANager). Celui-ci est assez similaire à LFC en terme de fonctionnalités et, comme ce dernier, ne découpe pas les LFN et SURL en deux catalogues distincts. La principale différence entre ces deux systèmes se situe au niveau de leur interface. En effet, conformément à la philosophie générale de glite, FireMan possède une interface à base de services web contrairement à LFC. FireMan supporte en outre les opérations dites bulk qui permettent de soumettre une série d opérations de même type (insertion, suppression ou recherche) via un seul et même appel de fonction (et donc un seul message SOAP via le service web). En terme de performance, une étude a montré [39] que pour des requêtes isolées LFC est un meilleur choix que FireMan. Par contre, lorsqu il s agit de paquets de requêtes, FireMan surpasse LFC car ce dernier ne supporte pas les opérations bulks. Dans tous les cas, ces deux systèmes restent un meilleur choix que RLS, devenu obsolète Accès aux fichiers Ici encore, nous distinguerons les transferts de fichiers et les accès distants. Transfert de fichiers Un changement notable de glite par rapport à LCG 2 est l ajout d un service de transfert de fichiers. Le File Transfer Service (FTS) [123] prend en charge les transferts de fichiers d un site à l autre, ou plus exactement d un SE vers un autre SE. Lorsque l on désire effectuer un transfert, on contacte le FTS en lui spécifiant le fichier à transférer ainsi que les SE source et destination. FTS va alors prendre en charge l intégralité du transfert. Ce système permet de soumettre une série de transferts qui seront mis dans une file et exécutés de manière asynchrone évitant ainsi de bloquer le processus à l origine du transfert. Cette file permet également de différer des transferts en cas de problèmes éventuels (réseau, catalogue ou SE surchargé...). Le FTS peut également travailler avec des LFN et assurer la mise à jour des catalogues de données selon les transferts qu il effectue. On parle alors de File Placement Service (FPS).

67 CHAPITRE 5. LES INTERGICIELS 59 glite I/O À l instar de GFAL, glite I/O permet aux applications d interagir avec les fichiers à l aide d une interface similaire à celle de POSIX. Les principales améliorations de glite I/O par rapport à GFAL sont le support des ACL et du catalogue FireMan Service d information Le système d information de glite se nomme R-GMA pour Relational Grid Monitoring Architecture. Bien que MDS soit toujours utilisé actuellement avec glite, il est, à terme, condamné à disparaitre au profit de R-GMA. Certains services de LCG 2 utilisent R-GMA depuis peu, principalement pour la surveillance et les statistiques. R-GMA est une implémentation du standard Grid Monitoring Architecture créé par le Global Grid Forum et se présente comme une base de données relationnelle distribuée. Ce modèle se révèle être plus puissant que celui de MDS basé sur LDAP. Les bases de données relationnelles permettent en effet d effectuer des requêtes plus complexes et sont plus souples que LDAP pour les modifications du schéma des données. De plus, MDS n a pas été prévu pour permettre aux applications utilisateurs de publier leurs propres informations sur la grille ; R-GMA résout également ce problème. On distingue quatre composants dans l architecture de R-GMA. Les producteurs d informations qui s enregistrent auprès du serveur Registry central et l informent de la structure et du type des données qu ils désirent publier sur la grille. Les consommateurs d informations qui interrogent le Registry pour trouver quelles sont les informations disponibles et quels sont les producteurs qui les fournissent. Une fois qu un consommateur a contacté le Registry et trouvé un producteur publiant les informations qui l intéresse, il contacte directement ce dernier. Le Registry qui met en contact les producteurs et consommateurs. le Schema qui contient la structure des différentes tables virtuelles : le nom des colonnes et leur type. Du point de vue des utilisateurs et applications, les informations sont stockées dans une base de données relationnelle, ils soumettent donc des requêtes à l aide d un sousensemble de SQL via la commande SELECT. De même, les producteurs publient leurs informations via INSERT. La figure 5.4 illustre les différents échanges entre les quatre composants principaux de R-GMA. FIG. 5.4 Fonctionnement de R-GMA [28]