imprimer
n°11
Mai
2010
Transition EGEE / EGI

Nous traversons une période de transition marquée par la fin du cycle des projets EGEE. Le dernier EGEE User Forum à Uppsala en Avril a été de ce point de vue à la fois triste et joyeux : triste parce qu’il marque la fin d’un cycle de projets et que certaines communautés d’utilisateurs sont très inquiètes du lendemain et joyeux parce que c’était la première apparition publique au niveau international de l’Infrastructure de Grille Nationale française France Grilles. Je tiens à remercier toutes celles et tous ceux qui ont participé à l’animation du stand et dire ma joie de voir petit à petit les vêtements et les ordinateurs s’accumuler à l’intérieur du stand à mesure que les journées passaient. [1]

Beaucoup de personnes se posent des questions sur l’articulation entre le Groupement d’Intérêt France Grilles, l’Institut des Grilles, la NGI (National Grid Initiative) France et LCG France. Ce n’est pas simple et je vais essayer de l’expliquer de façon simplifiée.

France Grilles est le nom du Groupement d’Intérêt Scientifique créé entre le CEA, la Conférence des Présidents d’Universités (CPU), le CNRS, l’INRA, l’INRIA, l’INSERM , RENATER et le Ministère de la Recherche. Il a été créé pour coordonner le déploiement d’une infrastructure de grille nationale.
Ses missions principales sont les suivantes :

Etablir une infrastructure (...)

lire la suite

EGEE

CIC Portal

Le Portail des Opérations d’EGEE [1], développé au Centre de Calcul de l’IN2P3 depuis Novembre 2004, et aussi utilisé par le projet WLCG, est un portail web déployé pour différentes catégories d’acteurs opérationnels : responsable des opérations, responsables de fournisseurs de ressources de calcul et de stockage (sites), responsables de communauté d’utilisateurs (regroupées par discipline scientifique), ou bien encore utilisateurs finaux de l’ensemble des ressources informatiques participant au projet de grille européenne de production EGEE. Les fonctionnalités principales de ce portail sont la détection et le suivi de problèmes sur les sites en production, la mise à disposition d’informations opérationnelles sur les communautés d’utilisateurs, et des fonctionnalités de reporting. Le portail dispose aussi d’une plate-forme de communication transversale au projet, reliant des partenaires distribués dans plus de 130 institutions. En outre, l’utilisation d’outils de notifications d’incidents sur les sites a permis d’assurer une fluidité dans le quotidien des opérations du projet. Si, au départ, le projet portait sur une (...)

lire la suite

Cloud Computing

StratusLab

EGI (« European Grid Infrastructure »), une infrastructure de grille pérenne en Europe, a débuté le 1er mai dernier. Elle représente l’aboutissement de plusieurs projets Européens et nationaux qui ont été menés durant les dix dernières années. Environ 14.000 chercheurs et ingénieurs de domaines scientifiques variés l’utilisent quotidiennement pour leurs analyses scientifiques. Cette infrastructure est essentiellement une initiative académique. Au cours des trois dernières années est apparue dans le monde commercial une autre espèce d’infrastructure distribuée : le « cloud » (nuage). Le projet StratusLab [1], qui débutera le 1er juin, a pour objet de produire une distribution logicielle permettant la mise en œuvre d’un cloud « privé », principalement destiné à déployer des sites grille. Grâce à elle, EGI pourra offrir un service plus performant et qui intéressera une gamme d’utilisateurs encore plus diversifiée. La forte utilisation actuelle de la grille montre que l’infrastructure grille répond bien aux besoins d’une fraction importante de chercheurs européens. Grâce à un système global de sécurité qui garantit la confiance entre tous les (...)

lire la suite

Grille

L’accès aux grilles de calcul facilité par le Projet DIRAC.

Aujourd’hui, les projets scientifiques produisent et analysent une quantité d’information sans précèdent, ce qui nécessite une puissance de calcul jamais vue auparavant. Les leaders dans ce défi de traitement de données sont les expériences du LHC au CERN, qui accumulent des dizaines de Pétaoctets de données chaque année. Cependant, il se révèle que d’autres domaines scientifiques s’approchent aussi de ces limites. Très vite, il est devenu évident qu’aucun centre de calcul ne peut fournir, à lui seul, assez de ressources pour la gestion de toutes ces données. Par conséquent, nous devons exploiter les ressources disponibles à travers le monde de manière à ce que les utilisateurs les considèrent comme un seul super ordinateur, facile à gérer. C’est pourquoi le concept de Grille de Calcul a été proposé. Mais ses premiers prototypes ont rencontré bien des difficultés. Cela a conduit les 4 expériences du LHC à développer chacune sa propre solution au problème de la production massive de données. Dans le cas de l’expérience LHCb, cette solution a (...)

lire la suite

Calcul

Evolution du système de batch du Centre de Calcul IN2P3 (CC)

Courant 2009, le CC a décidé de faire évoluer son système de batch, et, plus précisément, a envisagé l’arrêt des développements de son produit historique, BQS (Batch Queueing System), pour le remplacer par une solution existant par ailleurs.

