An Optimal Model for Priority based Service Scheduling Policy for Cloud Computing Environment

Transcription

1 An Optmal Model for Prorty based Servce Schedulng Polcy for Cloud Computng Envronment Dr. M. Dakshayn Dept. of ISE, BMS College of Engneerng, Bangalore, Inda. Dr. H. S. Guruprasad Dept. of ISE, BMS College of Engneerng Bangalore, Inda. ABSTRACT Cloud computng refers to the model, whch s the pool of resources. Cloud makes on-demand delvery of these computatonal resources (data, software and nfrastructure) among multple servces va a computer network wth dfferent load condtons of the cloud network. User wll be charged for the resources used based upon tme. Hence effcent utlzaton of cloud resources has become a major challenge n satsfyng the user s requrement (QoS) and n ganng beneft for both the user and the servce provder. In ths paper, we propose a prorty and admsson control based servce schedulng polcy that ams at servng the user requests satsfyng the QoS, optmzng the tme the servce-request spends n the queue and achevng the hgh throughput of the cloud by makng an effcent provson of cloud resources. Keywords Subscrpton-category, servce schedulng polcy, Prorty, admsson control and deadlne. 1. INTRODUCTION Cloud computng provdes on-demand delvery of varous servces lke computaton, software, data access, and storage servces that do not requre end-user knowledge of the physcal locaton and confguraton of the system that delvers the servces. As the user s charged for the resources used, resource schedulng strategy plays sgnfcant role n cloud computng envronment. Users or clents can submt a job to the servce provder, wthout actually possessng the software or hardware. The consumer's computer may contan very lttle software or data (perhaps a mnmal operatng system and web browser only), servng as a basc dsplay termnal connected to the Internet. Earler, both data and software had to be stored and processed on or near the computer. The desgn of cloud computng technology allows the functonal separaton between the resources used and the user's computer, usually resdng outsde the local network. Consumers regularly use data ntensve applcatons drven by cloud computng technology earler whch were unavalable due to the cost and the complexty nvolved n deployment [1,4]. An analogy to explan cloud computng s that of publc utltes such as electrcty, gas, and water. Centralzed and standardzed utltes have made ndvduals free from the dffcultes of generatng electrcty or pumpng water. The development and mantenance tasks nvolved were drastcally reduced wth cloud technology. It s very much useful for small organzatons that cannot afford huge nvestment on ther IT sector but n order to survve n today s complex compettve busness world they expect maxmum beneft from such supportng ndustry. Cloud computng can help such small organzatons by provdng massve computng power, unlmted storage capacty, less mantenance cost, avalablty of useful web-servces etc [2]. As per Buyya et. all [3], A Cloud s a type of parallel as well as dstrbuted system consstng of a collecton of nterconnected and vrtualzed computers that are dynamcally provsoned and presented as one or more unfed computng resources based on servce-level agreements establshed through negotaton between the servce provder and consumer. The defnton clearly mples that there s a Servce Level Agreement (SLA) between the provder and the consumer for gettng servces from cloud on pay per use bass. Hence effcent schedulng system s one of the core and challengng area n cloud and grd computng. Actually n Cloud computng there are three types of servces such as Infrastructure as a Servce (IaaS), Platform as a Servce (PaaS), Software as a Servce (SaaS). SaaS provdes dfferent types of applcatons as a Servce for the end user. It ncludes dfferent useful web-servces. PaaS provdes a standard platform for better executon of applcaton wth proper explotaton of physcal resources. PaaS ncludes Database servces, Mddleware Servces etc, IaaS provdes the nfrastructure of cloud consstng of physcal resources lke CPU, Storage, and Network etc [3-5]. The rest of ths paper s organzed as follows. In Secton 2, related works n the area are dscussed. Secton 3 analyzes the varous system parameters used n the system model. Proposed cloud archtecture and the schedulng polcy are descrbed n Secton 4. Secton 5 descrbes smulaton model and performance evaluaton. Fnally, n secton 6, we conclude our work and refer to future work. 2. RELATED WORK In case of Cloud computng envronment, there are some crtcal QoS parameters to be consdered, such as tme, cost (servce charge for the user and servcng charge for provder), relablty and trust/securty. In partcular, QoS requrements are not statc and need to be updated dynamcally over the tme due to contnuous changes n the operatng envronments. That s greater mportance should be gven to user s tme as they pay for usng servces from the Clouds based on tme. In addton, dynamc negotaton of SLAs between the users and the servce provder s not completely supported n the Cloud computng envronment. S. Venugopal, X. Chu, and R. Buyya [9] have 23

