NFS Specific Configuration Considerations

The following should be considered before using the LifeKeeper NFS Server Recovery Kit:

• The NFS file system to be placed under LifeKeeper protection must be exported by the primary server (the server where the NFS resource is being created). This implies that NFS is running and the underlying file system is mounted.

*Note: If the /home directory is shared via NFS, then /home is the underlying file system.

• When you export a read/write file system, use the sync option. This option requests that all file system writes be committed to disk before the write request completes. If the sync option is not used with an NFS file system under LifeKeeper protection, data may be lost during a failover.

• The underlying file system must be on a shared device and mounted with write permission.

• If the underlying file system is already protected by LifeKeeper, it must be in service on the primary server and have the highest priority. If the underlying file system is not under LifeKeeper protection, then the Recovery Kit will place it under protection.

• The NFS Server Recovery Kit requires an IP resource that must be created and in service on the primary server. The IP resource must also have its highest priority on the primary server.

• Before creation of the NFS resource, clients must be able to mount the NFS file system using the LifeKeeper-protected IP address.

• When you extend an NFS file system resource, the file system must mount at the same mount point on each server.

• When protecting NFSv4 root exports, /var/lib/nfs is moved to the NFSv4 root file system which must have write permissions set when mounted. To provide continued access, a symbolic link is created from /var/lib/nfs to the NFSv4 root. Because of this, Active/Active NFSv4 configurations are not supported nor are configuations with NFSv2/v3 and NFSv4.

• The Oracle Recovery Kit supports NFSv3 for shared database storage. NFSv4 is not supported by the Oracle Recovery Kit at this time due to NFSv4 file locking mechanisms.

• When using a system that adopts Linux kernel 3.12 or later as an NFS client, the file lock at the client side is lost when the communication is disconnected depending on specifications of the kernel. Therefore, takeover of the lock is not guaranteed during switchover or failover.

• In NFS v4, the file lock is lost when the client cannot communicate with the server for more than a certain period of time. This period of time is set as the variable NFS_V4_LEASE_TIME and the default value is 10 (seconds). When the communication between the client and the server is disconnected for a longer time than the period set in NFS_V4_LEASE_TIME during a switchover or failover, the file lock set by the client is forcibly disabled. In order to change this value, set an appropriate value of the environment variable NFS_V4_LEASE_TIME in /etc/default/LifeKeeper.
  If you increase the value of NFS_V4_LEASE_TIME, the above mentioned problem will less likely to occur but it will take time to reconnect to the client after the server switching.

*NFSv2 is not supported on RHEL 7/CentOS 7/OL 7 or later.

*NFS over UDP is not supported on RHEL 8 or later.