SLA-based Resource Allocation for Software as a Service Provider (SaaS) in Cloud Computing Environments

Transcription

1 2 th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing SLA-based Resoure Alloation for Software as a Servie Provider (SaaS) in Cloud Computing Environments Linlin Wu, Saurabh Kumar Garg and Rajkumar Buyya Cloud Computing and Distributed Systems (CLOUDS) Laboratory Department of Computer Siene and Software Engineering The University of Melbourne, Australia {linwu,saurabh, raj}@sse.unimelb.edu.a Abstrat Cloud omputing has been onsidered as a solution for solving enterprise appliation distribution and onfiguration hallenges in the traditional software sales model. Migrating from traditional software to Cloud enables on-going revenue for software providers. However, in order to deliver hosted servies to ustomers, SaaS ompanies have to either maintain their own hardware or rent it from infrastruture providers. This requirement means that SaaS providers will inur extra osts. In order to minimize the ost of resoures, it is also important to satisfy a minimum servie level to ustomers. Therefore, this paper proposes resoure alloation algorithms for SaaS providers who want to minimize infrastruture ost and SLA violations. Our proposed algorithms are designed in a way to ensure that Saas providers are able to manage the dynami hange of ustomers, mapping ustomer requests to infrastruture level parameters and handling heterogeneity of Virtual Mahines. We take into aount the ustomers Quality of Servie parameters suh as response time, and infrastruture level parameters suh as servie initiation time. This paper also presents an extensive evaluation study to analyze and demonstrate that our proposed algorithms minimize the SaaS provider s ost and the number of SLA violations in a dynami resoure sharing Cloud environment. Keywords- Cloud omputing; Servie Level Agreement (SLA); Resoure Alloation; Sheduling; Software as a Servie. flexibility, salability and ost-effetiveness, it has been inreasingly adopted for distributing many enterprise software systems, suh as banking, e-ommere business software [7][9]. SaaS providers suh as Computer Assoiates (CA) [6] derive their profits from the margin between the operational ost of infrastruture and the revenue generated from ustomers. Therefore, SaaS providers are looking into solutions that minimize the overall infrastruture ost without adversely affeting the ustomers. Hene, the fous of this paper is on exploring poliies to minimize the required infrastruture to meet ustomer demand in the ontext of SaaS providers offering hosted software servies. Customers SaaS Provider PaaS IaaS Appliation Layer Platform Layer. Request Software Servie Software Servie Mapping Infrastruture Layer Data Centre 4. Provide Aess Information 2. Deision Software Servie Sheduling 3. Alloate resoure for ustomer requests I. INTRODUCTION Traditionally the shrink-wrapped software sales model dominated the market. This model requires ustomers are required to purhase per petual or subsription-based liense and manage the deployment themselves, inluding transitioning between different versions. Hene, ustomers need tehnial expertise and high initial investment for buying software. They also need to pay for upgrades as annual maintenane fee. With the emergene of Software as a Servie (SaaS), appliations are moving away from PCbased or ownership-based programs to web delivered hosted servies [9]. The software servies are provisioned on a pay-as-you-go basis to overome the limitation of the traditional software sales model. Using the SaaS model, providers gain steady, on-going revenue from their ustomers. In exhange for the on-going harges, the ustomers get the benefit of ontinuously maintained software. Hene, there is no additional liense fee for new versions and the omplexity of transitioning to new releases is managed by SaaS providers. Due to the SaaS model s Figure. A system model of a SaaS layer struture A SaaS model for serving ustomers in Cloud is shown in Fig.. A ustomer sends requests for utilizing enterprise software servies offered by a SaaS provider, who uses three layers, namely appliation layer, platform layer and infrastruture layer, to satisfy the ustomer s request. The appliation layer manages all appliation servies that are offered to ustomers by the SaaS provider. The platform layer inludes mapping and sheduling poliies for translating the ustomer s Quality of Servie (QoS) requirements to infrastruture level parameters and alloating Virtual Mahines (VMs) to serve their requests. The infrastruture layer ontrols the atual initiation and removal of VMs. The VMs an be leased from IaaS providers suh as Amazon EC2 or private virtualized lusters owned by the SaaS provider. In both ases, the minimization of the number of VMs will deliver savings. The savings are greater when SaaS providers use the third party IaaS providers sine no apital expenditure is required / $26. 2 IEEE DOI.9/CCGrid

