Sizing SAP S/4HANA using the Quick Sizer Tool Sebastian Schmitt, SAP June, 2017 PUBLIC
Disclaimer
This presentation outlines outlines our general product direction and should not be relied on in making a purchase decision. decision. This presentation is not subject to your license agreement or any other agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to develop or release any functionality mentioned in in this presentation. pr esentation. This presentation and SAP's strategy and possible future developments are subject to change and may be changed by SAP at any time for any reason without notice. This document is provided without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in this document, except if such damages were caused by SAP intentionally or grossly negligent.
Agenda
Sizing Introduction and Basics Sizing Tools and Results Sizing SAP S/4HANA
Wrap-up
SAP HANA Sizing KPIs – Game Changer
Memory
Memory sizing is determined by the data footprint in SAP HANA (business and meta data in co lumn and row store)
Memory is also used by other components (e.g. HANA caches) and for processing of requests
Different sizing approach: HANA sizing vs. sizing of traditional DB
is the leading driver for HANA sizing Massive parallelization in analytical scenarios will have an influence on ; hence CPU requirement will get more important for analytical scenarios
Compared to anyDB, more CPU power is required to fully benefit from the parallel processing capabilities of HANA for optimal response times
Disk is required for data persistence and for logging data Disk sizing depends on type of store which is used Sufficient I/O performance required to enable processes to run with acc eptable data throughput and storage system latency.
CPU
Disk size Disk I/O
Front-end Network Load
Network sizing typically focuses on the bandwidth and is described in gigabits per second (gbps)
now possible with SAP HANA but compete for shared resources
Memory: Leading Driver for SAP HANA Sizing
The main driver for memory sizing is the
of the planned SAP HANA system
Most tables are located in the highly compressed column store of SAP HANA
For of the database and temporary calculations, almost the same size as for required additionally
A SAP HANA database includes further memory areas, such as code, stack, caches, operating system and other system files. These areas are typically small compared to a typical database
is
Approach es to SAP HANA Si zing General Information: Different Memory Areas in SAP HANA
Room to grow
Sizes
Results of sizing reports
Sizing “offset”
1. The memory area allocated for table data, either row store or column store.
Pool
Temporary memory
HANA Table data (row store and column store) HANA caches and services (code and stack included)
Operating System
Relevant memor y parts
Equal to table footprint (assumed)
Table footprint (measured)
~50 GB Depends on node size
2. Subsequently, the buffer for dynamic and temporary computations is assumed to be equal to the table data size 3. “Offset” refers to space required for code and stack, caches and services and the operating system. Note: Used memory consists of temporary memory parts and table data, either in row store or in column store. HANA code and stack is also included, but usually negligible.
What are SAPS?
SAP Application Performance Standard (SAPS) is a hardware-independent measurement unit that describes the throughput of hardware in an SAP environment.
Laptop
1 processor Quad-core Approx. 10,000 SAPS
Definition of SAPS:
Derived from Sales & Distribution (SD) Stand ard Application Benchmark
100 SAPS = 2, 000 fully-processed order line items per hour
Commodity server
2 processors 40 cores Approx. 90,000 SAPS
High-end server
16 processors 244 cores Approx. 500,000 SAPS
For more information on SAPS, see www.sap.com/benchmark → Measuring in SAPS
Three-Party Collaboration Model
Sizing is the joint responsibility of customer (LoB), SAP and HW Vendor. Expectations from benchmarking & sizing
Contributions
Certified benchmarks scalable hardware Different configurations together with technology partners Service level agreements Final responsibility for sizing at customer site
CPU (SAPS) Memory (GB) Database space (GB) Disk I/O operations per sec Frontend bandwidth mbps
Development and provision of benchmark toolkits Regression testing for new releases Standard sizing guidelines Sizing verification processes
The main responsibility have the HW Vendor.
Contributions
Contributions
Optimal performance Suggestion for HW config. Responsetime requirements Throughput requirements Provides business input
Examples: Custom coding Different businesses require different sizings Different applications need different amounts of CPUs Additional needs might come from additional not sized usages
Agenda
Sizing Introduction and Basics Sizing Tools and Results Sizing SAP S/4HANA
Wrap-up
General Available Sizing Page (www.sap.com/sizing)
Access Sizing Guidelines Access Sizing-related Materials
Access Quick Sizer * Sizing Decision tree Others
* Requires login credentials
Standard Sizing Methods and Tools
Educated guess
For structured questions
Simple algorithms with many assumptions Supports userbased and throughput-based sizing
Simple or more complex
Example: Quick Sizer, SAP’s Online Sizing Tool
Structured sizing questionnaires Input for – Greenfield sizing – GoingLive Check Hardware vendor contact list
Available online since 1996
Free of charge As of 2016: avg. 35,000 new projects per year
SAP Key applications – SAP S/4HANA – SAP Business Suite and Industries – SAP NetWeaver® – etc. Sizing by users and/or by throughput
available (since 09/2014)
Agenda
Sizing Introduction and Basics Sizing Tools and Results Sizing SAP S/4HANA
Wrap-up
SAP HANA Sizing – In a Nutshell
New SAP HANA system (Greenfield Sizing )
Use HANA Quick Sizer
Appliances, SAP Tailored Datacenter Integration (TDI), Cloud via SAP Cloud Appliance Library (CAL) Connect with hardware vendor and check for sample configuration or get started with SAP CAL
Existing SAP system migrated to HANA (Migration Sizing )
Use Migration Reports
Greenfield Sizing
Greenfield Sizing for SAP S/4HANA
For greenfield sizing for SAP S/4HANA, use HANA version of Quick Sizer
Please note: The basics of the calculations are the same in HANA QS and in the Classic QS, e.g. the think times of the different user types (low, medium, high) are the same
Data Aging
Data aging is a business data management concept for reducing the memory footprint in SAP HANA
Only operationally relevant (“hot”/current) data is loaded into main memory of SAP HANA
Other (“cold”/historical) data remains primarily stored on disk, not affecting hot data performance, yet cold data remains accessible via SQL on request
HANA Quick Sizer News Data Aging in HANA Quick Sizer
There are aging objects available, if the aging column (residence time in memory) is changeable. Per default the aging period has been set to 24 months
There are no aging objects available, if the aging column (residence time in memory) is empty and highlighted in blue.
Since March 2017: Introduction of ‘What if analysis for the retention times (disk/memory)’
Example What-If Analysis Data Aging
Quick Sizer News Sizing Principles for SAP Fiori Frontend Server (FES)
SAP Fiori Launchpad (FLP) Logon is the most influencing sizing factor Determine Your FLP Logon Scenario for FES Sizing
The total resource consumption has two parts, the one on the SAP Fiori Frontend Server, and the other one on the SAP S/4HANA Backend
For Fiori Frontend Server Sizing, please use the SAP Fiori Frontend Server Sizing” in the Quick Sizer and estimate the maximal number of FLP logons per hour at peak time
Please Don‘t Forget to Size the Backend for Your Application Areas
Quick Sizer News HANA Disk I/O SAP HANA requires adequate I/O performance to support processes such as
Savepoint writing
Delta merges
Database startup times
Storage systems running with SAP HANA must provide sufficient I/O performance to enable processes to run with acceptable data throughput and storage system latency.
Sizing SAP S/4HANA Embedded Analytics
The goal of sizing for Sizing SAP S/4HANA Embedded Analytics is:
To determine how many CPU Cores/Threads and memory are required for the processing of target number of parallel queries
And at the same time achieving the average
Example Analytical Fiori Applications
HANA is designed for OLTP+OLAP. OLTP workloads can be sized with the Quick Sizer, whereas Analytical Fiori Applications (OLAP) have to be sized additionally.
Example Analytical Fiori Applications
Input
The SAPS out of the analytics sizing are very “peaky SAPS”, which are needed to get the best possible response times
Customers have to be asked, whether this load may be shifted to low load phases
Customers have to decide, whether this optimal response times justify systems, which have X times more CPU power compared to what is needed just for the usual throughput out of the usual sizing.
Customers and hardware partners have to find a balance between optimal response time on the one side and minimized costs for hardware on the other side (also higher response times might be acceptable for the business of the customer)
Result
Migration Sizing
Sizing Report for SAP S/4HANA
Described in SAP Note 1872170 – Suite on HANA sizing report
Runs on SAP_BASIS 620 and higher
Is suitable for sizing of all Business Suite products (ERP, CRM, SCM, SRM, etc.)
Not suitable for BW (Refer to SAP Note 1736976 – Sizing Report for SAP Business Warehouse on HANA)
Estimates the maximum memory consumption of the database, if migrated to SAP HANA
Is independent of the source database provider
Considers distribution of tables to row and column store
Considers differences for secondary indexes
Considers compression of legacy database
SAP Simple Finance Sizing for Migration Sizings
The current version of the report is also valid for sizing of HANA 2.0. The report can also be used for different sizing scenario such as SAP Suite on HANA, SAP S/4HANA Finance, SAP S/4HANA.
1872170 – Suite on HANA sizing report
Algorithm of Sizing Report /SDF/HDB_SIZING •
1
2
is read from the database statistics
• A tables in the system
from every
• Out of this sample, the report calculates the
3
4
Example: Column “mandt” has an average size of 6 bytes and the tables has 100 records. Total uncompressed size of the column is 600 bytes.
• Out of the average size per column and the total record count, the
• To the uncompressed size
5
Example: A typical column “mandt” has type c and values such as ‘100’, ‘000’, ‘066’. The report will calculate an average size of 6 bytes for this co lumn.
to get the estimated size in HANA.
The size estimation for keys (primary, secondary keys, etc.) is more complex (and more accurate) but uses the same metrics (avg. size per column and record count)
Results of Sizing Report /SDF/HDB_SIZING
The sizing report for SAP ERP on SAP HANA includes the sizing projections, based on the actual table sizes in the legacy system as well as an estimation of how much the memory footprint can be reduced using functionalities that HANA will enable.
How to Interpret the Results of the Sizing Report
Column store and row store estimations have good enough accuracy (10-20%). Still, do not forget it is an estimation.
Work Space (temporary memory) estimation uses a simple formula (data size in memory) * 2. Based on experiences, if the work space is bigger than 3TB, it might be oversized.
Always check the top tables. Very often, you will find basis tables with deletion/archiving potential such as idoc, workflow, application log tables, etc. See SAP Note 706478 – “Preventing Basis tables from increasing considerably” for more details.
The total estimated memory requirement given by the report should not be considered as the final memory sizing result. Take into account that: – Not all the server physical memory will be available to HANA (OS and other processes are run too). – There should be enough space left for future data growth or functional extension The sizing report takes a snapshot. Any growth between that date and the go-live date should be considered.
Memory Sizing Report News (1872170 – Business Suite on HANA and S/4HANA sizing report)
Added to already existing data aging estimation for Application log, Change documents and iDocs. The addition of this objects completes the full coverage of “service objects”.
Memory Sizing Report News
Improve sizing of the “Work Space” (or temporary memory)
Add more data aging objects to the report (especially, estimation of saving on “application objects”)
Integrate IOPS Sizing
Reflect further simplifications in data model
Deployment Options
Active-Active Read Enabled
Currently „out of the box“ about 60 Apps are Active-active read enabled.
Customer build queries – Usage of generic analytical clients that use analytical CDS views – Own Smart Business Apps (and respective adjustment of the Tile configuration) – Own purely reading Apps (and respective adjustment of the App Descriptor)
Sizing: Beware that in case of a fail over the complete load is on one instance
For resource intensive operations available resources are used
SAP HANA Multitenant Database Containers (MDC)
– Each tenant database has its own database admin and end users, database catalog, repository, persistence, backups, traces and logs
App li cati on
App li catio n
– Tenants Memory and CPU consumption can be configured independently
– Integration with SAP HANA data center operation procedures, housekeeping, backups (full and/or on tenant level), etc. SAP HANA System
– Shared installation of database system software and therefore better usage of hardware
System DB
– Tenant databases are identified by name or port – SAP HANA system replication covers whole system (Sys. DB and tenants)
– Additive sizing for all tenant database
Tenant DB
Tenant DB
The calculation of CPU requirements based on the memory footprint doesn’t take these differences into account Risk of CPU over-sizing Risk of CPU under-sizing with wrongly perceived C2M* (e.g. systems with high DB load)
Reduced memory footprint will also lead to reduced CPU requirements. But: Data aging should not reduce the required CPU resources for OLTP load Increased risk of CPU under-sizing with wrongly perceived C2M*
The calculation of CPU requirement based on the memory foo tprint might not reflect correctly the additional CPU requirements for OLAP workloads. Increased risk of CPU under-sizing with wrongly perceived C2M*
Distri butio n: User-based Sizing Elements vs. C2M Ratio
Expected shifts through Sizing of Anal ytic al Ap ps
Expected shifts through Data Agi ng eff ect s
Quick Sizer proj ects wit h higher CPU results as proj ected by th e C2M ratio
Sizing information and tools Sources of published sizing documentation www.sap.com/sizing – Access to Quick Sizer* – Access to sizing guidelines, for example, SAP HANA accelerators
SAP Support Portal – SAP Note 1872170 – SAP S/4HANA memory sizing – SAP Note 1793345 – Sizing for Suite on HANA – SAP Note 1736976 – Sizing Report for BW on HANA – SAP Note 1514966 – SAP HANA 1.0: Sizing SAP In-Memory Database
HANA Sizing – General Introduction to Sizing on SAP HANA video
HANA Quick Sizer (for greenfield sizing) & SAP SoH Migration Sizing Greenfield Sizing with SAP Quick Sizer demo video
* Requires login credentials
7 Key Points to Take Home
Sizing means translating business requirements into hardware requirements
The success of the sizing exercise almost entirely depends on the quality of the data
Sizing involves very different people and teams within an organization
Expert sizing is recommended for custom development
The HANA sizing approach is different from the sizing of traditional databases
Initial Sizing for HANA should be done with Quick Sizer
Migration sizing of an existing system to SAP S/4HANA should be done following SAP Note 1872170
