It’s hard to believe that it’s been less than three years since VMware's vStorage APIs for Array Integration (VAAI) first allowed us to offload tasks from servers to the storage array. Today, many virtualization experts, including this not so humble reporter, consider VAAI support a required feature for storage systems in virtualized data centers. However, users shouldn’t consider VAAI support as just a checklist item, as some modern arrays not only offload I/O to the array, but also eliminate most of the I/O altogether.
Truth be told, VAAI and Microsoft’s offloaded data transfers (ODX) for that matter, are extensions to the SCSI command set that’s ruled the storage world since the 1990s. Since server virtualization has been a major driver for storage sales, the storage vendors, and ultimately the T10 committee that defines the SCSI standards, took VMware’s extensions and standardized them.
When the boffins at VMware first thought up VAAI, they expected that offloading a task like copying a template to create a new VM would relieve the server and storage network from reading the template and writing the new VM’s virtual disk files while the storage array made the copy. On a conventional array, that’s just what happens -- the array controller copies the data from the template file to the new VMDKs.
In addition to almost eliminating the SAN traffic and server load of cloning, offloading the copy process to the array usually speeds up the process by a significant factor. In addition, better arrays will give higher priority to incoming I/O requests than the copy process to reduce the impact on users of cloning a VM or spawning a VM from a template.
More modern storage arrays handle the SCSI XCOPY (extended copy) command differently. Rather than copying the data, they take advantage of the same metadata-based technology they use to create snapshots to logically clone the VM without actually copying the data. Gene Amdahl, one of the lead architects of IBM’s 360 mainframes and founder of the mainframe clone vendor that shared his name, once famously said, “The best I/O is the one you don't have to do,” and these storage vendors have taken that quote to heart.
[Server SANs such as VMware VSAN are designed for virtualization administrators, but Howard Marks wonders whether these new storage buyers are paranoid enough to be entrusted with storage management in "Server SANs And Healthy Paranoia."]
Using metadata snapshots to support VM cloning makes the cloning process so fast that it frequently takes the vCenter server longer to update its database to include the new VMs than it takes to create them. Even better, the new VMs don’t take up any disk space until new data is written to them. Since Windows Server alone frequently takes up to 20GB of disk space, 50 Windows servers cloned from the same template could take up a terabyte less disk space than on a more conventional system.
Moreover, since those 50 VMs will be using the same on disk copy of Windows, the cloned Windows will usually be promoted into the array’s flash caching layer, speeding up those servers with a lot less flash than would be needed if the VMs were physically copied.
As I wrote three years ago, all snapshots are not created equal, and the variations in snapshot technology become even more apparent when ODX or VAAI is added to the mix. Those shopping for a hybrid or all- flash storage system, or thinking about using a server SAN product like VSAN, should ask about how the system interacts with VAAI to clone VMs.
[Howard Marks will present a half-day workshop, "Deploying SSDs In the Data Center," and a pair of sessions, "Using Flash on the Server Side" and "Software-Defined Storage: Reality or BS?" at Interop Las Vegas, which runs March 31-April 4.]