Managing NFS and NIS, 2nd Edition - Mike Eisler [73]
The NFS servers in the replica list must support a common NFS version. When specifying a replicated filesystem that has some servers that support NFS Version 3, and some that support just NFS Version 2, the mount command will fail with the error "replicas must have the same version." Usually, though, the NFS servers that support Version 3 will also support Version 2. Thus, if you are happy with using NFS Version 2 for your replicated filesystem, then you can force the mount to succeed by specifying the vers=2 suboption. For example:
# mount -o vers=2 serverA,serverB,serverC:/export /mnt
Note that it is not a requirement that all the NFS servers in the replicated filesystem support the same transport protocol (TCP or UDP).
Managing replicas
In Solaris, the onus for creating, distributing, and maintaining replica filesystems is on the system administrator; there are no tools to manage replication. The techniques used in the example given in the Section 6.5.1, can be used, although the example script given in that subsection for generating a replica may cause stale filehandle problems when using it to update a replica; we will address this in Section 18.8. You will want to automate the replica distribution procedure. In the example, you would alter the aforementioned example to:
Prevent stale filehandles.
Use the rsh command instead of the rlogin command.
Other methods of distribution to consider are ones that use tools like the rdistandfilesynccommands.
Replicas and the automounter
Replication is best combined with use of the automounter. The integration of the two is described in Section 9.5.1.
Naming schemes
Simple, efficient naming schemes make the difference between a filesystem that is well organized and a pleasure to use, and a filesystem that you are constantly fighting against. In this section, we'll look at ways of using mount points and symbolic links to create simple, consistent naming schemes on all NFS clients. NFS provides the mechanism for making distributed filesystems transparent to the user, but it has no inherent guidelines for creating easy to use and easier to manage filesystem hierarchies. There are few global rules, and each network will adopt conventions based on the number of servers, the kinds of files handled by those servers, and any peculiar naming requirements of locally developed or third-party software.
Note that this section assumes that you will not be using the automounter (see Chapter 9). It is strongly advised that you do use the automounter, because every issue mentioned and solved here is much more easily solved with the automounter.
As a system administrator, you should first decide how the various NFS fileservers fit together on a client before assigning filesystem names and filling them with software or users. Here are some ideas and suggestions for choosing NFS naming schemes:
Avoid having NFS mounts on directories directly under the root (/ ) directory of each NFS client. The reason is that if an NFS server crashes, then any attempts to access the mounted directory will hang the application even if it is not interested in the NFS mount point. This can happen if an application invokes the library equivalent of the pwd command: getcwd( ). [1]
Pick a common directory on each client under which you will mount each user's home directory. For example, if you pick /users, then each user's home directory is accessed via the /users/username naming scheme.[2]
This makes it easier to deal with servers that have several filesystems of home directories. The disadvantage to this approach is that it requires a larger /etc/vfstab file, with one entry for each user's home directory. If you use the NFS automounter, this naming scheme is more easily managed than the hostname-oriented one (and the automounter has a /home/username scheme preconfigured). Directories that follow any regular naming scheme are easily managed by the automounter, as discussed in Chapter 9.
Do not allow the physical location