www.s-cube-network.eu

S-Cube Learning Package

SLA-based Service Virtualization in distributed, heterogenious

environments

MTA SZTAKI, TU Wien (TUW)

Attila Kertesz, SZTAKI

Learning Package Categorization

S-Cube

Infrastructure Mechanisms for the Run-Time

Adaptation of Services

SLA-based Service Virtualization

Self-* Service

Execution

Learning Package Overview

Problem Description

SLA-based Service Virtualization

Federated Cloud Management

Discussion

Conclusions

User taskflow

Agreement negotiation

Service Discovery Service Brokering

Service Deployment

Virtual Resource

Service Registry

Service Execution lifecycle within S-Cube

Problem description

In heterogeneous, distributed service-based environments such as Grids

and Clouds, there is an emerging need for transparent, business-oriented

autonomic service execution.

In order to develop such a robust system, the following solutions need to

be achieved:

– Service-level agreement based user interaction at the highest level

– Self-managable system architecture to autonomously interact with the system

components and services

– Federation of different service infrastructures that enables interoperation at the

lowest level

Learning Package Overview

Problem Description

SLA-based Service Virtualization

Federated Cloud Management

Discussion

Conclusions

SLA-based service virtualization (SSV) architecture

Production Grids Clouds Web Services

Meta-Negotiator

Meta-Broker

Automatic Sevice Deployer

Broker Broker …

Au

ton

om

ic

Ma

nag

er

Parties, components

User: A person, who wants to use a service (also called as consumer)

MN – Meta-Negotiator: A component/service that manages Service-level

agreements. It mediates between the user and the Meta-Broker, selects

appropriate protocols for agreements; negotiates SLA creation, handles

fulfillment and violation.

MB – Meta-Broker: Its role is to select a broker that is capable of

deploying/executing a service with the specified user requirements.

B – Broker: It interacts with virtual or physical resources, and in case the

required service needs to be deployed it interacts directly with the ASD.

ASD – Automatic Service Deployment: It installs the required service on the

selected resource.

S – Service: The service that users want to deploy and/or execute.

R – Resource: Physical machines, on which virtual machines can be

deployed/installed.

S

R

S S

R

Target areas, operational steps

R R

ASD ASD ASD ASD

B B

MB

User

MN

. . .

. . . . . .

SLA negotiation,

assurance

Information on

availability, properties

Means of negotiation

User – MN: user supplies a specific meta-negotiation document

MN – MB: agreeing on specific negotiation documents containing specific

negotiation strategy to be used, negotiation protocols to be used (WSLA,

WS-Ag,…) , terms of negotiation (e.g. time, price, …), security infrastructure

to be used

MB – B: agreeing on a specific SLA written in a specific SLA language (e.g.

WSLA, WS-Agreement) containing concrete SLA parameters like concrete

execution time, concrete price, etc. Forming a service specification

document

B – ASD: agreeing on a specific service to be available on the ASD

managed resources with the resource constraints resulted from the higher

level negotiation – the service is going to be able to use the requested

resources without disruptions from other parties

Furthermore we need on each level (MN, MB, B, ASD) a negotiator which is

responsible for generating and interpreting SLAs.

Meta-Negotiation in SSV

Responsible for

creating low-level

agreements from

general user

requirements

MB provides

aggregated

dynamic data on

brokers and

available services

Sample Meta Negotiation document

<meta-negotiation xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance … >

<entity> <ID name="1234"/> … </entity>

<pre-requisite>

<role name="Consumer"/>

<security>

<authentication name="GSI"/><authorization name="xy"/>

</security>

<negotiation-terms>

<negotiation-term name="beginTime"/> <negotiation-term name="endTime"/>

<negotiation-term name="price"/>

</negotiation-terms>

</pre-requisite>

<negotiation>

<document name="WSLA" value="uri" version="1.0”/>

<document name="WS-Agreements" value="uri" version="1.0”/>

<protocol name="alternateOffers" schema="uri" version="1.0” location="uri"/>

