Primary characteristics of the SAP HANA In-Memory Database: The SAP HANA In-Memory Database can read memory data in 5 nanoseconds as compared to the conventional databases that take about 5 milliseconds to read such databases. The row based, column based and object oriented technology is combined in this database. While traditional sizing approaches focus on CPU performance, the main driver for SAP HANA sizing is memory. Because SAP HANA is a main memory database, essentially all business data (e.g., master and transactional data) resides in the main memory, which leads to a higher memory footprint compared to traditional databases.
Skip to end of metadataGo to start of metadataFor any questions regarding the content of this document please send an e-mail to erieger@vmware.com.
By running the SAP HANA platform virtualized on VMware vSphere, SAP customers can leverage an industry standard data center platform, optimized for agility, high availability, cost savings, and easy provisioning.
SAP customers will not only gain the ability to provision instances of SAP HANA in virtual machines much faster, but also benefit from unique capabilities like:
- Increased security and SLAs, e.g. through NSX or DRS.
- Live migration of running SAP HANA instances, with VMware vSphere® vMotion®
- Standardized High Availability, based on VMware vSphere® High Availability (HA)
- Built-in multi-tenancy support, through system encapsulation in a virtual machine (VM)
- Abstraction of the hardware layer
- Higher hardware utilization rates
- Lower TCO due to SAP HANA instance consolidation
These and other advanced features - to a large extend found exclusively in virtualization - lower the total cost of ownership and ensure the best operational performance and availability.
Support Information
SAP HANA on vSphere is only supported with following so called “main editions”, which are: vSphere Standard Edition and vSphere Enterprise Plus. Business One solutions are also supported with Acceleration or Essentials Kits. Please note the feature / CPU / host limitations that come with these kits.
For SAP production environments (HANA and Business One) 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”.
For latest SAP released support information please refer to the central VMware on SAP Community WIKI page.
For a collection of recent support issues with VMware vSphere, check Known Support Issues.
As of SAP note 2652670 -SAP HANA VM on VMware vSphere, usually all update and maintenance versions of vSphere hypervisors are automatically validated within the same boundary conditions(e. g. CPU, memory). SAP has the right to request additional validations if necessary. As an example, to leverage the increased vCPU support in vSphere 6.7U2, SAP and VMware had re-validated this version with 256 vCPUs. Otherwise this version would have been supported only on the feature basis of vSphere 6.7. As a new main release SAP has requested to validate vSphere 7.0, which is by now fully supported and the new basis for all future vSphere releases for SAP HANA.
SAP HANA Best Practices and Recommendations:
- Customers running SAP HANA on VMware shall follow the Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere.
- Support for non-prod. SAP HANA configurations is limited. Please review following blog “Cost-Optimized SAP HANA Infrastructure for Non-Production Usage” by Bill Zang, SAP, for details.
SAP Notes and additional information:
- SAP HANA on vSphere support notes: SAP Notes Related to VMware, section SAP HANA
- SAP HANA on vSphere with Persistent Memory:SAP HANA with Persistent Memory on VMware vSphere
- VMware blog: SAP HANA with Intel Optane Persistent Memory on VMware vSphere
- VMware blog: SAP NetWeaver and SAP HANA with VMware vSphere 7.0
SAP HANA on VMware vSphere Support Status and Overview:
Note:
For final design and infrastructure buying decisions, please always refer to the listed SAP notes and do not relay on below tables, as they may not have the latest support status. 'The single source of trough' are always the related SAP notes! |
|---|
| Disclaimer: For final design and infrastructure buying decisions, please always refer to the listed SAP notes and do not relay on below tables, as they may not have the latest support status! | |||||
Single, Multiple and Scale-Out SAP HANA Systems on VMware vSphere | |||||
| Availability | General Availability - Full SAP Support | ||||
| Support Level | production | ||||
| vSphere Release | vSphere 6.0 (out of support since March 2020, KB 66977) | vSphere 6.5 / 6.7 | vSphere 6.7U2/U3 | vSphere 7.0 incl. U1 | |
| SAP Note | 2393917 | 2937606 | |||
| SAP HANA start Release [1] | SAP HANA 1.0 SPS 11 | SAP HANA 1.0 SPS 12 Revision 122.19; SAP HANA 2.0 recommended | |||
| max. RAM VM Size | 4 TB | 4 TB Broadwell [2] 6 TB Skylake and Cascade Lake [2] | 6 TB Skylake and Cascade Lake [2] | ||
Workload Based sizing SAP Note 2779240 | not available | Amount of memory and CPU upon workload based sizing, single VM memory up to 6 TB (as of today) | |||
| min. RAM HANA VM Size | 128 GB RAM | ||||
| vCPUs per VM [3] | up to 128 | up to 256 Haswell up to 144 Broadwell up to 192 Skylake and Cascade Lake up to 224 | Skylake and Cascade Lake up to 224 | ||
| min. CPU Resources [3] |
| ||||
| Persistent Memory Support [6] | No Support | No Support | SAP Note 2913410 Restrictions:
| ||
| SAP HANA Scale-Out [7] | Non-Prod. support as of note 2315348 |
| |||
No Support | Node size 3 TB
*HA nodes should be added according to the cluster size. FAQ: SAP HANA High Availability**3 TB Scale-Out node deployment is currently limited to 1 master and 7 worker and SAP Sizing Class M workloads. This limitation is not a technical limitation but caused by the at the time of the validation used hardware.***3 TB, SAPCPU Class L workload validation on roadmapNote: The SAP HANA BW needed SAP CPU Class can get found in the BW sizing report under the heading 'RSDDSTAT ANALYSIS DETAILS'. See SAP note 2610534 for details. | ||||
Intel Haswell | E7 EX | Host server min 2 and maximal 8 sockets:
| No support | ||
E5 EP | Host server up to 2 sockets:
| ||||
Intel Broadwell | E7 EX | Host server min 2 and maximal 8 sockets:
| No support | ||
E5 EP | Host server up to 2 sockets:
| ||||
Intel Skylake | Platinum Gold Silver | Host server min 2 and maximal 8 sockets:
| |||
Intel Cascade Lake | Platinum Gold Silver | No support | Host server min 2 and maximal 8 sockets:
| ||
| Persistent Memory Support [6] | No support | First server platform with SAP support for Intel Optane PMem! VMware host restriction for PMem: max. 15 TB host memory (combined) and max. 4-CPU sockets. Later vSphere release will support larger host configurations. vSphere start release: vSphere 6.7 EP 14 and vSphere 7.0 P01 | |||
| vSphere Release | vSphere 6.0 (out of support since March 2020, KB 66977) | vSphere 6.5 / 6.7 | vSphere 6.7U2/U3 | vSphere 7.0 incl. U1 | |
[1] The SAP HANA start release defined as 'SAP HANA 1.0 SPS 12 Revision 122.19' includes support for SAP HANA 2.0. SAP HANA 2.0 recommended for Skylake and Cascade Lake platforms!
[2] Maximal SAP HANA VM RAM is 6 TB (OLTP). vRAM is limited by the maximal supported RAM of a physical SAP HANA supported server configuration as specified by SAP (Broadwell 4 TB, Skylake and Cascade Lake 6 TB) for appliance like configurations. Please refer to the Certified SAP HANA Hardware Directory. For the maximal supported 4-socket VM size, OLAP workload is limited to 3 TB of memory (Class L) or 6 TB (Class M - customers must size accordingly, for details read SAP note 277924).
[3] A SAP HANA VM configuration can get configured with maximal 256 vCPUs. As of today maximal 4-socket large VMs are supported on 4- or 8-socket systems. 8-socket large VMs are not supported yet. On Haswell based systems maximal 144 vCPUs, Broadwell based systems maximal 192 vCPUs and on Skylake and Cascade Lake based systems maximal 224 vCPUs can get configured. This is therefore the limiting factor of a SAP HANA VM for CPU resources (SAPS capacity). SAP requests for a SAP HANA system minimal 8 pCPU cores for production. As of today maximal 2 VMs per CPU socket are allowed with Haswell (18 core CPUs) or or later CPU generation (Half-Socket VM).
[4] SAP HANA VMs can get co-deployed on a ESXi host server with SAP non-production HANA VMs or any other workload VMs. Co-deployed VMs should not negatively impact production SAP HANA VMs (e.g. overloaded network cards). SAP HANA production VMs have to run on dedicated CPUs (NUMA nodes). Half-Socket SAP HANA VMs can share the CPU socket with other SAP HANA Half-Socket VMs (OLAP and OLTP, prod. and non-prod.). Sharing the CPU socket with non-SAP HANA VMs was not tested and is therefore not supported for SAP HANA production VMs.
[5] In case two VMs share a NUMA Node, both VMs need to fulfill the minimal resource requirements for an SAP HANA system: 128 GB RAM and 8 pCores per VM. An additional performance impact for NUMA-node sharing VMs should be considered and a sizing buffer of at least 15% should get used.
[6] SAP supports only Intel Optane PMem for persistence memory! VMware host restriction for PMem: max. 15 TB host memory (combined) and max. 4-CPU sockets. Later vSphere release will support larger host configurations. vSphere Persistent Memory requires vSphere Enterprise Plus. For details please review following document (page 6). Review https://blogs.vmware.com/apps/2020/06/sap-hana-with-intel-optane-dc-persistent-memory-on-vmware-vsphere.html and SAP HANA with Persistent Memory on VMware vSphere for additional information.
[7] SAP general sizing recommendations is to Scale-Up first. Intel E5 based 2-socket servers are not supported in Scale-Out deployments. This SAP recommendations are not specific to virtualization. Minimal and maximal SAP HANA VM and Host sizes as described in the previous table.
VMware vSphere Supported Storage Configurations for virtualized SAP HANA | |
| Supported SAP HANA Storage Systems for virtualisation [1] | All SAP HANA TDI certified and VMware [2] supported storage solutions can get used |
| Storage sizing [3] | As defined by storage vendor and tested regarding the SAP HANA storage KPIs |
[1] For details please refer to the Certified SAP HANA Hardware Directory and go to “Certified Enterprise Storage” configurations.
[2] Beside SAP HANA TDI stoarge certification, it has to get ensured, that the storage storage solution is VMware certified. See the VMware HCL for supported storage configurations and select the used storage interface as filter.
[3] The defined KPIs for Data Throughput and Latency for production SAP HANA systems has to be fulfilled for each VM. SAP has released a special tool, the SAP HANA HW Configuration Check Tool, to measure if the used storage is able to deliver the required IO capacity, see SAP Note 1943937.
VMware vSphere Supported OS Versions and Vendors for virtualized SAP HANA [1] | |
| Yes |
| Yes |
[1] Both, SUSE Linux Enterprise Server (SLES) for SAP Applications and SAP HANA and Red Hat Enterprise Linux (RHEL) for SAP Solutions and SAP HANA are supported operating systems when virtualized. However, due to different scope and test coverage during corresponding validation activities, the underlying server must be certified for corresponding operating system. For an updated list of supported releases please refer to SAP Note 2235581.
VMware vSphere and SAP HANA HA and Operation Features [1] | |
| VMware HA [2] | Yes |
| In-Guest Cluster [3] | Yes |
| SAP HANA System Replication | Yes |
| VMware FT [4] | No |
| VMware SRM [5] | Yes |
| vSphere vMotion | Yes |
| VMware DRS [6] | Yes |
| Hot-Add CPU [7] | No |
| Hot-Add Memory [8] | No |
Intel Cluster-On-Die (COD) / Sub-NUMA Clustering Technology [9] | No |
[1] Generally all VMware vSphere features, like distributed switches are supported. The listed features got expliciltly tested with the usage with SAP HANA like vMotion to ensure these features work and that the impact is know to SAP HANA (e.g. vMotion of running SAP HANA VMs).
[2] vSphere HA to protect against OS and Host failures.
[3] SAP HANA supported 3rd party Linux cluster solutions can get used to protect against SAP HANA application failures
[4] VMware FT is not suitable to protect a SAP HANA DB VM due to the resource limitations of VMware FT, but can get used to protect for instance the NetWeaver application servers, SCS application server instance or a virtualized NFS server to protect in a Scale-Out environment the shared SAP HANA directory. Ensure that the SAPS load of the FT protected SAP workload is suitable for the VMware FT limitations.
[5] VMware SRM is an automation tool for disaster recovery and allows a RPO of 5 minutes, if vSphere version 6.5 or above replication gets used for replication (RPO = 5 → data loss up to 5 minutes possible). vSAN also allows a recover point objective of 5 minutes. For any applications or databases that require a RPO < 5 minutes then VMware SRM can get combined with physical synchronous storage replication. For SRM supported storage arrays click on following link.
[6] VMware DRS should get configured in “manual mode” or set to 'fully automatic with conservative'. This is the preferred setting as it allows VM host evacuation for instance during a maintenance event.
[7] Please be aware that the use of hot-add CPU feature disables vNUMA and hence may lead to performance degradation. Therefore, as of today we are generally do not support this feature in combination with VMs that run SAP HANA.
[8] SAP HANA does not support hot-add memory. Because of this, hot-add memory was not validated by SAP and VMware with SAP HANA and is therefore not supported.
[9] SAP HANA does not support Intel Cluster-on-Die (CoD) and sub-NUMA clustering technology. Therefore this feature is also not supported in VMware virtual SAP HANA environments. Details: SAP HANA Hardware and Software Requirements.
SAP HANA on vSphere Best Practices
In a nutshell: SAP HANA follows general published vSphere Best Practices for databases:
- Set Memory Reservations for SAP HANA Virtual Machines
- Configuring Paravirtual SCSI Controllers and Network Adapters
- Right sizing of SAP HANA VMs to ensure local NUMA node memory access and high 2nd level cache hit ratios
- Enable Hyper Threading on the ESXi host
- Use dedicated networks for vMotion, management, client and if needed backup and replication network
- Use vMotion and VMware snapshots during non peak times
- Configure for SAP HANA latency critical the ESXi scheduler optimisation parameters as documented in below best practices guide
- Ensure you set following SAP HANA / vSphere specific Linux kernel parameters:
- transparent_hugepage=never
- numa_balancing=disabled
- elevator=noop (for RHEL and SLES 12)
- if blk-mq I/O path gets used (e.g. SLES 15) then use elevator=none. For further information ask your OS vendor*.
- vmw_pvscsi.cmd_per_lun=254
- vmw_pvscsi.ring_pages=32
*For SLES refer tohttps://documentation.suse.com, select SLES for SAP Applications and 'System Analysis and Tuning Guide', check out section 'Tuning I/O Performance'.
Please read the “Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere Guide” for detailed information on the best practices and recomendations. The guide can be downloaded from our central VMware SAP page. Direct link to the document: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/sap_hana_on_vmware_vsphere_best_practices_guide-white-paper.pdf. Also review the updated SAP HANA on vSphere 6.5 and later - Configuration / Best Practices Parameter List.
Sizing of SAP HANA VMs:
The sizing of virtual SAP HANA VMs is similar to bare metal SAP systems, with the limitation of a maximum size, beginning with with vSphere 6.7, of 6 TB, 256 vCPUs and a SAP support limitation to maximal 4-CPU socket wide VMs. In addition to this the usable resources get limited by 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. This results in the SAP HANA standard sizes for 4-socket large systems with VM sizes up to 6 TB for OLTP and 3 TB VM sizes for OLAP workloads with 224 vCPUs on an Intel Cascade Lake platform. For SAP supported systems a workload-based sizing has to get performed to define the actual CPU and memory configuration of a host and VM.
Also the memory limitations of appliance like configured hosts can be mitigated via workload-based sizing. Details see SAP note 2779240.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.
SAP HANA VM on vSphere Deployment Examples:
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.
SAP HANA on vSphere Support and Validation Roadmap:
Hana Database Size On Disk
SAP HANA VMware’s HANA certification/support strategy starting with Haswell, is to support a single chipset with 2 versions of the hypervisor and to have a single hypervisor version span normally 2 chipsets. VMware does its best to strike a balance between supporting new customers on the latest hardware and customers who are remaining on older platforms. vSphere 5.5 or 6.0 are by now out of support. The next planned vSphere release will be vSphere 7.0 U1,which will provide more CPU and memory resources per VM.
VMware SAP HANA System Health Check
SAP and VMware are offering joint services to help you design, deploy, and implement your virtual SAP HANA platform. Examples of services which may be offered are:
Sap Hana Database Size Limit
- Pre-Call to discuss PoC, goals, timeline and success factors (SAP, HW Partner, Customer and VMware)
- Architecture review and introduction to the SAP HANA on vSphere Configuration Guidelines and Requirements
- Introduction to SAP HANA Hardware Check Configuration Tool (HWCCT)
- Online review session to check prepared environment like:
- Host including storage and network configuration
- VM configuration
- Linux OS configuration
Hana Db Backup Size
For more information on SAP Consulting and VMware Professional Services, visit vmware.com/consulting or get in contact with your local VMware contact.