This article will describe the sizing of virtual machines running SAP HANA on Red Hat Virtualization. The article is organized into two parts. Part 1 provides some sizing background and virtual concepts. Part 2 will cover an actual example of sizing a SAP HANA virtual machine with respect to CPU and memory. Thanks to the following Red Hat colleagues for their inputs/reviews: Arne Arnold; Steffen Froemer; Nils Koenig; Chuck Mattern; Martin Tessun.
Red Hat Virtualization (RHV) is an enterprise virtualization platform that supports resource-intensive virtualization workloads, built on Red Hat Enterprise Linux and KVM and fully supported by Red Hat. SAP has certified RHV as a supported hypervisor for SAP HANA workloads.
The SAP sizing methodology is described by SAP at https://www.sap.com/about/benchmark/sizing.html – the process and guidelines defined here equally apply to virtual environments. Sizing involves determining hardware requirements such as memory, CPU, disk space, I/O capacity, and network bandwidth.
Sizing is a collaborative effort between the hardware vendor, the customer and SAP. The customer is responsible for defining the business requirements (e.g. number of users, business transaction volumes , etc). SAP defines multiple sizing scenarios / types. Two of the types include:
- Greenfield – typically used for new implementations. For this type SAP provides a sizing tool called Quick Sizer. Quick Sizer is a web-based tool developed by SAP in close cooperation with all technology partners. With Quick Sizer you can translate business requirements into technical requirements.
- Brownfield – this can refer to an upgrade, delta or migration sizing. This includes migrating an existing SAP Netweaver system to SAP HANA or S/4HANA. The outcome of a SAP HANA migration sizing project will generate technical requirements for the target SAP HANA environment.
The output of the greenfield and brownfield sizing project will generate technical requirements which the hardware vendor can use to determine target server specification and number of servers required. Once the exact specification of the target server is known (e.g. model number, number of sockets, cores per socket, etc) it is possible to estimate the configuration of the SAP HANA virtual machine with respect to memory and CPU.
The following diagram shows an overview of the sizing process.
We will cover some terminology and concepts that impact the sizing of the virtual machine (VM). First some terminology:
- virtual CPU (vCPU) – this is the CPU assigned to a virtual machine. A vCPU is a scheduling context that is executed on a core of a physical CPU. A VM running SAP HANA will have multiple vCPUs.
- virtual memory – this is the memory /RAM configured for the virtual machine.
- “SAPS” – stands for SAP Application Performance Standard . SAPS is a hardware-independent unit of measurement that describes the performance of a SAP system. It is derived from the Sales and Distribution (SD) benchmark and is a measure of transaction throughput. SAP CPU sizing is conducted in SAPS.
- Simultaneous multithreading (SMT) allows multiple independent threads of execution within a processor core to improve parallelization of compute instructions that can boost performance of workloads. Hyper-threading is Intel’s proprietary version of SMT. We will use the term hyper-threading (HT) in this article. With HT enabled on each physical processor core, the KVM hypervisor addresses two logical CPU/cores and shares the workload between them when possible. Please note the following quoted from SAP note 2852117: “Before enabling hyperthreading, consider security risks and how they apply to your setup. For more information, see https://access.redhat.com/security/vulnerabilities/mds “.
The processing power / SAPS throughput of the virtual machine depends on how the vCPUs are scheduled on the cores in relation to the hyper-threading feature of the X86 server. We will demonstrate vCPU scheduling of the virtual machine and processing impact in three scenarios. The three scenarios have been chosen to demonstrate the following concepts:
- How hyper-threading benefit is achieved by a VM
- Scenario 1 to Scenario 2 shows how increasing the vCPUs of a VM to use all the logical CPUs of the physical cores provides an increase in performance
- There are two ways to configure the vCPUs of a VM to provide the same SAPS throughput from a sizing standpoint
- Scenario 2 and Scenario 3 show a VM with a different number of vCPUs scheduled in different ways on the physical cores – both scenarios provide the same SAPS.
Scenario 1 – 8 vCPU virtual machine on 8 cores
In this scenario we have a virtual machine with 8 vCPUs and each vCPU is scheduled on a logical CPU on a dedicated physical core with exclusive access to core resources. With HT each core presents two logical CPUs to KVM so not all the processing power of the core is being utilized. There are 8 free logical CPUs.
Scenario 2 – 16 vCPU virtual machine on 8 cores
In this scenario we have a virtual machine with 16 vCPUs that are scheduled on all the logical CPUs of the 8 physical cores. This provides more processing power versus scenario 1 – the performance boost for SAP workloads is about 30% (source: Deploying SAP HANA on Red Hat Virtualization guide). This scenario is referred to as virtual machine hyper-threading on. It is expected that the HT benefit is limited i.e not doubled as the logical processors in a hyper-threaded core share the execution resources.
Scenario 3 – 10 vCPU virtual machine on 10 cores
This scenario shows a virtual machine with 10 vCPUs and each vCPU is scheduled on a logical CPU on a dedicated core. The processing power / SAPS throughput of this scenario is approximately similar to scenario 2. Here is why:
- Processing power of 16 vCPUs on 8 cores is approximately equivalent to: 8 x 1.22 cores = about 10 vCPUs on 10 cores. The 1.22 scaling factor/ 22 % increase in cores is calculated in the sizing example that will be shown in part 2 (and is derived from sizing guidelines in the Deploying SAP HANA on Red Hat Virtualization guide)
When designing virtual machines we have the option of sizing the vCPUs like scenario 2 or 3. Both scenarios provide the same SAPS throughput . The following table summarizes the differences.
In Part 1 of this article we have covered some sizing background and virtual concepts that impact sizing of VMs. In Part 2 we will show a sizing example of a SAP HANA VM based on requirements generated by the HANA Quick Sizer tool.