lire la suite

Equipe

Responsables éditoriaux : Dominique Boutigny et Cristinel Diaconu
Comité de rédaction : Virginie Dutruel, Sébastien Grégoire, Eric Legay, Gaëlle Shifrin et Tiffany Thome

Interview

Ikuo UEDA

"... je ne vois pas beaucoup de différences en ce qui concerne les méthodes de travail des deux pays."
#TITRE
Equipe centrale des opérations de l’informatique distribuée d’ATLAS / CERN

lire l'interview

A noter
Conseil Scientifique de l’Institut des Grilles
Le Conseil Scientifique de l’Institut des Grilles est en charge de superviser la pertinence et (...)

en savoir plus

Agenda
Formation Informatique et Eco-responsabilité - 12 au 15 octobre - Autrans (38)
Le groupe de travail EcoInfo propose une formation générale à "l’éco-responsabilité appliquée à (...)

en savoir plus

Atelier Technique France Grilles - 31 mai 2010 - CNRS / Délégation Paris Michel-Ange
L’atelier technique France Grilles constitue le véritable lancement de la grille de production (...)

en savoir plus

Conférence CHEP - Du 18 au 22 octobre - Taipei
La conférence CHEP 2010 se tiendra à Taipei du 18 au 22 octobre 2010. Pour plus d’informations : (...)

en savoir plus

Rencontres LCG-France Sites/Expériences - 24 et 25 juin - Marseille
Les prochaines rencontres LCG-France Sites/Expériences sont prévues les 24 et 25 juin à (...)

en savoir plus

Rechercher
Abonnement
Pour vous abonner/désabonner, suivez ce lien.
Proposer un article
Vous souhaitez proposer un article ? Envoyez un mail à LettreInformatique@in2p3.fr.
logo CCIN2P3
© 2010 CCIN2P3
n°11
Mai
2010
Transition EGEE / EGI

Nous traversons une période de transition marquée par la fin du cycle des projets EGEE. Le dernier EGEE User Forum à Uppsala en Avril a été de ce point de vue à la fois triste et joyeux : triste parce qu’il marque la fin d’un cycle de projets et que certaines communautés d’utilisateurs sont très inquiètes du lendemain et joyeux parce que c’était la première apparition publique au niveau international de l’Infrastructure de Grille Nationale française France Grilles. Je tiens à remercier toutes celles et tous ceux qui ont participé à l’animation du stand et dire ma joie de voir petit à petit les vêtements et les ordinateurs s’accumuler à l’intérieur du stand à mesure que les journées passaient. [1]

Beaucoup de personnes se posent des questions sur l’articulation entre le Groupement d’Intérêt France Grilles, l’Institut des Grilles, la NGI (National Grid Initiative) France et LCG France. Ce n’est pas simple et je vais essayer de l’expliquer de façon simplifiée.

France Grilles est le nom du Groupement d’Intérêt Scientifique créé entre le CEA, la Conférence des Présidents d’Universités (CPU), le CNRS, l’INRA, l’INRIA, l’INSERM , RENATER et le Ministère de la Recherche. Il a été créé pour coordonner le déploiement d’une infrastructure de grille nationale. Ses missions principales sont les suivantes :
- Etablir une infrastructure nationale de Grilles de production, pour le stockage et le traitement de données scientifiques massives en coordonnant les efforts de chaque associé et promouvoir son usage dans toutes les communautés scientifiques ;
- Contribuer, avec les autres "Infrastructures Nationales de Grille" des Etats membres impliqués, au fonctionnement de l’infrastructure européenne EGI
- Favoriser l’organisation au plan national d’une communauté utilisatrice par l’organisation de formations, de séminaires, par la diffusion d’informations sur les grilles ;
- Favoriser les coopérations académiques ou d’intérêt industriel, nationales ou internationales, utilisant les Grilles et à travers elles les usages avancés du calcul, de la gestion de données scientifiques, et les services innovants rendus possibles par les Grilles ;
- Favoriser les rapprochements et les échanges entre les équipes des Parties travaillant sur les Grilles de Production et les grilles de recherche ;
- Faciliter l’établissement de stratégies concertées et la coopération avec les organisations mises en place concernant les réseaux de communication électroniques destinés à la recherche et l’enseignement supérieur, et notamment le GIP RENATER et l’infrastructure européenne GEANT ainsi que les autres réseaux pour la recherche dans le monde.

