Hi,
A colleague has raised a question which I'm hoping might be answered here. He is testing Veeam 4.1 on vSphere ESXi 4 Update 1 servers which use local storage. He found that after the initial full replication, the subsequent incremental replications were much larger than expected. Even after moving the pagefile onto a seperate drive and excluding this, the Veeam reports showed a much greater data replication volume than expected. He was testing with a view to providing replication across a 10MB leased line for DR, but has concluded it does not seem viable.
The theory posed was that although a minor amount of data was changed within the Windows guests, the complete VMDK block that data resides in is being copied each time. So a few bytes changed in an NTFS file could equate to a 1/2/4/8 MB copy per block. Is that how it works?
Discussion also revolved around that issue the a near CDP replication schedule would mean the hosts guests are in an almost permanent state of snapshot and concerns were rasied about that.
I had suggested Veeam to the department initially and don't want to see it discounted without understanding these items in more detail. We are traditionally a Double Take house using DTVRA to replicate guests at the guest level, but we felt Veeam offered a cleaner (and lower cost) solution. Anything I can suggest to kickstart the evaluation again or just clarify the raised questions would be of help.
Thanks in advance.
MPLEP
-
- Service Provider
- Posts: 62
- Liked: never
- Joined: Sep 16, 2009 7:50 pm
- Contact:
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Block Tracking Size Questions
Hello, the block size we are using today is 1MB. You are correct that a few bytes changed in the block result in whole block transfered, this is the nature of block level replication. We are testing with smaller block sizes right now too, and will likely add this option to the next release as initial testing results show significant improvements.
Today for most typical workloads we are seeing that replicating every 15 minutes usually result in incremental replications to complete in under 1 minute over decent link even with the current block size, but of course for very I/O active servers you may want to consider lowering replication frequency because they those may take up to 5 minutes to process the changes today. Of course, using slower WAN links also affects these timings accordingly.
Thanks!
Today for most typical workloads we are seeing that replicating every 15 minutes usually result in incremental replications to complete in under 1 minute over decent link even with the current block size, but of course for very I/O active servers you may want to consider lowering replication frequency because they those may take up to 5 minutes to process the changes today. Of course, using slower WAN links also affects these timings accordingly.
Thanks!
Who is online
Users browsing this forum: Bing [Bot], Semrush [Bot] and 56 guests