Data management in grid. Comparative analysis of storage systems in WLCG.
Really Two Data Problems The amount of data –High-performance tools needed to manage the huge raw volume of data Store it Move it –Measure in terabytes, petabytes, and ??? The number of data files –High-performance tools needed to manage the huge number of filenames filenames is expected soon Collection of of anything is a lot to handle efficiently
Data Questions on the Grid Questions for which you want Grid tools to address Where are the files I want? How to move data/files to where I want?
Data intensive applications Medical and biomedical: –Image processing (digital X-ray image analysis) –Simulation for radiation therapy Climate studies Physics: –High Energy and other accelerator physics –Theoretical physics, lattice calculations of all sorts Material sciences
LHC as a data source 500 MB/sec 15 PB/year 15 years
A Model Architecture for Data Grids Metadata Catalog Replica Catalog Tape Library Disk Cache Attribute Specification Logical Collection and Logical File Name Disk ArrayDisk Cache Application/ Data Management System Replica Selection Multiple Locations Selected Replica SRM commands Performance Information and Predictions Replica Location 1Replica Location 2Replica Location 3 MDS
SRM: Main concepts –Space reservations –Dynamic space management –Pinning file in spaces –Support abstract concept of a file name: Site URL –Temporary assignment of file names for transfer: Transfer URL –Directory management and authorization –Transfer protocol negotiation –Support for peer to peer request –Support for asynchronous multi-file requests –Support abort, suspend, and resume operations –Non-interference with local policies
Storage properties Access Latency (ONLINE, NEARLINE, OFFLINE) Retention Policy (REPLICA, OUTPUT, CUSTODIAL)
Use cases Access Latency (ONLINE, NEARLINE, OFFLINE) Retention Policy (REPLICA, OUTPUT, CUSTODIAL)
Logical File Name (LFN) Also called a User Alias, In case the LCG File Catalog is used the LFNs are organized in a hierarchical directory-like structure, and they will have the following format: lfn:/grid/ / /
Site URL and Transfer URL Provide: Site URL (SURL)Provide: Site URL (SURL) –URL known externally – e.g. in Replica Catalogs –e.g. srm://ibm.cnaf.infn.it:8444/dteam/test Get back: Transfer URL (TURL)Get back: Transfer URL (TURL) –Path can be different from SURL – SRM internal mapping –Protocol chosen by SRM based on request protocol preference –e.g. gsiftp://ibm139.cnaf.infn.it:2811//gpfs/sto1/dteam/test One SURL can have many TURLsOne SURL can have many TURLs –Files can be replicated in multiple storage components –Files may be in near-line and/or on-line storage –In a light-weight SRM (a single file system on disk) SURL may be the same as TURL except protocol
July Lecture 4: Grid Data Management12 Third party transfer Controller can be separate from src/dest Site A Site B Control channels Data channel Server Client
July Lecture 4: Grid Data Management13 Going fast – parallel streams Use several data channels Site A Site B Control channel Data channels Server
SRB (iRODS) SDSC SINICA LBNL EGEE Interoperability in SRM v2.2 Client User/application CASTOR DPM Disk BeStMan xrootd BNL SLAC LBNL dCache
Total Online Space Share
Popularity
CASTOR Architecture VDQM server NAME server STAGER RFIOD (DISK MOVER) DISK POOL MSGD NAME server VOLUME manager RTCPD (TAPE MOVER) TPDAEMON (PVR) VDQM server CUPV RFIO Client
Basic dCache Design
DPM Very important to backup ! Store physical files -- Namespace -- Authorization -- Replicas -- DPM config -- All requests (SRM, transfers…) Standard Storage Interface Can all be installed on a single machine
EOS: What is it... Easy to use standalone disk-only storage for user and group data with in-memory namespace – Few ms read/write open latency – Focusing on end-user analysis with chaotic access – Based on XROOT server plugin architecture – Adopting ideas implemented in Hadoop, XROOT, Lustre et al. – Running on low cost hardware no high-end storage – At CERN: Complementary to CASTOR
EOS: Access Protocol EOS uses XROOT as primary file access protocol – The XROOT framework allows flexibility for enhancements Protocol choice is not the key to performance as long as it implements the required operations – Client caching matters most Actively developed, towards full integration in ROOT (rewrite of XRootD client at CERN) SRM and GridFTP provided as well – BeStMan, GridFTP-to-XROOT gateway
Thank you Grid, Storage and SRM. OSG. Managed Data Storage and Data Access Services for Data Grids. M. Ernst, P. Fuhrmann, T. Mkrtchyan DESY J. Bakken, I. Fisk, T. Perelmutov, D. Petravick Fermilab dCache. Dmitry Litvintsev, Fermilab. OSG Storage Forum, September 21, 2010 GridFTP: File Transfer Protocol in Grid Computing Networks. Caitlin Minteer Light weight Disk Pool Manager status and plans. Jean-Philippe Baud, IT- GD, CERN Storage and Data Management in EGEE, Graeme A Stewart1, David Cameron, Greig A Cowan and Gavin McCance and many others