VMware has come up with new vStorage APIs in vSphere 4.1 that improve storage array's abilities to store lots of virtual machines (VM), copy them, and help move them; great for VMware users; potentially terrible for some array vendors.
Maritz' developers seem to have modelled much of the new vStorage properties on pioneering work by 3PAR in terms of avoiding writing zeroes to the InServ hard drives and taken part of a leaf out of Pillar Data's book concerning quality of service.
Viewed through a VMware lens a storage array is a commodity that stores VMs and their apps' data. You buy the ones that deliver as much of this as reliably as they can for the lowest cost. Storage suppliers have to cut their product's cloth to fit VMware's needs and dance to VMware's management tune. The array software is little more, effectively, than a VMware plug-in.
It's inevitable I suppose. Operating systems like Windows and Unix grew up running in single servers with directly-attached storage (DAS). When networked storage was invented, whether block (SAN) or file (NAS) its suppliers could do pretty much what they liked as long as the product physically connected to servers and worked without breaking the operating system.
So the servers still thought they had DAS when in fact they were accessing a SAN, and still spoke familiar file access language when they wrote to a filer. VMware is different. It knows that its VMs can run in multiple servers and that an array's ability to hold and move VMs can be critical to extending the scale of server virtualisation within and between data centres.
It wants array manufacturers to co-operate in the great ESX adventure and help it build up a fabulous lead before Hyper-V gets established. Hence the focus on storage efficiency in the VAAI and SIOC announcements. The vSphere APIs for Array Integration (VAAI) include hardware-assisted locking to protect the VMFS cluster filesystem's meta data, full copy with no need for the vSphere host reading and writing the data, and block zeroing to improve large-scale VM deployments.
VMware has also introduced SIOC (Storage I/O Controls) to ensure particular VMs get a dependable level of storage I/O service in times of I/O bandwidth congestion.
Storage array suppliers have lined up to say they support vSphere 4.1, VAAI, including 3PAR, Compellent (which doesn't actually say it supports SIOC or VAAI), EMC (which supports VAAI but doesn't mention SIOC), HDS and NetApp (which similarly don't mention SIOC).
Each supplier has to prove it has a better VMware storage mousetrap. If they don't then they won't get past the door of VMware shops. NetApp has its ASIS deduplication and other integration tweaks. 3PAR makes use of its generation 3 ASIC to do somethings in hardware, meaning faster. For example, Marketing VP Craig Nunes talking about full copy oprerations, says, that "with zero detection in the 3PAR Gen3 ASIC, these copy operations are further accelerated because (1) zeros (used for initialising capacity for every VM) are not actually written and (2) the ‘zeroed’ capacity that would have been consumed (on other arrays) is unnecessary."
3PAR does support SIOC by the way.
Nunes points out that "These new features are not available today for NFS and NAS." by the way, and this is a general point, not a 3PAR specific one.
In VMware shops array integration with VMware is going to become more and more important. Vendors will have to tick all the VMware storage-related boxes to get a look in and then, effectively, present an overall storage cost per VM type metric. Perhaps we will get a new SPEC performance measure looking at this, a SPEC VM measure, one that will enable users to environments. (Maybe Hyper-V too.)
All storage suppliers are now in a VMware beauty parade and if they don't measure up they are out; that's why the increasing VMware-isation of storage is going to be terrible news for some suppliers. ®