1. Home
  2. Training Library
  3. Google Cloud Platform
  4. Courses
  5. Google Cloud Platform: Systems Operations

Disks and Images

Contents

keyboard_tab
Introduction
1
Course Introduction
PREVIEW1m 53s
2
Getting Started
PREVIEW9m 27s

The course is part of these learning paths

Google Cloud Platform for System Administrators
course-steps 3 certification 1 lab-steps 4 quiz-steps 3
Google Cloud Platform for Solution Architects
course-steps 3 certification 1 lab-steps 4 quiz-steps 3
Google Cloud Platform Fundamentals
course-steps 2 certification 1 lab-steps 3 quiz-steps 2
more_horiz See 2 more
play-arrow
Start course
Overview
DifficultyIntermediate
Duration1h 49m
Students2490
Ratings
4.9/5
star star star star star-half

Description

Google Cloud Platform Systems Operations

There are a lot of different options, across a variety of cloud platforms that are well suited for running specific workloads, such as web applications. Things such as Google App Engine, AWS Elastic Beanstalk, Azure App Services: Web Apps, among others.

However, there are still plenty of times where we need to setup our own infrastructure. And so cloud vendors offer IaaS (infrastructure as a service) options. Google provides us with Compute Engine which allows us to create virtual machines, custom images, snapshots, networks, auto-scalers and load balancers.

If we're going to create and implement an application on the Google Cloud Platform system operations, then understanding these services are going to help us to create highly available, highly scalable applications.

All the major cloud providers offer the ability to setup virtual machines, networks, auto-scalers and load balancers. Where the Google Cloud is different is in the speed of creating and starting up virtual machine instances. As well as the massively scalable software-based, global load balancer; which doesn't require pre-warming. Google also offers per-minute billing for VM instances, after the first 10 minutes.

So Google has a lot to offer. And if you're looking to learn more about the Google Cloud systems operations, then this may be the course for you.

What exactly will we cover in this course?

Course Objectives: Google Cloud Platform system operations 

By the end of this course, you'll know:

How to use Compute Engine to create virtual machines
How to create disk snapshots
How to create images
How to create instance templates and groups
How to create networks
How to use the auto-scaler and load balancer
Intended Audience

This is an intermediate level course because it assumes:

You have at least a basic understanding of the cloud
You’re at least familiar with general IT concepts

What You'll Learn

Summary A review of the course

Lecture What you'll learn
Intro What will be covered in this course
Getting Started An introduction to the Google Cloud Platform
Networking How to create and secure Cloud Networks
Disks and Images An overview of disk types and images
Authorization and IAM How to authenticate and authorise users
Disk Snapshots How to use snapshots for point-in-time backups
Cloud Storage Overview A refresher on Cloud Storage
Instance Groups How to manage instances with managed and unmanaged groups
Cloud SQL Overview A quick primer on how to use Cloud SQL
Startup and Shutdown Scripts Using startup scripts to provision machines at boot time
Autoscaling How to automatically add and remove instances
Load Balancing How to balance traffic across instances
Putting It All Together A demo of how to use some of the services we've learned about

 

Transcript

Welcome back. In this lesson we'll be talking about persistent disks, SSDs, RAM disks, boot disks, and virtual machine images. Let's jump right into it.

Persistent disks are important because they allow us to store the operating system and/or any persistent data that we'll need to run our server and applications. Persistent disks are zone based resources and they are encrypted by default. Each instance can have a maximum of 16 persistent disks and up to 64 terabytes of storage. And while typically disks would be attached to a single instance, it is possible to attach one to multiple instances in read only mode and that's kind of cool.

Let's head in to the console and check out how to actually create a new disk. So we start on the compute engine page and we click on the disks section on the left-hand side navigation and it starts with a name. And we're going to call ours app-disk. We'll skip the optional description. We don't need it for this demo. And then let's select a zone. We're going to leave the disk as a standard disk though we could use it as a SSD, but again for a demo that's not really needed. Then let's pick an image. We don't have any snapshots so we can't select that anyway. Let's use a ubuntu image. Okay, we need a size. That 10 gigs by default is going to be fine. Then we'll also leave the encryption set to automatic. Now the other option's for customer supplied where the customer can supply their own encryption key. The abilities to use your own encryption keys are going to be important for some companies for compliance reason, however, having Google automatically manage and rotate the keys is pretty valuable so I'm going to leave this by default. Okay and now we're going to create it and it'll take just a second. Okay there it is.

