It is certainly encouraging to see both NAS protocols, NFS and SMB, featured well in the latest VMware® vSAN 7 Update 1 release. The NFS v3 and v4.1 support was already in vSAN 7.0 when it was earlier announced as part of its Native File Services for vSAN. But some years ago, NFS was not always the primary storage protocol of choice. SAN protocols, Fibre Channel and iSCSI, were almost always designated to serve enterprise applications. At the client side, Windows became prominent, and the SMB/CIFS protocol dominated the landscape of the desktop. This further pushed NFS into the back closet.
NFS or Network File System has its naysayers. The venerable, but often maligned distributed network file protocol is 36 years today. In storage vendors such as NetApp®, VAST Data, Pure Storage FlashBlade, and Dell EMC Isilon, NFS is still positioned as the primary file protocol for manufacturing testers on the shop floor, EDA/eCAD applications, seismic and subsurface applications in Oil & Gas and many more. In another development, just like its presence in the vSAN Native Services,, NFS has also quietly embedded itself into many storage platforms to serve the data platform services within the respective framework itself.
And I have experienced NFS from the client side to the enterprise applications and more, and I take this opportunity to pay tribute.
NFS (Network File System) client server network
The RFCs (Request for Comments)
NFS was developed by Sun Microsystems® in 1984. Version 1.0 never saw the light of day but as of Version 2.0 onwards, there have been numerous RFCs (Request for Comments) which have defined the NFS protocol, and here are the key ones:
- Version 2.0 – RFC 1094
- Version 3.0 – RFC 1813
- Version 4.0 – RFC 3530
- Version 4.1 – RFC 5661
- Version 4.2 – RFC 7862
NFS, especially version 3.0, was wildly successful. The concept of having a seamless and transparent remote mount point existing in the Unix directory tree may seem trivial and insignificant today, but going back 30+ years ago, this concept and its implementation was game changing. Based on its foundations of RPC (remote procedure calls), the deployment of NFS defined much of the client-server architecture.
NFS mount point in a Unix directory tree
Without having to copy remote files to a local directory like FTP or rcp, users can work on the remote files and directories on the NFS mount points. NFS v3 was simple and effective for more than a decade, until security became a bigger concern.
My NFS journey
I started my NFS journey in the early 90s. Working for a Sun Microsystems® distributor at the time, I was given a task to learn and implement PC-NFS®. Sun wanted NFS to be ubiquitous and PC-NFS® had the (un)enviable task to turn a Windows desktop into an NFS client.
Sun Microsystems PC-NFS
In that first job, I also had the task to implement NFS on Sun workstations for several manufacturing customers in Penang, the manufacturing hub for Malaysia. The most notable customer for me was Advanced Micro Devices (AMD). I became fairly good with NFS servers and clients, but remain skeptical of its performance at that time.
Around the same time, I was also adept with Fibre Channel SAN because I implemented the first FC-SAN for Sun in 1993. It was for bank headquartered in Sibu, East Malaysia, and it was an FC-AL (Fibre Channel Arbitrated Loop) 0.25Gbps SAN with an SS1000. I become more of a FC-SAN guy until the year 2000, when I joined NetApp®.
There was a natural gravitation pull towards NAS because NAS was NetApp®’s bread and butter. NetApp® never had any Fibre Channel or iSCSI SAN support until 2003. So between 2000 and 2003, I spent a lot of efforts on NFS. My favourite was implementing and deploying Oracle® 9i on NetApp® NFS, so much so that I became the Oracle® go-to guy for NetApp® in South East Asia. I was convinced and converted that NFS was equal to some of the SAN performance for Oracle® databases but with far greater flexibility and simplicity. But many were still phobic about NFS for some time on.
NFS on Windows
The embrace of NFS and other Unix/Linux commands within the Windows world is refreshing and liberating. This is all part of the new Microsoft® and its “I Love Linux” revolution, and it has turned heads.
Since Windows Server 2012 and Windows 7, the support for NFS Server and Client respectively were already present. Even early on, the not-so-successful Windows SFU (Services for Unix), the NFS server and client components were in the package. Here are the PowerShell commands on how NFS server and NFS Share (shouldn’t it be called NFS exports, but this is Windows) are created.
Windows PowerShell command for NFS Server
Windows PowerShell command for NFS Share
SFU’s successor, WSL (Windows Subsystems for Linux) is gaining ground, partly because the timing to integrate Unix/Linux commands are more relevant to Microsoft Windows administrators and developers now. NFS client service have to be turned on in Windows 10 Professional. Here is an example for the NFS client mount:
Windows 10 NFS Client Mount
NFS to Kubernetes Persistent Storage
The growing importance and the rapid adoption of Kubernetes is also driving NFS to be a Persistent Volume choice for the cluster and the pods. NFS volumes (as they are termed in Kubernetes speak), have their merits compared to block-based brethren, and I would not feign clarity in this part. I am still learning and consuming the persistent storage for Kubernetes, as I have blogged in the past. What I have learned here is that the high level process of getting the NFS volume claimed for the Kubernetes pods or cluster can be summed by the diagram below:
Kubernetes Persistent Volume Claims for NFS exports
I am no longer an administrator or a systems engineer, and never have been a developer, and what I have shared is part of my learning journey. But I have learned to appreciate and respect NFS, in the many ways it has made network storage great.
Closing
There are many NFS use cases I could have written. Gateways to object storage platforms for example, is one I have forsaken for length of this blog. Metadata and credential servers with NFS, High Performance Computing (HPC) are other examples.
In closing, I am glad to have worked on the implementation of NFS in many different settings and applications. It has helped shaped my thoughts, with that, I would like to pay tribute and respect for its longevity in service, its resilience to weather the trials and tribulations, and its critical importance to so many applications and use cases out there.
This is my paean to NFS, the Network File System.
