“Let’s buy new & get less!”​ said no one ever, yet …

When you see data and it doesn’t make sense or there are differences so significant which make you want to know why? This blog does just this. When looking at the results for 2 different platforms, I had more questions than answers. How can one platform outperform another by so much and if it is accurate, who in their right mind buys the slower model? Nobody buys a tablet, laptop, vehicle or anything which they know will be intentionally slower vs alternatives.

Everyone reading this article is a consumer and as consumers when you bought your last vehicle did you set out to purposely buy that vehicle for it to underperform your current vehicle? Less fuel economy decreased reliability and slower acceleration. Likewise, when looking at different manufacturers and models of the same model year, do you seek the model that underperforms?

No, this isn’t what any of us expect. If you could buy a vehicle that was more reliable, had better fuel economy and faster over another of the same model year, that is very compelling.

Benchmark Observations

As I look over the SAP SD benchmark results for HPE models ranging from 2 sockets, 4 sockets, 8 sockets and 16 sockets I can’t help but make some observations. Likewise, when looking at IBM POWER9 results, some of which are unpublished I can’t help but also make some observations.

Tale of Two Platforms

General observations are this. HPE Intel systems deliver less performance on systems with more sockets. It ranges from just over 2% to over 40% decrease in per-core performance. Regarding POWER9, per-core performance increases going from 2 to 4 sockets by 2.5%, is essentially flat between 4 and 8 sockets and sees a 4% decrease in per-core performance from the 8 socket to the 16 socket model.

Looking only at the Intel results, there is obvious pressure on the scalability for their servers as they scale from 2, 4, 8 and 16 sockets. This isn’t unique to HPE by the way as every Intel vendors results which I looked at exhibited similar results, though my analysis was not exhaustive. Then, if we look at the POWER9 results, they show near-linear scaling regardless of the number of sockets.

Oh My!

The last observation is what I call the ‘foot-race’ results. POWER9 outperforms the other HANA alternatives, anywhere from 220% to 356% per core on systems with the same # of sockets.

S is for Scaling

Of course, POWER9 cores offer SMT8, which is 8 threads per core of parallel and simultaneous execution. SMT is configurable by VM and not the entire server as is the case with alternative systems. For POWER9 VM’s using 96 cores or less, SMT8 is supported. For POWER9 VM’s with more than 96 cores, SAP requires SMT-4 be used. (SAP Note: 2188482). This means a 2 socket 24 core POWER9 server or VM would deliver 192 threads while a 96 core VM would deliver 768 threads. SAP HANA loves threads. The more available, the greater the potential for increased throughput and performance.

Fill in the blank “_orrible”

Regarding Intel systems and threading. Intel’s threading technology is called hyperthreading. It only provides 2 threads per core if enabled. When disabled, there is 1 thread per core. SAP Notes 2100040 & 2711650 state hyperthreading should be disabled for systems with more than 8 sockets. Regarding any size system and hyperthreading, SAP’s position is to go with what each system manufacturer suggests. They have an opinion and recommendation on virtually every aspect of the SAP platform but with this one hot-button issue, they are choosing to pass the buck. For systems using virtualization on Intel systems. VMware in SAP Note 2393917 and VMware KB 55806, they recommend hyperthreading be disabled where the number of vCPU’s match the number of physical cores in the server. Red Hat Virtualization 4.2 states explicitly that hyper-threading must be disabled in SAP Note 2852117. It goes on to say that you should increase the capacity or sizing of the server to compensate for the loss of disabling hyperthreading. Maybe this bumps you from 4 to 8 sockets, who knows.

Is doubling the server a good thing?

This means a 2 socket 56 core server, running bare-metal would deliver 112 threads or if you chose to disable hyperthreading due to the many security vulnerabilities, there would only be 56 threads. Thus, to achieve 112 threads, it would now require a 4 socket server with 112 cores … it’s easy now to see how the project costs could escalate because of these many limitations and restrictions. A 4-socket server with 112 cores and hyperthreading enabled delivers 224 threads, just a few more than the 24 core POWER9. Interesting it would take 112 Intel cores to offer slightly more threads than a 24 core system. Mind-boggling. Continuing on, an 8 socket server with 224 cores offers 448 threads, slightly more than half offered by 96 POWER9 cores. It is pretty clear, the loss of hyperthreading due to the seemingly neverending discovery of new security vulnerabilities with Intel processors appears it will get worse before it gets better.

Summary

