Skip to Content

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

Multitenant Database Containers – SAP HANA Administration Guide – SAP Library :

     MDC.png


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:


     MDC 1.png

                         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,

then…

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 ?

AGILITY

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

at S4HANA.

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.




References


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


http://help.sap.com/hana/SAP_HANA_Multitenant_Database_Containers_en.pdf


http://help.sap.com/hana/SAP_HANA_Administration_Guide_en.pdf

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply