Cloud platforms offer different types of virtual machines which ensure different guarantees in terms of availability and volatility, provisioning the same resource through multiple pricing models. For instance, in Amazon EC2 cloud, the user pays per hour for on-demand instances while spot instances are unused resources available for a lower price. Despite the monetary advantages, a spot instance can be terminated or hibernated by EC2 at any moment. Using both hibernation-prone spot instances (for cost sake) and on-demand instances, we propose in this paper a static scheduling for applications which are composed of independent tasks (bag-of-task) with deadline constraints. However, if a spot instance hibernates and it does not resume within a time which guarantees the application's deadline, a temporal failure takes place. Our scheduling, thus, aims at minimizing monetary costs of bag-of-tasks applications in EC2 cloud, respecting its deadline and avoiding temporal failures. Performance results with task execution traces, configuration of Amazon EC2 virtual machines, and EC2 market history confirms the effectiveness of our scheduling and that it tolerates temporal failures.
Some works take into account Amazon spot VMs instance features. In @cite_20 , use hybrid instances, including both on-demand instances for high priority tasks and backup, and spot instances for normal computational tasks. Authors of @cite_25 propose to switch to on-demand resources when there is no spot instance available to ensure the desired performance. Using both on-demand and spot VM instances, SpotCheck @cite_8 provides the illusion of an IaaS platform that offers always-available on-demand VMs for a cost near that of spot VMs. Also claiming performance of on-demand VMs, but at a cost near that of the spot market, the authors in @cite_14 present the SpotOn batch service computing, that uses fault-tolerance mechanism to mitigate the impact of spot revocations. To our knowledge no work studies the impact of the new hibernation feature of spot instances on scheduling algorithms.
@cite_14 @cite_25 @cite_20 @cite_8
2033790833 1463932917 1997826804 2162331430
Infrastructure-as-a-Service (IaaS) cloud platforms rent resources, in the form of virtual machines (VMs), under a variety of contract terms that offer different levels of risk and cost. For example, users may acquire VMs in the spot market that are often cheap but entail significant risk, since their price varies over time based on market supply and demand and they may terminate at any time if the price rises too high. Currently, users must manage all the risks associated with using spot servers. As a result, conventional wisdom holds that spot servers are only appropriate for delay-tolerant batch applications. In this paper, we propose a derivative cloud platform, called SpotCheck, that transparently manages the risks associated with using spot servers for users. SpotCheck provides the illusion of an IaaS platform that offers always-available VMs on demand for a cost near that of spot servers, and supports all types of applications, including interactive ones. SpotCheck's design combines the use of nested VMs with live bounded-time migration and novel server pool management policies to maximize availability, while balancing risk and cost. We implement SpotCheck on Amazon's EC2 and show that it i) provides nested VMs to users that are 99.9989 available, ii) achieves nearly 5x cost savings compared to using equivalent types of on-demand VMs, and iii) eliminates any risk of losing VM state. Cloud spot markets enable users to bid for compute resources, such that the cloud platform may revoke them if the market price rises too high. Due to their increased risk, revocable resources in the spot market are often significantly cheaper (by as much as 10×) than the equivalent non-revocable on-demand resources. One way to mitigate spot market risk is to use various fault-tolerance mechanisms, such as checkpointing or replication, to limit the work lost on revocation. However, the additional performance overhead and cost for a particular fault-tolerance mechanism is a complex function of both an application's resource usage and the magnitude and volatility of spot market prices. We present the design of a batch computing service for the spot market, called SpotOn, that automatically selects a spot market and fault-tolerance mechanism to mitigate the impact of spot revocations without requiring application modification. SpotOn's goal is to execute jobs with the performance of on-demand resources, but at a cost near that of the spot market. We implement and evaluate SpotOn in simulation and using a prototype on Amazon's EC2 that packages jobs in Linux Containers. Our simulation results using a job trace from a Google cluster indicate that SpotOn lowers costs by 91.9 compared to using on-demand resources with little impact on performance. Spot virtual-machine (VM) instances, such as Amazon EC2 Spot VMs, are a class of VMs that are purchased through a market mechanism of price-bids submitted by cloud users. Spot VMs can be obtained at substantially lower cost than other VM classes such as Reserved and On-demand instances, but they do not have guaranteed availability since it depends on the submitted price bids and the fluctuating spot VM price. Many applications with large computing requirements but no real-time availability constraints, such as scientific computing, financial modelling and large data analysis, can be carried out at a significantly lower cost using spot VMs. For such jobs, an important question that arises is what should the submitted price bids be so that the computation is completed within a fixed time interval while the cost is minimized. Towards this goal, we model a job as a fixed computation request with a deadline constraint and formulate the problem of designing a dynamic bidding policy that minimizes the average cost of job completion. We obtain analytical and closed-form results for the optimal strategy under a Markov spot price evolution, and then evaluate the performance of the algorithms on the actual spot price history of Amazon EC2 Spot VMs. Cloud spot markets offer virtual machines (VMs) for a dynamic price that is much lower than the fixed price of on-demand VMs. In exchange, spot VMs expose applications to multiple forms of risk, including price risk, or the risk that a VM's price will increase relative to others. Since spot prices vary continuously across hundreds of different types of VMs, flexible applications can mitigate price risk by moving to the VM that currently offers the lowest cost. To enable this flexibility, we present HotSpot, a resource container that "hops" VMs---by dynamically selecting and self-migrating to new VMs---as spot prices change. HotSpot containers define a migration policy that lowers cost by determining when to hop VMs based on the transaction costs (from vacating a VM early and briefly double paying for it) and benefits (the expected cost savings). As a side effect of migrating to minimize cost, HotSpot is also able to reduce the number of revocations without degrading performance. HotSpot is simple and transparent: since it operates at the systems-level on each host VM, users need only run an HotSpot-enabled VM image to use it. We implement a HotSpot prototype on EC2, and evaluate it using job traces from a production Google cluster. We then compare HotSpot to using on-demand VMs and spot VMs (with and without fault-tolerance) in EC2, and show that it is able to lower cost and reduce the number of revocations without degrading performance.