Illustrating Deployment Options

SAP HANA can be deployed in on-premises, in the cloud, or even as a hybrid deployment where on-premises and cloud are combined. Which option is chosen depends on the customer's requirements. A new customer might start with a 100% cloud strategy in mind, whereas a longtime SAP customer over time wants to move to cloud solutions.

With SAP HANA deployment options, you can distinguish between a preconfigured on-premise appliance, SAP HANA tailored data center integration (TDI) deployments, an SAP HANA Cloud deployment, or a hybrid deployment model that combines cloud and on-premise instances.

The technical deployment options determine how SAP HANA systems, the hosts used for SAP HANA systems, and applications running on SAP HANA are deployed.

To run multiple scenarios on one system or database, you need to understand the availability and capabilities of the technical deployment options.

SAP HANA multi-tenant database containers establish a foundation for providing multi-tenancy in SAP HANA.

As of SAP HANA 2.0 SPS01, an SAP HANA system is installed in multiple-container mode. It can contain more than one multi-tenant database container.

A multiple-container system always has exactly one system database, which is used for central system administration. It also has any number of multi-tenant database containers (including zero), called tenant databases. An SAP HANA system installed in multiple-container mode is identified by a single system ID (SID). Databases are identified by a SID and a database name. From the 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 cockpit, connect to specific 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. However, each database is self-contained and fully isolated with its own, as follows:

• Set of database users

• Database catalog

• Repository

• Persistence

• Backups

• Traces and logs

Although database objects such as schemas, tables, views, procedures, and so on, are local to the database, cross-database SELECT queries are possible. This supports cross-application reporting, for example.

SAP HANA multi-tenant database containers allow you to manage several databases in one database management system. Note that a single database container is also called a tenant database.

A single application on one SAP HANA system is also known as Single Component on One System (SCOS).

To more readily describe the various other options for technical deployment, it is useful to first illustrate the simple, straightforward approach to deploy an application on an SAP HANA system. This will be useful for comparison purposes.

In this configuration, a single application runs in a single schema, in a single SAP HANA database as part of an SAP HANA system. This is a simple, straightforward scenario that is supported for all use cases without restriction.

Multiple applications on one SAP HANA system are also known as Multiple Components on One Database (MCOD).

The technical deployment type MCOD refers to the scenario where more than one application, scenario, or component runs on one SAP HANA system. This deployment type is available with restrictions for production SAP HANA systems. For production systems, there are allow lists that specify supported scenarios explicitly.

Multiple SAP HANA systems on one host are also known as Multiple Components on One System (MCOS).

SAP does support running multiple SAP HANA systems (SIDs) on a single production SAP HANA host. This is restricted to single-host or scale-up scenarios only. Multiple components on one system requires significant attention to various detailed tasks related to system administration and performance management.

Production support is restricted to SAP HANA SPS 09 or higher because of the availability of some resource management parameters (for example, affinity). Running multi-SID on one SAP HANA host can impact the performance of various types of operations, because competition for computing resources might occur (memory, CPU, I/O, and so on).

Perform the requisite testing in every project before going live. In general, stress or volume testing provides good indicators of the expected performance. When operating a system that features a multi-SID deployment, use the resource management features of SAP HANA (for example, parameters controlling memory limits, and influencing utilization of CPU cores, and so on) to optimize performance.

SAP HANA supports many popular virtualization hypervisors, such as:

• VMware vSphere (SAP Note 2652670 - SAP HANA VM on VMware vSphere)
• Hitachi LPAR (SAP Note 2063057 - SAP HANA on Hitachi LPAR logical partitions in production)
• Huawei FusionSphere (SAP Note 2659955 - SAP HANA on Fusionsphere KVM)
• IBM PowerVM (SAP 2947579 - SAP HANA on IBM Power Virtual Servers)
• SUSE Linux Enterprise hypervisors (SAP Note 3430656 - SAP HANA on SUSE KVM Virtualization)
• Red Hat Virtualization KVM (SAP Note 2599726 - SAP HANA on Red Hat Virtualization)
• Nutanix Acropolis Hypervisor (SAP Note 2686722 - SAP HANA virtualized on Nutanix AOS)

You can choose virtualization for a wide variety of configurations, for single and multiple virtual machines, in single- or multi-node configurations, for appliances of SAP HANA and SAP HANA tailored data center integration delivery methods.

The technical deployment type, SAP HANA with virtualization, refers to the scenario where one or more SAP HANA database SIDs are deployed on one or more virtual machines running on SAP HANA server hardware.

One benefit of virtualization is that you can assign dedicated CPU and memory resources to specific databases and increase the flexibility of hardware usage.

For customers already standardizing on virtualization technology, SAP HANA offers the customer total cost of ownership reductions and additional options for planning and managing their systems landscapes, as follows:

• Ease of hardware replacement and avoidance of recertification of OS and SAP installations

• Separation of IT ownership (hardware and software layer)

• OS-independent monitoring

• Low-cost High Availability (HA) capabilities in development and test environments

• Positive impact on capital expenditures