An Architecture for Providing Elasticity Based on Autonomic Computing Concepts Emanuel F. Coutinho
Paulo A. L. Rego
Federal University of Ceará Virtual University Institute (UFC VIRTUAL) Fortaleza, Ceará, Brazil
Federal University of Ceará Master and Doctorate in Computer Science (MDCC) Fortaleza, Ceará, Brazil
[email protected] Danielo G. Gomes
[email protected] José Neuman de Souza
Federal University of Ceará Teleinformatics Engineering Department (DETI) Fortaleza, Ceará, Brazil
Federal University of Ceará Master and Doctorate in Computer Science (MDCC) Fortaleza, Ceará, Brazil
ABSTRACT
should expand their resources without loss of QoS (Quality of Service) or SLA (Service Level Agreement) violation. The monitored computing resources, such as CPU, memory and bandwidth, become essential for providers, services administrators, and its customers. One way to evaluate an environment is monitoring its resource utilization. Often the elasticity is associated to a resource of the provider. For example, in Amazon EC2, the customer may be using an instance with few resources, that are monitored through tracking service (Cloud Watch). When more resources are needed, the customer can use the scheduling service (Auto Scaling), through the load balancing service (Elastic Load Balance) to increase the amount of instances. One way to monitor cloud applications more effectively is to use mechanisms of autonomic computing to add and remove resources to the environment according to pre-established thresholds.
CCS Concepts
R
A
F
Elasticity is a feature quite important for cloud computing and it is related to how a system autonomously adapts its capacity over time to fit the workload variation. In this context, this paper proposes an elastic architecture for cloud computing based on autonomic computing concepts, such as control loops and thresholds-based rules. In order to validate the proposed solution, we designed two experiments that use microbenchmarks on private and hybrid cloud environments. The results show cloud computing and autonomic computing may be leveraged together for elasticity provisioning.
[email protected]
T
[email protected]
Keywords
D
•Networks → Cloud computing; •General and reference → Metrics; •Social and professional topics → Quality assurance;
Cloud Computing; Elasticity; Autonomic Computing; Metrics; Performance Analysis
1.
INTRODUCTION
With an increase in cloud services availability and their easy accessibility, it is natural that the number of users and workloads also grow. Consequently, cloud services providers Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’16, April 4-8, 2016, Pisa, Italy
Copyright 2016 ACM 978-1-4503-3739-7/16/04. . . $15.00
http://dx.doi.org/xx.xxxx/xxxxxxx.xxxxxxx
An autonomous or autonomic system consists of a set of autonomous elements. An autonomous element is a component responsible for managing its own behavior in accordance with policies, and interact with other autonomous elements that provide or consume computational services [11]. Mechanisms of Autonomic Computing, such as control loops and rules, can be used in monitoring of a computational cloud. Thus, resources can be added and removed from the environment as pre-established thresholds. This type of monitoring strategy is directly associated with one of the main characteristics of cloud computing: elasticity. According to the National Institute of Standards and Technology (NIST) definition, resources can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand [13]. Elasticity can be defined as the degree to which a system is able to adapt to changes in workloads by resources provisioning and unprovisioning in an autonomic manner, so that at each point in time the available resources combine with the demand of workload as close as possible [9]. Thus, elasticity is becoming a growing need due to the dynamic nature of different applications and diverse workloads. A
Auto-scaling is a key feature in cloud responsible for adjusting the number of available resources to meet service demand [14]. This feature is generally used in architectures and experiments. Several architectures for SLA provisioning and maintaining using autonomic computing features in computational clouds have been proposed [19, 21, 6, 3, 2]. However, given the wide diversity of technologies and limited availability of information on their correct installation and configuration for the experimental setup, the implementation of such architecture is not trivial, even further in cloud. This paper aims to propose an architecture for cloud computing using concepts of autonomic computing for providing an elastic environment. Our main contributions are: (1) an architecture based on concepts of autonomic computing for the provisioning of elasticity in cloud computing (Section 3 and 4); and (2) experiments performed in a private and hybrid cloud to validate the proposed architecture (Section 6).
2.
RELATED WORK
Tordsson et al. [21] proposed an architecture for cloud brokering and multi-cloud virtual machine management. They described algorithms for optimized placement of applications in multi-cloud environments, using a model that incorporates price and performance, as well as constraints in terms of hardware configuration and load balancing. Emeakaroha et al. [6] presented the Detecting SLA Violation infrastructure (DeSVi) architecture, which detects SLA violations through resource monitoring. Based on user requests, DeSVi allocates computing resources for a requested service and arranges its deployment on a virtualized environment. Resources are monitored using a framework capable of mapping low-level resource metrics, (e.g., host up and down time) to SLAs defined by users (e.g., service availability). The detection of possible SLA violations relies on the predefined service level objectives and knowledge databases usage to manage and prevent such violations. Kouki et al. [12] proposed SCAling, a platform and an approach driven by SLA for cloud autoscaling. A SLA defines a formal contract between a service provider and a service consumer on an expected QoS level. The main idea is to exploit the SLA requirements to propose dynamic resources provisioning. They modeled cloud services using a closed queueing network model considering the SLA concept. Based on a capacity planning method, their solution calculates the optimal configuration for a cloud application, relying on autonomic computing to adjust the configuration.
F
The principles of autonomic computing are already found in cloud elasticity studies, mainly by the use of agents to collect data and formulate rules for decision making [8, 15, 17]. The use of agents to collect information is a technique often used to promote elasticity, especially metrics associated to some environment computational resource for later making decision based on rules. Moreover, in general, self scaling operations are based on resource rules. However, this environment has no standardization. The automation of providers resource provisioning for adaptation to the users needs, so that no human intervention is required, is another aspect to be considered. Many works indirectly used features or principles of autonomic computing, trying to reduce human intervention [7, 8, 16, 17].
the infrastructure.
T
detailed study about cloud elasticity were described in [4], such as: definitions, metrics, benchmarks, elastic strategies, challenges and trends in the construction of elastic solutions.
R
A
Uriarte et al. [2] proposed a monitoring architecture for private cloud focusing on providing data analytics capabilities considering the knowledge requirements of autonomic systems. They implemented this architecture as a framework named Panoptes and integrated it to a simple self-protection framework of private clouds as proof-of-concept.
D
Buyya et al. [3] identified open issues in autonomic resource provisioning and presented innovative management techniques for supporting SaaS applications in cloud. They presented a conceptual architecture and early results evidencing the benefits of cloud autonomic management. This architecture has an autonomic management system composed by the following components: Application Scheduler, Energy-efficient scheduler, Dynamic Resource Provisioning Algorithms (Dynamic resource allocation e Prediction for resource selection) and Security and Attack Detection. Rego et al. [19] proposed an architecture to handle virtual machines allocation. This architecture is composed of Limit Manager, Scheduler, Monitor, Logger and Daemon. The Limit Manager is responsible for applying the limits on CPU usage. The Monitor is responsible for capturing information about the entire infrastructure, and it can directly access the infrastructure’s data or make requests for the cloud computing middleware. The monitored information are related to CPU, memory, disk and network. The Scheduler is responsible for deciding on which physical machine the virtual machines should be allocated. The Logger is responsible for cataloging all operations and messages. The Daemon is responsible for managing all the other modules and control
Scandurra et al. [20] proposed a framework that adapts a cloud-based application by providing an improved set of resources using a Pareto-optimal solution for optimizing the resource allocation with a tight cooperation between the cloud layers. They presented a coordination scenario for the adaptation of a cloud application, consisting of the following steps: (1) the SaaS framework defines adaption actions; (2) the PaaS framework tries to satisfy the SaaS demands; (3) the IaaS Framework tries to satisfy the PaaS demands; and (4) contract re-negotiation between layers. Qin et al. [18] presented a load rebalancing framework based on a Monitor-Analyze-Plan-Execute loop model, named ElastiCat. Its aim is to eliminate load imbalance while minimizing rebalancing costs. ElastiCat uses interference-aware prediction models to predict data migration time and performance impact using statistical machine learning, and then to create a cost model to make trade-offs between them. Jamshidi et al. [10] described a cloud-based elastic system comprised in three parts: a cloud-based application, a cloud platform, and an elasticity controller. The elasticity controller monitors the application and the environment, analyzes the data, detect violations, plan corrective actions in terms of adding resources or removing existing unutilized ones, executes the plan according to a specific
Netto et al. [14] evaluated several auto-scaling strategies by log traces from a Google datacenter, consisting millions of jobs. They used usage level as performance indicator, and their results showed proper management of auto-scaling parameters reduces the difference between the target usage interval and the actual values. They also presented a set of lessons that can aid cloud providers build recommender systems for auto-scaling operations. Becker et al. [1] derived metrics for scalability, elasticity, and efficiency properties of cloud computing systems using GQM (Goal Question Metric). They showed a running example that outlines features of cloud computing systems, allowing to set up a systematic GQM plan and derive an initial set of six new metrics for cloud scalability, elasticity, and efficiency.
3.
AUTONOMIC ARCHITECTURE
1) Global Control Loop: responsible for organizing all activities in the environment related to the elasticity. The global control loop manages the overall behavior of the system and defines how information will impact local adaptations. It acts by modifying the current behavior of the environment so that it can adapts to the needs imposed by the workloads. This loop is the manager of the environment and triggers events of collection, prediction, analysis and resources adding/removal actions; 2) Collector: mechanism to collect data from virtual machines in the cloud environment. It retrieves data from various resources and stores in the database; 3) Database: repository of the cloud environment information. It stores data, metrics, and environment’s settings for later use by other components and services; 4) Actuator: responsible for performing actions to add and remove virtual machines on the load balancer, as well as its creation and deletion, as established in the resource allocation strategy;
F
Our architecture aims to define an elastic cloud computing environment that can be used for private, public and hybrid clouds, and supports several autonomic computing concepts in order to effectively provide elasticity.
in local control loop. The global control loop manages the entire flow of the architecture, triggering prediction and running services when needed. The global control loop is also responsible for monitoring whether the consolidated values are exceeding any of the thresholds defined by the rules, and thus, trigger a predefined action to adjust the allocation of resources. Herein, the components are described as follows:
T
platform, and uses or updates a shared knowledge. This is known as MAPE-K loop [11]. They discussed about fuzzy logic to enable qualitative specification of elasticity rules for cloud-based software. They conducted several experiments to demonstrate that cloud-based software enhanced with such elasticity controller can robustly handle unexpected spikes in the workload, providing acceptable user experience.
5) Local Control Loop: mechanism that manages local operations of collecting and consolidating data on virtual machines. The local control loop manages the behavior of individual system elements and does not have visibility of the global behavior, attending only local goals or functions;
D
R
A
In this section, we propose an architecture for provisioning cloud computing elasticity. The architecture is based on the concepts of autonomic computing described by Kephart and Chess [11]: control loops, collectors, actuators, rules and self configuration. Figure 1 illustrates the proposed architecture with its components and relationships. In general, workloads are generated by different sources such as human users, benchmarks, computational traces and applications. This workload, depending on its goals or design, can be applied only to the load balancer, or to other virtual machines in the infrastructure, thus creating competition for resources.
6) Load Balancer: mechanism for providing the distribution of requests among virtual machines allocated to the environment. The load balancer can be a proper tool for load balancing or a developed tool in some programming language; 7) Workloads: workload applied to the environment, which can be generated by users (human or not), applications, computational traces or synthetic benchmarks. The workload may have random or pre-defined rates; 8) Rules: conditions that define thresholds to be monitored over the resources of the environment. Quality thresholds may have upper, lower and intermediate limits, and depending on the collected values and the associated level, actions are performed on the infrastructure. They are used for decision-making;
Figure 1: Generic autonomic architecture for elasticity in cloud computing The requests received by the load balancer are distributed to the allocated virtual machines. Locally in each virtual machine, collectors store data in the database as defined
9) Prediction: mechanism based on statistical techniques (e.g., regression and machine learning techniques) that aims to predict events of demand increase or decrease in order to avoid breaks in the SLA and idleness; 10) Metrics: attributes that measure the environment resources usage or applications features. They compose the rules together with thresholds. They are obtained from infrastructure and applications by collectors.
Several aspects of this architecture are flexible in terms of implementation. For example, the load balancer can use pre-allocated or dynamically instantiated virtual machines. Hence, the global control loop must be configured to handle allocation, creating and removal of virtual machines dynamically. Besides that, despite Figure 1 does not distinguish the type of cloud being used, it is noteworthy that the architecture can be used with any cloud technology regardless the cloud type (private, public, community or hybrid). To exemplify such flexibility, Figure 2 illustrates the proposed architecture for a hybrid cloud.
Algorithm 1 Procedure for logging the data 1: procedure logData(M ) 2: for all m ∈ M do 3: data ← collectData(m) 4: f ormattedData ← f ormatData(data) 5: saveData(f ormattedData, f ile, type) 6: V (m) ← f ormattedData 7: end for 8: end procedure
mechanism. The identif yV alue(r.m, V ) function must be implemented to obtain the calculated metric value used in the rule. The checkV iolation(r, value) function is a mechanism for comparing the reference value with the value collected for the metric’s rule, and for identifying SLA violations. The perf ormAction(r.a) procedure must be implemented to trigger actions for events related to adding or removing resources.
F
T
Algorithm 2 Procedure for rule verification 1: procedure checkRule(R, M , V ) 2: for all r ∈ R do 3: value ← identif yV alue(r.m, V ) 4: if checkV iolation(r, value) = true then 5: perf ormAction(r.a) 6: end if 7: end for 8: end procedure
4.
PROPOSED ALGORITHMS
A few considerations have to be made regarding the maximum and minimum threshold of resources. When the maximum amount of resources is reached, there are two options: (i) stop the increase of resources and use an external solution (e.g., public or hybrid cloud) once there is no longer such a possibility, or (ii) migrate virtual machines. On the other hand, when the minimum threshold is reached and there is no longer the possibility of reducing resources, the solution is to remain in the minimum allocation by stopping removing resources. Both situations are critical moments for the occurrence of SLA violations, and they are dependent on the adopted elasticity strategy.
A
Figure 2: Autonomic architecture for elasticity in cloud computing using private and public clouds
D
R
To support the implementation of the components of the proposed architecture, we designed some algorithms in high level. Let the infrastructure be represented by the tuple I =< M, R, V >, where M is the set of metrics to be monitored and used for the creation of rules, R is the set of rules, and V is the set of values of the collected metrics. Also, let the rule be represented by the tuple R =< m, o, f, a >, where m is the metric used in the rule, o is the operator applied in the rule (e.g., =, >, , where m is the metric and v is its collected value. Algorithm 1 presents the pseudocode for the data collection procedure. The collectData(m) function must be implemented to collect data from metrics that will be used in the rules. For instance, scripts can be used to implement such function to obtain the percentage of used CPU. The f ormatData(data) function must implement mechanisms to standardize the data format, allowing all procedures to recognize the information (e.g., adding the metrics date of collection). The saveData(f ormattedData, f ile, type) procedure must be implemented to store the formatted data in text files or databases, according to f ile and type. The logData(M ) procedure can be executed by agents running on all virtual machine. Algorithm 2 presents the pseudocode for the rule verification
Algorithm 3 presents the pseudocode for an implementation of the global manager, represented by the global control loop component. The checkP rediction(V ) function must implement a mechanism for predicting SLA violations based on collected values and rules, and thus trigger or not the elasticity actions. If checkP rediction(V ) function returns true, the perf ormAction() procedure must be implemented to anticipate the addition or removal of resources. The checkRule(R, M, V ) procedure is described in Algorithm 2. Algorithm 3 Procedure for global control loop 1: procedure activateGlobalManager 2: loop 3: if checkP rediction(V ) = true then 4: perf ormAction() 5: else 6: CheckRule(R, M, V ) 7: end if 8: end loop 9: end procedure
Table 1: Criteria for the performance evaluation of the proposed architecture
Design of experiments
Data analysis
Description Private and hybrid cloud computing environment (OpenNebula and Microsoft Azure) Percentage of CPU usage, applications’ response time; SAT , U AT , OAT , T AT , T U AR, T OAR, T SAR [5] CPU, memory, operating system, number of virtual machines, instance type Benchmark configuration (repetitions and array size), HTTPERF configuration (number and rate of requests, time) Measurement Run matrix multiplication (dimension 200x200x200) through a microbenchmark built in Java programming language, in the form of small web applications, with requests triggered by HTTPERF with rates ranging from 1 to 5 requests per second and the number of connections varying between 10, 30 and 50 Generation of the workload on the web server with HTTPERF and in each virtual machine; Experiment 1: 4 virtual machines in private cloud; Experiment 2: 3 virtual machines in private cloud and 1 virtual machine in public cloud (hybrid cloud) Interpretation of the results regarding the average CPU usage, virtual machines’ allocation and response time requests graphs, and tables
The implementation of the global manager can lead to a data synchronization problem, once while the rules are being evaluated, the data can be changed according to the workload applied to the environment. A possible workaround for that is to collect the data using local agents embedded in the virtual machines. This way, the global manager would only capture the stored information, and not log the data, minimizing synchronization problems.
5.
MATERIAL AND METHODS
removed when they are no longer needed. To trigger elasticity actions, we use the virtual machines’ CPU usage metric, that is calculated as the average of the last 10 samples (collected every 1 second). The thresholds used for performing elasticity actions are: (Experiment 1) above 90% (allocates a new virtual machine), below 80% (deallocates a virtual machine), and between 80% and 90% (maintains allocation); (Experiment 2) above 70% (allocates a new virtual machine), below 60% (deallocates a virtual machine), and between 60% and 70% (maintains allocation).
T
Criterion System Metrics Parameters Factors Evaluation technique Workload
Finally, for prediction, we use multilinear regression on CPU, memory, disk and network values (collected from previous experiments, with similar workloads).
5.1
6.
R
A private and a public cloud were used for the experiments. The private cloud is based on the OpenNebula management tool and is composed of 5 servers. All servers have an Intel Core i7-2600 processor, 8 GB of memory and Ubuntu Server 14.04 64 bit as operating system, and they run the KVM hypervisor and are connected through a Gigabit network. All virtual machines were created with 1 VCPU, 1 GB of RAM memory and Ubuntu Server 12.04 operating system.
D
We used Microsoft Azure as public cloud and all virtual machines were created with the Ubuntu Server 14.04 64 bits operating system and using the A1 Standard template (1 core and 1.75 GB of RAM memory). Each experiment used four virtual machines, Apache Tomcat as web container, HTTPERF tool as workload generator, and NGINX as load balancer. Workload was generated directly on the load balancer virtual machine in order to distribute the HTTP requests across the servers. More details about the experiments are presented in Table 1.
5.2
EXPERIMENTS
A
Material
F
In this section, we describe the material used in the experiments as well as the experimental design.
Experimental Design
The objective of the experiments is to validate the proposed architecture evaluating the resource usage behavior in computational clouds. For this, we developed scripts based on proposed algorithms to start the data collection, consolidation and analysis, as well as for starting the workload generation, analysis of the results and triggering actions. To handle the workload variation, we use a horizontal elasticity strategy, where new virtual machines instances are added to the load balancer when resources are needed, and
This section presents two experiments that we designed to validate the proposed architecture, as well as the results discussion.
6.1
Experiment 1 - Private Cloud
The objective of this experiment is to verify the behavior of the application performance and SLA maintenance using only a private cloud. Figure 3 shows the average CPU usage for all four virtual machines involved in the experiment, the allocation of these virtual machines and the applications response time. Many variations in CPU usage due to the characteristic of the benchmark can be seen, once allocations and deallocations were triggered when the defined thresholds were reached. In addition, we can see that when the SLA was overcome, new instances were allocated to the load balancer, and when the CPU usage was below the lower threshold, virtual machines were deallocated. We can also see many variations in the applications response time, mainly in the VM 1, where several peaks occurred. On the other hand, the response time in other virtual machines varied little because of the load balancing strategy, that initially used the VM 1, while the others were used when more resources were needed.
6.2
Experiment 2 - Hybrid Cloud
The objective of this experiment is to verify the behavior of the application performance when a public cloud instance is used together with a private cloud to maintain the SLA.
R
A
F
T
Figure 3: Graphs for Experiment 1: Average CPU usage (%), allocation, and response time (ms)
D
Figure 4: Graphs for Experiment 2: Average CPU usage (%), allocation, and response time (ms) In this experiment, the average CPU usage was more constant because the workload was better distributed among the virtual machines. Whenever the threshold of 70%, established as upper limit was exceeded, the load balancer added first the other two virtual machines from the private cloud, and then the virtual machine from the public cloud. Even so, SLA violations occurred, but in less amount, as shown in the graph of average CPU consumption (Figure 4). The response time of requests initially had the lowest values, and most requests were allocated to the VM 1. When the workload increased, more allocations were done as needed for approximately one-third of the experiment time. During this time, several requests had a high response time, even with the allocation of four virtual machines. It is important to highlight that the highest response times occurred in the virtual machine of the public cloud.
6.3
Experiment 3 - Metrics Calculated from Related Work
This experiment used a set of metrics proposed in [5]. These metrics evaluate the cloud elasticity behavior based on response time and resource usage. They proposed four metrics related to operations time: Underprovisioned Allocation Time (U AT ), Overprovisioned Allocation Time (OAT ), Stable Allocation Time (SAT ) and Transient Allocation Time (T AT ). Three metrics were proposed to consider resources involved in allocation operations: Total of Underprovisioned Allocated Resource (T U AR), Total of Overprovisioned Allocated Resource (T OAR) and Total of Stable Allocated Resource (T SAR). These metrics are described in Table 2. For our experiments, we used minutes as measure unit for the time metrics, and for resource metrics, the quantity of allocated or deallocated virtual machines. Table 3 shows the collected metrics. These metrics describe
Table 2: Metrics description Acronym U AT OAT SAT T AT T U AR T OAR T SAR
Description Time spent to perform resource adding operations Time spent to perform resource removing operations Time interval where there is no addition or removal of resources Time interval where the effects of resources addition or removal are not in place Allocated resources quantity in an underprovisioned state, but not stabilized Allocated resources quantity in an overprovisioned state, but not stabilized Allocated resources quantity in a stabilized state
Table 3: Collected metrics for Experiments 1 and 2 Metric Total Time (minutes) U AT OAT SAT T AT T U AR T OAR T SAR
Experiment 1 12:58 00:26 00:27 11:01 01:03 47 31 54
Experiment 2 11:14 00:57 00:49 06:23 03:03 24 16 30
public cloud were longer than in the private cloud, probably due to latency. Four aspects are highlighted in this discussion: • Provision of elasticity: The proposed architecture enabled the used resources of the experiment to be increased, when more resources are needed to maintain the defined SLA, as well as reduced when they are longer needed to avoid idleness and waste. • Elasticity effect on SLA: Since the architecture enables elastic actions to be performed on the infrastructure, we noticed that the defined SLA was maintained in most cases. Nevertheless, it is important to highlight that in some moments there were SLA violations because all the resources available were already being used. In this case, there was not the possibility of adding more features, violating the SLA.
T
Metric Underprovisioned Allocation Time Overprovisioned Allocation Time Stable Allocation Time Transient Allocation Time Total of Underprovisioned Allocated Resource Total of Overprovisioned Allocated Resource Total of Stable Allocated Resource
F
how resources are used in allocation and deallocation operations under the viewpoint of allocation operations time and resources usage. We can see resources used in states of underprovisioned (T U AR), overprovisioned (T OAR) and stable allocation (T SAR), and their respectively times (U AT , OAT and SAT ). These values show the architecture allocating and deallocating resources at some times, when needed, demonstrating the architecture is functional for elasticity operations. Specifically T AT shows the time in which operations and resources are not effectively active and available, and this aspect impacts directly in performance.
Discussion of Results
A
6.4
• Autonomic computing resources: Some principles of Autonomic Computing were used to support the architecture: control loops, collectors, actuators, rules and self configuration. In general, these principles cooperate satisfactorily. Local control loops were essential to collect data on the virtual machines, with the support of collectors. Another level of control loop (global control loop) was used for the management of elasticity actions, and drive actuators. The rules for performing elasticity actions also allowed a certain control level over the SLA defined for the experiments. Finally, the self configuration allowed the infrastructure to be adjusted (increasing and reducing the amount of resources);
D
R
According to the proposed architecture, the resources were allocated and deallocated as needed, adjusting to the workload. Figures 3 and 4 showed SLA violations in several time intervals. This fact indicated the amount of resources available in the environment reached the maximum. If more resources were available, CPU usage would be better distributed, with lower values in CPU usage. Consequently, the allocation would have more “steps” in the graph, corresponding to virtual machines allocation and deallocation. Both experiments used the same workload and resource allocation strategy. However, the thresholds were different. The response times in several points present high values. In general, a request would last 2ms. However, some requests lasted approximately 80.000ms. Furthermore, the load balancing strategy overloaded the VM 1 in a few times, hampering the requests distribution. This was due to the response time not been used as a metric for elasticity actions. Ideally, application metrics, such as response time and throughput, should be used in rules for the implementation of elasticity actions. The use of virtual machines in a public cloud did not impact much on the results of the experiments in relation to infrastructure and percentage of CPU usage, but could be more effective because it easily reached the usage limit, and thus the occurrence of SLA violations. Regarding the response time, the requests from the conducted experiment in the
• Architecture reuse: Not necessarily all architecture components have to be deployed. This is a design decision. For example, an architecture instance can be either reactive as proactive. This decision depends on the applied strategy and used prediction mechanism, which can be constantly replaced. One of the advantages of the proposed architecture is its flexibility, being able to change components by others of the same functionality and interfaces.
7.
CONCLUSION
The use of autonomic cloud computing environments to support the elastic provisioning has proved to be very effective. Here, we propose an autonomic architecture for providing elasticity in computational clouds. Experiments for validating the architecture show that it is possible to use autonomic computing and cloud computing along with various technologies and different providers. Additionally, we
As future work for evolving of the proposed architecture, different criteria should be used for rules design (e.g., average response time of requests or latency). Furthermore, the use of other levels of control loops may improve the architecture’s effectiveness, focusing on better performance. The prediction mechanism should also be evolved with different strategies, such as machine learning. Other elasticity strategies should be explored, such as vertical elasticity solutions (increasing the capacity of resources) and hybrid solutions. Finally, large-scale experiments should be performed to validate the architecture, either by testing or simulation.
8.
[10]
[11] [12]
[13]
REFERENCES
[14]
[15]
F
[1] M. Becker, S. Lehrig, and S. Becker. Systematically deriving quality metrics for cloud computing systems. In Proceedings of the 6th ACM/SPEC International Conference on Performance Engineering, ICPE ’15, pages 169–174, New York, NY, USA, 2015. ACM. [2] R. Brundo Uriarte and C. Becker Westphall. Panoptes: A monitoring architecture and framework for supporting autonomic clouds. In Network Operations and Management Symposium (NOMS), 2014 IEEE, pages 1–5, May 2014. [3] R. Buyya, R. Calheiros, and X. Li. Autonomic cloud computing: Open challenges and architectural elements. In Emerging Applications of Information Technology (EAIT), 2012 Third International Conference on, pages 3–10, Nov 2012. [4] E. F. Coutinho, F. R. de Carvalho Sousa, P. A. L. Rego, D. G. Gomes, and J. N. de Souza. Elasticity in cloud computing: a survey. annals of telecommunications - annales des t´el´ecommunications, 70(7-8):289–309, 2015. [5] E. F. Coutinho, D. G. Gomes, and J. N. d. Souza. An analysis of elasticity in cloud computing environments based on allocation time and resources. In Cloud Computing and Communications (LatinCloud), 2nd IEEE Latin American Conference on, Maceio, Brazil, dec 2013. [6] V. C. Emeakaroha, M. A. Netto, R. N. Calheiros, I. Brandic, R. Buyya, and C. A. D. Rose. Towards autonomic detection of sla violations in cloud infrastructures. Future Generation Computer Systems, 28(7):1017 – 1029, 2012. Special section: Quality of Service in Grid and Cloud Computing. [7] X. Etchevers, T. Coupaye, F. Boyer, N. de Palma, and G. Salaun. Automated configuration of legacy applications in the cloud. In Utility and Cloud Computing (UCC), 2011 Fourth IEEE International Conference on, pages 170 –177, dec. 2011. [8] H. Ghanbari, B. Simmons, M. Litoiu, and G. Iszlai. Exploring alternative approaches to implement an elasticity policy. In Cloud Computing (CLOUD), 2011 IEEE International Conference on, pages 716 –723, july 2011. [9] N. R. Herbst, S. Kounev, and R. Reussner. Elasticity in cloud computing: What it is, and what it is not. In Proceedings of the 10th International Conference on
Autonomic Computing(ICAC 2013), San Jose, CA, pages 23–27. USENIX, 2013. P. Jamshidi, A. Ahmad, and C. Pahl. Autonomic resource provisioning for cloud-based software. In Proceedings of the 9th International Symposium on Software Engineering for Adaptive and Self-Managing Systems, SEAMS 2014, pages 95–104, New York, NY, USA, 2014. ACM. J. O. Kephart and D. M. Chess. The vision of autonomic computing. Computer, 36(1):41–50, 2003. Y. Kouki and T. Ledoux. Scaling: Sla-driven cloud auto-scaling. In Proceedings of the 28th Annual ACM Symposium on Applied Computing, SAC ’13, pages 411–414, New York, NY, USA, 2013. ACM. P. Mell and T. Grance. The nist definition of cloud computing. National Institute of Standards and Technology, 53(6):50, 2009. M. Netto, C. Cardonha, R. Cunha, and M. Assuncao. Evaluating auto-scaling strategies for cloud computing environments. In Modelling, Analysis Simulation of Computer and Telecommunication Systems (MASCOTS), 2014 IEEE 22nd International Symposium on, pages 187–196, Sept 2014. O. Niehorster, A. Krieger, J. Simon, and A. Brinkmann. Autonomic resource management with support vector machines. In Proceedings of the 2011 IEEE/ACM 12th International Conference on Grid Computing, GRID ’11, pages 157–164, Washington, DC, USA, 2011. IEEE Computer Society. D. Niu, H. Xu, B. Li, and S. Zhao. Quality-assured cloud bandwidth auto-scaling for video-on-demand applications. In INFOCOM, 2012 Proceedings IEEE, pages 460 –468, march 2012. S. Pandey, W. Voorsluys, S. Niu, A. Khandoker, and R. Buyya. An autonomic cloud environment for hosting ecg data analysis services. Future Generation Computer Systems, 28(1):147 – 154, 2012. X. Qin, W. Wang, W. Zhang, J. Wei, X. Zhao, and T. Huang. Elasticat: A load rebalancing framework for cloud-based key-value stores. In High Performance Computing (HiPC), 2012 19th International Conference on, pages 1–10, 2012. P. Rego, E. Coutinho, D. Gomes, and J. De Souza. Faircpu: Architecture for allocation of virtual machines using processing features. In Utility and Cloud Computing (UCC), 2011 Fourth IEEE International Conference on, pages 371–376, 2011. P. Scandurra, C. Raibulet, P. Potena, R. Mirandola, and R. Capilla. A layered coordination framework for optimizing resource allocation in adapting cloud-based applications. In Proceedings of the 27th Annual ACM Symposium on Applied Computing, SAC ’12, pages 471–472, New York, NY, USA, 2012. ACM. J. Tordsson, R. S. Montero, R. Moreno-Vozmediano, and I. M. Llorente. Cloud brokering mechanisms for optimized placement of virtual machines across multiple providers. Future Generation Computer Systems, 28(2):358 – 367, 2012.
T
recommend using application metrics for autonomic actions together with infrastructure metrics.
D
R
A
[16]
[17]
[18]
[19]
[20]
[21]
