It is always a pleasure to see SAP HANA maturing. Long desired features get implemented and support for more and more SAP software on top of SAP HANA is released. I even see more and more HANA appliances in the wild, doing actual work! The adoption rate could be higher, of course. It seems most SAP customers are quite reluctant to migrate their BW systems to SAP HANA (let alone migrating their ERP or other business suite systems to SAP HANA). What are the reasons? What is needed to make SAP HANA a quick and huge success in the marketplace?
Where is the mass market?
From my limited experience so far, the large Single-Box HANA Appliances sold pretty well. Scale-Out HANA Appliances were only available later, but this doesn’t give the whole point. As soon as you need scalability, high-availability and/or disaster tolerance, then you have no other option but go for a Scale-Out HANA Appliance. And this is exactly a crucial point. What are the majority of the SAP BW instances? They are smaller than you might think: Their average database size is around 2 TB. Of course, Scale-Out HANA Appliances are important and required for providing scalability for the large and huge SAP BW systems, but from a sizing point of view, a 1 TB HANA Appliance should suffice for 85% of the SAP BW instances!
Coming to think of it, there is a significant difference in the hardware between a Single-Box HANA Appliance and a Scale-Out HANA Appliance. This might make prospective administrators and controllers shy away unnecessarily. Most SAP BW systems simply need high availability features and many require also some disaster tolerance. I just wonder why SAP doesn’t fullfill such needs in an easier way?
A personal prediction from 2011
I can remember very well the early presentations from Hasso Plattner about HANA, as well as how thrilled I was about the whole idea. Using industry standard CPUs with a very good price/performance ratio, on commodity servers, on an open source operating system. Nothing really special or magic is needed except the very special SAP HANA database. It was clear from the very start that SAP HANA is a database, albeit with some non-standard additional features. For the Single-Box HANA Appliances this “commodity hardware” setup is true, but for Scale-Out HANA Appliances reality requires its toll. SAP made a wise decision to engineer SAP HANA as a distributed database right from design. If only the dreaded shared file systems or storage replication wasn’t required. My favorite slogan is “keep things simple” wherever possible. So why not provide rudimentary high-availability features also for Single-Instance HANA Appliances?
Two years ago I wrote a SDN blog post where I tried to catch the attention of SAP people involved in HANA development:
Reading my blog post again, now that I have seen some HANA implementations and spoke with prospective customers, I feel there is nothing to add. There is still a justification for near-zero-downtime migrations via HANA to HANA replication.
SAP HANA for the masses
So this is my favorite reference design of how SAP HANA would look like (and which would sell like crazy):
1. A Single-Box SAP HANA Appliance with 1 TB RAM.
By the way, it would be great if a Single-Box SAP HANA Appliance with 2 TB RAM was available as well. If the only reason why SAP doesn’t support 2 TB is that 80 CPU cores aren’t sufficient, then please SAP: Perform a field study about HANA RAM and CPU utilization. I bet: For small and mid-range BW systems you could be more relaxed on this. A 2 TB Single-Box HANA Appliance could alleviate the sizing issue significantly.
2. Maybe least important: Simply reuse existing SAN switches. This wouldn’t add to the SAP HANA costs. Also a 10 Gbit Ethernet infrastructure might be already available to build on.
3. An entry level disk array.
Now this message is specifically to SAP: “Please repeat after me: SSDs have no advantage whatsoever for sequential writes!” Am I missing the point completely or is this so hard? SAP HANA is about performance, but I always failed to understand the necessity of SSDs in a SAP HANA environment. SAP’s requirement to put the HANA log areas on SSD drives is simply ridiculous. Thanks, that said now I feel much better.
A simple entry level disk array or maybe midrange disk array with dozens of cheap SAS disks should suffice for SAP HANA. RAID5 for the data area and RAID1 for the log area, distributed over sufficient disks to guarantee the performance and you are done with it. I prefer a dedicated disk array to eliminate the possibility of collateral damage, which might happen on shared disk arrays.
4. Software Replication
This is the only new thing. If you know Oracle RMAN and DataGuard, then that is the concept. SAP HANA should allow cloning of instances via replication over the network. Once the shadow database is in sync it gets the changes from the primary database synchronously. Initially I had hoped that the SLT software might allow such a feature, because HANA to HANA replication would be the next logical step. I heard rumors that SAP is already working on such a HANA to HANA replication. Once more I have to be patient. Depending on the actual implementation, HANA to HANA replication could allow downtime-minimized migrations, basic high availability and maybe even disaster tolerance. HANA would be active on the standby node (“hot standby”), thereby the HANA standby node couldn’t be used for other tasks. This is a negative issue of this design, but the setup should allow for updating the OS or HANA revisions with only a minimal downtime!
In summary, the setup could satisfy the needs of most SAP BW customers for implementing SAP HANA. The same is valid for many Business Suite systems. It is still too early to decide about an ideal SAP HANA solution for ERP. SAP ERP is on a completely different plate when considering the architecture. (And I also need topics for further SCN blogs!) With my proposed setup you are definitely limited on scaling, but you can enjoy all other SAP HANA benefits, while running the commodity hardware, a popular standard OS and your familiar infrastructure.
Please note: All ideas and opinions are strictly my own. I could very well be mistaken on some points, so I hope for helpful comments below.