Tuesday, January 27, 2009

Replicate Exchange to a DRS (Disaster Recovery Site): Best Practices

In my last post I’ve gone over some of the considerations you need to keep in mind when choosing a replication setup for Exchange 2007.

Now there are of course some best practices you can keep in mind when you’ve chosen your setup concerning the replication of Exchange 2007. Since we are on the subject, and in order to keep a nice overview, I’ve created this post which is a summary of the Microsoft guidelines.

1. Mandatory Data to replicate
a) edb files: messages and MAPI-content
b) stm files: non-MAPI content
c) log files: changes to commit to the database
d) chk files: info on the entries in the log files

2. Best Practices for asynchronous replication (replication mechanisms)
a) Configure replication at the logical/mount point volume level: if the mailbox data path is G:\MDB1\MDB1.EDB, then drive G should be the base unit to perform replication. As a result, all the data on drive G will be replicated. Setting replication to occur at the file or subdirectory level is prone to human error and is not supported by Microsoft.
b) Create many replication points: reduce the queuing of multiple I/O’s which are destined for the same replication point
c) Keep transaction logs on different logical volumes: since each write I/O request is queued at the replication point, it is best to split the edb and log files to different logical volumes, to reduce long write response times.
d) Use multiple replication links: expensive, but necessary (although not technically) for availability and load-balancing.

3. Best Practices for Configuring Exchange For Synchronous Replication
a) Create the maximum number of storage groups per Exchange server: there will be more parallel log writing processes, which can reduce the overall transaction log-write latency
b) Increase transaction log buffer size: Increasing the log buffer size reduces the frequency of capacity flushes, increases the log write size, and subsequently reduces the overall log write latency.

That's about it for this post. Of course, this is only a short summary and can (should be) supplemented with other articles on this subject.

No comments: