The Storage Architect » storage vmotion

Enterprise Computing: VMware Announce vSphere 4

Chris M Evans — Tue, 21 Apr 2009 21:12:16 +0000

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.

Summary

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.

VMware Announce vSphere 4

Chris M Evans — Tue, 21 Apr 2009 21:12:16 +0000

vStorage Thin Provisioning

Improved iSCSI Initiator Efficiency

Dynamic Expansion of VMFS Volumes

Enhanced Storage vMotion

Pluggable Storage Architecture

Summary

Storage VMotion

Chris M Evans — Mon, 08 Oct 2007 21:09:00 +0000

I read the following interesting news release from VMware today. It covers lots of new features for the future release (3.5) of VMware but the one that caught my eye discusses a new feature called VMware Storage VMotion.

This feature will apparently allow the migration of a VMware virtual disk between different storage systems in the same manner that VMotion allows a virtual host to be moved between physical servers. I’m interested in how VMware will have chosen to implement this as there are lots of places in the stack they could choose to do it. For example, will there be any integration with array vendors’ technology (like SRDF/TrueCopy) to manage the replication at the lowest level? Will the replication be managed via a virtual target/initiator in the fabric or will the VMware O/S manage the duplexed data writes at the application layer?

The difficulty of using replication outside of the application layer will be managing data integrity and also speed of replication cutover as the VMware guest is shifted to the new physical location. Add into that the complexity that each member of the VMware “cluster” will probably want read/write access to the virtual disks on which the virtual hosts are defined, then technologies like SRDF aren’t going to work.

What about the CDP products? These seem to be a good logical fit as they replicate and track each block change independently, but I think the same issues of read/write access will apply and therefore these products will be equally unsuitable.

I think it is likely VMware will implement a “standard” cluster with multiple disks being written to by all members of the cluster and using IP to manage synchronisation. This may be good for a local solution but in reality what does VMotion then buy you? As a tool for managing the location of virtual machines across a farm of servers then VMotion is a fantastic tool. I just love the ability to move a host around to manage performance/workload on physical machines and to provide the ability to take physical servers out of a complex in order to do maintenance work.

But with today’s 99.999% available storage subsystems, which can be maintained and expanded online without outage, is there any benefit in being able to move a VMware host to another storage system, unless that storage system is remotely located?

Storage VMotion sounds like a great idea but I’m not sure of the practical use of it – especially bearing in mind there will be a significant cost associated with the new feature.