Storage Sizing for SAP

SAP Minors Program
TEEAM Region
Webex Series
“Storage Sizing
for SAP“
Cenk Ersoy
Advisory SE
cenk.ersoy@emc.com
© Copyright 2014 EMC Corporation. All rights reserved. 1

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

• Greenfield SIZING TYPES
– 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)
• SAN / NAS
• Storage
• Main memory (RAM)
• Count of channels to the storage
(HBA, NIC, Queue depth)
• Performance (Gb/s)
• Count of channels
• Distance
• 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.

SAPS
value is
closely
related to
CPU
power
Source: SAP AG

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
SAP Sources
SAP Recommendation Process Alternative Data Sources for SAPS
(if you don’t receive SAP Quick Sizer Project)
• Oracle AWR Reports + SAP EWA
• SAP Early Watch Reports
• Customer spreadsheet with SAPS
• Pure IOPS
• Customer RFP

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

• 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

• * 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.

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

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

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)

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.

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

More Related Content

What's hot (20)

Similar to Storage Sizing for SAP (20)

More from Cenk Ersoy (10)

Recently uploaded (20)

Storage Sizing for SAP