Autostart function for all HANA database systems
With our new autostart function for all HANA database systems, sudden restarts of the operating systems are no longer a problem. Based on automation, we have developed a way in which the high availability function of the ESX hypervisor and that of SAP’s Adaptive design do not hinder each other but complement each other. Our team paid particular attention to using only standard automation functionalities without slipping into the drawbacks of a cluster solution.
Implementation at the customer’s site:
Initial situation:
In the past, the customer relied on the static autostart functionality of VMWare’s ESXi hypervisor for the entire SAP system landscape. However, this approach limited the customer’s agility, scalability and maintainability. To counteract this limitation, the customer’s entire SAP landscape was converted to SAP’s Adaptive Design. By applying this concept, the above-mentioned disadvantages are now a thing of the past. Easier scalability of the systems in the case of new requirements, massively improved agility in the case of system failures, and simpler changeover in the case of new operating system releases name are only a small part of the resulting possibilities. The implementation of this design is accompanied by a complete separation between the operating system and the application.
Problem definition:
To control this design conditioned separation between operating system and application continuously, it is compellingly necessary to dissolve static connections of each layer. At the same time, this results in the operating system restarting automatically in the event of a failure, but the application remains completely unaffected due to a lack of information. The result are as follows.
Continuous operation:
Increased agility, better scalability and reduced downtime during maintenance.
After system failure:
The operating system is running, the application is not -> Business Impact!
Solution:
To counteract the above disadvantage of the application no longer starting automatically, we created a solution that resolves this stalemate. In a simplified representation: after the automatic restart, the operating system asks the SAP LaMa whether (and if so) which application was running on it before the failure. As a central point, SAP LaMa holds all the information needed to start the specific application. In addition to various security gates, a DR scenario has also been mapped in case the SAP LaMa is also unavailable. Thus, restart times of less than 5 minutes can be achieved.
Conclusion:
At the beginning, the customer was highly available, but not agile. Then it was agile, but not highly available. Now, thanks to our new solution, it is agile and highly available. It has also enabled us to significantly reduce downtime and the resulting financial losses.
