hs4mc hierarchical sla-based service selection for multi ... 2014/closer... · hs4mc hierarchical...

HS4MCHierarchical SLA-based Service Selection for Multi-Cloud Environments

Soodeh Farokhi1, Foued Jrad2, Ivona Brandic1 and Achim Streit21Institute of Information Systems, Vienna University of Technology, Vienna, Austria

2Steinbuch Centre for Computing, SCC Karlsruhe Institute of Technology, KIT Karlsruhe, Karlsruhe, Germanyfs.farokhi, [email protected], ffoued.jrad, [email protected]

Keywords: Multi-Cloud, Service Level Agreement (SLA), Service Selection, Software-as-a-Service (SaaS),Infrastructure-as-a-Service (IaaS), InterCloud-SLA.

Abstract: Cloud computing popularity is growing rapidly and consequently the number of companies offering theirservices in the form of Software-as-a-Service (SaaS) or Infrastructure-as-a-Service (IaaS) is increasing. Thediversity and usage benefits of IaaS offers are encouraging SaaS providers to lease resources from the Cloudinstead of operating their own data centers. However, the question remains for them how to, on the one hand,exploit Cloud benefits to gain less maintenance overheads and on the other hand, maximize the satisfactionsof customers with a wide range of requirements. The complexity of addressing these issues prevent manySaaS providers to benefit from the Cloud infrastructures. In this paper, we propose HS4MC approach forautomatic service selection by considering SLA claims of SaaS providers. The novelty of our approach liesin the utilization of prospect theory for the service ranking that represents a natural choice for scoring ofcomparable services due to the users preferences. The HS4MC approach first constructs a set of SLAs basedon the given accumulated SaaS provider requirements. Then, it selects a set of services that best fulfills theSLAs. We evaluate our approach in a simulated environment by comparing it with a state-of-the-art utility-based algorithm. The evaluation results show that our approach selects services that more effectively satisfythe SLAs.

1 INTRODUCTION

Using various services from multiple Clouds to havea wide range of choices with various cost and qualityof services (QoS) can be viewed as a natural evolu-tion in Cloud computing. There are several reasons toutilize multiple Clouds such as: improving the qual-ity of service, while optimizing service cost; migrat-ing among various providers; avoiding vendor lock-in; and the need of particular Cloud services which arenot provided elsewhere. There are two types of deliv-ery models for multiple Clouds: Federated Cloud andMulti-Cloud (Petcu, 2013), which differ in the degreeof collaborations between the involved Clouds and theway that the user interacts with them. In the Federatedmodel, there is a need for an agreement between thevarious involved Cloud providers transparent for theuser. While in the Multi-Cloud model, which is thefocus of this paper, there is no need for such agree-ment. In the latter, a user is aware of various Clouds,and usually a third party is responsible to deal withthese variation in the service provisioning phase.

Software-as-as-Service (SaaS) providers, as po-tential Cloud infrastructure service users, are beingencouraged to profit from hosting their offered soft-ware service in the Cloud instead of establishing theirown data-centers. Therefore, SaaS providers are look-ing into solutions that minimize their overall infras-tructure leasing cost without adversely affecting thecustomers (Wu et al., 2011). To achieve this goal, itis essential to have a clear definition of user require-ments and then provide a solution by which these re-quirements are met. In the Cloud context, the ex-act requirements (both functional and non-functional)under which the services are or should be deliveredare specified in SLA. In addition, service deliverysystems are managed through the SLA managementprocess to meet the QoS objectives specified in theSLA. In the SaaS provider scenario, it is necessaryto specify and manage SLAs in two layers: an SLAbetween the SaaS customer and the SaaS providerthat reflects the QoS objectives of the offered servicesto the customer, and an SLA between the SaaS andthe Infrastructure-as-a-Service (IaaS) provider, which

722

implicitly affects the customer satisfaction. Becauseof the aforementioned advantages of Multi-Cloud andthe various QoS requirements of the SaaS providers,they have begun to exploit this fertile environment.

There have been a number of studies exploringservice selection in the Cloud such as (Bellavistaet al., 2013), (Clark et al., 2013) and (Wu et al., 2013).However, they have mostly focused on maximizingthe profit of either the customer or the IaaS providersby proposing solutions in a single Cloud without thor-oughly investigating SLAs. Thus, barriers relevant tothe service allocation for SaaS providers while man-aging SLA issues in Multi-Cloud has not been stud-ied well. As a recent investigation of SLA interoper-ability issues in Multi-Cloud, an IEEE working groupcalled InterCloud Working Group (ICWG)1, has beenestablished recently to focus on developing a standardfor interCloud interoperability.

Since in Multi-Cloud dependent components ofa single SaaS application can be distributively de-ployed in diverse Cloud infrastructures with variousQoS attributes, from the SaaS provider perspective,the deployment can be considered as a Composite In-frastructure Service with a set of functional and non-functional requirements for each included applicationcomponent. As a result of service diversity in Multi-Cloud, the selection of a set of suitable services is achallenging task. The question remains how to, onthe one hand, score and select services for each sin-gle component and on the other hand, optimize thisallocation to satisfy the requirements of the compos-ite service. Moreover, these concerned QoS param-eters can be conflicting or have differing importancedegrees for the SaaS provider.

Stimulated by these challenges, in this paper weaddress the problems surrounding SLA managementand service selection for SaaS providers in Multi-Cloud to assist them in fulfilling their objectives inan effective way. We propose an SLA-based Multi-Cloud service allocation approach that sits betweenthe SaaS and IaaS provider and includes two mainphases: (1) the SLA Construction and the (2) ServiceSelection. In the first phase, the Composite Infrastruc-ture Service of SaaS provider is broken down to a setof functional and non-functional requirements calledsub-SLAs and a meta-SLA. Meta-SLA includes therequirements of a more abstract level related to thewhole composite service, while sub-SLAs express re-quirements of each infrastructure service included inthis composite service.

The first phase forms SLAs named InterCloud-SLAs that are provider-independent. These SLAs in-clude SaaS provider desired QoS requirements for the

1http://grouper.ieee.org/groups/2302/

