Hello, my name is Jay Judkowitz.
I'm the product manager for Google Cloud Platform block
storage products.
I'm here with some news, technical details,
and best practices about block storage
in Google Cloud Platform.
At Google, we're always excited to bring new storage offerings
to the cloud.
That's because it's all based on the great technology we've
built in-house to run some of the largest and most successful
applications on the internet.
When you use Google Cloud, you're
taking advantage of the same great storage infrastructure
as we do at Google.
Block storage in the cloud is general-purpose storage
that you attach to a virtual machine that
appears as a disk drive to the VM.
You generally format it with some file system
and write files or databases to it.
It's what you use to create your own self-managed data stores.
This section will announce two new pieces of news
about block storage in Google Cloud,
and quickly describe the three block storage options
that we now have.
Cloud Platform offers three types of block storage.
The key difference between them is how many
I/Os per second, or IOPS, can be supplied
by each gigabyte of storage.
Higher IOPS per gigabyte trade off
against cost and flexibility.
The first option, Standard Persistent Disk, or PD,
has been around since Google Compute
Engine was first released.
It utilizes networked hard drives.
It's designed for security, high availability,
and consistent performance.
For use cases that need up to, say, two
random read IOPS per second per gigabyte, this option is ideal.
You get steady performance at a low price.
The second option, SSD Persistent Disk,
we're pleased to announce is in general availability now.
It's like Standard PD, but backed by network SSD.
As a result, you have a higher cost
but a higher performance per gigabyte.
Use it like you would Standard PD, but in cases where you need
between two and 30 IOPS per gig.
The third option is not generally available,
but is now accepting trusted testers.
It's a local SSD option.
It offers the highest possible performance,
but has availability, durability, and flexibility
trade-offs I'll discuss shortly.
Before we get too deep into the numbers,
let's give a quick overview of the similarities
and differences between the two PD options, and local SSD.
First, the similarities.
All of our block storage options are
priced on a per-gigabyte basis, with no I/O charges ever.
This makes planning simpler, and eliminates surprises.
All of our block storage options are
designed to perform consistently.
Consistently between similar volumes,
and consistently over time.
Third, all of our block storage options are encrypted on disk.
And because PD is a network storage offering,
the data is also encrypted over the wire.
This is to give you the best possible security.
Lastly, all of our block storage options support live migration,
and are therefore not affected by planned downtimes that
keep Google Cloud data centers patched and maintained--
which is what keeps your applications as
secure and available as possible.
Now for differences.
Starting with reliability.
PD has additional reliability that
comes from storing its data redundant,
so the volumes can survive the sudden loss of hardware.
Local SSD does not have this redundancy.
It's up to you to protect the data that
needs to survive storage failures.
PD also was built in check sums.
Whenever you read data, no matter
how long ago it was stored, PD makes sure
that it returns what was written to you,
and avoids silent data corruptions.
Lastly, PD has a snapshot functionality
that makes it easier for you to protect your data against user
error and physical disasters.
In terms of performance, while all the
block storage options perform consistently,
local SSD has much higher IOPS, and is
designed for sub-millisecond latency,
making it ideal for the most performance-hungry databases.
For flexibility, note that both PD and local SSD
are very flexible.
PD volumes are the more flexible,
in that they can be created in sizes ranging from as small
as one gigabyte all the way up to 10 terabytes,
in one-gigabyte increments.
And it could be attached and detached from VMs on the fly.
Local SSD, by contrast, can be allocated
to VMs only at creation time, and needs
to be allocated in one to four partitions of 375 gigabytes.
While this isn't as flexible as PD,
local SSD does not require special instance types
with pre-specified amounts of SSD.
This lets you right-size the VM, CPU, memory, and storage.
So given these three options, how
do you decide which option is right for your application?
Let's split it up by use case.
First, boot volumes and bulk storage
are great use cases for standard PD,
because those use cases require low IOPS and low throughput,
and basically just want to occupy
the cheapest reliable space available.
Streaming I/O is a use case that works best for Standard PD
as well.
While the other two options have a much lower cost per IOPS,
the cost per throughput is generally better
on Standard PD.
Reading large, sequential blocks is what disks are good at.
SQL databases, like MySQL and Postgres, and NoSQL databases,
like Cassandra, Mongo, and Redis,
tend to be transactional and IOPS-heavy.
Smaller instances might be able to be run on Standard PD,
but important production databases should usually
be run on some form of SSD-- either SSD Persistent
Disk, or local SSD, depending on how high the IOPS needs are.
File servers, like NFS Gluster or Ceph,
can be more streaming or more transactional,
depending on what the clients are doing.
SSD PD is generally a great choice here.
High performance scratch disk, where keeping the track glocal
is the right architecture, should go on local SSD.
For Hadoop deployments, where I/O needs
exceed what Google Cloud Storage Connector for Hadoop
can provide-- for that case, you should use local SSD,
under Hadoop Optimized File System.
Here's another way to visualize the same information.
As you can see, depending on the performance needs of file
servers or databases, you have options
as to which block storage product to use.
To decide, you'll want to get down
to the real numbers of space and IOPS.
I'll go through some specific examples just a bit later
in the presentation.
But right now, let's double-click on Persistent
Disk, and talk about what separates the two PD
options-- their performance.
With both options, Standard and SSD,
for both read and write, the more space
you buy, more IOPS you get.
But SSD Persistent Disk grows in IOPS capability much faster
than Standard PD, which is why it costs more.
Each gigabyte of SSD PD gets 20 times the write IOPS
of a gigabyte of Standard PD, and a hundre
times the read IOPS of a gigabyte of Standard PD.
These high IOPS numbers are what make
SSD PD ideal for transactional workloads,
like heavily used databases.
Now, the SSD PD IOPS grow so fast
that they reach the limit of the IOPS
that a VM can handle at a relatively low volume
size, which is why these graphs have
this plateau at the top of the IOPS curve.
We're always working to increase the per VM limits,
and you should check on the current documentation
for the latest numbers, rather than coming back the graph.
Moving from IOPS to throughput, same pattern here.
Performance grows with space for both options.
Unlike the IOPS grass, however, you
can see that SSD PD's advantage in throughput is less dramatic.
And both Standard and SSD PD can hit the VM throughput limits
at moderate sizes.
This explains why we recommend Standard PD
for throughput-oriented applications
that have low IOPS.
While SSD PD has a much better cost per IOPS,
Standard PD has the better cost for throughput.
Like with the previous slide, please
check the latest documentation, as we're always
striving to raise the per VM caps on throughput,
just like with IOPS.
The idea of growing IOPS with space is pretty unique,
and many customers have asked us why we designed it this way.
We made this choice because of the following benefits
that we think are very important.
First, simple and consistent pricing.
With this model, there's no billing variations
due to your app's I/O needs changing over time.
The cost of a volume is the same from month
to month with no surprises, because all the I/O
was included in the cost of the space.
Second, consistency of performance.
This is critical.
By selling I/O and space together in a safe ratio,
we stabilize the overall storage traffic,
and keep volume performance consistent over time.
This means your app won't suffer the noisy neighbor problem.
Third, simplicity of in-VM management and snapshot
management.
Because larger volumes give you the performance
of many small volumes, your spared the upfront effort
of striping volumes together.
And because each VM needs only one data volume,
management of snapshots becomes trivial.
Each volume snapshot is a copy of an entire VM's data
at a given time.
Lastly, we wanted to give you consistency across the product
line.
We've been able to make all three block storage
options behave similarly.
You don't need to pick between different price and performance
models, or plan I/O down to the individual IOPS level.
We've tried to simplify everything as much as possible.
You decide how much space you need,
and you pick the storage type based on how many IOPS per gig
need to come along with it.
Now at this point, I'd like to help you
with the most important decisions you're
going to make in implementing block storage.
Given the three options, how do you
decide which to use for which app,
and how large do you need to make the volumes in order
to get the performance you need?
While I can't give you an exhaustive process or algorithm
to answer all the use cases, I will
walk through four separate examples
to show you how you can approach to decision
for your application.
In the first example, we're going
to have 300 gigabytes of space, and a fairly modest amount
of I/O. 60 random reads per second, and 120
random writes per second.
Here, simply 350 gigabytes of Standard Persistent Disk
will do the trick nicely.
Very economical cost, and give you all the I/O you need,
with some to spare.
The second example is actually the trickiest one.
Here, we're still going to go with 350 gigabytes of space,
but this time with more I/O. 450 random reads per second,
and 600 random writes per second.
We can quickly see that 350 gigabytes of Standard PD
will not give a sufficient I/O. While we could move up
to Standard PD, SSD PD, we don't absolutely need to.
Because the price of Standard PD is so low,
we can actually create roughly an 1800-gigabyte Standard PD
volume, and it winds up meeting the performance needs
while still being somewhat more cost-effective
than a 350-gigabyte SSD PD volume would be.
The third example leaves us no room for doubt.
Here, we want 350 gigabytes of space,
and a large amount of I/O. 9,000 randon IOPS.
Here, 300 gigabytes of SSD PD meets the needs perfectly.
In the last example, we're going to stay
with 350 gigabytes of space, but this time, a very large amount
of I/O. We're going to go for 60,000 random IOPS.
Here, you can use a single local SSD partition of the four
that you could use.
A single partition will meet both the space and the IOPS
requirements.
So now let's switch over to general best practices,
focusing on Persistent Disk here.
Most of the best practices we're going to talk about
are about performance.
The first performance tip comes from the fact
that PD works with four-kilobyte I/O boundaries.
Any misaligned I/O will dramatically
lower the performance.
All of the PD I/O should be multiples of four kilobyte,
and aligned to four-kilobyte boundaries.
Disk partitions and their file systems
must be aligned to those 4K boundaries.
The easiest way to be sure of doing this
properly is to have a simple partitioning scheme,
with a single partition for the volume,
and to format that partition using the Google-provided Safe
Format and Mount script.
The operating system and application stack
should do everything else for you.
Here's a syntax for that Safe Format and Mount script.
And keep in mind, if you don't use that script,
and you format your file systems on your own,
please make sure to align on 4K boundaries.
And if you mount your file systems on your own,
please make sure to mount with the Discard option.
The Discard option makes format times much faster,
makes snapshots smaller, faster to take,
and makes storing those snapshots less expensive.
The next performance recommendation
is about tuning your application properly for your I/O pattern.
Starting with IOPS.
PD attains its high IOPS performance
through the use of parallelism on the back end.
Therefore, for higher IOPS, you may need a larger queue depth,
or application thread pool.
The more I/Os you can issue at once,
the faster the PD volumes can return the data.
You'll need a queue depth of one for every 400 to 800 IOPS
you require, up to a maximum queue depth of 64.
Consult the application documentation
on how to configure this, as it's
different for every application.
Now, if you need higher throughput, as opposed
to higher IOPS, there are different recommendations.
When you need high throughput, the best thing to do
is to increase the I/O size to 256 kilobytes or greater.
Also, increasing the OS read-ahead cache,
using the command line here, will improve streaming I/O--
especially if you're forced by the application,
for some reason, to use small block sizes.
Please note that we intend for the values on this slide
to change over time, as we improve Persistent Disk.
The concepts described here will stay true, but consult
the Persistent Disk documentation for the latest
values.
Another performance tip is around CPU.
It's important to note that Google does not
require special instance type for getting high I/O. Larger
VMs can get higher I/O by virtue of their more CPUs.
A quick rule of thumb is to have one CPU core free
for every 2,000 to 2,500 IOPS.
As with the last slide, we intend this value
to change as well over time, as make Persistent Disk better.
Please consult the documentation for the latest value.
Like I mentioned before, the larger a PD volume
is, the more I/O it can do.
So you never need to create many small volumes
and stripe them together to increase performance.
For example, one terabyte volume will give the same performance
as 10 100-gigabyte volumes striped together.
And because we support volumes up to 10 terabytes in size,
you don't never need to stripe volumes
together for space, either.
One data volume per VM is all you should ever need.
Last performance tip.
Sometimes people mistakenly think
there's a need to pre-warm PD volumes.
This is not needed, as PD volumes perform consistently
over time, and are ready for their top performance
as soon as they're created.
Trying to pre-warm the volumes will only
waste time and resources.
PD volumes are also consistent relative to one another.
There's never a need to create many volumes, test their speed,
throw away the ones you don't like,
and keep the ones you do like.
All the volumes of the same size and the same type
will perform the same way.
So now let's move from performance to protection.
As you know, mistakes can happen, bugs can happen,
and disasters will eventually happen.
All of which can cause you lose data
if you don't take the proper precautions.
When using PD, please take snapshots frequently.
This will protect you against software and human errors that
may delete data, and will also protect you
from physical disasters.
Because PD has differential snapshots,
snapshot time and storage costs will
be as efficient as possible.
Also, snapshots will never perceptibly pause your VM,
and will not affect your applications.
Moving away from PD for just a second,
remember that local SSD does not have the snapshot feature.
So make sure when using local SSD,
if you need to protect some of that data,
that you use some backup mechanism supported by the OS
in application.
The last tip we have is about moving data.
If you want to move Persistent Disk volumes
from one zone to another zone, the easiest thing to do
is to snapshot the PD volume into Google Cloud Storage,
and then restore it to the other zone.
Now, if you need to move individual pieces of data
from a non-PD source into a VM, into the PD volume,
you can use the gcloud push command.
To do the reverse, and move data from a PD volume and a VM
to a non-PD destination, you can use the gcloud pull command.
So here's a quick summary of what we discussed.
First, Google's block storage is unique in its combination
of reliability, security features, and performance
consistency.
Second, Google's block storage options
offer a unique continuum, with all of the block storage
options scaling performance with volume size.
This way, the block storage options
can be compared in an apples to apples manner,
and decisions made simply, mostly based on the performance
needs.
Third, all the options have a simple price per gigabyte,
never charging extra for I/O. You can always
be assured that each option's complete cost is understood
up front, with no surprises later on.
Lastly, please refer back to this presentation for our best
practices on how to choose between block storage types,
and how to optimize I/O. If you follow these guidelines,
you should be able to get consistently superb performance
at the lowest possible price.
I encourage you to try out all of our block storage
options, especially the two new ones
we're so excited to announce here.
If you'd like to follow up on any
of this presentation for more detail,
please contact me personally, or contact the bigger teams
using the forums listed here.
Thank you very much for watching.