A Proposed Service Broker Policy for Data Center Selection in Cloud
Environment with Implementation
Dhaval Limbani*, Bhavesh Oza**
*(Department of Information Technology, S. S. Engineering College, Bhavnagar)
** (Department of Computer Engineering, L.D. College of Engineering, Ahmedabad)
Abstract
Cloud Services may be offered as public or private or combined. There is the demand of timely, repeatable, and controllable methodologies for evaluation of algorithms, applications, and policies before actual development of cloud products. Using simulation, we can study the behavior of them in cloud environment. Cloud-Analyst, the Cloud-Sim based tool, is useful to model and analyze cloud computing environment and applications. The simulator uses different algorithms (Service Broker Algorithms, Load balancing algorithms etc) and generates report as per configuration. With the help of simulation report, we can modify the cloud environment as per requirement. The service proximity based routing policy used in the simulator selects data center from the earliest region to route the user requests. When there is the situation to select one data center from those with same region, the policy selects data-center randomly without considering cost-effectiveness or other parameters. We have proposed the extended service proximity based routing policy. Using proposed policy, we can have cost effective routing of user requests to the data center than in the original one. And thus, some of the research issues related to cost can be explored.
1. Introduction
The offered Cloud Services classified as public or private or combined of both. These cloud architectures demand timely, repeatable, and controllable methodologies for evaluation of algorithms, applications, and policies before actual development of cloud services/products.[1]
For Cloud Computing environment, simulation-based approaches offer significant benefits, as it allows to test cloud services/products in repeatable and controllable environment free of cost, and to tune the performance bottlenecks before deploying on real Clouds. [1]
In Section 2, we have discussed some research issues related to the mapping of services to resources and economic models driven optimization techniques. In
Section 3, we have discussed about the CloudAnalyst,
the tool for simulation in cloud environment, and its working.
In Section 4, we have discussed working of a service broker policy of the CloudAnalyst. In Section 5 and
Section 6, we have proposed a service broker policy
with results. And finally we have concluded our work.
2. Some of the research issues
Flexible Mapping of Services to Resources[2]
With increased operating costs and energy requirements of composite systems, it becomes critical to maximize their efficiency, cost-effectiveness, and utilization. The process of mapping services to resources is a complex undertaking, as it requires the system to compute the best software and hardware
configuration (system size and mix of resources) to ensure that QoS targets of services are achieved, while maximizing system efficiency and utilization. This process is further complicated by the uncertain behavior of resources and services. Consequently,
there is an immediate need to devise performance modeling and market-based service mapping techniques that ensure efficient system utilization without having an unacceptable impact on QoS targets.
Economic Models Driven Optimization Techniques [2]
The market-driven decision making problem is a combinatorial optimization problem that searches the optimal combinations of services and their deployment plans. Unlike many existing multi-objective optimization solutions, the optimization models that ultimately aim to optimize both resource-centric (utilization, availability, reliability) and user-centric
(response time, budget spent, fairness) QoS targets need to be developed.
To enable the new mobile cloud application model, many challenges exist in different areas, including data replication, consistency, transaction management, cache management, optimal cost-effective execution in
heterogeneous computing environments.[3]
3
.
CloudAnalyst
Cloud-Analyst is built on the top of Cloud-sim. Cloud-sim is developed on the top of the Grid-sim. There are some new extensions in Cloud-analyst.[4][5]
Application users
There is the requirement of autonomous entities to act as traffic generators and behavior needs to be configurable.
Internet
It is introduced to model the realistically data transmission across Internet with network delays and bandwidth restrictions.
Figure 1. Responsibilities- Segregation
Simulation defined by time period
In Cloud-sim, the process takes place based on the pre-defined events. Here, in Cloud-Analyst, there is a need to generate events until the set time-period expires.
Service Brokers
DataCeneterBroker in CloudSim performs VM management in multiple data centers and routing traffic to appropriate data centers. These two main responsibilities were segregated and assigned to DataCenterController and CloudAppServiceBroker in Cloud-Analyst(Fig .1)
GUI and Ability to save simulations and results:
The user can configure the simulation with high level of details using the GUI. It makes easy to do the
simulation experiments and to do it in repeatable manner. Using the GUI introduced here, we can also save the simulation configurations as well as the results in the form of PDF files for future use.
3.1 Some Components [4]
Region
In the CloudAnalyst 6 „Regions‟ are there based on the 6 main continents in the World. To have the realisting simplicity for the large scaled testing in Cloud-Analyst.
User Base
A User Base models a group of users that is considered as a single unit in the simulation and its main responsibility is to generate traffic for the simulation. A single User Base may represent thousands of users but is configured as a single unit and the traffic generated in simultaneous bursts representative of the size of the user base. The modeler may choose to use a User Base to represent a single user, but ideally a User Base should be used to represent a larger number of users for the efficiency of simulation.
VM Load Balancer
VM Load balancer is useful to determine which VM should be assigned the requests (Cloudlet) for processing. Three policies are included currently in the Cloud-analyst.
Internet Cloudlet
It is a grouping of user requests. The number of requests grouped into a single Internet Cloudlet. This Internet Cloudlet is configurable in Cloud Analyst. The Internet Cloudlet is having information such as the size of a request execution command, size of input and output files, the originator and target application id used for routing by the Internet and the number of requests.
CloudApplicationServiceBroker
A service broker decides which data center should provide the service to the requests coming from each user base. And thus, service broker controls the traffic routing between User Bases and Data Centers. Currently, Cloud-Analyst is with three types of service brokers each implementing a different routing policy.
Service Proximity based routing
Here, the shortest path to the data center from the user base, depended on the network latency is selected and according to that, the service broker routes the traffic to the closest data center with the consideration of transmission latency.
DataAppServiceBroker DataCenterController
VM management and load balancing
of VM’s (within single data center)
Management of the routing of user requests
based on different Service brokerage
Performance Optimized routing
In this routing policy, service broker actively monitors the performance of all data centers, and based on that, directs traffic to the data center with best response time
Dynamically reconfiguring router
This router has one more responsibility of scaling the application deployment depended on the current load it faces. This policy increases and decreases the no. of virtual machines allocated in the data centers. This will be done taking under consideration the current processing times and best processing time ever achieved.
3.2 Routing of User Requests
In Cloud-Analyst, how the routing of user request takes place is shown in the figure (figure 2) below including the use of service broker policy and the virtual machine load balancer. [4][6]
Figure 2. User Requests Routing
User Base generates an Internet Cloudlet, with the application id for the application it is intended and also includes the name of the User Base itself as the originator for routing back the responses. With the Zero delay, REQUEST is sent to the Internet. On receiving the REQUEST, Internet consults the Service broker for the data center selection. The service broker uses any one of the service broker policy based on the REQUEST information and sends information about selected data center controller to the Internet. Using this information, Internet sends the REQUEST to the
Data Center Controller. Now Selected Data Center Controller uses virtual machines load balancer and after processing the requests, sends the RESPONSE to the Internet.
Now Internet will use the “originator” field of the cloudlet information it received earlier and will add appropriate network delay with RESPONSE and sends to the User Base.
4. Working of Service Proximity Based
Routing
This is the simplest Service Broker implementation. The region selection is based on the earliest/ highest region in the proximity list and any data center of the selected region is then selected randomly for the user requests to be processed. [4][6]
Figure 3. Service Proximity Based Routing
Problems using Service Proximity
1) Random selection of data center when more than one data center in the same region
2) possibility of selection of data center with higher cost
3) For the same configuration, results may be different (random selection) and developers/researchers may get difficulties to use the results.
5. Proposed Service Broker Algorithm
As concluded in the Service Proximity Based algorithm, modifications are made and we gave idea proposed service broker algorithm in our last research paper[4]6]. And here we have presented step by step with implementation.
1. ServiceProximityServiceBroker maintains an index table of all Data Centers indexed by their region.
2. When the Internet receives a message from a user base it queries the ServiceProximityServiceBroker for the destination DataCenterController.
3. ServiceProximityServiceBroker retrieves the region of the sender of the request and queries for the region proximity list for that region from the InternetCharacteristics. This list orders the remaining regions in the order of lowest network latency first when calculated from the given region.
4. The ServiceProximityServiceBroker picks the first data center located at the earliest/highest region in the proximity list. If more than one data center is
located in a region, the data center having less cost (here, considering only VM cost) will be selected. Now request will be sent to this most cost effective data center
As per this strategy, the data center selection is not made randomly and vm cost in each data center is compared with other data centers in the same region. The data center with lowest vm cost is selected. Now the requests will be sent to this data center to be processed.
Figure 4. Proposed algorithm
This strategy gives cost effective user request routing and this can be observed in the experiments and the results on the CloudAnalyst with the same configuration with both Service Proximity Based routing and Proposed Algorithm.
Algorithm: Data Center Selection (proposed)
01: Get the datacenter index of selected region
02: regionaList regionalDataCenterIndex.get (region) // store regionlist of selected datacentre
03: if regionaList is not NULL then 04: listSize size (regionalist) 05: if listSize is 1 then
06: dcName regionalist.get(0) 07: else
08: for all p in dcVMCostList do
09: if(dcVmCostList.get (smallest)>dcVmCostList.get (p)) then 10: smallest=p;
11: end if 12: end for
13: dcName regionalist.get (smallest) 14: end if
15: end if 16: return dcname
5.1 Proposed Algorithm (2) (Modified)
As we have explained in the implemented algorithm above, we are choosing the most cost effective data center. Now in that algorithm, if we choose most two cost effective data center for the requests to be processed, (if more than two data center in the same region) we can have better response time. However, the cost is increased compare to our proposed algorithm in section 5. We can also analyze that in the experiments in the next section.
6. Experiments & Results
ConfigurationTable 1. User Base Configuration
User base Name Region Request per user/hr Data Size per request (bytes) Peak hours GMT Avg. peak users Off peak users UB 1 2 60 100 3.00-9.00 1000 100
Table 2. Data Center Configuration DC Name DC1 DC2 DC3 DC4 DC5 Region 0 0 0 0 0 Vm per DC 5 5 5 5 5 Cost ($) per vm/hour 0.4 0.2 0.3 0.1 0.15
Simulation Duration: 24 hours
Table 3. Output
Figure 5. Cost comparison
From the outputs, as shown above (figure 5), we can observe that conventional service proximity based routing based on the random selection takes more cost compare to the proposed algorithm(1).
From the same figure, we can also observe that proposed algorithm (2) takes more cost than proposed algorithm(1) but less than the conventional algorithm.
Now as we can observe in the next figure (figure 6), Proposed algorithm (1) takes a very high data processing time compare to the conventional algorithm.
From the same figure (figure 6), we can observe that proposed algorithm (2) takes remarkable less time compare to the first proposed algorithm, however, it takes somewhat more time compare to the conventional algorithm.
Figure 6. Data Processing Time Comparision
So we can conclude from the experiments that proposed algorithm (1) gives more cost effective request routing but the data center processing time is higher than the closest data center. Proposed algorithm (2), with some modifications, gives better response time for the same configuration compare to the proposed algorithm (1) .
7. Conclusion and Future Work
From the experiments and results, we can conclude that proposed service broker policy works efficiently with respect to the cost for the data center selection. It can also be concluded that the processing time in the proposed algorithm (1) is higher than the closest data center algorithm but in the proposed algorithm (2), the processing time is improved.
In future, following can be done
1) To have optimized service broker policy.
2) To have new load balancing algorithms in the simulator.
8. References
[1] http://www.cloudbus.org/cloudsim : (Cloud Analyst can be downloaded from here)
[2] Rajkumar Buyya, Rajiv Ranjan, and Rodrigo N. Calheiros InterCloud: Utility-Oriented Federation of Cloud Computing Environments for Scaling of Application Services , The University of New South Wales, Sydney, Australia, 2010
0 20 40 60 80 100 120 140 160 Service Proximity Based Proposed Algorithm Proposed Algorithm(2) Overall Cost ($) 0.75 0.8 0.85 0.9 0.95 1 Service Proximity Based Proposed Algorithm Proposed Algorithm(2) Data Center Processing Time
Service Proximity Based Proposed Algorithm Proposed Algo.(2) Overall Cost ($) 142.91 117.70 121.30 D.C Processing Time 0.83 0.95 0.86
[3] Dejan Kovachev, Yiwei Cao and Ralf Klamma Mobile Cloud Computing: A Comparison of Application Models Information Systems & Database Technologies RWTH Aachen University, Aachen Germany 2010-2011 [4] Bhathiya Wickremasinghe CloudAnalyst: A
CloudSim-based Tool for Modelling and Analysis of Large Scale Cloud Computing Environments MEDC Project. 433-659 distributed computing project, csse dept., university of melbourne June 2009
[5] Bhathiya Wickremasinghe, Rodrigo N. Calheiros, and Rajkumar Buyya. CloudAnalyst: A CloudSim-based Visual Modeller for Analysing Cloud Computing Environments and Application. The Cloud Computing and Distributed Systems (CLOUDS) Laboratory, The University of Melbourne, Australia, 2009
[6] Dhaval Limbani and Bhavesh Oza, “A Proposed Service Broker Strategy in CloudAnalyst for Cost-Effective Data Center Selection”International Journal of Engineering Research and Applications, India, Vol. 2, Issue 1, Jan-Feb 2012, pp.793-797