application deployment on the Cloud. The focus ofthis paper is the second phase which uses an algorithmto score services based on the user satisfaction. As theuser satisfaction has been a subject of great interestto Cloud providers, the principle of prospect theory(Kahneman and Tversky, 1979) is used in the scoringand selection algorithm to model the user satisfactionas a function of quality aspect of service and the im-portance of each parameter for the user. This theoryis an alternative descriptive model of decision makingunder risk for utility theory and is said to be more re-alistic in calculating the user satisfaction. Based onthis theory the changes in specific quality aspects ofa service is sensed more by users who have assignedhigher weights to these aspects. Namely, satisfactionis subjective and may be different for different userseven for the exact same service with the same qualityaspects. To the best of our knowledge, this is the firstapplication of prospect theory in the Cloud service se-lection problem.

As prospect theory is an alternative model for util-ity theory, we evaluate our work by comparing the re-sult with a utility-based matching algorithm using areal-world SaaS provider scenario based on a simula-tion environment. As it will be presented later in thepaper, the evaluation result shows the flexibility andeffectiveness of our selection algorithm as well as jus-tification of our SLA specification in a Multi-Cloud.

The remainder of this paper is organized as fol-lows. In Section 2 we discuss the related work. Sec-tion 3 presents an overview of HS4MC approach andoutlines its main phases, while Section 4 focuses onthe selection algorithm and SLA specification by con-sidering a concrete example. Section 5 is dedicated tothe evaluation of our approach, and finally, in Section6 we conclude the paper and express the directions ofour future work.

2 RELATED WORK

The issues of SLA-based service selection has beenwidely investigated in both web service domain andCloud computing in recent years. In this section weexplore approaches dealing with this issue. An ex-tensive comparison of existing approaches workingon service selection for composite Web services isgiven in (Moghaddam and Davis, 2014). In web ser-vice domain, the author of (Yau and Yin, 2011) pro-poses a web service QoS-based ranking and selectionapproach. Their approach calculates the satisfactionscore of the user for each QoS parameter based onthe basis of prospect theory and then aggregates thescores in order to select the service with the highest

HS4MC�-�Hierarchical�SLA-based�Service�Selection�for�Multi-Cloud�Environments

723

HS4MC Approach

Multi-Cloud

SLA SLA

SLA

SLA

SLA SLA

SLASLA

SubSLA

subSLA

subSLA

SLA SLA

Middleware Layer

customer customer

SaaS provider

SLA

SLA

SaaS Provider Layer

Customer Layer

IaaS provider Layer

SLA SLA

SLA Tech

nical d

etails SLA

Ab

stra

ctio

n

metaSLA

Systematic perspective SLA hierarchy perspective

Customer SLA

SaaS Provider SLA

InterCloud SLAs

IaaS provider SLA

Figure 1: SLA hierarchy and service diversity in Multi-Cloud.

aggregated score. Their approach has some signifi-cant advantages over existing work, such as selectingthe service that best satisfies QoS requirements con-cerning by the user, instead of the service with the bestQoS, which may lead to over-qualification and canimprove utilization of services. Moreover, by usingprospect theory, they modeled the relation betweenservice QoS parameters and the user satisfaction moreprecisely. However, in their work, they only focus ona single service selection. In our work, we also use theprinciple of prospect theory to rank both single Cloudservices as well as composite Cloud services.

For the service selection in Multi-Cloud, amethodology is needed to compare Cloud servicesbased on the various criteria such as the cost and QoSparameters for different user profiles (Petcu, 2013).In addition, because of the SLA heterogeneity in thisenvironment, SLA management from both customerand provider perspectives is challenging.

Most of the works that focus on the SLA-basedservice selection and allocation in Clouds are focusedonly on maximizing the customer profit (Dastjerdi,2013) and (Clark et al., 2013) or IaaS provider profit(Lee et al., 2010). The work in (Wu et al., 2011) isone of the first dealing with resource allocation fromthe SaaS provider perspective. This work was alsoenhanced to support both customer and SaaS providerprofits in (Wu et al., 2013). The authors propose an al-location strategy for SaaS providers to maximize theirprofit and customer satisfaction level when deploy-ing their applications in Cloud infrastructure services.Their approach also supports the dynamic changingof customer requests with the goal to minimize thenumber of used VMs. However, in their SLA, theyconsider just response time and service initiation timeas service selection parameters for SaaS provider. Inaddition, their evaluation is performed in one Cloudwith a single requested VM per Service.

Similar works have investigated service alloca-tion in the Cloud (Son et al., 2013) and our previ-ous work (Emeakaroha et al., 2011) by providing anSLA-driven resource allocation scheme that selectsa proper data center among globally distributed cen-ters operated by a provider. In contrast, we supportcomposite Multi-Cloud services where the SLA of thecomponent services can even be conflicting, by sup-porting more parameters such as availability, latency,reputation, throughput and cost.

The concept of sub-SLA and meta-SLA were firstmentioned in (Ouelhadj et al., 2005) in Grid comput-ing domain. The authors use these concepts to sched-ule jobs in Grids by utilizing a multi-agent system andan SLA negotiation protocol. Our usage of these con-cepts on Multi-Cloud significantly differs from thisone due to the differences between Grid and Cloudbusiness models.

Compared to the previous works, we propose anapproach to assist SaaS providers to select the mostsuitable Cloud infrastructure services while handlingthe SLA hierarchy and heterogeneity (in abstractionand technical details) and variety of services in Multi-Cloud. Our goal is to maximize the SaaS providerprofit by maximizing its SLA satisfaction level, whichwe believe can be achieved by applying prospect the-ory in the computation of user satisfaction

3 HS4MC APPROACH

The systematic perspective of Figure 1 representsthe position of HS4MC approach. It lies betweenthe SaaS and IaaS provider layers and handling theSLA heterogeneity and service selection. HS4MCproposes the concept of sub-SLA and meta-SLA asInterCloud-SLAs to be able to cover the requirementsof the SaaS provider for the Composite Infrastructure

CLOSER�2014�-�4th�International�Conference�on�Cloud�Computing�and�Services�Science

724

SLA Repository

IaaS offers Repository

SaaS provider Requirements

2 sub sla

SLA Construction Engine

Meta-SLA

Sub-SLA

Service Selection Engine

Service Ranker

Composite Service Ranker

InterCloud SLA

sla sla

sla

sla

Composite Cloud Service

Phase 1

Phase 2

input

output

output

input

Input & output of phase 1

