Home > Blogs > Virtualize Business Critical Applications

New Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere Guide, now available!

I am happy to announce that after a very long review and publication cycle the “Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere Guide” is now published.

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

The chapter on sizing tackles the complex subject getting HANA VM’s sized properly, and provides incredible value to the reader as it provides guidance that explains how to size beyond physical to virtual so your organization can get it right the first time, every time.

Building a virtual SAP HANA VM requires to know not only the needed RAM, but also the number of needed CPUs to support this RAM. Without this information, it is not possible to create a VM.

The sizing guidelines published in this guide follow the SAP currently requested CPU socket / CPU core to RAM ratios or, when available describe how to perform a SAPS sizing. Using these guideless will provide you with SAP supported VM configurations.

I will provide some additional sizing examples that focus on SAPS and vCPU sizing, in addition to the already provided “NUMA” node based sizing example. Please remember, primary sizing figure for SAP HANA is memory and CPU is second and a SAP HANA configuration is optimized to optimal memory performance with lowest latency.

This entry was posted in SAP and tagged , on by .
Erik Rieger

About Erik Rieger

Erik Rieger is a global solutions architect, working with VMware’s global System Integrators and System Outsourcers (SI/SO) and strategic ISV technical alliances. He is responsible for defining, developing and delivering VMware specific SAP solutions that help customers to achieve accelerated business performance and real-time decision making.

7 thoughts on “New Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere Guide, now available!

  1. urs Mani

    good day Erik,
    we’re competing with a power8 based offering for a HANA deployment. one reason where we seem to lose out is fault tolerance (FT) which is expressly excluded here: https://blogs.sap.com/2014/12/03/sap-hana-on-vmware-vsphere/
    unfortunately also the latest best practiced guide https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/sap_hana_on_vmware_vsphere_best_practices_guide-white-paper.pdf
    doesn’t go into detail there. do you have any more indepth information on whether or not FT is a supported scenario now or in the future?
    thank you for your time!
    best regards,

    1. Erik RiegerErik Rieger Post author

      Hi Urs,

      there are very limited use cases for FT in the SAP HANA space due to the current FT limitations in terms of vCPU (4) and vRAM (64GB). One use case would be to protect a virtualized NFS server when deploying a SAP HANA Scale-Out configuration.

      We also see VMware FT as an alternative solution for SAP Enqueue Replication. Here you can use it to protect a complete (A)SCS instance to protect the enqueue and message service processes of a SAP system. FT provides some benefits to the SAP Enqueue Replication since we take care of a complete system failover, including network identity. When using SAP Enqueue Replication you have to use an 3rd party cluster solution to solve this problem. With VMware FT it is just a matter of a click.

      Check out the blog post of my colleague Vas Mitra to get more information on FT for SAP:

      While we work on our SAP HANA Scale-Out vSphere 6.x certification, we may use a FT to protected a virtualzed NFS server for the needed SAP HANA shared directory. This would provide a very reliable and FT protected SAP HANA shared directory which gets more and more critical for SAP HANA Scale-Out configurations. I will share the results as soon we have results for this test.


  2. Noe Hoyos

    Hi Erik,

    In regards to CPU affinity, the new best practice document it needs to be configured in the ..vmx file directly because doing it in the vSphere web client would result in ‘something’; the sentence seem to be incomplete. Can you clarify?

    It is a paragraph in secstion “vCPU Affinities _ Pinning Virtual NUMA to Physical NUMA”.

    Thank you,
    Noe Hoyos

    1. Erik RiegerErik Rieger Post author

      Hi Noe,

      thanks for letting me know. It seems we missed this while reviewing the guide. It will get corrected in the next version!

      The sentence should have been removed and replaced with: “Add these settings directly to the .vmx file via an editor or via the Web Client. If you are using the web client, then please review guide https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-resource-management-guide.pdf , page 22″ how to do it.

      My advice is to add this, if needed at all, via an editor, as it will save you some time…

      Again, affinities should only get configured if you want to optimize memory latency. Maintaining CPU affinities over the live span of a SAP HANA VM may become difficult, especially if you upgrade in the future to a newer CPU with more CPU cores. Nevertheless, it will help you optimizing memory latency of SAP HANA.


  3. Mark Herzfeld

    Hi Erik,
    Thanks for putting together a very comprehensive guide for Vsphere and Hana, since without it, we would have probably gone in a different direction.

    Referring to the Jan 2017 guide:
    On page 65, there is a formula that says “(4096 GiB divided by four)”, I believe should be “(2048 GiB divided by four)” . As that would yield the 512 GiB RAM per numa node.

    On page 77, consider adjusting from “it got already discussed” to “it already got discussed”
    Also on that same page, “fault recovery and in disaster recovery.” maybe should read: “fault recovery and disaster recovery.”

    On page 128, I just want to be sure, that the recommendation is to use virtual guest with “UEFI BIOS”. Or was this meant to be in the “Vsphere ESXI host” section?

    On page 133, “becausae” to “because”. Also: “Setting affinities is for this is not required.” should probably be restated as it is not clear. Are you saying that if we set halt_in_monitor=”True” and idleLoopSpinBeforeHalt=”True”, then we don’t need to set individual affinities, except in extreme situations?

    As you can see, that information that you and your provides is read thoroughly! Keep up the good work.

    1. Erik RiegerErik Rieger Post author

      Hi Mark,

      many thanks for your positive feedback and all the issues you found in the guide!

      Page 65, (4096 GiB divided by four) should be (2048 GiB divided by four)

      Page 77, good points! I will have a word with your native English speaking editor ^^

      Page 128, yes, that should be in the host parameter list!

      Page 133, What I tried to describe is that by setting parameter idleLoopSpinBeforeHalt and halt_in_monitor to “TRUE” you optimize already your VM in terms of CPU latency. Setting CPU affinities is not required for these parameters. They work without and with CPU affinities.
      Setting CPU affinities help to further optimize your, by now already, well tuned “formula one SAP HANA VM” . In most situations you won’t notice the difference.
      As stated, it provides an additional field of optimization you may want to use in extreme latency critical environments. Setting CPU affinities is also not required when you have a VM that is small enough to run inside a single NUMA node.

      Again many thanks for your feedback! Only with feedback like yours, I can make the document next time better!



Leave a Reply

Your email address will not be published. Required fields are marked *