Good day everyone! I hope you all enjoyed holidays, there is nothing better than spending time with family and friends, isn’t it? Now it’s time to gear up for more success and productivity in 2017!

I have realized that especially after the recent release of “more advanced” S/4 HANA products, the SAP community is now more focused on cloud, on premise or hybrid deployment options and it seems to me that the actual underlying SAP HANA database architecture is usually overlooked even though it is the core of the entire implementation. In case you end up with wrong HANA database architecture, it would be really hard to have a proper high-availability and disaster recovery setup in your landscape no matter where you deployed it – cloud or on premise. And remember, when it comes to architecting SAP HANA, there are 3 key elements must be considered carefully; scalability, effectiveness and fault tolerance. In this article, I aim to provide detailed information regarding the current available SAP HANA database architecture and deployment options.

There are six database deployment scenarios; three of them are perfectly fine for production use, other two options come with some restrictions in production and last one is available for non-production systems only.

1. Dedicated Deployment: This is the classical and most common scenario. Usually preferred for optimal (read: high) performance. As you can see from the below figure, there is one SAP system with one database schema created in one HANA DB running on one SAP HANA appliance.

Figure 1: SAP HANA Dedicated Database Deployment Scenario

2. Physical Server Partitioning: In this scenario, there is one storage and one HANA server which is physically split into fractions. Two separate operating systems installed on separate hardware partitions and hosting two separate HANA databases each have its own database schemas dedicated for respective SAP systems. There should not be any performance problems as long as you have a correct SAP HANA sizing specific for this purpose.

Figure 2: SAP HANA Physical Server Partitioning

 3. MDC (Multitenant Database Containers): I previously released an article about MDC concept, you can read it here. Basically, there is one HANA database (and one system database container for administration purposes) and multiple tenant database containers can be spread on several hardware. Perfectly fine for production usage and I have to admit that this scenario is becoming my favourite due to its flexibility and scalability J More information can be found in SAP note 2096000.

Figure 3: SAP HANA MDC Deployment

4. MCOD (Multiple Components in One Database): The concept of having multiple applications in one database was available to SAP customers for more than 10 years, of course not with SAP HANA database back in then, but the technology was already there. This is basically multiple SAP systems/applications running on one SAP HANA database under different database schemas. Note that there are some restrictions in production usage especially when combining applications on SAP HANA on a single database explained in note 1661202 (white list of applications / scenarios) and 1826100 (white list relevant when running SAP Business Suite on SAP HANA). These restrictions do not apply if each application is deployed on its own tenant database, but do apply to deployments inside a given tenant database.

Figure 4: SAP HANA MCOD Deployment

5. Virtualized Deployment: Since SAP HANA SPS 05, SAP has been supporting virtualization on the HANA appliances. This scenario is based on VMware virtualization technology where separate OS images installed on one hardware, and each image is containing one HANA database hosting one database schema for each SAP system. Note that there are some restrictions to the hypervisor (including logical partitions). More information can be found on SAP note 1788665, 2024433 and 2230704.


Figure 5: SAP HANA Virtualized Database Deployment

 

6. MCOS (Multiple Components in One System): MCOS scenario allows you to have multiple SAP HANA databases on one SAP HANA appliance, e.g. SAP DEV and Test systems on one hardware. Production support for this scenario is restricted to SPS09 or higher due to the availability of some resource management parameters. SAP also does support running multiple SAP HANA DBMSs (SIDs) on a single production SAP HANA hardware installation. This is restricted to single host / scale-up scenarios only. I personally don’t recommend this scenario because it requires significant attention to various detailed tasks related to system administration and performance management. Since MCD is available, it would be a much better option in terms of supportability and scalability. More information about MCOS, check SAP note 1681092.

Figure 6: SAP HANA MCOS Deployment

 

Which one I should choose?

For production environments, I would consider options 1 (Dedicated Deployment) and 3 (MDC) depending on a few factors including the existing infrastructure setup and capability, availability and performance requirements of the business, database sizes and structure, HA or DR setup requirements (if any), and overall SAP landscape size. The reason I favour MDC over Physical Server Partitioning is because it can achieve almost everything Physical Server Partitioning do, and comes with great flexibility in terms of supportability, scalability and re-architecture when needed.

Have you already migrated to SAP HANA? If so, which database deployment option you selected and what was the reason?

Have other ideas or questions regarding SAP HANA database deployment scenarios? Leave a comment below, I would love to help you and learn from you as much as I can!

