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.

Replicate Exchange to a DRS (Disaster Recovery Site): Design

Last week, we had a discussion over the design and configuration of an Exchange 2007 server in a DRS.

Of course, as always, there isn’t one answer that fits all. There are a few questions you need to answer to get to a solution that fits your needs:
- How will the data be replicated to the server located in the DRS?
- How performant is the link between the main site and the DRS?
- How important is are the e-mails within your company?
- How much money do you have to spend?

Let’s go over the questions one by one to come to our solution.

1. How will the data be replicated to the server located in the DRS?
There are 4 different replication menthods:
a) Synchronous replication: the Exchange host receives a “successful write” response when the operation is complete on the local AND remote locations.
Advantages:
I. guaranteed no data loss (how is that for a sole advantage … )
Disadvantage:
I. reduced performance (site link, link utilization, distance very important since mails have to saved to both local and remote storage)
II. more expensive than asynchronous replication
III. need for 3rd party software
b) Asynchronous replication: the Exchange host writes to the local storage and the data is replicated independently afterwards
Advantages:
I. not as heavy on performance indicators as synchronous replication
II. cheaper than synchronous replication
III. native Exchange 2007 technology (LCR, SCR & CCR)
IV. robust: (in case of a CCR no single failure will lead to a loss of service)
Disadvantages:
I. no guarantee against data loss can be provided
c) Host-based replication: a filter driver manages the replication (and needs to cut the I/O stream to do this)
d) Storage-based replication: replication at storage level (more performant than host-based replication)

2. How performant is the link between the main site and the DRS?
Whether you choose synchronous or asynchronous replication might not just depend on the budget you have to spend, but also on the environment that is already in place. Be aware that choosing synchronous replication will not only reduce the number of mailboxes per server (up to 75 % reduction in mailboxes/server scalability), the site link is largely impacted as well.

The tools LoadSim and JetStress are developed by Microsoft to test latencies and storage throughput.

3. How important is are the e-mails within your company?
As said above, asynchronous replication cannot guarantee that all data will be retained in case of a “disaster”, while synchronous replication does (providing the site links are operational). However, Exchange 2007 is designed to lose as little information as possible in case of a failure. Thanks to the LCR, CCR and SCR technologies, the losses should be minimized to read/unread messages statuses, incomplete contact, calendar entries, … If this is acceptable for your SLA, they offer a really good solution. Of course, if databases have to be moved to a new stand-by Exchange server, some downtime will be unavoidable.

4. How much money do you have to spend?
I guess this point is pretty clear. Choosing between LCR, SCR and CCR have already huge price effects on your budget. If your SLA requires you to choose for synchronous replication, this price will mount exponentially since third party software will have to be purchased, installed, configured, received training on, …

PowerShell Graphical Help

PowerShell is cool, isn't it? I absolutely love it.

But there was a downside. Using the help function within the PowerShell prompt is difficult to read not to mention it can scroll your screen quite a bit.

So instead of using the help function within PowerShell, the PowerShell guys of Microsoft have created a Graphical Help File.

It contains just the same information as the help within PowerShell when using the -detailed switch, but it comes with some definate advantages:
- fully searchable
- graphical
- seperate window so you can a clear eye on your code

A must have download.