This section contains information to consider before starting to configure and administer the NFS Server Recovery Kit as well as examples of typical LifeKeeper NFS configurations.
Please refer to for instructions on configuring your LifeKeeper Core resource hierarchies.
The following table describes the NFS files, commands and daemons that are important to the NFS Server Recovery Kit:
Access control list for file systems exported to NFS clients. Each line of the file contains an export point, an optional list of clients that can mount the file system and an optional list of mount parameters.
Note: When you create a LifeKeeper-protected NFS resource, the export information for the file system is removed from the exports file and maintained under LifeKeeper. If you delete the NFS resource, the export information is restored to the exports file.
|/var/lib/nfs||Directory that contains NFS information on current exports, client mounts, locking status and more. In Version 7.4 and later, this directory is moved to the NFS export directory when protecting an NFS v4 psuedo file system. /var/lib/nfs is replaced with a symbolic link to the new location on both the primary and standby systems.|
File that contains the current table of exported file systems for NFS. This file is maintained by the exportfs command; the user does not edit the file directly.
Note: When you bring an NFS resource into service on a backup server, the NFS file system is removed from the etab file on the primary server and inserted into the etab file on the backup server.
|/var/lib/nfs/rpc_pipefs||Used for kernel to userspace communication for NFS. This directory is relocated to /var/lib during installation of LifeKeeper.|
|Command used to maintain the table of exported file systems in /var/lib/nfs/etab.|
|Daemon that authenticates a mount request and returns a filehandle if the client is permitted to mount the file system.|
|Daemon that handles client file system requests.|
|The rpc server that returns quotas for a user of a local file system which is mounted remotely over NFS.|
|Daemon that handles client file lock requests.|
|Daemon that monitors the status of and makes status notifications for NFS clients and servers. This daemon must be running in order for NFS file locking to work properly.|
|portmap/rpcbind||Daemon process that converts RPC program numbers into port numbers and must be running for NFS. A failure of this process will force a switchover to a standby node. On some systems, this function is provided by portmap while on others this function is provided by rpcbind.|
|rpc.idmapd||NFS v4 ID to name mapper daemon process for translating user and group IDs to names and names to user and group IDs. This process must be running for NFS v4 but is not required for NFS v2/v3.|
LifeKeeper protection for a given exported file system depends on the export options being exactly of the form as described in the exports(5) man page. In particular, pay attention to the host restriction format. There are only four legal host restrictions: (single host, netgroup, wildcard host *name* and netmask).
In particular, a wildcard IP address (like 172.13.4.*) is not legal and will lead to potential stale filehandles on switchover or failover. Check very carefully by executing exportfs -v and manually comparing the returned export description against the format described in the man page (unfortunately, exportfs doesn’t check for you and will accept certain illegal export formats).
Under certain conditions with multiple NFS resource hierarchies, rpc.mountd fails to properly advertise the list of exports available. As such, the NFS Recovery Kit on a restore will stop and restart rpc.mount to ensure the proper list of exports is available to all clients. This action of stopping and restarting rpc.mount is controlled via the RESTARTMOUNTD entry in /etc/default/LifeKeeper. By default, this entry is set to true to cause the stop and restart of_ rpc.mount_ on all NFS restores:
To turn off this action set:
NFS Resource Hierarchy
When you create a LifeKeeper protected NFS resource, LifeKeeper creates the following hierarchy:
- NFS file system resource (parent or root)
- HA-NFS resource
- File system resource (the underlying file system)
Create the IP address resource before creating the NFS resource.
You have the option of creating the file system resource(s) before creating the NFS resource. If you do this, you can choose the name assigned to the file system resource(s). If not, the NFS Server Recovery Kit automatically creates the file system resource(s) when creating the NFS resource.
Set up for Automatic Startup of the Service
Set up nfs-server.service for automatic startup via the following commands when protecting NFSv2/NFSv3 exports.
# systemctl start nfs-server.service
# systemctl enable nfs-server.service
Note: Do not set up nfs-server.service for automatic startup when protecting NFSv4 exports.
Set up for Automatic Startup for rpcbind/portmap
Make sure that automatic startup for rpcbind or portmap is enabled.
# systemctl is-enabled rpcbind.socket
If the automatic startup of rpcbind or portmap is not active, execute following command to activate it:
# systemctl start rpcbind.socket
# systemctl enable rpcbind.socket
Handling of NFSv2/v3 and NFSv4
LifeKeeper protects the area as NFSv4 for which option “fsid=0” is specified. The area for which “fsid=0” is not specified is protected as NFSv2/3. Please note that the areas protected as NFSv2/3 and as NFSv4 cannot be mixed.
Post your comment on this topic.