FLASH INFORMATIQUE FI



Que fait votre PC la nuit ?




Michela THIEMARD


Grille de calcul, grid, grille de données, grille de savoir,...Peut-être avez-vous déjà entendu ces termes très à la mode dans le monde du HPC (High Performance Computing), du stockage et de l’analyse d’énormes quantités de données, ainsi que dans celui de la sémantique du Web. Mais que cachent ces mots ? En interrogeant votre entourage, vous obtiendrez probablement autant de réponses différentes que de fois vous poserez la question. En quelques mots, on appelle grille un ensemble de ressources distribuées vu par un utilisateur lambda comme une seule et unique ressource. Dans cet article, nous allons essentiellement nous limiter aux grilles de calcul (computational grid), c’est-à-dire aux structures permettant d’absorber une grande quantité de calculs.
Mais quelle est l’origine de la notion de grille ? Le terme a fait son apparition dans le monde académique au milieu des années 1990 [1] et s’inspire de la grille d’électricité [2] (power grid). Vers le début du 20ème siècle, la génération personnelle d’électricité était technologiquement possible et de nouveaux équipements utilisant la puissance électrique avaient déjà fait leur apparition. Paradoxalement, le fait que chaque utilisateur possède son propre générateur d’électricité était un obstacle majeur à la généralisation de son utilisation. La véritable révolution a nécessité la construction d’une grille électrique, c’est-à-dire la mise en place de réseaux de transmission et de distribution d’électricité. C’est l’accessibilité et la baisse des coûts qui ont finalement permis de généraliser l’exploitation industrielle de cette énergie.

Apparition des grilles informatiques

Deux éléments sont indispensables à l’apparition d’une grille : l’abondance des ressources et leur interconnexion. Comme l’illustre la figure 1 en première page, les grilles sont apparues une fois les protocoles de communication bien développés et durant une période où le parc de machines avait atteint une certaine masse critique.

JPEG - 3.2 ko
fig. 1
Chronologie de l’évolution technologique [2]

Voici déjà de nombreuses années que l’achat d’un PC n’est plus prohibitif. Quasiment chaque noyau familial en possède un, voire même plusieurs. Par ailleurs, la majorité de ces machines est aujourd’hui connectée à Internet. Cependant, comme il est assez rare qu’une personne disposant d’un PC l’utilise constamment, l’idée de récupérer cette puissance dormante, les cycles de calcul inutilisés (harvest cpu cycles), est apparue. En poussant ce raisonnement un peu plus loin, des instituts travaillant dans le même domaine, mais répartis sur divers sites géographiques, se sont associés pour s’équiper d’une infrastructure commune. Du coup des instituts virtuels, travaillant sur des organisations virtuelles de ressources (VO) (virtual organization) sont apparus. En dehors du partage des frais d’achat et de maintenance de l’infrastructure, les besoins en puissance brute de calcul varient généralement en fonction du temps et peuvent se répartir entre les membres d’un institut virtuel. Un exemple simple est l’exploitation du décalage horaire, lorsque les membres d’un institut virtuel ne vivent pas sous les mêmes longitudes. Un autre avantage de la mise en grille des ressources est la possibilité d’accéder à des bases de données ou à des logiciels distants. On évite ainsi de devoir rapatrier d’énormes quantités de données et le partage de l’achat de coûteux logiciels devient possible. En effet, l’accès à une VO doit être transparent pour l’utilisateur, c’est-à-dire qu’il doit avoir l’impression que la ressource est à côté de lui.

Deux formes de grilles de calcul

On distingue essentiellement deux formes d’exploitation d’une grille de calcul : la grille pull et la grille push . Ces deux formes ont cependant une base identique, à savoir d’un côté des clients avec des calculs à effectuer et de l’autre des noeuds mettant à disposition des ressources permettant d’absorber ces calculs.

La grille de calcul pull

Dans cette forme de grille, le client met à disposition, sur un ou plusieurs serveurs, différentes tâches à effectuer que les noeuds iront chercher à leur convenance, afin de les exécuter. L’exemple le plus connu d’un tel type de grille est le projet Seti@home [3, 4] qui a débuté en mai 1999. Son objectif est d’analyser les observations recueillies par le radiotélescope d’Arecibo (Puerto Rico) afin de détecter la présence de bruits extraterrestres. Le traitement de cette quantité faramineuse de données est réparti en petits morceaux à travers les noeuds de la grille, mais ce sont les machines qui se connectent au serveur de données (pour y chercher du travail) dès qu’elles sont disponibles (i.e. dès qu’elles ne sont plus utilisées depuis un certain temps). Dans la foulée de Seti, d’autres projets@home ont été lancés. Les sources du module de base étant libres, tout un chacun peut en faire de même en adaptant son code. Cependant, il ne faut pas oublier que les tâches à exécuter doivent être parallèlement indépendantes (embarassingly parallel), c’est-à-dire qu’elles ne doivent nécessiter aucune communication entre elles et que le temps d’exécution ne doit pas excéder quelques heures. En effet, une grille pull n’offre généralement aucune garantie quant à la durée de la disponibilité des noeuds de calcul.

La grille de calcul push

Contrairement au cas d’une grille de calcul pull, dans une grille push les clients soumettent des tâches à exécuter à un ensemble de noeuds qui vont les stocker dans une file d’attente et les exécuter dès qu’ils le pourront, selon une certaine logique prédéfinie. Cette forme de grille permet également d’exécuter des tâches parallèles, pour autant que ses noeuds soient configurés correctement. Usuellement, lorsque l’on parle de grille de calcul, il s’agit d’une grille push de la forme décrite ci-dessous. D’une manière synthétique, il est généralement possible de définir le protocole d’une grille de calcul à l’aide de quelques éléments, représentés dans la figure 2. Cette formulation a été proposée par Foster et al. [5]. Les divers composants de cette architecture sont la fabrique, l’intergiciel et les tâches.

JPEG - 4.6 ko
fig. 2
l’architecture du protocole de la grille de calcul

La fabrique comprend les ressources de calcul (clusters, machines de bureau,...), les systèmes de stockage, le réseau, etc., qui vont être partagés via les protocoles de la grille.
L’intergiciel (middleware) est en quelque sorte la glu qui se charge de connecter les diverses ressources de la fabrique afin de les transformer en une entité unique, la VO. Il se décompose en trois sous-couches : la sous-couche connectivité, la sous-couche ressource et la sous-couche collectivité.

  • La sous-couche connectivité fournit les mécanismes de sécurité nécessaires à la protection des ressources. Elle contient les protocoles de communication et d’authentification utilisés dans les transactions à l’intérieur du réseau spécifique à la grille. Les protocoles de communication permettent l’échange de données entre les diverses ressources de la fabrique. Les protocoles d’authentification sont construits sur les services de communication pour fournir des mécanismes sûrs et cryptés afin de vérifier l’identité des utilisateurs et des ressources. Idéalement, dans un environnement de VO, les solutions d’authentification devraient présenter les caractéristiques de single sign on et de délégation des droits à un autre programme : le client s’authentifie une fois et ses applications peuvent s’exécuter sur n’importe quelle ressource de la grille. Dans les grilles, la sécurité est un souci nettement plus important que dans les environnements informatiques traditionnels, à cause du grand nombre de ressources concernées, qui sont de plus généralement réparties sur divers sites géographiques.
  • La sous-couche ressource comprend des protocoles permettant d’obtenir des informations sur la structure et l’état d’une ressource, tels que sa configuration, sa charge courante et sa politique d’utilisation. Cette couche comprend aussi les protocoles de gestion et de négociation de l’accès à une ressource partagée.
  • Alors que la sous-couche ressource est centrée sur les interactions avec une seule ressource, la sous-couche collectivité permet de coordonner des ressources multiples. Elle contient des protocoles et des services qui sont associés aux interactions entre une collection de ressources. Elle doit permettre entre autres de :
    • découvrir l’existence et les propriétés des différentes ressources d’une VO (service d’information et d’annuaire) ;
    • faire de la coallocation, de l’ordonnancement et du courtage, c’est-à-dire permettre aux clients de la VO de demander l’allocation d’une tâche particulière à une ou plusieurs ressources, selon une certaine logique ;
    • transférer les données nécessaires aux tâches d’un site vers un autre ;
    • gérer la facturation des services.

La dernière couche concerne les tâches des clients. Elle contient des outils susceptibles d’aider les développeurs à concevoir et à écrire des applications adaptées à la grille. Il s’agit en particulier de compilateurs, de librairies, d’outils de conception d’applications parallèles ainsi que d’interfaces de programmation ou d’API.
Cette structure correspond aux standards élaborés dans le cadre du Global Grid Forum (GGF) [6] par l’Organization for the Advancement of Structured Information Standards (OASIS) [7]. Le standard actuel est le Web Service Resource Framework [1].

Quelques intergiciels

