LCG middleware and LHC experiments ARDA project

1. LCG middleware and LHC experimentsARDA project Julia Andreeva CERN Workshop LCG-France 23.02.2005

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 2004 prototyping prototyping product 2005 product LCG-3 LCG-2 and Next Generation of the Middleware (gLite) Next generation middlewarefocus 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-2focus on production, large-scale data handling • Theservice 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 Julia Andreeva CERN

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

9. LHC experiments prototypes (ARDA) LHCb ALICE • 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. 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. 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 ofhierarchy 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. 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