Details

Autor(en) / Beteiligte

• Bauerdick, L
• Benjamin, D
• Bloom, K
• Bockelman, B
• Bradley, D
• Dasu, S
• Ernst, M
• Gardner, R
• Hanushevsky, A
• Ito, H
• Lesny, D
• McGuigan, P
• McKee, S
• Rind, O
• Severini, H
• Sfiligoi, I
• Tadel, M
• Vukotic, I
• Williams, S
• Würthwein, F
• Yagil, A
• Yang, W

Titel

Using Xrootd to Federate Regional Storage

Ist Teil von

• Journal of physics. Conference series, 2012, Vol.396 (4), p.42009-14

Ort / Verlag

Bristol: IOP Publishing

Erscheinungsjahr

2012

Quelle

EZB Electronic Journals Library

Beschreibungen/Notizen

• While the LHC data movement systems have demonstrated the ability to move data at the necessary throughput, we have identified two weaknesses: the latency for physicists to access data and the complexity of the tools involved. To address these, both ATLAS and CMS have begun to federate regional storage systems using Xrootd. Xrootd, referring to a protocol and implementation, allows us to provide data access to all disk-resident data from a single virtual endpoint. This “redirector” discovers the actual location of the data and redirects the client to the appropriate site. The approach is particularly advantageous since typically the redirection requires much less than 500 milliseconds and the Xrootd client is conveniently built into LHC physicists’ analysis tools. Currently, there are three regional storage federations - a US ATLAS region, a European CMS region, and a US CMS region. The US ATLAS and US CMS regions include their respective Tier 1, Tier 2 and some Tier 3 facilities; a large percentage of experimental data is available via the federation. Additionally, US ATLAS has begun studying low-latency regional federations of close-by sites. From the base idea of federating storage behind an endpoint, the implementations and use cases diverge. The CMS software framework is capable of efficiently processing data over high-latency links, so using the remote site directly is comparable to accessing local data. The ATLAS processing model allows a broad spectrum of user applications with varying degrees of performance with regard to latency; a particular focus has been optimizing n-tuple analysis. Both VOs use GSI security. ATLAS has developed a mapping of VOMS roles to specific file system authorizations, while CMS has developed callouts to the site's mapping service. Each federation presents a global namespace to users. For ATLAS, the global-to-local mapping is based on a heuristic-based lookup from the site's local file catalog, while CMS does the mapping based on translations given in a configuration file. We will also cover the latest usage statistics and interesting use cases that have developed over the previous 18 months.