1. LCG middleware and LHC experiments ARDA project
Julia Andreeva
CERN
Workshop LCG-France

2. Overview LCG middleware evolution New middleware generation – gLite
Providing interface between LHC experiments software and gLite – ARDA project
Closer look to the requirements and functionality, accent to the experiments use-cases
Julia Andreeva CERN

3. LCG middleware Middleware package – components from –
European DataGrid (EDG)
US (Globus, Condor, PPDG, GriPhyN)  the Virtual Data Toolkit
Current version of the middleware
LCG-2 was released in February 2004
Julia Andreeva CERN

4. LCG-2 and Next Generation of the Middleware (gLite)
prototyping
product
2004
2005
LCG-3
Next generation middleware focus on analysis
Developed by EGEE project in collaboration with VDT (US)
LHC applications and users closely involved in prototyping & development (ARDA project)
Short development cycles
Completed components integrated in LCG-2
LCG-2 focus on production, large-scale data handling
The service for the 2004 data challenges
Provides experience on operating and managing a global grid service
Strong development programme driven by data challenge experience
Evolves to LCG-3 as components progressively replaced with new middleware
Julia Andreeva CERN

5. ARDA interface between HEP experiments and gLite
ARDA is an LCG project whose main task is to enable LHC analysis on the GRID
CMS
Cobra,Orca,
OCTOPUS…
Alice
ROOT,AliRoot,
Proof…
Atlas
Dial,Ganga,
Athena,
Don Quijote
LHCb
Ganga,Dirac,
Gaudi, DaVinci…
ARDA
LCG2
EGEE middleware (gLite)
Julia Andreeva CERN

6. ARDA activity with the experiments
The complexity of the field requires great care in the phase of middleware evolution and delivery:
Complex (evolving) requirements
New use cases to be explored (for HEP: large-scale analysis)
Different communities in the loop
LHC experiments and their middleware experts
other communities providing large middleware stacks (e.g. US OSG)
The complexity of the experiment-specific sw is comparable (often larger) of the “generic” one
The experiments require seamless access to a set of sites (computing resources)
but the real usage (therefore the benefit for the LHC scientific programme) will come from the possibility to build computing systems on a flexible and dependable infrastructure
How to progress?
Build end-to-end prototype systems for the experiments to allow end users to perform analysis tasks
Julia Andreeva CERN

7. LHC prototype overview
Experiment
Main focus
Basic prototype component
Experiment analysis
application framework
Middleware
GUI to Grid
GANGA
DaVinci
Interactive analysis
PROOF
ROOT
AliROOT
High level services
DIAL
Athena
Exploit native gLite functionality
Aligned with APROM strategy
ORCA
Julia Andreeva CERN

8. LHC experiments prototypes (ARDA)
ALICE
LHCb
ATLAS
CMS
Julia Andreeva CERN

9. LHC experiments prototypes (ARDA)
ALICE
LHCb
All prototypes have been presented and
“demo-ed” within the users communities
ATLAS
CMS
Julia Andreeva CERN

10. ARDA activities on the gLite testbed
Testing of the functionality and performance of the gLite middleware regarding experiment use-cases
Providing early feed back to the LHC community and gLite development team, initiating discussion on the problematic issues
Developing and testing analysis prototypes
Julia Andreeva CERN

11. To resolve for jobs submission
Overview of the job generation/processing and interaction with middleware components. Job creation-submission step
User
input
Input
To resolve for jobs submission
Middleware components
Where data collection is available?
Data collection to run on
Data
management
system
Experiment
Metadata
catalogue
Executable and user libraries
Where resources are available?
Workload
Management
system
Application to use (experiment specific software)
How to send executable and user libraries
Information
system
How to make experiment specific software available for the jobs
Software
distribution
systems
Output files to be saved
Package
manager
How to split the job in an optimal way
Julia Andreeva CERN

12. To resolve when job landed Retrieving of the results
Overview of the job generation/processing and interaction with middleware components. Job processing step
Middleware components
Job monitoring task
To resolve when job landed
at the worker node
Jobs clustering
Work load
Management
system
How to access input files
Access to log information
Information
&
Monitoring
service
How to setup the environment
Data
Management
system
Retrieving of the results
How to save the job output
Package
manager
Julia Andreeva CERN

13. Workload Management System
ARDA has been evaluating two WMSs
- Task queue (pull model) derived from Alien
- WMS derived from EDG (supports pull and push model)
ARDA observations:
Workload Management System has to be integrated
with other middleware components , like file catalogue and package manager
Experiments can have their own strategy for data discovery, so flexible integration mechanism should be in place (example integration of WMS with DLI)
Job clustering is needed (multiple similar jobs submitted under the same identifier, each job is processing a subset of data)
Access to log information is very important ( stderr and stdout of running jobs, system information)
Lightweight deployment of client interface
- Client has to be easy installable
Client should work behind Firewalls and NAT routers
Performance and scalability is a critical issue!
Julia Andreeva CERN

14. Data Management Some aspects requirements/observations Catalogue
High performance of the file catalog for insertion and queries.
ARDA is running performance tests on the catalogs available on the testbed
- Catalog derived from Alien
- Fireman catalog
Capability to serve a big number of clients simultaneously.
Distributed architecture has to be foreseen (for better scalability)
- Synchronization
Support of bulk operations
Integration with the catalogues used by experiment applications (POOL) can be required
Hierarchical (directory like) structure of the logical file names (LFN) can improve data access and allow s to record some meta attributes in the LFN
Permissions implemented at all levels of hierarchy
Julia Andreeva CERN

15. Data Management (continuation)
Some aspects requirements/observations
gLiteIO should be rock solid
- no data corruption even under high load and concurrency
- graceful error recovery
Reliable file storage with common interface
- space management functionality
- permissions (ACL like)
Reliable file transfer (low level service)
Data movement/location service (example CMS Phedex system)
- Transfer sets of files (data collections)
- Checking data collections integrity
- Integration with experiment catalogues and/or bookkeeping systems
Julia Andreeva CERN

16. Clearly more work has to be done to satisfy different use cases
Package management
Multiple approaches exist for handling of the experiment software and user private packages on the Grid.
Two extremes:
- “Static”: Pre-installation of the experiment software is implemented by a site manager with further publishing of the installed software, installation resides “forever” in the shared area, can be removed only by a site manager. Job can run only on a site where required package is preinstalled.
- “Dynamic”: Installation is done on demand at the worker node before job assigned to a given node starts execution. Installation can be removed as soon as job execution is over.
Current gLite package management implementation (derived fro Alien) can handle “Light-weight” installations, close to the second approach. gLite package manager was tested by ARDA team for this kind of installations.
Clearly more work has to be done to satisfy different use cases
Julia Andreeva CERN

17. Conclusions
LCG middleware development has to be aligned with LHC experiments requirements and use-cases
A lot of work was done to reach this goal.
More effort is required to be prepared for processing of the real data in 2007
Julia Andreeva CERN