storage sizing for sap

1 © Copyright 2014 EMC Corporation. All rights reserved. © Copyright 2014 EMC Corporation. All rights reserved.

SAP Minors Program TEEAM Region Webex Series

“Storage Sizing for SAP“

Cenk Ersoy Advisory SE [email protected]


SAP Minors Program SAP Minors Community Page: https://community.emc.com/community/connect/presales/presalesminorsprogram/presales-minors-sap

SAP Minors Training Path and Training Modules are available here: https://community.emc.com/docs/DOC-31637


WHAT IS SIZING •  Sizing is the process of translating business needs into hardware

requirements

•  SAP sizing determines max hardware requirements based on sizing KPIs such as CPU time, disk size/performance, memory size, network bandwidth

•  Sizing is an iterative process

•  Sizing method is usually based on several assumptions (number of users, documents processed per hour etc) – make sure you document/test your assumptions

•  Every vendor (or even every specialist at a vendor) may have its own method of sizing


SIZING TYPES •  Greenfield –  Customer is implementing SAP for the first time –  Estimate sizing using SAP QuickSizer and SAP Sizing Guidelines

(e.g. http://service.sap.com/quicksizing and http://www.sap.com/bisizing )

•  Brownfield or “post-go-live” –  Customer currently running SAP but looking to expand their

hardware capacity , add more users or re-platform –  Extrapolate sizing from existing hardware and measured

utilization

•  Hybrid –  Brownfield customer but …looking to implement new SAP

components or newer release which will be Greenfield –  Mix of approaches to sizing


ANOTHER VIEW OF SIZING TYPES TYPE Recommendation Initial (Greenfield) Use the online SAP QuickSizer Tool –

usually for budget estimation ( http://service.sap.com/quicksizing )

Resizing (no new functionality but more users or data)

Get values from current SAP monitors (DB02, ST06, ST03N etc), OS monitors (perfmon, kstat etc) and extrapolate

Delta Sizing (new business functionality)

Combination of QuickSizer and SAP monitors

Upgrade Sizing (newer release) Use SAP monitors (DB02, ST06, ST03N etc) and consult the related OSS Note for the upgrade

T-Shirt Sizing (new application where QuickSizer is not available)

Consult SNC, IPC sizing guide or see http://service.sap.com/sizing


CAUTION •  Do not rely simply on the output of the sizing tool. Factors such as

code customizing, parameter settings, usage behaviour, data growth rate, data lifecycle policies and in-place datacenter processes may affect the actual required sizing.

•  Get the input of business users as well (not just infrastructure team).

•  For customer with very extensive code modifications, expert level SAP sizing may be needed.

•  Sometime custom questionnaires may be used.


Usual Suspects - Bottlenecks •  SAP – ABAP Programming / SQL

•  Missing Index •  Z-procedures

•  Database •  Layout – count of data

container... •  Balance between the storage

components •  Data striping

•  Host (physical oder virtual) •  Main memory (RAM) •  Count of channels to the storage

(HBA, NIC, Queue depth)

•  SAN / NAS •  Performance (Gb/s) •  Count of channels •  Distance

•  Storage •  Frontend channels •  Cache (Storage system) •  Resource consumption •  Drive type and tiering •  Layout •  Multiple Striping


What is SAPS SAP Application Benchmark Performance Standard

•  It is a hardware-independent unit that describes the performance of a system configuration in the SAP environment. SAPs are the number of SD dialog steps using transactions VA01->VL01N->VA03->VL02N->VA05->VF01 that can be completed in one minute. •  Since the benchmark has a built-in think time of 10 seconds between dialog steps, each user can complete 60/(10+ RT) dialog steps per minute. 100 SAPS = 2,000 fully processed order line items / hour or

= 6,000 dialog steps and 2,000 postings or = 2,400 SAP transactions (VA01->VL01N->VA03->VL02N->VA05->VF01) or ~ 20 SD benchmark users @ 2 sec response time ~ 18,35 SD benchmark users @ 1 sec response time


What is SAPS •  SAPS value is a hardware-independent unit of measurement that equates to SAP OLTP throughput of Sales and Distribution users. •  SAPS value is not a pure hardware performance indicator, but also a software performance indicator—measuring a Unicode system yields lower SAPS numbers than a non-Unicode system. •  Starting in 2009, SAP SD Standard Application Benchmarks must have a response time below one second (instead of 2 seconds before), must be Unicode-based, must use the general ledger business functionality, must use Enhancement Package 4 for SAP ERP 6.0, and must use special versions of SAP_APPL and SAP_BASIS. Because of these changes, the same hardware can deliver a lower SAPS number in benchmark certificates of 2009 than of 2008.


Source: SAP AG

SAPS value is closely related to CPU power


SAP Benchmarks •  SAP works closely with hardware vendors and performs benchmarks on different hardware configurations. •  The results are published at http://www.sap.com/solutions/benchmark/sd2tier.epx


SAP Benchmark Example

Source: SAP AG


SAP Sizing Fundamentals •  The smallest possible server is usually determined by

the peak load of the largest data base (very conservative)

•  SAP recommends a max resource utilization of 65% Results of QuickSizer defines a system that will run at 65% utilization.

•  Some real life ratios of database versus App server power:

–  1 : 3 for OLTP (at least 25% for DB, 75% for App) –  1 : 2 for OLAP (at least 33% for DB, 66% for App)


SIZING: Key performance indicators •  CPU

–  Processing time –  Cost factor – number of servers and/or CPUs –  Expressed in SAPS (www.sap.com/benchmark) –  Rule of Thumb: 1:1 vCPU:pCore

•  Memory –  Cost factor – physical memory slots in server, DIMM size –  Expressed in MB/GB –  Rule of Thumb: No memory over-commitment. Don’t forget

to consider consider OS, DB memory requirements

•  Disk –  Needed to store data (SAP repositories - ABAP Code) –  Cost factor – amount of data, retention period, disk I/O, backup


Source: SAP AG


Sizing Core Storage

•  Oracle AWR Reports + SAP EWA

•  SAP Early Watch Reports

•  Customer spreadsheet with SAPS

•  Pure IOPS

•  Customer RFP

SAP Recommendation Process Alternative Data Sources for SAPS (if you don’t receive SAP Quick Sizer Project)

SAP Sources


SAP QuickSizer Example

Note: SAP OSS ID is required to access Quick Sizer


SAP QuickSizer �  The customer works with a SAP consultant to define their initial

environment within QuickSizer.

�  QuickSizer has two independent models for sizing: User based and throughput based

�  QuickSizer estimates CPU, memory and disk requirements.

�  Throughput based sizing is better for larger projects but usually the customer lacks the input data (number of processed orders, document sizes, online usage behaviour, background jobs etc)

�  It is better to use «DB SAPS» values from QuickSizer for storage sizing


SAP QuickSizer �  The CPU sizing result assumes 65% utilization. It is OS and

hardware independent

�  Disk size recommendation is based on the sizes of the DB tables in the DB Data Dictionary in SAP. It is platform independent. Storage sizing for binaries, images, temp areas and SAPMNT are not considered in the disk space calculations.

�  Memory sizing is also hadware independent. Unicode is assumed.


Source: SAP AG


Limits of QuickSizer Based Sizing


Sizing Core Storage SAP Early Watch Alert and AWR for Oracle


Sizing Core Storage SAP Early Watch Alert for SQL


Sizing Core Storage Customer Spreadsheet, Pure IOPS, Customer RFP


Disk: Space & IO Sizing •  Data from QuickSizer is database space only

–  Need to allow for OS, swap, database software, SAP software, etc –  Information is in ‘Installation Guides’

•  Estimating IOPS based on SAPS. –  IOPS can be estimated from SAPS, using just the Database SAPS –  For transactional systems, ECC, CRM, SRM, etc (%70r/30w or %80r/

%20w): •  Front End IOPS = 0.6 * Database SAPS

–  For analytical systems, BW, SEM, etc (%50r/%50w): •  Front End IOPS = 0.9 * Database SAPS

**If DB SAPS are not known, General Rule of Thumb recommends use 40%-60% of Total SAPS. On the other hand major Server Vendors (and some SAP documentation) usually pitch 20%-30%.

There is NO universally accepted method to convert SAPS to IOPS


Disk: Space & IO Sizing •  Some documentation use the following conversion from SAPS (not DBSAPS!)

to IOPS –  For transactional systems, ECC, CRM, SRM, etc (%70r/30w or %80r/

%20w): •  Front End IOPS = 0.4 * SAPS

–  For analytical systems, BW, SEM, etc (%50r/%50w): •  Front End IOPS = 0.6 * SAPS

There is NO universally accepted method to convert SAPS to IOPS


Disk: Space & IO Sizing •  * ALWAYS DOCUMENT YOUR ASSUMPTIONS

–  Document where you got your input values (Project No from QuickSizer, MiTrend utilization reports, PerfMon etc)

–  SAPS to DBSAPS conversion method –  DBSAPS to IOPS conversion method –  Overall storage utilization factor (%65) –  Read/write ratio for converting front end IOPS to backend IOPS –  RAID penalty for converting front-end IOPS to backend IOPS –  IO block size –  Storage cache hit rate


Disk Sizing Example – page 1 In this Greenfield sizing example we will assume that we have the following SAPS values from the customer (QuickSizer output, custom values etc). Since this sizing exercise is performance based, capacity needs are not listed here.

SERVER SAPS ERP - ECC 3,00 CRM 5,000 BW 4,000

1- First we should convert SAPS to DB SAPS by using

DB SAPS = 0.3 x SAPS (we could also use 0.4)

SERVER SAPS DB SAPS

ERP - ECC 3,000 900 CRM 5,000 1,500 BW 4,000 1,200

Note: Since QuickSizer calculates with 65% utilization, some specialists take %65 of the SAPS value from QuickSizer and design an array with higher utilization rate.


Disk Sizing Example – page 2 2 – Now it is time to convert DB SAPS to Front End IO

For transactional systems (OLTP), ECC, CRM, SRM, etc (%70r/30w or %80r/%20w):

Front End IOPS = 0.6 * Database SAPS For analytical systems (OLAP), BW, SEM, etc (%50r/%50w):

Front End IOPS = 0.9 * Database SAPS

SERVER SAPS DB SAPS

APP TYPE

Front End IO

ERP - ECC 3,000 900 OLTP 540 CRM 5,000 1,500 OLTP 900 BW 4,000 1,200 OLAP 1,080


Disk Sizing Example – page 3 3 – Now it is time to calculate front end read and front end write IOs

For transactional systems, ECC, CRM, SRM, etc %80 Front End Read / %20 Front End Write

For analytical systems, BW, SEM, etc %50 Front End Read / %50 Front End Write

SERVER SAPS DB SAPS APP TYPE

Front End IO F/E Read

F/E Write

ERP - ECC 3,000 900 OLTP 540 432 108 CRM 5,000 1,500 OLTP 900 720 180 BW 4,000 1,200 OLAP 1,080 540 540


Disk Sizing Example – page 4 4 – It is time to sum up front-end IO for OLTP and OLAP seperately to determine the IO workload from SAP servers to the storage

SERVER SAPS DB SAPS APP TYPE

Front End IO F/E Read

F/E Write

ERP - ECC 3,000 900 OLTP 540 432 108 CRM 5,000 1,500 OLTP 900 720 180 BW 4,000 1,200 OLAP 1,080 540 540

For OLTP workload, we have 1152 host reads / 288 host writes (small random IO)

For OLAP worload, we have 540 host reads / 540 host writes (large block sequential IO)


Disk Sizing Example – page 5 5 – Now that the host workload profile is determined EMC has several tools to size the storage array based on worload :

* Disk Sizer for VNX

* Tier Advisor for Symmetrix

Assume a storage array read cache hit rate of 20% - 40% (assume the larger value is you are proposing FASTCache.


Disk Sizing Example – page 6 If you do not have the storage array sizing tools (Poor Man’s Approach J ) •  Convert OLAP large block IO (128KB) to OLTP small block IO (8KB); •  take the front-end IOs write IO and multiply by RAID penalty factor for writes (4

for RAID5 and 2 for RAID1)

•  add the front end read IOs •  the result will give you the backend IO value •  finally define a tiered backend architecture with the following IOPS per drive

type: 3000 IO per SSD 180 IO per SAS/FC 15K

140 IO per SAS/FC 10K 60 IO per NLSAS/SATA (I personally do not recommend this tier)

Make sure that the capacity requirements are also met.


Sizing HANA �  HANA is server based in-memory with storage used

as persistence level

�  Sizing is determined by SAP and the server vendor –  CISCO –  VCE

�  Storage is usually sized at 4X the memory

�  Disk sizing is well documented for both appliance and TDI models (see the whitepapers)


LANDSCAPE DESIGN •  Sizing & Landscaping are different tasks

•  Landscaping is about how you logically will spread out your VMs in the SAP Systems and Landscape.

•  Define your VM profiles, socialize with customer. Ex.

–  2vCPU/32Gb –  4vCPU/64GB –  8vCPU/96GB

•  This can lead you to discussions about HA, DR at the application level for enqueue(locking), message and DB. (Be Aware of NUMA impact for virtualized systems)


THANK YOU

storage sizing for sap

Travel

sizing sizing

sap sizing guidelines

emc corporation

sizing tool

method of sizing

sizing kpis

expert level sap sizing

time estimate sizing