Dans le contexte du Traitement Distribué des Données, DEGISCO est un projet permettant d’utiliser la technologie ’3G bridge’ développée par EDGeS pour développer des Grilles de PC en dehors d’Europe.DEGISCO est un projet européen de Traitement Distribué des Données.
Financé par EC FP7 Research Infrastructures sous le numéro 261561, DEGISCO a démarré le 01 Juin 2010 et s’achèvera (avec succès) le 31 Mai 2012.
Dans le contexte du Traitement Distribué des Données, EDGI est un projet permettant la communication entre d’une part les Grilles de Service EGI et DEISA, qui utilisent les intergiciels gLite, ARC et Unicore, et d’autre part les Grilles de PC utilisant les intergiciels BOINC ou XtremWeb-HEP, plus des Nuages académiques. EDGI est un projet européen de Traitement Distribué des Données.
Financé par EC FP7 Research Infrastructures sous le numéro 261556, EDGI a démarré le 01 Juin 2010 et s’achèvera (avec succès) le 31 Mai 2012.
Le but est de permettre la communication entre :
– les grilles de Service EGI utilisant les intergiciels gLite et ARC, et DEISA utilisant l’intergiciel Unicore,
– les Grilles de PC utilisant les intergiciels Boinc ou XtremWeb-HEP, plus des Nuages académiques basés sur Eucalyptus ou OpenNebula permettant l’offre d’une certaine qualité de service.
In the context of Distributed Data Processing, EDGeS is a project bridging the EGEE Service Grid infrastructure, using the gLite middleware, with Desktop Grid infrastructures using the BOINC or the XtremWeb-HEP middleware.EDGeS is a European project about Distributed Data Processing.
Funded by EC FP7 Research Infrastructures under number 211727, EDGeS started on 01 January 2008 and ended successfully on 31 March 2010.
The goal of EDGeS was to bridge the EGEE Service Grid infrastructure, using the gLite middleware, with Desktop Grid infrastructures using the BOINC or the XtremWeb-HEP middleware.
EDGeS achieved this goal and even bridged the EELA Grid infrastructure, using the gLite middleware, with the Brazilian Desktop Grid infrastructure using the OurGrid middleware.
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.
New Introductory TextNew Detailed text
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
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
Nous avons mis à jour notre plate-forme.
Le client XWHEP pour le déploiement au LAL est disponible : ici.
Ce fichier de 21Mb contient toute la documentation :
We have upgraded our platform.
You can download the XWHEP client for LAL deployment: here.
This is a 21Mb file including full documentations :
Documents introducing our platform:
Documents detailing configuration and deployment: