Google Compute Engine lets you create and run virtual machines on Google infrastructure. You can create virtual machines running different operating systems, including multiple flavors of Linux (Debian, Ubuntu, Suse, Red Hat, CoreOS) and Windows Server!

But once you've created the virtual machine, you'll probably want to attach large persistent disks to store data.

Follow along this lab to learn how to create persistent disks and attaching it to a virtual machine.

What you'll learn

What you'll need

How will you use this tutorial?

Read it through only Read it and complete the exercises

How would rate your experience with Google Cloud Platform?

Novice Intermediate Proficient

Codelab-at-a-conference setup

The instructor will be sharing with you temporary accounts with existing projects that are already setup so you do not need to worry about enabling billing or any cost associated with running this codelab. Note that all these accounts will be disabled soon after the codelab is over.

Once you have received a temporary username / password to login from the instructor, log into Google Cloud Console: https://console.cloud.google.com/.

Here's what you should see once logged in :

Note the project ID you were assigned ( "codelab-test003" in the screenshot above). It will be referred to later in this codelab as PROJECT_ID.

Navigate to the the Google Cloud Console from another browser tab/window, to https://console.cloud.google.com. Use the login credential given to you by the lab proctor.

Once the operations completes, you will do most of the work from Google Cloud Shell, a command line environment running in the Cloud.

This Debian-based virtual machine is loaded with all the development tools you'll need. It offers a persistent 5GB home directory, and runs on the Google Cloud, greatly enhancing network performance and authentication. This means that all you will need for this codelab is a browser (yes, it works on a Chromebook).

To activate Google Cloud Shell, from the developer console simply click the button on the top right-hand side (it should only take a few moments to provision and connect to the environment):

Once connected to the cloud shell, you should see that you are already authenticated and that the project is already set to your PROJECT_ID :

gcloud auth list

Command output

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)
gcloud config list project

Command output

[core]
project = <PROJECT_ID>

If for some reason the project is not set, simply issue the following command :

gcloud config set project <PROJECT_ID>

Looking for you PROJECT_ID? Check out what ID you used in the setup steps or look it up in the console dashboard :

IMPORTANT. Finally, set the default zone and project configuration:

gcloud config set compute/zone us-central1-f

You can pick and choose different zones too. Learn more about zones in Regions & Zones documentation.

Certain Compute Engine resources live in regions or zones. A region is a specific geographical location where you can run your resources. Each region has one or more zones. For example, the us-central1 region denotes a region in the Central United States that has zones us-central1-a, us-central1-b, us-central1-c, and us-central1-f.

Virtual machine Instances and persistent disks live in a zone, and these are referred to as zonal resources. For example, to attach a persistent disk to a virtual machine instance, both resources must be in the same zone.

First, let's create a Compute Engine virtual machine instance that only has a boot disk but no additional persistent disk storage.

In Cloud Shell, create a new virtual machine instance from the command line by using gcloud:

$ gcloud compute instances create gcelab --zone us-central1-c
Created [...].
NAME       ZONE           MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
myinstance europe-west1-c n1-standard-1             10.240.X.X  X.X.X.X        RUNNING

The newly created virtual machine instance will have a default 10 GB persistent disk as the boot disk.

Google Compute Engine provides persistent disks for use as the primary storage for your virtual machine instances. Persistent disk storage is network storage that can be attached to virtual machine instances. Like physical hard drives, persistent disks exist independently of the rest of your machine – if a virtual machine instance is deleted, an attached persistent disk continues to retain its data and can be attached to another instance.

Create a new disk:

$ gcloud compute disks create mydisk --size=200GB \
--zone us-central1-c
NAME   ZONE          SIZE_GB TYPE        STATUS
mydisk us-central1-c 5       pd-standard READY

Attaching the persistent disk

You can attach a disk to a running virtual machine. Let's attach the new disk to the virtual machine instance.

Attach the disk:

$ gcloud compute instances attach-disk gcelab --disk mydisk --zone us-central1-c
Updated [https://www.googleapis.com/compute/v1/projects/...].

That's it!

Finding the device in the virtual machine

The persistent disk is now available as a block device in the virtual machine instance. Let's take a look. First, SSH into the virtual machine:

$ gcloud compute ssh gcelab --zone us-central1-c
Warning: Permanently added 'X.X.X.X' (ECDSA) to the list of known hosts.
...
username@gcelab:~$ 

Let's find the disk device, it is located under /dev/disk/by-id/ as scsi-0Google_PersistentDisk_persistent-disk-1

username@gcelab:~$ ls -l /dev/disk/by-id/
lrwxrwxrwx 1 root root  9 Feb 27 02:24 google-persistent-disk-0 -> ../../sda
lrwxrwxrwx 1 root root 10 Feb 27 02:24 google-persistent-disk-0-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 Feb 27 02:25 google-persistent-disk-1 -> ../../sdb
lrwxrwxrwx 1 root root  9 Feb 27 02:24 scsi-0Google_PersistentDisk_persistent-disk-0 -> ../../sda
lrwxrwxrwx 1 root root 10 Feb 27 02:24 scsi-0Google_PersistentDisk_persistent-disk-0-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 Feb 27 02:25 scsi-0Google_PersistentDisk_persistent-disk-1 -> ../../sdb

Formatting and mounting the persistent disk

Once you find the block device, you can partition the disk, format it, and then mounting it. If you are familiar with Linux, you can easily use the utilities fdisk, mkfs, and mount.

First, make a mount point:

username@gcelab:~$ sudo mkdir /mnt/mydisk

Next, format the disk with a single ext4 filesystem using the mkfs tool. This command deletes all data from the specified disk:

username@gcelab:~$ sudo mkfs.ext4 -F -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/disk/by-id/scsi-0Google_PersistentDisk_persistent-disk-1

Finally, use the mount tool to mount the disk to the instance with the discard option enabled:

username@gcelab:~$ sudo mount -o discard,defaults /dev/disk/by-id/scsi-0Google_PersistentDisk_persistent-disk-1 /mnt/mydisk

That's it!

Automatically mount the disk on restart

The disk will not be remounted if your virtual machine restarts. To make sure the disk is remounted on restart, you'll need to add an entry into /etc/fstab. Add below the line that starts with "UUID=..." An example is provided below:

/dev/disk/by-id/scsi-0Google_PersistentDisk_persistent-disk-1 /mnt/mydisk ext4 defaults 1 1

Google Compute Engine can also attach local SSDs. Local SSDs are physically attached to the server hosting the virtual machine instance to which they are mounted. This tight coupling offers superior performance, with very high input/output operations per second (IOPS) and very low latency compared to persistent disks.

Local SSD performance offers:

These performance gains require certain trade-offs in availability, durability, and flexibility. Because of these trade-offs, local SSD storage is not automatically replicated and all data can be lost in the event of a host error or a user configuration error that makes the disk unreachable. Users must take extra precautions to backup their data.

This lab does not cover local SSDs. To maximize the local SSD performance, you'll need to use a special Linux image that supports NVMe. You can learn more about local SSDs in the Local SSD documentation.

You've learned about persistent disks and the key difference between persistent disks and local SSDs. You can easily use persistent disks to setup and configure your database servers.

What we've covered