Use of Reactive and Proactive Elasticity to Adjust Resources Provisioning in the Cloud Provider

Transcription

1 6 IEEE 8th International Conference on High Performance Computing and Communications; IEEE 4th International Conference on Smart City; IEEE nd International Conference on Data Science and Systems Use of Reactive and Proactive Elasticity to Adjust Resources Provisioning in the Cloud Provider Raouia Bouabdallah Higher Management Institute of Tunis Tunis University Tunisia Soufiene Lajmi Higher Institute of computer science and multimedia of Sfax Sfax University Tunisia Khaled Ghedira Higher Management Institute of Tunis Tunis University Tunisia Abstract Elasticity is the most important feature that differentiates cloud computing from traditional IT infrastructure. It defines the capacity of cloud infrastructure provider to accelerate the provision or the deprovision of the resources needed to deploy client s services. Auto-scaling resource is typically done using two models: reactive and proactive. Most previous researches manage elasticity with a single model (reactive or proactive) in isolation without taking into account the combination of both. In this context, this paper presents the ElasticCloud system used to manage elasticity in the cloud provider. This system proposes a hybrid methodology that incorporates a reactive elasticity coupled with a proactive elasticity to, respectively, scale up and scale down resources running a web application hosted in the cloud. We evaluate the efficiency of our methodology through a set of experiments with a testbed based on a cloud management system and a synthetic workload. We have proved that our methodology reduces the number of CPU bottlenecks, the scale down mistakes and the scale operations compared to existing elasticity approaches. Index Terms Cloud Computing, Cloud Infrastructure Provider, Reactive Elasticity, Proactive Elasticity, Multi-Agent System (MAS). I. INTRODUCTION As defined by NIST [] "Cloud computing is a model for enabling ubiquitous, convenient and on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction". It appears from NIST definition that elasticity is a key feature to characterize the cloud computing from the traditional Information Technology (IT) infrastructure. It defines the ability of the cloud infrastructure provider to change rapidly the amount of allocated resource capacity, over time, according to the actual users requests. The horizontal elasticity [] in the cloud infrastructure provider refers to the ability to increase (scale up) or decrease (scale down) the number of allocated virtual machine instances needed to run an application in the cloud provider. Running a web application in the cloud infrastructure provider with the minimum resource allocation and the maximum utilization is a complex issue still far from being resolved. The web application traffic is highly dynamic. It is difficult to manually determine the resources required by the application for two main reasons: on the first hand, it is hard to overcome bottleneck situations, especially, the CPU bottleneck which results in the slow workload and a plenty of almost all internal processing (under-provisioning). on the other hand, it is tough to estimate the optimal resource running the web application (over-provisioning). The auto-scaling approaches try to resolve this difficulty. These approaches are grouped into two models []: reactive and proactive. The reactive model reacts to the observed workload changes. However, the proactive model reacts to the predicted workload changes. This paper proposes the ElasticCloud system used to manage the horizontal elasticity in the cloud provider. Our methodology to resolve the CPU bottleneck is purely based on a reactive model, which is the mean to speed enough in order to scale up the web application and make it nearer as possible to the real workload. In order to optimize the resources required by the web application, we have developed a proactive model to scale down its infrastructure whenever possible to minimize its resources utilization. The remainder of this paper is organized as follows. In section II, we discuss the related work. An overview of the ElasticCloud architecture is detailed in section III. Then, section IV presents our approach describing a hybrid methodology to adjust resources provisioning in the cloud provider. Next, section V implements a prototype to evaluate the efficiency of the proposed approach. Finally, section VI deals with the conclusion and the prospects of this work. II. RELATED WORK This section presents some of the researches interested in an hybrid elasticity (reactive and proactive models) to adjust the resources provisioning in the Cloud. For instance, the authors in [4] propose a hybrid methodology of elasticity (reactive and /6 $. 6 IEEE DOI.9/HPCC-SmartCity-DSS.6. 55

2 proactive models) for an automatic resolution of bottlenecks in the web application to satisfy the response time requirement. The bottleneck resolution method is reactive to dynamically scale up the resources required by the web application. When the allocated resources are not required during a period of time, a proactive model, based on time series analysis approach, has been developed using the polynomial regression method to scale down the resources whenever possible. The authors, in [5], propose a hybrid elasticity controller that combines reactive and proactive models for scaling the cloud resources in order to meet the SLA. The authors model the proactive model by using a queering theory to scale down the resources and use the reactive model to scale them up. However, this work does not clearly define a reactive model, it just bases its reactive model on a previous elasticity work. Moreover, the proposed proactive model uses the number of requests served per time unit as a controller parameter instead of the hardware parameter such as CPU usage and memory. Furthermore, the evaluation of this hybrid elasticity controller is based on a simulation which uses a traffic data set made to the 998 world cup website. This simulation does not integrate any Cloud Management System (such as Openstack and Opennebula) to allocate and release the resources. The authors, in [6], propose a hybrid methodology that contaminates the predictive and the reactive models to allocate the resources required by the application using a queering theory. The predictive method is used over long time scales such as hours and days. Whereas, the reactive model is used over short time scales such as seconds and minutes to overcome the flash crowds event and correct the predictive model mistakes. However, the proposed methodology is not addressed to release the resources running the application to optimize their utilization. Furthermore, this work is based on Xen as a virtual machine monitor instead of a Cloud Management System in its prototype. In contrast, our methodology allocates the resources by using reactive model to avoid the bottleneck situation and release resources by using proactive model to minimize their utilization over a Cloud Management System (CMS) [7]. In this paper, we describe our approach based on reactive and proactive elasticity to adjust provisioning resource running web application in the cloud provider. For these purposes, we present, first, the general organization of the ElasticCloud system. Second, we propose a hybrid methodology RU-PD (Reactive scale-up - Proactive scale-down) incorporating a reactive model to identify the CPU bottleneck coupled with a proactive model to estimate the over-provisioning. III. AN OVERVIEW OF THE ElasticCloud ARCHITECTURE Figure depicts an overview of the ElasticCloud architecture used to improve the horizontal elasticity by provisioning resources in the cloud provider. A. ElasticCloud actors The ElasticCloud system takes into consideration three main actors which are: the client, the user and the cloud provider. Client Elas c Interface Web Portal Manager agent Analyzer agent Make decision Monitoring agent WA VM Monitoring agent WA VM Cloud Registry Execute IAAS LB VM Users Fig. : An overview of the ElasticCloud architecture Client: represents the entity in need to manage the resources of his web application, which he pays only for his use. User: represents the entity that wants to communicate with client application instances, through Load Balancing (LB), by initiating HTTP requests. A set of users perform the workload of the application. Cloud provider: is the entity providing physical computing resources as a service to clients in the form of VMs. In order to provide the same features found in commercial cloud providers, we use a Cloud Management System (CMS) [7] to perform the operations needed to deploy the VMs hosted on the Infrastructure as a Service (IaaS) cloud provider. Furthermore, we have introduced a new layer called Elastic Interface (EI). This layer is put on each cloud provider wanting to monitor its resources. B. ElasticCloud components ElasticCloud components are mainly distributed into two parts (as shown in Figure ): First, a set of components focused on the Elastic Interface (EI) layer, which collaborate together to adjust the resources provisioning in the cloud provider. Second, a Monitoring agent deployed locally on each VM instance running the Web Application (WA) to collect data (measurement) about the managed resource status. A Load Balancing (LB) is used to guide the HTTP users requests into various web application instances. Moreover, the LB adjusts the resources by increasing and decreasing the number of VMs without requiring an infrastructure change. Our proposed EI layer has the following components: Web Portal, Cloud Registry (CR), Analyzer and Manager agents. Web Portal allows 56

3 the client to access to our EI layer. It helps him introduce his request. Cloud Registry (CR) creates a storage zone to keep monitoring information about the allocated resources of each client. Analyzer and Manager agents have been used to automatize the interaction of a problem solving related to adjusting resources provisioning in the cloud provider. IV. HYBRID METHODOLOGY OF ELASTICITY IN THE CLOUD PROVIDER We propose a hybrid methodology RU-PD (Reactive scale- Up - Proactive scale-down) to absorb respectively the over and the under provisioning of resources running a web application in the cloud provider. Our methodology helps the cloud provider to retreat the web application to its normal operating state and avoid its CPU bottleneck s resources in case the deployed web application lacks resources to treat all the users requests. The reactive model is applied to scale up the web application established by means of threshold-based rules. In case the web application runs in a normal operating state during an underlying time interval which satisfies the CPU usage performance metric, the proactive model has been used to identify the coming over-provisioning when the web application has more resources than its real need. The proactive model is applied to anticipate the CPU utilization over a time interval. Based on this anticipation, the scale down action is performed. We use a Multi-Agent System (MAS) [8], to deal with the concept of MAPE-K loops (Monitoring, Analyze, Planning, Execution and Knowledge ) [9] []. We describe, below, the agents involved in our methodology based on MAPE-K loops and their interactions. A. Monitoring agent The Monitoring agent represents the first phase of MAPE-K loops (Monitoring phase). This agent runs within the resource that deploys the web application. It collects, every time, data about CPU usage performance metric which describes the workloads resource consumption. Then, it sends this data to the EI layer, where, the Analyzer agent processes and analyzes it. The Monitoring agent uses SIGAR library [9] as a monitoring tool to measure the CPU Usage metric of the resource. B. Analyzer agent The Analyzer agent represents the second phase of MAPE- K loops (Analyze phase). It interferes the analyze of the data collected from the Monitoring agent about the current CPU utilization of the resource. This analysis includes reactive and proactive models. ) Reactive model for scale-up: The Analyzer agent applies threshold-based rules [] to perform the reactive model. So, it receives the CPU elasticity rule defined by the client. This rule is based on an event-condition-action approach. It has the following structure: If m(cpu)> thr(cpu) for dur(cpu) seconds then n(vm) = n(vm) + wait for T seconds The event defines the performance metric to be monitored. In our case CPU usage metric (m(cpu)). This metric is gathered with a specific threshold value (thr(cpu)) for a given time interval (dur(cpu)) to define a condition. The time interval is used to avoid oscillation which occurs when the scale-up action is performed too quickly. All the metrics sent by the Monitoring agent are continuously analyzed and checked respectively to the defined condition. When the condition is met, it might be necessary to perform an action (n(vm) = n(vm) + ). So, the Analyzer agent forwards the CPU elasticity rule to the Manager agent which aims to add an instance of a VM running web application. In this case, the Analyzer agent might wait for a given time (T) before restarting the analysis of the targeted condition. This time is taken to start a new VM, which is operated by the Manager agent. ) Proactive model for scale-down: The Analyzer agent applies the proactive model based on a time series analysis technique [] to scale-down the resources running a web application. This technique is a sequence of observations (or data points) collected at different dates to forecast the future value. The Analyzer agent collects, during a W time interval, a list of data about the CPU usage metric M(CPU) (where N is the length of the list) taken by the Monitoring agent. Where t is the current time step. The list of data is presented as follows: M(CPU)={m(CPU) t,m(cpu) t,..., m(cpu) t N+ } () The Analyzer agent uses the Simple Exponential Smoothing (SES) method of the list M(CPU) to make the forecasted value. This method is chosen for the list M(CPU) because this list has no significant trend changes [4]. The Analyzer agent calculates both the forecasted value for the time step t+ based on the current observation and the forecasted value for the time step t (the previous forecasted value). The following formula gives the simplest form of the simple exponential smoothing: f(cpu) t+ = α m(cpu) t +( α) f(cpu) t () The SES method depends on the smoothing factor, where its value is between and (< α <). In order to choose the best appropriate smoothing factor value of our list M(CPU), the Analyzer agent looks to optimize the Mean Square Error (MSE), which is calculated as follows: MSE = N N (f(cpu) t m(cpu) t ) () t= The Analyzer agent assigns α values from. to.9, with. step, {.,.,...,.9} and selects the value that provides the smallest MSE. The selected α is used to calculate the forecasted value. When the forecasted value of the CPU usage metric in under a threshold defined by the client, the Analyzer agent refers to the Manager agent, which looks to remove an instance of a VM running the web application. 57

