Page tree
Skip to end of metadata
Go to start of metadata

For any questions regarding the content of this document please send an e-mail to

As of SAP Note 2718982 - SAP HANA on VMware vSphere and vSAN, following deployment options, versions and sizes are supported and a SAP HANA hyperconverged infrastructure (HCI) vendor can build accordingly to below options its specific SAP HANA HCI solutions.


Note: The actual SAP HANA HCI vendor solution may differ from the current supported options. Like as of today no 8-socket SAP HANA HCI solution got certified.

VMware Technical Documents:

HANA on vSAN SAP supported and validated options:

  • CPU architecture:
    • Any supported Intel SkyLake, Cascade Lake, or Cooper Lake processors with 2,4 & 8 socket servers with existing VMware vSphere virtualization boundaries:
      • max. 6 TB RAM and 256 vCPUs per SAP HANA Scale-Up VM, see SAP Note 2393917 for details. Also beware, that the actual usable vCPUs depend on the used CPU type. 256 vCPUs represent the current vSphere maximum.
      • Cooper Lake requires vSAN 7.0 U2.
    • Certified Hardware for HCI solutions can be found on the Certified Hyper-Converged Infrastructure Solutions [1]
  • VMware vSphere Hypervisor 6.5, 6.7, 6.7 U2/U3, 7.0 U1/U2
    • SAP HANA SPS 12 Rev. 122.19 (or later releases) for production single-VM and multi-VM use cases. See SAP Note 2393917 [2] for detailed information and constraints. SAP HANA on vSAN has additional constraints, see next section.
  • VMware vSAN 6.6, 6.7 (incl. U1, U2/U3) and 7.0 U1/U2 (excluding 7.0 base version)
    • Starting from above vSAN versions, the HCI vendor can select the appropriate vSAN version for their HCI solution.
    • The vSAN versions 6.6 and 6.7 are included in vSphere version 6.5 U2 and vSphere version 6.7 / 6.7 U2/U3 respectively. vSAN 7.0 version U1 is included in vSphere version 7.0 U1, vSAN 7.0 U2 in vSphere 7.0 U2.
    • Minimal 3, maximal 64 nodes per SAP HANA HCI vSAN cluster
      • vSAN 6.6, 6.7, 6.7 U1, 6.7 U2, 6.7 U3, 7.0 U1, 7.0 U2: Maximum 4 SAP HANA VMs on 2, 4, and 8 socket servers
      • 4 or more nodes are recommended for optimal failure resilience, even during maintenance and for cross DC wide HA solutions required.
    • No CPU sockets need to get reserved for vSAN. Please note that vSAN will need, just like ESXi, system resources. Please refer to VMware KB 2113954 for information on resource needs of vSAN.
  • SAP HANA Scale-Up:

    • OLTP or Mixed type workload up to 6 TB RAM and up to 256* vCPUs per VM

    • OLAP type workload:

      • SAP sizing Class** L: up to 3 TB RAM and up to 256* vCPUs per VM

      • SAP sizing Class** M: up to 6 TB RAM and up to 256* vCPUs per VM

  • SAP HANA Scale-Out:
    • Intel Cascade Lake or Cooper Lake processors with 4 & 8 socket servers with existing VMware vSphere virtualization boundaries.
    • vSAN 6.7 U2/U3 and 7.0 U1/U2
    • Up to 1 master and 7 worker nodes are possible, plus HA node(s). HA nodes should be added according to the cluster size.FAQ: SAP HANA High Availability
    • SAP HANA Scale-Out system max. 16 TB memory with SAP HANA Class** L type sizing:

      • Up to 2 TB of RAM and up to 256* vCPUs per Scale-Out node (VM), sizing up to SAP HANA CPU Sizing Class** L type workloads

    • SAP HANA Scale-Out system max. 24 TB memory with SAP HANA M-Class* CPU sizing:

      • Up to 3 TB of RAM and up to 256* vCPUs per Scale-Out node (VM), sizing up to SAP HANA CPU Sizing Class** M*** type workloads

**Actual usable number of vCPU depends on the selected CPU type.
**Note: The SAP HANA BW needed CPU Sizing Class can get found in the BW sizing report under the heading "RSDDSTAT ANALYSIS DETAILS". See SAP note 2610534 for details.
***3 TB Scale-Out node deployment is currently limited to CPU Sizing Class M workloads. This limitation is not a technical limitation but caused by the available validation hardware. CPU Sizing Class L workload validation is on roadmap.

 Additional support information:

  • vSAN for SAP HANA is only supported as part of an SAP HANA HCI vendor-specific and certified solution
  • The SAP HANA HCI solution vendor (hardware vendor) is the primary support contact for the customer.
  • The SAP HANA HCI solution vendor is responsible for installing on the vSphere ESXi host the SAP HANA HCI VMware vSAN Detection Script, which can get downloaded from this link.
  • Intel Optane DCPMM (PMEM) can be used as described in note 2913410. Please note that especially the VMware HA restriction (as described in the mentioned note) applies and needs to get considered.

