VRB size-Replication

[jeremystw]

I am in the process of testing replication and trying to see how much bandwidth we are going to need when moving our Exchange 2007 server out to our DR site. Here is my environment.
We are using ESX4, version 7 vms, CBT and have our job enabled enable for every hour.
Our exchange 2007 server has three vmdks 2X250Gb and 1X50GB.
Currently during or reps our VRB sizes are averaging 1.5gb.
Now I know that file change is very different from block level changes but this number seems very high considering we are only doing approximately 4GB in Exchange transaction logs a day.
Is there anything I can do to minimize the size of this VRB file so that we are not utilizing so much bandwidth.
If not doesn't this suggest that for Exchange a application aware replication (like double take) may be a better option if you have limited bandwidth?
Thanks for your help with this,
Jeremy

[Gostev]

Jeremy, here is what other customers are doing to minimize WAN traffic.
Replication and SQL re-indexing tasks

Hope this helps.

[tsightler]

I'm not a Veeam employee, but I can say this, Veeam 4.1 makes HUGE VBR files for Exchange and other highly transactional systems. This is mainly due to it's block size. Veeam uses 1MB blocks while Exchange typically uses something like 8KB blocks. Because Exchange is both writing logs, and changing data blocks all over the EDB files, you get huge VBR files.

That doesn't mean that Veeam doesn't work in this scenario, but bandwidth is important. We have a ~500GB Exchange server and typically see VBR's in the 75GB range. Fortunately, our WAN acceleration boxes allow replication to work in a reasonable way even at this size by cutting the traffic that actually crosses the wire more that 80%.

We decided Veeam was still a win because we were looking for a simple solution that would work across all of our VM's, and while Veeam is not the most efficient, the fact that it can be used for backup or replication, for any VM, was better than using point products to address specific applications, but we were lucky enough to have WAN acceleration and a reasonably sized link. You may not be this same situation so the point products that are ultra space efficient might be the better choice for you.

[jeremystw]

Thanks Gostev and Tom,
We are planning on getting more bandwidth so this should help solve the issue. I was hoping there was going to be a magic switch that would solve this issue but such is life. I also assume latency can be a big factor in eplication performance over a WAN, is there a ttl above which issues can occur?
Thanks,
Jeremy

[Gostev]

Jeremy, we have added a number of optimizations to the product in previous release to better support slow and high-latency WAN links, so at this time the product treats bad links fine (as long as the connection does not drop).

[glennsantacruz]

Fortunately, our WAN acceleration boxes allow replication to work in a reasonable way even at this size by cutting the traffic that actually crosses the wire more that 80%.

@tsightler - would you mind sharing specifics regarding your WAN optimization? Software-based, appliance-based, baked into existing routers, etc?

If you'd prefer not to publicly disclose vendor preference, would you private message instead?

[Gostev]

Tom has already posted some information on his deployment earlier in this thread:
Anyone used WAN accelleration tools to replicate over WAN?