“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!

HANA – Winning with IBM POWER

IBM Power + IBM Storwize solution beats Intel based solution + competitive storage platform to migrate clients SAP ECC environment to Suite on HANA … for less money!

The Business Challenge: A $4B manufacturing company decided to migrate their AnyDB to Suite on HANA; but on which platform? 

The Competition: The client evaluated a TDI solution from an Intel based vendor + major storage vendor as part of a converged infrastructure solution as well as a TDI solution from IBM Power + IBM Storage. The SAP Basis Manager favored an Intel solution; either in the cloud or on-premises based on the perception is was the lowest cost, optimal platform for HANA with comparable features to the other choice.

The Evaluation: I was the Client Executive and Executive Architect for my team, leading the design and competitive effort. The clients initial objection to IBM Power stemmed from their view of the current platform running SAP ECC. Though it had done so, with virtually no issues for 20 years, they viewed it as expensive, inflexible and legacy. This was largely due to the fact they had not implemented all of the virtualization capabilities, having allowed the system to grow with dedicated resources. Also, due to some in-house mistakes with the current storage, their answer was to buy more hardware vs tightening up their own internal procedures plus key individuals taking ownership for the mistake which led to the problem.

The clients SAP team thought this would be a simple exercise. Get the Intel solution price and the IBM Power solution price, present to management for the rubber stamp to move off to the next phase, migration prep. Only there was a problem. the Intel solution costing was coming in higher than expected. The AnyDB size of 24 TB reduced down to ~4.1 TB, even to 3.6 TB with cleanup, per the SAP Quicksizer. True story – the Intel team proposed they start with 3 TB systems to get them on the floor, then wait and see if they truly needed more. Thankfully, the client didn’t accept this generous offer, requesting they quote 6 TB systems as that was the next increment. With IBM Power, you can configure DIMMs to more closely match the required capacity as the platform does not have the memory placement requirements (and limitations) as Intel platforms do. This client further required all environments be sized for the full HANA DB copy, which had grown from 4.1 TB to 5.1 TB (plus OS taking it to 5.3 TB). Good thing they didn’t go with those 3 TB Intel systems, eh?

The Intel solutions configured every HANA DB environment as bare-metal because the memory requirements didn’t support VMware for virtualization. It wasn’t an option due to the VMware maximum memory requirement was less than the client required. The memory sizing also pushed the Intel solution into larger servers with more sockets. The environments consisted of Sandbox, Dev, QA and Production. Each had a full memory sized HANA DB on bare-metal servers while they did use VMware to host the NetWeaver application servers; though again, they had multiple ones for each environment. I don’t know the exact numbers but believe they were north of 16 Intel servers with 10 of those configured as 6 TB bare-metal servers.

The IBM Power solution consisted of 3 x POWER9 servers. Yes, 3. Everything was fully virtualized, designed for maximum resiliency and serviceability. 2 smaller POWER9 servers for Production, each hosting 1 HANA DB + 2 NetWeaver VM’s for Production. DR hosted a server with 3X the capacity of the Production server. This single, highly performant and reliable server was configured for 17 VM’s. Sandbox, Dev and QA each had 1 VM for HANA DB and 2 VM’s for their NetWeaver App servers. Prod had 1 VM and 2 NetWeaver App servers for failover plus 2 VM’s for the Dual Virtual I/O Servers (VIOS). At each site, the servers were connected to an IBM flash storage solution using redundant IBM branded SAN switches.

The Decision: Management was presented with both options. Feedback was given to the SAP team. My team didn’t do anything but wait as the word was the Intel team was scrambling to “fix” their numbers. Updated pricing was presented to management and a decision was made. They chose the IBM Power solution running SUSE Linux with the IBM Storwize all flash storage for their Suite on HANA solution. Their justification was simple. The incredible reliability and performance record of the existing IBM Power spoke for itself – they had actual experience running SAP on it, albeit not HANA but who was I to split hairs. Secondly, and probably most important, the IBM Power solution was at least 35% less costly than the Intel solution. By the way, I had submitted a proposal for the migration services as well. Going up against a couple of big players. I won … beat them by 30% as well.

In Conclusion: though management didn’t know at the time, or at least couldn’t fully comprehend the benefits they would obtain with the virtualization capabilities which come with IBM Power servers that are #NoCompromise as this would play a key role during the 6 month migration window allowing their consultants and business leaders flexibility to provision, change, update, modify (you name it) and more the many requests which came up suddenly without downtime, added cost or delays.

I oversaw the implementation and migration effort, which started by ensuring the solution was properly designed with all of its pieces, ordered and the client environment prepared. Then, working closely with the migration team, ensuring we understood each others roles, not just our but the platforms capabilities as well as the current and future timelines. Took this all the way to the final Go-Live migration which went off like clockwork. Down at 10 pm Friday night. Migration done by 7 am Sunday morning. Clean-up and other details tended to to Go-Live by 4 pm Sunday afternoon. And they haven’t had to take an outage since … at least not for anything hardware related.

Reach out if you want to learn how my team designs world class systems, using world class assessment tools and migration techniques which allow our solutions to be optimized, faster, efficient and ultimately lower cost.