2 Currently, SaaS providers suh as Compiere ERP provide an individual VM for eah ustomer [7] to maintain servie level requirements in terms of response time and apaity. However, this auses wastage of hardware resoures whih results in high infrastruture ost sine ustomers may not use omplete VM apaity whih is reserved to serve their requests. A multi-tenany approah an redue the needed infrastruture, but are must be taken in providing aess to resoures so that Servie Level Agreements (SLAs) are not violated. The urrent works in Cloud omputing [3][][2] are foused mostly on maximizing the profit of IaaS providers, but works related to the SaaS provider onsidering SLAs are still in their infany. Many works do not onsider the ustomer driven management, where resoures have to be dynamially rearranged based on ustomers demands. Thus, in this paper, we examine the resoure alloation strategies, whih allow a ost effetive usage of resoures in Clouds to satisfy dynamially hanging ustomer demands in line with SLAs. Therefore, in order to ahieve the SaaS provider s objetive to maximize profit and ustomer satisfation levels, our work proposes ost effetive mapping and sheduling poliies whih minimize ost by optimizing the resoure alloation within a VM. These poliies also take into aount QoS parameters, and infrastruture heterogeneity regarding multiple types of VMs and various servie initiation times. To satisfy ustomer s request in order to enlarge market share and minimize ost, the following questions have to be addressed: How to manage the dynami hange of ustomer requests? (suh as upgrade from Professional to Enterprise produt, add more user aounts for the same produt) How to map ustomer requirements to infrastruture level parameters? How to deal with the infrastruture level heterogeneity? The key ontributions of this paper are as follows: It defines SLA with ustomers based on QoS parameters. It desribes the mapping strategy by interpreting ustomer request requirements to infrastruture level parameters. It designs and implements sheduling mehanisms to maximize an SaaS provider s profit by reduing the infrastruture ost and minimizing SLA violations. The sheduling mehanism determines where and whih type of VM has to be initiated by inorporating the heterogeneity of VMs in terms of their prie, dynami servie initiation time, and data transfer time. In addition, it manages to redue inurred penalties for handling dynami servie demands when ustomers are sharing resoures. This paper also presents a performane analysis of the proposed algorithms based on the ustomer s perspetive: (i) arrival rate, (ii) proportion of upgrade requests; from SaaS providers perspetive: (i) servie initiation time, (ii) penalty rate. The experimental results show that the proposed algorithms provide better solutions in terms of total profit and number of VMs when ompared with base algorithm in most of the senarios. The rest of the paper is organized as follows. In Setion II, we disuss prior works related to SLA-based and profit driven resoure alloation in Cloud omputing ontexts. We also identify how our work differs from related works. Setion III presents the detailed senario and outlines the SLA supporting QoS parameters. Setion IV desribes a referene and two proposed algorithms, whih are ProfminVio, ProfminVmMaxAvaiSpae and ProfminVmMinAvaiSpae. Setion V firstly presents the experimental methodology inluding test bed and evaluation metris; seondly, disusses the overall omparison of the performane evaluation results; thirdly, ompares the algorithms by providing insights on when eah algorithm should be used. Finally, Setion VI onludes the paper by summarizing the omparison results and future work proposals. II. RELATED WORK Researh on market driven resoure alloation was started in early 8s [8][5]. Most of the market-based resoure alloation methods are either non-priing-based [] or designed for fixed number of resoures, suh as FirstPrie [3] and FirstProfit [6]. Our work is related to user driven SLA-based profit maximization resoure alloation for SaaS providers. Reig G. et al [] ontributed on minimizing the resoure onsumption for serving requests and exeuting them before its deadline with a predition system. Their predition system enables the sheduling poliies to disard the servie of a request if the available resoure apability is not able to omplete the request before its deadline. However, in our work, we onsider the enterprise appliations whih are different from ompute and sientifi appliations. Fu Y. et al [2] proposed an SLA-based dynami sheduling algorithm (Squeeze) of distributed resoures for streaming. Moreover, Yarmolenko V. et al [22] evaluated various SLA-based sheduling heuristis on parallel omputing resoures using resoure (number of CPU nodes) utilization and inome as evaluation metris. Nevertheless, our work fouses on sheduling enterprise appliations on VMs in Cloud omputing environments. (The minimum unit of resoures in our work is the number of VMs). Popovii et al. [6] mainly onsidered QoS parameters on the resoure provider s side suh as prie and offered load, but did not fous on the user side. However, our proposed work differs on QoS parameters from both the ustomer s and the SaaS provider s point of view and fouses on user driven senarios. Lee et al. [2] investigated the profit driven servie request sheduling for workflow. In ontrast, our work a) fouses on SLA driven QoS parameters on both user and provider sides, and b) solves the hallenge of dynami hanging ustomer requests to gain profit and improve reputation. 96

