ScFourServiceDefinition Service Challenge 4 Service Definition

This page defines

• The products involved in the SC4 service definitions
• How the products map to services
• The service parameters

It does not cover the technical aspects of how the service is to be delivered (see ScFourServiceTechnicalFactors for this information).

Service Class

The Service Class is a set of parameters which share the same service level objectives. It permits an easy way of describing the high level parameters required for a service (such as the BDII is a class C rather than the BDII requires 99% availability with 1 hour response time...)

where

• downtime defines the time between the start of the problem and restoration of service at minimal capacity (i.e. basic function but capacity < 50%)
• Reduced defines the time between the start of the problem and the restoration of a reduced capacity service (i.e. >50%)
• Degraded defines the time between the start of the problem and the restoration of a degraded capacity service (i.e. >80%)
• Availability defines the sum of the time that the service is down compared with the total time during the calendar period for the service. Site wide failures are not considered as part of the availability calculations. 99% means a service can be down up to 3.6 days a year in total. 98% means up to a week in total.
• None means the service is running unattended

The service class structure is based on the MoU values.

Calendars

These define the times during the day and in the cycle of accelerator operations. Required service levels change depending on the time of day or year due to changing usage of the systems and the trade-off between cost and reliability.

where

• prime shift is defined as 08:00-18:00 working days
• second shift is anytime outside of prime shift

The calendar does not address the change of service levels from the early (September 2006) to full production (2007). Service Levels should be defined for the full production state.

Products

A product consists of a set of hardware and software can provide functions for which the availability can be measured. Products make no distinction between development, test or production or between the users. A product does not have a service level associated with them since this is performed at the Service level.

Product Name	Short Code	Purpose	Dvl Org	Dvl Contact
Resource Broker	RB	Farms out jobs to sites+logging and book-keeping		David Smith
MyProxy	PX	Renew/acquire credentials		Maarten Litmaath
BDII	BDII	Grid information system		Laurence Field
ComputeElement	CE	Gateway to local batch system
R-GMA	RGMA	Grid Monitoring		Laurence Field
Monbox	MONB	Grid Monitoring (including Capacity and performance data archiver)		Laurence Field
Grid View	GRVW	Monitoring
Site Functional Tester	SFT	Regular tests of components per site		Piotr Nyczyk, Judit Novak
Grid Peek	GRPK	Storage of outputs of running jobs		Patricia Mendez
VOMS	VOMS	Manages mapping of User / Roles / VO		Maria Dimou
LCG File Catalog	LFC	Maps file names to storage locations		Jean-Philippe Baud, Sophie Lemaitre
File Transfer Service	FTS	Reliable file transfer delivery		fts-support@cernNOSPAMPLEASE.ch
Storage Element	SE	SRM Compatible Storage Service

where

• Product Name is the usual english words used to describe the code
• Short Code is a short name which can be used for naming conventions such as hostnames or commands
• Purpose describes what functions the product delivers
• Dvl Org is the organisation responsible for development of the software and enhancements
• Dvl Contact is the primary contact within the Dvl Org

Customers

These are the users of the service.

Services

A service is constructed from a product (desribing what application), a customer (who uses it) and an instance (what is it for).

where

• Product defines the code which provides the visible function of the service
• Customer is the primary group using the service. SH (shared) implies the service is used by all experiments
• Class for each of the calendar windows defines what service class is expected for each of the times defined. Where current software restrictions limit the service possible to deliver, an entry such as M->H should be used to show that the best that can currently be delivered is medium but the requirement is for H. The SC4 tests can be used to validate the feasibility of the requested service level.
• Sup Org is the organisation providing support for the service who will cover problem resolution and deployment
• Support Contact is the primary contact point in the Sup Org for the service

The MoU minimum requirements for second shift would result in L in the columns for AS and OS. This has been ignored for the purposes of the first version but should be reviewed.

Maintenance Window

For planned changes, the following windows are defined during SC4. Maintenance windows are periods during which the services may run at reduced capacity (class C or H) or unavailable (class M or L) without being considered as downtime in the availability calculations.

These maintenance windows are used for operations such as

• Software upgrades
• System reboots where required

The actual window times will be defined later in the SC4 planning.

-- TimBell - 05 Sep 2005