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.
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.
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.
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.
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.
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:
--
If you liked this post, you might like these relevant posts:
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 Architecture Overview
SAP HANA Database Architecture
Multitenant Database Containers
--
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
- SAP Managed Tags:
22 Comments