3 In the ontext of the resoure alloation algorithms for enterprise appliations, Song et al. [8] presented the geneti algorithms in virtualized environments. However, the geneti algorithms generally require a long exeution time. The long exeution time inreases the probability of SLA violation in the Cloud omputing environments, where ustomers need to be served immediately. In summary, this paper is unique in the following aspets: It manages the ustomer satisfation level based on ustomer QoS requirements in minimizing the SLA violation and ost to inrease the revenue, whih is absent from most previous works in Cloud omputing environments. The utility funtion is time-varying by onsidering dynami VM deployment time (aka initiation time). It adapts to dynami resoure pools and onsistently evaluates the ost of adding a new instane or removing instanes, while most previous work deal with fixed size of the resoure pools. III. SYSTEM MODEL We onsider the ustomers requests for the enterprise software servies from a SaaS provider by agreeing to the pre-defined SLA lauses and submitting their QoS parameters. Customers an dynamially hange their requirements and usage of the hosted software servies. The SaaS provider an use their own infrastruture or outsoured resoures from publi IaaS providers. For instane, Salefore.om provides CRM software as a servie using its own infrastruture, and Fore.om offers this software using third party infrastruture [5]. The SaaS provider s objetive is to shedule a request suh that its profit is maximized while the ustomers (QoS) requirements are assured. The platform layer of a SaaS provider uses mapping and sheduling mehanisms to interpret and analyze the ustomers QoS parameters, and alloates respetively. In this setion, we explain the detailed system model from both the ustomers and the SaaS providers perspetive and also desribe the related mathematial models. A. Ators The ators involved in our system model are desribed below along with their objetives, ativities and onstraints. ) SaaS Providers SaaS providers lease enterprise software as hosted servies to ustomers. They are interested in maximizing profit and ensuring QoS for ustomers to enhane their reputation in the marketplae. In our ontext, an example of the business proess between a SaaS provider and a ustomer is where a servie provider (SaaS X) offers CRM or ERP software pakages, whih are offered as three types of produts (for example, Standards, Professional and Enterprise) and aounts (for example, Group, Team and Department). When a ustomer (Company X) submits its first time rent request with produt type (Standards), aount type (Group), and the required number of aounts (m), the provider will alloate resoures to serve this ustomer. At anytime, Company X may require an upgrade in the servie by adding more aounts or software editions. Customers an request an upgrade of servies dynamially at any time in pratie. Thus a SaaS provider has to handle these requests intelligently in line with the requirements as set out in the SLA. From a SaaS provider s point of view, there is a legal ontrat-sla with any ustomer and if any party violates SLA terms, the defaulter has to pay for the penalty aording to the lauses defined in the SLA. The SLA properties inlude SaaS provider pre-defined parameters and the ustomer speified QoS parameters. The properties defined in the SLA are as follows: Request Type (reqtype): It defines the ustomer request type, whih is fist time rent or upgrade servie. First time rent means the ustomer is the ustomer who is renting a new servie from this SaaS provider. Upgrade servie inludes two types of upgrade, whih are add aount and upgrade produt. Produt Type (protype): The software produt offered to ustomers. For example, SaaS X offers Standard, Professional, and Enterprise produt. The Standard produt inludes Order and Sales funtions. The Professional ontains all funtions of Standard plus Aounting funtion. The Enterprise inludes all features of Professional plus Report funtions. Aount Type (atype): It onstrains the maximum number of aounts a ustomer an reate. For example, SaaS X offers three types of aount: Group, Team, and Department, whih allows eah ustomer to reate up to m, 2m and 5m number of aounts respetively. Contrat Length (onlen): How long the software servie is legally available for a ustomer to use (minimum is one month). Number of Aounts (anum): The atual number of aounts that a ustomer wants to reate. (Must be the maximum number of aounts for partiular aount type). For example, a ustomer Company X wants to rent Standard software and Group aount type, then it an request [, m] number of aounts. Number of Reords (renum): The maximum number of reords a ustomer is able to reate for eah aount during the transation and this will impat the data transfer time during the servie upgrade. (The value of this parameter is predefined in SLA). Response Time (resptime): It represents the elapsed time between the end of a demand on a software servie and the beginning of a servie. Violation ours when atual elapsed time takes longer than pre-defined response time in SLA. We onsider three types of response time: (i) response time for the first time renting of the servie - resptime(ftr), (ii) response time for adding new 97

