REDUCING THE COST OF VIRTUAL MACHINE MIGRATION IN FEDERATED CLOUD ENVIRONMENT USING COMPONENT BASED VM

MONICA GAHLAWAT¹*, PRIYANKA SHARMA^2
1Department of MCA, L.J. Institute of Computer Application, Ahmedabad, India
²Department of MCA, Institute of Science & Technology for Advanced Studies, Anand, Gujarat, India
* Corresponding Author : monica.gahlawat@yahoo.com

Received : 12-01-2012     Accepted : 15-02-2012     Published : 24-03-2012
Volume : 3     Issue : 1       Pages : 288 - 290
J Inform Syst Comm 3.1 (2012):288-290

Cloud computing refers a paradigm shift to overall IT solutions while lifting the accessibility, scalability and effectiveness through its enabling technologies. Due to the nature of widely distributed service providers in clouds, the service performance could be impacted when the network traffic is congested. This can be a major barrier for tasks with real-time requirements. In clouds, this problem can be solved by migrating services to different cloud platforms. This also involves cost because GBs & GBs of data is transferred over the network typically called Internet. The paper is focusing on reducing the cost of Migration using a component based VM (Virtual Machine) in which VM is not considered as a monolithic image but as a collection of various components like kernel, OS, Programs and user data.

Data Migration, Cloud Computing, Component Based VM, Virtual Machine, Service level Agreement, Quality of Service.

Cloud computing is rapidly emerging as a new paradigm for delivering IT services as utility-oriented services on subscription-basis. Although cloud computing has emerged mainly from the appearance of public computing utilities [1] , various deployment models, with variations in physical location and distribution, have been adopted. In this sense, regardless of its service class, clouds can be classified as public, private, or hybrid depending upon the model of deployment. Typical examples of companies providing public clouds include Amazon, Google, Microsoft, E-Bay, and commercial banks. Public cloud providers usually provide Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). Because the service providers in cloud are growing very fast, the selection of a particular service provider depends upon various factors like price, QoS (Quality of service), reputation, and customer service defined in SLA (Service level Agreement). The customers and service providers agree upon a minimum service level and non-compliance to such agreement may incur in penalties to providers and if the service level is not satisfactory and there is no tradeoff between service and cost then the customers can decide to choose another service provider by migrating there data from current service provider to new service provider. Virtual Machine Migration is recently emerged for migration of customer from one service provider to another.
The VM Migration process can be “hot” or “cold”. In “cold” migration the Process running on the source VM is suspended and the VM image is copied to the destination host and the VM on the destination host is restarted. In contrast in “hot” migration the migration takes place while the source VM continues to run. The service downtime is so less that the customer is not able to identify the down in service performance.
The paper is organized as follows. Section II provides an overview of the most adopted VM migration in both LAN and WAN and cost related to all the methods. Section III explains the component based VM and the advantages of component Based VM. Section IV derives the cost function for the component Based VM. Conclusion is presented in section V.

VM Migration consists of transferring a VM from source to destination host. Basically there are two kinds of Migrations:” hot” and “cold”. The hot migration is also called live migration. A number of studies have been conducted by the authors to propose various techniques for live migration. Timothy Wood et al. [2] propose a smart stop and copy mechanism to optimize WAN VM migration.David Brietgand, Gilad kutiel, Danny Raz [4] propose a method of measuring the cost of VM migration using MM1 queuing model independent of the method of migration (pre copy or post copy).Ranjan Pal, Pan Hui [3] also formulated a separate end-user demand function for each cloud provider w.r.t to price and QoS (Quality of service) levels set by them and derive their individual utility functions(profit function).
The cost of the VM live migration in a cloud environment is discussed in [5] , where the authors evaluate the effect of live migration on the performance of applications running inside Xen based VMs. Cloud federation implies the dynamic load management of VMs. In [6] a management algorithm is proposed that allows deciding about the reallocation of VMs in cloud contexts characterized by a large number of hosts. Such algorithm simply identifies some critical instances and takes decisions without recurring to typical thresholds. [10] highlights the difference between cloud and grid.

