Developed by Sun, NFS version 2 was published as an IETF standard. Sun guarded NFS development for nearly two decades before handing protocol guardianship over the ITEF for version 4. This openness fueled adoption by the major UNIX vendors, even though most had their own competing protocols. Deployment on Big Iron fueled …
Sorry, the NFS server you are connecting to does not support MS LockFile extensions. Please upgrade your NFS server to one which supports this feature.
Client for win7
If they are so proud of their implementation I wish they would ship it with Win 7 home/pro.
Re: Client for win7
What, the unnecessary SMB weirdness isn't enough for you? You want to support another, even flakier, fileshare protocol too?
I think you've come in the wrong door, fellow -- the masochists' club is just around the corner. You'll know it when you see it, it's the one with broken glass set into the doorhandle.
Re: Client for win7
Good tip. Thanks Trevor, will have a look at the University of Michigan NFS v 4.1 client.
Everything old is new again
First mainframes and centralization in general (oops, sorry, I mean "the cloud"), then dumb terminals, now NFS. Could someone have a new idea please?
Aaw, it warms my heart to see
how much Microsoft cares for open standards and interoperability. Maybe it is because they don't want us to talk about SMB.
Was anyone else...
...hoping to see an actual benchmark of cheap x86 servers running Microsoft's NFS in an MSCS cluster? I admit I got a bit excited when I read the headline.
Re: Was anyone else...
I was going to, honest. Unfortunately my test lab has suffered setbacks. Namely, I've lost my SAN, two RAID controllers a pair of UPSes, a dozen drives and two server Mobos (with the CPUs and RAM!) Car vs. power pole combined with seriously dated equipment ends in sad.
The test lab made it through a recent set of private cloud testing I did, then the car --> power pole incident happened. I rebuilt with what I had lying around, but it all completely collapsed when I tried to do storage testing.
Since my lab is done on my personal dime, rebuilding will take time.
I don't have empirical data to share. I never got through the complete round of testing. I can however share both my initial impressions. Overall? NFS in Server 2012 is fast. Faster in almost every instance than iSCSI for VM hosting, and seriously neck-and-neck with SMB 3.
Both SMB 3 and NFS wreck SMB 2. Preliminary results had me getting 92% stable utilisation of a decent Intel NIC, with peaks at 96%. Basically right at the upper limit of theoretical. Preliminary results on 10GbE had me actually pulling the disk-native speeds.
Failover was seamless. None of the software I have was good enough to even measure the event. Flip the switch on the primary and not even a ping dropped to the VM you were accessing. Unreal.
In all honesty, Microsoft’s NFS implementation is on par with the best configured Linux systems I have seen in the field. It’s easier to set up, handles clustered failover better and might actually be more stable than the default CentOS 6.2 implementation. I can’t confirm that last bit with absolute certainty, as it was during the stress testing to really ramp up throughput versus stability versus failover testing that the wheels came off the test lab.
Hope that helps…
Re: Was anyone else...
Sorry to hear about your accident; I have been managing similar setup some years ago and I know these things do not come cheap.
Re: Was anyone else...
Just hoping I win some replacement gear during some of those "attend out online training webinar and enter $impossibly_large_pool_of_other_nerds for a chance to win a new $midrange_item!"
In the meantime, I have 4 pano logic zero clients to test. They seem to like me and sent me demo gear of their latest widgetry. Should keep me occupied for a month or so. After that? Maybe I'll write more about Android. I have rather a lot of Android gear.
Change it up, I say. Write about new thing as they cross your desk. :)
"Far from a locked-down, proprietary implementation, Microsoft's Windows Server clusters provide seamless failover for mixed-mode clients."
Really? Has Microsoft provided source code? Have they at least documented their entire implementation so that the community can benefit from their approach? I am genuinely curious given that last time I heard, Windows Server was a pretty locked-down, proprietary product.
The last three companies I have worked for have a copy of the source.
@AC 17:53GMT - Re: Hmm..
All three covered by an iron clad "forget you ever saw it" NDA ?
But you are a few articles ahead of me here... ;)
Source code, etc
I don't particularly like MS, and of course prefer Linux's openness instead, but that is down to their behaviour of propitiatory protocols and dirty tricks to promote vendor lock-in (not the only company to do so, I hasten to add).
So if they are indeed properly supporting an open protocol that is a very good thing and as such the source code is not essential if it works properly with a good selection of other's products.
Slightly different if high trust is needed (e.g. encryption).
I'm not really sure what the revelation is here other than Microsoft has developed something that complies with an open specification and tested that compliance thoroughly with 15+ clients. Now, I do assume that's 15+ different vendors' implementations and not just a bank of Windows 7 laptops.
Interesting but dull.
But then that's what good NFS servers should be,
Aren't "interesting" and "dull" direct antonyms? ;)
Trevor, if you haven't already, read the "The Design and Implementation of the 4.4 BSD Operating System" (McKusick/Bostic/Karels/Quaterman), published in 1996 (the 4.3 edition was published in 1991). One of the subjects it covers is NFS, and surprise surprise you will see that they make a point of the servers being stateless - allowing clients to fail over relatively painlessly. The tricky bit is keeping the servers synced up on the hoof, which is left as an exercise for the reader. ;)
It's a good read in any case and even if the NFS stuff doesn't tickle you the other stuff is pretty useful. It helped me "get" UNIX. I also found that MS has spent the last (now) 26 years implementing features 4.3BSD already had (and to be fair a few things it didn't have).
IMHO the world would be a marginally happier and more productive place if folks used what UNIX had to offer instead of trying to make VMs & CLR & Java do resource management (poorly as it turns out).
Added to my kobo. Cheers!
Nice article, shame about some of the comments
Am I the only one who mistakenly read that sub-headline
as NSFW instead of NSF?
"Whatever the corporate history of Microsoft, the incomprehensible logic driving the licensing department, the facepalms of marketing or the variegated legal machinations, Microsoft employs an great many good people, and they do a lot of good works. Roy has the opportunity to work with the best Microsoft has to offer, and it shows each time he talks about them."
While Microsoft is in many ways one of the worst companies in the IT world, once in a while (presumably unbeknownst to management), they do actually ship a decent product.
Of course, eventually Licensing will notice and sod it all up, but until then...
But what about translation?
I want to really know how filename translation compatible their NFS implementation is.
Is it compatible with EMC multi-protocol?
What about NetApp multi-protocol?
What about with Microsoft CIFS and DFS?
Even better, how about translating a filename from EMC or NetApp multi-protocol share served as a Microsoft DFS share and a Microsoft NFS share?
Anyone want to bet it doesn't play nice? I will.