Document Actions

4.3.4. SLA Templates

Jump to:

How to configure SLA templates

Overview

The SLA template controls which services the client may use, the quantity of resources on those services they may use and how much and how often they will be charged. A service provider may define and publish many different SLA templates. Templates may be tailored to individual customers and access to the templates restricted accordingly, or several different general templates may be defined with a variety of level of service and price to give the customer some choice.

The SLA templates may be defined and managed in the main service administration page as shown below.

An SLA template can be in one of two states:

draft: In this state the template is not visible to anyone but the service administrator. It can be edited and published.
published: In this state the template's visibility is defined by its access control rules. It cannot be edited any more.

In either state, a template may have its access permissions set, may be copied (creating a new draft template), exported and deleted.

Parts of an SLA Template

SLA templates may be defined either using the built in editor or using an XML file. An annotated sample SLA template is provided, parts of which are reproduced and discussed below. This template may be edited and then added to the SLA service using the "Add New SLA Template from file" facility. Once a template is uploaded, it can be viewed and edited by clicking on the template ID in the main SLA service web page.

Label and Description

The SLA template starts with a <label> and <description> tag that are used in both the client and server interfaces to identify the SLA template to users.

Billing Period

The SLA service aggregates usage of the functional services and periodically calculates a bill and charges the account that the SLA was proposed under. The billing period defines how often the account is charged.

    <billingPeriod>
        <years>0</years>
        <months>0</months>
        <days>1</days>
        <hours>0</hours>
        <minutes>0</minutes>
        <seconds>0</seconds>
    </billingPeriod>

The billing period is defined in terms of <years>, <months>, <days>, <hours>, <minutes> and <seconds> as shown above. The first bill for usage will occur one period after the SLA is agreed, or after the previous bill thereafter (i.e. every 1 day in this example).

Signing Fee, Subscription Fee and Currency

The signing fee is a charge made to the account when the SLA is agreed. The subscription fee is charged at the end of every billing period in addition to charges made for the resources used. The currency definition applies to all prices in the SLA.

    <signingFee>10.00</signingFee>
    <subscriptionFee>10.00</subscriptionFee>
    <currency>EUR</currency>

Validity Period

An SLA template is valid for a restricted period of time, outside of which a proposal from the client to use the SLA template will be rejected (e.g. "Special offer! This month only!"). The validity period is defined by a <startTime> and <endTime> element:

    <startTime>
        <year>2000</year>
        <month>1</month>
        <dayOfMonth>1</dayOfMonth>
    </startTime>

    <endTime>
        <year>2010</year>
        <month>1</month>
        <dayOfMonth>1</dayOfMonth>
    </endTime>

Permitted Services

A Service provider may want to only provide certain functional services to certain customers. For this reason, the SLA template may contain a list of permitted services. For convenience however, if the list of permitted services is empty then all functional services in the "sla-managed-services" group may be used with the SLA.

    <permittedServices>
        <permittedService>
            <url>http://example.com:443/gria-basic-app-services/services/JobService</url>
        </permittedService>
    </permittedServices>

Metrics

Metrics are used in the constraint and pricing term definitions (below). The concept of metrics is discussed earlier in the manual and further information is available in the metric editor page of this configuration section. Shown here is one exmaple of a metric represented in XML. Further examples may be seen in the supplied SLA template file.

    <metric type='RESOURCE'>
        <uri>http://www.gria.org/sla/metric/resource/cpu</uri>
        <description>
            <description>CPU</description>
            <plural>CPUs</plural>
            <instantaneous>number of CPUs</instantaneous>
            <cumulative>CPU time</cumulative>
        </description>
        <units type='DECIMAL'>
            <instantaneous>CPU</instantaneous>
            <cumulative>CPU.s</cumulative>
        </units>
    </metric>

Constraints

Each constraint element in the SLA template constrains the instantaneous value or cumulative usage of a metric. There are two sorts of constraint: indefinite and periodic. An indefinite constraint applies over the whole time of the SLA, from the start to now. A periodic constraint constrains the usage of a metric within a repeating time period. The later may be used to permit a certain amount of usage per day or month for instance.

    <constraint type='INSTANTANEOUS'>
        <metric>
            <uri>http://www.gria.org/sla/metric/resource/cpu</uri>
            ...etc...
        </metric>
        <bound>LE</bound>
        <private>false</private>
        <limit>1.0</limit>
        <contention>1.0</contention>
        <repeating>false</repeating>
    </constraint>

