Configuring a Highly Available NFS Package

Set the PACKAGE_NAME variable.

PACKAGE_NAME pkg01

You can use the default package name if you will run only one Highly Available NFS package on your MC/ServiceGuard cluster. Each package must have a unique name.

Create a NODE_NAME variable for each node that will run the package. The first NODE_NAME should specify the primary node. All the NODE_NAME variables following the primary node should specify the adoptive nodes, in the order in which they will be tried.

NODE_NAME thyme 
NODE_NAME basil
NODE_NAME sage

Set the RUN_SCRIPT and HALT_SCRIPT variables to the full path name of the control script (/etc/cmcluster/nfs/nfs.cntl or whatever you have renamed it). You do not have to specify a timeout for either script.

RUN_SCRIPT /etc/cmcluster/nfs/nfs1.cntl
RUN_SCRIPT_TIMEOUT NO_TIMEOUT
HALT_SCRIPT /etc/cmcluster/nfs/nfs1.cntl
HALT_SCRIPT_TIMEOUT NO_TIMEOUT

If you want to run the NFS monitor script , set the SERVICE_NAME variable to indicate the NFS monitor script:

SERVICE_NAME nfs1.monitor

Each package must have a unique service name. The SERVICE_NAME variable in the package configuration file must match the NFS_SERVICE_NAME variable in the control script.

If you do not wish to run the NFS monitor script, comment out the SERVICE_NAME variable:

# SERVICE_NAME nfs.monitor

You do not have to run the NFS monitor script. If your NFS package configuration file specifies PKG_SWITCHING_ENABLED YES and NET_SWITCHING_ENABLED YES (the defaults), the package will switch to the next adoptive node or to a standby network interface in the event of a node or network failure. The NFS monitor script causes the package to fail over if any of the monitored NFS services fails. NFS services are monitored if they are configured in the /etc/rc.config.d/nfsconf file to be started at system boot. If you set the NFS_SERVER variable to 1, the nfsd, rpc.lockd, and rpc.statd processes are monitored. If you set the PCNFS_SERVER variable to 1, the pcnfsd process is monitored. If you set the START_MOUNTD variable to 1, the rpc.mountd process is monitored.

Set the SUBNET variable to the subnet that will be monitored for the package, as in the following example:

SUBNET 15.13.112.0

Create a separate VG[n] variable for each volume group, as in the following example:

VG[0]=/dev/vg01
VG[1]=/dev/vg02

Create a separate LV[n] and FS[n] variable for each volume group and file system that will be mounted on the server, as in the following example:

LV[0]=/dev/vg01/lvol1;FS[0]=/ha_root
LV[1]=/dev/vg01/lvol2;FS[1]=/users/scaf
LV[2]=/dev/vg02/lvol1;FS[2]=/ha_data

Create a separate XFS[n] variable for each NFS directory to be exported. Specify the directory name and any export options. Following is an example:

XFS[0]="/ha_root"
XFS[1]="/users/scaf"
XFS[2]="-o ro /ha_data"

Do not configure these 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.

Specify the IP address for the package and the address of the subnet to which the IP address belongs, as in the following example:

IP[0]=15.13.114.243
SUBNET[0]=15.13.112.0

The IP address you specify is the relocatable IP address for the package. NFS clients that mount the file systems in the package will use this IP address to identify the server. You should configure a name for this address in the DNS or NIS database, or in the /etc/hosts file.

If you want to run the NFS monitor script , set the NFS_SERVICE_NAME variable to the value of the SERVICE_NAME variable in the package configuration file, as in the following example. Each package must have a unique service name.

NFS_SERVICE_NAME[0]=nfs1.monitor

If you do not want to run the NFS monitor script, comment out the NFS_SERVICE_NAME and NFS_SERVICE_CMD variables:

# NFS_SERVICE_NAME[0]=nfs.monitor
# NFS_SERVICE_CMD[0]=/etc/cmcluster/nfs/nfs.mon

By default, the NFS_SERVICE_NAME and NFS_SERVICE_CMD variables are commented out, and the NFS monitor script is not run.

You do not have to run the NFS monitor script. If your NFS package configuration file specifies PKG_SWITCHING_ENABLED YES and NET_SWITCHING_ENABLED YES (the defaults), the package will switch to the next adoptive node or to a standby network interface in the event of a node or network failure. The NFS monitor script causes the package to fail over if any of the monitored NFS services fails. NFS services are monitored if they are configured in the /etc/rc.config.d/nfsconf file to be started at system boot. If you set the NFS_SERVER variable to 1, the nfsd, rpc.lockd, and rpc.statd processes are monitored. If you set the PCNFS_SERVER variable to 1, the pcnfsd process is monitored. If you set the START_MOUNTD variable to 1, the rpc.mountd process is monitored.

