GRC
HR
SCM
CRM
BI


Article

 

Sizing Modern SAP HANA Landscapes

How to Plan the Right Hardware Configuration with the SAP HANA Version of Quick Sizer

by Sebastian Schmitt and Dagmar Kirsamer | SAPinsider, Volume 18, Issue 1

January 31, 2017

SAP HANA offers capabilities that are critical for competing in the digital economy, including real-time processing, advanced analytics, and access to insights gleaned from big data and the Internet of Things. To fully benefit from these capabilities in on-premise deployments, you must correctly size the hardware on which the SAP HANA database runs. To help customers with this task, SAP provides an SAP HANA-specific version of its online Quick Sizer tool. This article takes an in-depth look at the SAP HANA version of Quick Sizer and walks through an example of sizing for an on-premise SAP S/4HANA deployment. 

The SAP HANA in-memory computing platform provides organizations with the foundation required to operate successfully in a modern, digital economy. Available on premise or in the cloud, SAP HANA combines a database, application development and deployment services, and real-time data processing and analytics capabilities into a single platform, both simplifying your IT landscape and providing the functionality businesses need to compete, including instant insight gleaned from big data and the Internet of Things.

To fully benefit from SAP HANA in on-premise application deployments, it is critical that you correctly size the hardware on which the SAP HANA database runs — otherwise, you risk poor system performance and end-to-end system response times. Since 1996, SAP has provided the free, online Quick Sizer tool to help businesses — not only customers, but also partners and SAP consulting and support organizations — right-size their hardware landscapes for SAP software deployments. The release of SAP HANA in 2010 brought with it a new set of hardware needs, however, and while sizing teams could use the classic version of Quick Sizer for SAP HANA landscapes, it required some manual calculations using the sizing results.

To meet the need for more comprehensive, SAP HANA-specific sizing support, in September 2014, SAP added an SAP HANA version of Quick Sizer designed to support new, on-premise SAP HANA-based application deployments and, similar to the classic version, updated quarterly to keep pace with changing hardware recommendations. While previous SAPinsider articles introduced the classic version of Quick Sizer and how to use it when sizing for SAP HANA, this article examines how the latest release of the SAP HANA version of Quick Sizer — version 246, due for release in February 2017 — supports SAP HANA-specific sizing. It first examines the critical role of accurate data in sizing, and then walks through an example of sizing for an on-premise SAP S/4HANA deployment.

Accurate Sizing Depends on Accurate Data

As with the classic version of the Quick Sizer tool, the SAP HANA version calculates peak and average loads using a set of key performance indicators (KPIs): memory, CPU (measured in SAPS1), and disk requirements (see the sidebar “KPIs Used by the SAP HANA Version of Quick Sizer”). The KPIs are based on usage information for your application deployment — including information about business processes, user numbers, and data retention times — that you enter in an online questionnaire. The results of these calculations help you pinpoint the hardware requirements for your specific implementation.

KPIs Used By the SAP HANA Version of Quick Sizer

The SAP HANA version of Quick Sizer bases its hardware requirement calculations on a set of key performance indicators (KPIs) that are largely similar to the KPIs measured in the classic version of Quick Sizer:

  • Memory: Memory is the central factor in most SAP HANA sizing decisions and is primarily determined by the data footprint in SAP HANA, where essentially all data — including both master and transactional data — resides in main memory.
  • CPU: To enable optimal response times for analytical applications, SAP HANA requires sufficient CPU headroom, measured in SAPS (SAP Application Performance Standard), to fully support its parallel processing capabilities, which require more capacity than traditional databases.
  • Disk size: SAP HANA requires disk storage space to preserve database information in case of a system shutdown, to store a full image of business data, to preserve the current state of the database and all data entered in the persistence layer, and to support the logging of changes.

While the classic and SAP HANA versions share similar KPIs, the way the KPIs are calculated and their importance differ between versions. For example, CPU is generally the most important KPI when sizing for an application to run on a traditional database, while memory is the most important KPI when sizing for SAP HANA.

Upcoming releases of the SAP HANA version will also include brand-new KPIs, such as a disk input/output KPI. SAP HANA requires adequate input/output performance to support processes such as database startup times, savepoint writing, and delta data merges. Storage systems running with SAP HANA must provide sufficient input/output performance to enable processes to run with acceptable data throughput and storage system latency.


One of the biggest challenges in any sizing project is obtaining accurate usage information for performing the sizing calculations. In large companies, the sizing team usually requests this information from the IT department, which then contacts the user department to collect the data that best describes your company’s business processes. It may also make sense to involve an SAP consultant, who can help you map your business processes to the corresponding SAP applications, understand the scope of the SAP applications, and improve communication by translating customer language into SAP language. Regardless of who is involved, all parties must collaborate efficiently from the start to ensure the accuracy of the usage information — the sizing depends on this data.

