SAP HANA - Implementation Guide

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>

Further considerations:

• 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

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

• 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 PowerVM

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.

Huawei FusionSphere

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.

Hardware Virtualization

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

• 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