Place photo here IBM sizing for SAP solutions

Transcription

1 Place photo here IBM sizing for SAP solutions Last update

2 Content SAP Sizing Process in General Rules of Thumb Landscape Considerations 2

3 Content SAP Sizing xxxxx Process in General SAP Rules of Thumb Landscape Considerations 3

4 Content SAP Sizing Process in General Terminology Fundamentals of sizing methodology 4

5 What is Sizing? to predict the expected workload, to propose the infrastructure that can cope with the load. 5

6 Sizing and its deliveries. CPU capacity Precise science Main memory Disk capacity ü Without fail A mystery X Network speed Black magic... à Sizing is a technical presales effort! 6

7 Sizing of SAP Systems Estimation of the necessary system resources for a new SAP System (CPU capacity, memory, disk space, network) based on a workload estimation. Customer Requirements Questionnaire Load Profile Estimation iterative Measurements Analysis Capacity Ratings close contact Customer IBM/BP HW Selection & Sizing Customer Configuration ISICC IBM Labor SAP 7

8 Setting the right expectations SAP Sizing is only an approximation of reality Throughput sizing only, NO guaranteed response times Rules of Thumb are only an approximation of SAP Sizing Please work with IBM Techline to have the actual sizing work done! Talk the same language your customers do: SAP Releases Types of Users Business scenarios and their mapping to infrastructure 8

9 Definitions of SAP user types Have the same User definitions your customers uses Named è SAP license only Logged in è Memory (paging area), but no CPU Concurrent è CPU, Memory, I/O High (10 sec), Medium (30 sec), Low (300 sec) transaction rate n. u. 100% of named users l. u. c. u. 65% of named in users are logged users 52% of named users are concurrent active users 9

10 The SAP sizing anchor point: SAPS SAPS S AP A pplication Benchmark P erformance S tandard 2,000 fully processed 100 SAPS order line items / hour* SD Benchmark * 6,000 dialog steps and 2,000 postings or 2,400 SAP transactions 10

11 SAP Quicksizer normalizes to SAPS SAP Quicksizer THE central online sizing tool by SAP All SAP application loads although not Sales&Distribution are normalized to SAPS Two modes: User based è fast, less accurate Transaction based è sophisticated input, more realistic results User based targets for 33% dialog utilization + 32% batch load = 65% overall system utilization Input covers users Batch load (e.g. reports, printing) is assumed to be a fixed, incremental portion to it Transaction based targets for 65% utilization Input covers dialog and batch load Requires process knowledge and timing 11

12 Quicksizer : transaction vs. user based sizing transaction based user based DATA Structure 100% 90% 80% 70% 60% 50% 40% 30% CPU Variable Quantified Load 35% Buffer Target utilization 65% DATA Structure 100% 90% 80% 70% 60% 50% 40% 30% CPU Variable Non-Quantified Load 20% 20% Quantified Load 10% 10% 0% 0% 12

13 Content SAP Sizing Process in General SAP Rules Rules of Thumb of Thumb for basic Sizing Landscape Considerations 13

14 Content Rules of Thumb for Basic Sizing Processor Memory Disk & IO Unicode 14

15 User Weighting per SAP Quicksizer The typical load ratio between SAP production Users is: Light 0,1 Medium 1 Power Mostly Power-Users consume factor 10 vs. Medium. Average over all assessed modules is by a factor of 7. The user weighting has NO impact on memory footprint 15

16 Impact of User Load distribution on ECC 6.0 Backend Systems Lighter Heavier Avg.=12 SAPS/user Avg.=18 SAPS/user Light 30% Medium 60% Power 10% Light 10% Medium 70% Power 20% Assume 100 Users: the difference is 600 SAPS ~ 1/4th of a today s processor core In other words: 400 Users would require an additional x86 CPU in this case 16

17 Today s SAP landscape ERP (main OLTP load) BW (main OLAP system) EP + PI = transient load Ø additional capacity per user required! Solution Manager Ø additional capacity for administration purposes required. 17

