4.1 Compute Engine Architecture, Sizing & Managed Instance Groups

Compute Engine Architecture, Sizing & Managed Instance Groups

Architectural Objective: Compute Engine provides flexible, enterprise-grade virtual machines running on Google's global infrastructure. A Google Professional Cloud Architect must master workload-specific machine family selection, cost-optimized rightsizing, instance lifecycle management, and high-availability patterns using Regional and Stateful Managed Instance Groups (MIGs).

---

Compute Engine Machine Families & Architectural Sizing

Selecting the optimal machine family is the foundation of cost and performance optimization in Compute Engine. Google Cloud categorizes machine types into five primary architectural families, each engineered for distinct workload characteristics:

+---------------------------------------------------------------------------------------------------+
|                             COMPUTE ENGINE MACHINE FAMILY TAXONOMY                                |
+---------------------------------------------------------------------------------------------------+
| 1. GENERAL-PURPOSE     | E2 (Cost/Burstable) | N2/N2D/N4 (Balanced) | C3/C4 (Titanium DPU / High IOPS)  |
| 2. COMPUTE-OPTIMIZED   | C2 / C2D (High Single-Thread Performance, HPC, EDA, Gaming Servers)      |
| 3. MEMORY-OPTIMIZED    | M1 / M2 / M3 (In-Memory Databases, SAP HANA, Large Scale Analytics)      |
| 4. ACCELERATOR-OPTIMIZED| A2 (NVIDIA A100) | A3 (NVIDIA H100) | G2 (NVIDIA L4 AI Inference / Media)|
| 5. STORAGE-OPTIMIZED   | Z3 (Dense High-Throughput NVMe Local SSDs, Real-Time Analytics)          |
+---------------------------------------------------------------------------------------------------+

Detailed Machine Family Comparison

Custom Machine Types

When a workload requires a non-standard memory-to-core ratio (for example, a memory-intensive caching daemon requiring 4 vCPUs and 32 GB RAM), provisioning a standard n2-standard-8 (8 vCPUs, 32 GB RAM) results in paying for 4 unutilized vCPUs. Compute Engine allows architects to define Custom Machine Types (custom-vCPUs-RAM) in the N1, N2, and N2D series.

• Licensing Optimization: Custom machine types are especially valuable for third-party commercial software licensed on a per-core basis (such as Microsoft SQL Server or Oracle Database). By provisioning an n2-custom-4-32768 instead of an n2-standard-8, the enterprise cuts software licensing fees in half while maintaining the necessary 32 GB memory footprint.
• Extended Memory: If a machine requires more than 8 GB of RAM per vCPU, architects can attach extended memory up to maximum platform thresholds without adding more vCPUs.

Instance Templates & Configuration Overrides

• Instance Templates: Immutable, reusable global resources that define machine type, boot image, persistent disk attachments, network interfaces, subnets, service accounts, and startup scripts. Because templates are immutable, updating a template requires creating a new version (instance-template-v2) and updating the Managed Instance Group target.
• Configuration Overrides (All-Instances vs. Per-Instance):
  • All-Instances Configuration: Applies baseline metadata, labels, and service accounts across the entire group.
  • Per-Instance Configurations (PICs): Allows architects to attach specific persistent disks, reserve static internal/external IP addresses, or apply unique metadata keys to individual named instances within an otherwise uniform Managed Instance Group without breaking MIG membership.

---

Managed Instance Groups (MIGs): Zonal vs. Regional Architectures

A Managed Instance Group (MIG) pools identical Compute Engine instances created from a shared instance template, providing automated provisioning, auto-healing, auto-scaling, and rolling updates.

ZONAL MANAGED INSTANCE GROUP                  REGIONAL MANAGED INSTANCE GROUP (HIGH AVAILABILITY)
┌──────────────────────────────────────┐     ┌────────────────────────────────────────────────────────┐
│ Region: us-central1                  │     │ Region: us-central1                                    │
│  ┌────────────────────────────────┐  │     │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
│  │ Zone: us-central1-a            │  │     │  │ Zone: -a     │  │ Zone: -b     │  │ Zone: -c     │  │
│  │  [VM-1]  [VM-2]  [VM-3]  [VM-4]│  │     │  │  [VM-1]      │  │  [VM-2]      │  │  [VM-3]      │  │
│  └────────────────────────────────┘  │     │  │  [VM-4]      │  │  [VM-5]      │  │  [VM-6]      │  │
│  [!] Single Zone Outage = Total Down │     │  └──────────────┘  └──────────────┘  └──────────────┘  │
└──────────────────────────────────────┘     │  [OK] Zone Outage: Traffic shifts across healthy zones │
                                             └────────────────────────────────────────────────────────┘

