Managed Instance Groups and Standby Pool

Q: What are Managed Instance Groups?

Managed Instance groups in Google Compute engine are a handy option when it comes to deploying applications which deal with bursty workloads, one time data analysis, POC activities, experimentation etc

These provide with a capability to scale up and scale down by adding or removing/deleting resources proportional to the workloads. We can achieve this by defining the auto-scaling policy while configuring the instance group.

Key use cases where MIG can be handy:

• Bursty workloads which sees a spike in the traffic during certain periods
• One time ML training jobs where control on the training environment is a priority
• One time Data analysis jobs
• Independent small micro services or website front end applications which can be front faced by an internal load balancer

Q: How to setup MIG in Google Compute Engine?

Managed Instance groups (MIGs) use instance templates to create a group of instances, which means we setup an instance with a certain configuration and MIG uses that template to scale up the resources when the demand is higher and scale down the resources when demand is lower

• Step 1 - Create Instance templates Compute Engine >> Instance templates >> Define the machine and network configurations You can also define any startup script which helps in deploying additional softwares once the instance is deployed
• Step 2 - Create Managed Instance Group Compute Engine >> Instance Groups >> Create instance group
• Name —> Name of the instance group
• Instance template —> Defines which template to follow to create VMs
• Region & Zone —> Specifies which region/zone the VMs are to be created
• Autoscaling (min instances) —> The minimum number of VMs it can scale down to
• Autoscaling (max instances) —> The maximum number of VMs it can scale up to
• Autoscaling (Signal type) —> Specifies the decision criteria. For ex: If CPU utilisation is selected, MIG monitors the CPU consumption rate and decides whether to scale up or scale down
• Target utilisation —> Defines the threshold of signal type. Ex: 80% CPU utilisation. once this rate is reached, instance scales up

Q: What is Standby Pool in MIG?

One of the drawbacks always with manually controlled environments is cost inefficiency. We end up paying for idle time of the resources. With Standby Pool capability, it is now possible to stop, pause and resume VMs either manually or in automated way.

Imagine you have a busy cloud workload that sometimes needs more machines (VMs) to handle the spike. Instead of waiting for brand new VMs to start up slowly, you can have a standby pool of pre-configured VMs ready to jump in instantly.

Think of it like this:

• Your normal VMs are like regular employees,?working hard.
• Standby pool VMs are like trained interns,?waiting patiently for their turn.
• When workload increases,?instead of hiring and training new interns,?you simply call upon the standby pool.?They're already trained and ready to go!

Benefits of a standby pool:

• Faster scaling:?No waiting for new VMs to initialize,?saving precious time during peak loads.
• Improved performance:?Applications with long initialization times (downloading data,?caching,?installing software) run smoothly even with sudden spikes.
• Cost efficiency:?Standby pool VMs might cost slightly extra,?but it can prevent performance bottlenecks and lost revenue from slow scaling.

Q: What are the modes in Standby Pool and how it works?

Stopped VMs: These helpers are off duty, sleeping soundly and not costing you anything. Think of them as taking a long nap.

Suspended VMs: These helpers are on a short break, ready to jump back in quickly. They cost a little bit, but not as much as working VMs.

How it works:

1. When you need more VMs, the MIG first wakes up any idle VMs in the standby pool.
2. If still not enough, it turns on any VMs temporarily turned off in the standby pool.
3. If still not enough, it creates entirely new VMs.
4. Once the workload goes down again, it adds new VMs to the standby pool to refill it and then turns off these new VMs for later use.

Q: Are there any other key points to note while designing MIG’s with standby pool?

• As said previously, the advantage is faster scaling as the new VM creation takes a lot of time whereas restarting or waking up existing VM for scaling is extremely fast
• Also deleting the VM means that the data is lost, IP addresses are lost which requires reconfiguring in the dependent resources when a new VM is created, but pausing or stopping the VM will ensure the data is l=not lost, IPs are retained and VM is restored in the same state before it was stopped External IPs are not preserved for both suspended and stopped VMs if its ephemeral IP, but preserved if its a static IP Memory is not preserved for a stopped VM VM name, Internal IP, Static IP, disks, metadata etc are all preserved for both suspended and stopped VMs
• Batch processing jobs that run continuously over week days but not on weekends is one of the common use cases where this feature can be extremely handy along with development and test environments which can be stopped/paused during non working days
• VM can be suspended upto 60 days and beyond that MIG automatically terminates the VM, creates a new VM and fills up the empty space
• You can manually suspend and stop the VMs by selecting all the VMs and clicking on respective action button