PRIYANKA VERGADIA: Welcome to "Get
Cooking in Cloud," where we share the best recipes
to apply in your Cloud kitchen.
I am Priyanka, and in this episode,
we will share the recipe to plan a cold DR
pattern for applications that are primarily
deployed on Google Cloud.
[MUSIC PLAYING]
Main Street Art has migrated to Google Cloud,
but they still need a disaster recovery plan.
They would like to set up cold DR pattern with one
recoverable application server.
Based on your architecture, just one recoverable server
may or may not work.
But consider this just as an example.
Here's how this would work.
Create a VPC network.
Then, create a custom image that's
configured with the application service.
As part of the image, make sure a persistent disk
is attached for the data that's being processed.
Then, create a snapshot from the attached disk,
and configure a startup script to create a persistent disk
from the latest snapshot and mount that disk.
Then create an instance template from the image we just created.
Using this instance template, configure
a regional managed instance group with a target size of 1.
Make sure the health checks are configured at the managed
instance group level.
Configure internal load balancing using the regional
managed instance group, and then configure a scheduled task
to create a regular snapshot of persistent disk.
Now, what happens in case of a disaster?
Well, Main Street Art does not need
to initiate any failover steps, because they
occur automatically.
That is the best part of the default HA features
available in Google Cloud.
Let's look at some of these components to learn more.
The load balancer ensures that even when
a replacement instance is needed,
the same IP address is used to front that application server.
The instance template and the custom image
ensure that the replacement instance
is configured identically to the instance it is replacing.
Main Street Art's RPO will be determined
by the last snapshot taken.
The more often the snapshots are taken,
the smaller that RPO value.
The regional managed instance groups provide HA in depth.
It provides mechanisms to react to failure at the application,
instance, or zone level.
You don't have to manually intervene
if any of these scenarios occur.
Setting a target size of 1 ensures you only ever
have one instance running.
Persistent disks are zonal, so snapshots
are required in order to recreate disks
in case of zonal failures.
Although snapshots are also available across regions,
which permits you to restore a disk to a different region
as easily as restoring it to the same region.
In the event of a zonal failure, the regional instance group
launches a replacement instance in a different zone
in the same region.
A new persistent disk is created from the latest snapshot
and attached to that new instance.
Now, you could use a regional persistent disk instead
of zonal, which will be great, because you won't
have to use snapshots to restore the persistent disk
for recovery.
But be mindful that this consumes twice
as much storage, which needs to be budgeted.
Note that these are just some scenarios.
The actual decision that Main Street Art takes
will be dictated by their budget, RTO, and RPO values.
Well, there you have it.
If your application is deployed on Google Cloud,
and you are on a specific budget to meet those RPO and RTO
values, then use the cold DR pattern.
That's all for today on "Get Cooking in Cloud."
Here's hoping you are whipping up your own DR strategy.
Join us next time, where we will share the recipe
to implement warm DR and HA for applications
that are built on Google Cloud.
If you would like to see more such content,
don't forget to like and subscribe to our channel.
[MUSIC PLAYING]