About Me

My photo
I am Suresh Chinta, working on SAP HANA Cloud & SAP BTP Cloud/ AWS/Azure cloud consultant.I have experience in SAP Basis/Netweaver , S4HANA Cloud implementations / Support. I'm certified Microsoft Azure cloud & AWS professional. I have started this blog to share my knowledge with all those who are interested to learn & enhance their career.

Tuesday, May 21, 2024

HANA High Availability

SAP HANA database runs mission critical applications and it is important that these systems remain available to users always. This requires that these systems can make faster recovery after system component failure (High Availability) or after a disaster (Disaster Recovery). This should happen without any data loss (zero RPO) and in very short recovery time (low RTO).

To provide fault recovery SAP HANA software includes a watchdog function, that automatically restarts configured services (index server, name server, and so on) in case of their failure. In addition to these features, SAP and its partners offer the following high availability mechanism for SAP HANA. These solutions are based on completely redundant servers and/or storage.

  • Host Auto-Failover: One (or more) standby nodes are added to a SAP HANA system and configured to work in standby mode. In case of failure, data and log volumes of a failed worker node is taken over by a standby node. The standby node becomes a worker node and takes over user load. This solution does not need additional storage, only servers.
  • SAP HANA System Replication: SAP HANA replicates all data to a secondary SAP HANA system constantly. Data can be constantly pre-loaded in the memory of the secondary system to minimize the recovery time objective (RTO). This solution needs additional servers and storage. The focus of this reference architecture guide is SAP HANA System Replication.
  • Storage Replication: Data replication is achieved by means of storage mirroring independent from the database software. Disks are mirrored without a control process from the SAP HANA system. SAP HANA hardware partners offer this solution. This solution needs additional servers and storage.

SAP HANA System Replication

SAP HANA System Replication is implemented between two different SAP HANA systems with same number of active nodes. After system replication is setup between the two SAP HANA systems, it replicates all the data from the primary HANA system to the secondary HANA system (initial copy). After this, any logged changes in the primary system are also sent to the secondary system. The following replication modes are available for this procedure:

  • Synchronous on disk (mode=sync): Transaction is committed after log entries are written on primary and secondary systems.
  • Synchronous in memory (mode=syncmem): Transaction is committed after the secondary system receives the logs, but before they are written to disks.
  • Asynchronous (mode=async): Transaction is committed after log entries are sent without any response from the secondary system.

SAP HANA System Replication

SAP HANA System Replication is implemented between two different SAP HANA systems with same number of active nodes. After system replication is setup between the two SAP HANA systems, it replicates all the data from the primary HANA system to the secondary HANA system (initial copy). After this, any logged changes in the primary system are also sent to the secondary system. The following replication modes are available for this procedure:

  • Synchronous on disk (mode=sync): Transaction is committed after log entries are written on primary and secondary systems.
  • Synchronous in memory (mode=syncmem): Transaction is committed after the secondary system receives the logs, but before they are written to disks.
  • Asynchronous (mode=async): Transaction is committed after log entries are sent without any response from the secondary system.
  • Full Sync: Full synchronization is supported by SAP but cannot be configured with SUSE HAE. Full Sync mode stops the surviving node if either node is down, so failover with SUSE HAE is not possible.

If the primary SAP HANA system fails, the system administrator must perform a manual takeover. Takeover can be performed using SAP HANA Studio or the command line. Manual failover requires continuous monitoring and could lead to higher recovery times. To automate the failover process, SUSE Linux Enterprise High Availability Extension (SUSE HAE) can be used or you can any third party vendor. The use of SUSE HAE for the takeover process helps customers achieve service level agreements for SAP HANA downtime by enabling faster recovery without any manual intervention.