Input & output of phase 2

MetaSLA

SaaS Component

sub sla

sub sla

Figure 2: HS4MC architecture and phases.

Service as well as each included service. In HS4MCapproach, we focus on the SLA between a SaaS andan IaaS provider which includes both functional andnon-functional parameters. Each non-functional pa-rameter in an SLA can be considered as hard or soft.Hard parameters must be satisfied, e.g the infrastruc-ture cost must be less than a specific amount, whilesatisfaction of soft parameters is not mandatory butpreferred, e.g response time is preferred to be lessthan 5s. By SLA satisfaction, we mean providingfunctional and hard non-functional parameters as wellas trying to find the most suitable services for the softones.

In HS4MC there are two phases: SLA Construc-tion and Service Selection, which are described in thissection. Figure 2 depicts the HS4MC architecture andthe included phases along with the input and output ofeach phase.

SLA Construction Phase. As the input of thisphase, the SaaS provider submits its Cloud infras-tructure requirements to the SLA Construction Engineas a single XML file. These requirements containtwo abstract parts: one including the requirementsfor each infrastructure component (Cloud virtual ma-chine (VM) or storage), and the other enfolding therequirements of the whole set of requested infrastruc-tures. The SLA Construction Engine extracts the datarelated to these two parts and constructs a set of sub-SLAs as well as a meta-SLA by utilizing an SLA on-tology. The main purpose of constructing such SLAs,named InterCloud-SLA2 is to address the SLA inter-operability issue in Multi-Cloud. Figure 1 presentsthis process by considering the SLA hierarchy per-

2Inspired by a sub-group of aforementioned IEEE Inter-cloud Working Group (ICWG), named InterCloud-SLA.

CAD-aaS

Customer

meta-SLA

SaaS Provider1

CAD-aaS Standard Edition

(connectivity =1)(connectiv

ity =3)

(connectivity =2)

4

CAD Application UI

(1 Small Cloud-VM)

sub-SLA (UI)

3

CAD Models(100 GB Cloud-Storage in Europe)

sub- SLA (Storage)

2GPU

(1 Large Cloud-VM)

sub- SLA(Computation)

Figure 3: Composite infrastructure service for a CAD-aaSstandard edition.

spective.Namely, the SLA Construction Engine needs some

sort of data-connection and reasoning ability in or-der to break down the SaaS requirements in a waythat they can be mapped to the current service offers.Moreover, it should be able to combine current offersin order to provide new value-added services for theuser requirements. The further steps of this phase onSLA extraction are according to our previous work(Breskovic et al., 2013) and (Redl et al., 2012).

Service Selection Phase. The InterCloud-SLAsand the IaaS providers’ offers are two inputs of thisphase, as shown in Figure 2. The Service Rankercomponent is responsible for creating a ranking listof services for each sub-SLA, which are then used bythe Composite Service Ranker component to score thecombinations of services for the meta-SLA. The out-put of this phase is a Composite Cloud Service, whichhas the best satisfaction score among the other candi-dates. Before describing the details of this phase inthe following section, we present a concrete exampleto provide the intuition of our approach.

3.1 Example Scenario

As a running example, a CAD3 software provideraims to deploy its CAD software in Cloud and offersit as a public Cloud SaaS, called CAD-as-a-Service(CAD-aaS), in three software editions: enterprise,professional and standard. Each edition has a specificset of requirements. The CAD-aaS provider wantsto deploy the various components of its CAD ser-vice, presented in Figure 3 in Cloud, so it requestseveral Cloud infrastructure services: one small VMfor the application user interface (UI), one large VMwith GPU features for the computation componentand 100GB of storage to store the CAD models. Eachrequested service has a sub-SLA. Non-functional pa-rameters related to the whole CAD composite ser-

3Computer-Aided Design


725

vice form the meta-SLA. The edge numbers repre-sent the execution sequence of the CAD-aaS. Thecomponents communicate with each other based onthe CAD software application topology. The degreeof data communications between components are de-picted as connectivity value for each edge and it willbe described later. The rationale behind choosing thisexample is that deploying CAD applications in theCloud has been investigated widely; for example itis used in the Cloudflow project 4 which has the aimto make the Cloud infrastructures a practical solutionfor manufacturing by automatic provisioning of SaaSapplications over Cloud infrastructure services.

4 SERVICE SELECTION PHASE

The cornerstone of the Service Selection Phase is aselection algorithm that works based on prospect the-ory to compute the user satisfaction score for a certainservice. This theory is proper for describing user de-cisions among various choices with uncertainty, andconsiders human behavior in computation of the usersatisfaction. We adopted the idea of the algorithmpresented in (Yau and Yin, 2011) and developed it tosupport service selection for a Cloud composite ser-vice, and to cover all functional and non-functionalparameters of InterCloud-SLAs. In this section, wefirst introduce the SLA specification used in the Ser-vice Selection Phase, then we elaborate the steps ofthe selection algorithm.

4.1 SLA Specification

A set of m infrastructure services can be defined asfollows where Fi is the functional parameter of serviceSi and NFi is its non-functional parameter.

Service O f f ers = fS1; � � � ; Smg;

Si = fFi; NFig 1� i� m (1)

The InterCloud-SLA contains a set of n sub-SLAs andone meta-SLA and is defined by

InterCloud SLA =

ffsubSLA1; � � � ; subSLAng; metaSLAg (2)

where each subSLA j and metaSLA includes a set offunctional parameters F and non-functional parame-ters NF as follows:

subSLA j = fFj; NFjg 1� j � n (3)

metaSLA = fF; NFg (4)

4http://eu-cloudflow.eu/project/concept.html

Non-functional parameters of subSLA or metaSLA,NFk are represented as tuple

NFk = fMink; Maxk; Wk; Tkg 1� k � l (5)

where Mink and Maxk determine the accepted bound-aries for parameter k. Wk represents the user prefer-ence on parameter k in the service selection, and it isvalued within (0, 1]. A larger Wk shows that parameterk is more important for the user, so this parameter willhave more impact on the service ranking. Tk specifiesthe type of parameter k, which can be hard or soft.In the selection algorithm, non-functional parametersare treated in the same way as functional parameters.