4 C. Manager agent The Manager agent represents the two last phases of MAPE- K loops (planning and execution phase). It takes the decision in the ElasticCloud system to plan how to allocate (scale up) and release (scale down) resources for the web application. This decision deals with reactive and proactive models. ) Reactive model for scale-up: The Manager agent takes the decision in the reactive model to plan how to allocate (scale up) a new VM for the web application in order to avoid the CPU bottleneck. This decision is made regarding the CPU elasticity rule obtained from both the the Analyzer agent and the availability of a VM in the cloud infrastructure. An example of the elasticity rule: "add one instance of VM when the CPU usage is greater than 8% for a period of minutes and then wait for minutes". To treat this rule, the Manager agent checks, with the Cloud Registry (as a Knowledge in the MAPE-K loop), the availability of a VM. If it is the case, the Manager agent refers to the Cloud Management System (CMS) which initially deploys the web application into two VM instances: one is running and the other is suspended (not running). When the Manager agent needs to scale up the resource, it starts this suspended VM and creates a new suspended one. This technique can hugely optimize the waiting time T defined in the rule structure. After that, the Manager agent turns to the load balancing to associate the network address of the underlying VM and updates the cloud provider capacity described in the Cloud Registry. ) Proactive model for scale-down: In the proactive model, the Manager agent takes the decision to remove a VM running the web application. Thus, the Manager agent turns to the Cloud Management System (CMS) to release the underlying VM. Next, the Manager agent configures the load balancing and updates the cloud provider capacity described in the Cloud Registry. V. PERFORMANCE ANALYSIS In this section, we implement a prototype to prove the efficiency and the effectiveness of our approach through four experiments. The first one (Experiment ) is aimed to identify the appropriate value factors of the reactive and the proactive models. The second experiment (Experiment ) is carried out to prove how our hybrid methodology (RU-PD) is performed to scale up and scale down resources. The third one (Experiment ) is designed to compare our methodology with different possible elasticity approaches combining the reactive and the proactive models. The last one (Experiment 4) is realized to evaluate the efficiency of our hybrid methodology of elasticity compared to an existing one proposed by Iqbala et al.[4]. A. Experiment setup The experiments presented in this section were carried out by a physical node composed of.4 GHZ processor with GB of memory and TB of data storage. The underlying physical node uses Open Nebula 4. platform, as a Cloud Management System (CMS), running in CentOS 6.5 (Linux). These experiments are implemented using JADE platform (Java Agent Development Framework) [] to deal with distribution. To implement the LB component, we use Pound [] as a HTTP load balancer to distribute the users traffic across the web application instances. B. Workload generation We generate the workloads of our experiments using httperf [4] which is a web server performance tool dedicated to generate and measure the HTTP workload. In all our experiments, we make a specified workload with the number of users requests, issued per second, to measure the CPU usage performance metric of the web server running web application. This workload varies during ninetime interval ( from Interval (I) until Interval 9 (I9)) as shown in Figure. We perform, also, all of our experiments based on a Web application which consists of a JSP web page. I I I4 I6 6 I I I I7 I C. Performance metrics Fig. : The workload generation. This section deals with the experiments input data. Each virtual machine, used in the four previously mentioned experiments, runs on CentOS 6.5 with Apache Tomcat v7 web server and has the following hardware configuration: CPU with GB of RAM and 5 GB of disk. This VM deploys the web application as well as the Monitoring agent which frequently sends the CPU usage of the resource every 5 s. This value is taken by [5] and [6] to monitor cloud resources. In all the experiments, we initiate with one VM to monitor the CPU usage of the resource running the web application. we consider in these experiments both the reactive and the proactive models to scale-up and scale-down of resources. In the reactive model, we give 85% value [7] to the threshold CPU saturation (thr(cpu)=85%). This value allows the system to treat unexpected workload changes by scaling up the resources. In the proactive model, we put 5% value [8] as an under threshold to optimize the resources required by the web application. Our system needs s to locally add a new VM (T= s). This time includes the restart of the suspended VM and the configuration update of the load balancing. 58

