Moving workloads, split cluster or the cloud?

A few little elements have popped up this week to raise the whole question again of VMotion across data centers or stretched ESX clusters.

Splitting a ESX cluster across sites has been a something that most of us have looked at over the last year and most of us still want to do it at some stage. However is it really a good idea? Chad Sakac did a great write up on this “The Case For and Against Stretched ESX Clusters” that I often refer people to as it is well worth the read. 

Then last week over on the Cisco Data Center podcast Sidney Morgan, IT Manager at Cisco was interviewed (MP3) about their internal use and plans for virtualisation. They mention at one point they may have been one of VMware’s largest customers. Sidney is asked what is the next wave for their datacenters. The goal is to “not only load balance between rooms but between datacenters”. Sidney seems to be talking about VMotioning across locations, talking about using it for much better BC failover, using layer 2 adjacencies to allow DRS across sites for failure in a true active/active nature, inter rather than intra data center. In marketing speak the end goal according to Sidney is “End to end virtualisation, any application, on device running on any network hosted out of the most convenient data center”. The first bit sounds like split clusters to me where as the second sounds like vCloud.

Moving the running machine networking wise is sort of easy, it’s moving the storage that’s the issue. As Alan pointed out on “The Virtual Datacenter Blog” in referring to some Cisco comments, the amount of bandwidth consumed by video is going to be dwarfed by that of moving VMs. 

However it has been my belief that in the early generations of vCloud we are probably not going to see VMotion and dynamic movement of workloads across clouds (sure you can spin up a new VM, but that’s different to moving a running one). This is certainly not what I thought the vCloud API would provide, although there may be a mechanism to move a powered off or suspended VM. The dynamic moving of workloads around the cloud is something for down the track, first generations will be more about deployment placement choice than say load balancing. Until its released or we see it under NDA we just don’t know yet.

So it was all good, then I got a curve ball. Today I reviewed the VMware partner training materials on vCloud that Eric Sloof posted about. You could not count the times within these sessions that it mentioned VMotion and Storage VMotion and this got me worried. This training is early days and the full details for vCloud is not released yet, but … putting the idea of VMotion which is really split ESX clusters and Storage VMotion which could certainly be used as a way to migrate all of a workload to another site is putting dangerous thoughts into sales peoples heads. I can imagine what sales people will say to customers after reviewing this material, “Oh yea, VMotion into the cloud, no problem, you can Storage VMotion the VMDK files over too”. No offence to all my sales friends.

Lets see what pans out but I think VMware are going to have to be really clear as to what the goal is, setting the right expectation. If we have all sorts of confusing messages mixing up split clusters with federated clouds and vendors like Cisco pushing its all sweet, you just need layer 2 adjacencies (ignore the storage, thats an exercise for the reader, a bit like the replication bit within SRM) we may have some untangling to do. 

On the other hand it may all be sweet and all that fibre capacity bandwidth the carriers have is going to get sold real quick. Boss, can you place an order for 10G between data centers and the cloud provider please, bandwidth is cheap isn't it.

Exciting times.

Rodos