I’m excited to announce SAP support for SAP HANA 2.0 virtual machines with up to 16 TB of memory on 8-socket systems powered by 4th Gen Intel® Xeon® Scalable processors (Sapphire Rapids) Glued and Non-Glued architectures. Please refer to SAP note 3372365 – SAP HANA on VMware vSphere 8 for full details.
This marks a significant milestone for Broadcom and our hardware partner Lenovo, who provided two Lenovo ThinkSystem SR950 V3 servers, each equipped with 16 TB of memory, for this validation. With this, customers running on-premises or in SAP partner-managed datacenters can now fully virtualize SAP HANA systems up to 16 TB and 768 vCPUs using VMware vSphere 8.0 U3, without compromising SAP HANA database size, performance, reliability, or security.
This validation doubles the previously supported maximum for SAP HANA on the Sapphire Rapids (SPR) platform, increasing from 8 TB on a 4-socket system to 16 TB on an 8-socket system.
As with the 4-socket configuration, half-socket deployments, where two SAP HANA VMs share a NUMA node, are also supported on 8-socket systems and position this system as an ideal platform not only for large Scale-Up SAP HANA systems but also as a consolidation platform for up to 16 SAP HANA VMs with the appropriate storage and network available.
Supported Standard VM Configurations (based on vSphere 8 maximums with maximal 768 vCPUs):
- Smallest supported SAP HANA VM:
“0.5 CPU socket” | 8 cores | 16 vCPUs | up to 1 TB vRAM - Largest supported SAP HANA VM:
8 CPU sockets | 384 cores | 768 vCPUs | up to 16 TB vRAM
VM configurations may vary depending on the specific CPU core count and memory configuration in use. All configurations, that deviate from the SAP defined standard SPR CPU configuration, require SAP HANA TDI or workload-based sizing. For more guidance, see SAP Note 2779240 – SAP HANA TDI/Workload-Based Sizing.
The SAP-defined tests executed for this validation included both functional tests (e.g., vMotion) and performance-related tests for large SAP BW/4HANA systems (OLAP workloads) and SAP ERP systems based on S/4HANA (OLTP workloads), simulating tens of thousands of concurrent users executing SAP transactions.
When running the publicly available SAP BWH benchmark on this configuration, the virtualization overhead ranged from 1.2% to 3.7%, depending on the memory sizing category used – L (12 TB) or M (16 TB) – based on the measured queries per hour (QPH) performance compared to a bare metal system.
In the S/4HANA mixed workload test focusing on OLTP transactions, the virtualization impact remained below 5%, particularly at CPU utilization levels up to 65% (approximately 70,000–115,000 concurrent users). When scaling the test to 135,000 users, CPU utilization reached up to 86%, and the impact on transactions per hour (TPH) rose to approximately 8%, even though VMXNET3 was used – which typically shows higher OLTP network latencies compared to a bare metal SAP HANA deployment or a pass-through NIC setup.
These results confirm that vSphere 8 is well-suited to virtualize even the most demanding, business-critical workloads like SAP HANA, and can now scale up to 16 TB of memory with 768 vCPUs without significant performance impact on QPH or TPH metrics.
Our vMotion test with a 16 TB SAP BW/4HANA VM completed successfully with no errors, even during the execution of phase 2 of the BWH benchmark at a CPU load of up to 25%. This demonstrates that vMotion can be used reliably to migrate active SAP HANA VMs during non-peak load times from ESXi hosts requiring maintenance.
Furthermore, using such a powerful 8-socket, 16 TB Sapphire Rapids system as a consolidation platform for multiple smaller SAP HANA VMs provides additional benefits, significantly reducing TCO by lowering the number of systems to manage. Additionally, smaller and more cost-effective memory modules (e.g., 128 GB DIMMs instead of 256 GB DIMMs) can be utilized compared to smaller socket systems.
It is important to note that when using the system for SAP HANA consolidation scenarios, sufficient storage and network bandwidth must be available to ensure optimal performance for each deployed VM. Table 1 shows SAP HANA VM deployment examples possible with this platform.
Table 1, 8-socket, up to 60 core SPR CPU system with up to 16 TB RAM*
*Notes for table 1:
- CPUs with a smaller core count are supported; memory sizing should follow TDI guidelines.
- Supported 8-socket system architectures are Intel Standard Architecture Systems (non-glued) and HPE glued 8-socket 3200 systems. Other 8-socket architectures are not validated and therefore not supported for virtual SAP HANA deployments.
- *vSphere 8 maximum: 768 vCPUs per VM, see VMware configuration maximums web page.
- **vSAPS values are derived from publicly available benchmarks for 8-socket Sapphire Rapids systems with 960 CPU threads, reduced by 10% to account for virtualization overhead. While this 10% sizing buffer is typically conservative, it serves as a solid baseline for initial sizing.
- The vSAPS value for the 8-socket-wide VM configuration is adjusted to reflect the vSphere 8 limitation of 768 vCPUs, which results in fewer available CPU threads compared to the native 960-thread benchmark.
- Half-socket vSAPS results include an additional 15% sizing buffer.
What’s Next?
The next scheduled test with this configuration will be conducted using vSphere 9, increasing the per-VM vCPU limit to 960 vCPUs, up from 768 vCPUs in vSphere 8.
Larger memory configurations (>16 TB per VM), other Glued / QPI meshed 8-socket systems, or SAP HANA Scale-Out deployments upon request.
References:
- SAP note 3372365 – SAP HANA on VMware vSphere 8
- SAP note 2779240 – Workload-based sizing for virtualized environments
- SAP Certified and Supported SAP HANA® Hardware Directory
- 4-Socket SPR SAP HANA vSphere 8 support blog
- VCF / vSphere product web page
- VCF Technical Overview
- VMware Configuration Maximums web page
