SIOS LifeKeeper provides out-of-the-box high availability protection for SAP HANA environments (on-premises or in the cloud) and ensures that cluster failover automatically adheres to SAP best practices for fast, reliable continued operations.
In this video, Todd Doane, Solutions Architect at SIOS Technology, demonstrates how SIOS LifeKeeper helps maintain high availability by performing automatic failover quickly and easily.
There are different layers of the application stack: presentation layer, application layer where the ABAP SAP Central Services (ASCS) and the Enqueue Replication Server (ERS) reside, and the database layer.
You have to interpret and account for all of the SAP best practices.
There is a ton going on at any point in time that when there is a failure, automating the failover and meeting your recovery time and recovery point objectives are difficult.
High availability options for the SAP infrastructure:
Red Hat Enterprise Linux (Pacemaker integration)
SUSE High Availability Extension (Pacemaker integration)
SIOS LifeKeeper protection suite
Advantages of SIOS LIfeKeeper:
It is its own custom clustering software.
It is simple and easy to use. It has wizards to configure the chat environment.
It is SAP certified.
It handles data replication at the application level for ASCS and ERS volumes.
It handles database reregistration and can do manual or automatic switchback when a source comes back online.
Advice for companies looking to ensure business continuity:
Identify all the places that you could possibly have a failover, which could be environmental, human error, hardware failure, software failure, power failure, etc.
Plan for each single point of failure.
Train all the people responsible for supporting and keeping that SAP HANA environment up and running and available.
Test the failover scenarios. Ensure that when something fails and takes your data center out, you’re ready for it, i.e., your HA and DR systems will actually work the way you expect them to.
Let’s see SIOS Lifekeeper in action:
Doane shows two servers in AWS: one is running ASCS, the other is running ERS. He injects a kernel failure into the ASCS server. It goes down. The secondary server automatically takes over and starts running the ASCS process. When the server that failed comes back up, ERS is going to automatically move from the currently active server to the other one in order to maintain SAP best practices.