4 aounts - resptime(upsev,adda) and (iii) response time for upgrading the produt - resptime(upsev,uppro). (The value of eah type of response time is different and predefined in SLA). The platform layer (Fig. ) of a SaaS provider uses VM images to reate instanes aording to the mapping deision. Therefore, it is important to identify the following properties for the resoure alloation mehanisms to assure the SLA is adequately drafted: VM types (l): How many types of VM an be used and what are they? For example, there are three types of VM, whih are large, medium and small. The apaity of large VM equals to two medium VMs or four small VMs. Servie Initiation Time (initimesev): How long it takes to initiate a VM, whih is deployed with a type of software produt. VM Prie (PriVM): How muh it osts to a SaaS provider for using a VM to serve the ustomer request per time unit? It inludes the physial equipment, power, network and administration prie. Data Transfer Time (datatraft): How long does it take to transfer a Gigabyte data from one VM to another? Data Transfer Speed (datatrafspeed): It depends on the loation distane and the network performane. 2) Customers When a ustomer agrees with pre-defined SLA properties (suh as response time), a request for an enterprise appliation is sent to the SaaS provider s appliation layer with the ustomer s QoS requirements (inluding request type, produt type, aount type, ontrat length, and number of aounts). B. Mapping Strategy: Mapping of ustomer QoS requirements to resoures The way of interpreting ustomer requirements to infrastruture level parameters depends on the resoure apability. In our work, the infrastruture layer fouses on the VM level but not the host level. To be pratial, we use the same reord model as Salefore.om to restrit eah aount so as to reate the maximum N number of reords. An example of the mapping strategy between VM type, servie produt type, and the maximum and minimum number of aounts for eah aount type is desribed in Table I. TABLE I. VM Type Small Medium Large THE SUMMARY OF MAPPING BETWEEN RQUESTS AND RESOURCES Produt Aount Max Min Type Type Aount # Aount # Standard Group m Standard, Professional Standard Professional, Enterprise, Team. 2m m+ Department 5m 2m+ C. Mathematial Models ) Profit Model Let C be the number of ustomer requests and indiates ustomer request id. Let at a given time instane t, a ustomer submits a servie request to the SaaS Provider. The ustomer speifies a produt type, aount type, ontrat length (onlen), number of aounts after agreeing with the pre-defined SLA lauses (response time). After the agreement, based on the SLA, the SaaS provider will reserve the requested software servies whih are translated at the infrastruture level as VM apaity. Let I be the number of initiated VMs, and i indiates the VM id. Let L indiate the types of VMs, where for a partiular VM i with type l (VM il ) has PriVM il prie. Let initimesev il be the time taken for initiating servie using VM il. Let PriServ be the SaaS provider s final harge from ustomer per month, whih is subjet on the produt type, and aount type. Let P indiates all produt types. Let Cost il be the ost inurred to the SaaS provider by serving the ustomer with VM il. The Prof il indiates the profit for serving ustomer request using VM il. Then, the total profit C Pr = of il gained by the SaaS provider for serving total C number of ustomer requests is defined in Eq.() C C C C Pr of il = Pr iserv onlen Cost il = = = = where, i I, l L, C () For a ustomer request, the final servie prie PriServ is subjeted to the produt type and aount type. Let Cost il indiate the ost for serving request with VM il and it depends on the VM ost (VMCost il ) and penalty ost (PenalytCost il. ). il il Cost = VMCost + PenaltyCost where, i I, l L, C (2) The VM ost depends on the VM type l, the prie of VM i with type l (PriVM il ), the servie initiation Time (initimesev il ) and servie length (or ontrat length onlen) of ustomer request. Eq. (3) defines the VM Cost. il il ( initimesev onlen ) VMCost = Pr ivm il il where, i I, l L, C (3) The SLA violation penalty (Penalty) model is similar to other related works [][3][4] and is modeled as a Linear funtion. In Eq. (4), β is the penalty rate and DT is delay time. Penalty = α + β DT (4) The penalty funtion penalizes the servie provider by reduing the utility (profit). Aording to the penalty model, PenaltyCostil = α + β ( reqtype) delaytimeil ( reqtype) where i I, l L, C (5) 98