Modularization of a system is a basic technique for developing complex software. The complexity is reduced and at last the modules are integrated to get the final software. If the cloud environment is federated the VM can be considered as a collection of components (hypervisor format, kernel, OS, user data & programs). The cloud repository does not contain a set of VM disk-images anymore but a set of VM components. [9] It is analogous to usage of shared libraries. The [Fig-1] depicts an example of VM live migration between federated cloud providers A and B. In the figure we can see that we want to migrate a VM Q from source cloud to destination cloud which is composed of the components A,Z,C,D. Z is not available on destination cloud so only Z component needs to be migrated from source to the destination cloud which saves cost and time both. The cost of the live migration is directly related to the bandwidth. The shared bandwidth consumes part of the bandwidth used to serve clients and the remaining is used for the migration. If we talk about the cost of the live migration is the cost of bandwidth used and the time taken to serve the clients. SLA specifies the maximum time that is required to execute a specific query & SL (service level) is also specified in SLA that tells the percentage of requests that are being served within a particular time bound specified in SLA.

The cost of live migration includes the cost of bandwidth used for migration plus the cost of bandwidth used for the service of the users. Assume that the total bandwidth available (both for the migration process and for the service itself) is Ba and the migration process consuming Bam<= Ba of it, then the residual bandwidth utilized by the running service is Bas = Ba-Bam. Clearly, increasing Bam would speed up the migration process, but at the same time it will reduce Bas and thus may also reduce the service level during this time. We define the cost function F(Bas) to be the portion of the requests that are not satisfied by their deadline. In other words, if S denote the serving time of a request and tSLA denote the period, specified in the SLA, for a request to be served then we can say that: F(Bs) =P [ S > tSLA ] .
Queuing theory can be applied to variety of operational situations where it is not possible to predict accurately the arrival rate (or time) of the customers and service rate (or time) of service facilities (as in above situation). In particular, it can be used to determine the level of service (either the service rate or the number of service facilities) that balances the two conflicting costs: 1) cost of offering the service 2) cost incurred due to delay in offering service. [7]
To construct a first order approximation of response time and simplify the analysis, we consider M/M/1 model for the server. As our experimentation shows, this model is sufficient to gain insights into the problem. Denote by µ(Bs) the rate at which the server is capable of sending responses given residual bandwidth BaS, then µ(Bas) = Bs/Average Response Size. Denote by Ex(S) the expected serving time of a request, then, as known from the basic queuing theory, the probability that the time it takes to handle request is greater than aEx(S) is given by P [ S > aEx(S) ] = e-a where

Ex(S) = Expected Service time + Expected waiting time in system (1)
Ex(S) = 1/µ + Wq where Wq= λ/ µ(µ- λ). After solving the equation (1)
Ex(S) = 1/ µ- λ (2)
if tSLA = aEx(S) then F(Bas) = P [ S > tSLA ]
F(Bas)= e-tSLA/Ex(S)=e tSLA(λ-µ(Bs)) (3)

