Cooperative Resource Management in a IaaS Giang Son Tran, Alain Tchana, Daniel Hagimont, Noel Depalma To cite this version: Giang Son Tran, Alain Tchana, Daniel Hagimont, Noel Depalma. Cooperative Resource Manage- ment in a IaaS. 29th International Conference on Advanced Information Networking and Applications (AINA 2015), Mar 2015, Gwangju, South Korea. pp. 611-618. hal-01343030 HAL Id: hal-01343030 https://hal.archives-ouvertes.fr/hal-01343030 Submitted on 7 Jul 2016 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Open Archive TOULOUSE Archive Ouverte ( OATAO ) OATAO is an open access repository that collects the work of Toulouse researchers and makes it freely available over the web where po ssible. This is an author-deposited version published in : http://oatao.univ-toulouse.fr/ Eprints ID : 15384 The contribution was presented at AINA 2015 : http://voyager.ce.fit.ac.jp/conf/aina/2015/ To cite this version : Tran, Giang Son and Tchana, Alain and Hagimont, Daniel and Depalma, Noel Cooperative Resource Management in a IaaS. (2015) In: 29th International Conference on Advanced Information Networking and Applications (AINA 2015), 24 March 2015 - 27 March 2015 (Gwangju, Korea, Republic Of). Any corresponde nce concerning this service should be sent to the repository administrator: staff -oatao@listes -diff.inp -toulouse.fr Cooperative Resource Management in a IaaS Giang Son Tran∗, Alain Tchana†, Daniel Hagimont†, and Noel De Palma‡ ∗University of Science and Technology of Hanoi, Vietnam. E-mail: [email protected] ∗University of Toulouse, Toulouse, France. E-mail: fi[email protected] †University of Grenoble, Grenoble, France. E-mail: [email protected] Abstract—Virtualized IaaS generally rely on a server con- operations lead to the management of what we call elastic solidation system to pack virtual machines (VMs) on as few VMs, i.e., VMs which size can be modified dynamically. servers as possible, for energy saving. However, two situations Such an approach requires cooperation between the applica- are not taken into account, and could enhance consolidation. First, since the managed VMs can be of various sizes (small, tion (customer) level and the provider level, as they impact medium, large, etc.), VMs packing can be obstructed when sizes management at both levels (a VM split or fusion initiated by don’t fit available spaces on servers. Therefore, we would need the provider modifies the architecture of the application and to ”split” such VMs. Second, two VMs which host replicas of the should therefore be taken into account at the application level). same application server (for scalability) could be ”fusionned” In this paper, we propose such an elastic VM cooperative when they are located on the same physical server, in order to reduce virtualization overhead and VMs memory footprint. scheme between the provider and the customer levels. In this Split and fusion operations lead to the management of elastic novel scheme, we consider master-slave applications where VMs and requires cooperation between the application level and a load is distributed by a master between a set of slaves. the provider level, as they impact management at both levels. The provider is aware of the set of VMs which host slave In this paper, we propose a IaaS resource management system applications. Thanks to this knowledge, the provider can which implements elastic VMs based on split/fusion operations and cooperative management. We show its benefit with a set of propose to the customer to split a slave VM when it could experiments. improve consolidation (better fit available spaces) and it can propose to the customer to fusion slave VMs when they are gathered on the same physical machine. This paper makes the following contributions: I. INTRODUCTION 1) a new resource allocation model in the cloud. Nowadays, many organizations tend to outsource the man- 2) a novel resource management vision which involves the agement of their physical infrastructure to hosting centers contribution of cloud customers. called cloud. A majority of cloud platforms implement the 3) a prototype which considers (1) and (2). Infrastructure as a Service (IaaS) model where customers buy 4) an empirical demonstration of the benefit of (1) and (to providers) virtual machines (VM) with a set of reserved (2) in terms of energy consumption and virtualization resources. This set of resource corresponds to a Service Level impacts on customers applications. Agreement (SLA) that providers are expected to guarantee. The rest of the article is organized as follows. Section II de- Both providers and customers aim at saving resources. They scribes the context of our work. Section III motivates our work. generally implement a resource manager which is responsible Sections IV-VI present our cooperative resource management for dynamically reducing the amount of used resource. At the model between the two layers. We evaluate and compare the level of the customer, such a resource manager allocates and effectiveness of this model in Section VII. After highlighting deallocates VMs according to applications’ needs at runtime various related works in Section VIII, we conclude and present to deal with different load situations and to minimize resource future works in Section IX. cost [1]. At the provider level, the resource manager relies on VM migration to gather VMs on a reduced set of machines II. CONTEXT (according to VMs’ loads) in order to switch unused machines Resource management is one of the most important tasks off, thus implementing a consolidation [8], [13] strategy. in cloud computing. Inefficient resource management has a However, two situations are generally not taken into ac- direct negative impact on performance and cost. Ensuring count, and could enhance consolidation. First, since the man- performance and effective use of resources is a challenge for aged VMs can be of various sizes (small, medium, large, both the provider and the customer. Resource management etc.), VMs packing can be obstructed when sizes don’t fit in a IaaS is mostly based on the allocation, relocation and available spaces on servers. Therefore, we would need to deallocation of VMs. The provider is responsible for managing ”split” such VMs. Second, two VMs which host replicas of the resources effectively to reach his goal: minimizing operational same application server (for scalability) could be ”fusionned” cost. To do this, the provider manages his physical servers and when they are located on the same physical server, in order allocated VMs at run time, by (1) relocating VMs (using VM to reduce virtualization overhead (which impacts applications live migration), in order to span as few servers as possible, performance) and VMs memory footprint. Split and fusion then (2) switching off or suspending the unused servers to save 500 :;<<+=>?@'* :;<<+$9>9@'* :;<<+$'* :;<<+$'* 1 Instance 1x(6 vCPU 2048MB) 450 2 Instances 2x(3 vCPU 1024MB) -AA9+D#EF>?@'* 3 Instances 3x(2 vCPU 667MB) -AA9+D#E?>@'* 400 -AA9+D#EF>?@'* -AA9+D#EF>?@'* 350 300 -AA$+D#E?>@'* -AA$+D#E?>@'* -AA$+D#E?>@'* 250 -AA9+D#EF>?@'* 200 #$ #9 #$% #$. 150 $&'*+,-# $&'*+,-# $&'*+,-# $&'*+,-# Response Time (ms) Response Time 100 50 :;<<+@'* :;<<+&'* :;<<+&'* :;<<+&'* 0 0 20 40 60 80 100 Request Rate (req/s) D#9EF'* D#=%E@'* D#FE$G'* D#=E$G'* Fig. 1. Overhead caused by Collocation of VMs serving the same Tier. D#$EH'* D#=.E@'* #$ #9 #F% #F. $&'*+,-# $&'*+,-# $&'*+,-# $&'*+,-# energy. On the customer side, allocated resources can also be Fig. 2. The Needs of VM Merging (top) and Splitting (bottom) managed: the more unused VMs, the more wasting for the customer. The objective for the customer is also to minimize operational cost. To achieve this goal, the customer tends to measure the application’s response time. Application response minimize the number and size of his allocated VMs, thanks time for each benchmark (with 1, 2, or 3 application instances) to an on-demand resource allocation policy [5]: it actively is summarized on Figure 1. From this figure, we can see that monitors the application load, detects underload and over- when the generated request rate is higher, a higher number of load situations and reconfigures the application accordingly. VMs for providing the same amount of resources has a higher In this paper we consider master-slave applications for the response time. These differences are due to the multiple VMs customer. Master-slave refers to a fundamental and commonly that can be merged when collocated. implemented pattern in distributed applications. It consists of In addition, merging VMs allows the provider to reduce re- a master component and multiple slave components, where source waste due to VMs footprint. Therefore, a consolidation the master distributes its workload (requests) between the process can result in non-optimal resource management. In this associated set of slaves. The slaves execute the received situation, merging VMs can be of great interest. Figure 2 top requests and return the results to the master. A typical web shows an example where a VM of application 2 is migrated applications in Java Platform Enterprise Edition (JEE) is a from PM2 to PM1 (where another VM of application 2 runs), popular example of a master-slave architecture. Each of its tier so that the provider can shutdown or suspend PM2. (web, application and database) is replicated. Such a replicated The consolidation process can also result in a situation architecture is a means for implementing scalability by cloud where there would be enough available free memory to further users in order to dynamically add or remove tier instances consolidate, but this free memory is fragmented over several according to the load.