6.4. Triggering the SAPHanaFilesystem failure action
Block the write access to the monitored directory to test the correct behavior of the SAPHanaFilesystem resource. You can test this on both instances. Only the primary instance triggers a failure and recovery action. On the secondary node the resource does not trigger an action.
Prerequisites
-
You have configured the
SAPHanaFilesystemresource. Skip this test if you have not configured this optional resource.
Procedure
Go to the hidden directory which the
SAPHanaFilesystemresource uses to test read and write filesystem access:[root]# cd /hana/shared/<SID>/.heartbeat_SAPHanaFilesystem/<node>Set the existing
testfile to become immutable, which prevents write access by the resource monitors:[root]# chattr +i testVerify the behavior during the simulated failure.
You can check the
/var/log/messagesfile for the related log message if the resource action is set toignore:[root]# grep ON_FAIL_ACTION /var/log/messages ... node1 SAPHanaFilesystem(rsc_SAPHanaFil_RH1_HDB02)[715184]: INFO: -2- RA monitor() ON_FAIL_ACTION=ignore => ignore FS error, do not create poison pill fileYou can verify the fence behavior if the resource action is set to
fence:[root]# pcs status --full ... Failed Resource Actions: * rsc_SAPHanaFil_RH1_HDB02_stop_0 on node1 'error' (1): ... Pending Fencing Actions: * reboot of node1 pending: client=pacemaker-controld.1694, origin=node2
You must remove this blocker again after the test. If the node is fenced, do this after the node is running again:
[root]# chattr -i test
Next steps
- Clear any failure notifications from the cluster that may be there from previous testing. For more information see Cleaning up the failure history.
- When necessary, depending on the configuration, manually reregister the stopped former primary HANA instance and start it using HANA tools. For more information, refer to Registering the former primary after a takeover.