L’intergiciel (middleware) est l’élément essentiel qui permet d’agréger les diverses ressources constitutives d’une grille. Plusieurs groupes de chercheurs et développeurs travaillent à la création de divers intergiciels. Certains cherchent à connecter des ressources de taille conséquente, comme des clusters, alors que d’autres s’attachent plus particulièrement à la récupération de cycles de calcul sur des machines personnelles. Dans la suite de cet article, on nommera les premiers des intergiciels globaux et les seconds des intergiciels spécifiques, cette dénomination n’étant toutefois pas standard.

Intergiciels globaux

Parmi les exemples les plus connus, il convient de citer Globus Toolkit, NorduGrid, Glite, Unicore,... Ces intergiciels libres, ne fonctionnant que dans le monde Unix, ont été développés autour de Java et XML. Ils offrent des interfaces permettant de dialoguer avec les ordonnanceurs locaux des divers clusters de la grille et l’authentification des clients et des noeuds de la grille s’effectue via des certificats SSL.
L’intergiciel Globus Toolkit [8] est le plus répandu. Il est développé par la Globus Alliance et supporté par un consortium comprenant notamment IBM. Globus Toolkit comprend un ensemble d’outils plus ou moins indépendants les uns des autres. Lors du déploiement d’une grille basée sur cet intergiciel, il est possible de n’utiliser que certains modules. On y trouve en particulier, le module GSI (Grid Security Infrastructure) pour gérer la sécurité, le module GRAM (Grid Resource Allocation and Management) pour gérer l’allocation et la supervision des tâches sur les noeuds de la grille, le module MDS (Monitoring and Discovery Service) pour répertorier en temps réel les noeuds de la grille disponibles et GridFTP pour transférer des données d’un site à un autre. Notons également que le client ne doit s’authentifier qu’une seule fois à une porte d’entrée d’une grille Globus (single sign on) ; par la suite, il sera connu de tous les autres noeuds via un proxy chargé de la délégation de l’authentification. Dans leur version 4, les modules de Globus Toolkit commencent à intégrer les Web services, i.e. tous les protocoles de communication se font via des services Web. Cette version est une première mouture du standard WSRF. Elle n’est pour l’instant que peu utilisée en production et c’est encore la version 3.2 qui prédomine.
Les intergiciels NorduGrid (développé en Scandinavie) et Glite (développé au CERN) sont basés sur Globus. Chacun d’eux comprend un choix de modules de Globus associés à des modules spécifiques adaptés en vue d’une forme d’utilisation particulière de la grille. Notons également que Glite tend à devenir de plus en plus indépendant de Globus.
L’intergiciel Unicore (version 1.5)[9] est le concurrent européen de Globus Toolkit. Il est supporté par un consortium d’industriels et par le gouvernement allemand. Il est entièrement écrit en Java et chaque module prend la forme d’un plugin. Le client de la grille Unicore peut charger les plugins souhaités à l’aide d’une interface graphique permettant de soumettre des tâches et de les suivre. Il est un peu moins complet que Globus, mais son installation s’avère plus aisée. Notons de plus qu’Unicore est capable de dialoguer avec Globus, mais que le contraire n’est pas encore possible (l’implémentation d’une passerelle est toutefois prévue : Grid Interoperability Project).

Intergiciels spécifiques

Ces intergiciels ont pour but de récupérer des cycles de calcul sur un parc de machines personnelles. Certains ne permettent d’exécuter que des tâches parallèlement indépendantes, alors que d’autres sont plus flexibles et autorisent des communications entre les processeurs. Cependant, les applications parallèles (avec communications) nécessitant beaucoup de processeurs ne sont pas très adaptées à une grille de machines personnelles, cette dernière étant très instable. En effet, les machines n’entrent dans le groupe de noeuds disponibles que pour quelques heures et ceci de manière totalement imprévisible. Compte tenu de cette instabilité, les intergiciels spécifiques sont généralement dotés d’une fonctionnalité leur permettant de réallouer des tâches qui auraient été interrompues. Un exemple d’intergiciel libre développé pour des applications parallèlement indépendantes est XtremWeb-CH [10]. Les principaux intergiciels non libres pouvant être déployés sur un parc de machines hétérogènes au niveau du système d’exploitation sont GridMP et InnerGrid. Ceux-ci permettent de soumettre des tâches parallèles (MPI pour GridMP et GridStudio pour InnerGrid). Condor, un logiciel libre, est un ordonnanceur évolué permettant la migration de tâches en cas de disparition d’un noeud et qui peut également être vu comme un intergiciel. Cette remarque est d’ailleurs valable pour tout ordonnanceur (PBSPro, LSF, LoadLeveler,...), sachant que dans ce cas, certaines fonctionnalités grille peuvent être limitées.