If the user specifies no value for each of the in-troduced factors, the default values are assigned, Tk =so f t and Wk = 0:5 that show the medium importanceof parameter k. Moreover, for Mink and Maxk, thedefault values are defined as the smallest and largestvalues for parameter k within a corresponding set ofService O f f ers. For example, if k = availability,then Mink = 90% and Maxk = 100% can be assignedas the default values.

The last part in our modeling is a graph which de-scribes the degree of connectivity among sub-SLAs (anumber between 1 to 3, larger means higher connec-tivity). In this graph, the nodes present the sub-SLAsand the edge shows to which degree these two cor-responding components are going to transfer data atruntime, which influence the traffic cost and latencyof the composite deployment. As depicted in Fig-ure 3, the connectivity value for each edge shows theamount of data transfer between the involved nodes.For example, the computation node transfers the high-est amount of data with the storage node, among otheredges in the CAD-aaS graph.

4.2 Service Selection Algorithm

The selection algorithm, as depicted in the followingpseudo code, can be described in six steps.

Step (1) A set of services that satisfies the func-tional and hard non-functional parameters is chosenfor each sub-SLA (line 4-5). We assume that the fil-tered list in not empty at this step, indeed the negoti-ation with the user in case that no service is found forthe given requirements can be considered as a futurework.

Step (2) Due to the variety of differing non-functional parameters in metrics and scales for a givenservice set, they are needed to be normalized beforebeing used in service ranking. In Equation (6), wenormalize service quality parameters in such a waythat the higher value always means better. This equa-tion calculates the normalized result, Nik, for values


726

Norm(NFik) = Nik =

8>><>>:NFik � Min jkMax jk � Min jk

i f larger NFik is desirable

Max jk � NFikMax jk � Min jk

i f smaller NFik is desirable

(6)

between the accepted boundaries, Min and Max. Forvalues which are better than accepted boundaries, theresult is 1 and for the worse values the result would be0. For parameters like availability where larger valueis desirable, we use the first case, and for parameterslike cost, where minimization is the goal, the secondcase is used for the normalization (line 6-8).

Listing 1: Pseudo-code of the selection algorithm.

1 Input: ServiceOfferList , subSLAList , metaSLA

2 Output : Selected CompositeService

3

4 for each subSLA in subSLAList

5 Filter ServiceOfferList by F and Hard -NF

6 for each NFi of Si in ServiceOfferList

7 for each NFj in subSLA j

8 Normalize Value NFik by Norm(NFik)

9 Compute satisfaction score Nik by SSF(Nik)

10 endfor

11 Compute FinalSatisfactionScore Si by CF(Si)

12 endfor

13 endfor

14 Store all Combinations of services of Service -

15 OfferList in CompositionServiceList

16 for each Composition in CompositionServiceList

17 for each NF in metaSLA

18 Compute AggregatedValue

19 endfor

20 endfor

21 Filter CompositionServiceList by F and Hard -NF

22 for each Composition in CompositionServiceList

23 for each NF in metaSLA

24 Normalize AggregatedValue of NF by Norm(NF)

25 Compute satisfaction score Composition

26 by SSF(N)

27 endfor

28 // based on included services and subSLAs

29 Compute average FinalSatosfactionScore

30 // based on subSLAs and metaSLA

31 Compute FinalCompositionScore by Score f inal

32 // based on calculated FinalCompositionScore

33 Sort CompositionServiceList

34 endfor

35 return Selected CompositeService

Step (3) Let Nik be the normalized value of NFik ofservice Si, the Satisfaction Scoring Function SSF canbe defined as Equation (7). This formula computesthe user satisfaction score of the normalized value Nikof each non-functional parameter in Si based on the

Wj in subSLA j (line 6-10).

SSF(Nik) =

8<: 0:5(2Nik�1)1�Wjk +0:5 Nik>0:5

�0:5(�2Nik +1)1�Wjk +0:5 Nik�0:5

(7)The rationale behind the SSF is based on prospect

theory. This theory implies that changes in a specificquality aspects of a service is sensed more by userswho have assigned higher weights to those quality pa-rameters. Indeed, the satisfaction of user for a ser-vice is based on the gains and losses relative to thereference point (normalized value of 0.5) instead ofabsolutely determined by the normalized QoS param-eters of that service. Moreover, satisfaction is influ-enced by the importance weight of user assigned to aspecific quality parameter. According to this theory,the satisfaction function should be concave for gains,and convex for losses. To clarify the behavior of theSSF , we present the graphs in Figure 4. Each curveshows the behavior of SSF based on different weightsfor various non-functional parameters supported ei-ther in sub-SLA or meta-SLA. For example, in thesecond diagram which the accepted boundaries are99.5% as minimum and 100% as maximum, then thenormalized value of 0.4 (value=99.7%) has differentsatisfaction scores for standard, professional and en-terprise users based on their specified weights. Otherdiagrams also show the influence of weights in SSFfor differing non-functional parameters. The weightscan also be different based on the goal of the user fora service. For example, the first diagram shows vary-ing weights of a user for response-time of differentinfrastructure services. As depicted response-time forVM which is dedicated to UI5 is more important foruser (higher weight) than VM for computation.

Step (4) Until now, we have calculated the satis-faction score for each NFi of service Si, so we have asatisfaction score set fSCi1; � � � ;SCik; � � � ;SCilg calcu-lated based on the fNFj1; � � � ;NFjk � � � ;NFjlg. At thispoint, it is needed to compute the final satisfactionscore of each service by the following CombinationFunction CF (line 11)

CF(Si;subSLA j) =å

lk=1 SCik:Wjk

ålk=1 Wjk

(8)

Step (5) The previous steps (line 4-13) are exe-cuted on the sub-SLA level, while from this step on,

5User Interface


727

0.0 0.2 0.4 0.6 0.8 1.0Normalized Value

min=0; max=30 (s)

0.0

0.2

0.4

0.6

0.8

1.0

Sati

sfact

ion S

core

(used in sub-SLA) Response-time

vm-UI: w=0.8

vm-Com: w=0.5

storage: w=0.7


min=99.5; max=100 (%)

0.0

0.2

0.4

0.6

0.8

1.0

(used in sub-SLA & meta-SLA) Availability

stand. w=0

prof. w=0.5

ent. w=0.75


min=0; max=budget ($)

0.0

0.2

0.4

0.6

0.8

1.0

(used in meta-SLA) Cost

