VMware has worked together with SAP and its hardware partners like Dell and Fujitsu to validate and test vSphere 7.0 against SAP defined KPIs for virtualized platforms.
These KPIs validate not only performance deviations, but also consistency and operation of a virtualized SAP NetWeaver (AnyDB) and SAP HANA systems on vSphere.
I am very pleased to announce that validation is complete, and VMware vSphere 7.0 is now fully supported for SAP NetWeaver (Linux and Windows) as well for SAP HANA.
For Persistent Memory support please check following blog: SAP HANA with Intel Optane Persistent Memory on VMware vSphere and SAP Note 2913410 – SAP HANA on VMware vSphere with Persistent Memory for details.
In this blog I describe the current support status, available sizes and reference important information for your virtual SAP application deployment on vSphere 7.0.
What’s New?
SAP has granted support for SAP NetWeaver (AnyDB) based products running on Linux and Windows operating systems on any SAP and VMware supported server platforms with vSphere ESXi version 7.0. See SAP notes:
- SAP Note 1122387 – Linux: SAP Support in virtualized environments
- SAP Note 1409608 – Virtualization on Windows
SAP has also granted support for SAP HANA 2 SPS 4 (or later) on vSphere ESXi version 7.0 for Intel Cascade Lake 2-, 4- and 8-socket servers for Scale-Up and Scale-Out deployments.
See SAP notes:
- SAP Note
- SAP Note 2937606 – SAP HANA on VMware vSphere 7.0 in production
The maximum VM size with vSphere 7.0 is 256 vCPUs and 6 TB of memory with up to 4 virtual CPU sockets. This results in SAP HANA VM sizes up to 6 TB for OLTP and 3 TB VM sizes for OLAP workloads with 224 vCPUs on Intel Cascade Lake platforms. The maximum ESXi supported host memory can be up to 16 TB (current vSphere limit) and must follow the hardware vendors memory configuration guidelines.
The minimal supported SAP HANA VM size is 128 GB memory, 8 physical cores (with HT enabled) and 16 vCPUs. SAP NetWeaver / AnyDB VM sizes can be up to 6 TB and 256 vCPUs.
For SAP HANA only up to two SAP HANA VMs can share a CPU socket. This results in following supported configurations per ESXi host for SAP HANA:
Please keep in mind, that the number of SAP HANA VMs depend strongly on the used storage configuration and that the SAP HANA TDI storage KPIs must be met for all SAP HANA production level VMs. Also, no SAP HANA VM support for 1.5, 2.5 or 3.5 CPU socket VM sizes!
The next figure shows multi-VM SAP HANA configurations in more detail by using a 4-socket server CPU architecture picture. Not shown in the picture is a single large 3 or 4-socket spanning SAP HAN VM.
In the SAP NetWeaver case, the described SAP HANA support and configuration restrictions do not exist and more than two SAP NetWeaver VMs can get installed on a CPU socket! Also, there is no minimal VM size for SAP NetWeaver or SAP AnyDB VMs defined. The actual configuration should be based on an SAP CPU and memory sizing (SAP Quick Sizer). The configuration of SAP AnyDB VMs should follow the SAP and database vendor recommendations.
Performance of vSphere virtualized NetWeaver and SAP HANA VMs
During our vSphere 7.0 SAP NetWeaver and SAP HANA validation, different tests were conducted. We used SAP NetWeaver and HANA related benchmarks / tools, to measure virtualization impact on OLTP/OLAP type workloads. We measured NUMA node latencies and we verified typical use cases like massive data load activities.
Overall, the virtualization impact (measured with the SAP public benchmark tools) is below 10% when compared to physical deployed SAP NetWeaver and SAP HANA systems on the same hardware configuration for CPU and memory. Depending on the test case, the virtualization costs can be as low as 3%1 for OLAP (throughput) and 6.5% OLTP (SD-Benchmark2). For sizing purposes, we recommend calculating with 10% virtualization costs. This provides a sizing buffer and eases the sizing calculation for vCPUs.
vSphere allows the deployment of several SAP NetWeaver and or database instances on one host. Only restriction here is a size the VM accordingly the workload memory and CPU requirement and to configure fix resource commitments and to avoid oversubscribing host resources.
Co-deployment of SAP HANA VMs on a single host is also supported, but limited. This can be either one SAP HANA VM per CPU socket (NUMA node) or NUMA node sharing VMs, where it is supported by SAP to deploy two SAP HANA VMs on one NUMA node (NUMA node sharing VM) with vSphere. In the case of NUMA node sharing higher impact on a virtual SAP HANA system was measured.
If you deploy NUMA Node sharing VMs (half-socket VM with 50:50 CPU socket split), then an additional performance impact should be considered and a sizing buffer of at least 15% should get used. One of the reasons for this higher impact is that NUMA sharing VMs share CPU resources like the CPU cache.
1SAP and VMware internal benchmarks. 2public SD benchmarks cert. 2019061 (vSphere 6.7, 298,850 SAPS) vs. cert. 2019042 (physical system, 319,580 SAPS).
Sizing of SAP NetWeaver and SAP HANA VMs:
The sizing of virtual SAP NetWeaver and SAP HANA VMs is similar to bare metal SAP systems, with the limitation of a maximum size of 6 TB and 256 vCPUs per VM and the ESXi resource consumption (memory and CPU costs). Actual VM sizes depend on the used CPUs and number of CPU sockets. For example: On a 4-socket Cascade Lake server only up to 224 vCPUs with up to 6 TB of RAM can get configured per VM.
Which vSphere versions for SAP Applications?
We recommend for SAP applications on vSphere the so called “main editions”, which are: vSphere Standard Edition and vSphere Enterprise Plus.
For SAP production environments a support contract with a minimal production support level with an 24×7 option is highly recommended.
Following document provides an overview of the licensing, pricing, and packaging for VMware vSphere. For VMware support offerings review following page, section “On-Premises Support”.
Which VMware vSphere 7.0 features are supported?
Generally, all VMware vSphere features, like distributed switches are supported. The below listed features got explicitly tested with the usage with SAP HANA, like vMotion, to ensure these features work and that the impact on SAP HANA is known.
Features like VMware FT are not suitable to protect SAP DB VMs (SAP HANA) due to the resource limitations of VMware FT but can get used to protect the ASCS application server instances. Ensure that the SAP workload is suitable for the VMware FT limitations, mainly the latency increase for transactions.
*VMware SRM is an automation tool for disaster recovery and requires data replication via vSphere replication (RPO 5 minutes) or replication with physical storage solutions (RPO <5 minutes possible). VMware SRM based on vSphere replication may get used for SAP application servers but is not recommended for performance critical VMs like SAP HANA database VMs.
One of the major changes in vSphere 7 is a new vMotion (live migration) algorithm. Since vMotion is one of the most used vSphere features, we wanted to make sure that these changes will also have a positive impact for SAP HANA system.
We tested therefore vMotion with vSphere 6.7 and 7.0 SAP HANA VMs while executing a VDM workload that caused a CPU utilization of around 30%. All tests got executed on the same physical hosts configuration. Moving, in our case 4.5 TB large SAP HANA VM, between hosts with vSphere 7 was around 2.5 times faster, and showed a 6 times lower impact on the running workload during a vMotion process as with vSphere 6.7. This test proved that the new enhanced vMotion algorithm has a very positive impact on the vMotion time and much lower impact on the workload.
SAP NetWeaver and SAP HANA VM best Practices and Configuration details:
For SAP NetWeaver (AnyDB) configuration details please check and follow SAP note 2161991 – VMware vSphere configuration guidelines.
To configure an SAP HANA enabled VM for optimal performance it is necessary to align the VM configuration to the underlying HW and especially NUMA configuration.
Conclusion:
We are excited that vSphere 7.0 is by now supported to run and operate all SAP supported applications including SAP HANA in VMware virtualized environments and to continue to provide the benefits of running SAP HANA on vSphere.
Especially the new vMotion algorithm works very good and helps reducing the life migration time by a lower impact on the running workload.
References:
