Blog

Introduction

Early stage – appliances

In the last few years there has been a significant interest around SAP’s most progressive product – its in-memory database product SAP HANA. SAP HANA was announced in 2010 and made generally available in 2011. At the beginning SAP embraced the approach of supporting only hardware appliances for SAP HANA. This meant that all main vendors of hardware equipment had to not only certify but build together with SAP dedicated appliances to provide to customers.

During this period appliances were based mainly on Intel architecture with standard configurations to ensure the right performance is achieved from the new system. This is understandable from a company that has tried to push and establish a new product on the market – ensuring performance and reliability are guaranteed especially for the early adopting companies. Every enterprise product bases its vitality on its first implementations and client feedback.

This, however, brought some implications.

First, the appliance model made the system hard to grow. Appliances were preconfigured hardware systems, ideally populated with memory and disks, which would be difficult to upgrade for more heavy usage. Instead in most cases the whole appliances would have to be replaced, causing not only expenditure issues but also requiring complex projects for stopping the system, backing up and restoring data to the new appliance. Given the fact, that SAP HANA would almost certainly host your most critical applications, this could result in a significant implication for the business.

Additionally, appliances necessitate a specific set of knowledge from a group of skilled people, which might be hard to train, maintain and keep. Almost no usage of existing resources was possible.

Tailored datacenter integration approach

In 2013, SAP decided to launch an approach that almost entirely changed the way SAP HANA implementations were perceived. The so called TDI approach permitted to customers and partners to not only use appliances as hardware basis for their implementation, but also certified server and storage solutions. Also clients could use existing hardware if it was in the list of certified solutions.

TDI resulted in more options for clients to integrate SAP HANA within the existing environments and to start using internally built knowledge on support of the hardware infrastructure below it.

Around this time IBM began to achieve certification for Power systems culminating in 2015 with IBM and SAP announcing the general availability of SAP HANA on IBM POWER Systems.

Comparing IBM Power and Intel based approaches

Low hypervisor overhead.

PowerVM, IBM’s hypervisor for the Power platform provides excellent results when it comes to virtualizing I/O, CPU, RAM and network. All latest studies show that difference between overhead on standard x86 hypervisors and PowerVM could reach up to 15-20% in favor of IBM’s product.

High memory bandwidth.

In a world where bottlenecks start to shift from CPU-disk communication to CPU-memory communication, memory bandwidth is essential. With Power8, servers provide 5 times more memory bandwidth than comparable Intel-based architectures. This will prove even more essential in future, where delta merge processes on SAP HANA become more and more intensive and with techniques like Dynamic Data Tiering that will ensure that only very highly used data remain in memory.

Keeping that in mind, there is no wonder in the fact that IBM POWER 8 is the only platform certified to run 8 simultaneous SAP HANA instances on one physical host (server). Also one of the few to be on general availability for multiple virtualized instances

What does it mean for the clients?

From a technology point of view Power8 should certainly be evaluated and be part of any proof of concept plan. There can also be financial benefits from using IBM Power.

When comparing the memory architectures best practices of Intel and IBM Power differ in one significant point – IBM recommends populating 4 DIMMS per socket, while Intel goes for 8 DIMMs per socket. Both vendors recommend for best performance to utilize same size memory DIMMs.

For a client that means that if using standard four socket appliance from an Intel-vendor there should be 32 DIMMs from the same type and size. For IBM – a four socket system would require 16 DIMMs of the same type and size. This means in most cases more flexibility in terms of upgrading the system, as well as licenses used.

SAP HANA is licensed per GB memory so the usage of memory should be kept as close to the production needs as possible. Deviations in memory usage of 256 GB might mean thousands in operational costs.

Relying on appliances might be a good thing from the perspective the configuration is approved, certified and pre-configured for use. However, in most cases if you chose an appliance close to your initial needs, it might turn out that you have to buy a new one even if you might need a small to medium upgrade in memory.

Moreover, IBM’s SAP-certified virtualization abilities will allow you to host 8 different SAP HANA instances on a single host thus providing you space for your testing, reporting, pre-production environments. This means more savings from investment in hardware.

Combined with SAP HANA TDI approach and IBM’s range of certified storage solution, more financial savings will come reutilizing already existing storage or purchasing storage that is no longer dedicated to just one system.

Considering these aspects you might find that the initial investment in IBM Power may be a little higher than investing in Intel, however, on the long term savings could come from:

• Cheaper upgrades
• Smaller footprint thus less cooling and power
• Usage of existing knowledge
• Easier migrations and updates
• Higher utilization with lower overhead
• At least 4 time more instances for production servers
• Higher reliability from various RAS functionalities of the technology

A sample calculation of savings might look like this depending on the specific environment.