This constraint constrains the instantaneous measurement of CPU to be less than or equal to 1.0 at any one time. Or to put it another way the number of CPUs ≤ 1.

<bound>: This may take the value "LT" or "LE". These stand for "less than" and "less than or equal to" respectively (the same as the Fortran operators of the same name). If the above example constraint was changed to restrict the rate to < 1.0 (using "LT") then no jobs at all could be run.
<private>: This element may take the value of "true" or "false". If it is set to "true" then the constraint will be hidden from the user. See the discussion of private constraints below.
<limit>: Limit is the value we are constraining to.
<contention>: This element is only applicable to INSTANTANEOUS constraints and defines how many users are subject to the same constraint on the same resource (i.e. share the resource), with the limit giving the maximum available to any or all of them at any instant. For most purposes this "contention ratio" may be set to 1.0 but it is very useful to set higher values for some types of usage. For example, a service provider may have a cluster of 10 CPUs along with a queuing system. The constraint in the SLA could limit the instantaneous CPU number to ≤ 10 CPUs with a contention of 20. Twenty of these SLAs could be sold, and each client would know that there were 19 other users contending for the cluster and that they could expect to get just 0.5 CPU on average over a long enough period.
<repeating>: This element takes the value of "true" or "false". If it is false then the constraint is an "indefinite constraint" and applies for all time. For "true" see below.

    <constraint type='CUMULATIVE'>
        <metric>
            <uri>http://www.gria.org/sla/metric/resource/cpu</uri>
            ...etc...
        </metric>
        <bound>LE</bound>
        <private>false</private>
        <limit>1000.0</limit>
        <contention>1.0</contention>
        <repeating>true</repeating>
        <duration>
            <years>0</years>
            <months>0</months>
            <days>1</days>
            <hours>0</hours>
            <minutes>0</minutes>
            <seconds>0</seconds>
        </duration>
    </constraint>

This constraint constrains the CUMULATIVE usage of CPU to just 1000 CPU.seconds every day. In other words, the CPU time is ≤ 1000.0 CPU.s.

<repeating>: When this is "true" the constraint is a "periodic constraint" and a duration for the repeating period is also required.
<duration>: The duration specifies the length of the repeating period in terms of <years>, <months>, <days>, <hours>, <minutes> and <seconds> as shown above. The first period begins as soon as the SLA is agreed.

Private Constraints

In some situations a client will want to deal with a service provider in "business terms", that is what the client wants to get done, rather than "technical terms", or what resources are required to do the job. For instance, a client who requires frames of a video to be rendered may prefer to have an SLA that specified how many frames of high-definition video they were permitted to render per day, rather than an SLA that described how many CPUs and how much memory etc was on offer. To support this scenario in GRIA, private constraints may be defined.

In this example the service provider might define three constraints and a pricing term:

A public constraint saying "number of frames <= 100 per day".
A private constraint saying "CPU time <= 50 hours per day".
A private constraint saying "Disc space <= 100GB".
A pricing term saying "€0.50 per frame".

The service provider has had to make a judgement about what basic resources (CPU, disc) are required to fulfill the offer of 100 frames of video per day. All three constraints then go into the SLA template and the template is published. When the client views the SLA template though the private constraints are removed so all the client sees is the information they are interested in, namely how many frames they will be able to render (and how much it will cost). The SLA manager will pay attention to all the constraints though and will ensure that the service provider has sufficient capacity to meet the CPU and disc space constraints.

Further Examples of Constraints

It is easy to get confused about what different constraints mean and what the service is guaranteeing (or not), especially for metrics like CPU. Let us imagine that we have a service with a capacity constraint set to 10 CPUs. Given this, the service must share out the CPUs between competing users, each with CPU constraints in their SLAs.

If the constraint in the SLA says that you can have ≤1 CPU then upon agreeing the SLA the service will record than 1 CPU is permanently reserved and will let you have up to 1 CPU all of the time. The rest of the time the CPU would be left idle. The service could sell only 10 of these SLAs (to match its 10 CPUs).

If the constraint in the SLA says you can have ≤5 CPUs with a contention of 10 then the service will record that 0.5 CPUs are used up (5 CPUs shared between 10 is effectively 0.5 CPU each on average) and will let you have up to 5 CPUs any time you request a job. The service could sell 20 of these SLAs. If the service was sold up to its capacity then on average you will actually be able to use your 5 CPUs 1/10th of the time (10 being the contention ratio). Jobs for all users would enter the resource manager's queue and execute when the CPUs were available.

