WEIGHTED ROUND ROBIN POLICY FOR SERVICE BROKERS IN A CLOUD ENVIRONMENT

WEIGHTED ROUND ROBIN POLICY FOR SERVICE BROKERS IN A CLOUD ENVIRONMENT MOHAMMED RADI Computer Science Department,Faculty of Applied Science Alaqsa University, Gaza Moh_radi@alaqsa.edu.ps ABSTRACT Cloud computing is a distributed computing paradigm wherein computation is performedby a third-party computer.it can be utilized instorage. In the CloudAnalystsimulation tool, aservice broker applies a service broker to select the target data center(dc) whena user creates a new request.the routing based on service proximity is one such;it routes user requests by selecting the closest regional DC. When the closest region contains more than one DC, thisrouting randomly selects one of these centerswithout consideringits characteristics. However, this randomselectionof DCslimits response time and DC processing time when the processing capacities of DCs differ. In this study, we therefore propose a weighted round robin (WRR) service broker that maintains a weighted list of all DCs in the same region and forwards new requests according to the weight (or preference) of each DC. We integratedthis into the CloudAnalystsimulator and then compared it with other policies. Simulation results proved that the proposed WRR improves overall response time and DC processing time. Key Words Broker Policy, Cloud Computing, Data Center Selection, Cloudanalyst University of Nizwa, Oman December 9-11, 2014 Page 45

1. Introduction Cloud computing is a distributed computing paradigm wherein computation is performedby a third-party computer.it can be utilized in storage and is widely acknowledged by the industry. However, cloud computing is presently limited by system bottleneckas a result of load imbalance, the inefficient distribution of computing resources, and minimum resource consumption [1].In a real-time environment, the effectof different factors on cloud environments is difficult to determine. In the present study, therefore, we examinethiscloud environment through simulation. The CloudAnalysttool [2]models, simulates, and experiments on cloud computing infrastructures smoothly. This platform can also be used to model data center (DCs), service brokers, and scheduling and allocation policies for cloud.to distribute workloads evenly to all of the DCs in the entire cloud system, a service broker is applied. This significantlyaffectssystem performance and resource utilization. Aservice broker that selects the closest regional DC to which user requests can be routedis known as a service proximity-based routing. If the closest region contains more than one DC, this randomly selects a DC without considering its characteristics. However, this random selection ofdcslimits response time and DC processing time when the processing capacities of DCs differ.many researchers aim to overcome these problems [1, 3 7]; however,most of themdo not select DCs efficiently, especially when their processing capacities vary.as a result, system performance deteriorates.in this study,we focus on service broker whena single region containsmore than one DC. We propose a weighted round robin (WRR) service broker that maintains a weighted list of all DCs and forwards new requests according to the weight (or preference) of each DC. We integratethiswrr into the CloudAnalystsimulator and compareit with other policies.the results show that the proposed WRR service broker enhances overall response time and DCprocessing time. The remainder of the paper is organized as follows In Section 2, we discussedpreviousworks related to cloud service broker policies. In Section 3, we describedthe CloudAnalyst tool. In Section 4, we present the proposed. In Section 5, weexplain the configuration of the simulation andthe results. We also analyzeperformance. Finally, we conclude the paper with a brief summary and a description of our future research directions in Section 6. 2. Related Work The service broker routes requests from variousglobal user groups located at different geographical regions to cloud DCs, which are also distributed worldwide. In this respect, thecloudanalyst simulator follows the followingthree standard service broker policies Proximity-basedBroker Policy This determines the shortest path to a DC. The service brokerthen sends arequest to the closestdcin consideration ofnetwork latency. Performance Optimization Policy In this, the service broker actively monitors all of the DCs and sends arequest to the center that responds the most efficiently to the query of anend user. Dynamic Configuration Policy In this, the service broker alsoscalesthe deployment of an application depending on its current load. This adjuststhe number of virtual machines (VMs) in the DCs dynamically according to current processing times, which arematchedagainst the best processing times achieved. The service proximity broker selects DCs randomly when a single region contains more than one DC. However, this random selection is problematic. First, the process of requesting is not properly controlled. Second, it may choose a DC with a heavy workload and a long processing time. Third, resources may be underutilized. Finally, different results may be obtained under the same configuration; hence,they may be difficult to apply for developers/researchers. Many researchers aim to overcomethese problems[1, 3 7]. For instance,[1] proposed the improved round robin algorithm for service brokers.thisproposed DCselection algorithm combinesthe advantages of existing round robin and service proximity algorithms for service brokersandselects DCs in a round-robin manner from among all of the DCs withina single region. Therefore,resource utilization is increased.however, the processing speeds of DCs may vary, andfastdcs should bechosenmore often than slow ones to improve performance and resource utilization. Hence,we mustconsiderdcspeed in the selection process. In [3], the authors improved on theservice proximitybased routing by proposing a priority-based round-robin service broker algorithm that distributes requests based on DCpriority and enhances performance more than the conventional random selection algorithm.[4]establishedthe extended service proximity-based routing. Whenthe selected region contains more than one DC, this chooses thelow-cost DC (it considersvm cost alone). [5] proposed a round robin-based selection algorithm to select DCs. This round-robin technique is used to choose both adcand a physical machine. However, it University of Nizwa, Oman December 9-11, 2014 Page 46

