VMware SAP sizing

VMware SAP Sizing
There are multiple blog articles from vmware and others about it but i quickly wanted to summarize it here. The credit goes to go BSN for helping me to understand this better. The first things that we have to read are Sap Solutions on VMware Best Practises Guide, Sap Hana on VMware and there are multiple vmware blogs for the same.


Step 1 – Have the number of SAPS required for different modules ready with you. This means, there is no sizing calculator designed by VMware or designed for VMware. The SAP sizing has to come from the official SAP sizer designed by SAP or one of the server OEMs.

Step 2 – Based on some standard benchmarks done (which are published) by various
hardware vendors a few years back, we have arrived at the following ratio. For every 1000 SAPS required, configure 1 vCPU. For every 200 SAPS, configure 1 GB of RAM. Note that these are arrived at assuming 70% utilization, so are already very conservative. DO NOT ADD ANY MORE BUFFERS TO THIS AND MAKE THE SIZING ULTRA CONSERVATIVE & HENCE UNREALISTIC. Let’s take an example. If the SAPS required are 13400, it needs 13.4 vCPUs, rounded off to 14. RAM would be 67 GB.

Step 3 – After arriving at the no. of vCPUs & vRAM, we need to calculate the number of virtual machines. This again would depend on whether it is DB or App. If it is for DB, normally we do not divide it into multiple VMs. Unless you are using something like Oracle RAC. It is usually scale up within a single box in the traditional physical environment. The same logic applies in the virtual world too. If it is a DB VM, design it as a single VM with 14 vCPUs & 67 GB RAM. If it is for App, you could divide it into two, three or four VMs depending on how many hosts you have. It is generally a good practice to spread an App server VM on every ESXi host for HA purposes.

Step 4 – According to SAP, neither CPU nor memory over-commitment is supported (though it works perfectly). So we have to make sure that the total no. of vCPUs does not exceed the no. of logical CPUs on a given physical ESXi host. For ex., if we are using a 4 CPU 8-core server, without hyper-threading enabled, we would have 32 logical CPUs, with hyper-threading enabled it would be 64 logical CPUs. Using hyper-threading is encouraged & also supported by SAP. So on this host, the maximum no. of vCPUs configured should not exceed 64. On the memory front, it is fine to go close to 85-90% memory utilization of the host.

Step 5 – What about the clock speed of CPUs to be used? Generally speaking, in a virtual environment, the clock speed does not matter much. Instead the no. of cores makes a difference. To re-phrase the same, higher no. of cores helps in achieving higher no. of VMs on a host while higher clock speeds help in better application performance. However, this has to be taken with a pinch of salt. There are few applications that benefit with a higher clock speed. SAP is one of them. Use as high clock speeds as possible.

Step 6 – HA has to be planned properly. If one of the hosts fails, the number of vCPUs & vRAM configured on that host should be available as spare capacity on other hosts in the cluster.

Step 7 – Finally, it is good to refer to some of the published benchmarks on the SAP site to verify if our sizing is correct. For ex. According to one of the benchmark results, we could achieve 25000 SAPS on a 2-socket, 6-core server using a 3.4 GHz CPU with 96 GB RAM. The sizing we have done should be closer to this.

If you want to do the sap sizing the using sap quicksizer then you might have to get access to (this is done by a sap professional)





Leave a comment