Google Compute Engine
It's the Google Virtual Machine offering (as per EC2 in AWS), with full control over configuration.
VMs are considered resources for IAM, billing, etc.
- 1 Billing
- 2 VM lifecycle
- 3 VM creation
- 4 VM Images
- 5 VM families and types
- 6 GPU
- 7 VM tenancy
- 8 VM Instance Template
- 9 Storage
- 10 Snapshots
- 11 VM Instance Groups
- 12 VM maintenance
- 13 Other features of GCE
All Virtual Machines are billed per first minute an then on a second basis. VMs of predefined types are billed based on selected instance. They cost mostly less than equivalent custom machine type. VMs of custom types are billed per first minute an then on a second basis (CPU and RAM):
- Number of vCPUs: single hardware hyper-thread on the underlying processor.
- Gigabytes of RAM.
Additional billing for block storage(disks), not tied to machine definition.
Snapshots are also charged for amount used.
Unused static IP addresses are charged per hours.
Ingress traffic is free. Egress traffic may be billed depending on egress type used.
- Committed use (for a period of time) within the region. Up to 57% discount on comitment for 1 year to 3 years. Upon purchase, a monthly fee will be billed. Not available for shared core VMs.
- Sustained use.
- Inferred instance: an inferred instance combines multiple, non-overlapping instances in the same zone into a single instance for billing, helping to obtain a sustained use discount.
- Preemptible VM: they can be stopped anytime and they only live for 24 hours.
- Standard: they run until you stop them and they are maintained in stopped status.
- Much cheaper than standard and sold on excess capacity.
- They can be stopped anytime and they only live for 24 hours. Not covered under SLA.
- Wonderful for short term workloads, batch processing or spikes in traffic.
- Charged if started at least for 10 mins.
- Once they are to stop, Compute Engine sends signal for preemption to VM with a 30 seconds of short notice.
- Cannot live migrate nor auto restart.
- When a GPU is attached to the VM, the quota will be used.
- Average preemption rate varies 5-15% per seven days per project.
Standard VM keeps running until stopped by user, they can be restarted. Preemptible VMs are stopped/deleted: they run and they are then terminated (what happens before, 24 hours of spike in usage) and immediately deleted. VM Status are the following ones:
- VM created
- VM started
- VM migrated: seamless migration of VMs to new hardware.
- Preemptible VMs stopped/deleted.
- VM stopped: user is only billed for storage, IP addresses, etc., but not vCPU nor RAM.
- VM deleted: decide what to do with resources, include boot disk.
VMs are created:
- From VM images
- From docker containers:
- Using a single docker container image (in remote repository) and a configuration so that container image runs in the VM.
- The VM boots under Container Operative System (COS), a Google-maintained image with minimal docker.
- From VM instance templates.
- From existing disks.
It is possible to create images from disks.
VM Image Types
- Public Images: maintained by Google. Linux & Windows support. Stored in Google Cloud Storage Image Service.
- Third party images with common applications: ERPs, CRMs, etc.
- Private Images: maintained by user. Custom. Stored in Google Cloud Storage Image Service.
VM families and types
- Shared-core: small and micro. They allow small periods of bursting.
- Second Generation:
- E2: CPU platform selection based on availability.
- N2: Powered by Intel Cascade Lake CPU platform.
- N2D: Powered by AMD EPYC Rome CPU platform. Shared core not available.
- First generation:
- N1: Powered by Intel Skylake CPU platform or predecessors. Standard up to 6,5GB/vCPU and 96vCPUs
Up to 3,75 TB Machine Types:
- Mega memory
- M1: Powered by Intel Skylake CPU platform or predecessors.
Up to 60 vCPU. Machine Types:
- C2: Powered by Intel Cascade Lake CPU platform.
Use them for compute workloads, or graphics workloads.
You must have GPU quota before you can create instances with GPUs.
Instances with GPUs have a maximum number of vCPUs per GPU attached, depending of GPU family.
Not available to shared-core machine types.
GPU instances cannot live migrate.
GPUs require device drivers in order to work properly. User must ensure that drivers are installed an configured properly.
- Shared tenancy (default)
- Sole tenancy, so underlying hardware machine is used on exclusivity basis. It is useful for compliance requirements or controlling performance.
VM Instance Template
Define the machine type, image, zone and other instance in a managed instance group.
Based on SUN device (Storage Network) living close to the VM, backed by HDD (Spinning Magnetic Media) or SSD (Solid State Disks).
Performanced in IOPS (operations per second) and Throughput (data read/written by a sustained/burst operation).
- Attached network interfaces
- Persistent and independent of compute (instance).
- Used as Bootable, Snapshots.
- Resize dynamically.
- Attached to multiple VMs for read only data.
- Automatic Encryption (you can use your own key).
Persistent Disk Types
- Standard (HDD)
- Balanced (SSD): SSD that balances performance and cost (cheaper but less throughput per GB and less maximum read IOPS per instance).
Local Storage: Local SSD Scratch Disks
375GB SSD physically attached to the system running VM (no network).
- Ephemeral: data stays on restart but is lost on stop.
- Up to 24 disks per VM (9000GB).
- SCSI or NVMe (which have more IOPS and thoughput but require using a SSSOO image with additional drivers).
- Ultra high performanced, good for temporary workloads or caches.
- They can not live migrate.
- Not available to shared-core machine types.
You can allocate some of RAM memory to create a RAM disk with exceptionally low latency and high throughput.
- RAM disks work well when your application expects a file system structure and cannot simply store its data in memory.
- RAM disks share instance memory with your applications, so instances do need to have enough memory.
- They are not replicated.
- Ephemeral: data is lost on stop, restart, terminate, and they are erased in case of host error or system restart.
Backup/recovery and replication with snapshots. They are incremental. Charged on amount used.
VM Instance Groups
They can be managed (either zonal or regional) or unmanaged.
VM Managed Instance Groups
Use Identical instance resources.
They can be used for auto-scaling and they do support rolling updates.
They can be either zonal or regional.
Changes to instances are propagated to rest of instances of the group.
They are used for load balancing only similar resources.
VM Unmanaged Instance Groups
Non-identical instance resources.
They can not be used for auto-scaling and they do not support rolling updates.
Rolling updates can not be used.
Changes to instances are not propagated to rest of instances of the group.
They are used for load balancing pre-existing resources or groups of dissimilar resources.
Live Migration (transparent maintenance): during maintenance, VM is migrated to another hardware without stopping or restarting.
Migration is seamless for most of resources (GPUs cannot be migrated), so no impact for processes running within VMs. Adding a disk can be done without restarting. However, GPUs cannot be migrated.
You can check metadata to check if VM is in live migration.
Changing VM type requires restarting the VM.
Connecting to VM
- Linux: ssh from Google Cloud Console (key is not required), SSH from Google CloudShell, SSH via Cloud SDK. Need firewall opened to allow tcp:22
- Windows (needs to set password): rdp, powershell. Need firewal opened to allow tcp:3389.
Other features of GCE
- Confidencial VM service: VM memory is encrypted.
- Mark boot disk for deletion.
- Data encryption with keys provided by user, managed by user or managed by Google.
- Firewall policies for incoming HTTP and HTTPS traffic.
- Global scoped images.
- It supports CDN
- High Network Performance.
- It supports Global load balancing.
- It supports autoscaling.