Hands-on experience with Hana on Power
The "appliance Hana system" meant that customers who were used to a classic system being deployed in our private cloud within a few weeks had to wait well over a month for a Hana system, because the appliance first had to be built at the manufacturer's in the respective size, flown in and cleared through customs before it could be installed in our cloud data center.
Then there was the problem of inserting a "bare metal" system as a "customized special lock" into an environment that was optimized for standardization, virtualization and automated deployment. Not to mention monitoring, patching and expanding.
Hana T-Shirt Sizes
The rigid restriction to T-shirt sizes also meant that no fine-tuning to customer needs was possible; unfortunately, flexibility is a foreign word for appliances! You always had to round up the memory and guess what the customer might need in three years, which of course led to much higher procurement costs.
With many customers, we also faced the problem that their main memory requirements then increased much faster than expected. However, the only way to "upgrade" an appliance is to physically add more DIMMs and CPUs - if the originally selected motherboard still had room for them. If it didn't, a larger appliance had to be purchased.
Never Touch a Running Appliance
Here we had to make the experience that the old computer wisdom "Never Touch a Running System" is still valid. Since additional DIMMs and CPUs have to be pressed into their sockets with a certain amount of force and the motherboard bends a bit in the process, it was possible that a plug popped out of the socket at another point.
Then, when trying to boot up again, suddenly all the fans were no longer operational or the system could not be brought back to life at all, again necessitating the deployment of vendor service engineers - all while the customer was waiting to get back to work!
All in all, an unsatisfactory situation for all involved - Hana as an appliance was simply a contradiction to the cloud. Perhaps one reason for the low implementation figures for Hana in the first few years.
Tailored Datacenter Integration
Fortunately, with the help of some large customers, the hardware manufacturers were able to gradually persuade SAP to soften the rigid appliance model. In the first phase, external storage arrays were allowed to be used instead of internal disks, later the cheaper E5 processors were allowed to be used for small systems, followed by support for VMware and finally IBM Power - all under the label: Tailored Datacenter Integration (TDI).
Tailored suit instead of straitjacket
This also gave us the opportunity to provide SAP's existing customers with a flexible tailored suit instead of an off-the-shelf straitjacket, which also fitted into a modern private cloud environment. But on which platform?
A comparison of Intel's restrictions with VMware versus IBM Power with "built-in" virtualization revealed differences in the possible size and number of virtualized Hana systems.
In addition, several customers had signaled that they needed considerably more memory than the 3 TB possible on the usual 4-socket Intel systems at that time. And the whole thing "as single instance as possible", since they hadn't exactly had the best experiences with scale-out.
On this basis and due to the company's existing experience with IBM Power, the decision was made to procure two machine types: the S824L for Hana systems up to 2 TB and E880 for everything larger. Later, an E850 was added, which with its 4 TB established itself as the ideal "bread and butter" workhorse.
In the "Linux only" version, as required for Hana, Power machines are also considerably less expensive than for AIX. This decision proved to be a complete success within a short time - both from a technical and a commercial point of view.
Virtualization
Due to the virtualization originating from the mainframe world (who still remembers MVS?) on firmware level, the losses otherwise usual with 3rd party virtualizations due to additional latencies especially in the IO could be avoided - for Hana this means "bare metal performance".
Both memory and CPU power can be customized down to 1 MB and 1/20 core levels. Since Hana systems typically require only a fraction of the CPU power specified by SAP rules as "scare steel," the excess CPU power can be put into a pool shared by all Hana systems running on the machine. (Scared steel is what civil engineers call a completely oversized reinforcement of reinforced concrete to be "one thousand percent" sure so that the builder doesn't file a lawsuit because of cracks in the wall). This can be used for a system that needs more power than expected, without any additional costs for the customer.
In principle, you could also dynamically adjust the memory if Hana did not try to access resources that are no longer available after a reduction in memory. Therefore, it is recommended to restart Hana when memory resources change.
LPAR Live Mobility has proven to be particularly beneficial, enabling even very large Hana systems to be moved from one machine to another during operation.
Even though the Power hardware is extremely stable, it is statistically possible that a problem will occur in a larger machine park that requires the replacement of a component. Fortunately, all problems that have occurred so far have been kind enough to announce themselves in advance, or have been intercepted by redundancy.
As a result, thanks to Live Mobility, we were able to clear the machines in question of customer systems while they were running, replace the motherboard or network card in question, and then move the systems back without the customer noticing.
Even a complete change of architecture from shared cluster to SAN boot, where each individual machine in the cluster could be cleared and reconfigured once on a rolling basis, was possible without impacting customer operations.
Memory Tetris
Sales and customers were particularly enthusiastic because, with a little forward planning, it was always possible to keep enough reserves to make even medium-sized Hana systems available on an ad hoc basis by filling up free slots on the machines. And if there was no free slot large enough on any machine, it was always possible to free up enough by castling smaller systems.
The whole thing is very reminiscent of the computer game Tetris, in which blocks of different sizes "fall from the sky" and have to be distributed in such a way that a "densest ball pack" is created.
That's kind of what we do in Hana operations. What falls "out of the blue" are customer requests for new Hana systems of any size, all of which are supposed to be available yesterday.
As in a computer game, clever distribution ensures that the memory of all machines is utilized to almost one hundred percent in the shortest possible time, which in turn pleases the CFO, even if he constantly complains professionally that new machines have to be bought every few weeks to get free slots again due to ever increasing customer demand.
By cleverly reallocating memory, it is also possible to adapt the running customer systems to the real demand. Via our "Hana Memory Observatory", we can give SAP customers a forecast of when it will be necessary to allocate more main memory to a Hana system in order to avoid the notorious aborts of large reports due to "Out of Memory" (OOM).
What many customers also appreciate is that they can also use larger Hana systems temporarily for PoCs. When the PoC is over, the resources are returned to the pool and no further costs are incurred.
This means that even with large Hana systems, customers only ever have to pay for what they currently need - in stark contrast to cloud providers, where you have to book and pay for large Hana instances that don't fit on their standard blades three years in advance.
The only downside here is that 4096 GB are not available on a power machine with e.g. 4 TB, since the virtualization itself consumes some GB. In most cases, however, it is possible to agree with the customer that 1 TB equals 1000 GB - then this works quite comfortably.
With the new IBM Power 9 machines, which provide a maximum of 16 TB with 4 sockets and 8 TB with affordable DIMMs, the possibility of optimizing the system landscape is further improved.
Conclusion
With Hana on Power, we have succeeded in integrating Hana flexibly and cost-efficiently into a private cloud, thereby enormously increasing the satisfaction of customers, sales and also the finance department.
Flexible system sizes, fast availability of new systems and temporary use of resources please customers and sales, an almost complete utilization of investments in a short time the finance department. In addition, we can offer larger Hana systems with 7-by-24 operation at a much lower price than any public cloud provider.
This is reflected in constantly increasing installation figures. Currently, our Hana on Power system landscape is growing by 1 TB per week with a tendency to double due to constantly new customer installations. Hana on Power is Hana as you would expect it to be in a cloud - we at Syntax (formerly Freudenberg IT) call it flexHana.
