Servers: The Right Compute
Showing results for 
Search instead for 
Did you mean: 

Scale Up or Out with SAP S/4HANA? Think Speed of Transactions.



Understand the differences between scale-up configurations and scale-out configurations with SAP S/4HANA. Learn which you should do first and why.

HPE SAP HANA_scale up_blog.jpgDid you know that SAP has added “Scale-out: S4H” as an appliance type to the SAP Certified and Supported Hardware Directory?

Until recently, only “scale-up” appliances were certified to run SAP’s next generation business suite, SAP S/4HANA, on the SAP HANA platform. Recall that scale-out equates to a clustered multi-node system, whereas scale-up equates to a single-node system.  

So which system type is best for S/4HANA? That hasn’t changed. As SAP advises, scale up first.  

Before explaining why, the addition of Scale-out:S4H to the hardware directory is eventful nonetheless, as from my perspective, it reflects a new level of maturity for SAP HANA.  No update was made to SAP S/4HANA to support scale-out systems.  But you can choose to run conventional enterprise databases in a multi-node cluster and, while SAP HANA is much more than a database, SAP ultimately wants to offer the same flexibility.

Giving you more choice in deployment for S/4HANA is not without clear guidance from SAP to scale up first. 

As SAP Note 2408419 - SAP S/4HANA - Multi-Node states, “We recommend using scale-up configurations as long as this is economically justifiable, taking operational costs and drawbacks into account.” 

SAP further clarifies by stating, “Managing, configuring and optimizing a scale-out configuration has certain costs and drawbacks.”  SAP emphasize all tables in a group must reside on the same node and flags customers to “a significant performance impact due to suboptimal data distribution” resulting from data growth, changed usage, and other situations, and to the downtime needed for redistribution. The note also “strongly advises” limiting to a single tenant database and one SAP application. 

Why scale up first

To understand why scale up first with S/4HANA, let’s take a simplified look at a single system with Intel Xeon processors running SAP HANA (pictured below).  

HPE SAP HANA_scale up_image1.JPG

Within the system, you have processors and memory tightly interconnected over ultra high-speed links. Here latency is measured in nanoseconds. You have one operating system.  You have cache-coherency — when multiple operations read the same record such as a customer address, multiple copies will reside in processor caches. If one operation changes the record, all copies must be updated (and without delay) or errors can occur.  And you have attached persistent storage.

But if the HANA database exceeds the size of the system, you can deploy a cluster.

HPE SAP HANA_scale up_image2.JPG

                                                                           Scale out:   SAP BW/4HANA >4TBs

Here you have “nodes” (individual servers) to include a standby node(s) if a worker node fails, that are connected via a switched network. Each node has its own operating system and cache-coherency is limited to the node level. Persistent storage is delivered via a clustered file system in a SAN.

While this clustered architecture enables scaling out the HANA database, it also introduces two elements that can impact performance, specifically node-to-node traffic and network switch latency measured in microseconds. 

Clustered systems are conducive to running and scaling out your data warehouse using SAP Business Warehouse (BW) on HANA or new SAP BW/4HANA.  BW is optimized to run on clusters and can tolerate cluster latency. SAP also currently requires running BW on HANA in a cluster if the database is greater than 4TBs. 

Avoid adding latency that can slow transactions

If you wish to leverage the breakthrough capabilities of SAP S/4HANA and run transactional and analytic workloads on the same database to achieve “real-time analytics,” you can’t introduce latency that slows transactions.

You will indeed hear from business lines if you do. This is why such guidance from SAP to use a single system, and ideally, a system that can scale up by adding processors and memory as your data environment grows.

                       Scale up:   SAP S/4HANA    Advanced Analytics      SAP BW/4HANA <4TB                                      

Now you can run S/4HANA applications without worrying about table distribution and node containment, disruptive table redistribution due to growth or usage changes, and most importantly, transactions slowing. You can also perform advanced analytics than can tax clusters with high node-to-node traffic  and lock up applications, from highly complex joins to multi-engine analytics (e.g., text and geospatial). A single, scale-up system can also be ideal to run BW if under 4TB, as it’s just simpler.

We too, however, do support S/4HANA on HPE scale-out systems to give you a choice – but also with clear guidance. 

As Hasso Plattner states in his book, The In-Memory Revolution, “As long as we stay on a one-node server (chassis, board, blade), we can enjoy fast memory access for all cores of all CPUs. We really should avoid going beyond this setup on one chassis and use multiple nodes for the actual data only when absolutely necessary.” 

Sound advice.

0 Kudos
About the Author


Jeff is a 25-year technology industry veteran with experience in hardware and software engineering, customer sales and support, business planning. product management and marketing, including the last 15 years with HP and HPE. Jeff leads the hardware and software product planning and management teams for HPE Servers focused on delivering the Mission Critical Solutions portfolio.

June 18 - 20
Las Vegas, NV
HPE Discover 2019 Las Vegas
Learn about all things Discover 2019 in  Las Vegas, Nevada, June 18-20, 2019
Read more
Read for dates
HPE at 2019 Technology Events
Learn about the technology events where Hewlett Packard Enterprise will have a presence in 2019.
Read more
View all