I spent last week at SNW talking about key NAS technologies for 2009/2010 and a host of offerings from NetApp on accelerating engineering and business lifecycles. Topping off the week was a vibrant and interactive talk on parallel NFS (pNFS/NFS v4.1). Given the level of interest in pNFS at SNW I want to cover that first, then in part two I'll cover and post the presentations I did on NFSv4 and accelerating engineering applications.
As I began my talk on pNFS I needed to brief the audience on the role of an evangelist. I was quick to inform them that as an evangelist I spend more time looking at adoption than evangelizing, basically the 80/20 rule – 80% adoption research and 20% evangelizing, but people only seem me evangelize. Thus, everyone thinks I spend more time evangelizing than I do looking at adoption metrics -- tragic.
Adoption metrics with pNFS are limited to issues that have driven the need for a pNFS specification and some bake-a-thon information that is available through public disclosure. During my talk I was asked to cover the history of NFS, dating back to the early 1980’s and commencing with the issues that drive the need for pNFS. I took a show of hands as to who was already familiar with NFS and about 80% of the audience raised their hand, so I covered the history, albeit briefly, for the 20%. The net-net is NFS means Network File System and is designed to expose server storage to a network of NFS clients.
Assuming most of you have the history of NFS behind you, we must understand a business and technical driver for pNFS. A key technical driver for parallel NFS is based on NFS in-band model that requires a server managing the reading and writing data to also manage the client/server interaction, including metadata, locking, security, etc. This in-band model is sufficient, provided the NFS server isn’t overpowered by the NFS client systems.
NFS clients are over powering the NFS servers. The business conditions of technology consumption have driven down the costs to acquire NFS client computing power (CPU, Memory, etc), thus increasing the load on the NFS server. The NFS client’s are further grouped into grids to accommodate the grueling computations required by the applications. Each NFS client increases the storage input and output operations (IOPs) on the NFS server, exposing the weakness of the protocol, in-band metadata, operations and data storage model.
The requirement was to apply a grid technique used by NFS clients to support NFS server’s writing data in parallel. Thus, to scale a single in-band NFS Server into a grid of NFS servers, requires improvements to the NFSv4 specification. Specifically, NFSv4 is extended with the NFSv4.1 specification describing the use of a metadata server and n+1 data servers. The goal of parallel NFS is to support parallel access to data servers in a standard way so that clients and servers can be productized and supported across multiple brands, such as NetApp. Moreover, pNFS can be expanded to support multiple layout types, including:
- Blocks, the pNFS client uses the SCSI protocol, which could be iSCSI, FC, FCoE.
- Objects, the pNFS client uses the OSD protocol. OSD moves the storage management to the storage subsystem, i.e. storage head/controller.
- Files, the pNFS client uses the NFSv4.1 protocol. This layout type supports all NFSv4 and v4.1 operations, including compounds, file and directory delegations and access control lists, to name a few.
After explaining the layouts and client interactions, the audience started asking detailed questions about the blocks based layout. To that end I owe a special note of gratitude to Dr. David Black, EMC, Distinguished Engineer, who helped move along the presentation on pNFS with respect to blocks layout discussions.
What we learned at this event was that pNFS is on the minds of many people, not just vendors and HPC users, but enterprise users with enterprise level needs – operational expenses, backup, recovery and high-availability. So it’s in our best interest as an industry to deliver on parallel storage. NetApp provides complementary parallelization of storage today for CIFS and NFSv3 standard using ONTAP GX and Storage Acceleration (FlexCache*) appliances. Our goal is to incorporate pNFS services in a time frame that’s inline with client code base support, i.e. RedHat, etc. For a bit more detail on pNFS, please read the article that Mike Eisler and I just co-authored in our Tech OnTap monthly editorial.
The NFSv4.1 specification is rounding the bend on finalization and we expect it to be approved for publication near the end of CY09 CY08, keep an eye on Mike Eisler’s blog for more on the IETF specification process. Mike mentioned to me yesterday that this is the largest specification in the history of IETF;
totaling just under 600 pages – a healthy read for anyone. If only we could find a way to solve the metadata server scalability problem...
Next up a brief on my talk about NFSv4 and accelerating engineering applications…
*SA/FlexCache is NFSv3 only
Comments