In the first period of the WZH model, users purchase an options contract that gives them the right to subsequently buy a resource for a pre-agreed strike price, with the “delivery date” being the start of the second period. In the second period, users may then choose to exercise their option by paying the pre-agreed strike price. If they do not wish to execute their right, they pay nothing (apart from the price of the contract already paid in the first period, which is not refunded).
For each user, the price of the contract and the pre-agreed strike price are calculated using a probability in the range [0,1]. The probability q
i
is submitted by each user i to the Coordinator in the first period. User i’s submitted value q
i
is user i’s statement of the probability that she will want to use a resource in the second period. Their submitted probability, q
i
, does not have to been their actual probability, p
i
. The Coordinator aggregates these probabilities and purchases resources on the users’ behalf.
Wu et al. showed via theoretical analysis that, when the WZH model’s parameters were set with appropriate values:
● The Coordinator could make a profit by providing the service;
● Users are encouraged to submit their probabilities honestly; and
● Users who submit honest probabilities will reduce their costs over time, despite sometimes purchasing an options contract which is subsequently not executed.
In this paper, we use the truth-telling mechanism proposed by Wu et al. to derive forecasts of future demand for computing resources from users, which is subsequently used to schedule virtual machines. The mechanism works as follows:
The price paid by user i for a resource is:
Each user submits her true probability so that she expects to pay the least amount later. User i would expect to pay:
Her optimal submission q
i
* is determined by the following first order condition:
For an honest forecast, p
i
= q
i
It is clear that f ' (p) = − k(1 − p) and g ' (p) = kp satisfies this condition, where k > 0.
Therefore, we obtain the following pricing equations that meet the truth telling condition:
This can be considered an option if g(p) is paid in the first period to reserve the resource, and f(p) – g(p) is paid in the second period should the user wish to use the resource.
In previous work [14], we explored and validated Wu et al.’s claims though simulation experiments and showed that a simple evolutionary optimization process operating on an initially maximally dishonest pool of users results in the pool of users becoming more honest over time when interacting with the WZH system.
In [15], we demonstrated how a broker (a third party who buys and sells resources on her clients behalf) can use the WZH model as a basis for determining when to invest in longer-term access to cloud computing resources. We showed that the broker can profit in a number of situations, using a publicly available cloud computing service as the provider.
In [15], we focussed on the benefits of the model to the brokers and consumers. We assumed the provider would benefit as a result of increased uptake of their services. In this paper, we use the same pricing scheme as used in our previous work. However, we now investigate if the WZH model can directly benefit the provider through better virtual machine scheduling.
We propose that the provider can benefit by offering both probability-based options directly and on-demand pricing, without the need for a third party intermediary. The mechanism used by the provider is discussed in the next section.
Mechanism
In our ‘combined pricing’ method described below, the provider allows users to purchase options 24 hours in advance (the reservation phase) of when they will be executed (the execution phase). Options provide one hour of access to the virtual machine, and as European Options, they can only be executed at the expiry date.
Users can also purchase on-demand virtual machines which provides one hour of access to the resource, starting the moment the order is made. We use the pricing equations originally proposed by Wu et al. but employ them to define the price of a computational unit. Thus, the cost of a virtual machine of size n is the cost of n computational units.
Reservation phase
-
1.
In the reservation phase, users may choose to purchase an options contract for a virtual machine by paying a premium prior to execution phase. They pay:
where n is the number of computational units the virtual machine will require (the ‘instance size’), p is the probability it will be required, and k is a constant introduced by Wu et al. to tune pricing. We use the same value of k = 1.5 used by Wu et al. for consistency. We also assume that due to the truth-telling condition being satisfied earlier in this section, users submit honest probabilities.
-
2.
For each instance size, the provider aggregates the probabilities from the entire user population that a virtual machine of this size will be required at the time of expiry. This gives the provider the basis of a forecast of how many of each size of virtual machine will be required.
-
3.
The provider trials a number of bin-packing algorithms with the objective of finding the method that uses the lowest number of servers that contains all requests from all users as submitted in the first period. In our simulations, we use the following algorithms:
-
a.
First fit decreasing algorithm (FFD)
-
b.
Martello and Toth’s lower bound and reduction procedure (LBR) [11], which was chosen due to its significantly verified performance and easily replicated algorithm
-
4.
The best-performing algorithm is used to map the forecasted demand for instances to servers ready for use in the Execution Phase.
-
5.
This forecast could potentially be used to reduce variable costs, for example, by purchasing electricity usage in advance for a discount [16].
Execution phase
-
6.
At the point of execution, users can choose to execute their option, i.e. claim their right to use a resource. If they want to do this then they pay:
-
7.
The provider supplies the user with access to the size of virtual machine requested previously, using the map created in the Reservation Phase. If the provider has not mapped enough virtual machines to meet demand, it will start virtual machines where they will fit using the first-fit algorithm.
-
8.
If a user needs further resources, they will purchase on-demand virtual machines. The on-demand price is the price of executing an options contract with probability 0, as this was not forecasted by the user thus they pay the highest price in our model:
-
9.
A rational user will choose to exercise their option on a resource over purchasing a unit of the same resource on-demand, because the on-demand instance will cost more than the combined prices of the option’s purchase price and its strike price (Figure 1).
For the method to be of benefit, it must:
● reduce costs for the users, thus encouraging them to forecast; and
● reduce the number of active servers in use, thus reducing costs for the provider and therefore encouraging her to offer discounts for options.
To test this method, a simulation of this market for cloud-computing resources via options and on-demand purchases was written in Python and deployed on a commercial infrastructure-as-a-service environment.
Simulation study of allocation via of forward and option contracts
In this section, we present results from simulation studies that compare the efficiency of allocations via our combined pricing method to the efficiency of allocations using conventional on-demand scheduling. We find that using options contracts can offer significant efficiency improvements, but only when usage is above a particular threshold: when it is below that threshold, using options can actually make things worse. Nevertheless in Section 4 we go on to show how options can be combined with provision-point contracts to create an improved method that reduces utilisation losses. Furthermore, we show how provision-point forward contracts can deliver significant gains in efficiency, while preventing discounts being awarded where no gain in efficiency is realised.
Scenario
Users purchase options up to 24 hours in advance of when they will be exercised. Potentially, other regimes could be used but we have chosen this so that users have a fair change of predicting future resource requirements, and the provider has enough notice to benefit from this prediction (e.g. by scheduling workloads, purchasing electricity in advance, etc.). Options specify one hour of resource-usage, and can be used in combination with on-demand resources.
For comparison purposes only, we also run a simulation where users may purchase forward contracts instead of options. This is essentially an advance reservation where users are obliged to pay for the resource.
In the simulations in this paper, the provider operates a datacentre of homogeneous servers, due to the cost benefits of bulk purchasing hardware and the convenience of having a single stock of servers from which replacements can be obtained. The provider partitions these servers up into computational units which can then be aggregated together to offer a range of different instance types.
Users can purchase multiple virtual machines instances of any integer size from 1 to 8 computational units; one computational unit provides access to one CPU core for one hour. We typically simulate a run of 28 consecutive 24-hour days, with no difference in demand between week-days and weekends: 28 days therefore could be interpreted as one calendar month. A month duration of 28 days was chosen so that it would be easier to conduct future work on reservation periods of 7 days.
It is possible that the provider may have different physical server types to meet specific needs, such as having servers containing Graphical Processing Units (GPUs) for image processing applications. In this case, the provider could partition these servers into computational units too, and therefore offer the consumer a choice of technology, with a choice of instance types to run upon it. In our experiments, we assume that the provider uses a single technology and has access to a homogenous datacentre of servers with 2 × Quad-Core CPUs.
User behaviour
A user’s behaviour is determined by two factors: her market demand profile, and her product demand split.
A user’s market demand profile determines the resource requirements she will experience at each hour throughout the simulation. Demand varies smoothly from 0 to 1, where a demand of 1 means that a user’s maximum demand requirement (40 VMs in the simulations shown here) will be needed, 0.5 represents that the user’s demand is 50% of its maximum, and zero equates to no demand. The atomic unit of consumption is one computational unit for one hour. To model the dynamic variation in demand across each working day, and also across longer-term time-scales, five different demand profiles are used in the simulations. Each demand profile defines the pattern of demand variation over one 28-day month (672 hourly time-periods):
· Flat profile represents where demand is constant, and hence trivially easy to predict;
· Random profile represents stochastically unpredictable demand;
· Sine profiles (with period of 24 hours) are an approximation to daily rhythms, where demand varies sinusoidally, peaking in the middle of the day and at a minimum in the middle of the night. More precisely, in our simulations this sinusoidal demand pattern peaks around mid-day, and demand can never be negative, so a function of the form 1 + cos(2πh/24) is used, where h is the hour-number in the day. We have explored three variations of these sinusoid patterns:
○ Flat Sine represents constant a constant baseline of demand with periodic variations across each day;
○ Growing Sine represents daily periodic demand, with the baseline increasing steadily across the month;
○ Shrinking Sine represents daily periodic demand, shrinking through the month.
The demand profiles are illustrated in Figure 2
A user’s product demand split (PDS) defines the probability, for each instance type, that that instance type will be required in a time period by the user. A user may require many different types of instance, of different quantities, in a time period. This is to simulate a population where some users might generally require smaller instances, while others may frequently require larger ones.
In this simulation, we assume that user i has a product demand split that is generated from a normal distribution defined by its mean μ
i
, and its standard deviation σ
I
, with the value then thresholded to clip it within the range [0,8], i.e.: PDS
i
= min(max(0,N(μ
i
,σ
i
)),8). The mean represents the instance size that is most likely to be demanded by user i. The standard deviation represents the degree of variation in the distribution of instance sizes demanded by user i.
This method means that within any time period, a consumer will require a number of virtual machines of different types. For a user with μ
i
= 4 and σ
i
=0.25, it is likely that a large number of instance types of size 4 will be required in any time period. However, it is also possible they will require other instance types in the same time period, but due to the small standard deviation this will only occur rarely.
For a user with μ
i
= 3 and σ
i
=6.0, instances types of size 6 will be demanded most frequently in each time period. However, instance types of size 4 or 5 will also be demanded with roughly the same frequency as size 6 in any time period, due to the larger standard deviation
Each user’s requirements are generated at random from the thresholded normal distribution defined by their individual PDS
i
function. Although the demand patterns are smooth, individual user’s PDS
i
functions inject noise into the simulation as a result of the random selection of product demands from the normal distribution
This is a suitable function for modelling demand across virtual machine sizes, to a first approximation, for the following reasons. Consumers have two objectives when choosing a size of virtual machine: first, to ensure the virtual machine can meet the performance of the application running upon it; and second, to pay the least price to meet this performance. This reflects the fact that many cloud-computing customers have broadly similar performance requirements due to the prevalence of standard “stacks” of applications running on standard operating systems (such as the well-known “LAMP stack”, involving Linux, Apache, MySQL, and Perl/PHP/Python), so it is probable that many consumers would choose the same virtual instance size that meets an acceptable level of performance for the least cost. Nevertheless, some consumers may need better performance, while others may need to reduce cost further; that is, some users have a preference for performance over price while others value price over performance. Consumers could start with a standard size of VM and then increase or reduce that, to meet their performance or cost requirements.
To determine their probability of future resource demands, our model users employ a simple prediction based on their immediate history of past usage: each user considers if a resource was needed at that hour over the past working three days. For example, if a resource was required at 11 am every day for the past 3 days, the user will reserve a resource with probability 1.0 that it will be used at 11 am tomorrow. If a resource was used two out of three periods, the user will purchase an options contract with probability 0.66 and so on. If the provider offers forward contracts rather than options, then resources can only be reserved with a probability of 1.0 if it has been used in all three periods.
The provider aggregates probabilities for each instance-size and assigns the expected number of virtual machines to each server.
Execution
The simulation was deployed on a commercial infrastructure-as-a-service service to allow parallel processing of multiple experiments1.
To obtain a comparison with an on-demand only provisioning method, the simulation processed exactly the same requests for resources as for the combined-pricing method. However, each user’s requests were randomly re-ordered to simulate the scenario of users purchasing on-demand resources, where the provider must start virtual machines immediately wherever space is available.
Results
To judge the performance of our model, we monitor two measures: the mean reduction in cost per computational unit when the users employ combined options and on-demand purchases; and the reduction in the number of servers needed to service the combined demands of the users. We express both measures as percentages in comparison to results from the same simulation model when configured to run a purely on-demand purchasing system. In this manner, we compare the performance of the models against each other, rather than analysing the absolute values of costs and active servers for each model.
When viewing our results for reduction in server usage, it is important to realise that the large numbers of servers in a typical cloud data-centre mean that a small percentage value, such as a one or two percent reduction, can nevertheless involve the freeing up of hundreds or thousands of server machines.
Figures 3 and 4 shows the mean server reduction and mean cost saving respectively using combined pricing via options contracts, as a percentage increase/decrease of the same measure from on-demand-only pricing, over the course of the simulation for each product demand split μ and market profile. Figures 5 and 6 show the same measures, but for combined pricing using forward contracts.
Server usage reduction
From Figure 3, it can be seen that the combined pricing method via options contracts offers improvements in server utilisation compared to on-demand only pricing, but only when the mean product demand split is greater than three. This pattern is also seen in the case of combined pricing via forwards contracts (Figure 5). Furthermore, the combined pricing method using options contracts also makes improvements in server utilisation compared to traditional advance reservations (forward contracts) when the product demand split has a mean greater than three.
When the mean product demand split is three or less, the magnitude of the loss of utilisation for smaller instances is far greater than the gain in utilisation achieved when advance-scheduling larger instances. So the combined method using options contracts does have a benefit over both on-demand and advance reservations, but only when larger sized virtual machines are demanded by the user population. The provider must be confident that demand for larger resources is greater than that for smaller resources, or risk worsening the overall server utilisation.
Consider a partially utilised datacentre, receiving requests for instances in a random, on-demand fashion. Figure 7 shows such a scenario, where a datacentre of five servers is partially utilised by virtual machines of varying sizes. In this scenario, an instance of size three can be placed on any server. An instance of size four can only be placed on three of the already utilised servers. The instance of size five cannot fit on any partially utilised server, and a new server must be powered-on to support it.
In a similar manner, when there is an abundance of smaller on-demand virtual machine requests arriving in random order, many of these smaller instances can be placed on already partially-utilised servers. However, when there is an abundance of larger on-demand virtual machine requests, it is more difficult to place them and additional servers must be activated.
As a result of this, the online first-fit algorithm schedules very efficiently when smaller instances are dominant.
The offline first-fit decreasing algorithm also performs very efficiently in advance scheduling of virtual machines. However, in the execution phase, some users may choose not to execute their options contracts. When this occurs, many servers are left under-utilised. The net effect is a drop in utilisation using combined-pricing compared to on-demand only pricing.
In these experiments, there is a ‘tipping-point’ when the product demand split mean is 4 where the loss in utilisation caused by user’s choosing not to execute their options is less than the utilisation gained by advance scheduling. We believe the tipping-point is related to the point at which there is a large quantity of instances of a size greater than 50% of the maximum server size. Instances that are larger than 50% of the maximum server size cannot be scheduled together, so efficiencies gained by advance scheduling these are likely to be greater that for instances smaller than 50% of the maximum server size.
Figure 3 shows that options contracts achieve better utilisation than forward contracts (Figure 5) for larger instance sizes. When options contracts are deployed, instances are allocated to servers in advance. Subsequently, some users will choose not to execute their contracts and their allocated instances will not be utilised. However, users requiring on-demand resources can be given access to these unused instances, which have been previously mapped in an efficient manner using the bin packing algorithms. In forward contracts, however, it is not possible to assign requests for on-demand resources to unutilised instances. As such, new servers must be started for these new instances and the random order of on-demand instances causes an inefficient mapping.
As the provider aggregates probabilities from the entire user population, if a user chooses not to execute their options, there is a good chance the mapped space will be filled by another consumer purchasing on-demand virtual machines.
Consumer cost reduction
Figures 4 and 6 show that consumers make a cost-saving regardless of profile, product demand split or instrument. However, consumers make a greater cost saving using options contracts (Figure 4) than forwards contracts (Figure 6), implying consumers would prefer to use the combined pricing model utilising options contracts.
The cost reduction experienced by consumers is equivalent to the loss in revenue to the provider. If cost saved through better utilisation (and therefore less server requirements) is greater than the revenue lost, then the provider will make a net improvement in profits. As we discuss in Section 5, the pricing equations can be changed to ensure a net improvement is obtained. However, the provider often loses revenue as a result of offering discounts to consumers which subsequently fail to deliver improved utilisation. As a result, the provider will lose revenue without gaining a tangible benefit in some situations, which is clearly undesirable.
Tweaking the pricing parameters is unlikely to remedy this, as the nature of the method is that consumer’s requests must be fulfilled by the provider. In the next section, we develop an extension to this method, using provision-point mechanisms, as a method of protecting against lost revenue.