This post is the second of two describing the features of the VMware vSphere Storage APIs for Array Integration (VAAI) version 2 as it works with vSphere 5. If you missed the first part, you can read it here: What Will VAAI v2 Do for You? Part 1 of 2: Block
My earlier posting covered the five features for block storage available in VAAI v2:
Probably the biggest and most-anticipated aspect of VAAI v2 was the the addition of advanced features for NFS datastores. VAAI v2 includes three features for NFS:
I’ll cover each of them in detail below.
NFS File Cloning is more or less the NFS analog of the Block VAAI feature Hardware-Assisted Copy — with one fairly significant difference.
Without VAAI, an ESXi server replicating a VM or performing a Storage vMotion operation acts the same regardless of whether it’s using VMFS or NFS: the ESXi server reads the data from storage, then writes it back to storage — essentially making the server into a “middle man” for the operation, using server resources (CPU, RAM, bandwidth) and affecting other storage traffic.
Similar to VMFS’s Hardware Assisted Copy, NFS File Cloning eliminates this middle man, however, NFS File Cloning takes things one step further.
To block storage, blocks are just blocks. It’s the ESXi server, not the array, that’s making the distinction between different blocks, deciding the placement of the files within the VMFS filesystem.
NFS storage, on the other hand, is “file-aware” if you’ll indulge my creating that phrase. This allows an NFS storage array — not just the server — to take actions at the file level within the file system.
So, when you have a vSphere 5 ESXi server with NFS File Cloning enabaled (and VMware enables the feature by default) connected to an NFS datastore on a supported array that also has the feature enabled, copy operations can happen very quickly.
NFS File Cloning allows the ESXi server to call the array’s built-in file replication facility. On some arrays this might simply create a copy of the file without having to send the data off the array. On others, this will call the array’s native snapshot solution.
On the EMC VNX (the NFS array I’m most familiar with), an NFS File Cloning call will cause the VNX to create a writeable snapshot of the VMDK file that the ESXi server wanted copied. From the server’s point of view, a complete copy of the file was created nearly instantaneously — and the only space it takes up will be any blocks within the file that are changed to be different than the original file they were copied from.
All in all, NFS File Cloning provides huge performance benefits when creating VMs from templates, and can bring with it a great deal of space efficiency.
Prior to vSphere 5, ESXi servers weren’t able to get as much information about what was going on deep inside an NFS filesystem — certainly far less information then they could get from a VMFS filesystem. This makes a lot of sense if you think about it — VMware created VMFS — of course they know what’s going on inside it.
What this means is that, without VAAI v2, the ESXi server only gets the most basic information about a file from storage. If a file is listed as a 100GB file, ESXi treats it like a 100GB file. All space calculations, capacity planning, anything else vSphere or any of its tools might use file information for — all will treat that file as 100GB.
Which would be exactly what you’d want it to do — if it were, in fact, taking up 100GB of space on the NFS datastore…
In reality, our hypothetical 100GB file might:
It is, in fact, entirely possible on modern storage devices, that this “100GB” file is, in reality, only occupying 5GB of physical space on the NFS datastore.
Without VAAI v2, vSphere will treat that 5GB as if it were 100GB, effectively wasting 95GB of potentially-usable space.
With NFS Extended Stats enabled, the ESXi server gets full insight into the inner workings of the NFS filesystem. It will know to tell the application that has up to 100GB to use, and to tell capacity planning tools that the file is 5GB.
NFS datastores, on VAAI-supported NFS arrays can become incredibly space-efficient.
Prior to vSphere 5, there was no way for anyone using an NFS datastore to create the NFS equivalent of an “eager-zeroed think” VMDK file.
Some of you may be asking, “so what?”
Eager-zeroed think VMDKs tend to be the go-to for VMs with high I/O performance requirements, but this just wasn’t an option for NFS.
Additionally, Microsoft Windows Server Failover Clustering (WSFC) requires the physical reservation of the entire space. So, in vSphere 4.1, WSFC was incompatible with NFS datastores.
In vSphere 5, with NFS Reserve Space enabled, when using a supported NFS array, vSphere now has the option to reserve the entire space for the VMDK files.
It’s all about VMware giving customers more options.
I hope you’ve found my write-up of the VAAI v2 features helpful. Hopefully it’s explained the tangible benefits of the various features.
If you’d like the “short version” of this information, about a week ago I posted the presentation that I gave in the EMC booth at VMworld 2011 in Copenhagen. It’s available in two versions: straight PowerPower file (with speaker notes) or a recording of the presentation (complete with the melodious tones of my voice narrating).
Me? I’m trying to second-guess what new features might be coming in VAAI v3…