Unmanaged Instance Groups

GCP Compute Engine Instance Groups

~ jayendrapatil ~ Leave a comment

GCP – 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 zone) deployment, and automatic updating
    • Unmanaged instance groups
      • allows load balance across a fleet of VMs that you manage yourself which may not be identical

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
Use a managed instance group to build highly available deployments for stateless serving, stateful applications, or batch workloads.

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. You may want to recreate instances when an application freezes, crashes, or runs out of memory.

Health Checking

  • Managed instance group health checks proactively signal to delete and recreate instances that become UNHEALTHY.
  • Health checks used to monitor MIGs are similar to the health checks used for load balancing, with some differences in behavior.
  • 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.

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

Automatic Updating

  • MIG automatic updater supports a flexible range of rollout scenarios to deploy new versions of the software to instances in your 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 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 if you need to manage the instances yourself.