1. Introduction to EDGI

In the context of Distributed Data Processing, EDGeS is a project bridging on one part the EGI Service Grid infrastructure, using the gLite and ARC middleware, and the DEISA Service Grid Infrastructure, using the Unicore middleware, with on the other part Desktop Grid infrastructures using the BOINC or the XtremWeb-HEP middleware, plus academic Clouds.EDGI is a European project about Distributed Data Processing.

Funded by EC FP7 Research Infrastructures under number 261556, EDGI started on 01 June 2010 and will finish (with success) on 31 Mai 2012.

The goal is to permit communication between :
– the EGI Service Grid using gLite and ARC middleware, and the DEISA Service Grid using Unicore middleware,
– Desktop Grids using Boinc or XtremWeb-HEP middleware, plus academic Clouds based on Eucalyptus or OpenNebula to offer a certain quality of service.

1. Introduction to EDGeS

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.

EDGeS is now followed by the EDGI and DEGISCO projects.

XWHEP-EGEE bridge updated

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 for EDGeS

Parterns of the EDGeS project have agreed to use XWHEP 5.6.0 based branches.

We call this “XWHEP for EDGeS”

We present, in this page, the XWHEP versions tested by EDGeS partners.

The european EDGeS project has been accepted

The EDGeS project aims to propose a standardization of grids so that any type of grid could exchange and share resources. The goal is to enable resources sharing between EGEE and Desktop Grid such as Boinc, Xgrid or XtremWeb.Introduction.

EDGeS (http://www.edges-grid.eu/) is a two years european project of type "infrastructure" aiming to work on grid convergence from "insutionnal" grid such as EGEE to desktop grids such as Boinc, Xgrid ot XtremWeb.

This project agregates 9 participants from 6 countries:

  • SZTAKI, Hongary
  • CIEMAT, Sapin
  • Fundecyt, Spain
  • INRIA, France
  • IN2P3, France
  • Universite de Westminster , UK
  • Universite de Cardiff, UK
  • AlmereGrid, Netherlands
  • Universite de Coimbra, Portugal

The LAL has the responsability of the NA3 (Network Activity 3) : "Standardization procedures", and will especially work with the INRIA which is le leader of the JRA1 (Joint Research Activity) "SG-DG Bridges Technologies". LAL also participates to "Service Activities" which goal is to deploy and maintain a new infrastructure combining resources from the different platforms.

NA3 :"Standardization procedures".

NAE is an activity that will focus on collecting and spreading the new standards proposed by this project while aggregating the deepest communion. It will also open the widest possible audience from public and private entities. It will call for experience and expertise sharing in order to define a definitive standard to enable SG and DG resource sharing by unifying a set of standard and immutable interfaces as well as services and protocols. The process of standardization will iterate until an agreement is found within the obtained audience. NA3 will highly interact with JRA1 since this collaboration will help to iterate through the definition of the standard.

Budget.

EDGeS budget is 2.500KE.

LAL manages 297KE including 268KE for salary and 29KE for equipements and missions.