Skip to Content
Business Trends

Optimizing SAP HANA Hardware Cost

One of the questions I hear most often from customers is “How do I reduce my SAP HANA Hardware Cost?”

We are focused on trying to get the best value for our customers, and I know that hardware can form a significant part of the SAP HANA TCO. Here are a few things you can do, to get the cost of your physical infrastructure down.

1) Size & Architect Carefully

We found a lot of customers don’t spend as much time sizing a HANA system as they should. The best way to achieve this is to talk to your account team about our HANA sizing services. We have a set of services available to all customers, to make sure we intelligently size and architect the environments, and we can share reference architectures for your scenario.

There are also sizing tools available like HANA Quick Sizer, which you can access via our Sizing Microsite.

2) Read our Landscape Definition Guide

We have published a Landscape Definition Guide, which discusses deployment models for SAP HANA. If you are looking to build a SAP HANA-based architecture, it’s a great place to start.

It includes Available Deployment Models, Conducting Sizing of Your Hardware, Components, Defining Your Hardware Requirement, Defining Your Cluster Strategy (Scale-Up or Scale-Out), Deciding on Multitenancy and Virtualization Options, Defining High-Availability and Disaster-Recovery Strategy and System Replication Requirements and Change Management.

3) Data Lifecycle Management

In many cases, we find that customers want to move existing systems and re-platform them onto the HANA Data Management Suite. On a disk-based database, the penalty to keeping old, unused data is lower performance and larger storage requirements. With SAP HANA, it can increase the size of the database, and therefore the sizing. Think about the following:

  • Temporary/Admin tables: Many older SAP systems have terabytes of data which are redundant, and can be cleaned up.
  • Data Temperature Management: The SAP HANA Data Management Suite has built-in capabilities for data temperature management, including Dynamic Tiering, which is a disk-based store for cool data.
  • Archiving: Data Archival tools like OpenText are available, which store data on disk or tape. Archival is particularly useful for compliance to GDPR, where data must be retained for a period of time, and then destroyed.

4) Benchmark against the Cloud

The Amazon x1.32xlarge 2TB, 128-core system runs, at the time of writing, at $13.44/hour for an on-demand system, and $3.76 for a 3-year term, which is a pretty amazing price.

Whilst your datacenter or provider might provide better Service Level Agreements (SLAs), this is a good way to think about TCO.

As a note: If you are an Public Cloud customer (Amazon Web Service, Microsoft Azure or Google Cloud), think carefully about using reserve instances to get to the 3-year term pricing, which is 3-4x less expensive.

5) Tailored Datacenter Integration (TDI) Phase 5

When we first created SAP HANA, we decided to specify a core:memory ratio. At the time, it was 128GB/socket. Depending on the requirement, we now support up to 1.5TB/socket, which means for a simple 2-socket system we support up to 3TB.

With TDI Phase 5, we allow you to customize the core:memory ratio or use slower CPUs to reduce cost. This is especially significant in smaller environments, where the cost of high-end CPUs is a big contributor to overall landscape price.

6) Non-functional Requirements (HA/DR)

I wrote some time back about HANA HA/DR, and what I find most often is that customers over architect HANA environments. The business requirements for downtime should define your Recovery Point Objective (RPO, or amount of data lost) and Recovery Time Objective (RTO, or time to get back up and running).

Once you understand RPO and RTO, an architect can define the least expensive system which meets those requirements. I recommend you choose the least expensive option.

Why? High RPO and RTO require more complex environments (think car, not rocket ship!) and more complex environments are harder to setup correctly and may even go wrong more often. Choose the simplest and least expensive option that meets your business requirements.

7) Vendor Comparison

I needed to have a dead tree cut down last summer, and the first quote was terribly expensive. I settled on a price nearly 3x less than the original quote, from an excellent company that is an expert in tree removal.

The same applies when buying hardware: get more than one quote, so you can be sure what a fair market value for your purchase is. In particular, try bringing an outsider in. IBM’s POWER systems are very interesting, as are the various Intel Skylake-based appliances.

In addition, I don’t recommend that the hardware vendor is responsible for sizing and architecture – this provides a conflict of interest. By all means let them make input into it, but make sure you have the expertise to challenge their approach along the way, or you may not get what you need.

8) Hybrid Cloud

One of the most common moves I see today is that organizations look to use the Hybrid Cloud for HANA. You can do Dev/Test in the Cloud (Amazon/Microsoft/Google), and then build Production on-premises, or in a managed cloud like our HANA Enterprise Cloud.

This allows a fast start, and then flexibility down the line. Plus, you can turn the systems off at night if you don’t need them, and save even more.

9) Cost Optimization

