Sizing modern sap hana landscapes

1. Sizing Modern SAP HANA Landscapes
How to Plan the Right Hardware Configuration with the SAP HANA Version of Quick Sizer
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.

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

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

4.  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.

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

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