Re-sync when everything is outa sync

Re-sync when everything is outa' sync

Since vSphere Replication hit last year, I have had to walk countless people through a vSphere Replication re-deploy. The re-deploy is for another post but what I want to cover here is the BEST way to re-create your replications with the least amount of hassle.

The setup:

I have my VM, cLevingerAD replicating successfully from our production site to the DR site. I have shown it here in SRM but it could be in the 5.1 web client as well.

The problem:

I need to stop replication and re-start it for some reason. This could be for a million reasons. Some of the common ones are you need to make a change to the VM, you need to re-deploy vSphere Replication, you failed over and now you need to reverse replication, you need to stop replication for some business reason but want to enable it later. Whatever the reason, you have a need, let's give you a solution.

So, how do I go about this? Well, you could hit the "Remove Replication" button and then just re-replicate everything AGAIN but this isn't the best way to go about this. Instead, we can preserve the remote VMDKs and use them as initial seeds. This means we don't have to replicate any of the already-replicated information. vSphere Replication will go through the disks at the Production and DR sites and compare them. It will figure out what is different and then only replicate the changes made while replication was off.

The procedure:

So how do we do this magic? Easy, first, we want to pause replication.

This ensures that no operations will go through while we make changes to the back-end storage.

Next, we need to change the name of the VMs folder at the DR site. I usually add "(hold)" to the end of the folder name. When we remove replication late, the vSphere Replication Appliance looks for the name of the folder from when replication was initially created. Since it's no longer there (cLevingerAD  ≠ cLevingerAD(hold)) vSphere Replication will leave this new folder alone.

After changing the folder name, we can safely remove replication.

Now we can make all the changes we want to the VM. Once we are done messing around with it, we can re-enable replication using the old disks as initial full seeds. The first thing we want to do is change the folder name back to the original name. This isn't absolutely necessary but a good idea so that all of the folder names are the same. 



After re-re-naming the folder, we can enable replication for the VM. Click the VM, then click the vSphere Replication tab and click "Configure Replication". This will bring up the vSphere Replication configuration page. 

Here is where we work our magic. When it asks for the destination, we are going to specify the old datastore. 

Hit OK and if you did everything right, a message should pop up saying that an initial seed was found and do you want to use it. Duh, of course we want to use it.

 Finish the configuration (note that on the summary page next to "initial seed found" we see "yes").

So you finish this and you expect to see a regular sync going through. WRONG. You will see "initial full sync" just like you would if you replicated from scratch. 

So what was the point of all of that?! This is normal. The initial full sync is mapping the 2 VMKDs and only replicating the changes made. It will take a little longer than a regular sync due to the mapping processes but not nearly as long as replicating ALL the data again. 

All in all, this process can be used for a lot of different reason, re-deploying being one of them that I will cover in another post, but hopefully this sheds some light on how to avoid re-replication and make your vSphere Replication experience a little better (and faster!).

Thanks for reading and don't forget to follow me on Twitter! @SRM_Guru

**********************************************Disclaimer**********************************************
This blog is in no way sponsored, supported or endorsed by VMware. Any configuration or environmental changes are to be made at your own risk. Casey, VMware, and any other company and/or persons mentioned in this blog take no responsibility for anything.