stand. w=0.75

prof. w=0.6

ent. w=0.5


min=3,4,5; max=10

0.0

0.2

0.4

0.6

0.8

1.0

(used in meta-SLA) Reputation

stand. w=0.25

prof. w=0.5

ent. w=0.75

Figure 4: The effect of weighting and min-max boundaries in satisfaction score for parameters of sub-SLA and meta-SLA.

the meta-SLA will be processed. First, for all possi-ble combinations of selected services correspondingto each subSLA, the aggregated non-functional val-ues are calculated by using their correlated aggregatedfunctions, defined in Table 3 (line 14-20). Then, thealgorithm follows the same steps (1 to 4) by consider-ing the aggregated values, meta-SLA and the possibleservice combinations, named Composition (line 21-26).

Step (6) For the final selection, the algorithm con-siders the influence of both sub-SLAs and meta-SLA.To this aim, the average FinalSatis f actionScoresof services included in the Composition (line 27-28) is computed. Then, by the Equation (9)in which WmetaSLA is the importance weight ofmeta-SLA and WsubSLA the weight of sub-SLA, theFinalCompositionScore is calculated for the final se-lection (line 29-30).

Score f inal =WmetaSLA:Scoreagg +WsubSLA:Scoreave(9)

The first ranked CompositeService would be the out-put of Selection Algorithm (line 31-34). The topranked composite service is the one with the largestsatisfaction score which means that the service QoScan best satisfy the user requirements. Hence, in theproposed algorithm the services whose QoS parame-ters are not the best in comparison with other servicescan still be ranked on the top as long as they perfectlysatisfy the user QoS requirements. This is beneficialin improving utilization of services, and also savingthe resources to satisfy other users.

5 EVALUATION

In this section, we evaluate the proposed algorithmusing the scenario described in Section 3.1 in com-parison with a state-of-the-art utility-based matchingalgorithm (Jrad et al., 2013). For this purpose, we im-plemented both algorithms in Java language and then

Table 1: Functional and non-functional parameters of sim-ulated IaaS providers (S=Small; M=Medium; L=Large).

Parameters Definition (unit/range)IaaSType V MS=M=L , StorageLocation data-center region (1�4)

Reputation provider reputation rank (1�10)

Availability up-time of service (%=3 Month)

ResTime time to fully receive an answer (s)

T hroughput download a few large files (Mb=s)

CostV M lease V MS=M=L ($=hour)

CostStorage store ($=GB=Month)

CostTra f f ic download ($=GB=Month)

conducted a set of simulations. The experimental re-sult will be presented in this section.

Table 2: Latency matrix (ms).

USA Europe Asia AustraliaUSA 25 150 250 100Europe 150 25 150 200Asia 250 150 25 500Australia 100 200 500 25

5.1 Simulation Setup

In order to model heterogeneous infrastructure ser-vices in a Multi-Cloud environment, we simulate 12commercial IaaS providers, each with one or moredata centers distributed along different geographicallocations (four continents). In our simulation envi-ronment, each provider has a set of functional andnon-functional parameters as well as pricing models,as depicted in Table 1. Each provider either providesCloud storage or Cloud VMs presented in three sizes:small, medium, and large. The VM budget is givenbased on the computation units. one, two and fourcomputation units are respectively assigned to small,medium and large VM sizes. We assume that compu-


728

Table 3: Meta-SLA functional and non-functional parameters and the corresponding aggregated functions.

Parameter Definition Unit/Range Aggregation functionContractduration leasing period hour -Budget V M(small=hour); Storage(GB=month); Tra f f ic(GB=month) $ -Availability up-time of composite service % Avaagg = Õ

ni=1 Ava(Si)

Throughput downloaded data from composite service Mbit/s T hagg = minni=1T h(Si)

Latency latency of composite service ms Latagg =å

ni; j=1 W (Si j):Lat(Si j)

åni; j=1 W (Si j)

Reputation popularity of included providers 1 - 10 Repagg =å

ni=1 Rep(Si)

n

tational units of different IaaS providers for the sameVM size are similar. The pricing model for each simu-lated provider has been acquired by the pricing modelof the corresponding real-world IaaS provider, whilethe values of QoS attributes have been gathered byrunning a set of Cloud tests via CloudHarmony6 onthe considered public Cloud providers using a singleclient hosted in Europe. This specification allows usto model a realistic simulation environment.

Furthermore, the reputation value for eachprovider is simulated considering the reputation rank-ing model introduced in (Itani et al., 2011). Dueto lack of free access to information related to thelatency between different data centers (available onCloudHarmony), a latency matrix has been definedwith synthesized values by considering the geograph-ical distances, shown in Table 2, while the latency be-tween services within the same data center is assumedto be 10ms.

Supported meta-SLA parameters in our simula-tion are presented in Table 3. In this Table, budgetis the willingness of the user’s investment in VM andstorage renting as well as the data traffic based on thedefined units. For the VM a unit of cost expresses thevalue of renting a small VM per hour, while for thestorage and traffic it represents the value of storing ortransferring 1GB of data per month. The calculationof the total budget in our simulation is based on thesethree introduced units as well as the Contractduration.In addition, the estimated size of the transferred dataalso influences the calculation of traffic cost. Forother non-functional parameters in the meta-SLA, asdepicted in Table 3, there is a corresponding aggre-gation function according to the ones introduced in(Zeng et al., 2003). These functions calculate the ag-gregated values of composite service non-functionalparameters based on its constituent services. In theaggregated latency formula W (Si j) is the connectivityvalue of each edge in the graph introduced in Section4.1. While Lat(Si j) is gathered from the latency ma-trix, showed in Table 2, based on the data center geo-

6http://cloudharmony.com/

Table 4: Meta-SLA values for different software editions.

Parameter (unit) Stan. Prof. Ent.Contractduration (hour) 720 720 720

Budget-VM ($=hour) 0:07 0:1 0:14

Budget-Storage ($=month) 0:1 0:12 0:15

Budget-Traffic ($=month) 0:1 0:12 0:15

Availability (%) 96 98 99:8

Throughput (Mbit=s) 5 5 15

Latency (ms) 100 100 40

Reputation (1�10) 3 3 5

Table 5: Sub-SLA values for different software editions(St=Standard; Pr=Pro f essional; En=Enterprise).

SubSLAUI SubSLAComp: SubSLAStor:Edit. St = Pr =En St = Pr =En St = Pr =En

Type vm vm storageSize S=M=L L=L=L 100=500=1000

Num. 1 = 1 =1 1 = 2 =5 1 = 1 =2

Loca. � � Europe

graphical location of included services in the compo-sition. In order to show the different aspects of our ap-proach, we run the experiments by three sets of SLAsfor three CAD software editions (Standard, Profes-sional and Enterprise), each with different meta-SLAsand sub-SLAs as depicted in Table 4 and Table 5, re-spectively.

As shown in Figure 3, CAD-aaS example, we di-vided the sub-SLAs into three logical groups. Thefirst group of requested services belongs to the in-frastructures which provide the application’s user in-terface, called subSLAUI . The second group, is re-lated to the infrastructures for computing the appli-cation’s business logic which is rendering the im-ages in CAD-aaS, called subSLAComputation. Finally,data persistence group belongs to the infrastructureswhich store and maintain the data (CAD models),called subSLAStorage. Although our approach is flex-ible enough to receive three different sets of sub-SLAs fsubSLAUI , subSLAComputation, subSLAStoragegfor each software edition, we consider the same setfor all editions. The rationale behind it is that each


729

96

5

100

3

99.91

19.11

10

99.79

36.5

10

5

99.91

19.11

10

9

Availability Throughput Latency

Q o S P a r am e t er s ( M e t a - S L A)

Meta-SLA Utility-based Prospect-based (1st)

Reputation

Prospect-based (2nd)

364.4

252

10

102.4243.5

234.00

9.5

319

309

10

243

234

9.5

Co st (M e ta -S L A)

Total-cost VM-cost

Meta-SLA Value Utility-based

Storage-cost

Prospect-based (1st)

Traffic -cost

Prospect-based (2nd)

Figure 5: Simulation results: aggregated QoS values of selected services and meta-SLA for the standard edition scenario.

sub-SLA expresses the functional and non-functionalrequirements related to the application components(UI, Computation, Storage). While it is possible tohave different functional needs such as type, size andnumber of requested infrastructure services for eachcomponent, the non-functional requirements of vari-ous components in different software editions are al-most the same.

5.2 Utility-based Matching Algorithm

The utility-based algorithm, which the proposed al-gorithm is compared to, uses a quasi-linear utility-function adopted from the multi-attribute auction the-ory (Asker and Cantillon, 2008) to calculate the userutility, taking the user payment willingness in focus.The utility for each composite service is calculated bysubtracting the total service usage costs (include VM,traffic, storage) from its monetized usage benefit. Theformer is calculated for each user by multiplying hisoverall score for the SLAs with his maximal paymentfor a perfect service. The overall SLA scores (a nor-malized value between 0 and 1), defined as the sumof the weighted single SLA parameter scores, expressthe overall user satisfaction for a certain service qual-ity. For the calculation of the SLA score, the algo-rithm uses so called fitting functions that map eachSLA metric value to a satisfaction level between 0 and1.

5.3 Theoretical Comparison

The key differences of the proposed algorithm, namedprospect-based, with the utility-based algorithm canbe summarized as follows.

(1) The two algorithms have a different perspec-tive on the cost. In our algorithm, the cost has a flexi-ble impact with a specified weight, similar to the othernon-functional parameters, while in the utility-basedalgorithm, the cost has a fixed influence with a pre-defined impact. (2) The weighting model of these

two algorithms are different. In the prospect-basedalgorithm, the weight of each non-functional param-eter is chosen within (0,1] independently of other pa-rameters. However, in the utility-based algorithm theweights are dependent to each other within (0,1] andthe sum of them should be 1. (3) The utility-basedalgorithm selects as the target a Composite Infras-tructure Service which the one offering the maximalutility value for the user. While, our algorithm se-lects the service that best satisfies both the meta-SLAand the sub-SLAs. In both algorithms, functional pa-rameters must be fulfilled and both aim to find thebest set of non-functional parameters. However, con-trary to the utility-based algorithm, our algorithm canalso support hard non-functional parameters that canbe treated as the same way as functional parameters.(4) The fitting functions used in the utility-based al-gorithm are quite similar to SSF used in our algo-rithm. However, our algorithm is more flexible asit is based on the weights, while the utility-based al-gorithm needs to define separated fitting function foreach QoS. Therefore, supporting more SLA parame-ters in our algorithm needs less effort. Furthermore,these fitting functions in utility-based algorithm areonly used to score the aggregated QoS based on theSLA for the Composite Infrastructure Service, whileour algorithm supports scoring each single infrastruc-ture service based on the sub-SLA as well as the com-posite service based on the meta-SLA using the SSF .

5.4 Experimental Results

In this section, the service selection results of bothalgorithms are analyzed based on several evaluationscenarios in which the inputs are as shown in Table4 and Table 5, described earlier. The scenarios inthe following sections have been designed in a wayto highlight different aspects of our work.


730

99.97

3

99.97

2.73

Availability Response time

Q o S p a r am e te r s ( S u b - SL A f o r U I )

meSubSLA_UI Prospect-based

6

8

Q o S p a r am e te r s ( S u b - SL A f o r S t o r a g e)

Reputation

SubSLA_Storage Prospect-based

1535

99.87

11.28

100

6.33

2008.8

98.00

5

20

3

Total Cost Availability Throughput Latency Reputation

Q o S p a r am e te r s a n d C o s t ( M e t a - S L A)

Meta-SLA Prospect-based

Figure 7: Simulation results: QoS values of selected services, meta-SLA and sub-SLAs for the professional edition scenario.

99.8

15

40

3

18086.4

99.44

23.13

16.429

1673

99.91

19.11

10

9

1317.76

Availability Throughput Latency Total-cost

Q oS par ame t e r s an d C ost (M e t a - SLA )

Meta-SLA Utility-based

Reputation Prospect-based

violation!

Figure 6: Simulation results: aggregated QoS values of se-lected services and meta-SLA for the enterprise edition sce-nario.

5.4.1 Impact of Cost

