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

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


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’ll share the recipe
to set up a cold DR pattern for applications
that are primarily deployed on premise. So let’s dive in. [MUSIC PLAYING] Your DR plan would depend
on your specific application and recovery goals. Let’s consider a few
scenarios to understand this. If you run batch
processing workloads, they tend to be
non-mission critical and don’t need to be designed
for high availability. In such cases, you would use
pre-emptable virtual machine instances in conjunction
with Google Cloud Storage. And that’s your DR plan. If you run an e-commerce site,
then the actual purchasing pipeline needs to have
high availability, but the email process that
sends those notifications to customers can
tolerate a bit of delay. This is a mix of hot purchasing
and warm or cold notification patterns. If you have a video
streaming solution, then from the search to
actually streaming content, the entire experience
needs to be HA or the customer might
turn to your competitor. Well, let’s talk about an
interesting company, Main Street Art. They run their
application on premise and are building a DR
infrastructure on Google Cloud. They are now working
out a disaster recovery plan with the low budget and are
OK with a bit high RPO and RTO values. This means they need to
set up a cooled DR pattern. In cooled DR pattern,
Main Street Art needs minimal resources in
the DR Google Cloud project, just enough to enable
the recovery scenario. When a disaster occurs,
the fail over strategy requires a mirror of the
production environment to be started in Google Cloud. Let’s see how this would work. We create a VPC network, then
we configure the connectivity between the on premise network
and the Google Cloud network. We need a Cloud Storage
bucket as the target for our backup data. Now, for your on premise machine
to upload database backups to Google Cloud, we will
need a service account key to authenticate your machine
within an automated script. We would use IM policies
to restrict access to the right user as well
as ensure that the service account has the minimal
permissions required and make sure uploads and
downloads to and from the cloud storage bucket are working. Then, you finally script
the data transfer, create a scheduled task
to run that script, and then create
custom images that are configured for
each type of server in the production environment. You configure the DNS to
point to your internet facing web services and then create
the deployment manager template that will create
servers in your Google Cloud network using the previously
configured custom images. When a disaster
hits, all you need is to execute the
deployment manager template, which will create a Google
Cloud deployment automatically. Apply the most recent database
backups and transaction logs from the cloud
storage bucket, test the application works
as expected by simulating a user in the recovered
environment, then finally point the Cloud DNS to
the web server on Google Cloud. When the production environment
is running on premise again and the environment can
support production workloads, we reverse the steps
that we followed. Typically it goes
something like this. Take a backup and
transaction logs of the database running
on Google Cloud. Copy and apply the backup
files to the database in production environment. At this stage, you should
prevent connections to the application
in Google Cloud, or you can stop the connections
after the database had been successfully restored and
apply any transactions that occurred after the backup
was taken In our case, we need to stop the connections
to the global load balancer. From this point,
your application will be unavailable until you
finish restoring the production environment. Configure Cloud DNS to point
to your on premise web service. Ensure that the process you
had in place to copy data to cloud storage is
operating as expected. Then finally delete
your deployments. Well, there you have it. If you are running your
application on premise and have a constrained budget
and can work with higher RTO and RPO values, then a cold
DR pattern is the way to go. We learned how to
approach recovering the environment from failure
in a cold DR scenario. That’s all for today on
GitHub Cooking in Cloud. Here’s hoping you’re cooking
up your own DR strategy. Join us next time where
we will share the recipe to implement a warm standby DR
pattern for mainstream thought. If you would like to
see more such content, don’t forget to like and
subscribe to our channel.

One thought on “Cold Disaster recovery on Google Cloud for on-premise applications (Get Cooking in Cloud)”

Leave a Reply

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