I recently had the pleasure of attending SAP & ASUG SapphireNow conference in Orlando Florida, where the audience learned that SAP systems now have up to 76% of world GDP running through them. I had many questions about sizing SAP for virtualized environments, which also comes up on a daily basis in the work my team and I do at Nutanix. I realized that nobody has really published anything on this topic since 2013 when Vas Mira from VMware wrote SAP on VMware Design and Sizing Example, which is also still relevant today. But given the changes the IT industry has been through, and the rise of hyper-converged infrastructure (such as Nutanix), it is about time we did a brief review, so you can easily size and successfully deploy your SAP environments virtualized. This article will take you through some of the basic sizing guidelines, including specific considerations for hyper-converged environments.

Before we get into sizing, why would you want to virtualize SAP systems anyway? Some of the most common reasons are as follows:

• Improved availability, even during infrastructure maintenance – updates and refreshes of infrastructure should not have any impact on availability of applications at all
• Improved recoverability, the applications recovery should be easily and predictably tested, without disruption to production, and be repeatable and automated, actual recovery in a disaster can be executed quickly and efficiently
• Rapid, Automated Provisioning – On demand deployment of completely application environments in minutes from templates, ensure consistency and scalability across SAP environments. This capability can greatly improve quality of releases to production in less time, while at the same time allowing dynamic increase in capacity for production environments to handle cyclical peak load demands.
• Simplified driver stack for the operating system reduces complexity and risk for the applications and removes the need to manage storage multi-pathing and network teaming compared to a traditional physical infrastructure.

I have written about these and other aspects in the article covering Nutanix becoming SAP Netweaver certified 2 years ago and there are more details below.

Nutanix: First Hyperconverged Vendor with SAP Certified Platform

However to illustrate some of these advantages it makes it easier to understand if you can see it in action. Here are two quick videos that show some of these benefits with live running SAP systems. The first video covers infrastructure maintenance and upgrades without any SAP application impact.

This second video covers rapid cloning of SAP systems, which only takes just over a minute and doesn’t consume additional storage capacity due to smart modern storage techniques. This allows higher quality releases to get to production faster, with less defects, as they can be more rapidly and accurately tested. It also removes the infrastructure from being a bottleneck to SAP system testing.

SAP Sizing for Virtualized Environments

To keep the sizing examples and process simple there are a number of assumptions. The guidelines don’t apply to every situation, or every SAP product. But they can be used as a general guideline to get a sense of how much infrastructure may be required and how VM’s may be sized if an SAP system were to be virtualized. For new SAP environments it is recommended that qualified system integrators are engaged to ensure proper sizing based on actual business requirements, which may involve a QuickSizer exercise, which can then feed into later virtualization sizing. Where you have an existing physical SAP environment you can use SAP Application Performance Standard (SAPS) from SAP Sales and Distribution (SD) Benchmarks to help. We will use SAPS in the examples here.

When considering virtualizing an SAP system it is important to consider the following:

1. Sizing is not a one time activity, it is a regular activity that needs to be reviewed when SAP systems are being modified to ensure it is always consistent and appropriate capacity planning allows for required growth.
2. Systems are critical and therefore reducing risk and meeting or exceeding application SLA’s are more important than reducing system resource consumption.
3. System resources should not be over allocated for production systems, they should be designed to provide optimal performance and availability even when system maintenance is being conducted, so that there is zero planned infrastructure downtime.
4. Production systems should be sized to run on average at around 65% system utilization, which allows for cyclical peaks to be absorbed without additional resources being added. However, you know your business better than anyone else and should consider your business cycles and peaks of demand in any sizing calculation. If you size for peak period the average will take care of itself. Benchmarks are always at 100% utilization and therefore need to be adjusted when used for sizing.
5. You don’t need to purchase the infrastructure today that you will need in 5 years and leave it idle for 4 years. Virtualization and modern infrastructure allows you to easily and quickly grow and expand your environment as/when needed, this also includes the ability to dynamically add CPU, RAM and storage to running application instances, or to quickly provision new instances. You will achieve are lower TCO and higher ROI by purchasing what you need for the short / medium term and then expanding as/when needed.
6. Leverage your chosen hardware vendors SAP engineering team to help with sizing and deployment guidance. They know how SAP runs best on their platform. They can also review and confirm your sizing, provided you give them the necessary information, such as the QuickSizer reports or EarlyWatch Alert Reports (from Solution Manager).
7. SAPS Values in Virtualized Environments are generally discounted 10% to allow for any performance variances at high utilization levels, this is not required if you use SAPS values from an already virtualized benchmark result for the hardware you plan to use. In many cases, virtualized workloads will perform the same or better than workloads deployed on a native OS on bare metal due to hypervisor scheduling optimizations.
8. When sizing for Hyper-converged infrastructure environment you need to account for the system resources used to provide the storage capabilities, this means discounting available resources by the CPU and RAM required to run the storage controller or hypervisor storage functions. Even if your platform doesn’t use a storage controller VM, it still consumes system resources to provide storage, and those resources need to be considered. In a Nutanix environment, a minimum of 4 Cores and 32GB RAM is assumed to be consumed to each node in the architecture to provide enterprise storage functions, which includes DR/BCP backup, replication and recovery, system management and analytics.
9. Compute resources are usually distributed as 70% allocated to application servers and 30% to database server, but this will depend on the SAP product being deployed. For each “provisioned” 1 vCPU of compute resources, allow for a minimum of 8GB RAM.
10. IO resources are usually 90% allocated to the database and 10% allocated to application servers, but this changes dramatically in an SAP HANA environment. Use this rule of thumb when sizing for traditional databases. IOPS = SAPS x 0.6 for OLTP and SAPS * 0.8 for OLAP. These metrics are only applicable for greenfield deployments. For existing SAP systems, the IO pattern and measurements can be easily derived by observing the reports of the current instances.

What are SAPS?

SAP Application Performance Standard (SAPS) is a hardware-independent unit of measurement that describes the performance of a system configuration in the SAP environment. It is derived from the Sales and Distribution (SD) benchmark, where 100 SAPS is defined as 2,000 fully business processed order line items per hour. In technical terms, this throughput is achieved by processing 6,000 dialog steps (screen changes), 2,000 postings per hour in the SD Benchmark, or 2,400 SAP transactions.

Because the benchmark is hardware-independent it can be used to calculate sizing from Unix systems to X86 when considering a system platform migration. It is also useful when considering non-SAP applications because it provides a relative performance metric between dissimilar systems. It is widely used by many different system vendors and provides consistency in the method of measuring performance.

SAPS benchmarks are available for 2 tier and 3 tier application configurations from the following location:

• SD Benchmark 2 Tier Results
• SD Benchmark 3 Tier Results

Nutanix has an SAP certified SD 2 Tier Benchmark that can be referenced for sizing.

Certified and published benchmarks are always on supported platforms from certified and supported SAP system vendors. This means that SAP customers can rely on the support of both SAP and the vendor publishing the benchmark for their critical systems.

Benefits of using SAPS include:

• Allow users to compare different platforms
• Enable Proof-of-concepts scenarios
• Provide an outlook for future performance levels (new platforms, new servers, etc.)
• Provide basic information to configure and size SAP Business Suite
• Baseline QA

Using SAPS for a Simplified Sizing Calculation

For arguments sake, lets use the Nutanix Certified 2 Tier benchmark for sizing an SAP production system that needs 140,000 SAPS @ 65% utilization.

Firstly, we need to discount the benchmark SAPS value by 10% as it was done on bare metal to allow for a virtualized SAPS number. This suggests that at 100% utilization virtualized the hardware platform (8150-G5) can support 94K SAPS.

To get the SAPS per core we divide the value by the number of cores, in this case 44. This gives us 2140 SAPS per Core at 100% utilization.

To get the SAPS per core at 65% utilization, we need to multiple the SAPS per core by 0.65. This gives us ~1400 SAPS per core (SAPS / Cores, in this case 44 cores per server) at 65% utilization. Note: These numbers used have been selected to make the calculations easy.

If our SAP system requires 140K SAPS and we get 1400 SAPS per core, we know that we’ll need 100 CPU cores. We also know from this we will require 800GB RAM (8GB per CPU Core). Remember, this is a production instance, so we assume 1 vCPU = 1 core. Based on 1400 SAPS per core, we can calculate how many SAPS the NX8150-G5 can do at 65% utilization, which is ~61K SAPS. However we need to reduce this by the resources that will be consumed by the storage controller, which is 4 cores. This leaves us with 56K SAPS at 65% utilization per NX8150-G5. Immediately we can tell that we will need 3 x NX8150-G5 to cover the workload (140K / 56K and round it to nearest whole number), and at least 1 for failover and maintenance capacity (N+1 design), so we would use 4 x NX8150’s for the environment.