When a source cloud needs to migrate a VM into a destination cloud, three different situations may occur: the worst case, the average case, and the best case. In order to better clarify the ideas, we consider two clouds: source and destination. The source cloud wants to migrate three VMs: VM1, VM2, VM3. For each VM, we consider its respective composable block as a set of VM-com VM1 = {W,X,Y,Z}, comVM2 = {A,B,C,D}, and comVM3 = {A,B, G, F}. Moreover, we define the set CR = {A,B,C,D,H,I,L}as the VM-CMPs (Components) repository of the destination cloud. The “worst case” is when the destination cloud does not have within its repository any VM-Components for the local arrangement of the composable block ,therefore, it has to copy all the required VM-components from the source cloud repository. In such case the amount of storage transferred and the workload is the same of the storage access mechanism [9] , adopted for the VM disk image relocation over a WAN: the destination cloud has to copy all the VM-components in its repository, plus the user data block. An example is when the source cloud migrates VM1. Since VM1 − CR = {W,X, Y, Z}, the destination cloud has to copy the W, X, Y, Z “VM-Components” from the source cloud repository. The “best case” is when the destination cloud has in its repository all the required VM-Components, and it has only to copy the user data block. An example is when the source cloud migrates VM2. Since VM2 − CR = {∅}, the destination cloud does not have to copy any VM-Component from the source cloud. The “average case” deserves further considerations. It is when the destination cloud has in its repository only some of the required VM-Components for the locally composition of a given composable block and therefore it needs to obtain all the missing pieces. An example is when the source cloud migrates VM3. Since VM3−CR = {G, F}, the destination cloud has to copy only the G and F VM-Components from the source cloud. Considering a scalable federated cloud scenario, when a cloud joins the federation, initially, the average case is closer to the worst case because the cloud does not have a varied and stocked set of VM-Components in its repository. Instead with the experience gained over the time and by means of the “Self-Learning” due to the previous live migrations of VM from other source federated clouds, the VM-Component repository of the destination cloud grows up becoming always more varied and stocked. Therefore, for large scale scenarios, through the gained experience of each cloud, the average case becomes closer to the best case. The minimum and default size that is considered in Ubuntu and Fedora for VM is 8GB so we have done experiments for the transfer of 8GB with different Bandwidth. The time required to transfer 8GB of data is displayed in the table 1 and the cost function also changes with the amount that is not required to transfer from source machine to destination machine. Let Bλ is the bandwidth required for each component of the VM then the cost function will be as follows in best (eq 4), worst (eq 5) and average case (eq 6)
F(Bas)= e tSLA(λ-µ(Bs)) -3B λ (4)
F(Bas)= e tSLA(λ-µ(Bs)) -2B λ (5)
F(Bas)= e tSLA(λ-µ(Bs)) (6)
The equation (6) is same as (1) because this is the worst case cost function in which no component is available at destination cloud every component needs to migrate from source cloud to destination cloud.

Currently, the worldwide cloud computing scenario includes several independent cloud providers, but the last trend is the cloud federation, where providers will be able to exchange and share virtual resources with each other. The component based VM reduces the cost and time of transfer of data from source machine to destination machine in clouds. But the component repository should be modified continuously otherwise the benefits that can be gained from the component based VM is reduced.

[1] Buyya R., Broberg J. and Goscinski A. (eds) (1892) J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., 2. 68-73.  
» CrossRef   » Google Scholar   » PubMed   » DOAJ   » CAS   » Scopus  

[2] Jacobus van der Merwe Timothy Wood., Ramakrishnan K.K. and Prashant Shenoy (2011) International Conference on Virtual Execution Environments.  
» CrossRef   » Google Scholar   » PubMed   » DOAJ   » CAS   » Scopus  

[3] Ranjan Pal. and Pan Hui (2011) Economics of Cloud Markets.  
» CrossRef   » Google Scholar   » PubMed   » DOAJ   » CAS   » Scopus  

[4] David breitgand., Gilad Kuitel., Danny Raz (1989) 3rd Annual Haifa Experimental system conference.  
» CrossRef   » Google Scholar   » PubMed   » DOAJ   » CAS   » Scopus  

[5] Voorsluys W., Broberg J., Venugopal S. and Buyya R. (2009) Cost of virtual machine live migration in clouds: A performance evaluation, 254-265.  
» CrossRef   » Google Scholar   » PubMed   » DOAJ   » CAS   » Scopus  

[6] Andreolini M., Casolari S., Colajanni M. and Messori M. (2009)Dynamic load management of virtual machines in cloud architecture.  
» CrossRef   » Google Scholar   » PubMed   » DOAJ   » CAS   » Scopus  

[7] Sharma J.K. third edition faculty of Management Studies, 712-728.  
» CrossRef   » Google Scholar   » PubMed   » DOAJ   » CAS   » Scopus  

[8] File size Bandwidth Calculator, http://www.ibeast.com.  
» CrossRef   » Google Scholar   » PubMed   » DOAJ   » CAS   » Scopus  

[9] Antonio Celesti, Francesco Tusa, Massimo Villari and Antonio Puliafito Mathematics, Faculty of Engineering.  
» CrossRef   » Google Scholar   » PubMed   » DOAJ   » CAS   » Scopus  

[10] Foster I., Zhao Y., Raicu I. and Lu S. (2008) Grid Computing Environments Workshop, 1-10.  
» CrossRef   » Google Scholar   » PubMed   » DOAJ   » CAS   » Scopus  

	Fig. 1- component Based VM
	Fig. 2-