Une grille à l’EPFL

L’EPFL dispose d’un grand nombre de machines se trouvant dans des salles de cours ou dans les bureaux des collaborateurs. La plupart de ces ordinateurs ne sont pas utilisés constamment. Par ailleurs, l’école dispose de nombreux clusters, mais plus le nombre d’utilisateurs y ayant accès est restreint, plus ils souffrent des variation de charge (fin de thèses, délais de rendus de projets, etc. qui surviennent à des périodes différentes selon les instituts). Vu les ressources dont elle dispose, le déploiement d’une grille de calcul à l’intérieur de l’école s’impose de lui-même. Le projet GRID@EPFL [11], qui s’inscrit lui-même dans le cadre plus large du projet Swiss Grid Initiative piloté par le CSCS [12], a donc été lancé. Schématiquement, afin d’intégrer tout ou partie du parc informatique de l’EPFL dans une grille, une approche consiterait à

  • donner l’apparence d’une entité unique aux machines de bureau du site (salles de cours dans un premier temps) à l’aide d’un intergiciel spécifique ;
  • choisir un intergiciel global permettant de rendre toutes les ressources (clusters + grilles de machines de bureau) visibles comme une seule et dont l’accès serait transparent pour les utilisateurs.

Réseau de machines de bureau

Le site comprenant essentiellement des machines Windows et Linux, il est nécessaire de choisir un intergiciel multi-plateforme. Actuellement, PBSPro, qui s’avère facilement interfaçable avec un intergiciel global, est à l’étude. Il a également l’avantage de faire entrer automatiquement un noeud dans l’ensemble des machines de la grille dès qu’il devient inactif et de l’en sortir dans le cas contraire.

Intelligent grid Scheduling System

En collaboration avec le CSCS et l’École d’Ingénieurs de Fribourg (EIA-FR), l’EPFL travaille au développement d’un système d’ordonnancement intelligent (ISS) (Intelligent grid Scheduling System), que l’on peut considérer comme un module d’un intergiciel global. Schématiquement, lors de la soumission d’une tâche à la grille, ISS déterminera sur quelle machine la tâche sera exécutée, après analyse de l’adéquation de l’architecture machine à la tâche, du temps probable nécessaire pour l’obtention des résultats et du prix d’utilisation de la machine. La collaboration sur ce projet s’est étendue à deux instituts allemands, (Fraunhofer Institute SCAI et Research Center Jülich), en vue de l’intégration d’ISS à Unicore [13]. Un prototype sera d’ailleurs installé et testé cet été sur les clusters Pleiades (STI). En résumé, la future grille de l’EPFL pourrait donc ressembler au schéma de la figure 3.

JPEG - 4.4 ko
fig. 3
Projet de grille à l’EPFL

Références

[1] Foster, I. et C. Kesselman, The Grid : Blueprint for a New Computing Infrastructure, Morgan Kaufmann, 1999.
[2] Chetty, M. et R. Buyya, Weaving Computational Grids : How Analogous Are they with Electrical Grids ?, Computing in Science & Engineering, July/August 2002.
[3] Seti@home, http://setiathome.ssl.berkeley.edu
[4] Kopela, E., D. Wertheimer, D. Anderson, J. Cobb et M. Lebofsky, Seti@home - massively distributed computing for seti, Computing in Science & Engineering, 3(1):78 - 83, January/February 2001.
[5] Foster, I., C. Kesselman et S. Tuecke, The Anatomy of the Grid : Enabling Scalable Virtual Organization, The International Journal of High Performance Computing Applications, 15(3), 2001
[6] Global Grid Forum, http://www.gridforum.org/
[7] Organization for the Advancement of Structured Information Standards, http://www.oasis-open.org/home/index.php
[8] Globus Alliance et GlobusToolkit, http://www.globus.org
[9] Unicore Forum et Unicore, http://www.unicore.org [10] Abdennadher, N. et R. Boesch, Vers un outil Peer-to-Peer orienté calcul intensif, fi/SP05
[11] GRID@EPFL, http://grid.epfl.ch
[12] Swiss National Supercomputing Center, http://www.cscs.ch
[13] Keller, V., K. Cristiano, R. Gruber, P. Kuonen, S. Maffioletti, N. Nellari, M.-C. Sawley, M. Spada, T.M. Tran, O. Wäldrich, P. Wieder et W. Ziegler, Integration of ISS into the VIOLA Meta-Scheduling Environment, CoreGRID, TR-0025, January 2006

[1] Il succède aux standards OGSA (Open Grid Services Architecture) et OGSI (Open Grid Services Infrastructure).



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.