If the constraint in the SLA said you can have 1 day's worth of CPU seconds every month then the service will record that approximately 1/30th of a CPU has been allocated and could sell 30 of these SLAs. If you had a job that lasted a day and added it to the queue at the start of the month then you would get it executed by the end of the month, but if you put it in the queue near the end of the month it might not get run by the end of the month if the queue was full.

Other examples of constraints are given in the XML annotated example.

Pricing Terms

At the end of each billing period, the usage of an SLA is examined and a bill is calculated. Charges may be made for the cumulative usage of a metric (integral of measurement over time) or for the increase in the measurement of a metric over the billing period.

    <pricingTerm type='CUMULATIVE'>
        <description>standard rate</description>
        <lowerBound>300</lowerBound>
        <upperBound>-1</upperBound>
        <price>0.01</price>
        <currency>EUR</currency>
        <metric>
            <uri>http://www.gria.org/sla/metric/resource/cpu</uri>
            ...etc...
        </metric>
    </pricingTerm>

This pricing term charges 0.01 EUR for every second of CPU time used above 300 CPU.seconds. That is, 305 CPU.seconds costs 0.05 EUR.

<lowerBound> and <upperBound>: The lower and upper bound specify the usage interval that the pricing term applies to. The interval is closed at the lower end and open at the upper end. If the upperBound is set to -1 then it is taken as meaning +infinity.
<price> and <currency>: The price and currency define the charge that will be multiplied by the usage in the interval.
<metric>: The metric that this pricing term applies to.

    <pricingTerm type='INSTANTANEOUS_INCREASE'>
        <description>charge</description>
        <lowerBound>0</lowerBound>
        <upperBound>-1</upperBound>
        <price>0.10</price>
        <currency>EUR</currency>
        <metric>
            <uri>http://www.gria.org/sla/metric/resource/job</uri>
            ...etc...
        </metric>
    </pricingTerm>

This pricing term is of type INSTANTANEOUS_INCREASE and will cause a charge of 0.10 EUR for every job that is created.

The INSTANTANEOUS_INCREASE type of pricingTerm adds up all the increases in the instantaneous measurement of a metric over the billing period. It does not look at the difference between the start and the end of the billing period. As the number on the job metric increases by one every time a job is created, this can be used to charge for the number of jobs created during the billing period.

More pricing term examples may be found in the annotated example.

Defining and Editing SLA Templates

By clicking on the "New SLA template..." button or the "Edit" button of a draft SLA template you are taken to the SLA template editor page. Here using the simple interface all aspects of an SLA template including its access control rules may be defined or changed. If you have a fresh installation of the service and no metrics are defined, it will not be possible to define any constraints or pricing terms.

Publishing SLA Templates

When a Service Manager wants to publish an SLA Template they must click the "Publish" button next to the template. This action changes the state of the SLA Template from "draft" to "published" and gives access to the template to any person with the "client" role.

Setting Access Permissions on SLA Templates

When an SLA Template is initially uploaded to the SLA Service it is in the "draft" state. This means only the Service manager (who has the "owner" role) has access to it. Once the SLA template is published, it enters the "published" state and users with the owner and client roles can access it.

By default, anyone is accepted as having the client role, so anyone will be able to see a published SLA template. To restrict access to an SLA template the definition of who a "client" is must be changed. This is done by clicking on the template ID in the main SLA service web page to get to the template details page. Scrolling to the bottom reveals the access control rules for that template:

Access control rules for an SLA template

The first rule in the list says that to have the client role it is sufficient to have any subject distinguished name in your certificate and for your certificate to be signed by anyone. To remove this rule, click on the "Delete" button by the rule. A new rule must then be added to redefine who a "client" is. If the SLA template was intended to be seen by just one company, then the new rule would probably be one saying that to be a client, it is sufficient to have your certificate signed by the company's CA. This may be achieved by selecting "client", "sufficient" and "Certificate is signed by..." in the form, pressing "Add" and then uploading the relevant CA certificate.

For more information on how to configure access rules, please see the PBAC 2 manual.

Exporting an SLA Template

Clicking on the "Export" button in the SLA template table will create an XML definition of the template for downloading. Unfortunately, this XML definition is in a slightly different format to the one described above. It may still be used for uploading to another service but is not very easy to edit.

Next: Monitoring