How to get your HANA sizing done right?

Digital Maps Oct 17, 2022

Overview of SAP HANA

SAP HANA (High Performance Analytic Appliance) is a comprehensive business data platform which brings about significant business and IT benefits to companies of all sizes through in-memory computing and real-time data analytics. It is a combination of software and hardware innovation and is designed to provide real-time analytics and transactional processing at lightening speeds. The in-memory technique allows processing in the memory itself and the disk exists only for the purpose of persistency.

SAP has leveraged more than 40 years of business and technology experience to create SAP HANA, the business data platform for an intelligent enterprise. SAP HANA consists of a set of in-memory processing engines. Calculation engine is the main in-memory processing engine in SAP HANA.

It works with other processing engines like Relational Database Engine (Row and Column engine), OLAP Engine, etc. It can help any business unleash the power of all its data and leverage real-time intelligence from its business processes.

Key benefits of SAP HANA
Why should you size your SAP HANA?
Understanding HANA sizing
Sizing Approach
KTern’s HANA sizing approach during SAP S/4HANA Migration

Key benefits of SAP HANA

Analytics

SAP HANA has been designed to run analytics on live transactions.
The SAP HANA does not only run operational analytics on structured data (such as business transactions), but also includes advanced analytics processing (such as predictive, machine learning, or natural language processing) on structured and unstructured data (such as graph and spatial data, files, and live data streams).

Real Time Data

SAP HANA has all the capabilities that an organization needs to process any data – from transactions to advanced analytics – whether stored locally or virtually.
And because it has been designed to manage data in-memory first, allowing businesses to act with live intelligence from all its data.
It can also be used for OLAP (On Line Analytic) and OLTP (On Line Transaction) on a single database. This, combined with having everything you need on one platform, accelerates access to data and insights while also providing a simplified IT landscape.

Security and Business Benefits

SAP HANA takes data security and privacy protection to the next level to preserve customer’s trust, while also enabling them to get full value from their data assets.
Since its launch in 2011, companies using SAP HANA have seen significant business and IT benefits. Analysts from IDC have shown how SAP HANA is helping customers reimagine their business operations. Potentially offering a five-year ROI of 575% and saving millions on costs, SAP HANA helps enterprises grow new businesses and revenue opportunities.

However, to take full advantage of the power of SAP HANA for SAP and non-SAP applications and to reduce the total cost of ownership, it is critical that the platform be properly sized for the required business needs. SAP provides the tools to correctly size SAP HANA and build a strong foundation for your digital transformation success.

Why should you size your SAP HANA?

It is vital to size an SAP HANA hardware correctly to realize the maximum benefit from an investment and reduce the long-term total cost of ownership. Over-provisioned sizing of SAP HANA can lead to excess capacity and bloated hardware while under-provisioning can cause unexpected delays which will increase the cost of operational performance.

For the most part, sizing of SAP HANA database is based on the main memory, which in turn is determined by the amount of actual data stored in memory. Since the data is compressed in HANA and the compression results depends on the used scenario, it is not easy to guess the amount of memory needed for sure. Therefore, the memory sizing for SAP HANA should be performed using SAP’s Quick Sizer tool, relevant SAP notes and SAP sizing reports.

When we talk about right sizing, it means the right amount of memory and the right CPU processing power which needs to be calculated.

Sizing means determining hardware requirements such as memory, CPU power, disk space, input and output capacity, and network bandwidth. It is an iterative process aimed at translating business requirements into hardware requirements and is usually done early in a project.

Understanding HANA sizing

The primary and most obvious reason why sizing matters for all IT installations, and not just for SAP HANA, is cost. If money were no factor, every organization would be happy to run an oversized capacity to deliver the best possible performance with any type of workload. This is, however, unrealistic.

SAP defines “sizing” as determining the right hardware configuration to meet current and future business requirements. It is an iterative process that involves a three-party collaboration between the customer, SAP, and the hardware vendors.

It is all about establishing, in a hardware and vendor-neutral way, the amount and types of components needed to meet the targeted output and response time of a given workload, as well as the level of effort each equipment type including memory, processors, disks, and so on– must deliver at a certain level of performance.

Effort can be calculated in terms of power, capacity, frequency, or other parameters often encountered with hardware. But what matters most, is the capacity of each component to make the required resources available for the next level of calculation chain as and when they are required.

The goal of any properly designed system is to eliminate any waiting period or idle processing time. This is called response-time optimization

Sizing Approach

The sizing approach at SAP assumes and considers a fair mix of best, normal, and worst-case scenarios for a certain workload. Out of this process, certain throughput metrics are defined, such as CPU power in SAP Application Performance Standard (SAPS) values, memory size, and Input & Output operations per second. Sizing results will likely change with any change in workload, which is why sizing must always be an iterative process.

Configuration is the second step in defining the system architecture and it consists of translating the sizing results to determine the best vendor-specific equipment. This involves deciding on a hardware vendor and evaluating their fit within the existing enterprise architectures. Machine models and specifications for all necessary hardware elements from a selected vendor are defined, including integrations with external components from other vendors, to determine the best fit for the complete system. This is the step where the ongoing costs of the purchase can be evaluated and changes in business requirements can be anticipated. For many customers, existing deployed hardware such as enterprise storage or networking systems can also be leveraged, assuming they meet the configuration requirements.

Selecting a configuration where the sizing characteristic of the moment matches the top of the performance range will leave enough room for subsequent iterative sizing changes without forcing a premature hardware replacement. Although this has a direct negative impact on total cost of ownership in the short term, it may be the right decision for the long term, as there will be enough capacity for future increases in workload.

KTern’s HANA sizing approach during SAP S/4HANA Migration

SAP S/4HANA runs only on the HANA database. Hence, it is essential to switch from whatever database you are using to SAP HANA before moving to the all-in-one business suite SAP S/4HANA.

The most important factor which makes an SAP HANA migration challenging is how HANA organizes the data within itself. The HANA database is columnar based, whereas the traditional RDBMS is row-based. The columnar database loads only the relevant columns making it faster than the traditional database. And, SAP HANA shrinks the data footprint, but requires high CPU and memory.

KTern checks, estimates and provides HANA sizing recommendations during the Discover phase of SAP S/4HANA system conversion process. Several datapoints suggest that after moving to SAP S/4HANA, the database size reduces by 40 - 50%, provided all the archiving is done. However, that’s not only entirely true. What happens during the conversion process is, the database size increases by about 1.5x and then reduces.

For example, if the original database size is 1 TB, then it increases to about 1.5 GB during the conversion process and after that only the size reduces to about 600 - 650 GB. Most organizations do not take this fact into account and buy a much lower size of the HANA box. This in turn will not be enough during the conversion process and may lead to unwanted complications.

Hence, KTern recommends a relatively higher size of the HANA box during the Discover phase itself. Also, another advantage of this methodology is that when the data footprint inevitably increases after 2 to 3 years, the HANA database will be equipped to handle that data as well.

Curious to learn more about KTern and SAP S/4HANA Conversion? Go through our articles and on-demand webinars at your convenience. To learn even more, do schedule your direct 60 minute session on KTern along with a demo of the product at Getting Started.