5 Number of CPU bottlenecks Proactive time interval (P, P7 and P) (a) Number of CPU bottlenecks R R Number of scale up operations n R R 7 Proactive time interval (P, P7 and P) (b) Number of scale-up operations Number of scale down operations R R 7 Proactive time interval (P, P7 and P) (c) Number of scale-down operations Scale down mistakes R R The average used CPU (%) R R Proactive time interval (P, P7 and P) 7 (d) Number of scale-down mistakes 7 Proactive time interval (P, P7 and P) (e) The used average of CPU Fig. : The different value factors of the reactive and the proactive models. Experiment is performed to provide different value factors to reactive and proactive models. These factors are dur(cpu) and N. However, in experiments, and 4, these factors are fixed to dur(cpu)=5 s for the reactive model and to N=7 for the proactive model. D. Simulation results This section describes the results of the mentioned experiments. ) Experiment : It is realized to identify the appropriate value of the important factors of the reactive and the proactive models for our hybrid methodology RU-PD. These factors are dur(cpu) and N. dur(cpu) defines the satisfaction duration of the threshold value condition in the reactive model. N defines the number of collected sequences of observations in the proactive model. We refer to R, R and as the different reactive models which take, respectively, dur(cpu)= s, 5 s and 9 s. However, we refer to P, P7 and P as the different proactive models with N=, 7 and respectively. In order to compare between these different reactive models and proactive models for our hybrid methodology, we monitor and sum the number of CPU bottlenecks that occur over the workload, the number of scale (up and down) operations, the number of scale-down mistakes (in case the system scale-in quickly the resources in the drop of the workload) and the used average of CPUs over the workload. Figure shows the result of this comparison. It is clear from Figure that the highest value factor of the reactive model () increases the number of CPU bottlenecks, regardless of the values of the proactive model factor, compared to R and R reactive models. The smallest value factor of reactive model (R) shows generally the small number of CPU bottlenecks, because the system reacts quickly to every increase in the workload. This conducts, on the one hand, to rise the number of scale-up and scale-down operations, thus, to oscillate the system. On the other hand, it increases the number of scale-down mistakes compared to R and reactive models which take a mature decision. The highest value factor of proactive model (P) shows the smallest number of scale-down operations, especially R-P and R-P approaches which have no decrease in resources. This may lead to an over-provisioning of the infrastructure running the web application as shown in R-P where the average of its CPU usage is under 5%. With the smallest value factor of proactive model (P), the system releases quick resources to every instantaneous decrease in the workload and reallocates them again when the workload s CPU usage rises which increases the number of scale-down mistakes and the number of scale(up and down) operations. An important issue related to the number of scale operations is that they can damage the hardware (mainly the disk driver) [7] and cause the CPU bottlenecks that can increase the used average of the CPU. In our work, we selected the approach R-P7 which fixed the value factor of reactive model to dur(cpu)=5s and the value factor of proactive model to N=7. As depicted in Figure, this approach has the third smallest number of CPU bottlenecks with no scale-down mistakes and a reasonable number of scale-up and scale-down operations. ) Experiment : Experiment evaluates the CPU usage of the VM running the web application, over a time interval, using our hybrid methodology RU-PD. The analysis of Figure 4 shows that the CPU usage of the VM varies in a fourtime period. The first one begins from the start of traffic workload to just before the CPU. In this period, the underlying VM has not yet been busy (the CPU usage is under 85%). The second one during the CPU bottleneck detection, in this 59

