This section discusses the various different types of technical deployment options (see Figure 2.1), such as:
- single application on one SAP HANA system (SCOS)
<li>multitenant database containers (MDC)</li> <li>multiple applications on one SAP HANA system (MCOD)</li> <li>multiple SAP HANA systems on one host (MCOS)</li> <li>SAP HANA with virtualization</li>
Figure 2.1: SAP HANA deployment options
2.1.1 Single Application on One SAP HANA System (SCOS)
The standard SAP HANA deployment is a single SAP HANA application running in a single database schema in a single SAP HANA database as part of an SAP HANA system or, as SAP calls it, a single application on one SAP HANA system (SCOS). This is a simple, straightforward scenario that is supported for all scenarios without restriction.
For example, two SAP HANA appliances are sufficient for a two-system SAP BW landscape (development and production). There is no failover for the production system in this setup. This might be acceptable for customers where reporting is not considered business critical.
Figure 2.2: SAP HANA standard deployment option
The standard SAP HANA deployment option (see Figure 2.2) is a system layout which was often used in the early days of SAP HANA and is still used by customers who are only deploying SAP HANA for a limited use case such as SAP BW.
Note that in the example above, only the SAP HANA database is installed on the appliance. The SAP NetWeaver application server is deployed on a different, in this case, virtual machine running on SUSE Enterprise Linux.
2.1.2 Multitenant Database Containers (MDC)
SAP HANA supports multiple isolated databases in a single SAP HANA system. These are referred to as multitenant database containers. The multitenant database container setup of SAP HANA is comparable to the SQL-Server or Sybase instance layout. There is an SAP HANA instance, a system database and several tenant databases. The system database is used for central system administration. It is also the database from which recoveries of the tenant databases are initiated.
An SAP HANA system installed in multiple-container mode is identified by a single system ID (SID). An SID and a database name identify databases. From an administration perspective, there is a distinction between tasks performed at system level and those performed at database level. Database clients, such as the SAP HANA studio, connect to the system or the tenant databases.
All the databases in a multiple-container system share the same installation of database system software, the same computing resources, and the same system administration. As a result, software upgrades or system maintenance impact all databases. In addition, system replication applies to the whole SAP HANA instance; that is, for all tenant databases including the system database.
Newly created tenant databases are automatically integrated into the replication process after they are backed up.
However, each database is fully isolated when it comes to:
- Security—Each tenant DB has its own users and authorizations which are completely separate from the other tenant databases. The database catalog and repository are also isolated in each tenant DB.
<li>Backups—With SAP HANA multitenant database containers, if each application is deployed on its own tenant DB, then each can be backed up and recovered independently.</li> <li>Moving and copying tenant DB’s—Tenant databases can be moved or copied using the backup and restore capabilities. This only needs downtime for the tenant database affected. The other tenant databases can stay online. Simply perform a backup and then either create a new tenant database and restore the backup into this tenant database, or restore the copy into an existing tenant database.</li> <li>Traces and logs—Each tenant database has his own set of trace and log files.</li>
In general, all applications that are supported to run on a single database SAP HANA system are also supported to run on an MDC system. Tools exist to convert a single-container system to a multiple-container system.
Many customers use MDC to consolidate several SAP HANA databases into one SAP HANA system. This setup minimizes the number of appliances and reduces total cost of ownership (TCO).
Consider the following example:
The customer has SAP ERP, SAP PO and SAP CRM landscapes. Every landscape consists of a development, acceptance and production system. In addition, system replication is a requirement for all production systems.
The following SAP HANA landscape has been designed (see Figure 2.3):
- There are two appliances; one for the production and another for the non-production SAP HANA systems.
<li>The appliance for production hosts an MDC installation for the production SAP-HANA systems. The MDC consists of a system database and three production databases, one each for SAP ERP, SAP PO and SAP CRM.</li> <li>The appliance for the non-production systems hosts two MDC installations. One MDC installation for the development and another for acceptance systems. Each MDC installation has one system database and three non-production databases, one each for SAP ERP, SAP PO and SAP CRM. The two MDC installations have their own SID and software installation and are actually MCOS (multiple SAP HANA installations on one system). MCOS is explained in detail in <a href="#c2.1.4">Section 2.1.4</a>.</li> <li>On the appliance for the non-production systems, there is an MDC installation for the failover of the production MDC system. This SAP HANA system has the same layout as the SAP HANA system on the production system and system replication is set up between both.</li> <li>Only SAP HANA is installed on the appliances. The SAP application servers for SAP ERP, SAP PO and SAP CRM are installed on two ESX servers running VMware. High availability for the production application servers is guaranteed by VMware HA (see <a href="../Text/171EN_HANA-Deployment-Guide_0011.html#c7.1.1">Section 7.1.1</a>).</li> <li>Finally, each ESX server also hosts an SAP Content Server or MaxDB database.</li>
Figure 2.3: SAP HANA landscape with MDC and MCOS
2.1.3 Multiple Applications on One HANA System (MCOD)
With the Multiple Components in One SAP HANA system (MCOD) setup, several independent SAP components can be installed in one database. Every component uses a different database user schema.
MCOD is not unique to SAP HANA
<p class="BoxTipText"><img alt="Tip" class="BoxImage" height="90" src="https://et-production.fra1.digitaloceanspaces.com/0/289/HTMLReader/images/icon-hint.png?X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=QKGDUDTCQFHSFKCYSNLS%2F20230418%2Feu-fra-1%2Fs3%2Faws4_request&X-Amz-Date=20230418T095052Z&X-Amz-SignedHeaders=host&X-Amz-Expires=3600&X-Amz-Signature=eec40a1679b53ea650da1b50f27160a4a48db36f0aa489f05e6a92600abc643c" width="90" loading="lazy">MCOD has been around for quite some time. These systems have been mostly used to combine SAP ERP with SAP CRM or SAP SRM systems. SAP CRM and SAP SRM read and write data from and to the backend system SAP ERP. They need the backend system to function correctly. As such, downtime on SAP ERP systems always results in downtime of SAP CRM and SAP SRM, whether they use MCOD or not.</p>
This deployment type is available for production SAP HANA systems, albeit with restrictions. The restrictions are listed in SAP Note 1661202 – Support for multiple applications on SAP HANA. If the Business Suite is deployed on the SAP HANA system, the restrictions of SAP Note 1826100 – Multiple applications SAP Business Suite powered by SAP HANA apply.
Further considerations: there is a section of Note 1661202 that discusses aspects that should be taken into account when considering deploying multiple applications on the same SAP HANA system. Some of the key considerations discussed in this section are as follows:
- If running multiple applications on one SAP HANA system, there is a risk that one application could consume a significant amount of available CPU and memory resources, thereby reducing the amount of such resources available for the other applications at a given point in time.
<li>Capacity planning is crucial when combining different applications, components and scenarios on a single SAP HANA system. You must determine the resource allocation needs for each application and then add them together to estimate the required sizing for your SAP HANA system.</li> <li>Backup and Recovery is only supported at the SAP HANA database level, and not at the database schema level. This means that a point-in-time recovery for the SAP HANA system will impact all applications residing on that SAP HANA system. This is unacceptable from a disaster recovery perspective. MCOD should, therefore, only be considered for non-production systems.</li> <li>A system copy of one application is not possible. The database is always copied completely.</li> <li>High availability is always done at database level, not at application level.</li>
2.1.4 Multiple applications on One SAP HANA System (MCOS)
Several applications on one System (MCOS) simply refers to the scenario where more than one SAP HANA database is installed on one server.
Each of the databases in this configuration has its own System Identifier (SID), software installation and directory structure. They are basically completely independent from any other database which may reside on the same system.
MCOS is supported with restrictions. These restrictions are documented in SAP Note 1681092 – Multiple SAP HANA databases on one SAP HANA system. It basically comes down to the following:
- Running multiple SAP HANA DBMS’s (SIDS) on a single production SAP HANA hardware installation is supported for single host or scale-up scenarios only. Scale-out is not supported.
<li>Running multiple SAP HANA DBMSs (SIDs) on a single non-production or scale-out SAP HANA environment is supported without restrictions (DEV, QA, test, production fail-over, etc.).</li>
- When deploying MCOS, it’s important to ensure that the system is sized appropriately, with capacity planning that reflects the additional resources necessary to accommodate the additional database(s). SAP recommends working closely with the hardware partner to ensure adequate capacity planning.
<li>Additionally, running MCOS may impact performance of various types of operations, as competition for memory and or CPU resources may occur. This performance impact can occur despite adequate sizing. MCOS is not recommended for use cases where optimal performance is considered particularly important.</li>
Figure 2.4 is an example of an MCOS environment. The production SAP HANA system is isolated on the primary appliance. The development and acceptance SAP HANA systems share the secondary appliance together with the failover SAP HANA system for production. If a system failure occurs on the primary appliance, the production SAP HANA system is resumed on the secondary system and the development and acceptance SAP HANA system are stopped. The primary appliance is a standard SAP HANA deployment or SCOS while the secondary appliance is a typical example of a Several Databases on One System or MCOS.
Figure 2.4: MCOS environment with SAP HANA Replication
2.1.5 SAP HANA with Virtualization
With virtualization, each virtual machine houses an independent operating system and appears like a real host. From the SAP HANA server installation perspective, it appears as if the SAP HANA database is deployed in the same manner as the standard SAP HANA deployment.
There are some important restrictions in regard to the technical deployment type SAP HANA with virtualization that must be considered. An important reference for the topic of SAP HANA with virtualization is SAP Note 1788665—SAP HANA running on VMware vSphere VMs and the FAQ document that is attached to that note.
The following considerations should be taken into account with virtualization:
- Each SAP HANA instance or virtual machine needs to be sized according to the existing SAP HANA sizing guidelines and corresponding hypervisor vendor recommendations.
<li>CPU and memory over-provisioning must not be used.</li> <li>The SAP HANA system setup needs to be done by an SAP HANA certified engineer on SAP HANA certified hardware and successfully verified with the SAP HANA hardware configuration check tool (SAP HANA Tailored Datacenter Integration option). Alternatively, the system can be delivered pre-configured with the hypervisor and the SAP HANA software installed by an SAP HANA hardware partner (SAP HANA appliance option).</li> <li>The maximum size of a virtual SAP HANA instance is limited by the maximum size the hypervisor supports per virtual machine and the application dependent core-to-memory ratios.</li>
Virtualization comes in two flavors, software and hardware virtualization.
Software virtualization is done by software, or so-called hypervisor, which emulates a physical machine. The difference between software and hardware virtualization is that with software virtualization the same hardware platform is shared between the hypervisor and the virtual machine.
Software virtualization on an x86 hardware platform will only be able to run virtual machines capable of running on that platform. The hypervisor divides the hardware resources among the different virtual machines or guests. The biggest advantage of virtualization is that hardware resources can be better divided according to the needs of the different virtual systems. These guest operating systems are unaware of the fact that they are running on a virtualized environment. Examples of software virtualization are VMware and Microsoft Hyper-V.
The following hypervisors are currently supported with SAP HANA:
- VMware vSphere 5.1 with SAP HANA SPS 05 or later for non-production use cases
<li>VMware vSphere 5.5 with SAP HANA SPS 07 or later for production and non-production use cases: <ul><li>in general availability for single-VM scenarios (See SAP Note 1995460 for specific information and constraints).</li> <li>in general availability for multi-VM scenarios (See SAP Note 2024433 for specific information and constraints).</li> <li>in general availability for SAP BW, powered by SAP HANA scale-out scenarios (See SAP Note 2157587 for specific information and constraints).</li> </ul></li>
- VMware vSphere 6.0
<ul><li>in general availability for SAP HANA SPS 09 or later for non-production use cases</li> <li>in general availability for and with SAP HANA SPS 11 or later for production single-VM scenarios (See SAP Note 2315348 for specific information and constraints).</li> </ul></li>
Hitachi LPAR 2.0
Hitachi LPAR 2.0 is supported as of SAP HANA SPS 07 for production and non-production use cases. It is in controlled availability for single and multi-VM scenarios. (See SAP Note 2063057 for specific information and constraints).
IBM Power VM LPAR on IBM Power Systems is supported for production use-cases. It is generally available for single-VM and multi-VM scenarios with up to 4 LPARs on 1 server. (See SAP Note 2055470 for specific information and constraints).
KVM and XEN
Software virtualization with KVM (on SUSE SLES 11 and 12 or Redhat RHEL 7.x) and XEN (on SUSE SLES 11 and 12) with SAP HANA SPS 11 (or later releases) are supported for non-production use cases.
Software virtualization is supported with Huawei FusionSphere version 3.1 and 5.1:
- support for FusionSphere 3.1 as of SAP HANA SPS 09 for production and non-production use cases in controlled availability for single-VM scenarios (See SAP Note 2186187 for specific information and constraints).
<li>support for FusionSphere 5.1 as of SAP HANA SPS 10 / 11 for production and non-production use cases in controlled availability for single-VM, multi-VM and scale-out scenarios (See SAP Note 2279020 for specific information and constraints).</li>
Be aware that access to these SAP Notes is restricted to customers participating in the controlled availability phase.
With hardware-enabled virtualization or partitioning, the software which divides the hardware among the different partitions is implemented in the hardware itself. The partitions are electrically isolated. They operate independently of each other, even to the extent that a partition can be powered up or down without impacting any of the other partitions. An advantage of hardware partitioning is that there is no software hypervisor and, therefore, less overhead for the virtualization layer.
Hardware partitioning technology currently supported for running SAP HANA in a partitioned environment are:
Hewlett Packard nPartitions
- HP nPartitions in the context of HP CS 900 with Superdome X servers for production and non-production use cases. (See SAP Note 2103848 for more specific information and constraints).
Fujitsu Physical Partitioning
- Fujitsu physical partitioning with PRIMEQUEST 2400 E/L and PRIMEQUEST 2800 E/L for production and non-production use cases. (See SAP Note 2111714 for more specific information and constraints).
- Lenovo FlexNode partitions in the context of Lenovo x3950 X6 servers for production and non-production use cases. (See SAP Note 2232700 for more specific information and constraints).
2.1.6 Deployment Options Compared
Table 2.1 compares the different deployment options together with their advantages and disadvantages.
Table 2.1: Comparison—SAP HANA deployment options
To summarize, the following deployment options exist:
The single application option
There are no limitations with the standard option, but since hardware is not shared it is the most expensive option.
Multitenant database containers
Multitenant database containers allow a combination of multiple databases on the same hardware with few limitations. The most important being the shared SAP HANA software release.
SAP considers the multitenant database containers the standard deployment option for SAP HANA.
Multiple applications in one SAP HANA system
Multiple Components in One SAP HANA system (MCOD) is an older alternative for operating multiple production systems on the same hardware. MCOD should not be considered. The showstopper is backup and recovery. Backup and recovery is currently supported only at the SAP HANA database level and not at the database schema level. This means that a point-in-time recovery for the SAP HANA system will impact all applications residing on that SAP HANA system. This is unacceptable from a disaster recovery perspective.
Multiple applications on one HANA system
Multiple Components on one System (MCOS) is an option to have different SAP HANA systems on the same hardware. It is useful when hardware is used by multiple independent systems. An often-seen layout is an MCOS system in which the disaster recovery production is installed on the same system as the acceptance or development system.
SAP HANA with Virtualization
Virtualization provides good control of physical resources and is, therefore, quite flexible. In our opinion, virtualization only makes sense when shared storage is available. As such, it should be considered in combination with the SAP HANA Tailored Datacenter Integration (TDI) installation option.
Different deployment options can be combined. A layout often used is the Multitenant Database Containers (MDC) combined with Several Databases on One System (MCOS) option. An MDC is set up for the production SAP HANA databases on one SAP HANA appliance and several MDC SAP HANA systems are set up for the non-production SAP HANA databases on another SAP HANA appliance (for example, one MDC for development and another for acceptance). As such, the SAP HANA appliance for the non-production systems is actually Several Databases on One System (MCOS).
2.1.7 Multitenant Database Containers versus Virtualization
A Multitenant Database Container (MDC) SAP HANA system combines multiple databases in a single SAP HANA instance. These databases are referred to as multitenant database containers. Apart from sharing the same instance, they are completely isolated from one another. MDC is therefore often considered a sort of virtualization.
There are however some crucial differences:
- TCO is lower than with virtualization as there is a single software stack. There is no need for a virtualization or additional operating system license.
<li>All databases share the same instance. An upgrade of the SAP HANA revision impacts all tenants. This is not the case with virtualization because every SAP HANA system is isolated on a dedicated virtual machine.</li> <li>MDC has a performance advantage over standard virtualization as there is no overhead of the Hypervisor.</li>
Table 2.2 compares the differences between MDC and virtualization.
Table 2.2: MDC versus virtualization