70 likes | 253 Views
CMS T2_FR_CCIN2P3 Separation from T1. CMS-CCIN2P3 July 7, 2009 CCIN2P3. Tibor Kur ča Institut de Physique Nucléaire de Lyon. CMS Tier 2 vs Tier 1. T2_FR_CCIN2P3 is specific Usually diffrent sites for different Tiers
E N D
CMS T2_FR_CCIN2P3Separation from T1 CMS-CCIN2P3 July 7, 2009 CCIN2P3 Tibor Kurča Institut de Physique Nucléaire de Lyon T.Kurca CMS-CCIN2P3
CMS Tier 2 vs Tier 1 • T2_FR_CCIN2P3 is specific • Usually diffrent sites for different Tiers • - exceptions : CERN (T0, T1, T2) , FNAL (T1, T3) and CCIN2P3 (T1, T2 ) • CE …. ok • - SE, PhEDEx node : some complications to be solved • What can we learn from CERN/FNAL ? Tier 3 IPNL Tier 2 GRIF Tier 1 CC IN2P3 Tier 2 CC AF Tier 2 IPHC T.Kurca CMS-CCIN2P3
CERN-FNAL Comparison CERN FNAL PhEDEx nodes: different different SE: reallydifferent different (only alias) srm-cms.cern.ch (T1) cmssrm.fnal.gov (T1) caf.cern.ch(T2) cmsdca2.fnal.gov(T3) dCache: the same for T1 & T2 the same for T1 & T3 Disk pools : different the same needed special download agents T.Kurca CMS-CCIN2P3
Data Transfers CERN : - T2 subscription – if data already at T1 then no actual PhEDEx transfer again …. just stageing to the right disk - developed dedicated T1CAF local download agents to ensure replication to the correct service class and to register download data in the local CAF DBS - using space tokens to separate T1T1_CH_CERN from T1T2 transfers FNAL : -T1 subscription doesn’t mean automatically also data at T3 - T1 data are fully accessible via CRAB to T3 users (no blacklisting) - user data are subscribed to T3 – track kept by the T3-manager as the dcache is the same for T1/T3 T3 data will be migrated to tape, but PhEDEx doesn’t know about it - caveat : don’t subscribe the same data to T1 & T3 T.Kurca CMS-CCIN2P3
T2_FR_CCIN2P3 Before • Site configuration : • CE - different for T1 & T2 • SE - one for both T1&T2 • PhEDEx – only T1 node • Access to data in T1 for users of T2 • - data stored at T1 only • - non productions jobs to be run at T2 • Jobs: temporaryhack from CRAB_2_4_4(Jan 23,2009) • users jobs can access T1_CCIN2P3 data without show-prod = 1 option • …. all T1 are masked in DLS by default except CCIN2P3 • at the end transparent for the user T.Kurca CMS-CCIN2P3
T2_FR_CCIN2P3 Now dCache: the same for T1/T2 Disk pools : the same for T1/T2 …. create specific for T2 ? • New PhEDEx node T2_FR_CCIN2P3 on VOBox cclcgcms06 - disk only - separated from T1 (although the same SRM endpoints) - SE ccsrmt2.in2p3.fr published & declared close to CE cclcgceli05(6) - T2 jobs still can see data at SE ccsrm.in2p3.fr Main Goals: - avoid transferring the same data 2x ….. - avoid T1T2 intra CCIN2P3 transfers - avoid hacks on different levels should be solved at PhEDEx level with different T2_FR_CCIN2P3 node & correct config T.Kurca CMS-CCIN2P3
CMS T2 Environment • T2: $VO_CMS_SW_DIR redefined set by the MW layer ($GLITE_LOCATION/etc/profile.d/grid_env.(c)sh) $VO_CMS_SW_DIR = $VO_CMS_SW_DIR/T2_VO_CMS_SW_DIR /afs/in2p3.fr/grid/toolkit/cms2/T2_VO_CMS_SW_DIR because T2 specific config path needed $VO_CMS_SW_DIR/SITECONF/T2_FR_CCIN2P3 • url for T2 TrivialFile Catalogue (TFC) - TFC : LFN PFN mapping with ccsrmt2 instead of ccsrm SITECONF/T2_FR_CCIN2P3/JobConfig/site-local-config.xml /afs/in2p3.fr/grid/toolkit/cms2/T2_VO_CMS_SW_DIR/SITECONF/local/PhEDEx/storage.xml • The same T1 CMSSW installation used use soft links - slc4_ia32_gcc345 ….. $SCRAM_ARCH - cmsset_default.(c)sh T.Kurca CMS-CCIN2P3