We have been getting a fair number of questions regarding interoperability of vSphere Data Protection (VDP) and vSphere Replication (VR) both of which are included with vSphere 5.1 (Essentials Plus and higher). I spent some time in my lab with these questions and decided to focus on the two most common questions: 1. Does VDP and VR interfere with each other? 2. Can I use VR to replicate VDP to another site?
For the first question/scenario, I set up replication for three virtual machines (VMs). With VR, you can set the Recovery Point Objective (RPO) within the range of 15 minutes to 24 hours. I chose 15 minutes for all three VMs to maximize the frequency of VR operations against the VMs. I also made sure that one of the VMs was performing an initial sync. The initial sync in VR is when the entire VM is being replicated from the source to the target location for the first time. Once the initial sync is complete, only the changes to the VM are replicated to minimize bandwidth usage and maintain RPO policy compliance. Having VMs with VR performing an initial sync and regular (lightweight delta) syncs allowed testing against both replication status types. Having both replication status types running in the environment, I then ran several manually backup jobs using VDP. These jobs consisted of both the initial full (entire VM) backup and the subsequent synthetic full (changed blocks) backups. VDP and VR performed well together. The only hint of an issue that I saw was a warning message stating that replication for a VM is not active. This occurred when I manually started a replication cycle and a backup at the same time. The warning went away within a minute or two and I found no evidence that either job had any failures. VDP reported a successful backup and VR reported "OK" for the replication status a few minutes later suggesting VR simply retried replication. I also let the environment "simmer" for a few days leaving the RPO setting for the VMs at 15 minutes and VDP running its scheduled backup jobs for the same VMs once per day. Again, no evidence of issues.
For the second question/scenario, I configured VR to replicate the VDP appliance and set the RPO to its most aggressive setting of 15 minutes. I configured replication during the middle of the day. At that time, the backup window was closed and scheduled to open at 8:00 PM. The initial sync completed fine, as expected. However, once the backup window opened and the scheduled backups started, a warning message was logged: "System has paused replication for virtual machine vSphere Data Protection on host in cluster Cluster in Datacenter: Disk added to VM". As part of the backup process, VDP (along with several other backup and recovery solutions) utilizes the SCSI HotAdd functionality of vSphere to improve backup job efficiency and to keep backup traffic off of the network. The .vmdk being backed up is dynamically attached to the VDP appliance while the backup is occurring. VR detected the addition of the .vmdk file and paused. Replication of the VDP appliance was paused indefinitely and required manual intervention to reconfigure replication for the VDP appliance. This issue occurred every time the backup window opened. The RPO could be changed to make the replication occur less frequently – perhaps a RPO policy somewhere between 18 and 24 hours – thus reducing the chance replication will occur when backup jobs are running. This still does not guarantee that VR will not attempt to replicate changes to the VDP appliance at the same time backup jobs are running.
In summary, there appears to be no issues with both VR and VDP protecting a VM. In contrast, it is not recommended to use VR to replicate a VDP appliance. In an upcoming article, I will look at recovering VDP from a (non-VR) replicated or cloned copy of the VDP appliance. Stay tuned…
blogs.vmware.com [X] <http://blogs.vmware.com/vsphere/2012/10/vdp-and-vr-interoperability.html> |by Jeff Hunter on October 15, 2012
◆
________________________________
Original Page: http://blogs.vmware.com/vsphere/2012/10/vdp-and-vr-interoperability.html
Sent from Feeddler RSS Reader
No comments:
Post a Comment