18 SAP NetWeaver landscape example For the ECC NetWeaver landscapes we assume the following load distribution of the production system: 100% of users use ECC % of these concurrently use an Enterprise Portal 30% create messages on PI 10% of them create concurrent workload using BW 18

19 ECC 6.0 EHP4 / aka BS7 SAPS and concurrent users covered by configurations The chart depicts the capacity requirements for essential SAP NetWeaver based scenarios The Mix ECC+NW curve represents the module load mix outlined on previous chart, i.e. 100% concurrent user in ECC, 50% EP, 30% XI, 10% BI. The slope in SAPS capacity represents the advantage by dynamic resource sharing by Advanced POWER virtualization. 19

20 SAP Sizing CPU Rules of Thumb Per previous charts, we can conclude : 1 concurrent / active user requires 12 SAPS Backend (ECC) + 10 SAPS (EP, PI, BI). = 22 SAPS 1 named SAP NW user requires 11 SAPS Now it s easy to map this to CPUs and Models ~ SAPS/core for ECC 6.0 EHP4 for POWER7 systems ~ SAPS/core for ECC 6.0 EHP4 for Intel/AMD based systems 20

21 Official System Sizing tables Source: ISICC Sizing Tables for System x Maintained by performance team from IBM Beaverton and ISICC IBM Confidential Updated 2 4x a year Published on ISICC SAP Architecture Notes- DB for all platforms Available for IBM System x on Partnerworld at public.dhe.ibm.com/ partnerworld/pub/sap/ pw_system_x_capacity_ tables_2013_03_06.pdf 21

22 Capacity versus Response Times SAPS as a sizing metric is a measure for system capacity provided and throughput consumed SAPS is not a response time indicator IT Departments and SAP Basis teams are primarily interested in transaction capacity of their servers SAP End-Users are primarily interested in a fast response time for their individual transactions. SAP ERP < 0,5 sec, Analytical Queries ~some seconds When Server capacity becomes exhausted, response time turns bad: A desirable overall system utilization rate is 70%-80% SAP SD-Benchmark characteristic 22

23 Throughput versus (Single-Thread) Performance Single-thread performance is important for SAP batch runs and certain transactions Faster CPUs (GHz) result in faster processing times for a thread (= executable) But also other processor design points impact its performance e.g.: out-of-order processing, branch efficiency, Today s CPUs are multi-threaded: 2 threads x86, 4 threads POWER7 Best gain, whenever there is a good mix of computation and wait cycles for any of the concurrent threads As soon as all concurrent threads are CPU bound, performance of each single thread will suffer consequently, multi-threading benefit depends on individual SAP workload mix ABAP Java ABAP 23

24 SAP Sizing Some Memory Rules of Thumb Memory Recommendations 6 8 GB per 1000 SAPS (Quick)sizer output assumes an ABAP:Java mix of 80%:20% Consequently, server capacity is MEMORY bound Above values are OK for a single SAP instance on a server/lpar. Add a minimum of 2 GB for each instance in case you consolidate several SAP instances on a single server/partition. Consider some additional memory for virtualization features Also consider DIMM upgrade capabilities of the selected box. 24

25 Variations of SAP memory requirements 25

26 Virtualization Some Memory Rules of Thumb Memory is NOT a dynamic resource as processors are Ideally size Memory for a Virtual Machine resp. a Dynamic VM/LPAR targeting its largest extension. Allocate some additional memory for virtualized systems management through Hypervisors For Hypervisor itself, e.g. 256MB for PowerVM For virtual memory, device slots (adapters) About 1GB of incremental memory footprint for smaller systems Example: Memory Allocation duration from Shared Memory Pool via AMS. 26

