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 LifeKeeper for Linux Technical Documentation for instructions on configuring your LifeKeeper Core resource hierarchies.
NFS
The following table describes the NFS files, commands and daemons that are important to the NFS Server Recovery Kit:
| exports(5) (/etc/exports) | 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. |
| /var/lib/nfs/etab | 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. |
exportfs(8) (/usr/sbin/exportfs) |
Command used to maintain the table of exported file systems in /var/lib/nfs/etab. |
| rpc.mountd(8) (/usr/sbin/rpc.mountd) |
Daemon that authenticates a mount request and returns a filehandle if the client is permitted to mount the file system. |
| rpc.nfsd(8) (/usr/sbin/rpc.nfsd) |
Daemon that handles client file system requests. |
| rpc.quotad(8) (/usr/sbin/rpc.rquotad) |
The rpc server that returns quotas for a user of a local file system which is mounted remotely over NFS. |
| rpc.lockd(8) (/sbin/rpc.lockd) |
Daemon that handles client file lock requests. |
| rpc.statd(8) (/usr/sbin/rpc.statd) |
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. |
| 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. LifeKeeper also uses this for monitoring. |
| 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. |
Export Considerations
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).
Export option “fsid=0” is not supported
If “fsid=0” is specified as an export option, it is processed as a pseudo file system in NFS v4. LifeKeeper does not support this option. Do not specify ”fsid=0” for the export point option to be protected by LifeKeeper. Also, LifeKeeper cannot protect the sub directory export point of the export point specifying fsid=0. Do not export by specifying “fsid=0” for the export which is not protected by LifeKeeper in order to avoid connection problems from a client.
Bind mounts are not supported
Bind mounts are not supported by LifeKeeper and cannot be used for the export point.
RPC.MOUNTD Restart
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:
RESTARTMOUNT=true
To turn off this action set:
RESTARTMOUNT=false
NFS Resource Hierarchy
Create an IP address resource before creating an NFS resource.
When you create a LifeKeeper protected NFS resource, LifeKeeper creates the following hierarchy:
- NFS file system resource (parent or root)
- IP resource
- HA-NFS resource
- File system resource (the underlying file system)
- HA-NFS resource
- IP 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.
Stopping and starting NFS subsystem adversely impacts LifeKeeper protected NFS exports
If the NFS subsystem is stopped while the NFS Server Recovery Kit is protecting NFS exports, then all protected exported directories will be impacted as the NFS stop action performs an un-export of all the directories. The quickCheck script will detect the stopped NFS processes and the un-exported directories, and run a local recovery to restart the processes and re-export the directories. However, you will need to run quickCheck for each protected export to recover everything. For example, if five exports are protected you will need to run quickCheck five times to recover all the exported directories the kit protects. Based on the default quickCheck time of two minutes, it could take up to ten minutes to recover all the exported directories. Do not stop the NFS subsystem while the NFS Server Recovery Kit is actively protecting exported directories on the system. If the NFS subsystem must be stopped, all NFS resources should be switched to the standby node before stopping the NFS subsystem. Use of the exportfs command should also be considered. This command line utility provides the ability to export and un-export a single directory thus bypassing the need to stop the entire NFS subsystem.
Post your comment on this topic.