Simplified Sizing for Virtualizing SAP

Environments
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.

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.

Video on link https://youtu.be/6B9d3JXXAHg

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.

Video on link https://youtu.be/qrzPwsQ3ymg

 
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.

About the Author

Michael Webster
Michael is Technical Director, Business Critical Applications Engineering at
Nutanix. He has been using VMware products since 1998 and has been deploying
ESX solutions since 2002. He specializes in designing virtualization solutions for
Unix to Linux migrations, business critical applications, disaster avoidance, and
mergers and acquisitions. Michael has been in the IT industry since 1995 and
consulting since 2001. Michael is Nutanix Platform Expert (NPX) #007. In addition
to VMware Certified Design Expert (VCDX) he holds VCP, VCP-Cloud, VCAP-DCD,
VCAP-DCA, VCAP-CID, VCAP-CIA, ITIL Foundation, MCP I, and MCSE (NT4 – 2K3).

Ref: http://longwhiteclouds.com/2017/06/11/simplified-sizing-for-virtualizing-sap-environments/

Other Tips

1 Core is approx = 2000 SAPS

and 1 GB RAM = 400 SAPS

You can use this information to calculate the approx SAPS rating of your server.