6 period the CPU usage is overused. It reaches %, which means the deployed web application exploits the entire VM capacity ranking its maximum. In this situation, the web application lacks resources to treat all the users requests. This causes a poor performance and consequently loss of its future users. When the system detects that the CPU usage is over 85%, the reactive model is performed. The system waits 5 s (dur(cpu)=5 s) before adding a new VM, which takes s to get started and become available to the users. The third period begins with the CPU bottleneck resolution. During this period, the web application is deployed on more than one VM. The proactive model is applied. In case the CPU usage is underused (under 5%) as shown in Interval 7 of workload, the web application does not exploit the entire resources. This underutilization is justified by few users who are using the web application in this period. This decreases the web application profitability. For this reason, the adoption of our proactive model can increase the profitability and identify the overprovisioning when the web application has more resources than its real need. The system anticipates the CPU usage during 5 seconds to estimate the predicted value using SES method, whenever this CPU usage predicted value is around 5%, the scale-down action is performed to release the starting VM. For example, to anticipate the CPU usage during the period 5s-45s of the workload, the system calculates the predictive values, based on the actual observed values of the CPU usage using the SES method with different smoothing factor values from. to.9 {.,.,...,.9}. Our goal is to use the actual CPU usage data to make guesses about the best smoothing factor value to achieve a good estimation. Then, it calculates the MSE to measure the average squared difference between the observed values and the predicted ones, to evaluate the error rate of the predicted ESE values set for the smoothing factor value. Finally, it selects the smoothing factor value that provides the smallest MSE Second period Second period First 9 period Third period Third period Fig. 4: The CPU usage over the workload. ) Experiment : In this experiment we compare our hybrid methodology RU-PD with different possible scenarios combining the reactive and the proactive models. Figures 5(a), 5(b), 5(c) and 5(d) show the different elasticity approaches to monitor the workload s CPU usage (presented in Figure ) of the web server running the web application. These approaches are RU-RD (Reactive scale-up - Reactive scale- Down), PU-PD (Proactive scale-up - Proactive scale-down), PU-RD (Proactive scale-up - Reactive scale-down) and RU- PD (Reactive scale-up - Proactive scale-down). The RU-RD approach, seen in Figure 5(a), successfully absorbs the increase of users requests due to its reactive scaleup behavior. However, the scale down of these resources is not mature enough to reduce any oscillations that occur when the scaling-down action is carried out too quickly, before being able to realize the impact of this scaling on the application []. For example, this approach releases the resources when there is a decrease in the workload s CPU usage, as shown during Interval, and reallocates them again once the workload s CPU usage rises. This premature release is due to the reactive model behavior which rapidly reacts to the instantaneous fall of workload s CPU usage. The PU-PD approach, shown in Figure 5(b), performs the proactive model for both scaling-up and scaling-down the resources. It is clear, during Interval 5, that this approach is unable to handle unexpected workload rises. he prediction of a peak workload, due to flash crowds which usually happen in Internet applications, is performed badly. The goal of the proactive model is to take decisions to adjust the resources over long-term workload variations [6]. The PU-RD approach, presented in Figure 5(c), performs the worst performance to adjust cloud resources. It gathers the disadvantages previously mentioned in RU-RD and PU- PD approaches when a proactive model is used to scale up and a reactive model is used to scale down resources [5]. In Figure 5(d), we show the performance of our RU-PD elasticity approach. During Interval and Interval 5 of the workload s CPU usage, the reactive model successfully scale up the resources, after waiting 5 seconds to avoid oscillation, to deal with the CPU bottleneck coming with a peak workload. When The CPU usage is underused, as shown during Interval 7, due to the decrease of the number of users requests. The scale down, of these resources, is not instantaneous. This is based on the proactive model which reposed its decision on the history of the workload s CPU usage. We monitor the number of CPU bottlenecks, scale (up and down) operations and scale-down mistakes of these elasticity approaches and we conclude, regarding Table I, that our approach RU-PD has the best results compared with the other approaches. However, our approach comes sometimes with the cost of some over-provisioning because the decrease of the resources running the web application is not instantaneous. The second best result is provided by RU-RD approach which occurs with a less cost compared to our approach. The RU- RD approach releases the resources when there is a drop in the workload s CPU usage which decreases the cost of the resources. 4) Experiment 4: We compare our elasticity approach with an existing hybrid elasticity approach provided by Iqbala et al.[4]. This approach comes up with a proactive model to estimate the over-provisioning of the resources coupled 6