Dans le jargon du monde des grilles, on peut donc dire que le GIS France Grilles est la NGI France, l’Initiative de Grille Nationale Française. Aujourd’hui, la France dispose d’atouts exceptionnels :
- le G.I.S France Grilles, entité légale dans laquelle inscrire les actions techniques, scientifiques et même médiatiques au niveau national et qui est habilité à parler au nom de la NGI France au niveau international
- la grille de production française, labellisée Très Grande Infrastructure de Recherche par le Ministère de la Recherche et à ce titre bénéficiaire d’un financement pluriannuel démarré en 2009.
- LCG France, colonne vertébrale de la grille de production française, appuyée sur les personnels et les équipements des laboratoires de l’IN2P3. Le financement des équipements pour LCG France est indépendant du financement de la grille de production et l’objectif sera de mettre en place des synergies pour un bénéfice mutuel.
- Des communautés d’utilisateurs hors de la physique des particules (sciences de la vie, sciences de la planète, SHS) qui ont des besoins importants et qui ont déjà acquis une expérience solide et reconnue de l’utilisation des grilles
- la communauté scientifique structurée autour de la grille de recherche nationale Grid5000 constitue un partenaire naturel pour développer des collaborations à long terme
- plusieurs projets européens qui démarrent en 2010 (EUMedGrid-Support, DEGISCO, EDGI, EGI-Inspire, SHIWA, StratusLab) où les acteurs du GIS France Grilles sont fortement présents voire même leaders.

Et l’Institut des Grilles dans tout cela ? L’Institut des Grilles du CNRS représente le CNRS dans le GIS France Grilles. Il va être amené à jouer un rôle central dans le fonctionnement du GIS au niveau technique et au niveau scientifique. Le CNRS a été présent dans les projets européens depuis DataGrid aux côtés du CEA et sa vocation pluridisciplinaire le qualifie pleinement pour être le moteur du GIS. Au moment où j’écris ces lignes, le texte final du GIS est en cours de signature par ses tutelles. La prochaine étape est la mise en place des structures exécutives et le remplissage de l’organigramme d’ici l’été. Les premiers défis des personnes nommées seront de mettre en route les opérations de la NGI France et de préparer la réponse à l’appel à projets d’équipements technologiques d’excellence du Grand Emprunt National dont l’ouverture est imminente.

Pour finir, je voudrais tous vous inviter à l’atelier technique France Grilles le 31 Mai 2010 au siège du CNRS à Paris. Ce sera le véritable lancement de la grille de production française. Toute une équipe d’ingénieurs, notamment au CC-IN2P3, a travaillé pour préparer la transition depuis EGEE pour qu’elle soit totalement transparente aux utilisateurs. Un nouveau portail http://www.france-grilles.fr est en cours de finalisation qui doit être LE portail unique de la grille de production française. Nous avons énormément de pain sur la planche : je suis très encouragé quand je vois la motivation des ingénieurs et des chercheurs. La vraie richesse de tous ces projets, le vrai atout pour leur réussite, ce sont les femmes et les hommes qui se battent pour les mener à bien.

Vincent Breton

[1] Les personnes présentes au EGEE User Forum comprendront.

n°11
Mai
2010

"... je ne vois pas beaucoup de différences en ce qui concerne les méthodes de travail des deux pays."

Ikuo UEDA

Equipe centrale des opérations de l’informatique distribuée d’ATLAS / CERN

Né au Japon, Ikuo UEDA a étudié la physique à l’Univesité de Tokyo et travaillé sur une expérience embarquée sur un ballon lors de ses études en doctorat et pendant le post-doctorat. L’expérience se déroulait au Canada, tous les ans, dans le but de mesurer les flux anti-proton et faire de la recherche des noyaux anti-hélium dans les rayons cosmiques. Il est ensuite venu en France en 1997, en tant qu’associé de recherche du Centre International pour la Physique Elémentaire des Particules (ICEPP) de l’Université de Tokyo, afin de travailler au CERN sur l’expérience OPAL qui se déroulait au LEP. Quelques années plus tard, il a commencé à travailler sur ATLAS au LHC.


En quoi consiste votre travail sur l’expérience LHC ?

L’institut auquel je suis rattaché, l’ICEPP, joue le rôle de centre régional au Japon. Ainsi, ma première mission dans le LHC a été d’établir le centre régional à Tokyo et de coordonner les activités liées au traitement de données avec des collègues japonais. A cette époque, il y avait les concepts de « centres régionaux » et de « tiers », mais nous n’avions pas le WLCG et notre principale préoccupation était de trouver comment conserver une bonne connexion au CERN Tier-0 malgré la grande distance. Depuis qu’ATLAS a adopté le concept de nuage et que le centre régional de Tokyo a décidé de ce joindre au nuage français, j’ai étroitement travaillé avec les collègues français, principalement sur la distribution de données. Je fais désormais partie de l’équipe centrale des opérations de l’informatique distribuée d’ATLAS, en travaillant notamment sur le suivi au quotidien de l’infrastructure distribuée pour le traitement des données de l’expérience.

Quelles sont vos relations avec les laboratoires de l’IN2P3 ?

J’ai travaillé en tant que chercheur associé avec l’IN2P3/LAPP en 2008 et en 2009 dans le cadre du programme d’échange de chercheurs du CNRS. L’objectif était d’établir un flux de données régulier à l’intérieur du nuage français et d’être préparés au démarrage de l’accélérateur et de l’expérience.

Quelles différences avez-vous constatées entre les méthodes de travail des français et celles des japonais ?

