2408419 - SAP S2408419 - SAP S/4HANA - Multi-Node Support/4HANA - Multi-Node Support

Symptom

SAP S/4HANA - Multi-Node (Scale-Out) Support

Other Terms

SAP S4/HANA onPremise Scale-out

Reason and Prerequisites

We wish to inform you about the SAP HANA scale-out options for S4/HANA on Premise Releases >= 1610 FPS1.

Solution

HANA multi-node configurations are used for different purposes:

a) Scaling memory and CPU (scale-out)
b) High-availability with standby nodes
c) Installing the XS Advanced runtime on a dedicated node

See also the chapter related to "Availability and Scalability" of the SAP HANA Administration Guide available on the SAP Help Portal at https://help.sap.com/viewer/p/SAP_HANA_PLATFORM. We use the following terms to describe different types of nodes in the SAP HANA database system, following the terminology introduced in the SAP HANA Server Installation and Update Guide. This guide is also available from the SAP Help Portal at https://help.sap.com/viewer/p/SAP_HANA_PLATFORM.

• worker: an SAP HANA database node that processes data. In particular, the HANA indexserver is running in "worker" mode on this node.
• standby: an SAP HANA database node does not handle data, but is on standby, waiting to take over processes in case of a worker machine failure.
• xs_worker: an SAP HANA database node on which the processes of XS Advanced are running. 
• xs_standby: an SAP HANA database node on standby, which can take over the processes of the XS advanced component in case of an xs_worker machine failure.

Ad a) Scale-out scenarios with multiple worker nodes to scale memory are generally released for SAP S/4HANA >= Release 1610 FPS1 in combination HANA 2 >= SPS 00 with following restrictions:

Hardware configuration:

We recommend using scale-up configurations as long as this is economically justifiable, taking project efforts and operational costs into account. 
If several scale-out configurations are possible, those that use fewer nodes should be chosen.

Hardware restrictions:

In the following we list restrictions that apply to the hardware supported for S/4HANA scale-out deployments. These restrictions apply for any SAP S/4HANA deployment, unless you are deploying an industry solution or add-on that defines specific hardware restrictions (see below).

Supported hardware types:

SAP S/4HANA scale-out is only supported on nodes with minimum sizes:
- Intel hardware: >= 8 CPUs per node and >= 6 TB RAM per node
- IBM Power: >=64 cores per LPAR and >= 6 TB RAM per LPAR

Generally, all hardware must be listed in the SAP HANA Hardware directory https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/index.html.

Within the hardware directory, supported hardware can be found as follows:

Intel based appliances:
- Listing of "Certified Appliances"
- "Appliance Type” = “Scale-out: S4H"
- For S/4HANA scale-out, one may use either fully certified appliances, or systems complying with the rules of HANA tailored data center integration, as long as they are based on systems certified for type "Scale-out: S4H"
- All nodes must have identical memory size. It is recommended to use identical CPU generations in all nodes, see also the attachment "SAP HANA in Data Center" of SAP Knowledge Base Article 2407186 (slide "SAP HANA Scale-Out Extension"). 

IBM Power based
- Listing of Supported Power? Systems
- >= 64 cores per LPAR with >= 6 TB Memory per LPAR
- LPAR configuration according to SAP Note 2188482 - SAP HANA on IBM Power Systems: Allowed hardware 
- all LPARs must have identical configuration on identical hardware type

IaaS Platforms
- Listing of Certified IaaS Platforms of the hardware directory
- Application Type "OLTP"
- Clustering ="yes"
- System must be explicitly released for OLTP-workload in scale-out (check details of a given system in the hardware directory)

Cluster size:

The maximum cluster size is limited to 4 worker nodes. One or several standby nodes may be used for HA purposes.

It must be noted that in a given system a reasonable balancing of CPU and memory load on the workers may only be possible with a smaller number of worker nodes. This is due to the way data (and with data also workload) is distributed to the nodes of a scale-out cluster in S/4HANA systems. The reasonable number of worker nodes therefore must be determined individually for each system and may vary between one and four.

Note of advice: When planning a high-availability solution, always consider your SLAs regarding system availability, allowed downtimes, recovery point and time objective (RPO / RTO), etc. and match them against the technical capabilities of the different availability options which include but are not limited to SAP HANA standby nodes,  SAP HANA system replication, storage replication, or database backup and recovery.

Further hardware requirements:

Regarding storage and network specifications, the rules for SAP HANA scale-out configurations as known to the hardware partners apply.

Considerations for operating multiple applications on same database or same hardware

The best practices, recommendations and restrictions as listed for "Multiple Components on One Database (MCOD) - SAP Note 1661202" and "Multiple SAP HANA databases on the same physical server (MCOS) - SAP Note 1681092" apply.

Data distribution within the scale-out cluster:

Groups of tables are defined according to semantically-related tables. All tables in a group including all table partitions must reside on the same node. SAP defines a standard grouping of tables (see attachment TABLE_GROUP_SQLSCRIPT.txt). It is strongly recommended to use these groups as basis for table grouping in a given customer system. Typically, a group corresponds to the transactional tables of an application. For example, the large transactional tables related to managing financial documents (ACDOCA, BSEG, etc.) form one group. Consequently, all tables of a certain application will jointly reside on one node.

The S/4HANA Sizing Report SAP Note 1872170 and SAP S/4HANA Scale-Out Sizing Note 2428711 estimates the minimum required node size for your system based on the predefined table groups.

It may be necessary to define additional table groups or add customer-specific processes and extensions to existing table groups. Defining additional table groups or adding customer-specific table groups can change the minimum required node size (SAP Note 2447004 - Table Grouping Report for SAP S/4HANA in Scale-Out Systems).

A small number of master data and configuration data tables will have join relationships with multiple table groups, so that it will be beneficial to have local copies of these tables on all nodes of the scale-out cluster. In order to achieve this, the SAP HANA feature of synchronous table replication (OSTR) can be used. A starting set of tables to be replicated is included in attachment TABLE_GROUP_SQLSCRIPT.txt. Further tables may be replicated as required. The table grouping report of SAP Note 2447004 can recommend additional tables for replication.

The process for optimizing the data distribution in scale-out systems and further background information about the data distribution strategy is described in the documentation attached to this note.

In SAP S/4HANA systems with the activated feature "Production Planning and Detailed Scheduling (PP/DS)", liveCache functionality will be used (further details see https://uacp.hana.ondemand.com/http.svc/rc/PRODUCTION/f431c95360267614e10000000a174cb4/1610%20000/en-US/frameset.htm as well as KBA 2420674 and SAP Note 2382787). In a scale out landscape, liveCache data stays on the master index server. This will be automatically ensured by the installation procedure and the table placement rules. We also recommend leaving all related tables in the namespace /SAPAPO/ on the master index server.

Role of the master indexserver in SAP S/4HANA scale-out:

In SAP HANA scale-out systems, data resides on nodes of type "worker". Within the HANA database, there is always one worker named "master" which has a special role within the database. From the point of view of SAP S/4HANA data distribution, the master is special in that all tables that are not explicitly grouped will be placed on the master. Apart from this, the master is used as a regular worker node, including the placement of table groups. Thus in a typical scale-out system, the master will contain all ungrouped data as well as a few table groups; all other workers will only contain tables from table groups and tables replicated via synchronous table replication.

Conversion SAP Business Suite to SAP S/4HANA scale-out:

To optimize and verify the data distribution in the S/4 scale out system it is highly recommended to execute realistic load tests of the core business processes. This process requires a test landscape that is configured as a production landscape for testing.

If not properly tested there is a risk of a mismatch of data distribution and system workload that can lead to significant performance impact. In such a case, it is possible that code needs to be adjusted or tables need to be redistributed shortly after going live. A business downtime may be needed in order to solve the situation.

Continuous optimization of the scale-out Cluster:

Several situations can require a change of the data distribution, e.g. changed usage of the system, data growth, ... . Please be aware that redistributions of data within the scale-out cluster typically requires a business downtime.

Managing, configuring and optimizing a scale-out configuration has certain costs and drawbacks. Customers should also consider the option of using a scale-up configuration.

Limited knowledge about S/4HANA customer scenarios using scale-out is currently available. For questions and support please get in touch with us by creating a ticket on the component XX-SER-REL.

Solutions with specific support for HANA scale-out

The following applications have implemented specific means to operate on SAP HANA scale-out infrastructure and may therefore allow using SAP HANA scale-out in a way that deviates from the above rules in one or several aspects:

• SAP S/4HANA Utilities, see SAP Note 2446942
• SAP S/4HANA for Financial Products Subledger, see SAP Note 2637010

Ad b) Simple high availability scenario (host auto-failover) with two servers (one worker and one standby-node)

This scenario is released for SAP S/4HANA.

Note of advice: When planning a high-availability solution, always consider your SLAs regarding system availability, allowed downtimes, recovery point and time objective (RPO / RTO), etc. and match them against the technical capabilities of the different availability options which include but are not limited to SAP HANA standby nodes,  SAP HANA system replication, storage replication, or database backup and recovery.

Ad c) Operating the XS Advanced runtime on a dedicated SAP HANA node.

The SAP HANA XS Advanced runtimes can be installed on a dedicated node of the SAP HANA database. We define a node as dedicated to XS Advanced if the node only has node type "xs_worker", but not any other HANA node type. Such a dedicated XS Advanced worker node is then used only for running the processes related to XS Advanced, not for core HANA database services such as the indexserver. An SAP HANA system with exactly one "worker" node and one or several dedicated XS Advanced worker nodes, and optionally standby and/or xs_standby nodes, is released for the Suite on HANA. Please note that this is purely a technical statement. Not all SAP HANA licenses allow installation or use of SAP HANA XS Advanced. Please contact your SAP account representative if you have questions related to permitted system usage.