27 Virtual I/O Server Design Basic recommendations Two Virtual I/O Server partitions are required for production load resilience against failure or misconfiguration planned maintenance for VIO server Use Dedicated Donating In shared pools assign minimum 10% CPU power to the VIO Server +Clients Sample Virtual I/O Server partition configuration 1 GB Memory (min=512mb max= 4GB) Uncapped Micropartitions with Capacity Entitlement = 0,5 2 Virtual CPUs, SMT enabled 30 Virtual Slots Maximum number of virtual slots has to be defined in LPAR profile and is not dynamic Hypervisor TCE memory allocation scales with the slot number Default of 10 for Client partition sufficient in most cases Attention: Using Slot Nr. 16, means that the Hypervisor reserves 16 Slots 27

28 SAP Sizing Basic I/O Rules of Thumb 2.5 SAPS (DB+App-Serv) generate 1 I/O operation per second 1 concurrent SAP NW user generates ~ 9 I/Os per second A single 15k rpm disk is capable to support a maximum of 200 I/Os per second in other words: per 22 concurrent SAP users configure one disk drive hence, disk configuration is not capacity, but I/O driven Disk Controller RAID mechanisms have impact on aggregate I/O rates of storage subsystem e.g. RAID 10 increases READ throughput (reads from 2 disks) but WRITE is reduced Adapters SCSI, FC, SATA, NAS, iscsi Storage Sizing Guide and SAP Magic Tool available Links and details in following Tools presentation 28

29 SAP Sizing DB-centric I/O Rules of Thumb 0.3 DB-Server SAPS generate 1 I/O operation per second New SAP I/O sizing approach for situations where DB-SAPS portion is well defined Previous RoT is considered to result in too high I/O estimates for newer SAP modules. Reason: more SAPS are consumed on App-Server side relative to DB SAP Quicksizer now explicitly shows SAPS split between the two instances. Variation of DB-SAPS : App-SAPS is significant for different SAP modules e.g., 1:3 for ERP = OK versus 1:15 for CRM = too high I/O load for DB-Server Their number is defined as own DB-Server SAPS requirement in SAP Quicksizer result section 29

30 Delta Sizing Guide when moving to Unicode base Based on parallel benchmarking of Unicode / non-unicode customer systems Note: The CPU/RAM figures are measured average numbers and will be different for different transactions CPU IBM: CPU +20% RAM IBM: RAM +50% l +30% l depending on existing scenario (MDMP, double- byte) *+5% on DB2 for z/os because no conversion between application server and database is needed Database size l UTF-8* : up to +10% l UTF-16 : % * 10% is the observed maximum for bigger systems (db size > 200 GB). IBM: % l +50% l Application Servers are based on UTF-16 internally Network Load (SAP GUI for Windows) l UTF-8 l almost no change due to efficient compression Source: SAP 30

31 SAP Upgrade Sizing via Release Deltas Inital Release 4.5B 4.6B 4.7 x x x200 ECC 5.0 ECC 6.0 ECC 6.0 BS 7 BS Unicode Unicode 4.5B B Initial Rel. = 100% 4.7 x x x ECC ECC ECC 6.0 Unicode Target Rel. requirements BS BS 7 Unicode

32 Content SAP Sizing Process in General Rules of Thumb for basic Sizing T-shirt Landscape Sizing Considerations for Appliances 32

33 Landscape Considerations Supporting Systems How many supporting systems do you plan for a production system? Development System? Quality Assurance System? Sandbox or Training System? Template Approach for deployment in several countries. This could imply more support systems. A common approach is to have at least one DEV and one QA system. In small installations you might consider to have only one supporting system, combining DEV, QA and SANDBOX in one system. 33

34 Landscape Considerations 2-Tier or 3-Tier 2-Tier versus 3-Tier SAP Applications do have a layered architecture Database Layer Application Layer Presentation Layer You can combine the Database and Application Layer (2-Tier) Or you can seperate these two layers on different operating system images (3-Tier) 2-Tier ease of operations, less SAPS because savings in the communication 3-Tier saving resources for High Availability (In case you have several application servers, they are not seen as a single point of failure), more SAPS because of communication overhead. 34

