The UNICORE integration Activities




Background as described in DJRA 1.2.2

The integration of the LFC client provides an abstract file system view towards the UNICORE data management components, representing files stored in Grid storage elements. Independently of its different physical storage locations, files are visible under a single namespace. Replicas of files, stored on different Grid storage elements, can be addressed using its unique LFC entry (logical filename, LFN). As data locations, within the LFC, are mostly expressed by Storage URL’s being the URL used by the Storage Resource Manager protocol to calculate the transfer URL, the consequent next step is to implement the SRM client into the UNICORE SMS service. A combined LFC, SRM client library seamlessly integrates the UNICORE storage services into the existing Grid infrastructure and, depending on permission settings, offers Grid storage to classic HPC applications.

Design and proposed solution


During the preparation phase, several potential LFC client APIs were evaluated and an appropriate one chosen. Based on that API, an LFC client was implemented and tested in detail. A prototype of the UNICORE LFC client is available for M12. UNICORE abstracts access to target storage systems by its Storage Management Service interface (SMS). To logically complete the work of providing a Grid implementation of SMS, the SRM client still needs to be integrated. Further development and timelines are discussed in paragraph 4.4 and 4.5.

Current status (M16):

Both, LFC and SRM SMS work principally. As the UNICORE SMS model only supports a subset the functions of a SE and it is primarily used for data staging in, just a subset of functions have to be implemented for the SMS to work. Those are basically the following ones:

functionSorted ascending SRM LFC open issues
chmod 4 0 UNICORE user rights vs. srm/lfc user/group/other rights
cp 5 X no cp available for lfc
getAvailableDiskSpace 0 X how to deal available disk space in srm, unnecessary in lfc
getFile 3 2 lfc getFile depends on srm getFile
getFileProperties 4 0 UNICORE user rights vs. srm/lfc user/group/other rights
ls 4 4 UNICORE user rights vs. srm/lfc user/group/other rights
mkdir 5 5  
rename 5 5  
rm 5 5  
rmdir 5 5  

The numbers represent the current status of implementation (0=none, 5=finished).




Motivation and technical description

The South Korean KISTI Supercomputing Center has been showing interest in integrating client access to the AMGA metadata catalogue into UNICORE. AMGA is currently a prototype of a distributed, high performance file metadata server, written by the ARDA metadata catalogue project. It serves the needs on metadata catalogues in a Grid environment, including the solutions offered by the HEP experiments so far.

-- PatrickFuhrmann - 02-Aug-2011

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2011-08-23 - unknown
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback