VMware Cloud Community
notesguru99
Contributor
Contributor
‎09-03-2013 06:53 AM

Best Practice - Seeding Replications

Dear All

This is my plan for replicating my VM's to other offices. Just want to make sure all is OK or if there is anything I've missed.

:smileyinfo: 5 offices connected via 10Mbps fibre, one vCenter server, one vSphere replication appliance

  1. Replicate my VM's at Site 1 to a local iSCSI store (QNAP in fact!)
  2. Do one last sync job...... then disable replication for all the replicated VM's...
  3. Then Unmount the datastore at Site 1(QNAP)
  4. Remove the datastore!?
  5. Delete the iSCSI connections at Site 1
  6. Drive up to Site 2 with the QNAP
  7. Plug the QNAP into the iSCSI network at Site 2
  8. Add the device as a new datastore at Site 2
  9. Reconfigure replication pointing at the 'seeded' files
  10. Hey presto all done Smiley Wink

Me being lazy, I am wondering whether I can get away with leaving all of the replication settings intact and then using the reconfigure replication option and point at the datastore again?  Or if I keep the same name of the datastore, will it be smart and just continue to replicate? wishful thinking :smileylaugh:

Any better ideas, much appreciated

Stuart

Reply
0 Kudos
1 Reply
mvalkanov
VMware Employee
VMware Employee
‎09-03-2013 07:47 AM

Hi Stuart,

There is a known issue in VR 5.0.x and 5.1.x - when the managed object id for a target datastore in vCenter Server changes, failover can not be performed - 921061. A datastore might have its managed object id in vCenter Server changed (but uuid preserved), when it is unmounted and later mounted again.

Doing reconfigure on the replication and pointing at the 'seeded' files should help.

In step 2 - do not attempt to "stop" the replication - this will automatically remove all replicated .vmdk files from the target datastore.

You might want to "pause" the replication.

Please note that until reconfigure and next sync are performed, failover can not be performed on these replica files (information in VRMS database about the target datastore would be stale).

In the upcoming VR 5.5 release this issue is resolved. And the scenario above will work without any tweaking on the replications, but simply unmount the datastore and mount it at the new site, ensuring that the same uuid value is used.

If there is any issue with the reconfigure approach described above and most notably to ensure that you have consistent data at the target datastore, and if disaster happens to the source site, the replica can be powered on, in VR 5.1 you could replace step 2 with:

2.1 "Perform recovery (failover) using the latest available data". No need to shutdown the source VM.

2.2 Stop the replication.

2.3 Unregister from vCenter Server the recovered VM at the target site (without removing the disk files)

and replace step 9 with "Configure the replication pointing at the 'seeded' files".

Regards,

Martin

Reply