SRM Configuration

[aniruddh22]

I have two ESX clusters (Cluster 1 at primary and Cluster 2 and secondary) with VM's replicating through SRM between Cluster 1 and Cluster 2. The underlying LUN's are replicated through snapmirror.

I have a task at hand to migrate the VM's from Cluster 1 to Cluster 3 at primary and Cluster 2 to Cluster 4 at secondary. Which of the following will be a convenient solution -

1. Provisioning new LUN's to Cluster 3 and Cluster 4 and setting up a snapmirror relationship between them. Migrating the VM's on old cluster to the new LUN's through storage vmotion.

2. Mapping the old LUN mapped to Cluster 1 to the Cluster 3 and then unmapping it from Cluster 1 once the SRM relationship is setup again between the VM's on new clusters.

The second solution seems a little dodgy and it was suggested by someone so as to reduce time involved in storage vmotion. Sorry if the text is confusing.

[colsen]

Hello,

We tend to use storage vMotion when we're moving things around - but yes, it can be time consuming and such.  That said, usually about the time we're looking at migrating to new storage, we typically have either decided to do an ESX upgrade and/or restructure our datastores (i.e. go to a different storage design based on SLA, occupancy, etc).  The storage vMotion makes for a clean way of getting onto the "new" platform.

If that's not in the cards for you all, is it possible to join Cluster1 to Cluster3 together (as well as Cluster2 to Cluster4) and then just perform non-disruptive volume moves (as well as move your SVM root/LIF) over to the new storage?  We've done a ton of moves of VMware datastore volumes and it's gone very smoothly.

I'm not familiar enough with ESX and SAN storage (we're using NFS) to speak to the option 2 - it seems to imply some cut-over or something which makes me think there's potential downtime?  I'm probably not reading your description accurately and perhaps there's a way of doing this I'm not familiar with...

Hope that helps,

Chris