A performance Brokerage for Heterogeneous Clouds
VM Sizing: Instance Types
Yüklə 1,38 Mb.
|
2.6 VM Sizing: Instance TypesProviders typically offer a variety of different instance families and within a family a specific size is known as an instance type. Instance types are of non-negotiable fixed sizes, albeit the sizes are provider specific. A particular instance type, at a minimum, would be expected to define (1) an amount of RAM (2) a number of vCPUs and (3) the amount of local storage (if any). It is commonplace for providers to specify an amount of ‘compute capacity’ that a vCPU should provide. AWS specifies compute capacity in terms of the EC2 Compute Unit (ECU), whilst we also find the Google Compute Engine Unit (GCEU) and Azure Compute Units (ACU), used on GCE and Azure respectively. Definitions of the above compute metrics are somewhat obtuse, for example the ECU provides: ’…the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor’ (Amazon Web Services, 2017). The purpose of provider metrics is to express the expected relative performance of instances. On GCE for example, an instance with a vCPU core rated at 5.5 GCEUs should execute a workload in half the time of one rated at 2.75 GCEUs. ACU is notable as no definition of the rating is given, and further they state that it is ‘…only a guideline. The results for your workload may vary’ (Microsoft Azure, 2017). This is perhaps an acknowledgement of the difficulty of finding one measurement that will be representative for the relative performance of arbitrary workloads. Limited hardware information of underlying hosts, such as the CPU model(s), may also be included in instance type specifications. For example, on EC2, instance types in the M4 family run on hosts that use either an Intel Xeon E5-2676 v3 or an Intel Xeon E5-2686 v4 CPU. Notably, AWS further specifies that a vCPU from the M4 family is allocated a full hyper-thread. This would appear to imply that a hyper-thread on an E5-2676 v3 has the same compute capacity as a hyper-thread on an E5-2686 v4. A priori, identical performance from different architectures appears unlikely, and a reasonable conjecture would be that the performance of both would be within some ‘tolerable’ distance of whatever defines 3.25 ECUs. On EC2, likely due to its age, instance families, such as General Purpose, contain different generations of instance types. So, in this case, we find the M1, M2, M3 and M4 classes, with M3 and M4 classified as current generation. Amongst the M3 and M4 families we find 10 different instance types. All M4 instance types have 4GB of RAM per vCPU as compared to 3.75GB for the M3 series. Interestingly, we find a range of ECUs per vCPU depending upon type, from 2.938 to 3.344. Differences between instance families allow for users to run workloads on instance types suited to the workloads’ needs. To support differentiated instance families, providers employ a variety of hardware and assign (or schedule) requests for instances of a particular type onto suitable platforms. That is, a request for a High Memory instance should be provisioned from a server with the physical characteristics required for supporting that instance type. On EC2, it is readily possible to identify the CPU model backing a particular instance once it has been obtained, but not in advance unless it is advertised as homogeneous. From this, one can begin to associate CPU platforms to instance classes - indeed, for some instance classes this homogeneity is advertised, as we have already discussed with the M4 family. Whilst some classes may currently be associated with only one hardware platform, this has tended not to be the case for all instance classes. The General Purpose M1 class is currently associated with at least 6, whilst the C1, M2, M3 and M4 are associated with 4, 2, 2 and 2 respectively. In addition to EC2, we have found that instance type heterogeneity exists on GoGrid, Rackspace and GCE, whilst Leitner and Cito (2016) report it for Azure. Whilst heterogeneity is commonplace, the degree of heterogeneity of particular classes is typically small. In light of heterogeneity, provider-specific rating schemes serve an additional purpose to expressing relative performance. So long as instances conform to the instance type specification, they are considered by the provider as equivalent irrespective of the hardware they are running on. This has an interesting consequence: If a provider makes their specification public, other providers could offer the same instance types and compete on price. Interestingly, as noted, providers are offering increasingly similar categories. Table : Common instance families across providers.
Within the High CPU instance class described in Table 3, we can find:
This is perhaps an indication that certain categories of instance types are becoming commodities and that providers are trying to compete with each other on the basis of price. In addition to increasingly common instance types across providers, we also find each of the major providers offering at least one type which, as of 10/2016, is unique to it:
However, maintaining product differentiation is difficult in the long run as competing providers can implement the same or similar types, and so we would expect to see a range of providers offering, for example, low latency network instances. Indeed, this process of commoditisation is likely inevitable, and we discuss the related notions of utility and commodity next, Yüklə 1,38 Mb. Dostları ilə paylaş:
|