Google Cloud – Compute Engine Instance Groups

• An instance group is a collection of virtual machine (VM) instances that can be managed as a single entity.
• Compute Engine offers two kinds of VM instance groups
  • Managed instance groups (MIGs)
    • allows app creation with multiple identical VMs.
    • workloads can be made scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multiple zones) deployment, and automatic updating
  • Unmanaged instance groups
    • allows load balance across a fleet of self managed nonidentical VMs

Managed instance groups (MIGs)

• A MIG creates each of its managed instances based on the instance template and specified optional stateful configuration
• Managed instance group (MIG) is ideal for scenarios
  • Stateless serving workloads, such as a website frontend
  • Stateless batch, high-performance, or high-throughput compute workloads, such as image processing from a queue
  • Stateful applications, such as databases, legacy applications, and long-running batch computations with check pointing

Health Checking

• Managed instance group health checks proactively signal to delete and recreate instances that become UNHEALTHY.
• Load balancing health checks help direct traffic away from non-responsive instances and toward healthy instances; these health checks do not cause Compute Engine to recreate instances.
• Health checks used to monitor MIGs are similar to the health checks used for load balancing, with some differences in behavior.

High Availability & Autohealing

• Managed instance groups maintain high availability of the applications by proactively maintaining the number of instances and keeping the instances available, which means in RUNNING state.
• Application-based autohealing improves application availability by relying on a health checking signal that detects application-specific issues such as freezing, crashing, or overloading.
• If a health check determines that an application has failed on a VM, the MIG automatically recreates that VM instance.
• A MIG automatically recreates an instance that is not RUNNING. However, relying only on VM state may not be sufficient and should include check for application freezes, crashes, or runs out of memory.

Regional or Zonal groups

• Zonal MIG,
  • deploys instances to a single zone.
• Regional MIG
  • deploys instances to multiple zones across the same region
  • provides higher availability by spreading application load across multiple zones,
  • protects the workload against zonal failure
  • offer more capacity, with a maximum of 2,000 instances per regional group.

Load Balancing

• MIGs work with load balancing services to distribute traffic across all of the instances in the group.
• Google Cloud load balancing can use instance groups to serve traffic by adding instance groups to a target pool or to a backend service.

Scalability & Autoscaling

• MIGs provides scalability and supports autoscaling that dynamically adds or removes instances in response to increases or decreases in load.
• Autoscaling policy determines how the group would scale which includes scaling based on CPU utilization, Cloud Monitoring metrics, load balancing capacity,  or, for zonal MIGs, by using a queue-based workload like Pub/Sub
• Autoscaler continuously collects usage information based on the selected utilization metric, compares actual utilization to the desired target utilization, and uses this information to determine whether the group needs to remove instances (scale in) or add instances (scale out).
• Cool down period
  • is known as the application initialization period
• Stabilization period
  • For scaling in, the autoscaler calculates the group’s recommended target size based on peak load over the last 10 minutes which is called the Stabilization period
  • Using the stabilization period, the autoscaler ensures that the recommended size for the managed instance group is always sufficient to serve the peak load observed during the previous 10 minutes.
• Predictive autoscaling
  • helps to optimize your MIG for availability,
  • the autoscaler forecasts future load based on historical data and scales out a MIG in advance of predicted load, so that new instances are ready to serve when the load arrives.

Automatic Updating

• MIG automatic updater supports a flexible range of rollout scenarios to deploy new versions of the software to instances in the MIG such as rolling updates and canary updates.
• Speed and scope of deployment can be controlled as well as the level of disruption to the service.

Stateful Workloads Support

• MIGs can be used for building highly available deployments and automating operation of applications with stateful data or configuration, such as databases, DNS servers, legacy monolith applications, or long-running batch computations with checkpointing.
• Uptime and resiliency of such applications can be improved with autohealing, controlled updates, and multi-zone deployments, while preserving each instance’s unique state, including customizable instance name, persistent disks, and metadata.
• Stateful MIGs preserve each instance’s unique state (instance name, attached persistent disks, and metadata) on machine restart, recreation, auto-healing, and update events.

Preemptible Instances Groups

• MIG supports preemptible VM instances, which can help reduce cost.
• Preemptible instances last up to 24 hours and are preempted gracefully and the application has 30 seconds to exit correctly.
• Preemptible instances can be deleted any time, but autohealing will bring the instances back when preemptible capacity becomes available again

Containers

• MIG supports the deployment of containers to container-optimized OS that includes docker, if the instance template used specifies a container image.

Network and Subnet

• Instance template, used with MIG, defines the VPC network and subnet that member instances use.
• For auto mode VPC networks, the subnet can be omitted ; this instructs GCP to select the automatically-created subnet in the region specified in the template.
• If VPC network is omitted, GCP attempts to use the VPC network named default.

Unmanaged instance groups

• Unmanaged instance groups can contain heterogeneous instances that can be arbitrarily added and removed from the group.
• Unmanaged instance groups do not offer autoscaling, autohealing, rolling update support, multi-zone support, or the use of instance templates and are not a good fit for deploying highly available and scalable workloads.
• Use unmanaged instance groups, if load balancing needs to be added to groups of heterogeneous instances, or needs self managed instances

GCP Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. Your company’s test suite is a custom C++ application that runs tests throughout each day on Linux virtual machines. The full
   test suite takes several hours to complete, running on a limited number of on-premises servers reserved for testing. Your company
   wants to move the testing infrastructure to the cloud, to reduce the amount of time it takes to fully test a change to the system,
   while changing the tests as little as possible. Which cloud infrastructure should you recommend?
   1. Google Compute Engine unmanaged instance groups and Network Load Balancer.
   2. Google Compute Engine managed instance groups with auto-scaling.
   3. Google Cloud Dataproc to run Apache Hadoop jobs to process each test.
   4. Google App Engine with Google Stackdriver for logging.
2. Your company has a set of compute engine instances that would be hosting production-based applications. These applications
   would be running 24×7 throughout the year. You need to implement the cost-effective, scalable and high availability solution even
   if a zone fails. How would you design the solution?
   1. Use Managed instance groups with preemptible instances across multiple zones
   2. Use Managed instance groups across multiple zones
   3. Use managed instance groups with instances in a single zone
   4. Use Unmanaged instance groups across multiple zones