</negotiation>

<agreement>

<confirmation name="confirmator" value="arbitrator”/>

</agreement>

</meta-negotiation>

Meta-negotiation steps

Publish. A service provider publishes descriptions and conditions of

supported negotiation protocols into the registry.

Lookup. Service consumers perform lookup on the registry database by

submitting their own documents describing the negotiations that they are

looking for.

Match. The registry discovers service providers who support the

negotiation processes that a consumer is interested in and returns the

documents published by the service providers.

Negotiate. Finally, after an appropriate service provider and a negotiation

protocol is selected by a consumer using his/her private selection strategy,

negotiations between them may start according to the conditions specified

on the providers document.

The participants publishing into the registry follow a common document

structure (ie. meta-negotiation document) that makes it easy to discover

matching documents.

Meta-brokering in SSV

Meta-brokering means a higher level resource management that utilizes existing Brokers to access various resources of different distributed environments.

Meta-Broker components

The Meta-Broker is the core component: this communicates with the other components

The Translators are responsible for transforming the user request to the language of the actually selected Broker (JSDL<-> JDL, RSL, xRSL…)

The Invokers hand over the job to the brokers and wait for the results, and provide additional information for the Information Collector about the submissions

The Information Collector stores the connected broker properties and historical data of the previous submissions

The Matchmaker compares the JSDL of the actual job to the BPDL of the registered resource brokers, and selects a ‘good’ broker for the job (or service)

The IS Agent regularly updates current properties and availability of the virtual resources reachable by the utilized brokers

Automatic Service Deployment in SSV

Automatic service

deployment is a higher

level service

management concept

which provides the

dynamics to SBAs

E.g. during the SBA’s

lifecycle services can

appear and disappear

without the disruption of

their overall behavior.

On demand deployment

ASD architecture details

Repository – holds the images of various services as ready to use virtual

machine images (Virtual Appliances)

ASD – Automatic Service Deployment coordinates the proper resource

allocation for the given service according to the requirements from the

broker

WS – Workspace service, offers the virtualization capabilities – virtual

machine creation, removal and management - of a given grid/cloud site

as a WSRF service

Component interactions in SSV

Simulation environment for managing services in a heterogenious environment

Simulator Meta- Broker

J J

B B …

…

J

B result

Broker P P …

Broker P P …

…

Resource M M …

Resource M M …

Resource M M …

…

Workload Workload Workload …

IS Grids load

GridSim

GridSim extension

CloudSim extension

Cloud Broker

CloudSim

Data- center

VM …

VM

SSV

Brokers in the simulation:

Grid brokers are extended GridUser entities:

– they can be connected to one or more resources,

– they are able to execute gridlets on these resources,

– different properties can be set to these brokers, some properties can

be marked as unreliable,

– various scheduling policies can be defined,

– finally they report to the IS Grid load database.

A Cloud broker is an extended DatacenterBroker entity:

– it can be connected to a data center with one or more virtual machines

(VMs),

– and it is able to execute cloudlets on these virtual machines.

Simulator entity

The Simulator class is an extended GridSim entity:

– it can generate and submit a requested number of gridlets (jobs) with different properties, start and run time (length);

– it is connected to the created brokers and able to submit jobs to them;

– in case of submissions to the Cloud broker, it converts gridlets to cloudlets;

– the default job distribution is the random Grid broker selection;

– in case of job failures a different broker is selected for the actual job;

– it is also connected to the Meta-Broker Service through its web service interface and able to call its matchmaking service for broker selection.

We suppose in these simulations that meta-negotiation is done before submitting the jobs to the meta-broker. Therefore the job description contains such requirements that can be satisfied by one of the available brokers (or the Cloud broker).

Simulation setup

4 virtual appliances encapsulate the four different services of the TINKER workflow: GEN, TINKERALG, COLL and UPLOAD images.

ASD have reduced the sizes of the created appliances

