Although the LifeKeeper SAP hierarchy described in this section implements the SAP NFS hierarchies as child dependencies to the SAP resource, it is possible to detach and maintain the NFS hierarchies separately after the SAP hierarchy is created. You should consider the advantages and disadvantages of maintaining these as separate hierarchies as described below prior to removing the dependency. Note that this is only possible if the NFS shares being detached are hosted on a logical volume (LUN) that is separate from other SAP filesystems.
To maintain these two hierarchies separately, simply create the SAP hierarchy as described in this documentation and then manually break the dependency between the SAP and NFS resources through the LifeKeeper GUI.
Advantage to maintaining SAP and NFS hierarchies separately: If there is a problem with NFS, the NFS hierarchy can fail over separately from SAP. In this situation, as long as SAP handles the temporary loss of NFS mounted directories transparently, an SAP failover will not occur. The NFS mounts need to be in both /etc/mtab and listed in the tunable value SAP_NFS_CHECK_DIRS in /etc/default/LifeKeeper in order to avoid LifeKeeper hanging while the NFS shares are unavailable.
Disadvantage to maintaining SAP and NFS hierarchies separately: NFS shares are not guaranteed to be hosted on the same server where the PAS, ASCS, SCS or ERS instance is running. Note: Consult your SAP Installation Guide for SAP’s recommendations.
The diagram below shows the SAP and NFS hierarchies after the dependency has been deleted.
Post your comment on this topic.