This series is available as PDF download (English, Spanish and French) at the bottom of the page.
Our customers were accustomed to having traditional SAP systems delivered by our private cloud in just a few weeks. Because of SAP’s appliance concept, however, the customers had to wait way over a month for their Hana systems. The appliances of a given size had to first be manufactured, delivered, and declared at customs before they could be integrated into our cloud datacenter, after all.
But once the appliance was finally in our datacenter, the ordeal was far from over. We had to integrate a bare metal system as customer-specific appliance into an environment which was optimized for standardization, virtualization, and automated deployment. Not to mention monitoring, patching, and customizing.
Hana T-shirt sizes
Due to the rigid limitation to T-shirt sizes, we were also unable to customize the system according to customer-specific needs. Unfortunately, flexibility is a foreign phrase for appliances! We always had to round up memory and guess what the customer might need in three years. This naturally led to significantly higher costs.
In many cases, the customers’ demand for memory increased faster than expected. The only way to “upgrade” an appliance, however, is to physically install more DIMMs and CPUs – if the given motherboard can even support them. If that wasn’t the case, we were forced to order a bigger appliance, leaving a system behind with no use for the customer.
Never touch a running Hana appliance
But even if an upgrade was possible, as practical experience proves, the old saying in IT “Never touch a running system” still holds true. Additional DIMMs and CPUs have to be pushed into place with some force, which causes the motherboard to bend a little.
Consequently, other connections might loosen a little or disconnect completely. In some cases, cooling fans don’t blow, or the entire system doesn’t boot at all. The manufacturer’s service technicians had to be called – while the customer is still waiting to be able to resume his business!
All in all, Hana as appliance was an unsatisfactory solution for everyone involved. The whole concept simply contradicted the very idea of cloud computing. Maybe this caused the low implementation rates in the first years of Hana.
Tailored Datacenter Integration with Hana
Fortunately, hardware providers and major customers were able to convince SAP to leave the rigid appliance model behind – step by step. In the first phase, customers were allowed to use external storage arrays instead of internal ones.
After some time, customers with small systems were even allowed to use the more cost-efficient E5 processors. Last but not least, SAP allowed support for VMware and IBM Power – all under the label of Tailored Datacenter Integration (TDI).
Tailored suit instead of straitjacket
This granted us the possibility to provide customers with a tailored suit perfectly integrated into private cloud environments instead of a straitjacket off the rack. However, there was still the question of which platform to use.
We compared the restrictions of VMware on Intel with IBM Power with built-in virtualization and found differences in the possible size and number of virtualized Hana systems. Furthermore, many customers told us that they would need significantly more memory than the 3 TB a traditional 4 socket Intel system could provide at this time. These customers needed all the memory in a single instance because their experiences with scale-out haven’t exactly been pleasant.
Based on these facts and because of the experiences with IBM Power, we decided on two machine types: S824L for Hana systems for up to 2 TB, and E880 for anything larger. We also added the E850 with 4 TB when becoming available, which came to be the ideal workhorse for our company.
The Linux-only versions of Power needed for Hana are furthermore significantly more cost-efficient than AIX. After only a short time, our decisions proved to be right, as we and our customers experienced technical and economic success.
Virtualization
IBM’s virtualization is a product of the mainframe era (who still remembers MVS?). Because of that, the additional latency losses typical for third-party virtualizations can be avoided. For Hana, this results in bare metal performance. Memory and CPU performance can be tailored to customer needs in increments of 1 MB and 1/20 cores.
Practical experience demonstrated that Hana generally only needs a mere fraction of what SAP recommends in regards of CPU performance. This is a safeguard for the rare cases where Hana indeed does need more performance.
With Power we can redirect the unused CPU performance into a pool to be used by other Hana systems operating on the same machine. If a system needs more performance than expected, it can use the pool for the excess performance – without admin intervention and without the customer having to pay more.
In theory, we could also dynamically adapt memory – if Hana didn’t still try to access non-existent resources after memory reduction. We therefore recommend restarting Hana after changing memory resources.
Especially LPAR Live Mobility – which is able to transfer even large live Hana instances from one machine to another – has proven to be very useful.
Even though Power hardware is extremely stable, larger machine parks will still have problems once in a while, making it necessary to replace components. Fortunately for us, the internal monitoring made us aware of most of these problems before they could cause any trouble, or they were absorbed by redundancy.
Thanks to Live Mobility, whenever there was a problem, we were able to remove customer systems from the affected machine, replace the motherboard or the network card, and put the systems back in place without our customers noticing.
Even a complete change of architecture – from Shared Cluster to SAN boot, where we were able to clear and reconfigure every machine in turn – was possible without affecting customer operations.
Memory Tetris with Hana
Sales teams and customers were especially excited about an additional benefit. With some proactive planning, it is possible to always have enough resources to have even mid-sized Hana systems ready at short notice.
If no memory big enough is available on a single machine, we are able to clear some space by relocating and swapping smaller systems. This process is very reminiscent of the computer game Tetris, where building blocks falling from the sky have to be fitted together.
In our case the blocks falling from the sky are customers’ demands for new Hana systems in every possible size, preferably already available yesterday. Just like in the computer game, we are able to skillfully relocate resources to make sure that almost 100 percent of the memory of every machine is used.
This in turn makes our CFO happy, even though he always professionally complains that we have to buy new systems every few weeks because of increasing customer demands. However, this strategy can not only be used with new customer requests.
We can also adapt customer systems to their real-life usage. Our Hana Memory Observation can forecast when our customers might need more memory for their Hana systems to prevent termination of large reports because of “Out of Memory” (OOM).
Many customers also appreciate the possibility of using even larger Hana systems temporarily for a PoC. Once the PoC is finished, all the resources are redistributed without additional costs for customers.
This means that customers only have to pay for what they really need – even with large Hana systems. Many cloud providers are doing the exact opposite. Customers have to book and pay for large Hana instances which do not fit on standard blades three years in advance.
The only drawback is that a Power machine with 4 TB cannot provide 4069 GB because the virtualization itself needs some GB. In most cases, however, customer can accept that 1 TB means 1000 GB – making the supposed problem disappear. New IBM Power 9 machines, which provide up to 16 TB with high density DIMMs and up to 8 TB with more cost-efficient DIMMs, grant yet another opportunity to optimize system landscapes even further.
Conclusion
Thanks to Hana on Power, we were able to flexibly and cost-efficiently integrate Hana into a private cloud and therefore significantly increase the satisfaction of customers, sales teams, and our finance department.
Flexible system sizes, high availability and temporary usage of resources are good for customers, and a fast return of investment pleases the finance department. Moreover, we are able to offer 24/7 operation of larger Hana systems for significantly less than every public cloud provider.
Our ever-increasing number of installations gives testimony to this development. At the moment, our Hana on Power system landscapes grows 1 TB per week because of new customer installations – with strong tendencies to double soon. Hana on Power is what you’d expect Hana in the cloud to be. We at Syntax (formerly Freudenberg IT) call that flexHana.
This is the last article of a series! If you would like to read the first one, click here.
Add Comment