Handling failed NFS share in SUSE HA cluster for HANA system replication
This document (000019904) is provided subject to the disclaimer at the end of this document.
SUSE Linux Enterprise Server for SAP Applications 12
In case of NFS failure, HANA might stop working but the Linux cluster might not take action in a reasonable time.
Due to obligatory NFS for the directory /hana/shared/<SID>/, scale-out systems are affected more often than scale-up systems.
The Linux cluster could manage the filesystems as cluster resources. On the other hand, putting HANA filesystems under cluster control would massively increase complexity. Dependecies between HANA instances, nodes, and filesystems would need to be implemented by cluster constraints.
A dummy filesystem resource /hana/shared/<SID>/check/ is added to the cluster. If this filesystem reports monitor failures, the node gets fenced and take-over is initiated. The monitor and action timeouts can be chosen shorter than HANA timeouts to get faster fail-over actions. By letting the Linux cluster fencing a node immediately on filesystem monitor failure, the take-over time can be decreased even further. Regular start and stop of the HANA is not affected by
this dummy filesystem resource.
Since a bind-mounted dummy filesystem is used as cluster resource, NFS shares of both sites could be monitored by the same common clone resource.
Shown below is an example for a scale-out HANA's /hana/shared/<SID>/check/ clone resource. Details like mount point and NFS options are depending on the particular environment. Of course, timeouts are always subject to tuning. The example assumes SID "ADA" and instance number "00", a dummy directory "check" is used for the bind mount, the majority maker node is "vm-majority".
Mandatory parameters are mount option "bind", monitor on-fail action "fence" and OCF_CHECK_LEVEL "20".
--- primitive rsc_fs_check_ADA_HDB00 Filesystem \ params device="/hana/shared/ADA/check/" \ directory="/hana/shared/check/" fstype=nfs4 \ options="bind,defaults,rw,hard,proto=tcp,intr,noatime,vers=4,lock" \ op monitor interval=120 timeout=120 on-fail=fence \ op_params OCF_CHECK_LEVEL=20 \ op start interval=0 timeout=120 \ op stop interval=0 timeout=120 clone cln_fs_check_ADA_HDB00 rsc_fs_check_ADA_HDB00 \ meta clone-node-max=1 interleave=true location fs_check_not_on_majority_maker \ cln_fs_check_ADA_HDB00 -inf: vm-majority ---
Possible side effects:1. The filesystem monitor is not related to HANA system replication. Thus on NFS failure the Linux cluster might decide to fence an HANA primary, even if the system replication is not in sync. Due to this srHook=SFAIL state, the HANA secondary will not get promoted to primary. Even if this useless fence could happen due to HANA monitor failure
anyway, it is more likely to happen with the intentionally shorter NFS monitor timeouts.
2. In some environments NFS is used for /hana/data/<SID>/ and /hana/log/<SID>/ as well as for /hana/shared/<SID>/. In such cases usually all shares are provided by the same NFS server via the same network. If that server or network fails, all shares are affected. Thus the afore mentioned dummy resource will cover failures of all three HANA filesystem.
initiated by the Linux cluster.
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:000019904
- Creation Date: 10-Mar-2021
- Modified Date:10-Mar-2021
- SUSE Linux Enterprise Server for SAP Applications
For questions or concerns with the SUSE Knowledgebase please contact: email@example.com