IT-Tude.com → Technical Solutions → Articles → 

 

Service Level Agreements

The areas covered by the SLA section include the grid aspects of Service Level Agreements. The focus is put on stressing the successful principles and identifying the lacking appropriate mechanisms which are important barriers for the Grid uptake by industry in distributed e-business environments. Any SLA management strategy considers two well differentiated phases: the negotiation of the contract and the monitoring of its fulfillment in run-time. Thus, SLA Management encompasses the SLA contract definition (basic schema with the QoS parameters), SLA negotiation, SLA monitoring and SLA enforcement according to defined policies.

The main point is to build a new layer upon the grid middleware able to create negotiation mechanism between providers and consumer of services. The automatic QoS negotiation is far away from being solved in a business context. Several SLA schemas and negotiations protocols have been proposed (WS-Agreement, WSLA, etc). These mechanisms tackle the negotiation of a simple service and with basic messages exchange. The automatic negotiation of composed services and consequently the multi-step negotiation of composed SLAs is a research topic for the future.

In addition the transformation of business like QoS metrics to measurable Grid infrastructure parameters is another important topic to look into. SLA Enforcement and monitoring subsystem have also the supervisor role in order to verify that the negotiated contract conditions of all running services are met. They use notification mechanisms for alerting about abnormal situation so that SLA Management can undertake effective corrective decision according to defined policies. The strategies to apply the defined corrective actions to achieve the desired resilience system levels are another important topic to support the future envisaged business environment.

 

Eight generic Requirements have been identified, describing specific problems which can be solved through the use of SLAs. These have then been grouped into Capabilities, which describe the functionalities of solutions to the previous problems. The Capabilities have been prioritised, and four main concepts have been extracted. They have been made into Design Patterns, which describe how a software component should address these issues. These have in turn been the basis for the implementation of middleware-specific software components. The following sections provide more insight.

 

SLA Requirements

There are a number of common requirements which have been identified as important for service level agreements:

 

SLA Common Capabilities

A Common Capability describes a functionality which answers one or several requirements.

Optimisation of resource selection
Addresses the need for an optimisation algorithm within the provider, linked to the resource scheduler, to find the most suitable time allocation based on the SLA.

Runtime monitoring
Deals with comparing provider monitored values with the metrics agreed in the SLA, and notifying in case of violations.

Negotiation
The Client and Provider need to agree on the conditions of the SLA before signing it. The algorithm presented is a negotiation based on requests sent by the user, and quotes replied by the provider. The initial situation is a client aware of a provider’s existence, and the final result is the signature of the SLA.

Publication and Discovery
Providers and clients need a common virtual place (marketplace) to meet. The former need to advertise their services, through a publication mechanism based on their SLA templates, while the latter need to find who can fulfill their needs, by using a search engine.

SLA Template
The providers may find it difficult to describe their resources in a clear and secure manner (including legal aspects and usability). The SLA Template capacity is a proposal of a format for templates to provide easy access to new Grid providers.

SLA Accounting
The providers need to make a summary of the used resources on a user basis, and compare it to the conditions offered within the agreed SLA. The monitoring data must be used and analysed, and the accounting done regularly, including the possible penalties for violation of the SLA.

 

SLA Design Patterns

A Design Pattern describes a generic architecture for an abstracted solution to a Common Capability.

Optimisation of Resource Selection
Offers a service to the Grid users aiming at optimizing the scheduling of the jobs in the environment.

Runtime Monitoring
Receives from the Host Monitoring components information on the status of the hosts where the application is deployed.

Negotiation
Negotiates the SLA between a customer and provider.

SLA Accounting
Computes the charges to be made to each consumer’s account according to a record of their usage for a specific service provider’s resources or services.

Components

Components are middleware-specific implementations of Design Patterns. The following components addressing SLA issues have been developed and improved as a result of their use within the Business Experiments (BE19 to BE25).

A summary table containing all the components, with their main information, can be consulted to have a global view of the components provided by the SLA cluster. It is available on the SLA components overview

The components above can be integrated into a general framework, which adds the SLA capability to the GT4 middleware. You can find more detail about this in this white paper Integrating an SLA architecture based on components.