Cold Disaster recovery for applications in Google Cloud (Get Cooking in Cloud)

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]

Leave a Reply

Your email address will not be published. Required fields are marked *