5 The penalty ost depends on the penalty delay time delaytime il, penalty rate (β) and a onstant number (α). The delay time and rate are subjeted to the request type. The delay time is the time variation between the response time speified in SLA and the atual time taken for ustomers to wait for the servie response. TABLE II. Table Head SLA predefined response time Atual Time delaytime il = THE SUMMARY OF PENALTY DELAY TIME ACCORDING TO REQUEST TYPES First Time Rent resptime (ftr) Servie initiation time(init imesev) Add aount resptime(upsev, adda) Upgrade Servie Servie initiation time (initimesev) Data transfer time(datatraft) Upgrade produt resptime(upsev, uppro) Servie initiation time(initimesev) Data transfer time(datatraft) There are three situations in whih penalty delay an our (Table II). If the request type is first time rent, the delay (violation) an our due to long servie initiation time. If the request type is upgrade servie, the delay may be aused in adding aounts whih may lead to servie initiation time and data transfer time (if there is available initiated VMs), or aused by upgrade servie produt type whih depends on servie initiation and data transfer time for the total number of reords reated by previous request from the same ompany. The servie initiation time varies subjeted to the physial mahine s apability. The total data transfer time depends on the reords data reated by previous request of the same ompany. More speifi, number of aount ' reated by previous request - ( anum ), number of ' reords reated per aount ( renum ), the total reord N size ( resize ' ) (GB) and data transfer time per GB n= initimesev resptime( ftr) where, reqtype is first time rent (6) N initimesev + datatraft n = resptime ( upsev where, reqtype is upgrade servie (7) ( datatranft ). N indiates the total number of reords and n is the reord id. N ' ' N n= n= datatraft= anum renum resize ' datatraft where n N, ' C (8) IV. ALOGORITHM The main objetive of our work is to maximize the profit for a SaaS provider by minimizing the ost of VMs using effetive platform layer resoure alloation strategies. As noted earlier, the urrent SaaS providers suh as Compiere ) ERP provide an individual VM for eah ustomer [7] to maintain servie level requirements in terms of response time and apaity. We implemented this senario as a base algorithm by initiating a new VM for eah individual ompany in order to minimize the SLA violation (ProfminVio). To optimize the profit further, we propose two SLA-based profit maximization algorithms. A. Base Algorithm: Maximizing the profit by minimizing the number of SLA violations (ProfminVio) A SaaS provider an minimize SLA violations by serving eah individual ompany with a new VM involving the two main request types: a) first time rent and b) upgrade servie. The algorithm first heks the request type, if the request type is first time rent servie then it finds the most suitable VM type l by using mapping strategy desribed in Table I, and afterwards alulates and reords the profit for initiating a new VM using Eq. () and (2). Otherwise if the request type is upgrade, then hek whih type of upgrade is requesting. If upgrade type is add aount, then the ompany s permissions are updated by allowing aess to more users on VM i whih is serving this ompany. If the upgrade type is upgrade produt, then first it finds the most suitable VM type l (Table I) and assigns request to it, then alulates and reord the profits. This algorithm redues the number of violations by using a new VM for eah ompany to guarantee the response time. However, it is ostly beause a large number of VMs are initiated. B. Proposed Algorithms We propose the following two algorithms: Maximizing the profit by minimizing the ost by reusing VMs, whih have maximum available spae (ProfminVmMaxAvaiSpae). Maximizing the profit by minimizing the ost by reusing VMs, whih have minimum available spae (ProfminVmMinAvaiSpae). ) Algorithm : ProfminVmMaxAvaiSpae A SaaS provider an maximize the profit by minimizing the resoure ost, whih depends on the number and type of initiated VMs. Therefore, this algorithm is designed to minimize the number of VMs by utilizing already initiated VMs. Algorithm desribes the ProfminVmMaxAvaiSpae algorithm, whih involves two main request types: a) first time rent and b) upgrade servie. Let the request of a ustomer inludes request type (reqtype), produt type (protype), aount type (atype), number of aounts (anum). The algorithm heks the request type, if the request type is first time rent then it finds the VM i with type l (VM il ) that mathes to the servie request parameters using mapping table similar to Table I. Then, it heks whether there is already initiated VM il and deployed with same type of produt as ustomer requested. If there is an initiated VM il where produt protype has been deployed as ustomer requested, then the algorithm heks whether this 99

6 VM il has enough spae to plae the request of ustomer aording to his/her requested number of aounts (anum) and the available spae on this VM. If there are more than one VM il with enough available spae to plae the request, then the request is assigned to the mahine with maximum available spae (Worst-fit manner) as illustrated in Fig. 2. (The gray spae indiates unavailable spae, x axis indiates the id of VM with same type and deployed with same type of produt as ustomer requested; y axis indiates number of aounts a VM an hold). If there is no initiated VM with type l, then hek the next type of VM - VM i(l+) whih is deployed with the same software produt type as request speified, repeat step (2 to 3) Figure 2. MaxAvaiSpae Strategy If the request type is upgrade, then the type of upgrade is heked. If upgrade type is add aount, then it first heks VM i, whih has plaed the previous request from the same ompany. If VM i is not apable to plae new request without exeeding the number of aount limitation, then the suitable type l of VM is found that has the maximum available apaity to plae request. Then move the previous data from VM i to new VM and release the spae oupied by old request from VM i. On the other hand, if upgrade to more advaned produt edition, the new request is plaed to the suitable VM by using the MaxAvaiSpae Strategy (Fig. 2) and then the ustomer data is migrated to new VM and release the spae oupied by old request from VM i. Algorithm. Pseudo-ode for ProfminVmMaxAvaiSpae Input request () with QoS parameters, VMi Output Boolean Funtions: First Time Rent (){ If (there is initiated VM i with type l mathes to the VM type requested by ) { 2 If (VM i deployed the same produt type as required) { 3 For eah initiated VM i with type l (VM il ){ 4 If (VM i has enough spae to plae ){ 5 put VM i into vmlist 6 } 7 } 8 Sort(vmList) aording to the available spae 9 Shedule to proess on VMmax, whih has maximum available spae } Else { 2 Initiate new VM with type l and deploy the produt type as request required 3 } 4 } 5 Else While (l+j<=l) loop { 6 If (there is initiated VM with next type l+j, where type l+j mathes to the VM type required by request ) { 7 Repeat from Step 2 to 3 8 j++ 9 } 2 } 2} Upgrade() { If (upgrade type is add aount ) { 2 get Id i and type l of VM, whih proessed the previous request from same ompany as 3 If ( VM i has enough spae to plae ){ 4 Shedule to proess on VM i. 5 } 6 Else { 7 Repeat step to 2 of First Time Rent() 8 Transfer data from old VM to new VM 9 Release spae in old VM } } 2 If (upgrade type is upgrade servie ){ 3 Repeat step 7 to 9 of Upgrade() 4 } 5} Figure 3. Example of disadvantage of MaxBlankSpae Strategy Figure 4. MaxAvaiSpae Stratege This algorithm minimizes the number of initiated VMs in order to optimize profit. Moreover, it minimizes number of violations aused by servie upgrade beause the request is sheduled to the VM, whih has the maximum available spae. In suh a way, it redues the penalty aused by upgrading servie. However, the disadvantage of this algorithm is that it an derease the profit in some ases; partiularly when the maximum available spae is oupied by small number of aounts and lead to requests (required large number of aounts) have to be served by a new VM. For example, in Fig. 3, VM 6 is a new VM initiated to serve request +, beause VM has been oupied by Request. 2

7 2) Algorithm 2 : ProfminVmMinAvaiSpae To overome the disadvantages of algorithm, we redue the spae wastage by using minimum available spae (MinAvaiSpae) Strategy (Fig. 4) instead of MaxAvaiSpae Strategy. When there are more than one VM with type l, deployed with the same produt type as ustomer request required, the VMs with enough available spae to serve are seleted. Then request is sheduled to the mahine with the minimum available spae (Best-fit manner) (Step 9). The rest of steps are the same as Algorithm. V. PERFORMANCE EVALUATION We present the performane results obtained from an extensive set of experiments. We have ompared our algorithms with the sheduling strategy used by urrent SaaS providers suh as Compiere, i.e., ProfminVio. In following setions, we first desribe our experiment methodology, followed by performane metris and detailed QoS parameters desription. In subsequent setions, we present the analysis of the results showing the impat of the ustomer-side QoS parameters - (i) request arrival rate, (ii) proportion of upgrade request; and SaaS providers side parameters - (i) servie initiation time, (ii) penalty rate. A. Experimental Methodology CloudSim [] is used to simulate the loud omputing environment that utilizes our proposed algorithms for resoure alloation. We observe the performane of the proposed algorithms from both ustomers and SaaS providers perspetives. From ustomers perspetive, we observe how many SLAs are violated. From SaaS providers perspetive, we observe how muh ost redued and how many VMs are initiated. Therefore, there are three performane measurement metris: total ost, number of initiated VMs, and perentage of SLA violations. All the parameters used in the simulation study are given in following setions. ) Customers Side We examine our algorithms with ustomers. From ustomer side, two parameters (arrival rate and number of ompany upgrade) are varied to evaluate their impat on the performane of our proposed algorithms. Sine there is no available workload speifying these parameters, we use normal distribution (standard deviation = (/2)x mean) to model all parameters, exept request arrival rate, whih follows Poisson distribution. Five different types of request arrival rate are used by varying the mean from 2 to 65 ustomers per seond. Five different sets of ompany request types are used by varying the mean from 2% to 8% of ompanies request upgrade servie in order to vary the portion of servie request type. 2) SaaS Providers Side The SaaS provider offers three types of software servie produts, and also three types of aount types (Table ). The ost per hour for using a VM (PriVM) in self-hosted VM follows the prie shema of Amazon EC2 [4], beause it is easier for SaaS provider to extend to publi Cloud and atual ost of self-hosted VMs is less expensive than the prie shema we are using. Resoure prie whih are used for modeling VMs are shown in Table III. The five different types of average servie initiation time are used in the experiment, and the mean servie initiation time varied from 5 minutes to 5 minutes. The mean of initiation time is alulated by onduting real experiments of 6 samples on Amazon EC2 [4] done for four days (2 week days and 2 weekend days) by deployed different edition of produts. The servie initiation time is varied using normal distribution. The penalty ost (the same as in Eq. 5) is modeled by Eq. (5) (6) (7). It depends on the request type, produt type and aount type. The mean of Penalty Rate (β) is varied from value 2 (very low) to value 5 (very high). TABLE III. THE SUMMARY OF VM PRICE VM Type Prie($/hour) Small.85 Medium.34 Large.68 B. Impat of QoS parameters We ompare our proposed algorithms by examining the impat of QoS parameters on the performane metris. All of results present the average obtained by 5 experiment runs. In eah experiment, we vary one parameter, and the rest parameters are given onstant mean value. The onstant mean values are: arrival rate= requests/se, other parameters, and penalty rate fator (r) =. In the following setions, we examine various experiments by varying both ustomer and SaaS provider side s SLA properties to analyze the impat of eah parameter. The mean response time whih is used to measure the violation equals 5 if the request type is first time rent, equals if the request type is upgrade produt and 3 when the request type is add aount. ) Impat of arrival rate variation To observe the impat of arrival rate in our algorithms, we vary the arrival rate fator, while keeping all other fators as the same. All experiments are onduted with ustomers requests. It an be seen from Fig. 5, in average the algorithm ProfminVMminAvaiSpae performs best to redue about 5% ost by using approximately only 6% number of VMs ompared with ProfminVio. As Fig. 5 shows, when the request arrival rate varies from large to very large, the number of SLA violations aused by our proposed algorithms inreases beause when large number of onurrent requests omes, delaying the response time for upgrading servies. Similar ost is generated by 2

