This document is intended to address the following issues:
- Delineate the job execution model to be supported by LCG-1. This depends in large part on what is feasible with the software expected to be available in LCG-1, and discussed in:
- Services “architecture”, in terms of what services must run, where and how many of them need to run, and how this will evolve
The scope of this document is the initial service to be run in July 2003.
For each service we will define how to implement the service with the following parameters:
The proposal is to use National, Regional, or community CA's. In general LCG will not be responsible for providing personal certificates. The exception to this is the CERN CA, currently run and supported by the LCG deployment group, which will provide certificates to CERN resident users.
There is a need for a "catch-all" CA. The need for this is for exceptional cases, for testing, and for getting things running. Presently this is the EDG (WP6) CA; but probably should become the CERN/LCG CA. Production systems and all users should, however, use their appropriate official CA.
In the longer term the CERN experiment secretariats must run the registration and VO membership service. LCG will maintain the tools.
In the following we assume that the Information Service is based on R-GMA. The needs are an IS instance at each participating site (all Tiers) into which information at all sites are published. This will be installed as part of the general LCG deployment process at each site. In addition, in the current implementation of R-GMA, a single look-up registry service must be run.
(Not yet clear if can only be 1 instance of registry)
If R-GMA is demonstrated to have serious problems, LCG must set up an MDS structure instead. We will use a hierarchy in the same way that EDG has been running.
The Replica Location Service (RLS) consists of several components:
For the July, 2003 release of LCG-1 only the LRC will be implemented (RLI scheduled for integration not before June 6). Without the RLI, there can only be a single instance of the LRC for each VO.
Once the RLI is available, the goal would be to run a LRC at each site with a mass storage system that will hold file replicas. The LRC is associated with that MSS and is separate for each VO. Thus a site supporting 4 VOs will run 4 LRC instances. There will be a set of RLI's at strategic locations.
Notes: Any LCG centre can run Oracle (license has been negotiated). The LRC database can run on any hardware (i.e. Oracle can run on a supported platform - does not have to be Linux). However, Oracle on Linux must use Redhat Advanced Server in order to get support.
Not clear if RMC is needed at all. LRC does mapping from GUID to physical file names; if experiment db maps from LFN to GUID then no RMC is needed.
These are currently client tools, and will be installed so that they are available at all worker nodes and service nodes.
This will be based on SRM and will run wherever the local MSS has an agreed implementation of the SRM interface that is demonstrated to interoperate with other implementations.
This is the gateway service to the compute farm of worker nodes. All sites will run this and it is part of the standard LCG-1 distribution.
How many to run and where depends on testing still to be done. We should foresee at least 1 per VO in each continent.
RAL have agreed to lead the project on defining the functions and responsibilities of the LCG operations centres. IN2P3 Lyon will collaborate in the development work. In the US the iVDGL project will collaborate (and act as the US operations centre for LCG -- to be confirmed). A proposal for prototype operations centres with an implementation timescale of the 4th quarter of 2003 will be produced in May.
For the July deployment, we foresee that we will have an installation of the DataTag (Nagios-based) monitoring tools at CERN as a minimum, together with a problem reporting system.
FZK Karlsruhe have agreed to lead the activity on LCG support centres, and will build a first prototype based on a web service and problem reporting system.