Google Compute Engine (GCE) is part of Google’s Infrastructure-as-a-Service (IaaS) offering, where you can build high-performance, fault-tolerant, massively scalable compute nodes to handle your application’s needs. Virtual Machine instances are provisioned in GCE and can be pre-packed or fully customized. In this article, we’ll cover some of the fundamentals of VM Instances within GCE.
Virtual Machine (VM) Instances
The terms Virtual Machine and Instance are synonymous in GCP. VM Instances are comprised of on Operating System and infrastructure resources such as CPU, Memory, Disk, and Networking. Creating VM instances can be done using the GCP console (console.google.com), using the command line via Cloudshell or SDK, or via the REST API.
When creating a VM instance, you have the option of choosing a predefined machine type or a custom machine type.
Machines types are templates of virtualized hardware that will be available to the VM instance. These resources include the CPU, Memory, Disk capabilities, and so on.
Predefined machine types are managed by Google, and are categorized by 4 types:
- Standard machine type
- Ideal for typical balanced instances with respect to RAM and CPU
- Have 3.75GB of RAM per virtual CPU
- High-memory machine types
- Ideal for applications that require more memory
- Have 6.5GB of RAM per virtual CPU
- Shared-core machine types
- These machines have one virtual CPU on a single hyper-thread of a single host CPU that is running the instance. Ideal for non-resource intensive applications.
- Very cost effective
- Large machine types
- Ideal for resource-intensive workloads
- Up to 1TB of memory
Custom machine types
Say that none of these predefined machine types match your requirements. No worries, you can completely customize the machine type to fit your vCPU and Memory needs. This is ideal if you have a workload that maybe requires more processing power or memory than what is offered by the Google-provided types, or if you need GPUs. You may pay a small premium to use custom machine types.
After choosing a machine type which covers CPU and Memory, it’s time to choose a disk option. You have a few options when choosing a disk type for your VM instance. The disk you choose will be your single root disk in which your image is loaded during the boot process. Do you choose a persistent disk or a local disk?
Persistent disks are network-based “disks” abstracted to appear as a block device. Data is durable, meaning the data will remain as you left it after reboots and shutdowns. Available as either a standard hard disk drive or as a solid state drive (SSD), persistent disks are located independently of the VM instances, which means they can be detached and reattached to other instances. You have the option to keep your disk when deleting your instance, or having it terminated along with the instance.
- Standard persistent disks
- Ideal for efficient and reliable block storage
- Max 64TB per instance
- Only available within a single zone
- SSD persistent disks
- Ideal for fast and reliable block storage
- Max 64TB per instance
- Only available within a single zone
Other key features:
- Redundancy is built-in, protecting your data from unforeseen failures.
- GCE automatically encrypts all data on the persistent disk, protecting integrity with cipher keys
- You can resize disks and migrate instances with zero downtime
- Disks scale in performance as capacity increases
- Supports snapshots
Local SSD disks are physically attached to VM instances. These will offer the highest possible IOPS and are used for seriously intensive workloads.
- Local SSD
- Ideal for very high-performance local block storage
- Available as SCSI or NVMe
- Max 3TB (which is a total of eight 375GB disks)
- Available only to a single Instance, meaning it cannot be reattached elsewhere
- Only Persistent if you do not stop or terminate your instance.
- Does not support snapshots
More often than not, you’ll be choosing a Standard persistent disk for your VMs. So, what’s next?
Images contain a bootloader, Operating System, file system structure, and any software customizations needed for your deployment. The image describes what actually gets loaded onto the root disk. Tons of public images are available from Google and other authorized third-party vendors. Google Compute Engine (GCE) uses the selected image to create a persistent boot disk for each instance.
Some public images include:
- Container-Optimized OS from Google
- Windows Server 2008, 2012, 2016
- SQL Server on Windows Server
Alternatively, you can create your own custom images! Custom images can be created from a VM in your environment that has all the necessary settings and additional software configured. You can even import custom images from on-prem environments, or another cloud provider such as AWS.
You actually choose the zone in the very beginning of creating a new instance. We talk more about Regions and Zones in another article, but what is important to know here is the different CPU architectures in each zone which could be a deciding factor where you run your applications. The processor families include Broadwell, Sandy Bridge, Skylake, Ivy Bridge, and Haswell. If you have a specific requirement for a specific processor, just visit documentation to validate zone availability. Otherwise, just pick the zone that is closest to you or your customers.
What if I choose a zone and want it changed afterward?
You can absolutely move VM instances to another zone, but it will require a short outage. To do this manually, you’ll snapshot the disk on the instance you wish to move. Next, create a new disk in the desired zone from the snapshot. Create a new VM instance in the new zone and attach the new disk. Update any IPs and references for a clean migration.
Alternatively, you can do this automatically with the gcloud compute instances move command.
Networking & Firewall
Each VM will have a single interface by default. This interface can be placed in a particular subnet of a particular network with respect to the zone that you choose. You can add multiple interfaces if desired, but that is more of an advanced topic.
By default, the primary internal IP will be set to Automatic (DHCP) and the External IP set to Ephemeral (DHCP).
A couple of easy checkboxes can get your VM setup with the proper firewall rules for HTTP and HTTPS traffic as well.
There are three categories under the Availability Policy when creating a new VM — Preemptibility, Automatic Restart, and On host maintenance.
Off by default, a preemptible VM is an affordable, short-lived instance ideal for batch jobs or fault-tolerant workloads. They’re up to 80% cheaper than regular instances, so if your application can handle random the termination of VMs at any time, then give this a look. Some common applications that use preemptible VMs are modeling or simulations, rendering, media transcending, big data, continuous integration, and web crawling.
On by default, this feature of GCE can automatically restart VM instances if they are terminated due to a non-preemption, non-user-initiated reason. Some examples are due to maintenance events or hardware/software failures.
On host maintenance
On by default, this feature of GCE can automatically migrate your VM instances to other hardware during infrastructure maintenance periods to ensure your VMs operate with no downtime. This is called Live Migration and is a key differentiator of GCP. Alternatively, you can set this to turn off the VM.
There are various other options you can choose from, such as automation with startup scripts, metadata tags, SSH key, and so on, but these are beyond the scope of fundamentals.
Accessing the VM
After creating the VM, you’ll certainly want to access it someway – but how? Well, if your VM is running Linux, you can access it via the console through SSH, from another VM running CloudShell via the Cloud SDK, or from your computer via SSH. If your VM is running Windows, you can use an RDP client or Powershell terminal.
Lastly, let’s look at some GCE fundamentals when it comes to pricing. Google handles charges and discounts differently than AWS and Azure. With GCP you’re always billed for the first 10 minutes and then for each minute afterward for the life of the machine, rounded up to the nearest minute. The console will summarize this into costs per month so you don’t have to do the per-minute math.
Discounts are extended for sustained use, meaning if you commit to keeping instances alive for some period of time, a discount will be applied.
Another neat discount is what Google refers to as Inferred instance discounts. If you have multiple VMs of the same machine type in the same zone, they are combined as if they were a single machine, giving you the maximum available discount.
A sustained usage discount applies to custom machine types as well. Google Compute Engine will perform calculations to match the best qualifying discount for usage in the month. In the example given in their documentation, two custom machine type instances are split to provide discounts on vCPU and Memory when stretched across the whole month instead of just 15 days.
In this article, we looked at some of the fundamental concepts of Google Cloud Platform’s (GCP) Compute Engine (GCE). You should have a basic understanding of VM instances in GCE, with enough knowledge to be dangerous in your own lab. That said, if you haven’t already, head over to https://console.cloud.google.com/ to create yourself a free account and get started with GCP!