8 ProfminVMminAvaiSpae and ProfminVMmaxAvaiSpae, and the former one is slightly better than the latter one, beause it osts less with similar number of VMs but generates less number of SLA violations. Therefore, during the variation of arrival rate, the ProfminVMminAvaiSpae perfoms best and optimizes the SLA violations in the ontext of resoure sharing, where it is impossible to avoid SLA violations. Total Cost ($) VM Initiated % SLA Violations very small small medium large very large Variation in Request Arrival Rate ProfminVio ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae (a). Total Cost very small small medium large very large Variation in Request Arrival Rate ProfminVio ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae (b). Number of initiated VMs very small medium large very large small Variation in Request Arrival Rate ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae (). Perentage of SLA Violations Figure 5. Impat of arrival rate variation 2) Impat of ompany upgrade frequeny variation To investigate the impat of different proportion of request types ( first time rent, upgrade servie ) by varying the ustomer upgrade number. As it an be seen from Fig. 6, during the variation of number of ustomer upgrade, the total ost of ProfminVio dereases beause it redues number of VMs (redued almost 49% on average) by utilizing the already initiated VMs for serving upgrades. With given redution in ost, our proposed algorithms ause very less number of violations as an be seen from the Fig. 6, where the overall perentage of SLA violations is less than 3%, and only when the ompany upgrades perentage is very high, the perentage of SLA violations is higher than 8%. When the variation in ompany upgrade frequeny is low (7% upgrade servie requests), ProfminVMmaxAvaiSpae auses more SLA violations due to the disadvantage of MaxAvaiSpae Strategy. In the ontrary, when the ompany upgrade frequeny is very high, ProfminVMminAvaiSpae violates more requests beause spae has been oupied by first time rent request types, leading to long upgrade time and even penalty delay. Therefore, when large numbers of requests are first time rent, the algorithm ProfminVMminAvaiSpae and ProfminVMminAvaiSpae ost less with less number of VMs, and with a bit more SLA violations ompare with ProfminVio (no violation). Total Cost ($) VM Initiated % SLA Violations Variation in Number of Upgrade Requests ProfminVio ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae (a). Total Cost Variation in Number of Upgrade Requests ProfminVio ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae (b). Number of Initiated VMs Variation in Number of Upgrade Requests ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae (). Perentage of SLA Violations Figure 6. Impat of number of upgrade requests 22