Architectural Comparison: Zonal vs. Regional MIGs

Auto-Healing and Health Checks

MIGs integrate with Google Cloud Application-Level Health Checks. When an instance fails health check probes (e.g., consecutive HTTP 500 responses or TCP connection timeouts on /healthz):

1. The health check marks the instance UNHEALTHY.
2. The MIG controller gracefully shuts down and recreates the VM in place, preserving its configuration and IP addressing if configured as stateful.
3. Initial Delay (Cool-Down Period): Architects must configure an adequate initialDelaySec (e.g., 60–180 seconds). This instructs the auto-healer to ignore health check failures while the VM is completing OS boot, pulling container images, and running startup scripts, preventing infinite recreation loops.

---

Stateful Managed Instance Groups

While traditional MIGs are designed for stateless applications where instances can be destroyed and recreated arbitrarily ("cattle"), Stateful MIGs accommodate workloads that require persistent state, fixed identity, or localized storage across VM lifecycles.

+-----------------------------------------------------------------------------------+
|                         STATEFUL MIG PERSISTENCE GUARANTEES                       |
+-----------------------------------------------------------------------------------+
| 1. STATEFUL DISKS     | Preserves data disks across recreation, updates, healing. |
| 2. STATEFUL IPS       | Retains static internal / external IPs on VM restart.     |
| 3. STATEFUL METADATA  | Preserves unique node-specific configuration keys.         |
| 4. INSTANCE IDENTITY  | Preserves stable instance names (e.g., kafka-broker-0).   |
+-----------------------------------------------------------------------------------+

When to Deploy Stateful MIGs

• Stateful Clustered Databases: Apache Cassandra nodes, Apache Kafka brokers, Elasticsearch clusters, and ZooKeeper ensembles.
• Legacy Monoliths: Enterprise applications that store local configuration files or write transaction logs to a dedicated persistent disk that cannot be lost during OS updates.
• Fixed Network Endpoints: Internal systems that require static private IP addresses for legacy firewall whitelist rules.

Stateful vs. Stateless Auto-Healing Behavior

• Stateless MIG: When an instance becomes unhealthy, the MIG deletes the VM, wipes the root and attached disks, and boots a brand-new instance from the template.
• Stateful MIG: When an instance becomes unhealthy, the MIG stops the VM, detaches the stateful persistent disk, recreates the underlying compute instance, reattaches the exact stateful disk with all existing data intact, and reassigns the same private/public IP address.

---

Rolling Update Strategies & Lifecycle Orchestration

Deploying new software versions or OS patches to a MIG requires updating the underlying instance template and executing a rolling update. Google Cloud provides two update operational modes:

+-----------------------------------------------------------------------------------+
|                         MIG ROLLING UPDATE CONFIGURATION                          |
+-----------------------------------------------------------------------------------+
| PROACTIVE UPDATE   | MIG immediately replaces/updates instances automatically.    |
| OPPORTUNISTIC      | MIG applies new template ONLY when instances are recreated   |
|                    | manually, scaled out, or replaced by auto-healing.           |
+--------------------+--------------------------------------------------------------+
| maxSurge           | Number of EXTRA instances created above target size.         |
| maxUnavailable     | Number of instances that can be OFFLINE during update.       |
+-----------------------------------------------------------------------------------+

Sizing maxSurge and maxUnavailable for Production Workloads

Instance Lifecycle Stages

Architects must understand the state machine of Compute Engine instances:

1. PROVISIONING: Hardware resources (CPU, RAM, Disks) are being allocated on the physical host.
2. STAGING: Resources are allocated; the hypervisor is booting the kernel and initializing startup scripts.
3. RUNNING: The instance is actively executing; billable compute and OS licensing apply.
4. STOPPING: Shutdown scripts are executing; guest OS is terminating processes.
5. TERMINATED: VM is completely halted. vCPU/RAM are released (no compute billing); attached Persistent Disks and reserved Static IPs continue to incur standard storage/networking charges.

---

Spot VMs and Graceful Preemption Handling

Spot VMs are surplus Compute Engine capacity offered at 60% to 91% discounts relative to on-demand pricing. Spot VMs have no maximum runtime limit (unlike legacy 24-hour Preemptible VMs), but Google Cloud can reclaim them at any moment when capacity is required by standard on-demand customers.

+-----------------------------------------------------------------------------------+
|                         SPOT VM PREEMPTION SEQUENCE (30 SECONDS)                  |
+-----------------------------------------------------------------------------------+
| Google Reclaims Capacity ──> ACPI Shutdown Event Dispatched ──> Guest OS Catches  |
|                                                                 Signal            |
|                                                                       │           |
|                                                                       v           |
| 1. Stop accepting new tasks / unregister from queue.                  [ 30 SEC    |
| 2. Flush memory buffers and active transactions.                       COUNTDOWN ]|
| 3. Write checkpoint state to Cloud Storage / Firestore.              │           |
| 4. Cleanly exit container / OS shutdown.                              v           |
|                                                                 VM Terminated     |
+-----------------------------------------------------------------------------------+

