Category: EDGeS

1. Introduction à EDGeS

Dans le contexte du Traitement Distribué des Données, EDGeS est un projet permettant la communication entre la Grille de Service EGEE, qui utilise l’intergiciel gLite, et les Grilles de PC utilisant les intergiciels BOINC ou XtremWeb-HEP.EDGeS est un projet européen de Traitement Distribué des Données.

Financé par EC FP7 Research Infrastructures sous le numéro 211727, EDGeS a démarré le 01 Janvier 2008 et s’est achevé avec succès le 31 Mars 2010.

Le but était de permettre la communication entre la Grille de Service EGEE, qui utilise l’intergiciel gLite, et les Grilles de PC utilisant les intergiciels Boinc ou XtremWeb-HEP.

EDGeS a atteint ces objectifs et a même réussi à la communication entre la Grille de Service EELA, qui utilise l’intergiciel gLite, et la Grille de PC brésilienne utilisant l’intergiciel OurGrid.

EDGeS est maintenant relayé par les projets EDGI et DEGISCO.

Mise à jour de la passerelle XWHEP-EGEE

In the opposite of what announced before, each XWHEP deployment must have its own XWHEP->EGEE bridge due to performance problems. It appeared that it is too heavy to manage several XWHEP server on a single XWHEP->EGEE bridge. We then had to correct this bridge and implement a new version «V2» as member of activity «JRA1». As V2 was implemented and debugged, we deploy that new version in the context of this SA1 activity.

In V1, any job submitted with an X509 proxy had to be computed by an EGEE resource, and an EGEE resource only: an XWHEP resource had no chance to compute such a job. In V2, any job submitted with an X509 can be computed by any resource, including XWHEP (non secured resources) as well as EGEE ones (secured resources). The XWHEP logging and bookkeeping protocols and services ensure enough security to track any malicious behaviour. The end user X509 proxy security and integrity are still ensured because resources connected to XWHEP server never download X509 proxies. Their are exclusively and only downloaded and used by the bridge itself. This clearly means, in both versions, that the bridge must be run in a secured resource.

Figure «Fig 1 : XWHEP->EGEE bridge V1 Vs V2» shows the performances differences between V1 and V2. The blue line represent the amount of jobs submitted with an X509 certificate proxy -hence able to be computed by any EGEE resources. The green line represents the total amount of completed jobs, independently of their submission type (with or without X509 proxy), hence computed by XWHEP and EGEE resources. The red line represents job failures (data unavailable etc).
This figure also shows two different bar types: a black and a blue one. The black one represents the amount of connected EGEE resources.This resources are allocated when the XWHEP->EGEE bridge has found XWHEP jobs submitted with X509 proxy. When such a job is found, the bridge download the end user proxy and uses it to an XWHEP pilot job to EGEE (a pilot job being an XWHEP worker that will connect to the XWHEP server and request an XWHEP job to compute).
The blue bar represents the amount of job effectively computed by EGEE resources.
We can see two different periods in Figure 1: before october 2009 and since november 2009. In the first period, we were using the XWHEP->EGEE bridge version V1; since the second period, we use the bridge version V2. In first period we can see that the bridge unnecessarily overbooked EGEE resources which were really used in a 10% ratio only, which were just very bad. This was due to the fact that the bridge was designed to try to manage jobs from many XWHEP deployment connecting to all XWHEP server. In the second period, using the bridge V2, the average effective usage of connected EGEE resources is 75%, which is very good. this is due to the fact that the bridge does not connect to XWHEP servers, but directly to the database used by this server; of course the bridge does not modify the database itself : it only connects to the database in read only mode to ensure that it does not perturb the server. Connecting to the database ensures a better performance rates but does not allow the management of more than one XWHEP server per bridge since database accesses are usually not allowed outside an administrative domain.





Fig 1 : XWHEP->EGEE bridge V1 Vs V2

XWHEP pour EDGeS

Les partenaires du projet EDGeS ont décidé d’utiliser XWHEP 5.6.0.

Nous présentons ici les versions d’XWHEP testées et utilisées dans le cadre du projet EDGeS.

  • 18 août 2009 : XWHEP pour EDGeS 1.1.0
    • cette version est un tag EDGeS pour XWHEP 5.7.4 où :
      1. le nom du répertoire contenu dans le TAR est fixé à XWHEP-EDGeS
      2. la gestion des applications linkée dynamiquement est inactive
      3. on peut choisir le compte à utiliser pour tourner le middleware
        (il suffit de positionner la variable “system.user” dans le fichier build.conf)

    • 25 mai 2009 : XWHEP pour EDGeS 1.0.1
      • cette version est un tag EDGeS pour XWHEP 5.7.1 où :
        1. le nom du répertoire contenu dans le TAR est fixé à XWHEP-EDGeS
        2. la gestion des applications linkée dynamiquement est inactive
        3. on peut choisir le compte à utiliser pour tourner le middleware
          (il suffit de positionner la variable “system.user” dans le fichier build.conf)

      • 31 mars 2009 : Les sources XWHEP-EDGeS 1.0.0 ; Le binaire de XWHEP-EDGeS 1.0.0

      • 31 mars 2009 : XWHEP-EDGeS 0.0.0

La passerelle EDGeS de XWHEP à EGEE est en production

Nous avons le plaisir d’annoncer la mise en production du bridge XW->EGEE.

Le bridge est un service installé au LAL sur l’UI grid11 et connecte trois plates-formes XWHEP.
Les pages suivantes montrent l’activité de notre bridge:

Le projet EDGeS a été accepté

Le projet EDGeS propose de standardiser l’accès aux grilles, que ce soient des grilles "institutionnelles" comme EGEE, ou des grilles de calcul global, comme XtremWeb.Introduction.

EDGeS (http://www.edges-grid.eu/) est un projet européen d’une durée de 2 ans, de type "déploiement d’infrastructure", qui propose de travailler sur la convergence des grilles qu’elles soient "institutionnelles" (comme EGEE) ou pair a pair, comme XtremWeb, XGrid, Boinc…

Ce projet regroupe 9 participants, parmi 6 pays :

  • SZTAKI, Hongrie
  • CIEMAT, Espagne
  • Fundecyt, Espagne
  • INRIA, France
  • IN2P3, France
  • Universite de Westminster , UK
  • Universite de Cardiff, UK
  • AlmereGrid, Hollande
  • Universite de Coimbra, Portugal

Le LAL, en la personne de Oleg Lodygensky, a la responsabilité du NA3 (Networking Activity) : "Standardization procedures", d’une part, travaillera avec l’INRIA qui a la responsabilité du JRA1 (Joint Research Activity) "SG-DG Bridges Technologies", d’autre part. Le LAL participe aussi au "Service Activities" dont les buts sont de mettre en place et de maintenir une nouvelle infrastructure combinant des ressources volontaires et des ressources dédiées.

Presentation du NA3 :"Standardization procedures".

L’activité NA3 a pour but de collecter et diffuser les nouveaux standards proposés dans le cadre du projet EDGeS afin d’agréger la plus large communion possible au sein de la communauté scientifique et informatique. Cette activité aura a coeur de communiquer avec les institus privés et publics, les entreprises, mais aussi de faire connaître les travaux de ce projet auprès du grand public.

Budget.

Le montant alloué au projet se monte a 2.500KE.

Le LAL s’est vu allouer 297KE divisés en 268KE de salaire et 29KE pour les déplacements et l’équipement.