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

Hot 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 plan a hot DR pattern
for your application that’s deployed on-premise. So, let’s dive in. [MUSIC PLAYING] A little recap– in
the last two episodes, we talked about Mane Street Art,
that runs their applications on-premise and are building a DR
infrastructure on Google Cloud. This started with a cold DR plan
and moved to a warm standby, due to the need for
lower RTO and RPO values. Well, now, Mane Street Art
has become really popular and cannot afford to be
down, even for seconds. Since their requirement is to
achieve a near-zero RTO and RPO appeal values, the only way
is by running HA architecture across their production
environment and Google Cloud concurrently. Let’s see how this works
from the setup perspective. We create a VPC network. Then we configure
the connectivity between the on-premise network
and the Google Cloud network. We create custom
images of the servers in Google Cloud with the
exact same configuration as on-premise. Then, configure the replication
between on-premise database server and the one
on Google Cloud. Remember, that if your
database systems permit only a single rateable database
instance when you configure replication, then you
might need to ensure that one of the
database replicas act as a read-only server. Create individual
instance templates that use the images for the
application server and the web server. Configure regional
managed instance groups for the application
and web servers. Then configure health checks
using Stackdriver monitoring and load balancing
using the regional managed instance groups. Configure a scheduled a task
to create regular snapshots of the persistent disk. And lastly, configure
the DNS service to distribute traffic between
your on-premise environment and the Google
Cloud environment. With this hybrid
approach, you need to use a DNS service that
supports weighted routing to the two production
environments so that you can serve the
same application from both. In case of a failure
on premise, you just disable the DNS routing to
the on-premise web server, and that’s it. In most cases, the DNS
service supports health checks and will automatically route all
the traffic to the LD servers on Google Cloud. And when it is all
back to normal, and can handle
production traffic, we need to resynchronize
the databases. If your database system
doesn’t automatically promote a read-only replica
to be the rateable primary on failure, you need
to intervene to ensure that the replica is promoted. After ensuring that, just
enable the DNS routing back to distribute traffic to both
on-premise and Google Cloud. Well, there you have it. If you are running your
application on premise and are looking to
achieve very, very small RTO and RPO values,
then hopefully you’ll learn how to approach recovering
the environment from failure using Google Cloud hot HA
across the two environments. That’s all for today on
“Get Cooking in Cloud.” Here’s hoping you’re cooking
up your own DR strategy. Join us next time
and learn the recipe to implement disaster
recovery for applications that are built on Google Cloud. If you like this video and 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 *