Joep – NetApp Metrocluster (IBM resells Netapp as N Series) along with other approaches (some listed earlier in the thread) can make a datastore be presented at two geographically dispersed sites.

There are good whitepapers on this topic, and there is a specific VMware/NetApp KB article on it.

As we’ve been drafting the EMC doc for this use case we got into a furious internal debate. Some want to point out what’s technicallly possible, some wanting to recommend specific choices. I fall into the “recommend specific choices” category.

While POSSIBLE to create a single stretched VMware cluster, I agree with Arnim’s conclusion.

Until:
1) VM HA has a more transparent way to define primaries/secondaries
2) VM HA has a more “SRM like” ability to control restart conditions/sequencing
3) VM DRS has “sub-cluster affinity zones”
…I personally wouldn’t recommend a single stretched cluster across geo distances, as operational complexity outweighs the advantages (IMO).

BTW – all these current gaps are actively being worked on.

Generally what I’ve found is that people do this (geographically dispersed VMware) for two reasons:

1) Disaster Avoidance
2) Disaster Recovery

vMotion between different VMware clusters is possible, so you can get Disaster Avoidance with two seperate clusters, and don’t run into all of the caveats.

Use of VM HA response for disaster recovery is really a bad idea IMO. Not only does it lack the sequencing control, and the ability to test and report (DR testing is critical as anyone doing DR knows), and of course the fact that it’s designed for recovery from a small number of hosts failing, not half.

In the end, this is usually because someone doesn’t want to spend the $ to license Site Recovery Manager, or because a storage vendor is jockeying for position (this makes for a very cool demo, and customers dig cool demos), or to take the customer revenue rather than partnering with VMware on a Site Recovery Manager solution.

Just because something is POSSIBLE, doesn’t mean it should be done, and often infrastructure-level (alone) solutions aren’t enough.

very good post.

What about an IBM metro cluster ? Imho the storage is transparant in case of a campus solution. If the first datacenter on a campus fails, the storage fails over directly to the second datacenter. In this scenario you would have to make a cluster over two datacenters. Disadvantage is indeed that you cannot exceed 8 nodes in a cluster. Hence it is a campus design DRS would be fine, while using the campus infrastructure.

Unfortunately I can’t view this VMworld session as I don’t have an account.

Good to know that there’s more coming on this front from both EMC, Cisco and VMware.
Can’t wait to take these new technologies for a testdrive!

I’m of the same mind – that isolated clusters (options 4 and 5) are the best (there are a number of VM HA and DRS conditions as you noted). The other variations are valid of course, but the litmus test for me is:

1) “do you really not care which side the VMs are on (ergo it’s a MAN or you have existing dark fiber), or are you willing to setup very specific, and relatively complex DRS exclusion rules”

2) “are you willing to do the homework on the VM HA primaries” (as you noted)

At VMworld in session SS5240, we covered what worked and was supported today, and we did a technology preview of whats coming in this area.

On the VMware side, there’s a set of DRS and VM HA changes coming that will broaden the use cases; on the Cisco side, a series of technolgies that make the networking constraints looser; and on the EMC side, the ability to have an active-active storage model across long distances (maintaining the “writeable on both sides simultaneously” requirement for these shared datastore use cases – both for NFS and VMFS use cases).

The design target is to enable the action to also not require all the data replicating all the time (optionally) – so the impact only occurs at the point of vmotion.

Stay tuned – lots coming on this front soon!

First of all thank you for your comments.

When I was asked to look into stretched clusters there wasn’t any storage virtualization solution in place at that site and couldn’t introduce new technologies either.

I wanted to share my thoughts about the options I came up with, without using a storage virtualization solution. Also those storage virtualization solutions aren’t in the field of my expertise (yet). So that’s one thing I have to look into, in the near future.

Luckily the beauty of blogging is you guys commenting on my article.

-Arnim

I must disagree to your conclusion regarding stretched clusters!

If you add a storage virtualisation technology like NetApp Metrocluster, Data Core or FalconStore into the picture and also assume you have sufficant network and storage bandwidth available, then you can clearly build very powerful and simple stretched clusters. Of course this will only work if latency between those two sites is acceptable low.

I agree that this is a long list of “must have”, but at least I have some big customers running this sort of setup very successful.

You point of “VMware official Support” is a nice one .

Alexander

P.S.: In this post I only express my personal oppinions and NOT an official comment by VMware.

As far as I understand, you’re talking about active-passive solutions like Continous Data Access or MirrorView in order to mirror storage between datacenters. What about some kind of storage virtualization? Our VMware consultant recommended SAN Symphony from DataCore- a technician from HP recommended another product although I can’t remember what it was. FalconStore?

Anyway: This would be an active-active mirror without the problems you mentioned above. However, this might be more expansive and would probably result in increased traffic between datacenters. Additionally, datacenters shouldn’t be too far apart.

Nevertheless, I think this is an interesting option. Did you have any special reasons not to include this scenario?

cu

Mario

I mentioned that the first requirement is stretched vlans and that we assume that this requirement is in place. So this means for all design scenarios.
I’ll see if I can put it in the graphs.

-Arnim