Overhead on hosts from using VSphere replication with SRM.

[Seph8]

Hello,

We're currently looking to begin implementing a SRM solution between our two sites. We've opted to initially use VSphere replication rather than Storage replication for cost reasons. One concern that has been raised while planning this is the performance or resource overhead to our hosts resulting from using the VSphere replication appliances. Can anyone point me to some documentation regarding this, or give me some metrics regarding what kind of overhead we would see? Any info or advice is appreciated.

Thanks,

[dave330i]

Can't point you to any docs, but in SRM5.0, VR replication didn't scale very well. The VR appliance would replicate the VMs serially, so if you wanted a low RPO/RTO you needed 1:1 ratio between proteced VMs & VR appliance.

[mvalkanov]

Hi Dave,

Can you provide more information about "replicate the VMs serially"? If there was an SR, its number would be helpful.

It is the source ESXi replication scheduler that decides when to fire a delta packet to satisfy the RPO requirements (and minimize data transfer). The VR server (running within an appliance) will simply receive the delta packets and write them to the placeholder disks at the target datastores. A single VR server should handle hundreds of replications simultaneously, though there might be some throttling on the traffic send to the storage.

Regards,

Martin

[mvalkanov]

Hi,

I am not aware of any public documentation on this topic yet.

However, the overhead on source host CPU/memory should be marginal:

- A bitmap is being kept when a disk block is changed. Data is transferred only once within an RPO window, even if has been changed multiple times.

- If a block that is currently participating in an delta packet is being changed, it will be temporarily copied to a file at the source host, so that VR can guarantee a consistent copy of the disk when the delta packet completes.

At the secondary site, the VR server writes the received changed blocks and periodically consolidates the redo logs with the placeholder disks. During the initial full-sync checksum is performed, so that if initial copies (replication seeds) are used, only the changed data is transferred, not the whole disks.

Regards,

Martin

[dave330i]

Martin,

That wasn't my experience when using VR replication with SRM 5.0. When we had a VR protect multiple VMs, the delta of 1 VM would be replicated while other VMs were waiting. We ended up deploying 2 SRM, 2 VRMS and 6 VRs.