9 3) Impat of initiation time variation ) Impat of penalty rate variation 35 3 Total Cost ($) VM Cost ($) very short short medium long very long Variation in Servie Initiation Time Variation in Penalty Rate ProfminVio ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae ProfminVio ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae (a). Total Cost (a). VM Cost 9 VM Initiated Penalty Cost very short short medium long very long Variation in Servie Initiation Time Variation in Penalty Rate ProfminVio ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae ProfminVio ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae (b). Number of initiated VMs (b). Penalty Cost % SLA Violations very short short medium long very long % SLA Violations Variation in Servie Initiation Time Variation in Penalty Rate ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae ProfminVmMinAvaiSpae ProfMinVmMaxAvaiSpae (). Perentatge of SLA Violations Figure 7. Impat of initiation time variation The servie initiation time also inludes the VM initiation time for deploying software servie as requested. Fig. 7 shows how the variation in servie initiation time after aepting a ompany request on the SaaS provider s ost. When the initiation time varies from very short to very long, the total ost of all algorithms inreased slightly. The ProfminVio is impated more beause it initiated more VMs. The average SLA violation perentage of our algorithms is less than 3% When the initiation time is very short and very long, the algorithm ProfminVMminAvaiSpae and ProfminVMminAvaiSpae generate a similar number of violations, beause initiation time delay is the same for both of the algorithms. (). Perentage of SLA Violations Figure 8. Impat of penalty rate variation We investigate how penalty rate (β) impats our algorithms. It an be observed from Fig. 8 that ProfminVmMinAvaiSpae and ProfminVmMaxAvaiSpae are impated when varying the penalty rate fator beause they shedule ustomer requests with shared resoures. The penalty ost of algorithms inreases during variation of the penalty rate due to SLA violation inreases beause of resoure sharing between multiple ustomers. However, when the SLA violation is very low the maximum perentage is less than 2.5%. In onlusion, Fig. 8 a and b show that our algorithms minimize the ost although penalty ost is inreasing during penalty rate variation. VI. CONCLUSION AND FUTURE WORK In Cloud omputing environments, primarily three types of on-demand servies are available for ustomers i.e. Software as a Servie, Infrastruture as a Servie and 23

