Network File System (NFS)
The NFS was developed in 1984 by Sun Microsystems. It is a file-based storage network solution, using the client/server architecture of communication, and operates at the application layer (Layer 7) of the OSI reference model. The NFS allows a user on the client, which is a computer, to access over the network storage resources on a server, which is called an NFS server. The NFS server has multiple file systems available for the NFS clients to mount and use as if the storage were local. The NFS server can be a computer, or it can be a storage system, such as a NetApp storage system, with the needed software to act as an NFS server.
Currently, there are three versions of the NFS:
- NFSv2: Defined in RFC 1094 (March 1989). Originally used the User Datagram Protocol (UDP) for stateless communication. Because it is 32-bit only, the first 2GB of a file can be read.
- NFSv3: Defined in RFC 1813 (June 1995). Developed to overcome some of the NFSv2 limitations. It is 64-bit, which allows it to handle files bigger than 2GB. Supports additional file attributes in the replies and asynchronous writes to the NFS server. Added support for TCP-based communication.
- NFSv4: First defined in RFC 3010 (December 2000) and revised in RFC 3530 (April 2003). There are additional minor versions, such as NFSv4.1 and NFSv4.2, that add support for clustered server deployments, parallel access to files distributed among different servers, server-side clone and copy, space reservation, application data block (ADP), and session trunking (also known as NFS multipathing). NFSv4 adds support for end-to-end security, such as Kerberos 5. A big advantage is that the NFS server runs the service on a single port (TCP/UDP 2049). The latter makes controlling the NFS communication through firewalls and applying quality of service (QoS) much easier.
As mentioned before, the NFS is supported on Linux/Unix platforms, including the following:
- Solaris
- AIX
- HP-UX
- Apple’s macOS
- Different Linux OSs
- FreeBSD
- Microsoft Windows (it’s more common to use SMB/CIFS on the Windows OS)
- IBM OS/2
- OpenVMS
The NFS is based on a client/server architecture. This approach is based on the concept that one computer, which will be the server, has resources that are needed by another computer. This other computer is the client. The server will share, or make available, the needed resources to the client. The client and the server communicate with each other through established protocols, which in this case are the protocols defined by the NFS. The client will consume the shared resources as if they were local. The communication takes place in a network environment. If there are multiple servers and multiple clients, or multiple clients and one server, it is a distributed client/server network.
Using the client/server approach is beneficial because of the cost reduction, as there is no need for any additional hardware and there are minimum space requirements. The clients do not need a lot of local disk space because they use storage on the server. Other benefits are the centralized management and maintenance, such as backups, performed on the server.
As the NFS operates at Layer 7, the communication between the client and the server is basically communication between two applications. The applications in a client/server architecture communicate using Remote Procedure Call (RPC), which makes it possible for a client process to call a server process and ask it to execute the call as a local process. The rpcbind, or portmap, is an RPC service that allows clients and servers to communicate with one another by using interprocess communication methods. In other words, the rpcbind (portmap) is a service that takes care of the addressing in the communication between services. It is responsible for mapping the service to a port on which it listens. The RPC services are assigned ports, as long as they are registered with the portmap with a program number, version, and transport protocol. The portmap service is usually running on TCP/UDP port 111, also known as a privileged port in Unix. The NFS servers use the UDP/TCP port 2049 by default.
Based on this information, the NFS flow between the NFS server and client can be described with the following sequence:
The NFS server must run the needed services and daemons, such as mountd, nlm_main, NFSD, status monitor, quota daemon, and portmap (also known as rpcbind). These services are required, as each has its own role in that communication. The portmap is responsible for the mapping of the ports to the services and announcing this; the mountd allows the client to mount the storage and so on.
The storage that will be shared and available must be exported under the /etc/exports configuration file.
The client uses the mount command to connect to and use the shared resources (or using the NFS terminology, to mount the shared storage).
- The client will call the portmap service on the NFS server to find on which port to communicate.
- The client will connect to the NFSD.
- The NFSD will proxy the call to the mountd service.
The client will be able to access the shared storage.
Figure 10-3 illustrates the NFS client/server architecture and the communication over the network infrastructure.
Figure 10-3 NFS Client/Server Architecture