En regardant les personnes travaillant dans la physique et l’informatique dans le domaine de la physique des hautes énergies, je ne vois pas beaucoup de différences en ce qui concerne les méthodes de travail des deux pays. La manière de penser et d’aborder les problèmes me semble assez semblable. Pour moi, les différences portent plutôt sur les personnalités que sur les nationalités. Une des différences flagrante est le temps passé au bureau : beaucoup de mes collègues japonais restent sur le lieu de travail jusque tard dans la nuit, alors que je ne vois pas de collègues français pendant la nuit. Je sais cependant que certains d’entre eux travaillent depuis chez eux. Mes collègues japonais pensent probablement qu’il est plus efficace de travailler dans leur bureau, alors que mes collègues français jugent qu’il est plus important d’être à la maison. Ou peut-être, est-ce simplement le fait que mon expérience de la façon de travailler des japonais date de quelques années, avant que je ne vienne en France, et qu’à cette époque, nous n’avions pas une bonne connexion réseau à notre domicile.

Propos recueillis par Tiffany Thomé

n°11
Mai
2010
CIC Portal

Le Portail des Opérations d’EGEE [1], développé au Centre de Calcul de l’IN2P3 depuis Novembre 2004, et aussi utilisé par le projet WLCG, est un portail web déployé pour différentes catégories d’acteurs opérationnels : responsable des opérations, responsables de fournisseurs de ressources de calcul et de stockage (sites), responsables de communauté d’utilisateurs (regroupées par discipline scientifique), ou bien encore utilisateurs finaux de l’ensemble des ressources informatiques participant au projet de grille européenne de production EGEE.

Les fonctionnalités principales de ce portail sont la détection et le suivi de problèmes sur les sites en production, la mise à disposition d’informations opérationnelles sur les communautés d’utilisateurs, et des fonctionnalités de reporting. Le portail dispose aussi d’une plate-forme de communication transversale au projet, reliant des partenaires distribués dans plus de 130 institutions. En outre, l’utilisation d’outils de notifications d’incidents sur les sites a permis d’assurer une fluidité dans le quotidien des opérations du projet.

Si, au départ, le projet portait sur une trentaine de sites en production , et sur trois fournisseurs d’informations - outils opérationnels centraux - aujourd’hui le portail permet de suivre plus de 260 sites et une dizaine de sources d’informations différentes.

Si le portail des opérations EGEE a suivi le changement d’échelle du projet EGEE au fil des ans, en mettant en œuvre de façon réactive les demandes du projet, il a aussi permis de faire le prototype des évolutions du modèle opérationnel depuis 6 ans. De plus, il a su évoluer dans les technologies utilisées pour sa conception, afin de refléter les évolutions du projet lui-même, et des composants de son intergiciel, de ses outils opérationnels ou de l’ évolution de ces procédures.

Pour se faire, les développements se sont organisés autour d’un service d’accès uniforme à des sources de données hétérogènes : Lavoisier [2]. Ce service permet ainsi de récupérer des données hétérogènes, de les organiser, de les croiser à travers des vues et de les rendre disponibles sous forme d’interfaces ou alors de flux RSS ou XML.

La collecte croissante de sources d’informations et de demandes d’interface, nous a poussé en outre à reconsidérer une partie des développements du module Web dans un framework.

Cette dernière restructuration réalisée durant EGEE-III permet d’effectuer une transition vers le but affiché de pérennisation de l’infrastructure du projet EGEE dans le cadre de la coordination de EGI. En effet, l’efficience de la maintenance, ainsi que les possibilités de personnalisation de l’outil et de la structure modulaire permettent de proposer des versions de fonctionnalités pertinentes qui sont « packagées » et qui fonctionnent localement au sein des futures collaborations nationales de grille, partenaires principales de la structure EGI. Notre idée est de proposer une vue régionale des interfaces hébergées, sur une instance centrale dans un premier temps, afin de parvenir dans un deuxième temps à proposer une version distribuée dans les différentes régions. En fait, les diverses instances nationales pourront opter pour l’une ou l’autre solution sans risquer de dysfonctionnement de la supervision internationale des opérations.

Cette démarche est appliquée de manière progressive aux fonctionnalités phares du portail et la première à avoir été considérée a été le tableau de bord des opérations ou « operations dashboard » [3].

Ce « dashboard » est en fait bien plus que l’agrégation de différents indicateurs et informations concernant les sites à travers un tableau de bord synthétique. Intégrant aussi bien des informations de supervision, des informations administratives sur les sites, ou l’accès aux historiques des incidents, l’outil permet à travers une vue synoptique d’identifier rapidement un incident et de le traiter grâce à des procédures et des outils développés de facçon spécifique (en particulier un opérateur chargé de la surveillance des sites de production peut créer et/ou suivre des tickets d’incident sur une seule et même interface). Les incidents sur les sites de toute la grille EGEE peuvent donc être traités par une équipe d’opérateurs en rotation au niveau central à l’aide de cet outil.

