A performance Brokerage for Heterogeneous Clouds

4.5 Pricing

Cloud resources are typically priced on a flat pay per use basis, with sustained usage on GCE and reserved instances on EC2 providing discounts on the on-demand price. The EC2 spot market is the only market with dynamic pricing, that is, it changes in response to supply and demand. Observations (Ben-Yehuda et al., 2011) from this market are of small price variations around a long term constant mean, with infrequent, short lived but very large price spikes. Indeed, spot prices have been observed that are well in excess of the on-demand price.

That spot prices can be above on-demand is notable, as it points to a lack of on-demand availability. Whilst Clouds offer the illusion of infinite resource, on-demand capacity is not guaranteed. On EC2, reserved instances are the only guarantee of future capacity: at all times, EC2 must have sufficient capacity to meet its reserved commitments. Further, unused reserved capacity cannot be sold as on-demand instances as there is no agreement regarding reclaiming them. They can, however, be sold as spot instances which can be reclaimed. In the case when there is no on-demand availability (and they do not want to purchase reserved instances) users may still be able to purchase spot instances, but this likely helps to drive spot prices up beyond the on-demand price.
Users make bids for spot instances by submitting a maximum per instance hour price they are willing to pay. The current spot price, also quoted in instance hours, can be seen by all buyers and indeed spot price histories are available for download. EC2 processes spot bids as follows: bids are ordered by price, with the highest bid processed first. If the bid is above the existing spot price and there are sufficient resources the order is satisfied, at which point the second bid in the list is processed. This continues until no more orders can be satisfied.
The spot price is then updated and set to the price at which the last order was satisfied – and so is the lowest price amongst the successful bids. This price is then applied to all spot instances from the pool, that is, the price that all users are paying for instances from a particular pool is updated. If a spot price is updated so that it is higher than a user’s bid price, which we recall is the maximum they wish to pay, then their instances are terminated and resources reclaimed. From historical data collected across a variety of instance types and AZs, we observe that spot prices are updated every 90-120 seconds.
Wang et al. (2013) consider a Cloud environment whereby providers periodically hold auctions at which users have to rebid for their instances. The idea is to bring pricing dynamics to the on-demand market. However, if users are unsuccessful in their bids they must release their resources back to the provider. Forcing customers to return resources seems somewhat unsatisfactory. Whilst prices will rise and fall in accordance with demand and supply, it would seem preferable to encourage users to give up resources through price rises rather than force this through an unsuccessful bid.
Alzhouri and Agarwal (2015) suggest a dynamic pricing model that a provider can employ based on their available capacity. Put simply, as available capacity increases/decreases the price decreases/increases. Prices are adjusted continuously and the new price applies to existing customers as well as new ones, with price increases encouraging existing customers to release their resources back. In a commodity market however, whilst the available capacity of one provider may decrease, this doesn’t necessarily mean there will be a drop in supply (capacity) across the market as a whole. This is of benefit to users as the market price cannot be determined, or overly influenced, by a single provider.
Nasiriani et al. (2015) consider the problem of how providers who are subject to peak-based electrical pricing should fairly distribute this charge amongst their tenants. A requirement for this is that the provider can precisely determine the power consumption on a per tenant basis. However, this may cause difficulties for a CSB who is maintaining a pool of instances which they are then sub-letting as the CSB is the only tenant. For the CSB to fairly distribute the peak load pricing back to its customers, billing is required based on usage within an instance, and it is not clear if providers would, or indeed even can, make such granular billing available.
In a step towards performance pricing, Lucanin et al. (2015) considers heterogeneous Clouds where the CPU frequency of the hosts may be scaled up and down as this leads to energy, and hence cost, savings. They note that this would be at the expense of performance for CPU-bound workloads, whilst having less effect on I/O bounded ones. They propose a Cloud controller together with a pricing model based on the CPU frequency of the physical host on which a VM is instantiated. The customer is required to submit a parameter in the range [0,1] indicating the CPU ‘boundness’ of their workload. The controller then schedules the instances on to an appropriate host with the aim of minimising increases in energy costs whilst providing required performance. The price of the instance is then related to the CPU frequency of the host it is running on.
Whilst there are some interesting ideas, there are clear issues as well. For the same CPU model, price increases are proportional to CPU frequency increases; however application performance does not necessarily scale in the same manner. Customers may then see price increases without the corresponding performance increases. We also note that instance performance is highly dependent on features such as CPU cache contention, and this is not addressed here.

4.6 Cloud Simulators

To run a simulation, we must implement our model in code. CloudSim is a well-known set of libraries and classes with which to simulate Cloud environments (Cloud Computing and Distributed Systems (CLOUDS) Laboratory, n.d.). However, it is clear that some of the concepts used in CloudSim have been inherited from its predecessor GridSim, a set of libraries for simulating Grid environments. In CloudSim, a user submits workloads to run, referred to as ‘cloudlets’, to the broker, who in turn is responsible for the provisioning of instances, submission of cloudlets to virtual machines, and finally virtual machine termination when the cloudlets have finished. Further, a broker can place cloudlets in a queue if there are insufficient virtual machines to execute them.

Such a broker appears to be similar to typical grid job schedulers, such as Torque, with the additional ability to provision Cloud resources, so the notion of broker is quite different from a Cloud notion of offering a value-add service. Indeed, a broker is part of a data centre in CloudSim, so to have a broker that can use multiple data centres (providers) requires, at a minimum, extending the Broker class.
More problematically for our requirements is how CloudSim defines and uses performance. Each host in a data centre is assigned a number of MIPS (millions of instructions per second), each virtual machine is defined as having a number of MIPS the host will attempt to allocate to it, and each Cloudlet has a fixed number of instructions to execute. Given knowledge of the number of instructions a virtual machine has been allocated it is possible to determine cloudlet execution times. It is possible to vary cloudlet execution times by varying the number of virtual machines on a host, or the amount of MIPS assigned to them. However, is it not possible, simply from the base classes provided, to simulate two cloudlets (A and B) and two VMs (alpha and beta), in such a way that cloudlet A is faster than B on alpha, but slower on beta.
To simulate workload-specific performance variation as well as brokers that can use multiple providers requires extending CloudSim base classes, which in turn means accepting some unnecessary overheads. Indeed the limitations of CloudSim, as well as GridSim and a number of commercially available toolkits, led to Cartlidge (2013) developing the Cloud Research Simulation Toolkit (CReST). CReST reflects the research problems it was developed to investigate, namely pricing experiments through trading agents (Cartlidge and Clamp, 2013) and network topologies in data centres (Cartlidge and Cliff, 2013). However, CPU objects in CReST only have a utilization attribute, and so to use CReST to investigate performance variation also requires extending it with appropriate notions of performance. Rather than extending either CloudSim or CReST we choose therefore to write our own simulation, in Python, allowing us to focus on the specifics of our problem, and we note this is the approach followed by Rogers and Cliff (2012) who also implement their brokerage in Python. We have, for example, instances with identifiable CPU models, and workload performance is CPU specific - simulated by sampling from a probability distribution.