Managing NFS and NIS, 2nd Edition - Mike Eisler [171]
Whenever you make a change, you run the risk of affecting more than just one machine. If you add a new NFS client, for example, you should consider all possible impacts on the computing environment: network bandwidth consumed by traffic to and from this node, or the incremental workload imposed on any servers used by the client. Similarly, when upgrading server resources you must identify those areas that are the tightest constraints: CPU speed, disk speed, or aggregate disk space. Adding another server to a network may not be as economical or beneficial as upgrading to faster disks, adding CPUs to an expandable server or offloading other tasks, such as web service to another host.
This portion of the book focuses on network analysis, debugging, and performance tuning. Its goal is to present the tools, procedures, and evaluation criteria used for analyzing network, NFS, or NIS problems. In addition to tuning and administration, these techniques can be used to evaluate proposals for expanding an existing network with additional clients or servers. Symptoms and causes of common problems will be examined in detail, but the overall focus is on developing techniques to be used on complex problems peculiar to your specific combination of hardware and software.
In this chapter, we present tools for examining the configuration and performance of individual network components, starting at the lowest level of basic point-to-point connectivity and working up to the RPC layer where the NFS- and NIS-specific issues come into play. The chapter includes examples relevant to problem diagnosis to define the methods for collecting and interpreting data about the network and its components. A healthy network is essential to the proper behavior of NFS and NIS. Developing network diagnostic skills is necessary for resolving problems that may only be apparent at the application level. NFS may behave poorly because of a saturated network or due to an overloaded server; a thorough examination of the problem requires checking each component involved. If you fail to understand the low-level operation of a facility, you are more likely to misinterpret performance or usage statistics provided for that facility. We cover the lower layers of the network protocols in detail so that you can see how they affect the performance and behavior of the application layer protocols like NFS and NIS.
As explained in Section 2.3, NIS and DNS can be used concurrently to resolve hostnames on the same system, although throughout the remainder of this book, we assume that NIS is the only name service running. In some cases, we refer to local files that are used without NIS. However, examples and discussions refer to the most common NIS maps, as shown in Table 13-1.
Table 13-1. Common NIS maps and their nicknames
Map Name
Nickname
Local File
passwd.byname
passwd
/etc/passwd
group.byname
group
/etc/group
hosts.byname
hosts
/etc/inet/hosts
ipnodes.byname
ipnodes
/etc/inet/ipnodes
rpc.bynumber
rpc
/etc/rpc
services.byname
services
/etc/inet/services
netmasks.byaddr
netmasks
/etc/inet/netmasks
The /etc/inet/ipnodes file and ipnodes NIS map form a database that associates the names of nodes with their IP addresses. The IP addresses can be either IPv4 or IPv6 addresses. The ipnodes database was introduced in Solaris 8 to support IPv6-aware[1] and IPv6-enabled[2] applications that need to obtain IPv6 addresses. When these applications need IPv4 addresses, they first consult the ipnodes database. If the address is not found, they then consult the traditional hosts database. IPv6-unaware[3] applications simply consult the hosts database, as they are unaware of IPv6 extensions. Although not a requirement, IPv4 addresses defined in the hosts database should be copied to the ipnodes database