Ce dispositif, qui regroupe une communauté d’opérateurs et qui met en place des procédures et des outils dédiés, a été reconnue comme un facteur clef de la fiabilisation de la « grille » de production dès 2007. De plus, ce modèle de fonctionnement au quotidien s’est avéré durable puisque la charge de travail est restée stable malgré l’augmentation du nombre de sites en production.

Depuis 2008, dans la phase finale du projet EGEE, le modèle opérationnel a évolué vers un modèle pérenne en transférant la plupart des opérations aux fédérations de pays en Juin 2009. Les équipes d’opérateurs se sont donc concentrées sur une supervision permanente au sein de leur propre région avec une coordination minime au niveau international. Ce modèle, évalué à l’aide de métriques depuis l’automne 2009, est considéré comme stable. C’est sur ce modèle des opérations qu’est fondé EGI, qui a commencé à compter du 1er Mai 2010.

Aujourd’hui, le challenge est notamment de faire évoluer, de façon similaire au « dashboard », le reste des fonctionnalités du portail dans le cadre de notre nouvelle mission de portail des opérations EGI.

Cyril L'Orphelin

[1] http://cic.gridops.org

[2] http://grid.in2p3.fr/lavoisier

[3] https://operations-portal.in2p3.fr

n°11
Mai
2010

Renforcement des Infrastructures de Grille grâce aux Technologies "Cloud" et de Virtualisation

StratusLab

EGI (« European Grid Infrastructure »), une infrastructure de grille pérenne en Europe, a débuté le 1er mai dernier. Elle représente l’aboutissement de plusieurs projets Européens et nationaux qui ont été menés durant les dix dernières années. Environ 14.000 chercheurs et ingénieurs de domaines scientifiques variés l’utilisent quotidiennement pour leurs analyses scientifiques. Cette infrastructure est essentiellement une initiative académique. Au cours des trois dernières années est apparue dans le monde commercial une autre espèce d’infrastructure distribuée : le « cloud » (nuage). Le projet StratusLab [1], qui débutera le 1er juin, a pour objet de produire une distribution logicielle permettant la mise en œuvre d’un cloud « privé », principalement destiné à déployer des sites grille. Grâce à elle, EGI pourra offrir un service plus performant et qui intéressera une gamme d’utilisateurs encore plus diversifiée.

La forte utilisation actuelle de la grille montre que l’infrastructure grille répond bien aux besoins d’une fraction importante de chercheurs européens. Grâce à un système global de sécurité qui garantit la confiance entre tous les acteurs, un chercheur peut accéder à des ressources informatiques distribuées. Inversement, il peut partager ses expertises, algorithmes, données et ressources informatiques avec les autres membres de son Organisation Virtuelle via la grille. Malgré ces succès, la grille présente aux utilisateurs un environnement hétérogène qui diminue le taux de réussite des jobs et n’offre pas la capacité de déployer des services « niveau utilisateur » pour traiter les grosses analyses.

La technologie cloud promet de corriger ces défauts. Le cloud utilise intensivement la virtualisation des machines, qui permet à chaque Organisation Virtuelle, voire chaque utilisateur, de personnaliser son environnement d’exécution et donc de faciliter le portage des applications sur la grille, et éviter les problèmes qui découlent de l’hétérogénéité. De plus, l’utilisation en mode « cloud » permet aux chercheurs de déployer aussi les serveurs sur les ressources grilles. Cette possibilité est utile par exemple dans le cas des systèmes maitre/esclaves où le maitre coordonne un grand nombre des tâches. Aujourd’hui, le maitre est typiquement l’ordinateur personnel d’un chercheur, qui doit rester connecté pendant l’analyse, ou un serveur réservé à cet usage au laboratoire.

En résumé, StratusLab veut créer une distribution qui permette à un administrateur système de déployer un nuage privé. Il installe les services grilles sur ce nuage et offre à ses utilisateurs les avantages des technologies à la fois grille et cloud. Pour valider cette distribution, le projet va mettre en œuvre deux sites grille et mesurer les performances avec une gamme d’applications représentatives. La première version opérationnelle est prévue pour septembre prochain, suivie par beaucoup d’autres sur un rythme fréquent.

Le Laboratoire de l’Accélérateur Linéaire (LAL, Orsay) est impliqué dans trois aspects du projet : la coordination, les interactions avec les utilisateurs, et la mise en œuvre d’un site StratusLab. L’Institut de Biologie et Chimie des Protéines (IBCP, Lyon) est en charge de la liaison avec la communauté bioinformatique qui va tester la distribution initiale et les nouvelles fonctionnalités. Le coût total du projet est d’environ 3,3 M€, pour un effort de 340 hommes mois, avec une contribution de la Commission Européenne de 2,3 M€. La partie CNRS est de 470 k€ pour 81 hommes mois. Il compte six partenaires de cinq pays différents (FR, ES, GR, CH, IE).

