Chapter 1. Introduction

The FailSafe NFS plug-in lets you add NFS to the highly available services that are failed over in a cluster. A plug-in is the set of software required to make an application highly available, including a resource type and action scripts. There are plug-ins provided with the base FailSafe release, optional plug-ins available for purchase from SGI, and customized plug-ins you can write using the instructions in the IRIS FailSafe Version 2 Programmer's Guide. The optional FailSafe NFS plug-in enables FailSafe to provide failover protection for filesystems and directories that are exported using NFS. The plug-in supports NFS version 2 and version 3.

The rpc.lockd and rpc.statd daemons manage NFS file locks.

FailSafe operates on the concept of resources. A resource can be a filesystem, an IP address, or any entity that can be moved from one node to another when a problem (or scheduled downtime) occurs.

In a FailSafe 2.1.x cluster, one or more nodes can export NFS resources. A resource group can contain multiple NFS resources and a single node in the cluster may have multiple resource groups that contain NFS resources. If a node that exports NFS resources fails, another node provides backup service.

The FailSafe NFS plug-in provides the NFS and statd_unlimited resource types, which includes the following set of action scripts for each resource type:

These scripts are found in the following directories:

/var/cluster/ha/resource_types/NFS
/var/cluster/ha/resource_types/statd_unlimited

You can use the NFS resource type to export the following:

Planning NFS Filesystems


Caution: Do not cross-mount filesystems using NFS in a FailSafe cluster (that is, do not mount a locally mounted filesystem on a different node using NFS). This configuration is not reliable and will not work with FailSafe. Instead, you should use the CXFS (clustered XFS) plug-in, which provides this functionality. For more information, see IRIX FailSafe NFS Administrator's Guide.

Use of NFS over TCP is not recommended. If the client loses the TCP connection and does not reconnect, it can cause the client to hang on a failover. You should use UDP rather than TCP. If TCP is the default for your NFS clients, you must reconfigure them to use UDP. One method to accomplish this is to create the /etc/config/nfsd.options file with the content -p UDP, which will prevent the server from accepting TCP mount requests.

In a FailSafe cluster, one or more nodes can export NFS filesystems. If a node that exports NFS filesystems fails, the NFS filesystem is failed over to the next node that is listed in the application failover domain for the resource group.

When the NFS server on one node fails, a surviving node must take over the NFS file-locking information from the failed node. FailSafe does this by storing the NFS locking state for each exported filesystem. The NFS lock information for each exported NFS directory is stored in a directory that is in the shared disk. The filesystem that contains the directory should also be in the same resource group. This directory must be named statmon.

The locks held by clients on a filesystem are stored in the statmon directory for each exported filesystem. The statmon directory is maintained in the shared disk, along with the exported filesystem or directory.

NFS lock failover is required if the application running on the client using the NFS filesystem obtains file locks. In this case, you must also provide a resource of type statd_unlimited. (The resource type statd_unlimited replaces the old statd resource type. It provides NFS lock failover functionality but is not restricted to two resource groups per cluster, as was statd.) The resources that are type statd_unlimited can be present in any number of resource groups in the FailSafe cluster.

Do not place NFS filesystems on shared disks in the /etc/exports file. FailSafe exports these filesystems only after ensuring that another node does not have these filesystems exported.


Note: The use of the wsync option is applicable only to NFS version 2, because NFS version 3 implements a safe, asynchronous write.

You can reconfigure NFS exports and XFS local mounts on the node to perform writes synchronously to disk (when received) by adding the parameter wsync to the mode parameter in all filesystem blocks and to the export-info parameter in all NFS blocks. In this case, a reply to an NFS write will not be returned until the NFS write data is written to the server's disk. However, performance can be greatly affected by adding the wsync option in the filesystem blocks and in the NFS blocks. You must balance the risk of NFS data corruption during a node failure against the performance gain from using asynchronous NFS writes. Some applications perform their own error checking of data or perform writes in which data corruption does not occur.


Required Software

The required software for NFS failover is as follows:

  • NFS software. See the ONC3/NFS Administrator's Guide for more information about NFS.

  • Base IRIS FailSafe software. See the IRIS FailSafe Version 2 Administrator's Guide for a complete list of required base software.

  • IRIX FailSafe NFS software:

    • failsafe2_nfs.books.book_AG contains this book.

    • failsafe2_nfs.man.man contains the man pages.

    • failsafe2_nfs.man.relnotes contains the release notes.

    • failsafe2_nfs.sw.base contains the base software.

Overview of the Configuration Process

To configure a FailSafe cluster for failover of NFS, follow these steps:

  1. Install, configure, and test the base IRIX FailSafe software as described in the IRIS FailSafe Version 2 Administrator's Guide.

  2. Install the NFS software. See “Required Software”.

  3. Configure the NFS file-locking information. See Chapter 2, “Configuring NFS”.

  4. If needed, install the NFS and statd_unlimited resource types. See “Installing the NFS and statd_unlimited Resource Types” in Chapter 3.

  5. Add the individual instances of NFS and (if needed) statd_unlimited resources to the cluster database. See “Defining Resources” in Chapter 3.

  6. Create the resource group that will be failed over. See “Creating a Resource Group” in Chapter 3.

  7. Test the NFS failover. See the section “Testing the start Script ” in Chapter 4.