1 / 5

Data Access Solution for CMS-France-CCIN2P3

This meeting in Lyon on February 3, 2009 discusses the problem of accessing data at T1 for users of T2 and proposes solutions from CERN, FNAL, and CCIN2P3.

verng
Télécharger la présentation

Data Access Solution for CMS-France-CCIN2P3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMS T1-T2 CCIN2P3Data Access CMS-France-CCIN2P3 Meeting February 3, 2009 Lyon Problem CERN Solution FNAL Solution T2_FR_CCIN2P3 ? Tibor Kurča Institut de Physique Nucléaire de Lyon T.Kurca - CMS-CC

  2. Problem Definition Access to data in T1 for users of T2 - data stored at T1 only - non productions jobs to be run at T2 - avoid transferring the same data 2x - avoid T1T2 intra CCIN2P3 transfers - access to T1 data by local users status –Site configuration :CE - different for T1 & T2 SE - one for both T1&T2 PhEDEx – only T1 nodes status – jobs: temporaryhack inCRAB_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  should be solved at PhEDEx level with different T2_FR_CCIN2P3 node T.Kurca - CMS-CC

  3. CERN Configuration dCache: the same for T1 & T2 ???? Disk pools : ?????? PhEDEx nodes: T1_CH_CERN_Buffer, T1_CH_CERN_MSST2_CH_CAF T2 end point diskonly but having access to T1-tape (CASTOR) ? SE: srm-cms.cern.ch (T1) - caf.cern.ch (T2) -real, not only alias CE: No CE registered (T1&T2) ???? Data subscription: - T2 subscription – if data already at T1 then no actual PhEDEx transfer again …. just stageing to the right disk - developed dedicated T1CAF local download agents to ensure replication to the correct service class - using space tokens to separate T1T1_CH_CERN from T1T2 transfers - a special CAF agent to register download data in the local CAF DBS T.Kurca - CMS-CC

  4. FNAL Configuration 1 dCache: the same for T1 & T3 (independently configured in SiteDB & PhEDEx) all files accessible for everyone Disk pools : common for T1&T3 PhEDEx nodes: T1_US_FNAL_Buffer, T1_US_FNAL_MSST3_US_FNALLPC SE: cmssrm.fnal.gov (T1) - cmsdca2.fnal.gov (T3) – alias for cmssrm ! T3 end point diskonly is a CNAME to FNAL’s CMS-SE cmssrm.fnal.gov CE: production jobs run on T1; users run on T3 Data subscription: - T1 subscription doesn’t mean automatically also data at T3 ! - T1 data are fully accessible via CRAB to T3 users (no blacklists…) - user data are subscribed to T3– track kept by the T3-manager - caveat: don’t subscribe the same data to T1 & T3 ! ….. No mechanism to prevent the data deletion from both PhEDEx endpoints if the data subscribed to the both - data subcribed to T3 is still archived by dCache but PhEDEx doesn’t know that ! (???old PhEDEx) T.Kurca - CMS-CC

  5. CCIN2P3 Configuration dCache: the same for T1 & T2 ???? Disk pools : only for T1 ?  create specific for T2 ? PhEDEx nodes: T1_FR_CCIN2P3_Buffer,T1_FR_CCIN2P3_MSS no T2node for the moment ! create T2 node T2_FR_CCIN2P3 real or only alias to T1 node ? (no subscription synchronization should be needed …) SE: ccsrm.in2p3.fr (T1) - ccsrm.in2p3.fr (T2)  create T2 specific …. alias to ccsrm.in2p3.fr ? Wouldn’t this be enough ? CE: different CE for T1 and T2 ! SE is CloseSE to both the T1 & T2 CEs; if the jobs cannot go to T1 why they don’t got to T2 ??????????????? Isn’t T1-SE close to T2-CEs ? - problem that there is no T2_PhEDEx node ? Data subscription: T.Kurca - CMS-CC

More Related