Du fait du grand intérêt actuel pour la technologie cloud, StratusLab n’est pas seul dans ce domaine. Il existe beaucoup de sites qui ont déjà déployé des nuages et conduit des tests avec les outils existants. Le projet a pour ambition de devenir le centre des activités open source cloud en Europe pour faciliter l’échange d’informations et d’édifier les bases d’une collaboration qui perdurera après son achèvement.

Charles Loomis

[1] http://stratuslab.eu/

n°11
Mai
2010
L’accès aux grilles de calcul facilité par le Projet DIRAC.

Aujourd’hui, les projets scientifiques produisent et analysent une quantité d’information sans précèdent, ce qui nécessite une puissance de calcul jamais vue auparavant. Les leaders dans ce défi de traitement de données sont les expériences du LHC au CERN, qui accumulent des dizaines de Pétaoctets de données chaque année. Cependant, il se révèle que d’autres domaines scientifiques s’approchent aussi de ces limites. Très vite, il est devenu évident qu’aucun centre de calcul ne peut fournir, à lui seul, assez de ressources pour la gestion de toutes ces données.

Par conséquent, nous devons exploiter les ressources disponibles à travers le monde de manière à ce que les utilisateurs les considèrent comme un seul super ordinateur, facile à gérer. C’est pourquoi le concept de Grille de Calcul a été proposé. Mais ses premiers prototypes ont rencontré bien des difficultés. Cela a conduit les 4 expériences du LHC à développer chacune sa propre solution au problème de la production massive de données.

Dans le cas de l’expérience LHCb, cette solution a été proposée par le projet DIRAC. Le projet DIRAC a débuté en 2003 dans le but de fournir à la Collaboration LHCb un système de la production massive de données de modélisation du détecteur. Le projet a présenté plusieurs innovations, parmi lesquelles le système d’ordonnancement des tâches avec Jobs Pilotes. Ce système a permis de construire un système distribué de plus de 20 centres de calcul avant même que les solutions Grille soient en place. En 2004, la Grille LCG a été mise en production et LHCb a assuré sa première utilisation massive avec un succès, grâce au système DIRAC, qui a permis de surmonter les instabilités du logiciel Grille (middleware) encore inachevé. Dans les années qui ont suivi, DIRAC est passé d’un système de production de données de simulation Monte-Carlo à un middleware complet, utilisé par la Collaboration LHCb pour tous les besoins en matière de calculs distribués : de la distribution des données du détecteur et leur reconstruction jusqu’à l’analyse finale par les utilisateurs. Sa performance est caractérisée par sa capacité à gérer jusqu’à 30 milles tâches tournant simultanément sur plus de 150 sites, ce qui est équivalent au fonctionnement d’un centre de calcul virtuel comparable à celui du CERN.

Depuis le début, l’équipe du projet DIRAC avait pour but de produire un logiciel bien organisé, facilement extensible aux besoins des utilisateurs. Il a été complètement réécrit deux fois, pour pouvoir prendre en compte l’expérience acquise lors des productions massives des données. Par conséquent, DIRAC est maintenant devenu le middleware d’application générale, ou les parties spécifiques au LHCb sont bien séparées. Ainsi, cette solution peut être proposée à d’autres communautés d’utilisateurs.

Quelle technologie avancée DIRAC peut-il mettre à la disposition de ses utilisateurs ? Avant tout, DIRAC est basé sur le cadre logiciel pour la construction des système distribués orienté service (nommé DISET) qui est entièrement compatible avec les standards grille de sécurité et permet de définir les règles d’autorisation précises. Cela permet d’ajouter très facilement de nouveaux services, ce qui fait de DIRAC un système flexible, qui s’adapte aux besoins d’une communauté spécifique d’utilisateurs. Le système d’ordonnancement des tâches (Workload Management System - WMS) de DIRAC est basé sur le cadre DISET. Pour un utilisateur occasionnel il peut très bien être utilisé de la même manière que le WMS gLite. Toutefois, il est basé sur le concept de Jobs Pilotes. Cette méthode augmente l’efficacité d’exécution des tâches d’utilisateur.

Mais c’est surtout pour les grandes communautés d’utilisateurs que DIRAC révèle son efficacité réelle. Les grandes communautés ont des groupes internes qui utilisent des ressources de calcul communes. Il est donc nécessaire de définir des priorités pour les groupes, en accord avec la politique de la communauté. Le middleware gLite ne fournit pas les moyens pour prioriser des tâches. Avec DIRAC, cet arbitrage peut être appliqué dans sa Queue des Tâches Centrale, de manière similaire aux systèmes batch standards. Grâce à cela, les utilisateurs LHCb bénéficient d’une exécution plus rapide de leurs tâches car ils ne souffrent pas d’une compétition avec l’activité de la production de données de priorité inferieure.

