Managing NFS and NIS, 2nd Edition - Mike Eisler [108]
Client/server ratios
The number of clients that can be supported from a single server depends on many variables: the type of work done on each client, the type of disks and network interfaces on the server, the number of clients on the network, and the configuration of the clients. Diskless clients used in a software engineering shop do not have the same server requirements as diskless machines used to run the documentation group. Similarly, when dozens of diskless clients are put onto the same physical network, the network itself becomes a bottleneck before the server does. Instead of adopting a somewhat arbitrary client-server ratio, use the following steps to calculate a rough client-server distribution:
Set up a diskless or dataless client on a network with its own server. Put home directories, applications, tools, and other NFS-mounted filesystems on another server, so that the server under test does nothing but handle root and swap filesystem requests from the client. Use only one client for this test so that the server does not become a bottleneck: you want to measure the load imposed by a single client in an unconstrained environment.
Run a normal workload on the client, using scripts or a live user to produce a typical traffic pattern. On the server, measure the average traffic generated (over the course of several hours) and also try to measure the peak request rates produced by the client. Use the nfsstat utility on the server to determine the number of NFS requests per second that the server handles. nfsstat is described in more detail in Chapter 14.
Repeat the first two steps for each "type" of client or user: diskless client, dataless client, development engineer, testing/quality assurance lab, documentation writer, and so on. Blend these figures together based on the percentage of each client type to determine the average NFS load imposed by all of the clients.
Tune and benchmark the server using the methodologies described in Chapter 17. The benchmarks should produce an expected upper bound on the number of NFS operations that the server can provide.
Divide the server's capacity by the weighted average of the client request rates to determine a coarse client-server ratio. Conversely, you can multiply the weighted number of NFS operations performed by each client by the number of clients to set a goal for the server tuning process.
The ratio produced in this manner should be used as a coarse estimate only. The client-server ratio will be overstated because each diskless client server may handle other responsibilities, such as serving other NFS filesystems or driving printers. It may also be understated, because it is rare to find an environment in which the average load produced by N hosts is N times the load produced by a single host. Desktop users simply aren't that synchronized. We'll take closer looks at server and client tuning, NFS benchmarking, and performance optimization in later chapters.
Chapter 9. The Automounter
The automounter is a tool that automatically mounts NFS filesystems when they are referenced and unmounts them when they are no longer needed. It applies NIS management to NFS configuration files so that you can edit a single NIS map and have it affect client mount information throughout the network. Using the automounter, you don't have to keep /etc/vfstab files up-to-date by hand.[1] Mount information, including the server's name, filesystem pathname on the server, local mount point and mount options, is contained in automounter maps, which are usually maintained in NIS maps.
Why would you want to bother with another administrative tool? What's wrong with putting all of the remote filesystem information in each hosts' /etc/vfstab file? There are many motivations for using the automounter:
/etc/vfstab files on every host become much less complex