JENNY BROWN: In a previous episode,
we talked about how Critter Junction acquired
another company and had to integrate
their VMs with their existing architecture.
This had gone well so far, but Critter Junction
had noticed some areas where things
could be improved using Google Cloud Persistent
Disks to save money and to make the entire application more
scalable.
Stay tuned to see how.
[MUSIC PLAYING]
After the big acquisition, Critter Junction
had to maintain and, ideally, upgrade another company's VMs.
After using the architecture for a few months,
one of the first potential areas of improvement Critter Junction
found was that there were many of these VMs disks that
were being underutilized, meaning
the speed at which the application was requesting
data was much slower than the speed their disk could
read the data.
And they realized that other parts of the architecture
were overutilizing resources.
So Critter Junction also realized
if their growth projections were accurate,
they would need to resize their VMs'
disks as they would very quickly outgrow their current disk
size.
And on top of all that, they wanted this resizing
to happen without any downtime or costly VM restarts,
if possible.
This seemed like a lot to ask for, but what they didn't know
is that Google Cloud Persistent Disks
solve a lot of their problems.
Let's dig in.
Google Cloud Persistent Disks are
a durable, high-performance block-storage option
for Cloud VMs.
Their main benefit is that they can be attached to
or detached from VMs as needed, allowing for long-lived data
to persist even where those VMs are started,
stopped, or terminated.
There are three different types of block storage.
Local SSDs are high-performance scratch spaces
that are best suited for in-memory databases up
to 9 terabytes in size.
Then there's standard persistent disks.
These are network devices suited for large data-processing
workloads that primarily use sequential IOs.
There are SSD persistent disks, which
are suited for enterprise applications
and high-performance database needs that
require lower latency and more IOPs
than standard persistent disks provide.
SSD persistent disks are designed
for single-digit-millisecond latencies.
The observed latency is app specific.
And finally, there are balanced persistent disks
which, as named, provide a balance between PD
standard and PD SSDs.
They are backed by a solid-state drives that balance performance
and cost.
Now that we reviewed the different types,
let's see how this applied to Critter Junction.
Critter Junction mostly uses standard persistent disks,
which are good for using as boot devices, persisting data,
used as data-distribution devices for static website
content, and they can be a useful way
to replicate data across zones.
Unfortunately, the current architecture
didn't take much advantage of these features
because each PD is attached to a corresponding VM.
As we mentioned, this caused the application
to underutilized some PDs while overutilizing others.
Another concern Critter Junction had
is that as their application data and boot volume grows,
they're afraid they'll have to reboot the VM, detach the PD,
resize it, and reattach it, resulting in scaling
limits with downtime.
Fortunately, this isn't the case at all.
What Critter Junction didn't know
is that persistent disks provide scalability
because multiple VM instances can connect
to content at the same time within the same zone, allowing
applications to scale up or instances down as needed
to serve data to customers.
And better yet, attaching a persistent disk
to multiple virtual machines doesn't
affect total performance or cost either.
Each machine gets a share of the per disk performance limit.
Performance scales automatically with size,
so you can resize existing PDs or add more PDs to an instance
to meet performance and storage-space requirements.
Each PD can be up to 64 terabytes in size,
so there's no need to manage arrays of disk
to create large logical volumes.
Critter Junction also didn't realize that persistent disks
provide nearly unlimited flexibility
by allowing you to resize your storage while it's
in use by one or more virtual machines with no downtime.
That means they could resize their disks on the fly
without interruption.
This is all made possible by Google Cloud Persistent
Disks being network attached.
Since the disks aren't physically
attached to the VMs that are using them,
you get the benefit of using Google's network fabric, which
can deliver more than 1 petabit per second of total bisection
bandwidth.
That's a lot of that.
With all of this new information,
Critter Junction went ahead and moved away
from assigning one PD per VM.
This allowed them to connect more VM instances
to their underutilized disks.
These instances all read from the same standard persistent
disk, allowing the entire application
to serve more users.
And for the disks that were overutilized,
Critter Junction decided to upgrade them to larger disks.
And best of all, Critter Junction
took advantage of Google Cloud Persistent Disks' ability
to resize a storage while it's in use by a VM
to do all of this without any downtime.
For Critter Junction, Google Cloud Persistent Disks
turn out to be a simple, fast, and flexible solution
for those needs.
So that's a wrap for this episode of "Season of Scale."
Stay tuned for more about Critter Junction.
And remember, always be architecting.
[MUSIC PLAYING]