Un autre problème est fréquemment rencontré avec les grandes communautés : elles ont typiquement accès à différentes ressources informatiques, mais cet accès n’est pas uniforme puisqu’il est géré par les systèmes WMS spécifiques. C’est là où le concept de Jobs Pilotes se révèle très utile. Il suffit de soumettre les Jobs Pilotes aux différentes ressources hétérogènes, ce qui est pris en charge par DIRAC. Les Jobs Pilotes présentent toutes les ressources de manière uniforme et les utilisateurs bénéficient, comme par magie, d’un accès transparent. Dans le cas de LHCb, cette méthode a été présentée en regroupant les ressources des Grilles EGEE, EELA et NORDUGRID. Plus récemment, un exercice similaire a eu lieu pour l’expérience Belle, au KEK, Japon, dans le but d’inclure le Nuage de Calcul ( Computing Cloud ) – la ressource de calcul commerciale fournit par la société Amazon. D’autres ressources, comme des grappes de calcul ou même des ordinateurs de bureau individuels peuvent aussi être intégrés. Le Système de Gestion de la Production (Production Management System – PMS) est basé sur le WMS et permet la définition et exécution de séquences complexes des tâches (workflows) de façon tout à fait automatique déclenchée par la disponibilité de données à traiter. Le Système de Gestion de Données de DIRAC inclut des Catalogues de Réplicas et de Métadonnées complets mais l’utilisation des Catalogues standard de gLite est aussi possible. Les fonctionnalités d’un plus haut niveau incluent la réplication automatique des données, en accord avec des algorithmes spécifiques qui peuvent être fournis comme plugins. Des outils pour la vérification de l’intégrité des données sont également disponibles. Tout cela permet de gérer le système complexe de production de données du LHCb avec un seul operateur de production.

Chez DIRAC, une grande attention est portée aux interfaces utilisateurs, dans le but de les rendre le plus pratique possible. Une interface en ligne de commande est disponible, mais aussi une librairie Python pour les utilisateurs plus avancés. Toutefois, il est de plus en plus commun de voir des applications grilles complétées par des interfaces graphiques dédiées, pour plus de commodité et d’efficacité. DIRAC propose aussi une interface utilisateur graphique basée sur son cadre de Portail Web. Ce cadre permet de construire les interfaces Web à tous les services DIRAC avec la sécurité d’accès sans compromis grâce au système de délégation d’accrédités des utilisateurs intégré. Pratiquement toutes les opérations de DIRAC peuvent être exécutées via son Portail Web : de l’administration du système jusqu’au monitorage des tâches des utilisateurs. Les pages web du système PMS de LHCb sont un bon exemple de Portail Web pour une application complexe. Des portails similaires peuvent facilement être fourni pour d’autres applications. Pour un utilisateur qui souhaiterait l’essayer, il y a un outil Web simple pour la soumission des tâches sur la grille, avec la possibilité de téléchargement des fichiers d’entrée et de sortie. Une fois la tâche soumise, son progrès peut être suivi, tout en en ayant accès aux résultats intermédiaires.

Le projet DIRAC a déjà traversé une longue période d’évolution, et a prouvé sa valeur pour la Collaboration LHCb et d’autres utilisateurs dans le domaine de la physique des particules et bien d’autres. Maintenant, le projet est ouvert à de nouvelles applications et aide encore plus de communautés d’utilisateurs dans l’univers des grilles de calcul.

Andreï Tsaregorodtsev

n°11
Mai
2010
Evolution du système de batch du Centre de Calcul IN2P3 (CC)
Grille d'évaluation par thèmes

Courant 2009, le CC a décidé de faire évoluer son système de batch, et, plus précisément, a envisagé l’arrêt des développements de son produit historique, BQS (Batch Queueing System), pour le remplacer par une solution existant par ailleurs.

Petit rappel : les premiers balbutiements de BQS remontent aux années 1992-1993 lorsque le CC est passé de l’environnement VM (mainframe centralisé) à l’environnement Unix (informatique distribuée). Yves Fouilhé [1] fut initialement « porteur » de ce logiciel, suivi, plus tard par Bernard Chambon [2] et Julien Devemy [3]. BQS a subi de profondes évolutions au cours des années, telles le stockage en base de données, le multithreading, la fonctionnalité de jobs parallèles, le fairshare à deux niveaux. BQS a ainsi pu absorber une forte monté en charge (x10 entre 2004 et 2009) tout en fournissant un service de grande qualité : actuellement plus de 10,000 cœurs de calcul et un flux quotidien d’environ 100,000 jobs.

Mais l’environnement de travail s’ouvrant vers l’extérieur, il convenait de s’orienter vers une solution adoptée par ailleurs.

C’est dans ce contexte qu’une étude a été lancée courant 2009, visant à trouver, parmi les produits existants, la meilleure solution, si possible adoptée dans la communauté HEP, et prenant en compte les différentes contraintes du CC. S’appuyant sur l’expérience acquise pendant plus de 15 ans avec BQS, l’étude a commencé par le recensement des caractéristiques principales d’un système de batch. Ces éléments ont permis de construire une grille de plus de 60 critères regroupés sous 15 thèmes majeurs (cf. : Schéma). Un système de pondération et de notes par critère et par thème a ensuite permis d’obtenir une note d’appréciation globale.