When you are done with your initial architecture, you should look at some ways to optimize cost. Here are a few thoughts to get you started:

  • Multiple Components on One System (MCOS). You can run multiple databases on one HANA host, especially for non-production systems. This is a good way to consolidate multiple development systems, or spin up test systems.
  • Multiple Components on One Database (MCOD). In some cases, it makes sense to run multiple schemas on one database. Be careful here as they can be hard to split out.
  • Multi-tenancy. You can run multiple database containers on one HANA instance. This is memory-efficient, but you all containers need to run the same HANA version, so be careful not to run Dev and Test on the same tenant.
  • Homing QA and DR together. It’s possible to run your DR system in low-memory mode and run a full size QA on this system. This has the disadvantage that it increases RTO of the DR system, but a significant cost advantage. In most cases, business requirements for DR are 36-72 hours, so there is zero business impact of this.

10) Perform a Sanity Check

When you’re done sizing, does it make sense? Did it give you an answer like 2TB for your 5000 row analytics store? Is it 200x smaller than what you have today?

In addition, remember if you are buying in the cloud, you don’t need to size 3 years from now. You can run a small system today, and grow it when the database grows. There is literally no benefit of renting a system too big in the cloud.

If it feels wrong, go back and challenge the team that put it together: sizing always feels right, when it’s done correctly.

Final Words

At SAP, we have always focused on open innovation. We offer a ton of choices for HANA: IBM Power or Intel, RedHat or SUSE Linux. We offer an appliance approach or the TDI build-your-own approach. Enterprise Storage. Hybrid Cloud. Public Cloud. Private Cloud. Of course, on-premises.

There are 1339 supported appliances today, from 14 vendors: Bull, Cisco, Dell, Fujitsu, HP, Hitachi, Huawei, Inspur, Lenovo, NEC, SGI, Super Micro, Unisys and VCE. We support TDI approaches from IBM POWER and 10 of the x86 vendors. We support all the major storage subsystems and all of the cloud vendors.

Whilst I’m a huge believer in the choice we offer customers, it does mean there are a lot of options when sizing and architecting a HANA environment, and some of these choices can cause you to spend more than you need to (or less, and end up with an inadequate environment).

So if you feel lost, simply get in touch with your account team, and they can explain our options for HANA Hardware Sizing. We have some free services as well as deep dive consulting and architecture packages. It’s important to us that you get the amount of HANA that is best for your business.

11 Comments
You must be Logged on to comment or reply to a post.
  • I am surprised to not see anything about archiving.
    Do you really need all the data you have?
    should be one of the top question before engaging in HANA Journey.
    it might take some time to agree on archiving policy with all business owners.

  • John, This is an informative and structured list of ways to reduce the h/w TCO of SAP HANA deployments, naturally there are alternative ways to reduce the overall TCO of SAP Business Suite / NetWeaver and/or SAP BW implementations, including for example implementing Db2 BLU in-memory columnar with SAP BW 7.40 Flat InfoCubes which provides similar or greater throughput to HANA but with fractions of the required hardware capacity (Cores, Ram and/or TB SAN), enabling SAP Clients an AnyDB platform choice (Intel / Linux, Windows, AIX, i/OS, Z/OS including a choice of industry leading Hypervisors like like VMware, PowerVM, z/OS), but without forcing O/S DB migrations and/or HANA 1.0 to HANA 2.0 platform transition and/or appliance / OS upgrade costs. Tim

    • I don’t recommend implementing DB2 BLU – it is a stopgap solution to customers looking to get some extra reporting performance whilst they plan to move to HANA.

      Much better to go directly to HANA and skip this step, which requires extra hardware and which does not improve many scenarios, like simplified ETL, data modeling, real-time data, planning, and complex reporting scenarios, many of which BLU does not accelerate.

  • Hi John, TDI Phase 5, to me still not quite clear what it means with regard to (strict) socket – memory ratio’s for PRD BWoH and SoH on physical and vm servers and also for the socket allocation when hosting on VM ware (VM configuration 4 socket server:
    0.5, 1, 2, 3 and 4-socket VMs, maximal 8 SAP HANA VMs per 4 socket server).

  • Hi john,
    If I am certifying a separate SAP HANA Appliance from a non-HW vendor, do I need to permanently send some of the certified servers to SAP?
    Could you check if this is true?

    • Hi John,
      If I apply for a SAP HANA Appliance certification from a non-HW vendor, how will I handle the HW after certification?

    • Hey JaeHan,

      If I understand correctly, you are a HW vendor who seeks to do certification? If so, drop me an email and I can connect you to the certification team.

      If you are a customer who wishes to certify equipment from a HW vendor who is not certified, I’d recommend you ask the HW vendor to do certification.

      John

  • We are looking to migrate existing SAP BI NW 740 running on ASE Sybase 15.7 to Hana Database. We already have Hana MDC database running EhP 7 of ERP 6.0 database, can we create new tenant database and use to for SAP BI NW 740. The HANA Database server has 2 TB of RAM out of which only 600 GB is used and as per sizing report ran on existing BI on ASE Sybase the RAM requirement for migration for BI to HANA is 500 GB.
    Do we need to increase CPU and Harddisk on existing Hana server for this too.