At the first scenario, minimizing the cost is the maingoal of the user and the composite service QoS ismore important than the quality of individual services.To simulate this scenario, we assigned the weights asWsubSLA = 0:1 and WmetaSLA = 0:9, to dominate the in-fluence of meta-SLA on sub-SLAs in service selec-tion. Furthermore, in meta-SLA, WCost = 0:8 and forother non-functional parameters WNF = 0:25 to makecost as the most effective factor on service selection.

Figure 5 depicts the results of aggregated QoS val-ues of chosen services for the both algorithms. Inthis scenario, the selected services (the 1st ranked orthe 2nd rank) of the prospect-based algorithm are theexactly the same as the selected result of the utility-based algorithm, and both algorithms select the ser-vices of the same Cloud provider data center. For thisreason, the aggregated values of latency are 10ms.Furthermore, both algorithms are successful in sat-isfying the requested non-functional parameters ofmeta-SLA including cost (cost of VM, Storage andTraffic), as illustrated in Figure 5.

The results of the first scenario, demonstrate thetendency of both algorithms to select services fromthe same Cloud provider data center, if this does notlead to SLA violations. The first ranked services of

the prospect-based algorithm were chosen from Ama-zonEC27 (Europe8) while the utility-based algorithmand the second ranked of our algorithm selected allservices from the Voxel9 (Europe). This is reason-able, since the data traffic is free of charge and la-tency is negligible when all the services are located atthe same data center. Note that the experiments withthe professional and enterprise editions achieved sim-ilar results to the experiments with the standard edi-tion and will, therefore, not be herewith discussed indetail.

5.4.2 Impact of Meta-SLA

At the second scenario, we evaluate the proposed al-gorithm in a condition in which the importance ofanother QoS parameter, availability, for the user isequal to cost and higher than the ones of other non-functional parameters. We achieve this by setting theweight of availability more than the weights of othermeta-SLA parameters (incl. throughput, latency, rep-utation) in the enterprise software edition scenario.

Moreover, in the utility-based algorithm, we setthe weight equal to 0.5 for the availability and 0.25 forboth the latency and throughput. By applying thesesettings, we gain the results as depicted in Figure 6.Our algorithm chose AmazonEC2 (Europe), while theutility-based algorithm selected Voxel (Europe) for allrequested infrastructure services. The graphs in thisfigure show that our algorithm performs well by firstnot violating any SLA parameters and then by giv-ing priority to the parameters that are more impor-tant for the user (cost and availability) and finally try-ing to choose the services with suitable quality val-ues (closer to the user request) for other parameters.This can justify the idea of applying prospect theoryin the service selection, in which the best score is fora service that more closely satisfy the requested SLA

7http://aws.amazon.com/ec2/8It means data center is located in Europe.9http://www.voxel.net


731

parameters from the higher priority ones to the lowerones, contrary to the services that have the best qual-ity. The throughout graph of this figure demonstratesthat the utility-based algorithm tries to maximize thevalues of throughput, while the requested availabilityis violated. This scenario shows that the utility-basedalgorithm focuses more on keeping the cost underthe requested budget as the cost impact is not config-urable in the algorithm. While in the prospect-basedalgorithm by assigning suitable weights and acceptedboundaries for each SLA parameters, we can obtainthe ranking score that maximizes the user’s satisfac-tion.

5.4.3 Impact of Sub-SLA

At the last scenario, we consider that the SaaSprovider has specific non-functional requirementsfor some of its components. In the other word,the CAD-aaS provider wants to provide a profes-sional software edition in which, for the security rea-sons, it is required to use Cloud storage service thatstores the CAD models only in Europe, and has agood reputation (location = EU and reputation =6 in subLSAStorge). Furthermore, the CAD-aaSprovider wants to keep the response-time of its de-ployed UI under 3s, and makes it highly available(responseTime = 3s and availability = 99:98% insubSLAUI) with high importance weights (0.75) forthe professional software edition. we consider the im-portance weight as default (W=0.5) for other meta-SLa parameters.

The graphs depicted in Figure 7 depict the com-parison results between the QoS parameters requestedin meta-SLA and sub-SLAs, and the QoS values ofthe selected services (Rackspace10 for UI and Stor-age, Citycloud11 for Computation both in Europe) bythe prospect-based algorithm. As shown, the algo-rithm found a suitable set of services that satisfies notonly the requested meta-SLA for the composite ser-vice, but also all the requested sub-SLAs’ parametershave been satisfied.

5.4.4 Discussion

From the first scenario, we conclude that although theimpact of cost in the prospect-based algorithm is not apredetermined like the utility-based algorithm, by as-signing proportional weights to the service selectioncriteria, the proposed algorithm can behave the sameas a utility-based method which is widely accepted

10http://www.rackspace.com11https://www.citycloud.com

Cloud service selection from the efficiency point ofview.

The second scenario, in which another QoS pa-rameter is as important as cost for the user, shows thatthe prospect-based algorithm outperforms the utility-based algorithm. It selects more suitable serviceswhich first do not violate any requested meta-SLAparameters, and then chooses the services with betterquality values for the parameters that are more impor-tant for the user.

The third scenario highlights one of the main fea-tures of the proposed algorithm. The proposed al-gorithm not only tries to find an optimum compos-ite service with accepted aggregated QoS values tosatisfy the meta-SLA, but also consider the sub-SLAsatisfaction for each included service. While, exist-ing service selection algorithms that support compos-ite service selection, only focus on finding the set ofservices which satisfies the aggregated QoS parame-ters and neglect to view the included services in thiscomposite service separately. We can cover this needeasily by the sub-SLA concept, as represented in thethird scenario.

To sum up, according to the experimental results,when we are dealing with the quality parameters of aservice as a whole, any algorithms may be adequateto find the most suitable services among the candi-dates. The main problem here is that in this situa-tion, services provided by the same provider are pre-ferred. This diminishes the benefits of a multi-cloudenvironment. Our algorithm comes into play whenusers want to take the advantage of being able to com-bine services offered by different providers availablein a multi-cloud. By introducing the sub-SLA con-cept, now the user can defines more details regard-ing the individual services inside a composite service.This, as can be seen in the results, leads to a betteruser satisfaction. It is worth mentioning that support-ing parameters such as reputation is significant in ourwork.

However, as also hinted in (Yau and Yin, 2011)regarding to the application of prospect theory in webservice domain, although this theory has been widelyaccepted and used in economics, the evaluation of itseffectiveness and accuracy in regarding to its influ-ence on Cloud service ranking and selection needsmore studies and investigation.

