Skip to Content

Introduction:

In 2011, the SAP HANA database shipped with appliance deliver model (pre-configured hardware with software – Linux/HANA installed from the hardware vendor) and SAP introduced HANA tailored data center integration delivery model (pure server with the certified storage/network and Linux/HANA configuration by the customer or partner) in year 2013. In the early stage of SAP HANA server, there are lots of limitation with multiple HANA instance in Production HANA server which mean the customer will required to purchase 2 separate HANA server if they plan to have BW on HANA and ERP on HANA for production usage or maybe another HANA server for the HANA platform usage only.

With the innovation of the SAP HANA technology, the multiple HANA instances in Production HANA is supported and customer can have multiple SAP application running on Production HANA server as in “SAP Note 1661202 Support multiple applications one SAP HANA database / tenant DB”. There are several ways to have multiple HANA instances in PRD HANA server for example MDC, VMware, LPAR and MCOS which currently supported for Production usage.

What is it about?

The diagram and table will give you an idea on what is the difference between the multiple HANA instance technologies. Always remember to have the clear objective and the right SAP Partner for the HANA design and planning phase when you decided to go for SAP HANA journey.

Figure 1: Multiple HANA instances logical diagram

    

Multitenant Database Containers (MDC)

VMware (Vsphere 5.5)

Hardware logical partition (LPAR)

Multiple Components One System (MCOS)

All the tenant DB sharing the same system HANA revision

Independent HANA revision of each HANA instance

Independent HANA revision of each HANA instance

Independent HANA revision of each HANA instance

No additional SAP HANA License

Separate SAP HANA  License

Separate SAP HANA  License

Separate SAP HANA License

No additional hypervisor virtualization license and hardware independent

Vsphere license required

LPAR technology only offered in certain hardware vendor (for example Hitechi, IBM)

No additional hypervisor virtualization license and hardware independent

No additional machine for hardware/vm management console

Additional machine needed for VM management console

Additional machine for LPAR management console

No additional machine for hardware/vm management console

No support on storage snap shot backup

Support on storage snap shot backup

Support on storage snap shot backup

Support on storage snap shot backup

Shared SAP HANA Binaries – Yes

Shared SAP HANA Binaries – No

Shared SAP HANA Binaries – No

Shared SAP HANA Binaries – No

1 Linux license

Multiple Linux license

Multiple Linux license

1 Linux license

Support > 4 socket hardware

Maximum of 4 socket hardware

Support > 4 socket hardware

Support > 4 socket hardware

Support > 1TB memory

Maximum of 64 vCPU and 1TB memory

Support > 1TB memory

Support > 1TB memory

Tenant DB only can restore to tenant DB

No dependency of tenant DB backup/restore

No dependency of tenant DB backup/restore

No dependency of tenant DB backup/restore

Multiple BW on HANA – Yes

Multiple BW on HANA – Yes

Multiple BW on HANA – Yes

Multiple BW on HANA – No

No Performance degrade

Performance degrade about 8-12%

No Performance degrade

No Performance degrade

No additional maintenance required for vsphere patch, Lpar patching

Required Vsphere maintenance

Required LAPR maintenance

No additional maintenance required for vsphere patch, Lpar patching

Hardware Resource Management – SAP HANA internal

Hardware Resource Management – Hypervisor

Hardware Resource Management – Firmware

Hardware Resource Management – SAP HANA internal

Table 1: Comparison MDC vs VMware vs LPAR vs MCOS:-

*Please note that the HANA on vSphere 6 is GA since May 2016 as in SAP Note 2315348 – Single SAP HANA VM on VMware vSphere 6 in production with the maximum size of 128 vCPU and 4TB of memory. The SAP HANA version run on vSphere  will required at least SPS11 or later.

Our Experiences:

In the recent design and planning phase that we had, there is a debate between MDC and VMware and LPAR. The customer having 2 BW systems whereby one of the BW 7.31 system is already migrated to HANA (with HANA rev 97) and the other BW 7.01 still running on Oracle. They plan to migrate the BW 7.01 into the existing HANA landscape. At first, the customer was considered VMware for their to-be HANA landscape which plan to reuse the existing HANA server and install the VMware hypervisor on top of the server. Somehow, there is limitation of the maximum 4 socket and maximum 1TB for the VSphere 5.5 (supported for PRD usage) hence the VMware option was dropped and left with MDC and LPAR option. Some of you might curious that the MCOS option might be the case for the customer but the “SAP Note 1666670 – SAP BW powered by SAP HANA – Landscape Deployment Planning” mentioned that SAP does not support the deployment of multiple SAP BW systems on the MCOS option whereby if SAP HANA multitenant database containers are in use, SAP does support the deployment of multiple BW systems (with one BW system deployed per tenant database) in a production environment.

The next consideration from the customer will be the existing HANA rev 97 is not possible upgrade to rev 102 due to existing running project. As we all know the MDC is introduce in HANA SPS9 and it work better in HANA SPS 10, furthermore the MDC option will only have one HANA revision for all the tenant DB underneath which mean you can’t have HANA rev97 for BW 1 and HANA rev102 for BW 2 in the MDC option. The requirement from the customer is very clear that existing BW 7.31 on HANA is only can run on HANA rev97 and the other BW 7.01 will required migrate to HANA rev 102 or above. Hence, we left with the option of LPAR for the entire design and planning exercise. Of course, they have to live with hardware vendor that provide the LPAR technology plus maintenance of the LPAR, multiple set of HANA and OS. It took us about couple of weeks to explain the pro and cons on different option of the multiple HANA instances in Production HANA server and we even sit together with the hardware vendor to discuss about the possible option for the customer.

The other design and planning activities that we have for the customer who are currently running the BW on MSSQL and ERP on MSSQL and they plan to migrate both BW and ERP to HANA in the near future. They do not want to maintain so many OS, HANA revisions and paying additional license fees for Hypervisor. As a results, the MDC option will be the best fit for this kind of customer.

Conclusion:

The SAP Partner able to identify which method is suitable for the customer needs throughout the HANA design and planning phase before the actual HANA project kick start. This HANA design and planning phase is necessary to identify the right HANA architecture landscape, HANA journey roadmap, cost and budget for the project implementation and etc. We got some customers who do not run the HANA design and planning phase and causes them having the over-size or under-size HANA server which incurred most cost to the HANA project, they even can’t enjoy the business benefit of SAP HANA without the proper HANA roadmap.

References:

SAP Note 1681092 – Multiple SAP HANA DBMSs (SIDs) on one SAP HANA system

SAP Note 1995460 – Single SAP HANA VM on VMware vSphere in production

SAP Note 2024433 – Multiple SAP HANA VMs on VMware vSphere in production

SAP Note 1788665 – SAP HANA Support for virtualized / partitioned (multi-tenant) environments
SAP Note 1661202 – Support multiple applications one SAP HANA database / tenant DB

To report this post you need to login first.

2 Comments

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

Leave a Reply