16.12 NFS and Aliases

NFS is an example of a network service that is started at boot time. As such, it is not under the control of the inetd daemon. Typical use of NFS in a cluster is as a highly available NFS server. Recall that NFS is a software mechanism for allowing file systems (or directories) to be accessible to client nodes in the network through remote mounting. Should we worry about which member of the cluster actually functions as the NFS server?

Under normal circumstances, where the storage to be served is on a bus shared by all cluster members, it makes little difference which member serves the data. But imagine the overhead involved with a member of the cluster having been chosen to do the NFS serving that does not have direct access to the storage to be served. This would require excess traffic over the CI in order to access the CFS server for the data to be served out over NFS. Yikes! What a waste of system resources.

16.12.1 The exports.aliases File

In this case, a solution would be to define a cluster alias that includes the member(s) with direct access to the storage, and then have the clients use that cluster alias when doing their remote mounts. The problem is that the mountd will not work unless it is requested using the default cluster alias – or if the alias is reflected in the /etc/exports.aliases file (new for V5.1A). This simple file consists of a list of cluster aliases that may be used by clients in their remote mount requests. This file does not associate aliases with particular file systems. See Chapter 20, or the contents of the /etc/exports.aliases file, or the exports.aliases(4) reference page for more information.