Current information about SAPHanaSR – the resource agents for SAP HANA system replication

What is this solution about?

The new solution created by SUSE is to automate the takeover in SAP HANA system replication setups.

The basic idea is that only synchronizing the data to the second SAP HANA instance is not enough, as this only solves the problem of having the data shipped to a second instance. To increase the availability you need a cluster solution, which controls the takeover of the second instance as well as providing the service address for the client access to the database.

What are the current limitations?

For the first version of the SAPHanaSR resource agent software package we limit the support to the following scenarios and parameters:

1. Two-node clusters
2. The cluster must include a valid STONITH method like SBD or IPMI
3. Scale-Up (single-box to single-box) system replication
4. Both nodes are in the same network segment (layer 2)
5. Technical users and groups such as sidadm are defined locally in the Linux system
6. Name resolution of the cluster nodes and the virtual IP address can be done locally on all cluster nodes
7. Time synchronization between the cluster nodes using NTP
8. There is no other SAP HANA system (like QAS or TST) on the replicating node which needs to be stopped during takeover.
9. Only one system replication for the SAP HANA database
10. Both SAP HANA instances have the same SAP Identifier (SID) and Instance-Number
11. If the cluster nodes are installed in different data centers or data center areas, the environment must match the requirements of the SLE HAE cluster product. This in special means the network latencies between the nodes and the recommended maximum distance. Please review our product documentation for SLE HAE about those recommendations.
12. As a good starting configuration for PoCs and projects we recommend to switch-off the automated registration of a failed primary. The setup AUTOMATED_REGISTER=”false” is also the default since version 0.139.
13. The SAPHOSTAGENT must be installed on both nodes.

Note: Please note that without a valid STONITH method the complete cluster is unsupported and will not work properly.

If you need to implement a different scenario we strongly recommend to define a PoC with SUSE. This PoC will focus in testing the existing solution in your scenario. The limitation of most of the above items is mostly due to testing limits.

The resource agent supports SAP HANA in System replication beginning with SAP HANA version 1.0 SPS 7 patch level 70.

Beside SAP HANA you need SAPHOSTAGENT to be installed on your system. Automated start of SAP HANA instances during system boot must be switched off.

Which general steps are needed to get this solution into operation?

1. Install two systems using SUSE Linux Enterprise Server for SAP Applications. For update levels, package solution and so on see also SAP notes like 1310037, 1944799 and 1855805.
2. Install SAP HANA on both nodes using the same SID and instance number. Please refer to the SAP installation guides for details.
3. Check, if SAPHOSTAGENT is installed on both nodes. If not please install that software on both nodes.
4. Create a user in the database and user store keys at Linux level, so the resource agent could check the SAP HANA internal synchronization status. This step is described in SAP HANA administration manuals as well as in our setup guide (SAP HANA System Replication Scale-Up – Performance Optimized Scenario | SUSE).
5. Perform a database backup on the node that will hosts the primary side and enable the system replication at this instance.
6. Register the other SAP HANA instance to be the secondary.
7. Install the SUSE pattern for high availability cluster and install the new resource agents.
8. Setup the cluster base configuration on the first node and make it available on the second node.
9. First tuning of the cluster bootstrap parameters.
10. Do not forget to setup a STONITH method.
11. Simply call our HAWK configuration wizard, enter the SID, the instance number and the IP address. An other method is to use crmsh, the command line interface (CLI) of our cluster solution.
12. Enjoy the cluster controlling your SAP HANA instance in scale-up scenario.

Are there already customers running this solution?

Yes, but however at this point in time I could not name the customers as a reference, but we already have customer and partner installations.