10 Platform as a Servie. This paper foused on sheduling ustomer requests for SaaS providers with the expliit aim of ost minimization with dynami demands handling. To ahieve this goal, we answered questions raised in the introdution setion by using mapping and sheduling mehanisms to deal with the ustomer side dynami demands and resoure level heterogeneity. Thus, we implemented three ost driven algorithms whih onsidered various QoS parameters (suh as arrival rate, servie initiation time and penalty rate) from both the ustomers and the SaaS providers perspetive. Simulation results show that on average, the ProfminVMminAvaiSpae algorithm optimized ost savings better when ompared to the other proposed algorithms. In building on the researh undertaken in this paper in the future, we will analyze ways to inrease the effiieny of the algorithms in terms of total profit and shall also onsider the SLA negotiation proess in Cloud omputing environments to improve ustomer satisfation levels. We would also like to add different types of servies and other priing strategies suh as spot priing to inrease the profit for servie providers. Moreover, investigating the knowledge based sheduling for maximizing a SaaS provider s profit to improve our algorithms time omplexity. Moreover, we will look into the penalty limitation by onsidering system failures. ACKNOWLEDGMENT We thank the anonymous reviewers, olleagues in Cloud Lab at the University of Melbourne and Mr. Bevan Mailman who helped us to improve the quality of this paper. REFERENCES [] C.S. Yeo, and R. Buyya, Servie level agreement based alloation of luster resoures: Handling penalty to enhane utility. In Proeedings of the 7th IEEE International Conferene on Cluster Computing (Cluster 25), Bostan, MA, USA. [2] Y.C. Lee, C. Wang, A.Y. Zomaya and B.B. Zhou, Profit-driven Servie Request Sheduling in Clouds. In Proeedings of the International Symposium on Cluster and Grid Computing, (CCGrid 2), Melbourne, Australia. [3] O. F. Rana, M. Warnier, T. B. Quillinan, F. Brazier, and D. Cojoarasu, Managing Violations in Servie level agreements. In proeedings of the 5th International Workshop on Grid Eonomis and Business Models (GenCon 28), Gran Canaris, Spain. [4] D.E. Irwin, and L.E. Grit, and J.S. Chase, Balaning Risk and Reward in a Market-based Task Servie. In Proeedings of the 3th International Symposium on High Performane Distributed Computing (HPDC 24), Honolulu, HI, USA. [5] Y. Yemini, Selfish optimization in omputer networks proessing. In Proeeding of the 2th IEEE Conferene on Deision and Control inluding the Symposium on Adaptive Proesses, San Diego, USA. [6] I. Popovii, and J. Wiles, Proitable servies in an unertain world. In Proeeding of the8th Conferene on Superomputing (SC 25), Seattle, WA. [7] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg, and I. Brandi, Cloud Computing and Emerging IT Platforms: Vision, Hype, and Reality for Delivering Computing as the 5th Utility, Future Generation Computer Systems, 25(6), (pp ), Elsevier Siene, Amsterdam, The Netherlands. [8] D. Parkhill, The hallenge of the omputer utility, 966, Addision- Wesley Eduational Publishers In., USA. [9] M. A. Vouk, Cloud Computing-Issues, Researh and Implementation. In Proeedings of 3th International Conferene on Information Tehnology Interfaes ( ITI 28), Dubrovnik, Croatia. [] J. Broberg, S. Venugopal, and R Buyya, Market-oriented Grids and Utility Computing: The state-of-the-art and future diretions, Journal of Grid Computing, 3(6), (pp ). [] Rodrigo N. Calheiros, Rajiv Ranjan, Anton Beloglazov, Cesar A. F. De Rose, and Rajkumar Buyya, CloudSim: A Toolkit for Modeling and Simulation of Cloud Computing Environments and Evaluation of Resoure Provisioning Algorithms, Software: Pratie and Experiene (SPE), Volume 4, Number, Pages: 23-5, ISSN: , Wiley Press, New York, USA, January, 2. [2] G Reig, J. Alonso,and J. Guitart, Deadline Contrained Predition of Job Resoure Requirments to Manage High-Level SLAs for SaaS Cloud Providers. Teh. Rep. UPC-DAC-RR, Dept. d Arquitetura de Computadors, University Polit enia de Catalunya, Barelona, Spain. [3] S. K. Garg, R. Buyya, and H. J. Siegel, Time and Cost Trade-off Management for Sheduling Parallel Appliations on Utility Grids, Future Generation Computer Systems,26(8), (pp ). [4] C. Vehiola, X.C. Chu, M. Mattess, and R. Buyya, Aneka Integration of Private and Publi Clouds, Cloud Computing Priniples and Paradigms, Willy, USA, 2 [5] Salefore.om, Retrived on 6th De 2: [6] Computer Assoiates Pty Ltd. Retrived on 6th De 2: [7] Compiere ERP on Cloud, Retrieved on 6th De 2: [8] Y. Song, Y. Li, H. Wang, Y. Zhang, B. Feng, H. Zang, Y. Sun, A Servie-Oriented Priority-Based Resoure Sheduling Sheme for Virtualized Utility Computing, High Performane Computing-HiPC 28. [9] T. Gad, Why Traditional Enterprise Software Sales Fail. July 2, Retrieved on 6th De 2: [2] Y. Fu, A. Vahdat, SLA Based Distributed Resoure Alloation for Streaming Hosting Systems, [2] V. Yarmolenko and R. Sakellariou. An Evaluation of Heuristis for SLA Based Parallel Job Sheduling. In Proeddings of the 3rd High Performane Grid Computing Workshop (in onjuntion with IPDPS 26). Rhodes, Greee. 24