[MUSIC PLAYING] JEREMY SOLARZ:
Welcome, everyone. Welcome to the session-- best practices for SAP
deployments in GCP. My colleague, Babu,
tech lead SAP in GCP, and myself will
cover with you today. We have prepared the
following agenda. First, I will give
you an overview of GCP in the context of SAP workloads. I will do that by mentioning
typical components of SAP deployment on GCP, and recap
the most important things about these components. A short note-- on
some of the slides, you will find some references
to related sessions to the content
shown on the slides. Then, my colleague Babu, will
give you an overview of SAP in the context of GCP. And we'll move on to best
practices and reference architectures. Then I will take over
and we'll present some migration prospectuses
and options how to bring your workloads to GCP. Finally, we will show a
short demo and have a Q&A. So let's start with
giving an overview of GCP in the context of SAP workloads. If you look at the typical
SAP deployment on GCP, it normally consists of
the following components. First, you need
to think about how to connect to GCP data centers. Second, you need to think about
a proper networking setup. Third, you need to think
about compute resources where you want to host
your SAP workloads on. And you need to think about
storage, either with the VM as persistent
storage, or globally through our global
storage offering, GCS. Then another aspect
is you want to be sure about the health
of your systems. This can be achieved
via monitoring. And finally, the whole
thing is summed up with built-in security concepts. So let's talk about compute. What you have to remember is
that the network throughput scales with the amount
of CPUs, maxing out at 16 gigabits per second. Through live migration
and active auto restart, we can provide you with
higher reliability. That means that during a
software or hardware update, the VM is moved to another
host transparently. This gives you a better
resilience for all levels below the operating system. Through sustained use discounts,
a customer has the choice to and only pays for
what they use, meaning the longer they use a
resource in a month, the more distant count they get. Moving on to persistent disk. As I mentioned before, with
compute engine, throughput and IOPS scale with
the size of the disk, and depending if you
are using HDD our SDD, you have different read or write
metrics, as can be seen here. For SDD workloads, which are
a higher performance option, you have 800 bytes
per second read, and 400 megabytes
per second write. Another deciding factor with
SSDs is the amount of VCPUs. You will reach the maximum
performance metrics only if you have more than 32 CPUs. Additionally worth mentioning
is that our persistent disk can save up I/O capabilities
to handle I/O spikes well above the average. And also worth mentioning
is that typical operation tasks like partitioning and
right on the disk erase, as well as subvolume management
are not necessary with it. Now moving on to networking. When we talk about our
software-defined network and compare it to a
typical on-prem deployment, our VPCs can span
regions, meaning they are a global resource. Our subnets can span
[INAUDIBLE],, meaning they are a regional resource. They can have
non-overlapping address space and can be dynamically extended. Through shared VPCs, we
provide you the possibility to have a VPC as a sharable
resource that can be managed by a central networking team. And another thing to consider,
when talking about performance for intra-VM communication, use
internal IPs over external IPs, and rightly size
your TCP window. Now talking about how
to connect to GCP. You have the following options. For low bandwidth
connections which are connecting via
the public internet, you can use VPN, which provides
you 1.5 gigabits per second. If you want to save up to 50%
on [? rigorous ?] cost compared to the VPN option and want
to connect via public IP, you can either use direct
or carrier peering, depending on if you meet
Google's peering requirements. If you want to
connect via private IP and want to have
an SLA, then you have either a
dedicated interconnect or partner interconnect. Dedicated interconnect
provides you with 10 gigabits
per second per link. Partner interconnect
provides you with a range of 50
megabits per second, or 10 gigabits per
second per link. Talking about security in this
context, especially encryption. Google encrypts all
data by default, with Google's internal keys. But additionally, Google
gives you the option to use customer-supplied
encryption keys, meaning that you provide us
the keys, keep them on premise, and only if you want to retrieve
or store data, we need them. In between, we have a
cloud management service that lets you keep keys in GCP,
have them automatically used by GCP as needed,
but control things like key rotation or
revocation of the keys. Now, moving to the last point
of those components, monitoring. Through our joint
work with SAP, we could provide specific
Stackdriver agents, which hook into NetWeaver and Harner. They can give you
the possibility to see, in one single
view, the health and detail about your SAP
deployment on GCP. Through Stackdriver's
alerting mechanisms, you have the possibility
to get notified in case of any incidents. And through aggregated
locking, you have the possibility to get a
high level overview of your SAP deployment amongst
multiple projects. With that, I will give
it to my colleague Babu, who will now show you
an overview of SAP in the context of GCP. BABU PRASAD ELUMALAI:
Thank you, Jeremy. Can I have a quick
show of hands? How many people
here have experience running SAP workloads? OK. How many of you have experience
running SAP workloads in the cloud? Any cloud? OK. So that's-- OK. Cool. So in this section, I'm going
to cover two important topics. The first topic is what
SAP services and solutions are certified to run on GCP. And the second
topic is, what are the benefits of bringing
your SAP workloads to run on Google Cloud platform. So we have been working with
SAP, starting from Q1 of 2017 for multiple certifications
and [INAUDIBLE] integrations. We've come a long way
in the past one year. We go through a rigorous
functional and performance testing for each
certification that we make available for product
reviews for customers. If you look at NetWeaver, we run
something called a three tier benchmark to prove
linear scalability of our virtual machines. For example, we will
take the NetWeaver stack. We will run the
application on a single VM. We'll create the database
in a separate VM. We will run the SD benchmark. We will look at
the SAPS numbers-- SAPS is SAP's application
performance standard. Let's say the SAPS number
is 100, for example. If you create another VM,
and you run the same workload with two VMs, you
should get 200 SAPS. You prove linear scalability. That's when you get certified. We have a few NetWeaver
colleagues here who can attest to that. So we go through all
of that to make sure that customers have the best
possible experience when they are bringing their SAP
workloads to run on GCP. We also certified custom
VM types for customers to run their S/4HANA workloads
on Google Cloud Platform. What that essentially
means is, let's say you do a sizing
exercise, and you determine that based on
the SAPS that you need, you need an instance with
approximately 20 cores. But if you look at
the predefined machine types available
in many platforms, including Google Cloud,
you'll find a 16 core machine and a 32 core machine. You'll not find a
20 core machine. That's when custom virtual
machines will help you. So with this certification,
you can run virtual machines with the exact amount of
cores that you need, based on the SAPS that you have. Basically, if you look at the
20 core versus the 32 core comparison, you're
basically saving 60% in terms of resources and costs,
just by using custom VM types. We also worked with SAP to
certify SAP cloud platform for Google Cloud Platform. So if you're a developer
who's developing Cloud Foundry applications,
SAP-based applications, this is a platform
that you can leverage. And you can build custom
applications on top of GCP with the SAP Cloud platform. SAP HANA is an
in-memory database that serves as a backing
store for SAP applications like S/4HANA,
BW/4HANA and so on. Customers who use
SAP HANA require VMs with a large amount of memory. So the slide here shows the
rapid pace of innovation that allowed us to go from 200
gigabytes of memory, roughly, last year, to four
terabytes of memory this year, within
a span of a year. And through this
process we also realized that you can run
scalar workloads, where you can scale out your SAP
HANA from a single machine to multiple machines in
a VW OLAP environment. So our scalar
certification currently allows you to go up to
16 nodes and 22 terabytes for your VW OLAP workloads. Finally, we also
certified dynamic tiering. This is hot off the press
for SAP HANA workloads. So if you look at SAP HANA, SAP
HANA is an in-memory database. Memory is expensive. And if you ask the question
whether your application requires all the data that's
in memory, maybe, maybe not, right? So you decide at what
point the data becomes less interesting
to your application and you define a warm tier
to move the data to the, let's say, the dynamic
tiering portion. This basically allows you
to optimize costs and also leverage the SAP HANA
certified ecosystem for storing large amounts
of data at the same time. And during this process,
we also made sure that customers can deploy
SAP HANA in our environment in a matter of minutes. We developed
automation templates. These automation templates
can do end to end stuff, starting from configuring
virtual machines with the required
amount of storage, certified configuration, making
sure high availability is configured, making sure that
there is automatic failover. So for example, if
one machine fails, the other machine
automatically takes over within a matter of seconds. So you can satisfy the high
availability and disaster recovery requirements that
you have in mind already. This is just an overview slide
talking about a summary of what we have achieved so far. So now let's move on
and talk about benefits. Why should you bring your
SAP workloads to run on GCP? So Data Custodian is a
partnership initiative between SAP and Google Cloud in
the GRC space, the governance, risk and compliance space. Google Cloud developed
a solution called AXT-- Access Transparency,
which is a set of APIs that will expose to
customers what is happening in your infrastructure. Who's accessing your data, from
the infrastructure provider's side. So this is bundled into the
Data Custodian application to provide more visibility. Where SAP acts as a data
custodian customers' data in Google Cloud. This is a unique initiative
in the public cloud space [INAUDIBLE] SAP and
Google Cloud today. I talked about dynamic
tiering integration earlier. What if you have
a user case where you have petabytes
of data and you have to store these
petabytes of data and query the data at the same
time with high performance? This is where integrations like
BigQuery come into picture. With dynamic tiering,
you have basically defined a hot and a warm tier. What if if you could
define another tier, where you can take the
data that is, let's say, greater than a year,
or greater than three years, depending on application needs,
and archive it off to BigQuery? But the problem is,
when you archive it off to another store, you
have to manage it, right? But the thing with BigQuery is,
BigQuery is a 0 [INAUDIBLE],, which means that there is no
servers, no software for you to manage. You just create a table and the
table just scales to the load, to the data you throw at it,
to the queries you throw at it. There is no concept
of servers at all. It's a serverless data
[INAUDIBLE],, literally. So now this basically allows
you to have another layer, scale to petabytes of data,
without incurring any operational costs. So how is this possible? You can basically
make this possible through leveraging
multiple technologies, like SAP data services is one. Data Hub is the new
kid on the block for all the workflow,
orchestration and data processing applications. You can also use
Data Flow, which is another serverless processing
data processing application, to archive data off to
BigQuery from within SAP HANA. Now what? Now you have data in SAP HANA. You have hot and warm tiers. Now you have data
in BigQuery also. How do you get a 360 degree
view of all your data for good analytics processing? So this is where we
innovated with SAP to make BigQuery
as a native option available through
smart data access. What this essentially means
is, the BigQuery tables can be virtually accessible
through SAP HANA using smart data access. So now you can do things
like creating a view that encompasses, let's say,
the hot, warm and cold tier with BigQuery,
bring them together. So when you do the query, based
on what you are accessing, the query is pushed down
to whichever layer the data exists, and you get
the results back. One thing you should
not do here-- you should probably not run full
table scans on BigQuery, because when you do
that, you're basically going to page out all the
active data in memory sitting in the SAP HANA database. But then if you run queries
that materialize data, you can just get the
process results back, because SDA just
pushes the query down directly to BigQuery. Now let's talk about
machine learning. I'll just talk about one
portion of this here. We have partnered with Deloitte. And Deloitte has actually
built a cool solution to solve the invoice
management problem. This is a business
process problem. So the solution looks like this. Let's say you have invoices
that you are getting. And you need to
input these invoices, digitize these invoices
in an SAP HANA system. Typically, you would
have a data operator. He will read the invoices. He will input the data
in the SAP HANA system. And then he has to basically
copy the invoice data and store it somewhere reliably. What the solution does that
Deloitte has built, is it uses Google's machine learning
technologies with OCR. And you can basically take
a picture of the invoice. And the solution
tool will basically extract the textual
information from the invoice, populate a digitized invoice
in the SAP HANA system, takes the original
picture of the invoice and stores it in a cloud
storage system reliably. This is all done with
a single solution. And I've actually mentioned
where the session is happening. That's happening tomorrow. I would recommend for you
to go and take a look at it. So if you're doing
it yourself, you can develop continuous machine
learning deployment pipelines. For example, this is an example. Where, if you data
on SAP HANA, and you want to derive intelligence
from that data, using the power of machine
learning available in Google Cloud, you can take
the data and throw it into Google Cloud Storage. And then you can use TPUs, which
are tensor processing units available in Google Cloud. You can portion them
as much as you want, and scale independently. And then develop your
machine learning models. And then bring the
TensorFlow serving. Now, HANA can basically
consume all the machine learning models through
TensorFlow serving [INAUDIBLE] Compute Engine. So you can basically do
continuous model training. As new data comes in,
train it, bring it back into TensorFlow serving. New data comes in. Train it. Bring it back to
TensorFlow serving. You can build a continuous
machine learning model. Google has been innovating in
the containerization space. We've been running containers
for a decade or so, and we open source Kubernetes. We also have a service called
Google Kubernetes Engine, which is a managed version
that allows you to manage Kubernetes services
running in Google Cloud Platform. SAP has standardized many
of their applications to use Kubernetes. So when you're thinking about
applications like SAP Data Hub or [INAUDIBLE],, they are
standardized on Kubernetes, which means that you can
leverage the managed Kubernetes platform that we have. You don't have to manage any
servers, services, parts. Everything is fully
managed for you. You just know
Kubernetes definition, the container definition files. And they just basically
can run these workloads with minimal operations. So this is a quick
demo, an architecture showing how you can leverage
DataHub to bridge the Google and SAP ecosystem together. DataHub also has
native integrations. The newer version
of DataHub will have native integrations with
BigQuery, PubSub and Google Cloud Storage. So if you are basically
developing big data processing applications,
you can use DataHub to bridge the Google
and SAP technologies together. So what are we doing
for developers? So we worked with SAP to
enable Cloud Appliance Library. So today, we have
80 plus solutions available in Cloud
Appliance Library for GCP. So if you want to
get started quickly and build a sandbox environment
and play around on GCP, you can get started
with CAL immediately. So lets talk about
business continuity. Google Cloud exists
across 17 regions today. And we are going to
launch three more regions by the end of this year. So we'll have 20 regions. And all these regions are
connected by Google's backbone network, which means
that you basically have access to low
latency networking for all your
infrastructure needs, plus, within the regions we also
have the concept of zones where you can architect your
applications to leverage multiple zones. And these zones--
typically, the zone to zone latency is under one
millisecond at the P95 level, which means that you can
leverage multiple zones and build highly
scalable applications across these zones. You can also develop
via strategies, using, let's say you're using
HANA systems application. You can configure asynchronous
system application across regions, and develop like
a minimal [INAUDIBLE] solution. Let's talk about best
practices and reference architectures now. So everybody must be
familiar with it, right? I mean, [INAUDIBLE]
has SAP experience. So this is a typical
sizing exercise that you go through when
you size your SAP workloads. So you have the SAP Quick Sizer. Your input all your data as
to how many users you have, how do you scale, data
edging and all those things. And then it outputs
the SAPS number. And then you take
the SAPS numbers to the infrastructure provider. In this case, it's GCP. And we will take a
look at the numbers. So you can basically take
a look at our SAPS numbers in the SAP node. And then you can map
the instance types that you want for your
workloads based on the SAPS that you have. I talked about custom
VM types earlier, right? So let's say you
have a SAPS number. Let's say, for a 16 core
machine, you know 32,000 SAPs, and on a 32 core machine,
you have 64,000 SAPS. But what if you have a
SAPS need that is 40,000? That's right in
between these two. This is where you can
leverage custom VM types for your workloads and
basically optimize your costs. For SAP HANA, this is a simple
algorithmic representation that I put together to size
your SAP HANA workloads. So there are four factors
that you need to consider. The first factor is
what source database are you migrating
from, if you are migrating from something else. If it's a row store database
like Oracle or SQL server, then you typically have to
accommodate the compression benefits that you will get. Typically it could be anywhere
between 5x through 10x. So let's say you have a 20
terabyte Oracle database. You would size it at roughly
between two to four terabytes for SAP HANA. That's factor number one. Factor number two is whether
you're looking to any data edging solutions, like using
dynamic tiering or extension nodes and so on. So when you do that, your memory
footprint drastically reduces. That's another way of
optimizing your memory footprint costs as well. The third thing is, if you are
running all app workloads-- typically SAP HANA
has memory overheads. For example, when you
are running queries, it uses temporary
space to store the data in between during
the processing. So you have to accommodate for
those memory overheads as well. So that will be
around 25% to 50%. The fourth thing is
accommodate for future growth. You are running a database. You're going to get
data in constantly. You cannot predict for
what's going to happen today. You have to predict for what's
going to happen down the line. But in the cloud, you
don't have to plan for three to five years, because
the only thing that you have to do to scale your
infrastructure in the cloud is basically stop and
start on a larger machine. But then you still have to
plan at least six months to one year in advance. That's something that has to go
into your sizing calculations as well, when doing
sizing for SAP HANA. So when you are running
NetWeaver workloads on GCP, this is something
that is mandatory for customers to install to
get product support from SAP. This is a metrics agent that
we worked with SAP to develop. This agent gives you
infrastructure level metrics, and surfaces it to the SAP
host agent, which will then consume these metrics. This will give you a
single pane of view of whatever is happening,
not only from the SAP side, but also from the infrastructure
side to the customer. And this is something
that's absolutely mandatory if you want product support
from SAP for your SAP workloads running on GCP. So let's talk about
networking best practices. So one of the first
decisions that you make, after the sizing and
everything, is basically which region do you want to
deploy your workloads in. So you choose the region
based on multiple factors. I've represented
three factors here. The first one is, where does
your business process run? You need your region,
your infrastructure, to be hosted closer to where
your business processes are running, or where
your client is. That's the first thing. Secondly, let's say you have
a tie between two regions. How do you decide which
region you want to choose? So GCP, or any cloud
product, for that matter, will have different pricing
across different regions. So that's something that
you need to consider. You cannot assume that the
pricing is similar across all the regions that we
have across the cloud. That's not the case. So you have to look at pricing. That's a second thing. Third thing is, when we
launch new instance types, we eventually will
launch these instance types across all the regions. But intermediately,
these instance types are going to be available
only in specific regions. So when you are thinking
about your deployments, you should look at what
instance types you're choosing, and whether these are
available in the regions that you are
choosing, basically, or choose a different region
based on the availability. And when you are setting
up your infrastructure, leverage private IPs for
cross-node communication. This is a good
practice, especially for latency and costs. And when you want to access
Google Cloud Platform services like GCS-- for example, to store your
backups and other things, offload backups off-- you can basically leverage
private IP access, which means that your
virtual machine doesn't have to have an
access to an internet, but with the private
APIs that you have, you can access the Google
Cloud API's services natively. The other thing is, in
any SAP installation, you have a specific
IP protocol port combination through
which traffic flows across the system. For example, you have
administrative components like SAP Router or
Solution Manager that will basically talk
to the application stack. And within the
application stack, you have [INAUDIBLE]
application server. And then you have
central services that talk to each
of the [INAUDIBLE].. And then from the
application stack, you talk to the database. There is a defined traffic
flow in your SAP installation. You can design that traffic
flow by using network tags in our VPC environment today. Now there are going
to be cases where you want to go out
of the VPC network to the internet to get
packages and things like that. So that's when you leverage NAT. So in Google Cloud, NATing
is implemented differently, through a solution
called ECMP NAT. ECMP stands for Equal
Cost Multi Path, where you can scale your NAT
environment by just adding more instances and adding those
instances to routing tables, so that it routes the
packets that are not belonging to the network, or
not targeted to the network, to the NAT instance. So Jeremy talked about how our
network [INAUDIBLE] bandwidths are. We scale up to 16 gigabits
per second for machines eight cores and above. So if you want to get
higher bandwidth than this, then you can basically
use an ECMP NAT solution and scale it independently and
get how much of a NAT bandwidth you want. So let's talk about storage. So one thing that we
absolutely recommend is to avoid using local SSD for
your SAP HANA or applications. We have certified
and tested using persistent disk,
which is basically network-attached storage. If you look at the persistent
sizes that we have supported, you need at least 1.7 terabytes,
because that's basically when you get the optimum
storage throughput for your data and logs you also
run in SAP HANA. For backups, you need at
least two exercises of DRAM, so that you can accommodate at
least two full backup copies of your SAP HANA database. There are several cost
optimizations that you can do. For example, if you have
your management components like SAP Router and Solution
Manager in a DR environment, you don't have to have
a VM and disks running on the DR site for these
management components. You can just take a snapshot
of these components. And those snapshots can just
live there in a DR scenario. You can use the
snapshots to bring up your entire system together,
at least the management components. So you can do some
of these things to optimize in terms of cost. NFS. NFS is actually one of the
major components in any SAP installation. So we have an avoid
option, which is definitely something you should not do. But then you also
have do it yourself in the GCB marketplace. For example, in do it
yourself, we typically recommend leveraging
NFS services that is provided by the
operating system provider. We also have a single
load filer solutions available in our marketplace. If you look at the
availability SLOs that Compute Engine provides,
the four lines of availability SLOs for a single VM
running in a single zone. This is basically leveraging
reliability features like live migration,
automatic instance restart, which make sure that your VMs
are up and running always, even in case of failures. So a single node
filer will typically satisfy your SLA
requirements, if they are on under 99.99%
of availability SLOs. We are also coming up
with new solutions. We have announced new solutions. Those are going to be coming up
in GA by the end of this year. So in terms of
operating system images, you're not going to just
take whatever images that we provide that
are available to you, and just use it. You're going to apply some
customization to these images. When you are applying
customizations to these images, you'll have to look
at two components. The first component is what
portions of this customization do you need every
time a VM comes up, and what portions of
this customizations do you need to be updated
once every three months. So these are static
and dynamic components. The static components need to
be baked into the VM image. This will allow you to
improve boot up times, so that when a new
VM comes up in case of a failure on some
event, you have a faster boot up time for your VMs. But the dynamic things, we
cannot do anything about it. That depends on how you
pull the packages in. There are a couple of
Compute Engine best practices that I want to talk about here. By default, you need to
enable live migration and automatic instance restart
for all your SAP installations. This absolutely needs
to happen, because we've seen clear benefits when there
are infrastructure events, when there are instances going down,
when there are security events. We live migrate your
virtual machines without any downtime
to your applications. Without this enabled, your
VMs will basically crash. So this is something
that you need to do. You should also limit API access
to a specific GCP services from within your VM. For example, typically
in SAP installation, you don't access many services. You don't access App Engine. You don't access like
PubSub and things like that. But you might access things
like BigQuery and Google Cloud Storage. So when you're creating
these instances, restrict access
only to those APIs that you absolutely
need access for. Now let's talk about a few
reference architectures. And then I'll close. So this is something where we
show our SAP HANA HA reference architecture. We have SAP HANA primary
hosted in zone one. And you have SSD persistent
disk for all your data and log volumes, so that you can satisfy
your storage and throughput requirements. The backups are
returned to [INAUDIBLE].. That's another
cost-savings that you have. Now, once you have
this enabled, you can create a similar
set up in zone B. You can do the initial data load. And then you basically have
system replication configured. You'll have a synchronous data
replication, which basically works, because the
zone to zone latencies are under one millisecond. And you can configure backups
to cloud storage at this point. So in the high availability
setup that we recommend, you can also configure
automatic failover, which means that if zone
A entirely goes down, zone B, whatever is
running in zone B, will take over and start
running your database as if nothing happened,
in a matter of seconds. A similar thing can be applied
to asynchronous replication in a DR scenario,
where you will have the databases across
region A and region B. And then in this case,
instead of configuring synchronous
replication, you will have asynchronous
replication, because you don't want every right to
block on a cross WAN network. So you basically configure
asynchronous replication to achieve this. So now in this case, you
can reduce your RPO and RTO requirements because there is
somebody who is waiting hard on the other side to
take over in a case where the entire
region A goes down. Now let's talk about scale out. Sorry about all this animation. So in a scale out
environment, we typically recommend installing
it in a single zone. You will have
masters and slaves. All the master and
slave configuration should live in a single zone. One difference here
is that all the nodes in a scale out
cluster configuration should have their
own persistent disks. Do not use NFS for data and
logs in scale out environment at all. Use NFS only for [INAUDIBLE]. For data and logs, they're all
on their independent volume. We are currently
working on announcing a solution for high
availability for scale out clusters and HANA, using
the concept of stand by nodes. But that's something
that's not out there yet. But meanwhile, you can basically
leverage instance reliability capabilities like live migration
and automatic instance restart. So I'll now hand over to
Jeremy to talk about migration. Thank you. [APPLAUSE] JEREMY SOLARZ: Excuse me? Oh, perfect. Since we have now covered
the possible reference architectures and
best practices, let's go over to
some options for how to move existing
workloads to GCP, given that you have a proper
network connection to our data centers in place. The first option I will
cover is Velostrata. Velostrata is a solution that
allows you to quickly move workloads into GCP. It thereby takes an
agentless approach, and does some
specific optimizations when moving data into the cloud. It takes a streaming approach
and performs a native boot over the wide area network to
on premise operating systems. So while the operating system
boots, it is adapted on the fly to meet the cloud
environment requirements. And then streaming starts. So only the data that you need
to work with your workloads in the cloud is
streamed to the cloud. This technology is called
intelligent streaming. And you can, after
a few minutes, already use your compute
resources in GCP. Meanwhile, transparently,
the rest of the data is migrated to the cloud. And finally, once the
synchronization is done, you can do the switch
over to the VM in GCP, and still take or
keep the backup that you have on premise. Velostrata uses some specific
optimization technologies, like multi-tier
caching, de-duplication, asynchronous write back,
and network optimizations to speed up this process. Another option that you
have is CloudEndure. CloudEndure takes a little bit
of a different approach here. It uses an [INAUDIBLE] approach. And it offers a central
management console that allows [INAUDIBLE]
migrate the data, but also do disaster recovery. So as soon as we install
the agent on your VM, the streaming starts. And in the GCP the CloudEndure
services are set up and do the replication. [INAUDIBLE] block level
copy approach in difference to Velostrata, which uses
a streaming approach. And once you have
done the migration and finished your
testing, you're ready for the
[INAUDIBLE] and can start using the machine in the cloud. And you can decide if you
want to remove the agent, or if you want to keep on
the regular data replication. So now that we have talked
about some options for how to move the data
as is to the cloud, I will show you some scenarios
how you could use these tools. Scenario one, or
option one, is you want to do, in a first
step, [INAUDIBLE] use a tool like CloudEndure
or Velostrata to move your data as is to the
cloud, and already get the first technology refresh. However, you will still
have your technical depth, and need to address this
at a later point in time. Nevertheless, since you
are already in the cloud, this is a much easier step. So many customers do this
because they have to go off of the current platform. You do contract expiration,
capacity limitations, or other non-technical reasons. So the option of moving
quickly takes precedence. The other option
that you could use, or the oddest scenario
that you could use, is to use DMO for that. And since DMO normally is
an in-place procedure that just works on the same
application server, you could use DMO with
System Move for that. That allows you to migrate to
another application server. Therefore, you can move
your workloads to GCP with this approach. So if you want to bring
your workloads to GCP, we work with various partners. We have a partner
ecosystem that you can use to implement your
SAP workloads in GCP. And Babu already
mentioned some of them-- for instance Deloitte,
Essentia, and others. Now that I have shown you the
migration part of the picture, I will move on into the
demo part of the session. So I have prepared for
you to following demo. Babu mentioned it before. We have the possibility of
deploying a high availability set up on GCP. And this can be achieved via
Deployment Manager, which is our infrastructure
as a code tool. We have provided Deployment
Manager templates, which you can leverage and
deploy a high availability set up in GCP. It uses Linux clustering
and a virtual IP address to do the simple switchover,
as well as HANA system replication. So now let me start the demo. As you can see on
the first screen, this is the bucket where you
normally store the HANA files. So you have a GCS
bucket, which you will reference in the
Deployment Manager template. So this describes, actually,
the high availability set up. And further down, you
can see the command which executes this setup. You can also see
the sample output of a working installation. Now I switch to
Stackdriver Logging, where you can see how
the normal logging output would look like on a
typically HA deployment on GCP. You will find some references
to the buckets you were using, as well as the IP
addresses that are used, and the virtual IP
addresses that is shared amongst those two instances. And finally, once the
whole setup is done, you are greeted
with the message, instance deployment complete. So you know the deployment
has been finished. And I'm switching
over to HANA Studio to show that the
deployment works. And you can see all
services are started, as well as the replication
service has started. You see the VM one as the
primary host, and the VM two as the secondary host,
and the replication type that is used. Now I log on to VM one. And we'll try to start
the failover, meaning, I will shut down the
one VM, and show you how the failover happens, and
how the takeover is happening. So I log on as administrator,
and simply shut down the network interface. In Google, that means once the
network interface is shut down, the VM automatically restarts. Now again, I move to
Stackdriver Logging, which shows you exactly what
is happening in the cloud. In this case, it shows you,
OK, a VM is going down. As you see, I have to
refresh a little bit. It takes a couple of seconds. And you will see then
that the system detects. OK, a VM is down. And it does the takeover. You can also see that
the virtual IP address that I mentioned before will
be changed to the other host, to VM two. So as you can read, it's
issuing a reset to check. It's seeing that the
VM is going down. And the 10124 is the
virtual IP address that is shared amongst
the two instances. Now the VM two is taking over. And I switch back to HANA
studio to show you exactly that first the system, or
VM two, has taken over. The synchronization is
not currently running. It takes a couple
of seconds again, until the synchronization
is properly set up again. So you can see,
now it says VM two. So it has switched the primary
host from VM one to VM two. And you can see, I'm getting
a little bit nervous. What is happening? But now you can see the
synchronization is also kicking in. The primary host is VM two. Secondary host is VM one. And the replication
mode is coming up. So it takes a couple of seconds. Of course, when the
VM one is back up, the replication can be started. And with that, the
failover is done and you still have
a running system. And as I said, this
is all provided out of the box via our
Deployment Manager templates. You have access to
these templates. You can further look into the
code that is written there. So it uses Ginger and
Python to script this. And you can drill down and find
out, OK, what is happening. You can also attach
additional logic if you need, all to your liking. [MUSIC PLAYING]