Se référant à cette grille d’évaluation et à différentes sources de données, auxquelles s’est ajoutée une enquête sur les retours d’expérience d’administrateurs de systèmes de batch, l’étude s’est poursuivie par l’inventaire des solutions existantes, tant commerciales qu’en open-source.

Parmi les différents systèmes considérés (LSF, PBS-Pro, SGE, Torque/Maui, Slurm, Condor, OAR, LoadLeveler…), deux solutions se sont démarquées, entre autre sur les critères de scalabilité, non négligeables eu égard au projet d’extension de la salle machine : LSF (Load Share Facilities de Platform Computing) et SGE (Sun Grid Engine). Afin de ne retenir qu’une seule de ces deux solutions, chacun de ces produits a été « pris en main » durant quelques jours. Il a été reconnu que ces logiciels sont assez comparables, offrant tous deux des fonctionnalités très riches, mais au regard des critères de la grille, le choix se porte actuellement sur SGE.

La mise en place du nouveau système de batch est maintenant imminente. L’opération, complexe, va solliciter au cours de cette année 2010, tous les services du CC, plus spécifiquement, l’exploitation et le support aux utilisateurs, mais également la collaboration des utilisateurs.

Exemple concret de l’adaptation permanente qu’exigent les métiers de l’informatique, ce travail est un véritable challenge pour toutes les personnes directement impliquées.

Bernard Chambon

[1] Yves Fouilhé : Développeur de BQS jusqu’à son départ à la retraite en 2008.

[2] Bernard Chambon : Développeur sur BQS depuis 2002.

[3] Julien Devemy : Développeur sur BQS parallèle.

n°11
Mai
2010
Rencontres LCG-France Sites/Expériences - 24 et 25 juin - Marseille

Les prochaines rencontres LCG-France Sites/Expériences sont prévues les 24 et 25 juin à Marseille, au CPPM.  Inscrivez dès maintenant ces dates importantes sur vos agendas. Informations et inscriptions sur Indico à l’adresse suivante : http://indico.in2p3.fr/conferenceDisplay.py?confId=3760

Conférence CHEP - Du 18 au 22 octobre - Taipei

La conférence CHEP 2010 se tiendra à Taipei du 18 au 22 octobre 2010. Pour plus d’informations : http://event.twgrid.org/chep2010/in...

Atelier Technique France Grilles - 31 mai 2010 - CNRS / Délégation Paris Michel-Ange

L’atelier technique France Grilles constitue le véritable lancement de la grille de production française. Le but de la journée est de présenter les structures opérationnelles, dont le nouveau portail http://france-grilles.fr, et de faire un bilan de la situation aux niveaux régional, national et européen dans cette période de transition EGEE à EGI.

Plus d’informations sur http://indico.in2p3.fr/conferenceDisplay.py?confId=3782

Formation Informatique et Eco-responsabilité - 12 au 15 octobre - Autrans (38)

Le groupe de travail EcoInfo propose une formation générale à "l’éco-responsabilité appliquée à l’information" (GreenIT) Le groupe de travail EcoInfo (CNRS) propose cette année une formation sur le thème de l’éco-responsabilité appliquée à l’informatique (GreenIT). Cette formation s’adresse aux informaticiens, DSI des secteurs recherche / universités / grandes écoles, une dizaine de personnes du secteur privé pourront également participer à cette formation.

Cette formation se présente sous la forme d’"école technologique" CNRS et propose des cours théoriques et des ateliers. Les intervenants sont des spécialistes de leur domaine, ils seront pour la plupart présents pendant l’ensemble de la formation, afin de rendre les échanges plus fructueux.

- Dates : du 12 octobre 2010 midi au 15 octobre 2010 14h.

- Lieu : Autrans, Massif du Vercors, Isère (38). L’hébergement se fait en résidentiel à l’Escandille. Une navette sera mise en place au départ de la gare de Grenoble.

- Public : responsables informatiques, directeurs des systèmes d’information, chargés de mise en œuvre d’une politique "greenIT", .. issus des secteurs recherche/enseignement supérieur (25 places) et secteur privé (10 places)

Le programme, les modalités de pré-inscription et d’inscription sont précisées ici : http://www.ecoinfo.cnrs.fr/spip.php?article167

Les délais sont relativement courts :
- pré-inscription par mail à l’adresse : Formation.Ecoinfo@grenoble.cnrs.fr avant fin mai,
- demande d’inscription définitive avant le 24 juin.

n°11
Mai
2010

Information

Conseil Scientifique de l’Institut des Grilles

A noter

Le Conseil Scientifique de l’Institut des Grilles est en charge de superviser la pertinence et la qualité scientifique des activités de l’institut. Il se réunit une fois par an afin de passer en revue et d’étudier les programmes de recherche et les contrats, d’évaluer les résultats et d’avancer des recommandations pour les orientations scientifiques ainsi que des suggestions d’action.

Cette année, il se réunira le 1 juin 2010 au CNRS - Délégation Paris Michel-Ange.