Can I use vSAN / SAP HANA HCI with PMEM?

VMware vSAN does not have support for “App-Direct” mode (source) as cache or as a capacity tier device of vSAN. However, vSAN will work with vSphere hosts equipped with Intel Optane PMem in App-Direct mode and SAP HANA VM’s can leverage PMEN according to SAP Note 2913410. Please note that especially the VMware HA restriction (as described in note 2913410) applies and needs to get considered.

SAP HANA HCI on vSAN—Architecture Overview

In SAP HANA environments, it is required to use a minimum of three vSAN hosts. Four nodes are recommended for easier maintenance and Stretched Cluster readiness. All vSphere/vSAN cluster nodes contribute cache and capacity to the vSAN distributed/clustered datastore and are interconnected through a dedicated min. 10 GbE or preferable better path redundant network. 

Below figure shows the high-level architecture of an SAP HANA landscape running on a VMware-based SAP HANA HCI solution built upon several vSphere and vSAN hosts in a n+1 HA configuration. 

Storage policies shown in the figure as bronze (App server), silver (for less demanding SAP HANA application), and gold (for IO demanding HANA VMs), will ensure that all VMs get the performance, resource commitments, failure tolerance, and quality of service they required.

With such an environment, changing the assigned storage policy in response to the changing needs of a virtualized application can directly influence the underlying infrastructure. The different storage policies allow changing the level of protection or possible IO limits without disturbing operation of a VM, allowing it to remain available and maintain the defined SLAs and performance KPIs.

SAP HANA HCI on VMware – SAP HANA Deployment Examples:

Depending on the selected SAP HANA HCI nodes SAP HANA Suite Scale-Up sizes are possible up to 6 TB and BW workloads are possible up to 3 TB. SAP HANA Scale-Out deployments are supported and can get used to deploy a single SAP HANA Scale-Out BW system with one master and up to 7 worker nodes. Node size can be up to 3 TB (Class M CPU sizing). If a Class L CPU is required for the given workload then only 2 TB per node are supported as of today.

Respect following SAP's requirements on Scale-Out deployments, a 4-socket large VM has to get used with all available CPU resources assigned. Running several Scale-Out systems in production on 4socket SAP HANA HCI nodes is therefore not supported. This is not a VMware but SAP restriction.

For details review SAP note 2393917 - SAP HANA on VMware vSphere 6.5 and 6.7 in production. Following graphics shows a Scale-Up and a Scale-Out example.

SAP HANA HCI on vSphere – Scale-Up Example:

SAP HANA HCI on vSphere – Scale-Out Example:

SAP HANA HCI on VMware – HA Ready out of the Box!

An SAP HANA VMware HCI solution provides HA out of the box. The n+1 cluster concept provides one full compute host as failover capacity. VMware DRS can help with the initial deployment of the VMs and ensures a homogeneous distribution of the workload between the hosts. VMware HA monitors HW and can monitor OS failures and initiates automatically a failover of any VMs that run on an affected host. If more HA capacity is required, then more HA nodes can get added (e.g. n+2 cluster).

Below figure shows multiple SAP HANA Systems, running on an Active-ActiveVMware based SAP HANA HCI cluster.

VMware HA with HANA System Replication (HSR) 

To protect SAP HANA data against logical or disastrous failures, which could impact a complete data center (DC), then VMware HA can get combined with HSR. VMware HA protects in this case against local failures, like OS or host HW failures and HSR would protect SAP HANA data against logical or disastrous datastore failures. HSR can get also used to minimize the SAP HANA restart time if HSR gets configured to replicate data in a synchronous way into the memory of the replication target.

The next figure shows a vSphere cluster, with an SAP HANA production VM replicated to an SAP HANA replication VM. The HSR replica VM can be running on the same cluster, or on an independent vSphere host/cluster to protect against DC impacting failures.

Note: If the HSR replicated VM shall run in a remote DC, then this VM cannot get stored on the same vSAN datastore and a separate vSphere / SAP HANA HCI cluster needs to get used. To ensure that HSR replication does not impact performance, a RTT, of the SAP HANA replication network, below 1 ms is required. If this is not possible then asynchronous HSR replication can get used.

