In sections 2.1 to 2.2 we consider the characteristics of Cloud systems, and arguably elasticity, which is the ability to acquire seemingly unlimited resources on-demand, is the key characteristic of Clouds that differentiates them from other distributed systems. Indeed, for certain types of workloads, elasticity makes Clouds high performing systems as it removes the limit of work done per unit of time. Another important characteristic of Cloud systems, and which differentiates them from typical on-premise systems, is the self-service model. This helps to eliminate the bottleneck that can be caused when resource requests are submitted to IT service teams, particularly when the latter operate without SLAs between themselves and their users.
In section 2.3 we discussed common Cloud service models. Of these, Infrastructure as a Service (IaaS) is arguably the most important as other higher level abstractions such as container and function services runs atop them.
In section 2.4 we discussed the various Cloud deployment models. Clouds may be deployed on-premise, and in doing so perhaps provide for more flexible provisioning than found on traditional IT systems, however, it is not clear how issues with traditional on-premise systems can be avoided. In particular, the inability to scale quickly and the need to provision for peak demands. Public Clouds benefit from a large and diverse user base which helps to reduce correlation in use, and so smooth variation in aggregate demand. As a consequence Public Clouds can support bursty and unpredictable needs in a more cost effective manner than most organisations can with an on-premise system. Due to its prominence and ability to support elasticity, our focus in this thesis is on Public Infrastructure Cloud, which we refer to simply as Cloud.
In section 2.5 we discussed how in order to support elasticity providers deploy globally spanning infrastructure, which is concentrated in specific geographic locations known as Regions. In turn, Regions contain distinct locations called Availability Zones, into which resources can be placed. AZs are comprised of heterogeneous data centres containing tens of thousands of physical servers and the performance of instances, which is the primary concern of this thesis, is derived from these and the virtualization software which combine to provide instances on-demand.
As discussed in section 2.6, providers make instances available in a variety of flavours and sizes known as instances types. Typically the sizes offered are non-negotiable, which likely eases the mass production of them, required to support elasticity, and such standardisation draws natural comparisons with commodity, and we note that offerings from different providers are increasingly similar, indicative of a market undergoing commoditisation. However, perhaps due to mass production model, we typically find that instances of the same type may be provisioned from a range of different hardware. As we shall discover in sections 5.2 to 5.4, this has significant performance implications as it introduces variation due to hardware differences.
Utility and commodity are pervasive notions in Cloud Computing, and in section 2.7 we discussed them in further detail, taking the opportunity to provide some background with regards to previous generations of distributed systems. Arguably, future commodity marketplaces for Cloud resources are likely to resemble current Regions, with vast quantities of compute resources concentrated into specific geographical locations. However, instead of a single provider operating multiple, distinct, and independent AZs, each of which offers the same types of potentially heterogeneous instances at the same price, we will find multiple independent providers offering the same instances types, which again are likely to be heterogeneous, but at different prices. Looking ahead to section 6.2, we model a future commodity exchange for Cloud resources as an extension of the current Region/AZ architecture.
However, as already noted, deciding when two resources from different providers are equivalent will require a consideration of their performance. In the next chapter we discuss how performance properties transpire on IaaS Clouds.
15. 16.3 Cloud Performance
An Infrastructure Cloud is a system of physical components and software tools which combine to allow resources to be created and destroyed on-demand. The performance properties of these resources derive from the performance properties of the underlying system components, and so to understand the former we must understand the latter. The objective of this chapter is describe the components of an Infrastructure Cloud system, from which we can determine the most appropriate metrics for defining their performance as well as benchmarks for measuring. Further, we aim to identify aspects of the system which may lead to performance variation. In that regard, in section 3.2 we note that providers make no assurance with regard to resource performance in their SLAs.
In section 3.3 we discuss server virtualisation which is arguably the key enabling technology for Cloud Computing as it allows for a CPU to be securely shared amongst virtual machines (on the same host) and so a physical server can be partitioned into multiple instances and made available for rent.
In sections 3.4 and 3.5 we discuss how performance should be defined and measured. Simple early benchmarks reflect simpler CPU architecture, but become obsolete with improvements to hardware. We note a preference for task progression metrics which measure progress towards the completion of a task, such as execution time. Further, we note a preference for real-world benchmarks, which overcome a number of issues that ‘smaller’ and typically specifically crafted benchmarks have when measuring performance of modern systems.
For motivation, we begin by providing some hypothetical examples of problems that may arise due to performance variation.
Dostları ilə paylaş: |