SAP HANA Recovery Kit Hardware and Software Requirements

*Beginning in v9.5.0 SIOS has released the new SAP HANA Application Recovery Kit. SIOS will continue to support the SAP HANA gen/app based Recovery Kit with the 9.4.x releases until March 31, 2022. If you are using LifeKeeper for Linux v9.5 or later you must use the new (built-in) SAP HANA Application Recovery Kit.

Hardware Requirements

• Servers: Servers should be configured in accordance with the requirements described in the SAP HANA Master Guide, SAP notes mentioned in this guide, LifeKeeper for Linux Documentation, and the LifeKeeper for Linux Release Notes.

• Storage: For SAP HANA databases utilizing SAP HANA System Replication, no shared storage is necessary. Special storage requirements are given in the SAP HANA Master Guide and the aforementioned SAP notes.

Software Requirements

• LifeKeeper Software: It is imperative that you install the same version of LifeKeeper software and apply the same versions of the LifeKeeper software patches to each server in your cluster.

• SAP HANA Software: SAP HANA Platform Edition 2.0 SP04 (or later) is required for use of the SAP HANA Recovery Kit. The same version of the SAP HANA software must be installed and configured on each server before configuring LifeKeeper and the LifeKeeper SAP HANA Recovery Kit. Since SAP HANA licenses are tied to hardware, each server will require its own license from SAP. SAP HANA System Replication must be enabled and fully configured and the database must be running on all cluster nodes before creating the SAP HANA resource hierarchy in LifeKeeper.

• LifeKeeper SAP HANA Recovery Kit: The SAP HANA Recovery Kit is bundled as an optional recovery kit with the core installation in LifeKeeper for Linux v9.5.0 and later.

*As of LifeKeeper for Linux v9.7.0, the SAP HANA Recovery Kit supports Multitarget HSR configurations with up to four cluster nodes (one primary database server replicating to up to three secondary servers).

• Witness Server: SIOS recommends the use of quorum/witness functionality to prevent split brain scenarios due to communication failures between cluster nodes. In a cluster with an even number of nodes, this may require the addition of a cluster node to act as a dedicated witness server.