Replicating a VMware datastore on NFS

[CLOUDMINER]

I need to be able to replicate a VMware datastore, from one site to another site.  The two sites are managed by different vCenter Servers.

The goal is to create a datastore that has all the .iso files I will use in the environment, accessible to vCenters at both sites.  When an iso file gets added to the main iso datastore at the main site, it automatically gets replicated to the datastore at the other site.

The datastores are using NFS.  Can I use snapmirror and set the main site as the source and the branch site as the destination?  If snapmirror changes the contents of the branch site's NFS datastore WHILE it is connected to and being managed by the branch site's vCenter server, will that cause a problem?

(For example, If this were an FC LUN instead of NFS I would have to resignature the LUN for it to be used by the other vCenter server.)

How can this be done with NFS and what are the caviats / gotchas?  Should I replicate at the volume level or qtree level?

Thanks!

[GARDINEC_EBRD]

We had a very similar situation recently.  We were using volume snapmirror to replicate the templates datastore, then mount the mirror via NFS (effectively read-only).  This worked well, and I setup a backup job in VSC so the VM admins to take a backup and effectively trigger a mirror update on demand without the storage guys needing to get involved.  This was often used when a template was changed/created in the primary site, then they wanted to use it to deploy in the remote sites.  However, they would obviously need to wait for the backup/mirror update to complete.

This worked OK, and the number of template changes is minimal so we never encountered any issues with the templates changing during use, but I would imagine that is a possibility.

We've now changed this:- our license bundles include FlexCache, so I've changed this to use FlexCache volumes.  This has the advantage that changes are recognised immediately.  ESX has mounted the cache vols read-only to avoid changes being made by the remote vcenter boxes, but you could theoretically allow this (as long as you accept the write latency is going to be poor).

If we lose the WAN, we lose the caches (it's set not to retain the cache on loss of connectivity), but we accept that.  Worst case (or in a DR situation) we can still go back to mounting the snapmirror destinations.

Anyway, hope that helps in some way!

Craig

[CLOUDMINER]

OK thanks for the input. In this case we wouldn't have flexcache.

I wanted to clarify your statement that "they would need to wait for the backup/mirror update to complete".  I want to make sure I understand exactly which side needs to "wait" and whether that waiting pertains to reads, writes or both.  For example,

We have a main Site A with datastore A and a remote site B with datastore B

-Initiate a backup of datastore A in site A with our templates on the primary site using VSC, which will cause snapmirror replication to take place from site A to site B.

-Site A must refrain from writes to datastore A until snapmirror replication completes, but Site A can continue reads

-Site B can continue reads from datastore B during the replication.  (It can never write to datastore B)

-After the replication, Site A can resume writes.

Is this correct?

[GARDINEC_EBRD]

Hi,

"-Initiate a backup of datastore A in site A with our templates on the primary site using VSC, which will cause snapmirror replication to take place from site A to site B."

>> Correct.

"-Site A must refrain from writes to datastore A until snapmirror replication completes, but Site A can continue reads"

>> No, Site A can continue reads and writes, but it would make sense to have the templates in a static state (ie not being changed) when the SnapMirror update is initiated (ie the VSC job is run).  The filer will create a snapshot of datastore A which will be used for the mirror update to site B.  You can still write to Datastore A, but only data that was present when the snapshot was created will be replicated.

"-Site B can continue reads from datastore B during the replication.  (It can never write to datastore B)"

>> Technically, Site B can continue reads from Datastore B, but it is possible data will change as the mirror update completes.  It would be good practice not to deploy from any templates at site B until the mirror update is completed.  The mirror destination volume cannot be written to from Site B unless the mirror is broken.

"-After the replication, Site A can resume writes."

>> As above.

I'm assuming you have a dedicated datastore for Templates?  If not, I would recommend this.

Hope that helps,

Craig

[CLOUDMINER]

OK thanks again.  One more question.  Suppose I have one main site (A) and TWO remote sites (B and C).  Can I snapmirror directly from site A to site B AND C at the same time?  Site B and C would be read only nfs datastores, and site A would be read / write.  Any issues here?  Would my snapmirror have to daisy chain from site A to B then to C?  Or can it go directly from A to B and C at the same time? 

[GARDINEC_EBRD · Accepted solution]

Yes, you can mirror A to B and C at the same time, no problem.

[keitha]

Guys,

I'm late getting to this one but the VSC has the built in functionality to handle this for you. In the Provisioning and cloning section of the VSC it has a remote datastore replication section thats purpose is just for this scenario. It will mount the datastore on the remote vCenter then when you make changes allow you to "sync" the datastores, It will remove the datastore at the remote location, sync the snapmirror and then remount the datastore... Check it out, it might make things easier for you.

Keith

[CLOUDMINER]

Thanks everyone- Keith it sounds like I need to look into this.  I created a separate discussion to try to answer some questions that come from your suggestion.

Your input is welcome if you want to check it out:

https://communities.netapp.com/thread/32010

[justin_smith]

I know this is an old topic, but does this exist with VSC plugin 6.1?

Im trying to do the same thing and hopefully the VSC plugin will remediate it. Instead of VSC, Im doing snapmirror jobs. Right now we have the datastore presented to 3 different vcenters that have roughly 4 clusters within each. The main volume is on our test netapp cluster that has a snapmirror job going to prod (same datacenter) and then to our remote DR datacenter. We're running into some weird VMWare hosts issues that seem to panic lately and we believe the shared storage might be freaking out the hosts.

Is this easier to do with a job in VSC?