6 CONCLUSION

Diversity of services in Multi-Cloud is encouragingmore SaaS providers to move towards using the in-frastructures provided by the IaaS providers instead


732

of running their own private data centers. However,there are still some issues that impede this evolu-tionary process such as the lack of an efficient ser-vice selection and SLA management. In this pa-per, we introduced HS4MC approach an HierarchicalSLA-based Service Selection for Multi-Cloud Envi-ronments. This approach contains two phases: SLAConstruction and Service Selection. In the former,we investigated the SLA hierarchy issue and tack-led it by proposing the sub-SLA and meta-SLA con-cepts. In the latter, we used a selection algorithmbased on prospect theory to score the infrastructureservices based on the given SLAs and the degree ofuser satisfaction. Our simulation-based evaluationand a comparison with a utility-based matching algo-rithm showed that our approach effectively selects aset of services for the composition that satisfy bothmeta-SLA and sub-SLA parameters. For this pur-pose, we implemented both algorithms and modeled arealistic simulation environment for a CAD softwareprovider scenario.

In our future work, we will investigate more onthe construction of InterCloud-SLAs by utilizing themodel driven principles. We will also focus on map-ping these SLAs to the selected cloud infrastructureservices at runtime. Finally, we will explore the SLAviolation detection issue and develop a penalty modelin case of violations as the next steps in the Multi-Cloud SLA management.

ACKNOWLEDGEMENTS

Soodeh Farokhi is financed through the doctoral col-lege ”Adaptive Distributed Systems”, Holistic En-ergy Efficient Management of Hybrid Clouds (HA-LEY) project of the Vienna University of Technology,the Austrian National Research Network S11403 andS11405 (RiSE) of the Austrian Science Fund (FWF),and by the Vienna Science and Technology Fund(WWTF) grant PROSEED. Foued Jrad’s research stayabroad at the Vienna University of Technology wasfunded by the Karlsruhe House of Young Scientists(KHYS).

REFERENCES

Asker, J. and Cantillon, E. (2008). Properties of scoringauctions. The RAND Journal of Economics, 39(1):69–85.

Bellavista, P., Corradi, A., Foschini, L., and Pernafini,A. (2013). Automated provisioning of saas applica-tions over iaas-based cloud systems. In Advances in

Service-Oriented and Cloud Computing, pages 94–105. Springer.

Breskovic, I., Altmann, J., and Brandic, I. (2013). Creatingstandardized products for electronic markets. FutureGeneration Computer Systems, 29(4):1000–1011.

Clark, K., Warnier, M., and Brazier, F. M. (2013). Auto-mated non-repudiable cloud resource allocation. InCloud Computing and Services Science, pages 168–182. Springer.

Dastjerdi, V. (2013). QoS-aware and semantic-based ser-vice coordination for multi-Cloud environments. PhDthesis, University of Melbourne.

Emeakaroha, V. C., Brandic, I., Maurer, M., and Breskovic,I. (2011). Sla-aware application deployment and re-source allocation in clouds. In Computer Software andApplications Conference Workshops (COMPSACW),2011 IEEE 35th Annual, pages 298–303. IEEE.

Itani, W., Ghali, C., Kayssi, A. I., and Chehab, A. (2011).Accountable reputation ranking schemes for serviceproviders in cloud computing. In CLOSER, pages 49–55.

Jrad, F., Tao, J., Knapper, R., Flath, C. M., and Streit, A.(2013). A utility-based approach for customised cloudservice selection. Int. J. Computational Science andEngineering.

Kahneman, D. and Tversky, A. (1979). Prospect theory: Ananalysis of decision under risk. Econometrica: Jour-nal of the Econometric Society, pages 263–291.

Lee, Y. C., Wang, C., Zomaya, A. Y., and Zhou, B. B.(2010). Profit-driven service request scheduling inclouds. In Proceedings of the 2010 10th IEEE/ACMInternational Conference on Cluster, Cloud and GridComputing, pages 15–24. IEEE Computer Society.

Moghaddam, M. and Davis, J. G. (2014). Service selectionin web service composition: A comparative reviewof existing approaches. In Web Services Foundations,pages 321–346. Springer.

Ouelhadj, D., Garibaldi, J., MacLaren, J., Sakellariou, R.,and Krishnakumar, K. (2005). A multi-agent infras-tructure and a service level agreement negotiation pro-tocol for robust scheduling in grid computing. InAdvances in Grid Computing-EGC 2005, pages 651–660. Springer.

Petcu, D. (2013). Multi-cloud: expectations and currentapproaches. In Proceedings of the 2013 internationalworkshop on Multi-cloud applications and federatedclouds, pages 1–6. ACM.

Redl, C., Breskovic, I., Brandic, I., and Dustdar, S. (2012).Automatic sla matching and provider selection in gridand cloud computing markets. In Proceedings of the2012 ACM/IEEE 13th International Conference onGrid Computing, pages 85–94. IEEE Computer So-ciety.

Son, S., Jung, G., and Jun, S. C. (2013). An sla-basedcloud computing that facilitates resource allocation inthe distributed data centers of a cloud provider. TheJournal of Supercomputing, pages 1–32.

Wu, L., Garg, S. K., and Buyya, R. (2011). Sla-based re-source allocation for software as a service provider


733

(saas) in cloud computing environments. In Clus-ter, Cloud and Grid Computing (CCGrid), 2011 11thIEEE/ACM International Symposium on, pages 195–204. IEEE.

Wu, L., Kumar Garg, S., Versteeg, S., and Buyya, R. (2013).Sla-based resource provisioning for hosted softwareas a service applications in cloud computing environ-ments. Journal of IEEE Transactions on ServicesComputing.

Yau, S. S. and Yin, Y. (2011). Qos-based service rankingand selection for service-based systems. In ServicesComputing (SCC), 2011 IEEE International Confer-ence on, pages 56–63. IEEE.

Zeng, L., Benatallah, B., Dumas, M., Kalagnanam, J., andSheng, Q. Z. (2003). Quality driven web servicescomposition. In Proceedings of the 12th interna-tional conference on World Wide Web, pages 411–421.ACM.


734

hs4mc hierarchical sla-based service selection for multi ... 2014/closer... · hs4mc hierarchical...

Documents