Personal tools
 

4.1. Introduction

Up one level
Introduction to the SLA Management Service

Overview

This provides the service manager with the ability to define their available resources (e.g. CPUs, applications, etc), assign portions of their resources to users by the way of service level agreements (SLAs) and bill for resource usage.

The SLA Service is highlighted in the diagram below:

Highlighting the SLA Management Service in the GRIA Architecture

Highlighting the SLA Management Service in the GRIA Architecture

Once someone (the engineer or project manager) at the client organisation has (1) obtained an account and (2) obtained an SLA, the user/engineer at the client organisation may (3) use a functional service that is managed by the SLA Service, which in turn will bill the account for any usage.

The SLA Service manages activities (e.g. data-stagers, jobs, databases) at the functional service, and to a lesser extent, the account service manages the SLA Service. In the following discussion, the functional service is the data service but the same interactions occur with any functional service.

Managing the SLA Service

The SLA Service manager will write and publish "SLA templates" which are offers of service. Using the SLA templates the manager is able to offer many different SLAs with different levels of service at different prices (e.g. "gold", "silver" and "bronze" packages). These represent the service provider's "offers" on terms for using their services. The GRIA access control system can then be used to control which clients are able to see each SLA template. This makes it possible to offer special rates to particular customers, for instance, by creating an SLA template with lower pricing terms, but making it accessible only to those customers.

Using a Managed Functional Service

Before a client is able to use a managed functional service they must have agreed an SLA with the relevant SLA Service. To agree an SLA, the client first retrieves SLA templates that the service provider is offering. The client chooses a template, fills in any fields where they must make a choice and "proposes" it to the service provider. If the service provider agrees with the proposal and has enough spare capacity to honour the agreement, the service provider will agree the SLA and the contract is made. This agreement decision is made automatically by the SLA Service, based on a description of the available resource capacity, taking account of previous SLA agreed.

The SLA between the client and the service provider contains information describing the charges that will be made for various actions and the constraints placed on the client's usage of services.

The client is also able to query the SLA Service directory to retrieve information on their resource usage.

When the client uses the functional service, they quote the ID of their SLA in their request. Through the SLA ID, the functional service is able to be managed by the SLA Service (see below).

How the SLA Service Shares Out Resources

Part of the purpose of an SLA is to give the consumer confidence that they will receive a certain standard of service. For grid services this "standard of service" is often something as basic as a quota of disc space or quantity of CPU time (however, more consumer friendly metrics may be used: see private constraints).

The GRIA SLA Service has a "constraint manager" that deals with making sure that the agreements defined in the SLAs are met. It is possible to replace the constraint manager by a different one with a more advanced algorithm, but the one supplied with GRIA takes a simple conservative approach.

The administrator of the service will define the service's "capacity" and then publish one or more "SLA templates". Both the capacity definition and the SLA templates use constraints to define quantities of resources and the constraint manager must balance one set of constraints against the other. For instance, a capacity constraint may define that there is 10GB of disc space available. If the administrator publishes an SLA template offering up to 1GB of disc space, then the constraint manager will ensure that at most 10 of these SLAs are agreed: guaranteeing that the terms in the SLA can be met. The situation is more complicated when more complicated constraints involving CPU time or contention ratios are used (see further examples of constraints) but the principle is the same.

Management of a Functional Service by the SLA Service

For a functional service to be managed by the SLA Service it must:

  1. query the SLA Service when it is about to perform an action that may potentially involve a lot of usage,
  2. notify the SLA Service of resource usage in a timely manner, and
  3. obey the SLA Service's instructions to destroy activities.

So, for instance, when a client requests a new data-stager, the data service queries the SLA Service to check that the client is allowed another data-stager in their SLA. If the SLA Service were to say that the client was not allowed, then the functional service must obey and not continue. When the client uploads a file to a data-stager, the data service notifies the SLA Service of the disc space and data transfer usage. If the SLA Service discovers that a client has exceeded a constraint in their SLA, then it takes steps (where possible) to bring the usage back within the constraint by instructing functional services to kill a minimum number of the client's activities.

Functional services query new usage requests from the client and report usage of resources using "metrics" such as disc space, data transfer, CPU, database transactions etc. The SLA Service has no concept of what each metric actually represents, it just records their usage and compares the usage against the constraints in the SLAs. As a result, the SLA Service is able to manage new functional services that use highly customised usage metrics with no alteration to the SLA Service itself.

Management of the SLA Service by the Account Service

There is a looser form of management between the SLA Service and the Account Service:

  1. When a client proposes a new SLA, the SLA Service checks with the Account Service that the client's credit is good.
  2. At the end of each SLA billing period, the SLA Service records an aggregated bill (for all the period's usage) on the client's trade account.
  3. If, when billing an account, the SLA Service discovers that the account is suspended or closed, then the SLA is itself suspended.

Configuring, Using and Managing the SLA Service

The following list summarizes the steps taken in configuring, using and managing the SLA Service:

Next: Metrics Previous: SLA Management Service