Google have released Google Compute Engine ‘preemptible’ virtual machines (VMs) in beta, which are the same as normal instances with the exception that they are limited to a maximum 24 hour runtime, and may be shut down at any time. Preemptible VMs are offered at a fixed price, which is discounted up to 70% off the prices of normal instances.
Preemptible VMs are the same as regular Google Compute Engine (GCE) VM instances, with the exception that they may be shut down at any time. By not guaranteeing indefinite VM uptime, Google is able to offer preemptible instances at a substantial discount in comparison with normal instances. This behaviour is comparable to that offered by Amazon Web Services (AWS) ‘spot instance’ VMs. However, unlike AWS’s spot instances, which require price ‘bidding’, Google offers preemptible VMs at a fixed price.
The Google Cloud Platform blog states that preemptible VMs are run on the spare capacity within Google datacenters, and the ability to reclaim (or ‘preempt’) these VM instances at any time helps to optimise datacenter utilisation. Preemptible VMs are limited to a 24 hour runtime, and receive a 30 second notification warning of shutdown when the instance is about to be preempted. GCE will initially send a preemption notice to the instance in the form of an ACPI G2 Soft Off signal. If the instance does not stop after 30 seconds, GCE sends an ACPI G3 Mechanical Off signal to the instance operating system. GCE then transitions the instance to a ‘TERMINATED’ state.
A preemptible VM can be created via the GCE developers console, gcloud CLI tool or GCE API. Within the GCE developers console the ‘availability policies’ can be used to enable preemptibility, the gcloud CLI tool utilises a ‘--preemptible’ option, and the GCE API allows a boolean ‘preemptible’ key to be set under the top-level ‘scheduling’ key. Enabling preemptibility automatically disables automatic restarts, prevents live migration, and sets the host maintenance action to ‘Terminate’. Accordingly, the responsibility is placed onto the VM user to ensure that these settings meet their workload requirements.
For customers using Hadoop on GCE, the open-source bdutil tool that allows the creation of a Hadoop cluster can be used to mix in preemptible VMs with normal VMs. By adding a ‘--preemptible .25’ option to the bdutil CLI, 25% of the created cluster (or whatever portion is required) is run as preemptible VMs.
The Google Compute Platform blog suggests that preemptible VMs are a good choice for distributed, fault-tolerant workloads that do not require continuous availability of a single instance. Examples of this type of workload include video encoding, rendering for visual effects, data analytics, simulation, and genomics. These use cases are a good match for cloud computing, as they consume a large volume of compute resources but typically only run on a periodic basis.
InfoQ caught up with Paul Nash, senior product manager at Google Cloud Platform, and asked several questions about the release of preemptible VMs within GCE.
InfoQ: The choice to utilise fixed pricing for preemptible instances is interesting. Can you offer any more insight into why a fixed cost model was chosen?
Nash: We thought this was an area where our simpler approach to pricing really made sense, and we’ve gotten a very enthusiastic confirmation of that. Many customers we talked to made it very clear that they did not like the auction-based pricing model for two reasons. The first is that the market is opaque - nobody knows who else is bidding and what they are willing to pay. When an auction market is opaque like that, the seller benefits from getting the maximum price possible at any moment, but it’s unclear if buyers are always getting a fair deal. The second thing we heard is that customers don’t like the unpredictability: one day it’s fairly cheap, but the next you’re priced out of your particular instance shape or preferred location. We’ve seen several third party companies spending years building software just to try and manage that for customers (and then taking a cut of the savings). We think our pricing is a win-win: we get better utilization and you get a cheaper, yet predictable price.
InfoQ: There are several interesting design choices baked in to the new preemptible VMs, for example the 24 hour uptime limit. Could you offer more explanation as to these choices please? Is it to encourage certain use cases, or is it a limitation on the way that resources are managed in Google Cloud Platform?
Nash: The 24 hour limit reinforces the “these will get preempted” mentality. Applications using Preemptible VMs really need to be prepared for getting preempted much earlier than 24 hours, the fixed limit is a strong reminder of that. We don’t want people to wake up one day and suddenly see that their VM that usually ran for 5 days in a row is now getting killed every 12 hours because it’s New Year’s Eve and regular VM demand is off the charts. Most of our early customers were either comfortable with the 24 limit or realized that if they needed much more time (like a week) their VMs were unlikely to survive that long anyway.
InfoQ: The 30 second ACPI G2 Soft Off signal warning is relatively short (in comparison with other vendor shutdown warnings). What was the reasoning for choosing 30 seconds?
Nash: Customers definitely need some time to shut down cleanly, but we’ve found with our early adopter customers that 30 seconds is more than enough for many scenarios. The tension is that when a regular VM needs the space a Preemptible VM occupies, the regular VM may need to wait for the Preemptible VM to shutdown. We have really aggressive targets for VM creation time (which is one of the things our customers love so much about Google Compute Engine), and we didn’t want to dramatically increase our tail latency.
InfoQ: We also notice that preemptible VMs cannot currently live migrate. Could this feature be added in the future? Perhaps for people willing to pay more if required, a preemptible VM could be 'upgraded' to a standard VM?
Nash: Our goal is that customers can get useful work done with Preemptible VMs without impacting our regular VM experience. If that means that we should start live migrating them to avoid certain classes of eviction, then we’d certainly consider it.
Customers looking to “upgrade” their Preemptible VM to a Standard VM are usually trying to guarantee some amount of forward progress, or running long-lived tasks that aren’t a great fit for Preemptible VMs. In many cases, it makes more sense to create a pool of regular instances and then supplement with Preemptible VMs. When we preempt your VM we just terminate or stop it, so you can bring it back up later when there is capacity available. Importantly, we don’t delete your Persistent Disk (PD) so your data isn’t lost if you’d like to continue your work on a new (possibly regular) VM.
InfoQ: A lot of people are becoming very interested in container clustering and orchestration technologies, such as Kubernetes, where variable demand and elasticity are a given. Could you see the preemptible VM model being rolled out to services such as Google Container Engine (GKE)?
Nash: The focus of Kubernetes and Google Container Engine so far has been web application serving (stateless front ends and 'cloud friendly' stateful workloads). Right now the team is focusing on shipping a production-ready version of Kubernetes for developers building and operating these apps. We expect to release this version in the next couple of months. Kubernetes’ next focus will be orchestrating batch centric, computationally intensive workloads. We see this as a great way to reduce both the hosting cost and operational complexity of running these workloads
Preemptible VMs have been released as beta in the Google Compute Platform, and are available to all customers in all regions. Additional information on preemptible VMs can be found within the GCE documentation, and additional pricing information can be on the GCE pricing page.
