Before Creating a Highly Available NFS Package

Set up your MC/ServiceGuard cluster according to the instructions in the Managing MC/ServiceGuard manual.

On the primary node and all adoptive nodes for the NFS package, set the NFS_SERVER variable to 1 in the /etc/rc.config.d/nfsconf file:

NFS_SERVER=1

Do not configure the exported directories in the /etc/exports file. When an NFS server boots up, it attempts to export all file systems in its /etc/exports file. If those file systems are not currently present on the NFS server node, the node cannot boot properly. This happens if the server is an adoptive node for a file system, and the file system is available on the server only after failover of the primary node.

If your NFS servers must serve PC clients, set the PCNFS_SERVER variable to 1 in the /etc/rc.config.d/nfsconf file on the primary node and each adoptive node:

PCNFS_SERVER=1

If you run the NFS monitor script, setting the PCNFS_SERVER variable to 1 will cause the monitor script to monitor the pcnfsd daemon. Then, if the pcnfsd daemon fails, your NFS package will fail over to an adoptive node. If you do not want to monitor pcnfsd, do not run the NFS monitor script, or set the PCNFS_SERVER variable to 0 and run pcnfsd manually from the command line.

If your NFS servers will also be NFS clients, set the START_MOUNTD variable to 1 in the /etc/rc.config.d/nfsconf file on the primary node and each adoptive node:

START_MOUNTD=1

If you configure rpc.mountd in the /etc/inetd.conf file, set the START_MOUNTD variable to 0. If the START_MOUNTD variable is set to 0, the NFS monitor script will not monitor the rpc.mountd process. If the START_MOUNTD variable is set to 1, and you run the NFS monitor script, your NFS package will fail over to an adoptive node if rpc.mountd fails.

On the primary node and all adoptive nodes for the NFS package, set the NUM_NFSD variable in the /etc/rc.config.d/nfsconf file to the number of nfsd daemons required to support all the NFS packages that could run on that node at once. It is better to run too many nfsd processes than too few. In general, you should configure a minimum of four nfsd processes and at least two nfsd processes for each exported file system. So, for example, if a node is the primary node for a package containing two exported file systems, and it is an adoptive node for another package containing three exported file systems, you should configure it to run at least 10 nfsd processes:

NUM_NFSD=10

Issue the following command on the primary node and all adoptive nodes to start the NFS server processes:

/sbin/init.d/nfs.server start

Configure the disk hardware for high availability. Disks must be protected using HP's MirrorDisk/UX product or an HP High Availability Disk Array with PV links. Data disks associated with highly available NFS must be external disks. All the nodes that support the Highly Available NFS package must have access to the external disks. For most disks, this means that the disks must be attached to a shared bus that is connected to all nodes that support the package. For information on configuring disks, see the Managing MC/ServiceGuard manual.

Use SAM or LVM commands to set up volume groups, logical volumes, and file systems as needed for the data that will be exported to clients.

The names of the volume groups must be unique within the cluster, and the major and minor numbers associated with the volume groups must be the same on all nodes. In addition, the mounting points and exported file system names must be the same on all nodes.

The preceding requirements exist because NFS uses the major number, minor number, inode number, and exported directory as part of a file handle to uniquely identify each NFS file. If differences exist between the primary and adoptive nodes, the client's file handle would no longer point to the correct file location after movement of the package to a different node.

It is recommended that filesystems used for NFS be created as journalled file systems (FStype vxfs). This ensures the fastest recovery time in the event of a package switch to another node.

Make sure the user IDs and group IDs of those who access the highly available NFS file system are the same on all nodes that can run the package. Make sure the /etc/passwd and /etc/group files are the same on the primary node and all adoptive nodes, or use NIS to manage the passwd and group databases. For information on configuring NIS, see the Installing and Administering NFS Services manual.

Create an entry for the name of the package in the DNS or NIS name resolution files, or in /etc/hosts, so that users will mount the exported file systems from the correct node. This entry maps the package name to the package's relocatable IP address.

Decide whether to place executables locally on each client or on the NFS server. There are a number of trade-offs to be aware of regarding the location of executables with Highly Available NFS.

The advantages of keeping executables local to each client are as follows:

The advantage of putting the executables on the NFS server is as follows:

If executables are placed on the NFS server, you need to ensure that interrupts are handled correctly in a highly available environment. The client must mount the filesystem using the nointr option. This mount option will ensure that the executable continues running correctly on the client after a failover of the server occurs. For example, enter the following command on the NFS client:

mount -o nointr relocatable_ip:/usr/src /usr/src

where relocatable_ip is the IP address of the package, and /usr/src represents the mount points of the server and the client, respectively.

Without the nointr option, if an interrupt (or a SIGKILL, SIGHUP, SIGINT, SIGQUIT, SIGTERM, or SIGALRM signal) is sent to an executable while the NFS server is failing over, NFS will terminate the executable. This is a standard feature of NFS that allows interrupts such as ^C to kill a "hung" client executable if the NFS server is down. Specifying the nointr option resolves this problem. See the mount_nfs(1M) man page for more information.