7 (a) RU-RD approach (b) PU-PD approach (c) PU-RD approach (d) RU-PD approach Fig. 5: Comparison between different elasticity approaches TABLE I: Comparison between different elasticity approaches. Approaches RU-PD RU-RD PU-PD PU-RD Scale-down mistakes Scale-down operations 4 Scale-up operations CPU bottlenecks with the reactive model to react to the under-provisioning of the resources hosted by a web application in the cloud. The proactive model, proposed in this work, is based on a polynomial regression method with two degrees recalculated every time a new measurement is detected. We denote RU- PDPR and RU-PDevery-time as hybrid elasticity approaches which respectively recalculated polynomial regression method and our experiential smoothing method every time a new observation is collected during a time interval. Our goal is to compare these approaches with our RU-PD approach, which recalculates exponential smoothing method once during a time interval. Figure 6 shows the workload s CPU usage and the required number of virtual machines for each one of theses approaches(ru-pd, RU-PDPR and RU-PDevery-time). To evaluate the results shown in Figure 6, we sum the number of scale(up and down) operations and the number of scale-down operation mistakes as well as the number of CPU bottlenecks (as depicted in Table IV). Figure 6 and Table II show that the amount of scale-up and scale-down operations as well as scaledown mistakes of RU-PDPR approach are higher compared to those obtained from RU-PDevery-time approach and our RU-PD approach. Furthermore, the CPU bottlenecks of RU- PDPR approach are more than those of the other. The RU- PDPR approach based on polynomial regression as a proactive model shows the worst results compared to other approaches which applies Exponential smoothing method as a proactive model. It is clear, from the result depicted in Table II, that the scale down of resources by using the polynomial regression method is not mature to reduce the oscillation of the system. This method releases quick resources to instantaneous fall in workload s CPU usage that causes to increase the number of CPU bottlenecks. TABLE II: Comparison with an existing approach. RU-PD RU-PDPR RU-PDevery-time Scale-down mistakes 4 Scale-down operations 7 Scale-up operations 7 4 CPU bottlenecks 4 5 VI. CONCLUSION In this paper, we have proposed the ElasticCloud system to manage elasticity in the cloud provider. So, we have intro- 6