Each service have been pre-deployed 50 times on an 8 node (32 CPU) Eucalyptus cluster, and measured the interval between the deployment request and the service's first availability.

The measurement results are shown in the next table; these latencies were also applied in the simulation environment within the Cloud broker.

Results

On demand deployment

introduces some overhead

Service duplication

increases performance

Further investigation of

deployment strategies

are needed

Learning Package Overview

Problem Description

SLA-based Service Virtualization

Federated Cloud Management

Discussion

Conclusions

Emerging Clouds

As the interests towards Cloud Computing solutions are

growing, the need for federating separate Cloud systems is

inevitable.

Cloud delivery models

Infrastructure as a Service

Platform as a Service

Software as a Service

Federated Cloud Management architecture

The introduced SSV architecture can be extended and

focused on infrastructure Cloud solutions.

Federating different clouds can be facilitated using the

brokering and meta-brokering layers of the SSV architecture

with a two-level brokering:

– At the top level a meta-brokering service chooses among available

infrastructure Clouds

– At the bottom level CloudBrokers schedule virtual machines (VM) to

available resources

FCM architecture

Each CloudBroker

has an own queue

for storing the

incoming service

calls, and manages

one virtual machine

queue (VMQ) for

each appliance (VA).

Cloud brokering in FCM

The default virtual machine scheduling is based on the

currently available requests in the queue, their historical

execution times, and the number of running virtual machines

(VM).

The secondary task of the CloudBroker involves the dynamic

creation and destruction of the various VMQs.

Virtual Machine Handler components are assigned to each

virtual machine queue. These components process the virtual

machine creation and destruction requests placed in the

queue. The requests are translated and forwarded to the

corresponding IaaS system. This component is a cloud

infrastructure-specific one, that uses the public interface of the

managed infrastructure.

Learning Package Overview

Problem Description

SLA-based Service Virtualization

Federated Cloud Management

Discussion

Conclusions

Discussion and futher research directions

In this learning package we revealed how to manage different

service infrastructures in a unified system:

– by supporting SLA-based user interaction,

– using an autonomic system to manage inner interactions, and

– building a federation of different infrastructures.

There is still room for further research in:

– enhancing self-healing capabilities of the system, and

– increasing the number of supported application types to exploit more

from the available infrastructures.

Learning Package Overview

Problem Description

SLA-based Service Virtualization

Federated Cloud Management

Discussion

Conclusions

Summary

Service provisioning can be facilitated with an SLA-based

Service Virtualization architecture built on three areas:

– a meta-negotiation component for generic SLA management

– a meta-brokering component for diverse broker management

– and an automatic service deployment for resource virtualization on

the Cloud

The shown service virtualization architecture can be validated

in a heterogeneous, distributed simulation environment, which

has been exeplified using a biochemical case study.

The SSV architecture can be extended towards infrastructure

Clouds to operate as a Federated Cloud Management

solution, using a two-level brokering for Cloud selection and

optimal VM placement.

Further S-Cube Reading

A. Kertesz, G. Kecskemeti, I. Brandic, I. An SLA-based resource virtualization approach for on-demand service provision. In Proceedings of the 3rd international Workshop on Virtualization Technologies in Distributed Computing. VTDC '09. ACM, New York, NY, 27-34, 2009.

A. Kertesz, G. Kecskemeti, I. Brandic, Autonomic SLA-aware Service Virtualization for Distributed Systems, In proceedings of the 19th Euromicro International Conference on Parallel, Distributed and Network-Based Computing, IEEE Computer Society, pp. 503-510, 2011.

A. Cs. Marosi, G. Kecskemeti, A. Kertesz, P. Kacsuk, FCM: an Architecture for

Integrating IaaS Cloud Systems, In Proceedings of The Second International

Conference on Cloud Computing, GRIDs, and Virtualization.

Rome, Italy. September, 2011.

Acknowledgements

The research leading to these results has

received funding from the European

Community’s Seventh Framework

Programme [FP7/2007-2013] under grant

agreement 215483 (S-Cube).