An ongoing discussion about SAP infrastructure

SAP HANA on Power support expands dramatically

SAP’s release of HANA SPS11 marks a critical milestone for SAP/IBM customers. About a year ago, I wrote that there was Hope for HoP, HANA on Power.  Some considered this wishful thinking, little more than a match struck in the Windy City.  In August, that hope became a pilot light with SAP’s announcement of General Availability of Scale-up BW HANA running on the Power Systems platform.  Still, the doubters questioned whether Power could make a dent in a field already populated by dozens of x86 vendors with hundreds of supported appliances and thousands of installed customers.  With almost 1 new customer per business day deciding to implement HANA on Power since that time, the pilot light has quickly evolved into a nice strong flame on a stove.

In November, 2015, SAP unleashed a large assortment of support for HoP.  First, they released a first of a kind support for running more than 1 production instance using virtualization on a system.[1]  For those that don’t recall, SAP limits systems running HANA in production on VMware to one[2], count that as 1, total VMs on the entire system.  Yes, non-prod can utilize VMware to its heart’s content, but is it wise to mess with best practices and utilize different stacks for prod and non-prod, much less deal with restrictions that limit the number of vps to 64, i.e. 32 real processors not counting VMware overhead and 1TB of memory?  Power now supports up to 4 resource pools on E870 and E880 systems and 3 on systems below this level.  One of those resource pools can be a “shared pool” supporting many VMs of any kind and any supported OS as long as none of them run production HANA instances.  Any production HANA instance must run in a dedicated or dedicated-donating partition in which when production HANA needs CPU resources, it gets it without any negotiation or delay, but when it does not require all of the resources, it allows partitions in the shared pool to utilize unused resources.   This is ideal for HANA as it is often characterized by wide variations in loads, often low utilization and very low utilization on non-prod, HA and DR systems, resulting in the much better flexibility and resource utilization (read that as reduced cost).

But SAP did not stop there.  Right before the US Thanksgiving holiday, SAP released support for running HANA on Power with Business Suite, specifically ERP 6.0 EHP7, CRM 7.0 EHP3 and SRM 7.0 EHP3, SAP Landscape Transformation Replication Server 2.0, HANA dynamic tiering, BusinessObjects Business Intelligence platform 4.1 SP 03, HANA smart data integration 1.0 SP02, HANA spatial SPS 11 and controlled availability of BPC[3], scale-out BW[4] using the TDI model with up to 16-nodes.  SAP plans to update the application support note as each additional application passes customer and/or internal tests, with support rolling out rapidly in the next few months.

Not enough?  Well, SAP took the next step and increased the memory per core ratio on high end systems, i.e. the E870 and E880, to 50GB/core for BW workloads thereby increasing the total memory supported in a scale-up configuration to 4.8TB.[5]

What does this mean for SAP customers?  It means that the long wait is over.  Finally, a robust, reliable, scalable and flexible platform is available to support a wide variety of HANA environments, especially those considered to be mission critical.  Those customers that were waiting for a bet-your-business solution need wait no more.  In short order, the match jumped to a pilot light, then a flame to a full cooktop.  Just wait until S/4HANA, SCM and LiveCache are supported on HoP, likely not a long wait at this rate, and the flame will have jumped to one of those jet burners used for crawfish boiling from my old home town of New Orleans!  Sorry, did I push the metaphor to far?  🙂


[1] 2230704 – SAP HANA on IBM Power Systems with multiple – LPARs per physical host

[2] 1995460 – Single SAP HANA VM on VMware vSphere in production

[3] 2218464 – Supported products when running SAP HANA on IBM Power Systems  and

[4] BW Scale-out support restriction that was previously present has been removed from 2133369 – SAP HANA on IBM Power Systems: Central Release Note for SPS 09 and SPS 10

[5] 2188482 – SAP HANA on IBM Power Systems: Allowed Hardware