35 Landscape Considerations - Consolidation Combining several Applications on one server gives the opportunity to save resources Basically you will observe that not all applications will peak at the very same time. In case the applications are not up and running you have to determine the consolidation factor upfront. Realistic factors are between 1.2 and 4 A combination of supporting systems and production systems will give higher consolidation factors. 35

36 Customer environment exploiting virtualization capabilities on Power5 systems: 4x p570, each with 12 active CPU + 4 CPU CUoD) 36

37 Intelligent distribution of productive and non-productive instances on one physical server: e.g. 21 SAP instances on one single p570 SAP-System LPAR Memory (in G) CPU-Entitlement vcpu Weighting ID MinimumDesired Maximum Desired Minimum Maximum desired min max uncapped VIO-Server ,4 0, VIO-Server ,4 0, P ,4 0,2 1, P ,5 0, CS-Test ,1 0,1 0, C ,3 0,2 0, C ,2 0,2 0, C ,2 0,2 0, C ,4 0,2 0, P07_idle 11 1/ ,4 0, P31_idle ,4 0,2 0, I ,1 0,1 0, C ,1 0,1 0, T ,1 0,1 0, C ,1 0,1 0, IDMS-X ,1 0,1 0, A ,1 0,1 0, K ,1 0,1 0, IDMSXP ,2 0,1 0, sideprod ,1 0,1 0, Q ,1 0,1 0, P04_idle 23 1/ ,2 0,1 0, Q ,6 0, MME RZ ,7 3,0 19,9 44 Production Qualityassurance Development K-Backup (idle LPAR) Virtual-I/O Server 37

38 Resource utilization (measured with rrdtool ) leading to best-class value of 60% Additional CPUs for CUoD Active CPUs in uncapped SPLPAR pool 38

39 And IBM has the right proof-points already on the table: Resource synergies from real customer cases Classical SILO Setup (based on SAP Quicksizer) Intelligent Virtualization on IBM Power Systems Reduction of Server HW Infrastructure Admin/Operating Energy Consumption CPUs Memory CPUs Memory GB GB GB GB n/a n/a GB GB TB GB GB GB GB IT Shop SCM IT 39

40 Time for questions SAP Main Products and Solutions Mail contact: 40

41 Special Notices Information in this document concerning non-ibm products was obtained from the suppliers of these products or other public sources. Questions on the capabilities of non- IBM products should be addressed to the suppliers of those products. IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. Send license inquires, in writing, to IBM Director of Licensing, IBM Corporation, New Castle Drive, Armonk, NY USA. All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. The information contained in this document has not been submitted to any formal IBM test and is provided "AS IS" with no warranties or guarantees either expressed or implied. All examples cited or described in this document are presented as illustrations of the manner in which some IBM products can be used and the results that may be achieved. Actual environmental costs and performance characteristics will vary depending on individual client configurations and conditions. IBM Global Financing offerings are provided through IBM Credit Corporation in the United States and other IBM subsidiaries and divisions worldwide to qualified commercial and government clients. Rates are based on a client's credit rating, financing terms, offering type, equipment type and options, and may vary by country. Other restrictions may apply. Rates and offerings are subject to change, extension or withdrawal without notice. IBM is not responsible for printing errors in this document that result in pricing or information inaccuracies. All prices shown are IBM's United States suggested list prices and are subject to change without notice; reseller prices may vary. IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless, our warranty terms apply. Many of the features described in this document are operating system dependent and may not be available on Linux. For more information, please check: Any performance data contained in this document was determined in a controlled environment. Actual results may vary significantly and are dependent on many factors including system hardware configuration and software design and configuration. Some measurements quoted in this document may have been made on development-level systems. There is no guarantee these measurements will be the same on generally-available systems. Some measurements quoted in this document may have been estimated through extrapolation. Users of this document should verify the applicable data for their specific environment. Revised January 19,

