1. CMS data access Artem Trunov

2. CMS site roles Tier0 –Initial reconstruction –Archive RAW + REC from first reconstruction –Analysis, detector studies, etc Tier1 –Archive a fraction of RAW (2 nd copy) –Subsequent reconstruction –“Skimming” (off AOD) –Archiving Sim data produced at T2s –Serve AOD data to other T1 and T2s –Analysis Tier2 –Simulation Production –Analysis

3. Data Distribution T0 – T1 –RAW + first pass RECO,AOD T1 – T1 –subsequent reco pass AOD exchange T1 – T2 –AOD and other data T2 – T1 –MC upload

4. Access Policies Transfer –use of SRM, FTS for T0-T1-T2 transfers –(although in practice FTS can work with bare gsiftp – to explore!!) Reading by jobs from the local storage –always native remote access protocol: dcap for dCache rfio for DMP and Castor root:// for xrootd –CMS never preloads input data files to WN’s scratch space. –CMS never accesses data over WAN Uploading results of jobs to local storage –SRM in general and for dCache, –rfcp for Castor, DPM –could be local upload or to another (associated T1, neighbor T2) site Conditions and calibration data –squid cache – http protocol

5. LFN to PFN translation Trivial File Catalog CMS doesn’t use LFC or any database at all for LFN-to-PFN mapping! Instead TFC is used –an xml file –inside: a set of rules for LFN-PFN mapping for every access protocol at site direct(posix) srm dcap or rfio –based on LFN pattern match. –takes advantage of CMS standard name space so that few rules could be defined locally –No scalability and reliability issue at all! TFC is maintained by a CMS site contact person, kept in CMS CVS and is installed in the $VO_CMS_SW_DIR TFC works together with another configuration file site-local-config.xml which defines job access protocol (site-wide), other config details like Squid server, MC upload endpoint etc

6. TFC example

7. Conditions and Calibration Frontier/squid Main Oracle server at CERN Hierarchical squid caches, one per site Oracle SQL queries are wrapped into HTTP requests to Frontier Squid is caching server response Jobs always access local cache first, if misses, the request goes up in the hierarchy and the response is cached locally. Very trouble free technology –however not much experience with large number of jobs yet.