References and further reading:

SAP HANA System Types

SAP HANA System Architecture Overview

SAP HANA Database Architecture

Multitenant Database Containers

SAP HANA Administration Guide


If you liked this post, you might like these relevant posts:

SAP HANA Multitenant Database Concept

Choosing The Most Effective Approach for Technical Migration to SAP HANA

 

 

To report this post you need to login first.

12 Comments

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

  1. Jens Gleichmann

    Hi Alper,

    thanks for collecting all the different deployment options at one place. Just a few questions:

    1. The description “Physical Server Partitioning” is a little bit unlucky. To part physical servers with separate OS installation you need a kind of hypervisor (managing ressources like network adaptors, CPU, memory and storage). So I think you mean the LPAR concept of IBM. If I get you wrong please provide the official details for this method.
    2. I would appreciate if you could also add some details (what is supported) about the most known scenarios with two schemata like Solution Manager or BW with Portal.
    3. I’m missing some more pros and cons for each deployment option and the combination with other features like workload management, system replication (cost optimized)
    4. I’m missing the cloud approach.
    5. I’m missing the technical co-deployment for instance two suite components
    6. For prod. usage all the options have to be deployed on supported hardware which is officially certified by SAP => listed in the hardware directory

    If you could add this missing details, the blog is a great starting point for those who are searching for the right deployment option.

     

    Thanks!

    Regards,

    Jens

     

    (1) 
    1. Alper Somuncu Post author

      Hi Jens,

      Thanks for the comment and sorry for my late response as I don’t check this blog regularly. Actually I thought this post more like a first step for beginners so I didn’t include many details. Will certainly post some specific comparisons.

      You are right, but since physical server partitioning is handled by hardware vendors mostly, I didn’t provide detailed information.

      With two schema, the most common scenario is MDC, physical server partitioning usually not preferred as it adds extra layer of complexity on the OS level. Which components you combine depends on their importance in your landscape. For example, we are doing an MDC setup for 3 business systems (ECC, BW, SRM) and because ECC has the top priority we are building it as MDC but only one system per host. BW and SRM have less priority than ECC so we will combine them on another host. We are also adding two more hosts for High Availability via System Replication and another two hosts for DR with System replication. So 6 host will be sufficient to cover all 3 critical business systems with HA and DR in place.

      For the system repication I am currently performing some test, will publish the results soon.

      Cloud approach (HEC) is too damn expensive so it still needs some more time. I’ll look at those options as well.

      What exactly you mean with “technical co-deployment”? I know some companies installed ECC, SRM and BW databases on one HANA host (in MDC) and they live happily with that. However, system replication as HA solution may not be the best approach in this case becase if you have a problem with one of the databases (and you need to restart it for instance) you will need to failover other 2 systems to other host first so restart the databases (incl system database). Host Auto-Failover might be a better option for HA. Of course it depends on your existing landscape setup and cost.

      Thanks for the link of supported hardware which is officially certified by SAP.

      Cheers,

      Alper

      (0) 
  2. Ilke Tutku Senol

    Hello Alper,

    Thank you for the great article. I want to ask that Is multiple instance (one os, more than 1 sid) is supported for Production systems? And why didn’t you mention about multi instances db?

    Regards

    Tutku

    (1) 
    1. Alper Somuncu Post author

      Tutku, thanks for the comment.

      Yes, that scenario is no.6 MCOS in the list and its production support is restricted to SPS09 or higher due to the availability of some resource management parameters. I personally favour MDC over this scenario because if you have constant performance issues with MCOS the first thing SAP will ask is to shutdown the other instance before even investigating it. Also you need to carefully tune the memory parameters to make this architecture running. That is not too bad if your secondary system is DR but still offers a longer RTO than System Replication for instance. You can check SAP Note 1681092 for more details.

      (1) 
  3. Ed Hickey

    Looking to understand the HA /DR capabilities in a dual datacentre scenario.

    Specifically we are looking at SAP CAR and would like to understand best practices for not only a single datacentre and HA and what a dual datacentre scenario would look like.

    (0) 
    1. Alper Somuncu Post author

      Hi Ed,

      Sorry for my late answer as I usually am more active on LinkedIn.

      I’d be happy to help.

      Are you planning to run DR crossite? Can you provide more information?

       

      Kind regards,

      Alper

       

      (0) 

Leave a Reply