hello and welcome to this session on
best practices for setting up disaster
recovery for sa P systems in Google
cloud
my name is Rohit comet and in this video
I would like to tell you a little bit
about the various options you have for
designing and architecting a disaster
recovery solution for SA P applications
in Google cloud so let's get started
first let's quickly define disaster as
it relates to cloud however unlikely
this event may be where an entire
geographic region is considered
unavailable meaning all applications in
this region are also considered
unavailable this could be due to a
natural phenomenon or an unnatural event
when such an event occurs the business
continuity process is triggered where
necessary folks in the organization are
contacted and a decision to fail overall
business critical applications to the
disaster recovery site is initiated for
this purpose it is always recommended to
properly test plan and update the
business continuity and disaster
recovery plans
needless to say anytime there's a change
to the system or the landscapes these
plans will have to be updated
accordingly now let's take a look at
items to be considered for best
practices to handle disaster recovery to
fail our applications to the disaster
recovery site proper setup planning
testing and validation are necessary in
every organization various applications
are necessary for business to function
for each of these business critical
applications certain key metrics namely
recovery point objective and recovery
time objective need to be defined
recovery point objective is the amount
of data loss business is willing to
accept in the event of a disaster
meaning transactions that are being
recorded in the system during normal
business operations on the primary site
that business is willing to live without
in case of a disaster
these very transactions will then need
to be either manually or systematically
re-entered in the system on the DR site
recovery time objective on the other
hand is the amount of time business is
willing to wait for these systems to be
up and running on the DR site it also
means it's the amount of time the teams
have to prepare the systems prior to
handing them over to the business so
it's the
time taken to restart your database
start up your application servers
validate to ensure the system are up and
running in the right order validate
connectivity of these systems to
peripheral systems validate business
data and also ensure users connectivity
to the dr site depending on the RTO and
RPO defined for each application
appropriate solutions can be chosen and
implemented in case of a low RTO and RPO
you will need to ensure the systems are
able to failover quickly and in case of
relaxed RTO and RPO and appropriate
backup restore solution may be
sufficient to begin with it is
recommended to reserve necessary
instances in the dr region to ensure you
have necessary compute for you to stand
up your business critical applications
second also have a proper business
continuity plan that is up-to-date test
and validate these plans at least once a
year if not more frequently this ensures
the teams involved know exactly what
needs to be done in the event of a dr
depending on the application and
databases involved there are several
ways of replicating data and
corresponding application configuration
from primary site to the dr site as an
example if you're using s AP hana as the
database there is built-in replication
referred to as HSR or Hana system
replication available that will help
with this process this HSR will not only
replicate data in the database but will
also help with database configuration
and other items in case of other
traditional databases like sapa SC log
shipping mechanism can be used to send
data over to the dr site in case of
application servers you can use Google
Cloud Storage snapshot that can help
with this process now let's take a look
at some of the tools if your landscape
is fairly simple and only has a handful
of applications to failover then you can
adopt native Google cloud tools to set
up your dr process as an example you can
use persistent disk snapshot mechanism
to create snapshots and schedule
snapshots to ensure data is back
on a regular basis and in the event you
need to recover from this you can
restore from these snapshots onto the dr
site in case of larger databases you can
either continue to use built-in database
or application and failure mechanism or
save database backups to Google Cloud
storage and restore from them these
triggers and failures can be scripted in
Google Club in case of complex
landscapes you can use partner provided
solutions that are available in Google
cloud marketplace apart from
infrastructure you will also need to
ensure your network is laid out
appropriately this is also to ensure
your users are able to connect to the dr
site typically this is done by updating
your network alias in the dns to point
to new dr IP addresses second you need
to ensure the primary and dr sites are
able to talk to each other during normal
operations to perform replication this
is all made simple and easy in google
cloud via the dedicated high-bandwidth
low-latency fiber which allows
connectivity between sites without
having to go to the internet or use an
isp virtual private cloud or VPC
provides networking functionality that
can extend your network around the globe
you can set up your network in such a
way that your primary site and dr sites
are in the same VPC or you can also
create a sub network and IP address
range for the dr site another option is
also to place your primary and dr sites
in separately pcs or for that matter
even in completely different projects
that's the true flexibility that google
cloud provides at the network layer
giving you extensive control of how you
want to design and lay your network in
closing i would like to say that
disaster recovery planning is very
application and organization specific
proper planning and testing is paramount
to having a smooth failover in the event
of a dr google cloud can provide tools
and integrate with applications and
databases for a smooth failover process
finally i would like to point you to
documentation that you
refer to four items that I did not cover
today and also find more detailed
documentation on rest of the topics
thank you
[Music]