BENJAMIN SCHULER: SAP systems are often
amongst the most critical parts of a company's IT landscape,
and therefore, they need to be protected against downtime
to allow continuous operation of the entire company.
Google Cloud can help you improve your SAP system's
uptime and provide you with different options
for designing high-availability architectures.
Hi.
My name is Benjamin Schuler.
And in this video, I'd like to tell you
a little bit about the different options
that you have for designing high-availability architectures
for SAP on Google Cloud.
Let's take a look.
[MUSIC PLAYING]
Before looking at the SAP-specific architecture
patterns, I want to highlight some of the out-of-the-box
concepts that Google Cloud can offer to improve the uptime
of any virtual machine running on Google Compute Engine.
Google Cloud is highly available by design,
with a redundant infrastructure of data centers
around the world that contain zones designed to be
independent from each other.
The blue dots on the map indicate regions
that are available today.
The white ones indicate future regions.
Zones usually have individual power, cooling, network,
and control planes that are isolated from other zones.
If a single failure event were to occur--
for example, a bulldozer cutting through a network cable
during some nearby construction work--
it would affect only a single zone.
As you can see, every region in Google Cloud
provides at least three isolated zones,
which enables our customers to design
a high-availability architecture across multiple zones
in the region of their preference
without being tied to selected parts of the world.
Since all of our regions offer multiple zones,
the first step towards a proper high-availability architecture
in Google Cloud should be to distribute your instances
across different zones within the same region.
Our high-performing network connection
ensures that we can provide latency
below one millisecond from one zone
to another in the same region, which
makes synchronous replication between systems
a valid option without keeping the users waiting.
Now that we have learned about the different regions
and zones, let's look at some features
that we can offer thanks to our virtualized infrastructure.
When we need to perform maintenance
on our infrastructure, Google Compute Engine automatically
migrates your instance away from the maintenance event while
trying to keep your application running without any downtime.
We call this feature Live Migration.
This happens without any user interaction,
and is a feature that we provide free of charge.
The migrated instance is identical
to the original instance, including the instance
ID, private IP address, and all instance metadata and storage.
Another handy feature that comes with Google Compute Engine
is our automatic restart of virtual machines.
If your instance is set to terminate
when there is a maintenance event,
or if your instance crashes because of an unexpected issue,
you can set up Compute Engine to automatically restart
that instance.
This setting is turned on by default on all virtual machine
instances, and we recommend that you
keep this feature activated.
In combination with a startup script,
you can automate your SAP system start after a crash
without any manual user activity,
and therefore, reduce its impact on the user significantly.
In some cases, you might already meet your availability
requirements by running your systems on Google Cloud
infrastructure without the need for redundant components, which
could save you both time and money.
When it comes to running SAP HANA databases
in a high-availability setup, the first mechanism
that comes to mind is the built-in HANA system
replication.
SAP provides this functionality out of the box,
and offers a number of replication models
so you can tweak it to match your requirements.
For synchronous replication, SAP recommends network latency
below one millisecond between the primary and secondary
database.
This means that you can deploy your two HANA instances
in two different zones in any of our regions,
and protect your system against a failure of one zone
while still meeting the requirements to run
a synchronous replication between both instances
in that same region.
If you'd like to try such a setup for yourself,
check out this link, which provides
some additional information, and also
a template for our own automated infrastructure provisioning
service, which is called Deployment Manager.
This script will spin up two HANA instances
in two different zones, then configure HANA system
replication between them, and also set up a Linux cluster
without any user interaction, fully automated,
in less than 30 minutes.
Pretty cool, huh?
For scale-out HANA systems, so a scenario
where multiple nodes are connected
to form one combined database, you
can deploy additional standby nodes that
can take over in case one of the worker node fails.
As you can see in this diagram, the data and log partitions
of each node are attached to a single virtual machine
instance.
In our example here, worker node two is no longer available,
and the standby node immediately takes over.
The data and log partitions are detached from worker node two
and mounted to the standby node.
This is executed by a storage plugin
that works together with the SAP Storage Connector API.
The standby node can now function as a new worker node,
and once the failed worker node is available again,
it will act as the new standby node.
With Google Cloud, you also have the option
to run non-HANA databases.
Check out our database planning and deployment guides
behind this link.
These databases have their own built-in functionality
to provide a high-availability architecture.
For example, a warm standby server with SAP ASE's Always On
option, or a high-availability cluster of IBM's DB2 database.
For your application servers, the first components
that you probably want to protect against downtime
are the central services.
Similar to the database, these present a possible single point
of failure, and therefore, should be protected.
You can choose to run the different services
on multiple instances, so have one server running
the message service and another server
running the enqueue service.
If your message service instance fails,
the instance running the enqueue service
can take over with the latest log information
and continue to allow users to work with your SAP system.
For such a setup, we recommend that you
distribute the different instances
across multiple zones.
One of the benefits of running your SAP system on Google Cloud
infrastructure is the ability to provision new servers
in a matter of seconds and to automate
the entire installation process.
With this flexibility, you can get new application servers
ready for your users as they are needed.
And by running multiple instances,
they can immediately log onto a different server if one of them
fails.
OK, let's wrap up.
As a general statement, it can be
said that moving an SAP system from on-premises hardware
to Google Cloud infrastructure can improve the availability
through built-in concepts of the virtualization layer,
like Live Migration and Host Auto-Restart,
and therefore, improve the uptime
without any additional configuration.
Downtimes caused by hardware failures
can be reduced or even eliminated
without requiring any customer activity.
For the database layer, various concepts
exist depending on the database system.
Typically, these concepts are either
based on a regular copy of the database logs
to a standby system or a set of database instances running
in some sort of synchronous replication mode.
For such a setup, the two database instances
should be placed in different zones
within the same Google Cloud region for the highest
level of isolation while still meeting requirements
for low latency.
And finally, on the application layer,
the SAP NetWeaver architecture can provide end users
with multiple application servers
to ensure the failure of one instance
does not block all users from accessing the system,
and that those who lose connection
can log on via a different server immediately.
With the flexible infrastructure in Google Cloud and automated
deployment scripts, a new application server
can be added on demand, and placing multiple application
servers in a [? logon ?] group can improve the uptime
of the application layer.
I hope this brief video has given you
a better idea about the various high-availability architectures
on Google Cloud and what they mean
for running your SAP workloads.
You can find a lot of additional information
about SAP on Google Cloud in our YouTube channel
and in the online documentation.
Check out those links right next to me and in the description
below.
Thanks for watching.
[MUSIC PLAYING]