Home > Workload Solutions > SAP > Guides > Dell Ready Bundle for SAP with Unity Storage > Sizing and performance
Sizing considerations for SAP landscape design
Business and technology considerations influence the sizing of the hardware infrastructure. When planning to use Dell EMC infrastructure, work with Dell EMC representatives to determine a solution design that includes business requirements for performance, response times, availability, data protection, and DR for the SAP systems.
Table 8 describes the sequence of steps that are involved in sizing the infrastructure requirements for your Ready Bundle for SAP Landscapes solution.
Table 8. Infrastructure sizing steps
Step | Activity | Performed by |
1 | Determine the number of SAP production systems you need. | Dell EMC completes these steps when collecting your business requirements.
|
2 | Define the SAP system landscapes. Typically, each SAP production system (ERP, BW, CRM, and so on) has its own SAP system landscape, consisting of a DEV, QAS, SBX, and PRD environment. | |
3 | Determine if virtualization is to be used. | |
4 | Determine the HA requirements. | |
5 | Determine the DR requirements and the number of data centers or sites involved. | |
6 | Consider data protection requirements for backing up the SAP systems. | |
7 | Determine an expected annual data growth and the number of years’ maintenance required. | |
8 | Size each of the SAP systems and system landscapes using the SAP Quick Sizer tool on your production systems. | You complete this step and then provide the results to Dell EMC. |
9 | Calculate the total compute requirements and determine the number and models of servers (CPU/memory/storage) that are required to support the workloads. | Dell EMC completes these steps using the information that you provided in step 8.
|
10 | Calculate the total storage requirements, based on capacity or IOPS or both, and use the Unity Sizer tool to determine the model and size of the Unity storage system. | |
11 | Determine the backup capacity requirements for Data Domain. |
SAP Quick Sizer
SAP Quick Sizer is a web-based tool that calculates hardware requirements. The tool bases its calculations on functional parameters such as the number of users working with the different SAP application systems, throughput, and other inputs.
SAP has identified different and independent sizing models with different advantages and disadvantages. The Quick Sizer tool incorporates both of the following sizing models:
Quick Sizer presents the results in SAPS. Hardware vendors provide their SAPS for a particular server configuration by running SAP Benchmark tests and posting the results on the SAP website. For more information about SAPS sizing, see the SAP Quick Sizer documentation.
SAPS is a hardware-independent unit of measure that describes the performance of a system configuration in the SAP environment. It is derived from the SD benchmark, where 100 SAPS is defined as 2,000 fully business-processed order line items per hour.
In the SD benchmark, fully business-processed means the full business process of an order line item, as follows:
This throughput is achieved by processing 2,400 SAPS transactions, 6,000 dialog box steps (screen changes), or 2,000 postings per hour in the SD benchmark. SAPS is divided into requirements for the database layer (database SAPS) and application layer (application SAPS). Database SAPS are more relevant for sizing your storage requirements.
Using SAPS for sizing
The design approach for this Ready Bundle for SAP Landscapes solution uses the published SAPS values for the PowerEdge R940 and R740/R740xd servers based on official SAP SD Standard Application Benchmark Results. The certifications are based on high-performance Intel Xeon Platinum 8180 processors. Dell EMC performed internal testing with Standard Performance Evaluation Corporation (SPECint) benchmarks to extrapolate and determine values for SAPS and SAPS per core. Calculations are for all platinum, gold, silver, and bronze processors available in the R940 and R740/R740xd PowerEdge server range. You can calculate server sizing and storage capacity requirements by using the output from SAP Quick Sizer projects and the chosen R940 or R740/R740xd PowerEdge server model by using the SAPS values.
Table 9 provides details of certified SAPS values for PowerEdge servers. For a full list of PowerEdge R940 and R740/R740xd systems with extrapolated SAPS values, see Appendix: SAPS values for PowerEdge R940 and R740/R740xd.
Table 9. SAPS values for PowerEdge servers
PowerEdge server (CPU model) | Number of cores | Number of sockets | Number of cores per socket | Certified SAPS | SAPS per core |
PowerEdge R940 (Intel Xeon Platinum 8180, 2.50 GHz) | 112 | 4 | 28 | 341,100 | 3,046 |
PowerEdge R740 or R740xd (Intel Xeon Platinum 8180, 2.50 GHz) | 56 | 2 | 28 | 175,230 | 3,129 |
Note: The Quick Sizer tool bases calculations on 65 percent utilization. Therefore, additional calculations to account for overhead are not required to achieve predictable server behavior. You can compare your Quick Sizer SAPS result with existing certified benchmark results. However, you can expect a 10 percent performance degradation in virtualized environments.
Greenfield and brownfield sizing
We use the SAP QuickSizer tool to estimate greenfield (new) sizing for SAP standard solutions if you are planning either of the following:
We use brownfield (post-go-live) sizing if you are currently running SAP but want to expand your hardware capacity or introduce new infrastructure. For brownfield sizing, we collect data and metrics from the system on the existing hardware and use the information to extrapolate sizing as follows:
Interpreting Quick Sizer results
This section provides information about how to interpret Quick Sizer results for CPU, disk, disk I/O, and memory requirements.
Sizing the CPU for database and application servers
CPU sizing results provide requirements for the relevant layers, primarily the database layer and the ABAP application layer. The results are specified in SAPS, which, in CPU terms, is a performance unit that describes the throughput power of a server. Two‑thousand fully business-processed order line items per hour equates to 100 SAPS. If a customer provides the total SAPS requirement but not the breakdown between database SAPS and application SAPS, we apply general rules for the ratio of database SAPS to application SAPS:
Disk sizing is the general sizing determined for the database by the SAP Quick Sizer tool, using the following assumptions:
Some factors that might influence disk size, such as small tables, indexes, backups, dumps, and exports, are not considered or are considered only as exceptions. Calculating disk I/O is linked to database SAPS based on the analytical or transactional consumption of SAPS and disk I/O.
The following general rule applies for translating SAPS to IOPS:
Note: Disk space calculations from Quick Sizer are for database space only. Also, consider storage sizing for the operating system, swap, database software binaries, and SAP software binaries on each host.
Sizing the system memory
If a customer does not provide a memory size result from the SAP Quick Sizer project, we use the following general rule from the SAPS requirement: estimate 3 GB of memory for every 1,000 SAPS in most throughput-based sizing.
Note: Quick Sizer results are assumption-based estimates. Contact Dell EMC to obtain solution sizing for your specific requirements.
Single system versus system landscape considerations
Quick Sizer results are for a single application system. Sizing for SAP must be performed against a system landscape rather than a single system for each application that is implemented. A basic SAP system landscape comprises at least three systems: PRD, QAS, and DEV. Many customers have up to five or seven systems per SAP application, which can result in a high number of systems in a landscape, with each system demanding resources.
Virtualization sizing considerations
VMware has provided a direct comparison between virtualized and bare metal systems with the same hardware configuration and the same SAP benchmark workload. The overhead is less than 6 percent. When sizing a virtualized SAP system or landscape with VMware vSphere, consider an overhead of 10 percent. Therefore, if you are using VMware virtualization, you can calculate the virtual SAPS as 90 percent of the certified server SAPS value. In addition, follow these guidelines:
The maximum number of vCPUs in VMware is 128 for a single VM, which might limit the SAPS value that is achievable in a single VM.
For more information, see the following documents:
High availability
With a VMware ESXi cluster, you define two or more physical machines that are to provide resources for the hosts (or resource pools) that are assigned to the cluster. You can achieve HA and load balancing of VMs with vSphere DRS by using ESXi clusters. Both these features use the vSphere vMotion tool to move these virtual guests from one physical host to another.
When you size clusters, the amount of spare compute resources that you require depends on the number of physical hosts in the cluster. Spare compute resources must be available to take over the workload for at least one physical host in the cluster to ensure continuous availability.
Disaster recovery and multisite data centers
Failure and downtime of mission-critical SAP environments can bring an entire organization or large parts of it to a halt. The business costs associated with SAP downtime can be high. If your primary site suffers a disaster such as flooding, fire, or a major earthquake, the DR plan must have your normal operations up and running in as short a recovery time (recovery time objective, or RTO) as possible and with minimal data loss (recovery point objective, or RPO).
With multisite data centers, the secondary site must have enough available compute, network, and storage resources to take over the workloads from the failed site. Therefore, the compute, network, and storage requirements are doubled when you size for DR.
Sizing for future database growth
SAP systems will grow year on year over time, affecting the size of the database and the number of users. Dell EMC recommends factoring an annual growth rate into the sizing of the storage requirements over the term of the maintenance support for the infrastructure.
For example, if a database sizing is 600 GB and you expect an annual growth rate of 8 percent with maintenance for 4 years, calculate the requirement as follows:
600 GB x 1.08 x 1.08 x 1.08 x 1.08 = 816 GB
Sizing example
The following sizing example uses sample customer inputs to show how you can determine compute and storage requirements for SAP landscapes.
A customer has three PRD systems: ERP, CRM, and BW. Each system has a system landscape consisting of DEV, QAS, and SBX non-PRD systems. Based on its Quick Sizer projects, the customer provided the information in Table 10 for each PRD system.
Table 10. Customer inputs from a Quick Sizer project
Application | Application type | Total SAPS | Disk size (GB) |
ERP | OLTP | 96,000 | 4,000 |
CRM | OLTP | 32,000 | 1,000 |
BW | OLAP | 60,000 | 2,000 |
The customer uses VMware virtualization for server consolidation and HA.
The customer advised that the quality system should be sized the same as production, with a VMware CPU overcommit factor of 2. Both the DEV and SBX system should be sized at 50 percent of production, with a VMware CPU overcommit factor of 4.
A Data Domain system is included for data protection and backups. The annual growth forecast is 7 percent with a maintenance term of 4 years.
Table 11 shows the SAP landscapes that we derived from the customer inputs.
Table 11. SAP landscapes and customer inputs from Quick Sizer
System | Application | Type | Description | SAPS | Disk size | Annual disk growth |
BM1 | ERP | OLTP | PRD | 96,000 | 4,000 | 7% |
QM1 | ERP | OLTP | QAS | 96,000 | 4,000 | 7% |
DM1 | ERP | OLTP | DEV | 48,000 | 2,000 | 7% |
SBX | ERP | OLTP | SBX | 48,000 | 2,000 | 7% |
CRM | CRM | OLTP | PRD | 32,000 | 1,000 | 7% |
CRQ | CRM | OLTP | QAS | 32,000 | 1,000 | 7% |
CRD | CRM | OLTP | DEV | 16,000 | 500 | 7% |
CRS | CRM | OLTP | SBX | 16,000 | 500 | 7% |
BWP | BW | OLAP | PRD | 60,000 | 2,000 | 7% |
BWQ | BW | OLAP | QAS | 60,000 | 2,000 | 7% |
BWD | BW | OLAP | DEV | 30,000 | 1,000 | 7% |
BWS | BW | OLAP | SBX | 30,000 | 1,000 | 7 % |
Sizing the compute requirements
We used the inputs from Table 11 to calculate the compute and memory requirements, as shown in Table 12.
Table 12. CPU and memory calculations for each system in the landscapes
System | SAPS (input) | Database | Application SAPS1 | VMware CPU over-commit factor | Database SAPS (with VMware overcommit) 2 | Application SAPS | Database memory (GB) 3 | Application memory (GB)3 | Number of application servers1 |
BM1 | 96,000 | 19,200 | 76,800 | 1 | 19,200 | 76,800 | 57.6 | 230.4 | 5 |
QM1 | 96,000 | 19,200 | 76,800 | 2 | 9,600 | 38,400 | 57.6 | 230.4 | 5 |
DM1 | 48,000 | 9600 | 38,400 | 4 | 2,400 | 9,600 | 28.8 | 115.2 | 2 |
SBX | 48,000 | 9600 | 38,400 | 4 | 2,400 | 9,600 | 28.8 | 115.2 | 2 |
CRM | 32000 | 6,400 | 25,600 | 1 | 6,400 | 25,600 | 19.2 | 76.8 | 3 |
CRQ | 32,000 | 6,400 | 25,600 | 2 | 3,200 | 12,800 | 19.2 | 76.8 | 3 |
CRD | 16000 | 3,200 | 12,800 | 4 | 800 | 3,200 | 9.6 | 38.4 | 1 |
CRS | 16,000 | 3,200 | 12,800 | 4 | 800 | 3,200 | 9.6 | 38.4 | 1 |
BWP | 60,000 | 20,000 | 40,000 | 1 | 20,000 | 40,000 | 60 | 120 | 3 |
BWQ | 60,000 | 20,000 | 40,000 | 2 | 10,000 | 20,000 | 60 | 120 | 3 |
BWD | 30,000 | 10,000 | 20,000 | 4 | 2,500 | 5,000 | 30 | 60 | 1 |
BWS | 30,000 | 10,000 | 20,000 | 4 | 2,500 | 5,000 | 30 | 60 | 1 |
1 Ideally, the customer provides a breakdown of the database and application SAPS from a Quick Sizer project. Otherwise, we apply a general rule to calculate the ratio of database SAPS to application SAPS using total SAPS. For OLTP, we use 1:4 and for OLAP we use 1:2.
2 The database and application SAPS values for each system are adjusted to include the VMware CPU overcommit factor.
3 To calculate the required memory for each database and application server, we use the general rule for throughput-based sizing, where we estimate 3 GB of memory for each 1,000 SAPS. We calculate this memory against the SAPS values without the CPU overcommit factor.
Note: In virtual environments, do not overcommit memory for SAP PRD and non-PRD systems.
Using the customer inputs in Table 10, we calculated the total SAPS and memory requirements. Table 13 shows the results of our calculations.
Table 13. Total compute requirements
Total database SAPS | Total application SAPS | Total SAPS | Total database memory | Total application memory | Total memory |
79,800 | 249,200 | 329,000 | 410.4 | 1,281.6 | 1,692 |
To calculate the number of physical servers that are required, we compared our total compute requirements with the recommended processing performance for each SAPS value and the memory of the chosen server models.
Additional compute resources for HA are included. Therefore, if a server is lost, sufficient resources are available to take over the failed server workloads.
In this example, we calculated the result using both the PowerEdge R940 and PowerEdge R740/R740xd models. Table 14 shows the physical compute requirements for the solution using the R940 server on each site.
Table 14. Physical compute requirements with the PowerEdge R940 server
Total SAPS required | Total memory required | Virtual SAPS | Cores | RAM | Number of servers SAPS bound2 | Number of servers memory bound3 | Number of servers required4 | Number of servers required with HA5 |
329,000 | 1,692 | 306,990 | 112 | 768 | 2 | 3 | 3 | 4 |
1 In this sizing example, we are using PowerEdge R940 servers with 768 GB of RAM.
2 The PowerEdge R940 has the capabilities of up to 306,990 virtual SAPS, and the SAPS requirement in the example is 329,000. Therefore, two servers are needed to satisfy the requirement.
3 The PowerEdge R940 server in the example has 768 GB of RAM and the compute requirement is 1,692 GB of RAM. Therefore, three servers are needed to satisfy the requirement.
4 The higher value of 2 and 3 is the number of servers required.
5 We added a server to the value of 4 for HA.
Table 15 shows the physical compute requirements for the solution using the R740 or R740xd server on each site.
Table 15. Physical compute requirements with the PowerEdge R740 or R740xd server
Total SAPS required | Total memory required | Virtual SAPS | Cores | RAM | Number of servers SAPS bound2 | Number of servers memory bound3 | Number of servers required4 | Number of servers required with HA5 |
329,000 | 1,692 | 157,707
| 56 | 384 | 3 | 5 | 5 | 6 |
1 In this sizing example, we are using PowerEdge R940 servers with 384 GB of RAM.
2 The PowerEdge R940 has the capabilities of up to 157,707 virtual SAPS, and the SAPS requirement in the example is 329,000. Therefore, three servers are needed to satisfy the requirement.
3 The PowerEdge R940 server in the example has 384 GB of RAM and the compute requirement is 1,692 GB of RAM. Therefore, five servers are needed to satisfy the requirement.
4 The higher value of 2 and 3 is the number of servers required.
5 We added a server to the value of 4 for HA.
Sizing storage requirements
Table 16 presents the storage requirements for each production and nonproduction SAP system.
Table 16. Customer storage requirements
System | Disk size | DB disk final size | Database SAPS (with VMware overcommit) | IOPS (calculated)2 | Number of app servers | Total operating system size (GB)3 | Total .exe file size (GB)3 | Dump size | Total storage require- |
BM1 | 4,000 | 5,243 | 19,200 | 11,520 | 5 | 768 | 768 | 5,243 | 12,022 |
QM1 | 4,000 | 5,243 | 9,600 | 5,760 | 5 | 768 | 768 | 5,243 | 12,022 |
DM1 | 2,000 | 2,622 | 2,400 | 1,440 | 2 | 384 | 384 | 2,622 | 6,012 |
SBX | 2,000 | 2,622 | 2,400 | 1,440 | 2 | 384 | 384 | 2,622 | 6,012 |
CRM | 1,000 | 1,311 | 6,400 | 3,840 | 3 | 512 | 512 | 1,311 | 3,646 |
CRQ | 1,000 | 1,311 | 3,200 | 1,920 | 3 | 512 | 512 | 1,311 | 3,646 |
CRD | 500 | 655 | 800 | 480 | 1 | 256 | 256 | 655 | 1,822 |
CRS | 500 | 655 | 800 | 480 | 1 | 256 | 256 | 655 | 1,822 |
BWP | 2,000 | 2,622 | 20,000 | 18,000 | 3 | 512 | 512 | 2,622 | 6,268 |
BWQ | 2,000 | 2,622 | 10,000 | 9,000 | 3 | 512 | 512 | 2,622 | 6,268 |
BWD | 1,000 | 1,311 | 2,500 | 2,250 | 1 | 256 | 256 | 1,311 | 3,134 |
BWS | 1,000 | 1,311 | 2,500 | 2,250 | 1 | 256 | 256 | 1,311 | 3,134 |
1 Future database disk size = disk size x annual growth of 7 percent over 4 years
2 From calculation of database SAPS based on the analytical or transactional consumption of SAPS. See Sizing the disk and disk I/O. Disk I/O for OLTP applications = 60 percent of database SAPS. Disk I/O for OLAP applications = 90 percent of database SAPS.
3 128 GB disk capacity for operating system and 128 GB for .exe file on each DB and application server of a system
4 Storage capacity for a database dump, exports, or logs
5 Sum of the DB final disk size + operating system size + .exe file size + dump size values per system.
Table 17 presents the total storage requirements.
Table 17. Total SAP storage requirements
SAP Landscapes | Storage (GB) | IOPS |
Total SAP systems | 65,805 | 58,380 |
We use the storage and IOPS totals in the Unity Sizer tool to determine the model and configuration of the Unity All Flash array.