Designing Resilient Spot Workloads

1. 30-Second ACPI Signal: When Google Cloud preempts a Spot VM, it sends an ACPI Power Off signal. The guest OS receives this event and triggers configured /etc/acpi/events handlers or standard shutdown scripts.
2. Graceful Teardown Script: Shutdown scripts must execute within 30 seconds. For distributed workloads (e.g., Apache Spark or rendering nodes), the script flushes intermediate calculations to Cloud Storage or commits job status back to a Cloud Pub/Sub queue.
3. MIG Mixed-Instance Policies: In production batch architectures, architects configure MIGs with a combination of standard on-demand instances (providing a guaranteed minimum serving floor) and Spot instances for elastic bursting.

---

Sole-Tenant Nodes: Enterprise Isolation, BYOL & Maintenance

Sole-Tenant Nodes are physical Google Cloud Compute Engine servers dedicated entirely to a single enterprise customer's virtual machines. They provide hardware-level physical isolation from all other cloud tenants while retaining Compute Engine APIs and elasticity.

+-----------------------------------------------------------------------------------+
|                   PHYSICAL SOLE-TENANT NODE SERVER (DEDICATED HOST)               |
|   ┌───────────────────────────────────────────────────────────────────────────┐   |
|   │ Enterprise Tenant A Virtual Machines Only:                               │   |
|   │  [VM-1: Windows Server (BYOL)]  [VM-2: Windows Server]  [VM-3: SQL Server]│   |
|   │  - No noisy neighbors                                                     │   |
|   │  - Physical core visibility for licensing compliance                      │   |
|   └───────────────────────────────────────────────────────────────────────────┘   |
+-----------------------------------------------------------------------------------+

Primary Architectural Use Cases

1. Strict Regulatory Compliance & Security: Workloads in healthcare (HIPAA), government (FedRAMP High), or banking that legally mandate single-tenant physical hardware separation.
2. Bring Your Own License (BYOL): Enterprise software (Microsoft Windows Server, SQL Server, Red Hat Enterprise Linux) licensed per physical core, socket, or processor. Sole-tenant nodes allow enterprises to view physical core mappings to satisfy licensing audit requirements.
3. Host Maintenance Policies: Architects can control how Google performs physical hardware maintenance on the host:
   • Migrate in Group (Default): VMs automatically live-migrate to another sole-tenant node within the same node group during hardware maintenance, ensuring 100% continuous uptime.
   • Restart in Place: VMs shut down and restart on the same physical host once maintenance completes (required for strict software licenses tied to physical CPU IDs).

---

Concrete Architectural Scenario: Clustered Messaging & Analytics Pipeline

Scenario Profile

• Workload: Enterprise Kafka cluster processing 250,000 telemetry messages/sec alongside a stateless data transformation worker fleet.
• Availability SLA: 99.99% availability with zero message loss.
• Budget Constraint: Maximize compute cost efficiency without risking cluster integrity.

Solution Architecture Blueprint

1. Kafka Broker Tier: Deployed across a Regional Stateful Managed Instance Group in us-east4 spanning zones -a, -b, and -c. Each broker is assigned a Stateful Persistent Disk (SSD) and a Stateful Static Internal IP. When an auto-healing or rolling OS update event occurs, the MIG reattaches the exact storage volume and IP, preventing Kafka partition rebalancing storms.
2. Worker Processing Fleet: Deployed in a Regional Stateless MIG utilizing Spot VMs with an autoscaling policy tied to the Kafka consumer group lag metric. An ACPI shutdown hook checkpoints in-flight batch state to Cloud Storage within the 30-second preemption notice window.
3. Licensing Compliance: Dedicated legacy database hosts are placed on a Sole-Tenant Node Group with a Migrate in Group maintenance policy to utilize existing per-core Microsoft SQL Server BYOL licenses.

---

[!IMPORTANT] Exam Watch: On the Google Professional Cloud Architect exam, whenever a scenario mentions running stateful clustered systems (like Kafka, Cassandra, or Elasticsearch) on Compute Engine that require persistent disk attachments and static IPs across auto-healing cycles, choose Stateful MIGs. If the question involves minimizing licensing costs for software licensed per physical core, choose Sole-Tenant Nodes with BYOL. If a question describes batch or fault-tolerant processing with strict budget limits, choose Spot VMs with graceful shutdown handling.