SAP HANA MultiTenancy (MDC)
What’s the best thing about SAP HANA MultiTenancy ?
I’ll answer that at the end of the blog, but first I’m going to talk about…
SAP HANA Tenant Mobility
What is SAP HANA Tenant Mobility and where did it come from ?
Let’s start from the beginning, we all know what HANA MultiTenancy is right ?
If not, in a nutshell as described very nicely on help.sap.com
So this is what Multiple Tenancy and Multiple Database Containers are, but, what does it look like ?
This is how Tenants look on a Single HANA system:
Source: SAP HANA MultiTenancy Administration Guide
We can see, we have 1 HANA System (Single Node), with many Tenant Databases from many SAP systems.
For more than a generation now, in the SAP world we have been installing SAP systems with a classical
approach of Database and Central Instance (aka Primary Application Server) on one “physical host or partition”
and Additional Application Servers (aka Dialogue Instances) on other hosts.
The HANA MultiTenancy moves away from this model, to a model of having 1 HANA System hosting many
Databases from many SAP systems.
This has many benefits which I will go into at the end of the blog.
Recap, we now know what SAP HANA MultiTenancy is, and have links to resources for further information.
So, what about SAP HANA Tenant Mobility ?
Imagine, in your SAP Landscape, at each layer of the SAP Landscape you have more than 1 HANA system.
This means, at the Dev layer of your SAP Landscape you have several HANA Systems (probably Appliances
and in the future TDI) and at the Q layer of your landscape you have several HANA systems and the same
at the Production layer of your SAP landscape you have several HANA Systems.
Each of these HANA Systems are probably hosting a single Database for 1 SAP system.
Imagine you convert all of these HANA Systems to MultiTenancy and on each HANA system you have many
Databases, this means at each layer of your SAP landscape you’ve got several HANA Systems and on
each HANA system you have several Databases from different SAP systems.
Eg, let’s say, in Production we have 3 HANA Systems like this:
. HANA System PH1
. Tenant DB for a SAP CRM
. Tenant DB for a SAP SRM
. Tenant DB for a SAP GRC
. HANA System PH2
. Tenant DB for a SAP ECC
. Tenant DB for a SAP BW
. Tenant DB for a SAP Portal
. HANA System PH3
. Tenant DB for a SAP CE
. Tenant DB for a SAP PI
. Tenant DB for a SAP MDM
When we planned this setup, we calculated all of the sizings, all of the capacity on HANA required by the
different SAP backends, we calculated the average monthly growth of every SAP system’s DB’s and
we ensured that that the systems we put together on each HANA would have enough capacity for growth.
(Regarding what SAP system’s DB’s to put together as Tenants on which HANA Systems, there is an
OSS Noteon this, references at the end of the blog)
And everything was fine for a certain amount of time.
But then our company did some mergers and acquisitions and the ECC and BW DB Tenants started growing,
and we began to see that the rate of growth of the DB’s will outgrow the capacity of the HANA system PH2.
At the same time, the CE for certain reasons was due to be retired and consequently the Tenant on PH3
becoming redundant and freeing up capacity on PH3.
I am sure, on the larger landscapes we are all familiar with Logical/Virtual Partition Mobility where a SAP
system on a Virtual Operating System Unix or WinTel can be moved from Server to Server. In IBM Power
terms this is called LPAR Mobility and it is where SAP Systems and the LPARs they are running on are moved
from Managed System to Managed System to ensure the most efficient use of available capacity.
And this is the whole point of SAP HANA Tenant Mobility, it is the possibility to move a HANA
Tenant DB from one HANA System to another to ensure the most efficient utilization of the SAP HANA
capacity in your landscape.
Coming back to the example, using SAP HANA Tenant Mobility, as ECC and BW DB Tenants are out growing
PH2, we can move one of the Tenants to PH3 where we have capacity and this saves us Scaling Out/Up our
existing HANA investment.
The principles for how to move a SAP HANA Tenant from one SAP HANA System to another are fully
supported by SAP and described clearly in both the SAP HANA Administration Guide and the SAP HANA
MultiTenancy Administration Guide.
One top tip to help make moving your Tenant DBs from one HANA System to another easier,
Assumption 1 –
if we implement SAP HANA Tenant Mobility, Tenant DB’s will only ever reside on HANA systems respective to the
SAP system’s layer of the landscape. ie, Tenant DB’s from Dev SAP systems will only ever reside on a Dev HANA
system, Tenant DB’s from SAP systems in the QA layer of the landscape will only ever reside on HANA systems in
the QA layer of the landscape, and Tenant DB’s from Prod SAP systems will only ever reside on Prod HANA systems,
ie, Tenants will never move from one layer of the landscape to another
Assumption 2 –
obviously, if we want to make SAP HANA Tenant Mobility possible we have more than one HANA system at every
layer of our landscape, more than one Dev HANA system, more than one QA HANA System and more than one
Prod HANA system considering these assumptions, if we want SAP HANA Tenant Mobility to be possible with the
least amount of complication,
when we create a Tenant DB on any HANA System at a certain layer of the landscape (Dev or QA or Prod), there
cannot be two Tenant DB’s in any layer of the landscape with the same Tenant ports, otherwise, moving a Tenant
from one HANA system to another will be very complicated.
Therefore, when choosing your Tenant DB ports, keep track of every Tenant DB at every layer of your
landscape and ensure across all HANA systems at each layer of the landscape you do not have two
Tenant DB’s with the same ports.
That’s it, that’s SAP HANA Tenant Mobility.
Ok, the next item on the list, what’s the best thing about SAP HANA MultiTenancy ? Give me one reason why
my company should implement SAP HANA MultiTenancy ?
During the SAP HANA journey, there have been a lot of constraints, the hands of SAP implementors have been
tied in many ways, for example,
. only this Operating System is supported
. only this Hardware is supported
. the Hardware is very expensive
. the Appliance implementation model
yes this is changing, yes we have more Operating Systems, yes we now have more supported Hardware, yes we
now have a choice between the Appliance Model and TDI,
but what SAP HANA MultiTenancy brings is AGILITY in your SAP HANA road map.
With MultiTenancy, you can now (providing you have available capacity) install whatever SAP systems on HANA
you want on one of your existing Appliances or TDI systems without (as was the case in the past) being slowed down
by having to buy new hardware.
We are running MultiTenancy (MDC) in Production, and consequently we have landscape layers of HANA systems
on MDC including a MultiTenancy Sandbox HANA system.
Recently “the Business” came with a demand, please set us up a Sandbox S4HANA system, we want to have a look
Two years ago, the bottleneck would have been, sorry you’ll have to wait, we need to buy a new HANA Appliance,
now with MultiTenancy, we just setup an S4HANA Primary Application Server and put the DB as a Tenant on
the Sandbox MDC HANA system. Voila.
Even if you’re not ready to go into Production with HANA MDC, set it up in your Sandbox so that you can benefit
from the agility of prototyping SAP systems on HANA.
There are other benefits, for example, patching the DB, you’re going to be patching 1 db instead of many. Historically
we generally had a 1:1 relationship between SAP systems and DB’s now with HANA MDC we have a Many:1
relationship and consequently less maintenance.
Recommendation: have a look into SAP HANA MultiTenancy,and if you implement it, keep track of the Tenant DB Ports
which you choose so that in the future when you take advantage of SAP HANA Tenant Mobility you are able to more
smoothly move Tenant DBs from one HANA system to another.
2104291 – FAQ SAP HANA Multitenant Database Containers
2101244 – FAQ SAP HANA Multitenant Database Containers
2121768 – Considerations with SAP HANA multitenant database containers and SAP BW