Ranking Model for SLA Resource Provisioning Management

Ranking Model for SLA Resource Provisioning Management

C. S. Rajarajeswari (Department of Computer Science, Indira Gandhi College of Arts and Science, Puducherry, India) and M. Aramudhan (Department of Information Technology, Perunthalaivar Kamarajar Institute of Engineering and Technology, Karaikal, India)
Copyright: © 2014 |Pages: 13
DOI: 10.4018/ijcac.2014070105
OnDemand PDF Download:
No Current Special Offers


Cloud computing is an amazing technology, which provides services to users on-demand. Since there are many providers in the cloud, users get confused in selecting the optimal cloud service provider. To overcome this limitation, federated cloud management architecture was proposed. There is no standard framework for ranking the cloud service providers in the existing federated cloud model. The proposed work provides a new federated cloud mechanism, in which Cloud Broker Manager (CBM) takes up the responsibility of resource provisioning and ranking. Differentiated Service Module (DSM) is projected in CBM that classifies the incoming users as SLA or non-SLA members. Dynamic Loose Priority Scheduling (DLPS) is proposed in CBM to manage the number of services. To reduce the overload of the CBM, a secondary CBM (sCBM) is proposed. Experimental results show that the proposed DLPS technique improves the resource provisioning and Quality of Service (QoS) to SLA members and improves the performance of federated cloud by 18% than the existing model.
Article Preview


Cloud computing is a current paradigm in the field of Information Technology that offers cost effective outsourcing in dynamic service environment (Marosi, Kecskemeti, Kertesz, & Kacsuk, 2011; Buyya, Yeo, Venugopal, Broberg, & Brandic, 2009; Li, Qiu, Niu, & Ming, 2010). Service Level Agreement (SLA) is defined as a document that contains the level of performance promise made by a provider at the user side (Jrad, Tao, & Streit, 2012; Wu & Buyya, 2010). A single cloud service model does not provide proficient service, when workload becomes high. Small organizations cannot compete with the prominent cloud service providers even though they have enough resources expected by a customer. In order to overcome the heavy load of single cloud model and compete with the prominent cloud service providers, federated cloud architecture was suggested.

Federated cloud is a federation of cloud model that helps to resolve the complexity present in the single cloud service model. SLA is implemented between cloud member and cloud service provider for efficient processing of federated cloud. Functional SLA parameters includes memory related information like memory size, CPU cores, CPU size etc. and non-functional SLA parameters consists of response time, cost, execution time, security etc (Jrad, Tao, & Streit, 2012; Aljawarneh, 2011). User requirements include both functional and non-functional SLA parameters. Cloud service provider chosen for execution, must satisfy both the functional and non-functional requirements given by a user. Best resource provisioning (Calheiros, Vecchiola, Karunamoorthy, & Buyya, 2011) to user’s requirements is one of the challenging tasks in the existing federated cloud mechanism (Toosi, Calheiros, Thulasiram, & Buyya, 2011).

In the proposed model, Cloud Broker Manager (CBM) takes up the responsibility of resource provisioning in federated cloud. Each provider has broker that interconnects with CBM.There are two types of CBM namely pCBM and sCBM. The roles of pCBM in the proposed cloud architecture are (i) identifying the category of user (ii) managing the request processing and (iii) allocating cloud provider to the request. Differentiated Service Module (DSM) is suggested in pCBM that classifies the incoming users as either SLA or non-SLA members.In implementation, pCBM architecture maintains two service queues for users at application level and accordingly promotes their differential treatment. It is simple, extensible, flexible and portable. The DSM module leads to starvation; hence DLPS is proposed to manage the incoming request and improves the response time of the user. To reduce the overload of pCBM, a secondary CBM (sCBM) is proposed to take up the responsibility of resource provisioning only for SLA members.

The functionality of sCBM are (i) finding the cloud service providers matching with user requirements, (ii) assigning ranks to the selected service providers (iii) finding the best cloud service provider and (iii) performance with respect to QoS parameters such as scalability and reliability. In this paper, all the above challenges are addressed and solutions are provided. Today, the number of provider offering cloud services is increasing rapidly. The manual process of cloud selection becomes quite complicated and time consuming (Gulia & Sood, 2013). Hence, a stochastic Markov process model is used in sCBM for selecting the matched cloud providers based on the SLA requirements. The second challenge in sCBM is addressed using the concept of cloud ranking. Cloud ranking (Zheng, Zhang, & lyu, 2010; Tran, Tsuji, & Masuda, 2009) model is a method of assigning ranks to the providers discovered by Markov process. Based upon the output of the cloud ranking, sCBM selects the best provider and choose appropriate broker from the interconnected list, and assigns a user tasks to the selected service provider. In the existing work, ranking is computed for all service providers (Garget, Versteeg, & Buyya, 2013) where as in the proposed model, the ranking is computed only for the providers in the selected list.

This paper describes how the SLA management is effectively designed for users and efficient interoperability is achieved through broker architecture. This paper also discusses how the customers are linked to the best available cloud service providers through brokers.

Complete Article List

Search this Journal:
Open Access Articles: Forthcoming
Volume 12: 4 Issues (2022): 1 Released, 3 Forthcoming
Volume 11: 4 Issues (2021)
Volume 10: 4 Issues (2020)
Volume 9: 4 Issues (2019)
Volume 8: 4 Issues (2018)
Volume 7: 4 Issues (2017)
Volume 6: 4 Issues (2016)
Volume 5: 4 Issues (2015)
Volume 4: 4 Issues (2014)
Volume 3: 4 Issues (2013)
Volume 2: 4 Issues (2012)
Volume 1: 4 Issues (2011)
View Complete Journal Contents Listing