While the Google Compute Engine will typically try to avoid preempting instances, Google does tell us that larger instances are usually more likely to be preempted. That being the case, there are steps you can take to minimize preemption of your VMs.

For example, you can use smaller machine types, you can run larger preemptible VM clusters during off-peak times, and you can design the apps that will run on preemptible machines to be fault and preemption tolerant. Shutdown scripts can also be helpful.

By using smaller machine types, you can minimize preemption because it’s usually easier for Compute Engine to carve out the compute capacity that is necessary to run smaller instances from the excess compute capacity that’s used for preemptible instances. For example, machine types with fewer than 32 cores have a historically lower preemption rate than larger machine types.

In cases where you absolutely must use larger preemptible VMs, using preemptible VM clusters during off-peak hours can help minimize preemption, since there is typically more excess capacity available during these non-peak types.

And since you know going in that your machines are likely to be preempted at what will often be random times, regardless of sizing, ensuring your applications are configured in a fault tolerant or preemption tolerant manner, you can mitigate the impact that preemption has on your apps.

To ensure jobs that get impacted by preemption can pick up where they left off, rather than needing to start over, you can and should use shutdown scripts to manage shutdowns.

Now, since this course is more about optimization and cost management, let’s take a quick look at what happens with operating systems, local SSDs, and GPUs when used with preemptible instances and how costs are affected.

It’s important to understand that using a preemptible instance does not reduce the cost of a premium operating system that you may be using on your preemptible instance, like Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Windows Server, and SQL Server. Instead, you are billed for such operating systems like you would for any instances that you stop and start on your own.

A local SSD that’s attached to a preemptible instance works like a normal local SSD. However, you are charged the preemptible price for that local SSD usage. You can choose to use your regular local SSD quota when deploying a local SSD on a preemptible instance OR you can request a separate quota for preemptible local SSDs. I should also mention that you are not charged for a local SSD if the instance it is attached to is preempted within the first minute of being started up.

Just as you can use local SSDs with preemptible instances, you can also use GPUs on preemptible instances. When you add a GPU to a preemptible instance, you are charged the preemptible price for that GPU. When adding GPUs to preemptible instances, you can choose to use your regular GPU quota, or you can request a separate quota specifically for preemptible GPUs.

Like local SSDS, you are not charged for a GPU if the instance it is attached to is preempted within the first minute after being started up.

By following the guidelines I’ve touched on over the last few minutes, you can not only optimize your preemptible instances, but also minimize the costs associated with them.