underutilizes resourcesand consumes power. [6] mainly implementedthe predictive service broker algorithm based on the weighted moving average forecast model. This algorithm minimizesthe reduction in response time as felt by users and as shown in terms of the load on DCs. [7] extended the service proximitybased broker by selecting a cost-efficient DC. However, this algorithm does not consider performance and availability. 3. CloudAnalyst The CloudSimtoolkit models, simulates, and experimentson cloud computing infrastructures smoothly [8]. It is a platform that can be used to model DCs, service brokers, and the scheduling and allocation policies of large cloud platforms. CloudAnalyst[2] is built directly on CloudSim. VM Load Balancer This component models the load balance used by DCs when serving allocation is requested. Broker The service broker selects adc to fulfill requests obtained from the userbase. 4. Framework of Broker Policy In the cloud environment, the service broker selectsadc to process the cloudlet, whereas the VM load balancer component load balances the cloudlet inthe VMs of the DC. Figure 1 shows how user requests are routed throughthe service broker and the VM load balancer [8][2]. The main features of CloudAnalyst are as follows Easy-to-use graphical user interface (GUI). Capability to define a simulation with high degrees of configurability and flexibility. Repeatability of experiments. Graphical output. Use of consolidated technology and ease of extension. The main components of CloudAnalyst and their responsibilities are as follows[2] GUI Package It handles the GUI and acts as the front end controller for the application. It also managesscreentransitionsand other UI activities. RegionSixexisting regions correspond to the sixcontinents in the world. User Base This component models a group of users and generates representative traffic. DC. DCencapsulates a set of computing hosts or servers that are either heterogeneous or homogeneous based on their hardware configurations. DC Controller This component controls DC activities. Cloudlet It specifies a set of user requests. It contains application ID, the name of the user base as the originator towhich responses can be returned, request execution commands (considered in terms of size), and input and output files. Internet. This component models the Internet and implements traffic routing behavior. Internet Characteristics This component defines the Internet characteristics applied during the simulation. Figure 1 Routing of user requests in CloudAnalyst As soon as the user base generates an Internet cloudlet, the Internet requests DC selectionfrom the service broker. The service broker then appliesa service broker to return information about the selected DC controller to the Internet. Using this information, the Internet then sends the requests to the selecteddccontroller. Theselected DCcontroller processes the requests usinga VMload balancer before it finally sends the response to the Internet. proximity-based routing is aservice broker based on the strategy involving the closest DC. The service proximity works as follows 1. The service proximity service broker maintains a table of all DCs that are indexed according toregion. 2. When the Internet receives a message from a user base, it requests the selection of a DC controller fromthe service proximity service broker. University of Nizwa, Oman December 9-11, 2014 Page 47

