Disclaimer: I work for Hitachi Data Systems. However this post is not officially sanctioned by or speaks on behalf of my company. These thoughts are my own based on my experience. Use at your own discretion.
Did you know that the world’s largest SAP HANA implementation runs on Hitachi servers and was installed by HDS. It’s true, and the whole area of in-memory database systems is growing rapidly.
Before I begin I have to give a shoutout to my colleague Sander who works in my team as an SAP SME. I’ve learned a lot about HANA from him – otherwise I would know just the basics. He doesn’t blog so I thought I’d put some info out there.
One of the biggest areas where HDS is focusing is on SAP HANA and the partnership with SAP is of strategic importance, just like it is with VMware. And it’s true to say this is an area where Hitachi has technical leadership.
Just as I’m writing this another massive deal has been signed based on Hitachi (SMP) blades and our Global Active Device (GAD) technology. You can read more about GAD here.
For any customers looking to deploy HANA I suggest you contact HDS as in this area HDS has many advantages that are black and white. There are many design criteria to consider when running HANA to guarantee performance, and HDS qualified limits are higher than competitors from a compute and storage perspective. In some cases our competitors don’t have a competing compute offering so it’s even more compelling.
I should mention that at the moment the ability to use vSphere for HANA is slightly limited mainly due to SAP limitations regarding what is and is not supported. This will undoubtedly change especially thanks to vSphere 6 and the increased VM and host limits of 4TB and 12TB respectively.
What is HANA ?
In case you don’t know, SAP HANA is SAP’s relational database that runs in memory. It’s a compelling technology for a number of reasons, mostly due to speed of query, massive paralleism and smaller footprint. The figure of queries running 1800 times faster is being widely mentioned.
It stores data in columns so it is called a columnar database. This has the effect of a massive reduction in required storage capacity due to a reduction in duplication of stored data.
Pre-reqs
HANA has some particularly important pre-requisites for performance both in terms of memory and back-end storage, and very careful qualification is required.
In the Hitachi UCP stack, currently the CB500 blades are supported in our UCP Director which is the fully orchestrated converged platform. This is a 6u 8-blade chassis with all blades half-width in form. This is not the subject of this post really – in this one I want to talk about the CB2500 chassis and how you might use it.
Let me refer you to my colleague Nick Winkworth’s blog announcing the release of the Hitachi CB2500 blades here for a little more info on use cases etc.
Here’s a picture of the chassis:
How can you use the CB2500 chassis ?
The CB2500 chassis is 12U in height which might seem quite large until you understand what you can do with it.
On the chassis, you can have:
- (Up to)14 half-height CB520Hv3 blades with a maximum of 768GB DDR4 RAM each. These have Intel Xeon E5-2600v3 series inside.
- 8 full-width blades that can hold up to 1.5TB each when configured with 32GB DIMMs, or 3TB each when configured with 64GB DIMMs. These can have Intel Xeon E7-8800v2 series processors inside.
Data Locality and SMP
When you start using in-memory databases and other in-memory constructs this is where SMP and LPARs can become important.
- SMP = A single logical server instance spanning multiple smaller servers
- LPAR = A logical hardware partition of a server on which a single OS can run
There is an obsession with data living close to the CPU these days. Some of this is just marketing. The reason I say this is that if you use a suitably sized fibre channel array the latency can be so negligible as to be irrelevant. Also for typical business-as-usual use cases this is typically not a consideration.
However for applications like HANA it’s of particular importance. And this is where scale-out systems can trip up. How do you create a single 6 or 12TB HANA Scale-Up instance on a hyper-converged architecture and protect this with HA ?
The answer is you can’t right now.
Subdividing SMP
In relation to SMP technology, when you create a larger SMP instance you can still subdivide this into LPARs to maintain further flexibility.
Take 8 full-width dual-socket blades for example and subdivide into:
- 4 x 4-socket blades
- 2 x 8-socket blades
So if you plump for larger blades you can create logical blades from these. Furthermore, in a single SMP instance comprising 4 CB520X blades you can have 192 DIMMS of 64GB in size totalling 6TB of RAM.
You can protect this inside the same chassis with Hitachi N+M failover.
Multiple chassis can be connected together to create larger instances. We currently a customer running a 12TB+ in-memory database instance spanning multiple chassis.
Summary
Running in memory requires us to go beyond the limits of one box if we want to address the required amounts of memory for the largest use cases, where right now vSphere cannot meet these requirements. This is not entirely related to vSphere limits but is more related to what SAP do and don’t support.
This is where the ability to link multiple blades together using Hitachi SMP is a powerful tool in the next generation of systems which will use memory as the primary storage tier.
330 total views, 1 views today