As stated, these are just my observations of the two platforms. Other than the obvious per core performance differences, the intent of this article is to provide the reader with information allowing for responsible business decisions. Because who intentionally sets out to buy an underperforming, less reliable, more costly vehicle? As a consumer spending my own money I sure do not and when I am charged with spending my companies money, I also want to be responsible as if I were spending my own.

To learn how to get the most benefit from technology to support your enterprise workloads such as SAP HANA and about Clear Technologies, please visit Clear Technologies SAP Practice. To learn more about our 3 core businesses: Clear TechnologiesVisual Storage Intelligence, and our AI practice; Clear Intelligence.

SAP HANA on … #ChooseRight

Window of Opportunity

IBM Power systems started late in the SAP HANA market, on standby if you will when IBM still had their System X business. Once they sold off their x86 business, it opened the door for IBM to work with SAP to offer clients a 2nd platform choice especially with many ECC shops coming from Enterprise platforms and now their only option is to deploy their most critical business application on Intel.

With thousands of clients running SAP ECC using Oracle or DB2 on AIX or running IBM I, there is a large and experienced install base. IBM’s move to support Linux little endian natively beginning with POWER8 eased any development concerns SAP may have had. IBM Power has been fastest adoption for a platform after the initial SAP Ramp-up Program.

Rapid Growth

After the initial Ramp-up program, SAP announced the first GA of HANA for IBM Power in 2015. Since then, it has been the fastest adopted platform by clients to run SAP HANA.

Whether deploying a Greenfield or Brownfield SAP HANA solution, what makes IBM Power such a better platform for SAP HANA over Intel based systems? It starts with its DNA. IBM Power was born an Enterprise system, in the data center running mission critical workloads. Read the Forrester Total Economic Impact of IBM Power Systems for SAP HANA study how they rate the platform.

Flexibility, Performance & Resiliency

  • SAP Certified HANA Prod OLTP – 24 TB Scale-up
  • SAP Certified HANA Prod OLAP – 24 TB Scale-up
  • SAP Certified HANA Prod OLAP – 24 TB Scale-out
  • SAP exceptions available upon request
  • Up to 16 Production VM’s on E950 & E980
  • POWER9 servers can scale up to 64 TB of Memory
  • Highly resilient memory offering DDDC+1+1
  • Memory sparing, spare chips, ChipKill
  • HANA is always virtualized using the integrated IBM PowerVM hypervisor
  • Live Partition Mobility
  • Dynamically add / remove cores and memory
  • Supports TDI 5 delivering greater SAPS per core, up to 2X+
  • Offers Elastic Capacity on Demand activations of cores & memory
  • Highest Reliability excluding Z for 11 years per ITIC
  • Concurrent maintenance features for firmware, drives, PCIe adapters, fans and power supplies
  • Concurrent maintenance for the I/O path from VM to SAN and network when using Dual Virtual I/O Servers
  • Dynamic tuning & optimization
  • Supports SAP Native Storage Extension and Fast Restart
  • IBM Storwize storage is optimized for SAP HANA on POWER

Additional features to be announced any day (Nov 5, 2019 is todays timestamp).

  • Persistent Memory at no additional cost
  • Persistent Memory with no performance degradation
  • Use of Shared Processor Pools for Production in addition to existing support for non-Prod
  • RHEL 8

Clients will deploy fewer systems, while able to host more workloads per system, whether those are legacy SAP ECC, SolMan or non-SAP workloads such as legacy Oracle workloads or possibly new Cognitive workloads.

Bringing it ALL together

SAP HANA; whether Suite or BW on HANA or S/4HANA or BW/4HANA, businesses tend to focus on the application, discounting the infrastructure as commodity – it’s all the same. With SAP HANA, designed as a scale-up in-memory technology, IBM Power is the optimal platform to host it.

  • Primary benefits such as fewer systems with greater utilization.
  • Secondary benefits such as less infrastructure and data center services required, i.e. fewer network & SAN ports, fewer power plugs with lower electrical consumption requiring less to cool.
  • Tertiary benefits, often more difficult to quantify such as the downtime the business did NOT have to take to perform a maintenance action such as updating firmware or adding an adapter for additional capacity.
  • Other actions such as downstream activities impacting the I/O paths like a network switch service event can all be accommodated with a properly architected and deployed Power solution.

These foundational capabilities allow the business to remain on schedule, consultants continue to work and not be idle.

#ChooseRight

There are only two options for SAP HANA. One option is the platform forcing you to choose one feature for another making every decision a compromise. The other option is the platform offering complete flexibility, scalability and resiliency with no compromises as even IDC states in this whitepaper. No one wants to go back to their board asking for more money admitting they made a mistake, undersized or failed to anticipate something, so #ChooseRight!