2 developed negotaton mechansms based on alternate offers protocol for establshng SLAs. Rajkumar Buyya, Chee Shn Yeo and Srkumar Venugopal have presented a 21st century vson of computng n ther keynote paper [3]. They also have dentfed varous computng paradgms promsng to delver the vson of computng utltes. Cloud computng defntons and the archtecture for creatng market-orented Clouds by leveragng technologes such as VMs are also dscussed. Buyya et al. [8] have proposed schedulng polces to address the tme mnmzaton and cost mnmzaton problem n the context of Grd computng. K.Mukherjee, G.Sahoo, [2] have gven a Mathematcal Model for Market-Orented Cloud Computng. They also have proposed a Bee and Ant colony system based schedulng polcy. Qang L and Yke Guo [10] have proposed a model for resource schedulng n cloud computng based on stochastc nteger programmng technque, but none of these papers have consdered the concept of admsson control and prorty of user s requests. In ths paper we are proposng an effcent prorty based schedulng polcy [PSP] and the supportng cloud archtecture wth approprate components to acheve optmzaton. We also have ncorporated an admsson control technque based on deadlne of the servce-request, that allows the cloud to accept the servce-requests only f the cloud can provde the servce satsfyng the requred QoS. 3. SYSTEM MODEL Accordng to the analyss of the behavor of the cloud computng network wth multple servers and servce-requests for servce, the cloud can be consdered as a pool of resources. The prorty based group of servce-requests n the cloud computng envronment can be consdered as M/G/c queue, and all the queues together can make a queung network. Hence applyng multple server queueng system, we gve a model for the proposed Prorty based schedulng polcy [PSP]. The parameters consdered n ths system model are lsted n the table 1. Table 1. Parameters consdered for the queung system model Parameter Q H Q M Q L Defnton Hgh Prorty Queue Medum Prorty Queue Low Prorty Queue Q H Sze of Q H Q M Sze of Q M Q L Sze of Q L T1 Threshold tme for deadlne at level 1 T2 Threshold tme for deadlne at level 2 λe Mean request arrval rate Effectve arrval rate w Ρ Average tme spent by the user request n the cloud Server utlzaton We defne the PSP wth the followng assumptons a. Subscrpton: Before demandng for the servce every user must subscrbe themselves to the cloud manager usng one of the 3 subscrpton category (SB CAT ). SB CAT Hgh, SB CAT - Medum or SB CAT - Low. For each subscrpton category subscrpton charge vares. b. Requests arrval pattern: The user s request arrvals occur randomly accordng to a Posson dstrbuton wth λ arrvals per unt tme. c. SLA between the cloud provders and the cloud users: s an agreement on guaranteed hgh qualty servce and cost for the servce d. QoS of the servce requests: There are 3 attrbutes: guaranteed servce, hgh qualty servce and cost for the servce e. Queue behavor: Request s selected from one of the three queues based on the prorty. In ths model, whenever the request for the servce from the user (servce-request ) arrves at the cloud, the Req-control-mgr estmates the servce tme ST est requred to complete that servce-request based on the type of the servce-request and the average servce tme taken (by experence) for that type of servce-request. delay T = ( DL T - C T ) (1) where C T DL T - Current tme - Deadlne gven by servce-request delay T - Maxmum tolerable tme of th ser-req Req-control-mgr also estmates the total servcng tme requred ST T est for all the servce requests n all the three queues (Y) and s computed as: ST T est Y = ST (2) est 1 Where Y= Q H + Q M + Q L w Q Total tme a Req spends n the queue Total servce tme taken by the Req Accordng to the tolerable delay computed (delay T ) and SB CAT of th servce-request (ser-req ), arrved servce-request wll be placed n one of the 3 queues (Q H Hgh prorty queue, Q M - Medum prorty queue or Q L -Low prorty queue) 24

3 { If (( delay T = ( (ST T est /C ) + ST est )) and SB CAT ==1or 2 or 3) Place the ser-req n Q H If ((delay T > ( (ST T est /C ) + ST est ) by T 1 ) ) Place the ser-req Place the ser-req n Q H n Q M Place the ser-req n Q L } If ((delay T > ( (ST T est /C ) + ST est ) by T 2 ) ) Place the ser-req n Q H or n Q M based on the space avalablty Place the ser-req n Q M or n Q L based on the space avalablty Place the ser-req n Q L based on space avalablty } } (3) Wth ths system model, the probablty that there are N customers n the system s P N. The effectve arrval rate, that s the mean number of arrvals per tme unt who enter and reman n the system s λ e. λ e = λ (1 - P N ) (4) The total tme a ser-req ( w ) spends n the cloud s: Where w w Q (5) w Q - s the total tme a ser-req spends n the queue - s the total servce tme taken by the ser-req The average tme spent by the user request ser-req n the cloud s the average req-to-servce delay/ ser-req n the Cloud. w = 1 N w N (6) The average number of user requests beng served n the cloud s the average server utlzaton p Where Ρ = e c 1 C s the number of servers n the system The maxmum delay delay T the ser-req can tolerate s specfed n SLA. To meet ths QoS requrement for the ser-req w delay T In addton to meet the QoS requrement of the servce-request, the proft ω for the cloud n provdng the servce to userrequests should also be consdered and computed. We assume that: The unt of cost for servce from the cloud as /mn Total amount of unt tme for whch servce s provded to ser-req as H. Charge per Request ser-req s = H * /mn Total proft of servcng all the requests QH QM QL = + j + 1 j1 k1 Our optmzaton problem s to k Mnmze the total tme a ser-req spends n the queue Mn w Q Guaranteed hgh qualty of servce w delay T Maxmzng the throughput 4. PRIORITY BASED SCHEDULING ALGORITHM AND ARCHITECTURE 4.1 Archtecture Our proposed archtecture conssts of 2 levels, cloud servce provder level (SPL) and user level (UL). SPL provdes a set of servces to the user wth sutable communcaton among several components of the cloud. Varous components of the cloud are Request Control-Manager (Req-Cntr-mgr), Servce Manager (Ser-mgr) n assocaton wth Resource usage Accountng- Manager (Res-mgr) etc; whereas the UL provdes secured access pont between the user and the servce provder. 25

4 Fgure 1: Cloud archtecture to support Prorty and Admsson control based servce schedulng system Whenever the request from UL arrves at the cloud the Req- Cntr-mgr accepts the request after ensurng that the servcerequest can be served wth the requred QoS (Admsson control). For ths, the Req-Cntr-mgr nteracts contnuously wth Ser-mgr regardng resource avalablty; whle the Bll-mgr decdes the charges for the fnshed job. The fnal bllng charge of the fnshed job s fxed by the Bll-mgr, based on the actual tme taken for the servce by hrng the requred resources. Thus, t ensures that there s no overloadng of resources whereby many servce requests cannot be fulflled successfully due to lmted resources avalable. The man role of Ser-mgr s to keep track of the avalablty of processors (Vrtual Machnes (VM)), assgnng the avalable requred resources to the servce-request and ntatng the servcng of the servce-request on the allocated Vrtual Machnes. The Vrtual Machnes execute the servce- request on physcal machnes. It s observed that performance montorng of any applcaton n cloud computng s always complex, dfferent and challengng. Fgure 1 shows the archtecture of the system model supportng Prorty, subscrpton-category (SUB CAT ) and SLA based servce schedulng n Clouds and Data Centers. There are bascally fve man components nvolved n ths desgn: Users: Users can submt ther requests for servcng the jobs from anywhere n the world to the Cloud through secured connecton. Request-Control-Manager (Req-Cntr-mgr): The Req-Cntrmgr behaves as an nterface between the Cloud servce provder and external users. In order to schedule the servces, t requres the nteracton wth the other enttes to support prorty, Admsson control and subscrptoncategory based servce management. When the servcerequest s frst submtted, the Req-Cntr-mgr checks whether the servce-request can be admtted to the cloud or not by computng tolerable delay for that request usng the equaton (1) f ( delay T ( ( ST T est /C ) + ST est )) Admt the servce-request reject the servce-request the Req-Cntr-mgr assgns the prorty to each user request based on the delay T and SB CAT to whch user belongs. Every user has to subscrbe themselves to the cloud before accessng the cloud for submsson of servce request. Durng ths subscrpton phase SLA s sgned between the cloud servce provder and the user. The Req-Cntr-mgr analyzes the submtted request for QoS requrements based on the prorty and adds the request to one of the 3 queues Hgh prorty queue (Q-H), Medum prorty queue (Q-M), low prorty queue (Q-L) based on the prorty computed usng equaton (3), SUB CAT and on the avalablty of the resources. These ser-reqs wll be taken from these queues and servced based on the avalablty of the resources requred. Before decdng whether to accept or reject the request Req- Cntr-mgr communcates wth the Ser-mgr. Thus, t ensures that 26

