In case you haven’t noticed, the next chapter in the story of the unstoppable juggernaut that is VMware is here. It’s called VMware vSphere 4 (dropping the Virtual Infrastructure moniker) but is still essentially the same as the previous VMware with incremental improvements. The full story of what private and public clouds will be seems a long way off, however in the short term there are improvements to storage which are worthy of discussion.
vStorage Thin Provisioning
Although it existed in VI3, Thin Provisioning is now fully integrated in vSphere 4. A VMDK can be allocated as thick or thin. Thin VMDKs are created initially with only 1MB of storage. As data is written to the VMDK, then storage blocks are created on physical storage. Thin VMDKs definitely save on storage; on my test VMware environment I use a template of each Windows platform. My Windows 2008 template is created with a default 40GB of storage; this actually uses around 5GB when cloned to a thin VMDK.
Here’s a (plagiarised) graphic which goes towards explaining how vStorage Thin Provisioning works. It also shows that vStorage TP can be used in conjunction with thin provisioning on the underlying storage array. Question: why do that? Well, firstly, the benefits of vStorage Thin Provisioning are obvious – don’t allocate storage you’re not using, especially when you’re creating tens if not hundreds of virtual machines. Thin provisioning on the storage array also makes sense. It allows you to create a large datastore and grow into it; having a large datastore in the first place reduces the need to move or re-allocate VMDKs once they are created (more on this later).
Improved iSCSI Initiator Efficiency
The ESX iSCSI initiator has been completely re-written. This is expected to result in higher throughput and lower CPU utilisation. This also seems like the first step (of likely many) towards enabling converged and unified storage connectivity for the hypervisor. Of course it’s also a implied admission that performance of iSCSI needed to be improved.
Dynamic Expansion of VMFS Volumes
A new feature called VMFS Volume Grow allows the expansion of a datastore on a VMFS LUN. If the underlying physical LUN is expanded then Volume Grow can be used to expand the datastore to make use of the new space. Enabling this dynamic expansion allows more flexibility in virtual storage design and these kinds of features are going to be essential in enabling always-on technology.
Enhanced Storage vMotion
Storage vMotion has been improved in a number of ways. Datastores can now be moved between LUNs from different protocols (Fibre Channel, iSCSI or NFS). Removal of this restriction gives more options for placing data on the right platform. It also negates the discussion about protocol; eventually the protocol will be irrelevant and so we see again a move towards commoditisation of the storage array. Storage vMotion performance has been improved and can manage thick to thin conversion at the same time as migrating.
Pluggable Storage Architecture
PSA enables vendors to provide their own multi-path drivers to supplement the native multi-path drive (NMP). Presumably for EMC this means a version of PowerPath for ESX. As we move forward with larger VMware deployments, then clever multipathing will be essential. If we are seeing VMware as the new mainframe, then multi-pathing will need to be the new EMIF (if you don’t know what that means, ask me and I might write a post on it). Future architecture will be storage, interconnect and processing power; storage will be plugged into the interconnect with many connections (USP and V-Max both now support up to 128 physical connections, 192 on a USP with restricted disk backend) and efficient multi-path algorithms will be needed to make most use of this.
So, there are things I’ve not mentioned (VMDirect path, paravirtualised SCSI) but this post is getting long now. vSphere is definitely addressing storage needs for the future. I can’t wait to get stuck in and see it in action.