SAP HANA multitenant database containers

Symptom:

SAP HANA multitenant database containers

Solution:

This note is a collection of information about SAP HANA multitenant database containers. It links to further materials.

Introduction:

The feature "SAP HANA multitenant database containers" (or, "MDC") was first introduced starting with SPS09. The concept is based on a single SAP HANA system or database management system (DBMS), with a single system id (SID), which contains at least one tenant database, in addition to a system database. The system database keeps the system-wide landscape information and provides configuration and monitoring system-wide. Users of one tenant database cannot connect to other tenant databases and neither access application data there (unless the system is enabled for cross-database access). The tenant databases are, by default, isolated from each other in regards to application data and user management. Each tenant database can be backed up and recovered independently from one another. Since all tenant database is part of the same SAP HANA DBMS, they all run with the same SAP HANA version (revision number).  In addition, in regards to HA/DR, the defined HA/DR scenario applies to all tenant database.

Focus:

On-Premise Scenarios:
Alternative to MCOS deployments (Multiple components one system), install MDC instead of MCOS to where it fits
Featuring several tenant databases
Address common MCOD scenarios (e.g. ERP-CRM-BW, QA/DEV, Data Marts)
Cloud Scenarios (SAP internal):
SAP HANA Cloud Platform
SAP HANA Enterprise Cloud
Positioning:

Reduces TCO
Enables tenant operation on database level
Offers integrated administration, monitoring, resource management, strong isolation
Offers optimized cross-database operation within the system (read access)
Supports flexible landscape management, cloud scenarios, on-premise scenarios
Combining Applications, Scenarios:

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, particularly if the application functionality in use is the same as when running on a single database SAP HANA system. However, for statements about a specific application’s support for special features of MDC, such as cross-tenant query functionality, and for general statements about a specific SAP application’s support for SAP HANA MDC, please consult application-specific information regarding viable deployment options.

Note: Some other SAP notes discuss restrictions when combining applications on SAP HANA on a single database (known as MCOD Multiple Components One Database), such as note 1661202 (whitelist of applications/scenarios) and 1826100 (whitelist 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.

SAP note 1681092 discusses support for more than one SAP HANA DBMS on a single hardware unit, (otherwise known as MCOS, Multiple Components One System).  With MDC, we aim to meet most customer requirements that would lead to consider MCOS, perhaps except cases which require more than one SAP HANA version on the same hardware installation, which is most likely to occur in a non-production system.

Sizing and Implementation Approach (Recommendation):

A pragmatic approach for sizing MDC systems is required. The general recommendation is to perform a sizing exercise for each application or use case and then utilize an additive sizing approach.  When considering BW, Suite-on-HANA, for example, consult notes 1774566, 1825774, 2121768 can be found attached to this note). In the current timeframe, Suite-on-HANA must be deployed on a single node in an MDC System. In determining applications to deploy, a step-by-step approach makes sense. First, install a few applications in different tenants, and proactively monitor resource utilization and performance; based on observations, make determinations about possible additional deployments of applications on other tenant databases in the same system. Implementation considerations: as MDC is a relatively new technology, a conservative approach to implementation is warranted.  A significant amount of stress/volume testing on a project basis is recommended.

Additive sizing: Perform a sizing estimation for each tenant database, utilizing known sizing approaches (e.g. quick sizer, POC, working with a hardware partner, etc) as if it were a single database.  Next, add the individual sizing estimates together and avoid underestimating. In addition to CPU and memory sizing aspects, the I/O throughput aspect should be taken into account. One option to address this is to utilize the SAP HANA HW Configuration Check Tool, to measure if the used storage is able to deliver the required I/O capacity. SAP Note 1943937 has more details.

Architecturally, each tenant database has its own index server, and upon initial deployment, consumes approximately 8 GB (before any application data is added). This means that the actual number of tenant databases that can be deployed is limited by available resources; in other words, a large number of very small tenant databases is not possible given the current MDC architecture.

Separation and Security recommendation

Multitenant database containers are suggested to be used in a trusted environment. It is not recommended, especially with SPS09 to run a hosted environment with several databases from different domains, singular and separate data sources, or customers together in one multitenant container system. With SPS10, an option was added to increase the isolation level between tenant databases. If requirements dictate to run tenant databases with different customers, or strict separation of data, SPS10 or higher is recommended.


Migration towards an 'SAP HANA multitenant database containers' system

SAP HANA single database system can be migrated to a multi-tenant database system. This step is irrevocable. The single database is the SAP HANA default configuration, MDC is optional. Upgrading to a higher support package will not change the system mode. If a migration is explicitly launched, the single database will be converted into a tenant database.
During this process, the system database, responsible for the system topology, will be generated. There will be no changes to application/customer data. Additional tenant databases can be added to the system afterward.

Copying databases into tenant databases: 

With HANA 1.0, it is not supported to take a backup of the single database system, and then restore it into a tenant database of an MDC system. Only a backup from an MDC system can be utilized to copy into a tenant of another MDC system.  Here is an example approach that would accomplish this objective:

A sample pattern to move a single database into an MDC tenant would be:

perform a system copy of a single database system to create another system
update this copied system to a revision enabled for MDC (SPS09 rev95 or higher)
migrate this copy to an MDC system. This will result in a system database and one tenant database
take a backup from this tenant database
set up your target tenant database, by creating a new tenant database in a new or an already existing MDC system
restore the tenant backup (from 3.) into this new tenant
Starting with HANA 2.0, a single database backup can be restored directly into a tenant database. Step 4 of the list above would then be the starting point: Take a backup from the database. Step 1-3 become obsolete.

License Management

Starting with HANA 2.0 SPS02 license keys can be installed in individual tenant databases. For more information about the licensing handling in MDC systems, see 'License Keys for the SAP HANA Database' in the 'SAP HANA Administration Guide' or 'SAP HANA Tenant Databases'.

Administration and monitoring tools

Several tools are available for the administration of SAP HANA. While all tools support database-level administration (which is comparable to the administration of a single-container system), system-level administration of tenant databases requires the SAP HANA cockpit. With SPS10 a new catalog for the system database is available in the SAP HANA Cockpit to monitor overall system health and manage all tenant databases. The SAP HANA studio is required for system configuration tasks. For more information about the SAP HANA cockpit and other administration tools, see SAP HANA Administration tools in the SAP HANA Administration Guide.

Starting with HANA 2.0 there will start a transition regarding tooling. Please see note 2396214.

Backup and Recovery

The focus of the SAP HANA B&R concept for MDC is on backing up and restoring the individual tenant databases, including the system database. So, in the end, there will be a set of tenant backups and the system database backup that can be restored individually or be used all together to restore a complete MDC system from scratch:

install MDC software/system, and the system database will implicitly be created
start recovery of system database. Afterwards, the system database tracks all tenants
there have not to be additional create database requests
start recovery tenant by tenant
Using Backing

Using 'Backint' with external backup tools for recovering MDC systems/tenants requires SPS09 revision 94 or higher. This fix will allow using Backint for backing up and recovering exactly the same tenant of an MDC system. It may not be used for restoring it into another tenant in the same or in another MDC system (tenant copy).

As of SAP HANA, 2.0 SPS01 Backint-based backups of a tenant database ca be recovered into a tenant database using a target SID or tenant NAME that is different to the original one. Likewise, Backing-based backups of a single container system can be recovered into a tenant database using a target SID that is different to the original one.

Moving and copying tenant databases

Tenant databases can be moved or copied using the backup and restore capabilities. This needs downtime only 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 then restore the backup into this tenant database. Or, restore the copy into an existing tenant database.

With SPS12 a new path for copying and moving tenant databases have been introduced. It utilizes the algorithms of system replication to enable a near zero downtime copy/move for the tenant database, within an MDC system or between MDC systems. This feature is available from the command line interface only yet. NOTE: For the time being this copy/move cannot be used if an HA/DR system replication is active. This is addressed in future planning.

The standard copy/move process of tenant databases requires an initial certificate configuration in order to enable communication between systems.

Inside an MDC system, in non-production set-up or isolated environment, it may be reasonable to allow to proceed without the need for trusted communication. Starting with HANA 2.0 the internal communication of the copy/move processes may now also run unencrypted.

Cross-Database Access

Inside the same SAP HANA system, read-only queries between tenant databases are possible. Database objects like tables and views from one tenant database can be read by users from other tenant databases. By default cross-database access between tenants is inactive. It must be explicitly enabled and a user mapping is needed in the remote tenant database (more information is available the SAP HANA Administration Guide and notes 2196359). As cross-database-access at certain points has restrictions please refer to the documentation for further guidance.

High availability/Disaster recovery

The SAP HANA HA/DR solution chosen applies to the whole SAP HANA instance, thus for all tenant databases including the system database. The HA/DR solution SAP HANA system replication – works with an "all or nothing" approach – all tenant databases are subject to failover to another data center. Newly created tenant databases are integrated into the replication process automatically after they were backed up. The HA/DR solution SAP HANA storage replication is agnostic about the instance content, thus requires no special actions regarding tenant databases.

Load management

When implementing MDC, attention details for workload management is required. The help documentation, in particular, the MDC operations guide, discusses this topic.  Thus, in order to divide up system resources, parameters such as allocation limit and max_concurrency should be set when tenant databases share the same host.

Current restrictions / Not supported (i.e. not working with MDC) in SPS12 and further notice

SAP HANA Smart Data Streaming can be installed on an SAP HANA system that has been configured for multi-tenant database containers only starting with SPS12. Refer to SDS material for further info

SAP HANA Dynamic Tiering is not recommended to be used in production within MDC systems up to SPS12. SAP HANA dynamic tiering only supports low tenant isolation. Each tenant database is associated with a maximum of one dynamic tiering worker/standby pair. Conversely, the same dynamic tiering worker/standby pair cannot be associated with multiple databases. Refer to DT material for further info.

For the time being copy/move tenant database cannot be used if HA/DR system replication is active. This is addressed in future planning. In that case please use backup/recovery for copy/move purpose instead.

Backup and recovery using snapshots is not yet available for MDC.

SAP HANA Application Lifecycle Management support for tenant databases begins with revision 96, see note 2073243.

FullSystemInfoDump is not working on tenants, only from the system database for all tenants.


More details refer Snote: 2096000