VMware vSAN Stretched Cluster Support SAP HANA Systems

Stretched clusters extend the vSAN cluster from a single data site to two sites for a faster level of availability and cross-site load balancing. Stretched clusters are typically deployed in environments where the distance between data centers is limited, such as metropolitan or campus environments. SAP HANA is now tested and is supported on vSAN stretched cluster 7.0 U1/U2 environments. SAP HANA requires that log file writes have a less than 1ms latency, and this log file write latency should not exceed 1ms across primary and secondary sites. The underlying network infrastructure plays a key role, as the distances supported between the two sites solely depends on ability to achieve latency of 1ms across these sites for SAP HANA.

Tests conducted with one of our HCI hardware partners showed that distances up to 30 km between the two sites, all SAP HANA performance throughput and latency KPIs were passed across the tested SAP HANA VMs. Actual distances could be lower since the network latency is depending on the used network components and architecture. SAP HANA HCI support of stretched cluster configurations is upon the SAP HANA HCI hardware vendor and not VMware.

You can use stretched clusters to manage planned maintenance and avoid disaster scenarios, because maintenance or loss of one site does not affect the overall operation of the cluster. In a stretched cluster configuration, both data sites are active sites. If either site fails, vSAN uses the storage on the other site. vSphere HA restarts any VM that must be restarted on the remaining active site.

You must designate one site as the preferred site. The other site becomes a secondary or non preferred site. If the network connection between the two active sites is lost, vSAN continues operation with the preferred site. The site designated as preferred typically is the one that remains in operation unless it is resyncing or has another issue. The site that leads to maximum data availability is the one that remains in operation.

Below example shows a simplified stretched cluster configuration. Site X is the preferred (prod. site), which can be a complete datacenter or a single rack. Site Y is the secondary site and in this case the failover site in the case of site failure. Local failures can get compensated by providing HA capacity inside the site and a site failover can get initiated by providing enough failover capacity at site Y, or by freeing up failover capacity. The witness appliance must run on a host placed in an independent site Z. The witness decides ultimately on a site failover and can run for instance on an ESXi host which supports the SAP application server VMs.

SAP HANA Stretched Cluster Example Configuration:

Streched Cluster vSAN for SAP HANA summary:

  • Tested distances maintain <= 1 ms KPI for SAP HANA log writing up to 30 km
  • Stretched clusters are normally used campus wide, therefore distances up to 5 km supportable.
  • Witness VM can run on any vSphere host in 3rd size “z”.
  • Failover capacity is n+1, where 1 stands for one host failure. N+2 would support two host failures.
  • Failover can be bi-directional.


The SAP HANA HCI solution vendor is the primary support contact for the customer with escalation possibilities to VMware and SAP.  

As of today, VMware vSAN is only supported for SAP HANA as part of an SAP HANA HCI vendor-specific solution, which comply to the minimum SAP and VMware defined Life Cycle management functionality. No support for non-SAP HANA HCI certified vSAN ReadyNode™ or custom built vSAN configurations. 

Support Process

If you want to escalate an issue with your SAP HANA HCI solution, work directly with your HCI vendor and follow the defined and agreed support process, which normally starts by opening a support ticket within the SAP support tools. 

Beside the HCI vendors specific support process, customers can benefit from VMware vSAN Support Insight, which is a next-generation platform for analytics of health, configuration, and performance telemetry. 

Its purpose is to help vSAN users maintain reliable and consistent computing, storage and network environment and can get used. Support insight is an additional support offer and requires an active VMware support contract.

SAP HANA HCI VMware Solution Partners

As of June 2020, seven VMware partners are SAP HANA HCI certified and offer 17 different solutions that use VMware software for their SAP HANA HCI solutions.

Most of these solution partners, namely DellEMCFujitsu, Supermicro, HPE and Lenovo using beside vSphere also vSAN. A benefit using vSAN is, that with vSAN, all available SAP HANA HCI hosts resources can get used for SAP HANA and up to 4 VMs per host can get deployed. Check the below listed specific HCI vendor SAP support note to learn how many VMs are supported on a specific HCI vendor solution.

As of today, the largest SAP HANA system, which can get virtualized as Scale-Up is a 6 TB instance on the LenovoHPE, Fujitsu and Dell certified 4-socket server HCI solutions. 

Please check out the SAP HANA Certified Hyper-Converged Infrastructure Solutions web page for details and the latest certified solutions and vendors.

Partner specific documentation:

Additional References: 

VMware Blogs:

VMware Technical Documents:

  • No labels