TECH::The Evolution of NAS

In the animal kingdom, there is a concept known as a “mimic.” These are animals who have evolved and adapted to look more like another animal in its species that evokes fear in predators. An example of this is the Viceroy butterfly.

The Viceroy is a small-ish butterfly that employs mimicry as a defense mechanism. It tries to look like the Monarch butterfly because birds tend to not like the taste of Monarchs and will leave them alone. In areas where the Monarch butterfly is not prevalent, it has been argued that the Viceroy will actually use “model switching” to appear more like a locally dominant species.

The notion of mimicry could also be applied to the evolution of NAS protocols.

Like the Mac vs. PC argument (zzzzz), CIFS vs. NFS has been an unending battle about which is the superior protocol. In fact, the only thing that the NAS protocols could agree on? SAN sucks. 😉

In the early days, it could be argued that the overall edge went to NFS, due to its performance and ability to avoid disruptions due to its stateless nature. But over time, the flaws in NFS became apparent. Performance was great, but it was at the cost of security and data integrity via locking. Of course NFS was faster – it didn’t have to do as much as CIFS on the backend.

As for CIFS, its flaws were always obvious – SMBv1 was pretty slow. Overly chatty. A laissez-faire attitude of “you’ll get your packet when I’m good and ready.” Not at all resilient for network disruptions or storage failovers. CIFS was the awkward teenager at the NAS dance. NFS was the belle of the ball.

It did not help that CIFS had a stubborn parent in Microsoft, while NFS had the goodwill of the open source community and a common standard via the RFC.

NFS, realizing its own fatal flaws, such the abhorrent lack of security, began to develop its own upgrade to the protocol. Enter NFSv4.

NFSv4’s RFC 3530 was written in 2003 by a number of leaders in NFS, including NetApp’s own Mike Eisler, who happens to have a pretty fantastic blog about NFS.

That RFC introduced the following enhancements to the NFS protocol stack (credit to Tech OnTap and my NFS TME predecessor Bikash Roy Choudhury):

  • Access Control Lists (ACLs)
  • “Mandatory” security with Kerberos
  • Client side delegations for caching
  • File streams
  • Global Namespace/Referrals
  • Compound NFS calls

If some of the above sound familiar, they should. Things like ACLs, Kerberos and file streams? Pshaw. CIFS was already on that boat. Namespace? How about DFS? Imitation, it seems, is the greatest form of flattery…

As time passed, and as 3rd party CIFS providers began to appear, as well as improvements to NFS, Microsoft likely began to see the writing on the wall and decided to adapt via mimicry. It began to take on the form of its bitter rival.

SMB upgraded its protocol to v2 in 2007. It came with the following features (taken from TechNet):

  • Reduced complexity, going from over 100 commands and subcommands to just 19
  • General mechanisms for data pipelining and credit-based flow control
  • Request compounding, which allows multiple SMB requests to be sent as a single network request
  • Larger reads and writes make better use of faster networks, even with high latency
  • Caching of folder and file properties, where clients keeps local copy of information on folders and files
  • Durable handles allow an SMB2 connection to transparently reconnect to the server if there is a temporary loss of network connectivity
  • Message signing improved (HMAC SHA-256 replaces MD5 as hashing algorithm) and configuration/interoperability issues simplified
  • Improved scalability for file sharing (number of users, shares and open files per server greatly increased)
  • Protocol works well with Network Address Translation (VC count is gone)
  • Extension mechanism (for instance, create context or variable offsets)
  • Support for symbolic links

In one fell swoop, CIFS became fitter, happier, more productive

It also became more like NFSv4. Compound calls. Client side caching. Symlink support. Larger reads/writes. Improved resiliency via durable handles. CIFS took some of the best parts of NFSv3 and NFSv4 and made them their own. The Microsoft way, of course.

On the flip side, NFSv4 became more like CIFS, for better or worse. Slower performance as a result of extra overhead for locking, state IDs and security. More disruptive than NFSv3 because of the statefulness. Better security, but a pain in the rear to configure/set up the “right way.” (See TR-4073: Secure Unified Authentication if you want to find out what it takes) NFSv4.x will get there. It has to. That’s evolution.

Now, we’re seeing even more convergence with SMBv3 and NFSv4.1. Features like pNFS and CIFS auto-location. Continuously available shares in SMBv3 for more reliable hosting of databases and virtual machines. You know, like NFSv3 was always good for.

Some other SMBv3 features (via Microsoft):

  • SMB Transparent Failover
  • SMB Scale Out
  • SMB Multichannel
  • SMB Direct
  • SMB Encryption
  • VSS for SMB file shares
  • SMB Directory Leasing
  • SMB PowerShell

Times are a-changin’ for NAS protocols. It’s starting to feel less like mimicry and more like a convergent evolution. Did you know that koalas have developed fingerprints indistinguishable from humans? Or that the Australian honey possum has developed a long tongue to drink nectar from flowers, similar to butterflies like the Viceroy?

Evolution is good for everything, no matter how we get there.

One thought on “TECH::The Evolution of NAS

  1. Pingback: TECH::vSphere 6.0 – NFS thoughts | Why Is The Internet Broken?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s