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.
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.
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.