Another important component of accurate sizing data is to take an iterative approach to the sizing process itself (see Figure 1). Typically, the usage information is initially based on assumptions about future user behavior and the planned volume of business processes that must execute within a certain period of time. As you collect more usage information, you can refine your sizing input and improve the quality of your sizing output. The more precise your data, the more accurate the sizing result that will guide your hardware configuration.

PDMC figure 1

Figure 1 — Sizing SAP HANA landscapes is an iterative process



As you can see in Figure 1, there are five basic steps to using the SAP HANA version of Quick Sizer to size your hardware for a new, SAP HANA-based application deployment:

  1. Go to the SAP HANA version of Quick Sizer (available at www.sap.com/sizing) and create a Quick Sizer project. Select the type of deployment (SAP S/4HANA or SAP BW/4HANA, for example), and enter your usage information in the online questionnaire for that type of application (see Figure 2).
  2. Click on the Calculate result button, which provides initial hardware sizing results for memory, CPU, and disk based on the parameters entered in the questionnaire.
  3. If necessary, use additional sizing guidelines provided by SAP. Quick Sizer includes sizings only for applications that require significant load and have well-established sizing algorithms. For other applications, including new applications, SAP provides additional sizing documents (available at www.sap.com/sizing) that include a short summary of the required architecture and some simple, assumption-based algorithms based on different sizing categories. These algorithms may eventually be added to Quick Sizer once they are more established.
  4. Once the sizing is complete, you can check for sample hardware configurations in SAP’s Certified and Supported SAP HANA Hardware directory.
  5. You can then work with a trusted hardware vendor to evaluate your sizing calculations and determine the appropriate hardware configuration for your implementation.

PDMC figure 2

Figure 2 — The SAP HANA version of the Quick Sizer tool includes online sizing questionnaires for various types of applications



Let’s now walk through an example of sizing for an SAP S/4HANA deployment with the SAP HANA version of Quick Sizer. Specifically, we’ll look at sizing the SAP Fiori front-end server and back-end server components that are required for SAP S/4HANA deployments.

An SAP S/4HANA Sizing Example

In this example, we are sizing an SAP HANA landscape for a new deployment of the on-premise SAP Fiori front-end server for SAP S/4HANA and the required back-end server.

Since SAP S/4HANA natively incorporates the SAP Fiori user experience, which is browser-based and accesses data in the back end, sizing for SAP S/4HANA requires sizing for both front-end server and back-end server components:

  • The SAP Fiori front-end server hosts the SAP Fiori user interface resources and converts OData service calls into remote function calls (RFCs) to the back-end server. Additional services run on the front-end server that are responsible for all SAP Fiori Launchpad functions, such as user personalization and logon functionality.
  • The back-end server consists of the OData services implementation required for an SAP Fiori application to access the back-end data along with the business logic for performing its business functions, such as sales operations and procurement.

For this example, let’s say that the requirement is for 10,000 employees to maintain their working times in the SAP S/4HANA system on a weekly basis. For this purpose, SAP S/4HANA includes a self-service application called My Timesheet that enables employees to manage their time entries quickly and efficiently using their desktop or mobile device. Here, we are sizing our SAP Fiori front-end server and back-end server for a new deployment of this application.

As part of the sizing for this application, it’s important to understand that not all employees will record their working times at the same time. For example, some employees are sick, are on vacation, or simply record their times during different working hours. Therefore, for the peak load scenario for this example, we make the following assumptions:

  • Half of the employees (5,000 users) are using the self-service app on Friday between the hours of 2:00pm and 4:00pm.
  • A user will stay in the system for 2 minutes, and the system accesses are equally distributed during those 2 hours.

Let’s now look at how to size both the back-end server and the SAP Fiori front-end server required for the My Timesheet application deployment.

Sizing the Back-End Server

We first create a Quick Sizer project for the My Timesheet application, and then select the questionnaire for the back-end server, which takes us to the fields shown in Figure 3. We calculate the number of high-activity concurrent users as follows, using our assumptions for the peak load scenario:

(5000 users * 2 minutes) / 2 hours = 83 concurrent users

Figure 3 — The Quick Sizer questionnaire for the back-end server


We then enter the result into the No. of high activity users field in the Quick Sizer questionnaire and click on the Calculate result button to get the sizing KPIs for the back-end server, which are shown in Figure 4.

