Managing NFS and NIS, 2nd Edition - Mike Eisler [193]
ypwhich, embedded in a shell script, collects NIS client demographics to perform a "census" of server usage:
#! /bin/sh
# ypcensus - poll for ypservers
( for h in `ypcat hosts | awk '{print $2}'`
do
ypwhich $h
done ) | grep -v 'not running' | sort | uniq -c
The for expression dumps the hosts NIS file, and awk extracts the second field — the hostname — from each entry. The loop then queries each host for its NIS server, and then the output from the loop is sorted. The entire loop is executed in a subshell so that its output is treated as a single stream by the next stage of the command pipeline. The grep command filters out errors from ypwhich, produced when an NIS client has not found a server for its domain. At the end of the pipe, uniq -c counts the occurrences of each line, producing the census of NIS servers. Sample output from the script is:
% ypcensus
26 onaga
7 mahimahi
8 thud
You may find that the total number of bindings recorded is less than the number of clients — some clients may not have formed a server binding when the script was run. Executing ypwhich causes the client to bind to a server, so if you "miss" some hosts on the first attempt, execute the script again after all clients have been forced to find servers.
What does the output indicate? With multiple NIS servers, it is possible for the client distribution to load one server more heavily than the others. In the previous example, the large number of clients bound to server onaga could be caused by several things:
The NIS server onaga is significantly faster than the other NIS servers, so it always replies to ypbind requests before other servers.
The servers have about the same CPU speed, so the lopsided binding indicates that onaga has the lightest CPU load. It generates replies faster than the other servers.
onaga may be "closer" to more NIS clients on the network, counting delays in network hardware. Network topology favors NIS servers that are physically close to the client if bridges or repeaters separate clients and potential NIS servers, adding packet transmission delays that can overshadow CPU scheduling delays on loaded servers.
The few clients bound to mahimahi and thud may experience NIS timeouts if these NIS servers are heavily loaded. The relatively small number of clients bound to these servers may indicate that they aren't the best candidates for NIS service because they have a higher CPU load.
Results of the binding poll should be compared to desired goals for balancing NIS server usage. If one NIS server is much faster than the others, you may improve the NIS binding distribution by shifting the fast machine's NIS service to one or two machines that are more similar to the other NIS servers.
To see if you have enough NIS servers, or if your choice of servers provides adequate NIS service, watch for broadcasts from NIS clients to the yserv port. You can observe network broadcasts using a tool like snoop or ethereal, both of which watch every packet on the network and print those that meet a defined criteria. ethereal and snoop are introduced in Section 13.5. To find all ypbind broadcasts, use the following snoop command line:
# snoop broadcast port sunrpc
aqua -> 131.40.52.255 NIS C DOMAIN_NONACK mydomain.com
semaphore -> 131.40.52.255 NIS C DOMAIN_NONACK mydomain.com
ypbind sends its RPC broadcast to the portmapper on the sunrpc port (port 111), and the portmapper calls the ypserv process indirectly. If you see a large number of broadcast calls being made to the portmapper, then your NIS clients are rebinding frequently and you should add more NIS servers or choose servers that have a lighter load.
Other NIS map information