You are here: Configuration Considerations > Configuring NFS Server with LifeKeeper

Configuring NFS Server with LifeKeeper

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:

NFS Component

Description

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. 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.

/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

7_4_and_later

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.

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

7_4_and_later

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.

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).

NFS File Lock Failover

The NFS Server Recovery Kit can fail over file locks taken by NFS clients when protecting NFS v2/v3 exports. With the enhanced locking features available in the NFS subsystem for a v4 export, this setting is not required as lock failover will occur automatically. In order to enable file lock failover for v2/v3 exports, the following entry in /etc/default/LifeKeeper must be modified:

FAILOVERNFSLOCKS=false

This should be changed to:

FAILOVERNFSLOCKS=true

Note: Currently, the recovery kit cannot protect file locks if there is more than one virtual IP address being used for NFS client connections. (This limitation stems from the statd daemon’s inability to send status notifications out from more than one IP address. The statd daemon is responsible for sending notifications to all NFS clients of a given server, and therefore must be able to send out status notifications to clients on all IP addresses.) This limitation would include an Active/Active configuration. Additionally, in the 2.6 kernel on SUSE Linux Enterprise Server 10, the rpc.statd function runs internal to the kernel and not as a user process, thus LifeKeeper is unable to provide lock failover on this Linux distribution at this time.

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

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)

  • For NFS v4 hierarchies with bind mounts, a file system resource will be created  7_4_and_laterwarrow
    for each bind mount. 

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.

© 2012 SIOS Technology Corp., the industry's leading provider of business continuity solutions, data replication for continuous data protection.