Search for a command to run...
Optimizing Performance and Savings with Google Cloud Preemptible VMs
I'm an experienced backend and cloud devops engineer with great experience in building microservices, distributed systems, SOAs, event-driven systems and writing Infrastructure as Code (IaC).
In my spare time, I love writing technical articles, reading engineering blogs, as well as reading books on engineering leadership.
No comments yet. Be the first to comment.
Overview Circuit Breakers To put it simply, circuit breaker in the context of software engineering is a pattern that prevents further damage made to a system/service when a section of it fails, allowing the other parts of the system to continue funct...
We all know that sending data from a client to a server, especially as a web page is closing, is essential. This article explains how Beacon API makes this easy - a web standard designed to send small bits of data to the server without slowing down t...
Introduction Efficient task management is vital in modern distributed and scalable cloud environments. Google Cloud Tasks offers a managed solution that simplifies the distribution and execution of tasks across various components of your application....
In this article, we will learn how to install Redis on a GCP VM instance using Ansible. Prerequisites: A GCP account with a project and a VM instance. Ansible is installed on your local machine. An SSH key pair to access the VM instance. You must...
In the world of cloud computing, optimizing costs without sacrificing performance is a constant challenge. One way that Google Cloud offers to address this is through preemptible virtual machines.
For AWS folks, it's called AWS EC2 Spot Instance. The idea behind a spot instance and preemptible VM is the same.
Essentially, Preemptible VMs provide a cost-effective solution for running fault-tolerant and non-critical workloads. In this article, we will explore the benefits of preemptible VMs/Spot Instance, limitations, use cases, how the preemptible process work, creating a preemptible VM from a regular instance and many more.
Google Cloud preemptible VMs are similar to regular instances but come with a significant cost advantage. Well, the tradeoff is that these VMs/Spot Instances may be terminated by Google/AWS at any time albeit with a 30secs/2 mins notice. While this means they are not suitable for long-running, critical tasks, they are ideal for batch processing, distributed computing, and fault-tolerant applications.
Before we move ahead to spin up some preemptible VM instances (actually, in a followup article), i'd like to highlight the benefits, limitations and use cases.
Cost Efficiency: Preemptible VMs are priced significantly lower than regular instances, providing cost savings of up to 80%. This makes them an attractive option for workloads that can tolerate occasional interruptions.
Scalability: By leveraging preemptible VMs, you can easily scale your infrastructure at a fraction of the cost. This is particularly advantageous for bursty (occurring at intervals in a short timespan) workloads that require additional resources temporarily.
High Availability: Preemptible VMs can be used in combination with managed instance groups and autoscaling to ensure high availability and fault tolerance. The system automatically replaces preempted VMs with new ones, maintaining the desired level of capacity.
Limited Availability: Preemptible VMs are available on a "best-effort" basis and their availability is not guaranteed. They are offered at a significantly reduced price compared to regular VMs because Google Cloud can terminate them at any time. So, this means that they may not be suitable for applications requiring strict uptime or critical workloads.
Maximum Runtime: Preemptible VMs have a maximum runtime limit of 24 hours. After this time, they will be automatically terminated by Google Cloud. If your application or job requires longer execution times, you need to account for this limitation and design your solution accordingly :).
Termination without Warning: Preemptible VMs can be terminated at any time, without any advanced warning. While Google Cloud typically provides a 30-second notification before termination, your applications and processes must be designed to handle sudden interruptions and gracefully recover or resume operations when a VM is preempted.
Limited Quantity: There is a finite capacity of preemptible VMs available within a specific region and zone. If the demand for preemptible VMs exceeds the available capacity, you may not be able to launch new instances until capacity becomes available.
Resource Constraints: Preemptible VMs have some resource constraints compared to regular VMs. For example, they cannot be live migrated to other hosts, and they have a limited amount of CPU and memory resources. These constraints may impact certain workloads or applications that require specific configurations or resource-intensive operations.
Despite these limitations, preemptible VMs can still be a cost-effective option for certain use cases which are mentioned below:
Batch Processing: Preemptible VMs are ideal for batch processing workloads that can be divided into smaller tasks or jobs. You can leverage the significant cost savings offered by preemptible VMs to run large-scale data processing, ETL or other batch jobs. If a batch job is preempted, it will be restarted on a new preemptible VM. However, the job may lose some of its state, so it is important to design the job in a way that minimizes the impact of preemptions.
For example, let's say you have a batch job that is processing a large file or running image analysis or machine learning training, you could have a checkpoint logic that checks its progress every few minutes or seconds (the latter would be recommended) configurable by you and saves the state so that if the job is preempted at any point, it can continue processing from the last saved checkpoint when another VM is up and running - this is called checkpointing technique.
Test and Development Environments: Preemptible VMs can be used for creating temporary or short-term test and development environments. For instance, if your dev team requires isolated environments for testing, experimenting, or prototyping, preemptible VMs can provide the necessary resources at a much lower cost.
Non-Critical Workloads: Applications or workloads that can tolerate occasional interruptions or delays are good candidates for preemptible VMs. Examples include non-production environments, non-critical background tasks, non-time-sensitive data processing, or non-mission-critical applications.
DevOps: Preemptible VMs can be used for DevOps tasks, such as running continuous integration and continuous delivery (CI/CD) pipelines. These tasks can be interrupted and restarted without any loss of data, so they are well-suited for preemptible VMs. By leveraging the cost savings, you can scale your CI/CD infrastructure without incurring high expenses during idle or low-demand periods.
High-Performance Computing (HPC): For certain HPC workloads, preemptible VMs can be used to increase compute capacity while managing costs. Tasks such as rendering, simulation, scientific calculations, or distributed computing can benefit from the availability of preemptible VMs.
Web Crawlers or Scrapers: Preemptible VMs can be used for web crawling or scraping tasks where the workload can be divided into smaller chunks or parallelized. The lower costs associated with preemptible VMs make them an attractive option for scraping data from websites or conducting periodic web crawls.
Overall, batch jobs can be run on Google Cloud preemptible VMs, but it is important to design the job in a way that minimizes the impact of preemptions. By following these tips, you can save money on your batch processing jobs without sacrificing reliability. It is important to assess your application's requirements, resilience, and cost considerations before incorporating preemptible VMs into your infrastructure.
💡Spot VMs are the latest version of preemptible VMs. New and existing preemptible VMs continue to be supported, and preemptible VMs use the same pricing model as Spot VMs. However, Spot VMs provide new features that preemptible VMs do not support. For example, preemptible VMs can only run for up to 24 hours at a time, but Spot VMs do not have a maximum runtime unless you limit the runtime. You can read more on them and decide which one to use for your project and/or tasks.
According to Google Cloud documentation, the preemption process is as follows:
Once Compute Engine needs the capacity, Google sends a preemption notification as an Advanced Configuration and Power Interface (ACPI) G2 Soft Off signal -- a standard motherboard soft shutdown command, which every OS can handle -- that signals the system must reboot.
Ideally, the Soft Off signal then triggers a shutdown script that users have previously configured to save any system state and application data, terminate processes and stop the VM.
If the instance is still running after 30 seconds, GCE sends an ACPI G3 Mechanical Off signal to the OS, which is the equivalent of pulling the power on a server.
The Compute Engine instance then enters a terminated state, which preserves its configuration settings, metadata and attachments to other resources -- such as storage volumes -- but destroys in-memory data and VM state. Users can choose to restart or delete an instance in a terminated state, or leave it terminated indefinitely
Preempted instances still appear in your project, but you are not charged for the instance hours while it remains in a TERMINATED state.
There's no direct way to convert an existing regular VM into a preemtible VM but there's a workaround and i'll be showing you the steps.
Goto snapshots page here and click on Create Snapshot.
Input the name of your snapshot, click on "source disk" to choose which VM instance you want to create a snapshot from and then click on "Create"
Once a snapshot is created, click on it to view details and then click on "Create Instance".
Scroll to the near bottom under Available policies. Standard is selected by default but you have to select "Spot" because that's what we want to create. You will also notice that the price when you choose Standard is very different from (and higher than) the Spot and that's because it's a preemtible VM. Once that's done, just click on Create.
Step 5: That's it. You've successfully created a preemptible VM instance from a regular VM!
Your application must be fault-tolerant: Your application must be able to handle being interrupted and restarted. If your application cannot handle being interrupted, then you should not use preemptible VMs.
Your application must be stateless: Your application must not store any state on the VM. If your application stores state on the VM, then it will be lost when the VM is preempted.
Your application must be able to run quickly: Your application should be able to complete its work within 24 hours, wrap up and save the current state within the 30-seconds notice period. If your application takes longer than that to run, then it is possible that it will be preempted before it completes.
Google Cloud preemptible VMs offer an excellent opportunity to optimize costs while leveraging the power of cloud computing. By understanding the benefits, limitations and implementing them in your applications, you can unlock significant savings and scalability. However, it's important to carefully assess the suitability of preemptible VMs for your specific use case and ensure appropriate fault tolerance measures are in place.