Failover is process of selecting a server from a list of servers that support a replicated file system. Normally, the next server in the sorted list is used unless it fails to respond. By using client-side failover, an NFS client can detect when multiple servers are making the same data available and can switch to an alternative server when the current server is unavailable. This switch is known as remapping. Through normal use, the clients store the path name for each active file on a remote file system. During the remapping, these path names are evaluated to locate the files on the new server.
The file system can become unavailable if one of the following conditions occurs:
If the file system is connected to a server that crashes
If the server is overloaded
If a network fault occurs
The failover under these conditions is normally transparent to the user. It can occur at any time without disrupting the processes that are running on the client.
For failover to occur, the file systems must be mounted read-only. The file systems must be identical for the failover to occur successfully. For information about identical file systems, see What Is a Replicated File System?. A static file system or a file system that is not changed often is the best candidate for failover.
You cannot use CacheFS and client-side failover on the same NFS mount. Extra information is stored for each CacheFS file system. This information cannot be updated during failover, so you can use only one of these two features when mounting a file system.
The number of replicas that must be established for every file system depends on many factors. Ideally, you have a minimum of two servers. Each server supports multiple subnets. This setup is better than having a unique server on each subnet. The process requires the checking of each listed server. Therefore, if more servers are listed, each mount is slower.
For the purposes of client-side failover, a file system can be called a replica when it is the same size and has the same file size or file type as the original file system. Permissions, creation dates, and other file attributes are not considered. If the file size or file types are different, the remapping fails and the process hangs until the old server becomes available. In NFS Version 4, the behavior is different. For more information about client-side failover, see Client-Side Failover in NFS Version 4.
You can maintain a replicated file system by using rsync, cpio, or another file transfer mechanism. Because updating the replicated file systems causes inconsistency, for best results consider these precautions:
Rename the old version of the file before installing a new version of the file.
Run the updates at night when client usage is low.
Keep the updates small.
Minimize the number of copies of the file.
Some software packages require read locks on files. To prevent these products from breaking, read locks on read-only file systems are allowed but are visible to the client side only. The locks persist through a remapping because the server cannot detect the locks. Because the files should not change, you do not need to lock the file on the server side.
In NFS Version 4, if a replica cannot be established because the file sizes are different or the file types are not the same, then the following happens:
The file is marked dead.
A warning is displayed.
The application that uses a file on the replicated mount receives a system call failure.
In NFS Version 4, you no longer receive replication errors for directories of different sizes. In prior versions of NFS, this condition was treated as an error and would impede the remapping process.
Furthermore, in NFS Version 4, if a directory read operation is unsuccessful, the operation is performed by the next listed server. In previous versions of NFS, unsuccessful read operations would cause the remapping to fail and the process to hang until the original server was available.