/usr/local -ro \ /bin ivy:/export/local/sun4\ /share ivy:/export/local/share\ /src ivy:/export/local/src /usr/man -ro oak:/usr/man \ rose:/usr/man \ willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news \ willow:/var/spool/news
The mount points /usr/man and /usr/spool/news list more than one location, with three locations for the first mount point and two locations for the second mount point. Any of the replicated locations can provide the same service to any user. This procedure is sensible only when you mount a file system that is read-only, as you must have some control over the locations of files that you write or modify. You want to avoid modifying files on one server on one occasion and, minutes later, modifying the “same” file on another server. The benefit is that the best available server is used automatically without any effort by the user.
If the file systems are configured as replicas (see What Is a Replicated File System?), the clients have the advantage of using failover. Not only is the best server automatically determined, but if that server becomes unavailable, the client automatically uses the next-best server.
An example of a good file system to configure as a replica is man pages. In a large network, more than one server can export the current set of man pages. Which server you mount the man pages from does not matter as long as the server is running and exporting its file systems. In the direct map example, multiple mount locations are expressed as a list of mount locations in the map entry.
/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man
In this example, you can mount the man pages from the servers oak, rose, or willow. Which server is best depends on a number of factors, including the following:
Number of servers that support a particular NFS protocol level
Proximity of the server
During the sorting process, a count is taken of the number of servers that support each version of the NFS protocol. Whichever version of the protocol is supported on the most servers becomes the protocol that is used by default. This selection provides the client with the maximum number of servers to depend on.
After the largest subset of servers with the same version of the protocol is found, that server list is sorted by proximity. To determine proximity, IPv4 addresses are inspected to determine which servers are in each subnet. Servers on a local subnet are given preference over servers on a remote subnet. Preference for the closest server reduces latency and network traffic.
Figure 2–5 illustrates server proximity.
Figure 2-5 Server Proximity
If several servers that support the same protocol are on the local subnet, the time to connect to each server is determined and the fastest server is used. The sorting can also be influenced by using weighting. For more information about weighting, see Autofs and Weighting.
For example, if NFS Version 4 servers are more abundant on the local subnet, NFS Version 4 becomes the protocol that is used by default. However, the sorting process is more complex when servers on the local subnet support different protocols. Here are some examples of how the sorting process works:
Servers on the local subnet are given preference over servers on a remote subnet. So, if a NFS Version 3 server is on the local subnet and the closest NFS Version 4 server is on a remote subnet, the NFS Version 3 server is given preference. Likewise, if the local subnet consists of NFS Version 2 servers, they are given preference over remote subnets with NFS Version 3 and NFS Version 4 servers.
If the local subnet consists of a varied number of NFS Version 2, NFS Version 3, and NFS Version 4 servers, more sorting is required. The automounter prefers the highest version on the local subnet. In this instance, NFS Version 4 is the highest version. However, if the local subnet has more NFS Version 3 or NFS Version 2 servers than NFS Version 4 servers, the automounter “bids down” from the highest version on the local subnet by one version. For example, if the local subnet has three servers with NFS Version 4, three servers with NFS Version 3, and ten servers with NFS Version 2, a NFS Version 3 server is selected.
Similarly, if the local subnet consists of a varied number of NFS Version 2 and NFS Version 3 servers, the automounter first looks at the which version represents the highest version on the local subnet. Next, the automounter counts the number of servers that run each version. If the highest version on the local subnet also represents the most servers, the highest version is selected. If a lower version has more servers, the automounter bids down from the highest version on the local subnet by one version. For example, if more NFS Version 2 servers are on the local subnet than NFS Version 3 servers, a NFS Version 2 server is selected.
With failover, the sorting is checked at mount time when a server is selected. Multiple locations are useful in an environment where individual servers might not export their file systems temporarily.
Failover is particularly useful in a large network with many subnets. Autofs chooses the appropriate server and is able to confine NFS network traffic to a segment of the local network. If a server has multiple network interfaces, you can list the host name that is associated with each network interface as if the interface were a separate server. Autofs selects the nearest interface to the client.
For more information, see automount (1M) man page.