Tips on improving the replication of Exchange

[icebun]

Reading through the various articles already posted with regard to improving performance over the WAN for Exchange (2003 in my case), am I right in thinking that I need to do the following:-

- Do not tick the option "Do not truncate logs" in the Advanced section

- Disable indexing

If I have missed any of the other recommendations (or if I misinterpreted the existing ones) can someone let me know?

By the way, does powering off the VM before the replication offer any advantages?

Thanks.

[Gostev]

The only tips on improving WAN replication performance of Exchange I have are to use "WAN target" optimization in the job settings, and full ESX as target as opposed to ESXi (with Backup v5).

Not truncating logs will not affect replication performance. Likewise, not performing indexing will not affect replication performance significantly.

Powering off the VM will increase pre/post tasks speed (faster snapshot management, no application quiescence which takes time). However, these operations are usually not a primary bottleneck for replication performance anyway - WAN speed is. Plus, some VMs you just do not want to process in powered off state (such as DCs), because for successful recovery you need to make sure application-aware processing does happen.

Thanks!

[icebun]

Thanks again Gostev.

I should have mentioned that our backup speed is not great either (around 8 hours for a 900GB VM).

The processing rate is really poor (38 MB/s) on a reverse incremental and there are other servers with greater rates of data change.

Is it worth using the WAN Target option for SAN attached backups as well?

[Gostev]

No. WAN Target option will drop the performance for SAN backups. Performance wise, this option is typically only good for when your primary bottleneck is WAN link speed.

[Jonathan]

The processing rate is really poor (38 MB/s) on a reverse incremental and there are other servers with greater rates of data change.

Take a look at the size of the vrb files on your target datastore. Chances are they're at least 50GB a piece. That's 50GB of changed disk blocks. Are you telling me you've got servers other than database hosts that produce that many changes? Don't forget Exchange uses a maintance schedule to defragment its databases. That could mean over 20 percent changed blocks per database, depending on your mail flow.

We're seeing processing rates of roughly 50MB/s for our Exchange 2007 servers over a 20Gbit LAN.
Mind you, the vrb files are anywhere between 50 and 100GB each for a total of 300GB worth of Exchange databases.

Exchange 2010 has its own internal replication mechanism (Database Availability Groups), which we're implementing now. You basically create two Exchange servers, one at each site and Exchange keeps the databases in sync. If you deploy more servers so each database has at least 3 copies, you could stop making backups, increase deleted items retention to a couple of months and enable circular logging. No more brick-level backups!