Sizing Modern SAP HANA Landscapes

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 SAPS¹), 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.

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.

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.

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).

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.

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