5 there s no overloadng of resources whereby many servce requests cannot be fulflled successfully due to lmted resources avalable. It also needs the latest status nformaton regardng resource avalablty (from Ser-mgr) n order to make resource allocaton decsons effectvely. Then, t assgns requests to VMs. Queung-manager (Q-mgr) : s responsble for keepng all the ser-reqs n an approprate queue based on the prorty decded (computed by Assgn-Prorty module) by Req-Cntrmgr. It releases the ser-reqs for servcng accordng to the nstructon gven by Req-Cntr-mgr wth ser-mgr. (Pr ) = Assgn-prorty(delay T, ST T est,sub CAT) If (Pr == H) Q H = ser-req If (Pr == M) Q M = ser-req If ((Pr == L) Q L = ser-req Storage-Manager (Sto-mgr): Sto-mgr stores and retreves the data requred for processng of the jobs. Bllng-Manager (Bll-mgr): The Bllng-mgr decdes (computed by Amt-to-be-pad module) how the completed servced requests should be charged. For nstance, servcerequest can be charged based on the total tme taken to complete the servce Hμ and bllng rates (fxed/changng). 4.2 Algorthm [Nomenclature : Req - Servce request from user Hμ - Total tme (mns) served - Subscrpton category SB CAT delay T - Tolerable delay for the request ] When a request for the servce from the user ser-req arrves at the Cloud (Servce provder) Req-control-mgr checks for the admsson by computng the maxmum tolerable delay and requred servce tme for that serreq f ( delay T ( ( ST T est /C ) + ST est )) Admt the servce-request reject the servce-request Req-control-mgr assgns the prorty by callng Assgn-prorty module. (Pr ) = Assgn-prorty(delay T, ST T est,td max) If (Pr == H) Q H = ser-req If (Pr == M) Q M = ser-req If ((Pr == L) Q L = ser-req Based on prorty and SUB CAT of the ser-req servce schedulng happens as follows Whle (Q H NULL) {For each servce-request n Q H Req-ser-mgr Checks for the resource avalablty by f (requred resources are avalable) communcatng wth the Ser-mgr { Schedule the ser-req for the servce and ntate the Once the s completed servcng of ser-req Bllng s done by Bll-mgr to charge for the servce Amt-to-be-pad(Hμ) } provded to ser-req dynamcally reallocate the resources based on delay T and ST est and SB CAT } Whle (Q M NULL) {For each servce-request n Q M Req-ser-mgr Checks for the resource avalablty by f (requred resources are avalable) communcatng wth the Ser-mgr { Schedule the ser-req for the servce and ntate the Once the s completed servcng of ser-req Bllng s done by Bllng-mgr to charge for the servce Amt-to-be-pad(Hμ) } provded to ser-req 27

6 dynamcally reallocate the resources based on delay T Place the servce-request n Q H or n Q M } and ST est and SB CAT Whle (Q L NULL) } Place the servce-request n Q M or n Q L Place the servce-request n Q L } {For each servce-request n Q L Req-ser-mgr Checks for the resource avalablty by f (requred resources are avalable) communcatng wth the Ser-mgr { Schedule the ser-req for the servce and ntate the Once the s completed servcng of ser-req Bllng s done by Bllng-mgr to charge for the servce Amt-to-be-pad(Hμ) } provded to ser-req dynamcally reallocate the resources based on delay T and ST est and SB CAT } Prorty assgnment Module char Assgn-Prorty(delay T, ST T est,) { If ((delay T = ( ( ST T est /C ) + ST est )) and SB CAT ==1or 2 or 3) Rethrn(H) If ((delay T > ( ( ST T est /C ) + ST est ) by T 1 ) ) Rethrn(H) Rethrn(M) Rethrn(L) } If ((delay T > ( ( ST T est /C ) + ST est ) by T 2 ) ) Bllng Module Int Amt-tobe-pad ( H ) { } Re q = H * /mn Return (Re q) 5. SIMULATION MODEL AND PERFORMANCE EVALUATION In our smulaton model, we have a sngle cloud wth group of 4 servers. There are 3 queues namely hgh prorty queue-q H, medum prorty queue-q M and low prorty queue-q L wth queue sze of 15 each. We assume that, there s suffcent bandwdth n the cloud network. Smulaton has been conducted for 5 hours. The table 2 lsts the performance parameters consdered for the smulaton. Table 2:. Parameters for the Smulaton model Parameter Defnton Q H 15 Q M 15 Q L 15 T 1 T 2 λe 25 mns 60 mns 46 request/hr 30 to 45/hr C 4 Unt tme Mnutes Servce Completon Rate wth QoS Vs Prorty: In comparson wth the tradtonal servce schedulng technque(tsc) wth out consderng any prorty and admsson control [TSC-(AC+P)], Fgure 2 shows servce completon rate for the servce-requests wth our proposed prorty based schedulng polcy wth admsson control [PSC+AC]. Durng the admsson of the servce-request tself ths algorthm checks whether the guaranteed qualty servce can be provded by 28

