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.
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. 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.
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).
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.
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.
No comments:
Post a Comment