4.1. Introduction

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

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).

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:

• Configuration
1. Service manager configures SLA Service to trust one or more account services.
2. Service manager defines the capacity of their resources (disc space, CPU, etc), this is configured at the SLA Service.
3. Service manager creates one or more SLA templates according to what they want to offer to users.
4. Service manager defines who is permitted to see each template.
5. Service manager publishes the SLA template(s).
• Client Usage
6. Client (with an account at a trusted service) retrieves the list of available SLA templates.
7. Client examines the SLA templates, and if they want one, proposes the SLA back to the SLA Service.
8. SLA Service examines the proposal and checks the client's account. If these checks pass successfully then the proposal is accepted and the SLA is created.
9. Client uses services permitted by the SLA. The usage is monitored, restricted and billed for by the SLA Service.
• Maintenance
10. Service manager monitors usage
11. Service manager manages the service

Next: Metrics Previous: SLA Management Service