Project topics and materials
Get Complete Project Material File(s) Now! »
Elasticity definition and its related terms
There have been many definitions in the literature for elasticity [9], [10], [2], [1]. However, from our point of view, we define elasticity as the ability of a system to add and remove resources (such as CPU cores, memory, VM and container instances) “on the fly » to adapt to the load variation in real time. Elasticity is a dynamic property for cloud computing. There are two types of elasticity as shown in Figure 2.1: horizontal and vertical. Horizontal elasticity consists in adding or removing instances of computing resources associated with an application. Vertical elasticity consists in increasing or decreasing characteristics of computing resources, such as CPU time, cores, memory, and network bandwidth. There are other terms such as scalability and efficiency, which are associated with elasticity but their meaning is different from elasticity while they are used interchangeably in some cases. Scalability is the ability of the system to sustain increasing workloads by making use of additional resources [2], it is time independent and it is similar to the provisioning state in elasticity but the time has no effect on the system (static property). In order to have a complete understanding, we deduce the following equation that summarizes the elasticity concept in cloud computing. Elasticity = scalability + automation+optimization auto-scaling It means that the elasticity is built on top of scalability. It can be considered as an automation of the concept of scalability, however, it aims to optimize at best and as quickly as possible the resources at a given time. Another term associated with elasticity is the efficiency, which characterizes how cloud resource can be efficiently utilized as it scales up or down. It is the amount of resources consumed for processing a given amount of work, the lower this amount is, the higher the efficiency of a system. The amount of resources can relate to cost, power consumption, etc., depending on the targeted resource [11]. Generally, this is a measure of how well the application is using the provided resources. Higher cloud elastic system results in higher efficiency. The processes of resource provisioning and scheduling (i.e., jobs or customer’ requests on instances) are both related to elasticity since they try to provision instances but in response to provider and customer tradeoffs. [12], [13] provision resources according to a utility model to satisfy customers’ needs and a certain pricing model to increase service provider profit. The provisioning and scheduling processes may take a certain delay in order to meet SLAs and provider profit conditions.
It is worth noting that scaling up or down the resources can lead to a deviation of the current amount of allocated resources from the actual required resource demand. The accuracy of elasticity systems varies from one system to another. Over-provisioning and under-provisioning are two important factors that characterize an elastic system. The system enters in over-provisioning state once the resources provided (called supply S) are greater than the consumer required resources (called demand D), i.e., S > D. Though QoS can be achieved, over-provisioning state leads to extra and unnecessary cost to rent the cloud resources. Under-provisiong takes place once the provided resources are smaller than the required resources, i.e., S < D, and this causes performance degradation and violation of service level agreement (SLA). There is no common methodology to measure or determine temporal or quantitative metrics for elasticity. A consumer can measure the delay it takes to provision and deprovision resources, in addition to the sum of delays of over-provisioning and under-provisioning states to quantify different elastic systems [14].
[15] discusses methods to measure scalability and elasticity of a system. According to [15], effects of scalability are visible to the user via observable response times or throughput values at a certain system size. On the other hand, the elasticity, namely the resource resizing actions, may be invisible to the user due to their shortness or due to the transparency and dynamicity of resource provisioning. The effect of reconfiguration on performance metrics (e.g., response time) due to elastic adjustments of resources and the reaction time can quantify the elasticity. It is clear that elasticity is controlled with time. Therefore, the speed is also very important in elasticity. Reaction time is the time interval between the instant when a reconfiguration has been triggered/requested and until the adaptation has been completed. [16] proposes an approach for elasticity measurements. In addition to the over-provisioning and under-provisioning states, another state called just-in-need is introduced. Just-in-need denotes a balanced state, in which the workload can be properly handled and quality of service (QoS) can be satisfactorily guaranteed. The approach developed calculation formulas for measuring elasticity values based on the time intervals a system stays in one state. There are three states: over-provisioning, under-provisioning, and just-in-need. A set of rules is used to determine the state of a system based on the workload and computing resources. The equations can be obtained and calculated by directly monitoring the system or by using continuous-time Markov chain (CTMC) model. The drawback of the proposed system is that it assumes the system is in a certain state based on rules. For example, the system is in just-in-need state if the number of requests (j) is greater than the number of VMs (i) and less than 3 multiplied by the number of VMs (i), i.e., (i < j 3i). We cannot guarantee the certainty for these rules on all elastic systems.
Elasticity taxonomy
Elasticity solutions build their mechanisms on different strategies, methods, and tech-niques. Therefore, different classifications [9], [10], [17], [18], [19] have been proposed according to the characteristics implemented in the solutions. We have investigated many industrial and academic solutions, in addition to papers in the elasticity literature, and then we propose the classification shown in Figure 2.2. It is an extended and complementary elasticity classification as compared to classification in [9], [10], [17], [18], and [19]. Next subsections explain in details each characteristic and mechanism used. The solutions are classified according to the chosen configuration, scope, purpose, mode or policy, method or action, architecture, and provider.
Configuration
Generally, configuration represents a specific allocation of CPU, memory, network band-width and storage [20]. In the context of our classification (see Figure 2.2), configuration represents the method of the first or initial reservation of resources with a cloud provider. During the first acquisition of resources, the consumer either chooses from a list of offer packs or specifies its needs, i.e., combining different resources. Therefore, the configuration can be either rigid (fixed) or configurable. The rigid mode means that the resources are offered or provisioned in a constant capacity. The virtual machine instances (VMIs) are found with a predefined resource limit (CPU, Mem, etc.) called instances such as Amazon EC2 (offering 38 instances), Microsoft Azure (offering many series A, D, DS, G, and GS and each series has different VM sizes). In the cloud market, the VMIs are offered in various configurations. The problem with rigid configuration is that the resource rarely meets the demand, therefore, there is always under-provisioning or over-provisioning. The configurable mode allows the client to choose the resource such as number of CPU cores in the VMs. ProfitBricks [21] and CloudSigma [22] are examples of this type.
The customers can reserve the resources according to the following reservation meth-ods [20]:
• On-demand reservation: The resources are reserved immediately or the requests will be rejected if there are no enough available resources.
• In advance reservation: The clients send initial requests to reserve resources and a fixed price charge is required to initiate the reservation, the resources must be available at a specific time.
• Best effort reservation: Reservation requests are queued and served accordingly such as Haizea, an open-source VM-based lease management architecture used in OpenNebula [23].
• Auction-based reservation: Specific resource configurations are reserved dynami-cally as soon as their prices are less than bid amount offered by the customer [24].
• There are other types of reservation such as Amazon’s scheduled reserved instances, Amazon’s dedicated instances, Google’s preemptible instances, etc.
Table of contents :
List of figures
List of tables
1 Introduction
1.1 Scope and Challenges
1.2 Research Problems and Objectives
1.3 Evaluation Methodology
1.4 Contributions
1.5 Dissertation Outline
1.6 Publications
I State of the Art
2 Elasticity in Cloud Computing: State of the Art and Research Challenges
2.1 Introduction
2.2 Elasticity
2.2.1 Elasticity definition and its related terms
2.2.2 Elasticity taxonomy
2.2.3 Elasticity performance evaluation
2.3 Containerization
2.3.1 Pros and Cons
2.3.2 Container technologies
2.3.3 Container orchestration and management tools
2.3.4 Elasticity of containers
2.4 Open Issues and Research Challenges
2.5 Related Work
2.6 Conclusion
II Elastic Docker
3 ElasticDocker Principles
3.1 Introduction
3.2 Motivation
3.2.1 Resource over-provisioning and de-provisioning
3.2.2 Vertical elasticity
3.2.3 Containers vs VMs
3.2.4 Elasticity coordination
3.3 Background
3.3.1 Docker technology
3.3.2 Checkpoint/Restore In Userspace (CRIU)
3.4 ElasticDocker Approach
3.4.1 System design
3.4.2 Monitoring system
3.4.3 Elasticity controller
3.5 Coordinated Controller
3.5.1 General Design
3.5.2 Components of the System
3.6 Container live migration
3.7 Discussions
3.8 Related Work
3.9 Conclusion
4 ElasticDocker Evaluation
4.1 Introduction
4.2 ElasticDocker Experiments and Evaluation
4.2.1 Experimental setup
4.2.2 Evaluation and results
4.3 Coordinated controller validation
4.3.1 Experimental Setup
4.3.2 Research Questions
4.3.3 Evaluation Results
4.4 Docker live migration efficiency
4.5 Conclusion
III Model-Driven Elasticity Management with OCCI (MoDEMO)
5 MoDEMO Principles
5.1 Introduction
5.2 Motivation
5.2.1 Motivation for MoDEMO
5.2.2 Motivation for Docker Model
5.3 Background
5.4 Docker Model
5.4.1 Architecture overview
5.4.2 Modeling Docker Containers
5.5 MoDEMO Approach
5.5.1 MoDEMO Model
5.5.2 MoDEMO elasticity policies
5.5.3 MoDEMO design tool
5.6 Discussion
5.7 Related Work
5.8 Conclusion
6 MoDEMO Evaluation
6.1 Introduction
6.2 High Level Architecture Overview
6.3 Validation
6.3.1 MoDEMO policies
6.3.2 Runtime settings
6.3.3 MoDEMO overhead
6.3.4 Docker model evaluation
6.4 Conclusion
IV Conclusion and Final Remarks
7 Conclusions and Future Directions
7.1 Summary and Conclusions
7.2 Future Directions
7.2.1 Proactive approach
7.2.2 Application-based elasticity
7.2.3 Dynamic thresholds
7.2.4 Elasticity coordination
References
