Review the latest NFSv4 enhancements that deliver enhanced security, simplicity, and performance
In the previous blog-post, we reviewed how VAST Data takes NFS3 to a whole new level of performance. We discuss options that go beyond just using NFS/RDMA, including the use of nconnect and multipathing. In this article, we’ll examine VAST Data’s implementation of NFS4 - recently announced in our VAST Release 4.0 - with more enhancements coming very soon in Release 4.1.
Why NFS4?
Given our success with NFS3 with our customers, it is instructive to understand what the benefits are for moving to NFS4. Now NFS4 is definitely not new - it was proposed in the mid-90’s and the formal specifications are described in RFC3530 from 2003. A more modern spec is described in RFC7530 from 2015 - it just took a long time to get into mainstream computing.
Simple protocol structure
NFS4 is a stateful protocol, unlike NFS3 which is stateless. NFS3 has historically been dogged with many issues - one of which was the number of protocols and ports it needed to function. NFS3 needs separate services and ports for mountd, portmapper and statd, some well known ports, and some ephemeral ports, as shown below. This made operation of NFS3 across firewalls difficult and impractical. In addition, locks were managed by yet another ancillary service - Network Lock Manager (NLM). The major structural change to this was the coalescing of all these into one port (2049) and protocol to handle everything NFS needed. This is now supported by VAST Data for NFS4 operations.
Enhancements with locking
Locking with the new structure in NFS4 is also significantly improved. One of the significant problems with NFS3 NLM was having dangling locks when a client had a failure or was rebooted, leaving orphaned locks that had to be cleared out manually. With NFS4.1, the locking has been enhanced to be lease based.
In addition, the NFS server provides mechanisms for lock expiration and timeouts, significantly simplifying lock management withNFS4. This is also important to eventually support mandatory locks as well. Please note that NFS3 NLM only supports advisory locks. VAST now supports byte-range locking as per the NFS4 specification. More advanced features like mandatory locks are forthcoming in future releases.
COMPOUND RPCs
NFS3 is built on top of the Remote Procedure Protocol (RPC) in a client server environment. A major difference between NFS3 and NFS4 is the introduction of COMPOUND RPCs.
This allows NFS4 to function using operations instead of atomic RPCs, reducing the number of client-server round trips to fulfil a client request. COMPOUND RPCs are supported as part of the NFS4 implementation for VAST Data.
Going beyond POSIX ACLs
NFS3 supports only POSIX ACLs (as described here, for example) while NFS4 ACLs are far richer. A full discussion of NFS4, Windows and POSIX ACLs/mode bits is beyond the scope of this document, but the reader may begin their investigation with the linux-nfs Wiki. VAST has always had an implementation of POSIX ACLs for NFS3, and now we support NFS4 ACLs as well. VAST will continue its tradition of allowing all protocols to interpoperate using a unified and flexible authorization and id mapping model.
Security
This is one area where NFS4 has introduced extensive enhancements to what is available in NFS3. User authentication with NFS3 is host based, i.e. the UserID (UID) and GroupID (GID) are defined on the client machine, so the problem of managing identity across multiple machines in a distributed environment was an open issue. Attempts were made to use Network Information Services (NIS) to try to address centralized identity management, including support for netgroup and automount administered as NIS maps. This fell out of vogue at some point, and today different directory services such as Active Directory and LDAP are used instead.
NFS is based on ONCRPC [RFC1831] and leverages its security architecture, bolstered by the addition of a security flavor based on the Generic Security Services API (GSS-API), called RPCSEC_GSS [RFC2203]. The implementation of secure authentication, and subsequent authorization for specific services, can be achieved in an NFS3 environment. However, the implementation of security authentication is not mandatory in NFS3. Most implementations have done very little beyond Unix authentication.
NFS4 improved on NFS3 in several ways. In the area of security, NFS Version 4 improves over NFS Versions 2 and 3 by:
mandating the use of strong RPC security flavors that depend on cryptography
negotiating the security used via a system that is both secure and in-band
using character strings instead of integers to represent user and group identifiers
supporting access control that is compatible with UNIX and Windows
removing the Mount protocol.
Furthermore, conforming NFS Version 4 implementations must implement security based on Kerberos Version 5 [RFC1510] , each of which are GSS-API conforming security mechanisms.
The details of Kerberos implementation are described in this Wikipedia article and will not be discussed here. Pertinent to us though, is that NFS4 can be implemented using integration with a Key Distribution Center (KDC) for Authentication/Authorization, Integrity Checking and Wire Encryption of NFS4 traffic, The dominant choice of KDC in use by our customers is the Active Directory one (AD KDC), which we are implementing at VAST Data.
VAST Data will be supporting the NFS4.1 implementation for Authentication - krb5 auth - in our upcoming minor release. Subsequent releases will also support krb5i for integrity checking and krb5p (wire encryption) for our customers who have requested it.
Enhancing performance for NFS4
Performance measurements for NFS4/TCP show that we are on par with simple NFS3/TCP mount performance for single clients, for both IOPS and bandwidth. One of the first features we will be introducing to increase performance beyond a single TCP session for NFS4 is the introduction of the nconnect feature present in the Linux 5.3 kernel and beyond in the upstream code. To refresh the reader’s memory, nconnect allows multiple TCP transports to be used for an NFS mount to an NFS server IP.
Previously, for NFS3, VAST Data had introduced backporting the nconnect feature to lower kernels (3.x and 4.x kernels) for Fedora and Debian forks such as RHEL, Centos, SLES and Ubuntu. We expect to have similar support for NFS4.1 as well - as we continue our goal to contribute the code to upstream kernels.
In Conclusion
NFS4 has many other features which VAST Data will continue to develop and implement in the next several months, including RDMA support, wire encryption, mandatory locks, extended attributes, pseudo file system support, delegations etc. We are committed to delivering the most forward thinking implementation available for NFS4, taking advantage of the unique architecture for the VAST platform, and enhancing the experience for the community by contributing any client side enhancements to the upstream kernels.
To learn more about VAST Data, read our white paper on Exascale NAS or simply request a demo with one of our experts.