7 computng delay T and ST est. Hence almost 99% of the servcerequests have been provded wth guaranteed hgh qualty servce. Snce ST est s the estmated servce tme requred to complete the servce-request, as λ and λ e ncreases 1% of the requests could not fnsh ther servce wthn the specfed deadlne as shown n the fgure 2. Whereas the tradtonal servce schedulng polcy n whch, the prorty and admsson control polcy are not consdered accepts all the requests. Hence t s not able to complete all the requests wth specfed QoS as shown n fgures 2 and 3. Thus the overall performance of the cloud throughput has been ncreased n the proposed prorty based schedulng polcy wth admsson control technque. Fgure 2: Servce Completon Rate Vs Prorty Impact of Prorty and admsson control based schedulng polcy on an average tme a user request spends n the Queue: Keepng all the ser-reqs n the approprate queues the proposed algorthm ensures the guaranteed qualty servce to every user request. As [PSP+AC] gves hgher precedence to hgh prorty servce-request, the average tme servce-request wats n the queue also decreases as the prorty ncreases as shown n the fgure 3. Fgure 3: No. of reqs met delay T Vs No. of reqs volated delay T 6. CONCLUSION In ths paper an effcent Prorty and admsson control based servce schedulng polcy[psp+ac] and an optmzaton model are proposed. Ths polcy wth the proposed cloud archtecture has acheved very hgh (99%) servce completon rate wth guaranteed QoS over the tradtonal schedulng polcy whch does not consder the prorty and admsson control technques[tsp-(ac+p)]. As ths polcy provdes the hghest precedence for hghly pad user servce-requests, overall servcng cost for the cloud also ncreases. In our future work, we are plannng to extend ths model to hre resources from other clouds and provson of securty to mprove the performance of the cloud system. 7. REFERENCES [1] Cloud computng - Wkpeda, the free encyclopeda.htm [2] K.Mukherjee, G.Sahoo, Development of Mathematcal Model for Market-Orented Cloud Computng, Internatonal Journal of Computer Applcatons ( ), Volume 9 No.11, November [3] Rajkumar Buyya, Chee Shn Yeo and Srkumar Venugopal, Market-Orented Cloud Computng: Vson, Hype, and Realty for Delverng IT Servces as Computng Utltes, The 10th IEEE Internatonal Conference on Hgh Performance Computng and Communcatons, IEEE Computer Socety, 2008, pages [4] P. Mell and T. Grance, Draft NIST workng defnton of cloudcomputng, Referenced on June. 3rd, 2009 Onlne at [5] Lu Peng. Cloud computng prncple. Web Page [6] Chen Mng1,L Mengkun1,Ca Fuqn1 A model of schedulng optmzng for cloud computng resource sevces based on, 2010 IEEE Internatonal conference on Granular Computng. DOI /GC [7] A Sachn V. Solank, B. Mnal Gour and C. A.R. Mahajan, An overvew of Dfferent Job Schedulng Heurstcs Strateges for Cloud Computng Envronment, [8] R. Buyya, M.M. Murshed, D. Abramson, and S. Venugopal. Schedulng parametersweep applcatons on global grds: a deadlne and budget constraned cost-tme optmzaton algorthm. Software Practce and Experence, 35(5):491{512, [9] S. Venugopal, X. Chu, and R. Buyya. A Negotaton Mechansm for Advance Resource Reservaton usng the Alternate Offers Protocol. In Proceedngs of the 16th Internatonal Workshop on Qualty of Servce (IWQoS 2008), Twente, The Netherlands, June [10] Qang L, Yke Guo. Optmzaton of Resource Schedulng n Cloud Computng, 12 th Internatonal Symposum on Symbolc and Numerc Algorthms for Scentfc Computng, /10 IEEE, DOI /SYNASC