If you will run the NFS monitor script, set the NFS_SERVICE_CMD variable to the full path name of the NFS monitor script, as in the following example:

NFS_SERVICE_CMD[0]=/etc/cmcluster/nfs/nfs.mon

The path name for the executable script does not have to be unique to each package. Every package can use the same script. Multiple instances of the monitor script can run on the same node without any problems, and if a package fails over, only the instance associated with that package is killed.

If you do not want to run the NFS monitor script, comment out the NFS_SERVICE_NAME and NFS_SERVICE_CMD variables:

# NFS_SERVICE_NAME[0]=nfs.monitor
# NFS_SERVICE_CMD[0]=/etc/cmcluster/nfs/nfs.mon

By default, the NFS_SERVICE_NAME and NFS_SERVICE_CMD variables are commented out, and the NFS monitor script is not run.

If two packages have the same adoptive node, and you want to prevent the adoptive node from adopting both packages at once, specify the cmmodpkg command with the package control option (-d) in the customer_defined_run_cmds, as in the following example:

function customer_defined_run_cmds
{
    cmmodpkg -d -n 'hostname' pkg02 &
}

The package control option can prevent an adoptive node from becoming overloaded when multiple packages fail over. If an adoptive node becomes overloaded, it can fail.

In this example, if a host is an adoptive node for both pkg01 and pkg02, the above cmmodpkg -d command, in the control script for pkg01, would prevent the host that is running pkg01 from adopting pkg02. A similar line in the control script for pkg02 could prevent the host that is running pkg02 from adopting pkg01. The ampersand (&) causes the cmmodpkg command to run in the background. It must run in the background to allow the control script to finish bringing up the package. The cmmodpkg command will hang until the package is up, so it must run in the background to allow the control script to complete.

There is a short time, after one package has failed over but before the cmmodpkg command has executed, when the other package can fail over and the host will adopt it. In other words, if two packages fail over at approximately the same time, a host may adopt both packages, even though the package control option is specified.

See “One Adoptive Node for Two Packages” for a sample configuration using the package control option.

Make a copy of the /etc/cmcluster/nfs/nfs_xmnt script:

cd /etc/cmcluster/nfs
cp nfs_xmnt nfs1_xmnt

In the copy of the nfs_xmnt script, create an SNFS[n] and CNFS[n] variable for each file system in the package that will be NFS-mounted by servers. The SNFS[n] variable is the server location of the file system, and the CNFS[n] variable is the client mount point of the file system.

SNFS[0]="nfs1:/hanfs/nfsu011";CNFS[0]="/nfs/nfsu011"

In this example, "nfs1" is the name that maps to the package's relocatable IP address. It must be configured in the name service used by the server (DNS, NIS, or the /etc/hosts file).

If a server for the package will NFS-mount the package's file systems, the client mount point (CNFS) must be different from the server location (SNFS).

Copy the script you have just modified to all the servers that will NFS-mount the file systems in the package.

After the package is active on the primary node, execute the nfs_xmnt script on each server that will NFS-mount the file systems:

/etc/cmcluster/nfs/nfs1_xmnt start

Hewlett-Packard recommends that you execute the nfs_xmnt script from the command line after the package is active on the primary node. However, you can configure the nfs_xmnt script to be executed by the NFS control script in the customer_defined_run_cmds function, as in the following example:

function customer_defined_run_cmds
{
    /etc/cmcluster/nfs/nfs1_xmnt start
    remsh sage /etc/cmcluster/nfs/nfs1_xmnt start
}

The second line in the function invokes remsh to run the nfs_xmnt script on remote host sage.

Running the nfs_xmnt script from the NFS control script guarantees that the package is active before the mount command executes. It prevents cross-mounted servers from becoming deadlocked while each server hangs on the mount command, waiting for the other server's package to become active. However, if the package fails to activate, or if the remsh command fails, the file systems will not be mounted, and no error will be returned. The only way to be sure the file systems are mounted successfully is to run the nfs_xmnt script manually on each host where the file systems should be mounted.

Use the cmapplyconf command to verify the content of your cluster and package configuration and to copy the binary configuration file to all the nodes in the cluster. In the following example, the cluster configuration file is /etc/cmcluster/cluster.conf, and the NFS package configuration file is /etc/cmcluster/nfs/nfs.conf. On your system, use the names of your own cluster configuration and package configuration files.

# cmapplyconf -v -C /etc/cmcluster/cluster.conf \
-P /etc/cmcluster/nfs/nfs.conf

Use your favorite copy utility (for example, ftp or rcp) to copy the package control and monitor scripts to the same path names on all the nodes in the cluster. For example, to copy the files from host thyme to host basil, issue the following command from host thyme:

# rcp /etc/cmcluster/nfs/* basil:/etc/cmcluster/nfs