8 (a) RU-PD approach (b) RU-PDevery-time approach Fig. 6: Comparison with an existing approach (c) RU-PDRP approach. duced a new layer within the cloud provider named "Elastic Interface" designed to monitor the resources using Multi- Agents System (MAS). The ElasticCloud system proposes a hybrid methodology RU-PD that incorporates a reactive model coupled with a proactive model. The reactive model is applied to resolve the CPU bottlenecks by scaling up the web application. In order to optimize the resources required by the web application, we have developed a proactive model to scale down the infrastructure whenever possible in order to minimize the resources utilization. Four experiments have been realized to evaluate the benefit of our approach. First, an experiment is intended to identify the appropriate value factors of the reactive and the proactive models. Second, an experiment is carried out to prove how our hybrid methodology (RU-PD) is performed to scale-up and scale-down the resources. Third, an experiment is dedicated to compare our methodology with different possible approaches of elasticity combining reactive and proactive models. Finally, an experiment is realized to evaluate the efficiency of our hybrid methodology of elasticity compared to an existing one proposed by Iqbala et al.[4]. In future work, we plan to extend our system to support multi-tier web application running across federated cloud providers. This system is based on peer-to-peer cloud federation architecture. This architecture consists of a set of cloud providers which voluntarily collaborate with each other to improve the horizontal elasticity by provisioning resources not only from a single cloud but also from multiple ones. [5] A. Ali-Eldin, J. Tordsson, and E. Elmroth, An adaptive hybrid elasticity controller for cloud infrastructures, in IEEE Network Operations and Management Symposium,. [6] B. Urgaonkar, P. Shenoy, A. Chandra, P. Goyal, and T. Wood, Agile, dynamic provisioning of multitier internet applications, 8. [7] W. Iqbal, M. N. Dailey, D. Carrera, and P. Janecek, Adaptive resource provisioning for read intensive multi-tier applications in the cloud, Future Generation Computer Systems, vol. 7, no. 6, pp ,. [8] P. C. Chao and H. M. Sun, Multi-agent-based cloud utilization for the {IT} office-aid asset distribution chain: An empirical case study, Information Sciences, vol. 45, pp ,. [9] M. Ryan and M. Doug, SIGAR - System Information Gatherer And Reporter,. [] F. Soodeh, J. Pooyan, B. L. Ewnetu, B. Ivona, and E. Erik, A hybrid cloud controller for vertical memory elasticity: A control-theoretic approach, Future Generation Computer Systems, vol. 65, pp. 57 7, 6. [] H. Paul, Autonomic computing : Ibm s perspective on the state of information technology, in IBM,. [] L. Fabio, C. Giovanni, and G. Dominic, Developing Multi-Agent Systems with JADE. WILEY, 7. [] Pound, POUND - REVERSE-PROXY AND LOAD-BALANCER. [Online]. Available: web site: [4] M. David and J. Tai, httperf: A tool for measuring web server performance, in Internet Server Performance Workshop, 998. [5] Cloudera, Cloudera Manager Introduction, 5. [6] C. Analytics, Application Performance Management for Cloud,. [7] A. John, The Art of Capacity Planning: Scaling Web Resources. O Reilly Media, 8. [8] S. Luke, Day 99: Creating Highly Available Servers in AWS, 4. REFERENCES [] F. Liu, J. Tong, J. Mao, R. Bohn, J. Messina, L. Badger, and D. Leaf, National Institute of Standards and Technology Special Publication, September. [] M. Sedaghat, R. F. Hernandez, and E. Elmroth, A virtual machine re-packing approach to the horizontal vs. vertical elasticity trade-off for cloud autoscaling, in Proceedings of the ACM Cloud and Autonomic Computing Conference,, pp. 6: 6:. [] L. Tania, M. A. Jose, and A. L. Jose, A review of auto-scaling techniques for elastic applications in cloud environments, Journal of Grid Computing, vol., pp , 4. [4] W. Iqbal, M. N. Dailey, D. Carrera, and P. Janecek, Adaptive resource provisioning for read intensive multi-tier applications in the cloud, Future Gener. Comput. Syst., vol. 7, no. 6, pp , jun. [Online]. Available: 6