I. Installation

Just install the package SAPHanaSR-ScaleOut.
Please follow the instructions of the Setup Guides published on our web site at
https://documentation.suse.com/sbp/all/?context=sles-sap.

See manual pages SAPHanaSR-ScaleOut(7) and SAPHanaSR_basic_cluster(7).


II. Supported Scenarios and Prerequisites

For the current version of the package SAPHanaSR-ScaleOut, the support is
limited to the following scenarios and parameters:

1. HANA scale-out cluster with system replication.
   Performance optimized, multi-tenant (A => B).
   Performance optimized, multi-target system replication to 3rd site (A => B -> C).
   Performance optimized, 2x 2 nodes HANA with IP address on second site.
2. It does NOT support cost optimized scenario.
3. It does NOT manage IP addresse for more than 2x 2 nodes.
4. It does NOT manage a 3rd HANA site inside the Linux cluster.
5. The replication mode should be either 'sync' or 'syncmem'.
6. The HANA consists of two sites with same number of nodes each.
7. The two HANA database systems (primary and secondary site) are managed by
   the same single Linux cluster.
8. The maximum number of nodes in that single Linux cluster is given by the
   Linux cluster limit.
9. An odd number of nodes is needed to handle split-brain situations
    automatically.
10. A dedicated cluster node might be used as majority maker.
    This dedicated node does not need to have HANA installed and must not run
    any SAP HANA resources for the same SID. Nevertheless resource agents and
    saphostagent needs to be installed and configured, including users.
11. The Linux cluster must include a valid STONITH method.
12. As the STONITH mechanism SBD is recommended. Either disk-based or diskless.
13. Both sites are either in the same network segment (layer 2) to allow an
    easy takeover ofan IP Address, or you need a technique like overlay IP
    addresses in virtual private clouds.
14. Technical users and groups such as <sid>adm are defined locally in the Linux
    system.
15. Name resolution of the cluster nodes and the virtual IP address should be
    done locally on all cluster nodes.
16. Strict time synchronization between the cluster nodes using reliable time
    services like NTP.
17. There is no other SAP HANA system (like QA) on the replicating node which
    needs to be stopped during take-over.
    See 2. No cost optimized scenario is supported.
18. Both SAP HANA database systems have the same SAP Identifier (SID) and
    Instance Number.
19. The SAP HANA scale-out system must have only one active master name server
    per site.
20. The SAP HANA scale-out system must have only one failover group.
21. The SAP hostagent must be installed and started on your system.
22. Automated start of SAP HANA database systems during system boot must be
    switched off.
    All SAP HANA instances controlled by the cluster must not be activated
    via sapinit autostart.
23. If the shared storage is implemented with another cluster, that one does
    not interfere with the Linux cluster.
    All three clusters (HANA, storage, Linux) have to be aligned.
24. Automated registration of a failed primary after takeover is possible.
    And for optimal automation, AUTOMATED_REGISTER="true" is recommended.
    But as a good starting configuration for projects, it is recommended to
    switch off the automated registration of a failed primary, therefore the
    AUTOMATED_REGISTER="false" is the default.
    In this case, you need to register a failed primary after a takeover
    manually. Use SAP tools like hdbnsutil or HANA Cockpit.
25. The current resource agent and srHook for Scale-Out supports SAP HANA in system
    replication beginning with HANA version 1.0 SPS12 (121) or HANA 2.0 SPS02.
    Older versions do not provide the srHook method srConnectionChanged().
    HANA multi-target system replication needs at least HANA 2.0 SPS03.

See manual pages SAPHanaSR-ScaleOut(7) and SAPHanaSrMultiTarget.py(7).


III. Upgrading to Multi-Target System Replication

SAPHanaSR-ScaleOut prior to version 0.180 and HANA 2.0 prior to SPS03 do
not support Multi-Target System Replication.

Since multi-target system replication uses different CIB attributes than
the old-style srHook, an upgrade procedure is needed for making existing
cluster multi-target aware.
Therefor current package SAPHanaSR-ScaleOut provides two srHooks:
 a. SAPHanaSR.py - old-style, not multi-target aware
 b. SAPHanaSrMultiTarget.py - new multi-target aware

See manual pages SAPHanaSR-manageAttr(8), SAPhanaSR.py(7) and
SAPHanaSrMultiTarget.py(7).
