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
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
deploys instances to a single zone.
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.
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
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.
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.
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
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.
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?
Google Compute Engine unmanaged instance groups and Network Load Balancer.
Google Compute Engine managed instance groups with auto-scaling.
Google Cloud Dataproc to run Apache Hadoop jobs to process each test.
Google App Engine with Google Stackdriver for logging.
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?
Use Managed instance groups with preemptible instances across multiple zones
Use Managed instance groups across multiple zones
Use managed instance groups with instances in a single zone
Use Unmanaged instance groups across multiple zones