42 Special Notices (Cont.) The following terms are registered trademarks of International Business Machines Corporation in the United States and/or other countries: AIX, AIX/L, AIX/L(logo), alphaworks, AS/400, BladeCenter, Blue Gene, Blue Lightning, C Set++, CICS, CICS/6000, ClusterProven, CT/2, DataHub, DataJoiner, DB2, DEEP BLUE, developerworks, DirectTalk, Domino, DYNIX, DYNIX/ptx, e business(logo), e(logo)business, e(logo)server, Enterprise Storage Server, ESCON, FlashCopy, GDDM, i5/os, IBM, IBM(logo), ibm.com, IBM Business Partner (logo), Informix, IntelliStation, IQ-Link, LANStreamer, LoadLeveler, Lotus, Lotus Notes, Lotusphere, Magstar, MediaStreamer, Micro Channel, MQSeries, Net.Data, Netfinity, NetView, Network Station, Notes, NUMA-Q, Operating System/2, Operating System/400, OS/2, OS/390, OS/400, Parallel Sysplex, PartnerLink, PartnerWorld, Passport Advantage, POWERparallel, Power PC 603, Power PC 604, PowerPC, PowerPC(logo), Predictive Failure Analysis, pseries, PTX, ptx/admin, RETAIN, RISC System/6000, RS/6000, RT Personal Computer, S/390, Scalable POWERparallel Systems, SecureWay, Sequent, ServerProven, SpaceBall, System/390, The Engines of e-business, THINK, Tivoli, Tivoli(logo), Tivoli Management Environment, Tivoli Ready(logo), TME, TotalStorage, TURBOWAYS, VisualAge, WebSphere, xseries, z/ OS, zseries. The following terms are trademarks of International Business Machines Corporation in the United States and/or other countries: Advanced Micro-Partitioning, AIX 5L, AIX PVMe, AS/400e, Chipkill, Chiphopper, Cloudscape, DB2 OLAP Server, DB2 Universal Database, DFDSM, DFSORT, DS4000, DS6000, DS8000, e-business(logo), e-business on demand, eserver, Express Middleware, Express Portfolio, Express Servers, Express Servers and Storage, GigaProcessor, HACMP, HACMP/6000, IBM TotalStorage Proven, IBMLink, IMS, Intelligent Miner, iseries, Micro-Partitioning, NUMACenter, On Demand Business logo, OpenPower, POWER, Power Architecture, Power Everywhere, Power Family, Power PC, PowerPC Architecture, PowerPC 603, PowerPC 603e, PowerPC 604, PowerPC 750, POWER2, POWER2 Architecture, POWER3, POWER4, POWER4+, POWER5, POWER5+, POWER6, POWER6+, Redbooks, Sequent (logo), SequentLINK, Server Advantage, ServeRAID, Service Director, SmoothStart, SP, System i, System i5, System p, System p5, System Storage, System z, System z9, S/390 Parallel Enterprise Server, Tivoli Enterprise, TME 10, TotalStorage Proven, Ultramedia, VideoCharger, Virtualization Engine, Visualization Data Explorer, X-Architecture, z/architecture, z/9. A full list of U.S. trademarks owned by IBM may be found at: A full list of trademarks owned by SAP may be found at: UNIX is a registered trademark in the United States, other countries or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries or both. Microsoft, Windows, Windows NT and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries or both. Intel, Intel Xeon, Itanium and Pentium are trademarks or registered trademarks of Intel Corporation in the United States and/or other countries. AMD Opteron is a trademark of Advanced Micro Devices, Inc. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States and/or other countries. TPC-C and TPC-H are trademarks of the Transaction Performance Processing Council (TPPC). SPECint, SPECfp, SPECjbb, SPECweb, SPECjAppServer, SPEC OMP, SPECviewperf, SPECapc, SPEChpc, SPECjvm, SPECmail, SPECimap and SPECsfs are trademarks of the Standard Performance Evaluation Corp (SPEC). NetBench is a registered trademark of Ziff Davis Media in the United States, other countries or both. AltiVec is a trademark of Freescale Semiconductor, Inc. Other company, product and service names may be trademarks or service marks of others. Revised June 15,