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.
-
- Enthusiast
- Posts: 50
- Liked: 1 time
- Joined: Oct 28, 2009 2:19 pm
- Contact:
-
- Chief Product Officer
- Posts: 31780
- Liked: 7280 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Tips on improving the replication of Exchange
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!
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!
-
- Enthusiast
- Posts: 50
- Liked: 1 time
- Joined: Oct 28, 2009 2:19 pm
- Contact:
Re: Tips on improving the replication of Exchange
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?
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?
-
- Chief Product Officer
- Posts: 31780
- Liked: 7280 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Tips on improving the replication of Exchange
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.
-
- Enthusiast
- Posts: 81
- Liked: 5 times
- Joined: Oct 15, 2009 8:52 am
- Contact:
Re: Tips on improving the replication of Exchange
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.The processing rate is really poor (38 MB/s) on a reverse incremental and there are other servers with greater rates of data change.
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!
Who is online
Users browsing this forum: AdsBot [Google], FrancWest and 81 guests