Database Reference
In-Depth Information
is a set of large-scale tests focused on verifying the readiness and functionality
of its computing infrastructure. The BSWG report 25 includes an assessment
of the main functionalities needed from storage services. It established that
an SE is a logical entity that provides the following services and interfaces:
An MSS that can be provided by either a pool of disk servers or more spe-
cialized high-performance disk-based hardware, or a disk cache front-end
backed by a tape system.
A storage interface to provide a common way to access the specific MSS, no
matter what the implementation of the MSS is.
A GridFTP service to provide data transfer in and out of the SE to and from
the grid. This is the essential basic mechanism by which data is imported
to and exported from the SE. The implementation of this service must
scale to the bandwidth required. Normally, the GridFTP transfer will
be invoked indirectly via the FTS or via the storage interface.
Local POSIX-like input/output calls providing application access to the data
on the SE.
Authentication, authorization, and audit/accounting facilities. The SE
should provide and respect ACLs for files and datasets, with access con-
trol based on the use of extended X.509 proxy certificates with a user
distinguished name (DN) and attributes based on virtual organization
membership service (VOMS) roles and groups. It is essential that an
SE provide sucient information to allow tracing of all activities for an
agreed historical period, permitting audit on the activities. It should also
provide information and statistics on the use of the storage resources,
according to schema and policies.
A site may provide multiple SEs with different qualities of storage. For
example, it may be considered convenient to provide an SE for data intended
to remain available for extended periods and a separate SE for data that is
transient—needed only for the lifetime of a job or set of jobs. Large sites with
MSS-based SEs may also deploy disk-only SEs for such a purpose or for general
use. Since most applications will not communicate with the storage system
directly but will use higher-level applications such as ROOT, 26 it is clear that
these applications must also be enabled to work with storage interfaces.
3.4.4.3 Beyond the WLCG Baseline Services Working Group
The BSWG required storage services to provide the features of SRM v1.1
along with a subset of SRM v2.1. By the end of 2005, however, it became
clear that suciently compatible implementations would not be available be-
fore the spring of 2006, by which time it was foreseen to start WLCG Service
Challenge 4, the last in a series of large-scale tests to assess the WLCG in-
frastructure readiness for handling LHC data taking and analysis. Therefore,
in February 2006 an initiative was agreed to simplify the set of requirements.
Search WWH ::




Custom Search