Figure 4 — The back-end server sizing results for the example My Timesheet application deployment


Assumptions should always be verified by checking productive usage statistics after go live and the data refined as part of the iterative sizing process described earlier. Remember that this is just an example — for your own project, ensure that the assumptions fit to your unique business.

Sizing the SAP Fiori Front-End Server

Next, we size the SAP Fiori front-end server. For this step, we select the questionnaire for the SAP Fiori front-end server, which takes us to the fields shown in Figure 5. Here, instead of asking for the number of concurrent active users, Quick Sizer asks for the maximum number of SAP Fiori launchpad logons per hour at peak time. You must always think carefully about this number — if you underestimate or overestimate this number, your sizing will be incorrect.

Figure 5 — The Quick Sizer questionnaire for the SAP Fiori front-end server


For the example, if we assume that every employee needs to log on to the system using SAP Fiori launchpad to maintain their timesheets, this would mean 5,000 logons during the 2 hours of peak time between 2:00pm and 4:00pm on Friday. Based on this assumption, the input for the SAP Fiori front-end server sizing is 2,500 per peak hour, which produces the sizing results shown in Figure 6.

Figure 6 — The SAP Fiori front-end server sizing results for the example My Timesheet application deployment


Viewing the Aggregated Sizing Results

For convenience, Quick Sizer enables you to aggregate your sizing results by category (see Figure 7).

Platform figure 5

Figure 7 — Quick Sizer provides options for aggregating sizing results by category



Figure 8 shows the aggregated view of the calculated hardware requirements for both the SAP Fiori front-end server and back-end server components — including the CPU (measured in SAPS), the memory, and the disk requirements — for the example scenario.

Figure 8 — An aggregated view of the sizing results for the example scenario


As you can see, the total memory requirement for the example scenario is approximately 210 GB, which means that the recommendation is a 256 GB SAP HANA box to allow for scalability. When sizing for your particular scenario, remember to always include data growth in your planning.

Conclusion

Accurate sizing is essential to reducing the total cost of ownership of your system landscape and to guaranteeing that your system is running smoothly. SAP helps its customers achieve this goal — for both greenfield installations as well as migrations — with tools and methodologies for translating business requirements into hardware requirements.

The SAP HANA version of Quick Sizer provides SAP customers embarking on new SAP HANA-based deployments with the same guidance used by SAP consulting, sales, and support organizations, as well as by SAP partners, to ensure successful deployments, and going forward SAP plans to continue adding new features to meet the evolving needs of a digital business. SAP also provides support for SAP HANA-based migrations through ABAP-based reports that estimate the required hardware resources (see the sidebar “Migrating to SAP HANA”).

Whether you plan to deploy a new SAP HANA-based application or migrate your existing SAP software to SAP HANA, SAP offers proven tools and methodologies that will help you build the system infrastructure that your business needs. Learn more at www.sap.com/sizing.

Migrating to SAP HANA

If you are already running productive SAP Business Suite and SAP Business Warehouse software, and want to migrate these solutions to SAP HANA, SAP provides migration sizing reports for estimating the required maximum memory consumption of the database.

These ABAP-based sizing reports are independent of the source database provider and calculate the memory requirements for the table data in SAP HANA. The same amount of memory is assumed for temporary working memory. The SAP HANA database also requires memory for code, stack, data caches, the operating system, and other files, although these areas consume smaller amounts of memory in SAP HANA than in traditional databases.

For migrating SAP Business Suite to SAP S/4HANA, see SAP Note 1872170. For migrating SAP Business Warehouse to SAP HANA, see the sizing report in SAP Note 1736976.


1 SAP Application Performance Standard (SAPS) is a hardware-independent unit of performance measurement. Learn more at www.sap.com/benchmark. [back]

An email has been sent to:





 

Sebastian Schmitt
Sebastian Schmitt

Sebastian Schmitt (sebastian.schmitt@sap.com) joined SAP in 2007 after studying at the Universities of Cologne, Cáceres, and Barcelona. He has been a member of the Performance & Scalability team since 2008, and is responsible for hardware sizing from a product management perspective and for the cooperation of SAP and hardware vendors in the area of sizing.


Dagmar Kirsamer
Dagmar Kirsamer

Dagmar Kirsamer (dagmar.kirsamer@sap.com) joined SAP in 1996 after finishing her studies in biology and business informatics at the University of Karlsruhe. Since 2000, she has been a member of the product management team for Performance & Scalability, where she manages sizing processes and is responsible for the Quick Sizer tool.



More from SAPinsider



COMMENTS

Please log in to post a comment.

SAPinsider
FAQ