The question is what did we just do? We just created a boot disk that we can use for new instances. If we create an instance and we use this disk as its boot disk it's going to have ubuntu 1604 and it's going to be up and running with 10 gigs of space.

Okay. We'll get back to taking about disks and images, however, I want to take a quick detour and I want to talk about Solid State Drives which are abbreviated SSD. Sometimes you're going to need higher IOPS than the standard disks provide. IOPS stands for Input Output Operations per Second. So for this we can use SSDs. If you find that solid state drives aren't enough random IOPS and there's also an option for local SSDs.

Now local SSDs are physically attached to the server that hosts your virtual machine instance. Local SSDs have higher throughput and lower latency than standard persistent disks and SSDs. Though the data that you store on local SSDs persist only until you stop or delete the instance. They offer sub-millisecond latency with up to 680,000 read IOPS and up to 360,000 write IOPS. Local SSDs will be great when you need to do some caching operations and you don't want to use the system memory.

So if local SSDs aren't fast enough for you then there's always RAM disks. They're extremely fast, however, they're not persistent. So as soon as you reboot or shut down, anything that you have in that disk is going to be lost.

So if we look at the disk types in this comparison we can see that both standard and SSD disks offer all of the functionalities such as snapshotting, and as you know the SSD are great for random IOPS. And then when we move to the local SSDs and the RAM disks we lose most of the features in favor of speed. So you need to consider these trade offs when selecting which type you want to use and for which type of applications you want to use them for.

Okay. Let's jump back to talking about disks and images. Do you recall when we created that persistent disk we had to select an image? We touched on it previously, but what exactly is that image? That was an operating system image and what that means is it was the disk with a boot loader and operating system and a block device containing our file system. The specific image we used was for an ubuntu image and it came from the public images that Google provides, though if we had our own image we could also use that to create instances and it would be considered a private image because it's only accessible to our projects. We can create an instance based off of any images that we have access to, public or private.

Let's check out how to actually create an instance on the command line. Okay, so here's what we'll do, we'll use the gcloud command to create and instance so we'll use the compute instances create subcommand and we just need to pass them the name of our image, and it's going to take a moment to run. Okay. Now that it's done we've created an actual instance. It's up and running. We can connect to it and use it as we need to and if we look in the console we're going to see that this same image exists and there it is. We can create instances with the console just as easily as we can create them on the command line.

Here's a few other options we can use when creating instances. Now we can create an instance from an image within the project and we've seen that, from an image in an alternate project, from a URI for a tar file that's hosted on cloud storage. We could use an alias for the latest version of an image, and finally we have the option of specifying a specific version of an image. So we have a few different methods that we can choose from when selecting the images that we want to use for our instances.

Now we can also create our own images. If we need to create an image, we can create it based on a running instance. We'd use an existing base, as our example unbuntu, and then install whatever we need to before we delete the instance and use the keep disk option and that'll leave us with a boot disk image. There's also documentation to create something from scratch if we don't want to use one of the existing images.

Images are used for things such as a bootable "gold master" image for deployment, an image with standard tools for the development teams, an image with approved production software and libraries, or even a foundation for cluster deployments. And so having images with everything we need loaded on there is incredibly valuable, however, there are alternatives to doing it this way.

We could configure instances at boot time with start up scripts. And start up scripts are something we're going to cover later in the course. We can configure with provisioning tools such as Ansible, Chef, and Puppet. We could use docker and container images. So we have options for how we would get our images production ready and due to the effort involved in setting up custom images as golden images I tend to recommend some sort of boot time configuration. Now that depends on the circumstances because sometimes you're going to have a boot time configuration that adds too much boot time and so it's going to slow down the actual process of getting that instance into the load balancer and if you're seeing heavy traffic that might be a blocker. However, if your traffic increases fairly evenly then boot time configuration will allow you to get everything installed and configured on startup. And that'll make it more flexible to implement changes because once our configuration management code has been tested and deployed we can easily run it against the targets of our choosing.

Okay, let's wrap up this lesson by summarizing what we've covered so far. We talked about persistent disks and different disk types. We talked about standard hard disk drives and how they support things such as snapshots and encryption, however it won't be as fast as solid state drives or random IOPS. We talked about local and RAM disks which are very fast, however, don't support things such as snapshots. And we talked about how to create and use disk images that can be used as a base image. And then we wrapped up the discussion by talking about methods that would allow us to use a standard image and configure it at boot time.

Okay, in our next lesson we're going to talk about authorization and IAM. If you're ready to keep going then let's get started with the next lesson.

About the Author

Students37206
Courses16
Learning paths15

Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.