3. The service proximity service broker determinesthe region of the request sender and queries itsregion proximity list as per Internet characteristics. This list orders the remaining regions in terms ofdecreasingnetwork latency asderivedfrom the given region. 4. The service proximity service broker choosesthe first DC located at the earliest/highest region on the proximity list. If a region contains more than one DC, thedcis selected randomly. The service proximity randomly chooses DC if a region has more than one DC. However, this random selection may be problematic. First, results may varyunder the same configuration. As a result, they are difficult to apply for developers/researchers. Second, the selected DCmay be under a heavyworkload and be limited by a longprocessing or response time. Finally, resources may be underutilized. 5. Weighted Round Robin (WRR) Broker Policy In this study, the proposed WRR service broker is a modified version of the service proximity andconsiders the processing capacitiesof DCs in terms oftwo main factors, namelynumber of processors and processor speed. In the proposed WRR, an initialization algorithm maintains a weighted list of all DCs in a single region. The weight of each DC is calculated based on the number of processors and processor speed usingequation 1. Data_Center_Weight= (1) where Figure 2 details the initialization algorithm. 1 2 3 4 5 6 Algorithm 1 Initialization Begin For all region having more than one data center do For each data center do DCi(W) = Endfor Endfor End Figure 2 Initialization of WRR If the closest region has more than one DC, the WRR selects the best DC based on weightinstead of selecting the target DC randomly (as shown in Figure 3). 6. Simulation and results To evaluate the proposed WRRservice broker, we apply the CloudAnalyst tool. We compare WRR with the service proximity and the improved round-robin through a simulationconfigured with a single user base and four DCs in a region. Table 1depictsthe configuration of the user base;table 2presents that of thedc;andtable 3liststheother simulation parameters. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Algorithm 2 WRR service broker Input Region number, Weight list Output Destination DC name Begin Dclist regionaldatacenterindex.get(region) if Dclist is not NULL then nodc Dclist.size() if nodc==1 then DcName Dclist.get(0) Return DcName else Let Dc(i)= such DCi(W) is the maximum If DCi(W)!=0 DCi(W)= DCi(W) -1 DcName = DCi.name Return DcName Else for each data center in the current region do DCi(W) = Go to (11) Figure 3Algorithm for the WRR service broker Table 1User base configuration UB name Region UB1 0 Table 2DCconfiguration Name Regio n #VM s Cost/VM ($/Hr) Peak hrs (GMT) 300 900 Data transfer cost ($/Gb) Avg. users Avg. offpeak users 10000 1000 Numbe r of process ors Speed (MIPS) DC1 0 5 0.05 0.05 2 5000 DC2 0 10 0.1 0.1 4 10000 DC3 0 15 0.12 0.12 6 15000 DC4 0 20 0.15 0.15 8 20000 Table 3 Other simulation parameters Parameter User grouping factor in user base 1000 Request grouping factor 10 Executable instruction length/request 500 Load balancing Roundrobin Simulation duration 24 Hr VM image size 10000 VM memory 512 Mb VM bandwidth 1000 University of Nizwa, Oman December 9-11, 2014 Page 48

DCarchitecture X86 DCprocessor/machine 4 DCOS Linux The service proximity-based routing algorithm was simulated under this configuration, along with the service proximity, improved round-robin, and WRRpolicies. The overall response time and DCprocessing time were considered performance metrics. Tables 4 and 5 depict the simulation results as computed by CloudAnalyst. broker proximity Improved Round- Robin Table 4 Overall response time Overall response time Avg (ms) Min (ms) Max (ms) 92.90 41.62 404.17 84.95 41.62 226.86 WRR 72.57 41.68 205.25 As shown in Figure 4, the proposed WRR service Table 5 Overall DC processing time Overall DC processing time broker Avg (ms) Min (ms) Max (ms) 42.89 0.29 348.63 proximity Improved 34.95 0.29 178.34 roundrobin WRR 22.58 0.29 151.25 broker enhancesoverall response time and DCprocessing timemore than the service proximity and the improved round-robin policies. Figure 4AverageDCprocessing time; Average overall response time 7. Conclusion In this study,we modified the service proximity and proposed a WRR service broker. Ifthe closest region determined has more than one DC, the proposed selects the best DC based on weightinstead of through random selection. We integrated the proposed WRR into the CloudAnalyst simulator and compared it with other policies. The simulation results confirm that the proposed WRR improved overall response time and DC processing time. 8. References 1. Kapgate, D., Improved Round Robin Algorithm for Data Center Selection in Cloud Computing International Journal of Engineering Sciences & Research TECHNOLOGY (ijesrt ) 2014. 3(2) p. 686-691. 2. Wickremasinghe, B., R.N. Calheiros, and R. Buyya. Cloudanalyst A cloudsim-based visual modeller for analysing cloud computing environments and applications. in Advanced Information Networking and Applications (AINA), 2010 24th IEEE International Conference on. 2010. IEEE. 3. Mishra, R.K., S. Kumar, and B. Sreenu Naik. Priority based Round-Robin service broker algorithm for Cloud-Analyst. in Advance Computing Conference (IACC), 2014 IEEE International. 2014. IEEE. 4. Limbani, D. and B. Oza, A Proposed Broker Policy for Data Center Selection in Cloud Environment with Implementation. International Journal of Computer Technology & Applications, 2012. 3(3) p. 1082-1087. 5. Sharma, V., R. Rathi, and S.K. Bola, Round- Robin Data Center Selection in Single Region for Proximity Broker in CloudAnalyst. International Journal of Computers & Technology, 2013. 4(2a1) p. 254-260. 6. Kapgate, D., Weighted Moving Average Forecast Model based Prediction Broker Algorithm for Cloud Computing. IJCSMC, 2014. Vol. 3(Issue. 2) p. pg.71 79 7. Dash, M., A. Mahapatra, and N.R. Chakraborty, Cost Effective Selection of Data Center in Cloud Environment. International Journal on Advanced Computer Theory and Engineering (IJACTE), 2013. Volume- 2(Issue-1) p. pp 2319 2526. 8. Calheiros, R.N., et al., CloudSim a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms. Software Practice and Experience, 2011. 41(1) p. 23-50. University of Nizwa, Oman December 9-11, 2014 Page 49