vmotion between SRM clusters

[rbirri]

Hello

I am planning a vmware cluster design.

I am thinking of a 2 clusters design each controlled by their own VC as SRM requies.

Storage is shared and each hosts can see the same volumes.

Can I do vmotion & storage vmotion between those 2 clusters ?

[mreferre]

Storage is shared and each hosts can see the same volumes.

Ho come?

SRM integrates with Storage replication algorithms that are typically active passive algorithms (i.e. an active LUN gets replicated into a passive LUN on the other site/cluster).

Sure you can have ACTIVE/ACTIVE sites with SRM but you have to do cross stuff such as ACTIVE->PASSIVE and PASSIVE<-ACTIVE........ but the point is that at any point in time a LUN that is seen by a cluster cannot be seen by the other.

?

Massimo.

[weinstein5]

As the other poster pointed out SRM is based on a SAN's rpelicaiton technology so technically you are not looking at the same LUN so VMotion would not work -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

[rbirri]

ok thanks for your answers.

I would like to simplfy my question. Forget the SRM thing. Is it possible to vmotion VM between two clusters managed by their own VC ?

Reading this tread http://communities.vmware.com/thread/104849 seems to say that it is possible.

[mreferre]

If I remember well one of the enhancement of VI3 (over ver 2) was to allow VMotion across Datacenters (which means across Clusters also). Assuming this is true I think it's also fair to say it's not a best practice to allow different clusters to share the same LUNs.

Usually clusters are intended to be isolated islands where VMotion/HA/DRS events take place..... crossing the cluster boundaries for these things it's not advisable.

Why would you want to do that by the way?

Massimo.

[weinstein5]

That is correct 3.5 does support vmotioning between nodes of different clusters as long as the vmotion requirements are met -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

[Rodos]

Rbirri what are your requirements driving this desire? Are you thinking of splitting a cluster across two sites? Knowing your requirements we may be able to shed some further light on what you are wanting to do.

Rodos

Consider the use of the helpful or correct buttons to award points. Blog: http://rodos.haywood.org/

[rbirri]

ok

2 sites, site A site B

5 ESX on each site

I would like to use bidirectional SRM

From SRM documentation it is required that each site has its own VC.

So we have 2 Datacenters with 1 cluster each.

I would like to be able to manualy vmotion hosts between site A and site B if needed

Is it possible ?

[weinstein5]

between physical sites - no the latency would be too high -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

[rbirri]

We have extended LANs between our sites, very low latency (1ms) and gigabit links available so the network will not be an issue if vmotion is possible.

[weinstein5]

As long as they see the same datastores (not replicated) you should be able to vmotion - I have had customer vmotion on the same campus with fiber netwroks strung between them - I would give it a try - if vcenter can not dot it it will just time out -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

[Rodos]

You could make it work but you may have results you don't want.

If you vmotion it to the other cluster you will need to zone the LUNs to both ESX clusters. Only one SAN can be primary for the LUN so if you move the VM to the other site all of the IO will still go back to the previous site, you could then storage vmotion the disks to a LUN which is primary on the same site as the VM. However this is going to make your SRM really weird and difficult to setup if its covering those same VMs. Also to vmotion across clusters do they need to be controlled by the same vCenter Server, thats going to be very hard if you want to use SRM and have a separate vCenter Server manage the ESX hosts at its own site.

Have a quick read of one of my blog posts

http://rodos.haywood.org/2009/01/moving-workloads-split-cluster-or-cloud.html

which also points to an even better one to read on this topic

http://virtualgeek.typepad.com/virtual_geek/2008/06/the-case-for-an.html

Keep the discussion going.

Rodos

Consider the use of the helpful or correct buttons to award points. Blog: http://rodos.haywood.org/

[kimono]

I hope everybody reads that article at Virtual Geek.

At least with cluster+VCENTER being bound to a site, you always know where things are at. Let's face it, sometimes HA does not completely live up to expectations, so if you don't have a VCENTER Cluster in place, you're environment will be invisible until you get VCENTER UP.

I really like Chad's idea of adding more site awareness into VCENTER. To extend upon that, I'd also say yes to giving it Active-Directory style multi-master redundancy. So in day-to-day operation the site's VCENTERS are responsible for looking after its local hosts, but in event of a failover the role can be run from another VCENTER in the forest. This of course would be dependent on networking, but for simplicity let's presume all VCENTERS have connectivity to all ESX hosts in the whole environment. Also it would give the ability for cross-vCenter clusters to be setup. Perhaps these things could be called Meta-Clusters.

Perhaps VMware will facilitate this, and then rely on VSTORAGE and the storage vendors to write more VCENTER plugins. E.G. Giving VCENTER "Metro-Cluster" site-awareness and also the ability to sync this awareness across multiple VCENTERS. How cool would it be to be able to evacuate a building by evacuating that half of the cluster, putting all these hosts into maintenance mode, and then cut-over the storage, and then cut over to the other VCENTER.

This would all be a major change to the way VCENTER works, but that's also my utopia.

/kimono/