Now, we can allocate the resources between app servers and database servers based on the above calculations. Assuming the split of 70/30 between app servers and database we will use 70 CPU cores for app servers and 30 CPU cores for database. The Database server will be configured with 240GB RAM at least (probably 256GB). App servers could be configured with 4 vCPU and 32GB RAM, and to cover the requirements we would deploy 18 app server VMs (72 cores in total). ASCS with 1 vCPU, 8GB RAM, and other AD or utility servers will also be supported in the environment. Why do we split apps into multiple instances over multiple VMs? Because it helps in getting better performance out of your virtual environment by scheduling compute resources more efficiently and even for SAP, having multiple smaller instances instead of 1 large application instance helps in better CPU context switching in the work processes and eventually, lower compute overheads. You can refer to SAP Note 9942 for a detailed explanation on this.

With 512GB RAM per NX8150-G5 node in this environment it would have sufficient resources for the current workload and room for additional growth, while being able to allow for non-disruptive maintenance and recover in the event of component failures.

From an IO perspective, assuming this is an OLTP environment, the Database will require 90% of the IOPS at 0.6 x SAPS, which is ~76K IOPS, which is easily achievable from the proposed configuration.

Remember that the above sizing is only an example for 1 SAP Netweaver based product production instance requiring 140K SAPS to operate. Typical SAP environments have a 3-system landscape (Dev, QA, Production) with their respective workload profiles, a mandatory 1 Solution Manager instance at a minimum and other SAP and non-SAP products to support the SAP environment ecosystem.

Some Sizing Gotchas

For SAP QuickSizer, the SAPS are already adjusted to 65% utilization. So you don’t need to reduce the SAPS per server based on the benchmarks. Don’t make the mistake a lot of people do and double discount. It will mean your utilization from your system will be extremely low and you will not have an optimal ROI.

SAP EarlyWatch Alert Reports show actual system utilization and system metrics. They are one of the most useful tools for sizing new platforms for existing environments. If SAP EarlyWatch Alert Reports are not available you can use ST03N, ST06 and DBACOCKPIT transactions in the SAP system to find out the system metrics. Some systems, especially SAP JAVA based systems will require additional tools and information, to size them.

With better information, your sizing can be more accurate, and therefore you may be able to size for less physical resources, and provide a better TCO and ROI. The lesser the information, the more conservative the sizing needs to be. Virtualize but without compromise, this is required for critical systems and may be different to how dev/test systems have been handled in the past.

At least some non-prod systems will require 100% of prod resources to allow for accurate reproduction of performance expected in the prod systems. Usually this is QA or Perf environment. Other dev, test and training environments may not require the same level of resources. Once you know the resources or relative resources per landscape you can calculate the total systems required. My experience has shown there can be between 2 and 13 landscapes per product (where a landscape is an environment, such as dev, test, QA, training, support, prod etc).

Going from Non-Unicode to Unicode system will require more resources, assume at least 1.5x the resources in terms of storage capacity, CPU and RAM.

Additional Resources

VMware SAP Best Practices Guide

Nutanix is a SAP Global Technology Partner 

SAP on Nutanix Support / Certification OSS Notes:

1122387 – Linux: SAP Support in Virtualized Environments

2428012 – SAP on Nutanix

Nutanix SAP Resources Web Page

SAP Support Platforms Page

SAP on Win Certification Site

Virtualizing SAP on Nutanix Tech Note

Nutanix and SAP HANA

Final Word

SAP has supported virtualization for production systems since 2007 and most customers are choosing to virtualize their systems to yield some of the benefits explained in this article. It is critically important however that the design and implementation of the virtualized environment is done such that it is verified and tested against the business requirements, including performance, availability, failure scenarios, and that resources are not over allocated and cause unnecessary support incidents. Virtualize without compromise, and when in doubt, seek assistance from your vendor’s SAP teams. Thanks to Kasim Hansia from Nutanix for his constant support with all things SAP & Databases over the years that we’ve been working together, and to our entire SAP engineering team at Nutanix that help our customers implement successful solutions for the critical applications all over the globe.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2017 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.