December 8, 2015 - Posted by | Uncategorized | , , , , , , , , ,


  1. […] Source: SAP HANA on Power support expands dramatically […]

    Pingback by SAP HANA on Power support expands dramatically | All Things BOBJ BI Blog | December 10, 2015 | Reply

  2. I can confirm that HANA on Power really run good on Power…. Have a customer that before use to run BI on 4 node x86 cluster (80 core) and now run on a P880 on 32 core and the load/batch times is about 50%!!


    Comment by Joakim Bergkvist | December 14, 2015 | Reply

  3. Maybe I misread SAP Note 1995460, but It does not claim you can only have one HANA VM on the server, instead it is my understanding that you can have one HANA VM and any others VMs running on the same server. That applies to any x86 server running supported Vmware versions.

    So this phrase is a little misguided “For those that don’t recall, SAP limits systems running HANA in production on VMware to one[2], count that as 1, total VMs on the entire system.”

    Comment by Alejandro Perez | December 30, 2015 | Reply

    • Yes, you did misread SAP Note 1995460. The title is: “Single SAP HANA VM on VMware vSphere in production” and the first two bullet points leave little to the imagination:
      – “A single SAP HANA virtual machine on a dedicated SAP HANA certified server is supported.”
      – “Multiple SAP HANA virtual machines on a single physical server and scale-out scenarios are not supported in general availability.”

      It does go on to say: “SAP has released use of parallel SAP HANA VMs on VMware vSphere 5.5 and the use of scale-out scenarios into controlled availability, allowing selected customers, depending on their scenarios and system sizes to go live with these configurations.”

      Controlled Availability is not General Availability and often comes with terms and conditions that may be unacceptable to many customers. In order to have more than one production VM supported with PowerVM, IBM had to pass the noisy neighbor test, i.e. where you run two HANA VMs and prove that unacceptable performance degradation does not result from such a combination. After passing this test, SAP released a formal statement of support for multiple VMs with at least one being in production meaning that if a performance problem were to occur with a production VM, SAP would aid in the diagnostics and resolution through normal support processes.

      If VMware has passed the noisy neighbor test with SAP, it is likely that SAP would revise the above SAP note to include GA support of multiple VMs with at least one being in production. Lacking this, it is possible that SAP may approve the use of more than one VM with production HANA, but may elect to deny support for performance problems or place other restrictions on this use. I say may, as SAP has listed the constraints of this controlled availability phase in SAP note 2024433, but this document is not “release”, i.e. normal SAP Marketplace users cannot see the contents of this note.

      Comment by Alfred Freudenberger | December 30, 2015 | Reply

  4. Jan/Feb 2016 Things moved a bit.

    The VMware vSphere 5.5 Controlled Availability program is now GA.
    But the restriction is that you cannot have more than 1 VM per socket. (and with 5.5 the max is 4 sockets per server, but with 6.0 this is going to be more)
    In addition to that, in each VM the HWCCT storage test has to be performed in parallel and yield “green” results.
    So this is a bit of a showstopper for Hana on Power.

    If I look at the IBM Power platform I do not understand the max 4 LPARS with production HANA policy. (3 on the small servers)
    The CPU cores in a Power 8 are about 50% more capable then the fastest Intel EV7 core.
    IBM can deliver up to 96 cores in a single box. (so we can scale up a lot more before we even think about scale out)
    The memory bus is wider and faster than any currently available X86 server.
    Memory capacity is a lot higher than most x86 servers available.
    And the IO path to Storage can be very wide With multple Controllers so to get the HWCCT green with 8 or 16 LPARS running Production Hana should be possible.

    So please SAP talk with IBM and get a testcase up and running….And get GA for max 16 LPARs for Production on a single Box and get rid of this strange max 4 LPARS with Production Hana rule that favor Intel. And not the technical better sollution.



    Comment by Frans Trip | February 16, 2016 | Reply

    • Frans, You are correct. The Controlled Availability of VMware for HANA has moved to GA. I don’t agree that this is a showstopper as all of the previous limitations still exist, e.g. 64 vpus/VM, 1TB/VM, although another controlled availability is ongoing with VMware 6.0 to relieve these a bit. Agreed, the limitation of 4 prod VMs with PowerVM is not clear to you or me, but I suspect that SAP has a rational reason for this. I am in the process of doing some research on this and hope to include the results of my research in a blog post in the near future.

      Comment by Alfred Freudenberger | February 22, 2016 | Reply

      • Any updates already on this matter ?

        Comment by Frans Trip | March 15, 2016

      • Frans, Yes, but the updates are too numerous to include in a reply. I plan on posting a blog entry on the new VMware support in the near future. Please stay tuned.

        Comment by Alfred Freudenberger | March 25, 2016

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: