Network Considerations for Optimizing NFS Performance
- Analyze Network Layout
- Measure Network Throughput Capabilities
- Network Troubleshooting Tools
This chapter is from the book
This chapter is from the book
This chapter is from the book
NFS is an acronym for "Network File System," so it should come as no surprise that NFS performance is heavily affected by the latency and bandwidth of the underlying network. Before embarking on a detailed investigation into a specific area of NFS, it is a good idea to first verify that the underlying network is performing as expected.
This chapter focuses on three main areas: analyzing the physical layout of the network that separates your NFS clients and servers, measuring the throughput capabilities of the network, and network troubleshooting concepts.
This chapter describes a recommended methodology and set of tools available for understanding the physical layout of your network, measuring its throughput, and performing routine network troubleshooting tasks. This chapter does not discuss the myriad of networking topologies and interface cards that are currently available for HP-UX systems. NFS runs on most any networking link supporting Internet Protocol (IP), and it typically performs better on faster links.1
1.1 Analyze Network Layout
An important early step in troubleshooting any NFS performance issue is to learn as much as possible about the physical layout of the underlying network topology. Some of the questions you should be trying to answer at this stage are:
How many network hops (i.e. bridges, hubs, routers, switches, etc.) do network packets traverse between the client and the server systems?
What is the speed of each link separating these systems?
Does your network equipment use auto-negotiation to set speed and duplex settings?
Are your network interfaces configured for half-duplex or full-duplex mode?
Do your switch port settings match the speed and duplex settings of your host interfaces?
What is the maximum transmission unit (MTU) size of the links between these systems?
If the links are using different MTU sizes, how are the packets being translated? For example, if the NFS client resides in an FDDI ring and uses an MTU size of 4352 and the NFS server uses a 100BT interface with an MTU size of 1500, how are the 4352 byte packets from the client being fragmented into 1500 byte packets for the server?
Do packets sent from the client to the server take the same route through the network as the packets sent from the server to the client?
Are your NFS client and server members of a simple Local Area Network (LAN), such as the example shown in Figure 1.1, where the systems are connected to the same switch?
)
Figure 1.1 NFS Clients and Servers on Same Physical LAN
Are the systems geographically separated by a Wide Area Network (WAN) such as the example shown in Figure 1.2, where NFS requests and replies must traverse many network switches, routers, and firewalls?
)
Figure 1.2 NFS Clients and Servers Separated by a WAN
While network administrators should be the best source of knowledge about the layout and capabilities of the underlying network, even they are not always up-to-date on the current state of the network. In many large corporate environments, the physical network is constantly evolving as new equipment replaces old, new backbone technologies replace antiquated technologies, new systems are added to existing networks, new subnets are created, etc. Whenever there is any uncertainty as to the physical layout of the network separating the NFS clients and servers, a network layout analysis should be performed.
Among the best tools available for analyzing network capabilities is the HP OpenView suite of products, such as Network Node Manager.2 Even without using a full-blown network management tool such as OpenView, you can still collect a good deal of information about your network topology using tools that ship with HP-UX.
1.1.1 traceroute(1M)
The traceroute(1M) tool provides a simple means of determining the path through the network taken by packets sent from one system to another. HP's version of traceroute is based on the source code originally developed by Van Jacobson. Since traceroute is considered "contributed" software, it resides in the /usr/contrib/bin directory.
Figure 1.3 shows a sample screen shot of traceroute output displaying the physical path taken between a system located in Roseville, CA and a system located in Cupertino, CA. In this example, and the sample shown in Figure 1.4, traceroute is run with the "-n" option, instructing traceroute to display IP address information for each network hop without performing address-to-hostname translation.3
)
Figure 1.3 traceroute Output from Roseville to
Cupertino
Figure 1.4 reveals the network path taken by traceroute packets sent from the Cupertino system to the Roseville system.
)
Figure 1.4 traceroute Output from Cupertino to
Roseville
In this example there are six network links separating these two systems (the last line in the traceroute output is the actual destination system). The output shows the cumulative latency experienced as the packets transition through the various network links on their way to the final destination. By comparing these two traceroute outputs you can see the number of network hops taken in both directions is the same, but the physical path through the network is different in each direction. For example, going to Cupertino the packets went through "10.4.32.143" while on the way to Roseville the packets went through "10.75.208.10." The latencies experienced in both directions appear comparable.
1.1.2 ping(1M)
Another tool shipping with HP-UX that can simplify the process of collecting network topology information is ping(1M). Michael Muuss originally developed the ping program at the US Army Ballistics Research Lab (BRL) in the early 1980's. It has since become one of the most widely used UNIX networking commands. Most every UNIX administrator has used ping at one time or another to quickly verify connectivity between two network nodes. When used with the "-o" option, ping inserts an IP Record Route4 option into its outgoing packets, allowing ping to track and display the physical network path taken between two nodes.
Figure 1.5 shows the "ping -o" command displaying the network path taken by packets sent between the same systems used in the earlier traceroute example. The "-n 1" option was also used to instruct ping to only send a single packet to the remote system.5
)
Figure 1.5 ping -o between Roseville and
Cupertino Systems
Comparing this output against the traceroute screen shot in Figure 1.3, you can see that the ping packet took the same number of hops to get from Roseville to Cupertino as the traceroute packet. However, the ping traffic took a different route through the HP network than the traceroute traffic. These differences in the network path are most likely the result of dynamic routing tables kept in the routers and bridges used in corporate network backbone.
Unlike traceroute, ping does not report the individual latencies experienced at each location in the topology. While this information may not be as useful as the traceroute output, it provides an easy way of determining the network topology separating two systems.
Once you've determined the physical layout of the network separating your NFS clients and servers, there are several other questions to ask yourself:
Does the layout make sense to you? In other words, is the network laid out as you expected or were you surprised by what traceroute and ping revealed?
Did the physical layout change recently? If so, why?
Are packets taking the most efficient path through the network? If not, can you force them to take the most efficient path?
Can any of the network hops separating the clients and servers be eliminated?
If there is any way to optimize the physical layout of the network (i.e. minimize the number of network hops and use the most efficient route between the systems) it can help NFS performance tremendously.